Category: hl7

Posted on

HL7 en de coronacrisis

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?

SARS-CoV-2 without background

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.

COVID-19 outbreak the Netherlands per capita cases map

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

  1. Demografische gegevens: geslacht, geboortedatum, locatie, identificatie, eventueel etniciteit (mogelijk is er een genetische component in mate bevattelijkheid)
  2. Klachten en diagnose
    • koorts, (droge) hoest, vermoeidheid, kortademigheid, spierpijn, hoofdpijn, misselijkheid, loopneus, reuk/smaak etc.
    • dit alles waarschijnlijk met een schaal van mate van ernst
    • longontsteking, ARDS ( acute respiratory distress syndrome) etc.
    • aanvang klachten, verloop tot opname etc.
  3. Beeldvorming
    • CT: matglasafwijkingen, reversed halo, “crazy pavement” etc.
  4. Voorgeschiedenis
    • obesitas, chronische hartaandoeningen, longziekten (COPD, asthma, emfyseem), diabetes, immunogecompromitteerd, roker etc.
  5. Behandelplan
    • opname IC, beademing, etc.
  6. Medicatie
    • chloroquine, hydroxychloroquine en remdesivir (allen experimenteel) etc.
  7. Verloop/vitale functies
    • temperatuur, bloeddruk, pols, etc.
  8. Uitslagen
    • getest op SARS-CoV2 ja/nee, uitslag (nu PCR, LOINC 94315-9 en 94314-2), binnenkort antilichaam/antigen)
    • influenza, rhinovirus, enterovirus, corona (OC43m 229E, HKU1, NL63) etc.
    • serologie (niet diagnostisch, wel voor verloop): diverse bloedwaarden

(Bronnen: o.a. LCI, SWAB ,CDC )

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.

Photo by Paul Hanaoka on Unsplash

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:

  1. Demografische gegevens: geslacht, geboortedatum, locatie
  2. Klachten
    • koorts, (droge) hoest, vermoeidheid, kortademigheid, spierpijn, hoofdpijn, misselijkheid, verkoudheid, reuk/smaak etc.
  3. Voorgeschiedenis
    • obesitas, chronische hartaandoeningen, longziekten (COPD, asthma), diabetes, immunogecompromitteerd, roker etc.
  4. Familie en omgeving
    • personen met en zonder klachten in de directe omgeving, of getest en reeds genezen van COVID-19
  5. Verloop/vitale functies
    • temperatuur, ademhaling, gewicht, lengte etc.
    • voeding, vochtopname, welbevinden etc.
  6. 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

Photo by Martha Dominguez de Gouveia on Unsplash

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.

Posted on

Klinische genetica op de HL7 WGM Atlanta

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.

PLoSBiol3.5.Fig7ChromosomesAluFish

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.

Posted on

Kankerregistratie en mCode op de HL7 WGM in Atlanta

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

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

mCode overzicht data model
mCode overzicht data model (klik voor vergroting)

 

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

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

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

 

 

 

 

 

Posted on

De “International Patient Summary” op de HL7 WGM Atlanta

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

Het Marriott Marquis Hotel waar de WGM is.

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

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

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

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

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

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

Posted on

Is RIMBAA a Mistake?

HL7v3 is a framework for developing messages in healthcare. Unlike its predecessor, v2, HL7v3 has at its core an information model, the RIM (Reference Information Model). The RIM contains classes and relations. From the RIM actual healthcare messages are derived, usually as XML instances. This is what HL7v3 does in a nutshell, and its focus is clearly on messaging, nothing else.

Recently a new school of thought is gaining ground: RIMBAA (RIM-Based Application Architectures). RIMBAA seeks to use the RIM not solely as the basis for messages, but to use it as the basis for an entire EHR (Electronic Health Record) system. The RIM, after all, is quite rich, and if it is rich enough to describe messages which care providers exchange between them, why not use it to describe the data contained in an EHR itself? This also makes deriving messages from my EHR a piece of cake.

Here’s why not.

Suppose I build an EHR from a certain HL7v3 version X (there are plenty of versions, called “ballots”, to choose from) and I also exchange messages with my colleagues using version X. If we now decide to upgrade the messages to version Y, I’m forced to do a double update: I have to upgrade not only my messaging framework to version Y, I also have to upgrade my entire EHR to version Y.

RIMBAA thus leads to tightly coupled systems. In a loosely coupled architecture, systems are black boxes: each system just has to know the interface (messages) of another system to communicate. In loosely coupled systems, each system can be upgraded or changed independent of other systems, as long as the interfaces remain unchanged. Loose coupling is a core design principle of Internet-scale messaging, and RIMBAA violates it.

Moreover, if RIMBAA gains wide acceptance, a majority of EHR’s would become RIM-based, and thus EHR’s would be very alike. Good, not? Since they’re so alike, won’t it be easy to communicate? Nope. If all, or many, EHR’s follow the RIM, there will be less competition, which will stifle innovation. Having EHR’s which are not based on the RIM enables healthcare developers to adopt any wild, new, unthought-of innovation they wish, as long as they keep supporting the common messages. This difference allows the full creativity of healthcare providers to be expressed in their systems, and is good for innovation and competition, major drivers of human progress.

With RIMBAA, it’s either taking what the RIM offers, or leaving RIMBAA. The latter is probably the best choice: take some inspiration from the RIM where useful, develop your EHR, and forget there ever was a link. I’ve seen a lot of efforts to harmonize data models, and it seldom works on a large scale, not even in a single large company. Different needs are simply too different. For messaging, a common data model is a necessity. For application architectures, it is a commodity at best and a nuisance at worst.

RIMBAA (and similar initiatives), in short, will lead to systems which are hard to upgrade, will stifle innovation and will hinder progress. It is much better to follow HL7v3’s original course and keep standards for messaging separate from standards for EHR’s. RIMBAA violates the fundamental design pattern of loose coupling and is a mistake.

Posted on

Implementing Healthcare Messaging with XML

Last week Monday I gave a presentation on XML 2007 titled “Implementing Healthcare Messaging with XML” for a very attentive and responsive audience, chaired by Tony Coates. David Orchard and Glen Daniels of multiple WS-standards were there, and I had an interesting chat with them afterwards on the layering problems of WSDL mentioned in my presentation. Jon Bosak inquired about ebXML – which we hadn’t used because it did not seem to get any traction from IBM and Microsoft at the time. With hindsight, looking at what ebXML (ebMS specifically) delivered years ago and the time the WS-* stack took, one wonders whether this was such a wise decision… Anyway, it was great to have such a responsive crowd.

Posted on

Axioms of Versioning 2

I’ve written a new version of ‘Axioms of Versioning‘. I extended the formalization to get a grasp of the concept of ‘Semantic Backward Compatibility in HL7v3, which I believe is flawed (quote: “Objective of backward model compatibility is that a receiver expecting an ‘old’ version will not misinterpret content sent from a new version”). It seems to be the reverse of the position of the W3C TAG in ‘Extending and Versioning Languages: Terminology‘, and the position I would defend myself. Yet the interaction of new senders with old receivers was not sufficiently explored in my Axioms.

It turns out that exploration of this notion leads to quite natural definitions of ‘may ignore’ and ‘must understand’ semantics. The HL7v3 notion is probably best characterized by the concept of ‘partial semantical forward compatibility’ in my new Axioms. The concept is also close to, if not the same as, the TAG’s ‘Partial Understanding‘.

It really thrilled me to see how helpful my formalisms were in exploring the notions in HL7v3, and uncovering the – I think – hidden meaning in it.