Eind september was er weer een internationale HL7 Working Group meeting waar ik namens HL7 Nederland aan deelnam. Er waren verschillende interessante onderwerpen. Een paar eruit gelicht: diabetes en continue glucose monitoring, de plannen van LOINC, FHIR versionering, CDA (CDA? ja, CDA) en de International Patient Summary. En de kers op de taart: een Internationale Implementation Guide met Nederlandse conceptie.
Continuous Glucose Monitoring Data
Josh Mandel presenteerde een Implementation Guide (IG) voor het delen van gegevens van een CGM, een Continuous Glucose Monitoring apparaat. Tegenwoordig hebben veel diabetici een CGM die continue de bloedwaarden meet met een CGM op bijvoorbeeld de bovenarm. Dat kan dan uiteraard veel preciezer en vaker dan het grofmazige zelf meten door te prikken. En dat levert data op, heel veel data. Die data kunnen uitgewisseld worden met een patient app of met de behandelend arts. (Vaak gebeurt dat via het backend van een leverancier.)
Josh heeft CGM IG geschreven die besproken is. Interessant voor mij, ik heb een keer ook zo’n CGM IG gemaakt voor een van die leveranciers, en die (gelukkig) grotendeels lijkt op dit werk.
LOINC en semantische iInteroperabiliteit
LOINC is een standaard voor onder andere labresultaten. LOINC is geen concurrent voor SNOMED CT, omdat ze beide sterk zijn in andere domeinen, maar er is wel de nodige overlap en werken met zowel LOINC als SNOMED is vaak lastig. De partijen erachter, Regenstrief en IHTSDO zien dat ook wel en zijn een nauwe samenwerking aangegaan. Daarbij zullen de 6 assen in LOINC (eigenlijk de basis van het informatiemodel onder LOINC) allemaal gemapt worden op SNOMED concepten, en de SNOMED regels voor het samenstellen van een naam (een “Fully Specified Name”) zullen ook in LOINC toegepast worden.
Een voorbeeld: Hier zien we een LOINC concept (een labonderzoek naar de aanwezigheid van de veroorzaker van de ziekte van Lyme). Alle assen van LOJNC (hier 5 stuks, zoals property en component) zijn gemapt op de bijbehorende SNOMED concepten.
Er is een preview van de hele samenwerking te zien op loincsnomed.org. Zeker voor Nederland, waar we met beide standaarden werken, is dit een veelbelovende stap vooruit.
FHIR, hoe verder
Bij FHIR is men druk bezig met FHIR R6, de “grote” normatieve volgende versie. Lang was het idee dat FHIR dan min of meer af zou zijn dat en vervolgens alleen nog backward compatibele wijzigingen zouden mogen. Inmiddels is duidelijk dat weliswaar veel FHIR content heel stabiel en beproefd is, en dus klaar om normatief te worden, maar veel andere content nog helemaal niet. Gino Canessa presenteerde een voorstel om delen van FHIR normatief te maken, maar andere nog niet. Dat gaat natuurlijk afhankelijkheden opleveren:
Er zou dan een normatieve core R6 komen, en modules die nog niet normatief zijn. Dit voorstel schetste de afhankelijkheden en de gevolgen ervan. Het idee dat niet alles in FHIR in een grote big bang normatief kan worden werd breed gedeeld. Ik ben benieuwd hoe dit verder gaat.
CDA
CDA? Dat is toch die oude standaard, die niemand meer wil gebruiken nu we FHIR hebben. Aan de ene kant wel, maar CDA wordt gewoon heel veel gebruikt in de wereld, en ook oude standaarden hebben werk nodig. Ook in CDA komen dus nog aanpassingen.
Wat ook goed nieuws is voor een “old hand” als mijzelf die af een toe met CDA moet werken, is de nieuwe site https://hl7.org/cda/ waarop alles wat met CDA te maken heeft mooi op een rijtje staat. CDA migreert trouwens meer en meer richting FHIR. Zo kan de FHIR Implementation Guide Builder gebruikt worden om CDA specificaties te maken en kunnen sommige FHIR datatypes in CDA gebruikt worden.
Geboren in Nederland: een IG!
Door Glenn Ederveen – wikiportret.nl, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=68678443
De IG is geballot (er is over gestemd en bijna klaar voor acceptatie). In deze IG wordt uitgewerkt hoe de zorg rond zwangerschap, foetus, moeder en kind in FHIR gemodelleerd wordt. Dat is geen open deur, want FHIR kent geen “foetus” resource. De relaties tussen moeder, een of meer foetussen en de geboren kinderen moeten dus in kaart gebracht worden, en bij voorkeur op internationaal gestandaardiseerde wijze. Hier ligt een gedegen stuk werk, waar de meerwaarde van het werk in Geboortezorg in Nederland binnenkort leidt tot een internationale standaard.
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.)
Photo by Jan Antonin Kolar on Unsplash
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?
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:
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.
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:
(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:
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.)
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.
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.
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:
(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.
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
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.
