Skip to main content
Skip table of contents

Interfaces Adressering Server

Routing Info Interface

Feature informatie

Feature

getRoutingInfo

Type

Service

Versie

1.3.2

Systeemrolcode

routing-info:OIS:-:1

Groep

Adressering

Gepubliceerd

Delta

Fix:

Backwards-compatible wijze om onderscheid te maken tussen conformances voor bouwsteeninteracties die zelf door een client worden geïnitieerd, en die via een $get-aorta-data worden geïnitieerd.

Use case

AOF.UC.ADS.100.v5

Feature

Versie

Dependency

Aanbieder

Afnemer

getRoutingInfo

1.3.2

AORTA Stelseltoken

>=*

>=*

getRoutingInfo

1.3.2

AORTA-ID HTTP Header

>=1.0.0

>=1.0.0

getRoutingInfo

1.3.2

Formaat AORTA interactietabel

>=*

-

getRoutingInfo

1.3.2

getTransformatieMetadata

>=*

-

Inhoud en formaat van een getRoutingInfoRequest

Een getRoutingInfoRequest wordt op de volgende wijze verzonden:

POST [base endpointadres]/getRoutingInfo/v1

Totdat AoF 0.7 wordt uitgefaseerd, biedt de Adressering Server tijdelijk ook nog de interface, zoals beschreven in de AoF 0.7 specificaties.

Bij het verzenden van een getRoutingInfoRequest dienen de volgende HTTP headers te worden meegezonden:

Feature

AORTA-ID HTTP Header

Type

Subfeature

Versie

1.0.0

Systeemrolcode

-

Groep

HTTP Headers

Gepubliceerd

Delta

Initiële versie van feature.

AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>

Het initialRequestID attribuut bevat het ID van het allereerste request in de hele keten en dient te worden opgenomen in de logbestanden van alle partijen in de keten, zodat bij foutopsporing de verschillende logbestanden aan elkaar kunnen worden gerelateerd.

Het requestID is voor iedere request message uniek. In requests wordt deze gegenereerd door de client. Ook het requestID dient te worden opgenomen in de verschillende logbestanden, zodat altijd duidelijk is op welk bericht een log entry van toepassing is.

Content-Type: application/json; charset=utf-8

Het technische formaat van de HTTP body van een getRoutingInfo request is:

JSON
{
    "destination": {
        "code": "",
        "codeSystem": ""
    },
    "interaction": [{
        "id": "",
        "type": "",
        "mode": "",
        "fhirProfile": "",
        "fhirProfileVersion": ""
    }],
    "client ": {
        "code": "",
        "codeSystem": ""
    }
}

Input parameters:

Name

Cardinality

Type

Toelichting

destination

0..1

Object met attributen

Beoogde bestemming van de interactie.

Vereist wanneer één van de ingestuurde interactions géén url  attribuut bevat met daarin een appID.

Wordt genegeerd wanneer alle ingestuurde interactions een url  attribuut bevatten met daarin een appID.

Wanneer één ingestuurde interaction een url attribuut bevat met een appID en een andere ingestuurde interaction wordt uitgedrukt middels een id attribuut, dan wordt de destination slechts gebruikt voor de interaction met het id attribuut. Voor de interaction met het url attribuut wordt dan de appID uit het url attribuut gebruikt.

destination.code

1..1

String

Beoogde bestemming van de interactie.

Mogelijke waarden:

  • <appID>

  • <URA>

destination.codeSystem

1..1

String

Het gehanteerde codesysteem.

Mogelijke waarden: 

  • "urn:oid:2.16.840.1.113883.2.4.6.6" (appID)

  • "urn:oid:2.16.528.1.1007.3.3" (URA)

interaction

1..n

Object met attributen

Structuur waaruit het interactie-id van ieder te adresseren bericht kan worden bepaald.

Een interactie dient op één van de volgende methoden te worden doorgegeven:

  1. id (bijv. search:zib-LivingSituation:2)

  2. type + fhirProfile + fhirProfileVersion (bijv. read +  http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation + 2.1.3)

  3. type + fhirProfile (bijv. search +  http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation )

interaction.id

0..1

String

Interactie-id van het te adresseren bericht, of van de te adresseren berichten.

Het versie-deel in het id attribuut wordt gespecificeerd a.d.h.v. aan major versienummer conform semver, dus bijvoorbeeld "1", "*" of "x". Hiermee is de compatibiliteit afdoende geborgd.

interaction.type

0.1

String met waarde create | read | update | delete | search | batch | transaction

Het (restful FHIR) interactie type.

interaction.mode

0..1

String

Dit attribuut geeft aan of de client de interactie zelf wil initiëren (“initiate”), of dat de resource broker de interactie, bijv. als gevolg van een $get-aorta-data, initieert namens te client (“trigger”).

Indien het attribuut wordt weggelaten, dan is de veronderstelde waarde “initiate”.

Mogelijke waarden:

  • “initiate”

  • “trigger”

interaction.fhirProfile

0..1

String

De canonical van het gehanteerde FHIR profiel, bijv. "http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation ".

interaction.fhirProfileVersion

0..1

String

De versie van het gehanteerde FHIR profiel.

Het attribuut wordt gespecificeerd conform semver, dus bijvoorbeeld "1.0.0" of "2.x". De Adressering Server houdt bij het zoeken naar applicaties slechts rekening met het major nummer, omdat compatibiliteit hierdoor afdoende is geborgd.

client

0..1

Object met attributen

Beoogde client voor de interactie.

Indien aanwezig dan kan deze als volgt zijn gevuld:

  • role-id van Resource Broker MedMij-in (deze fungeert binnen AORTA als client namens een PGO)

  • app-id van een GBx-applicatie (interactie is geïnitieerd of wordt getriggerd door een GBx-applicatie)

client.code

1..1

String

Beoogde client voor de interactie.

Mogelijke waarden:

  • <appID>

  • <role-id>

client.codeSystem

1..1

String

Het gehanteerde codesysteem.

Mogelijke waarden: 

  • "urn:oid:2.16.840.1.113883.2.4.6.6" (appID)

  • "urn:oid:2.16.840.1.113883.2.4.3.111.8" (role-id)

Inhoud en formaat van een getRoutingInfoResponse

Bij het verzenden van een getRoutingInfoResponse dienen de volgende HTTP headers te worden meegezonden:

Content-Type: application/json; charset=utf-8

Het technische formaat van de HTTP body van een getRoutingInfoResponse is:

JSON
[{
    "interactionId": "",
    "destinationInfo": [{
        "destination": {
            "code": "",
            "codeSystem": ""
        },
        "fqdn": "",
        "transformationId": "",
        "aortaATversion": ""
    }]
}]

Output bestaat uit 0..n JSON objecten die, voor elk van de ontvangen interactions, de volgende inhoud bevatten. Deze objecten worden geretourneerd in de volgorde waarin de betreffende interactions werden ontvangen in het getRoutingInfo request.

Name

Cardinality

Type

Toelichting

interactionId

1..1

String

Interactie-id van het te adresseren bericht, of van de te adresseren berichten.

Wordt gevuld met de interactie, indien mogelijk inclusief het  exacte versienummer, waarmee de flow dient te worden vervolgd. Ook indien een transformatie is vereist.

destinationInfo

0..n

Object met attributen

Slechts aanwezig indien tenminste één geschikte GBx-applicatie is gevonden, en de interactie ook mag worden geïnitieerd.

destinationInfo.destination

1..1

Object met attributen

Beoogde bestemming van de interactie.

destination.code

1..1

String

Beoogde bestemming van de interactie.

Mogelijke waarden:

  • <appID>

destination.codeSystem

1..1

String

Het gehanteerde codesysteem.

Mogelijke waarden: 

  • "urn:oid:2.16.840.1.113883.2.4.6.6" (appID)

destinationInfo.fqdn

1..1

String

FQDN van de GBx-applicatie.

destinationInfo.transformationId

0..1

String

Het ID van het uit te voeren transformatie algoritme.

Slechts aanwezig indien de applicatie die het request moet beantwoorden, vereist dat eerst een transformatie wordt uitgevoerd.

Wordt nooit gevuld wanneer de interactie een FHIR-operation is.

destinationInfo.aortaATversion

0..1

String

De hoogste versie van het AORTA access_token die wordt ondersteund door de beoogde bestemming van de interactie.

Afwezig indien de bestemming geen AORTA access_tokens kan verwerken.

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.

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:

  • 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 (zie: “Specificaties gebruik ZORG-AB”).
    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 (zie: “Specificaties gebruik ZORG-AB”).
    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

Aanvullende eisen

AOF-I.GEN.110.v1 - Gebruik van veilig intern netwerk

De interface wordt aangeboden op een beveiligd besloten netwerk dat ter beschikking staat voor communicatie tussen componenten onderling, en tussen componenten en de ZIM.

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.450.v1 - Verkrijgen base-URL van component

Deze interface wordt geboden door een component die is opgenomen in het AORTA Stelseltoken. In de specificaties is aangegeven welke component het betreft.

Wanneer deze interface wordt gebruikt via HTTP, dan mag deze slechts worden gericht aan de base-URL van een server/component die deze rol blijkens het AORTA Stelseltoken vervuld.

Het geldende AORTA Stelseltoken dient periodiek te worden opgehaald via de AORTA Stelsel Metadata Interface. De aangeven caching directives dienen hierbij te worden gevolgd.

Voorbeelden van gebruik Routing Info Interface

Interactie vanuit MedMij

Het technische formaat van een getRoutingInfo request is:

CODE
POST [base endpointadres]/getRoutingInfo/v1

{
    "destination": {
        "code": "382",
        "codeSystem": "urn:oid:2.16.528.1.1007.3.3"
    },
    "interaction": [{
        "id": "create:zib-BloodPressure:3"
    }]
}

Het technische formaat van een getRoutingInfo  response is:

CODE
200 OK

[{
    "interactionId": "create:zib-BloodPressure:3",
    "destinationInfo": [{
        "destination": {
            "code": "5476",
            "codeSystem": "urn:oid:2.16.840.1.113883.2.4.6.6"
        },
        "fqdn": "bron.zorgaanbieder.nl",
        "transformationId": "1"
    }]
}]

In bovenstaande situatie is transformatie #1 vereist om de gevraagde FHIR-interactie af te kunnen leveren bij GBZ-applicatie #5476.

Initiatie vanuit GBx-client

Het technische formaat van een getRoutingInfo request is:

CODE
POST [base endpointadres]/getRoutingInfo/v1

{
    "destination": {
        "code": "592",
        "codeSystem": "urn:oid:2.16.528.1.1007.3.3"
    },
    "interaction": [{
        "type": "read",
        "fhirProfile": "http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement",
        "fhirProfileVersion": "1.0"
    }, {
            "type": "read",
        "fhirProfile": "http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement",
        "fhirProfileVersion": "2.0"
    }, {
        "id": "search:eAfspraak-Appointment:2"
    }]
}

Het technische formaat van een getRoutingInfo  response is:

CODE
200 OK

[{
    "interactionId": "read:mp-MedicationAgreement:1",
    "destinationInfo": [{
        "destination": {
            "code": "3287",
            "codeSystem": "urn:oid:2.16.840.1.113883.2.4.6.6"
        },
        "fqdn": "bron-1.zorgaanbieder.nl",
        "aortaATversion": "2.0"
    }]
}, {
    "interactionId": "read:mp-MedicationAgreement:2"
}, {
    "interactionId": "search:eAfspraak-Appointment:2",
    "destinationInfo": [{
        "destination": {
            "code": "3288",
            "codeSystem": "urn:oid:2.16.840.1.113883.2.4.6.6"
        },
        "fqdn": "bron-2.zorgaanbieder.nl",
        "transformationId": "3"
    }]
}]

In bovenstaande situatie is transformatie #3 vereist om de gevraagde Appointment interactie af te kunnen leveren bij GBZ-applicatie #3288. Er is géén transformatie vereist om de gevraagde MedicationRequest interactie af te kunnen leveren bij GBZ-applicatie #3287.

Aanroep vanuit Autorisatie Server ZA

Het technische formaat van een getRoutingInfo request is:

CODE
POST [base endpointadres]/getRoutingInfo/v1

{
    "destination": {
        "code": "3287",
        "codeSystem": "urn:oid:2.16.840.1.113883.2.4.6.6"
    },
    "interaction": [{
        "id": "search:mp-MedicationAgreement:1"
    }, {
        "id": "search:mp-MedicationAgreement:2"
    }],
    "client ": {
        "code": "205",
        "codeSystem": "urn:oid:2.16.840.1.113883.2.4.6.6"
    }
}

Stel dat de client in deze situatie versie 1.1 van de gevraagde interactie ondersteunt, dan wordt, omdat eenzelfde major nummer voldoende is, het technische formaat van de bijbehorende getRoutingInfo response:

CODE
200 OK

[{
    "interactionId": "search:mp-MedicationAgreement:1",
    "destinationInfo": [{
        "destination": {
            "code": "3287",
            "codeSystem": "urn:oid:2.16.840.1.113883.2.4.6.6"
        },
        "fqdn": "bron-1.zorgaanbieder.nl",
        "aortaATversion": "1.0"
    }]
}]

In bovenstaande situatie is géén transformatie vereist om de gevraagde MedicationRequest interactie af te kunnen leveren bij GBZ-applicatie #3287.

JavaScript errors detected

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

If this problem persists, please contact our support.