connect: release 2.3 webinar january 19, 2010. connect architecture overview les westberg 2

CONNECT:Release 2.3 Webinar

January 19, 2010

CONNECT Architecture Overview

Les Westberg

2

CONNECT ArchitectureMessage from NHIN

3

PatientDiscovery

MPI Query forDocuments

RetrieveDocuments

Policy SubscriptionManagement

NotificationProcessing

AuditReporting

Patient Discovery

Query forDocuments

RetrieveDocuments

UDDI UpdateManagement

SubscriptionManagement


AuditReporting

NHINNHINCONNECT Components

Customizable Components

Replaceable Components

CONNECT AdapterCONNECT Adapter

Do

cum

ent

Rep

osito

ryD

ocu

men

t R

epo

sitory

SDK ServicesSDK Services

Data Transforms

Data Transforms

Terminology Services


OthersOthersOthersOthers

Do

cum

ent

Reg

istryD

ocu

men

t R

egistry

MP

IM

PI

Po

licyE

ng

ine

Po

licyE

ng

ine

Su

bscrip

tion

R

epo

sitory

Su

bscrip

tion

R

epo

sitory

Re-

Iden

tification

Re-

Iden

tification

Adapter Service Bus

CONNECT GatewayCONNECT Gateway

NHIN Orchestration ComponentsNHIN Orchestration Components

CONNECT Core ComponentsCONNECT Core Components

Patient DiscoveryPatient

DiscoveryQuery for

DocumentsQuery for

DocumentsRetrieve

DocumentsRetrieve

DocumentsSubscription ManagementSubscription Management

Notification Processing


AuditReporting

AuditReporting

UDDI Update ManagementUDDI Update Management

Patient Correlation Repository


Audit Repository

Audit Repository

Document Cache

Document Cache

Connection Manager

Connection Manager

Subscription Repository



CONNECT ArchitectureMessage to NHIN

4

CONNECT AdapterCONNECT Adapter

Entity Integration SoftwareEntity Integration Software

CONNECT GatewayCONNECT Gateway

Message Proxy ComponentsMessage Proxy Components

CONNECT Core ComponentsCONNECT Core Components


DiscoveryQuery for

DocumentsQuery for

DocumentsRetrieve

DocumentsRetrieve




AuditReporting

AuditReporting



Audit Repository

Audit Repository

Document Cache

Document Cache



UDDI Update ManagementUDDI Update Management


SDK ServicesSDK Services

Data Transforms

Data Transforms




PatientDiscovery

Query forDocuments

RetrieveDocuments

SubscriptionManagement


AuditReporting

CONNECT Components

Customizable Components

Replaceable Components

Entity Orchestration ComponentsEntity Orchestration Components


DiscoveryQuery for

DocumentsQuery for

DocumentsRetrieve

DocumentsRetrieve




AuditReporting

AuditReporting

Connection Manager

Connection Manager

NHINNHIN

PatientCorrelation

PatientDiscovery

Query forDocuments

RetrieveDocuments


AuditReporting


PassThrough

Orchestrated vs. Pass Through Mode

5

Adapter InterfacePass-Through

Adapter InterfacePass-Through

NHIN Message Receiver

NHIN Message Receiver

CHOICE OF PATH BASED ON CONFIGURATION

Internal NHIN Message Orchestrator

Internal NHIN Message Orchestrator

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


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


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.3New NHIN Attributes

New Attribute Statement Attributes

• Home Community ID Attribute

– Provides the Home Communityinitiating 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 therequesting organization

– OID for the assigning authority and the identifier of the patient within thatassigning 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

Focus of Modifications in Release 2.3Attribute 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.3Attribute 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


Document Query / Retrieve

Neil Webb

20

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

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


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:

• 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


Patient Discovery

Jon Hoppesch

28

Subject Discovery vs.Patient Discovery

29

Feature Subject Discovery Patient Discovery

MatchingMatching done by patient name and a small subset of demographics

Matching done by a larger set of demographics

Communication Announce/Revoke/Ack Query/Results

MessagesUsed HL7 201301, 201302, and 201303 messages

Uses HL7 201305 and 201306 messages

CorrelationsCorrelations 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 ModeThis 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 ModeThe 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

act Outbound - Send XCPD requestA

gen

cy/E

nti

ty I/

F

Res

po

nd

ing

Gat

ewa

yIn

itiati

ng

Gat

ewa

y

ActivityInitial

Initiate XCPDrequest message

Receive XCPDrequest

Invoke Audit log Create XCPDrequest message

Receive XCPD request

Send XCPDrequest

Receive singleunambiguous request

Invoke audit log forresponse msg

Deter mineRespondingMode

Query MPI

Matchfound?

Patient IDavailable?

Establish PatientCorrelation

If singlematchfound?

If multiplematchfound?

Receive specialerror code

A

Receive XCPDresponse message

AInvoke audit log

Send to Agency

Receive emptymessage

Activity Final

Invoke PolicyEngine

Policy Enginecheck pass?

Invoke PolicyEngine

Policy Enginecheck pass?

Match patientdemographics

Receive emptymessage

ActivityFinal

It either goes to the next target community OR if there are no more target communities then the message stops at NHIN I/F.

Invoke Audit logto log XCPD

request

Yes

Pass-through ModeTrust Mode

No

Yes

No

No match

Yes

VerifyMode

Demographicsand/or Patient ID

Demographics

Yes - Patient ID andDemographics

Fail

Pas s

Pas s

No

Fails

Patient Discovery – Outbound Request Flow Diagram

33

act Inbound - Receiv e XCPD messa...

Req

uesti

ng g

atew

ayR

espo

ndin

g ga

tew

ay

Receive XCPDrequest

Invoke audit logServiceenabled?

Send requestmessage

Pass-throughmode

Query MPI

Singlematchfound?

Patient idavailable inrequestmessage?

Send empty msg

Receive responsemessage

Establish PatientCorrelation

AdapterI/F

InvokePolicyEngine ?

ActivityInitial

Send demographics andpatient id

InvokePolicyEngine ?

No

Yes

Yes

No

Empty message

Demographics

No

Yes

No

Yes

NoNo

Demographics and patient id

Yes

Yes

The flow diagram depicts CONNECT responding to a patient discovery request message from NHIN (remote gateway)

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.

• NSS was FIPS 140-2 Level 2 certified.

36

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=truewhere %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_FIPS_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 fromftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.6.4/

• http://www.connectopensource.org/download/attachments/23691564/CONNECT_Release_2_3_FIPS_010510.pdf

39

Migration Towards App Server – Platform Independence using JBoss

Sai Valluripalli

40

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

41


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/<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

42


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.SOAP12HTTP_BINDING")

or to a more standard annotation.

43

Improvements to Continuous Integration Process

Srikanth Vadlamaniand 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/NHINC-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.

connect: release 2.3 webinar january 19, 2010. connect architecture overview les westberg 2

Documents

nhin audit query wsdl

updated nhin specs

nhin specific attributes

audit query wsdlthe

grained policy document

event support

audit querynhin specification

audit queryincorrect