CONNECT as an Interoperability Platform - Demo

1. CONNECT as an Interoperability Platform - Demo

2. Agenda • Demonstrate CONNECT “As an Evolving Interoperability Platform” • Incremental addition of features and capabilities to the CONNECT product that furthers “Health Information Exchange” • Obtain feedback from the participants on • Various Technologies used for the prototype • Are the concepts applicable to your business use cases ? • Are the critical factors considered in the prototype ? • What kind of features/concepts are missing ? • Demo Content is not a “NHIN Specification or Standard” , It is a prototype to evaluate technology options that lower the barrier for health information exchange 2

3. Health IT Spectrum 3

4. Health IT Spectrum Interoperability (From HL7/CDA Academy) 4

5. Enabling Health Information Exchange using CONNECT – (Using existing Gateway/Adapter) Your Health Organization Other Health Organizations Locate Patients Your Existing HealthInformation System Master PatientIndex ProprietaryInterface Patient Identity Locate/RetrieveHealth Documents Health Information HealthData CustomInterface Publish/Subscribe to Data Feed Adapter CONNECT Gateway ExchangePolicies ProprietaryInterface Exchange Decision Retrieve Disclosure History Audit Logs Disclosure History Custom Interface Locate Health Systems/Services NHIN Conventions Framework for Authorization,Security, Privacy • Terminology Mapping • Document Viewers • Clinical Decision Support • Other Future Services Proprietary/Custom Interface External NHIN API Internal CONNECT API 5

6. Enabling Health Information Exchange using CONNECT – (Using existing Gateway/Adapter) • Small organizations and their business use cases are more localized in nature and typically requires light weight point to point exchanges • “Provider to Provider exchange”, • “Provider to Pharmacy” • “Provider to lab” • A CONNECT Gateway/Adapter has to be instantiated for each edge system that requires to exchange health information • This may not be feasible due to the lack of IT support and the required sophistication (Introduces a higher barrier for adoption) 6

7. Potential Instantiations that simply the end user’s IT needs and experience • Use Hosted services from organizations that have the required IT knowledge and support that can provide • Easy to use user interfaces • Lowers the barrier for health information exchange Health Service Provider (HIE/HIO/RHIO/HSP/Hospitals) Health Service Provider (HIE/HIO/RHIO/HSP/Hospitals) Provider Pharmacy Lab Provider Pharmacy Lab 7

8. Demo Use Case Flow(Enabling Health Information Exchange between Provider A and Provider B) • Provider A and Provider B get new account from their Health Service Provider by signing up for a service • Generic Trust verification requirements will be performed by the HSP • (Similar to creating an account for Cable Service) • Provider uses the HSP application to login to the HSP server. • Similar to switching on the cable box • For Eg. Provider A logs into their application. • Provider A comes to know that he needs the services Provider B • Provider A requests permission from Provider B to use his services • Similar to Movie on Demand • Provider B grants permission • This allows for the second level of trust whereby the parties can agree on sharing information or decline. • This is similar to negotiating the price and content • Provider A sends information to Provider B requesting services via the HSP application. • Provider A and Provider B start creating electronic documents for the patient via the information exchange if it did not exist. 8

9. Transport Technologies used for the Prototype XMPP Protocol • Provides end to end security of the channel • Provides ability to discover organizations and entities and people (Presence Detection) • Ability to provide multiple Inboxes for a single entity and prioritize the receiving mailbox • Provides ability to exchange any type of data (structured, non-structured, images etc) • Works like an Email and allows “Federation” between Health Service Providers • Providers registered with different HSP’s can still exchange data • Integrates with existing LDAP Directories • No need to recreate any existing accounts • Provides audit trail of all information exchanges • Protocol built for XMPP Transport • Provides pathway to future applications like VOIP / Video Conferencing / Whiteboard sessions / Collaboration applications. 9

10. Client Technologies used for the Prototype Universal Client Framework (Eclipse RCP – SWT and JFACE) • Provides the basic widgets and libraries that allow any software vendor or developer to develop applications. • Standard Library features that are being considered for addition: • Contact Management • Inbox Management • Messaging feature for both XMPP and the existing Gateway/Adapter • Minimum CCD for information exchange • Structured Templates such as CCD/C32/C78 etc. • Standard User Interface Controls that need to be added for user interaction • ?? • ?? • Standard Repository that will be added to the framework 10

11. Infrastructure and Service Views of the Prototype OpenLDAP 389,636 Apache Server 80, 443 XMPP Openfire Server 5222, 5223 MySQL DB Windows Cloud Instance User Registration Web Services In band File and Message Transfers Provider A Health Application Provider B Health Application Out of Band File Transfers 11

12. Technologies behind the Prototype - Client Universal Client Framework • Provides the basic widgets and libraries that allow any software vendor or developer to develop applications. • Standard Library features that are being considered for addition: • Contact Management • Inbox Management • Messaging feature for both XMPP and the existing Gateway/Adapter • Minimum CCD for information exchange • Structured Templates such as CCD/C32/C78 etc. • Standard User Interface Controls that need to be added for user interaction • ?? • ?? • Standard Repository that will be added to the framework 12