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
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
We found several (structural) weaknesses in the security architecture of the EPD. Below a list of the main findings.
- There currently is no end-to-end authenticationfor 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.
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.
- The delegation mechanismis 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
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.
token authenticationmechanism which may be exploitable in decentral information systems.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.
- 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.
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.
- 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 authenticationis 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.
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.
Conclusion
In time, the EPD design may become a reasonably secure solution for exchanging patient information in the Netherlands. However, it still includes a number of security vulnerabilities that should be addressed to provide a better protection of privacy sensitive information. Overall, I believe the current architecture places too much confidence in the defensibility of the LSP and the decentral information systems against possible attacks.
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
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 foundusing 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.
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.