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.
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.)
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
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.
In deze tijd van een pandemie van COVID-19 duikt de vraag op: wat kunnen we bijdragen aan het oplossen van deze crisis? En wat kunnen standaarden zoals HL7 bijdragen?
Allereerst geldt natuurlijk dat HL7 al veel bijdraagt: laboratoria en ziekenhuizen kunnen niet zonder HL7v2, o.a. het LSP gebruikt HL7v3 en FHIR speelt een grote rol bij BGZ en MedMij. Maar beter dan trots zijn op behaalde resultaten in het verleden is het te kijken naar uitdagingen die nog opgelost moeten worden. Dus: wat kan HL7 nog meer bijdragen?
Laten we wel wezen: standaarden invoeren waar ze nog niet gebruikt worden kost tijd. Op de korte termijn – nu – moet gewerkt worden met bestaande systemen of ad hoc oplossingen (zeg maar Excel of de telefoon). Maar zoals het er naar uit ziet is deze crisis voorlopig niet voorbij. Dat duurt waarschijnlijk tot er een vaccin is: een jaar of zelfs langer. Misschien kunnen de meest extreme maatregelen op een gegeven moment wat versoepeld worden, maar ook dan blijft het: direct mensen met klachten opsporen, isoleren, patiënten behandelen, schaarse capaciteit nauwlettend monitoren. En wordt het noodzakelijk schaalbare, beheersbare oplossingen te realiseren.
Gelukkig hebben we al een behoorlijke infrastructuur rond NICE, RIVM en de GGD’en. Neemt niet weg dat deze infrastructuur nu onder druk staat als nooit tevoren. Zonder twijfel is er meer nodig en mogelijk dan wat nu kan. Deze crisis kent ook heel specifieke problemen, van afstand houden tot de behandeling van deze groep patiënten.
Een overzicht: het zal zeker niet volledig zijn. Heb je aanvullingen of correcties, mail me op marcdegraauw@gmail.com.
Electronic Case Reporting
Bij het evalueren van de behandeling van corona-patiënten is informatie essentieel. We moeten zo spoedig mogelijk beoordelen wat het beste werkt en bij wie. Wanneer het aantal ziekenhuisopnames met 1/3 daalt, en het aantal patiënten wat vervolgens naar de IC moet ook met 1/3, is het aantal benodigde IC-bedden al gehalveerd. Ook zonder geneesmiddel is de optimale behandeling van belang. De ziekenhuizen werken al samen om een database met gegevens van IC-patiënten aan te leggen. Hetzelfde is nodig van niet-IC patiënten. Ook moet gemonitord worden waar en wanneer ziektegevallen opduiken. Het gaat dan om “publieke gezondheid”, dus niet de behandeling of overdracht van een individuele patiënt maar het beheersen en onder controle brengen van een uitbraak. (Dat gebeurt nu al met de huidige systemen van GGD’en RIVM, maar daar zal vast wat “op maat” te maken zijn voor deze ziekte.) Laten we kijken welke HL7 stukken in deze puzzel passen.
Er zijn HL7 standaarden voor Electronic Case Reporting (eCR): in CDA en FHIR. Beide zijn “US Realm”, dus toegespitst op de situatie in de Verenigde Staten. Dat maakt ze minder geschikt voor toepassing zonder aanpassing in Nederland. Zo kent b.v. het FHIR eCR profile een message infrastructuur die we hier niet zo zouden willen overnemen, en heeft de FHIR eCR Patient us-core-race wel, maar nl-core-humanname (met “onze” tussenvoegsels) niet. De eCR profielen kunnen wel een kader geven voor een Nederlandse invulling.
Daarnaast zijn – uiteraard – de bestaande standaarden nog niet toegespitst op COVID-19: het gaat om algemene profielen voor besmettelijke ziekten. Hoe zou een profiel voor COVID-19 er ongeveer uitzien? Een schets (disclaimer: ik ben geen arts, en hoewel ik al een tijd in ICT in de gezondheidszorg werk zullen artsen een dergelijk profiel moeten opstellen – dit is niet meer dan een indruk).
Demografische gegevens: geslacht, geboortedatum, locatie, identificatie, eventueel etniciteit (mogelijk is er een genetische component in mate bevattelijkheid)
We verkeren in Nederland in de gelukkige situatie dat een groot deel van deze benodigde componenten al gestandaardiseerd is in de BGZ en de onderliggende zorginformatiebouwstenen (zibs). Daarbij horen ook HL7 FHIR profielen. Een groot deel van het bovenstaande past in zibs voor Metingen, Medicatie, Klinische context etc. LOINC- en Snomedcodes voor COVID-19 zijn al uitgegeven door Nictiz. Veel van deze gegevens (maar zeker niet alle) zitten al in de datasets van de stichting NICE , de GGD’en het RIVM. Het is de rol van deze zorginstellingen en zorgprofessionals aan te geven verder wat nodig is: de bouwstenen zijn er al.
Wat er nog niet is, is een profiel voor COVID-19: wat willen we precies vastleggen en uitwisselen voor deze ziekte? Wanneer dat er wel is, kunnen we de bestaande componenten op een uniforme manier vullen. Ontbrekende delen kunnen we snel specificeren. Daarmee wordt het mogelijk een langdurige uitwisseling van deze essentiële gegevens op een beheersbare manier te regelen, direct vanuit het EPD. Want op korte termijn kunnen we de standaarden even overslaan, maar als dit virus een jaar of zelfs langer gevolgd moet worden, worden standaarden onontbeerlijk.
PGO’s en de thuispatiënt
Gegevens zijn ook nodig van patiënten die thuis uitzieken. Nu is er maar weinig inzicht in het verloop van die gevallen, en ook te weinig over factoren die ziekenhuisopname beïnvloeden. En zelfs van mensen met klachten, van wie nog niet duidelijk is of ze patiënt zijn, zoals gebruikers van de OLVG coronacheck. Hoe meer data, hoe beter.
In Nederland heeft MedMij PGO’s uitgerold, waarmee burgers hun eigen gezondsheidsgegevens kunnen inzien en delen. En belangrijker: waarmee ze gegevens toe kunnen voegen. Kunnen we die PGO’s op gaan gebruiken om de bevolking (nu ja, diegenen die deel willen nemen) te monitoren? Daarmee is het in principe mogelijk inzicht te krijgen in wie geen klachten hebben, wie klachten ontwikkelen en hoe dat verloopt. Binnenkort, wanneer er serologische testen beschikbaar komen waarmee massaal getest kan worden op antigenen en antilichamen van SARS-CoV2 kunnen ook die uitslagen gedeeld worden.
Welke gegevens zijn dan nodig? Het is feitelijk een deelverzameling van de eCR gegevens. Wederom een schets:
obesitas, chronische hartaandoeningen, longziekten (COPD, asthma), diabetes, immunogecompromitteerd, roker etc.
Familie en omgeving
personen met en zonder klachten in de directe omgeving, of getest en reeds genezen van COVID-19
Verloop/vitale functies
temperatuur, ademhaling, gewicht, lengte etc.
voeding, vochtopname, welbevinden etc.
Testuitslagen
van het lab of thuistests
Ook hier is het meeste al aanwezig als zelfmetingen in het PGO, alleen dan nog niet specifiek gemaakt voor wat je wilt weten van deze aandoening. Datzelfde geldt voor de klachten: wanneer je zinvolle informatie van heel veel burgers wilt, is gericht uitvragen wat je wilt weten nodig. Feitelijk is dit een verdere uitrol van de corona check van het OLVG, maar dan gebruikmakend van de PGO infrastructuur.
Capaciteitsbeheer en SANER
Op het chatforum van FHIR is ook veel te doen over COVID-19, en dat leidde heel snel tot een initiatief: SANER. Dit is een standaard-in-wording (een “Implementation Guide”) voor het uitwisselen van beschikbare resources in ziekenhuizen: aantallen bedden, beademingsapparaten etc. Dergelijke gegevens worden nu veelal uitgewisseld door ze te verzamelen en opnieuw in te voeren. Wanneer deze gegevens live vanuit de ziekenhuissystemen uitgewisseld kunnen worden met de landelijke databases scheelt dat veel werk en mogelijk fouten. Het SANER initiatief trekt veel belangstelling, er zijn dagelijkse meetings (betrokken partijen zijn onder andere Epic, Cerner en Microsoft) en laat zien in wat voor tempo nieuwe specificaties gemaakt kunnen worden.
(Update 31-3-2020: Dit artikel net geplaatst, en het de NOS meldde dat 2TWNTY4 een landelijk platform uitrolt voor beschikbaarheid van bedden.)
Nu verder, met standaarden
Gabrielle Speijer, radiotherapeut-oncoloog, zei onlangs in een interview: “De COVID-19 crisis vergt het uiterste van de zorg… (zo) … biedt SNOMED nieuwe COVID-19 gerelateerde termen. Dit levert uniforme data op die artsen en onderzoeksinstellingen gebruiken voor analyses om verdere verspreiding te voorkomen. Dit soort specifieke toepassingen vraagt om een robuust en betrouwbaar systeem, waar HL7 een belangrijke schakel in is.”.
Nogmaals de disclaimer: dit is een schets, zorgprofessionals moeten invullen wat precies nodig is. Het goede nieuws is: veel van de HL7 componenten die nodig zullen zijn, zijn er al. Wanneer we langere tijd met dit virus zullen leven, en daar ziet het wel naar uit, moeten we zorgen dat we op een gestructureerde, beheersbare manier de gegevens delen die nodig zijn. HL7, LOINC en Snomed CT zijn daar een onlosmakelijk onderdeel van.
Een van de meest actieve HL7 Working Groups is die rond “Clinical Genomics”. Niet vreemd natuurlijk, sinds het Human Genome Project in 2003 het volledige menselijk genoom in kaart bracht, heeft DNA sequencing een grote vlucht genomen. Voor een paar tientjes kun je privé al je DNA laten analyseren om de Neanderthaler in jezelf te ontdekken (ongeveer 2%). Ook de medische toepassing neemt toe – het is een kwestie van tijd voor een genetische analyse standaard wordt voor zelfs de meest eenvoudige aandoeningen.
Klinische genetica draagt ook bij aan de belofte van “precision medicine”: per persoon op maat gemaakte optimale behandelingen. Genetische gegevens spelen daarbij uiteraard een belangrijke rol. Het gaat dan niet alleen om genetische data, maar ook de familie-anamnese (welke familieleden hadden welke ziektes of afwijkingen) en individuele fenotypische eigenschappen: genetische data hebben pas relevantie wanneer ze (kunnen) leiden tot een probleem voor de mens.
De FHIR implementatie van Clinical Genomics gaat uit van een Diagnostic Report. Daarin worden genetische bevindingen opgenomen:
Heel kort: een Sequence is een weergave van een stukje DNA van een mens (of ander levend wezen – in dit artikel richten we ons op mensen). Op zich is dit niet meer dan een reeks betekenisloze ATCG-letters. Een Variant is een bekende variatie in het menselijk genoom – een allel. Een Haplotype is een aantal allelen (of SNP’s, puntmutaties) die normaliter samen overerven. Een verzameling Haplotypen beschrijft het Genotype van een mens. Dit zijn allemaal GenomicFindings, en dat is weer een specialisatie van een FHIR Observation. Uiteraard is dit een vogelvluchtperspectief , voor details zie de FHIR pagina van Clinical Genomics.
Een ander onderwerp op de WGM was het informatiemodel van Clinical Genomics. Hierin worden het domein geanalyseerd en beschreven in UML. Bovenstaand plaatje is een klein deel daarvan. Daarbij gaat het om verschillende manieren om een stuk genoom te lokaliseren (coördinaten versus cytoband), introns, exons, et cetera. Het is een terugkerend thema in meerdere HL7 werkgroepen: de behoefte een aan abstract informatiemodel, waarbij het onderliggende domein beschreven wordt zonder aan concrete syntax als FHIR, CDA of HL7v2 te hoeven denken.
Een ander onderwerp was de aanstaande integratie van Phenopackets. Phenopackets is een standaard voor het uitwisselen van fenotypische informatie, bijvoorbeeld Microtia (een onderontwikkeld oor). De fenotypische abnormaliteiten worden (meestal) gecodeerd met de Human Phenotype Ontology (HPO).
Met phenopackets wordt informatie over fenotypische afwijkingen, familie en afstamming, genetische informatie en diagnose gebundeld. Phenopackets is geen HL7 standaard, maar van onder andere de Global Alliance for Genetics & Health, het Monarch Initiative (HPO) en Orphanet (zeldzame ziekten). Er is al een (draft) FHIR specificatie van phenopackets. Op de WGM is besloten integratie van deze draft met de FHIR specificatie van Clinical Genomics op te pakken. Een flinke uitbreiding van het bestaande model met fenotypische informatie en het belooft een integraal genetisch en fenotypisch, klinisch relevant, model voor uitwisseling.
Clinical Genomics is een van de meest dynamische gebieden in medische informatica en HL7. De ontwikkelingen volgen is meer dan de moeite waard. HL7 en FHIR lopen – met andere organisaties – voorop op dit gebied.