search

BRP-API / Haal-Centraal-BRP-bevragen

https://brp-api.github.io/Haal-Centraal-BRP-bevragen/
Other
33 stars 22 forks source link

Als berichtonwikkelaar wil ik weten welke onderdelen van het LO-GBA opgenomen worden in deze bevragingen API. #147

Closed JohanBoer closed 3 months ago

JohanBoer commented 5 years ago

...zodat ik de API-specificatie op kan stellen en kan verifieren of die compleet is. Onderhanden wijzigingen n.a.v. LO GBA.docx

Definition of done

CathyDingemanse commented 5 years ago

Hierbij mijn antwoorden Onderhanden.wijzigingen.n.a.v.LO.GBA COMMENTAAR CD.docx

JohanBoer commented 5 years ago

GertJan: 2) Als er nog nieuwe GBA-rubrieken aan het model worden toegevoegd die een datum betreffen, voor deze datumvelden controleren of deze (deels) onbekend kunnen zijn

gertjanvanderkooij commented 5 years ago

Bijgaand mijn review op document. Onderhanden.wijzigingen.n.a.v.LO.GBA.COMMENTAARCD_ReaGKJ.docx

@JohanBoer ; voor de nieuwe datumvelden aangegeven of deze onder het '(deels) onbekend' regime vallen.

CathyDingemanse commented 5 years ago

Hierbij mijn reactie. Onderhanden.wijzigingen.n.a.v.LO.GBA.COMMENTAARCD_ReaGKJ_PO.docx

JohanBoer commented 5 years ago

@CathyDingemanse Frank constateert dat conform bovenstaand document het element "indicatie onjuist" (84.10) zou moeten worden opgenomen in de verblijfplaats. Ik meen mij te kunnen herinneren dat we die indicatie niet op zouden nemen, maarkan daar nergens documentatie over vinden. Wel hebben we gedocumenteerd dat bij de partner, ouder en kind de indicatie onjuist niet opgenomen wordt.

Wil jij uitsluitsel geven of indicatie onjuist in de verblijfplaats moet worden op[genomen ?

fsamwel commented 5 years ago

@CathyDingemanse Frank constateert dat conform bovenstaand document het element "indicatie onjuist" (84.10) zou moeten worden opgenomen in de verblijfplaats.

Er zit nu ook een inconsistentie tussen de API specificatie, waar in Verblijfplaats geen indicatieOnjuist is opgenomen, en de feature indicatie onjuist, waarin staat "Alleen voor de categorie 08.58 Verblijfplaats wordt de indicatie onjuist opgenomen." Onze developers weten hierdoor nu niet hoe dit geïmplementeerd moet worden.

CathyDingemanse commented 5 years ago

@JohanBoer @fsamwel We hebben idd afgespreken dat we niets opnemen met een indicatie onjuist. Dat geldt dus ook voor een Verblijfplaats met indicatie onjuist.

gertjanvanderkooij commented 5 years ago

Heb ik op zich geen probleem mee; eerder is hierover gemeld dat SocialeZaken hier specifieke behoefte aan had (zie reactie Cathy op 28-2 j.l op mijn review 'OnderhandenWijzigingennavLOGBA' hierboven):

"Voor Categorie 08/58 is ‘Indicatie onjuist’ nu als ‘Graag opnemen’ aangegeven; eerder is een besluit genomen om de categorieën met de indicatie ‘onjuist’ in z’n geheel niet te leveren. Draaien we dit nu terug? Dan alleen voor adres of geldt ook hier dit aspect generiek te behandelen?"

"IS EEN FUNCTIONELE WENS VAN SOCIALE ZAKEN (UITKERINGSFRAUDE). GELDT NIET VOOR ANDERE CATEGORIEEN. DEZE KUNNEN WE ER ALTIJD NOG BIJ LEVEREN ALS EEN AFNEMER MET DEZE BEHOEFTE ZICH MELDT."

CathyDingemanse commented 5 years ago

Tjonge, het is maar goed dat er nog iemand oplet! Thnx Gert-Jan! Deze dus wel opnemen.

fsamwel commented 5 years ago

Is het voor gebruikers dan niet logischer hiervoor een eigen endpoint te maken, of het in (historische) bewoning op te nemen? Anders moet elke consumer bij een adres eerst checken of het onjuist is. Wanneer de developer (van iets anders dan sociale zaken) dat "vergeet" wordt mogelijk een onjuist adres gebruikt.

CathyDingemanse commented 5 years ago

Zeker, het is ook historie!

JohanBoer commented 5 years ago

Prio laag, maar de content moet wel gedocumenteerd worden in de design decisions. Taak voor Johan

Check ook nog even de laatste drie opmerkingen over indicatie onjuist.