Skip to main content
Skip table of contents

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.

image-20240213-083225.png

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

AOF.UC.ADS.100.v4

Realiseert Feature

getRoutingInfo

Pre-condities

Het systeem is slechts benaderbaar voor

  • GBx-applicaties die zijn aangesloten op het AORTA netwerk, OF

  • componenten van VZVZ die zijn aangesloten via een intern netwerk of op het AORTA netwerk

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 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).

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. 

  • Instance-level interactie: het appID wordt verkregen uit het url attribuut in de interaction (formaat van de url is in deze situatie "<base endpointadres Resource Broker XXX-in>/<appID>/<type>/<id>").

  • Type- of whole system interactie: hierbij wordt gebruik gemaakt van de Applicatie Register Interface van het APR (zie ook de Toelichting "systeemrollen en conformances" en de Toelichting "filtering interacties").

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:

  • voor een interactie geen route kan worden gevonden binnen AORTA, en

  • de beoogde bestemming van een interactie (URA) deze blijkens de registratie in ZORG-AB ook kan ontvangen. NB. omdat ZORG-AB hiervoor niet tijdig geschikt zal zijn, wordt in eerste instantie gewerkt met een interne registratie in het systeem.

  • het AORTA GTK een interactie blijkens de registratie in ZORG-AB namens de initiërende zorgaanbieder ook mag initiëren via Twiin.
    NB. omdat ZORG-AB hiervoor niet tijdig geschikt zal zijn, wordt deze check vooralsnog niet uitgevoerd.

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:

  • datum en tijd van ontvangst

  • request-id

  • initial-request-id

  • sender-id

    • role-id wanneer de sender van het request een VZVZ component is, en de aanroep niet via TLS geschiedt

    • common name wanneer de aanroep via TLS geschiedt

==

Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:

  • datum en tijd van verzending

  • request-id

  • initial-request-id

  • receiver-id

    • role-id wanneer de receiver van het request een VZVZ component is, en de aanroep niet via HTTP geschiedt

    • FQDN wanneer de aanroep via HTTP geschiedt

Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:

  • datum en tijd van response

  • request-id van het bijbehorende request

  • initial-request-id van het bijbehorende request

  • receiver-id

    • role-id wanneer de receiver van de response een VZVZ component is, en de aanroep niet via TLS geschiedt

    • common name wanneer de aanroep via TLS geschiedt

  • HTTP statuscode en eventueel geretourneerde foutinformatie

==

Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:

  • datum en tijd van response

  • request-id van het bijbehorende request

  • initial-request-id van het bijbehorende request

  • sender-id

    • role-id wanneer de sender van de response een VZVZ component is, en de aanroep niet via TLS geschiedt

    • common name wanneer de aanroep via TLS geschiedt

  • HTTP statuscode en eventueel geretourneerde foutinformatie

Toelichting systeemrollen en conformances

ZORG-AB en het APR bevatten gegevens over welke systeemrollen een applicatie ondersteunt. 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 welke FHIR mode bij de systeemrol hoort, d.w.z. client of server.

  • 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”.

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:

  1. Een client vraagt RoutingInfo voor een interactie-id, bijvoorbeeld "search:mp-MedicationAgreement:1".

  2. Een client vraagt RoutingInfo o.b.v. type + fhirProfile + fhirProfileVersion, bijvoorbeeld read +  http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation  + 2.1.3.

  3. Een client vraagt RoutingInfo o.b.v. type + fhirProfile, bijvoorbeeld search +  http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation.

  4. Een AoF 0.7 client vraagt RoutingInfo o.b.v. een interactie-id, bijvoorbeeld “search:Observation:2.1:request”.

  5. 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:

  1. 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.

  2. 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).

  3. 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.

  4. Bij de selectie van de juiste interactie uit een set van interacties die tot eenzelfde groep behoren gelden de volgende eisen:

    1. Niet transformeren heeft de voorkeur boven een nieuwere versie gebruiken.

    2. Exact dezelfde interactie heeft voorkeur boven gebruik van een nieuwere compatible versie.

    3. 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.

  5. 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

-

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close