1. CONNECT: Release 2.3 Webinar January 19, 2010

2. CONNECT Architecture Overview Les Westberg 2

3. CONNECT Architecture Message from NHIN 3

4. CONNECT Architecture Message to NHIN 4 CONNECT Adapter Entity Integration Software CONNECT Gateway Message Proxy Components CONNECT Core Components Patient Discovery Query for Documents Retrieve Documents Subscription Management Notification Processing Audit Reporting Patient Correlation Repository Audit Repository Document Cache Subscription Repository UDDI Update Management Others SDK Services Data Transforms Terminology Services Others Patient Discovery Query for Documents Retrieve Documents Subscription Management Notification Processing Audit Reporting CONNECT Components Customizable Components Replaceable Components Entity Orchestration Components Patient Discovery Query for Documents Retrieve Documents Subscription Management Notification Processing Audit Reporting Connection Manager NHIN Patient Correlation Patient Discovery Query for Documents Retrieve Documents Notification Processing Audit Reporting Notification Processing Pass Through

5. Orchestrated vs. Pass Through Mode 5 Adapter Interface Pass-Through NHIN Message Receiver CHOICE OF PATH BASED ON CONFIGURATION Internal NHIN Message Orchestrator

6. CONNECT Development Environment Version 2.1 6 ItemVersion Java JRE/JDK1.6 Update 16 GlassFish2.1.1 NetBeans6.7.1 Metro1.5 MySQL5.1.41 SoapUI3.0.1

7. Major Changes in 2.3 Support of the Updated NHIN Specs: –Access Consent –Audit Query –Authorization Framework –Document Query / Document Retrieve –GIPSE Profile –Patient Discovery (replaces Subject Discovery) FIPS Compliance integrated 2.3 Baseline Migration towards [App Server – Platform Independence] using JBOSS Improvements to the Continuous Integration Process. 7

8. Support of the Updated NHIN Specifications Access Consent Les Westberg 8

9. Summary of Changes Fine-grained policy document stored as XACML –Previously it was CDA wrapping XACML Storage/Retrieval of PDF Consent Documents –AdapterPIP interface modified Added “Query by Event” support to Document Query Changed document registry meta-data to conform to latest NHIN specification Removed HIEM notification of access consent documents Updated SAML assertions which identify remote access consent documents Creation of XSPA XACML to be sent to Policy Decision Point (PDP) 9

10. Things to be Aware Of Fine-grained policy changes were made only to storage and retrieval functions – not to the policy decision point (PDP) Redaction has not been implemented yet CPP GUI is not supported under Release 2.3 –SoapUI test used to store and retrieve Access Consent documents AdapterPIP-soapui-project.xml Custom XACML still used between gateway and adapter –Transformed to XSPA XACML by the Policy Enforcement Point (PEP) XSPA support limited to current OASIS specification –Authorization framework fields which are not defined in XSPA are not sent to PDP 10

11. Support of the Updated NHIN Specifications Audit Query Visu Patlolla 11

12. Audit Query NHIN Specification: Audit Log Query Specification Version 1.3.1 Dated: 02/03/2009 Underlying Specifications: HITSP/TP15 Collect and Communicate Security Audit Trail Transaction Version 1.4, July 8, 2009 IHE ITI TF Revision 5.0 Vol 1& 2 2008-12-12 IHE IT Infrastructure Technical Framework Supplement 2007-2008: Cross-Enterprise Document Sharing-b (XDS.b) IHE IT Infrastructure Technical Framework Supplement 2007-2008: Cross Community Access XC 12

13. Audit Query Incorrect Namespace in Audit Query WSDL The version of the Nhin Audit Query WSDL used by the CONNECT Gateway did not use the correct Target Namespace from NHIN. Changes were made to the NhinAuditLogQuery.wsdl file to use http://services.nhin.com instead of http://services.nhin.com/wsdl/auditlogqueryhttp://services.nhin.com http://services.nhin.com/wsdl/auditlogquery NhincAuditQueryEJB, EntityAuditLogQueryEJB, and NhinAuditQueryProxyImpl NetBean projects updated as appropriate 13

14. Support of the Updated NHIN Specifications Authorization Framework Victoria Vickers 14

15. Baseline Authorization Framework Purpose of the Authorization Framework Specification Defines the structure of the SAML header for cross enterprise messages Defines the NHIN specific attributes Underlying Specifications Assertions and Protocols for the OASIS Security Assertion Markup Language(SAML) V2.0 http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare Version 1.0 http://docs.oasis-open.org/security/xspa/v1.0/saml-xspa-1.0.pdf 15

16. Focus of Modifications in Release 2.3 New NHIN Attributes New Attribute Statement Attributes Home Community ID Attribute –Provides the Home Community initiating the request –OID format of the NHIE –Example - urn:oid:2.16.840.1.113883.3.190 Patient Identifier Attribute –The patient as identified in the requesting organization –OID for the assigning authority and the identifier of the patient within that assigning authority –Example – 543797436^^^&1.2.840.113619.6.197 &ISO New Authorization Decision Statement Attributes The “ContentReference”, “ContentType”, and “Content” attributes from the Trial Implementation specifications have been removed and should no longer be used AccessConsentPolicy Attribute –NameFormat “http://www.hhs.gov/healthit/nhin” –Value is the OID of the access policies that the asserting entity has previously agreed to –Example - urn:oid:1.2.3.4 InstanceAccessConsentPolicy –NameFormat “http://www.hhs.gov/healthit/nhin” –Value is the OID of the patient specific access policy instances –Example - urn:oid:1.2.3.4. 123456789 16

17. Focus of Modifications in Release 2.3 Attribute Statement – Attribute Name Attribute naming moves toward XSPA profile for SAML User Name Attribute: urn:oasis:names:tc:xspa:1.0:subject:subject-id User Organization Attribute: urn:oasis:names:tc:xspa:1.0:subject:organization Organization ID Attribute: urn:oasis:names:tc:xspa:1.0:subject:organization-id Home Community ID Attribute: urn:nhin:names:saml:homeCommunityId User Role Attribute: urn:oasis:names:tc:xacml:2.0:subject:role Purpose For Use Attribute: urn:oasis:names:tc:xspa:1.0:subject:purposeofuse Patient Identifier Attribute: urn:oasis:names:tc:xacml:2.0:resource:resource-id 17

18. Focus of Modifications in Release 2.3 Attribute Statement – Coded Elements Usage of CE datatype from HL7 v3 User Role Attribute Value –HL7 namespace - hl7:Role xmlns:hl7="urn:hl7-org:v3“ xsi:type="hl7:CE" –The code is assigned from SNOMED CT as defined for “NHIN-ROLE” –The codeSystem is defined to be “2.16.840.1.113883.6.96" –The codeSystemName is defined to be "SNOMED_CT“ –The displayName shall correlate with the assigned code Purpose for Use Attribute –HL7 namespace - hl7:PurposeForUse xmlns:hl7="urn:hl7-org:v3“xsi:type="hl7:CE" –The code is assigned from Authorization Framework specification –The codeSystem is defined to be “ 2.16.840.1.113883.3.18.7.1 " –The codeSystemName is defined to be " nhin-purpose” –The displayName shall correlate with the assigned code 18

19. Ins and Outs Authorization Framework Fields Transform Assertion Class to/from SAML assertions Assertion class fields –User Name Attribute: Assertion.userInfo.personName (familyName, givenName, secondNameOrInitials) –User Organization Attribute: Assertion.userInfo.org.name –Organization ID Attribute: Assertion.userInfo.org.homeCommunityId –Home Community ID Attribute: Assertion.homeCommunity.homeCommunityId –User Role Attribute: Assertion.userInfo.roleCoded (code, codeSystem, codeSystemName, displayName) –Purpose For Use Attribute: Assertion.purposeOfDisclosure (code, codeSystem, codeSystemName, displayName) –Patient Identifier Attribute: Assertion.uniquePatientId Defines XACML Attribute Values for Policy Engine Usage 19

20. Support of the Updated NHIN Specifications Document Query / Retrieve Neil Webb 20

21. Asynchronous Web service calls tested for Doc Query/Retrieve CONNECT supports Asynchronous Web service calls. The NHIN Specification was updated for Document Query and Document Retrieve to support Asynchronous web service calls by initiating and responding Gateways. This was tested and found that the current NHIN Gateway release 2.3 already had capabilities to support Asynchronous Web service calls. The test is performed using a JAX-WS Java client project. When a client calls a JAX-WS Web service operation asynchronously, the client does not need to wait for the response to be received. The client consumes the web services either through the “polling” or the “callback” approach. We used the “callback” approach to test this. The client passes a callback handler during the web service method invocation. The handler’s handleResponse() method is called when the result is available. 21

22. Support to XDS.b error codes CONNECT supports various XDS.b error codes The NHIN Specification was updated for Document Query and Document Retrieve to support a set of error codes. This was tested with a SoapUI project and found that the Gateway is already capable of handling all the error codes mentioned below with out any code modifications.  XDSRegistryError  XDSRegistryBusy  XDSRegistryOutOfResources  XDSTooManyResults  XDSUnknownStoredQuery  XDSStoredQueryMissingParam  XDSStoredQueryParamNumber Note: Expect for BAD ID, all other error codes are supported by NHIN Gateway. The BAD ID is not directly supported by XDS Registry Services instead we get an XDSRegistryError. 22

23. Additional Stored Query Support Document Query Stored Query Stored query types –FindDocuments –FindFolders –GetAll –GetDocuments –GetFolders –GetAssociations –GetDocumentsAndAssociations –GetSubmissionSets –GetSubmissionSetAndContents –GetFolderAndContents –GetFoldersForDocument –GetRelatedDocuments Created SoapUI tests to verify proper handling in the gateway 23

24. Document Query and Retrieve Audit Audit Modifications Additional Fields –EventID –EventTypeCode Document Query –EventID set to “110112” –EventTypeCode set to “ITI-18” Document Retrieve –EventID set to “110107” –EventTypeCode set to “ITI-17” 24

25. Support of the Updated NHIN Specifications GIPSE Profile Scott Borst 25

26. GIPSE Profile This is a HIEM profile. The GIPSE Profile specification contains definitions for the following five topics: nhin:DeidentifiedPopulationHealthData nhin:DeidentifiedPopulationHealthData/Biosurveillance nhin:DeidentifiedPopulationHealthData/Biosurveillance/InfluenzaLikeIllness nhin:DeidentifiedPopulationHealthData/Biosurveillance/Influenza nhin:DeidentifiedPopulationHealthData/Biosurveillance/Pneumonia The topics were added to hiemTopicConfiguration.xml and validated using the HIEM services in R2.3 and a small GIPSE file. 26

27. GIPSE Profile The profile is currently in use by the following agencies: Centers for Disease Control & Prevention (CDC) New York State Department of Health (NYSDOH) Northwest Public Health Information Exchange (NW-PHIE) Indiana State Department of Health (ISDH) 27

28. Support of the Updated NHIN Specifications Patient Discovery Jon Hoppesch 28

29. Subject Discovery vs. Patient Discovery 29 FeatureSubject DiscoveryPatient Discovery Matching Matching done by patient name and a small subset of demographics Matching done by a larger set of demographics CommunicationAnnounce/Revoke/AckQuery/Results Messages Used HL7 201301, 201302, and 201303 messages Uses HL7 201305 and 201306 messages Correlations Correlations are added and removed via SD messages Correlations are added via PD messages, but removal is based on an expiration value

30. What’s new in Patient Discovery Based on query by search method Patient search is based on demographic data Cannot revoke correlations at another community Uses expiration date in patient correlation for cleanup of correlations Supports both synchronous and asynchronous mode of transactions More detailed error handling Policy checks before sending messages out on the NHIN as well as on the receipt of a message Added hooks to Entity Messages to support community lists and state (regions) messages targets 30

31. Three modes of Patient Discovery Trust Mode This mode of response does not require the responding gateway to verify the match but instead creates a patient correlation directly based on the responding message. Verify Mode* This mode of response indicates the responding gateway to verify the match before agreeing on the match and create a patient correlation. Pass-through Mode The responding gateway sends the message directly to the agency without creating any patient correlation. * Verify is the default Mode 31

32. Patient Discovery – Outbound Request Flow Diagram The flow diagram depicts CONNECT sending a patient discovery request message to NHIN and receiving a response back from NHIN 32

33. Patient Discovery – Outbound Request Flow Diagram 33 The flow diagram depicts CONNECT responding to a patient discovery request message from NHIN (remote gateway)

34. Patient Discovery Story Plan The story plan is a new concept created for patient discovery in an attempt to put together Main (happy) and alternate paths to determine various acceptance criteria. For further information go to http://www.connectopensource.org/display/CONNECTWIKI/Patient+Discovery http://www.connectopensource.org/display/CONNECTWIKI/Patient+Discovery 34

35. FIPS Compliance Visu Patlolla 35

36. Purpose, FIPS 140-2, and NSS Cryptographic Solution Purpose FIPS (Federal Information Processing Standards) publication 140-2 defines the Security Requirements for Cryptographic Modules. Cryptographic modules used in CONNECT should be FIPS 140-2 compliant in order to meet Federal Government requirements. Evaluated FIPS 140-2 compliant Cryptographic Solutions Network Security Services (NSS) Cryptographic Module (Software Version: 3.11.4), wiki.mozilla.org/NSS. NSS depends on Netscape Portable Runtime (NSPR) libraries. wiki.mozilla.org/NSS Crypto++™ Library (Software Version: 5.3.0 [32-bit and 64-bit]), www.cryptopp.comwww.cryptopp.com OpenSSL FIPS Object Module (Software Version: 1.1.1), www.openssl.orgwww.openssl.org NSS Cryptographic Solution Network Security Services (NSS) was selected because the Glassfish’s enterprise profile has built-in support and it is pre-configured to use NSS libraries. NSS was FIPS 140-2 Level 2 certified. 36

37. SunPKCS-NSS Provider NSS modules consists of native libraries written in C and they are platform dependent. NSS libraries are integrated into Glassfish using SunPKCS security provider dynamically. SunPKCS configuration required for loading NSS libraries. These will be stored in a file ending with.cfg. For example, nss.cfg name=NSS nssLibraryDirectory=%AS_HOME%\lib nssSecmodDirectory=%AS_HOME%\domains\nssdomain\config nssModule=fips showInfo=true nssUseSecmod=true where %AS_HOME% is the Glassfish home directory and should be replaced with absolute path 37

38. Configuring NSS in CONNECT Create Glassfish Enterprise domain. Add NSS and NSPR libraries to Glassfish library folder. Update Glassfish enterprise domain’s domain.xml with the NSS configuration. Add <property name="NSS Certificate DB” value="${com.sun.aas.instanceRoot}/config/nss.cfg"/> to the element in domain.xml. Configure SSL protocols and Cipher suites. Follow the CONNECT source code/binary installation to deploy the CONNECT application on the enterprise domain. Detailed instructions are available in the following document: http://www.connectopensource.org/download/attachments/23691564/CONNECT_Release_2_3_F IPS_010510.pdf http://www.connectopensource.org/download/attachments/23691564/CONNECT_Release_2_3_F IPS_010510.pdf 38

39. References http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm Download NSS from ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_11_4_RTM/ ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_11_4_RTM/ Download NSPR from ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.6.4/ ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.6.4/ http://www.connectopensource.org/download/attachments/23691564/CONNECT_Rele ase_2_3_FIPS_010510.pdfhttp://www.connectopensource.org/download/attachments/23691564/CONNECT_Rele ase_2_3_FIPS_010510.pdf 39

40. Migration Towards App Server – Platform Independence using JBoss Sai Valluripalli 40

41. Application Server Independence Using JBoss CONNECT wanted to be "J2EE Application Server" Independent We have verified that CONNECT 2.3 is portable to other application servers other than GlassFish. Verified using JBoss Application Server. Ran internalSelfTest and found everything works fine. There are few minor code modifications required with respect to annotations on service objects. Have to generate vendor specific deployment descriptors (Jboss.xml) Need to identify the configuration options, files and their physical location to modify. Update the third party libraries for App Server specific (Jboss) example: Metro. Posted to public Wiki: http://www.connectopensource.org/display/CONNECTWIKI/CONNECT+on+JBoss http://www.connectopensource.org/display/CONNECTWIKI/CONNECT+on+JBoss 41

42. Application Server Independence Using JBoss Deployment issues (NO CODE MODIFICATIONS REQUIRED) Note: After adding JBoss deployment descriptor jboss.xml file, do a build and place all the EJB jar files under the deploy path of your JBoss installation "C:\jboss- 5.1.0.GA\server\default\deploy" and restart your JBoss Application Server. Run the InternalSelfTest scripts afterward. Issue 1: Need to add JBoss deployment descriptor in the configuration path of each EJB we are deploying. Issue 2: JBoss can not handle the root Context for all the EJBs starting with same name (e.g. http://localhost:8080/NhinConnect/ ). JBoss expects a unique root context (e.g. the EJB component name by itself) where the endpoint can be resolved as http://localhost:8080/MyServiceEJB/MyService 42

43. Application Server Independence Using JBoss Deployment issues (cont’d) –Issue 3: the internalConnectionInfo.xml file should be modified based on Issue 2. –Issue 4 (to be addressed in the future): All of the Nhinc*EJBs use a non-standard SOAP Binding annotation. We need to modify them from @BindingType(value = "http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/") to @BindingType(value="javax.xml.ws.soap.SOAPBinding.SOAP12HTT P_BINDING") or to a more standard annotation. 43

44. Improvements to Continuous Integration Process Srikanth Vadlamani and Mark Goldman 44

45. List of Release Artifacts Release artifacts CONNECT Binaries: Solaris and Windows distro CONNECT Database Scripts CONNECT Interfaces CONNECT Configuration files CONNECT SoapUI tests * All artifacts are available for download from CONNECT Portal or download mirror sites. 45

46. Continuous Integration Continuous Integration process –Dev Build triggered for each new code check-in to Subversion -compiles, unit tests and performs static code analysis. –Release Build triggered multiple times per day - compiles, unit tests, performs static code analysis, packages and publishes Release artifacts on Build server dashboard. –Deploy Build triggers upon successful Release Build - deploys Release artifacts. –Test Build triggers upon successful Deploy Build - executes Acceptance Tests (SoapUI). Release process –On day of Release same bundles are published on CONNECT Portal. –Additional manual tests performed during Release cycle. 46

47. Major Changes in 2.3 Solaris automated build as part of CONNECT CI process –Compiles, unit test, packages and deploys build artifacts for each Subversion check-in. Release 2.3 Subversion branch is available to the community - https://svn.connectopensource.org:8443/svn/Nhin_Public/2.3 https://svn.connectopensource.org:8443/svn/Nhin_Public/2.3 Information for each subversion check-in published on CONNECT forum Windows, Solaris and Linux Source code installation manuals are available on CONNECT Portal in Release 2.3 area 47

48. Automated Development Workspace Setup Internally* we use automation to setup a new workspace - developer, tester, build server. Only Windows XP and up are supported. Admin rights are required. SVN client, Java, GlassFish, NetBeans, MySQL, SoapUI, etc… are installed in predefined locations. * Environment setup executable is available for download from: https://svn.connectopensource.org:8443/svn/Nhin_Public/Current/Build/dashboard/WorkspaceSetup/N HINC-Current-WorkspaceSetup.exe https://svn.connectopensource.org:8443/svn/Nhin_Public/Current/Build/dashboard/WorkspaceSetup/N HINC-Current-WorkspaceSetup.exe 48

49. Overview of 2.4 Plans Jason Ray 49

50. Release 2.4 Highlights UDDI Client Enhancements Certificate Revocation C-HIEP XDR Push Integration MITA Medicaid Eligibility Verification Authorization Framework - Support for Additional Fields Address Memory Consumption and High Build Times Stewardship Activities (Federal Partners & Community) 50

51. Questions? Thank you for joining.