1. © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use SOA Working Group Meeting Mark Kramer July 22, 2013 Status Update: hData Record Format, Rel. 2

2. Created in 2009 in response to then-current healthcare standards, which were viewed as complex, somewhat technologically backward, and unsuitable for mobile health hData core principles: –Adoption of common web technology such as REST and Atom –Disaggregation of large medical records into granular clinical resources identified by URLs –Access to clinical resources via REST interface –Use of simplified, easily validated XML representations hData addresses two parts of the information interoperability problem: –Framework for declaring and organizing resources (hData Record Format, or HRF) –REST realization of RLUS data operations (hData RESTful Transport, or HRT) hData Background

3. hData Timeline 3 2009 20102011 2012 HL7 Fresh Look kick-off (May 2011) First public presentation of hData at Balisage Conference (Aug 2009) hData Record Format DSTU approval (Sept 2011) Begins (Jan 2012) hData-HL7 standardization effort begins (Feb 2010) hData REST Transport Beta (Jan 2012) ONC NwHIN team looks at hData and REST 2013 hData REST Transport Normative (Jan 2013) ONC S&I Framework Project uses hData Adopts hData for next generation device standards Medication hData Content profile DSTU begun ONC NwHIN recommends FHIR + RHEx

4. hData and FHIR Comparison hData and FHIR are complementary and partially overlapping hData can be used when a combination of FHIR and non-FHIR resources are exchanged 4 hDataFHIR ResourcesFHIR and non-FHIR resources, files, images, etc. Specific set of FHIR resources TransportREST Resource groupingUp to implementer; can be arranged by patient, resource type, location, date, medical specialty, etc. By class Exchange FormatsUnlimitedXML, JSON

5. hData Task Force Mark Kramer David Hay Paul Knapp Muhammed Asim Sam Sayer Erik Pupo 5

6. Task Force Process Weekly meetings since Atlanta meeting Meetings documented on HSSP Wiki Major activities: –Reviewed and classified DSTU comments –Obtained consensus on direction for each issue –Created technical approaches –Implemented and reviewed document updates Aiming for normative ballot in August-September 6

7. Goals for HRF Release 2 Terminology clarification* Root file content profile incorporation Content profile simplification Path templates* Resource prefix* JSON support* Atom Feed FHIR Alignment* Atom feed metadata simplification* *FHIR Alignment 7

8. Classification of DSTU Comments (by ID #) Terminology Issues: 256 Root File Multiplicity (including URL templates): 251, 257 Query, Atom Feed Issues: 252, 253, 258 Root File Links (to profiles, xsds, etc.): 83, 264, 265 Other Issues: –Editorial Comments: 54, 250 –XML Issues: 53, 261 8

9. Terminology Changes Intended to make the specification more accessible and to use terminology in a more standard way; also better aligned with FHIR 9 Release 1Release 2 ExtensionResource type Section documentResource PedigreeProvenance

10. hData Record Format: Root Files (Release1) HRF contains the recipe for creating root files –Root file is how an hData server documents itself –Client retrieves the root file (HTTP) from known URL –Root lists URLs (sections) and resource types (extensions) 10 Root Id: string 1..1 version: integer 1..1 created: dateTime 1..1 lastModified: dateTime 1..1 Id: string 1..1 version: integer 1..1 created: dateTime 1..1 lastModified: dateTime 1..1 extension @extensionID: string 1..1 @contentType: string 1..1 (MIME type) extension: string 1..1 (definitional URL) @extensionID: string 1..1 @contentType: string 1..1 (MIME type) extension: string 1..1 (definitional URL) extensions 0..N section @path: string 1..1 @extensionID: string 1..1 @requirement: extension: string 1..1 @path: string 1..1 @extensionID: string 1..1 @requirement: extension: string 1..1 sections 0..N

11. hData Record Format, Release 2 11 NEW XML or JSON

12. JSON Conversion Root file and Atom feed can be provided in XML or JSON We follow FHIR rules of thumb with some differences: –FHIR cant handle complex elements with text values –FHIR JSON doesnt distinguish attributes from child elements and therefore isnt perfectly reversible –FHIR JSON doesnt deal with XML namespaces and so naming collisions are possible 12

13. Patient Specific Endpoints (Release 1) 13 Root URL fragment Patient- specific baseURL +/patient ID Root hierarchy … Assumed prior knowledge No assumption about behavior here Probably the same root files (but not required)

14. Path Templates Templates denoted by {curly_brackets} –[baseURL]/Patients/{Patient.id}/Conditions –[baseURL]/Patients/{Patient.id}/Allergies Templates allow "dependent resources" that are owned by an existing resource –DICOM: Studies > Series > Images Example:../Patients/{Patient.id}/Radiology/Studies/{Study.id}/Series/{Series.id}/Images../Patients/1234/Radiology/Studies/567/Series/2/Images Templates can also be used for parametric access, e.g.:../Patients/{Patient.id}/Radiology/Studies/{YYYY}/{MM}/{DD}../Patients/{Patient.id}/Radiology/Studies/2013/07/22 14

15. Template example: [baseURL]/Patients/{patientID}/medications Patient-Specific Hierarchy, Release 2 15 /patient 1 Root Patient- specific resources Base URL /patient 2 /patient N hierarchy … The only required prior knowledge /Patients Possible service to get patient IDs Same hierarchy

16. Resource Prefix Use of templates can lead to confusion between sections and resources:../Patients/1234/Radiology/Studies/567 Study #567../Patients/1234/Radiology/Studies/2012 Study #2013 ?!? Solution: Use resource prefix, like in FHIR (@)../Patients/1234/Radiology/Studies/@567 Study 567 (resource)../Patients/1234/Radiology/Studies/2012 List of studies from 2012 (Atom) Resource prefix used by default; user declaration can turn off 16

17. Atom Feed FHIR Alignment –Aligned Atom feed with FHIR element profile Title changed from URL to description Clarified use of link element JSON feeds supported Simplified and aligned additional metadata 17

18. Atom Feed: Metadata Release 1 required metadata on Atom to represent pedigree, confidentiality, styled after CDA header –Too complicated, should not have been required (since some resources represent their own pedigree internally) –We re-modeled the metadata after the FHIR Provenance resource 18

19. hData Content Profiles (HCP), Release 2 Re-written to be more informative, less prescriptive –Emphasize that HCPs are just domain-specific implementation guides for using hData –We provide suggested contents for HCP, but no requirements Removed schema for HCP Definition Documents –Sufficient for authors of HCP to provide a sample root file 19

20. HRF Release 2 Document Status Almost complete (only missing JSON in Examples section) Waiting on feedback from some team members Significantly upgraded document –New FHIR-style UML diagrams and pseudo-XML, JSON –Updated schemas, examples –Better descriptive writing Don Lloyd has indicated flexibility on submission format –Provide MS-Word, he will convert to PDF 20