This page contains a brief explanation of some aspects of the security analysis of the Dutch National Electronic Patient Record System (EPD). As often, the devil is in the details. This page is not intended as a complete summary of the results; please refer to the paper or to the letter to the senate for that.

  • End-to-end authentication

    End-to-end authentication is the property that the receiver of a request can verify (authenticate) who the sending party is, and that the content of the request has not been altered. In systems that support public key cryptography, such as the EPD, this can be achieved by creating a digital signature over the message and sending this signature along with the message. Using the signature, the receiver of the message can ensure that the message was sent by the person who signed the message.

    End-to-end authentication is not supported for patient record retrieval requests. Therefore, decentralized systems cannot verify that an actual care professional (each care professional has a smartcard for signing requests) is behind a request for obtaining a patient record. The authentication information (a digitally signed token) is there, but this is removed from the request by the LSP before the message is forwarded to the information system(s) containing the requested patient record(s). This means that a hack of the central system can have severe consequences. In particular, malicious software in the LSP can forge requests, in order to obtain practically any patient record from any information system that is part of the EPD. The problem can be fixed, however, this fix should be made without backward support for the unsafe mechanism; also, the fix should include a solution of the token issue described below.

  • Token authentication

    The authentication tokens used in the communication protocols -tokens are the part of the messages which are signed by health professionals- do not embed all relevant information regarding a request. This makes it possible to tamper with messages without this being detectable: the token and the digital signature over this token remain valid even when certain parts of the message are modified. For example, malicious code on a communication server in a hospital can (covertly) extend query parameters in a request message to obtain more information than the requesting physician originally intended, without the physician or the LSP being able to notice it. More details are discussed in the paper.

  • Delegation

    Delegation (mandatering in Dutch) is a mechanism for physicians to delegate authority to access the EPD to, for example, a nurse or a secretary. Delegation is managed decentrally - that is, in the information systems attached to the LSP. The LSP has no overview of which employees may be mandated by whom. There exists currently no way to centrally verify the validity of delegations when, for example, access to a patient record is requested; as far as the LSP is concerned, any employee may be mandated by any care professional. The lack of verifyability of delegations in the LSP, creates a significant vulnerability in the security mechanisms of the EPD.

    Technically, in the communication protocols, an employee can claim to be mandated by any physician in the same organization by simply filling in this physician's name (or identifier) in a field in a request message. For this, no active participation of the mandating physician is required. Verification can only take place after the fact. Practically, this means that when software is compromized in the decentralized information system, it becomes straightforward to bypass LSP authorization rules -including authorization profiles defined by patients- by claiming a mandate from any physician within the same organization. This attack is particularly powerful when combined with a stolen UZI pass with PIN code.

    Employee UZI passes are not inherently restricted with regard to delegation. For example, employee UZI passes do not have a built-in role to limit access to patient records based on information category. Employee passes can even be used to access or register information regarding a given patient for the first time - operations which we would expect to be reserved for physicians alone, as these implicitly claim a treatment relationship as far as the LSP is concerned.

  • Patient web portal

    In the long term, patients will be provided with a way to view the information stored about them in the EPD, and by whom it was accessed. In the short term, patients can view the references stored in the EPD, and the access logs related to these references (records), but not yet the full records. We will call this system the patient web portal (loosely translated from the Dutch term virtueel klantenloket).

    Patients can also set their authorization profile in the patient web portal. The authorization profile can be used by parients to deny access to patient records (of a given type) to specific health professionals or employees - for example, a neighbour or family who works in health care. Defining an authorization profile and viewing access logs are both critical aspects of the current security framework of the EPD.

    Because patients are currently effectively relied upon to verify whether access to their records was legitimate, that is, took place within the context of treatment, the patient web portal is essential for EPD security. However, it is currently unclear how authorization profiles or access logs will be presented to patients, or how detailed they will be. It is unclear whether patients will understand how to adjust their authorization profile, or how to interpret the access logs to their EPD. These are significant questions, since security of the system currently depends on these aspects. Therefore, it is important to test and evaluate the patient web portal thoroughly and publicly before the EPD is introduced.

  • Patient authentication

    The patient web portal is expected to be accessed using a system called DigiD. DigiD is a Dutch nation-wide infrastructure for accessing governmental services. Currently, DigiD authentication takes place using a username/password extended with SMS authentication. An inherent weakness of the approach is that the DigiD infrastructure has to effectively translate the DigiD authentication method to the authentication mechanism used by the EPD. An attacker who gains access to the DigiD (back-end) authentication infrastructure, will be able to access all patient records directly (see this report, p.26, par.4.07).

    In the future, DigiD authentication may be replaced by a stronger authentication mechanism, for example, based on a future make of the Dutch passport or (electronic) National identity card (eNIK). However, these mechanism are not expected to be available the coming years. Introducing a smartcard for patients based on the UZI smartcard could provide an alternative. This technology is already used in the EPD infrastructure, and it can provide a solution to several problems observed in the current system. More details are given in the paper.

    It could be argued that a disadvantage of using a smartcard for patient authentication is that patients will have to install smartcard readers and software in their home. This issue can be alleviated by installing terminals for patient at health providers and pharmacies, or in some cases in a physician's office. In this case, health organizations may even help when there are questions or problems with accessing or understanding the patient web portal. As long as PIN codes are kept private, this is perfectly legitimate and safe.

  • Other risks

      • Providing patients with full access to patient records may have additional risks and disadvantages which were not yet described in the report. These are independent of the particular authentication method used to provide access to the patient web portal.

      In particular, patients may be coerced into providing access to their health records using the portal, for example by insurers or law enforcement officials, or even by relatives. Vulnerable (groups of) people may be particularly sensitive to forms of pressure or coercion, and the results may be severe in individual cases.

      This risk is a further argument for creating a possibility to arrange consent prior to registering information in the LSP. This way, (vulnerable) patients can make absolutely sure that specific sensitive information will never be registered in the LSP without their knowledge based on assumed consent, thus ensuring that this information can never be found using the patient portal - even when they succumb to pressure to provide access to their records.

    Essentially, there are very good reasons that patients confide only with their physician under patient-doctor confidentiality, and do not provide broader access to their information in general - and through the EPD specifically.