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

Difference between revisions of "MessageDefinition FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template:FHIR Resource Proposal}}")
 
Line 13: Line 13:
  
  
=PutProposedResourceNameHere=
+
=MessageDefinition=
 
 
<!-- 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. -->
 
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. -->
[[YourCommitteeName]]
+
[[FHIR Infrastructure]]
 
==Committee Approval Date:==
 
==Committee Approval Date:==
<i>Please enter the date that the committee approved this Resource proposal</i>
+
TBD
  
 
==Contributing or Reviewing Work Groups==
 
==Contributing or Reviewing Work Groups==
 
+
* Infrastructure & Messaging
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the resource (optional) -->
 
* Work Group Name
 
* or link
 
* or "None"
 
  
 
==FHIR Resource Development Project Insight ID==
 
==FHIR Resource Development Project Insight ID==
Line 46: Line 30:
  
 
==Scope of coverage==
 
==Scope of coverage==
 
+
This represents the description of a type of message that can be sent from one system to another using the FHIR message paradigmIt describes the content of the message, the triggering event and the expected behavior of the receiving systemIt can be thought of as the parallel to OperationDefinition, but for the messaging paradigm rather than the services paradigm. It is an infrastructure resource and can be used in all possible contexts.
<!-- Define the full scope of coverage for the resourceThe scope must be clearly delineated such that it does not overlap with any other existing or expected resourceThe 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%"
 
 
 
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.
 
-->
 
  
 
==RIM scope==
 
==RIM scope==
 
+
N/A - This would have been handled at the RIM layerIt sort of acts like a v3 Interaction definition.
<!-- Identify the formal RIM mapping for the root concept of the resourceThe expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. -->
 
  
 
==Resource appropriateness==
 
==Resource appropriateness==
 +
Message Definitions have been a key part of HL7 since v2.  It includes the definition of the triggering event, the structure of transmitted messages and what sorts of responses are permitted.  This same set of information existed in the v3 methodology.  In FHIR, this information is currently captured as part of CapabilityStatement.  However, in doing so, it doesn't support the re-use of message definition information.  There's definitely a need for message definitions to be created in implementation guides and then referenced in down-stream CapabilityStatements.
  
<!-- Does the resource meet the following characteristics?
+
Each MessageDefinition is stand-alone and independently identifiable and maintainable, sharing the characteristics of other MetadataResources such as ValueSet and StructureDefinition.  As such it can be queried, subscribed to, included in implementation guides, etc. in the same manner as any other infrastructure 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==
 
+
This will be implemented by all implementation guides and specifications that need to define messages.
<!--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. -->
 
  
 
==Content sources==
 
==Content sources==
 
+
v2 chapter 2, v3 MIF, FHIR CapabilityStatement resource
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult
 
 
 
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
 
  
 
==Example Scenarios==
 
==Example Scenarios==
 
+
*Defining an "Admit Patient" message, including the focal resource, other resources to be included in the bundle, the event code and allowed response messages
<!-- 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.) -->
+
*Defining a messaging equivalent of a FHIR operation (with the ability to do asynchronous and routed processing)
  
 
==Resource Relationships==
 
==Resource Relationships==
 
+
* MessageDefinition will point to StructureDefinition (or potentially GraphDefinition) to define the content for the message.
<!-- What are the resources do you expect will reference this resource and in what context?
+
* MessageDefinition will point to other MessageDefinitions to define allowed responses to a given message
 
+
* ConformanceStatement will point to MessageDefinition indicating the messages that are/should be supported by a system
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==
 
+
For inclusion as draft in STU 3, publish as STU in release 4
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
 
  
 
==gForge Users==
 
==gForge Users==
 
+
lloyd_mckenzie
<!-- Identify the userids who will require commit access to gForge to maintain the resource.  (Ensure all users have registered for gForge.) -->
 
  
 
==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 22:39, 25 February 2017



MessageDefinition

Owning committee name

FHIR Infrastructure

Committee Approval Date:

TBD

Contributing or Reviewing Work Groups

  • Infrastructure & Messaging

FHIR Resource Development Project Insight ID

Scope of coverage

This represents the description of a type of message that can be sent from one system to another using the FHIR message paradigm. It describes the content of the message, the triggering event and the expected behavior of the receiving system. It can be thought of as the parallel to OperationDefinition, but for the messaging paradigm rather than the services paradigm. It is an infrastructure resource and can be used in all possible contexts.

RIM scope

N/A - This would have been handled at the RIM layer. It sort of acts like a v3 Interaction definition.

Resource appropriateness

Message Definitions have been a key part of HL7 since v2. It includes the definition of the triggering event, the structure of transmitted messages and what sorts of responses are permitted. This same set of information existed in the v3 methodology. In FHIR, this information is currently captured as part of CapabilityStatement. However, in doing so, it doesn't support the re-use of message definition information. There's definitely a need for message definitions to be created in implementation guides and then referenced in down-stream CapabilityStatements.

Each MessageDefinition is stand-alone and independently identifiable and maintainable, sharing the characteristics of other MetadataResources such as ValueSet and StructureDefinition. As such it can be queried, subscribed to, included in implementation guides, etc. in the same manner as any other infrastructure resource.

Expected implementations

This will be implemented by all implementation guides and specifications that need to define messages.

Content sources

v2 chapter 2, v3 MIF, FHIR CapabilityStatement resource

Example Scenarios

  • Defining an "Admit Patient" message, including the focal resource, other resources to be included in the bundle, the event code and allowed response messages
  • Defining a messaging equivalent of a FHIR operation (with the ability to do asynchronous and routed processing)

Resource Relationships

  • MessageDefinition will point to StructureDefinition (or potentially GraphDefinition) to define the content for the message.
  • MessageDefinition will point to other MessageDefinitions to define allowed responses to a given message
  • ConformanceStatement will point to MessageDefinition indicating the messages that are/should be supported by a system

Timelines

For inclusion as draft in STU 3, publish as STU in release 4

gForge Users

lloyd_mckenzie

When Resource Proposal Is Complete

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