This specification conforms to FHIR®© R4
Governance for MedCom FHIR Messages
Table of content
- 1. MedComMessagingMessage-bundle
- 2 MedComMessagingMessageHeader
- 3 MedComMessagingOrganization
- 4 MedComMessagingProvenance
- 5 MustSupport
- 6 Narrative texts
1 MedComMessagingMessage (Bundle)
An inherited instance profile of MedComMessagingMessage SHALL follow the generic concept of the MedComMessagingMessage as outlined here: Click here to read more about the MedComMessagingMessage (Bundle) in IG for MedCom Message
1.1 MedComMessagingMessage Rules
| MedComMessagingMessage Rules |
|---|
| A MedCom FHIR Message SHALL be a Bundle resource of type “message” |
| A MedCom FHIR Message SHALL contain at least one bundled MedComMessagingHeader resource |
| The MedComMessagingHeader resource SHALL be the first resource in a MedCom Message Bundle |
| A MedCom FHIR Message SHALL contain at least two bundled MedComMessagingOrganization resources |
| One of the two bundled MedComMessagingOrganization resources SHALL represent the Sender Organization pointed to by the MedComMessagingHeader.sender element |
| One of the two bundled MedComMessagingOrganization resources SHALL represent the Receiver Organization pointed to by the MedComMessagingHeader.destination:primary sliced element |
| A MedCom FHIR Message MAY contain more bundled MedComMessagingOrganization resources |
| The MedComMessagingHeader resource MAY include a list of carbon-copy receiver organizations pointed to by the MedComMessagingHeader.destination:cc sliced element(s) |
| If there exists one or more destination:cc elements, these SHALL be represented as bundled MedComMessagingOrganization resource(s) each one of the carbon-copy receiver Organizations pointed to by the MedComMessagingHeader.destination:cc sliced element |
| A MedCom FHIR Message SHALL contain at least one bundled MedComCorePatient resource |
| A MedCom FHIR Message SHALL contain at least one bundled MedComMessagingProvenance resource |
| A MedCom FHIR Message SHALL contain one bundled focused resource pointed to by the MedComMessagingHeader |
| The MedComMessagingHeader resource SHALL contain a Narrative text |
| A MedCom FHIR Message SHALL be validated before disptching of the message |
| A MedCom FHIR Message SHALL be validated on reception of the message in the Receiving Apllication |
1.2 MedComMessagingMessage Links
2 MedComMessagingMessageHeader
An inherited instance profile of MedComMessagingMessageHeader SHALL follow the generic concept of the MedComMessagingMessageHeader as outlined here: Click here to read more about MedComMessagingMessageHeader in IG for MedCom Message
2.1 MedComMessagingMessageHeader Rules
The MedComMessageHeader profile is a resource that SHALL be used in all MedCom FHIR Messages. A MedComMessagingMessageHeader SHALL include a sender and receiver and it MAY include a carbon-copy receiver, however this is depended on type of standard. Each MedComMessagingMessageHeader SHALL include a globally unique id, which SHALL be used to reference the message in the message history from the MedComMessagingProvenance profile.
The element event SHALL be defined in accordance with the type of standard the message concerns e.g., HospitalNotification and CareCommunication. Due to the different requirements for each standard, it SHALL be expected that the MedComMessagingMessageHeader is inherited in each standard.
| MedComMessageHeader Rules |
|---|
| The MedComMessagingHeader resource SHALL be the first resource in a MedCom Message Bundle |
| The MedComMessagingHeader resource SHALL contain an event of the MedCom Message (eg. the type of the message) |
| The MedComMessagingHeader resource SHALL contain an MedComMessagingHeader.id of the MedCom Message (eg. the letter.id of the message) |
| One of the two bundled MedComMessagingOrganization resources SHALL represent the Sender Organization pointed to by the MedComMessagingHeader.sender element |
| One of the two bundled MedComMessagingOrganization resources SHALL represent the Receiver Organization pointed to by the MedComMessagingHeader.destination:primary sliced element |
| The MedComMessagingHeader resource MAY include a list of carbon-copy receiver organizations pointed to by the MedComMessagingHeader.destination:cc sliced element(s) |
| MedCom FHIR Messages SHALL contain one bundled focused resource pointed to by the MedComMessagingHeader pointed to by the MedComMessagingHeader.focus element |
2.2 Identifiers and Timestamps
Click here to go to Governance for Identifiers
3 MedComMessagingOrganization
An inherited instance profile of MedComMessagingOrganization SHALL follow the generic concept of the MedComMessagingOrganization as outlined here: MedComMessagingOrganization in MedCom Message
This profile describes the Organization resource that SHALL be used in all MedCom FHIR Messages. MedComMessagingOrganization inherits from MedComCoreOrganization as it SHALL include both a SOR and an EAN/GLN identifier. MedComMessagingOrganization SHALL be used to describe the sender and receiver organizations of all MedCom FHIR Messages.
3.1 MedComMessagingOrganization Rules
A MedComMessagingOrganization that is referenced as a “primary” receiver SHALL never be used also to reference a “cc-receiver” in the same FHIRMessage.
A MedComMessagingOrganization that is referenced as either a “primary” receiver or a “cc-receiver” MAY be used to reference organization entities used otherwhere in a FHIRMessage.
A MedComMessagingOrganization SHALL include both a SOR and an EAN/GLN identifier.
A MedComMessagingOrganization MAY include more identifiers. These Identifiers **SHOULD NOT** be expected to introduce application logic for the receiver(s) of the FHIRMessage.
3.2 MedComMessagingOrganization Links
4 MedComMessagingProvenance
The Provenance resource tracks information about the activity what was created, revised, or deleted, while referencing the current message and previous messages if such exist. To identify the actual content of the message and time of activity, it is important to look in the resources carrying the clinical content, such as the Encounter for the HosptialNotification standard, and the Communication for the CareCommunication standard.
4.1 MedComMessagingProvenance Rules
- MedCom FHIR Messages SHALL contain at least one bundled MedComMessagingProvenance resource
- MedCom FHIR Messages SHALL contain one bundled MedComMessagingProvenance resource for each message exchange the message has been involved in
- MedCom FHIR Messages SHALL contain no more than two bundled MedComMessagingProvenance resource when acknowledging a message
4.2 MedComMessagingProvenance Links
5 MustSupport
Unless otherwise stated, the following criteria apply to elements marked as “Must Support” in MedCom’s Implementation Guides:
Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide “support” for the element in some meaningful way, and is therefore a part of a standard. Because the base FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as mustSupport=true as part of the base specification. This flag is intended for use in profiles that have a defined implementation context.
5.1 MustSupport Rules
In MedCom FHIR Messaging MustSupport requires that a system provides “support” for the element in some meaningful way. A meaningful way depends on the type of information, which will be expressed for each standard.
For technical profiles
Systems receiving or consuming a resource instance:
MUST be able to process the field’s content when it is present MUST process the content according to the rules defined for the profile MUST NOT fail when the value is not present.
Systems sending or creating a resource instance
SHOULD populate the element when the information is available MUST populate the element according to the rules defined for the profile
For Logical Models Functional Analysis MUST consider the data element as defined
“Must Support” elements that are used in an implementation MUST inherit the behaviour and constraints defined for the data element “Must Support” elements not needed in a particular implementation MAY be excluded from implementation but such exclusion MUST be described Derived implementations SHOULD inherit the field’s “Must Support” flag
5.2 MustSupport Links
| Links for MustSupport |
|---|
| Detailed specification for MustSupport in FHIR R4 |
6 Narrative Texts
The narrative text contains sufficient detail to make it “clinically safe” for a human to just read the narrative.
The narrative text SHALL encode all the structured data pointed out by the ∑-symbol in combination with MustSupport. Elements only marked with the ∑-symbol, and not MustSupport are not expected to be a part of the narrative text.
Each resource, beside the MedComMessagingMessage, SHALL contain a narrative text in the element text, eventhough this element is not marked with MS or has a minimum cardinality of 1.
Narratives contain two sub elements, status and div.
6.1 The status element
In MedCom FHIR Messages the status SHALL always be “generated” meaning that the narrative is generated from elements with ∑-symbol and MustSupport, or “extension” meaning that in addition to “generated”, it is including extensions.
A narrative in MedCom FHIR Messages SHALL NEVER be of code: empty.
6.2 The div element
The contents of the div element are XHTML fragments that SHALL contain only the basic HTML formatting elements described in chapters 7-11 (except section 4 of chapter 9) and 15 of the HTML 4.0 standard, ‘’ elements (either name or href), images and internally contained style attributes.
The XHTML content SHALL NOT contain a head, a body element, external stylesheet references, deprecated elements, scripts, forms, base/link/xlink, frames, iframes, objects or event related attributes (e.g. onClick).
If a resource includes a base-64-encoded attachment, this SHALL NOT be included in the narrative text, as it will cause the size of the message to increase rapidly.
6.3 General Narrative Text Rules
- All resources in a MedComMessagingMessage SHALL contain a Narrative Text defined by the [resource].text element.
- The Narrative Text SHALL have a status with value “generated” or “extensions”.
- The Narrative Text SHALL include elements marked with ∑-symbol in combination with MustSupport.
- The Narrative Text SHALL NOT include base-64-encoded attachments.
6.4 Links for Narrative Text
| Links for Narrative Text |
|---|
| Narrative Text description in FHIR R4 |
| NarrativeStatus in FHIR R4 |
| Styling the XHTML in FHIR R4 |
About
Support or contact
MedCom is responsible for this page. If you have any questions regarding this page, please contact fhir@medcom.dk or write to MedComs stream on Zulip.Version of this documentation
The version of this documentation is: Version 1.0.10 You can finde the release note of the version here."FHIR® is the registered trademark of HL7 and is used with the permission of HL7. Use of the FHIR trademark does not constitute endorsement of this implementation guide by HL7, nor affirmation that this content is conformant to the various applicable standards"