Werkgroep G19. Nota betreffende de doelstellingen en standaardfunctionaliteiten van een hub in de context van het project hubs-metahub

Datum: 26/05/2010 Pagina: 1

Werkgroep G19 Nota betreffende de doelstellingen en standaardfunctionaliteiten van een “hub” in de context van het project “hubs-metahub”


INHOUDSOPGAVE INLEIDING................................................................................................................................................ 3 1

ALGEMENE DOELSTELLINGEN ................................................................................................ 4

2

ARCHITECTUUR: FUNDAMENTELE PRINCIPES .................................................................. 5

3

STANDAARDFUNCTIONALITEITEN ......................................................................................... 7 3.1 3.1.1

Opzoeking en raadpleging van documenten ............................................................ 7

3.1.2

Toestemmingen en therapeutische relaties .............................................................. 7

3.1.3

Andere functionaliteiten............................................................................................. 7

3.2

Functionaliteiten voor andere hubs ............................................................................... 8

3.2.1


3.2.2


3.3

Interactie met de metahub............................................................................................. 8

3.3.1


3.3.2

Toestemmingen en therapeutische relaties .............................................................. 8

3.3.3


3.4 4

Functionaliteiten ten behoeve van de klanten van de hubs .......................................... 7

Globaal proces .............................................................................................................. 9

TECHNISCHE ELEMENTEN....................................................................................................... 10 4.1

Uitwisselingsstandaarden............................................................................................ 10

4.2

Vercijfering................................................................................................................... 10


Inleiding Dit document geeft een korte beschrijving van de rol en de “standaard”-functionaliteiten die een “hub” moet ondersteunen in de globale context van het systeem van “hubs-metahub” vastgesteld op het niveau van het eHealth-platform. Het is niet de bedoeling om de mogelijke diensten van een gezondheidsnetwerk aan zijn partners te beperken, maar om de rol van een “hub” te bepalen, samen met de onderliggende functionaliteiten die hij moet bieden aan de andere deelnemers van het netwerk, hetgeen overeenstemt met de scope van de “Geïnformeerde toestemming van de patiënt voor het systeem van hubs-metahub”. Ieder gezondheidsnetwerk kan immers bijkomende functionaliteiten aanbieden en de nodige middelen implementeren om deze functionaliteiten te ondersteunen, maar die zullen dan niet gedekt zijn door deze toestemming en door de hiermee verbonden machtigingen. Bovendien wordt er benadrukt dat het hier gaat om een eerste gemeenschappelijke (en minimale) basis voor de definitie van deze rol en deze functionaliteiten. Deze definitie kan, onder voorbehoud van overeenstemming tussen de verschillende partners, nog verder evolueren. 1

Deze nota is een technische nota en vervangt dus geenszins het « algemeen reglement voor het gebruik van het systeem van hubs-metahub » waaraan momenteel gewerkt wordt. De nota vormt echter geen lastenboek met een opsomming van de informatica-vereisten van een hub. Een dergelijk lastenboek behoort tot de verantwoordelijkheid van elke afzonderlijke hub. De nota bevat ook geen specificaties op het vlak van technische interfaces. Deze technische specificaties worden vastgesteld binnen een werkgroep architectuur en kunnen worden beschouwd als een technische bijlage bij dit document. Het gaat hier meer over de opbouw van een vocabularium en het uitwerken van een gemeenschappelijke definitie met het oog op de ondersteuning van de uitbouw van een coherent globaal systeem. De bedoeling is om een samenvatting te geven van de discussies binnen de werkgroep G19 omtrent het systeem van hubs-metahub. Dit document bestaat uit 4 delen. Het eerste en het tweede deel geven respectievelijk een beschrijving van de primaire doelstellingen van het globale systeem van « hubs-metahub » en van het fundamentele principe van de architectuur die geïmplementeerd werd om deze doelstellingen te bereiken. Het derde deel geeft een opsomming van de verschillende functionaliteiten op het niveau van de hubs ter ondersteuning van deze architectuur. Deze functionaliteiten worden beschouwd als standaardfunctionaliteiten. Het vierde deel beschrijft ten slotte de technische vereisten waaraan de hubs moeten voldoen om de globale architectuur van het systeem te ondersteunen.

1

De nota handelt niet over organisatorische aspecten.


1 Algemene doelstellingen De centrale problematiek van het systeem van hubs-metahub kan kort worden samengevat: de uiteindelijke bedoeling van het systeem in zijn geheel is om een zorgverlener de mogelijkheid te bieden om alle gepubliceerde medische documenten met betrekking tot een bepaalde patiënt terug te vinden en te raadplegen, ongeacht de plaats waar deze documenten opgeslagen zijn en ongeacht de plaats vanwaar de zorgverlener op het systeem inlogt. Het doel is om de uitwisseling van gegevens te ondersteunen in het kader van de continuïteit van de zorg, zonder centralisering van de gegevens maar via lokale of regionale netwerken. Het spreekt voor zich dat dit de uiteindelijke bedoeling is maar dat de implementatie van een dergelijk systeem geleidelijk zal gebeuren. Er wordt in het bijzonder op gewezen dat niet « alle documenten » onmiddellijk en massaal beschikbaar zullen zijn. Het invullen van het systeem zal geleidelijk gebeuren in functie van de prioriteiten van de verschillende actoren. Uiteraard zal de raadpleging van de medische documenten strikt geregeld worden. Zonder in detail te willen treden, brengen we de volgende twee fundamentele principes in herinnering. •

Geen enkel document met betrekking tot een patiënt zal toegankelijk zijn zonder de toestemming van de patiënt in kwestie. Dit principe wordt beschreven in de nota “geïnformeerde toestemming van de patiënt”. De toestemming bepaalt dus de effectieve publicatie van de medische gegevens van een patiënt.

•

Geen enkel document kan worden geraadpleegd (of gezien) door een zorgverlener zonder dat er tussen de patiënt en de zorgverlener een verband bestaat dat deze raadpleging rechtvaardigt. Men spreekt van « therapeutische relatie ». Het bewijs en de aard van deze relatie worden beschreven in de « Nota met betrekking tot het elektronische bewijs van een therapeutische relatie tussen een ziekenhuis of een arts enerzijds en een patiënt 2 anderzijds » . De therapeutische relaties bepalen de « standaard » toegangsregels tot de documenten die binnen het systeem gepubliceerd zijn. Naast deze standaardregels zijn er nog andere mechanismen die de toegang beperken, zoals het lokale user management en uitsluitingsmechanismen.

Om deze doelstelling van opzoeking en raadpleging van documenten te bereiken, dient het systeem van “hubs-metahub” twee belangrijke functionaliteitgroepen te ondersteunen. •

Het systeem moet toelaten om een “verwijzingsrepertorium ” te voeden en te raadplegen, met aanduiding van waar een bepaald soort document met betrekking tot een bepaalde patiënt zich bevindt. Het gaat hier om een virtueel repertorium, waarvan de organisatie verder beschreven wordt op het niveau van de architectuur, en niet om een centrale database.

•

Het systeem moet de mededeling toelaten van een medisch document tussen de actor van het systeem die dit document bewaart en de actor van het systeem die de raadpleging van het document mogelijk maakt.

3

2

Document beschikbaar op https://www.ehealth.fgov.be/binaries/website/nl/pdf/Nota_therapeutische_relatie_19012010FINAL.pdf 3

Verwijzingsrepertorium voorzien in artikel 5, 4°, b) van de wet van 21 augustus 2008 houdende oprichting en organisatie van het eHealth-platform.


2 Architectuur: fundamentele principes De gekozen architectuur is een gedistribueerde architectuur van het type “System-to-System”, waarbij de hubs het kernelement vormen. Elk gezondheidsnetwerk is opgebouwd rond een centraal element, « hub » genoemd. Elke hub laat toe documenten uit te wisselen tussen de ziekenhuizen en huisartsen(organisaties) waaruit de hub is samengesteld. Deze laatsten kunnen worden beschouwd als « klanten » van de hubs. Dit model is uiteraard technisch uitbreidbaar tot andere soorten “klanten”, zoals de groepspraktijken. Elke hub beschikt over een soort verwijzingsrepertorium waarin is aangegeven in welk ziekenhuis (of ander soort organisatie) van het netwerk een document m.b.t. een patiënt zich bevindt. 4 De implementatie van dit verwijzingsrepertorium binnen elk netwerk is de verantwoordelijkheid van dit netwerk.

Figuur 1 : Algemene architectuur

De basisdienst “metahub”, die door het eHealth-platform ter beschikking wordt gesteld, biedt ondersteuning bij de gegevensuitwisseling tussen hubs. Technisch gezien betreft het echter eerder een "lokalisatiedienst" aan de hand waarvan een hub kan weten of er binnen een andere hub documenten m.b.t. een patiënt bestaan. Geen enkel medisch gegeven passeert via de "metahub". Met behulp van het "User and Access Management" van het eHealth-platform worden de vereiste hoedanigheden gevalideerd om toegang te krijgen tot de diensten van de metahub of om de verbindingen tussen hubs tot stand te brengen. De eigenlijke gegevensstromen verlopen via de hubs. De gezondheidsnetwerken dienen de verschillende toegangsregels voor het raadplegen van de documenten te controleren. Bij een interhubraadpleging zal het netwerk dat de raadpleging uitvoert verantwoordelijk zijn voor de controle van de therapeutische relatie ter rechtvaardiging van de raadpleging van het document. Bij deze controle

4

Dit repertorium kan in de praktijk virtueel zijn.


worden de principes uit de « Nota met betrekking tot het elektronische bewijs van een therapeutische 5 relatie tussen een ziekenhuis of een arts enerzijds en een patiënt anderzijds » in acht genomen. De gegevens die in het verwijzingsrepertorium van het eHealth-platform zijn opgenomen ter ondersteuning van de implementatie van de basisdienst metahub zijn in hoge mate gekoppeld. Het repertorium bevat immers hoofdzakelijk de “linken patiënt – hub”. Een link patiënt – hub duidt aan dat er binnen de hub minstens één document m.b.t. een patiënt beschikbaar is. Uiteindelijk is het algemene verwijzingsrepertorium uit twee hoofdlagen opgebouwd: een eerste, zeer gecondenseerde laag wordt opgeslagen op het niveau van het eHealth-platform, terwijl de laag van de eigenlijke documentverwijzingen op het niveau van elke hub wordt opgeslagen. Er werd voor deze aanpak gekozen om twee redenen: enerzijds slaat het eHealth-platform aldus geen medische informatie over de patiënten op, ook niet onrechtstreeks, en anderzijds laat deze aanpak toe de bestaande lokale en regionale initiatieven te benutten en te valoriseren. Bovendien wordt in het verwijzingsrepertorium van het eHealth-platform ook informatie opgeslagen met betrekking tot het bestaan van een geïnformeerde toestemming van de patiënt voor het systeem van hubs-metahub. Het bestaan van een dergelijke toestemming is een voorwaarde voor iedere verdere registratie binnen het systeem. Het verwijzingsrepertorium van het eHealth-platform wordt gevoed door de hubs.

5

Beschikbaar op: https://www.ehealth.fgov.be/binaries/website/nl/pdf/Nota_therapeutische_relatie_19012010-FINAL.pdf


3 Standaardfunctionaliteiten Ter ondersteuning van deze architectuur interageert iedere hub hoofdzakelijk met drie soorten actoren: zijn klanten, de andere hubs en de metahub. We onderscheiden dus drie standaardinteracties: de functionaliteiten ten behoeve van de klanten van de hubs, de functionaliteiten ten behoeve van de andere hubs en de interacties met de metahub.

3.1 Functionaliteiten ten behoeve van de klanten van de hubs 3.1.1

Opzoeking en raadpleging van documenten

Een hub moet aan zijn klanten de mogelijkheid bieden om het verwijzingsrepertorium te voeden en te raadplegen. Een hub moet met andere woorden toelaten om: •

aangifte te doen van een document met betrekking tot een patiënt door een aantal minimale gegevens, zoals de medische auteur van het document, op te geven;

•

de lijst van de referenties van documenten met betrekking tot een patiënt te raadplegen (door een aantal bijkomende zoekcriteria te ondersteunen, zoals de auteur of het type document bv. “onderzoeksresultaten” of “aankondiging van opname”).

De aangifte van een document kan slechts gebeuren als de patiënt zijn toestemming heeft gegeven aan het systeem en de raadpleging van de lijst van referenties kan slechts gebeuren als er een therapeutische relatie bestaat die deze raadpleging rechtvaardigt. Het is de taak van de hub om te controleren of deze twee voorwaarden wel degelijk vervuld zijn. Een hub moet zijn klant ook de mogelijkheid bieden om een document te verkrijgen op basis van een referentie. Het verkrijgen van dit document impliceert opnieuw dat de patiënt zijn toestemming heeft gegeven en dat er een therapeutische relatie bestaat. Elke toegang tot medische documenten (of tot de referenties) dient te worden geregistreerd. Een document kan ook op ieder ogenblik uit het verwijzingsrepertorium worden verwijderd.

3.1.2

Toestemmingen en therapeutische relaties

Ter ondersteuning van de opzoekings- en raadplegingsfunctionaliteiten moet het beheer van de toestemmingen van de patiënten en van de therapeutische relaties binnen een hub mogelijk zijn. Een hub moet dus toelaten om binnen het systeem aangifte te doen van het bestaan van een toestemming, het bestaan van een toestemming te controleren of een toestemming te herroepen. Een hub moet ook toelaten om aangifte te doen van een therapeutische relatie, het bestaan van een therapeutische relatie te controleren en een therapeutische relatie te herroepen. Het beheer van de therapeutische relaties, buiten de “institutionele" therapeutische relaties zoals het bestaan van een GMD, mag dan wel beperkt zijn tot het niveau van elke hub, het beheer van de toestemmingen moet echter op het globale niveau gebeuren. Een toestemming kan immers binnen een hub gecreëerd worden en herroepen worden binnen een andere hub.

3.1.3

Andere functionaliteiten

Iedere hub laat aan zijn klanten toe om de gerealiseerde toegangen tot de gegevens van een patiënt (in het volledige systeem) te raadplegen.


3.2 Functionaliteiten voor andere hubs 3.2.1


Om opzoekingen en raadplegingen in het volledige systeem toe te laten, dient elke hub aan de andere hubs dezelfde functionaliteiten aan te bieden. Een hub moet meer bepaald aan de andere hubs toelaten om: •

binnen de eigen hub de lijst van referenties van documenten m.b.t. een patiënt te raadplegen (door minimale zoekcriteria te ondersteunen die gedefinieerd zijn op het niveau van de functionaliteiten ten behoeve van de klanten van de hubs);

•

op basis van een referentie een document te verkrijgen dat opgeslagen is bij één van zijn klanten.

Wanneer een hub gebruik maakt van een dienst die aangeboden wordt door een andere hub, dient de hub-gebruiker te garanderen dat deze raadpleging gebeurt met de toestemming van de patiënt en in het kader van een therapeutische relatie. De controle van de eventueel bijkomende 6 restricties, bv. toegang beperkt tot één categorie van zorgverleners , op het niveau van het document wordt verzekerd door de hub die de dienst levert. Elke toegang tot medische documenten (of tot de referenties) dient te worden geregistreerd.

3.2.2


Elke hub laat de andere hubs toe om de gerealiseerde toegangen tot de gegevens van een patiënt (binnen de eigen hub) te raadplegen.

3.3 Interactie met de metahub 3.3.1


Bij een globale opzoeking van documenten zal de hub die de opzoeking verricht de metahub raadplegen om de andere hubs te identificeren die mogelijk kunnen verwijzen naar documenten met betrekking tot deze patiënt. Opdat de metahub deze functie zou kunnen vervullen, moet de hub die naar een document m.b.t. een patiënt verwijst een aangifte doen van een link met die patiënt op het niveau van de metahub . Een dergelijke link kan ook weer maar effectief zijn mits de toestemming van de patiënt. De metahub komt niet tussen in de routering van de documenten.

3.3.2

Toestemmingen en therapeutische relaties

De metahub dient als centraal punt voor wat het bestaan van een toestemming van de patiënt betreft. De metahub beperkt zich echter tot de registratie van de informatie die door de hubs geleverd wordt. Elke aangifte of herroeping van een toestemming op het niveau van een hub dient dus weerspiegeld te worden op het niveau van de metahub. De metahub slaat geen enkele informatie op met betrekking tot de therapeutische relaties. Er is echter voorzien dat het eHealth-platform een database ter beschikking stelt met betrekking tot de uitsluitingen op het niveau van de zorgverleners. Deze uitsluitingen kunnen worden beschouwd als een soort “negatieve therapeutische relaties”. Er kan dus worden overwogen om die raadpleegbaar te maken via de dienst "metahub", teneinde de hubs één enkele technische interface aan te bieden. Dit dient nog besproken te worden. De therapeutische relaties met betrekking tot het bestaan van een GMD zullen ook toegankelijk zijn via de basisdiensten van het eHealth-platform.

6

Bijvoorbeeld, het feit dat een document (uit de psychiatrie) enkel toegankelijk is voor psychiaters.


3.3.3


De metahub geeft iedere hub de mogelijkheid om de gerealiseerde toegangen tot de gegevens van een patiënt (hier beperkt tot de relaties met de hubs) te raadplegen.

3.4 Globaal proces Figuur 2 : Globaal proces geeft een grafische samenvatting van de voorgaande paragrafen in de vorm van een schematische weergave van het proces. 7

Dit schema toont de interacties tussen de verschillende actoren in het kader van een globale opzoeking van documenten (die zonder fouten verloopt). Het gaat hierbij enkel om een voorbeeld dat geenszins alle alternatieve of mogelijke varianten van implementatie (onder meer binnen elk netwerk) dekt. Het doel van het schema is enkel het verduidelijken van de concepten, maar is niet bepalend voor de uiteindelijke implementatie van het proces. In het voorbeeld van Figuur 2 : Globaal proces gaat men ervan uit dat een patiënt zich eerst begeeft naar ziekenhuis A1 dat aangesloten is bij hub A. Binnen dit ziekenhuis ondertekent hij een toestemming. Vervolgens begeeft hij zich voor een consultatie naar ziekenhuis B1, dat aangesloten is bij hub B. De zorgen die hij in ziekenhuis B ontvangt geven aanleiding tot de aangifte van een therapeutische relatie binnen hub B en tot de aangifte van een document in het verwijzingsrepertorium van deze hub. De patiënt begeeft zich vervolgens opnieuw naar ziekenhuis A1, hetgeen aanleiding geeft tot een aangifte van therapeutische relatie op het niveau van hub A. Naar aanleiding hiervan verricht de zorgverlener die de patiënt verzorgt een opzoeking met betrekking tot deze patiënt. Na raadpleging van de metahub wordt deze opzoeking door hub A voortgezet op het niveau van hub B. Op basis van de resultaten van deze opzoeking vraagt de zorgverlener om het door ziekenhuis B1 opgestelde document te raadplegen. Hub A stuurt dit verzoek door naar hub B, die op zijn beurt het verzoek aan ziekenhuis B1 doorstuurt. Dit ziekenhuis stuurt vervolgens het gevraagde document terug in zijn antwoord.

7

Dit schema maakt gebruik van de notering BPMN.

Datum: 26/05/2010 Pagina: 10

4 Technische elementen 8

Zonder in detail in te gaan op de technische specificaties , worden in dit hoofdstuk een aantal algemene principes uitgelegd die nageleefd dienen te worden bij de implementatie.

4.1 Uitwisselingsstandaarden Om een dergelijke architectuur te ondersteunen is het noodzakelijk om de technische interfaces te standaardiseren die de uitwisselingen tussen de verschillende actoren bepalen. De algemene regel is dat de technische interfaces geïmplementeerd worden via KMEHR-webservices. Meer bepaald zal een gemeenschappelijke technische interface worden gedefinieerd ter ondersteuning van de functionaliteiten die door een hub aan de andere hubs worden geboden (zie hoofdstuk 03.2.). Hetzelfde geldt uiteraard voor de dienst « metahub » die door het eHealth-platform geïmplementeerd wordt. De KMEHR-webservices zullen ook gedefinieerd worden om de communicatie tussen de hubs en hun klanten te standaardiseren. Deze webservices zullen als basis dienen voor het labelen van de medische software voor de huisartsen. Hoewel een hub de standaardfunctionaliteiten voor de klanten van een hub (zie hoofdstuk

03.1.) dient te ondersteunen, kan hij ervoor kiezen om intern geen gebruik te maken van de gemeenschappelijke berichtstructuur die hiervoor vastgesteld werd. Aangezien deze structuur gebruikt zal worden voor de uitwisselingen tussen hubs, zal een dergelijke hub de nodige technische conversies moeten voorzien. Wat dit betreft wijzen we erop dat de interfaces voor de huisartsen rekening zullen houden met deze gemeenschappelijke structuur. Een hub die geen gebruik maakt van de gestandaardiseerde interfaces zou a priori dus geen betrekking hebben op huisartsen.

4.2 Vercijfering 4.2.1

Principes

De primaire doelstelling van een hub is om een verwijzingsrepertorium te ontwikkelen voor de opzoeking van documenten met betrekking tot een patiënt, maar het is niet de bedoeling dat de hub de documenten opslaat waarnaar het verwijst. De opslag van medische documenten maakt dus geen deel uit van de standaardfunctionaliteiten van een hub. Het is a priori ook niet de taak van een hub om een medisch document te visualiseren. De hub staat in voor de beveiligde mededeling van het medische document maar houdt zich niet bezig met de uiteindelijke presentatie van dit document aan de zorgverlener. Deze functionaliteit is de verantwoordelijkheid van de "klant" van de hub (het ziekenhuis of de software van de huisarts). De primaire doelstellingen van een hub vereisen bijgevolg niet dat de hub toegang krijgt tot de medische inhoud van een document. De meest eenvoudige oplossing om de vertrouwelijkheid van de medische inhoud te waarborgen bestaat erin een systeem van end-to-end vercijfering te implementeren. Het spreekt evenwel voor zich dat de hubs die niet met KMEHR-webservices zullen werken ten behoeve van hun klanten, een dergelijk systeem niet zullen kunnen implementeren gelet op de technische conversies die ze zullen moeten ondersteunen. Deze hubs zullen dus de garanties inzake vertrouwelijkheid op organisatorisch niveau moeten verzekeren. 9

Concreet zal de inhoud van de uitwisselingen tussen hubs bij voorkeur end-to-end vercijferd zijn (bv. van ziekenhuis tot ziekenhuis). Als een hub "zonder vercijfering" tussenkomt bij een dergelijke uitwisseling zal de vercijfering en de ontcijfering ten laste van deze hub zijn en zal die hub via andere middelen de vertrouwelijkheid van het document moeten waarborgen.

8 9

Deze specificaties worden momenteel uitgewerkt door de werkgroep Architectuur. Het betreft hier enkel de medische inhoud van de uitwisselingen en niet de globale beveiliging van het systeem.

Datum: 26/05/2010 Pagina: 11

4.2.2

Middelen

In het kader van de vereenvoudiging en om te passen in een ruimere visie, zal er slechts een enkel systeem voor versleuteling gebruikt worden. Dit systeem zal gebruik maken van de oplossing opgesteld en ontwikkeld door het eHealth-platform, zodat elke zorgverlener (individu of organisatie) 10 die een document moet versleutelen slechts met één enkele technische specificatie geconfronteerd wordt. Aangezien sommige hubs het principe van ‘end to end’ versleuteling toepassen, en andere niet, moet de voorgestelde oplossing verschillende ‘dieptes’ van versleuteling ondersteunen. Bijvoorbeeld, een ziekenhuis binnen een hub die het principe ‘end to end’ versleuteling toepast, zal zowel berichten naar andere ziekenhuizen (end to end) moeten kunnen versleutelen, maar ook naar andere hubs. Het aanvaarden van dit systeem voor versleuteling hangt af van de garantie dat hetzelfde systeem zal gebruikt worden in de software van de huisartsen, in de ambulante voorschriften en in webservices toegankelijk via het eHealth-platform die omgaan met medische gegevens, zoals de webservices eCare, eBirth en Kankerregister.

10

Ter herinnering, het gaat hier enkel om versleuteling van medische gegevens op het berichtniveau, en niet om versleuteling op niveau van de transportlagen.

Datum: 26/05/2010 Pagina: 12

Patient consent

Patient consultation A1

Global Consultation of patient dossier

declares patient consent

declares therapeutic link

checks internal rights

Hospital A1

requests document list

proposes list of documents

requests document document selection

Network A

Hub A

stores patient consent

checks patient consent

declares patient consent

creates therapeutic link

checks therapeutic link

consult metahub

requests external document list

returns list of references

checks therapeutic link

forwards request to hub owner

stores patient consent flag


Metahub stores link

validates required attributes

returns patient - hub links

checks access rights stores document reference Hub B

creates therapeutic link

First patient publication

declares patient link

check access rights returns list of references


forwards request to document owner


Network B

declares therapeutic link

checks internal rights

Patient consultation B1

Publication of patient document

stores document

requests docume nt publication (with access rights)

provides document

Hospital B1

Figuur 2 : Globaal proces

proposes document

Werkgroep G19. Nota betreffende de doelstellingen en standaardfunctionaliteiten van een hub in de context van het project hubs-metahub

Recommend Documents