istandaarden / iwlz-indicatie Goto Github PK

De requirements rondom Bopz zijn verre van duidelijk. Verder is het best waarschijnlijk dat deze tijdens de POC niet gebruikt zullen worden.

Om overbodig werk te voorkomen, zou ik willen voorstellen om het endpoint /wlzindicaties/{wlzindicatieID}/bopz/ te verwijderen tot de requirements bekend zijn.

De waarde "04" (Tijdelijk adres) ontbreekt in de gedefinieerde enumeratie van het element.

Kijk bijv naar de response van https://petstore.swagger.io/?url=https://raw.githubusercontent.com/iStandaarden/iWlz-indicatie/master/api-specificatie/indicatieregister.yaml#/operations-bopz-getBopz. Die geeft in de swagger ui view:

(no example available)

bij de responses.

MrinDoc wil niet eens laden.

In een eerdere versie zat de Uzovi in de entiteit 'Wlzindicatie'. Deze is in de huidge versie verdwenen.
Wij als Menzis hebben echter 3 zorgkantoren onder ons beheer. Het is voor ons van belang dat wij niet hoeven te bepalen voor welk zorgkantoor de geraadpleegde wlzindcatie is aan de hand van het vestigingsadres van de cliënt.

Verzoek om of in de entiteit 'Wlzindicatie' de Uzovi terug te doen keren of in de notificatie op een abonnement mee te geven voor welke Uzovi genotificeerd wordt!

Onderdeel wijziging:
BeperkingScore

Voorstel wijziging:
BeperkingScore hoort onder de Beperking (situatie als in IO31)
Separate BeperkingScore verwijderen.

@removanrest is dit iets wat we nu nog recht moeten trekken?

In GraphQL heet het type ContactGegevens

In OpenAPI heet het type ContactGegeven

Onderdeel wijziging:
De GraphQL specificatie bevat gecommentarieerde enumeratie regels. Deze worden niet gebruikt in de schema specificatie zelf en zijn beschikbaar in het informatiemodel (informatiemodel.istandaarden.nl)

Voorstel wijziging:
verwijderen uit specificatie

Onderdeel wijziging:
In de yaml-specificatie is het datatype van geslacht gespecificeerd als integer. Dit wijkt af van de specificatie in de huidige iWlz xsd's en graphQl-specificatie. Daarin is het datatype gespecificeerd als String.

Met de verwachte toevoeging van non-binaire geslacht (met code X), is het ook wenselijk om als datatype String te hanteren.

Voorstel wijziging:
datatype in yaml-specificatie wijzigen van integer naar string.

YAML wijziging:

GraphQL wijziging:

Onderdeel wijziging:
/wlzIndicaties

Voorstel wijziging:
Nu wordt

geretourneerd, dat kan korter:

3fa85f64-5717-4562-b3fc-2c963f66afa6

Met meerdere wlzindicatieIDs wordt dat dan:

3fa85f64-5717-4562-b3fc-2c963f66afa6
3fa85f64-5717-4562-b3fc-2c963f66afa7
3fa85f64-5717-4562-b3fc-2c963f66afa8

Onderdeel wijziging:
Entiteiten adres, telefoon en email
Voorstel wijziging:
In de bovengenoemde entiteiten zit een verwijzing naar de entiteit contactgegevens. (Zie ERD op istandaarden voor het indicatieregister)
Deze verwijzing heet contactgegevenID. Puur voor het nette zou de verwijzing contactgegevensID moeten heten naar de entiteit waarnaar het gegevens verwijst

Onderdeel wijziging:
wzdVerklaringBijAfgifte: Boolean @deprecated # Niet bruikbaar ivm hybride situatie met berichten (IO31/AW33/ZK33)

Voorstel wijziging:
Kan de reden ook volgens de GraphQL specs worden meegegeven. Zie hier de specs hoe dit zou moeten.
https://spec.graphql.org/October2021/#sec--deprecated

Het zou dan zoiets moeten zijn als
wzdVerklaringBijAfgifte: Boolean @deprecated (reason: "Niet bruikbaar i.v.m. hybride situatie met berichten (IO31/AW33/ZK33)")

In de query strings van de GETs requests zit allemaal gevoelige persoonlijk info. Dat betreft niet alleen BSNs maar ook allerlei ids waarmee je vervolgens persoonlijke informatie kan ophalen.

Dit soort GET requests wordt overal vastgelegd in diverse server logging en vormt daarmee een security risico.

Daarom is het niet acceptabel dat er GET requests gebruikt worden. Svp omzetten naar POST requests.

(NB: dit heeft niets te maken met autorisatie issues).

https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url

Onderdeel wijziging:
Uit de fitgap analyse tussen de huidige kv-spec en het huidige IO31 bericht is gebleken dat volgnummer relatie ontbreekt in het register. Deze alsnog toevoegen om de overgangssituatie naar het register beter te ondersteunen.

Voorstel wijziging:
property [volgorde] toevoegen aan schema [contactpersoon]

Relatienummer is onlangs toegevoegd aan ContactPersoon.

Aangezien het een "Identificerend nummer van de relatie van een client" is en een nummer is dat CIZ genereert zodra het wordt toegevoegd aan het IndicatieRegister lijkt het mij dat dit een verplicht nummer zou kunnen zijn.

Describe the bug
De voorgestelde wijziging mbt Contactgegevens in issue #35 is niet correct.

To Reproduce
ContactGegevens:
type: object
properties:
contactGegeven:
$ref: '#/components/schemas/ContactGegeven'
xml:
name: contactGegevens

Expected behavior
Contactgegevens moet een array zijn.

correct syntax
ContactGegevens:
type: object
properties:
contactGegeven:
$ref: '#/components/schemas/ContactGegeven'
xml:
name: contactGegevens

De huidige opzet van BOPZ en WZD in het koppelvlak wekt de suggestie dat op een willekeurig moment in de tijd een bevraging kan worden gedaan van een actuele waarde. Dit is echter bij de indicatie niet het geval. De waarde die Wzd heeft wordt door het CIZ vastgesteld op het moment van indicatiestelling en veranderd daarna niet meer.

Daarom is het voorstel gedaan Wzd weer onder de indicatie te plaatsen en onderdeel te maken van de Client. Dit komt overeen met het huidige indicatiebericht (IO31).

De wens is er wel voor een mogelijkheid een actuele Wzd-status op te vragen. Dit zal in een afzonderlijk WZD-register opgelost moeten worden.

BOPZ is in zijn geheel niet meer van toepassing

Onderdeel wijziging:
[Wzd] & [Bopz] verwijderen

Voorstel wijziging:
Onder Client de volgende attributen toevoegen met betrekking tot Wzd
<wzdVerklaring>1</wzdVerklaring>
<wzdIngangsdatum>2021-03-19</wzdIngangsdatum >
<wzdEinddatum>2021-03-19</wzdEinddatum >

In de huidig spec worden bij aan aantal endpoints 404 codes teruggeven met de volgende omschrijving:

Geen xxxxxx gevonden

Wij missen echter een onderscheid tussen "404 Geen xxxxxx gevonden" en "404 Onbekend WLZ indicatie ID". De afzender weet nu niet of er een onbekend wlzindicatieID in het request stond of dat er simpelweg geen entries waren voor de geleverde (en wel bekende) wlzindicatieID.

Bij de ​/wlzindicaties​/{wlzindicatieID}​/client​/** endpoints is dit, in onze ogen, correct gedefinieerd. Hier krijg je een 404 bij een onbekend wlzindicatieID en een 200 met een lege lijst als er geen contactpersonen (bijvoorbeeld) met de wlzindicatieID zijn geassocieerd.

Aangezien een 4xx error wijst op een client side error, lijkt het ons beter om deze code alleen te gebruiken als er door de afzender foutieve data in het request is gezet (e.g. Onbekend Wlz indicatie ID). Indien dit niet het geval is, moet de gevonden data aangeleverd worden met een 2xx status, ook al is dit alleen een lege array.

Ons voorstel is om dezelfde 404 logica toe te passen voor de overige /wlzindicaties endpoints (met uitzondering van de /wlzindicaties​/{wlzindicatieID} endpoint). Een geldig wlzindicatieID zonder geassocieerde data voor de opgevraagde endpoint resulteert dan in een 200 response met [] als body.
Als het toch gewenst is om een aparte status code te hanteren voor een request met een bekend wlzindicatieID maar geen geassocieerde data, dan stellen wij voor om hiervoor 204 No Content te hanteren.

Onderdeel wijziging:
De postcode van een client bepaald welk zorgkantoor de notificatie ontvangt van een nieuwe indicatie. De postcode van de client valt in die regio van dat zorgkantoor

Het zorgkantoor kan m.b.v. de ontvangen WlzIndicatieID een bevraging doen, maar controle of het zorg inderdaad het initieel zorgkantoor is geweest dat verantwoordelijk is gemaakt door het CIZ kan niet plaatsvinden zonder vastleggen van dat initieel verantwoordelijke zorgkantoor

Voorstel wijziging:
het element initieelVerantwoordelijkZorgkantoor toevoegen volgens het ERD

De afgesproken koppelvlak standaard is GraphQL.

De OpenApi specificatie wordt niet meer bijgewerkt is is vanaf versie 1.3.x - Indicatieregister 2 Deprecated.

Aanleiding

De structuur van de Client, Contactpersoon, Contactgegevens (incl Adres, Email en telefoonnummer) in GraphQL en OpenApi specificatie zijn niet in lijn met het ERD in het informatiemodel.

Beknopte Analyse
(Volledige analyse hier)

Voorstel
Wijzigingen overnemen zoals beschreven in de kolom Aanpassing GraphQL en Aanpassing OpenApi doorvoeren

Oplossing
-Wijzigingen in Aanpassing GraphQL in branch 35-graphql
-Wijzigingen in Aanpassing OpenApi in branch 35-graphql-openapi (inclusief Aanpassingen GraphQL)

Volledige Analyse

Ik zou graag bij de specs in Github een duidelijke omschrijving willen hebben met wat er precies bedoeld wordt met een bepaald veld en waar het voor dient. Bijvoorbeeld Xorgkey. Maar dat geldt voor alle velden.

Lijkt dubbelop.

De properties van het WZD object krijgen nu allemaal de prefix wzd. Lijkt overbodig?

Verder staat er ergens: "Nog verder aanvullen"

Onderdeel wijziging:
Het wijzigingsverzoek "iWlz 2024 - RFC001 Vervaldatum indicatiebesluit" beschrijft het toevoegen van een element vervaldatum aan het indicatiebesluit. (zie www.istandaarden.nl).

Het wijzigingsverzoek is goedgekeurd en is doorgevoerd in het informatiemodel iWlz Release 2.5 (zie https://informatiemodel.istandaarden.nl/iWlz25-netwerk/

Voorstel wijziging:
Overnemen wijziging: element vervaldatum toevoegen aan het object WlzIndicatie. type is Date en optioneel

Onderdeel wijziging:
GraphQL specificatie bevat een deprecated veld:

wzdVerklaringBijAfgifte: Boolean @deprecated(reason: "Niet bruikbaar i.v.m. hybride situatie met berichten (IO31/AW33/ZK33)")
Voorstel wijziging:
Dit element kan nooit terug worden teruggegeven want bestaat niet en niet aanwezig in de scope in het Lua-script.
Daarom verwijderen

Hallo,

Wat is de status van deze headers? Kunnen ze er uit als ze niet verplicht zijn?

Met vriendelijke groet,
Michiel

Onderdeel wijziging:
[onderdeel]
Wzd:
required:
- wzdVerklaring
- wzdIngangsdatum
-
Voorstel wijziging:
[wijziging]
Wzd:
required:
- wzdVerklaring
- ingangsdatum
-

In de endpoints wordt een X-PSID header opgevoerd. Eigenlijk is mij onduidelijk wat deze header betekent en wat het indicatie register er mee moet doen. Kunnen jullie documentatie opnemen in de swagger spec?

Verder komt deze header niet in de iWlz-generiek swagger voor. Is hij eigenlijk wel nodig?

"https://www.istandaarden.nl/ibieb/codelijsten-iwlz-221" geeft pagina niet gevonden.

Onderdeel wijziging:
De volgende twee queries zijn overbodig:

# Haal alle   Wlzindicaties voor bsn
 getWlzIndicatiesVoorBsn(bsn: String!): [WlzIndicatie!]
--
# Haal Client op   voor bsn
getClientVoorBsn(bsn: String!): Client!

Voorstel wijziging:
queries verwijderen