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

Difference between revisions of "CompartmentDefinition FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template:FHIR Resource Proposal}}")
 
Line 13: Line 13:
  
  
=PutProposedResourceNameHere=
+
= CompartmentDefinition =
 
 
<!-- 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-Infrastructure
[[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) -->
+
* CGIT?
* 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 -->
+
Unknown
  
 
==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%"
+
The scope of this resource is to define a compartment in the specification (e.g. the patient compartment), or for a server to declare how it supports a compartment as defined in the specification. It may also be used to define new compartments, but the methodological consequences of this are unknown, and this isn't a focus.
  
Scope should consider numerous aspects of breadth of scope, including:
+
The resource will be suitable for use in the same way the other conformance resources are. (All locales)
* 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.
 
-->
 
  
 
==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. -->
+
N/a - out of scope for the RIM
  
 
==Resource appropriateness==
 
==Resource appropriateness==
  
<!-- Does the resource meet the following characteristics?
+
The specification already defines the concept of a compartment, and the build tool internally defines what each compartment means in a computable way. However this is not published by the build tool in any computable fashion. Nor is there any meaningful way to represent this in a conformance statement of a server, but it makes a difference to implementers, who may need or want to know what compartments a server offers, and how it decides that resources are in the compartment. This resource just makes a computable declaration of these things possible from a conformance resource. hence, it's requirements for storage etc match the conformance resource.
 
 
Must
 
* Represents a well understood, "important" concept in the business of healthcare
 
* 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. -->
+
* Build tool
 +
* Health intersections server
 +
* others?
  
 
==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
+
* Specification
 
 
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.) -->
+
see note above
  
 
==Resource Relationships==
 
==Resource Relationships==
  
<!-- What are the resources do you expect will reference this resource and in what context?
+
* will be referred to explicitly from the Conformance resource
 
+
* may be referred to explicitly from the IG resource, but will be able to included there even if not specifically referenced
What resources do you expect this resource reference and in what context?
 
 
 
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==
  
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
+
will be implemented prior to Montreal (may 2016) connectathon
  
 
==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
  
 
==When Resource Proposal Is Complete==
 
==When Resource Proposal Is Complete==
 
'''When you have completed your proposal, please send an email to [mailto:FMGcontact@HL7.org FMGcontact@HL7.org]'''
 
'''When you have completed your proposal, please send an email to [mailto:FMGcontact@HL7.org FMGcontact@HL7.org]'''

Revision as of 12:06, 18 February 2016



CompartmentDefinition

Owning committee name

FHIR-Infrastructure

Contributing or Reviewing Work Groups

  • CGIT?

FHIR Resource Development Project Insight ID

Unknown

Scope of coverage

The scope of this resource is to define a compartment in the specification (e.g. the patient compartment), or for a server to declare how it supports a compartment as defined in the specification. It may also be used to define new compartments, but the methodological consequences of this are unknown, and this isn't a focus.

The resource will be suitable for use in the same way the other conformance resources are. (All locales)

RIM scope

N/a - out of scope for the RIM

Resource appropriateness

The specification already defines the concept of a compartment, and the build tool internally defines what each compartment means in a computable way. However this is not published by the build tool in any computable fashion. Nor is there any meaningful way to represent this in a conformance statement of a server, but it makes a difference to implementers, who may need or want to know what compartments a server offers, and how it decides that resources are in the compartment. This resource just makes a computable declaration of these things possible from a conformance resource. hence, it's requirements for storage etc match the conformance resource.

Expected implementations

  • Build tool
  • Health intersections server
  • others?

Content sources

  • Specification

Example Scenarios

see note above

Resource Relationships

  • will be referred to explicitly from the Conformance resource
  • may be referred to explicitly from the IG resource, but will be able to included there even if not specifically referenced

Timelines

will be implemented prior to Montreal (may 2016) connectathon

gForge Users

Grahame

When Resource Proposal Is Complete

When you have completed your proposal, please send an email to FMGcontact@HL7.org