This specification conforms to FHIR®© R4
Introduction to the technical specification
Table of contents
- 1 Profiles in the HospitalNotification Standard
- 2 Internal References in a HospitalNotification Message
- 3 Examples in a HospitalNotification Message
-
4 Timestamps in HospitalNotification message
Note: In case of discrepancies between the MedCom HospitalNotification Implementation Guide (IG) and this page, it is the IG which should be followed. Please contact fhir@medcom.dk if you find discrepancies.
1 Profiles in the HospitalNotification Standard
In total, seven profiles from MedCom Core IG, MedCom Messaging IG and MedCom HospitalNotification IG constitute the HospitalNotification standard. A short description of each profile can be seen in the Table 1.
| Profile | Resource | Description | MustSupport elements | Implementation Guide Origin |
|---|---|---|---|---|
| MedComHospitalNotificationMessage | Bundle | Acts as a container for the content of the message. The type of the Bundle shall always be 'message'. This profile inherits from MedComMessagingMessage. |
Id Type Timestamp Entry |
HospitalNotification |
| MedComHospitalNotificationMessageHeader | MessageHeader | The header of a message, which shall 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, the content of the message and request for report of admission. This profile inherits from MedComMessagingMessageHeader. |
Id ReportOfAdmissionFlag ReportOfAdmissionRecipient Event[x]:eventCoding Sender Organization Receiver Organization Source (Receiver of the Acknowledgement) Focus |
HospitalNotification |
| MedComHospitalNotificationEncounter | Encounter | A meeting between a healthcare professional and a patient. In a HospitalNotification message the start time of the encounter represents the hospitalization of the patient. This profile inherits from MedComCoreEncounter |
Id Status class Subject EpisodeOfCare identifier Period start (start time of the encounter) Period end (end time of the encounter) ServiceProvider organization |
HospitalNotification |
| MedComCorePatient | Patient | Describes a citizen or patient, when exchanging a MedCom message. | Id identifier (CPR-number) Name Address Telecom Deceased[x] |
Core |
| MedComCoreOrganization | Organisation | Contains information which is useful in order to identify an organisation. In a HospitalNotification message it is often used to describe the serviceProvider organisation or department. | Id Identifier (SOR-id) Name |
Core |
| MedComMessagingOrganization | Organisation | Contains information which is useful in order to identify a sender or receiver organisation. This profile inherits from MedComCoreOrganization. |
Id Slices for identifier (SOR-id) Slices for identifier (EAN/GLN-id) Name |
Messaging |
| MedComMessagingProvenance | Provenance | Describes the activity of a message, e.g. whether the message concern an inpatient admission or discharge. In cases of a previously send message concerning the same admission, the Provenance resource holds a reference to the previous message. Thereby it is possible to get an overview of the patient's admission. | Id Target OccurredDateTime Timestamps Activity Agent Entity (Reference to the previous message) |
Messaging |
1.1 ServiceProvider and Sender
The serviceProvider is the organisation or department in charge of the patients admission, whereas the sender is the organisation or department responsible for sending the HospitalNotification message. The sender of a HospitalNotification and the serviceProvider may be the same hospital department, hence be represented referencing the same instance of a Organization resource, which in this case shall be a MedComMessagingOrganization. However, the sender organisation may be a higher-level deparment (in the SOR-register) than the serviceProvider, and in this case they shall be represented referencing two different instances of a Organization resource.
1.2 Report of admission
The request for a report of admission must be sent when a patient is initially admitted, meaning that the type of HospitalNotification is STIN og STAA. In these cases, the Provenance.activity.code is admit-inpatient or admit-emergency, respectively. A request for a report of admission shall not be send when the patient returns from leave (SLOR) or is relocated from another hospital.
On page 10 in the use case document the usage of the report of admission flag is further described. Click here to finde the use cases.
2 Internal References in a HospitalNotification Message
The HospitalNotification message follows MedCom’s generic messaging model.
The references between the profiles are shown in Figure 1 below. The MedComHospitalNotificationMessage profile acts as the container which includes the other profiles. From the MedComHospitalNotificatiomMessageHeader are the sender, receiver and carbon-copy organisation referenced as the MedComMessagingOrganization together with the focus of the message, which is the MedComHospitalNotificationEncounter profile. This encounter must always reference a subject of the type MedComCorePatient. Additionally, the patient’s service provider organisation is also referenced from the encounter.
MedComMessagingProvenance is used to keep track of the messaging history and define the activity of the notification. The provenance both references the MedComMessagingMessageHeader as the target and the actor in terms of a MedComMessagingOrganisation.
3 Examples in a HospitalNotification Message
Examples in section 3.1 to 3.6 illustrates different types of HospitalNotifications. For each example, the type of HospitalNotification can be seen in the associated headline. In the examples the serviceProvider and sender organisation is represented by the same Organization instance. Further, the instances in the examples are in the same order to create a better overview, however IT vendors cannot assume any specific order of the instances in a message.
Click here to get an overview of the HospitalNotification types.
On Figure 2 to Figure 7, the required content of a HospitalNotification message is illustrated. There is a difference between the required elements and MustSupport elements, as the required elements always shall be included in a message. However, 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.
Click here to see examples in in XML and JSON for MedCom HospitalNotificationMessage
On Figure 2, only one instance of the Provenance recource is included, since only one HospitalNotification has been sent. On Figure 3 to Figure 7, two or more in instance of the Provenance recource, to reference the previously sent HospitalNotifications as well as the instance representing the current HospitalNotfication.
3.1 STIN - Start hospital stay - admitted
On Figure 2, a simplified example of a ‘Start hospital stay - admitted’ HospitalNotification is presented. 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 the activity code is ‘admit-inpatient’.
3.2 STOR - Start leave
On Figure 3, a simplified example of a ‘Start leave’ HospitalNotification is presented, which is sent in continuation of the simplified example in Figure 2. 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 current Provenance instance the activity code is ‘start-leave-inpatient’.
3.3 SLOR - End leave
On Figure 4, a simplified example of a ‘End leave’ HospitalNotification is presented, which is sent in continuation of the simplified example in Figure 3. 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 current Provenance instance the activity code is ‘end-leave-inpatient’.
3.4 SLHJ - End hospital stay - patient completed to home/primary sector
On Figure 5, a simplified example of a ‘End hospital stay - patient completed to home/primary sector’ HospitalNotification is presented, which is sent in continuation of the simplified example in Figure 2. 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 current Provenance instance the activity code is ‘discharge-inpatient-home’.
3.5 MORS - Deceased
On Figure 6, a simplified example of a ‘Deceased’ HospitalNotification is presented, which is sent in continuation of the simplified example in Figure 2. 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 current Provenance instance the activity code is ‘admit-inpatient’, as it shall remain the current activity.
3.6 AN_STIN - Cancellation Start hospital stay - admitted
On Figure 7, a simplified example of a ‘Cancellation Start hospital stay - admitted’ HospitalNotification is presented, which is sent in continuation of the simplified example in Figure 2. In the current Provenance instance the activity code is changed to ‘cancel-admit-inpatient’ and the entity.what is ‘removal’ indicating that the previous message is cancelled.
4 Timestamps in 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:
- Encounter-timestamps represent the time of an event. For receiving systems, this is the timestamps that must be displayed for the end user as ‘date and time of start/end for the event’. The usage of these timestamps is more thoroughly described in the IG on the page for the MedComHospitalNotificationEncounter profile.
- Bundle.timestamp represents the time bundle is generated.
- Provenance.occuredDateTime[x] represents the time the HospitalNotification is sent, in a human-readable time
- Provenance.recorded represents the time the HospitalNotification is sent, in a machine-readable time
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 MedComs stream on Zulip.Version of this documentation
The version of this documentation is: Version 3.0.7 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"