Use Cases Resource Broker v3-in

Overzicht Resource Broker v3-in

Onderstaande figuur toont een overzicht van de interfaces, services en functies van de Resource Broker v3-in component. Resource Broker v3-in is voor HL7-v3 Resource Clients de ingang om interacties te initiëren bij AORTA Resource Servers. Wanneer een interactie moet worden geïnitieerd bij een AORTA Resource Server, dan verloopt dit altijd via Resource Broker VnC.

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 Screening. De RB v3-in component maakt zelf ook gebruik van een aantal interfaces, bijvoorbeeld van de Verzending & Consolidatie Interface.

Verwerken AORTA v3-interactie

Primaire actor	Resource Client (GBx-applicatie)
Systeem	ZA V3 Processor
Secundaire actor	Autorisatie Server ZA, Resource Broker VnC
Code	AOF.UC.V3IN.100.v3
Realiseert Feature	Generieke Query, core-V3-push-interactie

Pre-condities

De primaire actor is aangesloten op het systeem.

Het systeem is slechts benaderbaar voor

GBx-applicaties die zijn aangesloten op het AORTA netwerk

Het systeem ontvangt een v3-request slechts indien het hiervoor vereiste vertrouwensniveau wordt gehanteerd en de beschreven controles in het Ontwerp Authenticatie m.b.t. systeemauthenticatie zijn doorlopen. Dit wordt getoetst in de technische infrastructuur.

Triggers

De primaire actor stuurt een resource request in

Main flow

Stap	Omschrijving	Uitzondering(en)
1	Het systeem ontvangt een verzoek en start de verwerking.
2	Het systeem controleert het ontvangen request, zoals omschreven in de toelichting "Inhoudelijke toetsing v3-request".	Het resource request voldoet niet aan de specificaties Het systeem genereert de vereiste response conform de reguliere verwerking van berichten in AORTA en de AORTA foutentabel en keert terug naar de exit stap van de main flow.
3	Het systeem controleert dat de primaire actor in het APR is geregistreerd bij de organisatie met wie een TLS-verbinding is opgezet. Het id van de organisatie met wie een TLS-verbinding is opgezet wordt verkregen uit het servercertificaat van de TLS Client, of in het geval een AORTA Contracttoken werd ontvangen, uit de Issuer van het AORTA Contracttoken (NB. dus niet uit het concept-contracttoken). Het appID van de primaire actor wordt verkregen uit het binnenkomende bericht (<interactieID>/sender/device/id).	Geen match tussen applicatie en organisatie Het systeem genereert de vereiste response conform de reguliere verwerking van berichten in AORTA en de AORTA foutentabel en keert terug naar de exit stap van de main flow.
4	Het systeem controleert de ingezonden SAML Assertions zoals omschreven in de toelichting "Toetsing tokens bij inkomend v3-request".	Een verplicht token ontbreekt Het systeem genereert de vereiste response conform de reguliere verwerking van berichten in AORTA en de AORTA foutentabel en keert terug naar de exit stap van de main flow. Token kan niet worden gevalideerd of is ongeldig Het systeem genereert de vereiste response conform de reguliere verwerking van berichten in AORTA en de AORTA foutentabel en keert terug naar de exit stap van de main flow.
5	Het systeem verkrijgt een AORTA access_token middels Feature AORTA Token Exchange. Eventueel ontvangen zoekparameters in een generieke v3-query worden hierbij doorgegeven, zoals beschreven in de toelichting “Transformatie generieke parameters naar interactie-specifieke parameters“.	Géén AORTA access_token verkregen Het systeem genereert de vereiste response conform de reguliere verwerking van berichten in AORTA en de AORTA foutentabel en keert terug naar de exit stap van de main flow. Mapping van getTokenResponse/tokenExchangeResponse naar v3 foutcodes: statuscode 400, error=invalid_request >> SYNZIM statuscode 403, error=access_denied, error_description="Initiërende applicatie beschikt niet over de vereiste capabilities." >> AUTERR_CONFSND statuscode 403, error=access_denied, error_description="Ontvangende applicatie beschikt niet over de vereiste capabilities." >> AUTERR_CONFRCV statuscode 403, error=access_denied >> AUTERR_MEDISCH statuscode 500 >> SYNZIM
6	Afhankelijk van het type uit te voeren interactie, initieert het systeem Feature Uitvoeren get-aorta-data, of Uitvoeren push-aorta-data Eventueel ontvangen zoekparameters in een generieke v3-query worden hierbij doorgegeven, zoals beschreven in de toelichting “Transformatie generieke parameters naar interactie-specifieke parameters“.
7	Het systeem ontvangt een response.
8 <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.

Het systeem heeft het ontvangen request en de geretourneerde response gelogd.

Het systeem heeft van het ontvangen request, de volgende attributen gelogd:

datum en tijd van ontvangst
request-id
initial-request-id
sender-id
- role-id wanneer de sender van het request een VZVZ component is, en de aanroep niet via TLS geschiedt
- common name wanneer de aanroep via TLS geschiedt

Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:

datum en tijd van verzending
request-id
initial-request-id
receiver-id
- role-id wanneer de receiver van het request een VZVZ component is, en de aanroep niet via HTTP geschiedt
- FQDN wanneer de aanroep via HTTP geschiedt

Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
receiver-id
- role-id wanneer de receiver van de response een VZVZ component is, en de aanroep niet via TLS geschiedt
- common name wanneer de aanroep via TLS geschiedt
HTTP statuscode en eventueel geretourneerde foutinformatie

Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:

datum en tijd van response
request-id van het bijbehorende request
initial-request-id van het bijbehorende request
sender-id
- role-id wanneer de sender van de response een VZVZ component is, en de aanroep niet via TLS geschiedt
- common name wanneer de aanroep via TLS geschiedt
HTTP statuscode en eventueel geretourneerde foutinformatie

Toelichtingen

Inhoudelijke toetsing v3-request

Het systeem toetst of de ontvangen SOAP Envelope en de HL7v3-wrappers voldoen aan de van toepassing zijnde standaarden (hiervoor zijn XML-Schema beschikbaar).

Indien een request is gericht aan de Resource Broker zelf (bijvoorbeeld in geval van een generieke query), wordt daarnaast ook de inhoud van het request gevalideerd.

Het systeem voert de checks uit die zijn beschreven de AORTA publicatie. Het gaat hierbij om de volgende onderdelen:

Validatie van de berichtsyntax.

Toetsing tokens bij inkomend v3-request

Het systeem ondersteunt interacties die plaatsvinden o.b.v. tokenauthenticatie. Hierbij kunnen de volgende tokens worden meegezonden:

AORTA Transactietoken;
AORTA Mandaattoken;
AORTA Inschrijftoken;
AORTA Contracttoken.

De tokens dienen te worden getoetst op de wijze, zoals omschreven in de implementatiehandleidingen van de betreffende tokens. Bij deze validatie wordt ook de relatie tussen de tokens en het ontvangen v3-request getoetst. Dit is nodig omdat het v3-request niet wordt meegezonden naar Autorisatie Server ZA, en Autorisatie Server ZA deze checks daarom niet kan uitvoeren.

Bij alle ontvangen tokens moet worden getoetst of:

De Assertion correct is ondertekend door de Signature te valideren met het gerefereerde authenticatie certificaat. Het gebruikte certificaat en de relevante certificaatketen te valideren op geldigheid, inclusief revocatie.
Er wordt voldaan aan alle controles, zoals omschreven in de sectie "Generieke toetsing AORTA SAML Assertions".

Specifiek voor het AORTA Transactietoken moet worden getoetst of:

De Issuer gelijk is aan de URA uit het servercertificaat van de TLS-Client waarmee wordt gecommuniceerd.

Indien dit niet het geval is, dan dient gecontroleerd te worden of er een contracttoken is meegestuurd.

Indien naast het transactietoken een contracttoken wordt meegestuurd, dan moeten de volgende controles uitgevoerd worden:
- De Issuer van het contracttoken (URA van de zorgaanbieder) moet gelijk zijn aan de Issuer van het transactietoken.
- Als Subject.NameID van het transactietoken NIET gevuld is dan:
  - Het contracttoken bevat het private PKIo-certificaat met daarin de publieke sleutel waarmee het contracttoken is ondertekend. Hiermee wordt het transactietoken gevalideerd.
Indien Subject.NameID is gevuld: het transactietoken is getekend m.b.v. een UZI-zorgverlenerspas, medewerker-pas-op-naam, of ZORG-ID Smartcard.

Transformatie generieke parameters naar interactie-specifieke parameters

Eventuele additionele zoekparameters die zijn ontvangen in de generieke v3-query worden als volgt doorgegeven in de scope van het token request en bij de aanroep van de protocol-agnostische get-aorta-data:

Interactie-specifieke v3-parameter	Generieke parameter
MBHid	therapy-identifier
Identificatie	instance-identifier
GebruiksPeriode, VerstrekkingsPeriode, ToedieningsPeriode	effective-time