This wiki has undergone a migration to Confluence found Here

Difference between revisions of "DocumentRoot FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template:FHIR Resource Proposal}}")
 
Line 1: Line 1:
 
 
<div class="messagebox cleanup metadata">
 
<div class="messagebox cleanup metadata">
 
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
Line 13: Line 12:
  
  
=putProposedResourceNameHere=
+
=DocumentRoot=
  
 
<!-- Resource names should meet the following characteristics:
 
<!-- Resource names should meet the following characteristics:
Line 30: Line 29:
  
 
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. -->
 
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. -->
[[YourCommitteeName]]
+
[[Structured Documents]]
  
 
==Contributing or Reviewing Work Groups==
 
==Contributing or Reviewing Work Groups==
  
 
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the resource (optional) -->
 
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the resource (optional) -->
* Work Group Name
+
* [[EHR]]
* or link
 
* or "None"
 
  
 
==FHIR Resource Development Project Insight ID==
 
==FHIR Resource Development Project Insight ID==
  
 
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
 
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
 +
 +
pending
  
 
==Scope of coverage==
 
==Scope of coverage==
Line 55: Line 54:
 
As a rule, resources should encompass all of these aspects.
 
As a rule, resources should encompass all of these aspects.
 
  -->
 
  -->
 +
A documentation of healthcare-related information that is assembled together into a single statement of meaning that establishes its own context. A document is composed of a set of resources that include both human and computer readable portions. A human may attest to the accuracy of the human readable portion and may authenticate and/or sign the entire whole. A document may be kept as a set of logically linked resources, or they may be bundled together in an atom feed.
 +
 +
FHIR resources can be used to build clinical documents that capture information about clinical observations and services. A clinical document is a [http://hl7.org/implement/standards/fhir/resources.htm#bundle bundle] (a list of resources in an [http://hl7.org/implement/standards/fhir/formats.htm#atom atom feed]) that is fixed in scope, frozen in time and authored and/or attested as a set of logically contained resources by humans, organisations and devices. Documents built in this fashion may be exchanged between systems and also persisted in document storage and management systems, including systems such as IHE XDS. Applications claiming conformance to this framework claim to be conformant to "FHIR documents".
 +
 +
Note that FHIR defines both this document format and also a [http://wiki.hl7.org/index.php?title=DocumentReference_FHIR_Resource_Proposal document reference] resource. FHIR documents are for documents that are authored and assembled in FHIR, while the document reference resource is for general references to other documents.
  
 
==RIM scope==
 
==RIM scope==
  
 
<!-- Identify the formal RIM mapping for the root concept of the resource.  The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. -->
 
<!-- Identify the formal RIM mapping for the root concept of the resource.  The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. -->
 +
CDA
  
 
==Resource appropriateness==
 
==Resource appropriateness==
Line 74: Line 79:
 
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document  
 
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document  
 
  -->
 
  -->
 +
All documents have the same structure: a bundle that has a Document resource (see below) first, followed by a series of other resources referenced from the Document header that provides guidance on how they fit together. The bundle gathers all the content of the document into a single XML document which may be signed and managed as required. The resources include both human and computer readable portions.
 +
 +
The document resource identifies the document and its purpose, sets the context of the document and carries key information such as the subject and author. It also divides the document up into a series of sections that contain other resources identified in this specification that carry the content. Any resource referenced directly in the Document resource must be included in the bundle when the document is assembled. Other resources that these referenced resources refer to may also be included in the bundle if the document originator chooses to.
 +
 +
Document profiles can make additional rules about which resources must be included in the bundle along with the resources that are directly referenced in the Document resource. In addition, Document Profiles can specify what sections a document contains and what the constraints on those contents are. Applications should consider publishing conformance statements that identify particular documents they support.
  
 
==Expected implementations==
 
==Expected implementations==
  
 
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->
 
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->
 +
Those systems using Documents, Health Information Exchanges, and Personal Health Record systems.
  
 
==Content sources==
 
==Content sources==
Line 99: Line 110:
 
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
 
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
 
  -->
 
  -->
 +
unknown
  
 
==Timelines==
 
==Timelines==
  
 
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
 
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
 +
unknown
  
 
==gForge Users==
 
==gForge Users==
  
 
<!-- Identify the userids who will require commit access to gForge to maintain the resource.  (Ensure all users have registered for gForge.) -->
 
<!-- Identify the userids who will require commit access to gForge to maintain the resource.  (Ensure all users have registered for gForge.) -->
 +
unknown

Revision as of 18:12, 27 May 2013



DocumentRoot

Owning committee name

Structured Documents

Contributing or Reviewing Work Groups

FHIR Resource Development Project Insight ID

pending

Scope of coverage

A documentation of healthcare-related information that is assembled together into a single statement of meaning that establishes its own context. A document is composed of a set of resources that include both human and computer readable portions. A human may attest to the accuracy of the human readable portion and may authenticate and/or sign the entire whole. A document may be kept as a set of logically linked resources, or they may be bundled together in an atom feed.

FHIR resources can be used to build clinical documents that capture information about clinical observations and services. A clinical document is a bundle (a list of resources in an atom feed) that is fixed in scope, frozen in time and authored and/or attested as a set of logically contained resources by humans, organisations and devices. Documents built in this fashion may be exchanged between systems and also persisted in document storage and management systems, including systems such as IHE XDS. Applications claiming conformance to this framework claim to be conformant to "FHIR documents".

Note that FHIR defines both this document format and also a document reference resource. FHIR documents are for documents that are authored and assembled in FHIR, while the document reference resource is for general references to other documents.

RIM scope

CDA

Resource appropriateness

All documents have the same structure: a bundle that has a Document resource (see below) first, followed by a series of other resources referenced from the Document header that provides guidance on how they fit together. The bundle gathers all the content of the document into a single XML document which may be signed and managed as required. The resources include both human and computer readable portions.

The document resource identifies the document and its purpose, sets the context of the document and carries key information such as the subject and author. It also divides the document up into a series of sections that contain other resources identified in this specification that carry the content. Any resource referenced directly in the Document resource must be included in the bundle when the document is assembled. Other resources that these referenced resources refer to may also be included in the bundle if the document originator chooses to.

Document profiles can make additional rules about which resources must be included in the bundle along with the resources that are directly referenced in the Document resource. In addition, Document Profiles can specify what sections a document contains and what the constraints on those contents are. Applications should consider publishing conformance statements that identify particular documents they support.

Expected implementations

Those systems using Documents, Health Information Exchanges, and Personal Health Record systems.

Content sources

Example Scenarios

Resource Relationships

unknown

Timelines

unknown

gForge Users

unknown