Het issue is uitgewerkt, maar ivm. Hemelvaartsdag is de review nog niet afgerond. Dit issue heeft daardoor een kleine uitloop naar de integratieweek,

De R4-situatie is anders; die hint erop dat je de LOINC-code aanvullend zou kunnen gebruiken (overigens zou dit nog scherper verwoord kunnen worden). Het huidige profiel geeft je de keuze tussen ofwel de Snomed-code, ofwel de LOINC-code. Voor ontvangende partijen is het dus essentieel dat ze beide ondersteunen, terwijl dat in de R4-situatie niet zo is.

Bij een comment heb je altijd het gevaar dat het minder expliciet is dan een aparte slice en dat je het sneller over het hoofd ziet; het is waar dat je naar .code.coding moet kijken, maar de kans is groot dat er alleen naar de gestructureerde informatie gekeken wordt. Om die reden – twijfel – zou ik hier terughoudend zijn.

Het mooiste zou zijn om optie 1 te implementeren, aangezien we dan ook al vooruitlopen/aansluiten op het gemaakte R4-profiel. Het argument dat het profiel documentatiekracht verliest is op zich waar, maar datzelfde argument zou je kunnen opvoeren om de huidige R4-implementatie af te keuren (daar gelden immers dezelfde argumenten die je geeft m.b.t. het valideren van verschillende instances). Stel dat we de comment aanwezig op Observation.component:cuffType.code in het R4-profiel ook toevoegen in het STU3-profiel, dan denk ik dat het meevalt met het verlies aan documentatiekracht. Om als implementer van een ontvangend systeem namelijk erachter te komen wat voor codes verwacht kunnen worden, moet je namelijk toch al tot het niveau van de .code.coding doorzakken, en dan kom je vanzelf langs die comment dat ook de LOINC-code toegestaan is. Of zijn er toch nog incompatibiliteiten die ik over het hoofd zie wanneer je de R4-implementatie (zo goed als) volledig overneemt?

Overigens vind ik optie 2 ook nog steeds een redelijk mooi alternatief, maar mijn voorkeur gaat uit naar optie 1.

De aanpak met aparte slices voor cuffTypeLOINC en cuffTypeSNOMED is destijds gekozen om duidelijk te maken dat de Observation.component voor CuffType geïdentificeerd kan worden mbv. ofwel een LOINC-, ofwel een SNOMED-code – het gaat uitdrukkelijk niet om de gecodeerde waarde ervan. Met voortschrijdend inzicht is dat geen keus die interoperabiliteit ten goede komt. In de zib2020-uitwerking van dit profiel wordt er expliciet gekozen voor alleen de SNOMED-codering.

Deze aanpak zorgt er nu voor dat het problematisch is om de Observation.component met zowel de LOINC- als de SNOMED-code te identificeren, iets dat juist wel goed gebruik is en ook toegestaan zou mogen worden. Het commentaar in het profiel beargumenteert dit ook juist. (Nog een extra probleem is dat de manier van profilen niet conform de zib, omdat het nu in theorie mogelijk is om twee keer een CuffType mee te sturen, maar dat terzijde).

Het is echter niet mogelijk om de CuffType nu te standaardiseren op één van deze codes, dit zou voor sommige implementerende systemen een breaking change inhouden.

Mogelijke oplossingsrichtingen:

1. Verwijder de slice cuffTypeLOINC en plaats in de slice cuffTypeSNOMED de opmerking dat de LOINC-code als alternatief gebruikt mag worden. Pas daarna de discriminator aan naar een pattern op code zodat het daadwerkelijk mogelijk wordt om alternatieve codes te gebruiken naast de Snomed-code. Hiermee valideren zowel instances die Snomed gebruiken (de validator herkent de slice), instances die LOINC gebruiken (de validator herkent de .component niet als slice, maar andere .component's zijn toegestaan), en instances die beide coderingen gebruiken (de validator herkent de slice aan de hand van de Snomed-code). Dit vermindert iets van de validatiekracht op de gekoppelde waardelijst als alleen LOINC gebruikt wordt, maar de binding is extensible dus dat speelt geen grote rol. Het grote nadeel is echter dat het profiel documentatiekracht verliest – de mogelijkheid van de LOINC-code wordt minder zichtbaar, wat voornamelijk voor ontwikkelaars van ontvangende systemen problematisch is.

2. Pas alleen de discriminator aan naar een pattern zodat het daadwerkelijk mogelijk wordt om alternatieve codes te gebuiken. Dit vermindert het aantal foutmeldingen, maar instances met zowel de LOINC- als de Snomed-code worden hierdoor nog steeds afgekeurd omdat ze meerdere slices matchen.

Gezien het grote nadeel van optie 1 en de overweging om bij twijfel terughoudend te zijn, zou ik willen voorstellen om optie 2 te kiezen, aangevuld met een known issue-vermelding dat het gebruik van zowel de Snomed- als LOINC-identificatie binnen een slice toegestaan is en dat validatiefouten genegeerd dienen te worden.