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)
Your Health Organization
Locate Patients
Other Health
Organizations
Retrieve
Disclosure
History
Locate Health
Systems/Servic
es
Health
Data
Exchange
Decision
Disclosure
History
NHIN Conventions
Framework for Authorization,
Security, Privacy
External NHIN API
5
Proprietary
Interface
Patient
Identity
Internal CONNECT API
Future
Services
Adapter
Publish/Subscribe
to Data Feed
CONNECT Gateway
Locate/Retrieve
Health Documents
Your Existing
Health
Information System
Custom
Interface
Proprietary
Interface
Custom
Interface
•
•
•
•
Master
Patient
Index
Health
Information
Exchange
Policies
Audit Logs
Terminology Mapping
Document Viewers
Clinical Decision Support
Other
Proprietary/Custom Interface
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
Health
Service
Provider
(HIE/HIO/RHIO/HSP/Hospitals)
Provider
Pharmacy
Lab
Health
Service
Provider
(HIE/HIO/RHIO/HSP/Hospitals)
Provider
Pharmacy
Lab
• 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
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
User
Registration
Web Services
80, 443
Apache
Server
XMPP
Openfire
5222, Server
5223
389,636
OpenLDAP
MySQL
DB
In band File and
Message Transfers
Provider A
Health Application
Out of Band File Transfers
11
Provider B
Health Application
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