zib-compliance algemeen NullFlavor of SNOMED

[Michael van der Zel]

Bij implementatie merken we dat die NullFlavor gewoon lastig is. Meer een technisch ding, voor de hard-coded dingen zeg maar. Dus als het systeem masked bij anonimiseren b.v. Ik zou nu dus zeggen gebruik CD met SNOMED CT als de gebruiker de keuze kan maken en NullFlavor als het systeem het doet. Maar het is fijner als je 1 codesysteem hebt, dus alles met SNOMED CT.

Dus:

BL	SNOMED CT (CD)
NullFlavor.NASK	1631000175102 | Patient not asked |
NullFlavor.UNK	261665006 | onbekend (kwalificatiewaarde) |
true	373066001 | ja (kwalificatiewaarde) |
false	373067005 | nee (kwalificatiewaarde) |

Ben benieuwd naar de reacties

 

[Elze de Groot]

Ik ben zelf niet zo fan van ja/nee in Snomed. Daar kun je helemaal niks mee. Vaak is absent/present beter omdat dit in een postcoordinatie gebruikt kan worden. Bijv als het gaat om een bevinding die wel/niet aanwezig is of onbekend. Maar dat is afhankelijk van de vraag waar ja/nee een antwoord op is. Dus wellicht heb je meerdere waardenlijsten nodig.

Vaak zij. Die null flavors wel handig als het toch geen semantisch bruikbaar concept oplevert in Snomed.

 

[Christine van der Aa]

Dit is wel een onderwerp waar ik ook mee te maken heb bij onze datasets voor kwaliteitsregistraties. Daar komen allerlei items in voor als "is er sprake van een complicerende factor" met als antwoordmogelijkheid
1 enkele benoemde aandoeningen
2 anders, nl. ...
3 onbekend
4 geen
De opties 1 en 2 staan dan in een DHD- of SNOMED-waardelijst, optie 3 is NullFlavor OTH, en voor 4 wisten we het niet goed, en hebben voorlopig (bij cataract) een SNOMED-term gebruikt, 2667000 afwezig (kwalificatiewaarde). Die laatste 2 staan dan in ART-DECOR onder de Uitzonderingen, dus niet in de standaard-waardelijst.

Nu heb ik een paar vragen:
@Elze de Groot en @Michael van der Zel
- Wat is precies het probleem van de NullFlavors bij implementatie?
- Waarom kennen de NullFlavors geen waarde "afwezig"?
- De waarden worden verstuurd in het kader van de betreffende vraag. Maar ik zou in de zib Probleem (wat hier van toepassing is) inderdaad niet weten waar ik dit kwijt zou kunnen, en postcoördineren met een ProbleemNaam kan niet omdat er allerlei aandoeningen mogelijk zijn. Nu wordt de zib in FHIR wel verstuurd in de context van de betreffende vraag, zou het dan wel "los" verstuurd kunnen worden in plaats van de zib Probleem? En als dat ook niet wenselijk is, is er dan bezwaar om gewoon af te spreken dat we "GEEN" doorsturen?

 

[Michael van der Zel]

Het beste is om volledige codes te gebruiken. Dus idd zoals Elze zegt niet de kwalificatiewaarde los.
Bij het voorbeeld "geen" van Christine, zou ik dan "315215002 | aandoening uitgesloten (situatie) |" gebruiken.
Voor "onbekend" wellicht iets met "no known condition" of "unknown complications" ofzo.

Doorgaans is NullFlavor, en de FHIR versie DataAbsentReason, bedoeld voor system level redenen. Dus "Not Asked" betekent "The workflow didn't lead to this value being known", het is dus geen keuze aan de eindgebruiker.

 

[Christine van der Aa]

Als ik dit zo lees denk ik dat uitgebreidere toelichting op het gebruik van NullFlavors heel welkom zou zijn. Is hier een factsheet voor of zo? Ik zou Not Asked makkelijk geïnterpreteerd kunnen hebben als "was niet door de zorgvelener gevraagd". En UNK ook als een optie die een zorgverlener zou kunnen invullen als men het gevraagde gegeven niet weet of kan opvragen. Klopt dat dan ook niet?
Maar hoe zit het dan met de waardelijsten in de zibs waarin ook UNK of OTH is opgenomen? Bv. VerificatieStatus in zib Probleem kent de NullFlavor UNK naast de SNOMED-waarden waar de rest van de lijst uit bestaat. Is die dus niet bedoeld voor de zorgverlener maar voor het systeem? En wat is er dan de functie van?

Overigens lijkt 315215002 | aandoening uitgesloten (situatie) | me inderdaad een veel betere keuze dan 2667000 afwezig (kwalificatiewaarde) voor bovengenoemd doel.

 

[Elze de Groot]

Wat betreft 'geen complicaties' zou een wijziging in datasetstructuur ook nog een optie kunnen zijn door geen eruit te trekken.
Als je perse wilt weten dat er geen complicaties zijn opgetreden bij een bepaalde verrichting (op het moment van registreren dan, want er kan later nog een complicatie optreden) dan kun je ook eerst een vraag stellen 'is er wel/geen complicatie opgetreden' en zo ja dan de lijst met mogelijke complicaties openklappen. Dan kun je voor de vraag voor of er een complicatie is opgetreden de waardenlijst ja/nee/onbekend gebruiken.
Aandoening uitgesloten vind ik een lastige bij complicaties, omdat je nooit weet of er nog een complicatie gaat optreden. Kun je het dan wel uitsluiten?

Maar een richtlijn voor null flavors is zeker wenselijk, we willen dit ook gaan opnemen in onze leidraad terminologiekoppelingen. Voor zover ik weet wordt op dit moment UNK gebruikt als het gegeven niet bekend is. In die zin kan dat ook aan de gebruiker getoond worden uiteraard.

 

[Lonneke Vermeulen]

Wij gebruiken bij de oncologie de null flavors UNK en OTH ook volop in onze waardelijsten. Deze worden ook gebruikt voor het tonen aan zorgverleners. (Ik dacht eigenlijk dat dat de 'standaard' was om het te doen)

 

[Christine van der Aa]

@Ali Zada , is er een factsheet o.i.d. beschikbaar over hoe de NullFlavors bedoeld zijn en hoe ze eigenlijk gebruikt zouden moeten worden? Want het lijkt er nu op dat hier verschillende interpretaties over mogelijk zijn.

 

[Christine van der Aa]

@Michael van der Zel Hoe is dit dan indertijd bij het ontwikkelen van de zibs gedefinieerd? Is wat je in je post van 16-12 schrijft een nieuwe manier om ertegenaan te kijken, of was het nooit de bedoeling om de NullFlavors te gebruiken als opties voor zorgverleners om in te vullen?

En hoe zien anderen het gebruik van de NullFlavors, bijvoorbeeld @Erik van der Velde , @Daniel Woning , @Fred Smeele ?