Overview for IHE

The MITRE Corporation

Overview

• hData was originally developed by The MITRE Corporation– Internal R&D– Focus on simplifying Continuity of Care use cases– Broad initial goal set:

• Wire format simplification• Strict data modeling and content separation from exchange mechanics• Flexible metadata model• Transport simplification• Patient-centric identity management and access control

• Significant interest from XML, health IT, and government communities

hData goes Standard

• To improve quality and adoption, hData pursued standardization– Health Layer 7 (HL7) and Object Management Group (OMG)– Part of Service-Oriented Architecture catalog of standards

• Realization of Resource Locate and Update Service (RLUS) Functional Model

• REST Binding established Resource-Oriented Service approach

– Limited scope for initial set of standards• Packaging and meta-data (HL7)• REST Transport and RLUS realization (OMG)

• Current status: Draft/Beta Standards (Q1CY2012)

Core Specifications

Scoping hData

• What can hData do?– Uniform way to organize clinical information– Standard metadata annotation– Transport/network API– Normalized way to describe content models

• What does hData not do?– Provide topical/domain specific content– Offer XML simplification approach

Architecture Focus: Health Data Exchange

• hData focuses on system-to-system data exchange– There is no architectural requirement on the

system itself– hData’s network-facing interfaces are simple and

can be “plugged on” existing clinical systems

Architectural Concepts

• “Service and Resource Oriented”• “Disaggregated, but Linked Data”• “Uniform Access, Rich Semantics”

“Service and Resource Oriented”

• hData departs from message/document exchange paradigm

• Context for exchange is set by service contract, deployment parameters, and exchange – NOT – implicitly within document/message

“Disaggregated, But Linked Data”

• Allow (but do not require!) small information pieces– Individual allergies, medications, lab results, orders, etc., but

allow full CCD or V3 messages– Provide full set of meta-data for each information piece– Offer chronological lists of pieces, sorted by type or by other

criteria; subscription to new information• Allow complex and semantically rich linking between data

– Abstract links or URLs for web based access• Visibility of individual pieces

– Hide sensitive information; don’t redact – just do not share– Data re-use through simple de-identification and selective

sharing

“Uniform Access, Rich Semantics”

• Uniform data access methods– REST Binding for RLUS defines default effects of

GET/PUT/POST/DELETE on record elements• Semantics through self-describing structures– “Root.xml” manifest describes high-level structure of

actually contained information– RLUS “semantic signifiers” indicate support for data types

and content profiles• Negotiable resource representation – Device/data consumer selectable wire-level format (XML,

JSON, PDF, PNG, DICOM, etc.)

hData in a Nutshell

hData enabled System

GET resource

2

XML listing of patient documents (metadata and hyperlinks)

1GET ATOM feed

CCD or CCR XMLDICOM imagesOther formats

Integration Points With XD*

• MIME-centric payload model• Meta-data alignment– Initial mapping table on HL7 hData wiki page

• Hierarchical sectional structure in HRF supports IHE Folders and Submission Sets– Semantics will need to be clearly defined

• Developing concepts of linked data

BACKUP

Relation to Other HL7 Products

(Note: this is not UML)

hData Mobile Architecture

15

There’s a problem with your Blood

Sugar!

Alert patient or local care provider

Cloud Push

Compliance ↑ Cost ↓ Clinician views EHR with hData client on

iPad or Android device

hData

hData Server

Server polls device for new

readings

device polls server for updates and alerts

hData

Monitoring

hData

Patient

Domain App (e.g Diabetes)

Bluetooth

hHub App

Enablerparsing,

persistence, and OAuth2

negotiation