Keuzes bij Standaardisering

Inleiding

Zo eenvoudig als "Informatie-uitwisseling in de zorg" klinkt, zo complex blijkt het vaak te zijn. Nieuwe inzichten in de beste behandeling van patiënten vragen vaak om een multidisciplinaire aanpak, waarbij bijvoorbeeld het diabetesteam van een ziekenhuis al uit vier verschillende disciplines kan bestaan: de diabetoloog, de diabetesverpleegkundige, de diëtist en de podoloog. En dan vaak nog een manager en een secretaresse om het organisatorisch ook nog eens rond te krijgen. Verschillende disciplines met hun eigen taalgebruik en idioom, hun eigen gewoontes en (on)hebbelijkheden. Om intern de activiteiten goed op elkaar af te stemmen moet gezocht worden naar eenheid van taal en eenheid van informatieoverdracht. Dat is binnen een team goed te ontwikkelen, te leren en af te spreken, zij het dat er per team een unieke vorm ontstaat die niet goed vergelijkbaar is met andere teams in het land of internationaal. In het kader van de zorg wordt er natuurlijk informatie uitgewisseld met medisch ondersteunende afdelingen, zoals de klinische laboratoria en de beeldvormende techniek (röntgen, echo, CT, etc.). Deze afdelingen stellen zo hun eigen eisen aan de informatie die moet worden aangeleverd om de patiënt goed te kunnen onderzoeken en een gericht verslag van het onderzoek uit te kunnen brengen. Vervolgens ontstaat de uitdaging om informatie uit te wisselen met zorgverleners die geen onderdeel uitmaken van het team, maar wel goed betrokken moeten zijn en blijven. In het voorbeeld van de diabetes, zijn dat in ieder geval de huisarts, de doktersassistente en de oogarts. Uiteindelijk zal ook nog verantwoording moeten worden afgelegd over de verleende zorg, zowel aan de verschillende financiers (zorgverzekeraars voor de zorgverzekering, zorgkantoren/CAK voor de AWBZ, gemeentes voor de WMO) als aan de inspectie, het centraal bureau voor de statistiek en een variëteit van koepelorganisaties of door hen ingeschakelde onderzoeksbureaus.

Health Level 7 (HL7) is een familie van internationale standaarden die de betekenisvolle uitwisseling van informatie in de zorg ondersteunt. Om ondersteuning aan de verschillende vormen van informatie-uitwisseling in de zorg zelf te kunnen vormgeven, zijn ook verschillende standaarden binnen de HL7 familie ontstaan. In deze bijdrage wil ik ingaan op de keuzes die hierbij gemaakt kunnen worden en welke richtlijnen je daarbij zou kunnen hanteren. HL7 als familie van standaarden schrijft niet voor in welk geval je welke standaard moet gebruiken, maar eenduidige keuzes hierin vergroten natuurlijk wel de interoperabiliteit tussen informatiesystemen in de zorg. Door verder in te gaan op het zorgproces voor diabetici wil ik illustreren voor welke uitdaging we staan als het gaat om informatie-uitwisseling. Een beknopt overzicht van de HL7 familie van standaarden leidt tot inzicht de rol die de verschillende HL7 standaarden hierbij kunnen spelen. Vervolgens zullen de meer algemene keuzes bij de toepassing van HL7 aan de orde komen, waarbij een speciale plaats wordt ingeruimd voor de inhoud van de uitwisseling. Ook dit licht ik weer toe aan de hand van de diabetespatiënt. Tenslotte zal ik ingaan op de wijze waarop ook in uw praktijk gebruik kan worden gemaakt van de HL7 standaarden.

De uitdaging

Inhoudelijk is informatie-uitwisseling in de zorg al niet eenvoudig, zoals in de inleiding aangegeven, qua informatiesystemen ziet het er niet veel beter uit. Nemen we de diabetespatiënt, dan heeft de huisarts een eigen Huisartseninformatiesysteem (HIS), bijvoorbeeld het Medicom systeem van softwareleverancier PharmaPartners . Het HIS is niet specifiek op diabetespatiënten ingericht, maar kan wel mogelijkheden bevatten om diabetespatiënten specifiek te volgen en hiervan bepaalde meetwaarden op te slaan. De specialist in het ziekenhuis (de diabetoloog) kan wellicht wel gebruik maken van een toegesneden systeem voor de diabeteszorg, bijvoorbeeld zoals dat door leverancier Chipsoft binnen het pakket EZIS is ingericht. Wanneer echter de oogarts wordt ingeschakeld voor de jaarlijkse controle zal deze veelal geen gebruik maken van dezelfde EZIS module voor de diabeteszorg, maar een eigen EZIS module hebben waarin specifiek de koppelingen met de oogheelkundige apparatuur zijn ondergebracht. Deze koppeling van modules binnen het systeem van één leverancier is wellicht nog goed te overzien. Echter, wanneer onderzoek wordt aangevraagd bij de klinische laboratoria, ter bepaling van bloedsuiker, hemoglobine en cholesterol van de diabetespatiënt, zullen we zeker een systeemgrens overschrijden: Leverancier Chipsoft heeft geen module voor laboratoria en (in Nederland) worden de laboratoria inmiddels alleen door onafhankelijke softwareleveranciers ondersteund, zoals met het GLIMS systeem van MIPS.

Hierboven is aangegeven waar de verschillende systemen van de betrokken zorgverleners van elkaar verschillen. Tegelijkertijd is er één punt waar veel van de informatie samenkomt: bij de diabetesverpleegkundige. Deze specialistisch verpleegkundige is vaak eerste aanspreekpunt voor de patiënt en moet juist het overzicht houden en de planning en uitvoering van benodigde en afgesproken zorg bewaken. Daarmee is de diabetesverpleegkundige de spin in het web van de ketenzorg die door de verschillende personen en instellingen in de zorgketen aan de diabetespatiënt wordt verleend. Er zijn inmiddels informatiesystemen ontwikkeld die ketenzorg ondersteunen, zoals Vital for Diabetes van VitalHealth Software. Hiermee is in het eenvoudige voorbeeld hierboven echter een vierde autonoom informatiesysteem van een afzonderlijke leverancier geïntroduceerd binnen de ketenzorg voor diabetespatiënten, zie Figuur 1. Aangezien elk van deze informatiesystemen heel specifiek de werkprocessen van de betrokken zorgverleners ondersteund, is het niet voor de hand liggend om te veronderstellen dat men wel van elkaars systemen gebruik zou kunnen maken. Ook in de huidige papieren wereld kunnen zorgverleners maar slecht wijs uit elkaars dossiers, en dit is in de elektronische praktijk niet anders. Eén gemeenschappelijk dossier kan voor het diabetesteam in het ziekenhuis een prima oplossing zijn, maar voor die zorgverleners waarvoor diabetespatiënten slechts een klein deel van hun totale populatie uitmaken, zal het werken in een specifiek diabetesdossier een (onoverkomelijke) extra belasting vormen die tijd en geld kost en ten koste gaat van de kwaliteit van de informatie-uitwisseling (meer fouten).

Een tweede punt waar alle informatie samen zou kunnen komen is bij de patiënt zelf. Zo wordt door de Diabetes Vereniging Nederland (DVN) een online persoonlijk diabetes dossier ontwikkeld op mijndiabetes.nl. Internationaal zijn Google Health en Microsoft HealthVault twee belangrijke spelers die ook persoonlijke zorgdossiers willen gaan leveren. Op dit moment is het echter nog niet zo eenvoudig om alle informatie die bij de zorgverleners beschikbaar is ook in het persoonlijk zorgdossier inzichtelijk te maken. Ook spelen discussies over de privacy en de begrijpelijkheid van de gegevens een belangrijke rol: informatie die voor een diabetoloog helder en duidelijk is zal wellicht door de patiënt niet of verkeerd begrepen worden. Het is echter wel een trend die de toekomst lijkt te hebben, waarmee het aantal systemen dat informatie moet uitwisselen wederom is toegenomen.

Dat er ook daadwerkelijk informatie in de zorgketen uitgewisseld moet worden kan worden geïllustreerd aan de hand van de kwaliteitscriteria die voor diabeteszorg zijn geformuleerd. Deze zijn weergegeven in tabel 1. De eerste groep kwaliteitscriteria zijn de procesvariabelen, waarbij per patiënt kan worden vastgesteld of de voorgeschreven jaarlijkse controles zijn uitgevoerd. De tweede groep kwaliteitscriteria zijn de direct meetbare uitkomsten, in dit geval de hemoglobine- en cholesterolwaarden. Uiteraard gelden deze waarden voor de individuele patiënt, maar de kwaliteit van de diabeteszorg kan niet afgemeten worden aan één patiënt en gaat daarom over het percentage van de hele patiëntengroep dat onder de gedefinieerde drempelwaarden blijft. Tot slotte gelden er de indirecte uitkomsten van de geleverde diabeteszorg, in termen van het optreden van ongewenste en te voorkomen incidenten bij diabetespatiënten: amputaties, nierziekten en overlijden als gevolg van hart- en vaatziekten.

Tabel 1 Kwaliteit van diabeteszorg volgens de OECD, gebaseerd op [1]

Area Indicator name Toelichting

Process of care Annual HbA1c testing Jaarlijks testen van het (geglyceerd) hemoglobinegehalte

Annual LDL cholesterol testing Jaarlijks testen van het cholesterolniveau

Annual screening for nephropathy Jaarlijkse controle op nierfalen

Annual eye examination Jaarlijks oogonderzoek

Proximal outcomes HbA1c control Percentage patiënten dat onder drempelwaarde voor hemoglobine blijft

LDL cholesterol control Percentage patiënten dat onder drempelwaarde voor cholesterol blijft

Distal outcomes Lower-extremity amputation rates

Kidney disease in persons with diabetes

Cardiovascular mortality in people with diabetes

Bovenstaande schets van de diabeteszorg laat zien dat, wanneer (zoals in Engeland inmiddels verplicht) een huisartsengroep wil rapporteren over de wijze waarop er voor diabetespatiënten wordt gezorgd, er gestructureerde gegevens aanwezig moeten zijn die hun oorsprong vinden in verschillende informatiesystemen bij verschillende zorginstellingen in de regio, die samen de ketenzorg vormgeven. Helemaal spannend wordt het wanneer sprake is van vrije keuze van patiënten voor hun zorgaanbieder, want dan wordt het bloedonderzoek wellicht ineens heel ergens anders (bijvoorbeeld dicht bij het werk) uitgevoerd dan waar de zorgketen normaal de ketenzorg voor diabetespatiënten verleend. Voor het uitwisselen van informatie is het daarom handig om te kiezen voor landelijke of internationale standaarden, zodat het eenvoudiger wordt om met willekeurige systemen van willekeurige zorgaanbieders te kunnen koppelen. Health Level 7 is zo'n internationale standaard.

De HL7 familie van standaarden

Health Level Seven refereert aan de zevende laag van het ISO Open Systems Interconnection (OSI) model, waar de applicatielogica in interactie met het netwerk wordt vormgegeven. HL7 International is de organisatie die de HL7 standaarden ontwikkelt en beheert. HL7 International is van oorsprong een Amerikaanse organisatie die in 2011 haar 25-jarig bestaan viert. Bij HL7 International zijn meer dan 30 onafhankelijke organisaties aangesloten die HL7 binnen het eigen land vertegenwoordigen. HL7 Nederland is één van deze zogenaamde Affiliates en houdt zich sinds 1992 bezig met de vertaling, toepassing, verspreiding en beheer van de standaarden voor Nederland (en in mindere mate het Nederlandstalige deel van België). De missie van HL7 is als volgt geformuleerd:

HL7 provides standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients. In all of our processes we exhibit timeliness, scientific rigor and technical expertise without compromising transparency, accountability, practicality, or our willingness to put the needs of our stakeholders first.

Centraal staat derhalve het aanbieden van standaarden voor interoperabiliteit in de zorg, met de focus op verbetering van het zorgproces. Daarbij maakt HL7 gebruik van andere beschikbare standaarden. Dit speelt in ieder geval op de niveaus 1 tot en met 6 van het ISO OSI model, maar zeker ook voor niet-zorgspecifieke standaarden zoals XML of voor standaarden voor medische terminologie zoals SNOMED. HL7 streeft ernaar om technologie onafhankelijke standaarden te ontwikkelen: ze beschrijven alleen de logische en functionele eisen en de keuzen voor de modellering van de te ondersteunen interoperabiliteit tussen applicaties. Om het geheel ook technisch werkend te krijgen zijn er één of meer Implementable Technology Specifications (ITS) opgesteld voor de standaarden. XML speelt een belangrijke rol in de ITS van verschillende HL7 standaarden. Daarmee kan HL7 ook gezien worden als een standaard die beschrijft hoe je XML binnen de zorg eenduidig toe kan passen.

De oudste en meest gebruikte HL7 standaard is de versie 2 berichtenstandaard. Na de eerste publicaties eind jaren 80 van de vorige eeuw is in 1996 versie 2.2 als ANSI-standaard vastgesteld. In 2007 is HL7 versie 2.6 vastgesteld en er wordt momenteel gewerkt aan uitbreidingen voor versie 2.7. HL7 versie 2 wordt wel gezien als het werkpaard van HL7, omdat het al zoveel jaren trouwe dienst bewijst, met name bij de informatie-uitwisseling binnen ziekenhuizen. Om de hierboven beschreven technologie-onafhankelijkheid te illustreren zijn in Figuur 2 twee verschillende implementaties van een (stukje van) een HL7 v2 bericht opgenomen: de eerste in de oorspronkelijke HL7-eigen pipe-bar notatie en de tweede conform de XML ITS voor v2.3.1. [2]

Figuur 2 Twee representaties van hetzelfde (stukje) HL7 v2 bericht

De doorontwikkeling van versie 2 werd bemoeilijkt door het feit dat er geen sprake was van één gemeenschappelijk gegevensmodel, waardoor dezelfde informatie in verschillende (onderdelen van) berichten op een andere manier moesten worden gerepresenteerd. Dit was één van de aanleidingen om eind jaren '90 van de vorige eeuw versie 3 te ontwikkelen, met een centraal HL7 Reference Information Model (RIM) om een eenduidige representatie en interpretatie van gegevens mogelijk te maken. De HL7 v3 berichten kennen eigenlijk alleen een XML ITS. Gelijktijdig aan de ontwikkeling van de v3 berichten is ook gewerkt aan een model waarbij documenten konden worden uitgewisseld. Dit is neergelegd in de Clinical Document Architecture (CDA) standaard, die ook gebaseerd is op het RIM. Daarmee wordt de CDA standaard tot HL7 v3 gerekend, al is het dus uitdrukkelijk geen berichtenstandaard. Ook CDA wordt vrijwel uitsluitend op basis van XML geïmplementeerd. Naast berichten en documenten zijn binnen HL7 v3 inmiddels ook services gedocumenteerd en in samenwerking met de Object Management Group van een ITS voorzien. Daarmee kent HL7 v3 dus drie verschijningsvormen: berichten, documenten en services, allen gebaseerd op één en hetzelfde Reference Information Model. De vraag is natuurlijk wanneer welke vorm het best toepasbaar is. Daarvoor is het goed om de verschillen even op een rijtje te zetten.

Het verschil tussen documenten, berichten en services

Het doel van HL7 documenten, berichten en services is vergelijkbaar: het verzorgen van interoperabiliteit met het doel de zorg te verbeteren. Het zijn daarom allemaal standaarden die gericht zijn op informatie-uitwisseling in de zorg met meer of minder uitgesproken aannames over het gedrag van de systemen die de informatie uitwisselen. In Tabel 1 staan de verschillen tussen de drie paradigma's beknopt weergegeven. Het voert te ver om daar op deze plaats uitgebreid bij stil te staan.

Tabel 2 Karakteristieke eigenschappen waarin de drie paradigma's van elkaar verschillen

Berichten Documenten Services

Bestaan alleen in de uitwisseling tussen informatiesystemen (non-persistent) Hebben zelfstandig bestaansrecht, ook buiten informatiesystemen (persistent) Hebben zelfstandig bestaansrecht, maar alleen in de wereld van informatiesystemen

Zijn alleen door specifieke informatiesystemen te interpreteren en te verwerken Zijn door informatiesystemen én mensen te interpreteren en te verwerken Zijn alleen door specifieke informatiesystemen te gebruiken

Kunnen gestructureerde en ongestructuureerde gegevens bevatten (encapsulated blobs) Kunnen gestructureerde en ongestructureerde gegevens bevatten (free text) Kunnen gestructureerde en ongestructureerde gegevens bewerken

Lenen zich goed voor snelle interactieve verwerking Lenen zich goed voor store-and-forward-achtige toepassingen zonder interactieve urgentie Lenen zich goed voor geïntegreerde verwerking binnen informatiesystemen

Passen goed bij interactieve informatiesystemen Passen goed bij papieren correspondentie Passen goed bij een moderne service gebaseerde architectuur

Verwachten beperkt gespecificeerd gedrag aan beide zijden van de uitwisseling Kennen geen inherente verwachtingen over het gedrag van de ontvangende partij Omvatten de specificatie van het verwachte gedrag op basis van de service aanroep

Om de verschillen in gebruik van berichten, documenten en services te illustreren wil ik teruggaan naar het zorgproces van de diabetespatiënt. Wanneer de diabetoloog vanuit het elektronisch patiëntendossier een laboratoriumaanvraag plaatst voor de bepaling van de HbA1c in het bloed, gebeurt dit in de huidige Nederlandse praktijk meestal met een HL7 v2.4 bericht. Hierin staan de patiëntgegevens en het type onderzoek dat wordt aangevraagd. Het laboratoriumsysteem antwoord met een acknowledgement: de aanvraag is in goede orde ontvangen. Tussentijds kan het laboratoriumsysteem, refererend aan het gezamenlijke ordernummer, de status van het onderzoek doorgeven: bloed is afgenomen, bepaling is uitgevoerd, bepaling is gecontroleerd en vrijgegeven. Afhankelijk van de afspraken in het ziekenhuis kunnen de voorlopige en definitieve uitslagen afzonderlijk worden gerapporteerd. Ook is het mogelijk om vanuit het laboratorium aan te geven dat een bepaalde uitslag om directe actie van de arts vraagt. Het is dan aan het EPD-systeem van de diabetoloog om actie te ondernemen. Deze opvolging van communicatie is netjes beschreven in de HL7 v2.4 standaard en de inhoud van de berichten is tot op veldniveau gespecificeerd.

De diabetoloog zal na het consult, waar het bloedonderzoek en andere onderzoeken met de patiënt zijn besproken, een verslag maken dat naar de huisarts en de diabetesverpleegkundige wordt gestuurd. Hiervoor wordt een document gebruikt, analoog aan de brief die de specialist vroeger aan de huisarts schreef. Het is van belang dat hier netjes en in samenhang de problematiek, onderzoeken, bevindingen en conclusies van de diabetoloog vermeld staan. In dit document wordt ook de laboratoriumuitslag voor de HbA1c vermeld, maar nu niet in de vorm van een segment in een HL7 v2.4 bericht, maar als onderdeel van de tekst van de brief, in CDA formaat. Dit kan gewoon als "platte tekst" worden weergegeven, maar in aanvulling ook als gecodeerde gegevens volgens het HL7 v3 RIM. Dit laatste maakt het mogelijk om de inhoud van het document gestructureerd op te slaan in het huisartseninformatiesysteem en/of in het ketenzorgsysteem van de diabetesverpleegkundige. Alleen als de HbA1c waarde gestructureerd wordt opgeslagen is het mogelijk om zonder aanvullende handelingen de door de inspectie gevraagde kwaliteitsindicator te berekenen: hoeveel procent van de populatie blijft onder de drempelwaarde voor (geglyceerd) hemoglobine.

Inmiddels heeft onze patiënt een moderne bloedsuikermeter aangeschaft, waarmee regelmatig het bloedsuikergehalte wordt gemeten. De meter communiceert draadloos met de insulinepomp om eenvoudiger de juiste dosering te kunnen bepalen. Hiervoor wordt gebruik gemaakt van een service-call: als de meting is uitgevoerd wordt automatisch de registratieservice in de software van de insulinepomp aangeroepen, waardoor de gemeten waarde wordt toegevoegd aan de historie van bloedwaarden en de insulinepomp aan het rekenen slaat om de juiste dosering te bepalen. Tegelijk komen de gegevens via een aanvullende service-call ook beschikbaar op de iPhone app waarop suggesties worden gedaan voor sportieve activiteiten om het bloedsuikergehalte op peil te houden.

Samenhang op de inhoud

Uit bovenstaand voorbeeld wordt duidelijk dat dezelfde inhoud in verschillende vormen kan worden gecommuniceerd. Het is dan natuurlijk wel van belang om ook daadwerkelijk dezelfde representatie van de inhoud te hanteren. Dit vraagt om afspraken op verschillende niveaus van documenten, berichten en services. Al op het hoogste niveau moet duidelijk zijn dat we het bijvoorbeeld over dezelfde patiënt hebben. Hiervoor heeft HL7 de zogenaamde CMETs gedefinieerd: eenduidige beschrijvingen van gemeenschappelijke elementen, zoals patiënt, arts, verwanten, zorginstelling, etc. Op een niveau lager worden in een document afzonderlijke secties onderkend, bevat een bericht diverse onderdelen en wordt een service ook met een vaste structuur van parameters aangeroepen. Wanneer dezelfde structuur moet worden gerepresenteerd kunnen zogenaamde templates worden gebruikt: beschrijvingen die eisen stellen aan de structuur van onderdelen van een document, bericht of service-parameter. Deze templates kunnen ook een niveau dieper gaan, waar de beschrijving van specifieke velden beschreven worden, zoals de diagnose diabetes of de HbA1c waarde. Deze HbA1c meetwaarde wordt bijvoorbeeld standaard gerepresenteerd als een observation met een code, tijdsaanduiding en waarde. Elk van deze drie elementen kennen een ISO/HL7 datatype, dat aanmerkelijk complexer kan zijn dan de standaard datatypes die door een gemiddelde programmeertaal worden ondersteund. Zo is de code voor HbA1c van het datatype CD en ziet er (in XML codering) als volgt uit:

Hiermee zijn we bij een laatste onderdeel van de inhoudelijke specificatie aangekomen: de zogenaamde vocabulary bindings. Veel gecodeerde elementen verwijzen naar een specifiek vocabulaire of terminologie systeem. Twee internationaal veelgebruikte vocabulaires in de zorg zijn SNOMED en LOINC, maar in Nederland kennen we voor medicatie bijvoorbeeld de G-Standaard en zo zijn er nog vele andere standaard coderingen, al dan niet onderdeel van een gestructureerd terminologiesysteem.

De intuïtieve samenhang tussen al deze niveaus is weergegeven in Figuur 3. Hierbij is het onderscheid tussen de zogenaamde levels in CDA weergegeven: Level 1 geeft alleen structuur aan de header waar gegevens over patiënt, arts en document zijn voorgeschreven, maar de body geen verdere structuur kent. Level 2 bepaalt een soort inhoudsopgave voor de body in secties. Een veelgebruikte inhoudsopgave is die van het Continuity of Care Document (CCD). Wat er in de secties moet staan is echter niet beschreven en niet gecodeerd. Dat laatste gebeurt wel op level 3, waarbij zowel leesbare tekst als gecodeerde inhoud verplicht wordt gesteld. Aan de kant van de berichten staat een geheel andere volgorde: triggers en interactions bepalen waarom en tussen welke systemen er berichten worden uitgewisseld. Het Message Information Model beschrijft de logische inhoud van de berichten, terwijl de Hierarchical Message Description aangeeft hoe al deze elementen in volgorde geplaatst moeten worden. Zowel CDA als HL7 v3 berichten kennen een XML ITS om een eenduidige weergave van de logische inhoud te garanderen.

Figuur 3 Samenhang op inhoud tussen documenten en berichten

Tot slot

De informatie-uitwisseling tussen systemen in de zorg vraagt om een behoorlijk uitgebreid arsenaal aan standaarden. Er zijn veel verschillende disciplines betrokken bij de zorg en elk van deze disciplines hebben hun eigen werkprocessen en ondersteunende informatiesystemen. De noodzaak tot uitwisseling van gegevens wordt groter naarmate er meer geautomatiseerde informatiesystemen worden gebruikt en er hogere eisen worden gesteld aan het automatisch verwerken van zorginhoudelijke gegevens, zoals het rapporteren van een scala aan kwaliteitsindicatoren. Ook de opkomst en verbreiding van beslissingsondersteunende systemen in de zorg vragen om meer gestructureerde en gecodeerde gegevens uit verschillende bronnen. Internationale standaardisatie organisaties doen hun best om eenheid van representatie en interpretatie van deze zorginhoudelijke gegevens mogelijk te maken, waardoor semantische en pragmatische (of organisatorische) interoperabiliteit tussen informatiesystemen kan worden verwezenlijkt.

De complexiteit van deze opgave is echter enorm, temeer omdat er verschillende verschijningsvormen zijn van dezelfde inhoudelijke gegevens: in berichten, documenten en services. Methodisch en modelmatig werken is derhalve geboden. HL7 gebruikt hiervoor verschillende methoden en modellen. De basis wordt gevormd door het Reference Information Model (RIM) waarop alle informatiemodellen binnen HL7 worden gebaseerd. Methodisch beschrijft het HL7 Develpment Framework (HDF) de stappen die doorlopen moeten worden van usecase tot standaardspecificatie en implementatietechnologie. Om de samenhang tussen de verschillende projecten en standaarden in de HL7 familie te bewaren wordt het Services Aware Interoperability Framework (SAIF) gehanteerd. Maar uiteindelijk draait de hele ontwikkeling van standaarden vooral om mensen, processen en tools om het werk goed uit te kunnen voeren.

Ik kan me voorstellen dat u, wanneer u een speler bent in de informatievoorziening van de zorgketen voor diabetespatiënten, u zich afvraagt wat u over zichzelf afroept als u met HL7 standaarden wilt gaan werken: RIM, HDF, SAIF, XML ITS, en nog veel meer. In principe hoeft u hier echter helemaal niets van te weten, als u de XML specificaties maar kunt hanteren en kunt afbeelden op de databases, functies en services van uw informatiesysteem. Deze specificaties zijn bijvoorbeeld beschikbaar als onderdeel van de Implementatiehandleiding HL7 v3 e-Diabetes [4] die door Nictiz, het Nederlands ICT instituut in de zorg, wordt uitgegeven. Zowel op het niveau van de informatie-inhoud (welke speler in de zorgketen moet welke informatie krijgen of versturen), processen (wie stuurt wanneer welke informatie) als technische implementatie (XML schema's) is het al helemaal uitgewerkt. HL7 Nederland en HL7 International zorgen er voor dat er consistentie is in de specificatie en toepassing van de standaard op verschillende terreinen en tussen de verschillende verschijningsvormen van de standaard en dat nieuwe onderdelen van de standaard worden ontwikkeld op terreinen waar deze nodig zijn. Vrijwilligers uit vele landen helpen, uit welbegrepen eigenbelang, bij al deze standaardisatiewerkzaamheden en de open organisatie zorgt ervoor dat u ook invloed kan uitoefenen op de ontwikkeling van de standaard. Maar dat hoeft niet. De standaarden voor inhoud, proces en techniek zijn er, implementatiehandleidingen en XML-schema's kunt u downloaden en er zijn opleidingen en adviseurs die u helpen de standaarden toe te passen. En dat is het mooie van de HL7 v3 familie van standaarden: je hoeft de specificaties niet zelf te ontwikkelen, maar alleen te gebruiken!

Referenties

[1] Si et al., 'Comparison of diabetes management in five countries for general and indigenous populations: an internet-based review', BMC Health Services Research 2010 10:169

[2] http://wiki.hl7.org/index.php?title=V2.xml

[3] http://www.continuaalliance.org/products

[4] http://www.nictiz.nl/module/360/61/10047RP_Implementatiehandleiding_HL7v3_e-Diabetes-pdf

Robert Stegwee is als principal consultant binnen Capgemini Consulting verantwoordelijk voor de strategische advisering van zorgorganisaties, netwerken en overheden rondom het gebruik van ICT in de zorg. Daarnaast is hij verbonden als hoogleraar E-Health Architectuur en Standaarden aan de vakgroep Health Technology and Services Research van de Universiteit Twente. Tevens is hij voorzitter van HL7 Nederland, een officiële Affiliate Member van HL7 International.