IT and security requirements in healthcare

Current efforts to digitalize different aspects of healthcare, the transformation to “e-health”, will have a great impact on the development of the healthcare sector. But what requirements does this put on the systems that enable the transition from conventional healthcare to e-health?

The threat

Health records are being targeted by hackers and sold openly on the “dark web”. In 2016 it was estimated that one third of the total of American health records was available to criminals, and things have hardly improved since then (see for example the NHS list of active investigations [1]).

There are a number of reasons health records are being targeted. Large volumes of data and poor security seem to be important factors, but it is probably the high quality and value of the data that attracts criminals mostly. Because while you may lie about your age and financial situation on Facebook, your doctor probably knows the truth. This makes the data ideal for fraud and identity theft.

In ASCLEPIOS we also consider a broader threat where data from every single patient must be protected not only from criminals but also from curious employees and third-parties. Hence, the threat model considers both external and internal threat sources. The internal threats may come from unprivileged sources such as the medical staff, to privileged adversaries such as system administrators.

To mitigate the threat from internal sources, the system must be robust and secure by-design, so that the exposure of health records to threats – be it malicious or unintentional – is minimized.

Security and Privacy

The use of digital health records creates a number of security and privacy issues that need to be addressed.

The main challenge is obviously preventing unauthorized access or manipulation of health records. The next issue is traceability of any (presumably) authorized access. This in turn requires mechanisms to securely identify entities (doctors, labs, and so on). Finally, records may need to be made available to third parties in a redacted and/or anonymized version.

There are three additional complications that one must take into account.  First, the data is processed by many different entities with different levels of access. This makes interoperability – without loss of privacy and security – a key issue. Secondly, with the introduction of data protection laws such as GDPR, a number of additional functions must be implemented to allow, for example, auditing and revocation of consent. Thirdly, the system must provide additional channels for retrieving data, in case of an emergency. For example, consider that an unconscious patient will not be able to provide his medical record or consent to any information sharing.

Technical requirements

To meet the security and privacy objectives, a number of high-level requirements must be met: (A) protect communication, (B) protect data at rest, (C) protect data operations and (D) monitor and limit access.

In ASCLEPIOS these four objectives are translated to a number of technical requirements which revolve around four main axes (Figure 1):

Figure 1: The four axes of technical requirements
  1. Access control: the system must be able to provide secure access control mechanisms for use in a distributed environment. These mechanisms require secure authentication and the ability to revoke future access. Furthermore, they must generate a trace log for future audits. However, neither the access mechanisms or the trace log should reveal any information to unauthorized entities.
  2. Device integrity: as data is stored and processed by multiple entities, the systems must be able to verify the “correctness” of a number of trusted components. To achieve this, mechanisms to securely identify each component as well as methods to remotely verify the state of it are required.
  3. Data security: the system must provide mechanisms for secure storage, ensuring confidentiality and integrity. Additionally, it must ensure that in-transit data is handled in a secure manner and purged after use.
  4. Network security: avoid leakage of data in-transit. Provide mechanisms for confidential communication with strong authentication, robust traceability and non-repudiation.


In a complex distributed system with multiple stakeholders, these technical requirements cannot be implemented in a satisfactory way using only traditional security technologies. In particular, when we take internal threats into account it becomes evident that we need a system with built-in security that cannot be bypassed by any entities. To achieve this, ASCLEPIOS utilizes modern cryptography such as functional encryption, symmetric searchable encryption and attribute-based encryption.

In addition, a trusted execution environment using modern isolation technologies can be utilized, so that the device owners and administrator do not need to be trusted at all time. Technologies such as Intel SGX allow us to minimize trust dependencies and when possible replace trust in owners and administrators with trust in hardware manufacturer.

If you want to find out more about how all these concepts will be incorporated in ASCLEPIOS, stick around for upcoming blogposts.


[1] “Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information”,