Zoekresultaat inclusief of exclusief overledenpersonen

[CathyDingemanse]

Originally posted by @CathyDingemanse in https://github.com/VNG-Realisatie/Bevragingen-ingeschreven-personen/issue_comments#issuecomment-428562691

Hieronder de opmerkingen van Frank, Johan en Joeri

[CathyDingemanse]

Frank:

Wat is het effect voor onze keuze voor zoeken bewoners op de functionele wens om wel of juist geen overleden personen terug te krijgen? Krijg je nu altijd bij /bewoners (of /bewoning ?) alleen levende personen en bij /bewonershistorie (of bewoningshistorie ?) altijd (voormalige) bewoners ook als ze inmiddels overleden zijn?

[CathyDingemanse]

Johan

Ik heb inmiddels de queryparameter "InclusiefoverledenPersonen"toegevoegd, zodat je expliciet aan kan geven of de overleden personen opgenomen moeten worden in het resultaat. Deze userstory heeft stevige raakvlakken met #9 en #17 .
Het zoeken op een adres (actueel of in het verleden) levert in mijn beleving altijd bewoners. (een bewoner is een ingeschreven persoon + de ingangsdatum en de einddatum van de relatie "Ingeschrevenop" (verblijfsadres). Vraag is of je in de resource "bewoners" dehele doopceel van de ingeschrevenpersoon opneemt of alleen enkele gegevens en een verwijzing naar de ingeschrevennatuurlijkpersoon.
Ik heb vooralsnog voor het laatste gekozen.

[CathyDingemanse]

Joeri

Iets RESTfuller zou zijn: ?overlijden=null. Dit betekent namelijk dat het (groeps)attribuut overlijden niet is voorzien van data. Hiervoor hoeft dan geen parameter verzonnen te worden.

Het is wel de omgekeerde variant: Standaard krijg je iedereen, en met filteren krijg je alleen mensen die nog niet overleden zijn. Dit is wel consistenter met de andere filters.

Als ik in Johans versie namelijk zoek op een BSN, en ik vind niets. Dan moet ik daarna zoeken op BSN + InclusiefOverledenPersonen, om te controleren of het wellicht een overleden persoon betreft. Geldt uiteraard ook voor zoeken op achternaam, etc..

Ik zou zo min mogelijk aannames doen op de "collection" (zoals er van uit gaan dat mensen moeten leven). Ik beschik echter niet over de User Stories die aangeven hoe de API het meest gebruikt zou worden.

[JohanBoer]

Joeri heeft hier een punt. Ik heb n.a.v. een discussie van enkele weken terug nieuwe resources gedefinieerd voor bewoning en bewoners (voor de endpoint /bewoningen). We nemen dan bij de bewoners de overlijdendatum op wn die nemen we daar ook als parameter op.

We kunnen overigens dezelfde informatie krijgen door de ingeschreven persoon te bevragen met een parameter geldigVan en geldigTotEnMet ingevuld (en natuurlijk de pastcode, huisnummer etc....) . Je krijgt dan alle ingeschreven personen inclusief hun historie op verblijfsplaats, (en ook de verblijfstitelhistorie en partnerhistorie die binnen de geldigVan en geldigTotEnMet vaallen)

Dan is de response weliswaar niet gestructureerd als een adres met de bijbehorende bewoners, maar als ingeschreven personen met hun adreshistorie voor zover die voldoen aan de criteria.
Als de parameters scherp genoeg zijn om 1 adres te selecteren krijg je dus alle personen die op dat adres gewoond hebben in de opgegeven periode.

Ik heb dit voor vandaag (12-10) nog niet in de openapi spec doorgevoerd.

[gertjanvanderkooij]

Als we het GBA-model als uitgangspunt nemen, kunnen we dan niet beter 'Reden opschorting' (in GBA rubriek 07.67.20). Dan markeer je niet alleen de 'overleden personen, maar bv. ook de geëmigreerde' personen.

Drietal aanpalende vragen:

1. Hoe gaan we in z'n algemeenheid om met personen die een indicatie geheimhouding hebben. In LO GB Ais hiervoor de volgende tekst opgenomen:
   "Bij het beantwoorden van de vraag speelt de Indicatie geheim op een PL een belangrijke rol.
   Door deze indicatie kan de verstrekking van persoonsgegevens aan bepaalde groepen
   afnemers worden tegengegaan. De groepen afnemers waarvoor dit van toepassing is, zijn
   geautoriseerd voor het stellen van ad hoc vragen, maar hebben de Indicatie geheimhouding
   aan staan in hun autorisatietabelregel."

2. Hoe wordt omgegaan met het feit dat één van de gegevens van een persoon 'InOnderzoek' kan zijn; wordt dit standaard meegeleverd?

3. In de functionele specificaties wordt aangegeven dat 'De gegevens in de API zijn zoveel mogelijk gemodelleerd zoals deze ook in de bron zitten.'. Kan ik op Github een lijst vinden van de maximaal door de Bevraging-API te leveren gegevens, inclusief de eigenschappen (naam, type, enumeraties etc)?

[fsamwel]

Kan ik op Github een lijst vinden van de maximaal door de Bevraging-API te leveren gegevens, inclusief de eigenschappen (naam, type, enumeraties etc)?

Dit vind je in de API-specificaties

[fsamwel]

Hoe wordt omgegaan met het feit dat één van de gegevens van een persoon 'InOnderzoek' kan zijn; wordt dit standaard meegeleverd?

Goede vraag. Ik heb hiervoor issue #74 gemaakt. Dit punt was nog niet geadresseerd.

Heb je een voorstel hoe je dat graag in de api zou willen zien?

[fsamwel]

Hoe gaan we in z'n algemeenheid om met personen die een indicatie geheimhouding hebben. In LO GB Ais hiervoor de volgende tekst opgenomen:
Ook dit is een belangrijke vraag. Hiervoor issue #75 gemaakt.

[fsamwel]

queryparameter zit in de open api specificaties