Technical Overview of the Common FrameworkHIT Symposium at MITJ. Marc Overhage, MD, PhDRegenstrief InstituteIndiana University School of MedicineIndiana Health Information Exchange

Common FrameworkConnecting for Health principlesBuilds on existing systems (incremental) and creates early value for doctors and patientsDesigned to safeguard privacy imposed the requirements and then designed the solutionConsists of an interoperable, open standards-based network of networks built on the Internet Leverages both bottom-up and top-down strategies

Architecture is Federated and Decentralized: Once records are located, the health information flows peer-to-peer with patients authorization

The architecture supports point of care information sharing and population-based reporting

The Connecting for Health Model for Health Information SharingSharing occurs via a network of networks (National Health Information Network) not a completely new architectureThe 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 recordsSNOs are interconnected through ISBs (Inter-SNO Bridges)

NHIN: Network of NetworksNational Health Information Network, not National Health Information DatabaseBad Tradeoff: 1000x Searches for 0.1 to 0.01 increaseNo Top Level QueryPrivacySecurityPatient TrustSource of TruthData CleanlinessQueries Must Be Targeted/No FishingBuilt On Lines of Actual Human Trust

What is a SNO?A group of entities (regional or non-regional) that agree to share information with each otherImplements the Common FrameworkProvides an ISB for all external trafficRuns an RLS internally

What is a Record Locator Service (RLS)?Like a phone book listing locations of informationContains no clinical informationOnly authorized participants can access it Obtaining the actual clinical record is a separate transaction not involving RLS

What is a Inter-SNO Bridge (ISB)?Software that provides the interfaces that define a SNOProvides essential services

How Multiple SNOs Connect to Form NHINA SNO queries other SNOs when it knows:An institution where the patient received careA region where the patient received careSame query formatted for all remote SNOsOnly need location of ISBs

Three Standard Interfaces RequiredPublish local record locations to RLS (Pink)Query institution+MRN from RLS (Orange)Retrieve clinical data directly from sources (Green)

Location: NamespacesProblem of Global UniquenessGlobally Unique Institutions IDs +Locally Unique Record Numbers =Globally Unique Record IDsExamples: John.Smith@IBM.comHHS.gov/help.htmlGeneralHospital/MRN:457398457

Disambiguation:Probabilistic Match on DemographicsAssume No National Health IDUse Only Demographics / No Clinical DataUse common set of patient demographicsName/DOB/Gender/Zip/SSN/etcPluggable Matching AlgorithmOptimized To Minimize False Positives

Patient MatchIncoming PID Fields Matched Against DBAlgorithm Tuned to Local ConditionsFalse Positives Tuned to < 1 in 100,000

Underlying TechnologiesTCP/IPSOAPWeb ServicesHL7/NCPDP messaging standardsLOINC codesNDC codes

Security / ConfidentialityServer-to-server (ISB-to-ISB) authentication via X.509 certificatesCommunication protected by SSL/TLS Federated identity based on single token authentication in edge systemsRole based/level based access control

What did we learn from the prototype work?

Authentication

Patient demographic entry

Query options

Viewer results display

Viewer results display -- more

Prototype SNOs reflect the realities of existing market and health IT variation

Prototype Approaches

What Common Framework technical resources are available?

Types of Technical ResourcesBackground InformationOn the Technical Architecture and Design Overall (T1) On Data Quality (T5)On the RLS (from the MA prototype site) (T6)

Implementation GuidesNHIN Message Implementation Guide including Record Locator Service/Inter-SNO Bridge (T2)Standards GuidesMedication History: Adapted NCPDP SCRIPT (T3)Laboratory Results: ELINCS 2.0, with modifications (T4)

Example Code/InterfacesTest Interfaces: CA, IN, MA www.connectingforhealth.org (under T2) Code base: CA, IN, MA www.connectingforhealth.org (under T2)

When you introduce yourself, explain your relationship to Connecting for Health.

According to the Connecting for Health model, the National Health Information Network is the sum of all smaller communities that exchange health information electronically among their members. It is a network of networks whose participants agree to use the Common Framework. Nationwide health information exchange takes place not through a separately funded entity, but through a framework of cooperation and compliance.

You will explain the unfamiliar terms SNO and RLS on the following slides. Some more detailed definitions FYI:

Entity: An entity refers to functionally independent participants within the health care system, from single doctor practices up to hospital chains and national organizations, whether public or private. An entity is any organization, institution, or practice; the only parts of the health care system that are not entities are the patients themselves.

SNO: A SNO is any group of entities (regionally or non-regionally defined) that agree to communicate clinical data with one another using a single Record Locator Service (RLS), using shared policies and technological standards, and operating together under a single SNO-wide set of policies and contractual agreements. A SNO has two sets of interfaces, one internal, which binds its member entities together, and one external, which is where traffic to and from other SNOs and outside entities come from. Examples of non-regionally-organized SNOs include the VA and RxHub.

Background Information resources help the reader get a general understanding of a subject and how the Common Framework addresses it. They would be appropriate for relatively non-technical people who are concerned in a general way with questions about how to design a system for information sharing.

Implementation Guides are much more technical. They provide code and other details of interest to system designers and programmers.

Example Code/Interfaces are resources made available by all three Connecting for Health prototype sites. They are available live through links in the Connecting for Health web site. They enable users to try and learn from the interfaces and code developed by each of the sites. This diagram shows the full array of Connecting for Health Common Framework resources.

It is designed to help you find your way around the different resources, and to underscore the point that policy guides (on the left) and technology guides (on the right) are complementary and closely linked. Model contractual language (at the bottom) supports and integrates elements of the policy and technical guides.

A good place for you to start using the Common Framework is the Common Framework Overview and Principles (at the top). It gives you some background on how the Common Framework evolved and how the pieces fit together.

As you can see from the boxes with the dotted lines on each side, the Common Framework is still evolving. There will be future guides that address new topics, such as how the Common Framework applies to patients access to their own health information.