DK MedCom HospitalNotification
3.0.1 - Release
DK MedCom HospitalNotification
3.0.1 - Release
This page is part of the DK MedCom HospitalNotification (v3.0.1: Release) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions 
| Official URL: http://medcomfhir.dk/ig/hospitalnotification/ImplementationGuide/medcom.fhir.dk.hospitalnotification | Version: 3.0.1 | |||
| Active as of 2023-03-02 | Computable Name: MedComHospitalNotification | |||
This implementation guide (IG) is provided by MedCom to describe the use of FHIR ®© in message based exchange of data in Danish healthcare.
The IG contains profiles for MedCom HospitalNotification (Dansk: Sygehusadvis), which is used to inform a municipality about hospitalization of a patient. The HospitalNotification contributes to securing the foundation for a coherent clinical pathway across sectors. The specific purpose of the HospitalNotification is to inform the citizen’s current care and health provider in the primary sector about the start and end of the citizen’s stay at the hospital. It makes it possible to pause the current care and health providers’ services during the hospital stay and resume them when it ends. At the same time, the HospitalNotification can trigger the automatic sending of Report of Admission (XDIS16) from the receiver’s system, which gives the health professionals an overview of the citizen’s current services, level of function and health-related problems. The HospitalNotification also contains notification of the patient’s leave from the hospital stay and acute ambulant care.
Profiles used in HospitalNotification are not as open as other profiles because the message is automatically sent and thus not based on a patient consent. The legislation permits this exchange, but the message shall not contain more information than necessary.
More information about the clinical guidelines and legislation can be found here.
The following diagram depicts the structure of the HospitalNotification message.
The HospitalNotification message follows the general MedCom FHIR messaging structure, except that the carbon-copy destination is not allowed. The following sections describe the overall purpose of each profile.
The MedComHospitalNotificationMessage profile constrains the MedComMessagingMessage to further use the MedComHospitalNotificationMessageHeader and to require exactly one patient resource in the message. Furthermore, it constrains the Provenance.activity to contain only activities from the MedComHospitalNotificationMessageActivities ValueSet.
All referenced resources within the message shall be contained in the entry list in MedComHospitalNotificationMessage.
The MedComHospitalNotificationMessageHeader profile constrains the MedComMessagingMessageHeader further to specify the fixed coding for this message and require a focus of the message to be a MedComHospitalNotificationEncounter.
The MedComHospitalNotificationEncounter profile contains the main clinical content of the message. It constrains the MedComCoreEncounter further to require a episodeOfCare-identifier and restricts the status and class to ValueSet of relevant values. The start time of the encounter and a reference to the service provider organization are also mandatory. Most other values are disallowed due to the legislation.
The MedComMessagingProvenance profile is used to track information about the activity of the notification, e.g. if the message describes a ‘start hospital stay - inpatient’ or ‘end leave’. The allowed activity codes for a HospitalNotification message can be found in MedComHospitalNotificationMessageActivityCodes ValueSet on the Terminology IG.
In cases of a previously sent HospitalNotification message, MedComMessagingProvenance references the lateste message which makes it possible to create a historic overview of the admission.
The MedComCorePatient profile is used in a HospitalNotification message. However, a HospitalNotification message may only be exchanged for patients with an official Danish civil person register (CPR)-number.
The MedComCoreOrganization profile is used in a HospitalNotification message to describe the serviceprovider organisation, which is the organisation responsible for the patient’s admission.
The MedComMessagingOrganization profile is used in a HospitalNotification message to describe the sender and primary receiver of the notification. Please notice, that carbon-copy receiver is not allowed in a HospitalNotification message.
HospitalNotification messages are generated and sent based on real-time registration in the EPR/PAS system. In case the EPR allows future registrations of planned contacts or a period of leave, the HospitalNotifications shall only be triggered when the event occurs, i.e. at the patient’s physical attendance, as described in the Clinical guidelines for application.
The HospitalNotification message contains several timestamps. These timestamps are present in the profiles MedComHospitalNotificationEncounter, MedComHospitalNotificationMessage and MedComMessagingProvenance and have different purposes:
All profiles 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 HospitalNotification message. Throughout this section different activity codes and statuses are used. To get an overview of all the codes and statuses, please go to GitHub pages for HospitalNotification.
In the sections below is a limited number HospitalNotifications simplified examples. More examples of a HospitalNotification message can be found here. For examples of a profile, take a look under the tab ‘Examples’ on the site for the given profile.
Please notice, that in the following examples is the resources listed as an array. This is just an example of an order, resources may be listed in any order.
The simplified example below is an example of a ‘Start hospital stay - admitted’ HospitalNotification. In the MessageHeader there is a request for a reportOfAdmission (extension:reportOfAdmissionFlag). In the Encounter instance the status is ‘in-progress’, and the Encounter is populated with a start timestamp (period.start). In the Provenance instance is the activity code ‘admit-inpatient’. The sender and serviceProvider organisation is the same.
Click here to see the generated example of simplified example number 1.
The simplified example below is an example of a ‘Start leave’ HospitalNotification which is sent in continuation of simplified example number 1. The status in the Encounter is changed from ‘in-progress’ to ‘onleave’, and the Encounter is populated with a start timestamp for the period of leave (extension:leavePeriod.start). In the Provenance instance is the activity code ‘start-leave-inpatient’. The sender and serviceProvider organisation is the same.
Click here to see the generated example of simplified example number 2.
The simplified example below is an example of a ‘End leave’ HospitalNotification which is sent in continuation of simplified example number 2. The status in the Encounter is changed from ‘onleave’ to ‘in-progress’, and the Encounter is populated with a end timestamp for the period of leave (extension:leavePeriod.end). In the Provenance instance is the activity code ‘end-leave-inpatient’. The sender and serviceProvider organisation is the same.
Click here to see the generated example of simplified example number 3.
The simplified example below is an example of a ‘End hospital stay - patient completed to home/primary sector’ HospitalNotification which is sent in continuation of simplified example number 1. The status in the Encounter is changed from ‘in-progress’ to ‘finished’, and the Encounter is populated with a timestamp indicating end of the encounter (period.end). In the Provenance instance is the activity code ‘discharge-inpatient-home’. The sender and serviceProvider organisation is the same.
Click here to see the generated example of simplified example number 4.
The simplified example below is an example of a ‘Deceased’ HospitalNotification which is sent in continuation of simplified example number 1. The status in the Encounter is changed from ‘in-progress’ to ‘finished’, and the Encounter is populated with a timestamp indicating end of the encounter (period.end) i.e. the death of the patient. The element Patient.deceased is sat to ‘true’, indicating that the patient is deceased. In the Provenance instance is the activity code ‘admit-inpatient’, as it shall remain the current activity. The sender and serviceProvider organisation is the same.
Click here to see the generated example of simplified example number 5.
The simplified example below is an example of a ‘Cancellation Start hospital stay - admitted’ HospitalNotification which is sent in continuation of simplified example number 1. In the Provenance instance the activity code is changed to ‘cancel-admit-inpatient’ and the entity.what is now ‘removal’ indicating that the previous message is cancelled. The sender and serviceProvider organisation is the same.
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. This is currently reflected in MedComHospitalNotificationMessage, MedComHospitalNotificationMessageHeader and MedComHospitalNotificationEncounter which all inherits from profiles defined in MedComCore or MedComMessaging IG. Further, it is reflected in references to MedComCorePatient, 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 HospitalNotification 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.
