TE-BW.001: Extensible waardelijsten zijn voor software lastig en dynamisch onnodig

[CS-Olav]

https://richtlijnen.zibtransitie.nl/terminologie/binding-waardelijst/#te-bw001-de-binding-van-een-waardelijst-zou-extensible-moeten-zijn

Hier wordt gesteld dat waardenlijsten extensible zouden moeten zijn. In termen van zibs wil dit zeggen dat ook andere codes uit hetzelfde systeem zijn toegestaan. Dat lijkt vooral bedoeld voor als een nieuwe code in een systeem is toegevoegd, maar daarvoor lijken (required) dynamische waardenlijsten een betere oplossing. Deze brengen namelijk het voordeel met zich mee dat niet zomaar iets totaal onzinnigs kan worden geregistreerd terwijl de gebruikte codesystemen als SNOMED CT vaak zo breed zijn dat dat met een extensible waardenlijst wel het geval is. Wat moet software er mee als als status van het tabakgebruik van een patiënt bijvoorbeeld in plaats van "rookt", "rookt niet meer" of "heeft nooit gerookt" een "gebroken linker bovenbeen" geregistreerd is, wat met een extensible lijst hiervoor toegestaan zou zijn aangezien er ook een code voor in SNOMED CT zit?

Voorgestelde wijziging

Prefereer required waardenlijsten die waar nodig dynamisch zijn boven extensible waardenlijsten.

[rjpnienhuis]

Het idee achter de binding extensible is niet dat zij een oplossing is voor situaties dat een nieuwe code wordt toegevoegd aan een terminologie, maar dat een zorgverlener altijd de ruimte zou moeten hebben om iets anders te registreren dan vooraf in de waardenlijst is vastgesteld. Het voorbeeld van het gebroken bovenbeen is een goed voorbeeld om de discussie te openen of deze mate van vrijheid wenselijk is.

[CS-Olav]

@rjpnienhuis ik denk dus niet dat dit altijd wenselijk is. Wellicht is er een aantal concepten waarbij dit wenselijk is, maar ik denk dat er veel situaties zoals bovenstaand voorbeeld zijn waarin dit helemaal niet wenselijk is.

[rjpnienhuis]

DIscussie tav extensible igv FHIR: https://confluence.hl7.org/display/VOC/Policy+on+the+use+of+extensible+value+set+bindings

Let op de wording van issue: Extensible bindings including broad SNOMED CT value sets are nonsensical

@CS-Olav is jouw mening dat we juist terughoudend moeten zijn met extensible? Dus dat required de voorkeur heeft?

[CS-Olav]

@rjpnienhuis vooral i.c.m. dynamische bindings ben ik inderdaad van mening dat we terughoudend zouden moeten zijn met extensible bindings. Als iets nieuws nodig wordt, kan het dan immers ook (beter) in de terminologie worden opgenomen waardoor het niet nodig is een code van buiten de waardenlijst te gebruiken. Als 'iets anders' wordt geregistreerd, is dat bovendien meestal vrije tekst en is er dus meer behoefte aan de null flavor "UNC" dan aan een mogelijkheid om andere codes uit te wisselen.

[rjpnienhuis]

Uit de vogelvlucht sessie:

• Naast zibs ook (al dan niet domein specifieke) registratie afspraken maken die voldoen aan de zib.
• FHIR gaat fijnmaziger methoden voor extensible bieden. In de toekomst is dat een oplossing
• Als je iets wil afspreken (geldige waarden) dan moet die afspraak ook hard zijn
• Open world modelling: required binding is te restrictief voor zorgverleners. Dat moet wel in gedachten blijven
• Zegt extensible iets over het maturity level van de waardelijst? Er is (nog) geen afspraak
• Misschien heb je wel example nodig bij dynamische waardenlijsten
• Nullflavor gebruiken voor de andere gevallen

Consensus: binding ZOU required MOETEN zijn Uitzonderingen:

• Beheercyclus van onderiggend codesysteem niet vaak is (bijv net als zibs 4 jaar) -Igv hele zwakke afspraken --> dan is het dus ook een signaal dat er zorgbrede afsprsken gemaakt moeten worden