© 2012 The MITRE Corporation. All rights reserved. For internal MITRE use 5 July 2013 Meeting #5 hData Record Format Task Force 1 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Attendees  Mark Kramer  Sam Sayer  David Hay 2 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Agenda  Draft Document – overview of changes  Root file schema proposal  Section template proposal  HCP simplification proposal 3 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

HL7 Ballot Schedule 4 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Draft HRF 2.0 Document  Distributed via prior to meeting  Change tracking on –Easiest to read in “Final” mode  Significant changes in: –Introduction through Section 2.5, Section 3 (Content Profiles) –No changes yet in:  Metadata (Section 2.6)  Schemas (Section 4)  Example (Section 5)  Feedback on Sections 1 – 2.5 and 3 requested by Thursday, July 11 5 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Proposed Root File Schema 6 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Proposed Root File Schema (Pseudo-XML) 7 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

REJECTED: Alternative Proposal for Root File  Top-level section contains one or more resources of type “Root” –One root resource per content profile –If no content profiles are implemented, there must be a custom root file (with arbitrary name)  Name of file would be the name of the content profile, not “root”. For example: –HL7MedicationStatement.xml –ContinuaObservationUpload.xml –ContinuaQuestionnaire.xml  GET [baseURL] returns a list of root files in an Atom feed –Content may be inlined in feed>entry>content  Benefits: –Avoids the merging of root files and potential conflicts –Makes it clear how sections map to content profiles. –Eliminates the need for a new element in root files –Allows implementers to directly copy pre-existing root files  Cons: –Takes N+1 GETs to obtain all N root files (if content is not inlined) 8 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Path Templates  Templates solve the problem of needing one hData endpoint per patient (if data is arranged on per-patient basis)  Templates denoted by {curly_brackets}  More generally, 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/06/22 9 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Section/Resource Ambiguity../Patients/1234/Radiology/Studies/567 → Study 567../Patients/1234/Radiology/Studies/2012 → Study 2013 ?!? Solution: Use resource prefix, like in FHIR → Study 567../Patients/1234/Radiology/Studies/2012 → List of studies from 2012 Resource prefix (only) required in sections defined by templates  Backward-compatible change  Implementer free to specify the resourcePrefix (none by default) 10 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Example Read (HTTP GET) Behaviors../Patients/1234/Radiology/Studies → List of Studies for Patient → Study 567../Patients/1234/Radiology/Studies/567 → Empty list (no resources in section 567)../Patients/1234/Radiology/Studies/567/Series → List of Series in Study → Series 2../Patients/1234/Radiology/Studies/567/Series/2/Images → List of Images in Series → Image 4../Patients/1234/Radiology/Studies → List of Studies for Patient /Patients/1234/Radiology/Studies/2012 → List of Studies in /Patients/1234/Radiology/Studies/2012/11 → List of Studies in November → Study 11 (Error 404 if Study 11 is not 2012) 11 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Requirements and Recommendations for Templates (Section 2.3)  The string inside curly brackets has no semantics –Allowable substitutions and behavior to be documented in HCP –RECOMMEND using “hinting” – see HRF for details  RECOMMEND using dependent-resource pattern:../[resourceType]/{resource.id}/../[dependentResourceType]/{dependentResource.id}  Implementer MUST use a resourcePrefix to denote resources in sections defined by templates –Inherited downward in the hierarchy –Section names MUST NOT begin with the resourcePrefix –Certain characters MUST NOT be used: $ # % & *| { } \ : ? / + 12 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

hData Content Profiles (HCP) – Section 3  Re-written to be more informative, less prescriptive –Emphasize that HCPs are just domain-specific implementation guides for using hData  Removed schema for HCP Definition Documents –Authors of HCP should provide a sample root file  Section 3.1 contains suggested contents for HCP –Please review 13 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

Action Items  David H. –Will look at harmonizing Atom feeds between hData and FHIR –NO - Can we use FHIR build tool to generate XSD and JSON examples for Root resource? (not realistic in time frame)  Mark K. –Can Root.xml equally support for JSON? –In accord on changing “contentType” to “representation”  Reason: content suggests something that is contained; contentType is HTTP jargon it is synonymous with media type  Sam –Take a look at excluded characters for resourcePrefix, or why not just use 14 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use