Interfaces Notificatie Broker
Mitz Notificatie Interface
Deze interface is slechts bedoeld voor gebruik door Mitz, en kan niet worden gebruikt door GBx-applicaties.
Feature | |
|---|---|
Type | Service |
Versie | 1.0.0 |
Systeemrolcode | - |
Groep | Broker |
Gepubliceerd |
|
Delta | Initiële versie. |
Use case |
Feature | Versie | Dependency | Aanbieder | Afnemer |
|---|---|---|---|---|
1.0.0 | AORTA-ID HTTP Header | >=1.0.0 | - | |
1.0.0 | AORTA-Version HTTP Header | >=1.0.0 | - | |
1.0.0 | >=1.0.0 | - |
Een notificatie betreft een POST van een FHIR Bundle van het type “transaction”.
De inhoud van een Toestemming Notificatie is beschreven in het Mitz afsprakenstelsel. Mitz documentatie, FHIR-profiel en voorbeeld(en) zijn te vinden bij de specificaties van Feature: consentNotification.
HTTP statuscodes
HTTP statuscodes die kunnen worden geretourneerd zijn opgenomen in onderstaande tabel.
Omdat bepaalde Confluence macro’s nog niet worden ondersteund in de publicatie omgeving, bevat de tabel, in de publicatieomgeving, ook informatie over de wijze waarop de betreffende interface wordt geïmplementeerd in de server component. De statuscodes die kunnen worden geretourneerd zijn opgenomen in de kolom “Uitkomst”. De overige informatie mag worden genegeerd.
AOF.UCe.VAL.100.v1 - Toetsing type content | Uitkomst | |
|---|---|---|
Stap | Omschrijving | |
i | Het systeem ontvangt een verzoek en start de verwerking. Het systeem toetst of het gevraagde type content (Accept header) en het gehanteerde type content (Content-Type header) worden ondersteund. NB. wanneer het verzoek wordt ontvangen van een component van VZVZ, dan hoeft geen toets op type content te worden uitgevoerd. | Gevraagd type content niet ondersteund statuscode 406 Not Acceptable |
Gehanteerd type content niet ondersteund statuscode 415 Unsupported Media Type | ||
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
AOF.UCe.VAL.160.v1 - Inhoudelijke toetsing request | Uitkomst | |
|---|---|---|
Stap | Omschrijving | |
i | Het systeem toetst of het request geen malafide inhoud bevat (zie FHIR security, input validation). | Ongeldig verzoek statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
ii | Het systeem toetst of het verzoek voldoet aan de interface specificatie. Hierbij moet ook worden voldaan aan de toelichting "Controle van batch en transaction requests". FHIR-requests dienen te worden getoetst tegen de core FHIR specificaties (RESTful API). Indien een Indien een specifieke FHIR-profiel van toepassing is voor het gevonden interactie-id, dan dient het FHIR-request hier ook tegen te worden getoetst. NB. toetsing tegen een volledig FHIR-profiel wordt nog niet gedaan - consequenties van deze toets worden eerst in kaart gebracht. | Ongeldig verzoek statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
Stap | Omschrijving | Uitkomst |
|---|---|---|
1 | Het systeem verkrijgt, m.b.v. Feature getApplication(s), informatie over de GBx-applicatie van de bronhouder, die hoort bij het endpoint waarop de notificatie werd ontvangen. | Bronhouder onbekend statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
2 <exit> | Het systeem retourneert een response naar de primaire actor. Let op. Deze stap is gemarkeerd als <exit> stap, maar is vanwege het asynchrone karakter van deze use case niet de laatste stap. | Verwerking succesvol statuscode 200 OK |
3 | Indien de bronhouder Mitz Toestemming Notificaties wil en kan ontvangen: Het systeem bepaalt m.b.v. de geregistreerde conformances in het APR (verkregen in een vorige stap) of een FHIR- of een v3-notificatie moet worden uitgestuurd. De FQDN waarop een notificatie moet worden afgeleverd wordt eveneens verkregen uit het APR. | |
4 | Het systeem verstuurt de notificatie via het bestaande mechanisme voor guaranteed delivery, op de wijze zoals gespecificeerd in
|
Aanvullende eisen
AOF-I.GEN.100.v1 - Gebruik van GZN
De interface wordt aangeboden op AORTA-net, dus via een GZN.
AOF-I.GEN.150.v1 - Gebruik van HTTP
HTTP-requests en -responses op deze interface worden verzonden conform HTTP versie 1.1.
Alle HTTP-verkeer wordt verzonden binnen een TLS verbinding.
AOF-I.GEN.200.v1 - TLS verbindingen
TLS clients en TLS servers dienen tenminste TLS versie 1.2 te ondersteunen en mogen hierbij slechts gebruik maken van algoritmeselecties uit de categorie "Goed", zoals genoemd in bijlage C van de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS).
Bij het opzetten van een verbinding dient gebruik te worden gemaakt van de sterkste algoritmeselectie die door beide partijen wordt ondersteund. TLS clients en TLS servers maken bij voorkeur echter gebruik van een hogere TLS versie dan 1.2.
Binnen TLS verbindingen dienen tijdelijke sleutels te worden toegepast, die elke 5 minuten worden ververst door middel van TLS Secure Renegotiation.
TLS verbindingen worden opgezet middels PKIo servercertificaten of, voor zorgaanbieders, m.b.v. UZI-servercertificaten.
AOF-I.GEN.250.v1 - Systeem Authenticatie (mTLS)
Indien uitwisseling plaatsvindt binnen TLS verbindingen, dan dient op deze interface gebruik te worden gemaakt van tweezijdige authenticatie (mutual TLS, mTLS), waarbij de TLS client en de TLS server zich wederzijds authenticeren.
AOF-I.GEN.400.v1 - FHIR
Op deze interface gelden de generieke eisen uit de MedMij informatiestandaarden. Dit betekent ondermeer dat zowel JSON als XML moet worden ondersteund.