istandaarden / iwlz-generiek Goto Github PK

Hoi Heren,

Als ik naar de specificaties bij GraphQL kijk maken ze van enum value's UPPER_SNAIL_CASE. Zie hieronder 2 artikelen daarover:
https://graphql.org/learn/schema/#enumeration-types
https://chillicream.com/docs/hotchocolate/defining-a-schema/enums#naming

Is het oké als wij deze naming convention overnemen?

De wijzigingen beschreven in de de RFC's

• RFC0008 - notificaties en abonnementen: iStandaarden/iWlz-RequestForComment#2
• RFC0018 - (Fout-)meldingen: iStandaarden/iWlz-RequestForComment#16

Zowel organisatieId als organisatieIdType zijn verplicht bij het creeeren van een abonnement.

Ik dacht dat was omdat we willen registreren welke organisatie achter het zendende NP het abonnement wilde aanvragen.

Maar we geven dit organisatie id niet mee in de callback. Wordt de organisatie dan toch ergens in het netwerk bij het abonnement geregistreerd? In dat geval hoeven organisatieId en organisatieIdType wellicht niet verplicht te zijn.

het returntype van createAbonnement is nu gebaseerd op het complete abonnementstype, maar de response bevat alleen het abonnementsID. Omdat type Abonnement meer verplichte velden bevat is dit type niet geschikt.

@stefanbertensvecozo

Er zit een abonnementType in de request, dus waarom zitten er nog aparte organisatie, persoon en record ids in de request body?

Gewoon abonnementType, entiteitsId en entiteitsIdType lijkt dan wel voldoende.

/volgindicaties/record heeft geen definitie voor header x-request`-id.

Dat geldt bijvoorbeeld ook voor de callback {/netwerkpunt/zendNotificatie}.

Er zijn waarschijnlijk nog meer plekken.

De wijzigingen beschreven in de de RFC

• RFC0016 - Service Directory: iStandaarden/iWlz-RequestForComment#20

In de callback is 'all' als eventType opgenomen. Dat lijkt mij onjuist.

Hoi Heren,

Zoals besproken nog even een samenvatting van een aantal bevindingen / vragen:

In alle types kunnen deze velden weg
xOrgKey: Int! # Uniek ID van het netwerkpunt binnen het netwerk
xRequestID: String! # Identificatie van het request

Bij DeleteAbonnement kan dit veld weg
deletedAt: Time!

Is processAbonnement omdat het zowel een create al een update ondersteund?
Of is createAbonnement wellicht een logischere naam?

Het returntype van deleteAbonnement is nu een Abonnement. Dit is onlogisch in onze ogen.
deleteAbonnement(input: DeleteAbonnement!): Abonnement!

In de Backoffice van het CIZ wordt bepaald voor welk Zorgkantoor een notificatie moet zijn. Echter wordt dit niet meegegeven in de notificatie richting het netwerkpunt. Hierdoor moet het netwerkpunt bijhouden welke abonnementen zijn afgesloten voor welke organisatie. Vervolgens moet het netwerkpunt de body van het notificatiebericht openen omdat alleen daarin het volgindicatienummer zit, ipv, in een header.

Beide issues kunnen voorkomen worden door in de header mee te geven voor welk zorgkantoor (Uzovi) (of andere netwerkpartij) de notificatie is.

/backoffice/abonnement worden zowel X-orgKey als organisatieId gebruikt - lijkt dubbelop?

Het probleem dat ik zie is dat het type naar dit enum refereert als CamelCase. Terwijl het enum zonder CamelCase is gedefinieerd.

Wat ik verwacht is dat het enum AbonnementType wordt genoemd.

Het is denkbaar dat we abonnementen gaan verwijderen zonder dat daarvoor een aanvraag komt van buiten het IndicatieRegister.

Een voorbeeld is als een client overlijdt (oid). In dat geval zal (als er een abonnement op de client is), een event worden gestuurd voor het deleten van een client via de callback.

In dat geval zullen we ook gelijk het abonnement verwijderen want er is geen garantie dat er een DELETE gaat komen die dit aanvraagt.

Is er een wens om voor het verwijderen van een abonnement ook een event te ontvangen?

Zo ja, dan zal wellicht de request body van de callback uitgebreid moeten worden.

eventType:
description: specificatie voor welke gebeurtenissen er een abonnement wordt afgesloten. all = alle gebeurtenissen / create = alleen aanmaken / update = alleen wijzigingen
type: string
entiteit:
description: entiteit waarop het abonnement geplaatst moet worden
type: string
enum: ["all","create", "update", "delete"]

Yup, de enum moet verplaatst worden

Hoi Hilko en Remo,

In de schema van netwerkpunt/notificeren staat dat de recordID type is een string en als voorbeeld wordt deze url meegegeven "https://api.ciz.nl/wlzindicatieregister/wlzindicaties/da8ebd42-d29b-4508-8604-ae7d2c6bbddd".

Van CIZ hebben we vernomen dat de recordID altijd gevuld zal worden met een uuid (id van de record en bij notificeren betreft het om de id van de indicatiebesluit).

Willen jullie svp beoordelen of de schema aangepast moet worden naar type uuid en dat het voorbeeld in de schema dan ook mee aangepast wordt? Bedankt!

Met vriendelijke groet,

Rini van Ras