EHMI Security
-
General information regarding security for components in EHMI
-
General security definitions for components in the message chain
General information regarding security for components in EHMI
It is possible to report and access data via a FHIR API. Web-services/RESTful-services, that are exposed via an interface, must, like other national web-services on the health area, comply with national architecture and national standards.
This means, among other things, that in case of personally identifiable information:
A strong authentication of users must take place (equivalent to NIST level 3-4 or NSIS level “significant”).
- Access control must be carried out based on national standardized information (attributes).
- Consent/rejection and treatment relation (dansk: behandlingsrelation) must be checked against the national consent service and the national treatment relation service (dansk: behandlingsrelationservice)
- Information about healthcare professionals’ access to personal data must be viewable by the citizen via MinLog.
The general and specific security about this is described in: Sikkerhedsarkitektur EHMI services v 0.98/Security architechture regarding EHMI central services v 0.98 (opens in new window)
Be aware that the document is written in Danish and that most part of the document is describing, how the general security model is working as the document later will be a more general model throughout national healthcare services based on rest. However there is an appendix, “Appendiks: Anvendelse af sikkerhedsmodellen i EHMI services”, where the focus is on the EHMI services described here. There is also translations in English of the appendix sub-chapters, these are placed in a security tab in the specific IG’s. Links will be provided in the sub-sides here as well.
General security definitions for components in the message chain
Following definitions for all systems/components in EHMI apply:
- Systems/components can be a stand-alone application or build together with one or more systems/components in the message flow.
- Systems/components can be a stand-alone application or grouped together with one or more systems/components in the message flow on the same server.
EHMI Core Security
EHMI Core Security is defined as
- the needed security implementation to serve message delivering as described in EHMI Core Description
- the already established security implementation regarding XDS Document Sharing on NSP
- this part of EHMI Core Security is described here (Link to NSP opens in a new window)
- EHMI Core Security Description
EHMI Delivery Status Security
EHMI Delivery Status Security is defined as
- the needed security implementation to serve EHMI Delivery Status as described in EHMI Delivery Status Description
- Specific technical details of EHMI Delivery Status Security Description can be found in the EDS IG (opens in a new window)
EHMI Addressing Service Security
EHMI Addressing Service Security is defined as
- the needed security implementation to serve EHMI Addressing Service as described in EHMI Addressing Service Description
- Specific technical details of EHMI Addressing Service Security Description can be found in the EAS IG (opens in a new window)
EHMI Endpoint Register Security
EHMI Endpoint Register Security is defined as
- the needed security implementation to serve EHMI Endpoint Register as described in EHMI Endpoint Register Description
- Specific technical details of EHMI Endpoint Register Security Description can be found in the EER IG (opens in a new window)
About
Support or contact
MedCom is responsible for this page. If you have any questions regarding this page, please contact ehmi@medcom.dk.If you want to report an issue regarding this page, please report it at GitHub issues for EHMI®
Version of this documentation
The version of this documentation is: 1.0.0 You can find the release note of the version here."EHMI® is the registered trademark of MedCom and is used with the permission of MedCom."