Tuesday, 9 January 2024Wednesday, 10 January 2024

Deduplicating Patient Summaries

The International Patient Summary (IPS) is the to-go exchange format for cross-border patient care – and a growing inspiration for in-country data exchange as well. The IPS is a document containing a summary of the most essential healthcare data.

There is, however, a problem with the idea of a Patient Summary to be exchanged internationally – most patients do not have such a single PS in their own country. Most often their data resides with several healthcare organizations – a GP, some pharmacists, one or more hospitals and so on. So how should a single IPS be generated from separate data sources? Here is a take a the problem based on the Dutch proposals (not final yet).

For this discussion I’ll take the IPS FHIR format as starting point – so I’ll assume the various data holders will generate an PS per data source in the IPS FHIR format, and those PSes are consolidated into a single IPS. This should not be a problem when all data sources only store their “own” data, but this is normally not the case. Data is more often than not copied between healthcare organizations, and the resulting IPS would contain a lot of duplicate information.

When not to dedup

For a lot of data, we choose not to deduplicate at all. For patient demographics, healthcare providers in the Netherlands use a single source (SBV-Z), and they do not usually copy addresses etc. between them – they just access the single source. Likewise, for patient data not in the single source, such as email address or mobile phone of first contact, deduplicating is not worth the effort. Ever been to a hospital? They usually ask if your first contact, email etc. is still correct anyway, so why deduplicate when data is checked anyway?

In other cases deduplication may not be worth the effort: we’ll check sections in detail below.

How to deduplicate

One approach to deduplicating FHIR resources is simply comparing the entire resources. This, however is hard. In XML, attribute order may be different but the resources may still be the same. In JSON, objects need not be in the same order at all. On top of that comes non-significant whitespace and other problems such as character encoding – the same issues that make electronic signatures on XML or JSON data a non-trivial effort. To sum up: comparing raw resources may not be impossible, but is far from ideal. Of course for those who want to this and do have a rigid algorithm for raw resource comparison, deduplication is allowed: if resources are the same on this level, they are true duplicates. I will however explore a higher level approach here.

True copies

There are other ways to find out whether resources are the same or not. On a FHIR server, this is not a problem. Any resource will look like this: [base]/[resourcetype]/[id], and it will yield a single resource – and adding a version id retrieves a specific version of it. The IPS however is a FHIR document, and things are more complicated. The id, to start with, cannot be expected to be unique in a FHIR Document: it is only so on a FHIR server. (If the meta.source element is included in the resource, meta.source+id might suffice to establish resource identity – but discussions on Zulip indicate that meta.source is not very strictly defined, so without further agreements this is not a very reliable approach.)

Looking at the actual international examples of the IPS from various countries, the meta element is not often populated. Within an ecosystem with tightly defined rules, the various items in meta could in principle be used to deduplicate resources in a FHIR document, but such an ecosystem is not in place internationally.

Relevant resources may have an identifier (a business identifier, such as social security number for a Patient). This should be globally unique, due to the system namespace. If we find two resources with the same identifier, they will represent the same entity, but maybe not the same version of that entity. The main question then is: what entities change over time, and may have separate versions, and which do not? (In FHIR, in theory any resource can have versions but in practice a lot won’t change over time.) Unfortunately an identifier by itself won’t indicate version information.

Last there is the Provenance resource, which could be the best solution, but in none of the IPS examples there are Provenance resources (unsurprisingly, since the IPS says nothing on Provenance), and this would require an ecosystem with even tighter rules. To sum up: there is no foolproof way (yet) in an international context to establish whether two resources are same or not, and certainly not which is the latest version.

Luckily in practice the situation is not always as dire as this paragraph might suggest.

Regarding Observations

For Observations there usually is no real need to deduplicate. First, duplicates for Observations should be rarer than for some other FHIR resources. A measurement such a body temperature or a lab result is usually done at one place at some specific time, and though doctors will want to see previous results, they may not always need to store those in their own EHR.

Second, if there are duplicates, this is usually not much of a problem. If there is an entry of my Body Weight stating that I weigh 79 kilograms on January 4, 2024, 09:57, and there is a second entry stating the same, if I plot the two, the points on the plot will be indiscernible. Likewise, if they are in a date-ordered table, no doctor will get confused. Of course, if one entry states that I weigh 79 kilograms and the second that it’s 89 kilograms on exactly the same datetime, there is a problem, but such data corruption problems would need to be addressed by humans anyway, not machines. On other words: don’t deduplicate, leave as is or just mark apparent conflicts.

The same applies to the Results section comprising lab, pathology, radiology and other Observations. In theory a lab result can change, but he IPS (and our Dutch PS) restricts lab results to only final results – so if there are duplicates (the same code and value on the same datetime), this should not be much of a problem. Of course the UI rendering the IPS can do something about duplicate results, i.e. plot on a single plot, or indent or shade apparent copies.

Guideline: do not bother to deduplicate Observations, except when they are known to be true copies

The same reasoning would apply to (most of) the Diagnostic Results, Vital Signs, Pregnancy, Social History and Functional Status sections of the IPS.

Conditions et cetera

The problem list is one of the main suspects for duplicated data. Doctors will want to see a patient’s current and past problems, and quite often some or most of this list will come from other sources – that means, duplicates from elsewhere. In the Netherlands entries from the problem list of one’s GP usually float around everywhere, and since the list can be long, this is a real problem. Doctors do not want to fish in a large pond of duplicated data to find out what the problems of a patient are.

Let’s look at some examples:

A patient has shortness of breath and goes to his GP. The GP makes a record, and since the condition is not easily diagnosed, sends the patient to a pulmonologist in a hospital, along with the record. After treatment the condition has abated and the shortness of breath is no longer an active problem. What could happen here?

Photo by National Cancer Institute on Unsplash

The GP could send a record with an identifier, and the hospital could copy and update this record and set it to: ‘not active’.
The GP could send a record with an identifier, but the hospital might only consult that, make its own record with its own identifier, and set that record to: ‘not active’.
Or the GP could send a record without a proper identifier, and force the hospital to make its own record.
The GP could code the condition as Dyspnea (Snomed: 267036007) and the hospital might retain that code.
Or the hospital’s doctor might refine the code to Dyspnea on exertion (Snomed: 60845006).
After a year or so, the condition might recur, and the GP might set it to ‘active’ again – illustrating that the status of a condition cannot be used for establishing which instance comes first.
If the two doctors both conclude that the patient has Asthma (Snomed: 195967001), the patient will have one asthma (which is a non-curable disease) and not two asthmas, even when the diagnoses are apart in time.
Even though there is only one asthma for this patient, there can very well be multiple records, i.e. multiple FHIR Condition resources – highlighting that the Condition resource is often not really about a patient problem, but about a record of that problem.
But if the patient is diagnosed with Covid-19 (Snomed: 840539006), the patient might very well have had Covid twice, not once, likely indeed if the diagnoses are removed in time.

All this illustrates that with Condition there is preciously little to rely on when deduplicating. When everything is a FHIR server, with support for updates, changing an existing record is not much of a problem: send an update or patch to the server which hosts the resource. (Of course, this assumes an ecosystem with agreements on who can update what.) But in the real world, not everything is a FHIR server with support for updates. When a PS is exchanged as a FHIR document, or retrieved with RESTful read, but without RESTful updates, one cannot update the original resource. To handle the list of possible changes to a Condition, we are considering a set of rules.

Guideline: when copying a resource, retain the original identifiers and do not change the resource.

Guideline: when changing a copied resource, issue a new identifier and discard the old ones.

The guidelines in practice mean that a resource, such as Condition, essentially becomes a doctor’s record of that Condition. If two doctors are saying something about a patient’s disorder, there will be two records. For instance, if the “Shortness of breath” problem is diagnosed by the GP as active, and later set to to not active by the pulmonologist, there will be two copies of the Condition, and another doctor receiving both should be able to see how the actual patient’s disorder has evolved over time. In the future, we might also consider relating Condition resources, enabling one to say: this record was based on that one. That also is useful when the code for the diagnosis changes, like from ‘Dyspnea’ to ‘Dyspnea on exertion’ above.

When did it happen?

Some resources have a dedicated element which indicates when a record was made or changed. As mentioned above, Observation has an effective[x] element with a datetime, period, instant etc. (There also is Observation.issued, but if we limit ourselves to Observations with status ‘final’ effective[x] seems to do.)

Condition does not have such an element. There’s recordedDate, but that is ‘Date record was first recorded’ – so that won’t change when the record is changed. There is meta.lastUpdated, but this is shaky ground. For reads on a single server, this could be useful, but if records are copied to another server, there should be a new meta.lastUpdated on the copy, even if nothing else has changed, and it’s not even clearly defined what the value of meta.lastUpdated should be in a FHIR Document: the value from the server? The moment it was written to the FHIR Document?

So for Condition and other resources there is a need for an element to capture when the record was updated. With such an ‘update time’ any PS could be rendered with possible copies grouped on Condition.code and shown in ascending time order, thus allowing the doctor to see how the Condition has changed over time – or, if wanted, simply show the last state of affairs. (We still have to decide how to register the ‘update time’ in FHIR – maybe Provenance.)

Medication

Medication in the Netherlands is handled by a separate project, and we’re moving to an ecosystem where all medication information is available to all (authorized) care providers. In theory one could go a long way with deduplication using subject, medication code and effective[x], but deduplication (especially of MedicationStatement) is error-prone and consequences of faulty deduplication can be serious. Good advice would be to always include identifiers and leave deduplication to the expert, not the machine, unless there are rigid rules on which to rely. Since we do have such an (evolving) set of rules in the Netherlands, I won’t go into details.

Other sections

For Allergies and Intolerances, the situation is similar to the Problem list, although in most cases the allergy list won’t be as long as the problem list can be, making duplicates easier to handle for humans.

Immunizations also should be of overseeable length, and grouping by code can help. Since an immunization once given should not change, deduplication on identifiers is also possible.

The entries in History of procedures should normally be past events which do not change (in some cases, the procedure could be ongoing or planned). Adding identifiers helps, and if two copies are seen, a look a status could help. Unlike Observations, the IPS does not restrict procedures to completed ones.

Medical devices such as pacemakers will carry an UDI which allows deduplication, and devices which do not, such as wheelchairs, can easily be grouped on code and should not constitute a very long list anyway.

Plan of care is often more the current plan of care. Deduplication should not be tried – if there are multiple plans, a doctor should decide what to do.

For Advance directives, the list should not be too long, and errors in deduplication are serious. So we advice not to deduplicate.

Conclusion

Deduplication of patient summaries is a though problem. However, when looking in detail, it often is not necessary and when it is, there are guidelines which can help a lot. One final piece of advice:

Guideline: when in doubt, let the humans decide.

Monday, 16 October 2023Friday, 20 October 2023

Van BasisGegevensset Zorg naar International Patient Summary

(English version here)

Op de 37^e HL7 Working Group Meeting in Phoenix heb ik namens Stichting HL7 Nederland deelgenomen aan de FHIR Connectathon. Mijn doel was onze Nederlandse Basisgegevensset Zorg (BgZ) te vergelijken met de International Patient Summary (IPS). Niet alleen op functioneel niveau maar ook op het echte uitwisselformaat –de IPS in FHIR. Ik neem al enige tijd deel aan de IPS FHIR Working Group en dit was een mooie gelegenheid eens te kijken hoe ver we zijn – of niet natuurlijk.

Nederland gaat voorlopig nog geen gebruik maken van de FHIR IPS. Europees is er vooralsnog gekozen voor de Europese Patient Summary in CDA. Die lijkt veel op de IPS, maar is op details anders. Europa en de USA, en veel andere landen, zijn het er wel over eens dat we moeten op termijn migreren naar een en dezelfde standaard. Dat zal de FHIR IPS worden.

Het goede nieuws: een IPS aanmaken vanuit een BgZ is relatief eenvoudig, en redelijk compleet. Daarbij aangetekend, uiteraard, dat er op detailniveau wel de nodige verschillen zijn. Laten we eens de diepte induiken.

De BgZ versus de IPS

De BgZ is de Nederlandse “Patient Summary”: een samenvatting van de meest relevante medische gegevens van een patiënt. De BgZ is deels gebaseerd op internationale standaarden zoals C-CDA uit de USA en de Europese epSOS Patient Summary. De BgZ is in tegenstelling tot de IPS gebaseerd op Nederlandse zorginformatiebouwstenen (zibs) die internationaal niet veel gebruikt worden. In de praktijk vallen de verschillen mee, maar ze zijn er wel.

Internationaal staat de wereld ook niet stil. Bovengenoemde C-CDA en de epSOS PS zijn ook gebruikt als uitgangspunt voor de IPS. Dat leidt weer tot de nodige verschillen op detailniveau – voornamelijk verbeteringen door opgedane ervaring met het gebruik. Technisch is er ook een groot verschil: de IPS kent een CDA-variant maar ook een FHIR R4 variant. Die is er voor de Europese PS niet. Onze eigen BgZ kent wel een FHIR variant.

Nictiz heeft een fit-gap analyse gemaakt van de verschillen tussen de BgZ en de Europese PS op functioneel niveau: komen data-elementen en waardenlijsten overeen of niet. Zelf wilde ik een slag dieper kijken: wat zijn de verschillen op FHIR-niveau? Waarbij aangetekend dat mijn analyse verkennend en niet uitputtend is, zoals de fit-gap analyse wel is.

Aanpak

FHIR kent veel open source software, waaronder de HAPI server, die ook publiek toegankelijk is. Vanuit de Nederlandse FHIR projecten hebben we al veel voorbeelden in FHIR R4. Ook voor de BgZ, waarbij van een voorbeeldpatiënt een groot aantal zibs (zorginformatiebouwstenen) beschikbaar zijn als FHIR R4 resources. Deze FHIR-zibs kun je uploaden naar een FHIR server. Ik heb alle FHIR-zibs van de BgZ van een voorbeeldpatiënt met een Python script naar HAPI overgebracht met de FHIR update operation. HAPI controleert daarbij of de inhoud deugdelijk is. Na het uploaden van de voorbeeldpatiënt functioneert de HAPI server dus als een FHIR database waarmee we de patiëntgegevens kunnen bevragen.

Zonder inspanning gaat het niet: het is geen kwestie van uploaden en klaar, Met 2 dagen FHIR Connectathon en zo’n 3 dagen eromheen had ik een BgZ testset omgezet naar een FHIR IPS die zonder errors was, testend met de validatiesoftware van FHIR zelf. Er zijn dus wel aanpassingen nodig aan de BgZ.

Intermezzo: hoe werkt het

HAPI heeft nog niet zo lang de $summary operation: een uitvraag waarbij vanuit de FHIR resources die op de server aanwezig zijn, een IPS wordt gegenereerd. Daarbij wordt de hele documentstructuur van de IPS aangemaakt maar worden ook de narratieve secties gevuld.

IPS secties kennen naast gestructureerde gegevens ook een tekstuele weergave in HTML, die getoond kan worden aan de gebruiker. De IPS viewers die er zijn maken daar vaak gebruik van. Na het aanmaken van de patient op HAPI, kan de IPS dus direct opgehaald worden met:

https://hapi.fhir.org/baseR4/Patient/nl-core-Patient-01/$summary

(De HAPI testserver wordt regelmatig ververst, het is dus goed mogelijk dat dit voorbeeld niet meer te zien is. Het voorbeeld is hier ook te vinden.)

Deze IPS kan direct getoond worden in een IPS viewer. Voor wie dit na wil spelen: klik boven op de pagina op “Raw JSON”, of “Raw”. Kopieer de hele pagina. Ga dan naar: https://www.ipsviewer.com/ en plak de IPS in de tekstbox. Vervolgens kun je de IPS, die is omgezet uit de BgZ, zien in de viewer. De IPS kan getoond worden als FHIR Entries (de gestructureerde gegevens) of als FHIR Narrative (de door HAPI gegenereerde tekst als HTML). Hier een stuk van de BgZ zoals dat te zien is in de IPSviewer.

Een andere viewer is: https://ps-ca-renderer.apibox.ca/

Bevindingen

De structuur van de IPS

De BgZ in Nederland wordt samengesteld met FHIR queries. Kort gezegd: je vraagt bij een bron de allergieën uit, dan de problemen, dan de labuitslagen et cetera en wanneer je klaar bent heb je een complete BgZ. De IPS werkt anders: dat is een FHIR Document, en alles zit daar al in. Het maakt uit bij afwijkende bevindingen, zoals: voor deze patiënt zijn er geen allergieën bekend. In de IPS kan dat toegevoegd worden in het document. En dan niet alleen als “ik heb niks gevonden”, maar ook als positieve uitspraak: “de patiënt is bevraagd door arts X op datum Y, en er zijn geen allergieën bekend”. De BgZ kan dat niet zo eenvoudig. (Het is wel al langer een bekend en openstaand issue.)

De IPS is – omdat het een document is – ook eenvoudiger te bewaren, en eenvoudiger uit te wisselen over andere infrastructuren, zoals IHE XDS/XCA – appeltje eitje daar een IPS in op te nemen, maar met de huidige BgZ gaat dat niet. De eerlijkheid gebiedt wel te zeggen dat queries en documents beiden voor- en nadelen hebben.

Omdat de IPS een document is, is er ook een manier om een server te vragen: “geef mij een IPS”. Dat heet de $summary operation, en de FHIR server stelt dan een IPS samen op basis van wat er in die server bekend is. De open source HAPI server heeft die operation, en die wordt in het begin van deze blog ook gebruikt om de BgZ om te zetten naar een IPS.

Een ander punt is de tekstuele weergave in de IPS. Een FHIR Document (net als de oudere standaard CDA) kent bij iedere sectie een tekstueel blok, en een blok met gecodeerde gegevens. Dat tekstuele blok is een variant van HTML, en kan gewoon in een webbrowser getoond worden. Makkelijk, want zo kan de arts of patiënt de informatie altijd zien, ook als de applicatie die gebruikt wordt de gecodeerde gegevens niet ondersteund. Maar wanneer je alleen losse FHIR resources hebt die je met queries ophaalt, heb je helemaal geen tekstueel blok per sectie. De HAPI server lost dat op door een tekstblok per sectie te genereren. Dat is dan meestal een tabel met de meest essentiële gegevens uit de gecodeerde gegevens. Het werkt. Misschien zou een lokaal gegenereerd tekstblok per sectie nog beter kunnen zijn, maar eerlijk gezegd: steeds vaker worden die tekstblokken altijd gegenereerd uit de gecodeerde gegevens, ook in Nederland in onze BgZ. Het is dus meer de vraag of de aanpak van CDA en FHIR Documents met altijd-tekstblok-en-gecodeerde-gegevens niet zijn langste tijd gehad heeft.

Extensies en de zibs

In Nederland zijn de zibs de basis van de gegevensuitwisseling in de zorg. In andere landen is dat niet zo. Vaak wordt gewerkt vanuit een “Implementation Guide” voor een specifiek domein, wat in de Engelstalige wereld vaak gebeurt, of vanuit een dataset zoals o.a. in Duitsland. Bij het omzetten van zibs naar FHIR resources blijkt dan ook vaak dat het niet helemaal past: er ontbreken bijvoorbeeld elementen die de zib kent in de FHIR resource. Dat hoeft geen heel groot probleem te zijn: FHIR kent “extensions” waarmee gegevens toegevoegd kunnen worden aan een FHIR resource.

Zie dit voorbeeld van de zib MedischHulpmiddel:

Een onderdeel van de zib is de lateraliteit: links, rechts of beide. Dat zit niet op die manier in de FHIR resource, en daarom wordt er een extensie gebruikt:

Zolang we in Nederland blijven werkt dat prima. Alleen: de IPS, en andere internationale standaarden, kennen die Nederlandse extensies helemaal niet. Dat leidt ertoe dat je de extensie ook helemaal niet ziet in een internationale toepassing op de IPS, en de toevoeging “Rechts” daar wegvalt.

Is dat erg? Dat hangt van de extensie af. In het ene geval gaat vrij essentiële informatie verloren, in het andere geval valt er mee te leven. Soms voegt een extensie alleen een Snomed code toe aan een HL7 code. Een ander mooi voorbeeld is de naam:

In Nederland kennen we een voorvoegsel bij de achternaam. Het FHIR voorbeeld hierboven ziet er prima uit in de IPS:

Maar dit is alleen omdat zowel de hele “family” string gevuld is met de componenten (“van Putten-van der Giessen”). En dat is in Nederland niet verplicht: de “family” string leeg laten en alleen de onderdelen “van”, “Putten” etc. vullen mag. En als je alleen die onderdelen vult, maar niet de samengestelde achternaam, blijft die in een IPS toepassing leeg. Voor het aanmaken van een correcte IPS is dus wel wat te doen: bijvoorbeeld vullen van de samengestelde familienaam als die leeg is uit de componenten, en dito voor veel andere extensies.

Er zitten heel veel extensies in onze Nederlandse FHIR resources, grotendeels het gevolg van het eigen model wat de zibs kennen. Dat biedt voordelen in Nederland. Internationaal betaal je daar weer een prijs voor: deze extensies gaan verloren bij internationale uitwisseling zonder aanvullende maatregelen.

Verschillen in de inhoud

De IPS en de BgZ verschillen ook in inhoud. Nictiz heeft een fit-gap analyse op detailniveau gemaakt. Om een paar punten op te noemen: de BgZ kent een sectie “Alerts”, waarin bijvoorbeeld zaken staan als een MRSA-besmetting (een bacterie die resistent is tegen antibiotica): belangrijk, want zo’n patiënt wil je niet in je ziekenhuis zonder maatregelen, anders hebben spoedig alle patiënten die bacterie. De IPS kent dan weer een sectie “Zwangerschap” die de BgZ niet kent. Die zou relatief eenvoudig toe te voegen zijn, want we hebben in Nederland al uitgebreide standaarden rond geboorte.

Verder is er een belangrijk verschil, ook met de Europese PS: de IPS heeft een subset van Snomed (de Snomed IPS Free Set) beschikbaar gekregen. Snomed CT is een internationaal terminologiestelsel dat o.a. in Nederland veel gebruikt wordt, en essentieel is in onze uitwisselingen. Helaas wordt Snomed niet overal gebruikt en dat heeft er onder andere mee te maken dat Snomed niet gratis beschikbaar is. De Snomed IPS Free Set is dat wel, en die is pas ontstaan na de Europese PS. Die Free Set speelt dus een belangrijke rol in de IPS: veel waardenlijsten bestaan uit concepten uit de Free Set. In de Nederlandse BgZ (en de Europese PS) is daarmee nog geen rekening gehouden en er zitten dan ook verschillen in. Belangrijk is bij aanpassingen in terminologie in de BgZ, altijd goed naar de Free Set te kijken.

Vaak vallen de verschillen in de waardenlijsten tussen de BgZ en de IPS wel mee. Voor TabakGebruik hanteren beide 8 codes, waarvan 6 dezelfde. Voor de ernst van een allergie kent de zib 1 code meer dan de IPS. In dit soort gevallen is een mapping wel te vinden die in de conversie gebruikt kan worden zonder groot verlies van informatie.

Op een dieper niveau zijn er ook verschillen te vinden. Zowel de zibs als de IPS kennen een “Functionele of mentale status”. Bij de zib is ervoor gekozen deze te implementeren als een FHIR Observation. De IPS biedt hier de keuze tussen een FHIR Condition (de zib Probleem) of een FHIR ClinicalImpression. Uiteraard zou het goed zijn hier altijd te kijken naar keuzes die internationaal gemaakt worden. Bij het omzetten van de BgZ naar de IPS gaat de sectie “Functionele of mentale status” dus verloren. Om die te behouden zouden de FHIR Observations in die sectie eerst omgezet moeten worden naar ClinicalImpression of Condition.

Medicatie

Een lastig verhaal is medicatie. De BgZ2017 kent drie medicatiebouwstenen: MedicatieAfspraak (wat de arts voorschrijft), Toedieningsafspraak (precieze instructie van de apotheker) en MedicatieGebruik (wat de patiënt echt gebruikt). Het is me in Phoenix bij een aantal medicatiebouwstenen niet gelukt die zodanig in de IPS op te nemen dat er geen foutmeldingen optraden. Op zich niet heel vreemd, ik heb een weekend en wat uurtjes daarna eraan gewerkt, dat is niet veel, en met wat meer tijd en moeite kom je vast verder. Het is wel het enige onderdeel waar ik hier tegen aan liep.

Fundamenteler zijn de extensies in medicatie. In medicatie is er een extensie voor de hele doseerinstructie als tekst: “Vanaf 1 september 2012 gedurende 5 dagen 1x per dag om 8uur 40 mg (=1 st)”. Er zijn nog wel meer extensies in medicatie met nuttige informatie. In een internationale applicatie als de IPSviewer valt het allemaal weg. Ook een narrative (tekstblok) per medicatiebouwsteen helpt niet veel: de IPSviewer (en andere applicaties) laten ofwel de narrative van de hele sectie zien ofwel de gestructureerde inhoud, waarin de Nederlandse extensies dus ontbreken. Voor het internationaal uitwisselen van medicatie met de IPS is nog wel wat werk te verrichten. De aanpak: in een FHIR server stoppen en een IPS genereren alleen is hier niet voldoende. Voor medicatie is het dus nodig de Nederlandse resources met een stukje custom software om te zetten naar de internationale. Dat is op zich niet erg, en het zal op meer plaatsen in de BgZ wel nodig zijn.

En de taal dan?

Hierboven was het al te zien, een doseerinstructie als: “Vanaf 1 september 2012 gedurende 5 dagen 1x per dag om 8uur 40 mg (=1 st)”. Dat zal een arts in Frankrijk of Polen niet zonder meer begrijpen. Veel van de inhoud kan wel “vertaald” worden. De meting “Lichaamsgewicht” is bijvoorbeeld gecodeerd met de LOINC code “29463-7”, en de Engelse vertaling is bekend: “Body weight”. Eigenlijk is alles wat gecodeerd is in principe te vertalen. De zibs, en dus onze BgZ, kennen wel veel tekstuele toelichtingen. Die zijn niet te vertalen op basis van coderingen. Vertaalsoftware op vrije tekst kan steeds meer; wanneer dit gebruikt kan worden hangt van de toepassing af. Voor ingrijpende medische handelingen zal dit nog niet het geval zijn, voor alledaagse hulpverlening waarschijnlijk wel. Maar ook zonder het vertalen van vrije tekst is de IPS al een zeer nuttig overzicht van essentiële medische gegevens in een internationale context.

Conclusie

Er is goed nieuws: zonder bijzonder veel inspanning is, door onze zibs te uploaden in een FHIR server, met de $summary operation een heel behoorlijke IPS te maken. Die is zeker niet perfect, er zijn de nodige hoeken die bijgeschaafd moeten worden maar in wezen is het een overzichtelijke inspanning. Met name voor de secties Medicatie en Functionele en mentale status is nog wel werk nodig. Dat betekent dat internationaal delen van een IPS met standaardsoftware van FHIR, een te overzien aantal aanpassingen, vanuit de BgZ mogelijk is.

Voorlopig ziet het er naar uit dat we daar in Nederland niet direct mee te maken hebben omdat Europa eerst aansluit op de wat oudere Europese PS die nog gebaseerd is op CDA. Maar mijn doel op de HL7 WGM in Phoenix was te kijken hoe ver we afdrijven van het einddoel waar ook Europa naar toe wil: de IPS in FHIR. Dat lijkt mee te vallen. Wel een punt van zorg zijn de vele Nederlandse extensies: die zullen internationaal niet begrepen worden. Er zijn dan twee routes denkbaar: bij conversie naar de IPS die Nederlandse extensies – waar mogelijk – omzetten naar iets wat internationaal wel begrepen wordt. Of dit soort extensies zoveel mogelijk vermijden, in ieder geval in de BgZ. Ook dat vergt een lange adem: voor zibs2017 en zibs2020 kan dat niet meer. Het zou wel een belangrijk punt van aandacht moeten zijn bij latere versies van de zibs.

Monday, 2 December 2019Sunday, 28 February 2021

Toestemming: puzzel in de zorg

Privacy en zorg: het is al jaren een moeizame relatie. Kwam de overheid een paar jaar geleden met een plan om de controle over toegang tot medische gegevens bij de patiënt te leggen, onlangs meldde de minister dat deze “Gespecificeerde Toestemming Structureel” (GTS) niet doorgaat. De uitwerking van de wet die eraan ten grondslag ligt leidde tot een totaal van 160 keuzemogelijkheden voor patiënten. Een simpeler oplossing met 28 keuzes is nog steeds te complex, en het is maar de vraag of dit wel conform de wet is. Onwerkbaar, volgens het Adviescollege Toetsing Regeldruk. GTS van de baan dus.

Tijd om te kijken naar alternatieven: kluisjes bij de huisarts of patiënt, tot EPD-toegang en “just-in-time” toestemming.

Wat is het probleem?

Maar eerst: wat is het probleem precies? De minister schrijft in de kamerbrief:

“Deze gespecificeerde toestemming geldt nadrukkelijk alleen voor die situaties waarin gegevens beschikbaar worden gesteld voor nog onbekend later gebruik … Terwijl het zorgproces daar helemaal niet om vraagt. In vrijwel alle gevallen gaat het immers om een behandelrelatie waarbinnen gegevens gewoon mogen worden uitgewisseld.”

Dat laatste klopt: de Wet op de Geneeskundige Behandelovereenkomst stelt dat een arts geen medische gegevens mag verstrekken zonder toestemming van de patiënt. Die toestemming kan expliciet zijn (dat wilde GTS regelen) of impliciet: als een huisarts een patiënt doorverwijst naar b.v. een cardioloog, mag de huisarts uitgaan van toestemming van de patiënt. Als de patiënt dat niet wil, moet deze dat zelf aangeven.

De minister wil uitgaan van impliciete toestemming: “…de meeste zorg (is) geplande zorg is. Bij geplande zorg kunnen zorgverleners bewust kiezen welke gegevens ze moeten delen, en met wie.”

Er zijn wel uitzonderingen. Ten eerste ongeplande zorg, zoals een spoedopname. Daarvoor komt de minister met een oplossing. Ten tweede kan een arts bijvoorbeeld oudere beelden in willen zien: als de longarts ziet een vlekje ziet, is het van belang om te weten of dat vlekje er al langer zit. Zat er een jaar geleden niets, dan levert dat een andere beoordeling op dan wanneer precies datzelfde vlekje er een jaar geleden ook zat, en niet veranderd is.

Zulke oudere beelden kunnen bij een heel ander ziekenhuis liggen. Opvragen mag dan alleen met (gespecificeerde) toestemming van de patiënt. Een algemene toestemming (“iedere arts mag alles opvragen”) voldoet niet aan de wet. Wat staat de minister voor ogen:

” (ik) vind dat er andere infrastructurele keuzes moeten worden gemaakt. Namelijk voor systemen die niet werken met beschikbaarstelling vooraf, maar met het uitwisselen in de behandelrelatie zelf.”

Hopeloos optimistisch

De visie van de minister lijkt hopeloos optimistisch. De meeste medische gegevens kúnnen helemaal niet gedeeld worden in een behandelrelatie die in geplande zorg ontstaat, omdat die gegevens dan simpelweg niet voorhanden zijn. Oudere beelden zijn maar één voorbeeld.

Laboratoriumuitslagen liggen bij het laboratorium. De huisarts heeft wel een kopie, maar met eigen (NHG) coderingen, niet de originele uitslagen zoals het lab die heeft. En alleen voor onderzoeken die de huisarts zelf heeft aangevraagd. Bij laboratoriumuitslagen speelt precies hetzelfde issue als bij beelden: bij een afwijkende bloedwaarde is het relevant te weten of die recent is of langer bestaat. Niet alle patiënten zijn gelijk. Sommigen hebben probleemloos jarenlang vrij hoge waarden voor een specifieke test. Bij anderen is er een plotselinge piek: dat is een ander beeld, en relevant voor de beoordeling.

Medicatie ligt bij de apotheek. Ook hier heeft een huisarts wel voorschriften, maar de originele bron van de verstrekkingen is de huisarts niet.

Bij een zwangerschap liggen de gegevens van de voorgaande zwangerschappen vaak bij een andere verloskundige of gynaecoloog dan de huidige. Kortom: dat medische gegevens buiten de huidige geplande zorg liggen is geen uitzondering. Het is de regel. Hopen dat het probleem weggaat bij geplande zorg is wensdenken.

Maar wat doen we dan wel? Ik schets hier zes alternatieven. Sommige wild, andere niet realiseerbaar. Ik sta er zelf misschien niet eens achter. Maar op dit moment is het beter buiten de doos te denken dan op een dood spoor verder rijden.

Alle gegevens bij de huisarts

Een manier om bij de geplande zorg van de minister aan te sluiten, is zorgen dat alle gegevens wél aanwezig zijn in dat traject. Dat kan wanneer we alle gegevens in een kluisje stoppen bij een preferentiële zorgverlener, zoals de huisarts (het kan natuurlijk ook een andere arts zijn, bijvoorbeeld bij patiënten in een verpleeghuis of instelling voor langdurige zorg). Daar moet dan alles in zitten: oude beelden, alle laboratoriumuitslagen, medicatie, zwangerschappen et cetera. De beherende arts kan dan de benodigde informatie uit het kluisje delen met volgende partijen in de geplande zorg, die het zo nodig weer verder kunnen delen (bijvoorbeeld bij doorverwijzing naar een academisch ziekenhuis).

De huisarts ligt voor de hand omdat veel gegevens relevant zijn voor de huisarts. Desalniettemin: misschien wil een patiënt niet dat een huisarts verslagen van de psychiater kan zien. Daarnaast is nodig dat de patiënt aangeeft wie de zorgverlener is die de gegevens mag beheren. Al met al is dit een model dat aansluit bij het idee van geplande zorg, maar ook haken en ogen kent.

Power to the Patient!

Een verdere stap: stop alle gegevens in een kluisje bij de patiënt. Die regelt dan dat zorgverleners die geplande zorg verlenen bij de gegevens kunnen. Bij bijvoorbeeld een verwijzing naar een KNO-arts bij een ziekenhuis kan de KNO-afdeling bij het maken van een afspraak de patiënt een verzoek tot toegang kunnen sturen. De patiënt logt dan in bij de eigen kluis, ziet een verzoek van de inmiddels bekende KNO-afdeling, en verleent toestemming. Met het programma MedMij is veel van de nodige infrastructuur al aanwezig. PGO’s zijn nu niet bedoeld voor zorg-naar-zorg uitwisseling, maar dat kan uiteraard veranderen.

Een nadeel is dat niet alle patiënten even digitaal vaardig zijn: de populatie patiënten bestaat voor een groot deel uit ouderen, maar ook voor andere patiënten kan zoiets een uitdaging zijn. Een valkuil in dit soort trajecten is altijd dat we een oplossing bedenken die prima bij onszelf, digitaal vaardige burgers, past maar anderen in de kou laat staan.

Uiteraard sluiten deze opties elkaar niet uit: een kluisje beheerd door de patiënt wanneer die dat wil, en uitbesteed aan de huisarts voor patiënten die dat liever zien. Voor spoedeisende hulp zou de patiënt zelf aan kunnen geven of SEH-artsen en huisartsenposten er wel of niet bij mogen.

De oplossingen met één centraal kluisje per patiënt waar alle informatie in zit, lossen het probleem van vooraf beschikbaar stellen op. Daarbij moet wel gezegd worden dat het deels een schijnoplossing is: is er nu zo’n groot verschil tussen een ziekenhuis dat via een uitwisselsysteem toegang geeft, mits er toestemming is, en een kluisje ergens dat ook toegankelijk is, mits er toestemming is? In beide gevallen ben je afhankelijk van een veilige implementatie en controle op toestemming.

Kijk in elkaars EPD

De Federatie Medisch Specialisten kwam onlangs met een ander idee: laat artsen in elkaars EPD kijken. Gewoon door ze een inlog te geven. In ieder geval voorlopig, tot het beter geregeld is. Er gaan immers mensen dood omdat gegevens niet beschikbaar zijn. De minister gaat erover denken maar verwacht wel “haren in de soep qua privacy”.

Nu zitten er aan het idee van de FMS natuurlijk twee uitersten. Alle specialisten toegang geven tot alle EPD’s is een no-go. Maar dat bij verwijzing van een oncoloog uit de regio naar een oncoloog in een academisch ziekenhuis die tweede toegang heeft tot de relevante gegevens van de eerste, is minder vreemd. Ook bij spoedopname in een regio is inzage binnen die regio misschien wenselijk.

Het idee van de FMS gaat er wel van uit dat iedere specialist in ieder EPD zomaar de weg weet te vinden. Dat is niet altijd een uitgemaakte zaak. Wellicht kan het voorstel van de FMS in specifieke situaties een oplossing bieden. Wanneer ziekenhuizen fuseren, wat regelmatig gebeurt, is het qua privacy natuurlijk van de ene op de andere dag geregeld. Stellen dat het nooit kan is dan wat vreemd.

Just-in-time toestemming

Het hele idee van vóóraf toestemming specificeren is natuurlijk vreemd. Dat leidt tot vragen als: verwacht ik eerder kanker te krijgen of dement te worden? En als ik kanker krijg, wat moet die oncoloog dan zien? Medicatie, oké, maar arbeidsconflicten, een burn-out, seksuele problematiek? Nee, dat niet. Hoewel: als het nu kanker aan de geslachtsorganen is… Afijn, dit voorleggen aan een gezonde patiënt vereist nogal wat mentale gymnastiek.

Kunnen we niet in plaats van alles vooraf te regelen, dat pas doen wanneer het nodig is? Als ik een specifieke klacht heb, en een specifieke arts verzoekt om gegevens, is dat een eenvoudige vraag. Toestemming wordt dan niet vooraf geregeld, maar bij het maken van een afspraak voor geplande zorg. Er gaat dan een (veilig) bericht naar de patiënt die op dat moment een specifieke toestemming verleent.

Dit veronderstelt uiteraard nog steeds dat de gegevens vooraf beschikbaar gesteld worden voor artsen die toestemming hebben, maar het hele probleem van de 160 keuzemogelijkheden wordt omzeild. Ook een uitzondering voor spoedeisende hulp past bij deze uitwerking. Bij een presentatie over Mitz, een nieuwe dienst voor toestemmingen, werd ook langs deze lijnen gedacht.

Volg de behandelrelatie

We kunnen ook de behandelrelatie volgen. Bij een verwijzing kan de huisarts dan toestemming geven aan een KNO-afdeling. Een specifieke afdeling, of regio wanneer de patiënt zelf een ziekenhuis uit wil zoeken (er is immers nog steeds het recht op vrije artsenkeuze). Daarbij kan de huisarts die toestemming bij de verwijzing registreren in een centraal register. Dat toestemmingenregister moet uiteraard geen antwoord geven op de vraag: wie heeft een behandelrelatie met patiënt Jansen? Dat is te privacygevoelig. Maar de vraag beantwoorden: heeft arts X of instelling Y toegang tot deze gegevens, waarbij die arts of instelling geauthenticeerd is, en het antwoord een simpel ja of nee is, lijkt me haalbaar.

De KNO-afdeling kan dan bij doorverwijzing weer verder toestemming geven: de KNO-arts heeft dan immers zelf een behandelrelatie. Wanneer advies van een MDL-arts nodig is, kan de toestemming doorgegeven worden om gegevens in te zien. Ook hier worden gegevens wel vooraf beschikbaar gesteld, maar zijn ze alleen toegankelijk na toestemming.

Sex and drugs and rock ‘n roll

Je kunt je ook afvragen wélke gegevens privacygevoelig zijn. Alle medische gegevens uiteraard, maar niet in gelijke mate. Informatie over seksuele geaardheid of aandoening, over psychiatrie, over middelengebruik, over arbeidsgerelateerde aandoeningen is veel vertrouwelijker dan dat gebroken been van die skivakantie, of het amandelen knippen toen je zes was. Toestemming kan gekoppeld worden aan het privacy-aspect van een gegeven. GTS gaat bijvoorbeeld uit van een hele categorie gegevens, zoals medicatie. Maar ibuprofen is niet hetzelfde als PrEP, methadon of de morning-after pil.

Toestemming per vertrouwelijkheidscategorie zal beter aansluiten bij de behoefte van de meeste burgers.

Hoe vooruit?

De minister heeft al aangegeven met een nieuw voorstel te komen. Voor de zomer. Feitelijk is dit de situatie waar we al jaren in zitten: wachten op een oplossing. Ik heb hier een aantal scenario’s geschetst. Ik denk dat deze oplossingen redelijk in lijn zijn met de wetgeving zoals WGBO en AVG (en de delen van de Wabvpz die doorgaan). Al geldt hier zeker: the devil is in the details. Feit is wel dat dit een moment is om breed na te denken. We kunnen niet blijven wachten op een goede oplossing voor dit urgente probleem.

Verder lezen?

De kamerbrief is hier te vinden:

https://www.rijksoverheid.nl/documenten/kamerstukken/2019/10/04/kamerbrief-over-gespecificeerde-toestemming-structureel

Voor degenen die niet de hele wet willen lezen, maar wel de essentie is er het uitstekende kennisdocument van OTV/GTS:

https://www.programma-otv.nl/nieuws/20191009-nieuwsbericht/

Over toegang tot EPD’s voor artsen:

https://www.medischcontact.nl/nieuws/laatste-nieuws/nieuwsartikel/bruins-wil-meedenken-over-toegang-artsen-tot-epds.htm

Over Mitz:

https://www.vzvz.nl/actueel/borgen-van-toestemming-patient-met-mitz

Tuesday, 24 September 2019Tuesday, 1 October 2019

Kankerregistratie en mCode op de HL7 WGM in Atlanta

Op de HL7 Working Group Meeting in Atlanta was veel aandacht voor de “minimal Common Oncology Data Elements” (mCode) en het verwante Codex. mCode is een van de “FHIR Accelerators” – initiatieven waar in de VS extra geld en moeite in gestoken wordt om FHIR verder uit te rollen.

mCode is een project om een minimale set gegevens die alle kankersoorten gemeen hebben te specificeren en uit te wisselen, om zo tot betere zorg en beter onderzoek te komen. Het gaat dus niet om gegevens specifiek voor borstkanker of darmkanker, maar om die gegevens deze en andere soorten gemeen hebben. Een vereenvoudigd visueel datamodel geeft weer om welke gegevens het gaat:

mCode overzicht data model (klik voor vergroting)

Van de minimale gegevensset is een FHIR specificatie gereed. Meteen maar het slechte nieuws: mCode is een Amerikaans initiatief, en dat betekent dat centrale gegevens zijn gebaseerd op “us-core” componenten, waar we in Nederland “nl-core” hebben. Denk daarbij aan namen (tussenvoegsels), adressen (huisnummer toevoeging) en dergelijke: zaken die in Nederland nodig zijn, maar in de VS anders liggen. Gelukkig is er veel overlap: Amerikaanse kankers kunnen net als de Nederlandse links-of rechtszijdig zijn,, Amerikaanse genen worden hetzelfde vastgelegd als Nederlandse genen, en de TNM-score wordt ook gebruikt. Daarnaast is vanuit het mCode Initiative aangegeven dat men geïnteresseerd is in internationalisering: een kans dus om aan te haken. Het Codex project maakt extensies boven op de minimale set van mCode.

De FHIR implementatie van mCode loopt voor op wat we in Nederland hebben. Zo is er een specificatie voor IKNL (ik ben een van de auteurs). Deze was gebaseerd op de kennis en stand van zaken van enkele jaren terug: toen was er internationaal nog niets. Ook in regionale netwerken als Oncozon en initiatieven van het Citrienfonds wordt gewerkt aan uitwisseling van oncologische gegevens.

Een goed moment dus om aan te sluiten bij mCode, en in ieder geval te (her)gebruiken wat ook in de Nederlandse context past.

Monday, 23 September 2019Sunday, 28 February 2021

De “International Patient Summary” op de HL7 WGM Atlanta

Internationaal uitwisselen van patiëntgegevens komt een stap dichterbij. De FHIR versie van “International Patient Summary” (IPS) van HL7 gaat naar “Standard voor Trial Use” (STU) status, naar verwachting nog dit jaar. (De CDA variant is al STU.) De laatste oneffenheden worden er op de HL7 Working Group Meeting in Atlanta uitgestreken. Daarmee wordt het meenemen van medische gegevens bij een vakantie of werk over de grens straks een stuk makkelijker.

Het Marriott Marquis Hotel waar de WGM is.

De IPS heeft een lange geschiedenis achter de rug. Het Europese epSOS project kende al de European Patient Summary. Echt van de grond gekomen is die niet, maar dit project is een van de voorlopers van de IPS, net als diverse Amerikaanse initiatieven. Internationaal uitwisselen van medische gegevens kent eigen valkuilen en problemen. Bijvoorbeeld: in Nederland kennen we voor medicatie onze G-standaard, maar die is in het buitenland niet bekend. Hetzelfde geldt voor ons BSN: buitenlanders in Nederland hebben dit niet.

De IPS wil een minimale maar wel relevante set gegevens zijn. Specialisme-agnostisch en niet gericht op een specifieke aandoening. De voornaamste use case is ongeplande grensoverschrijdende zorg. Een casus die ik me goed voor kan stellen: oudere vakantiegangers, die het fijn vinden ook in het buitenland over basale medische gegevens te kunnen beschikken. Nu is er het medicijnenpaspoort, een papieren overzicht met medicatie. De IPS bevat daarnaast ook allergieën, klachten, inentingen, ondergane operaties, medische hulpmiddelen zoals implantaten, diverse labuitslagen en meer.

Ik denk dan aan mijn ouders, die een aantal jaren geleden met teruglopende gezondheid nog graag naar Zuid-Frankrijk gingen, maar bezorgd waren dat ze niet de nodige gegevens zouden hebben wanneer dat nodig was. Mijn vader kan redelijk Frans, maar niet goed genoeg om een medisch verhaal uit te leggen. Dat nog los van de vraag of ze uit het geheugen alle details weten te vertellen. Dan zou het prettig zijn dat een Franse arts toegang heeft tot die basale gegevens, zodat het gesprek wat eenvoudiger – en inhoudelijk juister – plaats kan vinden.

De IPS heeft een grote overlap met de Nederlandse Basisgegevensset Zorg (BGZ). Er is dan ook een goede basis voor Nederland om mee te kunnen doen aan b.v. een pilot met een van de Europese landen waar veel Nederlanders werken of met vakantie gaan. Er zijn nog wel de nodige problemen. Zo is de BGZ gebaseerd op FHIR 3 en de IPS op FHIR 4. Dat valt nog wel te converteren. Maar de BGZ wordt op dit moment voornamelijk geïmplementeerd in ziekenhuizen. Nu zijn ziekenhuizen voor mensen die op vakantie gaan of in het buitenland werken meestal niet de houders van de meest recente informatie: dat is in Nederland de huisarts, maar die heeft nog geen BGZ.

Een andere optie is MedMij: gebruik gegevens uit de persoonlijke gezondheidsomgeving (PGO) voor de IPS. In principe haalt MedMij wel de meeste recente gegevens uit meerdere bronnen op. Bij MedMij is er alleen geen “auteur” van het hele IPS. Dat raakt meteen ook een van de laatste discussiepunten van de Working Group Meeting: moet de IPS een “document” zijn dat door een verantwoordelijke zorgverlener is goedgekeurd? Of mag het ook een verzameling zijn uit diverse bronnen, waarbij nooit een mens het geheel heeft beoordeeld? De Working Group heeft besloten dat het per jurisdictie kan verschillen: dus het ene land kan een IPS door de huisarts op laten stellen, het andere land kan de IPS “on the fly” samenstellen. In het IPS moet aangegeven worden of er wel of niet een verantwoordelijke auteur is, maar beide mag.

Hoe dan ook, Nederland loopt voorop, en de IPS heeft een aantal duidelijke – en zeer nuttige – use cases. Al met al tijd voor een verdere stap vooruit in medische gegevensuitwisseling: de grens over.

Wednesday, 1 June 2016Thursday, 9 June 2016

AMOQR: Een Actueel Medicatieoverzicht in je portemonnee

Een actueel medicatieoverzicht (AMO) is essentieel voor goede zorg. Bij een opname in een ziekenhuis bijvoorbeeld wordt je gevraagd eerst een AMO op te halen bij je apotheek. Dan wordt, met een medewerker van de apotheek, gekeken of de medicijnen zoals die in het systeem van de apotheker staan, nog kloppen: of je alles nog slikt wat erop staat, misschien gestopt bent met “zo nodig” middelen, of wellicht ook nog iets bij de kruidenier om de hoek hebt gekocht en inneemt. Dat krijg je mee op een of twee A4’tjes. Handig, want zo weet de specialist precies wat je neemt. Alleen: die A4’tjes neem je alleen mee wanneer je ze nodig hebt. Is het niet veel makkelijker een AMO te hebben dat je altijd mee kunt nemen?

Open space

Pas was ik op de Open Space Werkconferentie Medicatieoverdracht. Een inspirerende middag in de mooie Janskerk in Utrecht.

Wie gedacht had een middagje rustig te kunnen gaan zitten luisteren had het mis. De dames van meeuwenroos hebben ons aan het werk gezet, en alsof dat niet genoeg was mochten we een opdracht aan onszelf op een gefrankeerde kaart zetten. Over een maand krijgen we die in onze eigen brievenbus om te zien wat we ervan terecht hebben gebracht. (Anne, Helen, Elline, bij deze: die van mij mogen jullie houden. Opdracht voltooid.)

Een van de ideeën in de groepen was dat ophalen en meenemen van die A4’tjes, of ophalen van medicatie uit het Landelijk Schakelpunt omslachtig is. Iedereen (die dat wil) moet gewoon een actueel medicatieoverzicht bij zich kunnen hebben. In de binnenzak. Altijd. Mobieltje, en apps, werd meteen geroepen. Nu ben ik daar als ICT’er helemaal voor, maar het kan ook laagdrempeliger. Op een visitekaartje. Ik had me voorgenomen uit te zoeken of dat met een QR code ook kan.

Een Actueel Medicatieoverzicht (AMO)

Wanneer je een AMO ophaalt bij je apotheek ziet dat er zo uit:

Je patiëntgegevens staan erop, de apotheker met wie het besproken is wordt genoemd, evenals huidige en recent beëindigde medicatie, eventuele labwaarden (bijvoorbeeld bloedwaarden) en andere zaken die van belang kunnen zijn zoals allergieëen. Tot slot, belangrijk: wie er naar gekeken heeft. De praktijk wijst uit dat het medicatieoverzicht dat de apotheker in het syteem heeft staan vaak niet up to date is, en apothekers die ik sprak zeggen me dat gegevens uit het LSP veel te vaak ook niet volledig zijn. De patiënt zelf weet het beste wat zij of hij slikt (of soms de mantelzorger), dus die moet meekijken om tot een echt AMO met de A van Actueel te komen. (Zie de richtlijn medicatieoverdracht voor de details van het AMO.)

En nu de portemonnee in!

Dat A4’tje past niet zo makkelijk in de portemonnee. En dit overzicht afdrukken op het formaat van een bankpasje levert ook geen leesbaar document op. Een QR-code kan dat wellicht oplossen.

Hoeveel gegevens passen er eigenlijk in een QR code? Er zijn meerdere formaten (“versions”) met aantal blokjes (“modules”) van 21×21 (version 1) tot 177×177 (version 40). Hoe meer blokjes, hoe meer informatie. Daar komen nog zaken als foutcorrectie en dergelijke bijdie de hoeveelheid informatie beïnvloeden. Een paar rekensommen. Een visitekaartje is 55 mm hoog. Om een QR code heen moet wat witruimte zitten, er blijft dus zo’n 5 centimeter over. Scannen hoeft niet van een billboard, maar kan van dichtbij, dus we kunnen rustig voor een lage foutcorrectie gaan. Dan moet daar een QR code version 27 van 125×125 blokjes met zo’n 2100 alfanumerieke tekens in passen.

Dat lijkt genoeg. Maar ik wil het ook in de praktijk proberen. Ik maak dus een medicatieoverzicht met de patiëntgegevens van mij, zes medicatieregels en één contra-indicatie. Met wat passen en meten worden het 1425 tekens. Alles conform de richtlijn medicatieoverdracht, alleen de layout pas ik wat aan. Die tabellen werken niet goed samen met QR codes, en de icoontjes die in het AMO zitten passen er ook niet in. Dit zijn twee van de zes regels (met fictieve medicatie, aan een glas rode wijn op zijn tijd heb ik voldoende):

-------------------
KENACORT A 40 INJECTIESUSPENSIE 40MG/ML FLACON 5ML
verstrekking
van 1-3-2016 tot 5-6-2016
afgeleverd tot 5-6-2016
1 maal per week 15 milliliter
Dr. Dokter,06010859
-------------------
TRUSOPT OOGDRUPPELS 20MG/ML FLACON 5ML
verstrekking
van 1-3-2016 tot ---
afgeleverd tot 1-6-2016
2 maal per dag 1 druppel
Dr. Dokter,06010859 
-------------------

Met een van de vele onlineapps maak ik een QR code van de 1425 tekens, en download die. Die print ik met mijn huis-tuin-en-keukenprinter op visitekaartformaat. Ik download een QR app op mijn Samsung S4 Mini. Het werkt prima: bij scannen van mijn AMO-visitekaartje staan de gegevens van “mijn” AMO er weer.

Voor patiënten die erg veel medicatie nemen, of voor het opnemen van labuitslagen zal het printje iets groter worden dan een visitekaartje. Het maximum van een QR code is 4296 tekens, dat is driemaal zoveel informatie als in mijn AMO met patiëntgegevens, zes medicatieregels en één contra-indicatie. Dat zal in de meeste gevallen wel voldoende zijn.

Uiteraard is er niets meer geheim aan dit kaartje wanneer ik mijn portemonnee kwijtraak. Datzelfde geldt overigens voor het papieren AMO in mijn binnenzak. Maar medicatie in een app op de telefoon, die beter beveiligd is, heeft ook nadelen. Wanneer ik een ongeluk krijg, en niet meer aanspreekbaar ben, kan de ambulance of de SEH ook niet meer bij mijn medicatie. Uiteindelijk blijft het een keuze voor iedere burger of ze een AMO met alle informatie bij zich willen dragen of niet. Iemand die medische risico’s loopt, zal het eerder doen, anderen zullen de medische gegevens liever achter slot en grendel laten. Geen reden uiteraard deze keuze niet aan de burger zelf aan te bieden.

AMO everywhere!

Het is natuurlijk geen enkel probleem dit AMOQR af te drukken op het “gewone” AMO. Daar is voldoende ruimte voor. Even uitknippen en in de portemonnee. Afdrukken bij de apotheek op een kartonnen kaartje, of sealen in een plastic hoesje is natuurlijk nog mooier. Altijd het laatste AMO op zak. Welke apotheek komt als eerste met deze extra service voor de patiënt?

Update 9-6-2016: Vandaag een interessant gesprek gehad met Bart Luiken van 112QR. Ze hebben een vergelijkbare implementatie, i.s.m. o.a. MS Fonds en Epilepsie Vereniging Nederland. Een kaartje op zak. Niet met een statische QR, maar een dynamische die op een veilige manier toegang geeft tot je kritische gegevens op een website. Geïnteresseerden kunnen daar ook eens kijken naar de mogelijkheden.

Friday, 27 February 2015

Mijn medisch dossier is van mij! Of toch niet?

Je hoort het met enige regelmaat. “Het is eigenlijk heel simpel: het dossier van een patiënt is eigendom van die patiënt! En niet van anderen, zoals de zorgverlener.” Maar zo eenvoudig is het niet.

Om te beginnen bestaat er in Nederland geen “eigendom” van intellectuele gegevens. Op het fysieke dossier kan wel eigendomsrecht rusten, maar in deze tijd van digitale dossiers is dat vrij betekenisloos geworden. Een digitaal dossier is dus niemands juridische eigendom. (Zie ook: ‘Van wie is het dossier’, Anton Ekker, Nictiz 2010.) Er is hoogstens sprake van auteursrecht, maar daarop wordt bij medische dossiers zelden of nooit een beroep gedaan. Prima, zal de tegenwerping zijn, misschien klopt dat in technische zin wel, maar dat is juridische haarkloverij. Moreel gezien is er maar één iemand eigenaar van het dossier, en dat is de patiënt! Maar nee, ook dat klopt niet.

Neem een simpel voorbeeld. Mijn arts schrijft mij een recept uit voor 30 keer 75 mg Nortrilen. Dat recept maakt deel uit van mijn medisch dossier. Maar mag ik nu naar eigen inzicht dat recept wijzigen, en die 30 veranderen in 300? De Wet op de Geneesmiddelenvoorziening stelt dat een recept door een arts ondertekend moet zijn. Wat ik dus ook zelf aanpas in een dossier, een recept is het daarna niet meer. Zo zal een arts ook niet willen dat ik in “mijn” dossier de diagnose obstipatie aanpas wanneer ik vermoed dat er toch wel wat ernstigers dan dat aan de hand zal zijn. (Wanneer een patiënt het niet eens is met een diagnose, heeft deze wel het recht een eigen verklaring aan het dossier toe te laten voegen.) En wanneer ik een bloedwaarde in een laboratoriumuitslag aanpas, is dat geen laboratoriumuitslag meer, maar gewoon een kladje waarin ik zelf wat gerommeld heb. Wat is dat nog voor “eigenaarschap”, wanneer ik de gegevens niet aan mag passen?

Zelfs het (laten) verwijderen van gegevens uit mijn dossier mag niet altijd. Meestal heb ik dat recht wel, maar niet als een aanmerkelijk belang van een derde zich daartegen verzet. Zo’n belang kan bijvoorbeeld de arts zelf hebben. Wanneer ik een klacht over de arts indien bij een tuchtcollege, kan de arts zijn dossier nodig hebben om zich te verdedigen, en hoeft het zolang de zaak loopt, niet te vernietigen wanneer ik daarom vraag.

Kortom, ik heb het recht niet “mijn” dossier naar eigen inzicht te wijzigen, en onder omstandigheden kan ik het zelfs niet verwijderen. Wat voor een eigendom is dat? De feitelijke situatie is natuurlijk anders. Juridisch is er geen sprake van eigendomsrechten, en in lossere zin is het eigendom gedeeld: de zorgverlener heeft het deels geschreven, en de medische inhoud is de verantwoordelijkheid van de zorgverlener.

Uiteraard kan ik prima spreken over “mijn medisch dossier”, maar dan in de zin van “over mij”, niet “van mij”. De essentie van “mijn dossier” is dan ook ten eerste dat ik mag bepalen wat ermee gebeurt: wie het in mag zien, wat er uit verwijderd wordt (met een klein voorbehoud om anderen te beschermen), en uiteraard: dat ik er zelf bij mag! Niet een beetje, niet een deel, maar helemaal. Dat is in Nederland in de praktijk nog niet altijd goed geregeld. Daarover een andere keer meer.

Friday, 30 September 2011Friday, 30 March 2012

Informatie-uitwisseling in de zorg: hoe nu verder?

Deze column is eerder verschenen in ICT Zorg Magazine, Jaargang 12, nr. 4, augustus 2011.

De toekomst van informatie-uitwisseling in de zorg is onduidelijk. In maart heeft de Eerste Kamer het landelijke Elektronisch Patiëntendossier (landelijk EPD) verworpen, ten faveure van ontwikkeling van onderop. Een politieke spagaat van jewelste: het parlement wil van bovenaf opleggen dat informatie-uitwisseling in de zorg bottom-up georganiseerd moet worden. Daarnaast is een toename te zien van initiatieven die de ketenzorg willen verbeteren. Te verwachten is met de toenemende specialisatie van ziekenhuizen dat dit alleen maar zal toenemen.

Daarnaast het aantal patiëntportalen dat de patiënt inzage in het medisch dossier bieden, toe. Maar in juni maakte Google, toch niet voor een kleintje vervaard, bekend het eigen patiëntportaal, Google Health, te beëindigen: wegens gebrek aan succes. Hebben patiëntendossiers dan wel een toekomst? Als het Google niet lukt, wie lukt het dan wel? Voorlopig ontbreken de voorwaarden voor succes nog. Continue reading “Informatie-uitwisseling in de zorg: hoe nu verder?”

Tuesday, 5 April 2011Friday, 30 March 2012

Het EPD, standaarden en marktwerking

Nu de Eerste Kamer naar verwachting de Wet op het EPD afwijst, is het de vraag hoe het verder moet. De Eerste Kamer ziet liever eerst uitwisseling van medische gegevens in de regio, en tegelijkertijd een rol voor de overheid bij het opstellen van standaarden en normen en het houden van toezicht. Beter het EPD eerst op te bouwen van onderop – en tegelijkertijd vragen om sturing van de overheid. Het lijkt een tegenstelling. En deels is het dat ook.

Is het niet beter wanneer de overheid zich even terugtrekt uit de sturende rol? Wanneer lokale initiatieven de kans krijgen te bloeien – of te mislukken, zonder last van die vervelende pottenkijkers van de ministerie? Echt innovatie ontstaat zelden vanuit regulering en de moloch van de ambtenarij. Is het niet beter eerst te zien wat werkt, en later als overheid te proberen die succesvolle initiatieven verder te verbreiden? Laat de markt haar werk doen – het zou VVD-minister Schippers en VVD-opponente Dupuis als liberalen uit het hart gegrepen moeten zijn.

Of toch niet? Continue reading “Het EPD, standaarden en marktwerking”

Friday, 1 April 2011Friday, 30 March 2012

EPD: De weg vooruit

De Eerste Kamer heeft de Wet op het EPD gekraakt. Dinsdag aanstaande volgt de stemming: zonder veel twijfel zal de wet het niet halen. Unaniem (of nagenoeg: het CDA weet het nog niet zeker) willen de senatoren géén Landelijk Schakelpunt en voorlopig alleen uitwisseling in de regio. De privacy is met een landelijke toegang onvoldoende geregeld, aldus de Kamer.

Het zorgveld likt de wonden. Er is jaren geïnvesteerd, niet alleen de vaker genoemde 300 miljoen overheidsgeld, ook veel inzet en werk bij talloze ICT-leveranciers en zorginstellingen lijkt weggegooid. Er wordt volop getwitterd “terug naar het stenen tijdperk”.

Of niet? Is er leven voor het EPD na de stemming? Continue reading “EPD: De weg vooruit”