Specification of security regarding message flow in EHMI Core

**Disclaimer** 

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

Table of content

• General security definitions regarding components in the delivery chain

• General information about security for components in EHMI

• Specifications - security regarding message communication

• Decentralized regarding security

• All components stand-alone - implemented on different servers

• All components stand-alone - grouped together on the same server

• All components stand-alone - sending system and MSH grouped together on the same server

• All components stand-alone, MSH and AP grouped together on the same server

• Sending system stand-alone - MSH/AP build together - implemented on different servers

• Sending system stand-alone - MSH/AP build together - all grouped together on the same server

• Sending system/MSH build together - AP stand-alone - implemented on different servers

• Sending system/MSH build together - AP stand-alone - all grouped together on the same server

• Sending system/MSH build together - MSH/AP build together - implemented on different servers

• Sending system/MSH build together - MSH/AP build together - all grouped together on the same server

• All components build together

• Receiver

General security definitions regarding components in the delivery chain

The following definitions regarding all systems/components in EHMI applies:

• Systems/components can be a stand-alone applications or build-in with one or more systems/components in the message flow.
• Systems/components can be a stand-alone application grouped together with one or more systems/components in the message flow on the same server.

General information about security for components in EHMI

It is possible to report and access data via a FHIR API. Web-services/RESTful-services, which are exposed via such interface, must, like other national web-services in the healthcare area, comply with national architecture and national standards.

This means, among other things, that in case of personal identifiable information:

A strong authentication of users must take place (according to NIST niveau 3-4 or NSIS niveau “substantial”)

1. Access control must be carried out based on nationally 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: behandlingsrelationsservice)
3. Information about healthcare professionals’ access to personal data must be viewable for the citizen/patient via MinLog

Specifications - security regarding message communication

First, the general guidelines regarding security in the message flow in EHMI are described. Secondly, it is described for the different scenarios of interconnections and grouping, cf. General security definitions regarding components in the delivery chain how the guidelines is implemented in the individual scenarios.

Decentralized regarding security

The following table illustrates in general, how the guidelines are regarding security in the message flow in EHMI.

Autenticity management between C1 and C2 (cf. section 6.1.1 in the Architectural Vision):

In the health sector, there is a requirement that the message and/or the envelope is signed in C1, and that this signature is subsequently verified in C2. This way, the authentication of C1 is ensured in C2. This authentication will be a part of the agreement between the AP and the system, which the AP acts on behalf of. This is ensured by explicit signing between the sending system/MSH/AP (with associated verification) on system certificate level (VOCES/FOCES/Level 3). This can, for example, be ensured via DGWS/IDWS or similar.

Integrity protection between C1 and C2 (cf. section 6.1.2 in the Architectural Vision):

This is ensured, in addition to the envelope signing described under authenticity (section 6.1.1), via the protocols used between the Aps and the systems, which the Aps acts on behalf of, e.g. TLS (Transport Layer Security).

Confidentiality between C1 and C2 (cf. section 6.1.4 in the Architectural Vision):

As all messages under the health domain basically contain sensitive personal data, the encryption must be used, when it is possible. Therefore, the message must be encrypted between sender and the sending AP via MSH (C1 and C2) as well as between the receiving AP and receiver via MSH (C3 and C4). The use of this encryption will be part of the agreement between the AP and the system, which the AP acts on behalf of. This is ensured as via the integrity protection.

The above also applies to all communication between C3 and C4.

All components stand-alone - implemented on different servers

All components stand-alone - grouped together on the same server

All components stand-alone - sending system and MSH grouped together on the same server

All components stand-alone, MSH and AP grouped together on the same server

Sending system stand-alone - MSH/AP build together - implemented on different servers

Sending system stand-alone - MSH/AP build together - all grouped together on the same server

Sending system/MSH build together - AP stand-alone - implemented on different servers

Sending system/MSH build together - AP stand-alone - all grouped together on the same server

Sending system/MSH build together - MSH/AP build together - implemented on different servers

Through dialog with the participating parties, we have learned that this scenario is possible. In that case, it is important, that parties with this kind of setup agree on which MSH is the primary with fulfilling the MSH obligations, and which MSH simply forwards information to the next link in the chain. Once this is in place , the following security instructions will apply.

Sending system/MSH build together - MSH/AP build together - all grouped together on the same server

All components build together

In this scenario, all components are built together, and therefore all security is handled internally in the assembly/sammenbygning, which means that there is no need to explicitly describe security here.

Receiver

The above only describes how security looks on the sender’s side. The corresponding mechanisms are, of course, also implemented on the recipient side. On the recipient side, the mechanisms are simply used in the opposite order with the corresponding actors/parties in opposite order.

About

Support or contact

Version of this documentation