PROGRAMMA VAN EISEN VOOR EEN GOED BEHEERD ZORGSYSTEEM (GBZ)

PROGRAMMA VAN EISEN VOOR EEN GOED BEHEERD ZORGSYSTEEM (GBZ) - Versie 1.1 -

postadres: Po stbus 262, 2260 AG Leidschendam bezo ekadres: Ov ergoo 11, 2266 JZ Lei ds chend am tel efo o n: ( 07 0) 31 7 3 4 5 0; f ax: ( 0 70 ) 3 20 7 4 3 7; e -m ai l : i nfo @N I CT I Z. nl www.NI CTIZ.nl

Status Datum

: :

Definitief 11 augustus 2006

Managementsamenvatting Ten behoeve van het landelijk uitwisselen van patiëntgegevens, kan een zorgaanbieder diens zorginformatiesysteem (HuisartsInformatieSysteem (HIS), ApotheekIinformatieSysteem (AIS), ZiekenhuisInformatieSysteem (ZIS), etc.) via een DataCommunicatieNetwerk (DCN) van een Zorg Service Provider (ZSP) aansluiten op de ZorgInformatieMakelaar (ZIM) van het Landelijke SchakelPunt (LSP). Zie de onderstaande figuur.

Vektis

CIBG ZG

UZI

SBV

UZOVI

LSP VWI ZIM I&A ZIM AUT SCH LOG

HIS

AIS

huisarts apoth’k

ZSP

ZSP

DCN

DCN

LIS ZIS RIS ziekenhuis

ZVIS

HIS

AIS

verzek’r huisarts apoth’k

LIS ZIS RIS

ZVIS

ziekenhuis

verzek’r

Ook zorgverzekeraars zullen hun informatiesysteem (ZVIS) op de ZIM kunnen aansluiten, maar dat valt buiten het bereik van dit document. Het Landelijk SchakelPunt ontsluit respectievelijk de Sectorale BerichtenVoorziening (SBV), het UZI-register (Unieke ZorgverlenerIdentificatie), de ZorgaanbiederGids (ZG) en op termijn ook het UZOVI-register (Unieke ZorgVerzekeraars-register).

Programma van Eisen voor een GBZ

-i–

Om te mogen aansluiten op de ZIM, moet een zorginformatiesysteem (XIS) voldoen aan een aantal eisen inzake: • gebruikersfuncties: bijv. de XIS moet zorgverleners in staat stellen om transmuraal patiëntgegevens op te vragen en te versturen, • berichtuitwisseling: bijv. de XIS moet patiëntgegevens uitwisselen met de ZIM volgens bepaalde HL7v3-berichten, • connectiviteit: bijv. de XIS moet berichten uitwisselen met de ZIM volgens bepaalde protocollen, • beveiliging: bijv. de XIS moet toegang tot patiëntgegevens beperken tot gebruikers van UZI-passen, • beschikbaarheid: bijv. de XIS moet 7 dagen per week, 24 uur per dag beschikbaar zijn met zeer beperkte uitval wegens storing of onderhoud, • responstijden: bijv. de XIS moet berichten van de ZIM binnen bepaalde tijd verwerken en beantwoorden, • capaciteit: bijv. de XIS moet in staat zijn alle berichten van de ZIM te verwerken, • betrouwbaarheid: bijv. de XIS moet op bepaalde wijze omgaan met foutsituaties die optreden in de berichtuitwisseling met de ZIM, • actualiteit: bijv. nieuwe patiëntgegevens moeten tijdig worden aangemeld bij de verwijsindex van de ZIM, • beheer: bijv. beheerders moeten de werking van de XIS bewaken en zonodig corrigeren. Het gaat dus niet alleen om functionele en technische eisen van het XIS, maar ook om procedurele eisen inzake de wijze van gebruik door de zorgverleners en de beheerders. Een XIS of verzameling XIS’en bij een zorgaanbieder dat voldoet aan al deze eisen, kan de kwalificatie Goed Beheerd Zorgsysteem (GBZ) krijgen. XIS-leveranciers kunnen voor hun XIS ook een XIS-typegoedkeuring verwerven. GBZ’en kunnen in aard en omvang verschillen. Qua aard kan een GBZ omvatten: • een enkele XIS, zoals het HIS van een huisarts, • een verzameling XIS’en, zoals het ZIS, radiologie-informatiesysteem, laboratoriuminformatiesysteem, etc. van een ziekenhuis. Qua omvang kan een GBZ bijvoorbeeld omvatten: • een enkele PC met een XIS, zoals bij een huisarts, • een client/server-platform, waarbij de XIS deels op de client en deels op de server draait, zoals in een gezondheidscentrum, • een ASP-platform met een XIS, althans dat deel dat exclusief onder verantwoordelijkheid van één zorgaanbieder valt, dat via een PC met webbrowser via het internet kan worden benaderd, zoals in een HAP, • een grote verzameling centrale server-platformen met XIS’en, die via clientplatformen op de werkvloer kunnen worden benaderd, zoals in een ziekenhuis.

- ii -


Afhankelijk van de aard, zal een XIS bepaalde typen HL7v3-berichten wel of niet moeten kunnen uitwisselen. Aldus zal de XIS-typegoedkeuringmoeten aangeven voor welke landelijke toepassingen en toepassingsrollen deze geldt. Dit document “Programma van Eisen voor een Goed Beheerd Zorgsysteem” specificeert de eisen waaraan een GBZ moet voldoen. De huidige versie van dit document is primair gericht op de landelijke toepassingen Elektronisch Medicatie Dossier (EMD) en elektronisch WaarneemDossier Huisartsen (WDH), maar is zodanig generiek opgezet dat deze analoog kan worden uitgebreid voor andere zorgtoepassingen.


- iii –

Inhoudsopgave 1

2

3

4

- iv -

Inleiding

6

1.1

Doel van dit document

6

1.2

Achtergrond van dit document

6

1.3

Doelgroep van dit document

6

1.4

Reikwijdte van dit document

7

1.5

Structuur van dit document

7

1.6

Relatie met andere documenten

8

1.7

Status van dit document

9

Uitgangspunten

11

2.1

11

Normatieve referenties

2.2

Informatieve referenties

11

2.3

Afkortingen

13

2.4

Begrippen

16

Overzicht van een GBZ

20

3.1

Wat is een GBZ?

20

3.2

Categorieën van eisen aan een GBZ

21

3.3

Omgeving van een GBZ

21

3.4

Grenzen van een GBZ

24

3.5

GBZ-kwalificatie

25

3.6

XIS-typegoedkeuring

26

3.7

XIS-combinaties

27

3.8

Aansluitvoorwaarden versus gebruikerswensen

27

3.9

Toepassingsrol-afhankelijke eisen

28

Applicatie-eisen

29

4.1

Inleiding

29

4.2

In-/uitloggen gebruiker

31

4.3

Selecteren patiënt/cliënt

33

4.4

Selecteren zorgaanbieder

37

4.5

Bijhouden Patiëntgegevens

39

4.6

Publiceren Patiëntgegevens

40

4.7

Initieel koppelen Patiëntgegevens

43

4.8

Opvragen Patiëntgegevens

45

4.9

Versturen Patiëntgegevens

49

4.10

Raadplegen toegangslog

52

4.11

Bijhouden mandateringen

54

4.12

Aan/afsluiten GBZ-applicatie m.b.t. schakelpunt

56

4.13

Beheren GBZ

57


5

6

7

4.14

Berichtuitwisseling als gevolg van gebruikersfuncties

58

4.15

Berichtuitwisseling t.b.v andere zorgaanbieders

62

4.16

Autorisatie

67

4.17

Toegangslog

67

4.18

Connectiviteit

67

4.19

Beveiliging

68

4.20

Betrouwbaarheid

69

4.21

Actualiteit

70

Implementatie-eisen

71

5.1

Inleiding

71

5.2

Connectiviteit

72

5.3

Beveiliging

72

5.4

Beschikbaarheid

73

5.5

Responstijden

74

5.6

Capaciteit

75

5.7

Betrouwbaarheid

75

Exploitatie-eisen

76

6.1

76

Inleiding

6.2

Toegangslog

77

6.3

Connectiviteit

77

6.4

Beveiliging

77

6.5

Beschikbaarheid

77

6.6

Actualiteit

78

6.7

Ondersteuning

79

Voorbeelden van een GBZ

80

7.1

Inleiding

80

7.2

PC-gebaseerde XIS

80

7.3

Client/server-gebaseerde XIS

81

7.4

Meerdere client/server-gebaseerde XIS’en

82

7.5

ASP-gebaseerde XIS

84


-v–

1

Inleiding

1.1 Doel van dit document Dit document specificeert de eisen waaraan een zorginformatiesysteem (XIS) van een zorgaanbieder moet voldoen, opdat deze mag worden aangesloten op het Landelijk SchakelPunt. Een zorginformatiesysteem bij een zorgaanbieder dat voldoet aan al deze eisen, kan zich kwalificeren als Goed Beheerd Zorgsysteem (GBZ). Deze eisen omvatten zowel procedurele, functionele als technische aspecten. Deze GBZ-eisen vormen de basis voor een GBZ-kwalificatie die een zorginformatiesysteem van een zorgaanbieder moet verwerven, voordat deze wordt aangesloten op de operationele Zorg Informatie Makelaar (ZIM) van het Landelijk SchakelPunt (LSP). Om de noodzakelijke tests te kunnen uitvoeren, zal een kandidaat-GBZ tijdelijk worden aangesloten op de test-ZIM van het LSP. Na verwerving van een GBZ-kwalificatie zal een GBZ blijvend moeten moeten voldoen aan de GBZ-eisen. Dit document kan tevens worden gebruikt door XIS-leveranciers die een XIStypegoedkeuring willen verwerven voor hun XIS. Daarvoor zullen XIS-leveranciers hun XIS ook moeten kunnen aansluiten op de test-ZIM van het LSP. Een XIStypegoedkeuring kan een afnemende zorgaanbieder veel werk besparen, doordat alleen het resterende deel van de GBZ-kwalificatieprocedure hoeft te worden doorlopen. Dit document is geschreven in het kader van het AORTA-programma van NICTIZ.

1.2 Achtergrond van dit document Het ministerie van VWS, CIBG en NICTIZ werken samen met partijen in het veld aan de invoering van een landelijk Elektronische PatiëntDossier (EPD). De eerste stappen in die richting worden gevormd door de landelijke toepassingen: • EMD – Elektronisch Medicatie Dossier, ook wel e-medicatiedossier genoemd, • WDH – elektronisch Waarneem Dossier Huisartsen, ook wel ewaarneemdossier genoemd.

1.3 Doelgroep van dit document Dit document is bedoeld voor partijen die zich bezighouden met de ontwikkeling en implementatie van ICT-toepassingen in de zorg, zoals zorgaanbieders en ontwikkelaars, leveranciers, onderzoekers, etc. De lezer wordt verondersteld een ICT-achtergrond en enige kennis van UML en HL7v3 te hebben. Voor een goed begrip van dit document is het ook raadzaam de documenten “Architectuurontwerp Basisinfrastructuur in de Zorg” en “Specificatie van de Basisinfrastructuur in de Zorg” te lezen, aangezien dit document daarop gebaseerd is.

-6–


1.4 Reikwijdte van dit document Dit document concentreert zich op de eisen die worden gesteld aan een GBZ in verband met de aansluiting op het LSP en de landelijke uitwisseling van patiëntgegevens. Daarnaast moet een GBZ ook voldoen aan eisen die voortvloeien uit bestaande wetten en normen, zoals de WBP, de WGBO, de WGBZ en de NEN 7510. Die eisen worden niet gespecificeerd in dit document, want die eisen zijn ook van toepassing op zorginformatiesystemen die niet aansluiten op het LSP. Deze versie van dit document is primair gericht op de landelijke toepassingen EMD en WDH. Wanneer het LSP nieuwe zorgtoepassingen gaat ondersteunen, zullen eisen m.b.t. nieuwe zorgtoepassingen volgens huidige inzichten eenvoudig kunnen worden toegevoegd. Deze versie van dit document geeft een totaal programma van eisen, dat geen rekening houdt met de fasering van het implementatieprogramma voor EMD en WDH. Het “Handboek ICT-leveranciers in de zorg” geeft nader inzicht in de fasering van de eisen.

1.5 Structuur van dit document Het begeleidende deel van dit document bestaat uit: • Hoofdstuk 1 geeft een inleiding voor dit document, • Hoofdstuk 2 geeft de uitgangspunten voor dit document, • Hoofdstuk 3 geeft een beeldende beschrijving van wat een GBZ zou kunnen zijn en wat een GBZ-kwalificatie en een XIS-typegoedkeuring inhouden. Het normatieve deel van dit document bestaat uit: • Hoofdstuk 4 specificeert de applicatie-eisen die worden gesteld aan een XIS, • Hoofdstuk 5 specificeert de implementatie-eisen die worden gesteld aan een GBZ met alle geïmplementeerde XIS’en bij een zorgaanbieder, • Hoofdstuk 6 specificeert de exploitatie-eisen die worden gesteld aan een GBZ met alle gebruikte en beheerde XIS’en.


-7–

1.6 Relatie met andere documenten De onderstaande figuur toont de relatie van dit document met andere documenten van NICTIZ, waarbij de pijlen wijzen naar het afgeleide document. Centraal staat de “Specificatie van de basisinfrastructuur in de zorg, versie 2.4”: • deze is gebaseerd op het “Architectuurontwerp basisinfrastructuur in de zorg, versie 4.2”, • hierop gebaseerd is dit document “Programma van Eisen voor een GBZ, versie 1.1”, • hierop gebaseerd zijn ook diverse HL7-implementatiehandleidingen (zie hieronder), • hierop gebaseerd is ook het document “Kwalificeringsschema Zorg Service Providers, versie 1.1 voor referentieomgeving”. Tenslotte is er het “Handboek ICT-leveranciers in de Zorg, versie 4.1”, dat aangeeft in welke fase van de invoering van EMD en WDH aan welke GBZ-eisen precies moet zijn voldaan. Dit “Programma van Eisen voor een GBZ, versie 1.1” specificeert daarentegen de eindsituatie. Architectuur ontwerp Basisinfra Zorg

Specificatie Basisinfra Zorg

Programma van eisen LSP

Programma van eisen GBZ

HL7 implementatie handleidingen

Kwalificerings schema ZSP

Handboek ICT leveranciers

De HL7-implementatiehandleidingen betreffen de volgende documenten met de aangegeven versienummers of hoger: • Implementatiehandleiding HL7v3 Infrastructurele domeinen v2.4, • Implementatiehandleiding HL7v3 Zorg Informatie Makelaar v2.5, • Implementatiehandleiding HL7v3 Medicatieberichten v2.5, • Implementatiehandleiding HL7v3 Gegevensuitwisseling huisartsen v3.2.1, • Implementatiehandleiding HL7v3 Web Services Profile v1.2. De programma’s van eisen vormen de basis voor de verwerving van de verschillende ICT-voorzieningen. Het architectuurontwerp en de specificatie richten zich zoveel mogelijk op de gewenste eindsituatie.

-8-


1.7 Status van dit document Dit document “Programma van Eisen voor een GBZ, versie 1.1” wordt compleet geacht voor de landelijke toepassingen EMD en WDH. Deze versie 1.1 wordt uitgebracht i.v.m. de afronding van de Proof of Concept en de daaropvolgende Pilot. Let op dat deze versie 1.1 van dit document verder gaat dan wat voor fase 1 van het implementatieprogramma voor EMD en WDH wordt gevraagd. Het “Handboek ICT-leveranciers in de zorg” geeft nader inzicht in de fasering van de eisen waaraan de koplopers moeten voldoen. Deze versie van dit document heeft enkele eisen het etiket {toekomst} gegeven, indien de eis nog niet kan worden gerealiseerd omdat de daarvoor benodigde HL7v3-berichten of voorzieningen voorlopig nog niet beschikbaar zijn. Deze eisen zijn niettemin opgenomen opdat XIS-ontwikkelaars daarmee rekening kunnen houden. Deze versie 1.1 verschilt van versie 1.0.1 op de volgende punten: • AORTA-wijziging #3: sommige gebruiksscenario’s vereisen inloggen met UZI-pas maar hebben geen interactie met de ZIM tot gevolg, zodat er sprake is van lokaal inloggen, zie paragraaf 4.2 en 4.19. • {toekomst} AORTA-wijziging #4: GBZ moet UZI-passen controleren tegen CRL, zie paragraaf 4.19 en 6.4. • AORTA-wijziging #5: GBZ moet ZIM-certificaat controleren tegen CRL, zie paragraaf 4.19 en 6.4. • AORTA-wijziging #6: de tabel in Bijlage A.7 klopte voorheen niet met de eisen in paragraaf 4.5, 4.6 en 4.8. • AORTA-wijziging #10: wanneer een zorgverlener een nieuw patiëntstuk heeft vastgelegd in zijn dossier maar deze vervolgens herroept (ongeldig maakt), moet deze automatisch afgeschermd worden, zie paragraaf 4.6. • AORTA-wijziging #21: de structuur van de toegangslog verduidelijken,verbeteren en in lijn brengen met het Functioneel Ontwerp van de ZIM, zie paragraaf 4.10. • AORTA-wijziging #23: ten onrechte werd gesuggereerd dat een GBZ bij mandateren moet toelaten dat de URA van de mandaterende zorgverlener vrij kan worden gekozen, zie paragraaf 4.11. • AORTA-wijziging #24: nieuwe eis: een GBZ moet altijd via één netwerkadres naar buiten communiceren, zie paragraaf 5.2. • AORTA-wijziging #25: verduidelijken dat de applicatie-id per zorgaanbieder uniek moet zijn, belangrijk voor een ASP, zie paragraaf 5.2. • AORTA-wijziging #27: voor opvragen BSN is UZI-pas niet noodzakelijk maar is authenticatie op instellingniveau met UZI-servicescertificaat voldoende, dit komt neer op het reeds gedefinieerde vertrouwensniveau laag, zie paragraaf 4.2 en 4.19. • AORTA-wijziging #33: eisen dat een GBZ onmogelijk maakt dat een malafide applicatie vanaf een onveilige client als GBZ-applicatie allerlei berichten met de ZIM kan uitwisselen, zie paragraaf 4.19. • AORTA-wijziging #36: toevoegen GBZ-eis dat landelijke unieke patiëntstukid’s worden gebruikt, zie paragraaf 4.20. • AORTA-wijziging #39: paragraaf 4.19 moet verwijzen naar [Spec Basisinfra] paragraaf 4.3.13 voor de waarden van de tijdsparameters. • AORTA-wijziging #44: GBZ’en kunnen voortaan hostnamen (domeinnnamen) gebruiken, zie paragraaf 4.13.


-9–

• • • • • • •

•

- 10 -

AORTA-wijziging #102: zorgaanbiedernaam is voorlopig vrij te kiezen, in afwachting van zorgaanbiedergids, zie paragraaf 4.9 en 4.13. AORTA-wijziging #111: een indicatie van de beschikbaarheid moet etiket {toekomst} krijgen, zie paragraaf 4.8. AORTA-wijziging #112: de zorgaanbiederidentiteit kan als URA of zorgaanbiedernaam worden gepresenteerd, te kiezen door de XISleverancier, zie paragraaf 4.8. AORTA-wijziging #131: correctie dat ontvangende systeem op een duplicaatbericht altijd antwoord moet sturen als de afzender dat verwacht, zie paragraaf 4.20. AORTA-wijziging #134: correctie dat gebruiker niet de vrije keuze heeft om een klaarstaande aanmelding te negeren, zie paragraaf 4.6. AORTA-wijziging #145: diefstal van duplicaatberichten voorkomen, zie paragraaf 4.20. AORTA-wijziging #154: de gegevenssoort ligt besloten in de gebruikersinteractie en hoeft niet steeds apart genoemd te worden in het autorisatieprotocol, toegangslog en mandateringstabel, zie paragraaf 4.10 en 4.11. Eigenlijk is dit een vereenvoudiging, want de oude eisen dwongen tot het uitsplitsen van de gebruikersinteracties tot 2 dimensies gegevenssoort en interactietype, wat voor WDH niet mogelijk blijkt. Nu kan men volstaan met gebruikersinteractie en dit begrip is mede daarom beter gedefinieerd, zie [Spec Basisinfra] paragraaf 5.3.1. een aantal eisen heeft het etiket {wens} gekregen, zie paragraaf 4.11 en 4.12.


2

Uitgangspunten

Dit hoofdstuk is bedoeld voor lezers die precies willen weten op welke uitgangsdocumenten het gedachtegoed in dit document is gebaseerd. Andere lezers kunnen dit hoofdstuk overslaan en beginnen in Hoofdstuk 3, en alleen voor de gebruikte afkortingen en begrippen even terugslaan naar dit hoofdstuk.

2.1 Normatieve referenties De onderstaande documenten zijn beschouwd als leidend voor dit document: [Spec Basisinfra] “Specificatie van de basisinfrastructuur in de zorg”, versie 2.4, 11 augustus 2006, NICTIZ. [HL7 v3] “HL7 Version 3 Standard” © 2002 Health Level Seven ®, Inc. Deze standaard is belangrijk voor het voorliggende document. Echter, HL7 richt zich op de informatie-uitwisseling tussen systemen en doet geen uitspraken over informatieverwerking of –ordening binnen systemen. Omdat HL7 Version 3 nog niet formeel bekrachtigd is, worden de meest recente ballotdocumenten geraadpleegd. [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” [NEN7510] “Nederlandse norm NEN7510 (nl), Medische Informatica – Informatiebeveiliging in de zorg - Algemeen”

2.2 Informatieve referenties De onderstaande documenten hebben gediend als bron voor dit document: [Architectuurontwerp] “Architectuurontwerp basisinfrastructuur in de zorg”, versie 4.2, 15 november 2005, NICTIZ. [prENV13606:2003] “Health Informatics – Electronic Health Care Record communication”, revised final draft, May 1999, CEN/TC251. Deze standaard beschrijft de informatie-uitwisseling, vanuit het perspectief van informatieordening binnen een EHR. [Tijdmachine] “Access to EHR and access control at a moment in the past: a discussion of the need and an exploration of the consequences”, artikel van Ab Bakker gepresenteerd tijdens IMIA Working Conference "Realizing Security of the Electronic Health Record", 31 mei - 3 juni 2003, Varenna, Italië. [EMD-autorisatie] “Modelrichtlijn en modelvoorlichtingsmateriaal autorisatie voor koplopers Electronisch Medicatie Dossier”, versie 1.0, november 2005, Leidschendam.


- 11 –

[WDH-autorisatie] “Modelrichtlijn en modelvoorlichtingsmateriaal autorisatie voor koplopers Waarneem Dossier Huisartsen”, versie 1.0, november 2005, Leidschendam.

- 12 -


2.3 Afkortingen AGB AIS ASP BIG BPR BSN BVBSN BZK CA CIBG CPI CRL CS DCN DWH EMD EPD GBA GBZ HAGRO HAP HOED HIS HL7 HL7v3 HTTP ICT ID, id IP LAN LIS LSP

Algemene Gegevens Beheer, een code voor de identificatie van zorgaanbieders ten behoeve van hun declaraties bij zorgverzekeraars Apotheek Informatie Systeem Application Service Provider, bedrijf dat gebruik van applicaties via Internet aanbiedt wet op de Beroepen in de Individuele Gezondheidszorg Basisadministratie Persoonsgegevens en Reisdocumenten, agentschap van BZK Burger Service Nummer Beheer Voorziening BSN (ministerie van) Binnenlandse Zaken en Koninkrijksrelaties Certification Authority, een TTP die PKI-sleutels certificeert en deze certificaten uitgeeft Centraal Informatiepunt Beroepen Gezondheidszorg, agentschap van het ministerie van VWS Centrale Patiënt Index Certificate Revocation List, lijst van ingetrokken (certificaten van) PKIsleutels CommunicatieServer Data Communicatie Netwerk Dienst Waarneming Huisartsen Elektronisch Medicatie Dossier Elektronisch Patiënten Dossier Gemeentelijke Basis Administratie Goed Beheerd Zorgsysteem, zorgsysteem dat voldoet aan eisen voor aansluiting op de basisinfrastructuur in de zorg Huisartsen Groep Huisartsenpost Huisartsen Onder Een Dak Huisarts Informatie Systeem Health Level 7, internationale organisatie voor standaardisatie van de informatie-uitwisseling in de zorg Health Level 7 version 3, op XML gebaseerde standaard voor informatie-uitwisseling in de zorg Hyper Text Transfer Protocol, protocol voor het transporteren van tekstberichten over een TCP-verbinding Informatie en Communicatie Technologie Identiteit Internet Protocol, netwerkprotocol Local Area Network, lokaal datacomnetwerk, bijv. binnen een zorginstelling Laboratorium Informatie Systeem Landelijk SchakelPunt, de organisatie die de ZIM exploiteert


- 13 –

MPI MTBF MTTR NAW NEN NTP OCSP OID PKI RA

Master Patient Index, een systeem dat patiëntnummers uit verschillende zorginformatiesystemen kan vertalen Mean Time Between Failures, tezamen met de MTTR een maat voor de beschikbaarheid van een systeem Mean Time To Repair, tezamen met de MTBF een maat voor de beschikbaarheid van een systeem Naam, Adres, Woonplaats Nederlands Normalisatie-instituut Network Time Protocol, protocol voor het synchroniseren van tijdklokken tussen verschillende ICT-voorzieningen Online Certificate Status Protocol, techniek voor het verifiëren van een (certificaat van) een PKI-sleutel Object Identifier, een standaard wijze voor de identificatie van willekeurige objecten, zie www.alvestrand.no/objectid/ Public Key Infrastructure, een methode voor beveiliging gebaseerd op het gebruik van publieke en private sleutels Registratie Autoriteit, een TTP die aanvragen voor certificering namens de CA afhandelt

RIS SBV SBV-Z SEH SOAP

Radiologie Informatie Systeem Sectorale BerichtenVoorziening van het BSN-stelsel SBV voor de zorgsector Spoed Eisende Hulp Simple Object Access Protocol, op XML gebaseerde techniek om een elektronisch document in te pakken in een envelop met routeringsgegevens, gestandaardiseerd door W3C

SSL

Secure Socket Layer, techniek voor het beveiligen van een TCPverbinding over het internet Transport Control Protocol, protocol voor het opzetten van een verbinding over een IP-netwerk Transport Layer Security, de opvolger van SSL

TCP TLS TTP UML

Trusted Third Party, rol van een vertrouwde derde binnen een PKIkader Unified Modeling Language, door de OMG gestandaardiseerde modelleertechniek

URA

UZI-Register Abonneenummer, identificatienummer van de zorgaanbieder die UZI-passen heeft aangevraagd

URI

Universal Resource Identifier, wijze van adresseren van systemen op het Internet

UZI

Unieke Zorgverleners Identificatie, landelijk identificatienummer voor zorgverleners, zorginstellingen en zorgsystemen Unieke ZorgVerzekeraars Identificatie, landelijk identificatienummer voor zorgverzekeraars

UZOVI VWS WABB

(ministerie van) Volksgezondheid Welzijn en Sport Wet Algemene Bepalingen Burgerservicenummer (wetsvoorstel)

WBP WDH

Wet bescherming persoonsgegevens elektronisch Waarneem Dossier Huisartsen

- 14 -


WEH WGBO WGBZ WID

Wet elektronische handtekeningen Wet op de geneeskundige behandelingsovereenkomst Wet Gebruik BSN in de Zorg (wetsvoorstel) Wettelijk Identificatie Document

WOG WSP

Wet op de geneesmiddelenverstrekking Web Services Profile, wijze waarop HL7v3-berichten moeten worden gebonden op HTTP/SOAP, gestandaardiseerd door HL7

XIS XML

generieke term voor HIS, AIS, ZIS, etc. (zorginformatiesysteem) eXtensible Markup Language, techniek voor het structureren van elektronische documenten Ziekenhuis Apotheek Informatie Systeem

ZAIS ZIM

ZIS ZSP

Zorg Informatie Makelaar, onderdeel van de basisinfrastructuur in de zorg waarlangs alle aangesloten GBZ’en veilig patiëntgegevens kunnen uitwisselen Ziekenhuis Informatie Systeem Zorg Service Provider, netwerkdienstverlener die namens LSP zorgaanbieders met hun GBZ mag aansluiten op de ZIM


- 15 –

2.4 Begrippen Begrip

Omschrijving

Abonnee

Zorgaanbieder die met het UZI-register een overeenkomst sluit om UZI-passen te kunnen afnemen programmatuur die bepaalde functies kan leveren aan Gebruikers of andere ICT-voorzieningen toekennen van bevoegdheden aan een persoon of organisatie controleren van de authenticiteit zekerheid dat de identiteit waarvoor een persoon of organisatie zich uitgeeft juist is door Patiënt / Cliënt bepaalde autorisatietabel die bepaalt welke categorieën van zijn patiëntgegevens voor welke Zorgaanbieders toegankelijk zijn onder welke voorwaarden

Applicatie Autoriseren Authenticeren Authenticiteit Autorisatieprofiel

Autorisatieprotocol

door Zorgaanbieders gedefinieerde autorisatietabel die bepaalt welke categorieën patiëntgegevens voor welke categorieën Zorgaanbieders toegankelijk zijn onder welke voorwaarden

Basisinfrastructuur

Dienst

geheel aan gemeenschappelijke ICT-voorzieningen met bijbehorende organisatorische voorzieningen kans dat een systeem in staat is de gespecificeerde diensten of functies te bieden verantwoordelijkheid van een zorgverlener t.o.v. een patiënt/cliënt m.b.t. de overeengekomen zorgdienst kans dat een systeem de gespecificeerde diensten of functies uitvoert conform de specificatie (IEC 61508) persoon die verpleging of verzorging (care) geniet of mogelijk zal genieten prestatie geleverd door een partij aan een andere partij

Duplicaatbericht Elektronisch Patiëntdossier

bericht met dezelfde ID als een ander bericht ICT-voorziening die toegang geeft tot de verschillende patiëntdossiers binnen een zorginstelling

Functie GBZ-applicatie

Gegevenssoort

zie Systeemfunctie of Zorgverlenerfunctie Zorgapplicatie die als onderdeel van een GBZ is aangesloten op de ZIM Zorgverlener of Medewerker die gebruik maakt van een GBZ_applicatie actie van een Gebruiker m.b.t. het landelijk uitwisselen van Patiëntgegevens, zie [Spec Basisinfra] § 5.3.1 periode dat een Gebruiker via een GBZ-applicatie gebruik maakt van zijn bevoegdheden tot landelijke uitwisseling van patiëntgegevens typering van een soort van patiëntgegevens

Herroepen Hoofdbehandelaar

ongeldig maken, bijv. van een patiëntstuk Zorgaanbieder waarmee een Patiënt / Cliënt een behandel-

Beschikbaarheid Betrokkenheid Betrouwbaarheid Cliënt

Gebruiker Gebruikersinteractie Gebruikersessie

- 16 -


Hostnaam Identificeren ICT-infrastructuur ICT-voorziening Integriteit

Interactiemechanisme Mandateren Medebehandelaar Medewerker

Onweerlegbaarheid Patiënt Patiëntbericht Patiëntdocument

Patiëntgegevens

Patiëntdossier

Patiëntenindex Patiëntstuk Postbus Rol

Sessie SSL/TLS-sessie Systeem

overeenkomst heeft in een DNS-server geregistreerde naam van een systeem op het internet of een ander IP-netwerk, zie RFC 3986 bepalen van de identiteit van een persoon of organisatie geheel aan gemeenschappelijke ICT-voorzieningen hardware en software gericht op het elektronisch verwerken of communiceren van informatie zekerheid dat bepaalde gegevens niet (ongemerkt) kunnen worden gewijzigd wijze waarop een Gebruikersinteractie vanaf een GBZ door de ZIM wordt afgehandeld in relatie tot andere betrokken GBZ’en overdragen van bevoegdheden bij het delegeren van taken Zorgaanbieder die in opdracht van een Hoofdbehandelaar handelt persoon in dienst van een Zorginstelling of in dienst bij een Zorgverlener die in opdracht daarvan ondersteunende diensten verleent zekerheid dat bepaalde handelingen niet kunnen worden ontkend door de verantwoordelijke persoon die geneeskundig onderzoek of behandeling (cure) geniet of mogelijk zal genieten bericht met Patiëntgegevens dat in het kader van samenwerking wordt verstuurd aan een Zorgaanbieder persistente verzameling van samenhangende Patiëntgegevens die als één geheel wordt vastgelegd, opgevraagd en verstuurd. (persoonlijke, logistieke, medische en/of financiële) gegevens over een bepaalde Patiënt / Cliënt die zijn vastgelegd in het kader van een Zorgdienst verzameling van Patiëntgegevens van één of meer Patiënten / Cliënten onder beheer van de verantwoordelijke zorgaanbieder Lijst met identificerende gegevens van patiënten van een zorgaanbieder deel van, of uittreksel uit, een Patiëntdossier zie Zorgaanbiederpostbus een veelgebruikte term met verschillende interpretaties, zie verder onder Betrokkenheid, Werkverband en Zorgverlenerfunctie Zie SSL/TLS-sessie of Gebruikersessie tijdelijke verbinding tussen twee systemen op basis van SSL of TLS ICT-voorziening of verband van ICT-voorzieningen, al dan niet inclusief de beheerders en gebruikers, dat zelfstandig Diensten of Functies kan leveren


- 17 –

Systeemfunctie Time-out

prestatie geleverd door een Systeem aan een Gebruiker het verlopen van een tijdsinterval waarbinnen een systeem het resultaat van een actie afwacht alvorens een fout wordt verondersteld

Toepassingsrol

functie van een Applicatie in het kader van een bepaalde landelijke Zorgtoepassing reeks van twee of meer iinteracties die als één geheel moeten worden uitgevoerd persoonsgebonden vertrouwensmiddel voor Zorgverleners en hun Medewerkers, uitgegeven door het UZI-register systeemgebonden vertrouwensmiddel voor ICTvoorzieningen van Zorgaanbieders, uitgegeven door het UZI-register zekerheid dat bepaalde gegevens uitsluitend door bevoegden kunnen worden ingezien middel waarmee iemand zich elektronisch kan identificeren, authenticeren en eventueel een elektronische handtekening kan zetten

Transactie UZI-pas UZIservicescertificaat Vertrouwelijkheid Vertrouwensmiddel

Werkverband

XIS-applicatie Zoekpad Zorgaanbieder Zorgaanbiedergids

Zorgaanbiedernummer Zorgaanbiederpostbus Zorgapplicatie

Zorgcontact Zorgdienst

Zorginstelling

Zorgpartij Zorgsysteem

- 18 -

de verantwoordelijkheid van een Zorgpartij t.o.v. zijn eventuele Zorginstelling m.b.t. het verlenen van Zorgdiensten onderdeel van een XIS dat als GBZ-applicatie zou kunnen functioneren set van identificerende gegevens t.b.v het zoeken in een register of gids individuele Zorgverlener of Zorginstelling gids waarin Zorginstellingen en Zorgverleners de door hun geboden Zorgdiensten en bereikbaarheidsgegevens kunnen vermelden identificatienummer van een Zorgverlener of medewerker, zonodig in combinatie met het identificatienummer van de Zorginstelling verzameling door Zorgaanbieder af te handelen Patiëntberichten Applicatie die ter beschikking van een Zorgpartij staat, nader onder te verdelen in Zorgaanbiederapplicatie, Patiëntapplicatie, etc. sessie waarin een Zorgaanbieder aandacht besteedt aan één of meer Zorgvragen van een Patiënt / Cliënt dienst gericht op het onderzoeken, verbeteren, behouden of ondersteunen van de lichamelijke of geestelijke gezondheidstoestand van een Patiënt / Cliënt organisatorisch verband van Zorgverleners en ondersteunende medewerkers dat Zorgdiensten verleent aan een Patiënt / Cliënt persoon of organisatie die een primaire rol speelt bij de verlening van Zorgdiensten ICT-voorziening die rechtstreeks ter beschikking staat van


Zorgtoepassing

Zorgverlener Zorgverlenerfunctie

Zorgverzekeraar Zorgvraag

een Zorgaanbieder toepassing van landelijke uitwisseling van patiëntgegevens tussen samenwerkende zorgaanbieders, ten behoeve van een bepaalde Zorgdienst persoon die beroepsmatig Zorgdiensten verleent aan een Patiënt / Cliënt de beroepstitel (en eventueel het specialisme) van een zorgverlener die bepaalt welke zorgdiensten hij of zijn zorginstelling kan verlenen ziekenfonds, ziektekostenverzekeraar of zorgkantoor 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.


- 19 –

3

Overzicht van een GBZ

Dit hoofdstuk geeft een beeldende beschrijving van wat een GBZ zou kunnen zijn, maar is niet normatief. Dit is nodig omdat de eisen in de navolgende hoofdstukken, die wel normatief zijn, zoveel mogelijk SMART zijn geformuleerd en dus geen ruimte voor een beeldende beschrijving of een suggestief voorbeeld laat.

3.1 Wat is een GBZ? Een GBZ wordt gedefinieerd als: •

een XIS-applicatie of een verzameling van XIS-applicaties,

•

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,

•

die zich met één UZI-servicescertificaat authenticeert,

•

inclusief de voorzieningen die waarborgen dat alleen bevoegden toegang krijgen tot patiëntgegevens,

•

inclusief de gebruiks- en beheerprocedures voor de gebruikers en beheerders van alle bovengenoemde voorzieningen.

GBZ’en kunnen in aard en omvang verschillen. Qua aard kan een GBZ bijvoorbeeld omvatten: •

een enkele XIS-applicatie, zoals een HIS bij een huisarts,

•

een verzameling XIS’en, zoals het ZIS, ZAIS, RIS, LIS, etc. van een ziekenhuis.

Qua omvang kan een GBZ bijvoorbeeld omvatten: •

een enkele PC met een XIS-applicatie, zoals bij een huisarts,

•

een client/server-platform, waarbij een XIS deels op de client en deels op de server draait, zoals in een gezondheidscentrum,

•

een ASP-platform met een XIS dat via een PC met webbrowser via het internet kan worden benaderd, zoals in een HAP,

•

een verzameling platformen met verscheidene XIS’en, gekoppeld via een communicatieserver en door de gebruikers te benaderen via een verzameling PC’s, zoals in een ziekenhuis.

- 20 -


De bovenstaande voorbeelden zijn niet normatief. Er is pas sprake van een GBZ indien het voldoet aan de eisen zoals gespecificeerd in de navolgende hoofdstukken van dit document.

3.2 Categorieën van eisen aan een GBZ De eisen die worden gesteld aan een GBZ vallen uiteen in de volgende categorieën: •

Applicatie-eisen waaraan iedere XIS-applicatie binnen een GBZ moet voldoen. Het gaat hier vooral om functies die een XIS-applicatie moet kunnen uitvoeren in opdracht van een gebruiker of na ontvangst van een bericht van de ZIM. Deze eisen zijn gespecificeerd in hoofdstuk 4.

•

Implementatie-eisen waaraan een GBZ moet voldoen. Het gaat hier vooral om de kwaliteiten die een GBZ met de geïmplementeerde XIS-applicaties, compleet met alle benodigde voorzieningen en koppelingen met andere systemen binnen een zorgaanbieder, voortdurend moet kunnen leveren. Deze eisen zijn gespecificeerd in hoofdstuk 5.

•

Exploitatie-eisen waaraan een GBZ moet voldoen. Het gaat hier vooral om de gebruiks- en beheerprocedures die een GBZ in staat stellen diensten te leveren aan de buitenwereld, zijnde patiënten, het LSP en alle andere daarop aangesloten GBZ’en. Deze eisen zijn gespecificeerd in hoofdstuk 6.

De onderstaande figuur toont hoe diensten, functies en kwaliteiten in theorie samenhangen binnen een GBZ: diensten

functies

diensten

Zorgaan bieder

diensten

Patiënt/cliënt

functies

Zorgverlener

XIS applicatie implementatie

gebruiksprocedures

functies

Beheerder beheerprocedures

In de bovenstaande figuur is nog niet getoond dat behalve de zorgaanbieder ook diens XIS-leverancier een belangrijke rol kan spelen bij het beheer van het GBZ. Ook is niet getoond dat één GBZ meerdere XIS’en kan omvatten. Deze aspecten komen aan de orde in paragraaf 3.4.

3.3 Omgeving van een GBZ De onderstaande figuur toont hoe de verschillende diensten en functies van een GBZ samenhangen met zijn omgeving.


- 21 –

NICTIZ

u Klanten ondersteuning

CIBG

Systeem beheerder

Systeem beheerder

F2

Klanten ondersteuning

F4

UZIregisterF1 F3

F1

v

SBV-Z

w LSP opdrachtgever

x s t

Autorisatie manager

n

o

p

Log beheerder

Autorisatie beheerder

LSP opdrachtnemer

F3

F2

LSP

F1

F4

F5

Klanten ondersteuning

Systeem beheerder

q

F7 Applicatie beheerder

F6

Test/acceptatie beheerder

k

ICTarchitecten

r

Systeem beheerder F1 F3

Klanten ondersteuning j

e

F1

DCN

F1

F1

h

i

b

a Zorg verlener

Systeem beheerder

GBZ

XIS

c Autorisatie beheerder

- 22 -

Programmamanagers

F8

F1

l

ZSP

d

F1

ZIM

m

Patiënt/ cliënt

Applicatie beheerder

Toezicht houder

Log beheerder

Berichten modelleurs

f

g Test/acceptatie Applicatie beheerder ontwikkelaar D1

XIS

XIS leverancier

Zorg aan bieder


De zorgaanbieder levert de volgende diensten: (a) de zorgverlener levert zorgdiensten aan de patiënt/cliënt en legt patiëntgegevens vast in zijn XIS en wisselt ze uit met andere zorgaanbieders via de ZIM. (b) de zorgverlener stelt met zijn XIS patiëntgegevens beschikbaar voor opvraag door andere zorgaanbieders via de ZIM. (c) de lokale autorisatiebeheerder biedt de patiënt/cliënt eventueel de mogelijkheid om een intern autorisatieprofiel in te stelllen. (d) de lokale logbeheerder biedt de patiënt/cliënt eventueel de mogelijkheid om de interne toegangslog te raadplegen. (e) de systeembeheerder beantwoordt eventuele vragen en verzoeken van de ZSP. De XIS-leverancier van de zorgaanbieder levert de volgende diensten: (f) de XIS-test/acceptatie-beheerder test zijn XIS tegen de test-ZIM. (g) de XIS-applicatieontwikkelaar implementeert in overleg met NICTIZ nieuwe functies 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 voor vragen en verzoeken van zorgaanbieders inzake de aansluiting op het LSP. Het LSP levert de volgende diensten: (k) de ZIM levert verwijs- en routeringsdiensten aan de aangesloten XIS’en van zorgaanbieders. (l) de LSP-systeembeheerder regelt op verzoek van de ZSP-systeembeheerder de koppeling van XIS’en aan de ZIM via zijn DCN. (m) de LSP-klantenondersteuning handelt de door de ZSP-klantenondersteuning doorverwezen vragen en verzoeken van zorgaanbieders af. (n) de LSP-logbeheerder doorzoekt op verzoek van de toezichthouder de toegangslog, al dan niet ten behoeve van een patiënt/cliënt. (o) de LSP-autorisatiebeheerder werkt op verzoek van de autorisatiemanager het landelijke autorisatieprotocol en de autorisatieprofielen van patiënten bij.


- 23 –

(p) de LSP-opdrachtnemer rapporteert aan de LSP-opdrachtgever van NICTIZ, over de diensten geleverd door het LSP en maakt afspraken met de LSPopdrachtnemer over de eventuele uitbreiding of bijstelling van de diensten. (q) de LSP-applicatiebeheerder implementeert op verzoek van NICTIZ nieuwe functies en (versies van) gestandaardiseerde berichtformaten. (r) de LSP-test/acceptatie-beheerder geeft XIS-leveranciers de mogelijkheid om hun XIS te testen op het voldoen aan de eisen voor een GBZ. Een nader aan te wijzen partij (in de figuur aangeduid met ???) levert de volgende diensten: (s) de toezichthouder controleert de rechtmatigheid van landelijke toegang tot patiëntgegevens door zorgaanbieders, dit zowel op eigen initiatief als op verzoek van patiënten/cliënten. (t) de autorisatiemanager zorgt namens beroepsverenigingen van zorgverleners en namens patiënten/cliënten voor de juiste instellingen van het landelijke autorisatieprotocol respectievelijk de autorisatieprofielen. Het CIBG levert de volgende diensten: (u) het UZI-register geeft na zorgvuldige registratie aan zorgaanbieders UZIpassen en UZI-servicescertificaten uit. (v) het UZI-register publiceert certificaten van uitgegeven UZI-passen en lijsten van ingetrokken UZI-certificaten, onder meer ten behoeve van het LSP. (w)de SBV-Z levert aan het LSP een berichtendienst voor het opvragen of verifiëren van het BSN van een patiënt/client. (x) de applicatieontwikkelaar implementeert op verzoek van NICTIZ nieuwe functies en (versies van) gestandaardiseerde berichtformaten. De menssymbolen in de bovenstaande figuur vertegenwoordigen de aanspreekpunten voor de verschillende diensten. De menssymbolen zijn geenszins bedoeld om voor te schrijven op welke manier de getoonde partijen hun interne organisatie moeten inrichten.

3.4 Grenzen van een GBZ Zoals de bovenstaande figuur toont is een GBZ veel meer dan de XIS (-en) zoals die van de XIS-leverancier(s) komt: het omvat alle aspecten van implementatie bij de zorgaanbieder en exploitatie door de zorgaanbieder. Niettemin blijft een XISleverancier vaak een belangrijke rol spelen, bijv.: •

Bij de ontwikkeling van een XIS zal een XIS-leverancier zich moeten conformeren aan GBZ-eisen en kan een XIS-typegoedkeuring voor zijn XIS proberen te verwerven.

•

Bij het beheer van een XIS kan de zorgaanbieder diverse taken (hosting, technisch beheer, applicatiebeheer) uitbesteden aan een XIS-leverancier. In

- 24 -


geval van ASP zullen meerdere zorgaanbieders dat gezamenlijk doen bij één XIS-leverancier. In al deze gevallen blijft de zorgaanbieder verantwoordelijk. Een zorgaanbieder kan meerdere XIS-leveranciers inschakelen voor één GBZ. Een zorgaanbieder met een ICT-afdeling kan deels ook zijn eigen XIS-leverancier zijn. Al deze nuances zijn weggelaten in de figuur van paragraaf 3.3. De exacte grens van een GBZ kan verschillen per situatie, maar wordt meestal begrensd door de systemen die patiëntgegevens delen die in het kader van een zorgtoepassing via het LSP zullen worden uitgewisseld. . De verantwoordelijke zorgaanbieder kan zelf bepalen welk deel van zijn ICT-voorzieningen wel/niet tot zijn GBZ behoren. Tijdens de kwalificatie kan blijken of die grenzen goed gekozen zijn. Met name eis (d) van paragraaf 5.3 speelt hier een grote rol. In de loop van de tijd kan een GBZ groeien. Zo kan bijv. een ziekenhuis beginnen met de kwalificatie van zijn ZIS als GBZ en daaraan later het ZAIS, RIS, LIS, etc. toe te voegen. De grenzen van een GBZ kunnen in principe dwars door ICT-voorzieningen lopen. Zo bestaat een ZIS vaak uit verschillende modules die al of niet tot een GBZ worden gerekend. Het is daarom beter te spreken over een XIS-applicatie als atomair onderdeel van een XIS dat zelfstandig kan aansluiten op het LSP en derhalve al of niet tot een GBZ kan behoren. Een bijzonder geval is het ASP-model, waarbij alle deelnemende zorgaanbieders voor hun GBZ grotendeels gebruik maken van gemeenschappelijke ICTvoorzieningen. Dit is geen probleem zolang de patiëntgegevens van de afzonderlijke zorgaanbieders logisch van elkaar gescheiden zijn, zodanig dat bijv. landelijke uitwisseling van patiëntgegevens niet buiten het LSP om plaatsvindt. In de loop van de tijd kunnen grenzen vervagen en verschuiven. Zorgaanbieders kunnen fuseren tot één zorgaanbieder. Een zorgaanbieder kan er op zeker moment voor kiezen om al zijn GBZ’en te laten versmelten tot één GBZ. Een GBZ moet feitelijk een goed beheerde en beveiligde zone (Engels: secure zone) vormen, waarbinnen één of meer XIS-applicaties draaien.

3.5 GBZ-kwalificatie Om te mogen aansluiten op het LSP, heeft een zorgaanbieder een GBZ-kwalificatie nodig voor zijn ICT-voorzieningen. Het aansluiten van een zorgaanbieder op het LSP geschiedt op twee niveaus, zie ook [Spec Basisinfra] paragraaf 5.5: •

op netwerkniveau wordt een GBZ als geheel gekoppeld aan de ZIM,

•

op applicatieniveau wordt iedere XIS-applicatie binnen dat GBZ afzonderlijk aangesloten.

Daarvoor gelden de volgende voorwaarden: •

voor iedere aangesloten XIS-applicatie binnen een GBZ moet aan de applicatie-eisen worden voldaan. Deze eisen kunnen deels vooraf worden getest door aansluiting op de test-ZIM.


- 25 –

•

voor het gekoppelde GBZ met alle aangesloten XIS-applicaties moet aan de implementatie-eisen en de exploitatie-eisen worden voldaan. Deze eisen kunnen beperkt vooraf worden getoetst. Dus zal in de praktijk moeten blijken of aan de eisen wordt voldaan.

Een GBZ-kwalificatie is dus geen keurmerk dat op één tijdstip wordt verkregen, maar een verzameling eisen waaraan moet wordt voldaan, zoals op verschillende tijdstippen zal moeten blijken. In een apart document zal precies worden gedefinieerd welke eisen, wanneer en op welke wijze getoetst gaan worden. Wanneer een XIS-applicatie of een verzameling XIS-applicaties reeds een XIS-typegoedkeuring heeft verworven, hoeven de applicatie-eisen bij aansluiting, , afhankelijk van de specifieke implementatie bij de zorgaanbieder, niet allemaal opnieuw te worden getest.

3.6 XIS-typegoedkeuring Een XIS-typegoedkeuring zal verschillen per XIS of XIS-applicatie, afhankelijk van: •

de landelijke zorgtoepassingen die worden ondersteund door de XIS: o EMD o WDH o etc.

•

de toepassingsrol van de XIS binnen iedere landelijke toepassing: o EMD: voorschrijver, verstrekker o WDH : dossierhouder, waarnemer

Zo kan een AIS van een apotheek het keurmerk EMD-verstrekker verwerven. Een HIS van een huisarts kan aanvankelijk het keurmerk EMD-voorschrijver verwerven en later uitbreiden naar EMD-voorschrijver en WDH-dossierhouder. In de toekomst kunnen zonodig meer toepassingsrollen worden gedefinieerd dan de bovenstaande. Zo valt te denken aan EMD-inkijker voor bijv. thuiszorginstellingen die patiënten/cliënten helpen bij het dagelijkse gebruik van medicatie. Verder kunnen XIS-typegoedkeuringen in de toekomst een release-aanduiding krijgen. Op het moment dat er voor een bepaalde landelijke zorgtoepassing nieuwe (versies van) HL7-berichten komen, zal onderscheid gemaakt moeten worden tussen een XIS die de oude release ondersteunt en een XIS die al de nieuwe release ondersteunt. Het LSP zal bij aansluiting van een XIS-applicatie op de ZIM het keurmerk vastleggen in een configuratietabel. De ZIM weet dan welke HL7-berichten die XISapplicatie mag versturen en welke HL7-berichten die XIS-applicatie kan ontvangen en verwerken.

- 26 -


3.7 XIS-combinaties Grotere zorginstellingen hebben meestal verschillende XIS’en, bijv. een ZIS, ZAIS, RIS, LIS, etc., die ieder gebruik kunnen maken van gemeenschappelijke ICTvoorzieningen binnen de zorginstelling, bijv.: •

een centrale patiëntenindex (CPI) die de patiëntidentificatie voor alle aangesloten XIS’en verzorgt,

•

een clinical data repository (CDR) die de opslag van patiëntgegevens voor alle aangesloten XIS’en verzorgt,

•

een communicatieserver (CS) die de berichtuitwisseling tussen de verschillende XIS’en verzorgt.

In deze gevallen is het denkbaar dat de XIS-applicaties niet afzonderlijk worden aangepast voor àlle GBZ-eisen, maar bijv.: •

alleen de centrale patiëntenindex (CPI) geschikt wordt gemaakt voor koppeling van patiëntgegevens aan het BSN,

•

alleen de clinical data repository (CDR) geschikt wordt gemaakt voor hoge beschikbaarheid van patiëntgegevens voor opvraag door anderen,

•

alleen de communicatieserver (CS) geschikt wordt gemaakt voor uitwisseling van HL7v3-berichten.

Dit zou betekenen dat een XIS niet zelfstandig een XIS-typegoedkeuring kan verkrijgen, maar wel in combinatie met andere ICT-voorzieningen. In dergelijke gevallen zou een XIS-typegoedkeuring van bijv. een ZAIS kunnen aanduiden: • “ZAIS van leverancier A in combinatie met CPI van leverancier B en CS van leverancier C voldoet aan de eisen voor toepassingsrol EMD-verstrekker.” Bij de implementatie van een GBZ zal de zorgaanbieder moeten aantonen dat de ZAIS voor de patiëntidentificatie daadwerkelijk gebruik maakt van de desbetreffende CPI en CS.

3.8 Aansluitvoorwaarden versus gebruikerswensen De GBZ-eisen zijn te onderscheiden in: •

Aansluitvoorwaarden, minimale eisen die door het LSP worden gesteld aan een GBZ alvorens het GBZ kan worden aangesloten op de ZIM. Deze eisen hebben (alleen in hoofdstuk 4) het etiket {eis}.

•

Gebruikerswensen, aanvullende eisen die door een zorgaanbieder kunnen worden gesteld aan een XIS-leverancier opdat de mogelijkheden van de ZIM daadwerkelijk worden benut. Deze eisen hebben het etiket {wens}.

Zo is de ondersteuning van het gebruiksscenario voor het selecteren van een zorgaanbieder in de landelijke zorgaanbiedergids (zie paragraaf 4.4) geen


- 27 –

voorwaarde voor aansluiting op de ZIM. In plaats daarvan kan een XIS-applicatie gebruik maken van een lokaal bestand. Echter, als een zorgaanbieder dit gebruiksscenario toch wil gebruiken, kan een zorgaanbieder deze eisen zelf stellen aan zijn XIS-leverancier. Maar als een GBZ dan gebruik maakt van de zorgaanbiedergids, zal het moeten voldoen aan de eisen gesteld aan de berichtuitwisseling. Behalve het bovengenoemde gebruiksscenario als geheel, worden ook individuele gebruikersfuncties als gebruikerswens aangemerkt. Zo zijn eisen met betrekking tot de wijze van presenteren van gegevens (bijv. sorteren, doseren,) meestal gebruikerswensen en geen voorwaarde voor aansluiting op de ZIM. De reden dat deze functies hier toch zijn opgenomen, is omdat deze functies invloed kunnen hebben op de wijze waarop het GBZ berichten zal uitwisselen met de ZIM. Als alle zorgaanbieders andere gebruikerswensen hebben, kunnen de ontwikkelkosten van een XIS hoog oplopen. Het is daarom verstandig als zorgaanbieders gezamenlijk (bijv. binnen een regio, of met betrekking tot bepaalde zorgtoepassingen) besluiten te kiezen voor bepaalde gebruikerswensen.

3.9 Toepassingsrol-afhankelijke eisen Niet alle GBZ-eisen zijn relevant voor alle zorgtoepassingen of toepassingsrollen. Het gaat hier met name om gebruiksscenario’s met betrekking tot patiëntgegevens en eisen inzake berichtuitwisseling van een bepaalde gegevenssoort. Zo hoeft een XIS-applicatie met toepassingsrol WDH-dossierhouder geen gebruikersfuncties te ondersteunen voor het opvragen van patiëntgegevens. Daarentegen moet deze XIS-applicatie wel de berichtuitwisseling ondersteunen voor opleveren van patiëntgegevens aan een XIS-applicatie met toepassingsrol WDH-waarnemer. De onderstaande tabel toont welke gebruiksscenario’s wel of niet van toepassing zijn voor de momenteel bekende toepassingsrollen. Gebruiksscenario Selecteren zorgaanbieder Bijhouden patiëntgegevens Publiceren patiëntgegevens Initieel koppelen patiëntgegevens Opvragen patiëntgegevens Versturen patiëntgegevens Raadplegen toegangslog Bijhouden mandateringen

EMDvoorschrijver wel

EMDverstrekker niet

WDH-dossierhouder niet

WDHwaarnemer wel

wel

wel

wel

wel

wel

wel

wel

wel

wel

wel

wel

wel

wel

wel

niet

wel

wel

wel

niet

wel

wel

wel

wel

wel

wel

wel

wel

wel

Voor wat betreft de berichtuitwisseling, zie de tabellen in paragraaf 4.14 en 4.15.

- 28 -


4

Applicatie-eisen

Dit hoofdstuk beschrijft normatief de applicatie-eisen waaraan een (combinatie van) XIS-applicatie (-s) moet voldoen om als onderdeel van een GBZ te kunnen worden aangesloten op het LSP. Het gaat hier vooral om functies die een GBZ-applicatie moet kunnen uitvoeren in opdracht van een lokale gebruiker of na ontvangst van een bericht van de ZIM.

4.1 Inleiding Een GBZ-applicatie binnen een GBZ moet de volgende functies kunnen uitvoeren, ongeacht of de gebruikers die daadwerkelijk benutten: •

gebruikersfuncties in opdracht van een lokale gebruiker: een zorgverlener, een medewerker of een systeembeheerder van de zorgaanbieder,

•

berichtuitwisseling met de ZIM als gevolg van de gebruikersfuncties of ten behoeve van andere zorgaanbieders.

Deze functies worden gepositioneerd door de onderstaande figuur.

bericht uitwisseling

gebruiks functies

XIS applicatie

beheer functies

De gebruikersfuncties voor zorgverleners en hun medewerkers omvatten: (a) in/uitloggen gebruiker, zie paragraaf 4.2, (b) selecteren patiënt/cliënt, zie paragraaf 4.3, (c) selecteren zorgaanbieder, zie paragraaf 4.4, (d) bijhouden patiëntgegevens, zie paragraaf 4.5, (e) (f) (g) (h) (i) (j)

publiceren patiëntgegevens, zie paragraaf 4.6, koppelen patiëntgegevens, zie paragraaf 4.7, opvragen patiëntgegevens, zie paragraaf 4.8, versturen patiëntgegevens, zie paragraaf 4.9, raadplegen toegangslog, zie paragraaf 4.10, bijhouden mandateringen, zie paragraaf 4.11,

De gebruikersfuncties voor beheerders omvatten: (k) aan/afsluiten GBZ-applicatie, zie paragraaf 4.12, (l) beheren GBZ-applicatie, zie paragraaf 4.13.


- 29 –

Berichtuitwisseling met de ZIM omvat: (m) berichtuitwisseling met de ZIM als gevolg van de gebruikersfuncties, zie paragraaf 4.14, (n) berichtuitwisseling met de ZIM ten behoeve van andere zorgaanbieders, zie paragraaf 4.15. In dit hoofdstuk zijn eisen die voortvloeien uit bijv. de WGBO en de NEN 7510 nadrukkelijk niet opgenomen als aansluitvoorwaarde, omdat een XIS-applicatie daaraan sowieso moet voldoen, ook als deze niet wordt aangesloten op het LSP.

- 30 -


4.2 In-/uitloggen gebruiker Wanneer een zorgverlener/medewerker via een GBZ-applicatie op een werkplek gebruik wil maken van zijn bevoegdheden tot het landelijk uitwisselen van patiëntgegevens, dient hij zich eerst te identificeren en authenticeren aan het LSP. Zie verder [Spec Basisinfra] paragraaf 4.2.2 en paragraaf 4.4.2. In dat document zijn de volgende gebruiksscenario’s onderkend: •

(gebruiksscenario 0.2.1) inloggen van een gebruikersessie.

•

(gebruiksscenario 0.2.2) uitloggen van de gebruikersessie.

Bij (gebruiksscenario 0.2.1) inloggen gebruikersessie gelden de volgende eisen en wensen: (a) {eis} Een zorgverlener/medewerker moet een sessie voor het landelijk uitwisselen van patiëntgegevens op vertrouwensniveau laag kunnen starten door: het invoeren van zijn gebruikersnaam en wachtwoord. (b) {eis} Een zorgverlener/medewerker moet een sessie voor het landelijk uitwisselen van patiëntgegevens op vertrouwensniveau midden kunnen starten door: het invoeren van zijn UZI-pas op de werkplek, en het invoeren van de bijbehorende toegangscode (PIN-code). (c) {wens} Een zorgverlener/medewerker moet een sessie voor het landelijk uitwisselen van patiëntgegevens op vertrouwensniveau midden tijdelijk kunnen onderbreken door: het uitnemen van zijn UZI-pas op de werkplek. (d) {wens} Een zorgverlener/medewerker moet die sessie voor het landelijk uitwisselen van patiëntgegevens op vertrouwensniveau midden binnen het tijdsinterval gebruiker-max-kaart-uit na onderbreking kunnen voortzetten door het opnieuw invoeren van zijn UZI-pas op de werkplek. Bij (gebruiksscenario 0.2.2) uitloggen gebruikersessie gelden de volgende eisen en wensen: (e) {eis} Een zorgverlener/medewerker moet een sessie voor het landelijk uitwisselen van patiëntgegevens op vertrouwensniveau laag of midden op commando kunnen afsluiten. (f) {eis} Een sessie voor het landelijk uitwisselen van patiëntgegevens op vertrouwensniveau midden moet in de volgende gevallen automatisch worden afgesloten: 1. wanneer de UZI-pas meer dan het tijdsinterval gebruiker-max-kaartuit van de werkplek is verwijderd, 2. wanneer de gebruiker zijn GBZ-applicatie gedurende het tijdsinterval gebruiker-max-applicatie-onbruik niet meer heeft gebruikt. (g) {wens} Een zorgverlener/medewerker moet worden geïnformeerd als zijn sessie is beëindigd door het LSP, zoals zal geschieden in de volgende gevallen:


- 31 –

1. wanneer deze sessie reeds gedurende het tijdsinterval gebruikermax-sessie-duur open staat, 2. wanneer de gebruiker via deze sessie gedurende het tijdsinterval gebruiker-max-sessie-onbruik geen gegevens meer landelijk heeft uitgewisseld, {toekomst} Voor deze gebruiksscenario’s is het nodig dat de GBZ-applicatie zich als actief heeft gemeld bij het schakelpunt (zie gebruiksscenario 0.1.1, paragraaf 4.12).

- 32 -


4.3 Selecteren patiënt/cliënt Een zorgaanbieder die contact heeft met een patiënt/cliënt, zal die patiënt/cliënt moeten identificeren door het bepalen van diens landelijke patiëntnummer (BSN) en zonodig authenticeren door het controleren van diens Wettelijk Identificatie Document (WID). Bovendien zal de zorgaanbieder bij het eerste contact na de invoering van het BSN extra controles moeten uitvoeren: • het BSN opvragen of verifiëren bij de SBV-Z , • het WID controleren op gelijkenis met de patiënt/cliënt, • het WID controleren op echtheidskenmerken, • {toekomst} de geldigheid van het WID controleren, • het dossier inhoudelijk controleren met de patiënt/cliënt, • de identificerende gegevens in het dossier zonodig actualiseren. Zie verder [Spec Basisinfra] paragraaf 4.2.3, paragraaf 4.4.3 en bijlage A. In dat document zijn de volgende gebruiksscenario’s onderkend: •

(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: (a) {eis} De gebruiker moet een patiënt/cliënt kunnen opzoeken in de lokale patiëntenindex dan wel de patiëntdossiers bij de zorgaanbieder door het invoeren van identificerende gegevens, waarna wordt getoond: 1. of de patiënt/cliënt is gevonden, en zo ja 2. of het BSN wel/niet is opgevraagd of geverifieerd bij de SBV-Z. (b) {eis} Indien bij (a) de patiënt/cliënt niet is gevonden of blijkt dat nog geen BSN succesvol is opgevraagd of geverifieerd bij de SBV-Z, moet de gebruiker na invoeren van (een deel van) de onderstaande identificerende gegevens, het BSN van die patiënt/cliënt uit de SBV-Z gepresenteerd of bevestigd kunnen krijgen: 1. landelijk patiëntnummer (BSN); 2. geboortenaam; 3. voorvoegsels geboortenaam; 4. voornamen; 5. eerste voorletter; 6. geslachtsaanduiding; 7. geboortedatum; 8. geboorteplaats; 9. geboorteland; 10. postcode; 11. straatnaam; 12. huisnummer;


- 33 –

13. huisletter; 14. huisnummertoevoeging; 15. aanduiding bij huisnummer; 16. gemeente van inschrijving. waarbij: 17. de gebruiker bij het invullen eerst langs de attributen van de zoekpaden, zoals gedefinieerd in [BSN], wordt geleid, 18. {toekomst} plaatsnamen zonodig worden vertaald naar de gemeente waarvan zij onderdeel uitmaken, 19. diakritische tekens kunnen worden gepresenteerd, 20. eventueel foutief gespelde gegevens zo mogelijk automatisch worden gecorrigeerd. (c) {eis} Indien bij (b) de patiënt/cliënt is gevonden, moet de gebruiker het BSN kunnen koppelen aan diens identificerende gegevens in de patiëntenindex of het patiëntdossier waarbij automatisch wordt vastgelegd bij het overgenomen BSN: 1. de bron van het BSN (bijv. GBA, SBV-Z), 2. datum en tijd van koppelen, 3. UZI-nummer of andere identificatie van de gebruiker. Bij (gebruiksscenario 0.3.2) authenticeren patiënt/cliënt gelden de volgende eisen: (d) {eis} De gebruiker moet na identificatie van een patiënt/cliënt: 1. worden gewaarschuwd indien diens WID nog niet is gecontroleerd op gelijkenis met de patiënt/cliënt, 2. kunnen vastleggen in de patiëntenindex of het patiëntdossier dat hij heeft gecontroleerd of het WID hoort bij de patiënt/cliënt, onder vermelding van: § resultaat van de controle § datum en tijd § UZI-nummer of andere identificatie van de gebruiker § type en nummer van het WID. (e) {eis} De gebruiker moet na identificatie van een patiënt/cliënt: 1. worden gewaarschuwd indien diens WID nog niet is gecontroleerd op echtheidskenmerken, 2. kunnen vastleggen in de patiëntenindex of het patiëntdossier dat hij diens WID heeft gecontroleerd op echtheidskenmerken, onder vermelding van: § resultaat van de controle § datum en tijd § UZI-nummer of andere identificatie van de gebruiker § type en nummer van het WID. (f) {eis} {toekomst} De gebruiker moet na identificatie van een patiënt/cliënt: 1. worden gewaarschuwd indien de geldigheid van het WID nog niet is gecontroleerd, 2. de geldigheid van het WID kunnen controleren door raadplegen van het relevante WID-register na invoeren van de volgende WIDkenmerken: § type WID § nummer van het WID

- 34 -


1. kunnen vastleggen in de patiëntenindex of het patiëntdossier dat hij de geldigheid van diens WID heeft gecontroleerd, onder vermelding van: § resultaat van de controle § datum en tijd § UZI-nummer of andere identificatie van de gebruiker § type en nummer van het WID. Bij (gebruiksscenario 0.3.3) controleren patiëntendossier gelden de volgende eisen: (g) {eis} De gebruiker moet na identificatie van een patiënt/cliënt: 1. worden gewaarschuwd indien diens patiëntdossier nog niet inhoudelijk is gecontroleerd met de patiënt/cliënt, 2. kunnen vastleggen in de patiëntenindex of het patiëntdossier dat hij heeft gecontroleerd of het patiëntdossier inhoudelijk hoort bij de patiënt/cliënt, onder vermelding van: § resultaat van de controle § datum en tijd § UZI-nummer of andere identificatie van de gebruiker § UZI-nummer van de mandaterende zorgverlener, indien van toepassing 3. het BSN zonodig kunnen ontkoppelen van het patiëntdossier en derhalve alle eventueel reeds aangemelde gegevenssoorten weer afmelden. (h) {eis} 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 en wensen: (i) {wens} De gebruiker moet identificatie van een patiënt/cliënt: 1. worden gewaarschuwd indien de identificerende gegevens in de patiëntenindex of diens patiëntdossier niet overeenkomen met die in het landelijke patiëntenregister, 2. diens identificerende gegevens uit de SBV-Z desgewenst kunnen overnemen naar de patiëntenindex of diens patiëntendossier, onder automatische vermelding van: § datum en tijd § UZI-nummer of andere identificatie van de gebruiker. (j) {wens} {toekomst} De gebruiker moet kunnen aangeven dat hij voor een bepaalde patiënt/cliënt wil worden ingelicht door een patiëntenadresboek over eventuele wijzigingen van diens identificerende gegevens en bereikbaarheidsgegevens. (k) {wens} {toekomst} De gebruiker moet, na een signaal dat de identificerende gegevens en bereikbaarheidsgegevens van een patiënt zijn gewijzigd, de nieuwe gegevens kunnen overnemen in de patiëntenindex of diens patiëntdossier, waarbij automatisch wordt vastgelegd: 1. datum en tijd van overnemen, 2. UZI-nummer of andere identificatie van de gebruiker.


- 35 –

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft lokaal of landelijk ingelogd als zorgverlener of medewerker op vertrouwensniveau laag of midden (dus met gebruikersnaam/wachtwoord of UZI-pas, zie gebruiksscenario 0.2.1). In geval van gebruiksscenario 0.3.3 moet de medewerker gemandateerd zijn door een zorgverlener.

- 36 -


4.4 Selecteren zorgaanbieder Wanneer een zorgverlener aan een andere zorgaanbieder bepaalde patiëntgegevens wil toesturen, bijv. een medicatievoorschrift, moet hij diens HL7-adres kunnen bepalen. Als de zorgverlener een HL7-adres wil kunnen opvragen uit de landelijke zorgaanbiedergids, gelden de onderstaande eisen. Zie verder [Spec Basisinfra] paragraaf 4.2.4 en paragraaf 4.4.4. In dat document zijn de volgende gebruiksscenario’s onderkend: •

(gebruiksscenario 0.4.1) opzoeken zorgaanbieder in de zorgaanbiedergids.

•

(gebruiksscenario 0.4.2) opvragen bereikbaarheidsgegevens uit de zorgaanbiedergids.

•

(gebruiksscenario 0.4.3) bijwerken bereikbaarheidsgegevens in de zorgaanbiedergids.

•

(gebruiksscenario 0.4.4) controleren zorgaanbieder in het zorgaanbiederregister.

Bij (gebruiksscenario 0.4.1) opzoeken zorgaanbieder gelden de volgende eisen: (a) {wens} De gebruiker moet vrij kunnen zoeken in de zorgaanbiedergids en daarbij per zorgaanbieder de onderstaande gegevens gepresenteerd krijgen. 1. naam 2. vestigingsplaats 3. in geval van een zorginstelling bovendien: • type zorginstelling • eventueel lijst van afdelingen binnen deze zorginstelling 4. {toekomst} in geval van een zorginstelling-afdeling bovendien: • verwijzing naar de zorginstelling • eventueel lijst van zorgverleners binnen deze afdeling 5. in geval van een zorginstelling-zorgverlener bovendien: • verwijzing naar zijn zorginstelling • eventueel verwijzing naar zijn afdeling • beroepstitel • specialisme(n) 6. in geval van een individuele zorgverlener bovendien: • beroepstitel • specialisme(n) (b) {wens} De gebruiker moet na invoeren van één of meer van de onderstaande selectiecriteria, een lijst met alle matchende zorgaanbieders gepresenteerd krijgen, waaruit de zorgverlener kan selecteren om alsnog (a) gepresenteerd te krijgen: 1. {toekomst} zorginstellingtype (alleen voor zorginstellingen) 2. {toekomst} beroepstitel (alleen voor zorgverleners) 3. {toekomst} specialisme (alleen voor zorgverleners) 4. naam 5. vestigingsplaats of regio


- 37 –

Bij (gebruiksscenario 0.4.2) opvragen bereikbaarheidsgegevens gelden de volgende eisen en wensen: (c) {wens} De gebruiker moet voor een geselecteerde zorgaanbieder de volgende bereikbaarheidsgegevens gepresenteerd kunnen krijgen: 1. bezoekadres 2. fysiek postadres 3. elektronisch postadres (Internet: e-mail-adres) 4. elektronisch postadres (HL7v3: applicatie-id) 5. {toekomst} ondersteunde zorgtoepassingen en toepassingsrollen 6. telefoonnummers 7. {toekomst} beschikbare diensten per adres 8. {toekomst} openingstijden per dienst per adres 9. {toekomst} verwijzing naar een waarnemer (d) {wens} De gebruiker moet een elektronisch postadres door eenvoudig aanklikken kunnen overnemen als bestemming voor een te versturen patiëntbericht. Bij (gebruiksscenario 0.4.3) bijwerken bereikbaarheidsgegevens gelden de volgende eisen: (e) {wens} {toekomst} De gebruiker moet na gebruiksscenario 0.4.1 of 0.4.2, de onder gebruiksscenario 0.4.2 genoemde bereikbaarheidsgegevens kunnen bijwerken. Bij (gebruiksscenario 0.4.4) controleren zorgaanbieder gelden de volgende eisen: (f) {wens} {toekomst} De gebruiker moet na gebruiksscenario 0.4.1 of 0.4.2, een zorgaanbieder kunnen selecteren en diens gegevens opvragen uit het zorgaanbiederregister. Voor al deze gebruiksscenario’s is het nodig dat de gebruiker lokaal of landelijk heeft ingelogd als zorgverlener of medewerker op vertrouwensniveau laag of midden (dus met gebruikersnaam/wachtwoord of UZI-pas, zie gebruiksscenario 0.2.1).

- 38 -


4.5 Bijhouden Patiëntgegevens Wanneer een zorgverlener voor een patiënt/cliënt allerlei patiëntgegevens vastlegt in zijn dossier, ten behoeve van een landelijke zorgtoepassing, moeten deze patiëntgegevens zorgvuldig zijn gekoppeld aan het BSN van die patiënt/cliënt. Zie verder [Spec Basisinfra] paragraaf 4.2.5. In dat document zijn de volgende gebruiksscenario’s onderkend: •

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 eisen: (a) {eis} De gemandateerde gebruiker moet bij het vastleggen en herroepen van patiëntstukken in een patiëntdossier kunnen aangeven namens welke zorgverlener dit wordt gedaan. (b) {eis} De gebruiker moet de zekerheid hebben dat patiëntstukken, na het vastleggen daarvan in een patiëntdossier, niet ongemerkt kunnen worden gewijzigd. (c) {eis} {toekomst} De gebruiker moet onder zijn verantwoordelijkheid aangemaakte, vastgelegde en gefiatteerde patiëntstukken kunnen bekrachtigen door het zetten van een elektronische handtekening met behulp van zijn vertrouwensmiddel en deze toevoegen aan het patiëntdossier. Bij (gebruiksscenario 1.1.2) verwijderen patiëntgegevens gelden de volgende eisen en wensen: (d) {wens} De gebruiker moet op verzoek van een patiënt/cliënt bepaalde patiëntstukken kunnen verwijderen, waarbij na keuze: 1. {toekomst} de patiëntstukken worden versleuteld met behulp van het vertrouwensmiddel van de patiënt/cliënt, 2. de patiëntstukken definitief en onherstelbaar worden uitgewist, inclusief de eventuele verwijzingen vanuit een toegangslog voorzover die nog niet gearchiveerd zijn. Voor al deze gebruiksscenario’s is het nodig dat de gebruiker lokaal heeft ingelogd als zorgverlener of gemandateerde medewerker op vertrouwensniveau midden (dus met UZI-pas, zie gebruiksscenario 0.2.1).


- 39 –

4.6 Publiceren Patiëntgegevens Wanneer een zorgverlener allerlei patiëntstukken toevoegt aan zijn dossier, moeten deze patiëntstukken in principe automatisch worden gepubliceerd, opdat deze beschikbaar komen voor landelijke opvraag door andere zorgverleners. Toch moet de zorgverlener de mogelijkheid hebben bepaalde patiëntstukken af te schermen of het gehele dossier niet aan te melden. Zie verder [Spec Basisinfra] paragraaf 4.2.6 en paragraaf 4.4.7. In dat document zijn de volgende gebruiksscenario’s onderkend: •

Gebruiksscenario 1.2.1: vrijgeven patiëntgegevens en aanmelden bij de verwijsindex,

•

Gebruiksscenario 1.2.2: afschermen patiëntgegevens en afmelden bij de verwijsindex.

Bij (gebruiksscenario 1.2.1) vrijgeven patiëntgegevens gelden de volgende eisen: (a) {wens} De gebruiker moet kunnen instellen welke gegevenssoorten van patiëntstukken na toevoegen aan zijn dossier automatisch, dan wel op commando per patiëntstuk (zie paragraaf 4.5), worden vrijgegeven. (b) {eis} De gebruiker moet na het vastleggen van patiëntstukken in zijn dossier, deze automatisch of op commando per patiëntstuk kunnen vrijgeven. (c) {eis} De gebruiker moet naderhand individuele patiëntstukken in zijn dossier alsnog kunnen vrijgeven. (d) {eis} Bij het vrijgeven van een patiëntstuk moet de gebruiker erop kunnen vertrouwen dat: 1. hij wordt gewaarschuwd indien het patiëntstuk ooit als kopie van een andere zorgverlener is ontvangen, 2. de gegevenssoort van het patiëntstuk nieuw wordt aangemeld bij de verwijsindex, indien dat nog niet was gedaan, zoals voorgeschreven per zorgtoepassing, 3. de gegevenssoort van het patiëntstuk opnieuw wordt aangemeld (heraanmelden) bij de verwijsindex, indien de vorige aanmelding meer dan een bepaald tijdsinterval geleden is, (e) {eis} De gebruiker moet na het voorlopig koppelen (zie gebruikscenario 1.4.1) of na het definitief koppelen (zie gebruikscenario 0.3.3) van een patiëntdossier aan een BSN, de relevante patiëntstukken in één keer kunnen vrijgeven en aanmelden, alleen indien: o diens BSN ooit door de desbetreffende zorgaanbieder is opgevraagd of geverifieerd bij de SBV-Z, en/of o het WID is gecontroleerd op echtheidskenmerken en gelijkenis met de patiënt/cliënt, waarbij de gebruiker moet worden gewaarschuwd indien: 1. het BSN nog niet is geverifieerd bij het landelijke patiëntenregister, 2. het WID nog niet is gecontroleerd op gelijkenis met de patiënt/cliënt, 3. het WID nog niet is gecontroleerd op echtheidskenmerken,

- 40 -


4. het dossier nog niet inhoudelijk is gecontroleerd met de patiënt/cliënt. waarbij de gebruiker vooraf per gegevenssoort kan aangeven tot hoever terug in het verleden naar relevante patiëntstukken moet worden gezocht. (f) {eis} {toekomst} De gebruiker moet een gegevenssoort kunnen aanmelden zonder dat patiëntstukken van die gegevenssoort zijn vrijgegeven. Bij (gebruiksscenario 1.2.2) afschermen patiëntgegevens gelden de volgende eisen en wensen: (g) {eis} De gebruiker moet vrijgegeven patiëntstukken naderhand weer kunnen afschermen en wel op de volgende aggregatieniveaus: 1. patiëntdossier, 2. patiëntdocument, 3. patiëntgegevensbijdrage, 4. patiëntgegevenselement. (h) {eis} De gebruiker moet in de volgende gevallen patiëntstukken in zijn dossier automatisch kunnen laten afschermen: 1. bij het herroepen van patiëntstukken, 2. bij het overdragen van patiëntstukken aan een andere zorgaanbieder. (i) {eis} Bij het afschermen of verwijderen van een patiëntstuk moet de gebruiker erop kunnen vertrouwen dat: 1. het patiëntstuk niet meer beschikbaar is voor opvraag, ook niet in noodsituaties, 2. indien er voor de onderhavige patiënt/cliënt verder géén vrijgegeven patiëntstukken meer zijn met deze gegevenssoort, de gegevenssoort van het patiëntstuk wordt afgemeld bij de verwijsindex, zoals voorgeschreven per zorgtoepassing, waarbij de gebruiker vooraf om bevestiging wordt gevraagd, 3. indien dit vrijgegeven patiëntstuk het meest actuele met die gegevenssoort was, de gegevenssoort opnieuw wordt aangemeld bij de verwijsindex, maar dan met de actualiteit van het meest actuele nog vrijgegeven patiëntstuk met deze gegevenssoort. (j) {eis} {toekomst} Een zorgverlener moet bij vermoede onjuistheden in de verwijsindex, al zijn vermeldingen in de verwijsindex op commando, per patiënt kunnen laten bijwerken (synchroniseren). Voor beide gebruiksscenario’s geldt: (k) {eis} De gebruiker moet bij het aanmelden of afmelden van patiëntgegevens. 1. worden gewaarschuwd indien de verwijsindex niet bereikbaar is, 2. de aanmeldingen en afmeldingen automatisch laten bewaren voor latere afhandeling, 3. bij de eerstvolgende keer inloggenalle klaarstaande aanmeldingen en afmeldingen alsnog automatisch laten afhandelen, 4. worden geïnformeerd of alles met succes is afgehandeld.


- 41 –

Voor al deze gebruiksscenario’s is het nodig dat de gebruiker landelijk heeft ingelogd als zorgverlener of gemandateerde medewerker op vertrouwensniveau midden (dus met UZI-pas, zie gebruiksscenario 0.2.1).

- 42 -


4.7 Initieel koppelen Patiëntgegevens Een zorgverlener moet bij de invoering van het landelijke patiëntnummer (BSN) zijn patiëntdossier’s opschonen door alle patiëntgegevens te koppelen aan het juiste BSN. Dit kan een zorgverlener druppelsgewijs of bestandsgewijs doen. Deze paragraaf is alleen van toepassing indien een zorgverlener kiest voor bestandgewijs koppelen. Zie verder [Spec Basisinfra] paragraaf 4.2.8. In dat document zijn de volgende gebruiksscenario’s onderkend: •

Gebruiksscenario 1.4.1: voorlopig koppelen patiëntgegevens aan BSN,

•

Gebruiksscenario 1.4.2: definitief koppelen patiëntgegevens aan BSN.

Bij (gebruiksscenario 1.4.1) voorlopig koppelen gelden de volgende eisen: (a) {wens} De gebruiker moet van de patiënten/cliënten in de eigen patiëntdossier’s het interne patiëntnummer en andere identificerende gegevens, kunnen overnemen 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) {wens} De gebruiker moet het conversiebestand kunnen opsturen naar de SBV-Z. (c) {wens} De gebruiker moet het resultaatbestand kunnen ontvangen van de SBV-Z. (d) {wens} De gebruiker moet vanuit het resultaatbestand de toegevoegde BSN’s met de eventueel afwijkende attributen in één keer kunnen overnemen naar het eigen patiëntdossier, waarbij automatisch wordt vastgelegd: 1. de bron van het BSN (SBV-Z), 2. datum en tijd van koppelen, 3. zorgaanbiedernummer van de gebruiker. (e) {wens} De gebruiker moet de onderstaande situaties handmatig kunnen langslopen, zonodig corrigeren en/of zonodig ontkoppelen van het BSN: 1. patiënten voor wie afwijkende attributen waren gevonden, 2. patiënten met verschillende interne patiëntnummers die aan éénzelfde BSN waren gekoppeld, 3. patiënten voor wie het eventueel aanwezige BSN onjuist blijkt te zijn, 4. patiënten die helemaal niet gekoppeld konden worden. (f) {wens} De gebruiker moet tenslotte worden geleid naar gebruiksscenario 1.2.1 vrijgeven patiëntgegevens om reeds vastgelegde patiëntgegevens met terugwerkende kracht beschikbaar te stellen voor opvraag door andere zorgverleners.


- 43 –

Bij (gebruiksscenario 1.4.2) definitief koppelen gelden dezelfde eisen en wensen als voor gebruikscenario 0.3 selecteren patiënt/cliënt. Voor al deze gebruiksscenario’s is het nodig dat de gebruiker lokaal heeft ingelogd als zorgverlener of medewerker op vertrouwensniveau laag of midden (dus met gebruikersnaam/wachtwoord of UZI-pas, zie gebruiksscenario 0.2.1).

- 44 -


4.8 Opvragen Patiëntgegevens Een zorgverlener moet landelijk patiëntgegevens kunnen opvragen. Als hij niet precies weet welke patiëntgegevens hij nodig heeft, kan hij eerst een overzicht opvragen van beschikbare gegevenssoorten zoals vermeld in de verwijsindex. Zie verder [Spec Basisinfra] paragraaf 4.2.9 en paragraaf 4.4.5. In dat document zijn de volgende gebruiksscenario’s onderkend: •

Gebruiksscenario 2.1.1: opvragen index van beschikbare patiëntstukken,

•

Gebruiksscenario 2.1.2: opvragen inhoudelijke patiëntstukken,

Bij (gebruiksscenario 2.1.1) opvragen index gelden de volgende eisen en wensen: (a) {eis} De gebruiker moet, uitgaande van een geselecteerde patiënt/cliënt (zie gebruiksscenario 0.3.1) een totaaloverzicht van alle beschikbare gegevenssoorten gepresenteerd krijgen, met daarin de volgende attributen per indexregel, voorzover aanwezig in de verwijsindex: o identiteit van de verantwoordelijke zorgaanbieder (URA of naam), 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) {wens} De gebruiker moet de presentatie van indexregels kunnen doseren, bijv. door steeds de volgende 20 items te laten presenteren, (c) {wens} De gebruiker moet de presentatie van indexregels kunnen sorteren, bijv. door ze in oplopende of aflopende volgorde van een bepaald attribuut te zetten. (d) {wens} De gebruiker moet door eenvoudig aanklikken van een indexregel een overzicht van alle patiëntstukken voor die gegevenssoort gepresenteerd krijgen, zie gebruiksscenario 2.1.2. (e) {wens} De gebruiker moet binnen 2 seconden na opvraag de index gepresenteerd krijgen. (f) {eis} {toekomst} De toezichthouder wil de situatie voor een willekeurige datum in het verleden kunnen reconstrueren. Hierbij is de bovengenoemde responstijd niet van toepassing. Bij (gebruiksscenario 2.1.2) opvragen patiëntstukken gelden de volgende eisen en wensen: (g) {wens} De gebruiker moet desgewenst kunnen selecteren wèlke patiëntstukken opgevraagd worden, aan de hand van één of meer van de volgende kenmerken/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,


- 45 –

o o o

tot welke episode de gegevens behoren, op welke tijdsperiode de gegevens slaan, eventueel nog specifieke criteria, afhankelijk van de gegevenssoort,

(h) {eis} De zorgverlener moet kunnen verklaren waarvoor hij de patiëntstukken nodig 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) {wens} De gebruiker moet de presentatie van patiëntstukken, afhankelijk van de omvang, kunnen doseren, bijv. door steeds de volgende 20 items te laten presenteren. (j) {wens} De gebruiker moet de presentatie van patiëntstukken uit verschillende patiëntdossiers kunnen sorteren, door patiëntgegevens op volgorde van bepaalde kenmerken te zetten. (k) {eis} De gebruiker moet de opgeleverde patiëntstukken na uitlezen geheel of gedeeltelijk kunnen opnemen in het eigen patiëntdossier, aangemerkt als kopie, en anders wissen. (l) {eis} De gebruiker moet als volgt gewaarschuwd worden indien niet alle patiëntstukken konden worden gepresenteerd: Nr

Reden

Melding

1

Opleverende GBZ is tijdelijk niet beschikbaar of bereikbaar (bijv. storing)

2

Zorgverlener heeft in overleg met patiënt het gehele dossier niet aangemeld Zorgverlener heeft in overleg met patiënt enkele gegevens afgeschermd {toekomst} Zorgverlener kan gegevens niet elektronisch beschikbaar stellen, maar vond ze wel belangrijk om aan te melden

“Een of meer dossiers zijn tijdelijk niet bereikbaar, probeer het later nog eens“ Geen, of zie melding 6

3 4

Geen, of zie melding 6 “Enkele gegevens zijn niet elektronisch beschikbaar, neem contact op met de zorgaanbieder(s)”

(m) {eis} De gebruiker moet als volgt gewaarschuwd worden indien helemaal geen patiëntstukken konden worden gepresenteerd: Nr Reden 5 De ZIM is tijdelijk niet beschikbaar of bereikbaar

Melding “Het landelijke schakelpunt is tijdelijk niet bereikbaar, probeer het later nog eens”

6

Er zijn überhaupt geen gegevens

7

Opvragende zorgverlener is op grond van zijn functie niet geautoriseerd (volgens

“Er zijn geen gegevens beschikbaar” “U bent niet geautoriseerd voor deze gegevenssoort”

- 46 -


autorisatieprotocol) Patiënt heeft alle opvragende zorgverleners met dezelfde functie uitgesloten, behalve in noodsituatie (volgens autorisatieprofiel) 9 Patiënt heeft alle opvragende zorgverleners met een dezelfde functie geheel uitgesloten (volgens autorisatieprofiel) 10 Patiënt heeft deze ene opvragende zorgverlener uitgesloten, behalve in noodsituatie (volgens autorisatieprofiel) 11 Patiënt heeft deze ene opvragende zorgverlener geheel uitgesloten (volgens autorisatieprofiel) 12 Patiënt heeft principieel bezwaar tegen elektronische uitwisseling van zijn gegevens (volgens autorisatieprofiel) 8

“U heeft geen toegang tot deze gegevens, behalve in noodsituatie” “U heeft geen toegang tot deze gegevens” “U heeft geen toegang tot deze gegevens, behalve in noodsituatie” “Patiënt stelt geen gegevens beschikbaar” “Patiënt stelt geen gegevens beschikbaar”

(n) {wens} De gebruiker moet binnen 5 seconden na opvraag de patiëntstukken gepresenteerd krijgen. (o) {eis} {toekomst} De toezichthouder wil de situatie voor een willekeurige datum in het verleden kunnen reconstrueren. Hierbij is de bovengenoemde responstijd niet van toepassing. Bij (gebruiksscenario 2.1.3) opvragen multimediale patiëntstukken gelden de volgende eisen en wensen: (p) {eis} {toekomst} Een gebruiker moet de multimediale patiëntstukken kunnen opvragen door eenvoudig aanklikken vanuit (gebruiksscenario 2.1.2). (q) {wens} {toekomst} De gebruiker moet binnen 10 seconden na opvraag de multimediale patiëntstukken gepresenteerd krijgen. (r) {eis} {toekomst} De toezichthouder wil de situatie voor een willekeurige datum in het verleden kunnen reconstrueren. Hierbij is de bovengenoemde responstijd niet van toepassing. Voor al deze gebruiksscenario’s geldt: (s) {eis} De gebruiker mag voor een patiënt/cliënt landelijk patiëntgegevens opvragen, alleen indien: waarbij de zorgverlener moet worden gewaarschuwd indien: 1. het BSN nog niet is geverifieerd bij het landelijke patiëntenregister, 2. het WID nog niet is gecontroleerd op gelijkenis met de patiënt/cliënt, 3. het WID nog niet is gecontroleerd op echtheidskenmerken, 4. het dossier nog niet inhoudelijk is gecontroleerd met de patiënt/cliënt. (t) {eis} De gebruiker mag alleen gepresenteerd krijgen: 1. indexregels die verwijzen naar patiëntstukken waarvoor hij geautoriseerd is, 2. patiëntstukken waarvoor hij geautoriseerd is,


- 47 –

waarbij geen reden wordt opgegeven indien niet alle gepresenteerde stukken compleet waren. Voor al deze gebruiksscenario’s is het nodig dat de gebruiker landelijk heeft ingelogd als zorgverlener of gemandateerde medewerker op vertrouwensniveau midden (dus met UZI-pas, zie gebruiksscenario 0.2.1).

- 48 -


4.9 Versturen Patiëntgegevens Een zorgverlener moet verschillende soorten patiëntberichten via het landelijk SchakelPunt veilig kunnen versturen naar andere zorgverleners, bijv. medicatievoorschrift, medicatieverstrekking, waarneemretourbericht. Zie verder [Spec Basisinfra] paragraaf 4.2.10 en paragraaf 4.4.8. In dat document zijn de volgende gebruiksscenario’s onderkend: •

Gebruiksscenario 2.2.1: sturen patiëntbericht naar een andere zorgverlener,

•

Gebruiksscenario 2.2.2: ontvangen patiëntbericht van een andere zorgverlener.

•

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: (a) {wens} De gebruiker moet bij het samenstellen van een patiëntbericht het volgende kunnen aangeven: 1. het type patiëntbericht: opdracht, antwoord en melding, 2. 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, 3. of de aflevering van het patiëntbericht in de juiste postbus aan de afzender wel of niet onmiddellijk bevestigd moet worden. (b) {wens} De gebruiker moet bij het samenstellen van een patiëntbericht de inhoud op verschillende manieren kunnen invullen: 1. door het kiezen van een berichtsoort en het handmatig of automatisch invullen van de velden, 2. {toekomst} door het kiezen van een vrij tekstformaat en het handmatig invullen van het bericht, 3. door het bijvoegen van een kopie van een patiëntstuk uit het eigen patiëntdossier, 4. {toekomst} door het aangeven van de identificatie van een patiëntstuk uit het eigen patiëntdossier. (c) {eis} De gebruiker moet bij het samenstellen van een patiëntbericht de bestemming op verschillende manieren kunnen aangeven: 1. door de afzender van een ander patiëntbericht automatisch over te nemen als bestemming, 2. door één of meer zorgaanbieders te selecteren uit de zorgaanbiedergids, zie paragraaf 4.4, of eventueel uit een eigen zorgaanbiederadresboek, 3. door rechtstreeks het HL7-adres als applicatie-id in te voeren. (d) {eis} De gebruiker moet bij het verzenden van een patiëntbericht: 1. worden gewaarschuwd indien het schakelpunt of de postbus van de bestemde zorgaanbieder niet bereikbaar is, 2. ervoor kunnen kiezen om het patiëntbericht te bewaren voor latere verzending,


- 49 –

3. bij de eerstvolgende keer inloggen erop worden geattendeerd dat er patiëntberichten klaarstaan voor verzending, 4. alle klaarstaande patiëntberichten alsnog kunnen verzenden. (e) {eis} De gebruiker moet, indien het samenstellen, adresseren en verzenden van een patiëntbericht automatisch plaatsvindt, de mogelijkheid hebben om: 1. de inhoud of strekking van het patiëntbericht te beoordelen, 2. de verzending van het patiëntbericht te continueren of te stoppen. Bij (gebruiksscenario 2.2.2) ontvangen patiëntbericht gelden de volgende eisen: (f) {wens} De gebruiker moet na het ontvangen van een patiëntbericht de inhoud op de volgende manieren kunnen ontsluiten: 1. door het selecteren van het bijgevoegde patiëntstuk, 2. {toekomst} door het selecteren van de identificatie van een patiëntstuk genoemd in het patiëntbericht en het opvragen daarvan uit het patiëntdossier van de afzender. (g) {wens} De gebruiker moet na het ontsluiten van de inhoud van patiëntgegevens in een patiëntbericht, deze op de volgende manieren kunnen afhandelen: 1. door het uitlezen daarvan door de zorgverlener, 2. door het automatisch uitlezen daarvan door een GBZ-applicatie, 3. door het opnemen daarvan in het eigen patiëntdossier, aangemerkt als kopie, 4. door het wissen ervan. (h) {wens} De gebruiker moet na het ontvangen van een patiëntbericht van het type opdracht, een patiëntbericht van het type antwoord kunnen terugsturen en daarbij: 1. automatisch de afzender van het ontvangen patiëntbericht overnemen als bestemming, 2. automatisch de referentie naar de identificatie van het ontvangen patiëntbericht vermelden, 3. automatisch de identificatie van de onderhavige patiënt/cliënt overnemen, 4. aangeven of de opdracht wordt geaccepteerd of afgewezen. Bij (gebruiksscenario 2.2.3) klaarzetten patiëntbericht gelden de volgende eisen en wensen: (i) {wens} {toekomst} De gebruiker moet een patiëntbericht kunnen klaarzetten zonder te versturen, opdat een andere zorgaanbieder het patiëntbericht zelf kan opvragen, waarbij geldt: 1. zonder vermelde bestemming kan iedere geautoriseerde zorgaanbieder het bericht opvragen, 2. met vermelde bestemming kan iedere vermelde, geautoriseerde zorgaanbieder het bericht opvragen. Bij (gebruiksscenario 2.2.4) ophalen patiëntbericht gelden de volgende eisen en wensen: (j) {wens} {toekomst} De gebruiker moet uitgaande van een geselecteerde patiënt/cliënt (zie use case 0.3.1) een totaaloverzicht van alle klaargezette

- 50 -


patiëntberichten gepresenteerd krijgen, met daarin vermeld voor ieder patiëntbericht: 1. zorgaanbieder-functie van die zorgaanbieder, 2. berichtsoorten bij die zorgaanbieder, 3. actualiteit van die berichtsoort bij die zorgaanbieder, 4. indicatie van de beschikbaarheid van die patiëntberichten. (k) {wens} {toekomst} De gebruiker moet, uitgaande van het totaaloverzicht, door eenvoudig 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) {eis} De gebruiker mag voor een patiënt/cliënt diens landelijke patiëntgegevens versturen of klaarzetten, alleen indien: o diens BSN ooit door de desbetreffende zorgaanbieder is opgevraagd of geverifieerd bij de SBV-Z, waarbij de gebruiker moet worden gewaarschuwd indien: 1. het WID nog niet is gecontroleerd op gelijkenis de patiënt/cliënt, 2. het WID nog niet is gecontroleerd op echtheidskenmerken, 3. het dossier nog niet inhoudelijk is gecontroleerd met de patiënt/cliënt. Voor al deze gebruiksscenario’s is het nodig dat de gebruiker lokaal (gebruiksscenario 2.2.2) of landelijk (overige) heeft ingelogd als zorgverlener of gemandateerde medewerker op vertrouwensniveau midden (dus met UZI-pas, zie gebruiksscenario 0.2.1).


- 51 –

4.10Raadplegen toegangslog Een zorgverlener wil kunnen achterhalen welke patiëntgegevens ooit landelijk (of eventueel intern) zijn opgevraagd uit zijn patiëntdossiers of verstuurd vanuit zijn patiëntdossiers, door raadplegen van de lokale toegangslog. Zie verder [Spec Basisinfra] paragraaf 4.2.14. In dat document zijn de volgende gebruiksscenario’s onderkend: •

Gebruiksscenario 4.1: opvragen lijst van zorgaanbieders die landelijk patiëntstukken hebben opgevraagd of verstuurd.

•

Gebruiksscenario 4.2: opvragen inhoud van de patiëntstukken die ooit door een bepaalde zorgaanbieder landelijk zijn opgevraagd of verstuurd.

Bij (gebruiksscenario 4.1) gelden de volgende eisen: (a) {eis} De toegang tot logregels moet als volgt worden beperkt: 1. een logbeheerder mag alle logregels inzien, 2. een zorgverlener mag alle logregels inzien m.b.t. patiëntgegevens waarvoor hij verantwoordelijk is, 3. een patiënt/cliënt mag alle logregels inzien m.b.t. patiëntgegevens over zichzelf. (b) {eis} De gebruiker moet een lijst van logregels kunnen oproepen, die per logregel de volgende attributen kan tonen, voor zover relevant: 1. de identiteit van de patiënt/cliënt (BSN), 2. identiteit (URA) van de andere (opvragende of bestemde) zorgaanbieder 3. de functie en identiteit (UZI-nr) van de andere (opvragende of bestemde) zorgverlener of medewerker, 4. indien relevant: de functie en identiteit (UZI-nr) van de mandaterende zorgverlener, 5. type en volgnummer van de uitgevoerde gebruikersinteractie (tenminste opvragen en versturen patiëntgegevens), 6. het tijdstip van de gebruikersinteractie, 7. de episode waarvoor de gebruikersinteractie is uitgevoerd, 8. de reden waarom de gebruikersinteractie is uitgevoerd, 9. een indicatie of een beroep is gedaan op een noodsituatie, 10. de bericht-id van het ontvangen (opvraag- of bevestig-) bericht, 11. de bericht-id van het verzonden (oplever- of opdracht-) bericht, 12. de patiëntstuk-id’s van de in het verzonden bericht aanwezige patiëntstukken, 13. een indicatie van eventueel opgetreden foutsituaties met betrekking tot het ontvangen en verzenden van de berichten. (c) {eis} De gebruiker moet voor de lijst van logregels kunnen selecteren dat uitsluitend worden getoond: 1. logregels voor een bepaalde patiënt/cliënt, zie gebruiksscenario 0.3, 2. logregels binnen een bepaald tijdvenster, 3. logregels van bepaalde gebruikersinteracties, 4. bepaalde attributen per logregel.

- 52 -


(d) {wens} De gebruiker moet in de lijst van logregels: 1. kunnen bladeren, 2. kunnen bepalen volgens welk attribuut de logregels op volgorde worden gezet, 3. kunnen zoeken naar logregels met een aangegeven waarde voor één of meer van de attributen, 4. een te selecteren deel van de logregels kunnen afdrukken, 5. een te selecteren deel van de logregels kunnen exporteren naar een intelligent analysegereedschap. (e) {eis} De gebruiker moet logregels: 1. tot een instelbare bewaartermijn kunnen raadplegen, 2. na die instelbare bewaartermijn kunnen verwijderen. (f) {wens} De gebruiker moet voor een bepaalde patiënt/cliënt: 1. logregels jonger dan 3 maanden binnen 5 seconden kunnen oproepen, 2. logregels ouder dan 3 maanden binnen 1 uur kunnen oproepen. (g) {eis} De gebruiker moet de zekerheid hebben: 1. dat eenmaal aan de toegangslog toegevoegde logregels niet meer kunnen worden gewijzigd of verwijderd voor het einde van de bewaartermijn, 2. dat eenmaal na de bewaartermijn verwijderde logregels geen onbedoelde sporen nalaten. Bij (gebruiksscenario 4.2) gelden de volgende eisen: (h) {toekomst} {eis} De gebruiker moet op basis van een patiëntstuk-id de inhoud van het patiëntstuk kunnen raadplegen, binnen 1 dag. Voor al deze gebruiksscenario’s is het nodig dat de gebruiker lokaal heeft ingelogd als zorgverlener of gemandateerde medewerker op vertrouwensniveau midden (dus met UZI-pas, zie gebruiksscenario 0.2.1).


- 53 –

4.11Bijhouden mandateringen Een zorgverlener moet kunnen vastleggen in een lokale mandateringstabel welke andere zorgverleners (als medebehandelaar) en/of medewerkers zijn gemandateerd om namens hem landelijk patiëntgegevens uit te wisselen. Zie verder [Spec Basisinfra] paragraaf 4.2.15. In dat document zijn de volgende gebruiksscenario’s onderkend: •

Gebruiksscenario 7.1: bijwerken mandateringen.

•

Gebruiksscenario 7.2: inzien mandateringen.

Bij (gebruiksscenario 7.1) bijwerken mandateringen gelden de volgende eisen: (a) {eis} De gebruiker moet hebben ingelogd als zorgverlener (zie gebruiksscenario 0.2.1). (b) {eis} De gebruiker moet namens hemzelf een nieuwe mandatering kunnen vastleggen door het kiezen van: 1. de UZI-nummer van te mandateren zorgverlener of medewerker, 2. {wens} de bevoegde gebruikersinteractie(s), zie [Spec Basisinfra] paragraaf 5.3.1, 3. een ingangsdatum, 4. eventueel een verloopdatum, en het automatisch overnemen uit de UZI-pas van de gebruiker: 5. het UZI-nummer van de mandaterende zorgverlener, 6. het abonneenummer (URA) van de zorgaanbieder. waarbij zekergesteld wordt dat de mandaterende en gemandateerde tot dezelfde zorgaanbieder behoren. (c) {eis} De gebruiker moet een lijst van alle door hemzelf vastgelegde mandateringen kunnen raadplegen. (d) {eis} De gebruiker moet uitsluitend een door hemzelf vastgelegde mandatering kunnen wijzigen. (e) {eis} De gebruiker moet uitsluitend een door hemzelf vastgelegde mandatering kunnen verwijderen. Bij (gebruiksscenario 7.2) inzien mandateringen gelden de volgende eisen: (f) {eis} De gebruiker moet hebben ingelogd als zorgverlener of medewerker (zie gebruiksscenario 0.2.1). (g) {eis} De gebruiker moet een lijst van alle aan hem toegekende mandateringen kunnen raadplegen. (h) {eis} De gebruiker moet, indien hij door meerdere zorgverleners is gemandateerd, kunnen kiezen namens welke zorgverlener hij patiëntgegevens gaat beheren of uitwisselen.

- 54 -


Voor al deze gebruiksscenario’s is het nodig dat de gebruiker lokaal heeft ingelogd als zorgverlener op vertrouwensniveau midden (dus met UZI-pas, zie gebruiksscenario 0.2.1).


- 55 –

4.12Aan/afsluiten GBZ-applicatie m.b.t. schakelpunt Voordat een zorgverlener/medewerker patiëntgegevens kan uitwisselen, moet zijn beheerder hun GBZ-applicatie met bijbehorend dossier en bijbehorende postbus aansluiten op het schakelpunt. Zie verder [Spec Basisinfra] paragraaf 4.2.1 en paragraaf 4.4.1 In dat document zijn de volgende gebruiksscenario’s onderkend: •

Gebruiksscenario 0.1.1: aansluiten GBZ-applicatie op schakelpunt,

•

Gebruiksscenario 0.1.2: schakelpunt legt verbinding met GBZ-applicatie,

•

Gebruiksscenario 0.1.3: afsluiten GBZ-applicatie van schakelpunt.

Bij (gebruiksscenario 0.1.1) aansluiten op schakelpunt gelden de volgende eisen: (a) {eis} {toekomst} De gebruiker moet voor zijn GBZ-applicatie de volgende stuurparameters kunnen instellen: 1. koppeltoestand: operationeel, uitwijk of test, 2. actiemodus: gereed, actief, onderhoud of storing, (b) {eis} {toekomst} De gebruiker moet zijn GBZ-applicatie kunnen aansluiten op het schakelpunt door: 1. het opzetten van een beveiligde verbinding op basis van het UZIservicescertificaat, 2. en het sturen van een toestandsbericht met de actiemodus actief, Bij (gebruiksscenario 0.1.2) schakelpunt legt verbinding met applicatie gelden de volgende eisen: (c) {eis} De GBZ-applicatie moet na aansluiten op het schakelpunt toestaan dat het schakelpunt een beveiligde verbinding opzet. Bij (gebruiksscenario 0.1.3) afsluiten van schakelpunt gelden de volgende eisen: (d) {eis} {toekomst} De gebruiker moet zijn GBZ-applicatie kunnen afsluiten van het schakelpunt door: 1. het opzetten van een beveiligde verbinding op basis van het UZIservicescertificaat, 2. het sturen van een toestandsbericht met de volgende gegevens: o de nieuwe actiemodus, onderhoud of storing, o reden van afsluiten, o verwachte tijdstip van weer beschikbaar zijn, 3. het afsluiten van de beveiligde verbinding. Voor gebruiksscenario 0.1.1 en 0.1.3 is het nodig dat de gebruiker heeft ingelogd als beheerder.

- 56 -


4.13Beheren GBZ Voordat een GBZ-applicatie kan worden aangesloten op een schakelpunt, moet de beheerder een koppeling met de ZIM configureren. Zie verder [Spec Basisinfra] paragraaf 4.2.16. In dat document zijn de volgende gebruiksscenario’s onderkend: •

Gebruiksscenario 8.1: koppelen van een GBZ aan een ZIM.

•

Gebruiksscenario 8.2: koppelen van een GBZ-applicatie aan een schakelpunt.

Bij (gebruiksscenario 8.1) koppelen GBZ aan ZIM gelden de volgende eisen: (a) {eis} De gebruiker moet de volgende configuratieparameters kunnen instellen voor zijn GBZ: 1. GBZ-id, 2. URI en hostnaam van het GBZ, 3. URI en hostnaam van de operationele ZIM, 4. URI en hostnaam van de test ZIM, 5. {toekomst} URI en hostnaam van de uitwijk ZIM, 6. naam van het GBZ zoals bekend bij de zorgaanbieder, 7. naam van de zorgaanbieder, 8. abonneenummer van de zorgaanbieder in het UZI-register, 9. {wens} E-mailadres van de beheerder, 10. {wens} telefoonnummer van de beheerder. Bij (gebruiksscenario 8.2) koppelen GBZ-applicatie aan schakelpunt gelden de volgende eisen: (b) {eis} De gebruiker moet binnen zijn GBZ verscheidene GBZ-applicaties kunnen toevoegen en verwijderen, en daarvoor de volgende configuratieparameters kunnen instellen per GBZ-applicatie: 1. applicatie-id van de GBZ-applicatie, 2. applicatie-id van het operationele schakelpunt waarop kan worden aangesloten, 3. applicatie-id van het test-schakelpunt waarop kan worden aangesloten, 4. {toekomst} applicatie-id van het uitwijk-schakelpunt waarop kan worden aangesloten, 5. UZI-nr van het UZI-servicescertificaat waarmee het is geassocieerd, 6. {wens} fabrikaat en type van de GBZ-applicatie, 7. naam van de GBZ-applicatie zoals bekend bij de zorgaanbieder, 8. naam van de zorgaanbieder, 9. {wens} E-mailadres van de beheerder, 10. {wens} telefoonnummer van de beheerder, 11. toepassingsrollen die geactiveerd moeten worden, 12. HL7v3-conformancetabel van de GBZ-applicatie, 13. HL7v3-release gebruikt door de GBZ-applicatie. Voor al deze gebruiksscenario’s is het nodig dat de gebruiker heeft ingelogd als beheerder.


- 57 –

4.14Berichtuitwisseling als gevolg van gebruikersfuncties Als gevolg van de eerder gespecificeerde gebruikersfuncties zal een GBZ-applicatie bepaalde berichten moeten sturen naar de ZIM en zonodig retourberichten ontvangen van de ZIM. Zie de onderstaande figuur.

:gebruiker

:XISapplicatie

:ZIMschakelpunt

HL7-bericht

HL7-retourbericht

- 58 -


De onderstaande tabel geeft een overzicht van de berichten die een GBZ-applicatie moet sturen aan de ZIM en vervolgens moet ontvangen van de ZIM, als gevolg van de bovengenoemde gebruiksscenario’s, afhankelijk van de verschillende toepassingsrollen waarop de GBZapplicatie aanspraak maakt. Voor de wijze waarop deze HL7-berichten moeten worden opgebouwd, zie [Spec Basisinfra] paragraaf 5.3. Gebruiksscenario Gebruikersinteractie

Bericht te sturen door een GBZapplicatie aan de ZIM

HL7v3interactie

Retourbericht te ontvangen door een GBZ-applicatie van de ZIM

HL7v3interactie

Toepassingsrol

0.1

aan/afsluiten applicatie

Geen

0.2

in/uitloggen gebruiker

Geen

0.3

selecteren patient/cliënt

Opvragen PatiëntIdentificatie

opvragenPatiëntIdentificatie

opleverenPatiëntIdentificatie

QUPA_IN 101104

alle

0.4

selecteren zorgaanbieder

Opvragen Zorgaanbieders

opvragenZorgverlenerDetails

PRPM_IN opleverenZorgverlenerDetails 306050NL

PRPM_IN 306051NL

EMD-voorschrijver

OpvragenZorginstellingDetails

PRPM_IN 405010

opleverenZorginstellingDetails

PRPM_IN 405110

EMD-voorschrijver

1.1

bijhouden patiëntgegevens

Geen

1.2

publiceren patiëntgegevens

Publiceren MedicatieVoorschriften

aanmeldenGegevens (eerste)

MFMT_IN 002101

bevestiging, indien de GBZapplicatie daarom had gevraagd

MCCI_IN 000002

alle

Publiceren heraanmeldenGegevens MedicatieVerstrekkingen (bijgewerkte)

MFMT_IN 002102


MCCI_IN 000002

alle

Publiceren EerstelijnsDossier

afmeldenGegevens

MFMT_IN 002103


MCCI_IN 000002

alle

1.3

abonneren patiëntgegevens

Geen

1.4

koppelen patiëntgegevens

Geen

2.1

opvragen patiëntgegevens

Opvragen Index

OpvragenIndex

opleverenIndex

QUMT_IN

alle

- 59 –

QUPA_IN 101103

QUMT_IN


Opvragen MedicatieVoorschriften

020010

020020

opvragenMedicatievoorschriften (eerste)

QURX_IN opleverenMedicatievoorschriften 990001NL

QURX_IN 990003NL

EMD-voorschrijver

opvragenMedicatievoorschriften (vervolg)

QUQI_IN 000003

QURX_IN 990003NL

EMD-voorschrijver

QURX_IN opleverenMedicatieverstrekkingen 990011NL

QURX_IN 990013NL

EMD-verstrekker EMD-voorschrijver

QUQI_IN 000003

QURX_IN 990013NL

EMD-verstrekker EMD-voorschrijver

Opvragen opvragenMedicatieverstrekkingen MedicatieVerstrekkingen (eerste) opvragenMedicatieverstrekkingen (vervolg)

opleverenMedicatievoorschriften

opleverenMedicatieverstrekkingen

Opvragen Samenvatting OpvragenSamenvattingVoorDWH DWH

QUPC_IN opleverenSamenvattingVoorDWH 990001NL

QUPC_IN 990002NL

WDH-waarnemer

Opvragen Samenvatting OpvragenSamenvattingVoorSEH SEH

QUPC_IN opleverenSamenvattingVoorSEH 990011NL

QUPC_IN 990012NL

WDH-waarnemer

2.2

versturen patiëntgegevens

Versturen MedicatieVoorschrift

versturenMedicatievoorschrift

PORX_IN bevestiging, indien de GBZ932000NL applicatie daarom had gevraagd

MCCI_IN 000002

EMD-voorschrijver

Versturen MedicatieVerstrekking

versturenMedicatieverstrekking

PORX_IN bevestiging, indien de GBZ924000NL applicatie daarom had gevraagd

MCCI_IN 000002

EMD-verstrekker

Versturen Verslag DWH

versturenVerslagDWH

REPC_IN bevestiging, indien de GBZ990003NL applicatie daarom had gevraagd

MCCI_IN 000002

WDH-waarnemer

Versturen Verslag SEH

versturenVerslagSEH


MCCI_IN 000002

Nader in te vullen

Versturen PatiëntOverdracht

versturenPatiëntOverdracht


MCCI_IN 000002

Nader in te vullen

Versturen Verwijzing

versturenVerwijzing


MCCI_IN 000002

Nader in te vullen

Versturen

versturenBepalingOpdracht

POLB_IN

MCCI_IN

Nader in te vullen

- 60 -

bevestiging, indien de GBZ-


BepalingOpdracht

002121

applicatie daarom had gevraagd

000002


MCCI_IN 000002

Versturen BepalingResultaat

versturenBepalingResultaat

POLB_IN 004410

4

raadplegen toegangslog

geen

7

bijhouden mandateringen

geen

8

beheren GBZ

geen


Nader in te vullen

- 61 –

4.15Berichtuitwisseling t.b.v andere zorgaanbieders Andere zorgaanbieders moeten in staat worden gesteld via de ZIM berichten te sturen naar dit GBZ om patiëntgegevens op te vragen uit een dossier, dan wel af te leveren in een postbus. Zonodig moet de GBZ-applicatie een ontvangen bericht beantwoorden met een retourbericht Zie de onderstaande figuur.

:gebruiker

:XISapplicatie

:ZIMschakelpunt

HL7-bericht HL7-bericht

HL7-retourbericht

Een GBZ-applicatie dient te voorzien in de volgende functies: (a) {eis} Een GBZ-applicatie dient alle HL7v3-berichten van de ZIM te accepteren, conform de geclaimde toepassingsrollen zoals vastgelegd in de configuratietabel van de ZIM bij aansluiting van deze GBZ-applicatie. (b) {eis} Een GBZ-applicatie dient HL7v3-berichten van het type indirect opvragen af te handelen, zoals aangegeven in de onderstaande tabel, waarbij: 1. de opvraag leidt tot het raadplegen van het patiëntdossier van de aangegeven patiënt/cliënt en het zoeken naar alle vrijgegeven patiëntstukken die voldoen aan de opgegeven zoekcriteria, 2. de oplevering van resultaten aan de ZIM wordt gedoseerd, indien daarom was gevraagd, 3. de resultaten worden gegroepeerd tot één oplevering aan de ZIM, indien dat voor de zorgtoepassing is voorgeschreven, (c) {eis} Een GBZ-applicatie dient HL7v3-berichten van het type indirect versturen af te handelen, zoals aangegeven in de onderstaande tabel, waarbij: 1. het bericht onmiddellijk wordt afgeleverd in de postbus van de geadresseerde zorginstelling, zorginstelling-afdeling of zorgverlener, 2. een bevestiging aan de ZIM wordt gestuurd, indien die daarom had gevraagd.


- 62 –

(d) {eis} Een GBZ-applicatie dient elk van de HL7v3-berichten in de onderstaande tabel van de ZIM te beantwoorden met een retourbericht met foutmelding in de volgende gevallen: 1. indien de GBZ-applicatie het type HL7v3-bericht niet ondersteunt, 2. {toekomst} indien de GBZ-applicatie nog bezig is met het afhandelen van een HL7v3-bericht als onderdeel van dezelfde opvraagsessie, 3. {toekomst} indien de GBZ-applicatie het HL7v3-bericht niet kan verwerken wegens capaciteitstekort, 4. indien het bestemde dossier of postbus niet beschikbaar is, 5. indien het bestemde dossier of postbus niet bekend is, 6. indien het bestemde dossier of postbus niet binnen de time-out reageert 7. indien het bestemde dossier of postbus het type HL7v3-bericht niet ondersteunt, Zie verder de foutmeldingen in de “HL7v3 Implementatiegids Infrastructurele Domeinen”.


- 63 –

De onderstaande tabel geeft een overzicht van de berichten die een GBZ-applicatie moet ontvangen van de ZIM en moet beantwoorden aan de ZIM ten behoeve van andere zorgaanbieders, afhankelijk van de verschillende toepassingsrollen waarop de GBZ-applicatie aanspraak maakt. Gebruikersinteractie

Bericht te ontvangen door een GBZ-applicatie van de ZIM

HL7v3interactie

Retourbericht te beantwoorden door een GBZ-applicatie aan de ZIM

HL7v3interactie

Toepassingsrol

indirect versturen Versturen MedicatieVoorschrift

versturenMedicatievoorschrift

PORX_IN 932000NL

bevestiging, indien daarom was gevraagd

MCCI_IN 000002

EMD-verstrekker

Versturen MedicatieVerstrekking

versturenMedicatieverstrekking

PORX_IN 924000NL


MCCI_IN 000002

EMD-voorschrijver

Versturen Verslag DWH

versturenVerslagDWH

REPC_IN 990003NL


MCCI_IN 000002

WDH-dossierhouder

Versturen Verslag SEH

versturenVerslagSEH

REPC_IN 990013NL


MCCI_IN 000002

Nader in te vullen

Versturen PatiëntOverdracht

versturenPatiëntOverdracht

REPC_IN 004411NL


MCCI_IN 000002

Nader in te vullen

Versturen Verwijzing

versturenVerwijzing

REPC_IN 002111NL


MCCI_IN 000002

Nader in te vullen

Versturen BepalingOpdracht

versturenBepalingOpdracht

POLB_IN 002121


MCCI_IN 000002

Nader in te vullen

Versturen BepalingResultaat

versturenBepalingResultaat

POLB_IN 004410


MCCI_IN 000002

Nader in te vullen

opvragenMedicatieVoorschriften (eerste opvraag)

QURX_IN 990001NL

opleverenMedicatieVoorschriften

QURX_IN 990003NL

EMD-voorschrijver

opvragenMedicatieVoorschriften

QUQI_IN

opleverenMedicatieVoorschriften

QURX_IN

EMD-voorschrijver

indirect opvragen Opvragen MedicatieVoorschriften


- 64 –

(vervolg opvraag)

000003

Opvragen opvragenMedicatieVerstrekkingen QURX_IN MedicatieVerstrekkingen (eerste opvraag) 990011NL opvragenMedicatieVerstrekkingen QUQI_IN (vervolg opvraag) 000003

990003NL opleverenMedicatieVerstrekkingen QURX_IN 990013NL

EMD-verstrekker

opleverenMedicatieVerstrekkingen QURX_IN 990013NL

EMD-verstrekker

Opvragen Samenvatting opvragenSamenvattingVoorDWH DWH

QUPC_IN 990001NL

opleverenSamenvattingVoorDWH

QUPC_IN 990002NL

WDH-dossierhouder WDH-waarnemer

Opvragen Samenvatting opvragenSamenvattingVoorSEH SEH

QUPC_IN 990011NL

opleverenSamenvattingVoorSEH

QUPC_IN 990012NL

Nader in te vullen

MCCI_IN 000002

niet

-

alle

foutmelding, indien niet om dit bericht gevraagd was

MCCI_IN 000002

alle

overige bevestiging overige berichten

Voor de wijze waarop deze HL7-berichten moeten worden opgebouwd, zie [Spec Basisinfra] paragraaf 5.3.


- 65 –

4.16Autorisatie Indien een GBZ-applicatie interne uitwisseling van patiëntgegevens tussen zorgverleners met verschillende functies ondersteunt, dient het te voorzien in een vorm van interne autorisatie: (a) {wens} Een GBZ-applicatie moet de toegang tot lokale patiëntgegevens beperken tot zorgverleners en medewerkers die daartoe bevoegd zijn op grond van de WGBO.

4.17Toegangslog Een GBZ-applicatie dient te voldoen aan de onderstaande eisen, zie ook [Spec Basisinfra] paragraaf 4.3.8: (a) {eis} Een GBZ-applicatie moet alle ontvangen HL7v3-opvraagberichten en verzonden HL7v3-opleverberichten van resp. aan andere zorgaanbieders (zie paragraaf 4.15) loggen in de lokale toegangslog, in de vorm van: 1. een logregel, zodanig dat deze gepresenteerd kan worden zoals gespecificeerd in paragraaf 4.10, 2. {toekomst} de berichtinhoud (opgeleverde patiëntstukken). (b) {eis} Een GBZ-applicatie moet alle verstuurde HL7v3-opdrachtberichten en ontvangen HL7v3-bevestigingen als gevolg van gebruikersfuncties (zie paragraaf 4.14) loggen in de lokale toegangslog, in de vorm van: 1. een logregel, zodanig dat deze gepresenteerd kan worden zoals gespecificeerd in paragraaf 4.10, 2. {toekomst} de berichtinhoud (verstuurde patiëntstukken). Indien een GBZ-applicatie interne uitwisseling van patiëntgegevens tussen zorgverleners met verschillende functies ondersteunt, dient het te voorzien in een vorm van interne logging: (c) {wens} Een GBZ-applicatie moet de toegang tot lokale patiëntgegevens door zorgverleners en medewerkers loggen in de lokale toegangslog.

4.18Connectiviteit Een GBZ-applicatie dient te voldoen aan de onderstaande connectiviteitseisen, zie ook [Spec Basisinfra] paragraaf 5.5. (a) {eis} Een GBZ-applicatie dient voor berichtuitwisseling met iedere ZIM de volgende protocolstack te ondersteunen: • HL7v3 • SOAP v1.1 • HTTP v1.1 • SSL v3.0 of TLS v1.0 • TCP • IP v4 (b) {eis} Een GBZ-applicatie moet na het beschikbaar worden voor een bepaalde ZIM (zie paragraaf 4.12):


- 67 –

1. verzoeken van die ZIM voor het opzetten van nieuwe SSL/TLS-sessies honoreren ten behoeve van berichtuitwisseling ten behoeve van andere zorgaanbieders (zie paragraaf 4.15), 2. voor iedere gebruiker die landelijk patiëntgegevens wil uitwisselen, een SSL/TLS-sessie met die ZIM opzetten voor berichtuitwisseling als gevolg van gebruikersfuncties (zie paragraaf 4.14).

4.19Beveiliging Een GBZ-applicatie dient te voldoen aan de onderstaande beveiligingseisen, zie ook [Spec Basisinfra] paragraaf 5.6. (a) {eis} Een GBZ-applicatie dient een SSL/TLS-sessie met de ZIM te weigeren indien voor het SSL-certificaat van de ZIM blijkt dat: 1. de geldigheidstermijn is verlopen of nog niet aangevangen, 2. het niet correct is ondertekend door een CA onder de root van de Staat der Nederlanden, 3. het staat op een geldige lijst van ingetrokken certificaten (CRL) van die CA, 4. na het verlopen van de geldigheid van deze CRL geen nieuwe CRL kan worden opgehaald bij die CA. (b) {eis} Een GBZ-applicatie dient het lokaal inloggen door een gebruiker te weigeren indien voor zijn UZI-pas blijkt dat: 1. de geldigheidstermijn is verlopen of nog niet aangevangen, 2. het niet correct is ondertekend door het UZI-register, 3. het staat op een geldige lijst van ingetrokken certificaten (CRL) van het UZI-register, 4. {toekomst} na het verlopen van de geldigheid van deze CRL geen nieuwe CRL kan worden opgehaald bij het UZI-register . (c) {eis} Een GBZ-applicatie moet bij (a) en (b) proberen: 1. een nieuwe CRL op te halen bij de CA zodra deze gepubliceerd wordt, 2. de systeembeheerder waarschuwen indien de CRL niet correct is ondertekend door de CA, 3. de systeembeheerder waarschuwen indien de CA na 15 minuten opnieuw proberen nog steeds niet bereikbaar is. (d) {eis} Een GBZ-applicatie die dossiers en/of postbussen ontsluit, moet waarborgen dat: •

alle patiëntgegevens in HL7-berichten die namens een zorgverlener worden opgeleverd aan de ZIM ook daadwerkelijk uit diens dossiers afkomstig zijn en door die zorgverlener zijn vrijgegeven,

•

alle patiëntgegevens in HL7-berichten die voor een zorgverlener zijn afgeleverd door de ZIM ook daadwerkelijk terechtkomen in de postbus van die zorgverlener.

(e) {eis} Een GBZ-applicatie die gebruikers in staat stelt landelijk patiëntgegevens uit te wisselen op vertrouwensniveau midden, moet:

- 68 -


1. een gebruiker in staat stellen met zijn UZI-pas landelijk in te loggen door via een SSL/TLS-sessie zich te authenticeren aan de ZIM, 2. een gebruiker in staat stellen met zijn UZI-pas lokaal in te loggen door zich te authenticeren aan de GBZ-applicatie, 3. iedere keer bij het authenticeren die gebruiker vragen de PIN-code van zijn UZI-pas in te toetsen, 4. die gebruiker weigeren indien de PIN-code niet klopt met de UZI-pas, 5. de ingetoetste PIN-code na gebruik steeds onmiddellijk uitwissen. (f) {eis} Een GBZ-applicatie die gebruikers in staat stelt een BSN op te vragen of de zorgaanbiedergids te bevragen op vertrouwensniveau laag, moet: • een gebruiker in staat stellen lokaal in te loggen en zich met het UZIservicescertificaat van de zorgaanbieder te authenticeren aan de ZIM. (g) {eis} Een GBZ-applicatie moet een SSL/TLS-sessie tussen een gebruiker en de ZIM beëindigen (zie [Spec Basisinfra] paragraaf 4.3.13 voor de waarden van de tijdparameters): 1. wanneer de UZI-pas meer dan het tijdsinterval gebruiker-max-kaartuit uit de kaartlezer van diens werkplek is verwijderd, 2. wanneer de gebruiker zijn applicatie gedurende het tijdsinterval gebruiker-max-applicatie-onbruik niet meer heeft gebruikt. (h) {eis} Een GBZ-applicatie moet na afloop van een SSL/TLS-sessie met de ZIM, alle gebruikte geheimen zorgvuldig uitwissen: de master secret van de SSL/TLS-sessie en de daarvan afgeleide tijdelijke sleutels.

4.20Betrouwbaarheid Een GBZ-applicatie dient bij de berichtuitwisseling te voldoen aan de volgende betrouwbaarheidseisen, zie ook [Spec Basisinfra] paragraaf 5.10. (a) {eis} Een GBZ-applicatie moet bij het verzenden van een HL7v3opdracht/opvraag-bericht aan de ZIM: 1. indien het HL7v3-bericht na de GBZ-bevestig/oplever-time-out nog niet beantwoord was, een duplicaat van dat HL7v3-bericht nazenden, 2. dit herhalen tot een maximum van GBZ-opdracht/opvraag-retry aantal pogingen, 3. bij uitblijven van antwoord van de ZIM, melden aan de gebruiker dat de ZIM niet bereikbaar lijkt en de gebruiker het later nog eens kan proberen, 4. ieder nieuw HL7v3-opdracht/opvraag-bericht voorzien van een uniek bericht-id, 5. ieder duplicaat HL7v3-opdracht/opvraag-bericht identiek houden aan het originele bericht. (b) {eis} Een GBZ-applicatie moet bij het ontvangen van een HL7v3opdracht/opvraag-bericht van de ZIM: 1. bepalen aan het bericht-id en de applicatie-id of het om een nieuw of duplicaat HL7v3-bericht gaat,


- 69 –

2. een nieuw HL7v3-opdracht/opvraag-bericht beantwoorden met een HL7v3-bevestig/oplever-bericht, zoals gespecificeerd in paragraaf 6.4, en daarvan het bericht-id tenminste 2 dagen onthouden, 3. een duplicaat HL7v3-opdracht/opvraag-bericht uitsluitend beantwoorden met een duplicaat van het reeds teruggezonden HL7v3-bevestig/oplever-bericht, indien de ZIM-bevestig/oplevertime-out nog niet verstreken is, en anders negeren, 4. ieder nieuw te versturen HL7v3-oplever/bericht-bericht voorzien van een uniek bericht-id, 5. ieder duplicaat HL7v3- oplever/bericht-bericht identiek houden aan het originele bericht. (c) {eis} Een GBZ-applicatie moet bij het opleveren en versturen van een patiëntstuk: 1. ieder origineel patiëntstuk voorzien van een landelijk uniek patiëntstuk-id, 2. ieder kopie van een reeds eerder opgeleverd of verstuurd patiëntstuk voorzien van het originele patiëntstuk-id. Voor de waarden van de tijdparameters, zie [Spec Basisinfra] paragraaf 4.3.13.

4.21Actualiteit Een GBZ-applicatie dient te voldoen aan de volgende eisen inzake actualiteit van patiëntgegevens: (a) {eis} Een GBZ-applicatie dient nieuw vrijgegeven patiëntgegevens binnen onderstaande tijdspanne aan te melden bij de ZIM: 1. binnen 1 kwartier voor een gegevenssoort die nog niet was aangemeld bij de ZIM, 2. binnen 1 dag voor een gegevenssoort die reeds eerder was aangemeld bij de ZIM, waarbij de tijdspanne wordt gemeten vanaf het moment waarop de zorgaanbieder deze patiëntgegevens heeft vrijgegeven. (b) {eis} Een GBZ-applicatie mag geen patiëntgegevens aanmelden indien deze een kopie zijn van patiëntgegevens uit een ander GBZ-applicatie, anders dan tijdens een dossieroverdracht.

- 70 -


5

Implementatie-eisen

Dit hoofdstuk beschrijft normatief de implementatie-eisen waaraan een GBZ moet voldoen. Het gaat hier vooral om de kwaliteiten die een GBZ voortdurend moet kunnen leveren.

5.1 Inleiding Een GBZ van een zorgaanbieder, met de geïmplementeerde GBZ-applicaties, compleet met alle benodigde voorzieningen en koppelingen met andere systemen binnen de zorgaanbieder, moet de volgende kwaliteiten kunnen leveren: • Connectiviteit, • Beveiliging, • Autorisatie en logging, • Beschikbaarheid, • Responstijden, • Capaciteit, • Betrouwbaarheid. De onderstaande figuur toont hoe de kwaliteiten zijn gepositioneerd binnen een GBZ: bericht uitwisseling

Zorgaan bieder

gebruiks functies

XIS applicatie

beheer functies

implementatie kwaliteiten

Het gaat hier om eisen die niet alleen afhangen van de door XIS-leveranciers geleverde XIS-applicaties, maar ook afhangen van: • de hardwareplatformen waarop deze draaien, • de koppelingen met een eventuele communicatieserver, • werkplekken met UZI-paslezers, • overige ICT-voorzieningen als routers, firewalls, etc. In dit hoofdstuk zijn eisen die voortvloeien uit bijv. de WGBO en de NEN 7510 nadrukkelijk niet opgenomen, omdat een zorgaanbieder daaraan sowieso moet voldoen, ook als deze niet aansluit op het LSP.


- 71 –

5.2 Connectiviteit Een GBZ dient te voldoen aan de volgende connectiviteitseisen, zie ook [Spec Basisinfra] paragraaf 5.5: (a) Een GBZ dient via een DCN van een gekwalificeerd ZSP te communiceren met het LSP. (b) Een GBZ moet bereikbaar zijn voor de ZIM via het IP-adres dat door de ZSP is toegekend aan het GBZ en dat is verkregen door DNS-vertaling van de hostnaam van dat GBZ. (c) Een GBZ-applicatie moet HL7v3-berichten van het aangesloten schakelpunt kunnen ontvangen via de applicatie-id die is toegekend door het LSP. (d) Een GBZ dient NTP te gebruiken voor tijdsynchronisatie met de ZIM.

5.3 Beveiliging Een GBZ dient te voldoen aan de volgende beveiligingseisen, zie ook [Spec Basisinfra] paragraaf 5.6: (a) Iedere GBZ-applicatie binnen een GBZ moet zich aan een ZIM kunnen authenticeren met het UZI-servicescertificaat van dat GBZ. (b) Een GBZ dient zijn UZI-servicescertificaat zodanig te beschermen dat dit niet kan worden gekopieerd, gewijzigd of verwijderd, zonder toestemming van de verantwoordelijke zorgaanbieder en kennisgeving aan het LSP. (c) Een GBZ moet zodanig zijn ingericht dat: •

alle UZI-paslezers gekoppeld zijn aan de werkplekken van de gebruikers,

•

de PIN-code die ten behoeve van een UZI-pas wordt ingetoetst op een werkplek, exclusief wordt aangeboden aan de gekoppelde UZIpaslezer,

•

alle patiëntgegevens in HL7-berichten die namens een gebruiker worden verstuurd naar de ZIM ook daadwerkelijk door die gebruiker waren bedoeld voor verzending,

•

alle patiëntgegevens in HL7-berichten die ten behoeve van een gebruiker worden toegestuurd door de ZIM ook daadwerkelijk exclusief aan die gebruiker worden gepresenteerd.

(d) Voor een GBZ moet zijn gedefinieerd:

- 72 -

•

welke landelijke zorgtoepassingen en toepassingsrollen worden ondersteund en gebruikt,

•

hoe de grenzen van het GBZ lopen door de ICT-voorzieningen van de zorgaanbieder,


•

hoe en wanneer patiëntgegevens die grenzen kunnen passeren,

•

hoe wordt gewaarborgd dat patiëntgegevens in de dossiers en postbussen niet kunnen lekken naar onbetrouwbare bestemmingen,

•

hoe wordt gewaarborgd dat patiëntgegevens uit onbetrouwbare bronnen niet kunnen terechtkomen in de dossiers en postbussen,

•

hoe wordt gewaarborgd dat anderen dan bevoegde gebruikers geen fysieke toegang tot (delen van) het GBZ kunnen krijgen.

(e) Als een GBZ-applicatie voor een bepaalde zorgtoepassing is aangesloten op de ZIM, moet die GBZ-applicatie alle patiëntgegevens in het kader van die zorgtoepassing ook daadwerkelijk uitwisselen via de ZIM.

5.4 Beschikbaarheid Een GBZ dient te voldoen aan de volgende beschikbaarheidseisen, zie ook [Spec Basisinfra] paragraaf 5.7: (a) Een GBZ dient 24 uur per dag en 7 dagen per week beschikbaar te zijn voor het afhandelen van berichten vanuit de ZIM, uitgezonderd gepland onderhoud, zie paragraaf 6.5. (b) Kleine storingen in een GBZ mogen niet meer dan gemiddeld 1 keer per maand voorkomen (MTBF) en dienen dan binnen 1 kwartier (MTTR) te zijn opgelost. (c) Grote storingen in een GBZ mogen niet meer dan gemiddeld 2 keer per jaar voorkomen (MTBF) en dienen dan binnen 1 dag (MTTR) te zijn opgelost. (d) Een GBZ dient aantoonbaar te zijn beschermd tegen storingen als gevolg van bijv.: a. stroomuitval, b. brand, c. blikseminslag.


- 73 –

5.5 Responstijden Een GBZ dient te voldoen aan de volgende eisen, zie ook [Spec Basisinfra] paragraaf 5.9: (a) Een GBZ dient voor gebruikersinteracties, na het commando van een gebruiker of een daaropvolgend ontvangst van een bericht van de ZIM, binnen de doorlooptijd vermeld in de onderstaande tabel het aangegeven resultaat te hebben bereikt. Gebruiksscenario commando / bericht van ZIM

Gemiddelde Resultaat doorlooptijd

0.3 selecteren patient/cliënt 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

commando van gebruiker

0,3 sec



0,3 sec



0,3 sec

opdracht verstuurd aan ZIM

bevestiging ontvangen van ZIM

0,3 sec

bevestiging gepresenteerd


0,3 sec



0,3 sec



0,3 sec



0,3 sec



0,3 sec



0,3 sec



0,3 sec



0,3 sec



0,3 sec



0,3 sec


0.4 selecteren zorgaanbieder opzoeken identificatie / bereikbaarh.

1.2 publiceren patiëntgegevens vrijgeven/afschermen gegevens

2.1 opvragen patiëntgegevens opvragen index / gegevens

2.2 versturen patiëntgegevens 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

- 74 -


(b) Een GBZ dient een HL7v3-bericht van het type indirect versturen na ontvangst van de ZIM, en aflevering van de opdracht in de bestemde postbus, te beantwoorden met een HL7v3-bevestiging aan de ZIM binnen de doorlooptijd vermeld in de onderstaande tabel, indien de ZIM daarom gevraagd had. (c) Een GBZ dient een HL7v3-bericht van het type indirect opvragen na ontvangst van de ZIM, te beantwoorden met een HL7v3-oplevering aan de ZIM binnen de doorlooptijd vermeld in de onderstaande tabel. Interactiemechanisme

Gemiddelde doorlooptijd

90% binnen doorlooptijd

1 sec

2 sec

2 sec

4 sec

indirect versturen versturen terugmelden indirect opvragen opvragen opleveren Voor de interactiemechanismen, zie paragraaf 4.15.

5.6 Capaciteit Een GBZ dient te voldoen aan de volgende capaciteitseisen, zie ook [Spec Basisinfra] paragraaf 5.8: (a) Een GBZ dient per gebruikersessie niet meer dan één opvraagbericht tegelijk naar de ZIM te sturen. (b) Een GBZ dient een zodanige capaciteit te hebben voor het beantwoorden van berichten aan de ZIM dat het kan voldoen aan de gestelde responstijden.

5.7 Betrouwbaarheid Een GBZ dient te voldoen aan de volgende betrouwbaarheidseisen, zie ook [Spec Basisinfra] paragraaf 5.10: (a) De tijdklok van een GBZ mag niet meer dan 1 seconde afwijken van de tijdklok van de ZIM.


- 75 –

6

Exploitatie-eisen

Dit hoofdstuk beschrijft normatief de exploitatie-eisen waaraan een GBZ moet voldoen. Het gaat hier vooral om de gebruiks- en beheerprocedures die een GBZ in staat stellen diensten te leveren aan de buitenwereld, zijnde patiënten, het LSP en alle andere daarop aangesloten GBZ’en

6.1 Inleiding Een GBZ als gebruikt en beheerde GBZ-applicaties aan de buitenwereld, zijnde patiënten, het LSP en alle andere daarop aangesloten GBZ’en kunnen leveren: • Toegangslog, • Connectiviteit, • Beveiliging, • Beschikbaarheid, • Betrouwbaarheid, • Actualiteit, • Ondersteuning. De onderstaande figuur toont hoe de gebruiks- en beheerprocedures en de resulterende diensten zijn gepositioneerd binnen een GBZ: verzoeken van toezichthouder

bericht uitwisseling

verzoeken van ZSP en LSP

Zorgaan bieder

zorg diensten Patiënt/cliënt

gebruiks functies Zorgverlener gebruiksprocedures

XIS applicatie implementatie

beheer functies Beheerder beheerprocedures

In dit hoofdstuk zijn eisen die voortvloeien uit bijv. de WGBO en de NEN 7510 nadrukkelijk niet opgenomen, omdat een zorgaanbieder daaraan sowieso moet voldoen, ook als deze niet aansluit op het LSP. In dit hoofdstuk zijn momenteel geen gebruiksprocedures voorgeschreven, hiervoor wordt verwezen naar [EMD-autorisatie] en [WDH-autorisatie].

- 76 -


6.2 Toegangslog Een GBZ moet procedures hebben voor de volgende taken, die aantoonbaar moeten worden nageleefd: (a) Een logbeheerder moet verzoeken van de toezichthouder inwilligen met betrekking tot het raadplegen van de lokale toegangslog.

6.3 Connectiviteit Een GBZ dient te voldoen aan de volgende connectiviteitseisen, zie ook [Spec Basisinfra] paragraaf 5.5: (a) Een GBZ dient IP-koppelingen via een DCN, te hebben geconfigureerd voor: 1. de test-ZIM, 2. de operationele ZIM, 3. {toekomst} de uitwijk-ZIM (indien aanwezig). (b) Een GBZ-applicatie moet een aansluiting met een schakelpunt binnen elk van de bovengenoemde ZIM’s te hebben geconfigureerd. (c) Een GBZ mag de volgende IP-adressen niet intern gebruiken: 1. het IP-adres dat door het LSP is uitgegeven voor het GBZ als geheel, 2. de IP-adressen die zijn gereserveerd voor de ZIM 3. de IP-adressen uit het landelijke IP-nummerplan van het LSP.

6.4 Beveiliging Een GBZ moet procedures hebben voor de volgende taken, die aantoonbaar moeten worden nageleefd, zie ook [Spec Basisinfra] paragraaf 5.6: (a) Een GBZ dient op aanwijzing van het LSP een nieuw stamcertificaat te laden van: 1. de CA die het SSL-certificaat van de ZIM heeft uitgegeven, 2. {toekomst} het UZI-register. (b) De zorgaanbieder verantwoordelijk voor het GBZ moet, conform de voorwaarden van het UZI-register, aanvragen resp. tijdig vernieuwen: • een UZI-servicescertificaat voor het GBZ, • UZI-passen voor de GBZ-gebruikers. (c) Afgedankte GBZ-apparatuur moet worden geschoond van patiëntgegevens. (d) {toekomst} Een GBZ moet binnen een nader te specificeren aantal dagen na het beschikbaar komen van nieuwe patches voor het dichten van beveiligingslekken, deze patches hebben geïnstalleerd.

6.5 Beschikbaarheid Een GBZ moet procedures hebben voor de volgende taken, die aantoonbaar moeten worden nageleefd, zie ook [Spec Basisinfra] paragraaf 5.7:


- 77 –

(a) Gepland onderhoud van een GBZ-applicatie, mag niet meer dan gemiddeld 12 keer per jaar geschieden (MTBF) en dient dan binnen 1 uur (MTTR) te zijn afgerond. (b) Wanneer een GBZ-applicatie door diens beheerder onbeschikbaar wordt gemaakt voor gepland onderhoud, dient de beheerder: •

dit 2 weken van te voren te melden aan de ZIM-beheerders met een inschatting van de tijdsduur van onbeschikbaarheid.

•

dit 1 uur van te voren nog eens te bevestigen aan de ZIM-beheerders met een inschatting van de tijdsduur van onbeschikbaarheid.

(c) Wanneer een GBZ-applicatie door diens beheerder beschikbaar wordt gemaakt, dient het GBZ dit telefonisch of per e-mail te melden aan de ZIMbeheerders of {toekomst} dit per toestandsbericht te melden aan de ZIM, zie paragraaf 4.12 eis (b). (d) Wanneer een GBZ-applicatie ongepland onbeschikbaar raakt en niet binnen 1 kwartier weer beschikbaar wordt, dient de beheerder dit te melden aan de ZIM-beheerders met een inschatting van de tijdsduur van onbeschikbaarheid. (e) Een GBZ dient de wettelijke bewaartermijnen van patiëntgegevens te garanderen. (f) Een GBZ dient van zijn patiëntgegevens een back-up te maken en binnen 1 dag over te brengen naar een plaats die het beschermt tegen beschadiging en onbevoegde inzage.

6.6 Actualiteit Een GBZ moet procedures hebben voor de volgende taken, die aantoonbaar moeten worden nageleefd: (a) Een GBZ-applicatie voor een bepaalde landelijke zorgtoepassing dient alle beschikbare patiëntgegevens jonger dan een nader te bepalen tijdsinterval binnen een nader te bepalen periode na eerste aansluiting op de ZIM te hebben aangemeld bij de ZIM. (b) {toekomst} De GBZ-beheerder moet in de zorgaanbiedergids actueel (laten) houden via welke applicatie-id’s de patiëntdossiers en zorgaanbiederpostbussen bereikbaar zijn. (c) {toekomst} Een GBZ dient binnen een nader te specificeren aantal maanden na het vaststellen van een nieuwe versie van het Programma van Eisen voor een GBZ, te voldoen aan de nieuwe eisen.

- 78 -


6.7 Ondersteuning Een GBZ moet procedures hebben voor de volgende taken, die aantoonbaar moeten worden nageleefd: (a) De beheerder van een GBZ en diens vervangers dienen met telefoonnummers bekend te zijn bij de beheerder van de ZIM, waarbij altijd tenminste één beheerder bereikbaar is en in staat is de nodige beheertaken uit te voeren. (b) De beheerder van een GBZ dient verzoeken van de ZSP en het LSP met betrekking tot het configureren van het GBZ en het aan/afsluiten van GBZapplicaties in te willigen.


- 79 –

7

Voorbeelden van een GBZ

Dit hoofdstuk beschrijft informatief enkele voorbeelden van GBZ'en.

7.1 Inleiding GBZ’en kunnen zeer verschillende gedaanten hebben, afhankelijk van de omvang van de zorginstelling, maar ook afhankelijk van de technologie waarop de XIS gebaseerd is. In deze paragraaf worden enkele typische gevallen besproken, uitgaande van de verschillende soorten XIS: • PC-gebaseerde XIS • Client/server-gebaseerde XIS • Meerdere client/server-gebaseerde XIS’en • ASP-gebaseerde XIS

7.2 PC-gebaseerde XIS In het geval dat een XIS op een enkel PC-plaform draait, kan een GBZ worden gevormd door de XIS-applicatie met de PC. Voorbeeld is een eenvoudige HIS op één werkplek bij een individueel werkende huisarts. Het client-platform moet dan intern worden voorzien van een UZI-servicescertificaat en moet extern worden voorzien van een UZI-paslezer. Een modem of router is nodig voor de verbinding via het DCN met het LSP.

LSP

Zorgaanbieder

PC

Applicatie-id

XIS applicatie Zorg verlener lezer

GBZ

ZIM-platform ZIM applicatie

r/m

Hostnaam / IP-adres

= UZI-servicescertificaat

Zoals de bovenstaande figuur beoogt weer te geven, heeft het GBZ hier: • één hostnaam en IP-adres als eenduidig netwerkadres voor communicatie met de ZIM, • één UZI-servicescertificaat om zich te authenticeren aan de ZIM, • één applicatie-id dat kan worden gebruikt in HL7v3-berichten. Niet weergegeven in de figuur zijn andere (bijv. financieel-administratieve) applicaties die ook op het client-platform draaien, maar geen patiëntgegevens delen met de XIS-applicatie en derhalve niet als onderdeel van het GBZ wordt beschouwd.

- 80 -


7.3 Client/server-gebaseerde XIS Wanneer binnen een zorgaanbieder meerdere zorgverleners en/of medewerkers tegelijkertijd dezelfde XIS-applicatie moeten gebruiken, wordt vaak gekozen voor een client/server-gebaseerde XIS. Daarbij staat op iedere werkplek een client-platform (meestal PC) waarop de XISclient-applicatie draait, en is er een centraal server-platform waarop XIS-serverapplicatie draait. Voorbeeld is een AIS met verschillende werkplekken aan de balie van de apotheek. Een GBZ kan dan worden gevormd door het geheel, waarbij: • de client-platformen extern worden voorzien van een UZI-paslezer, • het server-platform intern wordt voorzien van een UZI-servicescertificaat, • een modem of router wordt geplaatst voor de verbinding met het LSP.

Zorgaanbieder

Client XIS Zorgverlener/ clnt-appl medewerker lezer

Zorgverlener/ medewerker lezer

LSP

Client

Server

Applicatie-id

ZIM-platform

XIS clnt-appl

XIS srvr-appl

r/m

ZIM applicatie

Hostnaam IP-adres

Client XIS clnt-appl Zorgverlener/ medewerker lezer

GBZ

= UZI-servicescertificaat

Zoals de bovenstaande figuur beoogt weer te geven, heeft het GBZ hier weer: • één hostnaam en IP-adres als eenduidig netwerkadres voor communicatie met de ZIM, • één UZI-servicescertificaat om zich te authenticeren aan de ZIM, • één applicatie-id dat kan worden gebruikt in HL7v3-berichten. Bovenstaande sluit niet uit dat binnen de zorgaanbieder heel andere IP-adressen worden gebruikt. Het gebruik van NAT-tabellen in de router kan ervoor zorgen dat het GBZ zich met één IP-adres naar de ZIM manifesteert. Niet weergegeven in de figuur is dat de XIS-server-applicatie kan bestaan uit meerdere schillen (bijv. aparte schillen voor presentatie, verwerking, opslag), die al of niet draaien op aparte server-platformen. Daarentegen is de XIS-client-applicatie veelal zo licht dat deze weinig of geen specifieke applicatielogica bevat.


- 81 –

7.4 Meerdere client/server-gebaseerde XIS’en Wanneer een zorgaanbieder meerdere XIS-applicaties heeft, waarop meerdere zorgverleners en/of medewerkers tegelijkertijd moeten werken, wordt vaak gekozen voor client/server-gebaseerde XIS’en met communicatie-server. Daarbij staat op iedere werkplek een client-platform (meestal PC) waarop meerdere XIS-client-applicaties kunnen draaien, en zijn er enkele centrale server-platformen waarop de verschillende XIS-server-applicaties draaien. Daarbij wordt een communicatie-server gebruikt voor de berichtuitwisseling tussen de verschillende XIS-server-applicaties. Voorbeeld is een ziekenhuis waarbinnen een zorgverlener of medewerker bijvoorbeeld vanaf één werkplek zowel een ZIS als een RIS kan benaderen. Een GBZ kan dan worden gevormd door het geheel, waarbij: • de client-platformen extern worden voorzien van een UZI-paslezer, • het communicatie-server-platform intern wordt voorzien van een UZIservicescertificaat, • een modem of router wordt geplaatst voor de verbinding met het LSP.

Zorgaanbieder Client

Server

XIS clnt-appl

XIS srvr-appl

Client

Server

Server

XIS clnt-appl

XIS srvr-appl

Comm. server

Client

Server

XIS clnt-appl

XIS srvr-appl

Applicatie-id LSP

Zorgverlener/ lezer medewerker

Applicatie-id

Zorgverlener/lezer medewerker

Applicatie-id

ZIM-platform R

ZIM applicatie

Hostnaam IP-adres

Zorgverlener/lezer medewerker

GBZ

= UZI-servicecertificaat

Zoals de bovenstaande figuur beoogt weer te geven, heeft het GBZ hier: • één hostnaam en IP-adres als eenduidig netwerkadres voor communicatie met de ZIM, • één UZI-servicescertificaat om zich te authenticeren aan de ZIM, • meerdere applicatie-id’s opdat binnenkomende HL7v3-berichten door de communicatie-server kunnen worden afgeleverd bij de juiste XIS-applicatie. Niet weergegeven in de figuur is de situatie waarin de communicatie-server optreedt als poortapplicatie, die fungeert als uiteindelijke ontvanger en verzender van alle HL7v3-berichten en HL7v3 vertaalt van/naar andere berichtformaten ten behoeve van de verschillende XIS-applicaties. In dat geval kan worden volstaan

- 82 -


met één applicatie-id, maar wordt de communicatie-server belast met verregaande kennis over de verschillende XIS-applicaties.


- 83 –

7.5 ASP-gebaseerde XIS Wanneer een zorgaanbieder niet zelf een XIS-applicatie wil kopen en beheren, kan hij het gebruik van de XIS-applicatie als dienst inkopen bij een zogenaamde Application Service Provider (ASP). Deze dienstverlener kan zo met beperkte ICTvoorzieningen vele zorgaanbieders tegelijk van dienst zijn. Daarbij kan de zorgaanbieder volstaan met een client-platform (meestal PC) waarop slechts een XIS-client-applicatie draait. In de praktijk is dat vaak een webbrowser of een andere generieke applicatie-client. De specifieke applicatielogica bevindt zich met de patiëntdossiers van de verschillende zorgaanbieders in de XISserver-applicatie, die op één of meer centrale server-platformen draait. Hier moet voor iedere zorgaanbieder een afzonderlijk GBZ worden gevormd, waarbij: • het client-platform bij de zorgaanbieder extern wordt voorzien van een UZIpaslezer, • het server-platform intern wordt voorzien van een UZI-servicescertificaat van die zorgaanbieder, zodanig dat deze wordt gebruikt voor de authenticatie bij de uitwisseling van diens patiëntgegevens met de ZIM. Voorwaarde is dat de XIS-server-applicatie logisch bestaat uit afzonderlijke domeinen per zorgaanbieder waarin diens patiëntdossiers en zorgaanbiederpostbus zich bevinden, zodanig dat andere zorgaanbieders daar niet bij kunnen, anders dan via de ZIM of een vorm van lokale autorisatie. Onder die voorwaarde mogen de patiëntgegevens van de verschillende zorgaanbieders fysiek in één database worden opgeslagen.

Zorgaanbieder PC XIS clnt-appl Zorg verlener lezer

Zorgaanbieder

ASP dienstverlener

Applicatie-id Server

PC Zorg verlener lezer

XIS clnt-appl

Applicatie-id

XIS srvr-appl

Applicatie-id

LSP

Hostnaam GBZ1 GBZ2

IP-adres R

Hostnaam GBZ3 Hostnaam

ZIM-platform ZIM applicatie

Zorgaanbieder PC Zorg verlener lezer

- 84 -

XIS clnt-appl

= UZI-servicecertificaat


De bovenstaande figuur beoogt weer te geven dat: • de grenzen tussen de verschillende GBZ’en virtueel door de XIS-serverapplicatie lopen, zodanig dat er logische partitities per zorgaanbieder ontstaan, • ieder domein een eigen UZI-servicescertificaat heeft om zich te authenticeren aan de ZIM, • ieder domein een eigen applicatie-id heeft opdat binnenkomende HL7v3berichten kunnen worden afgeleverd bij het juiste domein, • ieder GBZ een eigen hostnaam hebben, • alle GBZ’en één IP-adres als netwerkadres delen. De hostnaam moet zijn vermeld op het UZI-servicescertificaat ten behoeve van authenticatie door de ZIM.


- 85 –

PROGRAMMA VAN EISEN VOOR EEN GOED BEHEERD ZORGSYSTEEM (GBZ)

Recommend Documents