1. © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use 13 June 2013 Meeting #3 hData Record Format Taskforce 1 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

2. Agenda  Organization of comments into thematic groups (Mark)  Discuss development of technical solutions for the following areas: –Nomenclature improvements –Patient-specific vs. Single vs. Multiple root files –New tag for content profiles (and relationship to Sections and Extensions) –Search and query support –Documentation and validation links  Next meeting planning  Mark has a hard stop at 4:00 EST 2 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

3. Process Suggestion  Obtain a “Sense of the Committee” consensus on each issue before starting technical work –Not a formal approval –An OK to work on a specific change that we can vote to approve or reject at a later dates  Suggested “Sense of Committee” choices are: –Advance (to move the issue forward with proposed solution) –Modify (to advance a different concept or idea) –Reject (keep the spec as-is) –Defer 3 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

4. Classification of 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  No current issues on: –Document metadata 4 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

5. Terminology Issues  Rename “Extension” to “ResourceType” –(HRF 2.2) “Extensions define the default type of section documents that appear in a section” –Reason: Extension is not descriptive; t he term “resource” resonates with REST and FHIR; FHIR refers to “resource types” –Scope: Change would apply to xml elements and HRF document –Possible alternative: resource Class Sense of Committee: _____Advance _____Modify _____Reject_____Defer Notes: 5 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

6. Terminology Issues  Rename “Section” to “URL” –(HRF 2.3) “Sections within an hData record form an abstract hierarchy, similar to the file folder structure commonly used in hierarchical file systems” –Reason: Term “section” derives from CDA nomenclature, however:  There is no direct relationship between hData and CDA  hData sections do not have to be the CDA sections –Scope: Change would apply to xml elements and HRF document –Possible alternatives: path, URI, URL, collectionURI (or URL), folder Sense of Committee: _____Advance _____Modify _____Reject_____Defer Notes: 6 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

7. Terminology Issues  Change documentation references to “Section Documents” or “Documents” to “Resources” –(HRF 1.0, 2.1) “… we use the word “ “section document” or “document” instead of “file” …. resources [are] referred to as “section documents” within the HRF specification.” –Reason:  Resource is the accepted term in REST and FHIR  “Document” has a special meaning in clinical context; hData’s “documents” do not necessarily follow the HL7 Clinical Document Architecture –Scope: Change would apply to documentation only Sense of Committee: _____Advance _____Modify _____Reject_____Defer Notes: 7 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

8. Other Terminology: Root.xml  (HRF 2.2) “At the top of the hierarchy is a special document which is called the “root document”, which describes many of the properties of the hierarchy”  Reason: –“Root” is not descriptive of its function or contents, which is to describe the resource hierarchy –Not like a WSDL or a FHIR conformance document  Suggestions: hDataResourceMap.xml, manifest.xml Sense of Committee: _____Advance _____Modify _____Reject_____Defer Notes: 8 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

9. Other Terminology: Content Profile  Descriptions of hData Content Profiles from HRF Sections 1.0, 3.2, 3.3: –“hData Content Profiles are Implementation Guides created by the HL7 domain working group, formatted as HCP documentation packages” –“Each HCP defines a specific document format to be exchanged, for example, a DICOM image, a continuity of care record (CCR), a device reading, etc.” (No!) –“To describe hData Content Profiles, the following [XML] schema is used for the HCP definition file…”  Reason for change: CP is confusingly described as a Content Profile Description Package (written document) and a Content Profile Definition Document (an xml doc similar to a root file)  Proposal: –Establish that a CP is a document profiling the use of hData for a specific purpose –State that the CP document should include a sample root file (this eliminates HRF 3.3, the hcp namespace, the XSD in HRF 4.2) –Steer away from making normative statements about the contents of a CP –Explain how a single root file can conform to multiple content profiles Sense of Committee: _____Advance _____Modify _____Reject_____Defer Notes: 9 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use

10. Attendees 10 © 2012 The MITRE Corporation. All rights reserved. For internal MITRE use