In overleg met het NCJ is besloten om de nieuwe elementen in R052 alleen op te nemen in het scenario 'registratie jeugdige'. De voorgestelde technische/template uitwerking is uit dit ticket gehaald.

Cf. het proces beschreven door Tanja, zodra je een signaal invoert controleer je ook op een match, dit is inherent aan het proces.

— Dan weet je direct of er een match is

— Dus de 'ja' (er is een match) gaat samen met een datum waarop de match is ontstaan.

Als je het direct weet en niet registreert volg je dus niet de richtlijn. Zou ook raar zijn, want je bent op dat moment de registratie aan het invullen.

Overigens is dat dus bij een geautomatiseerde koppeling met de verwijsindex al niet mogelijk. Op het moment dat er een signaal geregistreerd wordt, krijg je direct terug of er een match is of niet. Dat geldt voor de handinvoer ook.

Pas als er later een match is, is de datum ook relevant, maar hiervoor geldt dat dit dus in een ander contactmoment/registratie plaatsvindt omdat de terugkoppeling asynchroon is, dan zit je dus weer buiten de groep waarin de oorspronkelijke aanmelding heeft plaatsgevonden.

@Meindert-Jan Kroese, het moet mogelijk zijn om een onderscheid te maken tussen:

• Het niet uitvoeren van de controle op de match;

• Het controleren op een match met de constatering dat er geen match is. 

Hoe komt dit naar voren als E1621 een berekend veld is? Bij E1622 = <LEEG> is het nog niet duidelijk of er geen match is, of geen controle is gedaan.

Voor de verplichting van ja+datum heb ik een ander voorstel, namelijk de eis dat nee+datum niet mag. Deze eis heb ik verwerkt in het concept als een schematron assert.

De gecombineerde verplichting ja+datum (en nee: geen datum) maakt de implementatielast voor de leveranciers wel iets zwaarder omdat dit een vreemde eend in de bijt is als je kijkt naar de rest van de BDS. Eventuele historische waarden die dus nu non-BDS geregistreerd worden en conversie daarvan vereist dus ook het meenemen van de waarde "ja" voor E1621. V.v. kan het ook zijn dat organisaties alleen de match hebben geregistreerd, zonder datum.

M.i. is het alleen logisch om datum match te registreren, waarbij het ontbreken van een waarde impliceert dat er (nog) geen match is. Ik weet ook dat impliciete betekenissen niet gewaardeerd worden, maar dit voelt wel als een over-engineering voor exact 2 registraties die exact 2 varianten kan kennen:

• E1621 = JA, E1622 = <een datum, niet leeg>

• E1621 = NEE, E1622 = <LEEG>

Voorstel om E1621 een berekend veld te maken op basis van vulling van E1622. In de uitwisseling kan je namelijk slechts bovenstaande varianten doorgeven.

Implementatie in UI kan het nog steeds tonen als 2 velden, waarbij de verplichting dus gevolgd wordt uit de BDS.

Hallo @Tanja Geerdes,

We gaan de beschreven functionaliteit opnemen in de voorgestelde oplossing van dit ticket en vervolgens toetsen met de leveranciers. Als die akkoord gaan dan kunnen we het zo doorvoeren.

Zie de beschrijving van de aangepaste functionaliteit in https://nictiz.atlassian.net/browse/JGZ-303#icft=JGZ-303 en https://nictiz.atlassian.net/browse/JGZ-304#icft=JGZ-304.

Groeten,

Niek