CONNECT as an Interoperability Platform - Demo. Agenda Demonstrate CONNECT “As an Evolving...

12
CONNECT as an Interoperability Platform - Demo

Transcript of CONNECT as an Interoperability Platform - Demo. Agenda Demonstrate CONNECT “As an Evolving...

CONNECT as an Interoperability Platform - Demo

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

Health IT Spectrum

3

Health IT Spectrum Interoperability (From HL7/CDA Academy)

4

Enabling Health Information Exchange using CONNECT – (Using existing Gateway/Adapter)

Ada

pter

Your Health Organization

Future Services

• Terminology Mapping• Document Viewers• Clinical Decision Support• Other

Patient Identity

HealthData

Exchange Decision

Disclosure History

NHIN ConventionsFramework for Authorization,

Security, Privacy

Locate/RetrieveHealth Documents

Publish/Subscribeto Data Feed

Your Existing Health

Information System

Health Information

Health Information

Audit LogsAudit Logs

ExchangePolicies

ExchangePolicies

Master PatientIndex

Master PatientIndex

ProprietaryInterface

CustomInterface

ProprietaryInterface

CustomInterfaceC

ON

NE

CT

Gat

eway

Locate Patients

Locate HealthSystems/Services

Other Health

Organizations Retrieve Disclosure

History

Proprietary/Custom InterfaceExternal NHIN API Internal CONNECT API

5

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

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)

ProviderProvider PharmacyPharmacy LabLab

Health Service

Provider(HIE/HIO/RHIO/HSP/Hospitals)

Health Service

Provider(HIE/HIO/RHIO/HSP/Hospitals)

ProviderProvider PharmacyPharmacy LabLab

7

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

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

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

Infrastructure and Service Views of the Prototype

Windows Cloud Instance

XMPP

Openfire

Server

MySQL

DB

OpenLDAP389,636

5222,

5223

Apache

Server

80, 443User

Registration

Provider A

Health ApplicationProvider B

Health Application

In band File and

Message Transfers

Out of Band File Transfers

Web Services

11

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