Skip to main content
Skip table of contents

Interfaces MAP Server

MAP Interface

Deze interface is slechts bedoeld voor gebruik door VZVZ-componenten, en kan niet (rechtstreeks) worden gebruikt door GBx-applicaties.

Toetsing van het MAP

Feature

checkRequest

Type

Service

Versie

1.0.0

Systeemrolcode

-

Groep

Autorisatie

Gepubliceerd

Delta

Initiële versie van feature.

Use case

AOF.UC.MAP.100.v1

Feature

Versie

Dependency

Aanbieder

Afnemer

checkRequest

1.0.0

AORTA Stelseltoken

-

>=*

checkRequest

1.0.0

AORTA-ID HTTP Header

>=1.0.0

>=1.0.0

Inhoud en formaat van een checkRequest

Een checkRequest wordt op de volgende wijze verzonden:

POST [base endpointadres]/check/v1

Bij het verzenden van een checkRequest 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 checkRequest is:

{

    "interactionId": ["", ""],

    "roleCode": {
        "code": "",
        "codeSystem": ""
    },

    "dataCategory": {
        "code": "",
        "codeSystem": ""
    }

}

Input parameters:

Name

Cardinality

Type

Toelichting

interactionId

1..n

String

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

roleCode

0..1

String

Rolcode van de verantwoordelijke persoon voor de initiatie van de interactie-set.

roleCode.code

1..1

String

Het attribuut kan bevatten:

  • De rolcode die hoort bij een persoon, ofwel "P"

  • De UZI-rolcode van een zorgverlener, ofwel "<UZI-rolcode>"

roleCode.codeSystem

1..1

String

OID. Toegestane waarden:

  • "2.16.840.1.113883.2.4.3.11.8" (AORTA rolcode)

  • "2.16.840.1.113883.2.4.15.111" (UZI rolcode)

dataCategory

0..1

String

De contextcode die aanduidt binnen welke (zorg)toepassing de interacties worden geïnitieerd.

dataCategory.codeSystem

1..1

String

OID van het object "AORTA contextCodes".

Waarde: "urn:oid:2.16.840.1.113883.2.4.3.111.15.1"

dataCategory.code

1..1

String

De feitelijke contextcode die aanduidt binnen welke (zorg)toepassing de interacties worden geïnitieerd. Bijv. “BGZ”.

Inhoud en formaat van een checkResponse

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

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

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

[{
    "interactionId": "",
    "status": ""
}]

Output bestaat uit 0..n JSON objecten die elk bestaan uit de volgende attributen:

Name

Cardinality

Type

Toelichting

interactionId

1..1

String

Interactie-id van het te verzenden bericht.

status

1..1

String

MAP autorisatiebesluit m.b.t. dit interactie-id.

Mogelijke waarden:

  • "Allow"

  • "Deny"

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.

statuscode 200 OK

statuscode 400 Bad Request

statuscode 406 Not Acceptable

statuscode 415 Unsupported Media Type

statuscode 429 Too Many Requests

statuscode 500 Internal Server Error

Voorbeeld van gebruik MAP Server

Gedeeltelijke vulling van MAP t.b.v. medicatieoverdracht:

roleCode

Gebruikersinteractie

interactionId

securityLevel

contextCode

X

search:mp-MedicationAgreement:*

Midden

MEDGEG

X

QUMA_IN991201NL04

Midden

MEDGEG

X

search:mp-VariableDosingRegimen:*    

Midden

MEDGEG

X

QUDS_IN000001NL01

Midden

MEDGEG

..

Ontvangen checkRequest:

POST [base endpointadres]/check/v1
Content-Type: application/json; charset=utf-8AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>

{

    "interactionId": ["search:mp-MedicationAgreement:1.2", "search:mp-MedicationDispense:2"],

    "roleCode": {
        "code": "X",
        "codeSystem": "2.16.840.1.113883.2.4.15.111"
    },

    "dataCategory": {
        "code": "MEDGEG",
        "codeSystem": "urn:oid:2.16.840.1.113883.2.4.3.111.15.1"
    }

}

Bijbehorende checkResponse:

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

[{
        "interactionId": "search:mp-MedicationAgreement:1.2",
        "status": "Allow"
    },
    {
        "interactionId": "search:mp-MedicationDispense:2",
        "status": "Deny"
    }
]

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

JavaScript errors detected

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

If this problem persists, please contact our support.