The Dutch Electronic Patient Record System

This page gives an overview of the overall architecture and some security issues in the Dutch National Electronic Patient Record System (EPD).

A detailed technical description of the system and the security analysis can be found in Technical Report UVA-SNE-2010-01 More information here.

Overview

The Dutch Electronic Patient Record (EPD) System is a Dutch Nation-wide system for exchanging medical records, which is introduced in 2009-2010. The Dutch senate is currently preparing a decision on a law that regulates and mandates the use of the EPD for exchanging patient information in the Netherlands.

The EPD is generally characterized as a decentralized system. Patient records are stored in the systems used by the care professional(s) - i.e., the responsibility for managing and storing these records remains with the care professionals; records are not stored a central database as in, for example, the SPINE system used by the U.K. National Health Service.

The system's core is the National Switching Point (LSP in Dutch). This system contains a reference index which stores references (pointers) to patient records. Patient records are indexed using a unique identifier for patients (BSN, the former Dutch social security number) and an information type. Access control takes place centrally in the LSP, based on authorization of the care professional for a given information category (e.g., GP record or pharmacy record). The patient records in the EPD will in most cases be professional summaries created by physicians for the purpose of sharing information with collegues.

The decentral information systems that care professionals store their records in and which are connected to the LSP are termed well-managed care systems (GBZ systems). Only systems who adhere to the requirements for GBZ systems can connect to the LSP.

Above, a figure showing the LSP in relation to GBZ systems is shown. The central role of the LSP is clearly visible. To the right, GBZ systems (belonging to different organizations) are shown which registered patient information in the LSP. Clients (physicians or mandated employees in a GBZ, left) can access the central reference index in the LSP to find relevant records, or they can construct a query to let the LSP find and retrieve relevant records. All access is mediated by the LSP. In reality, GBZ systems will contain client as well as server functionality.

GBZ systems may be small (e.g., GP systems) or very large - including hospitals containing many different systems that contribute information to the EPD, or from which requests are made. For more details, please refer to the paper.

Summary of the results

• There currently is no end-to-end authentication for patient record retrieval requests, making the system vulnerable to attacks on the core of the system, the LSP. The architectural design makes the system more dependent on the defensibility of the LSP than necessary.

• The delegation mechanism is very weak. Delegations are managed decentrally and cannot be verified by the LSP, or by the endpoint who receives a request. This makes the system vulnerable to misuse of the delegation mechanism - as the result of an attack on a decentralized information system or by employees. There is also a weakness in the token authentication mechanism which may be exploitable in decentral information systems.

• Security of the system depends almost completely on verification after the fact. This is detrimental to security. There exist no mechanisms to explicitly establish authorization of specific physicians or employees before they can access information in the EPD. The resulting task of verifying access logs will be overly complicated if not unmanageable. By ensuring that authorizations are confirmed, eventually or in advance, auditing can be significantly simplified, allowing the verification process to focus on unconfirmed cases. These and related solutions are discussed in the paper.

• As a result of the above, patients are implicitly depended upon to verify whether physicians accessed patient records legitimately, that is, within the course of treatment. Meanwhile, the patient web portal, intended for this purpose, among other things, is not ready. It is not clear if patients will be able to distill the relevant information from the access logs, or even make sense of them. This is crucial to security of the system as it is currently designed.

• Quite a lot of information will be stored in the LSP. Besides references to patient records, the LSP must retains logging information about all accesses to patient records. However, the system also currently retains historical information that allows for reconstructing past events (such as the conditions surrounding an attack). This implies that even information that relates to a patient record which was explicitly removed by a patient, may never be completely removable from the system. This information may be vulnerable in view of attacks, either from inside or outside the system.

• The mechanism used for patient authentication is weak. A stronger mechanism, such as a smartcard-based solution, would provide more secure access to the patient web portal. It would also allow for patient-specific encryption of privacy sensitive historical data that has to be stored in the LSP, such as the reconstruction information as described above.

Conclusion

A recommendation

In addition to fixing the found security problems, I think it is very important to realize that a system such as the EPD will never be completely secure. After all, the system is intended to share information between people in different organizations which use a potentially very diverse set of information systems and different procedures to manage these. In this context, it will be impossible to protect privacy sensitive information securely in all cases.

The system comes with an 'informed consent' model where the absence of an opt-out can be interpeted as an assumed consent, meaning that the lack of an opt-out may be interpreted as a consent to use the EPD for exchanging this patient's information.

In fact, assumed consent has already been applied; CSC, the organization which implements and deploys the LSP, has reported in a presentation which I attended, that batch jobs were run -for those patients that have not opted out- to register medical records from a hospital pharmacy in the LSP.

Since it is not clear whether over time an opt-out remains practical for patients to maintain, having an assumed consent model may lead to unforeseen problems in case of a breach of confidentiality due to technical (security) problems. (see also this note.) Such breaches of privacy may be more damaging than necessary, when considering that people could have been able to leave specific, potentially damaging information out of the EPD - but then, clearly, they would have to be given the opportunity to prevent specific, in their view potentially damaging, information from being registered in the EPD.

Therefore, I believe that that an individualizable consent preference should be created in the patient's central authorization profile, which, if set appropriately, tells the system and the physician that this patient must be informed before any (new) information is registered in the LSP. This creates a possibility for patients to have a say in what information about them is registered in the LSP - which is important, as preventing registration of information in the LSP is, ultimately, the only fully effective safeguard to protect privacy sensitive information in the event of a security breach of the LSP, or an incident in some other part of the EPD.

Guido van 't Noordende, March 12, 2010