CONNECT:Release 2.4 Webinar

March 25th, 2010

CONNECT Architecture Overview

Les Westberg

2

CONNECT ArchitectureMessage from NHIN

3

CONNECT ArchitectureMessage to NHIN

4

CONNECT Development Environment

Version 2.1

Item Version

Java JRE/JDK 1.6 Update 16 (32-bit version)

GlassFish 2.1

NetBeans 6.7.1

Metro 1.5

MySQL 5.1.41

SoapUI 3.0.1

5

Major Changes in 2.4

• Support of the Updated NHIN Specs:

– Document Submission

– UDDI• Also added as part of release 2.3.1

– Certificate Revocation List (CRL)• Also added as part of release 2.3.1

• Performance and Build Time Improvements

• Progress toward IDE Neutral Build Scripts

• Dynamic Document Assembly Components

• SoapUI Updates

• Asynchronous Messaging Research

6

Support of the Updated NHIN Specifications

Document Submission

Kieran Dunne

7

Document Submission

NHIN Specification:• Document Submission V 1.1.0 Dated: 10/26/2009

Underlying Specifications:• HITSP/T31 Document Reliable Interchange Transaction Version 1.3

July 8, 2009

• IHE ITI TF Supplement XDR TI 2009-8-10

• IHE ITI TF Revision 6.0 Vol. 2b, 2x, 3 2009-8-10

Emerging Specification:• Document Submission Specification has not been finalized.

8

Document Submission

Purpose of the Document Submission Framework

• Provide the ability to “push” data for a given patient from one NHIE to another via configuration on the submission side.

• This is a different model of exchange than subscription because the sender decides who the data should go to and the receiver receives data on an appropriate available endpoint from the sources it authorizes

Intended Usage

• Document Submission is viable where XDS Registry/Repositories are not yet implemented or available for the exchange of information.

• Intended only for exchange of patient related medical documents and not intended to address all cross‐enterprise EHR communication needs

9

Document Submission

Profile Highlights

• Receiver does not need to know about the sender

• Differs from the Publish/Subscribe model currently in place.

• Sender controls who receives the data.

• Built on XDS.b specification

• Uses the same ProvideAndRegisterDocumentSet-b message

• Routing Ability

• Intended Recipient Field

• Spring Framework Adapters

Reference

http://developer.connectopensource.org/display/CONNECTWIKI/XDR+Service

10

Document Submission

Asynchronous Support

• Document Submission needed an Asynchronous Solution

• Interim solution put in place in patch 2.4.1

• Two one-way messages.

– Request from Sender to Receiver

– Response from Receiver to Sender

• General Asynchronous solution will be available in Release 3.0

11

Support of the Updated NHIN Specifications

UDDI (Service Registry)

Jon Hoppesch

12

Service Registry

NHIN Specification:

• Services Registry V 1.4 Dated: 11/03/2009

• This is not a service specification, but rather a client

specification

Underlying Specifications:

• OASIS specification for Universal Description and Discovery

Interface (UDDI) registry version 3.0.2

13

Service Registry

Previous Service Registry Support:

• Previous releases CONNECT did provide UDDI support

• Was more of a proof of concept

• UDDI was not stood up by the NHIN

• Communications were through an unsecure interface

• UDDI Polling mechanism to periodically get updates from the UDDI and cache them locally

• Internal Connection file available to provide overrides to theUDDI endpoints

Latter two bullets are still in place for the R2.4 implementation

14

Service Registry

R2.4 Service Registry Summary:

UDDI tModel changes from previous versions Changes were made to the underlying structure of the records in the UDDI

Standard names defined for Patient Discovery, Document Query, and Document Retrieve

UDDI Secure Communications Communications with the UDDI are now secured via 2-way SSL

Entrust certificates issued from the NHIN Certificate Authority are required for communication with the UDDI

The Query By State feature Enables NHIEs to easily communicate with NHIEs in a particular state or set of states.

Initiated on the initial message sent to the Entity Interface for a NHIN Service.

Support for this feature was also added to the internal CONNECT Connection management feature.

Currently supported for Patient Discovery, Document Query, Audit Query, and HIEM subscribe

Not using UDDI feature to query by state, but rather filtering internal cache

15

Service Registry

R2.4 Service Registry Summary:• Flag added to disable UDDI functionality

• UDDI subscribe/notify The original thought was that the Subscribe/Notify mechanism in the UDDI would be

event driven. If an entry was change notification would occur immediately.

Instead this feature ended up being is time-driven. When you subscribe you specify how often you want to be notified of changes.

Previous functionality pulled data from the UDDI based on a timer.

Implementing this feature we would essentially just have changed this to a push model.

Based on this information this capability was not built into the CONNECT Gateway at this time

http://developer.connectopensource.org/display/CONNECTWIKI/Service+Registry+%28v2.3%29

16

CRL (Certificate Revocation Lists)

Sai Valluripalli

17

Certificate Revocation List

• Certificate Revocation Lists (CRLs) are lists of certificates that are no longer valid or that have been revoked by a CA (Certificate Authority).

• Each NHIN initiating and responding gateway MUST implement either Online Certificate Status Protocol (OCSP) based x.509 certificate revocation checking or use CRLs against an NHIN-governed CA to determine the revocation status of each certificate as per NHIN policy.

• Various reasons to revoke a certificate are Unspecified, Key compromise, CA Compromise, Affiliation Changed, Superseded Privileges withdrawn etc.,

• We have to configure Glassfish application server to achieve dynamic CRL functionality. The details of configuring JVM OPTIONS can be found in our documentation at: http://developer.connectopensource.org/display/NHINR24/Certificate+Validation+Using+Certificate+Revocation+Lists

18

Performance & Build Time Improvements

Neil Webb

19

Performance & Build Time Improvements

Overview• EJB web services now hosted as POJO web services in web applications

• Consolidated 58 EJB projects into 6 web applications

• Many library projects consolidated

Goals• Reduce memory footprint

• Increase performance

• Increase portability

• Reduce build times

• Reduce complexity

Results• http://developer.connectopensource.org/display/CONNECTWIKI/

Memory+Performance+Implementation

20

Performance & Build Time Improvements

Heap memory consumption

• Average before: 1,283 KB

• Average after: 404 KB

• 68% Reduction in heap memory consumed

• Results obtained running InternalSelfTest

21

Performance & Build Time Improvements

Performance Improvements

• 81% reduction in processing time in InternalSelfTest

• Processing times in MS

• Most savings likely due to significant decrease in garbage collection

22

Performance & Build Time Improvements

Build Time Improvements• Previous CI build time for full clean build was 1 hour 30 minutes

• Custom modification to WSImport reduced full clean build to 45 minutes

• Project consolidation reduced full clean build to 26 minutes. 71% reduction in time to perform a full clean build

• Normal CI “dirty” build reduced to 11 minutes

• Developer build reduced to under 6 minutes

Project Creation Guidelines• http://developer.connectopensource.org/display/CONNECTWIKI/

Project+Creation+Guidelines

• New projects created only if absolutely necessary. Follow guidelines in the link above.

23

Progress towards IDE Neutral Build Scripts

Srikanth Vadlamani

24

IDE Neutral Build Scripts

• Patch Release 2.4.1 - will contain both IDE Neutral build scripts and old build scripts.

• Release 2.4 - Initial version of these scripts are added (sprint #50).

• Release 3.0 - old build scripts will be replaced with new build scripts.

• CONNECT CI build Servers (Windows and Solaris) have been switched to use new build scripts.

• Targets executed are

• Heavy build : ant -f build_new.xml just.clean just.source.compile just.unittest.run

• Deploy on GF : ant -f build_new.xml just.package.create deploy

• SOAP UI Test : ant -f "SoapUI Test\RegressionSuite\build_new.xml" soapui.run

• Dependency management is done using IVY.

• Build timings

• As ivy-cache is build first time on local desktop, Initial build time will be longer.

http://www.connectopensource.org/developer-resources/forums#nabble-td4758335%7Ca4758335

25

Dynamic Document Assembly Components

Martha Flynn

26

Dynamic Document Generation

• Contribution from TATRC/NGC based on their development effort to

support DoD/VLER Phase 1a.

• Developed against CONNECT R2.1.

– This is an EJB implementation which has yet to be converted to POJO.

• Replacement of the reference version of DocumentRespositoryEJB provided

with CONNECT.

• Templates used for dynamic document generation to support Patient

Information, Medications, Problems and Allergies sections of CDA document.

• Database tables allow the user to configure which sections are included in a

generated document.

– AHLTA interface is stubbed out using XML files

27

SoapUI Updates

Scott Borst

28

29

Property File

• The property file is now renamed to have the same name as the soapUI project itself and should be placed in the same directory where the soapUI project file resides.

• The property file is now loaded at the project level instead of being loaded within every test case.

• The Load Script includes Groovy code to load the property file at the project level, when the project is loaded into soapUI.

• The project level properties as well as the test case level properties are now embedded directly in the request XML itself via property expansion, eliminating the need of a Property Transfer step.

• The Load Script also includes Groovy code to add dynamic properties to the property list that are created during the test case for just that test case run.

SQL and GetDates Steps

SQL steps:• The Load Script includes a Groovy method to access the database at the

project level, when the project is loaded into soapUI.

• All the SQL steps within each test case are now simplified to use the new withSql method in the Load Script.

GetDates steps:• The Load Script includes a test case listener to set the StartDate, EndDate,

SigDate and ExpireDate at the project level, when the project is loadedinto soapUI.

• This eliminated the step to set dates within a particular test case.

30

With all of the above changes…

• The self-tests are now portable and can be executed from any folder as long as the project and properties file are in the same folder.

• The self tests are platform independent, the same test can be run on Windows and Solaris.

Useful tips:When running the soapUI GUI, when

a change is made to a properties file, the change is not reflected within the soapUI project until the Load Script at the project level runs again. To run the script, double click on the Project name in soapUI and go the Load Script tab on the right panel and click on the Green arrow.

31

CONNECT Asynchronous Support

Les Westberg

32

WS-Addressing

• Transport-neutral mechanisms to address web services and messages

• Fields– MessageId: Unique ID for the message

– ReplyTo: URL to send response to

– RelatesTo: Message ID for which the message is a response

• ReplyTo field implication– Response on same HTTP connection

• http://www.w3.org/2005/08/addressing/anonymous

– Response on separate HTTP connection

• URL for web service that will catch the response

33

Messaging Forms

Synchronous (supported)

API Async – Single HTTP connection (supported)

Async Messaging – Multiple HTTP connections (research)

34

Asynchronous Messaging Research

• Needs to handle extreme latent response

– Could be as large as one week

– May have manual processes before response can be sent

• Engineering Analysis

– Web Service Stack Support for WS-Addressing

• Metro

• Axis2

• CXF

– Security implications

• 2-way SSL

• SAML

• Digital signatures

– Handling of extreme latent responses

35

Research – General Information

• Web service stacks were very similar

– Code generation

– Web service handling

• Process

– Create WSDL

– Generate service shell from WSDL

– Implement custom code into generated shell

– Deploy to application server

• Research Points

– Main effort focused on Metro

– Analysis of other stacks – only took them to the point where it appeared that they would behave in a similar fashion to Metro (Time and resources did not allow for further analysis)

36

Synchronous Messaging (All stacks)

37

Asynchronous Messaging – Managed by Web Service Stack

38

Asynchronous MessagingUsing Two Services

39

Research Posted to CONNECT Site

http://developer.connectopensource.org/display/CONNECTWIKI/Asynchronous+Messaging

40

Overview of 3.0 Plans

Les Westberg

41

CONNECT 3.0

• Gateway of Gateways

• ESMD Profile (Electronic Submission of Medical Documentation)

• Soap 1.2 upgrade on internal interfaces

• Universal client framework enhancements

• CONNECT Direct

– XMPP protocol framework

• Policy and redaction engine enhancements

• Asynchronous messaging

– Document Submission (interim implementation)

– Patient discovery

42

CONNECT Release 2.4

Release 2.4 is currently available for download

http://developer.connectopensource.org/display/NHINR24/Release+2.4+Home

43

Questions?

Thank you for joining.

Survey – Please let us know

http://www.surveymonkey.com/s/LTLLVF3

45