Wijzigingsvoorstel technische verbetering berichten (#487346)

Dag Arjan,

In reactie op de voorgestelde wijzigingen:

1. Komt met het introduceren van ‘geboortedatumVermoedelijk’ de werkwijze te vervallen dat bij geboortedatum van een ongeboren kind de verwachte geboortedatum gevuld mag worden?
2. In de huidige standaard zijn er ook al een aantal regels voor het omgaan met gedeeltelijke en onvolledige geboortedatums. Op welke wijze wordt duidelijk gemaakt dat geboortedatumVermoedelijk gaat over de verwachte geboortedatum van een ongeboren kind, en niet over de onbekende of onvolledige geboortedatum van een geboren persoon.
3. Waarom moet het adres bij notificatieDi01-berichten verplicht worden? Vanuit de RvdK is dit gegeven bijna altijd leeg. Met het verplicht stellen van dit element krijg je vooral een grotere xml met lege elementen. Is dit de bedoeling?
4. Punt 3 geldt ook voor de zorgmelding. Ook hier wordt in de praktijk niet veel meer dan een bsn meegeleverd. Wat voegt het verplicht stellen van deze adreselementen toe?
5. Naast adreselementen wordt bij de zorgmelding ook voorgesteld om naam, geslacht, geboortedatum e.d. verplicht te stellen. Welk doel dient dit als deze velden in de praktijk toch niet gevuld worden?
6. Bij de ontvangen zorgmeldingen valt op dat bij meerdere adressen van een `heeftBetrekkingOp` adresgegevens in de extraElementen worden opgenomen. Dit is niet erg standaard, en bovendien ook niet in de documentatie terug te vinden. Het liefst zouden wij hier een structurele oplossing voor zien, het gebruik van extraElementen is mijn ogen wel praktisch maar niet gewenst. Als dit als werkwijze behouden blijft zou ik dit graag opgenomen zien worden in de documentatie.

In reactie op voorgestelde wijzigingen W1507 002 en W1507 001:

1. In de berichtspecificatie van jz0101 (en ook 0904) wordt gesproken over `verblijfadres` als het gaat om het vastleggen van het adres van de jeugdige en diens belanghebbende. De voorgestelde wijzigingen suggereren naar onze mening dat naast het verblijfadres straks ook het GBA-adres (zou dit niet BRP-adres moeten zijn?) meegegeven moet worden. Dit lijkt mij niet wenselijk. Welk probleem moet hier eigenlijk opgelost worden?

Wat betreft planning van de releases:

Zou het een idee zijn om met een Tick-Tock planning te gaan werken? Je kunt dan één keer per jaar een grote wijziging doorvoeren met de mogelijkheid om nieuwe schema's en nieuwe berichten te introduceren. Bij de volgende halfjaarlijkse release doe je geen wijzigen aan de wijze van het berichttransport (cpa's) en de berichttypes. Deze release kan gebruikt worden om issues uit de vorige release op te lossen, bijvoorbeeld door nieuwe businessrules toe te passen of een patch uit te brengen op de bestaande schema's. Dit maakt de wijzigingen in de applicatie te overzien, ook kunnen we dan de bestaande testinrichting en testaansluiting gebruiken om de ketentesten te doorlopen.

Hartelijke groet,

Jarich Ypma, Solviteers

Gezien de opmerkingen van Jarich, stel ik voor om dit voorstel eerst verder uit te werken. Vervolgens is het goed om de impact (oa compatibiliteit oude en nieuwe versie) van de wijzigingen te beoordelen. De verhouding tussen het effect van de voordelen en de impact van de aanpassingen moet een wijziging rechtvaardigen.

Ik kan niet bepalen of dit voorstel correct is omdat het een technische invalshoek lijkt te hebben en ik de relatie met de functionele behoeften niet kan leggen.