Nadat er een jaar lang weinig hard nieuws te melden was, is er sinds kort een nieuw [businessplan van VZVZ](http://www.vzvz.nl/uploaded/FILES/Businessplan%20VZVZ%20DEF.pdf), welke ten grondslag ligt aan het convenant dat door zorgpartijen, ICT-leveranciers en zorgverzekeraars is gesloten rond de doorstart van het LSP/EPD. Dit plan straalt torenhoge ambities uit, en is nogal onrustbarend. Het businessplan geeft een goed beeld van welke kant men op wil met het Landelijk Schakelpunt, hoe de initiatiefnemers dat (qua sturing) willen realiseren, en wat de consequenties daarvan kunnen  zijn. Het lijkt erop dat men straks zo'n beetje alle zorgcommunicatie via het LSP wil laten lopen, inclusief bij uitstek regionale of één-op-één communicatie zoals bij geboortezorg of ketenzorg. Dat is onnodig riskant.
---


Een kort nieuwsitem

Actualisering

# Brief explanation of terminology

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 <publication pdf="pdf/Techreport-VWS.pdf">paper</publication> or to the <readmore type="archive" slug="brief-aan-de-eerste-kamer">letter to the senate</readmore> for that.

### End-to-end authentication {#end-to-end}

*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 {#token-auth}

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}

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 {#klantenloket}

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 {#patient-auth}

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](http://www.cs.ru.nl/B.Jacobs/PAPERS/BLG18295.pdf), 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](http://www.uziregister.nl/english/) 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 {#other}

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.

Brief explanation of terminology

# Continuiteit {#continuiteit}

Het risico van een centraal schakelpunt bestaat niet alleen uit een beveiligingsrisico op lange termijn, zoals beschreven in mijn [onderzoek](/archief/uva-archief), maar ook uit een beschikbaarheidsrisico.

Het EPD moet continu beschikbaar zijn. Als er iets gebeurt waardoor het LSP de lucht uit moet (wat bijvoorbeeld zou moeten gebeuren als er een inbraak wordt geconstateerd - waarbij het backup schakelpunt geen afdoende oplossing biedt aangezien op die backup dan net zo gemakkelijk op ingebroken kan zijn, of worden), is er een probleem.

Het nare is dat nu niet alleen het systeem voor *landelijke* gegevensuitwisseling wordt getroffen, maar ook de *regionale* uitwisseling van patiëntgegevens wordt geraakt. Als er regionale schakelpunten zouden bestaan, naast een eventueel (<pdf pdf="opinie-qure.nl-reformatted-minor-changes.pdf">liefst "push" georienteerd</pdf>) systeem voor landelijke uitwisseling, dan zou deze regionale uitwisseling niet getroffen worden door uitval van het landelijke schakelpunt. Echter, door het gebruik van één *landelijk* schakelpunt, ook voor de regionale uitwisseling van gegevens, wordt een kritieke bottleneck ingevoerd.

Met andere woorden: het landelijke schakelpunt vormt een **single point of failure** - een klassiek probleem in het bouwen van grootschalige gedistribueerde systemen, dat vermeden kan en moet worden vanuit het ontwerp, de *architectuur*, van het systeem.

Continuiteit

# The Direct Project {#the-direct-project}

Het [Direct Project](http://directproject.org/content.php?key=overview) is een nieuwe standaard die wordt ontwikkeld in de VS. Het wordt ook ondersteund door Microsoft HealthVault. Feitelijk implementeert men hier eenvoudig, beveiligd berichtenverkeer bovenop bestaande email standaarden. In combinatie met UZI passen / UZI certificaten geeft dit (uitgaande van een betrouwbare Certificate Authority) een elegante manier om veilig [versleutelde berichten](http://www.cerner.com/Direct_Project_not_just_about_email/) (ter vervanging van fax) direct uit te wisselen tussen arts A en arts B. Dit kan heel goed gebruikt worden om bestaand berichtenverkeer (per mail, fax, of de Edifact berichten die nu worden gebruikt voor het uitwisselen van gegevens tussen eerste en tweede lijn) beter te beveiligen.


The Direct Project

# Longitudinaal dossier {#longitudinaal-dossier}

Hiermee wordt een dossier bedoeld dat over lange termijn, dus historisch, gegevens bevat. Mogelijk "cradle to grave." Beredeneerd vanuit gevoelige gegevens in zo'n dossier, wordt de kans op misbruik door een inbraak of oneigenlijk gebruik groter naarmate de tijd dat de gegevens ontsloten zijn langer is en de schaal van het systeem groter is. Als een dossier voor 30 jaar aangemeld is in (en ontsloten wordt via) een centraal 'schakelpunt', kan elke inbraak in die 30 jaar de gegevens kwetsbaar maken voor diefstal en/of misbruik. Zeker zolang de patënt niet actief betrokken is bij de autorisatie van zorgverleners neemt het risico toe met het aantal aangesloten zorgsystemen. Door de longitudinale aanpak verhogen de risico's ten opzichte van systemen waarbij de ontsluiting van bestanden -of meta-gegevens zoals verwijsindices of logbestanden- slechts voor zo kort mogelijke termijn centraal (of decentraal) worden opgeslagen. "Push" gegevensverkeer (dus veilige, versleutelde email) leidt tot een nog grotere afname van het risico, aangezien hier geen centraal geheugen bestaat.


Longitudinaal dossier

Expertdiscussie op website Nieuwsuur

Het Pobelka botnet. En het EPD?

Samenvatting

Mijn reactie op de reactie van het ministerie (2010)

My reaction to the ministry's reaction

Over Diginotar, falend toezicht, en de les voor het EPD

Over specifieke toestemming - en autorisatie

Overview of the Dutch Electronic Patient Record System

Aandacht in de media

Perikelen rondom de opt-in

Position paper bijeenkomst Tweede Kamer

Publicatie rapport en resultaten

Security flaws in the Dutch EPD system - a summary

Specifieke toestemming en end to end beveiliging

Veranderingen aan EPD-ontwerp verbeteren de beveiliging niet. De uitgangspunten en de fundamenten blijven een groot risico voor de privacy van patiënten.

Update specficiatie van het Landelijke EPD