Interfaces Adressering Server
Adressering Interface
getRoutingInfo
Feature informatie
Feature | |
|---|---|
Type | Service |
Versie | 1.6.0 |
Systeemrolcode | routing-info:OIS:-:1 |
Groep | Adressering |
Gepubliceerd |
|
Delta | Tijdelijke work-around voor Twiin cancel-notification. De legacy feature samengevoegd met de actuele feature. Ready for review. Versie verhoogd van 1.5.0 naar 1.6.0 |
Use case |
Feature | Versie | Dependency | Aanbieder | Afnemer |
|---|---|---|---|---|
1.6.0 | >=* | >=* | ||
1.6.0 | AORTA-ID HTTP Header | >=1.0.0 | >=1.0.0 | |
1.6.0 | >=* | - | ||
1.6.0 | >=* | - |
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 legacy interface, zoals beschreven in de AoF 0.7 specificaties.
Een legacy getRoutingInfoRequest wordt op de volgende wijze verzonden:
POST [base endpointadres]/getRoutingInfo
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 getRoutingInfoRequest is:
{
"destination": {
"code": "",
"codeSystem": ""
},
"interaction": [{
"id": "",
"type": "",
"mode": "",
"fhirProfile": "",
"fhirProfileVersion": ""
}],
"client": {
"code": "",
"codeSystem": ""
}
}
Het technische formaat van de HTTP body van een legacy getRoutingInfoRequest is:
{
"destination": {
"code": "",
"codeSystem": ""
},
"interaction": [{
"id": "",
"method": "",
"url": "",
"aortaVersion": ""
}],
"client": {
"code": "",
"codeSystem": ""
}
}
Name | Cardinality | Type | Toelichting |
| 0..1 | Object met attributen | Beoogde bestemming van de interactie. Vereist wanneer er geen ontvangen
Wanneer één ontvangen |
| 1..1 | String | Beoogde bestemming van de interactie. Mogelijke waarden:
|
| 1..1 | String | Het gehanteerde codesysteem. Mogelijke waarden:
|
| 1..n | Object met attributen | Structuur waaruit het interactie-id van ieder te adresseren interactie kan worden bepaald. Een
Bij gebruik van één van de bovenstaande bepalingswijze is de cardinaliteit van de hierboven genoemde attributen verplicht (1..1) en alle andere attributen moeten niet aanwezig zijn (0..0). |
| 0..1 | String | Ontvangen interactie-id van het te adresseren bericht. Indien het Vereist voor Het versie-deel in het |
| 0..1 | String | De gebruikte HTTP method. Vereist voor Moet worden gevuld met waarde “GET”, “POST”, “PUT” of “DELETE” |
| 0..1 | String | De gebruikte URL, inclusief eventuele (zoek)parameters. Vereist voor Toegestane formaten zijn:
De waarde van een eventueel meegezonden [base] deel van de URL wordt genegeerd. Bij search interacties kunnen optioneel parameters worden opgenomen in de URL. Deze parameters worden eveneens genegeerd, omdat ze niet van belang zijn voor de juiste bepaling van het interactie-id. |
| 0..1 | String | De gebruikte AORTA versie van de interactie. Vereist voor Het |
| 0..1 | String | Het (restful FHIR) interactie type. Vereist voor Moet worden gevuld met waarde “create”, “read”, “update”, “delete”, “search”, “batch” of “transaction“. De waarden “batch” en “transaction” zijn uitsluitend van toepassing op bundle‑gebaseerde interacties en niet op resource‑specifieke instance‑level interacties. |
| 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”. Moet worden gevuld met waarde “initiate” of “trigger”. |
| 0..1 | String | De canonical van het gehanteerde FHIR profiel, bijv. "http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation". Vereist voor |
| 0..1 | String | De versie van het gehanteerde FHIR profiel. Vereist voor Het |
| 0..1 | Object met attributen | Client die de interactie initieerde. Indien aanwezig dan kan deze als volgt zijn gevuld:
Afwezig wanneer er een ontvangen |
| 1..1 | String | Client die de interactie initieerde. Mogelijke waarden:
|
| 1..1 | String | Het gehanteerde codesysteem. Mogelijke waarden:
|
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:
[{
"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 uitvoerbare (het adresseren) bericht. Wordt gevuld met de interactie, indien mogelijk inclusief het exacte versienummer, waarmee de flow dient te worden vervolgd. Ook indien een transformatie is vereist. Merk op, dit kan een actuele (> AoF 0.7) interactie-id, of legacy (=< AoF 0.7) interactie-id bevatten. (Legacy) |
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:
|
destination.codeSystem | 1..1 | String | Het gehanteerde codesysteem. Mogelijke waarden:
|
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. Indien een transformatie vereist is naar een v3 bouwsteenquery, dan moet dit attribuut tenminste AORTA access_token versie 3 bevatten zodat de RB VnC de juiste queries kan opbouwen. Afwezig indien de bestemming geen AORTA access_tokens kan verwerken, en ook geen transformatie naar een v3 bouwsteenquery is vereist. Afwezig indien de ontvangen getRoutingInfoRequest volgens de legacy interface was (Legacy) |
Voorbeelden van gebruik getRoutingInfo
Interactie vanuit MedMij
Het technische formaat van een getRoutingInfoRequest is:
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 getRoutingInfoResponse is:
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 getRoutingInfoRequest is:
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 getRoutingInfoResponse is:
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.
Legacy initiatie vanuit GBx-client
Het technische formaat van een getRoutingInfo request is:
POST [base endpointadres]/getRoutingInfo
{
"destination": {
"code": "592",
"codeSystem": "urn:oid:2.16.528.1.1007.3.3"
},
"interaction": [{
"method": "GET",
"url": "3287/MedicationRequest/23483147812",
"aortaVersion": "1.0"
}, {
"method": "GET",
"url": "4001/MedicationRequest/23483147813",
"aortaVersion": "2.0"
}, {
"id": "search:Appointment:1.0:request"
}]
}
Het technische formaat van een getRoutingInfo response is:
200 OK
Content-Type: application/json; charset=utf-8
[{
"interactionId": "read:MedicationRequest:1.0:request",
"destinationInfo": [{
"destination": {
"code": "3287",
"codeSystem": "urn:oid:2.16.840.1.113883.2.4.6.6"
},
"fqdn": "bron-1.zorgaanbieder.nl"
}]
}, {
"interactionId": "read:MedicationRequest:2.0:request"
}, {
"interactionId": "search:Appointment:1.0:request",
"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 getRoutingInfoRequest is:
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 getRoutingInfoResponse:
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.
HTTP Status Codes
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 het verzoek voor welke interactie-id('s) routing info wordt gevraagd. Zie de Toelichting bepalen ontvangen interactie-id(s) NB. interacties van het type transaction of batch, worden hierin vooralsnog niet uitgesplitst in de individuele interacties die deel uitmaken van de batch/transaction. Tijdelijke work-around (nodig tot GBZ-applicaties cancelation van notificaties gaan ondersteunen). Indien de uitvoerbare interactie een “update:twiin-TaskNotifiedPull:1” interactie betreft, dan behandelt het systeem deze als “create:twiin-TaskNotifiedPull:1“. In de response (exit stap) wordt als interactie-id echter wel opgenomen “update:twiin-TaskNotifiedPull:1“. | Interactie-id kan niet worden bepaald (komt niet voor in de AORTA interactietabel en/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 vast voor voor het verzoek welke beoogde doel systeem(en) routing info wordt gevraagd. Zie de Toelichting bepalen beoogde destination(s). | Destination kan niet worden bepaald statuscode 400 Bad Request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
4 | Het systeem stelt de routeringsinformatie vast m.b.v. het routeringsalgoritme. Als input voor het routeringsalgoritme wordt het interactie-id(s) en beoogde doelsystem(en) gebruikt. Zie de Beschrijving routeringsalgoritme. | Destination niet gevonden statuscode 404 Not Found |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
5 <exit> | Het systeem retourneert een response naar de primaire actor. | Verwerking succesvol statuscode 200 OK |
getInteractionInfo
Feature informatie
Feature | |
|---|---|
Type | Service |
Versie | 1.0.0 |
Systeemrolcode | interaction-info.OIS.-.1 |
Groep | Adressering |
Gepubliceerd |
|
Delta | Initiële versie. |
Use case |
Feature | Versie | Dependency | Aanbieder | Afnemer |
|---|---|---|---|---|
1.0.0 | >=* | >=* | ||
1.0.0 | AORTA-ID HTTP Header | >=1.0.0 | >=1.0.0 | |
1.0.0 | >=* | - | ||
1.0.0 | >=* | - |
Inhoud en formaat van een getInteractionInfoRequest
Een getInteractionInfoRequest wordt op de volgende wijze verzonden:
POST [base endpointadres]/getInteractionInfo/v1
Bij het verzenden van een getInteractionInfoRequest 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 getInteractionInfoRequest is:
{
"interaction": [{
"id": "",
"type": "",
"mode": "",
"fhirProfile": "",
"fhirProfileVersion": ""
}]
}
Name | Cardinality | Type | Toelichting |
interaction | 1..n | Object met attributen | Structuur waaruit het interactie-id kan worden bepaald waar informatie over is opgevraagd Een interactie dient op één van de volgende methoden te worden doorgegeven:
|
interaction.id | 0..1 | String | Interactie-id waarover meer informatie wordt gevraagd. 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:
|
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. |
Inhoud en formaat van een getInteractionInfoResponse
Bij het verzenden van een getInteractionInfoResponse dienen de volgende HTTP headers te worden meegezonden:
Content-Type: application/json; charset=utf-8
Het technische formaat van de HTTP body van een getInteractionInfoResponse is:
[{
"interactionId": "",
"interactionInfo": {
"transformableInteractions": [{
"id": ""
}]
}
}]
Output bestaat uit 1..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 getInteractionInfoRequest.
Name | Cardinality | Type | Toelichting |
interactionId | 1..1 | String | Elk JSON object bevat één van de interactie-ids waarover informatie is opgevraagd. Wordt gevuld met de interacties vanuit de getInteractionInfoRequest. |
interactionInfo | 1..1 | Object | Object welke interacties bevat die (mogelijk m.b.v. een transformatie) compatible zijn met de gevraagde interactie. |
interactionInfo.transformableInteractions | 0..n | Array van objecten | Array met interacties die transformeerbaar zijn met de gevraagde interactie. |
transformableInteractions.id | 1..1 | String | Het ID van de betreffende interactie. |
HTTP Status Codes
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 ontvangen interactie-id('s) interactie info wordt gevraagd. Zie de Toelichting bepalen ontvangen interactie-id(s) | Interactie-id kan niet worden bepaald (komt niet voor in de AORTA interactietabel en/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 bepaald m.b.v. de transformatie server metadata de interactie-ids waarnaar de gevraagde interactie getransformeerd kan worden. | |
4 <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.