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 2.2
INLEIDING .............................................................................................................................................. 3 DEFINITIES ............................................................................................................................................. 4
2.2.1 2.2.2 2.3
Geconnecteerde systemen.................................................................................................................. 4 Geïntegreerde systemen .................................................................................................................... 6 OPSPLITSEN VAN HET ZIS: INHOUDELIJKE OPTIES .................................................................................. 9
2.3.1 2.3.2
Per groep gebruikers......................................................................................................................... 9 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 2.4.2.2
Onafhankelijkheid van verzender, ontvanger en transferproces ............................................................. 14 Gegarandeerde aflevering....................................................................................................................... 15
2.4.2.3 2.4.2.4
Herstartprocedure ................................................................................................................................... 15 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 2.4.4.2 2.4.4.3
Master slave............................................................................................................................................ 19 Routeringsregels ..................................................................................................................................... 19 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
3
2.6.2
Front end componenten................................................................................................................... 24
2.6.3
Samenwerkende toepassingen als alternatief voor front end componenten - CCOW ..................... 24
INHOUDELIJKE STRUCTUUR ............................................................................................................. 26 3.1 DATA ORGANISATIE ............................................................................................................................. 26 3.1.1 Patiëntennummer ............................................................................................................................ 26 3.1.1.1 3.1.1.2
3.1.2
Beheer..................................................................................................................................................... 26 Uniciteit van het patiëntennummer......................................................................................................... 27
Coderingen...................................................................................................................................... 28
3.1.3 Structurering ................................................................................................................................... 30 3.2 FUNCTIONALITEIT ................................................................................................................................ 30 3.2.1 3.2.2
Afsprakenbeheer.............................................................................................................................. 30 Resultatenbeheer ............................................................................................................................. 32
3.2.3 3.2.4
Aanvraag- en registratiesysteem ..................................................................................................... 32 Medicatie voorschrift en toediening................................................................................................ 34
i
3.2.4.1
4
3.2.5 3.2.6
Patiëntenbewegingen ...................................................................................................................... 34 Facturatie........................................................................................................................................ 35
3.2.7
Probleemlijst en progress notes ...................................................................................................... 35
BESCHIKBAARHEID VAN HET COMPUTERSYSTEEM ................................................................ 36 4.1 4.2
OORZAKEN VAN ONBESCHIKBAARHEID ................................................................................................ 36 TECHNIEKEN OM DE ONBESCHIKBAARHEID TE BEPERKEN .................................................................... 37
4.2.1
Backup............................................................................................................................................. 37
4.2.2 4.2.3
Hardware redundantie .................................................................................................................... 39 Onderhoudscontracten .................................................................................................................... 40
4.2.4 4.2.5
Cluster ............................................................................................................................................. 40 Replication server ........................................................................................................................... 40
4.2.6 4.2.7
Inrichting computerruimtes............................................................................................................. 41 UPS, noodstroom voor infrastructuur buiten de computerruimtes ................................................. 42
4.3 5
6
Verbruik ................................................................................................................................................. 34
REDUNDANTIECRITERIA VOOR EEN ZIEKENHUIS ................................................................................... 42
ARCHIVERING......................................................................................................................................... 44 5.1
FYSISCHE PROBLEMEN ......................................................................................................................... 44
5.2
LOGISCHE PROBLEMEN ......................................................................................................................... 44
BEVEILIGING........................................................................................................................................... 46 6.1 6.2
TOEGANGSCONTROLE .......................................................................................................................... 46 AUTHENTICATIE ................................................................................................................................... 46
6.2.1
Basistechnieken ............................................................................................................................... 46
6.2.2
Discipline bij authenticatie ............................................................................................................. 47
6.2.2.1 6.2.2.2 6.2.2.3 6.2.2.4
6.2.3 6.2.4
Stimuleren van discipline bij authenticatie met paswoorden .................................................................. 48 Stimuleren van discipline door keuze van de authenticatietechnieken ................................................... 49 Uitreiken van nieuwe of vernieuwde authenticatiemiddelen .................................................................. 49 Reageren op inbraakpogingen ................................................................................................................ 50
Welke authenticatie technieken gebruiken voor een ZIS ? .............................................................. 50 Individuele gebruikersnamen .......................................................................................................... 51
6.3 6.4
AUTORISATIE ....................................................................................................................................... 51 BEHEER VAN GEBRUIKERS .................................................................................................................... 52
6.5 6.6
AUTOMATISCH VERGRENDELEN VAN EEN SESSIE BIJ INACTIVITEIT ...................................................... 53 AUDITING ............................................................................................................................................. 53
6.7
ENCRYPTIE EN DIGITALE HANDTEKENING ............................................................................................ 54
6.7.1 6.7.2
Symmetrische encryptiealgoritmes.................................................................................................. 54 Public-private key algoritmes ......................................................................................................... 55
6.7.3 6.7.4
Certificaten...................................................................................................................................... 55 Hashing technieken ......................................................................................................................... 56
6.8 6.9
VIRUSSEN, WORMEN EN TROJAANSE PAARDEN ..................................................................................... 56 FYSISCHE TOEGANG TOT COMPUTERSYSTEMEN.................................................................................... 57
6.10
DIEFSTAL VAN LAPTOPS ....................................................................................................................... 57
6.11 6.12
TOEGANG VOOR ONDERSTEUNING VAN TOESTELLEN. .......................................................................... 57 INTERNET TOEGANG ............................................................................................................................. 58
6.13 6.14
VIRTUELE PRIVÉ NETWERKEN .............................................................................................................. 59 TOEGANGSCONTROLE OP TOEPASSINGSNIVEAU ................................................................................... 59
ii
6.14.1
Authenticatie ............................................................................................................................... 59
6.14.2
Autorisatie................................................................................................................................... 60
6.14.3
Audit............................................................................................................................................ 62
6.14.3.1 6.14.3.2 6.14.3.3 6.14.3.4
Beleid ..................................................................................................................................................... 62 Audit per patiënt..................................................................................................................................... 62 Audit per gebruiker................................................................................................................................. 63 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 8.1.1.2 8.1.1.3 8.1.1.4 8.1.1.5
Dimensionering van het archief.............................................................................................................. 68 Hierarchische organisatie van het archief ............................................................................................... 70 Symmetrie in de toegang tot het archief ................................................................................................. 71 Backup en continuiteit van werking ....................................................................................................... 71 Consolidatie van opslagnoden ................................................................................................................ 73
8.1.2 8.1.3
Distributie van radiologische beelden doorheen het ziekenhuisnetwerk......................................... 73 Koppelen van de beeldvormende toestellen..................................................................................... 73
8.1.4 8.1.5
Viewing voor primaire diagnose ..................................................................................................... 75 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
9
8.2.2
“Front office” integratie van PACS in een overkoepelende gebruikersinterface ........................... 82
8.2.3 8.2.4
Informatie-uitwisseling met de beeldvormende toestellen............................................................... 84 Correctie van fouten in het PACS ................................................................................................... 87
TELEMATICA........................................................................................................................................... 88 9.1
BEVEILIGING BIJ TELEMATICA .............................................................................................................. 88
9.1.1 9.1.2
Definiëren van verantwoordelijkheden ........................................................................................... 88 Beveiligen van de communicatie ..................................................................................................... 89
9.1.3
Authenticatie van de gebruikers ...................................................................................................... 89
9.1.4 9.1.5
Inperken van bedrijfslogica in de client-software ........................................................................... 90 Gedetailleerde toegangsregels en externe artsen............................................................................ 91
9.2 TECHNOLOGIE VOOR TELE-INTERACTIE TUSSEN PERSONEN .................................................................. 91 9.2.1 Video conferencing.......................................................................................................................... 92 9.2.2 9.2.3 9.3
Data conferencing ........................................................................................................................... 94 “Delayed time” interactie door uitwisselen van bestanden ............................................................ 95 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 9.3.1.2
9.3.2
Interactieve tele-toegang tot het dossier binnen een ziekenhuis...................................................... 98
9.3.2.1 9.3.2.2
9.3.3
Organisatorische uitdagingen ................................................................................................................. 96 Architectuur en technologie voor communicatie .................................................................................... 97 Organisatorische uitdagingen ................................................................................................................. 99 Technologie voor interactieve tele-toegang.......................................................................................... 100
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
Data connectie. Ad hoc protocol, HL/7 connectie of andere. Apotheek
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
ID info RX System
Appointment scheduler
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
Toepassing 2
Geimplementeerd op “applicatie servers” type J2EE, .NET of servlets. Meerdere middellaag servers mogelijk. Middle tier
Middle tier
RX aanvraag
RX rapportering
RX system
Patient admin
Afspraken
Patiënt admin
Medicatievoorschrit
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 Dossier Pakket A
Abdominale heelkunde
Dermatologie
Anesthesiologie
Dossier Pakket B
Dossier Pakket C
Anesthesie/ pre-op bewaking
Cardiologie
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
Dossier Pakket A
Abdominale heelkunde
Dermatologie
Anesthesiologie
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
Naast de maatregelen nodig om het verlies van berichten tegen te gaan moet men er ook voor zorgen dat de systemen die de datareplicatie verzorgen voldoende ruim gedimensioneerd zijn. Als het systeem b.v. 4 uur uitgelegen heeft wegens panne zou men de berichten die zich tijdens die 4 uur opgestapeld hebben snel moeten kunnen wegwerken. Zolang het systeem nog “oude” berichten die tijdens de panne gegenereerd werden aan het verwerken is, kunnen de nieuwe niet verzonden worden en blijft de ontvanger achterlopen op de zender. Voor de ontvanger is de effectieve downtime = de tijd van de panne + de tijd om de achterstand weg te werken.
2.4.2.4
TRANSACTIES
Transacties implementeren over messaging systemen is zeer complex. Eenvoudige datareplicatie kan men zelf opzetten maar om transacties bovenop een messaging systeem te laten werken maakt men best gebruik van gespecialiseerde software. Tijdens de transactie blijven op de database locks openstaan, die op hun beurt andere (lokale of gedistribueerde) transacties blokkeren. Als de transacties onvoldoende snel verwerkt worden veroorzaakt dit een vicieuze cirkel die de systemen tot stilstand brengt. Hoe trager de transacties hoe sneller dit fenomeen optreedt. Transacties over messages zijn doorgaans veel trager dan transacties tussen databases die op hun beurt trager zijn dan transacties binnen een database. Voor men een architectuur opzet waarin gedistribueerde transacties nodig zijn, moet men er zich van vergewissen dat deze transacties voldoende snel afgehandeld kunnen worden om de operationele werking van de deelnemende systemen niet in het gedrang te brengen..
2.4.3
Centraal knooppunt
Als men veel connecties moet maken tussen verschillende systemen kan men ervoor opteren alle connecties via een centraal knooppunt te laten lopen (zie figuur pag. 1). Elk van de systemen connecteert zich met het knooppunt. Voordelen •
Het aantal connecties dat moet onderhouden worden daalt drastisch.
•
Het knooppunt kan ook routeren: een zender moet het bericht maar één keer naar het knooppunt sturen en deze kan het bericht op meer dan één plaats afleveren. In sommige commerciële producten kan men vrij complexe routeringsregels opgeven.
•
Single point of management: via het knooppunt kan men alle connecties opvolgen.
•
Protocolconversie: de verzender stuurt het bericht in een bepaald protocol naar het knooppunt. Het knooppunt kan het bericht naar een ander protocol omzetten vooraleer het naar een ontvanger te sturen.
16
•
Onderhoudbaarheid: één systeem om buffers op te zetten, één systeem van gegarandeerde aflevering, …
Nadelen •
Single point of failure: als het knooppunt down is, vallen alle connecties uit.
•
Telkens twee connecties nodig om systemen te verbinden: van verzender naar knooppunt en van knooppunt naar ontvanger. Hierdoor verhoogt de transmissietijd nog meer (zie ook pag. 14). Voor online opvragingen wordt deze manier van werken dikwijls te traag.
•
Kost. Voor enkele connecties is dit meestal niet de moeite: men heeft een aparte machine nodig, software licentie (als men een commercieel product gebruikt), moet het pakket leren kennen , onderhouden, …
2.4.3.1
INTERFACE ENGINE
In de medische wereld werkt men reeds lang met zogenaamde HL/7 interface engines. Een HL/7 interface engine is een centraal knooppunt voor HL/7 berichten. Meestal wordt deze software op een aparte server geïnstalleerd. Alle systemen zenden hun HL/7 berichten naar de interface engine. De interface engine buffert deze en zorgt voor verzekerde aflevering van de berichten. Sommige interface engines laten toe (beperkte) business logica te implementeren. Deze wordt vooral gebruikt voor routering en filtering. Dmv van regels kan men bepalen welke berichten naar welke ontvangers moeten gezonden worden. Meestal kan men, vóór dat men het bericht routeert naar een ontvanger, ook nog wijzigingen aan aanbrengen. Zo kan men b.v. filters definiëren. Stel dat een medisch systeem data stuurt naar een ander medisch systeem en een administratief systeem moet op de hoogte gebracht worden van het feit dat een onderzoek uitgevoerd werd, maar niet van het eigenlijke resultaat. Dan kan men op de interface engine instellen dat het andere medische systeem het volledige bericht ontvangt maar dat het administratief systeem een gefilterde kopie (zonder het resultaat) van het originele bericht krijgt. Vele interface engines kunnen ook andere protocols aan en kunnen HL/7 berichten van één versie in een andere omzetten.
2.4.3.2
MESSAGE BROKER
Men kan ook opteren voor een algemene message broker. De markt voor EAI (enterprise application integration) heeft een aantal algemene integratie producten voortgebracht. Het verschil met de HL/7 interface engines is dat deze dus niet rechtstreeks het HL/7 protocol ondersteunen maar meer algemene applicatie-aspecifieke protocols ondersteunen. 17
Deze producten hebben als voordeel dat ze ook voor integratie van niet medische toepassingen kunnen worden gebruikt, waar HL/7 niet gekend is. Vermits ze een grotere markt bestrijken zijn ze over het algemeen ook meer gesofisticeerd maar meestal duurder. Vermits een centraal knooppunt een bijzonder belangrijke en kwetsbare component is van de architectuur, moeten in het informaticaplan volgende opties bepaald worden: •
Beveiliging van het knooppunt: wie heeft toegang, wie definieert de routeringsregels, …
•
Performantievereisten: doorstuurtijd van berichten, recovery tijd nodig om na herstart gebufferde berichten te verwerken, …
•
Bedrijfszekerheid:
welke mechanismen verzorgen verzekerde aflevering, uptime
(ontdubbeling van de server nodig?), idempotente operaties of niet,
2.4.4
Datareplicatie: inhoudelijke opties
Los van bovenstaande technische opties zijn er inhoudelijke opties die men moet nemen en die louter verband houden met het feit dat men data wenst te repliceren (los van welke technische optie ook). Indien de verschillende systemen die gerepliceerde data ontvangen onder afzonderlijk beheer staan en een eigen beleid voeren, moeten er een aantal afspraken gemaakt worden i.v.m. kopiebeheer. Wie beheert de kopieën van de gerepliceerde data? Als dienst A data doorstuurt naar dienst B: •
Wie is dan verantwoordelijk voor de toegangscontrole tot de gerepliceerde gegevens?
•
Wie is verantwoordelijk voor de correcte presentatie en visualisatie van de data?
•
Mag dienst B de gegevens wijzigen?
•
Mag dienst B interpretatieregels toepassen op de gegevens van A (buiten de controle van A)? Het gaat hier niet om ruwweg wijzigen van de basisgegevens maar om programmatorisch interpreteren ervan, al dan niet door ze te combineren met eigen gegevens.
•
Mag B de gegevens op zijn beurt doorsturen naar C?
Presentatie en visualisatie Bij datareplicatie worden de gegevens naar een andere database gestuurd maar dit garandeert nog niet dat ze daar correct gepresenteerd worden. Zo kan men b.v. labresultaten doorsturen naar een systeem dat deze zonder normale waarden of met verouderde normale waarden aanbiedt aan haar gebruikers. Vermits het hoofd van de laboratoria verantwoordelijk is voor de rapportering, zou deze persoon moeten nagaan of de data correct gepresenteerd wordt op het andere systeem.
18
Sommige data worden als “ruwe data” gepropageerd en kunnen niet zonder meer gevisualiseerd worden. Voorbeelden zijn EKG tracés, radiologische beelden, of resultaten van beeldverwerking. Voor dergelijke resultaten heeft men steeds gespecialiseerde viewers nodig. De dienst die de data produceerde moet nagaan of de ontvangende dienst de gegevens kan visualiseren. Bij complexe gegevens kan worden overwogen of i.p.v. functiereplicatie (zie pag. 5), de producerende dienst niet beter een visualisatiecomponent ter beschikking kan stellen die kan ingebouwd worden door de ontvangende dienst.
2.4.4.1
MASTER SLAVE
Het is best tussen de verzender en de ontvanger van de data een master-slave relatie op te zetten. Alle wijzigingen van de gepropageerde data gebeuren via en door de master die de gewijzigde data propageert naar alle slaves. Master-slave relatie betekent in deze context dat alleen de verzender het recht heeft om gegevens van dat type toe te voegen, te wijzigen of te verwijderen. De ontvanger mag de gegevens alleen lezen. Als de ontvanger een autonoom beheerd systeem is, zal dit door procedureafspraken afgedwongen moeten worden: technisch is er geen manier om te verhinderen dat de ontvanger de gegevens wijzigt. Voor de meeste datatypes is het eenvoudig om een zogenaamde authentieke bron te definiëren die dan als master fungeert. Soms wenst men vanuit een systeem toch data aan te passen waarvan men niet de master is. Als dit noodzakelijk is kan men best de master een functie laten definiëren via dewelke de andere systemen gegevens kunnen aanpassen op de master. De aangepaste gegevens worden dan vanuit de master weer naar alle slave systemen gepropageerd. Dit heeft volgende voordelen •
de master bevat alle nodige bedrijfslogica om te controleren of de wijziging toegelaten is en om de gegevens intern consistent te houden;
•
alle andere applicaties (slaves) krijgen de gewijzigde data ook door;
•
het systeem dat de wijziging aanvroeg hoeft niet te weten welke andere systemen hiervan op de hoogte gebracht moeten worden noch op welke manier;
•
er zijn geen inconsistenties tussen de kopieën op de verschillende systemen.
2.4.4.2
ROUTERINGSREGELS
Zelfs als de verschillende deelsystemen decentraal beheerd worden, worden de routeringsregels
en
filters
op
het
centrale
knooppunt
best
centraal
beheerd.
Administratortoegang en paswoorden voor het centrale knooppunt moeten bijzonder goed beveiligd worden vermits alle (medische) informatie via deze server passeert. 19
2.4.4.3
SYNCHRONISEREN VAN VERSCHILLENDE DATAKOPIEËN
Indien nadat de gegevens op de master verstuurd worden er nog wijzigingen kunnen doorgevoerd worden, moeten er ook synchronisatieprocedures en -berichten gedefinieerd worden. Een probleem hierbij kan zijn dat als een groot deel van de inhoud van het bericht wijzigt het niet steeds duidelijk is of het om een nieuw bericht gaat dan wel om een wijziging van een oud bericht. Elk bericht moet een unieke identificator hebben waarnaar verwezen kan worden om latere wijzigingen door te geven.
2.4.4.4
IMPLICATIES VAN DATAREPLICATIE OP TOEGANGSCONTROLE
Of men werkt met een centraal knooppunt dan wel met rechtstreekse connecties, het resultaat is dat er verschillende kopieën van medische resultaten op verschillende servers terecht komen. Dit verhoogt het risico van oneigenlijke toegang en bemoeilijkt de controle. We halen volgende aandachtspunten aan: Uniformiteit van de toegangscontroleregels Worden dezelfde toegangscontrole regels gerespecteerd in alle systemen? Het heeft geen zin dat men in één systeem zeer streng is maar door in te loggen op een ander systeem toch aan de gegevens geraakt. Uniformiteit in het toekennen van toegangsrechten De toegangscontroleregels kunnen gelijkaardig geïmplementeerd zijn in twee systemen, maar er zou een verschil kunnen zijn in het toekennen van de privileges in beide systemen. Stel dat in beide systemen alleen “administrators” bepaalde toegangen hebben, maar in één van beide systemen verkrijgt men zeer snel de rol van administrator, dan is dit systeem een beveiligingsrisico. Uniformiteit in de opvolging In alle systemen zal er een vorm van opvolging (audit) zijn van de uitgevoerde toegangen. Men kan best - indien technisch mogelijk – deze gelijkaardig opzetten voor alle kopieën. Indien medische data over verschillende servers gekopieerd wordt, moet de toegangscontrole over die verschillende systemen heen zo veel mogelijk geüniformiseerd worden en dit zowel qua regels, toekennen van privileges als opvolging.
20
2.5 Resultatenserver Een resultatenserver is in zeker zin een speciaal geval van de architectuur met centraal knooppunt. Alle systemen connecteren met de resultatenserver maar er worden alleen “resultaten” doorgegeven en de resultatenserver slaat deze op in plaats van ze door te zenden. De andere systemen vragen de gegevens online op wanneer ze deze nodig hebben. Net zoals bij het knooppunt heeft men dus minder connecties nodig, maar in plaats van de berichtenstroom centraal te beheren, beheert men hier de resultaten zelf centraal. Voordelen Veel minder redundantie. De resultaten zijn maar op twee plaatsen aanwezig: in het producerende systeem en in de resultatenserver. Hierdoor heeft men globaal gezien ook minder opslagruimte nodig. Toegangscontrole voor de gerepliceerde data is beter beheersbaar omdat ze gecentraliseerd kan worden (zie verder). Nadelen •
Performantie. De gerepliceerde data worden niet meer lokaal in de diverse systemen bijgehouden en moeten nu online op de resultatenserver opgevraagd worden. Dit is trager.
•
Single point of failure.
Als men een resultatenserver heeft vermijdt men best dat deelsystemen de gegevens op deze server nog eens redundant opslaan.
2.5.1
Implicaties op toegangscontrole
Centrale toegangscontrole Vermits alle resultaten in één resultatenserver terecht komen moet men maar op één plaats de toegangscontroleregels definiëren om een uniforme implementatie te bekomen. Om fijne toegangscontroleregels te implementeren zal men echter meer informatie nodig hebben dan de resultaten alleen. Zo kan men ook de plaats waar de patiënt gehospitaliseerd is, de dienst waarvoor hij ingeschreven is, de afspraken, … nodig hebben om te oordelen of de toegang tot het dossier toegelaten is of niet. Dit betekent dat deze gegevens, naast de resultaten zelf, ook moeten gerepliceerd worden naar de resultatenserver. Verder moeten alle gebruikers individueel gekend zijn in de resultatenserver, alsook de groep waartoe ze behoren of de rollen die zij kunnen aannemen. Dit is uiteraard technisch mogelijk maar niet altijd haalbaar omdat de implementatie hiervan arbeidsintensief is. 21
Decentrale toegangscontrole Het andere uiterste is om de toegangscontroleregels toch op de opvragende systemen te implementeren en deze de gegevens uit de resultatenserver te laten ophalen zonder dat de resultatenserver nog een bijkomende controle uitvoert. De andere systemen worden dan volledig vertrouwd door de resultatenserver. Soms laat men de opvragende systemen elk maar met één loginnaam de data opvragen aan de resultatenserver. In dat geval kan de resultatenserver maar een beperkte log bijhouden van wat er opgevraagd werd: men weet alleen welke gegevens naar welke toepassingsserver gestuurd werden maar niet voor welke gebruiker. Als men voor dit laatste kiest is het van het grootste belang dat de loginnaam/paswoord combinatie waarmee de toepassingsservers naar de resultatenserver gaan goed beveiligd zijn. Vermits de resultatenserver geen enkele verdere controle uitoefent is het uitlekken van zo’n loginnaam/paswoord combinatie een groot veiligheidsrisico. Meestal zal de toegangscontrole op een resultatenserver deels centraal en deels decentraal gedefinieerd worden. Definieer in de mate van het mogelijke de toegangscontroleregels zoveel mogelijk centraal. Wij stellen voor zoveel mogelijk met unieke logins te werken op de resultatenserver en daar waar een toepassingsserver met een groepslogin resultaten opvraagt te bepalen welke beveiligingsmaatregelen deze server moet implementeren op gebied van authenticatie, autorisatie, en logging. Combinatie van resultatenserver en centraal knooppunt Voor order entry is een resultatenserver geen oplossing: de aanvragen moeten uiteindelijk doorstromen tot in de toepassingsserver van de dienst die de aanvraag moet uitvoeren. Om die reden kan het nuttig zijn een centraal knooppunt te combineren met een resultatenserver. De resultatenserver kan de resultaten dan rechtstreeks of via het knooppunt ontvangen. Het opvragen van resultaten kan ook via het knooppunt gebeuren of rechtstreeks in client-server mode. Dit laatste is uiteraard sneller.
2.6 Component integratie Componentintegratie is de meest moderne manier van integreren en biedt ook de meeste mogelijkheden maar is technologisch het moeilijkste. Het is ook maar met de modernere technologische middelen dat dit mogelijk wordt. Oude toepassingen zullen zich niet makkelijk lenen tot integreren of geïntegreerd worden als component. We bespreken hier alleen de technische opties die door het management moeten genomen worden. 22
Standaardisatie op één technologie Als men naar een componentgeoriënteerd systeem gaat, moet men in de mate van het mogelijke standaardiseren op één component technologie. Er bestaan bruggen tussen componenttechnologieën maar die bemoeilijken integratie en meestal verliest men hierdoor aan functionaliteit en performantie. Het ziet er naar uit dat de markt door 2 technologieën zal gedomineerd worden: .NET van Microsoft en Java dat door een aantal grote en kleine leveranciers gesteund wordt. Het is allicht niet steeds vermijdbaar om ook een andere technologie te gebruiken, maar men moet (1) één technologie definiëren als diegene met de voorkeur vanuit de organisatie, (2) bij uitzonderingen per geval afwegen of de voordelen van de “vreemde” component opwegen tegen de bijkomende kost in het maken van bruggen en het onderhouden van de voor dit geval vereiste kennis van de andere technologie. Of men nu opteert voor front end of back end componentintegratie, men bepaalt best in het informaticamasterplan de technologieën die het ziekenhuis wil en kan supporteren zodat deze als richtlijnen kunnen opgelegd worden aan alle componentleveranciers. Tevens moet men bepalen aan welke basisinterfaces de componenten moeten voldoen om ingebouwd te kunnen worden. Ook bepaalt men op voorhand welke functies de deelcomponenten moeten delegeren naar de overkoepelende front end toepassing waarin de componenten geïntegreerd worden of naar het back end framework. Men laat de deelcomponenten best alleen de specifieke functionaliteit en interne toegangscontrole afhandelen. Volgende functies behoudt men best in de overkoepelende applicatie of binnen de structuren van het framework: •
Authenticatie, zodat deze uniform is (eventueel via LDAP)
•
Toegang tot de component zelf: alleen geautoriseerde gebruikers mogen de component te zien krijgen. De toegang tot de verschillende functies binnen de component moeten uiteraard door deze zelf geïmplementeerd worden.
•
Logging van het gebruik.
Componenten zijn doorgaans kleiner dan subsystemen. Men bekomt dus een systeem waaraan veel verschillende fabrikanten bouwstenen bijgedragen hebben. Elk van deze componenten kent zijn eigen migratiepad maar vooral zijn eigen migratiesnelheid. Er ontstaat een probleem wanneer men het component framework wil upgraden naar een volgende versie. Op dat ogenblik moeten alle componenten die gebruikt worden binnen dat framework kunnen werken met deze versie. Dit is niet vanzelfsprekend vermits fabrikanten soms niet geneigd zijn om werkende oude systemen te upgraden. Anderen willen daarentegen soms geen “oude” versies van het framework ondersteunen. Op die manier kan men in een impasse geraken waarbij sommige componenten minimaal een bepaalde versie van het framework vereisen en anderen daar nog niet op kunnen draaien. Dit kan de evolutie van het systeem blokkeren. 23
Bij aankoop van componenten moet men er zich contractueel van verzekeren dat de fabrikant de versies van het component framework blijft volgen.
2.6.1
Back end componenten
Componenten die veel met elkaar moeten interageren implementeert men best op hetzelfde type framework. Er bestaan bruggen tussen de verschillende component frameworks maar gebruik daarvan geeft meestal performantieverlies. Ook is het implementeren van transacties over componenten in 2 of meer verschillende frameworks geen sinecure. Delegeer zoveel mogelijk useradministratie en toegangscontroleregels naar de daarvoor voorziene functies in het framework zelf. Dit maakt een uniforme toepassing van de regels eenvoudiger en zo bekomt men (binnen dat framework) ook een centralisatie hiervan wat het onderhoud en de controle vergemakkelijkt.
2.6.2
Front end componenten
Indien je een toepassing voor het medisch dossier maakt aan de hand van front end componenten, dan speelt de overkoepelende toepassing waarin de componenten geïntegreerd worden een belangrijke rol. Bovenvermelde opmerkingen blijven van toepassing. Hoe meer functies de componenten met elkaar delen, hoe minder functiereplicatie nodig is en hoe consistenter de interface en het gebruik is. Bij front end componenten definieert men best ook de visuele integratie (look and feel, integratie in één venster of een venster per component, …). Laat componenten zoveel mogelijk
functies
met
elkaar
delen
(vooral
basisfuncties
als
patiënt-
en
gebruikersidentificatie, opzoeken van patiënten, gebruikers, materialen,…).
2.6.3
Samenwerkende toepassingen als alternatief voor front end componenten - CCOW
“By synchronizing and coordinating applications so that they automatically follow the user’s context, the CCOW Standard serves as the basis for ensuring secure and consistent access to patiënt information from heterogeneous sources. The benefits include applications that are easier to use, increased utilization of electronically available information, and an increase in patient safety.”1
1
Uit “Overview of HL7’s CCOW Standard” door Robert Seliger, Co-Chair, CCOW Technical
Committee, www.hl7.org. 24
CCOW is geen component framework maar eerder een technologie waarmee men verschillende toepassingen die tegelijkertijd open zijn synchroniseert. CCOW kent het concept “patiënt” en “episode” en zal als de gebruiker in de ene toepassing een patiënt en een bepaalde episode kiest, de andere open toepassingen ook hiervan op de hoogte brengen zodat ze dezelfde patiënt en episode kunnen selecteren. CCOW wordt nu beheerd door het HL/7 consortium. Dit breidt CCOW nog uit zodat men de toepassingen nog verder met elkaar kan laten synchroniseren. CCOW levert synchronisatie maar geen integratie.
25
3 Inhoudelijke structuur In dit hoofdstuk bespreken we vooral aandachtspunten in verband met de wijze waarop de inhoud van het medische dossier wordt gestructureerd. Dit omvat vooral de graad en wijze van coderingen en structurering. Wat de functionaliteit betreft wordt er geen uitspraak gedaan over welke functies al dan niet aanwezig moeten zijn. Welke functies men wenst te automatiseren en welke niet geven geen indicatie over een beter medisch dossier. In een aantal gevallen is niet-automatisatie immers een even goede optie. De functionaliteit wordt enkel besproken in zoverre dat er aanbevelingen te doen zijn over de manier waarop men een bepaalde functionaliteit automatiseert.
3.1 Data organisatie 3.1.1 3.1.1.1
Patiëntennummer BEHEER
Het patiëntennummer is het centrale ankerpunt, index, voor alle aan de patiënt gerelateerde informatie in de toepassingen. Kies voor een betekenisloos patiëntennummer. De bedoeling van een patiëntennummer is dat het constant blijft over de tijd heen. Alles wat ook maar enige betekenis heeft i.f.v. de patiënt (geboortedatum, geslacht, …), de organisatie (volgnummer per jaar, jaartal van eerste contact, …), externe referenties (SIS kaart nummer, verzekeringsinstelling, …),... en wat opgenomen is in dit nummer kan veranderen of verkeerd geregistreerd zijn, … en dus een aanleiding zijn om het nummer van een patiënt te moeten veranderen. Dit moet zo veel mogelijk worden vermeden. Al deze informatie moet een attribuut zijn van de patiëntidentificatie gerelateerd aan dit betekenisloze nummer. In geval van de minste twijfel of het dezelfde patiënt betreft wordt een nieuw patiëntennummer aangemaakt. Er moet een procedure zijn voor het samenvoegen van twee patiëntennummers en bijhorende dossiers die hierna deze ontdubbeling kan ongedaan maken nadat is bewezen dat het dezelfde patiënt betreft. Verkeerdelijk samengevoegde patiëntendossiers of informatie over verschillende patiënten in eenzelfde dossier kunnen onmogelijk automatisch terug opgesplitst worden. Deze fouten rechtzetten vergt manuele interventies van gebruikers die met de (medische) inhoud vertrouwd zijn. Meestal is dit een tijdrovende bezigheid die alleen verricht kan worden door de behandelende arts. Daarenboven heeft men beter minder informatie door een dossier verkeerdelijk te scheiden dan verkeerde informatie door verkeerdelijk samengevoegde dossiers van verschillende patiënten te behouden.
26
3.1.1.2
UNICITEIT VAN HET PATIËNTENNUMMER
De beslissing of u al dan niet een uniek patiëntennummer gebruikt in het ziekenhuis is niet van toepassing indien er maar één (centrale) toepassing ter beschikking is. Uniek patiëntennummer doorheen het hele ziekenhuis Indien er meerdere (gekoppelde) patiëntentoepassingen zijn, kiest u voor 1 toepassing waarin het basisbestand van de patiëntidentificaties beheerd wordt. Dit basisbestand wordt dan in kopie
doorgestuurd
naar
alle
andere
patiëntentoepassingen.
In
de
andere
patiëntentoepassingen mogen geen wijzigingen, toevoegingen, … toegelaten worden op de kopie gegevens. Zie p. 12 voor technieken om toepassingen te koppelen. In de toepassing waarin de patiëntidentificaties beheerd worden, moeten alle patiënten ingevoerd kunnen worden. Belangrijk is dat er procedures worden afgesproken om te bepalen wie en wanneer patiëntengegevens in de centrale patiëntentoepassing kan invullen en wijzigen. Houd rekening met uitzonderingssituaties zoals weekends, nachten, … waarbij nieuwe patiënten in het systeem moeten worden opgenomen en de personen die normaal gezien deze identificatie uitvoeren niet beschikbaar zijn. Houd rekening met situaties van uitval van de centrale patiëntentoepassing terwijl de andere toepassingen die van deze gegevens een kopie krijgen wel ter beschikking zijn. Elke patiënttoepassing krijgt dan ook een kopie van elke patiëntenrecord en kan dus (meestal alleen administratieve) gegevens bevatten van patiënten waarvoor in die toepassingen geen medische gegevens beschikbaar zijn. Hiermee moet eventueel in de autorisatieregels van deze toepassing rekening gehouden worden. In sommige gevallen bevatten zelfs administratieve gegevens informatie die niet in deze toepassing beschikbaar mogen zijn. Meerdere patiëntennummers doorheen het hele ziekenhuis U kan beslissen om het genereren van het patiëntennummer en het beheer van de bijbehorende patiëntengegevens te laten gebeuren in elke toepassing afzonderlijk. Hierbij volgt de opsplitsing van het patiëntennummer op basis van de opsplitsing van de toepassingen zelf (per dienst, functie, …zie p. 9). Het voordeel is dat men geen administratieve patiëntengegevens heeft in toepassingen die ook geen andere gegevens hebben over deze patiënt. Dit maakt eventueel speciale autorisatieregels hier overbodig. Ook 27
het eventueel onbeschikbaar zijn van de centrale patiëntentoepassing is hierbij geen probleem. Indien er een koppeling moet gemaakt worden van patiëntengegevens over de toepassingen heen, moet er een relatie gelegd worden tussen het patiëntennummer van de verschillende toepassingen. Mogelijke koppelingen waaraan u moet denken, zijn deze met het facturatiesysteem, de resultatenserver, … Mogelijke technieken voor deze relatie zijn een gemeenschappelijk attribuut in de verschillende toepassingen zoals het SIS kaart nummer (wat met patiënten zonder SIS kaart?), combinatie van naam, adres, geboortedatum, … (wat met foutieve gegevens of varianten in schrijfwijze,...?)
3.1.2
Coderingen
Coderingen zijn vooraf gedefinieerde lijsten van begrippen waarin elk begrip een eenduidige en unieke alfanumerieke tekencombinatie bevat met daaraan gekoppeld één of meerdere omschrijvingen. Er zijn internationale erkende en gestandaardiseerde coderingen maar het kunnen ook kleine lokale lijstjes zijn2. Gegevens die men automatisch wenst te verwerken moeten gecodeerd worden. Indien men gegevens in vrije tekst laat invoeren, worden er voor eenzelfde begrip verschillende benamingen, schrijfwijzen, tikfouten, … gebruikt die door de computer niet als het begrip worden herkend. Deze fouten, varianten, … worden zowel door verschillende gebruikers begaan als door eenzelfde gebruiker door de tijd heen. Coderen is dus ook nodig indien er maar één gebruiker is die het denkt consistent te doen3. Het berekenen van aantallen (statistische verwerking), het gebruik voor waarschuwingen (interacties tussen medicatie en diagnoses, …), het berekenen van afgeleidde waarden, … vereist dat de computer een code kan gebruiken. Gebruik een gestructureerd codeersysteem voor codelijsten met veel codes.
2
Het meest minimale voorbeeld is een vraag waarop men bevestigend of ontkennend kan
antwoorden. Dit kan men coderen door “ja”en “neen”. 3
In het bovenstaande voorbeeld zou men bij vrije tekst invoer “ja”, “j”, “OK”, “+”, … en
“nee”, “neen”, “n”, “-“ kunnen bekomen. 28
Bij een gestructureerd codeersysteem bestaat de code uit •
verschillende los van elkaar staande assen (b.v. SNOMED). Elke as heeft zijn eigen betekenis en is op zijn beurt een eigen codeersysteem dat los van de andere onderdelen van de code kan geïnterpreteerd worden
ofwel •
een hiërarchische structurering waarbij elk niveau geïnterpreteerd moet worden op basis van het vorige niveau (b.v. ICD-9).
Indien men geen gestructureerde code heeft zal men, om bepaalde vragen met de computer te kunnen beantwoorden, families van codes moeten maken. Dit kan een zeer omslachtig werk zijn dat continu moet onderhouden en uitgebreid worden. Er zijn verschillende technieken voor het invoeren van een juiste code. Elk van deze technieken heeft zijn toepassing in een bepaalde context: •
hiërarchische zoeksystemen waarin men de codes per niveau aanbiedt en men doorheen de verschillende sublijsten loopt als door een pad. Bij de keuze op elk niveau krijgt men de sublijst die hoort bij het volgende niveau;
•
zoeksystemen op de omschrijving van codes (exact, fonetisch, … zoeken);
•
gepersonaliseerde en beperkte lijstjes van de meest gebruikte codes. De meeste gebruikers zullen in de meerderheid van de te coderen gevallen slechts gebruik maken van een beperkte lijst van codes. Indien deze afzonderlijk aangeboden kunnen worden, versnelt dit het zoeken en bereikt men de volledige lijsten met een “andere”-optie.
•
natuurlijke taal herkenningssystemen waarbij de gebruiker de tekst in een vrij formaat ingeeft en het systeem hieruit de mogelijks van toepassing zijnde codes voorstelt.
Men moet eerst die systemen coderen die als input dienen voor andere systemen. De beste kandidaten om zo snel mogelijk te coderen zijn medicatievoorschrift, probleemlijst (diagnoses en ingrepen) en activiteiten. Coderen vraagt voor een gebruiker meer tijd bij het invoeren dan wanneer men het in vrije tekst kan invoeren. De winst van coderen komt vooral tot uiting indien er meer systemen van de gecodeerde informatie gebruik kunnen maken. Daarom is het aan te bevelen vooral te investeren in het laten coderen van de basisfunctionaliteit. Indien de gebruiker merkt dat het coderen nuttig kan gebruikt worden in andere systemen omdat er voordelen van interactie, detectie, rapportering, … zijn, zal hij zijn extra tijdsinvestering bij het coderen minder als verloren tijd beschouwen t.o.v. het vrije tekst invoeren.
29
3.1.3
Structurering
Structureren is het opdelen van informatie in kleinere delen waarin elk onderdeel een vooraf gedefinieerde betekenis en een plaats t.o.v. de andere informatie heeft. Wanneer men informatie wenst uit te wisselen met andere systemen moet men deze informatie structureren. Structurering kan ook nodig zijn om steeds informatie op eenzelfde wijze in te voeren (b.v. omwille van consistentie- of opleidingsredenen). Een andere reden voor structureren kan het herbruiken van informatie zijn. De structurering van een ontslagbrief in b.v. “medische voorgeschiedenis”, “huidige problematiek”, “bevindingen” en “besluit” geeft de mogelijkheid bepaalde van deze rubrieken in een volgende brief automatisch over te nemen of in te vullen vanuit een probleemlijst. Bepaal welke gegevens uitgewisseld zullen moeten worden met andere systemen. Structureer deze en codeer zoveel mogelijk de individuele data-elementen. Interessante kandidaten om tussen systemen uit te wisselen zijn brieven van technische onderzoekingen en ontslagbrieven. Deze moeten in eerste instantie vooral gestructureerd worden zodat delen ervan makkelijk en automatisch herbruikt kunnen worden in een andere brief. Ook bij het doorsturen ervan naar huisartsen vergemakkelijkt het de integratie met huisartsenpakketten. Ook het structureren van de probleemlijst (zie hieronder) kan nuttig zijn voor het opbouwen van de brieven.
3.2 Functionaliteit 3.2.1
Afsprakenbeheer
In afsprakenbeheerssystemen kan men een grof onderscheid maken tussen 2 versies: •
“slot” georiënteerd. Hierbij gaat men op voorhand in het systeem lege plaatsen voorzien waarop een afspraak kan gemaakt worden. In elke plaats kan een patiënt ingeschreven worden waarna deze plaats benomen is. Men bepaalt op voorhand het uur en de duur van deze plaats en het aantal plaatsen dat er ter beschikking is met hun beschikbaarheid (alleen opvraagbaar door bepaalde gebruikers, indien aan bepaalde voorwaarden is voldaan (zoals informatie die is opgegeven bij het zoeken van het slot (b.v. “dringend”, “eerste keer”, …) maar ook een toestand waarin het afsprakenboek zich bevindt (meer dan 80% gevuld, minder dan 2 dagen voor het moment van de afspraak, …). Het nadeel van deze werkwijze is dat op voorhand bepaald moet worden hoe groot de duur is van elke plaats (zonder dat men weet welke patiënt of voor welke problematiek de patiënt gaat consulteren). Het voordeel is dat het zoeken naar vrije plaatsen zeer snel kan verlopen. 30
•
regel gebaseerd. Hierbij gaat men op voorhand alleen de beperkingen/mogelijkheden opsommen (elke werkdag tussen 8u en 12u en 14u en 18u, zaterdag tussen 10u en 11:30u). Het voordeel is dat patiënten kunnen worden toegevoegd op vrije momenten en voor vrij te bepalen duur. Het nadeel is dat het zoeken naar vrije plaatsen complexe berekeningen met zich kan meebrengen en dat er niet opvulbare gaten ontstaan waardoor er in totaal nog wel ruimte genoeg is om een afspraak te maken maar dat deze ruimte gefragmenteerd is over verschillende momenten.
In een afsprakensysteem is er per definitie de nood voor het aanmaken van vele nieuwe patiëntidentificaties. Een afsprakensysteem wordt best niet als centrale patiëntentoepassing gekozen. Hou ermee rekening dat voor een afsprakensysteem het noodzakelijk is dat voorlopige patiënt identificaties worden aangemaakt en dat men deze voorlopige identificaties niet in de andere systemen mag overnemen. De identificatie van patiënten in een afsprakensysteem verloopt zeer snel (telefonisch, …) en weinig gecontroleerd, zodat het risico op verkeerde informatie zeer hoog is. Indien u over een aanvraag- en een afsprakensysteeem beschikt, mag het afsprakensysteem geen aanvraaginformatie bevatten maar moeten deze systemen naar elkaar verwijzen. Wanneer er alleen een afsprakensysteem aanwezig is, is een logische uitbreiding van functionaliteit het vragen van extra klinische parameters bij het invullen of zoeken van de afspraak. Als men echter over een aanvraagsysteem beschikt mag men deze informatie niet in het afsprakensysteem overnemen of opnieuw vragen maar moet men vanuit een aanvraag (met al zijn klinische parameters) een afspraak kunnen maken. De gemaakte afspraak en de aanvraag worden met elkaar gekoppeld en het vernietigen van de aanvraag vernietigt de afspraak en het vernietigen van de afspraak maakt de aanvraag ongepland. Voor het maken van combinatieafspraken kiest men voor een systeem dat voor elk onderdeel van de combinatie de mogelijkheden toont waaruit de gebruiker zelf de combinatie kan bepalen i.p.v. een systeem dat zelf de combinaties voorstelt. Voor het optimaal benutten van de afspraken moet men veel te veel parameters opgeven om de computer zelf een goede combinatie te laten voorstellen. Indien men deze informatie niet
31
opgeeft, zal de voorgestelde combinatie steeds minder optimaal zijn dan diegene die door een gebruiker kan bepaald worden4.
3.2.2
Resultatenbeheer
Kopieer resultaten tussen systemen minimaal. Indien men resultaten kopieert tussen verschillende systemen moet er op voorhand rekening mee houden dat er kopiebeheer wordt uitgevoerd Voor verdere bespreking zie p. 18.
3.2.3
Aanvraag- en registratiesysteem
Vóór het aanschaffen of het laten ontwikkelen van een aanvraag- of registratiesysteem, moet u bepalen wie wat wanneer gaat registreren en op welke plaats. Bepaal of de registratie onmiddellijk wordt ingegeven en de enige registratie is ofwel eerst op papier wordt gecreëerd en daarna pas wordt ingevoerd. Wie de aanvraag registreert in de computer bepaalt sterk de nodige gebruikersinterface en ondersteuning die moet geboden worden. Indien dit de persoon is die deze aanvraag zelf genereert (b.v. de arts zelf die in de computer een aanvraag registreert voor een functiemeting, een laboratoriumonderzoek, …) zijn de vereisten aan de gebruikersinterface zeer hoog. Men moet op een eenvoudige manier snel kunnen navigeren tussen de verschillende opties zonder hierin het overzicht te verliezen. Indien de persoon die de aanvraag registreert niet diegene is die de aanvraag genereert (b.v. administratieve gebruikers die een aanvraag die door een arts op papier is gezet in de computer moeten registreren), kunnen er eenvoudigere interfaces voorzien worden. Papieren laten veel
4
Indien men een gecombineerde afspraak moet maken voor 2 technische onderzoeken en
een daaropvolgende raadpleging voor de bespreking van het resultaat op dezelfde dag zal men moeten rekening houden met de conditie van de patiënt, de af te leggen afstand, mogelijke onverenigbaarheden bij de technische onderzoeken (contraststoffen, nuchter blijven, …), externe factoren (de patiënt mag de bus van 12u zeker niet missen, …). Als men dit automatisch gaat proberen te ondersteunen zal men nooit alle factoren kunnen opgeven en zal men veiligheidsmarges inbouwen. Een gebruiker kan echter wel eenvoudig met al deze factoren rekening houden. 32
complexere, visueel ondersteunde selectiemethodes toe dan de computer omwille van de hogere resolutie die men op papier kan bekomen dan op een computerscherm: Er kunnen bijvoorbeeld gemakkelijk meer dan 500 laboratoriumonderzoeken gestructureerd worden op een recto verso A4 aanvraagformulier (60 lijnen, 4 kolommen, 2 zijden) zonder dat hierbij aan de leesbaarheid en bruikbaarheid ingeboet wordt. Indien men eenzelfde aantal laboratoriumonderzoeken op het computerscherm zou aanbieden in een zelfde structuur zou deze onbruikbaar zijn. Er moeten dan meer tussenselecties gemaakt worden wat het uiteindelijk aantal acties om de aanvraag in te voeren vergroot. Wanneer een administratieve gebruiker de op papier aangeduide aanvraag in de computer moet ingeven, kan de gebruikersinterface vele malen eenvoudiger zijn omdat alleen testnummers moeten ingegeven worden. Wanneer de registratie gebeurt in de computer is ook een belangrijke factor voor het bepalen van de gebruikersinterface. Er is een groot verschil tussen de ondersteuning die nodig is voor gebruikers die informatie in bulk (en post factum) invoeren en die voor gebruikers die de informatie invoeren terwijl ze in een redenering, onderzoek, … zitten. Zo zal een arts die een aanvraag registreert tijdens de consultatie van de patiënt een andere interface vereiste stellen dan een verpleegster die op het einde van de shift alle verzamelde aanvragen invoert. Waar de registratie of de aanvraag gebeurt stelt eisen aan de technologie. Registraties die zo dicht mogelijk gebeuren bij de plaats waar de informatie gegenereerd wordt, hebben hoge technologie of infrastructuur eisen. Zo zal een registratie van de klinische parameters aan het bed een draadloos netwerk en een draagbare computer vereisen of een computer bij elk bed. Registraties in de consultatiecabines stellen eisen aan de aanwezige ruimte op het bureau. Indien de registraties verder van de plaats waar de informatie gegenereerd wordt ingevoerd worden, kan men optimaler gaan werken met ruimte, materiaal, … Het nadeel is in dat geval dat informatie vervormd kan zijn (omdat ze niet onmiddellijk is ingevoerd), vergeten wordt,… Wat men registreert kan opgesplitst worden in de inhoud en de graad van detail: De aanvragen of registraties die men invoert zijn best gebaseerd op eigen i.p.v. externe codes (b.v. eigen activiteitennummers i.p.v. riziv nomenclatuur nummers). Hiermee bepaalt men zelf de graad van detail die men wenst te registreren en is men onafhankelijk van de externe nood tot aggregatie. Meestal wenst men intern een meer gedetailleerde registratie dan diegene die nodig is voor externe rapportering (MKG, MVG, facturatie, …). Registreer continu alleen wat onmiddellijke impact heeft op de werking van het systeem of noodzakelijk is voor externe rapportering.
33
De kwaliteit van continue registraties die alleen dienen voor sturing op langere termijn zonder dat de gebruikers er onmiddellijke voordelen of effecten van zien is in de praktijk zeer laag. Indien u met registraties cijfers wil bekomen voor sturing op lange termijn kan u beter werken met steekproeven (continu voor een beperkte populatie of alleen op bepaalde ogenblikken voor de hele populatie).
3.2.4 3.2.4.1
Medicatie voorschrift en toediening VERBRUIK
Er is een duidelijk verschil tussen 3 soorten verbruiken die elk nodig zijn voor de sturing van verschillende aspecten van het medicatiebeheer: •
Het medische verbruik is de werkelijk door de patiënt ingenomen hoeveelheid.
•
Het fysische verbruik is de uit de voorraad verdwenen hoeveelheid.
•
Het factureerbare verbruik is de hoeveelheid die aangerekend mag worden op het factuur.
Het is belangrijk dit onderscheid te erkennen en ermee rekening te houden5. Kies voor het registreren van één soort medicatieverbruik en leid hiervan de andere verbruiken af.
3.2.5
Patiëntenbewegingen
Het centraal registreren van de patiëntenbewegingen kan een belangrijke sturende factor zijn voor verschillende toepassingen. Hoe verfijnder en actueler deze informatie hoe groter de daaraan verbonden voordelen zijn. De patiëntenbewegingen kunnen dienen als sturing voor autorisatieregels (tot het patiëntendossier maar ook voor externe systemen zoals medicatiekasten
voor
opiaten,
…),
voor
het
aansturen
van
werklijsten
(aanwezigheidsbeelden, combinaties van geplande en reeds aanwezige patiënten, …). De patiëntenbewegingen kunnen ook dienen voor online kwaliteitscontrole bij de invoer van gegevens: activiteiten kunnen niet geregistreerd worden buiten een aanwezigheidsperiode van de patiënt, een activiteit kan niet uitgevoerd worden op een dienst waar de patiënt niet aanwezig is, …
5
Een patiënt moet uit een flesje van 50ml 10ml toegediend krijgen. Bij het toedienen laat men
een flesje vallen. Het medische verbruik is 10ml, het fysische verbruik 2 x 50ml en het factureerbare verbruik 50ml. 34
3.2.6
Facturatie
Probeer de gegevens die nodig zijn voor het facturatie systeem zoveel als mogelijk af te leiden en te suggereren op basis van andere registraties. Mogelijke
bronnen
zijn
gestructureerde
en/of
gecodeerde
verslagen,
medische
registratiemodules. Zo kan men op basis van een gestructureerd verslag en de aanduiding daarin van bepaalde technische handelingen (voor redenen van verslaggeving), testen of de daarmee overeenkomstige aanrekeningen niet vergeten zijn.
3.2.7
Probleemlijst en progress notes
Een probleemlijst is een chronologische lijst van diagnoses en ingrepen die de actuele status van de patiënt weergeeft. Hierbij moeten de problemen eenvoudig van actieve naar inactieve status veranderd en inhoudelijk gecorrigeerd kunnen worden. De progress notes zijn korte nota’s in het dossier die gedateerd zijn en eventueel gerelateerd kunnen worden aan de problemen in de probleemlijst. De progress notes moeten niet geïnactiveerd kunnen worden, aangezien ze een vaststelling op een bepaald moment zijn en aldus steeds correct zijn. De progress notes vormen een soort van mededelingenlog over een patiënt. De progress notes zijn op lange termijn minder relevant. Een centrale, gestructureerde, actieve en gecodeerde probleemlijst is de basis voor de goede werking van het medisch dossier. Maak op voorhand afspraken over het gebruik hiervan en de snelheid van invoeren. Men moet ernaar streven om zo veel mogelijk en zo snel mogelijk informatie gecodeerd in een centrale probleemlijst te krijgen zodat deze verder kan dienen voor bijvoorbeeld input voor de voorgeschiedenis en huidige problematiek van de ontslagbrief, voor klinische inlichtingen bij het aanvragen van technische onderzoekingen en doorverwijzingen, als input voor sturende systemen zoals waarschuwingssystemen (medicatie allergie, contra indicaties,…). In het extreme geval moeten er zelfs geen inlichtingen verstrekt worden voor het aanvragen van onderzoeken op voorwaarde dat de actieve probleemlijst actueel is ingevuld. Hoe sneller de informatie hierin is ingevuld hoe nuttiger deze informatie kan gebruikt worden door verschillende toepassingen.
35
4 Beschikbaarheid van het computersysteem In dit hoofdstuk bespreken we een aantal technieken die uiteindelijk allen als doel hebben de gegevens die opgeslagen zijn in het computersysteem op ieder gewenst ogenblik ter beschikking te stellen. Een eerste aspect hiervan is uiteraard het vermijden van onbeschikbaarheid. We moeten er echter van uitgaan dat 100% beschikbaarheid onhaalbaar of op zijn minst onbetaalbaar is. Er moeten dus ook maatregelen genomen worden om bij problemen het systeem zo snel mogelijk terug ter beschikking te stellen. Om de volledigheid van het beleid op dit gebied te verifiëren kan u uitgaan van een lijst van mogelijke problemen. Voor ieder van deze items kan dan nagegaan worden hoe dit risico in uw instelling afgedekt wordt. Eventueel kan u besluiten dat de kans dat sommige problemen zich effectief voordoen zo klein is dat er geen maatregelen voor genomen worden. Dit betekent dan allicht wel dat, mocht een dergelijk probleem zich wel voordoen, u beroep zal moeten doen op algemene rampenplannen van het ziekenhuis en b.v. een aantal diensten tijdelijk sluiten.
4.1
Oorzaken van onbeschikbaarheid
We reiken een aantal mogelijke bronnen van problemen aan zonder volledigheid te ambiëren: •
Hardware problemen met een computer: uitvallen van een schijf, voeding, cpu,…
•
Hardware problemen met netwerkinfrastructuur: uitvallen switches, routers,…
•
Systeemsoftware problemen: problemen met operating system, database software,…
•
Problemen met netwerk door beschadiging van de bekabeling.
•
Toepassingssoftware problemen: bugs in de toepassingsoftware die de toepassing onbruikbaar maken.
•
Uitvallen van toepassingen door manipulatiefouten: uitwissen gegevens in de database, uitvegen van toepassingen,…
•
Externe factoren: uitvallen electriciteit, brand, rookschade, waterschade in de computerruimtes.
•
Moedwillige vernietiging van infrastructuur, vandalisme.
•
Installatie van nieuwe hardware.
•
Installatie van nieuwe versies van systeemsoftware of toepassingssoftware.
36
4.2 Technieken om de onbeschikbaarheid te beperken 4.2.1
Backup
Het maken van een backup is een voorbereiding op een herstellingsoperatie. Bij een backup worden de gegevens gekopieerd naar een ander medium (magneetband, cd,…) en bewaard onafhankelijk van het operationele systeem, ook fysisch onafhankelijk.6 Er wordt een onderscheid gemaakt tussen: •
Een volledige backup, waarop alle gegevens gekopieerd worden.
•
Een incrementele of differentiële backup, waarbij de gegevens die gewijzigd werden sinds de vorige volledige backup of sinds de vorige incrementele backup gecopieerd worden.
In het allerslechtste geval zal u alle gegevens van het computersysteem moeten herstellen op basis van de backups. Alle wijzigingen sinds de laatste backup zullen op dat ogenblik verloren zijn. De frequentie van de backups moet bepaald worden in functie van het maximaal accepteerbare verlies van gegevens. Als u voor het maken van de backups herschrijfbare media gebruikt, dan is van zodra de eerste byte van de nieuwe backup geschreven werd de volledige inhoud van het medium verloren. Om er voor te zorgen dat er altijd minstens 1 backup bestaat van een systeem moeten er dus minstens 2 sets media ter beschikking zijn. Hou er ook mee rekening dat inhoudelijke fouten pas na enige tijd aan het licht kunnen komen. In een dergelijke situatie kan de laatste backup met de situatie vóór de fout opgetreden is helpen om het probleem te verhelpen. Er moeten minstens 2 sets media gebruikt worden bij het maken van een backup. Bepaal het effectief aantal bij te houden versies van de backups in functie van de tijd die kan verlopen vooraleer een majeur inhoudelijk probleem ontdekt wordt.
6
Backup mag niet verward worden met archivering. Backup en archivering zijn twee
verschillende toepassingen met elk hun eigen eisen. Archivering richt zich op het consulteerbaar houden van de gegevens op zeer lange termijn.. Regelmatig een volledige backup bijhouden kan dus niet als een archief beschouwd worden. Voor de specifieke eisen van archieven verwijzen we naar hoofdstuk 5. 37
De backups moeten ook gebruikt kunnen worden in geval van een totale vernietiging van het computersysteem. Dit is uiteraard onmogelijk als de backup media tegelijk met het computersysteem vernietigd zijn. De backups moeten zodanig opgeslagen worden dat ze niet tegelijk met het operationele computersysteem kunnen vernietigd worden. Dit kan bereikt worden door de backups op voldoende afstand van het operationele systeem te bewaren, of door ze in b.v. een brandvrije kast te bewaren. Hou er mee rekening dat de backups alle gegevens van het computersysteem bevatten en dat de normale toegangscontrolemechanismen niet werken voor de backups. Dit kan alleen opgelost worden door de fysische toegang tot de backups te beveiligen. Bescherm de backups tegen toegang door onbevoegden. Zoals hoger aangegeven is het maken van een backup eigenlijk de voorbereiding voor een herstelprocedure. Uiteraard hoopt iedereen die herstelprocedure nooit te moeten toepassen, maar toch is het aan te bevelen deze herstelprocedure uit te testen. Dergelijke test zal u toelaten na te gaan of: •
de software die u gebruikt voor de backup wel degelijk 100% compatibel is met de recovery software;
•
de backup media leesbaar zijn;
•
de gegevens opgenomen in de backup voldoende informatie bevatten om zo nodig de toepassingen op een nieuwe, pas door de leverancier geleverde machine op te starten.
Een ander belangrijk element dat u uit een dergelijke test kan leren is hoeveel tijd die u nodig heeft om het systeem volledig te herstellen. Dit is dan ook de tijdsspanne waarin het ziekenhuis moet kunnen verder werken zonder ondersteuning van het computersysteem. Voorzie noodprocedures om het functioneren van het ziekenhuis te garanderen tijdens de periode die u nodig hebt om het computersysteem te herstellen. Mogelijk leiden deze testen tot de conclusie dat de hinder te groot is om het ziekenhuis op een realistische manier operationeel te houden. Overweeg dan of: •
De recovery procedure kan ingekort worden, b.v. door verschillende tape drives in parallel te gebruiken.
•
De netto periode van onbeschikbaarheid kan ingekort worden door het stellen van prioriteiten bij de recovery. Denk hierbij bijvoorbeeld aan het opsplitsen van de gegevensbanken in een actuele gegevensbank en een historische gegevensbank. Allicht
38
kan u in een dergelijke situatie reeds een zinvol toepassingspakket aanbieden van zodra de actuele gegevensbank hersteld is. •
De kans dat een volledige recovery moet uitgevoerd worden kan verkleind worden door redundantie in te bouwen in uw configuratie (zie verder).
Om een goede discipline bij het maken van de backups te garanderen is het belangrijk er voor te zorgen dat dit proces niet afhankelijk is van de goodwill van de gebruikers. Bij de bureauticaomgeving kan dit gestimuleerd worden door gebruikers aan te bevelen hun bestanden op centrale servers te plaatsen, waarvoor backup verzorgd wordt. Zorg er voor dat de backups niet afhankelijk zijn van de goodwill van de individuele gebruikers.
4.2.2
Hardware redundantie
Zowat alle grotere machines bieden de mogelijkheid om een aantal onderdelen redundant uit te voeren. Het eerste aspect dat hierbij aandacht verdient zijn de magneetschijven. Gezien magneetschijven bewegende onderdelen bevatten zijn zij vrij gevoelig tegen uitvallen. Bovendien moeten na herstelling van het hardware probleem ook de gegevens terug hersteld worden van backup. Alle “server” machines moeten beschermd worden tegen het uitvallen van een schijf door RAID of mirroring. Sommige server machines bieden nog andere mogelijkheden voor interne redundantie. Enkele voorbeelden: •
Redundante spanningsvoorzieningen: van de electronische onderdelen van een computer is de voeding allicht het meest kwetsbare onderdeel omdat hier het hele vermogen van het computersysteem verwerkt wordt. Voor grotere servers kan dus overwogen worden om een redundante voeding te voorzien.
De mogelijkheid om met een gedeelte van de server terug te starten: sommige servers zullen na een uitval door hardware defect opnieuw proberen te starten, waarbij defecte onderdelen uitgeschakeld worden. De server start dan terug, zij het met een verminderde capaciteit.Overweeg of verdere investeringen in hardware redundantie zinvol zijn in het kader van uw globaal beleid rond beschikbaarheid.
39
4.2.3
Onderhoudscontracten
Het spreekt voor zich dat u waar nodig onderhoudscontracten en ondersteuningscontracten afsluit. Dit moet uiteraard gemoduleerd worden in functie van de impact van het uitvallen van een systeem. Voor toestellen waarvan er tientallen exemplaren geïnstalleerd werden (b.v. kantoorprinters of PC’s) kan u overwegen om zelf een aantal reservetoestellen aan te kopen en de herstellingen in regie te laten uitvoeren. Voor andere toestellen is het allicht nodig om een onderhoudscontract af te sluiten dat voorziet in interventies tijdens kantooruren, voor nog anderen zelfs met mogelijke interventies rond de klok. Bepaal voor welke systemen u onderhouds- en ondersteuningscontracten moet afsluiten.
4.2.4
Cluster
Een cluster is een klassieke methode om de beschikbaarheid van een computersysteem te verbeteren. De typische configuratie bestaat uit 2 computersystemen en 2 schijfsystemen, waarbij beide schijfsystemen telkens met de 2 computersystemen gekoppeld zijn. In normale omstandigheden werkt een van de computersystemen, waarbij de beide schijfsystemen als mirror van elkaar optreden. Het spreekt voor zich dat bij uitval van een van de schijfsystemen het computersysteem verder werkt met het overgebleven schijfsysteem. Bij uitval van een computersysteem wordt op korte tijd overgeschakeld naar het andere computersysteem, zodat de gebruikers maar een korte onderbreking ondervinden. Bij software upgrades moet de volledige cluster gestopt worden. Met andere woorden: deze configuratie brengt geen oplossing voor onderbrekingen voor software upgrades.
4.2.5
Replication server
Met “replication server” bedoelen we hier een techniek waarbij een koppeling op logisch niveau gerealiseerd wordt tussen 2 database servers.
40
Dit kan b.v. door software die uit de log van een operationele server terug database opdrachten (SQL commando’s) afleidt. Deze opdrachten worden dan uitgevoerd door een tweede database server, de “warm standby”. Het genereren van de SQL opdrachten neemt wel enige tijd in beslag, zodat de wijzigingen op de primaire database met enige vertraging worden uitgevoer op de “warm standby” en deze geen exacte copie is. Deze techniek heeft als voordeel dat de “warm standby” geen fysische kopie is van de operationele server..De warm standby kan dus een andere software versie hebben dan de operationele server. Of er kunnen andere indexen e.d. toegevoegd zijn. Dit maakt het mogelijk om nieuwe versies van software en hardware te installeren met een minimale onderbreking van de dienstverlening aan het ziekenhuis. Een mogelijk scenario wordt dan: •
Stop het doorgeven van de SQL commando’s naar de warm standby, waarbij de opdrachten wel bijgehouden worden.
•
Voer de nodige onderhoudswerken uit op de “warm standby”.
•
Voer de gebufferde SQL opdrachten uit op de “warm standby”. Na een inhaaltijd zal deze dus terug een kopie zijn van de primaire server.
•
Schakel de gebruikers over op de warm standby door: ! Alle gebruikersactiviteiten op de operationele database te stoppen. ! Te wachten tot alle operaties ook uitgevoerd zijn op de “warm standby”. Op dit ogenblik zijn de databases dus logisch identiek. ! De rollen van “warm standby” en primaire server om te draaien.
•
Herhaal dan de upgrade procedure op de andere machine.
In dit scenario is er alleen een onbeschikbaarheid tijdens de eigenlijke overschakeling, een procedure die in enkele minuten kan uitgevoerd worden. Uiteraard kan, in geval van nood ook op een geforceerde manier overgeschakeld worden, zodat ook na uitvallen van het operationele computersysteem kan overgeschakeld worden naar de “warm standby”. In dit geval moet er wel rekening mee gehouden worden dat de gegevens die reeds verwerkt waren op de operationele server maar nog niet doorgegeven aan de “warm standby” verloren zijn.
4.2.6
Inrichting computerruimtes
Bij de inrichting van computerruimtes kunnen best faciliteiten voorzien worden om de computersystemen te beschermen. Denk hierbij aan:
41
•
Fysische afscherming als bescherming tegen vandalisme.
•
Automatische brandblusinstallatie.
•
UPS als bescherming tegen kortstondige onderbrekingen van de elektriciteit.
•
Aansluiting op de noodstroomvoorzieningen van het ziekenhuis als bescherming tegen langdurige onderbrekingen van de elektriciteit.
Overweeg ook om 2 computerruimtes op enige afstand van elkaar in te richten als bescherming tegen brand, rookschade, waterschade,…
4.2.7
UPS, noodstroom voor infrastructuur buiten de computerruimtes
Om bij langdurige spanningsuitval het computersysteem ter beschikking te houden moet uiteraard ook de apparatuur opgesteld op de werkplek en de netwerkinfrastructuur aangesloten worden op de noodstroomvoorziening. UPS is hier wellicht overbodig: in geval van spanningsuitval kan u deze systemen met grote waarschijnlijkheid terug starten. Wanneer
u
opteert
om
maar
een
gedeelte
van
de
infrastructuur
op
de
noodstroomvoorziening aan te sluiten, moet nagekeken worden of dit op een consistente manier gebeurt: het heeft geen zin om een PC op een bureau te laten werken als de netwerkapparatuur die voor de communicatie met de centrale servers moet zorgen niet op het noodstroomnet aangesloten is.
4.3 Redundantiecriteria voor een ziekenhuis Sommige productielijnen in industriële omgevingen zijn afhankelijk van de goede werking van een computersysteem: als het computersysteem uitvalt, valt ook de productielijn stil. Dergelijke omgevingen worden vaak als referentie voor hoge beschikbaarheid van computersystemen aangehaald. Maar in dergelijke omgevingen zijn er meestal min of meer grote periodes waarin er geen activiteit is: denk aan weekends of groot onderhoud aan de productielijn. Deze periodes kunnen dan uiteraard ook gebruikt worden voor onderhoud aan het computersysteem. Een ziekenhuis kent dergelijke periodes van inactiviteit niet: een ziekenhuis wordt nooit gesloten,
de
vragen
van
intensieve
diensten
blijven
altijd
even
kritisch.
De
computersystemen die deze diensten ondersteunen moeten dan ook continu beschikbaar zijn. We moeten hierin wel realistisch blijven: een echt 100% gegarandeerde beschikbaarheid van een computersysteem is allicht onhaalbaar en zeker onbetaalbaar.
42
Het is echter wel zo dat voor de werking van een ziekenhuis vooral langdurige onbeschikbaarheid zeer storend is. Hiermee moet rekening gehouden worden bij de keuze van de strategie op dit gebied. Hou er mee rekening dat in een ziekenhuis enkele kortere onderbrekingen in de beschikbaarheid van het computersysteem minder hinderlijk zijn dan een lange onderbreking. Dit is anders dan in de typische industriële omgeving. Hou hiermee rekening bij het bepalen van uw keuzes.
43
5 Archivering Met “archiveren” bedoelen we in dit kader het opslaan van gegevens op verwijderbare media (magneetband, CD, …) met de bedoeling deze gegevens voor lange tijd bij te houden. In de gezondheidssector moet “lange termijn” meestal als tientallen jaren beschouwd worden. Dit stelt specifieke problemen die het terug consulteren van de gegevens bedreigen.
5.1 Fysische problemen Een eerste reeks problemen situeert zich op het fysisch niveau: zal u de bits nog wel van het medium kunnen lezen. Denk hierbij aan volgende elementen: •
“bitrot”: bij de meeste media degradeert de opgeslagen informatie geleidelijk aan. Bij een magnetische informatiedrager vermindert het magnetisme geleidelijk aan tot op een niveau waarop een “0” niet meer van een “1” kan onderscheiden worden. Voor sommige magnetische media beveelt de leverancier aan om de gegevens om de 2 jaar te herschrijven. Ook schrijfbare CD’s degraderen geleidelijk aan. De voor de hand liggende oplossing hiervoor is de gegevens te kopiëren naar andere media vooraleer ze onleesbaar worden.
Vraag aan de leverancier van de media wat de gegarandeerde houdbaarheid van het medium is en herschrijf de media voor het verlopen van die termijn. •
De technologie van verwijderbare media evolueert nog altijd vrij snel en leveranciers ondersteunen oude toestellen niet voor eeuwig. Op termijn zal er dus een probleem ontstaan om nog een computer te vinden met een leesapparaat voor oudere media. Een ander scenario is dat er geen bedrijfssysteem meer is dat deze leesapparaten ondersteunt.
Zorg er voor dat u voor alle media die u nog nodig hebt een nog ondersteund leesapparaat ter beschikking is en blijft.
5.2 Logische problemen Een tweede reeks problemen situeert zich op het logische niveau: als u gegevens opslaat in het formaat van een specifieke applicatie, zullen er in de toekomst nog programma’s zijn die dit formaat zonder problemen kunnen lezen ?
44
Hiervoor kan in een aantal richtingen een oplossing gezocht worden: •
Ofwel voor het opslaan van de gegevens een formaat kiezen dat “tijdloos” is. Denk hierbij b.v. aan tekst bestanden, zonder wat dan ook aan formattering. Ook portable data format en XML lijken goede kandidaten om op zeer lange termijn leesbaar te blijven.
•
Ofwel moet u bewaken dat u blijft beschikken over een computersysteem dat de oudere versie van de software kan draaien. Dit omhelst dan aangepaste versies van het bedrijfssysteem, drivers en toepassingssoftware.
•
Ofwel zorgt u ervoor dat op regelmatige basis de oude formaten geconverteerd worden naar nieuwere formaten.
Zorg er voor dat u altijd over de nodige software blijft beschikken om de bestandsformaten van uw archieven te kunnen lezen.
45
6 Beveiliging 6.1 Toegangscontrole Via de toegangscontrole wordt aangegeven wie welke gegevens opgeslagen in het computersysteem mag consulteren en/of wijzigen. Bij toegangscontrole moet een onderscheid gemaakt worden tussen authenticatie en autorisatie: •
Via authenticatie zal een gebruiker zijn identiteit aan het computersysteem bewijzen.
•
Met autorisatie zal aangegeven worden tot welke diensten de gebruiker toegang heeft en/of tot welke gegevens toegang verleend wordt.
6.2 Authenticatie 6.2.1
Basistechnieken
Authenticatie wordt ook in het dagelijkse leven regelmatig gebruikt. Zo bewijst iemand die een deur opent met een sleutel dat hij gerechtigd is om deze deur te openen door het bezit van de passende sleutel. De meeste authenticatietechnieken zijn gebaseerd op een van deze basisprincipes: •
authenticatie op basis van iets wat je weet;
•
authenticatie op basis van iets wat je bezit;
•
authenticatie op basis van iets wat je bent.
Enkele voorbeelden: •
Authenticatie op basis van iets wat je weet is de basistechniek voor authenticatie bij computersystemen: om te bewijzen dat je het recht hebt om onder een bepaalde gebruikersnaam te werken moet je het bij de gebruikersnaam horend paswoord intikken.
•
Er worden op de markt tokens aangeboden waarop een regelmatig veranderend getal getoond wordt. De reeks van getallen is schijnbaar willekeurig, maar is in werkelijkheid gebaseerd op een algoritme waarin meestal de tijd en een voor ieder token unieke code gebruikt worden. Elk token produceert dus een unieke reeks getallen. Bij toegangscontrole gebaseerd op dergelijke tokens bewijst de gebruiker dat hij in het bezit is van de bij de gebruikersnaam horende token door het getal dat op dat ogenblik op het scherm getoond wordt te tikken.
•
Authenticatie op basis van iets wat je bent gebruiken we dagdagelijks bij het herkennen van mensen op basis van gelaatstrekken, stemtimbre,... De herkenning gebeurt eigenlijk door het “meten” van biologische eigenschappen. Vandaar dat deze technieken ook als
46
“biometrische” technieken aangeduid worden. In een informatica omgeving zijn biometrische authenticatietechnieken ook gebaseerd op het meten van biologische eigenschappen:
gelaatsherkenning,
retina
scan,
vingerafdruk
herkenning,
stemherkenning,... Specifiek aan biometrische authenticatietechnieken is dat zij meestal geen eenduidig antwoord geven of de gebruiker al dan niet herkend werd. Meestal is er sprake van een zeker “percentage” van herkenning. Dit is in de dagelijkse omgang met andere mensen niet anders, denk maar aan herkenning van tweelingen. Bij het gebruik van biometrische technieken in een informatica omgeving moet dan ook rekening gehouden worden met “vals positieve” herkenningen, waar iemand ten onrechte herkend wordt als een geldige gebruiker, en “vals negatieve” herkenningen, waar iemand ten onrechte niet herkend wordt. Soms bieden deze authenticatie softwares de mogelijkheid om het vereiste niveau van herkenning aan te geven. Als een hoog niveau van herkenning geëist wordt zal het aantal vals positieve herkenningen dalen, maar zal ook het aantal vals negatieve herkenningen stijgen. Het is ook mogelijk om een combinatie van deze principes te gebruiken om toegang te verlenen tot een computersysteem. Zo wordt de toegang tot een biljettenverdeler van Banksys verleend door een combinatie van iets wat je hebt, een bankkaart, en iets wat je weet, de bijhorende pin code. De combinatie van verschillende authenticatietechnieken kan ook een antwoord bieden op de problematiek van de valse herkenningen van biometrische technieken.
6.2.2
Discipline bij authenticatie
Een zeer belangrijk aspect bij authenticatie is de discipline van de gebruikers: een gedegen authenticatie staat of valt met de discipline van de gebruikers. Enkele voorbeelden hoe een slechte discipline de authenticatie kan ondermijnen: •
Doorgeven van paswoorden.
•
Paswoorden op een klevertje op het scherm of onder het toetsenbord.
•
Tokens voor authenticatie die een extra PIN code nodig hebben, maar waar de PIN code op het token geschreven werd.
Hieraan kan alleen verholpen worden door de discipline bij de gebruikers te stimuleren. Een goed uitgangspunt hierbij is het opstellen van een document met “deontologische regels” voor het gebruik van het computersysteem, waarin naast de vooropgestelde discipline ook een sanctioneringsbeleid opgenomen wordt. Er moet uiteraard voor gezorgd worden dat alle gebruikers wettelijk afdwingbaar gebonden zijn aan dit document. Voor gebruikers die een arbeidsrelatie hebben met de instelling kan 47
dit gebeuren door deze deontologische regels op te nemen in het arbeidsreglement. Voor gebruikers die niet gebonden zijn door het arbeidsreglement kan gevraagd worden om een exemplaar van deze deontologische regels voor akkoord te tekenen. Zorg er voor dat de vereiste discipline bij authenticatie opgenomen wordt in een document met “deontologische regels voor het computergebruik” en dat alle gebruikers op een wettelijk afdwingbare manier gebonden zijn aan dit document. In een aantal situaties kan de discipline ook gestimuleerd worden door technische maatregelen.
6.2.2.1
STIMULEREN VAN DISCIPLINE BIJ AUTHENTICATIE MET PASWOORDEN
Bij authenticatie met paswoorden wordt meestal toegelaten dat de gebruiker zelf het paswoord kiest. Dit heeft als voordeel dat de gebruiker een paswoord kan kiezen dat gemakkelijk te onthouden is. Het heeft als nadeel dat de gebruiker een slecht paswoord kan kiezen. Met “slecht” paswoord bedoelen we hier een paswoord dat gemakkelijk kan gevonden worden door een andere persoon. De methodes om paswoorden te vinden zijn meestal gebaseerd op een van volgende principes: •
“Brutale kracht” principe, waarbij alle mogelijke paswoorden getest worden tot het goede paswoord gevonden wordt.
•
“Woordenboek” principe, waarbij alle woorden uit een lijst geprobeerd worden.
Bij de meeste computersystemen het risico op slechte paswoorden wel bijgestuurd worden door de keuze van de gebruikers te beperken. Als verdediging tegen “brutale kracht” aanvallen legt men best een minimale lengte van de paswoorden op. Een verdediging tegen “woordenboek” aanvallen kan door paswoorden die bestaan uit woorden of eenvoudige combinaties van woorden te weigeren. Activeer de opties om te gemakkelijk te raden paswoorden te weigeren. Eis paswoorden van minstens 6 tekens lengte. Iemand die toekijkt op het ogenblik dat een gebruiker het paswoord intikt kan ook proberen om de toetsaanslagen te volgen en zo het paswoord te weten komen. Om het bekend raken van paswoorden door deze techniek te vermijden is het aan te raden de paswoorden regelmatig te wijzigen, b.v. om de 3 maanden. Minder gedisciplineerde gebruikers zullen proberen om dit te omzeilen door de paswoord wijzigingsprocedure te gaan, maar als “nieuw” paswoord terug het oude paswoord op te geven, of door kort daarop het nieuwe 48
paswoord terug door het oude te vervangen. Deze gebruikers kunnen tot een betere discipline gestimuleerd worden door herbruik van paswoorden onmogelijk te maken en/of door paswoorden een minimale geldigheidsduur te geven. Laat paswoorden om de 3 maanden vervallen. Activeer ook de opties om het herbruik van paswoorden te ontmoedigen.
6.2.2.2
STIMULEREN VAN DISCIPLINE DOOR KEUZE VAN DE AUTHENTICATIETECHNIEKEN
Men kan ook onderzoeken in hoeverre een authenticatietechniek intrinsiek gevoelig is aan een gebrekkige discipline. Enkele voorbeelden: •
Bij authenticatie via paswoorden kan het paswoord zeer eenvoudig doorgegeven worden. Bij de meeste computersystemen zal de rechtmatige gebruiker hier geen hinder van ondervinden. Sommige computersystemen bieden de mogelijkheid om maar 1 gebruiker tegelijk onder een bepaalde gebruikersnaam te laten werken. Dit kan dus een stimulans zijn om het paswoord niet door te geven.
•
Authenticatie via een of ander extern hardware toestel heeft het voordeel dat dit niet kan gecopieerd worden, er kan dus maar 1 persoon tegelijk van dit toestel gebruik maken. Dit kan dus niet doorgegeven worden.
Voor een sterke authenticatie kunnen best minstens 2 van de bovenstaande principes gecombineerd worden. Zoniet kan diegene die een token voor paswoord authenticatie vindt zonder meer aanloggen. Als dit gecombineerd wordt met een pincode wordt dit al heel wat moeilijker.
6.2.2.3
UITREIKEN VAN NIEUWE OF VERNIEUWDE AUTHENTICATIEMIDDELEN
Bij het toekennen van nieuwe gebruikersnamen en de daarbij horende authenticatie informatie moet de systeembeheerder er voor zorgen dat deze gegevens enkel en uitsluitend bij de rechtmatige gebruiker terechtkomen. Dit is zo mogelijk nog gevoeliger als de gebruiker aan de beheerder vraagt om in te grijpen in het authenticatiesysteem omdat hij b.v. het paswoord niet meer kent. Meestal zal deze vraag via de telefoon gesteld worden. In feite moet dan een authenticatie van de aanvrager gebeuren vooraleer het nieuwe paswoord doorgegeven wordt. Dit kan opgevangen worden door de uitreiking toe te vertrouwen aan vertrouwenspersonen die de gebruiker persoonlijk kennen. In een grote organisatie vereist dit allicht de aanduiding van meerdere vertrouwenspersonen.
49
Bij het vernieuwen van authenticatie informatie zou men als alternatief hiervoor de nieuwe authenticatieinformatie
kunnen
doorgeven
via
een
op
voorhand
afgesproken
communicatiekanaal..
6.2.2.4
REAGEREN OP INBRAAKPOGINGEN
In nogal wat gevallen wordt ook de mogelijkheid geboden om na enkele pogingen om aan te sluiten met een verkeerd paswoord de toegang voor die gebruikernaam volledig af te sluiten tot een beheerder de toegang opnieuw ontgrendelt. Dit is een verdediging tegen zowel “brutale kracht” als “woordenboek” aanvallen. Dit heeft echter wel als nadeel dat het mogelijk wordt het computersysteem te saboteren: het ligt voor de hand om gebruikers de rechtmatige toegang tot het computersysteem te ontzeggen. Overweeg of u de optie om na een aantal verkeerde paswoord opgaves te toegang tijdelijk te blokkeren al dan niet zal activeren.
6.2.3
Welke authenticatie technieken gebruiken voor een ZIS ?
Een authenticatie gebaseerd op een combinatie van technieken uit de 3 categorieën leidt wellicht tot een perfect sluitende authenticatie. Het is echter zeer de vraag of dit ergonomisch en financieel haalbaar is. In de praktijk zal dus een compromis moeten gevonden worden. De fundamentele vraag hierbij is in hoeverre u vertrouwen kan hebben in de groep mensen die uw authenticatiesysteem kunnen proberen te omzeilen. Bij de overweging van dit vertrouwen moet rekening gehouden worden met volgende elementen: •
Wat is de waarde van de gegevens die opgeslagen zijn in het computersysteem ? Het spreekt voor zich dat een minder strikte authenticatie kan volstaan voor toegang tot documenten rond b.v. interne procedures dan voor toegang tot medische of financiële gegevens.
•
Hoe groot is de groep mensen die kan proberen het authenticatiesysteem te omzeilen ? Voor werkposten opgesteld in ’s nachts afgesloten kantoren van de instelling moet u allicht enkel rekening houden met eigen personeelsleden. Bij werkposten opgesteld in “publieke” ruimtes moet u ook rekening houden met de patiënten en bezoekers. En wanneer u toegang verleent van buiten de instelling, b.v. via het Internet, moet u rekening houden met alle Internet gebruikers ter wereld.
•
In hoeverre kan u vertrouwen hebben in de discipline van de gebruikers ? 50
Voor gebruik vanuit de gebouwen van de instelling kan vandaag een authenticatie gebaseerd op paswoorden volstaan, mits voldoende aandacht geschonken wordt aan een gedegen discipline bij het gebruik. Voor toegang van buiten de instelling is het aangewezen over te gaan op een autenticatie gebaseerd op een combinatie van minstens 2 authenticatietechnieken, b.v. een token voor paswoordgeneratie gecombineerd met een PIN code.
6.2.4
Individuele gebruikersnamen
Om een effectieve autorisatie te garanderen moet de authenticatie op individuele basis uitgevoerd worden. Opteer in principe voor een individuele authenticatie. In omgevingen waar zeer frequent andere gebruikers eenzelfde werkpost moeten gebruiken kan het telkens opnieuw uitvoeren van de authenticatieprocedure zeer tijdrovend zijn waardoor een zeer grote verleiding kan ontstaan om niet telkens van gebruikersnaam te wisselen, wat neerkomt op het saboteren van de authenticatie. In dit geval kan overwogen worden om een gemeenschappelijke gebruikersnaam toe te kennen. De autorisatie van een gemeenschappelijke gebruikersnaam kan ook verder beperkt worden dan een individuele gebruikersnaam.
Dit
is
dan
te
verkiezen
boven
een
situatie
waarin
het
authenticatiemechanisme gesaboteerd wordt door de gebruikers. In uitzonderlijke omstandigheden kan een gemeenschappelijke gebruikersnaam met beperkte rechten toegekend worden.
6.3 Autorisatie Autorisatie bepaalt welke gebruikers toegang hebben tot welke gegevens. Dit moet op verschillende niveau’s ingesteld worden: bedrijfssysteem, gegevensbank, toepassingen, … Op het niveau van het bedrijfssysteem moet ingesteld worden wie toegang heeft voor consulteren
en/of
wijzigen
van
de
bestanden.
Gelijkaardig
moet
in
het
gegevensbanksysteem ingesteld worden wie toegang heeft tot de informatie die er in opgeslagen werd.
51
Ook binnen sommige toepassingen kan autorisatie ingesteld worden. In sommige gevallen worden deze instellingen vertaald naar instellingen op systeemniveau. In andere gevallen zal de toepassing zelf ook nog een aantal extra autorisatieregels toepassen, b.v. bepaalde informatie niet doorgeven aan de gebruiker. In sommige gevallen is dit zeer extreem toegepast: sommige pakketten zetten de verbinding met het gegevensbanksysteem altijd op met dezelfde gebruikersnaam en paswoord en realiseren de volledige toegangscontrole in eigen code. Mocht een gebruiker er in een dergelijke omgeving in slagen om rechtstreeks de gegevensbank te ondervragen vallen de extra beperkingen die de toepassing invoert uiteraard weg. Dergelijke toegang moet uiteraard onmogelijk gemaakt worden, zoniet hebben de beveiligingen in de toepassing geen zin. Zorg voor een consistent beleid dat op termijn vol te houden is. Gebruik hiervoor de beschikbare middelen, als indeling in groepen, rollen, … om het administratieve werk dat hieraan verbonden is aanvaardbaar te houden. Zorg dat extra beveiligingen ingevoerd door de toepassing niet kunnen omzeild worden door b.v. rechtstreeks de gegevensbank te ondervragen. De personeelsleden met systeembeheerdersrechten vereisen een bijzondere aandacht. Voor de systeembeheerders gelden de normale toegangscontroles niet. Het aantal personeelsleden dat over deze rechten beschikt moet dan ook beperkt gehouden worden. Ga na welke personen binnen de organisatie beschikken over systeembeheerder autorisaties.
6.4 Beheer van gebruikers Het spreekt voor zich dat gebruikersnamen van personeelsleden die de instelling verlaten moeten geblokkeerd worden om misbruiken te voorkomen. Ook de autorisatie van gebruikers moeten goed beheerd worden: als een gebruiker bepaalde autorisaties niet meer nodig heeft moeten ze ook verwijderd worden. De verantwoordelijke voor het instellen van de autorisaties moet over de correcte informatie over de huidige taakverdeling binnen de verschillende diensten beschikken. Indien de autorisaties centraal ingesteld worden moet er een vlotte doorstroming van de informatie georganiseerd worden. Een alternatief hiervoor is het delegeren van het beheer van de autorisaties tot op het niveau diegenen die voor de taakverdeling binnen de diensten instaan. De verantwoordelijke voor de taakverdeling kan dan zelf instaan voor het aanpassen van de autorisaties aan de
52
gewijzigde taakverdeling. Dit vereist uiteraard de nodige discipline van de decentrale beheerders. Zorg er voor dat bij ontslag/vertrek van een personeelslid of bij vermoeden van misbruik alle toegangen tot de computersystemen voor die persoon snel kunnen afgesloten worden. Probeer ook voor zoveel mogelijk consistentie te zorgen: zorg ervoor dat een gebruiker op alle systemen dezelfde gebruikersnaam heeft. Indien mogelijk ook hetzelfde paswoord. Een systeem dat hierbij meer en meer opgang maakt is het “Leightweight Directory Access Protocol” (LDAP). Dit systeem biedt de mogelijkheid om in 1 omgeving de gebruikers te beheren voor alle computersystemen van de instelling.
6.5 Automatisch vergrendelen van een sessie bij inactiviteit Een werkpost van een computersysteem die onbeheerd achterblijft opent uiteraard de mogelijkheid om met de auhorisatie van de vorige gebruiker verder te werken. Vele computersystemen en toepassingen bieden de mogelijkheid om na een korte periode van inactiviteit de werkpost te vergrendelen. Dit verhindert niet geautoriseerde toegang tot de toepassingen, maar in de meeste gevallen heeft dit echter als gevolg dat de werkpost allen terug kan ontgrendeld worden door de originele gebruiker. Eventueel kan hiervoor een oplossing gezocht worden door het mechanisme van het bedrijfssysteem niet te gebruiken, maar te vervangen door een mechanisme in de toepassing. Onderzoek hoe u het beste kan omgaan met werkposten waarop een tijdje geen activiteit meer geweest is..
6.6 Auditing Onder “auditing” verstaan we in dit verband het registreren van bepaalde acties op het computersysteem. De meeste bedrijfssystemen en gegevensbanksystemen bieden de mogelijkheid om audit logs aan te maken. Hierbij kunnen zowel geslaagde acties als door de autorisatieregels geweigerde acties geregistreerd worden. Voorbeelden hiervan zijn een geslaagde authenticatie of een mislukte authenticatie.
53
Dergelijke audit logs zijn onontbeerlijk om onrechtmatig gebruik te kunnen opsporen. Ook kunnen ze helpen om in geval van onrechtmatig gebruik na te gaan wat er exact gebeurd is. Daarom moeten dergelijke logs minstens gedurende enkele maanden bijgehouden worden. De toepassingsprogramma’s kunnen ook dergelijke audit logs voorzien die gebeurtenissen kunnen registreren op toepassingsniveau. Verzeker u er van dat de toepassingssoftware en de systeemsoftware (bedrijfssysteem en gegevensbanksystemen) voldoende auditing informatie registreren om onrechtmatig gebruik te kunnen opsporen. Zorg er voor dat de auditing logs op regelmatige basis nagekeken worden.
6.7 Encryptie en digitale handtekening Encryptie kan binnen een computersysteem gebruikt worden als een extra bescherming voor zeer gevoelige informatie: naast het omzeilen van de toegangscontrole moet men ook de encryptiesleutel kennen om de gegevens te kunnen lezen. De termen “encryptie en digitale handtekening” wijzen meestal naar een situatie waarbij gegevens elektronisch moeten overgebracht worden. Hierbij zal de encryptie er voor zorgen dat alleen de rechtmatige bestemmeling het bericht kan lezen, terwijl de digitale handtekening de afzender onweerlegbaar zal identificeren. Hierbij worden verschillende types algoritmes gebruikt: symmetrische encryptie algoritmes, assymetrische encryptie algoritmes (ook bekend als public-private key algoritmes) en hashing algoritmes. Voor public private key algoritmes zijn er ook nog certificaten nodig. Bij encryptie moeten we er van uitgaan dat een absolute bescherming van geëncrypteerde gegevens onmogelijk is: mits inzet van voldoende rekencapaciteit is het altijd mogelijk om de correcte encryptiesleutel te vinden. Het is dus belangrijk om voldoende lange sleutels te kiezen om deze operatie in de praktijk onuitvoerbaar te maken. Gezien de rekencapaciteit van een individuele computer alsmaar stijgt, moeten ook geleidelijk de sleutellengtes opgetrokken. Dit is dan ook een item dat regelmatig moet opgevolgd worden.
6.7.1
Symmetrische encryptiealgoritmes
Dit zijn encryptie algoritmes waarbij voor de encryptie en de decryptie dezelfde encryptiesleutel nodig is.
54
Deze algoritmes zijn meestal vrij snel in de uitvoering. Het voornaamste probleem is uiteraard dat de encryptiesleutel op een veilige manier moet uitgewisseld worden. Zorg bij het gebruik van symmetrische encryptie algoritmes voor een voldoende sleutellengte: 128 bits is een minimum.
6.7.2
Public-private key algoritmes
Zoals de naam het reeds zegt worden bij public-private key algoritmes 2 sleutels gebruikt: een private die enkel gekend is door de eigenaar van de sleutel en een publieke sleutel die aan iedereen bekend gemaakt wordt. Algoritmes op deze principes gebaseerd, zijn wiskundig zeer complex en vergen dan ook wat meer rekencapaciteit. Het meest in het oog springende voordeel is uiteraard dat zij geen uitwisseling van sleutels vereisen. Als de afzender het bericht encrypteert met de publieke sleutel van de bestemmeling kan enkel de private sleutel van de bestemmeling gebruikt worden om het bericht te decrypteren. Zorg bij het gebruik van public-private key algoritmes voor een voldoende sleutellengte: 512 bits is een minimum.
6.7.3
Certificaten
Bij het gebruik van public-private key algoritmes maken we gebruik van de publieke sleutel van de correspondent. Maar hoe kunnen we zeker zijn dat de sleutel die we gebruiken wel degelijk de sleutel is van de persoon of instelling die we bedoelen ? Het antwoord hiervoor wordt geboden door de “certificaten”. Een certificaat bevat de publieke sleutel en de identiteit van de eigenaar, samen getekend door een “certificatiedienstverlener”. Om een certificaat aan te vragen moet u een publieke sleutel, samen met de identiteitsgegevens van de persoon of instelling waarbij die sleutel hoort aanbieden aan de certificatiedienstverlener. De certificatiedienstverlener zal dan de identiteit controleren en via het certificaat bevestigen dat deze controle uitgevoerd werd. Certificatiedienstverleners hebben meestal verschillende types van certificaten met verschillende niveaus van controle van de identiteit. Welk
niveau
van
controle
van
de
identiteit
uitgevoerd
wordt
beschrijft
de
certificatiedienstverlener in het “Certification practice statement”. 55
De laagste niveaus van controle komen eigenlijk neer op helemaal geen controle en zijn dus enkel geschikt voor test doeleinden. Bepaal het niveau van identiteitscontrole dat nodig is voor uw toepassing en zorg er voor dat alleen certificaten waaraan een voldoende controle gekoppeld is aanvaard worden.
6.7.4
Hashing technieken
Een hashing algoritme berekent een controlegetal van een document. De algoritmes die hierbij gebruikt worden zijn zodanig dat de kans dat 2 verschillende documenten tot hetzelfde controle getal leiden quasi onbestaand is. Bekende algoritmes hiervoor zijn MD5 en SHA1.
6.8 Virussen, wormen en trojaanse paarden Virussen, wormen en trojaanse paarden zijn allen stukjes software die verspreid worden en als doel hebben een computersysteem dingen te laten uitvoeren zonder dat de normale gebruiker hierover controle heeft. Deze stukjes software proberen ook om zichzelf over zoveel mogelijk computers te verspreiden. Gezien de computersystemen die voor bureautica gebruikt worden veruit in de meerderheid zijn, vormen zij ook het meest geliefkoosde doelwit van virussen.. Ga er van uit dat het onmogelijk is om een instelling volledig vrij te houden van virussen e.d.. Om de verspreiding in toom te houden moeten de binnengedrongen virussen zo snel mogelijk verwijderd worden. Om dit te bereiken moeten de computersystemen regelmatig gescand worden. Het kan echter nuttig zijn om extra scanning uit te voeren op de wegen waarlangs virussen de instelling kunnen binnenkomen als b.v. e-mail. Stel een virusbestrijdingsschema op, waarbij minstens alle schijven waarop door een bureautica systeem
beheerde gegevens opgeslagen worden regelmatig gescand worden.
Evalueer of andere maatregelen aangewezen zijn.
56
6.9 Fysische toegang tot computersystemen De fysische toegang tot een computersysteem biedt meestal extra mogelijkheden om de authenticatiesystemen te omzeilen, b.v. door het systeem te herstarten, eventueel met een andere versie van het bedrijfssysteem. Beperk de fysische toegang tot de computersystemen tot bevoegde personen.
6.10 Diefstal van laptops Laptops vormen een specifiek veiligheidsrisico: als een laptop gestolen wordt is niet alleen het toestel verloren, maar heeft de dief ook toegang tot de gegevens die opgeslagen zijn op de harde schijf. Authenticatie helpt hierbij niet, gezien de dief alle mogelijkheden van systeembeheer kan gebruiken om de authenticatie te omzeilen. Er is maar één afdoende oplossing: de gevoelige gegevens versleutelen, eventueel door de volledige schijf te versleutelen. Indien er gevoelige gegevens opgeslagen worden op een laptop, zorg dan voor een versleuteling van die gegevens.
6.11 Toegang voor ondersteuning van toestellen. Meer en meer leveranciers vragen om van op hun kantoor toegang te verkrijgen tot de in het ziekenhuis opgestelde toestellen via modem of Internet. In het kader van de ondersteuning van deze toestellen is dit voor beide partijen een goede zaak: de leverancier kan vlotter ondersteuning bieden en de problemen zijn voor het ziekenhuis sneller verholpen. Indien een toestel ook aangesloten is op het netwerk van het ziekenhuis, zouden de medewerkers van het bedrijf ook kunnen proberen om verder door te dringen in andere computersystemen van het ziekenhuis. Dit betekent dat u de beveiliging van het netwerk van het ziekenhuis ook aan dit bedrijf uitbesteedt. Zorg er voor dat externe bedrijven geen toegang kunnen krijgen tot toestellen aangesloten op het netwerk van het ziekenhuis zonder vraag vanuit het ziekenhuis. Eventuele regelmatige rapportering moet verstuurd worden vanuit het ziekenhuis, niet opgevraagd vanuit het bedrijf.
57
6.12 Internet toegang Alle computersystemen van een instelling afdoende beschermen zodat zij zonder risico’s op het Internet kunnen aangesloten worden is in praktijk onmogelijk. Bovendien zouden de beveiligingsmaatregelen het dagdagelijks gebruik van de computers zeer ernstig hypothekeren. Daarom moet de verbinding met het Internet gebeuren via een firewall, die de toegang vanaf het internet tot de interne computersystemen onmogelijk maakt. Verbindingen waarvoor het initiatief genomen wordt vanuit het ziekenhuis vormen normaal vanuit een beveiligingsstandpunt geen probleem: het initiatief wordt genomen door een personeelslid van het ziekenhuis. Indien u wenst diensten aan te bieden via het Internet overweeg dan om de computersystemen die de diensten aanbieden in een “demilitarized zone” op te stellen zodat, mocht er toch iemand de controle over deze systemen kunnen overnemen er nog altijd geen toegang mogelijk is tot de andere computersystemen van de instelling. Voor diensten waarvoor geen authenticatie gevraagd wordt is dit een noodzaak. Zorg er voor dat voor de andere diensten u een eenvoudig te beheren en te bewaken omgeving opzet, onder andere door slechts 1 kanaal op te zetten dat gedegen bewaakt wordt. Ook hierbij is het aan te bevelen om er voor te zorgen dat alleen de toepassingen die echt nodig zijn ook kunnen bereikt worden. Indien het netwerk van het ziekenhuis met het Internet verbonden wordt, moet dit via een firewall gebeuren. Computers die diensten verlenen via het Internet waarvoor geen authenticatie gevraagd wordt moeten in een “demilitarized zone” opgesteld worden. Voorzie voor andere diensten 1 communicatiekanaal dat optimaal kan bewaakt en gecontroleerd worden. Diensten waarbij gevoelige informatie uitgewisseld worden moeten gebruik maken van versleutelde verbindingen. Zorg er ook voor dat de infrastructuur de gebruiker beschermt tegen “man in the middle” aanvallen. Het baat uiteraard niet om een gedegen firewall infrastructuur uit te bouwen als er ook nog andere minder goed bewaakte toegangen mogelijk zijn naar de computersystemen van het
58
ziekenhuis. Denk hierbij aan PC’s met een modem en PC Anywhere en gelijkaardige produkten. Zorg voor een policy die dergelijke opstellingen verbiedt, gekoppeld aan een sanctioneringsbeleid. Zorg er ook voor dat er geen extra verbindingen mogelijk gemaakt worden rond de firewall.
6.13 Virtuele privé netwerken Een virtueel privé netwerk (VPN) is een privé netwerkverbinding die via het Internet gerealiseerd wordt. Er wordt een tunnel opgezet tussen een computersysteem en het netwerk van een instelling zodat het is alsof de computer deel uitmaakt van het interne netwerk van de instelling en kan gebruik maken van alle diensten van het interne netwerk. Om de beveiliging van het interne netwerk te blijven verzekeren moet er dan ook voor gezorgd
worden
dat
voor
de
via
VPN
verbonden
computers
aan
dezelfde
beveiligingscriteria voldoen als de interne computersystemen: virusscanning, geen extra verbindingen rond de firewall, … Virtuele privé netwerken kunnen enkel gebruikt worden als het beheer van de computersystemen die op afstand opgesteld zijn voldoet aan dezelfde kwaliteitseisen als de interne systemen.
6.14 Toegangscontrole op toepassingsniveau De technieken en aanbevelingen voor de authenticatie, autorisatie en audit op algemeen systeemniveau zijn ook geldig voor de toepassingen. Hieronder geven we alleen een beschrijving van de extra aanbevelingen die in acht kunnen genomen worden voor de toepassingen.
6.14.1 Authenticatie De authenticatie is bij voorkeur gebaseerd op die van het onderliggende beheerssysteem of hiermee gesynchroniseerd. Wanneer
de
authenticatie
voor
de medische toepassingen
dezelfde is dan
of
gesynchroniseerd is met die van de andere toepassingen (e-mail, persoonlijke bestanden, …) houdt het doorgeven van de informatie hiervoor (wat men weet, heeft, … zie p. 46) meer risico’s in zodat gebruikers minder geneigd zullen zijn dit te doen. 59
Eén van de gangbare technieken om dit te realiseren is het gebruik van LDAP.
6.14.2 Autorisatie Bepaal op voorhand welk toegangscontrole model u wenst te gebruiken doorheen het gehele ziekenhuis. Deze keuze moet gebeuren onafhankelijk van de aangeboden oplossingen. Nadien zal deze keuze de mogelijke toepassingen en integratie bepalen (en niet omgekeerd). Bij het bepalen van het toegangscontrole model zijn er verschillende mogelijke toegangsassen waarmee rekening gehouden moet worden: •
Diensten (specialismen): een patiëntendossier per dienst of 1 centraal dossier.
•
Functies (artsen, verpleging, administratie, …): een dossier per functie of 1 centraal dossier voor alle functies.
•
Patiënten: heeft men toegang tot alle patiënten in het systeem of krijgt men alleen toegang tot bepaalde patiënten op basis van een recent contact, …
Het gekozen toegangscontrole model is een combinatie van keuzes in de bovenstaande assen. Hoe meer men kiest voor de verschillende assen om tot 1 centraal dossier te komen, hoe meer vereisten er zijn aan de autorisatiemogelijkheden van de toepassing. Kiest men hier in tegenstelling voor een dossier per dienst, functie en daarbinnen toegang tot alle patiënten, dan zullen de vereisten voor autorisatie minimaal zijn. Er zijn ook mengvormen mogelijk (1 centraal dossier voor alle specialismen maar opgesplitst per functie, …). Dit model zal invloed hebben op de nodige integratie en beperkingen in de toepassingen die worden aangeboden (zie p. 9). In een centraal of gekoppeld systeem waarin meerdere diensten toegang hebben, is een toegangscontrole die zich alleen baseert op de functie, geen goed autorisatiebeleid. Meestal denkt men te volstaan met toegangsregels die zich baseren op de groepen van de gebruikers. Artsen mogen alles zien, verpleging mag wat minder zien, administratie alleen administratieve gegevens. Systemen die alleen maar toelaten toegangsregels te bepalen op basis van de functie kunnen geen voldoende opsplitsing toelaten in de regels voor toegang tot de verschillende patiënten. De gebruikers kunnen dan de gegevens zien die hun functie toelaat voor alle patiënten en dat is een onaanvaardbare situatie indien deze toepassing gebruikt wordt over verschillende diensten. Indien men kiest voor een zeer strikt toegangscontrole model, moet de mogelijkheid bestaan dat de gebruiker dit, na opgave van reden en verdere audit van de acties, kan doorbreken.
60
De informatie waarop de toegangscontrole gebaseerd is, kan alleen historische informatie zijn. In een heel aantal gevallen wenst men toegang tot het dossier omwille van iets dat nog moet ingevoerd worden (en men vanaf dan wel geautoriseerd is om dit op te vragen). Typische voorbeelden zijn: de patiënt zal op raadpleging komen (maar heeft nog geen afspraak); de anesthesist zoekt toegang tot de patiënt om dat deze een ingreep zal krijgen maar de opnameplanning is nog niet ingevoerd. Hoe strikter de toegangscontrole is, hoe meer nood er is om deze te kunnen doorbreken. Als er meer doorbrekingen zijn, moet men deze doorbrekingen strenger onderzoeken. In dit geval zorgt men er best voor dat de redenen die opgegeven worden bij deze doorbrekingen zoveel mogelijk gestructureerd en gecodeerd zijn. Indien het aantal doorbrekingen zeer hoog is, bestaat het gevaar dat de aandacht voor de enkele niet legale doorbrekingen verzwakt door het grote aantal legale doorbrekingen. Daarom moet men in het geval van een groot aantal doorbrekingen snel kunnen uitmaken of een doorbreking al dan niet legaal is. Dit kan men doen door de doorbrekingen gestructureerd en zelfs gecodeerd te maken. Voor de patiënt die op raadpleging zal komen laat men de gebruiker dan een code “patiënt komt op raadpleging” registreren i.p.v. de reden voor deze doorbreking vrij door de gebruiker te laten ingeven. Men kan nadien automatisch deze gecodeerde doorbreking afvlaggen als legaal op basis van de ondertussen beschikbare informatie (b.v. een gemaakte afspraak, een latere patiëntenbeweging, …) Hoe strikter de autorisatieregels zijn, hoe meer ondersteuning er moet gegeven worden van gestructureerde gegevens binnen het systeem om deze regels op te kunnen baseren. Mogelijke gestructureerde gegevens waarop men de autorisatieregels kan baseren zijn: •
Patiëntenbewegingen: door het nauwgezet bijhouden van de fysische aanwezigheid en de bijhorende tijdsmomenten van de patiënten. De fysische aanwezigheid kan binnen het ziekenhuis sterk opgesplitst worden: van minimale aan- en afwezigheid in het ziekenhuis tot een verfijnde opvolging van alle mogelijke plaatsen (medische diensten, functiemetingen, operatiezalen, …).
•
Contacten tussen patiënten en zorgverstrekkers: het registreren van de verantwoordelijke arts, verpleging, sociale werksters, … met een bepaalde patiënt.
•
Informatie in de toekomst: afspraken, geplande ingrepen, …
•
Gebruikersbewegingen: wie wanneer en waar aanwezig is.
Deze gegevens kunnen manueel ingegeven worden (en zijn dan relatief statisch: arts x werkt gedurende 2 jaar op de spoedgevallen, verpleegster y 4 jaar op pediatrie, …). Er zijn ook mogelijkheden om deze gegevens dynamisch en automatisch te registreren (badge systemen
61
waarbij gebruikers hun aanwezigheid op een plaats kenbaar moeten maken, infrarood of radio gestuurde detectie systemen, …). Voor de medische toepassingen kan het noodzakelijk zijn een fijnere of andere hiërarchie van groepen en rollen te moeten definiëren dan deze voor administratieve toepassingen. Ga na of men deze afzonderlijk kan bepalen voor elke toepassing. De groepen en rollen die nodig zijn voor de verschillende toepassingen kunnen tegenstrijdig zijn. Iemand kan binnen de aankoopdienst een beheerdersfunctie hebben maar in het medische dossier slechts administratieve toegang krijgen.
6.14.3 Audit 6.14.3.1 BELEID Bepaal en communiceer op voorhand wat de sancties zijn bij vastgestelde inbreuken. Wanneer men niet op voorhand beslist en gecommuniceerd heeft wat de mogelijke sancties zijn bij inbreuken op de toegangsregels, zullen deze subjectief ingevuld worden op het ogenblik van het incident. Ga na op welk niveau (per patiënt, per gebruiker, globaal) audit kan gedefinieerd worden en voor welke acties (alleen aan- en afmelden, per actie, per actie en de daarbij horende inhoud). Hoe fijner het niveau en de acties, hoe meer controle men heeft over de nodige investering voor opslag van de auditlog of hoe lang men deze kan bewaren. Indien men geen beperkingen heeft voor opslag van de log, bewaart men deze zo lang en zo fijn mogelijk aangezien de meeste inbreuken post-factum gemeld en gedocumenteerd moeten kunnen worden. Het systeem gedraagt zich best gelijkaardig met of zonder log, zodat de gebruiker geen verschil merkt. Indien men merkt dat een bepaalde patiënt, actie,… gelogd wordt en andere niet, heeft men de neiging de niet gelogde acties als legaal te beschouwen. Indien alles gelijk functioneert maar men weet dat er mogelijks iets gelogd wordt, heeft men de neiging alle acties, alle patiënten, … met eenzelfde vertrouwelijkheid te behandelen.
6.14.3.2 AUDIT PER PATIËNT Een log per patiënt instellen kan nuttig zijn voor personen waarvoor het risico op inbreuken groter is dan normaal. Dit is zo voor VIP’s maar ook voor de eigen werknemers en hun familieleden. 62
Hou ermee rekening dat de grootste veiligheidsrisico’s de eigen werknemers zijn, zowel voor het begaan als het slachtoffer zijn van inbreuken. Indien men de mogelijkheid heeft de log per patiënt te activeren moet men dit zeker doen voor alle werknemers omdat de kans hier het grootste is op inbreuken. VIP’s registreert men niet als anonieme patiënten (met een pseudoniem) maar wel onder hun eigen naam waarbij men de log voor deze patiënt activeert. Wanneer VIP’s onder een pseudoniem worden geregistreerd is dit meestal slechts een beperkt aantal personen in het ziekenhuis bekend. Dit betekent juist voor deze patiënten een extra risico op het niet beschikbaar zijn van de op dat ogenblik nodige informatie in geval de patiënt urgent behandeld moet worden.
6.14.3.3 AUDIT PER GEBRUIKER Een audit per gebruiker is nuttig voor gebruikers waarmee geen contractuele bindingen bestaan en de sancties niet even hard kunnen gemaakt worden dan voor de eigen werknemers. Het kan ook zijn toepassing hebben voor gebruikers waarvan men op voorhand niet de autorisaties kan vastleggen maar pas post-factum kan nagaan of de gezochte toegangen legaal zijn. In plaats van deze gebruikers geen autorisaties te geven kan men beslissen volledige autorisatie te geven en post-factum de geregistreerde acties (automatisch te laten) bevestigen. Voorbeelden zijn toegangen tot trialpatiënten, …
6.14.3.4 AUDIT PER ACTIE Men moet niet alleen kunnen loggen wie wanneer (en eventueel waar) welke actie heeft uitgevoerd. Voor documentatie van een inbreuk of voor medico legale redenen is het zelfs nodig te kunnen documenteren welke informatie (de inhoud) men heeft opgevraagd, gewijzigd, …
6.14.3.5 CONTROLEREN VAN DE GELOGDE INFORMATIE Maak de groep van mensen die de logs kunnen nakijken zo groot mogelijk. Maak het nakijken van de logs niet de verantwoordelijkheid van een beperkte groep van personen maar wel van iedereen. Indien de logs moeten nagekeken worden door een beperkte groep van personen, gaan deze moeilijk de geldigheid van de gelogde acties kunnen nagaan. Daarenboven gaat deze kleine groep van personen uit een grote aantal gelogde acties moeten selecteren waar er problemen zijn. Dit gaat alleen kunnen gebeuren door geautomatiseerde en standaard controles. 63
Indien men de logs laat nakijken door een grote groep van personen gaan deze zich beperken tot het nakijken van die gelogde acties waarover zij meer informatie hebben en weten of ze al dan niet legaal zijn. Daarenboven is het aantal te bekijken logs relatief klein wat het een kleine extra taak maakt. Een arts zal makkelijk kunnen uitmaken of de gelogde acties voor de patiënten waarvoor hij de behandelende arts is legaal zijn. Hij weet wie hij een consult gevraagd heeft, wie werkzaam is op zijn afdeling, naar welke technische onderzoeken hij doorverwezen heeft, … Voor een kleine centrale groep kan een heleboel van deze informatie niet elektronisch of gestructureerd ter beschikking zijn, wat het onmogelijk maakt deze gelogde acties voor alle patiënten na te kijken. Er blijven dan te veel gelogde acties over waarover geen uitspraak gedaan kan worden zodat de verdachte gevallen minder snel zullen opvallen.
64
7 Aandachtspunten bij het projectbeheer In dit hoofdstuk is het niet onze bedoeling een bepaalde projectmethodologie aan te bevelen maar wel een aantal aandachtspunten te geven die specifiek zijn voor het opzetten en het uitvoeren van informaticaprojecten binnen een ziekenhuis. Bij aanschaf van een product moet men ernaar streven de eigen organisatie maximaal aan te passen aan de werking van het product en het product minimaal aan te passen aan de eigen organisatie. Bij de aankooponderhandeling zien de gebruikers typisch het product werken volgens hun huidige manier van werken en overtuigen verkopers met mogelijke aanpassingen van het product volgens de lokale manier van werken. Alhoewel dat bij de initiële implementatie de grootste voldoening kan geven, heeft deze beslissing grote gevolgen naar de verdere levensloop van het product binnen het ziekenhuis. De lokale aanpassingen zijn de duurste en steeds weerkerende elementen bij toekomstige ingebruikname van nieuwe versies. Meestal zijn deze aanpassingen omwille hiervan ook de redenen waarom nieuwe versies niet meer of met veel vertraging kunnen ingevoerd worden. Men moet overwegen beter de eenmalige prijs te betalen van de aanpassing van de eigen procedures of de keuze te maken voor een product dat dichter ligt bij de eigen werking (maar eventueel met minder functionaliteit, grotere initiële aankoopprijs, …). Het beslissingsorgaan en het projectteam moeten worden geadviseerd door een groep van gebruikersvertegenwoordigers
waarvan
de
individuele
leden
enerzijds
de
nodige
hiërarchische bevoegdheid hebben en anderzijds zelf met de geadviseerde beslissingen moeten werken. Men moet vermijden dat een product aangeschaft of een oplossing ontwikkeld wordt op basis
van
pure
managements-
of
economische
overwegingen
zonder
dat
een
gebruikersgroep dit kan vertalen naar de gebruikers die er dagelijks mee moeten werken. De leden van deze gebruikersgroep moeten wel voldoende hoog in de hiërarchie van het ziekenhuis zitten zodat de nood van deze overwegingen door hen gekend zijn. Anderzijds moeten deze personen ook met de beslissingen die ze positief adviseren dagelijks geconfronteerd worden in het gebruik. Dit garandeert een evenwicht tussen strikte gebruikersnoden enerzijds en economische en managementnoden anderzijds. De implementatie van een zelf ontwikkeld of aangekocht product vereist een ploeg van werknemers van het ziekenhuis die voldoende vertrouwd is met de werking ervan om de nodige informatie door te geven voor lokale invulling, onderhoud, … en die het product kan testen. Deze personen moeten hier voor de nodige tijd zijn vrijgesteld.
65
De kosten van de aanschaf of de eigen ontwikkeling van een product zijn niet beperkt tot het betalen van de leverancier of de ontwikkelaars maar houden een verborgen kost in van tijdsinvestering van werknemers die in het ziekenhuis andere dan informaticataken hebben. Probeer een schatting te bekomen van de nodige opleiding. Dit houdt niet alleen het geven van deze opleiding in maar ook het verlies aan tijd voor het volgen van deze opleiding door de toekomstige gebruikers. Vaak wordt een te lage schatting gemaakt van de nodige opleiding. Ofwel krijgen de toekomstige gebruikers hiervoor te weinig tijd ofwel besteden deze gebruikers zelf te weinig aandacht aan het bijwonen van de opleidingen. Het grondig op de hoogte zijn van de basiswerking van het product en het juiste gebruik ervan van in het begin, kan echter veel schade en tijd achteraf besparen. Werk vóór de ingebruikname van een nieuw product de noodprocedures uit die gevolgd moeten worden bij uitval. Baseer deze noodprocedures niet op de oude procedures die door het nieuwe product vervangen worden maar maak ze duidelijk anders en veel eenvoudiger. Ga bij het uitwerken van de noodprocedures niet uit van de beschikbaarheid van computerinfrastructuur. Geen enkele technische oplossing kan een 100% uptime garanderen. Zelfs 99,5% uptime betekent 2 dagen uitval op een jaar. Tegen deze realiteit moet men op voorhand procedures uitwerken om deze uitval te overbruggen. Na de succesvolle implementatie van de nieuwe oplossing zal de kennis bij de gebruikers over de oude manier van werken snel vervliegen. Maak daarom de noodprocedures zo eenvoudig mogelijk (maak in zo’n gevallen b.v. keuzes tussen dringende gevallen en zaken die mogen blijven wachten tot dat het systeem terug beschikbaar is). Voor de automatisatie heeft men typisch verschillende formulieren en procedures om alle mogelijke gevallen te ondersteunen. Wanneer deze formulieren en procedures zijn vastgelegd in een computerprogramma zullen de gebruikers vrij snel na het implementeren hiervan, niet meer de veelheid van papieren formulieren en procedures kennen. De noodprocedures maken dan ook best gebruik van sterk vereenvoudigde formulieren en procedures. Beslis of de noodprocedures regelmatig getest moeten worden. Het testen van noodprocedures heeft alleen maar zin indien dit gebeurt wanneer de normale werking ook effectief wordt onderbroken. Om het negatieve effect van deze testen, op een ogenblik dat ze strikt gezien niet nodig zijn, te minimaliseren, kan men deze testen op voorhand aankondigen. 66
Alleen wanneer men de noodprocedures regelmatig test, is men zeker dat iedereen tijdens een echte onbeschikbaarheid van de computers weet wat en hoe men deze onderbreking moet overbruggen. Daarenboven worden de noodprocedures dan continu getest op hun bruikbaarheid en kan men de nodige aanpassingen ontdekken. Tijdens deze testen moet men de systemen waarvoor deze noodprocedures ontworpen zijn, ook effectief onderbreken. Werk een uitrolplan uit waarbij elke fase in zijn geheel wordt aangepakt. Vermijd voor 1 fase een dubbele werking. Bij het ingebruiknemen van nieuwe procedures moet men ervoor zorgen dat men zo snel mogelijk de oude procedures stopt. In vele gevallen heeft men de neiging het nieuwe systeem nog niet volledig te betrouwen en zal men cruciale onderdelen op de oude manier blijven uitvoeren tot men zeker is dat het nieuwe systeem zijn deugdelijkheid heeft bewezen. De redenen hiervoor kunnen zijn dat nog niet alle functionaliteit beschikbaar is, er nog fouten zitten in het nieuwe systeem, niet alle afgeleide rapporteringen mogelijk zijn, … Indien men deze dubbele werking te lang aanhoudt, zal het nieuwe systeem echter nooit zijn goede werking kunnen bewijzen of zullen de gebreken niet voldoende naar boven komen omdat men altijd kan terugvallen op de oude manier van werken. De extra werkdruk door de dubbele werking en het beter vertrouwd zijn met de oude manier van werken, zal daarenboven als effect hebben dat men juist minder gaat werken met de nieuwe procedures. Controleer dan ook na een vooraf afgesproken tijd of alle oude procedures effectief zijn stopgezet en men alleen nog maar de nieuwe gebruikt.
67
8 PACS – “Picture Archiving and Communication Systems” Een PACS (“Picture Archiving and Communication System”) is een deelsysteem voor het beheer van “medische beelden”, inclusief presentatie daarvan op een werkstation. Dit deelsysteem specialiseert zich in beelden die hoge technologische eisen stellen, door de grote datavolumes en de nood aan domein-specifieke presentatie. In deze tekst gaat het om het beheer van de beelden gegenereerd door de dienst Radiologie7. PACS kan dan beschouwd worden als een computersysteem dat de functies overneemt die tot dan toe via film werden gerealiseerd. Daarentegen worden met digitale beelden ook fundamenteel nieuwe opties mogelijk die met film ondenkbaar waren, met name verwerking en analyse van de beelden, met manipulatie van de inhoud van die beelden. Voor de bespreking in deze tekst wordt dergelijke verwerking niet beschouwd als een deel van PACS, maar wordt PACS louter aanzien als de infrastructuur die dergelijke functionaliteiten moet faciliteren.
8.1 Individuele aspecten van een PACS 8.1.1 8.1.1.1
Archivering van de beelden DIMENSIONERING VAN HET ARCHIEF
Een eerste factor die de grootte van het archief bepaalt is het “ruwe volume” aan beeldmateriaal dat men wil opslaan (het aantal beeldpunten * het aantal bytes per beeldpunt). Het is goed doenbaar om dat af te schatten. Het aantal radiologische onderzoeken of het aantal bedden van het ziekenhuis geven reeds een indicatie van de jaarlijkse productie8. Hou er wel rekening mee dat nieuwe beeldvormende toestellen dat volume opdrijven (zie verder). Deze
beelden
worden
meestal
opgeslagen
in
een
gecomprimeerde
vorm.
Een
compressiefactor van 2 (tot 2,5) is haalbaar zonder enig kwaliteitsverlies (reversibele
7
Veel van de aandachtspunten zijn overdraagbaar naar een PACS voor andere medische
beelden, maar technologische details of organisatorische accenten kunnen verschillen. 8
Bij een typische mix van onderzoekstypes en de momenteel gebruikelijke technologie voor
beeldvorming, kan 20 Megabyte per radiologisch onderzoek dienen als eerste ruwe schatting. 68
compressie). Vermeld bij het bespreken van datavolumes steeds of het gaat om grootte vóór of na dergelijke compressie. Beduidend grotere compressiefactoren kunnen worden gehaald indien men bereid is te accepteren dat het beeld na eens gecomprimeerd te zijn lichtjes gewijzigd is t.o.v. het originele beeld (irreversibele compressie). De idee is dat bij matige compressiefactoren (b.v. rond een factor 10) het verschil in de praktijk niet merkbaar is, kleiner is dan andere oncontroleerbare factoren, en geen belang heeft voor het nemen van medische beslissingen. Deze vorm van compressie kan de technologische opties veranderen, en bijvoorbeeld maken dat je voor dezelfde investering snellere toegang tot oudere beelden kan realiseren, wat medisch een beduidend voordeel is (zie volgende sectie)9. Er is evenwel nog geen algemeen aanvaarde consensus over de aangewezen compressiefactoren. Daarom vrezen veel ziekenhuizen dat indien ze bij een eventuele aanklacht wegens medische fouten enkel “gecomprimeerde beelden” ter verdediging zouden kunnen voorleggen, de bewijslast in hun nadeel wordt omgekeerd. Beslis vanuit het ziekenhuismanagement óf en op welke manier gebruik wordt gemaakt van irreversibele beeldcompressie. Ga in elk geval het effect ervan na op kost en functionaliteit van archief en distributiesysteem, daar een eventuele resulterende snellere toegang ook een medisch voordeel is. Indien u opteert voor gebruik van irreversibele compressie, hou ook een versie bij van de beelden zonder gebruik van irreversibele compressie, in een langzamer deel van het archief. De evoluties in de radiologische beeldvorming stellen nieuwe uitdagingen aan PACS. Een eerste gegeven is dat de nieuwere beeldvormende toestellen, en zeker CT- en MR-scanners, steeds meer beelden genereren en/of beelden van hogere resolutie10. Een tweede, meer recent gegeven, is de verwachte opkomst van opnametechnieken waarbij een dataset wordt gegenereerd waardoorheen de gebruiker interactief kan navigeren. Daarmee vervaagt de notie van een beeld: uit die dataset kan een “oneindig” aantal beelden worden gegenereerd. Een vraag die hierbij kan worden gesteld is of álle beelden moeten worden bijgehouden11.
9
Er is geen technologisch voordeel om die compressie reeds uit te voeren vóór de radioloog
de beelden heeft bestudeerd. 10
Het is goed mogelijk dat voor de volgende jaren de groei in hoeveelheid geproduceerd
beeldmateriaal hoger ligt dan de groei in capaciteit van opslag– en communicatiesystemen. 11
Bij de filmgebaseerde werking werd het ook gebruikelijk om bij tomografie met dunne
sneden slechts een subset van die sneden af te drukken voor verdere distributie. Bij 69
Het is nog niet duidelijk hoe belangrijk de verschillende technologische evoluties deze vraag zullen maken. Als u gebruik maakt van tomografische beeldvorming met veel sneden, neem vanuit het ziekenhuismanagement een beslissing over wélke van die data bewaard moeten worden.
8.1.1.2
HIERARCHISCHE ORGANISATIE VAN HET ARCHIEF
Door de hoeveelheid gegevens die moet worden opgeslagen, is het gebruikelijk om een archief voor PACS op te delen in verschillende niveaus. Een “working set” van beeldonderzoeken wordt beschikbaar gehouden op magnetische schijf. Onderzoeken die een tijd niet opgevraagd werden zijn enkel beschikbaar op langzamere media in een robot, of eventueel enkel offline. Om bij deze organisatie niet geconfronteerd te worden met lange wachttijden als de beelden uit een robot moeten komen (minuten i.p.v. seconden) wordt “prefetching” gebruikt: beelden waarvan de kans groot wordt geacht dat ze zullen nodig zijn, worden automatisch gereed gezet op magnetische schijven. Dit vereist informatie over patiëntenbewegingen (uit andere informatiesystemen) en regels die bepalen wélke onderzoeken moeten worden gereedgezet. Dergelijke regels vallen nog op te stellen voor de operaties intern in de dienst Radiologie (“als de patiënt komt voor dit type onderzoek, zet dan de vorige twee onderzoeken van hetzelfde orgaan gereed”), maar veel moeilijker voor gebruik van beelden doorheen de rest van het ziekenhuis. Evenwel, met de dalende kost/volume verhouding van magnetische schijven kan het tegenwoordig worden overwogen om toch radicaal alle opslag op magneetschijf te voorzien, zeker als men geopteerd heeft voor gebruik van irreversibele compressie. Alle moeilijkheden met en nadelen van prefetching worden daarmee vermeden. De eventuele meerkost moet worden afgewogen tegen eenvoud in beheer. Neem i.v.m. de globale organisatie van het opslagsysteem volgende twee beslissingen: (1) of een hiërarchie wordt opgebouwd met daarin langzame componenten (wat prefetching vereist), en (2) of oudere beelden enkel offline worden bijgehouden (wat manuele acties vereist als men die beelden wil bekijken).
echografie,
een
interactief
onderzoek,
beslist
de
radioloog
eender
hoe
welke
momentopnamen ter illustratie worden bijgehouden. 70
8.1.1.3
SYMMETRIE IN DE TOEGANG TOT HET ARCHIEF
De grote datavolumes maakten het tot voor kort een technologisch uitdaging om de beeldonderzoeken snel (orde van seconden) op te vragen. Een al eens gebruikte methode om de technologische eisen te verminderen is de beelden op voorhand door te sturen naar de werkpost(en) waar ze vermoedelijk zullen worden gebruikt, of naar een lokaal deelarchief. Als je deze “prerouting” moet uitvoeren om die beelden vanuit die werkposten te kunnen oproepen, geeft dit beduidende beperkingen in de organisatie. Met de hedendaagse technologie voor netwerken en archieven is het gebruikelijker om een archief te gebruiken van waar alle werkposten alle beelden op een symmetrische manier kunnen opvragen12, wat veel handiger is in gebruik. Vermijd in de mate van het mogelijke een architectuur waarbij je op voorhand moet weten vanaf welke werkposten je welke beelden zal opvragen. Indien de snelheid van de verbindingen een probleem is, bijvoorbeeld bij operaties op twee verschillende locaties met lage bandbreedte daartussen, kan het juist een voordeel zijn als het PACS mechanismen heeft om expliciet op voorhand een kopie van de beelden gereed te zetten op de andere locatie. De extra kost door de complexiteit van het systeem (inclusief het onderhoud en de mindere flexibiliteit), moet evenwel worden afgewogen tegen de kost voor een grotere bandbreedte. Weeg bij “intelligente oplossingen” om met technologische beperkingen om te gaan maar waarbij je voorspellingen moet doen, af of een “brute force” gebruik van technologie uiteindelijk niet goedkoper is.
8.1.1.4
BACKUP EN CONTINUITEIT VAN WERKING
Database-technologie is maar een deel van het verhaal De beelden worden over het algemeen niet opgeslagen in een database, enkel de referenties naar die beelden en meta-informatie over die beelden (het eigenlijke “beeldmanagementsysteem”).
12
Eventueel sneller als het systeem een kopie in een lokale cache vindt, maar dat systeem
werkt transparant. 71
Backup & restore Uiteraard is een frequente backup van het eigenlijke beeldmanagement-systeem cruciaal. Deze database heeft geen uitzonderlijke omvang en de gebruikelijke backup-strategieën zijn geschikt. Daarentegen zijn deze backup-strategieën onbruikbaar voor het eigenlijke beeldmateriaal, gezien het volume daarvan. Evenwel hebben de beelden de eigenschap dat ze niet meer worden gewijzigd. Beveiliging tegen verlies van een individueel beeld, typisch door een mediafout, kan dus door eenmalig een kopie weg te schrijven op een onafhankelijk medium op een andere locatie (en de integriteit van deze kopie te verzekeren, volgens de gekende technieken). Beveiliging tegen vernietiging van het gehele archief of een belangrijk onderdeel daarvan, vormt een speciale uitdaging. De vragen zijn (1) hoe snel je opnieuw kan werken (eventueel met lagere performantie) door de kopieën van de beelden te gebruiken, en (2) hoe snel je het originele archief opnieuw kan opbouwen. Als alle beelden inclusief een kopie online staan op snelle media (ongebruikelijk) dan gaat dat allicht redelijk snel. Als de kopie offline wordt bijgehouden, dreigt één en ander zeer lang te duren. Je bent bij recovery allicht aangewezen op speciale ondersteuning van de software van het PACS. Immers, de beelden moeten geïndexeerd blijven vanuit het managementsysteem, de aansturing van de data-opslag kan specifiek zijn voor de robot(s), en daar je moeilijk kan wachten tot eerst een nieuwe reservekopie is gemaakt en het archief volledig in orde is gebracht vooraleer de operaties in het ziekenhuis te herstarten, moet de software ermee rekening houden dat het archief slechts gedeeltelijk beschikbaar is. Werk samen met de leverancier van het PACS een procedure uit voor het verderzetten van de operaties nadat een groot deel van het archief is vernietigd. Schat in hoelang deze procedure zal duren (tijd totdat werking mogelijk is met aanvaardbare beperkingen, versus tijd tot de originele situatie hersteld is). Indien de reservekopieën van de beelden offline worden bijgehouden, ga op zijn minst na of de software van het PACS toelaat deze kopieën dadelijk te gebruiken nadat ze in een nieuwe robot (mogelijks van ander type dan de vorige) geladen werden. Wijzigen of uitbreiden van het opslagsysteem Gezien de specifieke organisatie van het archief kan het van de software van de PACSleverancier afhangen hoe het archief kan worden uitgebreid. Gezien het volume aan gegevens kan het omzetten van een bestaand archief naar een nieuw archief lang duren, vooral als het om een near-line component gaat.
72
Bespreek met de leverancier van het PACS in detail welke mogelijkheden voorzien zijn om het archief uit te breiden of componenten ervan te vervangen (waarbij gegevens moeten worden overgezet).
8.1.1.5
CONSOLIDATIE VAN OPSLAGNODEN
Opslag, en het beheer ervan, wordt een belangrijke kost in ziekenhuizen. Ga na of je een gezamenlijk opslagsysteem kan gebruiken voor PACS en andere toepassingen waarbij veel data worden opgeslagen. Dat vereist dat het PACS gebruik kan maken van deze “3rd party” oplossing. In de vroegere PACS systemen was dat zeker niet vanzelfsprekend, gezien die de neiging hadden eigen software te voorzien voor het aansturen van de verschillende hiërarchieën in het opslagsysteem. In toenemende mate gebruiken deze systemen evenwel standaard oplossingen en kan dit zeker besproken worden.
8.1.2
Distributie van radiologische beelden doorheen het ziekenhuisnetwerk
De invoering van PACS kan een argument zijn om het netwerk sneller te maken. Met de huidige technologie is het netwerk binnen een gebouw geen knelpunt meer voor de invoering van PACS, en allicht ook niet de grootste kostfactor. In de meeste gevallen wordt geen gescheiden netwerkinfrastructuur gebruikt voor het PACS. De voor beelden te voorziene bandbreedte naar de gebruikers doorheen de gehele instelling wordt beïnvloed door de keuze van de “klinische viewer” (sectie 8.1.5) daar deze component al eens geoptimaliseerd wordt naar een zekere zuinigheid met bandbreedte. Er is voldoende ervaring bij de leveranciers van het PACS of bij gebruikers om suggesties te geven i.v.m. vereiste bandbreedte.
8.1.3
Koppelen van de beeldvormende toestellen
Digitale koppeling versus “secondary capture” Quasi alle nieuwe beeldvormende toestellen voor Radiologie kunnen digitaal aan het netwerk worden gekoppeld (zie volgende punt over DICOM). Indien een ouder toestel niet digitaal kan worden gekoppeld, is een mogelijkheid om de beelden te digitaliseren vanuit de analoge uitgang die wordt gebruikt om b.v. een printer aan te sturen. Het resultaat is dan alsof een afdruk op film zou zijn gescand. De functionaliteit voor het verder werken met die beelden is beperkter.
73
Een bijzonder probleem bij dergelijke “secondary capture” is het doorgeven van patiënt- en onderzoeks-IDs. Een mogelijke techniek is om deze via automatische karakterherkenning af te leiden uit de tekst die afgedrukt is op de “film”. Dat is evenwel onbetrouwbaar (zie sectie 8.2.3). DICOM De DICOM-standaard werd ontwikkeld voor het uitwisselen van medische beelden en daaraan gerelateerde gegevens. Deze standaard wordt in de radiologische wereld (en meer algemeen in PACS) ruim ondersteund. DICOM legt twee zaken vast: •
Codering (in hoge mate van detail) van beeldinformatie, inclusief acquisitieparameters, ruimtelijke verbanden tussen de beelden, informatie over patiënt en onderzoek,…
•
Een (complex) protocol voor communicatie naar een entiteit die een welbepaalde dienst aanbied voor die beelden (opslaan, afdrukken,…).
Verschillende DICOM-diensten Een toestel kan “DICOM compliant” zijn zonder daarom alle DICOM-diensten te ondersteunen. De meest gebruikelijke diensten worden hieronder kort beschreven: •
Image Storage definieert hoe een toestel een set beelden moet doorsturen naar een andere node, b.v. naar een PACS.
•
Storage Commitment is een verfijning van de vorige functie voor een archief, en geeft feedback als de beelden veilig werden weggeschreven (en dus b.v. van de modaliteit kunnen worden gewist).
•
Modality Worklist definieert hoe het ZIS informatie over patiënt en onderzoek naar het beeldvormende toestel kan sturen zodat die informatie in de digitale dataset kan worden opgenomen (Zie sectie 8.2.3 p. 84 voor de motivatie).
•
Print dient om over het netwerk een reeks beelden af te drukken op een DICOM printer. Allicht is een dergelijke printer voorzien voor afdruk vanaf de PACS-werkposten. De mogelijkheid om af te drukken vanaf het beeldvormende toestel is nuttig voor noodprocedures.
•
Performed Procedure Step laat het beeldvormende toestel toe te melden dat een (deel van een) onderzoek werd uitgevoerd en “administratieve” informatie te leveren over de beelden en de procedure, waarmee een PACS of ZIS verdere operaties kan initiëren of kwaliteitscontrole realiseren.
•
Query/Retrieve laat een onafhankelijk systeem toe om beelden uit een PACS op te vragen en een lokale kopie ervan te maken (zie sectie 8.1.4 p. 75, het deel over gespecialiseerde werkposten).
74
Probeer op alle beeldvormende toestellen die je aan het PACS wil koppelen op zijn minst de DICOM functies “Image Storage” en “Modality Worklist” te activeren. Bespreek met de leverancier van het PACS welke andere DICOM diensten door dat PACS nuttig kunnen worden gebruikt en ga beschikbaarheid daarvan na met de leveranciers van de beeldvormende toestellen. Niveau van integratie met DICOM DICOM is een communicatiestandaard, bedoeld voor uitwisseling van beeldgegevens tussen onafhankelijke systemen. DICOM dient niet om een hechte integratie te bekomen van toepassingen met beelden en b.v. een gezamenlijk beheer of een overkoepelende user interface te realiseren.
8.1.4
Viewing voor primaire diagnose
Functionaliteit, technologie en omstandigheden voor interactieve studie van beelden Er is momenteel voldoende ervaring met diagnose op werkstation, zodat we in deze tekst daar niet verder op ingaan. Ook bespreken we hier geen aspecten zoals het uitvoeren van metingen op de beelden, ijking van de beeldschermen, of realiseren van de juiste belichtingsomstandigheden. Selectie van onderzoeken, werklijsten Het systeem moet “werklijsten” opbouwen waaruit de te bestuderen onderzoeken kunnen worden geselecteerd. In de niet-geautomatiseerde organisatie bestaat de werklijst uit een stapel filmfardes, waarbij het meest dringende onderzoek bovenop werd gelegd. Bij volledig digitale werking verdwijnt de “token value” van papier en moet alle informatie expliciet door de computer worden gepresenteerd. Als verschillende radiologen samenwerken aan een pakket van onderzoeken, moet het systeem werklijsten synchroniseren over verschillende werkposten en vermijden dat verschillende radiologen starten met verslaggeving van een zelfde onderzoek. Ga na waar er in de huidige organisatie wordt gerekend op de “token value” van papier of film. Ga na of deze functie voldoende wordt overgenomen door de digitale werklijsten op de werkpost voor beeld-viewing, en waar er bijkomende informatie in het computersysteem moet worden gebracht. “Bookmarking” van beelden Het gaat hier om de mogelijkheid een verzameling van beelden te selecteren als bijzonder relevant of illustratief, bijvoorbeeld om later bij vergelijken van onderzoeken efficiënt de te 75
vergelijken beelden terug te vinden. Er is minder ervaring met deze functie, maar gezien de toename van de hoeveelheid beschikbare beeldmateriaal, zal ze belangrijk worden. Filtering van beelden Het kan de politiek van de beeldvormende dienst zijn om enkel een samenvatting van het beeldonderzoek (zie vorige punt) door te sturen naar de aanvrager, of deze samenvatting als een bijkomend gegeven samen met de andere beelden,… Het kan niet als vanzelfsprekend worden aangenomen dat het PACS juist de gewenste werkwijze ondersteunt. Indien het beeldvormende toestel zeer veel dicht op elkaar liggende sneden genereert, kan het de bedoeling zijn om een subset van beelden met grotere afstand daartussen te gebruiken doorheen het verdere proces. Dan moet het PACS mechanismen voorzien om dat te automatiseren. “Slechts een subset van de beelden ter beschikking stellen” kan door enkel díe beelden bij te houden (p. 70), of door de andere beelden enkel bij te houden in een langzamer deel van het archief (of in een deel voor de beeldvormende dienst), of door die subset gewoonweg eenvoudiger of sneller oproepbaar te maken, wat dan eerder over ergonomie en efficiëntie gaat dan over beperkingen. Er moet op beleidsniveau worden beslist in hoeverre slechts een subset van de beelden vanuit de beeldvormende dienst wordt doorgestuurd naar de rest van de instelling. Een andere zaak is of het PACS deze beslissing technisch kan implementeren zonder al te veel manuele acties te vereisen. Gebruik van werkposten van een andere leverancier op het PACS De user interface op de werkposten is sterk gekoppeld aan het niet-gestandaardiseerde managementsysteem van het PACS. Het is dan ook onmogelijk om de “viewing stations” van de leverancier van dat PACS op een transparante manier te vervangen door werkposten van een andere leverancier. Wat wel mogelijk is, is beeldonderzoeken uit te wisselen met een andere werkpost, die b.v. gespecialiseerde visualisatie of chirurgieplanning ondersteunt. De verdere manipulatie van de beelden op die andere werkpost gebeurt van dan af onafhankelijk van het PACS, en zonder de beheersfuncties aangeboden door dat PACS. Een eerste mogelijkheid is om die beelden door te zenden vanuit het het PACS (“DICOM Image Storage”). Een tweede mogelijkheid is om die gespecialiseerde werkpost toe te laten een lijst in het PACS aanwezige onderzoeken op te vragen die aan bepaalde criteria voldoen en zelf onderzoeken over te halen (“DICOM query/retrieve”).
76
Als je beelden wil uitwisselen met gespecialiseerde werkposten, voorzie je daarop best de geëigende DICOM functies. Hou er rekening mee dat de beeldmanipulaties en –verwerking op die werkposten onafhankelijk staat van het PACS. Beheer van resultaten van gespecialiseerde verwerking of –analyse Een veel voorkomende reden om beelden uit te wisselen met een aparte werkpost is om daar gespecialiseerde verwerkingen uit te voeren. De resultaten daarvan kunnen beelden zijn maar misschien ook getallen of gespecialiseerde voorstellingen. Het is niet vanzelfsprekend dat deze resultaten terug kunnen worden gezonden naar het PACS voor opslag en verder beheer, zeker als het om gegevens gaat waarvoor DICOM geen standaard voorziet. Als je zou willen dat resultaten van verwerking op onafhankelijke werkposten worden beheerd in het PACS, moet je in detail met de betrokken leveranciers nagaan of dat wel mogelijk is, en of de daarvoor nodige expliciete communicatie het deze opzet de moeite waard makt. Weeg af of de verwerking niet binnen het PACS kan gebeuren. Toegangscontrole Toegangscontrole vanuit de werkposten van het PACS moet in dat PACS expliciet worden voorzien. Zoals voor elk deelsysteem moet dan ook voor het PACS worden nagekeken hoe de algemene politiek voor toegang kan worden geïmplementeerd. Een alternatief is om de selectie van de onderzoeken te laten gebeuren in het ZIS of het RIS (sectie 8.2.2) en dus toegangscontrole naar dat systeem te delegeren. Als de beelden werden doorgestuurd naar een werkpost of systeem buiten het PACS, ligt de toegangscontrole van dan af uiteraard in handen van dat andere systeem. Een bijzonder probleem is dat er bij de “DICOM query retrieve” functie geen verfijnde toegangscontrole mogelijk. Het PACS weet o.a. niet welke gebruiker op het andere systeem de opvraging doet. Beperkt gebruik van de DICOM “query/retrieve” functie tot systemen waarvoor je toegangscontrole hebt. Het is met DICOM wel mogelijk om de beeld-transfer te initiëren vanaf een ander systeem dan datgene waarop de beelden staan of waarop ze moeten toekomen. Het is dus technisch realiseerbaar om b.v. dat doorzenden te initiëren vanaf het ZIS, waarin je toch toegangscontrole moet verzekeren.
77
8.1.5
Viewing doorheen de kliniek
“Clinical viewing” gaat over het bekijken van de beelden buiten de beeldvormende dienst, b.v. door de aanvrager van het (radiologische) onderzoek. Bij de meeste systemen wordt daarvoor andere software aangeboden dan voor gebruik binnen de beeldvormende dienst. De klemtoon bij die software kan dan meer liggen op een intuïtieve user interface voor deze meer occasionele gebruikers, op integreerbaarheid met andere componenten van het klinische werkstation, of op een grotere zuinigheid in technologische vereisten. Daardoor worden functies weggelaten of vereenvoudigd. Er kan ook minder aandacht zijn besteed aan zaken zoals het omgaan met gekalibreerde beeldschermen. Je moet de beleidsbeslissing nemen of alle werkposten worden uitgerust met de “radiologische” software, of buiten de beeldvormende dienst enkel de “klinische viewing” software wordt voorzien, dan wel of ook buiten de beeldvormende dienst een combinatie van beide werkposten worden gebruikt. Uiteraard is het bij een combinatie van beide de vraag of je daarmee de voordelen van de twee mogelijkheden verkrijgt of vooral een combinatie van de nadelen. Wat daarbij kan meespelen is dat je dan voor de twee systemen de integratie met het ZIS en toegangscontrole moet realiseren (aspecten die buiten de beeldvormende dienst een sterkere klemtoon hebben dan daarbinnen). Gespecialiseerde werkposten zoals b.v. voor chirurgieplanning blijven eender hoe buiten deze discussie. Functionaliteit, technologie en omstandigheden voor interactieve studie van beelden Er is minder ervaring met het gebruik van digitale viewing door heterogene groepen klinische gebruikers. Betrek daarom zeker van bij het begin van het project verschillende representatieve gebruikers bij de beoordeling van mogelijke systemen (zie p. 65). We willen er wel even op wijzen dat dynamische navigatie doorheen een reeks beelden met de nieuwe beeldvormende technieken aan belang wint. Er is daarvoor geen analoog in de filmgebaseerde werking, zodat de klinische gebruikers daar allicht minder ervaring mee hebben. Het is gebruikelijk om binnen de dienst Radiologie de beeldschermen regelmatig te ijken. Dat is moeilijk te organiseren doorheen de gehele instelling, zeker als die beeldschermen daarvoor niet speciaal zijn ontworpen, als ze ook moeten dienen voor presentatie van andere gegevens dan beelden, en als de afregeling niet vastgezet kan worden. Trouwens, allicht is ook het omgevingslicht niet steeds hetzelfde, al is het maar omdat de gebruikers voor hun andere taken veel licht nodig hebben terwijl bekijken van details in beelden over het algemeen een duistere omgeving vereist.
78
Selectie van onderzoeken, werklijsten Op een klinische dienst wordt een beeldonderzoek benaderd vanuit het gehele dossier van de patiënt. Onder andere om die reden wordt ook bij commercieel beschikbare systemen meer en meer de mogelijkheid voorzien om de beelden te selecteren vanuit de primaire user interface van het overkoepelende informatiesysteem (sectie 8.2.2, p. 82). “Bookmarking” van beelden en annotaties op beelden In het filmgebaseerde systeem maken klinische gebruikers vaak een eigen samenvatting van beelden, b.v. door markeringen op de film aan te brengen. Zo kan b.v. voor het opvolgen van tumortherapie een referentiesnede worden aangeduid die men snel wil terugvinden bij het later vergelijken met een nieuw onderzoek. Bespreek met de leverancier van het PACS welke mogelijkheden er zijn om beelden of delen van beelden te indexeren (of te annoteren) en hoe dergelijke selecties of aanduidingen kunnen worden beheerd. Bepaal een politiek voor het aanbrengen of wijzigen daarvan, en kijk na of het PACS die kan ondersteunen. Annotaties gemaakt vanuit de diagnostische dienst mogen niet door gebruikers buiten die dienst gewijzigd worden. Toegangscontrole Gedetailleerde toegangscontrole is nog belangrijker buiten de beeldvormende dienst dan erbinnen. Dat kan trouwens ook een motivatie zijn om het oproepen van de beeldonderzoeken te laten gebeuren in het overkoepelende informatiesysteem (sectie 8.2.2, p. 82).
8.2 Integratie van PACS in de gehele informatica-oplossing Door het hoogtechnologische karakter van een PACS heeft men al sneller de neiging om vooral aandacht te besteden aan de technische aspecten. Nochtans is integratie in de gehele informaticaoplossing essentieel. Een stand-alone PACS kan niet aan de verwachtingen voldoen.
8.2.1
“Back office” integratie van PACS in het overkoepelende informatiesysteem
De term “back office integratie” wordt hier gebruikt omdat het gaat om een koppeling door informatie-uitwisseling tussen computersystemen, los van en grotendeels onzichtbaar voor de interactieve gebruiker (Figuur 8). Dit is geen gestandaardiseerde term.
79
Exam scheduling info Patient info
HIS/RIS
PACS
Info for PACS user
Figuur 8. Het ZIS moet informatie doorsturen naar het PACS. Sommige informatie is nodig opdat het PACS de beeldonderzoeken zinvol zou kunnen beheren (in de globale context) of automatismen zou kunnen aansturen. Andere informatie is vooral bedoeld voor organisatie van de gebruikersinterface op de beeld-werkposten.
Doorsturen van administratieve en logistieke informatie naar het PACS Het PACS moet van het ZIS/RIS informatie krijgen over verwachte patiënten en uit te voeren onderzoeken. Alle wijzigingen in patiëntgegevens in het ZIS/RIS en “patiënt merges” moeten naar het PACS worden doorgedrukt. Het gaat op zijn minst om IDs van onderzoek en patiënt (gebruikt in het ZIS) en om de naam van de patiënt. Een fundamentele reden is uiteraard om in het beeldmanagement-systeem over dezelfde entiteiten te kunnen spreken dan in het ZIS (zie p. 26). Een bijkomende specifieke reden is opdat het PACS zou kunnen controleren of de binnenkomende beeldonderzoeken wel degelijk kunnen worden toegewezen aan een welbepaalde patiënt en gekoppeld aan een onderzoek in het overkoepelende informatiesysteem (meer daarover in secties 8.2.3 en 8.2.4). Een mogelijke verdere reden is om het PACS toe te laten prefetching (p. 70) en prerouting (p. 71) aan te sturen 13. Een vaak gebruikte methode voor deze informatie-uitwisseling is communicatie van boodschappen in de HL/7 standaard. Het kan een voordeel zijn als het PACS meer mechanismen voor deze uitwisseling aankan, daar HL/7 niet het meest eenvoudig te implementeren protocol is (zie p. 13).
13
Uiteraard impliceert gebruik van die informatie voor prefetching dat je die informatie ruim
op voorhand moet doorsturen, en dus dat ze ruim op voorhand in het ZIS beschikbaar moet zijn. 80
Doorsturen van verslagen naar het PACS Als er diagnostische beelden worden bekeken, is de kans groot dat men ook het verslag wil inzien. Dat verslag wordt evenwel beheerd buiten het PACS. Er kan dan geopteerd worden voor uitwisseling van deze verslagen tussen ZIS en PACS, bijvoorbeeld zodat je eerdere verslagen kan bekijken vanuit de viewing-software. Uiteraard heb je daarmee de gebruikelijke problemen van replicatie van gegevens in twee systemen (zie p. 18). Een alternatief is om een koppeling te voorzien op het niveau van de user interface (het gaat uiteindelijk puur om presentatie), als beschreven in sectie 8.2.2, p. 82. Maak het een beleidsbeslissing of je verslagen wil uitwisselen met het PACS (opdat ze van daar af kunnen worden opgevraagd). Indien je dat voorziet, zorg er dan ook voor dat de kopie steeds up-to-date is. Doorsturen van taakondersteunende informatie naar het PACS Bij de bespreking van radiologische viewing werd benadrukt dat ergonomische werklijsten belangrijk zijn (p. 75). Opdat het beeldwerkstation dergelijke lijsten zou kunnen opbouwen, heeft het informatie nodig uit externe systemen. De interactieve gebruiker wil misschien een lijst krijgen van onderzoeken aangevraagd door een bepaalde arts, of vanuit een bepaalde eenheid, of waarvan nog geen verslag gemaakt werd14. Een eerste vraag daarbij is of het PACS de informatie die je wil effectief kan gebruiken. De tweede vraag is hoe je die informatie zal doorsturen (ook de wijzigingen daarin). Ga na welke informatie er nodig is in de user interface (werklijsten, opzoekmechanismen) van de beeldwerkstations en die niet reeds aanwezig is in het PACS. Dat houdt in dat je in detail het proces van het werken met beelden moet analyseren. Hou er bij het definiëren van de workflow rekening mee dat er vertraging kan zitten op het doorgeven van deze informatie. Kijk na of het PACS mechanismen heeft om die informatie te accepteren en te gebruiken (dit is niet gestandaardiseerd). Een redelijk gebruikelijke informatie-communicatie is ook deze van de aanvraag en klinische vraagstelling naar het diagnostische werkstation, in organisaties waardoor daarmee de radioloog het meeste werk kan verrichten vanuit dat werkstation zonder naar andere informatiesystemen te moeten omschakelen.
14
Dat laatste gegeven kan soms ook in het beeldwerkstation worden aangegeven, maar in
veel organisaties is het robuuster als de informatie komt van het systeem waarin effectief het verslag wordt ingegeven. 81
8.2.2
“Front office” integratie van PACS in een overkoepelende gebruikersinterface
Met de term “front office integratie” geven we de integratie aan op het niveau van user interface, zodat de gebruiker op zijn minst de indruk krijgt in interactie te treden met één enkel overkoepelend informatiesysteem (Figuur 9). In de context van PACS is dat zeker relevant voor de clinici, daar voor hen beelden maar een deel zijn van de beschikbare informatie (misschien een technologisch “zwaar” deel, maar met maar beperkt belang). Een eerste voordeel voor integratie in de user interface is voor de hand liggende ergonomie doordat patiënt en/of onderzoek niet opnieuw zou moeten worden opgezocht in de andere toepassing. Een tweede voordeel van “front end” blijkt uit de discussie in de vorige sectie. Veel van de informatie die je “back end” communiceert dient uiteindelijk puur voor gebruikersinteractie in het andere systeem (presentatie van verslagen, sorteren van werklijsten per eenheid…). Vaak is het technisch eenvoudiger om in plaats daarvan de user interface functie te laten verzorgen door het systeem dat onmiddellijk alle gegevens heeft. Een derde voordeel is dat je op een consistente manier een beleid kan opleggen. Bijvoorbeeld, op verschillende plaatsen in dit hoofdstuk werd toegangscontrole vermeld. Als het oproepen van de beeldonderzoeken enkel in het ZIS kan gebeuren (en de viewer van het PACS dus door dat ZIS wordt aangestuurd), kan ook alle toegangscontrole centraal in dat ZIS gebeuren.
HIS/RIS
Exam scheduling info Patient info
PACS
This is any result or…
Figuur 9. In dit voorbeeld worden beelden opgeroepen vanuit de user interface van het klinische werkstation. Je hebt daarbij vanzelf de vertrouwde context en selectiemechanismen, en een deel van de informatie-uitwisseling uit Figuur 8 wordt onnodig.
Het primaire systeem voor selectie De vraag stelt zich welk systeem het “primaire systeem” moet zijn voor selectie van informatie uit werklijsten. Gezien de beperkte ervaring met front office integratie moet ook pragmatisch gekeken worden naar de beschikbare mogelijkheden. 82
Voor klinische viewing is het duidelijk dat de gebruikersinterface van het algemene patiëntendossier het meest geschikte startpunt is. Dat systeem heeft het meeste van de relevante context om krachtige opzoekmechanismen te voorzien of werklijsten te presenteren (b.v. van patiënten die aan deze gebruiker toegewezen zijn, op een bepaalde afdeling aanwezig zijn, of waarvoor een raadpleging gepland is). Dat systeem heeft ook de context voor toegangscontrole. Voor gebruik binnen de dienst radiologie kan worden aangevoerd dat de loutere beschikbaarheid van beelden veel van de workflow aanstuurt en dat de werklijsten geoptimaliseerd zijn naar de specifieke taak met beelden. De radioloog zou dan het onderzoek kunnen selecteren op het beeldwerkstation, waarna het ZIS/RIS de klinische inlichtingen en andere informatie presenteert en ondersteuning biedt voor het ingeven van het verslag. Beslis van bij de start van het PACS-project welke integratie op het niveau van de user interface je nastreeft (daar dat een verschuiving geeft in de vereiste inspanningen voor ontwikkeling). Beslis dan ook welk het primaire systeem is voor selectie van patiënt en onderzoek. Beschikbare technieken Het HL/7-consortium werkt aan de CCOW standaard voor dergelijke “visuele integratie” van informaticatoepassingen (zie p. 24). Het is te vroeg om van een uitgerijpte standaard te spreken, en de voorziene functionaliteit is al bij al nog beperkt. In afwachting voorzien veel PACS-aanbieders op een ad-hoc manier mogelijkheden om hun systeem aan te laten sturen dan wel om in overleg met andere aanbieders deze laatste hun systemen aan te sturen (technologisch is het inderdaad eenvoudig om in de ene of andere technologie een “event” naar een andere toepassing te sturen). Er is de laatste jaren opmerkelijke vooruitgang geboekt in de aanvaarding van de idee dat de verschillende toepassingen van verschillende leveranciers moeten samenwerken. Stel je evenwel nog niet te veel voor van de implementatie. Bijvoorbeeld, als je de klinische viewer van buitenaf kan oproepen met de instructie om dadelijk een beeldonderzoek te tonen, maar je moet die viewer heropstarten om een ander onderzoek te presenteren, dan verlies je veel van de ergonomie. Bij gebruik van een context-synchronisatie zoals via CCOW blijft het zichtbaar dat het om twee aparte toepassingen gaat. Tevens is het niveau van detail waarmee je de andere toepassing kan aansturen beperkt. Het andere uiterste is dat de leverancier van het ene systeem een software component aanlevert die de leverancier van het andere systeem in de
83
eigen toepassing integreert, wat een zeer hechte integratie mogelijk maakt (zie p. 24)15. Gezien de vooruitgang in componentraamwerken in het algemeen, kan verwacht worden dat dit principe in toenemende mate zal worden gebruikt. Als je integratie van user interfaces nastreeft tussen PACS en andere systemen, bespreek de mogelijkheden in detail met de betrokken leveranciers, daar dit helemaal niet gestandaardiseerd is. Ga na of de geïmplementeerde integratie ook werkbaar is bij complexe navigatie doorheen het gehele dossier van de patiënt. Bijkomende aandachtspunten De hechtheid van de visuele integratie kan de verlangde verfijning van aansturing beïnvloeden. Je moet beelden kunnen vergelijken, wat vlotte navigatie doorheen beeldonderzoeken vereist. Navigatiemechanismen van het ZIS hebben als voordeel dat ze de specifieke organisatie reflecteren en de ruimere aanwezige context benutten. Daarentegen, als de viewer zodanig geïntegreerd is dat je voor elke navigatie terug moet gaan naar een venster in het ZIS, kan het uiteindelijk handiger zijn om enkel aan de viewer te laten doorgeven om welke patiënt het gaat en interactieve navigatie doorheen de verschillende onderzoeken van die patiënt binnen die viewer te laten verzorgen. Naarmate “rond de beelden” meer gebruik gemaakt wordt van annotaties, samenvattingen, metingen en dergelijke, verhoogt het verband tussen die beelden en informatie of context in het overkoepelende informatiesysteem. Het beheer van die items kan allicht krachtiger en eenvoudiger worden door het te centraliseren in het ZIS. Hier is evenwel nog weinig ervaring mee.
8.2.3
Informatie-uitwisseling met de beeldvormende toestellen
IDs in de doorgestuurde DICOM dataset In de DICOM dataset die naar het PACS gestuurd wordt, is er een veld voor de patiënt-ID en een veld voor de ID waarmee het externe informatiesysteem verwijst naar dit beeldonderzoek (“accession number”). Deze attributen worden over het algemeen ingegeven aan het beeldvormende toestel (dat de DICOM boodschap genereert). Ingeven van patiëntgegevens aan het toestel is ook
15
Zowel beeldpresentatie als communicatie met het achterliggende archief zijn
gespecialiseerde functies. De component in de user interface brengt daardoor zijn eigen systeem achterliggend systeem mee. 84
gebruikelijk in de filmgebaseerde werking. Maar bij PACS is het essentieel dat rigoureus de juiste IDs worden ingegeven. Dit kan niet worden gegarandeerd als de invoer gebeurt door manueel intypen. Vermijd waar maar mogelijk dat patiënt- en onderzoeks-ID manueel op het beeldvormende toestel moeten worden ingegeven, maar zorg dat deze elektronisch uit het overkoepelende informatiesysteem worden overgenomen. Technieken De meest gebruikte methode bij “radiologische” beeldvorming is het doorsturen van gegevens over geplande onderzoeken naar het beeldvormende toestel via de DICOM “Modality Worklist” functie. De operator moet dan uit die lijst de juiste entry selecteren. Deze DICOM-communicatie kan dadelijk vanuit het ZIS gebeuren. Evenwel kan ook het PACS de taak van de communicatie met deze toestellen op zich nemen. Het PACS krijgt immers van het ZIS toch informatie over geplande onderzoeken (back office integratie, p. 79), zodat dat ZIS enkel enige bijkomende gegevens moet aanleveren waarmee het PACS kan bepalen welk toestel aan te sturen (Figuur 10). Deze taak van aansturing is niet eenvoudig. Zo moet ermee rekening worden gehouden wanneer juist (“welke dag”) het onderzoek gepland is. Er zijn gespecialiseerde “interface engines” (zie p. 17) op de markt die het verkeer tussen ZIS, PACS en beeldvormende toestellen verzorgen, en een lijst van nietDICOM compatibele toestellen kunnen aansturen. Als je een beeldvormend toestel aan het PACS wil aansluiten en je hebt nog geen precies idee van de beste methode om IDs automatisch op dat toestel te kijken, kijk dan alvast na of de “DICOM Modality Worklist” functie gebruikt kan worden. Sluit evenwel niet dadelijk andere opties uit, b.v. rechtstreeks aansturen van dat toestel vanuit de selectie in het ZIS/RIS, wat handiger kan werken als je op dat toestel veel korte onderzoeken uitvoert (waardoor selectie uit een lange lijst omslachtig wordt) en de operator voor de algemene organisatie toch in het ZIS/RIS moet aangeven dat je met dat onderzoek bezig bent.
85
Patient & exam IDs
Patient & exam IDs
HIS/RIS
Patient & exam IDs
PACS
Procedure type Scheduling info
Figuur 10. Het is essentieel dat de beeldvormende toestellen de externe IDs voor patiënt en onderzoek elektronisch uit het globale informatiesysteem betrekken, zodat deze correct in de gegenereerde DICOM datasets kunnen worden opgenomen. In dit voorbeeld maakt het PACS werklijsten voor de meeste modaliteiten uitgaande van informatie uit het ZIS, terwijl een ander toestel dadelijk vanuit het ZIS (in de praktijk vanuit het RIS) wordt aangestuurd.
Bijkomende aandachtspunten Bij de “Modality Worklist” is het het beeldvormende toestel dat een nieuwe werklijst opvraagt, b.v. om de paar minuten. Er moet dan ook op een zekere vertraging worden gerekend tussen invoer in het ZIS/RIS en beschikbaarheid van de gegevens op het toestel. Zorg ervoor dat het onderzoek in het ZIS aangemaakt is vóór het beeldvormend onderzoek wordt gestart. (Het “onderzoek” slaat op het object waaraan het beeldonderzoek wordt gekoppeld.) Zeker als onderzoeken kunnen doorgaan op verschillende toestellen en de gegevens naar al die toestellen werden gezonden, kom je tot lange werklijsten die onpraktisch worden. De werklijst op het toestel moet ook terug worden opgekuist. Dit kan niet steeds automatisch (je wilt b.v. in staat zijn om nog een beeld bij te nemen). Het beeldvormende toestel kan eventueel enkel werklijsten presenteren die voor “vandaag” gepland zijn, maar dat veronderstelt dan weer dat de datum op dat toestel juist staat en dat uitstel in onderzoeken effectief in het informatiesysteem ingegeven wordt. Uiteraard moet manuele invoer wel mogelijk blijven, b.v. om operaties met het beeldvormende toestel te kunnen starten als de informatie in het overkoepelende systeem niet (tijdig) ter beschikking is.
86
8.2.4
Correctie van fouten in het PACS
Doordat het PACS weet welke onderzoeken te verwachten (p. 80) kan het controleren of de binnenkomende DICOM datasets de juiste IDs van patiënt en/of onderzoek bevatten (Figuur 11). In sommige gevallen, als manueel invoer vereist was, kunnen er nog inconsistenties zijn. Het is nodig om deze beeldonderzoeken te kunnen bekijken “voor noodgevallen” (binnen de beeldvormende dienst) maar ze kunnen niet nuttig gebruikt worden doorheen het gehele ziekenhuis. Zorg ervoor dat fouten in identificatie van de onderzoeken snel manueel kunnen worden gecorrigeerd (ook tijdens nacht- en weekenddiensten). Zorg ervoor dat fouten worden gemeld zo dicht mogelijk bij de plaats waar ze zijn opgetreden. Correctie achteraf of personen die niet het onderzoek hebben uitgevoerd vereist grondige kennis van de organisatie en van beeldvorming ! Voorzie in een meer strikte discipline van de operatoren dan in de filmgebaseerde situatie. Een venijnige fout is b.v. het selecteren uit een “modality worklist” van een ander gepland onderzoek van dezelfde patiënt. Voorzie feedback mechanismen om de operatoren op fouten te wijzen, wat o.a. impliceert dat de radiologen foute identificaties moeten melden.
IDs DICOM data set
IDs
HIS/RIS
IDs
PACS
=
≠
This is any result or…
Manual correction Figuur 11. De informatie-uitwisselingen tussen ZIS, PACS en beeldvormende toestellen beschreven in de vorige secties laten het PACS toe enige controle uit te voeren op binnenkomende beeldonderzoeken. Bij afwezigheid van deze mechanismen zijn evenwel manuele correcties vereist.
87
9 Telematica Telematica gaat over het ondersteunen, d.m.v. informatietechnologie, van operaties waarbij een grotere afstand in het spel is. “Afstand” kan hierbij gaan om: •
Fysische afstand, waardoor (1) beperkingen van communicatietechnologie meespelen en (2) beveiliging gebaseerd op fysische barrières wegvalt.
•
Het feit dat de informatie-uitwisseling gaat buiten je eigen ziekenhuis, waardoor je (1) geen invloed hebt op de systemen en manier van werken aan de andere kant, en (2) moet werken zonder de algemene informatiecontext die je wel binnen je eigen werking hebt.
De belangrijkste aandachtspunten bij telematica zijn een gevolg van dat tweede punt. Indien enkel de fysische afstand speelt, gaat het om telewerken. We bespreken telewerken niet in deze tekst, tenzij om enkele verschillen aan te halen met de situatie waar je communiceert met personen buiten je eigen ziekenhuis. In dit hoofdstuk wordt eerst extra de aandacht gevestigd op aspecten van beveiliging die met telematica bijzonder belangrijk worden. Dan worden enkele technieken besproken voor informatie-uitwisseling tussen personen zonder dat daarbij die informatie langs beide zijden in een medisch dossier zit. Tenslotte worden mogelijkheden en aandachtspunten gegeven voor tele-informatie-uitwisseling in het kader van het medische dossier.
9.1 Beveiliging bij telematica Aandachtspunten voor beveiliging werden reeds gegeven in hoofdstuk 6. In deze sectie worden die aspecten hernomen die bij gebruik van telematica bijzonder belangrijk zijn, en aangevuld met enkele aspecten vanuit deze specifieke toepassing. De aandachtspunten die in die andere hoofdstukken reeds gegeven werden, worden hier niet expliciet hernomen.
9.1.1
Definiëren van verantwoordelijkheden
Een belangrijke component bij beveiliging is het leggen van verantwoordelijkheid bij de gebruiker, met daaraan gekoppeld de mogelijkheid tot sanctioneren. Als je via telematica gevoelige informatie of diensten ter beschikking stelt van externen, moet je ervoor zorgen dat die gebruikers ook op hun plichten gewezen worden en verantwoordelijkheid dragen. Maar tegelijk moeten ook verantwoordelijkheden meer algemeen worden uitgesproken. Maak rond beveiliging en verantwoordelijkheden juridische afspraken met de externen. Er is ook de relatie tussen het ziekenhuis en de patiënt. Misschien heeft de patiënt liever niet dat zijn of haar gegevens doorgegeven worden naar informatiesystemen van andere 88
zorgenverstrekkers. Daar het gebruik van telematica op dit terrein een nieuw gegeven is, worden veel situaties niet voorzien in de algemene regelgeving. Ga na of voor het elektronisch communiceren van patiëntengegevens “informed consent” van de patiënt nodig is.
9.1.2
Beveiligen van de communicatie
Eén vorm van onrechtmatige toegang tot gegevens is het “afluisteren” van de communicatie. Bij een lokaal netwerk wordt dat risico beperkt doordat de kraker zich fysisch bij de infrastructuur moet bevinden. Bij telematica-netwerken verhoogt het risico enorm, niet enkel omwille van het langere en minder bewaakte fysische pad naar de partner, maar ook omdat de knooppunten in dat externe netwerk op zich weer van elders bereikbaar zijn. Het Internet is hier bijzonder kwetsbaar. De boodschap kan worden doorgestuurd langs (en vaak zelfs bijgehouden op) knooppunten die beheerd worden door organisaties die niet de mogelijkheden hebben om een beveiligingspolitiek te voeren en niet verantwoordelijk kunnen worden gesteld voor inbreuken door derden. Er is geen formeel briefgeheim op het Internet. Langs de andere kant is het Internet organisatorisch juist een dankbaar medium voor samenwerking tussen allerlei gezondheidswerkers (zie sectie 9.3.2.2, p. 100). De manier om met dit gegeven om te gaan is encryptie, best van de volledige communicatie (zie p. 54). Er bestaan technieken om te controleren of de boodschap tijdens de communicatie (moedwillig) werd veranderd, en om te controleren of het bericht wel degelijk afkomstig is van je partner (zie p. 56).
9.1.3
Authenticatie van de gebruikers
Bij telematica hoeft een persoon zich niet fysisch nabij het systeem te bevinden om te proberen informatie op te vragen, wat de inbraak vereenvoudigt16. Indien een brede groep van gebruikers waarover je geen controle hebt, toegang heeft tot een dienst (zoals een publieke Web-site), dan mag iemand die inbreekt in de computers die deze dienst verzorgen nog steeds geen toegang kunnen krijgen tot de computersystemen in het ziekenhuis die gevoelige informatie bevatten of van waaruit gevoelige operaties mogelijk zijn (zie p. 58).
16
Een bijkomend probleem daarmee is dat iemand kan proberen in te breken “voor de
sport”, terwijl het niet sportief zou worden gevonden om de gegevens fysisch te gaan stelen. 89
Als je een gebruiker van buitenaf toegang moet geven tot gevoelige informatie, zijn sterke authenticatiemethoden vereist (zie p. 46). Dit betekent steeds dat je voorafgaand afspraken maakt met die gebruiker en apparaten of sleutels uitwisselt.
9.1.4
Inperken van bedrijfslogica in de client-software
Ook wanneer je zeker bent van de betrouwbaarheid van de persoon die toegang vraagt, is er het risico dat de werkpost waarmee deze persoon toegang krijgt geïnfiltreerd is. Je hebt over die werkpost immers niet dezelfde controle als over deze binnen je eigen ziekenhuis. Daardoor kan je niet vertrouwen op enige beperking die je zelf geïmplementeerd hebt in de software die je aan die persoon hebt verschaft. Stel, bijvoorbeeld, dat die software een verbinding naar de database opent en een aantal “veilige” opvragingen doet. Een hacker kan proberen die verbinding naar de database op zich te misbruiken. Volgens dezelfde redenering kan je niet vertrouwen op eender welke vorm van toegangscontrole die in die toepassing geïmplementeerd werd. Je kan er ook niet zeker van zijn dat de bedrijfslogica in die toepassing correct wordt uitgevoerd en dus je interne systeem in een consistente toestand houdt. De software bij de clients mag geen functies bevatten die niet mogen omzeild worden, zoals toegangscontrole of belangrijke bedrijfslogica. De software op de server mag er niet vanuit gaan dat opvragingen of oproepen van diensten door de tele-software “well behaved” zijn. Een eerste veiliger methode is om al dergelijke opvragingen, toegangscontrole, en bedrijfslogica te concentreren in componenten binnen het ziekenhuis (in een “middle tier”) van waaruit enkel welbepaalde methoden ter beschikking worden gesteld van de teletoepassing (zie p. 8)17. Ook dan nog moeten die interne componenten rekening houden met “parameter tampering”, maar naarmate de set van aanroepbare methodes beperkter is kan hier beter tegen beveiligd worden.
17
Een mogelijk nadeel van sterk doorgedreven gebruik van dit principe is een tragere
respons voor gebruikersacties die sterke wisselwerking vereisen tussen de user interface en de bedrijfslogica. Dat argument speelt minder bij toepassingen die expliciet bedoeld zijn voor gebruik buiten het ziekenhuis, waarbij allicht toch een eenvoudiger user interface wordt nagestreefd. 90
Een tweede veiliger methode is enkel de grafische user interface te laten lopen op de werkpost, maar de eigenlijke toepassing op de servers van het ziekenhuis, door middel van technieken met “terminal servers” (populair in Windows omgevingen) of “display servers” (zoals b.v. bij gebruik van X-Windows). Een voordeel hier is dat bestaande toepassingen dadelijk kunnen ingezet worden. Langs de andere kant kan het niet wenselijk zijn om personen van buiten het ziekenhuis zonder meer dezelfde toepassing te laten gebruiken als internen, gewoonweg omdat zij door onbekendheid met het systeem te veel foutieve acties kunnen doen. Deze oplossing is dan ook eerder geschikt voor telewerken.
9.1.5
Gedetailleerde toegangsregels en externe artsen
Gedetailleerde toegangscontrole is gebaseerd op informatie in het computersysteem over de relatie tussen arts en patiënt. Dergelijke informatie is in veel mindere mate beschikbaar voor de externe artsen (die externe arts is allicht niet verbonden aan een bepaalde afdeling van het ziekenhuis, heeft misschien geen in het dossier genoteerde medische contacten gehad met de patiënt,…). Houd er rekening mee dat de bestaande toegangsregels voor medische gegevens informatie kunnen vereisen die over de externe arts niet in het interne systeem beschikbaar is, zodat je andere regels moet implementeren.
9.2 Technologie voor tele-interactie tussen personen Er zijn enkele redelijk gestandaardiseerde methoden waarbij het doel is om personen te laten samenwerken zonder fysische verplaatsingen. Het is niet onze bedoeling sterke aanbevelingen te geven, en zeker geen kwaliteitscriteria, maar we halen wel een paar aandachtspunten aan. Bij informatie-uitwisseling via video conferencing, data conferencing, e-mail,… wordt deze informatie bij de communicatiepartner niet geïntegreerd in een informatiesysteem. Beschouw dit dan ook niet als een middel om informatie uit te wisselen tussen medische dossiers.
91
Organization 1
Organization 2
Record 1
Record 2
Other healthcare actor
Local record
Figuur 12. Bij de technieken van tele-samenwerking besproken in deze sectie is er interactie tussen personen maar geen informatie-uitwisseling tussen de medische dossiers. In het beste geval gebruiken de personen informatie uit hun eigen dossier in het gesprek of tonen ze deze aan hun communicatiepartner.
9.2.1
Video conferencing
Niveau van verwachtingen De kwaliteit van visuele informatie bij videoconferentie is aan de lage kant. Het is de bedoeling om een “meeting experience” te geven, niet om subtiele details over te brengen. De gebruikelijke standaarden gaan uit van de “CIF” resolutie van 352x288 punten, zowat de helft in beide richtingen van de resolutie van televisie en dat is op zich reeds veel minder dan op een computerscherm. Bij voldoende bandbreedte en verwerkingssnelheid worden de bewegingen dan wel vloeiender weergegeven, maar de resolutie blijft beperkt. Gebruik gangbare videoconferentie-technieken niet als een manier om beelden of tekst in hoge kwaliteit te bespreken. Om documenten van op afstand in detail te bespreken is “data conferencing” meer aangewezen (sectie 9.2.2, p. 94). Uiteraard, als de kwaliteit weinig belang heeft, en het materiaal enkel nodig is ter illustratie van de discussie, kan het voldoende zijn om het voor de camera te houden of om te schakelen naar een aparte document-camera. Als vooral de “meeting experience” van belang is, zorg dan voor voldoende kwaliteit van geluid, eventueel ten koste van beeldkwaliteit.
92
Het is meer storend wanneer je de andere zijde moeilijk verstaat dan wanneer het beeld af en toe hapert. Eén aspect hierbij is het optreden van echo’s, wat voorzieningen voor “echo cancellation” kan vereisen. Vereiste netwerkcapaciteit Bij videoconferentie is de vertragingstijd in de communicatie relevant en heb je een gegarandeerde bandbreedte nodig. Om die reden is gebruik van ISDN populair, daar een gegarandeerde bandbreedte wordt gecombineerd met bijna universele beschikbaarheid. De bandbreedte van ISDN is evenwel laag. Bij de huidige compressietechnieken worden vaak verschillende ISDN-lijnen in parallel gebruikt. De meeste telecommunicatieaanbieders kunnen synchrone verbindingen leveren met hogere gegarandeerde bandbreedte, maar dat moet geval per geval besproken worden. Videoconferentie d.m.v. het IP-protocol, b.v. over het Internet, is aantrekkelijk door de flexibiliteit. Er zijn aparte standaarden voor. Op dit ogenblik kan je evenwel over het publieke Internet geen gegarandeerde bandbreedte krijgen. Als je die toch wil, moet je afspraken maken met alle betrokken aanbieders van Internetcommunicatie. De vorige vereisten voor bandbreedte gaan ervan uit dat communicatie wordt opgezet tussen twee locaties. Als het om meerdere locaties gaat kunnen paarsgewijze bijkomende communicaties worden opgezet of kan één knooppunt verantwoordelijk worden gemaakt voor de regie waarna een samengesteld signaal wordt doorgegeven (met hoge bandbreedte en gespecialiseerde apparatuur en bediening in dat knooppunt). De aanbieder van de telecommunicatiekanalen kan dat ook als bijkomende dienst aanbieden. Organisatie De “regie” van beeld en geluid is niet vanzelfsprekend. Voor vergaderingen met meerdere personen, zeker als af en toe documenten in beeld gebracht moeten worden, of voor uitzendingen waarbij kwaliteit van de bewegende beelden belangrijk is (beeldcompositie, inzoomen, lichtreflecties,…) kan het nodig zijn iemand te voorzien die met kennis van zaken de camera(s) bedient. Als kwaliteit van de videoconferentie van belang is, overweeg of investering in juiste bediening van de apparatuur niet zinvoller is dan bijkomende investering in apparatuur.
93
9.2.2
Data conferencing
Als de gegevens in digitale vorm beschikbaar zijn op de werkpost van één van de deelnemers, kunnen die gegevens met dezelfde kwaliteit worden zichtbaar gemaakt op de werkpost aan de andere zijde van de communicatie. Bij een “electronic whiteboard” is op alle aangesloten werkposten een venster zichtbaar waarin elk van de deelnemers informatie kan plaatsen vanuit de lokale omgeving. Op deze in de discussie gebrachte informatie kunnen door alle deelnemers onder meer markeringen worden aangebracht. Bij “application Sharing” is de user interface van een programma dat draait op één werkpost ook zichtbaar op de andere aangesloten werkpost(en). Eventueel kan de controle van dat programma (“muis en toetsenbord”) worden doorgegeven aan een andere deelnemer. Om die reden wordt ook al eens gesproken van een “shared desktop”. In een whiteboard kan je enkel gestandaardiseerde media inbrengen. Het accepteert b.v. niet rechtstreeks een radiologische beeldenreeks in DICOM. Om interactieve navigatie doorheen een dergelijke beeldenreeks te realiseren (doorheen tientallen beelden lopen, interactief contrast aanpassen) is application sharing nodig. Voor de meer basale toepassingen volstaat een beduidend lagere bandbreedte dan deze voor videoconferentie. Maar voor de in vorige paragraaf vermelde interactie op reeksen van beelden kan er juist een hoge bandbreedte vereist zijn. In de wereld van teleradiologie worden al eens gespecialiseerde toepassingen gebruikt die deze beperkingen omzeilen18, maar elke partner in de communicatie moet dan dezelfde gespecialiseerde software gebruiken. Als je in hoge kwaliteit complexe interacties wil uitvoeren op grote reeksen beelden (typisch voor radiologie-toepassingen, en dan nog vooral voor primaire diagnose), moet je een afweging maken tussen gebruik van gestandaardiseerde toepassingen die een grote bandbreedte vereisen, of specifieke radiologische oplossingen.
18
Bij de standaard-toepassing vereist elke interactieve aanpassing van de beeldpresentatie
dat een nieuwe “scherm-beeld” worden doorgestuurd. Je kan voor deze specifieke toepassing de beelden slechts eenmaal doorsturen en van dan af enkel commando’s die de presentatie ervan wijzigen, 94
9.2.3
“Delayed time” interactie door uitwisselen van bestanden
Het “real time” aspect van de vorige technieken betekent dat alle personen tegelijk aanwezig moeten zijn. Voor veel toepassingen is de meest efficiënte werkwijze nog het doorsturen van gegevens waarna de bestemmeling deze asynchroon bestudeert. Gebruik telematica-technologie waarbij personen terzelfder tijd aanwezig moeten zijn, zij het op verschillende plaatsen, enkel als er effectief “real time” interactie nodig is. Elk type bestand kan worden doorgestuurd via e-mail, maar doordat de boodschap op tussenliggende computers moet worden opgeslagen, is de totale lengte van een boodschap beperkt. Om grote boodschappen te versturen (b.v. sets van beelden) is gebruik van een server waarop de ene partij ze zet en de andere ze afhaalt, meer algemeen bruikbaar dan e-mail. Naast beveiliging, ook tussen gebruikers onderling, moet je ook een organisatie opzetten om de gegevens op die server gereed te zetten, op te kuisen… Het wordt meer en meer gebruikelijk om toegang tot die server te voorzien via een Web interface, wat niet alleen een toelaat om een specifieke gebruikersinterface te voorzien, maar ook mogelijkheden geeft om extra beheer van de gegevens te realiseren. De communicatiepartner moet over de software beschikken om de gegevens te lezen. Ga na of belangrijke meta-informatie of organisatorische informatie over de verschillende informatie-item ook kan worden weergegeven. Dat lijkt vanzelfsprekend. Bij complexe datatypes, b.v. reeksen radiologische beelden, is het dat echter niet. Misschien kan de “viewer” van je communicatiepartner wel die beelden zien maar worden posities niet in mm gegeven terwijl je in een bijhorend verslag daar wel op rekent… (zie ook sectie 9.3.2, p. 98).
9.3 Tele-koppeling van en tele-toegang tot medische dossiers We
bespreken
enkel
situaties
waarbij
er
communicatie
is
tussen
onafhankelijke
gezondheidswerkers (ziekenhuizen of artsen voor deze tekst). Indien daarentegen verschillende ziekenhuizen samensmelten en besluiten een gezamenlijk dossier uit te bouwen, zijn de integratietechnieken besproken in hoofdstuk 2 van toepassing waarbij enkel de technologie voor de communicatie verandert (en voor wat betreft beveiliging een VPN aangewezen is).
95
Enkele kenmerken van deze situatie, en de daarin ingebakken beperkingen, zijn dan ook: •
De structuur van de medische dossiers is en blijft verschillend. Er is in de praktijk immers
hoegenaamd
geen
standaard
voor
dat
dossier.
Er
is
zelfs
geen
gestandaardiseerde manier van werken, en in veel gevallen niet eens een gestandaardiseerde verzameling begrippen. •
Je hebt slechts beperkte invloed op de technologie bij je communicatie-partners.
Het is dan ook a-priori onrealistisch om een sterke integratie te verwachten tussen de verschillende systemen. Het zal om losse koppelingen gaan, waarbij zeker de workflowondersteuning beperkt is.
9.3.1
Uitwisselen van informatie tussen onafhankelijke medische dossiers
In deze situatie wordt informatie gekopieerd van het ene dossier naar het andere. Nadien wordt die informatie op de twee plaatsen onafhankelijk beheerd (Figuur 13).
Organization 1
Organization 2
Record 1
Record 2
Other healthcare actor
Local record
Figuur 13. Uitwisseling van informatie tussen medische dossiers, waarbij de verschillende artsen elk met hun eigen dossier interageren. Er is vooral interactie met de locale dossiers, terwijl de informatieuitwisseling tussen die dossiers onderling beperkt is.
9.3.1.1
ORGANISATORISCHE UITDAGINGEN
Een eerste probleem is dat een gemeenschappelijke betekenis moet worden afgesproken voor de gegevens die worden uitgewisseld. Het is allicht aanvaardbaar om de volledige tekst van een radiologisch verslag op te vatten als één item, maar afspraken, opnameberichten, probleemmeldingen,… moeten bijkomende gestructureerde informatie bevatten wil een computersysteem er actie op kunnen nemen. In de meeste gevallen kan dan ook enkel een “grootste gemene deler” aan informatie gestructureerd worden uitgewisseld. 96
Een tweede probleem is dat een gemeenschappelijke context van die gegevens gedefinieerd en gecodeerd moet worden: •
Deze context bevat op zijn allerminst de patiënt. Dat veronderstelt dat eenzelfde patiëntidentificatie gebruikt wordt in beide dossiers of dat een automatische vertaling mogelijk is (zie sectie 3.1.1, p. 26).
•
In de meeste gevallen is er eventueel meer context nodig. Een radiologisch resultaat refereert naar een bepaald type onderzoek, naar een aanvraag met klinische vraagstelling,… Ook hier zal enkel een “grootste gemene deler” van items overblijven met in de beschrijving een lager niveau van detail dan gangbaar in beide dossiers.
Een derde probleem is de afbeelding van de structuur van het verzendende dossier op deze van het bericht en vandaar op deze van het ontvangende informatiesysteem. Voor dat ontvangende systeem moet er misschien rekening mee worden gehouden dat informatie die van buiten komt niet dezelfde referenties heeft als interne informatie. Bijvoorbeeld, een extern radiologisch verslag heeft misschien geen aanvrager in het interne systeem, of de patiënt die nog niet werd ingeschreven in het interne systeem moet eerst worden aangemaakt en ook daarvoor moet gebruik worden gemaakt van de beperkte informatie in de doorgestuurde boodschap. Een uitspraak als “we zullen dossiers uitwisselen” moet vertaald worden naar welke exacte informatie-items, met specifieke betekenis, zullen worden uitgewisseld. Dat vereist dat een model wordt gemaakt van de informatie in beide systemen en in het bericht, en dat deze modellen op elkaar worden afgebeeld. Dat vereist keuzes over het niveau van detail of structuur in die uitwisseling, en allicht aanpassingen in de organisatie van het ontvangende systeem.
9.3.1.2
ARCHITECTUUR EN TECHNOLOGIE VOOR COMMUNICATIE
Voor communicatie tussen twee ziekenhuizen is dadelijke verzending van zender naar ontvanger geschikt19. Bij verzending naar computersystemen in privé-praktijken, die minder geschikt zijn om als server op te treden, is een handiger architectuur deze waarbij berichten naar een centraal knooppunt worden gezonden dat ze buffert tot het andere systeem ze op eigen initiatief komt halen.
19
We gaan er in deze sectie vanuit dat de ontvanger niet op eigen initiatief informatie mag
opvragen, al is het maar omdat dat een sterkere afstemming vraagt op de bedrijfsprocessen bij de zender (zie volgende secties). 97
De technische opties voor data-uitwisseling en de aandachtspunten beschreven in sectie 2.4 blijven gelden. Recente ontwikkelingen in communicatietechnologie in de sfeer van het WWW hebben duidelijk potentieel voor de “losse koppeling” tussen verschillende systemen in een telematica setting20. Enkele begrippen zijn “XML” (voor het gestructureerd coderen van de gegevens), “SOAP” (voor het verzenden van dergelijke berichten), en “Web-services” voor het vanop afstand aanroepen van diensten. Houd er rekening mee dat bij gebruik van communicatie-hulpmiddelen in de sfeer van XML er nog evenzeer de noodzaak is om nauwkeurige afspraken te maken over de betekenis van de uitgewisselde informatie-items. Indien u deze technologie wil gebruiken voor informatie-uitwisseling tussen dossiers, raden we aan om voor een mogelijke benadering (technisch zowel als inhoudelijk) kennis te nemen van “aanbeveling 4” van de Belgische Commissie "Standaarden inzake Telematica ten behoeve van de sector van de Gezondheidszorg" (werkgroep “Data”)21.
9.3.2
Interactieve tele-toegang tot het dossier binnen een ziekenhuis
Zowat de tegengestelde benadering van gegevensuitwisseling uit de vorige sectie, is om de externe arts vanop afstand interactieve toegang te geven tot het dossier van je ziekenhuis (Figuur 14). Er is in dit geval geen integratie met het lokale dossier van die arts. De verbanden tussen de contexten in beide dossiers worden enkel “mentaal” gemaakt. In tegenstelling tot bij de vorige techniek, wordt die arts geconfronteerd met de verschillen in organisatie van beide dossiers. Tegen dat nadeel staat dat álle beschikbare informatie uit het “centrale dossier” wordt aangeboden, binnen een sterke structuur, zonder dat compromissen moeten worden gemaakt i.v.m. vertalingen daarvan naar een lokaal dossier. Daartoe kan ook informatie
20
De concepten zijn doordacht, er is een sterke standaardisatie, en door de brede
verspreiding van die technologie zijn er efficiënte ontwikkel-tools beschikbaar en is de kans groot dat er rekening mee werd gehouden bij de implementatie van allerlei producten zoals voor firewall-beveiliging. 21
http://www.health/fgov.be/telematics/cnst/nl/an.htm 98
behoren die enkel relevant is in dat centrale dossier en waarvan het niet zinvol is dat ze in een ander dossier wordt opgeslagen (b.v. contactpersonen voor de verpleging), informatie die snel verandert (b.v. de locatie van de patiënt), informatie waarvan lokale opslag technisch bedenkelijk is (b.v. grote reeksen beelden), of informatie die zo specifiek is dat het moeilijk is er lokaal een “viewer” voor te voorzien. Het gebrek aan integratie tussen de dossiers van externe arts en ziekenhuis maakt automatische workflow tussen die systemen onmogelijk. Langs de andere kant is enige interactieve sturing van de workflow in het ziekenhuis door die externe arts relatief eenvoudig te realiseren.
Organization 1
Organization 2
Record 1
Record 2
Other healthcare actor
Local record
Figuur 14. Tele-interactie van externe artsen met het dossier van een ziekenhuis. Er is geen rechtstreekse koppeling tussen de verschillende dossiers, maar elke arts heeft een sterke interactie met de verschillende aparte dossiers.
9.3.2.1
ORGANISATORISCHE UITDAGINGEN
Bij deze manier van werken gaat het er eigenlijk om dat de interne processen van het ziekenhuis worden opengetrokken naar de externe arts, welke op zijn minst een zicht op die processen krijgt en eventueel enige invloed erop. Als je informatie en bedrijfsprocessen wil toegankelijk maken van buiten het ziekenhuis, moet je er in eerste instantie voor zorgen dat ze binnen het ziekenhuis beschikbaar zijn. De externe arts kan niet geacht worden vertrouwd te zijn met alle details van de interne processen. Allicht is dan ook vaak een vereenvoudiging van de procedures naar buiten toe zinvol (bijvoorbeeld i.v.m. het boeken van afspraken).
99
Een bijzonder probleem in dit verband zijn data en functies die verdeeld zijn over verschillende systemen, waarbij de interne gebruikers geleerd hebben hoe met dit kluwen om te gaan. Voor een buitenstaander doet de resulterende complexiteit allicht de voordelen van de tele-toegang teniet. Opdat een dossier naar buiten toe zinvol beschikbaar zou kunnen worden gemaakt moeten de gegevens en procedures erin reeds sterk geïntegreerd zijn. Vanuit het perspectief van het dossier is een context nodig voor de gebruiker, b.v. om te bepalen welke toegangen deze gebruiker heeft. De beschikbare context is voor externe artsen beduidend kleiner dan voor de interne gebruikers. Er moeten allicht aparte regels worden geïmplementeerd, zowel voor toegang (zie sectie 9.1.5, p. 91) als voor het ondersteunen van sommige delen van de workflow.
9.3.2.2
TECHNOLOGIE VOOR INTERACTIEVE TELE-TOEGANG
Externe gebruikers hebben een andere user interface nodig dan interne gebruikers. Allicht bevat de interne toepassing functies die de externe gebruiker niet nodig heeft, vraagt ze kennis over details van de organisatie in het ziekenhuis, en is ze vatbaar voor foutief gebruik bij gebrek aan deze kennis. Probeer, in de mate dat er geen performantie-beperkingen zijn, componenten voor bedrijfslogica te groeperen in een “middle tier” en dezelfde componenten aan te roepen vanuit de interne front-end en de externe front-end toepassingen. Eén voordeel is de mogelijkheid voor sterkere beveiliging (sectie 9.1.4, p. 90). Een tweede voordeel is hergebruik van ontwikkeling en onderhoud. Indien het de bedoeling is om een grote groep van externen toegang te geven, mag je in de software voor de client weinig beperkingen opleggen naar het onderliggende bedrijfssysteem of naar de beschikbare communicatiekanalen. Voor wat betreft de communicatie, is connectie via het Internet hier een voordeel. Het doet er dan niet toe op welke fysische manier of via welke provider (ISP) de externe arts en het ziekenhuis met het Internet verbonden zijn. Er wordt vermeden dat het ziekenhuis verschillende principes voor communicatie moet ondersteunen (verschillende soorten modems…). Voor
wat
betreft
de
toepassing,
is
software
gebaseerd
op
uitwisseling
van
gestandaardiseerde HTML-pagina’s of geschreven in Java hier een voordeel, wegens de redelijke onafhankelijkheid van het bedrijfssysteem van de werkpost van de gebruiker. Scripting-talen binnen een browser hebben dan weer de neiging om afhankelijk te zijn van 100
de browser of zelfs van de versie daarvan. Bedenk wel dat het “formulier gebaseerde” principe van HTML/HTTP zich weliswaar leent tot het bouwen van intuïtieve user interfaces maar dat de graad van interactie met het systeem in dat principe eerder beperkt is. Hou bij de technische opzet rekening met de nood aan onderhoud van de systemen van de gebruikers. Zorg voor een technisch duidelijke scheiding van verantwoordelijkheden in het maken van instellingen voor connectie. Vermijd dat je toepassing op het lokale systeem moet worden geïnstalleerd, en als dat toch nodig is zorg voor automatische update-procedures over het Web. In deze setting is gecentraliseerd onderhoud van de systemen van de gebruikers zeer duur, zowel door de vereiste verplaatsingen, doordat het om zeer heterogene configuraties gaat, en doordat je geen invloed mag of wil uitoefenen op die configuraties. Juist die methoden om intern in het ziekenhuis de onderhoudskost te verlagen, vallen dus weg. Een dankbare techniek is dan ook het gebruik van een Web-browser. De externe gebruiker kan volledig onafhankelijk (laten) zorgen voor de connectie naar het Internet en deze connectie kan onafhankelijk worden geconfigureerd en getest.
9.3.3
Het delen van een centraal dossier tussen onafhankelijke zorgenverstrekkers
De werkwijzen van de vorige secties hebben nadelen indien er meer dan slechts enkele ziekenhuizen bij de zaak betrokken zijn. “Data-uitwisseling” tussen meer dan twee verschillende dossiers wordt uiteraard moeilijker en zal op meer beperkingen stuiten (zie ook sectie 2.2.1, p. 4). “Visuele toegang” tot de verschillende centrale dossiers wordt omslachtiger naarmate de informatie meer verspreid zit over verschillende dergelijke dossiers en de gebruiker in aanraking komt met de verschillende organisaties van al die dossiers. Een mogelijkheid is dat de verschillende betrokkenen afspreken dat er een apart dossier wordt aangelegd op “neutral ground” (Figuur 15). Voor die operaties waar er samenwerking wordt nagestreefd, wordt dat centrale dossier gebruikt als een middel daartoe. Voor andere operaties gebruikt ieder zijn eigen informatiesysteem. Dit vereist uiteraard informatieuitwisseling tussen de verschillende interne systemen en dat centrale dossier. Je kan dit opvatten als een zeer centrale resultaten-server (zie sectie 2.5, p. 21). Door de grotere neutraliteit ervan in vergelijking met de twee vorige oplossingen (gekoppeld aan de daarmee gekoppelde nog meer beperkte structuur van de informatie) is het denkbaar dat de informatie niet louter visueel wordt geraadpleegd, maar ook door lokale software actief wordt opgevraagd. Een variante is om niet de resultaten zelf maar verwijzingen naar de
101
resultaten in de aparte dossiers te beheren. Er bestaan initiatieven waarbij de patiënt zelf een deel van deze gegevens beheert22.
Organization 1
Organization 2
Record 1
Record 2
Other healthcare actor
Central record Local record
Organization managing central record
Figuur 15. Een onafhankelijk centraal dossier op “neutral ground” voor samenwerking tussen verschillende ziekenhuizen en externe artsen. In deze illustratie kan elk ziekenhuis informatie in het centrale dossier inbrengen. Toegang tot deze informatie is vooral op “visuele manier” (pijlen naar elke arts toe).
9.3.3.1
TECHNISCHE EN ORGANISATORISCHE UITDAGINGEN
Houd er rekening mee dat bij gebruik van een gedeeld dossier tussen verschillende onafhankelijke ziekenhuizen, alle problemen i.v.m. (1) data-uitwisseling tussen dossiers en (2) tele-toegang tot een dossier samen komen. Uiteindelijk immers wordt er in deze setting ook informatie uitgewisseld met een ander dossier (van elk ziekenhuis naar het centrale dossier). Net zoals dat bij een resultaten-server binnen een ziekenhuis geldt naar de verschillende diensten, geeft deze configuratie niet vanzelf een oplossing voor het ondersteunen van workflow tussen de verschillende aangesloten ziekenhuizen.
22
Uiteraard is het in dit geval naïef om te vertrouwen op de aanwezigheid van een sterke
structuur in deze gegevens. Het is in het ideale geval alsof een papieren dossier steeds kan worden doorge’FAX’ed. 102
Een bijkomend probleem is het beheer (en technisch onderhoud) van dat bijkomende centrale dossier.
103
104
