Project Start Architectuur aansluiting NCPeH op LSP

(Programma Implementatie Europese ZOrgdiensten, Piezo)

Inleiding

Nederland doet mee aan het de Europese eHealth infrastructuur. Hiervoor kunnen nu al een beperkt aantal zorgaanbieders de Europese versie van de patiëntsamenvatting opvragen van buitenlandse patiënten (uit een beperkt aantal landen) via de nationale NCPeH portal. Nederland wil nu ook graag regelen dat buitenlandse zorgaanbieders voor Nederlandse patiënten gegevens bij Nederlandse zorgaanbieders kunnen opvragen. 

Aanleiding

De huisartsensystemen bieden qua medische gegevens de meeste dekking voor het vullen van de European Patient Summary (ePS). Het LSP biedt de mogelijkheid veel van deze bronnen te bevragen, ook zonder dat de betreffende HIS'en (extra) aangepast dienen te worden. Daarom is gekozen om in de eerste fase van  Piezo (alleen) op het LSP aan te sluiten om zo gegevens beschikbaar te hebben die een groot deel van de ePS kunnen vullen.

Stakeholders

Het beschikbaar maken van medische gegevens doen we natuurlijk om in het buitenland Nederlandse patiënten een betere zorg te kunnen geven. Directe stakeholders in dit project zijn de partijen die dit mogelijk willen maken:

• VWS als opdrachtgever

• CIBG als beheerder van het NCPeH

• ICTU als opdrachtnemer om het NCPeH te bouwen

• VZVZ als beheerder van de AORTA-infrastructuur waarmee de gegevens naar het NCPeH ontsloten kunnen worden

• VZVZ als beheerder van toestemmingsregistratiesysteem Mitz, waarin de patiënt de toestemming voor uitwisseling van gegevens met Europa zou moeten vastleggen

• HIS-leveranciers die de gegevens van de huisarts gestructureerd ontsluiten en de koppeling moeten leggen met Mitz

• Huisartsen die hun patiënten te informeren over de mogelijkheid de dossiergegevens ook voor buitenlandse zorgaanbieders raadpleegbaar te maken

• Nictiz als maker van de standaarden voor HIS'en en verantwoordelijk voor de inhoudelijke mapping naar van Nederlandse standaarden naar de ePS.

Doelstelling

In 2026 dient het NPCeH en achterliggende systemen en organisaties klaar te zijn om een opvraag van de ePS door een buitenlandse zorgaanbieder succesvol te beantwoorden.

Scope

Om de doelstelling te behalen:

• Dienen de huisartsgegevens opvraagbaar te zijn door het NCPeH

• Dient het LSP op Mitz te zijn aangesloten

• Dienen de HIS-leveranciers de uitdrukkelijke toestemming via Mitz te beheren. Ten minste één HIS-leverancier geaccepteerd op LSP voor Mitz en huisartstoestemmingen gemigreerd naar Mitz

• Dienen de huisartsen (die dat willen) de toestemmingsregistratie naar Mitz gemigreerd te hebben

Andere zaken zoals

• Het vaststellen van het correcte BSN

• Het vertalen van de door het LSP opgeleverde gegevens naar de ePS

• Het informeren van patiënt over de mogelijkheid om toestemming in Mitz aan te passen voor Europa

zijn buiten scope voor de opdracht aan VZVZ.

Samenhang en afhankelijkheden met andere trajecten

• De koppeling van het NCPeH zou kunnen zal lopen via een variant van de GBO aansluiting die voor het RIVM wordt gebruikt.

Beleidsuitgangspunten

De directe meerwaarde die voor patiënten behaald kan worden is in het begin relatief klein. Vermoedelijk kan er met andere projecten al snel voor meer patiënten en zorgaanbieders meerwaarde gecreëerd worden. Dit zou inhouden dat de prioriteit t.o.v. deze projecten lager zou moeten liggen.

De belangrijkste kaders die bij het opstellen van de architectuur zijn gehanteerd als uitgangspunten, zijn: 

• De relevante Europese en Nederlandse wet- en regelgeving

• Beveiligingsnormen: NEN7510, NEN7512 en NEN7513 
  Het opvragen van gegevens ten behoeve van een Europese patiëntsamenvatting wordt geclassificeerd als een elektronisch uitwisselingssysteem volgens de wet aanvullende bepalingen verwerking persoonsgegevens in de zorg. Het Besluit elektronische gegevensverwerking door zorgaanbieders schrijft voor dat de verantwoordelijke voor het uitwisselingssysteem en de betrokken zorgaanbieders moeten voldoen aan de NEN7510, NEN7512 en NEN7513.

• De afspraken die op Europees niveau zijn gemaakt en die zijn vervat in de specificaties van MyHealth@EU, met name de requirements uit die specificaties. 

Architectuurprincipes

Principes van Piezo

• Principe 1: Gebruik maken van wat er al is 

• Principe 2: Aansluiten op bestaande nationale en internationale ontwikkelingen 

• Principe 3: Open koppelvlakken op basis van open standaarden 

• Principe 4: Implementatie in stappen 

Principes van AORTA

Hieronder staan de generieke VZVZ principes en die van AORTA waarop mogelijk afgeweken wordt:

Zie Principes

• VZVZ.GEN.P110 Een stelsel of voorziening bevat een vertrouwensmodel. Het MyHealth@EU-netwerk kent een eigen vertrouwensmodel en voldoet aan het principe. Voor de uitwisseling tussen NCPeH en het LSP zou het vertrouwensmodel van AORTA moeten gelden, maar dat kan niet geheel ingevuld worden zoals binnen AORTA is afgesproken. Op basis van het Europese vertrouwensmodel moeten we kijken wat we wel en niet kunnen invullen van het AORTA-vertrouwensmodel. Later in het project zal er een besluit gevraagd moeten worden om van het AORTA-vertrouwensmodel af te wijken.

• VZVZ.GEN.P120 Het koppelen van verschillende vertrouwensdomeinen vergt een overeengekomen groeipad. Dit niet mogelijk. Europa trekt haar eigen pad. Hier kunnen we of moeten we zelfs in meegaan.

• VZVZ.GEN.P150 Privacy by design & Zero Trust. Dit wordt natuurlijk zo goed als mogelijk ingevuld, maar van een aantal zaken die hieronder genoemd worden, zoals end-to-end encryption, zijn technisch niet mogelijk.

• VZVZ.GEN.P170 Gebruikers (of hun vertegenwoordigers) zijn middels de governance medeverantwoordelijk voor het beheer en de doorontwikkeling van de voorzieningen. VWS en CIBG als opdrachtgever en uitvoerder van het NCPeH zitten (nog) niet in de governance van VZVZ.

• VZVZ.GEN.P180 Open speelveld en keuzevrijheid. Hier wordt niet aan voldaan omdat er afspraken gemaakt worden over het gebruik van diensten: het NCPeH als dé poort naar Europa en Mitz als dé voorziening voor het registreren en controleren van toestemmingen.

• VZVZ.AORTA.P1000 Het is voor de burger transparant welke gegevens tussen welke zorgaanbieders is uitgewisseld. In de logging van het LSP en NCPeH wordt opgenomen welke partij de gegevens raadpleegt, maar hierbij ben je afhankelijk van de gegevens die het raadplegende land meestuurt. Daardoor is het mogelijk dat het voor de burger niet compleet duidelijk is welke partij nu de gegevens heeft verwerkt. Onderzocht wordt nog of het NPCeH deze gegevens ook wel naar het LSP kan meesturen of dat de burger afhankelijk wordt van de transparantie die het NCPeH gaat bieden.

Oplossing

Organisatie en Beleid

Deze laag in het interoperabiliteitsmodel heeft betrekking op de beleidsmatige en organisatorische kant van de samenwerking tussen de betrokken (zorg)organisaties: wie zijn er bij de samenwerking betrokken en hoe zijn verantwoordelijkheden en bevoegdheden gedefinieerd? En welke beleidskeuzes worden gemaakt?  

Actoren en rollen 

Onderstaande figuur toont een overzicht van actoren en rollen en de wijze waarop in operationele zin samengewerkt wordt. Merk op dat ‘voorzieningen’ voor de herkenbaarheid in de figuur zijn weergegeven als business collaborations, ook als er feitelijk maar een beherende organisatie is. 

De figuur laat zien dat we bij plateau 1 kiezen voor het ontsluiten van patiëntdossiers via het LSP, waardoor we ons in dit plateau beperken tot huisartsdossiers. Wanneer in een volgend plateau andere bronnen gebruikt zullen worden, dan zal dat in deze figuur toegevoegd worden. NB: Het is nog niet bekend is welke BSN-bron gebruikt zal worden; daarom is dat in deze versie van de figuur nog in abstracte termen verwoord. 

Domeinen en programmaverantwoordelijkheden

We gebruiken de verschillende beheer-rollen in bovenstaande figuur als uitgangspunt voor het definiëren van domeinen. Onder ‘domein’ verstaan we hier een afgebakende eenheid binnen de architectuur waarvoor de verantwoordelijkheid bij een specifieke deelnemer in het programma belegd kan worden. Dat wil zeggen dat de desbetreffende programmadeelnemer de verantwoordelijkheid draagt voor ontwerp en realisatie van de componenten die binnen het domein vallen, alsmede voor het inrichten van de koppelvlakken die (de componenten binnen) het domein verbinden met (de componenten binnen) de andere domeinen. 

Op basis van bovenstaande onderkennen we de volgende domeinen: 

In deze tabel zijn het Ministerie, Nictiz en ICTU niet genoemd. Deze deelnemers hebben wel programmaverantwoordelijkheden maar geen operationele verantwoordelijkheden en zijn daarom niet in bovenstaande figuur opgenomen. 

Qua verwerkersverantwoordelijkheden ligt het iets anders. De stichting Gemeenschappelijke Voorzieningen voor Zorgcommunicatie is/wordt verwerkingsverantwoordelijke voor de (categorale) toestemmingen van de burgers. De verwerkingsverantwoordelijkheid voor een bronsysteem ligt bij de individuele zorgaanbieder. De verwerkingsverantwoordelijkheid voor de gegevensverwerking in het LSP zal mogelijk nog veranderen. Momenteel wordt VZVZ als verwerkingsverantwoordelijke gezien, maar met de komst van Mitz zou het LSP zo ingericht kunnen worden dat de gegevensverwerking altijd namens de zorgaanbieder die een bronsysteem beheert of de verwerkingsverantwoordelijke van een raadplegend systeem (in dit geval het is het CIBG verantwoordelijke van het NCPeH-NL).  

Beleid met betrekking tot identificatie 

Beleid met betrekking tot identificatie van patiënten 

Binnen Nederland is bepaald dat het burgerservicenummer (BSN) wordt gebruikt binnen de zorg als identificatie van patiënten. Dit nummer is ook opgenomen op de identiteitsdocumenten (met name paspoort en identiteitskaart) en de Europese zorgverzekeringspas (EHIC) waarmee patiënten zich voor behandeling melden bij een zorgaanbieder in het buitenland. Het burgerservicenummer (BSN) zal gebruikt worden ter identificatie van de patiënt. 

De patient summary usecase voorziet in de mogelijkheid (en tevens verplichting) voor de buitenlandse zorgverlener om de identiteit van de patiënt te controleren. Hiervoor is een gestandaardiseerde interactie beschikbaar die door elk A-land geïmplementeerd dient te worden. Elk A-land kan daarbij zelf definiëren welke persoonsgegevens uitgewisseld worden. 

De eenvoudigste implementatie is die waarbij de buitenlandse zorgverlener een BSN invoert en verstuurt, en de geretourneerde aanvullende persoonsgegevens vergelijkt met de persoonsgegevens op het identiteitsbewijs van de patiënt. 

Om te voorkomen dat bij het invullen van een verkeerd BSN, persoonsgegevens van een ander dan de beoogde patiënt geretourneerd worden, voegen we een controleveld toe. Voorstel is hiervoor de geboortedatum van de patiënt te kiezen. Aanvullende persoonsgegevens worden dan alleen geretourneerd wanneer BSN en geboortedatum bij elkaar passen. 

Beleid met betrekking tot identificatie van zorgverleners en zorgaanbieders

Aangezien opvragingen van de patient summary gedaan worden vanuit het buitenland door buitenlandse zorgverleners, zal het opvraagbericht ook een buitenlandse zorgverleneridentificatiecode bevatten. Welke identificatiecode gebruikt wordt zal per land verschillen. De code dient ten behoeve van verantwoording en transparantie naar de patiënt wel vastgelegd te worden in de logs, maar is verder in het systeem niet bruikbaar voor bijvoorbeeld autorisatiedoeleinden. 

Hetzelfde geldt voor identificatie van de zorgaanbieder van waaruit de opvraging gedaan wordt. 

Beleid met betrekking tot toestemming 

Vooralsnog gaan we uit van toestemming als grondslag voor het uitwisselen van patiëntgegevens in het kader van de patient summary usecase. Bij toestemming maken we onderscheid tussen toestemming gegeven door de patiënt aan dossierhoudende zorgaanbieders, aan het NCPeH en aan de behandelende zorgaanbieder. 

NCPeH 

De NCPeH's zijn op Europees niveau aangewezen als verwerkingsverantwoordelijke voor het verwerken van patiëntgegevens in het kader van MyHealth@EU. Dit betekent dat ook hier een geldige grondslag benodigd is. 

Behandelende zorgaanbieder 

De behandelende zorgaanbieder bevindt zich in een andere EU-lidstaat. Dat betekent dat de Nederlandse wetgeving daar niet van toepassing is, maar wel de Europese regelgeving. Er moet sowieso een geldige grondslag zijn voor het verwerken van de medische gegevens van de patiënt. Er zijn verschillen tussen landen. Ruwweg zijn er twee mogelijkheden bij het opvragen van de patient summary: in sommige landen is een grondslag in nationale regelgeving geregeld. In andere landen is (ter plaatse gegeven) toestemming van de patiënt noodzakelijk. Dat zal dan in het desbetreffende land georganiseerd worden; onze architectuur hoeft daar niet in te voorzien. 

Beleid met betrekking tot Autorisatie 

In het Europese afsprakenstelsel van MyHealth@EU zijn zorgaanbiedercategorieën gedefinieerd van waaruit de patient summary mag worden opgevraagd, beroepsgroepen (rollen) die de opvraging mogen doen, en de dataset van de patient summary die bepaalt welke gegevens opgeleverd worden. 

In het Nederlandse zorgstelsel zijn door de koepelorganisaties van beroepsgroepen richtlijnen opgesteld in de vorm van autorisatietabellen.  Deze worden bij uitwisseling van gegevens via het LSP geëffectueerd in de software van het LSP, zodat geen gegevens uitgewisseld worden die volgens de richtlijnen voor de opvrager niet toegankelijk zijn. De inhoud van de uit te wisselen dataset kan variëren met de rol van de opvrager.  

Uitgangspunt voor dit programma is dat we voor de Europese uitwisseling willen aansluiten bij wat er al voor binnenlandse uitwisselingen is geïmplementeerd.  

Autorisatie zal worden gedaan op basis van rol/functie en organisatietype van de opvragende zorgverlener/zorgaanbieder, waarbij deze gegevens geconverteerd worden naar de best passende Nederlandse equivalenten teneinde aan te sluiten bij de Nederlandse praktijk. 

Zorgprocesssen

Proces behandelen patiënt 

Het opvragen en gebruiken van de patient summary vindt plaats tijdens het zorgproces van behandelen van de patiënt. Dit proces wordt uitgevoerd in het ziekenhuis (of een ander type zorginstelling) in een ander Europees land dat is aangesloten op MyHealth@EU. Het proces in is hoofdlijnen weergegeven in onderstaande figuur. De bovenste helft toont het verloop van het zorgproces, de onderste helft toont welke interacties er in dat proces (kunnen) plaatsvinden tussen de zorginstelling en het NCPeH in het land van behandeling. 

Na binnenkomst van de patiënt worden diens gegevens geregistreerd in de administratie van de zorginstelling. Vervolgens start de behandeling. Daarbij zal de behandelende zorgverlener beoordelen of het voor de behandeling gewenst is om gegevens van de patiënt (in de vorm van de patient summary) op te vragen. Dit is niet altijd nodig. Richtlijnen hierover kunnen per land verschillen.  

Wanneer tot opvragen besloten wordt, zal eerst de patiënt hierover geïnformeerd worden. Elk land heeft daartoe een patient information notice (PIN) opgesteld. Daarin wordt toegelicht welke gegevens opgevraagd worden, wat daarmee gedaan wordt, en welke rechten de patiënt heeft. Afhankelijk van de wetgeving in het land van behandeling is mogelijk instemming van de patiënt vereist. 

Om de patient summary te kunnen opvragen zal de zorgverlener (of een daarvoor gemachtigde medewerker) eerst de identificerende gegevens van de patiënt moeten controleren. Dit gebeurt door een of enkele identificerende persoonsgegevens in te voeren in het systeem. Het systeem antwoordt vervolgens met aanvullende persoonsgegevens. Wanneer die aanvullende persoonsgegevens overeenkomen met gegevens op het identiteitsdocument van de patiënt, mag de zorgverlener de identificerende gegevens gebruiken. Wanneer niet op deze wijze een match gemaakt kan worden, dan is de patiënt niet (of niet uniek) geïdentificeerd. Opvragen van patiëntgegevens leidt dan mogelijk tot geen resultaat of tot gegevens van de verkeerde patiënt; dat moet voorkomen worden. Opvragen van de patient summary mag daarom alleen wanneer er sprake is van een unieke match. 

Het opvragen van patiëntgegevens gebeurt, afhankelijk van implementatie in het land van behandeling, in een of twee stappen. In de tweestapsvariant vraagt de zorgverlener eerst welke soorten documenten voor de patiënt opgevraagd kunnen worden (patient summary, eprescription of nog anders; in Nederland ondersteunen we vooralsnog alleen de patient summary), en kiest daarna voor het gewenste document wanneer dat beschikbaar is. In de eenstapsvariant vraagt de zorgverlener direct om de patient summary. Op de achtergrond is in beide gevallen sprake van twee technische interacties maar in het ene geval is dat onzichtbaar voor de zorgverlener. 

Nadat de patient summary is opgevraagd, kan deze door de zorgverlener bestudeerd worden. Er zijn voor hem/haar twee versies van de patient summary beschikbaar; een originele versie en een ‘vertaalde’ versie waarin de gebruikte codes en labels van het A-land omgezet zijn naar codes en labels die in het B-land gebruikt worden en die voor de behandelende zorgverlener begrijpelijk zijn. De originele versie kan de zorgverlener eventueel aan de patiënt overhandigen, wat het gesprek tussen zorgverlener en patiënt vergemakkelijkt. Het omzetten van de gebruikte codes gebeurt geautomatiseerd tijdens de opvraging en is een samenwerking tussen de systemen in het A-land en het B-land: het A-land transcodeert van de eigen codestelsels naar een “pivot”-formaat; het B-land transcodeert van het pivot-formaat naar de eigen codestelsels. 

Na de behandeling kan de patient summary bij het patiëntdossier in de administratie opgenomen worden. 

Proces toestemming geven/beheren

Voorwaardelijk voor het kunnen opvragen van de patient summary is dat de patiënt op een eerder moment toestemming heeft vastgelegd aan de dossierhouder voor het beschikbaar stellen van gegevens ten behoeve van de patient summary. Zie ook de paragraaf over toestemming.  

In dit programma gaan we uit van het gebruik van de toestemmingsvoorziening Mitz. Dat betekent dat burgers op een voor hen geschikt moment toestemming kunnen vastleggen, aanpassen en weer intrekken, met behulp van een online toestemmingsvoorziening in de vorm van de website MijnMitz.nl. De werkwijze is beschreven in de documentatie van Mitz. 

Processen beheer

Bij beheerprocessen maken we onderscheid tussen technisch beheer, regulier functioneel beheer en projectmatig beheer.  

Technisch beheer 

Het technisch beheer van de diverse componenten in de oplossing zal belegd worden bij de beherende partijen. Het is nadrukkelijk de bedoeling dat zij voor technisch beheer aansluiten bij de eigen processen. 

Regulier functioneel beheer 

Dit betreft met name: 

• Reageren op incidentmeldingen 
  Dit betreft bijvoorbeeld het uitzoeken wat de oorzaak is van het wegvallen van verbindingen of het niet aankomen van berichten. Van belang is dat hierbij goede afspraken gemaakt worden tussen de ketenpartijen over bereikbaarheid en de wijze waarop samengewerkt wordt bij het analyseren van foutsituaties. 

• Reageren op inzageverzoeken van patiënten 
  Dit betreft vragen van patiënten naar aanleiding van opvragingen van de patient summary. 

• Beheren tabellen 
  Dit betreft het bijwerken van diverse tabellen die nodig zijn voor de werking van het systeem. Hieronder vallen ook de MVC en mappingtabellen van zorgaanbiedertypen en beroepscategorieën. 

• Genereren rapportages 
  Dit betreft het samenstellen van rapportages ten behoeve van managementinformatie, waaronder begrepen de rapportages ten behoeve van ”Europa”. 

Voor bovenstaande beheeractiviteiten geldt dat we zoveel mogelijk gebruik willen maken van al bestaande procedures bij de ketenpartijen. Waar mogelijk willen we zaken automatiseren. 

Projectmatig beheer 

Taken die niet op reguliere basis uitgevoerd worden zijn bijvoorbeeld het testen en aansluiten van nieuwe landen of het invoeren van nieuwe releases van de OpenNCP-software. Dit soort activiteiten zullen op een projectmatige wijze worden uitgevoerd. 

Processen inzage patiënt 

Patiënten moeten inzage kunnen krijgen in de uitwisseling van hun gezondheidsgegevens. CIBG heeft besloten om via papieren formulieren inzagerecht te regelen. In een volgend plateau zal gekeken worden naar een portaal.

Informatie

Identificerende gegevens patiënt / zorgverlener / zorgaanbieder   

Het opvraagbericht dat NCPeH-NL ontvangt van het NCPeH-B bevat de volgende identificerende gegevens van de opvragende zorgverlener (HP – Health Professional) en zorgaanbieder (HCPO - Health Care Provider Organisation):  

• HP - Volledige naam (verplicht) 

• HP - National Provider Identifier – a unique identifier assigned to healthcare providers by their national authority  (optioneel) 

• HP - Structural role (verplicht) 

• HP - Functional role (verplicht) 

• HCPO -  Organization ID (verplicht) 

• HCPO -  Organization Name (optioneel) 

• HCPO - Type HCP Organization (verplicht)  

Bron: SAML Profile v6.2.0 

 Informatiestandaard voor ontsluiten gegevens huisartsdossier  

Voor de realisatie van PS-A plateau 1 is het uitgangspunt dat we gebruik maken van bestaande koppelingen en informatiestandaarden binnen het huisartsendomein. Omdat er binnen dit domein meerdere informatiestandaarden beschikbaar zijn, is een matrix met vergelijkingsaspecten opgesteld om tot een onderbouwde keuze te komen. Hierin zijn de relevante informatiestandaarden opgenomen (Huisartswaarneming (HWN), Ketenzorg (KeZo) en Acute Zorg) en een in ontwikkeling zijnde standaard (HWN  nieuwe stijl). Deze matrix inclusief afwegingen is beschikbaar in een separaat decision record. 

 De huisarts-informatiestandaarden zijn (met uitzondering van de wat oudere HWN standaard) gebaseerd op (zorginformatie)bouwstenen. Naast informatiestandaarden kent het LSP ook het begrip ‘zorgtoepassing’. Ketenzorg, acute zorg en huisartswaarneming zijn naast informatiestandaarden ook zorgtoepassingen. De dataset en de techniek zijn dezelfde, maar een zorgtoepassing legt een extra filter (op gegevenselementen en tijd) op de uiteindelijk geleverde informatie.  Deze filtering wordt op het LSP toegepast.  

 Op grond van vergelijking van de aspecten is een informatiestandaard gebaseerd op bouwstenen (=duurzame informatiestandaard) en HL7-CDA (=relatief duurzaam, en nu goed aansluitend op de Europese specificaties van MyHealth@EU) een goede oplossing. Daarbij lijkt het zuiver (conceptueel consistent) om een aparte zorgtoepassing te maken voor de uitwisseling van de EU-patient summary.  Daarmee kan de autorisatie en de historie-tijd expliciet voor deze uitwisseling worden bepaald en meebewegen met toekomstige veranderingen (waves), onafhankelijk van de bestaande zorgtoepassingen. Nadeel is wel dat de HIS’en zich mogelijk opnieuw moeten kwalificeren voor deze nieuwe zorgtoepassing (vanuit Nictiz gezien). Omdat de interface voor een ander doel dan bedoeld gebruiken van een zorgtoepassing (conceptuele consistentie) vindet men dit een zwaarwegend argument voor herkwalificatie. Omdat deze aparte zorgtoepassing gebruik maakt van bestaande bouwstenen hoeft de software niet aangepast te worden en zal de kwalificatie naar verwachting beperkte inspanning vergen. Echter vanaf het begin af aan heeft VZVZ ketenzorg zo ingestoken dat de partijen niet opnieuw hoeven te kwalificeren voor een nieuwe toepassing. Voor Mitz moeten de bronsystemen sowieso wel opnieuw kwalificeren. Aan VZVZ en Nictiz de taak om het voor de leveranciers zo makkelijk mogelijk te maken als er in de bouwsteeninterface toch geen wijzigingen zijn.

Samenstellen patient summary 

De patient summary als document is in Nederland geen bestaand document dat direct uit een informatiesysteem opgehaald kan worden. Het zal daarom moeten worden samengesteld uit een collectie van patiëntgegevens uit een of meerdere bronnen.   In dit programma (plateau 1) zal de patient summary worden samengesteld uit gegevens die opgehaald worden via het Landelijk Schakelpunt, dit zijn met name gegevens uit huisartssystemen. In het zeldzame geval dat een patiënt meerdere huisartsen heeft, bestaat de kans dat het LSP berichten uit meerdere bronnen aanlevert.

Besluit: Het samenstellen van de patient summary vanuit meerdere bronnen is een complex vraagstuk en zal pas in plateau 2 aangepakt worden. 

Nictiz zal een beschrijving leveren waarin per dataelement van de patient summary dataset zal worden gespecificeerd of en hoe dit gevuld moet worden met data uit de bij bronsystemen opgehaalde gegevens. Deze beschrijving bevat mappings en rekenregels (bijvoorbeeld het samenstellen van de achternaam uit naam en voorzetsel). Het streven is zo weinig mogelijk rekenregels toe te passen op het NCPeH, om mogelijke fouten in interpretatie te voorkomen. Dit betekent dat eventuele inconsistenties in de aangeleverde data niet gecorrigeerd worden. De interpretatie daarvan wordt overgelaten aan de behandelende zorgverlener. Dit is in lijn met hoe andere zorgtoepassingen hiermee omgaan. 

Bij elke nieuwe wave (versie/release) van de patient summary zal ook een nieuwe versie van de mappingtabel opgeleverd moeten worden. 

Vertalen en/of transcoderen patientsummary 

In de usecase PS-A vindt in Nederland geen vertaling plaats. Er vindt een mapping en zo nodig transcodering plaats vanuit de door het LSP aangeleverde berichten naar het format van de patient summary door het NCPeH. Het format bevat internationale coderingen. In het ontvangende land (land B) vindt de vertaling plaats vanuit de internationale coderingen naar de eigen taal. 

Toestemmingsgegevens 

Vastleggen van toestemming 

Voor het vastleggen en controleren van toestemming voor de patient summary usecase sluiten we aan bij het toestemmingsmodel van Mitz. In dat model bestaat een toestemming uit drie onderdelen: 

1. Eén of meer zorgaanbieders of categorieën van zorgaanbieders aan wie toestemming gegeven wordt om gegevens beschikbaar te stellen; 

2. Eén of meer typen van gegevens die gedeeld mogen worden. Dit betreffen behandelgegevens, medicatiegegevens en uitslagen. 

3. Eén of meer categorieën van zorgaanbieders waarmee die gegevens gedeeld mogen worden. 

 Toestemming heeft pas effect als een dossierhouder binnen de eerste zorgaanbiedercategorie bij Mitz in het abonnementenregister heeft aangegeven een dossier te hebben. De volgende dossierhoudende zorgaanbiedercategorieën zijn in Mitz gedefinieerd: 

• Huisartsen en huisartsenposten 

• Ziekenhuizen, medische centra, klinieken 

• Laboratoria en diagnostische centra 

• Geestelijke gezondheidszorg (GGZ) 

• Verpleging en verzorging 

• Apotheken 

• Overige zorg (tandartsen, paramedici, jeugdgezondheidszorg) 

 Nog te bepalen is hoe we de Europese dimensie hierin onder brengen. Mogelijkheden zijn: 

• Geen onderscheid maken. Een toestemming geldt dan altijd voor zowel Nederlandse als buitenlandse zorgaanbieders. Dit is de eenvoudigste oplossing, maar deze doet geen recht aan de verwachte wens vanuit de patiënt/burger om dit onderscheid wel te kunnen maken. 

• Europa als aparte zorgaanbiedercategorie. Daarmee kan onderscheid worden gemaakt tussen binnenlandse en buitenlandse uitwisseling, maar onderscheid tussen zorgaanbiedertypen geldt alleen binnen Nederland. 

• Europa als apart ‘vinkje’. Dit vereist een aanpassing binnen Mitz. Voordeel is dat het onderscheid tussen zorgaanbiedertypen dat de patiënt maakt zowel binnen als buiten Nederland blijft gelden. 

• De oplossingsrichting waar nu naar gekeken wordt is een aanvullende toestemmingsvraag met tijdsperiode en per land toestemming kunnen geven. Het land moet daarom ook meegenomen worden in koppelvlak met NCPeH-NL

Controleren van toestemming 

Om bij een opvraging van de patient summary te controleren of de patiënt een ‘passende’ toestemming heeft vastgelegd, moeten de gegevens van de opvraging gematcht worden met de vastgelegde toestemming. In de opvraging worden twee relevante metagegevens  doorgegeven (bron: eHDSI_SAML_Profile_v6.1.0.OR.pdf): 

• Type of HCPO:  

• "Hospital", 

• "Resident Physician", 

• "Pharmacy",  

• "Other" 

• Functional role of the HP 

• Medical doctors 

• Nursing professionals 

• Midwifery professionals 

• Pharmacists 

• Pharmaceutical technicians and assistants 

• Dentists 

• Physiotherapists 

• Dieticians and nutritionists 

• Audiologists and speech therapists 

• Optometrists and ophthalmic opticians 

• Medical imaging and therapeutic equipment technicians 

• Health professionals not elsewhere classified  

• Other Clerical Support Workers 

De Type of HCPO zou als volgt gemapt kunnen worden op de raadplegende zorgaanbiederscategorieën in Mitz: 

Het mappen van ‘Other’ op GGZ etc. lijkt juist, maar is dit niet. De burger in Nederland geeft expliciet wel of geen toestemming aan deze zorgaanbiedercategorie. De buitenlandse zorginstelling, horend bij ‘Other’ kan van alles zijn, is eigenlijk ongedefinieerd. Dus per definitie niet te mappen naar een specifieke toestemming.  

Zoals eerder in deze paragraaf is aangegeven, bestaat een toestemming uit 3 onderdelen: Toestemming aan de dossierhouder om gegevens te delen, toestemming voor welke gegeven gedeeld mag worden en toestemming aan wie de gegevens gedeeld mogen worden. 

Voor plateau 1 gaat het om informatie uit het huisartsendossier. Deze gegevens kunnen alleen opgeleverd worden als een burger een toestemming heeft vastgelegd voor de dossierhoudende zorgaanbiedercategorie ‘Huisartsen en huisartsenposten’ in combinatie met één van de "ondersteunde" (te mappen)  raadplegende zorgaanbiedercategorieën. 

Daarnaast heeft een burger ook de mogelijkheid om ook individuele toestemmingen vast te leggen (aan een specifieke zorgaanbieder). Indien dit het geval is, kijkt Mitz alleen naar deze individuele toestemming en negeert de categorale toestemming. De werking is verder hetzelfde: in plaats van dat Mitz kijkt naar de toestemming van de dossierhoudende categorie, kijkt Mitz naar de toestemming voor de desbetreffende dossierhoudende zorgaanbieder (voor plateau 1 is dit een individuele huisartsenpraktijk). 

Bovenstaande uitgangspunten leveren het volgende resultaat op: 

• Allereerst checkt Mitz of de burger toestemming heeft gegeven om zijn huisartsgegevens te delen (als categorie of via individuele toestemming.  

• Vervolgens checkt Mitz of de burger toestemming heeft gegeven voor het delen van behandelgegevens. De patient summary valt hieronder.  

• Als de EU-aanvrager van het type HCPO ‘Hospital’ is, wordt in Mitz gecheckt of de patiënt toestemming heeft vastgelegd voor de raadplegende zorgaanbiedercategorie ‘Ziekenhuizen, medische centra, klinieken, laboratoria en diagnostische centra’ 

• Als de EU-aanvrager van het type HCPO ‘Resident Physician is, wordt in Mitz gecheckt of de patiënt toestemming heeft vastgelegd voor de raadplegende zorgaanbiedercategorie ‘Huisartsen en huisartsenposten’ 

• Als de EU-aanvrager van het type HCPO ‘Pharmacy is, wordt in Mitz gecheckt of de patiënt toestemming heeft vastgelegd voor de raadplegende zorgaanbiedercategorie ‘Apotheken’ 

• Als de EU-aanvrager van het type HCPO ‘Other’ is stopt het proces.   

Mitz

• Besloten moet worden of het NPCeH nu al een interface met Mitz moet bouwen (open toestemmingsvraag). Op programmaniveau is het besluit genomen om in plateau 1 Mitz via LSP te raadplegen en niet direct NCP aan te sluiten op Mitz (mogelijk wel in plateau 2). De reden om dit wel nu te doen zou zijn dat wanneer er geen toestemming is er ook geen vraag meer aan het LSP gesteld hoeft te worden: dataminimalisatie. Daarbij zal het NCPeH wanneer het in de toekomst meerdere uitwisselingsdomeinen raadpleegt sowieso eerst Mitz moeten raadplegen.

• Mitz moet gaan bepalen hoe een toestemming voor Europa er uit moet komen te zien. Problematisch wordt mogelijk het feit dat het NCPeH niet goed het organisatietype weet van de raadplegende buitenlandse zorgaanbieder. Wel weet het de rol van de betreffende zorgverlener.

Autorisatiegegevens 

In het Europese afsprakenstelsel van MyHealth@EU is bepaald dat de patient summary opgevraagd mag worden door zorgverleners met een functie/rol uit een beperkte set van rollen. Binnen die set wordt geen onderscheid gemaakt in welke onderdelen van de patient summary voor hen toegankelijk zijn. Dit mechanisme wijkt af van de wijze waarop in Nederland autorisatie wordt toegepast. 

In Nederland wordt de medische autorisatierichtlijn gehanteerd die bepaalt welke beroepsgroep welke informatie mag inzien. Deze richtlijn is verwerkt in een autorisatiematrix die op het LSP als filter wordt toegepast binnen de zogenaamde zorgtoepassingen.  

Applicatie

De applicatielaag beschrijft de componenten die we in de architectuur onderkennen en de samenhang daartussen. De beschrijving omvat de vereiste functionaliteit voor elke component en de eigenschappen van de koppelvlakken (applicatieservices) tussen de componenten. Het onderstaande schema - in Archimate notatie - geeft deze applicatielaag weer met in lichtgrijs de domeinen die verantwoordelijk zijn voor realisatie en beheer van de applicatiecomponenten. 

Applicatiecomponenten 

NCPeH 

Het Nederlandse National Contact Point for e-Health (NCPeH-NL) is de centrale component binnen de Nederlandse infrastructuur. Deze component ontvangt opvragingen vanuit het B-land en verwerkt en beantwoordt deze vervolgens. 

Geboden applicatieservices 

Het NCPeH-NL biedt conform het MyHealth@EU afsprakenstelsel drie applicatieservices aan het NCPeH in het B-land: 

• het valideren van de identiteit van de patiënt; 

• het opvragen van een lijst met beschikbare documenten; 

• het opvragen van de patient summary van de patiënt. 

Naast deze drie primaire applicatieservices biedt het NCPeH-NL nog drie secundaire applicatieservices: 

• het uitvoeren van beheertaken; 

• het bieden van inzage in de logging aan de patiënt. 

• Het bieden van inzage in de patient summary van de patient 

Gebruikte applicatieservices 

Om de opvragingen vanuit Europa te kunnen beantwoorden, maakt het NCPeH-NL gebruik van applicatieservices van andere componenten.  

• Voor het controleren van de patiëntidentiteit raadpleegt NCPeH een BSN-bron. 

• Voor het ophalen van relevante patiëntgegevens raadpleegt NCPeH het LSP. 

• Vooralsnog, zeker voor plateau 1, zal het LSP de toestemmingen controleren bij Mitz. 

Applicatiefuncties 

De NCPeH component bevat functies voor het opvangen en verwerken van requests van land B en het opvangen en verwerken van responses van de gebruikte applicatieservices. Daarnaast bevat de NCPeH component functies voor: 

Samenstellen patient summary uit de gegevens die het uitwisselingssysteem LSP aanlevert*. 

• Vertalen/ranscoderen van de patient summary naar het Europese pivot formaat. 

 Niet in scope voor plateau 1 maar naar verwachting wel in toekomstige plateaus: 

Controleren van de toestemming van de patiënt bij de online toestemmingsvoorziening Mitz.*  

*Gegevens opvragen bij dossierhoudende zorgaanbieders die niet aangesloten zijn op het LSP. NCPeH zal deze zorgaanbieders dan rechtstreeks of via een ander knooppunt bevragen.  

Het NCPeH is dus de component waar alle medische gegevens uit dossiers samenkomen. Het NCPeH zal derhalve de applicatiefunctie bevatten die de patient summary samenstelt uit de aangeleverde brongegevens. 

Het samenstellen van de patient summary uit gegevens aangeleverd door de bronsystemen zal plaatsvinden in het NCPeH. 

BSN-bron 

De BSN-bron ondersteunt het valideren van de patiënt-identiteit door het verstrekken van een beperkte set persoonsgegevens ter vergelijking met het identiteitsbewijs van de patiënt. 

Geboden applicatieservices 

• Opvragen persoonsgegevens o.b.v. enkele sleutelgegevens. 

Gebruikte applicatieservices 

We willen gebruik maken van een bestaande dienst. De interne werking daarvan is voor deze architectuur niet relevant. 

Applicatiefuncties 

We willen gebruik maken van een bestaande dienst. De interne werking daarvan is voor deze architectuur niet relevant. 

Opmerking: de keuze voor bsn-bron moet nog gemaakt worden. 

LSP 

Het Landelijk Schakelpunt (LSP) is in plateau 1 de enige uitwisselingsinfrastructuur vanuit waar het NCPeH gegevens opvraagt om de European Patient Summary (ePS) op te stellen. Het LSP ontsluit hiervoor de huisartsinformatiesystemen (HIS) via de zgn Generieke Query. In deze query wordt als parameter de ePS meegegeven. In het LSP is geconfigureerd uit welke ZIBs (bouwstenen) de ePS bestaat. Het LSP vraagt bij Mitz op bij welke bronnen er toestemming is om de ePS te raadplegen en vervolgens worden deze bronnen via bouwsteenqueries voor iedere van toepassing zijnde ZIB opgevraagd. Dit kunnen meerdere bronnen zijn. Het LSP bundelt de resultaten en stuurt deze terug naar het NCPeH. Het LSP biedt patiënten ook inzage in de logging via www.volgjezorg.nl. Uitwisselingen i.h.k.v. de ePS zullen hierin ook getoond worden. 

 Geboden applicatieservices 

• Opvragen patiëntgegevens (LSP generieke query) 

 Gebruikte applicatieservices 

• Opvragen patiëntgegevens (LSP bouwsteenquery) 

• Controleren toestemming patiënt 

De vraag is of het NCPeH ook de beheerinterfaces voor TKID, Tick/Tock moet ondersteunen.

Applicatiefuncties 

We maken gebruik van de bestaande functionaliteit van het LSP 

Mitz 

Mitz is het systeem waarin patiënten in Nederland de benodigde uitdrukkelijke toestemming voor gegevensuitwisseling in de zorg kunnen beheren. Elektronische uitwisselingssystemen, zoals het LSP, kunnen hier dan ook controleren of en bij welke brondossierhouders er toestemming is om de gegevens uit te wisselen. 

 Geboden applicatieservices 

• Controleren toestemming patiënt 

Gebruikte applicatieservices 

Niet specifiek voor deze usecase. 

 Applicatiefuncties 

We maken gebruik van bestaande functionaliteit. Nieuw is de Europese dimensie van de toepassingen; dit moet in Mitz opgenomen worden. 

ZORG-AB

In ZORG-AB worden de gegevens van Nederlandse zorgaanbieders aangeboden. Hiermee kan het veld (XIS’en, volgjezorg en Mitz) de unieke identifiers die in berichtuitwisseling meekomen en in de logging wordt opgeslagen verrijken met gevelnamen en adressen. Voor buitenlandse zorgaanbieders is het niet mogelijk om deze allemaal in ZORG-AB te registreren. Dit levert problemen op voor het veld; Mitz kent het type zorgaanbieder niet, volgjezorg en XIS’en hebben alleen een onbekende unieke identifier in de logging staan. Een oplossing is om de verrijkte gegevens steeds mee te geven in de berichtuitwisseling, maar dit heeft grote impact op alle berichten en alle loggingen.

Besloten is dat het NCPeH-NL/CIBG in de Nederlandse (loggings)keten wordt opgenomen. Alleen deze partij moet (eventueel) in ZORG-AB worden opgenomen.

HIS 

Huisartsinformatiesystemen (HIS’en) zijn de bron voor de ePS. Deze ontsluiten hun gegevens via de bouwstenenquery. Het uitgangspunt is dat deze HIS’en geen aanpassingen hoeven doen aan de bestaande interfaces voor de uitwisseling met het NCPeH. Wél moet er een patiënttoestemming voor deze uitwisseling zijn. Hiervoor is het nodig dat de HIS’en een aansluiting hebben op Mitz.  

 Geboden applicatieservices 

• Opvragen patiëntgegevens (LSP bouwsteenquery) 

 Gebruikte applicatieservices 

Niet specifiek voor deze usecase. 

Applicatiefuncties 

Niet specifiek voor deze usecase. 

Alle componenten 

Een aantal zaken moet door alle componenten geboden worden. Die zijn niet per component  benoemd: 

• Logging: er is besloten om het NCPeH-NL / CIBG als partij in de Nederlandse loggingsketen op te nemen. Het NCPeH logt natuurlijk wel welke buitenlandse zorgaanbieder/zorgverlener een raadpleging heeft gedaan. Hiermee voldoet de gehele keten aan de NEN7513 norm, maar niet ieder individueel systeem. Daarom is het wel nodig om een procedure af te spreken waarin de verschillende verantwoordelijken in de keten onderling logginginformatie kunnen uitwisselen.

• Foutafhandeling 

• Patiëntinzage 

• Beheerfuncties 

Koppelvlakken 

In de vorige paragraaf zijn de applicatieservices benoemd die door de applicatiecomponenten geboden resp. gebruikt worden. Deze paragraaf beschrijft in meer detail via welke koppelvlakken die applicatieservices bereikbaar zijn. 

Koppelvlak NCPeH-NL – NCPeH-x  

Het koppelvlak tussen de NCPeH’s moet voldoen aan de specificaties van MyHealth@EU. 

• Functionaliteit 

Het koppelvlak biedt het NCPeH in land B de mogelijkheid om via het Europese netwerk service requests te plaatsen voor het kunnen opvragen van medische gegevens: check patient id; list documents; get patient summary. Het koppelvlak biedt het NCPeH in Nederland de mogelijkheid om via het Europese netwerk de responsies op de requests terug te geven aan het NCPeH in land B. NCPeH maakt hierbij gebruik van functionaliteit die het CIBG ‘koppelvlak’ biedt. Het CIBG koppelvlak is een verzameling van diensten en technologieën op het gebied van authenticatie, autorisatie, logging en dergelijke. 

• Protocol 

SOAP 

• Formaat 

Europese standaard Data in CDA, artefact pdf 

• Beveiliging 

TLS 

Koppelvlak NCPeH-NL – Beheerportaal  

• Functionaliteit 

Het koppelvlak biedt de functioneel beheerder van het NCPeH in Nederland de mogelijkheid om beheerservices aan te roepen voor: 

• Test functies uitvoeren 

• US'en activeren, deactiveren 

• Landen activeren, deactiveren 

• Performance rapporteren (# raadplegingen et cet) 

• Log raadplegen 

• Vertaaltabellen MVC NL <> EN onderhouden 

• Mapping tabellen HCO(B) categorie– HCO(NL) categorie onderhouden 

• ... 

Het koppelvlak biedt de technisch beheerder van het NCPeH in Nederland de mogelijkheid om beheerservices aan te roepen voor: 

• Systeemstatus monitoren 

• Excepties signaleren, raadplegen, rapporteren 

• Performance rapporteren 

• Log raadplegen... 

• ... 

• Protocol 

REST 

• Formaat 

? 

• Beveiliging 

JWT + identity access management 

 Koppelvlak NCPeH-NL – Patiëntportaal  

• Functionaliteit 

Het koppelvlak biedt de burger de mogelijkheid om de opvragingen en gegevensuitwisseling te raadplegen. 

• Protocol 

REST 

• Formaat 

? 

• Beveiliging 

JWT + identity access management 

Er wordt mogelijk een patiëntportaal ingericht om te voldoen aan de eisen ten aanzien van inzage door de patiënt van de gebeurtenissen met betrekking tot uitwisseling van de patient summary. 

Koppelvlak NCPeH-NL – BSN-bron  

• Functionaliteit 

Het koppelvlak biedt het NCPeH in Nederland de mogelijkheid om requests te plaatsen voor het opvragen van identificerende gegevens van burgers. 

• Protocol 

? 

• Formaat 

? 

• Beveiliging 

?

Koppelvlak NCPeH-NL – LSP 

Het koppelvlak tussen NCPeH en LSP is de zgn. Generieke Query. Op basis van parameters in de query kunnen specifieke datasets opgevraagd worden. De parameters verwijzen naar voor geconfigureerde datasets in het LSP waarin voor iedere Zib in een bepaalde dataset geconfigureerd is welke bouwsteenquery met welke parameters naar een bronsysteem gestuurd moet worden om deze ZIb op te halen 

Vertrouwensmodel. Hier zullen aanpassingen aan gedaan moeten worden, omdat men in Europa natuurlijk de UZI-pas niet gebruikt. Er worden wel eisen gesteld aan het authenticatiemiddel dat een buitenlandse arts moet gebruiken, maar er wordt geen cryptografisch bewijs van de authenticatie meegestuurd. 

Ook op netwerkniveau moet bekeken worden of gebruikt moet worden gemaakt van een GZN. In Nederland geldt het Besluit elektronische gegevensverwerking door zorgaanbieders waarin wordt vereist dat het gebruikte netwerk voldoet aan ZSP-eisen en aan de NEN7512.

Koppelvlak LSP/NCPeH – Mitz  

Regulier

Koppelvlak LSP – HIS’en  

Voor het koppelvlak tussen het LSP en de aangesloten HIS’en maken we gebruik van de bestaande bouwsteenquery. Deze is in detail beschreven in de AORTA-documentatie. 

Testen 

Voor de jaarlijkse audit door Europa wordt vereist dat er een aantal testen gedaan worden. Een aantal van deze testen wordt uitgevoerd op het productiesysteem. Met 3 verschillende ‘patiënten’ moet aangetoond worden dat het systeem naar behoren werkt. Dit heeft de volgende impact: 

• Er dienen 3 fictieve BSN's beschikbaar te zijn. 

• Deze dienen door het NCPeH-NL gecontroleerd te worden bij de BSN-bron (SBV-Z, BV-BSN) 

• Bij Mitz dienen er voor deze 3 BSN's toestemmingsprofielen aangemaakt te zijn. Hierbij is het dan ook nodig dat er toestemming gegeven wordt aan de bron(nen) (huisartsen) die meedoen in de test.  

• Bij deze huisartsen dient een fictief dossier van deze BSN's voor raadpleging beschikbaar te zijn.  

• Deze BSN's dienen te zijn aangemeld bij het LSP. 

Omdat testen in productie in AORTA eigenlijk niet kan, moet er goed bepaald worden wat impact hiervan gaat zijn bij de verschillende systemen en dan moet (gezamenlijk) het besluit gemaakt worden of we hier als Nederland/AORTA/XIS-leverancier/Huisarts mee akkoord kunnen gaan. 

Project overstijgende ontwerpkeuzes

• Keuze voor Mitz als manier om patiënttoestemming te registreren. Dit vergt aanpassingen aan Mitz en aansluiting van de betreffende bronnen op Mitz.

• Vanuit Europa is de eis dat gesynchroniseerd wordt met een stratum-2 NTP-server. Het is niet duidelijk of het LSP hieraan voldoet omdat VZVZ hier verder geen eisen aan gesteld heeft. Als dit een wijziging voor AORTA betreft heeft dit een ketenbrede impact.

Architectuurafwijkingen

• Vertrouwensmodel AORTA: Zorgaanbieders en -verleners vanuit Europa zijn geïdentificeerd en geauthentiseerd volgens de regels van het betreffende land. Hier geldt een Europees vertrouwensmodel. Dit betekent wel dat het LSP niet de waarborgen op vertrouwensniveau midden verkrijgt zoals normaliter het geval is.

  • authenticatieniveau

  • geboden transparantie richting burger

• Governance

  • VWS en CIBG zijn (nog) geen onderdeel van de AORTA/VZVZ governance.

  • Er is geen overeengekomen roadmap, maar we zijn afhankelijk van wat er in Europa wordt afgesproken

  • Er is geen open speelveld. Er worden keuzes gemaakt voor bepaalde voorzieningen: Mitz en NCPeH. Deze zijn ook niet openbaar aanbesteed.