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) 1 GET ATOM feed CCD or CCR XML DICOM images Other 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 Enabler parsing, persistence, and OAuth2 negotiation