From National to International Patient Summary

(Nederlandse versie hier)

At the 37th HL7 Working Group Meeting in Phoenix I participated in the FHIR Connectathon on behalf of HL7 Netherlands. My goal was to transform our Dutch National Patient Summary (Basisgegevensset Zorg, BgZ) to an International Patient Summary (IPS). I have been participating in the IPS FHIR Working Group for some time now and this was a great opportunity to see how far we are – or aren’t – apart.

The Netherlands will not be using the FHIR IPS in the near future. At the European level, the European Patient Summary in CDA has been chosen for the time being. It is very similar to the IPS, but details differ. Europe and the USA, and many other countries, agree that we should eventually migrate to one and the same standard. That will be the FHIR IPS.

The good news: creating an IPS from a BgZ is relatively simple and reasonably complete. It should be noted, of course, that there are some differences at a detailed level. Let’s do a deep dive.

The BgZ versus the IPS

The BgZ is the Dutch ‘Patient Summary’: a summary of the most relevant medical data of a patient. The BgZ is partly based on international standards such as C-CDA from the USA and the European epSOS Patient Summary. In contrast to the IPS, the BgZ is based on our Dutch HealthCare Information Models (HCIMs) that are not widely used internationally. In practice the differences are overseeable, but there are some.

Photo by National Cancer Institute on Unsplash

Internationally the world is not at a standstill either. The above-mentioned C-CDA and the epSOS PS have also been used as a starting point for the IPS. This in turn leads to differences at a detailed level – mainly improvements due to experience gained. Technically there is also a big difference: the IPS has a CDA variant but also an FHIR R4 variant. The latter does not exist for the European PS. Our national PS, the BgZ, does have an FHIR variant.

My approach

FHIR has a lot of open source software, including the HAPI server , which is also publicly accessible. For the BgZ we have a large number of HCIMs (our ‘HealthCare Information Models’) available as FHIR R4 resources. I transferred all those FHIR resources from the BgZ of an example patient to HAPI with a Python script using the FHIR update operation. HAPI checks whether the content is correct. After uploading the sample patient, the HAPI server functions as an FHIR database allowing us to query the patient data.

This is not without effort: it is not a matter of uploading and be done with. With 2 days of FHIR Connectathon and about 3 days extra effort it, I had converted our BgZ test set to an FHIR IPS that was error-free, testing with the validation software of FHIR itself. Adjustments are therefore required to the BgZ when converting it to an IPS.

How does this work

HAPI recently implemented the $summary operation: an operation which generates an IPS from the FHIR resources present on the server. The entire document structure of the IPS is created, and the textual representations of the IPS sections are also populated.

In addition to structured data, IPS sections also have a textual representation in HTML, which can be shown to the user. The available IPS viewers make use of those. After creating the patient on HAPI, the IPS can be retrieved immediately with:

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

(The HAPI test server is regularly refreshed, so it is quite possible that this example is no longer visible. The example can also be found here .)

This IPS can be displayed directly in an IPS viewer. For those who want to replay this: click on ‘Raw JSON’ at the top of the above HAPI page. Copy the entire page. Then go to: https://www.ipsviewer.com/ and paste the IPS into the text box. You can then see the IPS, which has been converted from the BgZ, in the viewer. The IPS can be displayed as FHIR Entries (the structured data) or as FHIR Narrative (the HAPI-generated section texts). Here is a piece of the BgZ as it can be seen in the IPSviewer:

Another viewer is: https://ps-ca-renderer.apibox.ca/

Findings

The structure of the IPS

The BgZ in the Netherlands is retrieved with FHIR queries. In short: you ask a source for the allergies, then the problems, then the lab results, etc. and when you are done you have a fully populated BgZ. The IPS works differently: it’s a FHIR Document, and everything is already in there. This matters if there are ‘absent’ findings, such as: there are no known allergies for this patient. In the IPS this can easily be added to the document as a special Allergy. And not only as ‘the server did not find anything’, but also as a positive statement: ‘the patient was interviewed by doctor X on date Y, and there are no known allergies’. The BgZ cannot do that so easily (this has been a known issue for some time.)

Photo by Julia Koblitz on Unsplash

The IPS – because it is a document – is also easier to store and easier to exchange across other infrastructures, such as IHE. For completeness: the query and documents approaches both have their own advantages and disadvantages.

Since the IPS is a document one can also ask a server: ‘give me an IPS’. This is called the $summary operation where the FHIR server compiles an IPS based on what is known in that server. The open source HAPI server has the $summary operation, and I used it to convert the BgZ to an IPS.

Another point is the textual representation in the IPS. A FHIR Document (just like the older standard CDA) has a textual block for each section as well as a block with structured and coded data. The textual block is HTML, and can simply be displayed in a web browser. This allows the doctor or patient to read the information, even when their application does not support the structured data. But if you only have separate FHIR resources that are retrieved with queries, you have no textual block per section at all. The HAPI server solves this by generating a text block per section. This is usually a table with the most essential information from the structured data. It works. Perhaps a locally generated text block per section would be better, but to be honest: often those text blocks are generated from the structured data anyway – in the Netherlands more often than not, I’d guess.

Extensions and the HCIMs

In the Netherlands, the HCIMs are the core of data exchange in healthcare. This is not the case in other countries. When converting HCIMs to FHIR resources, it often turns out that they don’t quite fit: for example, elements that are in the HCIM are missing from the FHIR resource. That does not have to be a very big problem: FHIR has ‘extensions’ which allow data to be added to a FHIR resource.

Take this example of our HCIM MedicalDevice:

A part of the HCIM is the laterality: left, right or both. It is not a separate item in the FHIR resource, and that is why an extension is used (in the R4 FHIR DeviceUseStatement, this would be encoded as ‘right ear’, whereas the HCIMs require ‘right’ (‘Rechts’) and ‘ear’ (‘Oor’) as separate items):

As long as we stay in the Netherlands this works fine. Only: the IPS, and other international standards, do not recognize those Dutch extensions at all. One does not see the extension at all in an international application such as the IPSviewer, and the addition ‘Right’ (‘Rechts’) disappears.

Is this bad? It depends on the extension. In some cases quite essential information is lost, in the other case one could live with it. Sometimes an extension only adds a Snomed code to an equivalent HL7 code. Another example are Dutch family names:

In the Netherlands we sometimes have a prefix with our surnames. This FHIR example renders fine in the IPSviewer:

But this is only because the entire ‘family’ string is filled with the components (‘van Putten-van der Giessen’). And this is not mandatory in the Netherlands: leaving the ‘family’ string empty and only filling the parts ‘van’, ‘Putten’ etc. is allowed. And if you only fill in those parts, but not the composite surname, it will remain empty in an IPS application. Something needs to be done to create a correct IPS: filling the composite family name if it is empty from the components. FHIR allows this, so this is just a case of having stricter national guidelines here.

There are many extensions in our Dutch FHIR resources, largely the result of the HCIMs having a different data model. While this has advantages in the Netherlands, one pays a price internationally: these extensions are lost during international exchange without additional measures.

Differences in content

The IPS and the BgZ also differ in content. To mention a few points: the BgZ has an ‘Alerts’ section, which lists matters such as MRSA infections (a bacterium that is resistant to antibiotics): important, because you don’t want such a patient in your hospital without measures. The IPS on the other hand has a ‘Pregnancy’ section which the BgZ does not have. (This would be relatively easy to add because we already have extensive standards regarding birth in the Netherlands.)

Furthermore, there is an important difference: the IPS has made a subset of Snomed (the Snomed IPS Free Set) available. Snomed CT is an international terminology system that is widely used in the Netherlands, among others, and is essential in our exchanges. Unfortunately, Snomed is not used everywhere and this is partly due to the fact that Snomed is not available for free. The Snomed IPS Free Set is free, and plays an important role in the IPS: many value lists consist of concepts from the Free Set. This has not yet been taken into account in the Dutch BgZ (and the European PS) and there are differences. It is important to always look carefully at the Free Set when making changes to terminology in the BgZ.

The differences in the value lists between the BgZ and the IPS are often not too bad. Both use 8 codes for Tobacco Use, 6 of which are the same. The HCIM has 1 more code than the IPS for the severity of an allergy. In these types of cases, a mapping can be found that can be used in the conversion without major loss of information.

There are also differences to be found at a deeper level. Both the HCIMs and the IPS have a ‘Functional or mental status’. The HCIM has chosen to implement it as an FHIR Observation. The IPS offers the choice between a FHIR Condition and or a FHIR ClinicalImpression. Naturally, it would be good for us to always look at international choices. When converting the BgZ to the IPS, the ‘Functional or mental status’ section is therefore lost. To retain this, the FHIR Observations in that section should first be converted to ClinicalImpression of Condition (note: there currently is discussion within the IPS community whether Observations should not be part of this IPS section, so maybe the issue will be resolved from the IPS side).

Medication

Photo by freestocks.org on Unsplash

A complicated story is medication. The BgZ has three medication HCIMs: Medication Agreement (what the doctor prescribes), Administration Agreement (precise instructions from the pharmacist) and Medication Use (what the patient actually uses). In Phoenix, I was unable to include a number of our medication resources in the IPS in such a way that no error messages occurred. Not very strange, I worked on it for a weekend and a few hours afterwards, which is not much, and with a little more time and effort one would probably make more progress. However, it’s the only section with the above ‘Functional or mental status’ which I could not fully transform.

More fundamental are the extensions in medication. In medication there is an extension for the entire dosing instruction as the text: ‘Vanaf 1 september 2012 gedurende 5 dagen 1x per dag om 8uur 40 mg (=1 st)’. There are many extensions in medication with useful information (whether it’s taken as instructed, why it is discontinued etc.). In an international application like the IPSviewer they all disappear. A narrative (text block) per medication building block also does not help much: the IPSviewer (and other applications) either show the narrative of the entire section or the recognized structured content, in which the Dutch extensions are not shown. There is still some work to be done regarding the international exchange of our medication HCIMs with the IPS. The approach: putting it all in an FHIR server and generating an IPS alone is not sufficient here. For medication it is necessary to convert Dutch resources to international resources with a piece of custom software. That in itself is not a problem, and it will be necessary in more places in the BgZ.

What about language?

As we saw above, Dutch HCIMs contain text such as: ‘Vanaf 1 september 2012 gedurende 5 dagen 1x per dag om 8uur 40 mg (=1 st)’. A doctor in France or Poland will not understand that. Much of the structured content can be translated. For example, our Dutch measurement ‘Lichaamsgewicht’ is coded with the LOINC code ‘29463-7’, and the English translation is known: ‘Body weight’. In fact, everything that is coded can in principle be translated. But the HCIMs, and therefore our BgZ, do have many plain text notes. These cannot be translated based on coding. Text translation software is ever more powerful but often still error-prone: whether automatic translation can be used depends on the use case. It will not yet be the case for surgical interventions, more so for everyday care. But even without automatic plain text translation, the IPS is a very useful overview of essential medical data in an international context.

Summary

The good news is: without too much effort, by uploading our HCIMs to a FHIR server, one can create a very decent IPS with the $summary operation from our national patient summary, the BgZ. It is certainly not perfect, and there are some corners that need to be refined. Work is still needed in particular for the Medication and Functional and mental status sections. This means that a conversion of our BgZ to an IPS with standard FHIR software, and an overseeable number of adjustments, is possible.

For the time being, it looks like we will not have to deal with this directly in the Netherlands because Europe will first connect to the somewhat older European PS that is still based on CDA. But my goal at the HL7 WGM in Phoenix was to see how far we are drifting from the final goal that Europe also wants to achieve: the IPS in FHIR. That doesn’t seem too far removed. The many Dutch extensions are a point of concern: they will not be understood internationally. There are two conceivable routes: when converting to the IPS, convert Dutch extensions – where possible – to something that is internationally understood. Or avoid these types of extensions as much as possible, at least in the BgZ. That also requires a lot of patience: this is no longer possible for our current HCIMs releases of 2017 and 2020. It should be an important point of attention in later versions of the HCIMs.

Van BasisGegevensset Zorg naar International Patient Summary

(English version here)

Op de 37e 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.

Photo by National Cancer Institute on Unsplash

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.)

Photo by Julia Koblitz on Unsplash

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

Photo by freestocks.org on Unsplash

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.