DocumentRoot FHIR Resource Proposal
This page documents a depricated FHIR Resource Proposal (In favour of composition)
Contents
- 1 DocumentRoot
- 1.1 Owning committee name
- 1.2 Contributing or Reviewing Work Groups
- 1.3 FHIR Resource Development Project Insight ID
- 1.4 Scope of coverage
- 1.5 RIM scope
- 1.6 Resource appropriateness
- 1.7 Expected implementations
- 1.8 Content sources
- 1.9 Example Scenarios
- 1.10 Resource Relationships
- 1.11 Timelines
- 1.12 gForge Users
DocumentRoot
Owning committee name
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
