ARCHITECTUURONTWERP BASISINFRASTRUCTUUR IN DE ZORG

ARCHITECTUURONTWERP BASISINFRASTRUCTUUR IN DE ZORG - Versie 4.2 -

postadres: Postbus 262, 2260 AG Leidschendam bezoekadres: Overgoo 11, 2266 JZ Leidschendam telefoon: (070) 317 34 50; fax: (070) 320 74 37; e-mail: [email protected] www.NICTIZ.nl

Status : Datum

Definitief :

16 november 2005

Managementsamenvatting Om te komen tot meer doelmatigheid en kwaliteit in de zorg dienen bedrijfsprocessen beter ondersteund te worden door middel van ICT. Met de totstandkoming van een landelijke basisinfrastructuur, wordt de basis gelegd voor het veilig en snel transmuraal uitwisselen van informatie tussen zorgverleners onderling en richting zorgverzekeraars. Daarnaast zullen ook medewerkers van zorginstellingen die te maken hebben met transmurale zorglogistieke en financieel-administratieve processen gebruik kunnen gaan maken van de verbeterde communicatiemogelijkheden. Op termijn zal ook de patiënt toegang kunnen krijgen, bijvoorbeeld om zijn dossier in te zien of om gebruik te maken van bepaalde applicaties zoals het “on line” maken van afspraken. Het architectuurontwerp geeft een overzicht van de landelijke basisinfrastructuur met daarin de benodigde infrastructurele voorzieningen en de daaraan gekoppelde systemen inclusief de onderlinge samenwerking en de samenhang. De bijbehorende bekostiging en organisatorische totstandkoming van de basisinfrastructuur vormen geen onderdeel van dit architectuurontwerp. Als startapplicaties is gekozen voor een drietal concrete toepassingen, het emedicatiedossier, het e-waarneemdossier en het e-declareren. Naast deze startapplicaties moeten ook andere transmurale toepassingen zoals telemedicine, logistiek en financiële administratie via dezelfde landelijke infrastructuur informatie snel en veilig kunnen uitwisselen. Dit architectuurontwerp dient gezien te worden als een blauwdruk op hoofdlijnen aan de hand waarvan verdere detaillering, afstemming en discussie kan plaatsvinden. Bij de opzet van het architectuurontwerp voor de basisinfrastructuur zijn de volgende ontwerpkeuzen gemaakt: • Waar mogelijk, is en blijft de opslag van patiëntgegevens in het bronsysteem van de verantwoordelijke zorgverlener. Daarmee kan de integriteit en actualiteit van de gegevens worden gerealiseerd en blijft de verantwoordelijkheid voor de gegevens waar die moet zijn: bij de bron. Dit sluit overigens niet uit dat categoraal of lokaal gebruik wordt gemaakt van via gecentraliseerde systemen aangeboden applicatiediensten met bijbehorende centrale opslag. Ook sluit dit niet uit dat in bepaalde gevallen (verhuizing, beëindigen van de praktijk etc.) dossieroverdracht plaatsvindt tussen zorgverleners, waarna het zorgsysteem van de nieuwe verantwoordelijke zorgverlener als bron van de gegevens gaat fungeren. • Aangesloten systemen moeten aan specifieke eisen voldoen ten aanzien van beveiliging en beheer. Voor bronsystemen die (nog) niet aan de gestelde eisen voldoen, kunnen voorzieningen worden getroffen, zoals replicatie van gegevens in een

Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- i-

• •

•

•

(lokale, regionale of landelijke) centrale database. Een dergelijke database zal dan gaan fungeren als bronsysteem voor de desbetreffende patiëntgegevens. Daarnaast zijn er specifieke applicaties die gebruik maken van centrale opslag van gegevens. De architectuur is er op ingericht ook deze gegevens te ontsluiten. Uitgave, beheer en valideren van identiteitcertificaten van de zorgverleners, zorginstellingen en zorgsystemen vindt plaats met behulp van een landelijk centraal Unieke Zorgverleners Identificatie (UZI) -register. Voor het opzoeken en opslaan van patiëntinformatie wordt gebruik gemaakt van een unieke patiënt identificatie door middel van het landelijke Burger Service Nummer (BSN). Voor het snel vinden en toegankelijk maken van de gezochte informatie wordt gebruik gemaakt van een verwijsindex (een verwijsindex geeft aan waar bepaalde informatie ligt opgeslagen). Aan deze verwijsindex zijn de volgende functies gekoppeld: o authenticatie van de aanvragende zorgverlener, om te kunnen bepalen of hij daadwerkelijk degene is die hij beweert te zijn; o autoriseren van toegang tot de patiëntgegevens op basis van de functie van de aanvragende zorgverlener; o loggen van de aanvragen en antwoorden om de rechtmatigheid van aanvragen achteraf te kunnen controleren.

Op technisch niveau zijn keuzen gemaakt die aansluiten bij bestaande praktijken voor uitwisseling van medische gegevens tussen zorgverleners. Daarbij wordt gekozen voor berichtuitwisseling op basis van HL7 versie 3 vanwege de groeimogelijkheden richting een EPD en de aansluiting bij internationale ontwikkelingen. Voor het transport van de berichten is gekozen voor Internettechnologie (XML/SOAP). Het op deze wijze uitwisselen van berichten met behulp van Internettechnologie, is gestandaardiseerd door het internationale standaardisatie-instituut W3C en wordt door alle grote leveranciers en systeemhuizen in de markt ondersteund. De beschrijvingsmethode die in dit document is toegepast is conform de beschikbare internationale standaard op dit gebied [1] en “best practices” op het gebied van architectuurmodellen. Inhoudelijk is het architectuurontwerp breed afgestemd met een veelheid van partijen binnen en buiten het zorgveld (Zie Bijlage B).

- ii -


Wijzigingen t.o.v. Architectuurontwerp Basisinfrastructuur in de Zorg, versie 4.1 Het architectuurontwerp 4.1 is verschenen op 11 mei 2005. Ten opzichte van dit document zijn er de belangrijkste toevoegingen en wijzigingen: • Generieke beschrijving van de belanghebbenden (paragraaf 4.1). • Aangeven van relaties met het e-kinddossier (EKD) voor de jeugdgezondheidszorg (paragraaf 5.3.5) en uitwerken GBZ-eisen hiervoor (paragraaf 7.6.4). • Nader uitwerken van de eisen vanuit de patiënt (paragraaf 5.4). • Expliciteren Dossieroverdracht (paragrafen 5.5.2 en 6.8). • Aanpassing procedure patiëntidentificatie en gebruik BSN in lijn met de te verwachten weten regelgeving BSN (paragraaf 5.5.3). • Verwijzing naar documentatie van implementatieprogramma WGBO i.v.m. de mogelijkheid om in bepaalde omstandigheden uit te gaan van veronderstelde toestemming van de patiënt (paragraaf 5.5.5). • Invoegen van functionaliteit voor zogenaamde “voorbehouden handelingen” ook wel bekend onder de aanduiding “verlengde arm” en betere onderbouwing autorisatiefunctie als gemeenschappelijke voorziening (paragraaf 5.5.5). • Aanpassing tekst over vierde domeinpartijen en VDZ-register (paragrafen 5.7.5 en 6.4.1) • Functionaliteit voor ondersteuning van wetenschappelijk onderzoek, rapportage en beheer van volksgezondheid en beleidsvorming (paragraaf 6.11). • Aanpassen CA-model UZI-register en invoegen mogelijkheid Online de status van een certificaat op te vragen via OCSP (paragraaf 6.12.3) • Aanpassing tekst over afwijkingen basiscommunicatiepatroon bij opvragen van informatie, vooral gericht op het uitwisselen van grote bestanden (paragraaf 6.14.3). • Aanpassen tekst over berichttranslatie (paragraaf 7.4) • Verduidelijken tekst over garanderen van vertrouwelijkheid (paragraaf 7.5.2) • Aanpassing van de tekst m.b.t. het opzetten van SSL-sessies voor opvragen van patiëntinformatie door de zorgverlener (paragraaf 7.5.3). • Weglaten minimale eis voor toegangsbeveiliging, aangezien dit al door NEN 7510 wordt gedekt (paragraaf 7.6.2) • Toevoegen GBZ-eis voor vastleggen aard en nummer van het WID (paragrafen 7.6.3 en 7.6.4) • Toevoegen specifieke eisen aan GBZ’en die niet continu en direct beschikbaar hoeven te zijn (paragraaf 7.6.4)


- iii -

•

- iv -

Toevoegen van beschrijving van mogelijke koppeling met Landelijk Centrale Middelen Registratie van de Verslavingszorg in hoofdstuk “Aanpalende domeinen” (paragraaf 8.3).


Documenthistorie Versie

Datum

Toelichting

Discussiedocument 1.0

18 juli 2002

Besproken op OIZ vergadering op 25 juli 2002

Discussiedocument 1.3

9 september 2002

Op individuele basis besproken met groot aantal leveranciers en adviesbureaus

Architectuurontwerp 1.0 1 oktober 2002

Oplevering definitieve versie 1.0 aan OIZ

Architectuurontwerp 1.1 15 november 2002

Verwerken commentaar en vragen van diverse betrokkenen, o.a. OIZ

Architectuurontwerp 2.0 15 december 2002

Toevoegen aantal bijlagen met nadere detaillering

Architectuurontwerp 3.0 1 februari 2004

Integreren Document Zekerheidsstructuur, Verwerken ontwikkelingen standaardisatie, Consistent houden specificaties en Architectuur

Architectuurontwerp 4.0 15 oktober 2004

Inpassingen in relatie tot SBV-Z en het UZI-register, Alternatieve communicatiepatronen, Dienstenmodel met rollen LSP en ZSP, Diverse uitvoeringsvormen, Ondersteuning alle processen in de zorg, Portalvarianten, De meest recente internationale ontwikkelingen.

Architectuurontwerp 4.1 29 april 2005

Relatie met e-declareren, aanpassen terminologie architectuurmodel, verduidelijken aspecten van semantische interoperabiliteit, verduidelijken autorisatieprofiel, organisatorische aspecten, evolutie-aspecten naar een zorgbreed EPD, verduidelijken autorisatieprofiel, voorzieningen voor beheer, Koppeling van DCN’en, relaties met “aanpalende domeinen”, weglaten van enkele informatieve (technische) bijlagen.

Architectuurontwerp 4.2 16 november 2005

Generieke beschrijving belanghebbenden, aangeven van relaties met het ekinddossier (EKD) voor de jeugdgezondheidszorg, uitwerking van de eisen vanuit de patiënt, expliciteren dossieroverdracht, veronderstelde toestemming van de patiënt,


- v-

“voorbehouden handelingen”, functionaliteit voor datamining, toevoegen OCSP, beschrijving van mogelijke koppeling met LCMR van de Verslavingszorg

- vi -


Inhoudsopgave 1

2

3

Inleiding

1

1.1 1.2 1.3 1.4 1.5

1 1 2 2 3

Uitgangspunten en randvoorwaarden

5

2.1 2.2

5 5

5

6

Eisen aan de architectuurbeschrijving Uitgangspunten en randvoorwaarden bij de architectuurinvulling

Scope en ambitieniveau 3.1 3.2 3.3

4

Algemeen Doel van dit rapport Doelgroep Totstandkoming van dit rapport Architectuurinrichtingsproces

Scope 7 Toekomstbeeld: e-zorg Ambitieniveau voor de architectuurbeschrijving

7 9 11

Beschrijvingsmodel

12

4.1 4.2 4.3 4.4

12 13 14 15

Belanghebbenden Het architectuurmodel Afbakening van de architectuurbeschrijving Aspectgebied Beveiliging

De bedrijfsarchitectuur

17

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13

17 18 19 23 23 31 32 36 37 43 44 46 47

Ondersteuning van bedrijfsprocessen in de Zorg Communicatie in de zorgsector Casebeschrijvingen Eisen vanuit de patiënt Eisen vanuit de zorgprocessen Diensten van de basisinfrastructuur Organisatorische aspecten van de basisinfrastructuur Dimensioneringseisen voor de basisinfrastructuur Inrichtingsvragen Eisen aan de infrastructurele voorzieningen Infrastructurele voorzieningen voor beveiliging Voorzieningen voor beheer Eisen aan zorgsystemen

De informatie (systeem) architectuur

50

6.1

50

Inleiding


- vii -

6.2 6.3 6.4 6.5

Semantiek en syntax Coderingsstelsels Identificatie Functionaliteit voor het bieden van generieke connectiviteit

50 51 51 52

6.6

Functionaliteit gegevens Functionaliteit Functionaliteit Functionaliteit

52 54 55 55

6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14

7

9

voor het versturen van gegevens voor dossieroverdracht voor het abonneren op gegevens

Functionaliteit voor het ondersteunen van semantische interoperabiliteit

Functionaliteit voor ondersteuning van wetenschappelijk onderzoek, rapportage en beheer van volksgezondheid en beleidsvorming 56 Beveiliging 56 Invulling van gemeenschappelijke voorzieningen 60 Interactieprincipes tussen zorgsystemen en infrastructurele voorzieningen

62 69

7.1 7.2 7.3 7.4 7.5

Het servicemodel Relatie met het OSI-model Functionele modules, protocollen en koppelvlakken Invulling van de lagen Beveiliging, continuïteit en beheer

69 70 70 71 75

7.6

Eisen aan beschikbaarheid, betrouwbaarheid en beveiliging van zorgsystemen (GBZ’n) Invulling architectuurmodel

85 87

Aanpalende domeinen

89

8.1 8.2 8.3 8.4

Inleiding e-Declareren Landelijke Centrale (Opiumwet-)Middelen Registratie Patiëntenportaal

89 89 90 93

8.5

Relatie met architectuur gegevensuitwisseling Uitvoeringsinstanties sociale zekerheid

94

Literatuur

BIJLAGE A: Afkortingenlijst BIJLAGE B: Internationale ervaringen BIJLAGE C: Consultatieproces

- viii -

55

De technische architectuur

7.7 8

voor het opvragen en verkrijgen van (patiënt)

96 100 102 106


1

Inleiding

1.1 Algemeen Een belangrijke voorwaarde voor efficiënte, betrouwbare en veilige informatieuitwisseling tussen (systemen van) zorgaanbieders1 ter verbetering van kwaliteit en doelmatigheid van de zorg is de totstandkoming van een ICT-basisinfrastructuur in de zorgsector. Bovendien moeten zorgsystemen transmuraal met elkaar en met de infrastructurele voorzieningen kunnen communiceren. Om dit te bereiken is een gemeenschappelijk referentiekader noodzakelijk voor alle direct betrokkenen, met name voor ontwikkelaars van systemen en dienstverleners. Een architectuur levert dit referentiekader door de samenhang van en samenwerking tussen de ICT-voorzieningen in een transmurale context te beschrijven.

1.2 Doel van dit rapport In dit document wordt het architectuurontwerp van de basisinfrastructuur voor de zorg beschreven. Voor alle duidelijkheid wordt hier opgemerkt dat het document er niet op gericht is een allesomvattende architectuur van de informatievoorziening in de zorg te bieden. Het architectuurontwerp van de basisinfrastructuur beschrijft de samenhang van en samenwerking tussen de ICT-voorzieningen in een transmurale context. Dit document beperkt zich tot de hoofdlijnen en belangrijkste ontwerpbeslissingen. De nadere uitwerking vindt plaats in het document “Specificatie van de basisinfrastructuur in de zorg”, waarin de specificaties worden beschreven van de functionaliteit die in de basisinfrastructuur moet worden ingericht en van de berichten die via de infrastructuur worden uitgewisseld. In dit document wordt dus op hoofdlijnen beschreven hoe de architectuur moet worden vormgegeven om aan de gestelde eisen te kunnen voldoen. Het is daarmee een blauwdruk hoe de basisinfrastructuur er uit moet gaan zien. Dit wordt wel aangeduid met de term “referentiearchitectuur”. Daarnaast zullen aparte documenten verschijnen voor het beschrijven van berichten op basis van de internationale standaard HL7 versie 3 en voor de uitwerking van migratiescenario’s hoe vanuit de huidige situatie een groeipad kan worden gecreëerd naar de in het architectuurontwerp beschreven situatie. De samenhang van dit document met de documenten die een verder uitwerking geven van het architectuurontwerp staat aangegeven in Figuur 1-1. 1

De term zorgaanbieder wordt gebruikt als een verzamelbegrip dat zowel de zorginstelling als de individuele

zorgverlener omvat. Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 1-

Het architectuurontwerp dient dus als basis voor de verdere architectuuruitwerking en specificaties van de basisinfrastructuur in de zorg en is daarnaast bedoeld als een referentiemodel om de afstemming tussen betrokkenen binnen de zorg-ICT-wereld richting te geven en te structureren.

Architectuurontwerp Basisinfra Zorg

Specificatie Basisinfra Zorg

Programma van eisen LSP

Programma van eisen GBZ

Programma van eisen ZSP

HL7 implementatie handleidingen

Figuur 1-1: Relatie tussen documenten voor architectuur en specificaties

1.3 Doelgroep Dit document is primair geschreven voor architecten en inhoudelijk deskundigen op het gebied van ICT in de gezondheidszorg. De consequenties van de gekozen uitgangspunten en gemaakte keuzen hebben echter een dermate grote invloed op de inrichting en organisatie van ICT in de zorg dat het document ook van belang is voor bestuurders en beleidsmakers.

1.4 Totstandkoming van dit rapport In de afgelopen jaren zijn veel rapporten geschreven en experimenten uitgevoerd op het gebied van elektronische communicatie in de zorg. Op basis van de beschikbare

- 2-


informatie is een eerste architectuuraanzet opgesteld. Deze aanzet is in het veld getoetst. Daarbij is OIZ2 als gesprekspartner namens de leveranciers opgetreden. Daarnaast hebben gesprekken plaatsgevonden met een groot aantal3 leveranciers, adviesbureaus en partijen uit het zorgveld afzonderlijk. Deze gesprekken en de feedback van de OIZ hebben geleid tot een verdere optimalisatie van de architectuur. Er is bij de invulling van de architectuur gekozen voor een pragmatische en aanpak die op relatief korte termijn haalbaar is, waarbij wel rekening wordt gehouden met de wenselijkheid van nadere invulling op de lange termijn. Om niet te hoeven wachten op de resultaten van vaak meerjarige standaardisatie- en normalisatieactiviteiten, is ervoor gekozen om de reeds beschikbare kennis en ervaring uit eerdere projecten te benutten en zoveel mogelijk aan te sluiten bij praktijkervaring uit het veld en ontwikkelingen in de industrie, zowel nationaal als internationaal. Bovendien wordt zoveel mogelijk aangesloten bij reeds beschikbare en in de praktijk getoetste standaarden en normen.

1.5 Architectuurinrichtingsproces Een architectuur dient dusdanig te worden ontworpen dat rekening wordt gehouden met de toekomstig benodigde functionaliteit en capaciteit. In principe zouden alle mogelijke toepassingen (use cases) ter ondersteuning van zorgprocessen moeten worden geanalyseerd, om zo tot een allesomvattend eisenpakket voor de basisinfrastructuur te komen. In de zorg hebben we echter te maken met een sterk veranderend en nog nauwelijks gecoördineerd veld zodat het ondoenbaar is binnen afzienbare tijd tot een dergelijke allesomvattende analyse te komen. Bovendien brengt het breed trekken van een ontwerptraject en uitwerken van alle mogelijke use cases zowel qua tijd (lange doorlooptijd) als qua complexiteit risico’s met zich mee. Veel projecten in de zorg zijn gestrand vanwege een te hoog ambitieniveau. Er is daarom gezocht naar een methode om breed te kijken naar mogelijke toepassingsgebieden en daar de basisinfrastructuur op in te richten zonder eerst alle toepassingen (use cases) in detail uit te werken. Daarbij ligt de focus op de gemeenschappelijke voorzieningen die minimaal noodzakelijk zijn. Om snel concrete doelen te kunnen bereiken is gekozen voor een aantal specifieke (start)applicaties dat gebruik maakt van de basisinfrastructuur: het e-medicatiedossier, e-waarneemdossier voor huisartsen en e-declareren. Zoals aangegeven brengt een dergelijke benadering ook risico’s met zich mee omdat niet met 100% zekerheid kan worden vastgesteld dat aan alle mogelijke toekomstige eisen kan worden voldaan. De functies van de basisinfrastructuur zijn echter dermate generiek gekozen dat deze risico’s minimaal zijn.

2

Vereniging van Organisaties voor ICT in de Zorg

3

Er hebben gesprekken met meer dan 30 partijen plaatsgevonden.


- 3-

In moderne architectuurbenaderingen wordt er veelal voor gekozen om niet op voorhand alles in detail te specificeren, maar voldoende modulariteit en flexibiliteit in te bouwen, zodat snel kan worden ingespeeld op veranderende situaties. Op deze wijze kan worden voorkomen dat een architectuur al weer verouderd is op het moment dat hij wordt ingevoerd. Dat is ook een van de uitgangspunten geweest bij het ontwerpen van de architectuur voor de basisinfrastructuur in de zorg.

- 4-


2

Uitgangspunten en randvoorwaarden

2.1 Eisen aan de architectuurbeschrijving De architectuurbeschrijving van de basisinfrastructuur dient aan de volgende eisen te voldoen: 1. Het vormt een samenhangend geheel van principes, richtlijnen en modellen voor het ontwerpen van de voorzieningen in de basisinfrastructuur die zorgdragen voor informatie-uitwisseling tussen applicaties in zorgsystemen. 2. Het levert de kaders voor het opstellen van de specificatie van de functionaliteit die in de basisinfrastructuur moet worden ingericht en de berichten die via de infrastructuur worden uitgewisseld. 3. Het vormt de basis voor het ontwerp van toepassingen zoals het e-medicatiedossier, e-waarneemdossier en e-declareren.

2.2 Uitgangspunten en randvoorwaarden bij de architectuurinvulling Bij het ontwerp zijn de volgende uitgangspunten en randvoorwaarden gehanteerd: • Er wordt gestreefd naar oplossingen die op draagvlak in het veld kunnen rekenen. Daarom is het ontwerp van de architectuur primair gebaseerd op de bestaande vertrouwenstructuren, autonomie en verantwoordelijkheden van patiënten, betrokken zorgverleners, organisaties en instellingen. Daarnaast is het draagvlak vanuit politiek en samenleving van belang. • De kosteneffectiviteit van de oplossing is een belangrijk criterium voor het afwegen van alternatieven. Uitgangspunt is dat niet wordt gestreefd naar een technisch perfecte invulling, maar naar een betaalbare, werkende oplossing, die leidt tot een aanmerkelijke verbetering van de informatievoorziening van de zorgaanbieder en kan doorgroeien naar een brede ondersteuning van applicaties in het zorgveld. • Er dient rekening te worden gehouden met de “installed base” van bestaande zorgsystemen. De informatie in deze systemen moet snel en zonder grote centrale investeringen toegankelijk gemaakt kunnen worden. • De autonomie van de zorgverlener impliceert dat deze, binnen bepaalde randvoorwaarden t.a.v beveiliging, zijn ICT-voorzieningen naar eigen inzicht kan organiseren en dat hij zelf verantwoordelijk blijft voor het waarborgen van de integriteit en privacy van patiëntgegevens. • Bij het ontwerp van de architectuur is zoveel mogelijk uitgegaan van de bestaande weten regelgeving. Het betreft hier met name de Wet op de Geneeskundige Behandelingsovereenkomst (WGBO) en de Wet Bescherming Persoonsgegevens (WBP). Patiënten dient overeenkomstig de WGBO in beginsel vooraf toestemming te worden gevraagd als hun gegevens aan derden worden verstrekt die niet rechtstreeks bij de behandeling zijn betrokken. Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 5-

• •

•

•

Er dient gebruik te worden gemaakt van (internationale) open standaarden. Om snel realistische doelen te kunnen bereiken is gekozen voor het realiseren van een concrete toepassing, het door zorgverleners kunnen raadplegen van de landelijk beschikbare gegevens over (afgeleverde) medicatie aan patiënten. Daarnaast dient de basisinfrastructuur vanaf de start de applicaties e-waarneemdossier voor huisartsen en e-declareren te ondersteunen. De architectuur en specificaties beperken zich derhalve tot een beschrijving van de basisinfrastructuur en biedt geen omvattende beschrijving van het gehele zorgdomein. De architectuur dient voldoende toekomstvast te zijn om de verdere groei naar het landelijk EPD en een bredere inzet van ICT in de zorg voor toepassingen zoals telemedicine, logistiek en financieel-administratief kunnen accommoderen. De eigen rol en verantwoordelijkheid van de leveranciers van systemen en softwarepakketten blijft gehandhaafd. Het streven is om oplossingen te zoeken waarbij de marktwerking zoveel mogelijk wordt gestimuleerd.

- 6-


3

Scope en ambitieniveau

3.1 Scope 3.1.1 Begripsbepaling Een architectuurbeschrijving is bestemd om op een passend abstractieniveau te kunnen communiceren met relevante partijen. In dit document wordt gebruik gemaakt van de volgende definitie van architectuur uit IEEE Std 1471-2000 [1]: de fundamentele organisatie van een systeem, uitgedrukt in zijn componenten, hun relaties onderling en met de omgeving, en de principes die het ontwerp en de evolutie ervan bepalen. Het begrip infrastructuur kan worden omschreven als: het geheel van permanent aanwezige gemeenschappelijke facilitaire voorzieningen. Voor bestuurders komen daar nog de aspecten van verantwoordelijkheid, financiering en besturing bij. In dit document wordt het begrip infrastructuur in de bestuurlijke betekenis gebruikt, namelijk een algemeen in de sector toegankelijk stelsel van gemeenschappelijke ICT-voorzieningen. Deze gemeenschappelijke voorzieningen kunnen tot stand komen doordat de bestuurlijke verantwoordelijkheid centraal is genomen. Dit kan zowel op regionaal als op landelijk niveau worden gerealiseerd4.

3.1.2 Afbakening: basisinfrastructuur In dit document is gekozen voor de volgende afbakening: het architectuurontwerp richt zich primair op de voorzieningen in de basisinfrastructuur die zorgdragen voor informatie-uitwisseling tussen applicaties in zorgsystemen en op de interactie tussen die voorzieningen en de applicaties. Het kan hier gaan om applicaties die het primaire (zorg) proces ondersteunen maar ook gaan om logistieke en of financieel-administratieve applicaties. Het is geenszins de bedoeling één allesomvattende architectuur voor de zorg te beschrijven. De huidige situatie m.b.t. zorginhoudelijke patiëntinformatie in de zorg wordt weergegeven in Figuur 3-1. Een patiënt kan contact hebben met diverse zorgverleners, die gegevens opslaan in hun eigen informatiesystemen, in de figuur bijvoorbeeld aangeduid met ZIS (Ziekenhuis Informatie Systeem), HIS (Huisarts Informatie Systeem) of AIS (Apotheek Informatie Systeem). Als algemene term worden deze systemen wel XIS’en genoemd. Daarnaast zijn in de zorg systemen in gebruik die niet direct zorginhoudelijke informatie bevatten, maar bijvoorbeeld financieel-administratieve

4

Voor een landelijke infrastructuur dient de bestuurlijke verantwoordelijkheid landelijk centraal te worden

genomen, waarbij de uitvoering ook decentraal (d.w.z. regionaal) kan zijn belegd. Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 7-

gegevens. De overkoepelende verzamelterm voor alle systemen in de zorg is zorgsystemen.

ZIS ZIS Spec. 1

XIS HIS Huisarts Paramed.

ZIS ZIS

Zkh

Patiënt

Verzekeraars Huisarts Huisarts

Apoth. Apoth.

HIS HIS

AIS AIS Figuur 3-1: Huidige situatie in de zorg v.w.b. zorginhoudelijke patiëntinformatie AIS = Apotheek Informatie Systeem HIS = Huisarts Informatie Systeem ZIS = Ziekenhuis Informatie Systeem XIS = Zorg Informatie Systeem

Om alle zorgsystemen met elkaar te kunnen koppelen zijn infrastructurele voorzieningen noodzakelijk. Deze infrastructurele voorzieningen worden in dit document aangeduid met het begrip basisinfrastructuur. In voorliggend document wordt de architectuur van de basisinfrastructuur gepresenteerd. In de architectuur wordt de functionaliteit van de infrastructurele voorzieningen beschreven en de relaties aangegeven tussen zorgsystemen en infrastructurele voorzieningen, gedefinieerd op koppelvlakken zoals aangegeven in Figuur 3-2. De basisinfrastructuur voorziet in gemeenschappelijke, algemeen toegankelijke voorzieningen die minimaal noodzakelijk zijn om veilige en betrouwbare communicatie tussen zorgsystemen mogelijk te maken. Naast de minimaal noodzakelijke voorzieningen van de basisinfrastructuur kunnen aanvullende voorzieningen worden geboden die meerwaarde bieden aan zorgmedewerkers. Waar zinvol zal de architectuur-beschrijving ook ingaan op deze optionele voorzieningen.

- 8-


Koppelvlakken ZIS ZIS XIS HIS

Spec. 1

Huisarts Pa ramed.

ZIS ZIS

Zkh

Patiënt

Verzekeraars Huisarts Huisarts

Apoth. Apoth.

HIS HIS

AIS AIS

Figuur 3-2: Basisinfrastructuur en koppelvlakken met XIS’en

De architectuurbeschrijving richt zich derhalve niet op de volgende aspecten: • de interne werking van de aangesloten zorgsystemen (wel wordt ingegaan op de eisen die aan zorgsystemen worden gesteld om op de infrastructuur te kunnen worden aangesloten); • de inhoudelijke definitie van de uit te wisselen informatie; • de verdere detaillering van bedrijfsprocessen in de zorg; dit document beschrijft alleen die aspecten van deze processen, die nodig zijn voor de invulling van de basisinfrastructuur.

3.2 Toekomstbeeld: e-zorg Het toekomstperspectief is een situatie waarbij ICT bijdraagt aan een maximale ontplooiing van kwaliteit en efficiëntie in de zorg. Deze situatie wordt in dit rapport ezorg genoemd. Het uitgangspunt van dit rapport is dat op termijn onder meer telemedicine, kennismanagement, kennissystemen voor diagnose, behandeling op afstand, ultiem geoptimaliseerde administraties, communicatie van en tussen patiënten, zorgverleners en zorginstellingen één werkend geheel kunnen vormen, dienstbaar aan kwaliteit en efficiëntie van de zorg. Om al deze zorggerelateerde processen te kunnen gaan ondersteunen, is een stelsel van algemeen toegankelijke en generieke ICT-voorzieningen onontbeerlijk: de basisinfrastructuur en een systeem van standaarden voor uitwisselen van gegevens,


- 9-

applicatie-interfaces en technologiekeuzen. Dit geheel wordt beschreven in dit architectuurontwerp.

Logistiek ZorgEPD proces EPD

Medicatie Medicatie E-Waarneem E-Waarneem dossier dossier

Algemene ICT-diensten

Financieel Administratief

E-declaratie E-declaratie

Figuur 3-3: Doorgroei naar de e-zorg situatie

Binnen die toekomstige e-zorg-situatie zal het Elektronisch Patiënten Dossier (EPD) een centrale rol vervullen: steeds vaker zullen ICT-toepassingen het niet kunnen stellen zonder elektronische opslag van en toegang tot patiëntendossiers. En deze ICTtoepassingen zullen alleen één geheel vormen als EPD-gegevens, uiteraard met in acht name van alle wettelijke regels, in principe voor alle zorgapplicaties op een standaardwijze toegankelijk zijn. In de E-zorg situatie is ICT ingezet voor de ondersteuning van primaire zorgprocessen, maar ook voor verbetering van de communicatie tussen mensen en organisaties in de zorgsector, voor de logistieke en financieel-administratieve processen en voor de ondersteuning van het (wetenschappelijk) onderzoek. Bij logistieke en financieeladministratieve processen kan o.a. worden gedacht aan [11]: • Procesmanagement-tools, workflow-management; • Elektronische opdrachten, orders (onder meer op het gebied van lab, radiologie, medicatie); • Elektronische agendering, afspraken door de gehele zorgketen; • Automatische facturering op basis van gegevens uit het zorgproces (DBC, ligdagen, onderzoeken, spreekuur).

- 10 -


3.3 Ambitieniveau voor de architectuurbeschrijving Zoals al eerder aangegeven is gekozen voor een aantal specifieke (start)applicaties om snel concrete doelen te kunnen bereiken: het e-medicatiedossier, e-waarneemdossier voor huisartsen en e-declareren. Om deze zorggerelateerde applicaties te kunnen gaan ondersteunen, is een stelsel van algemeen toegankelijke en generieke ICT-voorzieningen onontbeerlijk: de basisinfrastructuur en een stelsel van standaarden voor uitwisselen van gegevens, applicatie-interfaces en technologiekeuzen. De inrichting van de basisinfrastructuur voor deze applicaties moet op een dusdanige manier geschieden dat het tot stand komen van de basisinfrastructuur tevens een begin is van de generieke voorzieningen die noodzakelijk zijn voor het EPD en later E-zorg. De basisinfrastructuur dient derhalve minimaal alle applicaties te ondersteunen die op een gedefinieerde standaardmanier gebruik maken van uitwisseling van tekstgeoriënteerde berichten. Dit omvat alle vormen van berichtcommunicatie, zoals het ophalen en verzenden van berichten geïnitieerd door zorgmedewerkers of door applicaties op basis van bepaalde triggers. Daarnaast dient er een generieke datacommunicatiefaciliteit te zijn om alle overige vormen van communicatie tussen zorgsystemen te ondersteunen. Hoewel met de inrichting van de basisinfrastructuur een belangrijke stap wordt gezet om de informatievoorziening op een aantal belangrijke terreinen in de Zorg te verbeteren, betekent dit niet dat daarmee alle mogelijkheden voor verbetering van de informatievoorziening in de Zorg direct zijn gerealiseerd. Door te werken aan betere methoden om de beschikbare informatie op een eenduidige wijze te kunnen interpreteren, zoals goede structurering van de informatie en eenheid van taal, kunnen nog belangrijke verbeteringen tot stand worden gebracht. Deze aspecten zijn een belangrijk aandachtspunt in de internationale standaardisatie, maar zijn nog niet volledig stabiel en op een niveau uitgewerkt dat er al systeemontwerpen op kunnen worden gebaseerd. Het zal dan ook nog zeker een aantal jaren duren voor er systemen op de markt komen die kunnen voldoen aan de eisen van een zorgbreed EPD met volledige functionaliteit. Voordat er een zodanige penetratie van deze systemen is dat het zinvol is de aansluitvoorwaarden voor de basisinfrastructuur op deze eisen te baseren, is er nog een lange weg te gaan. Voor de basisinfrastructuur is er dan ook voor gekozen eerst te focussen op het op een uniforme manier ontsluiten van informatie in bestaande zorgsystemen en daarbij prioriteit te geven aan die domeinen waar de informatie al gestructureerd aanwezig is en er eenheid van taal bestaat of relatief eenvoudig is te realiseren.


- 11 -

4

Beschrijvingsmodel

4.1 Belanghebbenden Het invoeren van nieuwe informatiesystemen zoals het EPD gaat gepaard met grote sociale en politieke wijzigingen. Vooral uitwisselen van patiëntinformatie over de grenzen van instellingen heen speelt zich af in een politieke arena, waarin uiteenlopende belangen een rol spelen. Vanuit het architectuurdenken wordt benadrukt dat voor het laten slagen van de invoering van nieuwe informatiesystemen rekening moet worden gehouden met deze uiteenlopende belangen. De meeste benaderingen redeneren dan ook vanuit het perspectief van de diverse belanghebbenden (“stakeholders”). Dit is overigens voor het EPD geen eenvoudige zaak omdat de Nederlandse gezondheidszorg complex georganiseerd is en veel belanghebbenden kent. De belangrijkste belanghebbenden op wie hier zal in algemene termen zal worden ingegaan, zijn: • de patiënt • de zorgverlener • de bestuurder • de informatiemanager • de dienstverlener en ontwikkelaar van zorgsystemen Het perspectief van de patiënt De patiënt wil zo snel mogelijk geen patiënt meer zijn en daar zo min mogelijk voor betalen. In andere woorden, zo snel en effectief mogelijk geholpen worden met een zo laag mogelijke kans op fouten en/of complicaties tegen zo'n laag mogelijke kosten. Daarbij gaat de patiënt er van uit dat de nieuwste inzichten en methoden zullen worden toegepast zodra dit als “bewezen” ingang heeft gevonden (“best practices”). De groep patiënten die zich zorgen maakt over privacyaspecten wil de mogelijkheid hebben mede te bepalen welke informatie beschikbaar wordt gesteld aan andere zorgverleners of zorgverzekeraars, ook al zijn die betrokken bij een behandeling en de financiële afwikkeling daarvan. Het perspectief van de zorgverlener De zorgverlener heeft groot belang bij het verminderen van vermijdbare fouten. Dit belang ziet hij niet alleen vanuit het perspectief van patiëntveiligheid, maar ook zeker vanuit het aansprakelijkheidsrisico. Een ander belang heeft te maken met de kosten en opbrengsten van de zorgverlener. De opbrengsten voor de zorgverlener staan de afgelopen jaren onder druk, terwijl de kosten toenemen. De zorgverlener heeft dan ook een belang om in zijn processen te streven naar meer efficiëntie. Het elektronisch beschikbaar hebben van alle relevante medische informatie van een patiënt kan helpen deze efficiëntie te verbeteren.

- 12 -


Het perspectief van de bestuurder Met de bestuurlijke druk de zorg goedkoper te maken is voor de bestuurder efficiëntie een belangrijk onderwerp. Potentiële winst wordt gezien in betere en efficiëntere ketenprocessen binnen en buiten de grenzen van een zorginstelling. Een EPD kan hiervoor een belangrijk hulpmiddel zijn. Een ander belangrijk thema is patiëntveiligheid. Waar vroeger medische fouten geaccepteerd werden, zie je tegenwoordig dat de stap naar de rechter (en nog belangrijker, de media) steeds makkelijker gemaakt wordt. Een EPD draagt aanzienlijk bij in de verbetering van patiëntveiligheid omdat bij behandeling alle informatie voorhanden is. Ook in het kader van aansprakelijkheid helpt een EPD, omdat alle behandelinformatie beschikbaar is voor alle partijen. De bestuurder heeft niet altijd belang bij deze transparantie omdat die ook eventuele fouten van zijn organisatie gemakkelijker inzichtelijk maakt voor andere partijen. Het perspectief van de informatiemanager De informatiemanager in zorginstellingen is ervoor verantwoordelijk de informatiehuishouding in het ziekenhuis op orde te houden en vormt vanuit zijn functie de intermediair tussen de gebruikers en de IT-afdeling. Hij zal zich bezighouden met eenduidigheid van vastlegging van informatie en vertalen van eisen en wensen van gebruikers en bestuurders naar functionele eisen die aan applicaties en infrastructuur moeten worden gesteld. Het perspectief van de dienstverleners en ontwikkelaars van zorgsystemen Vanuit dit perspectief wordt vooral gekeken naar de technische keuzen die ertoe moeten leiden dat kan worden voldaan aan de functionele eisen aan applicaties en infrastructuur. Hierbij moeten er afwegingen gemaakt worden ten aanzien van het gebruik van nieuwe technologie die wellicht meer mogelijkheden biedt, maar ook grotere risico’s met zich mee brengt dan al langer bestaande oplossingen.

4.2 Het architectuurmodel Internationaal gezien bestaat er niet één geaccepteerd architectuurmodel. Derhalve is ervoor gekozen uit te gaan van een eenvoudig model, dat aansluit bij gangbare en praktische beschrijvingsmethodieken voor architectuur [52], [53],[61]. Ook in het overheidsdomein is dit een gebruikelijk model [50], [51]. Elke invalshoek is een beschrijving van aspecten die van belang zijn voor verschillende stakeholders: 1. Bedrijfsarchitectuur: beschrijving van de bedrijfsmatige, organisatorische aspecten en van de gerelateerde bedrijfsprocessen;


- 13 -

2.

3.

Informatiesysteem-architectuur: beschrijving van de relevante aspecten van de informatiehuishouding, inclusief functionaliteit van applicaties en infrastructuurvoorzieningen m.b.t. de informatieverwerking; Techniekarchitectuur: concrete benoeming van componenten en hun interacties (protocollen); beschrijving van applicaties, middleware, communicatie.

Bedrijfsarchitectuur Proces

Informatie Informatie (systeem) architectuur

Techniek architectuur Techniek

Figuur 4-1: Beschrijvingsmodel De verschillende deelarchitecturen worden verder uitgewerkt in de hierna volgende hoofdstukken. Hoofdstuk 5 gaat in op de uitgangspunten voor de bedrijfsarchitectuur betrekking hebbend op de inrichting van de basisinfrastructuur en de eisen die moeten worden gesteld aan de infrastructurele voorzieningen en zorgsystemen. Op het niveau van de informatiesysteemarchitectuur gaat het over het vastleggen van de betekenis (semantiek) van gegevens en de methoden om de structuur van informatie (syntax) vast te leggen. Bovendien wordt de vereiste functionaliteit van applicaties en infrastructuurvoorzieningen m.b.t. de informatieverwerking beschreven. Zie daarvoor hoofdstuk 6. Op het techniekniveau gaat het over de concrete benoeming van componenten en hun interacties. Zie hoofdstuk 7.

4.3 Afbakening van de architectuurbeschrijving Het architectuurontwerp richt zich primair op de voorzieningen in de basisinfrastructuur die zorgdragen voor informatie-uitwisseling tussen applicaties in verschillende zorgsystemen en op de interactie tussen die voorzieningen en de applicaties die door zorgmedewerkers binnen instellingen en/of ICT-dienstaanbieders worden gebruikt. Dit betekent dat de architectuurbeschrijving zich vooral richt op de transmurale aspecten van ICT-ondersteuning van zorggerelateerde processen en de interactie met de instellingen. In Figuur 4-2 is dit primaire aandachtsgebied met een rode lijn aangegeven.

- 14 -


) ng ise i l l r t e rp s e In nt E (

l aa r u m ed e ) s d s an ten pri r T x er (E nt E

BedrijfsProces architectuur Inf-systeem architectuur Techniek Techniek architectuur

Figuur 4-2: Primaire aandachtsgebied van de architectuurbeschrijving

4.4 Aspectgebied Beveiliging In alle drie de lagen van het beschrijvingsmodel is informatiebeveiliging van belang (zie Figuur 4-3).

Informatiesysteemarchitectuur Informatie Techniekarchitectuur Techniek

Beveiliging

Bedrijfsarchitectuur Proces

Figuur 4-3: Beveiliging in het beschrijvingsmodel Informatiebeveiliging in de zorg kan alleen goed worden ingevuld met een samenhangend pakket van maatregelen op het gebied van organisatie, bedrijfsprocessen, functionele eisen aan applicaties en infrastructurele voorzieningen en technische implementaties. In ieder van de drie hiernavolgende hoofdstukken is daarom aan dit onderwerp een paragraaf gewijd.


- 15 -

- 16 -


5

De bedrijfsarchitectuur

5.1 Ondersteuning van bedrijfsprocessen in de Zorg De basisinfrastructuur moet er voor worden ontworpen om informatie en communicatiediensten te leveren om de bedrijfsprocessen in het zorgveld te ondersteunen. Het gaat hier om een veelheid aan processen. In figuur 5-1 wordt in een gelaagd zorgprocesmodel aangegeven welke typen processen in de zorg van belang zijn.

Sturende processen Management, patiëntenlogistiek en procesbesturing etc.

Primaire (zorg) processen

Ondersteunende processen Financieel, administratief, goederenlogistiek etc.

Figuur 5-1: Indeling van bedrijfsprocessen in de zorg Dit model kan bijvoorbeeld worden gebruikt om de processen in een zorginstelling te beschrijven. Naast het primaire (zorg-) proces is er in een zorginstelling een aantal sturende processen, bijvoorbeeld strategisch en tactisch management, patiëntlogistieke processen en (zorg-)procesbesturing. Daarnaast zijn er ondersteunende processen, zoals financiële en administratieve processen, goederenlogistiek etc. Zoals al in de inleiding aangegeven zal voor de beschrijving van de architectuur van de basisinfrastructuur geen detailanalyse van alle processen in de zorg worden uitgevoerd. In deze architectuurbeschrijving zal worden aangegeven welke functies minimaal in de basisinfrastructuur noodzakelijk zijn om het totaal van bedrijfsprocessen te ondersteunen. Door de vergaande specialisatie in de zorg, is in deze sector vanouds het samenwerken in ketens van groot belang. Dit belang neemt bovendien nog steeds toe. Deze samenwerking kan plaatsvinden op de diverse niveaus van het zorgprocesmodel, bijvoorbeeld samenwerkingsrelaties tussen huisarts en specialist. In figuur 5-2 is dit illustratief aangegeven voor twee zorginstellingen die in een zorgketen samenwerken.


- 17 -

Zorgketens

Figuur 5-2: Samenwerking in zorgketens Ook kan samenwerking tussen instellingen op logistiek niveau of financieel-administratief niveau plaatsvinden. Afhankelijk van de type samenwerking zijn vaak verschillende ketenpartners betrokken.

5.2 Communicatie in de zorgsector Tot de zorgsector behoren vele partijen. Zij communiceren met elkaar en met partijen buiten de zorgsector. De onderwerpen waarover in hoofdlijnen wordt gecommuniceerd, zijn: medisch inhoudelijk financieel-administratief beleidsinformatief. Medisch inhoudelijke onderwerpen komen vrijwel alleen aan de orde in informatieuitwisseling tussen zorgverleners en instellingen onderling. Het betreft vaak informatie die in patiëntendossiers voorkomt, zowel in dossiers op papier, als elektronische patiëntendossiers (EPD). Zorgverzekeraars zullen in declaraties ook medisch gerelateerde informatie ontvangen, omdat de zorgverlener/instelling moet aangeven waarom een declaratiepost gerechtvaardigd is. Ook behoort de communicatie van medische adviseurs bij zorgverzekeraars met zorgverleners tot de medisch inhoudelijke communicatie. Binnen zorgverzekeraars vindt deze communicatie gescheiden van de pure administratieve communicatie (declaraties, enzovoort) plaats. De medische adviseurs mogen geen patiëntendossiers raadplegen. Financieel-administratieve informatie-uitwisseling is nodig voor de financiële afhandeling van zorg. Dit betreft declaraties, machtigingen, controle op verzekeringsrecht, communicatie met werkgevers, enzovoort Deze communicatie vindt plaats tussen zorgverleners en instellingen aan de ene kant en zorgverzekeraars aan de andere kant. Ook vindt er financieel-administratieve informatie-uitwisseling plaats tussen zorgaanbieders en leveranciers van producten die de zorgaanbieders nodig hebben voor het leveren van zorg. Ook kan met betrekking tot goederenlogistiek gedacht worden aan het naar patiënten brengen van hulpmiddelen. Verder behoren tot de financieel-

- 18 -


administratieve informatie-uitwisseling machtigingsberichten (een zorgverlener machtigen iets te doen), de melding van geleverde zorg en de opgave van productiegegevens zorg door instellingen (AWBZ). Daarnaast vindt ook uitwisseling van besturingsinformatie plaats, bijvoorbeeld de logistieke communicatie met betrekking tot de patiënt tussen en binnen instellingen. Als de patiënt van de ene naar de andere instelling gaat wordt hierover gecommuniceerd. Hetzelfde geldt bij doorverwijzing binnen een instelling naar een andere behandelaar of naar een onderzoeksafdeling (bloed, röntgen, enzovoort). Beleidsinformatie of managementinformatie betreft geaggregeerde informatie die niet tot fysieke personen herleidbaar is. Soms wordt deze informatie wel op individueel niveau verzameld (en vervolgens geanonimiseerd). De onderwerpen kunnen zowel medisch inhoudelijk als financieel-administratief zijn. Naast zorgverleners, instellingen en zorgverzekeraars verzamelen informatie-instituten, CVZ, VWS en brancheorganisaties beleidsinformatie. Hoewel bij beleidsinformatie niet de privacy van personen in het geding is, is deze informatie wel vaak van vertrouwelijke aard.

5.3 Casebeschrijvingen 5.3.1 Inleiding Om snel concrete doelen te kunnen bereiken is gekozen voor een aantal specifieke (start)applicaties dat gebruik maakt van de basisinfrastructuur: e-medicatiedossier, ewaarneemdossier voor huisartsen en e-declareren. Deze applicaties zijn mede gebruikt om te toetsen of de opgestelde eisen van de basisinfrastructuur in de praktijk kunnen voldoen voor een aantal representatieve processen. Inmiddels heeft ook een uitwerking van het e-kinddossier voor de jeugdgezondheidszorg plaatsgevonden, waarvan de hoofdlijnen hieronder worden geschetst.

5.3.2 Case e-medicatiedossier Motivatie Uit een aantal onderzoeken is gebleken dat de kwaliteit van de zorg zal verbeteren door landelijke inzage in de medicatiehistorie van patiënten: • Schattingen van het aantal ziekenhuisopnames door vermijdbare medicatiefouten lopen op tot 90.000 per jaar met € 300 miljoen aan directe kosten [56]; • Als het elektronisch medicatiedossier straks goed functioneert, zullen er door het toepassen van medicatiebewaking aanzienlijk minder medicatiefouten worden gemaakt, zoals is aangetoond in internationale onderzoeken naar elektronisch voorschrijven [57]; • Gebrekkige communicatie tussen zorgverleners is de oorzaak van veel medische fouten [58].


- 19 -

Casebeschrijving Een patiënt wendt zich met een verzoek tot een contact tot een zorgverlener. Dit “contact” kan telefonisch zijn of face-to-face. Tijdens het contact neemt de zorgverlener een anamnese af, doet eventueel onderzoek en komt op basis daarvan tot een werkdiagnose m.b.t. de door de patiënt aangegeven zorgvraag. De zorgverlener besluit tot al dan niet behandelen eventueel met ondersteuning van één of meer geneesmiddelen. Als (onderdeel van de) voorgenomen behandeling ontstaat bij de zorgverlener een voornemen tot het voorschrijven van één of meer geneesmiddelen aan de patiënt. Dit voornemen wordt (indien mogelijk) overlegd met de patiënt en getoetst aan het medicatiedossier en eventueel aan een elektronisch expertsysteem (beslissingsondersteuning). Bij deze toetsing vindt medicatiebewaking plaats, waarbij mogelijk signalering in het geval van ongewenste toepassing kan plaatsvinden. Hierop kan het voorschrift worden aangepast, eventueel op basis van een automatisch voorstel vanuit het EVS ( Elektronisch Voorschrijf Systeem). Een medicatiehistorie heeft altijd betrekking op één individuele patiënt en is opgebouwd of kan opgebouwd zijn uit: • Voorschriften (al dan niet gestopt) • Verstrekkingen • (Toedieningen). Voor het verantwoord voorschrijven en verstrekken kan het ook nodig zijn over andere relevante informatie van de patiënt te beschikken zoals allergieën, contra-indicaties, de reden van voorschrijven etc. Sommige van deze informatie (zoals nierfuncties) is generieker van aard en vallen niet specifiek onder het kopje medicatiehistorie. Op dit moment is, behalve in ziekenhuizen, toedieningregistratie nog niet gebruikelijk. Indien de toediening in de toekomst wel systematisch wordt vastgelegd, zou deze informatie ook opvraagbaar kunnen zijn in de medicatiehistorie. Vooralsnog valt dit buiten de scope. Met het realiseren van het e-medicatiedossier worden alle gegevens waaruit een medicatiehistorie is opgebouwd in principe beschikbaar gesteld door opvraag uit de systemen waar deze informatie is opgeslagen. De ontvanger heeft na ontvangst nog de mogelijkheid de ontvangen gegevens te filteren.

5.3.3 Case e-waarneemdossier huisartsen Motivatie In waarneemsituaties heeft de waarnemende huisarts op dit moment in veel gevallen weinig tot geen informatie beschikbaar over de medische historie van de patiënt. Hieraan is wel veel behoefte omdat zo kwaliteitswinst en een verbeterde efficiëntie kan worden bereikt. Met name door de opkomst van centrale doktersposten, zogenaamde huisartsenposten (HAP’s), ten behoeve van de avond-, nacht- en weekenddienst is de

- 20 -


behoefte aan het kunnen inzien van het patiëntendossier van de vaste huisarts toegenomen.

Casebeschrijving Het e-waarneemdossier richt zich in eerste instantie op het beschikbaar stellen van patiënt-informatie op de huisartsenpost. Er zijn inmiddels in Nederland meer dan honderd huisartsenposten. Patiënten kunnen er buiten kantooruren naartoe voor spoedgevallen. Er zijn artsen beschikbaar die eventueel de patiënt thuis bezoeken. Ook geven medewerkers telefonisch medisch advies. Met het e-waarneemdossier krijgt een huisarts op de huisartsenpost via het daar operationele Huisartspost Systeem (HAPS) inzage in een deel van het patiëntendossier van de vaste huisarts. De beperkte tijd van de waarnemer vereist dat hij/zij snel een compleet beeld van de gezondheidstoestand van de patiënt krijgt. Inzage hebben in een compact overzicht van relevante patiëntinformatie (de professionele samenvatting) is daarbij van belang. De informatie is afkomstig van de vaste huisarts en uitsluitend ter inzage beschikbaar. De bevindingen die gedaan zijn tijdens de waarneming worden elektronisch als retourinformatie naar de vaste huisarts gestuurd en vastgelegd in het dossier.

5.3.4 Case e-declaratie Motivatie De afhandeling van de declaratie voor een medische behandeling kost zorgverleners en zorgverzekeraars tijd en geld, en leidt ook tot ergernissen door de fouten die moeten worden hersteld. Onderzoeken - van Commissie De Beer in 2002 en het College voor zorgverzekeringen (CVZ) in 2003 - laten zien dat de kosten omlaag kunnen worden gebracht en fouten kunnen worden uitgebannen. Op diverse onderdelen van het declaratieverkeer zijn er al initiatieven om deze kosten- en foutenvermindering te realiseren. Een groot aantal partijen in de zorg meent dat het mogelijk is deze initiatieven te versnellen en te verdiepen. De besparingen (inclusief controle verzekering) bedragen naar schatting zo’n 100 miljoen euro per jaar.

Casebeschrijving Het declaratieproces kent een lange weg. De zorgverlener legt gegevens vast over de verzekerde en over de behandeling. Voor de declaratie moeten minimaal polisnummer, geboortedatum, geslacht, verzekeringsmaatschappij en de verrichting(en) geregistreerd worden. Daarna vindt controle op verzekering (COV) plaats. De declaratie wordt vervolgens opgemaakt en op papier via de post of digitaal per diskette, tape, regionaal netwerk of internet aangeboden aan de zorgverzekeraar of een intermediair. De zorgverzekeraar of derde partij verwerkt en betaalt de declaratie of wijst deze af. Ingeval van afwijzing kan de zorgverlener zonodig de declaratie corrigeren of eventueel overleg Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 21 -

voeren met de zorgverzekeraar, om ervoor te zorgen dat de declaratie alsnog door de zorgverzekeraar wordt geaccepteerd en betaald. In het declaratieproces worden zorgverleners opgezadeld met verscheidene administratieve lasten. Zo is de controle op verzekering tijdrovend, omdat het ontbreekt aan één loket voor controle op verzekering van alle verzekerden. Bovendien is de controle niet sluitend. Gegevens van verzekerden kunnen bijvoorbeeld met elkaar worden verward, omdat het ontbreekt aan uniek identificerende middelen. Ook stellen niet alle verzekeraars hun bestanden voor raadpleging beschikbaar. En de bestanden die wel beschikbaar worden gesteld, zijn niet altijd actueel. Dit komt onder meer door de toenemende mobiliteit van verzekerden. Daarnaast is het opmaken en indienen van declaraties bewerkelijk. Ook hier ontbreekt het aan één loket waar zorgverleners alle declaraties kunnen aanbieden. De praktijk is nu veelal dat zorgverleners bij tien tot vijfentwintig zorgverzekeraars declaraties moeten indienen. Dat is lastig, te meer omdat zorgverzekeraars afwijkende berichten retour sturen wanneer een declaratie wordt afgewezen. Retourberichten worden bovendien nog maar zeer beperkt elektronisch verstuurd. Daar komt nog bij dat zorgverleners de beleidsregels en tariefrichtlijnen ten aanzien van declaraties vaak als multi-interpretabel ervaren. ICT kan een oplossing bieden om de administratieve lasten die het declaratieproces met zich meebrengt te verlichten en het zorgverleners en zorgverzekeraars zo gemakkelijk mogelijk te maken. Om de veranderdoelstelling van het programma te kunnen realiseren zal het declaratieproces tussen zorgaanbieder en zorgverzekeraar volledig elektronisch moeten gaan plaatsvinden met een afwijzingspercentage lager dan 1%. Er dient voor te worden gezorgd dat de verschillende zorgaanbieders, te weten ziekenhuizen, tandartsen, fysiotherapeuten, overige paramedici, huisartsen, hulpmiddelen leveranciers, met alle zorgverzekeraars (ziekenfondsen, particuliere zorgverzekeraars) elektronisch informatie kunnen uitwisselen.

5.3.5 Case e-kinddossier jeugdgezondheidszorg Motivatie Het realiseren van een integraal e-kinddossier voor de jeuegdgezondheidszorg (EKD) voor 0 – 19 jarigen is nodig voor een kwalitatief sterk integrale jeugdgezondheidszorg. Dat wil zeggen dat zorgverleners te allen tijde over de meest actuele en relevante cliëntgegevens kunnen beschikken en gegevens elektronisch worden uitgewisseld tussen de jeugdgezondheidszorginstellingen. Elektronische registratie maakt het bovendien mogelijk beleids - en bedrijfsvoeringinformatie ten behoeve van landelijke ontwikkeling van de jeugdgezondheidszorg beschikbaar te stellen.

- 22 -


Casebeschrijving De informatisering moet er toe leiden dat zorgprofessionals effectief de taken kunnen uitvoeren zoals die beschreven zijn in het basistakenpakket. Ook krijgen beleidsmakers beter inzicht in de actuele gezondheidstoestand en de zorgbehoefte van de jeugd. Op basis van de informatie kan beleid worden bepaald of worden aangepast. De entadministraties zijn verantwoordelijk voor coördinatie van drie nationale preventieprogramma’s: onderzoek aangeboren stofwisselingsziekten bij pasgeborenen (neonatale screening), rijksvaccinatieprogramma en bloedonderzoek bij zwangere vrouwen (pre- en postnatale screening). Het belangrijkste voordeel dat met elektronische uitwisseling van gegevens kan worden bereikt, is het organiseren en bewaken van werkprocessen, die steeds complexer worden door een grote diversiteit aan klanten en een groter aantal samenwerkingsrelaties met andere organisaties. Hierdoor kan de onderlinge afstemming van het handelen tussen professionals, maar ook tussen organisaties binnen en buiten het JGZ-veld worden verbeterd en kan een betere en intensievere samenwerking in de keten worden gerealiseerd.

5.4 Eisen vanuit de patiënt Naast de eisen ten aanzien van zorgvuldigheid en bescherming van de privacy zal de patiënt op een aantal manieren betrokken zijn bij de informatievoorziening: • (Mede) bepalen wie wel of niet toegang mag krijgen tot de gegevens. Dit wordt vormgegeven door de mogelijkheid voor patiënten een uitgebreid autorisatieprofiel in te stellen. • Toegang tot de logging-gegevens om te kunnen controleren wie toegang heeft verkregen tot welke gegevens van de patiënt. • Toegang tot gegevens in verwijsindex en/of eigen dossier. • Aanmelden van en toegankelijk maken van “eigen” medische gegevens, bijvoorbeeld bij zelfmeting, zelfdiagnose of zelfmedicatie en het kader van op afstand door zorgverleners begeleide trajecten. In de beginsituatie wordt slechts beperkt invulling gegeven aan deze eisen: middels een procedure kan de patiënt, indien gewenst, toegang tot zijn gegevens blokkeren. Indien wel invulling wordt gegeven aan bovengenoemde eisen zal voor de patiënt en/of zijn informatiesysteem beveiligde toegang tot de AORTA basisinfrastructuur moet worden geregeld.

5.5 Eisen vanuit de zorgprocessen


- 23 -

5.5.1 Algemeen De basisinfrastructuur dient breed te kunnen worden ingezet ter ondersteuning van de processen in de zorg. Veel medische beroepsbeoefenaren gebruiken computersystemen voor het opslaan en verwerken van informatie. Huisartsen en specialisten willen in toenemende mate van deze systemen gebruik kunnen maken voor het voorschrijven van geneesmiddelen en voor het versturen van recepten naar apotheken. Evenzo willen apothekers hun computersystemen kunnen gebruiken voor de afhandeling van recepten en, waar gewenst, voor rapportage over de verstrekking van geneesmiddelen aan huisartsen en specialisten. Daarnaast zullen medewerkers van zorginstellingen steeds meer gebruik gaan maken van communicatievoorzieningen voor de uitwisseling van logistieke, financieel-administratieve en statistische informatie.

5.5.2 Communicatie Generieke connectiviteit Als primaire basisvoorziening zal generieke connectiviteit tussen alle aangesloten zorgaanbieders en zorgverzekeraars moeten worden geboden op basis van Internettechnologie.

Opvragen van patiëntinformatie Zoals blijkt uit de voorgaande casussen is het opvragen van allerlei soorten patiëntgegevens een belangrijke functie ter ondersteuning van het primaire (zorg-) proces is. De relatie met het zorgproces is dan relatief eenvoudig, namelijk het verkrijgen van die informatie over de patiënt die relevant is voor de behandeling van de patiënt. Door het verkrijgen van overzichten, bijvoorbeeld op het gebied van medicatie, kunnen allerlei toegevoegde gebruiksmogelijkheden worden ontsloten waardoor de zorgverlener efficiënter en effectiever kan gaan werken. Voorbeelden hiervan zijn het gebruik van profielen voor specifieke behandelingen zodat alleen relevante informatie voor die behandeling wordt gepresenteerd, medicatiebewaking, etc. Vanuit het zorgproces worden de volgende de serviceniveaus geformuleerd voor het opvragen van patiëntgegevens: De openstellingtijd van de dienstverlening dient 7 x 24 uur te zijn; De beschikbaarheid van de dienstverlening dient minimaal 99% te bedragen; in de specificaties wordt dit nader uitgewerkt. Responsetijden voor het ophalen van patiëntgegevens op landelijk niveau: • De zorgverlener wil gemiddeld binnen 2, maar maximaal 4 seconden na opvraag het overzicht van beschikbare gegevens gepresenteerd krijgen; • De zorgverlener wil voor normale bevragingen gemiddeld binnen 5, maar maximaal 10 seconden na opvraag de inhoudelijke patiëntgegevens gepresenteerd krijgen; • De zorgverlener wil gemiddeld binnen 10, maar maximaal na 20 seconden na opvraag van grote hoeveelheden informatie, bijvoorbeeld totale dossiers of

- 24 -


multimediale patiëntgegevens, de gegevens gepresenteerd krijgen. De maximale grootte van bestanden waarvoor dit geldt, dient nog nader te worden bepaald. In de specificaties wordt dit per type bevraging nader uitgewerkt. Volledigheid; de zorgverlener dient inzicht te hebben: • of de beschikbare informatie compleet is; • welke informatie weliswaar wel aanwezig is, maar niet (technisch) beschikbaar: de kans dat de gevraagde informatie niet volledig is dient voor normale bevragingen niet groter te zijn dan 2 à 3%; • welke informatie wel aanwezig zou kunnen zijn, maar niet toegankelijk is voor de zorgverlener, omdat hij daarvoor niet is geautoriseerd.

Versturen van informatie Om berichten, bijvoorbeeld voor een verzoek, een antwoord of een melding, te kunnen versturen naar een andere applicatie, zorgaanbieder of zorgverzekeraar, zou de verantwoordelijke verzendende applicatie, zorgaanbieder of zorgverzekeraar precies moeten weten wáár en hóe die ander bereikbaar is. Daarom is er behoefte aan: • een zorgaanbiedergids die aangeeft welke zorgaanbieders en zorgverzekeraars beschikbaar zijn en die informatie bevat over die partijen, bijvoorbeeld hoe zij bereikbaar zijn; • een verzenddienst die dergelijke berichten aflevert bij de desbetreffende postbus; • een postbus als individueel verzamelpunt voor inkomende post voor iedere applicatie, zorgaanbieder of zorgverzekeraar. In de praktijk kan het gebeuren dat een zorgaanbieder een verzoekbericht klaarzet, maar deze niet kan versturen, omdat de patiënt nog zelf de bestemde zorgaanbieder wil uitkiezen. Bijv. een huisarts die niet weet aan wie hij een medicatieopdracht moet sturen, omdat zijn patiënt nog niet weet bij welke apotheek hij de medicijnen wil afhalen. De basisinfrastructuur zal deze vorm van uitgestelde aflevering moeten ondersteunen.

Dossieroverdracht Hoewel in de AORTA-architectuur wordt uitgegaan van het principe dat waar mogelijk de opslag van patiëntgegevens in het bronsysteem blijft waar de invoer door de zorgverlener heeft plaatsgevonden, zijn er toch situaties (bijv. verhuizing, beëindigen van de praktijk etc.) waarbij het dossier(deel) van een bepaalde zorgverlener wordt overgedragen naar een andere zorgverlener (zie hiervoor bijvoorbeeld [65]). Dit kan uitsluitend na toestemming van de patiënt en nadat door betrokken zorgverleners duidelijke afspraken zijn gemaakt over de (overdracht van) verantwoordelijkheden.

Abonneren op gegevens Wanneer een zorgverlener interesse heeft in (patiënt)gegevens die nu nog niet beschikbaar zijn, bijv. een labuitslag, wil hij misschien gewaarschuwd worden wanneer


- 25 -

deze wél beschikbaar komen. Daartoe moet hij zich kunnen aan- en afmelden om deze waarschuwing eenmalig of voortdurend te ontvangen.

5.5.3 Unieke identificatie en authenticatie Patiëntidentificatie en authenticatie Bij de eerste keer dat een patiënt bij een zorgaanbieder langs komt na inwerkingtreding van de Wet gebruik burgerservicenummer in de zorg, moet deze altijd het geldig wettelijk identiteitsdocument van de patiënt controleren. Aard en nummer van het geldig wettelijk identiteitsdocument moeten worden vastgelegd in de administratie van de zorgaanbieder. Om de patiënt eenduidig te kunnen identificeren zal gebruik worden gemaakt van een landelijk uniek identificatienummer, het burgerservicenummer (BSN). In de basisinfrastructuur dienen voorzieningen aanwezig te zijn om dat unieke identificatienummer vast te stellen aan de hand van een set identificerende gegevens. Bij communicatie over patiënten wordt er van uitgegaan dat alle zorgsystemen gebruikmaken van het unieke identificatienummer. Om op termijn ook te kunnen voldoen aan de geformuleerde eisen in paragraaf 5.4, zal ook de elektronische identiteit van de patiënt moeten worden geregeld (authenticatie).

Zorgverlener-identificatie en authenticatie Voor het verbeteren van de informatie-uitwisseling in de zorg is een betrouwbare elektronische identiteit van zorgverleners een absolute noodzaak. Dit betekent dat de zorgmedewerker dient te kunnen worden geïdentificeerd met behulp van een uniek nummer. Daarnaast dient eenduidig te kunnen worden vastgesteld of de huidige communicatiepartner inderdaad de geïdentificeerde zorgverlener is (authenticatie). Het begrip zorgverlener is breder dan de strikte omschrijving van beroepsbeoefenaars als bedoeld in de artikelen 3 en 34 van de wet BIG. Zorgverleners die hier buiten vallen worden wel aangeduid met de term Vierde Domein in de Zorg (VDZ). Hiervoor zal ook de identificatie en authenticatie geregeld moeten worden willen deze partijen toegang kunnen krijgen tot de basisinfrastructuur.

Zorgverzekeraar-identificatie en authenticatie Voor communicatie met zorgverzekeraar is ook een unieke zorgverzekeraar-identificatie noodzakelijk. Onder deze groep worden onder meer gerekend: ziekenfondsen, particulier ziektekostenverzekeraars, gevolmachtigde assurantietussenpersonen en zorgkantoren. Naast de identificatie zal op termijn ook de authenticatie van deze partijen geregeld moeten zijn om toegang te krijgen tot de basisinfrastructuur.

5.5.4 Loggingfunctie De basisinfrastructuur dient voor het verkeer waarvoor dat gewenst is te zorgen voor vastlegging van het feit dat berichten zijn uitgewisseld. Deze vastlegging kan dienen als

- 26 -


onafhankelijk bron om de rechtmatigheid van toegang achteraf te kunnen toetsen of in geval van disputen tussen zorgverleners de gang van zaken rond uitgevoerde transacties te kunnen vaststellen. Logging dient in ieder geval te geschieden voor de toegang tot patiëntgegevens.

5.5.5 Beveiliging Algemeen Voor een succesvolle en grootschalige invoering is het van belang dat zorgaanbieders en zorgverzekeraars die gaan communiceren dit doen op het vereiste beveiligingsniveau dat geldt voor het type informatie dat wordt uitgewisseld. In dit document wordt vooral ingegaan op de beveiligingseisen die minimaal noodzakelijk zijn voor het ondersteunen van informatiestromen voor de hoogste beveiligingsniveaus. De zekerheidsstructuur voor de zorg dient daartoe de volgende diensten te leveren: o Garanderen van de Vertrouwelijkheid van communicatie (door encryptie) om ervoor te zorgen dat onbevoegden geen kennis kunnen nemen van de verzonden informatie. o Identificatie en Authenticatie van zorgsystemen, zorgverleners en verzekeraars om er zeker van te zijn dat het systeem en/of de persoon waarmee wordt gecommuniceerd inderdaad degene is die hij beweert te zijn. o Op basis van een correcte authenticatie kan worden bepaald welke rechten deze persoon heeft (Autorisatie). o Handhaven van de Integriteit van informatie om onbevoegd wijzigen van informatie te voorkomen. o Zorgdragen voor de Onweerlegbaarheid van opvragen en verzenden van informatie om rechtsgeldige handelingen via elektronische communicatie te kunnen verrichten. Daarnaast dienen de aangesloten zorgsystemen te voldoen aan een aantal minimumeisen op het gebied van beschikbaarheid, betrouwbaarheid en beveiliging.

Vertrouwelijkheid De zorgverlener is overeenkomstig de WBP en de WGBO in eerste instantie verantwoordelijk voor het waarborgen van de vertrouwelijkheid en de bescherming van de persoonsgegevens. De basisinfrastructuur dient de zorgverlener voldoende garanties te kunnen bieden dat de vertrouwelijkheid van de gegevens wordt gewaarborgd.

Identificeren en authenticeren Alleen zorgsystemen die eenduidig kunnen worden geïdentificeerd en geauthenticeerd, mogen worden aangesloten op de basisinfrastructuur. Een zorgverlener kan alleen transacties uitvoeren en informatie opvragen via de basisinfrastructuur indien zijn (elektronische) identiteit kan worden vastgesteld. Een Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 27 -

hoger beveiligingsniveau stelt ook hogere eisen aan de zekerheid waarmee de elektronische identiteit correct kan worden bepaald.

Autorisatie Voorkomen moet echter worden dat de patiëntengegevens toegankelijk worden voor onbevoegden. Ook zorgverleners (individueel niveau) en zorgaanbieders (organisatieniveau) zijn niet bij voorbaat bevoegd om over alle patiëntengegevens te beschikken. Toegang tot patiëntengegevens mag in beginsel alleen als dat noodzakelijk is voor de behandeling van de patiënt. In bepaalde gevallen mag daarbij worden uitgegaan van veronderstelde toestemming van de patiënt (zie hiervoor [66]). Bij autorisatie dient in eerste instantie duidelijk te zijn wie en onder welke voorwaarden, toegang mag krijgen tot de beschikbare patiëntengegevens. Naast wettelijke bepalingen zijn ook de wensen en ervaringen van patiënten van belang. Wanneer een andere zorgaanbieder patiëntgegevens wil opvragen, moet de verantwoordelijke zorgaanbieder strikt genomen voor individuele gevallen persoonlijk bepalen: heeft de andere zorgaanbieder een behandelrelatie? is de andere zorgaanbieder rechtstreeks betrokken? is er toestemming of bezwaar van de patiënt? is het noodzakelijk de patiëntgegevens in te zien? is de privacy van een derde in het geding? is er sprake van een noodsituatie? In de praktijk is zo’n persoonlijke controle per keer onwerkbaar: de opvragende zorgaanbieder zal geen direct antwoord krijgen als de verantwoordelijke zorgaanbieder niet bereikbaar is (afwezig, even van zijn plaats, wil niet gestoord worden, etc.) en/of als nog toestemming aan de patiënt moet worden gevraagd. De winst van elektronische uitwisseling van patiëntgegevens zou daarmee teniet worden gedaan. De zorgverlener dient daarom te kunnen vertrouwen op een autorisatiefunctie om ervoor te zorgen dat zorgaanbieders alleen díe patiëntgegevens kunnen inzien waarvoor zij gerechtigd zijn op grond van hun functie of rol5 en de wensen van de patiënt. Er zijn twee autorisatiemechanismen denkbaar: 1. Generieke toegankelijkheid, waarbij op basis van de functie of rol van de zorgverlener wordt bepaald of hij toegang heeft tot patiëntgegevens, tenzij dit expliciet

5

Bij het begrip “functie” of “rol” van de zorgverlener zijn twee aspecten van belang: de zorgverlenerfunctie,

bijvoorbeeld aangeduid met beroepstitel en specialisme (dit meer statische aspect wordt in [55] aangeduid met “structural role”) en de betrokkenheid van een zorgverlener bij een behandeling (dit meer dynamische aspect wordt in [55] “functional role” genoemd).

- 28 -


(bijvoorbeeld door de patiënt) is verboden. Dit is de meest open oplossing en vraagt relatief weinig administratieve afhandeling van de zorgverlener. Voor deze oplossing is het noodzakelijk na vaststellen van de identiteit, de functie of rol van de zorgverlener te bepalen. Op basis van deze vaststelling kan de verantwoordelijke zorgverlener dan (desgewenst selectief) toegang geven tot informatie. 2. Specifieke toegankelijkheid, waarbij de "verantwoordelijke” zorgverlener expliciet toestemming geeft aan bepaalde personen (bijvoorbeeld een specialist bij doorverwijzing) om informatie in te zien; dit sluit, ook juridisch, beter aan bij de huidige praktijk. Nadeel is dat de "verantwoordelijke zorgverlener" steeds expliciet toegang moet geven aan andere zorgverleners indien zij niet rechtstreeks bij de behandeling van de patiënt zijn betrokken. Zorgverleners worden dan op basis van hun identiteit geautoriseerd. Bij toegangverlening op basis van een specifieke identiteit dient er wel een “noodprocedure” met bijbehorende (gecontroleerde) logging te worden ingericht voor de situatie dat een patiënt in een noodsituatie terechtkomt bij een zorgverlener die niet is geautoriseerd zijn (medische) gegevens in te zien. Voor beide mechanismen is betrouwbare identificatie en authenticatie van zorgverleners noodzakelijk. Er zijn goede redenen deze functies bij een vertrouwde derde partij te beleggen, een zogenaamde 'Trusted Third Party (TTP)’. Technisch zijn er goede mechanismen voor de verificatie van identiteit en authenticiteit voor elektronische communicatie via een zogenoemde 'Public Key Infrastructure (PKI)’. Voor de basisinfrastructuur is gekozen voor het volgende autorisatiemechanisme: • Autorisatie vindt plaats op basis van de zorgverlenerfunctie. Het autoriseren op basis van een vastgestelde (en geregistreerde) betrokkenheid van alle zorgverleners bij een behandeling wordt niet gezien als een haalbare oplossing. Om te bepalen tot welke gegevens een zorgverlener in een bepaalde functie toegang krijgt, zal een autorisatieprotocol moeten worden opgesteld. • Samenwerkende zorgaanbieders die willen aansluiten op de basisinfrastructuur moeten akkoord gaan met het autorisatieprotocol en met de verklaring dat zij zich aansprakelijk stellen voor eventueel misbruik. Op deze wijze wordt de verantwoordelijke zorgaanbieder zoveel mogelijk gevrijwaard van aanspraken op zijn beroepsgeheim. Zonder deze waarborg zullen zorgaanbieders hun patiëntendossiers niet willen aansluiten op de basisinfrastructuur. • Het autorisatieprotocol is generiek en heeft derhalve betrekking op alle patiëntendossiers die toegankelijk zijn via de basisinfrastructuur. • Het autorisatiemechanisme dient ook rekening te houden met de wensen van de patiënt voor zover deze kenbaar zijn gemaakt. Daartoe dient de basisinfrastructuur te voorzien in een centraal in te stellen autorisatieprofiel, waarin per patiënt kan worden vastgelegd welke beperkingen er in acht moeten Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 29 -

•

•

6

worden genomen bij toegang tot zijn gegevens. Technisch gezien kan in het autorisatieprofiel worden gedifferentieerd naar: o zorgverlenerfunctie6 en/of identiteit van de zorgpartij o gegevensklasse, bijvoorbeeld persoonlijke gegevens, medische gegevens etc. o bevoegdheden per combinatie van zorgverlenerfunctie en gegevenssoort, bijvoorbeeld altijd, alleen in noodgeval, alleen na expliciete toestemming, nooit, etc. Uiteindelijk dient in de basisinfrastructuur een voorziening te zijn opgenomen waarmee patiënten zelf hun autorisatieprofiel kunnen aanpassen. Dat zou bijvoorbeeld mogelijk kunnen worden zodra de e-NIK (elektronische nationale identiteitskaart) of een andere ’sterke’ authenticatievoorziening voor de burger gerealiseerd is. Patiënten zouden met zo’n authenticatiemiddel gebruik kunnen maken van ‘informatiekanalen’ als het openbare internet, elektronische zuilen in ziekenhuizen, et cetera, om via een patiëntenportaal (bijvoorbeeld KiesBeter.nl) toegang te krijgen tot de basisinfrastructuur. Op deze wijze kan de patiënt (op termijn) toegang krijgen tot informatie die op hem betrekking heeft en zelf autorisaties instellen om zo te bepalen wie wel of geen toegang heeft tot zijn gegevens. In de beginsituatie wordt gebruik gemaakt van een beperktere invulling van het autorisatieprofiel (alleen aan/uit), waarbij instelling ervan niet rechtstreeks door de patiënt hoeft plaats te vinden. Voor het beheer van het autorisatieprofiel dienen dan aanvullende procedures te worden opgesteld. Gedacht wordt aan een nog nader aan te wijzen autorisatiebeheerder die op basis van een schriftelijk verzoek van een patiënt, de toegang tot zijn medische gegevens kan vrijgeven en blokkeren. Indien een patiënt geen toestemming geeft voor elektronische uitwisseling van ’zijn’ gegevens mogen in het Landelijk Schakelpunt (LSP) van die patiënt geen verwijzingen naar gegevens worden opgenomen. De verantwoordelijke zorgaanbieder kan onder bepaalde voorwaarden activiteiten delegeren naar een medewerker (de zogenaamde “voorbehouden handelingen” ook wel bekend onder de aanduiding “verlengde arm”). Dit kan alleen naar een specifieke medewerker, van wie ook de elektronische identiteit moet kunnen worden vastgesteld. De verantwoordelijke zorgaanbieder blijft aanspreekbaar op zijn beroepsgeheim, daarom moet hij ongeacht het autorisatieprotocol en het autorisatieprofiel uiteindelijk zelf kunnen bepalen welke gegevens wel of niet worden vrijgegeven om te kunnen worden ingezien door andere zorgaanbieders.

Het beroep met een of meer gerelateerd(e) specialisme(n) dat een zorgverlener daadwerkelijk uitoefent vanuit een bepaalde

individuele vestiging of volgens zijn aanstelling binnen een zorginstelling.

- 30 -


Voor de autorisatiefunctie is nog een afweging te maken of dit lokaal in de applicaties van zorgsystemen of als gemeenschappelijke voorziening in de infrastructuur dient te worden belegd. Uitgangspunt voor deze beschouwing is dat veel informatievragen op basis van generieke toegankelijkheid (dus op functie) kunnen worden afgehandeld. Slechts voor een deel van de informatievragen zal specifieke toegankelijkheid op basis van identiteit moeten worden geregeld. Dit opent de mogelijkheid om de autorisatiefunctie als een onderdeel van de gemeenschappelijke voorziening in de infrastructuur op te nemen. Hierdoor kan zowel de generieke toegankelijkheid (toegang op functie van de zorgverlener) als de specifieke toegankelijkheid (wens van de patiënt) op één plaats worden vastgelegd en beheerd en tevens eenduidig voor alle toegangsvragen worden geëffectueerd. Bovendien ontstaat voor de patiënt transparantie in de ingestelde autorisaties. Aangesloten zorgsystemen en applicaties kunnen derhalve gebruik maken van de autorisatiefunctie als een gemeenschappelijke voorziening.

Integriteit en onweerlegbaarheid Binnen de basisinfrastructuur moet de integriteit van berichten en de onweerlegbaarheid van aanvragen kunnen worden gegarandeerd. Daarvoor zijn de volgende methoden in overweging genomen: Het gebruik van de volgende combinatie van maatregelen: o waarborgen van de integriteit van het transport o adequate authenticatie van zorgverleners o een sluitend loggingsmechanisme voor alle informatieaanvragen en transacties die via de basisinfrastructuur plaatsvinden Het bewaken van de integriteit van een bericht en het realiseren van onweerlegbaarheid dat dit bericht door een bepaalde persoon is verzonden, door het zetten van een elektronische handtekening. Het zetten van een “formele” elektronische handtekening onder ieder te verzenden bericht is omslachtig voor de gebruiker. Indien een voldoend hoog beveiligingsniveau voor authenticatie wordt gekozen zal ook de eerste methoden kunnen voldoen. Vandaar dat ervoor wordt gekozen in de gemeenschappelijke voorzieningen te kiezen voor het eerste mechanisme. In specifieke situaties kan het echter zinvol zijn gebruik te maken van de elektronische handtekening, zodat deze ook dient te worden ondersteund.

5.6 Diensten van de basisinfrastructuur Op grond van de eerder geïdentificeerde eisen uit de bedrijfsprocessen in de zorg zal de primaire taak van de basisinfrastructuur zijn het leveren van de volgende informatie- en communicatiediensten: 1. Het op aanvraag leveren van een overzicht van beschikbare informatie over een patiënt, na controle of de aanvrager geautoriseerd is deze informatie in te zien. Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 31 -

2. Het opleveren van patiëntinformatie uit aangesloten systemen, na controle of de aanvrager geautoriseerd is deze informatie in te zien. 3. Het uitwisselen van berichten tussen postbussen en/of applicaties van zorgsystemen van zorgpartijen voor een veelheid van applicaties in de zorg. 4. Het leveren van informatie over de identiteit van zorgverleners als intermediair voor bevraging van het registratieregister van zorgverleners. 5. Het leveren van het patiëntidentificatie als intermediair voor bevraging van het register dat deze informatie kan leveren. 6. Het abonneren op patiëntgegevens; wanneer een zorgverlener interesse heeft in patiëntgegevens die nu nog niet beschikbaar zijn (bijvoorbeeld een laboratoriumuitslag) kan hij zich aanmelden bij de basisinfrastructuur, zodat hij gewaarschuwd wordt wanneer deze informatie beschikbaar komt. 7. Uitgestelde aflevering van berichten; in sommige gevallen is bij een verwijzing of het uitschrijven van een recept nog niet bekend bij welke zorgaanbieder deze informatie beschikbaar moet komen. Met deze voorziening kan een dergelijk bericht worden klaargezet om te worden opgehaald wanneer dit wel duidelijk is. 8. Het bieden van interconnectiviteit op netwerkniveau tussen aangesloten systemen onderling en tussen aangesloten systemen en functies geleverd door de basisinfrastructuur.

5.7 Organisatorische aspecten van de basisinfrastructuur 5.7.1 Algemeen Voor het leveren van de diensten van de basisinfrastructuur is de samenwerking tussen een aantal dienstenleveranciers vereist. Dit wordt gevisualiseerd in Figuur 5-3. Zo moet het mogelijk zijn een aantal identificerende registers te raadplegen die worden beheerd door registerhoudende partijen, zoals CIBG voor het zorgverlenerregister (UZI-register). In essentie zal een organisatorische eenheid, hier genoemd het Landelijk Schakelpunt (LSP), de diensten leveren die kunnen worden samengevat onder het kopje “verwijzend stelsel”. De technische voorziening om deze diensten te leveren wordt aangeduid met de term ZorgInformatie Makelaar (ZIM). Dit zorgt ervoor dat medische informatie over patiënten die ligt opgeslagen in de verschillende zorgsystemen (AIS, HIS, ZIS, ZAIS) van zorgpartijen, op een veilige en betrouwbare manier benaderd kan worden. Vanwege het belang van deze nutsfunctie wordt het LSP gezien als een publieke taak. Om de markt zoveel mogelijk ruimte te geven, worden alleen de hoogstnoodzakelijke functies in de ZIM ondergebracht. Het leveren van diensten aan zorgpartijen kan derhalve worden overgelaten aan marktpartijen, de zogenaamde Zorg Service Providers (ZSP’s). ZSP’s zorgen ervoor dat de systemen van zorgpartijen aangesloten zijn op de ZIM. Naast toegang tot de ZIM kunnen partijen aanvullende diensten bieden zoals bijvoorbeeld specifieke content etc. Om betrouwbaarheid en beveiliging te kunnen waarborgen dienen LSP, ZSP’s en Zorgpartijen te worden gecertificeerd, alvorens ze op de basisinfrastructuur worden toegelaten.

- 32 -


Registerhouders

Landelijk Landelijk Beheerder SchakelPunt(LSP SchakelPunt (LSP))

Zorg Service Providers(ZSP’s (ZSP’s))

Zorgpartijen

Figuur 5-3: Organisatorische relaties tussen betrokken partijen Steeds meer services zijn en worden in regionaal verband ontwikkeld, hetzij rondom ziekenhuis-verzorgingsgebieden hetzij in een zogenoemde Ring of enig ander verband. Daarbij kan het volgende geconstateerd worden: • Er is geen eenduidig bestuurlijk concept voor alle regio’s en er is geen wettelijke regeling (zoals bv bij politieregio’s) die hiervoor kaders afdwingt. • Door vele betrokkenen is geconstateerd dat 80-90% van alle communicatie binnen een regio plaatsvindt. Naar verwachting zullen regionale samenwerkingverbanden een belangrijke rol gaan vervullen om de wensen van zorgaanbieders te bundelen en als intermediair naar ZSP’s op te treden.

5.7.2 De Registerhouders Het UZI-register Voor de identificatie en authenticatie van zorgaanbieders is het Unieke Zorgverleners Identificatie register (UZI-register) ingericht. Hiervoor geeft het UZI-register aan zorgaanbieders een elektronische identiteit, waarmee zij zichzelf kunnen authenticeren, waarmee zij de vertrouwelijkheid in de communicatie kunnen borgen en waarmee zij een elektronische handtekening kunnen zetten. Deze elektronische identiteit wordt praktisch vormgegeven via een zogenaamde UZI-pas. Met behulp van een paslezer op de computer van de zorgaanbieder wordt de elektronische identiteit opgehaald en kan deze vanaf de computer gebruikt worden in beveiligde communicatie. Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 33 -

In het UZI-register worden die zorgverleners opgenomen die ook in het BIG-register of in het “Kwaliteitsregister paramedici” zijn opgenomen: • BIG-register (ondergebracht bij het CIBG): apothekers, artsen (huisartsen en medisch specialisten), fysiotherapeuten, gezondheidszorgpsychologen, psychotherapeuten, tandartsen, verloskundigen en verpleegkundigen • Kwaliteitsregister paramedici (ondergebracht bij het CIBG): diëtisten, ergotherapeuten, logopedisten en foniatristen, mondhygiënisten, oefentherapeuten Mensendieck en César, radiologisch laboranten, orthoptisten, podotherapeuten, optometristen, huidtherapeuten.

Het UZOVI-register UZOVI is de Unieke ZOrgVerzekeraarsIdentificatie. Deze identificatie is per januari 2004 opgenomen in het zogenaamde UZOVI-register dat bij Vektis is ondergebracht. Het register bevat: • ziekenfondsen; • particuliere ziektekostenverzekeraars; • gevolmachtigde assurantietussenpersonen; • zorgkantoren; • labelorganisaties; • nevenvestigingen. Het UZOVI-register vervangt per 15 september 2005 de Zorgverzekeraarstabel (ZV-tabel) van Vektis. Dat betekent dat het ZV-nummer (Code Zorgverzekeraar) wordt vervangen door het UZOVI-nummer. Het register is ontwikkeld om eenduidig vast te stellen wie een zorgverzekeraar is. Dit register draagt, samen met het UZI-register voor zorgverleners en het BSN voor patiënten, bij aan de integriteit, authenticiteit en vertrouwelijkheid van elektronische communicatie. Het UZOVI-register wordt momenteel door Vektis beheerd. De mogelijkheid bestaat dat VWS (of een uitvoeringsinstantie van VWS) dit beheer overneemt en het aantal UZOVIpartijen in dat geval beperkt wordt. De partijen die dan niet meer onder het UZOVIregister vallen, worden dan mogelijk overgeheveld naar het ’vierde domein’ (zie onder). Om ook zorgverzekeraars toegang te verlenen dient voor hen identificatie en authenticatie op basis van PKI-certificaten te worden geregeld. Een mogelijkheid is om het UZOVI-register onderdeel van de PKI voor de zorg te maken en certificaten te laten uitgeven.

SBV-Z Iedereen die een relatie heeft met de Nederlandse overheid, krijgt een uniek persoonsnummer: het Burger Service Nummer (BSN). Daarmee wordt de dienstverlening

- 34 -


door de overheid eenvoudiger, verdwijnt een aantal technische barrières bij de uitwisseling van persoonsgegevens tussen overheidsorganisaties en komt de eenmalige gegevensverstrekking door burgers een stap dichterbij. Ook kan de bestrijding van fraude doelmatiger plaatsvinden. Het Burger Service Nummer wordt gebaseerd op het bestaande sofi-nummer. Momenteel wordt gewerkt aan wetgeving die het mogelijk maakt om, onder voorwaarden, het BSN te gebruiken in de zorg. Het BSN wordt uitgegeven op basis van het GBA en het nog op te richten Register NietIngezetenen. Vanuit het ministerie van BZK zal voor het beheer van het BSN een algemene BeheerVoorziening BSN (BVBSN) worden ingericht. Voor elke sector waarin het BSN toegepast mag worden, zal door de verantwoordelijke minister een Sectorale Berichten Voorziening (SBV) ingericht worden. Deze sectorale voorziening zorgt voor de uitgifte van, intrekking van en controle op het BSN. Toegang tot de SBV voor de Zorg (SBV-Z) kan via het LSP verlopen. Ook kan de SBV-Z direct (zonder tussenkomst van het LSP) benaderd worden.

Het VDZ-register Niet alle partijen die communiceren over patiënten zijn opgenomen in het UZI- of UZOVIregister. Voor de unieke identificatie en authenticatie van deze partijen in het zogenoemde ‘vierde domein’ wordt op termijn een register voorzien, het VDZ-register (Vierde Domein Zorg).

5.7.3 Landelijk Schakelpunt De primaire taak van het LSP is het leveren van informatie- en routeringsdiensten op vastgestelde dienstenniveaus. Om deze diensten te kunnen leveren, dient te worden voorzien in het beheer van de gemeenschappelijke faciliteiten (ZIM) en de verbindingen met de buitenwereld, het bewaken van het berichtenverkeer en het ingrijpen bij dreigende of optredende storingen. Dit wordt verzorgd door het LSP.

5.7.4 Zorg Service Providers De ZSP’s, als intermediair voor aangesloten zorginstellingen, kunnen de informatie- en routeringsdiensten verrijken met aanvullende informatie-, applicatie- en netwerkdiensten en deze aanbieden aan zorgaanbieders. Daartoe kan een ZSP telecommunicatie-, informatie- en applicatiediensten afnemen van telecom-bedrijven en andere dienstaanbieders. De rol van de ZSP is belangrijk aangezien het LSP niet in staat zal zijn alle zorgaanbieders in Nederland individueel te benaderen en te ondersteunen.


- 35 -

5.7.5 Zorgpartijen Zorgaanbieders In dit architectuurontwerp wordt met zorgaanbieders bedoeld de zorginstelling of de individuele zorgverlener. Het UZI-register is afgebakend tot die partijen die vanuit hun functie toegang hebben tot zorginhoudelijke gegevens van personen. Zorgverzekeraar In dit architectuurontwerp wordt met zorgverzekeraars bedoeld: alle partijen die in het UZOVI-register opgenomen worden/zijn. Zie ook paragraaf 5.7.2 voor een overzicht van partijen die in het UZOVI-register worden opgenomen. Vierde domein partijen Naast zorgverleners, niet zijnde beroepsbeoefenaren als bedoeld in de artikelen 3 en 34 van de Wet BIG, en zorgverzekeraars, zullen wellicht in de toekomst ook andere zorgpartijen toegang moeten krijgen tot de basisinfrastructuur. In een onderzoek naar het vierde domein [68] definieert Vektis het vierde domein als: “Tot het VDZ behoren alle partijen met patiëntgerelateerde communicatie in de zorgsector, al dan niet geaggregeerd, behalve de partijen die opgenomen zijn in het UZI-register en het UZOVI-register.” Een deel van dit vierde domein betreft partijen die niet vallen onder de BSN-wet in de Zorg en die dus geen gebruik moeten/mogen maken van het BSN. Op dit moment is niet duidelijk hoe hiermee moet worden omgegaan.

5.8 Dimensioneringseisen voor de basisinfrastructuur De basisinfrastructuur moet ervoor zijn ingericht de intramurale communicatie in de zorg voor minimaal de komende 3-5 jaar te ondersteunen. Aangezien de dimensioneringseisen voor deze periode nu niet met zekerheid kunnen worden bepaald, is de belangrijkste eis hierbij dus schaalbaarheid. Er is echter een aantal dimensioneringseisen die nu wel concreet kunnen worden benoemd. Zo zal de basisinfrastructuur in ieder geval moeten ondersteunen: E-medicatiedossier: ondersteunen van het opvragen van het actuele medicatieoverzicht (verstrekte medicatie in het afgelopen jaar) voor iedere nieuwe medicatieverstrekking (eerste uitgifte). Uitgangspunt is dat hierbij de actuele medicatie van iedere Nederlander gemiddeld bij 2 apotheken moet worden opgehaald. Ook het versturen van het receptbericht zal elektronisch plaatsvinden. Voor de dimensionering moet er van worden uitgegaan dat 70% van alle verkeer tijdens het ochtendspreekuur plaatsvindt en dat rekening wordt gehouden met een piekfactor van 2 ten opzichte van het gemiddeld aantal berichten in het drukke uur.

- 36 -


E-waarneemdossier huisartsen: ondersteunen van opvragen waarneemdossier. Uitgangspunt is dat dit geen grote aantallen berichten betreft en voornamelijk in avond/nacht en weekend zal plaatsvinden. E-declareren: ondersteunen van controle op verzekering en declaratieverkeer. Uitgangspunt is dat het hier in eerste instantie vooral connectiviteit op netwerkniveau zal betreffen. Het verkeer zal verspreid over de werkdag plaatsvinden. Daarnaast dient er rekening mee te worden gehouden dat gedurende de periode van 3 – 5 jaar allerlei ander berichtenverkeer ondersteund zal gaan worden dat nog eens een extra belasting van 50% ten opzichte van de volumes voor bovengenoemde startapplicaties met zich mee kan brengen. Hoewel de functionaliteit voor ondersteuning van niet-berichtenverkeer, zoals grote bestanden voor röntgenfoto’s etc., wel is gedefinieerd, is dit in de dimensioneringseisen nog niet meegenomen. Dit zal in een latere fase worden bepaald.

5.9 Inrichtingsvragen 5.9.1 Inleiding De keuze voor een landelijk centrale of regionale invulling hangt af van een aantal factoren zoals financiering en organisatorisch vermogen in de regio. Om flexibiliteit te behouden, zal de architectuur waar zinvol zowel regionale als landelijke invulling van de infrastructurele voorzieningen ondersteunen. Met betrekking tot de inrichting van een EPD of e-medicatiedossier is vooral relevant waar de patiëntgegevens worden bewaard en beheerd. In de volgende paragrafen zal op dit aspect nader worden ingegaan.

5.9.2 Bewaren en beheren van patiëntgegevens Inleiding Er is een aantal mogelijkheden voor het bewaren en beheren van transmurale EPDgegevens: 1. bewaren op een persoonsgebonden middel (bijv. een smartcard), beheerd door de patiënt; 2. het voor alle zorgverleners gezamenlijk bewaren van alle patiëntgegevens, beheerd door een landelijke instantie; 3. het per regio voor alle zorgverleners gezamenlijk bewaren van alle patiëntgegevens, beheerd door een regionale instantie; 4. het lokaal bewaren onder direct beheer van de zorgverlener.


- 37 -

Bewaren op een persoonsgebonden middel Om een aantal redenen is een persoonsgebonden middel, bijvoorbeeld een smartcard niet geschikt als opslagmedium voor het volledige patiëntendossier: o De zorgverlener heeft een in de WGBO verankerde dossierplicht [17]. De zorgverlener dient dus alle voor de behandeling van de patiënt noodzakelijke gegevens in zijn dossier op te nemen, ongeacht wat de patiënt zelf doet. Het zich (deels) verlaten op de gegevens op de smartcard is onvoldoende om volledig aan deze verplichting te kunnen voldoen. De arts zal dus in ieder geval ook een eigen dossier moeten bijhouden. o Het “up to date” houden van de opgeslagen data vereist dat de card altijd en overal wordt bijgewerkt. Dit vereist een zorgvuldige procesgang die extra werkzaamheden van de zorgverlener of diens assistent vereist. Er zijn situaties waarbij de card of cardreader niet beschikbaar zijn; niet alleen is in deze gevallen de noodzakelijke informatie niet beschikbaar, maar de card kan ook niet worden bijgewerkt met de nieuwe gegevens. Bovendien worden gegevens niet altijd in aanwezigheid van de patiënt bijgewerkt (bijvoorbeeld röntgenverslagen); ook worden uitslagen vaak meegedeeld zonder dat de patiënt fysiek aanwezig is, bijvoorbeeld per telefoon of brief. In deze gevallen wordt de informatie niet direct op de smartcard bijgewerkt, zodra deze beschikbaar is. Dit alles maakt het garanderen van actualiteit en volledigheid van het dossier vrijwel onmogelijk. o De beveiliging van de opgeslagen data op de card heeft beperkingen. Indien de card eenvoudig toegankelijk is, zijn de gegevens bij verlies of diefstal niet beschermd. Een hoger beveiligingsniveau leidt tot duurdere en complexere oplossingen. o Door ontbreken van de gegevens van de smartcard voorafgaand aan een bezoek is de zorgverlener niet in staat een bezoek van een patiënt voor te bereiden op basis van alle beschikbare informatie. Het volledig opslaan van een EPD op een smartcard wordt derhalve niet gezien als een werkbare oplossing. Wel kan deze optie eventueel in aanvulling op andere concepten worden toegepast, bijvoorbeeld voor het opslaan van administratieve gegevens (bijvoorbeeld over zorgverzekeringen) en meer statische zorggegevens, zoals bloedgroep, allergieën etc.

Het voor alle zorgverleners gezamenlijk bewaren van alle patiëntgegevens Naar de inschatting van NICTIZ is één landelijk centrale7 oplossing in Nederland juridisch en organisatorisch niet haalbaar. De autonomie van de zorgverlener m.b.t. het inrichten van zijn ICT-voorzieningen sluit een monopoliesituatie voor het centraal aanbieden van

7

De term “centraal” kan verwarring wekken. Centralisatie wordt hier gebruikt voor het concentreren van de

verantwoordelijkheid naar één instantie. Dit sluit het op meer plaatsen verwerken en/of opslaan van data niet uit.

- 38 -


zorgapplicaties, met bijbehorende centrale dataopslag, uit. Dit geldt ook in het geval dat data vanuit lokale gedistribueerde zorgsystemen worden gerepliceerd in een centrale database of stelsel van databases. Bovendien is het noodzakelijk voor dergelijke landelijk centrale oplossingen de wet aan te passen. Het gebruik van het wettelijke concept “bewerker” is bij een dergelijke schaalgrootte niet meer bruikbaar, omdat de gezamenlijke verantwoordelijkheid van alle zorgverleners tezamen nauwelijks adequaat is te realiseren. Er moet dan ook een, in de wet verankerde, verantwoordelijke instantie worden aangewezen. Onze verwachting is dat een dergelijke wet, gezien de te verwachten maatschappelijke weerstand tegen een landelijk centrale database, zeer moeilijk te realiseren zal zijn. Hoewel dus één landelijk centrale oplossing niet als haalbaar wordt gezien om voor alle zorgverleners gezamenlijk alle patiëntgegevens te bewaren, dient de architectuur het mede centraal opslaan van (een deel van de) patiëntgegevens niet te blokkeren. Zo kunnen naast lokale en regionale dienstenaanbieders ook nationale dienstenaanbieders ontstaan die aan zorgverleners een centrale oplossing op nationaal niveau aanbieden in de vorm van een ASP-dienst met bijbehorende centrale opslag van gegevens. Bovendien kan het voor bepaalde sectorale toepassingen noodzakelijk of wenselijk zijn wel bepaalde gegevens in een centrale database op te slaan, waarvoor de bovengenoemde juridische en/of organisatorische beperkingen niet of in minder mate van toepassing zijn.

Het per regio voor alle zorgverleners gezamenlijk bewaren van alle patiëntgegevens Het voordeel van een regionaal centrale oplossing is dat in principe een betere beschikbaarheid, kans op volledigheid en responsetijd van dienstverlening kan worden gerealiseerd, dan met het opvragen uit een veelheid aan gedistribueerde lokale systemen. Daarbij moet de kanttekening worden gemaakt dat de beschikbaarheid ook wordt beperkt door het bevragende systeem. Lokale en regionale samenwerkingsinitiatieven kunnen leiden tot het centraal aanbieden van applicatiediensten met bijbehorende centrale opslag, waardoor regionaal centrale databases ontstaan. Denk hierbij aan het ontstaan van groepspraktijken, regionale HISinitiatieven en XIS ASP8-varianten. Op deze wijze zal naar verwachting in de komende jaren een stevige professionaliseringsslag plaatsvinden van de zorginformatiesystemen, zodat veel meer zorgsystemen aan de eisen van een Goed Beheerd Zorgsysteem (GBZ: zie par. 5.8) kunnen gaan voldoen. Zolang de zorgverlener de volledige zeggenschap houdt over de data, leidt dit ook juridisch en organisatorisch niet tot problemen.

8

Application Service Provider


- 39 -

Regionaal centrale databases kunnen ook ontstaan, indien wordt gekozen voor replicatie vanuit lokale systemen in een centrale Clinical Data Repository (CDR). Het voordeel van een dergelijke oplossing is dat in dat geval eenvoudiger kan worden voldaan aan de eisen die gelden voor een GBZ. Het waarborgen van de actualiteit van de data in een gerepliceerde database kan een probleem zijn, indien systemen tijdelijk niet beschikbaar zijn of niet in staat zijn in “real time” te repliceren. Dit betekent dat het kan voorkomen dat informatie in de centrale database niet actueel is, terwijl je dat niet weet omdat een systeem tijdelijk niet beschikbaar is of bij periodieke replicatie nog niet heeft gerepliceerd. Bovendien is het repliceren en consistent houden van de centrale database vanuit bestaande “legacy” systemen niet eenvoudig te realiseren. In het geval van een relatief kleinschalige regionale replicatie-oplossing, bijvoorbeeld voor een bepaalde groep zorgverleners, kan waarschijnlijk worden volstaan met het wettelijke concept “bewerker” conform de WBP [16], indien voldoende waarborgen worden ingebouwd dat de zorgverlener verantwoordelijk blijft voor de centraal gerepliceerde data. Bij grootschalige regionale replicatie-oplossingen waarbij ook een grote diversiteit aan zorgverleners is betrokken, is het wettelijk concept “bewerker” veel moeilijker toe te passen. Overigens blijft in beide gevallen de aansprakelijkheid en verantwoordelijkheid voor calamiteiten, fouten in de centraal gerepliceerde data en inbreuken op de beveiliging een probleempunt. Niet duidelijk is hoe de gezamenlijke verantwoordelijkheid van de zorgverleners in dit geval juridisch adequaat kan worden ingevuld.

Lokaal bewaren van patiëntgegevens Bij een stelsel van (lokale) databases per zorgaanbieder is de zorginstelling zelf de directe beheerder van de eigen gegevens. Dit zal veelal betrekking hebben op een individuele zorgverlener met zijn eigen persoonlijke zorgsysteem. Het zal duidelijk zijn dat een enigszins betrouwbare informatievoorziening alleen kan plaatsvinden indien ook de bronsystemen voldoende betrouwbaar en beveiligd zijn. Momenteel voldoet een aantal bestaande ZIS’en en AIS’en al aan de hoge kwaliteits- en beschikbaarheideisen die nodig zijn om gegevens in de bronsystemen op te halen wanneer dat nodig is. Er zijn er echter ook waarvoor dat zeker nog niet geldt. Ook voor andere XIS’en, met name in de HIS-omgeving, is dit veel minder het geval. Ook hier zal echter naar verwachting in de komende jaren een stevige professionaliseringsslag plaatsvinden vanwege de toenemende afhankelijkheid van de zorgverlener met betrekking tot de opgeslagen patiëntinformatie. Dit wordt versterkt door het ontstaan van groepspraktijken, dienstwaarneming, regionale HIS-initiatieven en XIS ASPvarianten. Dit valt dan onder de categorie regionaal centrale database. Ook binnen zorginstellingen kan worden gekozen voor replicatie vanuit lokale systemen in een Clinical Data Repository (CDR). Hiervoor gelden dezelfde voor- en nadelen als

- 40 -


eerder aangegeven voor de regionale variant, met uitzondering van de juridische aspecten. Met het koppelen van (lokale) databases per zorgaanbieder wordt tegen relatief beperkte kosten een significante verbetering van de informatievoorziening van de zorgverlener gerealiseerd, waarbij een optimale actualiteit van de gegevens kan worden gegarandeerd. Bij de voorgestelde minimale eisen die aan een GBZ (zie par. 5.8) worden gesteld heeft een dergelijke opzet echter ook zijn beperkingen: 1. De gegarandeerde beschikbaarheid van de dienstverlening ligt rond de 99%. Dit wordt overigens mede bepaald door de beschikbaarheid van het aanvragende systeem. Indien de beschikbaarheid van de aanvragende systemen niet sterk wordt verhoogd, kan ook de beschikbaarheid van de dienstverlening niet substantieel verbeteren. Bij een upgrading van de beschikbaarheideis naar bijvoorbeeld 99,9% kan ook de beschikbaarheid van dienstverlening worden verhoogd naar zo’n 99,8%. 2. De kans op volledigheid van de opgevraagde gegevens is afhankelijk van het aantal bevraagde systemen en de beschikbaarheid daarvan. De verwachting is dat het door zorgverleners ervaren percentage van volledige informatieleveringen rond de 97-99% zal liggen: 97% voor een gemiddelde bevraging, 99% voor een bevraging van een enkelvoudig systeem. Voor bevragingen waarbij informatie in een groot aantal systemen wordt geraadpleegd zal de kans op onvolledigheid groter zijn dan 2-3%. In die gevallen zal een zorgverlener echter niet alle informatie in één keer op zijn scherm willen hebben, maar zal hij er voor kiezen eerst via de verwijsindex (zie par. 6.6.1) een overzicht op te vragen en daarna gericht een bevraging op een beperkt aantal systemen te doen. Bij een upgrading van de beschikbaarheideis naar bijvoorbeeld 99,9% kan het percentage volledige informatieleveringen voor bevragingen worden verhoogd naar gemiddeld 99,5%. 3. De responsetijd van een bevraging wordt bepaald door het langzaamste systeem. Met de groei naar professionelere en krachtigere zorgsystemen worden hier echter geen grote problemen verwacht.

Evaluatie van de vier mogelijke invullingen Om een aantal redenen is een smartcard niet geschikt als opslagmedium voor het volledige patiëntendossier. Naar de inschatting van NICTIZ is ook één landelijk centrale oplossing in Nederland politiek, juridisch en organisatorisch niet haalbaar. Vanwege het gewenste draagvlak, kostenoverwegingen en de strakke tijdslijnen voor realisatie heeft NICTIZ ervoor gekozen zich eerst te richten op het tot stand brengen van een basisinfrastructuur die is gebaseerd op het koppelen van gedistribueerde systemen om zo een virtueel EPD te realiseren. Waar mogelijk, is en blijft de opslag van patiëntgegevens derhalve in het bronsysteem van de verantwoordelijke zorgverlener. Daarmee kan de integriteit en actualiteit van de gegevens worden gerealiseerd en blijft Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 41 -

de verantwoordelijkheid voor de gegevens waar die moet zijn: bij de bron. Dit sluit niet uit dat in bepaalde gevallen (verhuizing, beëindigen van de praktijk etc.) dossieroverdracht plaatsvindt tussen zorgverleners, waarna het zorgsysteem van de nieuwe verantwoordelijke zorgverlener als bron van de gegevens gaat fungeren. De architectuur faciliteert ook het koppelen van centrale oplossingen. Regionaal centrale oplossingen zullen vanwege de ontwikkeling naar schaalvergroting en professionalisering naar verwachting in de toekomst zelfs de meest voorkomende variant zijn. Instellingen en samenwerkingsverbanden van zorgverleners kunnen desgewenst gebruik maken van replicatietechnieken om de kwaliteit van hun informatievoorziening te verbeteren of om te kunnen voldoen aan de minimale eisen die aan een GBZ (zie par. 5.13) worden gesteld. Zowel systemen met (aanvullende) landelijk centrale, regionaal centrale als gedistribueerde dataopslag kunnen op de basisinfrastructuur worden aangesloten, zolang deze systemen maar voldoen aan de eisen die aan een GBZ worden gesteld. Met de gekozen opzet wordt tegen relatief beperkte kosten een significante verbetering van de informatievoorziening van de zorgverlener gerealiseerd. De verantwoordelijkheid om te voldoen aan de eisen van een GBZ ligt bij de zorgaanbieders. Vandaar dat dataopslag-varianten buiten de basisinfrastructuur worden gepositioneerd. Overigens kunnen deze varianten wel weer gebruikmaken van de generieke connectiviteit om replicatie van gegevens van de lokale systemen naar centrale gegevensopslag mogelijk te maken. Bij de minimale eisen die aan een GBZ worden gesteld heeft de gekozen opzet initieel echter ook zijn beperkingen: 1. De gegarandeerde beschikbaarheid van de dienstverlening ligt rond de 99%. Dit wordt overigens mede bepaald door de beschikbaarheid van het aanvragende systeem. Indien de beschikbaarheid van de aanvragende systemen niet sterk wordt verhoogd, kan ook de beschikbaarheid van de dienstverlening niet substantieel verbeteren. Bij een upgrading van de beschikbaarheideis naar bijvoorbeeld 99,9% kan ook de beschikbaarheid van dienstverlening worden verhoogd naar zo’n 99,8%. 2. De kans op volledigheid is afhankelijk van het aantal bevraagde systemen en de beschikbaarheid daarvan. De verwachting is dat het door zorgverleners ervaren percentage van volledige informatieleveringen rond de 97-99% zal liggen. Bij een upgrading van de beschikbaarheideis naar bijvoorbeeld 99,9% kan dit percentage worden verhoogd naar minimaal 99,5%. 3. De responsetijd van een bevraging wordt bepaald door het langzaamste systeem. Met de groei naar professionelere en krachtigere zorgsystemen worden hier echter geen grote problemen verwacht

- 42 -


5.10 Eisen aan de infrastructurele voorzieningen In voorgaande paragraaf is de afweging gemaakt over de opslag van gegevens van het EPD, waarbij de conclusie was dat wordt uitgegaan van een virtueel EPD. De data blijven in principe opgeslagen in de systemen waar de zorgverlener de data heeft ingevoerd, voor zover dat Goed Beheerde Zorgsystemen zijn. Dit sluit overigens niet uit dat categoraal of lokaal gebruik wordt gemaakt van via gecentraliseerde systemen aangeboden applicatiediensten met bijbehorende centrale opslag. Bovendien kunnen voor bronsystemen die (nog) niet aan de gestelde eisen voldoen, voorzieningen worden getroffen, zoals replicatie van gegevens in een (lokale, regionale of landelijke) centrale database. Een dergelijke database zal dan gaan fungeren als bronsysteem voor de desbetreffende patiëntgegevens. Aan de infrastructurele voorzieningen worden de volgende eisen gesteld: Het realiseren van veilige en betrouwbare communicatie tussen (goedbeheerde) zorgsystemen; Een mechanisme om te bepalen in welke zorgsystemen zich gegevens over een bepaalde patiënt bevinden; Een unieke patiëntidentificatie om gegevens eenduidig aan een patiënt te kunnen koppelen zowel bij registratie als bij opvraag van gegevens; Het bieden van zekerheden t.a.v. rechtmatige toegang tot patiëntgegevens door zorgverleners en zorgverzekeraars; dit vereist ondermeer een unieke identificatie en authenticatie van zorgverleners en zorgverzekeraars; Het realiseren van een mechanisme om aan de hand van de toestemming van de patiënt mede te laten bepalen wie toegang mag worden verleend tot zijn gegevens (“patient consent”) Het onweerlegbaar kunnen maken van informatievragen en transacties die door zorgverleners worden geïnitieerd. Het creëren van een uniform mechanisme om de communicatie tussen zorgverleners en zorgverzekeraars te faciliteren voor: o Controle op verzekering o Indienen van elektronische declaraties o Opvragen en afgeven van statusinformatie over ingediende declaraties o Indienen en afgeven van machtigingsverzoeken Het bieden van faciliteiten voor codebeheer De dienstverlening die door de infrastructurele voorzieningen wordt geboden, dient te passen binnen de overall-eisen zoals geformuleerd in paragraaf 5.4. Daarvoor dient een acceptatieprocedure te worden ingericht.


- 43 -

5.11 Infrastructurele voorzieningen voor beveiliging 5.11.1 Vereiste beveiligingsniveaus De uitwisseling van gegevens via de basisinfrastructuur van de zorg vindt plaats tussen diverse partijen: zorgverleners, zorginstellingen, zorgverzekeraars etc. De uit te wisselen gegevens tussen de genoemde partijen zijn ondergebracht in gestandaardiseerde berichten die in meer of mindere mate “gevoelige” (patiënt-) gegevens bevatten. Gebaseerd op de “gevoeligheid” van de gegevens kunnen deze berichten worden ingedeeld in zogenaamde risicoklassen, waarmee een set van toe te passen functionele beveiligingseisen samenhangt. Door invulling te geven aan de genoemde maatregelen wordt tegemoet gekomen aan de vigerende weten regelgeving aangaande de bescherming van persoonsgegevens en medische gegevens. De voornorm ENV 12924 [42] beschrijft een methode voor het indelen van automatiseringssystemen in de zorgsector in risicocategorieën. Hierin zijn 3 aspecten opgenomen die van belang zijn bij de beveiliging van informatie: Beschikbaarheid (Availability), Vertrouwelijkheid (Confidentiality) en Integriteit (Integrity). Daarnaast definieert ENV 13608 [36] nog het begrip Auditability (Controleerbaarheid). Deze vierdeling wordt ook in prEN 13606-4 [23] toegepast. Voorgesteld wordt om voor de aspecten Beschikbaarheid, Vertrouwelijkheid en Controleerbaarheid uit te gaan van 3 niveaus: Laag, Midden en Hoog. Controleerbaarheid betekent dat een zorgverlener niet kan ontkennen dat hij bepaalde communicatiehandelingen heeft verricht (onweerlegbaarheid). Daarnaast dient voor het aspect Integriteit een minimum niveau te worden gedefinieerd.

• Beschikbaarheid: • Vertrouwelijkheid: • Integriteit: • Controleerbaarheid:

L

M

H

L

M

H

minimum eis L

M

H

Figuur 7: Differentiatie in beveiligingsniveaus

- 44 -


5.11.2 Een PKI voor de zorg Indien partijen tot eigen keuzen komen ten aanzien van het realiseren van elektronische identificatie, elektronische handtekening en vertrouwelijkheid (met of zonder PKI), ontstaat een verwarrende situatie, vanwege een veelvoud aan implementaties, waardoor eindgebruikers worden geconfronteerd met meerdere wachtwoorden, beveiligingsprocedures en dienstverlenende instanties. Door een uniforme invulling van de zekerheidsstructuur wordt voorkomen dat organisaties in de zorg, individuele zorgverleners en zorgverzekeraars worden opgezadeld met extra administratieve lasten, toenemende complexiteit van beveiligingsoplossingen, beveiligingsrisico’s en onduidelijkheid over het gerealiseerde beveiligingsniveau. Deze invulling wordt vormgegeven door de inrichting van een Public Key Infrastructure (PKI) voor de zorg. Wat is een Public Key Infrastructure? Traditioneel wordt vertrouwelijkheid van communicatie gerealiseerd door bewerking (encryptie) van het originele bericht met een geheime sleutel, die bekend is bij zowel zender als ontvanger. Het vercijferen en ontcijferen vindt dus plaats met dezelfde sleutel. Public Key technologie is gebaseerd op mathematische principes, waarbij twee verschillende sleutels worden gebruikt, één om te vercijferen en één om te ontcijferen. Datgene wat vercijferd is met de ene sleutel kan alleen worden ontcijferd met de andere sleutel. Dit maakt het mogelijk één van de sleutels publiek te maken. Vercijferen van informatie die bestemd is voor een bepaalde persoon kan dan plaatsvinden door gebruik te maken van zijn publieke sleutel. Deze informatie kan alleen worden ontcijferd met behulp van de bijbehorende private sleutel van die persoon. Zoals de naam al aangeeft dient de private sleutel geheim te blijven om gebruik door onbevoegden tegen te gaan. Iedereen die beveiligd met een bepaalde persoon wil communiceren dient te kunnen beschikken over de publieke sleutel van die persoon. De infrastructuur die dit mogelijk maakt, wordt daarom Public Key Infrastructure genoemd.

5.11.3 Certificate policy Voor de deelname van instellingen aan de PKI-dienstverlening en de uitgifte van certificaten zijn beleidsrichtlijnen opgesteld. Deze zijn verwoord in de Certificate Policy (CP). Tevens is door de CA een gedetailleerde Certificate Practice Statement (CPS) uitgewerkt op basis van RFC 2527, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework". De CP en CPS maken geen deel uit van deze architectuurbeschrijving, maar worden in een apart document gepubliceerd [54].


- 45 -

5.12 Voorzieningen voor beheer 5.12.1 Inleiding De primaire taak van het LSP is het leveren van informatie- en routeringsdiensten op vastgestelde dienstenniveaus. Om deze diensten te kunnen leveren dient te worden voorzien in het beheer van de gemeenschappelijke faciliteiten en de verbindingen met de buitenwereld, het bewaken van het berichtenverkeer en het ingrijpen bij dreigende of optredende storingen. Door het LSP worden ook interconnectiediensten geleverd aan gecertificeerde Zorg Service Providers (ZSP’s). De beheerder van het LSP geeft de IP-adresreeksen uit voor het subnet van de desbetreffende ZSP. De ZSP zorgt voor een eventuele vertaling van adressen die intern in het ZSP-netwerk worden gebruikt naar deze IP-adressen. Met ZSP’s moeten afspraken worden gemaakt over op te stellen SLA’s en de procedures bij dreigende of optredende storingen. In de volgende paragrafen wordt ingegaan op de diverse beheerdiensten die door de beheerorganisatie voor het LSP dienen te worden geleverd.

5.12.2 Primaire beheerdiensten •

•

•

•

Toegangbeheer Het verstrekken van informatie aan zorgpartijen is gereguleerd door autorisatietabelregels en vindt plaats op basis van een geslaagde authenticatieprocedure. Het technisch beheer van de tabelregels voor het autorisatieprotocol en autorisatieprofiel is belegd bij de beheerder van het LSP. Systeembeheer Het LSP dient te beschikken over faciliteiten om adequaat systeembeheer uit te kunnen voeren. GBZ’n die een nader te bepalen foutgedrag vertonen, dienen te kunnen worden geïdentificeerd. Van deze GBZ’n moet het gedrag gemonitord kunnen worden. Indien uit de monitoring blijkt dat het GBZ niet naar behoren functioneert, dient correctieve actie te worden uitgevoerd. Applicatiebeheer De beheerder van het LSP dient zorg te dragen voor beheer, onderhoud en vernieuwing van de applicatiesoftware in het LSP. Beheer van adressen en namen De LSP-beheerder dient ervoor zorg te dragen dat er bij de communicatie tussen GBZ’n geen dubbele adressen en/of namen worden gebruikt. Een van de beheertaken van het LSP is het optreden als Registration Authority voor de uitgifte van IPnummers, domeinnamen en OID’s voor applicaties die via de basisinfrastructuur met elkaar moeten kunnen communiceren.

- 46 -


5.12.3 Ondersteuning van ZSP’s d.m.v. een helpdesk Vanuit een helpdesk dient ondersteuning te worden geboden aan ZSP’s, zorgaanbieders en patiënten bij eventuele vragen, verzoeken, storingen, etc.

5.12.4 Opleveren managementinformatie Het LSP dient rapportages op te leveren waarin de kwaliteit van de zorginfrastructuur wordt aangegeven in termen van beschikbaarheid, capaciteit en responsetijden.

5.13 Eisen aan zorgsystemen 5.13.1 Algemeen De basisinfrastructuur voor de zorg is ontworpen om een veelheid aan applicaties in de zorg te kunnen ondersteunen. Deze applicaties draaien op zorgsystemen. Zorgsystemen mogen alleen op de basisinfrastructuur van de zorg worden aangesloten indien wordt voldaan aan een aantal eisen. Een Goed Beheerd Zorgsysteem (GBZ) is een ICTvoorziening van een zorgpartij (zorgaanbieder, zorgverzekeraar, etc.) die voldoet aan deze eisen. De eisen die aan een GBZ worden gesteld kunnen over het algemeen per type applicatie verschillen, afhankelijk van de toepassingsrol die door de applicatie wordt ondersteund. Om een minimum niveau van beveiliging binnen de basisinfrastructuur te kunnen garanderen dient een GBZ in ieder geval aan een aantal eisen voor wat betreft beveiliging en beheer te voldoen. Voor het inrichten van een GBZ gelden de algemene eisen van goed vakmanschap. Daarbij wordt verondersteld dat gebruik wordt gemaakt van bestaande normen op het gebeid van informatiebeveiliging. Vanuit de architectuur wordt de eis gesteld dat alleen GBZ’n worden gekoppeld aan de basisinfrastructuur. Dat vereist een acceptatieprocedure voor het vaststellen dat een zorgsysteem de status heeft van GBZ. De acceptatiecriteria omvatten zowel eisen aan het systeem, als aan de beheerorganisatie en –processen, waarbij moet worden zekergesteld dat een GBZ voldoet aan gestelde normen en eisen.

5.13.2 Systemen met opslag van patiëntinformatie Gezien de wetgeving en de praktijk op het gebied van uitwisseling van patiëntgegevens moet er onder meer aan de volgende eisen zijn voldaan: er moet vertrouwen zijn dat de patiëntgegevens overeenkomstig de WGBO voor een goede hulpverlening aan de patiënt worden gebruikt met inachtneming van de voorwaarden die voortvloeien uit het medisch beroepsgeheim; de gegevens moeten integer, actueel en volledig zijn. Daarnaast zijn er de eisen aan de te leveren serviceniveaus. Deze eisen zijn afhankelijk van de applicaties die op deze systemen draaien. Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 47 -

Voor zorgsystemen met opslag van patiëntgegevens die continu beschikbaar moeten zijn, zoals geldt voor het e-medicatiedossier en EPD, gelden de volgende eisen: De openstellingtijd van de dienstverlening is 7 x 24 uur; De beschikbaarheid en responsetijden dienen te passen in de overall-eisen voor de dienstverlening zoals geformuleerd in paragraaf 5.2.2.; in de specificaties wordt dit nader vastgelegd. Om de kwaliteit van het beheer van de aangesloten systemen te waarborgen is eerder het concept Goed Beheerd Zorgsysteem (GBZ) ingevoerd. Dit kunnen bijvoorbeeld zorgsystemen van individuele zorgverleners zijn (Bijv. HIS, AIS, ZIS) die aan de gestelde eisen van een GBZ kunnen voldoen (zie Figuur 5-4).

AIS

BasisBasisinfrastructuur infrastructuur

GBZ’en HIS

Etc. Figuur 5-4: Het koppelen van Goed Beheerde Zorgsystemen aan de basisinfrastructuur

Het kunnen echter ook meer gecentraliseerde oplossingen zijn, zoals ASP-varianten voor een Regionaal HIS of een HOED- of HAP-oplossing (Zie Figuur 5-5). In sommige gevallen zullen applicaties ook landelijk worden aangeboden.

- 48 -


XIS


GBZ’en Centrale (XIS-) Applicatie

Lokale clients

Witte tekst Figuur 5-5: Alternatieve GBZ-vormen (1): gecentraliseerde applicatie servers Daarnaast komt het voor dat voor bepaalde doeleinden centrale gegevensopslag plaatsvindt. Dit kunnen bijvoorbeeld bepaalde landelijke sectorale databases zijn. Ook kunnen Clinical Data Repositories worden ingezet om de informatie te ontsluiten die zich bevindt in zorgsystemen die niet kunnen voldoen aan de eisen die aan een GBZ worden gesteld. Dit kan bijvoorbeeld in een zorginstelling worden gerealiseerd of gezamenlijk regionaal voor een bepaalde groep zorgverleners (zie Figuur 5-6).

XIS


GBZ’en Centrale Gegevensopslag

XIS-en

Witte tekst Figuur 5-6: Alternatieve GBZ-vormen (2): gecentraliseerde gegevensopslag door replicatie In dit rapport wordt er verder van uitgegaan dat EPD-gegevens zijn opgeslagen in GBZ’n en dat de architectuur zich richt op transmurale communicatie tussen GBZ’n.


- 49 -

6

De informatie (systeem) architectuur

6.1 Inleiding Bedrijfsprocessen stoelen in het algemeen op verwerking van diverse soorten gegevens. Betekenis en structuur van gegevens (semantiek en syntax) en de functionaliteit van applicaties voor informatieverwerking worden in de informatielaag gedefinieerd.

6.2 Semantiek en syntax Om zinvol gegevens uit te wisselen tussen applicaties zijn afspraken nodig over welke gegevens in een bepaalde situatie moeten worden uitgewisseld en wat de betekenis is van die gegevens (semantiek) en in welke structuur ze worden uitgewisseld (syntax). Algemeen wordt aangenomen dat het HL7v3 Reference Informatie Model (RIM) en de definitie van HL7v3 data types wereldwijd de basis zullen gaan vormen voor communicatie tussen zorgtoepassingen. Daarom zal voor de basisinfrastructuur worden aangesloten bij de ontwikkelingen in HL7v3. Het is de verwachting dat het HL7v3 RIM en de definitie van HL7v3 data types de basis zal worden voor de ontwikkeling van alle nieuwe zorgsystemen. In HL7v3 worden ook op XML-gebaseerde berichtstructuren gedefinieerd voor een veelheid aan zorgdomeinen. Om te komen tot een zorgbreed EPD met alle denkbare functionaliteit moet nog een aantal zaken worden geregeld: • Zorgverleners moeten worden ondersteund bij een gestructureerde verslaglegging met gebruik van eenduidige classificaties (codestelsels), waar er nu vooral verslaglegging plaatsvindt in de vorm van “verhalend proza”. • De structurering dient aan te sluiten bij de in ontwikkeling zijnde standaarden voor de uitwisseling van klinische documenten (HL7 V3 CDA, CEN pr EN13606 EHR Extract [23]). • Voor optimale samenwerking tussen systemen zullen databasestructuren die EPDdata verwerken en opslaan, moeten zijn gebaseerd op een gezamenlijk Referentie Informatie Model (RIM). Vanuit NICTIZ-perspectief zou dit het HL7 v3 RIM moeten zijn. • Daarnaast zijn er ontwikkelingen om domeinspecifieke concepten (bijvoorbeeld “bloeddruk”, “gewicht” etc.) te standaardiseren. Deze zogenaamde “Archetype-” (CEN) of “Template-” (HL7) benadering is eigenlijk een standaardisatie op het gebied van medischinhoudelijke kennis. In de architectuur kan slechts in beperkte mate rekening worden gehouden met bovenstaande ontwikkelingen. Aangezien de standaardisatie op deze gebieden nog niet is afgerond, zal het nog enige jaren duren voordat er systemen op de markt verschijnen die aan deze standaarden kunnen voldoen. Het architectuurontwerp kan dan ook nog niet op deze standaarden worden gebaseerd.

- 50 -


6.3 Coderingsstelsels Daarnaast zijn er diverse coderingsstelsels om specifieke begrippen in verschillende domeinen van de gezondheidszorg te coderen en classificeren, bijvoorbeeld WCIA codetabellen, International Classification of Diseases (ICD, meest recent ICD-10), International Classification of Primary Care (ICPC, meest recent ICPC-2). In recente rapporten is de stand van zaken op dit gebied vastgelegd [3], [8]. In [3] wordt geconstateerd: "Om te bepalen welke standaarden door de infrastructuur dienen te worden ondersteund dient een nader onderzoek naar de samenstelbaarheid van de informatiemodellen uit de beroepsdoelgroepen plaats te vinden.” Het vertalen tussen verschillende codestelsels wordt niet beschouwd als behorend tot de minimaal noodzakelijke gemeenschappelijke infrastructurele voorzieningen en kan heel goed als additionele dienstverlening door Zorg Service Providers of leveranciers van zorgsystemen aan zorgverleners worden geboden.

6.4 Identificatie 6.4.1 Identificatie van zorgverleners Om zorgverleners te kunnen identificeren wordt een uniek nummer, het zogenaamde UZI9-nummer gekoppeld aan iedere geregistreerde zorgverlener. Om dit nummer te kunnen achterhalen is in de architectuur een speciaal register voorzien: het UZI-register. Dit register schrijft zorgverleners in volgens beleid dat wordt vastgesteld door de minister van Volksgezondheid, Welzijn en Sport (VWS). De minister laat zich met betrekking tot dit beleid adviseren door NICTIZ, waarin alle beroepsgroepen in de zorg worden vertegenwoordigd. Een PKI voor de zorg kan certificaten uitgeven op basis van het UZI-register en de geldigheid van deze certificaten bij gebruik verifiëren, waardoor zekerheid kan worden verkregen over de authenticiteit van de gebruikte identificatie. Om toegang mogelijk te maken van zorgpartijen, niet zijnde beroepsbeoefenaren als bedoeld in de artikelen 3 en 34 van de Wet BIG, en zorgverzekeraars, en zorgverzekeraars (het zogenaamde vierde domein) is op termijn een VDZ10-register noodzakelijk. Dit register zou op termijn ook als een PKI moeten gaan werken om dit type zorgpartij te identificeren en authenticeren bij toegang tot de basisinfrastructuur.

9

Unieke Zorgverlener Identificatie

10

Vierde Domein in de Zorg


- 51 -

6.4.2 Identificatie van patiënten Voor het eenduidig identificeren van patiënten is een landelijk patiëntnummer (BSN) voorzien. In de architectuur wordt er van uitgegaan dat de zorgverlener het BSN kan bepalen aan de hand van toegang tot het GBA door middel van een Sectorale Berichten Voorziening voor de Zorg (SBV-Z). Aangesloten systemen moeten in staat zijn informatie op te leveren op basis van het BSN. In een latere fase kan identificatie en authenticatie van patiënten worden ondersteund door de PKI voor de zorg ook te koppelen aan de SBV-Z.

6.4.3 Identificatie van zorgverzekeraars Ook zorgverzekeraars dienen eenduidig te kunnen worden geïdentificeerd. In de architectuur is voorzien dat dit wordt ondersteund met een zorgverzekeraarnummer (UZOVI). Het UZOVI11-nummer kan worden bepaald aan de hand van een zorgverzekeraarregister. In een latere fase12 zal identificatie en authenticatie van zorgverzekeraars worden ondersteund door de PKI voor de zorg ook te koppelen aan dit register.

6.4.4 Identificatie van applicaties en systemen In het geval applicaties en/of systemen geautomatiseerd deelnemen in het communicatieproces dienen ze ook eenduidig te kunnen worden geïdentificeerd. Hiervoor wordt aangesloten bij de systematiek voor zorgverleners en zorgverzekeraars.

6.5 Functionaliteit voor het bieden van generieke connectiviteit De basis infrastructuur dient generieke connectiviteit te bieden en zal daarvoor aan de volgende eisen moeten voldoen: Verkeer tussen alle aangesloten zorgsystemen (“any-to-any”) moet mogelijk zijn; Er moet een vertaling kunnen worden gemaakt van gebruikte (domein-) namen naar adresinformatie.

6.6 Functionaliteit voor het opvragen en verkrijgen van (patiënt)gegevens 6.6.1 Functionaliteit van de basisinfrastructuur Gezien de keuze voor een virtueel EPD is het nodig de GBZ’n te vinden waar gegevens over de desbetreffende patiënt aanwezig zijn. Daarvoor zijn verschillende mogelijkheden beschikbaar:

11

Unieke ZOrgVerzekeraars Identificatie

12

Momenteel wordt voorzien dat dit per 1 januari 2006 zal zijn gerealiseerd.

- 52 -


1. elke aanvraag steeds naar iedere GBZ sturen; dit lijkt op den duur niet houdbaar vanwege de grote werklast die het oplevert en de lange responstijden die daarvan het gevolg kunnen zijn. 2. Het vastleggen van een verwijstabel op een smartcard met een VWI; zoals al besproken in paragraaf 5.9.2 is dit geen goede oplossing; 3. het opnemen van de verwijsfunctie in de infrastructuur; dit leidt tot een efficiënte goed beheerbare oplossing omdat alleen die zorgsystemen worden belast die daadwerkelijk informatie over de desbetreffende patiënt beschikken. Inmiddels heeft de industrieorganisatie IHE13 een zogenaamd Cross-Enterprise Document Sharing (XDS) profiel voor uitwisseling van (zorginhoudelijke) documenten gedefinieerd, dat is gebaseerd op dit principe [63]. Op grond van deze overwegingen wordt gekozen voor de oplossing met een verwijsindex, die de informatie bevat welke patiëntgegevens beschikbaar zijn en waar deze zich bevinden. De keuze voor een landelijk centrale of regionale invulling van een verwijsindex hangt af van een aantal factoren zoals financiering en organisatie in de regio. Om flexibiliteit te houden met betrekking tot de organisatorische invulling zal de architectuur beide opties ondersteunen. Een dergelijke invulling van de VWI behoort per definitie tot de infrastructuur. Daarnaast is het ondersteunen van een portaalfunctie voorzien voor het opvragen (en versturen) van informatie voor gecombineerd browser- en machine-machine-verkeer. Dit onderdeel is vooralsnog specifiek uitgewerkt voor e-declareren [62] en maakt nog geen onderdeel uit van de architectuur van de basisinfrastructuur. Daarnaast is het nodig over een aantal centrale registers te beschikken ter ondersteuning van identificatie van zorgverlener, patiënt en zorgverzekeraar (UZI-register SBV-Z en UZOVI-register). Specifieke beveiligingsfunctionaliteit wordt aangegeven in paragraaf 6.10.

6.6.2 Functionaliteit van aangesloten zorgsystemen Aan aangesloten zorgsystemen worden de volgende functionele eisen gesteld: Het aanmelden van (nieuwe) patiëntgegevens aan de verwijsfunctie VWI in de basisinfrastructuur; de basisinfrastructuur ondersteunt het aanmelden van patiënt- gegevens op het niveau van gegevenssoorten; Uniek identificeren van patiënt door bevraging van de SBV-Z; Aanbieden van de identiteit van de zorgverlener bij een aanvraag;

13

Integrating the Healthcare Enterprise


- 53 -

Ondersteunen van het opvragen van patiëntgegevens: de aanvraag van gegevens moet worden gespecificeerd naar inhoudelijke aard en presentatievorm; Het leveren van gevraagde patiëntgegevens, (eventueel) na autoriseren op basis van identiteit van de aanvrager; Het verwerken, combineren, reduceren en presenteren van het resultaat van de aanvraag; (Optioneel) het vertalen tussen verschillende codestelsels (zie ook 6.9). Specifieke beveiligingsfunctionaliteit wordt aangegeven in paragraaf 6.10.

6.7 Functionaliteit voor het versturen van gegevens 6.7.1 Functionaliteit van de basisinfrastructuur Ondersteunen zorgverlener en zorgverzekeraar bij het opzoeken van gegevens over andere zorgaanbieders en zorgverzekeraars; hiervoor wordt een directory service (o.a. zorgaanbiederadresboek) voorzien die kan worden geraadpleegd; Zorgen voor overdracht van berichten tussen zorgverleners onderling en (in een latere fase) tussen zorgverleners en zorgverzekeraars, door aflevering bij de juiste applicatie of postbus. Ondersteunen van een portaalfunctie voor het versturen van informatie voor gecombineerd browser- en machine-machine-verkeer. Dit onderdeel is vooralsnog specifiek uitgewerkt voor e-declareren [62] en maakt nog geen onderdeel uit van de architectuur van de basisinfrastructuur. Specifieke beveiligingsfunctionaliteit wordt aangegeven in paragraaf 6.10.

6.7.2 Functionaliteit van aangesloten zorgsystemen Opvragen adresinformatie (o.a. uit het zorgaanbiederadresboek); Uniek identificeren van de te adresseren zorgverlener; Samenstellen en verzenden van een bericht aan een andere zorgverlener; Beantwoorden en terugzenden van een bericht aan een andere zorgverlener; Abonneren op meldingen m.b.t. patiënt zodat nieuwe informatie over deze patiënt automatisch wordt toegestuurd; Vrijgeven van patiëntinformatie; artsen moeten controle kunnen uitoefenen wanneer en welke informatie ze willen vrijgeven; in ieder geval dient informatie pas te worden vrijgegeven als deze foutvrij en compleet is; ook moet het mogelijk zijn informatie niet vrij te geven als dat de expliciete wens is van de patiënt. Specifieke beveiligingsfunctionaliteit wordt aangegeven in paragraaf 6.10.

- 54 -


6.8 Functionaliteit voor dossieroverdracht Na overdracht van een dossier van de ene zorgverlener naar een andere waarbij ook de verantwoordelijkheid voor dit dossier wordt overgedragen, dient de verwijsindex te worden aangepast zodat de gegevens vanaf dat moment worden opgehaald bij de “nieuwe” zorgverlener. Deze gegevens moeten derhalve worden aangemeld bij de verwijsindex. Daarnaast dient de verwijzing in de verwijsindex naar de gegevens bij de “oude” zorgverlener te worden verwijderd. Dit betekent dat het verzendende en ontvangende GBZ na uitwisseling van het overdrachtsbericht door middel van aanmeld en afmeldberichten moeten zorgdragen voor aanpassing van de verwijsindex.

6.9 Functionaliteit voor het abonneren op gegevens 6.9.1 Functionaliteit van de basisinfrastructuur Het afhandelen van aan- en afmeldingen van zorgverleners om er op te worden geattendeerd zodra nieuwe informatie over een bepaalde patiënt beschikbaar komt; Signaleren naar de zorgverlener dat er nieuwe informatie over de desbetreffende patiënt beschikbaar is.

6.9.2 Functionaliteit van aangesloten zorgsystemen Aan aangesloten zorgsystemen worden de volgende functionele eisen gesteld: Het aan- en afmelden van een zorgverlener om te worden geattendeerd zodra nieuwe informatie over een bepaalde patiënt beschikbaar komt; Het afhandelen van de signalering naar de zorgverlener dat er nieuwe informatie over de desbetreffende patiënt beschikbaar is.

6.10 Functionaliteit voor het ondersteunen van semantische interoperabiliteit Momenteel is het voor een partij zeer lastig om overzicht en inzicht te krijgen in de berichtstandaarden en de daarbij toe te passen codestelsels. Er zijn verschillende beheerders voor verschillende berichtstandaarden en codestelsels. Om dit inzicht en overzicht beter mogelijk te maken, wordt een informatieportaal voorzien voor codestelsels. In eerste instantie wordt dit portaal alleen ingericht voor codestelsels die gebruikt worden bij e-declareren. Dit portaal maakt het mogelijk om via één centraal punt alle berichtstandaarden en codestelsels te vinden. Het portaal maakt (waar mogelijk) gebruik van verwijzingen naar de beheerder van een standaard of codestelsel. Dit portaal zal gebruik maken van de architectuur zoals beschreven in dit document.


- 55 -

6.11 Functionaliteit voor ondersteuning van wetenschappelijk onderzoek, rapportage en beheer van volksgezondheid en beleidsvorming Het verbeteren van de toegankelijkheid tot zorginhoudelijke gegevens biedt ook de mogelijkheid trends te signaleren en relaties te leggen tussen allerlei soorten gegevens ten behoeve van beleidsontwikkeling en wetenschappelijk onderzoek. Hiervoor is het noodzakelijk aandacht te besteden aan de mogelijkheden van datamining van de gegevens in het totaal van EPD’s van bepaalde patiëntgroepen. Zo kan bij het vroegtijdig signaleren van een mogelijke epidemie bijvoorbeeld een inentingsprogramma in gang worden gezet. Ook kan de effectiviteit van bepaalde behandelingsmethoden worden gemeten of een relatie worden gelegd tussen het meer dan gemiddeld voorkomen van bepaalde aandoening in bepaalde bevolkingsgroepen of geografische gebieden. In bepaalde gevallen is het daarbij zinvol gebruik te maken van datawarehousing technieken. Het gebruik van persoonlijke medische gegevens voor toepassingen anders dan de primaire toepassing in de behandelrelatie is echter niet toegestaan zonder uitdrukkelijke toestemming van de patiënt, tenzij de relatie met de identiteit van de patiënt ongedaan wordt gemaakt. Deze bewerking wordt anonimisatie van gegevens genoemd. Voor bepaalde onderzoeken die een langere onderzoeksperiode in beslag nemen, is het noodzakelijk gegevens van dezelfde patiënt te kunnen toevoegen aan eerder verzamelde gegevens van de patiënt. Er zijn tegenwoordig technieken beschikbaar die dit mogelijk maken zonder dat een relatie met de identiteit van de patiënt kan worden gelegd. Dit wordt pseudonimisatie genoemd. Vooralsnog wordt in de architectuur nog geen invulling gegeven aan deze gewenste functionaliteit.

6.12 Beveiliging 6.12.1 Functionaliteit van de basisinfrastructuur Een PKI ter ondersteuning van de gewenste beveiligingsfuncties (zie verder paragraaf 6.12.3); Authenticeren van zorgsystemen, zorgverlener en zorgverzekeraar; aangesloten zorgsystemen (GBZ’n) mogen er van uit gaan dat bij binnenkomende verzoeken om patiëntgegevens de identiteit van de vragende zorgverlener is geverifieerd; Vaststellen van de privileges die behoren bij de functie van de zorgverlener en zorgverzekeraar en de (eventuele) beperkingen die daaraan door de patiënt zijn gesteld (autorisatie);

- 56 -


(Op termijn) Het ondersteunen van door het LSP geautoriseerde directe toegang tot andere GBZ’n, bijvoorbeeld voor het opvragen van grote multimediabestanden. Logging van alle interacties, zodat de rechtmatigheid achteraf kan worden gecontroleerd en interacties onweerlegbaar worden vastgelegd.

6.12.2 Functionaliteit van aangesloten zorgsystemen Afschermen van onbevoegde toegang tot het systeem; Beveiligd opslaan van beveiligingsgegevens (“private keys” etc.); Controleren en verifiëren van identiteit van ZIM; Logging van alle externe transacties.

6.12.3 Inrichting PKI: certificaatprofielen Inleiding Om de rechtmatigheid van toegang tot zeer privacygevoelige informatie te kunnen garanderen en controleren, is het toepassen van PKI en daarmee van certificaten noodzakelijk. De aanbieding van een identiteit van zorgverleners vindt plaats door de (elektronische) afgifte van elektronische certificaten. Elektronische certificaten zijn gekoppeld aan de identiteit van de persoon. Voor zorgverleners wordt vereist dat certificaten op een zogenaamde UZI-pas (smart card) worden bewaard, zodat geen toegang kan worden verkregen tot de bij het certificaat behorende sleutelinformatie. Daarnaast is het voor een beveiligde communicatie noodzakelijk dat de betrokken systemen kunnen worden geauthenticeerd. Het gaat hier om de gemeenschappelijke functies en de informatieleverende systemen. Ook voor deze authenticatie kunnen certificaten worden toegepast.

Passenmodel Passen kunnen worden aangevraagd door een zogenaamde “abonnee”. Onder abonnee wordt verstaan “een natuurlijke of rechtspersoon die met het UZI-register een overeenkomst sluit waardoor deze persoon afnemer wordt van certificaatdiensten”. Een abonnee kan een zorginstelling of een individuele zorgverlener zijn. De verschillende passen die in het passenmodel van het UZI-register worden gehanteerd zijn: o

Pas voor een “Individuele zorgverlener” Een beroepsbeoefenaar als bedoeld in de artikelen 3 en 34 van de Wet BIG werkzaam in een zorginstelling krijgt op verzoek van de zorginstelling een zorgverlenerpas of kan zelf een aanvraag doen voor een Individuele zorgverlenerpas. Uitreiking van de pas vindt plaats op basis van een face-to-face controle en controle van de wettelijke identiteit, nadat getoetst is of het daadwerkelijk om een zorgverlener gaat. Het UZIregister garandeert naast de persoonlijke identiteit tevens de “status zorgverlener” en


- 57 -

o

o

o

de relatie naar de abonnee. Zorgverleners krijgen een persoonlijke pas met pasfoto en driecertificaten en sleutelparen (authenticatie, vertrouwelijkheid en onweerlegbaarheid). Pas voor een “Medewerker op naam” Een medewerker van een zorginstelling of die door een individuele zorgverlener si aangewezen als hulppersoon, kan de beschikking krijgen over een pas “Medewerker op naam” Uitreiking van de pas vindt plaats op basis van een face-to-face controle en controle van de wettelijke identiteit na een verzoek van een geautoriseerde aanvrager. Het UZI-register garandeert naast de persoonlijke identiteit tevens de relatie naar de abonnee. Medewerkers op naam krijgen een persoonlijke pas met een pasfoto en drie certificaten en sleutelparen (authenticatie, vertrouwelijkheid en onweerlegbaarheid). Pas voor een “Medewerker niet op naam” Voor medewerkers van een zorginstelling of die door een individuele zorgverlener zijn aangewezen als hulppersoon kan een UZI-pas worden verkregen. De certificaten van deze UZI-pas geven aan dat de pashouder een medewerker is van de abonnee die in het certificaat wordt genoemd. De abonnee is verantwoordelijk voor de juistheid van de gegevens op de certificaten van de medewerker. Het UZI-register garandeert alleen de relatie naar de abonnee. Medewerkers niet op naam krijgen een nietgepersonaliseerde UZI-pas met twee certificaten en sleutelparen (authenticatie en vertrouwelijkheid). Servicespas Voor services (systemen, websites, gegevensverzamelingen, servers etc.) in een zorginstelling of van een individuele zorgverlener kan een UZI-pas14 verkregen worden. De certificaten op de servicespas geven aan dat een bepaalde service namens de abonnee een bepaalde functionaliteit biedt. De abonnee is verantwoordelijk voor de juistheid van de gegevens van haar services op deze servicespas. Het UZI-register garandeert alleen de relatie naar de abonnee. Voor services zijn het authenticiteits- en vertrouwelijkheidscertificaat gecombineerd in één certificaat. De drager van de certificaten wordt veelal bepaald door de aard van de betrokken services, maar zal veelal en High Security Module (encryptiemodule) zijn.

Vertrouwensrelatie De gebruikerscertificaten die hiervoor zijn beschreven, worden uitgegeven door de certificatie autoriteit (CA) van het UZI. Omdat het UZI-register werkt volgens de richtlijnen van PKIoverheid (Zie eisen [27] en leidraad [28] van PKI overheid), wordt de CA van het UZI-register door PKIoverheid als vertrouwd aangemerkt en is onder de root van de Staat der Nederlanden opgenomen (zie Figuur 6-1).

14

Hoewel een systeemcertificaat meestal niet op een smartcard wordt geplaatst, wordt voor het gemak ook in

dit geval over een UZI-pas gesproken.

- 58 -


Figuur 6-1: CA-model voor het UZI-register

Criteria certificaatprofielen Bij de criteria die ten grondslag liggen aan de gepresenteerde profielen wordt zoveel mogelijk aangesloten bij de ontwikkelingen in de Nederlandse en Europese markt. De certificaatprofielen zijn opgesteld aan de hand van de criteria zoals vastgelegd in de volgende documenten: [27], [28], [29] en [30]. Om een brede toepasbaarheid van de certificaten te garanderen zijn daarnaast de richtlijnen zoals vastgelegd in [31] en [32], gebruikt.

Formaat certificaatprofielen Hier komt de inhoud van certificaatprofielen en het formaat waarin deze zijn beschreven aan de orde. Een X.509 certificaat bestaat uit een verzameling objecten. Ieder object heeft een naam, en bestaat uit een aantal attributen. Een attribuut kan diverse zaken bevatten: sleutels, algoritmen, namen, types, andere objecten, etc. Een certificaatprofiel beschrijft welke objecten worden gebruikt en welke waarden de attributen van deze objecten kunnen bevatten. De definitie van het certificaatprofiel staat beschreven in een apart document [37]. Voor het certificaatprofiel van eindgebruikers is de keuze gemaakt om zowel het UZI-nummer als de AGB-code op te nemen.

Certificaatvalidatie De certificaten kunnen worden gevalideerd door gebruik te maken van de Certificate Revocation List (CRL). Deze lijst van certificaten wordt eenmaal in de vier uur


- 59 -

bijgewerkt. CIBG hanteert de RFC 3280 (‘Internet X.509 Public Key Infrastructure Certificate and CRL Profile’) voor generatie van de Certificate Revocation List [29]. Het profiel van de CRL staat beschreven in een apart document [37]. Naast de publicatie van CRL’s biedt het UZI-register ook certificaat statusinformatie via OCSP (Online Certificate Status Protocol). OCSP validatie is een online validatie methode waarbij het UZI-register aan de vertrouwende partij een elektronisch ondertekend bericht verstuurt nadat de vertrouwende partij een specifiek verzoek heeft verstuurd naar de OCSP-dienst van het UZI-register. De informatie die via de OCSP-dienst wordt verstrekt kan actueler zijn dan de informatie die via de CRL wordt gecommuniceerd. Dit is alleen het geval als er een intrekking heeft plaatsgevonden en de reguliere CRL update nog niet heeft plaatsgevonden. OCSP wordt niet door het LSP ondersteund. Zorgsystemen die gebruik willen maken van deze dienst dienen direct het UZI-register te benaderen.

6.13 Invulling van gemeenschappelijke voorzieningen In de architectuur worden de volgende voorzieningen landelijk centraal ingevuld: 1. het UZI-register, dat fungeert als een PKI voor het uitgeven, beheren, valideren van identiteitcertificaten voor zorgverleners; het registreren (de RA) van UZI-passen gebeurt centraal bij het UZI-register; 2. het UZOVI15-register, waarmee een verzekeraar eenduidig kan worden geïdentificeerd; in een latere fase kan dit register ook een PKI voor de zorgverzekeraars gaan ondersteunen; 3. op termijn is wellicht ook een VDZ16-register noodzakelijk om zorgpartijen die niet in het UZI-register of UZOVI-register staan te kunnen idintificeren en authenticeren; dit register moet ook als een PKI gaan werken; 4. toegang tot een voorziening waarmee het BSN van een patiënt kan worden opgevraagd; Hiervoor wordt voorzien dat dit kan worden ingevuld door bevraging van een zogenaamde Sectorale Berichten Voorziening voor de Zorg (SBV-Z) die toegang geeft tot het BSN-stelsel; 5. registers voor vastlegging autorisatieprotocol en –profiel; 6. een certificatie-autoriteit (CA) voor een PKI in de zorg; 7. de gezamenlijke set afspraken m.b.t. semantiek, syntax en gebruikte invulling van de protocollen kunnen worden vastgelegd in een bestand, dat desgewenst via een repository (informatieportaal voor codestelsels) toegankelijk kan worden gemaakt. 8. (optioneel) bestand waarin zorgaanbieders en hun gegevens zijn opgenomen (zorgaanbiedergids of directory); 15

Unieke ZOrgVerzekeraars Identificatie

16

Vierde Domein register voor de Zorg

- 60 -


Een aantal voorzieningen kunnen zowel regionaal als landelijk worden ingevuld. Bestuurlijke en organisatorische overwegingen hebben geleid tot een keuze voor een landelijke invulling, niet noodzakelijkerwijs op één fysieke locatie. Deze voorzieningen worden geleverd door een functionele module die Zorg Informatie Makelaar (ZIM) wordt genoemd. De in het vorige hoofdstuk genoemde organisatorische eenheid Landelijk SchakelPunt (LSP) zal verantwoordelijk zijn voor inrichting en beheer hiervan. De ZIM zal de volgende voorzieningen bevatten: 1. verwijsindex: vullen en onderhouden van verwijzingen naar verwijsindexen, het vinden van een verwijzing; 2. identificeren en authenticeren van de aanvragende zorgverlener; 3. identificeren en authenticeren van de aangesloten GBZ’n; 4. vaststellen van de privileges die behoren bij de functie van de zorgverlener en zorgverzekeraar (autorisatie); 5. berichtverwerking en afhandeling: doorgeven van aanvraag aan gegevensleveranciers en antwoorden naar de gegevensvrager; 6. loggen van een aantal van de gegevens van uitgewisselde berichten; 7. ondersteunen van aan- en afmelden van abonnementen van zorgverleners op bepaalde patiëntgegevens; 8. signaleren van gepubliceerde informatie naar abonnementshouders; 9. het bieden van generieke (IP-) connectiviteit tussen DCN’en, inclusief DNSdienstverlening; 10. (optioneel) validatie van berichten en translatie van berichten en/of berichtdelen (bijvoorbeeld bij gebruik van verschillende codestelsels voor andere domeinen). Daarnaast is er een tweetal voorzieningen die ook een regionale of zelfs lokale component kennen: 1. de uitgifte van UZI-passen gebeurt decentraal bij de postkantoren. 2. het bieden van generieke connectiviteit door middel van een Data Communicatie Netwerk (DCN) door Zorg Service providers (ZSP’s). In de zorg heeft veel communicatie een sterk regionaal karakter waarbij het meeste verkeer binnen een regio blijft. Dit regionale karakter kan worden gebruikt om te komen tot een zeer schaalbaar LSP/ZIM ontwerp door de afhandeling van het verkeer van een regio door een deelsysteem te laten verzorgen. Alleen bij communicatie over de grenzen van de eigen regio vindt communicatie via andere deelsystemen plaats. Op deze wijze kan de belasting van de gemeenschappelijke voorzieningen efficiënt over meerdere deelsystemen worden verdeeld.


- 61 -

Het totaaloverzicht van de gemeenschappelijke voorzieningen en de organisaties die daar momenteel bij betrokken zijn, wordt op hoofdlijnen aangegeven in Figuur 6-2. Met stippellijnen zijn de voorzieningen getekend die nog moeten worden gerealiseerd.

CIBG

ICTU BV BSN BSN

SBV-Z (BSN)

Vektis

NICTIZ Landelijk Schakel Punt ZIM

UZI register UZI

Gemnet

UZOVI register UZOVI

DCN’en

UZI-pas

LRD

GBA GBA GBA

Gemeenten

ZSP

Zorg Zorg Zorg XIS aanbieder aanbieder aanbieder

Zorg Zorg Zorg aanbieder aanbieder verzekeraar Figuur 6-2: Totaaloverzicht gemeenschappelijke voorzieningen

6.14 Interactieprincipes tussen zorgsystemen en infrastructurele voorzieningen 6.14.1 Inleiding Veel communicatie die via de basisinfrastructuur plaatsvindt zal gericht zijn op het opvragen van patiëntinformatie. Het communicatiepatroon loopt dan altijd via het LSP/ZIM. Er zijn echter ook informatiestromen die niet noodzakelijkerwijs via het LSP/ZIM behoeven te lopen, bijvoorbeeld omdat de communicatiepartner op voorhand bekend is, zoals bij verwijzing, waarneming, receptberichten, declaraties etc. Bij het bepalen van het te gebruiken communicatiepatroon wordt onderscheid gemaakt tussen: • opvragen van, voornamelijk medische, patiëntinformatie • verzenden van, voornamelijk medische, patiëntinformatie • niet-medische communicatie In het navolgende wordt voor deze situaties beschreven hoe het communicatiepatroon het beste kan verlopen.

- 62 -


6.14.2 Communicatiepatroon bij opvragen van patiëntinformatie De basiscommunicatievorm voor het snel vinden en toegankelijk maken van gezochte patiëntinformatie is aangegeven in Figuur 6-3. In de meeste gevallen is het de meest efficiënte methode om een informatieverzoek rechtstreeks via de verwijsindex te laten afhandelen. Daarbij kunnen de aangesloten systemen er op vertrouwen dat autorisaties door de LSP/ZIM zijn gevalideerd en dat een formele vastlegging van alle transacties die via het LSP/ZIM lopen door een onafhankelijke partij wordt verzorgd.

Vraag

Aanvrager Aanvrager

1

LSP/ LSP/ ZIM ZIM

Antwoord

4 3 Antwoord

Vraag

Leverancier Leverancier 11

2

Leverancier Leverancier nn

Figuur 6-3: Aanvraag en aflevering via gemeenschappelijke functie bij opvragen van informatie De argumenten om op deze wijze via een gemeenschappelijk ZIM te communiceren zijn: 1. Via de Verwijsindex kan worden bepaald waar zich de informatie bevindt die door de zorgverlener wordt gezocht, zodat een efficiënte bevraging van de zorgsystemen kan worden gerealiseerd. 2. De ZIM controleert de identiteit van de zorgverlener. De aangesloten zorgsystemen hoeven deze controle dan niet meer uit te voeren. Er dient nog wel een controle van identiteiten op systeemniveau plaats te vinden. 3. Het ZIM kan op basis van functie van de zorgverlener bepalen welke rechten of “privileges” aan een bepaalde zorgverlener worden toegewezen. Door dit centraal te regelen wordt eenvormigheid in de toegangsverlening gerealiseerd. 4. Met de logging wordt een soort van “notarisfunctie” in de infrastructuur belegd. Hiermee kan de onweerlegbaarheid van informatievragen en verzendingen worden aangetoond en kan eventueel misbruik worden getraceerd. Vandaar dat deze functie onder onafhankelijk toezicht dient te staan. Overigens wordt deze functie ook door hedendaagse communicatie dienstenleveranciers al geboden.


- 63 -

5. Door de combinatie van een betrouwbaar transportprotocol en logging ontstaat een vorm van onweerlegbaarheid, zonder dat een elektronische handtekening voor elke handeling noodzakelijk is. 6. Indien gewenst of noodzakelijk kan in het LSP ook een berichtvertaling plaatsvinden. 7. De eindsystemen worden ontlast omdat ze maar met één ander systeem behoeven te communiceren (openstaan SSL-sessies) In dit architectuurontwerp wordt er van uitgegaan dat (vulling van) de verwijsindex, generieke autorisatie en (niet inhoudelijk) logging van transacties, functies zijn die vanwege de uniformiteit en formele juridische vastlegging moeten worden belegd bij een “trusted third party” die onafhankelijk is van de betrokken communicatiepartijen. Lokale applicaties kunnen in deze configuratie betrekkelijk licht worden opgezet. De eisen die door de sector worden gesteld aan veiligheid en vertrouwen in de gemeenschappelijke functies zijn zeer hoog. Deze opzet heeft als voordeel dat een eenvoudige procesbewaking voor de juiste afhandeling van transacties kan worden gerealiseerd. Daar staat tegenover dat de communicatie via de gemeenschappelijke module(s) verloopt, waardoor een potentiële performance bottleneck kan ontstaan. Hiermee moet in de dimensionering rekening worden gehouden.

6.14.3 Afwijkingen van het basiscommunicatiepatroon bij opvragen van informatie Dit betekent echter niet dat altijd alle communicatie via het LSP/ZIM zal moeten lopen. In bepaalde gevallen kan dit leiden tot inefficiënties en kan beter rechtstreekse communicatie met eindsystemen plaatsvinden. Indien daarbij generieke autorisatie en onafhankelijke logging vereist is, dienen aanvullende maatregelen te worden getroffen, waarop hieronder kort zal worden ingegaan. Een voorbeeld van het type verkeer waarbij een alternatief communicatiepatroon kan worden overwogen, is het overdragen van grote bestanden. De architectuur kan werken voor grote volumes indien de berichten niet te groot worden. Een alternatief communicatiepatroon kan er in voorzien dat zeer grote bestanden ook rechtstreeks tussen eindsystemen kunnen worden uitgewisseld. Nadere uitwerking van de bedrijfsprocessen waarbij dergelijke bestanden worden uitgewisseld, moet nog plaatsvinden. Een mogelijke methode is die waarbij het LSP/de ZIM bepaalt of een verzoek om informatie wordt doorgezet naar een leverend systeem of dat een verwijzing aan het vragende systeem wordt teruggegeven. Het communicatiepatroon dat hierbij van toepassing is, wordt weergegeven in Figuur 6-4.

- 64 -


1 Vraag

Aanvrager Aanvrager

Verwijzing

LSP/ LSP/ ZIM ZIM

2

3 Vraag

5

Check autorisatie, meld logging

4

Antwoord Leverancier Leverancier 11


Figuur 6-4: Rechtstreeks opvragen na verwijzing door LSP/ZIM De keuze om een verwijzing terug te sturen kan op basis van de gevraagde gegevenssoort (bijvoorbeeld radiologie, röntgenfoto) plaatsvinden. Het voordeel van deze methodiek is dat het LSP/ZIM met het meegeven van een verwijzing ook authenticatieen autorisatie-informatie kan meegegeven in de vorm van een zogenaamde “security assertion”. Het gegevensleverende systeem kan controleren of de opvragende zorgverlener gerechtigd is deze informatie te ontvangen door te controleren of de “security assertion” geldig is en op grond daarvan besluiten het bestand rechtstreeks toe te zenden zonder tussenkomst van LSP/ZIM.

6.14.4 Communicatiepatroon bij verzenden van patiëntinformatie Bij het verzenden van patiëntinformatie dient een keuze gemaakt te worden om rechtstreeks te verzenden of via het LSP/ZIM. In een aantal gevallen kan het nuttig zijn gebruik te maken van de functionaliteit van de ZIM bijvoorbeeld voor autorisatie en/of het bieden van onweerlegbaarheid. In die gevallen heeft verzenden via de ZIM de voorkeur (zie Figuur 6-5).


- 65 -

Gebruiker Gebruiker 11

Bericht

1

LSP/ LSP/ ZIM ZIM

2 Bericht


Gebruiker Gebruiker nn

Figuur 6-5: Verzenden van gegevens via LSP/ZIM In de overige gevallen kan rechtstreeks worden gecommuniceerd met andere gebruikers (Zie Figuur 6-6).

LSP/ LSP/ ZIM ZIM


Bericht

1



Figuur 6-6: Rechtstreeks verzenden van gegevens tussen zorgverleners (en/of zorgverzekeraars)

- 66 -


6.14.5 Communicatiepatroon bij niet-medische communicatie Voor niet-medische communicatie wordt uitgegaan van rechtstreekse communicatie tussen gebruikers, waarbij desgewenst wel gebruik kan worden gemaakt van de beschikbare PKI-functionaliteit maar de functionaliteit van het LSP/ZIM niet noodzakelijk is (zie Figuur 6-7).


LSP/ LSP/ ZIM ZIM



Figuur 6-7: Rechtstreekse niet-zorginhoudelijke communicatie

6.14.6 Het gebruik van Portals In toenemende mate worden allerlei vormen van zogenaamde “portals” gebruikt om informatie te ontsluiten. Wij gebruiken hier de term “portal” om het concept aan te duiden van een “web site” die als een gateway toegang biedt tot informatie. Toegang tot de informatie die via een portal toegankelijk wordt gemaakt, kan worden geboden via een standaard “browser” via Internet of via een besloten netwerk. Vanzelfsprekend blijven de beveiligingseisen in deze situatie onverkort van kracht ook voor het realiseren van de toegang van de browser tot de portal.


- 67 -

GBZ Browser Browser

Portal Portal

Vraag Antwoord

LSP/ LSP/ ZIM ZIM

Aanvrager Antwoord

Vraag

Leverancier Leverancier 11


Figuur 6-8: Toegang tot de basisinfrastructuur via een portal-configuratie.

Naar verwachting zullen er voor verschillende doelgroepen diverse portals gaan ontstaan waarmee een veelheid aan diensten aan die groepen zorgverleners geboden kan gaan worden. Aangezien dit waarschijnlijk een interessante vorm van dienstverlening is voor marktpartijen worden portals niet gezien als een voorziening die deel uitmaakt van de minimale voorzieningen van de basisinfrastructuur. Een portal met zijn toegangsconfiguratie zal derhalve worden beschouwd als een speciaal type GBZ. Alleen als aan de generieke eisen van een GBZ is voldaan (zie 7.6.2) kan deze worden aangesloten op de basisinfrastructuur.

- 68 -


7

De technische architectuur

7.1 Het servicemodel Voor het beschrijven van de technische architectuur maken we gebruik van een model. Dat model moet aan vier eisen voldoen: • er moet gebruik gemaakt worden van de specifieke structuurkenmerken die voor ICT-artefacten redelijk algemeen aanvaard zijn; • er moet een zodanige visuele presentatie worden gemaakt, dat deze op bestuurlijk niveau processen en beslissingen ondersteunt over de verdere realisatie en planning van het geheel (wat en wie); • het model moet gegevens bevatten die voor het verdere ontwerp nodig zijn; • het model moet naar de huidige inzichten aannemelijk maken dat de weg naar EPD en vervolgens e-zorg wordt geplaveid.

Figuur 7-1: Basismodel Technische Architectuur Als basismodel wordt gebruik gemaakt van een service model: een gelaagde hiërarchie, waarbij componenten uit een hogere laag een ‘service’ vragen aan een lagere laag. Voor de invulling wordt gekozen voor een 3-laags-model (zie Figuur 7-1) De getoonde lagen hebben de volgende functionaliteit: A. Toepassingen (ook wel de applicaties genoemd), onder te verdelen in: a. zoals die bij de diverse instellingen worden gebruikt (HIS, ZIS en overige lokale toepassingen); b. Infrastructurele toepassingen, bijvoorbeeld voor het realiseren van generieke functies als directories, verwijsindex en beveiliging; B. Interoperabiliteit/berichtcommunicatie, voor het ondersteunen van interacties tussen applicaties; C. Transport, de onderliggende netwerktechnologie.


- 69 -

Daarnaast zijn er bepaalde gebieden, beveiliging, continuïteit en beheer, die niet specifiek aan een bepaalde laag kunnen worden toegewezen, maar juist in hun samenhang voor het gehele ICT-bouwwerk moeten worden beschouwd. Dit is in het model aangegeven door een aparte kolom naast de drie lagen te plaatsen.

7.2 Relatie met het OSI-model Een bekend model voor het beschrijven van interconnectie tussen “open” systemen is het zogenaamde OSI-model17. Met name wat betreft de hogere lagen is het model minder goed bruikbaar omdat de functionaliteit in de architectuur niet eenvoudig is af te beelden op de OSI-lagen. Dit komt enerzijds omdat in applicaties vaak geen formele scheiding tussen de bovenste drie OSI-lagen wordt toegepast (zie hiervoor bijvoorbeeld [13]); het OSI-model is hier dus te gedetailleerd. Anderzijds is op applicatieniveau heel veel functionaliteit die juist weer moeilijk is te structureren m.b.v. het OSI-model. De relatie met het OSI-model staat weergegeven in Figuur 7-2.

Figuur 7-2: Relatie met het OSI-model

7.3 Functionele modules, protocollen en koppelvlakken De gelaagdheid van het servicemodel is ook te herkennen in de functionaliteit van de aangesloten systemen. Bestaande applicaties worden uitgebreid met extra functies op iedere laag van het servicemodel, zodat volgens de afgesproken protocollen kan worden gecommuniceerd met andere systemen van zorgverleners. Om de juiste informatie te kunnen vinden en de communicatie te laten verlopen volgens procedures die privacy, rechtmatigheid van informatievragen en integriteit van de gegevens waarborgen, dient

17

OSI staat voor Open Systems Interconnection. Het model is ontwikkeld door ISO, International Standards

Organisation.

- 70 -


de communicatie plaats te vinden via gemeenschappelijke voorzieningen. In Figuur 7-3 zijn de koppelvlakken aangegeven tussen de systemen.

Gebruiker A

APP

Gemeenschappelijke voorzieningen

VWI

LOG

AUT

I&A

Gebruiker B

APP

Berichten

Transport

protocollen

koppelvlakken

Figuur 7-3: Koppelvlakken en protocollen tussen systemen

De • • • • •

gebruikte afkortingen zijn: APP = Applicatie VWI = Verwijsindex LOG = Logging AUT = Autorisatie I&A = Identificatie en authenticatie

Gebruiker A en B kunnen zorgverleners zijn die medicatiegegevens uitwisselen. In de toekomst kunnen ook andere gebruikers en dienstverleners op dezelfde wijze op de gemeenschappelijke voorzieningen van de basisinfrastructuur zijn aangesloten.

7.4 Invulling van de lagen Uitgangspunten bij de invulling van de architectuur zijn: • Als applicaties en databases hun werking en hun gegevensstructuur en semantiek via gestandaardiseerde systematieken met elkaar delen en uitwisselen, dan is het relatief eenvoudig deze componenten te vernieuwen, aan te vullen, op te heffen etc; het is dan niet nodig bij wijziging van een applicatie alle andere applicaties ook aan te passen.


- 71 -

•

•

Voor de uitwisseling van informatie wordt gebruik gemaakt van gestandaardiseerde XML-berichten. Als men voor de berichtcommunicatie gebruik maakt van standaarden, kan voor de communicatie gebruik gemaakt worden van veel voorkomende en dus bekende en goedkope programma’s; Voor transport wordt gebruik gemaakt van Internetstandaarden (TCP/IP).

Applicaties die niet voldoen aan bovenstaande eisen, dus bijvoorbeeld geen datafunctiescheiding hebben, of een eigen messaging-mechanisme gebruiken, bemoeilijken implementaties. Bijna alle systemen uit het verleden hebben zo’n handicap. We noemen dit ‘legacy’-systemen. Er zijn ook recent gebouwde systemen die nog steeds aan dezelfde euvels lijden.

Een oplossing voor dit probleem is het gebruik van ‘vertalers’. Daarvoor zijn twee methoden beschikbaar: het uitbreiden van de applicatie met een vertaalmodule of een gemeenschappelijke vertaalapplicatie (die bijvoorbeeld "legacy berichtgegevens" ontvangt en omzet naar een XML gedefinieerd formaat). Zoals eerder aangegeven zal de infrastructuur in de toekomst wellicht tijdelijk diverse standaarden van gegevenssets en berichtstructuren en verschillende parallelle versies daarvan gaan ondersteunen. In dat geval dient berichttranslatie in de infrastructuur plaats te vinden. Vooralsnog wordt dit als een optionele functie in de architectuur opgenomen.

7.4.1 Netwerkniveau Op het netwerkniveau is de huidige situatie dat veel partijen al op basis van Internetprotocollen (TCP-UDP/IP) communiceren. Sommige organisaties hebben een besloten netwerk ingericht met andere organisaties. Voor de basisinfrastructuur is een belangrijke ontwerpkeuze of voor de gehele sector een eigen besloten netwerk moet worden ingericht. Met VPN-technieken in combinatie met bandbreedtegaranties kan wel een verbeterde continuïteit en een hoger niveau van beveiliging voor de basisinfrastructuur worden gerealiseerd. In paragraaf 7.5 Beveiliging, continuïteit en beheer wordt hier verder op ingegaan.

7.4.2 Interoperabiliteit/berichtcommunicatie In de applicatie is data op een bepaalde manier opgeslagen. Interoperabiliteit is noodzakelijk om applicaties te laten samenwerken. In deze paragraaf worden enkele beschikbare technologieopties besproken voor het realiseren van interoperabiliteit tussen applicaties. Daarna wordt op basis van een aantal criteria een keuze gemaakt voor de architectuur.

Technologiekeuzen Geen van de beschikbare oplossingsrichtingen voor technologiekeuzen hebben zich, gezien de vereiste schaalgrootte en heterogeniteit van de ICT-omgevingen in de

- 72 -


zorgsector, bewezen voor wat betreft de toepassing zoals vereist voor een landelijke zorginfrastructuur. Dit geldt voor CORBA en J2EE, weliswaar bewezen technieken voor interne bedrijfsomgevingen, maar onvoldoende toegepast over organisatiegrenzen heen. Messaging is een beproefde technologie die aansluit bij de bestaande praktijk van berichtuitwisseling op basis van Edifact en HL7. Dit betreft echter niet de technologie voor Web Service Messaging. Hoewel deze technologie breed wordt gezien als een veelbelovende technologie voor B2B-interoperabiliteit (vergelijkbaar met de heterogene zorgomgeving), is er met name op het gebied van betrouwbaar transport nog geen algemeen aanvaarde oplossing18. COM/DCOM en .NET vallen af vanwege de leverancierafhankelijkheid (Microsoft). Integration brokers tenslotte vallen af vanwege de grote complexiteit die in de infrastructuur ontstaat en de verwachte problemen met de schaalbaarheid. Als criteria om tot een technologiekeuze te komen, gelden: • het dient een gestandaardiseerde technologie te zijn die industriebreed wordt gedragen. • implementaties moeten platformonafhankelijk zijn. • bij voorkeur dient te worden uitgegaan van “bewezen” (proven) technologie. Geen van de bovenstaande technologieën voldoet volledig aan deze criteria. Ook de Web Service Messaging technologie is, met name op het gebied van beveiligd en betrouwbaar transport, nog niet volledig uitontwikkeld. Gezien de mogelijkheden een grote diversiteit aan applicaties op een standaard manier te koppelen en te laten samenwerken, is gekozen voor uitwisseling van berichten met Web Service Messaging met de volgende eigenschappen: Het bericht definieert de volledige serviceaanroep; deze methode leidt tot transparante interacties tussen toepassingen, meer hergebruik en simpeler structuren; Voldoet aan eis van ontkoppeling, waardoor het systeem blijft functioneren in situaties waarbij bijvoorbeeld componenten falen, computers niet altijd actief zijn, de betrouwbaarheid van het netwerk of de beschikbare bandbreedte onvoldoende zijn en/of applicaties worden aangepast. Om gebruik te kunnen maken van deze technologie wordt een aantal aanvullende maatregelen getroffen op het gebied van beveiligd en betrouwbaar transport, die als bewezen technologie kunnen worden beschouwd (zie paragraaf 7.5). Web Service Messaging vereist op XML gebaseerde technologieën om gegevens te transporteren en transformeren tussen applicaties en databases. Daarbij wordt SOAP toegepast voor transport via Internettechnologie. Dit protocol definieert een enveloppe voor communicatie, die is te transporteren via http en andere transportprotocollen. 18

Hoewel ebMS v2.0 inmiddels redelijk breed in de markt wordt toegepast zijn er nog volop ontwikkelingen op dit gebied.


- 73 -

De keuze voor Web Service Messaging betekent19: • XML berichten conform de HL7v3 standaard; • Gebruik van SOAP en transport via HTTP; • Het gebruik van WSDL voor het beschrijven van de Web Service; hiermee wordt een betere interoperabiliteit gerealiseerd tussen verschillende platformen en programmeeromgevingen; • Gebruik maken van de WS-I Basic Profile; in de Basic Profile worden richtlijnen gegeven hoe SOAP en WSDL te gebruiken om de interoperabiliteit te verbeteren. Berichtcommunicatie kan worden gerealiseerd door de applicaties aan te passen zodat ze de berichtcommunicatie zelf verzorgen. Dit kan echter ook als een infrastructurele voorziening worden aangeboden. Zo zijn er zogenaamde "message brokers" op de markt die de inhoudelijke messaging tussen applicaties reguleren. Deze brokers bieden vaak additionele functionaliteit zoals secure messaging, berichttranslatie en ‘workflow’ oplossingen in de markt. Standaarden die momenteel veel in gebruik zijn, zijn: HL7v2 binnen instellingen20 en Edifact tussen instellingen. Aangezien er al veel Edifact- en HL7v2-toepassingen zijn in de zorgsector, lijkt het aantrekkelijk een vertaler voor deze standaarden naar HL7v3 XML te maken waar iedereen desgewenst gebruik van kan maken. Echter argumenten om zo’n vertaler te motiveren als een noodzakelijke infrastructuur voor medicatie zijn thans niet voorhanden. Het zou wel als een optionele dienstverlening geboden kunnen worden.

7.4.3 Infrastructurele toepassingen De voorzieningen zoals aangegeven in paragraaf 6.9 zullen als infrastructurele applicaties worden gerealiseerd. Deze zullen in de specificaties verder worden uitgewerkt.

7.4.4 Toepassingen Op een GBZ kunnen verschillende zorgtoepassingen draaien. Bij databases moet er rekening mee worden gehouden dat bestaande implementaties van zorgverleners (al dan niet via een ASP) en instellingen veelal optimaal zijn ingericht voor de eigen bedrijfsvoering van de autonome organisaties; het is zinvol alleen die gegevens bijvoorbeeld via XML te standaardiseren wanneer ze extern zullen worden verzonden of van een externe instantie worden ontvangen. Dat brengt wel de eis met zich mee, dat er vertaalgateways door die organisaties moeten worden ingericht tussen de eigen legacyformaten en de extern te gebruiken formaten. Bepaalde vertaalfuncties kunnen als infrastructuur worden gerealiseerd, bijvoorbeeld als Edifact-berichten via een centrale

19

In de Specificaties van de Basisinfrastructuur wordt de meer gedetailleerde informatie over de te gebruiken

versies van deze standaarden benoemd. 20

Momenteel wordt in Nederland HL7 versie 2.2 veel toegepast. Ondersteuning van XML in de HL7 standaard is

er vanaf versie 2.4.

- 74 -


gateway worden vertaald. Hiermee ontstaat de mogelijkheid ieder gewenst datapakket te generen voor de e-zorg toekomst.

7.5 Beveiliging, continuïteit en beheer 7.5.1 Inleiding Zoals al eerder aangegeven is beveiliging één van de cruciale aspecten van de architectuur voor de zorg. Naast het creëren van een veilige netwerkomgeving, veilig en betrouwbaar berichtenverkeer en het certificeren van GBZ’n dienen ook de zorgapplicaties te voorzien in adequate beveiligingsmaatregelen. Naast het vraagstuk om in het architectuurontwerp te kunnen voldoen aan de eisen voor continuïteit en kwaliteit van de dienstverlening, zijn ook organisatorische maatregelen noodzakelijk die hier niet verder aan de orde komen.

7.5.2 Garanderen van de vertrouwelijkheid van informatieuitwisseling In deze paragraaf wordt aan de orde gesteld hoe kan worden voorzien in veilige communicatie tussen zorgaanbieders (en zorgverzekeraars) waarbij de vertrouwelijkheid van de informatie-uitwisseling kan worden gegarandeerd. Allereerst wordt ingegaan op het bepalen van de te gebruiken technologie voor het realiseren van de vertrouwelijkheid bij informatie-uitwisseling binnen en tussen DCN’s. Daarna wordt ingegaan op de technologische aspecten van het koppelen van DCN’s. Technologiekeuze Hier worden drie scenario’s besproken: twee scenario’s die in de praktijk vaak voorkomen en een scenario dat momenteel in standaardisatieorganen wordt ontwikkeld. In het eerste scenario wordt gebruik gemaakt van door service providers geleverde VPN’s. Het tweede scenario is gebaseerd op het gebruik van eind-tot-eind versleuteling tussen zorgsystemen die met elkaar communiceren. In beide gevallen gaat het over informatie-uitwisseling door een beveiligde ‘tunnel’ tussen de aangesloten zorgverleners. Door deze tunnel kunnen patiëntgegevens worden uitgewisseld zonder dat andere gebruikers van de desbetreffende infrastructuur daartoe toegang of inzage hebben. Daarnaast wordt nog een derde scenario behandeld, gebaseerd op recent ontwikkelde standaarden voor gebruik van encryptie op berichtniveau van W3C. Deze ontwikkeling biedt nieuwe mogelijkheden, zoals het gedeeltelijk versleutelen van berichten. 1. Scenario 1: Het gebruik van een provider-based VPN. In dit scenario neemt een aantal zorgverleners, bijvoorbeeld in een regionaal zorgnetwerk, gezamenlijk een VPN-dienst af van één aanbieder. Een voordeel van door aanbieders verzorgde VPN’s is dat garanties over de vereiste performance Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 75 -

(bijvoorbeeld eind-tot-eind delay etc.) kunnen worden afgegeven, iets wat bij openbaar internet over het algemeen niet gebeurt. Bij het afnemen van een VPNdienst kunnen kwaliteitsgaranties worden afgesproken. De term VPN zorgt voor veel verwarring omdat deze niet eenduidig is gedefinieerd. De meest geleverde variant is die waarbij een aanbieder aan de zorgverleners de toegang tot een VPN levert door middel van een VPN-router (in combinatie met een, eventueel breedband-, modem). Het fysieke netwerk waarover deze verbinding loopt, kan verschillen. De beveiliging die het VPN biedt, loopt tot aan de VPN-router. Hoewel een VPN gebaseerd kan worden op beveiligingsalgoritmen op basis van een PKI, wordt vanwege de lagere beheerlast vaak gebruik gemaakt van mechanismen die niet op PKI zijn gebaseerd. In Figuur 7-4 wordt dit scenario weergegeven.

ZIM Netwerk beveiligd VPN

Zorgsysteem Zorgverlener A

Modem +VPN router

Modem +VPN router

Zorgsysteem Zorgverlener B

Figuur 7-4: Het gebruik van een VPN

Voor de weergave van beide scenario’s geldt overigens dat het werkstation van de zorgverlener in de praktijk een stand-alone PC kan zijn (van bijvoorbeeld een huisarts), maar net zo goed een netwerk binnen een zorginstelling kan representeren. 2. Scenario 2: Eind-tot-eind versleuteling op transportniveau. In dit scenario zorgen alle zorgverleners voor hun eigen toegang tot gemeenschappelijke communicatiediensten. Dit kan bijvoorbeeld het (publieke) internet zijn. De toegang kan dan door verschillende aanbieders aangeboden worden. Om te zorgen voor een veilige verbinding (sessie), van zorgsysteem tot zorgsysteem wordt gebruik gemaakt van versleuteling met SSL/TLS. SSL/TLS maakt gebruik van een Public Key Infrastructure (PKI) voor de distributie van sleutels die nodig is voor authenticatie en encryptie. SSL/TLS zorgt voor beveiliging tot en met het werkstation van de individuele zorgverlener. Ter voorkoming van inbraken vanuit het internet in het werkstation van de zorgverlener, wordt bovendien een firewall toegepast. In Figuur 7-5 wordt deze opzet weergegeven. Ook hier geldt voor de weergave van beide scenario’s dat het werkstation van de zorgverlener net zo goed een netwerk binnen een zorginstelling kan representeren. De SSL-verbinding loopt dan over het interne netwerk tot aan het systeem van de zorgverlener (GBZ).

- 76 -


ZIM Publiek Internet

Modem

Zorgsysteem Zorgverlener A

Firewall

Firewall

Modem

SSL beveiligde verbinding

Zorgsysteem Zorgverlener B

Figuur 7-5: Eind-tot-eind versleuteling op transportniveau

2. Scenario 3: Versleuteling op berichtniveau Met deze methode van beveiliging is het mogelijk delen van berichten, bijvoorbeeld alleen gevoelige of persoonsgebonden informatie te versleutelen. Dit is een interessante optie indien de bestandsinhoud anoniem is en niet herleid kan worden tot de persoon waarop de informatie betrekking heeft. In veel gevallen (bijvoorbeeld bij DICOM bestanden) is de bulkinformatie zelf niet direct herleidbaar, maar is informatie toegevoegd om aan te geven om welke patiënt het gaat. Door selectieve encryptie toe te passen op berichtniveau kan de hoeveelheid processing bij grote bestanden worden gereduceerd omdat niet het gehele bestand behoeft te worden versleuteld. Web Services Security ondersteunt deze vorm van selectieve encryptie. De relevante standaarden zijn nu in public review. De verwachting is dan ook dat een brede ondersteuning door zorgsystemen nog even op zich zal laten wachten. Wanneer de scenario’s vergeleken worden, komt een aantal voor- en nadelen naar voren. Deze kunnen afgezet worden tegen de omstandigheden, wensen en behoeften van zorgverleners. In het kort gaat het om de volgende aspecten: o Kwaliteit van de dienstverlening: voor een provider-based VPN worden doorgaans garanties afgegeven door de leverancier over kwaliteit, snelheid, beschikbare capaciteit, stabiliteit van de verbinding en hersteltijd van de verbinding. Bij gebruik van het publieke internet kunnen deze garanties meestal niet gegeven worden. o Beheer: De installatie en het beheer van de verbindingen blijft in scenario 2 en 3 bij de individuele zorgverleners, terwijl dat in scenario 1 is uitbesteed aan een VPNleverancier (daar staan uiteraard kosten tegenover). Daarnaast is in scenario 1 de installatie bij de zorgverlener gemakkelijker te implementeren. Tevens zijn in scenario 1 geen aanpassingen nodig in de applicaties die gebruikt worden bij de zorgverlener. o Beveiliging: het gebruik van een VPN biedt betere garanties voor vertrouwelijkheid omdat het een ‘dedicated’ netwerk is en met een ingebakken firewall. Ook is een VPN beter opgewassen tegen zogenoemde Denial-of-Service aanvallen (zogenaamde “DOS-attacks”). Nadeel van scenario 1 daarentegen is dat het beveiliging biedt ‘tot de Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 77 -

o

voordeur’, wat concreet betekent dat binnen grote instellingen aanvullende beveiliging vereist is. De beveiliging in scenario 2 (met SSL/TLS) en 3 (WSS Security) loopt daarentegen wel tot de gebruikte applicatie. Toegankelijkheid: het VPN is alleen toegankelijk via locaties die een VPN router bezitten, terwijl de toegang via internet vanaf elke PC (met SSL/TLS of WSS) mogelijk is. Daarmee is het gebruik van internet een stuk flexibeler dan bij een VPN het geval is.

Tot XML-encryptie als onderdeel van Web Services Security breed wordt ondersteund, zullen implementaties afhankelijk zijn van beveiliging op transportniveau (SSL/TLS of VPN of een combinatie van die twee). In de toekomst wordt in de basisinfrastructuur ondersteuning van de WSS-standaard voorzien, bijvoorbeeld om selectieve encryptie van grote bestanden bij directe opvraging uit zorgsystemen mogelijk te maken. Om kwaliteitsgaranties te kunnen geven in combinatie met het realiseren van vertrouwelijkheid van de informatie-uitwisseling zal over het algemeen gebruik worden gemaakt van provider based VPN-technologie. In aanvulling hierop zal SSL/TLS worden toegepast. Eind-tot-eind wordt hier bedoeld in de betekenis van tot op de grens van het GBZ waarop de applicatie draait. Het koppelen van DCN’en Zoals aangegeven in 5.5.2 dient er een generieke connectiviteit tussen alle aangesloten zorgaanbieders en zorgverzekeraars te worden geboden. Aangezien verschillende Zorg Service Providers (ZSP’s) hun diensten kunnen aanbieden via een eigen DCN, dient ook te worden voorzien in een veilige koppeling tussen DCN’en. In een aantal gevallen kunnen deze koppelingen onderling worden geregeld tussen ZSP’s. Echter om de generieke connectiviteit tussen alle zorgaanbieders en verzekeraars te kunnen garanderen dient koppeling tussen DCN’en als gemeenschappelijke voorziening in de basisinfrastructuur te worden opgenomen. Om de complexiteit van koppelingen tussen diverse netwerken niet te groot te laten worden, dient te worden uitgegaan van vaste IP-adressen per aansluitpunt. Om er verder voor te zorgen dat er bij een latere koppeling aan andere VPN’s geen dubbele adressen ontstaan die alleen door complexe vertalingen kunnen worden opgelost, dient gebruik te worden gemaakt van unieke adressen over het gehele in de toekomst te koppelen VPNdomein. Hierbij wordt uitgegaan van adresreeksen die internationaal zijn vastgelegd voor private nummer-plannen. Om in dat geval toch te komen tot unieke nummers zullen ZSP’s in overleg met NICTIZ moeten komen tot een unieke adrestoekenning binnen deze private adresruimte. Voor regio’s is het in dat geval een actiepunt de ZSP er op te wijzen dat het adresplan voor het VPN wordt afgestemd met het LSP. Bij koppeling tussen VPN’s moet de bereikbaarheidsinformatie van klantlocaties over alle gekoppelde VPN’s heen beschikbaar zijn. Aangezien gebruik wordt gemaakt van vaste IP-

- 78 -


adressen kan in een beginsituatie gebruik worden gemaakt van statische routering, waarbij in de aansluitingsprocedure van een GBZ het te gebruiken IP-adres wordt vastgesteld. Echter met het oog op een meer complexe situatie die in de toekomst kan gaan ontstaan dient er rekening mee te worden gehouden dat routeringsprotocollen worden toegepast. Om de koppeling tussen netwerken niet te complex te maken zal slechts een beperkt aantal van dergelijke protocollen ondersteund gaan worden. Bij koppeling van DCN’en dient bovendien een unieke naamgeving te worden gerealiseerd. Het LSP zal derhalve het naamdomein voor de basisinfrastructuur beheren en een DNS-service bieden aan de aangesloten DCN’en. Om te kunnen voldoen aan de gedefinieerde “overall” serviceniveaus (zie 5.5.2), dienen ook voor het DCN serviceniveaus te worden geformuleerd voor delay en beschikbaarheid.

7.5.3 Identificeren en authenticeren Een zorgverlener kan transacties uitvoeren en informatie opvragen via de basisinfrastructuur indien zijn (elektronische) identiteit kan worden vastgesteld. Een hoger beveiligingsniveau stelt hogere eisen aan de zekerheid waarmee de elektronische identiteit correct kan worden bepaald. Indien een zorgverlener informatie wil inzien die niet in zijn eigen zorgsysteem is opgeslagen, kan hij deze via de basisinfrastructuur opvragen. In de basisinfrastructuur is een Zorg Informatie Makelaar (ZIM) aanwezig met een verwijsindex die bijhoudt in welk zorgsysteem deze informatie beschikbaar is. De ZIM zorgt ervoor dat de zorgverlener deze informatie ontvangt mits hij geautoriseerd is om deze te bekijken. Identificeren en authenticeren van systemen en zorgverleners vindt plaats op basis van certificaten die worden uitgegeven met behulp van een Public Key Infrastructuur (PKI). Voor een sluitende authenticatie is vereist dat tevens wordt vastgesteld dat degene die een certificaat overlegt, in het bezit is van de bijbehorende private key. Authenticatie op basis van SSL/TLS, dat is gebaseerd op een challenge-response mechanisme, voldoet aan deze vereisten. Aangezien het SSL/TLS protocol een bewezen technologie is die nog steeds voldoet, wordt de uitwerking van de authenticatie-methode hierop gebaseerd. Identificeren en authenticeren van systemen Zorgsystemen (GBZ’n) die informatie bevatten die door externe systemen (via het ZIM) worden bevraagd, zullen mee moeten kunnen werken aan het opzetten van een beveiligde verbinding. Aangezien dit zonder menselijke tussenkomst moet kunnen plaatsvinden, dient het GBZ zich te kunnen identificeren met een systeemcertificaat.


- 79 -

Alleen voor zeer gevoelige dossiers kan ervoor worden gekozen dat de gegevenshoudende zorgverlener expliciet toestemming geeft. Dit heeft dan wel als consequentie dat er een vertraging in de verzending optreedt tot na goedkeuring van de gegevenshoudende zorgverlener. Identificeren en authenticeren van zorgverleners Voor het identificeren en authenticeren van zorgverleners zijn diverse mogelijkheden beschikbaar. Hier worden besproken: o Het gebruik van biometrie; Biometrie is het gebruik van menselijke kenmerken, zoals gezichtsherkenning, vingerafdruk, handafdruk of irisherkenning voor de identificatie of verificatie van personen. Ook vormen van gedrag zoals lopen of schrijven kunnen gebruikt worden voor identificatie. Biometrische systemen bieden mogelijkheden om sneller en effectiever verificatie van identiteit of authenticiteit te realiseren. Technologisch hebben biometrische systemen de laatste jaren een aanzienlijke vooruitgang geboekt. Zowel ten aanzien van performance als eenvoud in gebruik en systeemintegratie. Het meest herkenbaar is dit zichtbaar in de vorm van vingerafdruksystemen, die men al ‘plug and play’ kan vinden in portabel computers, computermuizen of toegangscontrole systemen. Toch blijven de echte successen nog uit. De hoge verwachtingen worden kennelijk niet waargemaakt. Dit heeft vooral te maken met het feit dat de technologie (nog) niet volwassen is. De betrouwbaarheid van de systemen is onvoldoende om identificatie en authenticatie voor de zorg volledig op te baseren. Bovendien is er een gebrek aan standaarden. Dit betekent dat op dit moment naar andere methoden moet worden gezocht voor identificatie en authenticatie van zorgverleners. Biometrie kan wel aanvullend worden gebruikt om de betrouwbaarheid van deze methoden te verbeteren. o Een methode op basis van systeemcertificaten; Indien een zorgsysteem een systeemcertificaat bevat, kan deze een SSL/TLS verbinding opzetten met de ZIM onder eigen naam. Dat systeemcertificaat en de bijbehorende private key dienen dan op een veilige manier te zijn opgeslagen. De ZIM kan dan op basis van de authenticatie nagaan of een aanvraag komt van een vertrouwd zorgsysteem, maar niet nagaan wie een specifieke vraag stelt. Dit biedt geen mogelijkheid autorisatie op zorgverlenerniveau te ondersteunen. Het betekent dus dat alleen een generieke autorisatie voor alle gebruikers van het systeem met externe rechten kan worden gefaciliteerd. In deze situatie worden hoge eisen gesteld aan de toegangscontrole van de applicaties in het zorgsysteem en de procedures voor gebruik van deze applicaties. o Een methode op basis van persoonlijke certificaten. Indien aan de kant van de aanvragende zorgverlener sprake is van een enkelvoudig zorgsysteem voor één of meer zorgverleners kan deze vanaf zijn werkstation rechtstreeks een verbinding opzetten met een ZIM. Hierbij zal een normale Client-

- 80 -


Server SSL/TLS-sessie worden opgebouwd tussen de cliënt en server (ZIM), waarbij de zorgverlener zich kan authenticeren met zijn private authenticatiesleutel opgeslagen op zijn informatiesysteem (software certificaat) of op een zogenaamd hard token (“smart card”). Voor het hoogste beveiligingsniveau, waarbij ook een juridisch geldige elektronische handtekening moet kunnen worden gezet onder documenten, is opslag op een hard token vereist. Er zijn situaties denkbaar, bijvoorbeeld tijdens een migratieperiode, waarin tijdelijk wordt volstaan met een lager beveiligingsniveau. In dat geval zouden wellicht ook (persoonlijke) software certificaten kunnen worden toegepast. Het protocol SSL/TLS bevat functionaliteit voor authenticatie van de communicatiepartners. In het ontwerp van de basisinfrastructuur van de zorg is de Zorg Informatie Makelaar (ZIM) een gemeenschappelijke voorziening die informatie bevat waar zich gegevens over een bepaalde patiënt bevinden. De ZIM kan de aanvrager, nadat hij zich geauthenticeerd heeft met behulp van zijn certificaat, autoriseren tot toegang van deze gegevens. De zorgverlener is individueel verantwoordelijk voor misbruik van zijn persoonlijke UZIpas en zal deze voor toegang tot landelijke patiëntgegevens altijd bij zich moeten dragen. Het opzetten van een SSL-sessie voor het opvragen van patiëntinformatie door de zorgverlener dient altijd op basis van een challenge-response uitwisseling met de persoonlijke UZI-pas van die zorgverlener te geschieden. In veel gevallen maakt de aanvragende zorgverlener geen gebruik van een enkelvoudig systeem, maar wordt daar gebruik gemaakt van een diverse andere configuraties, zoals bijvoorbeeld client-server systemen. Indien de SSL-sessie met het LSP op basis van de UZI-pas niet wordt opgezet vanuit het (deel) systeem waarvan de zorgverlener gebruik maakt (en waarop de paslezer is aangesloten), maar vanuit andere systeemdelen dienen aanvullende maatregelen te worden genomen om de informatieoverdracht naar de eindgebruiker te beveiligen en misbruik van de identiteit van de aangesloten zorgverlener te voorkomen. De zorgaanbieder en/of zijn leverancier dienen in dat geval aan te kunnen tonen dat minimaal hetzelfde beveiligingsniveau en authenticatieniveau behaald kunnen worden als in situaties waarbij de SSL-sessie wel vanuit dat (deel) systeem plaatsvindt. Het gebruik van gefedereerde beveiligingsoplossingen Naast het afhandelen van communicatie tussen zorgsystemen via de gemeenschappelijke functie, kan het ook zinvol zijn rechtstreekse communicatie tussen zorgsystemen te ondersteunen. Om dan toch authenticatie en autorisatie vanuit de infrastructuur te kunnen bieden, dient een gefedereerde oplossing voor beveiliging beschikbaar te zijn, waarmee identiteiten en bevoegdheden kunnen worden doorgegeven. Er is recentelijk een (door OASIS) gestandaardiseerde oplossing beschikbaar gekomen om een dergelijke functionaliteit te implementeren: de Security Assertion Markup Language (SAML) [40].


- 81 -

Door de ZIM als autorisatie-autoriteit aan te merken en deze verklaringen over identiteit en bevoegdheden te laten afgeven aan de aangesloten zorgsystemen, kan ook de situatie worden ondersteund dat een dergelijk systeem na authenticatie en autorisatie door het ZIM gerechtigd wordt rechtstreeks bij andere zorgsystemen informatie op te vragen. Dit betekent dan wel dat systemen een dergelijke manier van communiceren moeten ondersteunen. Zolang dat niet het geval is, zal communicatie altijd via de ZIM moeten plaatsvinden, indien men gebruik wil maken van de generiek autorisatiefunctionaliteit van de ZIM. Introductie van deze functionaliteit wordt niet voorzien tijdens de opstartfase van de infrastructuur. Conclusie Identificatie en authenticatie van systemen en zorgverleners vindt plaats op basis van de functionaliteit van SSL/TLS, gebruik makend van certificaten die middels een PKI worden uitgegeven. Voorwaarden voor het gebruik van SSL/TLS zijn: o De zorgverlener moet een point-to-point verbinding met de ZIM kunnen opzetten o De zorgverlener en ZIM dienen de juiste actuele versie van het SSL v3.0 of TLS v1.0 protocol te gebruiken (hiermee wordt voorkomen dat misbruik gemaakt wordt van bekende kwetsbaarheden van oude versies). o De zorgverlener dient de juiste Client voor het opzetten van een SSL/TLS verbinding te gebruiken met de laatste patches. o De gebruikte certificaten dienen te voldoen aan X.509 versie 3. Bij configuraties waar de communicatie met de ZIM verloopt via een tussenliggend systeem, wordt ervan uitgegaan dat dit een vertrouwde server is. De voorwaarden voor een dergelijke aanname dienen te worden meegenomen in het acceptatieproces van het GBZ. Naast het afhandelen van communicatie tussen GBZ’n via de gemeenschappelijke functie, kan het ook zinvol zijn rechtstreekse communicatie tussen zorgsystemen te ondersteunen. Om dan toch authenticatie en autorisatie vanuit de infrastructuur te kunnen bieden, wordt voor een vervolgfase van de basisinfrastructuur ook ondersteuning voorzien van een gefedereerde beveiligingsoplossing op basis van SAML. Dit vereist dan wel een verdere aanpassing van de informatiesystemen van zorgverleners.

7.5.4 Integriteit en onweerlegbaarheid Binnen de basisinfrastructuur moet de integriteit van berichten en de onweerlegbaarheid van aanvragen kunnen worden gegarandeerd. Daarvoor zijn de volgende methoden in overweging genomen: 1. Het gebruik van adequate authenticatie van zorgverleners en een sluitend loggingsmechanisme voor alle informatieaanvragen en transacties die via de basisinfrastructuur plaatsvinden. Het behouden van de integriteit van berichten kan

- 82 -


worden gerealiseerd door gebruik te maken van de functionaliteit van SSL/TLS en TCP. 2. Het bewaken van de integriteit van een bericht en het realiseren van onweerlegbaarheid dat dit bericht door een bepaalde persoon is verzonden, door het zetten van een elektronische handtekening. Authenticatie en logging De zorgverlener (of zijn systeem) dient door de ZIM te worden geauthenticeerd bij het opzetten van een sessie. Onder de conditie dat het systeem van de zorgverlener een point-to-point verbinding met de ZIM kan opzetten is het mogelijk SSLv3.0 of TLSv1.0 toe te passen om een zorgverlener te authenticeren op basis van zijn private key en certificaat. Door voor iedere opgezette sessie alle informatievragen en transacties te loggen kan een audit trail worden gecreëerd, waarmee onweerlegbaar kan worden aangetoond dat berichten door een specifieke zorgverlener zijn verstuurd (en ontvangen). Het behouden van de integriteit van berichten kan worden gerealiseerd door gebruik te maken van de functionaliteit van SSL/TLS en TCP. Elektronische handtekening Het bewaken van de integriteit van een bericht en het realiseren van onweerlegbaarheid dat dit bericht door een bepaalde persoon is verzonden, kan ook worden gerealiseerd door het zetten van een elektronische handtekening. Door de procedure met de nodige zorgvuldigheid te omgeven21 kan de elektronische handtekening dezelfde juridische status krijgen als de zogenaamde “natte handtekening” onder een papieren document. Voor het koppelen van elektronische handtekeningen aan berichten zijn diverse gestandaardiseerde methodieken beschikbaar. Binnen ebMS is het mogelijk een elektronische handtekening te zetten. Hier staat de handtekening in de header. Voordeel van deze oplossing is dat ook eventuele andere attachments ondertekend kunnen worden. Ook binnen W3C is er Recommendation XML-Signature Syntax and Processing om een elektronische handtekening toe te voegen aan een XML-bericht [38]. In dat geval staat het in de XML payload. Dit biedt meer functionaliteit omdat selectief delen van een XMLdocument of zelfs externe resources van een handtekening kunnen worden voorzien. Door voor betrouwbare berichtoverdracht aan te sluiten bij de ontwikkelingen in WS-I ligt het voor de hand voor de methode van elektronische handtekening aan te sluiten bij de methodiek van W3C. Overigens moeten dan binnen dat kader nog nadere keuzen worden gemaakt t.a.v. de gebruikte algoritmen etc.

21

Dit houdt o.a. in dat hiervoor de (private) sleutel op een gepersonaliseerd “token”of smartcard wordt

geplaatst. Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 83 -

Conclusie De uiteindelijke doelstelling voor het garanderen van de integriteit van een bericht en het realiseren van onweerlegbaarheid dat dit bericht door een bepaald persoon is verzonden is het gebruik van de elektronische handtekening. Vooralsnog zullen veel applicaties deze vorm van beveiliging niet kunnen ondersteunen. De zekerheidsstructuur zal derhalve de integriteit van berichten in eerste instantie garanderen door gebruik te maken van de functionaliteit van SSL/TLS en TCP. Onweerlegbaarheid van aanvragen zal worden gegarandeerd door een adequate authenticatie van de zorgverleners en een sluitend loggingsmechanisme voor alle informatieaanvragen en transacties die via de basisinfrastructuur plaatsvinden.

7.5.5 Technische eisen PKI De volgende ontwerpkeuzen zijn gemaakt voor de inrichting van de PKI voor de zorg: o Voor het formaat en de publieke opslag van certificatie wordt aangesloten bij X.509 v3 en Certification Revocation List (CRL) versie 2. De specificatie voor gebruik in een Internet omgeving is vastgelegd in RFC 3280. Voor de zorgverlener-certificaten zijn in het kader van de proef met het UZI-register keuzen gemaakt voor gebruik van de velden [37]. o Voor uitgifte en gebruik van de certificaten wordt aangesloten bij de eisen van PKIoverheid. Dit betekent dat voor de uiteindelijk situatie van de zekerheidsstructuur wordt gestreefd naar het gebruik van 3 persoonsgebonden certificaten voor ieder van de toepassingen: o de elektronische handtekening o de elektronische identiteit o vertrouwelijke elektronische communicatie Deze persoonsgebonden certificaten en bijbehorende private sleutels zullen dan op een smartcard (ook wel “hard token” genoemd) komen te staan. Daarnaast is het ook mogelijk (software) systeemcertificaten te gebruiken. NICTIZ zal nog nader afwegen of het gebruik van drie afzonderlijke certificaten wel in alle gevallen van toepassing is. Voor de eerste applicaties wordt er van uitgegaan dat de zorgverlener wordt geauthenticeerd a.d.h.v. het desbetreffende certificaat voor de elektronische identiteit. o Opslag van private key en certificaat op een “hard token”; gestandaardiseerd volgens ISO 7816 en PKCS standaarden. Voor universele toepasbaarheid van de smartcard op iedere zorglocatie dienen aanvullende gedetailleerde eisen t.a.v. smartcard en kaartlezer te worden gesteld (Zie normen PKI-producten PKI-overheid). o Publicatie van certificaten vindt plaats in de LDAP-directory. De certificaten in de directory kunnen worden geraadpleegd via het LDAP-protocol, RFC 3377 Lightweight Directory Access Protocol (v3): Technical Specification. o De technische standaarden waaraan het UZI-register, de smartcard en de voorzieningen in het GBZ moeten voldoen staan beschreven in een apart document, uitgegeven door het CIBG [64].

- 84 -


7.6 Eisen aan beschikbaarheid, betrouwbaarheid en beveiliging van zorgsystemen (GBZ’n) 7.6.1 Inleiding Voor de systemen in de infrastructuur en de aangesloten systemen (GBZ’n) zullen de eisen aan beschikbaarheid, betrouwbaarheid en beveiliging moeten worden vastgesteld. Op basis van deze eisen kan dan acceptatie van deze systemen en hun beheeromgeving plaatsvinden. Het gaat hier om: o Procedurele eisen m.b.t. het beheer o Functionele eisen o Technische eisen

7.6.2 Generieke eisen voor alle typen GBZ’n Voor het inrichten van een GBZ gelden de algemene eisen van goed vakmanschap. Daarbij wordt verondersteld dat gebruik wordt gemaakt van bestaande normen zoals de Code voor Informatiebeveiliging [20][43] en de concept norm NEN 7510 (IBIZ) [19], met bijbehorende implementatierichtlijnen. Onder de algemene eisen van goed vakmanschap wordt in ieder geval verstaan: Inrichting informatiebeveiliging van instelling conform NEN 7510. Er dient een procedure voor toegang tot applicaties en gegevens te zijn ingericht, zodat de vertrouwelijkheid van gegevens kan worden gegarandeerd. Afhankelijk van het type applicatie en/of gegevens kan een zwaardere procedure noodzakelijk zijn. Voor toegang tot landelijke zorginhoudelijke gegevens moet gebruik worden gemaakt van door de UZI-pas. De technische standaarden hiervoor zijn geformuleerd in een rapport [64]. In de aanloopfase kan onder bepaalde voorwaarden en als tijdelijke voorziening gebruik worden gemaakt van useridentificatie/password in combinatie met UZI-systeemcertificaten in de basisinfrastructuur. Elke applicatie op een GBZ dient vast te leggen welke gegevens bij andere systemen/zorgverleners worden opgevraagd en welke gegevens aan andere systemen/zorgverleners worden geleverd (audit-trail of log). Per applicatie dient er een goede back-up procedure te zijn, waarbij regelmatig (dagelijks) back-ups worden gemaakt, waarbij een controle plaatsvindt op het resultaat van uitgevoerde back-ups en waarbij er een getoetste procedure is voor het terugzetten van back-ups. Een GBZ moet zijn geregistreerd bij het landelijk UZI-register en dient zich te identificeren met een door het UZI-register uitgereikt systeemcertificaat. Het controleren van de identiteit (authenticatie) vindt plaats met een gestandaardiseerde authenticatiemethode. Bij opslag van de bij dit certificaat behorende “private key” op de server dient gebruik te worden gemaakt van encryptie-technieken of externe Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 85 -

hardware-opslag. Gebruikers dienen geen toegang te hebben tot bestanden met (geëncrypte) sleutelinformatie. Een GBZ communiceert alleen met andere GBZ’n buiten de eigen instelling via de basisinfrastructuur. Daartoe sluit hij een contract af met een gecertificeerde Zorgserviceprovider (ZSP). Ook de basisinfrastructuur-componenten dienen zich te identificeren met een systeemcertificaat dat is uitgereikt door het UZI-register. Een GBZ beschouwt informatievragen die binnenkomen via componenten van de basisinfrastructuur als vertrouwd, waarbij er van kan worden uitgegaan dat informatievragen alleen worden doorgestuurd indien is voldaan aan de afgesproken generieke autorisatieregels. Een GBZ dient minimaal te voorzien in een toegangsverlening via persoonlijke useridentificatie/password-combinaties. Deze procedure dient te voldoen aan een aantal minimum eisen zoals minimale grootte van het password en regelmatig vernieuwen van het password. De beheerder dient er voor zorg te dragen dat het operating systeem van een GBZ zorgvuldig wordt ingericht, met recente security-patches, om te voorkomen dat het systeem gehackt en misbruikt kan worden. Servers, met name de file- en mailservers dienen door de verantwoordelijk beheerder te zijn voorzien van antivirusmaatregelen. Op het koppelvlak met de basisinfrastructuur voldoet het GBZ aan de volgende vereisten v.w.b. de invulling van de protocol stack: o Berichtuitwisseling op basis van HL7v3 o SOAP / WSDL o HTTP(S) / TCP / IP o WS-I Basic Profile Om kwaadwillenden van het netwerk te weren worden alle communicatieverbindingen van binnen naar buiten, en van buiten naar binnen, via een gecontroleerde toegang geleid. Bij koppeling aan het openbare Internet heeft deze gecontroleerde toegang een adequate firewall-functionaliteit, waarvan de filterregels door de eigen informatiemanager worden bepaald. Bij aansluiting op een VPN dient openbaar Internet-verkeer voor zover het niet via een gecontroleerde toegang binnenkomt op het externe netwerkaansluitpunt te worden afgestopt. Communicatie via het openbare Internet vindt geëncrypt plaats. Hierbij wordt gebruik gemaakt van een standaardmethode .

7.6.3 Specifieke eisen aan GBZ’n met gegevens die continu en direct beschikbaar moeten zijn In het kader van het e-medicatiedossier en e-waarneemdossier voor huisartsen moeten GBZ’n gegevens continu en direct beschikbaar hebben. De belangrijkste eisen voor dit type GBZ zijn:

- 86 -


Het GBZ slaat patiëntgegevens op op basis van het BSN van die patiënt. Een zorginstelling dient een procedure voor verificatie van de juistheid van het gebruikte BSN te hebben ingericht. Conform de richtlijnen van het Ministerie van VWS dient bij een zorgaanbieder ook een procedure te worden ingericht voor het vastleggen van aard en nummer van het WID. Het GBZ meldt beschikbare patiëntgegevens aan de verwijsindex in de Zorg Informatie Makelaar (ZIM) van het LSP. Het GBZ dient 24 uur per dag en 7 dagen per week beschikbaar te zijn voor het afhandelen van berichten. Beschikbaarheid: o Kleine storingen in een GBZ mogen maximaal 1 keer per maand voorkomen (MTBF) en dienen dan binnen 1 kwartier (MTTR) te zijn opgelost. o Grote storingen in een GBZ mogen maximaal 2 keer per jaar voorkomen (MTBF) en dienen dan binnen 1 dag (MTTR) te zijn opgelost. Dit leidt tot een beschikbaarheidpercentage van 99,4 %.

7.6.4 Specifieke eisen aan GBZ’n die niet continu en direct beschikbaar hoeven te zijn Dit geldt bijvoorbeeld voor GBZ’n die betrokken zijn bij de eerste fase van dienstverlening in de jeugdgezondheidszorg (JGZ). De belangrijkste eisen voor dit type GBZ zijn: Het GBZ slaat patiëntgegevens op op basis van het BSN van die patiënt. Een JGZinstelling dient een procedure voor verificatie van de juistheid van het gebruikte BSN te hebben ingericht. Conform de richtlijnen van het Ministerie van VWS dient bij een zorgaanbieder ook een procedure te worden ingericht voor het vastleggen van aard en nummer van het WID. Het GBZ meldt beschikbare patiëntgegevens aan de verwijsindex in de Zorg Informatie Makelaar (ZIM) van het LSP. Het GBZ dient op werkdagen van 8-18 uur beschikbaar te zijn voor het afhandelen van berichten. Beschikbaarheid: hiervoor zijn geen zware eisen noodzakelijk Responstijden op binnenkomende berichten. Gezien de tijdigheidseisen voor de eerste fasen van het e-kinddossier voor de jeugdgezondheidszorg (EKD) is er geen noodzaak voor korte reactietijden. Dossieroverdracht en uitwisseling van entberichten vereisen eigenlijk geen "real time" communicatie. Derhalve zijn reactietijden van 10-30 seconden acceptabel. Pas bij online inzage of bevraging van het dossier zijn strengere eisen nodig.

7.7 Invulling architectuurmodel Bovenstaande leidt tot de volgende invulling van het architectuurmodel.


- 87 -

Nieuw: MZD, EPD

Zorgtoepassingen

VWI

Authenticatie & Identificatie

Autorisatie

Infrastructurele toepassingen/ gemeenschappelijke basisfuncties

Intell. Routering

ZSP 1

Logging

ZSP2

Interoperabiliteit/ berichtcommunicatie

…..

Transport

Beveiliging, Continuïteit, Beheer

Bestaand: ZIS, HIS, AIS etc.

Figuur 7-6: Invulling technische architectuur

- 88 -


8

Aanpalende domeinen

8.1 Inleiding Naast de in dit document beschreven architectuur voor de landelijke basisinfrastructuur in de Zorg, zijn er diverse ontwikkelingen in en buiten de Zorg waarmee de architectuur van de basisinfrastructuur een relatie heeft of in de toekomst gaat hebben. In dit hoofdstuk worden de belangrijkste relaties met “aanpalende domeinen” aangegeven. Vooralsnog wordt hier vooral ingegaan op de relatie met de speciale voorzieningen voor e-Declareren, LCMR22 en het leggen van relaties met de architectuur voor gegevensuitwisseling tussen uitvoeringsinstanties. Om die relaties aan te geven wordt uitgegaan van het totaaloverzicht van de gemeenschappelijke voorzieningen zoals eerder aangegeven in Figuur 6-2.

CIBG

SBV-Z (BSN)


UZI register UZI UZI-pas

ICTU BV BSN BSN Vektis

LRD

Gemnet


DCN’en

GBA GBA GBA

Gemeenten

ZSP


Zorg Zorg Zorg aanbieder aanbieder verzekeraar Figuur 8-1: Totaaloverzicht gemeenschappelijke voorzieningen

8.2 e-Declareren Voor e-Declareren is het uitgangspunt om zoveel mogelijk aan te sluiten bij de AORTAreferentiearchitectuur voor de landelijke basisinfrastructuur in de zorg. Om echter per 11-2006 de doelstellingen van e-Declareren te kunnen halen, is het nodig geweest om op punten af te wijken van dit architectuurontwerp en aan te sluiten bij bestaande voorzieningen. Een voorbeeld hiervan is het gebruik van bestaande Externe Integratie 22

Landelijke Centrale (Opiumwet-) Middelen Registratie


- 89 -

(EI) standaarden voor declaratieverkeer. Op termijn is het doel om de architectuur voor e-Declareren te integreren met de AORTA-referentiearchitectuur. De totaalbeschrijving van het architectuurontwerp e-Declareren wordt gegeven in een separaat document: “Architectuurontwerp e-Declareren” [62]. In Figuur 8-2 wordt de relatie tussen de AORTA-architectuur en e-Declareren aangegeven. Voor e-Declareren wordt gebruik gemaakt van een specifiek declaratieportaal.

ICTU BV BSN BSN

SBV-Z (BSN)

CIBG

Vektis


UZI register UZI

AGB register AGB

DCN’en

UZI-pas

Declaratie Portaal

DCN’en

ZSP DCN’en



LRD

Gemnet

GBA GBA GBA

Gemeenten

Zorg Zorg Zorg aanbieder aanbieder verzekeraar

Declaratieketen Figuur 8-2: Relatie met e-Declareren

8.3 Landelijke Centrale (Opiumwet-)Middelen Registratie De hoofddoelstelling van de LCMR is om met behulp van een landelijk informatiesysteem zorgverleners van verschillende instellingen in verschillende sectoren, die vervangende middelen voorschrijven aan patiënten in het kader van een opiaatverslaving, te ondersteunen bij het bieden van een kwalitatief goede zorg (continuïteit van behandeling, voorkomen van overdosering of dubbeldosering). Daarnaast is het verkrijgen van geanonimiseerde beleidsinformatie een nevendoelstelling. Voor dit doel is een centrale verwijsindex ontwikkeld waarmee zorgverleners snel, betrouwbaar, 24 uur per dag en 7 dagen per week kunnen vaststellen of een patiënt bekend is, bij welke instelling(en) hij in behandeling is (geweest), wie de verantwoordelijke arts is (geweest), hoe deze bereikbaar is en wat de laatste doseringen zijn geweest die deze patiënt heeft ontvangen bij de betreffende verstrekker/instelling

- 90 -


(kwaliteitsverbetering zorg). Deze informatie is afkomstig uit verschillende lokale registratiesystemen (LRS) en wordt middels geautomatiseerd en beveiligd berichtenverkeer verzonden naar de LCMR. Alleen zorgverleners die via biometrie zijn geauthenticeerd krijgen toegang tot de LCMR. De LCMR-opzet is geschetst in Figuur 8-3.

IVZ LCMR Web interface DCN’en

Biometrie pas

LRSVerslaafdenzorg Verslaafdenzorg Verslaafdenzorg aanbieder aanbieder aanbieder

Patiënt / cliënt Figuur 8-3: Architectuur LCMR Koppeling van LCMR en AORTA zou tot wederzijdse voordelen van aangesloten populaties leiden: • LCMR-aangesloten zorgaanbieders kunnen, indien daartoe gerechtigd, beschikken over patiëntinformatie van andere artsen die wellicht nuttig of zelfs noodzakelijk is bij de behandeling van de cliënt. • Zorgverleners die zijn aangesloten op de basisinfrastructuur kunnen informatie verkrijgen over behandelend artsen en betrokken instellingen uit de verslavingszorg, alsmede recente verstrekkinginformatie. Over koppeling van beide domeinen heeft nog geen besluitvorming plaatsgevonden. Wel is een gezamenlijk eerste verkenning uitgevoerd over de mogelijkheden van koppeling. Voorlopige conclusies van deze verkenning zijn: • Koppeling kan plaatsvinden conform de interfacedefinitie voor aansluiting op de basisinfrastructuur AORTA. • Voor authenticatie zijn drie oplossingsrichtingen mogelijk:


- 91 -

Gebruik maken van de UZI-pas naast de biometrie pas. Dit is vanwege de omslachtigheid voor de zorgverlener geen goede methode o Gebruik van de biometriepas, ook voor bevraging van de basisinfrastructuur. Dit betekent dat de LCMR als een trusted peer-systeem wordt gezien en dat voor het LSP op deze interface een afwijkende methodiek van authenticatie moet worden geïmplementeerd. o Gebruik van een gecombineerde UZI-/biometrie-pas. Dit maakt het mogelijk de voordelen van beide systemen te combineren. De basis van de identificatie is het landelijk UZI-register, terwijl er door de biometrie een extra beveiligingsniveau wordt toegevoegd. Alleen de eigenaar van de pas kan deze activeren. Uitlenen van de pas en gebruik door derden wordt hiermee onmogelijk gemaakt. Indien te realiseren heeft de laatste mogelijkheid de voorkeur. Dit biedt meerwaarde op gebied van beveiliging en vraagt weinig aanpassing van het LSP. o

Bij een dergelijke methode van koppeling kan opvraag en levering van aanvullende patiëntinformatie aan LCMR-aangeslotenen uit de AORTA-omgeving worden gerealiseerd zoals aangegeven in Figuur 8-4.

CIBG

SBV-Z (BSN)

NICTIZ

Landelijk Schakel Punt ZIM

UZI register UZI

IVZ

1 2

DCN’en

UZI-pas

DCN’en

ZSP


LCMR Web interface

Opvraag door (1) en levering aan (2) LCMR-aangeslotenen van patiëntgegevens

Biometrie pas


Patiënt / cliënt

Figuur 8-4: Bevraging van zorgsystemen in de basisinfrastructuur vanuit LCMR

Een methode voor het beschikbaar maken van de LCMR-gegevens aan zorgverleners die zijn aangesloten op de basisinfrastructuur kan als volgt worden gerealiseerd. De LCMR

- 92 -


dient de gegevens aan te melden bij de ZIM van het Landelijk Schakelpunt. In dat geval kunnen deze gegevens op de standaardmanier beschikbaar worden gemaakt aan alle zorgverleners die daartoe zijn gerechtigd. Opgemerkt wordt dat in deze opzet alleen de landelijke geregistreerde gegevens beschikbaar worden gesteld en dat Lokale Registratie Systemen niet individueel op de basisinfrastructuur hoeven te worden aangesloten. Een ander nog nader uit te werken punt is onder wiens verantwoordelijkheid aanmelding van LCMR-gegevens dient plaats te vinden. De huidige specificaties gaan uit van aanmelding m.b.v. authenticatie van de zorgverlener (d.m.v. de persoonlijke UZI-pas). Het principe van aanmelding van gegevens bij de LCMR is echter anders ingericht, zodat dit niet eenvoudig is te realiseren. Een alternatief zou kunnen zijn om het LCMR onder eigen “verantwoordelijkheid” te laten aanmelden wat daar is opgeslagen.

CIBG

SBV-Z (BSN)

NICTIZ

Landelijk Schakel Punt ZIM

UZI register UZI UZI-pas


s n ven e d el ege nm R g a A M LC 1 IVZ

2 3

DCN’en

LCMR Web interface DCN’en

ZSP Opvraag aan (2) en levering uit (3) LCMR

Biometrie pas


Patiënt / cliënt Figuur 8-5: Bevraging van het LCMR vanuit de basisinfrastructuur

8.4 Patiëntenportaal In de architectuur van de basisinfrastructuur is voorzien dat de patiënt (op termijn) in staat is op elektronische wijze toegang te krijgen tot informatie die op hem betrekking heeft en zelf autorisaties in te stellen om zo te bepalen wie wel of geen toegang heeft tot zijn gegevens. Hiertoe zal een portaal worden ingericht, waarschijnlijk te combineren met Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 93 -

het generieke overheidsportaal voor de zorg (Kiesbeter.nl). Deze situatie is weergegeven in Figuur 8-6. Voor een dergelijk toegang moet de elektronische identiteit van de patiënt zijn geregeld, bijvoorbeeld door gebruik te maken van de eNIK. Deze functionaliteit wordt niet voorzien voor de aanvangsfase van de basisinfrastructuur.

NICTIZ Landelijk Schakel Punt ZIM DCN’en

ZSP Zorg Zorg Zorg XIS aanbieder aanbieder aanbieder

Zorg Zorg Zorg aanbieder aanbieder verzekeraar

Patiëntenportaal Patiënten portal (Kiesbeter.nl ?)

e-NIK ?

Patiënt / cliënt Figuur 8-6: Toegang voor de patiënt

8.5 Relatie met architectuur gegevensuitwisseling Uitvoeringsinstanties sociale zekerheid In de sociale zekerheid is al enige jaren een infrastructuur beschikbaar voor de informatie-uitwisseling tussen de uitvoeringsinstanties. Deze is gebaseerd op berichtuitwisseling via RINIS (Routerings Instituut (inter)Nationale Informatiestromen). Stichting RINIS is een samenwerkingsorganisatie van grote Nederlandse publieke uitvoerders, die partijen ondersteunt bij alle aspecten rond de uitwisseling van gegevens ten behoeve van de uitvoering van publieke taken. Naast het organiseren van de

- 94 -


gegevensuitwisseling via gestandaardiseerde berichten is RINIS een overlegplatform waarin partijen met elkaar afspraken maken over gegevensuitwisseling. Gegevensuitwisseling via RINIS vindt plaats via sectorale aanspreekpunten die in staat zijn om vragen en antwoorden door te sturen van en naar de achterliggende organisaties. Dit wordt gerealiseerd door gebruikmaking van zelfstandig werkende computers waarmee alléén vooraf gespecificeerde berichten kunnen worden uitgewisseld. Deze RINIS-servers zorgen voor veilige uitwisseling van berichten. Hierdoor is efficiënt en effectief hergebruik van éénmalig vastgelegde gegevens mogelijk.

LRD Gemnet

Gemeenten


GBA GBA GBA

Manifest

DCN’en

SVB

Declaratie Portaal

DCN’en


DCN’en

ZSP

Vektis Zorg Zorg Zorg aanbieder aanbieder verzekeraar

Declaratieketen

Sectoraal Aanspreek Punt

Belasting dienst SoFi

SAP RINIS

Belasting Overheid dienst Transact Poort OTP

UWV

etc.

CBS

etc.

Figuur 8-7: Relatie met architectuur gegevensuitwisseling uitvoeringsinstanties sociale zekerheid


- 95 -

9

Literatuur [1] [2] [3]

[4] [5] [6]

[7]

[8] [9] [10] [11] [12] [13] [14] [15]

[16] [17] [18]

- 96 -

IEEE Std 1471:2000; Recommended Practice for of Architectural Description of Software-Intensive Systems Documenten Verwijsindex, ABZ Branche Initiatieven, Februari 2002. Architectuurschets voor de ontwikkeling van nieuwe Huisarts Informatie Systemen, een verkennende studie in opdracht van VIZI, Cap Gemini Ernst en Young, 24 juni 2002. Inventarisatie gebruik Medeur in Huisarts Informatie Systemen, A.E. Vlug, EUR, 15 juni 2000. Masterplan Ontwikkeling Event-Based Bedrijfs- en ICT-Architectuur GGZinstellingen, B. de Moes en R. Sponselee, 28 mei 2002. Virtueel EPD, een virtueel dossier op basis van CorbaMed, H. v.d. Linden, G. Boers, H. Tange, Medische Informatica, Universiteit Maastricht, 11 oktober 2001. E-Health in zicht, Advies uitgebracht door de Raad voor de Volksgezondheid en Zorg aan de Minister van Volksgezondheid, Welzijn en Sport, Zoetermeer 2002. Ontwikkelingen rond internationale standaarden en de NICTIZ infrastructuur en infostructuur, versie 1.0, TNO-rapport, G. Freriks, 24 oktober 2002. Roadmap Berichtenverkeer; toekomstverwachtingen, stand van zaken en handreiking voor verandering, CSIZ versie 1.0, maart 2001. Requirements for Integration Brokers in Healthcare, Gartner September 2001. Nederlands Zorg Architectuur Model NZAM, Presentatie L. Vollebregt, HCON/OIZ, September 2002. Picnic, professionals and citizens network for integrated care, Interim System Architecture for PICNIC, September 2002. Computer Networks 4th edition, Andrew S. Tanenbaum. Prentice Hall 2002. Privacy-wetgeving en het omgaan met patiëntgegevens, KNMG Handleiding voor artsen, Utrecht, november 2001. RICHTLIJN 99/93 EG betreffende een gemeenschappelijk kader voor elektronische handtekeningen van het Europees parlement en de raad van de Europese Unie. Wet Bescherming Persoonsgegevens (WBP), wet van 6 juli 2000, houdende regels inzake de bescherming van persoonsgegevens. Wet Geneeskundige BehandelOvereenkomst (WGBO), wet van 17 november 1994. Wet Beroepen in de individuele Gezondheidszorg (Wet BIG), wet van 9 november 1993, houdende regels voor zorgverlening door beroepsbeoefenaren.


[19] Norm voor informatiebeveiliging in de zorg, normontwerp voor Nederlandse Norm NEN 7510, deze norm wordt in het project IBIZ (Informatie Beveiliging en Implementatie in de Zorg) ontwikkeld. [20] Britse standaard BS 7799 Part 1:1999 en ISO 17799:2000. [21] ISO/CD TS 17090-1 t/m 3:2002; met name gericht op PKI. [22] ICT in de Nederlandse Zorg, Visie 2000-2005, L.P. Vollebregt M.Sc. [23] prEN 13606-1 t/m 5:2005, de concept norm voor Electronic Health Record Communication). [24] prENV 12967-1 t/m 3: 2002, de concept norm voor Healthcare Information Systems Architecture (HISA). [25] Diverse technische standaarden: • OMG CORBA & Healthcare Domain Task Force; • Java Community Process: J2EE; • W3C: XML, SOAP; • EbXML; • IETF: SSL/TLS; • ITU-T: X.509. [26] Definitiestudie voor het Unieke Zorgverleners Identificatieregister (UZIregister), CIBG in opdracht van IPZorg. [27] PKI Overheid, Programma van Eisen, versie 3 definitief, mei 2002. Zie http://www.pkioverheid.nl/. [28] PKI Overheid, Leidraad Certificaatprofielen, versie 1.0, januari 2003. [29] RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Revocation List (CRL) Profile, april 2002. Zie http://www.ietf.org/rfc/rfc3280.txt?number=3280. [30] RFC 3039, Internet X.509 Public Key Infrastructure Qualified Certificates Profile, april 2002. Zie http://www.ietf.org/rfc/rfc3039.txt?number=3039. [31] PKIX, Public-Key Infrastructure. Zie www.ietf.org/html.charters/pkixcharter.html. [32] Peter Gutmann, X.509 Style Guide, October 2000. Zie http://www.cs.auckland.ac.nz/~pgut001/ [33] OID assignments from the top node. Zie http://www.alvestrand.no/objectid/top.html. [34] Richtlijn 1999/93/EG van het Europees Parlement en de Raad van 13 december 1999 betreffende een gemeenschappelijk kader voor elektronische handtekeningen. [35] ISO/CD TS 17090-1 t/m 3:2002; met name gericht op PKI; [36] ENV 13608-1 t/m 3: Beveiliging van communicatie in de gezondheidszorg; o Deel 1: Concepten en terminologie (NVN-ENV 13608-1:2000); o Deel 2: Beveiligde gegevenselementen (NVN-ENV 13608-2:2000); o Deel 3: Kanalen voor beveiligde gegevens (NVN-ENV 13608-3:2000); Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2

- 97 -

[37] CA-model, Pasmodel, Certificaat en CRL-profielen Landelijk operationeel UZI-register (productieomgeving), agentschap CIBG, versie 1.2, 23 december 2004. [38] XML-Signature Syntax and Processing, W3C Recommendation 12 February 2002. Zie: http://www.w3c.org/TR/xmldsig-core/ [39] RFC 2246, The TLS Protocol, Version 1.0, januari 1999. Zie http://www.ietf.org/rfc/rfc2246.txt?number=2246 [40] Assertions and Protocol for the OASIS, Security Assertion Markup Language (SAML) V1.1. OASIS Standard, 2 September 2003. [41] Functionele beveiligingseisen van het informatie-uitwisselingsproces. Taskforce Aanpak wachtlijsten, werkgroep beveiliging, Opgesteld op verzoek van het Project AWBZ-brede Zorgregistratie, 2e concept, 2 maart 2002. [42] NVN-ENV 12924:1997, ICS 35.240.70, NEN; Voornorm Medische informatica – Indeling van beveiliging en bescherming van informatiesystemen in de gezondheidszorg. [43] Code voor informatiebeveiliging: 2000. Een leidraad voor beleid en implementatie (SPE 20003, ICS 35.020,NEN) [44] Beveiliging van persoonsgegevens, Achtergrondstudies en verkenningen nummer 23 van G.W. van Blarkom en drs. J.J. Borking, Registratiekamer, april 2001. ISBN 90 74087 27 2, http://www.cbpweb.nl/downloads_av/AV23.PDF [45] Richtlijnen inzake het omgaan met medische gegevens (het ‘Groene Boekje’), Vademecum Richtlijnen 06, KNMG, http://knmg.artsennet.nl/index.asp?a=22963&s=322&p=1 [46] Web Services Security: SOAP Message Security, http://www.oasisopen.org/committees/download.php/3281/WSS-SOAPMessageSecurity-17082703-merged.pdf [47] Web Services Security: Username Token Profile, http://www.oasisopen.org/committees/download.php/3154/WSS-Username-04-081103merged.pdf [48] Web Services Security: X.509 Token Profile, http://www.oasisopen.org/committees/download.php/3214/WSS-X509 draft 10.pdf [49] XML Encryption Syntax and Processing, W3C Recommendation 10 December 2002, http://www.w3.org/TR/xmlenc-core/ [50] Architectuur Elektronische Overheid, samenhang en samenwerking F. van den Dool, W.Keller, R. Wagenaar, J.A.F. Hinfelaar Ministerie van BZK, November 2002 [51] Werken met architectuurmodellen, nut en noodzaak bij ICT innovaties binnen de publieke sector, A. Lassance, P. de Kam en R.W. Wagenaar Research Note, HEC en TU Delft, mei 2003

- 98 -


[52] DYA: snelheid en samenhang in business en ICT architectuur R.Wagter, M. van den Berg, J. Luijpers, M. van Steenbergen, IQUIP, 2001 [53] Model Driven Architecture, MDA Guide Version 1.0 OMG, June 2003 [54] Certificate Policy voor het UZI-register tijdens de begeleide start, CIBG, januari 2003 [55] ISO DTS 22600: Privilege Management en Access Control (PMAC). [56] Wetenschappelijk Instituut van de Nederlandse Apothekers(WINAP): H.J.M. Beijer and C.J. de Blaey. Pharm World Sci 2002; 24(2):46-54. Hospitalisations caused by adverse drug reactions (ADR): a meta-analysis of observational studies [57] Effects of computerized physician order entry and clinical decision support systems on medication safety: a systematic review, Arch Intern Med. 2003 June 23;163(12):1409-16 [58] NIPO Rapport: Fouten worden duur betaald, een onderzoek naar medische overdrachtsfouten. B5561|februari 2004 [59] Brancherapporten Ministerie van VWS (zie www.brancherapporten.minvws.nl) [60] Cijfers van Stichting Farmaceutische Kentallen (zie http://www.sfk.nl/) [61] TOGAF, the Open Group Architecture Framework, Version 8.1 “Enterprise edition”, 19 december 2003. [62] Architectuurontwerp e-declareren, versie 1.1., februari 2005, NICTIZ [63] IHE IT Infrastructure Technical Framework Supplement 2004-2005 CrossEnterprise Document Sharing (XDS), Trial Implementation Version. [64] Toegepaste Standaarden Landelijk Operationeel UZI-register, agentschap CIBG, versie 1.0, 12 januari 2005. [65] Overdracht van patiëntendossiers na ontstentenis van de arts zonder opvolging, Mr. D.Y.A. van Meersbergen, Dr. T.J.A.M. Meerman, KNMG 2005. [66] Van wet naar praktijk. Implementatie van de WGBO, Deel 4 Toegang tot patiëntengegevens. Uitgave van het Samenwerkingsverband Implementatieprogramma WGBO, Eindredactie J.M. Witmer en R.P. de Roode. Utrecht, juni 2004. ISBN 90-71994-34-1 [67] Handboek invoering en gebruik BSN in de zorg voor Koplopers, Ministerie van VWS, Versie 2.0, Datum: 21 oktober 2005 [68] Onderzoek Invulling Vierde Domein, Versie 4.0, 22 september 2004, Vektis KOVD-008, Wiecher Huisman


- 99 -

A

Afkortingenlijst

-

AIS BIG BSN BVBSN CBP COAS COV DCN DSS EPD - EVS

: : : : : : : : : : :

Apotheker InformatieSysteem Beroepen Individuele Gezondheidszorg Burger Service Nummer BeheerVoorziening BSN College Bescherming Persoonsgegevens Clinical Observation Access Service Controle op Verzekering Data Communicatie Netwerk Decision Support Service Elektronisch Patiënten Dossier Elektronisch Voorschrijf Systeem).

-

: : : : : : : : : : : : : : : : : : : : : : : : : : : :

Goed Beheerd Zorgsysteem Geneeskundige Hulpverlening bij Ongevallen en Rampen HuisArtsenPost Huisartsen Onder Eén Dak Huisarts Informatiesysteem Informatie Beveiliging in de Zorg International Classification of Diseases International Classification of Primary Care Integrating the Healthcare Enterprise Internet Inter-ORB Protocol International Standards Organisation Java 2 Enterprise Edition Java Community Process Landelijk SchakelPunt Landelijk Medicatie Dossier Lexicon Query Service Mean Time Between Failures Mean Time To Repair Object Management Group Object Request Broker Open Systems Interconnection Personal Identification System Public Key Infrastructure Regionaal Indicatie Orgaan Regionaal Instituut voor Ambulante Geestelijke Gezondheidszorg Sectorale Berichten Voorziening voor de Zorg Simple Object Access Protocol SOAP With Attachments

GBZ GHOR HAP HOED HIS IBIZ ICD ICPC IHE IIOP ISO J2EE JCP LSP LMD LQS MTBF MTTR OMG ORB OSI-model PIDS PKI RIO RIAGG SBV-Z SOAP SWA

- 100 4.2

Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e

-

TLS TTP UZI UZOVI VDZ VPN VWI WBP WCIA WGBO WID XIS XML ZIM ZIS

: : : : : : : : : : : : : : :

Transport Layer Security Trusted Third Party Unieke Zorgverleners Identificatie Unieke Zorgverzekeraars Identificatie Vierde Domein in de Zorg Virtual Private Network Verwijsindex Wet Bescherming Persoonsgegevens Werkgroep Coördinatie Informatisering en Automatisering Wet op de Geneeskundige Behandelingsovereenkomst Wettelijk IDentiteitsbewijs Verzamelnaam voor HIS, ZIS, AIS etc. eXtensible Mark-up Language Zorg Informatie Makelaar Ziekenhuis InformatieSysteem

Architectuurontwerp Basis Infrastructuur in de Zorg v e r s i e 4 . 2 -

- 101

B

Internationale ervaringen

Hoewel op veel plaatsen wordt nagedacht over het verbeteren van efficiëntie en effectiviteit in de zorg door inzet van ICT is er internationaal nog weinig concrete ervaring met grootschalige opzet voor een EPD. Ook zijn er niet veel landen die een expliciete architectuurvisie op nationaal niveau hebben vastgesteld. De stand van zaken in de landen die hierin voorop lopen is hieronder weergegeven. NICTIZ houdt wat dat betreft de internationale ontwikkelingen intensief in de gaten en heeft daartoe regelmatig contact met zusterorganisaties in andere landen. In Israël is het eerste wereldwijd echt grootschalige EPD operationeel sinds 2002 [17]. Het is gebaseerd op een decentrale oplossing. Bij deze oplossing worden de gegevens uit de lokale zorgsystemen en applicaties van een aangesloten instelling gerepliceerd naar een lokale Clinical Data Repositor (CDR). De data in deze CDR wordt toegankelijk gemaakt door een (gedistribueerde) verwijsindex. Het Israëlische Rabin Medical Center is samen met twaalf regionale ziekenhuizen aangesloten op één gemeenschappelijk (virtueel) EPD. Alle medische gegevens van 3,7 miljoen patiënten zijn met een minimale responstijd vanaf elke willekeurige werkplek in te zien door 12.000 actieve zorgverleners. De medische gegevens omvatten röntgenfoto's en radiologische beelden uit verschillende ziekenhuizen, testresultaten uit verschillende laboratoria en recepten van verschillende apothekers [8]. In Duitsland is een voorstel gelanceerd door een aantal expertgroepen van vier industrieorganisaties. Daarin wordt voorgesteld (een deel van) de patiëntinformatie op een smart card te zetten. Daarnaast wordt een telematica infrastructuur voorgesteld, die mede gebruikt kan worden voor het laden van de smart card. De aanwezige – wellicht aan te passen – applicaties in de vorm van HIS’en, ZIS’en, AIS’en, Laboratoriumsystemen en andere informatiesystemen zullen via die telematica infrastructuur gaan communiceren. Voor het toegankelijk maken van de informatie in deze systemen zijn centrale Verwijs- of Directorydiensten noodzakelijk. Bovendien wordt een centraal concept voor het vaststellen van de rol en bijbehorende autorisatie voorgesteld. In de UK is de zeer gecentraliseerde NHS-organisatie gestart met het realiseren van een Integrated Care Records Service. In de specificatie van de te leveren diensten wordt de beoogde architectuurinvulling beschreven. In eerste instantie kiest men voor een landelijk centrale opslag van “patient extracts” in gemeenschappelijke databases op nationaal niveau, de zogenaamde Data Spine [11]. Men voorziet daarbij echter tevens voorzieningen om meer informatie dan alleen de “patient abstracts” beschikbaar te kunnen gaan maken. Met een verwijsindex wordt daarom ook flexibiliteit geboden wordt om diverse vormen van opslag van data, ook decentraal, te ondersteunen.

- 102 4.2


Door de centrale dataopslag in de “data spine” kan aan zeer hoge performance eisen worden voldaan: beschikbaarheid van 99,99% en een application response tijd van gemiddeld 0,5 seconde en een maximum response tijd van 3 seconden. Daar moeten echter hoge kosten voor worden gemaakt: de Engelse overheid heeft $3,9 miljard toegezegd voor een driejarig programma. Voor de daarop volgende periode van 7 jaar wordt verwacht dat nog eens $ 13 miljard nodig is voor additionele contracten en een uitbreiding van het IT-budget voor de NHS. Denemarken heeft een zeer goed ontwikkelde zorg infrastructuur, waarover een veelheid van EDI-berichten worden uitgewisseld. Denemarken gaat uit van de PICNIC benadering, waarbij diverse gebruikersgroepen gebruik maken van veilige en op hun gebruik toegesneden toegang en gemeenschappelijk gebruik van informatie die is opgeslagen in geografisch gedistribueerde autonome informatie systemen. De infrastructuur dient er op te zijn ingericht communicatie tussen de autonome systemen mogelijk te maken, informatie te kunnen lokaliseren en gebruikers en patiënten te kunnen identificeren en zonodig te autoriseren [4], [5], [9]. Australië zit nog in een planfase voor de realisatie van een basis infrastructuur voor de Zorg, genaamd HealthConnect. De voorgestelde architectuur gaat uit van, bij voorkeur regionaal georganiseerde, HealthConnect Records Systems (HRS), die de EPD opslag en access services voor een gedefinieerde groep gebruikers regelen. Zorgverleners sturen een professionele samenvatting, na goedkeuring door de patiënt, naar deze HRS. Ook informatie-uitwisseling tussen zorgverleners zoals verwijzingen, ontslagbrieven etc., wordt automatisch opgeslagen in het HRS. Iedere HRS bedient een deel van de bevolking. Alle professionele samenvattingen van een bepaalde patiënt worden op één en hetzelfde HRS opgeslagen [11], [12], [13]. Performance eisen die worden gesteld voor real time bevraging: de gebruiker dient een pagina binnen 20 seconden na het verzenden van een verzoek te kunnen bekijken. De 20 seconden limiet geldt voor iedere pagina die wordt bekeken. Canada heeft recentelijk in een intensieve afstemmingsronde met heel veel stakeholders een EHRS (EHR Solution) Blueprint gedefinieerd. Aangezien Canada regionaal is georganiseerd is de architectuur gebaseerd op het aanbieden van een aantal gemeenschappelijke services die diverse vormen van opslag in de regio’s ondersteunt en een aantal registers (registries) om patiënten, zorgverleners en instellingen uniek te identificeren en de rechten (security rules) ervan vast te stellen. De EHR bevat summary level informatie over zorg “encounters” voor iedere patiënt en vaak ook de gedetailleerde klinische data die is gerepliceerd vanaf de point of service zorgapplicatie [15]. Voor het


- 103

koppelen van de verschillende geografische domeinen is een Verwijsindex voorzien (EHRS Locator). De kosten voor het ontwikkelen van de basis elementen van een dergelijk infrastructuur zullen naar schatting $2,5 miljard bedragen [16]23. In Finland hebben industrie en zorgverleners gekozen voor een berichtgeoriënteerde integratiearchitectuur voor regionale en nationale communicatie. Daarbij wordt gebruik gemaakt van de HL7 berichtenstandaard. In de toekomst verwacht men gebruik te maken van XML berichten. Voor het toegankelijk maken van patiëntinformatie voor andere zorgverleners gaat men uit van virtueel patiëntendossiers, dat toegankelijk wordt gemaakt met een verwijsindex [18], [19]. Literatuur voor Bijlage B: [1]. Einführung einer Telematik-Architektur im deutschen Gesundheitswesen, Expertise BITKOM, VDAP, VhitG, ZVEI, Juni 2003 [2]. Smart card and the electronic health record, NHS Bradford Health Authority, March 2001 [3]. Connecting health; a review of electronic health record projects in Australia, Europe and Canada, Amanda Cornwall, November 2002 [4]. PICNIC, Deleverable 6.3 Access to Patient Data Component Specifications, 11 March 2002. [5]. PICNIC, Deliverable D 2.3 Interim System Architecture for PICNIC, 8 May 2002 [6]. Wet Bescherming Persoonsgegevens (WBP), wet van 6 juli 2000, houdende regels inzake de bescherming van persoonsgegevens. [7]. Wet Geneeskundige BehandelOvereenkomst (WGBO), wet van 17 november 1994. [8]. Management info, maart 2003, http://www.management-info.nl/gezond03/art07.htm [9]. MedComIV Status, plans and projects, MedCom – the Danish Healthcare Data Network / Dec. 2003 / MC-S177 [10]. Delivering 21st Century IT, Support for the NHS National Specification for Integrated Care Records Service, Consultation Draft, Version: 1.22, 26 July 2002 [11]. Integrated Care Records Service, Introduction to the Output Based Specification, Department of Health, UK, Version 2, August 2003 [12]. HealthConnect Draft Systems Architecture, July 2003 [13]. HealthConnect Architecture Overview, HealthConnect Program Office, July 2003 [14]. Draft HealthConnect Business Architecture, HealthConnect Program Office, March 2002 [15]. EHRS Blueprint, an interoperable HER framework, Version 1.0, Canada Health Infoway Inc., July 2003 [16]. Canada Health Infoways, FAQ’s, Electronic Health Record Solution Blueprint,

23

Canada heeft 30 miljoen inwoners.

- 104 4.2


July 31, 2003 [17]. Grootschalig EPD in Israel is uniek in de wereld, Automatiseringsgids 5 juli 2002. [18]. Utillisation of ICT in Finnish Health Care, Ministry of Social Affairs and Health, 2001 [19]. Satakunta Macro Pilot, http://www.makropilotti.fi/english/, 2003


- 105

C

Consultatieproces

In de afgelopen twee jaar heeft een uitgebreide consultatie van het architectuurdocument plaatsgevonden met een veelheid van partijen in en buiten het zorgveld: • Individuele gesprekken met industriële partijen (meer dan 20); o.a. Microbais, Pharmapartners, Ness, CGEY, KPMG, Uzorg, Torex HISCOM, McKesson, Lifeline, Pink Roccade, Chipsoft, Ordina, HP, EuroNed. • OIZ-plenair en de OIZ-infrastructuurgroep in diverse samenstellingen zowel mondeling als schriftelijk. • Universiteiten (Rotterdam, Maastricht, Leiden). • Academische ziekenhuizen; er heeft een tweetal workshops over het architectuur van de basisinfrastructuur plaatsgevonden. • Algemene ziekenhuizen; er is een workshopcyclus met algemene ziekenhuizen georganiseerd. • NEN. • Verzekeraars (ZN, Vektis, Vecozo). • Zorgringen. • Stichting OZIS. • Consultaties CIBG m.b.t. UZI-register.

- 106 4.2


ARCHITECTUURONTWERP BASISINFRASTRUCTUUR IN DE ZORG

Recommend Documents