istandaarden / iwlz-generiek Goto Github PK
View Code? Open in Web Editor NEWKoppelvlak specificaties met netwerk brede functionaliteit
License: GNU General Public License v3.0
Koppelvlak specificaties met netwerk brede functionaliteit
License: GNU General Public License v3.0
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
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.
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.