1 / 45

CONNECT: Release 2.4 Webinar

CONNECT: Release 2.4 Webinar. March 25th, 2010. CONNECT Architecture Overview Les Westberg. 2. CONNECT Architecture Message from NHIN. CONNECT Architecture Message to NHIN. CONNECT Development Environment Version 2.1. Major Changes in 2.4. Support of the Updated NHIN Specs:

ghita
Download Presentation

CONNECT: Release 2.4 Webinar

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. CONNECT Architecture OverviewLes Westberg 2

  3. CONNECT ArchitectureMessage from NHIN

  4. CONNECT ArchitectureMessage to NHIN

  5. CONNECT Development Environment Version 2.1

  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

  7. Support of the Updated NHIN SpecificationsDocument SubmissionKieran Dunne

  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.

  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

  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

  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

  12. Support of the Updated NHIN SpecificationsUDDI (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

  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 theUDDI endpoints • Latter two bullets are still in place for the R2.4 implementation

  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

  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

  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+Validation+Using+Certificate+Revocation+Lists

  19. Performance & Build Time ImprovementsNeil 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

  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

  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

  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+Guidelines • New projects created only if absolutely necessary. Follow guidelines in the link above.

  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

  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

  28. SoapUI UpdatesScott 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. 29

  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 loadedinto soapUI. • This eliminated the step to set dates within a particular test case.

  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.

  32. CONNECT Asynchronous SupportLes 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

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

  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

  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)

  37. Synchronous Messaging (All stacks)

  38. Asynchronous Messaging – Managed by Web Service Stack

  39. Asynchronous MessagingUsing Two Services

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

  41. Overview of 3.0 PlansLes 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

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

  44. Questions? Thank you for joining.

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

More Related