Kardinaliteit naamgegevens bij patient, 1..1 is te strikt ivm kwaliteitsregistraties

Wijzigingen doorgevoerd in EA.

Reactie consultatieronde door de FMS (Annemarie Trompert):

Een ZiB is usecase onafhankelijk. Ik neem aan dat elke patient een naam heeft . Beter zou zijn om per zib element toe te voegen van een patient of het AVG item bevat en dus alleen bij een behandeltrelatie mag worden uitgewisseld en dus niet aangeleverd mag worden aan kwaliteitsregistraties

Reactie functioneel beheerder zib centrum:

**(toelichting gevraagd)  Zie uitleg in BITS bij betreffende issue

Reactie consultatieronde door Registratie aan de bron (Christine van der Aa):

Niet mee eens; deze zib is primair van belang in het zorgproces, en daar zijn naamgegevens essentieel. Dat een kwaliteitsregistratie ze niet kan/mag gebruiken is irrelevant. Zij hoeven het zelf niet op te slaan: ze kunnen kiezen in hun eigen database dit dataelement weg te laten, of standaard te vullen met nvt. Het moet ook mogelijk zijn om bij versturen van de zib deze gegevens weg te filteren of te versleutelen. 

Reactie functioneel beheerder zib centrum:

(niet overnemen) zie argumentatie in BITS. Punt is niet dat het niet van belang zou zijn in het zorgproces, maar er zijn in toenemende mate usecases buiten het zorgproces. Is ook in lijn met het principe dat inperkingen niet in de zibs moeten, maar in de toepassing

Reactie consultatieronde door Nexus:

In de voorgestelde oplossing kan het in de praktijk dus zijn dat er patientgegevens binnenkomen zonder naam. In geval je deze gegevens wel nodig hebt, waarbij deze niet technisch afgedwongen worden, dan kan je echter hiaten krijgen in de registratie. Een beter voorstel zou zijn om geen gestandaardiseerde anonimiseringsmogelijkheid op deze velden te zetten. Dit zou dan gelden voor alle zibs met privacy gevoelige informatie

Reactie functioneel beheerder zib centrum:

(niet overnemen) Moet in de toepassing/informatiestandaard worden opgelost.

De suggestie 1..x altijd te interpreteren als "required" en dan een nullFlavor te gebruiken vind ik niet geweldig. We hebben veel ellende gehad in perinatologie v3 met deze aanpak, het leidt dan tot elementen die wel verplicht in een document moeten zitten en dan nullFlavor="NI" krijgen: kortom, er wordt nog steeds geen informatie uitgewisseld, niet anders dan bij 0..x en deze constructie alleen maar omdat iets dan enkel voor de vorm 1..x genoemd kan worden. In mijn ervaring vaak een bron van frustratie bij leveranciers die door een XML hoepeltje moeten springen voor gegevens die ze niet kunnen/willen/mogen aanleveren.

Wat ook een probleem is: nullFlavors kun je bij coded datatypes wel vastleggen, maar wat zijn de toegestane nullFlavors bij booleans of quantities? Vaak zijn maar enkele relevant (UNK, MASK). 

Zou fijn zijn als de zibs deze problemen voorkomt. FHIR lost het in mijn ogen beter op: Patient.name is gewoon 0..*.

Lijkt me trouwens dat ook voor de zibs 1..x voor naamgegevens patient te strikt is: als iemand niet aanspreekbaar en zonder id op de IC beland ga je ook eerst behandelen, en niet uitzoeken wat de naam is. Als dan overgedragen moet worden aan een UMC, hoe doe je dat dan?