Categorie: fhir

^{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.