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 systeemrollen en 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, HL7-conformanceregels verbonden, met daarin de volgende gegevens:
interactie-id
ontvangen (ja/nee)
verzenden (ja/nee)
FHIR-interacties worden hierin als volgt opgeslagen:
M.b.v. de velden ontvangen en verzenden wordt bepaald of een request mag worden verzonden danwel ontvangen, en of een response mag worden ontvangen danwel verzonden (geretourneerd).
Het interactie-id heeft 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 altijd geregistreerd in request-response-paren. Om een v3-interactie te mogen initiëren of ontvangen, heeft een GBx-applicatie een conformance nodig voor de request-interactie en een voor de bijbehorend response-interactie. Voor FHIR-interacties wordt altijd gewerkt met één conformance voor een interactie. Wanneer een GBx-applicatie een FHIR-request mag verzenden of ontvangen, dan mag deze applicatie automatisch ook de bijbehorende response ontvangen of retourneren (verzenden).
Medische bouwstenen (bijv. medicatieafspraken) kunnen door een initiërende GBx-applicatie op verschillende manieren worden opgevraagd bij een bronsysteem (reagerende GBx-applicatie):
D.m.v. een bouwsteeninteractie die, via de resource broker, wordt geïniteerd door een GBx-applicatie. Op het moment kan dit slechts via een FHIR-search interactie, en is dit niet mogelijk o.b.v. HL7v3. Om zelf een bouwsteeninteractie te kunnen initiëren heeft een GBx-applicatie voor de betreffende FHIR-interactie een conformance nodig waarbij verzenden op “ja” staat en ontvangen op “nee” staat.
Via een generieke query (HL7v3) of een $get-aorta-data operation (HL7FHIR). Om dit te kunnen doen heeft een initiërende GBx-applicatie, naast de generieke conformance voor de generieke query of $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.
de betreffende v3-request-interactie, waarbij verzenden op “nee” staat en ontvangen op “nee” staat, EN voor de bijbehorende v3-response-interactie, waarbij verzenden op “nee” staat en ontvangen op “ja” staat.
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 | - |