DK MedCom Carecommunication
4.0.2 - release
DK MedCom Carecommunication
4.0.2 - release
DK MedCom Carecommunication, published by MedCom. This guide is not an authorized publication; it is the continuous build for version 4.0.2 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/medcomdk/dk-medcom-carecommunication/ and changes regularly. See the Directory of published versions
| Official URL: http://medcomfhir.dk/ig/carecommunication/ImplementationGuide/medcom.fhir.dk.carecommunication | Version: 4.0.2 | |||
| Active as of 2024-12-12 | 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 retract-message, modified-message and the carbon-copy destination is not allowed to be used. 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 the activities new-message, reply-message and forward-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 MedComCareCommunicationProvenance profile is used to track information about the activity of the communication, e.g. if the message describes a 'new-message' or 'reply-message'. Activity codes can be found in MedComCareCommunicationMessageActivityCodes ValueSet on the Terminology IG. Note that all not activity codes are allowed for a CareCommunication. The allowed activity codes are: new-message, reply-message and forward-message.
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 examples page illustrates a flow of CareCommunications sent between healthcare parties. This includes new message, replies and forwarded messages.
Additionally, does the page references new messages containing different type of content such as attachments, sender and recipient, priority, deceased patient and more.
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.