Difference between revisions of "MessageDefinition FHIR Resource Proposal"
(Created page with "{{subst::Template:FHIR Resource Proposal}}") |
|||
Line 13: | Line 13: | ||
− | = | + | =MessageDefinition= |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==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. --> | ||
− | [[ | + | [[FHIR Infrastructure]] |
==Committee Approval Date:== | ==Committee Approval Date:== | ||
− | + | TBD | |
==Contributing or Reviewing Work Groups== | ==Contributing or Reviewing Work Groups== | ||
− | + | * Infrastructure & Messaging | |
− | |||
− | * | ||
− | |||
− | |||
==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 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== | ==RIM scope== | ||
− | + | N/A - This would have been handled at the RIM layer. It sort of acts like a v3 Interaction 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. | ||
− | + | 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== | ==Expected implementations== | ||
− | + | This will be implemented by all implementation guides and specifications that need to define messages. | |
− | |||
==Content sources== | ==Content sources== | ||
− | + | v2 chapter 2, v3 MIF, FHIR CapabilityStatement resource | |
− | |||
− | |||
− | |||
==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 | |
− | + | *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. | |
− | + | * 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== | ==Timelines== | ||
− | + | For inclusion as draft in STU 3, publish as STU in release 4 | |
− | |||
==gForge Users== | ==gForge Users== | ||
− | + | lloyd_mckenzie | |
− | |||
==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
Contents
- 1 MessageDefinition
- 1.1 Owning committee name
- 1.2 Committee Approval Date:
- 1.3 Contributing or Reviewing Work Groups
- 1.4 FHIR Resource Development Project Insight ID
- 1.5 Scope of coverage
- 1.6 RIM scope
- 1.7 Resource appropriateness
- 1.8 Expected implementations
- 1.9 Content sources
- 1.10 Example Scenarios
- 1.11 Resource Relationships
- 1.12 Timelines
- 1.13 gForge Users
- 1.14 When Resource Proposal Is Complete
MessageDefinition
Owning committee name
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