Logo

This specification conforms to FHIR®© R4

MedCom FHIR®© LandingPage

Introduction to the technical specification

Table of contents

1 Profiles in the CareCommunication Standard

In case of any discrepancies between the MedCom CareCommunication IG and this page, the IG page should be followed. Please contact fhir@medcom.dk if you find any discrepancies.

There is a difference between the required elements and MustSupport elements, as the required element always shall be included in a message. MustSupport elements must be included if they are present in the sender’s system, and the receiver must be able to handle the information if it is included in a message.

Table 1: Overview of the profiles in the CareCommunication standard
Profile Resource Description MustSupport elements Implementation Guide Origin
MedComCareCommunicationMessage Bundle Acts as a container for the content of the message
Inherited from the MedComMessagingMessage		 Id
Type
Timestamp
Entry
 CareCommunication
MedComCareCommunicationMessageHeader MessageHeader The header of a MedComCareCommunication message, which must always be the first referenced profile, when the type of the bundle is 'message'.This profile holds references to the fundamental information in a message, such as sender, receiver, and the content of the message in terms of the CareCommunication profile.
Inherited from MedComMessagingMessageHeader		 Id
Text
Event[x]:eventCoding
Destination:primary
Destination:primary.use
Destination:primary.endpoint
Destination:primary.receiver
Sender
Source
Source.endpoint
Focus		 CareCommunication
MedComCareCommunication Communication The MedComCareCommunication profile contains the main content of the message in form of a message segment. A message segment consists of the textual part (payload:string.content[x]) and a signature which includes an author (payload:string.extension.author), a timestamp (payload:string.extension:date) and a relevant telephone number (payload:string.extension.authorContact), or an attachment (payload:attachment.content[x]). The message must include a category code (category) and it may include a topic (topic) that supports and elaborates the category.
Further, it is possible to include an episodeOfCare-identifier, by referencing an Encounter resource (encounter).
A more specific sender and recipient of the message may be referenced from the elements recipient and extension.sender.		 Status
Category
Priority
Subject
Topic
Encounter
Sent (dateTime)
Recipient
Extension.sender
Slices for payload
payload:string.content[x]
payload:string.extension:author
payload:string.extension:authorContact payload:string.extension:date payload:string.identifier
payload:attachment.content[x]
payload:attachment.identifier
 CareCommunication
MedComCorePatient Patient Describes a citizen or patient in which the communication concerns when exchanging a CareCommunication. Id
Identifier(CPR-number)
Name
Address
Telecom
Deceased[x]		 Core
MedComCorePractitioner Practitioner Describes a healthcare professional or another actor involved in citizen or patient care. This profile is used to describe the author and sender or recipient.

MedComCorePractitioner is inherited from the DkCorePractitioner, and must include a name of the practitioner if available.
Name Core
MedComCorePractitionerRole PractitionerRole Describes the role of a healthcare professional or another actor involved in citizen or patient care. This profile is used to describe the author role and sender or recipient. Practitioner
Organization		 Core
MedComCoreEncounter Encounter Describes the interaction between a patient and one or more healthcare providers. The Encounter holds the episodeOfCare-identifier. Status
Class
Subject
episodeOfCare-identifier		 Core
MedComCoreCareTeam CareTeam Describes one or more professionals who plan to participate in the coordination and delivery of care for a patient or citizen. It may be used as the sender or recipient from the MedComCareCommunication profile Name
ManagingOrganization		 Core
MedComMessagingOrganization Organisation Contains information which is useful to identify a sender or receiver organisation. It is primarily used for transportation matters, why it must contain a SOR and EAN identifier. This profile inherits from MedComCoreOrganization. Id
Identifier(SOR-id)
Identifier(EAN-id)
Name		 Messaging
MedComMessagingProvenance Provenance Describes the activity of a message, e.g. if the message is a new message or a modified message.
In case of a previously sent message, the Provenance resource holds a reference to this message.
Therefore, it is possible to get an overview of the communication about a patient.		 Id
Target
OccurredDateTime
Timestamps
Activity
Agent
Entity (reference to the previous message)		 Messaging
MedComCoreOrganization Organization Contains information about an organization. The Organization is referenced from Practitioner or CareTeam. Id
Identifier(SOR-id)
Name		 Core

1.1 Sender and recipient

In a CareCommunication, it is required to include information about a sender and receiver in terms of a reference to a MedComMessagingOrganization. This information is primarily used for transportation matters and will always include an EAN and SOR identifier.

When sending a CareCommunication, it is possible to add a more specific receiver of the message, called a recipient, and a more specific sender. This may be used to include a more specific group of people or a person related to the care, and wellbeing of the patient or citizen can be referenced. An example could be to address a specific general practitioner by name, a specific care team in a municpality or eventually a specific social unit within the social care sector in a municipality.

1.2 Categories and the use of priority

There is a nationally agreed list of categories that must be used when sending a CareCommunication.
The list of categories can be seen here.
When a category is of the type ‘regarding-referral’ it is allowed to add a priority, which can be ‘asap’ or ‘routine’. When the category ‘other’ is chosen, a topic must be included, as this is used to specify the topic of the CareCommunication.

1.3 Encounter and episodeOfCare-identifier

When receiving a message, either CareCommunication or EDIFACT/OIOXML message, there will in many cases be an episodeOfCare-identifier, as it describes the id of the contact. If this is the case, it shall always be included in the response. An Encounter profile contains the possibility to include an episodeOfCare-identifier, that contains this id.

2 Internal references in a CareCommunication

The CareCommunication follows MedCom’s generic messaging model.
The references between the profiles are shown in Figure 1 below. The MedComCareCommunicationMessage profile acts as the container which includes the other profiles. From the MedComCareCommunicationMessageHeader the sender and receiver organisations are referenced as the MedComMessagingOrganization together with the focus of the message, which is the MedComCareCommunication profile. This profile must always reference a subject of the type MedComCorePatient.
MedComMessagingProvenance is used to keep track of the messaging history and define the activity of the communication. The Provenance references the MedComMessagingMessageHeader as the target and the actor in terms of a MedComMessagingOrganization.

Show references between the profiles in an CareCommunication message.
Figure 1: Structure of the CareCommunication.



3 Examples of a CareCommunication

In this section, simplified examples of CareCommunication are presented, which includes:

All types of simplified examples are created as XML or JSON examples in the CareCommunication IG. Click here to see the full examples of a CareCommunication. All systems must be able to receive and display a forwarded, modified or cancellation messages, but it is optional to support sending a forward, modify or cancellation message.

Note: IT vendors cannot assume any specific order of the resources in a message.

Figure 2 is a simplified example of a new message. The MessageHeader references the sender and receiver organisations, both can be found at the bottom of the message. From the last element in the MessageHeader is the focus of the message referenced. This is a reference to the Communication instance, which holds information about the message segment. Information about the author of the message segment is represented in the PractitionerRole and Practitioner instances, which includes the author role and name, respectively. The type of message can be seen in the bottom, where the Provenance.activity.code is ‘new-message’.

Simplified example: New message
Figure 2: Simplified example: New message

Figure 4 is a simplified example of a reply message. This message represents a reply to the message on Figure 2. When replying to a message, a new message segment shall be added to the Communication instance. The reply can be seen in the payload[1], where the new message can be seen in the payload[0]. The author information for both message segments shall also be included in the message. The sender and receiver information has switched place. The message contains two Provenance instance, one from the previous message and one from the reply message, which holds a reference to the previous message.

Simplified example: Reply message
Figure 4: Simplified example: Reply message



Figure 5 is a simplified example of a forward message. This message represents a forwarding of the message on Figure 2. When forwarding shall the user decide which message segment or segments that shall be forwarded, in this case is only one segment selected. The forward message can be seen in the payload[1], where the new message can be seen in the payload[0]. For this reason, does the Communication instance contain two message segment and associated authors. Further shall the message contain two Provenance instance, one from the previous message and one from the forward message, which holds a reference to the previous message.

Simplified example: Forward message
Figure 5: Simplified example: Forward message



Figure 6 is a simplified example of a modify message. This message represents a modification of the message on Figure 2. A modification may be used when correcting a part of the message text, the category and/or topic, or the content of an attachment. The modification message shall contain both the message segment that are being modified from the previous message, as well as a message segment containing the actual modification or describing the modification, e.g. if the category is corrected. Further, shall the message contain two Provenance instance, one from the previous message and one from the modification message, which holds a reference to the previous message.

Simplified example: Modify message
Figure 6: Simplified example: Modify message



Figure 7 is a simplified example of a retract message. This message represents a cancellation of the message on Figure 2. A message shall be cancelled if the CareCommunication has been sent 1) about an incorrect patient CPR-number, 2) to incorrect receiver, and 3) with an attachment included with information about an incorrect patient. When the sender cancels a previously send CareCommunication, the sender shall create a cancellation message. This message shall include two instances of the Communication instance, one with the status ‘entered-in-error’ and a message segment stating the cancellation and one with the status ‘unknown’ representing the message being cancelled, hence including the message segment from the previous sent message. Further does the message contain two Provenance instance, one from the previous message and one from the retraction message, which holds a reference to the previous message.

Simplified example: Retract message
Figure 7: Simplified example: Retract message




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 MedCom's stream on Zulip.

Version of this documentation

The version of this documentation is: Version 3.0.3. You can find 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"