Aanbevelingen en kwaliteitscriteria voor ziekenhuisinformatiesystemen

Aanbevelingen en kwaliteitscriteria voor ziekenhuisinformatiesystemen (versie 1 december 2002) Prof. Dr. Bart Van den Bosch Prof. Erwin Bellon André De Deurwaerder Mark Vanautgaerden Dr. Marc Bangels

Inhoud 1 INLEIDING... 1 2 ARCHITECTUUR EN INTEGRATIE VAN HET ZIS... 3 2.1 INLEIDING... 3 2.2 DEFINITIES... 4 2.2.1 Geconnecteerde systemen... 4 2.2.2 Geïntegreerde systemen... 6 2.3 OPSPLITSEN VAN HET ZIS: INHOUDELIJKE OPTIES... 9 2.3.1 Per groep gebruikers... 9 2.3.2 Per dienst... 10 2.4 TECHNISCHE OPTIES VOOR DATA-UITWISSELING... 12 2.4.1 Syntax en standaarden voor data-uitwisseling... 13 2.4.2 Bedrijfszekerheid van de connectie... 14 2.4.2.1 Onafhankelijkheid van verzender, ontvanger en transferproces... 14 2.4.2.2 Gegarandeerde aflevering... 15 2.4.2.3 Herstartprocedure... 15 2.4.2.4 Transacties... 16 2.4.3 Centraal knooppunt... 16 2.4.3.1 Interface engine... 17 2.4.3.2 Message broker... 17 2.4.4 Datareplicatie: inhoudelijke opties... 18 2.4.4.1 Master slave... 19 2.4.4.2 Routeringsregels... 19 2.4.4.3 Synchroniseren van verschillende datakopieën... 20 2.4.4.4 Implicaties van datareplicatie op toegangscontrole... 20 2.5 RESULTATENSERVER... 21 2.5.1 Implicaties op toegangscontrole... 21 2.6 COMPONENT INTEGRATIE... 22 2.6.1 Back end componenten... 24 2.6.2 Front end componenten... 24 2.6.3 Samenwerkende toepassingen als alternatief voor front end componenten - CCOW... 24 3 INHOUDELIJKE STRUCTUUR... 26 3.1 DATA ORGANISATIE... 26 3.1.1 Patiëntennummer... 26 3.1.1.1 Beheer... 26 3.1.1.2 Uniciteit van het patiëntennummer... 27 3.1.2 Coderingen... 28 3.1.3 Structurering... 30 3.2 FUNCTIONALITEIT...30 3.2.1 Afsprakenbeheer... 30 3.2.2 Resultatenbeheer... 32 3.2.3 Aanvraag- en registratiesysteem... 32 3.2.4 Medicatie voorschrift en toediening... 34 i

3.2.4.1 Verbruik... 34 3.2.5 Patiëntenbewegingen... 34 3.2.6 Facturatie... 35 3.2.7 Probleemlijst en progress notes... 35 4 BESCHIKBAARHEID VAN HET COMPUTERSYSTEEM... 36 4.1 OORZAKEN VAN ONBESCHIKBAARHEID... 36 4.2 TECHNIEKEN OM DE ONBESCHIKBAARHEID TE BEPERKEN... 37 4.2.1 Backup... 37 4.2.2 Hardware redundantie... 39 4.2.3 Onderhoudscontracten... 40 4.2.4 Cluster... 40 4.2.5 Replication server... 40 4.2.6 Inrichting computerruimtes... 41 4.2.7 UPS, noodstroom voor infrastructuur buiten de computerruimtes... 42 4.3 REDUNDANTIECRITERIA VOOR EEN ZIEKENHUIS... 42 5 ARCHIVERING... 44 5.1 FYSISCHE PROBLEMEN... 44 5.2 LOGISCHE PROBLEMEN... 44 6 BEVEILIGING... 46 6.1 TOEGANGSCONTROLE... 46 6.2 AUTHENTICATIE... 46 6.2.1 Basistechnieken... 46 6.2.2 Discipline bij authenticatie... 47 6.2.2.1 Stimuleren van discipline bij authenticatie met paswoorden... 48 6.2.2.2 Stimuleren van discipline door keuze van de authenticatietechnieken... 49 6.2.2.3 Uitreiken van nieuwe of vernieuwde authenticatiemiddelen... 49 6.2.2.4 Reageren op inbraakpogingen... 50 6.2.3 Welke authenticatie technieken gebruiken voor een ZIS?... 50 6.2.4 Individuele gebruikersnamen... 51 6.3 AUTORISATIE... 51 6.4 BEHEER VAN GEBRUIKERS... 52 6.5 AUTOMATISCH VERGRENDELEN VAN EEN SESSIE BIJ INACTIVITEIT... 53 6.6 AUDITING... 53 6.7 ENCRYPTIE EN DIGITALE HANDTEKENING... 54 6.7.1 Symmetrische encryptiealgoritmes... 54 6.7.2 Public-private key algoritmes... 55 6.7.3 Certificaten... 55 6.7.4 Hashing technieken... 56 6.8 VIRUSSEN, WORMEN EN TROJAANSE PAARDEN... 56 6.9 FYSISCHE TOEGANG TOT COMPUTERSYSTEMEN... 57 6.10 DIEFSTAL VAN LAPTOPS... 57 6.11 TOEGANG VOOR ONDERSTEUNING VAN TOESTELLEN.... 57 6.12 INTERNET TOEGANG... 58 6.13 VIRTUELE PRIVÉ NETWERKEN... 59 6.14 TOEGANGSCONTROLE OP TOEPASSINGSNIVEAU... 59 ii

6.14.1 Authenticatie... 59 6.14.2 Autorisatie... 60 6.14.3 Audit... 62 6.14.3.1 Beleid... 62 6.14.3.2 Audit per patiënt... 62 6.14.3.3 Audit per gebruiker... 63 6.14.3.4 Audit per actie... 63 6.14.3.5 Controleren van de gelogde informatie... 63 7 AANDACHTSPUNTEN BIJ HET PROJECTBEHEER... 65 8 PACS PICTURE ARCHIVING AND COMMUNICATION SYSTEMS... 68 8.1 INDIVIDUELE ASPECTEN VAN EEN PACS... 68 8.1.1 Archivering van de beelden... 68 8.1.1.1 Dimensionering van het archief... 68 8.1.1.2 Hierarchische organisatie van het archief... 70 8.1.1.3 Symmetrie in de toegang tot het archief... 71 8.1.1.4 Backup en continuiteit van werking... 71 8.1.1.5 Consolidatie van opslagnoden... 73 8.1.2 Distributie van radiologische beelden doorheen het ziekenhuisnetwerk... 73 8.1.3 Koppelen van de beeldvormende toestellen... 73 8.1.4 Viewing voor primaire diagnose... 75 8.1.5 Viewing doorheen de kliniek... 78 8.2 INTEGRATIE VAN PACS IN DE GEHELE INFORMATICA-OPLOSSING... 79 8.2.1 Back office integratie van PACS in het overkoepelende informatiesysteem... 79 8.2.2 Front office integratie van PACS in een overkoepelende gebruikersinterface... 82 8.2.3 Informatie-uitwisseling met de beeldvormende toestellen... 84 8.2.4 Correctie van fouten in het PACS... 87 9 TELEMATICA... 88 9.1 BEVEILIGING BIJ TELEMATICA... 88 9.1.1 Definiëren van verantwoordelijkheden... 88 9.1.2 Beveiligen van de communicatie... 89 9.1.3 Authenticatie van de gebruikers... 89 9.1.4 Inperken van bedrijfslogica in de client-software... 90 9.1.5 Gedetailleerde toegangsregels en externe artsen... 91 9.2 TECHNOLOGIE VOOR TELE-INTERACTIE TUSSEN PERSONEN... 91 9.2.1 Video conferencing... 92 9.2.2 Data conferencing... 94 9.2.3 Delayed time interactie door uitwisselen van bestanden... 95 9.3 TELE-KOPPELING VAN EN TELE-TOEGANG TOT MEDISCHE DOSSIERS... 95 9.3.1 Uitwisselen van informatie tussen onafhankelijke medische dossiers... 96 9.3.1.1 Organisatorische uitdagingen... 96 9.3.1.2 Architectuur en technologie voor communicatie... 97 9.3.2 Interactieve tele-toegang tot het dossier binnen een ziekenhuis... 98 9.3.2.1 Organisatorische uitdagingen... 99 9.3.2.2 Technologie voor interactieve tele-toegang... 100 9.3.3 Het delen van een centraal dossier tussen onafhankelijke zorgenverstrekkers... 101 9.3.3.1 Technische en organisatorische uitdagingen... 102 iii

iv

1 Inleiding Deze tekst heeft tot doel een aantal aanbevelingen en eerste aanzet tot kwaliteitscriteria voor ziekenhuisinformatiesystemen aan te reiken. Een ziekenhuisinformatiesysteem is een zeer complex systeem waarbij alle aspecten van de informatica betrokken zijn. Het is onmogelijk al deze aspecten aan bod te laten komen in één tekst. We beperken ons dan ook tot bepaalde deelaspecten die o.i. in min of meerdere mate specifiek zijn voor de ziekenhuissector. Strikt genomen bestaat medische informatica niet. Er bestaat alleen de toepassing van informatica in de medische sector. Sommige informaticatechnieken komen daar meer voor dan in andere sectoren en sommige problemen (zoals b.v. beeldopslag en -distributie) krijgen andere accenten dan in de meeste businesstoepassingen. Veel ziekenhuizen hebben een managementstructuur die grondig verschilt van deze in de meest bedrijven: hoewel de verschillende medische diensten sterk samenwerken hebben ze een vergaande autonomie. Dikwijls kan in een ziekenhuis elk departement zijn eigen informaticastrategie voeren, daar waar dit in het bedrijfsleven meestal centraal bepaald wordt. Dit heeft zijn invloed op de problemen en mogelijke oplossingen ervan. In deze tekst hebben we geprobeerd aandachtspunten aan te duiden en een generieke aanpak voor te stellen die rekening houdt met deze specifieke situatie. We beperken ons tot die technische en architecturale keuzes die niet louter en alleen door technici kunnen gemaakt worden, maar die ook door het management moeten gedragen worden omdat ze invloed hebben op de werking van het ziekenhuis, de mogelijke (elektronische) interacties tussen diensten, de beveiligingsstrategie, de toegangscontrole, de uitbreidbaarheid van het systeem,. Verder richten we ons vooral op de problemen en keuzes die gemaakt moeten worden rond de implementatie en integratie van de klinische systemen. Deze worden sterk beïnvloed door het feit dat er hier een zeer strikte authenticatie nodig is, terwijl juist voor deze toepassingen toegangscontrole en toegangscontroleregels ongebruikelijk complex zijn. Voor administratieve systemen is de situatie niet alleen eenvoudiger, maar ook minder specifiek zodat er meer expertise kan gevonden worden bij het interne management als bij eventuele externen die de implementatie verzorgen. We willen geen minimumnormen definiëren voor de inhoud van het medisch dossier. Daarvoor verwijzen we naar het KB van 3 mei 1999 dat al minima oplegt. Het is niet aan de auteurs van deze tekst om prioriteiten te definiëren voor de verdere uitbouw van het medisch dossier. Wat optimaal en pragmatisch haalbaar is voor één ziekenhuis is voor een ander ziekenhuis zeer moeilijk implementeerbaar. We verwijzen wel naar integraties die o.i. gewenst of zelfs onmisbaar zijn, indien men besluit bepaalde modules te ontwikkelen of aan te kopen. 1

De tekst probeert genuanceerd weer te geven welke maatregelen strikt vereist zijn en welke gewenst, of aan te raden. We hebben er niet voor geopteerd een strikte normenlijst uit te schrijven. Een normenlijst zou natuurlijk kunnen leiden tot een strikte scoring van ziekenhuisinformatiesystemen maar het leek ons schier onmogelijk één zinnige relatieve scoring te maken van zowel technische, inhoudelijke, integratie-, beveiligings-, en managementaspecten van een ziekenhuisinformatiesysteem zonder eerst alle criteria exhaustief benoemd en beschreven te hebben. Vermits dit laatste ons onmogelijk leek, hebben we ons aan een kwalitatieve beschrijving gehouden. De tekst is dus ook geen exhaustieve behandeling van alle mogelijke opties die men moet nemen bij de implementatie van een ziekenhuisinformatiesysteem. Het is eerder een verzameling best practices en een aantal pragmatische aanzetten tot oplossing die als bedoeling heeft veel voorkomende problemen te structureren en het management zo te helpen bij het opstellen van het informaticamasterplan en de implementatie van het ziekenhuisinformatiesysteem. Aanbevelingen met deze stijl beschouwen we als heel belangrijk en strikt noodzakelijk. Aanbevelingen met deze stijl zijn in mindere mate belangrijk en kan men in tweede instantie overwegen. 2

2 Architectuur en integratie van het ZIS 2.1 Inleiding De architectuur van het ziekenhuisinformatiesysteem bepaalt mee de mogelijkheden en beperkingen van het systeem. Verschillende aspecten van een ziekenhuisinformatiesysteem worden beïnvloed door de architectuur: Toegangscontrole Migratie van toepassingen en systemen Performantie Toepassingsintegratie en workflow opvolging Gegevensopslag De architectuur wordt niet louter door technische factoren bepaald maar ook door hoe het systeem historisch gegroeid is en vooral door de structuur en het niveau van de integratie van het management. Om een geïntegreerd informaticasysteem te bouwen, moet er een eenduidige visie zijn op die architectuur en een eenduidige leiding om die visie te implementeren. In veel ziekenhuizen is het (medisch) beleid echter gedecentraliseerd. Men heeft meestal wel een centraal beleid voor de administratieve en logistieke ondersteuning maar het medisch beleid wordt volledig decentraal door de verschillende diensten (specialismen) aangestuurd. Het gevolg hiervan is dat we dikwijls wel een geïntegreerd patiëntmanagementsysteem zien en een geïntegreerde facturatie, maar verscheidene medische subsystemen waarover het medische dossier van de patiënt verdeeld is. De internist werkt met een ander pakket dan de chirurg, de neuroloog heeft weer iets anders etc Diensten als Apotheek, Radiologie of andere functiemetingen gebruiken meestal zeer sectorspecifieke software. Het systeem groeit dan door aankoop of uitbouw van modules zonder dat er voorafgaandelijk een globale architectuur uitgedacht werd. Integratie moet achteraf gerealiseerd worden en is daardoor duurder en moeilijker. Omdat de diensten ook financieel onafhankelijk zijn en eigen budgetten hebben, moet men dan ook nog onderhandelen met de verschillende diensten om hen te overtuigen de nodige budgetten voor integratie vrij te maken. Het feit dat de managementstructuren zo uitgebouwd werden heeft uiteraard te maken met de manier waarop de overheid de ziekenhuizen financiert. Dit is nu eenmaal een realiteit en bij het uittekenen van de architectuur van het ziekenhuisinformatiesysteem moeten we hiermee rekening houden: het heeft geen zin een niveau van integratie voorop te stellen dat managementbeslissingen vraagt die niet kunnen genomen worden omdat er geen managementstructuur is die de autoriteit heeft om ze te nemen. M.a.w.: het niveau van integratie van het informaticasysteem is geplafonneerd door het niveau van integratie van het management. 3

Als men bij het uittekenen van het globale informaticamasterplan hier rekening mee houdt, kan men ook de verwachtingen van de gebruikers bijstellen. Door de diensten te informeren over de consequenties van hun keuze voor een of ander subsysteem, kan men eventueel toch nog een aantal integratieopties openhouden. Zelfs als men met verschillende subsystemen werkt zijn er nog een aantal integratieopties die kunnen genomen worden. We beschrijven eerst een aantal basisarchitecturen en de voor- en de nadelen van deze architecturen. Daarna beschrijven we een aantal mogelijke integratie- en connectietechnieken. In het informaticamasterplan moet een hoog niveau architectuur gekozen worden waarin de integratie van de verschillende subsystemen beschreven staat. Het plan beschrijft de informatiestromen en de integratietechnieken op een hoog niveau. Indien de gemaakte keuzes bepaalde opties van samenwerking uitsluiten, moeten die worden vermeld. 2.2 Definities We bespreken eerst een aantal conceptuele basisarchitecturen en introduceren enkele termen om de verdere discussie te vergemakkelijken. De opdeling die we geven is zeker niet absoluut: het zijn types van architecturen maar daartussen ligt een continuüm. Een ziekenhuisinformatiesysteem zal meestal een combinatie van deze types zijn. Er is ook geen standaardisatie in de benaming van deze types. In andere teksten kan de terminologie dus verschillen. 2.2.1 Geconnecteerde systemen Een geconnecteerd systeem bestaat uit verschillende aparte subsystemen die met data connecties met elkaar verbonden zijn. Data wordt dus van één systeem naar een ander getransporteerd. Dit kan op 2 manieren: door online opvragen of door datareplicatie. Bij online opvragen zal systeem A indien er gegevens nodig zijn uit systeem B deze daar ophalen op het moment dat A ze nodig heeft. De gegevens worden alleen verwerkt op A, niet opgeslagen. Als A dezelfde gegevens later opnieuw nodig heeft zal A die dan weer opvragen. A gedraagt zich als een client en B is de server. 4

Bij datareplicatie zal A op regelmatige tijdstippen gegevens ophalen uit B en lokaal opslaan. Het kan ook dat B regelmatig of continu zijn gegevens doorstuurt naar A. De gegevens van B worden dus redundant op A bewaard. Datareplicatie heeft als voordeel performantie: de data zijn op het tweede systeem lokaal beschikbaar wat bevraging daar veel sneller maakt. Anderzijds moet men voor kopiebeheer zorgen (zie p 18). Indien verschillende subsystemen dezelfde functionaliteit herimplementeren spreken we van functiereplicatie. Voorbeeld: stel dat de dienst Inwendige en Chirurgie verschillende informaticasystemen hebben. In beide werd volgens de wensen van de dienst Radiologie een Radiologie-aanvraagmodule geïmplementeerd. Dit is functiereplicatie. De logica achter de aanvraagmodule moest namelijk in 2 verschillende systemen aangemaakt worden. Functiereplicatie is duur en gebeurt zelden maar is soms noodzakelijk. Soms volstaat het niet om alleen de data te repliceren naar een ander systeem maar moet men daar ook programma s toevoegen om deze data te bekijken en/of te manipuleren. Gegeven dat men verschillende systemen connecteert, kan men hier ook een onderscheid maken tussen ad hoc connecties en connecties via een centraal knooppunt. Ad hoc connecties hoeven niet veel definitie: in dit geval verbindt men 2 subsystemen rechtstreeks met elkaar. Als men met een centraal knooppunt werkt, dan worden alle subsystemen met dit knooppunt verbonden. Het knooppunt regelt ook meestal het verkeer tussen de subsystemen en treedt meestal op als een soort triëerstation. Radiologie Inwendige Dermato Chirurgie Apotheek Data connectie. Ad hoc protocol, HL/7 connectie of andere. Figuur 1: Ad hoc geconnecteerde systemen 5

2.2.2 Geïntegreerde systemen In een geïntegreerd systeem ziet de gebruiker één systeem van met elkaar interagerende deeltoepassingen. De mate en complexiteit van die interactie kan sterk variëren. Een geïntegreerd systeem kan monolithisch zijn of componentgeoriënteerd. In een monolithisch systeem is alles gemaakt door één fabrikant en is de integratie meestal zeer hoog. De deeltoepassingen gaan naadloos in elkaar over en de gebruiker heeft het gevoel met één grote toepassing te werken. Het voornaamste nadeel is dat zelden één fabrikant er in slaagt een bevredigende oplossing te vinden voor alle deelsystemen. Een ander nadeel is vendor lock in. Het ziekenhuis wordt sterk afhankelijk van die fabrikant en de toepassingen die door deze fabrikant ondersteund worden. In een componentgeoriënteerd systeem zijn de verschillende deeltoepassingen door verschillende fabrikanten gemaakt maar interageren ze met elkaar door elkaars functies te gebruiken. De gebruiker zal meestal wel verschillen in stijl merken tussen de deeltoepassingen omdat ze allen een verschillende oorsprong hebben. Het systeem gedraagt zich echter wel als één geheel. Verschil tussen functiereplicatie en componentoriëntatie Het verschil met functiereplicatie is dat in een componentgeoriënteerd systeem één component de functie implementeert maar deze in verschillende subsystemen gebruikt Radiologie Inwendige Interface engine (HL/7) of Message broker Dermato Chirurgie Apotheek Figuur 2: connecteren via centraal knooppunt 6

wordt. De functie is gegarandeerd op een consistente manier geïmplementeerd doorheen het hele systeem. De programmacode die de functielogica implementeert bestaat maar op één plaats en als ze moet aangepast worden moet dit dus ook maar op één plaats gebeuren. Bij functiereplicatie daarentegen zal men de functielogica telkens opnieuw herimplementeren in het doelpakket. Er bestaan dus verschillende implementaties van dezelfde functielogica en meestal ook in verschillende technologieën. Dit is duur in ontwikkeling én in onderhoud. Elke aanpassing moet ook door de verschillende partijen doorgevoerd worden. Het gevaar bestaat dat niet alle subsystemen op exact dezelfde manier de logica implementeren. Back end en front end componenten Componentintegratie kan zowel front end als back end gebeuren. Front end componenten zijn aparte onderdelen waaruit een toepassing gemaakt werd op de front end (client) en die mogelijks elk hun eigen back end systeem hebben. Zo kan men een component hebben voor het presenteren van uitgevoerde radiologieonderzoeken en radiologische verslagen, welke deze gegevens uit een eigen radiologiedatabase haalt maar die als gehele component toch ingebouwd is in de user interface van de toepassing die het Medical file application Patient admission discharge transfer Pat ID Appointment scheduler ID info RX System Appointment server Patient admin DB RX system Figuur 3: front end componenten 7

gehele medische dossier presenteert. Back end componenten worden meestal op een middenlaag geïmplementeerd in een zogenaamde 3 lagen architectuur. De derde laag zorgt dan meestal voor de persistentie van de data. Deze architectuur wordt zeer veel gebruikt in internet toepassingen waar men geen controle heeft (of wil hebben) over de front end systemen en daarom alle business logica implementeert in een middenlaag. De middenlaag levert diensten naar verschillende front end toepassingen toe. Het grote voordeel is dat de businesslogica maar op één plaats moet onderhouden worden. Men kan ze ook wijzigen zonder aanpassingen aan de client toepassingen te moeten doorvoeren zolang men de interface naar de clients niet wijzigt. Zo kan voor toegang via het Internet een andere front end worden gebouwd dan voor gebruik binnen de instelling (zie p. 100) Bovenstaande termen geven een aantal types weer. Binnen elk van deze types zijn er verschillende varianten. Toepassing 1 Wireless Toepassing 2 Toepassing Geimplementeerd op applicatie servers type J2EE,.NET of servlets. Meerdere middellaag servers mogelijk. Middle tier Middle tier RX aanvraag RX rapportering Afspraken Patient admin Medicatievoorschrit RX system Patiënt admin Apotheek Figuur 4: Back end componenten 8

2.3 Opsplitsen van het ZIS: inhoudelijke opties Het management moet in het informaticamasterplan een aantal integratiekeuzes maken. Zoals hoger gezegd beïnvloedt de architectuur van het systeem wat gemakkelijk of moeilijk is om te realiseren met het systeem. Het management moet dus enerzijds rekening houden met de beperkingen die uit de architectuur van het ziekenhuisinformatiesysteem voortkomen, anderzijds kan ze proberen de architectuur aan te passen aan de doelstellingen die ze wil realiseren. Tenzij men kiest voor een monolithisch systeem van één fabrikant, zal het management steeds de keuze moeten maken op welke manier men het systeem opsplitst in beheersbare delen die als bouwstenen van het ziekenhuisinformatiesysteem zullen dienen. Dit neemt men best op in het informaticamasterplan, evenals de aanpak om deze bouwstenen met elkaar en de reeds geïmplementeerde systemen te verbinden volgens één van bovenvermelde technieken. De verschillende delen van het ziekenhuisinformatiesysteem kunnen dan onafhankelijk van elkaar aangekocht of ontwikkeld worden. Hoe men het systeem functioneel opdeelt staat los van de technische opties die men neemt om de verschillende onderdelen te integreren. We bespreken nu een aantal basisopties die kunnen genomen worden i.v.m. de opdeling van het systeem, en gaan daarna in op technieken voor integratie. 2.3.1 Per groep gebruikers Men zou het systeem kunnen opdelen per groep gebruikers. M.a.w. elke groep heeft een eigen dossier. Men spreekt soms van een medisch dossier en een verpleegkundig dossier. Het eerste wordt door de artsen gebruikt, het tweede door de verpleging. Soms voegt men er nog een derde dossier aan toe: het sociaal dossier. Voordelen Het voornaamste voordeel in deze aanpak is dat men meestal wel één verpleegkundig dossier door heel het ziekenhuis kan uitrollen, terwijl het moeilijker is om consensus te krijgen over één medisch dossier(pakket) omwille van de grote technische verschillen tussen de specialisaties. Men kan daardoor soms sneller aan de informatisering van het verpleegkundige werk beginnen. 9

Nadelen Het is echter een zeer groot nadeel om de verpleegkundigen en de artsen op twee of meer verschillende systemen onder te brengen die dan weer met elkaar moeten geïntegreerd worden. Vermits er zeer veel en frequente informatieoverdracht nodig is tussen verpleegkundigen en artsen, zijn er veel (data) koppelingen nodig tussen beide systemen. Vermits dit vrij duur is, gebeurt het dus maar in beperkte mate en verliest men aan functionaliteit. Zonder zware integratie of connectie-inspanning kan men in een dergelijk systeem moeilijk workflow implementeren. Indien men opteert voor een opsplitsing per groep gebruikers zal de connectie tussen het medisch en het verpleegkundig systeem zeer performant moeten zijn omdat de meeste workflows verschillende keren de grens van deze systemen oversteken. Men kan dan best op database niveau integreren, waarbij het ene systeem rechtstreeks de database van het andere ondervraagt (client server) ofwel kiezen voor een uitgebreide datareplicatie met redundante opslag van de data die nodig is in de workflow(s). 2.3.2 Per dienst Sommigen opteren om een patiëntdossier per specialisme (groep) op te zetten. Verpleging en artsen van eenzelfde dienst werken in één systeem maar men heeft verschillende pakketten per specialisme: Inwendige Geneeskunde, Gynaecologie, Heelkunde, Algemeen Inwendige Cardiologie Abdominale heelkunde Dermatologie Anesthesiologie Medisch dossier Verpleegkundig dossier S` Administratief systeem Figuur 5: Opdeling per groep 10

Algemeen Inwendige Cardiologie Abdominale heelkunde Dermatologie Anesthesiologie Dossier Pakket A Dossier Pakket B Dossier Pakket C Anesthesie/ pre-op bewaking Administratief systeem Figuur 6: opdeling per specialisme Voordelen Specificiteit. Een voordeel van deze aanpak is dat men een zeer specifiek systeem kan kiezen per afdeling. Vooral voor de meer technische afdelingen kan een algemeen systeem ontoereikend zijn. In de praktijk evenwel zien we dat een dergelijke opdeling gewoonlijk niet gemaakt wordt vanuit deze motivatie, maar doordat elk van deze diensten een volledig autonoom management heeft en zonder overleg een systeem kiest. Beheersbaarheid. Vooral als men niet al te hecht wenst te integreren heeft men het voordeel van beheersbaarheid. Elk van de systemen kan apart aangepast of gemigreerd worden zonder al te veel hinder voor de anderen. Nadelen Fragmentatie. In een dergelijke aanpak wordt het medisch dossier van de patiënt gefragmenteerd opgeslagen. Meestal hebben de zorgverstrekkers van één dienst geen toegang tot het pakket van de andere dienst. Dure integratie. De integratie is duur, en als men de systemen sterk integreert vervallen een deel van de hierboven vermelde voordelen. Als men bij voorbeeld order entry wil implementeren zal men al snel functiereplicatie nodig hebben. 11

Algemeen Inwendige Cardiologie Abdominale heelkunde Dermatologie Anesthesiologie Dossier Pakket A Dossier Pakket B Dossier Pakket C Anesthesie/ pre-op bewaking Verpleegkundig dossier Administratief systeem Figuur 7: Combinatie van opdeling per groep en per specialisme Meerdere user interfaces. Als personeelsleden op verschillende diensten werken, worden zij met verschillende user interfaces geconfronteerd. Dit kan een probleem zijn voor assistenten in een opleidingsziekenhuis maar ook voor verpleegkundigen die roteren. De meeste ziekenhuisinformatiesystemen zijn combinaties van bovenstaande opdelingen (zie Figuur 7). 2.4 Technische opties voor data-uitwisseling Bij het opzetten/plannen van data-uitwisseling tussen verschillende systemen zou voor elk van de connecties volgende punten moeten gedefinieerd worden: Syntax voor data uitwisseling Welke maatregelen er genomen worden om de bedrijfszekerheid en de correcte werking van de connectie te garanderen o Hernemen van de datareplicatie na downtime van een van de systemen o Transactiebewaking Performantievereisten 12

2.4.1 Syntax en standaarden voor data-uitwisseling HL/7 Er zijn zeer vele standaarden gedefinieerd voor data uitwisseling in de medische informatica maar weinigen worden ook daadwerkelijk op grote schaal gevolgd door fabrikanten. Een van de weinigen die wereldwijde commerciële navolging kent is HL/7 (Health Level 7). Zelfs met HL/7 wordt plug-and-play nog maar benaderd tot op het niveau van plugand-pray. Er zijn kleine en grote dialectverschillen die maken dat het opzetten van een HL/7 connectie toch snel enkele manweken vraagt. Voor uitwisseling van diagnostische beelden en gerelateerde informatie wordt de DICOM standaard algemeen aanvaard (zie p. 73). Er is een verschil tussen een syntax (en een protocol) voor communicatie en een standaard. De syntax legt de manier vast om gegevens in het bericht te coderen en het protocol de techniek om ze naar de communicatiepartner te krijgen, terwijl de standaard de betekenis vastlegt. De HL/7 standaard is uitbreidbaar dwz dat de boodschap met user segmenten kan aangevuld worden waarin men data kan plaatsen die (nog) niet in de standaard opgenomen werden. In feite gebruik je HL/7 dan louter als een techniek voor communicatie van gegevens waarover je toch apart afspraken moet maken (wat uiteraard een voordeel is als je die techniek toch reeds nodig hebt). XML Een opkomende syntax is XML, en een gerelateerd communicatieprotocol is SOAP. Deze zullen belangrijk worden, maar ze vervangen geen standaard. Als twee systemen XML ondersteunen mag men daar niet uit afleiden dat ze berichten met elkaar kunnen uitwisselen (en verwerken). XML bepaalt alleen de syntax van het bericht maar nog niet de structuur en de betekenis van de elementen in die structuur. XML wordt algemeen ondersteund door de hele computerindustrie. XML zal dan ook de syntax worden waarboven de standaarden geïmplementeerd zullen worden. Latere versies van HL/7 zullen XML gebaseerd zijn. De betekenis en structuur van het bericht en de items erin worden bepaald door het HL/7 consortium. Als men een koppeling maakt tussen twee of meer systemen moet men afwegen of het gebruiken van een standaard formaat wel de moeite waard is. Te dikwijls vertrekt men van het idee dat men een standaard moet gebruiken. Er zijn echter soms redenen om een directere weg te nemen en een ad hoc koppeling te maken (die dan nog op XML gebaseerd kan zijn), zeker als je b.v. toch maar louter private elements in HL/7 zou gebruiken. 13

Performantie Als men werkt via een standaard zoals HL/7 dan moeten de gegevens die men wenst over te sturen eerst volledig in het HL/7 formaat omgezet worden. Daarna worden ze via het netwerk doorgestuurd naar het ontvangende systeem of het centrale knooppunt (zie verder). Het ontvangende systeem moet de gegevens weer uitpakken en omzetten in het lokale formaat. Dit alles creëert overhead die in een transactioneel systeem niet altijd aanvaardbaar is. Als de structuur van de informatie die men wenst over te sturen relatief eenvoudig is, goed gekend is, en in de tijd weinig zal veranderen dan kan het dikwijls veel makkelijker zijn een ad hoc formaat en datareplicatieprocedure op te zetten die dichter aanleunen bij het bron- en doelsysteem. Bijvoorbeeld als bron- en doelsysteem beide een relationele database gebruiken voor dataopslag kan men meestal op een efficiëntere manier data repliceren tussen databases door een programma rechtstreeks de nodige data te laten ophalen uit het ene systeem en te laten inserteren in het andere. De procedure om dit laatste te doen laat men dan best door de fabrikant van het ontvangende systeem maken. Men moet op voorhand nagaan of de standaard die men wenst te gebruiken niet te veel overhead met zich meebrengt waardoor de performantievereisten niet gehaald kunnen worden. 2.4.2 Bedrijfszekerheid van de connectie Bij elke connectie die men maakt tussen twee systemen moet men er rekening mee houden dat zowel de verzender als de ontvanger als het proces dat de datareplicatie verzorgt tijdelijk kunnen uitvallen, en dat men de datareplicatie na het herstellen van het defect weer moet kunnen herstarten. 2.4.2.1 ONAFHANKELIJKHEID VAN VERZENDER, ONTVANGER EN TRANSFERPROCES De connectie moet zo opgezet worden dat verzender ontvanger of transferproces mag uitvallen maar dat de andere twee verder blijven functioneren. Dit is juist een van de voordelen van het opsplitsen van systemen: defecten en downtime blijven geïsoleerd tot één onderdeel. Dit kan o.a. gerealiseerd worden door berichten te bufferen aan beide kanten. De verzender schrijft de te transfereren data in een lokale buffer. Het transferproces haalt ze uit deze buffer en stuurt ze naar de buffer van de ontvanger. De ontvanger leest ze uit deze buffer uit om te verwerken. Als de ontvanger niet operationeel is dan kan de verzender nog steeds blijven 14

verder werken en data aan de buffer toevoegen. Indien alleen het verwerkingsproces bij de ontvanger down is, kan het transferproces de data reeds transfereren naar de buffer van de ontvanger. Indien de ontvanger volledig onbeschikbaar is, blijven de te verzenden data gebufferd bij de verzender. De buffers moeten voldoende groot zijn om het volume data dat accumuleert bij downtime op te slaan. 2.4.2.2 GEGARANDEERDE AFLEVERING De connectie moet zorgen voor een gegarandeerde aflevering van elk bericht. Als het medisch dossier verspreid is over verschillende systemen, kan door het niet afleveren van een bericht belangrijke medische informatie verloren gaan. Meestal zal men een bericht pas verwijderen uit de verzendbuffer of afkruisen als zijnde verzonden na bevestiging van ontvangst. Idempotente operaties Dikwijls is de zender na uitval van de ontvanger niet zeker of het laatste bericht wel aangekomen is en er alleen geen ontvangstbevestiging teruggestuurd werd, dan wel dat het bericht zelf nooit aangekomen is. De zender kan dan nadat alles terug operationeel is kijken wat het laatste bericht is dat aangekomen is, maar dit maakt de interactie tussen zender en ontvanger complex. Een eenvoudiger manier is te werken met idempotente operaties. Dit zijn operaties die meerdere keren na elkaar kunnen uitgevoerd worden maar na de eerste keer geen effect meer teweegbrengen. M.a.w. of men een idempotente operatie één of meerdere keren uitvoert na elkaar geeft hetzelfde resultaat. Als men bij datacommunicatie ervoor zorgt dat elk bericht dubbel of zelfs meerdere keren kan gezonden worden dan kan men bij een herstart terug al die berichten beginnen te verzenden waarvoor men geen ontvangstbevestiging gekregen heeft. Op die manier kan de ontvanger een bericht meermaals binnen krijgen maar heeft dit geen effect. De verzender hoeft dus niet te controleren wat de ontvanger al verwerkt heeft, wat de connectie eenvoudig houdt. De meeste commerciële messaging engines hebben mechanismen voor gegarandeerde aflevering ingebouwd (zie verder). 2.4.2.3 HERSTARTPROCEDURE Voor elke connectie moet een herstartprocedure uitgewerkt en beschreven worden die geen berichten verloren laat gaan. De systemen moeten zo gedimensioneerd zijn dat ze in staat zijn de opgelopen achterstand voldoende snel in te halen. 15