Interfaces Applicatieregister

Applicatie Register Interface

Feature	activateTKID
Type	Service
Versie	1.0.1
Groep	Adressering
Gepubliceerd	08 Nov 2023
Delta	TKID-activatie moet, behalve in de component log, ook worden opgenomen in de messageLog.
Use case	AOF.UC.APR.100.v1

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

TKID-activatie

Inhoud en formaat van een activateTKIDrequest

Een activateTKIDrequest wordt op de volgende wijze verzonden:

CODE

POST [base endpointadres]/activate/v1

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

Bevragen Register

Feature	getApplication(s)
Type	Service
Versie	1.1.0
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
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
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

Feature	hasConformance
Type	Service
Versie	1.0.0
Groep	Adressering
Gepubliceerd	19 Oct 2023
Delta	Initiële versie van feature.
Use case	AOF.UC.APR.300.v1

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

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

Het versie-deel in het id attribuut wordt gespecificeerd conform semver, dus bijvoorbeeld "1.0.0" of "2.x". Resource Broker APR houdt bij het zoeken naar applicaties slechts rekening met het major nummer, omdat compatibiliteit hierdoor afdoende is geborgd.

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": "",
        "status": ""
    }]
}

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.status	1..1	String	Informatie over of dit interactie-id al dan niet wordt ondersteund. Mogelijke waarden: "Yes" "No"

Toetsen Mitz-status

Feature	migratedToMitz
Type	Service
Versie	1.0.0
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
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)