Het klinkt goed: internationale standaarden volgen. Niet zelf het wiel uitvinden maar gebruikmaken van wat er al is en de samengebalde kennis van experts uit de hele wereld benutten. Maar zijn standaarden wel altijd de oplossing? Standaarden kunnen ook problemen opleveren, zeker als er niet goed over nagedacht wordt. Een kritische blik en een aantal criteria bij de keuze om wel of niet een standaard in te zetten.
Gebruik van een standaard kan (let wel: kan) een aantal voordelen opleveren. Als iedereen een bepaalde standaard volgt, is er interoperabiliteit. Met mijn laptop kan ik in Duitsland inpluggen in het elektriciteitsnetwerk, maar zonder hulpmiddelen kan ik dat niet in Engeland. Een Nederlandse trein kan door het grootste deel van Europa rijden, maar niet op de bredere sporen van Rusland en Spanje. (Daar is men bewust van de toenmalige standaard afgeweken: de Russen vreesden dat een nieuwe Napoleon met de trein weleens meer succes zou kunnen hebben).
"Een standaard is als een confectiekleding: niet duur, maar ook op de gemiddelde persoon afgesteld"
Interoperabiliteit is niet het enige voordeel. Een standaard kan kosten besparen omdat er goedkope hulpmiddelen beschikbaar zijn voor die standaard. En in een standaard zit veel (denk)werk: bij een maatwerkoplossing zal een deel van dat werk ook gedaan moeten worden. Aan een maatwerkpak hangt een prijskaartje. Een standaard is als een confectiekleding: niet duur, maar ook op de gemiddelde persoon afgesteld.
Zoeken naar de heilige graal
Eén probleem is er niet in de zorg: een tekort aan standaarden. DBC, G-standaard, HL7v2, HL7v3, FHIR, Snomed-CT, ICD 9 en 10, LOINC, IHE, plus een wagonlading aan NEN-normen en ISO-standaarden. En dit is nog maar het topje van de ijsberg. Maar is het verstandig achter iedere nieuwe standaard aan te lopen? Standaarden lijken soms op de heilige graal: dat wat je zoekt is altijd achter de volgende bocht.
In de jaren tachtig en negentig waren er EDIFACT berichten in de eerste lijn en HL7v2 berichten in de tweede lijn. Vanwege tekortkomingen (te weinig semantiek, te rigide) is begin deze eeuw HL7v3 uitgevonden en geïmplementeerd. Ook daar zijn problemen mee. HL7v3 is te complex en sluit niet goed aan op de huidige mobiele platforms. Nu komt FHIR eraan: “fast and easy to implement”, “interoperability out-of-the-box” en “concise and easily understood”. Dat willen we allemaal! Na twee keer een valse start dan nu een standaard die al onze problemen oplost! Zo gaat het natuurlijk niet. Wanneer FHIR (op zich een goede standaard) is uitgerold, zijn er nieuwe ontwikkelingen die we nu niet voorzien. De wereld staat niet stil.
Mismatch
Wanneer zijn standaarden geen goed idee? Standaarden kunnen innovatie in de weg staan. Standaarden die af zijn en zich in de praktijk bewezen hebben, zijn niet gebaseerd op de nieuwste wetenschappelijke of informatiekundige inzichten. Standaarden zijn de wijsheid van gisteren in bevroren vorm. Voor innovatieve projecten is het vaak beter zelf iets te maken of bestaande standaarden aan te passen waar nodig. Soms kan dat niet (een stekker en een stopcontact moeten passen, en half passen werkt helemaal niet), maar soms is het geen groot probleem wat toe te voegen of aan te passen.
"Standaarden zijn de wijsheid van gisteren in bevroren vorm"
Soms past een standaard gewoon niet goed op de behoefte. Dan volstaat een eenvoudig uitwisselformaat, maar wordt een standaard ingezet die het geheel onnodig complex maakt. Let dus op of een standaard goed past op wat je nodig hebt. Gebruik nooit een standaard “omdat standaarden nu eenmaal goed zijn”.
De facto en de jure standaarden
Veel standaarden zijn alleen een standaard in naam. ISO-adepten beschouwen iets alleen als een standaard als er een stempel van een (inter)nationale standaardenorganisatie als ISO of NEN op staat. De werkelijkheid is dat een groot deel van die standaarden nauwelijks gebruikt wordt: wel een stempel, geen praktijk. De belofte achter standaarden is dat het kopen van commerciële of open source software goedkoper is dan zelf iets maken: maar vaak is die beloofde software er niet of nauwelijks! Dan heeft de standaard ook veel minder voordelen.
Aan de andere kant zijn er weer niet-standaard oplossingen die wel algemeen gebruikt worden. HTML, de basis van het Web, was heel lang suspect als standaard: eerst helemaal geen standaard, toen een standaard met als status “expired”, vervolgens ondergebracht bij een eigen organisatie (W3C) in plaats van het gerenommeerde IETF of ISO, en daarna opnieuw bedacht in een rebellenclubje (WHATWG) buiten het W3C om. En toch zijn weinig standaarden zo succesvol als HTML. Officiële stempels zeggen dus niet alles.
Standaarden zijn niet alleenzaligmakend
Wees dus bij de inzet van standaarden altijd kritisch. Een goede standaard heeft a) een heldere en ondubbelzinnige specificatie, b) een wijzigings- en goedkeuringsproces, bij voorkeur bij een organisatie die bewezen heeft dat te kunnen en c) wordt in de praktijk gebruikt. Let bij een standaard op of deze meer is dan alleen een standaard in naam. Is er voldoende software die de standaard ingebouwd heeft? Heeft de standaard zich in de praktijk bewezen? En vooral: past de standaard echt bij je behoefte?
"De standaarden van morgen zijn gebaseerd op de vernieuwingen van vandaag"
Standaarden zijn niet alleenzaligmakend. Als er een standaard bestaat die past op je use case, gebruik die dan. Zo niet, bedenk zelf wat, eventueel met gebruik van delen van een standaard die wel passen. En laat je nooit beperken door een standaard. De standaarden van morgen zijn gebaseerd op de vernieuwingen van vandaag. Gebruik dus wat past, en pas aan wat knelt.
Over de gastblogger:
Marc de Graauw is zelfstandig consultant en specialiseert zich in gegevensuitwisseling in de zorg. Betrokken bij landelijke uitwisselingsprojecten op het gebied van medicatie, oncologie, screeningsprogramma’s en patiëntendossiers. Opgeleid als filosoof, met hart voor de zorg.
Meer over Standaarden in de zorg
Plaats een Reactie
Meepraten?Draag gerust bij!