EHMI Addressing Service (EAS)
0.8.1 - ci-build
EHMI Addressing Service (EAS), published by MedCom. This guide is not an authorized publication; it is the continuous build for version 0.8.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/medcomdk/dk-ehmi-eas/ and changes regularly. See the Directory of published versions
This use case is virtually identical to the second part of use case 3. From a list in his/her local system, the user selects an organization, by id, and then calls EAS to retrieve the necessary message address metadata information for this. The sequence diagram for this is as follows:
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
Should an error occur while validating the given organization id or obtaining the relevant or-ganization information associated with the organization id, an error response stating this is packed and returned to the caller of EAS as illustrated in the following diagram:
Correspondingly, 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: