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.

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.

 

 

 

 

 

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.

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.

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.

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.