Specification of security regarding central EHMI services

**Disclaimer - The menu items above marked with a star are yet not specified**

Table of context

• General information regarding security for components in EHMI

• General security definitions for components in the message chain

• Security specifications regarding EHMI Delivery Status of messages

• Submission to EHMI Delivery Service repository

• Client security for EHMI Delivery Status - submission

• Exhibition via service

• Client security for EHMI Delivery Status – search

• Security specifications regarding EHMI Addressing Service

• Decentral regarding EHMI Addressing Service

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”).

1. Access control must be carried out based on national standardized information (attributes).
2. Consent/rejection and treatment relation (dansk: behandlingsrelation) must be checked against the national consent service and the national treatment relation service (dansk: behandlingsrelationservice)
3. 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: Security architecture EHMI support services v01 (opens in new window)

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.

Security specifications regarding EHMI Delivery Status of messages

Security in relation to delivery status is divided into these different steps:

1. EHMI Delivery Status is collected and saved in a repository.
2. EHMI Delivery Status is retrieved by users via displayed services.

Submission to EHMI Delivery Service repository

From the Architecture Vision, we know that security around this is necessary partly so that the users will consider the service based on the collected data to be trustworthy, and partly because personal data is collected, since unique citizen identification (most often the CPR number) is part of the collected information:

• Authenticity: A component that stores EHMI Delivery Status for messages must authenticate itself when accessing the repository.
• Availability: Agreed uptime and response must be ensured via standard operating mechanisms. This is particularly important, as EHMI Delivery Status, cf. section 5.2.8, must be updated close to real-time.
• Integrity: Ensured by the protocol through which the collection is implemented.
• Non-repudiation: A component, that stores EHMI Delivery Status, must audit log the collection in a standardized way.
• Confidentiality: When the collected EHMI Delivery Status is communicated to the repository, it is secured either via explicit encryption or implicit encryption in the underlying infrastructure level.

Client security for EHMI Delivery Status - Submission

Submissions in relation to the scenarios in Specifications – security regarding message communication

In the following, both sides of the sender and receiver ecosystems are assumed to have the same setup as the sending ecosystem. In practice, Sender and Receiver ecosystems are potentially very different, and in that case the different scenarios must be combined accordingly.

Exhibition via service

From the Architecture Vision, we know that the service, who exhibit EHMI Delivery Status on messages, must comply to the same security requirements and rules as other services in the health area, cf. the Architecture Vision’s principle PT6. Therefore, several of the same already existing security mechanisms from other services should be used:

• Authenticity: The service must be presented as a DGWS/IDWS service or a similar level, and the users (both systems, health professionals and citizens) must use digital certificates when calling the service in the same way as for other services on the healthcare area. Again, it is a requirement, that the certificates used are at user credentials level. For systems, however, the certificates must be at system credentials level.
• Availability: Agreed uptime and response time are ensured via the platform on which the service is carried out.
• Integrity: Secured by the protocol with which the service is implemented.
• Non-repudiation: The service implements a standardized audit log. Logging to MinLog is required in cases where a citizen retrieves the EHMI Delivery Status for messages concerning a citizen other than himself, and where a healthcare professional retrieves EHMI Delivery Status specifically for a citizen.
• Confidentiality: The service must actively use the identification of the user (system, healthcare professional or citizen) as well as the search parameters, that are part of the call for the service.

Since the service is exhibited and performed on a platform, that may have its own and more strict security politics than the general security politics in the healthcare area, these must also be observed if necessary.

Client security for EHMI Delivery Status - Search

It will be based on an OAuth-secured REST-interface and SMART-on-FHIR or similar.

For the collection of EHMI Delivery Status, explicit signature between the EHMI Delivery Status “client” and “server” (with associated verification) on system credentials level (VOCES/FOCES/Niveau 3) is required, cf. section 6.3.1 in the Architecture Vision.

To search for EHMI Delivery Status, it is required to use identification on system credentials level (VOCES/FOCES/Niveau 3) between the EHMI Delivery Status “client” and “server”.

To search for EHMI Delivery Status, it is further required to use identification on user credentials level (MOCES/MitID/Niveau 4) for a citizen’s own access as well as a healthcare professional’s specific access via the citizen’s/patient’s record.

Security specifications regarding EHMI Addressing Service

From the Architecture Vision it is known, that EHMI Addressing Service must comply to the same security requirements and rules as corresponding services on the healthcare area, and therefore more of the same already existing security mechanisms should be used:

• Authenticity: The service must be presented as a DGWS/IDWS service, and the users must use digital certificates when calling the service in the same way as for other services on the healthcare area. Due to the nature of the service, it is in this case sufficient, that the used certificates are at system credentials level.
• Availability: Agreed uptime and response time must be ensured via the platform on which the service is carried out, e.g. via standard operating mechanisms such as fail-over and load-balancing.
• Integrity: Secured by the protocol with which the service is implemented.
• Non-repudiation: The service must implement standardized audit log.
• Confidentiality: The service must use the identification of the user as well as the search parameters, that are part of the call for the service. An actual user management in relation to who calls the service, is assumed to be enforced by the calling systems. So, when a user system is correctly authenticated, there is access to the service.

Since the service is exhibited and performed on a platform, that may have its own and more strict security politics than the general security politics in the healthcare area, these must also be observed if necessary.

Decentral regarding EHMI Addressing Service

About

Support or contact

Version of this documentation