ARCHITECTUURONTWERP BASISINFRASTRUCTUUR IN DE ZORG

Transcriptie

1 ARCHITECTUURONTWERP BASISINFRASTRUCTUUR IN DE ZORG - Versie postadres: Postbus 262, 2260 AG Leidschendam bezoekadres: Overgoo 11, 2266 JZ Leidschendam telefoon: (070) ; fax: (070) ; info@nictiz.nl Status : Definitief Datum : 16 november 2005

2

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

4 (lokale, regionale of landelijke) centrale database. Een dergelijke database zal dan gaan fungeren als bronsysteem voor de desbetreffende patiëntgegevens. Daarnaast zijn er specifieke applicaties die gebruik maken van centrale opslag van gegevens. De architectuur is er op ingericht ook deze gegevens te ontsluiten. Uitgave, beheer en valideren van identiteitcertificaten van de zorgverleners, zorginstellingen en zorgsystemen vindt plaats met behulp van een landelijk centraal Unieke Zorgverleners Identificatie (UZI) -register. Voor het opzoeken en opslaan van patiëntinformatie wordt gebruik gemaakt van een unieke patiënt identificatie door middel van het landelijke Burger Service Nummer (BSN). Voor het snel vinden en toegankelijk maken van de gezochte informatie wordt gebruik gemaakt van een verwijsindex (een verwijsindex geeft aan waar bepaalde informatie ligt opgeslagen). Aan deze verwijsindex zijn de volgende functies gekoppeld: o authenticatie van de aanvragende zorgverlener, om te kunnen bepalen of hij daadwerkelijk degene is die hij beweert te zijn; o autoriseren van toegang tot de patiëntgegevens op basis van de functie van de aanvragende zorgverlener; o loggen van de aanvragen en antwoorden om de rechtmatigheid van aanvragen achteraf te kunnen controleren. Op technisch niveau zijn keuzen gemaakt die aansluiten bij bestaande praktijken voor uitwisseling van medische gegevens tussen zorgverleners. Daarbij wordt gekozen voor berichtuitwisseling op basis van HL7 versie 3 vanwege de groeimogelijkheden richting een EPD en de aansluiting bij internationale ontwikkelingen. Voor het transport van de berichten is gekozen voor Internettechnologie (XML/SOAP). Het op deze wijze uitwisselen van berichten met behulp van Internettechnologie, is gestandaardiseerd door het internationale standaardisatie-instituut W3C en wordt door alle grote leveranciers en systeemhuizen in de markt ondersteund. De beschrijvingsmethode die in dit document is toegepast is conform de beschikbare internationale standaard op dit gebied [1] en best practices op het gebied van architectuurmodellen. Inhoudelijk is het architectuurontwerp breed afgestemd met een veelheid van partijen binnen en buiten het zorgveld (Zie Bijlage B). - ii - Architectuurontwerp Basis Infrastructuur in de Zorg versie 4.2

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

6 Toevoegen van beschrijving van mogelijke koppeling met Landelijk Centrale Middelen Registratie van de Verslavingszorg in hoofdstuk Aanpalende domeinen (paragraaf 8.3). - iv - Architectuurontwerp Basis Infrastructuur in de Zorg versie 4.2

7 Documenthistorie Versie Datum Toelichting Discussiedocument juli 2002 Besproken op OIZ vergadering op 25 juli 2002 Discussiedocument september 2002 Op individuele basis besproken met groot aantal leveranciers en adviesbureaus Architectuurontwerp oktober 2002 Oplevering definitieve versie 1.0 aan OIZ Architectuurontwerp november 2002 Verwerken commentaar en vragen van diverse betrokkenen, o.a. OIZ Architectuurontwerp december 2002 Toevoegen aantal bijlagen met nadere detaillering Architectuurontwerp februari 2004 Integreren Document Zekerheidsstructuur, Verwerken ontwikkelingen standaardisatie, Consistent houden specificaties en Architectuur Architectuurontwerp oktober 2004 Inpassingen in relatie tot SBV-Z en het UZI-register, Alternatieve communicatiepatronen, Dienstenmodel met rollen LSP en ZSP, Diverse uitvoeringsvormen, Ondersteuning alle processen in de zorg, Portalvarianten, De meest recente internationale ontwikkelingen. Architectuurontwerp april 2005 Relatie met e-declareren, aanpassen terminologie architectuurmodel, verduidelijken aspecten van semantische interoperabiliteit, verduidelijken autorisatieprofiel, organisatorische aspecten, evolutie-aspecten naar een zorgbreed EPD, verduidelijken autorisatieprofiel, voorzieningen voor beheer, Koppeling van DCN en, relaties met aanpalende domeinen, weglaten van enkele informatieve (technische) bijlagen. Architectuurontwerp november 2005 Generieke beschrijving belanghebbenden, aangeven van relaties met het e- kinddossier (EKD) voor de jeugdgezondheidszorg, uitwerking van de eisen vanuit de patiënt, expliciteren dossieroverdracht, veronderstelde toestemming van de patiënt, Architectuurontwerp Basis Infrastructuur in de Zorg versie v -

8 voorbehouden handelingen, functionaliteit voor datamining, toevoegen OCSP, beschrijving van mogelijke koppeling met LCMR van de Verslavingszorg - vi - Architectuurontwerp Basis Infrastructuur in de Zorg versie 4.2

9 Inhoudsopgave 1 Inleiding Algemeen Doel van dit rapport Doelgroep Totstandkoming van dit rapport Architectuurinrichtingsproces 3 2 Uitgangspunten en randvoorwaarden Eisen aan de architectuurbeschrijving Uitgangspunten en randvoorwaarden bij de architectuurinvulling 5 3 Scope en ambitieniveau Scope Toekomstbeeld: e-zorg Ambitieniveau voor de architectuurbeschrijving 11 4 Beschrijvingsmodel Belanghebbenden Het architectuurmodel Afbakening van de architectuurbeschrijving Aspectgebied Beveiliging 15 5 De bedrijfsarchitectuur Ondersteuning van bedrijfsprocessen in de Zorg Communicatie in de zorgsector Casebeschrijvingen Eisen vanuit de patiënt Eisen vanuit de zorgprocessen Diensten van de basisinfrastructuur Organisatorische aspecten van de basisinfrastructuur Dimensioneringseisen voor de basisinfrastructuur Inrichtingsvragen Eisen aan de infrastructurele voorzieningen Infrastructurele voorzieningen voor beveiliging Voorzieningen voor beheer Eisen aan zorgsystemen 47 6 De informatie (systeem) architectuur Inleiding 50 Architectuurontwerp Basis Infrastructuur in de Zorg versie vii -

10 6.2 Semantiek en syntax Coderingsstelsels Identificatie Functionaliteit voor het bieden van generieke connectiviteit Functionaliteit voor het opvragen en verkrijgen van (patiënt) gegevens Functionaliteit voor het versturen van gegevens Functionaliteit voor dossieroverdracht Functionaliteit voor het abonneren op gegevens Functionaliteit voor het ondersteunen van semantische interoperabiliteit Functionaliteit voor ondersteuning van wetenschappelijk onderzoek, rapportage en beheer van volksgezondheid en beleidsvorming Beveiliging Invulling van gemeenschappelijke voorzieningen Interactieprincipes tussen zorgsystemen en infrastructurele voorzieningen 62 7 De technische architectuur Het servicemodel Relatie met het OSI-model Functionele modules, protocollen en koppelvlakken Invulling van de lagen Beveiliging, continuïteit en beheer Eisen aan beschikbaarheid, betrouwbaarheid en beveiliging van zorgsystemen (GBZ n) Invulling architectuurmodel 87 8 Aanpalende domeinen Inleiding e-declareren Landelijke Centrale (Opiumwet-)Middelen Registratie Patiëntenportaal Relatie met architectuur gegevensuitwisseling Uitvoeringsinstanties sociale zekerheid 94 9 Literatuur 96 BIJLAGE A: Afkortingenlijst 100 BIJLAGE B: Internationale ervaringen 102 BIJLAGE C: Consultatieproces viii - Architectuurontwerp Basis Infrastructuur in de Zorg v e r s ie 4. 2

11 1 Inleiding 1.1 Algemeen Een belangrijke voorwaarde voor efficiënte, betrouwbare en veilige informatieuitwisseling tussen (systemen van) zorgaanbieders 1 ter verbetering van kwaliteit en doelmatigheid van de zorg is de totstandkoming van een ICT-basisinfrastructuur in de zorgsector. Bovendien moeten zorgsystemen transmuraal met elkaar en met de infrastructurele voorzieningen kunnen communiceren. Om dit te bereiken is een gemeenschappelijk referentiekader noodzakelijk voor alle direct betrokkenen, met name voor ontwikkelaars van systemen en dienstverleners. Een architectuur levert dit referentiekader door de samenhang van en samenwerking tussen de ICT-voorzieningen in een transmurale context te beschrijven. 1.2 Doel van dit rapport In dit document wordt het architectuurontwerp van de basisinfrastructuur voor de zorg beschreven. Voor alle duidelijkheid wordt hier opgemerkt dat het document er niet op gericht is een allesomvattende architectuur van de informatievoorziening in de zorg te bieden. Het architectuurontwerp van de basisinfrastructuur beschrijft de samenhang van en samenwerking tussen de ICT-voorzieningen in een transmurale context. Dit document beperkt zich tot de hoofdlijnen en belangrijkste ontwerpbeslissingen. De nadere uitwerking vindt plaats in het document Specificatie van de basisinfrastructuur in de zorg, waarin de specificaties worden beschreven van de functionaliteit die in de basisinfrastructuur moet worden ingericht en van de berichten die via de infrastructuur worden uitgewisseld. In dit document wordt dus op hoofdlijnen beschreven hoe de architectuur moet worden vormgegeven om aan de gestelde eisen te kunnen voldoen. Het is daarmee een blauwdruk hoe de basisinfrastructuur er uit moet gaan zien. Dit wordt wel aangeduid met de term referentiearchitectuur. Daarnaast zullen aparte documenten verschijnen voor het beschrijven van berichten op basis van de internationale standaard HL7 versie 3 en voor de uitwerking van migratiescenario s hoe vanuit de huidige situatie een groeipad kan worden gecreëerd naar de in het architectuurontwerp beschreven situatie. De samenhang van dit document met de documenten die een verder uitwerking geven van het architectuurontwerp staat aangegeven in Figuur De term zorgaanbieder wordt gebruikt als een verzamelbegrip dat zowel de zorginstelling als de individuele zorgverlener omvat. Architectuurontwerp Basis Infrastructuur in de Zorg versie

12 Het architectuurontwerp dient dus als basis voor de verdere architectuuruitwerking en specificaties van de basisinfrastructuur in de zorg en is daarnaast bedoeld als een referentiemodel om de afstemming tussen betrokkenen binnen de zorg-ict-wereld richting te geven en te structureren. Architectuurontwerp Basisinfra Zorg Specificatie Basisinfra Zorg Programma van eisen LSP Programma van eisen GBZ Programma van eisen ZSP HL7 implementatie handleidingen Figuur 1-1: Relatie tussen documenten voor architectuur en specificaties 1.3 Doelgroep Dit document is primair geschreven voor architecten en inhoudelijk deskundigen op het gebied van ICT in de gezondheidszorg. De consequenties van de gekozen uitgangspunten en gemaakte keuzen hebben echter een dermate grote invloed op de inrichting en organisatie van ICT in de zorg dat het document ook van belang is voor bestuurders en beleidsmakers. 1.4 Totstandkoming van dit rapport In de afgelopen jaren zijn veel rapporten geschreven en experimenten uitgevoerd op het gebied van elektronische communicatie in de zorg. Op basis van de beschikbare Architectuurontwerp Basis Infrastructuur in de Zorg versie 4.2

13 informatie is een eerste architectuuraanzet opgesteld. Deze aanzet is in het veld getoetst. Daarbij is OIZ 2 als gesprekspartner namens de leveranciers opgetreden. Daarnaast hebben gesprekken plaatsgevonden met een groot aantal 3 leveranciers, adviesbureaus en partijen uit het zorgveld afzonderlijk. Deze gesprekken en de feedback van de OIZ hebben geleid tot een verdere optimalisatie van de architectuur. Er is bij de invulling van de architectuur gekozen voor een pragmatische en aanpak die op relatief korte termijn haalbaar is, waarbij wel rekening wordt gehouden met de wenselijkheid van nadere invulling op de lange termijn. Om niet te hoeven wachten op de resultaten van vaak meerjarige standaardisatie- en normalisatieactiviteiten, is ervoor gekozen om de reeds beschikbare kennis en ervaring uit eerdere projecten te benutten en zoveel mogelijk aan te sluiten bij praktijkervaring uit het veld en ontwikkelingen in de industrie, zowel nationaal als internationaal. Bovendien wordt zoveel mogelijk aangesloten bij reeds beschikbare en in de praktijk getoetste standaarden en normen. 1.5 Architectuurinrichtingsproces Een architectuur dient dusdanig te worden ontworpen dat rekening wordt gehouden met de toekomstig benodigde functionaliteit en capaciteit. In principe zouden alle mogelijke toepassingen (use cases) ter ondersteuning van zorgprocessen moeten worden geanalyseerd, om zo tot een allesomvattend eisenpakket voor de basisinfrastructuur te komen. In de zorg hebben we echter te maken met een sterk veranderend en nog nauwelijks gecoördineerd veld zodat het ondoenbaar is binnen afzienbare tijd tot een dergelijke allesomvattende analyse te komen. Bovendien brengt het breed trekken van een ontwerptraject en uitwerken van alle mogelijke use cases zowel qua tijd (lange doorlooptijd) als qua complexiteit risico s met zich mee. Veel projecten in de zorg zijn gestrand vanwege een te hoog ambitieniveau. Er is daarom gezocht naar een methode om breed te kijken naar mogelijke toepassingsgebieden en daar de basisinfrastructuur op in te richten zonder eerst alle toepassingen (use cases) in detail uit te werken. Daarbij ligt de focus op de gemeenschappelijke voorzieningen die minimaal noodzakelijk zijn. Om snel concrete doelen te kunnen bereiken is gekozen voor een aantal specifieke (start)applicaties dat gebruik maakt van de basisinfrastructuur: het e-medicatiedossier, e-waarneemdossier voor huisartsen en e-declareren. Zoals aangegeven brengt een dergelijke benadering ook risico s met zich mee omdat niet met 100% zekerheid kan worden vastgesteld dat aan alle mogelijke toekomstige eisen kan worden voldaan. De functies van de basisinfrastructuur zijn echter dermate generiek gekozen dat deze risico s minimaal zijn. 2 Vereniging van Organisaties voor ICT in de Zorg 3 Er hebben gesprekken met meer dan 30 partijen plaatsgevonden. Architectuurontwerp Basis Infrastructuur in de Zorg versie

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

15 2 Uitgangspunten en randvoorwaarden 2.1 Eisen aan de architectuurbeschrijving De architectuurbeschrijving van de basisinfrastructuur dient aan de volgende eisen te voldoen: 1. Het vormt een samenhangend geheel van principes, richtlijnen en modellen voor het ontwerpen van de voorzieningen in de basisinfrastructuur die zorgdragen voor informatie-uitwisseling tussen applicaties in zorgsystemen. 2. Het levert de kaders voor het opstellen van de specificatie van de functionaliteit die in de basisinfrastructuur moet worden ingericht en de berichten die via de infrastructuur worden uitgewisseld. 3. Het vormt de basis voor het ontwerp van toepassingen zoals het e-medicatiedossier, e-waarneemdossier en e-declareren. 2.2 Uitgangspunten en randvoorwaarden bij de architectuurinvulling Bij het ontwerp zijn de volgende uitgangspunten en randvoorwaarden gehanteerd: Er wordt gestreefd naar oplossingen die op draagvlak in het veld kunnen rekenen. Daarom is het ontwerp van de architectuur primair gebaseerd op de bestaande vertrouwenstructuren, autonomie en verantwoordelijkheden van patiënten, betrokken zorgverleners, organisaties en instellingen. Daarnaast is het draagvlak vanuit politiek en samenleving van belang. De kosteneffectiviteit van de oplossing is een belangrijk criterium voor het afwegen van alternatieven. Uitgangspunt is dat niet wordt gestreefd naar een technisch perfecte invulling, maar naar een betaalbare, werkende oplossing, die leidt tot een aanmerkelijke verbetering van de informatievoorziening van de zorgaanbieder en kan doorgroeien naar een brede ondersteuning van applicaties in het zorgveld. Er dient rekening te worden gehouden met de installed base van bestaande zorgsystemen. De informatie in deze systemen moet snel en zonder grote centrale investeringen toegankelijk gemaakt kunnen worden. De autonomie van de zorgverlener impliceert dat deze, binnen bepaalde randvoorwaarden t.a.v beveiliging, zijn ICT-voorzieningen naar eigen inzicht kan organiseren en dat hij zelf verantwoordelijk blijft voor het waarborgen van de integriteit en privacy van patiëntgegevens. Bij het ontwerp van de architectuur is zoveel mogelijk uitgegaan van de bestaande wet- en regelgeving. Het betreft hier met name de Wet op de Geneeskundige Behandelingsovereenkomst (WGBO) en de Wet Bescherming Persoonsgegevens (WBP). Patiënten dient overeenkomstig de WGBO in beginsel vooraf toestemming te worden gevraagd als hun gegevens aan derden worden verstrekt die niet rechtstreeks bij de behandeling zijn betrokken. Architectuurontwerp Basis Infrastructuur in de Zorg versie

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

17 3 Scope en ambitieniveau 3.1 Scope Begripsbepaling Een architectuurbeschrijving is bestemd om op een passend abstractieniveau te kunnen communiceren met relevante partijen. In dit document wordt gebruik gemaakt van de volgende definitie van architectuur uit IEEE Std [1]: de fundamentele organisatie van een systeem, uitgedrukt in zijn componenten, hun relaties onderling en met de omgeving, en de principes die het ontwerp en de evolutie ervan bepalen. Het begrip infrastructuur kan worden omschreven als: het geheel van permanent aanwezige gemeenschappelijke facilitaire voorzieningen. Voor bestuurders komen daar nog de aspecten van verantwoordelijkheid, financiering en besturing bij. In dit document wordt het begrip infrastructuur in de bestuurlijke betekenis gebruikt, namelijk een algemeen in de sector toegankelijk stelsel van gemeenschappelijke ICT-voorzieningen. Deze gemeenschappelijke voorzieningen kunnen tot stand komen doordat de bestuurlijke verantwoordelijkheid centraal is genomen. Dit kan zowel op regionaal als op landelijk niveau worden gerealiseerd Afbakening: basisinfrastructuur In dit document is gekozen voor de volgende afbakening: het architectuurontwerp richt zich primair op de voorzieningen in de basisinfrastructuur die zorgdragen voor informatie-uitwisseling tussen applicaties in zorgsystemen en op de interactie tussen die voorzieningen en de applicaties. Het kan hier gaan om applicaties die het primaire (zorg) proces ondersteunen maar ook gaan om logistieke en of financieel-administratieve applicaties. Het is geenszins de bedoeling één allesomvattende architectuur voor de zorg te beschrijven. De huidige situatie m.b.t. zorginhoudelijke patiëntinformatie in de zorg wordt weergegeven in Figuur 3-1. Een patiënt kan contact hebben met diverse zorgverleners, die gegevens opslaan in hun eigen informatiesystemen, in de figuur bijvoorbeeld aangeduid met ZIS (Ziekenhuis Informatie Systeem), HIS (Huisarts Informatie Systeem) of AIS (Apotheek Informatie Systeem). Als algemene term worden deze systemen wel XIS en genoemd. Daarnaast zijn in de zorg systemen in gebruik die niet direct zorginhoudelijke informatie bevatten, maar bijvoorbeeld financieel-administratieve 4 Voor een landelijke infrastructuur dient de bestuurlijke verantwoordelijkheid landelijk centraal te worden genomen, waarbij de uitvoering ook decentraal (d.w.z. regionaal) kan zijn belegd. Architectuurontwerp Basis Infrastructuur in de Zorg versie

18 gegevens. De overkoepelende verzamelterm voor alle systemen in de zorg is zorgsystemen. ZIS ZIS Spec. 1 HIS XIS Huisarts Paramed. ZIS Zkh Patiënt Verzekeraars Huisarts Huisarts Apoth. Apoth. HIS HIS AIS Figuur 3-1: Huidige situatie in de zorg v.w.b. zorginhoudelijke patiëntinformatie AIS = Apotheek Informatie Systeem HIS = Huisarts Informatie Systeem ZIS = Ziekenhuis Informatie Systeem XIS = Zorg Informatie Systeem Om alle zorgsystemen met elkaar te kunnen koppelen zijn infrastructurele voorzieningen noodzakelijk. Deze infrastructurele voorzieningen worden in dit document aangeduid met het begrip basisinfrastructuur. In voorliggend document wordt de architectuur van de basisinfrastructuur gepresenteerd. In de architectuur wordt de functionaliteit van de infrastructurele voorzieningen beschreven en de relaties aangegeven tussen zorgsystemen en infrastructurele voorzieningen, gedefinieerd op koppelvlakken zoals aangegeven in Figuur 3-2. De basisinfrastructuur voorziet in gemeenschappelijke, algemeen toegankelijke voorzieningen die minimaal noodzakelijk zijn om veilige en betrouwbare communicatie tussen zorgsystemen mogelijk te maken. Naast de minimaal noodzakelijke voorzieningen van de basisinfrastructuur kunnen aanvullende voorzieningen worden geboden die meerwaarde bieden aan zorgmedewerkers. Waar zinvol zal de architectuur-beschrijving ook ingaan op deze optionele voorzieningen Architectuurontwerp Basis Infrastructuur in de Zorg versie 4.2

19 Koppelvlakken ZIS ZIS Spec. 1 HIS XIS Huisarts Paramed. ZIS Zkh Patiënt Verzekeraars Huisarts Huisarts Apoth. Apoth. HIS HIS AIS Figuur 3-2: Basisinfrastructuur en koppelvlakken met XIS en De architectuurbeschrijving richt zich derhalve niet op de volgende aspecten: de interne werking van de aangesloten zorgsystemen (wel wordt ingegaan op de eisen die aan zorgsystemen worden gesteld om op de infrastructuur te kunnen worden aangesloten); de inhoudelijke definitie van de uit te wisselen informatie; de verdere detaillering van bedrijfsprocessen in de zorg; dit document beschrijft alleen die aspecten van deze processen, die nodig zijn voor de invulling van de basisinfrastructuur. 3.2 Toekomstbeeld: e-zorg Het toekomstperspectief is een situatie waarbij ICT bijdraagt aan een maximale ontplooiing van kwaliteit en efficiëntie in de zorg. Deze situatie wordt in dit rapport e- zorg genoemd. Het uitgangspunt van dit rapport is dat op termijn onder meer telemedicine, kennismanagement, kennissystemen voor diagnose, behandeling op afstand, ultiem geoptimaliseerde administraties, communicatie van en tussen patiënten, zorgverleners en zorginstellingen één werkend geheel kunnen vormen, dienstbaar aan kwaliteit en efficiëntie van de zorg. Om al deze zorggerelateerde processen te kunnen gaan ondersteunen, is een stelsel van algemeen toegankelijke en generieke ICT-voorzieningen onontbeerlijk: de basisinfrastructuur en een systeem van standaarden voor uitwisselen van gegevens, Architectuurontwerp Basis Infrastructuur in de Zorg versie

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

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

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

23 Het perspectief van de bestuurder Met de bestuurlijke druk de zorg goedkoper te maken is voor de bestuurder efficiëntie een belangrijk onderwerp. Potentiële winst wordt gezien in betere en efficiëntere ketenprocessen binnen en buiten de grenzen van een zorginstelling. Een EPD kan hiervoor een belangrijk hulpmiddel zijn. Een ander belangrijk thema is patiëntveiligheid. Waar vroeger medische fouten geaccepteerd werden, zie je tegenwoordig dat de stap naar de rechter (en nog belangrijker, de media) steeds makkelijker gemaakt wordt. Een EPD draagt aanzienlijk bij in de verbetering van patiëntveiligheid omdat bij behandeling alle informatie voorhanden is. Ook in het kader van aansprakelijkheid helpt een EPD, omdat alle behandelinformatie beschikbaar is voor alle partijen. De bestuurder heeft niet altijd belang bij deze transparantie omdat die ook eventuele fouten van zijn organisatie gemakkelijker inzichtelijk maakt voor andere partijen. Het perspectief van de informatiemanager De informatiemanager in zorginstellingen is ervoor verantwoordelijk de informatiehuishouding in het ziekenhuis op orde te houden en vormt vanuit zijn functie de intermediair tussen de gebruikers en de IT-afdeling. Hij zal zich bezighouden met eenduidigheid van vastlegging van informatie en vertalen van eisen en wensen van gebruikers en bestuurders naar functionele eisen die aan applicaties en infrastructuur moeten worden gesteld. Het perspectief van de dienstverleners en ontwikkelaars van zorgsystemen Vanuit dit perspectief wordt vooral gekeken naar de technische keuzen die ertoe moeten leiden dat kan worden voldaan aan de functionele eisen aan applicaties en infrastructuur. Hierbij moeten er afwegingen gemaakt worden ten aanzien van het gebruik van nieuwe technologie die wellicht meer mogelijkheden biedt, maar ook grotere risico s met zich mee brengt dan al langer bestaande oplossingen. 4.2 Het architectuurmodel Internationaal gezien bestaat er niet één geaccepteerd architectuurmodel. Derhalve is ervoor gekozen uit te gaan van een eenvoudig model, dat aansluit bij gangbare en praktische beschrijvingsmethodieken voor architectuur [52], [53],[61]. Ook in het overheidsdomein is dit een gebruikelijk model [50], [51]. Elke invalshoek is een beschrijving van aspecten die van belang zijn voor verschillende stakeholders: 1. Bedrijfsarchitectuur: beschrijving van de bedrijfsmatige, organisatorische aspecten en van de gerelateerde bedrijfsprocessen; Architectuurontwerp Basis Infrastructuur in de Zorg versie

24 2. Informatiesysteem-architectuur: beschrijving van de relevante aspecten van de informatiehuishouding, inclusief functionaliteit van applicaties en infrastructuurvoorzieningen m.b.t. de informatieverwerking; 3. Techniekarchitectuur: concrete benoeming van componenten en hun interacties (protocollen); beschrijving van applicaties, middleware, communicatie. B edrijfsarchitectuur Proces Informatie Informatie (systeem) architectuur Techniek Techniek architectuur Figuur 4-1: Beschrijvingsmodel De verschillende deelarchitecturen worden verder uitgewerkt in de hierna volgende hoofdstukken. Hoofdstuk 5 gaat in op de uitgangspunten voor de bedrijfsarchitectuur betrekking hebbend op de inrichting van de basisinfrastructuur en de eisen die moeten worden gesteld aan de infrastructurele voorzieningen en zorgsystemen. Op het niveau van de informatiesysteemarchitectuur gaat het over het vastleggen van de betekenis (semantiek) van gegevens en de methoden om de structuur van informatie (syntax) vast te leggen. Bovendien wordt de vereiste functionaliteit van applicaties en infrastructuurvoorzieningen m.b.t. de informatieverwerking beschreven. Zie daarvoor hoofdstuk 6. Op het techniekniveau gaat het over de concrete benoeming van componenten en hun interacties. Zie hoofdstuk Afbakening van de architectuurbeschrijving Het architectuurontwerp richt zich primair op de voorzieningen in de basisinfrastructuur die zorgdragen voor informatie-uitwisseling tussen applicaties in verschillende zorgsystemen en op de interactie tussen die voorzieningen en de applicaties die door zorgmedewerkers binnen instellingen en/of ICT-dienstaanbieders worden gebruikt. Dit betekent dat de architectuurbeschrijving zich vooral richt op de transmurale aspecten van ICT-ondersteuning van zorggerelateerde processen en de interactie met de instellingen. In Figuur 4-2 is dit primaire aandachtsgebied met een rode lijn aangegeven Architectuurontwerp Basis Infrastructuur in de Zorg versie 4.2

25 Bedrijfsarchitectuur Proces Inf-systeem architectuur Techniek architectuur Techniek Instelling Instelling (Enterprise) (Enterprise) Transmuraal (Extended Enterprise) Transmuraal (Extended Enterprise) Figuur 4-2: Primaire aandachtsgebied van de architectuurbeschrijving 4.4 Aspectgebied Beveiliging In alle drie de lagen van het beschrijvingsmodel is informatiebeveiliging van belang (zie Figuur 4-3). Bedrijfsarchitectuur Proces Informatiesysteemarchitectuur Techniekarchitectuur Beveiliging Figuur 4-3: Beveiliging in het beschrijvingsmodel Informatiebeveiliging in de zorg kan alleen goed worden ingevuld met een samenhangend pakket van maatregelen op het gebied van organisatie, bedrijfsprocessen, functionele eisen aan applicaties en infrastructurele voorzieningen en technische implementaties. In ieder van de drie hiernavolgende hoofdstukken is daarom aan dit onderwerp een paragraaf gewijd. Architectuurontwerp Basis Infrastructuur in de Zorg versie

26 Architectuurontwerp Basis Infrastructuur in de Zorg versie 4.2

27 5 De bedrijfsarchitectuur 5.1 Ondersteuning van bedrijfsprocessen in de Zorg De basisinfrastructuur moet er voor worden ontworpen om informatie en communicatiediensten te leveren om de bedrijfsprocessen in het zorgveld te ondersteunen. Het gaat hier om een veelheid aan processen. In figuur 5-1 wordt in een gelaagd zorgprocesmodel aangegeven welke typen processen in de zorg van belang zijn. Sturende processen Management, patiëntenlogistiek en procesbesturing etc. Primaire (zorg) processen Ondersteunende processen Financieel, administratief, goederenlogistiek etc. Figuur 5-1: Indeling van bedrijfsprocessen in de zorg Dit model kan bijvoorbeeld worden gebruikt om de processen in een zorginstelling te beschrijven. Naast het primaire (zorg-) proces is er in een zorginstelling een aantal sturende processen, bijvoorbeeld strategisch en tactisch management, patiëntlogistieke processen en (zorg-)procesbesturing. Daarnaast zijn er ondersteunende processen, zoals financiële en administratieve processen, goederenlogistiek etc. Zoals al in de inleiding aangegeven zal voor de beschrijving van de architectuur van de basisinfrastructuur geen detailanalyse van alle processen in de zorg worden uitgevoerd. In deze architectuurbeschrijving zal worden aangegeven welke functies minimaal in de basisinfrastructuur noodzakelijk zijn om het totaal van bedrijfsprocessen te ondersteunen. Door de vergaande specialisatie in de zorg, is in deze sector vanouds het samenwerken in ketens van groot belang. Dit belang neemt bovendien nog steeds toe. Deze samenwerking kan plaatsvinden op de diverse niveaus van het zorgprocesmodel, bijvoorbeeld samenwerkingsrelaties tussen huisarts en specialist. In figuur 5-2 is dit illustratief aangegeven voor twee zorginstellingen die in een zorgketen samenwerken. Architectuurontwerp Basis Infrastructuur in de Zorg versie

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

29 administratieve informatie-uitwisseling machtigingsberichten (een zorgverlener machtigen iets te doen), de melding van geleverde zorg en de opgave van productiegegevens zorg door instellingen (AWBZ). Daarnaast vindt ook uitwisseling van besturingsinformatie plaats, bijvoorbeeld de logistieke communicatie met betrekking tot de patiënt tussen en binnen instellingen. Als de patiënt van de ene naar de andere instelling gaat wordt hierover gecommuniceerd. Hetzelfde geldt bij doorverwijzing binnen een instelling naar een andere behandelaar of naar een onderzoeksafdeling (bloed, röntgen, enzovoort). Beleidsinformatie of managementinformatie betreft geaggregeerde informatie die niet tot fysieke personen herleidbaar is. Soms wordt deze informatie wel op individueel niveau verzameld (en vervolgens geanonimiseerd). De onderwerpen kunnen zowel medisch inhoudelijk als financieel-administratief zijn. Naast zorgverleners, instellingen en zorgverzekeraars verzamelen informatie-instituten, CVZ, VWS en brancheorganisaties beleidsinformatie. Hoewel bij beleidsinformatie niet de privacy van personen in het geding is, is deze informatie wel vaak van vertrouwelijke aard. 5.3 Casebeschrijvingen Inleiding Om snel concrete doelen te kunnen bereiken is gekozen voor een aantal specifieke (start)applicaties dat gebruik maakt van de basisinfrastructuur: e-medicatiedossier, e- waarneemdossier voor huisartsen en e-declareren. Deze applicaties zijn mede gebruikt om te toetsen of de opgestelde eisen van de basisinfrastructuur in de praktijk kunnen voldoen voor een aantal representatieve processen. Inmiddels heeft ook een uitwerking van het e-kinddossier voor de jeugdgezondheidszorg plaatsgevonden, waarvan de hoofdlijnen hieronder worden geschetst Case e-medicatiedossier Motivatie Uit een aantal onderzoeken is gebleken dat de kwaliteit van de zorg zal verbeteren door landelijke inzage in de medicatiehistorie van patiënten: Schattingen van het aantal ziekenhuisopnames door vermijdbare medicatiefouten lopen op tot per jaar met 300 miljoen aan directe kosten [56]; Als het elektronisch medicatiedossier straks goed functioneert, zullen er door het toepassen van medicatiebewaking aanzienlijk minder medicatiefouten worden gemaakt, zoals is aangetoond in internationale onderzoeken naar elektronisch voorschrijven [57]; Gebrekkige communicatie tussen zorgverleners is de oorzaak van veel medische fouten [58]. Architectuurontwerp Basis Infrastructuur in de Zorg versie

30 Casebeschrijving Een patiënt wendt zich met een verzoek tot een contact tot een zorgverlener. Dit contact kan telefonisch zijn of face-to-face. Tijdens het contact neemt de zorgverlener een anamnese af, doet eventueel onderzoek en komt op basis daarvan tot een werkdiagnose m.b.t. de door de patiënt aangegeven zorgvraag. De zorgverlener besluit tot al dan niet behandelen eventueel met ondersteuning van één of meer geneesmiddelen. Als (onderdeel van de) voorgenomen behandeling ontstaat bij de zorgverlener een voornemen tot het voorschrijven van één of meer geneesmiddelen aan de patiënt. Dit voornemen wordt (indien mogelijk) overlegd met de patiënt en getoetst aan het medicatiedossier en eventueel aan een elektronisch expertsysteem (beslissingsondersteuning). Bij deze toetsing vindt medicatiebewaking plaats, waarbij mogelijk signalering in het geval van ongewenste toepassing kan plaatsvinden. Hierop kan het voorschrift worden aangepast, eventueel op basis van een automatisch voorstel vanuit het EVS ( Elektronisch Voorschrijf Systeem). Een medicatiehistorie heeft altijd betrekking op één individuele patiënt en is opgebouwd of kan opgebouwd zijn uit: Voorschriften (al dan niet gestopt) Verstrekkingen (Toedieningen). Voor het verantwoord voorschrijven en verstrekken kan het ook nodig zijn over andere relevante informatie van de patiënt te beschikken zoals allergieën, contra-indicaties, de reden van voorschrijven etc. Sommige van deze informatie (zoals nierfuncties) is generieker van aard en vallen niet specifiek onder het kopje medicatiehistorie. Op dit moment is, behalve in ziekenhuizen, toedieningregistratie nog niet gebruikelijk. Indien de toediening in de toekomst wel systematisch wordt vastgelegd, zou deze informatie ook opvraagbaar kunnen zijn in de medicatiehistorie. Vooralsnog valt dit buiten de scope. Met het realiseren van het e-medicatiedossier worden alle gegevens waaruit een medicatiehistorie is opgebouwd in principe beschikbaar gesteld door opvraag uit de systemen waar deze informatie is opgeslagen. De ontvanger heeft na ontvangst nog de mogelijkheid de ontvangen gegevens te filteren Case e-waarneemdossier huisartsen Motivatie In waarneemsituaties heeft de waarnemende huisarts op dit moment in veel gevallen weinig tot geen informatie beschikbaar over de medische historie van de patiënt. Hieraan is wel veel behoefte omdat zo kwaliteitswinst en een verbeterde efficiëntie kan worden bereikt. Met name door de opkomst van centrale doktersposten, zogenaamde huisartsenposten (HAP s), ten behoeve van de avond-, nacht- en weekenddienst is de Architectuurontwerp Basis Infrastructuur in de Zorg versie 4.2