SPECIFICATIE VAN DE BASISINFRASTRUCTUUR IN DE ZORG files/M32/Doc/basisinfrastructuur.pdf · 5.7.3...

SPECIFICATIE VAN DEBASISINFRASTRUCTUUR

IN DE ZORG

- Versie 2.4 -

postad res: Po stbus 262, 2260 AG Le i dschendambezo ekad res: Ov ergoo 11, 2266 JZ Le i ds chendam

tel efoo n: (070) 317 34 50; f ax: (070) 320 74 37; e -mai l : i n [email protected] .n l

Status : DefinitiefDatum : 11 augustus 2006

mailto:[email protected]

http://www.NICTIZ.nl

Specificatie van de basisinfrastructuur in de zorg - i –

Managementsamenvatting

Voor een doeltreffende, doelmatige en veilige communicatie in de zorg, is een landelijkebasisinfrastructuur noodzakelijk. Deze moet mogelijk maken dat in principe alle partijenin de zorg met elkaar kunnen communiceren: patiënten/cliënten, zorgaanbieders enzorgverzekeraars. Een van de voorwaarden is een veilige opslag en uitwisseling vankritische zorginformatie, zoals persoonsgebonden medische gegevens. Daarnaast dientde toegang tot deze patiëntgegevens te worden geregeld door middel van een sluitendconcept van identificatie, authenticatie, autorisatie en versleuteling.

Centraal in de basisinfrastructuur staat de Zorg Informatie Makelaar (ZIM), die wordtgeëxploiteerd door het Landelijk Schakelpunt (LSP). Daarop kunnen zorgaanbieders hunbestaande zorginformatiesystemen (ook wel XIS´en genoemd) aansluiten, mits zijvoldoen aan de eisen van het Goed Beheerde Zorgsysteem (GBZ). Die aansluiting vindtplaats via bestaande en nieuwe Data Communicatie Netwerken (DCN), die wordengeëxploiteerd door Zorg Service Providers (ZSP).

Voor het uniek identificeren van patiënten, zorgaanbieders, zorgverzekeraars enzorgsystemen wordt gebruik gemaakt van landelijke registers: het UZI–register (UniekeZorgverleners Identificatie), de SBV-Z (Sectorale BerichtenVoorziening in de Zorg vanhet BSN-stelsel) en het UZOVI-register (Uniek Zorgverzekeraars Identificatie).

Het concept van de Zorg Informatie Makelaar heeft het uitgangspunt datpatiëntgegevens bij de bron blijven, dus bij de verantwoordelijke zorgaanbieder. Ditbetekent dat eisen moeten worden gesteld aan onder meer de beschikbaarheid,beveiliging en actualiteit van het Goed Beheerde Zorgsysteem.

Bij de ontwikkeling van deze concepten is zoveel mogelijk uitgegaan van het belang vande patiënt/cliënt. Tevens is rekening gehouden met het wettelijke kader van onder meerde Wet op de geneeskundige behandelingsovereenkomst (WGBO) en de WetBescherming Persoonsgegevens (WBP).

Wanneer een Goed Beheerd Zorgsysteem wordt aangesloten op de basisinfrastructuur,kan een zorgaanbieder de volgende generieke functies gebruiken:

• het opvragen van een overzicht dat aangeeft waar landelijk welke soortenpatiëntgegevens liggen opgeslagen en beschikbaar zijn voor opvraag;

• het opvragen van specifieke patiëntgegevens uit individuele patiëntdossiers vande verschillende zorgaanbieders;

- ii - Specificatie van de basisinfrastructuur in de zorg

• het versturen van opdrachten (medicatievoorschriften, labaanvragen, etc) naarandere zorgaanbieders;

• het vanuit de zorgaanbiedergids (ZG) opzoeken van zorgaanbieders op basis vande aangeboden zorgdiensten, locatie en/of naam.

De Zorg Informatie Makelaar biedt daartoe de volgende functionaliteit:

• een schakelfunctie (SCH) om berichten op veilige en betrouwbare wijze terouteren naar de juiste bestemming;

• een verwijsindex (VWI) om op doelmatige wijze inzicht te geven waar landelijkoveral gegevens van een patiënt liggen opgeslagen;

• een autorisatiefunctie (AUT) om ervoor te zorgen dat zorgaanbieders alleen díepatiëntgegevens kunnen inzien waarvoor zij gerechtigd zijn op grond van hunfunctie en de wensen van de patiënt/cliënt;

• een identificatie- & authenticatiefunctie (I&A) om te voorkomen dat onbevoegdendie zich voordoen als geautoriseerde zorgaanbieder, toegang kunnen krijgen totpatiëntgegevens;

• een loggingfunctie (LOG) om achteraf te kunnen nagaan welke patiëntgegevenseen zorgaanbieder heeft ingezien.

De onderstaande figuur toont de samenhang tussen de genoemde systemen:

Specificatie van de basisinfrastructuur in de zorg - iii –

ZSP

ziekenhuis ziekenhuis

ZSP

apoth’khuisarts apoth’k

CIBG

huisarts

LSP

SBVUZI

ZIM

AISHISAISHIS

Vektis

UZOVI

LISRISZISLISRISZIS

verzek’r

ZVIS

verzek’r

ZVIS

ZG

DCN DCN

ZIMVWI

AUT

I&A

LOGSCH

Dit document “Specificatie van de basisinfrastructuur in de zorg” beschrijft de totalewerking van de basisinfrastructuur, op het niveau van bedrijfsprocessen,informatiesystemen en technologie. Daarnaast specificeert dit document de eisen diegesteld worden aan de verschillende onderdelen van de basisinfrastructuur en de GoedBeheerde Zorgsystemen.

De huidige versie van dit document is primair gericht op de speerpunten van NICTIZ, hete-medicatiedossier en e-waarneemdossier voor huisartsen, maar is zodanig generiekopgezet dat de basisinfrastructuur ook andere zorgtoepassingen kan ondersteunen. Despeerpunt e-declareren wordt beschreven in een apart document. Niettemin beschrijft ditdocument verscheidene toekomstige functies, opdat ontwikkelaars daarmee rekeningkunnen houden.

Dit document is een uitwerking van het document “Architectuurontwerpbasisinfrastructuur in de zorg” en vormt zelf de basis voor een aantal HL7-implementatie-handleidingen (zie pagina 13).Tot slot bevat het ontwerp een grote mate van flexibiliteit, zodat afhankelijk vantoekomstige ontwikkelingen meerdere richtingen ingeslagen kunnen worden. Deverschillende migratiescenario’s worden later in separate documenten gepubliceerd.

- iv - Specificatie van de basisinfrastructuur in de zorg

Inhoudsopgave

1 Inleiding 10

1.1 Doel van dit document 10

1.2 Achtergrond van dit document 10

1.3 Doelgroep van dit document 11

1.4 Reikwijdte van dit document 11

1.5 Structuur van dit document 12

1.6 Relatie met andere documenten 13

1.7 Status van dit document 14

2 Uitgangspunten 16

2.1 Normatieve referenties 16

2.2 Informatieve referenties 17

2.3 Afkortingen 19

2.4 Begrippen 24

3 Bedrijfsarchitectuur 28

3.1 Zorgpartijen 28

3.1.1 Patiënt/cliënt 29

3.1.2 Zorgaanbieder 29

3.1.3 Zorgverlener 29

3.1.4 Zorginstelling 32

3.1.5 Zorgverzekeraar 33

3.1.6 Afbakening 33

3.2 Diensten 34

3.2.1 Zorgdiensten 35

3.2.2 Logistieke diensten 35

3.2.3 Financiële diensten 35

3.2.4 Sturende diensten 36

3.3 Relaties 37

3.3.1 Wetten, normen en andere uitgangspunten 37

3.3.2 Zorgrelatie 37

3.3.3 Samenwerkingsrelatie 40

3.4 Vastleggen van patiëntgegevens 42


3.4.2 Patiëntgegevens voortkomend uit zorgrelatie 43

3.4.3 Structuur van patiëntgegevens 46

3.4.4 Patiëntgegevens voortkomend uit samenwerkingsrelatie 49

3.4.5 Samenhang tussen patiëntgegevens 51

3.5 Beheren van patiëntgegevens 53


3.5.2 Afhandelen van patiëntgegevens 55

Specificatie van de basisinfrastructuur in de zorg - v –

3.5.3 Bijhouden van het patiëntdossier 57

3.5.4 Patiëntgegevens gezien vanuit patiënt/cliënt 60

3.6 Uitwisselen van patiëntgegevens 61


3.6.2 Opvragen van patiëntgegevens 63

3.6.3 Versturen van patiëntgegevens 66

3.7 Beschermen van patiëntgegevens 69


3.7.2 Autoriseren van zorgaanbieders 72

3.7.3 Loggen van toegang 78

3.7.4 Delegeren aan medewerkers 82

3.8 Bereiken van zorgpartijen en patiëntgegevens 85


3.8.2 Identificeren van patiënten/cliënten 87

3.8.3 Identificeren van zorgaanbieders 90

3.8.4 Adresseren van dossier en postbus 93

3.9 Vertrouwen van zorgpartijen en patiëntgegevens 95


3.9.2 Vertrouwen in zorgpartijen, dossiers en postbussen 96

3.9.3 Vertrouwen van beheerde patiëntgegevens 99

3.9.4 Vertrouwen van opgevraagde patiëntgegevens 100

3.9.5 Vertrouwen van verstuurde patiëntgegevens 101

3.9.6 Vertrouwensniveaus 102

3.10 Beheer 105


3.10.2 Dienstenmodel 106

3.10.3 Organisatiemodel 108

4 Informatiesysteemarchitectuur 112

4.1 Applicaties 112

4.1.1 Zorgaanbieder-applicaties 113

4.1.2 Patiënt/cliënt-applicaties 115

4.1.3 Beheerderapplicaties 117

4.2 Gebruiksscenario’s 118

4.2.1 Aan/afsluiten zorgaanbiederapplicatie m.b.t. schakelpunt 121

4.2.2 In-/uitloggen gebruiker 123

4.2.3 Selecteren patiënt/cliënt 126

4.2.4 Selecteren zorgaanbieder 133

4.2.5 Bijhouden Patiëntgegevens 137

4.2.6 Publiceren Patiëntgegevens 139

4.2.7 Abonneren Patiëntgegevens 144

4.2.8 Initieel koppelen Patiëntgegevens 145

4.2.9 Opvragen Patiëntgegevens 149

- vi - Specificatie van de basisinfrastructuur in de zorg

4.2.10 Versturen Patiëntgegevens 156

4.2.11 Overdragen patiëntgegevens 161

4.2.12 Beheren autorisatieprotocol 164

4.2.13 Bijhouden autorisatieprofiel 168

4.2.14 Raadplegen toegangslog 173

4.2.15 Bijhouden mandateringen 178

4.2.16 Beheren zorgaanbiederapplicatie 181

4.2.17 Beheren schakelpunt 183

4.2.18 Beheren patiëntenregister 190

4.2.19 Beheren zorgaanbiederregister 190

4.2.20 Beheren zorgaanbiedergids 190

4.3 Objecten 191

4.3.1 Patiëntdossier 192

4.3.2 Schakelpunt 196

4.3.3 Verwijsindex 200

4.3.4 Gegevenssoortentabel 203

4.3.5 Autorisatieprotocol 204

4.3.6 Autorisatieprofiel 206

4.3.7 Identificatie & authenticatie-module 208

4.3.8 Toegangslog 209

4.3.9 Mandateringstabel 215

4.3.10 Patiëntenregister 216

4.3.11 Zorgaanbiederregister 218

4.3.12 Zorgaanbiedergids 220

4.3.13 Configuratietabellen 222

4.4 Interacties 225

4.4.1 Aan-/afsluiten applicatie op schakelpunt 225

4.4.2 In/uitloggen gebruiker 227

4.4.3 Selecteren patiënt/cliënt 228

4.4.4 Selecteren zorgaanbieder 229

4.4.5 Opvragen patiëntgegevens 230

4.4.6 Abonneren patiëntgegevens 231

4.4.7 Publiceren patiëntgegevens 232

4.4.8 Versturen patiëntbericht 233

5 Technische Architectuur 234

5.1 Strategie 234

5.2 ICT-voorzieningen 235

5.2.1 Sectorale BerichtenVoorziening 235

5.2.2 UZI-register 235

5.2.3 Zorgaanbiedergids 236

5.2.4 UZOVI-register 236

5.2.5 Zorg Informatie Makelaar 236

Specificatie van de basisinfrastructuur in de zorg - vii –

5.2.6 RouteerFunctie 237

5.2.7 DataCommunicatieNetwerken 238

5.2.8 Goed Beheerd Zorgsysteem 238

5.2.9 Samenhang tussen ICT-voorzieningen 241

5.3 Berichtuitwisseling 243

5.3.1 Overzicht van gebruikersinteracties 243

5.3.2 Indirect opvragen 250

5.3.3 Indirect versturen 254

5.4 Transportprotocollen 256



5.5 Connectiviteit 262

5.5.1 IP-koppeling tussen GBZ en ZIM 262

5.5.2 Aansluiting van applicatie op schakelpunt 264

5.5.3 IP-koppeling tussen GBZ’en 265

5.5.4 IP-koppeling tussen GBZ en CA’s 266

5.6 Beveiliging 268

5.6.1 Inleiding 268

5.6.2 Beveiliging tussen GBZ-gebruikers en ZIM 272

5.6.3 Beveiliging tussen GBZ-dossiers/postbussen en ZIM 276

5.6.4 Beveiliging tussen GBZ-applicatie en ZIM 279

5.6.5 Beveiliging tussen registers en ZIM 280

5.6.6 Interne beveiliging GBZ 281

5.6.7 Interne beveiliging ZIM 282

5.7 Beschikbaarheid 283

5.7.1 Beschikbaarheid van een GBZ 283

5.7.2 Beschikbaarheid van de ZIM 284

5.7.3 Beschikbaarheid van een DCN 286

5.7.4 Beschikbaarheidstoestanden 287

5.7.5 Samenvatting 289

5.8 Capaciteit en schaalbaarheid 290

5.9 Responstijden 293



5.10 Betrouwbaarheid 297

5.10.1 Generieke foutsituaties 299



5.10.4 Identificatie van berichten en patiëntstukken 308

6 Eisen aan een Goed Beheerd Zorgsysteem (GBZ) 311

6.1 Definitie van GBZ 311

6.2 Gebruikersfuncties 312

- viii - Specificatie van de basisinfrastructuur in de zorg

6.3 Berichtuitwisseling als gevolg van gebruikersfuncties 312

6.4 Berichtuitwisseling t.b.v. andere zorgaanbieders 316

6.5 Autorisatie 320

6.6 Toegangslog 320


6.8 Beveiliging 323



6.11 Capaciteit 329


6.13 Actualiteit 330

6.14 Ondersteuning 330

7 Eisen aan een Zorg Informatie Makelaar (ZIM) 332

7.1 Definitie van de ZIM 332

7.2 Verwijs- & routeringsfuncties 333

7.3 Autorisatiebeheer 340

7.4 Toegangslogbeheer 340

7.5 Klantenondersteuning 340

7.6 Systeembeheer 341

7.7 Test/acceptatie-beheer 341

7.8 Applicatiebeheer 342

7.9 Aansturing en verantwoording 344


7.11 Beveiliging 349



7.14 Capaciteit 354

7.15 Schaalbaarheid 354


8 Eisen aan een Data Communicatie Netwerk (DCN) 357

8.1 Definitie van DCN 357


8.3 DNS-diensten 359

8.4 Beveiliging 359


8.6 Responsetijden 360

8.7 Beheer 360

Specificatie van de basisinfrastructuur in de zorg - ix –

Bijlagen

A Invoering burgerservicenummer 363

B Ongeadresseerde medicatievoorschriften 373

C Bundelen, groeperen, doseren en sorteren 377

D Adresseren 389

E Kolommen in de verwijsindex 399

F Overzicht van zekerheidsaspecten 401

- 10 – Specificatie van de basisinfrastructuur in de zorg

1 Inleiding

1.1 Doel van dit document

Dit document is een architectuuruitwerking van de beoogde basisinfrastructuur inde zorg. Deze basisinfrastructuur omvat de gemeenschappelijke ICT-voorzieningendie nodig zijn om de individuele ICT-voorzieningen van verschillende zorgpartijen(zorgaanbieders, zorgverzekeraars, etc.) onderling te kunnen koppelen. Daarnaastomvat de basisinfrastructuur ook de organisatorische voorzieningen om op juridischen economisch verantwoorde wijze te kunnen functioneren. Dezebasisinfrastructuur is noodzakelijk, opdat de vele, verschillende, specifieke ICT-applicaties in de zorg (zorgapplicaties) onderling op doeltreffende, betrouwbare enrendabele wijze informatie kunnen uitwisselen.

Dit document gaat aldus in op:• de eisen aan de basisinfrastructuur (verwijsindex, autorisatieprotocol, etc.),• de eisen aan de individuele ICT-voorzieningen (HIS, ZIS, etc.),• de wijze waarop de individuele ICT-voorzieningen met de basisinfrastructuur

dienen te communiceren.

Dit document is geschreven in het kader van het TEIN-project, onderdeel van hetAORTA-programma van NICTIZ.

1.2 Achtergrond van dit document

NICTIZ richt zich op de totstandkoming van een betere informatievoorzieningrondom en voor de patiënt/cliënt met behulp van ICT, met als doel de kwaliteit endoelmatigheid van de zorg te verhogen. NICTIZ heeft twee programmalijnen:AORTA en Zorgtoepassingen.

Het AORTA-programma richt zich op de realisatie van een toekomstvaste, landelijkebasisinfrastructuur in de zorg die regionaal en landelijk implementeerbaar, juridischen economisch levensvatbaar is. Dit programma omvat projecten op het gebiedvan:

• de technische infrastructuur,• generieke nummers en autorisatie,• het economische bedrijfsmodel,• implementatie in het veld.

Het programma Zorgtoepassingen richt zich op de ontwikkeling van berichten voorde uitwisseling van informatie tussen de vele zorgtoepassingen. Dit programmaomvat projecten voor verschillende zorgtoepassingen: medicatie, perinatologie, etc.Dit werkterrein, vroeger infostructuur en Koppeling Zorgtoepassingen genoemd,omvat de standaardisatie van de specifieke zorginhoudelijke informatie perzorgtoepassing, terwijl de infrastructuur zich richt op generieke voorzieningen.

NICTIZ werkt in deze programma’s nauw samen met (vertegenwoordigers van) deverschillende belanghebbers bij ICT in de zorg: patiëntenverenigingen, medischeberoepsverenigingen, zorgaanbieders, zorgverzekeraars, ICT-leveranciers, etc.Daarbij richt NICTIZ zich op de ontwikkeling van standaarden voor elektronischeinformatie-uitwisseling in de zorg. De ontwikkeling van ICT-voorzieningen conform

Specificatie van de basisinfrastructuur in de zorg - 11 –

deze standaarden, is nadrukkelijk geen taak voor NICTIZ, maar voor de ICT-leveranciers.

1.3 Doelgroep van dit document

Dit document is bedoeld voor partijen die zich bezighouden met de ontwikkelingvan ICT-toepassingen in de zorg, zoals ontwikkelaars, leveranciers, onderzoekers,etc. De lezer wordt verondersteld een ICT-achtergrond en enige kennis van UML enHL7v3 te hebben. Voor een goed begrip van dit document is het ook raadzaameerst het document “Architectuurontwerp Basisinfrastructuur in de Zorg” te lezen,aangezien dit document daarop gebaseerd is. Voor geïnteresseerden zonder dezevoorkennis brengt NICTIZ publicaties uit over specifieke kwesties die in ditdocument aan de orde komen.

1.4 Reikwijdte van dit document

Omdat het toepassingsgebied van ICT in de zorg zeer groot is, richt het AORTA-programma zich in eerste instantie op het landelijke elektronische patiëntdossier,m.a.w. de uitwisseling van patiëntgegevens tussen zorginstellingen. In latereinstantie zal de uitwisseling van informatie met zorgverzekeraars en anderezorgpartijen worden uitgewerkt. Naar verwachting zijn de meeste principes,ontwerpbeslissingen en oplossingen in dit document ook toepasbaar voor dezorgverzekeraars.

Dit document richt zich voornamelijk op de eisen voor de basisinfrastructuur, dusde gemeenschappelijke ICT-voorzieningen en het beheer daarvan, en bemoeit zichniet onnodig met de gang van zaken binnen zorginstellingen of de functionaliteitvan hun ICT-voorzieningen. Toch is het onvermijdelijk ook eisen te stellen aan deindividuele ICT-voorzieningen binnen zorginstellingen en het beheer daarvan.Daarbij gaat het zowel om technische eisen, inzake de wijze waarop zorgsystemendienen te communiceren met de basisinfrastructuur, als om organisatorische eisen,inzake het daadwerkelijke gebruik en beheer van die zorgsystemen. Als aan dieeisen wordt voldaan, krijgt de individuele ICT-voorziening binnen de zorginstellinghet predikaat Goed Beheerd Zorgsysteem (GBZ).

Daarnaast beperkt dit document zich tot de generieke functionaliteit die debasisinfrastructuur biedt aan de vele verschillende zorgtoepassingen: faciliteitenvoor het uitwisselen van patiëntgegevens tussen zorginformatiesystemen. In hetdocument worden generieke berichten gedefinieerd, ter ondersteuning van despecifieke berichten voor de verschillende, bestaande en toekomstigezorgtoepassingen. De invulling van deze specifieke berichten is het werkterrein vanhet programma Zorgtoepassingen. Toch worden deze specifieke berichten in ditdocument in generieke zin meegenomen, om duidelijk te maken hoe debasisinfrastructuur deze afhandelt. De generieke functionaliteit omvat verder deverwijs-, de identificatie-, authenticatie-, autorisatie- en loggingfuncties, en wordtondergebracht bij de Zorg Informatie Makelaar (ZIM).

De huidige versie van dit document is primair gericht op de speerpunten vanNICTIZ: het e-medicatiedossier (EMD) en e-waarneemdossier voor huisartsen(WDH). Het speerpunt e-declareren wordt beschreven in een apart document.

Tenslotte richt dit document zich vooral op de gewenste, toekomstige situatie vanICT in de zorg. Voorlopig heeft de zorgsector te maken met zeer verschillende,

- 12 - Specificatie van de basisinfrastructuur in de zorg

gesloten zorginformatiesystemen, die op één of andere manier moeten kunnenworden aangesloten op de basisinfrastructuur. Derhalve dient de basisinfrastructuurflexibel genoeg te zijn om bestaande zorginformatiesystemen te accommoderen énmee te buigen met toekomstige ontwikkelingen.

1.5 Structuur van dit document

Dit document begint met een overkoepelende architectuuruitwerking van degewenste situatie van ICT-voorzieningen in de zorg. Daarvoor is zoveel mogelijkgebruik gemaakt van UML als modelleertechniek. Als raamwerk is gekozen voor eendriedeling die in de meest gangbare architectuurraamwerken terugkomt. Conformdeze driedeling is de volgende hoofdstukindeling gebruikt:

• Hoofdstuk 3: bedrijfsarchitectuur (applicatie-onafhankelijk model)• Hoofdstuk 4: informatiesysteemarchitectuur (technologie-onafhankelijk

model)• Hoofdstuk 5: technische architectuur (technologie-specifiek model)

Bedrijfsarchitectuur

Informatiesysteemarchitectuur

Technischearchitectuur

MedicatieToek.

zorgtoe-passingen

Technische infrastructuur

Autorisatie Economisch model

GeneriekeNummers

Waar-neming

huisartsen

Declaratieverkeer

De bovenstaande naamgeving is ontleend aan TOGAF. Zij die het architectuur-raamwerk RM-ODP gewend zijn, kunnen de verschillende gezichtspunten als volgtterugvinden:

• Enterprise Viewpoint: paragraaf 3.1 t/m 3.3• Informational Viewpoint: paragraaf 3.4 t/m 3.10• Computational Viewpoint: paragraaf 4.1 t/m 4.3• Engineering Viewpoint: paragraaf 4.4 t/m 4.5 en paragraaf 5.3• Technological Viewpoint: hoofdstuk 5, behalve paragraaf 5.3.

De bovengenoemde hoofdstukken zijn een uitwerking van het document“Architectuurontwerp Basisinfrastructuur in de Zorg”, waarin op hoofdlijnen debelangrijke ontwerpbeslissingen zijn gemaakt. In paragraaf 2.1 van dit documentworden de ontwerpbeslissingen kort genoemd. Om te komen tot een specificatievan de uiteindelijke ICT-voorzieningen, zijn daarnaast nog enkele anderebelangrijke ontwerpbeslissingen gemaakt. Deze ontwerpbeslissingen zijn steedsgemarkeerd met [Bx] waarbij x een volgnummer is.

Op basis van de overkoepelende architectuuruitwerking in de hoofdstukken 3, 4 en5, is een vertaling gemaakt naar concrete eisen die worden gesteld aan deverschillende ICT-voorzieningen in de zorg, en de concrete wijze waarop dezeonderling communiceren. Deze zijn ondergebracht in de volgende hoofdstukken:

• Hoofdstuk 6 specificeert de eisen die worden gesteld aan een GBZ,• Hoofdstuk 7 specificeert de eisen die worden gesteld aan een ZIM,• Hoofdstuk 8 specificeert de eisen die worden gesteld aan een DCN.


1.6 Relatie met andere documenten

De onderstaande figuur toont de relatie van dit document met andere documentenvan NICTIZ, waarbij de pijlen wijzen naar het afgeleide document:

• deze “Specificatie van de basisinfrastructuur in de zorg, versie 2.4” isgebaseerd op het “Architectuurontwerp basisinfrastructuur in de zorg, versie4.2”,

• diverse HL7-implementatiehandleidingen (zie hieronder) zijn medegebaseerd op versie 2.4 van dit document,

• het “Programma van eisen en wensen van het LSP”, versie 1.0 wasgebaseerd op een vorige versie 2.2 van dit document,

• het “Programma van eisen voor een GBZ”, versie 1.1, is gebaseerd op versie2.4 van dit document,

• het “Kwalificeringsschema Zorg Service Providers, versie 1.1 voorreferentieomgeving”is mede gebaseerd op deze versie 2.4 van dit document.

SpecificatieBasisinfra Zorg

Architectuurontwerp

Basisinfra Zorg

Programmavan eisen

LSP

Programmavan eisen

GBZ

Kwalificeringsschema

ZSP

HL7implementatiehandleidingen

HandboekICT

leveranciers

De HL7-implementatiehandleidingen betreffen de volgende documenten:• [HL7v3 Infra] “Implementatiehandleiding HL7v3 Infrastructurele domeinen”,• [HL7v3 ZIM] “Implementatiehandleiding HL7v3 Zorg Informatie Makelaar”,• [HL7v3 EMD] “Implementatiehandleiding HL7v3 Medicatieberichten”,• [HL7v3 WDH] “Implementatiehandleiding HL7v3 Gegevensuitwisseling

huisartsen”,• [HL7v3 WSP] “Implementatiehandleiding HL7v3 Web Services Profile”.

Omdat dit document meer functionaliteit beschrijft dan concreet kan wordengerealiseerd met de beschikbare HL7v3-standaard, zijn de functies die nog nietkunnen worden gerealiseerd met het etiket {toekomst} gemerkt.

De programma’s van eisen vormen de basis voor de verwerving van deverschillende ICT-voorzieningen. Het programma van eisen voor het LSP wordt doormiddel van een gefaseerde aanbesteding vormgegeven. Dit betekent dat defuncties in dit document niet allemaal tegelijkertijd worden gerealiseerd. Dit


document houdt daarmee geen rekening en richt zich zoveel mogelijk op degewenste eindsituatie.

1.7 Status van dit document

Deze “Specificatie van de Basisinfrastructuur in de Zorg” is tot stand gekomen opbasis van:

• uitwerking van het Archtitectuurontwerp basisinfrastructuur in de zorg,• bestudering van internationale literatuur over ICT in de zorg,• discussies met diverse partijen die zich bezighouden met ICT in de zorg.

Deze versie 2.4 wordt uitgebracht i.v.m. de afronding van de Proof of Concept ende daaropvolgende Pilot. . Deze versie 2.4 wijkt af van versie 2.3.1 op de volgendepunten:

• AORTA-wijziging #3: sommige gebruiksscenario’s vereisen inloggen metUZI-pas maar hebben geen interactie met de ZIM tot gevolg, zodat ersprake is van lokaal inloggen, zie paragraaf 5.6.1.

• AORTA-wijziging #5: GBZ moet ZIM-certificaat controleren tegen CRL, zieparagraaf 5.5 en 7.11.

• AORTA-wijziging #6: de tabel in Bijlage A.7 klopte voorheen niet met deeisen in paragraaf 4.2.5, 4.2.6, 4.2.9.

• AORTA-wijziging #8: wijziging in de WGBO dat de bewaartermijn vanpatiëntgegevens van 10 naar 15 jaar is verlengd, zie paragraaf 3.6.1.

• AORTA-wijziging #10: wanneer een zorgverlener een nieuw patiëntstukheeft vastgelegd in zijn dossier maar deze vervolgens herroept (ongeldigmaakt), moet deze automatisch afgeschermd worden, zie paragraaf 4.2.6.

• AORTA-wijziging #11: de ZIM moet voor één opvraag iedere applicatieslechts éénmaal bevragen, ook als die applicaties toevallig meerdere kerenin de verwijsindex staan, zie paragraaf 4.3.2 en 7.2.

• AORTA-wijziging #14: verduidelijking dat foutmelding 10 en 11 niet deprivacy van de patiënt bedreigen, zie paragraaf 4.2.9.

• AORTA-wijziging #15: in een vervolgopvraag (HL7 query continuation) moetgeen StartResultNumber en geen ContinuationQuantity worden gebruikt, zieparagraaf 5.3, 7.2 en bijlage C.3.

• AORTA-wijziging #16: correctie van een verwijzing, zie paragraaf 7.2.• AORTA-wijziging #19: logging van berichtinhoud wordt niet van GBZ geëist

zolang de taken en bevoegdheden van de toezichthouder niet bekend zijn,zie paragraaf 4.3.8 en 6.6.

• AORTA-wijziging #21: de structuur van de toegangslogverduidelijken,verbeteren en in lijn brengen met het Functioneel Ontwerpvan de ZIM, zie paragraaf 4.3.8, 5.3.1 en 5.3.2.

• AORTA-wijziging #23: ten onrechte werd gesuggereerd dat een GBZ bijmandateren moet toelaten dat de URA van de mandaterende zorgverlenervrij kan worden gekozen, zie paragraaf 4.2.15.

• AORTA-wijziging #24: nieuwe eis: een GBZ moet altijd via één IP-adres(volgens #44 dus hostnaam) naar buiten communiceren, zie paragraaf5.5.1, 5.6.6 en 6.7.

• AORTA-wijziging #25: verduidelijken dat de applicatie-id per zorgaanbiederuniek moet zijn, belangrijk voor een ASP, zie paragraaf 5.5.1, 5.5.2, 5.6.6,6.7 en 7.10.

• AORTA-wijziging #27: voor opvragen BSN is UZI-pas niet noodzakelijk maaris authenticatie op instellingniveau met UZI-servicescertificaat voldoende, dit


komt neer op het reeds gedefinieerde vertrouwensniveau laag, zie paragraaf5.6.1, 5.6.4, 6.7, 6.8, 7.2, 7.10 en 7.11.

• AORTA-wijziging #32: verduidelijken waarom de zorgverlener en niet hetGBZ wordt geauthenticeerd, zie paragraaf 5.6.2.

• AORTA-wijziging #33: eisen dat een GBZ onmogelijk maakt dat eenmalafide applicatie vanaf een onveilige client als GBZ-applicatie allerleiberichten met de ZIM kan uitwisselen, zie paragraaf 5.6.6 en 6.8.

• AORTA-wijziging #36: toevoegen GBZ-eis dat landelijke unieke patiëntstuk-id’s worden gebruikt, zie paragraaf 6.12. Dit was wel reeds beschreven inparagraaf 5.10.4.

• AORTA-wijziging #39: paragraaf 6.8 moet verwijzen naar paragraaf 4.3.13voor de waarden van de tijdsparameters.

• AORTA-wijziging #44: GBZ’en moeten voortaan hostnamen (domein-nnamen) gebruiken, zie paragraaf 4.2.16, 4.2.17, 5.5.1, 6.10 en 8.4.

• AORTA-wijziging #102: zorgaanbiedernaam is voorlopig vrij te kiezen, inafwachting van zorgaanbiedergids, zie paragraaf 4.2.9, 4.2.16, 4.2.17.

• AORTA-wijziging #111: een indicatie van de beschikbaarheid moet etiket{toekomst} krijgen, zie paragraaf 4.2.9.

• AORTA-wijziging #112: de zorgaanbiederidentiteit kan op verschillendemanieren worden gepresenteerd, zie paragraaf 4.2.9.

• AORTA-wijziging #117: verduidelijken dat het verwijderen van logregels nietmag, behalve bij einde bewaartermijn, zie paragraaf 4.2.14.

• AORTA-wijziging #131: correctie dat ontvangende systeem op eenduplicaatbericht altijd antwoord moet sturen als de afzender dat verwacht,zie paragraaf 5.10.4, 6.12 en 7.16.

• AORTA-wijziging #134: correctie dat gebruiker niet de vrije keuze heeft omeen klaarstaande aanmelding te negeren, zie paragraaf 4.2.6.

• AORTA-wijziging #145: diefstal van duplicaatberichten voorkomen, zieparagraaf 5.10.4, 6.12 en 7.16.

• AORTA-wijziging #154: de gegevenssoort ligt besloten in de gebruikers-interactie en hoeft niet steeds apart genoemd te worden in het autorisatie-protocol, toegangslog en mandateringstabel, zie paragraaf 4.2.12, 4.2.14,4.2.15, 4.3.5, 4.3.8, 4.3.9. Eigenlijk is dit een vereenvoudiging, want deoude eisen dwongen tot het uitsplitsen van de gebruikersinteracties tot 2dimensies gegevenssoort en interactietype, wat voor WDH niet mogelijkblijkt. Nu kan men volstaan met gebruikersinteractie en dit begrip is mededaarom beter gedefinieerd, zie paragraaf 5.3.1.

• diverse aanscherpingen en verduidelijkingen, mede op grond van kwestiesopgevoerd tijdens de Proof of Concept door deelnemende XIS-leveranciers.

Deze versie 2.4 wordt compleet geacht voor de Proof of Concept met het beoogdelandelijke e-medicatiedossier (EMD) en e-waarneemdossier (WDH) voor huisartsen.

Op www.nictiz.nl kan worden gecontroleerd of deze versie nog steeds de meestactuele versie is.

Het is de bedoeling dat dit document uiteindelijk bijdraagt aan een norm voorinformatie-uitwisseling in de Nederlandse zorgsector.

http://www.nictiz.nl


2 Uitgangspunten

Dit hoofdstuk is bedoeld voor lezers die precies willen weten op welkeuitgangsdocumenten het gedachtegoed in dit document is gebaseerd. Andere lezerskunnen dit hoofdstuk overslaan en beginnen in Hoofdstuk 3, en alleen voor degebruikte afkortingen en begrippen even terugslaan naar dit hoofdstuk.

2.1 Normatieve referenties

De onderstaande documenten zijn beschouwd als leidend voor dit document:

[Masterplan] “Masterplan Nationaal ICT Instituut in de Zorg” april 2002, NICTIZ.

[Actieplan] “Actieplan 2003 en programma naar 2005”, september 2002, NICTIZ.

[Architectuurontwerp] “Architectuurontwerp basisinfrastructuur in de zorg”, versie4.2, 15 november 2005, NICTIZ. Van dat document zijn de volgende ontwerp-beslissingen overgenomen als uitgangspunt:

• paragraaf 3.1: de basisinfrastructuur biedt generieke functies omzorginformatiesystemen te kunnen koppelen, maar bemoeit zich nietonnodig met de interne werking van zorginformatiesystemen.

• paragraaf 3.3: de uitwerking van de basisinfrastructuur is in eerste instantiegericht op het landelijke e-medicatiedossier, e-waarneemdossier voorhuisartsen en e-declareren.

• paragraaf 5.13: alleen zorginformatiesystemen die voldoen aan de eisen vaneen GBZ worden aangesloten op de basisinfrastructuur.

• paragraaf 5.9: patiëntgegevens blijven in principe opgeslagen in dezorginformatiesystemen waar de zorgverlener deze heeft ingevoerd. Ditkunnen wel zorginformatiesystemen zijn met regionaal of categoraalgecentraliseerde applicatiediensten en bijbehorende centrale opslag. Inonontkoombare gevallen kunnen oplossingen met bijv. replicatie vanbronsystemen naar een centrale database tijdelijk worden toegestaan.

• paragraaf 5.5 en 6.4: de basisinfrastructuur biedt mogelijkheden om:o patiënten te identificeren via landelijke registers,o zorgaanbieders, zorgverzekeraars en zorginformatiesystemen te

identificeren en authenticeren via landelijke registerso patiëntgegevens op te vragen, te versturen,o te abonneren op patiëntgegevens.

• paragraaf 5.13: GBZ’en moeten zorgdragen voor integere, actuele, volledigepatiëntgegevens die 7 dagen per week en 24 uur per dag beschikbaar zijn.

• paragraaf 5.5 en 6.11: de basisinfrastructuur geeft zorgverleners toegangtot patiëntgegevens op basis van generieke autorisatie gericht op de rol vande zorgverlener met logging; autorisatieprotocollen en -profielen wordenlandelijk beheerd.

• paragraaf 5.7: als landelijke registers voor patiënten, zorgaanbieders enzorgverzekeraars wordt gekozen voor resp. SBV-Z, UZI-register en UZOVI-register.

• paragraaf 5.11: de basisinfrastructuur biedt verschillendebeveiligingsniveaus voor de beschikbaarheid, vertrouwelijkheid enonweerlegbaarheid en één niveau voor de integriteit van patiëntgegevens.

• paragraaf 6.2: patiëntgegevens worden uitgewisseld volgens HL7v3, eneventueel aanvullend volgens prEN 13606:2003.


• paragraaf 6.13: alle uitwisselingen van patiëntgegevens tussen GBZ’envinden in principe plaats via een centraal schakelpunt, tenzij er goederedenen en oplossingen zijn omdat anders te doen.

• paragraaf 6.6: een verwijsindex is nodig om bij het opvragen van bepaaldepatiëntgegevens alleen de relevante GBZ’en te bevragen.

• paragraaf 6.11: als vertrouwensmiddel maken zorgverleners en hunsystemen gebruik van UZI-passen.

• paragraaf 7.4: de uitwisseling van patiëntgegevens tussen GBZ’en enbasisinfrastructuur geschiedt via Web Service Messaging, en internet-protocollen.

• paragraaf 7.5: de uitwisseling van patiëntgegevens wordt beveiligd optransportniveau met SSL/TLS en VPN en in de toekomst op berichtniveaumet XML-encryption en XML-signature.

• paragraaf 7.5: de toegang tot patiëntgegevens wordt beveiligd oppersoonlijk niveau met hard tokens.

• paragraaf 7.5.2: voor de communicatie met de ZIM krijgt ieder GBZ eenvast IP-adres, dat uniek is binnen alle aangesloten DCN’s, binnen eenprivate IP-adresreeks.

• paragraaf 7.6: een GBZ mag niet buiten de ZIM om met GBZ’en van anderezorgaanbieders patiëntgegevens uitwisselen.

[HL7 v3] “HL7 Version 3 Standard” © 2002 Health Level Seven ®, Inc. Dezestandaard is belangrijk voor het voorliggende document. Echter, HL7 richt zich opde informatie-uitwisseling tussen systemen en doet geen uitspraken overinformatieverwerking of –ordening binnen systemen. Omdat HL7 Version 3 nog nietafgehamerd is, wordt ballot 7 gebruikt.

[BSN] een verzameling documenten m.b.t. het in ontwikkeling zijnde BSN-stelsel,zie http://www.programmabsn.nl of www.cibg.nl onder projecten.

[UZI] een verzameling documenten m.b.t. het UZI-register, zie www.uzi-register.nl.

[WBP] “Wet Bescherming Persoonsgegevens”

[WGBO] “Wet op de geneeskundige behandelingsovereenkomst”

2.2 Informatieve referenties

De onderstaande documenten hebben gediend als bron voor het voorliggendedocument:

[prENV13606:2003] “Health Informatics – Electronic Health Care Recordcommunication”, revised final draft, May 1999, CEN/TC251. Deze standaardbeschrijft de informatie-uitwisseling, vanuit het perspectief van informatieordeningbinnen een EHR. Van dit document zijn de concepten overgenomen voor zover zeniet wringen met HL7v3.

[Zorgverlenerwensen] “Eisen en wensen voor het aanleggen zorg infrastructuurnetwerk vanuit het gezichtspunt van de zorgverleners en de zorgverlener patiëntrelatie”, augustus 2002, P.L.Ragetlie, KNMG namens NICTIZ. Van dit document zijnde eisen en wensen met betrekking tot het virtuele patiëntdossier overgenomen, ensamengevat in paragraaf 3.4.

http://www.programmabsn.nl

http://www.cibg.nl

http://www.uzi-register.nl.


[KNMG] “Privacy-wetgeving en het omgaan met patiëntgegevens, KNMGHandleiding voor artsen”, Utrecht, mei 2001, KNMG.

[Privacy] “Privacy bij ICT in de zorg” november 2002, T.F.M. Hooghiemstra, CBP.

[Zorgpartijen] “Het wie en wanneer van het ZIN-gebruik – inventarisatie partijen inde zorg en de onderlinge informatieuitwisseling” Amersfoort, 18 januari 2003,diverse auteurs, M&I/Partners.

[Roadmap] “Roadmap Berichtenverkeer” versie 1.0, maart 2001, Wilfried Boon,CSIZ.

[UML] “UML in a Nutshell, a desktop quick reference” 1st edition 1998, Sinan SiAlhir, O’Reilly and Associates Inc. USA.

[Tijdmachine] “Access to EHR and access control at a moment in the past: adiscussion of the need and an exploration of the consequences”, artikel van AbBakker gepresenteerd tijdens IMIA Working Conference "Realizing Security of theElectronic Health Record", 31 mei - 3 juni 2003, Varenna, Italië.


2.3 Afkortingen

AGB Algemene Gegevens Beheer, een code voor de identificatie vanzorgaanbieders ten behoeve van hun declaraties bij zorgverzekeraars

AG(N)IO Assistent-Geneeskundige (Niet) In OpleidingAIS Apotheek Informatie Systeem

AmvB Algemene maatregel van BestuurAWBZ Algemene Wet Bijzondere ZiektekostenASP Application Service Provider, bedrijf dat gebruik van applicaties via

Internet aanbiedtBBR Basis Bedrijven RegisterBIG wet op de Beroepen in de Individuele GezondheidszorgBOPZ wet Bijzondere Opnemingen in Psychiatrische ZiekenhuizenBPR Basisadministratie Persoonsgegevens en Reisdocumenten, agentschap

van BZKBSN Burger Service NummerBVBSN Beheer Voorziening BSNBZK (ministerie van) Binnenlandse Zaken en KoninkrijksrelatiesCA Certification Authority, een TTP die PKI-sleutels certificeert en deze

certificaten uitgeeftCBP College Bescherming PersoonsgegevensCEN Comité Européenne de NormalisationCIBG Centraal Informatiepunt Beroepen Gezondheidszorg, agentschap van

het ministerie van VWSCPI Centrale Patiënt IndexCRL Certificate Revocation List, lijst van ingetrokken (certificaten van) PKI-

sleutelsCvZ College voor zorgverzekeringenDBC Diagnose Behandeling CombinatieDCN Data Communicatie NetwerkDNS Domain Name System, mechanisme voor het toekennen van

hostnamen aan systemen op het internet of een ander IP-netwerk enhet vertalen van die hostnamen naar IP-adressen

DICOM Digital Imaging and Communications in MedicineDWH Dienst Waarneming HuisartsenebXML electronic business XML, internationale familie van standaarden voor

informatie-uitwisseling in de elektronische handelebMS ebXML Messaging Service, standaard protocol voor betrouwbaar

berichtentransporttEHR Electronic Health Record, een Engelse vertaling voor EPDEMD Elektronisch Medicatie Dossiere-NIK elektronische Nationale IdentiteitskaartEPD Elektronisch Patiënten Dossier


GBA Gemeentelijke Basis AdministratieGBZ Goed Beheerd Zorgsysteem, zorgsysteem dat voldoet aan eisen voor

aansluiting op de basisinfrastructuur in de zorgGGZ Geestelijke gezondheidszorgHAGRO Huisartsen GroepHAP HuisartsenpostHOED Huisartsen Onder Een Dak

HIS Huisarts Informatie SysteemHL7 Health Level 7, internationale organisatie voor standaardisatie van de

informatie-uitwisseling in de zorgHL7v3 Health Level 7 version 3, op XML gebaseerde standaard voor

informatie-uitwisseling in de zorgHTTP Hyper Text Transfer Protocol, protocol voor het transporteren van

tekstberichten over een TCP-verbindingICT Informatie en Communicatie TechnologieICTU ICT Uitvoeringsorganisatie (voor overheden)ID, id IdentiteitIEC International Electrotechnical Commission

IETF Internet Engineering Task Force, een onafhankelijke organisatie voorde ontwikkeling en standaardisatie van internettechnologie

IGZ Inspectie voor de GezondheidszorgIP Internet Protocol, netwerkprotocol

ISO International Organization for StandardizationISP Internet Service Provider, bedrijf dat toegang tot het openbare

internet biedt

KNMG Koninklijke Nederlandsche Maatschappij tot bevordering derGeneeskunst

KvK Kamer van KoophandelLAN Local Area Network, lokaal datacomnetwerk, bijv. binnen een

zorginstellingLDAP Lightweight Directory Access Protocol, protocol voor het raadplegen

van een index, bijv. voor het ophalen van een CRL bij een CALIS Laboratorium Informatie SysteemLRD Landelijk Raadpleegbare Deelverzameling, dat deel van de GBA-

gegevens dat on-line opvraagbaar isLSP Landelijk Schakelpunt, de organisatie die de ZIM exploiteertMLLP Minimal Lower Layer Protocol, een datacom-protocol, veel gebruikt

binnen ziekenhuizen voor het transport van HL7-berichtenMPI Master Patient Index, een systeem dat patiëntnummers uit

verschillende zorginformatiesystemen kan vertalen

MTBF Mean Time Between Failures, tezamen met de MTTR een maat voor debeschikbaarheid van een systeem

MTTR Mean Time To Repair, tezamen met de MTBF een maat voor debeschikbaarheid van een systeem

NAT Network Address Translation, mechanisme om interne IP-adressen tevertalen naar externe IP-adressen en andersom


NAW Naam, Adres, WoonplaatsNEN Nederlands Normalisatie-instituutNTP Network Time Protocol, protocol voor het synchroniseren van

tijdklokken tussen verschillende ICT-voorzieningenOBV Overkoepelende Beheer Voorziening van het BSN-stelselOCSP Online Certificate Status Protocol, techniek voor het verifiëren van een

(certificaat van) een PKI-sleutelOID Object Identifier, een standaard wijze voor de identificatie van

objecten, zie www.alvestrand.no/objectid/OMG Object Management Group, samenwerkingsverband tussen enkele

grote ICT-leveranciers

OZIS Open Zorg Informatiesysteem, stichting die tot doel heeft deimplementatie van standaarden in de eerstelijnsgezondheidszorg tebevorderen

PACS Picture Archiving and Communication SystemPKI Public Key Infrastructure, een methode voor beveiliging gebaseerd op

het gebruik van publieke en private sleutelsPKIO PKI Overheid, verzameling richtlijnen voor de beveiliging van

overheidsgegevens met PKIRA Registratie Autoriteit, een TTP die aanvragen voor certificering namens

de CA afhandeltRFC Request for Comment, een verwijzing naar een internetstandaard

vastgesteld door de IETFRIAGG Regionale Instelling voor Ambulante Geestelijke GezondheidszorgRIBW Regionale Instelling voor Beschermd Wonen

RIO Regionaal Indicatie OrgaanRIM Reference Information Model, informatiemodel dat de basis vormt voor

de ontwikkeling van berichten, zie [HL7 v3] en CEN TC251RIS Radiologie Informatie Systeem

RM-ODP Reference Model for Open Distributed Processing, eenarchitectuurraamwerk, gestandaardiseerd door ISO

RNI Register Niet-Ingezetenen, te ontwikkelen register in het kader vanhet BSN-stelsel

SBV Sectorale BerichtenVoorziening van het BSN-stelselSBV-Z SBV voor de zorgsectorSEH Spoed Eisende Hulp

SOAP Simple Object Access Protocol, op XML gebaseerde techniek om eenelektronisch document in te pakken in een envelop met routerings-gegevens, gestandaardiseerd door W3C

SSL Secure Socket Layer, techniek voor het beveiligen van een TCP-verbinding over het internet

TCP Transport Control Protocol, protocol voor het opzetten van eenverbinding over een IP-netwerk

TEIN Technische InfrastructuurTLS Transport Layer Security, de opvolger van SSLTOGAF The Open Group Architecture Framework, een architectuurraamwerk,

http://www.alvestrand.no/objectid/


gestandaardiseerd door The Open GroupTTP Trusted Third Party, rol van een vertrouwde derde binnen een PKI-

kaderUDDI Universal Description, Discovery and Integration, op XML gebaseerde

techniek om web services op te zoeken, gestandaardiseerd door W3CUML Unified Modeling Language, door de OMG gestandaardiseerde

modelleertechniek

URA UZI-Register Abonneenummer, identificatienummer van dezorgaanbieder die UZI-passen heeft aangevraagd

URI Universal Resource Identifier, wijze van adresseren vaninformatiebronnen op het Internet

UZI Unieke Zorgverleners Identificatie, landelijk identificatienummer voorzorgverleners, zorginstellingen en zorgsystemen

UZOVI Unieke ZorgVerzekeraars Identificatie, landelijk identificatienummervoor zorgverzekeraars

VAN Value Added Network, openbaar netwerk met extra dienstverleningVeCoZo ‘Veilig Communiceren in de Zorg’, ICT-aanbieder die PKI-sleutels

uitgeeft ten behoeve van de beveiling van declaratieverkeer

VPN Virtual Private Network, techniek voor beveiligde datacommunicatieover openbare netwerken

VWS (ministerie van) Volksgezondheid Welzijn en SportW3C World Wide Web Consortium, internationale samenwerkingsorganisatie

voor de ontwikkeling en standaardisatie van webtechnologieWBP Wet bescherming persoonsgegevensWDH Waarneem Dossier Huisartsen

WEH Wet elektronische handtekeningenWGBO Wet op de geneeskundige behandelingsovereenkomstWGBZ Wet Gebruik BSN in de Zorg (wetsvoorstel)WID Wettelijk Identificatie DocumentWOG Wet op de geneesmiddelenverstrekkingWSDL Web Services Definition Language, op XML gebaseerde techniek om

web services te definiëren, gestandaardiseerd door W3CWSP Web Services Profile, wijze waarop HL7v3-berichten moeten worden

gebonden op HTTP/SOAP, gestandaardiseerd door HL7XIS generieke term voor HIS, AIS, ZIS, etc. (zorginformatiesysteem)XML eXtensible Markup Language, techniek voor het structureren van

elektronische documentenZAIS Ziekenhuis Apotheek Informatie SysteemZIM Zorg Informatie Makelaar, onderdeel van de basisinfrastructuur in de

zorg waarlangs alle aangesloten GBZ’en veilig patiëntgegevens kunnenuitwisselen

ZIN Zorg Identificatie Nummer, landelijk identificatienummer voorpotentiële patiënten/cliënten

ZIS Ziekenhuis Informatie SysteemZSP Zorg Service Provider, netwerkdienstverlener die namens LSP

zorgaanbieders met hun GBZ mag aansluiten op de ZIM


De afkortingen gebruikt in hoofdstuk 5 hebben geen geldigheid buiten ditdocument, zij worden aldaar verklaard.


2.4 Begrippen

Begrip Omschrijving

Abonnee Zorgaanbieder die met het UZI-register een overeenkomstsluit om UZI-passen te kunnen afnemen

Applicatie programmatuur die bepaalde functies kan leveren aanGebruikers of andere ICT-voorzieningen

Autoriseren toekennen van bevoegdheden aan een persoon oforganisatie

Authenticeren controleren van de authenticiteitAuthenticiteit zekerheid dat de identiteit waarvoor een persoon of

organisatie zich uitgeeft juist isAutorisatieprofiel door Patiënt / Cliënt bepaalde autorisatietabel die bepaalt

welke categorieën van zijn patiëntgegevens voor welkeZorgaanbieders toegankelijk zijn onder welke voorwaarden

Autorisatieprotocol door Zorgaanbieders gedefinieerde autorisatietabel diebepaalt welke categorieën patiëntgegevens voor welkecategorieën Zorgaanbieders toegankelijk zijn onder welkevoorwaarden

Basisinfrastructuur geheel aan gemeenschappelijke ICT-voorzieningen metbijbehorende organisatorische voorzieningen

Beschikbaarheid kans dat een systeem in staat is de gespecificeerde Dienstenof Functies te bieden

Betrokkenheid verantwoordelijkheid van een zorgverlener t.o.v. een Patiënt/ Cliënt m.b.t. de overeengekomen Zorgdienst

Betrouwbaarheid kans dat een systeem de gespecificeerde Diensten ofFuncties uitvoert conform de specificatie (IEC 61508)

Breng-mechanisme wijze van informatie-uitwisseling waarbij Patiëntgegevens opinitiatief van de verzender worden gebracht

Cliënt persoon die verpleging of verzorging (care) geniet ofmogelijk zal genieten

Canoniek XML standaardvorm van XML zonder lexicale vrijheden, opdatbitsgewijs kan worden gecontroleerd of twee XML-documenten semantisch identiek zijn

Convergeren Doorschakelen van berichten van meerdere afzenders naaréén bestemming

Dienst prestatie geleverd door een partij aan een andere partij

Divergeren Doorschakelen van berichten van één afzender naarmeerdere bestemmingen

Doorschakelen actie van een schakelpunt inzake het ontvangen envervolgens doorsturen, divergeren of convergeren van eenbericht

Doorsturen Doorschakelen van berichten van één afzender naar éénbestemming

Duplicaatbericht bericht dat identiek is aan een ander bericht, zie ook §


5.10.4ElektronischPatiëntdossier

ICT-voorziening die toegang geeft tot de verschillendePatiëntdossiers binnen een zorginstelling

Episode reeks van opeenvolgende Zorgcontacten die een Patiënt /Cliënt heeft met een of meer Zorgaanbieders in het kadervan een bepaalde Zorgvraag

Functie zie Systeemfunctie of ZorgverlenerfunctieGBZ-applicatie Zorgapplicatie die als onderdeel van een GBZ is aangesloten

op de ZIMGebruiker Zorgverlener, Medewerker, beheerder of Patiënt / Cliënt die

een GBZ-applicatie gebruikt, zie ook § 4.2Gebruikersinteractie actie van een Gebruiker m.b.t. het landelijk uitwisselen van

Patiëntgegevens, zie § 5.3.1Gegevenssoort typering van een soort van PatiëntgegevensHaal-mechanisme mechanisme van informatie-uitwisseling waarbij

Patiëntgegevens op verzoek van de ontvanger wordengehaald

Herroepen ongeldig maken, bijv. van een patiëntstuk, zie § 4.2.5Hoofdbehandelaar Zorgaanbieder waarmee een Patiënt / Cliënt een behandel-

overeenkomst heeft, zie ook § 3.3Hostnaam in een DNS-server geregistreerde naam van een systeem op

het internet of een ander IP-netwerk, zie RFC 3986Identificeren bepalen van de identiteit van een persoon of organisatieICT-infrastructuur geheel aan gemeenschappelijke ICT-voorzieningen

ICT-voorziening hardware en software gericht op het elektronisch verwerkenof communiceren van informatie

Integriteit zekerheid dat bepaalde gegevens niet (ongemerkt) kunnenworden gewijzigd

Interactie-mechanisme

wijze waarop een GBZ een HL7-bericht moet uitwisselen metde ZIM, afhankelijk van het type HL7-bericht, zie § 5.3

Mandateren overdragen van bevoegdheden bij het delegeren van takenMedebehandelaar Zorgaanbieder die in opdracht van een Hoofdbehandelaar

handelt, zie ook § 3.3Medewerker persoon in dienst van een Zorginstelling of in dienst bij een

Zorgverlener die in opdracht daarvan ondersteunendediensten verleent

Onweerlegbaarheid zekerheid dat bepaalde handelingen niet kunnen wordenontkend door de verantwoordelijke

Patiënt persoon die geneeskundig onderzoek of behandeling (cure)geniet of mogelijk zal genieten

Patiëntbericht bericht met Patiëntgegevens dat in het kader vansamenwerking wordt verstuurd aan een Zorgaanbieder

Patiëntdocument persistente verzameling van samenhangendePatiëntgegevens die als één geheel wordt vastgelegd,opgevraagd en verstuurd.


Patiëntgegevens (persoonlijke, logistieke, medische en/of financiële)gegevens over een bepaalde Patiënt / Cliënt die zijnvastgelegd in het kader van een Zorgdienst

Patiëntkluis verzameling van Patiëntgegevens van één Patiënt / Cliëntonder beheer van die Patiënt / Cliënt zelf

Patiëntdossier verzameling van Patiëntgegevens van één Patiënt / Cliëntonder beheer van de verantwoordelijke zorgaanbieder

Patiëntenindex Lijst met identificerende gegevens van patiënten bij eenzorgaanbieder

Patiëntstuk deel van, of uittreksel uit, een PatiëntdossierReconstructiehorizon tijdshorizon in het verleden tot wanneer een Gebruikers-

interactie moet kunnen worden gereconstrueerdRol een veelgebruikte term met verschillende interpretaties, zie

verder onder Betrokkenheid, Werkverband, Toepassingsrolen Zorgverlenerfunctie

Systeem ICT-voorziening of verband van ICT-voorzieningen, al danniet inclusief de beheerders en gebruikers, dat zelfstandigDiensten of Functies kan leveren

Systeemfunctie prestatie geleverd door een Systeem aan een GebruikerTime-out het verlopen van een tijdsinterval waarbinnen een Systeem

het resultaat van een actie afwacht alvorens een fout wordtverondersteld

Toepassingsrol rol van een Applicatie in het kader van een bepaaldelandelijke Zorgtoepassing, zie § 4.1

Transactie reeks van twee of meer Interacties die als één geheelmoeten worden uitgevoerd

UZI-pas Persoonsgebonden vertrouwensmiddel voor Zorgverlenersen hun Medewerkers, uitgegeven door het UZI-register

UZI-servicescertificaat

systeemgebonden vertrouwensmiddel voor ICT-voorzieningen van Zorgaanbieders, uitgegeven door hetUZI-register

Vertrouwelijkheid zekerheid dat bepaalde gegevens uitsluitend doorbevoegden kunnen worden ingezien

Vertrouwensmiddel middel waarmee iemand zich elektronisch kan identificeren,authenticeren en eventueel een elektronische handtekeningkan zetten

VirtueelPatiëntdossier

verzameling van organisatorisch en geografisch verspreidePatiëntdossiers die zodanig toegankelijk zijn, als waren zijéén groot Patiëntdossier

Virtueel Postkantoor verzameling van organisatorisch en geografisch verspreidepostbussen die alle zorgaanbieders zodanig bereikbaarmaken, als vormden zij één zorgaanbieder

Werkverband de verantwoordelijkheid van een Zorgpartij t.o.v. zijneventuele Zorginstelling m.b.t. het verlenen vanZorgdiensten

Zoekpad set van identificerende gegevens t.b.v het zoeken in eenregister of gids

Zorgaanbieder Zelfstandige Zorgverlener of Zorginstelling


Zorgapplicatie Applicatie die ter beschikking van een Zorgpartij, naderonder te verdelen in Zorgaanbiederapplicatie, Patiënt-applicatie, etc.

Zorgaanbiedergids gids waarin Zorginstellingen en Zorgverleners de door hungeboden Zorgdiensten en bereikbaarheidsgegevens kunnenvermelden

Zorgaanbieder-nummer

identificatienummer van een Zorgverlener of medewerker,zonodig in combinatie met het identificatienummer van deZorginstelling

Zorgaanbieder-postbus

verzameling door zorgaanbieder af te handelenpatiëntberichten

Zorgaanbieder-register

register met Zorgaanbieders die zorgpartijen in staat steltZorgaanbieders te identificeren

Zorgconsument Patiënt of CliëntZorgcontact sessie waarin een Zorgaanbieder aandacht besteedt aan één

of meer Zorgvragen van een Patiënt / CliëntZorgdienst dienst gericht op het onderzoeken, verbeteren, behouden of

ondersteunen van de lichamelijke of geestelijke gezond-heidstoestand van een Patiënt / Cliënt

Zorginstelling organisatorisch verband van Zorgverleners enondersteunende medewerkers dat Zorgdiensten verleentaan een Patiënt / Cliënt

Zorgpartij persoon of organisatie die een primaire rol speelt bij deverlening van Zorgdiensten

Zorgproduct product benodigd bij het onderzoeken, of gericht op hetverbeteren, behouden of ondersteunen van de lichamelijkeof geestelijke gezondheidstoestand van een Patiënt / Cliënt

Zorgnetwerk regionaal samenwerkingsverband van Zorgaanbieders enZorgverzekeraars

Zorgsysteem ICT-voorziening die rechtstreeks ter beschikking staat vaneen Zorgaanbieder

Zorgtoepassing toepassing van landelijke uitwisseling van patiëntgegevenstussen samenwerkende zorgaanbieders, ten behoeve vaneen bepaalde Zorgdienst, zie § 4.1

Zorgverlener persoon die beroepsmatig Zorgdiensten verleent aan eenPatiënt / Cliënt

Zorgverlenerfunctie de beroepstitel (en eventueel het specialisme) van eenzorgverlener die bepaalt welke zorgdiensten hij of zijnzorginstelling kan verlenen

Zorgverzekeraar ziekenfonds, ziektekostenverzekeraar of zorgkantoorZorgvraag behoefte van een Patiënt / Cliënt aan een Zorgdienst

Tenslotte: overal in dit document waar de voornaamwoorden “hij” of “zijn” staan,wordt “hij of zij” resp. “zijn of haar” bedoeld.


3 Bedrijfsarchitectuur

In de Bedrijfsarchitectuur worden de zorgpartijen (personen of instellingen), hundiensten, rechten, plichten, verantwoordelijkheden, informatie, onderlingesamenwerking en organisatie geanalyseerd, waarbij alle ondersteunende ICT-voorzieningen nog buiten beschouwing worden gelaten. Dit hoofdstuk isnadrukkelijk bedoeld als analyse van de manier waarop de partijen in de zorgonderling informatie zouden willen of kunnen uitwisselen, om in hoofdstuk 4 tekomen tot eisen aan de ondersteunende ICT-voorzieningen. Dit hoofdstuk isnadrukkelijk niet bedoeld als richtlijn voor de manier waarop zorgpartijen moetensamenwerken.

3.1 Zorgpartijen

Er zijn zeer veel verschillende partijen in de zorgsector. De belangrijkste zijn:• patiënt/cliënt,• zorgaanbieder, dit kan zijn:

o een individuele zorgverlenero een zorginstelling

• zorgverzekeraar.

De onderstaande figuur toont het verband tussen alle zorgpartijen in een UML classdiagram:

Patiënt/cliënt Zorgaanbieder

Zorgverzekeraar

Zorgpartij

Zorgverlener

Zorginstelling

Het begrip zorgpartij heeft betrekking op de rol van een persoon en niet op eenpersoon zelf. Zo kan een persoon verscheidene rollen hebben: zowel zorgaanbiederals patiënt/cliënt. Maar in één behandelrelatie heeft een persoon altijd één rol.


3.1.1 Patiënt/cliënt

Een patiënt/cliënt is een natuurlijke persoon die zorgdiensten ontvangt of wenst teontvangen. Dit begrip is een combinatie van de volgende begrippen:

• patiënt, de persoon die geneeskundig onderzoek of behandeling (cure)geniet,

• cliënt, de persoon die verpleging of verzorging (care) geniet.

3.1.2 Zorgaanbieder

Met een zorgaanbieder wordt zowel een individuele zorgverlener (bijv. een arts dieeen patiënt onderzoekt) als ook een hele zorginstelling (bijv. een verpleegtehuisdat een bed ter beschikking stelt) bedoeld. Deze abstractie wordt in dit documentgebruikt om de analogie aan te geven tussen de werkwijze van individuelezorgverleners en die van zorginstellingen als geheel.

De WGBO spreekt over hulpverlener en definieert deze als “de contractpartij diezich verbindt tot geneeskundige handelingen”. Dit kan zowel een natuurlijkepersoon (zorgverlener) als een rechtspersoon (zorginstelling) zijn. Daarmee is debenaming zorgaanbieder weer op zijn plaats.

3.1.3 Zorgverlener

Een zorgverlener is een natuurlijke persoon die beroepsmatig zorgdiensten verleentaan een patiënt/cliënt. Er zijn zorgverleners met zeer uiteenlopende beroepstitels.Volgens de Wet BIG zijn bepaalde beroepstitels wettelijk beschermd:

• arts• tandarts• apotheker• gezondheidspsycholoog• psychotherapeut• fysiotherapeut• verloskundige• verpleegkundige

Daarnaast laat Artikel 34 van de Wet BIG toe via een AmvB de volgendeberoepstitels toe te voegen:

• diëtist• ergotherapeut• huidtherapeut• logopedist• mondhygiënist• oefentherapeut (Mensendieck/Cesar)• optometrist• orthopist• podotherapeut• radiodiagnostisch laborant• radiotherapeutisch laborant

Tenslotte zijn er tal van andere zorgverleners zonder beschermde beroepstitels:• homeopaat• thuiszorgmedewerker• etc.


Binnen sommige beroepstitels is sprake van vergaande specialisatie, zoalsvastgesteld door de respectievelijke beroepsverenigingen, bijvoorbeeld:

• artso allergologieo anesthesiologieo cardio-thoracale chirurgieo cardiologieo dermatologie en venerologieo gastro-enterologieo huisartsgeneeskundeo etc.

• tandartso dento-maxillaire orthopaedieo mondziekten en kaakchirurgie

Men mag die beroepen met eventuele specialismen pas uitoefenen, als mendaarvoor de benodigde kwalificaties heeft. Deze kwalificaties worden vastgelegd enbijgehouden in het BIG-register resp. het Kwaliteitsregister Paramedici. Het gaathier om diploma’s, maar ook om eventuele nascholing en in de toekomst misschienook om tuchtrechtelijke zaken.

Aldus definiëren we het begrip zorgverlener-kwalificaties als:

• de kwalificaties van een zorgverlener, zoals vastgelegd in het BIG-register ofhet Kwaliteitsregister Paramedici, die bepalen dat hij een bepaald beroepmet eventuele specialismen mag uitoefenen.

Voor wat betreft de daadwerkelijke uitoefening geldt dat zorgverleners individueel,binnen een zorginstelling, beide of helemaal niet werken:

• individuele uitoefening is toegestaan voor bepaalde beroepen, voor sommigedaarvan (bijvoorbeeld gezondheidspsychologen) geldt een vrije vestiging,voor andere gelden vestigingsvoorwaarden. Als een zorgverlener meerdereberoepstitels heeft, zal altijd duidelijk moeten zijn welk beroep hij vanuit eenbepaalde vestiging uitoefent.

• uitoefening binnen een zorginstelling is verplicht voor de meestespecialismen. Als een zorgverlener gaat werken voor een zorginstelling,draagt hij de aansprakelijkheid over aan de (medisch) directeur van diezorginstelling. Als een zorgverlener meerdere beroepstitels en/ofspecialismen heeft, zal de directeur hem gewoonlijk aanstellen in éénberoep, met één of meerdere sterk gerelateerde specialismen.

Aldus definiëren we het begrip zorgverlener-functie als:

• het beroep met één of meer gerelateerd(e) specialisme(n) dat eenzorgverlener daadwerkelijk uitoefent vanuit een bepaalde individuelevestiging of volgens zijn aanstelling binnen een zorginstelling.

Merk op dat er geen exacte 1-op-1 relatie bestaat tussen zorgverlener-kwalificatiesen zorgverlener-functie. Immers, iemand met bepaalde zorgverlener-kwalificaties,maar zonder vestiging of aanstelling als zodanig, heeft geen zorgverlener-functie.


Let op: sommige zorgpartijen hebben weliswaar arts als beroepstitel, maar zijntoch geen zorgverlener:

• een keuringsarts onderzoekt de gezondheid van een (potentiële)werknemer, met als doel diens geschiktheid voor bepaalde werkzaamhedente bepalen. Zijn opdrachtgever is meestal de (potentiële) werkgever.

• een verzekeringsarts onderzoekt of bepaalde zorgdiensten in aanmerkingkomen voor vergoeding door de zorgverzekeraar. Zijn opdrachtgever is dezorgverzekeraar.

Daarentegen werkt de zorgverlener in opdracht van de patiënt/cliënt en is zijn doelgericht op de verbetering van diens gezondheidstoestand.

Opmerkingen:

• het begrip functie komt overeen met het begrip role in [HL7v3] en hetbegrip structural role in [prEN13606:2003].

• de apotheekhoudende huisarts lijkt in eerste instantie niet in hetbovenstaande stramien te vatten. Deze zorgverlener is formeel huisarts enheeft dus niet dezelfde bevoegdheden als een apotheker. Maar debevoegdheden die een huisarts heeft m.b.t. inzage in patiëntgegevens zijnvoldoende om op te treden als apotheekhoudende huisarts.

• een co-assistent is geen arts en wordt hier dus niet als zorgverlenerbeschouwd, maar als medewerker. Een AG(N)IO is een arts, zij het zonderspecialisme, en wordt dus wel als zorgverlener beschouwd. Zie verderparagraaf 3.3.3.


3.1.4 Zorginstelling

Een zorginstelling is een organisatorisch verband van zorgverleners enondersteunende medewerkers dat zorgdiensten verleent aan patiënten/cliënten.Zorginstellingen zijn er in vele soorten:

• geneeskundige behandeling en onderzoek:o ziekenhuizen (algemeen, academisch, categoraal)o laboratoriao revalidatiecentrao etc.

• verpleging en verzorging:o verpleeghuizeno verzorgingstehuizeno thuiszorginstelingeno consultatiebureauso etc.

• geestelijke gezondheidszorg:o RIAGG’so RIBW’so verslavingszorginstellingeno etc.

Deze lijst is geenszins limitatief: alle instellingen die een patiënt/cliënt zorgdienstenverlenen, kunnen in principe als zorginstelling worden beschouwd. In dit documentworden daarom ook de volgende zorgpartijen gemakshalve als zorginstellingbeschouwd:

• huisartspraktijken• apotheken• ziekenvervoerders

Anders dan voor zorgverleners gelden voor zorginstellingen geen éénduidigekwalificaties die bepalen welke zorgdiensten mogen worden aangeboden. Wel is ereen “Kwaliteitswet zorginstellingen” die bepaalt aan welke eisen een zorginstellingin zijn algemeenheid moet voldoen. Om te bepalen of een organisatie kan wordenbeschouwd als zorginstelling, wordt in de praktijk het toetsingsregister van het CVZgebruikt. Voor een compleet overzicht van mogelijke zorginstellingen, zie[Zorgpartijen].

Zorginstellingen zijn gewoonlijk als rechtspersoon ingeschreven bij de Kamer vanKoophandel (KvK), tezamen met één of meer directeuren. Daarvan dient één op tetreden als verantwoordelijke en aansprakelijke voor de aangeboden zorgdiensten.Deze zal ook verantwoordelijk zijn voor het aantrekken van de juiste:

• zorgverleners om bepaalde zorgdiensten te mogen of kunnen aanbieden,• ondersteunende medewerkers om bepaalde ondersteunende diensten te

kunnen aanbieden.

Grote zorginstellingen, zoals ziekenhuizen, hebben vaak een algemeen directeur eneen medisch directeur. Verder bestaan deze meestal uit een aantal gespecialiseerdeafdelingen met een grote mate van zelfstandigheid, die gezamenlijk gebruik makenvan de ondersteunende diensten en faciliteiten van de zorginstelling. Dezegespecialiseerde afdelingen worden meestal geleid door gespecialiseerdezorgverleners, die vaak in een maatschap zijn verenigd. Niettemin hebben dezemaatschappen de medische eindverantwoordelijkheid gewoonlijk overgedragen aande medisch directeur van het ziekenhuis.


Kleine zorginstellingen, zoals huisartsenpraktijken, zijn vaak niet ingeschreven bijde KvK, maar dat zou eigenlijk wel moeten als een huisarts medewerkers in dienstneemt. Er is een trend dat huisartsen steeds meer samenwerken in groeps-praktijken. Ook hier komen maatschappen voor, in dat geval ligt deaansprakelijkheid bij die maatschap.

Let op: sommige organisaties zijn samenwerkingsverbanden en geenzorginstellingen:

• huisartsen onder één dak (HOED) en huisartsengroepen (HAGRO) die eengemeenschappelijke praktijk met gezamenlijke medewerkers hebben,

• huisartsenposten (HAP), waar huisartsen gemeenschappelijke faciliteitengebruiken om buiten de normale diensturen voor elkaar te kunnenwaarnemen,

• gezondheidscentra, waar huisartsen, fysiotherapeuten en andere eerstelijns-zorgverleners gemeenschappelijke faciliteiten gebruiken.

Niettemin kunnen ook deze organisaties besluiten een maatschap of stichting tevormen en zich in te schrijven als zorginstelling bij de KvK. Om aannemelijk temaken dat de organisatie strekt tot zorg, zal een stichting op naam moeten staanvan minimaal twee zorgverleners die zijn erkend in het BIG-register.

3.1.5 Zorgverzekeraar

Zorgverzekeraars zijn te onderscheiden in:• een ziekenfonds,• een ziektekostenverzekeraar of• een zorgkantoor.

Deze paragraaf wordt in een latere versie van dit document nader uitgewerkt.

3.1.6 Afbakening

Met de keuze van de bovengenoemde zorgpartijen (patiënten/cliënten,zorgaanbieders en zorgverzekeraars) als doelgroep, wordt tevens de reikwijdte vande beoogde basisinfrastructuur voorlopig afgebakend. Zo worden bijvoorbeeld deleveranciers van de zorgaanbieders (zoals de farmaceutische groothandel)voorlopig buiten beschouwing gelaten. Dat wil zeggen, bij het maken vanontwerpkeuzes zullen alleen de belangen van patiënten/cliënten, zorgaanbieders enzorgverzekeraars worden afgewogen. Later kan worden bekeken of en hoe hetgebied van goederenlogistiek alsnog kan worden ingepast of aangesloten. Ook hetgebied van onderwijs en fundamenteel onderzoek in de zorg wordt voorlopig buitenbeschouwing gelaten.

Voor de beoogde basisinfrastructuur is de doelgroep van zorgaanbieders geenszinsafgebakend. Niettemin zal bij de navolgende analyses vooral worden gekeken naarde huisarts, de apotheker en het ziekenhuis.


3.2 Diensten

De zorgpartijen leveren elkaar de volgende diensten:

(a) een patiënt/cliënt (of diens werkgever) betaalt premie aan zijnzorgverzekeraar,

(b) een zorgaanbieder verleent zorgdiensten aan een patiënt/cliënt,

(c) de zorgaanbieder kan hierbij samenwerken met andere zorgaanbieders,

(d) de zorgaanbieder meldt dit vooraf eventueel aan de zorgverzekeraar, tercontrole van het verzekeringsrecht en zonodig ter verkrijging van eenmachtiging,

(e) de zorgverzekeraar vergoedt de zorgaanbieder rechtstreeks(ziekenfondspatiënten) na diens declaratie, of

(f) de zorgverzekeraar vergoedt de patiënt/cliënt na diens claim, en

(g) de patiënt/cliënt (particulier verzekerde) vergoedt zijn zorgaanbieder.

De onderstaande figuur toont deze relaties in een UML class diagram.

Patiënt/cliënt

Zorgaanbieder

Zorgverzekeraar

(b) v

erle

ent z

orgd

iens

t aan

>

< vergoedt (f)

< vergoedt (e)

(a) betaalt premie aan >

< ve

rgoe

dt (g

)

(c) werktsamen

met

(d) meldt evt. aan >

Meestal heeft een patiënt/cliënt op een bepaald moment één zorgverzekeraar enéén of meer zorgaanbieders. Omgekeerd hebben zorgaanbieders enzorgverzekeraars meerdere patiënten/cliënten. In het bijzondere geval van eengroepstherapie heeft een zorgaanbieder te maken met een groeppatiënten/cliënten.

Paragraaf 3.3 gaat nader in op de zorgrelatie tussen patiënt/cliënt enzorgaanbieder, en de samenwerkingsrelatie tussen zorgaanbieders onderling.


3.2.1 Zorgdiensten

Een zorgdienst is een dienst gericht op het onderzoeken, verbeteren, behouden ofondersteunen van de lichamelijke of geestelijke gezondheidstoestand van eenpatiënt/cliënt. Soms wordt in dit document ook het begrip behandeling gebruikt,omdat dit wordt gehanteerd in de WGBO, maar dit document richt zich op degehele zorgsector en derhalve is het ruimere begrip zorgdienst meer op zijn plaats.

Zorgdiensten zijn te divers om daarvan een goede generieke beschrijving te kunnengeven. Vaak hebben gespecialiseerde zorgverleners hun eigen werkwijzeontwikkeld, al proberen de verschillende beroepsverenigingen die werkwijze testandaardiseren en vast te leggen in een protocol.

De zorg is een bedrijfstak met een hoge mate van differentiatie van deverschillende aangeboden zorgdiensten. Bevoegdheden m.b.t. het verlenen vanbepaalde zorgdiensten zijn volgens diverse (al dan niet wettelijke) regelingenvoorbehouden aan zorgverleners met bepaalde beroepstitels en of specialismen.

Daardoor heeft een patiënt/cliënt naar aanleiding van een zorgvraag vaak metmeerdere zorgaanbieders te maken. Aldus doorloopt een patiënt/cliënt eenzorgketen van zorgcontacten met verschillende zorgaanbieders. Deze zorgketenkan voor sommige zorgvragen zeer ingewikkeld of onvoorspelbaar zijn. Nietteminwordt door beroepsverenigingen getracht multidisciplinaire samenwerkings-protocollen op te stellen.

3.2.2 Logistieke diensten

Zorginstellingen bieden behalve zorgdiensten ook een tal van logistieke diensten,bedoeld om vraag en aanbod van zorgdiensten bij elkaar te brengen:

• het maken van afspraken met zorgverleners,• het reserveren van de benodigde faciliteiten,• het aanvoeren van de benodigde zorgproducten,• etc.

Wegens schaarse beschikbaarheid van zorgverleners en faciliteiten is het een groteuitdaging voor een zorginstelling om de verschillende zorgcontacten voor éénpatiënt/cliënt goed op elkaar te laten aansluiten. Tussen zorginstellingen is dezepatiëntenlogistiek nog moeilijker. De goederenlogistiek wordt in dit documentvoorlopig buiten beschouwing gelaten.

3.2.3 Financiële diensten

Zorgverzekeraars bieden een aantal financiële diensten, bedoeld om niet alleenachteraf de vergoeding af te handelen, maar ook om vooraf de vergoeding veilig testellen:

• controle verzekeringsrecht,• afhandelen declaraties,• etc.

De zorgverzekeraars worden in deze versie van dit document nog buitenbeschouwing gelaten. In een volgende versie van dit document zal deze paragraafnader worden uitgewerkt.


Naar verwachting zijn de meeste principes, ontwerpbeslissingen en oplossingen indit document ook toepasbaar voor de zorgverzekeraars.

3.2.4 Sturende diensten

Het bovenstaande heeft betrekking op het operationele niveau van de zorgdiensten.Op tactisch en strategisch niveau spelen ook andere partijen een rol:

(a) een zorgcoördinator (bijv. een Regionaal Indicatie Orgaan) kan optreden alsintermediair tussen patiënt/cliënt en zorgaanbieder,

(b) beroepsverenigingen van zorgaanbieders resp. zorgverzekeraars verzamelenperiodiek medische en logistieke gegevens van hun leden,

(c) de overheid ontvangt al deze beleidsgegevens en stelt zonodig haar beleidbij,

(d) wetenschappelijke instituten ontvangen medische gegevens voorwetenschappelijk onderzoek.

De onderstaande figuur toont deze partijen in een UML class diagram, maar moetnog nader uitgewerkt worden.

Patiënt/cliënt

Zorgaanbieder

Zorgverzekeraar

Beroepsverenigingen

Wetensch.instituten

meldt indicatiebesluit

Zorgcoördinator

< bi

eden

med

ische

geg

Overheid

bieden beleidsgegevens

In een latere versie van dit document zullen deze diensten ook worden uitgewerkt.


3.3 Relaties

Zorgpartijen zullen voorafgaand aan hun wederzijdse diensten eerst onderling eenrelatie aangaan, daarover afspraken maken en deze soms contractueel vastleggen.De volgende relaties worden beschouwd:

• zorgrelatie tussen patiënt/cliënt en zorgaanbieder,• samenwerkingsrelatie tussen zorgaanbieders onderling.

3.3.1 Wetten, normen en andere uitgangspunten

Volgens de WBGO geldt het volgende ten aanzien van relaties tussen eenpatiënt/cliënt en zijn zorgaanbieder:

• een patiënt/cliënt sluit een behandelovereenkomst met zijn zorgverlener,dan wel zorgverleners.

• in geval van een zorginstelling is de zorginstelling centraal aansprakelijkvoor de geleverde zorgdiensten.

3.3.2 Zorgrelatie

Behalve de WGBO gelden binnen zorginstellingen ook tal van interne afsprakeninzake verdeling van taken, verantwoordelijkheden en bevoegdheden.

Zorginstellingafdeling

ZorginstellingverantwZorginstelling

Patiënt/cliënt

(j) heeft als aanspreekpunt >

(e) ontvangt zorgdiensten van >

(f) ontvangt onderst. diensten van >

Individuelezorgverlener

^ werken onder aansprakelijkheid van (h)

(g) werken somssamen in >

(a) sluit behandelovereenk. meten ontvangt zorgdiensten van >

(d) sluit behandelovereenk. met >

< is centraal aansprakelijk voor (i)

Zorginstellingzorgverlener

Zorginstellingmedewerker

Individuelemedewerker

^ werkt onder verantwoordelijkheid van (c)

(b) ontvangt onderst. diensten van >

De bovenstaande figuur toont de zorgrelatie tussen een patiënt/cliënt en deverschillende partijen binnen een zorgaanbieder in een UML class diagram, waarbijhet volgende geldt:


(a) in het geval van een individueel werkende zorgverlener, sluit depatiënt/cliënt een behandelovereenkomst met deze persoon en ontvangt deovereengekomen zorgdiensten van dezelfde persoon.

(b) de patiënt/cliënt ontvangt daarnaast ondersteunende (vaak administratieveof logistieke) diensten van een medewerker,

(c) deze medewerker werkt onder verantwoordelijkheid van die zorgverlener,

(d) in het geval van een zorginstelling, sluit de patiënt/cliënt eenbehandelovereenkomst met een zorgverlener van die zorginstelling,

(e) de patiënt/cliënt ontvangt de feitelijke zorgdiensten van die zorgverlener eneventueel, onder diens aansturing, ook andere zorgverleners van diezorginstelling,

(f) de patiënt/cliënt ontvangt daarnaast ondersteunende (vaak administratieveof logistieke) diensten van een medewerker in dienst van die zorginstelling,

(g) zorginstelling-zorgverleners en -medewerkers werken samen volgensbepaalde afspraken inzake taakverdeling, etc., soms in een afdeling onderaansturing van een hoofdzorgverlener of -medewerker.

(h) Zorginstelling-zorgverleners en -medewerkers werken altijd onderaansprakelijkheid van de zorginstelling,

(i) de zorginstelling is centraal aansprakelijk voor alle zorgdiensten,

(j) binnen een grote zorginstelling is er altijd een zorginstelling-verantwoordelijke als aanspreekpunt voor een patiënt/cliënt met klachten.

Aldus definiëren we het begrip werkverband als:

• de verantwoordelijkheid van een zorgverlener t.o.v. zijn eventuelezorginstelling m.b.t. het verlenen van zorgdiensten.

De variabele werkverband kan de volgende waarden hebben:

• individuele zorgverlener, voor de zorgpartij die als zelfstandige zorgverlenerbepaalde zorgdiensten verleent en daarvoor volledig verantwoordelijk enaansprakelijk is,

• zorginstelling-verantwoordelijke, voor de zorgpartij die binnen eenzorginstelling de verantwoordelijke is voor de aanstelling van zorgverlenersen medewerkers en wettelijk aansprakelijk is voor hun diensten.

• zorginstelling-zorgverlener, voor de zorgpartij die binnen een zorginstellingverantwoordelijk is voor het verlenen van bepaalde zorgdiensten onderaansprakelijkheid van de zorginstelling,

• zorginstelling-medewerker, voor de zorgpartij die binnen een zorginstellingverantwoordelijk is voor het verlenen van bepaalde ondersteunendediensten onder aansprakelijkheid van de zorginstelling.


Opmerkingen:

• het begrip zorgrelatie is ruimer bedoeld dan het begrip behandelrelatie. Eenzorginstelling-medewerker heeft geen behandelrelatie met eenpatiënt/cliënt, maar wel een zorgrelatie.

• het begrip werkverband staat los van het arbeidsrechtelijk begripdienstverband.

• ad (b) binnen een HAP zijn er medewerkers die werken voor verschillendeindividuele zorgverleners. Die situatie past niet in het bovenstaande model.Het CIBG werkt aan een oplossing.

• ad (d) binnen sommige zorginstellingen, bijv. apotheken, zijn dezorgdiensten zodanig uitgekristalliseerd dat de apotheker de dienstverleningin verregaande mate heeft gedelegeerd aan zijn assistenten.

• ad (e) zorginstelling-afdelingen hebben qua werkverband geen betekenis.Toch zijn ze hier afgebeeld, omdat ze bij de uitwisseling vanpatiëntgegevens geadresseerd moeten kunnen worden, zie paragraaf 3.8.4.

• ad (f) ook artsen die zelfstandig of in een maatschap binnen een ziekenhuiswerken, hebben hun aansprakelijkheid overgedragen aan de zorginstelling-verantwoordelijke.

• het begrip werkverband komt overeen met het begrip role-relationship in[HL7v3].


3.3.3 Samenwerkingsrelatie

Samenwerkende zorgaanbieders zullen vooraf onderling afspraken maken over deverdeling van taken en verantwoordelijkheden, en de wijze van interactie. Dit heeftook invloed op de behandelovereenkomst tussen de patiënt/cliënt en deoorspronkelijke zorgaanbieder:

(a) een zorgaanbieder die in het kader van een behandelovereenkomstverantwoordelijk is voor een bepaalde zorgdienst van een patiënt/cliënt, kandaarbij andere zorgaanbieders betrekken,

(b) de zorgaanbieder kan de patiënt/cliënt voor een bepaalde (vaakspecialistische) zorgdienst verwijzen naar een andere zorgaanbieder meteen bepaalde functie,

(c) de patiënt/cliënt sluit dan met de andere zorgaanbieder een nieuwebehandelovereenkomst, waarmee die andere zorgaanbieder deverantwoordelijkheid voor de verdere zorgdiensten op zich neemt,

(d) de zorgaanbieder kan wegens eigen afwezigheid de overeengekomenzorgdienst laten waarnemen door een andere zorgaanbieder met dezelfdefunctie,

(e) de zorgaanbieder kan binnen het kader van de behandelovereenkomstbepaalde (vaak routinematige) zorgtaken delegeren aan medebehandelaars,terwijl hijzelf als hoofdbehandelaar verantwoordelijk blijft voor de zorgdienstals geheel.

(f) de zorgaanbieder kan tenslotte bepaalde (vaak administratieve)ondersteunende taken delegeren aan medewerkers.

De onderstaande figuur toont deze relaties in een UML class diagram.

Mede-behandelaar

Hoofd-behandelaar

Anderehoofdbeh.

(b) verwijst naarWaarnemer

Patient/cliënt

(d) neemt waar voor

(a)heeft behandel-overeenkomst met

(e)delegeert

zorgtaken aan

(c)sluit nieuwebehandel-overeenkomstmet

Mede-werker

(f)delegeertondersteunende taken aan


Aldus definiëren we het begrip betrokkenheid als:

• de verantwoordelijkheid van een zorgpartij t.o.v. een patiënt/cliënt m.b.t. deovereengekomen zorgdienst.

Deze variabele kan de volgende waarden aannemen:

• hoofdbehandelaar, voor de zorgverlener die een behandelovereenkomstheeft met een patiënt/cliënt, en dus verantwoordelijk is voor deovereengekomen zorgdienst,

• medebehandelaar, de zorgverlener die feitelijk (een deel van) deovereengekomen zorgdienst verleent, in opdracht van de hoofdbehandelaaren dus ook onder diens verantwoordelijkheid,

• medewerker, de persoon die ondersteunende taken verricht ten behoevevan de overeengekomen zorgdienst, in opdracht van de hoofdbehandelaar ofeen medebehandelaar,

• waarnemer, voor de zorgverlener die tijdelijk de verantwoordelijkheid vaneen hoofdbehandelaar overneemt. Na afloop van de waarneming neemt dehoofdbehandelaar gewoonlijk de verantwoordelijkheid voor de resultatenvan de waarnemer over.

Opmerkingen:

• ad (e) bij individuele artsen gaat het meestal om arts-assistenten, dieuitsluitend onder de verantwoordelijkheid van een arts bepaalde zorgtakenmogen uitvoeren. Hier spreekt men van een verlengde arm,

• ad (e) bij afdelingen van ziekenhuizen gaat het meestal om een team vanzorgverleners en medewerkers, die in wisselende samenstelling werken.Daarbij is de taakverdeling sterk afhankelijk van de aanwezigheid van dezorgverleners en medewerkers. Hier spreekt men van een behandelteam,

• voorgaande figuur toont in feite één schakel in de zorgketen die eenpatiënt/cliënt doorloopt. Door de vele specialisaties in de zorg heeft eenpatiënt/cliënt vaak vele schakels nodig. Idealiter zou een patiënt/cliënt zijnzorgketen doorlopen zonder hinder te ondervinden van de aparte schakels,

• momenteel is het vaak de huisarts, als poort van de zorgketen, die voor eenpatiënt/cliënt een bepaalde specialist of ziekenhuis kiest. In de toekomstzullen patiënten/cliënten naar verwachting steeds vaker zelf een keuzemaken.

• een second-opinion arts die door een behandelend arts wordt ingeschakeldkan worden gezien als medebehandelaar. Een second-opinion arts die doorde patiënt/cliënt wordt ingeschakeld buiten de behandelend arts om, geldtniet als zorgverlener. Dit geval is enigszins te vergelijken met die van eenkeuringsarts, zie paragraaf 3.1.3.

• het begrip betrokkenheid komt overeen met het begrip participation in[HL7v3] en het begrip functional role in [prEN13606:2003].


3.4 Vastleggen van patiëntgegevens

De diensten die de verschillende zorgpartijen aan elkaar leveren, leiden tot hetvastleggen van gegevens met betrekking tot die diensten. Hier wordt onderscheidgemaakt tussen:

• patiëntgegevens die voortkomen uit een zorgrelatie,• patiëntgegevens die voortkomen uit een samenwerkingsrelatie.

De onderstaande figuur toont deze relaties tussen zorgpartijen in een UML classdiagram.

Patiënt/cliënt

Zorgaanbieder

Zorgverzekeraar

verle

ent z

orgd

iens

t aan

>

< vergoedt

< vergoedt

betaalt premie aan ><

verg

oedt

werktsamen

met

meldt evt. aan >

Zorgrelatie

Samenwerk.relatie

De volgende paragrafen gaan op beide relaties apart in.


Voor het vastleggen van patiëntgegevens kunnen in de toekomst verscheideneCEN-normen van toepassing worden:

• [prEN 13606:2003] beoogt de normalisatie van de uitwisseling vanpatiëntgegevens, maar stelt indirect ook eisen aan het vastleggen vanpatiëntgegevens. Deze norm is nog in ontwikkeling, maar zal naarverwachting belangrijk worden. Daarom worden de hoofdlijnen uit Part 1:Reference Model nu reeds meegenomen.


3.4.2 Patiëntgegevens voortkomend uit zorgrelatie

Uit de voorgaande paragrafen kan worden afgeleid dat een zorgrelatie leidt tot devolgende patiëntgegevens:

(a) bij het aangaan van een zorgrelatie legt een zorgaanbieder de persoonlijkegegevens van een patiënt/cliënt vast, voorzover niet reeds aanwezig.Persoonlijke gegevens omvatten diens namen, adres, telefoon, etc., maareventueel ook die van zijn familie en zijn verzekeraar(s),

(b) een zorgdienst wordt meestal voorafgegaan en gevolgd door het vastleggenvan logistieke gegevens. Vooraf wordt vaak een bepaalde capaciteitgereserveerd, bijv. een afspraak voor een onderzoek, een reservering vaneen bed in een verpleegtehuis, etc. Achteraf wordt vaak het daadwerkelijkegebruik vastgelegd,

(c) een zorgdienst leidt gewoonlijk tot het vastleggen van medische gegevens(gezondheidsgegevens) over die patiënt/cliënt als neerslag van het resultaatvan die zorgdienst, bijv. een diagnose, onderzoeksuitslag, een behandelplan,etc.,

(d) een zorgdienst wordt uiteindelijk gevolgd door het vastleggen van financiëlegegevens over die patiënt/cliënt, zoals de kosten van de afgenomenzorgdiensten, de daaruit op te maken facturen of declaraties, etc.

De onderstaande figuur toont het verband tussen genoemde objecten in een UMLclass diagram.

Zorgrelatie

leidt tot

(b)

Logistiekegegevens

Financiëlegegevens

(d)

Medischegegevens

(c)

Persoonlijkegegevens

(a)

Patiëntstuk

zijn alle

Dossier

zijn onderdeel van

Alle persoonlijke, logistieke, medische en financiële gegevens met betrekking toteen patiënt/cliënt zijn patiëntgegevens, vastgelegd in diverse soorten van


patiëntstukken. Iedere zorgaanbieder beheert deze patiëntgegevens in een dossier,zie paragraaf 3.5.2.

Vaak worden de identificerende gegevens van alle patiënten/cliënten binnen eenzorgaanbieder verzameld in een patiëntenindex, zodat een bezoekendepatiënt/cliënt snel kan worden opgezocht, zonder alle patiëntdossiers te hoevendoorzoeken.

Binnen zorginstellingen houden afdelingen of zorgverleners vaak eigen dossiers bij,maar worden de identificerende gegevens vaak gedeeld door middel van eencentrale patiëntenindex (CPI) of master patient index (MPI).

Opmerkingen:

• patiënten/cliënten willen graag inzage in hun medische gegevens. In hetgeval dat een patiënt/cliënt meent dat de vastlegging van zijn medischegegevens niet correct is, wil hij dit terugkoppelen met de verantwoordelijkezorgaanbieder.

• naast hun medische gegevens, willen patiënten/cliënten ook graag inzage ingenerieke behandelplannen en -protocollen. Deze gegevens hebben geenbetrekking op individuele patiënten/cliënten en zijn dus geenpatiëntgegevens.

• de bovenstaande indeling in gegevensklassen heeft niet slechts eeninhoudelijke betekenis, maar ook procedurele consequenties. Zo gelden voormedische gegevens strenge privacy-regels en wettelijke bewaartermijnen,zie verder paragraaf 3.5.1. Daarentegen zijn logistieke gegevens minderprivacy-gevoelig en kunnen ze worden verwijderd zodra de desbetreffendeoperationele zaken zijn afgehandeld.

• de bovenstaande indeling in gegevensklassen zegt weinig over de wijzewaarop de gegevens worden gepresenteerd. Zo kunnen bepaalde gegevensmet verschillende invalshoeken worden gepresenteerd, bijvoorbeeld:

o een patiënt/cliënt kan zijn agenda samenstellen uit logistiekegegevens m.b.t. zijn reserveringen van spreekuren van willekeurigezorgaanbieders,

o een zorgverlener kan zijn agenda samenstellen uit logistiekegegevens m.b.t. reserveringen van zijn spreekuren door willekeurigepatiënten/cliënten,

o een zorgcoördinator kan een overzicht van wachtlijsten samenstellenuit logistieke gegevens m.b.t. reserveringen van spreekuren vanwillekeurige zorgaanbieders door willekeurige patiënten/cliënten,

• patiëntgegevens worden vastgelegd in verschillende soorten stukken: vaneenvoudige aantekeningen of vermeldingen in een lijst, tot en met zelfstan-dige documenten en mappen. Meestal worden deze patiëntstukken in eenbepaalde samenhang opgeborgen in een dossier, zie verder paragraaf 3.4.3.

• uit de bovengenoemde gegevens kunnen statistische gegevens wordenafgeleid. Statistische medische gegevens zijn bijvoorbeeld interessant voorwetenschappelijke doeleinden, statistische logistieke gegevens vooroverheidsbeleid en de besturing van zorginstellingen. Idealiter zijn al die


gegevens geaggregeerd tot anonieme gegevens; daarmee zijn ze geenpatiëntgegevens meer.

• een zorgaanbieder beheert tenslotte ook logistieke en financiële gegevensdie geen betrekking hebben op individuele patiënten/cliënten. Ook diegegevens zijn geen patiëntgegevens.

Voor een analyse van de relaties tussen de patiënt/cliënt en de verschillendesoorten zorgaanbieders en de daaruit voortvloeiende vastlegging van informatie, ziehet document [Zorgverlenerwensen].


3.4.3 Structuur van patiëntgegevens

Patiëntgegevens kunnen op verschillende aggregatieniveaus worden gestructureerdals patiëntstuk. Vooral binnen zorginstellingen kan een langdurige behandeling viaverschillende zorgcontacten leiden tot een omvangrijke en ingewikkeldesamenstelling van medische gegevens, waaraan is bijgedragen door vele,verschillende zorgverleners en medewerkers binnen het behandelteam, zie ookparagraaf 3.5.3.

In de geest van [prEN13606:2003] worden aldus de volgende structuren vanpatiëntgegevens onderscheiden:

• patiëntstuk: algemene aanduiding voor een geheel van samenhangendepatiëntgegevens. Vergelijkbaar met EHR_EXTRACT uit [prEN13606:2003].

• patiëntmap: een verzameling samenhangende patiëntdocumenten, bijv.gegroepeerd naar episode, discipline, etc. Vergelijkbaar met FOLDER uit[prEN13606:2003].

• patiëntdocument: een verzameling patiëntgegevensbijdragen die naaraanleiding van een zorgcontact wordt samengesteld. Vergelijkbaar metCOMPOSITION uit [prEN13606:2003] en Clinical_document uit [HL7v3].

• patiëntgegevensbijdrage: een verzameling patiëntgegevenselementen diegedurende een deelcontact wordt bijgedragen. Vergelijkbaar met ENTRY uit[prEN13606:2003] of Act uit [HL7v3]. Deze bijdragen kunnen nader wordengegroepeerd in paragrafen, vergelijkbaar met SECTION uit[prEN13606:2003] en Section uit [HL7v3].

• patiëntgegevenselement: de kleinste verzameling van samenhangendepatiëntgegevens, bijv. een meetwaarde die door één meting wordtvastgelegd. Vergelijkbaar met ELEMENT uit [prEN13606:2003]. Dezeelementen kunnen nader worden gegroepeerd in groepen, vergelijkbaar metCLUSTER uit [prEN13606:2003].

De onderstaande figuur toont de (sterk vereenvoudigde) samenhang tussen al dezeobjecten in een UML class diagram.


Map

Document

Patiëntstuk

*

Bijdrage

*

Element

*

Om de verschillende soorten patiëntstukken te kunnen selecteren uit een dossier enafzonderlijk te kunnen beschouwen, moet ieder patiëntstuk tenminste de volgendegenerieke kenmerken bij zich dragen:

• de onderhavige patiënt/cliënt,• de verantwoordelijke zorgaanbieder en diens discipline,• de gegevenssoort, bijv. adresgegevens, diagnose, labuitslag, factuur,• de tijdsperiode waarop het patiëntstuk slaat,• de episode waartoe het patiëntstuk behoort.

Niet afgebeeld in de figuur is dat tussen de verschillende patiëntstukkenkoppelingen kunnen worden aangebracht, bijv. om ervoor te zorgen dat het enepatiëntstuk altijd in combinatie met een ander stuk wordt geselecteerd enbeschouwd.

Opmerkingen:

• [prEN13606:2003] is nog in ontwikkeling en is daarom niet in alle detailovergenomen. Bovendien wringt deze nog met HL7v3, waardoor patiënt-stukken alleen op het aggregatieniveau patiëntdocument enpatiëntgegevensbijdrage uitgewisseld kunnen worden.

• de bovenstaande structurering zegt weinig over de wijze waaroppatiëntgegevens worden opgeslagen in een dossier, maar wél alles over dewijze waarop de patiëntgegevens zouden moeten kunnen wordenopgeleverd naar buiten. Momenteel heeft iedere zorgaanbieder zijn eigenwijze van structurering van patiëntgegevens. Dit betekent dat diezorgaanbieder een voorziening nodig heeft om patiëntgegevens volgensbovenstaande structurering op te leveren, overigens zondernoodzakelijkerwijs de interne structurering aan te passen.

• het gebruik van episodes ligt in de praktijk erg moeilijk bij drukbezettezorgverleners. Niettemin moet de basisinfrastructuur erop voorbereid zijn,voor het geval zorgverleners toch beginnen met episodes te werken, bijv. inhet kader van de invoering van DBC’s.


• bij elektronische raadpleging is niet altijd goed zichtbaar uit welke originelepatiëntstukken de gepresenteerde patiëntgegevens afkomstig zijn. Voor eendoeltreffende ondersteuning van de zorgaanbieder bij zijn primairezorgtaken is dat ook niet van belang. Echter, wanneer de aansprakelijkheidvan een zorgaanbieder in het geding is, wordt dit juist weer wel belangrijk.


3.4.4 Patiëntgegevens voortkomend uit samenwerkingsrelatie

Uit paragraaf 3.3.3 kan worden afgeleid dat samenwerking tussen zorgaanbiedersleidt tot de volgende patiëntgegevens:

(a) bij het verwijzen naar een andere zorgaanbieder, zal de verwijzendezorgaanbieder gewoonlijk een opdracht formuleren voor die anderezorgaanbieder, bijv. een verwijsbrief voor een specialist,medicatievoorschrift voor een apotheek, aanvraag voor eenlaboratoriumonderzoek, etc.

(b) die andere zorgaanbieder zal na het uitvoeren van de opdracht gewoonlijkeen antwoord sturen. Dit kan het resultaat van de zorgdienst bevatten, bijv.uitslag van een laboratoriumonderzoek, bericht van medicatieverstrekking,etc. Het kan echter ook weigering bevatten, bijv. een specialistenbriefwaarin een ingreep wordt afgeraden.

(c) bij belangrijke, ongeplande gebeurtenissen zullen zorgaanbieders daarvaneen melding vastleggen voor andere geïnteresseerde zorgaanbieders, bijv.een spoedopname in een ziekenhuis, overlijden van een patiënt/cliënt, etc.

De onderstaande figuur toont het verband tussen de genoemde objecten in eenUML class diagram.

Samenwerk.relatie

Opdracht Resultaat Melding

leidt tot

(b) (c)(a)

Patiëntbericht

zijn alle

Postbus

is onderdeel van

Alle opdrachten, antwoorden en meldingen m.b.t. tot een patiënt/cliënt zijnpatiëntgegevens, vastgelegd in patiëntberichten. Ook deze zullen ooit terechtkomenin een dossier, maar voor zover ze nog niet zijn verwerkt en toegedeeld aan hetjuiste dossier, vormen deze als het ware een postbus met werkvoorraad voor dedesbetreffende zorgaanbieder.


Opmerkingen:

• door opdrachten, antwoorden en meldingen op gestructureerde wijze teformuleren, kunnen deze door de ontvangende zorgaanbieder (deels)elektronisch verwerkt worden, en dus handmatige verwerking besparen.Niettemin blijft er ook behoefte aan ongestructureerde berichten.Opdrachten, antwoorden en meldingen kunnen behalve tekst ookmultimediale informatie bevatten.

• Opdrachten, antwoorden en meldingen hebben doorgaans betrekking oppersoonlijke, logistieke, medische en/of financiële zaken, maar hoeven geeninhoudelijke persoonlijke, logistieke, medische en/of financiële details tebevatten. Zo is een antwoord op een labaanvraag vooral een kennisgevingdat een labuitslag beschikbaar is. De uitslag kan reeds bij deze kennisgevinggevoegd zijn, maar in plaats daarvan kan de kennisgeving ook aangevenwaar de uitslag opgehaald kan worden. Zo kan ook een verzoek aangevendat een verwijsbrief klaar ligt om opgehaald te worden.

• momenteel bepalen de zorgverleners nog vaak welke volgende zorgverlenerin de zorgketen wordt gekozen. Naar verwachting zullen patiënten/cliëntenstraks steeds vaker zelf een keuze maken. Door de signalering vanopdrachten, antwoorden en meldingen te ontkoppelen van de inhoudelijkepatiëntgegevens, kunnen de patiëntgegevens straks de patiënt door dezorgketen volgen en niet andersom.

• samenwerking kan tenslotte nog leiden tot nog andere gegevens diegeordend worden vastgelegd, zoals kennisbanken, discussieplatformen, etc.Deze gegevens zijn in beginsel niet gerelateerd aan patiënten en zijn dusgeen patiëntgegevens.

Voor een analyse van de samenwerking tussen de verschillende soortenzorgaanbieders en de daaruit voortvloeiende behoefte aan informatie-uitwisseling,zie het document [Zorgverlenerwensen].


3.4.5 Samenhang tussen patiëntgegevens

Vanuit de patiënt/cliënt gezien is er idealiter één dossier met daarin al zijnpatiëntstukken. Het feit dat zijn zorgaanbieders organisatorisch en geografischverspreid kunnen zijn, en daardoor zijn patiëntgegevens evenzo verspreid enmisschien deels gedupliceerd kunnen zijn, dient transparant te zijn voor depatiënt/cliënt en zijn samenwerkende zorgaanbieders. Aldus is er behoefte aan eenvirtueel patiëntdossier.

Vanuit de patiënt/cliënt gezien is er idealiter ook één postbus voor dezorgaanbieder met daarin al zijn patiëntberichten voor al zijn patiënten/cliënten.Aldus is er ook behoefte aan een virtueel postkantoor.

De onderstaande figuur toont de samenhang tussen al deze objecten in een UMLclass diagram.

Patiëntdossier

Patiëntstuk

Virtueelpatiëntdossier

*

*

Zorgaanb.postbus

Patiëntbericht

Virtueelpostkantoor

*

**

Aldus wordt hier gedefinieerd:

• virtueel patiëntdossier: de verzameling van organisatorisch en geografischverspreide patiëntdossiers die zodanig toegankelijk zijn, als waren zij ééngroot patiëntdossier,

• patiëntdossier: een verzameling van (persoonlijke, logistieke, medischeen/of financiële) patiëntgegevens van één patiënt/cliënt,

• patiëntstuk: geheel van samenhangende patiëntgegevens; hiervan bestaanverschillende soorten, zie paragraaf 3.4.3.

• virtueel postkantoor: de verzameling van organisatorisch en geografischverspreide postbussen die alle zorgaanbieders zodanig bereikbaar maken,als vormden zij één zorgaanbieder,

• zorgaanbiederpostbus: een verzameling van opdrachten, antwoorden enmeldingen gericht aan één zorgaanbieder,

• patiëntbericht: geheel van samenhangende patiëntgegevens dat in hetkader van samenwerking wordt uitgewisseld tussen zorgaanbieders.

Tussen een patiëntstuk en een patiëntbericht kunnen de volgende relaties bestaan:


• een patiëntbericht kan patiëntstukken als uittreksel uit een dossier bevatten,

• een patiëntbericht kan zelf als patiëntstuk worden beschouwd en als zodanigworden opgeborgen in een dossier, bijv. een labuitslag die door de huisartswordt toegevoegd aan zijn dossier.

Opmerkingen:

• [prEN13606:2003] Part 4: Messages zal ingaan op de relatie tussenpatiëntstuk en patiëntbericht, maar Part 4 was nog niet beschikbaar bij hetschrijven van dit document.

• vanuit de verschillende disciplines kunnen zorgaanbieders verschillendeinvalshoeken op het virtuele patiëntdossier creëren, door daaruitpatiëntgegevens met bepaalde kenmerken te selecteren. Op die manierkunnen bepaalde specialistische dossiers worden gedefinieerd, zoals eenverpleegdossier, diabetesdossier, etc. Voor de basisinfrastructuur zijn dieechter niet zichtbaar en worden daarom verder buiten beschouwing gelaten.

• veel ziekenhuizen hebben een elektronisch patiëntdossier (EPD)geïmplementeerd of zijn bezig met het implementeren daarvan. Dit is eenvirtueel patiëntdossier op instellingniveau. In dit document gaat het om eenvirtueel patiëntdossier op nationaal niveau.

• de zorgaanbiederpostbus is in de praktijk niet altijd goed herkenbaar.Zorgaanbieders met een papieren werkstroom hebben gewoonlijk eenpostbak met inkomende berichten. In geval van een elektronischewerkstroom zijn postbussen en berichten vaak niet als zodanig herkenbaar:voor de gebruikers zit alles verborgen in de applicatie. Toch heeft ook eenapplicatie een postbus, in de vorm van een buffer met werkvoorraad.


3.5 Beheren van patiëntgegevens

Patiëntgegevens worden beheerd in patiëntdossiers, maar verschillendezorgpartijen hebben hierop een eigen invalshoek. Deze paragraaf gaatachtereenvolgens in op:

• wettelijke uitgangspunten,• patiëntgegevens gezien vanuit de verantwoordelijke zorgaanbieder,• patiëntgegevens gezien vanuit de zorgverleners en medewerkers,• patiëntgegevens gezien vanuit de patiënt/cliënt.


Voor het beheren en bewaren van patiëntgegevens gelden de volgende wettelijkeregels:

• een zorgaanbieder heeft een dossierplicht tav zijn patiënt/cliënt en isdaarom verantwoordelijk voor het bijhouden van de medische gegevens ineen patiëntdossier.

• alleen een zorgaanbieder mag gezondheidsgegevens beheren. Anderepartijen mogen wel patiëntgegevens verwerken, maar uitsluitend inopdracht van de verantwoordelijke zorgaanbieders. In de terminologie vande WBP treedt deze partij dan op als bewerker van gezondheidsgegevens.

• de patiënt/cliënt heeft recht op inzage, afschrift, aanvulling en vernietigingvan zijn patiëntdossier bij zijn zorgaanbieder.

• de WGBO noemt een bewaartermijn van 15 jaar (gerekend vanaf het tijdstipwaarop de gegevens zijn aangemaakt), maar arts en patiënt kunnenovereenkomen langer te bewaren. Voor patiëntgegevens over genetischeafwijkingen en medische implantaten gelden speciale termijnen.

• de BOPZ kent een minimale bewaartermijn van 5 jaar voor verpleegdossiersen een maximale bewaartermijn van 5 jaar voor afschriften van rechterlijkebeslissingen tot dwangopname, etc. (gerekend vanaf het tijdstip waarop debehandeling is beëindigd).

• de WOG stelt dat apothekers en apotheekhoudende artsen hun recepten 6jaar op geordende en overzichtelijke wijze moeten bewaren.

• de WBP stelt dat gegevens niet langer mogen worden bewaard dannoodzakelijk voor het doel waarvoor de gegevens zijn verkregen.

• de WBP verplicht een zorgaanbieder om zijn patiëntdossier te melden bij hetCBP.

• voor instellingen die onder de Archiefwet vallen (bijv. academischeziekenhuizen) geldt voor een beperkte set gegevens een bewaartermijn van115 jaar.

De WGBO is van 1995, dus zouden in 2005 de eerste patiëntgegevens op grond vanhun maximale bewaartermijn moeten worden vernietigd. Evenwel is in 2005


besloten deze vernietigingsplicht voor 5 jaar te bevriezen, in afwachting van eenwetswijziging om in bepaalde gevallen een langere bewaartermijn te kunnenrealiseren.

De Gezondheidsraad heeft bepaald dat de bewaartermijn van alle patiëntgegevensdie behoren bij een episode, gemakshalve pas ingaat wanneer de behandeling isafgelopen.

Daarnaast gelden vanuit de KNMG de volgende richtlijnen:

• zelfstandige artsen:o hebben toestemming van een patiënt nodig als hij een patiëntdossier

overdraagt aan een opvolger van zijn praktijk, en moeten bijweigering het patiëntdossier blijven bewaren totdat de bewaartermijnis verstreken,

o mogen bij overdracht geen kopieën achterhouden, tenzij die nodigzijn in een juridische procedure,

• artsen in dienst van een zorginstelling:o mogen aan een opvolger volledig toegang verlenen tot een

patiëntdossier, maar de patiënt kan bezwaar aantekenen tegen deopvolging en de overdracht van het dossier,

o moeten een kopie verstrekken, in geval de patiënt kiest voor eenandere zorginstelling, maar het originele patiëntdossier blijft bij deoude instelling, tenzij de patiënt verzoekt deze te vernietigen.

Merk op dat, anders dan vaak gedacht, geen eigenaar van patiëntgegevens isgedefinieerd.


3.5.2 Afhandelen van patiëntgegevens

Voordat patiëntgegevens in een dossier terechtkomen, worden zij gegenereerd,vastgelegd, bewerkt en/of uitgewisseld. Zo heeft een zorgaanbieder in principe:

(a) voor iedere patiënt/cliënt een patiëntdossier, met daarin afgehandeldepatiëntstukken,

(b) één postbus met nog niet afgehandelde patiëntberichten, over verschillendepatiënten/cliënten,

(c) één werkblad met patiëntstukken en patiëntberichten die tijdens eenzorgcontact in bewerking zijn.

De onderstaande figuur toont dit in een UML collaboration diagram.

(d1)selecterenrelevante

stukkenv

Zorgaanbieder

(a) (b) (c)

(d2)presenteren

v

(d3)selecterenrelevanteberichtenv

(d4)presenterenv

(e2)aanmaken

v

(e1)aanmaken

nieuwestukken

v

(e4)aanmakenv

(f1)opbergennieuwestukkenv

(e3)aanmakennieuweberichtenv

(f2)opnemen

v

(f3)opbergen

nieuweberichten

v

(f4)opnemen

v

Patiëntendossier

Zorgaanb.postbus

Bestaandpatiënt

stuk

Bestaandpatiëntbericht

Nieuwpatiëntbericht

Nieuwpatiënt

stuk

Zorgaanb.werkblad

Aldus is de zorgaanbieder, ter ondersteuning van zijn zorgdiensten, bezig met devolgende werkstroom:

(d) aan het begin van een zorgcontact selecteert de zorgaanbieder voor deonderhavige patiënt/cliënt de relevante patiëntstukken uit zijn patiëntdossieren/of de relevante patiëntberichten uit de postbus.

(e) tijdens het zorgcontact maakt de zorgaanbieder nieuwe patiëntstukken enpatiëntberichten aan op zijn werkblad, op basis van patiëntgegevensafkomstig van de patiënt/cliënt of uit bestaande patiëntstukken.

(f) na afloop van het patiëntcontact verstuurt de zorgaanbieder de nieuwepatiëntberichten via de postbus en bergt de afgehandelde patiëntstukken opin het dossier.

(g) niet afgebeeld in de figuur is het feit dat afgehandelde berichten vroeg oflaat ook worden opgenomen in het patiëntdossier.


Elk van de verschillende typen patiëntberichten kan patiëntgegevens bevatten. Zois een labuitslag een antwoord op een labaanvraag, dat aangeeft dat hetlabonderzoek is uitgevoerd, met daarbij gevoegd de resultaten van dat onderzoek.Deze resultaten kunnen worden toegevoegd aan het dossier van de desbetreffendepatiënt/cliënt. Hoewel daarbij vaak ook het begeleidende bericht, en deoorspronkelijke labaanvraag wordt opgeborgen, is dat medisch inhoudelijk minderrelevant.

Zoals nader wordt besproken in een volgende paragraaf, is het eigenlijk nietwenselijk dat patiëntgegevens afkomstig van een bepaalde zorgaanbiedergedupliceerd worden opgeslagen door een andere zorgaanbieder. Wanneer depatiëntgegevens behorende bij een patiëntbericht snel opgevraagd kunnen worden,hoeven ze niet meegestuurd te worden en is een referentie naar de plaats waar zeopgevraagd kunnen worden voldoende.

Opdrachten, antwoorden en meldingen vormen, indien de inhoudelijke gegevens(resultaten) daarvan zijn losgekoppeld, vooral logistieke gegevens, die dezorgverlener helpen zijn dagelijkse gegevensverwerking af te handelen. Naafhandeling is deze informatie voor een patiënt niet meer relevant; maar dezeinformatie is na afhandeling wel interessant om eventueel tactische en strategischebesturingsgegevens van af te leiden.

Opmerkingen:

• Grote zorginstellingen hebben nog veel papieren dossiers. Sommige daarvanbesteden het beheer van patiëntgegevens uit aan gespecialiseerdebedrijven. In het geval van papieren dossiers worden deze gedigitaliseerddoor een dergelijk bedrijf en op verzoek van de zorginstelling weerbeschikbaar gesteld.

• Momenteel voeren zorgaanbieders de gegevens van nieuwepatiënten/cliënten handmatig in, terwijl die gegevens soms elderselektronisch beschikbaar zijn. Bij handmatig invoeren worden onvermijdelijkfouten gemaakt, die uiteindelijk leiden tot dubbele registratie van éénzelfdepatiënt/cliënt, dubbel uitgevoerde onderzoeken, etc. Door elektronischekoppeling van patiëntgegevens moeten deze problemen straks flinkteruggedrongen worden.

• Veel zorgaanbieders houden hun patiëntdossiers liefst in eigen huis, maarelektronische dossiers vergen voorzieningen die door individuelezorgverleners moeilijk op te brengen zijn. Omgekeerd maken elektronischedossiers het mogelijk dat deze individuele zorgverleners daarvoorgezamenlijke voorzieningen nemen. De trend is dat zorgaanbieders steedsnauwer samenwerken in groepspraktijken en gezondheidscentra, waarbijalle patiëntdossiers worden ondergebracht in een gecentraliseerd dossier.Voorbeelden zijn de zogenaamde huisartsenposten (HAP), huisartsen ondereen dak (HOED). Ook daar waar de samenwerkende zorgaanbieders op huneigen locatie blijven, worden steeds meer gecentraliseerde dossiersgebruikt, bijv. voor CVA-ketenzorg, jeugdgezondheidszorg, traumatologie,etc.


3.5.3 Bijhouden van het patiëntdossier

Een zorgaanbieder moet voor iedere patiënt een patiëntdossier bijhouden. In gevalvan een zorginstelling zijn daarbij vele, verschillende zorgverleners enmedewerkers betrokken. Binnen een behandelteam kunnen de taken als volgtworden verdeeld.

Verantwoordelijke(g) bekrachtigt document >

en voegt deze toe aan

Patiëntdocument

Vastlegger

Patiëntgeg.bijdrage

Patiëntendossier

Samensteller(f) fiatteert zijn bijdrage >

aan het document

(e) legt patiëntgegevens >vast als

delegeert (a)zorgtaken aan v

Hoofdbehandelaar

Medewerker

Medebehandelaar

(h)

(h)

Gegevensbron

Patiëntgeg.element(d) genereert patiënt- >

gegevens

Patiënt/cliënt

Vertegenwoordiger

delegeert (b)onderst. taken aan v

(c) laat zichv bijstaan door

B betekent “A kan de rol van B spelen”A

De bovenstaande figuur toont deze taakverdeling in een UML collaboration diagram.

(a) De hoofdbehandelaar delegeert tijdens een zorgcontact enkele zorgtakenaan één of meer medebehandelaars.

(b) Een medebehandelaar verleent tijdens dit deelcontact enkele zorgdienstenaan de patiënt/cliënt en vraagt een of meer medewerkers patiëntgegevensvast te leggen.

(c) Een patiënt/cliënt kan zich tijdens zo’n deelcontact laten bijstaan door diensvertegenwoordiger,

(d) In de rol van gegevensbron leveren de patiënt/cliënt en diens zorgverleners,en eventueel diens vertegenwoordiger, de feitelijke patiëntgegevens.

(e) In de rol van vastlegger legt een medewerker patiëntgegevens vast.Verscheidene medewerkers kunnen een bijdrage leveren aan eenzelfdepatiëntdocument.

(f) In de rol van samensteller fiatteert een medebehandelaar zijn bijdrage aanhet patiëntdocument. Daarbij kan hij aangeven welke andere behandelaarswaren betrokken.


(g) In de rol van verantwoordelijke bekrachtigt de hoofdbehandelaar hetpatiëntdocument en voegt deze toe aan het patiëntdossier. Daarbij kan hijaangeven welke delen van het patiëntdocument ter inzage beschikbaar zijnvoor andere behandelaars.

(h) In geval van een individuele zorgverlener, zal de hoofdbehandelaar de rolvan samensteller en eventueel ook de rol van vastlegger vervullen.

De figuur toont de specifieke situatie voor medische gegevens. In geval vanpersoonlijke, logistieke en financiële gegevens is de situatie vaak minderingewikkeld, maar past deze toch in het bovenstaande stramien.

Opmerkingen:

• Niet afgebeeld is de rol van gegevensonderhavige. Dit is meestal depatiënt/cliënt zelf, maar kan ook een bloedverwant zijn, bijv. in geval vanerfelijke ziekten. Het is belangrijk deze rol te onderkennen, omdat anders bijhet vrijgeven van een patiëntstuk niet alleen de privacy van depatiënt/cliënt, maar ongemerkt ook die van een andere onderhavigebedreigd kan worden.

• De bovenstaande taakverdeling is in de geest van [prEN13606:2003],waarin wordt gesproken over de subject of information(gegevensonderhavige), de information provider (gegevensbron), decommitter (vastlegger), de composer (samensteller) en de authoriser(verantwoordelijke).

• De gegevensbron is de zorgpartij van wie de patiëntgegevens feitelijkafkomstig zijn. Dat kan bijvoorbeeld zijn:

• de patiënt/cliënt die zijn anamnese laat afnemen,• de zorgverlener die de patiënt/cliënt observeert,• de wettelijke vertegenwoordiger van een patiënt/cliënt in coma, de

moeder van een ongeboren patiënt/cliënt, etc.

• De vastlegger is de zorgpartij die de patiëntgegevens feitelijk vastlegt. Devastlegger kan bijvoorbeeld zijn:

• een artsassistente die iets door een arts gedicteerd krijgt,• een medisch apparaat, bijv. een monitor op de intensive care

afdeling,• een receptionist in een ziekenhuis die namens een arts afspraken

inboekt,• de patiënt/cliënt die bijv. zelf een afspraak inboekt.

• De samensteller is de zorgpartij die bepaalt welke patiëntgegevens op welkewijze worden vastgelegd. De samensteller kan bijvoorbeeld zijn:

• in geval van medische gegevens is dat de zorgverlener die alshoofdbehandelaar voor de patiënt/cliënt optreedt,

• De verantwoordelijke is de zorgpartij die wettelijk verantwoordelijk is voorde patiëntgegevens. De verantwoordelijke kan bijvoorbeeld zijn:

• in geval van medische gegevens is dat de zorgverlener die alshoofdbehandelaar voor de patiënt/cliënt optreedt,


• in geval van financiële gegevens kan dat de financieel directeur vaneen ziekenhuis zijn.

• Typische bewerkingen op patiëntstukken zijn: aanmaken, inzien, wijzigen,verwijderen. Medische stukken mogen echter nooit gewijzigd of verwijderdworden, ook niet door de verantwoordelijke. In plaats daarvan mogenpatiëntstukken worden toegevoegd die aangeven dat andere stukken, naarde mening van een verantwoordelijke, niet meer valide zijn. Uitzonderingenzijn wanneer de wettelijke bewaartermijn afloopt of wanneer depatiënt/cliënt zijn gehele dossier vernietigd wil hebben.

• Sommige medische stukken zijn niet bedoeld voor gebruik buiten het zichtvan de verantwoordelijke. Zo houden artsen persoonlijkewerkaantekeningen bij als hulpmiddel bij de oordeelsvorming. Evenzohouden verpleegkundigen het beloop van iedere patiënt op de verpleeg-afdeling bij. Meestal hebben samenwerkende zorgverleners deze tussen-resultaten niet nodig van elkaar. Ook zijn bepaalde gegevenssoortenmoeilijk objectief interpreteerbaar, zoals diagnoses. Daarom kan deverantwoordelijke bij (g) definiëren welke patiëntstukken als uittreksel, ookwel “minimale dataset” genoemd, beschikbaar zijn voor anderen. De“professionele samenvatting” van een huisarts is een voorbeeld van zo’nminimale dataset.

• Zorgverleners hebben soms de behoefte om zeer belangrijkepatiëntgegevens (bijv. een risicovolle besmetting of allergie) te kenmerkenmet een bepaalde prioriteit, vergelijkbaar met de rode stikker in hetpapieren dossier.


3.5.4 Patiëntgegevens gezien vanuit patiënt/cliënt

De patiënt/cliënt heeft ten aanzien van zijn patiëntdossier bij zijn zorgaanbiederwettelijk recht op:

• inzage: wanneer een patiënt/cliënt dat wenst, dient de zorgaanbieder inzagein zijn patiëntdossier te geven. Alleen de persoonlijke werkaantekeningenvan de zorgaanbieder vallen buiten het inzagerecht, zie verder paragraaf3.7.1.

• afschrift: wanneer een patiënt/cliënt dat wenst, dient de zorgaanbieder eenafschrift van zijn patiëntdossier te geven.

• aanvulling: wanneer een patiënt/cliënt het niet eens is met een constateringvan een zorgaanbieder die is vastgelegd in zijn patiëntdossier, heeft hij hetrecht zijn mening daarover toe te voegen aan het patiëntdossier.

• vernietiging: wanneer een patiënt/cliënt wenst dat bepaaldepatiëntgegevens worden vernietigd, zou dit kunnen leiden tot eeninconsistent dossier. Dit is medisch niet aanvaardbaar. Wel kan het geheledossier van een patiënt/cliënt bij een zorgaanbieder worden vernietigd.

Deze rechten kan de patiënt/cliënt niet zelfstandig uitoefenen, hij zal zich moetenwenden tot de verantwoordelijke zorgaanbieder. In de toekomst moet depatiënt/cliënt ook rechtstreeks inzage en afschrift kunnen krijgen. Het is echter nietwenselijk dat de patiënt/cliënt zonder tussenkomst van de zorgaanbieder zijnpatiëntdossier kan vernietigen; daarvoor zal hij zich moeten wenden tot deverantwoordelijke zorgaanbieder.

Daarnaast moet de patiënt/cliënt in het kader van telemedicine ook de mogelijkheidkunnen krijgen tot:

• het zelf maken van afspraken voor een consult,• het vanuit huis dagelijks rapporteren over zijn medicijngebruik of een

ziektebeeld,• het thuis ontvangen van instructies.

De patiënt/cliënt kan deze gegevens in de vorm van een bericht sturen naar debestemde zorgaanbieder of via zijn patiëntkluis ter beschikking stellen aanbelanghebbende zorgaanbieders. Een belanghebbende zorgaanbieder kan naacceptatie van de verantwoordelijkheid de gegevens overnemen in zijnpatiëntdossier.

Tenslotte kan een patiënt/cliënt een zorgaanbieder vragen zijn dossier over tedragen aan een andere zorgaanbieder; dit kan spelen in de volgende gevallen:

• wanneer een patiënt/cliënt gaat verhuizen naar een andere regio,• wanneer een patiënt/cliënt geen vertrouwen meer heeft in een

zorgaanbieder en wil overstappen naar een andere zorgaanbieder.


3.6 Uitwisselen van patiëntgegevens

Wanneer een patiënt/cliënt een zorgketen van verscheidene zorgaanbiedersdoorloopt, volgen de patiëntgegevens idealiter de desbetreffende patiënt/cliënt doorde zorgketen. In de praktijk houden zorgaanbieders de gegevens waarvoor zijverantwoordelijk zijn, bij voorkeur zo dicht mogelijk binnen het eigen bereik.Daarom hebben zorgaanbieders de behoefte aan het uitwisselen vanpatiëntgegevens. Dit kan op twee manieren:

• het versturen van patiëntgegevens (breng-mechanisme)• het opvragen van patiëntgegevens (haal-mechanisme)

Momenteel sturen zorgaanbieders elkaar gegevens toe wanneer dit nodig is (breng-mechanisme). Omdat de ene zorgaanbieder niet precies weet wat de ander nodigheeft, stuurt een zorgaanbieder vaak teveel of te weinig relevante gegevens. Ditleidt bij de andere zorgaanbieder tot allerhande kopieën van gegevens, waarvan deactualiteit en volledigheid niet duidelijk zijn.

Door patiëntgegevens (zie paragraaf 3.4.2) zoveel mogelijk bij deverantwoordelijke zorgaanbieder te laten, maar wel elektronisch toegankelijk temaken voor andere betrokken zorgaanbieders, kunnen de laatsten straks zelfbepalen wélke gegevens zij wannéér willen hebben (haal-mechanisme). Ditvoorkomt onnodig beslag op transmissie- en opslagcapaciteit, vooral bijmultimediale gegevens (beeld, geluid, etc.).

Toch kan het zinvol zijn dat een zorgaanbieder bepaalde opgevraagdepatiëntgegevens (bijv. een labuitslag) opneemt in zijn eigen patiëntdossier binneneen bepaalde context (bijv. een anamnese), indien daarmee toegevoegde waardeontstaat (een labuitslag heeft immers weinig betekenis zonder context).

Niettemin blijft het versturen van gegevens nodig voor ordercommunicatie, bijv. omeen andere zorgaanbieder te attenderen op een opdracht, antwoord of melding (zieparagraaf 3.4.4). Verder kan het opvragen van gegevens handig zijn voor hetvolgen en bewaken van opdrachten, teneinde de patiënt te volgen in de zorgketen.

Tenslotte kan een zorgpartij de verantwoordelijkheid voor bepaaldepatiëntgegevens overnemen van een andere zorgpartij. Dit speelt bij waarnemingen bij overdracht van het gehele patiëntdossier (zie paragraaf 3.5.4). Dit is eenbijzondere vorm van versturen van patiëntgegevens.

Aldus gaat dit hoofdstuk in op:• wettelijke uitgangspunten• het opvragen van patiëntgegevens• het versturen van patiëntgegevens.

Opmerkingen:

• HL7v3 maakt een vergelijkbaar onderscheid tussen de verschillendemanieren van gegevensuitwisseling:

o query (interrogative) versus opvraag en (zoek)resultaato order (imperative) versus opdracht en antwoordo event (declarative) versus melding



Ten aanzien van het uitwisselen van patiëntgegevens geldt dat zorgaanbieders eengeheimhoudingsplicht hebben. De WGBO geeft richtlijnen wanneer zorgaanbiederstoegang mogen geven tot hun dossiers. Die richtlijnen en de consequenties daarvanworden apart uitgewerkt in paragraaf 3.7.

Voor het uitwisselen van patiëntgegevens gelden de volgende wettelijke regels:

• de WBP bepaalt dat een persoonsregistratie niet meer persoonsgegevensmag bevatten dan nodig is voor het doel van die persoonsregistratie.

Voor het uitwisselen van patiëntgegevens kunnen in de toekomst de volgendenormen van toepassing worden:

• [prEN 13606:2003] beoogt de normalisatie van de uitwisseling vanpatiëntgegevens. Deze norm is nog in ontwikkeling, en zal bovendien nogworden geharmoniseerd met HL7. Niettemin worden de hoofdlijnen uit Part1: Reference Model, waar mogelijk, nu reeds meegenomen.


3.6.2 Opvragen van patiëntgegevens

Om toegang tot andermans patiëntdossier te krijgen, zou de andere zorgaanbiederzich rechtstreeks moeten wenden tot de verantwoordelijke zorgaanbieder. Echter,vaak is bij de ene zorgaanbieder niet eens bekend welke andere zorgaanbiedersgegevens over een bepaalde patiënt/cliënt hebben. Daarom is er behoefte aan:

• een verwijsindex die aangeeft welke gegevens over een patiënt/cliëntbeschikbaar zijn en uit welk dossier die opgevraagd kunnen worden,

• een schakelpunt als centraal toegangspunt voor patiëntgegevens uit alleaangesloten dossiers.

Patiëntendossier

(a)bijhoudenpatiëntgegevens >

Schakelpunt

^(e)opzoekendossiers (d)

opvragen< patiëntgegevens

Verwijsindex

AndereZorgaanbieder

(f)opvragen uitvermeldedossiersv

^(c)

aanmeldendossier

(g) virtueel patiëntendossier

(b)aanmeldenpatiëntgegevens >

VerantwoordelijkeZorgaanbieder

Patiënt/cliënt

(h)opvrageneigengegevensv

De bovenstaande figuur toont de werking daarvan in een UML collaborationdiagram:

(a) de verantwoordelijke zorgaanbieder houdt de patiëntstukken van zijnpatiënten/cliënten bij in zijn eigen dossier.

(b) de verantwoordelijke zorgaanbieder meldt aan het schakelpunt van welkepatiënten/cliënten stukken beschikbaar zijn in zijn dossier.

(c) het schakelpunt legt de beschikbaarheid van die patiëntstukken in datdossier vast in de verwijsindex.

(d) andere betrokken zorgaanbieders willen stukken van een bepaaldepatiënt/cliënt opvragen, ongeacht in wélke dossiers die stukken liggen enrichten zich daarom tot het schakelpunt,


(e) het schakelpunt raadpleegt de verwijsindex om te weten in welke dossiersde gevraagde patiëntstukken te vinden zijn.

(f) het schakelpunt vraagt vervolgens de gevraagde patiëntstukken op bij allein de verwijsindex vermelde dossiers en schakelt de respons door naar deopvragende zorgaanbieder.

(g) als zodanig fungeren de verwijsindex, het schakelpunt en alle aangeslotenpatiëntdossiers tezamen als één virtueel dossier; dit wordt het virtueelpatiëntdossier genoemd.

(h) op dezelfde wijze kan ook de desbetreffende patiënt/cliënt in de toekomsttoegang tot zijn eigen gegevens krijgen.

Het virtueel patiëntdossier kan bestaan uit één landelijke verwijsindex, of meerdereverwijsindices die onderling naar elkaar doorverwijzen. Dat is voor de gebruikersechter transparant, en daarom ook niet zichtbaar in de figuur. Dit concept kan eengroeiscenario mogelijk maken, waarbij wordt begonnen met enkele regionalevirtuele dossiers, die vervolgens met elkaar versmelten tot één virtueel dossier,door de verwijsindices onderling te koppelen. Uiteindelijk zou dit kunnendoorgroeien naar één landelijke verwijsindex. NICTIZ heeft inmiddels gekozen voorde invoering van één landelijke verwijsindex.

Opmerkingen:

• ad (a) Ook als samenwerkende zorgaanbieders een gecentraliseerd dossiergebruiken (zie paragraaf 3.5.2) heeft iedere zorgaanbieder een deel daarvanonder zijn verantwoordelijkheid.

• ad (b) Conform paragraaf 3.4.3 kan een zorgaanbieder hier helepatiëntdocumenten aanmelden of de afzonderlijke bijdragen of elementen.Dit hangt af van het belang van de context waarin die patiëntgegevensbeschouwd moeten worden. Dit kan verschillen per zorgtoepassing engegevenssoort.

• ad (b) De verschillende afdelingsdossiers van een ziekenhuis kunnen iederafzonderlijk worden aangesloten op de verwijsindex. Ook is het mogelijk datde afdelingsdossiers binnen het ziekenhuis worden gekoppeld aan eeninterne verwijsindex, waarbij de laatste als toegangspunt dient. In dat gevalfungeert het ziekenhuisdossier ook als een virtueel patiëntdossier, maar datis transparant voor het landelijke patiëntdossier.

• ad (c) Bij het aanmelden van patiëntstukken aan de verwijsindex is het zéérbelangrijk dat een unieke identificatie van de patiënt/cliënt wordtgehanteerd. Een dergelijk uniek patiëntnummer zal ook moeten wordengebruikt bij het opvragen van patiëntstukken, zie verder paragraaf 3.8.2.Het koppelen van bestaande patiëntstukken aan een nieuw uniekpatiëntnummer is geen sinecure, bijv. wegens de vele dubbele enonherleidbare verwijzingen naar patiënten/cliënten die dan boven waterzullen komen.

• ad (d) Het opvragen van patiëntstukken kan in theorie op verschillendeaggregatieniveaus (zie paragraaf 3.4.3), maar wordt uiteindelijke beperktdoor de aggregatieniveaus waarin ze zijn aangemeld bij (b). Zo kan iemand


die een bloedsuikerspiegel wil weten, genoodzaakt zijn een heellaboratoriumverslag op te vragen. Een zorgtoepassing kan ervoor zorgen datdaaruit alleen de interessante gegevens worden geselecteerd engepresenteerd. Zo kan iedere zorgtoepassing een eigen invalshoekpresenteren.

• ad (e) De verwijsindex is aan te merken als een persoonsregistratie, dezemag op grond van de WBP niet méér persoonsgegevens bevatten dan nodigis voor het doel van de verwijsindex.

• ad (e) Het opvragen van patiëntgegevens is in theorie ook mogelijk zonderverwijsindex. Echter, gezien de vele tienduizenden zorgaanbieders inNederland zou een opvraag leiden tot het uitvragen van even zoveledossiers, wat zou leiden tot onnodig veel verkeer van gegevens. Doel van deverwijsindex is dus het doelmatig uitvragen van alleen díe dossiers diemogelijk de gevraagde gegevens bevatten.

• ad (f) De doelmatigheid van het uitvragen is groter naarmate de opvraagnauwkeuriger wordt geformuleerd aan de hand van de gegevenssoort, dediscipline, de tijdsperiode, etc. Daarvoor is het wel nodig dat bij aanmeldingvan patiëntstukken diezelfde karakteristieken worden vermeld in deverwijsindex. Echter, niet alle bestaande patiëntdossiers kennen dezekarakteristieken, de verwijsindex moet daarmee rekening houden.

• ad (f) Voor een zorgaanbieder kan het waardevol zijn om uit de verwijsindexeen overzicht van beschikbare gegevenssoorten op te vragen over eenpatiënt/cliënt, alvorens inhoudelijke patiëntgegevens op te vragen.

• ad (g) Wanneer wordt begonnen met het virtuele patiëntdossier, kan hetjaren duren voordat alle zorgaanbieders hun patiëntdossier hebbenaangesloten. Eenmaal aangesloten kunnen wellicht ook niet alle patiënt-stukken worden aangemeld in de verwijsindex. Tenslotte zijn er nog denodige papieren dossiers. Om te voorkomen dat in deze overgangsfasebepaalde cruciale verwijzingen ontbreken in de verwijsindex, kan wordenbesloten belangrijke patiëntstukken toch aan te melden in de verwijsindex,als “beschikbaar op papier”. Wanneer een ander na opvraag deze meldingkrijgt, kan hij besluiten de verantwoordelijke zorgaanbieder telefonisch teraadplegen.

• ad (h) Wanneer patiënten/cliënten eenmaal de mogelijkheid krijgenelektronisch de eigen gegevens op te vragen, dreigt de situatie dat zijmassaal hun zorgaanbieders gaan bellen voor uitleg. Patiënten/cliëntenzullen daarom specifieke sturing en ondersteuning nodig hebben. Dat wordtin deze versie van dit document niet verder uitgewerkt.

• Zoals gesteld aan het begin van paragraaf 3.6, moet het hiergepresenteerde haal-mechanisme voorkomen dat zorgaanbieders deopgevraagde patiëntstukken lokaal gaan opslaan. Dit kopiëren kan alleenworden voorkomen als een zorgaanbieder erop kan vertrouwen dat debenodigde patiëntstukken altijd beschikbaar zijn. Dit stelt hoge eisen aan deafzonderlijke patiëntdossiers. Websites op het Internet vormen wat datbetreft een slecht voorbeeld.


3.6.3 Versturen van patiëntgegevens

Om patiëntberichten (met een opdracht, antwoord of melding, zie paragraaf 3.4.4)te kunnen versturen naar een andere zorgaanbieder), moet de verantwoordelijkezorgaanbieder precies weten wáár en hóe die ander bereikbaar is. Daarom is erbehoefte aan:

• een zorgaanbiedergids die aangeeft welke zorgaanbieders beschikbaar zijnmet welke zorgdiensten en hoe zij bereikbaar zijn,

• een schakelpunt als gemeenschappelijk verzamelpunt voor uitgaande post(vgl. de rode brievenbus op de hoek van de straat) voor alle te versturenpatiëntberichten,

• een postbus als individueel verzamelpunt voor inkomende post (vgl. degroene brievenbus bij de huisdeur) voor iedere zorgaanbieder.

Zorgaanb.postbus

Schakelpunt

Zorgaanb.gids

AndereZorgaanbieder

VerantwoordelijkeZorgaanbieder

Patiënt/cliënt

(g)stureneigen

gegevensv

(b)sturenpatiëntgegevens >

^(d)

attenderenzorgaanbieder

(c)afleverenin vermeldepostbusv

(f) virtueel postkantoor(a)opzoekenzorgaanbieder >

(e)aanmelden

< postadres

De bovenstaande figuur toont de werking daarvan in een UML collaborationdiagram:

(a) de verantwoordelijke zorgaanbieder raadpleegt de zorgaanbiedergids omeen zorgaanbieder met een bepaalde specialisatie te vinden en vervolgensdiens postadres.

(b) de verantwoordelijke zorgaanbieder stuurt patiëntberichten met vermeldingvan de bestemde zorgaanbieder naar het schakelpunt.

(c) het schakelpunt levert de patiëntberichten af in de postbus van de bestemdezorgaanbieder.


(d) de postbus attendeert de bestemde zorgaanbieder op het beschikbaarkomen van bepaalde patiëntberichten.

(e) de bestemde zorgaanbieder dient zijn postadres vooraf te hebbenaangemeld in de zorgaanbiedergids.

(f) als zodanig fungeren de zorgaanbiedergids, het schakelpunt en alleaangesloten postbussen tezamen als één virtueel postkantoor voor alle teversturen berichten.

(g) op dezelfde wijze kan ook de desbetreffende patiënt/cliënt zijn eigenberichten sturen naar zijn zorgaanbieders.

(h) in de toekomst kan de desbetreffende patiënt/cliënt zelf een postbus openenom in het kader van telemedicine instructies te ontvangen van zijnzorgaanbieder.

Net als voor het virtuele patiëntdossier, kunnen meerdere regionale virtuelepostkantoren doorgroeien naar een landelijk virtueel postkantoor. NICTIZ heeftinmiddels gekozen voor de invoering van één landelijk postkantoor.

Opmerkingen:

• ad (b) Bij het versturen van een patiëntbericht kan een bestaandpatiëntstuk, bijv. een labuitslag, worden meegestuurd. Dat patiëntstuk is inprincipe een kopie, want het origineel blijft bij de verantwoordelijkezorgaanbieder. De ontvangende zorgaanbieder kan de inhoud van hetpatiëntbericht opnemen in zijn eigen dossier, bijv. als onderdeel van eenander patiëntstuk, maar dan wel aangemerkt als kopie. Voor hetpatiëntbericht zelf ligt dat anders: bijv. een labaanvraag voor eenlaboratorium is behalve een onderzoeksvoorstel, ook een verzoek aan hetlaboratorium om het onderzoek uit te voeren. Daarbij is sprake van eenoverdracht van de uitvoeringsverantwoordelijkheid aan dat enelaboratorium, waaraan bepaalde bevoegdheden, maar ook financiëleconsequenties zijn verbonden.

• ad (b) In de praktijk kan het gebeuren dat een zorgaanbieder een opdrachtklaarzet, maar deze niet kan versturen, omdat de patiënt/cliënt nog zelf debestemde zorgaanbieder wil uitkiezen. Bijv. een huisarts die niet weet aanwie hij een medicatievoorschrift moet sturen, omdat zijn patiënt/cliënt nogniet weet bij welke apotheek hij de medicijnen wil afhalen. In dat geval kande ongeadresseerde opdracht worden aangemeld in de verwijsindex, zodatdit patiëntbericht later door een andere zorgaanbieder kan wordenopgevraagd, zie verder Bijlage B.

• ad (d) Na ontvangst van een patiëntbericht met een opdracht, kan deandere zorgaanbieder besluiten een patiëntbericht met een antwoord op dieopdracht terug te sturen. Op deze wijze kunnen zorgtoepassingentransacties tussen zorgaanbieders afhandelen. Het schakelpunt kan destatus van deze transacties niet bijhouden, want het transactiemechanismeverschilt per zorgtoepassing en gegevenssoort.


• ad (b) en (d) Een bijzonder geval van versturen van patiëntgegevens is hetoverdragen van de verantwoordelijkheid van patiëntstukken aan een anderezorgaanbieder, zie ook paragraaf 3.5.4. Dit speelt bijv. in de volgendegevallen:o een zorgaanbieder wiens patiënten zijn behandeld door een

waarnemer, zal de relevante patiëntstukken willen overnemen van diewaarnemer,

o een zorgaanbieder kan op verzoek van een patiënt/cliënt diens geheledossier overdragen aan een andere zorgaanbieder.

Het gaat hier om een verzoekbericht van de ene zorgaanbieder aan de anderom de verantwoordelijkheid van één of meer patiëntstukken over te nemen.Nadat de ander een antwoordbericht met acceptatie heeft teruggestuurd,kan de eerste zorgaanbieder deze patiëntstukken afmelden en de ander dezeaanmelden in de verwijsindex. Als onderdeel van deze transactie wisselt destatus van het patiëntstuk bij de een van origineel naar kopie, bij de anderprecies andersom.

• ad (c) een zorgaanbieder kan verschillende postbussen hebben voorverschillende soorten berichten, bijv.:

o ongestructureerde berichten die via het internet komen vanvrijblijvende afzenders (bijv. patiënten),

o HL7v3-gestructureerde berichten die van vertrouwde zorgaanbiederskomen en automatisch verwerkt kunnen worden.

• ad (c) bij het versturen van patiëntgegevens is de toegevoegde waarde vaneen centraal schakelpunt minder duidelijk dan bij het opvragen vanpatiëntgegevens. Immers, zorgaanbieders kunnen elkaar ook rechtstreeksstukken toesturen, desnoods per e-mail. Echter, een centraal schakelpuntspeelt hier de rol van een betrouwbare intermediair die kan garanderen datverstuurde gegevens daadwerkelijk worden afgeleverd bij de bestemming,ook als die tijdelijk niet bereikbaar is, zie ook paragraaf 3.7.3.

• wanneer patiënten/cliënten eenmaal de mogelijkheid krijgen elektronischberichten te versturen naar zorgaanbieders, bestaat het gevaar datzorgaanbieders worden geconfronteerd met vele onbegrijpelijke verzoeken.Patiënten/cliënten zullen daarom specifieke sturing en ondersteuning nodighebben, bijv. door het toepassen van elektronische formulieren. Dat wordtin deze versie van dit document niet verder uitgewerkt.


3.7 Beschermen van patiëntgegevens

Patiëntgegevens zijn zeer privacygevoelig. Daarom is het uitwisselen vanpatiëntgegevens gebonden aan zeer strenge regels. Deze paragraaf gaatachtereenvolgens in op:

• wettelijke uitgangspunten,• autoriseren van zorgaanbieders,• loggen van de toegang,• delegeren aan medewerkers.


Ten aanzien van patiëntdossiers hebben de zorgpartijen de volgende rechten enplichten uit hoofde van de WGBO:

(a) een zorgaanbieder heeft een beroepsgeheim en mag anderen dus geentoegang geven tot patiëntgegevens die onder zijn verantwoordelijkheidvallen, met de onderstaande uitzonderingen.

(b) de patiënt/cliënt heeft recht op inzage, afschrift, aanvulling en vernietigingvan zijn dossier bij die zorgaanbieder.

(c) een verantwoordelijke zorgaanbieder mag alleen toegang totpatiëntgegevens verlenen aan waarnemers en rechtstreeks bij debehandeling betrokken zorgaanbieders, voor zover noodzakelijk. Eenpatiënt/cliënt kan niettemin bezwaar maken.

(d) voor andere dan rechtstreeks bij de behandeling betrokken zorgaanbieders,dient de verantwoordelijke zorgaanbieder toestemming te hebben van depatiënt/cliënt voor het verlenen van toegang tot diens patiëntgegevens aandie zorgaanbieders.

(e) een patiënt/cliënt heeft weliswaar een informatieplicht aan de betrokkenzorgaanbieder, maar die kan dit niet afdwingen. Bovendien kan eenpatiënt/cliënt op ieder moment een gegeven toestemming intrekken.

(f) in noodgevallen (bijv. een patiënt/cliënt in kritieke toestand, gewetensnoodvan een zorgaanbieder, etc.) mag een zorgaanbieder alle restrictiesomzeilen en toegang tot alle noodzakelijke patiëntgegevens krijgen.


De onderstaande figuur toont dit in een UML collaboration diagram.

Patiëntendossier

Rechtstreeksbetrokken

zorgaanbieder

Verantwoordelijkezorgaanbieder

Patiënt/cliënt

(b)heeft

recht op inzage,afschrift, aanvulling

en vernietigingv

(c)toegangzonder

toestemmingvoorzover

noodzakelijkv

< mogen in noodgevallen (f)restricties omzeilen

(d) vraagt toestemming >

< heeft informatieplicht (e)

(a)heeftberoeps-geheimv

Overigebetrokken

zorgaanbieder

(d)toegang

alleenmet

toestemmingvan

patiënt/cliëntv

Opmerkingen:

• ad (a) volgens de WGBO vallen “persoonlijke werkaantekeningen” van eenzorgaanbieder buiten het inzagerecht voor zover het gaat om “indrukken,vermoedens of vragen die bij de hulpverlener leven” en niet om “gegevens”.Sommige zorgaanbieders informeren elkaar over bijv. agressief gedrag vanhun patiënten/cliënten, deze worden soms ten onrechte als “persoonlijkewerkaantekeningen” beschouwd.

• ad (b) het vernietigingsrecht van een patiënt/cliënt geldt alleen voor zijngehele dossier bij een bepaalde zorgaanbieder, inclusief de eventuelereferenties in een toegangslog. Omdat een patiënt/cliënt later spijt kankrijgen van een dergelijke beslissing, moet dit op een reversibele manierkunnen geschieden, waarbij de sleutel uitsluitend in handen van depatiënt/cliënt blijft.

• bij (b) kan de inzage door de desbetreffende patiënt/cliënt worden beperktindien daardoor de privacy van een derde gegevensonderhavige (zieparagraaf 3.4.3) zou worden geschaad. Voor minderjarige patiënten/cliëntendragen hun ouders of voogden de genoemde rechten en plichten.

• bij (c) geeft de WGBO geen nadere omschrijving van de term “rechtstreeksbij de behandeling betrokken”, maar hier wordt dit als volgt opgevat:

o bij “rechtstreeks … betrokken” gaat het om medebehandelaars die inopdracht van de hoofdbehandelaar handelen,

o bij “andere dan rechtstreeks … betrokken” gaat het om anderehoofdbehandelaars naar wie de patiënt/cliënt wordt verwezen doorde oorspronkelijke hoofdbehandelaar.

• bij (c) geeft de WGBO ook geen nadere omschrijving van de term“noodzakelijk”, maar hier wordt dit als volgt opgevat: welke gegevens heefteen zorgaanbieder in een bepaalde functie nodig om zijn patiënt/cliënt in hetkader van een bepaalde zorgvraag adequaat te helpen.

• bij (d) kan de zorgaanbieder deze toestemming per kéér, maar ookeenmalig vóóraf vragen. Met de juiste voorlichting aan de patiënt/cliënt kaneen zorgaanbieder in bepaalde gevallen ook impliciete toestemming


veronderstellen. Blijft het feit dat een patiënt/cliënt in alle gevallen dietoestemming alsnog kan weigeren.

• bij (f) geldt dat sommige patiëntgegevens zo privacygevoelig zijn, dat dezealleen met expliciete toestemming vrijgegeven kunnen worden.

• de WGBO heeft betrekking op gezondheidsgegevens. Het gaat hier dus ommedische gegevens, en niet zozeer om persoonlijke, logistieke en financiëlegegevens. Toch kan het logistieke gegeven dat iemand een afspraak heeftmet een psychiater worden opgevat als een gezondheidsgegeven.


Voor het beschermen van patiëntgegevens kunnen in de toekomst de volgendenormen van toepassing worden:

• [prEN 13606:2003] beoogt de normalisatie van de uitwisseling vanpatiëntgegevens. Part 3: Distribution Rules gaat in op toegangsbeperking,maar dit deel is nog verre van compleet. Daarvan kon dus nog weinigworden overgenomen.

• ISO TC 215/WG4 werkt aan een norm voor Privilege Management andAccess Control, maar is alleen gericht op het koppelen van tweeverschillende domeinen met een eigen beveiligingsbeleid. Dit document richtzich echter op Nederland als één domein. De norm zou daarom pas vanbelang worden als de basisinfrastructuur wordt gekoppeld met buitenlandsezorgsystemen.

3.7.2 Autoriseren van zorgaanbieders

Wanneer een andere zorgaanbieder patiëntgegevens wil opvragen, moet de voordie patiëntgegevens verantwoordelijke zorgaanbieder strikt genomen voorindividuele gevallen persoonlijk bepalen:

• heeft de andere zorgaanbieder een behandelrelatie?• is de andere zorgaanbieder rechtstreeks betrokken?• is er toestemming of bezwaar van de patiënt/clië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 opvragendezorgaanbieder zal geen direct antwoord krijgen als de verantwoordelijkezorgaanbieder niet bereikbaar is (afwezig, even van zijn plaats, wil niet gestoordworden, etc.) en/of als de toestemming van de patiënt/cliënt nog gevraagd moetworden. De winst van elektronische uitwisseling van patiëntgegevens zou daarmeeteniet worden gedaan.

Daarom is het wenselijk deze controle zoveel mogelijk automatisch te latenverlopen. Daarvoor is het in theorie nodig dat de verantwoordelijke zorgaanbiederelk van de bovenstaande criteria vooraf vastlegt. Echter, in de dynamische praktijkvan de zorg kan een zorgaanbieder niet altijd van tevoren bepalen wélke anderezorgaanbieders zullen worden betrokken, vooral wanneer de patiënt/cliënt zelf zijnzorgaanbieders wil kiezen. Daarom kunnen sommige criteria niet tijdig wordenvastgelegd, zie verder paragraaf 3.7.3.

Wel zal het in de meeste gevallen mogelijk zijn het volgende autorisatie-mechanisme te hanteren in combinatie met logging.


Patiëntendossier


Patiënt/cliënt

(d)laat zijntoestemmingvastleggenv

(b)gaan

akkoordmet

v

(h)bepaaltuiteindelijkzelf wietoegangkrijgtv

Autorisatieprotocol

Autorisatieprofiel

(e) informeert overbehandeling >

Samenwerkendezorgaanbieders

informeren over (c)< verwijsindex

Schakelpunt

(f)laat zijn

eventuelebezwaren

vastleggenv

(j) hebben betrekking op

v

Verwijsindex

(a)komen

onderlingovereen

v

Belangenverenigingen

(i) wel/niet aanmeldenof afschermen >

< laat specifieke (g)gegevens

afschermen

De bovenstaande figuur toont het autorisatiemechanisme in een UML collaborationdiagram.

(a) beroepsverenigingen van zorgaanbieders formuleren in overleg metbelangenverenigingen van patiënten/cliënten een autorisatieprotocol, waarinstaat wélke soorten patiëntgegevens een zorgaanbieder, op grond van zijnfunctie, nodig kan hebben voor een adequate behandeling.

(b) samenwerkende zorgaanbieders die willen aansluiten op hetzelfdeschakelpunt moeten akkoord gaan met het autorisatieprotocol en verklarendat zij patiëntgegevens alleen zullen opvragen in het kader van eenbehandelrelatie.

(c) samenwerkende zorgaanbieders die hun patiëntdossiers hebben aangeslotenop hetzelfde schakelpunt, informeren hun patiënten/cliënten wanneer zij hunpatiëntgegevens aanmelden bij de verwijsindex.

(d) patiënten/cliënten kunnen het al of niet akkoord gaan met elektronischeuitwisseling van hun patiënt-/cliëntgegevens, centraal (laten) vastleggen ineen autorisatieprofiel.

(e) bij iedere zorgvraag informeert de verantwoordelijke zorgaanbieder zijnpatiënt/cliënt over welke andere zorgaanbieders in het kader van debehandeling toegang tot zijn patiëntgegevens zullen krijgen.

(f) patiënten/cliënten kunnen wensen of bezwaren m.b.t. bepaaldezorgaanbieders die wel of geen toegang mogen krijgen, centraal (laten)vastleggen in het autorisatieprofiel.

(g) patiënten/cliënten kunnen specifieke patiëntgegevens laten afschermen doorde zorgaanbieder zelf.


(h) de verantwoordelijke zorgaanbieder blijft aanspreekbaar op zijnberoepsgeheim. Daarom moet hij ongeacht het autorisatieprotocol en hetautorisatieprofiel uiteindelijk zelf kunnen bepalen welke gegevensopvraagbaar zijn.

(i) dit kan de zorgaanbieder bepalen door het wel of niet aanmelden vanpatiëntgegevens bij de verwijsindex in combinatie met het vrijgeven ofafschermen van specifieke gegevens voor opvraag door anderezorgaanbieders.

(j) het autorisatieprotocol en de autorisatieprofielen hebben betrekking op allepatiëntdossiers die zijn aangesloten op het schakelpunt, behalve dat iederautorisatieprofiel betrekking heeft op de patiëntdossiers van éénpatiënt/cliënt.

(k) in gevallen waarvoor dit autorisatiemechanisme niet werkt, zal het bij hetopvragen van patiëntgegevens mogelijk moeten zijn expliciete toestemmingvan de verantwoordelijke zorgaanbieder te vragen.

Opmerkingen:

• ad (a) de invulling van het autorisatieprotocol is geen sinecure. Het kanenige tijd duren voordat de koepelverenigingen hierover volledigeovereenstemming bereiken, daarom wordt het protocol incrementeelingevuld naar de behoefte van de landelijke toepassingen, te beginnen metEMD en WDH.

• ad (a) een strak autorisatieprotocol heeft het nadeel dat een zorgverlener inonvoorziene omstandigheden geen toegang tot patiëntgegevens kan krijgen,terwijl dat toch noodzakelijk is, bijv. in levensbedreigende gevallen. Voordergelijke noodsituaties moet er de mogelijkheid zijn het autorisatieprotocolte doorbreken.

• bij (b) is het wenselijk dat zorgaanbieders ervoor tekenen dat degenen diepatiëntgegevens opvragen zich aansprakelijk stellen voor eventueelmisbruik, opdat de verantwoordelijke zorgaanbieder zoveel mogelijk wordtgevrijwaard van aanspraken op zijn beroepsgeheim. Zonder deze waarborgzullen zorgaanbieders hun patiëntdossiers minder gauw willen aansluiten ophet schakelpunt.

• met (b) wordt tevens het probleem omzeild dat alle behandelrelaties meteen patiënt/cliënt niet tijdig vooraf vastgelegd kunnen worden. Overigensspeelt dit probleem op kleinere schaal ook binnen ziekenhuizen. Daarworden vaak slimme oplossingen gebruikt, bijv. door een elektronischvastgelegde afspraak van een patiënt/cliënt met een zorgverlener tebeschouwen als blijk van een behandelrelatie. Die afspraak moet dan weldoor een onafhankelijke, bevoegde partij worden vastgelegd. Op landelijkeschaal is deze oplossing vrijwel niet haalbaar.

• bij (b) zal het autorisatieprotocol alleen betrekking hebben op zorgverlenersen niet op hun medewerkers. In paragraaf 3.7.4 wordt beschreven hoe ookmedewerkers als “verlengde arm” van een zorgverlener kunnen optreden.


• bij (c) is het informeren van patiënten/cliënten noodzakelijk op grond van deWBP, omdat de inhoud van de verwijsindex als persoonsgegevens kanworden aangemerkt. Bij voorkeur doen alle zorgaanbieders in een regio ditgecoördineerd en sturen zij gezamenlijk één brief per patiënt/cliënt,eventueel gecombineerd met de uitgifte van een landelijk of regionaalpatiëntnummer, zie paragraaf 3.8.2. In theorie zou dit aanmelden bij deverwijsindex, en dus ook het informeren van de patiënt/cliënt, kunnenwachten tot de eerstvolgende keer dat de patiënt/cliënt naar eenzorgaanbieder gaat. Echter, dit zou voor vele patiënten/cliënten betekenendat, in afwachting van die eerstvolgende keer, hun patiëntgegevens innoodgevallen niet kunnen worden opgevraagd.

• bij (d) kan met de juiste voorlichting goedkeuring worden verondersteld,tenzij een patiënt/cliënt bezwaar maakt. Deze aanpak is doeltreffender danandersom, want vele patiënten/cliënten zullen het nalaten om te reageren.

• bij (e) zou de zorgaanbieder zijn patiënt/cliënt idealiter moeten informerenover:

• welke andere zorgaanbieders kunnen worden betrokken bij debehandeling,

• welke zorgaanbieders onderling elektronische patiëntgegevenskunnen uitwisselen en wat daarvan de voordelen zijn,

• welke soorten gegevens die andere zorgaanbieders op grond van hunrol dan mogen inzien, onder verwijzing naar het autorisatieprotocol,

• welke keuzemogelijkheden de patiënt/cliënt hierin heeft,• welke verdere technische voorzieningen (beveiliging, logging) worden

gebruikt om de privacy van de patiënt/cliënt te waarborgen,• welke controle-, bezwaar- en beroepsmogelijkheden de patiënt/cliënt

heeft.In de praktijk heeft een zorgverlener helemaal geen tijd om dit expliciet metiedere patiënt/cliënt door te nemen. In plaats daarvan kan hij zijnpatiënten/cliënten impliciet informeren via een folder en/of affiche in dewachtkamer.

• bij (f) kan het autorisatieprofiel door de zorgaanbieder worden vastgelegd,maar in de praktijk zal die daar geen tijd voor hebben. Daarom is er eenandere partij nodig die dit voor de patiënten/cliënten vastlegt, want dan iseen patiënt/cliënt niet afhankelijk van een drukke zorgaanbieder omeenmaal gegeven toestemming weer te kunnen intrekken. Als in detoekomst de e-NIK beschikaar is, kunnen patiënten/cliënten zelf hun wensenvia het internet vastleggen.

• bij (f) is het goed denkbaar dat een patiënt/cliënt alleen de hem bekende ofbehandelende zorgverleners toegang wil geven. Op het moment dat hijonverwacht een nieuwe zorgverlener bezoekt, blijkt dat die zorgverlener zijnpatiëntgegevens niet kan inzien. De patiënt/cliënt wil die zorgverleneralsnog toegang geven, maar kan dat ter plekke niet, want daarvoor moet hijeerst terug naar de beheerder van het autorisatieprofiel. Wanneer de e-NIKis ingevoerd komen er mogelijkheden voor de patiënt/cliënt om ter plekkeeen zorgverlener toestemming te geven.


• bij (f) kan de patiënt/cliënt bijvoorbeeld wensen dat hij niet wil dat eenbepaalde zorgaanbieder (bijv. een buurman die toevallig zorgverlener is)inzage krijgt in zijn patïentgegevens. Dit is een alles-of-niets kwestie: hijkan níet selectief aangeven dat voor die zorgverlener alleen gevoeligepatiëntgegevens (bijv. mbt. psychiatrie, HIV-besmetting, abortus) wordenuitgesloten.

• bij (g) kan de patiënt/cliënt onder begeleiding van de zorgaanbieder wélselectief aangeven dat hij bepaalde gevoelige patiëntgegevens wil latenafschermen, maar dan voor alle andere zorgaanbieders. De zorgaanbiederkan de patiënt/cliënt dan wijzen op de consequenties, bijvoorbeeld dat eenopvragende zorgaanbieder zou worden geconfronteerd met onvolledigepatiëntgegevens, terwijl juist de gevoelige gegevens vaak cruciaal zijn voorandere zorgaanbieders.

• bij (h) kan een zorgaanbieder uiteindelijk zelf bepalen, in hoeverre hijtegemoet komt aan de wensen van een patiënt/cliënt. Desnoods kan hij eenlastige patiënt/cliënt de simpele keuze voorleggen: wél of níet meedoen metelektronische uitwisseling van patiëntgegevens.

• ad (i) het aanmelden van patiëntgegevens aan de verwijsindex is net zogevoelig als het opvragen van patiëntgegevens. Ook deze handeling isvoorbehouden aan de verantwoordelijke zorgverleners.

• ad (j) het autorisatieprotocol en het autorisatieprofiel zijn slechts eenhulpmiddel en hebben juridisch geen betekenis. De zorgaanbieder blijftverantwoordelijk om voor individuele gevallen te beoordelen. Hetautorisatieprotocol is echter nodig als vertrouwenwekkende basis, opdatafzonderlijke zorgaanbieders bereid zullen zijn hun patiëntdossiers aan tesluiten op het schakelpunt. Evenzo is het autorisatieprofiel nodig ompatiënten/cliënten te overtuigen dat ze akkoord kunnen gaan metelektronische uitwisseling van hun patiëntgegevens. Het alternatief zou zijndat iedere zorgaanbieder zelf vastlegt welke andere zorgaanbieders toegangtot zijn dossier krijgen, zoals dit in sommige regionale toepassingen wordtgeregeld. Op kleine schaal kan dat werken, maar op landelijke schaal wordtdit onbeheersbaar voor de zorgaanbieders en ondoorzichtig voor depatiënt/cliënt.

• hoewel het hier beschreven autorisatiemechanisme vooral is bedoeld voorhet opvragen van patiëntgegevens, kan dit mechanisme evengoed wordentoegepast voor het versturen van patiëntgegevens.

• hoewel het hier beschreven autorisatiemechanisme vooral is bedoeld voor deuitwisseling van medische gegevens, kan dit mechanisme evengoed wordengebruikt voor persoonlijke, logistieke en financiële gegevens.

• het autorisatieprotocol en –profiel zijn in principe bedoeld voor de landelijkeuitwisseling van patiëntgegevens. Echter, als landelijk verkregenpatiëntgegevens lokaal worden opgeslagen binnen een zorginstelling,kunnen die gegevens alsnog in verkeerde handen vallen, bijv. als binnen dezorginstelling geen interne autorisatie is geregeld of als die interneautorisatie in strijd is met de landelijke autorisatie. Zie verder paragraaf3.7.4.


Openstaande punten:

• bij (b) kan het noodzakelijk zijn dat alle zorgverleners afzonderlijk moetentekenen. Dit kan betekenen dat bij het schakelpunt moet worden vastgelegdwelke zorgverleners hebben getekend en alleen dan deze zorgverleners methun UZI-pas toegang tot het schakelpunt kunnen krijgen.


3.7.3 Loggen van toegang

Van de criteria genoemd in de vorige paragraaf kunnen de volgende meestal niettijdig vooraf worden vastgelegd:

• behandelrelatie: welke zorgverlener de behandelrelatie met eenpatiënt/cliënt aangaat, is vaak afhankelijk van de beschikbaarheid binnen degekozen zorginstelling en/of de keuze van de patiënt/cliënt. Bovendien zoude patiënt/cliënt expliciet een behandelovereenkomst met deze zorgverlenermoeten sluiten, maar in de praktijk wordt de overeenkomst vaak nietformeel vastgelegd.

• betrokkenheid: welke medebehandelaars door de hoofdbehandelaar zullenworden betrokken bij de behandeling, is ook sterk afhankelijk van hunbeschikbaarheid op dat moment. Vaak is er geen tijd om de preciezebetrokkenheid van iedere medebehandelaar vast te leggen. in principe mageen hoofdbehandelaar zonder toestemming van de patiënt eenmedebehandelaar en medewerker toegang tot diens gegevens verlenen,maar in de praktijk is dat moeilijk per geval vast te leggen wie dat precieszijn. Wel kan een zorgverlener vooraf collega’s mandateren die ooit alsmedebehandelaar of medewerker zullen optreden, maar dit is geen sluitendeoplossing.

• noodsituatie: als een zorgverlener bepaalde patiëntgegevens nodig blijkt tehebben waarvoor hij niet geautoriseerd is, kan hij contact opnemen met dedaarvoor verantwoordelijke zorgaanbieder. In een noodsituatie is daarvoormeestal geen tijd en moet hij het autorisatieprotocol kunnen doorbreken.

In plaats daarvan moet een zorgaanbieder ervoor tekenen, dat hij de bovenstaandecriteria zal respecteren wanneer hij via het schakelpunt patiëntgegevens opvraagtuit andermans patiëntdossier. Om misbruik te voorkomen moet deze belofte welgecontroleerd en gesanctioneerd kunnen worden. Daarvoor is het nodig alletoegang te loggen.

Patiëntendossier


Anderezorgaanbieder

Schakelpunt

(a)maakttoegankelijkvoor anderezorgaanbiedersv

Toegangslog

(f)controleert

v

Toezichthouder

(c) logt al het opvragen in >

(b)vraagtpatiëntgegevensop viav

< vraagt om verantwoording (g)

Patiënt/cliënt

(d1)controleert

v

< kan klagen bij (e1)

(h) logt al het versturen in >

(d2) controleert >

(e2) kan klagen bij >

< waarschuwt eventueel (i)

De bovenstaande figuur toont het loggen van toegang in een UML collaborationdiagram:


(a) een verantwoordelijke zorgaanbieder maakt zijn patiëntdossiers toegankelijkvoor andere zorgaanbieders, op voorwaarde dat die daarvan geen misbruikmaken.

(b) een andere zorgaanbieder vraagt patiëntgegevens op via het schakelpunt.Hierbij zal hij de reden van het opvragen kunnen aangeven: wegens welkezorgvraag, vanuit welke betrokkenheid, eventuele noodsituatie.

(c) het schakelpunt houdt bij in een toegangslog welke patiëntgegevens doorwelke zorgaanbieder zijn opgevraagd.

(d) een patiënt/cliënt (maar ook de verantwoordelijke zorgaanbieder) kan detoegangslog raadplegen om te controleren welke andere zorgaanbieders zijnpatiëntgegevens hebben ingezien.

(e) een patiënt/cliënt (maar ook de verantwoordelijke zorgaanbieder) die meentdat andere zorgaanbieders onnodig toegang hebben gehad, kan daaroverklagen bij de toezichthouder. In alle gevallen kan hij zijn autorisatieprofiel(laten) aanpassen.

(f) de toezichthouder zal na klachten, maar ook op eigen initiatief, detoegangslog raadplegen om te verifiëren of zorgaanbieders inderdaadonbevoegd toegang hebben gehad tot patiëntgegevens.

(g) de toezichthouder zal zonodig de desbetreffende zorgaanbieders omverantwoording vragen en kan in een uiterst geval de zorgaanbieder latenuitsluiten van het virtuele patiëntdossier, dan wel juridische stappenondernemen. Daarbij kan de behoefte ontstaan om de betwiste opvraagopnieuw te doen, waarbij de omstandigheden van de oorspronkelijkeopvraag gereconstrueerd worden.

(h) verder kan ook het versturen van patiëntgegevens worden gelogd in detoegangslog, opdat patiënten/cliënten volledig inzicht kunnen krijgen in deuitwisseling van hun patiëntgegevens. Ook de toezichthouder kan invoorkomende gevallen behoefte hebben om alle uitwisseling tereconstrueren.

(i) het is mogelijk dat de toegangslog zelf automatisch gaat zoeken naarverdachte opvraagpatronen en zonodig het schakelpunt waarschuwt, opdatdie laatste de verdachte bron kan blokkeren.


Opmerkingen:

• bij (a) is het cruciaal dat de samenwerkende zorgaanbieders elkaarvertrouwen. Zonder vertrouwen zal een zorgaanbieder aarzelen om zijnpatiëntdossier toegankelijk te maken voor andere zorgaanbieders. Vooral alszorgaanbieders onderling (moeten gaan) concurreren, is dit cruciaal.Wellicht is het verstandig te beginnen in regionale samenwerkings-verbanden, die onderling pas aansluiten wanneer daarvoor voldoendevertrouwen bestaat.

• bij (c) geldt voor logging hetzelfde als voor autorisatie: behalve de landelijkemoet ook de interne uitwisseling van patiëntgegevens worden gecontroleerd,bijv. tussen afdelingen binnen een ziekenhuis. Immers, als een zorgverlenerrechtmatig bepaalde patiëntgegevens landelijk heeft opgevraagd, maar dezevervolgens onrechtmatig intern heeft doorgestuurd, moet dit achterhaaldkunnen worden.

• Ad (d) zolang de patiënt/cliënt geen rechtstreekse toegang heeft tot detoegangslog, zal hij zijn afzonderlijke zorgaanbieders moeten vragen wieinzage heeft gehad in zijn patiëntgegevens.

• bij (d) is behalve de passieve logging ook actieve logging denkbaar, bijv.:o wanneer een andere zorgaanbieder patiëntgegevens opvraagt, krijgt

de verantwoordelijke zorgaanbieder daarvan automatisch eenbericht,

o wanneer een zorgaanbieder een beroep doet op een noodgeval,wordt de desbetreffende patiënt/cliënt automatisch ingelicht.

Dit wordt in deze versie van dit document niet verder uitgewerkt.

• bij (e) kan de patiënt/cliënt ook eerst naar de verantwoordelijkezorgaanbieder stappen, maar omdat andere zorgaanbieders zich hebbenverplicht tot uitsluitend bevoegd gebruik, zijn die andere zorgaanbieders alseerste aanspreekbaar. Voor de patiënt/cliënt is het belangrijk dat er eenduidelijk en onafhankelijke aanspreekpunt is: de toezichthouder.

• bij (f) is het belangrijk dat de toezichthouder zodanig actief optreedt, datzorgaanbieders nooit het gevoel zullen krijgen dat ze ongecontroleerd eenberoep op een noodgeval kunnen doen. Anders bestaat het gevaar dat, alshet hek eenmaal van de dam is, zo vaak een beroep op een noodgeval zalworden gedaan, dat een toezichthouder deze gevallen niet meer allemaalkan uitzoeken.

• ad (g) behalve in autorisatiekwesties, kan de toegangslog ook wordengeraadpleegd om te controleren of een zorgaanbieder bij een bepaaldebehandeling heeft nagelaten bepaalde patiëntgegevens op te vragen. Alduszou de toezichthouder door de rechter kunnen worden gevraagd denagelaten opvraag te doen, waarbij de omstandigheden gereconstrueerdmoeten worden zoals die waren tijdens de betwiste behandeling. Op dezewijze zou kunnen worden bepaald of de zorgaanbieder door het nalaten vande opvraag, bepaalde cruciale patiëntgegevens zou hebben gemist, zie[Tijdmachine].


• Het is te verwachten dat de toegangslog op termijn voor allerlei praktischezaken zal worden benut. Bijvoorbeeld een patiënt/cliënt die zijn patiënt-dossier bij een bepaalde zorgaanbieder wil laten vernietigen, maar ook wilachterhalen bij welke andere zorgaanbieders eventuele kopieën van diepatiëntstukken kunnen liggen.

• Ad (h) dit wordt belangrijk wanneer een zorgaanbieder cruciale patiënt-gegevens heeft verstuurd naar een andere zorgaanbieder, terwijl de laatstebeweert niets te hebben ontvangen. In dat geval kan de toegangslog wordengeraadpleegd om te bepalen of de verstuurde patiëntgegevensdaadwerkelijk zijn afgeleverd bij de andere zorgaanbieder.

• Bij (h) kan de toezichthouder willen reconstrueren wat een zorgaanbiederheeft gezien bij het opvragen van een index van beschikbare gegevens-soorten. Dergelijke opvragingen moeten dus ook worden gelogd.

• Ad (i) voorbeelden van verdachte opvraagpatronen zijn: een zorgverlenervraagt binnen een bepaald tijdsbestek patiëntgegevens op van meerpatiënten/cliënten dan hij redelijkerwijs kan behandelen in dat tijdbestek;vanuit een zorginstelling worden patiëntgegevens opgevraagd, terwijl diezorginstelling voor de onderhavige patiënt/cliënt nog nooit patiëntgegevensheeft aangemeld.

• de toezichthouder kan op afstand functioneren, door operationele taken tebeleggen bij logbeheerders, al dan niet via een lokale onafhankelijkevertegenwoordiger bij ieder schakelpunt. Voor de rol van onafhankelijketoezichthouder moet nog een partij worden gevonden. Het CBP en de IGZzijn hiervoor momenteel niet toegerust.


3.7.4 Delegeren aan medewerkers

Zoals beschreven in paragraaf 3.3.3, kan een zorgaanbieder als hoofdbehandelaarbinnen het kader van een behandelovereenkomst bepaalde taken delegeren aanzijn medebehandelaren en medewerkers, de zogenaamde “voorbehoudenhandelingen” (ook wel “verlengde arm” genoemd). Die taken omvatten zowelzorgtaken als ondersteunende taken, waaronder het vastleggen, beheren enuitwisselen van patiëntgegevens. De hoofdbehandelaar blijft echterverantwoordelijk.

Voor het lokaal vastleggen en beheren van patiëntgegevens kan een zorginstellingeen interne autorisatietabel hanteren om de bevoegdheden van zorgverleners enmedewerkers te regelen conform de WGBO. In geval van een ziekenhuis zal dezetabel veel fijnmaziger zijn dan het landelijke autorisatieprotocol, onder meer doorde differentiatie van functies naar bijv. SEH-verpleegkundige, stomaverpleeg-kundige, etc.

Voor het landelijk uitwisselen van patiëntgegevens geldt het landelijke autorisatie-protocol. Daarin worden medebehandelaren met wettelijk beschermde beroepstitels(bijv. verpleegkundige, verloskundige, etc.) geautoriseerd op basis van hun functie.Daarentegen worden medewerkers zonder beschermde beroepstitel (bijv. co-assistent, doktersassistent, etc.) niet genoemd in het landelijke autorisatieprotocol.

Daarom is een mechanisme noodzakelijk waarmee een hoofdbehandelaar zijnmedewerkers kan mandateren om namens hem patiëntgegevens landelijk uit tewisselen. Langs deze weg kan een hoofdbehandelaar eventueel ook mede-behandelaren mandateren indien het landelijke autorisatieprotocol hun onvoldoendetoegang geeft.

Patiëntendossier

Hoofdbehandelaar

(b)legt vast wie namens hèmlandelijk patiëntgegevensmag uitwisselenv

(e)legt bevoegdheden vast

mbt vastleggen enbeheren patiëntgegevens

v

Mandateringstabel

Schakelpunt

(d) verdeelt verantwoordelijkheden over >

Autorisatietabel

(h)heeft betrekking op

v

(g)heeft betrekking opv

< zijn gemandateerd voor toegang tot (c)

< zijn geautoriseerd voor toegang tot (f)

Zorginstellingverantwoordelijke

Medebehandelaar

Medewerker

(a) delegeert taken aan >

De bovenstaande figuur toont het delegatiemechanisme in een UML collaborationdiagram.


(a) de hoofdbehandelaar delegeert bepaalde taken aan zijn medebehandelarenen medewerkers.

(b) de hoofdbehandelaar legt overeenkomstig in een mandateringstabel vast wienamens hèm landelijk patiëntgegevens mag uitwisselen.

(c) aldus worden medebehandelaren en medewerkers gemandateerd voortoegang tot het schakelpunt voor het uitwisselen van patiëntgegevens.

(d) in geval van een zorginstelling worden zorgverleners aangesteld in eenbepaalde functie en worden verantwoordelijkheden verdeeld overzorgverleners en medewerkers.

(e) overeenkomstig wordt in een interne autorisatietabel vastgelegd welkebevoegdheden zorgverleners en medewerkers krijgen m.b.t. de lokalepatiëntdossiers.

(f) aldus worden zorgverleners en medewerkers geautoriseerd voor toegang totde lokale patiëntdossiers.

(g) de lokale mandateringstabel heeft betrekking op het landelijk schakelpunt.

(h) de interne autorisatietabel, indien aanwezig, heeft betrekking op de lokalepatiëntdossiers.

Opmerkingen:

• ad (a) hoewel deze taakverdeling per zorgcontact anders kan zijn, zal in depraktijk vaak een karakteristiek samenwerkingspatroon ontstaan, bijv. in devorm van behandelteams.

• ad (b) deze mandateringstabel kan dus specifiek pèr zorgverlener (alshoofdbehandelaar) aangeven welke zorgverleners (als medebehandelaar) enmedewerkers gemandateerd worden voor het uitwisselen van welke soortenpatiëntgegevens.

• ad (c) met deze mandatering kan een medebehandelaar of medewerkerhandelingen uitvoeren die anders zijn voorbehouden aan dehoofdbehandelaar.

• ad (d) in een ziekenhuis is het vaak de medische directeur die, in overlegmet een staf van specialisten, de bijbehorende bevoegdheden bepaalt.

• ad (e) de invulling van de interne autorisatie is de verantwoordelijkheid vande zorginstelling en zal vaak wezenlijk verschillen van de landelijkeautorisatie. Bijvoorbeeld omdat in een ziekenhuis aan de hand van deagenda of de dossiers kan worden gecontroleerd of een zorgverlener eenbehandelrelatie heeft met een patiënt/cliënt. Om te voorkomen dat landelijkuitgewisselde patiëntgegevens alsnog in verkeerde handen kunnen vallen,dient te worden gecontroleerd dat een zorginstelling adequate interneautorisatie heeft geregeld, maar is de wijze waarop niet belangrijk.


• ad (g) ten behoeve van autorisatie en logging, zal een gemandateerdeuitvoerder (binnen HL7v3 “author or performer” genoemd) altijd moetenaangeven namens welke mandaterende zorgverlener (binnen HL7v3“overseer” genoemd) hij handelt. In geval van behandelteams moet dan welduidelijk worden bepaald welke zorgverlener als hoofdbehandelaar optreedt.

• ad (h) hoe de logging van toegang tot het lokale patiëntdossier wordtgeregeld, is de verantwoordelijkheid van de zorginstelling.


3.8 Bereiken van zorgpartijen en patiëntgegevens

Om goed te kunnen samenwerken met andere zorgaanbieders in de zorgketen, ishet voor een zorgaanbieder belangrijk dat hij:

• zijn patiënt/cliënt uniek kan identificeren,• andere zorgaanbieders uniek kan identificeren,• de juiste patiëntdossiers en postbussen kan adresseren.


Voor een goede landelijke samenwerking van zorgpartijen is het belangrijk datzowel patiënten/cliënten als hun zorgaanbieders uniek kunnen wordengeïdentificeerd. Daarom heeft het ministerie van VWS besloten tot invoering van:

• een landelijk patiëntnummer in de vorm van het Burger Service Nummer(BSN). De nummers worden onder verantwoordelijkheid van het ministerievan BZK gegenereerd door een Beheer Voorziening BSN (BVBSN) op basisvan de Gemeentelijke Basis Administraties (GBA’s) en een toekomstigRegister Niet-Ingezetenen (RNI). De nummers worden per overheidssectorbeschikbaar gesteld via een Sectorale BerichtenVoorziening (SBV), zie[BSN].

• een landelijk zorgverlenernummer, ook wel Unieke Zorgverlener Identificatie(UZI) genoemd, voor iedere zorgaanbieder die elektronisch patiëntgegevenswil uitwisselen. Deze nummers worden tezamen met vertrouwensmiddelen(UZI-passen) beschikbaar gesteld via een landelijk zorgaanbiederregister(UZI-register), zie [UZI].

• een landelijk zorgverzekeraarnummer, ook wel Unieke ZorgverzekeraarIdentificatie (UZOVI) genoemd, voor iedere zorgverzekeraar die elektronischpatiëntgegevens wil uitwisselen. Deze nummers zijn reeds beschikbaar viaeen landelijk zorgverzekeraarregister (UZOVI-register). Later zullen ookvertrouwensmiddelen (UZOVI-passen) beschikbaar worden gesteld.

Wettelijke regelingen voor deze nummers en registers worden momenteelopgesteld in een voorstel voor de “Wet gebruik BSN in de zorg”. Tevens komt ereen AMvB voor het experimenteren met het SoFi-nummer zolang het BSN er nogniet is.

Het ministerie van Economische Zaken werkt momenteel aan een wet voor hetBasisBedrijvenRegister (BBR). Volgens deze wet zullen alle zorgaanbieders moetenworden geregistreerd in het BBR. Momenteel zijn zorginstellingen reedsgeregistreerd in het Handelsregister van de KvK, maar individuele zorgverlenersnog niet, zie paragraaf 3.1.

Op grond van de WBP zullen het patiëntenregister en het zorgaanbiederregistermoeten worden aangemeld bij het CBP, en zullen de geregistreerde personenmoeten worden geïnformeerd.


Opmerkingen:• het BSN komt voort uit het advies van de Commissie Van Thijn over het

persoonsnummerbeleid, zie [Persoonsnummerbeleid]. Dat advies voorzagook in een apart Zorg Informatie Nummer (ZIN) voor de zorgsector, maarom reden van doelmatigheid is daarvan afgestapt.

• ziekenfondsen gebruiken van oudsher het SoFi-nummer voor de identificatievan patiënten en de gegevensuitwisseling daarover met partijen in hetsociaal-fiscale domein. Aangezien het BSN wordt afgeleid van het SoFi-nummer, wordt bijna automatisch een uniforme aanpak gerealiseerd.

• NICTIZ gaat uit van een succesvolle invoering van het BSN in de zorg eneen succesvolle uitrol van UZI-passen ten behoeve van het virtuelepatiëntdossier en het virtuele postkantoor. In principe zou debasisinfrastructuur ook moeten kunnen werken met andere identificatie- enauthenticatiestelsels. Daarom worden de bedrijfsprocessen in de navolgendeparagrafen op generieke wijze beschreven, zonder vooruit te lopen op de deSBV-Z en het UZI-register.

• er zijn discussies over een register voor partijen uit het zogenoemde “vierdedomein”. Dit betreft onder meer zorgverleners die niet in het UZI-registerstaan, maar wel het BSN moeten gebruiken, bijv. ten behoeve van hetdeclaratieverkeer. Deze problematiek wordt samen met die van de UZOVI-passen behandeld in een ander project


3.8.2 Identificeren van patiënten/cliënten

Wanneer samenwerkende zorgaanbieders van een bepaalde patiënt/cliënt dienspatiëntgegevens wil vastleggen, opvragen, versturen, etc. is het zéér belangrijk datzij steeds dezelfde patiënt/cliënt voor ogen hebben. Daarom is een landelijkpatiëntnummer nodig. Een patiëntnummer kan op de volgende wijze wordenuitgegeven en gebruikt.

Zorgaanbieder Patiënt/cliënt

Patiëntenregister

(e)kan zijn

bereikbaarheidsgegevens< (laten) vastleggen inPatiënten

adresboek

(d)kan patiënt/cliënt identificeren via >

(b) informeert over patiëntennummer ^

(f)kan bereikbaarheidsgegevensvan patiënt/cliënt opvragen via >

BronRegister

(bijv. GBA)(a)meldt (potentiële) patiënten/cliënten aan bijv

< kan zich met patiëntennummer identificeren bij (c)

De bovenstaande figuur toont het gebruik van een patiëntenregister en -adresboekin een UML collaboration diagram:

(a) vanuit een bepaald bronregister worden patiëntnummers gegenereerd vooreen bepaalde groep (potentiële) patiënten/cliënten, deze nummers wordenvastgelegd in een patiëntenregister.

(b) de desbetreffende (potentiële) patiënten/cliënten worden geïnformeerd overhun patiëntnummer.

(c) een patiënt/cliënt kan zich bij een zorgcontact identificeren met zijn patiënt-nummer en/of andere identificerende gegevens.

(d) de zorgaanbieder kan het patiëntnummer opvragen of verifiëren bij hetpatiëntenregister op basis van enkele identificerende gegevens(geboortenaam, -datum, -plaats, etc.).

(e) eventueel kan een patiënt/cliënt zijn bereikbaarheidgegevens (actuelenaam, postadres, telefoonnummer, etc.) vastleggen of laten vastleggen ineen patiëntenadresboek.

(f) een zorgaanbieder kan het patiëntenadresboek raadplegen wanneer die eenpatiënt/cliënt wil bellen of bepaalde gegevens wil toesturen.


Opmerkingen:

• ad (a) de overheid heeft besloten dat het BSN mag worden gebruikt in dezorgsector als patiëntnummer. Volgens de plannen van de overheid zal hetBSN worden gegenereerd door de BVBSN op basis van de LandelijkRaadpleegbare Deelverzameling (LRD) van de GBA’s. Er wordt gewerkt aaneen “Wet Gebruik BSN in de Zorg”, afgekort WGBZ, die de rechten enplichten van de betrokken zorgpartijen gaat regelen.

• ad (a) het CIBG is aangewezen als beheerder van de SBV voor dezorgsector, ook wel SBV-Z genoemd. Het is nog de vraag of deze partijrelaties met individuele patiënten/cliënten zal aangaan. Het loket voorburgers om mutaties aan te melden blijft in principe het gemeentehuis, danwel een elektronisch loket.

• ad (b) de patiënt/cliënt zal moeten worden geïnformeerd over het doel vanhet patiëntnummer en het mogelijke gebruik daarvan voor elektronischeuitwisseling van patiëntgegevens. Daarom is dit tevens het moment om depatiënt/cliënt toestemming te vragen voor elektronische uitwisseling vandiens patiëntgegevens, zie paragraaf 3.7.2.

• ad (c) momenteel kunnen zorginstellingen hun patiënten/cliënten vragen omlegitimatie. Het BSN zal worden vermeld op Wettelijke IdentificatieDocumenten (WID) en zal waarschijnlijk ook op veilige wijze wordenvastgelegd op de e-NIK, een elektronisch vertrouwensmiddel, dat deoverheid in de toekomst wil uitgeven aan iedere burger, zie paragraaf 3.9.2.

• ad (c) een zorgaanbieder heeft pas voordeel bij het gebruik van eenlandelijk patiëntnummer wanneer hij en de samenwerkende zorgaanbiedersalle patiëntgegevens hebben gekoppeld aan deze nummers, zie paragraaf3.6.2. Dat koppelen is geen sinecure, daarvoor zal het BPR de faciliteitbieden om de bestaande patiënten van een zorgaanbieder bestandgewijs tekoppelen. Omdat een dergelijke migratie lang kan duren, moet ermeerekening worden gehouden dat verschillende nummers ofidentificatiemethoden naast elkaar gehanteerd moeten kunnen worden:

o op instellingniveau,o op regionaal of categoraal niveau,o op landelijk niveau.

• ad (d) momenteel worden patiënten/cliënten veelal geïdentificeerd aan dehand van hun NAW en geboortedatum. Dat gaat vaak niet goed, omdat deNAW-gegevens nogal veranderlijk zijn. Daarentegen zijn geboortenaam,-datum, –plaats onveranderlijk en dus betrouwbaarder als identificerendkenmerk. Anderzijds hebben veel zorginstellingen de identificatie op huneigen manier geoptimaliseerd, zo heeft een huisarts vaak genoeg aan eennaam en geboortedatum, terwijl een ziekenhuis veel meer identificerendekenmerken nodig heeft. Het is dus niet wenselijk alle zorginstellingendezelfde identificatiemethode op te dringen.

• ad (d) nadat een zorgaanbieder eenmaal het BSN van een patiënt/cliëntheeft opgevraagd of geverifieerd bij de SBV-Z, kan de zorgaanbieder datBSN overnemen in zijn eigen patiëntdossier, zodat bij een volgendzorgcontact de SBV-Z niet opnieuw hoeft te worden geraadpleegd.


• ad (d) in theorie zou het mogelijk zijn op basis van het BSN van een burgerdiens identificerende gegevens op te vragen bij een SBV. De SBV-Z biedtdeze mogelijkheid niet, om te voorkomen dat zorgaanbieders blind gaanvertrouwen op het BSN dat op het WID staat vermeld.

• bij (d) zal blijken dat niet alle patiënten/cliënten in het landelijkepatiëntenregister gevonden kunnen worden, omdat:

o de patiënt/cliënt (nog) geen BSN heeft,o de patiënt/cliënt onjuiste identificerende gegevens opgeeft,o de patiënt/cliënt niet bij kennis is.

In dergelijke gevallen moet een tijdelijk patiëntnummer aangemaakt kunnenworden. Dat nummer moet voor ingezetenen van Nederland en hen die datalsnog worden (ongeborenen, pasgeborenen, asielzoekers, toeristen), latervervangen kunnen worden door het landelijke patiëntnummer.

• ad (e) in plaats van dat iedere zorgaanbieder voor zich een patiënten-adresboek bijhoudt, zou de actualiteit van de bereikbaarheidsgegevens betergediend zijn met een gezamenlijk adresboek dat door patiënten/cliënten kanworden bijgewerkt. Als de GBA ooit als patiëntenadresboek gaat fungeren, ishet belangrijk dat burgers bij de GBA een alternatief adres kunnenvastleggen. Immers, veel mensen zijn niet bereikbaar op hun formelewoonadres, vooral langdurig zieken verblijven elders.

• ad (f) momenteel zijn vele zorginstellingen bezig met een aansluiting op deGBA, om zo altijd over de actuele NAW-gegevens van een patiënt te kunnenbeschikken. Echter, niet alle zorginstellingen hebben recht op toegang totGBA-gegevens. Als de GBA een authentiek register wordt, zal het gebruikvan GBA-gegevens verplicht worden. Dat betekent ook dat de GBA deafnemers van GBA-gegevens actief moet informeren over wijzigingen, bijv.adreswijzigingen.


3.8.3 Identificeren van zorgaanbieders

Wanneer twee zorgaanbieders onderling willen samenwerken en patiëntgegevenswillen uitwisselen, is het zéér belangrijk te weten wie inhoudelijk verantwoordelijkis voor die patiëntgegevens en of de ander geautoriseerd is voor het inzien van diepatiëntgegevens . Daarom is een landelijk zorgaanbiedernummer nodig. Eenzorgaanbiedernummer kan op de volgende wijze worden uitgegeven en gebruikt.

Zorgaanbieder

Zorgaanb.register

Zorgaanb.gids

(a)kan zich registreren bij >

(c)kan zijn zorgdiensten enbereikbaarheidsgegevenspubliceren in >

BronRegister

(BIG of CvZ)

(b)dient evt. te zijningeschreven bij >

AndereZorgaanbieder

Patiënt/cliënt

(e)kan zorgaanbieder

< identificeren via

(f)kan bereikbaarheidsgegevens

< van zorgaanbieder opvragen via

kan overzicht van zorgaanbod >in regio vinden in(d)

(g)kan eventueelook toegangkrijgenv

(h)schrappen melden bij

v

(i)vormt basis voor

v

De bovenstaande figuur toont het gebruik van een zorgaanbiederregister en -gids ineen UML collaboration diagram:

(a) zorgaanbieders kunnen zich registreren bij de beheerder van hetzorgaanbiederregister, krijgen dan een landelijk zorgaanbiedernummertoegekend en kunnen vervolgens vertrouwensmiddelen aanvragen.

(b) zorgverleners met een beschermde beroepstitel dienen te zijn ingeschrevenbij het BIG-register, zorginstellingen dienen te zijn vermeld in hettoetsingsregister van het CVZ.

(c) zorgaanbieders kunnen de door hun aangeboden zorgdiensten metbereikbaarheidgegevens (laten) publiceren in een zorgaanbiedergids.

(d) zorgaanbieders die hun patiënt/cliënt willen verwijzen naar een andere zorg-aanbieder met bepaalde zorgdiensten, in een bepaald specialisme, binneneen bepaalde regio, etc. kunnen die opzoeken in de zorgaanbiedergids.

(e) andere zorgaanbieders kunnen, bijv. na ontvangst van een verwijsbrief vaneen onbekende zorgverlener, de afzender en diens zorginstellingidentificeren door het raadplegen van het zorgaanbiederregister.

(f) andere zorgaanbieders kunnen, bijv. na ontvangst van een verwijsbrief vaneen onbekende zorgverlener, diens bereikbaarheidsgegevens opvragen uitde zorgaanbiedergids.


(g) patiënten/cliënten kunnen in principe op vergelijkbare wijze toegang krijgentot de zorgaanbiedergids. Waneer zij ook elektronisch gaan communiceren,zullen zij ook toegang tot het zorgaanbiederregister moeten krijgen.

(h) nadat een zorgverlener is geschrapt uit het BIG-register of zijn aanstelling ineen zorginstelling is beëindigd, moet zijn vertrouwensmiddel door hetregister als ongeldig worden verklaard.

(i) om de zorgaanbiedergids consistent te houden met het zorgaanbieder-register, zou het register idealiter de basis vormen voor de gids.

Opmerkingen:

• ad (a) dit vertrouwensmiddel zullen zorgaanbieders moeten gebruiken ombijv. hun bevoegdheden te kunnen uitoefenen bij het opvragen van patiënt-gegevens, zie ook paragraaf 3.9.2. Als register en vertrouwensmiddel zijnresp. het UZI-register en de UZI-pas voorzien. Er zijn UZI-passen voor:

o zorgverleners,o vaste medewerkers (op naam gestelde UZI-pas),o tijdelijke medewerkers (niet op naam gestelde UZI-pas),o services (UZI-servicescertificaat).

Deze kunnen worden aangevraagd door de volgende soorten abonnee:o individuele zorgverlenero zorginstelling.

• ad (a) het CIBG is aangewezen als beheerder van het landelijke zorgaan-biederregister (UZI-register). Het UZI-register is begin 2005 operationeelgeworden.

• ad (a) het UZI-register is veeleer een zorgverlenerregister dan eenzorgaanbiederregister, want de uitgegeven identificaties (UZI-nummers) enauthenticatiemiddelen (UZI-passen) zijn primair bedoeld voor personen. HetUZI-register hanteert een abonneenummer dat als zorgaanbiedernummerkan worden gebruikt:

• ad (b) het BIG-register is ook via het Internet raadpleegbaar als toetsings-register voor de kwalificaties van een zorgverlener.

• ad (a) en (b) merk op dat het BIG-register gaat over bevoegdheden totmedisch handelen, terwijl het UZI-register gaat over bevoegdheden totinzage in patiëntgegevens.

• ad (d) het vastleggen van bereikbaarheidsgegevens in een aparte gids lijktoverbodig omdat deze (deels) ook in het zorgaanbiederregister zullen staan.Echter, het UZI-register:

o kan niet vrij worden ingevuld met actuele gegevens door dezorgaanbieders, omdat het CIBG de juistheid wil waarborgen,

o kan niet vrij ingezien worden door willekeurige partijen die een over-zicht van het zorgaanbod wensen, omdat de WBP dat niet toelaat.

• ad (e) bij het vastleggen en uitwisselen van patiëntgegevens kunnenzorgverleners daarbij hun zorgverlenernummer vermelden. Overigens is hetUZI-nummer (anders dan het BSN) nadrukkelijk bedoeld als “backoffice-nummer” dat alleen “onder water” wordt gebruikt door applicaties.


• ad (c) aan de hand van een uitgebreide zorgaanbiedergids zou men eenorder kunnen plaatsen bij de beste, snelste en/of goedkoopstezorgaanbieder. Het is nog niet duidelijk welke partij een zorgaanbiedergidsgaat invoeren en beheren. Hier zijn mogelijkheden voor commerciëledienstverleners. Aldus dient rekening te worden gehouden met verscheideneregionale en/of landelijke gidsen, die tezamen één virtuele zorgaanbieder-gids vormen.

• ad (f) momenteel maken zorgaanbieders vaak gebruik van een zogenaamdederdenbestand waarin voor iedere patiënt/cliënt onder meer de eigenhuisarts en de vaste apotheek wordt vastgelegd.

• ad (g) patiënten/cliënten zouden hier ook de historie van dienstverbandenvan een bepaalde persoon als zorgverlener willen nazoeken, voordat zij eenbehandelrelatie aangaan. Sommige klinieken publiceren de CV’s van hunspecialisten op het Internet. Aan de hand van het zorgaanbiederregister isde juistheid van de CV’s deels te controleren.

• zorgaanbieders hanteren voor hun declaratieverkeer reeds geruime tijd dezogenaamde AGB-codes, al dan niet in combinatie met VeCoZo-certificaten.Deze certificaten zijn echter niet geschikt voor de uitwisseling van medischepatiëntgegevens wegens het lagere zekerheidsniveau bij de uitgifte van dezemiddelen. Omdat de UZI-pas omgekeerd wel kan worden gebruikt voordeclaratieverkeer, wordt de AGB-code, indien een zorgverlener deze heeften vermeldt bij het aanvragen van een UZI-pas, opgenomen op de UZI-pas.


3.8.4 Adresseren van dossier en postbus

Wanneer een zorgpartij na raadpleging van de verwijsindex, specifiekepatiëntgegevens wil opvragen bij een specifieke zorgaanbieder, wil hij niet zozeerde zorgaanbieder adresseren (want die is misschien niet aanwezig) maar wel zijndossier (want dat moet altijd beschikbaar zijn). Daartoe is een zorgaanbiedergidsnodig waarin voor elke zorgaanbieder een adres van diens patiëntdossier isvermeld.

In geval van een zorginstelling, kan een dossier op verschillende niveaus wordengeadresseerd:

• zorginstelling – bijv. een apotheek kan via één adres toegang geven tot allemedicatieverstrekkingen, ongeacht welke apotheker of assistent welkeverstrekking heeft vastgelegd,

• zorginstelling-afdeling – bijv. binnen een ziekenhuis kan een laboratorium-afdeling via één eigen adres toegang geven tot alle labuitslagen, ongeachtwelke laborant voor welke labuitslag verantwoordelijk is,

• zorginstelling-zorgverlener – bijv. binnen een ziekenhuis kan een internistvia een eigen adres toegang geven tot alleen zijn dossier.

Aldus moeten zowel gezamenlijke als persoonlijke dossiers geadresseerd kunnenworden. Welke soorten dossiers precies nodig zijn binnen een zorginstelling, hangtaf van de verdeling van verantwoordelijkheden binnen die zorginstelling.

Wanneer een zorgpartij bepaalde patiëntgegevens (bijv. medicatievoorschrift,verwijsbrief) wil versturen naar een bepaalde zorgaanbieder, wil hij niet zozeer datdie gegevens worden afgeleverd aan de zorgaanbieder zelf (want die is misschienniet aanwezig) maar wel aan diens postbus (want die moet altijd beschikbaar zijn).Daartoe is weer een zorgaanbiedergids nodig, waarin voor elke zorgaanbieder eenadres van diens postbus is vermeld.

In geval van een zorginstelling, kan een postbus op verschillende niveaus wordengeadresseerd:

• zorginstelling – bijv. als een arts een receptaanvraag wil sturen naar eenbepaalde apotheek, adresseert hij de dienstpostbus van de apotheek,

• zorginstelling-afdeling – bijv. als een arts een labaanvraag wil sturen naareen ziekenhuislaboratorium, zonder dat het hem uitmaakt welkezorgverlener of medewerker deze labaanvraag oppikt, adresseert hij dedienstpostbus van het laboratorium,

• zorginstelling-zorgverlener – bijv. als een arts een verwijsbrief wil sturennaar een bepaalde internist en niet zijn collega van dezelfde afdeling,adresseert hij de persoonlijke postbus van die internist.

Aldus moeten zowel dienstpostbussen als persoonlijke postbussen geadresseerdkunnen worden. Welke soorten postbussen precies nodig zijn binnen eenzorginstelling, hangt af van de verdeling van verantwoordelijkheden binnen diezorginstelling.


Conclusie: van iedere zorginstelling, afdeling en zorgverlener moet naar behoefteeen dossier/postbus geadresseerd kunnen worden. Het adres van het dossier en depostbus moet op basis van een zorgaanbiedernummer kunnen worden gevonden ineen adresboek. In geval van zorginstellingen, staan alleen de bevoegde aanspreek-punten van die zorginstelling met dossier/postbus in de zorgaanbiedergids.

De onderstaande figuur toont de samenhang tussen de genoemde objecten in eenUML class diagram:

() kan hebben >

Afdeling

Zorginstelling

Zorgverlener

Instellingsdossier

Afdelingsdossier

Persoonlijkedossier

Instellingspostbus

Afdelingspostbus

Persoonlijkepostbus

() kan hebben >

() kan hebben >

Opmerkingen:

• Een zorgaanbieder kan geen, één of meer postbus- en dossieradressenhebben. Binnen zorgsinstellingen hebben zorgverleners meestal geenpersoonlijke, maar een gezamenlijk (afdelings-) dossier en postbus.Medewerkers kunnen geen persoonlijk dossier en postbus hebben.

• Het hebben van meerdere adressen is niet wenselijk, maar binnen eenziekenhuis staan vaak zodanig specialistische systemen dat sommigezorgverleners hun dossiers noodzakelijkerwijs verdeeld hebben overmeerdere systemen. In geval van meerdere postbusadressen, dient slechtséén te worden gepubliceerd in de zorgaanbiedergids.

• Omdat HL7v3 alleen applicaties kan adresseren en geen afzonderlijke post-bussen en dossiers kent, zullen zorgverleners binnen een instelling die één-zelfde applicatie gebruiken allemaal hetzelfde HL7-adres moeten opgeven inde zorgaanbiedergids. Die applicatie is vervolgens verantwoordelijk voor hettoegang geven tot de juiste postbus en het juiste dossier, zie ook Bijlage D.

• In de toekomst kunnen ook patiënten/cliënten in het kader van telemedicineeen patiëntkluis en een postbus beheren. Afhankelijk van hoeveel patiënten-/cliënten daaraan willen meedoen, kan een patiëntenadresboek nodig zijnom de adressen van hun patiëntkluis en postbus te kunnen vinden.


3.9 Vertrouwen van zorgpartijen enpatiëntgegevens

In het veld van veel en zeer verschillende zorgpartijen en patiëntgegevens, hebbenzorgpartijen behoefte aan:

• vertrouwen in zorgpartijen, dossiers en postbussen• vertrouwen van beheerde gegevens• vertrouwen van opgevraagde gegevens• vertrouwen van verstuurde gegevens


Het ministerie van Binnenlandse Zaken en Koninkrijkszaken heeft onder de naamPKI Overheid (PKIO) een aantal richtlijnen geformuleerd voor de beveiliging vanoverheidsgegevens. Omdat patiëntgegevens minstens zoveel zekerheid vergen, zijnde richtlijnen van PKIO hier overgenomen. Vermoedelijk gaat de “Wet gebruik BSNin de zorg” het gebruik van PKIO-vertrouwensmiddelen verplicht stellen voor allezorgpartijen die van het BSN gebruik willen maken.

In 2003 is de Wet Elektronische Handtekening (WEH) van kracht geworden. Dezewet geeft richtlijnen voor elektronische handtekeningen opdat zij dezelfde juridischegeldigheid krijgen als de handgeschreven handtekening. Overigens voldoet PKIOaan die richtlijnen.

Het NEN werkt in opdracht van het ministerie van VWS aan de norm NEN 7510“Informatiebeveiliging in de zorg”. Deze norm is op een abstract niveaugedefinieerd en wordt momenteel uitgewerkt in een aantal toetsbare voorschriften.

NICTIZ heeft voor de UZI-pas gekozen als basis voor de beveiliging van het virtuelepatiëntdossier en het virtuele postkantoor. In principe zou de basisinfrastructuurook moeten kunnen werken met andere vertrouwensmiddelen, als die er waren.Daarom worden de bedrijfsprocessen in de navolgende paragrafen op generiekewijze beschreven, dus in termen van “vertrouwensmiddel” in plaats van “UZI-pas”.


3.9.2 Vertrouwen in zorgpartijen, dossiers en postbussen

Wanneer iemand probeert toegang te krijgen tot een dossier of een postbus, al danniet via het schakelpunt, dient hij zich te identificeren als zorgaanbieder ofpatiënt/cliënt ten behoeve van autorisatie. Daarbij is het belangrijk erop te kunnenvertrouwen dat deze persoon inderdaad is, wie hij zegt dat hij is.

Om zich te authenticeren hebben zorgverleners en hun medewerkers (en straks ookpatiënten/cliënten) een persoonsgebonden vertrouwensmiddel nodig. Om tijdenshun afwezigheid andere zorgverleners toegang te bieden tot hun dossier enpostbus, hebben dossiers en postbussen een systeemgebonden vertrouwensmiddelnodig. Binnen zorginstellingen kunnen meerdere dossiers en postbussen gebruikmaken van éénzelfde vertrouwensmiddel.

Schakelpunt

Zorgaanbieder

Persoonsvertrouwens

middel

Zorgaanb.postbus

Systeemvertrouwens

middel

(b)krijgt toegang metvertrouwensmiddel > Schakelpunt

vertrouwensmiddel

Zorgaanb.register

^(e) koppelen aan met

vertrouwensmiddel

(c) authenticeert zichaan zorgaanbiedermet behulp van >

^(d) controleertgeldigheid van

vertrouwensmiddel

(f) authenticeren zichaan schakelpuntmet behulp van >

(g)krijgt toegang metvertrouwensmiddel tot eigen >

Patiëntendossier

TTP

(a) verkrijgt vertrouwensmiddel bij >

De bovenstaande figuur toont authenticatie in een UML collaboration diagram:

(a) een zorgaanbieder verwerft een persoonsgebonden vertrouwensmiddel bijeen TTP, die vervolgens een bijbehorend certificaat vastlegt in hetzorgaanbiederregister.

(b) wanneer de zorgaanbieder toegang probeert te krijgen tot het schakelpunt,zal hij zijn vertrouwensmiddel moeten gebruiken. Hij zal een toegangscodemoeten invoeren op zijn vertrouwensmiddel, ter controle dat hij derechtmatige houder is.

(c) het schakelpunt gebruikt zijn eigen systeemgebonden vertrouwensmiddelom zichzelf te authenticeren aan de zorgaanbieder.


(d) het schakelpunt raadpleegt het zorgaanbiederregister om te controleren ofhet vertrouwensmiddel van de zorgaanbieder nog geldig is.

(e) om het geheel gesloten te houden, dient ieder zorgaanbiederpostbus enpatiëntdossier bij aansluiting op het schakelpunt zich ook te authenticerenmet behulp van een systeemgebonden vertrouwensmiddel.

(f) evenzo dient het schakelpunt zich te authenticeren aan de aangeslotenzorgaanbiederpostbus en patiëntdossier.

(g) om het geheel gesloten te houden, moet een zorgaanbieder ook altijd zijnvertrouwensmiddel gebruiken om toegang tot zijn eigen zorgaanbieder-postbus en patiëntdossier te krijgen.

Opmerkingen:

• ad (a) het UZI-register hanteert strenge voorwaarden voor de uitgifte vanUZI-passen. Zo geldt onder meer (zie ook paragraaf 3.3.2):

o UZI-passen voor zorgverleners en medewerkers dienen vooraf te zijnaangevraagd door de zorgaanbieder voor wie de UZI-pashouderwerkt. Dit is nodig om het juiste zorgaanbieder te vermelden op deUZI-pas.

o UZI-passen op naam voor zorgverleners en medewerkers moetendoor de UZI-pashouder persoonlijk worden opgehaald bij de RA vanhet UZI-register. Dit is nodig om de identiteit van de UZI-pashouderte kunnen verifiëren.

o UZI-passen niet op naam voor medewerkers mogen door dezorgaanbieder aan de UZI-pashouder worden uitgereikt. Dit ispraktisch voor medewerkers met snel wisselende functies. Dezorgaanbieder moet echter zelf bijhouden wie de UZI-pas heeft,ervoor zorgen dat na overdracht van de UZI-pas op een anderemedewerker de PIN-code opnieuw wordt ingesteld, etc.

Het vertrouwensniveau van UZI-passen niet op naam ligt dus lager dan dievan de UZI-passen op naam. Als een zorgverlener een medewerker wilmandateren voor het uitwisselen van patiëntgegevens, zie paragraaf 3.7.4,heeft de laatste een UZI-pas op naam nodig.

• ad (d) een vertrouwensmiddel kan de volgende geldigheidstoestandenhebben:

o uitgegeven, dus nog niet geldig;o geactiveerd, dus geldig;o ingetrokken, dus niet meer geldig.

• ad (e) voor systeemgebonden vertrouwensmiddelen zal een zorgaanbiederzich ook moeten wenden tot de TTP. Door het plaatsen vansysteemgebonden vertrouwensmiddelen in zijn zorgsysteem met dossiers enpostbussen geeft de zorgaanbieder aan dat dit zorgsysteem autonoom debevragingen en opdrachten van andere zorgaanbieders mag beantwoorden.

• zorgverleners hebben dus altijd een eigen persoonsgebondenvertrouwensmiddel en daarnaast een systeemgebonden vertrouwensmiddeldat ze mogelijkerwijs delen met collega’s van de afdeling of van de helezorginstelling. Al deze middelen worden vermeld in hetzorgaanbiederregister.


• persoonsgebonden vertrouwensmiddelen kunnen in principe binnenzorginstellingen ook worden gebruikt voor:

o het geven van toegang aan gebouwen, afdelingen, zalen, etc.,o het registreren van het gebruik van apparatuur, verbruik van

middelen,o etc.

• als een zorgverlener in verschillende functies, werkverbanden en/ofzorginstellingen werkt, zal hij voor elke hoedanigheid als zorgverlenerverschillende bevoegdheden genieten. Dus zal hij voor elke hoedanigheideen apart zorgaanbiedernummer moeten hebben en ook een apartvertrouwensmiddel. Als de techniek zover is, zouden tweevertrouwensmiddelen op één chipkaart kunnen worden geplaatst, om tevoorkomen dat een zorgverlener met meerdere chipkaarten moet werken.

• straks zouden patiënten/cliënten ook een vertrouwensmiddel kunnenverwerven, waarmee zij rechtstreeks (dus zonder tussenkomst van deverantwoordelijke zorgaanbieder) toegang tot hun eigen patiëntgegevenskunnen krijgen. Ook kan zo’n vertrouwensmiddel zeer nuttige functieskrijgen tijdens een bezoek aan een zorgaanbieder, zoals:

o door het overleggen van het vertrouwensmiddel en het invoeren vaneen toegangscode heeft de zorgaanbieder (en dus ook dezorgverzekeraar) meer zekerheid over de verzekerings-gerechtigdheid. Momenteel komt identificatiefraude dooronverzekerden veel voor. Sinds kort mogen zorginstellingen depatiënten/cliënten vragen om een wettelijk identificatiedocument(paspoort, rijbewijs, etc.),

o door het insteken van het vertrouwensmiddel in een leesapparaat,verbonden met het zorgsysteem van de zorgaanbieder, kunnenonmiddellijk de juiste gegevens uit het patiëntdossier wordengepresenteerd,

o door het insteken van het vertrouwensmiddel in een leesapparaat,verbonden met het zorgsysteem, kan de patiënt/cliënt zelfstandigzijn zorgaanbieder toegang verlenen tot patiëntgegevens waarvoorde laatste anders niet geautoriseerd was. Op deze manier kanworden voorkomen dat de patiënt terug moet naar degegevensverantwoordelijke zorgverlener (zie paragraaf 3.7.2).

Het vertrouwensmiddel voor patiënten/cliënten is nog niet nader uitgewerktin deze versie van dit document.


3.9.3 Vertrouwen van beheerde patiëntgegevens

Hoewel het versturen en opvragen van patiëntgegevens naar en van anderezorgaanbieders veel meer risico’s heeft (zie navolgende paragrafen), is ook hetbeheren van patiëntgegevens bij één zorgaanbieder niet zonder risico’s. Daaromworden deze hier eerst behandeld en wel aan de hand van de volgende casus:

• vastleggen: een huisarts (of medewerker) schrijft recept uit en legt het vastin zijn dossier,

• raadplegen: de huisarts (of medewerker) raadpleegt het recept in zijndossier.

Huisarts

vastleggen recept >

< raadplegen recept

Huisartsdossier

In deze casus wil de huisarts de volgende zekerheden, uit hoofde van zijnverantwoordelijkheid:

vastleggen raadplegenAuthenticiteit Huisarts wil voorkomen dat

onbevoegden het receptongemerkt kopiëren

nvt

Vertrouwelijkheid Huisarts wil voorkomen datonbevoegden het recept kunneninzien

nvt

Integriteit Huisarts wil voorkomen dat iemandzijn recept na zijn fiat ongemerktkan wijzigen

nvt

Onweerlegbaarheid Huisarts wil zekerheid dat hetrecept door hem is gefiatteerd

Medewerker kan niet ontkennendat hij recept heeft ingezien

Betrouwbaarheid Huisarts wil voorkomen dat hetrecept kwijtraakt, bijv. door brand

nvt

Het gewenste niveau van vertrouwen kan verschillen per gegevenssoort enzorgtoepassing. Sommige zekerheden zijn überhaupt niet nodig, maar zijn hier voorde volledigheid gepresenteerd.


3.9.4 Vertrouwen van opgevraagde patiëntgegevens

Bij het opvragen van patiëntgegevens van andere zorgaanbieders kunnen dezegegevens in handen vallen van onbevoegden. Daarom wensen zorgaanbiedersbepaalde zekerheden. Deze worden hier behandeld aan de hand van de volgendecasus:

• opvragen: een apotheker (of medewerker) vraagt recepten op uit dedossiers van relevante huisartsen

• ontvangen: de apotheker (of medewerker) ontvangt de opgevraagderecepten

Huisarts Apotheker

< opvragen recept

ontvangen recept >

Huisartsdossier

In deze casus willen de huisarts en de apotheker de volgende zekerheden, uithoofde van hun verantwoordelijkheden:

opvragen ontvangenAuthenticiteit nvt Huisartsen willen voorkomen dat

de apotheker een receptkopie alsorigineel opneemt in zijn dossier

Vertrouwelijkheid nvt Huisartsen willen voorkomen datanderen dan de opvragendeapotheker de recepten kan inzien

Integriteit Apotheker wil voorkomen datiemand de opvraag onderwegongemerkt wijzigt

Huisartsen willen voorkomen datiemand de recepten onderwegongemerkt wijzigt

Onweerlegbaarheid Huisartsen willen voorkomen datde apotheker achteraf kanontkennen dat hij de receptenheeft opgevraagd

Huisartsen willen voorkomen datde apotheker achteraf kanontkennen dat hij de receptenheeft ontvangen

Betrouwbaarheid Apotheker wil voorkomen dat deopvraag niet aankomt bij allerelevante huisartsen,bijv. doordat een huisarts tijdelijkonbereikbaar is

Apotheker wil voorkomen dat eronderweg recepten kwijtraken

Volledigheid nvt Apotheker wil voorkomen dat erongemerkt recepten ontbreken inhet opgeleverde overzicht,bijv. wegens onbereikbare dossiers

Actualiteit nvt Apotheker wil voorkomen dat deontvangen recepten nietovereenkomen met dewerkelijkheid,bijv. omdat een huisarts zijndossier niet bijgewerkt heeft



3.9.5 Vertrouwen van verstuurde patiëntgegevens

Bij het versturen van patiëntgegevens naar andere zorgaanbieders, kunnen dezegegevens in handen vallen van onbevoegden. Daarom wensen zorgaanbiedersbepaalde zekerheden. Deze worden hier behandeld aan de hand van de volgendecasus:

• verzenden: een huisarts (of medewerker) stuurt een recept naar de postbusvan een apotheker

• ontvangen: de apotheker (of medewerker) haalt het verstuurde recept uitzijn postbus

Huisarts

Apothekerpostbus

Apotheker

verzenden recept > ontvangen recept >

In deze casus willen de huisarts en de apotheker de volgende zekerheden, uithoofde van hun verantwoordelijkheden:

verzenden ontvangenAuthenticiteit Huisarts wil voorkomen dat iemand

het recept nog eens verstuurt naareen apotheker en aldus demedicatie nog eens kan afhalen,bijv. in geval van verslavendemedicijnen

nvt

Vertrouwelijkheid Huisarts wil voorkomen dat iemandanders dan de bestemde apothekerhet recept kan inzien

nvt

Integriteit Huisarts wil voorkomen dat iemandhet recept onderweg ongemerktkan wijzigen

nvt

Onweerlegbaarheid Huisarts wil voorkomen dat deapotheker achteraf kan ontkennendat hij het recept heeft ontvangen

Apotheker wil voorkomen dat dehuisarts achteraf kan ontkennendat hij het recept heeft verstuurd

Betrouwbaarheid Huisarts wil voorkomen dat hetrecept niet aankomt bij deapotheker, bijv. doordat deapotheker tijdelijk onbereikbaar is

Apotheker wil voorkomen dat eenonverhoopt dubbel verstuurdrecept als nieuw recept wordtbeschouwd

Tijdigheid Huisarts wil zekerheid dat deapotheker het recept tijdigontvangt



3.9.6 Vertrouwensniveaus

Zoals beschreven in de vorige paragrafen, kan het vereiste vertrouwensniveauverschillen per gegevenssoort en zorgtoepassing. Een hoog vertrouwensniveau ismeestal duur en geeft veel ongemak voor de zorgaanbieder.

Daarom dient de basisinfrastructuur verschillende vertrouwensniveaus te bieden,die een zorgtoepassing naar behoefte kan gebruiken. Geredeneerd vanuit de risico’sbeschreven in de vorige paragrafen, zijn de volgende vertrouwensniveaushanteerbaar:

• laag: geeft de zekerheid dat alleen zorgverleners en medewerkers binnen dedesbetreffende zorginstelling rechten kunnen krijgen,

• midden: geeft de zekerheid dat alleen zorgverleners en medewerkers binnende desbetreffende afdeling van een zorginstelling rechten kunnen krijgen,

• hoog: geeft de zekerheid dat alleen de desbetreffende zorgverlener rechtenkan krijgen.

Deze vertrouwensniveaus kunnen worden gerealiseerd door een combinatie van devolgende vrijheidsgraden omtrent vertrouwensmiddelen toe te passen:

• geldigheidsduur van de authenticatie• sterkte van de authenticatie

De geldigheidsduur van de authenticatie geeft aan hoe lang een persoon of systeemde desbetreffende toegangsrechten kan uitoefenen. Hier maken we het volgendeonderscheid:

• moment: de zorgverlener moet zich iedere keer authenticeren wanneer hijactie onderneemt, bijv. patiëntstukken vastleggen in een dossier, ofpatiëntberichten ophalen uit een postbus.

• sessie: de zorgverlener hoeft zich slechts aan het begin van een sessie teauthenticeren. Gedurende de sessie kan hij zijn bevoegdheden uitoefenen.De sessie eindigt wanneer hij niet langer gebruik maakt van zijnbevoegdheden.

• werkdag: de zorgverlener hoeft zich slechts aan het begin van een werkdagte authenticeren. Vervolgens kan hij tot het einde van die werkdag zijnbevoegdheden uitoefenen.

• continu: het systeem hoeft zich slechts éénmaal bij koppeling met hetschakelpunt te authenticeren, totdat het systeem wordt afgekoppeld. Dit zoukunnen gelden voor dossiers en postbussen.

Een sessie zal veelal overeenkomen met een zorgcontact of een reeks vanaaneengesloten zorgcontacten.


De sterkte van de authenticatie is een maat voor de zekerheid dat een persoon ofsysteem inderdaad is, wie hij zegt dat hij is. Het is gangbaar daarbij het volgendeonderscheid te maken:

• zwakke authenticatie:o controleren dat iemand iets weet, bijv. een wachtwoord.

• normale authenticatie:o controleren dat iemand iets heeft, bijv. een chipkaart met uniek

nummer.

• sterke authenticatie:o controleren dat iemand iets heeft,o controleren dat iemand iets weet, bijv. een toegangscode voor die

chipkaart.

• zeer sterke authenticatie:o controleren dat iemand iets heeft,o controleren dat iemand iets weet,o controleren dat iemand iets is, bijv. een biometrische eigenschap.

Sterke authenticatie voorkomt dat iemand met een gestolen of verloren chipkaartonmiddellijk de rechten van de rechtmatige eigenaar kan uitoefenen. Zeer sterkeauthenticatie voorkomt dat iemand met een geleende chipkaart met bekendetoegangscode de rechten van de rechtmatige eigenaar kan uitoefenen.Vertrouwensmiddelen van systemen (dossiers en postbussen) die fysiek veiligbinnen het desbetreffende systeem liggen, en dus niet gestolen worden of verlorenraken, kunnen veelal volstaan met normale authenticatie. De authenticatiesterktehangt natuurlijk ook af van de manier waarop de vertrouwensmiddelen wordenuitgegeven, zie paragraaf 5.6.

De onderstaande tabel geeft voor personen aan welk vertrouwensniveau bereiktkan worden bij de diverse combinaties van authenticatie en geldigheidsduur (deprecieze invulling moet nog nader geëvalueerd worden):

Authenticatie Zwak Normaal Sterk Zeer sterkGeldigheidsduur

Werkdag Onveilig Laag Laag Laag

Sessie Laag Laag Midden Midden

Moment Laag Midden Hoog Zeer hoog


De onderstaande tabel geeft voor systemen aan welk vertrouwensniveau bereiktkan worden bij de diverse combinaties van authenticatie en geldigheidsduur (deprecieze invulling moet nog nader geëvalueerd worden):

Authenticatie Zwak Normaal Sterk Zeer sterkGeldigheidsduur

Continu Laag Midden Hoog Zeer hoog

In de praktijk zullen bepaalde combinaties van het bovenstaande het meestpraktisch zijn, bijv. sterke authenticatie aan het begin van een werkdag, normaleauthenticatie aan het begin van een sessie, etc.


3.10 Beheer

Alle genoemde dossiers, registers, adresboeken, etc. zullen moeten wordenbeheerd. Hiervoor zullen (deels) nieuwe partijen in het leven geroepen moetenworden. Voor een juridisch, economisch en organisatorisch haalbare bedrijfsvoeringzullen alle betrokken partijen elkaar diensten moeten leveren, daarvoor elkaarmoeten vergoeden en daarbij voldoende ruimte moeten laten voor commerciëlepartijen.


Het AORTA-dienstenmodel gaat uit van een organisatiemodel in vier lagen vanpartijen die elkaar diensten leveren:

• landelijke identificatiediensten worden geleverd door CIBG en VEKTIS voorhet registreren, identificeren van patiënten/cliënten, zorgaanbieders, resp.zorgverzekeraars,

• centrale verwijs- en routeringsdiensten worden geleverd door een nieuw opte zetten landelijke schakelpuntbeheerder, tezamen met eenautorisatiebeheerder en een logbeheerder.

• regionale of categorale netwerkdiensten worden geleverd door netwerk-dienstverleners, applicatiedienstverleners (ASP), etc.

• zorgaanbieders leveren zorgdiensten aan patiënten/cliënten en werkendaarbij samen met andere zorgaanbieders in zogenoemde zorgnetwerken.

Zorgnetwerken zijn regionale of categorale samenwerkingsverbanden vanzorgaanbieders, die onderling afspraken hebben gemaakt over het beheren enuitwisselen van patiëntgegevens. Daartoe maken zij gezamenlijk gebruik van decentrale verwijs- en routeringsdiensten en identificatiediensten.

De zorgnetwerken kunnen gezamenlijk diensten inkopen van netwerkdienst-verleners, om de dossiers en postbussen van de individuele zorgaanbieders aan tesluiten op het schakelpunt. Ook kunnen zij applicatiedienstverleners inhuren omzorgaanbiederapplicaties met bijbehorende dossiers en postbussen op een centraleplaats gezamenlijk te kunnen gebruiken.

De landelijke schakelpuntbeheerder zal dus behalve het schakelpunt ook deverwijsindex moeten beheren. Omdat de verwijsindex gezondheidsgegevens bevat,mag de schakelpuntbeheerder alleen optreden als bewerker (in de terminologie vande WBP) van gezondheidsgegevens, in opdracht van de verantwoordelijkezorgaanbieders, zie ook paragraaf 3.5.1.

Dit betekent dat de zorgaanbieder dus rechtstreeks verantwoordelijk is voor zijnvermeldingen in de verwijsindex en dus ook rechtstreekse zeggenschap over dievermeldingen moet hebben. In het kader van de WBP zal iedere zorgverlenerindividueel moeten tekenen bij het CBP voor het feit dat hij de schakelpunt-beheerder heeft aangewezen als bewerker van (een deel van) zijn patiëntgegevens.


3.10.2 Dienstenmodel

Volgens het AORTA-dienstenmodel zullen de verschillende partijen als volgt kunnensamenwerken:

Logbeheer Schakelpuntbeheer Autorisatiebeheer

RegisterbeheerRegisterbeheer

Registerbeheerder

Schakelpuntbeheerder

Registerbeheerder

(i)levertidentificatiedienstenv

(d)levert informatie-en routeringsdienstenv

Zorgaanb.adresboek

SchakelpuntToegangs

log

Patiëntenregister

Patiëntenadresboek

Verwijsindex

Zorgaanb.register

(h)levert

identificatiedienstenv

Autorisatiebeheerder

Autorisatieprofiel

Autorisatieprotocol

Logbeheerder

Toezichthouder

^levertinzage aan(g)

^bepalen autorisatie-protocol en laten dat

vastleggen door

beheert >

beheert >< beheert < beheert

< beheert

(g)levertinzage aanv

Netwerkdienstverlener

Applicatie(dienst)aanbieder

Applicatiebeheerder

Netwerkbeheerder

Datacomnetwerk

< beheert

Samenwerkingsverband

^werkt

samen in(b)

Patiënt/cliënt

(a)levertzorg-

diensten< aan

Zorgaanbieder

Zorgverlener

Dossier

Applicatie

Postbus

gebruikt >

(c)levert

netwerkdienstenv v

kooptdienstenin bij >

< beheert

Beroepsvereniging

(e) is lid van

(f) laat wensen t.a.v toegang patiëntgegevens vastleggen door >

Dossier/ kluis

Applicatie

Postbus

(j)levert

applicatie(dienst)

<

< levert applicatiedienst (k)

De bovenstaande figuur toont dit in een variant op een UML collaboration diagram:

(a) een zorgaanbieder levert zorgdiensten aan patiënten/cliënten en gebruiktdaarbij zorgaanbiederapplicaties met bijbehorend(e) dossier en postbus.

(b) de zorgaanbieder werkt samen met andere zorgaanbieders in een regionaalof categoraal samenwerkingsverband. Deze samenwerkende zorgaanbieders


kunnen individueel of gezamenlijk diensten inkopen bij netwerkdienst-verleners en eventueel ook bij applicatiedienstverleners.

(c) netwerkdienstverleners sluiten zorgaanbieders aan op hun datacom-netwerken leveren aldus netwerkdiensten opdat deze zorgaanbieders informatie- enrouteringsdiensten van het schakelpunt kunnen krijgen.

(d) de schakelpuntbeheerder levert landelijke informatie- en routeringsdienstenaan alle zorgaanbieders via de datacom-netwerken van de verschillendenetwerkdienstverleners . De schakelpuntbeheerder zorgt ervoor, datuitwisseling van patiëntgegevens geschiedt conform het autorisatieprotocolen het autorisatieprofiel en dat deze wordt gelogd.

(e) individuele zorgverleners zijn lid van beroepsverenigingen die samen met depatiëntenvereniging afspraken maken over wie toegang mag krijgen totwelke patiëntgegevens. De autorisatiebeheerder legt dat vast in eenautorisatieprotocol.

(f) patiënten/cliënten kunnen wel/niet akkoord gaan met elektronischeuitwisseling van hun patiëntgegevens en wensen dat bepaalde zorgverlenerswel/niet toegang mogen krijgen. De autorisatiebeheerder legt dat vast ineen autorisatieprofiel.

(g) de logbeheerder geeft de toezichthouder en patiënten/cliënten inzage in detoegangslog.

(h) de registerbeheerder beheert een patiëntenregister of de toegang tot eenburgerregister.

(i) de registerbeheerder beheert het zorgaanbiederregister en geeftvertrouwensmiddelen uit aan zorgverleners.

(j) in plaats van dat een zorgaanbieder zelf een applicatie aanschaft en beheert,kan een applicatiedienstverlener dat uit handen nemen en alleen het gebruikvan de zorgaanbiederapplicatie in rekening brengen.

(k) een applicatiedienstverlener kan ook aan patiënten/cliënten een patiënt-applicatie met bijbehorende patiëntkluis en postbus aanbieden.

Opmerkingen:

• ad (b) Deze samenwerkingsverbanden bestaan reeds in diverse vormen,bijv. Zorgring Noord Holland Noord, Stichting Uzorg, Stichting Gerrit.

• ad (c) deze netwerkdienstverlener kan een ISP (bijv. Planet Internet) zijndie toegang geeft tot het openbare Internet, of een partij (bijv. E-zorg) dieeen VPN beheert, of een VAN (bijv. LifeLine) die een gesloten netwerkbeheert. Alle soorten netwerkdienstverleners huren meestal de benodigdedatacom-verbindingen in van een datacom-aanbieder (bijv. KPN, Versatel,BBnet).

• ad (j, k) deze applicatiedienstverlener kan een ASP zijn, zoals Labelsoft ofUzorg BV die een zorgaanbiederapplicatie aanbieden voor waarneminghuisartsen, en Medlook die een patiëntapplicatie aanbiedt met patiëntkluis.


3.10.3 Organisatiemodel

De overheid heeft besloten tot het volgende:

• het CIBG gaat de rollen vervullen van landelijke beheerder van de SBV-Z alspatiëntregister resp. het UZI-register als zorgaanbiederregister. VEKTIS isaangewezen als beheerder van het UZOVI-register alszorgverzekeraarregister.

• er komt een Landelijk Schakelpunt (LSP) voor de centrale verwijs- enrouteringsdiensten alsmede het autorisatie- en logbeheer. Deze diensten zijndoor NICTIZ aanbesteed aan een marktpartij.

• netwerkdienstverleners zullen zich moeten kwalificeren tot Zorg ServiceProviders (ZSP’s) alvorens zij de aansluiting van GBZ’en op het LSP mogenverzorgen. Deze ZSP’s zullen ook de eerstelijns ondersteuning aanzorgaanbieders moeten verzorgen bij het aansluiten van hun XIS aan hetLSP. De ZSP zal veel vragen en verzoeken van zorgaanbieders doorzettennaar het LSP, maar moet het LSP echter afschermen van een toevloed vanonduidelijke en onnodige vragen en verzoeken.

• zorgaanbieders zullen voor hun zorgsystemen (XIS) het keurmerk GoedBeheerd Zorgsysteem (GBZ) moeten verkrijgen alvorens die XIS magworden aangesloten op het LSP.

• een nader aan te wijzen partij zal worden belast met het toezicht op derechtmatigheid van landelijke toegang tot patiëntgegevens doorzorgaanbieders. Ook patiënten/clienten moeten zich kunnen wenden totdeze partij.

Als gevolg van de bovenstaande beslissingen en taakverdelingen kan perorganisatie de benodigde dienstverlening worden gedefinieerd. De onderstaandefiguur toont dit in een variant op een UML collaboration diagram.


CIBG

???

Systeembeheerder

Toezichthouder

Systeembeheerder

Klantenondersteuning

Autorisatiemanager

F1

F2

F3

F4


F1

Applicatiebeheerder

UZI-register SBV-Z

NICTIZ

LSPopdrachtgever

v w

u

x

t

s

LSP

LSPopdrachtnemer



Test/acceptatiebeheerder

Logbeheerder

Systeembeheerder

F1

F3 F2

F4

F8

F5 F6

F1 F1

F7Applicatiebeheerder

Programma-managers

ICT-architecten

ZIM

o pn

kl rm

q

XISleverancier

Zorgaan

bieder

F1

F1 F1ZSP

Zorgverlener

Systeembeheerder

Applicatieontwikkelaar


Systeembeheerder

F3

Test/acceptatiebeheerder

F1DCN

D1 XIS

Berichtenmodelleurs

b


XIS

a

c

dLog

beheerder

Patiënt/cliënt

e f

g

h ij


De zorgaanbieder levert de volgende diensten:

(a) de zorgverlener levert zorgdiensten aan de patiënt/cliënt en legtpatiëntgegevens vast in zijn XIS en wisselt ze uit met andere zorgaanbiedersvia de ZIM.

(b) de zorgverlener stelt met zijn XIS patiëntgegevens beschikbaar vooropvraag door andere zorgaanbieders via de ZIM.

(c) de lokale autorisatiebeheeder biedt de patiënt/cliënt eventueel demogelijkheid om een intern autorisatieprofiel in te stelllen.

(d) de lokale logbeheerder biedt de patiënt/cliënt eventueel de mogelijkheid omde interne toegangslog te raadplegen.

(e) de systeembeheerder beantwoordt eventuele vragen en verzoeken van deZSP.

De XIS-leverancier van de zorgaanbieder levert de volgende diensten:

(f) de XIS-test/acceptatie-beheeder test zijn XIS tegen de test-ZIM.

(g) de XIS-applicatieontwikkelaar implementeert op verzoek van NICTIZ nieuwefuncties en (versies van) gestandaardiseerde berichtformaten.

De ZSP van de zorgaanbieder levert de volgende diensten:

(h) het DCN verbindt de XIS met de operationele ZIM.

(i) het DCN verbindt de te testen XIS met de test-ZIM.

(j) de ZSP-klantenondersteuning treedt op als eerste aanspreekpunt voorvragen en verzoeken van zorgaanbieders.

Het LSP levert de volgende diensten:

(k) de ZIM levert verwijs- en routeringsdiensten aan de aangesloten XIS’ en vanzorgaanbieders.

(l) de LSP-systeembeheerder regelt op verzoek van de ZSP-systeembeheerderde koppeling van XIS’en aan de ZIM via zijn DCN.

(m) de LSP-klantenondersteuning handelt de door de ZSP-klanten-ondersteuning doorverwezen vragen en verzoeken van zorgaanbieders af.

(n) de LSP-logbeheerder doorzoekt op verzoek van de toezichthouder detoegangslog, al dan niet ten behoeve van een patiënt/cliënt

(o) de LSP-autorisatiebeheerder werkt op verzoek van de autorisatiemanagerhet landelijke autorisatieprotocol en de autorisatieprofielen van patiëntenbij.


(p) De LSP-opdrachtnemer rapporteert aan de LSP-opdrachtgever van NICTIZ,over de diensten geleverd door het LSP en maakt afspraken met de LSP-opdrachtnemer over de eventuele uitbreiding of bijstelling van de diensten.

(q) de LSP-applicatiebeheerder implementeert op verzoek van NICTIZ nieuwefuncties en (versies van) gestandaardiseerde berichtformaten.

(r) de LSP-test/acceptatie-beheerder geeft XIS-leveranciers de mogelijkheid omhun XIS te testen op het voldoen aan de eisen voor een GBZ.

Een nader aan te wijzen partij levert de volgende diensten:

(s) de toezichthouder controleert de rechtmatigheid van landelijke toegang totpatiëntgegevens door zorgaanbieders, dit zowel op eigen initiatief als opverzoek van patiënten/cliënten.

(t) de autorisatiemanager zorgt namens beroepsverenigingen van zorgverlenersen namens patiënten/clienten voor de juiste instellingen van het landelijkeautorisatieprotocol respectievelijk de autorisatieprofielen.

Het CIBG levert de volgende diensten:

(u) het UZI-register geeft na zorgvuldige registratie aan zorgverleners UZI-passen uit.

(v) het UZI-register publiceert certificaten van uitgegeven UZI-passen, ondermeer ten behoeve van het LSP.

(w)de SBV-Z levert aan het LSP een berichtendienst voor het opvragen ofverifiëren van het BSN van een patiënt/client.

(x) de applicatieontwikkelaar implementeert op verzoek van NICTIZ nieuwefuncties en (versies van) gestandaardiseerde berichtformaten.

Opmerkingen:

• De taakverdeling en dienstverlening beschreven in deze paragraaf looptgrotendeels vooruit op ontwerpbeslissingen die pas in de hoofdstukken 4 en5 aan bod komen. Voor een goed begrip van deze paragraaf kan het dusnodig zijn de hoofdstukken 4 en 5 te raadplegen.

• In principe zou de basisinfrastructuur ook moeten kunnen werken met eenandere taakverdeling. Daarom worden de diensten in hoofdstuk 4 opgenerieke wijze beschreven, dus in termen van “zorgaanbiederregister”,“schakelpuntbeheerder”, “netwerkdienstverlener”, etc. in plaats van “UZI-register”, “LSP”, “ZSP” en “GBZ”.

• De menssymbolen in de figuur vertegenwoordigen de aanspreekpunten voorde verschillende diensten. Hiermee wordt geenszins bedoeld voor teschrijven op welke manier de getoonde partijen hun interne organisatiemoeten inrichten.


4 Informatiesysteemarchitectuur

In de Informatiesysteemarchitectuur wordt de toepassing van de ICT-voorzieningenin de zorg beschouwd, in termen van de functies benodigd voor de gebruikers, deapplicaties die deze functies bieden, de objecten zoals ze zichtbaar zijn voor degebruikers, en de interacties die de objecten onderling hebben. Daarbij worden alleondersteunende technische ICT-voorzieningen zoveel mogelijk buiten beschouwinggelaten.

4.1 Applicaties

Voor de verschillende zorgpartijen zullen gebruikersapplicaties nodig zijn om dezezorgpartijen te ondersteunen bij hun taken, bijv. door het vastleggen en uitwisselenvan patiëntgegevens. Op welke technische ICT-voorzieningen deze applicatiesdraaien, wordt besproken in hoofdstuk 5. Hier wordt verondersteld dat:

• zorgaanbiederapplicaties toegankelijk moeten zijn op een willekeurigewerkplek van de desbetreffende zorgverlener,

• patiënt/cliëntapplicatie toegankelijk moeten zijn op een willekeurigewoonplek, werkplek, of publieke locatie,

• diverse beheerapplicaties toegankelijk moeten zijn op een willekeurigewerkplek van de desbetreffende beheerders.

In principe vormen de verschillende gebruikersapplicaties geen onderdeel van debasisinfrastructuur. Deze applicaties kunnen worden ontwikkeld in vele soorten ensmaken. De benodigde standaardisatie rond applicaties valt onder het programmaZorgtoepassingen. Toch is het hier nodig een beeld te vormen van deze applicatiesom te bepalen op welke wijze de basisinfrastructuur deze applicaties kan en moetondersteunen met generieke functies.

De basisinfrastructuur moet in principe mogelijk maken dat applicaties onderlingalle soorten patiëntgegevens landelijk kunnen uitwisselen. Maar dat betekent nogniet dat één bepaalde applicatie daadwerkelijk alle soorten patiëntgegevens moetkunnen uitwisselen. Zoals zal blijken uit de volgende paragrafen, krijgen we temaken met gespecialiseerde applicaties die zich beperken tot specifieke zorg-toepassingen en daarbinnen een specifieke toepassingsrol hebben.

Bij landelijke uitwisseling van patiëntgegevens moet aldus van iedere applicatiekunnen worden vastgesteld:

• welke zorgtoepassingen de applicatie ondersteunt:o EMD,o WDH,o etc.

• welke toepassingsrol de applicatie daarbinnen ondersteunt:o EMD: voorschrijver, verstrekker, etc.o WDH: dossierhouder, waarnemer.


4.1.1 Zorgaanbieder-applicaties

Om zorgaanbieders zoveel mogelijk te ondersteunen bij het uitwisselen vanpatiëntgegevens, zijn specifieke zorgaanbiederapplicaties nodig voor deverschillende doeleinden. De onderstaande figuur toont dit in een UML collaborationdiagram:

Zorgaanb.postbus

Patiëntenadresboek

Zorgaanbieder

(b) aanmelden, opvragen, versturen patiëntgegevens >^

(d) attenderenzorgaanbieder

(c) opzoeken zorgaanbieder >bijhouden bereikbaarheidsgegevens >

(a) vastleggenpatiëntgegevens > Patiënt

dossier

Zorgaanb.gids

Schakelpunt

Zorgaanb.applicatie

Toegangslog

Zorgaanb.register

Patiëntenregister

Autorisatieprofiel

Verwijsindex

Autorisatieprotocol

Mandateringstabel(f) vastleggen mandateringen >

(e) raadplegen toegangslog >

Hoewel bijv. een apotheker heel andere applicaties nodig heeft dan een radioloog,hebben beide toch behoefte aan dezelfde generieke functies. Aldus zijnzorgaanbiederapplicaties wenselijk die een zorgaanbieder in staat stellen tot:

(a) het vastleggen van patiëntgegevens in het eigen patiëntdossier,

(b) het aanmelden, opvragen en versturen van patiëntgegevens via hetschakelpunt,

(c) het bijhouden van de eigen bereikbaarheidsgegevens en het opzoeken vanandere zorgaanbieders in de zorgaanbiedergids,

(d) het geattendeerd worden wanneer patiëntgegevens door een anderezorgaanbieder of een patiënt/cliënt toegestuurd zijn,

(e) het raadplegen van de toegangslog inzake bevragingen van het eigendossier door andere zorgaanbieders,

(f) het mandateren van medebehandelaren en medewerkers.

Specifieke applicaties voor specifieke doeleinden zullen, ieder op een eigen wijze,de twee manieren van gegevensuitwisseling (haal- en breng-mechanisme, dusopvragen en versturen van patiëntgegevens) combineren. Voorbeelden zijn:


• elektronisch voorschrijfsysteem: deze applicatie kan een zorgaanbieder instaat stellen:

o een overzicht van de actuele medicatie van een patiënt/cliënt tekrijgen (opvragen patiëntgegevens: medicatievoorschriften en -verstrekkingen)

o een recept uit te schrijven (vastleggen patiëntgegevens + aanmeldenpatiëntgegevens)

o een apotheek in een bepaalde regio te selecteren (opzoekenzorgaanbieder)

o een receptaanvraag te sturen naar een apotheek (versturenpatiëntgegevens: opdracht)

o de receptverstrekking bevestigd te krijgen door de apotheek(versturen patiëntgegevens: antwoord)

• elektronische agenda: deze applicatie kan een zorgaanbieder in staatstellen:

o een overzicht van alle zorgaanbieders met een bepaalde functie ineen bepaalde regio te krijgen (opzoeken zorgaanbieder)

o van iedere zorgaanbieder inzicht in de wachtlijst te krijgen (opvragenpatiëntgegevens: afspraken)

o een afspraak aan te vragen binnen een gewenste tijdsruimte(versturen patiëntgegevens: opdracht)

o de afspraak bevestigd te krijgen door de zorgaanbieder (versturenpatiëntgegevens: antwoord)

Tenslotte zullen ook generieke applicaties nodig zijn voor:

• elektronisch dossier inkijken: deze applicatie kan een zorgaanbieder in staatstellen:

o een index van alle beschikbare patiëntgegevens van eenpatiënt/cliënt te krijgen (opvragen patiëntgegevens: index)

o de beschikbare patiëntgegevens van een bepaalde gegevenssoort bijeen specifieke zorgaanbieder nader in te kijken (opvragenpatiëntgegevens: specifieke gegevenssoort)

• elektronische post: deze applicatie kan zorgaanbieders in staat stellenwillekeurige berichten met patiëntgegevens te versturen (gestructureerd ofniet).

Opmerkingen:

• de verschillende zorgaanbiederapplicaties met bijbehorende dossiers,postbussen en systeemvertrouwensmiddel vormen tezamen eenzorginformatiesysteem, zoals een huisartsinformatiesysteem (HIS),apotheekinformatiesysteem (AIS), ziekenhuisinformatiesysteem ZIS, etc. Ingenerieke zin worden deze vaak als XIS aangeduid.

• idealiter worden de verschillende gebruikersapplicaties zodanig geïntegreerddat de zorgaanbieder naadloos kan overstappen van de ene naar de andereapplicatie.

• in de praktijk zijn zorgapplicaties vaak veel complexer gestructureerd:vooral in grote zorginstellingen zijn er veel applicaties van verschillendfabrikaat, die onderling op zeer ingewikkelde wijze zijn geïntegreerd.


4.1.2 Patiënt/cliënt-applicaties

Ook patiënten/cliënten zullen in de toekomst op elektronische wijze hun rechten tenaanzien van hun patiëntgegevens willen uitoefenen. Om hen daarbij teondersteunen, zijn patiënt/cliënt-applicaties wenselijk. De onderstaande figuurtoont dit in een UML collaboration diagram:

Patiëntpostbus

Patiëntenadresboek

Patiënt/cliënt

(e) aanmelden, opvragen, versturen eigen patiëntgeg.>

^(f) attenderen

patiënt/cliënt

(d) opzoeken zorgaanbieder >bijhouden eigen bereikbaarheidsgegevens >

(c) vastleggen eigenpatiëntgegevens > Patiënt

kluis

Zorgaanb.gids

Schakelpunt

Patiënt/cliëntapplicatie

Toegangslog

Zorgaanb.register

Patiëntenregister

Autorisatieprofiel

Verwijsindex

Autorisatieprotocol

(a) raadplegen toegangslog >

(b) beheren autorisatieprofiel >

Mandateringstabel

Aldus zijn applicaties wenselijk die patiënten/cliënten in staat stellen tot:

(a) het raadplegen van de toegangslog m.b.t. de eigen patiëntgegevens,

(b) het beheren van het eigen autorisatieprofiel,

(c) het vastleggen van eigen patiëntgegevens in hun eigen patiëntenkluis, opdatdeze beschikbaar zijn voor opvraag door zorgaanbieders,

(d) het bijhouden van eigen bereikbaarheidsgegevens in het patiëntenadresboeken het opzoeken van zorgaanbieders in de zorgaanbiedergids,

(e) het aanmelden, opvragen en versturen van eigen patiëntgegevens,

(f) het er op geattendeerd worden wanneer patiëntgegevens door eenzorgaanbieder toegestuurd zijn.


Voor patiënt-/cliëntapplicaties geldt veelal hetzelfde als voor zorgaanbieder-applicaties. Immers, ook patiënten/cliënten kunnen behoefte hebben aan:

• een elektronische agenda: om zelfstandig een afspraak met eenzorgaanbieder te kunnen maken,

• een elektronisch dossier inkijken: om hun recht uit te oefenen tot inzage inhun dossier bij de zorgaanbieder,

• elektronische post: om vragen te kunnen stellen aan een zorgaanbieder.

Opmerkingen:

• ad (c) Hier kan het bijv. gaan om telemedicine, het bijhouden van eenlogboek met eigen metingen of medicatiegebruik, het vastleggen vanwensen met betrekking tot euthanasie, reanimatie, etc.

• ad (e) Langs deze weg krijgen patiënten/cliënten de mogelijkheid omzelfstandig inzage te krijgen in de eigen patiëntdossiers bij de verschillendezorgaanbieders. Het recht op aanvulling en vernietiging kan echter nietzelfstandig worden uitgeoefend, dat moet in overleg met deverantwoordelijke zorgaanbieder geschieden.


4.1.3 Beheerderapplicaties

Tenslotte hebben de verschillende beheerders behoefte aan ondersteuning in devorm van beheerderapplicaties. De onderstaande figuur toont dit in een UMLcollaboration diagram:

Patiëntenadresboek

Zorgaanb.gids

Schakelpunt

Toegangslog

Zorgaanb.register

Patiëntenregister

Autorisatieprofiel

Verwijsindex

Autorisatieprotocol


Beheerapplicatie

Registerbeheerder

Beheerapplicatie

Beheerapplicatie


Logbeheerder

Beheerapplicatie

Beheerapplicatie

Registerbeheerder

(a) beheren >

(e) beheren > < beheren (d)

< beheren (b)

< beheren (c)

Aldus zijn applicaties wenselijk die beheerders in staat stellen tot:

(a) het beheren van het schakelpunt en de verwijsindex,

(b) het bijhouden van het autorisatieprotocol en de autorisatieprofielen,

(c) het raadplegen van de toegangslog,

(d) het beheren van het patiëntenregister,

(e) het beheren van het zorgaanbiederregister.

Anders dan zorgaanbieders en patiënten/cliënten, zullen beheerders geenpatiëntgegevens beheren of uitwisselen.


4.2 Gebruiksscenario’s

De onderstaande figuur toont welke gebruikers welke functionaliteit nodig hebbenvan de ICT-voorzieningen in de zorg, in een UML use case diagram:

5.bijhouden autor.

profiel

3.beheren autor.

protocol

6.beheren

schakelpunt

Zorgverlener/medewerker

2.uitwisselenpatiëntgeg.

4.raadplegentoegangslog

ICT-voorzieningen in de zorg

Patiënt/cliënt


Logbeheerder

0.2in/uitloggen

sessie

<<uses>>

9.beherenregisters

Registerbeheerder

0.3selecteren

patiënt/cliënt

<<uses>>

0.4selecteren

zorgaanbieder

<<uses>>

1.beheren

patiëntgeg. 0.1aansluitenapplicatie

<<uses>>


7.beheren mand.

tabel

Applicatiebeheerder

8.beherenapplicatie

De gebruiksscenario’s komen overeen met de benodigde functionaliteit beschrevenin de paragrafen 3.5 tot en met 3.8. Merk op dat de gebruiksscenario’s 0.1 tot enmet 0.4 geen zelfstandige gebruiksscenario’s zijn, maar een onderdeel van deandere gebruiksscenario’s vormen.


De onderstaande figuur geeft een nadere uitwerking van gebruiksscenario 1,beheren patiëntgegevens, in een UML use case diagram:

1.1bijhouden

patiëntgeg.<<uses>>

1.1.1toevoegengegevens

1.2publicerenpatiëntgeg.

<<uses>>

1.2.1vrijgevengegevens

1.2.2afschermengegevens

1.1.2verwijderengegevens

1.3abonnerenpatiëntgeg.

<<uses>>

1.beheren

patiëntgeg.

<<uses>>

<<uses>>

1.4koppelen

patiëntgeg.<<uses>>

1.4.1voorlopigkoppelen

1.4.2definitiefkoppelen

<<uses>>

<<uses>>

1.3.1aanmelden

abonn.1.3.2

afmeldenabonn.

De onderstaande figuur geeft een nadere uitwerking van gebruiksscenario 2,uitwisselen patiëntgegevens, in een UML use case diagram:

2.2versturen patiënt

berichten

2.1.opvragen patiënt

gegevens

<<uses>>

2.1.1.opvragen

index2.1.2.

opvragengegevens

<<uses>>

2.2.1versturenbericht2.2.2

ontvangenbericht

<<uses>>2.1.3.

opvragenmultimedia

<<uses>> 2.2.3klaarzetten

bericht

2.3overdragenpatiëntgeg.

<<uses>>

2.uitwisselenpatiëntgeg.

<<uses>>

<<uses>><<uses>>

2.3.1verzoekenoverdracht

2.3.2beantwoorden

overdracht

<<uses>> 2.2.4ophalenbericht

<<uses>>2.3.1

afrondenoverdracht

In de navolgende paragrafen worden deze gebruiksscenario’s nader uitgewerkt naareisen en wensen van de gebruiker. Deze gebruiksscenario’s komen later terug inparagraaf 4.4, alwaar de interacties tussen de objecten voor elk van de gebruiks-scenario’s worden uitgewerkt. Gebruiksscenario 1.3 abonneren patiëntgegevens isnog niet uitgewerkt. Dit wordt in een latere versie voorzien.


Bij de uitwerking van de bovenstaande gebruiksscenario’s in de navolgendeparagrafen, zal blijken dat er behoefte is aan generalisaties van de bovengenoemdegebruikers. Deze worden samengevat in de onderstaande figuur:


Patiënt/cliënt


Logbeheerder

Registerbeheerder


Beheerder

Gebruiker

Medewerker

Zorgverlener


4.2.1 Aan/afsluiten zorgaanbiederapplicatie m.b.t.schakelpunt

Nadat een zorgaanbiederapplicatie eenmaal is gekoppeld aan het schakelpunt, zieparagraaf 4.2.16, kunnen andere applicaties via het schakelpunt in principeberichten sturen naar deze zorgaanbiederapplicatie. Dat is echter niet altijdgewenst, bijvoorbeeld wanneer de applicatie nog niet operationeel is bij dezorgaanbieder, of in onderhoud gaat, etc.

Daarom moet men een zorgaanbiederapplicatie kunnen aansluiten op, en afsluitenvan, het schakelpunt. Daartoe moet de beheerder melden aan het schakelpunt watde beschikbaarheidstoestand van die applicatie is. Deze toestand omvat:

• koppeltoestand die aangeeft of de applicatie op de operationele ZIM, deuitwijk-ZIM of de test-ZIM wordt aangesloten, zie paragraaf 5.5.2,

• actiemodus die aangeeft of de applicatie actief is om berichten uit tewisselen en te verwerken, gereed is om actief te worden, dan wel gepland inonderhoud is of onverhoopt in storing is, zie paragraaf 5.7.4.

Idealiter stuurt de applicatie een bericht naar het schakelpunt voor iederetoestandsverandering, zie paragraaf 5.7.4. Het schakelpunt weet dan of dieapplicatie wel of niet beschikbaar is om berichten te verwerken. In geval vanstoring zal een applicatie dat vaak niet meer kunnen melden. In geval vanonderhoud kan de beheerder erbij vermelden hoe lang het gaat duren.

Echter, voor toestandsveranderingen zijn nog geen berichten gedefinieerd. Alduszal de applicatiebeheerder dergelijke toestandsveranderingen voorlopig telefonischmoeten melden aan de schakelpuntbeheerders, waarna zij de nieuwe toestandhandmatig kunnen vastleggen. De eisen in deze paragraaf zijn daarom allemaalvoorzien van het etiket {toekomst}.

Ontwerpbeslissingen:

[B1] De beheerder van een zorgapplicatie meldt een nieuwe beschikbaarheids-toestand telefonisch of per e-mail aan de beheerders van het schakelpunt.

[B2] {toekomst} Een zorgapplicatie meldt aan het schakelpunt een nieuwebeschikbaarheidstoestand door het sturen van een bericht over eenbeveiligde verbinding die is opgezet met het systeemvertrouwensmiddel.

Hier zijn aldus de volgende gebruiksscenario’s te onderkennen:

• Gebruiksscenario 0.1.1: aansluiten applicatie op schakelpunt,

• Gebruiksscenario 0.1.2: schakelpunt legt verbinding met applicatie,

• Gebruiksscenario 0.1.3: afsluiten applicatie van schakelpunt.

Bij (gebruiksscenario 0.1.1) aansluiten op schakelpunt gelden de volgende eisen enwensen:

(a) {toekomst} De gebruiker moet voor zijn zorgaanbiederapplicatie devolgende stuurparameters kunnen instellen:


• koppeltoestand: operationeel, uitwijk of test,• actiemodus: gereed, actief, onderhoud of storing,

(b) {toekomst} De gebruiker moet zijn applicatie kunnen aansluiten op hetschakelpunt door.

• het opzetten van een beveiligde verbinding op basis van hetsysteemgebonden vertrouwensmiddel,

• en het sturen van een toestandsbericht met de actiemodus actief, zieparagraaf 5.7.4,

Bij (gebruiksscenario 0.1.2) schakelpunt legt verbinding met applicatie gelden devolgende eisen en wensen:

(c) De zorgapplicatie moet na aansluiten op het schakelpunt toestaan dat hetschakelpunt een beveiligde verbinding opzet.

Bij (gebruiksscenario 0.1.3) afsluiten van schakelpunt gelden de volgende eisen enwensen:

(d) {toekomst} De gebruiker moet zijn applicatie kunnen afsluiten van hetschakelpunt door:

• het opzetten van een beveiligde verbinding op basis van hetsysteemgebonden vertrouwensmiddel,

• het sturen van een toestandsbericht met de volgende gegevens:o de nieuwe actiemodus, onderhoud of storing, zie paragraaf 5.7.4,o reden van afsluiten,o verwachte tijdstip van weer beschikbaar zijn,

• het afsluiten van de beveiligde verbinding.

Voor gebruiksscenario 0.1.1 en 0.1.3 is het nodig dat de gebruiker heeft ingelogdals beheerder.

Opmerkingen:

• Ad (a) Door het instellen van de koppeltoestand wordt bepaald op welke ZIM(operationele ZIM, test-ZIM of uitwijk-ZIM) zal worden aangesloten.

• Ad (b) Het melden van de actiemodus aan het schakelpunt kan in detoekomst worden gecombineerd met het synchroniseren van allerleistuurparameters uit het schakelpunt.

• Ad (c) Dit is eigenlijk geen gebruikersscenario, maar iets dat optreedt alsonderdeel van andere scenario’s.

• Ad (d) De beheerder kan behalve onderhoud ook een storing van zijnzorgaanbiederapplicatie melden. Dat moet dan vermoedelijk geschieden meteen andere applicatie.

• Het kunnen verzenden van een toestandsbericht over een beveiligdeverbinding op basis van het systeemgebonden vertrouwensmiddel, geeft demogelijkheid dat een beheerder zonder UZI-pas, maar wel met een lokaalvertrouwensmiddel, deze taken kan uitvoeren.


4.2.2 In-/uitloggen gebruiker

Wanneer een zorgverlener/medewerker via een applicatie op een werkplek gebruikwil maken van zijn bevoegdheden tot het landelijk uitwisselen van patiëntgegevens,dient hij zich eerst te identificeren en authenticeren. Zoals beschreven in paragraaf3.9.6 kan dat op verschillende vertrouwensniveaus.

Voor het vertrouwensniveau laag is zwakke authenticatie aan het begin van eensessie voldoende, dan wel normale of sterke authenticatie aan het begin van eenwerkdag. Dit kan als volgt worden geïmplementeerd:

• Inloggen aan het begin van iedere sessie, met een wachtwoord. Uitloggenaan het einde van de sessie.

• Inloggen aan het begin van een werkdag, door het invoeren van eenvertrouwensmiddel in een leesapparaat op zijn werkplek. Uitloggen aan heteinde van de werkdag.

Voor het vertrouwensniveau midden is het nodig dat voor iedere sessie sterkeauthenticatie plaatsvindt en vervolgens voor iedere landelijke uitwisseling vanpatiëntgegevens normale authenticatie plaatsvindt. Dit kan als volgt wordengeïmplementeerd:

• Inloggen aan het begin van iedere sessie, door het invoeren van zijnvertrouwensmiddel in een leesapparaat op zijn werkplek en het intoetsenvan een toegangscode. Uitloggen aan het einde vande sessie.

• Daarnaast moet voor iedere gebruikersinteractie (aanmelden, opvragen,versturen, etc.) met patiëntgegevens gecontroleerd worden dat hetvertrouwensmiddel in het leesapparaat ingevoerd is.

Voor het vertrouwensniveau hoog is het nodig dat voor iedere landelijkeuitwisseling van patiëntgegevens sterke authenticatie plaatsvindt. Dit kan als volgtworden geïmplementeerd:

• Voor iedere gebruikersinteractie (aanmelden, opvragen, versturen, etc.) metpatiëntgegevens moet het vertrouwensmiddel in het leesapparaat ingevoerdzijn of opnieuw ingevoerd worden en moet een toegangscode wordeningetoetst. Na uitnemen van het vertrouwensmiddel verdwijnen devertrouwelijke patiëntgegevens automatisch van het scherm.

Voor het uitloggen is geen vertrouwensmiddel vereist, zoals dat voor inloggen welvereist is. Het uitloggen aan het einde van een sessie of een werkdag, kan opverschillende manieren:

• Uitloggen op commando: dit als enige manier is niet veilig omdat dezorgverlener/medewerker dit gemakkelijk kan vergeten of nalaten bij hetverlaten van zijn werkplek, en de sessie dan blijft doorlopen;

• Automatisch uitloggen door uitnemen vertrouwensmiddel: dit als enigemanier is niet veilig want het brengt de zorgverlener/medewerker in deverleiding zijn vertrouwensmiddel in het leesapparaat achter te laten omniet te worden uitgelogd bij het tijdelijk verlaten van de werkplek,


• Automatisch uitloggen na een tijdsinterval: dit als enige manier is redelijkveilig, maar is onwerkbaar voor de zorgverlener/medewerker dieonregelmatig op zijn werkplek zit,

• Automatisch uitloggen na een tijdsinterval na verwijderen van hetvertrouwensmiddel: dit is het meest veilig en werkbaar.


[B3] Een zorgverlener/medewerker moet voor vertrouwensniveau midden aanhet begin van een sessie inloggen door het invoeren van een persoonlijkvertrouwensmiddel én het intoetsen van een persoonlijke toegangscode.Daarna kan hij patiëntgegevens landelijk uitwisselen, gedurende een sessiedie wordt onderbroken na verwijderen van het vertrouwensmiddel. Als hetvertrouwensmiddel binnen een bepaald tijdsinterval opnieuw wordtingevoerd, mag de sessie worden voortgezet zonder het hoeven invoerenvan de toegangscode. Anders eindigt de sessie definitief na verstrijken vandit tijdsinterval.

[B4] {toekomst} Een zorgverlener/medewerker moet voor vertrouwensniveauhoog voor iedere toegang tot patiëntgegevens inloggen door het invoerenvan een persoonlijk vertrouwensmiddel én een persoonlijke toegangscode.


• (gebruiksscenario 0.2.1) inloggen van een sessie.

• (gebruiksscenario 0.2.2) uitloggen van de sessie.

Bij (gebruiksscenario 0.2.1) inloggen sessie gelden de volgende eisen en wensen:

(a) Een zorgverlener/medewerker moet een sessie voor het landelijk uitwisselenvan patiëntgegevens op vertrouwensniveau laag kunnen starten door: hetinvoeren van zijn gebruikersnaam en wachtwoord.

(b) Een zorgverlener/medewerker moet een sessie voor het landelijk uitwisselenvan patiëntgegevens op vertrouwensniveau midden kunnen starten door:het invoeren van zijn vertrouwensmiddel op de werkplek, en het invoerenvan de bijbehorende toegangscode.

(c) Een zorgverlener/medewerker moet een sessie voor het landelijk uitwisselenvan patiëntgegevens op vertrouwensniveau midden tijdelijk kunnenonderbreken door: het uitnemen van zijn vertrouwensmiddel op dewerkplek.

(d) Een zorgverlener/medewerker moet die sessie voor het landelijk uitwisselenvan patiëntgegevens op vertrouwensniveau midden binnen het tijdsintervalgebruiker-max-kaart-uit na onderbreking kunnen voortzetten door: hetopnieuw invoeren van zijn vertrouwensmiddel op de werkplek, zonder hetinvoeren van de toegangscode.

Bij (gebruiksscenario 0.2.2) uitloggen sessie gelden de volgende eisen en wensen:


(e) Een zorgverlener/medewerker moet een sessie voor het landelijk uitwisselenvan patiëntgegevens op vertrouwensniveau laag of midden op commandokunnen afsluiten.

(f) Een sessie voor het landelijk uitwisselen van patiëntgegevens opvertrouwensniveau midden moet in de volgende gevallen automatischworden afgesloten:

• wanneer het vertrouwensmiddel meer dan het tijdsinterval gebruiker-max-kaart-uit uit de kaartlezer is verwijderd,

• wanneer deze sessie reeds gedurende het tijdsinterval gebruiker-max-sessie-duur open staat,

• wanneer de gebruiker via deze sessie gedurende het tijdsintervalgebruiker-max-sessie-onbruik geen gegevens meer landelijk heeftuitgewisseld,

• wanneer de gebruiker zijn gebruikersapplicatie gedurende hettijdsinterval gebruiker-max-applicatie-onbruik niet meer heeftgebruikt.

{toekomst} Voor deze gebruiksscenario’s is het nodig dat de zorgaanbieder-applicatie zich als actief heeft gemeld bij het schakelpunt (zie gebruiksscenario0.1.1).

Opmerkingen:

• Het inloggen met een fysiek vertrouwensmiddel (bijv. chipkaart) kan doorzorgverleners/medewerkers als gebruiksongemak worden ervaren, maarbiedt ook nieuwe mogelijkheden. Zo wordt het mogelijk in een apotheeksnel te wisselen van werkplek, waarbij de gebruikersessie met hetvertrouwensmiddel wordt meegenomen, dat wil zeggen de sessie wordt opde oude werkplek afgebroken en op de nieuwe werkplek voortgezet.

• Het moeten inloggen om landelijk patiëntgegevens te kunnen uitwisselen,staat in principe los van het moeten inloggen voor de toegang tot depatiëntgegevens in het eigen patiëntdossier. Het eerste valt onderlandelijk beleid, het tweede is een zaak voor de zorgaanbieder zelf. Tochkan een applicatie deze twee op slimme wijze combineren, door gebruikvan hetzelfde vertrouwensmiddel.

• Het scenario van inloggen kan vervlochten met een ander gebruiks-scenario plaatsvinden. Bijv. als een zorgverlener/medewerker ongemerktwas uitgelogd en vervolgens patiëntgegevens opvraagt, dan kan deapplicatie na het opvraagcommando de gebruiker vragen opnieuw in teloggen.

• Ad [B3] en (d) Voorzover NICTIZ bekend is, is er (nog) geenhardware/software verkrijgbaar die het mogelijk maakt dat geentoegangscode hoeft te worden ingetoetst wanneer het vertrouwensmiddelbinnen een bepaald tijdsinterval opnieuw wordt ingevoerd. Dit betekentdat bij wisseling van werkplek altijd opnieuw een toegangscode moetworden ingetoetst.


4.2.3 Selecteren patiënt/cliënt

Zoals beschreven in paragraaf 3.8.2 zal een zorgaanbieder die contact heeft meteen patiënt/cliënt, die patiënt/cliënt moeten identificeren door het bepalen vandiens landelijke patiëntnummer (BSN) en zonodig authenticeren door hetcontroleren van diens Wettelijk Identificatie Document (WID).

Bovendien zal de zorgaanbieder bij het eerste contact na de invoering van het BSNextra controles moeten uitvoeren, zoals uitgewerkt in bijlage A:

• het BSN opvragen of verifiëren bij het landelijke patiëntenregister,• het WID controleren met de patiënt/cliënt,• het WID controleren op echtheidskenmerken,• {toekomst} de geldigheid van het WID controleren,• het patiëntdossier inhoudelijk controleren met de patiënt/cliënt,• de identificerende gegevens zonodig bijwerken.

Nadat het BSN is opgevraagd of geverifieerd in het landelijke patiëntenregister,mag het BSN tezamen met de identificerende gegevens worden opgenomen in delokale patiëntenindex bij de zorgaanbieder, zodat de zorgaanbieder bij volgendecontacten niet steeds het landelijke patiëntenregister hoeft te raadplegen. Omdateen zorgaanbieder voor een verschijnende patiënt/cliënt niet bij voorbaat weet ofdit zijn eerste contact na de invoering van het BSN is, zal hij eerst in zijnpatiëntenindex gaan zoeken.

Omdat de extra controles in de praktijk niet altijd bij het eerste contact kunnenworden uitgevoerd, zal voor iedere patiënt/cliënt moeten worden bijhouden welkecontroles wel/niet zijn uitgevoerd, opdat de zorgaanbieder bij een volgend contactkan worden geattendeerd op achterstallige controles.


[B5] Een zorgaanbieder zoekt een patiënt/cliënt eerst in zijn patiëntenindex endaarna zonodig in het landelijke patiëntenregister.

[B6] Een zorgaanbieder moet voor iedere patiënt/cliënt bijhouden welkecontroles wel/niet zijn uitgevoerd.

Tenslotte zal de zorgaanbieder de bereikbaarheidsgegevens van de patiënt/cliënt inzijn patiëntenindex actueel willen houden. Sommige bereikbaarheidsgegevens,zoals het woonadres, zijn als identificerende gegevens op te vragen uit hetlandelijke patiëntregister.

Wanneer de originele identificerende gegevens en/of bereikbaarheidgegevens ooitwijzigen, wil de zorgverlener/medewerker daarover worden ingelicht, bij voorkeurdoor het landelijke patiëntenregister of anders door middel van een gezamenlijkpatiëntenadresboek, dat eventueel door patiënten/cliënten zelf kan wordenbijgewerkt.

Zoals onderbouwd in paragraaf A.5, zijn hier aldus de volgende gebruiksscenario’ste onderkennen:

• (gebruiksscenario 0.3.1) identificeren patiënt/cliënt.

• (gebruiksscenario 0.3.2) authenticeren patiënt/cliënt.


• (gebruiksscenario 0.3.3) controleren patiëntdossier.

• (gebruiksscenario 0.3.4) bijwerken patiëntenindex.

Bij (gebruiksscenario 0.3.1) identificeren patiënt/cliënt gelden de volgende eisen enwensen:

(a) De gebruiker moet een patiënt/cliënt kunnen opzoeken in de lokalepatiëntenindex dan wel de patiëntdossiers bij de zorgaanbieder door hetinvoeren van identificerende gegevens, waarna wordt getoond:

o of de patiënt/cliënt is gevonden, en zo jao of het BSN wel/niet is opgevraagd of geverifieerd in het landelijke

patiëntenregister.

(b) Indien bij (a) de patiënt/cliënt niet is gevonden of blijkt dat nog geenpatiëntnummer succesvol is opgevraagd of geverifieerd bij het landelijkepatiëntenregister, moet de gebruiker na invoeren van (een deel van) deonderstaande identificerende gegevens, het BSN van die patiënt/cliënt uithet landelijke patiëntenregister gepresenteerd of bevestigd kunnen krijgen:

o landelijk patiëntnummer (BSN)o geboortenaamo voorvoegsels geboortenaamo voornameno eerste voorlettero geslachtsaanduidingo geboortedatumo geboorteplaatso geboortelando postcodeo straatnaamo huisnummero huislettero huisnummertoevoegingo aanduiding bij huisnummero gemeente van inschrijving

waarbij:o de gebruiker bij het invullen eerst langs de attributen van de

zoekpaden, zoals gedefinieerd in [BSN], wordt geleid,o {toekomst} plaatsnamen zonodig worden vertaald naar de gemeente

waarvan zij onderdeel uitmaken,o diakritische tekens kunnen worden gepresenteerd,o eventueel foutief gespelde gegevens zo mogelijk automatisch worden

gecorrigeerd.

(c) Indien bij (b) de patiënt/cliënt is gevonden, moet de gebruiker het BSNkunnen koppelen aan diens identificerende gegevens in de patiëntenindex ofhet patiëntdossier waarbij automatisch wordt vastgelegd bij hetovergenomen patiëntnummer:

o de bron van het BSN,o datum en tijd van koppelen,o zorgaanbiedernummer van de gebruiker.


Bij (gebruiksscenario 0.3.2) authenticeren patiënt/cliënt gelden de volgende eisenen wensen:

(d) De gebruiker moet na identificatie van een patiënt/cliënt:o worden gewaarschuwd indien diens WID nog niet is gecontroleerd op

gelijkenis met de patiënt/cliënt,o kunnen vastleggen in de patiëntenindex of het patiëntdossier dat hij

heeft gecontroleerd of het WID hoort bij de patiënt/cliënt, ondervermelding van:

§ resultaat van de controle§ datum en tijd§ zorgaanbiedernummer van de gebruiker§ type en nummer van het WID.

(e) De gebruiker moet na identificatie van een patiënt/cliënt:o worden gewaarschuwd indien diens WID nog niet is gecontroleerd op

echtheidskenmerken,o kunnen vastleggen in de patiëntenindex of het patiëntdossier dat hij

diens WID heeft gecontroleerd op echtheidskenmerken, ondervermelding van:


(f) {toekomst} De gebruiker moet na identificatie van een patiënt/cliënt:o worden gewaarschuwd indien de geldigheid van het WID nog niet is

gecontroleerd,o de geldigheid van het WID kunnen controleren door raadplegen van

het relevante WID-register na invoeren van de volgende WID-kenmerken:

§ type WID§ nummer van het WID

o kunnen vastleggen in de patiëntenindex of het patiëntdossier dat hijde geldigheid van diens WID heeft gecontroleerd, onder vermeldingvan:


Bij (gebruiksscenario 0.3.3) controleren patiëntdossier gelden de volgende eisen enwensen:

(g) De gebruiker moet na identificatie van een patiënt/cliënt:o worden gewaarschuwd indien diens patiëntdossier nog niet

inhoudelijk is gecontroleerd met de patiënt/cliënt,o kunnen vastleggen in de patiëntenindex of het patiëntdossier dat hij

heeft gecontroleerd of het patiëntdossier inhoudelijk hoort bij depatiënt/cliënt, onder vermelding van:

§ resultaat van de controle§ datum en tijd§ zorgaanbiedernummer van de gebruiker,


§ zorgaanbiedernummer van de mandaterende zorgverlener,indien van toepassing

o het BSN zonodig kunnen ontkoppelen van het patiëntdossier.

(h) De gebruiker moet de eerste keer nadat alle vereiste controles positief zijn,worden doorgeleid naar gebruiksscenario 1.2.1 vrijgeven patiëntgegevens,voorzover de patiënt/cliënt niet reeds initieel was gekoppeld.

Bij (gebruiksscenario 0.3.4) bijwerken patiëntenindex gelden de volgende eisen enwensen:

(i) De gebruiker moet na identificatie van een patiënt/cliënt:o worden gewaarschuwd indien de identificerende gegevens in de

patiëntenindex of diens patiëntdossier niet overeenkomen met die inhet landelijke patiëntenregister,

o diens identificerende gegevens uit het landelijke patiëntenregisterdesgewenst kunnen overnemen naar de patiëntenindex of dienspatiëntdossier, onder automatische vermelding van:

§ datum en tijd§ zorgaanbiedernummer van de gebruiker.

(j) {toekomst} De gebruiker moet kunnen aangeven dat hij voor een bepaaldepatiënt/cliënt wil worden ingelicht door een patiëntenadresboek overeventuele wijzigingen van diens identificerende gegevens enbereikbaarheidsgegevens.

(k) {toekomst} De gebruiker moet, na een signaal dat de identificerendegegevens en bereikbaarheidsgegevens van een patiënt zijn gewijzigd, denieuwe gegevens kunnen overnemen in de patiëntenindex of dienspatiëntdossier, waarbij automatisch wordt vastgelegd:

o datum en tijd van overnemen,o zorgaanbiedernummer van de gebruiker.

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd alszorgverlener of medewerker op vertrouwensniveau laag of midden (ziegebruiksscenario 0.2.1). In geval van gebruiksscenario 0.3.3 moet de medewerkergemandateerd zijn door een zorgverlener.

Opmerkingen:

• Binnen een zorginstelling kan men volstaan met eenmalige identificatie enauthenticatie van een patiënt/cliënt, indien de verschillende afdelingen ofzorgverleners het BSN of een daaraan gekoppeld lokaal patiëntnummergebruiken. De controle van de dossiers zal iedere afdeling of zorgverlenerafzonderlijk moeten doen, indien zij afzonderlijke dossiers hebben, zie ookad (g).

• Authenticatie van een patiënt/cliënt is niet mogelijk als de zorgaanbiederdaarmee geen persoonlijk contact heeft. Bijv. wanneer een ander namenseen patiënt/cliënt diens medicatie afhaalt bij een apotheek. Of wanneer eenstreeklaboratorium een bloedmonster van een patiënt/cliënt krijgtaangeboden. Zolang de verwijzende zorgaanbieder de patiënt/cliënt welheeft geauthenticeerd, zijn de risico’s beperkt.


• Ad (a) Dit is de enige stap die altijd plaatsvindt voor ieder contact tusseneen zorgaanbieder en een patiënt/cliënt. De overige stappen vinden alleenplaats als na de invoering van het BSN nog achterstallige controles moetenworden uitgevoerd.

• Ad (a) en (b) Voor het zoeken in de patiëntdossiers bij de zorgaanbiederhoeven niet dezelfde zoekpaden te worden gebruikt als voor het opvragenen verifiëren in het landelijke patiëntenregister. Lokaal zoeken kan immersverscheidene hits opleveren waaruit kan worden gekozen, echter met hetrisico van fout kiezen. Het landelijk patiëntregister biedt geenzoekfunctionaliteit maar alleen functies voor het opvragen en verifiëren vanhet BSN. Daarmee wordt de kans op fout kiezen geminimaliseerd, maar hetbetekent wel dat de zorgverlener eerst zelf (al dan niet met behulp van eenlokale zoekfunctie) de patiënt moet identificeren.

• Ad (b) De identificerende gegevens kunnen worden afgelezen van het WID,indien aanwezig, anders kan de patiënt/cliënt zelf worden bevraagd. Eenpatiëntnummer kan in de toekomst eventueel automatisch ingelezenworden, indien de patiënt/cliënt een geschikt vertrouwensmiddel (bijv.e-NIK) heeft en de zorgverlener/medewerker een geschikt leesapparaat.

• Ad (b) In geval van een landelijk patiëntenregister, moet er voor eenNederlands ingezetene altijd één match zijn. Als er geen match is, dan moetde patiënt/cliënt zijn eigen GBA-gegevens bij het gemeentehuis maar eensgaan controleren. Niet-ingezetenen kunnnen straks een BSN krijgen naregistratie in het RNI.

• Ad (b) Er zijn slechts beperkte mogelijkheden om foutief gespelde namen tecorrigeren. Zo kunnen bijv. ontbrekende diakrieten worden aangevuld.Echter, de naam Jansen levert geen Janssen op. Ook is het niet mogelijk omna een mislukte match, met behulp van fonetische matching, een lijst metalternatieven te presenteren. Dit zou gemakzucht en onzorgvuldigheid in dehand kunnen werken.

• Ad (c) De bron van het BSN kan zijn: de SBV-Z, de GBA, maar ook de CoV-functie van VeCoZo. Zorgaanbieders mogen de laatste bron raadplegen tenbehoeve van hun declaratieverkeer. Voor het landelijk uitwisselen vanmedische patiëntgegevens moet tenminste de SBV-Z of de GBA zijngeraadpleegd.

• Ad (d) Wanneer een patiënt/cliënt aan een zorgverlener/medewerker geenWID kan overleggen, moet hij dat binnen een bepaalde tijd alsnogoverleggen. Dit geldt ook voor telefonische consulten.

• Ad (a) Hoewel huisartsen hun patiënten/cliënten veelal kennen en dusminder behoefte hebben aan een compleet zoekpad conform [BSN], kan hetoptimale zoekpad cruciaal blijken, bijv. om meerlingen uit elkaar te houden.

• Ad (g) Grote zorgaanbieders, zoals ziekenhuizen, zullen per afdeling eenafzonderlijk medisch dossier hebben, zie ook paragraaf 4.3.1. In dergelijkegevallen zal iedere afdeling deze controle afzonderlijk moeten uitvoeren enhet resultaat daarvan per dossier moeten vastleggen. Deze controle isoverigens niet noodzakelijk voor dossiers waarvan de inhoud nooit zalworden uitgewisseld met andere zorgaanbieders.


• Ad (j) Wanneer de GBA deze faciliteit gaat bieden, zal er vermoedelijk eenlimiet komen aan de termijn waarop de zorgverlener wordt ingelicht. Vooreen ziekenhuis heeft het geen zin om van alle patiënten/cliënten deadreswijzigingen bij te houden, voor een huisarts echter wel.

• Inloggen op vertrouwensniveau laag heeft niet alleen het voordeel dat degebruiker geen UZI-pas nodig heeft, het biedt de applicatie tevens demogelijkheid om ’s nachts op basis van een behandelagenda het BSN vanalle patiënten voor de volgende dag te verifiëren.

Openstaande punten:

• Hoewel de SBV-Z na opvraag van het BSN het woonadres kan opleveren,kan de SBV-Z slechts in beperkte mate de rol van patiëntenadresboekvervullen. Momenteel is alleen de GBA in beeld als landelijkpatiëntadresboek. Volgens de wet moeten GBA-afnemers ieder afzonderlijktoestemming krijgen voor aansluiting op de GBA. Er wordt nog onderzocht inhoeverre de basisinfrastructuur hiervoor voorzieningen kan of moet leveren.

Voorbeeld van (b) waarbij een zorginstellingmedewerker voor een patiënt/cliëntaan de balie een foutieve geboorteplaats intoetst:

Actie<opvragen> Patiëntnr (BSN) Geslacht [Vrouw]

Voornamen GemeenteVoorletter J StraatnaamVoorvoegsels Huisnummer Geboortenaam Jong HuisletterGeboortedatum 11-11-1911 Huisnr.toev.Geboorteplaats Amstedam Aanduid.huisnr.Geboorteland Postcode

Het resultaat na het aanklikken van <opvragen> zou er als volgt kunnen uitzien:

Actie<kiezen> Patiëntnr (BSN) 1234567890 Geslacht [Vrouw]<overnemen> Voornamen Johanna Gemeente Rotterdam<afsluiten> Voorletter J Straatnaam Amstelweg

Voorvoegsels de Huisnummer 11Geboortenaam Jong Huisletter AGeboortedatum 11-11-1911 Huisnr.toev.Geboorteplaats Amsterdam ! Aanduid.huisnr.Geboorteland Nederland Postcode 1111 ZZBSN opgevraagd uit SBV-Z

<kiezen> WID nog NIET gecontroleerd met patiënt/cliënt !<kiezen> WID nog NIET op echtheid gecontroleerd !<kiezen> WID nog NIET op geldigheid gecontroleerd !<kiezen> Dossier nog NIET gecontroleerd met patiënt/cliënt<kiezen> Dossier nog NIET geactualiseerd !

Bovenstaande tabellen zijn een bescheiden poging tot weergave van eendialoogscherm waarbij:


• <xxx> een knop voorstelt die geselecteerd kan worden (al dan niet door hetaanklikken met de muis)

• [xxx] een veld voorstelt dat ingevuld kan worden (al dan niet door hetaanklikken van de gewenste optie binnen een lijst van opties)


4.2.4 Selecteren zorgaanbieder

Zoals beschreven in paragraaf 3.8.3 moeten zorgaanbieders elkaar elektronischkunnen opzoeken, identificeren en bereiken.

Wanneer een zorgverlener zijn patiënt/cliënt wil doorverwijzen naar eenzorgaanbieder met bepaalde zorgdiensten, in een bepaald specialisme, in eenbepaalde regio, etc. moet hij vrij kunnen zoeken in een landelijke zorgaanbieder-gids, op basis van verschillende zoekcriteria. Sommige patiënten/cliënten willen ditook zelfstandig kunnen doen.

Wanneer een zorgverlener of zijn patiënt/cliënt eenmaal een zorgaanbieder heeftgekozen, moet hij diens actuele bereikbaarheidsgegevens kunnen opvragen uitdeze zorgaanbiedergids. Belangrijk onderdeel daarvan is het adres van dezorgaanbiederpostbus, opdat aan deze zorgaanbieder een patiëntbericht kanworden toegestuurd. Ook belangrijk is te weten welke zorgtoepassingen entoepassingsrollen worden ondersteund, zie ook paragraaf 4.1. Omdat telefoon-nummers, openingstijden, spreekuren, etc. veranderlijk zijn, moeten deze door dezorgaanbieders vrij kunnen worden bijgewerkt.


[B7] Voor zorgaanbieders moeten de aangeboden zorgdiensten en debereikbaarheidsgegevens door de zorgaanbieder zelf kunnen wordenbijgewerkt en door andere zorgaanbieders worden opgevraagd.

Wanneer die andere zorgaanbieder een opdracht, bijv. een medicatievoorschrift ofeen verwijsbrief, krijgt van een onbekende zorgverlener, wil de ontvangendezorgverlener kunnen controleren wie de versturende zorgverlener is, welke functiehij heeft, voor wie hij werkt, etc. Hiervoor moet hij een zorgaanbiederregisterkunnen raadplegen, waarvan de juistheid wordt gewaarborgd door een autoriteit.


• (gebruiksscenario 0.4.1) opzoeken zorgaanbieder in de zorgaanbiedergids.

• (gebruiksscenario 0.4.2) opvragen bereikbaarheidsgegevens uit dezorgaanbiedergids.

• (gebruiksscenario 0.4.3) bijwerken bereikbaarheidsgegevens in dezorgaanbiedergids.

• (gebruiksscenario 0.4.4) controleren zorgaanbieder in het zorgaanbieder-register.

Bij (gebruiksscenario 0.4.1) opzoeken zorgaanbieder gelden de volgende eisen enwensen:

(a) De gebruiker moet vrij kunnen zoeken in de zorgaanbiedergids en daarbijper zorgaanbieder de onderstaande gegevens gepresenteerd krijgen.

o naamo vestigingsplaatso in geval van een zorginstelling bovendien:

• type zorginstelling


• eventueel lijst van afdelingen binnen deze zorginstellingo in geval van een zorginstelling-afdeling bovendien:

• verwijzing naar de zorginstelling• eventueel lijst van zorgverleners binnen deze afdeling

o in geval van een zorginstelling-zorgverlener bovendien:• verwijzing naar zijn zorginstelling• eventueel verwijzing naar zijn afdeling• beroepstitel• specialisme(n)

o in geval van een individuele zorgverlener bovendien:• beroepstitel• specialisme(n)

(b) De gebruiker moet na invoeren van één of meer van de onderstaandeselectiecriteria, een lijst met alle matchende zorgaanbieders gepresenteerdkrijgen, waaruit de zorgverlener kan selecteren om alsnog (a) gepresenteerdte krijgen:

o {toekomst} zorginstellingtype (alleen voor zorginstellingen)o {toekomst} beroepstitel (alleen voor zorgverleners)o {toekomst} specialisme (alleen voor zorgverleners)o naamo vestigingsplaats of regio

Bij (gebruiksscenario 0.4.2) opvragen bereikbaarheidsgegevens gelden de volgendeeisen en wensen:

(c) De gebruiker moet voor een geselecteerde zorgaanbieder de volgendebereikbaarheidsgegevens gepresenteerd kunnen krijgen:

o bezoekadreso fysiek postadreso elektronisch postadres (Internet)o elektronisch postadres (HL7v3)o ondersteunde zorgtoepassingen en toepassingsrolleno telefoonnummerso {toekomst} beschikbare diensten per adreso {toekomst} openingstijden per dienst per adreso {toekomst} verwijzing naar een waarnemer

(d) De gebruiker moet een elektronisch postadres door eenvoudig aanklikkenkunnen overnemen als bestemming voor een te versturen patiëntbericht.

Bij (gebruiksscenario 0.4.3) bijwerken bereikbaarheidsgegevens gelden devolgende eisen:

(e) {toekomst} De gebruiker moet na gebruiksscenario 0.4.1 of 0.4.2, de ondergebruiksscenario 0.4.2 genoemde bereikbaarheidsgegevens kunnenbijwerken.

Bij (gebruiksscenario 0.4.4) controleren zorgaanbieder gelden de volgende eisen:

(f) {toekomst} De gebruiker moet na gebruiksscenario 0.4.1 of 0.4.2, eenzorgaanbieder kunnen selecteren en diens gegevens opvragen uit hetzorgaanbiederregister.


Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd alszorgverlener of medewerker op vertrouwensniveau laag of midden (ziegebruiksscenario 0.2.1).

Opmerkingen:

• Ad (a) In geval van het UZI-nummer als zorgaanbiedernummer, dient dezeniet te worden gepresenteerd. Het UZI-nummer is (anders dan het BSN)nadrukkelijk bedoeld als “backoffice-nummer” dat alleen “onder water”wordt gebruikt door applicaties.

• Ad (a) Zorginstelling-medewerkers staan niet in de zorgaanbiedergids,omdat zij geen formeel aanspreekpunt zijn van een zorgaanbieder.

• ad (c) Zorginstelling-zorgverleners hebben vaak geen individuelebereikbaarheidsgegevens; zij kunnen daarom volstaan met de gezamenlijkebereikbaarheidsgegevens van hun afdeling gepubliceerd in dezorgaanbiedergids, zie ook paragraaf 3.8.4.

• Ad (c) Merk op dat een zorgaanbieder verschillende elektronischepostbussen kan hebben (zie ook paragraaf 3.6.3):

o openbare internet: dit kan nuttig zijn voor ongestructureerdeberichten van vrijblijvende afzenders (bijv. patiënten)

o gesloten HL7v3: dit is noodzakelijk voor HL7v3-gestructureerde, duselektronisch verwerkbare, berichten van authenticeerbare afzenders.

• Ad (d) Ter voorkoming van fouten is het belangrijk dat eenzorgverlener/medewerker geen zorgaanbiedernummers en postadressenhoeft over te tikken. Een gebruikersvriendelijke applicatie moet ervoorzorgen dat met name het zorgaanbiedernummer en het HL7v3-postadres“onder water” kunnen blijven. In dat geval hoeven deze attributen ook niette worden getoond onder (a) resp. (c). Wel is belangrijk om te tonen DAT dezorgaanbieder een HL7-adres heeft.

• Ad (e) In principe kunnen alleen zorgverleners hun eigen bereikbaarheids-gegevens invullen en bijhouden, echter:

o in geval van een zorginstelling kan dit worden voorbehouden aan eenspecifieke verantwoordelijke,

o een HL7-postadres is een lange cijferreeks, die tijdens het invullen bijvoorkeur wordt getoetst met een lijst van uitgegeven HL7-postadressen.

• Ad (f) Het CIBG garandeert de juistheid van de gegevens in het UZI-registeren is daarom geschikt als toetsingsregister. Verificaties van zorgaanbiedersmoeten handmatig op de website uitgevoerd worden, er is geen op HL7-berichten gebaseerde koppeling geïmplementeerd.

• Sommige gebruiksscenario’s kunnen door een zorgaanbiederapplicatie ookgecombineerd worden. Het is aan de leveranciers van zorgtoepassingen omgebruikersvriendelijke dialoogschermen te ontwikkelen.

• Naast een gezamenlijke zorgaanbiedergids, kan een zorgverlener ook eeneigen zorgaanbiederadresboek beheren, met daarin de zorgaanbiederswaarmee deze zorgverlener bij voorkeur samenwerkt. De gebruiksscenario’s


voor het overnemen van bereikbaarheidsgegevens uit de zorgaanbiedergids,naar het eigen zorgaanbiederadresboek zijn hier niet uitgewerkt. Eendergelijk adresboek is een zaak voor de zorgaanbieder zelf. Het is aan deleveranciers van zorgtoepassingen om op een eventuele behoefte daaraan inte spelen.

Openstaande punten:

• Het CIBG zal een zorgaanbiedergids gaan leveren. Welke gegevens deeerste versie van deze zorgaanbiedergids precies gaat bevatten, hoe deautorisatie wordt geregeld, etc. is nog in onderzoek.

• Wanneer zorgverzekeraars straks zorgdiensten gaan inkopen bij bepaaldezorgaanbieders, zou het wenselijk zijn als het zoeken naar eenzorgaanbieder in de regio kon worden gecombineerd met het toetsen of dezorgaanbieder wel vergoed kan worden door de zorgverzekeraar van deonderhavige patiënt/cliënt. De mogelijkheden hiertoe moeten wordenonderzocht.

De onderstaande figuur geeft een voorbeeld van (b) voor de plaats Amsterdam en(c) voor een huisarts. De getoonde boomstructuur met in-/uitklapbare takken isslechts een mogelijke manier van presenteren. Overigens is een dergelijkehiërarchie met de huidige HL7-berichten nog niet op te vragen.

Zorgaanbieder (type)

Amstelkliniek (specialistisch ziekenhuis)

-

Plastische chrirurgie (afdeling)

Oogheelkunde (afdeling)

Orthopedie (afdeling)

+

+

Amstelziekenhuis (algemeen ziekenhuis)

Amstelthuis (thuiszorginstelling)

Jansen (arts, orthopedie)

Pietersen (arts, orthopedie)

Willemsen (arts, orthopedie)

Amstelpraktijk (huisartsenpraktijk)

Amsterdam

Amstel, van (arts, huisartsgeneeskunde)

Amstelzorg (verzorgingstehuis))

Amstelberg (arts, huisartsgeneeskunde)

-

+

+

Amstelapotheek (apotheek)-Gerritsen (apotheker)

Dienst Adres Openingstijd

Inloopspreekuur Amstelweg 11 wrkdg 08:00-09:00

Spreekuur op afspraak Amstelweg 11 wrkdg 10:00-13:00

Telefonisch spreekuur 020–1234567 wrkdg 10:00-13:00

Afspraken maken 020–1234568 wrkdg 08:00-09:00

Herhalingsrecepten 020–1234568 wrkdg 00:00-24:00

Noodgevallen 0612–345678 wrkdg 00:00-24:00

Waarneming AmstelPost weekend

EMD-voorschrijver HL7-adres

WDH-dossierhouder HL7-adres

Vragen beantwoorden [email protected]

mailto:[email protected]


4.2.5 Bijhouden Patiëntgegevens

Zoals beschreven in paragraaf 3.5.3, moet een zorgverlener voor iederepatiënt/cliënt allerlei patiëntgegevens kunnen bijhouden in zijn dossier. Typischebewerkingen op patiëntgegevens zijn: aanmaken, inzien, wijzigen en verwijderen.Omdat medische patiëntstukken nooit mogen worden gewijzigd, komt het erop neerdat een zorgverlener een nieuwe versie van het achterhaalde patiëntstuk moetaanmaken en toevoegen aan het dossier.

Ook mogen medische patiëntstukken niet worden verwijderd, behalve naverstrijken van de bewaartermijn of op nadrukkelijk verzoek van een patiënt/cliënt.In het laatste geval is het wenselijk dat de verwijdering ongedaan gemaakt kanworden, als de patiënt/cliënt dat wenst. Zoals beschreven in paragraaf 3.9.3, zijnhiervoor vertrouwenswaarborgen nodig.

Wanneer een zorgverlener een patiëntstuk heeft vastgelegd in zijn dossier, maarlater ontdekt dat het foutief is, kan hij dit patiëntstuk niet verwijderen, maar welherroepen door het ongeldig te maken.

Tenslotte heeft een patiënt/cliënt recht op inzage, afschrift en aanvulling op zijnpatiëntdossier, zie paragraaf 3.7.1. Een patiënt/cliënt kan dat recht eventueel ookzonder de hulp van de zorgverlener uitoefenen. Deze functies worden in een latereversie van dit document uitgewerkt.


• Gebruiksscenario 1.1.1: toevoegen patiëntgegevens aan het dossier,

• Gebruiksscenario 1.1.2: verwijderen patiëntgegevens uit het dossier.

Bij (gebruiksscenario 1.1.1) toevoegen patiëntgegevens gelden de volgende eisenen wensen:

(a) De gebruiker moet patiëntstukken kunnen aanmaken, vastleggen, fiatteren,herroepen, waarbij voor een gemandateerde gebruiker wordt vastgelegd ineen patiëntdossier namens welke zorgverlener dit wordt gedaan.

(b)o

(c) De gebruiker moet de zekerheid hebben dat patiëntstukken, na hetvastleggen daarvan in een patiëntdossier, niet ongemerkt kunnen wordengewijzigd.

(d) {toekomst} De gebruiker moet onder zijn verantwoordelijkheidaangemaakte, vastgelegde en gefiatteerde patiëntstukken kunnenbekrachtigen door het zetten van een elektronische handtekening metbehulp van zijn vertrouwensmiddel en deze toevoegen aan hetpatiëntdossier.

Bij (gebruiksscenario 1.1.2) verwijderen patiëntgegevens gelden de volgende eisenen wensen:


(e) De gebruiker moet op verzoek van een patiënt/cliënt bepaaldepatiëntstukken kunnen verwijderen, waarbij na keuze:

o {toekomst} de patiëntstukken worden versleuteld met behulp vanhet vertrouwensmiddel van de patiënt/cliënt,

o de patiëntstukken definitief en onherstelbaar worden uitgewist,inclusief de eventuele verwijzingen vanuit een toegangslog voorzoverdie nog niet gearchiveerd zijn.

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd alszorgverlener of gemandateerde medewerker op vertrouwensniveau midden (ziegebruiksscenario 0.2.1).

Opmerkingen:

• Ogenschijnlijk is het bijhouden van patiëntgegevens in een dossier slechtseen zaak voor de verantwoordelijke zorgverlener. Maar wanneer dezepatiëntgegevens vervolgens voor landelijke uitwisseling in aanmerkingkomen, is het noodzakelijk eisen te stellen aan de manier waaropzorgverleners hun dossier bijhouden. De bovenstaande eisen gelden dusvoor de patiëntgegevens die in het kader van een bepaalde landelijkezorgtoepassing kunnen worden uitgewisseld.

• Ad (d) NICTIZ zal nader uitzoeken welke patiëntstukken en welkeonderdelen daarvan precies in aanmerking komen voor ondertekening.

• Ad (e) Het verwijderen van verwijzingen naar patiëntstukken uit eentoegangslog is moeilijk realiseerbaar wanneer deze is gearchiveerd op eenoff-line medium.


4.2.6 Publiceren Patiëntgegevens

Wanneer een zorgverlener allerlei patiëntstukken toevoegt aan zijn dossier, kan hijbesluiten deze patiëntstukken te publiceren, opdat deze beschikbaar komen voorlandelijke opvraag door andere zorgverleners. Ook in latere instantie kan hijbesluiten bepaalde patiëntstukken alsnog vrij te geven, dan wel weer af teschermen. Wanneer een zorgverlener allerlei patiëntstukken verwijdert uit zijndossier, zijn deze uiteraard niet langer beschikbaar voor opvraag.

Vrijgeven van een patiëntstuk betekent ook dat de gegevenssoort moet wordenaangemeld bij de verwijsindex. Anders blijft voor andere zorgverleners onbekenddat dit dossier patiëntstukken beschikbaar heeft gesteld voor opvraag. Afschermenvan een patiëntstuk kan betekenen dat de gegevenssoort weer moet wordenafgemeld bij de verwijsindex.

In principe moet een zorgverlener alle patiëntstukken van alle gegevenssoortenvermeld in het autorisatieprotocol vrijgeven. Alleen met goede redenen kan eenzorgverlener besluiten om bepaalde patiëntstukken, of zelfs alle patiëntstukken vaneen bepaalde gegevenssoort of een bepaalde episode, niet vrij te geven. Bijv. eenpatiënt/cliënt wenst dat zijn huisarts het medicatievoorschrift voor eenantidepressivum afschermt, waarop de huisarts besluit alle medicatievoorschriftenaf te schermen, om de schijn van volledigheid te vermijden. Zie ook paragraaf3.7.2 opmerking bij (f).

Merk op dat vrijgeven en afschermen betrekking hebben op afzonderlijkepatiëntstukken en zich binnen het dossier afspelen. Daarentegen hebbenaanmelden en afmelden in principe betrekking op alle patiëntstukken van eenbepaalde gegevenssoort. Bij het vrijgeven van een patiëntstuk is aanmelden dusniet nodig, als reeds een ander patiëntstuk van dezelfde gegevenssoort wasgepubliceerd. Heraanmelden is dan wel nodig als de actualiteit moet wordenbijgewerkt, zie paragraaf 4.3.3. Afmelden is alleen nodig als het laatste patiëntstukvan een bepaalde gegevenssoort wordt afgeschermd.

Hoewel aanmelden, heraanmelden en afmelden in principe automatisch plaatsvindtna het vrijgeven of afschermen van bepaalde patiëntstukken, kan de zorgverlenereen gegevenssoort aanmelden zonder dat patiëntstukken van die gegevenssoortzijn vrijgegeven. Bijvoorbeeld als een zorgverlener die patiëntstukken niet geschiktvoor publicatie acht, of die patiëntstukken alleen op papier heeft, maar kenbaar wilmaken dat hij gebeld kan worden over deze gegevenssoort.

Naast het hierboven beschreven categorale aanmelden, bestaat ook demogelijkheid van atomair aanmelden van afzonderlijke patiëntstukken. Dit is nuttigvoor omvangrijke patiëntstukken (bijv. CT-scans) of patiëntdocumenten die wegenshun aard (bijv. ontslagbrief) gewoonlijk niet groepgewijs maar afzonderlijkopgevraagd worden.

Een bijzonder geval is het aanmelden van een heel patiëntdossier. Dit wordtatomair als eerstelijnsdossier aangemeld, terwijl het dossier vele, verschillendepatiëntstukken bevat, die afzonderlijk maar ook tezamen (in de vorm van eenprofessionele samenvatting) kunnen worden vrijgegeven en afgeschermd.

Per zorgtoepassing (EMD, WDH, etc.) moet worden voorgeschreven op welkeaggregatieniveaus de betrokken patiëntgegevens door zorgaanbieders moetenworden aan/afgemeld resp. vrijgegeven/afgeschermd.


Afschermen staat in principe los van het autorisatieprofiel. Het autorisatieprofiel isbedoeld om specifieke zorgverleners uit te sluiten van landelijke uitwisseling vanpatiëntgegevens. Afschermen is bedoeld om specifieke patiëntstukken uit te sluiten,zonder aanziens des persoons en ongeacht of de noodknop wordt gebruikt.


[B8] Als gevolg van ontwerpbeslissing [B21] moet een zorgverlener in principede patiëntstukken van alle gegevenssoorten vermeld in het autorisatie-protocol vrijgeven en aanmelden, ongeacht het autorisatieprofiel van dedesbetreffende patiënt/cliënt.

[B9] Zorgverleners mogen beperkt in staat gesteld worden landelijk patiënt-gegevens aan te melden, indien de vereiste identificatie en authenticatievan de patiënt/cliënt en diens dossier nog niet geheel is uitgevoerd, ziebijlage A.


• Gebruiksscenario 1.2.1: vrijgeven patiëntgegevens en aanmelden bij deverwijsindex,

• Gebruiksscenario 1.2.2: afschermen patiëntgegevens en afmelden bij deverwijsindex.

Bij (gebruiksscenario 1.2.1) vrijgeven patiëntgegevens gelden de volgende eisen enwensen:

(a) De gebruiker moet kunnen instellen welke gegevenssoorten vanpatiëntstukken na toevoegen aan zijn dossier automatisch, dan wel opcommando per patiëntstuk (zie paragraaf 4.2.5), worden vrijgegeven.

(b) De gebruiker moet na het vastleggen van patiëntstukken in zijn dossier,deze automatisch of op commando per patiëntstuk kunnen vrijgeven.

(c) De gebruiker moet naderhand individuele patiëntstukken in zijn dossieralsnog kunnen vrijgeven.

(d) Bij het vrijgeven van een patiëntstuk moet de gebruiker erop kunnenvertrouwen dat:

o hij wordt gewaarschuwd indien het patiëntstuk ooit als kopie van eenandere zorgverlener is ontvangen,

o de gegevenssoort van het patiëntstuk nieuw wordt aangemeld bij deverwijsindex, indien dat nog niet was gedaan, zoals voorgeschrevenper zorgtoepassing,

o de gegevenssoort van het patiëntstuk opnieuw wordt aangemeld(heraanmelden) bij de verwijsindex, indien de vorige aanmeldingmeer dan een bepaald tijdsinterval (zie paragraaf 4.2.17 (e)) geledenis,

(e) De gebruiker moet na het voorlopig koppelen (zie gebruikscenario 1.4.1) ofna het definitief koppelen (zie gebruikscenario 0.3.3) van een patiëntdossier


aan een landelijk patiëntnummer, de relevante patiëntstukken in één keerkunnen vrijgeven en aanmelden, alleen indien:

o het BSN ooit door de desbetreffende zorgaanbieder is opgevraagd ofgeverifieerd bij het landelijke patiëntenregister, en/of

o het WID is gecontroleerd op echtheidskenmerken en gelijkenis metde patiënt/cliënt,

waarbij de zorgverlener moet worden gewaarschuwd indien:o het BSN nog niet is geverifieerd bij het landelijke patiëntenregister,o het WID nog niet is gecontroleerd op gelijkenis met de patiënt/cliënt,o het WID nog niet is gecontroleerd op echtheidskenmerken,o het dossier nog niet inhoudelijk is gecontroleerd met de

patiënt/cliënt.waarbij de gebruiker vooraf per gegevenssoort kan aangeven tot hoeverterug in het verleden naar relevante patiëntstukken moet worden gezocht.

(f) {toekomst} De gebruiker moet een gegevenssoort kunnen aanmeldenzonder dat patiëntstukken van die gegevenssoort zijn vrijgegeven.

Bij (gebruiksscenario 1.2.2) afschermen patiëntgegevens gelden de volgende eisenen wensen:

(g) De gebruiker moet vrijgegeven patiëntstukken naderhand weer kunnenafschermen en wel op de volgende aggregatieniveaus:

o patiëntdossier,o patiëntdocument,o patiëntgegevensbijdrage,o patiëntgegevenselement.

(h) De gebruiker moet in de volgende gevallen patiëntstukken in zijn dossierautomatisch kunnen laten afschermen:

o bij het herroepen van patiëntstukken,o bij het overdragen van patiëntstukken aan een andere

zorgaanbieder.

(i) Bij het afschermen of verwijderen van een patiëntstuk moet de gebruikererop kunnen vertrouwen dat:

o het patiëntstuk niet meer beschikbaar is voor opvraag, ook niet innoodsituaties,

o indien er voor de onderhavige patiënt/cliënt verder géén vrijgegevenpatiëntstukken meer zijn met deze gegevenssoort, de gegevenssoortvan het patiëntstuk wordt afgemeld bij de verwijsindex, zoalsvoorgeschreven per zorgtoepassing, waarbij de gebruiker vooraf ombevestiging wordt gevraagd,

o indien dit vrijgegeven patiëntstuk het meest actuele met diegegevenssoort was, de gegevenssoort opnieuw wordt aangemeld bijde verwijsindex, maar dan met de actualiteit van het meest actuelenog vrijgegeven patiëntstuk met deze gegevenssoort.

(j) {toekomst} Een zorgverlener wil bij vermoede onjuistheden in deverwijsindex, al zijn vermeldingen in de verwijsindex op commando, perpatiënt kunnen laten bijwerken (synchroniseren).

Voor beide gebruiksscenario’s geldt:


(k) De gebruiker moet bij het aanmelden of afmelden van patiëntgegevens.o worden gewaarschuwd indien de verwijsindex niet bereikbaar is,o de aanmeldingen en afmeldingen automatisch laten bewaren voor

latere afhandeling,o bij de eerstvolgende keer inloggen alle klaarstaande aanmeldingen en

afmeldingen alsnog automatisch laten afhandelen,o worden geïnformeerd of alles met succes is afgehandeld.


Opmerkingen:

• Ad (a) in principe moet een zorgverlener de patiëntstukken van allegegevenssoorten vermeld in het autorisatieprotocol vrijgeven. Toch kan eenzorgverlener bijzondere redenen hebben om bepaalde patiëntstukken, ofzelfs alle patiëntstukken van een bepaalde gegevenssoort of een bepaaldeepisode, niet vrij te geven, bijvoorbeeld op uitdrukkelijk verzoek van depatiënt/cliënt.

• Ad (d) in principe mag alleen de zorgverlener die verantwoordelijk is vooreen patiëntstuk deze aanmelden. Anderen die ooit een kopie hebbenontvangen, mogen dit patiëntstuk niet opnieuw of alsnog aanmelden, tenzijdaar bijzondere redenen voor zijn, zie ook paragraaf 4.2.11.

• Ad (d) en (g) in het dossier moet dus worden bijgehouden in hoeverre devrijgegeven patiëntstukken zijn aangemeld aan de verwijsindex, omoverbodige aanmeldingen te voorkomen.

• Ad (e) voor patiënten/cliënten zonder BSN (nieuw-ingezetenen,pasgeborenen, etc.) kunnen de patiëntgegevens pas worden aangemeldnadat alsnog een BSN is toegekend. Daarvoor moeten de nodige controleszijn uitgevoerd, zie ook paragraaf 4.2.3. Voor patiënten/cliënten die initieelworden gekoppeld, is de WID-controle niet nodig.

• Ad (f) dit kan belangrijk zijn als een zorgverlener bepaalde patiëntstukkenniet elektronisch heeft, maar deze toch wil aanmelden bijv. om anderezorgaanbieders te laten weten dat hij daarover gebeld kan worden.

• Ad (g) deze aggregatieniveaus komen voort uit paragraaf 3.4.3. Eenmedicatieregel is te beschouwen als patiëntgegevenselement, deprofessionele samenvatting van een huisarts is te beschouwen als eenpatiëntdocument. Zoals uitgelegd in paragraaf 3.6.2, opmerking bij (b)hangt het laagste niveau af van het belang van de context waarin diepatiëntgegevens beschouwd moeten worden. Dit kan verschillen perzorgtoepassing en gegevenssoort. Zo is het momenteel niet mogelijk binneneen professionele samenvatting bepaalde gegevens af te schermen.

• Ad (h) herroepen speelt wanneer een zorgverlener een patiëntstuk heeftvastgelegd in zijn dossier, maar later ontdekt dat het foutief is. Dan kan hijdit patiëntstuk niet verwijderen, maar wel herroepen door het ongeldig temaken. Overdragen speelt bijv. wanneer een huisarts het waarneemverslag


van een HAP voor één van zijn patiënten overneemt in zijn dossier, zieverder paragraaf 4.2.11.

• Ad (i) het categoraal afmelden van een gegevenssoort zal in de praktijk nietzo vaak plaatsvinden. Na het afschermen of verwijderen van één patiëntstukzullen vaak nog andere patiëntstukken van dezelfde gegevenssoortoverblijven, zodat de aanmelding gehandhaafd moet worden. Wel kanheraanmelden nodig zijn de actualiteit te wijzigen.

• Ad (k) de applicatie moet de gebufferde aanmeldingen en afmeldingenalsnog verzenden zodra de verantwoordelijke zorgverlener weer inlogt. Hetis dus niet mogelijk dat de applicatie deze in afwezigheid van dezorgverlener verzendt zodra de verwijsindex weer bereikbaar is. Deapplicatie kan dit allemaal automatisch afhandelen, maar de zorgverlenermoet wel worden geïnformeerd.


4.2.7 Abonneren Patiëntgegevens

Wanneer een zorgverlener interesse heeft in patiëntgegevens die nu nog nietbeschikbaar zijn, bijv. een labuitslag, wil hij misschien gewaarschuwd wordenwanneer deze wél beschikbaar komen.


• Gebruiksscenario 1.3.1: aanmelden abonnement bij de verwijsindex,

• Gebruiksscenario 1.3.2: afmelden abonnement bij de verwijsindex.

Hierbij gelden de volgende eisen:

(a) {toekomst} De gebruiker moet kunnen instellen of hij éénmalig ofvoortdurend op de hoogte gehouden wil worden van het beschikbaar komenvan bepaalde gegevenssoorten van patiëntgegevens.

(b) {toekomst} De gebruiker moet, nadat hij een melding heeft ontvangen vanhet beschikbaar komen van de gewenste patiëntgegevens, door eenvoudigaanklikken de gewenste patiëntgegevens kunnen opvragen.

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd alszorgverlener of medewerker op vertrouwensniveau midden (zie gebruiksscenario0.2.1).

Deze gebruiksscenario’s zullen in een latere versie van dit document wordenuitgewerkt. Daarbij wordt uitgezocht of dit mechanisme bijv. kan worden gebruiktom op de hoogte te worden gebracht van adreswijzigingen in de GBA.


4.2.8 Initieel koppelen Patiëntgegevens

Zoals beschreven in paragraaf 3.8.2, moet een zorgverlener bij de invoering vanhet landelijke patiëntnummer (BSN) zijn patiëntdossier’s opschonen door allepatiëntgegevens te koppelen aan het juiste BSN. Dat is geen sinecure want:

• elke ingeschreven patiënt/cliënt moet worden gematcht aan de hand vanactuele identificerende patiëntgegevens (NAW, geboortedatum, etc.), terwijlde aanwezige attributen in het patiëntdossier misschien verouderd zijn.

• het komt voor dat de gegevens van één patiënt/cliënt abusievelijk zijnopgeborgen in het patiëntdossier achter twee patiëntidentiteiten. Hetomgekeerde komt ook voor.

• sommige zorginstellingen hebben miljoenen patiënten in hun bestand. Hetzal erg veel inspanning kosten om al die gegevens op te schonen, terwijlveel gegevens nooit meer opgevraagd zullen worden. Daarom willenzorginstellingen wellicht ervoor kiezen om eerst een deel van hunpatiënten/cliënten te koppelen en later misschien de rest.

• hoewel een zorgverlener zich kan laten assisteren door medewerkers, blijfthij te allen tijde zelf verantwoordelijk voor de correctheid van de patiënt-dossiers, dus ook voor de koppeling van patiëntgegevens aan het juisteBSN.

• uiteindelijk moet ieder gekoppeld landelijk patiëntnummer eens wordengeverifieerd in aanwezigheid van de patiënt/cliënt. Het is ondoenlijk ompatiënten/cliënten hiervoor op te roepen. Dus is het wenselijk datzorgaanbieders geruime tijd krijgen om het nummer te verifiëren wanneerde patiënt/cliënt toch al op spreekuur komt of anderszins contact opneemt.


[B10] Het koppelen van patiëntgegevens aan het juiste BSN, moet kunnenworden uitgevoerd in twee stappen:

• een voorlopige koppeling: een bulkproces dat t.b.v. doelmatigheiddeels geautomatiseerd en deels door medewerkers van dezorgaanbieder kan worden uitgevoerd,

• een definitieve koppeling: een proces dat t.b.v. zorgvuldigheidhandmatig door de verantwoordelijke zorgverlener moet wordenuitgevoerd.

[B11] Met veronderstelde toestemming kunnen voorlopig gekoppelde patiënt-gegevens worden aangemeld bij de verwijsindex om beschikbaar te komenvoor opvraag door andere zorgverleners.

Het aanmelden bij de verwijsindex zonder expliciete toestemming van depatiënt/cliënt is mogelijk, zie paragraaf 3.7.2 ad (d), en heeft het grote voordeeldat in een vroeg stadium na de start van het landelijk schakelpunt reeds patiënt-gegevens kunnen worden opgevraagd. Anders gaat het jaren duren voordat deverwijsindex enigszins gevuld is.

Anderzijds is het hebben opgeschoond van patiëntdossiers en het aanmelden vanpatiëntgegevens een voorwaarde voor aansluiting van de zorgaanbieder op het


landelijk schakelpunt. Het aanmelden van patiëntgegevens zou een voorwaardekunnen worden voor het mogen opvragen van patiëntgegevens van anderezorgaanbieders.

Het achteraf koppelen van patiëntgegevens kan echter niet garanderen dat diegegevens inderdaad betrekking hebben op de aangegeven patiënt/cliënt.Bijvoorbeeld, patiëntgegevens die ooit zijn ingevoerd onder een valse identiteit vaneen patiënt/cliënt, worden keurig gekoppeld aan het BSN behorende bij die valseidentiteit. Wanneer de echte patiënt/cliënt met zijn WID verschijnt, komt dat nietaan het licht. Alleen als de zorgverlener ter verificatie de gekoppeldepatiëntgegevens inhoudelijk met hem doorneemt, zou dit aan het licht kunnenkomen.

Daarom moeten zorgverleners voor iedere initieel gekoppelde patiënt/cliënt zospoedig mogelijk de overige controles rond de invoering van het BSN uitvoeren,bijv. bij het eerste contact na de initiële koppeling, zie bijlage A, paragraaf 4.


• Gebruiksscenario 1.4.1: voorlopig koppelen patiëntgegevens aan landelijkpatiëntnummer,

• Gebruiksscenario 1.4.2: definitief koppelen patiëntgegevens aan landelijkpatiëntnummer.

Bij (gebruiksscenario 1.4.1) voorlopig koppelen gelden de volgende eisen enwensen:

(a) De gebruiker moet van de patiënten/cliënten in de eigen patiëntdossier’s hetinterne patiëntnummer en andere identificerende gegevens, kunnenovernemen naar een conversiebestand, waarbij hij kan kiezen voor:

o alleen de actieve patiënten/cliënten,o alle ingeschreven patiënten/cliënten,o alleen de patiënten/cliënten die patiëntgegevens van bepaalde

gegevenssoorten van na een bepaalde datum in het dossier hebben.

(b) De gebruiker moet het conversiebestand kunnen opsturen naar hetlandelijke patiëntenregister.

(c) De gebruiker moet het resultaatbestand kunnen ontvangen van hetlandelijke patiëntenregister.

(d) De gebruiker moet vanuit het resultaatbestand de toegevoegde BSN’s metde eventueel afwijkende attributen in één keer kunnen overnemen naar heteigen patiëntdossier, waarbij automatisch wordt vastgelegd:

o de bron van het BSN (landelijk patiëntenregister),o datum en tijd van koppelen,o zorgaanbiedernummer van de gebruiker.

(e) De gebruiker moet de onderstaande situaties handmatig kunnen langslopen,zonodig corrigeren en/of zonodig ontkoppelen van het BSN:

o patiënten voor wie afwijkende attributen waren gevonden,o patiënten met verschillende interne patiëntnummers die aan

éénzelfde BSN waren gekoppeld,


o patiënten voor wie het eventueel aanwezige BSN onjuist blijkt te zijn,o patiënten die helemaal niet gekoppeld konden worden.

(f) De gebruiker moet tenslotte worden geleid naar gebruiksscenario1.2.1vrijgeven patiëntgegevens.

Bij (gebruiksscenario 1.4.2) definitief koppelen gelden dezelfde eisen en wensen alsvoor gebruikscenario 0.3 selecteren patiënt/cliënt.

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker lokaal heeft ingelogdals zorgverlener of medewerker op vertrouwensniveau laag of midden (ziegebruiksscenario 0.2.1).

Opmerkingen:

• Ad (a) In principe moeten alle patiëntgegevens worden gekoppeld, maar hetkan verstandig zijn voorrang te geven aan actieve patiënten/cliënten. Ingeval van een ziekenhuis zijn dit de onder behandeling zijnde patiënten. Ingeval van een huisarts zijn dit de nog niet uitgeschreven patiënten. Eenzorginstelling kan ook besluiten eerst alleen de patiënten/cliënten tekoppelen voor wie in het afgelopen halfjaar bijv. medicatiegegevens zijnvastgelegd.

• Ad (a) Mocht voor een patiënt reeds een BSN aanwezig zijn in het eigenpatiëntdossier, dan kan deze ter verificatie worden meegegeven in hetconversiebestand.

• Ad (a) In geval van een ziekenhuis heeft men de keuze om alleen decentrale patiëntnummers in het ZIS of de MPI te koppelen, dan wel alle ZIS,ZAIS, RIS, LIS, etc. afzonderlijk te koppelen.

• Ad (b) De SBV-Z biedt de faciliteit om bestandsgewijs patiëntnummers tekoppelen, maar kan daarbij momenteel geen peildatums voor verouderdeidentificerende gegevens hanteren. Wellicht kan BPR daarbij hulp bieden.

• Ad (c) Het resultaatbestand is het conversiebestand waaraan per lokaalpatiëntnummer de koppelresultaten zijn toegevoegd. De koppelresultatenbestaan uit het gevonden BSN en de eventuele afwijkende attributen, danwel een foutmelding die vertelt welke attributen moeten worden aangevuldom alsnog een koppeling te krijgen. Zie verder [BSN].

• Ad (d) In geval van een ziekenhuis waar het ZAIS, RIS, LIS, etc. een eigenpatiëntnummer voeren, kan men ervoor kiezen de koppeling met het BSNvanuit het ZIS te propageren naar die systemen, opdat de definitievekoppeling aldaar afzonderlijk kan worden gedaan.

• Ad (d) Merk op dat het interne patiëntnummer niet wordt vervangen doormaar aangevuld met het BSN, opdat een abusievelijk gemaakte koppelingeventueel weer ongedaan kan worden gemaakt.

• Ad (e) Waar nodig en zinvol kunnen attributen handmatig wordengecorrigeerd of aangevuld, eventueel na raadpleging van andere dossiers


en/of contact met de desbetreffende patiënten. Desnoods wordt eenvoorlopige koppeling weer ongedaan gemaakt. Na afloop kan voor dezegroep patiënten het proces van voorlopige koppeling worden herhaald.

• Ad (f) Het initieel koppelen van patiëntdossiers zal in de praktijk eenonderdeel worden van een traject om de zorgaanbiederapplicatie aan tesluiten op het landelijk schakelpunt. Bij de eerste aansluiting kan deverwijsindex worden gevuld.

• Let op de analogie tussen gebruiksscenario 1.4 initieel koppelen engebruiksscenario 0.3 selecteren patiënt/cliënt. Deelscenario 1.4.1 isvergelijkbaar met deelscenario 0.3.1, maar dan voor een grote verzamelingpatiënten/cliënten, die bovendien niet aanwezig zijn. Deelscenario 1.4.2 is inprincipe gelijk aan deelscenario 0.3.2 en verder, maar zal in de praktijk tochbeginnen met deelscenario 0.3.1.


4.2.9 Opvragen Patiëntgegevens

Zoals beschreven in paragraaf 3.6.2, moet een zorgverlener patiëntgegevenskunnen opvragen. Voor sommige zorgvragen weet een zorgverlener precies welkepatiëntgegevens hij nodig heeft om zijn patiënt/cliënt te helpen. Hij kan aldus eengerichte opvraag formuleren die precies de benodigde gegevens oplevert. Voorsommige andere zorgvragen weet de zorgverlener niet direct welke opvraag hijmoet formuleren. Hij heeft dan baat bij een overzicht van beschikbaregegevenssoorten zoals vermeld in de verwijsindex.

Voorbeeld is een huisarts die wegens een vage klacht van een patiënt/cliënt eersteens wil kijken wat er allemaal bekend is over deze patiënt. De opvraag zou er alsvolgt kunnen uitzien, aangenomen dat de huisarts in 2003 alle feiten sinds het jaar1993 wil zien:

Actie<kiezen> Patiëntnr (BSN) 1234567890 Geboortedatum 11-11-1911<index> Geboortenaam Jong Geboorteplaats Amsterdam... ... ... ... ...Plaats Zorgaanb.naam Zorgaanb.functie Gegevens.soort Actualiteit[alle] [alle] [alle] [alle] [1993]

Het resultaat na het aanklikken van <index> zou er als volgt kunnen uitzien:

Actie<kiezen> Patiëntnr (BSN) 1234567890 Geboortedatum 11-11-1911<opvragen> Geboortenaam Jong Geboorteplaats Amsterdam... ... ... ... ...Plaats Zorgaanb.naam Zorgaanb.functie Gegevens.soort ActualiteitAmsterdam Amstelapotheek apotheker medic.verstrek. 2003Amsterdam IJ-apotheek apotheker medic.verstrek. 2003Amstelveen Veenapotheek apotheker medic.verstrek. 2003Rotterdam Maasapotheek apotheker medic.verstrek. 2002Schiedam Schieapotheek apotheker medic.verstrek. 1999Amsterdam Jansen arts, huisarts 1elijnsdossier 2003Amsterdam Jansen arts, huisarts medic.voorsch. 2003Amsterdam Jansen arts, huisarts kcl-labaanvr. 2002Rotterdam Pietersen arts, huisarts 1elijns dossier 1999Rotterdam Pietersen arts, huisarts verwijsbrief 1999Schiedam Jacobsen arts, huisarts 1993Amsterdam Amstelziekenhuis arts, inwendige diagnose 2002Amsterdam Amstelziekenhuis arts, inwendige spec.brief 2002Amsterdam Amstelziekenhuis arts, klinische kcl-labuitslag 2002Rotterdam Maasziekenhuis arts, orthopedie 1999Rotterdam Maasziekenhuis arts, pathologie spec.brief 1999Amsterdam Amstelziekenhuis arts, radiologie röntgenuitslag 2002Rotterdam Maasziekenhuis arts, radiologie röntgenuitslag 1994Rotterdam Willemsen fysiotherapeut brief 1999Amsterdam Amstelziekenhuis verpleging opname 2002<begin> <vorige 20> <volgende 20> <eind>


Op basis van deze index zou de huisarts door middel van aanklikken van<opvragen> de inhoudelijke patiëntgegevens van de aangegeven soort bij eenspecifieke zorgaanbieder kunnen opvragen.


[B12] Zorgaanbieders moeten een index van beschikbare patiëntstukken kunnenopvragen alvorens zij de inhoudelijke patiëntgegevens zelf opvragen.

[B13] Zorgverleners mogen beperkt in staat gesteld worden landelijk patiënt-gegevens te versturen, indien de vereiste identificatie en authenticatie vande patiënt/cliënt en diens dossier nog niet is uitgevoerd, zie bijlage A.

[B14] {toekomst} Ten behoeve van de toezichthouder moet de situatie voor eenwillekeurige datum in het verleden kunnen worden gereconstrueerd, totaan een afgesproken reconstructiehorizon, zie paragraaf 3.7.3 opmerkingbij (g).

Voor zo’n index is het belangrijk dat:

• de index voldoende details geeft, opdat de zorgverlener kan bepalen of hetzinvol is daarop verder in te zoomen,

• de index snèl op het scherm verschijnt, opdat de zorgverlener niet in deverleiding komt te stoppen met zoeken,

• de index compleet is, opdat de patiëntgegevens van de dossiers die op hetmoment van opvraag niet bereikbaar zijn, ook worden weergegeven.

Tenslotte kan de zorgverlener multimediale patiëntstukken apart opvragen. Dezeaparte opvraag is handig voor röntgenfoto’s, hartfilms, etc. waarvan het overhalenveel tijd kost.


• Gebruiksscenario 2.1.1: opvragen index van beschikbare patiëntstukken,

• Gebruiksscenario 2.1.2: opvragen inhoudelijke patiëntstukken,

• Gebruiksscenario 2.1.3: opvragen multimediale patiëntstukken,

Bij (gebruiksscenario 2.1.1) opvragen index gelden de volgende eisen en wensen:

(a) De gebruiker moet, uitgaande van een geselecteerde patiënt/cliënt (ziegebruiksscenario 0.3.1) een totaaloverzicht van alle beschikbaregegevenssoorten gepresenteerd krijgen, met daarin de volgende attributenper indexregel:

o identiteit van de verantwoordelijke zorgaanbieder,o functie van de verantwoordelijke zorgaanbieder,o gegevenssoort bij die zorgaanbieder,o actualiteit van die gegevenssoort bij die zorgaanbieder,o {toekomst} indicatie van de beschikbaarheid van die gegevens.


(b) De gebruiker moet de presentatie van indexregels kunnen doseren, bijv.door steeds de volgende 20 items te laten presenteren.

(c) De gebruiker moet de presentatie van indexregels kunnen sorteren, bijv.door ze in oplopende of aflopende volgorde van een bepaald attribuut tezetten.

(d) De gebruiker moet door eenvoudig aanklikken van een indexregel eenoverzicht van alle patiëntstukken voor die gegevenssoort gepresenteerdkrijgen, zie gebruiksscenario 2.1.2.

(e) De gebruiker moet binnen 2 seconden na opvraag de index gepresenteerdkrijgen.

(f) {toekomst} De toezichthouder wil de situatie voor een willekeurige datum inhet verleden kunnen reconstrueren. Hierbij is de bovengenoemderesponstijd niet van toepassing.

Bij (gebruiksscenario 2.1.2) opvragen patiëntstukken gelden de volgende eisen enwensen:

(g) De gebruiker moet desgewenst kunnen selecteren wèlke patiëntstukkenopgevraagd worden, aan de hand van één of meer van de volgendekenmerken/attributen:

o over welke patiënt/cliënt de gegevens gaan,o de identiteit van de verantwoordelijke zorgaanbieder,o de functie van de verantwoordelijke zorgaanbieder,o van welke gegevenssoort de gegevens zijn,o tot welke episode de gegevens behoren,o op welke tijdsperiode de gegevens slaan,o eventueel nog specifieke criteria, afhankelijk van de gegevenssoort.

(h) De zorgverlener moet kunnen verklaren waarvoor hij de patiëntstukkennodig heeft, door het invoeren van de volgende zaken:

o voor welke episode de gegevens nodig zijn,o {toekomst} wat de betrokkenheid van de zorgverlener bij deze

zorgvraag is,o {toekomst} de reden waarom de patiëntgegevens nodig zijn,o of er sprake is van een noodsituatie.

(i) De gebruiker moet de presentatie van patiëntstukken, afhankelijk van deomvang, kunnen doseren, bijv. door steeds de volgende 20 items te latenpresenteren.

(j) De gebruiker moet de presentatie van patiëntstukken uit verschillendepatiëntdossiers kunnen sorteren, door patiëntgegevens op volgorde vanbepaalde kenmerken te zetten.

(k) De gebruiker moet de opgeleverde patiëntstukken na uitlezen geheel ofgedeeltelijk kunnen opnemen in het eigen patiëntdossier, aangemerkt alskopie, en anders wissen.

(l) De gebruiker moet als volgt gewaarschuwd worden indien niet allepatiëntstukken konden worden gepresenteerd:


Nr Reden Melding1 Opleverende GBZ is tijdelijk niet beschikbaar

of bereikbaar (bijv. storing)“Een of meer dossiers zijntijdelijk niet bereikbaar,probeer het later nog eens“

2 Zorgverlener heeft in overleg met patiënthet gehele dossier niet aangemeld

Geen, of zie melding 6

3 Zorgverlener heeft in overleg met patiëntenkele gegevens afgeschermd

Geen, of zie melding 6

4 {toekomst} Zorgverlener kan gegevens nietelektronisch beschikbaar stellen, maar vondze wel belangrijk om aan te melden

“Enkele gegevens zijn nietelektronisch beschikbaar,neem contact op met dezorgaanbieder(s)”

(m) De gebruiker moet als volgt gewaarschuwd worden indien helemaalgeen patiëntstukken konden worden gepresenteerd:

Nr Reden Melding5 De ZIM is tijdelijk niet beschikbaar of

bereikbaar“Het landelijke schakelpunt istijdelijk niet bereikbaar,probeer het later nog eens”

6 Er zijn überhaupt geen gegevens “Er zijn geen gegevensbeschikbaar”

7 Opvragende zorgverlener is op grond vanzijn functie niet geautoriseerd (volgensautorisatieprotocol)

“U bent niet geautoriseerdvoor deze gegevenssoort”

8 Patiënt heeft alle opvragende zorgverlenersmet een dezelfde functie uitgesloten,behalve in noodsituatie (volgensautorisatieprofiel)

“U heeft geen toegang totdeze gegevens, behalve innoodsituatie”

9 Patiënt heeft alle opvragende zorgverlenersmet een dezelfde functie geheel uitgesloten(volgens autorisatieprofiel)

“U heeft geen toegang totdeze gegevens”

10 Patiënt heeft deze ene opvragendezorgverlener uitgesloten, behalve innoodsituatie (volgens autorisatieprofiel)

“U heeft geen toegang totdeze gegevens, behalve innoodsituatie”

11 Patiënt heeft deze ene opvragendezorgverlener geheel uitgesloten (volgensautorisatieprofiel)

“Patiënt stelt geen gegevensbeschikbaar”

12 Patiënt heeft principieel bezwaar tegenelektronische uitwisseling van zijn gegevens(volgens autorisatieprofiel)

“Patiënt stelt geen gegevensbeschikbaar”

(n) De gebruiker moet binnen 5 seconden na opvraag de patiëntstukkengepresenteerd krijgen.

(o) {toekomst} De toezichthouder wil de situatie voor een willekeurige datum inhet verleden kunnen reconstrueren. Hierbij is de bovengenoemderesponstijd niet van toepassing.

Bij (gebruiksscenario 2.1.3) opvragen multimediale patiëntstukken gelden devolgende eisen en wensen:


(p) {toekomst} Een gebruiker moet de multimediale patiëntstukken kunnenopvragen door eenvoudig aanklikken vanuit (gebruiksscenario 2.1.2),

(q) {toekomst} De gebruiker moet binnen 10 seconden na opvraag demultimediale patiëntstukken gepresenteerd krijgen.

(r) {toekomst} De toezichthouder wil de situatie voor een willekeurige datum inhet verleden kunnen reconstrueren. Hierbij is de bovengenoemderesponstijd niet van toepassing.

Voor al deze gebruiksscenario’s geldt:

(s) De gebruiker mag voor een patiënt/cliënt landelijk patiëntgegevensopvragen,waarbij de zorgverlener moet worden gewaarschuwd indien:

o het BSN nog niet is geverifieerd bij het landelijke patiëntenregister,o het WID nog niet is gecontroleerd op gelijkenis met de patiënt/cliënt,o het WID nog niet is gecontroleerd op echtheidskenmerken,o het dossier nog niet inhoudelijk is gecontroleerd met de

patiënt/cliënt.

(t) De gebruiker mag alleen gepresenteerd krijgen:o indexregels die verwijzen naar patiëntstukken waarvoor hij

geautoriseerd is,o patiëntstukken waarvoor hij geautoriseerd is,

waarbij geen reden wordt opgegeven indien niet alle gepresenteerdestukken compleet waren.


Opmerkingen:

• De tweede figuur toont slechts een voorbeeld van hoe een indexoverzichtgepresenteerd zou kunnen worden aan een huisarts. Een apotheker zoualleen de medicatievoorschriften, -verstrekkingen en allergieën zien. Ook degetoonde gegevenssoorten zijn vooral voorbeelden, waarvan slechts enkelewerkelijk zijn gedefinieerd. Tenslotte toont de figuur slechts een deel van debeschikbare informatie in de verwijsindex. Het is aan de leveranciers vanzorgaanbiederapplicaties om te bepalen welke gegevens op welke wijzegetoond worden. Zo kan het bijv. nuttig zijn op elke indexregel de naam ofhet type van de zorginstelling te vermelden.

• De eisen zijn bedoeld als generieke functionaliteit. Of deze functionaliteit ookwerkelijk beschikbaar is voor een specifieke zorgtoepassing, hangt geheel afvan de soort patiëntstukken. Zo zal per zorgtoepassing bepaald moetenworden welke opvraagcriteria mogelijk én zinvol zijn.

• De hierboven gestelde responstijden zijn wensen en houden géén garantie indat deze altijd gerealiseerd kunnen worden. Zo zijn deze responstijdenwellicht niet haalbaar voor patiënten/cliënten die een lange medischehistorie hebben bij vele zorgaanbieders. Echter het grootste deel van depatiënten/cliënten heeft een beperkt aantal zorgaanbieders.


• Per zorgtoepassing kunnen karakteristieke opvraagpatronen gedefinieerdworden, al dan niet parametriseerbaar, om zorgverleners niet te hoevenvermoeien met cryptische opvraagcriteria. Vermoedelijk zullenzorgapplicaties ook steeds intelligenter worden, zodanig dat:

o de zorgverlener slechts een bepaalde medische vraag hoeft testellen,

o de zorgapplicatie deze intern vertaalt naar een opvraag aan debasisinfrastructuur,

o de zorgapplicatie de opgeleverde patiëntgegevens op een intelligentewijze interpreteert en verwerkt,

o de zorgapplicatie slechts een bondig antwoord presenteert aan dezorgverlener,

Voorbeeld is een medicatievoorschrijfapplicatie die een vraag kanbeantwoorden als “zijn er complicaties te verwachten als deze patiënt hetmedicijn ABC zou gebruiken?”. Het blijft natuurlijk de verantwoordelijkheidvan een arts om zich al of niet op een dergelijke intelligente applicatie teverlaten.

• Ad (a) Bij het presenteren van de identiteit van de zorgaanbieder is het nietaltijd zinvol abstracte identificatienummers te tonen. In plaats daarvan kanbijv. de naam en de vestigingsplaats van de zorgaanbieder worden getoond,zoals in het voorbeeld is weergegeven. Die attributen worden danbijvoorbeeld ‘onder water’ opgehaald uit de zorgaanbiedergids, op basis vanhet zorgaanbiedernummer.

• Ad (e, m) Indien bepaalde patiëntstukken niet beschikbaar zijn wegensafscherming of een autorisatieprofiel dat afzonderlijke zorgverleners uitsluit,mag dat niet vermeld worden, want dat zo’n vermelding is zelf vertrouwelijk.

• Ad (g), (o), (r) De toezichthouder kan dit nodig hebben om te reconstruerenwat een zorgverlener gezien zou hebben als hij op een bepaald tijdstip in hetverleden bepaalde patiëntgegevens zou hebben opgevraagd. Dit tijdstip kanniet verder in het verleden liggen dan een afgesproken reconstructiehorizon.

• Ad (h) In grote zorginstellingen worden de patiëntgegevens van allepatiënten/cliënten die op het spreekuur verwacht worden, ruim tevorenopgevraagd, veelal automatisch. Deze gewoonte stamt uit het papierentijdperk, toen patiëntdossiers gemakkelijk konden zoekraken. Hetautomatisch opvragen van landelijk beschikbare patiëntgegevens is echterjuridisch niet toegestaan. Op grond van de WGBO moet in individuelegevallen bepaald worden of een opvraag nodig is.

• Ad (g) De gegevenssoort geeft niet alleen de aard van de informatie aan,maar impliciet ook het aggregatieniveau van de informatie. Zo is een briefeen patiëntdocument, een diagnose een patiëntgegevensbijdrage, eenbloeddruk een patiëntgegevenselement, zie verder paragraaf 3.4.3.

• Ad (h) Deze verklaring kan nodig zijn voor de logging, zodat eentoezichthouder beter kan beoordelen of de opvraag rechtmatig was.

• Ad (k) Een zorgverlener mag opgevraagde patiëntstukken alleen opnemen inzijn eigen dossier, voor zover dit voor de behandeling op dat momentnoodzakelijk is. Bijvoorbeeld een huisarts die bepaalde labuitslagen


overneemt in een eigen verwijsbrief voor een specialist. In andere gevallenmoeten de opgevraagde patiëntgegevens na uitlezen worden gewist.

• Ad (k) Het is dus niet toegestaan dat zorgverleners patiëntgegevens gaanopvragen, en daarvan lokaal een kopie gaan vastleggen om ze “alvast bij dehand te hebben”. Immers, van kopieën weet men nooit of de inhoud actueelis. De behoefte aan lokaal kopiëren kan overigens worden verminderd doorervoor te zorgen dat de verwijsindex voldoende snel en beschikbaar is.Vandaar de bovenvermelde responstijden

• Ad (l) In geval van 2 en 3 krijgt de gebruiker géén melding dat niet allepatiëntstukken kunnen worden gepresenteerd, want dit zou anders deprivacy van die patiënt/cliënt kunnen bedreigen.

• Ad (m) In geval van 10 en 11 krijgt de gebruiker dezelfde melding als bij 8resp. 12, opdat hij niet kan concluderen dat de patiënt/cliënt hem alspersoon heeft uitgesloten, want dat zou anders de privacy van diepatiënt/cliënt bedreigen.

• Ontwerpbeslissing [B14] staat nog ter discussie, wegens de mogelijk tezware consequenties voor het LSP en ieder GBZ.

Openstaande punten:

• De eisen en wensen van de patiënt/cliënt t.a.v. het opvragen van eigenpatiëntgegevens zijn nog niet uitgewerkt, maar zijn veelal eendeelverzameling van de bovenstaande.


4.2.10 Versturen Patiëntgegevens

Zoals beschreven in paragraaf 3.6.3, moet een zorgverlener verschillende soortenpatiëntberichten via het landelijk schakelpunt veilig kunnen versturen naar anderezorgverleners: opdracht, antwoord en melding. Voor het schakelpunt is datonderscheid niet zichtbaar. Het zijn de zorgaanbiederapplicaties die op grond vande berichtsoort kunnen bepalen dat bijv. een opdracht moet leiden tot eenantwoord.

Wanneer bijv. een huisarts een recept uitschrijft maar dit niet kan versturen, omdatde patiënt/cliënt nog niet weet bij welke apotheek hij de medicijnen wil afhalen,heeft de zorgverlener twee mogelijkheden, zie bijlage B:

• het patiëntbericht versturen naar een informatiedoorgever, volgensNEN7503,

• het patiëntbericht klaarzetten en aanmelden in de verwijsindex.

Wanneer een zorgverlener een of meer patiëntberichten wil versturen maar hetschakelpunt blijkt op dat moment niet bereikbaar, dan moet de zorgverlener dezepatiëntberichten kunnen bewaren voor latere verzending.


[B15] {toekomst} Zorgverleners moeten een patiëntbericht kunnen klaarzettenzonder te versturen, door het aan te melden in de verwijsindex, zodat eenandere zorgverlener het kan ophalen.

[B16] Zorgverleners mogen niet in staat gesteld worden landelijk patiënt-gegevens te versturen, indien de vereiste identificatie en authenticatie vande patiënt/cliënt en diens dossier nog niet is uitgevoerd, zie bijlage A.


• Gebruiksscenario 2.2.1: sturen patiëntbericht naar een andere zorgverlener,

• Gebruiksscenario 2.2.2: ontvangen patiëntbericht van een anderezorgverlener,

• Gebruiksscenario 2.2.3: klaarzetten ongeadresseerd patiëntbericht,

• Gebruiksscenario 2.2.4: ophalen ongeadresseerd patiëntbericht.

Bij (gebruiksscenario 2.2.1) versturen patiëntbericht gelden de volgende eisen enwensen:

(a) De gebruiker moet bij het samenstellen van een patiëntbericht het volgendekunnen aangeven:

o het type patiëntbericht: opdracht, antwoord en melding,o het BSN van de onderhavige patiënt/cliënt, door deze te selecteren

uit een lijst van patiënten/cliënten in het eigen patiëntdossier,o of de aflevering van het patiëntbericht in de juiste postbus aan de

afzender wel of niet onmiddellijk bevestigd moet worden.

(b) De gebruiker moet bij het samenstellen van een patiëntbericht de inhoud opverschillende manieren kunnen invullen:


o door het kiezen van een berichtsoort en het handmatig ofautomatisch invullen van de velden,

o {toekomst} door het kiezen van een vrij tekstformaat en hethandmatig invullen van het bericht,

o door het bijvoegen van een kopie van een patiëntstuk uit het eigenpatiëntdossier,

o {toekomst} door het aangeven van de identificatie van eenpatiëntstuk uit het eigen patiëntdossier.

(c) De gebruiker moet bij het samenstellen van een patiëntbericht debestemming op verschillende manieren kunnen aangeven:

o door de afzender van een ander patiëntbericht automatisch over tenemen als bestemming,

o door één of meer zorgaanbieders te selecteren uit dezorgaanbiedergids, zie paragraaf 4.2.4, of eventueel uit een eigenzorgaanbiederadresboek,

o door rechtstreeks het HL7-adres in te voeren.

(d) De gebruiker moet bij het verzenden van een patiëntbericht:o worden gewaarschuwd indien het schakelpunt of de postbus van de

bestemde zorgaanbieder niet bereikbaar is,o ervoor kunnen kiezen om het patiëntbericht te bewaren voor latere

verzending,o bij de eerstvolgende keer inloggen erop worden geattendeerd dat er

patiëntberichten klaarstaan voor verzending,o alle klaarstaande patiëntberichten alsnog kunnen verzenden.

(e) De gebruiker moet, indien het samenstellen, adresseren en verzenden vaneen patiëntbericht automatisch plaatsvindt, de mogelijkheid hebben om:

o de inhoud of strekking van het patiëntbericht te beoordelen,o de verzending van het patiëntbericht te continueren of te stoppen.

Bij (gebruiksscenario 2.2.2) ontvangen patiëntbericht gelden de volgende eisen enwensen:

(f) De gebruiker moet na het ontvangen van een patiëntbericht de inhoud op devolgende manieren kunnen ontsluiten:

o door het selecteren van het bijgevoegde patiëntstuk,o {toekomst} door het selecteren van de identificatie van een

patiëntstuk genoemd in het patiëntbericht en het opvragen daarvanuit het patiëntdossier van de afzender.

(g) De gebruiker moet na het ontsluiten van de inhoud van patiëntgegevens ineen patiëntbericht, deze op de volgende manieren kunnen afhandelen:

o door het uitlezen daarvan door de zorgverlener,o door het automatisch uitlezen daarvan door een applicatie,o door het opnemen daarvan in het eigen patiëntdossier, aangemerkt

als kopie,o door het wissen ervan.

(h) De gebruiker moet na het ontvangen van een patiëntbericht van het typeopdracht, een patiëntbericht van het type antwoord kunnen terugsturen endaarbij:


o automatisch de afzender van het ontvangen patiëntberichtovernemen als bestemming,

o automatisch de referentie naar de identificatie van het ontvangenpatiëntbericht vermelden,

o automatisch de identificatie van de onderhavige patiënt/cliëntovernemen,

o aangeven of de opdracht wordt geaccepteerd of afgewezen.

Bij (gebruiksscenario 2.2.3) klaarzetten patiëntbericht gelden de volgende eisen enwensen:

(i) {toekomst} De gebruiker moet een patiëntbericht kunnen klaarzettenzonder te versturen, opdat een andere zorgaanbieder het patiëntbericht zelfkan opvragen, waarbij geldt:

o zonder vermelde bestemming kan iedere geautoriseerdezorgaanbieder het bericht opvragen,

o met vermelde bestemming kan iedere vermelde, geautoriseerdezorgaanbieder het bericht opvragen.

Bij (gebruiksscenario 2.2.4) ophalen patiëntbericht gelden de volgende eisen enwensen:

(j) {toekomst} De gebruiker moet uitgaande van een geselecteerdepatiënt/cliënt (zie use case 0.3.1) een totaaloverzicht van alle klaargezettepatiëntberichten gepresenteerd krijgen, met daarin vermeld voor iederpatiëntbericht:

o zorgaanbieder-functie van die zorgaanbieder,o berichtsoorten bij die zorgaanbieder,o actualiteit van die berichtsoort bij die zorgaanbieder,o indicatie van de beschikbaarheid van die patiëntberichten.

(k) {toekomst} De gebruiker moet, uitgaande van het totaaloverzicht, dooreenvoudig aanklikken een patiëntbericht kunnen ophalen.

Bij (gebruiksscenario 2.2.1) versturen patiëntbericht en (gebruiksscenario 2.2.3)klaarzetten patiëntbericht geldt bovendien:

(l) De gebruiker mag voor een patiënt/cliënt diens patiëntgegevens landelijkversturen of klaarzetten, alleen indien:

o diens BSN ooit door de desbetreffende zorgaanbieder is opgevraagdof geverifieerd bij het landelijke patiëntregister,

waarbij de zorgverlener moet worden gewaarschuwd indien:o het WID nog niet is gecontroleerd op gelijkenis met de patiënt/cliënt,o het WID nog niet is gecontroleerd op echtheidskenmerken,o het dossier nog niet inhoudelijk is gecontroleerd met de

patiënt/cliënt.



Opmerkingen:

• Ad (gebruiksscenario 2.2.1) Het versturen van patiëntberichten wordtidealiter ondersteund door een zorgaanbiederapplicatie die de zorgverlenerafschermt van de vele, bovengenoemde keuzemogelijkheden en hetversturen zonodig combineert met andere acties. Zo zal een elektronischvoorschrijfsysteem het opstellen van een medicatievoorschrift én hetvastleggen daarvan als patiëntstuk in het eigen dossier én het versturendaarvan als patiëntbericht naar een andere zorgaanbieder, als ééngecombineerde actie aan de gebruiker presenteren.

• Ad (a) De aard van het patiëntbericht geeft aan of het onderdeel is van eenreeks samenhangende interacties. Zo is een melding een vrijblijvendpatiëntbericht, waarop niet gereageerd hoeft te worden. Een opdrachtberichtkan het begin zijn van een transactie, met status verstuurd. Daarop kunnenantwoordberichten komen, die de status van de transactie veranderen ingeaccepteerd of afgewezen, dan wel uitgevoerd. Daarop kunnen nog andereberichten volgen, die telkens de status veranderen. Dit verschilt perzorgtoepassing.

• Ad (c) Wegens de foutgevoeligheid is het niet wenselijk dat zorgverlenerseigenhandig HL7-adressen gaan intoetsen. Toch kan het noodzakelijk zijn,bijv. als een zorgaanbieder (nog) niet vermeld staat in dezorgaanbiedergids.

• Ad (c) In plaats van steeds de landelijke zorgaanbiedergids raadplegen, kanhet doelmatiger zijn om bereikbaarheidsgegevens over te nemen naar eeneigen zorgaanbiederbestand. Momenteel gebruiken zorgaanbieders vaak eenzogenaamd derdenbestand waarin voor iedere patiënt/cliënt onder meer deeigen huisarts en de vaste apotheek wordt vastgelegd. Het nadeel van dezealternatieven is dat ze de keuzevrijheid van de patiënt/cliënt beperken.

• Ad (e) Ook als een zorgaanbiederapplicatie, zoals een elektronischvoorschrijfsysteem, de zorgverlener afschermt van het bewerkelijke invullenvan een patiëntbericht, blijft de zorgverlener verantwoordelijk voor hetresultaat. Daarom moet hij de kans hebben om het resultaat te beoordelenen de verzending eventueel af te breken.

• Ad (g) Het uitlezen van een ontvangen patiëntstuk kan automatischplaatsvinden door bijv. een werkstroomapplicatie die opdrachten alsmedicatievoorschriften of labaanvragen, etc. automatisch toewijst aanbeschikbare medewerkers.

• Ad (g) Overigens mag een zorgverlener conform de WGBO kopieën vanpatiëntstukken alleen opnemen in het eigen dossier voorzover het op datmoment noodzakelijk is voor de behandeling.

• Ad (h) De identificatie van een ontvangen patiëntbericht is nodig opdatzorgaanbiederapplicaties eventueel transacties kunnen ondersteunen. Vaneen transactie is pas sprake als de opdrachtgevende applicatie na ontvangstvan een antwoordbericht een statusverandering in het eigen patiëntdossierdoorvoert. Merk op dat het schakelpunt slechts interacties voorbij zietkomen en dus geen transacties bewaakt. De transactie moet dus door debeide zorgaanbiederapplicaties worden bewaakt.


• Ad (j) Het ophalen van een patiëntbericht is vergelijkbaar met het opvragenvan een patiëntstuk zoals beschreven in paragraaf 4.2.9 onder punt (k). Eenbelangrijk verschil is echter: na het ophalen van een patiëntbericht wordt,net als bij het positief beantwoorden van een opdrachtbericht, deuitvoeringsverantwoordelijkheid voor dat verzoek geaccepteerd. Daarbijverandert de status van de transactie naar verstuurd.


4.2.11 Overdragen patiëntgegevens

Zoals beschreven in paragraaf 3.6.3 moet een zorgverlener de verantwoordelijkheidvan bepaalde patiëntstukken, of zelfs een heel patiëntdossier, via het schakelpuntveilig kunnen overdragen aan een andere zorgverlener.

Het overdragen van patiëntstukken houdt in dat de ene zorgverlener bepaaldepatiëntstukken aanmerkt als kopie in het eigen patiëntdossier, de stukken alsorigineel verstuurt in een opdrachtbericht naar een andere zorgverlener, waarna dieandere zorgverlener de verantwoordelijkheid kan accepteren of weigeren.

Bij acceptatie legt die andere zorgverlener de aangeboden patiëntstukken vast inhet eigen dossier als origineel, geeft ze vrij voor opvraag door derden (met zonodigeen aanmelding bij de verwijsindex) en stuurt een acceptatiebericht terug. Daarnakan de eerste zorgverlener de patiëntstukken afschermen voor opvraag doorderden (met zonodig een afmelding bij de verwijsindex) en eventueel verwijderen.

Bij weigering stuurt die andere zorgverlener een weigerbericht terug. Daarna kande eerste zorgverlener de patiëntstukken weer als origineel aanmerken.


[B17] Zorgverleners mogen niet in staat gesteld worden landelijk patiënt-gegevens over te dragen indien de vereiste identificatie en authenticatievan de patiënt/cliënt en diens dossier nog niet zijn uitgevoerd, zie bijlageA.


• Gebruiksscenario 2.3.1: verzoeken overdracht van patiëntstukken,

• Gebruiksscenario 2.3.2: beantwoorden overdracht van patiëntstukken,

• Gebruiksscenario 2.3.2: afronden overdracht van patiëntstukken.

Bij (gebruiksscenario 2.3.1) verzoeken overdracht gelden de volgende eisen enwensen:

(a) De gebruiker moet de overdracht van patiëntstukken kunnen verzoeken na:o vermelden van het BSN van de onderhavige patiënt/cliënt door te

selecteren uit een lijst van patiënten/cliënten in het eigenpatiëntdossier,

o selecteren van bepaalde patiëntstukken uit het eigen patiëntdossier,o aanmerken van die patiëntstukken in het eigen patiëntdossier als

kopie,o adresseren van de begunstigde, door een zorgaanbieder te selecteren

uit een eigen zorgaanbiederadresboek of de zorgaanbiedergids, zieparagraaf 4.2.4, of door rechtstreeks het HL7-adres in te voeren.

Bij (gebruiksscenario 2.3.2) beantwoorden overdracht gelden de volgende eisen enwensen:

(b) De gebruiker moet de overdacht kunnen beoordelen door het inzien van deaangeboden patiëntstukken.


(c) De gebruiker moet de overdacht kunnen weigeren door:o vermelden van de reden van de weigering,o vastleggen van de aangeboden patiëntstukken in het eigen

patiëntdossier, aangemerkt als kopie,o versturen van een weigerbericht aan de verzoekende zorgverlener.

(d) De gebruiker moet de overdacht kunnen accepteren door:o vastleggen van de aangeboden patiëntstukken in het eigen

patiëntdossier, aangemerkt als origineel,o eventueel vrijgeven van de aangeboden patiëntstukken voor opvraag

door derden (met zonodig een afmelding bij de verwijsindex),o versturen van een acceptatiebericht aan de verzoekende

zorgverlener.

Bij (gebruiksscenario 2.3.3) afronden overdracht gelden de volgende eisen enwensen:

(e) De gebruiker moet een weigerbericht kunnen verwerken door:o aanmerken van de geweigerde patiëntstukken in het eigen

patiëntdossier als origineel,

(f) De gebruiker moet een acceptatiebericht kunnen verwerken door:o afschermen van de overgedragen patiëntstukken voor opvraag door

derden (met zonodig een afmelding bij de verwijsindex),o of verwijderen van de overgedragen patiëntstukken uit het eigen

patiëntdossier.

Bij (gebruiksscenario 2.3.1) verzoeken overdracht en (gebruiksscenario 2.3.2)beantwoorden overdracht geldt bovendien:

(g) De gebruiker mag voor een patiënt/cliënt de overdracht van patiëntstukkenkunnen verzoeken resp. accepteren, alleen indien:

o diens BSN ooit is opgevraagd of geverifieerd bij het landelijkepatiëntregister,

o diens WID ooit is gecontroleerd met de patiënt/cliënt,o diens WID ooit is gecontroleerd op echtheidskenmerken,o diens dossier ooit inhoudelijk is gecontroleerd met de patiënt/cliënt.


Opmerkingen:

• De overdracht van patiëntstukken is een transactie tussen tweezorgaanbiederapplicaties. Merk op dat het schakelpunt slechts interactiesvoorbij ziet komen en dus geen transacties bewaakt. De transactie moet dusdoor de beide zorgaanbiederapplicaties worden bewaakt.

• Gedurende de transactie staan de desbetreffende patiëntstukken mogelijktwee keer vermeld in de verwijsindex. Bij opvragen zal blijken dat hetkopieën van elkaar zijn.


• Ad (a) Het verzoek tot overdracht is hier gecombineerd met de onderhavigepatiëntstukken, zoals dat bijvoorbeeld passend is voor het overdragen vaneen waarneemverslag bij huisartswaarneming. In geval van overdracht vaneen dossier is het verstandiger om eerst het verzoek te laten accepteren ofweigeren en daarna pas het dossier over te sturen. Daarbij kan nogonderscheid gemaakt worden tussen een haal-mechanisme en een breng-mechanisme. Dit wordt in een latere versie van dit document uitgewerkt.

• Ad (c) Ondanks de weigering kan de andere zorgverlener de ontvangenpatiëntstukken opnemen in zijn patiëntdossier, maar dan wel als kopie. Merkop dat het plaatsen van een los patiëntstuk in een bepaalde context van eendossier nieuwe toegevoegde waarde kan hebben.

• Ad (f) In principe mogen patiëntstukken niet worden verwijderd uit eenpatiëntdossier, maar in geval van overdacht tussen twee zelfstandige artsen,mogen geen kopieën worden achtergehouden conform de KNMG-richtlijnen,zie paragraaf 3.5.1.


4.2.12 Beheren autorisatieprotocol

Bij het autorisatieprotocol beschreven in paragraaf 3.7.2, moet onderscheidgemaakt worden tussen:

• een algemeen autorisatieprotocol, waarin de bevoegdheden van allezorgpartijen grofmazig staan vermeld, per gegevensklasse.

• een medisch autorisatieprotocol, waarin de bevoegdheden nader zijnuitgesplitst naar de functie van de zorgaanbieders en de gegevenssoortbinnen de klasse van medische gegevens.

De onderstaande tabel geeft een voorbeeld van een algemeen autorisatieprotocol:

Agerendezorgpartij

patiënt/cliënt

zorg-aanbieder

zorg-verzeker.

zorg-coördin.

Reagerendezorgpartij

gegevens-klasse

patiënten-register persoonlijk

O, eigen O O O

patiënt/cliëntpersoonlijk O, eigen O O, eigen O

zorgaanbiederpersoonlijk O, eigen O O Omedisch O, eigen M - -logistiek O, eigen O - Ofinancieel O, eigen - O, eigen -

zorgverzeker.financieel O, eigen O, eigen - -

…

De bevoegdheid kan per vakje worden aangeduid, bijv.:• O = bevoegd tot opvragen van deze patiëntgegevens,• V = bevoegd tot versturen van deze patiëntgegevens,• M = zie medisch autorisatieprotocol.

De reikwijdte van de bevoegdheid kan per vakje worden beperkt, bijv.:• eigen = alleen patiëntgegevens van de eigen patiënt.

De derde kolom geeft bijv. aan dat een zorgverzekeraar toegang heeft tot devolgende patiëntgegevens:

• persoonlijke gegevens in het patiëntenregister (SBV-Z),• persoonlijke gegevens in de patiëntkluizen van alleen de eigen cliënten,• persoonlijke gegevens in de dossiers van zorgaanbieders,• logistieke gegevens in de dossiers van zorgaanbieders,• financiële gegevens in de dossiers van zorgaanbieders van alleen de eigen

cliënten.

De bovenstaande invulling van bevoegdheden is slechts illustratief. Het algemeneautorisatieprotocol is vooralsnog alleen van toepassing op het opvragen van hetBSN. Pas na uitwerking van relevante landelijke toepassingen, kunnen meerrepresentatieve voorbeelden worden gegeven.


De onderstaande tabel geeft een voorbeeld van een deel van een medischautorisatieprotocol:

Landelijketoepassing:

EMD WDH

Gebruikers-interactie:

Publicmedicvoor

Verstumedicvoor

Opvramedicvoor

Publicmedicver

Verstumedicver

Opvramedicver

Public1-lijnsdoss

Opvrasamenvatt

Verstuverslag

Zorgverlener-functie:

schrft schrft schrft strekk strekk strekk DWH DWH

Apotheker,stad V V V VApotheker,zkh V V V V...Arts,allergolo.. V V V VArts,cardiolog.. V V V VArts,dermatol.. V V V VArts,gastro-e.. V V V VArts,huisarts... V V V V V V V V V...

In de praktijk zal weinig gebruik gemaakt worden van alle mogelijke differentiaties.Zo zullen de meeste artsen vermoedelijk dezelfde bevoegdheden krijgen, ongeachthun specialisme en betrokkenheid.

De tabellen met het algemene en het medische autorisatieprotocol kunnen worden:

• bijgehouden door autorisatiebeheerders op direct of indirect verzoek van demedische beroepsverenigingen in samenwerking met de patiënten-vereniging, nadat zij onderling een nieuw of gewijzigd autorisatieprotocolzijn overeenkomen.

• {toekomst} geraadpleegd door zorgverleners die willen weten welkebevoegdheden zij hebben. Anders zullen zij proefondervindelijk moetenvaststellen welke gegevenssoorten wel/niet toegankelijk zijn voor hen.


[B18] {toekomst} Zorgverleners moeten het autorisatieprotocol kunnenraadplegen.


• Gebruiksscenario 3.1: raadplegen autorisatieprotocol en autorisatielog.

• Gebruiksscenario 3.2: aanpassen algemeen autorisatieprotocol.

• Gebruiksscenario 3.3: aanpassen medisch autorisatieprotocol.

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd alsautorisatiebeheerder of lokale beheerder (zie gebruiksscenario 0.2.1).

Bij (gebruiksscenario 3.1) gelden de volgende eisen en wensen:


(a) de gebruiker moet het algemene en het medische autorisatieprotocolkunnen raadplegen, waarbij hij kan kiezen voor:

o de actuele situatie,o de toekomstige wijzigingen,o een historische situatie, door invoer van een bepaalde datum in het

verleden.

(b) de gebruiker moet de autorisatielog kunnen raadplegen, waarin wordtbijgehouden welke autorisatiebeheerder op welk tijdstip welke wijzigingheeft doorgevoerd.

Bij (gebruiksscenario 3.2) aanpassen algemeen autorisatieprotocol gelden devolgende eisen en wensen:

(c) de gebruiker moet het algemene autorisatieprotocol kunnen aanpassen,door voor iedere combinatie van:

o opvragende zorgpartijo opleverende zorgpartijo de gegevensklasse

de bevoegdheid vast te leggen met:o de bevoegde algemene gebruikersinteractie(s), zie paragraaf 5.3.1o {toekomst} autorisatieniveauo vereiste vertrouwensniveau: laag, midden, hoogo vereiste logging: wel, nieto ingangsdatum van wijziging

behalve voor de combinatie zorgaanbieder/zorgaanbieder/medisch, wantdaarvoor geldt het medische autorisatieprotocol.

Bij (gebruiksscenario 3.3) aanpassen medisch autorisatieprotocol gelden devolgende eisen en wensen:

(d) de gebruiker moet het medische autorisatieprotocol kunnen aanpassen, doorvoor iedere combinatie van

o de functie van de zorgverlenero de betrokkenheid van de zorgverlener: hoofdbehandelaar,

waarnemer, medebehandelaarde bevoegdheid vast te leggen met:

o de bevoegde medische gebruikersinteractie(s), zie paragraaf 5.3.1o {toekomst} autorisatieniveauo {toekomst} vereiste vertrouwensniveau: laag, midden, hoogo ingangsdatum van wijziging

Opmerkingen:

• de ontwerpbeslissing [B18] is als {toekomst} aangemerkt, omdat daarvooreerst HL7v3-berichten gedefinieerd moeten worden.

• ad (c) In het algemene autorisatieprotocol kan worden ingesteld of bijv. hetopvragen van persoonlijke patiëntgegevens (bijv. BSN) wel of niet gelogdmoet worden. Indien de bron (SBV-Z) zelf de logging verzorgt, zou hetschakelpunt dat niet hoeven te doen.


• ad (d) In het medische autorisatieprotocol kan niet worden ingesteld ofbepaalde gebruikersinteracties wel of niet gelogd moeten worden, want datzou fraudegevoelig zijn. Gebruikersinteracties met medische gegevensmoeten altijd worden gelogd.

• ad (c) en (d) Het autorisatieniveau heeft voorlopig geen betekenis. In detoekomst kunnen verschillende niveaus onderkend worden, in lijn met degevoeligheidsniveaus gehanteerd in [prENV13606:2003] en [HL7v3].

• ad (d) De gegevenssoorten in het medisch autorisatieprotocol moetenovereenkomen met die in de gegevenssoortentabel, zie paragraaf 4.3.4.

• De autorisatiebeheerder werkt direct of indirect in opdracht van de medischeberoepsverenigingen in samenwerking met de patiëntenvereniging.

• Medewerkers staan niet vermeld in het autorisatieprotocol, want zij kunnenhooguit onder verantwoordelijkheid van een mandaterende zorgverlenertoegang krijgen, zie paragraaf 3.7.4. Eventueel zou het landelijkeautorisatieprotocol gebruikt kunnen worden om een landelijke grens testellen aan de mandateringen van afzonderlijke zorgverleners, indien daarbehoefte aan is.


4.2.13 Bijhouden autorisatieprofiel

Het autorisatieprofiel van een patiënt/cliënt, zoals beschreven in paragraaf 3.7.2,bestaat uit:

• een vlag om aan te geven of de patiënt/cliënt überhaupt akkoord gaat metelektronische, landelijke uitwisseling van zijn patiëntgegevens,

• nadere wensen om bepaalde zorgpartijen uit te sluiten van inzage, alsinperking op het generieke autorisatieprotocol,

• {toekomst} vlaggen om aan te geven of de patiënt/cliënt akkoord gaat metelektronisch inkijken in zijn autorisatieprofiel, toegangslog resp. elektronischwijzigen van zijn autorisatieprofiel.

De onderstaande tabel geeft een voorbeeld van een autorisatieprofiel.

Patiënt/cliënt BSN Akkoord uitw.pat.geg. jaLaatst gewijzigd: dd-mm-jjjj Akkoord inkijk log ja

Akkoord inkijk profiel jaAkkoord wijzig profiel nee

Gegevensklasse > Persoonlijk Medisch Logistiek FinancieelZorgpartijzorgverleners alle N N N Narts, huisarts... Jansen A A A Aapothekers alle T T T Tapotheker Pietersen N N N Nzorgverzekeraars alle X X X X

Algemeene A X A A...

De bevoegdheid kan per vakje worden aangeduid als, bijv.:• A = altijd• N = alleen in noodgeval• T = alleen na expliciete toestemming• X = nooit

De patiënt/cliënt heeft in het bovenstaande voorbeeld aangegeven:

• akkoord te gaan met elektronische uitwisseling van zijn patiëntgegevensconform het autorisatieprotocol, met de navolgende uitzonderingen,

• dat zorgverleners in het algemeen geen inzage krijgen, met uitzonderingvan:

o een huisarts met UZI-nr 123 die alles mag inzien,o alle apothekers die alleen met expliciete toestemming alles mogen

inzien,o echter met uitzondering van apotheker met UZI-nr 234,

• dat zorgverzekeraars in het algemeen geen inzage krijgen, met uitzonderingvan:


o verzekeringsmij “De Algemeene” met UZOVI-nr 123 die alles maginzien behalve medische gegevens.

Het autorisatieprofiel van een patiënt/cliënt kan worden bijgehouden door:

• autorisatiebeheerders op verzoek van die patiënt/cliënt. Afhankelijk van dewerklast die dit zal opleveren voor de autorisatiebeheerders, kan dit beperktblijven tot het wijzigen van het al/of niet akkoord gaan met elektronischeuitwisseling.

• zorgaanbieders op verzoek van die patiënt/cliënt. Afhankelijk van deinrichting, kan dit beperkt blijven tot het interne autorisatieprofiel bij diezorgaanbieder, in welk geval de patiënt/cliënt langs elk van zijn zorg-aanbieders moet.

• de patiënt/cliënt zelf, bijvoorbeeld via het Internet wanneer hij beschikt overeen geschikt elektronisch vertrouwensmiddel. Verwacht wordt dat iedereburger in de toekomst een e-NIK heeft.

Wanneer een patiënt/cliënt niet akkoord gaat met elektronische uitwisseling vanzijn patiëntgegevens, mogen zorgaanbieders zijn gegevens ook niet aanmelden bijde verwijsindex. Nadeel daarvan is dat, wanneer hij later alsnog akkoord gaat, aande verwijsindex niet te zien is waar inmiddels allemaal patiëntgegevens van hemliggen en dat deze gegevens dus ook niet opgevraagd kunnen worden.Patiënten/cliënten dienen daarover duidelijk te worden voorgelicht.

In plaats daarvan kan een patiënt/cliënt ervoor kiezen wèl akkoord te gaan metelektronische uitwisseling, maar alle bevoegheden op nooit laten zetten. Op dezewijze worden zijn patiëntgegevens wèl aangemeld aan de verwijsindex, maar zijnze voor niemand zichtbaar.

Wanneer een patiënt/cliënt niet akkoord gaat met elektronische uitwisseling vanzijn patiëntgegevens, moet het voor zorgaanbieders mogelijk blijven om diens BSNop te vragen uit het landelijke patiëntenregister. Zorgaanbieders zijn immersverplicht om het BSN ook te gebruiken voor papieren uitwisseling van patiënt-gegevens.

Het is denkbaar dat een patiënt/cliënt in zijn autorisatieprofiel de bevoegdhedenvan bepaalde zorgverleners zou willen verruimen ten opzichte van die in hetautorisatieprotocol. Daarvoor is niet gekozen, want dit zou de werking vanautorisatie nog complexer maken dan het al is. Bovendien is het zeer de vraag ofeen zorgverlener met verruimde bevoegdheden eraan zal denken voor die enepatiënt/cliënt een opvraag te doen waarvoor hij gewoonlijk niet geautoriseerd is.

Als voor een patiënt/cliënt géén autorisatieprofiel is ingevuld (en dat zalaanvankelijk voor de meeste patiënten/cliënten het geval zijn), geldenverstekwaarden voor de “akkoord”-velden. Hoewel wordt gestreefd naarveronderstelde toestemming voor elektronisch uitwisseling van patiëntgegevensvoor alle patiënten/cliënten die geen bezwaar aantekenen (zie de toelichting oppunt (d) van paragraaf 3.7.2), is nog onzeker of dat lukt. Aldus moeten verstek-waarden voor akkoord kunnen worden ingesteld. Dit wordt dus een apartealgemene tabel.



[B19] Autorisatieprofielen zijn alleen van toepassing op patiëntgegevensafkomstig uit dossiers van zorgpartijen, niet op gegevens uit publiekeregisters.

[B20] Autorisatieprofielen geven een inperking van bevoegdheden ten opzichtevan die in het autorisatieprotocol.

[B21] Zorgverleners kunnen de autorisatieprofielen niet raadplegen, wegens devertrouwelijkheid, zie paragraaf 4.3.6.

[B22] Zorginstellingen kunnen de eventuele interne uitwisseling vanpatiëntgegevens regelen met interne autorisatieprofielen, die niet kunnenworden overgenomen van de landelijke autorisatieprofielen.


• Gebruiksscenario 5.1:raadplegen autorisatieprofiel.

• Gebruiksscenario 5.2: aanpassen akkoord.

• Gebruiksscenario 5.3: aanpassen autorisatieprofiel.

• Gebruiksscenario 5.4: vastleggen bewijs.

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd alslandelijke autorisatiebeheerder (zie gebruiksscenario 0.2.1). Een gebruiker dieheeft ingelogd als lokale autorisatiebeheerder binnen een zorginstelling, kangebruiksscenario 5.3 uitvoeren voor interne profielen. In de toekomst kan eengebruiker die heeft ingelogd als patiënt/cliënt de gebruiksscenario’s 5.1, 5.2 en 5.3uitvoeren op zijn eigen autorisatieprofiel.

Bij (gebruiksscenario 5.1) raadplegen autorisatieprofiel gelden de volgende eisen enwensen:

(a) de gebruiker moet het autorisatieprofiel van een patiënt/cliënt kunnenraadplegen, waarbij hij kan kiezen voor:

o de actuele situatie,o een historische situatie, door invoer van een datum in het verleden.

Bij (gebruiksscenario 5.2) aanpassen akkoord gelden de volgende eisen en wensen:

(b) de gebruiker moet voor alle patiënten/cliënten kunnen wijzigen:o de verstekwaarde voor het wel/niet akkoord gaan met elektronische

uitwisseling van zijn patiëntgegevens door zorgaanbieders,o {toekomst} de verstekwaarde voor het wel/niet akkoord gaan met

elektronisch inkijken in de toegangslog door hemzelf,o {toekomst} de verstekwaarde voor het wel/niet akkoord gaan met

elektronisch inkijken van zijn autorisatieprofiel door hemzelf,o {toekomst} de verstekwaarde voor het wel/niet akkoord gaan met

elektronisch wijzigen van zijn autorisatieprofiel door hemzelf.


(c) de gebruiker moet voor een patiënt/cliënt kunnen wijzigen het wel/nietakkoord gaan met elektronische uitwisseling van zijn patiëntgegevens doorzorgaanbieders, waarbij:

o in geval van “niet akkoord” de gebruiker vooraf wordt gewaarschuwdals de verwijsindex nog verwijzingen naar deze patiënt/cliënt bevat,

o in geval van “niet akkoord” na bevestiging van de gebruiker, dieverwijzingen worden verwijderd uit de verwijsindex,

o in geval van “niet akkoord” voortaan alle aanmeldingen vanzorgaanbieders worden geweigerd,

o in geval van “wel akkoord” voortaan alle aanmeldingen vanzorgaanbieders worden toegevoegd aan de verwijsindex.

o wijziging door de patiënt/cliënt zelf wordt geëffectueerd aan het eindvan de dag.

(d) {toekomst} de gebruiker moet voor een patiënt/cliënt kunnen wijzigen hetwel/niet akkoord gaan met elektronisch inkijken in de toegangslog doorhemzelf, waarbij:


(e) {toekomst} de gebruiker moet voor een patiënt/cliënt kunnen wijzigen hetwel/niet akkoord gaan met elektronisch inkijken van zijn autorisatieprofieldoor hemzelf, waarbij:


(f) {toekomst} de gebruiker moet voor een patiënt/cliënt kunnen wijzigen hetwel/niet akkoord gaan met elektronisch wijzigen van zijn autorisatieprofieldoor hemzelf, waarbij:


Bij (gebruiksscenario 5.3) aanpassen autorisatieprofiel gelden de volgende eisen enwensen:

(g) de gebruiker moet het autorisatieprofiel van een patiënt/cliënt kunnenaanpassen door voor iedere combinatie van

o zorgpartij, eventueel uitgedrukt in functie of identiteito de gegevensklasse

de bevoegdheid tot toegang vast te leggen met:o altijdo alleen in noodsituatieo {toekomst} na expliciete toestemmingo nooit

zodanig dat de autorisatieregels in de opgegeven volgorde worden toegepastbij het opvragen en versturen van diens patiëntgegevens:

Bij (gebruiksscenario 5.4) vastleggen bewijs gelden de volgende eisen en wensen:

(h) de gebruiker moet een juridisch geldig bewijs vastleggen (op papier ofelektronisch) van het feit dat de patiënt/cliënt de nieuwe instellingen heeftgezien en daarmee uitdrukkelijk akkoord gaat.


Opmerkingen:

• het niet akkoord gaan van een patiënt/cliënt met elektronische, landelijkeuitwisseling van patiëntgegevens zoals vastgelegd in het autorisatieprofiel,moet niet worden verward met het afschermen van patiëntgegevens.Afschermen is bedoeld om specifieke patiëntstukken uit te sluiten vanlandelijke uitwisseling, zie ook paragraaf 4.2.6.

• ad (b) wanneer het BSN wordt ingevoerd in de zorg, zal iedere burgerdaarover waarschijnlijk worden geïnformeerd per brief. Het is raadzaam deburger daarbij te vragen schriftelijk wel/niet akkoord te gaan metelektronische uitwisseling van patiëntgegevens. Bij voorkeur wordt “welakkoord” als verstekwaarde gehanteerd, zie de toelichting op punt (d) vanparagraaf 3.7.2. De antwoorden van de burgers kunnen worden verwerktdoor de autorisatiebeheerders in gebruiksscenario 5.2.

• ad (c,d,e,f) het zou een te zware eis zijn, als wijzigingen via het Internetonmiddellijk moesten worden geëffectueerd. Tevens wordt enige drempelopgeworpen voor patiënten/cliënten die onvoorbereid wijzigingendoorvoeren en daarop onmiddellijk weer terugkomen met nieuwe inzichten.In geval van (c) is dat bovendien ter bescherming van hemzelf, want als deverwijsindex éénmaal is geleegd, kan deze niet meer hersteld worden.

• ad (f) logischerwijze kan een patiënt/cliënt zelf via het Internet:• wel instellen dat hij niet akkoord gaat,• niet instellen dat hij wel akkoord gaat,

met elektronisch wijzigen van zijn autorisatieprofiel door hemzelf. In hetlaatste geval zal de patiënt/cliënt zich moeten wenden tot deautorisatiebeheerders.

• ad (g) een autorisatieregel koppelt een doelgroep aan een bevoegdheid.Autorisatieregels kunnen qua doelgroep elkaar (al dan niet deels)overlappen en kunnen qua bevoegheid een tegengestelde werking hebben.Het op volgorde toepassen van overlappende autorisatieregels geeftdaardoor de mogelijkheid tot verfijnde autorisatie met weinig regels.

• ad (g) behalve zorgverleners kunnen ook medewerkers worden uitgesloten.Daartoe moet wel diens UZI-nummer bekend zijn. Medewerkers met eenUZI-pas niet op naam hebben geen vast UZI-nummer, maar zij hoeven ookniet uitgesloten te worden, omdat zij überhaupt geen toegang tot medischepatiëntgegevens krijgen.

Openstaande punten:

• Ad (c) overwogen kan worden de patiënt/cliënt nog beter tegen zichzelf tebeschermen, bijv. door de patiënt/cliënt per brief nog eens te informerenover de consequenties van het intrekken van het akkoord en pas na diensbevestiging de verwijsindex te wissen.

• Ad (c) een patiënt/cliënt die pas later akkoord geeft, heeft op dat momenteen nog lege verwijsindex. Er is momenteel geen mechanisme gedefinieerdom historische aanmeldingen met terugwerkende kracht te doen uitvoeren.


4.2.14 Raadplegen toegangslog

Zoals beschreven in paragraaf 3.7.3, moet de toezichthouder en een patiënt/cliëntkunnen (laten) achterhalen welke patiëntgegevens ooit landelijk (of eventueelintramuraal) zijn opgevraagd of verstuurd, door raadplegen van een toegangslog.Onderstaande tabel geeft een voorbeeld van een deel van een toegangslog.

Pa-tiënt/cliënt

Agerendezorgpartij

Gebruikersinter-actie

Reagerendezorgpartijen

Datum/ Tijd

Nr. Naam: Functie: Naam: Functie:... ... ... ... ...BSN1 Jansen arts,huisa.. Opvragen index nvt ...BSN1 Jansen arts,huisa.. Opvragen med.

voorschriftenWillemsenGerritsen

Amstel-zkh.Hendriks..

arts,huisa..arts,huisa..arts,urolo..verloskun..

...

BSN1 PietersennamensJansen

medewerk..

arts,huisa..

Opvragen med.verstrekkingen

Amstelapo..Veenapot..Maasapot..

apothekerapothekerapotheker

...

BSN1 Jansen arts,huisa.. Versturen med.voorschrift

Veenapot.. apotheker ...

... ... … ... … ... ...

De toegangslog kan worden geraadpleegd door:

• logbeheerders die in opdracht van de toezichthouder periodiek willen nagaanwelke zorgaanbieders mogelijk onrechtmatig patiëntgegevens hebbenopgevraagd of verstuurd, dan wel dit ten onrechte hebben nagelaten.

• logbeheerders die op verzoek van een patiënt/cliënt willen achterhalenwelke zorgaanbieders patiëntgegevens over deze patiënt/cliënt hebbenopgevraagd of ontvangen, bijv. bij vermoeden van onrechtmatige toegangof wanneer de patiënt zijn patiëntdossier wil laten vernietigen en dus wilachterhalen waar eventuele kopieën van die patiëntstukken liggen.

• logbeheerders die op verzoek van een zorgaanbieder willen controleren of deverstuurde patiëntgegevens daadwerkelijk zijn afgeleverd bij de bedoeldezorgaanbieder, bijv. indien de laatste beweert niets te hebben ontvangen.

• zorgaanbieders die zelf willen achterhalen welke patiëntgegevens doorandere zorgaanbieders zijn opgevraagd uit zijn patiëntdossier.

• zorgaanbieders die op verzoek van een patiënt/cliënt willen achterhalenwelke patiëntgegevens over deze patiënt/cliënt door andere zorgaanbiederszijn opgevraagd uit het eigen patiëntdossier.

• patiënten/cliënten, wanneer zij beschikken over een geschikt elektronischvertrouwensmiddel. De toegang blijft beperkt tot het deel dat hun eigenpatiëntgegevens betreft.


Merk op dat logbeheerders niet zijn geautoriseerd om patiëntgegevens inhoudelijkte bekijken. Als een patiënt/cliënt wil weten wat een andere zorgaanbieder preciesgezien heeft, zal hij zich moeten wenden tot de zorgaanbieder die verantwoordelijkis voor die patiëntgegevens. Hij zal een bericht-id nodig hebben om de onderhavigepatiëntstukken precies te kunnen traceren.

Een zorginstelling zal ook de eventuele interne uitwisseling van patiëntgegevenstussen afzonderlijke zorgverleners moeten loggen en ter beschikking van eentoezichthouder moeten kunnen stellen. Dit speelt vooral voor grote zorginstellingenmet verschillende gespecialiseerde afdelingen. Interne uitwisseling valt in principebuiten het werkterrein van NICTIZ, maar het ligt voor de hand dergelijke eisen hiertoch een plaats te geven.


[B23] Logbeheerders krijgen alleen inzage in welke soorten patiëntgegevens zijnuitgewisseld. Alleen de verantwoordelijke zorgaanbieder en depatiënt/cliënt krijgen inzage in de inhoudelijke patiëntgegevens.

[B24] Logbeheerders moeten ook kunnen achterhalen of een zorgaanbieder eenindex van beschikbare gegevenssoorten heeft opgevraagd(gebruiksscenario 2.1.1) en welke gegevenssoorten van patiëntstukkenooit zijn aangemeld of afgemeld in de verwijsindex (gebruiksscenario 2.3).

[B25] Zorginstellingen moeten zelf de eventuele interne uitwisseling vanpatiëntgegevens kunnen loggen.


• Gebruiksscenario 4.1: opvragen lijst van zorgaanbieders die landelijkpatiëntstukken hebben opgevraagd of verstuurd.

• Gebruiksscenario 4.2: opvragen inhoud van de patiëntstukken die ooit dooreen bepaalde zorgaanbieder landelijk zijn opgevraagd of verstuurd.

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd alslogbeheerder, zorgverlener of {toekomst} patiënt/cliënt (zie gebruiksscenario0.2.1) op vertrouwensniveau midden.


(a) De toegang tot logregels moet als volgt worden beperkt:o een logbeheerder mag alle logregels inzien en na de bewaartermijn

verwijderen,o een zorgverlener mag alle logregels inzien en na de bewaartermijn

verwijderen m.b.t. patiëntgegevens waarvoor hij verantwoordelijk is,o een patiënt/cliënt mag alle logregels inzien m.b.t. patiëntgegevens

over zichzelf.

(b) De gebruiker moet een lijst van logregels kunnen oproepen, die per logregelde volgende attributen kan tonen, voor zover relevant:

o de identiteit van de patiënt/cliënt,o de agerende zorgpartij, in geval van zorgaanbieder:

o de identiteit van de zorgaanbieder,


o de functie en identiteit van de zorgverlener of medewerker,o indien relevant: de functie en identiteit van de mandaterende

zorgverlener,o de reagerende zorgpartijen, in geval van zorgaanbieder:

o de identiteit van de zorgaanbieder,o de functie en identiteit van de zorgverlener(s),

o de identiteit van de agerende applicatie,o de identiteit van de reagerende applicatie (s),o de uitgevoerde gebruikersinteractie, zie paragraaf 5.3.1o het tijdstip van de interactie,o de episode waarvoor de gebruikersinteractie is uitgevoerd,o de reden waarom de gebruikersinteractie is uitgevoerd,o het toegepaste vertrouwensniveau,o een indicatie of een beroep is gedaan op een noodsituatie,o het resultaat van de autorisatie,o bericht-id van het originele verzoekbericht,o bericht-id van het doorgeschakelde verzoekbericht,o aantal retries dat nodig was voor het doorschakelen van het

verzoekbericht,o indicatie (s) van eventueel opgetreden foutsituaties m.b.t. het

doorschakelen van het verzoekbericht,o bericht-id (‘s) van de originele antwoordbericht (en),o bericht-id (‘s) van de doorgeschakelde antwoordbericht (en),o bericht-id van de bundel van doorgeschakelde opleverberichten,o aantal retries dat nodig was voor het doorschakelen van het

antwoordbericht,o een indicatie van eventueel opgetreden foutsituaties m.b.t. het

doorschakelen van het antwoordbericht.

(c) De gebruiker moet voor de lijst van logregels kunnen selecteren datuitsluitend worden getoond:

o logregels voor een bepaalde patiënt/cliënt, zie gebruiksscenario 0.3,o logregels binnen een bepaald tijdvenster,o logregels met bepaalde gebruikersinteracties,o bepaalde attributen per logregel.

(d) De gebruiker moet in de lijst van logregels:o kunnen bladeren,o kunnen bepalen volgens welk attribuut de logregels op volgorde

worden gezet,o kunnen zoeken naar logregels met een aangegeven waarde voor één

of meer van de attributen,o een te selecteren deel van de logregels kunnen afdrukken,o een te selecteren deel van de logregels kunnen exporteren naar een

intelligent analysegereedschap.

(e) De gebruiker moet logregels:o tot een instelbare bewaartermijn kunnen raadplegen,o na die instelbare bewaartermijn kunnen verwijderen.

(f) De gebruiker moet voor een bepaalde patiënt/cliënt:o logregels jonger dan 3 maanden binnen 5 seconden kunnen

oproepen,o logregels ouder dan 3 maanden binnen 1 uur kunnen oproepen.


(g) De gebruiker moet de zekerheid hebben:o dat eenmaal aan de toegangslog toegevoegde logregels niet meer

kunnen worden gewijzigd of verwijderd voor het einde van debewaartermijn,

o dat eenmaal na de bewaartermijn verwijderde logregels geenonbedoelde sporen nalaten.


(h) {toekomst} De gebruiker moet op basis van een bericht-id de inhoud vanhet bericht kunnen raadplegen, binnen 1 dag.

Opmerkingen:

• In paragraaf 4.3.8 zal blijken dat er een centrale toegangslog bij hetschakelpunt moet komen en lokale toegangslogs bij de zorgaanbieders. Datis een ontwerpbeslissing die in principe niet relevant is voor de alhierbeschreven gebruiksscenario’s, behalve dat een lokale toegangslog minderlogregels en minder attributen per logregel bevat, zie hieronder.

• Ad (a) de logbeheerder moet alle logregels zoals gelogd door hetschakelpunt kunnen inzien, de zorgverlener alleen de logregels diebetrekking hebben op patiëntgegevens uit zijn dossiers, , de patiënt/cliëntalleen de logregels die betrekking hebben op zichzelf.

• Ad (b) de zorgverlener(s) als onderdeel van de reagerende zorgaanbiederkan zijn:

o (in geval van versturen) de zorgverlener voor wie de verstuurdepatiëntgegevens bestemd zijn, zoals vermeld in het opdrachtbericht,

o (in geval van opvragen) de zorgverlener(s) die verantwoordelijk zijnvoor de opgeleverde patiëntgegevens, zoals vermeld in deopleverberichten,

maar in de praktijk zijn deze velden vaak leeg.

• Ad (b) Niet alle attributen kunnen door de zorgaanbiederapplicatie wordengelogd. De attributen die niet kunnen worden gelogd zijn voor dezorgverlener ook niet zichtbaar.

• Ad (b) In geval van opvragen index is er geen sprake van een bepaaldegegevenssoort, maar wordt index vermeld. Dergelijke logregels kunnenalleen door het schakelpunt worden gelogd.

• Ad (f) De bewaartermijn van logregels is nog niet vastgesteld. Daarom isdeze instelbaar gemaakt. Deze bewaartermijn heeft overigens weinig temaken met de de wettelijke bewaartermijn van patiëntgegevens, zieparagraaf 3.5.1. Immers een logregel kan betrekking hebben op eenopvraag die patiëntgegevens van 1 dag oud en patiëntgegevens van bijna15 jaar oud heeft opgeleverd.

• Ad (g) Voor het oplossen van operationele en technische problemen (zieonder meer gebruiksscenario 6) moeten de logregels van de laatste 3maanden on-line raadpleegbaar blijven. Voor het achterhalen van al dan nietrechtmatige toegang tot patiëntgegevens moet men verder terug in de tijd


kunnen, maar laat de responstijd toe oudere logregels op een off-linemedium te archiveren en off-line te doorzoeken (bijv. door een verzamelingDVD-schijfjes één voor één te laden en te doorzoeken).

• Ad (e) Als gevolg van foutsituaties (autorisatie, onbereikbare patiënt-dossiers, etc.) kan het opvragen of versturen van patiëntstukken geheel ofdeels mislukken. Bij een gedoseerde opvraag kan de opvragendezorgaanbieder bovendien de stroom opleverberichten tussentijds afbreken.Daarom is het belangrijk te weten welke indexregels en patiëntstukkendaadwerkelijk zijn verzonden aan een zorgaanbieder.

• Ad (h) Bij vernietiging van een patiëntdossier zouden idealiter ook allereferenties naar dat dossier vanuit de toegangslog worden verwijderd. In depraktijk zal dit nauwelijks realiseerbaar zijn als toegangslog zal wordengearchiveerd op een off-line medium.

• Ad (h) De mate van zekerheid m.b.t. de volledigheid van de toegangslogmoet in verhouding staan tot de mate van onweerlegbaarheid van deinhoud, zoals moet blijken in de juridische praktijk.

• Ad (i) Deze eis pakt verschillend uit voor het schakelpunt resp. dezorgaanbieder, zie ook paragraaf 4.3.8:

o het schakelpunt moet berichten met indexregels inhoudelijk loggen,o {toekomst} zorgaanbieders moet berichten met patiëntgegevens

inhoudelijk loggen.Merk op dat hiervoor een ruime responstijd geldt.


4.2.15 Bijhouden mandateringen

Zoals beschreven in paragraaf 3.7.4, moet een zorgverlener als hoofdbehandelaarkunnen vastleggen in een mandateringstabel welke andere zorgverleners (alsmedebehandelaar) en/of medewerkers (met UZI-pas op naam) zijn gemandateerdom namens hem landelijk patiëntgegevens uit te wisselen. De gemandateerdezorgverlener of medewerker geniet dan de bevoegdheden van de mandaterendezorgverlener, zoals bepaald in het autorisatieprotocol. De onderstaande tabel geefteen voorbeeld van een mandateringstabel:

Mandaterende:Naam: Functie:Jacobsen Arts, internist

Gebruikers-interactie:

Publicerenmedicatie

Opvragenmedicatie

Versturenmedicatie

…

Gemandateerde: voorschrift voorschrift voorschriftNaam: Functie:Jansen Arts, internist V V V ...Gerritsen Arts, basisarts V V V ...Pietersen medewerker V ...Willemsen medewerker V ...... ... ... ... ... ...

In het bovenstaande voorbeeld mandeert een internist:• een collega internist resp. een basisarts (bijv. een arts in opleiding) tot het

landelijk aanmelden, afmelden, opvragen en versturen,• twee medewerkers (bijv. co-assistenten) tot alleen landelijk opvragen van

patiëntgegevens.

De mandaterende zorgverlener blijft verantwoordelijk voor de handelingen van dedoor hem gemandateerde medebehandelaren en medewerkers. Daarom is hetbelangrijk dat de mandaterende zorgverlener goed grip houdt op zijnmandateringen, zonder onnodige rompslomp. Zo zal een zorgverlener zijn vastemedewerkers voor onbepaalde tijd willen mandateren. Voor tijdelijke medewerkerszal hij een verlooptijd willen specificeren.


[B26] Alleen zorgverleners als hoofdbehandelaar worden in staat gesteld tot hetvastleggen, raadplegen, wijzigen en verwijderen van hun eigenmandateringen. Daarnaast krijgen alleen gemandateerdemedebehandelaren en medewerkers inzage in de aan hen toegekendemandateringen.

[B27] Omdat men door verscheidene zorgverleners kan worden gemandateerd,zal bij het uitoefenen van een gemandateerde bevoegdheid moeten wordenaangeven (automatisch door de applicatie of handmatig door de gebruiker)namens wie een gemandateerde medebehandelaar of medewerker handelt.


• Gebruiksscenario 7.1: bijwerken mandateringen.


• Gebruiksscenario 7.2: inzien mandateringen.

Bij (gebruiksscenario 7.1) bijwerken mandateringen gelden de volgende eisen enwensen:

(a) De gebruiker moet hebben ingelogd als zorgverlener (zie gebruiksscenario0.2.1) op vertrouwensniveau midden.

(b) De gebruiker moet namens hemzelf een nieuwe mandatering kunnenvastleggen door het kiezen van:

o de identiteit van te mandateren zorgverlener of medewerker,o de bevoegde medische gebruikersinteractie(s), zie paragraaf 5.3.1o een ingangsdatum,o eventueel een verloopdatum

en het automatisch overnemen uit het vertrouwensmiddel van de gebruiker:o de identiteit van de mandaterende zorgverlener

waarbij zekergesteld wordt dat de mandaterende en gemandateerde totdezelfde zorgaanbieder behoren.

(c) De gebruiker moet een lijst van alle door hemzelf vastgelegdemandateringen kunnen raadplegen.

(d) De gebruiker moet uitsluitend een door hemzelf vastgelegde mandateringkunnen wijzigen.

(e) De gebruiker moet uitsluitend een door hemzelf vastgelegde mandateringkunnen verwijderen.

Bij (gebruiksscenario 7.2) inzien mandateringen gelden de volgende eisen enwensen:

(f) De gebruiker moet hebben ingelogd als zorgverlener of medewerker (ziegebruiksscenario 0.2.1).

(g) De gebruiker moet een lijst van alle aan hem toegekende mandateringenkunnen raadplegen.

(h) De gebruiker moet een mandaterende zorgverlener kunnen kiezen alshoofdbehandelaar namens wie hij patiëntgegevens gaat beheren ofuitwisselen.

Opmerkingen:

• Afhankelijk van de zorgtoepassing, zou gebruiksscenario 7.2 automatischkunnen volgen op het inloggen van een medewerker of automatischvoorafgaan aan een poging tot het landelijk uitwisselen vanpatiëntgegevens. Het is ook denkbaar dat een applicatie op grond van hetBSN van de onderhavige patiënt automatisch kan bepalen wie de hoofd-behandelaar is en namens wie de medewerker dus moet handelen. Dit isbelangrijk voor een gezondheidscentrum, waar een medewerker doorverscheidene huisartsen gemandateerd kan worden, maar afhankelijk vande bellende patiënt altijd één mandaterende huisarts moet kiezen.


• Ad (b) De met de UZI-pas ingelogde zorgverlener is dus automatisch demandaterende zorgverlener. Het is dus niet mogelijk dat een lokalebeheerder even alle mandateringen regelt, want een zorgverlener wordt zelfpersoonlijk aangesproken als een gemandateerde medewerker onrechtmatigpatiëntgegevens opvraagt. Wel is het denkbaar dat een zorginstelling-verantwoordelijke alle mandateringen voorbereidt, zodat een mandaterendezorgverlener deze slechts met een druk opde knop hoeft te bekrachtigen. Ditis belangrijk voor een HAP, waar veel medewerkers door veel waarnemendehuisartsen gemandateerd moeten worden.


4.2.16 Beheren zorgaanbiederapplicatie

Voordat een zorgaanbiederapplicatie kan worden aangesloten op een schakelpunt,zie paragraaf 4.2.1, moet het volgende gebeuren:

• het zorgsysteem waarvan deze applicatie onderdeel uitmaakt, moet nagoedkeuring als GBZ, eenmalig worden gekoppeld aan de ZIM door hetwederzijds vastleggen van GBZ-id, URI en andere configuratieparameters,zie ook paragraaf 4.2.17 punt (p), waarna het GBZ kan worden opengestelddoor de schakelpuntbeheerder, zie punt (o).

• de aan te sluiten zorgapplicatie moet vervolgens eenmalig worden voorzienvan een applicatie-id en worden geassocieerd met een UZI-servicescertificaat in het GBZ, die tezamen met andere configuratie-parameters worden vastgelegd in het schakelpunt, zie paragraaf 4.2.17 punt(p).

Omdat een zorgaanbiederapplicatie naar keuze moet kunnen worden aangeslotenop de operationele ZIM, de uitwijk-ZIM of de test-ZIM (zie ook paragraaf 5.7.2),moeten de bovenstaande koppelingen in principe voor alle ZIM’s wordengeconfigureerd.

Daarnaast moet per applicatie worden vastgelegd welke toepassingsrollen wordengeactiveerd. Immers, een bepaalde applicatie kan zijn gekwalificeerd voor zowelWDH als EMD, terwijl de huisarts aanvankelijk slechts WDH wil activeren. Tenslottekunnen bereikbaarheidsgegevens van de beheerder van het GBZ of de applicatieworden ingevoerd.


• Gebruiksscenario 8.1: koppelen van een GBZ aan een ZIM.

• Gebruiksscenario 8.2: koppelen van een applicatie aan een schakelpunt.

Bij (gebruiksscenario 8.1) koppelen GBZ aan ZIM gelden de volgende eisen enwensen:

(a) De gebruiker moet de volgende configuratieparameters kunnen instellenvoor zijn GBZ:

• GBZ-id,• URI en hostnaam van het GBZ,• URI en hostnaam van de operationele ZIM,• URI en hostnaam van de test ZIM,• URI en hostnaam van de uitwijk ZIM,###• naam van het GBZ zoals bekend bij de zorgaanbieder,• naam van de zorgaanbieder,• abonneenummer van de zorgaanbieder in het UZI-register,• E-mailadres van de beheerder,• telefoonnummer van de beheerder.

Bij (gebruiksscenario 8.2) koppelen applicatie aan schakelpunt gelden de volgendeeisen en wensen:


(b) De gebruiker moet binnen zijn GBZ verscheidene zorgapplicaties kunnentoevoegen en verwijderen, en daarvoor de volgende configuratieparameterskunnen instellen per zorgapplicatie:

• applicatie-id van de zorgapplicatie,• applicatie-id van het operationele schakelpunt waarop kan worden

aangesloten,• applicatie-id van het test-schakelpunt waarop kan worden

aangesloten,• applicatie-id van het uitwijk-schakelpunt waarop kan worden

aangesloten,• UZI-nr van het UZI-servicescertificaatwaarmee het is geassocieerd,• fabrikaat en type van de zorgapplicatie,• naam van de zorgapplicatie zoals bekend bij de zorgaanbieder,• naam van de zorgaanbieder,• E-mailadres van de beheerder,• telefoonnummer van de beheerder,• toepassingsrollen die worden geactiveerd,• HL7v3-conformancetabel van de zorgapplicatie,• HL7v3-release gebruikt door de zorgapplicatie.

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd alsbeheerder.

Opmerkingen:

• Als het gehele GBZ slechts één beheerder heeft, kunnen diensbereikbaarheidsgegevens bij (a) worden opgegeven. Als iedere applicatieeen afzonderlijke beheerder heeft, kunnen diens bereikbaarheidsgegevensbij (b) worden opgegeven. Combinaties van beide zijn ook mogelijk. Eenapplicatie kan deze gegevens meegeven in de Transport Wrapper vanHL7v3-berichten. In de toekomst zouden deze gegevens eventueelautomatisch bij (de eerste) aansluiting op de ZIM kunnen wordendoorgegeven aan de ZIM in een toestandsbericht.

• De naam van de zorgaanbieder, moet altijd worden meegegeven in deControlAct Wrapper van HL7v3-berichten. Deze naam is gewoonlijk voor hetgehele GBZ hetzelfde, maar er kan de behoefte zijn om per applicatie bijv.de naam van de afdeling toe te voegen. Idealiter komt deze naam overeenmet die in de zorgaanbiedergids.


4.2.17 Beheren schakelpunt

Zoals beschreven in paragraaf 3.10.2, moet een schakelpuntbeheerder de goedewerking van de schakelpunten en alle daarop aangesloten objecten kunnenbewaken en besturen. In theorie heeft ieder beheerobject variabelen die kunnenworden bewaakt en parameters die kunnen worden bestuurd. Beheerders kunnenworden gealarmeerd door grenswaarden op variabelen te zetten.

Zoals zal blijken in hoofdstuk 5 vallen sommige objecten binnen een DCN of eenGBZ en vallen ze daarmee onder besturing van netwerkdienstaanbieders ofzorgaanbieders. De aansluitingen van de GBZ’en en DCN’en op de ZIM’s liggen inbeide besturingsdomeinen:

• Om te kunnen aansluiten, moeten het GBZ en de ZIM elkaars hostnamenen eventueel elkaars URI kennen. Daartoe moeten de schakelpuntbeheerderen de zorgaanbieder elkaars configuratieparameters in hun eigen systeeminvoeren.

• Om daadwerkelijk aan te sluiten, moet de schakelpuntbeheerder dekoppeling openstellen, na verificatie dat de XIS inderdaad een GBZ-statusheeft. Daarna kan de zorgaanbieder zijn GBZ pas communiceren met deZIM.

De schakelpuntbeheerder kan de GBZ’en en DCN’en alleen indirect beïnvloeden,bijv. door telefonisch aanwijzingen te geven aan die andere beheerders, bijv. omeen GBZ opnieuw te laten synchroniseren met de verwijsindex. Daartoe moet deschakelpuntbeheerder die andere objecten wel kunnen bewaken, bijv. door hetbijhouden van foutentellers van ieder GBZ. Merk op dat er naast de operationeleZIM ook een uitwijk-ZIM en een test-ZIM kunnen zijn.

Binnen een GBZ kunnen meerdere applicaties draaien, zie paragraaf 5.2.8. Dieapplicaties kunnen afzonderlijk worden aangesloten op het schakelpunt. Alleaangesloten objecten moeten een uniek ID hebben. Hoewel zorgaanbieders zelfzouden kunnen zorgen voor unieke GBZ-id’s en applicatie-id’s, is het veiliger deschakelpuntbeheerder deze ID’s te laten uitgeven.


[B28] de schakelpuntbeheerder moet de ZIM’s en alle daarop aangeslotenDCN’en en GBZ’en kunnen bewaken.

[B29] de schakelpuntbeheerder moet de ZIM kunnen configureren en besturentot en met het openstellen dan wel blokkeren van afzonderlijkekoppelingen met DCN’en en GBZ’en.

[B30] een zorgaanbieder moet een GBZ kunnen bewaken, besturen enconfigureren tot en met het aansluiten van het GBZ op de ZIM via een DCNen het eventueel afsluiten daarvan.

[B31] de schakelpuntbeheerder geeft voor ieder aan te sluiten GBZ en iedereapplicatie een uniek GBZ-id resp. applicatie-id uit.



• Gebruiksscenario 6.1: beheren ZIM.

• Gebruiksscenario 6.2: beheren DCN-koppeling aan ZIM.

• Gebruiksscenario 6.3: beheren GBZ-koppeling aan ZIM.

• Gebruiksscenario 6.4: beheren alarmmeldingen.

Bij alle gebruiksscenario’s gelden de volgende eisen en wensen:

(a) Bij het oproepen van een overzicht van variabelen van beheerobjecten,moet de gebruiker kunnen kiezen uit:

• actuele waarden: lopende gemiddelden/totalen over een instelbaardynamisch tijdsinterval (bijv. seconde, minuut, uur).

• historische waarden: gerealiseerde gemiddelden/totalen over eeninstelbaar historisch tijdsinterval (bijv. jaar, maand, week, dag).

(b) Bij het oproepen van een overzicht van variabelen van beheerobjecten,moet de gebruiker kunnen kiezen uit:

• grafiek: grafische presentatie van het verloop van de actuele ofhistorische waarden van te kiezen variabelen over een instelbaartijdsinterval.

• tabel: tabellarische presentatie van het verloop van de historischewaarden van te kiezen variabelen over een instelbaar tijdsintervalmet instelbare tussenstappen (bijv. alle maandelijkse waarden vaneen jaar).

• diagram: presentatie van een statisch diagram (dat bijv. deaansluiting van een GBZ voorstelt) waarin de actuele waarden van tekiezen variabelen dynamisch worden gepresenteerd, in de kleur dieovereenkomt met de eventuele alarmtoestand, zie gebruiksscenario6.4.

• log: chronologische lijst van gewijzigde variabelen, waarbij in gevalvan stuurparameters of configuratieparameters wordt vermeld welkegebruiker op welk tijdstip welke wijziging heeft doorgevoerd.

(c) Na het oproepen van een overzicht van variabelen van beheerobjecten,moet de gebruiker kunnen kiezen voor:

• export: vastleggen van geselecteerde historische waarden in eenexportbestand dat kan worden geladen in een intelligent analyse-gereedschap.

• rapportage: vastleggen van het gepresenteerde in een rapport, datkan worden opgeslagen, teruggehaald, gepresenteerd, afgedrukt enper E-mail verstuurd.

Bij (gebruiksscenario 6.1) beheren ZIM gelden de volgende eisen en wensen:

(d) De gebruiker moet een overzicht kunnen oproepen van de volgendevariabelen voor iedere geconfigureerde ZIM:

• beschikbaarheid van deze ZIM,• aantal GBZ’en dat:

§ geconfigureerd is voor aansluiting op de ZIM,§ daadwerkelijk is aangesloten op de ZIM,


• aantal gebruikers dat:§ nieuw heeft ingelogd,§ vergeefs heeft geprobeerd in te loggen,§ actief ingelogd is,§ zojuist heeft uitgelogd,

• gebruikte on-line opslagruimte door de:§ berichtenwachtrij,§ toegangslog,§ autorisatielog,§ systeemlog,§ alarmlog.

• tijdstip van de laatste volledige resp. incrementele backup,• alle stuurparameters en configuratieparameters voor deze ZIM,

en de volgende variabelen voor ieder afzonderlijk schakelpunt binnen dezeZIM, plus de totalen/gemiddelden over alle schakelpunten van deze ZIMindien zinvol:

• beschikbaarheid van het schakelpunt, zie paragraaf 5.7.4,• per gebruikersinteractie:

§ aantal interacties per seconde,§ aantal mislukte interacties, uitgesplitst naar foutsoort,§ aantal interacties dat via een ander schakelpunt afgehandeld

moest worden,§ gemiddeld aantal uitgewisselde patiëntstukken per interactie,§ gemiddeld aantal uitgewisselde bytes per interactie,§ minimum, gemiddelde en maximum responstijd,

• aantal applicaties dat:§ geconfigureerd is voor aansluiting op het schakelpunt,§ daadwerkelijk aangesloten is op het schakelpunt,

• alle stuurparameters en configuratieparameters van dit schakelpunt.

(e) De gebruiker moet de volgende stuurparameters kunnen instellen vooriedere geconfigureerde ZIM:

• status van de koppeling van deze ZIM met andere ZIM’s:§ opengesteld,§ geblokkeerd,

• bereikbaarheid van de ZIM, zie paragraaf 5.7.4,• beschikbare on-line opslagruimte voor de:

§ berichtenwachtrij,§ toegangslog,§ autorisatielog,§ systeemlog,§ alarmlog,

• tijdsparametertabel, zie paragraaf 4.3.13,• maximum aantal gelijktijdige SSL/TLS-sessies met een GBZ-

gebruiker (gebruikerssessies) per GBZ,en de volgende stuurparameters kunnen instellen voor iedere afzonderlijkschakelpunt, dan wel voor alle schakelpunten tegelijk indien zinvol:

• beschikbaarheid van het schakelpunt, zie paragraaf 5.7.4,• actiemodus van het schakelpunt, zie paragraaf 5.7.4,• per gegevenssoort:

§ maximum aantal patiëntstukken dat het schakelpunt peropvraag zal opleveren aan een opvragende applicatie,


§ maximum aantal patiëntstukken dat het schakelpunt peropvraag zal opvragen bij een achterliggende applicatie,

§ tijdsinterval na een aanmelding bij de verwijsindex,waarbinnen de applicatie nieuwe patiëntgegevens nietopnieuw hoeft aan te melden,

§ maximum tijdsinterval dat het schakelpunt wacht op eenopleverende applicatie, voordat het schakelpunt eenfoutmelding teruggeeft aan de opvragende applicatie,

§ maximum tijdsinterval dat het schakelpunt wacht op eenontvangstbevestiging, voordat het schakelpunt eenfoutmelding teruggeeft aan de versturende applicatie.

(f) {toekomst} De gebruiker moet een nieuw ingestelde actiemodus van eenschakelpunt kunnen melden aan alle aangesloten applicaties door het sturenvan een bericht met de volgende gegevens:

• de nieuwe modus, zie paragraaf 5.7.4,• in geval van onderhoud met vermelding van:

o tekstuele toelichting,o verwachte tijdstip van weer beschikbaar zijn.

(g) De gebruiker moet binnen iedere ZIM schakelpunten kunnen toevoegen enverwijderen, en voor de ZIM de volgende configuratieparameters kunneninstellen:

• URI,• hostnaam,• E-mailadres van de schakelpuntbeheerder,• telefoonnummer van de schakelpuntbeheerder,

en voor ieder afzonderlijk schakelpunt:• applicatie-id,• naam van het schakelpunt zoals gebezigd door de beheerders,• ondersteunde toepassingsrollen,• HL7v3 conformancetabel,• gebruikte HL7v3-release.

(h) De gebruiker moet voor iedere ZIM de volgende acties kunnen ondernemenm.b.t. de verwijsindex:

• verwijderen van alle verwijzingen naar een bepaalde applicatie vaneen bepaald GBZ,

• synchroniseren met de verwijsindices van de andere ZIM’s,• kopiëren van de inhoud van de verwijsindex van een andere ZIM.

(i) De gebruiker moet voor iedere ZIM de volgende acties kunnen ondernemenm.b.t. de logboeken (toegangslog, autorisatielog, systeemlog, alarmlog):

• archiveren van de logboeken op een off-line opslagmedium,• terughalen van (een deel van) een logboek naar de on-line

opslagruimte.

(j) De gebruiker moet voor iedere ZIM de volgende acties kunnen ondernemen:• maken van een volledige back-up,• maken van een incrementele back-up,• terughalen van een back-up.


Bij (gebruiksscenario 6.2) beheren DCN-koppeling aan ZIM gelden de volgendeeisen en wensen:

(k) De gebruiker moet een overzicht kunnen oproepen van de volgendevariabelen voor ieder geconfigureerd DCN:

• netwerkbelasting van HL7v3-verkeer met de ZIM,• netwerkbelasting van overig IP-verkeer met ieder ander DCN.

(l) De gebruiker moet de volgende stuurparameters kunnen instellen voor iedergeconfigureerd DCN:

• status van de koppeling van het DCN aan de ZIM:§ opengesteld,§ geblokkeerd,

• maximum aantal aangesloten GBZ’en via dit DCN.

(m) De gebruiker moet een DCN-koppeling kunnen toevoegen enverwijderen, en daarbij de volgende configuratieparameters kunneninstellen:

• DCN-id,• eventuele IP-adresreeks voor het DCN,• naam van het DCN zoals bekend bij de ZSP en de zorginstellingen,• E-mailadres van de netwerkbeheerder,• telefoonnummer van de netwerkbeheerder,• DCN-kwalificatieniveau,• datum eerste toelating,• tekstuele toelichting,• URI van de ZIM waarop dit DCN primair wordt aangesloten,• URI van de uitwijk-ZIM waarop dit DCN kan terugvallen.

Bij (gebruiksscenario 6.3) beheren GBZ-koppeling aan ZIM gelden de volgendeeisen en wensen:

(n) De gebruiker moet een overzicht kunnen oproepen van de volgendevariabelen voor ieder geconfigureerd GBZ:

• bereikbaarheid van het GBZ, zie paragraaf 5.7.4,• alle stuurparameters en configuratieparameters voor dat GBZ,• per gebruikersessie:

§ UZI-nr. van de gebruiker,§ vertrouwensniveau van de sessie,§ tijdstip van inloggen,

en de volgende variabelen voor iedere afzonderlijke applicatie binnen datGBZ, plus de totalen/gemiddelden over alle applicaties van dat GBZ indienzinvol:

• beschikbaarheidmodus van de applicatie, zie paragraaf 5.7.4,• per gebruikersinteractie:

§ aantal interacties per seconde,§ aantal mislukte interacties, uitgesplitst naar foutsoort,§ aantal interacties dat via een ander schakelpunt afgehandeld

moest worden,§ minimum, gemiddelde en maximum responstijd bij actie,§ minimum, gemiddelde en maximum responstijd bij reactie,§ gemiddeld aantal uitgewisselde patiëntstukken per interactie,§ gemiddeld aantal uitgewisselde bytes per interactie,

• alle stuurparameters en configuratieparameters voor die applicatie.


(o) De gebruiker moet de volgende stuurparameters kunnen instellen voor iedergeconfigureerd GBZ:

• status van de koppeling van het GBZ aan de ZIM:§ opengesteld,§ geblokkeerd,

en de volgende stuurparameters kunnen instellen voor iedere afzonderlijkeapplicatie, dan wel voor alle applicaties van dat GBZ tezamen indien zinvol:

• actiemodus van de applicatie, zie paragraaf 5.7.4.

(p) De gebruiker moet een GBZ-koppeling kunnen toevoegen en verwijderen, endaarbij de volgende configuratieparameters kunnen instellen:

• GBZ-id,• URI van het GBZ,• UZI-nr van het UZI-servicescertificaat,• naam van het GBZ zoals bekend bij de zorgaanbieder,• naam van de zorgaanbieder,• abonneenummer van de zorgaanbieder in het UZI-register (URA),• E-mailadres van de beheerder,• telefoonnummer van de beheerder,• GBZ-kwalificatieniveau,• datum eerste toelating,• tekstuele toelichting,• DCN-id van het DCN waarop dit GBZ is aangesloten,

en binnen dat GBZ verscheidene applicaties kunnen toevoegen en verwij-deren, en daarvoor de volgende configuratieparameters kunnen instellen:

• applicatie-id• fabrikaat en type van de applicatie,• naam van de applicatie zoals bekend bij de zorginstelling,• naam van de zorgaanbieder,• toepassingsrollen waarvoor een (type-) goedkeuring is verkregen,• HL7v3 conformancetabel van de applicatie,• datum eerste toelating,• tekstuele toelichting,• gebruikte HL7v3-release.

(q) {toekomst} De gebruiker moet een bij (o) nieuw ingestelde actiemodus,deze kunnen afdwingen bij de desbetreffende applicatie door het sturen vaneen bericht met de volgende gegevens:

• de nieuwe actiemodus, zie paragraaf 5.7.4,• een tekstuele toelichting.

(r) {toekomst} De gebruiker moet een tekstbericht kunnen sturen naar alleGBZ–gebruikers van:

• één bepaald GBZ,• alle GBZ’en aangesloten op een bepaalde DCN of ZIM,• alle GBZ’en van alle ZIM’s.


Bij (gebruiksscenario 6.4) beheren alarmmeldingen gelden de volgende eisen enwensen:

(s) De gebruiker moet voor iedere variabele van ieder type beheerobject één ofmeer alarmtoestanden kunnen definiëren met de volgende eigenschappen:

o de grenswaarde die bij onder- of overschrijding leidt tot een alarm-toestand,

o de alarmklasse waarin de variabele wordt gezet bij passeren van degrenswaarde,

o een tekstuele omschrijving van de alarmtoestand.

(t) De gebruiker moet verscheidene alarmklassen kunnen definiëren met devolgende eigenschappen:

o in welke kleur de alarmtoestand moet worden getoond in de lijst vanalarmregels en in een overzicht van variabelen,

o of bij eerste optreden een visueel en/of auditief signaal moet wordengegevens.

(u) De gebruiker moet een lijst van alarmregels kunnen oproepen, die peralarmregel de volgende attributen kunnen tonen:

o de identiteit van het object,o de grenswaarde die was onder- of overschreden,o de opgetreden alarmklasse,o het tijdstip van dit optreden,o een tekstuele omschrijving van de alarmtoestand,o een indicatie of de alarmmelding reeds is “erkend”,o de afhandelingstatus van de alarmtoestand,o de identificatie van de gebruiker die de afhandelingstatus laatst heeft

gewijzigd,o een tekstuele toelichting van die gebruiker,

waarbij de kleur van de alarmregel overeenkomt met de alarmklasse.

(v) De gebruiker moet voor de lijst van alarmregels kunnen selecteren datuitsluitend worden getoond:

o alarmregels van bepaalde typen object,o alarmregels opgetreden binnen een bepaald tijdvenster,o alarmregels van bepaalde alarmklassen,o alarmregels met bepaalde afhandelingstatus,o bepaalde attributen per alarmregel.

(w)De gebruiker moet:o kunnen bladeren door de lijst van alarmregels,o kunnen bepalen volgens welk attribuut de alarmregels in de lijst op

volgorde worden gezet,o de afhandelingstatus van een alarmregel kunnen wijzigen in:

o nieuw,o erkend,o afgehandeld,

o een tekstuele toelichting kunnen toevoegen aan een alarmregel,o een te bepalen deel van de lijst kunnen afdrukken,o een te bepalen deel van de lijst kunnen exporteren naar een

intelligent analysegereedschap.


Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd alsschakelpuntbeheerder (zie gebruiksscenario 0.2.1).

Opmerkingen:

• Ad (f) Het melden van een actiemodus aan een applicatie kan in detoekomst worden gecombineerd met het synchroniseren van allerleistuurparameters uit het schakelpunt. In afwachting van deze functie kan deschakelpuntbeheerder de telefoon pakken of een e-mail sturen.

• Gebruiksscenario’s worden gewoonlijk top-down afgeleid uit de voorgaandeparagrafen. Dit gebruiksscenario is echter deels bottum-up afgeleid uitnavolgende hoofdstukken. Voor een goed begrip van de bovenstaande eisenis lezing van de navolgende hoofdstukken noodzakelijk.

• De taken van de schakelpuntbeheerder worden bij voorkeur verdeeld overgespecialiseerde beheerders:

o systeembeheerders voor het instellen van de parameters en hetbewaken van de variabelen van:

o de operationele ZIM, uitwijk-ZIM en test-ZIMo de koppeling van DCN’en aan iedere ZIM,o de koppeling van GBZ’en aan iedere ZIM,

o applicatiebeheerders voor de implementatie van:o nieuwe soorten en versies van HL7-berichten,o nieuwe gegevenssoorten,o nieuwe zorgverlenerfuncties,o nieuwe programmatuur voor de ZIM,

o klantenondersteuning die ten behoeve van netwerkbeheerders enzorgaanbieders en andere gebruikers inzicht moeten hebben in:

o de variabelen van de operationele ZIM,o de variabelen van DCN’en gekoppeld aan die ZIM,o de variabelen van GBZ’en gekoppeld aan die ZIM,

o test- & demo-beheerders die ten behoeve van XIS-leveranciers enXIS-beheerders moeten kunnen configureren:

o bewaken van de variabelen van de test-ZIM,o instellen van de parameters voor de koppeling van XIS’en aan

de test-ZIM.

4.2.18 Beheren patiëntenregister

Dit gebruiksscenario wordt overgelaten aan het BSN-programma.

4.2.19 Beheren zorgaanbiederregister

Dit gebruiksscenario wordt overgelaten aan het UZI-project.

4.2.20 Beheren zorgaanbiedergids

Dit gebruiksscenario wordt overgelaten aan het UZI-project.


4.3 Objecten

De ICT-voorzieningen in de zorg omvatten tenminste de onderstaande objecten:• schakelpunt, een algemeen toegangspunt voor het uitwisselen van

patiëntgegevens• verwijsindex, een tabel die de toegang tot alle patiëntdossiers mogelijk

maakt• toegangslog, een lijst waarin alle toegang tot patiëntdossiers via het

schakelpunt wordt gelogd• autorisatieprotocol, een tabel die de toegang van zorgpartijen tot

patiëntdossiers in het algemeen autoriseert• autorisatieprofiel, een tabel die de toegang tot de patiëntdossiers van een

specifieke patiënt/cliënt autoriseert• identificatie & authenticatie-module, een module die de geldigheid van

vertrouwensmiddelen verifieert,• patiëntdossier, een verzameling patiëntstukken onder verantwoordelijkheid

van één zorgaanbieder• zorgaanbiederpostbus, een verzameling patiëntberichten ontvangen door

één zorgaanbieder• zorgaanbieder-applicatie, een applicatie die een zorgverlener toegang kan

verschaffen tot zijn eigen patiëntdossier• patiënt-applicatie, een applicatie die een patiënt/cliënt toegang kan

verschaffen tot een verwijsindex• zorgaanbiederregister, een register met identificerende gegevens van

zorgaanbieders• zorgaanbiedergids, een gids met aangeboden zorgdiensten en

bereikbaarheidsgegevens van zorgaanbieders• patiëntenregister, een register met identificerende gegevens van

patiënten/cliënten• patiëntenadresboek, een adresboek met bereikbaarheidsgegevens van

patiënten/cliënten• schakelbeheer-applicatie, een applicatie die een schakelpuntbeheerder

toegang kan verschaffen tot het schakelpunt en de daaraan gekoppeldeobjecten

• autorisatiebeheer-applicatie, een applicatie die een autorisatiebeheerdertoegang kan verschaffen tot het autorisatiepotocol en alleautorisatieprofielen

• logbeheer-applicatie, een applicatie die een logbeheerder toegang kanverschaffen tot de toegangslog

• registerbeheer-applicatie, een applicatie die een registerbeheerder toegangkan verschaffen tot het patiëntenregister en/of het zorgaanbiedersregister.

• mandateringstabel, een tabel waarin een zorgverlener andere zorgverlenerskan mandateren om namens hem/haar patiëntgegevens uit te wisselen.

De belangrijkste van deze objecten worden in de navolgende paragrafen nadergespecificeerd. De structuur van de verwijsindex en die van het autorisatieprotocolis sterk afhankelijk van die van het patiëntdossier. Daarom wordt eerst hetpatiëntdossier gespecificeerd.


4.3.1 Patiëntdossier

Het patiëntdossier (PD) wordt hier gedefinieerd als een verzameling van(persoonlijke, logistieke, medische en/of financiële) patiëntgegevens van éénpatiënt/cliënt, die via één zorgaanbieder toegankelijk is.

Niettemin kan een zorgaanbieder, bijv. een ziekenhuis, meerdere, apartepatiëntdossiers van één patiënt/cliënt onderhouden, bijv. een medisch dossier perafdeling. In dat geval is er vaak een intern patiëntenregister, ook welpatiëntenindex genoemd, waarin de persoonlijke, identificerende gegevens centraalworden bijgehouden.

Zoals beschreven in paragraaf 3.4.3 en 3.4.5, kan een patiëntdossier wordengezien als een verzameling van patiëntmappen met één of meer patiënt-documenten, ieder bestaande uit één of meer patiëntgegevensbijdragen, die iederweer bestaan uit één of meer patiëntgegevenselementen: de kleinste eenheid vanpatiëntgegevens waarin een patiëntdossier kan worden opgebroken zonder dat debetekenis verloren gaat.

Ieder aggregatieniveau van patiëntstuk kan in principe als uittreksel van datpatiëntdossier worden uitgewisseld. In de praktijk zal dit afhangen van dezorgtoepassing en de gegevensoort, welke patiëntstukken zinvol kunnen wordenuitgewisseld. HL7v3 ondersteunt momenteel uitwisseling op het niveaupatiëntdocument en patiëntgegevenselement.

De onderstaande figuur toont de compositie van een patiëntdossier, in een UMLclass diagram.

Map

Document

Patiëntstuk

*

Bijdrage

*

Element

*

Patiëntdossier

*

Het bovenstaande betekent niet dat ieder patiëntdossier intern daadwerkelijk zogestructureerd dient te zijn. Bestaande zorgsystemen hebben ieder een eigenstructurering van patiëntgegevens, waarbij een bepaald patiëntgegevenselementvaak betekenis ontleent aan zijn context: de exacte plaats in het patiëntdossierwaar het element is opgeslagen. Wanneer zo’n element nu wordt opgevraagd, endus uit zijn context wordt gehaald, dient dit element te worden voorzien vanattributen die het dreigende verlies aan betekenis compenseren.


Het bovenstaande betekent wél dat ieder patiëntdossier na opvraag vanpatiëntgegevens, op dezelfde wijze patiëntstukken aan de opvrager moetopleveren. Dit betekent dat bestaande zorgsystemen zullen moeten wordenvoorzien van een adapter die de interne structurering van patiëntgegevens vertaaltnaar patiëntstukken volgens onderstaande specificatie.


[B32] {toekomst} Als gevolg van ontwerpbeslissing [B14] mogen in iederpatiëntdossier de patiëntstukken niet worden gewijzigd of verwijderd,tenzij het gehele dossier wordt vernietigd.

Ieder patiëntstuk zal, voor zover relevant, de volgende inhoud hebben:• generieke attributen,• specifieke attributen, bijv. medicijn, hoeveelheid, omschrijving, etc.• specifieke bulkinhoud, bijv.: vrije tekst, digitaal beeld, digitaal geluid, etc.

De standaardisering van de specifieke inhoud is het werkterrein van het programmaZorgtoepassingen, zie paragraaf 1.2. De standaardisering van de generiekekenmerken behoort tot de basisinfrastructuur en wordt hier aldus gespecificeerd.

Ieder patiëntstuk zal de volgende generieke attributen kunnen bevatten:• het landelijke patiëntnummer (BSN) van de onderhavige patiënt/cliënt• {toekomst} de integriteit van de koppeling aan deze patiënt/cliënt,• de verantwoordelijke zorgaanbieder die het patiëntstuk heeft bekrachtigd,• de functie van de verantwoordelijke zorgaanbieder,• het dossier waaruit dit patiëntstuk afkomstig is,• het tijdstip waarop het patiëntstuk is aangemaakt• het patiëntstuk-id, een unieke identificatie, zie paragraaf 5.10.4.

Ieder patiëntdocument zal bovendien de volgende generieke attributen kunnenbevatten:

• de gegevenssoort van dit patiëntdocument.• de samensteller die dit patiëntdocument heeft gefiatteerd,• het tijdstip waarop dit patiëntdocument is gefiatteerd,• de episode waartoe de zorgdienst behoort,• de periode waarin deze zorgdienst is gepland of heeft plaatsgevonden.

Iedere patiëntgegevensbijdrage zal bovendien de volgende generieke attributenkunnen bevatten:

• de gegevenssoort van deze bijdrage.• de vastlegger die deze bijdrage heeft vastgelegd,• het tijdstip waarop deze bijdrage is vastgelegd,• de betrokkenheid van deze vastlegger,• de handeling van deze vastlegger.

Ieder patiëntgegevenselement zal bovendien de volgende generieke attributenkunnen bevatten:

• de gegevenssoort van dit element,• de gegevensbron die dit element heeft gegenereerd,• het tijdstip waarop dit element is gegenereerd,

Voor een verklaring van verantwoordelijke, samensteller, vastlegger engegevensbron, zie paragraaf 3.5.3.


De gegevenssoort is een manier om de vele verschillende soorten patiëntstukken tetyperen, zie ook paragraaf 3.5, zoals:

• medicatieverstrekking• labuitslag• professionele samenvatting• dossier

De definitie van medische gegevenssoorten en de daarmee samenhangendestandaardisering van de specifieke inhoud per gegevenssoort, is het werkterreinvan het programma Zorgtoepassingen, zie paragraaf 1.2. Niettemin is in ditdocument ook behoefte aan gegevenssoorten uit de persoonlijke, logistieke enfinanciële gegevensklassen, zie paragraaf 3.4.2. De opnieuw in ontwikkeling zijndestandaard [prENV13606] is hier nog niet meegenomen. Dit zal in een latere versievan dit document geschieden.

De episode duidt (conform [prENV13940] “episode_of_care”) op een reeks vansamenhangende zorgcontacten die een zorgaanbieder heeft met een bepaaldepatiënt/cliënt in het kader van een bepaalde zorgvraag.

De periode (conform [prENV13940] “period_of_service”) kan de datum van eenafspraak, observatie of rekening zijn, maar ook een tijdsinterval waarvoor eenmedicatie is voorgeschreven.

Het dossier is het adres van de applicatie waarlangs het patiëntstuk toegankelijk is.Voor de basisinfrastructuur is het niet van belang of het element ook daadwerkelijkin dat systeem ligt opgeslagen. Zo kan een ZIS binnen een ziekenhuis eventueelfungeren als interne verwijsindex en aldus een opvraag doorschakelen naar bijv.een RIS of LIS aangesloten op dat ZIS. Zie ook Bijlage D.

De koppelintegriteit is een maat voor de zekerheid dat de patiëntstukken werkelijkhoren bij deze patiënt/cliënt, zoals een zorgaanbieder moet bijhouden in hetpatiëntendosssier of een lokaal patiëntenregister, zie paragraaf 4.3.10. Het staatnog ter discussie of deze koppelintegriteit ook moet worden meegezonden metpatiëntstukken. Vooralsnog is daarvan afgezien.


Het patiëntdossier dient de volgende operaties te kunnen afhandelen:

• Een externe opvraag van patiëntgegevens dient te worden beantwoord methet opleveren van:

o (index) een lijst met alle beschikbare gegevenssoorten, inclusief deactualiteit van het laatst toegevoegde patiëntstuk van diegegevenssoort,

o (inhoud) alle patiëntstukken, inclusief attributen maar exclusiefmultimedia, die voldoen aan de opvraagcriteria,

o (multimedia) één specifiek multimediaal patiëntstuk, dat voldoet aande opvraagcriteria,

Indien het patiëntdossier niet in staat is alle opvraagcriteria te interpreteren(legacy), dient het patiëntdossier de desbetreffende opvraagcriteria tenegeren en slechts de overige te interpreteren.

• Bij het lokaal invoeren, overdragen of verwijderen van patiëntstukken, dienthet patiëntdossier te melden aan de verwijsindex dat dit patiëntdossier wèlof géén patiëntstukken heeft met de kenmerken/attributen genoemd in deverwijsindex, tenzij:

o dit aan de vermelding in de verwijsindex niets verandert,o het patiëntstuk van deze gegevenssoort volgens het autorisatieprofiel

überhaupt niet opvraagbaar is (ook niet in noodgevallen),Bij het overdragen van patiëntstukken dient het veld verantwoordelijkezorgaanbieder te worden aangepast. Indien het patiëntdossier niet in staat isalle attributen te onderscheiden (legacy), dient het patiëntdossier dedesbetreffende attributen te negeren. Dit zal wel leiden tot onnodigegegevensuitwisseling.

• bij vermoede onjuistheden in de verwijsindex, dient het patiëntdossier al zijnvermeldingen in de verwijsindex bij te werken (synchroniseren). Dit speeltbijv. in de volgende gevallen:

o wanneer het patiëntdossier enige tijd niet beschikbaar is geweestvoor de verwijsindex,

o wanneer de verwijsindex enige tijd niet beschikbaar is geweest voorhet patiëntdossier.

Opmerkingen:

• De bovengenoemde generieke attributen van patiëntstukken zijn nog inonderzoek; idealiter zijn ze in lijn met prEN13606 en passen ze bovendienbinnen HL7v3. In de HL7 Berichtdefinities zal blijken dat dit nog niethelemaal mogelijk is.

• Merk op dat een patiëntstuk geen attribuut heeft, dat aangeeft dat hetpatiëntstuk een kopie is. Dit moet impliciet blijken uit de vermeldeverantwoordelijke zorgaanbieder. Bij het overdragen van een patiëntstuk uitdit dossier aan een ander dient de andere zorgaanbieder hier alsverantwoordelijke zorgaanbieder te worden vermeld.

• Het bovenstaande specificeert geenszins de wijze waarop een patiëntdossierintern gestructureerd moet zijn. Het specificeert slechts de wijze waarop depatiëntstukken naar buiten opgeleverd kunnen worden.


4.3.2 Schakelpunt

Het schakelpunt (SCH) wordt hier gedefinieerd als:

• een loket voor het opvragen van patiëntgegevens:o waar alle opvragen van patiëntgegevens door een zorgaanbieder-

applicatie of patiëntapplicatie kunnen worden geplaatst,o dat deze opvragen vervolgens doorschakelt naar de juiste

patiëntdossiers en/of andere schakelpunten,o dat alle resultaten van die patiëntdossiers en/of andere

schakelpunten ontvangt en doorschakelt naar de opvrager.

• een doorgeefluik voor het versturen van patiëntgegevens:o waar alle berichten door een zorgaanbiederapplicatie of patiënt-

applicatie kunnen worden gepost,o dat deze berichten vervolgens doorschakelt naar juiste postbussen

en/of andere schakelpunten.

Bij het opvragen van patiëntgegevens is het schakelpunt verantwoordelijk voor hetraadplegen van de verwijsindex, het doorschakelen van de opvraag naar alle daarinvermelde dossiers, het verzamelen van alle opgeleverde resultaten en hetterugsluizen daarvan naar de opvrager. De onderstaande figuur toont dat éénopvraag kan leiden tot zeer vele resultaten. In paragraaf 5.3.2 wordt uitgewerkthoe de uitwisseling van patiëntgegevens kan worden gerealiseerd met behulp vanHL7v3-berichtenverkeer en welke opties van bundelen, groeperen, doseren ensorteren door het schakelpunt moeten worden ondersteund, zie ook Bijlage C.

opvraagApplicatie

:Zorgverlener

Schakelpunt Applicatie2

Applicatie1

Applicatie3

opvraag2

resultaat22

resultaat21

resultaat23

opvraag3

resultaat32

resultaat31

resultaat33

opvraag1

resultaat12

resultaat11

resultaat13

Dossier2

Dossier1

Dossier3

resultaat12

resultaat11

resultaat13

resultaat22

resultaat21

resultaat23

resultaat32

resultaat31

resultaat33

Wanneer de verwijsindex inconsistent raakt, kan het gebeuren dat het schakelpunteen opvraag richt aan een dossier, maar het dossier vervolgens geen resultatenkan opleveren. Om dergelijke gevallen bij te houden voor de schakelpuntbeheerder,kan het schakelpunt deze fouten zelf loggen of doorgeven aan de verwijsindex. De


laatste optie verdient de voorkeur. Voor de zorgaanbiedergids geldt een analogeredenering.

Bij het versturen van patiëntgegevens is het schakelpunt verantwoordelijk voor hetafleveren van opdrachten en meldingen in de juiste zorgaanbiederpostbus naraadplegen van een adrestabel. In paragraaf 5.3.3 wordt uitgewerkt hoe dezeuitwisseling van patiëntgegevens kan worden gerealiseerd met behulp van HL7v3-berichtenverkeer en welke opties door het schakelpunt moeten wordenondersteund: het eventueel bevestigen van het resultaat en het moment waarop :onmiddellijk of mettertijd? In het eerste geval zal het niet beschikbaar zijn van depostbus onmiddellijk leiden tot een bevestiging dat de aflevering mislukt is (instantmessaging mechanisme). In het tweede geval heeft het schakelpunt de tijd om hetnog eens te proberen als de postbus weer beschikbaar is (store & forward-mechanisme).

opdracht

terugmeldingApplicatie1

:Zorgverlener

Schakelpunt Applicatie2

opdracht

terugmeldingPostbus

In bijlage D wordt uitgelegd dat het schakelpunt niet zozeer de dossiers enpostbussen moet adresseren, maar de applicaties die deze dossiers en postbussenontsluiten, wegens de werkwijze van HL7v3.

Uit oogpunt van doelmatigheid moet het schakelpunt alle in de verwijsindexgenoemde applicaties bevragen, behalve de opvragende applicatie. Anders zou hetschakelpunt onnodig patiëntgegevens gaan rondpompen. Er zijn omstandighedendenkbaar van complexe applicaties waarvoor dit rondpompen toch wenselijk is. Inde toekomst kan die optie wellicht worden geboden.

Uit oogpunt van doelmatigheid moet het schakelpunt ten behoeve van één opvraagalle in de verwijsindex genoemde applicaties slechts één maal bevragen, ook alseen applicatie toevallig meerdere keren in de verwijsindex staat met de gevraagdepatiënt en gegevenssoort. Dit kan bijvoorbeeld gebeuren als verschillendespecialismen van één ziekenhuis vanuit dezelfde applicatie dezelfde gegevenssoorthebben aangemeld. Dubbele bevragingen zouden namelijk leiden tot dubbeleantwoorden.

Uit oogpunt van vertrouwelijkheid mag het schakelpunt geen patiëntgegevensopslaan langer dan nodig is om een opvraagsessie af te ronden of om eenpatiëntbericht af te leveren. Dit betekent dat buffers met patiëntgegevens nagebruik telkens moeten worden gewist of anderszins beschermd tegen abusievelijkuitlekken. Denk daarbij aan het afdanken van computers met achtergeblevengegevens, nieuwsgierige beheerders, etc.

Uit oogpunt van integriteit mag het schakelpunt geen berichten wijzigen, filteren ofinzien anders dan nodig voor het afleveren op de juiste bestemming.

Uit oogpunt van beschikbaarheid en schaalbaarheid zijn meerdere schakelpuntenmogelijk, al dan niet regionaal verspreid. Dit is alleen beheersbaar als deschakelpunten landelijk door één partij worden beheerd.



[B33] Er komt één landelijk schakelpunt, dat kan bestaan uit meerdere interneschakelpunten t.b.v. doelmatige opschaling van de capaciteit.

[B34] Het schakelpunt moet voorkomen dat buffers met patiëntgegevens na eenafgeronde of afgebroken gebruikersinteractie abusievelijk uitlekken.

[B35] Het schakelpunt mag niet het dossier van de opvragende applicatiebevragen, {toekomst} anders dan op uitdrukkelijk verzoek van deopvragende applicatie.

[B36] Het schakelpunt moet ten behoeve van één opvraag alle in de verwijsindexgenoemde applicaties slechts éénmaal bevragen, ook als een applicatietoevallig meerdere keren in de verwijsindex staat met de gevraagdepatiënt en gegevenssoort.

[B37] Als gevolg van ontwerpbeslissing [B42] moet het schakelpunt fouteverwijzingen en foute adressen terugmelden aan de verwijsindex resp. dezorgaanbiedergids.

Het schakelpunt dient de volgende operaties te kunnen afhandelen:

• Een verzoek tot inloggen door een gebruiker via een applicatie dient teleiden tot:

o het raadplegen van de identificatie&authenticatie-module, om deidentiteit van de aanvrager te authenticeren,

o het opzetten van een sessie waarlangs gebruikersinteracties kunnenworden afgehandeld (zie beneden),

o het afbreken van de sessie na uitloggen van de gebruiker,o het afbreken van de sessie na de time-out na niet gebruiken van de

opgezette sessie,o het loggen van het opzetten en afbreken in de toegangslog.

• Een gebruikersinteractie van een ingelogde gebruiker via een applicatiedient te leiden tot:

o het raadplegen van het autorisatieprotocol om te controleren of degebruiker op grond van zijn functie, of die van diens mandaterendezorgverlener, de gebruikersinteractie mag uitvoeren op degegevensoort,

o het raadplegen van het autorisatieprofiel om te controleren of:§ de patiënt/cliënt ooit toestemming heeft gegeven voor

elektronische uitwisseling van patiëntgegevens,§ zo ja, of de gebruiker niet expliciet is uitgesloten voor de

gegevensklasse,o het omzeilen van de autorisatie indien de gebruiker een beroep heeft

gedaan op noodgeval,o het controleren of het bericht met de gebruikersinteractie afkomstig

is van de gebruiker die heeft ingelogd,o het uitvoeren van de gebruikersinteractie (zie beneden),o het loggen van de gebruikersinteractie in de toegangslog met een

indicatie van het succes van die gebruikersinteractie.


• Een opvraag van patiëntgegevens (via een applicatie of een anderschakelpunt) dient te leiden tot:

o het raadplegen van de verwijsindex om de relevante applicaties metpatiëntdossiers te bepalen,

o het controleren in de configuratietabel of de vermelde applicatiesdeze gebruikersinteractie kunnen verwerken,

o het doorschakelen van de opvraag naar de relevante applicaties,eventueel ook naar andere schakelpunten,

o het ontvangen en het doorschakelen van de opgeleverde resultatennaar de aanvrager,

o het doorgeven van eventuele foute verwijzingen aan de verwijsindex,o het doorgeven van eventuele foute adressen aan de

configuratietabel.

• Een aanmelding of afmelding van patiëntgegevens (via een applicatie of eenander schakelpunt) dient te leiden tot:

o het aanmaken of verwijderen van een verwijzing in/uit deverwijsindex,

o het doorgeven daarvan aan alle andere schakelpunten, behalve hetaanmeldende schakelpunt.

• {toekomst} Een verzoek tot synchronisatie (via een applicatie of een andereverwijsindex) dient te leiden tot:

o het verwijderen van alle verwijzingen uit de verwijsindex, voorzoverze op de aanmelder slaan,

o het opnieuw toevoegen van verwijzingen in de verwijsindex,o het doorgeven daarvan aan alle andere schakelpunten, behalve het

aanmeldende schakelpunt.

• Een opdracht (via een applicatie of een ander schakelpunt) dient te leidentot:

o het controleren in de configuratietabel of de vermelde applicatie dezeHL7-interactie kan verwerken

o het doorschakelen van de opdracht naar de juiste applicatie metzorgaanbiederpostbus, eventueel via andere schakelpunten,

o het doorgeven van eventuele foute adressen aan deconfiguratietabel,

o het ontvangen en het doorschakelen van de bevestiging aan deopdrachtgever.


4.3.3 Verwijsindex

De verwijsindex (VWI) wordt hier gedefinieerd als een tabel met verwijzingen naarpatiëntdossiers waar patiëntgegevens met bepaalde kenmerken/attributenbeschikbaar zijn voor opvraag. Doel van de verwijsindex is het doelmatig uitvragenvan alleen díe dossiers die de gevraagde gegevens bevatten, zie paragraaf 3.6.2.

Om überhaupt te kunnen functioneren, zijn de volgende kolommen noodzakelijk inde verwijsindex:

• patiënt-id,• dossier-id.

In plaats van het dossier-id zal in de praktijk de applicatie-id worden gebruikt vande applicatie die het desbetreffende dossier ontsluit, zie bijlage D. In geval vanmeerdere schakelpunten die ieder een eigen verwijsindex onderhouden, kan deapplicatie-id van een ander schakelpunt worden gebruikt.

Uit oogpunt van doelmatigheid is het belangrijk de onderstaande attributen op tenemen in de verwijsindex. Dan kan een opvraagverzoek op basis van de zoek-criteria gericht worden doorgezet en wordt onnodig berichtenverkeer voorkomen:

• zorgverlener-functie,• zorgverlener-id,• zorginstelling-id.• actualiteit,• gegevenssoort.

De actualiteit kan naar keuze met een resolutie van een jaar, een maand, een dag,een uur, etc. worden bijgehouden. Een te scherpe resolutie zal er toe leiden dat ermeer heraanmeldingen bij de verwijsindex worden gedaan dan er opvragingenbespaard worden. Waar de balans precies zit is moeilijk te voorspellen en kanbovendien verschillen per gegevenssoort. Daarom is het verstandig deze resolutieals instelbare parameter eerst op één jaar te zetten en deze te verscherpenwanneer dat nodig blijkt.

Uit oogpunt van actualiteit van de verwijsindex zelf moet een nieuwe aanmeldingaan de verwijsindex snel worden gedaan. Bijv. om te voorkomen dat een apothekeraan de verwijsindex niet kan zien, dat de huisarts een half uur eerder voor eenpatiënt/cliënt voor het eerst de allergieën heeft aangemeld, wordt voorgesteld voornieuwe aanmeldingen 1 kwartier aan te houden.

Uit oogpunt van beheerbaarheid is het belangrijk de onderstaande attributen op tenemen in de verwijsindex. Dan kan onder meer bij het afmelden de juisteverwijzing worden gevonden:

• patiëntgegevens-id.

In geval van een atomaire aanmelding kan hier de identificatie van het aangemeldepatiëntstuk worden gebruikt, zie ook paragraaf 4.2.6 en 5.10.4. In geval van eencategorale aanmelding kan hier een willekeurige identificatie worden gebruikt,zolang de aanmeldende applicatie die identificatie onthoudt voor latereheraanmelding en eventuele afmelding.

Uit oogpunt van vertrouwelijkheid mag een verwijsindex buiten een zorginstellinggeen patiëntgegevens of verwijzingen daarnaar bevatten. Dit vergt aldus specialejuridische en organisatorische maatregelen om tenminste verwijzingen te kunnenopnemen.


Uit oogpunt van integriteit moet de verwijsindex worden teruggemeld indien deverwijzingen niets hebben opgeleverd. Op basis van foutentellers kunnenschakelpuntbeheerders bepalen of een verantwoordelijke zorgaanbieder moetworden aangesproken op correct aan/afmelden en regelmatig synchroniseren.

Uit oogpunt van schaalbaarheid is het mogelijk dat verscheidene schakelpuntenieder een eigen verwijsindex hebben. Daarbij is het de vraag of iedere verwijsindexmoet aangeven van welke patiënten/cliënten gegevens beschikbaar zijn via eenander schakelpunt of niet:

• Zo ja, dan zal iedere verwijsindex in de praktijk grotendeels gevuld zijn metverwijzingen naar andere verwijsindices. Nadeel is dat iedere aanmeldingaltijd naar alle andere verwijsindices moet worden gedivergeerd.

• Zo nee, dan zal iedere verwijsindex alleen verwijzingen binnen de regiobevatten. Nadeel is dat iedere opvraag altijd naar alle andere verwijsindicesmoet worden doorgestuurd. Voordeel is dat aanmeldingen juist binnen deregio blijven.

Het voorstel is te kiezen voor “ja”, omdat er naar verwachting meer opvragingendan aanmeldingen zullen zijn. Nog beter zou zijn, deze keuze aan deschakelpuntbeheerder te laten, zodat hij afhankelijk van het gegevensverkeer in depraktijk zijn verwijsindex kan optimaliseren.

Een variant van de hier beschreven verwijsindex is de zogenaamde Master PatiëntIndex (MPI). Dit is een verwijsindex waarin voor iedere verwijzing naar een lokaalpatiëntdossier, ook het interne patiëntnummer wordt vermeld. Hiervoor wordtnadrukkelijk niet gekozen, want:

• iedere zorgaanbieder is zelf verantwoordelijk voor de koppeling tussen zijnlokaal gebruikte patiëntnummer met een ander nummer. Een MPI zou dieverantwoordelijkheid op een centrale plek neerleggen.

• een MPI zou het probleem van de vele, verschillende patiëntnummers deelskunnen oplossen, maar zonder de waarborgen die het BSN wel biedt.


[B38] De verwijsindex zal bestaan uit een reeks verwijzingen die ieder bestaanuit:• patiënt-id (BSN)• applicatie-id• zorgverlener-id (UZI-nummer)• zorgverlener-functie• zorginstelling-id (abonneenummer in UZI-register)• gegevenssoort• patiëntgegevens-id• actualiteit, bestaande uit:

o begintijdo eindtijd

• foutenteller• {toekomst} status


[B39] Er wordt nadrukkelijk niet gekozen voor het mechanisme van eenzogenaamde Master Patiënt Index (MPI), waarbij de verwijsindex ook hetinterne patiëntnummer in dat dossier bevat.

[B40] Patiëntdossiers moeten een nieuwe verwijzing binnen 1 kwartieraanmelden aan de verwijsindex, en van iedere bestaande verwijzing deactualiteit met een resolutie van een dag bijwerken in de verwijsindex doorheraanmelden.

[B41] {toekomst} Als gevolg van ontwerpbeslissing [B14] zal de verwijsindexalle wijzigingen zodanig moeten loggen in de toegangslog, dat de inhoudvan de verwijsindex op een bepaald moment in het verledengereconstrueerd kan worden.

[B42] De verwijsindex zal het aantal mislukte opvragingen als gevolg van eenfoute verwijzing, moeten bijhouden in een foutenteller per verwijzing.

De verwijsindex dient de volgende operaties te kunnen afhandelen op verzoek vaneen schakelpunt:

• het opvragen van een verwijzing,• het toevoegen van een verwijzing,• het verwijderen van een verwijzing,• het ophogen van de foutenteller voor een mislukte verwijzing.

Opmerkingen:

• in de verwijsindex staat altijd de zorgverlener die verantwoordelijk is voorde medische handeling die resulteerde in de vastlegging van depatiëntgegevens. Als een gemandateerde medewerker bepaaldepatiëntgegevens aanmeldt, moet hier de mandaterende zorgverlener wordenvermeld. Als een zorgaanbieder een heel dossier overneemt van een anderezorgaanbieder, zal de applicatie-id veranderen, maar blijft deverantwoordelijke zorgverlener ongewijzigd.

• in de verwijsindex kan eventueel in de toekomst ook de zorgverlener dieverantwoordelijk is voor de aanmelding worden vermeld.

• met de keuze van het UZI-nummer als zorgverlener-id, is het noodzakelijkom ook diens functie en zorginstelling te vermelden, want een zorgverlenerdie meerdere functies uitoefent, al of niet in meerdere zorginstellingen,krijgt weliswaar meerdere UZI-passen, maar altijd met hetzelfde UZI-nummer.

• Per zorgtoepassing moet bepaald worden in hoeverre alle attributen in deverwijsindex verplicht moeten worden ingevuld bij de aanmelding. Pergegevenssoort moet bepaald worden of de patiëntgegevens categoraal ofatomair moeten worden aangemeld.


4.3.4 Gegevenssoortentabel

De gegevenssoortentabel vertelt het schakelpunt welke gegevenssoorten inaanmerking komen voor iedere soort opvraag. Deze tabel is nodig omdat op basisvan een bepaalde HL7-interactie-id niet automatisch kan worden afgeleid welkeaanmeldbare gegevenssoort wordt opgevraagd. De oorzaak daarvan ligt in het feitdat patiëntstukken en hun gegevenssoorten niet allemaal hetzelfde aggregatie-niveau hebben, zie ook paragraaf 4.3.1.

Bijvoorbeeld, als een huisarts een eerstelijnsdossier als gegevenssoort aanmeldt bijde verwijsindex, komt dit dossier in principe in aanmerking voor opvraag van devolgende gegevenssoorten:

• professionele samenvatting voor DWH,• professionele samenvatting voor SEH,• medicatievoorschriften.

Gewoonlijk is is er een eenvoudige 1-op-1 relatie. Bijvoorbeeld, als een apotheekmedicatieverstrekkingen aanmeldt bij de verwijsindex, komt diens dossier alleen inaanmerking voor opvraag van medicatieverstrekkingen.

De gegevenssoortentabel zal bestaan uit een lijst met regels die ieder bevatten:• een gegevenssoort-id als aanmeldbare gegevenssoort,• een HL7-interaction-id als opleverbare gegevenssoort.

Daarin kan iedere HL7-interactie en iedere gegevenssoort meer malen voorkomen.Op deze wijze kan één HL7-interactie gebonden worden aan meerdere opleverbaregegevenssoorten en andersom.

De onderstaande figuur geeft een voorbeeld (met suggestieve tekst in plaats vanonbegrijpelijke codes) van deze tabel voor de zorgtoepassingen EMD en WDH.

Gegevenssoort HL7-interactionIndex opvragenIndexMedicatievoorschrift opvragenMedicatievooschriftenMedicatieverstrekking opvragenMedicatieverstrekkingenEerstelijnsdossier opvragenSamenvattingVoorDWHEerstelijnsdossier opvragenSamenvattingVoorSEH


4.3.5 Autorisatieprotocol

Het autorisatieprotocol is een door koepelverenigingen gedefinieerdeautorisatietabel die bepaalt welke soorten patiëntgegevens voor welke functies vanzorgaanbieders toegankelijk zijn. Het autorisatieprotocol is bedoeld voor gebruikdoor het schakelpunt, maar kunnen eventueel ook door zorginstellingen wordengebruikt voor de interne autorisatie of voor inzage door zorgverleners.

Uit oogpunt van vertrouwelijkheid zijn er geen beperkingen: iedereen mag hetautorisatieprotocol inzien en vrij kopiëren.

Uit oogpunt van integriteit is het belangrijk te kunnen achterhalen wie hetautorisatieprotocol heeft aangepast, bijv. door middel van een autorisatielog.

Uit oogpunt van beheerbaarheid is het wenselijk het autorisatieprotocol centraal teonderhouden.


[B43] Er komt één centraal beheerd autorisatieprotocol t.b.v. landelijkeuitwisseling van patiëntgegevens via het schakelpunt.

[B44] {toekomst} Zorginstellingen kunnen een lokale kopie van ditautorisatieprotocol maken t.b.v. inzage of autorisatie van de interneuitwisseling van patiëntgegevens.

[B45] {toekomst} Als gevolg van ontwerpbeslissing [B14] zal hetautorisatieprotocol de historie van wijzigingen moeten bijhouden tot aan deafgesproken reconstructiehorizon.

Het autorisatieprotocol zal bestaan uit:

• een algemeen autorisatieprotocol, dat bestaat uit een aantalautorisatieregels met:

o opvragende zorgpartijo opleverende zorgpartijo de gegevensklasseo de bevoegde algemene gebruikersinteractie, zie paragraaf 5.3.1o autorisatieniveau: voorlopig alleen de indicatie wél of géén toegango vereiste logging: wel, nieto vereiste vertrouwensniveau: laag, midden, hoogo ingangsdatum van wijzigingo identiteit van de beheerder die de regel heeft vastgelegd

behalve voor de combinatie zorgaanbieder/zorgaanbieder/medisch, wantdaarvoor geldt het medische autorisatieprotocol.

• een medisch autorisatieprotocol, dat bestaat uit een aantal autorisatieregelsmet:

o de functie van de opvragende zorgverlenero de betrokkenheid van de opvragende zorgverlenero de bevoegde medische gebruikersinteractie, zie paragraaf 5.3.1o autorisatieniveau: voorlopig alleen de indicatie wél of géén toegango vereiste vertrouwensniveau: laag, midden, hoogo ingangsdatum van wijziging


o identiteit van de beheerder die de regel heeft vastgelegd

• een autorisatielog bestaande uit alle historische wijzigingen met telkens:o datum en tijd dat de wijziging is doorgevoerdo identiteit van de beheerder of {toekomst} patiënt/cliënt die de

wijziging heeft doorgevoerd.

Autorisatieregels die worden overschreven door een nieuwe autorisatieregel, zijndaarna alleen nog interessant voor auditdoeleinden en de reconstructie van eenhistorische opvraag door de toezichthouder. Aldus kunnen overschrevenautorisatieregels worden opgeborgen in een autorisatielog, die kan wordengearchiveerd naar een off-line opslagmedium.


4.3.6 Autorisatieprofiel

Het autorisatieprofiel bestaat uit een groot aantal individuele profielen, één vooriedere patiënt/cliënt die ooit heeft aangegeven al of niet akkoord te gaan metelektronische uitwisseling van zijn patiëntgegevens.

Uit oogpunt van vertrouwelijkheid mogen zorgverleners geen autorisatieprofieleninzien. Immers, als een patiënt/cliënt zijn buurman wil uitsluiten, die toevallig alsapotheker in een ziekenhuis werkt, mag die apotheker niet in dat autorisatieprofielkunnen zien dat hij is uitgesloten door zijn buurman.

Uit oogpunt van integriteit is het belangrijk te kunnen achterhalen wie deautorisatieprofielen heeft aangepast, bijv. door middel van een autorisatielog.

Uit oogpunt van schaalbaarheid zijn kopieën van alle (potentieel 16 miljoen)autorisatieprofielen lastig te distribueren over de vele zorginstellingen. Het zou ookniet doelmatig zijn, als men bedenkt dat een patiënt/cliënt slechts enkelezorginstellingen bezoekt. In het genoemde voorbeeld m.b.t vertrouwelijkheid, kande patiënt/cliënt beter kiezen om dat ziekenhuis te vermijden óf dat ziekenhuis tevragen een intern autorisatieprofiel in te stellen t.b.v. hun interne uitwisseling vanpatiëntgegevens.

Uit oogpunt van beheerbaarheid is het wenselijk de centrale autorisatieprofielen telaten onderhouden door een autorisatiebeheerder, die op verzoek vanpatiënten/cliënten aanpassingen doorvoert. In de toekomst is aanpassing door depatiënt/cliënt zelf via Internet mogelijk.

Uit oogpunt van actualiteit kan een aanpassing van een centraal of lokaalautorisatieprofiel onmiddellijk ingaan. Frequente wijzigingen worden pas verwachtals de patiënt/cliënt zelf toegang via Internet krijgt.


[B46] Er komt per patiënt één centraal beheerd autorisatieprofiel t.b.v. landelijkeuitwisseling van patiëntgegevens via het schakelpunt.

[B47] Zorginstellingen kunnen per patiënt een eigen, intern autorisatieprofielonderhouden t.b.v. interne uitwisseling van patiëntgegevens.

[B48] {toekomst} Als gevolg van ontwerpbeslissing [B14] zal hetautorisatieprofiel de historie van wijzigingen moeten bijhouden tot aan deafgesproken reconstructiehorizon.

Een centraal autorisatieprofiel van een patiënt/cliënt bestaat uit:

• een akkoordprofiel met afzonderlijke indicaties van de patiënt/cliënt of hijwel/niet akkoord gaat met:

o elektronische uitwisseling van zijn patiëntgegevens,o {toekomst} elektronisch inkijken in de toegangslog door hemzelf,o {toekomst} elektronisch inkijken in zijn autorisatieprofiel door

hemzelf,o {toekomst} elektronisch wijzigen van zijn autorisatieprofiel door

hemzelf,met voor iedere indicatie


o {toekomst} vereiste vertrouwensniveau

• nul of meer autorisatieregels, die ieder bestaan uit:o opvragende zorgpartij, eventueel uitgedrukt in functie of identiteito de gegevensklasse,o een indicatie met de waarde:

§ altijd§ alleen in noodsituatie§ na expliciete toestemming§ nooit

o eventueel de persoon van wie de expliciete toestemming wordtverlangd

o vereiste vertrouwensniveau

• een autorisatielog bestaande uit alle historische wijzigingen met telkens:o datum en tijd dat de wijziging is doorgevoerdo identiteit van de beheerder of {toekomst} patiënt/cliënt die de

wijziging heeft doorgevoerd.

Naast alle patiënt/cliënt-specifieke autorisatieprofielen is er een generieke tabelmet verstekwaarden voor de akkoordprofielen. Voor autorisatieregels zijn geenverstekwaarden nodig, want nul autorisatieregels betekent op grond van [B20]:géén inperking van de bevoegdheden zoals bepaald in het autorisatieprotocol.

Een intern autorisatieprofiel van een patiënt/cliënt bestaat slechts uit nul of meerautorisatieregels zoals hierboven beschreven.


4.3.7 Identificatie & authenticatie-module

De identificatie & authenticatie-module (I&A) wordt hier gedefinieerd als de eenheiddie ten behoeve van het schakelpunt:

• zorgverleners en {toekomst} patiënten/cliënten identificeert enauthenticeert aan de hand van hun persoonsgebonden vertrouwensmiddelwanneer zij inloggen op het schakelpunt,

• patiëntdossiers en zorgaanbiederpostbussen identificeert en authenticeertaan de hand van hun systeemgebonden vertrouwensmiddel wanneer zijworden aangesproken door het schakelpunt,

• zichzelf identificeert en authenticeert bij inloggende zorgverleners en{toekomst} patiënten/cliënten en aangesproken patiëntdossiers enzorgaanbiederpostbussen.

Gegeven de keuze voor PKIO, zie paragraaf 5.6, zal de identificatie & authenticatie-module ook zelf een systeemgebonden vertrouwensmiddel bevatten.

Uit oogpunt van authenticiteit van het schakelpunt, dient het vertrouwensmiddelfysiek te zijn beschermd tegen kopiëren of ongeautoriseerd verwijderen.

Uit oogpunt van schaalbaarheid kan ieder schakelpunt zijn eigen identificatie &authenticatie-module hebben, maar kunnen schakelpunten ook een gezamenlijkemodule hebben.

Uit oogpunt van actualiteit is het noodzakelijk dat deze module geregeld de lijstmet ingetrokken vertrouwensmiddelen ophaalt van de CA van hetzorgverlenerregister.

De identificatie & authenticatie-module dient de volgende operaties te kunnenafhandelen op verzoek van een schakelpunt:

• het identificeren en authenticeren van zorgverleners en {toekomst}patiënten/cliënten, patiëntdossiers en zorgaanbiederpostbussen op basis vanhun vertrouwensmiddelen,

• het opzetten van beveiligde sessies met de applicaties die dezezorgverleners en {toekomst} patiënten/cliënten gebruiken of de applicatiesdie deze patiëntdossiers en zorgaanbiederpostbussen ontsluiten.


4.3.8 Toegangslog

De toegangslog dient om de toezichthouder, zorgaanbieders en patiënten/cliëntente kunnen laten achterhalen welke patiëntgegevens ooit landelijk (en eventueelintramuraal) zijn uitgewisseld, zie paragraaf 4.2.14.

Ten behoeve van de toezichthouder, die een bewijs wil kunnen vinden dat eenzorgaanbieder bepaalde patiëntgegevens heeft ingezien, zou er een centraalbeheerde log moeten zijn, waarin alle landelijk uitgewisselde patiëntgegevensinhoudelijk worden gelogd. Maar daarmee zou een nieuwe, centrale vastlegging vanpatiëntgegevens ontstaan, hetgeen niet beantwoordt aan het doel van detoegangslog. Daarom moet een centrale log alleen de metagegevens (waaronder deuitgevoerde gebruikersinteractie) bevatten, onder verwijzing naar de plaats waarde inhoud gelogd is, of anderszins terug te vinden is.

Ten behoeve van de verantwoordelijke zorgaanbieder, die moet kunnen achterhalenwie zijn patiëntdossiers heeft ingezien, moet er toch al een lokale log wordenbijgehouden. Deze lokale log hoeft de (berichten met) uitgewisselde patiëntstukkenniet per sé inhoudelijk te bevatten, indien de afkomstige zorgapplicatie diepatiëntstukken kan reconstrueren als gevolg van ontwerpbeslissing [B14], of indienhet afkomstige patiëntdossier alle afzonderlijke versies van patiëntstukken bewaartals gevolg van ontwerpbeslissing [B32].

Ten behoeve van de toezichthouder, die wil kunnen achterhalen wat eenzorgaanbieder precies heeft gezien na het opvragen van een index van beschikbaregegevenssoorten, zouden de ontvangen indexregels inhoudelijk moeten wordengelogd. In plaats daarvan kan de inhoud van de verwijsindex op een bepaaldtijdstip ook worden gereconstrueerd. Als gevolg van ontwerpbeslissing [B14] moetdit toch al, dus verdient deze variant de voorkeur. Dat betekent wel dat alleinteracties van een zorgaanbieder met het schakelpunt centraal moeten wordengelogd.

Uit oogpunt van vertrouwelijkheid vindt de eventuele inhoudelijke logging plaats bijhet patiëntdossier waaruit de uitgewisselde patiëntstukken afkomstig zijn. In gevalvan gebruikersinteractie versturen is dat die van de agerende partij, in geval vanopvragen is dat de reagerende partij. Op deze wijze wordt onbedoelde proliferatievan patiëntstukken voorkomen.

Uit oogpunt van integriteit is het belangrijk dat oude logregels leesbaar blijven, ookals de daarin gebruikte codes en identiteiten zijn vervallen. Dit vereist dat dedesbetreffende codetabellen en registers de vervallen codes en identiteiten kanreconstrueren of dat de codes in de logregel worden vervangen.

Uit oogpunt van beheerbaarheid is het wenselijk de centrale toegangslog te latenbeheren door een logbeheerder, die op verzoek van patiënten/cliënten detoegangslog doorzoekt.

Uit oogpunt van schaalbaarheid is het wenselijk dat patiënten/cliënten zelf detoegangslog doorzoeken. In de toekomst wordt dit via Internet mogelijk.


[B49] De toegangslog zal alle gebruikersinteracties loggen:• {toekomst} aansluiten en afsluiten van een applicatie,


• inloggen en uitloggen van gebruiker,• opvragen, versturen van patiëntgegevens,• opvragen index van gegevenssoorten,• aanmelden en afmelden van gegevenssoorten.

[B50] {toekomst} De eventuele inhoudelijke logging vindt plaats bij de bron: hetpatiëntdossier waaruit de uitgewisselde patiëntstukken afkomstig zijn.

[B51] De toegangslog zal omvatten:

• een centrale log bij ieder schakelpunt, met daarin alle uitgevoerdegebruikersinteracties, met verwijzingen naar de zorgaanbiedervan wie ze afkomstig zijn en het patiëntdossier waaruit zeafkomstig zijn.

• een lokale log bij ieder (applicatie met) patiëntdossier, met daarinalle gebruikersinteracties waarbij dit patiëntdossier als bron vande patiëntgegevens fungeerde.

De toegangslog wordt dus een virtuele log. De onderstaande figuur toont dit, in eenUML class diagram, waarbij de logregels zijn uitgewerkt voor de interacties indirectopvragen en indirect versturen van patiëntgegevens.

Patiëntstuk

Patiëntdossier

*

Lokalelog

Centralelogregel

Centralelog

Virtueletoegangs

log

verwijst naar >

hoort bij >

**

*

Virtuelepatiëntdossier

Schakelpunt

< hoort bij

*

Gebruikersinteractie

verwerktv

< verwijst naar Centralelogregel

Lokalelogregel


verwijst naarv

1 11..X 1..X

Doorgeschak.antwoordbericht

Origineelantwoord

bericht

Doorgeschak.verzoekbericht

Origineelverzoekbericht

verwijst als reagerendeapplicatie naarv

1 1 1 1

verwijst als agerendeapplicatie naar

v

0..1

bevatv

bevatv

bevatv

[indien opdracht]bevat >

[indien oplevering]< bevat

is kopie van, of uittreksel uit >

1 1 1 1

0..Y

Verzoek(opvraag ofopdracht)

Antwoord(oplevering ofbevestiging)

Patiëntstuk

Bundelantwoordberichten

Enkelantwoord

bericht

bevatv1..X

< bevat

leidt tot > leidt tot > 11

Het diagram is gebaseerd op de UML class diagrammen in paragraaf 5.3.2 enparagraaf 5.3.3. De aldaar genoemde bericht-id’s, opvraag-id’s, patiëntstuk-id’s engebeurtenis-id’s kunnen in de toegangslog worden gebruikt om de relaties vast teleggen tussen:

• de initiërende gebruikersinteractie (gebeurtenis-id),• de eventueel daaruit voortkomende opvraagsessie (opvraag-id),• de uitgewisselde patiëntstukken (patiëntstuk-id),• de berichten waarin die patiëntstukken zijn uitgewisseld (bericht-id).

Merk verder op dat:• het schakelpunt alle berichten van iedere gebruikersinteractie logt,• een (applicatie met) patiëntdossier in principe alleen de berichten logt van:

o de interactie indirect opvragen als reagerende (opleverende)applicatie,

o de interactie indirect versturen als agerende (versturende) applicatie.

Een centrale toegangslog zal aldus bestaan uit een reeks logregels, met voor iederelogregel de volgende attributen:

• het tijdstip: jaar, maand, dag, uur, minuut, seconde, milliseconde,• het type en het volgnummer van de uitgevoerde gebruikersinteractie,• indicatie van een eventueel opgetreden foutsituatie m.b.t. het schakelpunt,• in geval van aansluiten, afsluiten, inloggen of uitloggen:

o het vertrouwensniveau: hoog, midden, laag,o in geval van vertrouwensniveau laag:

§ de identiteit van de inloggende zorgaanbieder,§ een referentie naar het gebruikte UZI-servicescertificaat,

o in geval van vertrouwensniveau midden:§ de functie en identiteit van de inloggende zorgverlener of

medewerker,§ een referentie naar het certificaat van de gebruikte UZI-pas,

o het resultaat van de authenticatiecontrole,• in geval van aanmelden, afmelden, opvragen of versturen:

o de identiteit van de patiënt/cliënt,


o de identiteit van de agerende zorgaanbieder,o de functie en identiteit van de agerende zorgverlener of medewerker,o indien van toepassing: de functie en identiteit van de mandaterende

zorgverlener,o de identiteit van de agerende applicatie,o de gebruikersinteractie,o het resultaat van de autorisatiecontrole,o de reden waarom deze gebruikersinteractie is uitgevoerd,o een indicatie of een beroep was gedaan op een noodsituatie,

• in geval van opvragen index:o de bericht-id van het opleverbericht, ,o het aantal retries dat nodig was voor het terugsturen van het

opleverbericht, zie paragraaf 5.10,o een indicatie van een eventueel opgetreden foutsituatie m.b.t. het

terugsturen van het opleverbericht,• in geval van opvragen patiëntgegevens,

o de bericht-id van het originele opvraagbericht,o in geval van een bundel: de bericht-id van de bundel van

geconvergeerde opleverberichten,o het aantal retries dat nodig was voor het verzenden van het

geconvergeerde opleverbericht, zie paragraaf 5.10,o een indicatie van een eventueel opgetreden foutsituatie m.b.t. het

convergeren van het opleverbericht,met daarnaast per reagerende (opleverende) applicatie:

o de identiteit van de reagerende zorgaanbieder,o de functie en eventueel identiteit van de verantwoordelijke

zorgverlener,o de identiteit van de reagerende applicatie, die diens dossiers ontsluit,o de bericht-id van het gedivergeerde opvraagbericht,o indicatie van een eventueel opgetreden foutsituatie m.b.t. het

divergeren van het opvraagbericht,o de bericht-id van het originele opleverbericht,o de bericht-id van het geconvergeerde opleverbericht,

• in geval van versturen patiëntgegevens:o de bericht-id van het opdrachtbericht,o de identiteit van de reagerende (bestemde) zorgaanbieder,o de functie en eventueel identiteit van de bestemde zorgverlener,o de identiteit van de reagerende applicatie, die diens postbus ontsluit,o een indicatie van een eventueel opgetreden foutsituatie m.b.t. het

doorsturen van het opdrachtbericht,o de bericht-id van bevestigbericht,o het aantal retries dat nodig was voor het doorsturen van het

bevestigbericht, zie paragraaf 5.10,o een indicatie van een eventueel opgetreden foutsituatie m.b.t. het

doorsturen van het bevestigbericht.

Een lokale toegangslog zal bestaan uit een reeks logregels, met voor iederelogregel de volgende attributen:

• de identiteit van de patiënt/cliënt,• indien van toepassing: de functie en identiteit van de mandaterende

zorgverlener,• het tijdstip: jaar, maand, dag, uur, minuut, seconde, milliseconde,


• het type en het volgnummer van de uitgevoerde gebruikersinteractie(tenminste opvragen en versturen patiëntgegevens vanuit het bijbehorendepatiëntdossier),

• indicatie van een eventueel opgetreden foutsituatie mbt het schakelpunt,• in geval van opvragen patiëntgegevens:

o de identiteit van de agerende (opvragende) zorgaanbieder,o de functie en identiteit van de agerende zorgverlener of medewerker,o de bericht-id van het gedivergeerde opvraagbericht,o de bericht-id van het originele opleverbericht,o indicatie van een eventueel opgetreden foutsituatie m.b.t. het

terugsturen van het opleverbericht,o de patiëntstuk-id’s van in het opleverbericht aanwezige

patiëntstukken,• in geval van versturen patiëntgegevens:

o de identiteit van de reagerende (bestemde) zorgaanbieder,o de functie en identiteit van de reagerende zorgverlener, indien

vermeld,o de identiteit van de reagerende applicatie, die diens postbus ontsluit,o de bericht-id van het opdrachtbericht,o de patiëntstuk-id van in het opdrachtbericht aanwezige patiëntstuk,o een indicatie van een eventueel opgetreden foutsituatie m.b.t. het

versturen van het opdrachtbericht,o de bericht-id van het bevestigbericht.

Indien het lokale patiëntdossier niet in staat is de historisch opgeleverdepatiëntstukken te reconstrueren, bestaat de toegangslog ook uit logbestand metalle opgeleverde of verstuurde patiëntstukken met hun patiëntstuk-id.

Opmerkingen:

• In theorie is een lokale toegangslog niet noodzakelijk. Zorgverleners zoudennamelijk rechtstreeks kunnen inkijken in hun deel van de centraletoegangslog. Er moeten dan nog wel HL7v3-berichten worden gedefinieerdvoor het uitwisselen van logregels. Ook zou de centrale toegangslog dan depatiëntstuk-id’s van de uitgewisselde patiëntstukken moeten bevatten.Voordeel van de huidige opzet is dat men niet geheel afhankelijk is van decentrale toegangslog, maar deze zonodig kan verifiëren met de lokaletoegangsloggen.

• De lokale toegangslog bij een bepaald patiëntdossier dient primair voor hetreconstrueren van welke patiëntstukken precies zijn ingezien door eenandere zorgaanbieder. Daarnaast mag een lokale toegangslog ook bijhoudenwelke andere gebruikersinteracties hebben plaatsgevonden m.b.t. datpatiëntdossier, zoals het aanmelden en afmelden van gegevenssoorten.Maar dat voegt inhoudelijk niets toe aan de centrale toegangslog, omdatdeze logregels niet naar afzonderlijke patiëntstukken verwijzen.

• Voor het loggen van de eventuele interne uitwisseling van patiëntgegevenskan een lokale log ook logregels bevatten met attributen zoalsgespecificeerd voor de centrale log.

• Een gedoseerde opvraag bestaat uit een eerste opvraag van N patiënt-stukken en een willekeurig aantal opvragingen voor de volgende N patiënt-


stukken. Hierbij wordt iedere (vervolg)opvraag als een afzonderlijk te loggengebruikersinteractie beschouwd.

• De toegangslog heeft geen betrekking op de autorisatietabellen en anderecentrale tabellen. Voor het loggen van beheeracties op die tabellen, ziealdaar.

Openstaande punten:

• De waarde van het lokaal loggen van de berichtinhoud bij de bron, zie[B50], staat nog ter discussie. Als het erom gaat te bepalen welkepatiëntgegevens een zorgverlener precies heeft gezien na opvraag, is ergeen garantie dat diens gebruikersapplicatie al die berichtinhoud ook heeftgetoond aan de zorgverlener. In plaats daarvan zou het loggen van descherminhoud (screen dumps) meer zekerheid geven, maar dat moet danniet bij de bron, maar bij de bestemming moeten gebeuren, hetgeen instrijd is met paragraaf 4.2.9 eis (k).


4.3.9 Mandateringstabel

In een mandateringstabel kan een zorgverlener vastleggen welke anderezorgverleners (als medebehandelaar) en/of medewerkers zijn gemandateerd omnamens hem landelijk patiëntgegevens uit te wisselen.

Uit oogpunt van integriteit mogen alleen zorgverleners hun eigen mandateringenvastleggen, raadplegen, wijzigen en verwijderen. Dit is belangrijk omdat demandaterende zorgverlener verantwoordelijk blijft voor de handelingen van de doorhem gemandateerde medebehandelaren en medewerkers.

Uit oogpunt van vertrouwelijkheid mogen alleen gemandateerde medebehandelarenen medewerkers inzage krijgen in de aan hen toegekende mandateringen. Zijhebben deze inzage nodig alvorens de aan hen gemandateerde bevoegdheden tekunnen uitoefenen.

{toekomst} Uit oogpunt van doeltreffendheid is er idealiter één centralemandateringstabel, zodat het schakelpunt zelfstandig kan verifiëren of eenmedebehandelaar of medewerker gemandateerd is voor landelijke uitwisseling vanpatiëntgegevens.

Uit oogpunt van beheerbaarheid heeft iedere zorgverlener zijn eigenmandateringstabel binnen handbereik. Dit wringt met de doeltreffendheid, maarvoorlopig wordt gekozen voor een lokale tabel, want een centrale tabel zou nieuweHL7v3-berichten vergen voor de uitwisseling van mandateringen tussen lokalezorgapplicatie en het centrale schakelpunt.


[B52] Er komt een lokale mandateringstabel voor iedere zorgverlener die alshoofdbehandelaar kan optreden.

[B53] {toekomst} Als gevolg van ontwerpbeslissing [B14] zal demandateringstabel de historie van wijzigingen moeten bijhouden tot aan deafgesproken reconstructiehorizon.

De mandateringstabel bestaat uit een aantal mandateringsregels met ieder:• de identiteit van de mandaterende zorgverlener,• de identiteit van de gemandateerde zorgverlener of medewerker,• de bevoegde medische gebruikersinteractie(s), zie paragraaf 5.3.1• een ingangsdatum,• eventueel een verloopdatum.


4.3.10 Patiëntenregister

Het patiëntenregister is een tabel met identificerende gegevens van (potentiële)patiënten/cliënten.

Uit oogpunt van vertrouwelijkheid mag het patiëntenregister geraadpleegd wordendoor alle zorgaanbieders en medewerkers voor het opvragen of verifiëren van eenpatiëntnummer, maar niet voor het opvragen van de bijbehorende identificerendegegevens, zie paragraaf 4.2.3.

Uit oogpunt van doeltreffendheid is er idealiter één landelijk patiëntenregister, waaralle potentiële patiënten/cliënten in te vinden zijn met een landelijk patiëntnummer.In plaats daarvan zou men ook meerdere (bijv. regionale) patiëntenregisterskunnen opzetten, maar groot risico daarvan is dat een patiënt/cliënt niet kanworden gevonden, omdat hij in een ander register staat, en dus een tweedepatiëntnummer krijgt toegewezen.

Uit oogpunt van beschikbaarheid is het wenselijk dat zorgaanbieders zelf depatiëntnummers met bijbehorende identificerende gegevens enbereikbaarheidsgegevens van zijn patiënten/cliënten opneemt in zijn patiëntdossierof een interne patiëntenindex, mocht de zorgaanbieder afzonderlijke dossiers perafdeling hebben.

Uit oogpunt van beheerbaarheid is het wenselijk dat zorgaanbieders wordeningelicht over eventuele wijzigingen van identificerende of bereikbaarheidsgegevensvan patiënten/cliënten.


[B54] Er is één landelijk patiëntenregister nodig waar landelijke patiëntnummerskunnen worden opgevraagd en geverifieerd voor tenminste alleNederlandse ingezetenen.

[B55] {toekomst} Als gevolg van ontwerpbeslissing [B14] zal het landelijkepatiëntenregister de historie van wijzigingen moeten bijhouden tot aan deafgesproken reconstructiehorizon.

Het landelijke patiëntenregister bestaat uit een tabel met tenminste:• landelijk patiëntnummer (BSN)• geboortenaam• voorvoegsels• voornamen• voorletters• geslacht• geboortedatum• geboorteplaats• geboorteland• postcode• huisnummer• gemeente van inschrijving


Een intern patiëntenregister, meestal patiëntenindex genoemd, al dan niet alsonderdeel van een patiëntdossier, bevat tenminste dezelfde attributen aangevuldmet de volgende vlaggen en attributen:

• vlag of het BSN is opgevraagd of geverifieerd en zo ja:o bron van het BSNo datum en tijd van de opvraag of verificatieo identificatie van de controlerende zorgverlener/medewerker

• vlag of het WID is gecontroleerd op gelijkenis met de patiënt/cliënt en zo ja:o resultaat van de controleo datum en tijd van de controleo identificatie van de controlerende zorgverlener/medewerker

• vlag of het WID is gecontroleerd op echtheidskenmerken en zo ja:o resultaat van de controleo datum en tijd van de controleo identificatie van de controlerende zorgverlener/medewerker

• vlag of de geldigheid van het WID is gecontroleerd en zo ja:o type WIDo nummer van het WIDo resultaat van de controleo datum en tijd van de controleo identificatie van de controlerende zorgverlener/medewerker

• vlag of de identificerende gegevens zijn bijgewerkt en zo ja:o datum en tijd van bijwerekeno identificatie van de gebruiker

• vlag of het patiëntdossier inhoudelijk is gecontroleerd met de patiënt/cliënten zo ja:

o resultaat van de controleo datum en tijd van de controleo identificatie van de controlerende zorgverlener/medewerkero zorgverlenernummer van de mandaterende zorgverlener, indien van

toepassingwaarbij de laatste vlag met attributen per dossier kan worden bijgehouden, mochtde zorgaanbieder afzonderlijke dossiers per afdeling hebben.

Het landelijke patiëntenregister dient de volgende operaties te kunnen afhandelenop verzoek van het schakelpunt:

• het zowel interactief als bestandgewijs opleveren of verifiëren van het BSNvan een patiënt/cliënt op basis van een zoekpad van identificerendegegevens.


4.3.11 Zorgaanbiederregister

Het zorgaanbiederregister is een tabel met identificerende gegevens vancertificaten van vertrouwensmiddelen uitgegeven aan zorgverleners, medewerkersen hun zorgsystemen. Ook publiceert het een lijst van ingetrokken vertrouwens-middelen.

Uit oogpunt van vertrouwelijkheid kan het register beperkt geraadpleegd wordendoor de geregistreerde zorgaanbieders, als toetsingsregister; er kan niet in wordengebladerd, zie paragraaf 4.2.4.

Uit oogpunt van doeltreffendheid is er idealiter één landelijk zorgaanbiederregister,maar in plaats daarvan zou men ook meerdere (bijv. regionale)zorgaanbiederregisters kunnen opzetten.

Uit oogpunt van integriteit is het zeer belangrijk te kunnen vertrouwen op dejuistheid van de gegevens in het register.

Uit oogpunt van beheerbaarheid is het wenselijk het zorgaanbiederregister centraalte onderhouden, maar lokale inschrijving bij een RA mogelijk te maken.

Uit oogpunt van actualiteit is het noodzakelijk om de lijst van ingetrokkenvertrouwensmiddelen (CRL) regelmatig te publiceren. Tevens moet het mogelijkzijn een vertrouwensmiddel rechtstreeks op geldigheid te laten controleren door hetregister (OCSP).


[B56] {toekomst} Als gevolg van ontwerpbeslissing [B14] zal hetzorgaanbiederregister de historie van wijzigingen moeten bijhouden tot aande afgesproken reconstructiehorizon.

[B57] Als gevolg van ontwerpbeslissing [B58] zal het zorgaanbiederregister allewijzigingen in identificerende gegevens spontaan moeten aanmelden bij dezorgaanbiedergids.

Het zorgaanbiederregister dient de volgende operaties te kunnen afhandelen opverzoek van de identificatie&authenticatiemodule:

• het opleveren van alle identificerende gegevens van een zorgverlener,medewerker of systeem voor een opgegeven zorgaanbiedernummer,

• het opleveren van een lijst met ingetrokken vertrouwensmiddelen (CRL),• het controleren van de geldigheid van de opgegeven vertrouwensmiddel

(OCSP),• het opleveren van (een certificaat met) de publieke sleutel van het

opgegeven type voor het opgegeven zorgaanbiedernummer.

Het zorgaanbiederregister dient de volgende operaties te kunnen afhandelen tenbehoeve van de zorgaanbiedergids:

• het spontaan aanmelden van wijzigingen in identificerende gegevens vanzorgverleners, medewerkers of systemen,

• het op verzoek opleveren van alle identificerende gegevens van eenzorgverlener, medewerker of systeem voor een opgegevenzorgaanbiedernummer,


Opmerkingen:

• Als zorgaanbiederregister heeft het ministerie van VWS reeds het UZI-register van CIBG aangewezen. Toch beoogt deze paragraaf alsnog eisen teformuleren voor een dergelijk zorgaanbiederregister, geredeneerd vanuit debehoefte van het landelijk uitwisselen van patiëntgegevens. Dit is belangrijkom te kunnen toetsen of het gerealiseerde UZI-register voorziet in debehoefte. Sommige zaken kunnen echter geheel aan CIBG worden gelaten,zie ook paragraaf 4.2.19.

• Vooral het schakelpunt heeft de lijst van ingetrokken vertrouwensmiddelen(CRL) nodig om de UZI-passen van zorgverleners die inloggen op hetschakelpunt te controleren op geldigheid. Zolang zorgaanbiederapplicatiesuitsluitend via het schakelpunt gegevens uitwisselen, hebben die applicatieszelf niks nodig van het zorgaanbiederregister, behalve als UZI-passen ookworden gebruikt voor het lokaal inloggen, zie paragraaf 5.6. Voor deverificatie van elektronische handtekeningen zullen applicaties straks wel hetzorgaanbiederregister moeten raadplegen, vermoedelijk is OCSP dandoelmatiger dan een CRL.


4.3.12 Zorgaanbiedergids

De zorgaanbiedergids is een tabel met bereikbaarheidsgegevens van alle zorg-aanbieders, zowel zorginstellingen als zorgverleners, die actief zijn (geweest).

Uit oogpunt van vertrouwelijkheid kan de zorgaanbiedergids geraadpleegd wordendoor alle zorgaanbieders die hun eigen gegevens hebben gepubliceerd. Ookpatiënten/cliënten zouden in de toekomst toegang kunnen krijgen, zie paragraaf4.2.4.

Uit oogpunt van integriteit wordt de zorgaanbiedergids eerst automatisch enonwijzigbaar gevuld vanuit het UZI-register, en kan pas daarna handmatig wordeningevuld door de zorgaanbieders zelf. De HL7-adressen die daarbij wordeningevuld, moeten worden getoetst op het bestaan ervan bij de GBZ-configuratietabel, zie paragraaf 4.3.13.

Uit oogpunt van schaalbaarheid is er idealiter één landelijk zorgaanbiedergids, maarin plaats daarvan kan men ook meerdere (bijv. regionale) zorgaanbiedergidsenopzetten.

Uit oogpunt van beschikbaarheid kunnen zorgaanbieders de bereikbaarheids-gegevens van collega’s waar ze veel mee samenwerken, overnemen in hun lokalezorgaanbiederadresboek.

Uit oogpunt van beheerbaarheid is het wenselijk dat zorgaanbieders zelf hun(frequent wijzigende) bereikbaarheidsgegevens onderhouden. Het automatischpropageren van aanpassingen is lastig.


[B58] Wenselijk is één landelijke zorgaanbiedergids die automatisch consistentwordt gehouden met het zorgaanbiederregister en de configuratietabellenvan het schakelpunt.

[B59] Het zorgaanbiederregister moet identificerende gegevens aanleveren aande zorgaanbiedergids.

[B60] De GBZ-configuratietabel moet HL7-adressen aanleveren aan dezorgaanbiedergids.

[B61] {toekomst} Als gevolg van ontwerpbeslissing [B14] zal dezorgaanbiedergids de historie van wijzigingen moeten bijhouden tot aan deafgesproken reconstructiehorizon.

De zorgaanbiedergids bestaat uit een groot aantal bereikbaarheidsprofielen, dieieder bestaan uit:

• zorgaanbiedernummer• zorgaanbieder-type of zorgverlener-functie• aangeboden zorgdiensten• nul of meer bereikbaarheidsregels, die ieder bestaan uit:

o adres, dit kan zijn een bezoekadres, fysiek postadres, elektronischpostadres (internet en HL7v3 applicatie-id) en telefoonnummer

o één of meer beschikbare diensten op dat adres


o één of meer openingstijden voor iedere dienst op dat adres

De zorgaanbiedergids dient de volgende operaties te kunnen afhandelen op verzoekvan het schakelpunt:

• het opleveren van identificerende gegevens van zorgaanbieders op basis vanwillekeurige zoekcriteria,

• het opleveren van het elektronische postadres van een zorgaanbieder opbasis van het opgegeven zorgaanbiedernummer.

Opmerkingen:

• De Zorgaanbiedergids lijkt dubbelop met het Zorgaanbiederregister, maar inhet register kan niet vrij gezocht worden en kunnen ook geen bereikbaar-heidsgegevens worden toegevoegd.

• Omdat de genoemde zorgaanbiedernummers uit het UZI-register komen, zaler onderscheid zijn tussen:

o abonneenummer voor een zorginstelling of individuele zorgverlener,o UZI-nummer voor een zorgverlener, medewerker of systeem.

Een zelfstandige huisarts heeft dus een abonneenummer voor zijn praktijken een UZI-nummer voor zichzelf.

• Wanneer een zorgverlener voor meerdere zorginstellingen werkt, krijgt hijweliswaar afzonderlijke UZI-passen, maar houdt hij éénzelfde UZI-nummer.Dit betekent dat het UZI-nummer alleen onvoldoende is om eenzorgverlener te selecteren.

• Het elektronische postadres kan zijn:o e-mailadres, conform RFC 821 en RFC 822,o application-id, conform HL7v3.


4.3.13 Configuratietabellen

De configuratietabellen zijn een verzameling tabellen die bijhouden hoe de ZIM issamengesteld uit verschillende schakelpunten en aangekoppelde beheerobjecten,en op welke manier GBZ’en met hun applicaties via welke DCN daarop zijnaangesloten. Ruwweg kan onderscheid gemaakt worden tussen:

• ZIM-configuratietabel, met daarin de kenmerken van de operationele, test-en uitwijk-ZIM,

• DCN-configuratietabel, met daarin de kenmerken van ieder aangeslotenDCN,

• GBZ-configuratietabel, met daarin de kenmerken van ieder aangeslotenGBZ.

De onderstaande figuur toont de relaties tussen alle beheerde objecten, in een UMLclass diagram.

Register

ZorgInformatieMakelaar

*

DataCommunicatie

Netwerk

*

GoedBeheerd

Zorgsysteem

*

Applicatie

Schakelpunt

Autorisatieprofiel

Toegangslogs

is gekoppeld aanv

is gekoppeld aanv

bestaat uit > *

^is gekoppeld aan

*

*

Autorisatieprotocol

bestaatuit >

1

Verwijsindex

*

SysteemVertrouwens

Middel < authenticeert zich met

SysteemVertrouwens

Middel

< authenticeert zich met

*

De in paragraaf 4.2.17 genoemde HL7-conformancetabel bestaat voor iedereapplicatie uit een lijst met de volgende attributen:

• HL7-interactie-id,• type HTTP/SOAP-binding: enkelvoudig of tweevoudig.

Versienummers zijn in de HL7-conformancetabel niet nodig, omdat nieuwe versiesvan HL7-berichten leiden tot nieuwe HL7-interactie-id’s.


De in paragraaf 4.2.17 genoemde tijdsparametertabel bevat de volgendeparameters:

Parameter Verklaring Initiëlewaarde

gebruiker-oplever-time-out

tijdsinterval na opvraag van gebruikerwaarbinnen moet worden opgeleverd aangebruiker

20 sec

GBZ-oplever-time-out tijdsinterval na HL7-opvraag van GBZ aan ZIMwaarbinnen HL7-oplevering moet zijn ontvangen

10 sec

GBZ-opvraag-retry aantal keren dat mislukte opvraag van GBZ aanZIM wordt herhaald

1

ZIM-oplever-time-out tijdsinterval na HL7-opvraag van ZIM aan GBZwaarbinnen HL7-oplevering moet zijn ontvangen

5 sec

ZIM-opvraag-retry aantal keren dat mislukte opvraag van ZIM aanGBZ wordt herhaald

2

gebruiker-bevestig-time-out

tijdsinterval na opdracht van gebruikerwaarbinnen moet worden bevestigd aangebruiker

10 sec

GBZ-bevestig-time-out

tijdsinterval na HL7-opdracht van GBZ aan ZIMwaarbinnen HL7-bevestiging moet zijnontvangen

5 sec

GBZ-opdracht-retry aantal keren dat mislukte opdracht van GBZ aanZIM wordt herhaald

1

ZIM-bevestig-time-out

tijdsinterval na HL7-opdracht van ZIM aan GBZwaarbinnen HL7-bevestiging moet zijnontvangen

2 sec

ZIM-opdracht-retry aantal keren dat mislukte opdracht van ZIM aanGBZ wordt herhaald

2

gebruiker-max-kaart-uit

maximum duur dat vertrouwensmiddel vanwerkplek verwijderd mag zijn, voordat sessiewordt beëindigd

5 minuten

gebruiker-max-sleutel-duur

maximum duur dat tijdelijke SSL/TLS-sleutelgebruikt mag worden, waarna deze ververstmoet worden

5 minuten

gebruiker-max-sessie-duur

maximum duur van SSL/TLS-sessie tussengebruiker en ZIM, voordat sessie wordtbeëindigd

8 uur

gebruiker-max-sessie-onbruik

maximum duur dat een SSL/TLS-sessie tussengebruiker en ZIM niet gebruikt wordt, voordatsessie wordt beëindigd

30minuten

gebruiker-max-applicatie-onbruik

maximum duur dat applicatie door gebruiker nietgebruikt wordt, voordat sessie wordt beëindigd

15minuten

systeem-max-sleutel-duur

maximum duur dat een tijdelijke SSL/TLS-sleutelgebruikt mag worden, waarna deze ververstmoet worden

5 minuten

systeem-max-sessie-duur

maximum duur van een SSL/TLS-sessie tussendossier/postbus en ZIM, voordat de sessie wordtbeëindigd

8 uur

systeem-max-sessie-onbruik

maximum duur dat een SSL/TLS-sessie tussendossier/postbus en ZIM niet gebruikt wordt,voordat de sessie wordt beëindigd

15minuten


Opmerkingen:

• Objectmodellen worden gewoonlijk top-down afgeleid uit de voorgaandeparagrafen. Dit objectmodel is echter deels bottum-up afgeleid uitnavolgende hoofdstukken. Zo toont het objectmodel dat een ZIM kanbestaan uit verscheidene schakelpunten en verwijsindices, terwijl dat pas inhet volgende hoofdstuk wordt onderbouwd. Voor een goed begrip van hetbovenstaande model is lezing van de navolgende hoofdstukken noodzakelijk.

• Evenzo komt de tijdsparametertabel voort uit de paragrafen 5.6, 5.9 en5.10.


4.4 Interacties

Deze paragraaf beschrijft de interacties tussen objecten uit paragraaf 4.3 voor elkvan de gebruiksscenario’s beschreven in paragraaf 4.2.

Merk op dat de diagrammen voor de gebruiksscenario’s 0.1 tot en met 0.4 enkelegenerieke objecten tonen die altijd één van de onderstaande specifieke objectenmoeten zijn:

gebruiker gebruikerApplicatie gebruikerRegisterpatiënt/cliënt patiëntApplicatie patiëntRegisterzorgverlener,zorgmedewerker

zorgaanbiederApplicatie zorgaanbiederRegister

beheerder beheerApplicatie beheerdersRegister

4.4.1 Aan-/afsluiten applicatie op schakelpunt

Onderstaande UML sequence diagram toont welke interacties plaatsvinden tussende bovengenoemde objecten, als gevolg van gebruiksscenario (0.1), zie verderparagraaf 4.2.1 en paragraaf 5.6.3.

:gebruikerapplicatie

:gebruikerpostbus

:schakelpunt

:identif.&authent.

:systeemvertrouw.

middel

opzettenTCPverbinding

opzettenSSLsessie

aansluitenApplicatie

:gebruikerdossier

:gebruiker

Gebruiksscenario 0.1.1Aansluiten applicatie op schakelpunt

:systeemvertrouw.middel

sluitenSSLsessie

authenticerenauthenticeren

meldenToestand

instellenStuurparameters

De figuur toont bij gebruiksscenario 0.1.1 hoe een beheerder op basis van hetsysteemvertrouwensmiddel een verbinding opzet met het schakelpunt om eenbericht te sturen met een nieuwe beschikbaarheidstoestand.



:gebruikerpostbus

:schakelpunt

:identif.&authent.

:systeemvertrouw.

middel

:gebruikerdossier

:gebruiker

:systeemvertrouw.middel

opzettenSSLsessie


Gebruiksscenario 0.1.2aschakelpunt legt nieuwe verbinding

authenticerenauthenticeren

Gebruiksscenario 0.1.2bschakelpunt hervat verbinding

hervattenSSLsessie

wissen sleutels wissen sleutels

sluitenSSLsessie

Gebruiksscenario 0.1.2cschakelpunt sluit verbinding

verversen sessie-sleutels verversen sessie-sleutels

De figuur toont bij gebruiksscenario 0.1.2a hoe de SSL-sessie wordt opgezet doorhet schakelpunt.De figuur toont bij gebruiksscenario 0.1.2b hoe het schakelpunt een SSL-sessie naverloop van het tijdsinterval systeem-max-sessie-sleutel kan hervatten zonder detijdrovende authenticatie.

De figuur toont bij gebruiksscenario 0.1.2c hoe het schakelpunt een SSL-sessiedefinitief zal sluiten als:

• het tijdsinterval systeem-max-sessie-onbruik is verlopen sinds het laatstebericht over de SSL-verbinding,

• het tijdsinterval systeem-max-sessie-duur is verlopen sinds de laatsteauthenticatie.


4.4.2 In/uitloggen gebruiker

Onderstaande UML sequence diagram toont welke interacties plaatsvinden tussende bovengenoemde objecten, als gevolg van gebruiksscenario (0.2), zie verderparagraaf 4.2.2.

:gebruiker.applicatie

:systeemvertrouwens

middel

:schakelpunt

:identif.&authent.

sluitenSSLsessie

:persoonvertrouwens

middel

toegangsCode

invoeren

toegangsCode

uitloggenSessie

inloggenSessie

:gebruikerregister

:gebruiker

[indien nodig] opvragenStatusCert

Gebruiksscenario 0.2.1inloggen door gebruiker


opzettenSSLsessie

Gebruiksscenario 0.2.2uitloggen op commando

Gebruiksscenario 0.2.2uitloggen door time out

time-outsluitenSSLsessie

authenticeren

authenticeren


4.4.3 Selecteren patiënt/cliënt



:patiëntenregister

:autorisatieprotocol

:patiëntendossier

:schakelpunt

: toegangslog

:gebruiker

Gebruiksscenario 0.3.1Selecteren nieuwe patiënt uit register

:patiëntenadresboek

opvragenPatiëntIdentificatie

opvragenPatiëntIdentificatie

invoerenIdentificerendeGegevens

opleverenPatiëntIdentificatieloggenOpvraag

autoriseren

Gebruiksscenario 0.3.2Selecteren ingeschreven patiënt uit dossier

opvragenPatiëntIdentificatieinvoerenIdentificerendeGegevens

opleverenPatiëntIdentificatie

vastleggenPatiëntIdentificatiekiezenOvernemen


4.4.4 Selecteren zorgaanbieder

Onderstaande UML sequence diagram toont, welke interacties plaatsvinden tussende bovengenoemde objecten, als gevolg van gebruiksscenario (0.4), zie verderparagraaf 4.2.4.


:zorgaanb.register


:autorisatieprofiel

:schakelpunt

: toegangslog

:gebruiker

:zorgaanb.gids

Use case 0.4.1opzoeken zorgaanbieder

opvragenZorgverlenerDetails

opvragenZorgverlenerDetails

invoerenZoekcriteria

loggenOpvraag opleverenZorgverlenerDetailsopleverenZorgverlenerDetails

opvragenZorginstellingDetails

opvragenZorginstellingDetails

loggenOpvraag opleverenZorginstellingDetailsopleverenZorginstellingDetails

Gebruikscenario 0.4.2 heeft met de huidige HL7v3-berichten dezelfde interacties alsgebruikscenario 0.4.1.


4.4.5 Opvragen patiëntgegevens


:zorgaanb.applicatie

:gegevensOpvrager

:gegevensHouder

opvragenIndex

opleverenIndex[voor elke vermelde verwijsindex] opvragenIndex

opvragenIndex


:schakelpunt

autoriserenGeneriek

:verwijsindex

autoriserenSpecifiek

lokaliserenGegevens

loggenOpvraag

:autorprotoc

:autorprofiel

:toeglog

:patiëntdossier

Gebruiksscenario 2.1.1opvragen index patiëntgegevens

presenterenIndex

opvragenGegevensautoriserenGeneriek

opleverenGegevens


lokaliserenGegevens

[voor elk vermeld dossier] opvragenGegevens

loggenOpvraag

[voor elke vermelde verwijsindex] opvragenGegevens

opvragenGegevens

opleverenGegevens

Gebruiksscenario 2.1.2opvragen inhoudelijke patiëntgegevens

opzoekenGegevens

presenterenGegevens

Merk op dat de figuur rekening houdt met eventuele meerdere schakelpunten enverwijsindices.


4.4.6 Abonneren patiëntgegevens



: zorgaanb.applicatie


:autorisatieprofiel

:schakelpunt

: abonneeindex

: toegangslog

:gegevensOpvrager

:gegevensHouder

autoriserenGeneriek


vastleggenAbonnement

[voor elke andere abonneeIndex] vastleggenAbonnement

aanmeldenAbonnement

Gebruiksscenario 1.3.1aanmeldenabonnement

Gebruiksscenario 1.3.2afmeldenabonnement

annulerenAbonnement

[voor elke andere abonneeIndex] annulerenAbonnement

afmeldenAbonnement

aanmeldenAbonnement

afmeldenAbonnement


4.4.7 Publiceren patiëntgegevens





:patiëntdossier

:schakelpunt

: verwijsindex

: toegangslog

:gegevensOpvrager

:gegevensHouder

[voor elke andere verwijsindex] aanmeldenGegevens

[indien niet eerder aangemeld] aanmeldenGegevens

Gebruiksscenario 1.2.1Vrijgeven patiëntgegevens

Gebruiksscenario 1.2.2Afschermen patiëntgegevens

[indien nodig] vastleggenAanmelding

[voor elke andere verwijsindex] afmeldenGegevens

[indien niets meer vrijgegeven] afmeldenGegevens

[indien nodig] annulerenAanmelding

vrijgevenGegevens

afschermenGegevens

autoriserenGeneriek

loggenAanmelding

loggenAfmelding


4.4.8 Versturen patiëntbericht




:autorprotoc

:autorprofiel

:schakelpunt

:zorgaanb.adresboek

: toeglog

:verzender :ontvanger

[naar juiste schakelpunt] versturenPatiëntbericht

Gebruiksscenario 2.2.1versturen patiëntbericht

lokaliserenZorgaanbieder

versturenPatiëntbericht

loggenVerzending

autoriserenGeneriek




:zorgaanb.postbus

Gebruiksscenario 2.2.2ontvangen patiëntbericht

kiezenPatiëntbericht

presenterenPatiëntbericht

Voor gebruiksscenario 2.2.3 en 2.2.4, zie bijlage B.


5 Technische Architectuur

In de Technische Architectuur worden de technische ICT-voorzieningen beschouwddie de objecten en hun interacties uit de informatiesysteemarchitectuurimplementeren, zoals software-componenten en hardware-platformen. Dithoofdstuk gaat achtereenvolgens in op:

• strategie• ICT-voorzieningen van de basisinfrastructuur• berichtuitwisseling, transportprotocollen en connectiviteit,• beveiliging, beschikbaarheid, capaciteit, schaalbaarheid, responstijden en

betrouwbaarheid.

5.1 Strategie

In het document [Architectuurontwerp] is reeds aangegeven dat de strategie vanNICTIZ zich richt op de totstandkoming van:

• een basisinfrastructuur• goed beheerde zorgsystemen (GBZ)

De basisinfrastructuur omvat de gemeenschappelijke ICT-voorzieningen, inclusieforganisatorische voorzieningen, die nodig zijn om de individuele ICT-voorzieningenvan verschillende zorgpartijen (zorgaanbieders, zorgverzekeraars, etc.) onderling tekunnen koppelen. Deze basisinfrastructuur zal bestaan uit:

• een landelijke ZIM (Zorg Informatie Makelaar) met RF (RouteerFunctie)• een landelijke SBV-Z (Sectorale BerichtenVoorziening in de Zorg van het

BSN-stelsel)• een landelijk UZI-register (Unieke Zorgverlener Identificatie)• een landelijk UZOVI-register (Unieke ZOrgVerzekeraar Identificatie)• verscheidene regionale DCN’en (datacommunicatienetwerken).

De onderstaande figuur toont hoe deze ICT-voorzieningen onderling in principeworden verbonden in een variant op een UML deployment diagram:

UZOVIregister

Lokaal

Nationaal

Nationaal

Regionaal

ZIM

ZSP

SBV-ZUZIregister

GBZ GBZ GBZ GBZ

DCN DCN

GBZ GBZ

RF

ZSP

LSP

CIBG

ZAgids

ZA ZA ZA ZA ZA ZA

De bovengenoemde voorzieningen worden in de volgende paragrafen naderuitgewerkt.


5.2 ICT-voorzieningen

In de volgende paragrafen worden de verschillende ICT-voorzieningen van debasisinfrastructuur beschreven. Een ICT-voorziening kan een netwerk van datacom-verbindingen zijn of een systeem bestaande uit één of meer hardware-platformenmet software-componenten.

5.2.1 Sectorale BerichtenVoorziening

De Sectorale BerichtenVoorziening – Zorg (SBV-Z) van het BSN-stelsel is eengemeenschappelijke ICT-voorziening ten behoeve van het gebruik van het BSN inde Nederlandse zorgsector. De SBV levert of verifieert op verzoek van zorgpartijenhet BSN op basis van een set identificerende gegevens.

Zorgpartijen kunnen rechtstreeks contact zoeken met de SBV-Z via een website endoor middel van bestandsuitwisseling. Wanneer de ZIM is aangesloten op de SBV-Zkunnen zorgpartijen ook met hun GBZ via de ZIM de SBV bevragen. Als zodanigkan de SBV-Z dienst doen als landelijk patiëntenregister.

De exploitatie en het beheer van de SBV-Z valt onder verantwoordelijkheid van hetCIBG. Zie verder [BSN].

5.2.2 UZI-register

Het (Unieke Zorgverlener Identificatie) UZI-register is een gemeenschappelijke ICT-voorziening waarin zorgaanbieders met hun zorgverleners en medewerkers wordengeregistreerd die zijn voorzien van een UZI-pas.

Het UZI-register levert of verifieert op verzoek van zorgpartijen het UZI-nummervan een zorgverlener op basis van een set identificerende gegevens. Daarvoorkunnen zorgpartijen rechtstreeks contact zoeken met het UZI-register via eenwebsite.

De UZI-pas is een vertrouwensmiddel op basis van PKIO; dat betekent onder meerdat de UZI-pas aparte sleutelparen bevat voor authenticatie, versleuteling enhandtekening. Er zijn twee varianten: persoonsgebonden en systeemgebondenpassen. Als zodanig kunnen de UZI-passen dienst doen alspersoonsvertrouwensmiddel (PVM) resp. systeemvertrouwensmiddel (SVM). UZI-passen voor medewerkers en systemen bevatten geen sleutelpaar voorhandtekening.

Het UZI-register verifieert op verzoek van zorgpartijen de geldigheid van een UZI-pas en geeft uitsluitsel omtrent wie de houder is, welke zorgverlenerfunctie dieheeft en voor welke instelling hij werkt. Het UZI-register levert op verzoek ookcertificaten van publieke sleutels, indien de gebruiker daarin toestemt.

De exploitatie van de CA- en RA-diensten en het beheer van het UZI-register valtonder verantwoordelijkheid van het CIBG. Zie verder [UZI].


5.2.3 Zorgaanbiedergids

De Zorgaanbiedergids (ZG) wordt een gemeenschappelijke ICT-voorziening waarinalle zorgaanbieders in Nederland kunnen worden gepubliceerd met hun bereikbaar-heidsgegevens. De gids biedt zorgpartijen de mogelijkheid om te bladeren enbijvoorbeeld het HL7-adres van een zorgverlener op te zoeken.

Wanneer de Zorgaanbiedergids is aangesloten op de ZIM kunnen zorgpartijen ookmet hun GBZ via de ZIM de gids bevragen. Merk opdat het UZI-register geen dienstkan doen als landelijk zorgaanbiederregister, omdat de WBP het bladeren daarinniet toelaat en omdat CIBG garant wil staan voor alle daarin opgenomen gegevens.

De exploitatie van de Zorgaanbiedergids komt vermoedelijk te vallen onderverantwoordelijkheid van het CIBG.

5.2.4 UZOVI-register

Het (Unieke ZOrgVerzekeraar Identificatie) UZOVI-register is eengemeenschappelijke ICT-voorziening waarin alle zorgverzekeraars in Nederland zijngeregistreerd. Het UZOVI-register levert of verifieert op verzoek van zorgpartijenhet UZOVI-nummer van een zorgverzekeraar op basis van een set identificerendegegevens.

Zorgpartijen kunnen rechtstreeks contact zoeken met het UZOVI-register via eenwebsite. Wanneer de ZIM is aangesloten op het UZOVI-register kunnen zorgpartijenook met hun GBZ via de ZIM het UZOVI-register bevragen, maar dat wordt pas oplangere termijn voorzien.

De exploitatie en het beheer van het UZOVI-register vallen onderverantwoordelijkheid van Vektis. Zie verder www.vektis.nl.

5.2.5 Zorg Informatie Makelaar

Een Zorg Informatie Makelaar (ZIM) is een gemeenschappelijke ICT-voorziening dienodig is voor alle zorgaanbieders en andere zorgpartijen in Nederland om via hunGBZ’en onderling patiëntgegevens te kunnen uitwisselen.

Om te kunnen voldoen aan de hoge eisen die worden gesteld door de aangeslotenGBZ’en, dient de ZIM te worden beheerd door een onafhankelijke partij die debelangen van alle aangesloten zorgpartijen zo goed mogelijk kan dienen. Dezeonafhankelijke partij wordt het Landelijk Schakelpunt (LSP) genoemd.

Een ZIM zal de volgende software-componenten bevatten:• SCH – Schakelpunt• APT – AutorisatieProTocol• APF – AutorisatieProFiel• LOG – ToegangsLOG• I&A – Identificatie & Authenticatie• SVM – SysteemVertrouwensMiddel waarmee de ZIM zich kan authenticeren

aan GBZ’en• CFG - ConFiGuratietabel• VWI – VerWijsIndex• GGS - GeGevenSoortentabel

en diverse beheerapplicaties.

http://www.vektis.nl.


De onderstaande figuur toont dit in een UML deployment diagram:

ZIMSCH

VWI

CFG

LOG

APF

APT I&A SVM

GGS

De figuur toont de meest eenvoudige configuratie van de ZIM. Later in dithoofdstuk zal blijken dat de ZIM om reden van schaalbaarheid op verscheidenehardware-processoren of –platformen moet kunnen draaien en dus verscheideneinstanties van het schakelpunt kan hebben. Of van de andere software-componenten ook verscheidene instanties nodig zijn, zal afhangen van de gebruiktetechnologie en is dus aan de ZIM-leverancier.

Ook zal blijken dat er naast een operationele ZIM nog een uitwijk-ZIM en eenontwikkel-, testen demo-ZIM zal moeten komen. Deze zullen allemaal door hetLSP worden beheerd.

De eisen die worden gesteld aan de functies van een ZIM worden gespecificeerd inhoofdstuk 7.

De ZIM’s zullen worden gerealiseerd door deze aan te besteden tezamen met deexploitatie en het beheer ervan door een LSP, onder verantwoordelijkheid vanNICTIZ. De eisen die worden gesteld aan de diensten te leveren door het LSPworden vastgelegd in een apart te verschijnen Programma van Eisen voor het LSP[LSP].

De operationele ZIM hoeft niet meteen alle beveiligingsniveaus te ondersteunen,omdat er voorlopig geen GBZ’en zullen zijn met het hoogste beveiligingsniveau.Anderzijds zal de ZIM in de loop van de tijd steeds meer nieuwe functies en HL7v3-berichtsoorten gaan ondersteunen. Daarom zullen verschillende ZIM-kwalificatie-niveaus worden gedefinieerd. Elke nieuwe versie van de ZIM zal grondig getest engekwalificeerd moeten worden alvorens operationeel te mogen gaan.

5.2.6 RouteerFunctie

Een RouteerFunctie (RF) is een gemeenschappelijke ICT-voorziening die nodig isom onderling IP-verkeer tussen GBZ’en aangesloten op verschillende DCN’enmogelijk te maken. Deze zogenaamde interconnectiviteit is niet nodig voor deuitwisseling van patiëntgegevens m.b.v. HL7-berichten via de ZIM, maar wordt welnoodzakelijk als GBZ’en rechtstreeks bestanden gaan uitwisselen, bijv.multimediale bestanden m.b.v. DICOM, zie paragraaf 5.5.3. In de praktijk zal dezevoorziening van het LSP als IP-ingang voor de ZIM gaan dienen.

Gemakshalve zal de RF vaak als onderdeel van de ZIM worden beschouwd. Echter,wanneer duidelijk onderscheid nodig is tussen HL7-verkeer via de ZIM en IP-verkeer via de RF, zullen zij als aparte componenten worden beschouwd. In veelfiguren zal de RF niet zichtbaar zijn, omdat netwerkrouters gewoonlijk transparantzijn voor interacties tussen applicaties.


5.2.7 DataCommunicatieNetwerken

Een DataCommunicatieNetwerk (DCN) is een gemeenschappelijke ICT-voorzieningdie nodig is om de GBZ’en van verschillende zorgpartijen (zorgaanbieders,zorgverzekeraars, etc.) te kunnen aansluiten op de ZIM.

Zo’n DCN kan een VPN of een VAN zijn, zolang deze voldoet aan de gestelde eisenm.b.t. beveiliging en dienstverlening. In Nederland zijn diversenetwerkdienstverleners actief die zo’n DCN kunnen aanbieden, zie ook paragraaf3.10.2. De opzet van de basisinfrastructuur biedt de ruimte aan verscheidene,concurrerende netwerkdienstverleners om een regionale of categorale groep vansamenwerkende zorgaanbieders deze faciliteit aan te bieden.

Om een DCN te mogen aansluiten op de ZIM zal de netwerkdienstverlenerbovendien een aantal ondersteunende diensten moeten bieden aan zorgaanbiedersdie hun GBZ willen aansluiten. Deze diensten omvatten:

• de uitgifte van hostnamen en IP-adressen aan GBZ’en op basis van een IP-adresblok toegekend door het LSP,

• de aanlevering van routeringsgegevens aan het LSP voor uitgegeven IP-adressen,

• hulp aan zorgaanbieders bij het aansluiten van hun GBZ’en,• de eerste-lijns hulp aan zorgaanbieders bij incidenten,• de bewaking van de prestaties van het DCN,• etc.

Een DCN hoeft niet slechts het berichtenverkeer tussen de ZIM en de GBZ’en teverzorgen. In principe kan het DCN willekeurige datacom-behoeften van eenzorgaanbieder ondersteunen. Omdat verschillende DCN’en op basis vanverschillende VPN-technieken niet altijd gemakkelijk onderling gekoppeld kunnenworden, zal het LSP die zogenaamde interconnectiviteit bieden d.m.v. een RouteerFunctie (RF).

Zo’n DCN geeft de netwerkdienstverlener tenslotte de mogelijkheid om extradiensten te leveren aan zorgaanbieders, bijv. ondersteuning van een DNS, beheervan GBZ’en, gemeenschappelijke applicaties, toegang tot het openbare internet,maar ook installatie, advies, etc.

Op deze wijze wordt een netwerkdienstverlener een zogenaamdeZorgServiceProvider (ZSP), die de aangesloten zorgaanbieders kan ondersteunenmet een compleet pakket van samenhangende diensten.

5.2.8 Goed Beheerd Zorgsysteem

Een Goed Beheerd Zorgsysteem (GBZ) is een zorgapplicatie of een verzamelingzorgapplicaties, inclusief de bijbehorende patiëntdossiers en zorgaanbieder-postbussen, die ter beschikking staat van een zorgpartij (zorgaanbieder,zorgverzekeraar, etc.) en die voldoet aan een aantal eisen om te mogen wordenaangesloten op de ZIM.

Voorbeelden van een GBZ zijn een HIS, AIS, ZIS, LIS, etc. dat dan wel moetvoldoen aan minimumeisen met betrekking tot connectiviteit, beveiliging,beschikbaarheid, betrouwbaarheid, actualiteit en goed beheer. Daarnaast dient eenGBZ bepaalde patiëntgegevens te kunnen uitwisselen conform de HL7v3-


berichtenstandaard. De meeste bestaande XIS’en voldoen nog niet aan die eisen enzullen moeten worden aangepast.

Binnen een ziekenhuis kan ook het gehele stelsel van ZIS, ZAIS, LIS, RIS, PACS,etc. worden beschouwd als één GBZ, maar het is ook mogelijk delen daarvan alsaparte GBZ aansluiten op de ZIM.

Veelal zal een XIS bestaan uit een of meer zorgaanbiederapplicatie (ZA),postbussen (PB), patiëntdossiers (PD) en veelal een patiëntenindex (PI). Om totGBZ te worden opgewaardeerd, zal een XIS veelal moeten worden voorzien van:

• GP – een GegevensPoort die alle patiëntgegevens in het dossier kan vertalennaar HL7v3-formaat en als bericht kan versturen naar de ZIM en andersom.

• APB – een interne autorisatietabel indien het GBZ ook interne uitwisselingvan patiëntgegevens ondersteunt.

• APF – interne autorisatieprofielen indien het GBZ ook interne uitwisselingvan patiëntgegevens ondersteunt.

• MDT – een mandateringstabel.

• LOG – een lokale toegangslog.

• SVM – een SysteemVertrouwensMiddel waarmee het GBZ zich kanauthenticeren aan de ZIM.

• Kaartlezers waarin de GBZ-gebruikers hun Persoonlijke vertrouwensmiddel(PVM) kunnen invoeren om zich te authenticeren aan het GBZ.

• Randapparatuur als firewall, router, modem, etc. voor zover niet reedsaanwezig.

De onderstaande figuur toont dit in een UML deployment diagram:

GBZ

PD

GP

PB

APB APF

Kaartlezer

KaartPVM

LOG SVM

PI

MDT

ZA

De figuur toont de meest eenvoudige configuratie van een GBZ. Later zal blijkendat een GBZ kan bestaan uit één of meer applicaties en andere software-componenten, die draaien op één of meer hardware-platformen.

Zowel het PVM als het SVM moeten volgens PKIO op een fysiek beveiligd hardware-medium (ook wel hard token of hardwarecertificaat genoemd) staan. Echter, hetUZI-register staat tijdelijk toe een SVM (ook servicescertificaat genoemd) op een


computerschijf te plaatsen (ook wel soft token of softwarecertificaat genoemd),mits deze goed is afgeschermd.

De eisen die worden gesteld aan de functies van een GBZ worden gespecificeerd inhoofdstuk 6.

Een GBZ kan op twee manieren worden gerealiseerd:

• door de XIS bij een zorgaanbieder te vervangen door een nieuwe versie diedoor en bij de XIS-leverancier is opgewaardeerd tot een GBZ. Dit kanwerken voor zorgaanbieders die een enkele XIS-leverancier hebben.

• door de operationele XIS bij een zorgaanbieder stapsgewijs op te waarderennaar een GBZ. Dit zal gelden voor zorgaanbieders die vele, verschillendeXIS-leveranciers hebben.

De eisen die worden gesteld aan de diensten te leveren door een GBZ wordenvastgelegd in een apart te verschijnen Programma van Eisen voor een GBZ.

Voor veel XIS’en zal het moeilijk zijn om te worden opgewaardeerd tot hetgewenste beveiligingsniveau. Ook hoeven niet alle XIS’en meteen alle HL7v3-berichtsoorten te ondersteunen. Bovendien zullen in de loop van de tijd steedsmeer nieuwe functies en HL7v3-berichtsoorten worden ontwikkeld. Daarom zullenverschillende GBZ-kwalificatieniveaus worden gedefinieerd.

Tenslotte kunnen ook systemen van zorgverzekeraars, applicatieaanbieders, etc.als GBZ worden aangesloten op de ZIM, maar dat is in deze versie van ditdocument nog niet uitgewerkt.


5.2.9 Samenhang tussen ICT-voorzieningen

In deze paragraaf wordt beschreven hoe de hierboven beschreven ICT-voorzieningen samenwerken. Daarbij worden de verschillende software-componenten (feitelijk de objecten gespecificeerd in paragraaf 4.3, zie aldaar vooreen nadere verklaring) als volgt afgekort:

PD – een PatiëntDossierPB – een zorgaanbiederPostBusZA – een ZorgaanbiederApplicatieGP – GegevensPoortSVM - SysteemVertrouwensMiddelSCH – SchakelpuntVWI – VerWijsIndexI&A – Identificatie & AuthenticatieLOG – toegangsLOGCFG - ConFiGuratietabellenAPT – AutorisatieProTocolAPB – (lokale) AutorisatietabelAPF – AutorisatieProFielMDT - ManDateringsTabelPR – (landelijke) PatiëntenRegisterPI – (lokale) PatiëntenIndexZR – ZorgaanbiederRegisterZG – ZorgaanbiederGids

De onderstaande figuur toont deze situatie in een variant op een UML deploymentdiagram:

DCN

SBV UZI

PR ZR

ZIMSCH

VWI

CFG

LOG

APF

APT I&A

ZG

SVM

GGS

GBZ

PD

GP

PB

APB APF

Kaartlezer

KaartPVM

LOG SVM

PI

MDT

ZA

De figuur toont de eenvoudige situatie van een ZIM met één schakelpunt. Als deZIM verscheidene schakelpunten bevat, verdeeld over verscheidene ZIM-


platformen, moet de ZIM zich naar de GBZ’en nog steeds gedragen als één logischeZIM.

De figuur toont ook een eenvoudige GBZ met slechts één zorgaanbiederapplicatie,één patiëntdossier en één zorgaanbiederpostbus. In de praktijk zal een GBZ veleapplicaties hebben met vele dossiers en postbussen.

De figuur toont niet de directe uitwisseling van bestanden tussen een GBZ en deSBV-Z t.b.v het koppelen van bestaande patiëntdossiers met het BSN. Überhauptkan niet worden uitgesloten dat systemen buiten de ZIM om met elkaarcommuniceren, maar dat valt buiten het aandachtsgebied van NICTIZ.

Belangrijk is op te merken dat de ZIM een centrale rol speelt in de communicatietussen de aangesloten systemen. De onderstaande tabel toont met welkeprotocollen die communicatie plaatsvindt.

ZIM GBZGBZ HL7v3 {toekomst} multimediale bestandsoverdrachtSBV-Z HL7v3 HL7v3, HTML, XML-bestandsoverdrachtUZI-register LDAP LDAP, HTMLZG HL7v3 HL7v3, HTML


5.3 Berichtuitwisseling

Als gevolg van de keuzes gemaakt in de vorige paragraaf inzake de verdeling vansoftware-componenten over hardware-platformen, zullen de interacties vanparagraaf 4.4 voor een deel tussen verschillende hardware-platformen moetenplaatsvinden. Dit wordt hier voor alle gebruikersinteracties uitgewerkt.

5.3.1 Overzicht van gebruikersinteracties

Voor de uitwisseling van patiëntgegevens tussen GBZ en ZIM is reeds gekozen voorHL7v3, zie [Architectuurontwerp]. HL7v3 definieert een scala aan zorginhoudelijkeberichten voor directe 1-op-1 communicatie tussen twee zorgsystemen, gewoonlijkbinnen zorginstellingen.

In het geval van de basisinfrastructuur gaat het om indirecte communicatie tussenzorginstellingen via een ZIM. In geval van opvragen van patiëntgegevens isbovendien sprake van 1-op-N communicatie. Deze kwestie is uitgewerkt in bijlageC. De adressering dient op meerdere niveaus geregeld te worden: op berichtniveau(met nader onderscheid tussen inhoudniveau en envelopniveau), transportniveauen verbindingniveau, zie bijlage D.

Als gevolg daarvan kan één gebruikersinteractie leiden tot één of meer HL7v3-gebeurtenissen (HL7v3 events):

• de gebruikersinteractie aan/afmelden patiëntgegevens leidt tot:o één HL7v3-gebeurtenis tussen de meldende GBZ en de ZIM.

• de gebruikersinteractie opvragen index leidt tot:o één HL7v3-gebeurtenis tussen de opvragende GBZ en de ZIM.

• de gebruikersinteractie versturen patiëntgegevens leidt tot:o één HL7v3-gebeurtenis tussen de versturende GBZ en de ZIM,o één HL7v3-gebeurtenis tussen de ZIM en de ontvangende GBZ.

• de gebruikersinteractie opvragen patiëntgegevens leidt tot:o één HL7v3-gebeurtenis tussen de opvragende GBZ en de ZIM,o X HL7v3-gebeurtenissen tussen de ZIM en X opleverende GBZ’en.

Aldus wordt bij een gebruikersinteractie voortaan onderscheid gemaakt naar devolgende interactiemechanismen:

• direct versturen: van agerende GBZ aan ZIM,• indirect versturen: van agerende GBZ via ZIM aan andere, reagerende GBZ,• direct opvragen: van agerende GBZ aan ZIM,• indirect opvragen: van agerende GBZ aan ZIM en van ZIM aan andere,

reagerende GBZ’en of PR of ZR of ZG.

In geval van indirect versturen moet de ZIM berichten doorsturen. In geval vanindirect opvragen treedt de ZIM eigenlijk op als virtuele beantwoorder, die van eenGBZ een opvraag krijgt, deze opvraag opnieuw stelt aan andere GBZ’en of eenregister, de resultaten verzamelt en de verzameling van resultaten oplevert alsof deZIM deze zelf had.


Elke HL7v3-gebeurtenis kan bestaan uit één of meer HL7-interacties, bijvoorbeeldeen HL7v3-verzoekbericht en een HL7v3-antwoordbericht.

HL7v3-berichten worden opgebouwd uit de volgende onderdelen:

• Payload bevat inhoudelijke patiëntgegevens van een bepaaldegegevenssoort.

• Control Act Wrapper bevat gegevens over de interactie die moet wordenuitgevoerd met de payload, bijv. het aantal resultaten dat voor een opvraagmoet worden opgeleverd.

• Transmission Wrapper bevat gegevens over het transport, bijv. van welkeapplicatie naar welke applicatie het bericht moet worden gestuurd.

• Batch Wrapper kan gebruikt worden om meerdere berichten in te pakken.

De onderstaande figuur toont met getrokken lijnen welke onderdelen altijdaanwezig zijn en met gestippelde lijnen welke onderdelen niet altijd aanwezig zijn:

HL7v3batch wrapper

HL7v3transmission wrapper

HL7v3control act wrapper

HL7v3payload

Op initiatief van NICTIZ is de HL7v3-standaard uitgebreid met een aantalberichtdefinities die toepasbaar zijn voor de Nederlandse basisinfrastructuur.De onderstaande tabel geeft een overzicht van de HL7-interacties die plaatsvindentussen een GBZ en de ZIM en tussen de ZIM en de SBV-Z en het UZI-register alsgevolg van de mogelijke gebruikersinteracties.


GebruiksscenarioGebruikersinteractie

Berichtnaam

HL7v3-interactie

HL7v3payload

HL7v3controlactwrapper

HL7v3transmisswrapper

HL7v3batchwrapper

Ge-gevens-soort

Mecha-nisme

Toepassingsrol

0.1 aan/afsluiten applicatie Geen

0.2 in/uitloggen gebruiker

Inloggen gebruiker Geen

Uitloggen gebruiker Geen

0.3 selecteren patient/cliënt

Opvragen PatiëntIdentificatie

opvragenPatiëntIdentificatie QUPA_IN101103

QUPA_MT101103

QUQI_MT020001

MCCI_MT000100

indirectopvragen

alle

opleverenPatiëntIdentificatie QUPA_IN101104

QUPA_MT101104

MFMI_MT700711

MCCI_MT000300

alle

0.4.1 opzoeken zorgaanbieder

Opvragen Zorgaanbieders

opvragenZorgverlenerDetails PRPM_IN306050NL

QUPA_MT101103

QUQI_MT020001

MCCI_MT000100

indirectopvragen

opleverenZorgverlenerDetails PRPM_IN306051NL

QUPA_MT101104

MFMI_MT700711

MCCI_MT000300

opvragenZorginstellingDetails PRPM_IN405010

PRPM_MT405010

QUQI_MT121001

MCCI_MT000100

indirectopvragen

opleverenZorginstellingDetails PRPM_IN405110

PRPM_MT405110

MFMI_MT700711

MCCI_MT000300

0.4.2 opvragen bereikbaarheid

Opvragen Zorgaanb.bereikbaarheid Zie 0.4.1

1.1 bijhouden patiëntgegevens Geen


1.2 publiceren patiëntgegevens

Publiceren MedicatieVoorschriftenPubliceren MedicatieVerstrekkingenPubliceren EerstelijnsDossier

aanmeldenGegevensMFMT_IN002101

MFMT_MT002002

MFMI_MT700702

MCCI_MT000100

SBADMSPLYPCPR

directversturen

EMD-voorschrijverEMD-verstrekkerWDH-dossierhouder

heraanmeldenGegevensMFMT_IN002102

MFMT_MT002001

MFMI_MT700702

MCCI_MT000100

SBADMSPLYPCPR

directversturen


afmeldenGegevensMFMT_IN002103

MFMT_MT002001

MFMI_MT700702

MCCI_MT000100

SBADMSPLYPCPR

directversturen


1.3 abonneren patiëntgegevens Niet gedefinieerd

2.1 opvragen patiëntgegevens

Opvragen Index

opvragenIndex QUMT_IN020010

QUMT_MT020020

QUQI_MT021001

MCCI_MT000100

directopvragen

alle

opleverenIndex QUMT_IN020020

MFMT_MT002001

MFMI_MT700712

MCCI_MT000300

Opvragen MedicatieVoorschriften

opvragenMedicatievoorschriften(eerste)

QURX_IN990001NL

QURX_MT990001NL

QUQI_MT020001

MCCI_MT000100

SBADM indirectopvragen

EMD-voorschrijver

opleverenMedicatievoorschriften QURX_IN990003NL

PORX_MT932000NL

QUQI_MT120001

MCCI_MT000300

MCCIMT200101

EMD-voorschrijver


opvragenMedicatievoorschriften(vervolg)

QUQI_IN000003

n.v.t. QUQI_MT000001

MCCI_MT000100

SBADM EMD-voorschrijver


PORX_MT932000NL

QUQI_MT120001

MCCI_MT000300

MCCIMT200101

EMD-voorschrijver

Opvragen MedicatieVerstrekkingen

opvragenMedicatieverstrekkingen(eerste)

QURX_IN990011NL

QURX_MT990011NL

QUQI_MT020001

MCCI_MT000100

SPLY indirectopvragen

EMD-voorschrijverEMD-verstrekker

opleverenMedicatieverstrekkingen QURX_IN990013NL

PORX_MT924000NL

QUQI_MT120001

MCCI_MT000300

EMD-verstrekker

opvragenMedicatieverstrekkingen(vervolg)

QUQI_IN000003

n.v.t. QUQI_MT000001

MCCI_MT000100

SPLY EMD-voorschrijverEMD-verstrekker


PORX_MT924000NL

QUQI_MT120001

MCCI_MT000300

MCCIMT200101

EMD-verstrekker

Opvragen Samenvatting DWH

opvragenSamenvattingVoorDWH QUPC_IN990001NL

QUPC_MT990001NL

QUQI_MT021001

MCCI_MT000100

PCPR indirectopvragen

WDH-waarnemer

opleverenSamenvattingVoorDWH QUPC_IN990002NL

REPC_MT004001NL-PS

QUQI_MT120001

MCCI_MT000300

MCCIMT200101

WDH-dossierhouder

Opvragen Samenvatting SEH

opvragenSamenvattingVoorSEH QUPC_IN990011NL

QUPC_MT990011NL

QUQI_MT021001

MCCI_MT000100

PCPR indirectopvragen

Nader in te vullen

opleverenSamenvattingVoorSEH QUPC_IN990012NL

REPC_MT004001NL-SH

QUQI_MT120001

MCCI_MT000300

MCCIMT200101

Nader in te vullen

2.2 versturen patiëntgegevens

Versturen MedicatieVoorschrift


versturenMedicatievoorschrift PORX_IN932000NL

PORX_MT932000NL

MCAI_MT700201

MCCI_MT000100

indirectversturen

EMD-voorschrijver

Versturen Medicatieverstrekking

versturenMedicatieverstrekking PORX_IN924000NL

PORX_MT924000NL

MCAI_MT700201

MCCI_MT000100

indirectversturen

EMD-verstrekker

Versturen Verslag DWH

VersturenVerslagDWH REPC_IN990003NL

REPC_MT004001NL_WR

MCAI_MT700201

MCCI_MT000100

indirectversturen

WDH-waarnemer

Versturen Verslag SEH

versturenVerslagSEH REPC_IN990013NL

REPC_MT004001NL_ER

MCAI_MT700201

MCCI_MT000100

indirectversturen

Nader in te vullen

Versturen PatiëntOverdracht

versturenPatiëntOverdracht REPC_IN004411NL

REPC_MT000001NL

MCAI_MT700201

MCCI_MT000100

indirectversturen

Nader in te vullen

Versturen Verwijzing

versturenVerwijzing REPC_IN002111NL

REPC_MT002001NL

MCAI_MT700201

MCCI_MT000100

indirectversturen

Nader in te vullen

Versturen BepalingOpdracht

versturenBepalingOpdracht POLB_IN002121

POLB_MT002100

MCAI_MT700201

MCCI_MT000100

indirectversturen

Nader in te vullen

versturenBepalingResultaat POLB_IN004410

POLB_MT004000

MCAI_MT700201

MCCI_MT000100

indirectversturen

Nader in te vullen


Voor de manier waarop van de verschillende, gestandaardiseerde HL7-interactiesgebruik wordt gemaakt, zijn er enkele keuzes te maken. Die keuzes wordeningeleid in de navolgende paragrafen en nader uitgewerkt in de HL7-Implementatiehandleidingen.Ten behoeve van autorisatie en mandatering worden de volgende klassen vangebruikersinteracties onderkend:

• Algemene:o Opvragen PatiëntIdentificatieo Opvragen Zorgaanbieders

• Medische:o Opvragen Indexo Publiceren MedicatieVoorschrifteno Publiceren MedicatieVerstrekkingeno Opvragen MedicatieVoorschrifteno Opvragen MedicatieVerstrekkingeno Versturen MedicatieVoorschrifto Versturen MedicatieVerstrekkingo Publiceren EerstelijnsDossiero Opvragen Samenvatting DWHo Versturen Verslag DWH

• Toekomstige:o Opvragen Samenvatting SEHo Versturen Verslag SEHo Versturen PatiëntOverdrachto Versturen Verwijzingo Versturen BepalingOpdrachto Versturen BepalingResultaat

Opmerkingen:

• Ad 0.3: De berichten voor het opvragen en verifiëren van het BSN van eenpatiënt zijn in de tabel opgenomen als opvragenPatiëntIdentificatie enopleverenPatiëntIdentificatie.

• Ad 0.4.1: er zijn aparte HL7-interacties voor het opvragen vanzorginstellingen en voor het opvragen van zorgverleners, dus leidt ditgebruiksscenario tot twee verschillende HL7-interacties.

• Ad 0.4.2: voor gebruiksscenario 0.4.1 zijn er geen HL7-interacties voor hetuitsluitend ophalen van identificerende gegevens van zorgaanbieders,daarom worden aldaar HL7-interacties gebruikt die tegelijk ook debereikbaarheidsdetails opvragen en opleveren. Dit betekent dat voorgebruiksscenario 0.4.2 geen HL7-interacties meer nodig zijn.


5.3.2 Indirect opvragen

Wanneer een zorgaanbieder patiëntgegevens wil opvragen (HL7: query) van anderezorgaanbieders, zal één opvraag al gauw leiden tot vele resultaten. Immers, een X-aantal opleverende GBZ’en kunnen ieder een Y-aantal resultaten opleveren, zie deonderstaande figuur.

Daarbij kan de ZIM in principe de volgende opties bieden die in een HL7-opvraagbericht als parameter kunnen worden aangegeven:

• wel/niet doseren van het aantal resultaten per oplevering,• wel/niet bundelen van verschillende opleveringen in één gebundelde

oplevering (HL7: batch),• wel/niet sorteren van resultaten,• wel/niet uitstellen van de oplevering (HL7: immediate vs. deferred).

Het uitstellen van de oplevering kent momenteel geen toepassing en wordt daaromniet als optie geboden. In Bijlage C wordt onderbouwd dat de ZIM aan eenopvragende GBZ slechts de volgende keuzevrijheid moet bieden:

• wel/niet bundelen,• wel/niet doseren.

In geval van WEL bundelen en NIET doseren zal één HL7-opvraagbericht (HL7:query request) altijd leiden tot één gebundelde HL7-oplevering (HL7: batch) metdaarin één of meer HL7-opleveringen (HL7: query response) met ieder één of meerresultaten, zie de onderstaande figuur.

:GBZ0:gegevensopvrager

: GBZx:gegevens

houder

:ZIM

HL7-query-req (batch)

HL7-batch (HL7-query-rsp (resultaten) )

[voor elke GBZx vermeld in verwijsindex]

HL7-query-req

HL7-query-rsp (resultaten)

opvraag

presentatieresultaten

(oorspronkelijk)opvraagbericht

gedivergeerdopvraagbericht

(oorspronkelijk)opleverbericht

geconvergeerdopleverbericht

Let op: anders dan de figuren suggereren, zijn het niet zozeer de GBZ’en maar deafzonderlijke applicaties binnen die GBZ’en die zijn vermeld in de verwijsindex.


In alle andere gevallen dan WEL bundelen en NIET doseren zal hetzelfde interactie-mechanisme plaatsvinden, maar kan dat herhaald geschieden, afhankelijk van hetaantal beschikbare resultaten en de gestelde maxima per oplevering. Merk op datzowel een opvragend GBZ als een opleverend GBZ een maximum aantal resultatenkan hanteren en dus aanleiding kan geven tot vervolgopvragen.

De eerste opvraag (HL7: query specification) bevat de opvraagcriteria; dedaaropvolgende HL7-vervolgopvragen (HL7: query continuation) geven slechts aandat de volgende resultaten moeten worden opgeleverd. Zie onderstaande figuur. Desessie eindigt na een HL7-eindeopvraag (HL7: query cancel) of wanneer alleresultaten zijn opgeleverd.


: GBZx:gegevens

houder

:ZIM

HL7-query-spec (max N) ofHL7-query-spec (batch, max N)

HL7-query-spec (max N)



opvraag

[voor elke opvraag van de volgende N antwoorden]

HL7-query-cancel

HL7-query-rsp (resultaten) ofHL7-batch (HL7-query-rsp (resultaten) )


(oorspronkelijk) eerste opvraagbericht

gedivergeerd eerste opvraagbericht

(oorspronkelijk) opleverbericht

geconvergeerd opleverbericht

origineel einde opvraagbericht

HL7-query-cont ()

(oorspronkelijk) vervolg opvraagbericht

HL7-query-rsp (resultaten) ofHL7-batch (HL7-query-rsp (resultaten) )


geconvergeerd opleverbericht

HL7-query-cont ()



gedivergeerd vervolg opvraagbericht

(oorspronkelijk) opleverbericht

afbreking

Ontwerpbeslissingen uit bijlage C:

[B62] De ZIM moet, indien een opvragende GBZ daarom verzoekt, de resultatenvan de opleverende GBZ’en bundelen tot één gebundeld opleverbericht aandat GBZ.

[B63] De ZIM moet opleverende GBZ’en nooit om een gebundeld opleverberichtvragen.

[B64] De ZIM moet opleveringen op verzoek van een opvragende GBZ kunnendoseren.


[B65] De ZIM moet een gedoseerde opvraag ook gedoseerd divergeren naar deopleverende GBZ’en, met hetzelfde maximum aantal resultaten.

[B66] De ZIM moet een oplevering van een GBZ weigeren als deze meer dan hetgevraagde maximum aantal resultaten bevat.

[B67] De ZIM moet rekening houden met een GBZ dat ongevraagd gedoseerdoplevert en zonodig vervolgopvraagberichten sturen.

[B68] De ZIM mag een vervolgvraag van een opvragende GBZ weigeren indiendeze een maximum aantal resultaten en/of een volgnummer zou bevatten.

[B69] De ZIM moet een verzoek van een opvragende GBZ voor het sorteren vanresultaten weigeren.

Merk op dat de positie van de ZIM tussen één opvragend GBZ en vele opleverendeGBZ’en wezenlijk anders is dan die bij het versturen van patiëntgegevens. De ZIMfungeert hier als “gateway”, zie HL7 Abstract Transport Specification. Dit betekentdat de ZIM meer doet dan HL7-berichten één op één doorschuiven. De ZIM treedteigenlijk op als tussenpersoon die van een GBZ een opvraag krijgt, deze opvraagopnieuw stelt aan andere GBZ’en, de resultaten verzamelt en de verzameling vanresultaten oplevert alsof de ZIM deze zelf had.

Om een HL7-opvraagbericht te kunnen divergeren naar een X-aantal andereGBZ’en aan de hand van de verwijsindex, moet de ZIM uit de HL7-inhoud (HL7:payload) kunnen lezen:

• patiëntnummer• gegevenssoort

Om een HL7-opvraagbericht vooraf te kunnen autoriseren, moet de ZIM bovendienuit de ControlAct Wrapper kunnen lezen:

• id en functie van de gebruiker• id en functie van de mandaterende zorgverlener

Evenwel kijkt de ZIM niet in HL7-inhoud (HL7: payload) van de HL7-opleverberichten, zie ook bijlage D.

Daarnaast volgt uit de HL7v3-implementatiehandleidingen dat de ZIM bij hetdoorschuiven van een bericht (meer specifiek: het divergeren van eenopvraagbericht en het convergeren van een opleverbericht) het volgende moetdoen:

• altijd de Transmission Wrapper wijzigen en dus ook een nieuw bericht-idtoekennen, ook als de berichten daarna nog worden gebundeld in een BatchWrapper.

• in het opvraag-specifieke deel van de ControlAct Wrapper wijzigen:o {toekomst} de opvraag-ido zonodig de tellers

• de rest van de ControlAct Wrapper canoniek ongewijzigd laten, evenals deeventuele Payload.


De onderstaande figuur toont ten behoeve van paragraaf 4.3.8 de relaties tussende verschillende berichten als gevolg van een opvraag door een gebruiker, in eenUML class diagram.

Zorgaanb.bereikb.geg.

Patiëntidentif.geg.

Indirecteopvraaginteractie

ResultaatYbevat >

leidt tot >

bevat >

bevat >

bevat >

bevat >

1

1

Geconverg.opleverbericht

Gedivergeerdopvraagbericht

(Oorspronk.)opleverbericht

(Oorspronk.)opvraagbericht Opvraag

Oplevering

HL7v3 Transmission Wrapper HL7v3 ControlAct Wrapper HL7v3 Payload

1

1

*

Bundeloplever

berichten

X..

Z

*X..

Z

Enkelopleverbericht

bevat >1..X

Patiëntstuk

EindeopvraagVervolg

opvraagEersteopvraag

De figuur toont onder meer:• dat een opvraagsessie kan leiden tot Z opvraagberichten,• dat één opvraag kan leiden tot X opleveringen met ieder Y resultaten,• dat een opvraag kan zijn:

o een eerste opvraag, ofo een vervolg opvraag, ofo een einde opvraag.

• dat een resultaat kan zijn:o een patiëntstuk, ofo identificerende gegevens van een patiënt, ofo bereikbaarheidsgegevens van een zorgaanbieder,

• dat een gedivergeerd opleverbericht kan zijn:o een enkel opleverbericht, ofo een bundel van X opleverberichten,

• dat een oorspronkelijk bericht en een gedivergeerd of geconvergeerd berichtverschillen op het niveau van:

o de HL7v3 Transmission Wrapper (dus met een ander bericht-id),o het opvraag-specifieke deel van de HL7v3 ControlAct Wrapper (dus

met een ander opvraag-id),maar gelijk zijn op het niveau van:

o het generieke deel van de HL7v3 ControlAct Wrapper (dus metdezelfde gebeurtenis-id indien aanwezig),

o de eventuele HL7v3 Payload (dus met dezelfde patiëntstuk-id).


5.3.3 Indirect versturen

Wanneer een zorgaanbieder een opdracht (HL7: order) wil sturen naar een anderezorgaanbieder, kan de ZIM daarbij in principe de volgende opties bieden, die in eenHL7-opdracht als parameter kunnen worden aangegeven:

• wel/niet bevestigen van gelukte of mislukte aflevering (HL7: acceptacknowlegdment),

• {toekomst} wel/niet onmiddellijk afleveren.

De optie WEL bevestigen wordt hier verplicht gesteld voor opdrachtberichtenzonder inhoudelijk antwoord (HL7: application response), omdat de opdrachtgeveranders geen enkele zekerheid krijgt dat zijn opdrachtbericht is aangekomen.Momenteel zijn nog geen opdrachtberichten mét inhoudelijk antwoord gedefinieerd,dus zal altijd een bevestiging moeten plaatsvinden. Een HL7-ontvangstbevestigingmag overigens niet worden gegeven voordat de HL7-opdracht persistent isgemaakt.

De optie WEL onmiddellijk afleveren valt momenteel niet te kiezen, maar wordtdoor de ZIM standaard uitgevoerd. Dit betekent dat de ZIM de opdracht van GBZ1onmiddellijk probeert af te leveren bij GBZ2 en meteen bevestigt of het gelukt is.Als GBZ2 toevallig even niet beschikbaar is, moet GBZ1 het later maar opnieuwproberen. Dit is het instant messaging mechanisme en verschilt wezenlijk van hetstore & forward-mechanisme zoals bij e-mail.

:GBZ1 : GBZ2:ZIM

HL7-accept-ack

:opdrachtgever

:opdrachtnemer

HL7-order-reqHL7-order-req

HL7-accept-ack

opdracht

presentatiebevestiging

(oorspronkelijk)opdrachtbericht doorgestuurd

opdrachtbericht

(oorspronkelijk)bevestigberichtdoorgestuurd

bevestigbericht

Merk op dat de positie van de ZIM tussen een versturend GBZ en een ontvangendGBZ wezenlijk anders is dan die bij het opvragen van patiëntgegevens. De ZIMfungeert hier als “bridge”, zie HL7 Abstract Transport Specification. Dit betekent datde ZIM slechts HL7-berichten doorschuift zonder de HL7-inhoud te beroeren. Zoworden HL7-opdrachten van GBZ1 door de ZIM afgeleverd bij GBZ2 alsof datrechtstreeks ging. Hetzelfde geldt voor HL7-bevestigingen van GBZ2 die door deZIM worden afgeleverd bij GBZ2. Alleen als er communicatieproblemen optredentussen ZIM en GBZ2, zal de ZIM zelf een HL7-bevestiging genereren, zie paragraaf5.10. Zie ook bijlage D.

Er is echter één reden voor de ZIM om toch in de HL7-inhoud (HL7: payload) tekijken. Om een HL7-opdrachtbericht te kunnen autoriseren moet de ZIM immers uitde HL7-inhoud kunnen lezen:


• patiëntnummer• gegevenssoort• zorgverleneridentificatie• zorgverlenerfunctie


[B70] De ZIM moet op verzoek van een versturende applicatie de patiënt-berichten zowel onmiddellijk als {toekomst} mettertijd kunnen afleveren.

Daarnaast volgt uit de HL7v3-implementatiehandleidingen dat de ZIM bij hetdoorsturen van een opdracht- of bevestigbericht het volgende moet doen:

• altijd de Transmission Wrapper canoniek ongewijzigd laten, evenals deeventuele ControlAct Wrapper en Payload.

Met canoniek ongewijzigd wordt bedoeld dat de verschijningsvorm mag verschillenzolang de XML-inhoud semantisch gelijk blijft.

De onderstaande figuur toont ten behoeve van paragraaf 4.3.8 de relaties tussende verschillende berichten als gevolg van een opdracht door een gebruiker.

Indirecteopdrachtinteractie

Patiëntstuk

1

1

1

1

1bevat >

leidt tot >

bevat >

^is gelijk aan

1

Doorgestuurdbevestigbericht

Doorgestuurdopdrachtbericht

(Oorspronk.)bevestigbericht

(Oorspronk.)opdrachtbericht

Opdracht

HL7v3 Transmission Wrapper HL7v3 ControlAct Wrapper HL7v3 Payload

^is gelijk aan

De figuur toont onder meer:• dat één opdrachtbericht steeds tot één bevestigbericht leidt.• dat een oorspronkelijk bericht en een doorgestuurd bericht gelijk zijn op het

niveau van:o de HL7v3 Transmission Wrapper (dus met dezelfde bericht-id),o de eventuele HL7v3 ControlAct Wrapper (dus met dezelfde

gebeurtenis-id),o de eventuele HL7v3 Payload (dus met dezelfde patiëntstuk-id).


5.4 Transportprotocollen

Voor de datacommunicatie tussen GBZ en ZIM is reeds gekozen voor internet-protocollen: HTTP met SSL/TLS over TCP/IP, zie [Architectuurontwerp]. Om dezorginhoudelijke HL7v3-berichten veilig te kunnen transporteren over een DCNgebaseerd op deze internet-protocollen, zijn aanvullende transportprotocollennodig. De HL7v3-standaard noemt hier de volgende mogelijkheden:

• Minimal Lower Layer Protocol (MLLP)• ebXML Messaging Service (ebMS)• Web Services Profile

Web Services Profile is gebaseerd op:

• SOAP 1.1, een XML-envelop om HL7v3-berichten over HTTP te kunnenversturen,

• WSDL 1.1, een XML-definitietaal om de web services te definiëren, zodanigdat de benodigde software met geschikte gereedschappen deels automatischontwikkeld kan worden,

• WS-I Basic Profile 1.0, een verzameling richtlijnen voor het gebruik vanSOAP en WSDL.


[B71] Voor het transport van HL7v3-berichten wordt gekozen voor Web ServicesProfile, wegens de mogelijkheden voor de beveiliging van berichten en debeschikbaarheid van gereedschappen voor softwareontwikkeling.

[B72] Voor het transport van HL7v3-berichten wordt verder gekozen voor deUnicode-tekenset en UTF-8 codering.

[B73] Er wordt geen SOAP-header gebruikt, omdat HL7v3 van zichzelf debenodigde betrouwbaarheid geeft.

De onderstaande figuur toont hoe een HL7-bericht wordt ingepakt in een SOAP-envelop.

HTTP header

SOAP envelope

SOAP header

SOAP body

HL7v3message


Voor de manier waarop een HL7-interactie wordt gebonden op een HTTP/SOAP-interactie zijn er enkele keuzes te maken. Die keuzes worden ingeleid in denavolgende paragrafen en verder uitgewerkt in de [HL7v3 WSP].

Opmerkingen:

• De keuze voor Web Services Profile is in 2003 gemaakt, omdat groteAmerikaanse softwareleveranciers zich toen richtten op WS-I ten koste vanebXML en omdat ebMS verregaande SOAP-functies bood, die overlappenmet de transportfuncties die HL7v3 reeds bood.

• In principe zullen alle GBZ’en voor een bepaalde HL7-interactie dezelfdeWSDL hebben, behalve de URI. De ZIM-beheerder kan ieder kandidaat-GBZeen WSDL-template toesturen, die na invulling van de URI kan wordenteruggestuurd als onderdeel van het contract. Publicatie van de WSDL in eenUDDI is niet nodig, omdat alle GBZ’en uitsluitend via de ZIM communicerenmet andere systemen. De ZIM houdt bij welke HL7-interacties ieder GBZondersteunt.

• Bijlage D probeert op vereenvoudigde wijze inzichtelijk te maken hoe HL7v3,SOAP en HTTP zich tot elkaar verhouden in de concrete gevallen vanopvragen en versturen van patiëntgegevens.



Als gevolg van de ontwerpbeslissingen in paragraaf 5.3.2, zal één HL7-opvraagaltijd leiden tot één HL7-oplevering (al of niet gebundeld). Dit biedt dekeuzevrijheid om deze interactie te binden op één paar van HTTP/SOAP-request enHTTP/SOAP-respons (enkelvoudige binding), zie onderstaande figuur,


: GBZx:gegevens

houder

:ZIM

HTTP req (SOAP req (HL7 query req))

HTTP rsp (SOAP rsp (HL7 query rsp))





opvraag

of op afzonderlijke paren (Tweevoudige binding), zie onderstaande figuur.


: GBZx:gegevens

houder

:ZIM


HTTP req (SOAP req (HL7 query rsp))

HTTP rsp (status)

HTTP req (SOAP req (HL7 query rsp))


HTTP rsp (status)

HTTP rsp (status)

HTTP rsp (status)



opvraag

Voordeel van de enkelvoudige binding is het zuinigere gebruik van systeem- ennetwerk-capaciteit, doordat de helft van het aantal HTTP-berichten wordtuitgewisseld, met vermoedelijk een snellere responstijd als resultaat. Eenogenschijnlijk nadeel van de enkelvoudige binding is dat de afhandeling van deopvraagsessie minder betrouwbaar is.

Echter, anders dan bij het versturen heeft het opvragen minder betrouwbaarheidnodig, zolang de gegevensopvrager duidelijkheid krijgt dat tijdens de opvraagsessieiets misgegaan is. Evenzo hoeft een HL7-opvraagbericht nooit persistent gemaakt


te worden, zolang de gegevensopvrager maar wordt geïnformeerd indien eenopvraagsessie wordt onderbroken. Hij kan dan beter opnieuw de opvraag doen.

Immers, als de gegevensopvrager merkt dat hij niet alle antwoorden heeftontvangen, kan hij de gewenste gegevens gewoon opnieuw opvragen. Nadeeldaarvan is de ondoelmatige belasting van de ZIM en de opleverende GBZ’en. Stel,de ZIM heeft tijdens een opvraagsessie alle antwoorden verzameld uit deopleverende GBZ’en. Vervolgens gaat er iets mis bij het afleveren van dezeantwoorden aan het opvragende GBZ. Als de gegevensopvrager besluit deopvraagsessie te annuleren en opnieuw dezelfde gegevens op te vragen, moet deZIM gegevens opvragen die hij reeds had klaar staan!

Omdat het beter is de reguliere gevallen te optimaliseren dan de uitzonderings-gevallen, heeft naar de huidige inzichten de enkelvoudige binding de voorkeur.


[B74] Voor het interactiemechanisme indirect opvragen wordt een HL7-opvraagen bijbehorende HL7-oplevering enkelvoudig gebonden op één paar vanHTTP/SOAP-request en HTTP/SOAP-response.



Als gevolg van de ontwerpbeslissingen in paragraaf zal één HL7-opdracht altijdleiden tot één HL7-bevestiging. Dit biedt de keuzevrijheid om de HL7-opdracht ende HL7-bevestiging te binden op één paar van HTTP/SOAP-request en HTTP/SOAP-respons (enkelvoudige binding), zie onderstaande figuur,

:GBZ1:opdracht

gever

: GBZ2:opdracht

nemer

:ZIM

HTTP req (SOAP req (HL7 order req))

HTTP rsp (SOAP rsp (HL7 accept ack))HTTP rsp (SOAP rsp (HL7 accept ack))



opdracht

of op afzonderlijke paren (tweevoudige binding), zie onderstaande figuur.

:GBZ1:opdracht

gever

: GBZ2:opdracht

nemer

:ZIM


HTTP req (SOAP req (HL7 accept ack))

HTTP rsp (status)

HTTP req (SOAP req (HL7 accept ack))


HTTP rsp (status)HTTP rsp (status)

HTTP rsp (status)


opdracht

In andere gevallen bestaat die keuzevrijheid niet en moet de HL7-interactie altijdworden gebonden op afzonderlijke paren van HTTP/SOAP-request en HTTP/SOAP-respons (tweevoudige binding). Die andere gevallen worden door de ZIMmomenteel niet ondersteund.

Wezenlijk verschil tussen de enkelvoudige en de tweevoudige binding is dat delaatste op HTTP-niveau extra ontvangstbevestigingen toevoegt, met meermogelijkheden voor automatisch hernieuwde pogingen tot versturen. Detweevoudige binding vergt evenwel dat het versturende GBZ niet slechts als HTTP-client maar ook als HTTP-server moet kunnen fungeren. Voor het ontvangende GBZgeldt het omgekeerde.


Uit paragraaf 5.10 over betrouwbaarheid zal blijken:• geen van beide bindingen biedt 100% garantie dat een HL7-opdrachtbericht

precies 1 keer wordt afgeleverd,• met de voorgeschreven foutafhandeling zijn beide bindingen voldoende

betrouwbaar voor het versturen van HL7-opdrachtberichten,• in geval dat de communicatie probleemloos verloopt is de enkelvoudige

binding doelmatiger,• in geval van communicatieproblemen is de tweevoudige binding

doelmatiger,• aldus geeft de tweevoudige binding iets meer betrouwbaarheid, maar wel

tegen de prijs van hogere systeem- en netwerkbelasting.

Het hangt wellicht af van de toepassing en van de betrouwbaarheid van deverbindingen, welke HTTP/SOAP-binding de voorkeur heeft. Voor WEL onmiddellijkafleveren ligt enkelvoudige binding meer voor de hand, voor NIET onmiddellijkafleveren eerder de tweevoudige binding wegens de ruimere mogelijkheden voorautomatisch hernieuwde pogingen, maar die optie wordt momenteel nog nietondersteund.

Omdat het beter is de reguliere gevallen te optimaliseren dan deuitzonderingsgevallen, heeft naar de huidige inzichten de enkelvoudige binding devoorkeur.


[B75] Voor het interactiemechanisme indirect versturen wordt een HL7-opdrachten bijbehorende HL7-bevestiging enkelvoudig gebonden op één paar vanHTTP/SOAP-request en HTTP/SOAP-response.


5.5 Connectiviteit

Voor de HL7-berichtuitwisseling tussen GBZ en ZIM via een DCN is reeds gekozenvoor internetprotocollen: HTTP, TCP, IP, zie [Architectuurontwerp]. Connectiviteitwordt hier uitgewerkt op de volgende niveaus:

• netwerkniveau: IP-koppelingen tussen een GBZ en de ZIM, tussen GBZ’enbuiten de ZIM om, resp. tussen een GBZ en de CA’s.

• applicatieniveau: aansluitingen van specifieke applicaties binnen een GBZ opspecifieke schakelpunten binnen de ZIM.

5.5.1 IP-koppeling tussen GBZ en ZIM

Ieder GBZ wordt via een DCN aangesloten op de ZIM en krijgt daartoe een IP-adrestoegekend door de ZSP die dat DCN beheert. Iedere ZSP krijgt daartoe een IP-adresreeks van het LSP toegewezen. Een GBZ kan op diens interne netwerk veleandere IP-adressen gebruiken of andere netwerkprotocollen en adresseringswijzentoepassen, maar naar het LSP moet het GBZ zich altijd manifesteren met hettoegekende IP-adres. In dergelijke gevallen zal het GBZ op het koppelvlak met hetDCN een adresconversie moeten uitvoeren die overeenkomt met de eigen netwerk-protocollen en adresseringswijzen. Afhankelijk van de netwerkinrichting kunnensommige GBZ’en volstaan met een vorm van netwerkadresvertaling (NAT), al ofniet gecombineerd met een vorm van tunneling, zie de onderstaande figuur.

Ook ZSP’s kunnen op hun DCN andere netwerkprotocollen en adresseringswijzentoepassen. In dat geval zal de ZSP een dergelijke adresconversie moeten uitvoerenop het koppelvlak met het LSP en misschien ook op de koppelvlakken met deaangesloten GBZ’en.

ZIM

ZSP

GBZ GBZ GBZ GBZ

DCN DCN

GBZ GBZ

ZSP

LSP

NAT NAT NAT NAT

primDNS

primDNS

secndDNS

NAT


Daarnaast moet ieder GBZ een hostnaam hebben, opdat de ZSP netwerk-aansluitingen kan onderhouden zonder dat andere partijen hoeven te wordeningelicht als een IP-adres is gewijzigd. Deze hostnamen kunnen worden gebruiktdoor systemen die met het GBZ communiceren: de ZIM, maar ook andere GBZ’endie rechtstreeks met deze GBZ willen communiceren, zie paragraaf 5.5.3. In deconfiguratietabel van de ZIM kan van iedere GBZ de URI worden vastgelegd, zieparagraaf 4.2.17 eis (p). Bovendien kunnen de hostnamen worden vermeld in deURI op de UZI-servicescertificaten van die systemen en kunnen ze worden verwerktin de webservice-namen.

Om hostnamen te kunnen vertalen naar IP-adressen is een DNS-dienst nodig. Dezezou zowel door het LSP als door iedere ZSP afzonderlijk kunnen worden geleverd.De laatste optie betekent een DNS-server met bijbehorende beheerinspanning perZSP, maar heeft toch de voorkeur wegens de betere flexibiliteit en onderhoud-baarheid van hostnamen. Om ZSP’s niet onnodig op kosten te jagen, kan het LSPten behoeve van de beschikbaarheid een gemeenschappelijke secundaire DNS-server inrichten voor alle primaire DNS-servers, zie de bovenstaande figuur.

In geval van een ASP die meerdere zorgaanbieders bedient, zie paragraaf 5.6.6,zullen de afzonderlijke domeinen per zorgaanbieder ieder een eigen hostnaamkunnen krijgen, opdat zij afzonderlijk als GBZ kunnen worden geadresseerd engeconfigureerd in de ZIM.

Zoals beschreven in paragraaf 5.7, komt er een operationele ZIM, een uitwijk-ZIMen een test-ZIM. Een GBZ moet van elk de hostnaam geconfigureerd hebben,want:

• een GBZ moet zonodig snel kunnen overschakelen van de operationele ZIMnaar de uitwijk-ZIM, zie ook openstaande punt in paragraaf 5.5.2,

• een GBZ kan meerdere applicaties bevatten waarvan de ene reedsoperationeel is en de andere nog wordt getest.

Iedere ZIM zal in principe alle operationele GBZ’en hebben geconfigureerd. De test-ZIM zal daarnaast ook zorgsystemen hebben geconfigureerd die nog bezig zijn eenGBZ-status te verkrijgen.

Iedere ZIM kan een geconfigureerde GBZ daarnaast openstellen of blokkeren. Zokan een zorgsysteem dat zijn GBZ-status verliest, bijv. wegens ernstige gebreken,door de operationele ZIM tijdelijk worden geblokkeerd, zonder de configuratiegeheel te verwijderen.

Openstaande punten:

• Momenteel wordt door NICTIZ onderzocht of ZSP’s naast (of in plaats van)private ook publieke IP-adresreeksen toegewezen kunnen krijgen. Idealiterzou een ZSP zelf mogen kiezen tussen een publieke of private IP-adresreeksten behoeve van de aangesloten of aan te sluiten GBZ’en. Daarvan is ookafhankelijk waar de hostnaam van een GBZ geregistreerd moet worden.


5.5.2 Aansluiting van applicatie op schakelpunt

Een GBZ kan meerdere zorgapplicaties bevatten die afzonderlijk kunnen wordenaangesloten. Iedere applicatie krijgt een applicatie-id toegewezen door het LSP.In geval van een ASP die meerdere zorgaanbieders bedient, zie paragraaf 5.6.6,zullen de afzonderlijke domeinen per zorgaanbieder een eigen applicatie-id krijgen,opdat zij afzonderlijk als GBZ kunnen worden geadresseerd en aangesloten op deZIM.

Evenzo kan een ZIM bestaan uit meerdere schakelpunten, uit oogpunt vanschaalbaarheid, zie paragraaf 5.8. Ook deze schakelpunten krijgen ieder eenapplicatie-id toegewezen.

Aldus wordt iedere zorgapplicatie aangesloten op een schakelpunt, niet alleen vande operationele ZIM, maar ook van de uitwijk-ZIM en test-ZIM. Zo’n aansluitingwordt geconfigureerd door elkaars applicatie-id op te nemen. Afhankelijk van dekoppeltoestand (test, operationeel of uitwijk) van de applicatie, zal het één van deschakelpunten gebruiken voor de uitwisseling van HL7-berichten.

Merk op dat een GBZ meerdere applicaties kan bevatten waarvan de ene reedsoperationeel is en de andere nog wordt getest, zie paragraaf 5.7.2.

De applicatie-id’s worden gebruikt in de Transmission Wrapper van HL7v3-berichtenom afzender en bestemming aan te duiden.

De onderstaande figuur toont de relaties tussen een GBZ met alle zorgapplicatiesen het LSP met de drie ZIM’s en alle schakelpunten in een UML class diagram.

Applicatie

GBZ

*Schakel

punt

ZIM

*

OperationeleZIM

TestZIM

UitwijkZIM

GBZIP-adres

1 heeft koppeling met > 1..3

1 heeft aansluiting met > 1..3

1 wisselt HL7-berichten uit met > 1

ZIMIP-adres

SchakelpuntApplicatie-id

ApplicatieApplicatie-idKoppeltoestand

Openstaande punten:

• In plaats van dat iedere GBZ voor de uitwijk-ZIM een aparte hostnaam enaparte applicatie-id moet bijhouden, naast die van de operationele ZIM, zouhet LSP ook kunnen zorgen voor transparante overschakeling op basis vanéén hostnaam en applicatie-id. Dit wordt nog door NICTIZ onderzocht.


5.5.3 IP-koppeling tussen GBZ’en

Binnen één DCN kunnen de aangesloten GBZ’en ook rechtstreeks gegevensuitwisselen, bijv. multimediale bestanden m.b.v. DICOM. Als GBZ’en op eenverschillend DCN met verschillende VPN-technieken zijn aangesloten, is IP-verkeerniet zo maar mogelijk. Om de zogenaamde interconnectiviteit tussen verschillendeDCN’en mogelijk te maken, heeft het LSP een RouteerFunctie (RF) nodig, zie deonderstaande figuur. Deze RF dient alle DCN’en te koppelen op basis van statischeroutering, met floating static routing voor redundante routes. Op termijn zal de RFnaar verwachting de routeringsprotocollen OSPF en IS-IS dienen te ondersteunen.

ZIM

ZSP

GBZ GBZ GBZ GBZ

DCN DCN

GBZ GBZ

RF

ZSP

LSP

NAT NAT NAT NAT

DNSDNS

DNS

Binnen DCN’s dient gebruik te worden gemaakt van unieke domeinnamen, diepassen in een door ieder ZSP te beheren naamruimte. Daartoe dient een ZSP eenDNS-dienst te leveren aan de op diens DCN’s aangesloten systemen.

Voor tijdsynchronisatie dient het Network Time Protocol (NTP) te worden gebruikt,waarbij de ZIM een NTP-server onderhoudt en de GBZ’en als NTP-clients optreden.


5.5.4 IP-koppeling tussen GBZ en CA’s

Volgens PKI Overheid (PKIO) moet men van andermans PKI-certificaten controlerenof deze niet zijn ingetrokken, door het raadplegen van de CRL die wordtgepubliceerd door de CA die de desbetreffende PKI-certificaten heeft uitgegeven.

Bij de berichtuitwisseling tussen de ZIM en alle aangesloten GBZ’en speelt de ZIMsteeds een centrale rol door de GBZ-gebruikers dan wel hun GBZ te authenticerenaan de hand van UZI-certificaten, zie paragraaf 5.6.1. GBZ’en hoeven dan alleen deZIM te vertrouwen, na authenticatie van de ZIM aan de hand van diens ZIM-certificaat. Dit betekent dat:

• de ZIM regelmatig een CRL moet ophalen van het UZI-register, de CA diealle UZI-certificaten uitgeeft,

• alle aangesloten GBZ’en regelmatig een CRL moet ophalen van de CA die hetZIM-certificaat uitgeeft (momenteel DigiNotar).

Daarnaast zal een GBZ in de volgende gevallen ook een CRL van het UZI-registermoeten ophalen:

• wanneer zorgverleners lokaal inloggen op een GBZ met hun UZI-pas, zoalsonder meer nodig is voor het bijhouden van mandateringen.

• {toekomst} wanneer GBZ'en buiten het LSP om berichten gaan uitwisselen,zoals nodig is voor de overdracht van grote bestanden.

• {toekomst} wanneer GBZ'en straks elektronische handtekeningen gaangebruiken voor ondertekenen van HL7-berichten.

Tenslotte moet de ZIM zowel als een GBZ volgens PKIO ook de PKI-certificaten vandie CA’s controleren op intrekking, door de CRL van hun CA op te halen.

Al deze CA’s publiceren hun CRL op een locatie die bereikbaar is via het publiekeinternet. GBZ’en zijn echter via een privaat DCN van een ZSP gekoppeld aan deZIM en andere GBZ’en. Dus zou iedere GBZ of iedere ZSP ook nog een eigenopening naar het publieke internet moeten maken. Dit vereist de nodigeinvesteringen in de beveiliging: firewall, intrusion detection, etc.

Om te voorkomen dat iedere GBZ of iedere ZSP op kosten wordt gejaagd, is hetvoorlopig beter dat de RouteerFunctie (RF) van het LSP een gemeenschappelijke,centrale opening biedt voor alle op de ZIM aangesloten GBZ’en. De ZIM heeft voortoegang tot de SBV-Z bovendien toch al een IP-koppeling via het publieke internet.

Om te voorkomen dat GBZ’en de opening misbruiken voor willekeurige toegang tothet publieke internet, kan de RF het gebruik beperken tot de genoemde CA’s en hetophalen van een CRL.


[B76] De RouteerFunctie (RF) moet alle op de ZIM aangesloten GBZ’en demogelijkheid bieden om de bovengenoemde CA’s te bereiken voor hetophalen van een CRL.


Opdat een GBZ een LDAP-request naar het UZI-register resp. de CA van hetZIM_certificaat kan sturen, op basis van de URL in een UZI-certificaat resp. ZIM-certificaat, is het nodig dat de DNS-servers van de ZSP’s de URL’s van de CA’svertalen naar een privaat IP-adres dat vervolgens door de RF door middel van NATvertaald kan worden naar een IP-adres op het publieke internet.

Tenslotte moet de RF bij die NAT-vertaling ervoor zorgen dat de LDAP-responseweer netjes terugkomt bij de oorspronkelijke GBZ, zie de onderstaande figuur.

ZIM

ZSP

SBV-ZUZIregister

GBZ GBZ GBZ GBZ

DCN DCN

GBZ GBZ

RF

Publieke internet

ZSP

LSP

CIBG

NAT NAT NAT NAT

DNS

CAregister

CA

DNS

DNS

NAT

Mocht op termijn blijken dat de capaciteit die de RF hiervoor kan bieden te klein is,dan kunnen ZSP’s wellicht in de toekomst aanvullende capaciteit bieden door ookeen opening naar de CA’s via het publieke internet te bieden, voorzover zij dat nietreeds doen.


5.6 Beveiliging

5.6.1 Inleiding

Voor de beveiliging van de landelijke uitwisseling van patiëntgegevens zijn devolgende zaken van belang:

• beveiliging tussen GBZ-gebruikers en de ZIM,• beveiliging tussen GBZ-dossiers/postbussen en de ZIM,• beveiliging tussen GBZ-applicaties en de ZIM,• beveiliging tussen registers en de ZIM,• interne beveiliging GBZ, inclusief lokaal inloggen,• interne beveiliging ZIM.

Voor de beveiliging van de communicatie tusen GBZ en ZIM is reeds een aantalkeuzes gemaakt, zie [Architectuurontwerp]:

• als vertrouwensmiddel maken zorgverleners en hun systemen gebruik vanUZI-passen respectievelijk UZI-servicescertificaten.

• De uitwisseling van patiëntgegevens tussen systemen wordt beveiligd optransportniveau met SSL/TLS en VPN en in de toekomst op berichtniveaumet XML-encryption en XML-signature.

• De toegang van personen tot patiëntgegevens wordt beveiligd op persoonlijkniveau met hard-tokens, uitgegeven volgens PKI.

Zoals beschreven in paragraaf 3.9.6, kunnen deze verschillende technieken wordengeprojecteerd op de volgende vertrouwensniveaus, zoals vereist voor de landelijkeuitwisseling van patiëntgegevens, afhankelijk van de gegevenssoort, zie paragraaf4.2.12:

• {toekomst} voor vertrouwensniveau hoog: versleuteling en elektronischehandtekening op berichtniveau via XML-encryption en XML-signature, metbehulp van de sleutels van persoonlijke UZI-passen.

• voor vertrouwensniveau midden: versleuteling en authenticatie optransportniveau via SSL/TLS, met behulp van de sleutels van persoonlijkeUZI-passen en/of UZI-servicescertificaten.

• voor vertrouwensniveau laag: versleuteling en authenticatie opnetwerkniveau door aansluiting van het GBZ op een VPN met bijv. IPsec ofSSL met behulp van de sleutels van UZI-servicescertificaten.

Bijlage F geeft een uitwerking van hoe deze technieken kunnen worden ingezet inde verschillende scenario’s op de verschillende vertrouwensniveaus.

Op vertrouwensniveau midden speelt de ZIM een centrale rol bij de authenticatievan zorgverleners, medewerkers en hun systemen. Immers, de ZIM authenticeertzelfstandig alle aangesloten partijen op persoonlijk niveau, waardoor deaangesloten partijen elkaar onderling niet hoeven te authenticeren. Daarbij is hetbelangrijk dat de ZIM zichzelf kan authenticeren aan de aangesloten partijen, meteen systeemgebonden vertrouwensmiddel uitgegeven door een CA conform de


richtlijnen van PKI-Overheid. Dit komt neer op een servicescertificaat, dat gezien detoepassing ook wel SSL-certificaat wordt genoemd.

De onderstaande figuur toont hoe dit vertrouwensniveau midden wordt gerealiseerdbij het opvragen en versturen van patiëntgegevens, doordat de ZIM de geheleketen bewaakt van GBZ-gebruiker via de ZIM naar de GBZ-applicatie die dedossiers en postbussen ontsluit. Dit is nodig voor de volgende gebruiksscenario’svan een zorgverlener:

• gebruiksscenario 1.1: publiceren patiëntgegevens,• gebruiksscenario 2.1: opvragen patiëntgegevens,• gebruiksscenario 2.2: versturen patiëntgegevens,• gebruiksscenario 2.3: overdragen patiëntgegevens,

In deze keten zijn de volgende verschillende schakels te herkennen, die afzonderlijkworden uitgewerkt in de volgende paragrafen:

• beveiliging tussen GBZ-gebruikers en ZIM,• beveiliging tussen GBZ-dossiers/postbussen en ZIM.

Zorgaanbieder

Zorgaanbieder

LSP

GBZ-platform ZIM-platform

schakelpuntZorg

verlener

GBZ-platform

applicatieapplicatie

dossier`postbusUZI-

paslezerUZI-pas SSL-cert UZI-cert

SSL-verbinding SSL-verbinding

HL7-verzoekbericht

HL7-verzoekbericht

HL7-antwoordbericht

HL7-antwoordbericht

Om de keten gesloten te houden, moet worden voorkomen dat patiëntgegevens dieverkregen zijn door landelijk uitwisseling, vervolgens lokaal te gemakkelijkbenaderd kunnen worden. Ook de toegang tot lokale tabellen die betrekkinghebben op landelijke uitwisseling zijn gevoelig. Dit betekent dat zorgverleners voorde volgende gebruikscenario’s lokaal moeten inloggen met een UZI-pas:

• gebruiksscenario 1.1: bijhouden patiëntgegevens,• gebruiksscenario 2.2.2: ontvangen patiëntbericht,• gebruiksscenario 4: raadplegen toegangslog,• gebruiksscenario 7: bijhouden mandateringen

De onderstaande figuur toont het lokaal inloggen, dit wordt nader uitgewerkt in eenvolgende paragraaf.


Zorgaanbieder

GBZ-platform

Zorgverlener


dossier`postbusUZI-

paslezerUZI-pas UZI-cert

applicatie

In principe staat lokaal inloggen op een zorgapplicatie los van het inloggen op deZIM. Technisch gezien kunnen deze twee vormen van inloggen wordengecombineerd tot één gebruikershandeling. Maar dat is niet altijd verstandigwegens de korte time out op de gebruikerssessie met de ZIM, zie volgendeparagraaf. Beter is het om een gebruiker eerst te laten inloggen op dezorgapplicatie voor zijn reguliere werkzaamheden. Daarbovenop kan hij nog eensinloggen op de ZIM voor de tijd dat dit nodig is. Een gebruiker hoeft dit niet teervaren als inloggen, maar als een verzoek om zich opnieuw te authenticeren.

Op vertrouwensniveau laag wordt de authenticatie van afzonderlijke zorgverlenersen medewerkers overgelaten aan ieder GBZ. De rol van de ZIM beperkt zich dan totde authenticatie van ieder GBZ, dus op instellingsniveau.

De onderstaande figuur toont hoe dit vertrouwensniveau laag wordt gerealiseerd,bij het opvragen van het BSN uit de SBV-Z en bij het opvragen uit dezorgaanbiedergids. De ZIM bewaakt hier slechts een deel van de keten. Dit isvoldoende voor de volgende gebruiksscenario’s van een zorgverlener:

• gebruiksscenario 0.3.1: identificeren patiënt/cliënt,• gebruiksscenario 0.4.1: opzoeken zorgaanbieder in de zorgaanbiedergids,• gebruiksscenario 0.4.2: opvragen bereikbaarheidsgegevens uit de

zorgaanbiedergids.

{toekomst} Dit speelt ook bij de volgende gebruiksscenario’s van een beheerder:• gebruiksscenario 0.1.1: aansluiten applicatie op schakelpunt,• gebruiksscenario 0.1.1: afsluiten applicatie van schakelpunt.

In deze keten zijn de volgende verschillende schakels te herkennen, die afzonderlijkworden uitgewerkt in de volgende paragrafen:

• beveiliging tussen GBZ-applicatie en ZIM,• beveiliging tussen registers en ZIM.


Registerbeheerder

Zorgaanbieder

LSP

GBZ-platform ZIM-platform

schakelpuntZorg

verlener

Register-platform


registerSSL-cert SSL-cert

SSL-verbinding SSL-verbinding

UZI-cert

HL7-verzoekbericht

HL7-verzoekbericht

HL7-antwoordbericht

HL7-antwoordbericht

Om de keten ook hier gesloten te houden, moet worden voorkomen dat eenwillekeurige persoon binnen de zorgaanbieder de registers benadert. Hoe dat wordtgerealiseerd, bijv. met lokaal inloggen met gebruikersnaam/wachtwoord, is deeigen verantwoordelijkheid van de zorgaanbieder.


5.6.2 Beveiliging tussen GBZ-gebruikers en ZIM

Zoals beschreven in paragraaf 4.2.2, moet een zorgverlener verschillendevertrouwensniveaus kunnen halen, afhankelijk van wat vereist is voor degegevenssoort en de interactie die hij daarop wil plegen (zie paragraaf 4.2.12).Daarvoor heeft een zorgverlener een vertrouwensmiddel nodig, dat afhankelijk vande benodigde authenticatiesterkte tenminste aan de volgende eisen moet voldoen:

• voor sterke authenticatie: een hardware-token met toegangscode (PIN), datis uitgegeven door een TTP, conform de richtlijnen van PKI-Overheid. Depersoonlijke UZI-passen die door het UZI-register worden uitgegevenvoldoen hier aan.

• voor normale authenticatie: een hardware-token dat is uitgegeven onderverantwoordelijkheid van de zorginstelling-verantwoordelijke, conform naderte bepalen richtlijnen.

• voor zwakke authenticatie: een wachtwoord dat is uitgegeven onder verant-woordelijkheid van de zorginstelling-verantwoordelijke, conform nader tebepalen richtlijnen.

In de laatste twee gevallen, kan de ZIM niet zelfstandig de gebruiker authenticeren.De ZIM kan dan slechts het GBZ authenticeren, dus op instellingsniveau. Dit wordtbehandeld in paragraaf 5.6.4. Hier wordt alleen het eerste geval behandeld.

Wanneer een zorgverlener inlogt met een UZI-pas om landelijk patiëntgegevens tekunnen uitwisselen, kunnen de zorgverlener en de ZIM elkaar authenticeren metbehulp van SSL/TLS. Na die tweezijdige authenticatie begint een sessie waarbinnenmeerdere SSL-verbindingen kunnen worden opgezet. Voor iedere SSL-verbindingworden tijdelijke sleutels aangemaakt ten behoeve van vertrouwelijkheid enintegriteit van de uitgewisselde berichten. Eventueel kunnen de tijdelijke sleutelsworden ververst.

Voor iedere afzonderlijke GBZ-gebruiker wordt een aparte SSL-sessie opgezet vanafhet GBZ naar de ZIM op basis van de persoonlijke UZI-pas, zoals de onderstaandefiguur toont in geval van een client/server-gebaseerde GBZ-applicatie. De figuurtoont daarbij een applicatie met een thin client, waarbij de HL7-berichten op deserver worden aangemaakt en aldaar een SSL-sessie wordt gestart, waarbij dejuiste UZI-pas op de client wordt aangesproken door middel van authenticationforwarding.

Niet getoond in de figuur is dat binnen één SSL-sessie meerdere SSL-verbindingenkunnen worden gemaakt, bijv. om parallel meerdere HL7-berichten naar de ZIM testuren. Om te voorkomen dat één GBZ-gebruiker op deze wijze teveel SSL-poortenvan het LSP in beslag neemt zal een maximum per GBZ-gebruiker moeten wordengedefinieerd.


Client

ZIM-platform

GBZ


ZIMapplicatie

Server

LSP

Client

Client

clientapplicatie

clientapplicatie

clientapplicatieZorgverlener/

medewerker


SSL-cert

HL7-verzk-brchtHL7-antw-brcht

verzoekantwoord

verzoekantwoord

verzoekantwoord

serverapplicatie

SSL-authenticatie

HL7-vrzk-brchtHL7-antw-brcht

HL7-vrzk-brchtHL7-antw-brcht

UZI-pas

UZI-pas

UZI-paslezer

lezer

lezer

SSL-verbinding

Om te voorkomen dat een ander dan de geauthenticeerde zorgverlener zijn sessiekan overnemen, moet de sessie automatisch en definitief worden beëindigd in devolgende gevallen:

• nadat de GBZ-gebruiker zijn UZI-pas heeft verwijderd,• wanneer de GBZ-gebruiker meer dan 8 uur gebruik maakt van de sessie,

waarbij een eventueel lopende HL7-interactie eerst wordt voltooid, maar eenopvraagsessie bestaande uit meerdere HL7-interacties kan dus wordenafgebroken,

• wanneer de GBZ-gebruiker gedurende 30 minuten geen gebruik heeftgemaakt van de sessie,

• wanneer de GBZ-gebruiker gedurende 15 minuten geen gebruik heeftgemaakt van zijn applicatie.

Omdat de UZI-pas tijdens een SSL/TLS-sessie niet gebruikt wordt, moet het GBZdus frequent controleren of de kaart nog in de kaartlezer zit. Een tijdsinterval van 5minuten maakt mogelijk dat een gebruiker zijn werkplek even kan verlaten en kanterugkeren (desnoods op een andere werkplek) om zijn sessie voort te zetten.

Na afloop van de sessie moet het GBZ alle gebruikte geheimen zorgvuldiguitwissen: de master secret van de SSL/TLS-sessie en de tijdelijke sleutels. De PIN-code van de UZI-pas mag sowieso niet worden bewaard door het GBZ, maar moetna intoetsen door de gebruiker onmiddellijk worden uitgewist.


[B77] Bij inloggen van een GBZ-gebruiker op vertrouwensniveau midden zet hetGBZ een SSL/TLS-sessie op met de ZIM met:• tweezijdige authenticatie tussen persoons-UZI-pas en ZIM-certificaat,• meesturen van certificaten,• 128 bit tijdelijke sleutels die elke 5 minuten ververst worden,• RSA_WITH_RC4_128_MD5 of RSA_WITH_RC4_128_SHA,• maximum sessieduur van 8 uur,• maximum ongebruikte sessie van 30 minuten,• maximum ongebruikte applicatie van 15 minuten,


• {toekomst} nader te bepalen maximum aantal verbindingen.

De bovenstaande tijdsparameters zijn instelbaar door de beheerders. Aldus wordtgedefinieerd:

• gebruiker-max-kaart-uit is de maximum duur dat een vertrouwens-middel van de werkplek verwijderd mag zijn, voordat een SSL/TLS-sessie wordt beëindigd.

• gebruiker-max-sleutel-duur is de maximum duur dat een tijdelijkeSSL/TLS-sleutel gebruikt mag worden, waarna deze ververst moetworden.

• gebruiker-max-sessie-duur is de maximum duur van een SSL/TLS-sessie tussen een gebruiker en de ZIM, voordat de sessie automatischwordt beëindigd.

• gebruiker-max-sessie-onbruik is de maximum duur dat een SSL/TLS-sessie tussen een gebruiker en de ZIM niet gebruikt wordt, voordat desessie automatisch wordt beëindigd.

• gebruiker-max-applicatie-onbruik is de maximum duur dat de applicatiedoor de gebruiker niet gebruikt wordt, voordat de sessie automatischwordt beëindigd.

• {toekomst} gebruiker-max-verbindingen is het maximum aantal SSL-verbindingen dat een GBZ-applicatie per gebruiker gelijktijdig magopzetten naar de ZIM.

Uit oogpunt van zekerheid moet de ZIM alle sessie-time-outs bewaken. De time-outs gebruiker-max-kaart-uit en gebruiker-max-applicatie-onbruik kunnen alleendoor het GBZ worden bewaakt.

Het gebruik van SSL/TLS voor de authenticatie van een zorgverlener met UZI-pasdoor de ZIM, garandeert nog niet dat de berichten die over de SSL/TLS-verbindinggaan, ook daadwerkelijk van die zorgverlener afkomstig zijn resp. bij de bestemdezorgverlener terechtkomen. Er zit immers altijd tenminste één applicatie tussen dieberichten van de ZIM vertaalt naar schermuitvoer (resp. toetsenbord/muis-invoerin combinatie met gegevens uit een dossier of op het scherm vertaalt naarberichten voor de ZIM). Bij de GBZ-keuring is het daarom belangrijk vast te stellenof de applicaties binnen een GBZ alle berichten van/naar de ZIM exclusief koppelenaan invoer van/uitvoer naar de kaartlezer op zijn werkplek waarin de zorgverlenerzijn UZI-pas heeft gestoken.

Wanneer een zorgverlener patiëntgegevens uitwisselt met de ZIM, moet datdaarom altijd geschieden via een GBZ. Dit GBZ moet bovendien van zijn eigenzorgaanbieder zijn, om te voorkomen dat bijv. een verzekeringsarts via eenwillekeurig ziekenhuis patiëntgegevens gaat opvragen. Een ander voorbeeld isiemand die is gediplomeerd als zorgverlener, maar werkt voor een zorgaanbieder ineen niet-zorgverlenerfunctie. Deze persoon kan buiten de zorgaanbieder om eenUZI-pas aanvragen en onbedoeld patiëntgegevens opvragen. Dit betekent dat deZIM moet controleren dat de persoonlijke UZI-pas waarmee is ingelogd, dezelfdeUZI-abonnee heeft als het UZI-servicescertificaat behorende bij het GBZ.


Het is verleidelijk te denken dat de ZIM dan ook dat GBZ moet authenticeren aande hand van het UZI-servicescertificaat, omdat een zorgverlener binnen eenzorginstelling niet de controle over het gehele GBZ kan hebben. Zo zou hij perongeluk zijn UZI-pas in een onveilige werkplek kunnen steken, waardoor zijn UZI-pas wordt misbruikt door malafide programmatuur die ongemerkt namens dezezorgverlener allerlei HL7-berichten met de ZIM gaat uitwisselen, zie ook paragraaf5.6.6. Echter, deze zorgverlener is mede verantwoordelijk voor de correcte werkingvan het GBZ en kan deze verantwoordelijkheid niet zo maar afschuiven op deinstelling. Bovendien wordt het UZI-servicescertificaat door de ZIM gebruikt voor deauthenticatie van postbussen en dossiers en niet zozeer een GBZ als technischsysteem, zie paragraaf 5.6.3.

Tenslotte hanteert het UZI-register enkele spelregels die consequenties hebbenvoor zorgaanbieders en hun GBZ:

• Zorgverleners die voor een zorginstelling werken, kunnen ook zelfstandigeen UZI-pas aanvragen. Ook maatschappen binnen een zorginstellingzouden eventueel UZI-passen kunnen aanvragen. Al deze UZI-passen zijnechter niet geschikt voor landelijke uitwisseling van patiëntgegevens via hetGBZ van de zorginstelling, omdat deze passen niet aangeven namens welkezorgaanbieder wordt gewerkt.

• Zorgverleners moeten ervoor tekenen dat zij hun UZI-pas strikt persoonlijkgebruiken. Dit betekent onder meer dat zij hun UZI-pas niet onbeheerd ineen kaartlezer mogen laten zitten. In de praktijk zal het erg verleidelijk zijndat toch te doen. De bovenstaande time-outs zijn bedoeld om dit teontmoedigen.


5.6.3 Beveiliging tussen GBZ-dossiers/postbussen en ZIM

Een dossier of postbus binnen een GBZ dat een HL7-verzoekbericht krijgttoegestuurd door de ZIM moet zich vooraf authenticeren aan de ZIM. Dit is bij eenopvraagbericht belangrijk, omdat de ZIM zekerheid moet hebben dat hetresulterende opleverbericht met patiëntgegevens daadwerkelijk afkomstig zijn hetuit het dossier van de verantwoordelijke zorgaanbieder. Evenzo is dit belangrijk bijeen opdrachtbericht, omdat de ZIM zekerheid moet hebben dat het opdrachtberichtmet de patiëntgegevens daadwerkelijk terecht komen in de postbus van debestemde zorgaanbieder.

Zoals beschreven in paragraaf 4.2.1, moet ook een GBZ (-applicatie) metbijbehorend(e) dossiers en postbussen (dus een GBZ) verschillende vertrouwens-niveaus kunnen halen, afhankelijk van wat vereist is voor de gegevenssoort (zieparagraaf 4.2.12). Daarvoor is een vertrouwensmiddel nodig, dat afhankelijk vande benodigde authenticatiesterkte tenminste aan de volgende eisen moet voldoen:

• voor sterke authenticatie: een hardware-token of versleutelde software-token, dat is geplaatst in een GBZ onder goedkeuring van een TTP, conformde richtlijnen van PKI-Overheid. De UZI-servicescertificaten die door hetUZI-register worden uitgegeven voldoen hier aan.

• voor normale authenticatie: een software-token dat is geplaatst in een GBZonder verantwoordelijkheid van de zorginstelling-verantwoordelijke, conformnader te bepalen richtlijnen.

Zoals beschreven in paragraaf 3.9.2, wordt een UZI-servicescertificaat gebruiktvoor de authenticatie van postbussen en dossiers van een bepaalde zorgaanbiederen niet zozeer diens GBZ als technisch systeem. Dit onderscheid is vooral vanbelang in geval van een ASP die voor meerdere zorgaanbieders werkt, zie ookparagraaf 5.6.6.

Wanneer (een applicatie binnen) een GBZ met een UZI-servicescertificaat aansluitop de ZIM om dossiers en postbussen open te stellen voor landelijke uitwisselingvan patiëntgegevens, kunnen (een applicatie binnen) het GBZ en de ZIM elkaarauthenticeren met behulp van SSL/TLS. Na die tweezijdige authenticatie begint eensessie waarvoor per verbinding tijdelijke sleutels worden aangemaakt ten behoevevan de vertrouwelijkheid en integriteit van de uitgewisselde berichten.

Het is echter de vraag of (een applicatie binnen) een GBZ continu een SSL/TLS-sessie moet openhouden met de ZIM, want het is onvoorspelbaar wanneer de ZIMkomt met HL7-berichten voor het opvragen van patiëntgegevens uit de dossiers,dan wel het versturen van patiëntgegevens naar postbussen. Voor de ZIM zou heteen enorm grote belasting zijn om voor alle aangesloten (applicaties binnen)GBZ’en een SSL/TLS-sessie continu open te houden. Het elke keer opnieuwopzetten van een SSL/TLS-sessie wanneer de ZIM een bericht wil sturen naar eenGBZ, gaat daarentegen ten koste van de responstijd van met name een opvraagvan patiëntgegevens.

Als compromis kan de ZIM een opgezette SSL/TLS-sessie open houden zolang deZIM nog meer berichten van of voor (die applicatie binnen) het GBZ verwacht, meteen maximum van bijvoorbeeld 8 uur. Deze maximumduur kan later op basis vanervaringscijfers worden geoptimaliseerd per (applicatie binnen een) GBZ. Tijdensdeze sessie kunnen de tijdelijke sleutels met enige regelmaat worden ververst. Ook


kunnen tijdens deze sessie meerdere SSL-verbindingen worden opgezet, zoalsnodig is wanneer de ZIM meerdere HL7-interacties parallel wil afhandelen metéénzelfde (applicatie binnen een) GBZ. Zie de onderstaande figuur. Het is teveelgevraagd van een GBZ om rekening te houden met het maximum aantal SSL-verbindingen dat de ZIM ooit zou willen opzetten met één GBZ. Daarom wordt perGBZ-applicatie een maximum aangehouden.

ZIM-platform

GBZ

ZIMapplicatie

GBZ-platform

LSP

UZI-certSSL-cert

applicatie

HL7-verzoek-berichtHL7-antwoord-bericht

SSL-authenticatieSSL-verbinding

dossier`postbus



De eerste keer aansluiten van (een applicatie binnen) een GBZ op de ZIM geschiedtop initiatief van de eerste, omdat alleen de GBZ-beheerder precies weet wanneer(een applicatie binnen) het GBZ gereed is voor aansluiting, zie paragraaf 5.6.4.Navolgende, reguliere aansluitingen geschieden echter op initiatief van de ZIM,omdat alleen de ZIM weet wanneer er HL7-berichten klaarstaan voor het opvragenvan patiëntgegevens uit de dossiers, dan wel het versturen van patiëntgegevensnaar de postbussen.


[B78] Wanneer de ZIM een bericht wil sturen naar (een applicatie binnen) eenGBZ op vertrouwensniveau midden, zet de ZIM eerst een SSL/TLS-sessieop met:• tweezijdige authenticatie tussen UZI-servicescertificaat en ZIM-

certificaat,• meesturen van certificaten,• 128 bit tijdelijke sleutels die elke 5 minuten ververst worden,• RSA_WITH_RC4_128_MD5 of RSA_WITH_RC4_128_SHA,• maximum sessieduur van 8 uur,• maximum ongebruikte sessie van 1 kwartier,• {toekomst} nader te bepalen maximum aantal verbindingen.


• systeem-max-sleutel-duur is de maximum duur dat een tijdelijkeSSL/TLS-sleutel gebruikt mag worden, waarna deze ververst moetworden.


• systeem-max-sessie-duur is de maximum duur van een SSL/TLS-sessietussen dossier/postbus en ZIM, voordat de sessie automatisch wordtbeëindigd.

• systeem-max-sessie-onbruik is de maximum duur dat een SSL/TLS-sessie tussen dossier/postbus en ZIM niet gebruikt wordt, voordat desessie automatisch wordt beëindigd.

• {toekomst} systeem-max-verbindingen is het maximum aantal SSL-verbindingen dat de ZIM gelijktijdig mag opzetten naar één GBZ-applicatie.

Het gebruik van SSL/TLS voor de authenticatie van een GBZ met UZI-servicescertificaat door de ZIM, garandeert nog niet dat de berichten die over deSSL/TLS-verbinding gaan, ook daadwerkelijk van de bevraagde zorgverlenerafkomstig zijn respectievelijk bij de bestemde zorgverlener terechtkomen. Er zittenimmers altijd tenminste één applicatie en één dossier dan wel een postbus tussen,die zijn opengesteld namens de verantwoordelijke zorgverlener, die niet altijdaanwezig is. Bij de GBZ-keuring is het daarom belangrijk vast te stellen of deapplicaties binnen een GBZ alle berichten van/naar de ZIM exclusief koppelen aande dossiers resp. postbussen van de zorgverlener, dan wel zorginstelling-afdeling.

Tenslotte hanteert het UZI-register enkele spelregels die consequenties hebbenvoor zorgaanbieders en hun GBZ:

• Een UZI-abonnee kan meerdere UZI-servicescertificaten aanvragen, bijv.voor (de applicaties met bijbehorende dossiers en postbussen van) deverschillende afdelingen van een ziekenhuis. Het UZI-register kan voor UZI-passen en UZI-servicescertificaten wel afdelingsgegevens (i.e.‘Organisational Unit Name’) opnemen, maar kan die gegevens nietcontroleren (en dus niet de juistheid ervan garanderen). Dit betekent dat bijde keuring van een GBZ moet worden gecontroleerd of de UZI-servicescertificatenzijn gekoppeld aan de juiste applicaties, alvorens debijbehorende applicatie-id’s worden vermeld in de zorgaanbiedergids.

• UZI-certificaten zijn 3 jaar geldig. Bij de uitgifte van een nieuwe persoonlijkeUZI-pas kan het oorspronkelijke UZI-nummer behouden blijven. Bij deuitgifte van een nieuw UZI-servicescertificaat kan dat niet. Dit betekent datde systeembeheerder van het LSP moet worden ingelicht wanneer een reedsaangesloten GBZ een nieuw UZI-servicescertificaat krijgt.


5.6.4 Beveiliging tussen GBZ-applicatie en ZIM

Zonder gebruik van de UZI-pas, zie paragraaf 5.6.2, kan de ZIM slechts het GBZauthenticeren, op basis van een UZI-servicescertificaat, dus op instellingsniveau.Dit is ook voldoende voor het opvragen van het BSN of het raadplegen van dezorgaanbiedergids. Immers, de SBV-Z volstaat ook met authenticatie op basis vaneen UZI-servicescertificaat.

Voordeel daarvan is het gebruiksgemak, want de gebruiker hoeft zich niet voorafmet een persoonlijke UZI-pas te authenticeren. Ander voordeel is bijv. datziekenhuizen voor hun baliepersoneel geen UZI-pas hoeven aan te vragen. Andereconsequenties zijn:

• dat iedere persoon binnen die zorgaanbieder het BSN mag opvragen enverifiëren, tenzij dit door de zorgaanbieder zelf is ingeperkt,

• dat een GBZ ook automatisch BSN’s kan gaan opvragen of verifiëren, bijv.op basis van een behandelagenda of vlak voordat alle facturen uitgaan,

• dat autorisatie en mandatering niet zinvol zijn om toe te passen door de ZIMop BSN-opvraagberichten,

• dat een patiënt uit de toegangslog van de ZIM alleen met zekerheid kanachterhalen vanuit welke zorgaanbieder zijn BSN is opgevraagd ofgeverifieerd, maar nooit met zekerheid welke persoon dat heeft gedaan.

Ook in het geval van meerdere, gelijktijdige GBZ-gebruikers wordt één SSL-sessieopgezet vanaf het GBZ naar de ZIM op basis van het UZI-servicescertificaat. Binnendie SSL-sessie kunnen vervolgens meerdere SSL-verbindingen worden gemaakt,één afzonderlijke verbinding voor iedere opvraag zie de onderstaande figuur.

Client

ZIM-platform

GBZ


ZIMapplicatie

Server

LSP

Client

Client

clientapplicatie

clientapplicatie

clientapplicatieZorgverlener/

medewerker


UZI-cert SSL-cert

opvraagantwoord

opvraagantwoord

opvraagantwoord

serverapplicatie

HL7-opvrg-brchtHL7-antw-brcht



SSL-authenticatieSSL-verbinding

Bijkomend voordeel van deze situatie boven die van paragraaf 5.6.2, is de snellereresponstijd, want de tijdrovende authenticatie geschiedt alleen bij het opzetten vande SSL-sessie. Het maken van een SSL-verbinding gaat aanmerkelijk sneller. Als deserver een pool van SSL-verbindingen in stand houdt, kan bij frequent BSNopvragen de gemiddelde responstijd nog sneller worden.


Merk op dat het bestandsgewijs opvragen of verifiëren van BSN’s hier niet speelt,omdat de ZIM dat überhaupt niet ondersteunt. Interessant wordt het wel, als eenGBZ berichtsgewijs via de ZIM de initiële koppeling gaat doen voor een groot aantalpatiënten tegelijk. Dan krijg je de situatie dat voor één gebruiker alle HL7v3-opvraagberichten serieel over één SSL-verbinding of parallel over meerdere SSL-verbindingen geperst zullen worden. Dit speelt ook bij automatische opvragen opbasis van een agenda of in het kader van facturering. Om te voorkomen dat éénGBZ op deze wijze teveel SSL-poorten van het LSP in beslag neemt zal eenmaximum per GBZ moeten worden gedefinieerd.


[B79] Wanneer een GBZ-applicatie een bericht wil sturen naar de ZIM opvertrouwensniveau laag, zet het GBZ een SSL/TLS-sessie op met:• tweezijdige authenticatie tussen UZI-servicescertificaat en ZIM-

certificaat,• meesturen van certificaten,• RSA_WITH_RC4_128_MD5 of RSA_WITH_RC4_128_SHA,• 128 bit tijdelijke sleutels die elke 5 minuten ververst worden,• maximum sessieduur van 8 uur,• maximum ongebruikte sessie van 1 kwartier,• {toekomst} nader te bepalen maximum aantal verbindingen.


• applicatie-max-sleutel-duur is de maximum duur dat een tijdelijkeSSL/TLS-sleutel gebruikt mag worden, waarna deze ververst moetworden.

• applicatie-max-sessie-duur is de maximum duur van een SSL/TLS-sessie tussen GBZ-applicatie en ZIM, voordat de sessie automatischwordt beëindigd.

• applicatie-max-sessie-onbruik is de maximum duur dat een SSL/TLS-sessie tussen GBZ-applicatie en ZIM niet gebruikt wordt, voordat desessie automatisch wordt beëindigd.

• {toekomst} applicatie-max-sessie-verbindingen is het maximum aantalSSL-verbindingen dat een GBZ-applicatie gelijktijdig mag opzetten naarde ZIM.

In theorie zijn er nog mogelijkheden om het aantal gelijktijdig openstaande SSL-verbindingen te beperken tot 1 of 2. Deze oplossingen zijn echter ingewikkelder enworden pas interessant als blijkt dat de GBZ’en het met de bovenstaande oplossingniet redden qua responstijd en capaciteit.

5.6.5 Beveiliging tussen registers en ZIM

De ZIM wisselt identificerende gegevens van patiënten/cliënten uit met de SBV-Z.De beveiliging van die gegevensstroom valt onder verantwoordelijkheid van SBV-Z.


De ZIM vraagt daarnaast certificaten en lijsten van ingetrokken certificaten vanzorgverleners en hun systemen op bij het UZI-register. De beveiliging van diegegevensstroom valt onder verantwoordelijkheid van het UZI-register.

Openstaande punten:

• Voor de aansluiting van de ZIM op de SBV-Z wordt in principe ook SSL/TLSgebruikt, zie [BSN], maar gezien het intensieve berichtenverkeer zou eenalternatief in de vorm van een VPN-verbinding zonder SSL/TLS teoverwegen zijn.

5.6.6 Interne beveiliging GBZ

De interne beveiliging van een GBZ is hier van belang, voor zover het de landelijkeuitwisseling van patiëntgegevens betreft. Het is moeilijk hieraan algemene eisen testellen, omdat de situatie per zorgaanbieder enorm kan verschillen.

Vanuit het vertrouwensmodel gezien is een GBZ idealiter een gesloten systeem datslechts openingen biedt aan gebruikers met UZI-passen en aan de ZIM. Bij eenzorgaanbieder met meerdere medewerkers is echter al gauw sprake van eengedistribueerd zorgsysteem met clients op de werkplek en servers in een aparteruimte. In de praktijk zijn de clients vaak zodanig open, dat gemakkelijk nieuweprogrammatuur kan worden geladen met een CD of via een USB-poort. Als eenzorgverlener zijn UZI-pas invoert op zo’n client, bestaat het risico dat malafideprogrammatuur ongemerkt HL7-berichten probeert te versturen naar de ZIM. Het isde verantwoordelijkheid van de zorgaanbieder om een GBZ zodanig gesloten tehouden dat dit niet kan gebeuren. Dit betekent niet dat elke werkplek binnen dezorgaanbieder beveiligd moet worden, maar wel de werkplekken van waarpatiëntgegevens landelijk worden uitgewisseld .

Bij een grote zorgaanbieder kan verder spelen dat sommige afdelingen meedoenmet landelijke uitwisseling via de ZIM, terwijl andere afdelingen daar voorlopig nogniet aan toe zijn. Daarom moet iedere zorgaanbieder met een GBZ zèlf bepalen hoede grenzen van dat GBZ lopen door de eigen ICT-voorzieningen, zèlf analyserenwanneer patiëntgegevens die grenzen kunnen passeren en zèlf waarborgen dat ditom betrouwbare bestemmingen en bronnen gaat. Zo kunnen werkplekken voorzorgverleners tot het GBZ worden gerekend, terwijl werkplekken vooradministratief personeel daarbuiten vallen.

Daarbij gaat het niet altijd alleen om ICT-voorzieningen binnen de zorgaanbieder.Wanneer een zorgaanbieder reeds patiëntgegevens uitwisselt met anderezorgaanbieders, bijv. via regionale voorzieningen, bestaat het risico datpatiëntgegevens die netjes via de ZIM zijn verkregen, onbedoeld bij anderezorgaanbieders terechtkomen. Daarom zal per zorgtoepassing ernaar gestreefdmoeten worden alle uitwisseling van patiëntgegevens landelijk via de ZIM te latenverlopen. Alleen tijdens de migratie kan eventueel tijdelijk worden toegestaandaarnaast ook via regionale voorzieningen uit te wisselen.

In geval van een ASP die meerdere zorgaanbieders bedient, zal het ASP-systeemlogisch moeten worden opgedeeld in afzonderlijke domeinen per zorgaanbiederwaarbinnen zijn postbus en dossiers met patiëntgegevens zich bevinden, zodanigdat andere zorgaanbieders daar niet zo maar bij kunnen. Voor zover de uitwisseling


tussen verschillende zorgaanbieders niet via de ZIM verloopt, zal een lokaalautorisatieprotocol gehanteerd moeten worden.

Ook in geval van een ASP moet iedere zorgaanbieder een eigen UZI-services-certificaat aanvragen. Door deze vervolgens te (laten) plaatsen in het ASP-systeem,geeft de zorgaanbieder dus te kennen dit ASP-systeem als beheerder van zijnpostbus en dossiers met patiëntgegevens te beschouwen.

Voor het overige is de interne beveiliging vooral een zaak voor de zorgaanbiederzelf, hoewel de NEN 7510 naar verwachting algemeen verplicht zal worden,ongeacht of de zorgaanbieder deelneemt aan landelijke uitwisseling vanpatiëntgegevens. Zo verplicht de NEN 7510 een zorgaanbieder tot een risico-analyse op alle externe verbindingen en maatregelen voor alle risico’s. Op dezewijze kan voorkomen worden dat een GBZ voldoet aan de GBZ-eisen terwijl deveiligheid wordt ondermijnd door een aspect dat niet expliciet door de GBZ-eisenwordt afgedekt.

5.6.7 Interne beveiliging ZIM

De interne beveiliging van de ZIM is van groot belang omdat in principe allelandelijk uitgewisselde patiëntgegevens via de ZIM lopen. Echter, de ZIM is slechtseen schakelpunt voor gegevensstromen. De ZIM kijkt in principe niet in de HL7Payload met patiëntgegevens van de uitgewisselde HL7-berichten. De ZIM kijkt welin de HL7 Transport Wrapper en de HL7 Control Act Wrapper, maar die bevattengeen patiëntgegevens. Daarmee is de interne beveiliging van de ZIM vooral eenzaak van fysieke toegangscontrole, betrouwbare beheerprocedures, betrouwbaarpersoneel, etc.


5.7 Beschikbaarheid

Zorgverleners moeten in principe 7 dagen per week en 24 uur per dag patiënt-gegevens kunnen opvragen en versturen. Dit stelt hoge eisen aan de basis-infrastructuur, maar ook aan de aangesloten GBZ’en en hun DCN’en. Immers, alséén GBZ patiëntgegevens opvraagt die verspreid liggen bij andere GBZ’en, moetendie andere GBZ’en ook beschikbaar en bereikbaar zijn.

5.7.1 Beschikbaarheid van een GBZ

Het is echter onvermijdelijk dat applicaties of hele GBZ’en uitvallen als gevolg vanonvoorziene storingen. Ook moet het mogelijk zijn applicaties tijdelijk uit de luchtte halen voor onderhoud. Deze tijdintervallen van niet beschikbaar zijn, moeten uitoogpunt van de gebruikers zo kort mogelijk gehouden worden. Uit oogpunt vankosten moet echter voorkomen worden dat te strenge eisen worden gesteld.

Een redelijk compromis tussen kosten en bruikbaarheid lijkt een gemiddeldestoringstijd (MTTR) van maximaal 15 minuten. Immers, als een of meer applicatiesuitvallen, bijv. door vastlopende programmatuur, is het meestal mogelijk dezeapplicaties binnen een kwartier weer op te starten.

Een kwartier is ook een tijdsinterval dat kan worden uitgelegd aan een gebruiker:als het opvragen of versturen van patiëntgegevens mislukt doordat de ZIM of eenGBZ uit de lucht is, kan men na een kwartier weer proberen met een redelijkewaarschijnlijkheid dat het dan wel lukt.

Niet uitgesloten kan worden dat een GBZ-platform zodanig defect raakt dat nieuweonderdelen nodig zijn of dat het GBZ op een ander PC-platform moet wordenovergezet. Dit vergt gauw een dag werk. Bovenstaande eisen aan een GBZ vergenwel professioneel beheer van het GBZ om binnen een kwartier een beheerder tekunnen waarschuwen en het GBZ weer op te starten. Voor de nachtelijke uren isdie eis te streng, maar dan is de kans dat een GBZ uitvalt ook kleiner.

Behalve de beschikbaarheid van de functies, is ook de beschikbaarheid van devastgelegde patiëntgegevens belangrijk. Het dagelijks maken van een back-up isonder professionele beheerders gebruikelijk. Back-ups moeten op een veilige plaatsworden opgeborgen.

Tenslotte moet gepland onderhoud kunnen plaatsvinden, bij voorkeur in de rustigeuren. Indien tijdig aangekondigd, kunnen gebruikers en beheerders daarmeerekening houden.


[B80] Een GBZ vergt professioneel beheer om het GBZ continu te bewaken enom kleine storingen binnen 15 minuten en grote storingen binnen 1 dag teherstellen en dagelijks een back-up te maken.


5.7.2 Beschikbaarheid van de ZIM

Ook voor de ZIM geldt een maximale storingsduur van 15 minuten als een redelijkcompromis tussen kosten en bruikbaarheid. En ook de ZIM kan zodanig defectraken dat nieuwe onderdelen nodig zijn, maar bij een ZIM loont het om een fout-tolerant platform te kiezen met meervoudige hardware-onderdelen en 24 uur x 7dagen per week bewaking door beheerders.

Een bijzondere situatie is overmacht door externe bedreigingen, zoalsoverstroming, aardbeving, bomaanslag, etc. die de ZIM onherstelbaar kunnenbeschadigen. Voor dergelijke gevallen is een uitwijkvoorziening met eengereedstaande ZIM nodig, maar de kans op de bovengenoemde bedreigingen is nietgroot genoeg om te eisen dat deze uitwijkvoorziening continu bemand moet zijn ombinnen een kwartier de taken integraal over te nemen. Een tijdsinterval van eendag geeft de beheerders de tijd om bijv. naar een andere locatie te reizen. Eencontinue synchronisatie van de uitwijk-ZIM met de gegevens in de operationele ZIMis niet vereist, het gebruiken van de laatst gemaakte back-up is dan ook mogelijk.

Daarnaast is er een aparte testen demo-voorziening met een aparte ZIM nodig.De risico’s zijn te groot als daarvoor de operationele ZIM wordt gebruikt. Voor dezetest-ZIM gelden lagere beschikbaarheidseisen.

De meervoudige ZIM betekent dat ieder DCN ervoor moet zorgen dat een daaropaangesloten GBZ in principe alle ZIM’s kan bereiken, zie onderstaande figuur.

operat.ZIM

GBZ GBZ GBZGBZ GBZ

test/acc.ZIM

uitwijkZIM

RF RF

DCN

Hoewel de ZIM geen patiëntgegevens opslaat, is beschikbaarheid van groot belangvoor alle gelogde gegevens. Alle overige gegevens kunnen weliswaar wordengereconstrueerd, maar om een snelle overschakeling van de operationele ZIM naarde uitwijk-ZIM mogelijk te maken, is het verstandig van alle gegevens dagelijkseen back-up te maken en deze over te brengen naar de uitwijk-ZIM.


[B81] Er moet een uitwijkvoorziening met gereedstaande ZIM zijn, om in gevalvan onherstelbare schade aan de operationele ZIM te kunnen uitwijken.

[B82] Er moet een testen acceptatievoorziening met test-ZIM zijn, om GBZ’ente kunnen testen en accepteren alvorens deze operationeel aan te sluiten.


Merk op dat een GBZ meerdere applicaties kan bevatten waarvan de ene reedsoperationeel is en de andere nog wordt getest, zie GBZ2 in de onderstaande figuur.Dit maakt noodzakelijk dat van een GBZ een IP-adres moet configureren voor zowelde operationele ZIM als de uitwijk-ZIM, zie ook paragraaf 5.5.2.

operat. ZIM

GBZ1 GBZ2 GBZ3

test/acc. ZIM uitwijk ZIM

DCN

RF RF

Appl.1 Appl.2

Sch.1 Sch.2 Sch.3

Appl.3 Appl.4 Appl.5


5.7.3 Beschikbaarheid van een DCN

Tenslotte is de beschikbaarheid van ieder DCN belangrijk. DCN’en kunnen behalvekortstondige storingen ook uitvallen als gevolg van defecte netwerkcomponenten.Klassieke defecten als kabels die door graafmachines worden geraakt, vragen omredundante verbindingen binnen het netwerk. Kleine storingen kunnen op afstandworden verholpen. Grote storingen vergen vaak werkzaamheden op locatie,waardoor hersteltijden snel kunnen oplopen tot een werkdag.

Een te vermijden single point of failure is de aansluiting van de ZIM op een DCN.Een uitvallende aansluiting van een GBZ raakt alleen de gebruikers van dat GBZ.Een uitvallende aansluiting van de operationele ZIM raakt zeer vele gebruikers.

De meervoudige ZIM heeft aldus consequenties voor de wijze van aansluiten op eenDCN. Ieder DCN moet aansluiten op de operationele ZIM; dat vergt een actieverouter, met daarnaast een redundant pad. Ieder DCN moet ook binnen een dagkunnen overschakelen naar de uitwijk-ZIM. Dit zou bijvoorbeeld kunnen door hetplaatsen van een passieve router bij de uitwijk-ZIM. Indien de RF bij de uitwijk-ZIMfungeert als een actieve back-up van de RF bij de operationele ZIM, kan de actieveredundante router van het DCN ook op deze uitwijk-ZIM worden gekoppeld. Letop:hier zijn vele opties mogelijk en die zijn nadrukkelijk niet afgebeeld inbovenstaande figuur.


[B83] Ieder DCN vergt een redundante actieve aansluiting met de operationeleZIM, een actieve aansluiting met de test-ZIM en tenminste een passieveaansluiting met de uitwijk-ZIM.


5.7.4 Beschikbaarheidstoestanden

Zowel een ZIM als een daarop aangesloten GBZ zal op een bepaald momentvaststellen dat de ander onbeschikbaar wordt of is geworden. In geval vanonderhoud wordt dit vooraf aangekondigd, in geval van storing wordt dit achterafgeconstateerd. In paragraaf 5.10 wordt beschreven hoe een incidentele fout wordtonderscheiden van een uitgevallen systeem. Daarnaast kan een systeemonbereikbaar worden, bijv. door het uitvallen van een DCN.

De ZIM of het GBZ dat constateert dat de ander onbeschikbaar of onbereikbaar isgeworden, zal zijn gebruikers daarover inlichten indien dat relevant is. Wanneer deZIM of een GBZ weer beschikbaar wordt, zullen de betrokken gebruikers ook weerworden ingelicht, al dan niet via de beheerders.

De onderstaande figuur toont in een UML statechart diagram de toestands-veranderingen van de ZIM en die van een schakelpunt binnen de ZIM, gezien vanuiteen GBZ. De gestippelde pijlen tonen een toestandsovergang die handmatig moetplaatsvinden, zie paragraaf 4.2.17.

ZIM bereikbaar

Schakelpuntbeschikbaar

Schakelpuntonbeschikbaar

GBZ verliestIP-contactmet ZIM

gereed

actief

onderhoud

storingApplicatie kan geenHL7-berichten meer

uitwisselen, geen SSL-sessiemet schakelpunt meer starten,

maar GBZ heeft nog IP-contact met ZIM

ZIM-beheerderinformeert

GBZ-beheerders

ZIMonbereik

baar

GBZ krijgtIP-contactmet ZIM

Schakelpunt stuurttoestandsberichtnaar applicaties

Schakelpunt stuurt toestands-bericht naar applicaties

Een schakelpunt heeft dus de volgende beschikbaarheidstoestanden:• actiemodus: gereed, actief, onderhoud of storing,• beschikbaarheidsmodus: beschikbaar of onbeschikbaar.

Een ZIM als geheel heeft de volgende beschikbaarheidstoestand:• bereikbaarheidsmodus: bereikbaar of onbereikbaar.


De onderstaande figuur toont in een UML statechart diagram de toestands-veranderingen van een applicatie binnen een GBZ, gezien vanuit de ZIM. Degestippelde pijlen tonen een toestandsovergang die telefonisch of per e-mail moetplaatsvinden, zie paragraaf 4.2.1. De getoonde toestandsberichten zijn nog{toekomst} zodat die toestandsveranderingen voorlopig ook telefonisch of per e-mail moeten worden gemeld. Niet getoond is dat ook de ZIM-beheerdereigenhandig kan bepalen dat een applicatie zodanig veel fouten veroorzaakt, datdeze in de modus storing moet worden gezet. Dit moet hij dan ook melden aan deGBZ-beheerder, want die heeft deze fouten misschien niet eens opgemerkt.

GBZ bereikbaar

Applicatiebeschikbaar

Applicatieonbeschikbaar

gereed

actief

onderhoud

storing

Applicatie stuurttoestandsberichtnaar schakelpunt

GBZonbereik

baar

ZIM verliestIP-contactmet GBZ

GBZ-beheerderinformeert

ZIM-beheerder

ZIM krijgtIP-contactmet GBZ

Schakelpunt kan geenHL7-berichten meer

uitwisselen, geen SSL-sessiemet applicatie meer starten,

maar ZIM heeft nog IP-contact met GBZ

Applicatie stuurt toestands-bericht naar schakelpunt

Een applicatie heeft dus de volgende beschikbaarheidstoestanden:• actiemodus: gereed, actief, onderhoud of storing,• beschikbaarheidsmodus: beschikbaar of onbeschikbaar.

Een GBZ als geheel heeft de volgende beschikbaarheidstoestand:• bereikbaarheidsmodus: bereikbaar of onbereikbaar.


5.7.5 Samenvatting

De onderstaande tabel geeft de verdeling van beschikbaarheidscijfers voorafzonderlijke componenten resp. de gehele keten, te meten over een jaar.

ZIM DCN > ZIM DCN > GBZ GBZKleine storingen:

max. frequentie 12 / jaar 6 / jaar 12 / jaar 12 / jaarmax. duur 1 kwartier 1 kwartier 1 kwartier 1 kwartierduur / jaar 3 uur 1,5 uur 3 uur 3 uur

Grote storingen:max. frequentie 0 0 2 / jaar 2 / jaar

max. duur 0 0 12 uur 1 dagduur / jaar 0 0 24 uur 48 uur

Onbeschikbaar / jaar 3 uur 1,5 uur 27 uur 51uur% beschikbaar 99,96 99,98 99,7 99,4

Voor één GBZ is de resulterende kans:• 99% dat het de ZIM kan bereiken om patiëntgegevens aan te melden,• 98% dat het aan een ander GBZ een patiëntbericht kan versturen,• 96% dat het van vier andere GBZ’en alle patiëntgegevens kan opvragen.

De onbeschikbaarheid als gevolg van goed gepland en tijdig aangekondigdonderhoud wordt niet meegeteld in de bovengenoemde beschikbaarheidscijfers.

Opmerkingen:

• Of een GBZ of ZIM voldoet aan de gestelde beschikbaarheideisen, zal pas nalange tijd kunnen blijken. Omdat ook vóóraf bepaald moet worden of eenGBZ resp. ZIM als zodanig mag functioneren, zullen specifieke preventievemaatregelen worden geëist, zoals een noodstroomvoorziening, back-upprocedures, etc.

• Wanneer behalve het e-medicatiedossier en e-waarneemdossier voorhuisartsen ook andere toepassingen worden geimplementeerd, zou debeschikbaarheid van de gegevens nader kunnen worden gedifferentieerdnaar de verschillende gegevensklassen (medische gegevens zijn immersveel belangrijker dan logistieke gegevens) of gegevenssoorten(medicatiegegevens zijn vaak urgenter dan röntgenfoto’s). Een dergelijkenuancering kan een zorgaanbieder veel kosten besparen.


5.8 Capaciteit en schaalbaarheid

De benodigde capaciteit van de basisinfrastructuur hangt sterk af van het aantalberichten dat wordt uitgewisseld tussen de aangesloten GBZ’en onderling en metde registers. Dit aantal berichten hangt weer af van het aantal aangesloten GBZ’enen het aantal daadwerkelijke gebruikers dat patiëntgegevens opvraagt enverstuurt. Deze aantallen zijn zeer moeilijk te voorspellen, want dat hangt af vande mate van succes van de zorgaanbiederapplicaties die gebruik maken van debasisinfrastructuur.

Dit succes is echter mede afhankelijk van de responstijden. Daarbij komt nog datveel zorgverleners vooral ’s ochtends hun spreekuur hebben en dan dus ook allerleipatiëntgegevens willen opvragen. Dit kan leiden tot enorme pieken in desysteembelasting en dus zeer lange wachttijden.

Deze problematiek kan worden vergeleken met die van andere infrastructuren diedreigden te bezwijken onder hun succes, bijv. het Internet. Daaruit kan wordengeleerd dat de oplossing ligt in schaalbaarheid en flexibiliteit. Schaalbaarheid houdtin dat de capaciteit in de tijd kan worden uitgebreid afhankelijk van de werkelijkebehoefte. Flexibiliteit houdt in dat mogelijkheden worden opengehouden om debeschikbare capaciteit anders te benutten.

Anderzijds blijkt vaak dat het feitelijke gebruik zich op termijn gaat voegen naar degunstigere momenten. Ook blijkt vaak dat werkprocessen veranderen als gevolgvan de nieuwe mogelijkheden. Uiteindelijk kan dit leiden tot een balans tussenvraag en aanbod.

Voor de basisinfrastructuur in de zorg betekent dit, dat de capaciteit niet vanaf deinvoering hoeft te zijn voorbereid op de uiteindelijke belasting, mits er voldoendemogelijkheden tot opschaling zijn. Hierbij is vooral de ZIM een cruciale factor,omdat deze een centrale schakel vormt in (vooralsnog) elke interactie tussen GBZen andere systemen. Ook de DCN’en zijn hier belangrijk, maar het Internet heeftbewezen dat in principe deze voldoende schaalbaar kunnen zijn. Bovendien kunnenverschillende ZSP’s onderling concurreren op de beste responstijden.

Voor de ZIM zijn er verschillende mogelijkheden tot opschaling. De ZIM kan wordenopgebouwd uit verscheidene schakelpunten die ieder op een aparte hardware-processor of hardware-platform draaien. De systeembelasting kan zodanig wordenverdeeld over de verschillende schakelpunten, dat groepen van applicaties dievooral binnen die groep berichten uitwisselen op hetzelfde schakelpunt wordenaangesloten. Zo zullen medicatieberichten vooral tussen HIS’en, AIS’en en ZAIS’enworden uitgewisseld. Ook het feit dat de meeste uitwisseling van patiëntgegevensbinnen de regio plaatsvindt, biedt mogelijkheden tot optimalisatie.

De basisinfrastructuur zal bij aanvang van de exploitatie alleen de volgendetoepassingen ondersteunen: e-medicatiedossier en e-waarneemdossier voorhuisartsen. Aangenomen dat het enkele jaren kost dat alle huisartsen, apothekersen ziekenhuizen voor al hun medicatie en waarnemingen gebruik maken van debasisinfrastructuur, moeten de ZIM en de verschillende DCN’en bij opleveringtenminste een zeker percentage van de uiteindelijk benodigde capaciteit leveren.



[B84] De basisinfrastructuur dient bij aanvang van de exploitatie een zekerpercentage van de uiteindelijk benodigde capaciteit te kunnen leveren.

[B85] De basisinfrastructuur moet schaalbaar zijn om de uiteindelijk benodigdecapaciteit te kunnen leveren. Het wordt de verantwoordelijkheid van hetLSP resp. de ZSP’s om de capaciteit van de ZIM resp. de DCN’en tijdig opte schalen om binnen de vereiste responstijden te blijven.

[B86] De ZIM kan verscheidene schakelpunten omvatten om te kunnenopschalen en optimaliseren, bijv. per regio, per type applicatie (en dusberichtsoort), etc.

Naar huidig inzicht dient de basisinfrastructuur uiteindelijk de volgende capaciteit televeren:

• 20.000 aangesloten GBZ’en,• 50 aangesloten DCN’en,• 10.000 gelijktijdige gebruikerssessies,• 4.312.000.000 berichten per jaar,• gemiddeld 5 kByte per uitgewisseld bericht.

Het aantal berichten is ingeschat op basis van een raming voor de toepassingen e-medicatiedossier en e-waarneemdossier voor huisartsen, zie de onderstaande tabel,en de aanname dat alle andere toepassingen tezamen nog eens zoveel berichtengenereren.

Landelijke toepassinggebruikersinteractie

Aantal interactiestussen agerend GBZen ZIM

Aantal interactiestussen ZIM enreagerend GBZ ofregister

Algemeen

Opvragen PatiëntIdentificatie 32.000.000/jr 32.000.000/jr

Opvragen Zorgaanbieders 14.000.000/jr 14.000.000/jr

aanmeldenGegevens 28.000.000/jr 0

afmeldenGegevens 14.000.000/jr 0

opvragenIndex 4.000.000/jr 0

EMD

Versturen Medicatievoorschrift 140.000.000/jr 140.000.000/jr

Versturen Medicatieverstrekking 14.000.000/jr 14.000.000/jr

Opvragen Medicatievoorschriften 28.000.000/jr 28.000.000/jr

Opvragen Medicatieverstrekkingen 280.000.000/jr 280.000.000/jr

WDH

Opvragen Samenvatting WDH 4.000.000/jr 4.000.000/jr

Versturen Verslag WDH 4.000.000/jr 4.000.000/jr

Totalen


totaal aantal interacties 562.000.000/jr 516.000.000/jr

totaal aantal HL7-berichten 1.124.000.000/jr 1.032.000.000/jr

maal 2 voor andere toepassingen 2.248.000.000/jr 2.064.000.000/jr

Totaal aantal berichten 4.312.000.000/jr

Merk op dat iedere interactie tussen twee systemen leidt tot twee HL7-berichten.Gezien vanuit één systeem, is dat telkens één binnenkomend bericht en éénuitgaand bericht.

De aantallen interacties in de tabel zijn een grove inschatting, gebaseerd op deonderstaande aannamen:

• 140.000.000 medicatievoorschriften per jaar, die leiden tot:o voor 10% tot opvragenPatiëntIdentificatie door de huisartso voor 10% tot opvragenPatiëntIdentificatie door de apotheeko voor 10% tot opvragenZorgaanbiederIdentificatie door de huisartso voor 100% tot versturenMedicatievoorschrift van huisarts aan

apotheeko voor 10% tot aanmeldenGegevens door de huisartso voor 10% tot aanmeldenGegevens door de apotheeko voor 10% tot versturenMedicatieverstrekking van apotheek aan

huisartso voor 10% tot opvragenMedicatievoorschriften door huisarts of

apotheeko voor 50% tot opvragenMedicatieverstrekkingen door huisartso voor 50% tot opvragenMedicatieverstrekkingen door apotheeko een opvraag van medicatiegegevens leidt tot gem. 2 opleveringen

• 100.000.000 huisartscontacten per jaar, waarvan 5% interveniërendewaarnemingen, die leiden tot:

o voor 80% tot opvragenPatiëntIdentificatie door de waarnemero voor 80% tot opvragenIndex door de waarnemero voor 80% tot opvragenSamenvatting door de waarnemero voor 80% tot versturenVerslag door de waarnemer

Naar verwachting zal 80% van de berichten tussen 8:00 en 17:00 uur wordenuitgewisseld, waarvan 70% tussen 8:00 en 12:00 uur.

Openstaande punten:

• Zonder enige dempende factor kan piekbelasting leiden tot overbelasting enuitval van de ZIM. Bijvoorbeeld, als vele zorgverleners om 9:00 uurbeginnen met opvragen van patiëntgegevens, leidt dit tot een piekbelastingvan de ZIM. Daardoor zullen de zorgverleners langer moeten wachten opantwoord. Als ongeduldige zorgverleners of hun applicatie daardoor opnieuwdezelfde opvraagberichten naar de ZIM gaan sturen, zal dit de situatie alleenmaar verergeren. Om dit te voorkomen, wordt momenteel geëist dat eenGBZ per gebruikerssessie niet meer dan één opvraagbericht tegelijk stuurt.Deze eis is achteraf te streng gebleken, want het dwingt bijv. een HIS omna opvraag van een professionele samenvatting te wachten op antwoordvoordat de medicatiehistorie kan worden opgevraagd, zie paragraaf 6.11.Dit probleem zal in een volgende versie worden opgelost.


5.9 Responstijden

De responstijden genoemd in hoofdstuk 4 zijn gebruikerswensen en tellen vanaf hetgeven van het commando op het GBZ tot en met (het begin van) het tonen van hetantwoord op het GBZ. De onderstaande tabel geeft de gemiddelde responstijdenvoor de verschillende gebruikersinteracties.

Gebruiksscenario Gemiddelderesponstijd

Interactiemechanisme metZIM

0.1 aan/afsluiten applicatie

0.1.1 aansluiten 5 sec -

0.1.2 synchroniseren onbepaald direct versturen

0.1.3 afsluiten 2 sec -

0.2 in/uitloggen gebruiker

0.2.1 inloggen 5 sec indirect opvragen

0.2.2 uitloggen 2 sec -


0.3.1 nieuwe patiënt 5 sec indirect opvragen

0.3.2 ingeschreven patiënt 2 sec -

0.4 selecteren zorgaanbieder

0.4.1 opzoeken identificatie 5 sec indirect opvragen

0.4.2 opvragen bereikbaarheid 5 sec indirect opvragen

1.1 bijhouden patiëntgeg.

1.1.1 toevoegen gegevens 2 sec -

1.1.2 verwijderen gegevens 2 sec -


1.2.1 vrijgeven gegevens 2 sec direct versturen

1.2.2 afschermen gegevens 2 sec direct versturen

1.3 abonneren patiëntgegevens

1.3.1 aanmelden abonnement 2 sec direct versturen

1.3.2 afmelden abonnement 2 sec direct versturen


2.1.1 opvragen index 2 sec direct opvragen

2.1.2 opvragen gegevens 5 sec indirect opvragen


2.2.1 sturen gegevens 3 sec indirect versturen

2.2.2 ontvangen gegevens 2 sec -

2.2.3 klaarzetten gegevens 2 sec direct versturen

2.2.4 ophalen gegevens 5 sec indirect opvragen

2.3 overdragen patiëntgegevens

2.2.1 verzoeken overdracht 3 sec indirect versturen

2.2.2 beantwoorden 3 sec indirect versturen

2.2.3 afronden 3 sec indirect versturen


De genoemde tijden zijn gewenste gemiddelden, met uitschieters naar boven alsgevolg van piektijden. 90% van de responstijden moeten blijven binnen hetdubbele van de gewenste gemiddelde responstijden. De responstijden moetenworden gehaald bij de capaciteit gegeven in paragraaf 5.8.

Zoals aangegeven in de bovenstaande tabel, leiden sommige gebruikersinteractiestot een keten van interacties plaats tussen GBZ, ZIM en andere GBZ’en, dan weleen register. De overige gebruikersinteracties worden geheel binnen het GBZafgehandeld.

De onderstaande tabel geeft voor de verschillende interactiemechanismen aan hoede afzonderlijke systemen moeten bijdragen in de responstijden voor deverschillende gebruikers.

Interactie-mechanisme

Gem.respons

tijd

AandeelGBZ

AandeelDCN

AandeelZIM

AandeelDCN

Aandeelander

systeem

direct versturen 2 sec

versturen 0,3 0,1 1,2

bevestigen 0,3 0,1

direct opvragen 2 sec

opvragen 0,3 0,1 1,2

opleveren 0,3 0,1

indirect versturen 3 sec

versturen 0,3 0,1 0,5 0,1 1

bevestigen 0,3 0,1 0,5 0,1

indirect opvragen 5 sec

opvragen 0,3 0,1 1,0 0,1 2

opleveren 0,3 0,1 1,0 0,1

Merk op dat het om streefcijfers gaat, die zijn afgeleid van de voor gebruikersgewenste responstijden. De cijfers veronderstellen dat een SSL-sessie tussen GBZen ZIM vooraf tot stand is gekomen als gevolg van vooraf inloggen door degebruiker.

De verschillende interactiemechanismen en hun doorlooptijden resp. vertragings-tijden worden uitgewerkt in de navolgende paragrafen.



De onderstaande figuur, afgeleid van die uit paragraaf 5.4.1, geeft aan welkeschakels in de keten bijdragen aan de totale responstijd.

:GBZ1 : GBZ2:ZIM

oplevering (resultaten)

123

5

4

:opdrachtgever

opvraag

responstijd

presenterenresultaten

opvragen

opzoeken resultaten

6789

opvraag

oplevering (resultaten)

De onderstaande tabel geeft aan welke doorlooptijden per schakel gelden:

Nr. Systeem Actie Tijd1 GBZ opvraagbericht samenstellen

opvraagbericht versturen0,3 sec

2 DCN transporteren bericht 0,1 sec3 ZIM opvraagbericht uitlezen

patiënt opzoeken in verwijsindexopvraagbericht divergeren naar relevante GBZ’en

1 sec

4 DCN transporteren bericht 0,1 sec5 GBZ’en opvraagbericht uitlezen

patiëntstukken opzoeken in patiëntdossieropleverbericht samenstellenopleverbericht terugsturen

2 sec

6 DCN transporteren bericht 0,1 sec7 ZIM opleverberichten uitlezen

opleverberichten zonodig bundelenopleverberichten gedoseerd terugsturen

1 sec

8 DCN transporteren bericht 0,1 sec9 GBZ eerste opleverbericht uitlezen

inhoud presenteren op scherm0,3 sec

Keten Totale responstijd 5 sec

Voor direct opvragen geldt eigenlijk hetzelfde, behalve dat de stappen 4, 5 en 6vervallen en dat stap 3 en 7 worden samengevoegd tot één stap van 1,2 sec.



De onderstaande figuur, afgeleid van die uit paragraaf 5.4.2, geeft aan welkeschakels in de keten bijdragen aan de totale responstijd.

:GBZ1 : GBZ2:ZIM

bevestiging

123

5

4

:opdrachtgever

opdracht

responstijd

presenterenterugmelding

opdracht geven

verwerken opdracht

678

opdracht

bevestiging

9

De onderstaande tabel geeft aan welke doorlooptijden per schakel gelden:

Nr. Systeem Actie Tijd1 GBZ opdrachtbericht samenstellen

opdrachtbericht versturen0,3 sec

2 DCN transporteren bericht 0,1 sec3 ZIM opdrachtbericht uitlezen

opdrachtbericht doorsturen naar bestemde GBZ0,5 sec

4 DCN transporteren bericht 0,1 sec5 GBZ opdrachtbericht uitlezen

patiëntbericht afleveren in postbusbevestiging terugsturen

1 sec

6 DCN transporteren bericht 0,1 sec7 ZIM bevestigingen uitlezen

bevestigingen zonodig bundelenbevestigingen gedoseerd terugsturen

0,5 sec

8 DCN transporteren bericht 0,1 sec9 GBZ bevestiging uitlezen

bevestiging presenteren op scherm0,3 sec

Keten Totale responstijd 3 sec

Voor direct versturen geldt eigenlijk hetzelfde, behalve dat de stappen 4, 5 en 6vervallen en dat stap 3 en 7 worden samengevoegd tot één stap van 1,2 sec.


5.10 Betrouwbaarheid

Betrouwbaarheid van een systeem wordt (conform IEC 61508) gedefinieerd als dekans dat het systeem functioneert zoals het is gespecificeerd. Hierbij kan het begripsysteem in de meest ruime betekenis worden opgevat. Omdat een betrouwbaarheidvan 100% nooit gegarandeerd kan worden, wordt meestal geëist dat het systeemtenminste een aantal te verwachten fouten (of bijzondere situaties) detecteert,eventueel corrigeert en anders meldt aan de gebruikers en/of beheerders, zodanigdat die gebruikers en/of beheerders weten hoe ze met de situatie moeten omgaan.Binnen één systeem kunnen fouten optreden in de volgende categorieën:

• incidenteel, bijv. een tijdelijke overbelasting van het systeem, waardoor degebruiker even geen respons krijgt. Voor dergelijke fouten geldt dat eengebruiker het over enkele minuten nog maar eens moet proberen. Als hetsysteem dergelijke fouten detecteert en de gebruiker een adequatefoutmelding geeft, kan worden voorkomen dat de beheerder onnodig wordtopgeroepen.

• systematisch, bijv. een programmatuurfout die zich in specifieke gevallenmanifesteert, of een foutief ingestelde configuratieparameter, waardoor degebruiker onverwachte respons krijgt. Dergelijke fouten vergen maatregelenvan de beheerder of leverancier. Zij worden vaak opgeroepen nadat degebruiker heeft geconstateerd dat de fout bij het systeem ligt.

• acuut, bijv. vastlopende programmatuur of stroomuitval, waardoor hetsysteem onbeschikbaar wordt voor de gebruiker. Dergelijke fouten vergensnel ingrijpen van de beheerder. Die wordt ook vaak snel ingeroepen doorde gebruikers, als de beheerder de fout niet reeds zelf herkend heeft.

De basisinfrastructuur in de zorg omvat de ZIM met alle aangesloten registers enGBZ’en, inclusief de DCN’en en andere ondersteunende faciliteiten. Dit betekent datfouten als onderdeel van een (keten van) interactie(s) tussen GBZ, ZIM, SBV, UZI-register, etc. door die afzonderlijke systemen moeten worden herkend en zonodigteruggemeld aan andere systemen. Tussen onderling communicerende systemenkunnen fouten optreden in de volgende categorieën:

• incidenteel, bijv. een zoekgeraakt bericht, waardoor het zendende systeemgeen respons krijgt van het bestemde systeem. Voor dergelijke fouten geldtdat het zendende systeem het nog maar eens moet proberen. Zo kanworden voorkomen dat de gebruiker onnodig een foutmelding krijgt.

• systematisch, bijv. foutieve berichtinhoud, waardoor het ontvangendesysteem de gevraagde functie niet kan uitvoeren. Voor dergelijke foutenmoet het ontvangende systeem een foutmelding retourneren naar hetzendende systeem. Het systeem die de fout heeft veroorzaakt moet zijnbeheerder of leverancier inlichten, al dan niet opgeroepen door de gebruiker,die onverwachte respons van zijn systeem heeft gekregen.

• acuut, bijv. uitgevallen netwerk of systeem, waardoor andere systemendaarmee geen verbinding kunnen krijgen. Dergelijke fouten vergen snelingrijpen van de beheerder die verantwoordelijk is voor het uitgevallennetwerk of systeem. Die beheerder moet kunnen worden gewaarschuwd


door andere beheerders, mochten de eigen gebruikers dat nog niet gedaanhebben.

In hoeverre de verschillende foutsituaties kunnen worden gedetecteerd, hangt weeraf van hoe de HL7-interacties worden gebonden op HTTP/SOAP-interacties. In devolgende paragrafen wordt dit uitgewerkt voor de verschillendeinteractiemechanismen.Daarnaast worden de generieke foutsituaties uitgewerkt die in alleinteractiemechanismen kunnen optreden en ook op generieke wijze kunnen wordenafgehandeld.

Merk op dat bij geen van deze interactiemechanismen sprake is van transacties inde zin van samengestelde (inter)acties die als één geheel moeten wordenuitgevoerd en zonodig geheel teruggedraaid. De ACID-eisen (atomic, consistent,isolated, durable) die meestal worden gesteld aan dergelijke transacties, zoudenook te zwaar zijn voor een stelsel van een ZIM met vele duizenden GBZ’en dieallemaal onder verantwoordelijkheid van zelfstandige zorgaanbieders vallen.

Merk op dat niet voor 100% kan worden gegarandeerd dat geanticipeerde foutenaltijd worden gedetecteerd en gecorrigeerd. Dit betekent dat gebruikers enbeheerders nooit blind mogen vertrouwen op het systeem en dus enigszins alertmoeten blijven op onvoorziene fouten en in geval van twijfel de telefoon moetenpakken.

In de navolgende paragrafen wordt gesproken over interacties en verbindingen meteen GBZ en het uitvallen van een GBZ. In geval van een GBZ met meerdereapplicaties die afzonderlijk communiceren met de ZIM, moet “GBZ-applicatie”worden gelezen in plaats van “GBZ”.


5.10.1 Generieke foutsituaties

Er zijn verscheidene generieke foutsituaties die voor elke HL7-interactie kunnenoptreden en die op generieke wijze kunnen worden afgehandeld. De onderstaandefiguur toont een HL7-bericht (opvraag of opdracht) waarop al of niet een HL7-retourbericht (oplevering, ontvangstbevestiging of foutmelding) kan terugkomen.

:GBZ:gebruiker

:beheerder

:ZIM

1 2

4 3HL7-retourbericht

HL7-bericht

:beheerder

56

87HL7-retourbericht

HL7-bericht

Om een incidentele en een acute fout van elkaar te kunnen onderscheiden, kan eensysteem het na een mislukte poging nog eens proberen. Na herhaalde misluktepogingen kan het systeem veronderstellen dat het netwerk of het andere systeemis uitgevallen. Zoals beschreven in paragraaf 5.7 moet een systeem of netwerk inprincipe binnen een kwartier weer beschikbaar zijn. De gebruiker weet dan dat hijhet opnieuw kan proberen.

De onderstaande tabel geeft aan welke fouten (bijzondere situaties) kunnenoptreden en hoe daarop gereageerd moet worden.

Nr Fout Detectie Actie1a DCN tijdelijk overbelast GBZ kan eens geen

IP-contact met ZIMkrijgen

GBZ probeert nog eens ofmeldt aan gebruiker dat hij hetlater nog eens moet proberen

1b DCN storing GBZ kan herhaaldgeen IP-contact metZIM krijgen

GBZ meldt aan gebruiker enbeheerder dat de ZIM tijdelijkniet bereikbaar is

1c ZIM tijdelijk overbelast GBZ kan eens geennieuwe SSL-sessiemet de ZIM opzettenof geen berichtsturen overbestaande

GBZ probeert nog eens ofmeldt aan gebruiker dat hij hetlater nog eens moet proberen


verbinding1d ZIM uitgevallen GBZ kan herhaald

geen nieuwe SSL-sessie met de ZIMopzetten en verliestevt. bestaande SSL-sessies

GBZ meldt aan gebruiker enbeheerder dat de ZIM tijdelijkniet beschikbaar is

2 GBZ stuurt onverwerk-baar HL7-bericht(onleesbaar, verkeerdeversie, onjuiste BSN,etc.)

ZIM kan HL7-berichtniet verwerken

ZIM stuurt HL7-foutmeldingterug aan GBZ. GBZ meldt foutaan gebruiker en beheerder

3a DCN tijdelijk overbelast ZIM verliest even IP-contact met GBZ

ZIM probeert het nog eens

3b DCN storing ZIM verliest alle IP-contact via dat DCN

ZIM meldt via alarmlog aanZIM-beheerder dat DCN isuitgevallen.

3c GBZ tijdelijk overbelast ZIM kan even geenbericht over SSL-verbinding sturen

ZIM probeert het nog eens

3d GBZ storing ZIM verliest SSL-sessie met GBZ

ZIM meldt via alarmlog aanZIM-beheerder dat GBZ isuitgevallen

4 ZIM stuurt onverwerk-baar HL7-retourbericht(onleesbaar, verkeerdeversie, onverwachtberichtype, etc.)

GBZ kan HL7-retour-bericht nietverwerken

GBZ meldt aan gebruiker enbeheerder dat de ZIM eenonverwerkbaar retourberichtheeft gestuurd.

5a DCN tijdelijk overbelast ZIM kan even geenIP-contact via datDCN krijgen

ZIM probeert het nog eens ofmeldt aan andere GBZ dat hijlater nog eens moet proberen

5b DCN storing ZIM kan herhaaldgeen IP-contact viadat DCN krijgen

ZIM meldt via alarmlog aanZIM-beheerder en aan andereGBZ dat GBZ tijdelijk nietbereikbaar is

5c GBZ tijdelijk overbelast ZIM kan eens geennieuwe SSL-sessiemet GBZ opzetten ofgeen bericht sturenover bestaandeverbinding

ZIM probeert het nog eens ofmeldt aan andere GBZ dat zijlater nog eens moetenproberen

5d GBZ storing ZIM kan herhaaldgeen nieuwe SSL-sessie met GBZopzetten en verliestevt. bestaande SSL-sessies

ZIM meldt via alarmlog aanZIM-beheerder en aan andereGBZ dat GBZ tijdelijk nietbeschikbaar is

6 ZIM stuurt onverwerk-baar HL7-bericht(onleesbaar, verkeerdeversie, onjuiste BSN,etc.)

GBZ kan HL7-berichtniet verwerken

GBZ stuurt HL7-foutmeldingterug aan ZIM. ZIM meldt foutvia alarmlog aan beheerder enaan andere GBZ


7a DCN tijdelijk overbelast GBZ verliest evenIP-contact met ZIM

GBZ probeert het nog eens

7b DCN storing GBZ verliest alle IP-contact via dat DCN

GBZ doet niks

7c ZIM tijdelijk overbelast GBZ kan even geenbericht over SSL-verbinding sturen

GBZ probeert het nog eens

7d ZIM storing GBZ verliest SSL-sessie met ZIM

GBZ doet niks

8 GBZ stuurt onverwerk-baar HL7-retourbericht(onleesbaar, verkeerdeversie, onverwachtberichtype, etc.)

ZIM kan HL7-retour-bericht nietverwerken

ZIM meldt via alarmlog aanZIM-beheerder en aan andereGBZ dat GBZ foutief reageert

Ad 2: De ZIM legt het probleem hier terug bij de oorsprong van de fout. Het betrefthier waarschijnlijk systematische fouten in de programmatuur. Het heeft weinig zinaan de gebruiker te melden wat er precies aan de hand is. Vaak is het verstandigerom de exacte fout direct aan de GBZ-beheerder te melden.

Ad 3: De ZIM-beheerder hoeft hier geen onmiddellijke actie te ondernemen, wanthij mag van de DCN-beheerder resp. GBZ-beheerder verwachten dat zij reeds doorGBZ-gebruikers gewaarschuwd worden.

Ad 4: Merk op dat bij fout 4 het GBZ in theorie weer een foutmelding aan de ZIMkan sturen, maar er is besloten geen HL7-retourbericht op een HL7-retourbericht testuren. Overigens zal fout 4 zeer zeldzaam zijn als de ZIM en alle GBZ’en goedgetest zijn. Fout 2 zal vaker voorkomen, doordat de HL7-inhoud (HL7: payload)zeer complex kan zijn en de invulling afhangt van vele factoren die niet in allemogelijke combinaties van factoren getest kunnen worden.

Ad 6: Als een GBZ een onverwerkbaar bericht ontvangt, is de kans groot dat ditniet aan de ZIM ligt, maar aan het GBZ. Toch moet het GBZ het feit terugmelden,want het andere GBZ moet weten dat de gevraagde operatie niet gelukt is.

Ad 7: Een GBZ kan het nog eens proberen, maar als dat niet lukt, hoeft het GBZverder niks te doen. Er is immers geen belanghebbende gebruiker van dat GBZ bijbetrokken.

Ad 8: Omdat er is besloten geen HL7-retourbericht op een HL7-retourbericht testuren, is er dus geen mogelijkheid om de foutieve GBZ te informeren over hetonverwerkbare bericht. Wel kan de ZIM-beheerder gaan bellen naar de GBZ-beheerder, maar die zal daarmee wachten tot het vaker optreedt. Het is dusbelangrijk dat de ZIM dergelijke fouten bijhoudt in foutentellers.

Voor de generieke fouten op HTTP- en SOAP-niveau, zie de HL7 Implementatie-handleiding Web Services Profile.



De foutafhandeling is afhankelijk van de gekozen HTTP/SOAP-binding. Hier wordtalleen de enkelvoudige binding beschouwd omdat de tweevoudige binding geen rolspeelt. Voor WEL doseren gelden dezelfde foutsituaties als voor NIET doseren. Zieonderstaande figuur, afgeleid van die uit paragraaf 5.4.1.


: GBZx:ZIM




HTTP req (SOAP req (HL7 query req))GBZ

oplevertime-out

1 2

35

4

678


ZIMoplever

time-out

gebruikeroplever

time-out

presenterenresultaten

opvragen

Om te kunnen onderscheiden of er nog wel OF niet meer een HL7-oplevering komt,is er een oplever-time-out nodig. GBZ1 en de ZIM kunnen verschillende time-outshanteren, aldus wordt gedefinieerd:

• GBZ-oplever-time-out is het tijdsinterval waarna een GBZ1 geen HL7-oplevering meer van de ZIM hoeft te verwachten,

• ZIM-oplever-time-out is het tijdsinterval waarna de ZIM geen HL7-oplevering meer van een GBZx hoeft te verwachten.

Deze time-outs zijn o.m. afhankelijk van het gewenste aantal N antwoorden perHL7-oplevering en de omvang per antwoord. De ZIM-oplever-time-out zou ook nogkunnen verschillen per soort GBZ, indien daarvoor verschillende prestatieniveausworden toegestaan.

Door de GBZ- resp. ZIM-oplever-time-out korter te zetten dan de gebruiker-oplever-time-out, komt er enige ruimte voor GBZ1 resp. de ZIM om automatischenkele (opvraag-retry) hernieuwde pogingen te doen, voordat de opdrachtgeverwordt ingelicht over mislukte aflevering. GBZ1 en ZIM moeten dat 1 of hooguit 2keer opnieuw proberen, anders kan een incidentele drukte in de ZIM leiden tot eenkettingreactie van vele hernieuwd verstuurde berichten die de ZIM vervolgens doenoverstromen.

Uiteraard moet de HTTP-time-out op GBZ1 resp. de ZIM voor de enkelvoudigebinding ruim genoeg zijn ingesteld voor de langste oplever-time-out.



Nr Fout Detectie Actie1 HL7-opvraag van GBZ1

arriveert niet bij ZIMGBZ1 krijgt binnenGBZ-oplever-time-outgeen HL7-opleveringvan ZIM

GBZ1 probeert GBZ-opvraag-retry opnieuw en meldt daarnaaan gegevensopvrager dat ZIMniet bereikbaar lijkt, zie A.Gegevensopvrager kan hetlater opnieuw proberen

2 ZIM ontvangt HL7-opvraag van GBZ1,maar ZIM valt uit

GBZ1 detecteert ZIM-uitval aan afgebrokenSSL-sessie

GBZ1 meldt fout aangegevensopvrager

3 HL7-opvraag van ZIMarriveert niet bij eenGBZx

ZIM krijgt binnenZIM-oplever-time-outgeen HL7-opleveringvan GBZx

ZIM probeert ZIM-opvraag-retry opnieuw en meldt daarnain HL7-oplevering aan GBZ1dat GBZx niet bereikbaar was,zie B. Gegevensopvrager kanhet later opnieuw proberen ofbellen naar de gegevenshouder

4 GBZx ontvangt HL7-opvraag van ZIM, maarGBZx valt uitofhet vergt GBZx veeltijd om HL7-opleveringsamen te stellen

ZIM detecteert GBZx-uitval aan afgebrokenSSL-sessie

Zie bij 3

5 HL7-oplevering vanGBZx arriveert niet bijZIM

Zie bij 3 Zie bij 3

6 ZIM ontvangt HL7-oplevering van GBZx,maar ZIM valt uit

Zie bij 2 Zie bij 2

7 HL7-oplevering vanZIM arriveert niet bijGBZ1

Zie bij 1 Zie bij 1

8 GBZ1 ontvangt HL7-oplevering van ZIM,maar valt uit

Gegevensopvragermerkt dat zijn GBZ1uitvalt

Gegevensopvrager kan naherstart GBZ1 opnieuwproberen

A. GBZ1 kan het onderscheid tussen 1 en 7 niet zien. In geval van een gedoseerdeopvraag kan dat tot problemen leiden. GBZ1 kan een opvraagbericht voor“volgende N” weliswaar opnieuw versturen, maar als de ZIM het vorigeopvraagbericht wel had ontvangen, zal de ZIM dit opnieuw verstuurde berichtbeschouwen als de “daaropvolgende N”. Om de ZIM duidelijk te maken dat hetopvraagbericht opnieuw is verstuurd, moet hetzelfde bericht-id worden gebruikt, zieparagraaf 5.10.4. Echter, de ZIM mag dit duplicaatbericht nu niet weggooien, maarmoet deze beantwoorden met hetzelfde opleverbericht dat misschien al wasverstuurd en kennelijk zoekgeraakt.

B. Hier geldt hetzelfde als voor A, maar dan zijn het alle GBZx die een duplicaatopvraagbericht opnieuw moeten beantwoorden.


Ten behoeve van de betrouwbaarheid is het dus belangrijk:

• dat de ZIM na ontvangen van de HL7-opvraag:o goed bijhoudt welke GBZ’en antwoorden kunnen leveren en

terugmeldt aan GBZ1 indien een GBZx niet bereikbaar lijkt,o per GBZx goed bijhoudt hoeveel antwoorden het GBZ kan opleveren

en terugmeldt aan GBZ1 indien een GBZx niet alles heeft opgeleverd.

• dat de ZIM bij het convergeren van gedoseerde HL7-opleveringen aanGBZ1:

o ieder opleverbericht onthoudt, en opnieuw doorstuurt na eenduplicaat opvraagbericht,

o het opleverbericht weggooit nadat uit de vervolgopvraag van GBZ1blijkt dat deze ontvangen is of niet meer belangrijk is.

• dat GBZ1 na het presenteren van alle antwoorden in een HL7-oplevering, degegevensopvrager duidelijk informeert:

o ofwel dat er nog meer antwoorden verwacht worden,o ofwel dat bepaalde GBZ’en geen antwoorden hebben opgeleverd,o ofwel dat alle verwachte antwoorden netjes zijn ontvangen.

• dat alle GBZx bij het opleveren van gedoseerde HL7-opleveringen aan deZIM:

o ieder opleverbericht onthoudt en opnieuw doorstuurt na een duplicaatopvraagbericht,

o het opleverbericht weggooit nadat uit de vervolgopvraag van de ZIMblijkt dat deze ontvangen is of niet meer belangrijk is.

• dat de gegevensopvrager goed begrijpt dat hij niet alle antwoorden heeftgezien voordat zijn GBZ1 expliciet heeft gemeld dat alle verwachteantwoorden netjes zijn ontvangen en dat hij eventueel moet bellen naar dezorgaanbieder wiens GBZ niet bereikbaar was.

Let op: als een GBZx meerdere applicaties bevat, dan kan het een enkele applicatiebinnen dat GBZ zijn, dat oplevert, uitvalt, onbereikbaar is, etc. in plaats van hetgehele GBZ. In dat geval kan het GBZx eventueel expliciet terugmelden dat deapplicatie uitgevallen is, in plaats van het laten aankomen op een ZIM-bevestig-time-out.



De foutafhandeling is afhankelijk van de gekozen HTTP/SOAP-binding. Hier wordtalleen de enkelvoudige binding beschouwd omdat de tweevoudige binding geen rolspeelt. Zie onderstaande figuur, afgeleid van die uit paragraaf 5.4.2.

:GBZ1 : GBZ2:ZIM

HTTP rsp (SOAP rsp (HL7 accept ack))

HTTP rsp (SOAP rsp (HL7 accept ack))

1 23

54

678

:opdrachtgever

HTTP req (SOAP req (HL7 order req))HTTP req (SOAP req (HL7 order req))

GBZbevestigtime-out

ZIM-bevestig-time-outgebruikerbevestigtime-out

presenterenbevestiging

opdracht geven

Om te kunnen onderscheiden of er nog wel OF niet meer een HL7-bevestigingkomt, is er een bevestig-time-out nodig. GBZ1 en de ZIM kunnen licht verschillendetime-outs hanteren, aldus wordt gedefinieerd:

• GBZ-bevestig-time-out is het tijdsinterval waarna een GBZ1 geen HL7-bevestiging meer van de ZIM hoeft te verwachten,

• ZIM-bevestig-time-out is het tijdsinterval waarna de ZIM geen HL7-bevestiging meer van een GBZ2 hoeft te verwachten.

Uiteraard moet de HTTP-time-out op GBZ1 resp. de ZIM voor de enkelvoudigebinding ruim genoeg zijn ingesteld voor de relevante bevestig-time-out.

Door de GBZ- resp. ZIM-bevestig-time-out korter te zetten dan de gebruiker-bevestig-time-out, komt er enige ruimte voor GBZ1 resp. de ZIM om automatischenkele (verstuur-retry) hernieuwde pogingen te doen, voordat de opdrachtgeverwordt ingelicht over mislukte aflevering. GBZ1 en ZIM moeten dat 1 of hooguit 2keer opnieuw proberen, anders kan een incidentele drukte in de ZIM leiden tot eenkettingreactie van vele hernieuwd verstuurde berichten die de ZIM vervolgens doenoverstromen.



Nr Fout Detectie Actie1 HL7-opdracht van

GBZ1 arriveert nietbij ZIM

GBZ1 krijgt binnenGBZ-bevestig-time-outgeen HL7-bevestigingvan ZIM

GBZ1 probeert GBZ-opdracht-retry keer opnieuw en meldtdaarna fout aanopdrachtgever, zie A

2 ZIM ontvangt HL7-opdracht van GBZ1,maar ZIM valt uit

GBZ1 detecteert ZIM-uitval aan afgebrokenSSL-sessie

GBZ1 meldt fout aan opdracht-gever, zie B

3 HL7-opdracht vanZIM arriveert niet bijGBZ2

ZIM krijgt binnenZIM-bevestig-time-outgeen HL7-bevestigingvan GBZ2

ZIM probeert ZIM-opdracht-retry opnieuw en stuurt daarnafoutmelding naar GBZ1, die deopdrachtgever inlicht, zie A

4 GBZ2 ontvangt HL7-opdracht van ZIM,maar GBZ2 valt uit

ZIM detecteert aanafgebroken SSL-sessiedat GBZ2 is uitgevallen

ZIM stuurt foutmelding naarGBZ1, die de opdrachtgeverinlicht

5 bevestiging vanGBZ2 arriveert nietbij ZIM

Zie bij 3 Zie bij 3

6 ZIM ontvangtbevestiging vanGBZ2, maar ZIM valtuit

Zie bij 2 Zie bij 2

7 bevestiging van ZIMarriveert niet bijGBZ1

Zie bij 1 Zie bij 1

8 GBZ1 ontvangtbevestiging van ZIM,maar valt uit

GBZ1 ontdekt bijherstart eventueelverweesde bevestiging

GBZ1 presenteert bevestigingalsnog aan de opdrachtgever

Wat betreft de Acties genoemd in kolom 3, moeten bevestigingen en foutmeldingenalleen worden teruggemeld als daarom was gevraagd door GBZ1.

A. GBZ1 moet hier (na eventuele hernieuwde pogingen) melden aan deopdrachtgever, dat onzeker is of de HL7-opdracht is aangekomen. Deopdrachtgever kan dan opnieuw proberen de gegevens te versturen totdat er weleen bevestiging komt. Anders moet de opdrachtgever zich realiseren dat GBZ2mogelijk toch de HL7-opdracht heeft ontvangen en zonodig de telefoon pakken omde opdrachtnemer te bellen.

B. GBZ1 moet hier melden aan de opdrachtgever dat de ZIM is uitgevallen enderhalve onzeker is of de HL7-opdracht is aangekomen. De opdrachtgever kan nietopnieuw proberen de gegevens te versturen voordat de ZIM weer in de lucht is. Ingeval van NIET onmiddellijk afleveren kan GBZ1 automatisch alle gestrande HL7-opdrachten opnieuw versturen wanneer de ZIM weer beschikbaar is.

In theorie had de ZIM het HL7-bericht na ontvangst persistent kunnen maken,opdat de ZIM na herstart de verweesde HL7-berichten alsnog zou afleveren opbestemming, voorzover dit past binnen de gebruiker-bevestig-time-out. Dit heeftechter geen zin, want beide GBZ’en hebben reeds gedetecteerd dat de ZIM was


uitgevallen. De opdrachtgever wordt aldus ingelicht en zal later wellicht opnieuwproberen de gegevens te versturen.

Merk op dat de opdrachtgever geen enkele zekerheid heeft of de opdrachtnemerzijn HL7-opdracht heeft ontvangen totdat zijn GBZ1 de HL7-ontvangstbevestigingpresenteert. Daarom moet de opdrachtnemer of diens GBZ1 tot dat moment deHL7-opdracht altijd opnieuw kunnen versturen. Zelfs al heeft de opdrachtgever deHL7-opdracht allang verwerkt. De opdrachtgever en diens GBZ2 moeten er dusrekening mee houden dat zij duplicaten van HL7-opdrachten kunnen ontvangen, zieparagraaf 5.10.4.

Merk op dat de opdrachtnemer nooit zekerheid heeft dat de opdrachtgever zijnHL7-ontvangstbevestiging heeft ontvangen. Dit als gevolg van de beslissing omgeen ontvangstbevestiging op ontvangstbevestiging te sturen.


5.10.4 Identificatie van berichten en patiëntstukken

Zoals beschreven in de vorige paragrafen, moet een GBZ of de ZIM een verzondenHL7-bericht opnieuw verzenden als binnen de time-out geen HL7-retourbericht isontvangen. Bij deze herhaalde poging (retry) moet de verzender een duplicaat vanhet oorspronkelijke HL7-bericht verzenden, opdat de ontvanger kan herkennen dathet om een duplicaat gaat.

Dit is belangrijk wanneer de ontvanger het oorspronkelijke HL7-bericht wel hadontvangen, maar te laat een HL7-retourbericht had verzonden. De verzender magbij lang uitblijven van het HL7-retourbericht veronderstellen dat het oorspronkelijkeHL7-bericht verloren is geraakt en opnieuw proberen. Zo kan het gebeuren dat hetduplicaat-HL7-bericht wordt gekruist door het vertraagde HL7-retourbericht.

Zowel een GBZ als de ZIM moet ontvangen duplicaat-HL7-berichten weggooien,met uitzondering van gedoseerde HL7-opvraagberichten, want die moeten wordenbeantwoord met een duplicaat HL7-opleverbericht.

Om berichten te kunnen identificeren, moeten GBZ’en en de ZIM alle te versturenberichten van een landelijk uniek bericht-id voorzien. Om duplicaat-berichten tekunnen versturen, moeten GBZ’en en de ZIM deze berichten na het versturenbewaren totdat daarop een retourbericht is ontvangen.

Om duplicaat-berichten van anderen te kunnen herkennen, moeten GBZ’en en deZIM de bericht-id’s en applicatie-id’s van de afzenders van ontvangen berichtengedurende 2 dagen onthouden. Het bijhouden van alleen de laatste bericht-id isonvoldoende, want er mag niet worden aangenomen dat de verzender lineairoplopende bericht-id’s hanteert.

Het bijhouden van alleen bericht-id’s is ook niet voldoende, want een GBZ datbericht-id’s van een andere GBZ hergebruikt zou dan de duplicaatberichtenbestemd voor een andere GBZ kunnen ophalen. De ontvanger mag er dus niet blindvan uitgaan dat iedere applicatie netjes landelijk unieke bericht-id’s genereert. Intheorie zouden zelfs alle attributen van een bericht moeten worden gecontroleerd,maar dat is ondoenlijk.

Wanneer een GBZ als onderdeel van een duplicaatbericht opnieuw dezelfdepatiëntstukken verstuurt of oplevert, moeten ook die patiëntstukken herkenbaarzijn als kopie. Dit is belangrijk omdat bij landelijke uitwisseling van patiëntgegevensallerlei kopieën van patiëntstukken terecht zullen komen in andere dan deoorspronkelijke patiëntdossiers. Merk op dat patiëntstukken verschillendeaggregatieniveaus kunnen hebben, zoals medicatievoorschrift, professionelesamenvatting, zie ook paragraaf 3.4.3.

Dit betekent dat ieder patiëntstuk een landelijk unieke identificatie moet hebben,dat bovendien persistent moet zijn, totdat dat patiëntstuk wordt weggegooid. Dezepatiëntstuk-id kan ook worden gebruikt bij een atomaire aanmelding bij deverwijsindex, zie paragraaf 4.3.3. Deze eis is een uitdaging voor een GBZ wanneermen bedenkt welke wijzigingen op een GBZ kunnen afkomen tijdens de levensduurvan patiëntstukken, bijv.:

• twee GBZ’en worden samengevoegd wegens een fusie van zorgaanbieders,• de applicatie die het patiëntdossiers ontsluit wordt vervangen door een

applicatie van een andere leverancier.


HL7v3 verplicht het gebruik van de OID als bericht-id en patiëntstuk-id, zie [HL7v3Infra]. Voor een GBZ wordt sterk aangeraden de URA van de zorgaanbieder dieverantwoordelijk is voor het GBZ, te hanteren als root-OID voor een tak met allebericht-id’s en voor een tak met alle patiëntstuk-id’s.

Let op dat bovenstaande niet geldt voor de applicatie-id’s, die worden namelijkuitgegeven door het LSP


6 Eisen aan een Goed Beheerd Zorgsysteem(GBZ)

Dit hoofdstuk definieert de eisen waaraan een GBZ dient te voldoen, opdat dezemag worden aangesloten op een ZIM. De onderstaande eisen vormen eenideaalbeeld. Er wordt nog gezocht naar mogelijkheden om een instapniveau tedefiniëren voor bestaande XIS’en om met beperkte aanpassingen aan een deel vande eisen te kunnen voldoen.

Merk op dat de onderstaande eisen niet slechts betrekking hebben op hettechnische zorgsysteem, maar ook op de wijze waarop de zorgaanbieder ditzorgsysteem gebruikt en beheert. Eisen die de werkwijze van zorgaanbiedersraken, dienen nader te worden afgestemd met de verschillende beroepsgroepen.

De eisen rond beschikbaarheid en beheer zullen voor een individuele zorgverlenermet een eigen GBZ (bijv. een huisarts) nauwelijks haalbaar zijn. Naar verwachtingzijn deze eisen wel haalbaar indien deze zorgverleners meer gaan samenwerken engezamenlijke zorgsystemen gaan gebruiken en professionele beheerders gaaninschakelen.

6.1 Definitie van GBZ

Een GBZ wordt gedefinieerd als:

• een zorgapplicatie of een verzameling van zorgapplicaties,

• inclusief bijbehorende patiëntdossiers en zorgaanbiederpostbussen,

• die ter beschikking staat van één zorgaanbieder,

• die landelijk patiëntgegevens kan uitwisselen via de ZIM,

• die via één IP-adres communiceert met de ZIM,

• inclusief de voorzieningen die waarborgen dat alleen bevoegden toegangkrijgen tot patiëntgegevens,

• inclusief de gebruiks- en beheerprocedures voor de gebruikers enbeheerders van alle bovengenoemde voorzieningen.

Een GBZ-applicatie is een zorgapplicatie als onderdeel van een GBZ, die in hetkader van een bepaalde landelijke zorgtoepassing is aangesloten op de ZIM.


6.2 Gebruikersfuncties

Een GBZ-applicatie dient te voorzien in functies voor zorgverleners en hunmedewerkers ten behoeve van de volgende gebruiksscenario’s:

(a) in/uitloggen gebruiker, zie paragraaf 4.2.2,(b) selecteren patiënt/cliënt, zie paragraaf 4.2.3,(c) selecteren zorgaanbieder, zie paragraaf 4.2.4,(d) bijhouden patiëntgegevens, zie paragraaf 4.2.5,(e) publiceren patiëntgegevens, zie paragraaf 4.2.6,(f) {toekomst} abonneren patiëntgegevens, zie paragraaf 4.2.7,(g) koppelen patiëntgegevens, zie paragraaf 4.2.8,(h) opvragen patiëntgegevens, zie paragraaf 4.2.9,(i) versturen patiëntgegevens, zie paragraaf 4.2.10,(j) overdragen patiëntgegevens, zie paragraaf 4.2.11,(k) raadplegen toegangslog, zie paragraaf 4.2.14,(l) bijhouden mandateringen, zie paragraaf 4.2.15.

Een GBZ-applicatie dient te voorzien in functies voor beheerders ten behoeve vande volgende gebruiksscenario’s:

(m) aan/afsluiten zorgaanbiederapplicatie, zie paragraaf 4.2.1,(n) beheren zorgaanbiederapplicatie, zie paragraaf 4.2.16.

6.3 Berichtuitwisseling als gevolg vangebruikersfuncties

De onderstaande tabel geeft een overzicht van de berichten die een GBZ-applicatiemoet sturen aan de ZIM en vervolgens moet ontvangen van de ZIM, als gevolg vande bovengenoemde gebruiksscenario’s, afhankelijk van de verschillendetoepassingsrollen waarop de GBZ-applicatie aanspraak maakt.


GebruiksscenarioGebruikersinteractie

Bericht te sturen door een GBZ-applicatie aan de ZIM

HL7v3-interactie

Retourbericht te ontvangen dooreen GBZ-applicatie van de ZIM

HL7v3-interactie

Toepassingsrol

0.1 aan/afsluiten applicatie Geen

0.2 in/uitloggen gebruiker Geen


OpvragenPatiëntIdentificatie



alle


OpvragenZorgaanbieders



EMD-voorschrijver

OpvragenZorginstellingDetails PRPM_IN405010


EMD-voorschrijver

1.1 bijhouden patiëntgegevens Geen


PublicerenMedicatieVoorschriften

aanmeldenGegevens (eerste) MFMT_IN002101

bevestiging, indien de GBZ-applicatie daarom had gevraagd

MCCI_IN000002

alle

PublicerenMedicatieVerstrekkingen

heraanmeldenGegevens(bijgewerkte)

MFMT_IN002102


MCCI_IN000002

alle

PublicerenEerstelijnsDossier

afmeldenGegevens MFMT_IN002103


MCCI_IN000002

alle

1.3 abonneren patiëntgegevens Geen

1.4 koppelen patiëntgegevens Geen


Opvragen Index OpvragenIndex QUMT_IN020010

opleverenIndex QUMT_IN020020

alle

Opvragen opvragenMedicatievoorschriften QURX_IN opleverenMedicatievoorschriften QURX_IN EMD-voorschrijver


MedicatieVoorschriften (eerste) 990001NL 990003NL

opvragenMedicatievoorschriften(vervolg)

QUQI_IN000003


EMD-voorschrijver

OpvragenMedicatieVerstrekkingen

opvragenMedicatieverstrekkingen(eerste)

QURX_IN990011NL


EMD-verstrekkerEMD-voorschrijver

opvragenMedicatieverstrekkingen(vervolg)

QUQI_IN000003


EMD-verstrekkerEMD-voorschrijver

Opvragen SamenvattingDWH

OpvragenSamenvattingVoorDWH QUPC_IN990001NL


WDH-waarnemer

Opvragen SamenvattingSEH

OpvragenSamenvattingVoorSEH QUPC_IN990011NL


WDH-waarnemer


VersturenMedicatieVoorschrift



MCCI_IN000002

EMD-voorschrijver

VersturenMedicatieVerstrekking



MCCI_IN000002

EMD-verstrekker

Versturen Verslag DWH versturenVerslagDWH REPC_IN990003NL


MCCI_IN000002

WDH-waarnemer

Versturen Verslag SEH versturenVerslagSEH REPC_IN990013NL


MCCI_IN000002

Nader in te vullen

VersturenPatiëntOverdracht



MCCI_IN000002

Nader in te vullen

Versturen Verwijzing versturenVerwijzing REPC_IN002111NL


MCCI_IN000002

Nader in te vullen

VersturenBepalingOpdracht



MCCI_IN000002

Nader in te vullen

Versturen versturenBepalingResultaat POLB_IN bevestiging, indien de GBZ- MCCI_IN Nader in te vullen


BepalingResultaat 004410 applicatie daarom had gevraagd 000002

4 raadplegen toegangslog geen

7 bijhouden mandateringen geen

8 beheren GBZ geen


6.4 Berichtuitwisseling t.b.v. andere zorgaanbieders

Een GBZ dient te voorzien in de volgende functies:

(a) Een GBZ-applicatie dient alle HL7v3-berichten genoemd in de onderstaandetabel van de ZIM te accepteren, conform de geclaimde toepassingsrollenzoals vastgelegd in de configuratietabel van de ZIM (zie paragraaf 4.3.13)bij aansluiting van deze GBZ.

(b) Een GBZ-applicatie dient HL7v3-berichten met foutmeldingen (zie paragraaf7.2 punt (f)) te presenteren aan de gebruiker en eventueel aan debeheerder.

(c) Een GBZ-applicatie dient HL7v3-berichten van het type indirect opvragen afte handelen, zoals aangegeven in de onderstaande tabel, waarbij:

a. de opvraag leidt tot het raadplegen van het patiëntdossier van deaangegeven patiënt/cliënt en het zoeken naar alle vrijgegevenpatiëntstukken die voldoen aan de opgegeven zoekcriteria,

b. de oplevering van resultaten aan de ZIM wordt gedoseerd, indiendaarom was gevraagd,

c. de resultaten worden gegroepeerd tot één oplevering aan de ZIM,indien dat voor de zorgtoepassing is voorgeschreven,

In bijlage C worden mechanismen voor groeperen en doseren beschreven.

(d) Een GBZ-applicatie dient HL7v3-berichten van het type indirect versturen afte handelen, zoals aangegeven in de onderstaande tabel, waarbij:

a. het bericht onmiddellijk wordt afgeleverd in de postbus van degeadresseerde zorginstelling, zorginstelling-afdeling of zorgverlener,

b. een bevestiging aan de ZIM wordt gestuurd, indien die daarom hadgevraagd.

(e) Een GBZ-applicatie dient elk van de HL7v3-berichten in de onderstaandetabel van de ZIM te beantwoorden met een retourbericht met foutmelding inde volgende gevallen:

a. indien het GBZ het type HL7v3-bericht niet ondersteunt,b. indien het GBZ het type HL7v3-bericht niet verwacht,c. {toekomst} indien het GBZ nog bezig is met het afhandelen van een

HL7v3-bericht als onderdeel van dezelfde opvraagsessie,d. {toekomst} indien het GBZ het HL7v3-bericht niet kan verwerken

wegens capaciteitstekort,e. indien het bestemde dossier of postbus niet beschikbaar is,f. indien het bestemde dossier of postbus niet bekend is,


g. indien het bestemde dossier of postbus niet binnen de time-outreageert

h. indien het bestemde dossier of postbus het type HL7v3-bericht nietondersteunt,

Zie verder de foutmeldingen in de “HL7v3 ImplementatiegidsInfrastructurele Domeinen”.

De onderstaande tabel geeft een overzicht van de berichten die een GBZ moetontvangen van de ZIM en moet beantwoorden aan de ZIM, afhankelijk van deverschillende toepassingsrollen waarop een GBZ aanspraak maakt.


Gebruikersinteractie Bericht te ontvangen door eenGBZ van de ZIM

HL7v3-interactie

Retourbericht te beantwoordendoor een GBZ aan de ZIM

HL7v3-interactie

Toepassingsrol

indirect versturen

VersturenMedicatieVoorschrift


bevestiging, indien daarom wasgevraagd

MCCI_IN000002

EMD-verstrekker

VersturenMedicatieVerstrekking



MCCI_IN000002

EMD-voorschrijver

Versturen Verslag DWH versturenVerslagDWH REPC_IN990003NL


MCCI_IN000002

WDH-dossierhouder

Versturen Verslag SEH versturenVerslagSEH REPC_IN990013NL


MCCI_IN000002

Nader in te vullen

VersturenPatiëntOverdracht



MCCI_IN000002

Nader in te vullen

Versturen Verwijzing versturenVerwijzing REPC_IN002111NL


MCCI_IN000002

Nader in te vullen

VersturenBepalingOpdracht



MCCI_IN000002

Nader in te vullen

VersturenBepalingResultaat



MCCI_IN000002

Nader in te vullen

indirect opvragen

OpvragenMedicatieVoorschriften

opvragenMedicatieVoorschriften(eerste opvraag)

QURX_IN990001NL

opleverenMedicatieVoorschriften QURX_IN90003NL

EMD-voorschrijver

opvragenMedicatieVoorschriften(vervolg opvraag)

QUQI_IN000003

opleverenMedicatieVoorschriften QURX_IN990003NL

EMD-voorschrijver

OpvragenMedicatieVerstrekkingen

opvragenMedicatieVerstrekkingen(eerste opvraag)

QURX_IN990011NL

opleverenMedicatieVerstrekkingen QURX_IN990013NL

EMD-verstrekker


opvragenMedicatieVerstrekkingen(vervolg opvraag)

QUQI_IN000003


EMD-verstrekker

Opvragen SamenvattingDWH



WDH-dossierhouderWDH-waarnemer

Opvragen SamenvattingSEH



Nader in te vullen

overige

bevestiging MCCI_IN000002

niet - alle

overige berichten foutmelding, indien niet om ditbericht gevraagd was

MCCI_IN000002

alle


6.5 Autorisatie

Indien een GBZ interne uitwisseling van patiëntgegevens tussen zorgverleners metverschillende functies ondersteunt, dient het GBZ te voorzien in een vorm vaninterne autorisatie:

(a) Een GBZ-applicatie moet de toegang tot lokale patiëntgegevens beperkentot zorgverleners en medewerkers die daartoe bevoegd zijn op grond van deWGBO.

Het beheer van de bevoegdheden kan eventueel worden ondersteund met devolgende functies:

• beheren intern autorisatieprotocol, zie paragraaf 4.2.12• beheren interne autorisatieprofielen, zie paragraaf Fout! Verwijzingsbron

niet gevonden..

6.6 Toegangslog

Een GBZ dient te voorzien in de volgende functies:

(a) Een GBZ-applicatie moet alle ontvangen HL7v3-opvraagberichten enverzonden HL7v3-opleverberichten van resp. aan andere zorgaanbieders (zieparagraaf 6.4) loggen in de lokale toegangslog, in de vorm van:

o een logregel zoals gespecificeerd in paragraaf 4.3.8,o {toekomst} de berichtinhoud.

(b) Een GBZ-applicatie moet alle verstuurde HL7v3-opdrachtberichten enontvangen HL7v3-bevestigingen als gevolg van gebruikersfuncties (zieparagraaf 6.3) loggen in de lokale toegangslog, in de vorm van:

o een logregel zoals gespecificeerd in paragraaf 4.3.8,o {toekomst} de berichtinhoud.

(c) Een GBZ-applicatie moet iedere zorgverlener in staat stellen de lokaletoegangslog te raadplegen conform paragraaf 4.2.14.

Indien een GBZ interne uitwisseling van patiëntgegevens tussen zorgverleners metverschillende functies ondersteunt, dient het GBZ te voorzien in interne logging:

(d) Een GBZ-applicatie moet de toegang tot lokale patiëntgegevens doorzorgverleners en medewerkers loggen in de lokale toegangslog.


Een GBZ moet procedures hebben voor de volgende taken, die aantoonbaar moetenworden nageleefd:

(e) Een logbeheerder moet verzoeken van de toezichthouder inwilligen metbetrekking tot het raadplegen van de lokale toegangslog.


6.7 Connectiviteit

Een GBZ dient te voldoen aan de volgende connectiviteitseisen:

(a) Een GBZ moet via een DCN van een gekwalificeerde ZSP communiceren methet LSP.

(b) Een GBZ moet bereikbaar zijn voor de ZIM via het IP-adres dat door de ZSPis toegekend aan het GBZ en dat is verkregen door DNS-vertaling van dehostnaam van dat GBZ.

(c) Een GBZ dient IP-koppelingen via een DCN zoals gespecificeerd in hoofdstuk8, te hebben geconfigureerd voor:

• de test-ZIM,• de operationele ZIM,• {toekomst} de uitwijk-ZIM (indien aanwezig).

(d) Een GBZ-applicatie dient voor berichtuitwisseling met iedere ZIM devolgende protocolstack te ondersteunen:

• HL7v3• SOAP v1.1• HTTP v1.1• SSL v3.0 of TLS v1.0• TCP• IP v4

(e) Een GBZ-applicatie moet een aansluiting met een schakelpunt binnen elkvan de bovengenoemde ZIM’s te hebben geconfigureerd.

(f) Een GBZ-applicatie moet HL7v3-berichten van het aangesloten schakelpuntkunnen ontvangen via de applicatie-id die is toegekend door het LSP.

(g) Een GBZ-applicatie moet na het beschikbaar worden voor een bepaalde ZIM(zie paragraaf 6.9 eis (g) ):

• verzoeken van de ZIM voor het opzetten van SSL/TLS-sessieshonoreren voor berichtuitwisseling ten behoeve van anderezorgaanbieders,

• voor iedere gebruiker die landelijk patiëntgegevens wil uitwisselen,een SSL/TLS-sessie met die ZIM opzetten voor berichtuitwisseling alsgevolg van gebruikersfuncties.

(h) Een GBZ mag de volgende IP-adressen niet intern gebruiken:• het IP-adres dat door het LSP is uitgegeven voor het GBZ als geheel,• de IP-adressen die zijn gereserveerd voor de ZIM• de IP-adressen uit het landelijke IP-nummerplan van het LSP.

(i) Een GBZ dient NTP te gebruiken voor tijdsynchonisatie met de ZIM.


6.8 Beveiliging

Een GBZ dient te voldoen aan de volgende beveiligingseisen:

(a) Een GBZ-applicatie moet zich aan een ZIM authenticeren met een UZI-servicescertificaat.

(b) Een GBZ dient zijn UZI-servicescertificaat zodanig te beschermen dat dit nietkan worden gekopieerd, gewijzigd of verwijderd, zonder toestemming vande verantwoordelijke zorgaanbieder en kennisgeving aan het LSP.

(c) Een GBZ dient een SSL/TLS-sessie met de ZIM te weigeren indien voor hetSSL-certificaat van de ZIM blijkt dat:

• de geldigheidstermijn is verlopen of nog niet aangevangen,• het niet correct is ondertekend door een CA onder de root van de

Staat der Nederlanden,• het staat op een geldige lijst van ingetrokken certificaten (CRL) van

die CA,• na het verlopen van de geldigheid van deze CRL geen nieuwe CRL

kan worden opgehaald bij die CA.

(d) Een GBZ dient het lokaal inloggen door een gebruiker te weigeren indienvoor zijn UZI-pas blijkt dat:

• de geldigheidstermijn is verlopen of nog niet aangevangen,• het niet correct is ondertekend door het UZI-register,• het staat op een geldige lijst van ingetrokken certificaten (CRL) van

het UZI-register,• {toekomst} na het verlopen van de geldigheid van deze CRL geen

nieuwe CRL kan worden opgehaald bij het UZI-register .

(e) Een GBZ moet bij (c) en (d) proberen:• een nieuwe CRL op te halen bij de CA zodra deze gepubliceerd wordt,• de systeembeheerder waarschuwen indien de CRL niet correct is

ondertekend door de CA,• de systeembeheerder waarschuwen indien de CA na 15 minuten

opnieuw proberen nog steeds niet bereikbaar is.

(f) Een GBZ-applicatie die dossiers en/of postbussen ontsluit, moet waarborgendat:

• alle patiëntgegevens in HL7-berichten die namens een zorgverlenerworden opgeleverd aan de ZIM ook daadwerkelijk uit diens dossiersafkomstig zijn en door die zorgverlener zijn vrijgegeven,

• alle patiëntgegevens in HL7-berichten die voor een zorgverlener zijnafgeleverd door de ZIM ook daadwerkelijk terechtkomen in depostbus van die zorgverlener.

(g) Een GBZ-applicatie die gebruikers in staat stelt landelijk patiëntgegevens uitte wisselen op vertrouwensniveau midden, moet:

• een gebruiker in staat stellen met zijn UZI-pas landelijk in te loggendoor zich met behulp van SSL/TLS te authenticeren aan de ZIM,


• een gebruiker in staat stellen met zijn UZI-pas lokaal in te loggendoor zich te authenticeren aan de GBZ-applicatie,

• iedere keer bij het opzetten van een SSL/TLS-sessie met de ZIM diegebruiker vragen de PIN-code van zijn UZI-pas in te toetsen,

• die gebruiker weigeren indien de PIN-code niet klopt met de UZI-pas,• de ingetoetste PIN-code na gebruik steeds onmiddellijk uitwissen.

(h) Een GBZ-applicatie die gebruikers in staat stelt een BSN op te vragen of dezorgaanbiedergids te bevragen op vertrouwensniveau laag, moet:

• een gebruiker in staat stellen zich met het UZI-servicescertificaat vande zorgaanbieder te authenticeren aan de ZIM.

(i) Een GBZ moet zodanig zijn ingericht dat (zie ook paragraaf 5.6.6):

• alle UZI-paslezers gekoppeld zijn aan de werkplekken van degebruikers,

• de PIN-code die ten behoeve van een UZI-pas wordt ingetoetst opeen werkplek, exclusief wordt aangeboden aan de gekoppelde UZI-paslezer,

• alle patiëntgegevens in HL7-berichten die namens een gebruikerworden verstuurd naar de ZIM ook daadwerkelijk door die gebruikerwaren bedoeld voor verzending,

• alle patiëntgegevens in HL7-berichten die ten behoeve van eengebruiker worden toegestuurd door de ZIM ook daadwerkelijkexclusief aan die gebruiker worden gepresenteerd.

(j) Een GBZ moet een SSL/TLS-sessie tussen een gebruiker en de ZIMbeëindigen (zie paragraaf 4.3.13 voor de waarden van de tijdparameters):

• wanneer de UZI-pas meer dan het tijdsinterval gebruiker-max-kaart-uit uit de kaartlezer van diens werkplek is verwijderd,

• wanneer de gebruiker zijn applicatie gedurende het tijdsintervalgebruiker-max-applicatie-onbruik niet meer heeft gebruikt.

(k) Een GBZ-applicatie moet na afloop van een SSL/TLS-sessie met de ZIM, allegebruikte geheimen zorgvuldig uitwissen: de master secret van de SSL/TLS-sessie en de daarvan afgeleide tijdelijke sleutels.

(l) Voor een GBZ moet zijn gedefinieerd:

• welke landelijke zorgtoepassingen en toepassingsrollen wordenondersteund en gebruikt,

• hoe de grenzen van het GBZ lopen door de ICT-voorzieningen van dezorgaanbieder,

• hoe en wanneer patiëntgegevens die grenzen kunnen passeren,

• hoe wordt gewaarborgd dat patiëntgegevens in de dossiers enpostbussen niet kunnen lekken naar onbetrouwbare bestemmingen,


• hoe wordt gewaarborgd dat patiëntgegevens uit onbetrouwbarebronnen niet kunnen terechtkomen in de dossiers en postbussen,

• hoe wordt gewaarborgd dat anderen dan bevoegde gebruikers geenfysieke toegang tot (delen van) het GBZ kunnen krijgen.

(m) Als een GBZ-applicatie voor een bepaalde zorgtoepassing isaangesloten op de ZIM, moet die GBZ-applicatie alle patiëntgegevens in hetkader van die zorgtoepassing ook daadwerkelijk uitwisselen via de ZIM.


(n) Een GBZ dient op aanwijzing van het LSP een nieuw stamcertificaat te ladenvan:

• de CA die het SSL-certificaat van de ZIM heeft uitgegeven,• {toekomst} het UZI-register.

(o) De zorgaanbieder verantwoordelijk voor het GBZ moet, conform devoorwaarden van het UZI-register, aanvragen resp. tijdig vernieuwen:

• een UZI-servicescertificaat voor het GBZ,• UZI-passen voor de GBZ-gebruikers.

(p) Afgedankte GBZ-apparatuur moet worden geschoond van patiëntgegevens.

(q) {toekomst} Een GBZ dient binnen een nader te specificeren aantal dagen nahet beschikbaar komen van nieuwe patches voor het dichten vanbeveiligingslekken, deze patches te hebben geïnstalleerd.

Tenslotte moet een GBZ zich conformeren aan de NEN7510, net als ieder andersysteem van een zorgaanbieder, ongeacht of deze wordt aangesloten op de ZIM.


6.9 Beschikbaarheid

Een GBZ dient te voldoen aan de volgende beschikbaarheidseisen:

(a) Een GBZ dient 24 uur per dag en 7 dagen per week beschikbaar te zijn voorhet afhandelen van berichten vanuit de ZIM, uitgezonderd geplandonderhoud.

(b) Kleine storingen in een GBZ mogen niet meer dan gemiddeld 1 keer permaand voorkomen (MTBF) en dienen dan binnen 1 kwartier (MTTR) te zijnopgelost.

(c) Grote storingen in een GBZ mogen niet meer dan gemiddeld 2 keer per jaarvoorkomen (MTBF) en dienen dan binnen 1 dag (MTTR) te zijn opgelost.

(d) Een GBZ dient aantoonbaar te zijn beschermd tegen storingen als gevolgvan bijv.:

a. stroomuitval,b. brand,c. blikseminslag.


(e) Gepland onderhoud van een GBZ-applicatie, mag niet meer dan gemiddeld12 keer per jaar geschieden (MTBF) en dient dan binnen 1 uur (MTTR) tezijn afgerond.

(f) Wanneer een GBZ-applicatie door diens beheerder onbeschikbaar wordtgemaakt voor gepland onderhoud, dient de beheerder:

• dit 2 weken van te voren te melden aan de ZIM-beheerders met eeninschatting van de tijdsduur van onbeschikbaarheid.

• dit 1 uur van te voren nog eens te bevestigen aan de ZIM-beheerdersmet een inschatting van de tijdsduur van onbeschikbaarheid.

(g) Wanneer een GBZ-applicatie door diens beheerder beschikbaar wordtgemaakt, dient het GBZ dit telefonisch of per e-mail te melden aan de ZIM-beheerders of {toekomst} dit per toestandsbericht te melden aan de ZIM.

(h) Wanneer een GBZ-applicatie ongepland onbeschikbaar raakt en niet binnen1 kwartier weer beschikbaar wordt, dient de beheerder dit te melden aan deZIM-beheerders met een inschatting van de tijdsduur van onbeschikbaar-heid.

(i) Een GBZ dient de wettelijke bewaartermijnen van patiëntgegevens tegaranderen.

(j) Een GBZ dient van zijn patiëntgegevens een back-up te maken en binnen 1dag over te brengen naar een veilige plaats.


6.10 Responstijden

Een GBZ dient te voldoen aan de volgende eisen:

(a) Een GBZ dient voor gebruikersfuncties zonder interactie met de ZIM deresponstijden te halen zoals aangegeven in paragraaf 5.9.

(b) Een GBZ dient voor gebruikersfuncties met interactie met de ZIM, na hetcommando van een gebruiker of een daaropvolgend ontvangst van eenbericht van de ZIM, binnen de doorlooptijd vermeld in de onderstaande tabelhet aangegeven resultaat te hebben bereikt.

Gebruiksscenariocommando / bericht van ZIM

Gemiddeldedoorlooptijd

Resultaat


0.3.1 nieuwe patiënt

commando van gebruiker 0,3 sec opvraag verstuurd aan ZIM

oplevering ontvangen van ZIM 0,3 sec resultaten gepresenteerd


opzoeken identificatie / bereikbaarh.




vrijgeven/afschermen gegevens

commando van gebruiker 0,3 sec opdracht verstuurd aan ZIM

bevestiging ontvangen van ZIM 0,3 sec bevestiging gepresenteerd


opvragen index / gegevens




2.2.1/2 sturen / ophalen gegevens



2.2.3 klaarzetten gegevens



2.2.4 ophalen gegevens



2.3 overdragen patiëntgegevens

verzoeken, beantwoorden, afronden




(c) Een GBZ dient een HL7v3-bericht van het type indirect versturen naontvangst van de ZIM, en aflevering van de opdracht in de bestemdepostbus, te beantwoorden met een HL7v3-bevestiging aan de ZIM binnen dedoorlooptijd vermeld in de onderstaande tabel.

(d) Een GBZ dient een HL7v3-bericht van het type indirect opvragen naontvangst van de ZIM, te beantwoorden met een HL7v3-oplevering aan deZIM binnen de doorlooptijd vermeld in de onderstaande tabel.

Interactiemechanisme Gemiddelde doorlooptijd 90% binnen doorlooptijd

indirect versturen

versturen 1 sec 2 sec

bevestigen

indirect opvragen

opvragen 2 sec 4 sec

opleveren


6.11 Capaciteit

Een GBZ dient te voldoen aan de volgende capaciteitseisen:

(a) Een GBZ dient per gebruikersessie niet meer dan één opvraagbericht tegelijknaar de ZIM te sturen.

(b) Een GBZ dient een zodanige capaciteit te hebben voor het beantwoordenvan berichten aan de ZIM dat het kan voldoen aan de gestelderesponstijden.


Een GBZ dient te voldoen aan de volgende betrouwbaarheidseisen (zie paragraaf4.3.13 voor de waarden van de tijdparameters):

(a) Een GBZ-applicatie moet bij het verzenden van een HL7v3-opdracht/opvraag-bericht aan de ZIM:

• indien het HL7v3-bericht na de GBZ-bevestig/oplever-time-out nogniet beantwoord was, een duplicaat van dat HL7v3-bericht nazenden,

• dit herhalen tot een maximum van GBZ-opdracht/opvraag-retryaantal pogingen,

• bij uitblijven van antwoord van de ZIM, melden aan de gebruiker datde ZIM niet bereikbaar lijkt en de gebruiker het later nog eens kanproberen,

• ieder nieuw HL7v3-opdracht/opvraag-bericht voorzien van een uniekbericht-id,

• ieder duplicaat HL7v3-opdracht/opvraag-bericht identiek houden aanhet originele bericht.

(b) Een GBZ-applicatie moet bij het ontvangen van een HL7v3-opdracht/opvraag-bericht van de ZIM:

• bepalen aan het bericht-id en de applicatie-id of het om een nieuw ofduplicaat HL7v3-bericht gaat,

• een nieuw HL7v3-opdracht/opvraag-bericht beantwoorden met eenHL7v3-bevestig/oplever-bericht, zoals gespecificeerd in paragraaf6.4, en daarvan het bericht-id tenminste 2 dagen onthouden,

• een duplicaat HL7v3-opdracht/opvraag-bericht uitsluitendbeantwoorden met een duplicaat van het reeds teruggezondenHL7v3-bevestig/oplever-bericht, indien de ZIM-bevestig/oplever-time-out nog niet verstreken is, en anders negeren,

• ieder nieuw HL7v3-bevestig/oplever-bericht voorzien van een uniekbericht-id.

• ieder duplicaat HL7v3-bevestig/oplever-bericht identiek houden aanhet originele bericht.

(c) Een GBZ-applicatie moet bij het opleveren en versturen van eenpatiëntstuk:

• ieder origineel patiëntstuk voorzien van een landelijk uniekpatiëntstuk-id,

• ieder kopie van een reeds eerder opgeleverd of verstuurd patiëntstukvoorzien van het originele patiëntstuk-id.


(d) De tijdklok van een GBZ mag niet meer dan 1 seconde afwijken van detijdklok van de ZIM.

6.13 Actualiteit

Een GBZ dient te voldoen aan de volgende eisen inzake actualiteit vanpatiëntgegevens:

(a) Een GBZ-applicatie voor een bepaalde landelijke zorgtoepassing dient allebeschikbare patiëntgegevens jonger dan een nader te bepalen tijdsintervalbinnen een nader te bepalen periode na eerste aansluiting op de ZIM tehebben aangemeld bij de ZIM.

(b) Een GBZ-applicatie dient nieuw vrijgegeven patiëntgegevens binnenonderstaande tijdspanne aan te melden bij de ZIM:

• binnen 1 kwartier voor een gegevenssoort die nog niet wasaangemeld bij de ZIM,

• binnen 1 dag voor een gegevenssoort die reeds eerder wasaangemeld bij de ZIM,

waarbij de tijdspanne wordt gemeten vanaf het moment waarop dezorgaanbieder deze patiëntgegevens heeft vrijgegeven.

(c) Een GBZ-applicatie mag geen patiëntgegevens aanmelden indien deze eenkopie zijn van patiëntgegevens uit een ander GBZ, anders dan tijdens eenoverdracht, zie paragraaf 4.2.11.


(d) {toekomst} De GBZ-beheerder moet in de zorgaanbiedergids actueel (laten)houden via welke applicatie-id’s de patiëntdossiers en zorgaanbieder-postbussen bereikbaar zijn.

(e) {toekomst} Een GBZ dient binnen een nader te specificeren aantal maandenna het vaststellen van een nieuwe versie van het Programma van Eisen vooreen GBZ, te voldoen aan de nieuwe eisen.

6.14 Ondersteuning


(a) De beheerder van een GBZ en diens vervangers dienen mettelefoonnummers bekend te zijn bij de ZSP en het LSP , waarbij altijdtenminste één beheerder bereikbaar is en in staat is de nodige beheertakenuit te voeren.

(b) De beheerder van een GBZ dient verzoeken van de ZSP en het LSP metbetrekking tot het configureren van het GBZ en het aan/afsluiten van GBZ-applicaties in te willigen.


7 Eisen aan een Zorg Informatie Makelaar(ZIM)

Dit hoofdstuk definieert de eisen waaraan een ZIM dient te voldoen, opdat dezedoor een zorgaanbieder vertrouwd mag worden om diens GBZ daarop aan tesluiten. De onderstaande eisen vormen een ideaalbeeld. Ze sluiten niet uit dat ermogelijkheden komen voor een instapniveau voor bestaande of in ontwikkelingzijnde oplossingen om met beperkte aanpassingen aan een deel van de eisen tekunnen voldoen.

Merk op dat de onderstaande eisen niet slechts betrekking hebben op hettechnische systeem, maar ook op de wijze waarop de ZIM-beheerder dit systeembeheert.

7.1 Definitie van de ZIM

De ZIM wordt gedefinieerd als:

• de apparatuur die zelfstandig in staat is tot landelijke uitwisseling vanpatiëntgegevens en zorgaanbiedergegevens tussen GBZ’en, het UZI-registeren de SBV-Z,

• inclusief alle aangesloten randapparatuur, voor zover die onder beheer vanhet LSP of een door het LSP gedelegeerde beheerder staan,

• tot en met de toegang tot de DCN’en met alle aangesloten GBZ’en,

• die tezamen fungeren als operationele omgeving, dan wel alsuitwijkomgeving, dan wel als ontwikkelen/of test/acceptatie-omgeving.

Opmerking: hoofdstuk 5 beslist dat er een aparte operationele omgeving, eenaparte ontwikkelen/of test/acceptatie-omgeving en ook een aparte uitwijk-omgeving moet komen. De bovenstaande definitie is mede bedoeld om aan tegeven dat iedere omgeving tenminste één aparte ZIM heeft. In dit hoofdstukworden aldus de functies gespecificeerd van een ZIM die in elk van de omgevingenkan fungeren.

Het LSP zal behalve het beheren van de ZIM ook vele andere diensten moetenleveren. Deze diensten worden beschreven in een te verschijnen Programma vanEisen voor het LSP.


7.2 Verwijs- & routeringsfuncties

De ZIM dient te voorzien in de volgende functies (F1):

(a) De ZIM dient HL7v3-berichten van GBZ-gebruikers te autoriseren door:a. bepalen van het vereiste vertrouwensniveau, door het raadplegen

van het autorisatieprotocol voor de onderhavige HL7-interactie,gegevenssoort, agerende zorgpartij en reagerende zorgpartij,

b. controleren of de auteur genoemd in (de ControlAct Wrapper van)het bericht overeenkomt met:

• in geval van vertrouwensniveau midden: de GBZ-gebruiker dieheeft ingelogd,

• in geval van vertrouwensniveau laag: de zorgaanbieder wiensGBZ heeft ingelogd,

c. in geval van een gemandateerde, controleren of de auteur een UZI-pas op naam heeft,

d. controleren of de applicatie-id genoemd als afzender in (deTransmission Wrapper van) het bericht bekend is als onderdeel vanhet GBZ dat qua URA overeenkomt met de UZI-pas van de GBZ-gebruiker,

e. controleren of de verantwoordelijke genoemd in (de ControlActWrapper van) het bericht van dezelfde zorgaanbieder is als deauteur,

f. controleren of de onderhavige patiënt/cliënt akkkoord gaat metelektronische uitwisseling van zijn patiëntgegevens, door hetraadplegen van diens autorisatieprofiel,

g. controleren van de bevoegdheid van de verantwoordelijke, door hetraadplegen van het autorisatieprotocol, tenzij de auteur een beroepdoet op een noodgeval,

h. controleren of de onderhavige patiënt/cliënt de verantwoordelijke ofde auteur heeft uitgesloten, door het raadplegen van diensautorisatieprofiel.

(b) De ZIM dient HL7v3-berichten van het type direct versturen te accepterenvan een GBZ-gebruiker, en te beantwoorden, zoals aangegeven in deonderstaande tabel, waarbij:

a. een eerste aanmelding leidt tot een nieuwe verwijzing in deverwijsindex voor de vermelde patiënt, gegevenssoort en actualiteit,

b. een bijgewerkte aanmelding leidt tot een overschreven verwijzing inde verwijsindex voor de vermelde patiënt, gegevenssoort enactualiteit,

c. een afmelding leidt tot een gewiste verwijzing in de verwijsindex voorde vermelde patiënt, gegevenssoort en actualiteit.


(c) De ZIM dient HL7v3-berichten van het type direct opvragen te accepterenvan een GBZ-gebruiker, en te beantwoorden, zoals aangegeven in deonderstaande tabel, waarbij:

a. het opvragen van een index leidt tot het opleveren van alleverwijzingen voor de vermelde patiënt, gegevenssoort en actualiteit,behalve die m.b.t. patiëntgegevens waarvoor de GBZ-gebruiker nietgeautoriseerd is, voorzover er geen sprake van een noodsituatie is.

b. de oplevering van indexregels aan de GBZ-gebruiker wordtgedoseerd, indien daarom was gevraagd,

c. de indexregels worden gegroepeerd tot één oplevering aan de GBZ-gebruiker, indien daarom was gevraagd,

(d) De ZIM dient HL7v3-berichten van het type indirect opvragen te accepterenvan een GBZ-gebruiker, deze door te divergeren naar de relevantegegevensbron(nen), te wachten op resultaten van die gegevensbron(nen) ende opgeleverde resultaten terug te sturen naar de opvragende GBZ-gebruiker, zoals aangegeven in de onderstaande tabel, waarbij:

a. de gegevensbron is een register, dan wel alle GBZ-applicatiesgenoemd in de verwijsindex voor de vermelde patiënt, actualiteit,gegevenssoort (afgeleid uit gegevenssoortentabel), voorzover dieGBZ-applicaties het opvraagbericht kunnen verwerken zoalsaangegeven in de HL7-conformancetabellen voor deze GBZ-applicaties,

b. een eerste opvraag leidt tot het divergeren van die opvraag (metdezelfde dosering) naar die gegevensbron(nen),

c. indien een GBZ-applicatie meerdere keren in de verwijsindex staat,deze GBZ-applicatie slechts één opvraagbericht krijgt toegezonden,

d. een vervolgopvraag leidt tot het opleveren van opleverbericht aan dieGBZ-gebruiker indien aanwezig in de buffer en/of tot hetdoorschakelen van die vervolgopvraag naar die gegevensbron(nen)indien de buffer leeg is of dreigt te raken,

e. een vervolgvraag mag worden geweigerd indien deze een maximumaantal resultaten en/of een volgnummer bevat,

f. een eindeopvraag leidt tot het afbreken van de sessie en het wissenvan de buffer met resultaten,

g. de ZIM van het opvraagbericht de Transmission Wrapper vernieuwten dus ook een nieuw bericht-id toekent,

h. de ZIM van het opvraagbericht in het opvraag-specifieke deel van deControlAct Wrapper vernieuwt {toekomst} en dus ook een nieuwopvraag-id toekent,

i. de ZIM van het opvraagbericht de rest van de ControlAct Wrappercanoniek ongewijzigd laat,


j. een opvraagbericht naar de SBV-Z moet de oorspronkelijke GBZ-gebruiker bevatten t.b.v. logging door de SBV-Z,

k. een opleverbericht vanuit de gegevensbron(nen) aan de ZIM leidt tothet convergeren van dat opleverbericht aan de GBZ-gebruiker, danwel het bufferen daarvan binnen de ZIM,

l. een opleverbericht door de ZIM wordt geweigerd indien deze meerresultaten bevat dan het gevraagde maximum aantal,

m. de ZIM van ieder opleverbericht de Transmission Wrapper vernieuwten dus ook een nieuw bericht-id toekent,

n. de ZIM van het opvraagbericht in het opvraag-specifieke deel van deControlAct Wrapper vernieuwt {toekomst} en dus ook de tellerszonodig aanpast,

o. de ZIM van het opvraagbericht de rest van de ControlAct Wrappercanoniek ongewijzigd laat, evenals de eventuele Payload,

p. de opleverberichten van de verschillende gegevensbron(nen) wordengebundeld tot één opleverbericht aan de GBZ-gebruiker, indiendaarom was gevraagd en anders niet,

q. zonodig een waarschuwing wordt opgeleverd zoals gespecificeerd inparagraaf 4.2.9 punt (l) en (m).

Bijlage C beschrijft mechanismen voor bundelen en doseren.

(e) De ZIM dient HL7v3-berichten van het type indirect versturen te accepterenvan een GBZ-gebruiker, door te sturen naar de in het bericht vermelde GBZ-applicatie, te wachten op een bevestiging van die GBZ-applicatie en dezebevestiging terug te sturen naar de GBZ-gebruiker, zoals aangegeven in deonderstaande tabel, waarbij:

a. de ZIM het opdrachtbericht onmiddellijk doorstuurt naar de bestemdeGBZ-applicatie, voorzover die GBZ-applicatie het opdrachtbericht kanverwerken zoals aangegeven in de HL7-conformancetabel voor dezeGBZ-applicatie en indien deze niet beschikbaar is meteen eenfoutmelding oplevert aan de versturende GBZ-gebruiker,

b. de ZIM van het opdrachtbericht de Transmission Wrapper, deeventuele ControlAct Wrapper en de Payload canoniek ongewijzigdlaat,

c. een bevestigbericht van die andere GBZ-applicatie aan de ZIMonmiddellijk wordt doorgestuurd naar de GBZ-gebruiker indien diedaarom had gevraagd,

d. de ZIM van het bevestigbericht de Transmission Wrapper, deeventuele ControlAct Wrapper en de Payload canoniek ongewijzigdlaat,

e. de ZIM onmiddellijk een foutmelding terugstuurt naar de GBZ-gebruiker indien die andere GBZ-applicatie niet beschikbaar was.


(f) De ZIM dient elk van de HL7v3-berichten in de onderstaande tabel van eenGBZ-gebruiker te beantwoorden met een retourbericht met foutmelding inde volgende gevallen:

a. indien de GBZ-gebruiker niet geautoriseerd is,b. indien de ZIM het type HL7v3-bericht niet ondersteunt,c. indien de ZIM het type HL7v3-bericht niet verwacht,d. {toekomst} indien de ZIM nog bezig is met het afhandelen van een

HL7v3-bericht als onderdeel van dezelfde opvraagsessie,e. {toekomst} indien de ZIM het HL7v3-bericht niet kan verwerken

wegens capaciteitstekort,f. indien de bestemde GBZ-applicatie niet beschikbaar is,g. indien de bestemde GBZ-applicatie niet bekend is,h. indien de bestemde GBZ-applicatie niet binnen de time-out reageerti. indien de bestemde GBZ-applicatie het type HL7v3-bericht niet

ondersteunt,Zie verder de foutmeldingen in [HL7v3 Infra].

(g) De ZIM dient elk van de ontvangen en verzonden HL7v3-berichten te loggenin de lokale toegangslog, zoals gespecificeerd in paragraaf 4.3.8.

(h) De ZIM dient een website te onderhouden die zorgaanbieders, ZSP’s, XIS-leveranciers en patiënten/cliënten wegwijs maakt in de diensten geleverddoor het LSP.

(i) {toekomst} De ZIM dient patiënten/cliënten via het web toegang teverlenen tot hun autorisatieprofiel en toegangslog, zoals beschreven inparagraaf 7.3 en paragraaf 7.4.

Merk op dat sommige HL7v3-berichten van een GBZ-gebruiker een inhoudelijkretourbericht voor die GBZ-gebruiker opleveren en andere slechts een bevestigingmet ontvangstbevestiging. Alle HL7v3-berichten kunnen echter een bevestiging metmet foutconditie opleveren.

De onderstaande tabel geeft een overzicht van uit te wisselen berichten tussen deZIM en de daarop aangesloten GBZ’en resp. registers: SBV-Z, UZI-register enzorgaanbiedergids (ZG).


Ontvangen bericht door ZIM HL7v3-interactie

Te ontvangenvan

Door te schakelen naar Te beantwoorden door LSPmet retourbericht

HL7v3-interactie

indirect opvragen Register


GBZ-gebruiker SBV-Z - -


SBV-Z GBZ-gebruiker die eromgevraagd had

- -


GBZ-gebruiker ZG - -

opvragenZorgverlenerDetails(vervolg opvraag)

QUQI_IN000003

GBZ-gebruiker ZG (indien buffer leegraakt)

(indien in buffer) opleveren-ZorgverlenerDetails


ZG GBZ-gebruiker die eromgevraagd had

- -

opvragenZorginstellingDetails PRPM_IN405010

GBZ-gebruiker ZG - -


ZG GBZ-gebruiker die eromgevraagd had

- -

direct versturen ZIM

aanmeldenGegegevens(eerste aanmelding)

MFMT_IN002101

GBZ-gebruiker - bevestiging, indien gevraagddoor GBZ-gebruiker

MCCI_IN000002

heraanmeldenGegegevens(bijgewerkte aanmelding)

MFMT_IN002102


MCCI_IN000002

afmeldenGegegevens MFMT_IN002103


MCCI_IN000002

direct opvragen ZIM

opvragenIndex QUMT_IN GBZ-gebruiker - opleverenIndex QUMT_IN


020010 020020

opvragenIndex(vervolg opvraag)

QUQI_IN000003

GBZ-gebruiker - (indien voorradig)opleverenIndex

QUMT_IN020020

indirect versturen GBZ

versturenMedicatieVoorschrift PORX_IN932000NL

GBZ-gebruiker GBZ-applicatie vermeldin bericht

- -

versturenMedicatieVerstrekking PORX_IN924000NL


- -

versturenVerslagDWH REPC_IN990003NL


- -

versturenVerslagSEH REPC_IN990013NL


- -



- -



- -



- -

bevestiging MCCI_IN000002

GBZ-applicatie GBZ-gebruiker vermeldin bericht

- -

indirect opvragen GBZ’en

opvragenMedicatieVoorschriften(eerste opvraag)

QURX_IN990001NL

GBZ-gebruiker GBZ-applicaties vermeldin VWI

- -

opvragenMedicatieVoorschriften(vervolg opvraag)

QUQI_IN000003

GBZ-gebruiker GBZ-applicaties vermeldin VWI (indien bufferleeg raakt)

(indien in buffer) opleveren-MedicatieVoorschriften

QURX_IN990003NL

opleverenMedicatieVoorschriften QURX_IN GBZ-applicatie GBZ-gebruiker die erom - -


990003NL gevraagd had

opvragenMedicatieVerstrekkingen(eerste opvraag)

QURX_IN990011NL


- -

opvragenMedicatieVerstrekkingen(vervolg opvraag)

QUQI_IN000003

GBZ-gebruiker GBZ-applicaties vermeldin VWI (indien bufferleeg raakt)

(indien in buffer) opleveren-MedicatieVerstrekkingen

QURX_IN990013NL


GBZ-applicatie GBZ-gebruiker die eromgevraagd had

- -



- -

opleverenSamenvattingopleverenSamenvattingVoorDWH

QUPC_IN990002NL


- -



-



-


7.3 Autorisatiebeheer

De ZIM dient te voorzien in de volgende functies (F2) ten behoeve van deautorisatiebeheerder voor de volgende taken:

• beheren centraal algemeen autorisatieprotocol,• beheren centraal medisch autorisatieprotocol,• beheren centrale autorisatieprofielen.

{toekomst} en ten behoeve van de patiënt/cliënt voor het beheren van zijn eigenautorisatieprofiel.

Voor de eisen, zie paragraaf 4.2.12 en paragraaf Fout! Verwijzingsbron nietgevonden..

7.4 Toegangslogbeheer

De ZIM dient te voorzien in de volgende functies (F3) ten behoeve van delogbeheerder en {toekomst} de patiënt/cliënt:

• raadplegen centrale toegangslog.

Voor de eisen, zie paragraaf 4.2.14.

7.5 Klantenondersteuning

De ZIM dient te voorzien in de volgende functies (F4) ten behoeve van de klanten-ondersteuning:

(a) De klantenondersteuning moet zich kunnen identificeren en authenticeren envervolgens toegang krijgen tot de ZIM die door de systeembeheerder in demodus operationeel is gezet.

(b) De klantenondersteuning moet een overzicht kunnen oproepen van allevariabelen voor iedere geconfigureerde ZIM, zoals nader gespecificeerd inparagraaf 7.6.

(c) De klantenondersteuning moet een overzicht kunnen oproepen van allevariabelen voor ieder geconfigureerd DCN, zoals nader gespecificeerd inparagraaf 7.6.

(d) De klantenondersteuning moet een overzicht kunnen oproepen van allevariabelen voor ieder geconfigureerd GBZ, zoals nader gespecificeerd inparagraaf 7.6.


Merk op dat de ZIM niet hoeft te voorzien in functies voor het vastleggen,bijhouden en volgen van hulpaanvragen. Hiervoor bestaan nl. goede COTS-oplossingen.

7.6 Systeembeheer

De ZIM dient te voorzien in de volgende functies (F5) ten behoeve van desysteembeheerder voor de volgende taken:

• beheren ZIM,• beheren DCN-koppeling aan ZIM,• beheren GBZ-koppeling aan ZIM,• beheren alarmmeldingen.

Voor de eisen, zie paragraaf 4.2.17.

(a) De systeembeheerder moet meldingen van GBZ-beheerders per telefoon ofe-mail de gewijzigde toestand van een GBZ of GBZ-applicatie vastleggen.

7.7 Test/acceptatie-beheer

De ZIM dient te voorzien in de volgende functies (F6) ten behoeve van detest/acceptatie-beheerder voor de volgende taken:

• beheren test-ZIM,• beheren DCN-koppeling aan test-ZIM,• beheren GBZ-koppeling aan test-ZIM,• beheren alarmmeldingen van test-ZIM.

Voor de taak beheren test-ZIM geldt:

(a) De test/acceptatie-beheerder moet een overzicht kunnen oproepen van allevariabelen voor de ZIM, zoals nader gespecificeerd in paragraaf 7.6.

Voor de taak beheren DCN-koppeling aan test-ZIM geldt:

(b) De test/acceptatie-beheerder moet een overzicht kunnen oproepen van allevariabelen voor ieder in de test-ZIM geconfigureerd DCN, zoals nadergespecificeerd in paragraaf 7.6.

(c) De test/acceptatie-beheerder systeembeheerder moet alle stuurparameterskunnen instellen voor ieder in de test-ZIM geconfigureerd DCN, zoals nadergespecificeerd in paragraaf 7.6.


(d) De test/acceptatie-beheerder moet een DCN-koppeling aan de test-ZIMkunnen toevoegen en verwijderen, en daarbij alle configuratieparameterskunnen instellen, zoals nader gespecificeerd in paragraaf 7.6.

Voor de taak beheren GBZ-koppeling aan test-ZIM geldt:

(e) De test/acceptatie-beheerder moet een overzicht kunnen oproepen van allevariabelen voor ieder in de test-ZIM geconfigureerd GBZ, zoals nadergespecificeerd in paragraaf 7.6.

(f) De test/acceptatie-beheerder moet alle stuurparameters kunnen instellenvoor ieder in de test-ZIM geconfigureerd GBZ, zoals nader gespecificeerd inparagraaf 7.6.

(g) De test/acceptatie-beheerder moet een GBZ-koppeling aan de test-ZIMkunnen toevoegen en verwijderen, en daarbij alle configuratieparameterskunnen instellen, zoals nader gespecificeerd in paragraaf 7.6.

Voor de taak beheren alarmmeldingen van test-ZIM geldt:

(h) De test/acceptatie-beheerder moet alarmmeldingen van de test-ZIM kunnenbeheren, zoals nader gespecificeerd in paragraaf 7.6.

Merk op dat de taken van de test/acceptatie-beheerder sterk overeenkomen metdie van de systeembeheerder, doch worden beperkt tot de ZIM die door desysteembeheerder in de modus test is gezet.

7.8 Applicatiebeheer

De ZIM dient te voorzien in de volgende functies (F7) ten behoeve van deapplicatiebeheerder:

(a) De applicatiebeheerder moet zich kunnen identificeren en authenticeren envervolgens toegang krijgen tot het schakelpunt dat door desysteembeheerder in de modus onderhoud is gezet.

(b) de applicatiebeheerder moet nieuwe soorten en versies van HL7v3-berichtenkunnen implementeren in de ZIM.

(c) de applicatiebeheerder moet nieuwe zorgverlenerfuncties kunnen definiërendoor het vastleggen van:

o de naam van de functie


o de identiteit van de functiezodanig dat deze door de andere LSP-beheerders kunnen worden gebruikt.

(d) de applicatiebeheerder moet nieuwe gegevenssoorten kunnen definiërendoor het vastleggen van:

o de naam van de gegevenssoorto de identiteit van de gegevenssoort

zodanig dat deze door de andere LSP-beheerders kunnen worden gebruikt.

(e) de applicatiebeheerder moet nieuwe versies van softwarecomponentenkunnen plaatsen op een ZIM met de modus onderhoud.


7.9 Aansturing en verantwoording

De ZIM dient te voorzien in de volgende functies (F8) ten behoeve van de LSP-opdrachtnemer:

• rapporteren aan LSP-opdrachtgever,• beheren LSP-medewerkers.

Voor alle taken geldt:

(a) De LSP-opdrachtnemer moet zich kunnen identificeren en authenticeren envervolgens toegang krijgen tot iedere ZIM.

Voor de taak rapporteren aan LSP-opdrachtgever geldt:

(b) De LSP-opdrachtnemer moet een overzicht kunnen maken van allevariabelen voor iedere geconfigureerde ZIM, zoals nader gespecificeerd inparagraaf 7.6.

(c) De LSP-opdrachtnemer moet een overzicht kunnen oproepen van allevariabelen voor ieder geconfigureerd DCN, zoals nader gespecificeerd inparagraaf 7.6.

(d) De LSP-opdrachtnemer moet een overzicht kunnen oproepen van allevariabelen voor ieder geconfigureerd GBZ, zoals nader gespecificeerd inparagraaf 7.6.

(e) Bij het oproepen van een overzicht van variabelen van beheerobjecten,moet de LSP-opdrachtnemer kunnen kiezen uit grafiek, tabel en log, zoalsnader gespecificeerd in paragraaf 7.6.

(f) Na het oproepen van een overzicht van variabelen van beheerobjecten,moet de LSP-opdrachtnemer kunnen kiezen voor:

o export: vastleggen van geselecteerde historische waarden in eenexportbestand dat kan worden geladen in een intelligent analyse-gereedschap.

o rapportage: vastleggen van het gepresenteerde in een rapport, datkan worden opgeslagen, teruggehaald, gepresenteerd, afgedrukt enper E-mail verstuurd.

Voor de taak beheren LSP-medewerkers geldt:

(g) De LSP-opdrachtnemer moet LSP-medewerkers kunnen autoriseren voor éénvan de volgende beheerfuncties:


o autorisatiebeheerder,o logbeheerder,o klantenondersteuning,o systeembeheerder,o test/acceptatie-beheerder,o applicatiebeheerder,o LSP-opdrachtnemer.

(h) De LSP-opdrachtnemer moet voor iedere LSP-medewerker de omvang vande geleverde diensten kunnen bewaken:

o autorisatiebeheerder: aantal afgehandelde verzoeken van deautorisatiemanager,

o logbeheerder: aantal afgehandelde verzoeken van de toezichthouder,o klantenondersteuning: aantal afgehandelde hulpvragen van de ZSP-

klantenondersteuning,o systeembeheerder: aantal afgehandelde alarmmeldingen en

configuratieverzoeken van de ZSP-systeembeheerder,o test/acceptatie-beheerder: aantal afgehandelde tests van

zorgaanbieders en XIS-leveranciers,o applicatiebeheerder: aantal nieuwe soorten en versies van HL7v3-

berichten geïmplementeerd op verzoek van NICTIZ-programma-managers,

o LSP-opdrachtnemer: aantal opgeleverde rapportages.

Merk op dat de ZIM niet hoeft te voorzien in een intelligent analysegereedschap.Hiervoor bestaan nl. goede COTS-oplossingen.


7.10 Connectiviteit

De ZIM dient ten behoeve van F1 te voldoen aan de volgende connectiviteitseisen:

(a) De ZIM dient te kunnen worden gekoppeld met GBZ’en via verscheideneDCN’en.

(b) De ZIM dient te zijn gekoppeld met de SBV-Z, het UZI-register en dezorgaanbiedergids zoals voorgeschreven voor die systemen, zie [BSN] en[UZI].

(c) De ZIM dient voor berichtuitwisseling met de GBZ’en en eventueel andereZIM’s de volgende protocolstack te ondersteunen:

• HL7v3• SOAP v1.1• HTTP v1.1• SSL v3.0 of TLS v1.0• TCP• IP v4

(d) {toekomst} Een schakelpunt van de ZIM dient van alle GBZ-applicatieswaarvoor een koppeling met dit schakelpunt is geconfigureerd, eenéénmalige SSL/TLS-sessie te accepteren, waarbij:

• tweezijdige authenticatie tussen het vertrouwensmiddel van de ZIM(SSL-certificaat) en dat van het GBZ (UZI-servicescertificaat)plaatsvindt,

• de ZIM deze GBZ-applicatie beschouwt als beschikbaar in de modusactief.

(e) De ZIM dient voor het uitwisselen van HL7v3-berichten met een GBZ opvertrouwensniveau midden, het GBZ in staat te stellen SSL/TLS-verbindingen met de ZIM te maken, waarbij:

• voor zover niet reeds aanwezig, eerst een SSL/TLS-sessie wordtopgezet, met tweezijdige authenticatie tussen het vertrouwensmiddelvan de ZIM (SSL-certificaat) en dat van de GBZ-gebruiker (UZI-pas)plaatsvindt,

• de ZIM weigert als het aantal SSL/TLS-verbindingen binnen dezeSSL/TLS-sessie reeds gebruiker-max-verbindingen bedraagt,

• de ZIM weigert als het GBZ niet was opengesteld, zie paragraaf4.2.17 eis (o),

• de ZIM weigert als het maximum aantal gelijktijdige gebruikers-sessies per GBZ wordt overschreden.


(f) De ZIM moet voor het uitwisselen van HL7v3-berichten met een GBZ opvertrouwensniveau laag, dat GBZ in staat stellen SSL/TLS-verbindingen metde ZIM te maken, waarbij:

• voor zover niet reeds aanwezig, eerst een SSL/TLS-sessie wordtopgezet, met tweezijdige authenticatie tussen het vertrouwensmiddelvan de ZIM (SSL-certificaat) en dat van het GBZ (UZI-services-certificaat) plaatsvindt,

• de ZIM weigert als het aantal SSL/TLS-verbindingen binnen dezeSSL/TLS-sessie reeds applicatie-max-verbindingen bedraagt,

• de ZIM weigert als het GBZ niet was opengesteld, zie paragraaf4.2.17 eis (o).

(g) De ZIM dient voor berichtuitwisseling met de onderstaande registers teconformeren aan de door CIBG gesteld eisen, maar rekening te houden metalternatieve datacommunicatieverbindingen, mocht de capaciteitbeperkingen gaan opleveren:

• voor SBV-Z zie [BSN],• voor UZI-register, zie [UZI],• voor zorgaanbiedergids, zie [UZI],

(h) {toekomst} De ZIM dient voor webtoegang door een internet-gebruiker,gangbare webbladeraars in staat te stellen een SSL/TLS-verbinding met deZIM te maken, waarbij:

• eenzijdige authenticatie tussen het vertrouwensmiddel van de ZIM(SSL-certificaat) en dat van de internet-gebruiker (e-NIK)plaatsvindt,

• de ZIM de SSL/TLS-verbinding afbreekt wanneer het door desysteembeheerder ingestelde tijdsinterval sinds de laatste HTTP-interactie is verstreken,

• het maximum aantal gelijktijdige internetsessies niet wordtoverschreden.

(i) De RouteerFunctie (RF) bij de ZIM dient het IP-verkeer tussen GBZ’enaangesloten op verschillende DCN’en te ondersteunen, waarbij de DCN’enworden gekoppeld op basis van statische routering, met floating staticrouting voor redundante routes.

(j) De RouteerFunctie (RF) bij de ZIM moet alle op de ZIM aangesloten GBZ’ende mogelijkheid bieden om de volgende CA’s te bereiken voor het ophalenvan een CRL:

• de CA die het ZIM-certificaat heeft uitgegeven,


(k) Het LSP moet DNS-diensten leveren aan alle aangesloten GBZ’en, zodanigdat:

• iedere ZSP een primaire DNS-server voor hun domein beheert,• het LSP de secundaire DNS-server voor al die domeinen beheert.• per forward DNS-zone wordt ook een reverse DNS-zone aangemaakt• voor ieder (sub-) domein (zowel voor forward als reverse zones) de

DNS van het LSP slave is.

(l) De ZIM dient voor tijdsynchonisatie met de GBZ’en NTP te gebruiken.


7.11 Beveiliging

De ZIM dient te voldoen aan de volgende beveiligingseisen:

(a) De ZIM dient alle door GBZ-gebruikers opgevraagde en verstuurdepatiëntgegevens na afhandeling van de interactie te wissen, zodanig datpatiëntgegevens niet abusievelijk kunnen uitlekken.

(b) De ZIM dient te worden beschermd tegen fysieke indringers, door plaatsingin ruimten die alleen toegankelijk zijn voor medewerkers van het LSP dienoodzakelijkerwijs fysieke toegang tot die onderdelen moeten hebben in hetbelang van goed functioneren.

(c) De ZIM dient zoveel mogelijk te worden beschermd tegen elektronischeindringers, door middel van intrusion detection en intrusion prevention.

(d) De ZIM dient een systeemgebonden vertrouwensmiddel (SSL-certificaat) tehebben dat op naam staat van de LSP-opdrachtgever en is gecertificeerddoor een CA onder de root van de Staat der Nederlanden.

(e) De ZIM dient zijn systeemgebonden vertrouwensmiddel (SSL-certificaat)zodanig te beschermen dat dit niet kan worden gekopieerd, gewijzigd ofverwijderd zonder toestemming van de LSP-opdrachtgever.

(f) De ZIM dient een SSL/TLS-sessie met een GBZ (zie paragraaf 5.6.3 en5.6.4) te weigeren indien voor het vertrouwensmiddel (UZI-servicescertificaat) van dat GBZ blijkt dat:

• de geldigheidstermijn is verlopen of nog niet aangevangen,• het niet correct is ondertekend door de CA van het UZI-register,• het staat op de lijst van ingetrokken vertrouwensmiddelen (CRL) van

het UZI-register• de URI op het certificaat afwijkt van de URI die van het GBZ bekend

is, zie paragraaf 4.2.17 eis (p).

(g) De ZIM dient een SSL/TLS-sessie met een GBZ-gebruiker (zie paragraaf5.6.2) te weigeren indien voor het vertrouwensmiddel (persoonlijke UZI-pas) van de GBZ-gebruiker blijkt dat:

• de geldigheidstermijn is verlopen of nog niet aangevangen,• het niet correct is ondertekend door de CA van het UZI-register,• het staat op de lijst van ingetrokken vertrouwensmiddellen (CRL) van

het UZI-register,• de UZI-abonnee afwijkt van die van het UZI-servicescertificaat

behorende bij het GBZ, zie paragraaf 4.2.17 eis (p).


(h) De ZIM dient minimaal eens in de 4 uur een nieuwe lijst van ingetrokkenvertrouwensmiddelen (CRL) op te halen van het UZI-register.

(i) De ZIM dient op vertrouwensniveau midden GBZ-gebruikers te autoriseren opbasis van hun vertrouwensmiddel (UZI-pas) zoals te authenticeren d.m.v.SSL/TLS en te controleren of die overeenkomt met de identiteit (URA en UZI-nummer) en de eventuele zorgverlenerfunctie (rolcode) zoals vermeld in eenHL7-bericht.

(j) De ZIM dient op vertrouwensniveau laag GBZ-gebruikers te autoriseren opbasis van het vertrouwensmiddel van hun zorgaanbieder (UZI-services-certificaat) zoals te authenticeren d.m.v. SSL/TLS en te controleren of dieovereenkomt met de URA zoals vermeld in een HL7-bericht.

(k) De ZIM moet een SSL/TLS-sessie geïnitieerd door een GBZ-gebruiker (zieparagraaf 5.6.2) beëindigen (zie paragraaf 4.3.13 voor de waarden van detijdparameters):

• wanneer deze SSL/TLS-sessie reeds gedurende het tijdsintervalgebruiker-max-sessie-duur open staat,

• wanneer de gebruiker via deze SSL/TLS-sessie gedurende hettijdsinterval gebruiker-max-sessie-onbruik geen HL7-interactie meermet de ZIM heeft gehad,

• waarbij een eventueel nog lopende HL7-interactie eerst wordtafgerond.

(l) De ZIM moet een SSL/TLS-sessie geïnitieerd door een GBZ-applicatie (zieparagraaf 5.6.4) beëindigen (zie paragraaf 4.3.13 voor de waarden van detijdparameters):

• wanneer deze SSL/TLS-sessie reeds gedurende het tijdsintervalapplicatie-max-sessie-duur open staat,

• wanneer de gebruiker via deze SSL/TLS-sessie gedurende hettijdsinterval applicatie-max-sessie-onbruik geen HL7-interactie meermet de ZIM heeft gehad,

• waarbij een eventueel nog lopende HL7-interactie eerst wordtafgerond.

(m) {toekomst} De ZIM dient een SSL/TLS-sessie met een Internet-gebruikerte weigeren indien voor het vertrouwensmiddel (e-NIK) van die gebruiker blijktdat:

• de geldigheidstermijn is verlopen of nog niet aangevangen,• het niet correct is ondertekend door de desbetreffende CA,


• het staat op de lijst van ingetrokken vertrouwensmiddellen (CRL) vanhet e-NIK-register.


7.12 Beschikbaarheid

De ZIM dient te voldoen aan de volgende beschikbaarheideisen, gemeten over eenkalenderjaar:

(a) De ZIM dient 24 uur per dag en 7 dagen per week beschikbaar te zijn voorhet afhandelen van berichten vanuit alle aangesloten GBZ’en en bedieningvan de andere functies door de medewerkers van het LSP.

(b) Kleine storingen in de ZIM mogen niet meer dan gemiddeld 12 keer per jaarvoorkomen (MTBF) en dienen dan binnen 1 kwartier (MTTR) te zijn opgelost.

(c) De ZIM dient aantoonbaar te zijn beschermd tegen grote storingen alsgevolg van bijv.:

a. stroomuitval,b. brand,c. blikseminslag.

(d) De operationele ZIM dient van zijn gegevens een back-up te maken enbinnen 1 dag over te brengen naar de uitwijklocatie.

(e) Gepland onderhoud van de ZIM waarbij GBZ’en moeten overschakelen, magniet meer dan gemiddeld 2 keer per jaar geschieden (MTBF) in het weekenden dient dan binnen 24 uur (MTTR) te zijn afgerond, waarbij:

a. de beheerders van de over te schakelen GBZ’en 2 weken van tevoren moeten worden ingelicht,

b. de gebruikers van de over te schakelen GBZ’en 1 uur van te vorenmoeten worden ingelicht,

c. binnen 1 kwartier na aanvang van het onderhoud wordt over-geschakeld naar een uitwijkvoorziening;

d. binnen 1 kwartier na afronding van het onderhoud wordt terug-geschakeld.

(f) Storingen als gevolg van overmacht (bijv. overstroming, aardbeving,bomaanslag) dienen binnen redelijke termijn te worden hersteld, waarbij:

a. binnen 1 dag na optreden van de storing wordt overgeschakeld naareen uitwijkvoorziening;

b. de uitwijk-ZIM start met de meest recente back-up van gegevens uitde operationele ZIM.


7.13 Responstijden

De ZIM dient te voldoen aan de volgende eisen:

(e) De ZIM dient een HL7v3-aan/afmeldbericht van het type direct versturen naontvangst van een GBZ-gebruiker te beantwoorden met een bevestiging,binnen de doorlooptijd vermeld in de onderstaande tabel.

(f) De ZIM dient een HL7v3-opvraagbericht van het type direct opvragen naontvangst van een GBZ-gebruiker te beantwoorden met de resultaten,binnen de doorlooptijd vermeld in de onderstaande tabel.

(g) De ZIM dient een HL7v3-opdrachtbericht van het type indirect versturen naontvangst van een GBZ-gebruiker door te sturen naar de in het berichtgenoemde GBZ, binnen de doorlooptijd vermeld in de onderstaande tabel.

(h) De ZIM dient een HL7v3-bevestiging van het type indirect versturen naontvangst van een GBZ door te sturen naar de in het bericht genoemdeGBZ, binnen de doorlooptijd vermeld in de onderstaande tabel.

(i) De ZIM dient een HL7v3-opvraagbericht van het type indirect opvragen naontvangst van een GBZ-gebruiker te divergeren naar tenminste één van dein de verwijsindex genoemde GBZ’en, binnen de doorlooptijd vermeld in deonderstaande tabel.

(j) De ZIM dient een HL7v3-opleverbericht van het type indirect opvragen naontvangst van een GBZ, binnen 1 sec te convergeren naar de GBZ-gebruikerdie erom gevraagd had.

Mechanisme Gemiddelde doorlooptijd 90% binnen doorlooptijd

direct versturen

aan/afmelden 1,2 sec 2,4 sec

bevestigen

direct opvragen

opvragen 1,2 sec 2,4 sec

opleveren

indirect versturen

versturen 0,5 sec 1 sec

bevestigen 0,5 sec 1 sec

indirect opvragen

opvragen 1 sec 2 sec

opleveren 1 sec 2 sec


7.14 Capaciteit

De ZIM dient te voldoen aan de volgende schaalbaarheidseisen:

(a) De ZIM dient bij aanvang een nader te bepalen percentage van decapaciteit, gespecificeerd in paragraaf 5.8, te leveren.

7.15 Schaalbaarheid

De ZIM dient te voldoen aan de volgende schaalbaarheidseisen:

(a) De ZIM dient zodanig ontworpen te worden dat er geen intrinsiekebeperkingen zijn voor opschaling naar de uiteindelijke capaciteit die isgespecificeerd in paragraaf 5.8.door uitbreiding van het aantal hardwarecomponenten.

(b) het LSP dient binnen 2 maanden na geconstateerde overschrijding van deresponstijden, de capaciteit van de ZIM te vergroten, zodanig dat degemiddelde responstijden weer zijn zoals voor de overschrijding.


De ZIM dient te voldoen aan de volgende betrouwbaarheidseisen:

(a) De ZIM moet bij het ontvangen van een HL7v3-opdracht/opvraag-berichtvan een agerende GBZ:

• bepalen aan het bericht-id en de applicatie-id of het om een nieuw ofduplicaat HL7v3-bericht gaat,

• een nieuw HL7v3-opdracht/opvraag-bericht beantwoorden met eenHL7v3-bevestig/oplever-bericht, zoals gespecificeerd in paragraaf7.2, en daarvan het bericht-id tenminste 2 dagen onthouden,

• een duplicaat HL7v3-opdracht/opvraag-bericht uitsluitendbeantwoorden met een duplicaat van het reeds teruggezondenHL7v3-bevestig/oplever-bericht, indien de GBZ-bevestig/oplever-time-out nog niet verstreken is, en anders negeren,

• ieder nieuw doorgestuurd HL7v3-bevestig-bericht ongewijzigd laten,• ieder nieuw geconvergeerd HL7v3-oplever-bericht voorzien van een

nieuwe transmission wrapper met een uniek bericht-id,• ieder duplicaat HL7v3-bevestig/oplever-bericht identiek houden aan

het originele bericht.

(b) De ZIM moet bij het doorsturen/divergeren van een HL7v3-opdracht/opvraag-bericht aan een reagerende GBZ:

• indien het HL7v3-bericht na de ZIM-bevestig/oplever-time-out nogniet beantwoord was, een duplicaat van dat HL7v3-bericht nazenden,


• dit herhalen tot een maximum van ZIM-opdracht/opvraag-retryaantal pogingen,

• bij uitblijven van een antwoord van een reagerende GBZ, een HL7v3-bericht aan de agerende GBZ terugzenden, met de boodschap dateen GBZ niet bereikbaar lijkt en dat de gebruiker het later nog eenskan proberen,

• ieder nieuw doorgestuurd HL7v3-opdracht-bericht ongewijzigd laten,• ieder nieuw gedivergeerd HL7v3-opvraag-bericht voorzien van een

nieuwe transmission wrapper met een uniek bericht-id,• ieder duplicaat doorgestuurd/gedivergeerd HL7v3-opdracht/opvraag-

bericht identiek houden aan het originele bericht,• waarbij fouten van reagerende GBZ’en leiden tot het ophogen van de

foutentellers, zie paragraaf 4.2.17 punt (n).

(c) De ZIM dient zijn tijdsklok niet meer dan een halve seconde te latenafwijken van een erkende tijdsreferentie.


8 Eisen aan een Data Communicatie Netwerk(DCN)

Dit hoofdstuk definieert de eisen waaraan een DCN dient te voldoen, opdat deze deaansluiting van GBZ’en op de ZIM mag verzorgen.

Merk op dat de onderstaande eisen niet slechts betrekking hebben op de technischevoorzieningen voor datacommunicatie, maar ook op de wijze waarop denetwerkaanbieder die voorzieningen exploiteert en beheert.

8.1 Definitie van DCN

Een DCN wordt gedefinieerd als:

• een netwerk van datcommunicatieverbindingen,

• inclusief de daarvoor benodigde voorzieningen op de locatie van aangeslotenpartijen,

• die door één ZSP wordt beheerd en geëxploiteerd,

• ten behoeve van zorgaanbieders die hun GBZ willen aansluiten op de ZIM.

Een ZSP zal behalve het beheren van zijn DCN ook aanvullende diensten moetenleveren.

8.2 Connectiviteit

Een DCN dient te voldoen aan de volgende connectiviteitseisen:

(a) een DCN dient ieder aangesloten GBZ toegang te bieden tot respectievelijk:• de operationele ZIM,• de test-ZIM,• de uitwijk-ZIM.

(b) een DCN dient een willekeurig GBZ te kunnen aansluiten, waarbij:• aan het GBZ een vast IP-adres wordt uitgegeven, afkomstig uit een

IP-adresblok toegekend aan het DCN door het LSP,• de ZSP zorgt voor een eventuele vertaling van adressen die intern in

het ZSP-netwerk worden gebruikt naar IP-adressen die het LSPuitgeeft voor het subnet van de betreffende ZSP,

• intern door de ZSP gebruikte adressen in de context van het vorigepunt, niet mogen conflicteren met het landelijke LSP-nummerplan.

(c) een DCN dient alle berichtuitwisseling tussen de ZIM en de GBZ’en zoalsgespecificeerd in dit document mogelijk te maken.


(d) een DCN dient IP-verkeer met andere DCN’en via het LSP mogelijk temaken.

(e) Voor het koppelvlak tussen ZIM en DCN geldt de volgende specificaties:a. Gebaseerd op UTPb. Snelheid:10/100/1000 Mb/s (laatste is optioneel en afhankelijk van

het aantal GBZ-en dat is aangesloten op een specifieke ZSP);snelheid wordt fixed ingesteld en niet onderhandeld.

c. Duplex-mode (fixed ingesteld): - Bij 10 Mb half - Bij 100/1000 Mb full

d. De koppeling zal plaatsvinden op basis van laag 3 (IP-routering engeen laag 2 koppelingen vanwege complexiteit en stabiliteit).

e. De fysieke locaties zullen worden gespecificeerd door NICTIZ (LSP);deze locaties zullen worden aangeduid als LSP entry points.

Indien er redundante koppelingen worden gemaakt dan kunnen deze wordengemaakt op de LSP entry points. Echter vanuit het LSP zal de routeringgebaseerd zijn op 1 IP next-hop adres, waarbij het de verantwoordelijkheidis van de ZSP om te bepalen op welke locatie/systeem dit IP-adres actief is(bijv. door middel van handmatig /VRRP /HSRP /GBLP, etc.). Het LSP zalzorgdragen voor een transparante laag 2-koppeling tussen de verschillendeLSP entry points.


(f) een ZSP dient als domeinscheiding en ten behoeve van monitoring-functionaliteit, op de GBZ-lokatie een door de ZSP te beherennetwerkcomponent (laag 2 of 3) te plaatsen.

8.3 DNS-diensten

Een ZSP dient als volgt DNS-diensten te bieden:

(a) De ZSP registreert alle host- en domeinnamen van alle op die ZSPaangesloten GBZ’en en het LSP.

(b) De ZSP beheert een authoritative DNS-server voor diens domein, zodanigdat:

• de ZSP de primaire DNS-server beheert,• het LSP de secundaire DNS-server beheert,• per forward DNS-zone wordt ook een reverse DNS-zone aangemaakt• voor ieder (sub-) domein (zowel voor forward als reverse zones) de

DNS-server van het LSP slave kan zijn.

(c) De ZSP dient de host- en domeinnamen, waarvoor het DNS-services biedt,te registreren bij het LSP.

(d) Indien een ZSP subdomeinnamen beschikbaar stelt aan GBZ dan dient voordeze namen alle volgende eisen te gelden:

• per subdomeinnaam maximaal 15 characters• de namen dienen voor de gebruiker betekenis te hebben• aantal niveaus in subdomeinen maximaal 3

(e) De ZSP moet de host- en domeinnamen vastleggen van de CA’s genoemd ineis (j) van paragraaf 7.10.

8.4 Beveiliging

Een DCN dient te voldoen aan de volgende beveiligingseisen:

(a) De netwerkaanbieder moet zorgen voor een voldoende beveiligingsniveauvan netwerkkoppelingen naast die van de eigen beheerssystemen, GBZ’en,de SBV-Z, het UZI-register en {toekomst} het UZOVI-register,

(b) Een DCN dient de aangesloten ZIM’s en GBZ’en te vrijwaren van spam,virussen en andere dreigingen van het openbare Internet, indien het DCNdaartoe toegang geeft.

(c) De ZSP dient zich te conformeren aan de NEN7510. Hierbij wordtaangetekend dat een DCN geen gegevens opslaat maar alleen (meestalversleutelde) gegevens transporteert.


8.5 Beschikbaarheid

Een DCN dient te voldoen aan de volgende beschikbaarheideisen:

(a) Een DCN dient voor de beschreven functionaliteit 24 uur per dag en 7 dagenper week beschikbaar te zijn.

(b) Kleine storingen in het IP-verkeer van een DCN aan een GBZ mogen nietmeer dan gemiddeld 1 keer per maand voorkomen (MTBF) en dienen danbinnen 1 kwartier (MTTR) te zijn opgelost.

(c) Kleine storingen in het IP-verkeer van een DCN aan de ZIM mogen nietmeer dan gemiddeld 6 keer per jaar voorkomen (MTBF) en dienen danbinnen 1 kwartier (MTTR) te zijn opgelost.

(d) Grote storingen in een DCN mogen niet meer dan gemiddeld 2 keer per jaarvoorkomen (MTBF) en dienen dan binnen 1 uur (MTTR) te zijn opgelost.

(e) Voor de dienstverlening van een DCN aan de ZIM dient een backup-voorziening voor continuering van de dienstverlening zorg te dragen, zodat(enkelvoudig) falen van componenten niet resulteert in uitval van dedienstverlening.

8.6 Responsetijden

Voor het DCN wordt als eis gesteld dat de maximale netwerkroundtrip delay tussenaangesloten systemen maximaal 200 ms mag bedragen.

8.7 Beheer

Een DCN dient te voldoen aan de volgende eisen inzake beheer:

(a) Wanneer een DCN na onderhoud of storing door diens beheerder weerbeschikbaar wordt gemaakt, dient de DCN-beheerder dit te melden aan debeheerders van de betrokken ZIM’s en GBZ’en.

(b) Wanneer een DCN door diens beheerder in onderhoud wordt genomen, endus niet langer beschikbaar is, dient de DCN-beheerder dit vooraf te meldenaan de beheerders van de betrokken ZIMs en GBZ’en met een inschattingvan de tijdsduur van onbeschikbaarheid.

(c) De beheerder van een DCN en diens vervangers dienen mettelefoonnummers bekend te zijn bij de beheerder van de ZIM, waarbij altijdtenminste één beheerder bereikbaar is en in staat is de nodige beheertakenuit te voeren.

(d) een DCN dient binnen een nader te specificeren aantal maanden na hetvaststellen van een nieuwe versie van het programma van eisen, te voldoenaan de nieuwe eisen.


(e) op IP-niveau dient men in staat te zijn om, in geval van een door GBZ ofLSP aangemeld probleem, te bepalen in welk domein dit probleem zichbevindt.

(f) Op verzoek moet men in staat zijn metingen te verrichten en te rapporterenaan het LSP over de geleverde en gebruikte bandbreedte per verbinding perGBZ binnen het netwerk.

(g) ten behoeve van de monitoring wordt periodiek informatie ter beschikkinggesteld aan het LSP over de niet-bereikbaarheid van de GBZ-en.


A Invoering burgerservicenummer

A.1 InleidingDe invoering en het gebruik van het burgerservicenummer (BSN) in de zorg zalworden geregeld in een nieuwe “Wet Gebruik BSN in de Zorg”, afgekort WGBZ.Omdat deze wet nog niet is gepubliceerd, wordt teruggevallen op het “Handboekinvoering en gebruik BSN in de zorg voor Koplopers”, zie [BSN].

Identifi-cerendegegevens

Patiëntdossier

(a) overhandigt >Wettelijk

IdentificatieDocument

(b) geeft op >

(c) heeft >

Patiënt/cliënt

Juiste BSN?

Juiste WID?

Juiste dossier?

Zorgaanbieder

De bovenstaande figuur toont de onzekerheden waarmee een zorgaanbieder kanworden geconfronteerd:

(a) de patiënt/cliënt overhandigt een WID, maar behoort deze WID toe aan dezepatiënt/cliënt? En is dit WID wel echt? En is dit WID niet gestolen ofverlopen?

(b) de patiënt/cliënt geeft identificerende gegevens op, maar wat is het BSN(indien niet gegeven)? Of is het BSN wel juist (indien wel gegeven)?

(c) de patiënt/cliënt heeft een dossier bij de zorgaanbieder, maar horen depatiëntgegevens wel bij deze patiënt/cliënt?

In de volgende paragrafen wordt uitgewerkt op welke wijze een zorgaanbieder dezeonzekerheden moet oplossen. Daarbij worden de volgende gevallen onderscheiden:

• Eerste contact met patiënt/cliënt,• Initiële koppeling patiëntgegevens,• Eerste contact met initeel gekoppelde patiënt/cliënt,• Vervolg contact met patiënt/cliënt,• Ontvangst patiëntgegevens.

Daarbij wordt het landelijk patiëntenregister genoemd; dit zal doorgaans de SBV-Zzijn, maar ook het GBA kan als zodanig dienen. Ook wordt een WID-registergenoemd; dat zal via de SBV-Z toegankelijk gemaakt worden.


De laatste paragraaf beschrijft de consequenties voor het landelijk uitwisselen vanpatiëntgegevens.

A.2 Eerste contact met patiënt/cliëntVanaf de inwerkingtreding van de WGBZ moeten zorgaanbieders van allepatiënten/cliënten bij het eerste contact het BSN vaststellen.

Zorgaanbieder


Patiëntdossier



(b) geeft op >

(c) heeft >

WIDregister

Patiëntenregister

(b1) vraagt BSN op >

(b3)legt BSN vast enkoppelt deze voorlopig aanv

^controleertgeldigheid(a3)

^controleert

echtheid(a2)

< controleert gelijkenis (a1)

Patiënt/cliënt

< controleert BSN met (b2)

< controleert dossier met (c1)

(c2)koppelt BSNdefinitief aan

v

< controleert (c3)afwijkingen

< actualiseert zonodig (c4)identificerende gegevens

De bovenstaande figuur toont de werkwijze in een UML collaboration diagram:

(a) de patiënt/cliënt overhandigt een WID, waarop de zorgaanbieder:1. het WID op gelijkenis met de patiënt/cliënt controleert,2. het WID op echtheidskenmerken controleert,3. {toekomst} indien mogelijk de geldigheid van het WID controleert

door raadpleging van een WID-register.

(b) de patiënt/cliënt geeft identificerende gegevens op, mondeling of aan dehand van zijn WID, waarop de zorgaanbieder:

1. op grond van die identificerende gegevens het BSN opvraagt bij hetlandelijke patiëntenregister,

2. het gevonden BSN controleert met die op het WID,3. het BSN vastlegt en deze voorlopig koppelt aan het dossier met

overeenkomende identificerende gegevens.

(c) indien de patiënt/cliënt reeds was ingeschreven bij deze zorgaanbieder,zoekt de zorgaanbieder diens patiëntdossier erbij en:

1. controleert hij of het dossier inhoudelijk bij deze patiënt/cliënt hoorten neemt hij zonodig het dossier door met de patiënt/cliënt,


2. zo ja, koppelt het BSN definitief aan dit dossier,3. controleert of de identificerende gegevens in de lokale patiëntenindex

dan wel het patiëntdossier nog actueel zijn,4. zo nee, vervangt deze zonodig door de actuele gegevens uit het

patiëntenregister of door de gegevens opgegeven door depatiënt/cliënt.

Hierbij kunnen bijzondere situaties optreden:

• Ad (a) een WID kan in de volgende gevallen niet worden overhandigd:o de patiënt/cliënt is niet aanwezig (bijv. telefonisch consult)o de patiënt/cliënt heeft geen WID bij zich (bijv. vergeten)o de patiënt/cliënt heeft geen WID (bijv. minderjarig)

In de eerste twee gevallen moet de patiënt/cliënt zijn WID binnen 14 dagenalsnog overhandigen.

• Ad (b) een BSN kan in de volgende gevallen niet worden opgevraagd ofgeverifieerd:

o het patiëntenregister is tijdelijk niet beschikbaar (bijv. storing)o de patiënt/cliënt heeft geen BSN (bijv. toerist)o de patiënt/cliënt heeft nog geen BSN (bijv. pasgeborene)

In het eerste geval moet de zorgaanbieder het later alsnog proberen.Toeristen kunnen erop gewezen worden dat ze een BSN kunnen krijgen doorinschrijving in het RNI. Voor pasgeborenen moet de ouder of voogd alsnogeen BSN komen opgeven.

• Ad (c) een dossier kan in de volgende gevallen niet worden geverifieerd ofgekoppeld:

o de patiënt/cliënt is niet aanspreekbaar (bijv. bewusteloos)o het dossier is tijdelijk niet beschikbaar (bijv. storing)

In deze gevallen moet de zorgaanbieder dit later alsnog proberen.

Opdat achterstallige controles niet worden vergeten, zal dit per patiënt/cliëntmoeten worden aangegeven met vlaggen in de patiëntenindex of in iederpatiëntdossier, zodat de zorgaanbieder erop wordt geattendeerd bij een vervolg-contact van de patiënt/cliënt. De benodigde vlaggen zijn:

• WID gecontroleerd op gelijkenis met patiënt/cliënt?• WID gecontroleerd op echtheidskenmerken?• {toekomst} Geldigheid WID gecontroleerd?• BSN opgevraagd of geverifieerd?• Dossier inhoudelijk gecontroleerd met patiënt/cliënt?• Identificerende gegevens geactualiseerd?

Opmerkingen:

• Ad (c4) een dossier kan een ander adres bevatten dan het patiëntregister.Dit kan doordat het dossier niet meer actueel is, maar kan ook doordat depatiënt/cliënt bewust een ander adres heeft opgegeven, wegens verblijfaldaar.


A.3 Initiële koppeling patiëntgegevensIn plaats van de druppelsgewijze invoering van het BSN, zie vorige paragraaf, kande zorgaanbieder kiezen voor initiële koppeling door alle ingeschreven, of alleen deactuele, patiënten/cliënten voorafgaand aan de inwerkingtreding van de WGBZbestandsgewijs te koppelen aan een BSN.

Zorgaanbieder


Patiëntdossier

WettelijkIdentificatieDocument

Patiëntenregister

vraagt BSNbestands-

(b2) gewijs op >

Patiënt/cliënt

^bevat(b)

extraheertbestands-

(b1) gewijs >

(b3)koppelt ieder BSNvoorlopig aanv


(a) er zijn géén patiënten/cliënten om een WID te overhandigen.

(b) er zijn géén patiënten/cliënten om identificerende gegevens op te geven,maar de zorgaanbieder kan:

1. deze bestandsgewijs extraheren uit de aanwezige dossiers,2. bestandsgewijs BSN’s opvragen uit het patiëntenregister,3. de gevonden BSN’s voorlopig koppelen aan de dossiers met

overeenkomende identificerende gegevens patiëntgegevens .

(c) er zijn géén patiënten/cliënten om de juistheid van de dossiers tecontroleren.

Aldus zullen (a) en (c) in een later stadium alsnog moeten worden aangepakt, datwil zeggen bij het eerste contact met iedere initieel gekoppelde patiënt/cliënt, ziede volgende paragraaf. Opdat de zorgaanbieder erop wordt geattendeerd dat eenpatiënt/cliënt slechts voorlopig is gekoppeld, zal dit moeten worden aangegevenmet een vlag in de patiëntenindex, dan wel het patiëntdossier.

Reden om initieel te koppelen ligt onder meer in het met terugwerkende krachtkunnen aanmelden van reeds bestaande patiëntgegevens aan de verwijsindex vanhet LSP. Gewoonlijk mogen patiëntgegevens niet worden aangemeld zonder dat destappen (a) en (c) zijn doorlopen, maar ter voorkoming van een lege verwijsindexbij de start van het LSP wordt dat toch toegestaan.


Omdat de meeste zorgaanbieders pas zullen aansluiten op het LSP na deinwerkingtreding van de WGBZ, mag de initiële aanmelding ook worden gedaan bijde eerste aansluiting op het LSP.

A.4 Eerste contact met initieel gekoppelde patiënt/cliëntZoals beschreven in de vorige paragraaf, zal de zorgaanbieder bij het eerstecontact van een initieel gekoppelde (a) en (c) alsnog moeten aanpakken.

Zorgaanbieder


Patiëntdossier



(b) geeft op >

(c) heeft >

WIDregister

(b1)zoekt patiënt/cliëntop inv

^controleertgeldigheid(a3)

^controleert

echtheid(a2)

< controleert gelijkenis (a1)

Patiënt/cliënt

< controleert BSN met (b2)

< controleert dossier met (c1)

(c2)koppelt BSNdefinitief aan

v

< controleert (c3)afwijkingen

< actualiseert zonodig (c4)identificerende gegevens


(a) de patiënt/cliënt overhandigt een WID, waarop de zorgaanbieder handelt alsbij een niet-gekoppelde patiënt.

(b) de patiënt/cliënt geeft identificerende gegevens op, mondeling of aan dehand van zijn WID, waarop de zorgaanbieder:

1. op grond van die identificerende gegevens het BSN opvraagt uit delokale patiëntenindex, dan wel diens patiëntdossier,

2. het gevonden BSN controleert met die op het WID,

(c) indien de patiënt/cliënt reeds was ingeschreven bij deze zorgaanbieder,zoekt de zorgaanbieder zijn dossier erbij en handelt als bij een niet-gekoppelde patiënt.

Merk op dat de situatie overeenkomt met het eerste contact met een niet-gekoppelde patiënt/cliënt, behalve op de punten b1 en b3.


A.5 Vervolg contact met patiënt/cliëntBij elk volgend contact met een patiënt/cliënt moet de zorgaanbieder hemidentificeren aan de hand van gegevens in zijn patiëntenindex, dan wel dienspatiëntdossier.

Zorgaanbieder


Patiëntdossier

WettelijkIdentificatieDocument

(b) geeft op >

(c) heeft >

(b1)zoekt patiënt/cliëntop inv

Patiënt/cliënt

Patiëntenregister

verifieert BSN(b2) eventueel in>


(b) de patiënt/cliënt geeft identificerende gegevens op, waarop dezorgaanbieder:

1. de patiënt/cliënt opzoekt in zijn patiëntenindex, dan wel allepatiëntdossiers,

2. bij twijfel het gevonden BSN verifieert bij het landelijkepatiëntenregister.

In de praktijk zal een zorgaanbieder van een verschijnende patiënt/cliënt niet bijvoorbaat weten of hij reeds gekoppeld is, zijn WID gecontroleerd is, etc. Ditbetekent dat er in de praktijk één procedure moet zijn voor de volgende gevallen:

• Eerste contact met patiënt/cliënt,• Eerste contact met initeel gekoppelde patiënt/cliënt,• Vervolg contact met patiënt/cliënt,

waarbij de vlaggen in de patiëntenindex, dan wel diens patiëntdossier bepalenwelke stappen worden doorlopen.

Deze algemene procedure kan als volgt verlopen:

• identificeren patiënt/cliënt:o de zorgaanbieder probeert de patiënt/cliënt op te zoeken in de lokale

patiëntenindex, dan wel alle patiëntdossiers,o als de patiënt/cliënt niet wordt gevonden of als een vlag aangeeft dat

het BSN nog niet in het landelijke patiëntenregister is opgevraagd ofgeverifieerd, moet de zorgaanbieder dat alsnog doen,

• authenticeren patiënt/cliënt:o als een vlag aangeeft dat het WID nog niet is gecontroleerd met de

patiënt/cliënt, moet de zorgaanbieder dat alsnog doen,


o als een vlag aangeeft dat het WID nog niet is gecontroleerd opechtheidskenmerken, moet de zorgaanbieder dat alsnog doen,

o {toekomst} als een vlag aangeeft dat de geldigheid van het WID nogniet is gecontroleerd, moet de zorgaanbieder dat alsnog doen,

• overnemen naar de patiëntenindex, dan wel diens patiëntdossier:o als een vlag aangeeft dat het dossier nog niet inhoudelijk is

gecontroleerd met de patiënt/cliënt, moet de zorgaanbieder datalsnog doen,

o als een vlag aangeeft dat de identificerende gegevens in depatiëntenindex of het dossier nog niet zijn geactualiseerd, kan dezorgaanbieder dat alsnog doen.

De gebruiksscenario’s in paragraaf 4.2.3 zijn gebaseerd op deze procedure.

A.6 Ontvangst patiëntgegevensWanneer een zorgaanbieder patiëntgegevens (bijv. medicatievoorschrift) ontvangtvan een andere zorgaanbieder, mag hij veronderstellen dat het daarbij vermeldeBSN op de juiste wijze is verkregen.

Zorgaanbieder

Patiëntgegevens

Patiëntdossier

(d) stuurt >

(d2)legt patiëntgegevensvast inv

Anderezorgaanbieder

< ontvangt (d1)


(d) Een andere zorgaanbieder stuurt patiëntgegevens, waarop dezorgaanbieder:

1. deze patiëntgegevens afhandelt zoals bedoeld,2. deze patiëntgegevens na afloop toevoegt aan het patiëntdossier met

hetzelfde BSN.

De ontvangende zorgaanbieder hoeft dus geen controles uit te voeren, ervanuitgaande dat zijn eigen dossier conform de voorschriften is gekoppeld, etc.


A.7 ConsequentiesZoals in de vorige paragrafen beschreven, moet een zorgaanbieder vooriederepatiënt/cliënt de stappen (a), (b) en (c) doorlopen, maar zal dat in depraktijk niet altijd geheel lukken. In dergelijke gevallen zal de zorgverlener gewoonmoeten doorgaan met het vastleggen van patiëntgegevens in zijn dossier, al danniet gekoppeld aan een BSN. Maar het aanmelden bij het LSP, opvragen ofversturen via het LSP, moet alleen onder bepaalde voorwaarden mogelijk zijn.

De onderstaande tabel geeft aan of een GBZ voor een bepaalde patiënt/cliënt hetaanmelden bij het LSP, opvragen of versturen via het LSP mag faciliteren. Met een* wordt aangegeven in welke gevallen een GBZ de zorgverlener moet waarschuwendat bepaalde controles nog niet zijn uitgevoerd voor deze patiënt/cliënt of dat eraanvullende wettelijke voorwaarden aan verbonden zijn. Het is dan verder aan dezorgverlener om het belang van beschikbaarheid van patiëntgegevens af te wegentegen de betrouwbaarheid van de identiteit van de patiënt. Merk op datonderstaande tabel nog kan wijzigen naar aanleiding van de definitieve vaststellingvan de WGBZ en bijbehorende Memorie van Toelichting. Deze wordt begin 2007verwacht.

Kleur code Groen geel oranje rood grijs zwartBSN aanwezig Ja Ja Ja Ja Ja NeeVlaggenBSN opgevraagd of geverifieerd? Ja Ja Ja Nee Nee NeeGelijkenis/echtheid WID gecontroleerd? Ja Ja Nee Ja Nee Neegeldigheid WID gecontroleerd? Ja Nee Nee Nee Nee NeeDossier gecontroleerd met patiënt? Ja Ja Ja/Nee Ja/Nee Nee NeeToegestane interactiesaanmelden aan LSP toegestaan? Ja Ja Ja * Ja * Nee Neeopvragen via LSP toegestaan? Ja Ja Ja * Ja * Ja * Neeversturen via LSP toegestaan? Ja Ja Ja * Nee Nee Nee

Hierbij moet een BSN worden opgevraagd of geverifieerd bij de SBV-Z, al dan nietvia het LSP. Het is verleidelijk een BSN dat is verkregen van een zorgverzekeraar,bijvoorbeeld bij de controle op verzekeringsrecht, te gebruiken als ware hetverkregen van de SBV-Z. Voor de landelijke uitwisseling van medischepatiëntgegevens wordt dat echter onvoldoende betrouwbaar geacht.

De bovengenoemde kleurcodes zijn slechts bedoeld als suggestieve benaming vooreen bepaalde combinatie van vlaggen en niet zozeer om zorgverleners daarmee teconfronteren. De vlaggen vertegenwoordigen condities zoals die binnen een GBZ-applicatie moet worden bijgehouden. Deze vlaggen worden niet landelijkuitgewisseld tussen zorgaanbieders.

Groen is het ideale geval.

Geel is het geval dat een patiënt bij bezoek aan een zorgverlener zijn WID gewoonbij zich heeft, maar dat de zorgverlener de geldigheid van het WID niet kanverifiëren in de SBV-Z, bijvoorbeeld omdat de SBV-Z die functie nog niet levert.

Oranje is het typische geval dat een patiënt bij bezoek aan een zorgverlener zijnWID is vergeten of bijvoorbeeld niet zelf zijn medicijnen bij de apotheek ophaalt.Ook het geval dat een patiënt een telefonisch consult heeft en dus geen WID kantonen, valt hieronder. Oranje is ook het geval als een zorgverlener al zijn


patiëntgegevens op automatische wijze initieel heeft gekoppeld aan het BSN. Hetopgevraagde BSN mag bij uitzondering worden gebruikt, mits de zorgverlenerwordt gewaarschuwd dat het WID nog niet is gecontroleerd. De waarschuwendetekst dient te verwijzen naar de wettelijke verplichtingen onder vermelding vantypische uitzonderingssituaties, zoals hierboven benoemd.

Rood is het typische geval dat een patiënt bij bezoek aan een zorgverlener zijn WIDbij zich heeft, maar dat de zorgverlener noch het BSN noch de geldigheid van hetWID kan verifiëren in de SBV-Z, bijvoorbeeld omdat de SBV-Z tijdelijk nietbeschikbaar is. In principe moet de zorgverlener wachten met het gebruik van hetBSN totdat de SBV-Z weer beschikbaar is en het BSN alsnog geverifieerd wordt. Zokan het aanmelden en versturen van patiëntgegevens ook plaatsvinden nadat depatiënt is vertrokken. In urgente situaties kan echter vaak niet worden gewacht.Het GBZ dient de zorgverlener dus te faciliteren om onder voorwaardenpatiëntgegevens aan te melden en op te vragen via het LSP.

Grijs is het geval dat een onaanspreekbare patiënt zonder WID, maar met anderepapieren voorzien van een BSN, bij een zorgverlener komt. Ook het geval dat eenzorgverlener bepaalde patiëntgegevens met BSN ontvangt anders dan via het LSP,waarbij dus niet geheel zeker is of het BSN is geverifieerd of het WID isgeverifieerd, etc. valt hieronder. In principe mag de zorgverlener een dergelijk BSNniet gebruiken. In noodsituaties kan opvraag van patiëntgegevens via het LSP tochbelangrijker zijn. Het GBZ dient de zorgverlener dus te faciliteren om ondervoorwaarden gegevens op te vragen via het LSP.

Zwart is het geval dat een onaanspreekbare patiënt zonder WID of andere papierenwordt binnengebracht bij een zorgverlener. Er is dus geen BSN en derhalve geenmogelijkheid om op basis van een BSN patiëntgegevens vast te leggen in hetdossier of uit te wisselen via het LSP.

Merk op dat het vastleggen van patiëntgegevens in een patiëntdossier altijd kanplaatsvinden, ook zonder verificatie van het BSN, zoals dat voor de invoering vanhet BSN ook plaatsvindt. Immers, bij de identificatie van de patiënt wordt eenlokaal patiëntnummer bepaald, waaraan een medisch patiëntdossier is gekoppeld.Aan dat lokale patiëntnummer kan door medewerkers een BSN worden gekoppeld,maar dat is voor de behandelende zorgverlener nauwelijks zichtbaar.


B Ongeadresseerde medicatievoorschriften

B.1 InleidingIn de praktijk kan het gebeuren dat een huisarts (voorschrijver) niet weet aan wiehij een medicatievoorschrift moet sturen, omdat zijn patiënt nog niet weet bij welkeapotheek (verstrekker) hij de medicijnen wil afhalen. Vroeger zou hij een recept-briefje zonder geadresseerde apotheker aan de patiënt hebben meegegeven, maarhoe realiseren wij de elektronische tegenhanger van dit ongeadresseerdemedicatievoorschrift?

Deze bijlage doet een voorstel voor een oplossing die voortborduurt op het conceptvan de verwijsindex, zie ook ontwerpbeslissing [B15]. Uiteraard beschouwen wehier alleen de extramurale situatie.


B.2 Oplossing met informatiedoorgeverDe NEN7503 ontwerpnorm beschrijft scenario’s voor recepten verstrekkings-berichten. Voor het geval van het ongeadresseerde medicatievoorschrift1 wordtvoorzien in een intermediaire partij (informatiedoorgever), die feitelijk fungeert alseen openbare postbus. Het scenario verloopt dan als volgt:

• de voorschrijver stuurt een ongeadresseerd medicatievoorschrift naar deinformatiedoorgever,

• de patiënt meldt zich bij een verstrekker,• de verstrekker vraagt alle ongeadresseerde medicatievoorschriften voor die

patiënt op bij de informatiedoorgever• de verstrekker selecteert het door de patiënt gewenste medicatievoorschrift

en meldt dit bij de informatiedoorgever,• de verstrekker verstrekt het medicijn aan de patiënt,• etc.

De onderstaande figuur is overgenomen van NEN 7503, waarbij de stopRecept-AanvraagBerichten van de voorschrijver zijn weggelaten.

Voorschrijver Verstrekker:Informatiedoorgever

receptAanvraagBericht

receptOpvraagBericht

receptSelectieBericht

receptLijstBericht

receptAanvraagBericht

receptVerstrekkingBericht

NEN7503 definieert verder een generiek medicatieAnnuleerBericht, maar beschrijftniet hoe dit in geval van het receptSelectieBericht leidt tot het terugzetten van dereceptaanvraag aan de informatiedoorgever.

De voorschrijver kan een willekeurige arts zijn. De verstrekker is natuurlijk eenstadsapotheek of een ziekenhuisapotheek. Blijft de vraag open, wie of wat de rolvan informatiedoorgever speelt? De ontwerpnorm laat overigens toe dat de rollenvan voorschrijver en informatiedoorgever bij éénzelfde partij liggen. De NEN7503ontwerpnorm geeft dus een abstract model dat op verschillende manieren kanworden ingevuld.

1 Let op: in NEN7503 wordt de volgende terminologie voor een recept gehanteerd:• medicatieopdracht voor de intramurale situatie• receptaanvraag voor de extramurale situatie

Hier wordt algemeen de term medicatievoorschrift gehanteerd.


B.3 Oplossing met verwijsindexDe basisinfrastructuur gaat uit van het principe dat informatie zoveel mogelijk bijde bron blijft. Aldus blijft een ongeadresseerd medicatievoorschrift gewoon bij devoorschrijver, zolang er nog geen verstrekker is geselecteerd. Als de patiënteenmaal een verstrekker heeft gekozen, kan deze verstrekker het ongeadresseerdemedicatievoorschrift gewoon opvragen bij de voorschrijver.

Om een medicatievoorschrift te kunnen opvragen, moet de voorschrijver ditmedicatievoorschrift wel eerst aanmelden bij de verwijsindex. Gewoonlijk wordt eenopdracht niet aangemeld bij de verwijsindex, want een opdracht is voor niemandinteressant anders dan de zorgverlener die deze opdracht toch al ontvangen heeft.Ongeadresseerde opdrachten vormen daarop een uitzondering: ze kunnen wordenaangemeld in de verwijsindex en vervolgens opgevraagd via de verwijsindex,volgens hetzelfde mechanisme als bij de medische patiëntgegevens.

Daarnaast zijn voor een ongeadresseerd medicatievoorschrift nog extra functiesnodig:

• na opvraag moet een verstrekker een medicatievoorschrift kunnenovernemen, waarbij het voorschrift uit de verwijsindex wordt verwijderd. Desituatie is dan alsof het voorschrift direct naar deze verstrekker wasverstuurd. De verdere afhandeling geschiedt vervolgens op dezelfde wijzeals voor directe opdrachten.

• na overname moet een verstrekker het medicatievoorschrift eventueelkunnen teruggeven, waarbij het voorschrift in de verwijsindex wordtteruggezet. De situatie is dan alsof het voorschrift nooit was overgenomen.Zo kan een andere verstrekker het voorschrift overnemen.

aanmeldenOrder

beantwoordenOrder

:Verwijsindex

opvragenOrder

[eventueel] teruggevenOrder

opleverenOrder

overnemenOrder

opvragenOrder

opleverenOrder

Opdrachtgever:Zorgverlener Opdrachtnemer:Zorgverlener

De bovenstaande figuur toont het afhandelen van een ongeadresseerde opdracht.Niet getoond is dat de aanvrager ná overname van de opdracht, maar vóórontvangst van een resultaat, de opdracht nog kan annuleren.


Deze oplossing wijkt nauwelijks af van de NEN7503 ontwerpnorm. Immers deverwijsindex speelt de rol van informatiedoorgever, behalve dat de verwijsindexniet het ongeadresseerde medicatievoorschrift zelf, maar de verwijzing daarnaar,bevat.

B.4 OntwerpkeuzesIn het bovenstaande voorstel zijn impliciet een aantal keuzes gemaakt die hierworden besproken:

• Iedere medicatie wordt als aparte opdracht aangemeld in de verwijsindex.Daardoor is het ingewikkelde mechanisme van NEN7503 niet nodig, waarbijbepaalde medicatieregels worden geselecteerd.

• Bij het opvragen van ongeadresseerde opdrachten via de verwijsindex werkthetzelfde mechanisme als bij het opvragen van medische patiëntgegevens,dus inclusief autorisatie en logging. Zo kan bijv. worden voorkomen datandere partijen dan apotheken ongeadresseerde medicatievoorschriftengaan opvragen.

• Bij het overnemen van een ongeadresseerde opdracht wordt deopdrachtgever niet geïnformeerd door de verwijsindex. Net als bij hetplaatsen van een directe opdracht, kan de opdrachtgever ook bij hetaanmelden van een ongeadresseerde opdracht aangeven dat hij eenexpliciete acceptatie van de opdracht verwacht. De opdrachtnemer kan deopdracht dan zelf direct naar de opdrachtgever beantwoorden met eenacceptatie, buiten de verwijsindex om.

• Na het overnemen van een ongeadresseerde opdracht kan blijken dat deopdrachtnemer de opdracht toch niet kan uitvoeren. Bij een directe opdrachtkan de opdrachtnemer deze direct naar de opdrachtgever beantwoorden meteen afwijzing. Maar dat zou betekenen dat de opdrachtgever de opdrachtopnieuw moet aanmelden bij de verwijsindex. Daarom is hier gekozen voorhet teruggeven van de opdracht aan de verwijsindex, alsof er niks wasgebeurd.

• Het teruggeven van een opdracht aan de verwijsindex komt neer op hetopnieuw aanmelden in de verwijsindex. In afwijking van het normalemechanisme heeft de aanmelding betrekking op gegevens die bij een anderliggen dan degene die de aanmelding doet. Misschien is het beter om deongeadresseerde opdracht niet eerder uit de verwijsindex te verwijderen,dan wanneer de opdrachtnemer de opdracht al heeft beantwoord aan deopdrachtgever met een acceptatie. Overigens kent NEN7503 geen berichtvoor het teruggeven van een receptaanvraag.

• Als een opdrachtnemer een opdracht al heeft beantwoord aan deopdrachtgever met een acceptatie, kan hij de opdracht niet meerteruggeven aan de verwijsindex. Net als bij een directe opdracht, kan hij deopdracht alleen nog maar direct afwijzen naar de opdrachtgever. De laatstezal de opdracht opnieuw moeten aanmelden.


C Bundelen, groeperen, doseren en sorteren

C.1 InleidingMoet de ZIM de resultaten op queries van verschillende opleverende GBZ’enkunnen bundelen, groeperen, doseren en sorteren bij het terugsluizen van deresultaten naar het opvragende GBZ?

HL7v3 biedt deze mogelijkheden bij de communicatie tussen twee zorgsystemen,maar in combinatie met een tussenliggende ZIM rijzen enkele vragen. Deze bijlageanalyseert deze vragen en komt tot een aantal ontwerpbeslissingen.

Tenslotte geeft deze bijlage een uitwerking van de scenario’s die aldus wordenondersteund en waaruit een opvragende GBZ kan kiezen:

• niet bundelen, niet doseren,• niet bundelen, wel doseren,• wel bundelen, niet doseren,• wel bundelen, wel doseren.

C.2 AchtergrondWanneer de ZIM een opvraag ontvangt van een GBZ0, zal de ZIM deze opvraagdivergeren naar alle GBZ’en waarvan in de verwijsindex is aangegeven dat zeantwoord hebben op deze opvraag. Daarbij kan sprake zijn van meerdere GBZ1,GBZ2, GBZ3, etc. die ieder vele resultaten opleveren, zie onderstaande figuur,waarbij iedere pijl een individueel resultaat voorstelt.

opvraag

resultaat12

resultaat11

resultaat13

resultaat22

resultaat21

resultaat23

resultaat32

resultaat31

resultaat33

GBZ0:Zorgverlener

ZIM GBZ2

GBZ1

GBZ3

opvraag2

resultaat22

resultaat21

resultaat23

opvraag3

resultaat32

resultaat31

resultaat33

opvraag1

resultaat12

resultaat11

resultaat13

HL7v3 geeft een opleverend GBZ in principe de vrijheid om de resultatenindividueel of gegroepeerd in berichten op te leveren. Anderzijds geeft HL7v3 eenopvragend GBZ de mogelijkheid af te dwingen dat alle opleverberichten in één


allesomvattend bericht (batch) worden gebundeld. Daarnaast geeft HL7v3 demogelijkheid van doseren en sorteren van de resultaten.

Dit betekent dat de tussenliggende ZIM de berichtenstroom moet coördineren,rekening houdend met de wensen van het opvragende GBZ en de vrijheden van deopleverende GBZ’en. Echter, er moet worden voorkomen dat de ZIM overbelastraakt door teveel keuzevrijheid van de aangesloten GBZ’en.

C.3 VraagstellingHL7v3 biedt een opleverend GBZ in principe de vrijheid om de resultaten tegroeperen alvorens deze in berichten op te leveren:

• groeperen betekent dat het opleverende GBZ meerdere of alle resultaten inéén opleverbericht plaatst. Dit is zo doelmatig dat een GBZ dit eigenlijkaltijd zou moeten doen, maar als de resultaten niet allemaal ineens kunnenworden opgeleverd, kan het nuttig zijn de resultaten te verdelen overmeerdere opleverberichten.

HL7v3 biedt het opvragende GBZ de mogelijkheid om in het opvraagbericht tevermelden dat de resultaten gebundeld, gedoseerd en/of gesorteerd moetenworden opgeleverd:

• bundelen betekent dat het opvragende GBZ alle opleverberichten éénallesomvattend bericht (batch) wil ontvangen. Dit kan nuttig zijn voor eenapplicatie omdat deze dan voor ieder opvraagbericht precies één oplever-bericht ontvangt.

• doseren betekent dat het opvragende GBZ kan aangeven hoeveel resultatenmaximaal mogen worden opgeleverd. De overige resultaten kunnen metvervolgopvragen worden opgeleverd. Dit kan nuttig zijn als er zeer veelresultaten zijn, terwijl niet alle resultaten ineens verwerkt kunnen worden.

• sorteren betekent dat het opvragende GBZ kan aangeven dat het alleresultaten in een bepaalde volgorde ontvangt. Dit kan nuttig zijn voor eenapplicatie die de resultaten op volgorde van een bepaald kenmerk wilpresenteren.

De vraag is of de ZIM deze mogelijkheden ook echt moet bieden, want dat kan insommige combinaties betekenen dat de ZIM eerst alle resultaten van deopleverende GBZ’en moet verzamelen, met alle gevaar van overbelasting van deZIM.

C.3.1 GroeperenGroeperen betekent dat het opleverende GBZ meerdere of alle resultaten in éénopleverbericht plaatst, aangenomen dat er meerdere resultaten kunnen zijn.Groeperen is zo doelmatig dat een GBZ dit eigenlijk altijd zou moeten doen. Echter,soms kunnen de resultaten niet allemaal ineens worden opgeleverd, bijv. omdateen GBZ verschillende dossiers heeft die niet allemaal even snel kunnen opleveren.Of omdat een GBZ een maximum aantal resultaten per keer aanhoudt, tervoorkoming van het overstromen van buffers. In dergelijke gevallen kan het nuttigzijn de resultaten te verdelen over meerdere opleverberichten.


Daarom biedt HL7v3 een opleverend GBZ in principe de keuze om de resultaten alof niet te groeperen, alvorens deze in berichten op te leveren. Niet groeperen heeftals consequentie dat het opvragende GBZ na ontvangst van het eerste oplever-bericht één of meer vervolgopvraagberichten moet uitsturen om alle resultaten teverzamelen. Aldus wordt het opvragende GBZ ongevraagd gedwongen totgedoseerd opvragen.

HL7v3 schrijft voor dat de resultaten als gegroepeerde payload binnen deControlAct Wrapper van een opleverbericht wordt geplaatst, zie de onderstaandefiguur.

Transmission Wrapper

ControlAct Wrapper

Payload: resultaat2

Payload: resultaat1

Payload: resultaat3

Een voorwaarde voor het groeperen is dat de resultaten allemaal van hetzelfde typezijn, dat wil zeggen, dat de opgeleverde patiëntstukken allemaal dezelfdegegevenssoort hebben. Als dat niet het geval is, moet het opleverende GBZ deresultaten per type groeperen in afzonderlijke opleverberichten. Wel kunnen dieopleverberichten weer worden gebundeld in één allesomvattend opleverbericht,maar daar moet de opvragende partij dan wel om gevraagd hebben, zie onderBundelen.

Voor de ZIM zou het goed uitkomen als alle opleverende GBZ’en altijd alleresultaten in één opleverbericht zouden groeperen. Of dit afgedwongen kanworden, hangt echter mede af van de zorgapplicatie en de daarbij betrokkengegevenssoorten.

Ontwerpbeslissing: per zorgtoepassing en gegevenssoort moet worden bepaaldof de opleverende GBZ’en alle resultaten moeten groeperen binnen de ControlActWrapper van één opleverbericht.

Merk op dat de ZIM niet zelf kan groeperen ten behoeve van de opvragende GBZ,want daarvoor zou de ZIM de ControlAct Wrappers moeten uitpakken en daarmeezou belangrijke informatie verloren gaan. Bundelen van de verschillende, al danniet gegroepeerde, opleverberichten is natuurlijk wel mogelijk.

C.3.2 BundelenBundelen betekent dat het opvragende GBZ alle opleverberichten éénallesomvattend bericht (HL7: batch) wil ontvangen. Bundelen kan nuttig zijn vooreen applicatie omdat deze dan voor ieder opvraagbericht precies één gebundeldopleverbericht ontvangt. Voor de belasting van het netwerk kan het voordelig zijnéén gebundeld bericht te hebben in plaats van veel kleine opleverberichten, maarafhankelijk van de grootte van het antwoord en het aantal resultaten kan dit ookjuist nadelig uitpakken. Het is aan de applicatie om al of niet gebruik te maken vanbundelen.


HL7v3 biedt de opvragende partij de mogelijkheid om n de ControlAct Wrapper deresponseModalityCode op Batch of RealTime te zetten. HL7v3 schrijft voor dat deopleverende partij de samen te voegen berichten met de Transmission Wrapper ineen Batch Wrapper plaatst, zie de onderstaande figuur.

Batch Wrapper


ControlAct Wrapper

Payload: resultaat12




ControlAct Wrapper




De ZIM is goed in staat om de opleverberichten van de verschillende GBZ’en tekunnen bundelen tot één allesomvattend opleverbericht. Dus kan een verzoek vaneen opvragende GBZ voor al of niet bundelen door de ZIM worden gehonoreerd.Paragraaf C.4.3 toont hoe dit bundelen uitpakt voor het berichtenverkeer.Paragraaf C.4.1 toont hoe het opvragende GBZ anders wordt gedwongen totvervolgopvraagberichten.

Ontwerpbeslissing: de ZIM moet op verzoek van een opvragende GBZ deopgevraagde resultaten van de opleverende GBZ’en bundelen tot éénallesomvattend opleverbericht aan het opvragende GBZ.

De vraag is dan vervolgens: moet de ZIM aan ieder opleverend GBZ ook om eengebundeld opleverbericht vragen? Het antwoord is nee, omdat dit geen voordelenoplevert. Zelfs als een opleverende GBZ zou besluiten niet te groeperen, zou deZIM alle afzonderlijke opleverberichten van dat GBZ kunnen verzamelen in hetgebundelde opleverbericht.

Ontwerpbeslissing: de ZIM moet opleverende GBZ’en nooit om een gebundeldopleverbericht vragen.

C.3.3 DoserenDoseren betekent dat het opvragende GBZ kan aangeven hoeveel resultatenmaximaal mogen worden opgeleverd. De overige resultaten kunnen dan metvervolgopvragen worden opgeleverd. Doseren is zinvol indien een opvraag kanleiden tot meer resultaten dan het opvragende GBZ, de ZIM of het datacom-netwerk ineens kan verwerken. Een opvragende GBZ heeft bij voorkeur zodanigruime buffers dat doseren niet nodig is, maar die buffer heeft altijd een maximumomvang.


Gedoseerd opvragen bij de ZIM heeft overigens weinig te maken met het eventueelgedoseerd presenteren van de resultaten aan de gebruiker. Voor de presentatie-logica is het meestal nodig dat alle resultaten binnen zijn, bijv. om ze te kunnensorteren op verschillende kenmerken.

HL7v3 biedt de mogelijkheid om in de ControlAct Wrapper van een opvraagbericht(Query Request) een maximum aantal resultaten (initialQuantity) te vermelden,waarmee de opvragende GBZ impliciet een sessie opent met de volgende opvraag-commando’s:

• Query Spec: voor het starten van de sessie en de eerste opvraag,• Query Continuation: voor de tweede en volgende opvraag,• Query Cancel: voor het afsluiten van de opvraagsessie.

De ControlAct Wrapper van het opleverbericht (Query Response) moet steedsvermelden: dit is resultaat X van een totaal Y en er zijn nog Z resultaten over,waarbij:

X = resultCurrentQuantityY = resultTotalQuantityZ = resultRemainingQuantity

In de ControlAct Wrapper van een vervolgopvraag kan een maximum aantalresultaten (continuationQuantity) en een volgnummer van het eerstvolgenderesultaat (startResultNumber) worden vermeld. Bij verstek geldt het maximum vanhet eerste opvraagbericht en het volgnummer van het eerstvolgende nog nietopgeleverde resultaat.

Ontwerpbeslissing: de ZIM moet opleveringen op verzoek van een opvragendeGBZ kunnen doseren, omwille van een doelmatige afhandeling van deberichtenstroom.

De vraag is dan vervolgens: moet de ZIM iedere gedoseerde opvraag ookgedoseerd doorzetten naar de opleverende GBZ’en? Het antwoord is JA, omdat deopleverende GBZ’en anders opleverberichten met teveel resultaten kunnenopleveren, die de ZIM dan zou moeten opsplitsen. Paragraaf C.4.2 toont hoe ditdoseren uitpakt voor het berichtenverkeer.

Ontwerpbeslissing: de ZIM moet een gedoseerde opvraag ook gedoseerddoorzetten naar de opleverende GBZ’en, met dezelfde dosis, omwille van eendoelmatige afhandeling van de berichtenstroom.

Een opleverende GBZ heeft de vrijheid een maximum aan te houden voor aantalresultaten per opleverbericht. Daarmee kan de ZIM worden gedwongenvervolgopvragen te doen, ook als de ZIM niet om doseren had gevraagd.

Ontwerpbeslissing: de ZIM moet altijd rekening houden met een GBZ datongevraagd gedoseerd oplevert en zonodig vervolgopvraagberichten sturen.

Als een opvragende GBZ in een vervolgopvraag een maximum aantal resultatenen/of een volgnummer zou mogen opgeven die afwijken van die in het eersteopvraagbericht, zou de ZIM de berichtenstroom niet goed kunnen optimaliseren,bijv. door opvraagberichten parallel te divergeren naar opleverende GBZ’en.


Ontwerpbeslissing: de ZIM mag een vervolgvraag van een opvragende GBZweigeren indien deze een maximum aantal resultaten en/of een volgnummer bevat.

Een oudere versie 2.3 van dit document bevat nog een beschouwing van deverschillende manieren waarop de ZIM zuinig of kwistig en serieel of parallel deopleverende GBZ’en zou moeten bevragen. Die beschouwing leidde niet tot eenontwerpbeslissing en is hier daarom weggelaten. Niettemin kan die beschouwingnuttig zijn voor de bouwer van de ZIM.


C.3.4 SorterenSorteren betekent dat het opvragende GBZ kan aangeven dat het alle resultaten ineen bepaalde volgorde wil ontvangen. Sorteren kan zinvol zijn als een opvragendGBZ de resultaten gedoseerd én gesorteerd wil presenteren. Als de ZIM deopgevraagde resultaten niet gesorteerd zou kunnen opleveren, zou het opvragendeGBZ alle resultaten moeten afwachten om de resultaten zelf te kunnen sorterenalvorens deze te presenteren. Daarmee zouden de voordelen van doseren vaakteniet worden gedaan.

Echter, als de ZIM alle resultaten gesorteerd moet opleveren, zal de ZIM in principeeerst álle resultaten moeten opvragen bij de achterliggende GBZ’en, en dezevervolgens sorteren, voordat de ZIM de eerste resultaten kan opleveren aan hetopvragende GBZ. Dat betekent feitelijk dat het sorteerprobleem van het GBZ naarde ZIM zou worden verplaatst.

Het sorteren door de ZIM in plaats van door het GBZ, heeft bovendien enkelebelangrijke nadelen:

• Als het opvragende GBZ zelf ook resultaten heeft, zou de ZIM die resultateneerst bij dit GBZ moeten opvragen, om ze na sorteren, samen met deresultaten van andere GBZ’en, weer terug te leveren aan het opvragendeGBZ.

• Sorteren kan heel veel geheugenruimte van de ZIM vergen, vooral alsandere GBZ’en tegelijkertijd hetzelfde willen. Alleen als de opleverendeGBZ’en in staat zijn gesorteerd op te leveren, zou de ZIM met parallel enzuinig gedoseerd opvragen van opleverende GBZ’en, dit eventueel kunnenvoorkomen. Maar dan moeten de achterliggende GBZ’en ook gesorteerdkunnen opleveren; dat kunnen niet alle GBZ’en.

• na het gesorteerd opleveren van resultaten aan een GBZ, zou eenzorgverlener diezelfde resultaten nog eens op een andere wijze (oplopendversus aflopend, of op basis van ander kenmerk) willen sorteren. Datbetekent dat een GBZ alsnog moet sorteren. De waarde van het gesorteerdopleveren vanaf de ZIM is dus vaak beperkt.

Ontwerpbeslissing: de ZIM moet een verzoek van een opvragende GBZ voor hetsorteren van resultaten weigeren.


C.4 Scenario’s van bundelen en doserenDeze paragraaf geeft een uitwerking van de verschillende combinaties vanbundelen en doseren. De volgende combinaties zijn mogelijk en moeten door deZIM worden ondersteund. Een opvragende GBZ kan kiezen welke combinatie vooreen bepaalde zorgtoepassing het meest geschikt is:

1. GBZ vraagt om NIET bundelen en NIET doseren2. GBZ vraagt om NIET bundelen en WEL doseren3. GBZ vraagt om WEL bundelen en NIET doseren4. GBZ vraagt om WEL bundelen en WEL doseren

De opvragende GBZ geeft zijn keuze als volgt aan in de ControlAct Wrapper van hetopvraagbericht:

• responseModalityCode=B betekent WEL bundelen• responseModalityCode=R betekent NIET bundelen• initialQuantity= N betekent WEL doseren (eigenlijk maximeren, maar dat

leidt dan tot vervolgopvragen, dus doseren)• geen initialQuantity betekent NIET doseren (maar als een opleverende GBZ

of de ZIM zelf besluit tot maximeren, zijn alsnog vervolgopvragen nodig.

Alle scenario’s gaan uit van een situatie waarbij:• GBZ1 heeft 2 zoekresultaten• GBZ2 heeft 5 zoekresultaten• GBZ3 heeft 13 zoekresultaten

Voor elk scenario geldt dat de ZIM in ieder opleverbericht moet aangeven dat ernog meer resultaten zijn door het aanpassen van de resultRemainingQuantity in deControlAct Wrapper. Dit is als volgt afgebeeld:

“oplevering (X van Y rest Z)” vertegenwoordigt een ControlAct Wrapper met:X = resultCurrentQuantityY = resultTotalQuantityZ = resultRemainingQuantity

Een ? vertegenwoordigt nullFlavor=”NAV”, zie “Implementatiegids HL7 v3Infrastructurele Domeinen” versie 2.3, paragraaf 2.5.3.


C.4.1 Niet bundelen, niet doserenIn dit scenario stuurt de opvragende GBZ een opvraagbericht naar de ZIM waarin:

• responseModalityCode=R, dus NIET bundelen• zonder initialQuantity, dus NIET doseren

De ZIM stuurt het opvraagbericht door naar de GBZ’en genoemd in de VWI, waarin:• responseModalityCode=R, dus NIET bundelen• zonder initialQuantity, dus NIET doseren

GBZ0:Zorgverlener

ZIM GBZ2

opvraag (R, alles)opvragen (alles)

GBZ1 GBZ3

opvraag (R, alles)

presenteren (2)oplevering (2 van ? rest ?)

opvraag (R, alles)

opvraag (R, alles)

vervolgopvraag ()

oplevering (5 van 20 rest 13)presenteren (5)

vervolgopvraag ()


oplevering (2 van 2 rest 0)



Voordelen van dit scenario zijn:

• de ZIM kan na de ontvangst van de eerste oplevering, deze onmiddellijkdoorzetten naar de opvragende GBZ0. Dit kan nuttig zijn als het belangrijkis de gebruiker snel resultaten te tonen, zonder dat alle resultaten meteencompleet hoeven te zijn. Dit kan ook gunstig uitpakken voorzorgtoepassingen waarbij gewoonlijk maar één GBZ als bron optreedt.

Nadelen van dit scenario zijn:

• de opvragende GBZ0 moet voor elke opleverende GBZ de resultaten bij deZIM ophalen. Over het geheel is dat minder doelmatig dan bij WELbundelen.

• doordat de ZIM begint met opleveren voordat alle resultaten binnen zijn,kan de ZIM nog niet meteen vertellen hoeveel resultaten er in totaal zijn.

Opmerkingen:

• de opvragende GBZ0 wilde alles ongedoseerd hebben, maar wordt tochgedwongen tot vervolgopvraagberichten. Dit is omdat de ZIM geenopleverberichten (met name de ControlAct Wrapper) mag uitpakken en dusniet alle resultaten van verschillende bronnen kan bundelen in éénopleverbericht. Niet afgebeeld is dat een opleverende GBZ ongevraagd eenmaximum kan aanhouden voor het aantal resultaten in een opleverbericht.De ZIM wordt dan ook gedwongen tot vervolgopvraagberichten.


C.4.2 Niet bundelen, wel doserenIn dit scenario stuurt de opvragende GBZ een opvraagbericht naar de ZIM waarin:

• responseModalityCode=R, dus NIET bundelen• initialQuantity=10, dus WEL doseren

De ZIM stuurt het opvraagbericht door naar de GBZ’en genoemd in de VWI, waarin:• responseModalityCode=R, dus NIET bundelen• initialQuantity=10, dus WEL doseren

GBZ0:Zorgverlener

ZIM GBZ2

opvraag (R, 10)opvragen (alles)

GBZ1 GBZ3

opvraag (R, 10)

presenteren (2)oplevering (2 van ? rest ?)

opvraag (R, 10)

opvraag (R, 10)

vervolgopvraag ()





opvraag (R, 3)vervolgopvraag ()

vervolgopvraag ()




Voordelen en nadelen van dit scenario zijn dezelfde als voor NIET bundelen en NIETdoseren, behalve dat de dosering dit scenario over het geheel genomen iets tragerkan maken. Dat gebeurt echter alleen als er een opleverende GBZ is die meerresultaten heeft dan de gevraagde initialQuantity.

Opmerkingen:

• De enige zinvolle reden van een opvragende GBZ om te kiezen voordosering, is het zichzelf beschermen tegen een overstroming van de buffer.Dan gaat het niet om een initialQuantity van 10, zoals in de figuur, maar omhet echte maximum aantal resultaten dat de GBZ ineens kan verwerken.Overigens laat de omvang van een resultaat zich moeilijk schatten. Zo kanbijv. een medicatievoorschrift in omvang fors variëren.

• Ten aanzien van de opleverende GBZ’en hanteert de ZIM dezelfde dosis alsde opvragende GBZ hanteert. Dit garandeert dat de ZIM alle ontvangenopleverberichten probleemloos kan doorschuiven naar de opvragende GBZ.Dit kan alleen misgaan als GBZ0 voor de vervolgvraag de dosis verlaagt,bijv. “vervolgopvraag (max 5)”. Dan kan de ZIM het klaarstaandeopleverbericht met 10 resultaten niet kwijt aan GBZ0 en moet antwoordenmet “oplevering (0 van 20 rest 18)”.


C.4.3 Wel bundelen, niet doserenIn dit scenario stuurt de opvragende GBZ een opvraagbericht naar de ZIM waarin:

• responseModalityCode=B, dus WEL bundelen• zonder initialQuantity, dus NIET doseren

De ZIM stuurt het opvraagbericht door naar de GBZ’en genoemd in de VWI, waarin:• responseModalityCode=R, dus NIET bundelen• zonder initialQuantity, dus NIET doseren

GBZ0:Zorgverlener

ZIM GBZ2

opvraag (B, alles)opvragen (alles)

GBZ1 GBZ3

opvraag (R, alles)

presenteren (20)batch (oplevering (2 van 20 rest 18), oplevering (5 van 20 rest 13), oplevering (13 van 20 rest 0))



opvraag (R, alles)

opvraag (R, alles)



• voor de opvragende GBZ is dit de meest eenvoudige interactie met de ZIM:één opvraag en één opleverbericht.

• als de opvragende GBZ alle resultaten ontvangen moet hebben voordat dieverwerkt of gepresenteerd kunnen worden, is dit het snelste scenario.


• als er veel resultaten zijn, kan de gebundelde oplevering erg grootuitpakken. De opvragende GBZ0 moet daarop voorbereid zijn. De ZIM ook,want die moet vele opvraagsessies tegelijk kunnen bedienen.

• het kan even duren voordat de opvragende GBZ het opleverberichtontvangt, omdat de ZIM moet wachten totdat alle opleveringen binnen zijn.Als sommige opleverende GBZ’en een eigen maximum hanteren bij hetgroeperen van resultaten, wordt de ZIM gedwongen tot een vervolgopvraagen kan het nog langer duren.

Opmerkingen:

• uit de figuur blijkt dat het geen zin heeft voor de ZIM om van deopleverende GBZ’en een gebundeld opleverbericht te vragen.

• niet afgebeeld is dat een opleverende GBZ ongevraagd een maximum kanaanhouden voor het aantal resultaten in een opleverbericht. De ZIM wordtdan alsnog gedwongen tot vervolgopvraagberichten.


C.4.4 Wel bundelen, wel doserenIn dit scenario stuurt de opvragende GBZ een opvraagbericht naar de ZIM waarin:

• responseModalityCode=B, dus WEL bundelen• initialQuantity=10, dus WEL doseren

De ZIM stuurt het opvraagbericht door naar de GBZ’en genoemd in de VWI, waarin:• responseModalityCode=R, dus NIET bundelen• initialQuantity=10, dus WEL doseren

GBZ0:Zorgverlener

ZIM GBZ2

opvraag (B, 10)opvragen (alles)

GBZ1 GBZ3

opvraag (R, 10)

presenteren (7)batch (oplevering (2 van 20 rest 18), oplevering (5 van 5 rest 13) )



opvraag (R, 10)

opvraag (R, 10)


vervolgopvraag ()


opvraag (R, 10)

batch (oplevering (10 van 13 rest 3) )

vervolgopvraag ()

batch (oplevering (3 van 3 rest 0) )

presenteren (10)

presenteren (3)


• zolang er geen opleverende GBZ is die meer resultaten heeft dan degevraagde initialQuantity, kan dit doelmatig uitpakken, met eenbescherming tegen overstroming van de buffers.


• voor de opvragende GBZ is dit de meest complexe berichtverwerking:gebundelde opleverberichten moeten worden uitgepakt en er moetenmogelijk vervolgopvraagberichten worden verzonden.

Opmerkingen:

• hier gelden dezelfde opmerkingen als voor NIET bundelen en WEL doseren.

• de ZIM moet in iedere gebundeld opleverbericht aangeven dat er nog meergebundelde opleverberichten zijn door het aanpassen van deresultRemainingQuantity in de ControlAct Wrapper.


D Adresseren

Deze bijlage is niet normatief en dient slechts voor een beter begrip van desamenhang tussen de verschillende mechanismen voor adresseren op deverschillende communicatieniveaus. Merk op dat het woord adresseren hier in demeest ruime zin wordt bedoeld.

D.1 InleidingBij het landelijk uitwisselen van patiëntgegevens tussen zorgaanbieders, wordendeze patiëntgegevens verstuurd in een HL7-bericht, wordt dit ingepakt in eenSOAP-envelop, voorzien van een HTTP-header, een TCP-header en een IP-headeralvorens deze over het netwerk wordt gerouteerd, zie de onderstaande figuur.

TCP header

IP header

A B

zorgaanbieder zorgaanbieder

SOAPclient

SOAPserver

HTTPclient

HTTPserver URL

Applicatieid

IP-adresPoort-nr

UZI-nr,URA

TCP header

HTTP header

SOAPenvelope

HL7transmission

wrapper

HL7controlactwrapper

bronapplicatie

doelapplicatie

HL7sender

HL7receiver

HL7payload

IPhandler

TCPhandler

IPhandler

TCPhandler

Op al deze commmunicatieniveaus moet de juiste adressen worden gehanteerd omzeker te stellen dat de patiëntgegevens op de juiste plek worden afgeleverd. In devolgende paragrafen wordt het principe van adresseren voor ieder niveaubehandeld:

• Inhoud: HL7v3 Payload en ControlAct Wrapper• Envelop: HL7v3 Transmission Wrapper• Transport: HTTP/SOAP• Verbinding: TCP/IP

Vervolgens worden de principes toegepast in de situatie dat een ZIM optreedt alsintermediair tussen zorgaanbieders. Daarbij wordt apart behandeld:

• het opvragen van patiëntgegevens,• het versturen van patiëntgegevens.


D.2 Inhoud: HL7v3 Payload en ControlAct WrapperDeze paragraaf beschouwt de wijze waarop de HL7v3-berichtinhoud wordt gerichtaan de juiste bestemming. De onderstaande figuur geeft een voorbeeld van hoeeen opdrachtbericht (HL7: order) kan worden gericht aan een zorgaanbieder.

A B


a1

zorgverlener

a2

medewerker

b2

zorgverlener

b1

medewerker

Informatiebron Informatiedoel

HL7v3 control act wrapper:

Author or Performer

Overseer

Information Recipient

HL7v3 payload:

Author or PerformerResponsible Partyrequested Performer

zorgapplicatie

zorgapplicatie

In de HL7v3 Payload kan onder meer worden aangegeven, inzien zinvol:• de requested Performer als beoogde uitvoerder van een verzoek. Dit kàn

binnen een zorgapplicatie worden gebruikt om de berichtinhoud onder ogenvan de beoogde uitvoerder te brengen.

In de HL7v3 ControlAct Wrapper kàn als informatiedoel worden aangegeven, indienzinvol:

• de Information Recipient als zorgaanbieder die de berichtinhoud onder ogenmoet krijgen.

De bovenstaande identificaties zijn alleen zinvol in geval van een opdrachtberichten zelfs dan zijn ze niet altijd aanwezig, afhankelijk van de zorgtoepassing.

In de HL7v3 ControlAct Wrapper moet als informatiebron worden aangegeven:• de AuthorOrPerformer als zorgverlener of gemandateerde medewerker die

het bericht heeft verstuurd,• de Overseer als verantwoordelijke, eventueel mandaterende, zorgverlener.

Als er geen sprake is van mandateren is de Author or Performer gelijk aande Overseer.


Zowel in de HL7v3 Payload als in de HL7v3 ControlAct Wrapper wordeninformatiebron en informatiedoel telkens aangeduid aan de hand van:

• het UZI-nummer, dit wordt gebruikt om een specifieke persoon teidentificeren: zorgverlener of medewerker,

• het UZI-abonneenummer (URA), dit wordt gebruikt om de omvattendeorganisatie te identificeren: de zorginstelling, de huisartspraktijk, deapotheek, etc.

• de rolCode, dit kan worden gebruikt om de zorgverlenerfunctie van dezorgverlener aan te duiden, of anders de functiegroep binnendezorgaanbieder als er geen specifieke zorgverlener was genoemd.

Zo wordt een opdrachtbericht (bijv. medicatievoorschrift) meestal gericht aan eenzorgaanbieder (bijv. apotheker) en niet aan een zorgverlener (bijv. apotheek). Ingeval van een grote zorgaanbieder (bijv. ziekenhuis met verschillendespecialismen) kan een opdrachtbericht (bijv. verwijsbrief) worden gericht aan eenspecifieke zorgverlenerfunctie (bijv. orthopedie), waarbij de dienstdoendezorgverlener de verantwoordelijkheid voor de opdracht op zich neemt.

Zie verder [HL7v3 Infra], [HL7v3 ZIM] en de implementatiehandleidingen van despecifieke zorgtoepassingen.


D.3 Envelop: HL7v3 Transmission WrapperDeze paragraaf beschouwt de wijze waarop een HL7v3-envelop wordt geadresseerdaan de juiste bestemming.

HL7v3 transmission wrapper:

Sender:device.id applicatie-idorganisation.id URA

Receiver:device.id applicatie-idorganisation.id URA

HL7v3 control act wrapper

HL7v3 payload

HL7applicatie

poortapplicatie

zorgapplicatie

zorgapplicatie

HL7sender

HL7sender

HL7applicatie

poortapplicatie

zorgapplicatie

zorgapplicatie

HL7receiver

HL7receiver

De bovenstaande figuur toont hoe op dit niveau applicaties als afzender en alsontvanger worden geadresseerd, telkens in de vorm van:

• de applicatie-id van de zorgapplicatie die de HL7v3-berichtinhoud moetverwerken, vooral belangrijk als de zorgaanbieder meerdere zorgapplicatiesheeft,

• het UZI-abonneenummer (URA) van de verantwoordelijke organisatie: dezorginstelling, de huisartspraktijk, de apotheek, etc.

Als ontvanger moet de identificatie worden aangegeven van de zorgapplicatie dieervoor zorgt dat de HL7-berichtinhoud onder ogen komt van de beoogdezorgaanbieder. Dit hoeft niet de applicatie te zijn bij wie het HL7v3-bericht wordtafgeleverd. Zo kan een poortapplicatie (bijv. als onderdeel van een communicatie-server) alle HL7-berichten van een zorginstelling ontvangen, waarna deze op basisvan de applicatie-id kan besluiten dat het bericht voor een andere applicatie is.

Als afzender moet de identificatie worden aangegeven van de applicatie die eeneventueel retourbericht kan verwerken namens de zendende author or performer.Naar analogie van het bovenstaande hoeft dit weer niet de zorgapplicatie te zijnwaar een zorgverlener of medewerker die de berichtinhoud heeft samengesteld.

Poortapplicaties worden vaak gebruikt om de berichtinhoud vertalen naar een anderberichtformaat. Zo hoeft een zorgapplicatie zelf geen HL7v3-berichten te kunnensamenstellen en uitlezen. In dat geval kan de applicatie-id van de poortapplicatieworden gebruikt.

Voor HL7v3-berichten die worden uitgewisseld via de ZIM mogen uitsluitendapplicatie-id’s worden gebruikt die zijn uitgegeven door het LSP.

Zie verder [HL7v3 Infra].


D.4 Transport: HTTP-header/SOAP-envelopDeze paragraaf beschouwt de wijze waarop een HTTP-bericht en SOAP-envelopmoet worden geadresseerd aan de juiste bestemming.

HTTP header:

POST /webServiceName HTTP/1.1SOAPAction: “urn:hl7-org:v3/naam”Host: www.gbz.nl… … …

SOAP envelope

SOAPclientHTTPclient


applicatie applicatie

HL7sender

HL7sender

SOAPclientHTTPclient

applicatie

HL7sender


applicatie

HL7sender

HL7v3 transmission wrapper

HL7v3 control act wrapper

HL7v3 payload

De bovenstaande figuur toont hoe op dit niveau webservers als afzender en alsbestemming worden geadresseerd, alleen voor de bestemming, in de vorm van:

• de hostnaam van de HTTP-server die de HTTP-berichtinhoud moetverwerken,

• de webServiceName van de webservice die wordt aangesproken, in de vormvan een resource path,

• de SOAPAction die aangeeft welke SOAP-server de SOAP-inhoud moetverwerken.

Niet weergegeven is dat:• een zorgaanbieder meerdere HTTP-servers kan hebben, die afzonderlijk

kunnen worden geadresseerd aan de hand van de resource path,• een zorgaanbieder meerdere SOAP-servers kan hebben, die afzonderlijk

kunnen worden geadresseerd aan de hand van de SOAPAction.

Merk op dat de SOAP-envelope geen adresgegevens bevat. De SOAPAction staat inde HTTP-header om op HTTP-niveau te kunnen routeren, dus zonder de XML tehoeven ontleden.

Voor HL7v3-berichten die worden uitgewisseld via de ZIM mogen uitsluitend devaste web service namen en SOAPAction namen worden gebruikt die zijngedefinieerd in de WSDL’s per HL7v3-interaction-id.

Zie verder [HL7v3 WSP].

http://www.gbz.nl


D.5 Verbinding: TCP-header / IP-headerDeze paragraaf beschouwt de wijze waarop een TCP-bericht in IP-pakketten moetworden geadresseerd aan de juiste bestemming.

GBZ GBZ

IP header

TCP header

URLURL

Applicatie-id’sApplicatie-id’s

IPhandler

A B


SOAPclient

SOAPserver

HTTPclient

HTTPserverHTTP header

SOAPenvelope

HL7transmission

wrapper

applicatieHL7

control actwrapper



applicatieapplicatie applicatie

HL7sender

HL7receiver

IP-adresIP-adres

HL7sender

HL7receiver

HL7payload

TCPhandler

IPhandler

TCPhandler

De bovenstaande figuur toont hoe op dit niveau GBZ’en als afzender en alsbestemming worden geadresseerd, telkens in de vorm van:

• het IP-adres van het GBZ,• de standaard TCP-poort voor HTTP over SSL: 443.

Voor HL7v3-berichten die worden uitgewisseld via de ZIM mogen uitsluitend dehostnamen en IP-adressen worden gebruikt die zijn uitgegeven door de ZSP. DeZSP’s krijgen weer IP-adresreeksen toegewezen door het LSP. Binnen het GBZmogen vele, willekeurige IP-adressen worden gebruikt, zolang het GBZ naar buitenzich manifesteert onder één IP-adres, zie paragraaf 5.5.

Merk op dat de HTTP-server en SOAP-server vaak niet apart herkenbaar zijn.Meestal is er een webserver die deze functies omvat, tezamen met de TCP/IP-handlers.


D.6 Versturen van patiëntgegevensDeze paragraaf beschouwt hoe de principes uit de vorige paragrafen wordentoegepast wanneer een HL7-opdrachtbericht via de ZIM aan een bestemming wordtgericht.

GBZ2GBZ1 ZIM

1 2ik wil iets versturen


SOAPclient

SOAPserver

HTTPclient

HTTPserver

Applicatie2

Applicatie1

HL7sender

HL7receiver

SOAPclient/serv

HTTPclient/serv

IPhandler

TCPhandler

IP-adres ZIM

www.zim.nl

IPhandler

TCPhandler

IPhandler

TCPhandler

HL7transceiver

Appl2-idURA2

UZI-nrURA-BrolCode

IP-adres GBZ2

www.gbz2.nl

Appl2-idURA2

UZI-nrURA-BrolCode

De bovenstaande figuur toont in de berichten slechts de cruciale adresgegevensvan de bestemming.

Zorgaanbieder1 gebruikt applicatie1 om een opdracht m.b.t. een bepaaldepatiënt/cliënt te sturen naar zorgaanbieder2 en zoekt daartoe diens UZI-nr,rolcode, URA op in een zorgaanbiedergids of een lokaal adresbestand (nietafgebeeld).

Applicatie1 heeft onder water tegelijk de applicatie-id van deze zorgaanbiederopgehaald uit de zorgaanbiedergids of adresbestand. Applicatie1 zet diens UZI-nr,rolcode, URA in een HL7v3-bericht en vermeldt de applicatie-id en URA op deHL7v3-envelop.

De web server van GBZ1 stuurt de HL7v3-envelop per HTTP/SOAP als transport-middel naar de ZIM en gebruikt daarbij altijd de zelfde host name van de ZIM alsbestemming.

De web server van de ZIM kiest weer HTTP/SOAP als transportmiddel naar GBZ2,nadat de ZIM heeft opgezocht in zijn GBZ-configuratietabel dat applicatie metAppl2-id zich bevindt op GBZ2 en gebruikt de bijbehorende host name alsbestemming.

Merk op dat de ZIM hier als “bridge” fungeert, zie HL7v3 Abstract TransportSpecification. Dit betekent dat de ZIM slechts HL7v3-berichten doorschuift zonderde HL7v3-envelop te openen. Zo worden HL7-opdrachten van GBZ1 door de ZIMafgeleverd bij GBZ2 alsof dat rechtstreeks ging.

http://www.zim.nl

http://www.gbz2.nl


D.7 Opvragen van patiëntgegevensDeze paragraaf beschouwt hoe de principes uit de vorige paragrafen wordentoegepast wanneer een HL7-opvraagbericht via de ZIM aan een bestemming wordtgericht.

GBZGBZGBZ2GBZ1 ZIM

1 2ik wil iets opvragen


SOAPclient

SOAPserver

HTTPclient

HTTPserver

Applicatie2

Applicatie1

HL7sender

HL7receiver

SOAPclient/serv

HTTPclient/serv

IPhandler

TCPhandler

IPhandler

TCPhandler

IPhandler

TCPhandler

HL7transceiver

Schakelpunt

IP-adres GBZ2

www.gbz2.nl

Appl2-idURA2

(rolCode)

IP-adres ZIM

www.zim.nl

ZIM-idLSP

(rolCode)

De bovenstaande figuur toont in de berichten slechts de cruciale adresgegevensvan de bestemming.

Zorgaanbieder1 gebruikt applicatie1 om een opvraag m.b.t. een bepaaldepatiënt/cliënt te sturen naar de ZIM, want hij weet zelf niet welke anderezorgaanbieders allemaal patiëntgegevens hebben van deze patiënt/cliënt.

Applicatie1 specificeert het BSN (niet afgebeeld) en de opvraagcriteria (waarondereventueel een specifieke rolcode) in een HL7v3-bericht en vermeldt de ZIM-id enhet LSP op de HL7v3-envelop.

De web server van GBZ1 stuurt de HL7v3-envelop per HTTP/SOAP als transport-middel naar de ZIM en gebruikt daarbij altijd dezelfde host name van de ZIM alsbestemming.

De ZIM-applicatie (schakelpunt) leest de HL7v3-berichtinhoud en kijkt op basis vanhet BSN en de opvraagcriteria in de verwijsindex (niet afgebeeld) om te bepalenwelke applicaties allemaal patiëntgegevens hebben van deze patiënt/cliënt, enstuurt de ongewijzigde HL7v3-berichtinhoud in nieuwe HL7v3-enveloppen door naardie applicaties.

De web server van de ZIM kiest weer HTTP/SOAP als transportmiddel naar deGBZ’en, nadat de ZIM heeft opgezocht in zijn GBZ-configuratietabel op welkeGBZ’en de verschillende bronapplicaties zich bevinden en gebruikt de bijbehorendehost names als bestemming.

http://www.gbz2.nl

http://www.zim.nl


Merk op dat de ZIM hier als “gateway” fungeert, zie HL7v3 Abstract TransportSpecification. Dit betekent dat de ZIM als ontvanger van HL7v3-berichten optreedten daarop gebaseerd andere HL7v3-berichten (met dezelfde inhoud) verstuurt naarandere zorgaanbieders.

Merk op dat de opleverende GBZ’en niet aan de (door de ZIM gewijzigde)Transmission Wrapper, maar wel aan de (door de ZIM niet gewijzigde) ControlActWrapper kunnen zien waar de opvraag vandaan kwam.


E Kolommen in de verwijsindex

Deze bijlage is vervallen.


F Overzicht van zekerheidsaspecten

De basisinfrastructuur dient verschillende vertrouwensniveaus te bieden. Dezeniveaus kunnen verschillen op elk van de volgende aspecten omtrent patiënt-gegevens:

• Authenticiteit• Vertrouwelijkheid• Integriteit• Onweerlegbaarheid

Merk op dat authenticiteit gewoonlijk betrekking heeft op personen, maar ookbetrekking kan hebben op gegevens, in de betekenis van uniciteit.

Maar wat voor zekerheid is eigenlijk nodig in de volgende gebruiksscenario’s?• beheren patiëntgegevens• versturen patiëntgegevens• opvragen patiëntgegevens

En wat moeten de ZIM en de GBZ’en in die gebruiksscenario’s precies doen met diePKI-sleutels om die verschillende niveaus van zekerheid te bereiken? Deonderstaande tabel inventariseert deze zaken. Als voorbeeld is het receptgenomen:

• beheren recept (ook aanmelden)• versturen recept• opvragen recept

Merk op dat in dit document alleen het vertrouwensniveau Midden is uitgewerkt.


Beheren Versturen (push) Opvragen (pull)vastleggen raadplegen verzenden ontvangen opvragen ontvangen

Casus Huisarts (ofmedewerker)schrijft recept uiten legt het vast inzijn dossier

Huisarts (ofmedewerker)raadpleegt recept

Huisarts (ofmedewerker) stuurtrecept naar postbusvan apotheker

Apotheker (ofmedewerker) haaltverstuurde receptuit zijn postbus

Apotheker (ofmedewerker)vraagt recepten opuit dossiers vanhuisarts

Apotheker (ofmedewerker)ontvangtopgevraagderecepten

Authen-ticiteit(van zorg-aanbieder)

Huisarts wilzekerheid datmedewerkers nietnamens hem receptvastleggen

Huisarts wilzekerheid datmedewerkers nietnamens hemrecept raadplegen

Huisarts wilzekerheid datmedewerkers nietnamens hem receptversturen

Apotheker wilzekerheid datmedewerkers nietnamens hem receptuitlezen

Apotheker wilzekerheid datmedewerkers nietnamens hem receptopvraagt

nvt

Oplossinghoog

huisarts moet zichvoor iederevastlegging indossierauthenticeren

huisarts moet zichvoor iedereraadpleging vandossierauthenticeren

huisarts moet zichvoor ieder teversturen berichtauthenticeren

apotheker moetzich voor iederontvangen berichtauthenticeren

apotheker moetzich voor iederopvraagauthenticeren

nvt

Oplossingmiddel

huisarts moet zichbij iederzorgcontactauthenticeren

< idem < idem apotheker moetzich bij iederzorgcontactauthenticeren

< idem nvt

Oplossinglaag

huisarts moet zichper dagdeelauthenticeren

< idem < idem apotheker moetzich per dagdeelauthenticeren

< idem nvt

Authen-ticiteit(vanpatiënt-gegevens)

Huisarts wilzekerheid datonbevoegden hetrecept nietongemerkt kopiëren

nvt Huisarts wilzekerheid dat metéén recept niet meerdan eenmaalmedicatie wordtafgehaald

nvt nvt Huisarts wilzekerheid datapotheker eenrecept niet alsorigineel opneemtin zijn dossier

Oplossinghoog

HIS moet receptondertekenen metprivate sleutel vanhuisarts,

nvt HIS moetreceptberichtondertekenen metprivate sleutel van

nvt nvt AIS mag geen kopievan een receptvastleggen in eendossier


HIS moet receptregistreren in VWImet uniek nummer

huisarts,HIS en AIS moetenafhandelingstatusvan receptberichtbijhouden in VWI

Oplossingmiddel

HIS moet receptregistreren in VWImet uniek nummer

nvt HIS en AIS moetenafhandelingstatusvan receptberichtbijhouden in VWI

nvt nvt AIS moet recept alskopie aanmerken

Vertrouwe-lijkheid(vanpatiënt-gegevens)

Huisarts wilzekerheid datonbevoegden hetrecept niet kunneninzien

nvt Huisarts wilzekerheid dat alleende geadresseerdeapotheker het receptkan inzien

nvt nvt Huisarts wilzekerheid dat alleende opvragendeapotheker derecepten kan inzien

Oplossinghoog

HIS moet receptversleutelen metpublieke sleutel vande huisarts en vooriedere bevoegdemedewerker eenkopie versleutelen,HIS kan dit alleenontsleutelen metprivate sleutel vanbevoegdemedewerkers

nvt HIS moetreceptberichtversleutelen metpublieke sleutel vande ZIM, i

ZIM versleuteltbericht met depublieke sleutel vande apotheker,AIS moet ditontsleutelen metprivate sleutel vanapotheker

nvt nvt HIS moetopgeleverdereceptenversleutelen metpublieke sleutel vande ZIM, ii

ZIM versleuteltbericht met depublieke sleutel vande apotheker,AIS moet ditontsleutelen metprivate sleutel vanapotheker

Oplossingmiddel

HIS geeftleesrechten permedewerker opbasis vanautorisatietabel

nvt HIS moet metpersoonlijksleutelpaar vanhuisarts een veiligesessie met ZIMopzetten,AIS moet veilige

nvt nvt AIS moet metpersoonlijksleutelpaar vanapotheker eenveilige sessie metZIM opzetten,HIS moet veilige


verbinding met ZIMhebben

verbinding met ZIMhebben

Oplossinglaag

HIS geeft alleentoegang aanmedewerkers

nvt alle XIS moeten zijnaangesloten op eenVPN

nvt nvt alle XIS moeten zijnaangesloten op eenVPN

Integriteit(vanpatiënt-gegevens)

Huisarts wil zeker-heid dat recept nazijn bekrachtigingniet ongemerktgewijzigd kanworden

nvt Huisarts wilzekerheid dat hetrecept onderweg nietongemerkt gewijzigdwordt

nvt Apotheker wilzekerheid dat deopvraag onderwegniet ongemerktgewijzigd is

Huisarts wilzekerheid datrecepten onderwegniet ongemerktgewijzigd kunnenworden

Oplossinghoog

Zie onderonweerlegbaarheidv

nvt Zie onderonweerlegbaarheidv

nvt Zie onderonweerlegbaarheidv

Zie onderonweerlegbaarheidv

Oplossingmiddel

HIS moet wijzigenen verwijderen vanreceptenonmogelijk maken

nvt Zie ondervertrouwelijkheid

nvt Zie ondervertrouwelijkheid

Zie ondervertrouwelijkheid

Oplossinglaag

HIS geeft alleentoegang aanmedewerkers

nvt alle XIS moetenintegere verbindingmet ZIM hebben

nvt alle XIS moetenintegere verbindingmet ZIM hebben

alle XIS moetenintegere verbindingmet ZIM hebben

Onweerleg-baarheid(vanpatiënt-gegevens)

Huisarts wilzekerheid dat hetrecept door hem isbekrachtigd

Medewerker kanniet ontkennen dathij recept heeftingezien

Huisarts kan nietontkennen dat hetrecept door hem isverstuurd

Apotheker kan nietontkennen dat hijhet recept heeftontvangen

Apotheker kan nietontkennen dat hijde recepten heeftopgevraagd

Apotheker kan nietontkennen dat hijde recepten heeftontvangen

Oplossinghoog

HIS moet receptondertekenen metprivate sleutel vanhuisarts,

HIS kan deze latercontroleren metdiens publiekesleutel

HIS moet inzagebevestigingondertekenen metprivate sleutel vanmedewerker,ZIM moetinzagebevestigingloggen,HIS kan deze

HIS moetreceptberichtondertekenen metprivate sleutel vanhuisarts,

ZIM moetreceptbericht loggen,AIS kan deze

AIS moet ontvangstbevestigingondertekenen metprivate sleutel vanapotheker,ZIM moet ontvangstbevestiging loggen,HIS kan dezecontroleren met

AIS moetopvraagberichtondertekenen metprivate sleutel vanapotheker,ZIM moetopvraagberichtloggen,HIS kan deze

AIS moet ontvangstbevestigingondertekenen metprivate sleutel vanapotheker,ZIM moetontvangstbevestiging loggen,HIS kan deze


controleren metdiens publiekesleutel

controleren metpublieke sleutel vanhuisarts

publieke sleutel vanapotheker



Oplossingmiddel

HIS meldt receptaan bij ZIM na fiatvan huisarts,ZIM moetaanmelding loggen

HIS raadpleegteigen dossier dooropvraag via deZIM,ZIM moetaanmelding loggen

zie ondervertrouwelijkheid,daarnaast moet ZIMontvangst vanreceptbericht loggen

zie ondervertrouwelijkheid,daarnaast moet ZIMverzending vanreceptberichtloggen

zie ondervertrouwelijkheid,daarnaast moetenHIS en ZIMontvangst vanopvraagberichtloggen

zie ondervertrouwelijkheid,daarnaast moetenHIS en ZIMverzending vanopleverberichtloggen

Oplossinglaag

HIS moet het fiatloggen

HIS moet deraadpleging loggen

ZIM moet ontvangstreceptbericht loggen

ZIM moetverzendingreceptberichtloggen

HIS en ZIM moetenontvangstopvraagberichtloggen

HIS en ZIM moetenverzendingopleverberichtloggen

Betrouw-baarheid

Huisarts wilzekerheid dat hetrecept niet verlorengaat

nvt Huisarts wilzekerheid dat dieapotheker het receptheeft ontvangen

Apotheker wilzekerheid dat hetrecept niet dubbelverstuurd is

Apotheker wilzekerheid dat deopvraag bij dehuisarts aankomt

Apotheker wilzekerheid dat allerelevante receptenvan de huisartsterugkomen

Oplossing HIS moetreservekopie maken

nvt ZIM moetfoutmelding ofontvangstbevestigingnaar HIS sturen

HIS moet berichtenvolgnummers geven

ZIM moetfoutmelding naarAIS sturen als HISniet bereikbaar is

ZIM moetfoutmelding naarAIS sturen als HISniet antwoordt

i Let op: de ZIM ontsleutelt en versleutelt om het bericht te kunnen loggen tbv onweerlegbaarheid. Klein nadeel is dat daarmee de ZIMeen zwakke schakel in de vertrouwelijkheidsketen is geworden. Volledige vertrouwelijkheid kan worden verkregen als de HIS hetreceptbericht versleutelt met de publieke sleutel van de apotheker. Onweerlegbaarheid dan niet meer worden aangetoond.ii Bij het opvragen geldt hetzelfde als bij het versturen. Daarnaast geldt als nadeel: als de ZIM ontsleutelt en versleutelt kost datverwerkingstijd. Dit kan weer opgelost worden als het HIS voor de ZIM een versleuteld recept klaarzet.

SPECIFICATIE VAN DE BASISINFRASTRUCTUUR IN DE ZORG files/M32/Doc/basisinfrastructuur.pdf · 5.7.3...

Documents

Transcript of SPECIFICATIE VAN DE BASISINFRASTRUCTUUR IN DE ZORG files/M32/Doc/basisinfrastructuur.pdf · 5.7.3...