DK MedCom Carecommunication
2.0.0 - Release
DK
DK MedCom Carecommunication
2.0.0 - Release
DK
This page is part of the DK MedCom CareCommunication (v2.0.0: Release) based on FHIR R4. This is the current published version. 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: 2.0.0 | |||
| Active as of 2022-11-24 | Computable Name: MedComCarecommunication | |||
This implementation guide (IG) is provided by MedCom to describe the use of FHIR ®© CareCommunication (Danish: Korrespondancen) 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 constrains the 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 defines 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 or an attachment and a signature. In MedComCareCommunication profile message segments can be found under the element payload. A CareCommunication shall always include a message segment with a message text and it may include zero or more message segments with an attachment.
In the MedComCareCommunicationMessageHeader profile it is required to include information about a sender and receiver in terms of a reference to a MedComMessagingOrganization. This information is used for transportation matters and will always include an EAN- and SOR-identifier.
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. Both sender and recipient reference a MedComCoreCareTeam and MedComCorePractitionerRole, where the MedComCorePractitionerRole shall reference a MedComCorePractitioner. Common for both references is that a name of the careteam or practitioner shall be included and there shall be a reference to sender or receiver organisation defined in the MedComCareCommunicationMessageHeader, in order to identify to which organisation the careteam or practitioner belongs.
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 segment 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 that represent different events before during sending a CareCommuncation. The meaning and use of these timestamps are described here.
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 two simplified examples of a new CareCommunication be seen, one with the minimum requirements and one with the minimum reqiurements as well as an attachment, episodeOfCare-identifier, sender, and recipient. Since both examples represents 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. All instances have a unique UUID and the Communication.status is unknown.
When a CareCommunication is a new message, reply message or forward message it is possible to add an attachment in a message segment. In the simplified example number 2 is the sender and recipient both represented with an instance of the CareTeam resource. Each team described with a CareTeam resource shall work in the organisation who sends or receives the CareCommunication. The episodeOfCare-identifier is also represented in the Encounter resource.
Click here to see the generated example of simplified example number 1. Click here to see the generated example of simplified example number 2.
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 and the Provenance instance from the previous message shall be included. The Provenance.entity.role shall be revision and Provenance.entity.identifier shall be 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. All instances have a unique UUID 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 3.
It is allowed to answer MedCom CareCommunication is sent based on a received MedCom OIOXML message. The Provenance.entity.what.identifier shall contain a reference to the received OIOXML. The reference shall contain the locationnumber and letter identifier, divided by #.
This simplified example describes how to forward a MedCom FHIR CareCommunication shall be handled.
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 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 4.
If a message a is modified by the sender of the previous message, it shall happen by creating another new CareCommunication. This message shall include two instances of the Communication resource, one with the status entered-in-error and a message segment stating the modification and one with the status unknown representing the message being modified, hence including the message segment from the previous sent message. The ID of the modified message is updated, since the reference to the patient and author are updated to avoid multiple instances with the same information. There shall also be two Provenance instances, one referencing to the message being modified the and one referencing to the modification message, where Provenance.entity.what.reference element points to the message being modified. In the latter instance of the Provenance resource, shall 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 5.
If a message a is sent by mistake, the message shall be cancelled by creating another MedCom CareCommunication. This message shall include two instances of the Communication resource, 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. The ID of the cancelled message is updated, since the reference to the patient and author are updated to avoid multiple instances with the same information. There shall also be two Provenance instances, one referencing to the message being cancelled the and one referencing to the cancellation message, where Provenance.entity.what.reference element points to the message being cancelled. In the latter instance of the Provenance resource, shall 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 6.
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.
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.
