1 / 20

Status Update: hData Record Format, Rel. 2

Status Update: hData Record Format, Rel. 2. SOA Working Group Meeting Mark Kramer July 22, 2013. hData Background. Created in 2009 in response to then-current healthcare standards, which were viewed as complex, somewhat technologically backward, and unsuitable for mobile health

ownah
Download Presentation

Status Update: hData Record Format, Rel. 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Status Update:hData Record Format, Rel. 2 SOA Working Group Meeting Mark Kramer July 22, 2013

  2. hData Background • 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)

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

  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

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

  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

  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

  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

  9. Terminology Changes • Intended to make the specification more accessible and to use terminology in a more standard way; also better aligned with FHIR

  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) Root section @path: string 1..1 @extensionID: string 1..1 @requirement: extension: string 1..1 sections 0..N Root Id: string 1..1 version: integer 1..1 created: dateTime 1..1 lastModified: dateTime 1..1 extension extensions 0..N @extensionID: string 1..1 @contentType: string 1..1 (MIME type) extension: string 1..1 (definitional URL)

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

  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 can’t handle complex elements with text values • FHIR JSON doesn’t distinguish attributes from child elements and therefore isn’t perfectly reversible • FHIR JSON doesn’t deal with XML namespaces and so naming collisions are possible

  13. Patient Specific Endpoints (Release 1) Patient-specific baseURL Assumed prior knowledge +/patient ID Root hierarchy URL fragment Root hierarchy … No assumption about behavior here Root hierarchy 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

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

  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

  18. Atom Feed: Metadata • Release 1 required metadata on Atom <entry> 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

  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

  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

More Related