DK MedCom Carecommunication
3.0.0 - release
DK MedCom Carecommunication
3.0.0 - release
This page is part of the DK MedCom CareCommunication (v3.0.0: Release) based on FHIR R4. The current version which supercedes this version is 2.0.0. For a full list of available versions, see the Directory of published versions 
| Official URL: http://medcomfhir.dk/ig/carecommunication/ImplementationGuide/medcom.fhir.dk.carecommunication | Version: 3.0.0 | |||
| Active as of 2023-10-04 | Computable Name: MedComCarecommunication | |||
This implementation guide (IG) is provided by MedCom to describe the use of FHIR ®© CareCommunication (Danish: Korrespondancemeddelelse) in message based exchange of data in Danish healthcare.
This IG contains profiles for MedCom CareCommunication. The purpose of a CareCommunication is to support digital communication between parties within healthcare, including amongst others the psychiatric and social area. The CareCommunication is used to ensure secure electronic communication of personally identifiable information and is most often used for ad hoc communication. However, the CareCommunication shall only be used in areas where no other MedCom standard is available, and it must not be used for cases with an acute nature. The CareCommunication supports:
More information about the clinical guidelines for applications can be found here.
The structure of a CareCommunication is depicted on the following diagram:
CareCommunication follows the general MedCom FHIR messaging model, except that the carbon-copy destination is not allowed to use. The following sections describe the overall purpose of each profile.
The MedComCareCommunicationMessage is a constraint of MedComMessagingMessage further to use the MedComCareCommunicationMessageHeader and to require exactly one MedComCorePatient resource in the message. Furthermore, it contains rules that constrains the ValueSet of activities in the MedComMessagingProvenance profile to only contain activities from the MedComCareCommunicationMessageActivities ValueSet, which contains activities such as new-message, forward-message, and other activities triggering the message.
All referenced resources within the message shall be contained in the entry list in MedCom CareCommunication.
The MedComCareCommunicationMessageHeader constrains the MedComMessagingMessageHeader further to specify the fixed coding for this message and require a focus reference to a MedComCareCommunication profile.
The MedComCareCommunication profile contains the main content of the message. It based on the Communication resource. MedComCareCommunication profile shall include a category code as defined in the MedComCareCommunicationCategories ValueSet and it is allowed to add a topic of the message which may be in free text or from a regionally agreed list of topics that supports and elaborates the category.
The profile also includes one or more message segment that consists of a message text and associated signature or an attachment. In MedComCareCommunication profile message segments can be found under the element Communication.payload. A CareCommunication shall always include a message segment with a message text and associated signature. A CareCommunication may include zero or more message segments with an attachment. Click here for more information about message segments
Further, It is possible to add a more specific receiver, called recipient, and a more specific sender of a message. These can be found in the MedComCareCommunication profile. This may be used to include a more specific group of professionals or practitioner related to the care and wellbeing of the patient or citizen. An example could be to address a specific general practitioner by name, a specific hospital department or eventually a specific social unit within the social care sector in a municipality. Click here for more information about sender and recipient.
The MedComCorePatient profile is used in a CareCommunication. It is preferred that a CareCommunication is being sent for a patient with an official Danish civil registration number (CPR)-number. In cases where a CPR-number is not known, a replacement CPR-number (Danish: Erstatnings-CPR) shall be included.
The MedComCorePractitionerRole and MedComCorePractitioner profiles are used to describe the author in the signature of a message text by name and role (Danish: Stillingsbetegnelse). The MedComCorePractitionerRole is referenced from the MedComCareCommunication profile and MedComCorePractitionerRole includes a reference to the MedComCorePractitioner, why both profiles are shown on Figure 1.
The MedComMessagingOrganization profile is used in a CareCommunication to describe the sender and primary receiver of the notification. Please notice, that carbon-copy receiver is not allowed in a CareCommunication. Both the sender and receiver shall be identified using a SOR- and EAN-identifier.
The MedComMessagingProvenance profile is used to track information about the activity of the communication, e.g. if the message describes a ‘new-message’ or ‘reply-message’. The allowed activity codes for a CareCommunication can be found in MedComCareCommunicationMessageActivityCodes ValueSet on the Terminology IG.
In cases of a previously sent CareCommunications, MedComMessagingProvenance references the metadata of the latest message which makes it possible to create a historic overview of the admission.
A CareCommunication includes several timestamps. These timestamps are present in the profiles MedComCareCommunication, MedComCareCommunicationMessage, and MedComMessagingProvenance and have different purposes:
It is assumed that in most cases, the above mentioned timestamps will be equal, as the events happpens instantly after eachother. However, there might be systems where the sending is delayed compared to the real world-event and bundle generation, hence will the Provenance timestamps differentiate from the Communication and Bundle timestamp.
It is optional to include the timestamp: Communication.payload:attachment.content[x]:contentAttachment.creation, which represents the date and time the attachment was created. Click here for more information about this timestamp.
All instances of a profile shall have a global unique id by using an UUID. Read more about the use of ids here.
The simplified examples contain the required content of a CareCommunication sent between organisations.
Below can a simplified example of a new CareCommunication be seen with the minimum requirements. Since the example is a new message is the activity in the Provenance instance ‘new-message’. The sender and receiver organisations are both referenced from the MessageHeader and are included in the message, and the Communication.status is unknown.
Click here to see the generated example of simplified example number 1.
This simplified example describes how a reply to a CareCommunication shall be handled. When sending a reply to a received CareCommunication the reply shall contain the message segment(s) including message text, and the Provenance instance(s) from the previous message shall be included. The Provenance.entity.role shall be revision and Provenance.entity.what.reference shall contain a reference to the MessageHeader.id of the previous message as the reply is the based on a previous entity. Provenance.activity shall be reply-message, and the Communication.status is unknown. This is a reply to ‘1 - Simplified example of a new CareCommunication’.
Click here to see the generated example of simplified example number 2.
It is allowed to answer a received MedCom EDIFACT or OIOXML message with a MedCom CareCommunication. The Provenance.entity.what.identifier shall contain a reference to the received OIOXML. The reference shall contain the locationnumber and letter identifier, divided by #. If the message being replied contains an episodOfCareIdentifier, this shall be included in the CareCommunication message.
Click here to see the generated example of a reply to an OIOXML message.
This simplified example describes how to forward a CareCommunication.
When forwarding a received CareCommunication the forward message shall contain both the message segment(s) that are being forwarded, as well as a message segment describing the reason for the forwarding. Further the message contains the instance(s) of the Provenance resource from the previous message.
The Provenance.entity.role shall be revision and Provenance.entity.what.reference shall be a reference to the MessageHeader.id of the previous message. Provenance.activity shall be forward-message. This message is forwarding ‘1 - Simplified example of a new CareCommunication’.
Click here to see the generated example of simplified example number 3.
Note: All systems must be able to receive and display forwarded messages, but it is optional to support forwarding of a message.
If the sender wants to modify a previously send CareCommunication, the sender shall create a modification message. A modification may be used when correcting a part of the message text, the category and/or topic, the content of an attachment, author information or episodeOfCare-identifier. 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.
There shall be a Provenance instance referencing the message being modified, and a Provenance instance referencing the modification message, where Provenance.entity.what.reference element points to the MessageHeader.id of the previous message. In the latter instance of the Provenance resource, Provenance.entity.role shall be revision and the Provenance.activity shall be modify-message.
Click here to see the generated example of simplified example number 4.
Note: All systems must be able to receive and display modified messages, but it is optional to support sending modify message.
If the sender wants to cancel a previously send CareCommunication, the sender shall create a cancellation message. 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. This message shall include two instances of the Communication resource, one with the status entered-in-error and a message segment stating the reason for the cancellation and one with the status unknown representing the message being cancelled, hence including the message segments from the previous sent message. There shall be a Provenance instance referencing to the message being cancelled, and a Provenance instance referencing the cancellation message, where Provenance.entity.what.reference element points to the message being cancelled. In the latter instance of the Provenance resource, the Provenance.entity.role shall be removal and the Provenance.activity shall be retract-message.
Click here to see the generated example of simplified example number 5.
In a cancellation message a reason for the cancellation must be included. It is recommended that display texts from the CodeSystem MedComMessagingCancellationReason are included in the message segment of the Communication resource with the status entered-in-error.
Note: All systems must be able to receive and display cancellation messages, but it is optional to support sending cancel message.
On MedCom Terminology IG all referenced CodeSystem and ValueSets developed by MedCom can be found.
This IG has a dependency to the MedCom Core IG, MedCom Messaging IG and DK-core v. 2.0.0, where the latter is defined by HL7 Denmark. These dependencies are currently reflected in MedComCareCommunicationMessage, and MedComCareCommunicationMessageHeader which both inherits from profiles defined MedComMessaging IG. Further, it is reflected in references to MedComCorePatient, MedComCoreEncounter, MedComCoreOrganization and MedComMessagingOrganization.
Content in this IG can be downloaded in npm format under Download. This can be used to validate locale FHIR profiles against.
On the introduction page for CareCommunication the following documentation can be found:
MedComs FHIR profiles and extension are managed in GitHub under MedCom: Source code
A description of governance concerning change management and versioning of MedComs FHIR artefacts, can be found on the link.
In the Quality Assurance report (QA-report) for this IG, there is an error with the following description: Reference is remote which isn’t supported by the specified aggregation mode(s) for the reference (bundled). The error occurs when creating instances of the profiles and is due to some elements having a Bundled flag {b}, however the referenced profile is not included in a Bundle in an instance, since the instance only represents a part of the entire message. This should not influence the implementation by IT-vendors.
MedCom is responsible for this IG.
If you have any questions, please contact fhir@medcom.dk or write to MedCom’s stream in Zulip.
