Overview for IHE

1. Overview for IHE The MITRE Corporation

2. 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

3. 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)

4. Core Specifications

5. 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

6. 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

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

8. “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

9. “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

10. “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.)

11. hData in a Nutshell GET resource 2 GET ATOM feed 1 XML listing of patient documents(metadata and hyperlinks) CCD or CCR XML DICOM images Other formats hData enabled System

12. 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

13. Backup

14. Relation to Other HL7 Products (Note: this is not UML)

15. hData Mobile Architecture There’s a problem with your Blood Sugar! Compliance ↑ Cost ↓ Clinician views EHR with hData client on iPad or Android device Domain App (e.g Diabetes) Alert patient or local care provider Cloud Push Bluetooth hData device polls server for updates and alerts hHub App Enabler Patient hData hData parsing, persistence, and OAuth2 negotiation Server polls device for new readings hData Server Monitoring