Interfaces Applicatieregister

Applicatie Register Interface

TKID-activatie

Feature	activateTKID
Type	Service
Versie	1.1.0
Systeemrolcode	activate:OIS:-:1
Groep	Adressering
Gepubliceerd	23 Sep 2024
Delta	Ook ondersteunen AoF 0.6 interface.
Use case	AOF.UC.APR.100.v1

Feature	Versie	Dependency	Aanbieder	Afnemer
activateTKID	1.1.0	AORTA Stelseltoken	-	>=*
activateTKID	1.1.0	AORTA-ID HTTP Header	>=1.0.0	>=1.0.0
activateTKID	1.1.0	AORTA-Version HTTP Header	>=1.0.0	>=1.0.0

Inhoud en formaat van een activateTKIDrequest

Een activateTKIDrequest wordt op de volgende wijze verzonden:

CODE

POST [base endpointadres]/activate/v1

Totdat AoF 0.6 is uitgefaseerd, biedt het Applicatieregister tijdelijk ook nog de interface, zoals beschreven in de AoF 0.6 specificaties.

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

Feature	AORTA-ID HTTP Header
Type	Subfeature
Versie	1.0.0
Systeemrolcode	-
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
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.

Feature	AORTA-Version HTTP Header
Type	Subfeature
Versie	1.0.0
Systeemrolcode	-
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
Delta	Initiële versie van feature.

AORTA-Version: contentVersion=<versienummer>; acceptVersion=<versienummer>

Wanneer een Resource Server een FHIR interactie ontvangt, dan kan het a.d.h.v. de syntax van het ontvangen request afleiden om welke interactie het gaat, bijvoorbeeld "een FHIR-search naar Obervations", of "een FHIR-read van een Binary". Daarnaast is iedere interactie voorzien van een versienummer. Voor versienummering wordt gebruik gemaakt van semantic versioning.

De acceptVersion geeft aan conform welke versie(s) de interactie mag worden verwerkt en beantwoord. Het versienummer in de acceptVersion wordt gespecificeerd conform semver, dus bijvoorbeeld "2.x" of "~1.2.3 || ^2.1.0". In het algemeen geldt dat een resource server een interactie dient te verwerken conform de hoogst aangegeven acceptVersion die het zelf op dat moment kan toepassen.

De contentVersion geeft aan welke versie van de interactie daadwerkelijk is gehanteerd. In de contentVersion dient het versienummer de exacte versie van de interactie te bevatten die is gehanteerd, dus zonder wildcards of ranges, bijvoorbeeld “1”, of "2.2". De versie van een FHIR-interactie is opgenomen in het interactie-id.

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

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

JSON

{
  "applicationId": "<app-id>",
  "tkid": ["string", "string"]
}

In Parameters:
Name	Cardinality	Type	Toelichting
applicationId	1..1	string	Het app-id van de GBx-applicatie waarvoor de TKID('s) geactiveerd dienen te worden. Het betreft het app-id zonder aanduiding van een namingsystem of root OID.
tkid	0..*	string	TKID die is toegekend tijdens AORTA acceptatie.

Inhoud en formaat van een activateTKIDresponse

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

Subfeature	AORTA-Version HTTP Header
Versie	1.0.0

AORTA-Version: contentVersion=<versienummer>

De contentVersion geeft aan welke versie van de interactie daadwerkelijk is gehanteerd. In de contentVersion dient het versienummer de exacte versie van de interactie te bevatten die is gehanteerd, dus zonder wildcards of ranges, bijvoorbeeld “1”, of "2.2". De versie van een FHIR-interactie is opgenomen in het interactie-id.

Een activateTKIDresponse bevat géén HTTP body.

Toelichting TKID

Middels een activatie van een TKID geeft de GBZ-beheerder aan dat het voor de xIS-instantie, die wordt aangeduid met het applicatieID, een bepaalde set van reeds verkregen acceptaties (nader aangeduid door een set van xIS-type kwalificaties ID's - TKID's) wil activeren. Als gevolg hiervan worden de AORTA systeemrollen, waarvoor het xIS-type blijkens de TKID's is geaccepteerd, in het APR gekoppeld aan de xIS-instantie (de Applicatie). Nadat deze actie is voltooid, kunnen de FHIR capabilities die deel uitmaken van deze AORTA systeemrollen, via de resource broker, bij het xIS worden aangesproken. Bij een activatie wordt een eventueel eerder geregistreerde set van TKID's vervangen door de nieuwe set van TKID's. Indien er een probleem is met één van de TKID's in een set, dan wordt de gehele transactie afgewezen en verandert er dus niets. Het is ook mogelijk om geen enkele tkid te activeren (door geen tkid attribuut op te nemen in de body van het request).

Aanvullende eisen

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.

Interne APR Interface

Bevragen Register

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

Feature	getApplication(s)
Type	Service
Versie	1.1.0
Systeemrolcode	-
Groep	Adressering
Gepubliceerd	22 Dec 2023
Delta	Toevoeging van URA aan getApplicationResponse en aan getApplicationsResponse.
Use case	AOF.UC.APR.200.v1

Feature	Versie	Dependency	Aanbieder	Afnemer
getApplication(s)	1.1.0	AORTA Stelseltoken	-	>=*
getApplication(s)	1.1.0	AORTA-ID HTTP Header	>=1.0.0	>=1.0.0

Inhoud en formaat van een getApplicationRequest

Een getApplicationRequest wordt op de volgende wijze verzonden:

CODE

POST [base endpointadres]/getApplication/v1

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

Feature	AORTA-ID HTTP Header
Type	Subfeature
Versie	1.0.0
Systeemrolcode	-
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
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 getApplicationRequest is:

JSON

{
  "applicationId": ""
}

Input parameters:

Name	Cardinality	Type	Toelichting
applicationId	1	String	Het betreft het app-id zonder aanduiding van een namingsystem of root OID.

Inhoud en formaat van een getApplicationResponse

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

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

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

JSON

{
  "applicationId": "",
  "ura": "",
  "active": "",
  "address": "",
  "systemRoles": [
    {
      "role": "",
      "conformances": [
        {
          "interactionId": "",
          "send": "",
          "receive": ""
        }
      ]
    }
  ]
}

Inhoud en formaat van een getApplicationsRequest

Een getApplicationsRequest wordt op de volgende wijze verzonden:

CODE

POST [base endpointadres]/getApplications/v1

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

Feature	AORTA-ID HTTP Header
Type	Subfeature
Versie	1.0.0
Systeemrolcode	-
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
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 getApplicationsRequest is:

JSON

{
  "ura": ""
}

Input parameters:

Name	Cardinality	Type	Toelichting
ura	1	String	Het betreft de URA zonder aanduiding van een namingsystem of root OID.

Inhoud en formaat van een getApplicationsResponse

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

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

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

JSON

[
  {
    "applicationId": "",
    "ura": "",
    "active": "",
    "address": "",
    "systemRoles": [
      {
        "role": "",
        "conformances": [
          {
            "interactionId": "",
            "send": "",
            "receive": ""
          }
        ]
      }
    ]
  }
]

Inhoud van een application object:

Name	Cardinality	Type	Toelichting
applicationId	1..1	String	Waarde is "<appID van GBx-applicatie>" Het betreft het app-id zonder aanduiding van een namingsystem of root OID.
active	1.1	String	Waarde "true" of "false".
address	1..1	String	FQDN waarop de GBx-applicatie kan worden bereikt.
systemRoles	0..n	Object met attributen	Ondersteunde systeemrollen.
systemRoles.role	1..1	String	Code van de ondersteunde systeemrol.
systemRoles.conformances	0..n	Object met attributen	Informatie over de ondersteunde conformances
conformances.interactionId	1..1	String	Het interactie-id
conformances.send	1..1	String	Waarde "true" of "false".
conformances.receive	1..1	String	Waarde "true" of "false".

Toetsen conformances

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

Feature	hasConformance
Type	Service
Versie	2.0.0
Systeemrolcode	-
Groep	Adressering
Gepubliceerd	08 Nov 2024
Delta	Onderscheid kunnen maken tussen verschillende situaties: zelf initiëren (en ontvangen antwoord) - mode=initiate ontvangen (en antwoorden) - mode=process laten initiëren (via get-aorta-data) en ontvangen antwoord - mode=trigger
Use case	AOF.UC.APR.300.v2

Feature	Versie	Dependency	Aanbieder	Afnemer
hasConformance	2.0.0	AORTA Stelseltoken	-	>=*
hasConformance	2.0.0	AORTA-ID HTTP Header	>=1.0.0	>=1.0.0
hasConformance	2.0.0	Formaat AORTA interactietabel	>=*	-

Inhoud en formaat van een hasConformanceRequest

Resource broker biedt een interactie aan, waarmee kan worden bepaald of een bepaalde GBx-applicatie, gegevens conformances bevat.

Een hasConformanceRequest wordt op de volgende wijze verzonden:

CODE

POST [base endpointadres]/hasConformance/v1

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

Feature	AORTA-ID HTTP Header
Type	Subfeature
Versie	1.0.0
Systeemrolcode	-
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
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 hasConformanceRequest is:

CODE

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

Input parameters:

Name

Cardinality

Type

Toelichting

applicationId

1..1

string

Het app-id van de GBx-applicatie waarvoor de toets moet worden uitgevoerd. Het betreft het app-id zonder aanduiding van een namingsystem of root OID.

interactionId

1..n

String

Te toetsen interaction-id.

Een interactie-id bevat voor FHIR-interacties een major versienummer conform semver.

Bij v3-interacties heeft een interactie een ID voor het request en een ander ID voor de bijbehorende response. Wanneer v3-conformances moeten worden getoetst dan hoeft een client slechts één van deze ID’s mee te geven. Bij het bepalen van de conformanceStatus die moet worden geretourneerd, wordt wel gekeken naar beide ID’s.

Bij FHIR-interacties heeft een interactie slechts één ID die hoort bij het request en bij de bijbehorende response.

Inhoud en formaat van een hasConformanceResponse

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

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

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

JSON

{
    "applicationId": "",
    "fqdn": "",
    "conformanceStatus": [{
        "interactionId": "",
        "initiate": "",
        "trigger": "",
        "process": ""
    }]
}

Output parameters:

Name	Cardinality	Type	Toelichting
applicationId	1..1	string	Het app-id van de GBx-applicatie waarvoor de toets moet worden uitgevoerd. Het betreft het app-id zonder aanduiding van een namingsystem of root OID.
fqdn	1..1	String	FQDN van de GBx-applicatie, die hoort bij het app-id.
conformanceStatus	1..n	Object met attributen	Eén object voor ieder te toetsen interaction-id.
conformanceStatus.interactionId	1..1	String	Het getoetste interaction-id. Wordt gevuld met het ontvangen interactionId uit het request.
conformanceStatus.initiate	1..1	String	Informatie over of de betreffende GBx-applicatie deze interactie zelf mag initiëren. Mogelijke waarden: "Yes" "No"
conformanceStatus.trigger	1..1	String	Informatie over of de betreffende GBx-applicatie deze interactie mag laten initiëren door de resource broker (via een generieke v3-query of een $get-aorta-data operation). Mogelijke waarden: "Yes" "No"
conformanceStatus.process	1..1	String	Informatie over of de betreffende GBx-applicatie deze interactie mag ontvangen, verwerken en beantwoorden. Mogelijke waarden: "Yes" "No"

Toetsen Mitz-status

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

Feature	migratedToMitz
Type	Service
Versie	1.0.0
Systeemrolcode	-
Groep	Adressering
Gepubliceerd	22 Dec 2023
Delta	Initiële versie van feature. Vervangt Feature isMitzClient.
Use case	AOF.UC.APR.400.v2

Feature	Versie	Dependency	Aanbieder	Afnemer
migratedToMitz	1.0.0	AORTA Stelseltoken	-	>=*
migratedToMitz	1.0.0	AORTA-ID HTTP Header	>=1.0.0	>=1.0.0

Inhoud en formaat van een migratedToMitzRequest

Resource broker biedt een interactie aan, waarmee kan worden bepaald of een zorgaanbieder gebruik maak van Mitz voor registratie en toetsing van patiënttoestemming.

Een migratedToMitzRequest wordt op de volgende wijze verzonden:

CODE

POST [base endpointadres]/migratedToMitzRequest/v1

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

Feature	AORTA-ID HTTP Header
Type	Subfeature
Versie	1.0.0
Systeemrolcode	-
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
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 migratedToMitzRequest is:

JSON

{
  "source": [
    {
      "code": "",
      "codeSystem": ""
    },
    {
      "code": "",
      "codeSystem": ""
    }
  ]
}

Input parameters:

Name	Cardinality	Type	Toelichting
source	0..n	Object met attributen	Identificatie van de zorgaanbieder, waarvoor de toets moet worden uitgevoerd. Toegestane vullingen: één URA, OF één of meerdere appID’s
source.code	1..1	String	Beoogde bestemming van de interactie. Mogelijke waarden: <appID> <URA>
source.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)

Inhoud en formaat van een migratedToMitzResponse

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

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

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

JSON

{
  "result": [
    {
      "applicationId": "",
      "status": ""
    },
    {
      "applicationId": "",
      "status": ""
    }
  ]
}

Output parameters:

Name	Cardinality	Type	Toelichting
result	0..n	Object met attributen	Indien géén GBx-applicatie is gevonden bij de URA, dan wordt geen result geretourneerd.
result.applicationId	1..1	String	Het app-id van de GBx-applicatie waarvoor de toets is uitgevoerd. Het betreft het app-id zonder aanduiding van een namingsystem of root OID.
result.status	1..1	String	Informatie over of de GBx-applicatie gebruik maakt van Mitz. Mogelijke waarden: "Migrated" (de GBx-applicatie is volledig gemigreerd naar Mitz) “Migrating” (de GBx-applicatie migreert op het moment naar Mitz) "None" (de GBx-applicatie is niet gemigreerd naar Mitz, en hier ook nog niet mee gestart)

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.