DK EHMI Endpoint Register (EER)
0.5.0 - ci-build Denmark flag

DK EHMI Endpoint Register (EER), published by . This guide is not an authorized publication; it is the continuous build for version 0.5.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/medcomdk/dk-ehmi-eer/ and changes regularly. See the Directory of published versions

Eas Use Case 1

Get Receiver metadata by SORID

An Eend USer Application, EUA, calls EAS to retrieve the necessary message address metadata information for a potential receiver of a message. The sequence diagram for this is as follows:

1_1_getReceiverData_getReceivingOrganizationBySORId

Initially, when EAS receives this request, the given organization id is validated, after which relevant organization information associated with the organization id is obtained from SOR. With this and the type of message to be sent, the EHMI Endpoint Register (EER) is then called to obtain the GLN number and other relevant information, and finally the response is packed and sent back to the caller of EAS. The message type is, again, needed in the second call to EAS, such that EAS can return the correct response for the given message type – it could for example be that the system of the general practitioner does not support receiving the particular type of message.

​This use case is conforming to this OperationDefinition: OperationDefinition-eas.getReceivingOrganizationBySORId

Error use cases for EAS use case 1

  • error use case 4a - SOR-Information does not exist

Error use case 1a - EER-ReceiverData does not exist

Should an error occur when calling EER to obtain the GLN number and other relevant information, an error response stating this is packed and returned to the caller of EAS as illustrated by:

1_1a_getReceiverData_error1_getReceivingOrganizationBySORId