This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "DocumentManifest 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=
+
=DocumentManifest=
−
 
 
−
<!-- Resource names should meet the following characteristics:
 
−
* Lower camel case
 
−
* U.S. English
 
−
* Domain-friendly
 
−
* Short
 
−
* Clear
 
−
* Unique
 
−
* Avoid non-universal abbreviations (e.g. URL would be ok)
 
−
* Be expressed as a noun
 
−
* Be consistent with other similar resources
 
−
-->
 
  
 
==Owning committee name==
 
==Owning committee name==
  
−
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. -->
+
[[FHIR]] project team
−
[[YourCommitteeName]]
 
  
 
==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) -->
+
* IHE
−
* Work Group Name
 
−
* 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 -->
+
FHIR project
  
 
==Scope of coverage==
 
==Scope of coverage==
  
−
<!-- Define the full scope of coverage for the resource.  The scope must be clearly delineated such that it does not overlap with any other existing or expected resource.  The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%"
+
A declaration that a set of document references (existing resource) are part of a single logical set of documents that are managed and accessed as a group
−
 
 
−
Scope should consider numerous aspects of breadth of scope, including:
 
−
* Subject: Human vs. non-human vs. non-patient (e.g. lab bench medicine)
 
−
* Disciplines: Environmental Health, Palliative, Respiratory, Psychology, Maternity, Clinical Research
 
−
* Delivery environment (Community, Geriatric, Home care, Emergency, Inpatient, Intensive, Neonatal, Pediatric, Primary)
 
−
* Locale: Country, region
 
  
−
As a rule, resources should encompass all of these aspects.
+
History: The existing DocumentReference resource was intended to cover the scope of IHE XDS. However a review of the DocumentReference Resource in that context identified that an IHE XDS submission set is not simply a transactional construct, but that there are semantics associated with the submission set, and these have been omitted from FHIR. This resource is required to resolve the ballot comments that arose from the IHE XDS review.
−
-->
 
  
 
==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. -->
+
An Act for submitting a group of documents, along with act references to the documents, and the usual participations
  
 
==Resource appropriateness==
 
==Resource appropriateness==
  
−
<!-- Does the resource meet the following characteristics?
+
* XDS has made clear how useful document references are, and an implicit part of this is a set of documents (technical) that constitute a single document (user perspective)
−
 
+
* this is, in effect, a manifest that declares that a set of different document references belong together for some workflow purpose. Hence, "DocumentManifest"
−
Must
+
* the logical group of documents is a distinct concept that needs tracking and storing. The individual document references in a manifest may be shared across document manifests that exist for different purposes
−
* Represents a well understood, "important" concept in the business of healthcare
+
* this is to support existing XDS functionality for MHD
−
* Represents a concept expected to be tracked with distinct, reliable, unique ids
 
−
* Reasonable for the resource to be independently created, queried and maintained
 
−
 
 
−
Should
 
−
* Declared interest in need for standardization of data exchange</span>
 
−
* Resource is expected to contain an appropriate number of "core" (non-extension) data elements (in most cases, somewhere in the range of 20-50)
 
−
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document  
 
−
-->
 
  
 
==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. -->
+
* any MHD implementation
  
 
==Content sources==
 
==Content sources==
  
−
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult
+
* IHE XDS + existing mapping
−
 
+
* Document Reference
−
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
 
  
 
==Example Scenarios==
 
==Example Scenarios==
  
−
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource.  They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
+
* taken from standard IHE XDS example
  
 
==Resource Relationships==
 
==Resource Relationships==
  
−
<!-- What are the resources do you expect will reference this resource and in what context?
+
Uses:
 +
* DocumentReference, Binary
  
−
What resources do you expect this resource reference and in what context?
+
Used By:
 +
* nothing yet
  
−
Note: These may be existing resources or "expected" resource
 
  
−
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
+
==Timelines==
−
-->
 
  
−
==Timelines==
+
End of october to meet DSTU reconciliation timelines
  
−
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
 
  
 
==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.) -->
+
Grahame, John M.

Revision as of 23:20, 3 October 2013

OpenHotTopic.GIF

This page documents a Pending FHIR Resource Proposal



DocumentManifest

Owning committee name

FHIR project team

Contributing or Reviewing Work Groups

  • IHE

FHIR Resource Development Project Insight ID

FHIR project

Scope of coverage

A declaration that a set of document references (existing resource) are part of a single logical set of documents that are managed and accessed as a group

History: The existing DocumentReference resource was intended to cover the scope of IHE XDS. However a review of the DocumentReference Resource in that context identified that an IHE XDS submission set is not simply a transactional construct, but that there are semantics associated with the submission set, and these have been omitted from FHIR. This resource is required to resolve the ballot comments that arose from the IHE XDS review.

RIM scope

An Act for submitting a group of documents, along with act references to the documents, and the usual participations

Resource appropriateness

  • XDS has made clear how useful document references are, and an implicit part of this is a set of documents (technical) that constitute a single document (user perspective)
  • this is, in effect, a manifest that declares that a set of different document references belong together for some workflow purpose. Hence, "DocumentManifest"
  • the logical group of documents is a distinct concept that needs tracking and storing. The individual document references in a manifest may be shared across document manifests that exist for different purposes
  • this is to support existing XDS functionality for MHD

Expected implementations

  • any MHD implementation

Content sources

  • IHE XDS + existing mapping
  • Document Reference

Example Scenarios

  • taken from standard IHE XDS example

Resource Relationships

Uses:

  • DocumentReference, Binary

Used By:

  • nothing yet


Timelines

End of october to meet DSTU reconciliation timelines


gForge Users

Grahame, John M.

Retrieved from "https://wiki.hl7.org/w/index.php?title=DocumentManifest_FHIR_Resource_Proposal&oldid=78883"