Use Cases Adressering Server
Overzicht Adressering Server
Onderstaande figuur toont een overzicht van de interfaces, services en functies van de Adressering Server. De Adressering Server helpt bij het bepalen welke interacties en versies, uit een beoogde set, kunnen worden geïnitieerd bij een bepaalde Resource Server. De Adressering Server houdt hierbij ook rekening met transformaties tussen informatiestandaarden die eventueel op het pad tussen Resource Client en Resource Server zouden kunnen worden uitgevoerd.
De services zijn toegankelijk via een geboden interface en worden beschreven in de vorm van use cases. Een service wordt altijd vervult middels één of meerdere applicatiefuncties, bijvoorbeeld "Adressering".
Bepaal route
Primaire actor | Resource Client, RB MedMij-in, Autorisatie Server ZA |
|---|---|
Systeem | Adressering |
Secundaire actor | Resource Broker APR, Transformatie Server, ZORG-AB |
Code | |
Realiseert Feature |
Pre-condities
Het systeem is slechts benaderbaar voor
|
Het systeem beschikt over up-to-date gegevens betreffende de door RB MedMij-in ondersteunde MedMij gegevensdiensten, en de daarbinnen gehanteerde AORTA interactie-id's. |
Het systeem beschikt over een voldoende actueel AORTA Stelseltoken die het via de AORTA Stelsel Metadata Interface heeft verkregen. |
Het systeem beschikt over up-to-date gegevens betreffende de ondersteunde interacties en compatible interacties. |
Het systeem beschikt over up-to-date gegevens betreffende de ondersteunde transformaties (transformatie server metadata), die het heeft verkregen via Feature getTransformatieMetadata. De base-URL van de Transformatie Server is verkregen uit het AORTA Stelseltoken. |
Het systeem beschikt over up-to-date gegevens betreffende ondersteunde scopes van externe GTK’s. |
Triggers
De primaire actor stuurt een routing info request in
Main flow
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. | ||
Stap | Omschrijving | Uitkomst |
|---|---|---|
1 | Het systeem toetst of het verzoek voldoet aan de interface specificatie. | Ongeldig verzoek statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
2 | Het systeem stelt vast voor welke interactie-id('s) routing info wordt gevraagd. NB. interacties van het type transaction of batch, worden hierin vooralsnog niet uitgesplitst in de individuele interacties die deel uitmaken van de batch/transaction. | Interactie-id kan niet worden bepaald (of is onjuist) statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
3 | Het systeem stelt, m.b.v. de transformatie server metadata, vast welk van de gevraagde interactie-id('s) eventueel m.b.t. transformatie kunnen worden uitgevoerd, en bepaalt naar welke interactie-id's dan zou worden getransformeerd. | |
4 | Het systeem stelt voor iedere gevraagde interactie-id vast, naar welke actieve GBx-applicatie(s) (appID) binnen de aangegeven destination, de betreffende interactie, zo nodig na transformatie, kan worden verzonden.
In de rol van Resource Server, verschijnt Resource Broker GTK hierbij als een reguliere GBx-applicatie (Resource Server). RB GTK heeft één appID, en kan interacties opzetten met alle, op Twiin aangesloten, externe GTK’s. RB GTK wordt als Resource Server slechts betrokken in het routeringsalgoritme indien:
| Destination niet gevonden statuscode 404 Not Found |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
Client niet gevonden statuscode 404 Not Found | ||
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
5 | Het systeem stelt voor iedere gevonden GBZ-applicatie, op basis van de systeemrollen in het APR, vast of de betreffende applicatie AORTA access_tokens kan verwerken, en zo ja wat de hoogste versie is die wordt ondersteund. | |
6 <exit> | Het systeem retourneert een response naar de primaire actor. | Verwerking succesvol statuscode 200 OK |
Post-condities
Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd. |
Het systeem heeft van het ontvangen request, de volgende attributen gelogd:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
|
Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
|
Toelichting conformances
Het APR bevat gegevens over welke systeemrollen een applicatie ondersteunt. Deze APR-gegevens zijn ook opvraagbaar via ZORG-AB.
Aan een systeemrol zijn, indien van toepassing, conformanceregels verbonden, met daarin de volgende gegevens:
interactie-id
ontvangen (ja/nee)
verzenden (ja/nee)
Het interactie-id heeft voor FHIR-interacties de volgende structuur:
<basis interactietype>:<FHIR-profiel>:<major FHIR profiel versie>, bijv. "search:mp-MedicationAgreement:1", OF
operation:<operation name>:<major operation versie>, bijv. "operation:$get-aorta-data:1".Voor oude interactie-id’s (<= AoF 0.7) geldt: de FHIR code (bijvoorbeeld "search" of "read"), het FHIR resourcetype (bijvoorbeeld "Observation") en interactieversie (bijvoorbeeld "1.0.x") worden tezamen opgevat als een interactie-id, en wel in het formaat "<code>:<resourcetype>:<versie>:<request/response>". Voorbeeld: “search:Observation:2.1:request”.
HL7v3-interacties worden in het APR altijd geregistreerd in request-response-paren. Voor FHIR-interacties wordt altijd gewerkt met één conformance voor een interactie, namelijk degene voor een request-interactie. Bijvoorbeeld, wanneer een GBx-applicatie een FHIR-request mag verzenden, dan mag deze applicatie altijd ook de bijbehorende response ontvangen. Wanneer een GBx-applicatie een FHIR-request mag ontvangen, dan mag ook de bijbehorende response worden geretourneerd (verzonden).
Om een v3-interactie te mogen initiëren (initiate=yes) en de bijbehorende response te mogen ontvangen heeft een GBx-applicatie een conformance nodig voor de request-interactie en één voor de bijbehorend response-interactie:
Initiëren van een request - verzenden “ja”.
Ontvangen van bijbehorende response - ontvangen “ja”.
Om een medische bouwsteen via een generieke query (HL7v3) te kunnen opvragen (trigger=yes), heeft een initiërende GBx-applicatie, naast conformances voor de generieke query, conformances nodig voor:
De betreffende v3-request-interactie, waarbij verzenden op “nee” staat en ontvangen op “nee” staat, EN voor de bijbehorende v3-response-interactie, waarbij ontvangen op “ja” staat (het laatste wordt geborgd door het TKID-proces).
Om een v3-interactie te mogen ontvangen (process=yes) en de bijbehorende response te mogen retourneren heeft een GBx-applicatie een conformance nodig voor de request-interactie en één voor de bijbehorend response-interactie:
Ontvangen van een request - ontvangen “ja”.
Retourneren van bijbehorende response - verzenden “ja”.
In het TKID-proces wordt geborgd dat een v3-systeem altijd beschikt over benodigde conformances voor de responses, doordat request-response paren zijn opgenomen in eenzelfde systeemrol.
Om een FHIR-interactie te mogen initiëren (initiate=yes) en de bijbehorende response te mogen ontvangen heeft een GBx-applicatie, zoals gezegd, slechts een conformance nodig voor de request-interactie:
Initiëren van een request inclusief ontvangen van bijbehorende response - verzenden “ja”.
Om een medische bouwsteen via een $get-aorta-data operation (HL7FHIR) te kunnen opvragen (trigger=yes), heeft een initiërende GBx-applicatie, naast een conformance voor de $get-aorta-data, een conformance nodig voor:
de betreffende FHIR-interactie, waarbij verzenden op “ja” OF op “nee” staat en waarbij ontvangen op “nee” staat.
Om een FHIR-interactie te mogen ontvangen (process=yes) en de bijbehorende response te mogen retourneren heeft een GBx-applicatie een conformance nodig voor de request-interactie:
Ontvangen van een request inclusief retourneren van bijbehorende response - ontvangen “ja”.
Additionele toetsen
Het systeem toetst altijd ook of een destination (appID) in staat is om interacties te verwerken ten behoeve van MedMij, danwel ten behoeve van zorgaanbieder-zorgaanbieder uitwisseling. Dit wordt gedaan middels specifieke systeemrollen in het APR:
DVZA.BES* voor MedMij uitwisseling.
GBZ.BES* voor zorgaanbieder-zorgaanbieder uitwisseling.
NB. aangezien v3-systemen allemaal verkeer moeten ontvangen van GBZ'en, maar de systeemrol GBZ.BES* nog niet hebben gekoppeld, is het noodzakelijk dat de Adressering Server er vooralsnog vanuit gaat dat, wanneer een v3-interactie zal worden uitgestuurd, het betreffende systeem altijd open staat voor ontvangst van zorgaanbieder-zorgaanbieder verkeer.
Een routing info request heeft betrekking op zorgaanbieder-zorgaanbieder uitwisseling wanneer deze wordt ingestuurd door Autorisatie Server ZA, of door een GBx-applicatie.
Een routing info request heeft betrekking op MedMij uitwisseling wanneer deze wordt ingestuurd door Resource Broker MedMij-in.
Toelichting filtering interacties
Ondersteunde situaties:
Een client vraagt RoutingInfo voor een interactie-id, bijvoorbeeld "search:mp-MedicationAgreement:1".
Een client vraagt RoutingInfo o.b.v. type + fhirProfile + fhirProfileVersion, bijvoorbeeld read + http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation + 2.1.3.
Een client vraagt RoutingInfo o.b.v. type + fhirProfile, bijvoorbeeld search + http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation.
Een AoF 0.7 client vraagt RoutingInfo o.b.v. een interactie-id, bijvoorbeeld “search:Observation:2.1:request”.
Een AoF 0.7 client vraagt RoutingInfo o.b.v. method + url + aortaVersion (bijv. GET + Observation/127328348 + 2.1, nodig voor instance-level interacties)
Eisen aan het algoritme:
Indien de client, blijkens het APR, een interactie niet ondersteunt, dan wordt voor deze nooit destinationInfo opgenomen in de getRoutingInfoResponse. De client mag deze interactie immers niet initiëren.
Indien een client RoutingInfo vraagt voor meerdere interacties, die functioneel equivalent zijn aan elkaar, dan wordt hiervan, per destination (appID), voor maximaal één interactie destinationInfo opgenomen in de getRoutingInfoResponse (dataminimalisatie).
Voor een interactie wordt, bij een specifieke destination (appID), slechts destinationInfo opgenomen in de getRoutingInfoResponse wanneer de betreffende GBx-applicatie deze interactie, of een compatible versie ervan, of een transformeerbare versie ervan blijkens het APR ondersteund.
Bij de selectie van de juiste interactie uit een set van interacties die tot eenzelfde groep behoren gelden de volgende eisen:
Niet transformeren heeft de voorkeur boven een nieuwere versie gebruiken.
Exact dezelfde interactie heeft voorkeur boven gebruik van een nieuwere compatible versie.
Nieuwe versie gaat voor een oudere versie. Let op: interacties binnen eenzelfde protocol kunnen functioneel equivalent zijn, maar een totaal ander interactie-id hanteren. In deze situaties kan de nieuwste versie worden bepaald a.d.h.v. een preference attribuut in de AORTA interactietabel.
Client-specifieke filtering en selectie van interacties wordt slechts gedaan wanneer een appID is ontvangen van de client.
Wanneer in één request RoutingInfo wordt gevraagd voor meer dan één destination, dan wordt bovenstaand algoritme uitgevoerd voor iedere gevonden destination (appID), waardoor eenzelfde interactie, door de client, dus mogelijk kan worden geïniteerd bij meerdere applicaties van eenzelfde zorgaanbieder.
Toelichting registratie GTK’s in ZORG-AB
In ZORG-AB wordt, t.b.v. Twiin, voor iedere zorgaanbieder die deelneemt aan Twiin ondermeer vastgelegd:
de URA van de zorgaanbieder
de scopes waarvoor de betreffende zorgaanbieder is gekwalificeerd.
de exacte inhoud van een scope dient binnen Twiin nog te worden uitgewerkt.
voor nu wordt daarom, in een interne registratie, gewerkt met scopes die gelijk zijn aan de conformances, zoals worden gehanteerd in het APR.
Voorbeeld werking routeringsalgoritme
Inhoud van de interactietabel:
interactieId | Preference | Protocol | groupId |
|---|---|---|---|
create:vitalsign-bloodglucose:1 | 2 | application/fhir | create:LaboratoryTestResult:1 |
create:vitalsign-bloodglucose:2 | 1 | ||
ZTZM_IN000004NL01 | 1 | application/hl7-v3 | |
search:mp-MedicationAgreement:1 | 1 | application/fhir | search:MediationAgreement:1 |
QUMA_IN991201NL04 | 1 | application/hl7-v3 | |
search:mp-VariableDosingRegimen:1 | 1 | application/fhir | search:VariableDosingRegimen:1 |
QUDS_IN000001NL01 | 1 | application/hl7-v3 | |
search:mp612-DispenseToFHIRConversion-AdministrationAgreement:1 | 3 | application/fhir | search:AdministrationAgreement |
search:mp-AdministrationAgreement:1 | 1 | application/fhir | |
search:zib-AdministrationAgreement:2 | 2 | application/fhir | |
QURX_IN990111NL | 2 | application/hl7-v3 | |
QUTA_IN991211NL02 | 1 | application/hl7-v3 |
Interacties delen eenzelfde groupId wanneer ze functioneel equivalent zijn. Verschillende interacties zijn technisch, per definitie, niet gelijk aan elkaar.
Functioneel equivalente interacties kunnen al dan niet transformeerbaar zijn naar elkaar. Ondersteunde transformaties worden vastgelegd in de Transformatie Server metadata.
Inhoud van de Transformatie Server metadata:
Transformatie Algoritme ID | Input | Output | ||||
Type | Protocol | Interactie-ID | Type | Protocol | Interactie-ID | |
|---|---|---|---|---|---|---|
1.1 | request | application/fhir+xml, application/fhir+json | create:vitalsign-bloodglucose:1 | request | application/hl7-v3+xml | ZTZM_IN000004NL01 |
1.2 | request | application/fhir+xml, application/fhir+json | create:vitalsign-bloodglucose:2 | request | application/fhir+xml, application/fhir+json | create:vitalsign-bloodglucose:1 |
2.1 | request | application/fhir+xml, application/fhir+json | search:mp-MedicationAgreement:1 | request | application/hl7-v3+xml | QUMA_IN991201NL04 |
2.2 | response | application/hl7-v3+xml | QUMA_IN991203NL04 | response | application/fhir+xml, application/fhir+json | search:mp-MedicationAgreement:1 |
3.3 | request | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 | request | application/hl7-v3+xml | QUTA_IN991211NL02 |
3.4 | response | application/hl7-v3+xml | QUTA_IN991213NL02 | response | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 |
3.5 | request | application/hl7-v3+xml | QUTA_IN991211NL02 | request | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 |
3.6 | response | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 | response | application/hl7-v3+xml | QUTA_IN991213NL02 |
request (oorspronkelijk request) | application/hl7-v3+xml | QUTA_IN991211NL02 | ||||
3.7 | request | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 | request | application/hl7-v3+xml | QURX_IN990111NL |
3.8 | response | application/hl7-v3+xml | QURX_IN990113NL | response | application/fhir+xml, application/fhir+json | search:mp-AdministrationAgreement:1 |
Betreffende interactie, zoals benoemd in de input, kan, na de genoemde transformatie, worden geïnitieerd bij een server die de interactie, zoals benoemd in de output, ondersteund.
Inhoud van het APR:
Applicatie | Conformances (send + receive) |
|---|---|
1 | create:vitalsign-bloodglucose:1 |
2 | create:vitalsign-bloodglucose:2 |
3 | ZTZM_IN000004NL01 |
4 | search:mp-MedicationAgreement:1 search:mp-VariableDosingRegimen:1 |
5 | QUMA_IN991201NL04 QUMA_IN991203NL04 |
6 | QUDS_IN000001NL01 QUDS_IN000003NL01 |
7 | search:mp-AdministrationAgreement:1 search:zib-AdministrationAgreement:2 |
8 | QURX_IN990111NL QUTA_IN991211NL02 |
9 | search:zib-AdministrationAgreement:2 QUTA_IN991211NL02 |
Inhoud van getRoutingInfoRequest en getRoutingInfoResponse:
getRoutingInfoRequest | getRoutingInfoResponse | ||||
|---|---|---|---|---|---|
Client | Destination | Interactions | Destination | Interaction | Transformation |
1 | 2, 3 | create:vitalsign-bloodglucose:1 | 3 | create:vitalsign-bloodglucose:1 | 1.1 |
2 | 1, 3 | create:vitalsign-bloodglucose:2 | 1 | create:vitalsign-bloodglucose:2 | 1.2 |
3 | 1, 2 | ZTZM_IN000004NL01 | - | - | - |
4 | 5, 6 | search:mp-MedicationAgreement:1 search:mp-VariableDosingRegimen:1 | 5 | search:mp-MedicationAgreement:1 | 2.1 |
Onbekend | 2, 3 | create:vitalsign-bloodglucose:1 create:vitalsign-bloodglucose:2 | 2 | create:vitalsign-bloodglucose:2 | - |
3 | create:vitalsign-bloodglucose:1 | 1.1 | |||
7 | 8 | search:zib-AdministrationAgreement:2 | - | - | - |
7 | 8 | search:mp-AdministrationAgreement:1 | 8 | search:mp-AdministrationAgreement:1 | 3.3 |
7 | 9 | search:mp-AdministrationAgreement:1 search:zib-AdministrationAgreement:2 | 9 | search:zib-AdministrationAgreement:2 | - |