eenheid van taal

Tooling voor SNOMED referentiesets en waardelijsten

^{Linda Mook en Marc de Graauw}

In ons artikel “Wat is SNOMED precies?” hebben we SNOMED browsers besproken. Er zijn meer tools beschikbaar voor taken rondom implementatie van SNOMED. Alle tools en services die zijn ontwikkeld door SNOMED International zijn open source en kunnen gebruikt worden om SNOMED in te bouwen in eigen systemen. In een vorig artikel gaven we voorbeelden hoe SNOMED is gebruikt binnen de Geboortezorg.

Maar wat is nou het verschil tussen een SNOMED referentieset en een waardelijst met SNOMED concepten? En welke tooling gebruik je waarvoor?

Een SNOMED referentieset is een gespecialiseerde subset van SNOMED CT-concepten, ontworpen voor gebruik in de zorgsector, die gebruik maakt van de complexiteit en hiërarchieën van SNOMED CT om consistente en gestandaardiseerde medische terminologie te ondersteunen.

Een waardelijst is een opsomming van mogelijke waarden voor een gegevenselement, vaak gebruikt voor eenvoudige invoer en validatie in gebruikersinterfaces. De concepten in een waardenlijst kunnen SNOMED concepten zijn maar er kunnen in een waardenlijst ook concepten uit andere codesystemen voorkomen.

De keuze tussen het gebruik van een SNOMED referentieset en een waardenlijst in een implementatie hangt af van de complexiteit en specificiteit van de medische gegevens die moeten worden beheerd en uitgewisseld. Een ander verschil is dat de waardelijsten geen onderdeel zijn van SNOMED. Beheerders van informatiestandaarden zoals de geboortezorg maken en beheren de waardelijsten en zorgen voor versiebeheer en publicatie. SNOMED referentiesets worden ook inhoudelijk onderhouden door experts maar de publicatie ervan wordt door SNOMED International geregeld, en het versiebeheer volgt de regels zoals vastgesteld door SNOMED international.

Met browsers kunnen SNOMED-concepten worden opgezocht. Je kunt door de hiërarchie navigeren en de eigenschappen van elk onderdeel bekijken. Sommige browsers ondersteunen ook ECL wat staat voor Expression Constraint Language. Dit is een query language waarmee selecties van SNOMED concepten gemaakt kunnen worden. Zo’n selectie kan dan gebruikt worden voor het maken van een nieuwe referentieset of gewoon voor een eenvoudige waardelijst .

Een voorbeeld

Je wilt een lijstje hebben van alle verpleegkundige verrichtingen over het geven van voorlichting. Dit lijstje wil je in een EPD formulier hangen. Deze concepten zitten allemaal in de referentieset met Verpleegkundige Interventies. Met behulp van ECL en de onderstaande 3 SNOMED concepten kan je dit lijstje maken:

99051000146107 |Referentieset met Verpleegkundige Interventies|
260686004 |methode (attribuut)|
425689005 |voorlichten (kwalificatiewaarde)|

“Methode” is een relatie-attribuut in SNOMED. Je wilt dus alleen de concepten selecteren waarbij die “Methode” gelijk is aan “voorlichten” . Je kunt nu met ECL een filter maken in de browser met behulp van bovenstaande 3 concepten:

^ 99051000146107:260686004=425689005

Dit levert de onderstaande lijst op van 30 concepten:

Voorbeeld ECL met de SNOMED International browser (eerste 10 van 30 concepten)

Nationale Terminology Server NTS

ECL is ook beschikbaar op de nationale terminologieserver, geïmplementeerd door Nictiz met het product “Ontoserver”. Dit is een FHIR-terminologieserver ontwikkeld door het Australische e-Health Research Center. Naast SNOMED biedt de NTS ook toegang tot andere codesystemen en waardelijsten, zoals de Nederlandse Labcodeset, UCUM, LOINC, ICD-10, ICF, ICPC-1, diverse NHG-tabellen inclusief de Nederlandse ICPC, Human Phenotype Ontology (HPO), en de HUGO Gene Nomenclature Committee (HGNC).

Ook zijn alle waardelijsten die in ART-DECOR staan via de NTS beschikbaar. De SNOMED-browser op de NTS heet “Shrimp” en de tool waarmee FHIR-codesystemen, waardelijsten en concept-maps kunnen worden gemaakt heet “Snapper”.

Referentiesets en waardelijsten op de NTS zijn via webservices (API’s) te ontsluiten. Dit is geen tool voor zorgverleners, maar IT-leveranciers kunnen via deze server referentiesets , waardelijsten en resultaten van ECL queries ophalen en gebruiken in hun applicaties.

Ook kunnen leveranciers zelf een FHIR-server configureren en de inhoud van de NTS naar deze eigen FHIR-server synchroniseren. Op deze manier kunnen ontwikkelaars bij IT-leveranciers de referentiesets en waardelijsten verder bewerken en aanvullen en als dropdownlijsten voor eindgebruikers van hun applicaties configureren.

ART-DECOR

ART-DECOR is een open source ontwikkelingstool. Nictiz gebruikt deze tool bij het opstellen, beheren en beschikbaar stellen van informatiestandaarden. Met ART-DECOR kunnen zorgverleners, terminologen, architecten, ontwerpers en programmeurs de nodige gegevens invoeren en iteratief verbeteren. Zo worden de functionele specificaties van zorgverleners vastgelegd in datasets en vertaald naar technische specificaties.

In ART-DECOR bij Nictiz zitten veel waardevolle gegevens die een rol kunnen spelen bij goed gebruik van SNOMED in de zorgsectoren. Ook voor het opstellen van waardelijsten kan het een geschikt hulpmiddel zijn. ART-DECOR bevat momenteel al heel veel waardelijsten van landelijke informatiestandaarden.

Conclusie

Er zijn veel tools, vaak open source, beschikbaar voor het inzetten van SNOMED in de zorgsectoren. Keuze van de juiste tools en het opzetten van een goede workflow zijn dan ook van groot belang. Zet op een rij wat er nodig is en check ook bij Nictiz en andere domeinen welke afwegingen zij reeds hebben gemaakt en waar ze tegen aan lopen bij het gebruik ervan.

Over Duometis

Duometis is gespecialiseerd in het implementeren van informatiestandaarden, terminologie en ontologie, FHIR implementation guides en andere uitwisselstandaarden in de zorg. Wij helpen u graag verder onder andere bij het implementeren van SNOMED in uw sector.

SNOMED in het informatiesysteem

^{Marc de Graauw en Linda Mook}

In een aantal vorige artikelen hebben we geschreven over het SNOMED advies van VWS en Nictiz en de gevolgen voor de zorg. Hier gaan we verder.

SNOMED en Eenheid van Taal is niet iets wat alleen “onder water” speelt. Met de verdergaande digitalisering ziet de zorgverlener dit terug in de informatiesystemen en gebruikersinterfaces. Digitalisering is ook de reden dat Eenheid van Taal en SNOMED nodig zijn. In het papieren tijdperk was geschreven tekst helder genoeg, maar moest wel alles met de hand worden overgenomen. Voor verwerking in een informatiesysteem is een eenduidige codering van begrippen nodig, maar het voordeel is dat informatie van andere zorgverleners hergebruikt kan worden.

In het SNOMED advies van Nictiz staat: “Een oplossingsrichting is te vinden in referentiesets. Dit is een door de sector(en) zelf samengestelde, herkenbare set van concepten uit SNOMED die wordt toegepast in de dagelijkse praktijk.”

Het maken van referentiesets is echter maar één stap die nodig is voor implementatie van SNOMED. Voor goed functionerende informatiesystemen op basis van SNOMED is meer nodig. Hier een aantal voorbeelden. (Hierbij is gekozen voor voorbeelden uit de Geboortezorg: dat is niet een van de zes sectoren uit het advies, maar juist omdat in de Geboortezorg al veel SNOMED gebruikt wordt, zijn daar goede voorbeelden te vinden.)

Context, context, context

In de kraamzorg worden in de eerste week na de bevalling verrichtingen gedaan: controles op het kind, zoals de kleur van de huid, temperatuur, gewicht, plassen en poepen et cetera.

^{Photo by freestocks on Unsplash}

Wanneer de geboortezorg een SNOMED referentieset heeft met alle verrichtingen in de geboortezorg, heeft een kraamverzorgende daar op zich niet veel aan: na ieder kraambezoek gedane verrichtingen invoeren en daarbij moeten kiezen uit alle verrichtingen die in de geboortezorg mogelijk zijn, is erg omslachtig. Beter is het een lijst te hebben met alleen die verrichtingen die in de kraamweek gedaan worden, en daaruit te kiezen (en eventueel de uitkomst wanneer het een controles betreft). Referentiesets zijn dus maar een deel van de oplossing. In een specifieke context speelt maar een subset van alle verrichtingen of aandoeningen uit de sector een rol. Voor een bruikbare inzet van SNOMED zijn niet alleen referentiesets nodig, maar ook waardelijsten die aangeven welke concepten relevant zijn in een bepaalde context.

Andere en onbekende waarden

Nog een voorbeeld uit de Geboortezorg, dit keer over problemen bij de moeder die rondom de bevalling op kunnen treden. Hieronder een (sterk ingekort) waardelijstje:

Code	DisplayName	CodeSystemName
312974005	preterm en prematuur gebroken vliezen (aandoening)	SNOMED CT
44223004	prematuur gebroken vliezen (aandoening)	SNOMED CT
386661006	koorts (bevinding)	SNOMED CT
….	….	….
OTH	overig	NullFlavor
UNK	onbekend	NullFlavor

Wat opvalt is dat er twee waarden staan die niet uit SNOMED komen, maar uit een “NullFlavor” codesysteem, namelijk “onbekend” en “overig”. Deze waarden zullen niet in een referentieset voor aandoeningen of verrichtingen in een sector staan, maar zijn wel essentieel voor de vastlegging. In een bepaalde context kan het namelijk prima zo zijn dat er wel een probleem is, maar dat er ofwel geen goed SNOMED concept in de referentieset staat, of dat er onvoldoende kennis is om een specifieke keuze te maken. In zulke gevallen zal “overig” (of: “anders”) met vaak een aanvullende tekst nodig zijn. Hetzelfde geldt voor “onbekend”: soms kan iets gewoon weg- of leeggelaten worden, in andere gevallen zal er expliciet aangegeven moeten worden dat het onbekend is.

Meer dan referentiesets alleen

Nog iets dat opvalt in bovenstaande korte lijst: een van de waarden is “koorts (bevinding)”. Daarbij is de context waarin dit gegeven wordt vastgelegd, “bij of rond de bevalling”, essentieel. Een SNOMED concept staat niet op zichzelf, en zonder de context waarin het wordt vastgelegd heeft het vaak onvoldoende betekenis.

Kortom: het bestaan van referentiesets in een sector alleen betekent niet dat er goede en gebruiksvriendelijke informatiesystemen gebouwd kunnen worden. Daar is meer voor nodig. Goede waardenlijsten (gebaseerd op die referentiesets) zijn een eerste stap, maar een stuk datamodellering (wat is de context?) daaromheen is vaak ook nodig.

Zoeken en vinden

Maar terug naar de referentiesets. Wanneer een sector die opstelt, zijn er ook keuzes te maken. In een vorig voorbeeld keken we naar artrose van de knie in SNOMED:

Hier zijn een aantal namen voor knieartrose te zien. De voorkeursterm in de Nederlandse editie van SNOMED is “gonartrose”, en dat is wat de orthopedische chirurgen gebruiken. In de richtlijnen voor de fysiotherapeuten wordt echter gesproken van “knieartrose”. De fysiotherapeut zal “gonartrose” echt wel begrijpen, maar iedere sector zal toch het liefst vasthouden aan het eigen taalgebruik, en dat mag ook: synoniemen in SNOMED zijn evenzeer geldig als de voorkeursterm. Het betekent wel dat een referentieset ook zal moeten specificeren welk synoniem de voorkeur heeft in een sector en als deze mist die omschrijving laten toevoegen in SNOMED. Een fysiotherapeut zal het liefst vastleggen met de termen waarmee deze al jaren vertrouwd is.

Een verwant onderwerp is zoeken in SNOMED concepten. Wanneer in de hele referentieset gezocht moet worden, bijvoorbeeld voor het vastleggen van een diagnose, dan werkt uiteraard een dropdown lijst met 10.000 concepten niet. Een zoekveld waarbij op een paar fragmenten van termen gezocht kan worden helpt dan. In de SNOMED browser van Nictiz levert zoeken op “artro knie” en “gonartro” hetzelfde concept op als eerste keuze, het bovenstaande. Zoeken op “knieartrose” levert (helaas) het bovenstaande concept niet op, omdat “knieartrose” geen officieel synoniem is. Zoeken in SNOMED is helaas niet altijd eenvoudig. Daarom is een goede zoekinterface ook zo belangrijk.

Korte en lange namen

Wanneer we verder kijken, zien we “gonartose (aandoening)” staan. Dat is de “fully specified name” (FSN), met tussen haakjes de “tak” van SNOMED waar het begrip in voorkomt. Veelal is die veel te lang om gebruikt te worden in een gebruikersinterface. Wanneer een patiënt hulp nodig heeft bij het aankleden, is dit een prima lijstje uit de zorginformatiebouwsteen:

Wanneer we hier de FSN zouden gebruiken komt er dit te staan:

Overbodig herhalend en complex: dat wil je niet. Maar wanneer je een dossier van een andere sector of instelling ontvangt, en dat als geheel weergeeft, kan de FSN juist weer heel nuttig zijn. Wat betekent “hulp bij aankleden” dan? Heeft iemand hulp bij aankleden nodig? Of is er hulp bij aankleden verleend? De FSN maakt dat onderscheid duidelijk:

Ook hier geldt weer dat goed gebruik van SNOMED betekent dat de context waarin een SNOMED concept gebruikt wordt, bepalend is voor de keuze van de juiste term.

Meer dan lijsten

Een goede implementatie van SNOMED in een sector behelst veel meer dan het maken van referentiesets voor diagnoses en/of aandoeningen en verrichtingen en/of behandelingen. Willen we gebruiksvriendelijke informatiesystemen, dan moeten er ook keuzes gemaakt worden hoe SNOMED in een bepaalde context toegepast gaat worden.

Over Duometis

De SNOMED transformatie

_{Marc de Graauw en Linda Mook}

In een vorig artikel “FHIR besluit en SNOMED advies: wat nu?” hebben we de gevolgen toegelicht van het SNOMED advies van Nictiz, en in het vervolg “Wat is SNOMED precies?” een korte uitleg van SNOMED gegeven. Maar hoe kan de overgang naar SNOMED eruit zien? De zes zorgsectoren die het in eerste instantie betreft zijn:

Geestelijke Gezondheidszorg (GGZ)
Huisartsen (HA)
Jeugdgezondheidszorg (JGZ)
Medisch Specialistische Zorg (MSZ)
Paramedische Zorg (fysiotherapie, oefentherapie, logopedie, ergotherapie, diëtetiek, optometrie en huidtherapie)
Verpleeg- en Verzorgingshuizen en Thuiszorg (VVT)

Het SNOMED advies geeft prioriteit aan diagnoses (of aandoeningen) en verrichtingen (of behandelingen) en adviseert referentiesets te maken per sector.

Een referentieset is – eenvoudig gezegd – een subset van codes uit SNOMED. Deze sets kunnen vervolgens ingebouwd worden door IT-leveranciers in zorg applicaties. Denk hierbij bijvoorbeeld aan een lijst van alle aandoeningen waarbij behandeling van een fysiotherapeut nodig is of een lijst van alle mogelijke handelingen die een thuiszorgmedewerker zou kunnen uitvoeren.

Wat komt hier allemaal bij kijken?

Referentiesets voor diagnoses en verrichtingen opstellen per domein is echter maar een eerste stap. Zo zullen niet alle bestaande lijsten binnen een domein tot een referentieset leiden waarbij het implementeren ervan vervolgens “eenheid van taal” teweegbrengt.

Er zijn veel meer (grotere en kleinere) lijsten in gebruik. Denk hierbij ook aan multidisciplinaire zorg voor bepaalde aandoeningen, medische en verpleegkundige richtlijnen, die deels en vaak ook verschillend zijn geïmplementeerd in een groot aantal informatiesystemen, in tal van vormen voor verslaglegging, in aanvraagformulieren, et cetera.

Die lijsten moeten afgeleid of gekoppeld worden aan die nog te maken referentiesets, maar zullen zelf wel moeten blijven bestaan als onderdeel van de gebruikersinterface. Idealiter ziet de eindgebruiker niets van SNOMED. Jarenlang is de zorgverleners verteld dat alles onder de motorkap plaats vindt en met een “mapping naar SNOMED” op te lossen is. De situatie is nu anders: met mappen komen we er niet staat in het advies van Nictiz. Overgaan naar SNOMED behelst dus meer dan alleen het opstellen van referentiesets. Zorgverleners krijgen er allemaal mee te maken. Het is dus nodig om een impactanalyse te doen.

Sommige lijstjes in een informatiesysteem zullen dit keer wel aangepast worden. Bijvoorbeeld wanneer de huisarts, orthopeed, fysiotherapeut, revalidatiearts en de thuiszorg allemaal hun eigen lijsten met eigen codes voor aandoeningen/diagnoses en handelingen/verrichtingen blijven hanteren wordt het delen van informatie wel erg ingewikkeld. Deze verschillende concepten en codes moeten dan telkens vertaald worden.

Op veel onderdelen is harmonisatie en onderlinge afstemming tussen domeinen nodig, en soms ook standaardisatie.

Daar waar bestaande concepten in een lijst niet “vertaald” kunnen worden naar SNOMED, zal ofwel het lijstje aangepast moeten worden ofwel een nieuwe SNOMED code aangevraagd moeten worden.

Stappenplan

Wat kunnen nu de volgende stappen zijn voor een sector? Om hiermee te beginnen stellen wij ons een volgende start voor:

Maak een overzicht van bestaande lijsten met diagnoses/aandoeningen en verrichtingen/handelingen. Natuurlijk kan het zo zijn dat deze lijsten nog niet overal in een gestandaardiseerde vorm bestaan en beheerd worden door de diverse koepelorganisaties. Dan is het wellicht zinvol om langs de lijn van bijvoorbeeld medische richtlijnen, behandelrichtlijnen en zorgstandaarden verder te inventariseren welke concepten voorkomen. Taalextractie met AI-tools kan daarbij hulp bieden.
Ga voor een kleine, representatieve, doorsnede van de items op al die lijsten na of er goede SNOMED codes voor dat concept beschikbaar zijn. Zo ontstaat er een beter beeld van hoeveel werk er uiteindelijk komt te liggen. Voor concepten waarvoor nog geen SNOMED code te vinden is, kan een verkenning volgen om de doorlooptijden en uiteindelijk plan van aanpak op te kunnen stellen. Bestaat het concept echt nog niet? Dan kan deze bij het terminologie centrum van Nictiz aangevraagd worden. Soms mist alleen een synoniem of een goede vertaling en kan deze in een nieuwe SNOMED release worden toegevoegd. Zijn er wel vergelijkbare concepten in SNOMED maar past het niet helemaal of is dat zelfs niet helemaal duidelijk? Dat zijn de moeilijke gevallen waarbij er verduidelijking nodig is. Vaak zal ook overleg met andere sectoren nodig zijn. Als het om uitwisseling van gegevens gaat wil je geen enkel misverstand. Door een dergelijke voorverkenning kan de hoeveelheid werk beter ingeschat worden. Uiteraard zal veel werk gaan zitten in de complexe gevallen. Daarbij zullen de zorgverleners een belangrijke rol spelen.
Doe een sector overstijgende verkenning voor gevonden concepten om erachter te komen hoe deze in andere zorgsectoren waarmee uitgewisseld wordt worden gebruikt. Worden ze op dezelfde wijze gebruikt? Zijn de concepten daar al gecodeerd of niet? Is de betekenis ook hetzelfde?

Een dergelijke verkenning is een eerste stap naar een gedegen plan. Hier moet tijd van zorgverleners, terminologen en IT specialisten vrijgemaakt worden. Uiteraard komen er veel organisatorische en programmatische aspecten bij kijken: hoe rollen we dit uit? Hoe betrekken we de stakeholders? Wat zijn de planning, risico’s en alternatieven? In deze blog concentreren we ons echter op de inhoudelijke aspecten.

Een verkenning aan de hand van een voorbeeld

Knieartrose bij de huisarts

Bij thuisarts.nl is een behandelkaart gemaakt waarin door huisartsen, fysiotherapeuten, orthopeden en patiëntvertegenwoordigers een overzicht is gemaakt van de mogelijke behandelingen wanneer de diagnose eenmaal is gesteld.

Wanneer we bij de NHG richtlijnen kijken komen we uit bij niet-traumatische-knieklachten. Bij de evaluatie vinden we knieartrose in het lijstje met mogelijke diagnosen

^{In dit lijstje hebben we in geel SNOMED concepten voor een referentieset toegevoegd. (Bij een echte verkenning zal vaak validatie door zorgverleners nodig zijn.)}

Bij dit lijstje is het niet echt moeilijk om snel de juiste diagnoses te vinden in een SNOMED browser. Dat komt omdat SNOMED zeer rijk is als het gaat om diagnoses. Als het gaat om symptomen en bevindingen wordt het wel wat ingewikkelder.

Fysiotherapie

Na diagnose knieartrose wordt de patiënt misschien doorverwezen naar een fysiotherapeut. Bij het Koninklijk Nederlands Genootschap voor Fysiotherapie (KNGF), de beroepsvereniging van en voor fysiotherapeuten in Nederland vinden we de richtlijn artrose heup-knie. Bij “B.5 Indicatiestelling, contra-indicaties en rode vlaggen” zien we een lijstje van 3 contra-indicaties voor behandeling: cardiale problematiek, COPD en hypertensie. Bij cardiale problematiek staat een lijstje van bevindingen, symptomen, diagnoses en gebeurtenissen die ingewikkelder zijn.

^{Wederom in geel voorbeeld van door ons gevonden SNOMED concepten voor een referentieset}

Een “cardiac finding (finding)” – zie bovenaan het plaatje – is als begrip wel erg breed. Een normale hartslag is namelijk ook een cardiac finding. Een dergelijke lijst is een beginpunt om te kijken welke concepten uitgewisseld worden met andere zorgsectoren en waar mogelijk concepten in SNOMED ontbreken.

Voorbeeld verrichting knieprothese

Kijken we bij de federatie van medisch specialisten (FMS) dan vinden we meerdere richtlijnen van de Nederlandse Orthopaedische Vereniging (NOV). In de richtlijn “Geïsoleerde mediale en laterale artrose van de knie” zit een sectie “Indicatiestelling bij geïsoleerde mediale en laterale artrose van de knie”. Hier gaat het om een operatie van de aangedane knie en keuzes daarin zoals fixatie van een knieprothese (een kunstknie).

Een dergelijke operatie vindt natuurlijk in een ziekenhuis plaats. Daar wordt naast de Diagnosethesaurus ook de Verrichtingenthesaurus van Dutch Hospital Data (DHD) gebruikt. Zoeken we in de zoeken we in Diagnosethesaurus browser (T-Rex) naar orthopedische operaties dan komen we bij deze lijst uit.

^{In groen de SNOMED concepten in de verrichtingen thesaurus}

De Diagnose- en Verrichtingenthesaurus zijn voorbeelden hoe een zorgdomein SNOMED kan implementeren. De thesauri bestaan uit lijsten met uniforme termen die worden ingeladen in het EPD van het ziekenhuis. Hierdoor kunnen artsen en andere zorgverleners verrichtingen vastleggen in de taal die zij in de praktijk gebruiken. Elke twee maanden verschijnen nieuwe versies, zodat de lijsten altijd actueel zijn. Gebruikers kunnen verzoeken voor wijzigingen bij DHD indienen. De termen leiden automatisch af naar o.a. SNOMED. Nictiz zorgt voor een Nederlandse vertaling en indien nodig het toevoegen van een code aan de Nederlandse extensie van SNOMED.

Over Duometis

Wat is SNOMED precies?

_{Marc de Graauw en Linda Mook}

In het advies van Nictiz aan het zorgveldwordt voorgesteld SNOMED stap voor stap in gebruik te nemen met als centrale vraag ‘Hoe gaan we samenwerken aan eenheid van taal met SNOMED over de sectoren heen’. Zie ook ons vorige artikel (“FHIR besluit en SNOMED advies“) hierover. Nictiz adviseert elke sector de komende maanden zelf een transformatieplan op te stellen. Vragen die men daarin beantwoordt zijn bijvoorbeeld: Wat is er nodig in de sector? Hoe groot is de veranderopgave? Nictiz ondersteunt de sectoren hierbij met kennis over SNOMED en faciliteert de samenwerking.

_{Photo by Kaffeebart on Unsplash}

Maar wat is SNOMED nou precies?

SNOMED is een medische standaard voor het documenteren en coderen van medische gegevens zodat ze door computers verwerkt kunnen worden. Het omvat gebieden als ziektes, symptomen, verrichtingen, behandelingen, apparatuur, medicatie. Het doel van SNOMED is het op een consistente manier indexeren, opslaan, ontvangen en verzamelen van medische data, ongeacht specialisme of zorglocatie. Tevens helpt het de inhoud van medische dossiers te structureren waardoor de variatie in de manieren om gegevens vast te leggen, te coderen en te gebruiken voor zorg en onderzoek wordt beperkt. SNOMED is gekoppeld aan andere internationale terminologieën, waaronder ICD-10, ICD-O en LOINC, via mappings die ook door SNOMED worden onderhouden.

De structuur bestaat in de basis uit een aantal componenten.

Concepten hebben numerieke codes met een voorkeursterm en synoniemen. Deze synoniemen zijn zeer goed bruikbaar voor zoekmachines en indien goed geïmplementeerd geschikt om snel, gedetailleerd medische gegevens vast te leggen of te tonen in diverse applicaties zoals patiëntendossiers. Oudere concepten worden nooit verwijderd en zo blijft het mogelijk om historische data te blijven gebruiken en indien gewenst te vertalen naar een nieuwe code, omschrijving of taal.

_{Voorbeeld van een SNOMED concept voor brandwond met gebruikte namen en synoniemen}.

2. Relaties zijn verbindingen tussen concepten die weer een nieuw concept vormen. De ‘is-a’ relatie wordt gebruikt om specialisaties of juist verruiming van bepaalde concepten uit te drukken en ‘attribute’ relaties voegen additionele eigenschappen toe.

_{SNOMED concept met diverse releaties die de context van het concept duidelijk maken.}

3. Referentiesets worden binnen SNOMED gebruikt om subsets van concepten, beschrijvingen of relaties die relevant zijn voor een bepaalde implementaties te maken. Een SNOMED referentieset moet voldoen aan opgestelde karakteristieken (waarover later in dit artikel meer). Het opstellen van referentiesets is belangrijk bij de implementatie van SNOMED in Nederland.

SNOMED browsers

Toegang tot SNOMED om concepten te zoeken en te bekijken gaat via SNOMED browsers, waaronder de Nederlandse SNOMED browser van Nictiz. Via deze terminology browser zijn ook andere terminologie stelsels in te zien.

Ook de browser gemaakt door de SNOMED organisatie zelf is zeer bruikbaar omdat hiermee naast de internationale ook alle beschikbare nationale extensies bekeken kunnen worden.

De browsers zijn bedoeld om termen op te zoeken of subsets te maken en niet voor gebruik en vastlegging van gegevens. Zorgverleners maken dus voor de registratie van patiëntgegevens gebruik van door IT leveranciers gemaakte producten in applicaties. Over beschikbare en eventueel nodige tooling voor de implementatie van SNOMED in Nederland zullen we binnenkort nog een ander artikel publiceren.

De verrichtingen- en diagnosethesaurus die bij de ziekenhuizen zijn geïmplementeerd bevatten voor vrijwel elke term een SNOMED code maar zijn geen referentiesets. Deze thesauri worden namens de ziekenhuizen in Nederland door Dutch Hospital Data (DHD) onderhouden en kent zijn eigen release schema. Voor meer informatie over producten van DHD voor de ziekenhuizen zie de documentatie over thesauri van DHD.

Releases en updates van SNOMED

Bij elke release van SNOMED komen er concepten en beschrijvingen bij, worden concepten geüpdatet en op non actief gezet (deprecated). Het is altijd mogelijk om oude concepten te blijven gebruiken maar het wordt aangeraden om voor het maken van nieuwe gegevens wel de meest recente publicatie te gebruiken.

SNOMED International brengt sinds 2022 elke maand een geüpdatete versie uit van de releasefiles. Nictiz gaat dit op (korte) termijn ook doen maar brengt vooralsnog om de 6 maanden een geüpdatete versie uit.

IT leveranciers met een SNOMED-licentie kunnen de Nederlandse SNOMED-editie downloaden via de Nationale Terminologie Server (NTS) of het MLDS-portaal en met deze bestanden hun eigen applicaties en software aanpassen. (Iedereen in Nederland kan via Nictiz kosteloos zo’n licentie krijgen.) Zij worden door Nictiz hierin ondersteund. Hoe vaak zij hun bestanden updaten naar een nieuwe versie verschilt per product en leverancier.

Wie beheert de SNOMED standaard?

De International Health Terminology Standards Development Organisation (IHTSDO) is de eigenaar van SNOMED en verzorgt ook het onderhoud ervan. Deze organisatie is in 2007 opgericht onder andere door Nederland als 1 van de 9 “charter members”. SNOMED International heeft momenteel 47 national Members over de wereld. Er is een SNOMED CT starter guide geschreven voor mensen die de ins en outs van SNOMED willen doorgronden.

Nederland heeft zijn eigen SNOMED extensie

In Nederland beheert Nictiz SNOMED. Naast het maken van vertalingen van concepten worden ook extra concepten en referentiesets toegevoegd voor gebruik binnen Nederland. Op verzoek voegt Nictiz dus concepten toe aan de Nederlandse extensie en draagt ook nieuwe concepten voor aan SNOMED internationaal voor opname in de internationale SNOMED release. Nictiz coördineert daarnaast de integratie van SNOMED met nationale standaarden, zoals de Diagnose- en Verrichtingenthesaurus van Dutch Hospital Data (DHD).

Belangrijk om te weten is dat niet alle SNOMED concepten van een nationale extensie voorkomen in de internationale versie maar alle concepten van de internationale versie wel in een nationale extensie. Daarnaast heeft Nederland niet alle concepten in de Nederlandse versie vertaald maar kan dat op verzoek van belanghebbenden wel doen.

Gebruiken van (Nederlandse) referentiesets
Een referentieset is dus een specifieke verzameling van SNOMED-concepten die voor een bepaald doel of domein zijn samengesteld. Deze referentiesets helpen zorgverleners en andere gebruikers om relevante medische begrippen eenduidig vast te leggen en worden door IT leveranciers ingebouwd.

Op dit moment worden Nederlandse referentiesets gemaakt en onderhouden door Nictiz. Het inhoudelijk beheer ligt idealiter bij vertegenwoordigers van de gebruikers van zo’n referentieset. Het is de bedoeling dat de sectoren de komende jaren starten met het definiëren van referentiesets voor hun beroepsgroep.

Een voorbeeld: de Optometristen Vereniging Nederland (OVN) heeft 3 lijsten opgesteld met optometrische diagnosen, verrichtingen en bezoekredenen die gebruikt worden voor de vastlegging van gegevens. Eenmaal vastgelegd kunnen deze gegevens gebruikt worden voor declaratie en bijvoorbeeld (anoniem) voor kwaliteitsregistraties.

Er zijn momenteel 3 soorten Nederlandse refsets gemaakt door Nictiz voor gebruik in Nederland.

De zogenoemde ‘simple reference sets’ die subsets zijn van SNOMED concepten die kunnen worden ingebouwd in applicaties voor het vastleggen van gegevens.

2. De ‘mapping reference sets‘ die een koppeling bieden tussen SNOMED en een andere code-of terminologie stelsel .

3. De derde soort zijn de taalreferentiesets waar o.a. de ‘Nederlandse taalreferentieset’ bij hoort maar ook vertalingen van medische termen naar een patiëntvriendelijk synoniem

Dan zijn er nog een aantal andere speciale referentiesets die gebruikt worden voor juistheid van publicaties en het versiebeheer van SNOMED zelf, een set voor het terugvinden van de reden voor het deactiveren van bepaalde concepten en een set om een alternatief concept te vinden. Te veel om hier op in te gaan maar ook nodig en zeer bruikbaar bij de implementatie van SNOMED.

Over Duometis

FHIR besluit en SNOMED advies: wat nu?

_{Marc de Graauw en Linda Mook}

Kort geleden heeft Nictiz het SNOMED advies (“SNOMED in gebruik bij Nederlandse zorgaanbieders“) gepubliceerd. Er staan verstrekkende conclusies in voor de zorgsector. Het is ook een advies dat nauw samenhangt met twee andere richtingen die VWS en Nictiz met voorzichtige tot stevige dwang inslaan: standaardisatie van gegevensuitwisseling in de zorg met:

zorginformatiebouwstenen (zibs),
FHIR,
SNOMED .

De gevolgen voor de zorg verschillen nogal. Eerst zullen we kijken wat de impact op de zorgsector is van deze wijzigingen, daarna zullen we in een aantal vervolgartikelen dieper inzoomen op de impact van het SNOMED advies en het FHIR besluit.

Zibs

De zorginformatiebouwstenen zorgen voor eenduidige registratie aan de bron. Wanneer in de zorg iedereen bepaalde basisgegevens op dezelfde manier vastlegt wordt het makkelijker om deze gegevens tussen zorgverleners onderling en met de patiënt uit te wisselen. De introductie van zibs heeft gevolgen voor de registratie door de zorgverlener zelf. De zibs vereisen bepaalde velden en beperken soms de toegestane waarden in die velden. Zo is er een zib “Gezinssituatie” met velden als “Burgerlijke staat”, “Gezinssamenstelling”, “Aantal kinderen” en meer. Zorgverleners die op basis van zibs registreren, moeten ook dergelijke velden (eenmalig) invullen en de informatie niet in één groot tekstveld intypen. Daarmee kunnen deze gegevens meervoudig gebruikt worden.

Daarnaast zijn er eisen aan de waarden die ingevoerd kunnen worden. Zo is er in de Geboortezorg een veld “Rookgedrag” met daarin een keuzelijst met waarden als “1-10 per dag”, “11-20 per dag” et cetera. De zib Tabakgebruik kent echter een veld “Hoeveelheid” waarin het aantal sigaretten vastgelegd wordt die per dag, week, maand of jaar worden gerookt: dus met een precies aantal en geen bereik. Daarnaast zijn er nog waardelijsten met specifieke waarden uit SNOMED: zie ook hieronder. Zibs hebben dus gevolgen voor de inrichting van het EPD, en voor de registratie door de gebruikers.

FHIR

FHIR is een manier waarop informatiesystemen met elkaar communiceren over het (beveiligd) Internet. Dat gaat nu nog te vaak op manieren die niet of met veel moeite (transformaties) met elkaar samenwerken. Binnen Nederland communiceren informatiesystemen in de zorg onder andere via Edifact, HL7v2, HL7v3 CDA, en FHIR. FHIR betekent dat echt gestandaardiseerd gaat worden op één standaard waardoor communicatie universeler wordt en de overige standaarden uit gefaseerd gaan worden. De introductie van FHIR is niet iets waar de zorgverlener heel veel van hoeft te merken (behalve dat gaandeweg meer informatie beschikbaar wordt).

De leverancier van het zorginformatiesysteem zal dit gaan inbouwen “onder de motorkap”. Voor de zorgsectoren heeft dit wel een flinke impact: er moeten migratieplannen worden opgesteld voor de gefaseerde overgang naar FHIR. Dat vereist nauw overleg met Nictiz, leveranciers en zorginstellingen – die deze migraties naar FHIR uiteindelijk uit moeten rollen over heel Nederland. Hoewel dit een belangrijke en forse stap voor de zorginstellingen en leveranciers is, kan de individuele zorgverlener dit “laten regelen” door de IT-professionals.

SNOMED

Heel anders ligt dat bij de introductie van SNOMED. SNOMED is de manier waarop informatie gecodeerd wordt. Hier wordt geregeld dat ook zorginformatiesystemen weten dat met myocardinfarct, hartinfarct, MI en hartaanval hetzelfde bedoeld wordt. Met SNOMED wordt een code (22298006) toegekend aan een concept ‘myocardinfarct’ en zijn de hierboven genoemde termen synoniemen voor deze ene code. SNOMED regelt dus Eenheid van Taal voor klinische concepten. Daarnaast doet LOINC dat als standaard voor de labwereld en IDMP voor geneesmiddelen.

Door Bleiglass at the English Wikipedia, CC BY-SA 3.0, Koppeling

Gebruik van SNOMED heeft de nodige gevolgen voor de zorgsector en – in tegenstelling tot FHIR – ook voor de individuele zorgverlener. Nu wordt nog vaak gebruik gemaakt van lokale codelijstjes of andere codesystemen. Met SNOMED moeten codes gebruikt worden uit SNOMED. SNOMED is niet voor eens en altijd vastgelegd in steen: wanneer er codes ontbreken die wel nodig zijn kunnen die aangevraagd en toegevoegd worden door Nictiz.

Ook voor SNOMED worden migratieplannen gevraagd aan zes sectoren:

Geestelijke Gezondheidszorg (GGZ)
Huisartsen (HA)
Jeugdgezondheidszorg (JGZ)
Medisch Specialistische Zorg (MSZ)
Paramedische Zorg (fysiotherapie, oefentherapie, logopedie, ergotherapie, diëtetiek, optometrie en huidtherapie) en
Verpleeg- en Verzorgingshuizen en Thuiszorg (VVT).

Die migratieplannen betreffen voor een deel organisatorische aspecten: hoe richten we dit in, hoe beheren we het, hoe financieren we dat?

Wij zullen hier meer de inhoudelijke aspecten gaan verkennen.

De eerste stap die gevraagd wordt is aangeven hoe van de huidige situatie binnen de sector naar de op SNOMED gebaseerde registratie kan worden overgegaan in 2025. Daarbij is de zorgsector “in the lead”. Waar SNOMED dus tot op heden iets was wat “Nictiz voor je regelde”, is het nu aan het veld om SNOMED te regelen. Nictiz treedt daarbij op als landelijk beheerder van SNOMED , zeg maar als scheidsrechter om een correcte toepassing te borgen en nieuwe concepten toe te voegen als deze landelijk nodig zijn. Maar invulling is aan het veld zelf.

Omdat SNOMED een (uitbreidbaar) aantal codes kent, die volgens een bepaalde systematiek is opgezet, betekent dat dat lokale codelijsten en codestelsels aangepast moeten worden met SNOMED codes. Daarbij kunnen pijnlijke keuzes gemaakt moeten worden die voor de zorgverlener niet alleen maar “onder water” zullen zijn maar ook merkbaar in de gebruikersinterface. In veel gevallen zal in SNOMED wel een code gevonden worden die een-op-een matcht met een bestaande eigen code, maar in heel veel gevallen ook niet. Dat betekent aanpassingen in codelijsten in zorginformatiesystemen en nieuwe SNOMED codes aanvragen bij Nictiz voor opname in de Nederlandse release van SNOMED.