Transcript CONNECT 2.3 Release

CONNECT:
Release 2.3 Webinar
January 19, 2010
CONNECT Architecture Overview
Les Westberg
2
CONNECT Architecture
Message from NHIN
CONNECT Components
NHIN
Customizable Components
Replaceable Components
Patient
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
UDDI Update
Management
CONNECT Gateway
NHIN Orchestration Components
Patient
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
UDDI Update
Management
CONNECT Core Components
Patient
Correlation
Repository
Audit
Repository
Patient
Discovery
Document
Cache
Query for
Documents
MPI
Connection
Manager
Retrieve
Documents
Policy
Subscription
Repository
Subscription
Management
Others
Others
Notification
Processing
CONNECT Adapter
Adapter Service Bus
ReIdentification
Subscription
Repository
Policy
Engine
MPI
Document
Registry
Document
Repository
3
SDK Services
Data
Transforms
Terminology
Services
Others
Others
Audit
Reporting
CONNECT Architecture
Message to NHIN
CONNECT Components
Customizable Components
NHIN
Patient
Discovery
Query for
Documents
Retrieve
Documents
Replaceable Components
Subscription
Management
Notification
Processing
Audit
Reporting
CONNECT Gateway
Message Proxy Components
Patient
Discovery
Query for
Documents
Retrieve
Documents
Subscription
Management
Notification
Processing
Audit
Reporting
CONNECT Core Components
Patient
Correlation
Repository
Audit
Repository
Document
Cache
Connection
Manager
Subscription
Repository
UDDI Update
Management
Others
Others
Entity Orchestration Components
Patient
Discovery
Query for
Documents
Patient
Correlation
Patient
Discovery
Retrieve
Documents
Query for
Documents
Subscription
Management
Retrieve
Documents
Notification
Processing
Notification
Processing
Audit
Reporting
Audit
Reporting
Notification
Processing
CONNECT Adapter
SDK Services
Entity Integration Software
4
Data
Transforms
Terminology
Services
Others
Others
Pass
Through
Orchestrated vs. Pass Through Mode
CHOICE OF PATH
BASED ON
CONFIGURATION
Internal NHIN Message
Orchestrator
NHIN Message
Receiver
Adapter Interface
Pass-Through
5
CONNECT Development Environment
Version 2.1
6
Item
Version
Java JRE/JDK
1.6 Update 16
GlassFish
2.1.1
NetBeans
6.7.1
Metro
1.5
MySQL
5.1.41
SoapUI
3.0.1
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
Support of the Updated NHIN Specifications
Access Consent
Les Westberg
8
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
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
Support of the Updated NHIN Specifications
Audit Query
Visu Patlolla
11
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
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/auditlogquery
• NhincAuditQueryEJB, EntityAuditLogQueryEJB, and
NhinAuditQueryProxyImpl NetBean projects updated as appropriate
13
Support of the Updated NHIN Specifications
Authorization Framework
Victoria Vickers
14
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
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
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
– Example - urn:oid:2.16.840.1.113883.3.190
• AccessConsentPolicy Attribute
• Patient Identifier Attribute
– NameFormat “http://www.hhs.gov/healthit/nhin”
– The patient as identified in the
requesting organization
– Value is the OID of the access policies that the
asserting entity has previously agreed to
– OID for the assigning authority and the
identifier of the patient within that
assigning authority
– Example - urn:oid:1.2.3.4
– Example –
543797436^^^&1.2.840.113619.6.197
&ISO
• 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
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
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
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
Support of the Updated NHIN Specifications
Document Query / Retrieve
Neil Webb
20
Asynchronous Web service calls
tested for Doc Query/Retrieve
CONNECT supports Asynchronous Web service calls.
21
•
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.
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
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
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
Support of the Updated NHIN Specifications
GIPSE Profile
Scott Borst
25
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
GIPSE Profile
The profile is currently in use by the following agencies:
27
•
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)
Support of the Updated NHIN Specifications
Patient Discovery
Jon Hoppesch
28
Subject Discovery vs.
Patient Discovery
Feature
29
Subject Discovery
Patient Discovery
Matching
Matching done by patient name
and a small subset of
demographics
Matching done by a larger set of
demographics
Communication
Announce/Revoke/Ack
Query/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
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
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
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
Patient Discovery – Outbound Request Flow Diagram
The flow diagram depicts CONNECT responding to a patient
discovery request message from NHIN (remote gateway)
act Inbound - Receiv e XCPD messa...
Adapter
I/F
Responding gateway
Receive XCPD
request
Invoke audit log
Yes
Service
enabled?
Establish Patient
Correlation
No
Yes
Yes
Demographics
Send demographics and
patient id
No
Send empty msg
Requesting gateway
Demographics and patient id
Send request
message
Receive response
message
ActivityInitial
33
Empty message
Query MPI
Patient id
available in
request
message?
No
No
Pass-through
mode
No
Invoke
Policy
Engine ?
Yes
Invoke
Policy
Engine ?
Yes
Single
match
found?
No
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
34
FIPS Compliance
Visu Patlolla
35
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.
•
Crypto++™ Library (Software Version: 5.3.0 [32-bit and 64-bit]), www.cryptopp.com
•
OpenSSL FIPS Object Module (Software Version: 1.1.1), www.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.
•
36
NSS was FIPS 140-2 Level 2 certified.
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
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 <security-service>
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
38
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/
• Download NSPR from
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.pdf
39
Migration Towards App Server –
Platform Independence using JBoss
Sai Valluripalli
40
Application Server Independence
Using JBoss
41
•
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
Application Server Independence
Using JBoss
Deployment issues
(NO CODE MODIFICATIONS REQUIRED)
42
•
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:\jboss5.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/<ServiceName>). 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
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
Improvements to Continuous
Integration Process
Srikanth Vadlamani
and Mark Goldman
44
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
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
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
• 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
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
48
Overview of 2.4 Plans
Jason Ray
49
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
Questions?
Thank you for joining.