Use Cases Applicatieregister
Overzicht Applicatieregister
Onderstaande figuur toont een overzicht van de interfaces, services en functies van de Applicatieregister component. Het Applicatieregister bevat en ontsluit gegevens omtrent capabilities (conformances), status en technische adressen van AORTA Resource Clients en Servers.
De services zijn toegankelijk via een geboden interface en worden beschreven in de vorm van use cases. Een service wordt altijd vervult middels één of meerdere applicatiefuncties, bijvoorbeeld Applicatie Register.
Verwerken TKID-activatie
Primaire actor | Resource Client |
|---|---|
Systeem | Applicatie Register |
Secundaire actor | - |
Code | |
Realiseert Feature |
Pre-condities
Het systeem is slechts benaderbaar voor
|
Triggers
Een GBZ-beheerder wil een TKID(-set) activeren.
Main flow
Stap | Omschrijving | Uitzondering(en) |
|---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | Het systeem controleert of het verzoek t.b.v. deze primaire actor mag worden verwerkt, d.w.z. betreft het een update van de eigen TKID-set van de primaire actor, d.w.z. valt de primaire actor onder dezelfde organisatie als het appID dat is opgenomen in de interactie. | Mag niet worden verwerkt statuscode 403 Forbidden
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. |
3 | 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. |
4 | Het systeem toetst of de activatie van de ontvangen TKID's voldoet aan de TKID activatieregels, zoals omschreven in de toelichting "TKID activatieregels". | Ongeldig verzoek statuscode 400 Bad Request Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. |
5 | Het systeem verwerkt het verzoek in het APR, d.w.z. het vervangt een eventueel reeds geregistreerde set van TKID's door de nieuwe set. | |
6 <exit> | Het systeem retourneert een response naar de primaire actor. |
Post-condities
Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd. |
AOF.UC-APR.POS.140.v1 Het systeem heeft van het ontvangen request, de volgende attributen gelogd:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
|
AOF.UC-APR.POS.160.v1 Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
|
Het systeem heeft ontvangen request en de geretourneerde response daarnaast ook gelogd op de wijze, zoals beschreven in de Toelichting logging. |
TKID activatieregels
Voor de verwerking van activaties zijn een aantal regels van toepassing. De volgende (typen) systeemrollen mogen per Organisatie (URA) maximaal door één GBZ-applicatie worden vervuld:
Systeemrollen van de vorm "<resourcetype> <interactietype> Verwerkend Systeem", waarbij het interactietype gelijk is aan "create";
Systeemrollen die zijn verbonden aan de ontvangst en verwerking van een HL7v3-interactie, waarbij de aard van de interactie equivalent is aan die van een FHIR-create;
De systeemrol "Ontvankelijkheidstatus Opleverend Systeem".
Toetsing van deze regels vereist een aanpassing van het APR en wordt daarom vooralsnog niet gedaan. Volgt in een latere, nader te bepalen, release.
Opleveren gegevens
Primaire actor | Adressering Server |
|---|---|
Systeem | Applicatie Register |
Secundaire actor | - |
Code | |
Realiseert Feature |
Pre-condities
Het systeem is slechts benaderbaar voor
|
Triggers
De primaire actor heeft APR gegevens nodig.
Main flow
Stap | Omschrijving | Uitzondering(en) |
|---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | 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. |
3 | Het systeem verkrijgt de gevraagde gegevens. | |
4 <exit> | Het systeem retourneert een response naar de primaire actor. |
Post-condities
Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd. |
AOF.UC-APR.POS.140.v1 Het systeem heeft van het ontvangen request, de volgende attributen gelogd:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
|
AOF.UC-APR.POS.160.v1 Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
|
Toetsen conformances
Primaire actor | Autorisatie Server ZA |
|---|---|
Systeem | Applicatie Register |
Secundaire actor | - |
Code | |
Realiseert Feature |
Pre-condities
Het systeem is slechts benaderbaar voor
|
Het systeem beschikt over up-to-date gegevens betreffende de ondersteunde interacties en compatible interacties. |
Triggers
De primaire actor wil toetsen of een GBx-applicatie beschikt over bepaalde conformances.
Main flow
Stap | Omschrijving | Uitzondering(en) |
|---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | 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. |
3 | Het systeem toetst de conformances, en gebruikt hierbij zonodig de informatie uit de AORTA interactietabel (zie ook de Toelichting conformances). | |
4 <exit> | Het systeem retourneert een response naar de primaire actor. |
Post-condities
Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd. |
AOF.UC-APR.POS.140.v1 Het systeem heeft van het ontvangen request, de volgende attributen gelogd:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
|
AOF.UC-APR.POS.160.v1 Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
|
Toelichting conformances
Het APR bevat gegevens over welke systeemrollen een applicatie ondersteunt. Deze APR-gegevens zijn ook opvraagbaar via ZORG-AB.
Aan een systeemrol zijn, indien van toepassing, conformanceregels verbonden, met daarin de volgende gegevens:
interactie-id
ontvangen (ja/nee)
verzenden (ja/nee)
Het interactie-id heeft voor FHIR-interacties de volgende structuur:
<basis interactietype>:<FHIR-profiel>:<major FHIR profiel versie>, bijv. "search:mp-MedicationAgreement:1", OF
operation:<operation name>:<major operation versie>, bijv. "operation:$get-aorta-data:1".Voor oude interactie-id’s (<= AoF 0.7) geldt: de FHIR code (bijvoorbeeld "search" of "read"), het FHIR resourcetype (bijvoorbeeld "Observation") en interactieversie (bijvoorbeeld "1.0.x") worden tezamen opgevat als een interactie-id, en wel in het formaat "<code>:<resourcetype>:<versie>:<request/response>". Voorbeeld: “search:Observation:2.1:request”.
HL7v3-interacties worden in het APR altijd geregistreerd in request-response-paren. Voor FHIR-interacties wordt altijd gewerkt met één conformance voor een interactie, een request-interactie. Wanneer een GBx-applicatie een FHIR-request mag verzenden of mag ontvangen, dan mag deze applicatie automatisch ook de bijbehorende response ontvangen of retourneren (verzenden).
Om een v3-interactie te mogen initiëren (initiate=yes) en de bijbehorende response te mogen ontvangen heeft een GBx-applicatie een conformance nodig voor de request-interactie en één voor de bijbehorend response-interactie:
Initiëren van een request - verzenden “ja”.
Ontvangen van bijbehorende response - ontvangen “ja”.
Om een medische bouwsteen via een generieke query (HL7v3) te kunnen opvragen (trigger=yes), heeft een initiërende GBx-applicatie, naast conformances voor de generieke query, conformances nodig voor:
De betreffende v3-request-interactie, waarbij verzenden op “nee” staat en ontvangen op “nee” staat, EN voor de bijbehorende v3-response-interactie, waarbij ontvangen op “ja” staat.
Om een v3-interactie te mogen ontvangen (process=yes) en de bijbehorende response te mogen retourneren heeft een GBx-applicatie een conformance nodig voor de request-interactie en één voor de bijbehorend response-interactie:
Ontvangen van een request - ontvangen “ja”.
Retourneren van bijbehorende response - verzenden “ja”.
In het TKID-activatie process wordt geborgd dat een v3-systeem altijd beschikt over benodigde conformances voor de responses, doordat request-response paren zijn opgenomen in eenzelfde systeemrol.
Om een FHIR-interactie te mogen initiëren (initiate=yes) en de bijbehorende response te mogen ontvangen heeft een GBx-applicatie, zoals gezegd, slechts een conformance nodig voor de request-interactie:
Initiëren van een request inclusief ontvangen van bijbehorende response - verzenden “ja”.
Om een medische bouwsteen via een $get-aorta-data operation (HL7FHIR) te kunnen opvragen (trigger=yes), heeft een initiërende GBx-applicatie, naast een conformance voor de $get-aorta-data, een conformance nodig voor:
de betreffende FHIR-interactie, waarbij verzenden op “ja” OF op “nee” staat en waarbij ontvangen op “nee” staat.
Om een FHIR-interactie te mogen ontvangen (process=yes) en de bijbehorende response te mogen retourneren heeft een GBx-applicatie een conformance nodig voor de request-interactie:
Ontvangen van een request inclusief retourneren van bijbehorende response - ontvangen “ja”.
Mapping van conformances op hasConformanceResponse
Initiate is voor een conformance (interactie) gelijk aan “yes” indien:
v3: het betreft een request-interactie waarvoor verzenden=“ja”
FHIR: verzenden=“ja”
Trigger is voor een conformance gelijk aan “yes” indien:
v3: het betreft een request-interactie waarvoor verzenden=“nee” is EN ontvangen=“nee”
FHIR: ontvangen=“nee”
Process is voor een conformance gelijk aan “yes” indien:
v3: het betreft een request-interactie waarvoor ontvangen=“ja”
FHIR: ontvangen=“ja”
Toetsen Mitz-status
Primaire actor | Autorisatie Server ZA |
|---|---|
Systeem | Applicatie Register |
Secundaire actor | - |
Code | |
Realiseert Feature |
Pre-condities
Het systeem is slechts benaderbaar voor
|
Triggers
De primaire actor wil weten of voor een GBx-applicatie patiënttoestemmingen worden vastgelegd in Mitz.
Main flow
Stap | Omschrijving | Uitzondering(en) |
|---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | 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. |
3 | Het systeem bepaalt de Mitz-status van de GBZ-applicatie(s) van de zorgaanbieder (URA). | |
4 <exit> | Het systeem retourneert een response naar de primaire actor. |
Post-condities
Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd. |
AOF.UC-APR.POS.140.v1 Het systeem heeft van het ontvangen request, de volgende attributen gelogd:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
|
AOF.UC-APR.POS.160.v1 Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
|