HANDBOEK ICT-LEVERANCIERS IN DE ZORG

HANDBOEK ICT-LEVERANCIERS IN DE ZORG - Versie 4.1 -

postad res: Postbu s 262, 2260 AG Leidschend am bezoekadre s: Overgoo 11, 226 6 JZ Leidschend am telefoo n: (070) 317 34 50; fax: (070) 320 74 37; e-mail: info@ nictiz.nl www.nictiz.nl

Status: Datum:

Definitief 11 augustus 2006

Inhoudsopgave 1

Inleiding 1.1 Aanleiding handboek 1.2 Doel handboek 1.3 Doelgroep 1.4 Relatie met andere documenten 1.5 Verschillen ten opzichte van de vorige release 1.6 Opzet en structuur van het handboek

3 3 4 5 5 6 7

2

Rol 2.1 2.2 2.3

8 8 8 8

3

Eisen aan Goed Beheerde Zorgsystemen 3.1 Normatieve referenties t.a.v. GBZ 3.2 Scope GBZ eisen t.b.v. aansluiting LSP voor EMD of WDH 3.3 Informatieve referenties t.a.v. GBZ 3.4 GBZ-voorbeelden in de praktijk 3.5 Implementatiestappen

10 10 10 12 13 14

4

Invoering burgerservicenummer in de zorg 4.1 Het BSN programma 4.2 Het BSN in de zorg 4.3 Het gebruik van BSN in de AORTA-architectuur 4.4 Stappen t.b.v. eerste aansluiting op LSP

15 15 15 17 18

5

Invoering Unieke Zorgverlener Identificatie Pas 5.1 Het UZI-register 5.2 Gebruik van UZI in AORTA-architectuur

20 20 21

6

EMD 6.1 Inleiding 6.2 EMD van Edifact naar HL7v3 6.3 Doelstelling t.b.v. eerste fase EMD 6.4 Migratie scenario’s

23 23 24 25 27

7

WDH 7.1 Inleiding 7.2 WDH van Edifact naar HL7v3 7.3 Doelstelling t.b.v. eerste fase WDH 7.4 Migratie scenario’s

28 28 28 30 31

8

Begeleiding 8.1 Inleiding 8.2 Accountmanagement leveranciers 8.3 Expertteam 8.4 Testfaciliteiten 8.5 AORTA Support & Productcommunicatie

32 32 32 32 33 34

VWS, NICTIZ en CIBG VWS CIBG Nationaal ICT Instituut in de Zorg

Bijlage 1: Overzicht gebruikte documentatie

35

Bijlage 2: EMD Toekomsscenario’s

36

Bijlage 3: Afkortingen- en begrippenlijst

36

Bijlage 4: Overzicht berichtdefinities

37

-2-

Handboek ICT-leveranciers in de zorg v4.1

1

Inleiding

1.1

Aanleiding handboek

Het implementatieprogramma ‘Invoering Elektronisch Medicatie Dossier en Waarneem Dossier voor Huisartsen’ is een samenwerking tussen het Centraal Informatiepunt Beroepen Gezondheidszorg (CIBG), het Ministerie van Volksgezondheid, Welzijn en Sport (VWS) het Nationaal ICT Instituut in de Zorg (NICTIZ) en staat onder regie van de implementatieorganisatie welke door VWS is opgericht. Over de basisinfrastructuur zal uitwisseling van patiëntgegevens tussen zorgaanbieders onderling en tussen zorgaanbieders en zorgverzekeraars op een veilige en effectieve manier kunnen plaatsvinden. Het elektronisch medicatiedossier (EMD) en het elektronisch waarneemdossier voor huisartsen (WDH) vormen de opstap naar een zorgbreed elektronisch patiëntendossier (EPD) en zijn de eerste landelijke toepassingen van de basisinfrastructuur. In 2006 richt de implementatieorganisatie zich met name op de volgende twee aspecten: -

Regie voeren over de realisatie van de basisinfrastructuur; de betrokken partijen adviseren, zorgen voor afstemming tussen de betrokken partijen en bewaken van de samenhang en de voortgang.

-

Aansluiten van een beperkt aantal koploperregio’s op het landelijk schakelpunt.

Hiertoe gaat de aandacht uit naar drie gebieden: 1. Landelijk: Het landelijk schakelpunt (LSP) is van start gegaan op 31 januari 2006 en biedt een operationele omgeving waar goed beheerde zorgsystemen (GBZ’en) mee kunnen testen. 2. Decentraal in het zorgveld: Implementeren van gebruikersomgevingen waardoor zorgaanbieders via het LSP patiëntgegevens met elkaar kunnen delen. Daarbij moeten de betrokken zorgverleners in het bezit komen van een UZI-pas, zodat zij op een veilige en betrouwbare manier hun informatie kunnen delen. Daarnaast moeten de betrokken zorgverleners het BSN invoeren in hun administraties, onder andere om de toegang tot hun dossiers via unieke patiëntidentificatie mogelijk te maken. Het BSN-programma, dat in samenwerking tussen VWS en CIBG wordt uitgevoerd, ondersteunt hierbij. 3. Leveranciers en gebruikers van de informatiesystemen in de zorg: Dienen hun systemen aan te passen, zodat via het LSP gecommuniceerd kan gaan worden. Dit handboek is een leidraad op het laatste gebied, waarbij de focus ligt op de eisen waaraan een GBZ volgens de AORTA-basisinfrastructuur moet voldoen om aan te sluiten op het LSP. Het Handboek voor GBZ in de praktijk is een ander Handboek en bevat een praktisch stappenplan voor zorgaanbieders om tot een GBZ in de praktijk te geraken.


-3-

1.2

Doel handboek

Dit handboek geeft aan welke acties leveranciers van informatiesystemen voor zorgaanbieders moeten nemen om hun systemen aan te kunnen laten sluiten ten behoeve van de toepassing EMD of WDH op het LSP. Daarbij heeft dit handboek tot doel leveranciers inzicht te verschaffen in de huidige en toekomstige eindsituatie. Omdat standaardisatie vooruitloopt op implementatie, is er meer gespecificeerd in de normatieve documentatie dan in eerste instantie gerealiseerd hoeft te worden. Alle eisen voor een GBZ staan gespecificeerd in het document “Programma van Eisen voor een Goed Beheerd Zorgsysteem” (PvE). Dit PvE document is gericht op de gewenste eindsituatie en geldt voor alle landelijke toepassingen. Het handboek geeft precies aan welke eisen voor de EMD of WDH toepassing vooralsnog niet noodzakelijk. Zie bijlage 1 voor een overzicht van de documenten waarnaar verwezen wordt. Er zijn verschillende redenen waarom zaken wel gespecificeerd zijn, maar die in dit handboek nog niet verplicht worden gesteld. •

De eerste reden is dat het functionaliteit betreft die voor de toepassingen in de eerste fase nog niet nodig zijn. In de EMD toepassing wordt bijvoorbeeld de voorschrijfrol in de eerste fase wel gerealiseerd (namelijk via het opvragen van verstrekkingen ten behoeve van medicatiebewaking tijdens het voorschrijven), maar het voorschrift (voorschrijfbericht) zal pas in de tweede fase worden gerealiseerd.

•

Een tweede reden is dat sommige zaken in de AORTA architectuur wel voorzien zijn als toekomstige functionaliteit, maar vooralsnog eerder als wensen worden beschouwd dan als eisen. Zo passen de eisen in het kader van een adequaat registreren van gegevens wel logisch in de architectuur van AORTA, maar vooralsnog worden ze niet afgedwongen. Realiseren van dergelijke eisen is nog niet verplicht, maar wordt wel toegestaan.

•

Een derde reden is dat sommige functies nog niet volledig zijn uitgewerkt (bijvoorbeeld wel in het architectuur- en specificatiedocument, maar nog niet in de specificaties van de daarvoor benodigde berichten). Zo zijn de HL7v3 berichten voor de formele overdracht van patiëntstukken van de ene zorgaanbieder naar de andere wel genoemd, maar nog niet in HL7 gemodelleerd. Deze eisen kunnen nog niet gerealiseerd worden, omdat de berichten er nog niet zijn.

Het handboek heeft als doel aan te geven wat vereist is voor een GBZ om aan te sluiten op het LSP ten behoeve van de eerste fase van het EMD en het WDH. Om vanuit de huidige situatie te komen tot het moment van aansluiten zijn in dit handboek diverse stappen beschreven. Om ook aan de tweede doelstelling van het handboek te beantwoorden zullen informatieve teksten worden toegevoegd. Overal waar dat van toepassing is, zal expliciet worden aangegeven wat informatief is en wat voor wie wanneer normatief is. Waar de normatieve documenten van NICTIZ voor iedereen bedoeld zijn, heeft het handboek een specifieke doelgroep (zie paragraaf 1.3).

-4-


1.3

Doelgroep

Het handboek richt zich op zorgaanbieders en hun ICT-leveranciers die hun producten willen aansluiten op het LSP. Het geeft antwoord op de vraag wat van de leveranciers verwacht wordt die hun product(en) willen aansluiten op de AORTA-infrastructuur ten behoeve van een EMD of WDH toepassing zoals die in eerste instantie van start gaan.

1.4

Relatie met andere documenten

De onderstaande figuur toont de relatie van dit document met andere documenten van de AORTA-infrastructuur, waarbij de pijlen wijzen naar het afgeleide document. De figuur toont onder meer dat dit handboek is afgeleid van het PvE document. Het PvE document specificeert de eisen voor de eindsituatie, het handboek beschrijft aan welke van die eisen voor de eerste fase van EMD en WDH nog niet hoeft te worden voldaan.

A r c h ite c t u u r o n tw e rp B a s is in fr a Z o r g

S p e c ific a t ie B a s is in fr a Z o r g

P ro g ram m a v a n e is e n LSP

P ro g ram m a v a n e is e n G BZ

H L7 im p le m e n t a t ie h a n d le id in g e n

K w a lif ic a tie sch em a ZSP

H andboek IC T le v e r a n c ie r s

Figuur 1: Onderlinge relatie documentatie


-5-

1.5

Verschillen ten opzichte van de vorige release

Onderstaand wordt een overzicht gegeven van de inhoudelijke (niet-redactionele) verschillen in de hoofdstukken ten opzichte van het ‘Handboek ICT-leveranciers in de zorg, versie 4.0’. Hoofdstuk 1 2 3 4 5 6 7 8 Bijlage 1 Bijlage 2 Bijlage 3 Bijlage 4

-6-

Onderwerp Inleiding Betrokken organisaties GBZ BSN UZI-pas EMD WDH Organisatie Documentatie EMD Toekomstscenario’s Afkortingen / begrippen Berichtdefinities

Wijziging Noemen van Handboek GBZ in de praktijk. Geen grote wijzigingen. Tekst over bundelen is aangepast. Geen grote wijzigingen Geen grote wijzigingen Geen grote wijzigingen Geen grote wijzigingen Geen grote wijzigingen Geen grote wijzigingen Vanuit hoofdstuk 6 wordt verwezen naar brondocumentatie. Verwezen wordt naar bron-document. Geen grote wijzigingen


1.6

Opzet en structuur van het handboek

Ten behoeve van de communicatie met het LSP moeten de leveranciers hun systemen op de volgende gebieden aanpassen, zodat het GBZ waar ze onderdeel van uitmaken voldoet aan de eisen van goed beheerde zorgsystemen. Voor de diverse applicaties binnen een GBZ kan dat betekenen dat ze: •

De ’unieke zorgverlener identificatie’-pas hebben geïmplementeerd;

•

Het burgerservicenummer kunnen vastleggen en in de functionaliteit van de systemen kunnen gebruiken;

•

In staat zijn te communiceren conform HL7v3 gebaseerd op het http(s)/SOAP protocol ten behoeve van het elektronisch medicatiedossier en elektronisch waarneemdossier voor huisartsen.

Deze zaken staan niet los van elkaar, zo is als eis bij het GBZ opgenomen dat de UZI-pas moet zijn geïmplementeerd en als eis bij het BSN dat deze opgevraagd of geverifieerd moet zijn voordat er landelijk patiëntgegevens mee uitgewisseld gaan worden. En in de HL7v3 berichten voor de landelijke toepassingen komen UZI en BSN terug. Voor de overzichtelijkheid worden deze zaken in afzonderlijke hoofdstukken behandeld. Daardoor wordt het tevens mogelijk om recht te doen aan de verschillende rollen en verantwoordelijkheden die de betrokken partijen hebben op de onderscheiden zaken. Hoofdstuk 2 beschrijft de rollen van de betrokken partijen. Hoofdstuk 3 verwijst naar de eisen van de architectuur waarin de onderscheiden zaken geïntegreerd zijn. Hierbij worden de eisen die vooralsnog niet noodzakelijk zijn voor de eerste fase van de EMD en WDH toepassing expliciet gemaakt. Hoofdstuk 4 beschrijft de context van BSN en hoofdstuk 5 beschrijft de context van UZI omdat zowel het BSN als het UZI een bredere scope hebben dan dit handboek. Inzicht in deze achtergrond kan verhelderend werken bij het lezen van de documentatie van de verschillende partijen. In beide hoofdstukken zullen de verschillen tussen de positionering van BSN en UZI in het algemeen en het gebruik van deze zaken in de NICTIZ architectuur expliciet worden beschreven. Hoofdstuk 6 adresseert de EMD toepassing en hoofdstuk 7 de WDH toepassing. Deze hoofdstukken verschaffen informatie met betrekking tot de overgang van de huidige berichtenset naar de nieuwe, de acties die ondernomen kunnen worden om de eerste fase van deze toepassingen te realiseren en verwijst voor een nadere uitwerking van deze zaken in de context van de zorgaanbieders naar de migratiescenario’s. Hoofdstuk 8 tenslotte beschrijft de wijze waarop de ondersteuning voor leveranciers georganiseerd is.


-7-

2

Rol VWS, NICTIZ en CIBG

Bij de realisatie van de landelijke basisinfrastructuur AORTA zijn vele partijen betrokken, zoals de koepelorganisaties, zorgaanbieders, ICT-leveranciers, het ministerie van VWS en haar agentschap het CIBG en NICTIZ. In dit hoofdstuk wordt de rol van VWS, CIBG en NICTIZ op hoofdlijnen geschetst.

2.1

VWS

Het Ministerie van Volksgezondheid, Welzijn en Sport heeft het elektronisch patiëntendossier (EPD) op landelijke schaal geagendeerd. De overheid richt zich daarbij vooral op het realiseren van de noodzakelijke randvoorwaarden, zoals een landelijk uniek patiëntnummer, een landelijke betrouwbare identificatie van zorgverleners, en een basisinfrastructuur. Een aantal van de taken die hiervoor uitgevoerd moeten worden zijn belegd bij het CIBG en NICTIZ. Met betrekking tot de eerste toepassingen, elektronisch medicatiedossier (EMD) en waarneemdossier voor huisartsen (WDH) heeft VWS onlangs de regie met betrekking tot de implementatie op zich genomen.

2.2

CIBG

Het CIBG bestaat uit negen verschillende units en is een agentschap van VWS. Tot de belangrijkste taken behoren het registreren van gegevens en het verstrekken van informatie. Iedere unit richt zich hierbij op een specifiek gebied in de zorg. Het CIBG kan daarom worden gezien als een kenniscentrum van de Nederlandse gezondheidszorg. Om de kwaliteit hiervan te waarborgen, zijn de activiteiten van de units aan strikte voorwaarden gebonden. Zo moeten de registratie en informatieverstrekking op basis van wetgeving of op basis van vastgesteld beleid geschieden. Speerpunt bij het CIBG is de ontwikkeling van ICT in de Zorg. Het elektronisch communiceren in het veld van de gezondheidszorg heeft immers de toekomst. Het CIBG levert een belangrijk aandeel bij de realisatie van de implementatie van het EMD en het WDH. Ook voor deze toepassingen is immers het BSN en de UZI-pas nodig. De sectorale berichten voorziening in de zorg (SBV-Z) en het UZI-register houden zich hier mee bezig. Zie verder de hoofdstukken 4 en 5.

2.3

Nationaal ICT Instituut in de Zorg

NICTIZ ondersteunt de totstandkoming van een betere informatievoorziening rondom en voor de patiënt/cliënt met behulp van ICT. In het bestuur en de Raad van Advies van NICTIZ zijn de koepel- en brancheorganisaties in de zorg vertegenwoordigd. De activiteiten van NICTIZ worden gesubsidieerd door het ministerie van VWS. Het uiteindelijke doel van NICTIZ is de ontwikkeling van een landelijk virtueel elektronisch patiëntendossier (EPD). NICTIZ stimuleert het proces hiernaartoe en schept randvoorwaarden, zoals de architectuur en specificaties voor de landelijke basisinfrastructuur in de zorg en specificaties voor toepassingen van het landelijke EPD. Naast het opstellen van deze specificaties heeft NICTIZ opdracht gegeven tot de realisatie en exploitatie van het LSP. Het landelijk schakelpunt (LSP) is een centrale organisatie die zorg draagt voor de noodzakelijke voorzieningen voor het elektronisch uitwisselen van informatie tussen zorginstellingen. Door de noodzakelijke voorzieningen éénmalig te ontwikkelen en onder te brengen in één organisatie ontstaan schaalvoordelen die ten gunste komen van de zorginstellingen. Via een Europese aanbestedingsprocedure heeft NICTIZ de opdracht tot het bouwen van het LSP gegund aan CSC. Dit LSP levert de diensten op basis waarvan zorgpartijen snel en veilig patiëntgegevens kunnen opvragen en uitwisselen op landelijke schaal. Het LSP is sinds 31 januari 2006 operationeel voor de eerste aansluitingen.

-8-


Het LSP levert onder meer de volgende diensten: •

Veilige en betrouwbare communicatie;

•

Toegang tot gegevens via een landelijke verwijsindex;

•

Autorisatie van zorgverleners;

•

Landelijke logging;

•

Verkeersregelaar;

•

Identificatie van patiënten;

•

Identificatie en authenticatie van zorgverleners;

•

Helpdesk voor ZSP’s;

•

Diverse beheerdiensten.

Om de veiligheid van gegevens en systeemprestatie te waarborgen worden eisen gesteld aan zorgaanbieders en hun informatiesystemen, het beheer ervan en de wijze waarop op het LSP wordt aangesloten. Zie verder hoofdstuk 3 voor de positionering van de GBZ-eisen.


-9-

3

Eisen aan Goed Beheerde Zorgsystemen

3.1

Normatieve referenties t.a.v. GBZ

Alle eisen voor een GBZ staan gespecificeerd in het document “Programma van eisen voor een GBZ” (PvE). Dit document verwijst verder naar de andere normatieve documenten voor een GBZ: • Implementatiehandleiding HL7v3 Infrastructurele domeinen; • Implementatiehandleiding HL7v3 Zorg Informatie Makelaar; • Implementatiehandleiding HL7v3 Medicatieberichten (BEMO); • Implementatiehandleiding HL7v3 Gegevensuitwisseling huisartsen (PriCa); • Implementatiegids HL7v3 Web Services Profile. Dit handboek is gesynchroniseerd met de versies van deze documenten zoals opgenomen in bijlage 1. Het PvE document is gericht op de gewenste eindsituatie en geldt voor de landelijke toepassingen. Dit handboek is gericht op de eerste fase van de EMD en WDH toepassing.

3.2

Scope GBZ eisen t.b.v. aansluiting LSP voor EMD of WDH

(normatief) Ter vermijding van redundantie en ter verhoging van de duidelijkheid, zal in het handboek niet een zoveelste opsomming gegeven worden van wat wel moet, maar zal expliciet worden aangegeven welke eisen voor aansluiting ten behoeve van EMD of WDH toepassing in eerste instantie nog niet geïmplementeerd hoeven te worden. Daarbij wordt de verwijzing naar de documenten als volgt gecodeerd: P: Programma van eisen voor een GBZ document (PvE). Vanuit de eisen in het PvE document wordt verwezen naar de verder gedetailleerde implementatiehandleidingen. Vanuit AORTA perspectief zijn de volgende zaken nog niet verplicht voor een GBZ met een rol in de EMD of WDH toepassing op het moment dat het GBZ aansluit op het LSP. Deze zaken hoeven dus niet, maar kunnen ook nog niet gerealiseerd worden, omdat ze niet mogelijk zijn of omdat ze niet door de gehele keten ondersteund worden: •

Alle eisen die in het PvE document voorzien zijn van het etiket {toekomst};

•

Selecteren zorgaanbieder (P4.1.c en P4.4);

•

Berichten die genoemd worden in P4.14 en P4.15 maar niet opgenomen zijn in de lijst met ‘verplichte interacties’ in bijlage 4A van dit handboek.

De volgende eisen zijn optioneel, dat wil zeggen ze zijn niet verplicht maar mogen wel worden geïmplementeerd en de ZIM zal de betreffende functionaliteit ondersteunen indien de ZIM hierin een rol speelt: •

- 10 -

Alle eisen die in het PvE document voorzien zijn van het etiket {wens};


•

Bijhouden patiëntgegevens (P4.1.d en P4.5);

•

Verklaren van reden opvraag (P4.8.h);

•

Manieren om bestemming patiëntbericht aan te geven bij versturen (P4.9.c);

•

Het lokaal inloggen op vertrouwensniveau midden bij gebruiksscenario 2.2.2 (P4.9);

•

De attributen van een logregel vermeld in P4.10.b.7 t/m 9;

•

Beschikbaarheidsmelding gepland onderhoud (P6.5.b t/m d).

Met betrekking tot het bundelen en groeperen (bijlage C in het Specificatiedocument) wordt het volgende verplicht of toegestaan: •

Verplicht, niets anders toegestaan: Het opvragen of verifiëren van BSN aan de ZIM door een GBZ gaat ongebundeld (geen ‘B’ in het query-bericht).

•

Verplicht, niets anders toegestaan: Het opvragen van de index of metagegevens aan de ZIM door een GBZ gaat ongebundeld (geen ‘B’ in het query-bericht).

•

Verplicht: Het opvragen van patiëntgegevens aan de ZIM door een GBZ gaat gebundeld (met een ‘B’ in het query-bericht)

•

Toegestaan: Het opvragen van patiëntgegevens aan de ZIM door een GBZ gaat ongebundeld.

•

Verplicht, niets anders toegestaan: Het opleveren van een GBZ aan de ZIM gaat gegroepeerd (alle antwoorden in één bericht) maar ongebundeld (geen batch-wrapper).

•

Verplicht: Het opvragen en het opleveren van een GBZ aan de ZIM moet zowel gedoseerd als ongedoseerd ondersteund worden conform de specificaties. Voor de WDH toepassing geldt echter dat het doseren nu nog niet verplicht is (maar optioneel).

Ter informatie wordt hieraan toegevoegd dat het LSP de patiëntgegevens vanuit de onderliggende GBZ’en ongebundeld zal opvragen (de eventuele ‘B’ uit het opvraagbericht van een GBZ zal verwijderd worden voordat het bericht doorgestuurd wordt naar de onderliggende GBZ’en). De Implementatiegids Web Services Profile gaat in op verschillende mogelijkheden met betrekking tot synchrone en asynchrone communicatie, deferred en immediate responses. Echter de ZIM ondersteunt vooralsnog alleen synchroon en immediate: die zijn verplicht voor een GBZ en de andere vormen zijn nog niet toegestaan. De Implementatiegids Infrastructurele Domeinen gaat in op de HL7 ping en de HL7 tick, waarmee bepaald kan worden of een applicatie hangt. Deze zijn (nog) niet verplicht en wordt vooralsnog niet toegestaan.


- 11 -

3.3

Informatieve referenties t.a.v. GBZ

Het “Programma van eisen voor een GBZ” is afgeleid van het document dat de architectuur beschrijft en van het document dat de specificaties beschrijft (zie ook figuur 1 in hoofdstuk 1 onder relatie met andere documenten). Voor hen die meer willen weten over de achtergrond van bepaalde eisen, of een illustratie van de invulling daarvan, is het nuttig deze te raadplegen. Het ‘Architectuurontwerp basisinfrastructuur in de zorg’ geeft een overzicht van de landelijke basisinfrastructuur met daarin de benodigde infrastructurele voorzieningen en de daaraan gekoppelde GBZ’en inclusief de onderlinge samenwerking en samenhang. o

Hoofdstuk 5.13 bevat de eisen aan zorgsystemen.

o

In diverse paragrafen van hoofdstuk 6 over de Informatiearchitectuur wordt de functionaliteit beschreven van de aangesloten zorgsystemen.

o

De technische architectuur, zoals beschreven in hoofdstuk 7, gaat in paragraaf 7.6 in op de eisen aan beschikbaarheid, betrouwbaarheid en beveiliging van GBZ’en.

De ‘Specificatie van de basisinfrastructuur in de zorg’ is een uitwerking van het document met de architectuur en beschrijft de totale werking van de basisinfrastructuur, op het niveau van bedrijfsprocessen, informatiesystemen en technologie. Daarnaast specificeert dit document de eisen die gesteld worden aan de verschillende onderdelen van de basisinfrastructuur en de GBZ’en. o

Hoofdstuk 6 bevat de eisen aan een GBZ.

o

Vanuit hoofdstuk 6 wordt verwezen naar specifieke paragrafen van hoofdstuk 4 en 5.

Het ‘Programma van eisen voor een GBZ’ is een document waarin de eisen uit het Specificatie document opgenomen zijn en waarin de procesmatige eisen aan het goede beheer zijn toegevoegd. Het is in feite een op zichzelf staand document waarin alle teksten uit het architectuur document en uit het specificatie document zonder interne verwijzingen, maar als een doorlopende tekst zijn opgenomen. Dit hoofdstuk is voornamelijk gebaseerd op en zal vooral verwijzen naar dit Programma van eisen voor een GBZ.

- 12 -


3.4

GBZ-voorbeelden in de praktijk

(informatief) - GBZ en zorgaanbieder Een systeem dat goed beheerd wordt is als geheel (systeem en beheer) zelf eerder als een organisatie dan als een softwaresysteem op te vatten. Het zorgsysteem kan een samenstelling van apparaten en applicaties zijn, het GBZ is dan op te vatten als een goed beheerd domein binnen de organisatie van een zorgaanbieder of daarmee samenvallend. Het goede beheer staat immers altijd onder verantwoordelijkheid van een zorgaanbieder. De zorgaanbieder (zorginstelling of individuele zorgverlener) heeft bepaalde wettelijke verantwoordelijkheden. In de AORTA-architectuur gaat het dan bijvoorbeeld om het aanvragen en beheren van certificaten (UZI-passen en UZI-servicescertificaat). De eindverantwoordelijkheid voor het goede beheer van een GBZ is bij de zorgaanbieder belegd. -

Positionering GBZ bij zorgaanbieder Een GBZ bestaat uit een of meer applicaties en valt onder de verantwoordelijkheid van één zorgaanbieder. In situaties waarbij zorgaanbieders gebruik maken van één systeem blijft de wettelijke verantwoordelijkheid voor het beheer van de gegevens van één zorgaanbieder onverkort bij die zorgaanbieder. Het (virtueel) scheiden van de patiëntgegevens tussen zorgaanbieders door bijvoorbeeld lokale autorisatie blijft dan ook van kracht. Dat laat onverlet dat zorgaanbieders die binnen de muren van een andere zorgaanbieder opereren keuzes kunnen maken ten aanzien van de positionering van hun GBZ’en ten opzichte van een ‘overkoepelend’ GBZ. Daarbij dient een afweging van de vooren nadelen gemaakt te worden. Twee GBZ’en zou bijvoorbeeld kunnen betekenen twee keer een kwalificatie en twee poorten naar buiten (anderen die iets naar jou willen sturen zien in de zorgaanbiedergids twee zorgaanbieders staan). Wellicht ook twee keer beheer van logging, autorisatie medewerkers, patiëntregistratie etc. Daar moet een zorgvuldige afweging gemaakt worden.

-

GBZ en applicaties Een GBZ bestaat uit applicaties die een rol kunnen vervullen in een zorgtoepassing. Zo kan een GBZ een applicatie bevatten die de rol ‘voorschrijver’ in de toepassing ‘EMD’ vervult. Een dergelijke applicatie dient dan te voldoen aan de algemene eisen (bijvoorbeeld gebruik van BSN) en aan de eisen die specifiek zijn voor de betreffende toepassingsrol (bijvoorbeeld het landelijk opvragen en verwerken van verstrekkingen m.b.v. de gespecificeerde HL7v3 berichten). Het maakt daarbij geen verschil of een applicatie geïnstalleerd is op systemen bij de zorgaanbieder of elders gehost wordt. Wel zullen alle systemen (of devices) die nodig zijn voor communicatie met het LSP of waar overheen gegevens via een ZSP naar of van het LSP gaan, behoren tot het GBZ. Het ligt voor de hand dat een leverancier per applicatie een typegoedkeuring regelt, maar voor het geheel van de implementatie en configuratie van diverse applicaties op diverse platformen van diverse leveranciers zal het beheer goed geregeld moeten zijn door of onder verantwoordelijkheid van een zorgaanbieder.


- 13 -

3.5

Implementatiestappen

Begin 2006 voldoen de meeste informatiesystemen in de gezondheidszorg nog niet aan de geformuleerde eisen. In onderstaande tabel staat een toelichting op de berichtimplementatie die ten behoeve van communicatie met of via het LSP moeten worden uitgevoerd. Zie verder “Implementatiehandleiding HL7v3 Zorg Informatie Makelaar”.

Actie Simultaan bevragingen van de ZIM kunnen afhandelen. Immediate response op queries van de ZIM kunnen geven. opvragen PatiëntIdentificatie (QUPA_IN 101103) ontvangen PatiëntIdentificatie (QUPA_IN 101104) aanmelden Gegevens (eerste MFMT_IN 002101) heraanmelden Gegevens (bijgewerkte MFMT_IN 002102) afmelden Gegevens (MFMT IN 002103) opvragen Index (QUMT IN 020010) opleveren Index (QUMT IN 020020) opvragen Medicatieverstrekkingen (eerste, QURX_IN 990011NL) opleveren Medicatieverstrekkingen (QURX IN 990013NL) opvragen Samenvatting Voor WDH (QUPC IN 990001NL) opleveren Samenvatting Voor WDH (QUPC IN 990002NL) versturenVerslagWDH (REPC IN990003NL) Inbouwen: Aanmaken en verwerken ControlAct wrappers: QUQI_MTxxxxxx en MFMI_MTxxxxxx Inbouwen : aanmaken en verwerken Transmission wrappers : MCCI_MT000xxx Uitbreiden loggingsmogelijkheden conform de specificaties.

- 14 -

Toelichting Volgende opvraagberichten kunnen ontvangen, ook al zijn eerdere berichten nog niet afgehandeld. Geen response binnen time-out betekent voor ZIM opnieuw vragen. ophalen of verifiëren BSN ontvangen BSN incl. overige patiëntgegevens Algemeen bericht voor aanmelden Algemeen bericht voor update aanmelding afmelden van aangemelde gegevens overzicht van aangemelde gegevens opvragen overzicht van aangemelde gegevens ontvangen

Antwoord op opvraging inzage dossier op huisartsenpost opvragen inzage dossier op huisartsenpost ontvangen waarneemretour bericht Zie ‘Implementatiehandleiding HL7v3 Infrastructurele domeinen. Zie ‘Implementatiehandleiding HL7v3 Infrastructurele domeinen. Advies: “Checklist autorisatie en logging regionale samenwerkingsverbanden” in toolkit medicatie- en waarneemdossier. Het opleverende systeem dient in de toekomst ook de inhoud van de verzonden berichten te loggen en daartoe op termijn de opslagcapaciteit aan te passen.


4

Invoering burgerservicenummer in de zorg

Omdat het burgerservicenummer (BSN) niet alleen in de NICTIZ architectuur gebruikt gaat worden, is de landelijke context van het BSN breder dan de focus van NICTIZ. In deze paragraaf wordt verwezen naar de bredere context, naar instanties die daarvoor verantwoordelijk zijn en naar documentatie waarin die context beschreven wordt. In de volgende paragraaf zal ingegaan worden op de wijze waarop NICTIZ gebruik maakt van het BSN in de zorg.

4.1

Het BSN programma

Het BSN is een verbeterde toepassing van het sofi-nummer, numeriek hetzelfde, maar met meer gebruiksmogelijkheden dan alleen sociaal-fiscale zaken. Het BSN zal bijvoorbeeld ook gebruikt worden in het onderwijs, door de Rijksdienst voor het Wegverkeer en voor de huurtoeslag (voorheen huursubsidie). Het BSN is een uniek identificerend persoonsnummer dat iedereen krijgt, die ingeschreven staat in de Gemeentelijke Basisadministratie Persoonsgegevens (GBA). Het gebruik van het BSN tussen gemeentes en binnen de overheid wordt geregeld in het programma BSN. Het beheer van het BSN is belegd bij de Beheervoorziening BSN (BVBSN) onder verantwoordelijkheid van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties. Voor meer informatie over het BSN zie: http://www.programmabsn.nl/ Hier staat een uitleg over wat BSN is. Ook wordt de voorgeschiedenis en de organisatie van het programma BSN beschreven en de rol van het ICTU daarin. Onder projecten wordt ingegaan op:

1. inrichten van de Beheervoorziening BSN (BVBSN);

2. realiseren en aanpassen van weten regelgeving omtrent het gebruik en het beheer van het BSN; op hoofdlijnen geregeld in de Wet algemene bepalingen bsn (Wabb); 3. Wet gebruik BSN in de Zorg (WGBZ); 4. inrichten van de Nationale Vertrouwensfunctie (NVF); 5. implementeren van het BSN. Documentatie over het BSN, over de wet Wabb, factsheets over o.a. het Register nietingezetenen, en de laatste stand van zaken is eveneens te raadplegen via: http://www.programmabsn.nl/.

4.2

Het BSN in de zorg

Het gebruik van het BSN in de zorg vereist aparte of aanvullende regulering, al was het maar omdat in de zorg een BSN gekoppeld kan worden met gegevens van patiënten. Het identificerend stelsel voor de zorg is door VWS belegd bij het CIBG. Omdat er niet gekozen is voor een apart nummer in de zorg, is het voldoende wanneer het CIBG een ‘toegangspoort’ realiseert voor de sector zorg naar de algemene beheervoorziening BSN. Deze toegangspoort is de sectorale berichten voorziening in de zorg (SBV-Z). Voor meer informatie over het BSN in de zorg zie: www.minvws.nl/dossiers/burgerservicenummer en www.sbv-ztest.nl Hier staan de organisatie en diensten van de SBV-Z uitgelegd. Onder organisatie zijn de achtergronden en doelgroepen van het BSN in de zorg te vinden. Ook de weten regelgeving die het gebruik van het BSN in de zorg regelt wordt hier genoemd. Het gaat dan vooral om de Wet gebruik BSN in de zorg (WGBZ). Omdat de SBV-Z als ‘bewerker’ van gegevens optreedt zoals bedoeld in de Wet Bescherming Persoonsgegevens (WBP) wordt naar het WBP verwezen.


- 15 -

Onder Diensten wordt de toegangspoort functioneel en technisch beschreven. Het gaat daarbij om de wijze waarop een BSN via de SBV-Z opgevraagd of geverifieerd kan worden. Onder Hulpmiddelen worden de beschikbare tools van de SBV-Z besproken. Te downloaden zijn o.a.: technische specificaties om BSN’s mee op te vragen en handleidingen waarin zoekpaden beschreven zijn om met een zo groot mogelijke kans een BSN terug te krijgen. Ook overwegingen bij bijvoorbeeld het gebruik van voorletters bij het opvragen van een BSN worden in deze handleiding beschreven. De SBV-Z heeft verschillende toegangen gespecificeerd om een BSN op te vragen of te verifiëren. Zo kunnen zorgaanbieders een groot bestand aanleveren (batchgewijs opvragen en verifiëren). Zorgaanbieders kunnen ook per patiënt een opvraag doen en dat kan via een SBV-Z XML bericht of via een HL7v3 bericht (ook XML maar dan conform de HL7v3 modellering). SBV-Z biedt diensten aan via een website of via een webservice (zie onderstaande tabel). Onder het tabblad ‘technische specificaties’ (onder de Hulpmiddelen) zijn de diverse interface-specificaties te downloaden. Voor ICT-leveranciers is het van belang onderscheid te maken tussen de communicatie XIS met SBV-Z enerzijds en de communicatie XIS met LSP anderzijds. De specificatie LSP met SBV-Z is voor ICT-leveranciers niet direct relevant. De condities van de diverse toegangen en de test-mogelijkheden worden in onderstaande tabel weergegeven: Beveiligde diensten:

Website Webservice Berichttype Grootte Restricties Zoekpad

Testtool enkelvoudige vraag

Nvt

Ja

SBV-Z XML en HL7v3

Nvt

Nvt

Auto

Testtool meervoudige vraag

Ja

Nvt

SBV-Z XML

max 1MB

Nvt

Auto

Initieel meervoudige vraag

Ja

Nvt

SBV-Z XML

max. 50MB

Afspraak, Auto max 3x per UZI-nr

Structureel enkelvoudige vraag

Ja

Ja

SBV-Z XML en HL7v3

Nvt

Nvt

website: 1 of 2 webservice: auto

Structureel meervoudige vraag

Ja

Nvt

SBV-Z XML

10MB

Nvt

Auto

Wat betreft de implementatie van het BSN in de zorg zijn er een tweetal handboeken geschreven: een algemeen handboek en een handboek specifiek voor koplopers. In het handboek BSN voor koplopers worden de stappen beschreven voor een zorgaanbieder om BSN initieel in systemen geïntegreerd te krijgen. Ook de wettelijke voorwaarden waaronder het BSN gebruikt mag worden, de controle op basis van een Wettelijke Identiteit (WID) en de interpretatie van het wetsvoorstel worden hierin beschreven. De laatste versie hiervan is te downloaden via: www.invoering-epd.nl. Wellicht ten overvloede: de BSN-handboeken zijn primair gericht op zorgaanbieders. NICTIZ heeft de proces eisen hieruit vertaald naar ICT eisen en opgenomen in het PvE (hoofdstuk 4.3).

- 16 -


4.3

Het gebruik van BSN in de AORTA-architectuur

Alle communicatie in de zorg zal vanaf de invoering van de betreffende wetgeving (WABB en WGBZ) een BSN moeten bevatten. Ook de landelijke uitwisseling van gegevens zoals die conform de NICTIZ specificaties gerealiseerd wordt zal het BSN bevatten. In de AORTAarchitectuur wordt nauwkeurig gespecificeerd hoe de bevoegdheden van deze uitwisseling gerealiseerd en geborgd wordt en daarin is het BSN integraal opgenomen. Tot aan de invoering kunnen zorgaanbieders in het koploperprogramma ministeriële toestemming krijgen om het sofi-nummer te gebruiken. Voor het opvragen of verifiëren van BSN kan initieel buiten het LSP om de SBV-Z benaderd worden. Een GBZ kan een BSN ook via het LSP opvragen of verifiëren. In dat geval dient het HL7v3 bericht gebruikt te worden. Het voordeel van opvragen via het LSP voor leveranciers is dat er geen additionele toegangen geïmplementeerd hoeven te worden. Een voordeel voor het communicatie proces is dat de logging van deze interacties landelijk plaatsvindt. In het ‘Programma van Eisen voor GBZ’ wordt aangegeven (hoofdstuk 4.3 en 4.7) hoe het voorlopig en het definitief koppelen van BSN gerealiseerd kan worden via het LSP (die de ook de communicatie met het SBV-Z verzorgt) en welke checks gedaan moeten worden voordat de interacties toegestaan zijn die NICTIZ gespecificeerd heeft (bijvoorbeeld aanmelden of opvragen van gegevens). Appendix A van ‘Specificatie van de basisinfrastructuur in de zorg’ is volledig gewijd aan de invoering van het burgerservicenummer. In de implementatiehandleidingen wordt gespecificeerd op welke wijze het BSN in de diverse HL7v3 berichten opgenomen dient te worden. In de onderstaande matrix is aangegeven welke interacties door een GBZ ondersteund moeten worden indien een BSN bijvoorbeeld wel aanwezig, maar niet geverifieerd is, of wel geverifieerd is maar niet WID-gecontroleerd. In het onderstaande overzicht zijn de mogelijkheden op hoofdlijnen gerangschikt. Het blijft de verantwoordelijkheid van de zorgverlener om te bepalen onder welke voorwaarden gebruik gemaakt wordt van deze mogelijkheden. Onder SBV-Z verificatie wordt verstaan: door de zorgaanbieder al dan niet via het LSP opgevraagd of geverifieerd bij het SBV-Z. Onder WID controle wordt verstaan de controle van de gelijkenis WID met patiënt en controle op echtheidskenmerken. WID controle uitgevoerd Raadplegen LSP toegestaan

Raadplegen van LSP toegestaan *

Aanmelden bij LSP toegestaan

Aanmelden bij LSP toegestaan *



Aanmelden bij LSP toegestaan *

Aanmelden bij LSP niet toegestaan

SBV-Z verificatie uitgevoerd

SBV-Z verificatie niet uitgevoerd

WID controle niet uitgevoerd

* GBZ waarschuwt indien er controles nog niet zijn uitgevoerd of indien er aanvullende wettelijke voorwaarden zijn.


- 17 -

4.4

Stappen t.b.v. eerste aansluiting op LSP

Om het volgende te realiseren: 1. Het BSN moet meegestuurd worden in alle berichten (uitzondering: het is optioneel in het BSN-vraagbericht: zonder BSN is het een opvraging, met BSN een verificatie). 2. Het BSN kan door een XIS opgevraagd en geverifieerd worden via het LSP, dat weer communiceert met de SBV-Z, of rechtstreeks bij de SBV-Z. In beide gevallen is het gebruik van een UZI-pas of UZI-servicescertificaat nodig. zijn de volgende stappen te onderkennen: •

een GBZ (concreet: de applicatie die de patiëntadministratie rol heeft) moet het door de patiënt geleverde BSN kunnen verifiëren door het aanmaken van een BSN-verificatiebericht en het verwerken van een BSN-antwoordbericht (zie onderstaande tabel);

•

een GBZ kent een opgeschoond patiëntenbestand;

•

een GBZ koppelt op basis van patiëntkenmerken de patiëntgegevens aan een BSN (een Algemene Maatregel van Bestuur heeft de zorgaanbieders die voorafgaand aan de invoering van de wetgeving rondom het BSN toch al BSN willen gebruiken toestemming verleend om het sofi-nummer te gebruiken);

•

een GBZ registreert per BSN wanneer een succesvolle opvraging of verificatie bij het SBV-Z heeft plaatsgevonden;

•

een GBZ stelt zorgverleners in staat om WID te controleren en het resultaat van deze controle vast te leggen.

Onderstaande tabel geeft de acties met actiehouder en toelichting.

Leveranciers

Actie

Allen

Toevoegen veld BSN in Hiervoor kan uitgegaan worden van de kenmerken datamodel. van het Sofi-nummer. Dit kan door een ‘aliastabel’ op te nemen, waarin de relatie intern-ID en BSN is opgenomen. Beter is het als een apart attribuut bij de persoonsgegevens opgenomen wordt.

Allen

Toevoegen BSNvlaggen voor verificatiestatus BSN, verificatiestatus WID, en bijbehorende datum en id van verificaties.

- 18 -

Toelichting

Attribuut om wijze van verificatie (bron) vast te leggen. Waarschuwingen op basis van BSN- en/of WID-vlaggen.


Leveranciers

Actie

Toelichting

Allen

Aanpassen functionaliteit systeem op gebruik BSN.

-

Aanpassing patiëntadministratiescherm Mogelijkheid tot invoeren/wijzigen/verwijderen BSN Doorvoeren nummer in formulieren, briefconcepten, etc. Mogelijk doorvoeren nummer in alle schermen waar administratie patiëntgegevens getoond wordt.

Allen

Checken identificerende velden met BVBSN-notatie en zo nodig aanpassen.

Indien meerdere personen gevonden worden of gegevens niet overeenkomen volgt een foutmelding of het sturen van de afwijkende gegevens. Indien er een eenduidige match is worden de gegevens in het antwoordbericht gezet.

Allen

Inbouwen: aanmaken berichten ten behoeve van opvragen en verificatie BSN bij SBVZ: QUPA_IN101103

Zie: “Implementatiehandleiding HL7v3 Zorg Informatie Makelaar” en “SBV-Z Conformance Profiel BSN: Opvraag/Verificatie HL7 v3” en “Interfacebeschrijving SBV-Z - XIS”. Dit laatste is tevens bedoeld voor de (initiële) batchgewijze communicatie met de SBV-Z t.b.v. de bestaande patiëntengegevens .

Allen

Inbouwen: ontvangen en verwerken BSNantwoord: QUPA_IN 101104

Zie: “Implementatiehandleiding HL7v3 Zorg Informatie Makelaar” en “SBV-Z Conformance Profiel BSN: Opvraag/Verificatie HL7 v3” en “Interfacebeschrijving SBV-Z – XIS”.

Opnemen BSN in de elektronische berichten.

Afspraken over hoe om te gaan met patiënten die geen BSN hebben of waarvan het BSN niet te achterhalen is, moeten nog gemaakt worden.

Indien gebruiker wenst: functionaliteit t.b.v. batchgewijs vullen bestand bij SBVZ.

“Interfacebeschrijving IV XIS-SBV-Z”. Hierbij moet rekening gehouden worden met de mogelijkheid het BSN o.b.v. de batchverwerking tijdelijk te koppelen totdat bijv. handmatige verificatie heeft plaatsgevonden.

Allen

Allen


- 19 -

5

Invoering Unieke Zorgverlener Identificatie Pas

5.1

Het UZI-register

Het identificerend stelsel in de zorg zoals dat belegd is bij het CIBG door de minister van VWS, gaat niet alleen over burgers (patiënten) maar ook over zorgaanbieders en zorgsystemen. Naast de SBV-Z als toegangspoort voor het BSN in de zorg, heeft het CIBG ook het UZIregister opgezet om de identiteit en authenticiteit van de zorginstellingen en zorgverleners mee vast te kunnen stellen. Het UZI-register voldoet aan een aantal wettelijke richtlijnen, waaronder die van PKI-overheid. Zie voor meer informatie over het CIBG als houder van het UZI-register: http://www.cibg.nl/units/uzi/index.html Voor meer informatie over het UZI-register zelf, zie: http://www.uzi-register.nl Een algemene informatiefolder over de UZI-pas staat onder Brochures op deze site. De diverse UZI-passen worden toegelicht onder het kopje ‘UZI-pas’. De eindgebruikercertificaten van het UZI-register worden uitgegeven onder de vertrouwensstructuur van de PKI voor de Overheid (zie www.pkioverheid.nl). De certificaten hiërarchie die nodig is om de vertrouwde uitgever van de certificaten te controleren wordt toegelicht onder ‘Raadplegen’. De vraag ‘voor wie is de UZI-pas bedoeld’ wordt beantwoord in de FAQ op deze site. De groep zorgaanbieders omvat zorginstellingen en zorgverleners. Het UZI-register hanteert bij het inschrijven van zorginstellingen de criteria uit de Kwaliteitswet Zorginstellingen. Als zorgverleners worden alle beroepsbeoefenaren als bedoeld in de artikelen 3 en 34 van de Wet op de Beroepen in de Individuele Gezondheidszorg aangeduid. Het UZI-register controleert of de aanvrager van een zorgverlenerpas voor een artikel 3 beroep is ingeschreven in het BIGregister. Voor een artikel 34 beroep wordt gecontroleerd of het is ingeschreven in het Kwaliteitsregister Paramedici. Zorgaanbieders worden gecontroleerd in het CVZ register. Omdat niet alle zorginstellingen en niet alle zorgverleners in deze registers opgenomen zijn, heeft het CIBG in een consultatieronde voorgesteld om naast de controle aan de hand van de registers andere controles te doen. Dat zou voor zorgaanbieders die anders geen UZI-passen kunnen aanvragen de mogelijkheid bieden dit wel te doen. De beschrijving van de controles waar een zorgaanbieder dan aan moet voldoen staan in het document over de Consultatieronde, onder Publicaties, Certificeringsbeleid en dan Wijzigingen. Ook de mogelijkheid van het aanvragen van een reservepas wordt hierin voorgesteld. Uitleg van alle certificaten en van de velden op de diverse UZI-passen staat in het document ‘CA model pasmodel Certificaten’ onder Publicaties en dan Specificaties. De overeenkomsten die aanvragers van UZI-passen aangaan met het CIBG en waarin procedurele zaken rondom het gebruik van de UZI-pas vastgelegd zijn, zijn te downloaden onder Publicaties en dan Overeenkomsten. De technische standaarden met betrekking tot de UZI-pas lezers en de PKI-middleware staan in het document UZI-register standaarden onder Publicaties en dan Specificaties.

- 20 -


5.2

Gebruik van UZI in AORTA-architectuur

Een UZI-pas biedt veel mogelijkheden, maar die zullen niet altijd worden benut. De wijze waarop een UZI-pas wordt gebruikt hangt af van de architectuur waarin de UZI-pas een rol vervult. Binnen de AORTA-architectuur wordt voor de autorisatie volledig gesteund op de authenticatie van zorgverleners op basis van de UZI-pas. De publieke en geheime sleutels die behoren bij het authenticatie certificaat worden door NICTIZ gebruikt bij het opzetten van een veilige verbinding tussen een GBZ en het LSP. Voordat het LSP gaat autoriseren wordt eerst de authenticiteit bepaalt. Daartoe wordt de geldigheid van het certificaat gecontroleerd bij het UZI-register en worden de identificaties van de zorgverlener (UZI-nummer) en aanvrager van de pas, de UZI register abonnee (URA) gecontroleerd met de berichten die over de veilige verbinding uitgewisseld worden. NB1. Het CIBG positioneert de UZI-pas bij zorgaanbieders in het algemeen, dus ook los van AORTA. In de brochures en documentatie zal daarbij veelal sprake zijn van het gebruik van de UZI-pas in de lokale architectuur. Voor het inloggen op het eigen XIS kan immers de UZI-pas als identificatie en eventueel authenticatie prima gebruikt worden. In de landelijke architectuur van AORTA gaat het echter vooral om het inloggen op het LSP op basis van de UZI-pas, waarbij identificatie en authenticatie op adequaat vertrouwensniveau geregeld worden. Idealiter worden beide vormen van inloggen gekoppeld (bv. via single-sign-on mechanismen), maar dat is niet altijd even makkelijk te implementeren. Een zorgaanbieder die een GBZ wil exploiteren, moet bij CIBG een UZI-servicescerificaat aanvragen en UZI-passen voor alle zorgverleners en medewerker die via het LSP patiëntgegevens gaan uitwisselen NB2. Hoewel het CIBG in het kader van authenticiteit UZI-passen kan verstrekken aan specialisten die zelf een UZI-pas aanvragen ook al zijn ze werkzaam in een ziekenhuis, zal het gebruik van deze passen voor autorisatie in de AORTA-architectuur ervoor zorgen dat alleen een zorgverlenerspas die is aangevraagd door het ziekenhuis binnen het ziekenhuis geldig is. Ten behoeve van de toepassingen van AORTA geldt ten aanzien van de UZI-pas en het UZI servicescertificaat: -

-

-

Voor het aanmelden en opvragen van patiëntgegevens dient de versleutelde verbinding naar het LSP opgezet te worden met de private key van de zorgverlener, d.w.z. dat hier één van de persoonsgebonden UZI-passen wordt gebruikt Voor het opvragen of verifiëren van een BSN dient de versleutelde verbinding naar het LSP opgezet te worden op basis van de zorgverlenerspas, een medewerkerspas (op naam of niet op naam) of (op termijn) het UZI-servicescertificaat van de instelling. Voor het aanleveren van gegevens zal het LSP de versleutelde verbinding opzetten met de eigen private key van het ZIM en de bron-systemen zullen hun private keys gebruiken: hiervoor is het UZI-servicescertificaat noodzakelijk.


- 21 -

Leveranciers Betrokken bij koplopers Alle HIS, (Z)AIS en EVS Alle HIS, (Z)AIS en EVS Alle HIS, (Z)AIS en EVS

Betrokken bij koplopers

Betrokken bij koplopers

- 22 -

Actie Testen BSN-aanpassingen met testpassen en testomgeving CIBG. Technische en functionele integratietest communicatie met het LSP. Uitwerken userscenario’s UZIpas. Deze scenario’s toetsen aan het vertrouwensmodel voor gegevensuitwisseling, eventuele hiaten signaleren en aanvullende implementatiestappen uitwerken. Aanpassen systemen op mogelijke userscenario’s.

Toelichting Testpassen en testomgeving CIBG is gereed.

In samenspraak met CIBG. In samenspraak met CIBG en NICTIZ.

Zie hiervoor ook: “CA model, Pasmodel, Certificaat- en CRL-profielen Landelijk operationeel UZIregister, versie 1.2 d.d. 23 december 2004” Gebruikerstest aanpassingen in Voor apothekersassistenten lokale omgeving binnen de en doktersassistenten systemen. kunnen de passen medewerker op naam gebruikt worden.


6

EMD

(informatief)

6.1

Inleiding

Veilige medicatie door middel van ICT is één van de speerpunten van NICTIZ. De werkgroep ‘Vaststelling medicatiedossier’ heeft in haar publicatie aangegeven welke gegevenssoorten van belang zijn in het proces van voorschrijven en verstrekken. Dit zijn in hoofdlijnen: •

Basale patiëntkenmerken;

•

Het medicatieprofiel;

•

o

Inzicht in verstrekkingen

o

Inzicht in voorschriften

Contra-indicaties; o

Allergieën, intoleranties

o

Co-morbiditeit

•

Reden van voorschrijven;

•

Overige medicatiebewakingssignalen.

De wijze waarop deze gegevens inzichtelijk zullen zijn, zijn per gegevenssoort verschillend en worden per gegevenssoort uitgewerkt. Zo zijn basale patiëntkenmerken (geslacht en leeftijd) reeds bekend voor iedere applicatie, maar gelden er condities waarvoor overige gegevens meegestuurd of opgevraagd kunnen worden. Voor het medicatiedossier worden natuurlijk ook de mogelijkheden van de nationale basisinfrastructuur benut. Het scala van essentiële gegevens wordt verbreed. Door deze verbreding en vanwege de noodzaak van flexibiliteit, worden deze gegevens niet meer elke keer per transactie meegestuurd, maar zijn ze via de verwijsindex van het LSP opvraagbaar. Daarnaast zal de nationale basisinfrastructuur een belangrijke rol spelen in de logistieke afhandeling van voorschriften. Zie voor de modellering van de betreffende zorgpaden en de daarbij behorende berichten de HL7v3 documentatie over de medicatieberichten. De gehyperlinkte versie is op te starten via: http://www.nictiz.nl/aortadocumentatie


- 23 -

6.2

EMD van Edifact naar HL7v3

In onderstaande tabel wordt aangegeven op welke wijze de nieuwe HL7-standaard de oude EDIFACT-berichtenstructuur vervangt: EDIFACT-bericht Update LDAP-server (verwijsindex): aanmelden en mutaties basispatiëntgegevens (NAW, verzekeringsgegevens) bij LDAP-server.

Wordt in HL7v3 N.v.t.

Query VWI om te bepalen waar informatie over een patiënt gevonden kan worden in de waarneemsituatie.

Is integraal onderdeel van de opvraagberichten verstrekkingen en voorschriften en gaat via LSP door naar aangesloten systemen. Opvragen van de verstrekkingen en aanvullende gegevens.

Aanvraag medicatiehistorie

Overzicht medicatiehistorie

Verstrekkingsberichten

Waarneemretourbericht Receptbericht

Verstrekkingsberichten Voorschriftbericht

Transmuraal bericht

Samenstelling van verstrekkings-, voorschriften stopbericht en wijzigingsbericht.

- 24 -

Toelichting Zie ook hoofdstuk 3, tabel met acties voor leveranciers en “Implementatiehandleiding HL7v3 Zorg Informatie Makelaar”. “Verlengde arm” constructie is niet aanwezig in Edifact berichten. In de basisinfrastructuur hoeft een gebruiker niet meer apart de informatie op te zoeken, maar wordt de routering geregeld door het LSP. Voor routering via LSP gelden extra autorisatie eisen. Voor noodsituaties moet het mogelijk zijn om een indicatie mee te geven, waarmee autorisatie overruled kan worden. Dit is in Edifact niet mogelijk. Er zijn afspraken gemaakt tussen KNMP en NHG inzake het meesturen van gegevens over allergieën, comorbiditeit en contra-indicaties. Het Edifact bericht bevat extra attributen, zoals allergieën, die in HL7v3 in aparte berichten worden gecommuniceerd. Idem Het voorschriftbericht is gereed om te implementeren, maar in de eerste fase van het LSP, zal het LSP het routeren naar de ontvanger nog niet faciliteren. Het stopbericht en bericht m.b.t. interventies in medicatie is beschikbaar, maar het dynamisch proces moet getoetst worden aan de Nederlandse transmurale situatie. NICTIZ stelt hiervoor specificaties en richtlijnen op.


Naast inhoudelijke verschillen zijn er ook generieke verschillen op het gebied van functionele eisen tussen Edifact en HL7v3 berichten. Bij aansluiting op het LSP moeten HL7v3 berichten immers voldoen aan eisen die door CBP gesteld worden voor veilig en betrouwbaar communiceren. Eén van de eisen is dat naast de uitvoerder (bijvoorbeeld een assistent) ook een verantwoordelijke zorgverlener (apotheker of arts) in een bericht meegestuurd wordt, zodat hiermee de bevoegdheid van een medewerker in een ‘verlengde arm’ constructie mogelijk wordt gemaakt. De eis is nodig voor de controle op autorisatie in een vraagstelling via het LSP. Deze constructie is (nog) niet mogelijk in een Edifact bericht. Op het gebied van transactieprotocollen wordt nu ook meer diepgang gevraagd voor de status van interacties. Waar voorheen met Edifact gewoonweg geen antwoord werd gegeven bij foutsituaties, wordt nu een toelichting terug verwacht van de foutsituatie. (bijvoorbeeld: ‘onvoldoende autorisatie’, of ‘geen antwoord binnen de gestelde range’). De foutafhandeling van Edifactberichten is bij aansluiting op het LSP ontoereikend. Het Edifact bericht staat namelijk toe dat een beperkte set van (onvolledige) informatie gestuurd wordt.

6.3

Doelstelling t.b.v. eerste fase EMD

Veilige medicatie begint bij een goed inzicht in het gebruik van geneesmiddelen van de patiënt. Dit geldt zowel in de ambulante als de klinische setting. De eerste release van het LSP ondersteunt het opvragen van medicatieverstrekkingen bij elke vorm van apotheken. Dat wil zeggen dat: -

Een XIS met verstrekkingfunctionaliteit, bijvoorbeeld (Z)AIS of HIS van apotheekhoudende huisarts, medicatieverstrekkingen op basis van het BSN dient aan te melden bij de verwijsindex (per categorie);

-

Een XIS met verstrekkingsfunctionaliteit een vraag voor de medicatiehistorie op basis van een BSN en de gestelde parameters kan beantwoorden.

-

Een GBZ met de toepassingsrol ’EMD-voorschrijver’ het opvragen van verstrekkingen dient te ondersteunen (verstrekking-opvraagbericht maken en verstrekking-antwoordberichten verwerken). Met verwerken wordt bedoeld het integreren van het bericht in het dossier ten behoeve van zorgfuncties, bijvoorbeeld medicatiebewaking. Met het ontvangen wordt bedoeld sorteer, filter en weergave of printfuncties.

Naast het treffen van maatregelen op het gebied van GBZ, UZI-pas en BSN, dienen de acties in het volgende schema te worden ondernomen. Achter de actie is tussen haakjes het type interactie vermeld). Leveranciers (Z)AIS-systeem (Z)AIS-systeem

(Z)AIS-systeem

Actie Melden van patiënt en gegevenssoort bij de verwijsindex van het LSP (MFMT_IN002101) Wijzigen of afmelden van patiënt en gegevenssoort bij de verwijsindex van het LSP (MFMT_IN002102/3) Ontvangen van query van medicatiehistorie (QURX_IN990011NL)


Toelichting Voor deze zorgtoepassing wordt uitgegaan van categorale aanmelding Voor deze zorgtoepassing wordt uitgegaan van categorale aanmelding Indien apotheek zelf de bron is van de gegevens.

- 25 -

Leveranciers (Z)AIS-systeem

Actie Genereren van medicatiehistorie van verstrekkingen en deze verzenden naar LSP (QURX_IN990013NL)

(Z)AIS-systeem

Plaatsen van query voor medicatiehistorie van een patiënt (QURX_IN990011NL)

(Z)AIS-systeem

Ontvangen en tonen van medicatiehistorie met bijbehorende sorteer- en filtermogelijkheden (QURX_IN990013NL) Plaatsen van query voor medicatiehistorie van een patiënt (QURX_IN990011NL) Ontvangen en tonen van medicatiehistorie met bijbehorende sorteer- en filtermogelijkheden (QURX_990013NL) Het komt ook voor, dat het EPD het antwoord geeft op een vraag van het LSP op een verzoek voor de medicatiehistorie. Ook hier geldt, dat alleen de eigen verstrekkingen worden gerapporteerd.

ZIS/EVS/EPD voorschrijvers (1e en 2e lijn) ZIS/EVS/EPD voorschrijvers (1e en 2e lijn) ZIS/EVS/EPD-systeem voorschrijvers

Toelichting Alleen verstrekkingen door eigen apotheek meesturen. De apotheek moet ook verstrekkingen gedaan tijdens de waarneming als antwoord op de query medicatiehistorie kunnen geven. Indien de apotheek zelf een medicatiequery via LSP wil opvragen bijvoorbeeld voor dienstwaarneming apotheek Idem

Idem.

Toelichting op in tabel beschreven acties Ziekenhuisapotheeksysteem De verstrekkingen van de ziekenhuisapotheken zullen in eerste instantie categoraal aangemeld worden in de verwijsindex van het LSP (zie hiervoor “Implementatiehandleiding HL7v3 zorginformatiemakelaar”). Naast de patiënt- en de zorgverleneridentificatie, wordt de gegevenssoort en een datum-range (effective time) meegegeven. Voor de UZI gaat het om hier de zorgverlenersidentificatie van de verantwoordelijke apotheker. Bij nieuw opgenomen patiënten wordt de eerste aanmelding gedaan op het moment dat de ziekenhuisapotheker een (definitieve) medicatieopdracht registreert in het apotheek systeem. Gebruik van één bericht (QURXIN990013) voor medicatiehistorie Het HL7v3 (QURXIN990013NL) bericht is geschikt voor zowel de poliklinische als de klinische informatie. De query wordt aan het LSP gesteld en het antwoord is afkomstig van het LSP. Het LSP zoekt zelf via de verwijsindex de bijbehorende adressen van de bronnen.

- 26 -


6.4

Migratie scenario’s

Bij het uitrollen van de implementatie hebben regio’s niet te maken met nieuwbouw, maar met bestaande functionaliteit. Er zal dus een overgangssituatie zijn, waarin instellingen één voor één aangesloten worden op het LSP. Voor grote regio’s is dit een proces van enkele maanden. Voor deze situatie is door NICTIZ een migratiescenario voorgesteld waarin een GBZ tijdelijk zowel via de bestaande communicatie mogelijkheden als via het LSP de functionaliteit in de lucht kan hebben. Indien alle zorgaanbieders in een regio op het LSP zijn aangesloten en er geen verlies van bestaande functionaliteit is, is het migratie scenario ten aanzien van deze toepassing niet langer noodzakelijk. Verdere uitwerking en besluitvorming rond migratie trajecten zal door het implementatieteam ter hand worden genomen.


- 27 -

7

WDH

(informatief)

7.1

Inleiding

Dienstwaarneming van Huisartsen betreft de avond- nacht- en weekend-waarneming die door Huisartsen Diensten Structuren (HDS) worden gerealiseerd met huisartsenposten (HAP). De informatiebehoefte op de huisartsenpost is door het NHG vastgesteld in de vorm van een Professionele Samenvatting van het dossier van de eigen huisarts. Omdat deze samenvatting wel de volledige structuur van een medisch dossier bevat (alleen niet alle contacten) dient het bericht het volledige dossier zoals dat uitgewisseld zou kunnen worden te reflecteren. Daarom is er voor gekozen eerst het volledige domein van de eerstelijn te modelleren in HL7v3, zodat het waarneembericht en het waarneemretourbericht daar van afgeleid zouden kunnen worden.

7.2

WDH van Edifact naar HL7v3

Het Domain Message Information Model Primary Care (DMIM PriCa) vormt een afspiegeling van wat er in de huidige HIS’en geregistreerd kan worden. Tevens is zij voorbereid op systemen gebaseerd op het onlangs door het NHG gepubliceerde HIS-referentiemodel 2005. In het DMIM PriCa zijn de volgende berichten opgenomen: -

Patiëntoverdracht bij verhuizing;

-

Query-bericht (verzoek voor waarneeminformatie);

-

Waarneming Avond/nacht/weekend (ANW) (Professionele Samenvatting);

-

Waarneemretourbericht (retour informatie van de huisartsenpost naar de eigen, vaste huisarts);

-

Verwijsbericht op basis van de NHG-richtlijn Huisarts – Specialist (HASP);

-

Medicatievoorschrift (verwijzing naar “Implementatiehandleiding HL7v3 Medicatieberichten”);

-

Medicatieaflevering (verwijzing naar “Implementatiehandleiding HL7v3 Medicatieberichten”);

-

Labaanvraag (verwijzing naar “Implementatiehandleiding HL7v3 Perinatologie”);

-

Labresultaat (verwijzing naar “Implementatiehandleiding HL7v3 Perinatologie”);

-

Query-bericht (verzoek voor spoedeisende hulp informatie);

-

Samenvatting t.b.v. Spoedeisende Hulp;

-

Spoedeisende Hulp retourbericht (retour informatie van de spoedeisende hulp naar de eigen, vaste huisarts).

Het DMIM PriCa vormt daarmee een volwaardig alternatief voor de EDIFACT-drager MEDEUR, en de EDIFACT-berichten MEDOVD, MWNH, MVWI, MEDREC en MEDSPE. Voor MEDLAB is een eerste aanzet gedaan. Het DMIM PriCa model is tijdens de internationale HL7 Spring 2005 Working Group Meeting getoetst aan het bredere, internationale DMIM Patient Care. Het DMIM PriCa vormt hier een geldige restrictie op. Het DMIM PriCa wordt beschreven in de “Implementatiehandleiding HL7v3 Gegevensuitwisseling Huisartsen”. Deze handleiding is een uitbreiding op en vervangt de ‘Implementatiehandleiding HL7 versie 3 Waarneming Huisartsen’.

- 28 -


Het bestaat uit de volgende onderdelen die allen afzonderlijk zijn te downloaden via de website www.nictiz.nl: -

Mappingsdocument EDIFACT HL7 DMIM PriCa: Er is een integrale mapping samengesteld van EDIFACT-berichtelementen naar de overeenkomstige HL7v3-berichtelementen.

-

Mapping WCIA naar HL7v3 Er is een integrale mapping samengesteld van de WCIA-tabellenklapper naar HL7v3. Voor de mapping van tabel 25 is een apart document beschikbaar.

-

OIDs DMIM PriCa Er is een lijst samengesteld met OIDs die in het D-MIM PriCa gebruikt worden.

-

Hierarchical Message Description De HMD’s zijn uitgewerkt. Deze zijn afgeleid van de R-MIM’s.

-

Grafische weergave van de modellen Alle submodellen zijn in een apart bestand als JPEG opgenomen zodat deze op gewenst formaat af te drukken zijn.

-

XML-schema’s De XML-schema’s zijn uitgewerkt. Deze zijn afgeleid van de R-MIM’s.

-

Voorbeeldberichten De voorbeeldberichten (XML-bestanden) zijn uitgewerkt voor zowel het patiëntoverdrachtbericht als berichten t.a.v. het WDH.

In de volgende tabel wordt, specifiek t.a.v. dienstwaarneming huisartsen (avond, nacht, weekend) c.q. de informatie-uitwisseling tussen Huisarts en Huisartspost, aangegeven hoe de nieuwe HL7v3-standaard de oude EDIFACT-berichtenstructuur vervangt. EDIFACT: Medeur MEDOVD: overdracht volledig dossier patiënt

Wordt in HL7v3 Niet gebruikt voor het WDH. Wel wordt leveranciers aanbevolen dit bericht te implementeren t.b.v. overdracht inschrijving patiënt naar andere huisarts (REPC_IN004411NL)

MVWI

Opvragen professionele samenvatting (QUPC_IN990001NL) Professionele samenvatting (QUPC_IN990002NL) Waarneemretourbericht (REPC_IN990003NL)

MWNH: Samenvatting Waarneemretourbericht: MEDVRI-bericht: vrije tekst en MEDOVD (OZIS-pro) MWNH (OZIS)


Toelichting Dit bericht wordt nu ingezet voor: overdracht inschrijving patiënt naar andere huisarts en bij de ‘OZIS-pro’strategie in de dienstwaarneming. Nu de professionele samenvatting gedefinieerd is, wordt deze overdracht niet zinvol geacht voor dienstwaarneming.

- 29 -

7.3

Doelstelling t.b.v. eerste fase WDH

Bij oplevering van het LSP is op basis van HL7v3: De professionele samenvatting van het huisartsdossier opvraagbaar. Het waarneemretourbericht routeerbaar. Het is in deze eerste fase nog niet verplicht om de berichten voor de overdracht van verantwoordelijkheid voor beheer van patiëntgegevens te implementeren. Het verwerken of overnemen van gegevens uit het waarneemretourbericht betekent in deze fase dan ook dat de gegevens van het waarneemcontact zowel bij de waarneempost zijn op te vragen, als bij de eigen huisarts via de professionele samenvatting. Omdat de contacten uniek geïdentificeerd worden, kunnen ze ook in deze fase worden herkend als hetzelfde contact. Dat wil zeggen dat: •

Een XIS met functionaliteit voor registratie van eerstelijnsconsulten (HIS, HAPsysteem) één patiëntendossier moet aanmelden bij de VWI (dossier-aanleg per patiënt).

•

Een XIS met toepassingsrol ’dienstwaarneming huisartsen’ (bijvoorbeeld HAP) een waarneembericht moet kunnen opvragen, ontvangen en verwerken en een retourbericht aan moet kunnen maken.

•

Een HIS een waarneemretourbericht moet kunnen ontvangen.

Onderstaande tabel geeft de acties aan met een verwijzing naar de betreffende documentatie. Leverancier HIS-systeem

HAP-systeem

HIS-systeem HAP-systeem HIS-systeem HAP-systeem HAP-systeem

HAP-systeem

- 30 -

Actie Inbouwen bericht aanmaken dossier-aanmelding/wijziging/-afmelding : MFMT_IN002101/2/3 Inbouwen HL7v3 bericht opvragen professionele samenvatting QUPC_IN990001NL

Toelichting Zie “Implementatiehandleiding HL7v3 zorginformatiemakelaar” Zie “Implementatiehandleiding HL7v3 Gegevensuitwisseling Huisartsen” Inbouwen bericht ontvangen Idem. en verwerken opvragen professionele samenvatting QUPC_IN990001NL Inbouwen bericht antwoord Idem. professionele samenvatting QUPC_IN990002NL Inbouwen functionaliteit Aanpassing systeem zodat inlezen professionele professionele samenvatting samenvatting geïntegreerd QUPC_IN990002NL kan worden in het waarneemsysteem. Inbouwen bericht aanmaken Zie (waarneem)dossier“Implementatiehandleiding aanmelding/-wijziging/HL7v3 afmelding: Zorginformatiemakelaar” MFMT_IN002101/2/3


Leverancier HAP-systeem

Actie Inbouwen aanmaken waarneemretourbericht REPC_IN990003NL

HIS-systeem

Inbouwen functionaliteit inlezen waarneemretourbericht REPC_IN990003NL

7.4

Toelichting Zie “Implementatiehandleiding HL7v3 Gegevensuitwisseling Huisartsen” Aanpassing systeem zodat waarneemretourbericht kan worden ingelezen. Zie: “Implementatiehandleiding HL7v3 Gegevensuitwisseling Huisartsen”

Migratie scenario’s

Bij het uitrollen van de implementatie hebben regio’s niet te maken met nieuwbouw, maar met bestaande functionaliteit. Er zal dus een overgangssituatie zijn, waarin instellingen één voor één aangesloten worden op het LSP. Voor grote regio’s is dit een proces van enkele maanden. Voor deze situatie is door NICTIZ een migratiescenario voorgesteld waarin een GBZ tijdelijk zowel via de bestaande communicatie mogelijkheden als via het LSP de functionaliteit in de lucht kan hebben. Indien alle zorgaanbieders in een regio op het LSP zijn aangesloten en er geen verlies van bestaande functionaliteit is, is het migratie scenario ten aanzien van deze toepassing niet langer noodzakelijk. Verdere uitwerking en besluitvorming rond migratie trajecten zal door het implementatieteam ter hand worden genomen.


- 31 -

8

Begeleiding

8.1

Inleiding

Met enige regelmaat worden er themabijeenkomsten en leveranciersdagen georganiseerd. Daarnaast worden leveranciers uitgenodigd voor klankborden en werkgroepen om tijdens de ontwikkeling van standaarden hun kennis en ervaring in te brengen. Naast het algemene accountmanagement, bestaat de ondersteuning van de leveranciers, uit de volgende onderdelen: a. Handboek: periodiek uit te geven, verwijzing naar de voor de leverancier belangrijke documenten om de applicaties gereed te maken voor landelijke aansluiting; b. Expertteam: gremium met deskundigen (op persoonlijke titel) ter ondersteuning van ontwikkelen implementatieproces van de leveranciers, initiator van themabijeenkomsten en betrokken bij de verdere ontwikkeling van de testtool; c. Klankbordgroep: regulier overleg met product managers van ICT-leveranciers in de zorg waar informatie wordt uitgewisseld en issues geagendeerd kunnen worden. d. Testtool: tool t.b.v. leveranciers om de berichten te valideren via Internet; e. Supportorganisatie: organisatie waar alle vragen van leveranciers worden neergelegd. De afdeling support zorgt voor gestructureerde beantwoording van de vragen; f. Bijeenkomsten: organiseren van praktische bijeenkomsten t.b.v. de leveranciers die aansluiten op de behoefte in het ontwikkelproces. Denk hierbij aan de interactie met de LSP-bouwer, praktische ondersteuning bij de invoering van UZI, etc.

8.2

Accountmanagement leveranciers

Binnen NICTIZ is een accountmanager benoemd die zich volledig richt op de ondersteuning van de leveranciers en communicatie met de leveranciers. Deze accountmanager: • Speelt vragen van leveranciers door naar de ter zake kundigen binnen NICTIZ en bewaakt het proces van afhandeling van de vragen; • Communiceert nieuwe inzichten en ontwikkelingen vanuit NICTIZ op de goede momenten met leveranciers; • Heeft per leverancier een managementaanspreekpunt en een technisch inhoudelijk aanspreekpunt om deze communicatie vorm te geven; • Adviseert inzake financieringsvraagstukken m.b.t. NICTIZ activiteiten vanuit leveranciersoogpunt; • Bewaakt de voortgang van de in het handboek opgenomen planning. • Bijeenkomsten organiseren, behoefte hieraan signaleren etc.

8.3

Expertteam

Er is een expertteam ingericht met als doel: • Advies en richting te geven aan faciliteiten voor leveranciers, in het bijzonder testfaciliteiten; • Als advisory board te dienen voor de interpretatie van standaarden en richtlijnen; • Het opzetten en vaststellen van goede testcriteria en daarmee samenhangende testscenario’s; • Feedback geven in het testtraject. Het expertteam bestaat uit ter zake kundigen vanuit NICTIZ, experts op het gebied van HL7v3, verwijsindex, wrappers, transport, XML etc. en een aantal experts vanuit de leveranciers.

- 32 -


Er is een keuze gemaakt in de interacties die NICTIZ als eerste set in een testtool beschikbaar stelt: Transportprotocol: http/soap; encryptie met behulp van (UZI/systeem) certificaten. Schakelpuntfuncties: registratie gegevens in verwijsindex; opvragen / respons BSN. EMD: opvragen / respons medicatiehistorie (=verstrekkingsbericht); opvragen / respons voorschriften. WDH: opvragen / respons proffesionele samenvatting van een patient; waarneembericht naar vaste huisarts. De testtool is door het expertteam opgeleverd. Het expertteam zal de komende periode een belangrijke rol vervullen in de beantwoording van de vragen en het organiseren van themabijeenkomsten.

8.4

Testfaciliteiten

Zoals aangekondigd in de vorige versie van dit handboek is The Beagle Armada door NICTIZ geselecteerd voor de realisatie van de testtool. Deze tool kan gebruikt worden door leveranciers om: 1. Syntax te valideren van de HL7v3 berichten die aan het EMD- en WDH (incl. ZIM) gerelateerd zijn. 2. Semantiek te valideren van de HL7v3 berichten die aan het EMD en WDH (incl. ZIM) gerelateerd zijn. 3. Het transportprotocol (SOAP) te testen. 4. Code en referenties te valideren (o.a. Z-index en G-standaard). Voor de huidige scope van het EPD-programma zijn twee releases gedefinieerd voor de testtool (zie onder). In de toekomst kan de testtool uitgebreid worden met nieuwe zorgapplicaties (zoals bijvoorbeeld JGZ) afhankelijk van het succes en de resultaten die behaald worden met EMD en WDH. Release 1

Beschikbaar vanaf 29 september 2005

2

16 oktober 2005

3

15 januari 2006

Beschrijving beschikbare functionaliteit Syntaxvalidatie en handmatig uploaden van ZIM-, WDH- en EMD-berichten (totaal 19) Release 1 + semantiekcontrole van HL7v3berichten EMD en WDH + webservice (SOAP) + code/referentietabellen (Z-index + Gstandaard) Definitieve oplevering

De testtool is te benaderen zijn via www.testtool.nl en de webservice via http://webservice.testtool.nl. Ondersteuning betreffende gebruik en werking van de testtool zal geleverd worden via [email protected] of telefonisch op 078-6521118. De meest actuele documentatie betreffende het gebruik van de testtool is te vinden op de website van NICTIZ.


- 33 -

8.5

AORTA Support & Productcommunicatie

AORTA Support & Productcommunicatie heeft de volgende taken: • Het ontvangen, registreren en zorgen voor beantwoording van vragen uit het veld en dan vooral voor ICT-afdelingen van zorgpartijen en ICT-leveranciers van XIS-en. Voor de koplopers en het LSP vormt AORTA Support en Productcommunicatie een tweedelijns ondersteuning. Vragen kunnen hierbij gesteld worden via het emailadres: [email protected]. Deze taak voert NICTIZ samen met CIBG uit, waarbij NICTIZ de vragen over AORTA zal afhandelen en CIBG de vragen over UZI en BSN. • Het voorzien van het veld van productinformatie. Hierbij kan gedacht worden aan veelgestelde vragen (FAQ’s), informatie over wijzigingen of nadere uitleg van onderdelen van de specificaties via de XISMAIL. • Het opzetten en bewaken van change en releasebeheer voor de producten van AORTA en de publicatie hiervan en het voeren van een configuratiebeheer op die producten. Dit proces wordt van groot belang nu er steeds meer componenten in de AORTAarchitectuur worden gerealiseerd. Samenwerking met alle betrokken partijen is hierbij van belang. • Een coördinerende taak bij het beheer van dit handboek, in samenwerking met VWS en CIBG.

- 34 -


Bijlage 1: Overzicht gebruikte documentatie Relevante websites: • • • • • •

www.minvws.nl www.invoering-epd.nl www.cibg.nl www.nictiz.nl (Voor vragen m.b.t. specificaties kan contact opgenomen worden met helpdesk van het NICTIZ: [email protected]) www.sbv-ztest.nl (Voor vragen m.b.t. implementatie van BSN kan contact opgenomen worden met helpdesk van het SBV-Z, 070-3407005 of mail naar [email protected]) www.uzi-register.nl (Voor vragen m.b.t. implementatie van de UZI-pas kan contact opgenomen worden met helpdesk van het CIBG, 070-3406020 of mail naar [email protected])

Documenten te vinden op www.nictiz.nl: §

Programma van Eisen voor een Goed Beheerd Zorgsysteem, versie 1.1, augustus 2006

§

Specificatie van de basisinfrastructuur in de zorg, versie 2.4, augustus 2006

§

Architectuurontwerp basisinfrastructuur in de zorg, versie 4.2, november 2005

§

Implementatiehandleiding HL7v3 Medicatieberichten versie 2.5, augustus 2006

§

Implementatiehandleiding HL7v3 Gegevensuitwisseling Huisartsen versie 3.2.1, augustus 2006

§

Implementatiehandleiding HL7v3 Zorg Informatie Makelaar versie 2.5, augustus 2006

§

Implementatiehandleiding HL7v3 Infrastructurele Domeinen versie 2.5, augustus 2006

§

Implementatiegids HL7v3 Web Services Profile versie 1.2, augustus 2006

§

Implementatiehandleiding HL7v3 Data Types en CMETs, versie 1.0, november 2005

§

Kwalificeringsschema ZSP, vesie 1.1, augustus 2006

§

XML-materiaal versie 1.1.13

§

Toegang tot patiënt gegevens van het WGBO-implementatie-programma

§

Modelrichtlijn en modelvoorlichtingsmateriaal autorisatie voor Koplopers Elektronisch Medicatie Dossier

§

Modelrichtlijn Dienstwaarneming huisarts en bijbehorende voorlichtingsmateriaal autorisatie voor Koplopers Waarneem Dossier Huisartsen

§

Checklist autorisatie en logging regionale samenwerkingsverbanden in toolkit medicatie- en waarneemdossier

§

Rapport Inventarisatie Waarneemsystemen 2004 met updates uit 2005

§

Richtlijn Gegevensuitwisseling huisarts - Centrale Huisartsenpost

§

Implementatie Richtlijn Adequate Dossiervorming met het EMD


- 35 -

Bijlage 2: EMD Toekomsscenario’s Geschrapt, vanuit hoofdstuk 6 wordt verwezen naar bron-documentatie.

Bijlage 3: Afkortingen- en begrippenlijst Om ook hier redundantie met het risico van inconsistentie te vermijden, is deze bijlage geschrapt en wordt verwezen naar hoofdstuk 2 van het Programma van Eisen voor een Goed Beheerd Zorgsysteem.

- 36 -


Bijlage 4: Overzicht berichtdefinities 4A: Overzicht van berichten die verplicht zijn voor de XIS-en met een bepaalde toepassingsrol binnen EMD of WDH (zie onder opmerkingen). Beschrijving

Toepassing

Berichtnaam

Verwerking

Specificatie

opvragenPatiëntIdentificatie

BSN van patiënt opvragen en verifiëren

in: QUPA_IN101103 br: QUPA_MT101103 cw: QUQI_MT020001 tw: MCCI_MT000100 in: QUPA_IN 101104 br: QUPA_MT101104 cw: MFMI_MT700711 tw: MCCI_MT000300 in: QUMT_IN020010 br: MFMT_MT020020 cw: QUQI_MT021001 tw: MCCI_MT000100

aanmaken

ZIM handleiding alle rollen

ontvangen en verwerken

Idem

alle rollen

aanmaken

Idem

alle rollen

in: QUMT_IN020020 br: QUMT_MT002001 cw: MFMI_MT700712 tw:MCCI_MT000300 in: MFMT_IN002101 br: MFMT_MT002002 cw: MFMI_MT700702 tw: MCCI_MT000100 gs: SPLY in: MFMT_IN002102 / 3 br: MFMT_MT002001 cw: MFMI_MT700702 tw: MCCI_MT000100 in: QURX_IN990011NL br: QURX_MT990011NL cw: QUQI_MT020001 tw: MCCI_MT000100 Idem

ontvangen

Idem

alle rollen

aanmaken

Idem

EMD-verstrekker

aanmaken

Idem

Idem

aanmaken

Medicatie berichten

alle rollen

ontvangen en verwerken aanmaken

Idem

EMD-verstrekker

Idem

Idem

ontvangen

Idem

alle rollen

opleverenPatiëntIdentificatie opvragenIndex

Overzicht opvragen van wat aan de verwijsindex aangemeld is

opleverenIndex

aanmeldenMedicat Aanmelden van ieVerstrekking een verstrekking ten behoeve van het opvragen van verstrekkingen heraanmelden of actualiseren van afmelden aanmelding of afmelden opvragenMedicati e-Verstrekking

opvragen van alle verstrekkingen voor een patiënt

Idem opleverenMedicati eVerstrekking

in: QURX_IN990013NL br: PORX_MT924000NL cw: QUQI_MT120001 tw: MCCI_MT000300 Idem

Idem

Landelijke toepassingsrol

aanmeldenEerstelijnsZorgverlening

Aanmelden van een eerstelijnspatiëntendossier als ‘primary care provision’

in: MFMT_IN002101 br: MFMT_MT002002 cw: MFMI_MT700702 tw: MCCI_MT000100 gs: PCPR

aanmaken

ZIM handleiding WDHdossierhouder WDH-waarnemer

heraanmelden of afmelden

actualiseren (bijv. van einddatum) of afmelden (bijv. bij overdracht dossier) opvragen van professionele samenvatting

in: MFMT_IN002102 / 3 br: MFMT_MT002001 cw: MFMI_MT700702 tw: MCCI_MT000100

aanmaken

Idem

Idem

in: QUPC_IN990001NL br: QUPC_MT990001NL cw: QUQI_MT021001

aanmaken

Huisarts berichten

WDH-waarnemer

opvragenSamenvattingVoorDWH


- 37 -

t.b.v. dienstwaarneming huisartsen

tw: MCCI_MT000100

Idem

Idem


Idem

opleverenSamenvattingVoorDWH

in: QUPC_IN990002NL br: REPC_MT004001NLPS cw: QUQI_MT120001 tw: MCCI_MT000300 Idem

aanmaken

Idem

WDHdossierhouder WDH-waarnemer Idem


Idem

WDH-waarnemer

Huisarts berichten

Idem

ontvangen

Idem

WDHdossierhouder

aanmaken en verwerken

Idem

alle rollen

aanmaken en verwerken

Idem

alle rollen

Idem versturenVerslagDWH

terugrapporteren van waarneemcontact aan eigen huisarts

vervolg-opvraag

Transmission wrappers

Accepteren of foutmelden

in: REPC_IN990003NL br: REPC_MT004001NLWR cw: MCAI_MT700201 tw: MCCI_MT000100 Idem in: QUQI_IN000003 br: n.v.t. cw: QUQI_MT000001 tw: MCCI_MT000100 MCCI_MT000xxx

Legenda: in: interactienummer (volgens specificatie) br: berichtnummer cw: control-act wrapper (TECA) tw: transmission wrapper gs: gegevenssoort (in aanmeldbericht en vanuit opvraagbericht via koppeltabel LSP) Opvraagbaar betekent aanmelding bij VWI, overzicht mogelijk en opvragen van medische inhoud Routeerbaar betekent verzenden point-to-point van zender naar ontvanger Verifieerbaar betekent bijeenhoren van identiteitgegevens wordt al dan niet bevestigd Maken van een bericht: genereren van gespecificeerd bericht conform applicatierol Ontvangen van een bericht: het kunnen tonen van de gegevens van een bericht Verwerken van een bericht: het toevoegen van gegevens uit een bericht in het informatiesysteem, al dan niet na filtering door een gebruiker of het reageren op een bericht conform specificaties. Hoewel de toepassingsrol van WDH-waarnemer altijd die van WDH-dossierhouder impliceert, zijn ze in de tabel toch apart vermeld.

- 38 -


4B. Berichten die optioneel zijn, dus niet verplicht maar wel toegestaan Vervallen 4C. Berichten die gespecificeerd zijn, maar nog niet verplicht Beschrijving

Toepassing

opvragenZorgverlenerDetails

opvragen UZInummers

Berichtnaam

in: PRPM_IN306050NL br: QUPA_MT101103 cw: QUQI_MT020001 tw: MCCI_MT000100 opleverenin: PRPM_IN306051NL ZorgverlenerDetails br: QUPA_MT101104 cw: MFMI_MT700711 tw: MCCI_MT000300 in: PRPM_IN405010 opvragenopvragen van br: PRPM_MT405010 ZorgInstellingDetails gegevens over een organisatie cw: QUQI_MT121001 tw: MCCI_MT000100 opleverenin: PRPM_IN405110 ZorginstellingDetails br: PRPM_MT405110 cw: MFMI_MT700711 tw: MCCI_MT000300 Aanmeldenaanmelden van in: MFMT_IN002101 br: MFMT_MT002002 MedicatieVoorschrift voorschriften ten behoeve van cw: MFMI_MT700702 tw: MCCI_MT000100 het opvragen gs: SBADM van voorschriften opvragenMedicatie- opvragen van in: QURX_IN990001NL Voorschrift voorschriften br: QURX_MT990001NL voor een patiënt cw: QUQI_MT020001 tw: MCCI_MT000100 Idem idem opleverenMedicatieVoorschrift Idem versturenMedicatieVerstrekking

versturen van afleverbericht

Idem versturenMedicatieVoorschrift

versturen van recept

opvragenSamenvattingVoorSEH

opvragen van patiëntgegevens in het kader van SpoedEisendeHu lp

in: QURX_IN990003NL br: PORX_MT932000NL cw: QUQI_MT120001 tw: MCCI_MT000300 idem in: PORX_IN924000NL br: PORX_MT924000NL cw: MCAI_MT700201 tw: MCCI_MT000100 idem in: PORX_IN932000NL br: PORX_MT932000NL cw: MCAI_MT700201 tw: MCCI_MT000100 idem in: QUPC_IN990011NL br: QUPC_MT990011NL cw: QUQI_MT021001 tw: MCCI_MT000100

idem

Idem

opleveren-

in: QUPC_IN990012NL


Verwerking

Specificatie

Landelijke toepassingsrol

aanmaken

ZIM handleiding

nader in te vullen


Idem

aanmaken

Idem


Idem

aanmaken

Idem

aanmaken

Medicatie berichten


Idem

ontvangen aanmaken

Idem

Idem

ontvangen aanmaken



Huisarts berichten

Idem Idem

- 39 -

SamenvattingVoorSEH

br: REPC_MT004001NL-SH cw: QUQI_MT120001 tw: MCCI_MT000300 Idem

idem

versturenVerslagSEH versturen van in: REPC_IN990013NL retourinformatie br: REPC_MT004001NL-ER cw: MCAI_MT700201 tw: MCCI_MT000100 idem Idem in: REPC_IN004411NL versturenversturen van br: REPC_MT000001NL PatiëntOverdracht compleet patiëntendossier cw: MCAI_MT700201 bijvoorbeeld bij tw: MCCI_MT000100 verhuizing patiënt idem idem in: REPC_IN002111NL versturenVerwijzing versturen van br: REPC_MT002001NL verwijsbrief cw: MCAI_MT700201 vanuit eerste naar tweedelijn tw: MCCI_MT000100 idem idem versturenBepalingversturen van in: POLB_IN002121 Opdracht lab-aanvraag br: POLB_MT002100 cw: MCAI_MT700201 tw: MCCI_MT000100 idem idem versturenBepalingResultaat idem

terugsturen van lab-resultaat

in: POLB_IN004410 br: POLB_MT004000 cw: MCAI_MT700201 tw: MCCI_MT000100 idem


Idem

ontvangen aanmaken

Idem Huisarts berichten

ontvangen aanmaken

Idem Huisarts berichten

ontvangen aanmaken

Idem Perinatologie


Idem


Huisarts berichten

Idem

Idem

Legenda: in: interactienummer (volgens specificatie) br: berichtnummer cw: control-act wrapper (TECA) tw: transmission wrapper gs: gegevenssoort (in aanmeldbericht en vanuit opvraagbericht via koppeltabel LSP) Om als GBZ getoetst te worden gelden een aantal eisen waar XIS-en aan moeten voldoen. Onderdeel van die eisen is de correcte implementatie van een minimum set berichten op een bepaald moment. Andere zaken kunnen op dat moment optioneel zijn. Niet verplicht voor GBZ-toetsing bij de aanvang van de operationele periode van het LSP, maar ‘optioneel’ wil zeggen: • een XIS mag het ondersteunen • maar het wordt pas op een later tijdstip onderdeel van de GBZ-toetsing • en het wordt pas dan ondersteund door het expertteam van NICTIZ.

- 40 -


HANDBOEK ICT-LEVERANCIERS IN DE ZORG

Recommend Documents