1
Technical Overview of the Common FrameworkHIT Symposium at MIT
J. Marc Overhage, MD, PhDRegenstrief Institute
Indiana University School of MedicineIndiana Health Information Exchange
2
Common FrameworkConnecting for Health principles
– Builds on existing systems (“incremental”) and creates early value for doctors and patients
– Designed to safeguard privacy – imposed the requirements and then designed the solution
– Consists of an interoperable, open standards-based “network of networks” built on the Internet
– Leverages both “bottom-up” and “top-down” strategies
Engaging the American Public
Engaging the American Public
Designing forPrivacy & Security
Designing forPrivacy & Security
The Infrastructure—technical architecture
& approach
The Infrastructure—technical architecture
& approach
Accurate Linkingof Patient
Information
Accurate Linkingof Patient
Information
DataStandards
DataStandards
Clinical Applications
Clinical Applications
Funding & IncentivesFunding & Incentives
Legal Safe Harbors
Legal Safe Harbors
1.1.
2.2.
3.3.
4.4.
5.5.
6.6.
7.7.
8.8.
3
Architecture is Federated and Decentralized: Once records are located, the health information flows peer-to-peer – with
patient’s authorization
4
The architecture supports point of care information sharing and population-based
reporting
5
The Connecting for Health Model for Health Information Sharing
• Sharing occurs via a network of networks (National Health Information Network) — not a completely new architecture
• The nationwide “network” is made up of smaller community networks or SNOs (Sub Network Organizations)
• Each SNO has an RLS (Record Locator Service) to locate patient records
• SNOs are interconnected through ISBs (Inter-SNO Bridges)
6
NHIN: Network of Networks• National Health Information Network, not National
Health Information Database• Bad Tradeoff: 1000x Searches for 0.1 to 0.01
increase• No “Top Level” Query
–Privacy–Security–Patient Trust–Source of Truth–Data Cleanliness
• Queries Must Be Targeted/No Fishing• Built On Lines of Actual Human Trust
7
What is a SNO?• A group of entities (regional or non-regional)
that agree to share information with each other• Implements the Common Framework• Provides an ISB for all external traffic• Runs an RLS internally
8
What is a Record Locator Service (RLS)?
• Like a phone book listing locations of information
• Contains no clinical information
• Only authorized participants can access it
• Obtaining the actual clinical record is a separate transaction not involving RLS
RLSRLS
Care Delivery Organization 2Care Delivery Organization 2
Care Delivery Organization 1Care Delivery Organization 1
Public Health Organization
Public Health Organization
Payer or Other Organization
Payer or Other Organization
SNO (Secure Reliable
Internet)
9
RLSRLSISBISB
SNO 1
RLSRLS
ISBISB
SNO 3NHIN
ISBISBRLSRLS
SNO 2
What is a Inter-SNO Bridge (ISB)?
• Software that provides the interfaces that define a SNO
• Provides essential services
10
How Multiple SNOs Connect to Form NHIN• A SNO queries other SNOs when it knows:
–An institution where the patient received care–A region where the patient received care
• Same query formatted for all remote SNOs• Only need location of
ISBs
11
Three Standard Interfaces Required• Publish local record locations to RLS (Pink)• Query institution+MRN from RLS (Orange)• Retrieve clinical data directly from sources (Green)
Healthcare Practitioner Clinical Data
Source
Patient Index[RLS]1. Request
Record Locationsfor Patient
2. Return Index tolocation of patient records
0. Publish Index tolocation of patientmedical records
3. Request Patient Medical Records
4. Provide Patient Medical Records
12
Location: NamespacesProblem of Global Uniqueness
Globally Unique Institutions IDs +Locally Unique Record Numbers =Globally Unique Record IDs
Examples: [email protected]/help.htmlGeneralHospital/MRN:457398457
13
Disambiguation:Probabilistic Match on Demographics• Assume No National Health ID• Use Only Demographics / No Clinical Data• Use common set of patient demographics
– Name/DOB/Gender/Zip/SSN/etc• Pluggable Matching Algorithm• Optimized To Minimize False Positives
14
15
Patient Match• Incoming PID Fields Matched Against DB• Algorithm Tuned to Local Conditions• False Positives Tuned to < 1 in 100,000
16
17
Underlying Technologies
• TCP/IP• SOAP• Web Services• HL7/NCPDP messaging standards• LOINC codes• NDC codes
18
Security / Confidentiality
• Server-to-server (ISB-to-ISB) authentication via X.509 certificates
• Communication protected by SSL/TLS • Federated identity based on single
token authentication in edge systems• Role based/level based access control
19
What did we learn from the prototype work?
20
Authentication
21
Patient demographic entry
22
Query options
23
Viewer results display
24
Viewer results display -- more
25
Mixed Open SourceMicrosoft .NETJ2EEDevelopment preference
Browsersoft(small commercial)
CSC (large commercial)
Regenstrief (academic not-for-profit)
Technology partner
Brokered through mirrored data at central HRE
Federated, with shared Record Locator Service
Central data repository with standardized data
Overall architecture
“Bi-lingual”(HL7 2.x and 3.0)
Implementing HL7 3.0; investigating XDS
Significant investment in HL7 2.xStandards
7 years25+ years35+ yearsRHIO-related history
Rural and underserved community medicine and
health centers
Urban mix of academic, community and
commercial influences
Mixed urban and rural; dominant academic
anchor (IU)Market
Mendocino HREMA-SHAREIHIE
Prototype SNOs reflect the realities of existing market and health IT variation
26
Prototype Approaches
Indiana • Developed Disburser / Aggregator for ISB • Adapted existing MPI for RLS• Source systems send data to hosted HL7
Update Services for transformation and hosting in standard form Community-
level registries
HL7 Update
ServicesMPI / RLS Service
Clinical Data
Auth / Access Control Service (AACS)
Record Exchange Service (RES)
Registries, Audit, etc.
Mirrored Clinical Data
Mendocino• Developed RLS
and ISB• Source systems
send data to HRE for hostingin native form with on demand transformation
= New “NHIN” functionality
IHIE / INPC (at Regenstrief)
gg
Supported by Browsersoft, Inc. (OpenHRE)
RLS InterSNOBridge
Hosted by CSC
CDX Gateway (serving as InterSNO Bridge)
RLSINPC Disburser / Aggregator (serving as InterSNO Bridge)
IN Cancer Registry
St. Francis St. Vincent Wishard
IU Medical Group
Community HospitalsClarian
Indiana Medicaid
Indiana DPH
Beth Israel Deaconess
Boston Medical Ctr.
AEGIS(public health)
Massachusetts• Adapted its CDX Gateway as
front-end to the RLS and ISB• Distributed CDX Gateways
fetch source data on demand from participant sites
UVPMCG Ukiah Valley Medical Ctr.
Consolidated Tribal Health
27
What Common Framework technical resources are available?
28
Types of Technical Resources
Background Information• On the Technical Architecture and Design Overall (T1) • On Data Quality (T5)• On the RLS (from the MA prototype site) (T6)
Implementation Guides• NHIN Message Implementation Guide including Record Locator Service/Inter-SNO
Bridge (T2)• Standards Guides
– Medication History: Adapted NCPDP SCRIPT (T3)– Laboratory Results: ELINCS 2.0, with modifications (T4)
Example Code/Interfaces• Test Interfaces: CA, IN, MA www.connectingforhealth.org (under T2) • Code base: CA, IN, MA www.connectingforhealth.org (under T2)
29