NIST collaboration and testing CONNECT 4.5

Overview

The CONNECT team has collaborated with the NIST team on testing and validating SOAP-based transport for XDR Document Submission and Direct using the NIST's Transport Testing Tool (TTT). This is part of an ongoing effort to ensure that the CONNECT product meets all compliance requirements that are being tested by various certification bodies including NIST. 
 

Important

The NIST TTT that used for this test is no longer available; NIST ETT may be use but current document reference for NIST TTT.  the source for the TTT may be found here.

CONNECT 4.5 Release Testing with NIST TTT

  • Latest version tested: CONNECT 4.5 RC1
  • XDR Send from the TTT to the CONNECT SUT resulted in successful execution with no errors. Document Submission from the CONNECT SUT to the TTT uncovered a possible specification compliance issue documented in CONN-1532. Ongoing discussions will determine whether or not changes need to be made to the way CONNECT prepends hl7 to the purposeOfUse attributes post 4.4 release. All tests executed on 06/17/2015.
  • Direct testing with NIST TTT successful with both SUT and TTT as recipient. Direct Message Validation Reports attached to this page (executed on 06/19/2015)

NIST Edge Testing Tool (https://ttpedge.sitenv.org/ttp/#/home)

As of CONNECT release 4.5, ETT testing for only the following are available:

  • XDR Document Submission
  • DIRECT

SUT Setup

Set up trust store and key store

keytool -export -rfc -alias gateway -file nist.cer -keystore keystore -keypass changeit -storepass changeit
  • Import the NIST certificate into cacerts.jks 
keytool -import -v -noprompt -trustcacerts -alias HOST1 -file nist.cer -keystore cacerts.jks -storepass changeit
  • If the certificate already exists in cacerts.jks, delete the HOST1 certificate and import the NIST certificate:
keytool -delete -alias HOST1 -keystore cacerts.jks
keytool -import -v -noprompt -trustcacerts -alias HOST1 -file nist.cer -keystore cacerts.jks -storepass changeit

Configure Direct

  • Import the direct.connectopensource.org mail certificate into cacerts.jks (TTT not set up to communicate with direct.connectopensource.net)
  • If configdb is not already set up for Direct testing, run PopulateConfigDB-CERTS-anchors.sql
  • Download the NIST trust anchor at http://transport-testing.nist.gov/ttt/pubcert/nist.gov.der
  • Using AdminGUI, add the trust anchor to the Direct domain

Configure connect to use NIST keystore

domain.xml
Set NIST keystore as the new key store:
 
	Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore
 
Set SSL port to 443:
 
	<network-listener port="443" protocol="http-listener-2" transport="tcp" name="http-listener-2" thread-pool="http-thread-pool"></network-listener>
signature.properties
Replace org.apache.ws.security.crypto.merlin.file=gateway.jks with:
 
	org.apache.ws.security.crypto.merlin.file=keystore
PolicyEngineProxyConfig.xml
Replace adapterpolicyengineorchestratorsamljava with adapterpolicyengineorchestratorjava:
 
	<!-- Beans defined : Adapter Policy Engine Orchestrator -->
	
		<alias alias="adapterpolicyengineorchestrator" name="adapterpolicyengineorchestratorjava" />

Restart the application server!

XDR Testing

Set up TTT to send XDR to SUT and send XDR

Provide NIST team with SUT endpoints:

  • XDR Send = Document Submission:  https://<Hostname or IP address>:443/Gateway/DocumentSubmission/2_0/DocumentRepositoryXDR_Service

Send request from TTT to SUT

  1. Browse to http://transport-testing.nist.gov/ttt/
  2. Click on XDR Send
  3. In Environment dropdown, select SOAP_TEST
  4. Enter local patient ID
  5. In Select Test Data Set, select anything that has full metadata
  6. In SAML dropdown, select NHIN SAML
  7. Check the TLS box
  8. For Document Recipient, choose the Actor
  9. Click Run
  10. Click Inspect Results for detailed test results.

Set up TTT to accept XDR from SUT

Define an Actor Simulator:

  1. On the Home panel, select the “Simulator Control” in the “Simulators” column
  2. In the Environment dropdown, select SOAP_TEST
  3. Select “Document Recipient” from the Actor Type pull-down menu.
  4. Click “Create Actor Simulator”
  5. Copy the End Point Displayed in “PnR TLS endpoint”, this is a TLS endpoint, DO NOT USE the PnR endpoint above it, as it is non-TLS. Note/Copy the TLS endpoint displayed in the page which needs to be updated in the uddiConnectionInfo_g1.xml. The endpoint looks like https://ttt.transport-testing.org:8443/ttt/sim/e6bb0458-ee24-42dc-a003-cb28683e3cd2/rec/xdrpr where the bold characters in the URL is the simulator actor data which will change for each simulator actor we create.
  6. Select the Expected C-CDA Type from the list that you will send to the TTT, this will allow the C-CDA to be sent to the appropriate Validator. This endpoint will always be associated with this type C-CDA, you will create an endpoint for each C-CDA you will send. Select Non-CCDA content (no validation) as Expected CCDA Type for XDR content.
  7. Enter in the “Name” field the Name you wish to give this connection and save it.
  8. Click “Save”, this will create a new simulator under the name you entered above. You can continue to create several connections here, give each a different name to reference later. These names can be referenced in the simulator control messages page for filtering.
  9. To leave the “Sim Control” menu up, click “Home”

Set up SUT to submit a document to TTT

  1. In validation suite uddiConnectionInfo_g1.xml, for the 2.2 gateway, change the Document Submission endpoint https://<Host Name or IP Address>:8181/Gateway/DocumentSubmission/2_0/DocumentRepositoryXDR_Service to the NIST TLS endpoint created above.
  2. In validation suite internalConnectionInfo_g1.xml, replace all 8181 ports to 443.
  3. In validation suite - g1 - Document Submission test case request, blank out the content for the <urn1:resource> tag.
  4. In validation suite - g1 - Document Submission test case request, change the value of Association type for the <urn4:Association> tag to "urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember".
  5. In validation suite - g1 - Document Submission test case request, provide a valid urn:oid value for AccessConsentPolicy tag like urn:oid:1.2.3.4.
  6. In validation suite - g1 - Document Submission test case request, provide a valid urn:oid value for instanceAccessConsentPolicy tag like urn:oid:1.2.3.4.123456789.

Submit a document from SUT to TTT

  1. In SoapUI, execute the g1 Document Submission test.
  2. Click on “Simulator Message View” in the NIST toolkit. Select the name from the drop down menu “Simulator”.
  3. When the message from the messages list is selected, request and response messages, detailed log are displayed. The response contains the validation errors and/or warnings detected by the tool. Additionally, the bottom part contains a log that can be inspected for further insights on the tests performed.

Direct Testing

Register a Direct email address with the TTT

  1. In TTT Home under Direct, click Registration
  2. Contact Email Addr*: Email account to receive validation reports - NOT the same as Direct email address
  3. Click Load/Create Contact
  4. Direct (From) Email Addr*: Direct email account from where Direct messages will be sent to the TTT and to where the TTT will send Direct messages
  5. Click Add

Send Direct messages to SUT

  1. In TTT Home under Direct, click Send Direct Message
  2. Direct From Address: Enter "test" (mail will be sent from test@transport-testing.nist.gov)
  3. Direct To Address: Enter the Direct email created in Register steps above
  4. Choose document to be sent as the message content: See table below for a list of documents to send

  5. Message Format: Always select wrapped
  6. Signing Certificate: See table below for a list of Signing Certificates to use
  7. Encryption Certificate: Click Browse and select connectopensourceorg.der
  8. Click Submit
  9. In TTT Home under Direct, click View Direct Message Status
  10. Click Load without selecting a test session. Message will need to be identified based on the time the message was sent. Click Load again to refresh the message status.
  11. Verify the expected results approximately two minutes after the message was sent
    1. If an MDN is received by the TTT, check validation report sent from TTT to the contact email address specified in the Register section for any failures or errors
DocumentSigning CertificateExpected ResultLatest Test Results
CCDA_Inpatient_in_XDM

GOOD_CERT

MDN was received by the TTT (MDN Validation Status is MDN Received)
Message Validation Report sent to contact email address 

PASSED on 06/19/2015
Message Validation Report

CCDA_InpatientGOOD_CERTMDN was received by the TTT (MDN Validation Status is MDN Received)
Message Validation Report sent to contact email address 

PASSED on 06/19/2015
Message Validation Report 

CCDA_Inpatient_in_XDMINVALID_CERTNo MDN was received by the TTT (MDN Validation Status stays at Waiting for MDN)
No Message Validation Report generated 

PASSED on 06/19/2015
No Message Validation Report

CCDA_InpatientINVALID_CERTNo MDN was received by the TTT (MDN Validation Status stays at Waiting for MDN)
No Message Validation Report generated 
PASSED on 06/19/2015
No Message Validation Report
CCDA_Inpatient_in_XDMEXPIRED_CERTNo MDN was received by the TTT (MDN Validation Status stays at Waiting for MDN)
No Message Validation Report generated 
PASSED on 06/19/2015
No Message Validation Report
CCDA_InpatientEXPIRED_CERTNo MDN was received by the TTT (MDN Validation Status stays at Waiting for MDN)
No Message Validation Report generated 
PASSED on 06/19/2015
No Message Validation Report
CCDA_Inpatient_in_XDMCERT_FROM_DIFFERENT_TRUST_ANCHORNo MDN was received by the TTT (MDN Validation Status stays at Waiting for MDN)
No Message Validation Report generated 
PASSED on 06/19/2015
No Message Validation Report
CCDA_InpatientCERT_FROM_DIFFERENT_TRUST_ANCHORNo MDN was received by the TTT (MDN Validation Status stays at Waiting for MDN)
No Message Validation Report generated 
PASSED on 06/19/2015
No Message Validation Report

Send DIRECT messages to TTT

  1. Send email to each NIST Direct email address in the table below (one at a time)
  2. Check validation report sent from TTT to the contact email address specified in the Register section for any failures or errors

CCDA_Inpatient.xml and CCDA_Inpatient_in_XDM.zip can both be downloaded from the shared drive in the \shared-folder\nist\4.4_release\documents directory

Direct (To) addressDocument to attachExpected ResultsLatest Test Results
direct-inpatient@transport-testing.nist.govCCDA_Inpatient.xml (copy and paste contents of CCDA_Inpatient.xml directly into the email)Automatic MDN from TTT is received by the Sending Edge and Validation report shows no failures or errorsPASSED on 06/19/2015
Message Validation Report
direct-inpatient-xdm@transport-testing.nist.govCCDA_Inpatient_in_XDM.zip (attach the entire zip file to the email, leave the email message blank)Automatic MDN from TTT is received by the Sending Edge and Validation report shows no failures or errorsPASSED on 06/19/2015
Message Validation Report 
ccda@transport-testing.nist.govNone (Leave message blank)Automatic MDN from TTT is received by the Sending Edge and Validation report shows no failures or errors

PASSED on 06/19/2015
Message Validation Report

ccda@transport-testing.nist.govCCDA_Inpatient.xml (copy and paste contents of CCDA_Inpatient.xml directly into the email)Automatic MDN from TTT is received by the Sending Edge and Validation report shows no failures or errors

PASSED on 06/19/2015
Message Validation Report

Appendix A:  Acronyms

ATL - Authorized Test Laboratories
CDA - Clinical Document Architecture
MDN - Multicast Domain Name System
MU  - Meaningful  Use
NHIO - National Health Insurance Office
NIST - National Institute of Standards and Technology
PnR - Provide and Register
SAML - Security Assertions Markup Language
SUT - System Under Test 
TLS - Transport Level  Security
TTT - Transport Testing Tool

Transport Testing Tool User Guide
Transport Testing Tool Configuration (source)