DK MedCom acknowledgement
2.0.1 - Release
DK MedCom acknowledgement
2.0.1 - Release
This page is part of the DK MedCom Acknowledgement (v2.0.1: 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/acknowledgement/StructureDefinition/medcom-messaging-acknowledgementHeader | Version: 2.0.1 | |||
| Active as of 2023-03-10 | Computable Name: MedComAcknowledgementMessageHeader | |||
A resource that describes a reponse to a message that is exchanged as a MedCom messgage within Danish healthcare
This profile is used as the MessageHeader resource for the MedCom Acknowledgement message. Constraint and rules from MedComMessagingMessageHeader is inherited to this profile. However, does MedComAcknowledgementMessageHeader not allow for a receiver of the type carbon-copy and the profile requires a response code. This code includes information about the delivery of a message e.g., if the message was delivered without error it would resolve in response code ‘ok’.
Below can the structure of a MedCom AcknowledgementMessageHeader be seen.
Please refer to the tab “Snapshot Table(Must support)” below for the definition of the required content of a MedComAcknowledgementMessageHeader.
A MedComAcknowledgementMessageHeader is required in MedCom FHIR Messaging and follows the recommandations from HL7 FHIR ValueSet response-code
The codes here are equivalent to HL7 v3.Acknowledgement as described in the table below.
| HL7 FHIR Code | HL7 FHIR Code Display | HL7 FHIR Definition | HL7 v3 Code | HL7 v3 Code Display | HL7 v3 Definition |
|---|---|---|---|---|---|
| ok | OK | The message was accepted and processed without error. | AA | Application Acknowledgement Accept | Receiving application successfully processed message. |
| fatal-error | Fatal Error | The message was rejected because of a problem with the content. There is no point in re-sending without change. The response narrative SHALL describe the issue. | AE | Application Acknowledgement Error | Receiving application found error in processing message. Sending error response with additional error detail information. |
| transient-error | Transient Error | Some internal unexpected error occurred - wait and try again. Note - this is usually used for things like database unavailable, which may be expected to resolve, though human intervention may be required. | AR | Application Acknowledgement Reject | Receiving application failed to process message for reason unrelated to content or format. Original message sender must decide on whether to automatically send message again. |
Please go to this definition of OperationOutcome to get informed how and when to use if the code response is different from “OK”.
Usage:
Description of Profiles, Differentials, Snapshots and how the different presentations work.
This structure is derived from MedComMessagingMessageHeader
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
  MessageHeader | 0..* | MedComMessagingMessageHeader | A resource that describes a message that is exchanged between systems | |
  destination:cc | 0..0 | |||
 source | 1..1 | BackboneElement | Contains information about the sender of the Acknowledgement message | |
 response | S | 1..1 | BackboneElement | If this is a reply to prior message |
 identifier | S | 1..1 | id | Id of original message |
| code | S | 1..1 | code | ok | transient-error | fatal-error |
  details | S | 0..1 | Reference(MedComAcknowledgementOperationOutcome) | Specific list of hints/warnings/errors |
| Documentation for this format | ||||
Other representations of profile: CSV, Excel, Schematron
