Transcript CONNECT 2.3 Release

CONNECT:
Release 2.4 Webinar
March 25th, 2010
CONNECT Architecture Overview
Les Westberg
2
CONNECT Architecture
Message from NHIN
3
CONNECT Architecture
Message to NHIN
4
CONNECT Development Environment
Version 2.1
5
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
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 the
UDDI 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
18
•
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+Valida
tion+Using+Certificate+Revocation+Lists
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
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.
29
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 loaded
into 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 Messaging
Using Two Services
39
Research Posted to CONNECT Site
http://developer.connectopensource.org/display/CONNECTWIKI/A
synchronous+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/NHINR
24/Release+2.4+Home
43
Questions?
Thank you for joining.
Survey – Please let us know
http://www.surveymonkey.com/s/LTLLVF3
45