1. CONNECT: Release 2.4 Webinar March 25th, 2010

2. CONNECT Architecture Overview Les Westberg 2

3. CONNECT Architecture Message from NHIN 3

4. CONNECT Architecture Message to NHIN 4

5. CONNECT Development Environment Version 2.1 ItemVersion Java JRE/JDK1.6 Update 16 (32-bit version) GlassFish2.1 NetBeans6.7.1 Metro1.5 MySQL5.1.41 SoapUI3.0.1 5

6. 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

7. Support of the Updated NHIN Specifications Document Submission Kieran Dunne 7

8. 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

9. 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

10. 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

11. 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

12. Support of the Updated NHIN Specifications UDDI (Service Registry) Jon Hoppesch 12

13. 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

14. 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

15. 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

16. 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

17. CRL (Certificate Revocation Lists) Sai Valluripalli 17

18. 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+Valida tion+Using+Certificate+Revocation+Lists http://developer.connectopensource.org/display/NHINR24/Certificate+Valida tion+Using+Certificate+Revocation+Lists 18

19. Performance & Build Time Improvements Neil Webb 19

20. 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

21. 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

22. 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

23. 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+Guidelineshttp://developer.connectopensource.org/display/CONNECTWIKI/Project +Creation+Guidelines New projects created only if absolutely necessary. Follow guidelines in the link above. 23

24. Progress towards IDE Neutral Build Scripts Srikanth Vadlamani 24

25. 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

26. Dynamic Document Assembly Components Martha Flynn 26

27. 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

28. SoapUI Updates Scott Borst 28

29. 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.

30. 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

31. 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

32. CONNECT Asynchronous Support Les Westberg 32

33. 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

34. Messaging Forms Synchronous (supported) API Async – Single HTTP connection (supported) Async Messaging – Multiple HTTP connections (research) 34

35. 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

36. 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

37. Synchronous Messaging (All stacks) 37

38. Asynchronous Messaging – Managed by Web Service Stack 38

39. Asynchronous Messaging Using Two Services 39

40. Research Posted to CONNECT Site http://developer.connectopensource.org/display/CONNECTWIKI/A synchronous+Messaging 40

41. Overview of 3.0 Plans Les Westberg 41

42. 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

43. CONNECT Release 2.4 Release 2.4 is currently available for download http://developer.connectopensource.org/display/NHINR 24/Release+2.4+Home 43

44. Questions? Thank you for joining.

45. Survey – Please let us know http://www.surveymonkey.com/s/LTLLVF3 45