Procesimplementatie Raadplegen

versie: 04-11-2021 status: Consultatie

  • 04-11-2021

    • Implementatievarianten Ⅰ t/m Ⅴ geüpdatet

  • 22-06-2021

    • Sequentiediagram en bijbehorende omschrijving geüpdatet

    • Implementatievarianten geüpdatet en uitgebreid

    • De volgende rollen zijn hernoemd

      • “Mitz toestemmingsregister“ naar “Autorisatievoorziening“

      • “RLV“ naar “Knooppunt“

    • De rol “Requestor“ toegevoegd;

    • Oplossingsrichtingen “FHIR i.c.m. IHE XDS“ en “IHE-XDS“ verwijderd.

  • 07-04-2021

    • Diverse tekstuele aanpassingen doorgevoerd

  • 25-03-2021

    • Implementatieniveaus zijn komen te vervallen

    • Implementatievarianten toegevoegd

  • 25-11-2020

    • JWT toegevoegd aan transactie 1

  • 17-11-2020 (versie 1.1)

    • Volgorde in de beschrijving van sequentiediagram aangepast naar de huidige referentiearchitectuur;

    • Juiste doorverwijzing in de specificaties van de transacties tabel;

    • FHIR transacties onder oplossingsrichting FHIR bijgewerkt.

  • 15-10-2020 (versie 1.0)

    • Rollen in sequentiediagram en oplossingsrichtingen aangepast naar de vernieuwde referentiearchitectuur;

    • Sequentiediagram aangepast zodat een response terugkomt bij het systeem dat het bijbehorende request heeft uitgestuurd.

  • 1-7-2020

    • Eerste versie gepubliceerd

Dit artikel is op dit moment in uitgebreide revisie!

Toelichting
In dit artikel wordt de implementatie van Proces Raadplegen toegelicht. Het artikel beschrijft wat de verantwoordelijkheden van de rollen op de architectuurlaag Applicatie zijn ten aanzien van het proces Raadplegen. De procesimplementatie wordt toegelicht aan de hand van een sequentiediagram en een overzicht van de bijbehorende transacties. Vervolgens worden a.d.h.v. implementatievarianten verschillende manieren van de invulling van de rollen, die benodigd zijn voor het proces Raadplegen, beschreven.

Sequentiediagram

Toelichting
In het sequentiediagram worden de actoren en transacties van procesimplementatie Raadplegen weergegeven. De actoren komen overeen met de rollen op de architectuurlaag Applicatie. De referentiearchitectuur maakt in onderstaand sequentiediagram gebruik van gemeenschappelijke diensten, bijvoorbeeld van de autorisatievoorziening. Doordat de brondossierhouders gegevens ontsluiten voor meerdere zorgaanbieders, zorgpaden en zorgverleners zal de rol Lokalisatie-voorziening namens de raadpleger de toestemming opvragen bij de rol Autorisatievoorziening volgens de ‘open vraag'.

 

Beschrijving sequentie

Beschrijving sequentie

1. De Requestor roept de Viewer aan. Hiermee wordt de Zorgverlener die het proces start geauthentiseerd.
2a. Viewer verstuurt een informatievraag over een Cliënt aan Query Builder.
3. Query Builder vertaalt de informatievraag naar een query naar specifieke zibs. Welke zibs zijn benodigd en mag ik deze ophalen (autorisatie op basis van zibs)?
4a. Query Builder verstuurt de zib-query naar het raadplegende Knooppunt
5. Het Raadplegende Knooppunt authentiseert als eerste de zorgverlener.
6a. Het Raadplegende Knooppunt bevraagt de Lokalisatievoorziening om erachter te komen welke ‘bron’-Knooppuntdn informatie hebben over de Cliënt die opgevraagd kan worden in ZIB formaat.
7a. De Lokalisatievoorziening bevraagt de Autorisatievoorziening door middel van een open vraag om te controleren of er toestemming is om gegevens op te vragen.
6b. De Lokalisatievoorziening geeft antwoord met daarin de vermelding dat bron-Knooppunten US 1, 2 en 3 zibs beschikbaar hebben van Cliënt.
8a. Het raadplegende Knooppunt weet nu de locaties van de bron-Knooppunten die zibs beschikbaar kunnen stellen. De ZIB vraag (vanuit Query Builder) wordt nu gesteld aan alle bron Knooppunten die zibs beschikbaar hebben voor de Cliënt (Uitwisselingsysteem 1, 2 &3)
9a. Het bron-Knooppunt bevraagt de Resource Server welke zibs beschikbaar zijn.
10a. De Resource Server zal een autorisatievraag stellen of de gevraagde ZIB beschikbaar gesteld mag worden aan de geïdentificeerde zorgverlener. Dit kan via de autorisatievoorziening middels ‘de gesloten vraag’.
9b. De Resource Server stuurt de locatie/endpoints van de opgevraagde zibs terug naar het bron-Knooppunt.
11a. Het bron-Knooppunt haalt de daadwerkelijke zibs op bij de Resource Server.
8b. Het bron-Knooppunt stuurt nu de geautoriseerde zibs naar het raadplegende Knooppunt.
4b. Het raadplegende Knooppunt stuurt alle verzamelde zibs terug naar de Query Builder
12a. De Query Builder stuurt de zibs naar de Translator waar de gegevens worden vertaald van code naar een leesbare taal.
12b. De Translator stuurt de gegevens in leesbare taal terug naar de Query Builder.
2b. De Query Builder stuurt de vertaalde informatie naar Viewer, welke de informatie vervolgens toont aan de zorgverlener.

Transacties

Toelichting
In onderstaande tabel worden de transacties toegelicht die in het sequentiediagram zijn weergegeven.

Transactie #

Transactie

Specificaties

Opmerking

Transactie #

Transactie

Specificaties

Opmerking

1

SAML2.0 / OAuth2.0 / JWT

Transactie 1: XIS - Viewer

 

2

n.t.b.

Transactie 2: Viewer - Query Builder

 

3

n.t.b.

 

 

4

FHIR: GET DocumentReference

Transactie 4: Query Builder - RLV 

 

5

n.t.b.

 

 

6

FHIR: GET DocumentReference

 Transactie 6: RLV - LLV

Deze transactie wordt gespecificeerd in het Twiin Afsprakenstelsel.

7

n.v.t.

 Transactie 7: LLV - Mitz Toestemmingsregister

De rollen LLV en Mitz Toestemmingsregister worden uitgevoerd door 1 applicatie.

8

FHIR: GET <Resource>

 Transactie 8: RLV (raadplegend) - RLV (bron)

Deze transactie wordt gespecificeerd in het Twiin Afsprakenstelsel.

9

FHIR: GET DocumentReference

 Transactie 9: RLV - Resource server

Deze transactie wordt gespecificeerd in het Twiin Afsprakenstelsel.

10

n.t.b.

 Transactie 10: Resource server - Mitz Toestemmingsregister

 

11

FHIR: GET <Resource>

 Transactie 11: RLV - Resource server

 

12

n.t.b.

Transactie 12: Query Builder - Translator

 

Implementatievarianten

Toelichting
Het Afsprakenstelsel Interoperabiliteit Geboortezorg onderscheidt op het gebied van Raadplegen de volgende implementatievarianten:

  • Het zorginformatiesysteem bestaat uit de rol Requestor. De rollen Viewer, Query Builder en Translator zijn ingevuld door middel van losse applicaties.

  • Het zorginformatiesysteem bestaat uit de rollen Requestor en Viewer. De rollen Query Builder en Translator zijn ingevuld door middel van losse applicaties.

  • Het zorginformatiesysteem bestaat uit de rollen Requestor, Viewer en Query Builder. De rol Translator is ingevuld als een losse applicatie.

  • Het zorginformatiesysteem bestaat uit de rollen Requestor, Viewer, Query Builder en Translator.

Om tot een keuze voor een implementatievariant te komen, dienen per Zorgaanbieder de volgende vragen te worden beantwoord:

  • Welke rollen kán het zorginformatiesysteem invullen in relatie tot het Afsprakenstelsel Interoperabiliteit Geboortezorg in het algemeen en de Informatiestandaard Geboortezorg in het bijzonder?

  • Welke rollen wíl de Zorgaanbieder dat het zorginformatiesysteem invult?

Voor een overzicht van de verschillende leveranciers en de mogelijke implementatievarianten zie Applicatie overzicht.

Implementatievariant Raadplegen Ⅰ

  • Er wordt voor gekozen dat het Zorginformatiesysteem invulling geeft aan de rol Requestor waarmee de Zorgverlener de Viewer opent. De Requestor stuurt informatie over de zorgverlener mee zodat deze kan worden geauthentiseerd;

  • De Zorgaanbieder is verantwoordelijk voor de juiste invulling van alle rollen die nodig zijn voor het Raadplegen van gegevens. In deze implementatievariant geeft het zorginformatiesysteem alleen invulling aan de rol Requestor;

  • De Viewer, Query Builder, Translator en Knooppunt zijn losstaande applicaties. Deze rollen kunnen door 1 of meerdere leveranciers aan de Zorgaanbieder worden geleverd;

  • De Query Builder en Translator zijn losstaande applicaties die gebruik maken van een tabel met landelijke definities.


Implementatievariant Raadplegen Ⅱ

  • Er wordt voor gekozen dat het Zorginformatiesysteem invulling geeft aan de rollen Requestor, waarmee de Zorgverlener de Viewer opent, en de Viewer, waarin de Zorgverlener gegevens kan raadplegen en inzien. Hiermee vindt de authenticatie al plaats bij de Requestor en is de Viewer onderdeel van het zorginformatiesysteem;

  • De Zorgaanbieder is verantwoordelijk voor de juiste invulling van alle rollen die nodig zijn voor het Raadplegen van gegevens. In deze implementatievariant geeft het zorginformatiesysteem invulling aan de rollen Requestor en Viewer;

  • De Query Builder, Translator en Knooppunt zijn losstaande applicaties. Deze rollen kunnen door 1 of meerdere leveranciers aan de Zorgaanbieder worden geleverd;

  • De Query Builder en Translator zijn losstaande applicaties die gebruik maken van een tabel met landelijke definities.

Implementatievariant Raadplegen Ⅲ

  • Er wordt voor kozen dat het Zorginformatiesysteem invulling geeft aan de rollen Requestor, waarmee de Zorgverlener de Viewer opent, de Viewer, waarin de Zorgverlener gegevens kan raadplegen en inzien, en de Query Builder welke een lijst met benodigde zibs samenstelt a.d.h.v. de vraag van de Zorgverlener;

  • De Zorgaanbieder is verantwoordelijk voor de juiste invulling van alle rollen die nodig zijn voor het Raadplegen van gegevens. In deze implementatievariant geeft het zorginformatiesysteem invulling aan de rollen Requestor, Viewer en Query Builder;

  • De rollen Translator en Knooppunt worden door een aparte leverancier aan de Zorgaanbieder geleverd;

  • De Translator is een losstaande applicatie die gebruik maakt van een landelijke definitie.

 

 

Implementatievariant Raadplegen Ⅳ

  • Er wordt voor gekozen dat het Zorginformatiesysteem invulling geeft aan de rollen Requestor, waarmee de Zorgverlener de Viewer opent, de Viewer, waarin de Zorgverlener gegevens kan raadplegen en inzien, de Query Builder welke een lijst met benodigde zibs samenstelt a.d.h.v. de vraag van de Zorgverlener, en de Translator, welke ervoor zorgt dat de gegevens vanuit code (bv SNOMED) vertaald worden naar een voor Zorgverleners leesbare taal;

  • De Zorgaanbieder is verantwoordelijk voor de juiste invulling van alle rollen die nodig zijn voor het raadplegen van gegevens. In deze implementatievariant geeft het zorginformatiesysteem invulling aan alle benodigde rollen voor dit proces;

  • De rol Knooppunt wordt door een aparte leverancier aan de Zorgaanbieder geleverd;

  • De Query Builder en Translator zijn onderdeel van het zorginformatiesysteem en maken gebruik van een tabel met landelijke definities.

 

Implementatievariant Raadplegen Ⅴ

  • Er wordt voor gekozen dat het Zorginformatiesysteem invulling geeft aan de rollen Requestor, waarmee de Zorgverlener de Viewer opent, de Viewer, waarin de Zorgverlener gegevens kan raadplegen en inzien, de Query Builder welke een lijst met benodigde zibs samenstelt a.d.h.v. de vraag van de Zorgverlener, de Translator, welke ervoor zorgt dat de gegevens vanuit code (bv SNOMED) vertaald worden naar een voor Zorgverleners leesbare taal en een Knooppunt, waarmee toegang verkregen wordt tot de gemeenschappelijke functies.

  • De Zorgaanbieder is verantwoordelijk voor de juiste invulling van alle rollen die nodig zijn voor het raadplegen van gegevens. In deze implementatievariant geeft het zorginformatiesysteem invulling aan alle benodigde rollen voor dit proces;

  • De Query Builder en Translator zijn onderdeel van het zorginformatiesysteem en maken gebruik van een tabel met landelijke definities.

 

 

 

 

Samen komen we verder
Dit artikel is tot stand gekomen met de kennis en inzichten van professionals, experts, beleidsmakers en bestuurders. Bij VIPP Babyconnect geloven we dat er vele perspectieven nodig zijn om te gaan zien wat voor iedereen werkt. En die afweging kan altijd beter. Zie jij mogelijkheden voor verbetering in dit artikel? Vraag via info@carecodex.org een review-account aan en laat een reactie achter.
Samen weten we meer. Samen komen we verder.