INTEROPERABILITEIT IN RADIOTHERAPIE. Hogeschool Inholland. Jelle Scheurleer juni 2011

INTEROPERABILITEIT IN DE RADIOTHERAPIE

Hogeschool Inholland

Jelle Scheurleer juni 2011

INTEROPERABILITEIT IN DE RADIOTHERAPIE

A dissertation submitted in partial fulfillment of the requirements for the MSc Radiation Oncology Name: Jelle Scheurleer Inholland University of Applied Sciences Graduate School, Health juni 2011

pagina 2 van 131

Summary Interoperability of healthcare information systems means that they are able to work together within and across organizational boundaries in order to advance the effective delivery of healthcare. Although problems in interoperability are not new they are likely to become more prominent as a result of increasing complexity, technological development and an expectation of multidisciplinary medical care. These challenges are highly relevant to the delivery of modern radiotherapy. In addition there is currently a trend in the Netherlands for radiotherapy departments to provide treatment at multiple locations. In 2012 the VU University medical center (VUmc) in Amsterdam will open its first satellite radiotherapy facility at the Westfries Gasthuis (WFG) in Hoorn. This necessitated an investigation to identify and anticipate possible interoperability problems and preserve or improve current standards. This is the background for the present thesis, the explicit purpose of which can be summarised as: “Increasing the interoperability of multi-site radiotherapy departments in general and that of the VUmc in particular with the aim of improving the care of patients undergoing radiotherapy”. To achieve this a survey was conducted to identify the extent of interoperability problems in radiation oncology and to characterise the situation in the VUmc radiotherapy department. This was explored using a case study format. The questionnaire survey collected data from all radiotherapy departments in the Netherlands and nine other departments in Europe, the United Kingdom, the United States and Australia. More detailed information was obtained by interviews with four Dutch radiotherapy departments. The existing situation in the VUmc radiotherapy department was evaluated using observations and interviews. These data were used to model business processes and information flow for the current and the future configurations (with the latter including the satellite in Hoorn). Any interoperability problems that were identified were subsequently analysed and recommendations and solutions were formulated. The conclusions of this work are that technical interoperability problems are rare, and that current problems usually occur on a strategic and semantic level. To counter these challenges a long-term vision is necessary. For VUmc radiotherapy no major new interoperability problems are expected when it grows into a multi-location department. It is anticipated that most problems will be covered by existing or future Integrating Healthcare Enterprise (IHE) profiles.

pagina 3 van 131

pagina 4 van 131

Inhoudsopgave Summary3 Inleiding7 1 Theoretische achtergrond

11

1.1

Interoperabiliteit

11

1.2

Standaarden

11

1.3

Integrating the Healthcare Enterprise

19

2 Modelleren

23

2.1

Object oriented technology

23

2.2

Unified Modelling Language

24

2.3

Het three-layer graph-based model

29

2.4

Samenvatting

30

3 Methode en materialen

31

3.1

Onderzoeksstrategie

31

3.2

Survey

33

3.3

Casestudy

37

4 Resultaten survey

39

4.1

Resultaten enquêtes Nederland

39

4.2

Resultaten enquête buitenland

45

4.3

Resultaten interviews

50

5 Resultaten case study

55

5.1

Model bedrijfsprocessen

55

5.2

Het Three-layer Graph-based Model

63

5.3

Interoperabiliteitsproblemen van de afdeling

72

6 Analyse en discussie

77

6.1

Interoperabiliteitsproblemen

77

6.2

Strategieën

79

6.3

Bekendheid met de IHE

80

6.4

Informatiestroom afdeling radiotherapie VUmc

81

6.5

Werken op meerdere locaties

82

6.6

Interoperabiliteitsproblemen van de afdeling

88

6.7

Beschouwing

88

Inhoudsopgave

pagina 5 van 131

7 Conclusie en aanbevelingen

91

Conclusies

91

Aanbevelingen aan de afdeling radiotherapie VUmc

91

Aanbevelingen IHE

92

Aanbeveling ten behoeve van het platform “ICT in de radiotherapie

92

Literatuurlijst

93

Bijlage 1: Nederlandse vragenlijst

97

Bijlage 2: Engelse vragenlijst

107

Bijlage 3: Interview protocol

117

Bijlage 4: Activiteitsdiagram “Voorbereiding”

123

Huidige situatie

123

Toekomstige situatie

124

Bijlage 5: Activiteitsdiagram “uitvoering”

125

Huidige situatie

125


126

Bijlage 6: Het 3LGM2-model - de domeinlaag

127

Bijlage 7: Het 3LGM2-model - de applicatielaag

129

Bijlage 8: Het 3LGM2-model - de fysieke laag

131

pagina 6 van 131

Inhoudsopgave

Inleiding Er was eens een afdeling radiotherapie waar gegevens van de patiënt te allen tijde beschikbaar waren en waar medisch beeldvormend onderzoek zonder menselijke interactie in het treatment planningssysteem geïmporteerd konden worden. Nadat een bestralingsplan vervaardigd was, werd het geaccordeerd door de klinisch fysicus en de radiotherapeut vanaf hun eigen werkplek. In een multi-disciplinair overleg werd het behandelplan van de patiënt vanuit diverse perspectieven belicht en ondersteund met de medische gegevens van de patiënt afkomstig van diverse zorginstellingen. Na zijn succesvolle behandeling ….. leefde de patiënt nog lang en gelukkig Helaas is bovenstaande een sprookje omdat de gegevensoverdracht verre van naadloos is en lijkt het meer op het rijden op een zandweg. Kleine en grote hobbels worden op die weg opgeworpen door interoperabiliteitsproblemen. De essentie van interoperabiliteit laat zich goed illustreren met het verhaal van de toren van Babel (Genesis 11 : 1 – 9). Een perspectief om naar het verhaal is te kijken, is dat van de menselijke verdeeldheid. Die toren van Babel is een symbool voor het streven van mensen om eensgezind te worden, maar tegelijk ook een symbool voor de illusie daarvan. Een algemene definitie voor “interoperabiliteit” is: ”Het vermogen van systemen en organisaties om effectief te kunnen samenwerken.”. Sander Zwienink en Pieter Wisse laten in het boek “Eerlijk zullen we alles delen – verkenningen naar interoperabiliteit” (Zwienink, 2008) de diversiteit van interoperabiliteit zien en demonstreren dat de problematiek rond interoperabiliteit door alle lagen van de samenleving loopt. Van communicatie tussen banken, communicatie tussen diplomaten, communicatie in de industrie tot,…… communicatie in de zorg. Voor de uitwisseling van medische gegevens zijn veel standaarden geformuleerd. Zij geven echter geen garantie voor het succesvol operationeel integreren van medische informatiesystemen en garanderen zodoende geen interoperabiliteit (Siegel & Channin, 2001). Kees Louwense stelt in de studie van Zwienink en Wisse (2008) dat de problemen rond interoperabiliteit in de zorg niet specifiek is voor deze tijd. Wel stelt hij dat de problemen steeds zichtbaarder worden. Dit wordt veroorzaakt door de veranderende communicatie: deze moet sneller, is omvangrijker en complexer en is met minder menselijke tussenkomst. Tot slot stelt hij dat dit wordt versterkt door de toenemende interdisciplinaire aanpak in de zorg.

Ontwikkelingen binnen het vakgebied radiotherapie Alle genoemde redenen gelden ook voor het vakgebied radiotherapie, maar zeker geldt de toename in de interdisciplinaire benadering van oncologische aandoeningen. Afdelingen radiotherapie kenmerkten zich enkele decennia geleden als medisch-technologische afdelingen die apparatuur hadden van één fabrikant, op één locatie gelokaliseerd met slechts een beperkte datastroom binnen de afdeling en tussen de afdeling en andere afdelingen binnen het ziekenhuis. Door de toename van het gebruik van beeldvormende technieken en de interdisciplinaire aanpak, is de informatiestroom sterk gestegen en beperkt deze zich zeker niet tot de grenzen van de afdeling. Het vakgebied radiotherapie kenmerkt zich door snelle technologische ontwikkelingen en een toename aan complexiteit van bestralingstechnieken. Het lijkt soms wel dat “…anyone predicting a ceiling on high-tech in radiation oncology simply lacks imagination and visions…” (Bentzen, 2004). Radiotherapie zou ‘intensity modulated, image guided, biologically optimized, apdative and evidence based’ moeten

Inleiding

pagina 7 van 131

zijn (Bentzen, 2005). De verwachting is dat hierdoor dat de interoperabiliteitsproblemen binnen het vakgebied steeds prominenter worden (Knaup & Dickhaus, 2009). Als interoperabiliteitsproblemen optreden, is menselijk ingrijpen veelal nodig om de dataoverdracht te bewerkstelligen. Wanneer dat menselijk ingrijpen een ad-hoc oplossing is dan schuilt hierin een gevaar. Meerdere studies zijn verricht naar incidenten en kwaliteitsbreuken in de radiotherapie, in het door de WHO uitgebrachte risicoprofiel wordt gesteld dat dit in ruim een derde van de gevallen te wijten is aan de overdracht van informatie (Radiotherapy risk profile, 2008). In het vakgebied radiotherapie is nog een andere ontwikkeling te zien. Ingegeven door demografische ontwikkelingen in de samenleving groeien afdelingen radiotherapie naar multi-locatie afdelingen. Enkele afdelingen hebben al meerdere locaties, maar de komende jaren zullen hier veel afdelingen in volgen. Het VU medisch centrum (VUmc) in Amsterdam zal in 2012 haar eerste satellietlocatie in het Westfries Gasthuis (WFG) in Hoorn openen. Deze satellietlocatie een initiatief van het VUmc en de stichting Esperanz, een samenwerkingsverband tussen het Westfries Gasthuis, het Zaans Medisch Centrum (Zaanstad) en het Waterland Ziekenhuis (Purmerend). In dit samenwerkingsverband werken de drie ziekenhuizen samen in het verlenen van oncologische zorg .

Doelstelling van het onderzoek De toekomstige satellietlocatie in Hoorn is voor de afdeling radiotherapie van VUmc aanleiding geweest om een onderzoek te starten naar interoperabiliteitsproblemen. Voor de afdeling is namelijk onduidelijk hoe zij kan anticiperen op deze veranderingen en de huidige interoperabiliteit kan behouden, dan wel kan verbeteren. Doelstelling van dit onderzoek is: Het versterken van de interoperabiliteit van multi-locatie afdelingen radiotherapie in het algemeen en die van het VUmc in het bijzonder. Het verbeteren van de interoperabiliteit heeft tot doel het verbeteren van de zorg van patiënten die een radiotherapeutische behandeling ondergaan. Omdat deze studie zich specifiek richt op de gezondheidszorg, is de eerder beschreven definitie van interoperabiliteit voor de context van dit onderzoek aangescherpt tot: “het vermogen van gezondheidsinformatiesystemen om samen te werken, zowel binnen als buiten de grenzen van een zorginstelling, om zodoende de effectiviteit van het zorgproces te versterken.” (HIMMS, 2005). Ten behoeve van dit onderzoek zijn de volgende deelvragen geformuleerd: 1. Welke interoperabiliteitsproblemen zijn actueel voor afdelingen radiotherapie? 2. Welke strategieën worden op afdelingen gebruikt om interoperabiliteitsproblemen te voorkomen? 3. Welke afdelingen radiotherapie in Nederland maken een vergelijkbare ontwikkeling1 door als de afdeling radiotherapie van het VUmc? Welke ervaringen bij het werken op twee locaties zijn voor het VUmc belangrijk?

1

Hierbij wordt gedoeld op het werken op zowel op een hoofdlocatie als één of meerdere satellietlocaties.

pagina 8 van 131

Inleiding

4.

Welke afdelingen radiotherapie in het buitenland lopen voorop in de aanpak van interoperabiliteitsproblemen en kunnen een voorbeeld zijn voor de afdeling radiotherapie van het VUmc? 5. Hoe verlopen de datastromen binnen de afdeling radiotherapie van het VUmc? 6. Welke datastromen lopen naar informatiesystemen elders in het ziekenhuis en welke lopen eventueel naar extramurale informatiesystemen? 7. Hoe gaat het werkproces op de afdeling radiotherapie van het VUmc eruit zien in de multilocatie situatie? 8. Welke knelpunten in interoperabiliteit zijn te verwachten ten gevolge van de groei naar een multi-locatie afdeling? 9. Hoe zouden deze knelpunten opgelost kunnen worden? 10. Wat zijn de voor- en nadelen van de verschillende oplosstrategieën?

Onderzoeksstrategie In dit onderzoek is nagegaan welke interoperabiliteitsproblemen actueel zijn voor afdelingen radiotherapie en hoe daar door de organisaties op geanticipeerd en gereageerd wordt. Het gaat er om dit onderwerp vanuit het perspectief van het vakgebied radiotherapie te leren kennen met het doel om het te beschrijven. Dominerend hierbij zijn de methodes van kwalitatief beschrijvend onderzoek. In kwalitatief onderzoek richt de vraagstelling zich op onderwerpen die te maken hebben met de wijze waarop mensen betekenis geven aan hun omgeving en hoe ze zich op basis daarvan gedragen (Jong de, Vandenbroele, Glorieux, Maesschalk, & Visser, 2008; Verhoeven, 2010; Verschuren & Doorewaard, 2000). Omdat zowel een diepgaand beeld geschetst dient te worden van de situatie van het VUmc en een breed beeld van de problematiek binnen het vakgebied als geheel is gekozen voor een mengvorm als onderzoeksdesign. Een survey is uitgevoerd om het vakgebied als geheel te onderzoeken en om na te gaan in hoeverre de situatie op de afdeling radiotherapie van het VUmc afwijkt van die van andere afdelingen radiotherapie. Om de situatie op de afdeling radiotherapie van het VUmc te onderzoeken is als onderzoeksdesign dat van de casestudy gekozen. In dit onderzoek is de problematiek binnen het vakgebied nader in kaart gebracht en is beschreven welke oplossingsstrategieën worden gehanteerd. De onderzoeksinstrumenten literatuurstudie, enquête, interview en observatie zijn hierbij gebruikt. Gestart is met een literatuurstudie naar de problematiek rond interoperabiliteit. Vervolgens is een enquête onder de experts van 21 afdelingen radiotherapie in Nederland en negen afdelingen in het buitenland afgenomen. Na analyse van de gegevens uit de enquête zijn vervolgens op vier geselecteerde afdelingen in Nederland diepte-interviews uitgevoerd. De gegevens uit de enquêtes en de interviews zijn geanalyseerd en vergeleken met de situatie in het VUmc. Om de situatie op de afdeling VUmc goed te doorgronden en antwoord te kunnen geven op de gestelde onderzoeksvragen, is het zorgproces op de afdeling nader geanalyseerd. Door observaties en gesprekken is een beeld verkregen van het werkproces. Deze zijn vertaald naar modellen van het werkproces en de informatiestromen. De interoperabiliteitsproblemen van de afdeling radiotherapie van het VUmc zijn geanalyseerd en adviezen zijn geformuleerd om de interoperabiliteitsproblemen op te lossen.

Inleiding

pagina 9 van 131

Leeswijzer In hoofdstuk 1 wordt de theoretische context van dit onderzoek verder uitgewerkt. Het fenomeen interoperabiliteit wordt verder uitgewerkt en de relatie wordt gelegd met een aantal relevante standaarden. Vervolgens wordt stil gestaan bij de IHE (Integrating the Healthcare Enterprise), één van de organisaties die verbetering van interoperabiliteit nastreeft. In het tweede hoofdstuk wordt ingegaan op de gebruikte modelleringstechnieken die in dit onderzoek ten behoeve van de casestudy gebruikt zijn. Eerst wordt ingegaan op de ideeën van object georiënteerd technologie en de modelleertaal Unified Modelling Language die daar op gebaseerd is. De voor dit onderzoek relevante diagramtechnieken van de modelleertaal zullen de revue passeren. Het hoofdstuk wordt afgesloten met een beknopte beschrijving van een drielaags model dat specifiek ontwikkeld is voor het analyseren van informatiesystemen in de gezondheidszorg. Vervolgens wordt in hoofdstuk 3 ingegaan op de methoden en materialen die in dit onderzoek gebruikt zijn. Ingegaan zal worden op de keuze van het onderzoeksdesign en de gebruikte dataverzamelings technieken van zowel de survey als de casestudy. In de hoofdstukken 4 en 5 zullen de resultaten van respectievelijk de survey en de casestudy worden gepresenteerd. Waarbij in hoofdstuk 4 eerst ingegaan worden op de resultaten van de enquêtes op de Nederlandse afdelingen en vervolgens op de resultaten van de enquêtes op buitenlandse afdelingen. Het hoofdstuk wordt afgesloten met de presentatie van de resultaten van de interviews op de vier Nederlandse afdelingen. In hoofdstuk 5 worden eerst worden de werkprocessen op de afdeling beschreven en de daarop gebaseerde diagrammen gepresenteerd. In de tweede paragraaf worden de resultaten gepresenteerd van de analyse die uit is gevoerd van de informatiesystemen. Het hoofdstuk wordt afgesloten met een analyse van de interoperabiliteitsproblemen die de afdeling ervaart. In hoofdstuk 6 worden de resultaten bediscussieerd en wordt antwoord gegeven op de verschillende deelvragen. De resultaten van de enquêtes onder de Nederlandse afdelingen worden vergeleken met die onder de buitenlandse afdelingen en met de resultaten van interviews. Tevens vindt een vergelijking plaats tussen de survey en de casusstudie om zodoende te komen tot de doelstelling van dit onderzoek. De conclusies en aanbevelingen worden tot slot gepresenteerd in hoofdstuk 7.

pagina 10 van 131

Inleiding

1 Theoretische achtergrond In dit hoofdstuk wordt de context van het onderzoeksgebied verder uitgewerkt. In eerste instantie zal het begrip interoperabiliteit verder worden verklaard. Vervolgens zal ingegaan worden op standaarden in de zorg die van belang zijn binnen de context van dit onderzoek en zal uitgelegd worden dat standaarden alleen niet voldoende zijn om interoperabiliteit te garanderen. Vervolgens zal ingegaan worden op de IHE (Integrating the Healthcare Enterprise), een non-profit organisatie die probeert de interoperabiliteit binnen de zorg te verbeteren.

1.1 Interoperabiliteit Bij het begrip interoperabiliteit gaat het om het betekenisvol uit kunnen wisselen van informatie. In het kader van dit onderzoek is gekozen voor de definitie die door de “Healthcare Information and Management Systems Society” (HIMSS) geformuleerd als: “het vermogen van gezondheidsinformatiesystemen om samen te werken, zowel binnen als buiten de grenzen van een zorginstelling, en zodoende de effectiviteit van het zorgproces te versterken” (HIMMS, 2005). Om volledige interoperabiliteit te kunnen waarborgen moet aan verschillende voorwaarden worden voldaan (Bekkum & Verhoosel, 2009; Curran, 2007): 1. 2. 3. 4.

Technische of functionele interoperabiliteit; Tactische interoperabiliteit; Semantische interoperabiliteit; Proces interoperabiliteit.

Om technische interoperabiliteit mogelijk te maken moeten systemen gegevens kunnen uitwisselen. Bij tactische interoperabiliteit gaat het om standaarden die een eenduidige berichtenstructuur kunnen waarborgen. Om semantische interoperabiliteit mogelijk te maken en de in het bericht daarin opgeslagen informatie te interpreteren en automatisch te verwerken zijn referentie informatie modellen en classificatie modellen nodig. Proces interoperabiliteit kan worden bereikt indien verschillende systemen niet alleen effectief informatie kunnen uitwisselen, maar de informatiestroom daarnaast ook in zijn geheel is afgestemd op het gewenste werkproces, dit niveau wordt ook wel aangeduidt met de term organisatorische interoperabiliteit. De oorzaak van interoperabiliteitsproblemen start bij het feit dat elk informatiesysteem de informatie op zijn eigen manier opslaat. Om informatie dan tussen systemen uit te wisselen moet de informatie vertaalt worden naar een intermediaire lingua franca (Benson, 2010).

1.2 Standaarden Twee technische standaarden die technische interoperabiliteit mogelijk moeten maken, zijn het “Open Systems Interconnection”-model en het TCP/IP-protocol (TCP=Transmission Control Protocol & IP=Internet Protocol). De beide standaarden zijn niet specifiek zijn voor de gezondheidszorg. Zij zijn van toepassing op bijna alle informatieoverdracht via computernetwerken. Theoretische achtergrond

pagina 11 van 131

1.2.1 Het Open Systems Interconnection-model Om gegevensuitwisseling tussen computersystemen mogelijk te maken is door de Internationale Organisatie voor Standaardisatie (ISO1) een communicatie model opgesteld, het OSI (Open Systems Interconnection)-model. Dit model voorzag in de behoefte die omstreeks 1975 ontstond aan een standaard voor netwerkcommunicatie. In deze periode ontstond namelijk een grote groei van netwerken binnen en tussen bedrijven. Het model dat dateert uit 1977 dient zorg te dragen voor compatibiliteit en interoperabiliteit tussen systemen ongeacht de gebuikte netwerktechnologie. De standaard gaat uit van zeven lagen waarbij alleen op de meest basale laag daadwerkelijk contact is tussen de systemen (Afbeelding 1.1). Transport van gegevens van een applicatie op systeem A naar een applicatie op systeem B verloopt als een ‘U’. Op systeem A eerst naar beneden naar laag 1, transport van A naar B, en tot slot weer omhoog naar de applicatie op systeem B. De datastroom verloopt dus in een U, maar voor een computer applicatie lijkt de communicatie horizontaal te verlopen. Deze opdeling in zeven lagen, waarbij alleen op het niveau van laag 1 werkelijk contact mogelijk is, moet de veiligheid van gegevens overdracht waarborgen (Pluis, 2005). Eventuele versleuteling van gegevens dient op de hogere lagen plaats te vinden, meestal vindt dit in de presentatie-laag plaats. Van het model zijn ook communicatie protocollen afgeleid, deze zijn echter nooit succesvol geweest. Door het ontbreken van succesvolle OSI-protocollen heeft het OSI-model technisch gezien zijn nut verloren. Het model wordt momenteel echter toch gebruikt als referentiemodel.

1.2.2 Het Internet Protocol en het Transmission Control Protocol. Een veel bekender communicatie protocol is het TCP/IP-protocol, omdat het de basis van de communicatie over het internet is. Dit protocol is feitelijk opgebouwd uit twee standaarden: het Internet Protocol (IP) en het Transmission Control Protocol (TCP). Van dit TCP/IP-protocol is een TCP/IP-model afgeleid, dat in tegenstelling tot het ISO-OSI model, slechts vier lagen kent (Afbeelding 1.1.). De applicatie-, de presentatie- en de sessielaag uit het OSI-model zijn in het TCP/IP-model samengevoegd tot één applicatielaag. De data-link-laag en de fysieke laag zijn samengevoegd tot de netwerklaag. Het IP-protocol is een zogenaamd ‘best-effort’ protocol. Als het protocol een hoeveelheid gegevens moet verzenden, dan doet het daartoe één poging en het protocol neemt vervolgens aan dat de gegevens zijn aangekomen. Het TCP-protocol is een zogenaamd ‘reliable’ protocol. Het garandeert dat alle door het protocol verstuurde pakketten (in de goede volgorde) bij de ontvanger afgeleverd worden. Als door de verzender geen ontvangstbevestiging wordt ontvangen, wordt het pakket nogmaals verstuurd. Een TCP-verbinding is, in tegenstelling tot de IP-verbinding, virtueel. Voor de virtuele verbinding is het noodzakelijk dat eerst een IP-verbinding wordt opgebouwd. De virtuele verbinding blijft in stand totdat deze expliciet wordt beëindigd (Pluis, 2005).

1

De Internationale Organisatie voor Standaardisatie heeft voor de afkorting ISO gekozen om in elke taal een herkenbare afkorting te krijgen, zodoende is de volgorde van de letters niet conform de naam van de organisatie.

pagina 12 van 131

Theoretische achtergrond

Afbeelding 1.1: In de figuur links is te zien hoe volgens het ISO-OSI model vanuit de zevende laag, de applicatielaag, omlaag loopt naar laag 1, de fysieke laag. Alleen op laag 1 is daadwerkelijk contact tussen de twee computer systemen. In de rechter figuur is de relatie tussen het ISO-OSI model en het TCP-IP model. Het TCP-IP model maakt geen onderscheid tussen de applicatie-, presentatie- en sessie-laag.

1.2.3 Health Level 7 De in de vorige paragraaf beschreven standaarden zijn onafhankelijk van het vakgebied. Naast deze algemene standaarden zijn vele gezondheidszorg specifieke standaarden ontwikkeld. Zo is door schaalvergroting van de zorg in de afgelopen decennia grote behoefte ontstaan aan een standaardisatie van berichten binnen en tussen de ziekenhuizen. De standaard Health Level 7 is één van de standaarden die in deze behoefte voorziet. De naam en het nummer in de naam verwijzen naar de applicatie laag, laag 7 in het OSI-model. In deze laag gaat het om de communicatie met de gebruiker. Zoals in de vorige paragraaf beschreven, functioneren de lagen in het OSI-model onafhankelijk van elkaar. Zodoende hoeft de HL7-standaard geen rekening te houden met de onderliggende zes lagen: waarin o.a. de connectiviteit, het transport of versleuteling van de gegevens, gedefinieerd zijn (Englebardt & Nelson, 2002). Op het moment zijn twee versies van de standaard in gebruik. Versie 2.x van de standaard is een set berichtformaten voor gegevensuitwisseling binnen ziekenhuizen. Versie 3 van de standaard richt zich meer op de berichtgeving tussen zorginstellingen en zou zodoende als basis moeten dienen voor het gebruik in een EHR (Electronic Health Record). Deze versie is een uitbreiding op versie 2 en kan opgevat worden als een verzameling van substandaarden. Componenten van de standaard zijn een gegevens referentie informatiemodel (RIM) en een set met algemene en domein specifieke berichtenformaten (Stap & Verhoosel, 2007) (Afbeelding 1.2).


pagina 13 van 131

Structuur HL v2.x

Structuur HL v3

Afbeelding 1.2: De relatie tussen HL7 versie 2 (V2.x) en 3 (V3). Te zien is dat versie 3 (rechts) een uitbreiding is van versie 2. Aan versie 2 is een referentiemodel toegevoegd en de domein specifieke specificaties zijn verder uitgewerkt. Ook heeft een verdere integratie van andere standaarden plaats gevonden (Paterson, 2003).

In Nederland wordt de HL7 versie 2 standaard toegepast in vrijwel alle ziekenhuizen voor de berichtgeving tussen het ziekenhuis informatiesysteem en domein specifieke applicaties. De HL7 versie 3 wordt in Nederland als standaard toegepast binnen de nationale infrastructuur voor het uitwisselen van patiëntgegevens2 tussen zorginstellingen. Het verschil tussen versie 2 en versie 3 en het belang van het informatiemodel wordt door Michael Henderson treffend uitgelegd. Hij stelt dat het ontbreken van het informatiemodel in versie 2 vragen kan oproepen als: “Als ik de uitslag van een onderzoek aan een arts kan faxen, waarom kan ik dat dan niet naar een patiënt faxen?”. In de reële wereld is dat inderdaad vreemd en zou dat geen probleem mogen zijn. Echter door het ontbreken van een informatiemodel in versie 2 is het niet duidelijk dat zowel de patiënt als de arts personen zijn met een aantal overeenkomstige eigenschappen en dat zowel die arts als de patiënt een faxnummer kunnen hebben3. In versie 3 is door het informatiemodel een grotere consistentie van de berichten gewaarborgd (Henderson, Behlen, Parisot, Siegel, & Channin, 2001). Daarnaast is versie 2 bericht platte tekst, terwijl een versie 3 bericht gebaseerd is op de XML-standaard (eXtensible Markup Language) (Henderson, 2007). Bij XML wordt het bericht gestructureerd met ‘tags’, een soort van etiket. De interpretatie van de tags wordt bij XML aan de applicatie overgelaten, de interpretatie van het bericht is daardoor minder intuïtief als bij versie 2 en dit is vermoedelijk één van de redenen waarom de introductie van versie 3 ook langzaam gaat in vergelijking met versie 2.

2

Deze infrastructuur is door het NICTIZ (Nationaal ICT Instituut in de Zorg) vormgegeven en wordt AORTA genoemd. AORTA bestaat uit vier componenten: goed beheerd zorgsysteem, zorgservice provider, unieke zorgverlener identificatie en het landelijk schakelpunt.

3

Verderop in dit hoofdstuk zal ingegaan worden op object georiënteerd denken en wordt duidelijk dat zowel de “arts” als “patiënt” classes zijn van de superclass “persoon”.

pagina 14 van 131


Tot slot kent HL7 een derde standaard, HL7 CDA (Clinical Documentation Architecture), die de architectuur voor het uitwisselen van documenten standaardiseert. Het kenmerkende verschil tussen een bericht en een document is dat een bericht tot doel heeft om een aantal velden in een database aan te passen, terwijl het bij een document gaat om de lange termijn opslag van samenhangende informatie (Henderson, et al., 2001). 1.2.4 De Europese standaard EN 13606 De HL7v3-standaard is een Amerikaanse standaard. Door een samenwerking tussen CEN (Comité Européen de Normalisation) en ISO is de Europese standaard EN 13606 ontwikkeld. De standaard richt zich op specificatie van een EHR (Electronic Health Record) ten behoeve van het uitwisselen van patiënt georiënteerde medische informatie. Deze standaard kent grote overlap in functionaliteit met de Amerikaanse HL7v3-standaard. In 2006 zijn afspraken gemaakt om harmonisatie tussen HL7v3 en EN 13606 te bereiken (Stap & Verhoosel, 2007).

1.2.5 Digital Imaging and Communications in Medicine De HL7 standaarden zijn onafhankelijk van het vakgebied, voor het vakgebied medische beeldvorming is de laatste twee decennia de standaard DICOM (Digital Imaging and Communications in Medicine) niet meer weg te denken. Begin jaren 80 van de vorige eeuw werd door het Amerikaanse college van radiologen (ACR) en de NEMA (National Electrical Manufacturers Association de behoefte gesignaleerd om tot een standaard voor de opslag en transport van Medische beelden te komen. De DICOM 3.04 (Digital Imaging and Communications in Medicine) standaard is de derde versie van deze standaard en verscheen in 1993 (Oosterwijk, 2005; Wiggins, Davidson, Harnsberger, Lauman, & Goede, 2001). Het succes van de standaard is dat het zowel een netwerkcommunicatie protocol, gebaseerd op het eerder beschreven TCP/IP-protocol, als een bestandsformaat voor medische beelden voorschrijft. Het bestandsformaat van een DICOM-image file bestaat uit zowel een header als de afbeelding. De header bevat informatie over de patiënt, de beeldmodaliteit (CT, MRI etc.) en over het beeldformaat (Clunie, 2009). Net zoals HL7 versie 3, is DICOM gebaseerd op de filosofie van object georiënteerd technologie (OOT) (zie ook § 2.1). Volgens deze denkwijze is een object ‘iets’ uit de werkelijke wereld. DICOM modelleert de werkelijkheid met objecten als medische beelden (zoals CT, MRI of PET beelden), werklijsten en printwachtrijen. Naast objecten kent DICOM ook services en dit zijn kortweg opdrachten, zoals: ‘store’, ‘get’, ‘find’ en ‘move’. De combinatie van een service en een object, wordt een service-object-paar (SOP) genoemd. Een belangrijk onderdeel van de DICOM-standaard is het DICOM informatiemodel. Dit model definieert de relatie tussen de DICOM-objecten (Afbeelding 1.3). Uit het informatiemodel is af te lezen dat: een imaging modaliteit van één patiënt één of meerdere studies vervaardigt, waarbij een studie bestaat uit één of meerdere series en een serie bevat geen of meer dan één afbeeldingen.

4

Versie 3.0 refereert aan de twee ACR-NEMA standaarden die aan DICOM vooraf gingen. Dicom 1.0 en 2.0 hebben nooit bestaan. En ondanks de vele herzieningen van de standaar blijft het vesrienummer ongewijzigd in 3.0.


pagina 15 van 131

Afbeelding 1.3 Het DICOM informatiemodel. Het laat zien hoe de verschillende objecten zich tot elkaar verhouden. De rechthoeken geven de verschil-lende objecten aan, een ruit geeft de relatie aan. De bijschriften bij de pijlen geven de aantallen aan (NEMA, 2008)

Hoewel de standaard primair ontwikkeld is vanuit het vakgebied radiologie, is de standaard in de loop van de jaren verder uitgebreid naar andere vakgebieden, zoals: radiotherapie, pathologie, endoscopie, microscopie en cardiologie. De DICOM-standaard is zodoende niet langer een radiologie specifieke standaard die het versturen van beelden tot doel heeft. In 1997 werden de eerste radiotherapie objecten aan de DICOM-standaard toegevoegd.De huidige radiotherapie specifieke objecten zijn (Afbeelding 1.4) (Law & Liu, 2009; NEMA, 2008; Seelentag, 2003): • RT Plan; Omvat de geometrische en dosimetrische gegevens van externe radiotherapie of een brachytherapie behandeling. • RT Image; Dit kunnen beelden zijn van een conventionele lokalisator, portal images en digital reconstructed radiographs (DRR’s). • RT Dose; Bevat dosisgegevens gegenereerd door een treatment planningssysteem. Dit kan zijn in de vorm van isodoselijnen, drie dimensionale dosisverdelingen, dosis volume histogrammen (DVH’s) en dosiswaarden van een punt. pagina 16 van 131


• •

RT Structure Set; Informatie over anatomische structuren, markeringen en het isocentrum RT Treatment Record. Dit bestand kan bestaan uit behandel overzichten van externe bundels en brachytherapie behandelingen.

Een bron van interoperabiliteitsproblemen rond de DICOM-RT standaard wordt veroorzaakt door het gebruik van optionele attributen bij de DICOM wijzigingsvoorstellen. Deze wijzigingsvoorstellen worden gebruikt om fouten of onduidelijkheden in de standaard te corrigeren of de functionaliteit van de RT-objecten te verbeteren. In de meeste gevallen wordt dan gebruik gemaakt van optionele attributen om de conformiteit van bestaande applicaties te waarborgen. Dit kan tot gevolg hebben dat meerdere attributen in een DICOM-RT dezelfde of nauw verwante informatie kunnen weergeven. Zo kan de naamgeving van een ingetekende structuur vastgelegd worden met het attribuut “ROI Naam” of met het attribuut “ROI Observatie Label”. De DICOM-standaard beoogt een standaard te zijn die zowel technische interoperabiliteit als de tactische interoperabiliteit nastreeft. De HL7-standaard richt zicht zich op de tactische interoperabiliteit. Beide standaarden beogen een integratie met semantische standaarden om ook semantische interoperabiliteit te waarborgen.

Afbeelding 1.4 Een vereenvoudigd overzicht van de radiotherapie objecten te zien met hun onderlinge relatie. Te zien is dat het bestralingsplan een belangrijk DICOM-RT object is het is gerelateerd aan alle andere objecten (NEMA, 2008). Theoretische achtergrond

pagina 17 van 131

1.2.6 International Statistical Classification Voor het medische domein zijn verschillende semantische standaarden ontwikkeld, reden hiervoor is dat taal niet exact genoeg is. Met veel verschillende termen wordt hetzelfde bedoeld. Dit verschijnsel is niet specifiek voor deze tijd. In 1977 publiceerde de Wereldgezondheidsorganisatie (WHO) de negende versie van het classificatiestelsel ICD (International Statistical Classification of Diseases and Related Health Problems) (Englebardt & Nelson, 2002). ICD-9 is inmiddels opgevolgd door ICD-10. Omdat versie 10 echter sterk verschilt van versie 9, worden beiden naast elkaar gebruikt. Een Nederlandse vertaling van ICD-9 is de basis van de Diagnose/Behandeling/Combinatie-codering (DBC-codering), zoals die in Nederlandse ziekenhuizen gebruikt wordt.

1.2.7 Systematized Nomenclature of Medicine – Clinical Terms Een classificatie systeem dat op het moment erg in de belangstelling staat, is SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms). Dit is een medisch terminologiestelsel en bestaat uit een verzameling standaard termen met hun synoniemen, die in de directe patiëntenzorg gebruikt wordt voor de vastlegging van klachten, symptomen, omstandigheden, ziekteprocessen, interventies, diagnosen, resultaten en de besluitvorming. In dit systeem wordt onderscheid gemaakt tussen “termen” en “concepten”, waarbij de “termen” aangeven wat er gezegd wordt en “concepten” wat bedoeld wordt (Benson, 2010). Ondanks al deze standaarden is van volledige interoperabiliteit binnen de zorg nog geen sprake (Bosch, Curran, & Swedloff, 2010; Ciottl, 2010; Siegel & Channin, 2001). De technische standaarden zorgen wel voor connectiviteit maar garanderen geen tactische en semantische interoperabiliteit. HL7 versie 2 richt zich op de tactische interoperabiliteit en de uitbreidingen in versie 3 met een informatiemodel en semantische standaarden zou in principe semantische interoperabiliteit mogelijk moeten maken (Banfai, Ulrich, Torok, Natarajan, & Ireland, 2009). De DICOM standaard richt zich over de hele linie van technische tot semantische interoperabiliteit, maar ook hier is geen sprake van volledige interoperabiliteit omdat geen consensus bestaat over hoe de standaard moet worden ingevuld (Bosch, et al., 2010; Ciottl, 2010; Siegel & Channin, 2001). Om proces interoperabiliteit te verkrijgen dient meer te worden nagstreeft als consensus over het gebruik van standaarden. Werkprocessen en informatiesystemen dienen dan volledig op elkaar te zijn afgestemd (Benson, 2010). Samenvattend kan gesteld worden dat standaarden veel mogelijk zouden moeten maken, maar dat onvoldoende consensus bestaat wanneer en hoe de standaarden zouden moeten worden ingezet. Een organisatie die daar verandering in wil brengen is de IHE (Integrating the Healthcare Enterprise). De activiteiten van IHE richten zich op beide domeinen en op termijn zou voor een groot deel van het zorgproces de interoperabiliteit gegarandeerd moeten zijn.

pagina 18 van 131


1.3 Integrating the Healthcare Enterprise Om interoperabiliteit in de zorg te verbeteren zijn internationaal twee non-profit organisaties actief, de IHE (Integrating the Healthcare Enterprise) en Continua Health Alliance (Benson, 2010). Terwijl Continua zich met name richt op het verbeteren van interoperabiliteit in de thuiszorg, is het doel van de IHE gericht op de interoperabiliteit binnen en tussen zorginstellingen. De IHE is een samenwerkingsverband tussen leveranciers en de professionals in de zorgsector en is opgericht in 1998 door de Healthcare Information and Management Systems Society (HIMMS) en de Radiological Society of North America (RSNA). De IHE ontwikkelt zelf geen standaarden, maar promoot het gebruik van gevestigde standaarden om zo de interoperabiliteit te verbeteren (Siegel & Channin, 2001). Dit wordt nagestreefd door een samenwerkingsverband te creëren waarbij zowel gebruikers als producent kunnen werken aan het oplossen van interoperabiliteitsproblemen. Om dit wederzijdse belang van gebruiker en producent te waarborgen, kent de organisatie ook twee voorzitters, één namens de fabrikanten en één namens de gebruikers.

1.3.1 Werkwijze De IHE definieert per domein zogenaamde technische raamwerken, waarin in detail de gebruikte terminologie en een informatiemodel voor het betreffende vakgebied beschreven zijn. Zo een raamwerk is het perspectief van waaruit het betreffende vakgebied wordt bekeken. Een dergelijk raamwerk is dus geen statisch gegeven. Gaandeweg zullen namelijk meer processen van het betreffende vakgebied worden beschreven en zal het raamwerk groeien (Channin, 2001). Door het leveren van deze eenduidigheid, vormt dit de basis om doelgericht verder te kunnen werken aan het oplossen van interoperabiliteitsproblemen binnen het betreffende vakgebied (Channin, 2001; Siegel & Channin, 2001). In het raamwerk, dat is opgebouwd uit integratieprofielen, worden de processen en de taken van het betreffende vakgebied beschreven. Daarnaast is in een informatiemodel uitgewerkt welke berichten tussen verschillende actoren, of te wel systemen, verstuurd moet worden om het betreffende proces succesvol te kunnen voltooien (Channin, 2001). Voor het ontwikkelen van integratieprofielen werkt de IHE volgens een cyclisch proces (Afbeelding 1.5). De eerste stap die gezet wordt in dit proces is het definiëren van een interoperabiliteitsproblemen op basis van een zogenaamde ‘use case’ beschrijving. In een use case wordt kort het probleem en de gewenste functionaliteit beschreven. Elke zorgprofessional kan use cases indienen. Vervolgens worden door een werkgroep prioriteiten gesteld en wordt bepaald welke use cases in dat jaar worden aangepakt. In de tweede fase wordt per use case door experts een integratieprofiel beschreven. In het profiel wordt beschreven met welke standaarden het probleem kan worden aangepakt. Een integratieprofiel is dus een oplossing voor een interoperabiliteitsprobleem. Nadat het profiel is beschreven, krijgen fabrikanten de gelegenheid om de profielen in hun producten te implementeren. In een jaarlijkse testsessie, waarop leveranciers van informatiesystemen kunnen inschrijven, wordt het proces vervolgd. In deze testsessie waarin de verschillende systemen met elkaar worden verbonden, wordt een zorginstelling gesimuleerd en wordt de onderlinge interoperabiliteit van de systemen getest. Deze testsessies worden georganiseerd in Noord Amerika, Europa en Azië. Theoretische achtergrond

pagina 19 van 131

De laatste stap in de werkcyclus van de IHE is het publiceren van het integratieprofiel. Leveranciers publiceren IHE integratieverklaringen om aan te geven welke IHE-integratieprofielen door hun producten worden ondersteund. Gebruikers kunnen de IHE-integratieprofielen bij offerteaanvragen als referentie gebruiken. Op deze wijze wordt de gewenste functionaliteit en interoperabiliteit eenduidig vastgelegd (Channin, 2001; Channin, Parisot, Wanchoo, Leontiev, & Siegel, 2001; Siegel & Channin, 2001).

Afbeelding 1.5 De werkwijze van de IHE voor het vaststellen van integratieprofielen. Stap 1 is het identificeren van een interoperabiliteitsprobleem en het omschrijven van een “use case”. In de tweede fase wordt een concept integratieprofiel vastgesteld. In een grootschalige test wordt getest in hoeverre fabrikanten het profiel hebben geïmplementeerd. In de laatste fase wordt het definitieve profiel gepubliceerd.

1.3.2 Ontwikkelde integratie profielen Na de oprichting heeft de IHE zich de eerste jaren geconcentreerd op het vakgebied van de radiodiagnostiek, nu bestrijkt de IHE inmiddels negen domeinen, waaronder: pathologische anatomie, cardiologie, oogheelkunde, klinische laboratoria, radiotherapie en de medische beeldvorming (echografie, nucleaire geneeskunde en radiodiagnostiek). Voor de medische beeldvorming zijn inmiddels 24 integratieprofielen beschreven. Voor de radiotherapie zijn naast het technische raamwerk drie integratieprofielen beschreven. De integratieprofielen voor de radiotherapie zijn gericht op fundamentele delen van de werkprocessen binnen de radiotherapie en betreffen (Abdel-Wahab, et al., 2010; Bosch, et al., 2010): • Normal Treatment Planning-Simple Dit is het eerste profiel voor de radiotherapie. De nadruk ligt bij dit profiel op het gebruik van RT informatie objecten ten behoeve van treatment planning. Het profiel beschrijft de normale workflow van de klinische data van CT-scanner tot aan de beoordeling van 3D-conformatie plannen (Technical Framework, 2008). • Image Registration Integration profile Dit profiel heeft betrekking op medische beeldvorming met meerdere modaliteiten (zonder deformatie) ten behoeve van treatment planning (Image Registration (REG) Integration Profile, 2007).

pagina 20 van 131


•

Managed Delivery Workflow Dit profiel integreert dagelijkse IGRT met de radiotherapeutische behandeling in één workflow (Technical Framework, 2008).

De lijst met nog af te ronden interoperabiliteitsproblemen voor het vakgebied radiotherapie omvat nog een kleine twintigtal interoperabiliteitsproblemen en richt zich op meer informatiestromen bij meer complexere behandeltrajecten en op inbedding van de radiotherapeutische behandeling in het gehele zorgproces (Curran, 2007). Enkele voorbeelden zijn: • Het combineren van twee of meer plannen tot een nieuw treatment plan; • Geavanceerde interoperabiliteit van treatment planningssystemen; • Samenstellen van sjablonen van anatomische structuren; • Export van gegevens voor klinische trials; • Het voorkomen van interoperabiliteitsproblemen bij combinatiebehandeling Toekomstige werkzaamheden van de IHE binnen de radiotherapie omvat de toepassing van DICOMsupplement 96 (Unified Procedure Step) naar andere werkstromen binnen de afdeling radiotherapie (bv. Treatment Planning, QA, vervaardiging van hulpmiddelen) en het opnemen van ionen- en brachytherapie (Bosch, et al., 2010). Bij de jaarlijkse testsessies worden systemen vanuit verschillende vakgebieden getest, het vakgebied radiotherapie (IHE-RO) heeft haar eigen testsessies, de reden voor deze aparte testsessies voor IHE-RO is onduidelijk. Voor het vakgebied radiotherapie zijn door het Nederlandse bedrijf Humiq in opdracht van de ASTRO software testtools ontwikkeld voor deze testsessies. Deze testtools zijn gebaseerd op het open-source platform DTVk (Dicom Validation Toolkit), een samenwerkingsverband tussen Agfa, Humiq en Philips. De testtools simuleren de verschillende actoren in de integratieprofielen en kunnen op vier mo-menten worden ingezet.: 1. Voor de connectathon; 2. Tijdens de connectathon; 3. Tijdens de installatie van de systemen bij de gebruiker; 4. Bij de implementatie van de integratieprofielen. In voorbereiding op de connectathon worden de tools beschikbaar gesteld aan de fabrikanten, met behulp van de tools kunnen zij aantonen dat zij voldoen aan de gestelde criteria voor deelname aan de connectathon. Tijdens de testsessie worden de tools gebruikt door de IHE om na te gaan of de systemen aan de integratieprofielen voldoen. Tijdens de installatie van informatiesystemen bij de gebruiker kunnen de tools door de leverancier gebruikt worden om in een vroeg stadium integratieproblemen te ontdekken. Na verloop van tijd worden de ontwikkelde testtools beschikbaar gesteld aan derden zodat zij gebruikt kunnen worden als hulpmiddel bij de implementatie van integratieprofielen op afdelingen radiotherapie (Bosch, et al., 2010; DVTk,” 2010; IHE Radiation Oncology test tool,” 2010).


pagina 21 van 131

pagina 22 van 131


2 Modelleren Zoals in het vorige hoofdstuk uiteen is gezet, hebben enkele deelvragen betrekking op de werkprocessen en de informatiestromen op de afdeling radiotherapie van het VUmc. Om deze in kaart te brengen worden modelleringstechnieken gebruikt. In dit hoofdstuk zal ingegaan worden op de modelleringstechnieken die in dit onderzoek zijn gebruikt. Eerst wordt de modelleertaal Unified Modelling Language beschreven en vervolgens zal ingegaan worden op het 3LGM2-model. Een model dat afgeleid is van UML en dat specifiek voor de gezondheidszorg is ontwikkeld.

2.1 Object oriented technology Een model is een afspiegeling van de werkelijkheid. Meestal is het model een combinatie van tekst en afbeeldingen. Voor het modelleren van systemen of processen zijn meerdere technieken beschikbaar. Eén techniek die de laatste decennia erg in de belangstelling staat is Object Oriented Technology (OOT). De techniek is afkomstig uit de software-ontwikkeling en dateert al uit ca. 1960, maar is pas in de laatste twee decennia tot bloei gekomen (Hoogendoorn, 2010; Object gericht denken, 2010). OOT heeft bewezen een aantal voordelen te hebben boven klassieke procesgerichte modelleringstechnieken. Cruciaal hierin is dat de techniek uitstekend werkt in snel veranderende situaties. Deze techniek is gebaseerd op het paradigma dat de werkelijkheid (het systeem of het proces) bestaat uit objecten en dat die objecten berichten (een bericht in OOT terminologie is ‘message’) aan elkaar versturen en zo een bepaalde functie vervullen. Naast objecten onderscheidt OOT ‘attributes’ en ‘methods’, dit zijn respectievelijk de kenmerken en de functies of gedragingen van een object (Object gericht denken, 2010). Een belangrijk aspect hierbij is dat elk object slechts zijn eigen functionaliteit definieert en verder alles aan de andere objecten overlaat (Hoogendoorn, 2010; Warmer & Kleppe, 2008). De positieve consequentie van deze benadering is, dat bij veranderingen van de werkelijkheid alleen de bij de verandering betrokken objecten aangepast hoeven te worden (Hoogendoorn, 2010). De techniek is nu een basistechnologie in de informatica. Om dit te verduidelijken een voorbeeld van een patiënt uit de reële wereld. Deze wordt in OOT gemodelleerd als het object “Patiënt” en enkele attributen van dit object zijn: naam, geboortedatum, burgerservice nummer en adres. Als door een hulpverlener de vraag wordt gesteld: “Hoe oud bent u/je?”, dan wordt dit gemodelleerd als de message “geefLeeftijd” (Afbeelding 2.1). Vervolgens wordt de operatie “geefLeeftijd” door de patiënt uitgevoerd. Hoe dit intern wordt aangepakt is afgeschermd van de omgeving. Zo zal een kind van drie dat op basis van herinnering doen, een volwassene zal waarschijnlijk

Afbeelding 2.1: Voorbeeld van een object, de patiënt met de naam “Scheurleer, J.S.”. Links is meer generiek de class “Patiënt” gemodelleerd. Een class wordt weergegeven met een rechthoek onderverdeeld in drie delen. In het bovenste deel wordt de classnaam weergegeven, daaronder de attributen en in het onderste deel de attributen. Modelleren

pagina 23 van 131

gaan zitten rekenen met zijn geboortedatum en de huidige datum. Voor een niet al te complex deel van de werkelijkheid is het mogelijk om basis van individuele objecten de werkelijkheid te modelleren. Met toenemende complexiteit zal dit al snel een onoverzichtelijk model opleveren. Hiervoor is binnen OOT het begrip class geïntroduceerd, waarbij een class de beschrijving is van gelijksoortige objecten. Indien een object tot een class behoort, wordt gezegd dat het object een instantie is van die class.

2.2 Unified Modelling Language De eerste object georiënteerde programmeertaal dateert uit 1967, maar pas een decennium later kwam de belangstelling voor object georiënteerd denken goed op gang. Al snel kwam het besef dat de op dat moment gebruikelijke modelleringstechnieken niet toereikend waren voor dit denkkader. Zo ontstond aan het eind van de jaren ’80 een heel scala aan nieuwe modelleringstechnieken. Hieruit is uiteindelijk de modelleertaal UML (Unified Modelling Language) ontstaan. UML voegt verschillende hulpmiddelen, technieken en processen samen in één taal en het is inmiddels een algemeen geaccepteerde standaard. Hoewel de modelleertaal oorspronkelijk bedoeld is als hulpmiddel bij het ontwikkelen van software systemen, kan deze ook uitstekend gebruikt worden om bedrijfsprocessen te modelleren (Business Process Modelling) (Benson, 2010; Eriksson & Penker, 2000). Het visueel modelleren van bedrijfsprocessen maakt een goede communicatie over de processen mogelijk en geeft meer inzicht dan geschreven tekst (Benson, 2007). Daarnaast is de stap om applicaties die het bedrijfsproces moeten ondersteunen eenvoudig (Eriksson & Penker, 2000). Tot slot noemt Eriksson als voordeel het modelleren van bedrijfsprocessen bij innovaties in het bedrijfsproces. Het model kan gebruikt worden om te onderzoeken in hoeverre de bestaande organisatie, middelen en informatiesystemen gebruikt kunnen worden in de nieuwe situatie. Een belangrijke stap in het modelleren van classes is het beschrijven van de ‘responsibilities’ van die class. Als deze stap niet goed gedaan wordt, veroorzaakt dit afhankelijke relaties tussen objecten. Het lijkt dan ontwikkeld vanuit het OOT-paradigma, echter het voordeel van herbruikbaarheid is verloren gegaan. Bij aanpassingen van het systeem moeten dan meerdere objecten worden aangepast dan strikt noodzakelijk zou zijn (Object gericht denken, 2010). Ook bij het modelleren van bedrijfsprocessen is het echter verstandig afhankelijke relaties te ver mijden. Het goed beschrijven van verantwoordelijkheden verhoogt de transparantie en effectiviteit van een organisatie (Eriksson & Penker, 2000). De UML 2.0 kent dertien modelleertechnieken onderverdeeld in twee categorieën (Tabel 2.1): structuur en gedrag diagrammen. In structuur diagrammen wordt de statische structuur gemodelleerd, in de gedragsdiagrammen wordt het dynamische gedrag beschreven. Zo wordt bij een activiteitsdiagram de samenhang van de activiteiten en bij een sequentie diagram de volgorde van de berichten in de tijd getoond. Door verschillende experts wordt gewezen op het feit dat UML alleen een modelleertaal is en geen methode, de modelleertaal schrijft zodoende niet voor in welke situatie welk diagram ingezet moet worden en welke systematiek gehanteerd moet worden bij het modelleren (Benson, 2010; Object gericht denken, 2010; Unified Modeling Language, 2010). pagina 24 van 131

Modelleren

In de context van dit onderzoek zijn de volgende diagramtechnieken van belang en zullen worden beschreven: • Class diagram; • Deployment diagram; • Activiteitsdiagrammen; • Use case diagram; • Sequentiediagrammen. Tabel 1.1 Overzicht van de diagram technieken in UML. Uitleg toevoegen over verschil structuur en gedrag diagrammen. Structuur Diagrammen

Gedrag Diagrammen

1. Class diagram

7. Use case diagram

2. Object diagram

8. State machine diagram

3. Samengesteld structuur diagram

9. Activiteiten diagram

4. Package diagram

INTERACTIE DIAGRAMMEN

5. Component diagram

10. Interactie overzichtsdiagram

6. Deployment diagram

11. Sequentie diagram 12. Communicatie diagram 13. Tijdsdiagram

2.2.1 Class diagram Zoals eerder beschreven is een object een representatie van een al dan niet tastbaar begrip uit de werkelijkheid. De class is de beschrijving van de attributes (=specificaties) van gelijksoortige objecten. In het class diagram wordt de samenhang tussen de verschillende classes getoond (Afbeelding 2.2). Het in hoofdstuk 1 beschreven informatiemodellen van HL7, van DICOM en van DICOM-RT zijn voorbeelden van class-diagrammen.

Afbeelding 2.2: Voorbeeld van een eenvoudig class diagram. Een class wordt weergegeven met een rechthoek onderverdeeld in drie delen. In het bovenste deel wordt de class naam weergegeven, daaronder de attributes en in het onderste deel de methods. De attributes en de me-thods hoeven niet gespecificeerd te worden. De relatie tussen de classes, ook wel associaties geheten worden door middel van lijnen tussen de classes gespecificeerd.

Modelleren

pagina 25 van 131

2.2.2 Deployment diagram Eén van de implementatiediagrammen is het deployment diagram, dit diagram geeft weer hoe een informatiesysteem geïmplementeerd is op de fysieke computerarchitectuur. Dit type diagram kan daarom uitstekend gebruikt worden om de structuur van een (bestaand) informatiesysteem visueel te maken. In dit type diagram wordt gebruik gemaakt van nodes en artefacten. Een node is een computer resource waarop artefacten, dit zijn fysieke stukken informatie, kunnen worden geplaatst om bewerkingen uit te voeren. Voorbeelden van artefacten zijn databestanden zoals documenten, DICOMbestanden etc. (Unified Modeling Language, 2010). Communicatie tussen nodes kan worden weergegeven met een associatie tussen de nodes te tekenen. Hierbij kan het soort communicatie (bv. TCP-IP) als label van de associatie aangegeven worden (Afbeelding 2.3). Deze diagramtechniek kan zodoende gebruikt worden om de fysieke componenten en de daarop draaiende applicaties te modelleren. Uiteindelijk is niet voor deze diagram techniek gekozen omdat gemodelleerd is aan de hand van de applicatie laag en de fysieke laag uit het 3LGM2-model (paragraaf 2.2.5).

2.2.3 Activiteitsdiagram

Afbeelding 2.3: Voorbeeld van een eenvoudig deployment diagram, bestaande uit twee nodes en één applicatie.

Het activiteitsdiagram is één van de diagramtechnieken waarbij de dynamiek van het gedrag van één of meerdere objecten kan worden beschreven. Hierin wordt beschreven hoe de objecten reageren op een gebeurtenis in de reële wereld. In een activiteitsdiagram (Afbeelding 2.4) wordt de volgorde van de activiteiten die op een gebeurtenis volgen grafisch weer gegeven. Daarnaast biedt het diagram de mogelijkheid om de activiteiten te groeperen naar de objecten (personen, afdelingen of actoren) die activiteit uitvoeren door gebruik te maken van zogenaamde ‘swimlanes’. In een activititeitsdiagram wordt de activiteit gestart met een zwart rondje (activity initial), het eind van de activiteit met een zwart rondje met een cirkel eromheen (activity final). Elke actie in het diagram wordt omschreven met een afgeronde rechthoek met daarin de omschrijving van de actie. De volgorde van de acties wordt weergegeven met een pijl (control flow) tussen de activiteiten. Voor voorwaardelijke activiteiten is het symbool van de ‘desicion node’ gereserveerd. Hiervoor wordt het ruitsymbool gebruikt. Bij elke control flow vanuit een desicion node moet een conditie worden weergegeven (guard). Het ruitsymbool kan ook gebruikt worden om de verschillende activiteitsstromen weer bij elkaar te brengen (merge node). Deze diagramtechniek is gebruikt voor het modelleren van de werkprocessen van de afdeling radiotherapie van het VUmc. Bij het modelleren van het werkproces gaat het om de volgorde van de activiteiten en door welke professies deze activiteiten worden uitgevoerd.

pagina 26 van 131

Modelleren

Afbeelding 2.4: Voorbeeld van een eenvoudig activiteitsdiagram van de radiotherapeutische behandeling van een patiënt. Het diagram maakt gebruik van twee swimlanes (dit zijn de verticale kolommen). In een meer uitgewerkt diagram zou voor elke professie een aparte swimlane aangemaakt kunnen maken. Rechts in het diagram zijn twee ruitsymbolen te zien. De zwarte balk geeft een splitsing aan van de control flow. In tegenstelling tot bij de merge node is hier niet dat één van beide control flows wordt gevolgd, maar beide control flows lopen naast elkaar.

2.2.4 Use case diagram Zoals eerder beschreven is een ‘use case’ is een functionele beschrijving van een onderdeel van een systeem. Een use case is een black box met functionaliteit. Voor de buitenwereld is alleen de functionaliteit van belang, de wijze waarop de functionaliteit wordt verricht is niet van belang. Een use case kan men opvatten als een bedrijfsproces of bedrijfstaak. Bij het formuleren van use cases zullen eerst use cases van bedrijfsprocessen als geheel worden beschreven, vervolgens zullen deze worden verfijnd tot bedrijfsactiviteiten en uiteindelijk zullen de functies worden gespecificeerd. De mate van detaillering zal dus gaandeweg dus toe nemen tijdens het modelleren. In een use case diagram wordt een use case als een ellips worden weergegeven, de naam van de use case wordt in de ellips opgenomen. Een actor wordt in een use case diagram als een luciferpoppetje weergegeven. Dit zou echter onterecht de indruk kunnen wekken dat actoren alleen mensen kunnen zijn. Voor een ander (deel)systeem wordt hetzelfde icoon gebruikt. Deze diagramtechniek is gebruikt bij de analyse van de interoperabiliteitsproblemen van de afdeling radiotherapie van het VUmc.

Afbeelding 2.5: Use case diagram van geanonimiseerde export van DICOM-RT objecten. De use case “geanonimiseerd exporteren” maakt ge-bruik van de use cases “selecteren patiënten”, “selecteren DICOM RT objecten”, “exporteren DICOM RT” en “Haal ziek-tegeschiedenis op”. Modelleren

pagina 27 van 131

2.2.5 Sequentiediagram Dit diagram wordt gebruikt als de volgorde van de berichten die worden verstuurd een belangrijke rol speelt. Een sequentie diagram toont namelijk de berichten in hun onderlinge volgorde en de objecten waar de berichten naar worden verstuurd. Berichten die later worden verstuurd, worden meer naar onder in het diagram getekend. Daarnaast toont het diagram de berichten die als reactie weer naar andere objecten worden gestuurd. Het diagram is zodoende te zien als een script van (geautomatiseerde) activiteiten van een afgeronde taak (zoals bijvoorbeeld een use case) (Benson, 2010; Unified Modeling Language, 2010). Het sequentiediagram wordt door de IHE veelvuldig gebruikt in de integratieprofielen. In afbeelding 2.6 is een sequentiediagram te zien uit het IHE integratieprofiel “Image Registration” (Image Registration (REG) Integration Profile, 2007). Dit profiel voorziet in de functionaliteit dat voor radiotherapie gebruik gemaakt wordt van meerdere datasets die met elkaar gefuseerd worden. Het diagram toont drie objecten die aan elkaar berichten versturen: 1. “Archiver”; Dit object is verantwoordelijk voor de opslag van datasets van verschillende beeldvormende modaliteiten. Hoewel niet gespecificeerd in het integratieprofiel zou dit het PACS kunnen zijn. 2. “Registrator”; Dit object relateert de “frames of reference” de verschillende datasets aan elkaar en registreert de verplaatsingen tussen de datasets. 3. “Registered display”. Dit object is in staat om de gefuseerde datasets af te beelden door gebruik te maken van de opgeslagen verplaatsingen tussen het “frames of reference” van elke dataset. Uit het archief worden de datasets opgehaald. Door de “Registrator” worden de datasets aan elkaar gerelateerd, waarna de datasets weer in het archief worden opgeslagen (bericht 1.2). Indien nodig kunnen de datasets opgevraagd worden door het object dat de datasets afbeeld.

Afbeelding 2.6: Sequentiediagram afkomstig uit het integratieprofiel “Image Registration” dat voorziet in de functionaliteit van het fuseren van DICOM-RT datasets. In de afbeelding zijn drie objecten te zien die aan elkaar berichten versturen. De berichten volgen elkaar op in de tijd. Berichten lager in het diagram zijn later in de tijd (vrij naar figuur 4.3-1 het integratieprofiel Image Registration.(Image Registration (REG) Integration Profile, 2007)). pagina 28 van 131

Modelleren

2.3 Het three-layer graph-based model Op basis van het UML is door de Universiteit van Leipzig een metamodel ontwikkeld, het “Three Layer Graphed bases Meta model” geheten. Dit wordt door de ontwikkelaars afgekort tot het 3LGM2-model, waarbij twee in de naamgeving refereert aan het feit dat dit de tweede versie van het model is. Met de term metamodel wordt bedoeld dat het model zelf geen gebruik maakt van UML, maar dat aan het model een UML class diagram ten grondslag ligt (Winter, Brigl, & Wendt, 2001, 2003). Dit 3LGM2-model is ontwikkeld om de informatiesystemen in de gezondheidszorg te analyseren. Zodoende voegt het een functionaliteit toe aan modellen die vervaardigd zijn op basis van UML. Verschillende Universiteitsziekenhuizen in Duitsland en van een verschillende afdelingen in het AMC zijn de informatiesysteem op deze wijze gemodelleerd en geanalyseerd (Bosman & Raghoebier, 2009; Brigl, Hubner-Bloder, Wendt, Haux, & Winter, 2005; Vries & Vleeschhouwe, 2010). Daarnaast is het 3LGM2-model gebruikt om de regionale medische gegevensuitwisseling in één van de Duitse deelstaten te analyseren (Winter, et al., 2005, 2007). Winter e.a. stellen daarbij dat op basis van het model en de analyses strategische keuzes ten aanzien van informatiemanagement gemaakt kunnen worden. Op basis van het model is tevens een softwareapplicatie ontwikkeld (Wendt, Haber, Brigl, & Winter, 2004; Winter, et al., 2003). Afbeelding 2.7 toont het model dat door studenten, van de Master opleiding Medische Informatie van de Universiteit van Amsterdam, met behulp van de applicatie is vervaardigd is van de afdeling gynaecologie en obstetrie (Vries & Vleeschhouwe, 2010). Het model onderscheidt drie lagen. In de domeinlaag worden de verschillende functies van het ziekenhuis of afdeling gespecificeerd. Het gaat hier om het onderscheiden van de bedrijfsprocessen die nodig zijn om de doelen te bereiken die de afdeling of het ziekenhuis zichzelf stelt. De ‘logische tool’ of applicatielaag richt zich op de applicaties die gebruikt worden om de functies te

Afbeelding 2.7: Een voorbeeld van een informatiemodel vervaardigd op basis van het 3LGM2-model. In de bovenste laag zijn de functionaliteiten beschreven, in de middelstel laag de componenten (computerapplicaties & papierencomponenten) en in de onderste laag de hardware waar de applicaties op draaien. Het model is het resultaat van een analyse van de afdeling gynaecologie en obstetrie van het AMC die is uitgevoerd door studenten van de opleiding Medische Informatica (Vries & Vleeschhouwe, 2010). Modelleren

pagina 29 van 131

ondersteunen. In de fysieke laag worden de fysieke componenten (zoals personal computers, servers, switches, routers, enz.) en hun onderlinge dataverbindingen weergegeven. Omdat het model verder gaat dan het visualiseren IT-gerelateerde zaken, is ook een begrip van de functies van een zorginstelling en haar doelstellingen vereist (Winter, et al., 2003). Naast een beschrijving van de afzonderlijke lagen is het mogelijk om in het model de relatie tussen de drie lagen uit te zetten in een matrix. Van de informatie in de domeinlaag en in de applicatielaag kan een matrix worden weergegeven waarbij de relatie tussen de applicaties en de functies helder overzichtelijk wordt gepresenteerd. Van de informatie in de applicatielaag en de fysieke laag kan een matrix worden weergegeven, waarbij de relatie tussen de applicaties en de fysieke componenten waar zij op draaien overzichtelijk is weergegeven.

2.4 Samenvatting Binnen de context van dit onderzoek zijn twee modelleertechnieken interessant. De modelleertaal Unified Modelling Language wordt veel gebruikt ten behoeve van het ontwikkelen van software, maar wordt ook gebruikt voor het modelleren van bedrijfsprocessen. De modelleertaal kent 13 verschillende diagramtechnieken. In de context van dit onderzoek zijn vijf diagramtechnieken van belang: 1. het class diagram; Dit diagramtype toont de samenhang tussen de verschillende objecten 2. het deployment diagram; Met behulp van dit diagram is de samenhang tussen de verschillende computer componenten en de applicaties die daarop draaien weer te geven. Dit diagram zou gebruikt kunnen worden in plaats van de applicatielaag en de fysieke laag uit het 3LGM2-model dat aan bod komt in de volgende paragraaf. 3. het activiteitsdiagram; Dit diagram geeft de samenhang tussen de activiteiten en welke objecten / actoren daar voor verantwoordelijk zijn weer. Het diagram is met name heel bruikbaar voor het beschrijven van processen. 4. het use case diagram; Met behulp van dit diagram is het mogelijk om de samenhang tussen verschillende functionaliteiten weer te geven. Dit diagram kan met name gebruikt worden om de gewenste functionaliteit van een informatiesysteem bondig neer te zetten. 5. het sequentiediagram. Dit diagram toont evenals het activiteitsdiagram de interactie tussen objecten, maar in dit diagramtype staat de volgorde van de verstuurde berichten centraal. Daarnaast is het 3LGM2-model relevant. Dit model dat gebaseerd is op het UML classdiagram maakt het mogelijk om informatiesystemen in de gezondheidszorg te modelleren en te analyseren.

pagina 30 van 131

Modelleren

3 Methode en materialen In dit hoofdstuk staat de methode van onderzoek centraal. In paragraaf 3.1 wordt de onderzoeks strategie besproken. In paragraaf 3.2 komt de onderzoeksstrategie en in paragraaf 3.3 de methode van dataverzameling en data-analyse aan de orde. Ten behoeve van dit onderzoek zijn de volgende doelstelling en deelvragen geformuleerd: Doelstelling:

Het versterken van de interoperabiliteit van multi-locatie afdelingen radiotherapie in het algemeen en die van het VUmc in het bijzonder. Het verbeteren van de interoperabiliteit heeft tot doel het verbeteren van de zorg van patiënten die een radiotherapeutische behandeling ondergaan. Deelvragen: 1. Welke interoperabiliteitsproblemen zijn actueel voor afdelingen radiotherapie? 2. Welke strategieën worden op afdelingen gebruikt om interoperabiliteitsproblemen te voorkomen? 3. Welke afdelingen radiotherapie in Nederland maken een vergelijkbare ontwikkeling1 door als de afdeling radiotherapie van het VUmc? Welke ervaringen bij het werken op twee locaties zijn voor het VUmc belangrijk? 4. Welke afdelingen radiotherapie in het buitenland lopen voorop in de aanpak van interoperabiliteitsproblemen en kunnen een voorbeeld zijn voor de afdeling radiotherapie van het VUmc? 5. Hoe verlopen de datastromen binnen de afdeling radiotherapie van het VUmc? 6. Welke datastromen lopen naar informatiesystemen elders in het ziekenhuis en welke lopen eventueel naar extramurale informatiesystemen? 7. Hoe gaat het werkproces op de afdeling radiotherapie van het VUmc eruit zien in de multilocatie situatie? 8. Welke knelpunten in interoperabiliteit zijn te verwachten ten gevolge van de groei naar een multi-locatie afdeling? 9. Hoe zouden deze knelpunten opgelost kunnen worden? 10. Wat zijn de voor- en nadelen van de verschillende oplosstrategieën?

3.1 Onderzoeksstrategie Verschuren en Doorewaard onderscheiden een aantal classificaties in het uitvoeren van wetenschappelijk onderzoek. Gekozen dient te worden tussen theoriegericht en praktijkgericht onderzoek en tussen meer kwantitatief of meer kwalitatief onderzoek (Verschuren & Doorewaard, 2000). Bij de keuze tussen theoriegericht en praktijkgericht onderzoek speelt in belangrijke mate het doel van het onderzoek mee. Theoriegericht onderzoek is gericht op het oplossen van een probleem in de theorievorming. Daarentegen heeft praktijkgericht onderzoek als doel een bijdrage te leveren aan het 1

Hierbij wordt gedoeld op het werken op zowel op een hoofdlocatie als één of meerdere satellietlocaties.

Methode en materialen

pagina 31 van 131

oplossen van een probleem in de praktijk. Het doel van dit onderzoek is het geven van aanbevelingen aan de afdeling radiotherapie van het VUmc ter verbetering van de interoperabiliteit. Omdat bij dit onderzoek sprake is van praktijk gerelateerd probleem, is gekozen voor een praktijkgericht onderzoek. Het maken van de keuze tussen een kwantitatief onderzoek en een kwalitatief onderzoek wordt mede bepaald door de wijze waarop de resultaten gepresenteerd gaan worden. Bij kwantitatief onderzoek worden de resultaten vooral in grafieken, tabellen en cijfers gepresenteerd. Bij kwalitatief onderzoek worden de resultaten meer verbaal en beschouwend beschreven (Verschuren & Doorewaard, 2000). Omdat dit onderzoek meer beschouwend van aard om begrip te verkrijgen in de problematiek, is gekozen voor een kwalitatief onderzoek. Bij het presenteren van de gegevens van de enquêtes worden uiteraard wel cijfers gepresenteerd. Hierbij is het doel echter de omvang en de importantie van het probleem te schetsen. Verschuren en Doorewaard (2000) noemen een vijftal belangrijke onderzoeksstrategieën, dit zijn: 1. de survey; 2. het experiment; 3. de casestudy; 4. de gefundeerde theoriebenadering; 5. het bureauonderzoek. Met uitzondering van de laatste zijn dit allemaal empirisch onderzoeksstrategieën. Bij empirisch onderzoek worden de gegevens verkregen door zelf in het veld gegevens te verzamelen. Tijdens het vooronderzoek bleek dat geen andere studies zijn verricht naar interoperabiliteitsproblemen binnen het vakgebied radiotherapie, zodoende is gekozen voor een empirische onderzoeksstrategie. De onderzoeksvragen één tot en met vier hebben tot doel om een breed beeld van de problematiek te verkrijgen. De onderzoeksstrategie die hier bij is gekozen is die van het survey. Passende dataverzamelingsmethoden zijn enquêtes en interviews. Beide methoden worden gebruikt om de antwoorden op deze deelvragen te vinden. Omdat bij de onderzoeksvragen vijf tot en met tien specifiek wordt gekeken naar de problematiek van interoperabiliteit van de afdeling radiotherapie van het VUmc, is hierbij als onderzoeksstrategie gekozen voor de case study. Bij een case study gaat het om diepteonderzoek, de problematiek is niet los te zien van de context. Voor de casestudy zijn geen vastliggende dataverzamelingsmethoden voorgeschreven (Jong de, et al., 2008). Als dataverzamelingsmethoden is gekozen voor observatie, het bestuderen van documenten en het voeren van gesprekken. Drie aspecten hebben meegespeeld bij de keuze van case study als onderzoeksdesign. Ten eerste geeft een casestudy de mogelijkheid om een integraal beeld te krijgen van het onderzoeksgebied. Van te voren was maar voor een deel bekend welke factoren een rol spelen bij de interoperabiliteitsproblemen op de afdeling radiotherapie van het VUmc en welke knelpunten aan het licht zouden komen in de loop van het onderzoek. pagina 32 van 131


Een tweede aspect dat heeft meegespeeld bij de keuze, is dat bij aanvang van het onderzoek nog veel onduidelijk was over het onderzoeksonderwerp. De voorstructurering van het onderzoek is bij een casestudy als onderzoeksdesign beperkt, dit maakt dat de casestudy een heel flexibel onderzoeksdesign is. Tijdens het onderzoek kan nog van koers veranderd worden (Verschuren & Doorewaard, 2000). Tot slot heeft de keuze om de survey te combineren met een casestudy van het VUmc te maken met het feit dat bij een survey een ongeoorloofde simplificatie van de werkelijkheid zou kunnen optreden (Hutjes, 2000). Hutjes stelt in zijn beschouwing over de waarde van de casestudy dat, om deze reden, het combineren van een casestudy met een survey erg waardevol kan zijn (Hutjes, 2000). De casestudy geeft diepgang van de context en de survey ondersteunt de externe validiteit. Aan dit open design kleven echter wel enkele nadelen. De betrouwbaarheid is door het open onderzoeksdesign moeilijk te waarborgen. Bij kwalitatief onderzoek gaat het bij betrouwbaarheid om de mate van stabiliteit van de resultaten bij hertesting. Het schematiseren van de overwegend tekstuele data zou volgens Lutjes de controle voor de onderzoeker zelf en de lezer vergroten (Hutjes, 2000). De modellen, van de werkprocessen en de informatiestromen op de afdeling radiotherapie, zijn op tekstuele beschrijvingen en geven door de schematisering inderdaad een controleerbare weergave van de situatie. Daarnaast is bij een casestudy de interne validiteit moeilijk afdoende te waarborgen. Bij interne validiteit gaat het om het feit of wel gemeten wordt wat beoogd wordt te meten. Door triangulatie van dataverzameling toe te passen is dit voor een deel te ondervangen (Hutjes, 2000). Bij de dataverzameling ten behoeve van de casestudy is zijn observaties gecombineerd met gesprekken en documentenanalyse. Tot slot wordt in de literatuur de beperkte externe validiteit als nadeel van de casestudy genoemd (Verschuren & Doorewaard, 2000). Indien heel erg gericht wordt op de case dan zouden de conclusies niet goed te generaliseren zijn. Dat is ook één van de reden waarom bij de keuze van het onderzoeksdesign de keus is gemaakt om de casestudy te combineren met een survey. Op deze manier is nagegaan in hoeverre de problematiek op de afdeling radiotherapie van het VUmc exemplarisch is en of het generaliseren van de conclusies uit de casestudy toegestaan is.

3.2 Survey Om op de eerste drie onderzoeksvragen antwoord te kunnen geven is een enquête gehouden onder de afdelingen radiotherapie in Nederland. Om inzicht te krijgen in de omvang van de interoperabili teitsproblemen is naar alle afdelingen in Nederland een vragenlijst verstuurd. Om antwoord te geven op onderzoeksvraag 4 is de vragenlijst verspreid onder afdelingen in de Verenigde Staten, Europa en Australië. Om vervolgens meer achtergrond informatie te krijgen omtrent de aard van de interoperabiliteitspro blemen, de impact die de problemen hebben op het zorgproces en de vraag hoe afdelingen omgaan met de problemen zijn vier diepte-interviews gehouden met professionals op geselecteerde afdelingen radiotherapie. De selectiecriteria worden in paragraaf 3.2.2 uit één gezet.


pagina 33 van 131

3.2.1 Enquêtes Om de omvang van interoperabiliteitsproblemen vast te stellen is als dataverzamelingsinstrument gekozen voor de enquête. Hiervoor is een vragenlijst ontwikkeld welke gebruik maakt van zo wel gesloten als open vragen (zie bijlage 1). Om de vragenlijst ook onder afdelingen in het buitenland te kunnen aanbieden, is deze vertaald naar het Engels (zie bijlage 2). Reden om de vragenlijst ook internationaal aan te bieden was om te onderzoeken of de situatie in Nederland afwijkt van de situatie in het buitenland en of aanvullende informatie aanwezig was. Inhoud De vragenlijst valt uiteen in drie delen. Met het eerste deel van de vragenlijst is de complexiteit van de afdeling in kaart te gebracht. In dit deel zijn vragen gesteld over: de gebruikte apparatuur en software op de afdeling, welke apparatuur gedeeld wordt met afdelingen medische beeldvorming en of gewerkt wordt op meerdere locaties. Om een indruk te krijgen van de complexiteit van de datastroom binnen de afdeling zijn tevens vragen gesteld over welke koppelingen aanwezig zijn. In het tweede deel van de vragenlijst is ingegaan op de interoperabiliteitsproblemen die de afdeling ervaart en de mate waarin deze problemen het gewenste werkproces beïnvloeden. Naar de interoperabiliteitsproblemen wordt op drie niveaus geïnformeerd: problemen met informatiesystemen binnen de afdeling, problemen tussen informatiesystemen op afdeling radiotherapie en systemen elders in het ziekenhuis en problemen tussen informatiesystemen op de afdeling radiotherapie en informatiesystemen buiten het ziekenhuis. Tot slot is in het derde en laatste deel van de vragenlijst gevraagd naar de gebruikte strategieën om interoperabiliteitsproblemen op te lossen en naar de bekendheid met de IHE. De Engelse vragenlijst is na een aantal onvolledig ingevulde vragenlijsten en het achterblijven van de respons iets ingekort waarbij met name in het eerste deel van de vragenlijst minder in detail is gevraagd naar de complexiteit van de afdeling. Verder is in tegenstelling tot de Nederlandse vragenlijst gevraagd of in het verleden ten gevolge van interoperabiliteitsproblemen er kwaliteitsbreuken of incidenten opgetreden zijn. In de Nederlandse vragenlijst is hier niet naar gevraagd omdat in eerste verondersteld werd dat deze informatie wellicht uit de database van de vereniging PRISMA-RT2 verzameld kon worden. Toen bleek dat dit binnen het tijdsbestek van het onderzoek niet mogelijk was, is dit aspect meegenomen in de interviews. Procedure Om de interne validiteit van de vragenlijst te waarborgen, is in eerste instantie een pilot gehouden, waarin twee afdelingen participeerden. Op basis van de reacties en de feedback op de vragenlijst is de lijst op enkele punten aangepast. Zo zijn de vragen zijn concreter gemaakt en is het begeleidend schrijven aangepast. In eerste instantie was onvoldoende duidelijk dat van elk instituut één ingevulde vragenlijst werd verwacht. 2

PRISMA-RT is een samenwerkingsverband tussen radiotherapeutische instellingen die samen werken op het gebied van patiëntveiligheid. De naam PRISMA-RT is een acroniem voor Prevention, Recovery and Information System for Monitoring and Analyses in RadioTherapy.

pagina 34 van 131


De vragenlijst is beschikbaar gesteld via het internet. Tijdens de pilot werd gebruik gemaakt van een gratis enquête hulpmiddel op internet. Vanwege de ongewenste toevoeging van reclame en het informeren naar gegevens van de contactgegevens van de respondent door de aanbieder is bij de definitieve vragenlijst gebruik gemaakt van een betaalde aanbieder. Een uitnodiging om deel te nemen aan het onderzoek is verspreid via de e-mail. De uitnodiging om deel te nemen is verstuurd naar alle afdelingen radiotherapie in Nederland. Hierbij is de vragenlijst in ieder geval gestuurd naar de hoofd klinische fysicus van de afdeling radiotherapie en indien bekend naar de vertegenwoordiger van de afdeling in de netwerkgroep radiotherapie-ICT. Na een eerste mailing is in een later stadium een tweede mailing verstuurd naar alleen die afdelingen die nog niet hadden gereageerd. Voor de uitnodigingen van buitenlandse afdelingen is gebruik gemaakt van het intercollegiale netwerk van de opdrachtgever en contacten binnen de ESTRO en contacten van het lectoraat Medische Technologie van Hogeschool Inholland. Analyse De gegevens uit de enquêtes zijn verzameld in een database. Na het sluiten van de dataverzameling zijn de gegevens geëxporteerd naar programma Excel en verwerkt. Om een overzicht van de resultaten van de gesloten vragen te kunnen geven, zijn hier tabellen en diagrammen van vervaardigd. De open vragen en dan in het bijzonder de vragen over de interoperabiliteitsproblemen zijn eerst gerubriceerd en vervolgens zijn daar ook diagrammen van vervaardigd.

3.2.2 De interviews Van de 21 afdelingen radiotherapie zijn vier afdelingen geselecteerd voor het afnemen van een interview. Dit zijn de volgende afdelingen: • Het Universitair Medisch Centrum Nijmegen St. Radboud (UMCN) • Het Algemeen Medisch Centrum (AMC), Amsterdam • Het Verbeeten Instituut, Tilburg • Het Erasmus Medisch Centrum (ErasmusMC), Rotterdam Het AMC, het Verbeeten Instituut en het ErasmusMC zijn geselecteerd door hun ervaring met het werken op meerdere locaties. Het UMCN is geselecteerd vanwege het feit dat deze afdeling haar zorgproces heeft gemodelleerd. Inhoud Voor de interviews is gekozen voor een half gestructureerd interview. Op basis van de uitkomsten van enquêtes is een vragenlijst voor de interviews opgesteld (Bijlage 3). De geformuleerde vragen hebben betrekking op: • Het werken op twee locaties Dit onderdeel heeft betrekking op de ervaringen van het instituut met het werken op twee locaties. Aandachtspunten in dit deel zijn: splitsing van het werkproces op de hoofd- en nevenlocatie(s), deskundigheid op de nevenlocatie(s) en de architectuur van het netwerk.


pagina 35 van 131

•

•

•

Ervaring met interoperabiliteitsproblemen Dit onderdeel gaat in op de ervaring met interoperabiliteitsproblemen en de impact daarvan op het gewenst zorgproces. Tevens wordt ingegaan op de vraag of interoperabiliteitsproblemen in het verleden hebben geleid tot incidenten. Toegepaste strategie Geïnformeerd is naar de gebruikte strategieën en of de gebruikte strategie succesvol is. De rol van de IHE (Integrating the Healthcare Enterprise) Met dit deel is in kaart gebracht in hoeverre de respondent op de hoogte is van het werk van de IHE en of de werkwijze volgens de respondent succesvol is.

Procedure Omdat bij het afnemen van interviews de dataverzameling en de analyse naast elkaar lopen en een iteratief proces is, zijn de uitkomsten van elk interview gebruikt om de daarop volgende interviews bij te stellen. Als voorbereiding op elk interview zijn de vragen toegespitst op de afdeling van de respondent en zijn de niet relevante vragen geschrapt. Om de betrouwbaarheid te waarborgen is gebruik gemaakt van een interview protocol (Bijlage 3). De vragen in dit protocol zijn geformuleerd als open vragen. Afhankelijk van de wijze waarop de re spondent antwoordt, bondig of uitweidend, is de vraag als open vraag gesteld of geherformuleerd als gesloten vraag. Om de objectiviteit en de interne validiteit zo groot mogelijk te laten zijn, is geprobeerd om tijdens de interviews zo veel mogelijk als toehoorder en observator te fungeren. Indien toestemming is gegeven, is het interview opgenomen. Dit heeft als voordeel dat tijdens het interview geen aandacht besteed hoeft te worden aan het notuleren. Bijkomend voordeel is dat ten gevolge van het notuleren tijdens het interview geen vervorming van de data plaatsvindt. Na het afsluiten van het onderzoek zijn de opnames vernietigd. Van elk interview is een verslag gemaakt waarin in elk geval is vastgelegd de datum van het interview, de respondent(en) en een weergave van het gesprek. Enkele dagen na het interview is het verslag voor revisie aan de respondent gestuurd. Samen met dit verslag is een toestemmingsverklaring voor gebruik van de gegevens in het onderzoeksverslag aan de respondent gestuurd. Aan elk interview is een korte kennismaking voorafgegaan, deze had tot doel de betrokkenheid van de respondent te vergroten. Tijdens de kennismaking is het doel van het onderzoek en het interview ge schetst en is de toestemming van de respondent voor opname van het interview gevraagd. In het eerste deel van het interview is ingegaan op eventuele onduidelijkheden in de reactie van de respondent op de vragenlijst. Vervolgens zijn in het tweede deel de relevante vragen van het interview aan de respondent gesteld. De volgorde van de vragen in interviewprotocol zijn bedoeld als uitgangspunt, afhankelijk van de antwoorden van de respondent is deze aangepast. Na het afronden van het interview, is de verdere procedure uitgelegd ten aanzien van de verslaglegging en de toestemming voor gebruik van de informatie in het onderzoeksverslag.

pagina 36 van 131


Naast de interviews met de gebruikers zijn nog enkele gesprekken gevoerd met experts in de industrie en binnen IHE Nederland en zijn enkele stuurgroep vergaderingen van de IHE bezocht. Doel van deze gesprekken was het verifiëren van informatie die in de loop van het onderzoek naar voren kwam. Analyse Zoals eerder aangegeven is, zijn de interviews opgenomen en is van elk interview een verslag gemaakt. De interviews zijn volgens een voor kwalitatief onderzoek specifieke manier uitgewerkt, uitrafelen genaamd (Boeije, 2005; Verhoeven, 2010). Deze systematiek verloopt in een aantal stappen. Nadat de eerste resultaten van de enquêtes en de eerste interviews zijn verzameld, is ten behoeve van het uiteenrafelen een lijst met codes opgesteld, het zogenaamde open coderen. Vervolgens zijn, uitgaande van deze lijst, de codes geordend en is een hiërarchie in de codes aangebracht (axiaal coderen). Deze lijst is bij verdere data-analyse gebruikt (selectief coderen) en daar waar nodig bijgesteld. In de daarop volgende fase zijn relaties tussen de codes gevonden en deze zijn in de laatste interviews getoetst aan de hand van nieuwe data.

3.3 Casestudy Om op de onderzoeksvragen vier tot en met tien antwoord te kunnen geven zijn op de afdeling radiotherapie van het VUmc gesprekken gevoerd, observaties gepleegd en documenten geanalyseerd. De gegevens die hiermee zijn verkregen zijn gebruikt om een tekstuele beschrijving van het werkproces te verkrijgen. Modelvorming Deze tekstuele beschrijving zijn vervolgens gebruikt om procesdiagrammen te vervaardigen met behulp van de modelleertaal Unified Modelling Language. Als diagramtype is hierbij gekozen voor acti viteitsdiagrammen. Zoals beschreven in het voorgaande hoofdstuk is dit type diagram goed te gebruiken om inzicht te krijgen in uitgevoerde deelactiviteiten en welke professionals daarbij betrokken zijn. Voor het construeren van de UML-diagrammen is gebruik gemaakt van het software pakket Visual Paradigma for UML versie 8.1. Nadat een beeld is verkregen van de werkwijze is volgens het 3LGM2-model een analyse gemaakt van informatiestromen op de afdeling radiotherapie. De reeds vervaardigde UML-diagrammen zijn gebruikt om de toplaag van het model, de functionele laag, te vullen. Op basis van documenten en gesprekken zijn tabellen vervaardigd van de gebruikte componenten (applicaties, papieren componenten en de fysieke componenten). Deze informatie is gebruikt om de applicatie- en de fysieke laag te modelleren. Voor het vervaardigen van de modellen volgens het 3LGM2-model is gebruik gemaakt van het door de universiteit van Leipzig ontwikkelde software pakket (Winter, et al., 2001, 2003). Gebruik is gemaakt van versie 3.2.8. De informatie die nodig was om te komen tot beide modellen is verkregen door met verschillende betrokkenen op de afdeling radiotherapie van het VUmc gesprekken te voeren. Hierbij zijn zowel gesprekken gevoerd met klinisch fysici, radiotherapeutisch laboranten en de informatiedeskundige van de afdeling.


pagina 37 van 131

Bij de modelvorming is gekozen voor een cyclische werkwijze. Nadat na de eerste gesprekken concept modellen vervaardigd waren, zijn deze voorgelegd aan de betrokkenen. Op basis van correcties en nieuwe informatie zijn de modellen verfijnd en bijgesteld. In elke daarop volgende cyclus is het detailleringniveau van de modellen toegenomen.

Analyse interoperabiliteitsproblemen Daarnaast zijn de interoperabiliteitsproblemen die de afdeling radiotherapie ondervindt geanalyseerd. Deze interoperabiliteitsproblemen zijn gelegd naast de ontwikkelde en de nog te ontwikkelen integratieprofielen van de IHE. Nagegaan is of deze profielen van toepassing zijn op de gevraagde functionaliteit.

pagina 38 van 131


4 Resultaten survey In dit hoofdstuk worden de resultaten van survey gepresenteerd. Achtereenvolgens worden de resultaten van de enquête in Nederland, de enquête in het buitenland en de interviews in Nederland gepresenteerd. In dit hoofdstuk wordt een samenvatting van de ruwe data gepresenteerd. Omdat in de vragenlijst open vragen gesteld zijn, was opname van de gegevens in een bijlage niet wenselijk. Het bestand met de gegevens is voor eventuele nadere analyse beschikbaar voor de afdeling radiotherapie van het VUmc.

4.1 Resultaten enquêtes Nederland Bij de presentatie van de resultaten van de enquêtes uitgevoerd in Nederland is de volgende structuur gehanteerd: • de mate van respons; • complexiteit van de afdelingen • de interoperabiliteitsproblemen die ervaren worden; • de gebruikte strategieën om de problemen te voorkomen; • bekendheid met het werk van de IHE.

4.1.1 Respons In Nederland was de respons op de uitnodiging om deel te nemen aan de enquête groot. Vanuit alle afdelingen (n=21) is tenminste één reactie gekomen. Op drie afdelingen is de vragenlijst door meerdere personen ingevuld. De oorzaak hiervan was divers. Door één afdeling is het begeleidend schrijven anders geïnterpreteerd, één van de afdelingen deed aan de pilot mee en heeft daarna de vragenlijst opnieuw ingevuld en bij één afdeling was in de database de vragenlijst niet compleet en is de vragenlijst opnieuw ingevuld. Later kwam de oorspronkelijke respons toch beschikbaar. Het merendeel van de vragenlijsten is ingevuld door klinisch fysici, iets meer dan een kwart is ingevuld door een informaticus (Afbeelding 4.1). Enkele respondenten hebben deze vraag overgeslagen, de reden hiervoor is onduidelijk.

Afbeelding 4.1 Bijgaande afbeelding toont de functie van de respondenten. Dertig procent is informatie deskundige en zestig procent is (klinisch) fysicus. De functie van de overige tien procent is zeer divers. Resultaten survey

pagina 39 van 131

4.1.2 Complexiteit van de afdelingen De afdelingen zijn verdeeld in drie subgroepen op basis van het aantal versnellers dat de afdeling bezit. • kleine afdelingen met drie of minder versnellers; • middelgrootte afdelingen met vier tot zes versnellers; • grote afdelingen met zeven of meer versnellers. Volgens deze indeling kent Nederland vier kleine afdelingen, tien middelgrote en zeven grote afdelingen (Tabel 4.1). Bij deze indeling is RCWest beschouwd als twee aparte afdelingen, omdat zij nog maar recent zijn gefuseerd. Zou dit niet gedaan zijn dan zou zij in de categorie grote afdelingen vallen. Nederland kent drie afdelingen met meerdere locaties, hierbij is RCWest niet meegerekend. Twee van deze afdelingen kennen één nevenlocatie, het Erasmus MC kent twee nevenlocaties. Een aantal afdelingen heeft plannen voor het opzetten van één of meerdere satelliet locaties. Omdat in de enquête gevraagd is de huidige situatie te beschrijven, is dit niet terug te zien in het geschetste overzicht. Zestien afdelingen hebben versnellers van één fabrikant. Alle kleine afdelingen hebben versnellers van één fabrikant. Tabel 4.1 In bijgaande tabel is een overzicht van de afdelingen radiotherapie. De afdelingen zijn onderverdeeld op basis van het aantal versnellers en of zij single of multi-vendor zijn. Tussen haakjes is het aantal versnellers vermeld. Cursief zijn de afdelingen die meerdere locaties kennen, tussen haakjes staat dan zowel het aantal versnellers op de hoofdlocatie als de nevenlocatie(s) vermeld. Groot Single-vendor

Multi-vendor

Middelgroot

Amsterdam, NKI-AvL (10) Eindhoven, CZE (8) Maastricht, MAASTRO (7) Utrecht, UMCU (8)

Amsterdam, AMC (4+2)

Groningen, UMCG (7)

Amsterdam, VUmc (6)

Arnhem, ARTI (6) Enschede, MST (4) Leeuwarden, RIF (5) Leiden, LUMC (5) Nijmegen, UMCN (4) Vlissingen, ZRTI (4)

Klein Alkmaar, MCA (3) Delft RdGG (2) Den Haag, RCWest Leyweg (2) Zwolle, ISALA (3)

Rotterdam, ErasmusMC (7+2+2) Deventer, RISO (4) Tilburg, Verbeeten Instituut (6+2) Den Haag, RCWest Lijnbaan (5)

Ongeveer de helft van de afdelingen (n=12) heeft nog een conventionele lokalisator en op één afdeling na heeft elke afdeling in Nederland één of meerdere CT-lokalisatoren. De afdelingen die over een eigen PET-CT beschikken, zijn zelfstandig opererende radiotherapeutische instituten en hebben zodoende niet de mogelijkheid deze imaging modaliteit te delen met een afdeling nucleaire geneeskunde. Zeventien afdelingen geven aan één of meer beeldvormende modaliteiten met een afdeling radiodiagnostiek of nucleaire geneeskunde te delen. Respectievelijk zes afdelingen delen een CT, 14 afdelingen delen een MRI en 12 een PET/CT. Eén afdeling geeft aan tevens een PET te delen. Vier afdelingen geven aan geen imaging modaliteiten te delen, drie daar van zijn zelfstandige radiotherapeutische instituten. Drie zelfstandige radiotherapeutische instituten delen één of twee beeldvormende modaliteiten.

pagina 40 van 131

Resultaten survey

Van de 21 radiotherapie afdelingen in Nederland maken 12 afdelingen gebruik van treatment planningssystemen van meer dan één fabrikant. Dit heeft geen duidelijke relatie met de grootte van de afdeling. Eén van de vier kleine afdelingen en drie van de vier grote afdelingen hebben TPS-werkstations van meer dan één fabrikant. De commercieel gebruikte software is zeer divers en geen van de afdelingen maakt gebruik van software van één fabrikant. Waarschijnlijk levert geen van de fabrikanten alle gewenste functionaliteiten. Dit wordt ook ondersteund door de constatering dat negentien afdelingen gebruik maakt van zelf ontwikkelde software. Het ontbreken van de gewenste functionaliteit in commerciële software wordt als belangrijkste redenen genoemd. Daarnaast worden de wens naar flexibiliteit en de wens om volledige controle te hebben over de informatiestroom genoemd. Bij de zelf ontwikkelde applicaties gaat het om applicatie ten behoeve van: • kwaliteitsborging (EPID-dosimetrie, afregelen van MLC’s, etc.); • positieverificatie; • intekenen van CT en MRI beelden; • workflow. De architectuur van de afdelingen is zeer divers. Binnen de afdelingen wordt veel gebruik gemaakt van DICOM(-RT) koppelingen, op enkele afdelingen wordt gebruik gemaakt van een eigen PACS-server. Deze functioneert dan als een spin in het web met daar omheen het TPS, de beeldvormende modaliteiten, het verificatiesysteem en eventueel de workflow applicatie. Voor connectiviteit met informatiesystemen elders in het ziekenhuis wordt veel gebruik gemaakt van HL7-koppelingen en DICOM-koppelingen. Voor de koppeling met het ziekenhuis informatiesysteem en de financiële administratie betreft het vaak een HL7 koppeling. Bij de koppelingen met het ZIS en de financiële administratie gaat het onder andere om het uitwisselen van NAW-gegevens, afspraken van de patiënt en verrichtingen informatie. Bij de DICOM-koppelingen zijn het de koppelingen met het ziekenhuis PACS en direct met beeldvormende modaliteiten op de afdeling radiodiagnostiek en nucleaire geneeskunde. Opgemerkt dient te worden dat de zelfstandig opererende radiotherapeutische instituten geen verbindingen hebben met informatiesystemen elders in het ziekenhuis, bij deze instituten gaat het dan per definitie om extramurale koppelingen. Enkele afdelingen geven aan gebruik te maken van afwijkende maatwerk koppelingen, deze koppelingen zijn dan vaak ontwikkeld omdat een HL7-koppeling niet mogelijk was. Acht afdelingen geven aan extramurale koppelingen te hebben. Het gaat hier om DICOM-koppelingen voor diagnostische data uit andere instituten. Alle zelfstandige radiotherapeutische instituten maken van deze mogelijkheid gebruik om diagnostische data binnen te halen. Eén radiotherapeutisch instituut geeft aan naast de DICOM-koppeling tevens gebruik te maken van een HL7-koppeling met een extern ziekenhuis. Enkele afdelingen geven aan gebruik te maken van CD en DVD als informatie drager voor de uitwisseling van DICOM-beelden. De afdelingen die al op meerdere locaties werken, hebben alle een netwerk verbinding tussen de locaties. Eén van de drie afdelingen geeft aan daarnaast gebruik te maken van een videoconferencing via een derde partij. Resultaten survey

pagina 41 van 131

Afbeelding 4.2 Gerapporteerde interoperabiliteitsproblemen van de Nederlandse respondenten ingedeeld naar de plaats waar ze optreden: binnen de grenzen van de afdeling, tussen de afdeling en de rest van het ziekenhuis of tussen de afdeling en locaties buiten het ziekenhuis. Op de y-as de relatieve cummulatieve bijdrage. Tabel 4.2: Interoperabiliteitsproblemen ingedeeld naar categorie. In de kolommen zijn de problemen ingedeeld naar de plaats waar ze optreden: binnen de grenzen van de afdeling, tussen de afdeling en de rest van het ziekenhuis of tussen de locaties buiten het ziekenhuis. In de rijen zijn de problemen ingedeeld naar de oorzaak van de problemen. Binnen de afdeling

Tussen de afdeling en


de rest van het ziekenhuis

extramurale instellingen

Totaal

DICOM

12

7

5

24

DICOM-RT

26

2

0

28

HL7

2

10

2

14

Overig

7

8

14

29

Totaal

47

27

21

95

4.1.3 Interoperabiliteitsproblemen Alle afdelingen geven aan één of meerdere interoperabiliteitsproblemen te ondervinden. Totaal zijn vijfennegentig interoperabiliteitsproblemen gerapporteerd, zevenenveertig problemen hebben betrekking op informatieoverdracht binnen de grenzen van de afdeling, zevenentwintig tussen de afdeling en de rest van het ziekenhuis en eenentwintig tussen de afdeling en locaties buiten het ziekenhuis. Ruim de helft (52 van de 95) van de gerapporteerde problemen heeft betrekking op de informatieoverdracht op basis van DICOM-objecten en achtentwintig van de tweeënvijftig heeft betrekking op DICOM-RT objecten (Afbeelding 4.2 en tabel 4.2). In afbeelding 4.2 is de relatieve bijdrage van het type probleem op het totale aantal grafisch uitgezet in tabel 4.2 zijn de absolute aantallen gepresenteerd.

pagina 42 van 131

Resultaten survey

Het gaat hier dan om: • problemen in de gegevens overdracht van TPS naar verificatiesysteem; • problemen in de gegevens overdracht van het verificatie systeem naar de imaging software; • andere interpretatie van de DICOM-tags; • problemen rond de werklijst koppelingen; • het niet kunnen archiveren van de DICOM-RT objecten in het PACS; • het ontbreken van fusie-informatie tussen twee beeldmodaliteiten. Bij de niet radiotherapie gerelateerde DICOM-problemen (de overige 24), worden problemen gerapporteerd ten aanzien van: • identificatie van de patiënt; • identificatie van medisch beeldvormend onderzoek; • het gebruik van de DICOM-worklist. Tussen de overige problemen worden technische interoperabiliteitsproblemen gerapporteerd, pro blemen die te maken hebben met het niet toegankelijk zijn van gegevens in een database. Daarnaast worden bij de groep overig een aantal zaken beschreven die eigenlijk meer een onderliggende oorzaak dan het eigenlijke probleem betreffen. Zo wordt door vijf instituten afstemmings- en beleidsproblemen beschreven die ertoe leiden dat de gewenste koppeling niet kan worden gelegd tussen twee informatiesystemen. De respondenten hebben ook aangegeven welke problemen het gewenste werkproces het meest beïnvloeden. Daarbij valt op dat de met name de gerapporteerde problemen tussen het planningssysteem en het verificatie systeem worden gekwalificeerd als problemen met een grote impact. Het gaat dan met name over problemen in de export van gegevens naar het verificatiesysteem. Veertien van de afdelingen rapporteren interoperabiliteitsproblemen tussen de afdeling en de rest van het ziekenhuis. De zes zelfstandige instituten rapporteren hier over uiteraard geen interoperabiliteitsproblemen. Het gaat hier dan om problemen in de gegevensuitwisseling tussen het ziekenhuis informatiesysteem en de workflow applicaties die gebruikt worden op de afdeling radiotherapie. Het gaat dan bijvoorbeeld om het niet kunnen uitwisselen van informatie tussen de workflow applicatie op de afdeling radiotherapie en het ZIS. Daarnaast geeft ongeveer een kwart van de afdelingen aan problemen te ondervinden in de informatieoverdracht tussen systemen op de afdeling radiotherapie en het ziekenhuis PACS. Hierbij worden zowel de problemen rond de koppelingen met het ZIS als die met een PACS gekwalificeerd als problemen met een zeer grote invloed op het gewenste werkproces. Het aantal interoperabiliteitsproblemen (n=13) buiten de grenzen van het ziekenhuis is beperkt en de gerapporteerde problemen hebben betrekking op verschillen in de wijze van patiëntidentificatie of problemen met het uitwisseling van DICOM-beelden van of naar andere instituten. Eén afdeling geeft tevens aan dat ze problemen ondervindt met het kunnen waarborgen van de gewenste toestemmingsvereiste.

Resultaten survey

pagina 43 van 131

4.1.4 Strategieën van Nederlandse afdelingen Op de vraag hoe afdelingen interoperabiliteitsproblemen oplossen, wordt divers gereageerd. Enkele afdelingen geven aan dat de problemen niet te voorkomen zijn. Ongeveer een kwart van de afdelingen geeft aan dat hun strategie is, het maken van goede afspraken met de fabrikant bij aanschaf of dat de problemen teruggelegd worden bij de fabrikant als ze optreden. Bijna een derde van de afdelingen geeft aan de problemen op te lossen met behulp van zelf ontwikkelde applicaties of door te komen tot goede afspraken met de centrale ICT-afdeling of betrokkenen buiten het ziekenhuis. Eén afdeling geeft aan dat ze probeert de problemen te voorkomen door het aantal koppelingen te beperken en een andere afdeling geeft aan dat zij probeert zoveel mogelijk producten van één fabrikant aan te schaffen.

4.1.5 Bekendheid met de IHE Dertien van de respondenten geeft aan bekend te zijn met het werk van de IHE. Eén van de respondenten geeft aan dat één van de concept profielen op de afdeling is geïmplementeerd, het gaat hierbij om het profiel “RT Treatment workflow”. Tot slot geeft geen van de respondenten aan dat gebruik is gemaakt van de profielen bij een aanbestedingstraject. Geen van de respondenten geeft aan dat de afdeling betrokken is bij het werk van de IHE. Wel geeft één van de respondenten graag bij de actieve rol te willen spelen bij de activiteiten van de IHE.

pagina 44 van 131

Resultaten survey

4.2 Resultaten enquête buitenland Net zoals bij de presentatie van de enquêtes onder de Nederlandse afdelingen is de volgende structuur aangehouden: • de mate van respons; • complexiteit van de afdelingen • de interoperabiliteitsproblemen die ervaren worden; • incidenten ten gevolge van interoperabiliteitsproblemen1; • de gebruikte strategieën om de problemen te voorkomen; • bekendheid met werk van de IHE.

4.2.1 Response Vanuit het buitenland zijn vijftien reacties gekomen, waarvan zes reactie onvolledig waren. De negen volledige reactie kwamen uit de Verenigde Staten, Australië, België, Oostenrijk en Zweden (Tabel 4.3). Alle vragenlijsten zijn ingevuld door klinisch fysici. Tabel 4.3: Overzicht van de instituten uit het buitenland waarvan een volledige reactie is ontvangen. Land

Instituut

Verenigde Staten

UT MDACC, Houston Barnes Jewish Hospital, St. Louis Rhode Island Hospitals, Providence

Australië

WBRC Alfred Hospital, Prahran

België

UZ Brussel, Brussel

Italië

San Rafaelle Hospital, Milaan

Oostenrijk

Medical University Vienna, Wenen Medical University Gräz, Gräz

Zweden

Skäne University Hospital, Lund

4.2.2 Complexiteit van de afdelingen Net zoals bij de Nederlandse afdelingen zijn de afdelingen van de buitenlandse respondenten verdeeld in drie subgroepen op basis van het aantal versnellers dat de afdeling bezit. • kleine afdelingen met drie of minder versnellers; • middelgrootte afdelingen met vier tot zes versnellers; • grote afdelingen met zeven of meer versnellers. Geen van de respondenten werkt op een kleine afdeling. Het merendeel valt in de categorie van middelgrootte afdelingen (n=6), drie afdelingen behoren tot de categorie groot. De verdeling tussen single (n=4) en multi vendor afdelingen (n=5) is nagenoeg gelijk. Drie van de afdelingen kennen meerdere locaties (Tabel 4.4).

1

Het aspect van incidenten ten gevolge van interoperabiliteitsproblemen is in de Nederlandse enquete niet aan bod gekomen. Dat is in de interviews aan bod gekomen.

Resultaten survey

pagina 45 van 131

Tabel 4.4 In bijgaande tabel is een overzicht van de buitenlandse afdelingen radiotherapie. De afdelingen zijn onderverdeeld op basis van het aantal versnellers en of zij single of multi-vendor zijn. Tussen haakjes is het aantal versnellers vermeld. Cursief zijn de afdelingen die meerdere locaties kennen, tussen haakjes staat dan zowel het aantal versnellers op de hoofdlocatie als de nevenlocatie(s) vermeld. Single-vendor

Groot

Middelgroot

WBRC Alfred Hospital (4+1)

UT MDACC (>16+7)

Medical University Vienna (5) Medical University Gräz (5) Multi-vendor

Lund, Skäne University Hospital (6) Providende, Rhode Island Hospitals (5) San Rafaelle Hospital (5)

Brussel, UZB (5+2) Barnes Jewish Hospital (8)

Twee afdelingen hebben nog de beschikking over een conventionele lokalisator en alle afdelingen beschikken over een CT-lokalisator. Daarnaast beschikken drie afdelingen nog over één of andere imaging modaliteiten (PET, MRI, PET/CT, SPEC/CT of echografie). Alle afdelingen geven aan ook nog imaging modaliteiten te delen met een beeldvormende afdeling. Van de negen radiotherapie afdelingen maakt, op één afdeling na, elke afdeling gebruik van treatment planningssystemen van meer dan één fabrikant. Evenals bij de Nederlandse afdelingen maakt geen van de buitenlandse afdelingen gebruik van commerciële software van één fabrikant. Iets meer dan driekwart van de afdelingen maakt gebruik van zelf ontwikkelde software. Als belangrijkste redenen voor het zelf ontwikkelen van applicaties worden gegeven: het ontbreken van de gewenste functionaliteit in commerciële software en de wens naar flexibiliteit. Bij de ontwikkelde applicaties gaat het dan om applicaties op het gebied van: • imaging; • matching; • workflow; • onafhankelijke dosisverificatie. Op de vragen welke datakoppelingen er zijn, binnen de afdeling, tussen de afdeling en de rest van het ziekenhuis, wordt in tegenstelling tot de antwoorden van de Nederlandse respondenten heel algemene antwoorden gegeven; er wordt niet concreet beschreven tussen welke systemen koppelingen bestaan. Binnen de afdeling gaat het veelal om DICOM(-RT)-koppelingen tussen de verschillende applicaties. Tussen de afdeling en het ziekenhuis gaat het veelal om een DICOM-koppeling naar een centrale ziekenhuis PACS en HL7-koppeling tussen de workflow-applicatie van de afdeling naar het ZIS. Drie ziekenhuizen geven aan over extramurale koppelingen te beschikken. Het gaat hier dan om DICOM-koppelingen met andere ziekenhuizen en HL7-koppelingen voor laboratorium uitslagen, het aanmelden van patiënten en terugrapportage naar de verwijzend arts. Eén van de afdelingen geeft aan gebruik te maken van videoconferencing faciliteiten en een virtuele desktop omgeving voor het op afstand kunnen bediscussiëren van bestralingsplannen.

pagina 46 van 131

Resultaten survey

Afbeelding 4.2 Gerapporteerde interoperabiliteitsproblemen van de Nederlandse respondenten ingedeeld naar de plaats waar ze optreden: binnen de grenzen van de afdeling, tussen de afdeling en de rest van het ziekenhuis of tussen de afdeling en locaties buiten het ziekenhuis. Op de y-as de relatieve cummulatieve bijdrage. Tabel 4.5: Interoperabiliteitsproblemen ingedeeld naar categorie. In de kolommen zijn de problemen ingedeeld naar de plaats waar ze optreden: binnen de grenzen van de afdeling, tussen de afdeling en de rest van het ziekenhuis of tussen de locaties buiten het ziekenhuis. In de rijen zijn de problemen ingedeeld naar de oorzaak van de problemen. Binnen de afdeling



de rest van het ziekenhuis

extramurale instellingen

Totaal

DICOM

2

1

1

4

DICOM-RT

9

1

0

10

HL7

1

3

0

4

Overig

5

3

3

11

Totaal

17

8

4

29

4.2.3 Interoperabiliteitsproblemen Op één afdeling na geeft elke respondent aan één of meerdere interoperabiliteitsproblemen aan. In afbeelding 4.3 is de relatieve bijdrage van het type probleem op het totale aantal grafisch uitgezet, in en tabel 4.5 zijn de absolute aantallen gepresenteerd. Totaal zijn 29 interoperabiliteitsproblemen gerapporteerd. Evenals bij de Nederlandse afdeling is ongeveer de helft (14 van de 29) gerelateerd aan DICOM. Van deze 14 interoperabiliteitsproblemen zijn 10 problemen gerelateerd aan DICOM-objecten, het gaat hier dan om: • problemen in de gegevens overdracht van het TPS naar het verificatiesysteem; • problemen in de gegevens overdracht van het verificatiesysteem naar de imaging software; • andere interpretatie DICOM-tags; • problemen in de communicatie tussen het verificatie systeem en een bestralingsmodaliteit. Resultaten survey

pagina 47 van 131

Geen van de afdelingen rapporteert problemen ten aanzien van identificatie van de patiënt en de bij behorende medisch beeldvormend beelden. Naast de DICOM gerelateerde problemen worden enkele connectiviteitsproblemen en een HL7 gerelateerd probleem gerapporteerd. Op de vragen in hoeverre de problemen het gewenste proces beïnvloeden, wordt door de buitenlandse respondenten aangegeven dat de problemen met de grootste impact de problemen zijn tussen het planningssysteem en het verificatie systeem en tussen het verificatie systeem en de versnellers. Vier afdelingen geven aan interoperabiliteitsproblemen te ondervinden tussen de afdeling en de rest van het ziekenhuis. Drie problemen zijn HL7 gerelateerd en één probleem heeft betrekking op de koppeling tussen het treatment planningssysteem en het centrale ziekenhuis PACS. De HL7 gerelateerde problemen hebben betrekking op problemen ten aanzien van de radiotherapie werklijst, het radiotherapie elektronisch dossier en de koppeling tussen de workflow applicatie op de afdeling radiotherapie en het ziekenhuis informatie systeem. Met name de HL7 gerelateerde problemen worden gekwalificeerd als problemen met een grote impact en aangegeven wordt dat daar veel menselijke interactie nodig blijft om het probleem het hoofd te bieden. Vier afdelingen geven aan problemen te ondervinden met de uitwisseling van gegevens met andere zorginstellingen. Door één afdeling wordt aangegeven dat het elektronisch patiënten dossier van de ziekenhuizen waar frequent mee wordt samengewerkt wordt, niet toegankelijk is. Twee andere afdelingen geven aan dat door het strikte privacy- en veiligheidsbeleid de uitwisseling van gegevens bemoeilijkt wordt en soms in het geheel niet mogelijk is. Als voorbeelden wordt aangegeven dat de firewall van het ziekenhuis zo dicht getimmerd is dat medische gegevens van de patiënten die mee doen aan een trial niet naar het coördinerende instituut kunnen worden gestuurd en dat het elektronisch medisch (radiotherapie) dossier niet verstuurd kan worden naar een gelieerde radiotherapie afdeling. Om de firewall te omzeilen wordt dan gebruik gemaakt van een modem en een telefoonverbinding om de gegevens te versturen.

4.2.4 Incidenten ten gevolge van interoperabiliteitsproblemen In tegenstelling tot de Nederlandse vragenlijst is bij de vragenlijst voor buitenlandse radiotherapie afdelingen gevraagd of één van de gerapporteerde interoperabiliteitsproblemen in het verleden heeft geleid tot een incident. Met een incident wordt hiermee gedoeld op een kwaliteitsbreuk, een bijna fout of een fout in de behandeling van een patiënt. Door bijna de helft van de afdelingen wordt één of twee incidenten beschreven, met een totaal van zeven. Eén van de incidenten heeft geleid tot een kwaliteitsbreuk, de overige gerapporteerde incidenten hebben betrekking op een fout in de behandeling. Onvoldoende informatie van de incidenten is gegeven om te kunnen achterhalen in hoeverre de incidenten de kwaliteit van de behandeling heeft beïnvloed. De kwaliteitsbreuk had betrekking op het ontbreken van cruciale informatie op het gewenste moment, dit had tot gevolg dat de bestraling uitgesteld moest worden. De incidenten met een fout in de behandeling waren het gevolg van: het verlies van informatie in het verificatiesysteem, het niet volledig oversturen van de benodigde informatie van het TPS naar verificatiesysteem en een fout in de transfer van de coördinaten van het isocentrum.

pagina 48 van 131

Resultaten survey

4.2.5 Strategieën Op de vraag hoe afdelingen interoperabiliteitsproblemen proberen te voorkomen, wordt zeer divers gereageerd. Drie afdelingen geven aan dat ze de problemen oplossen als ze optreden. Drie afdelingen geven aan dat hun strategie is het maken van goede afspraken met de fabrikant bij aanschaf of dat de problemen terug gelegd worden bij de fabrikant als ze optreden. Twee afdelingen geven aan geen strategie te hebben. Eén afdeling geeft aan een one vendor strategie te hanteren en tot slot geeft één afdeling aan dat haar strategie de betrokkenheid bij IHE activiteiten is.

4.2.6 Bekendheid met de IHE Op één respondent na geven alle respondenten aan bekend te zijn met het werk van de IHE (Tabel 4.6). Drie van de respondenten geven aan dat zij zelf of anderen op de afdeling betrokken zijn bij de IHE. Daarnaast geven zes respondenten aan dat één of meerdere concept integratieprofielen geïmplementeerd zijn op de afdeling. In tabel 4.6 is een overzicht te zien van welke profielen zijn ingevoerd. Van de vier afdelingen die aan geeft “Radiotherapie Treatment Workflow” te hebben geïmplementeerd, is één afdeling op het moment bezig met implementatie. Tabel 4.5: Interoperabiliteitsproblemen ingedeeld naar categorie. In de kolommen zijn de problemen ingedeeld naar de plaats waar ze optreden: binnen de grenzen van de afdeling, tussen de afdeling en de rest van het ziekenhuis of tussen de locaties buiten het ziekenhuis. In de rijen zijn de problemen ingedeeld naar de oorzaak van de problemen. Geïmplementeerde integratieprofielen

bekend met IHE

betrokken bij IHE

Instituut 1

ja

ja

x

Instituut 2

ja

ja

x

Instituut 3

ja

ja

Instituut 4

ja

nee

Instituut 5

ja

nee

Instituut 6

ja

nee

Instituut 7

ja

nee

Instituut 8

ja

nee

Instituut 9

nee

nee

MR- RO

WF-RO

x

x

x x

x

x x

Totaal

Resultaten survey

NTPS

3

3

3

pagina 49 van 131

4.3 Resultaten interviews Na het analyseren van de gegevens van de survey zijn vijf afdelingen geselecteerd voor het houden van interviews. Uiteindelijk was het bij één afdeling logistiek niet mogelijk om een afspraak voor een interview binnen de looptijd van het onderzoek te plannen. In de interviews is ingegaan op vijf hoofdonderwerpen. Allereerst wordt ingegaan op het werken op twee locaties. Ten tweede wordt ingegaan op de interoperabiliteitsproblemen die de afdelingen ervaren. Als derde onderwerp wordt ingegaan op eventuele incidenten die zijn opgetreden ten gevolge van interoperabiliteitsproblemen. Vervolgens wordt ingegaan op de strategieën die de afdelingen hanteren bij het voorkomen en oplossen van interoperabiliteitsproblemen. Tot slot wordt ingegaan op het beeld van de respondenten over de IHE en haar manier van werken.

4.3.1 Werken op meerdere locaties Drie van de bezochte afdelingen werken op twee of drie locaties, de andere afdeling heeft concrete plannen ten aanzien van het werken op een satellietlocatie. Op twee van de drie afdelingen die op twee of meer locaties werken, wordt het voorbereidingstraject van de behandeling (lokalisatie en planning) uitgevoerd op de hoofdlocatie. Op één afdeling wordt de lokalisatie-CT op de satellietlocatie gemaakt en wordt het plan vervaardigd op de hoofdlocatie. Voor alle afdelingen is het mogelijk om op de satellietlocatie bestralingsplannen in te zien. Op de drie afdelingen die op meerdere locaties werken zijn dagelijks één of meer artsen aanwezig op de satellietlocatie(s). De werkzaamheden van artsen omvatten: intake en follow up van patiënten op een radiotherapie polikliniek, controle afspraken van patiënten die op de satelliet locatie behandeld worden. Indien nodig kan de radiotherapeut geconsulteerd worden bij het uitvoeren van de radiotherapie behandeling op de locatie. Eén afdeling geeft aan dat op de satellietlocatie ook een klinisch fysicus aanwezig is, bij de andere twee afdelingen is op de satellietlocatie de klinisch fysicus alleen op afstand te consulteren. Bij problemen tijdens de bestraling is het voor de afdeling waarbij geen klinisch fysicus op de nevenlocatie aanwezig is mogelijk via een remote desktop verbinding mee te kijken op de console van de versneller en mee te kijken in de IGRT-applicatie(s). Eén afdeling heeft ten behoeve van deze functionaliteit een versnellercockpit ingericht waarbij op de verschillende beeldschermen van de versneller meegekeken kan worden. Eventueel kan de bediening het treatment werkstation van de versneller en de imaging console worden over genomen. Om ervoor te zorgen dat de remote desktop software de processen op de versneller niet kan beïnvloeden, wordt het VGA-signaal extern afgevangen en wordt voor het toetsenbord en de muis gebruik gemaakt van een KVM-hardware switch (KVM = Keyboard Video Mouse). Het VGA-signaal en alle I/O-signalen worden aangeboden aan een VNC-server (VNC staat voor Virtual Networking Computing) die op een aparte computer draait. De VNC-server is beveiligd met een wachtwoord en de verbinding met de hoofdlocatie is versleuteld. Zoals gezegd heeft dit als voordeel dat de remote desktop software en de andere applicaties elkaar niet kunnen beïnvloeden. Zodoende blijft het remote kanaal werken als de computers vastlopen en worden de klinische computers niet belast met VNC-taken.

pagina 50 van 131

Resultaten survey

Ten behoeve van patiëntbesprekingen en andere vergaderingen zijn op alle afdelingen videoconferencing faciliteiten beschikbaar. Eén afdeling gaf aan dat, met name vlak na implementatie van de faciliteiten, de verbinding nogal eens wegviel. Aangegeven werd dat dit tamelijk hinderlijk was en dat daardoor een goed overleg eigenlijk niet meer mogelijk was. Het opnieuw opstarten van het systeem kostte ongeveer een kwartier. Alle afdelingen hebben gekozen om het netwerk op de satellietlocatie een uitstulping te laten zijn van het netwerk op de hoofdlocatie. Zodoende zijn op de satellietlocatie twee gescheiden netwerken: het radiotherapie netwerk dat een uitstulping is van de hoofdlocatie en het netwerk van het “gast” ziekenhuis. De verbinding tussen de hoofd en de nevenlocatie is altijd dubbel uitgevoerd. Eén afdeling geeft aan dat de verbinding eigendom is van het ziekenhuis, de andere twee ziekenhuizen hebben de verbinding ondergebracht bij een derde partij. De afdeling die bezig is met de plannen voor de satellietlocatie heeft aangegeven de twee verbindingen onder te willen brengen bij twee verschillende partijen die grafisch gezien ook de locaties op twee aparte punten het ziekenhuis in- en uitgaan, om zo de kans op het verlies van verbinding zo klein mogelijk te laten zijn. Mocht om wat voor reden dan ook de verbinding tussen de hoofdlocatie en de nevenlocatie wegvallen dan accepteren twee afdelingen dat het werkproces tijdelijk onderbroken is en dat bestralen niet mogelijk is. Eén afdeling heeft een noodprocedure beschreven en maatregelen genomen om toch in geval van een calamiteit door te kunnen werken op de satellietlocatie. De back-up van het verificatiesysteem (gelokaliseerd op de nevenlocatie) wordt op dat moment productie server, zodat toch verder gewerkt kan worden. Dit betekent wel dat indien dat de verbinding hersteld is, de twee databases van het verificatiesysteem gesynchroniseerd moeten worden. Om positioneringshulpmiddelen en gegevens op papier te vervoeren, rijdt, bij alle afdelingen die op meerder locaties werken, een bode één of meerdere keren per dag tussen de locaties heen en weer. Twee van de drie afdelingen werkt digitaal en de derde afdeling heeft plannen om een elektronisch medisch radiotherapie dossier op te zetten. Op die laatste afdeling is zojuist een voorstudie naar een elektronisch medisch radiotherapie dossier afgerond.

4.3.2 Interoperabiliteitsproblemen De gerapporteerde interoperabiliteitsproblemen uit de enquête zijn meer in detail besproken tijdens de interviews. Alle bezochte afdelingen geven één of meer DICOM-RT gerelateerde problemen aan. Bijna alle problemen lijken veroorzaakt te worden door het verschillend interpretatie van de DICOMstandaard of extra eisen die door één van de applicaties aan een DICOM-RT object wordt gesteld. De koppeling tussen het TPS en het verificatiesysteem heeft bij drie afdelingen in het verleden tot problemen geleid, één afdeling gaf aan problemen te hebben ondervonden in de koppeling tussen het verificatiesysteem en enkele versnellers. De afdelingen hebben zelf, dan wel samen met de fabrikant, hier een oplossingen voor ontwikkeld.

Resultaten survey

pagina 51 van 131

Voor twee afdelingen is het niet mogelijk om DRR’s vanuit het TPS naar het verificatiesysteem te zenden. Beide afdelingen hebben hier zelf een applicatie voor ontwikkeld. Twee afdelingen geven aan dat eenmaal geëxporteerde plannen in het DICOM-RT formaat niet meer in het TPS geïmporteerd kunnen worden. De twee andere twee afdelingen vonden de export archiveringsfunctionaliteit in het TPS onvoldoende en hebben een applicatie ontwikkeld om dit geautomatiseerd te laten verlopen. Eén van de afdelingen zou graag het PACS gebruiken als centrale opslag voor DICOM-RT objecten, dit is echter niet mogelijk. Voor twee andere afdelingen is het wel mogelijk om DICOM-RT objecten centraal in het PACS op te slaan. Samenvattend kan gesteld worden dat de import van DICOM-objecten over het algemeen goed verloopt, maar dat de problemen zich concentreren aan de export kant van het treatment planningssysteem. Een meer technisch interoperabiliteitsprobleem wordt door één van de afdeling aangegeven. Vanwege de grote doorvoersnelheid bij het maken van 4D-CT’s ervoer de afdeling performance problemen. De problemen traden op doordat het PACS te zwaar belast werd bij het opslaan van de 4D-CTs, in enkele secondes kreeg het PACS circa duizend CT-beelden te verwerken. Als het PACS tegelijkertijd CT’s moest aanbieden aan een andere client dan leidde dit geregeld tot een time-out. Dit is opgelost door enerzijds enkele componenten in het netwerk te vervangen en anderzijds door het PACS te splitsen over verschillende servers; aan de buitenkant lijkt het of er één PACS is, echter één server behandelt alle ‘STORAGE’-opdrachten en de andere server behandelt alle ‘QUERY & RETRIEVE’opdrachten.

4.3.3 Incidenten ten gevolge van interoperabiliteitsproblemen Zoals eerder aangegeven, is met de Nederlandse vragenlijst niet in kaart gebracht of interoperabiliteitsproblemen in het verleden hebben geleid tot incidenten. In de interviews is dat alsnog mee genomen. Alle geïnterviewden geven aan dat interoperabiliteitsproblemen waarschijnlijk in het verleden hebben geleid tot incidenten. Op twee van de vier afdelingen zijn ook concreet voorbeelden beschreven.

4.3.4 Strategieën Twee afdelingen geven aan zo veel mogelijk een single vendor strategie na te streven en zo het aantal interoperabiliteitsproblemen te beperken. Eén van die twee afdelingen geeft aan dat hierin wel een gevaar schuilt omdat dit (mogelijk) een ongewenste afhankelijkheid creëert. Eén van de anderen respondenten onderschreef dit en gaf aan juiste lange tijd om die reden bewust een multi vendor afdeling te zijn geweest. Alle respondenten geven aan dat veel inspanning wordt geleverd in het oplossen van interoperabiliteitsproblemen en dat men liever zou willen dat voor deze problemen oplossingen worden gecreëerd door de fabrikant. Men geeft aan dat de fabrikant veel beter de expertise hiervoor bezit en de mogelijkheid om eventueel ontwikkelde oplossingen te testen dan een afdeling. Op drie afdelingen wordt verder aangegeven dat problemen bij de fabrikant worden aangegeven met de vraag om een oplossing te creëren. Hier wordt dan, zo wordt gesteld, onvoldoende op gereageerd. Aangegeven wordt dat de fabrikant een andere prioriteitstelling heeft dan dat de gebruikers. Verder wordt aangegeven dat een pagina 52 van 131

Resultaten survey

aantal fabrikanten heel erg gericht is op de Amerikaanse markt en dat gebruikers in Nederland nage noeg geen invloed kunnen uitoefenen. De manier van werken is dan soms anders en de applicatie heeft vaak niet die flexibiliteit dat hij ook zo geconfigureerd zou kunnen worden dat hij aan zou sluiten bij een andere werkvolgorde. Eén van de respondenten geeft aan dat zijn afdeling een lange termijn visie heeft in het oplossen van interoperabiliteitsproblemen en dat zij zelf applicaties ontwikkelt om grip te hebben op de gehele informatiestroom op de afdeling. Drie van de bezochte afdelingen geeft aan aansluiting te zoeken bij regionale initiatieven voor het uitwisselen van informatie tussen de afdeling en andere zorginstellingen

4.3.5 Beeld van de IHE Voor alle geïnterviewde respondenten geldt dat ze bekend zijn met de IHE als organisatie, maar dat het beeld van het doel en de werkwijze beperkt is. Bij twee respondenten kwamen misconcepties aan het licht. Eén van de respondenten gaf aan dat de IHE zich met name richt op het standaardiseren van de uitwisseling van gegevens tussen instelling en op één van de ander afdelingen bestond de indruk dat de IHE een platform was om als gebruikers samen naar de fabrikanten sterker te staan in het eisen van aanpassingen. Eén van de respondenten geeft aan dat zijn afdeling mogelijk geïnteresseerd zou zijn om actief betrokken te zijn bij de activiteiten van de IHE.

Resultaten survey

pagina 53 van 131

pagina 54 van 131

Resultaten survey

5 Resultaten case study Om op de onderzoeksvragen die gericht zijn op de situatie in het VUmc antwoord te kunnen geven, is een case study verricht. Op basis van gesprekken en documenten zijn modellen vervaardigd van de bedrijfsprocessen en de informatiestromen. De bedrijfsprocessen zijn gemodelleerd met de model leertaal UML. Als diagramtechniek is hierbij gekozen voor het activiteitsdiagram. Dit type diagram geeft inzicht in de deelactiviteiten die worden uitgevoerd en door wie de deelactiviteiten worden uitgevoerd. De resultaten hiervan worden gepresenteerd in paragraaf 5.1. Gekozen is om de modellen in delen op te knippen en naast de deelmodellen een tekstuele beschrijving van het werkproces te presenteren. De activiteitsdiagrammen in zijn geheel zijn opgenomen in de bijlage 4 en 5. Het eerste deel van paragraaf 5.1. betreft een actuele beschrijving van het werkproces. In de laatste paragraaf wordt aangegeven welke aspecten van het werkproces veranderen door het werken op meerdere locaties. Vervolgens zijn de verkregen inzichten gebruikt om de functionele laag uit het 3LGM2-model te modelleren. Op basis van verdere gesprekken zijn daarna de applicatie- en de fysieke laag gemodelleerd. De resultaten daarvan worden gepresenteerd in paragraaf 5.2 Tot slot zijn de interoperabiliteitsproblemen die afdeling radiotherapie van het VUmc ondervindt nader geanalyseerd en vergeleken met de ontwikkelde en nog te ontwikkelen integratieprofielen van de IHE. De resultaten worden gepresenteerd in paragraaf 5.3.

5.1 Model bedrijfsprocessen In de eerste verkennende gesprekken bleek dat eerder het werkproces in kaart was gebracht. Deze modellen waren klassieke stroomdiagrammen1. Tevens bleek dat de diagrammen niet meer actueel waren. Op basis van de oude modellen en verschillende gesprekken zijn in een iteratief proces activiteitsdiagrammen vervaardigd van de “voorbereiding” en de “uitvoering”. Met de voorbereiding worden de activiteiten bedoeld tussen aanmelding en de eerste bestraling. Met de uitvoering worden de activiteiten vanaf de eerste bestraling tot aan de laatste bestraling beschreven. Het modelleren is een iteratief proces geweest waarbij in elke volgende iteratie is gekomen tot een meer juiste en gedetailleerde weergave van het proces.

5.1.1 Voorbereiding: intake & lokalisatie In verticale swimlanes (dit zijn zoals in paragraaf 2.2.3 is uitgelegd de verticale kolommen waarin de verschillende actoren zijn gepositioneerd) worden de verschillende professionals betrokken bij het proces weergegeven. In de “Voorbereiding” zijn dat: de administratie, de datamanager, de radiotherapeut oncoloog, de Medisch Beeldvormings- en Bestralingsdeskundige (MBB)2 en de klinisch fysicus. “Administratie en logistiek” is in werkelijkheid opgedeeld in twee delen, een logistiek plan bureau (LPB) en de administratie. Vanwege de leesbaarheid is dit als één functionele eenheid beschouwd (Afbeelding 5.1). Zodra een afspraak voor radiotherapeutische behandeling via het LPB binnen komt wordt een afspraak 1

De oorsprong van klassieke stroomdiagrammen loopt terug tot het begin van de vorige eeuw, waar de basis gelegd door medisch ingenieurs. Hun populariteit ligt in het uitgebreide gebruik bij het beschrijven van computer algoritmes.

2

MBB is sinds 2008 de beroepstitel voor radiotherapeutisch en radiodiagnostich laboranten en staat voor Medisch Beeldvormings- en Bestralingsdeskundige.

Resultaten casestudyey

pagina 55 van 131

gemaakt voor de lokalisatie en wordt de patiënt voor een intake ingepland bij één van de radiotherapeuten. Deze zal een beslissing nemen of al dan niet radiotherapeutisch behandeld gaat worden. Als besloten wordt om niet radiotherapeutisch te behandelen, zal het logistiek planbureau daarvan op de hoogte worden gesteld zodat al gemaakte vervolgafspraken afgezegd kunnen worden en zal de administratieve afhandeling in gang worden gezet bij de datamanager en zal door de administratie een brief verstuurd worden naar de aanvragend arts. Indien wel tot behandeling besloten wordt, zal indien nodig aanvullend onderzoek, zoals een PET- of MRI-onderzoek worden aangevraagd en zal de patiënt op dezelfde dag komen voor een CT-lokalisatie. Eventueel worden afspraken met andere disciplines zoals de diëtist en de mondhygiënist gemaakt. Indien nodig zal voor de CT-lokalisatie een masker worden vervaardigd. Voor een beperkt aantal patiënten is de CT-lokalisatie niet geïndiceerd en zal de bestraling handmatig door een MBB worden aangemaakt in het verificatie systeem.

Afbeelding 5.1: Detail van de modellering van de voorbereiding volgens de UML-activiteitsdiagram techniek. In dit detail zijn niet alle disciplines zichtbaar, de klinisch fysicus heeft in deze fase van het proces geen rol en is zodoende weggelaten, daarnaast is “administratie en logistiek” in de werkelijkheid opgedeeld in twee delen, een logistiek planbureau (LPB) en de administratie. Vanwege de leesbaarheid is dit als één functionele eenheid beschouwd.

5.1.2 Voorbereiding: Planning In afbeelding 5.2 is het vervolg van het proces gemodelleerd. Nadat de CT-lokalisatie en aanvullend onderzoek is verricht, kunnen de benodigde datasets worden ingelezen in het treatment plannings systeem. De datasets worden gematched en begonnen kan worden met het intekenen. Of de arts of de MBB de match uitvoert is afhankelijk van de persoonlijke ervaring, hierin is geen eenduidige regel. Opgemerkt dient te worden dat de MBB wel deskundig genoeg dient te zijn om de match uit te voeren. Het intekenen van de doelgebieden wordt uitgevoerd door de radiotherapeut. De MBB tekent de Organs At Risk (OARs) in. Het kan zijn dat een deel door de radiotherapeut wordt ingetekend. Na het intekenen vult de radiotherapeut in ARIA het “physician’s intent” in en vult hij een logistiek planbureau formulier in. Het “physician’s intent” is het bestralingsvoorschrift van de radiotherapeut, hierin geeft hij de locatie van de tumor aan, de fractiedosis en het aantal te geven fracties, de stralingssoort en de energie, de normering en tot slot de gewenste bestralingstechniek. Op het LPB formulier (papier) geeft de radiotherapeut de opdracht tot het maken van bestralingsafspraken. Hij geeft aan: het aantal fracties en de soort behandeling, op welk bestralingstoestel de behandeling moet plaats vinden en het gewenste IGRT-protocol. Daarnaast wordt op het formulier diagnose informatie voor de datamanager vastgelegd. Het formulier gaat naar het logistiek planbureau en hier worden de bestralingsafspraken pagina 56 van 131


voor de patiënt in ARIA aangemaakt. Het formulier wordt vervolgens doorgegeven naar de datamanager die in ARIA de courses en de diagnose vast legt. Nadat alle benodigde structuren zijn ingetekend kan begonnen worden met het vervaardigen van het bestralingsplan. Het kan zijn dat tijdens het vervaardigen van het plan de klinisch fysicus of de radiotherapeut wordt geconsulteerd ten aanzien van te maken keuzes. Nadat het plan klaar is kan worden verder gegaan met alle controles.

Afbeelding 5.2: De modellering van het intekenen en het vervaardigen van het plan. Dit detail sluit aan op de onderkant van afbeelding 5.1.

5.1.3 Voorbereiding: Controles bestralingsplan Nadat het plan vervaardigd is, zal de radiotherapeut het plan evalueren op de medische aspecten en zal indien mogelijk zijn akkoord geven (Afbeelding 5.3). Vervolgens wordt het plan in multidisciplinair verband besproken op de dagelijkse patiëntenbespreking. Indien nodig kan deze stap later worden uitgevoerd, bij voorkeur echter voor het geven van de eerste bestralingsfractie. Voor IMRT en Rapid¬Arc bestralingen wordt daarna het plan door een klinisch fysicus gecontroleerd op fysische en dosimetrische aspecten en geaccordeerd. Dit kan ook op aanvraag plaats vinden bij complexe 3D-conformatie bestralingsplannen. Bij RapidArc bestralingen wordt door de klinisch fysicus opdracht gegeven tot dosimetrie. Deze wordt uitgevoerd door de klinisch fysisch medewerker. De uitvoering van de dosimetrie en de daaropvolgende evaluatie door een klinisch fysicus dient uitgevoerd te worden voor de vierde bestralingsfractie (bij hypogefractioneerde behandeling gelden andere richtlijnen). Na het akkoord van de klinisch fysicus wordt het plan gecontroleerd op uitvoerbaarheid en enkele praktische aspecten door een andere MBB. Deze MBB bereid ook de IGRT in het verificatiesysteem voor. Tot slot geeft de radiotherapeut een “plan approval” in het treatment planningssysteem af. Hiermee worden alle planning gerelateerde gegevens vastgezet zodat deze niet meer gewijzigd kunnen worden. Als ergens in dit chronologische proces blijkt dat een aanpassing van het bestralingsplan nodig is, zal terug gegaan worden in het proces.


pagina 57 van 131

Afbeelding 5.3: De modellering van het vervaardigen van het plan en de daarop volgende controles. Dit detail sluit aan op de onderkant van afbeelding 5.2.

Nadat alle controles zijn doorlopen worden de bestralingsgegevens in het verificatiesysteem gecontroleerd en door een MBB geautoriseerd met een zo genaamde ‘treatment approval’. Op basis van de gegevens van het verificatiesysteem wordt dan de digitale stralenkaart samengesteld. De digitale stralenkaart is een door de afdeling zelf ontwikkelde applicatie die, uit de database van het verificatiesysteem, gegevens extraheert en dat op een overzichtelijke wijze presenteert. De digitale stralenkaart is dus een momentane weergave van de patiënt gebonden gegevens in de database. In de digitale stralenkaart kunnen geen wijzigingen zelf worden aangebracht. Na de treatment approval wordt een export uitgevoerd uit het treatment planningssysteem van het enkele DICOM-RT objecten (RT-plan en MLC-settings) naar een netwerkschijf. Vervolgens zorgt een script ervoor dat deze gegevens gekopieerd worden naar elk bestralingstoestel. Dit wordt gedaan om in geval van een storing, in het verificatie systeem of het netwerk, toch een bestraling uit te kunnen voeren buiten het verificatiesysteem om. De digitale stralenkaart wordt op het moment niet geëxporteerd en is zodoende niet beschikbaar bij netwerkproblemen of bij het niet beschikbaar zijn van de ARIA-database.

5.1.4 Bestraling: positionering De patiënt meldt zich digitaal aan door middel van het scannen van een barcode op zijn afsprakenkaart met de bestralingsafspraken van die week (Afbeelding 5.4). Dit zorgt er voor dat de in werklijst de bestraling voor die dag wordt vrijgegeven (mocht de patiënt zijn barcode niet mee hebben, dan kan de blokkering handmatig worden opgeheven). Voordat de patiënt wordt gehaald uit de wachtkamer, vindt een controle op het bestralingstoestel of alle benodigde gegevens en hulpmiddelen aanwezig zijn. De patiënt wordt geïdentificeerd op basis van zijn foto in de digitale stralenkaart en zijn geboortedatum. Deze foto is ook zichtbaar in de console in de bedieningsruimte.

pagina 58 van 131


De MBB die de bestraling uitvoeren in de bunker, leggen de hulpmiddelen klaar en positioneren de patiënt. De MBB in de bedieningsruimte roept de bestralingsgegevens op in het verificatiesysteem en opent de digitale stralenkaart. Nadat de patiënt gepositioneerd is, wordt achtereenvolgens een eventuele á priori verschuiving uitgevoerd, vindt controle van de bestralingsparameters plaats en vindt bij de eerste fractie een controle plaats op eventueel botsingsgevaar. Dit laatste is nodig om het vanuit de bedieningsruimte draaien van het bestralingstoestel mogelijk te maken en bij rotatiebestralingen, zoals RapidArc, is deze stap nodig om zeker te zijn dat een boog in één sessie gegeven kan worden.

Afbeelding 5.4: Een detail van het activiteitsdiagram van de start van de bestraling. Het proces start bij de zwarte stip boven aan, met als eerste activiteit “de controle of gestart kan worden de bestraling”. Omdat alleen de MBB betrokken is in dit proces maar één kolom (=swimlane in UML-terminologie) aanwezig.

5.1.5 Bestraling: beeldvorming en uitvoering Na de eventuele controle op mogelijk botsingsgevaar wordt gestart met de pre-treatment imaging (Cone Beam CT, kV-images of portal images (=MV images)). Welk protocol van toepassing is, heeft de radiotherapeut aangegeven op het physician’s intent en is geregistreerd in het verificatiesysteem. Hoe het proces verloopt is afhankelijk van het protocol dat van toepassing is (Afbeelding 5.5). Bij een online protocol wordt direct na de acquisitie de match uitgevoerd en een verschuiving bepaald. Indien de match daartoe aanleiding geeft, kan besloten worden of consultatie van de radiotherapeut of van een klinisch fysicus vereist is. Na het uitvoeren van de verschuiving wordt een tweede opname vervaardigd om de verschuiving te controleren. Bij een off-line protocol vind de match, het bepalen van de verschuiving en de daarop volgende controle door een tweede MBB plaats na de bestraling en voor de daaropvolgende fractie. Bij CBCT’s of als de patiënt een kind betreft, dient de tweede match uitgevoerd te worden door een radiotherapeut. Op basis van een beslisregel wordt bepaald of een verschuiving bij de volgende fractie noodzakelijk is. De activiteiten van het off-line protocol zijn in afbeelding 5.5 opgenomen in de “control flow” omhoog. Resultaten casestudyey

pagina 59 van 131

Nadat het imaging protocol is doorlopen, kan begonnen worden met de bestraling. Afhankelijk van het imaging protocol wordt dit in eerste of vierde fractie voorafgegaan door het overnemen van de tafelpositie in het verificatiesysteem. Nadat de bestraling is uitgevoerd, wordt de imaging geregistreerd op het white board (handmatig) en in de digitale stralenkaart (automatisch na afronden bestraling). De reden voor de registratie op het white board is dat de matching van de images tussen de fracties gecontroleerd moet worden door een tweede laborant. Vervolgens kan de bestraling worden afgerond door het plaatsen van een digitale handtekening door degene die achter de bedieningsconsole zit. Deze noteert ook in het verificatiesysteem de initialen van de MBB die de patiënt hebben gepositioneerd. Na het afsluiten van de patiëntgegevens in het verificatiesysteem, worden deze gegevens in de database opgeslagen. Als daarna (bv. de volgende dag) de digitale stralenkaart opnieuw wordt geopend, worden de gegevens opnieuw uit de database ingelezen en is de gegeven fractie ook in de digitale stralenkaart verwerkt. Overdracht van bijzonderheden over een bestraling kunnen zoals eerder beschreven niet direct in de digitale stralenkaart aangebracht worden omdat deze applicatie alleen uit de ARIA-database kan lezen en niet kan schrijven. Via twee applicaties worden opmerkingen in de database geplaatst. Opmerkingen ten aanzien van de

Afbeelding 5.5: Een detail van het activiteitsdiagram van het werkproces op het bestralingstoestel vanaf de pré-treatment imaging tot aan het einde van de bestraling. Het proces loopt van boven naar beneden, echter omdat het hier een cyclisch proces is, gaat ook een “control flow” terug voor de volgende fractie. Bij een off-line imaging protocol moet tussen de fracties de match en de controle daarvan worden uitgevoerd.Dit detal sluit aan op de onderkant van afbeelding 5.4. pagina 60 van 131


imaging worden via “Off-line review” in de database geschreven. Fractie gebonden opmerkingen worden met de “RT-Chart” applicatie in de database geschreven. Op het moment dat de digitale stralenkaart opnieuw wordt geopend en zijn gegevens opnieuw leest uit de database, zal deze de ingevoerde opmerkingen presenteren. Na de laatste fractie wordt op het toestel gecontroleerd of de dosisgegevens kloppen in het verificatiesysteem. In de status wordt de datum van de laatste fractie ingevuld en worden de eerder opgeslagen DICOM-objecten uit de back-up folder verwijderd.

5.1.6 Gevolgen van het werken op twee locaties Als de satellietlocatie in Hoorn wordt geopend, worden daar de volgende werkzaamheden uitgevoerd: 1. Uitvoeren van de bestraling, • Wekelijkse controle van de patiënt door de radiotherapeut • Follow-up van de patiënten Het voorbereidingsproces zal deels in Hoorn en deels in Amsterdam plaats vinden. Zeker is dat het vervaardigen van de planning in Amsterdam plaats vindt. De intake, de CT-lokalisatie, de eventuele lokalisatie en het intekenen vinden waarschijnlijk op de satellietlocatie plaats. Deze tweedeling van het voorbereidingsproces zorgt er voor dat de patiënt in principe geen enkele keer naar het VUmc hoeft te reizen (Afbeelding 5.6). Een belangrijk punt van aandacht is dat de communicatie die nu nog een deel op papier plaats vindt. In paragraaf 5.2.2 wordt een overzicht gegeven van de controlelijsten, de communicatieformulieren en de radiotherapie status. Een digitale vorm van de controlelijsten en de communicatieformulieren zou zonder al te veel problemen mogelijk moeten zijn. Een laagdrempelige mogelijkheid is dat de formulieren op papier gebruikt worden, maar na gebruik ingescand worden. Het digitaal maken van de

Afbeelding 5.6: Overzicht van de gevolgen van het splitsen van het voorbereidingsproces in een deel dat op de satellietlocatie (rood) plaats vindt en een deel dat in het VUmc (blauw) plaats vindt. Aanvullend onderzoek is groen gekleurd omdat dit een punt van aandacht is, waar het kan plaats vinden is afhankelijk van de mogelijkheid om gegevens van die locatie te benaderen vanaf het VUmc netwerk.


pagina 61 van 131

radiotherapie status is een grotere opgaaf en valt buiten de context van deze studie. Daarnaast moet nagedacht worden over de uitvoering van aanvullend onderzoek, zoals een MRI-onderzoek. Op de satellietlocatie zelf is geen MRI aanwezig, echter wel in het Westfries Gasthuis. Als deze gegevens gebruikt moeten worden voor het intekenen van structuren, dan dient gegevensuitwisseling tussen het VUmc netwerk en het netwerk van het Westfries Gasthuis mogelijk te zijn. Nadat het eerste deel van het voorbereidingstraject is afgerond, wordt het plan vervaardigd op de hoofdlocatie in Amsterdam. Daarna vinden alle controles plaats en wordt het plan besproken op de ochtendbespreking. Om het mogelijk te maken dat alle artsen aan de ochtendbespreking deel nemen zal op de satellietlocatie een videoconferencing zaal moeten worden ingericht. Nu maakt de afdeling radiotherapie gebruik van videoconferencing faciliteiten elders in het gebouw. De uitvoering van de bestralingen vindt in zijn geheel op de satellietlocatie plaats. In het huidige werkproces komt het geregeld voor dat de radiotherapeut of de klinisch fysicus voor consultatie op de versneller worden geraadpleegd (Afbeelding 5.7). Op de satellietlocatie zal elke dag een arts aanwezig zijn, een klinisch fysicus zal waarschijnlijk niet regulier aanwezig zijn. Consultatie van de klinisch fysicus zal zodoende vanaf afstand moeten plaats vinden, maar ook voor consultatie van de arts kan het zijn dat consultatie vanaf afstand moeten plaats vinden. Zo zou het kunnen zijn dat de behandelend radiotherapeut op die dag niet op de satellietlocatie aanwezig is. De afdeling radiotherapie is van plan voor deze consultatiemogelijkheden een zogenaamde versnellercockpit in te richten, hierbij is het mogelijk om vanaf afstand op de computers in de versneller ruimte mee te kijken en eventueel de computers te bedienen.

Afbeelding 5.7: Een deel van het model van de uitvoering van de bestraling. Alle rood gekleurde onderdelen vinden plaats op de satellietlocatie in Hoorn. Een eventuele consultatie van de klinisch fysicus vindt plaats vanuit Amsterdam, de consultatie van de arts kan lokaal plaats vinden, maar tevens van afstand en is zodoende groen gekleurd.

pagina 62 van 131


5.2 Het Three-layer Graph-based Model Het 3LGM2-model bestaat uit drie lagen: een functionele laag, een applicatielaag en een fysieke laag. In deze lagen worden respectievelijk de functies van de organisatie, de hierbij gebruikte applicaties en de hardwarecomponenten die door deze applicaties gebruikt wordt.

5.2.1 De domeinlaag In de domeinlaag worden de functies en de entiteiten van de afdeling radiotherapie grafisch weergegeven (Afbeelding 5.8) De functies die de afdeling radiotherapie vervult, vallen uiteen in: • Patiëntenzorg ◊ Voorbereiding, dit loopt van de aanmelding van de patiënt tot aan de eerste bestraling ◊ Behandeling, dit loopt van de eerste bestraling tot en met de laatste bestraling ◊ Follow-up, de nazorg van de patiënt na het afronden van de behandeling. • Facturatie, dit is het financieel administratieve proces • Onderzoek • Onderwijs en opleiden In respectievelijk tabel 5.1 en tabel 5.2 zijn de functies en de entiteiten van de afdeling uiteen gezet. De functies zijn een weerspiegeling van het in paragraaf 4.1 beschreven werkproces. De entiteiten zijn de gegevens die ontstaan en gebruikt worden tijdens het proces. In de domeinlaag zijn de functies “Onderzoek” en “Onderwijs en opleiden” niet in detail uitgewerkt. Dat wil niet zeggen dat die functies niet belangrijk zijn. Omdat deze studie zich echter richt op het voorkomen van interoperabiliteitsproblemen rond de patiëntenzorg, vallen deze buiten de context van dit onderzoek. Daarnaast speelt mee dat bij de functie “Onderwijs en opleiden” momenteel geen specifieke applicaties worden gebruikt. Tabel 5.1 In deze tabel is een overzicht van de functies van de afdelingen radiotherapie. In afbeelding 4.7 is hun onderlinge relatie en hun relatie met de entiteiten weergegeven. Functie

Omschrijving

Aanmelding patiënt

De patiënt wordt door een verwijzend arts aangemeld bij de afdeling radiotherapie

Controle positionering

De analyse van de in-room imaging data.

Controles bestralingsplan

Het vervaardigde bestralingsplan wordt door de verschillende betrokken professionals geëvalueerd en gecontroleerd.

DBC codering

Codering op basis van verrichtingen ten behoeve van het aanmaken van de factuur.

Dosimetrie bestralingsplan

Voor een aantal indicaties worden de bestralingsplannen dosimetrisch gecontroleerd.

Facturatie

Na overdracht van de verrichtingen naar het ZIS kunnen door het ZIS DBC-codes worden vastgesteld. Op basis van de DBC codes vindt vervolgens de facturatie plaats.

Follow-up

Nazorg van de patiënt na behandeling, screening op het optreden van complicaties en op de actuele status van het ziekteproces.

In room imaging

Ter controle van de positionering kan voor de bestraling een cone-beam CT, portal image of een kV-image vervaardigd worden

Inplannen patiënt

De lokalisatie en bestralingen worden ingepland.


pagina 63 van 131

Functie

Omschrijving

Intake patiënt

Na aanmelding van de patiënt heeft de een intake gesprek met een radiotherapeut.

Intekenen structuren

Op de vervaardigde lokalisatie CT worden de verschillende tumorvolumina en kritieke organen ingetekend.

Lokalisatie patiënt

Ten behoeve van het vervaardigen van een behandelplan wordt een lokalisatie CT bij de patiënt vervaardigd.

Moulage

Bij een aantal indicaties moeten individuele hulpmiddelen worden vervaardigd.

Ochtendbespreking

Alle vervaardigde plannen worden besproken op de ochtendbespreking.

Onderwijs en opleiden

Het VUmc is een opleidingsziekenhuis, zowel AGIO’s, CliFyO’s, als MBB worden op de afdeling radiotherapie opgeleid.

Onderzoek

Door de fysici, de radiotherapeuten en de MBB wordt onderzoek uitgevoerd.

Opstellen behandelplan

Op basis van behandelrichtlijnen, gegevens uit de intake en de klinische gegevens van de patiënt wordt een behandelplan opgesteld.

Rapportage verwijzend arts

Na de intake en na de afronding van de behandeling vind een rapportage naar de verwij-zend arts plaats.

Repositioneren patiënt

Voor elke fractie dient de patiënt gerepositioneerd te worden.

Uitvoeren bestraling

De bestraling van de patiënt.

Vervaardigen bestralingsplan

Het vervaardigen van een bestralingsplan op basis van de het opgestelde behandelplan.

Tabel 5.2 In bijgaande tabel is een alfabetisch gerangschikt overzicht van de entiteiten op de afdeling radiotherapie. In afbeelding 4.7 is hun onderlinge relatie en hun relatie met de functies weergegeven. Entiteit

Omschrijving

Afspraken patiënt

Dit zijn zowel de afspraken voor de lokalisatie als de afspraken voor de bestralingen.

Approval

De benodigde goedkeuring om het bestralingsplan te kunnen gebruiken.

Behandeloverzicht

Een samenvatting van alle gegevens van de radiotherapeutische behandeling

Behandelplan

Hierin legt de radiotherapeut vast hoe hij de patiënt wil behandelen.

Behandelrichtlijnen

De richtlijnen en de protocollen die gebruikt worden bij de patiëntenzorg.

Bestralingsplan

Alle benodigde gegevens benodigd voor de bestraling.

Data van beeldvormend onderzoek

Aanvullend beeldmateriaal van PET, MRI of diagnostische CT.

DBC-code

De code die in Nederland gebruikt wordt om elke medische behandeling te coderen.

Dosisvoorschrift

De te geven dosis en het fractioneringsschema.

Imaging data

De data die wordt gegenereerd bij de in-room imaging

Ingetekende dataset

De dataset met de ingetekende structuren

Klinische gegevens

De medische historie en de gegevens over de behandeling van de patiënt.

Lokalisatie gegevens

De CT-data en gegevens over de positionering van de patiënt tijdens de lokalisatie-CT.

Positioneringshulpmiddelen

Voor het positioneren van de patiënt individueel vervaardigd materiaal

pagina 64 van 131


Tabel 5.3 en Afbeelding 5.8 tonen beide de relatie tussen de entiteiten en de functies. In de afbeelding wordt de aard van relatie aangeduid door middel van de richting van de pijl, in de tabel wordt dit met een kleurcodering gedaan. Een pijl van een functie naar de entiteit duidt aan dat de functie gebruik maakt van de betreffende entiteit, in de tabel wordt dat aangeduid met de kleur blauw. Een pijl van de entiteit naar de functie duidt aan dat de functie de entiteit aanpast, in de tabel aangeduid met de kleur groen. Als de functie gebruik maat van de entiteit en hem aanpast dan is de pijl beide kanten op en dat wordt aangeduid met de kleur geel in de tabel. Zo is in de tabel en de figuur af te lezen dat de entiteit “DBC-code” aangepast wordt door de functie “DBC Codering” en maakt de facturatie gebruik van de entiteit “DBC-code” en wordt de entiteit “klinische gegevens” aangepast en gebruikt door de functie “Follow up”.

Afbeelding 5.8: Het model van de domeinlaag. De blauwe ovalen representeren de entiteiten, de rode rechthoklen de functies. De pijlen geven aan of door een functie gebruik wordt gemaat van de entiteit (pijl naar de entiteit toe), dat de entiteit aangepast wordt door de functie (pijl van de entiteit naar de functie) of dat de functie zowel gebruik van de entiteit maakt als hem aan past (pijl beide kanten op). In bijlage 6 is de figuur in het groot afgebeeld. In tabel 4.1 en 4.2 wordt een korte beschrijving gegeven van de functies en de entititeiten.


pagina 65 van 131

Tabel 5.3: Een overzicht van de applicaties (in de rijen) uitgezet tegen de functies die afdeling radiotherapie vervult (in de kolommen). De tabel laat zien welke applicaties voor welke functie gebruikt worden.

pagina 66 van 131


5.2.2 Applicatielaag In de tweede laag worden niet alleen de computerapplicaties beschreven, maar ook de gebruikte papieren componenten zoals een status of een brief. De papieren componenten zijn in de grafische weergave van de applicatie laag blauw gekleurd (Afbeelding 5.9). Een overzicht van de gebruikte papieren componenten: • Status radiotherapie ◊ Aanvraag radiotherapie, dit is het formulier dat gebruikt wordt om de patiënt aan te melden. ◊ Medische gegevens Anamnese gegevens, medische historie en uitslagen van bloedonderzoek, pathologisch anatomisch onderzoek e.d. ◊ Complicatie registratie formulier ◊ Toestemmingsformulier opvragen medische gegevens Dit formulier wordt gebruikt als communicatieformulier als tijdens de intake blijkt dat behandeling niet zinvol of wenselijk is. ◊ Formulier “Niet behandelen” Dit formulier wordt gebruikt als communicatieformulier als tijdens de intake blijkt dat behandeling niet zinvol of wenselijk is. • Uitdraai digitale stralenkaart van eerdere behandelingen Van elke afgeronde bestralingsserie wordt een uitdraai van de digitale stralenkaart in de status opgenomen. • Uitdraai van het bestralingsplan Nadat het plan definitief is, wordt een afgedrukt exemplaar opgenomen in de patiënten status. • Communicatieformulieren Deze lijsten worden gebruikt als overdrachtsformulier. Als de lijsten niet meer gebruikt worden, worden zij toegevoegd aan de status radiotherapie. ◊ Formulier Logistiek Plan Bureau (LPB-formulier) Dit is het formulier dat de arts invult tijdens de lokalisatie. Dit formulier komt nadat de datamanager het heeft gebruikt in de status. ◊ CT-formulier Het formulier dat op de CT-gebruikt wordt voor het noteren van de lokalisatiegegevens. ◊ Formulier ochtendbespreking • Checklijsten: Deze lijsten worden gebruikt om te zorgen dat alle deelprocessen zijn voltooid. Als de lijsten niet meer gebruikt worden, worden zij toegevoegd aan de status radiotherapie. ◊ Ten behoeve van de voorbereiding ◊ Ten behoeve van de planning ◊ Ten behoeve van de administratie


pagina 67 van 131

De lijst met applicaties die op de afdeling radiotherapie gebruikt worden, is lang. Een groot deel van de applicaties zijn software producten van Varian. Deze producten zijn verzameld in één suite. Centraal in de suite staat een SQL-database. Naast de applicaties uit de ARIA-suite worden een aantal applicaties uit het ziekenhuis informatiesysteem en een aantal applicaties van de firma Brainlab gebruikt. In tabel 5.5 is een overzicht geschetst van de gebruikte applicaties op de afdeling radiotherapie. Tabel 5.5 In bijgaande tabel is een overzicht van de gebruikte applicaties op de afdeling radiotherapie en de functie van de applicatie. In afbeelding 4.8 is hun onderlinge relatie en hun relatie met de functies weergegeven. Functie

Applicatie

Beeldbewerking

Enhanced Brilliance Workspace

Dosimetrie

Portal dosimetry (ARIA)

Financiële administratie

TOREN (ZIS)

In-room imaging kV-images (Varian) Portal images CBCT kV-images (Brainlab)

OBI-applicatie(ARIA) OBI-applicatie (ARIA) OBI-applicatie (ARIA) ExacTrac (Brainlab)

Intekenen structuren

GE advantage Eclipse (ARIA) iPlan RT-image (Brainlab)

Intramuraal elektronisch patiëntendossier

MIRRADOR (ZIS)

Invoeren en aanpassen bestralingsgegevens in verificatiesysteem

RT Chart (ARIA)

Invoeren en aanpassen patiëntengegevens

PATREG (ZIS)

Invoeren van gegevens in verificatiesysteem

RT-Chart (ARIA)

Matchen

Off-line review (ARIA) OBI-applicatie (ARIA) ExacTrac (Brainlab) ExacTrac (Brainlab)

Off-line (Varian) On-line (Varian) Off-line (Brainlab) On-line (Brainlab)

Monitoren ademhaling patiënt

Real-time Position Management (ARIA)

Rapportage van de bestralingsgegevens (aantal gegeven fracties, gege- Digitale stralenkaart ven dosis, opmerkingen, verschuivingsgegevens) uit ARIA Registratie en aanpassing van patiëntgebonden afspraken binnen het ULTRAGENDA (ZIS) ziekenhuis Treatment planningssysteem

Eclipse (ARIA) IRREG (ARIA) iPlan RT-dose (Brainlab)

Verificatie van bestralingsparameters

Treatment (ARIA)

Virtuele simulatie

GE advantage

In afbeelding 5.9 is de grafische weergave van de applicatielaag. In deze grafische weergave zijn links twee applicatie componenten die buiten de afdeling vallen weergegeven. Links boven is het ziekenhuis PACS weergegeven, met daaronder in het groen het ziekenhuis informatiesysteem met de componenten die door de afdeling radiotherapie gebruikt worden. Het ZIS kent meer applicatiecomponenten maar die zijn niet van belang voor de afdeling radiotherapie.

pagina 68 van 131


Afbeelding 5.9 Het model van de applicatielaag. De applicatie componenten zijn voorgesteld als de afgeronde rechthoeken. In de afbeelding zijn vier grote componenten te herkennen: het ziekenhuis informatiesysteem (groen), de ARIAsuite (roze), het iPlan-systeem (lila) en de radiotherapie patiënten status. Deze laatste is evenals de andere papierencomponenten blauw gekleurd. In bijlage 7 is de figuur in het groot afgebeeld.

In het midden in het roze is de ARIA-suite met haar bijbehorende componenten te zien. Centraal in de ARIA-suite staat de ARIA-database. Rechts boven in het lila is het softwarepakket iPlan te zien met twee componenten. Tussen het ziekenhuis PACS en iPlan in staan de CT-scanner, de virtuele simulatieapplicatie en een PET-CT beeldbewerkingsstation geplaatst. Verder staan in het blauw de papieren componenten, met als belangrijkste de radiotherapie status. Niet alle papieren componenten komen direct in de radiotherapie status, maar na gebruik worden ze wel aan de radiotherapie status toegevoegd. Een deel van deze componenten wordt uit de status verwijderd na het afronden van de behandeling.


pagina 69 van 131

5.2.3 De fysieke laag In deze derde en onderste laag worden alle fysieke componenten beschreven. Ter vereenvoudiging van het model zijn overeenkomstige fysieke componenten beschreven als zijnde één component (Afbeelding 5.10). Rechts in afbeelding 5.10 zijn in de groene vakken de onderdelen van de nog te bouwen satellietlocatie Esperanz gepositioneerd. In het rood is de verbinding tussen de satellietlocatie in Hoorn en de hoofdlocatie in Amsterdam. Onder in de figuur zijn in het geel van links naar rechts de versnellers A tot en met F, de ochtendbesprekingsruimte (OB-ruimte) en de versnellercockpit (waar eerder in paragraaf 5.1.6 over is gesproken). De huidige ochtendbesprekingsruimte heeft nu nog geen videoconferencingsfaciliteiten en de bestralingscockpit is nog in zijn geheel nog niet gerealiseerd. De afdeling radiotherapie van het VUmc heeft 6 versnellers, vijf versnellers van de fabrikant Varian en één versneller van de fabrikant Brainlab. Op de satellietlocatie in Hoorn worden drie bestralingsbunkers gebouwd, waar in twee daar van een versneller wordt geplaatst. Dit zullen twee versnellers zijn van Varian. Alle servers en data-opslag zijn ondergebracht bij de centrale ICT-afdeling van het VUmc. De ARIAserver is niet dubbel uitgevoerd, de data-opslag is wel redundant uitgevoerd.

Afbeelding 5.10 Het model van de fysieke laag. De componenten zijn voorgesteld als een rechthoek of als een pictogram. In bijlage 8 is de figuur in het groot afgebeeld. De onderdelen in de groene vakken (= satellietlocatie) en in het blauwe vak (versnellercockpit) moeten nog gerealiseerd worden.

pagina 70 van 131


Het netwerk van het VUmc bestaat uit één geheel, de afdeling radiotherapie heeft geen eigen netwerk. Het netwerk op de satellietlocatie in Hoorn wordt tevens VUmc netwerk. Op de satellietlocatie zullen enkele computers verbonden zijn met het ZIS van het Westfries Gasthuis, deze computers hebben dan geen verbinding met het netwerk van het VUmc. Op de satellietlocatie zullen dus twee netwerken aanwezig zijn, het grootste deel VUmc-netwerk en een klein deel WFG-netwerk. Fysieke onderdeel

Locatie

CT

Afdeling radiotherapie VUmc

Werkstations iPlan


Werkstations Eclipse


Werkstation PET-CT


Werkstations virtuele simulatie


iPlan Sever

VUmc – data centrum

ARIA Server


ExacTrac Server


PACS-server


ZIS-server

VUmc

Centrale data opslag

VUmc

Back-up centrale data opslag

VUmc

Bestralingscockpit

Afdeling radiotherapie VUmc (nog niet gerealiseerd)

Ochtendbesprekingsruimte VUmc

Afdeling radiotherapie VUmc (nu nog geen videoconferencing faciliteiten)

Toestel A t/m F


Esperanz 1 en 2

Esperanz, Hoorn (nog niet gerealiseerd)

Ochtendbesprekingsruimte VUmc

Esperanz, Hoorn (nog niet gerealiseerd)

Artsenkamer Esperanz

Esperanz, Hoorn

Verbinding VUmc - Esperanz

Dubbel uitgevoerde verbinding tussen VUmc en satellietlocatie Esperanz

5.2.4 Samenhang tussen de functionele laag en de applicatie laag Tussen de lagen is een onderlinge samenhang aanwezig. De functies worden ondersteund door de applicaties en de applicaties draaien op fysieke componenten. In tabel 5.7 zijn deze relaties uiteen gezet. De tabel laat zien welke componenten (applicaties en papierencomponenten) bij welke functies gebruikt worden. Deze tabel kan gebruikt worden om na te gaan of er sprake is van redundantie. Als voor één functie meerdere componenten benodigd zijn, kan dat erop wijzen dat informatie in meerdere systemen moet worden ingevoerd en aanwezig is of dat van meerdere applicaties gebruik gemaakt kan worden voor hetzelfde doel. Zo kan voor de functionaliteit “Intekenen” de applicaties “iPlan image”, “GE-advantage”, “Eclipse”, “PET-CT beeldbewerking” gebruikt worden. In dit geval ligt de oorzaak in het feit dat de verschillende applicaties gebruikt worden voor verschillende specifieke indicaties. Zouden de applicaties geheel gelijkwaardig aan elkaar zijn dan is sprake van redundantie in de beschikbare applicaties. Ook kan met de tabel nagegaan worden welke functionaliteiten weg vallen als de verbinding tussen beide locaties weg valt. Zo zijn alle onderdelen van het ZIS en ARIA niet beschikbaar als de verbinding tussen beide locaties weg valt. Alle functies die in de rode balken gemarkeerd staan, kunnen dan niet meer of niet meer op de reguliere uitgevoerd worden. Resultaten casestudyey

pagina 71 van 131

5.3 Interoperabiliteitsproblemen van de afdeling Door de twee respondenten uit het VUmc zijn in het totaal acht interoperabiliteitsproblemen beschreven. Daarvan spelen vijf problemen binnen de grenzen van de afdeling radiotherapie, drie problemen betreffen problemen in de informatieoverdracht tussen de afdeling en de rest van het ziekenhuis en één probleem heeft betrekking op de informatie overdracht met andere instituten. Tabel 5.8 Overzicht van de gerapporteerde interoperabiliteitsproblemen die op het moment nog spelen op de afdeling radiotherapie van het VUmc. Waar?

Korte beschrijving probleem

Afdeling

Export van DICOM-objecten van de klinische database naar de database voor onderzoeksdoeleinden.

Afdeling

Registratie van bijzonderheden kan niet in de digitale stralenkaart. Transfer via ver verstopte velden in ARIA.

Afdeling

Ingetekende structuren zijn niet identiek als ze overgestuurd worden van de ene applicatie naar een andere applicatie.

Afdeling

Fusieresultaten blijven niet behouden.

Ziekenhuis

Netwerk problemen bij opvragen van omvangrijke datasets.

Ziekenhuis

ZIS mag geen externe afspraken ontvangen, dubbele registratie van afspraken voor patiënten.

Extramuraal

Overdracht van onderzoeksgegevens moet anoniem gebeuren, dit is nogal bewerkelijk en soms niet voor alle gegevens.

In de volgende paragrafen zullen de interoperabiliteitsproblemen worden beschreven, voor een aantal is een use case beschrijving toegevoegd. Op basis van de use case beschrijving is nagegaan of één van de IHE-profielen van toepassing is op het betreffende interoperabiliteitsprobleem.

5.3.1 Fusie van multi-modality imaging Een probleem dat speelt op de afdeling betreft de fusie van meerdere datasets. Ten behoeve van de intekening worden vaak verschillende beeldvormende modaliteiten met elkaar gefuseerd (zoals MRI met CT of PET met CT). In de huidige situatie gaat het resultaat van de fusie gaat echter verloren als de gegevens over gestuurd worden van het ene systeem naar het andere. In het geval van het VUmc betreft het dan bijvoorbeeld het oversturen van het ene treatment planningssysteem (iPlan) naar het andere systeem (Eclipse) of van het virtuele simulatie werkstation (GE advantage) naar een treatment planningssysteem. In de gewenste functionaliteit worden de frames of reference aan elkaar gerelateerd en worden de verplaatsingen opgeslagen. Door de IHE wordt deze functionaliteit gedekt door het profiel “Image fusion profile (FUS)” (Image Fusion (FUS) Integration profile, 2006; Wallis, 2006). Dit profiel heeft op het moment de status “Trial Implementation”. Indien de fabrikanten van de applicaties die gebruikt worden voor het fuseren van beelden dit profiel zouden implementeren, dan zou dit probleem bij een toekomstige upgrade van het systeem opgelost moeten worden. Een ander profiel dat bij dit interoperabiliteitsprobleem van toepassing kan zijn, is het profiel “Image Registration (REG)” (Image Registration (REG) Integration Profile, 2007). Het verschil tussen het “Image Registration” en “Image fusion profile” is dat “Image Registration” ook betrekking heeft DICOM-RT objecten zoals RT-structure sets RT-dose profiles en DRRs. pagina 72 van 131


Beide profielen houden nog geen rekening met deformatie. Deze functionaliteit staat sinds 2010 wel op de wensenlijst voor het ontwikkelen van een integratieprofiel, hiervoor is nog geen use case ingediend. Tijdens dit onderzoek kwam naar voren dat het VUmc graag haar eigen PACS zou willen hebben voor de opslag van DICOM(-RT) objecten. Bij de aanschaf van een PACS zou gelet moeten worden op het PACS beide profielen ondersteund.

5.3.2 Export (geanonimiseerde) datasets Door de respondenten van het VUmc zijn twee interoperabiliteitsproblemen beschreven die betrekking hadden op het exporteren van patiëntgegevens in DICOM-RT formaat. Het gaat dan om: • De export van patiëntdata van de klinische database naar de research database; • De overdracht van geanonimiseerde klinische gegevens moet anoniem gebeuren. De huidige manier van geanonimiseerde export is als volgt. Voor de export van data ten behoeve van een klinische trial selecteert een gebruiker de te exporteren gegevens van een patiënt. De gegevens worden geëxporteerd naar een systeem en op de één of andere manier verwijderd de gebruiker de identiteitsgegevens in de data. De gegevens worden vervolgens verstuurd naar het andere instituut. Behandelinformatie wordt over het algemeen niet verzonden in een DICOM-RT formaat, maar als screen captures of gedrukte exemplaren. De gewenste manier zou als volgt zijn: vanuit het treatment planningssysteem, virtuele simulatie applicatie of een verificatie systeem selecteert een gebruiker de gewenste DICOM-RT objecten (bijv. CT, MR, structure-set, plannen, DVHs, DRRs, behandel gegevens) en de gewenst patiënten die geëxporteerd dienen te worden. Vervolgens wordt de data repository geselecteerd waar naar geëxporteerd dient te worden. De gegevens worden dan vervolgens geautomatiseerd verzameld, geanonimiseerd, versleuteld en verstuurd. Van deze gewenste functionaliteit is een use case diagram opgesteld (Afbeelding 5.11).

Afbeelding 5.11: Use case diagram van geanonimiseerde export van DICOM-RT objecten. De use case “geanonimiseerd exporteren” maakt gebruik van de use cases “selecteren patiënten”, “selecteren DICOM-RT objecten”, “exporteren DICOMRT” en “Haal ziektegeschiedenis op”. Resultaten casestudyey

pagina 73 van 131

Nadat de use case geïnitieerd is door een actor zal eerst de use case “selecteren patiënten” en “selecteren DICOM RT objecten” worden gestart. Als deze zijn uitgevoerd en de patiënten en de gewenste DICOM objecten zijn geselecteerd, worden respectievelijk uit het ZIS en de ARIA database de ziektegeschiedenis en de DICOM RT objecten opgehaald door de use cases “exporteren DICOM RT” en “Haal ziektegeschiedenis op”. Vervolgens zal door de use case “geanonimiseerd exporteren” het anonimiseren en de uiteindelijke export worden uitgevoerd. Voor een niet geanonimiseerde export is het use case diagram slechts op één aspect verschillend. De use case “geanonimiseerd exporteren”, moet dan vervangen worden door “exporteren”. Deze use case is in 2006 ingebracht in de use case wensenlijst op de Wiki van het radiotherapie deel van de IHE onder de naam: “Clinical Trials submission II-Radiotherapy Patient Anonymization” (Curran, 2007; Field, 2007). Het VUmc zou bij de verdere uitwerking van de use case betrokken kunnen zijn en zodra een concept profiel gepubliceerd wordt, feedback op het ontwikkelde profiel kunnen geven. Dit profiel zou de functies “Onderwijs en opleiden” en “Onderzoek” ten goede komen. Daarnaast zou het profiel het eenvoudiger maken om ervaringen, in het vervaardigen van bestralingsplannen, tussen afdelingen radiotherapie uit te wisselen. Indirect zou zodoende dit profiel de kwaliteit van de patiëntenzorg ten goede komen.

5.3.3 Registratie van bijzonderheden in de digitale stralenkaart De afdeling radiotherapie maakt nu gebruik van een digitale stralenkaart. Dit is een JSP3-applicatie waarbij door het script gegevens uit de ARIA-database wordt verzameld en gepresenteerd worden. Bij het gebruik van een papieren stralenkaart was het gebruikelijk om opmerkingen in de stralenkaart te schrijven als tijdens één van de fracties een bijzonderheid optrad. Bijvoorbeeld: Bij de 15e fractie valt op dat het masker van een patiënt niet meer perfect aansluit. Omdat de digitale stralenkaart een leesapplicatie is, is het niet mogelijk om opmerkingen in de stralenkaart te noteren. De oorzaak hiervan ligt in het feit dat in de velden van de database door de applicatie niet geschreven mag worden. Op de afdeling radiotherapie is hiervoor een work-around gecreëerd waarbij via een andere applicatie de ARIA-database wordt benaderd om bijzonderheden in de database te kunnen wegschrijven.

5.3.4 Overdracht van ingetekende structuren Gebruik makend van DICOM-RT is het mogelijk ingetekende structuren over te sturen van de ene applicatie naar de andere. Soms blijkt hier informatie verloren te gaan. Zo is er in sommige systemen een maximum gesteld aan het aantal punten waarmee een structuur gedefinieerd wordt in het coördinatensysteem van de beeldvorming (zoals CT of MR). Ook blijkt soms een resampling plaats te vinden. Zo blijkt in Eclipse een punt alleen met de resolutie van de onderliggende beeldvormende modaliteit gedefinieerd te kunnen worden. Details die kleiner zijn dan de voxel-resolutie van de CT verdwijnen dan (dunne uitlopers bv). In Eclipse moet een structuur ‘High Resolution’ gemaakt worden om dit te voorkomen. Probleem hierbij is dat dit pas gedaan kan worden na de import. De resampling heeft dan al plaats gevonden. Geen van de ingediende use cases of reeds geformuleerd integratieprofielen richt zich op dit interoperabiliteitsprobleem. 3

JSP staat voor JavaServer Pages

pagina 74 van 131


5.3.5 Radiotherapie afspraken in ZIS Voor het VUmc is het niet mogelijk om afspraken in vanuit de workflow applicatie naar het ZIS te sturen. Patiënt gegevens kunnen wel uit het ZIS gehaald worden middels een HL7 versie 2 koppeling, het is echter niet mogelijk om gegevens te schrijven. Het gevolg is dat de afspraken van de patiënt handmatig in twee systemen verwerkt moeten worden. Deze use case is in 2008 ingediend bij de IHE en staat onder de naam “Radiation Oncology Workflow Exchange with HIS” in de wensenlijst van de IHE (Brian, 2010; Curran, 2007).


pagina 75 van 131

pagina 76 van 131


6 Analyse en discussie In de komende paragrafen zullen de resultaten worden geanalyseerd en bediscussieerd. Leidraad hierbij zijn de geformuleerde deelvragen. De resultaten van de drie onderdelen van het algemene deel (enquête in Nederland, enquête in het buitenland en interviews in Nederland) worden met elkaar vergeleken en geanalyseerd. Tevens zal de relatie worden gelegd met het casusdeel om zodoende te komen tot een beantwoording van de hoofddoelstelling: “Het versterken van de interoperabiliteit van multi-locatie afdelingen radiotherapie in het algemeen en die van het VUmc in het bijzonder. Het verbeteren van de interoperabiliteit heeft tot doel het verbeteren van de zorg van patiënten die een radiotherapeutische behandeling ondergaan.”

6.1 Interoperabiliteitsproblemen Uit de resultaten van de enquête in Nederland komt naar voren dat interoperabiliteitsproblemen met name DICOM en HL7-gerelateerde problemen zijn. Van de 95 gerapporteerde problemen gerapporteerd komt 69 % voor rekening van HL7 en DICOM. Van die 69 % zijn de meeste problemen DICOM-RT gerelateerd (29 %). Verder is het zo dat de 49 % van de problemen speelt binnen de afdeling, 28 % van de problemen tussen systemen op de afdeling en systemen in de rest van het ziekenhuis. Binnen de afdeling spelen met name de DICOM en DICOM-RT gerelateerde problemen. Tussen de afdeling en het ziekenhuis spelen zowel DICOM als HL7 gerelateerde problemen. Het type problemen en de verhouding dat door Nederlandse en buitenlandse afdelingen gerapporteerd werd, is redelijk vergelijkbaar (Afbeelding 6.1). Relatief gezien worden in het buitenland minder DICOM problemen gerapporteerd (14 % in het buitenland tegen 25 % in Nederland). Daarentegen worden relatief meer HL7 en DICOMRT problemen gerapporteerd.

Afbeelding 6.1: Gerapporteerde interoperabiliteitsproblemen van de Nederlandse en buitenlandse respondenten ingedeeld naar de plaats waar ze optre-den: binnen de grenzen van de afdeling, tussen de afdeling en de rest van het ziekenhuis of tussen de afdeling en extramurale locaties. Op de y-as de relatieve bijdrage ten opzichte van het totaal aantal problemen binnen een locatie. Analyse en discussie

pagina 77 van 131

Van de interoperabiliteitsproblemen die spelen binnen de afdeling worden de problemen tussen het treatment planningssysteem en het verificatiesysteem gezien als de problemen die het gewenste proces het meest verstoren. Een aantal afdelingen heeft dit probleem opgelost door applicaties te ontwikkelen die de export kant van het treatment planningssysteem reguleren. Bij de interoperabiliteitsproblemen tussen de afdeling en de rest van het ziekenhuis worden de problemen tussen workflow applicaties en het ZIS als problemen met grote impact gekwalificeerd. Deze problemen hebben vaak tot gevolg dat handmatig gegevens moeten worden overgenomen van het ene systeem in het andere systeem. Een deel van de problemen worden veroorzaakt door HL7-conflicten. Een aantal instituten (zowel in binnen- als buitenland) beschrijft dat de problemen veroorzaakt wordt door veiligheidsbeleid van het ziekenhuis. Het is dan alleen toegestaan om met andere informatiesystemen gegevens uit het ZIS te lezen en het is niet toegestaan om te schrijven. Bij de interoperabiliteitsproblemen tussen de afdeling en instellingen buiten het ziekenhuis worden vergelijkbare redenen gegeven. Door beleid van het eigen of het andere instituut is koppeling van de systemen niet mogelijk. Strikt genomen zijn dit eigenlijk geen echte interoperabiliteitsproblemen. De systemen zijn namelijk in het geheel niet gekoppeld, dus van een zinvolle gegevensuitwisseling kan sowieso geen sprake zijn.

6.1.1 Problemen van het VUmc vergeleken met die op andere afdelingen De problemen die door de respondenten gerapporteerd zijn, zijn vergelijkbaar met de problemen die het VUmc zelf ondervindt. Het VUmc heeft acht interoperabiliteitsproblemen aangegeven: • vijf problemen binnen de grenzen van de afdeling radiotherapie; • twee problemen tussen de afdeling en de rest van het ziekenhuis; • één probleem had betrekking op extramurale gegevensuitwisseling. Twee problemen die het VUmc ondervindt, zijn niet gerapporteerd door andere instituten. Als eerste wordt het probleem met het oversturen van een RT-structure file van het ene systeem naar het andere systeem, waarbij de structuren niet identiek over komen, door geen enkele ander instituut gerapporteerd. Reden hiervoor zou kunnen zijn dat dit probleem alleen merkbaar is bij zeer kleine ingetekende structuren. Het VUmc heeft dit probleem gesignaleerd door het intekenen van structuren ten behoeve intracraniale stereotactie en bij stereotactie bij long tumoren. Een andere reden zou kunnen zijn dat dit door respondenten niet gezien wordt als een interoperabiliteitsprobleem. Het is namelijk wel mogelijk om de CT-data van het ene systeem naar het andere systeem te sturen, alleen door resampling komt de intekening niet identiek over. Of dit gezien moet worden als een interoperabiliteitsprobleem wordt dan bepaald door hoe strikt de definitie van interoperabiliteitsproblemen wordt gehanteerd. De in dit onderzoek gehanteerde definitie luidt: “het vermogen van gezondheidsinformatiesystemen om samen te werken, zowel binnen als buiten de grenzen van een zorginstelling, en zodoende de effectiviteit van het zorgproces te versterken”. Bij dit probleem is wel samenwerking tussen beide systemen mogelijk. De effectiviteit van het zorgproces komt echter wel in het gedrang. Ingetekende structuren moeten opnieuw ingetekend worden of de kwaliteit van de behandeling zou negatief beïnvloed kunnen worden als het niet opvalt dat de ingetekende structuur niet identiek is overgekomen. pagina 78 van 131

Analyse en discussie

Ten tweede wordt het probleem met de koppeling van de zelf ontwikkelde digitale stralenkaart met het verificatiesysteem, waarbij het niet mogelijk is om opmerkingen in de stralenkaart te sturen naar de database van het verificatiesysteem, niet door andere afdelingen beschreven. Dit probleem is zeer specifiek omdat het hier gaat over een zelf ontwikkeld applicatie. Als het probleem echter wat meer generiek wordt beschouwd en wordt gezien als een probleem waarbij een database niet door software van derden mag worden geschreven, dan wordt dit probleem door vier andere respondenten beschreven.

6.2 Strategieën 6.2.1 One vendor strategie De strategie die afdelingen gebruiken in het voorkomen en oplossen van interoperabiliteitsproblemen is heel divers. Een aantal instellingen in Nederland en in het buitenland geeft aan een “one vendor” strategie aan te houden in het voorkomen van interoperabiliteitsproblemen. Een “one vendor” afdeling bestaat niet echt. Bij geen van de onderzochte instellingen is sprake van een zuivere “one vendor” afdeling. Bij alle afdelingen was wel een combinatie van systemen van verschillende fabrikanten, bijvoorbeeld: • het treatment planningssysteem, het verificatiesysteem en de versnellers van één fabrikant heeft, maar dan een tweede treatment planningssysteem van een andere fabrikant; • alle versnellers en het verificatiesysteem van één fabrikant, maar het treatment planningssysteem van een andere fabrikant. Maar ook bij de afdelingen die een “one vendor”-strategie nastreven, spelen interoperabiliteitsproblemen. Dit komt enerzijds doordat deze strategie niet de problemen kan voorkomen die optreden door communicatie met applicaties buiten het “systeem”: zoals een ziekenhuis informatiesysteem of een extramuraal informatiesysteem. Anderzijds kan het zijn dat de applicaties van één fabrikant niet voldoende geïntegreerd zijn en niet goed op elkaar aansluiten. Zo schrijft één van de buitenlandse respondenten in de toelichting bij de interoperabiliteitsproblemen die zijn afdeling ervaart: “Our imaging applications are like islands.”. Verder wordt door twee respondenten in de interviews aangegeven dat een “single vendor” strategie ook een mogelijk ongewenste afhankelijkheid kan creëren. Gesteld wordt dat de fabrikant een monopoly positie heeft en de afdeling te veel afhankelijk wordt op lange termijn.

6.2.2 Zelf oplossen van interoperabiliteitsproblemen Binnen een aantal afdelingen is veel expertise in het oplossen van interoperabiliteitsproblemen. Dat blijkt onder andere door de hoeveelheid aan applicaties die door afdelingen ontwikkeld is. In een eerste analyse van de enquêtes leek het alsof een deel van de afdelingen interoperabiliteitsproblemen accepteert als een gegeven. De afdeling ondervindt een interoperabiliteitsprobleem en lost deze middels de aanwezige expertise op de afdeling zelf op. Uit de interviews blijkt echter, doordat elke respondent wel op één of andere manier hier over opmerkingen maakt, dat afdelingen heel graag zouden willen dat fabrikanten de interoperabiliteitsproblemen zouden oplossen. Een belangrijk aspect hierin is de hoeveelheid tijd en mankracht die een afdeling moet steken om de problemen zelf op te lossen.


pagina 79 van 131

Daarnaast wordt door een aantal afdelingen aangegeven dat zij graag zouden willen dat de fabrikant de interoperabiliteitsproblemen zou oplossen omdat de fabrikant meer expertise zou bezitten. Zowel in de interviews als in de enquête wordt daarentegen aangegeven dat de fabrikant onvoldoende zicht heeft op de manier waarop in de kliniek met de ontwikkelde producten gewerkt wordt en dat een deel van de problemen daar aan te wijten is. Zowel in de enquête onder de Nederlandse, de buitenlandse instituten, als de interviews is onvrede merkbaar over de mate waarin op fabrikanten geconstateerde interoperabiliteitsproblemen oplossen. Zo wordt gesteld dat de prioriteitstelling van de fabrikant anders is, gesteld wordt dat commerciële doelen en het ontwikkelen van “fancy nieuwe features” prevaleren boven veiligheid en gebruiksgemak. Een oorzaak voor deze onvrede zou kunnen zijn dat het voor een gebruiker niet zichtbaar is aan welke verbeteringen door de fabrikant gewerkt wordt. Een ander aspect dat hierbij mee speelt is dat het aanpassen van software een tijdrovende aangelegenheid is. Niet alleen de software moet aangepast worden, maar ook alle benodigde juridische trajecten, zoals bijvoorbeeld het verkrijgen van een FDA1 approval, moeten doorlopen worden. Veel zelf ontwikkelde applicaties worden ontwikkeld omdat bestaande (commerciële) producten niet voldoen. Bij het zelf ontwikkelen van applicaties geldt als groot voordeel natuurlijk dat de applicatie zo ontwikkeld kan worden dat hij perfect aansluit bij het werkproces van de afdeling. Een belangrijk nadeel is echter de kwetsbaarheid en de benodigde mankracht en kennis (Benson, 2010). Bij aanpassingen van de applicaties van de vendor of het anders inrichten van het werkproces kan het zijn dat veel programmeerwerk verricht moet worden om de applicatie aan te passen aan de nieuwe situatie. Indien bij het ontwikkelen van de applicaties gebruik wordt gemaakt van de principes van object georiënteerd denken dan zou dit geen probleem hoeven te zijn.

6.2.3 Strategie ten aanzien van intramurale gegevensuitwisseling Voor het oplossen van interoperabiliteitsproblemen tussen de afdeling en instellingen buiten het ziekenhuis wordt door een aantal afdelingen aansluiting gezocht of wordt actief het voortouw genomen in regionale initiatieven voor de uitwisseling van medische gegevens tussen instituten. Voor de drie instituten die in de interviews zijn meegenomen en die op meerdere locaties werken, geldt dit zeker. De resultaten uit de enquêtes bevestigen dit beeld. Bij de andere instituten die op meerdere locaties (gaan) werken en de zelfstandig opererende radiotherapeutische instituten worden initiatieven ontplooid om intramurale gegevens uitwisseling mogelijk te maken.

6.3 Bekendheid met de IHE Wat een opvallend verschil is in de resultaten uit de enquête onder de Nederlandse afdelingen en de buitenlandse afdelingen is het verschil participatie bij de activiteiten van de IHE en het verschil in het aantal IHE-profielen dat geïmplementeerd is. Geen van de Nederlandse respondenten heeft aangegeven betrokken te zijn bij de activiteiten van de IHE, tegenover drie in het buitenland. En dat één van de Nederlandse afdelingen één profiel heeft geïmplementeerd, tegenover zes afdelingen die in het totaal acht profielen hebben geïmplementeerd en één implementatietraject loopt (Tabel 4.6 in hoofdstuk 4). Nu is het mogelijk dat het gevonden verschil louter op toeval berusten en dat juist die afdelingen 1

De Amerikaanse overheidsinstantie FDA (Food and Drug Administration) controleert en reguleert producten zoals: voeding, medicijnen en medische apparatuur.

pagina 80 van 131


aan de enquête hebben deel genomen omdat zij zich tot het onderwerp interoperabiliteitsproblemen aangetrokken voelt omdat zij daar actief mee bezig is. Feit blijft staan dat geen participatie van Nederlandse afdelingen gerapporteerd is. Voor participatie bij de IHE is een lange termijn visie vereist, immers de vruchten van de inspanningen kunnen pas na een aantal jaar geplukt worden. Het hele proces van indienen van een use case tot aan een getest en gepubliceerd integratieprofiel neemt immers één tot enkele jaren in beslag. Zo blijkt uit de radiation oncology Wiki van de IHE dat de tijd voor het ontwikkelen van een integratieprofiel twee tot drie jaar in beslag neemt. Het gaat dan om de tijd tussen het indienen van de use case tot het publiceren van het concept profiel (Curran, 2007). Voor de IHE lijkt een taak weggelegd om zich meer te profileren naar de Nederlandse gebruikers. De gebruikers kennen de organisatie, maar ze zijn zich slechts beperkt bewust van de werkwijze van de IHE. Zo geeft een aantal respondenten aan niet op de hoogte te zijn dat zij lid kunnen worden van de IHE en een bijdrage kunnen leveren aan de activiteiten van de organisatie. Bij de bestudering van de IHE-integratieprofielen uit het domein radiation oncology valt op dat de aanduiding in naamgeving niet consequent is en dat worden discrepanties gevonden. Zo wordt op de IHE-RO Wiki gesproken over vier ontwikkelde profielen, maar op dezelfde Wiki zijn slechts het tech nische raamwerk en twee profielen terug te vinden. Verder wordt in één van de gesprekken met leden van IHE-Nederland aangegeven dat het technisch raamwerk op de IHE-RO Wiki niet het meest actuele is. Op basis van de informatie op deze website zou een vertekend beeld kunnen ontstaan van de vooruitgang binnen het IHE-RO domein.

6.4 Informatiestroom afdeling radiotherapie VUmc Het modelleren met UML heeft inzicht gegeven in het werkproces op de afdeling radiotherapie van het VUmc. De modellen maken het daarnaast mogelijk om binnen en buiten de afdeling te communiceren over het werkproces. Tijdens het modelleren zijn gesprekken gevoerd met verschillende medewerkers. Doordat elke professional vanuit zijn eigen perspectief naar het werkproces kijkt, worden verschillen zichtbaar. Bij het modelleren is gezocht naar de grootste algemeen deler, het zou goed zijn om de modellen te gebruiken om het werkproces nog eens met alle professies te bespreken en zo afstemming te krijgen van de activiteiten en verantwoordelijkheden. Dit sluit aan bij de bevindingen van Eriksson en Penker dat het modelleren van bedrijfsprocessen een hulpmiddel kan zijn bij verkrijgen van transparantie en efficiëntie (Eriksson & Penker, 2000). Door Kleppe en Warmer worden zes niveaus van modelleren onderscheiden. Waarbij op niveau 0 geen modelvorming heeft plaats gevonden, slechts een tekstuele beschrijving tot niveau zes waarbij slechts diagrammen de werkelijkheid beschrijven (Warmer & Kleppe, 2008). Volgens deze indeling zijn de verkregen modellen op niveau 3. Dit niveau kenmerkt zich door zowel een tekstuele beschrijving als een schematische beschrijving middels de diagrammen. In de tekst zijn de details van de diagrammen uitgewerkt.


pagina 81 van 131

Het inzicht verkregen met de activiteitendiagrammen, heeft het vullen van de domeinlaag en de applicatielaag uit het 3LGM2-model mogelijk gemaakt. Het vullen van de fysieke laag is maar voor een deel gelukt. De reden hiervoor is dat alleen gebruik is gemaakt van de informatie die op de afdeling radiotherapie voor handen is. Het detailleringniveau van de fysieke laag zou nog verhoogd kunnen worden door bij de centrale ICT-afdeling van het VUmc meer gedetailleerde informatie te verkrijgen. Op die manier kan meer inzicht verkregen worden wat de eventuele consequenties zijn van het uitvallen van één of meerdere fysieke componenten. Het netwerk op de afdeling radiotherapie is in zijn geheel niet gescheiden van het netwerk van het VUmc. Omdat de bedrijfsprocessen zeer zwaar leunen op de ICT faciliteiten, schuilt hier mogelijk een gevaar. Problemen elders in het netwerk kunnen op de afdeling radiotherapie problemen veroorzaken. Zo is in het verleden een probleem geweest met de server die IP-adressen uitdeelt. Omdat door een configuratiefout een IP-adres van een versneller werd uitgedeeld aan een computer elders in het VUmc viel plots de verbinding tussen de versneller en het netwerk uit. Een opdeling van het netwerk in functionele eenheden zou mogelijk te verkiezen zijn, hierbij kan gedacht worden aan een configuratie waarbij de versnellers in een eigen netwerk zijn geplaatst. Het meer in detail uitwerken van de fysieke laag kan duidelijkheid geven over de consequenties van het uitvallen van de verbinding van de satellietlocatie in Hoorn en welke applicaties en functies dan niet meer ondersteund worden. Het gebruik van dit model heeft op een overzichtelijke manier de informatiestromen gevisualiseerd. Zonder het 3LGM2-model zou het ook gelukt zijn om de informatiestromen in kaart te brengen. Hiervoor zou dan het deployment en het classdiagram gebruikt zijn. De relatie tussen de informatiestroom en de functies zou dan mogelijk echter minder duidelijk tot uiting zijn gekomen.

6.5 Werken op meerdere locaties De groei van afdeling radiotherapie van het VUmc naar een multi-locatie afdeling is niet uniek. Andere afdelingen in Nederland maken dezelfde ontwikkeling door of lopen in de tijd hier op voor. In Nederland zijn drie afdelingen die op het moment op meerdere locaties werken en daar zullen de komende jaren nog zeker vijf afdelingen in volgen. Van de afdelingen die ervaring hebben in het werken op meerdere locaties kan veel geleerd worden ten aanzien van: • de gekozen netwerk architectuur; • het omgaan met het wegvallen van de verbinding tussen beide locaties; • de aanwezige deskundigheid op de satellietlocatie; • hoe omgegaan wordt met de communicatie tussen beide locaties; ◊ papieren componenten ◊ videoconferencing • hoe extramurale informatie uitwisseling wordt nagestreefd.

6.5.1 Gekozen architectuur Alle afdelingen die nu op meerdere locaties werkt, hebben ervoor gekozen om het netwerk op de satellietlocatie een uitstulping te laten zijn van het bestaande netwerk. Hierdoor worden veel nieuwe interoperabiliteitsproblemen voorkomen. Een belangrijk punt dat dan cruciaal wordt, is de verbinding tussen de hoofdlocatie en de satellietlocatie. Nu is voor de afdeling radiotherapie van het VUmc nog pagina 82 van 131


onduidelijk op welke wijze de verbinding met de satellietlocatie in Hoorn vorm wordt gegeven. Zeker is dat voor het waarborgen van technische interoperabiliteit een betrouwbare verbinding tussen de locaties gebruikt dient te worden. Alle afdelingen die zijn bezocht voor een interview en op twee locaties werkt, hebben ervoor gekozen om de verbinding dubbel uit te voeren. Het gaat hierbij niet alleen om de verbinding maar ook de componenten die onderdeel uit maken van deze verbinding (zoals switches en routers). Naast het dubbel uitvoeren van de verbinding zou gedacht kunnen worden aan het onder brengen van de verbinding bij twee verschillende aanbieders. Bij het onderbrengen van de verbindingen bij twee verschillende aanbieders, moet gelet worden op het feit of het wel gaat om fysiek twee verschillende verbinding. Het zou zo kunnen zijn dat twee aanbieders feitelijk dezelfde glasvezel gebruiken tussen Amsterdam en Hoorn en als dan een graafmachine die glasvezel stuk graaft dan vallen beide verbindingen weg. Een ring architectuur is te verkiezen, waarbij de gegevens nog via de andere zijde van de ring getransporteerd kunnen worden, als één zijde wordt doorbroken. Ook dient in de keuze van de verbindingen mee genomen te worden of de tweede verbinding niet van een heel ander type moet zijn (bv. straalverbinding of satelliet). Of dat naast de twee vaste verbindingen een derde prepaid verbinding van een ander type achter de hand wordt gehouden. Deze derde verbinding wordt alleen in geval van calamiteiten gebruikt en zo zouden de kosten van deze bijzondere derde verbinding in de hand gehouden kunnen worden. Bij de keuze hoe de verbinding vorm gegeven gaat worden dient een afweging gemaakt te worden tussen de kosten en de baten: “Welke kosten zou de afdeling VUmc willen dragen om het risico te ondervangen dat de patiëntenzorg op haar satellietlocatie stagneert?”.

6.5.2 Werken bij wegvallen van de verbinding Uit de interviews bleek dat twee van de drie afdelingen, die op meerdere locaties werken, accepteren dat tijdelijk geen bestralingen kunnen worden uitgevoerd bij het wegvallen van de verbinding. De afdeling die nu nog niet op twee locaties werkt maar dat wel gaat doen, heeft aangegeven ook dit risico te accepteren. De vierde afdeling heeft ervoor gezorgd dat de patiëntenzorg door kan gaan bij het langdurig wegvallen van de verbinding. Deze afdeling heeft in een standaard operating procedure (SOP) beschreven hoe één van de back-up servers van het verificatiesysteem productie server wordt en de patiëntenzorg voortgang kan hebben bij het (langdurig) weg vallen van de verbinding. Deze back-up server is geplaatst op de satellietlocatie. Deze constructie betekend dat bij het langdurig wegvallen van de verbinding beide locaties tijdelijk hun eigen verificatiesysteem hebben. Indien het VUmc de patiëntenzorg wil waarborgen bij het uitvallen van de verbinding, dan zijn drie opties denkbaar. Als eerste mogelijkheid zou het VUmc ervoor kunnen kiezen om de faciliteiten analoog in te richten aan de vierde afdeling. Zoals beschreven wordt bij deze oplossing: de back-up server van het verificatiesysteem, die op de satellietlocatie is geplaatst, een productie server bij het langdurig wegvallen van de verbinding. Dit heeft als grote voordeel dat op beide locaties een werkend verificatiesysteem hebben. Nadeel van deze oplossing is dat beide servers gesynchroniseerd moeten worden na het herstellen van de verbinding.


pagina 83 van 131

Technisch zou het synchroniseren van twee databases geen problemen mogen opleveren. Praktisch blijkt dit echter lastig te realiseren. Een belangrijk punt hierbij is hoe voorkomen kan worden dat de gegevens van één patiënt niet in beide databases worden aangepast. Om dit te voorkomen zouden alle gegevens van de patiënten die op de locatie Esperanz bestraald worden automatisch beveiligd moeten worden tegen schrijven op de server in Amsterdam bij het wegvallen van de verbinding. Omdat fabrikanten problemen ten gevolge van fouten in de synchronisatie van twee databases willen voorkomen, is het vaak niet mogelijk om de database met software van derden te benaderen en is een afdeling aangewezen op de producten van fabrikant van het verificatiesysteem. Nagegaan zou moeten worden in hoeverre deze methode voor het VUmc haalbaar zou zijn. Op het moment is de server van het verificatiesysteem nog niet redundant uitgevoerd. Van de server worden snapshots gemaakt en de van de data worden back-ups gemaakt. Bij uitval van de server kan van zo een snapshot weer heel snel op een andere server een werkende configuratie worden gecreëerd, tijdelijke uitval is echter niet tegen te gaan. Een tweede mogelijkheid voor de afdeling radiotherapie van het VUmc is dat zij gebruik maakt van de faciliteiten die zij nu al heeft. In de huidige situatie is het proces zo ingericht dat, als door netwerkpro blemen het verificatiesysteem niet benaderd kan worden, behandeld kan worden in een “off-line mode”. Ten behoeve van deze “off-line mode” worden voor de start van de eerste fractie van een patiënt enkele DICOM-RT bestanden naar een netwerkschijf geschreven. Een script kopieert deze bestanden lokaal naar elke versneller. Nagegaan zou moeten worden welke indicaties op deze wijze bestraald zouden kunnen worden. De bestralingstechnieken worden steeds complexer en voor elke bestralingstechniek zou nagegaan moeten worden of deze manier van aansturen van de versneller daadwerkelijk foutloos gebeurd. In de keuzes die hierin gemaakt wordt, moet mee genomen worden of op de satellietlocatie bij het geval van het stralen in “off-line mode” al dan niet een klinisch fysicus op de locatie aanwezig moet zijn. Tot slot is er een derde mogelijkheid. Dit is een variant op de tweede mogelijkheid. Het zou mogelijk zijn om voor de opslag van de DICOM-RT bestanden op beide locaties een PACS in te richten. In de huidige situatie worden de bestanden lokaal op de versneller bewaard voor het “off-line” bestralen. Tijdens de dataverzameling van dit onderzoek bleek dat de afdeling radiotherapie van het VUmc graag haar eigen PACS zou willen hebben waarop DICOM-RT bestanden kunnen geschreven worden. Als deze aangeschaft zou worden, dan zou ook de back-up van het PACS op de satellietlocatie geplaatst kunnen worden. Naast het probleem van het wegvallen van het verificatiesysteem, zal bij het wegvallen van de verbinding het niet mogelijk zijn de digitale stralenkaart van een patiënt te openen. De digitale stralenkaart is een JSP2-applicatie die op het moment dat de stralenkaart van een patiënt wordt geopend alle gegevens uit de database van ARIA verzameld. Als door netwerkproblemen de database niet beschikbaar is dan kan geen digitale stralenkaart worden samengesteld. De afdeling radiotherapie van het VUmc werkt op het moment aan een oplossing om deze stralenkaarten geautomatiseerd vooraf te laten genereren. Van elke patiënt, die behandeld wordt, wordt dan een digitale stralenkaart in bijvoorbeeld PDF-formaat weggeschreven naar de computer van de versneller waar de patiënt op wordt behandeld. 2

JSP staat voor JavaServer Pages

pagina 84 van 131


6.5.3 Deskundigheid op de satellietlocatie Hoewel het niet echt een punt van aandacht is ten aanzien van interoperabiliteit is een punt van aandacht de aanwezigheid van een klinisch fysicus op de satellietlocatie voor consultatie. Bij het modelleren van het werkproces van het VUmc bleek dat consultatie op het toestel met name nodig is bij het online imaging protocol. Zowel consultatie van een radiotherapeut als een klinisch fysicus komt geregeld voor. Op de satellietlocatie zal altijd een radiotherapeut aanwezig zijn, zodoende is hier geen knelpunt te verwachten. Bij één van de afdelingen die is mee genomen in de interviews en werkt op meerdere locaties, is telefonisch overleg mogelijk en kunnen de gegevens van de patiënt op de hoofdlocatie in de op dat moment relevante applicatie worden geopend. Eén afdeling gaat daar een stap verder in en heeft een zogenaamde versnellercockpit ingericht. Door een VNC-verbinding (VNC staat voor Virtual Networking Computing) is het mogelijk om het treatment werkstation en de imaging console van de versnellers op de satellietlocatie over te nemen. Hierin zou je nog een stap verder kunnen gaan door ook te zorgen dat de situatie in de versnellerruimte met een camera bekeken kan worden. De afdeling die gebruik maakt van de versnellercockpit heeft deze functionaliteit in het begin overwogen, maar het in eerste instantie niet geïmplementeerd. De functionaliteit wordt op het moment niet gemist. Tot slot heeft één afdeling ervoor gekozen om elke dag een klinisch fysicus op de satellietlocatie aanwezig te laten zijn. Deze versnellercockpit zou ook gebruikt kunnen worden gebruikt door de informatiedeskundige bij een probleem in één van de applicaties die op de versnellers gebruikt worden. Hoewel in de interviews hier geen aandacht is geschonken, moet de afdeling ook besluiten of op de locatie in Hoorn een klinisch fysisch medewerker of een versnellertechnicus regulier aanwezig is.

6.5.4 Papieren componenten Op het moment gebruikt de afdeling radiotherapie van het VUmc nog enkele papieren componenten (patiëntenstatus radiotherapie, aanvraag radiotherapie enkele overdrachtsformulieren en check lijsten). Als bij het werken op twee locaties papieren componenten op de verkeerde locatie aanwezig zijn, zou het bedrijfsproces kunnen stagneren. Dagelijks zou één of meerdere keren een bodedienst tussen beide locaties kunnen rijden. Logistiek vraagt dit echter om een zeer goede afstemming. Digitale formulieren zijn te verkiezen en de afdeling radiotherapie van het VUmc onderzoekt op het moment of zij de papieren patiëntenstatus kan vervangen voor een elektronisch medisch dossier. Alle afdelingen die bezocht zijn, hebben deze stap gemaakt of gaan deze stap maken. Een punt van aandacht hierin is de autorisatie, hoe wordt gewaarborgd dat alleen personen die daartoe recht hebben toegang hebben tot dit medisch dossier. Uiteraard geldt dit ook bij een papieren dossier, als een papieren dossier netjes achter slot en grendel wordt opgeborgen zijn de gegevens niet door onbevoegden in te zien. Bij digitale opslag van gegevens van patiënten is dit complexer om te waarborgen. Eén aspect is de versleuteling van de gegevens ten behoeve van transport van de gegevens tussen beide locaties. Een moeilijker te waarborgen aspect heeft te maken met de attitude van medewerkers in het afsluiten van ingelogde computers. Als een medewerker is ingelogd en deze wegloopt van een computer, is informatie vrij toegankelijk. Nu kan de computer zo geconfigureerd worden dat na een zekere tijd van inactiviteit de computer vanzelf uitlogt. Hiermee is het probleem echter slechts ten dele ondervangen, als de medewerker zonder uit te loggen wegloopt is de informatie tijdelijk beschikbaar voor onbevoegden. Het beveiligen van het systeem met een sleutelkaart zou ook dit aspect kunnen ondervangen. Een medewerker heeft dan alleen toegang tot een computer als hij zichzelf autoriseert met een sleutelkaart. Analyse en discussie

pagina 85 van 131

6.5.5 Videoconferencing Door het werken op meerdere locaties wordt het lastig en vaak onmogelijk om voor overleg alle betrokkenen op één locatie bij elkaar te brengen. Om dit probleem te ondervangen maken alle afdelingen, die in de interviews zijn meegenomen en werken op meerdere locaties, gebruik van videoconferencing faciliteiten. Met name voor het dagelijkse interdisciplinaire overleg waarbij de behandelplannen van patiënten worden besproken kan dit bruikbaar zijn. Maar ook voor vergaderingen en bijscholingen is dit een goed alternatief voor overleg op één locatie. Maar ook deze faciliteit staat of valt met een goede verbinding. Eén van de bezochte instituten heeft in de startfase regelmatig problemen ondervonden, waarbij de verbinding weg viel. Volgens het IKA (Integraal Kankercentrum Amsterdam) zou de apparatuur na een eerste instructie door de gebruikers zelf bediend moeten kunnen worden. Een eventuele herstart van de software neemt enige tijd in beslag, maar hiervoor is in principe geen ICT-ondersteuning nodig. Bij het inrichten van de videoconferencing faciliteiten in de satellietlocatie moet wel rekening gehouden worden met waar de ruimte voor gebruik gaat worden en de benodigde capaciteit (Voor technische eisen en een schatting van de kosten kan gebruik gemaakt worden van een business case van het IKA (IKA, 2009)). Indien de videoconferencing faciliteiten ook door nieuwe gebruikers gebruikt gaat worden, dient wel zorg besteedt te worden aan het feit dat de manier van overleg bij het gebruik van videoconferencing faciliteiten meer vergaderdiscipline vraagt, een (getrainde) gespreksleider is essentieel hierin.

6.5.6 Aansluiting bij regionale initiatieven Doordat het netwerk op de satellietlocatie een uitstulping is van het bestaande VUmc netwerk, is het niet mogelijk om medische gegevens van het Westfries Gasthuis via een vaste verbinding op elektro nische wijze uit te wisselen met de satellietlocatie in Hoorn. Zoals eerder beschreven wordt door andere afdelingen die werken op meerdere locaties aansluiting gezocht of actief het voortouw genomen in initiatieven voor het regionaal elektronisch uitwisselen van medische gegevens. De afdeling radiotherapie zou in de Amsterdamse regio aansluiting kunnen zoeken bij het eRadiologie project. In dit project is eerste een haalbaarheidsstudie uitgevoerd . Vervolgens is een pilot uitgevoerd met drie ziekenhuizen. Als het project wordt opgeschaald, niet alleen in het aantal instituten, maar ook in vakgebieden, zou aansluiting gezocht kunnen worden. Ook zou samen met de ziekenhuizen in het Esperanz verband een eigen project kunnen opstarten om uitwisseling tussen de deelnemende ziekenhuizen mogelijk te maken. Voor deze strategie dient een lange termijn visie door de afdeling radiotherapie ontwikkeld te worden. In hoeverre hier aangesloten kan worden bij andere initiatieven binnen het VUmc is niet bekend. Andere vergelijkbare projecten hebben getoond dat winst te halen valt uit het op efficiënte wijze uitwisselen van medische gegevens. Enkele succesvolle regionale en landelijke projecten zijn: • het Regionaal Cardiologienetwerk Friesland; • het RijnmondNet in de regio Rotterdam; • het bevolkingsonderzoek borstkanker.

pagina 86 van 131


Meerdere technische oplossingen zijn mogelijk om regionaal medische gegevens uit te wisselen. Allereerst is het mogelijk om tussen de verschillende instellingen verbindingen te leggen. Bij schaalvergroting wordt deze optie al snel onbeheersbaar (Ciottl, 2010) en deze oplossing is niet in overeenstemming met de visie van de afdeling ICT van het VUmc. Ten tweede is het mogelijk om een centraal archief in te richten. Hierbij organiseren meerdere instellingen een gezamenlijk archief van medische gegevens. De derde mogelijkheid is het gebruik van regionale verwijsindex. Hierbij wordt een infrastructuur opgezet waarbij de zorgverlener medische gegevens kan aanmelden en opvragen in de index. De gegevens worden niet centraal opgeslagen, maar in de verwijsindex staat opgeslagen welke zorgaanbieders gegevens over een patiënt heeft opgeslagen. Deze oplossing met een centrale verwijsindex maken veelal gebruik van het de IHE integratieprofielen XDS en XDS-I (“cross enterprise document sharing” en “cross enterprise document sharing for imaging”) (Huttink & Mekenkamp, 2011). Deze laatste methode werkt volgens het zelfde principe dat gebruikt is bij het inrichten van de infrastructuur ten behoeve van het landelijke EPD. Door recente ontwikkelingen ten aanzien van het EPD en het afwijzen van de wet op het EPD heeft het landelijke proces in de elektronische uitwisseling van medische gegevens een grote deuk opgelopen. Het afwijzen van de wet op het EPD staat haaks op het advies dat de Raad voor de Volksgezondheid en Zorg in 2002 heeft gegeven. In dit advies ‘E-health in zicht’ wordt door de Raad aangegeven dat de overheid de randvoorwaarden voor elektronische gegevensuitwisseling zou moeten scheppen (E-health in zicht, 2002). In haar advies verwoordde de Raad verwoordde de problematiek als volgt: “ ….. Eén van de belangrijkste problemen is het feit dat gegevens niet of onvoldoende tussen zorgverleners op een elektronische wijze kunnen worden uitgewisseld. In de eerste plaats is dit het gevolg van het feit dat veel van deze gegevens niet elektronisch zijn vastgelegd. In de tweede plaats is dit het gevolg van het niet of onvoldoende toepassen van technische standaarden.“(E-health in zicht, 2002). Het is te hopen dat het NICTIZ (Nationaal Instituut voor ICT in de Zorg) ondanks deze recente tegenslag blijft werken aan de randvoorwaarden voor het elektronisch uitwisselen van medische gegevens op regionaal niveau. Een belangrijk bij het van de grond krijgen van dergelijke projecten is de financiering. De initiële instapkosten zijn relatief hoog bij gering aantal deelnemers, maar worden bij meerdere gebruikers snel lager (Huttink & Mekenkamp, 2011). Huttink en Mekenkamp stellen verder dat het bij een regionaal initiatief zorg besteed moet worden aan het beleid rondom autorisaties, informed consent, privacy, veiligheid en het centraal bijhouden van alle transacties (=centrale logging). Hierbij is het goed om de wet van Metcalfe (de uitvinder van het etherenet) in het achterhoofd te houden. Hij stelt dat de waarde van een netwerk kwadratisch toeneemt met het aantal gebruikers (Benson, 2010). Dus in andere woorden: als meer ziekenhuizen zich aansluiten bij een regionaal netwerk voor het uitwsisselen van medische gegevens hoe meer nut aan het netwerk kunnen worden ontleent.


pagina 87 van 131

6.6 Interoperabiliteitsproblemen van de afdeling Een analyse van de interoperabiliteitsproblemen die de afdeling ondervindt, heeft getoond dat de gerapporteerde problemen vergelijkbaar zijn met de problemen die andere afdelingen ondervinden. Tevens blijkt dat een deel van de problemen gedekt worden door ontwikkelde of de nog te ontwikkelen IHE integratieprofielen waarvan de use cases al wel op de wensenlijst staan. De afdeling radiotherapie van het VUmc zou een actieve rol kunnen spelen in het ontwikkelproces van integratieprofielen van de IHE. Deelname van de afdeling aan de activiteiten van IHE Nederland is een mogelijkheid. Een gezamenlijk initiatief vanuit het bestaande platform “ICT in de radiotherapie” zou te verkiezen zijn. Nagegaan zou moeten worden of voldoende interesse bestaat om een Nederlandse IHE-RO werkgroep op te richten. Het overwinnen van de interoperabiliteitsproblemen binnen de afdeling heeft niet alleen een positief effect op de patiëntenzorg. De functies “Onderwijs en opleiden” en “Onderzoek” zullen hier tevens van profiteren. Het geanonimiseerd kunnen exporteren van geanonimiseerde datasets is nu tijdrovend en is zodoende een struikelblok. Voor Interinstitutioneel onderwijs en deelname aan klinische trials is het uitwisselen van klinische gegevens essentieel. Bij de aanschaf van nieuwe apparatuur of software zou gelet kunnen worden op het feit of de ontwikkelde integratieprofielen van de IHE ondersteund worden. Zo dienen bij voorkeur door een nog aan te schaffen afdelings-PACS de profielen “Image fusion profile (FUS)” en “Image Registration (REG)” ondersteund te worden.

6.7 Beschouwing In hoofdstuk één werden vier niveaus van interoperabiliteit: technische, tactische, semantische en proces interoperabiliteit belicht. Tijdens dit onderzoek is gebleken dat technisch interoperabiliteit over het algemeen haalbaar is. Uiteraard dienen om dit te bereiken keuzes worden gemaakt en de benodigde architectuur te worden gebouwd. Een proces dat tijd, mankracht en de nodige investeringen vraagt. De grootste uitdaging zit hem echter in het komen tot tactische en semantische interoperabiliteit. De aanpasbaarheid van standaarden is een zwak punt. Deze vrijheid betekent namelijk flexibiliteit voor de fabrikant in de wijze waarop hij de betreffende standaard implementeert. Het nadeel hiervan is dat het ad-hoc oplossingen in de hand werkt en dat interoperabiliteit niet bereikt wordt. Om dit te bereiken moet gewerkt worden aan het verkrijgen van consensus over: “waar welke standaarden moeten worden ingezet”. De vier niveaus van interoperabiliteit kunnen de indruk wekken dat proces interoperabiliteit pas kan worden bereikt als semantische interoperabiliteit is bereikt. Echter proces of organisatorische interoperabiliteit kan ook gezien worden als de drijfveer voor het bereiken van de andere drie vormen van interoperabiliteit. Gemeenschappelijke doelen voor de verschillende actoren moeten eerst worden gesteld voordat interoperabiliteit kan worden nagestreefd. Interoperabiliteit is zodoende een lange termijn streven naar permanente structuren voor het bereiken van consensus tussen alle betrokken actoren. Het ronde tafel overleg tussen gebruikers en fabrikanten georganiseerd door de IHE zou hier een belangrijke rol kunnen spelen. Een actieve betrokkenheid van pagina 88 van 131


de gebruikers is daarbij essentieel om te komen tot het gewenste eindresultaat. Om intramurale interoperabiliteit mogelijk te maken zijn ook politieke en economische hobbels te overwinnen. Het nastreven, maar ook het ontbreken van interoperabiliteit kent een aantal ethische aspecten. Het nastreven van interoperabiliteit is het zoeken naar de balans tussen beschikbaarheid en vertrouwelijkheid en naar de balans tussen flexibiliteit en standaardisatie (Fernando & Dawson, 2009; Kluge, 2007). Een recent voorbeeld van de discussie tussen beschikbaarheid en vertrouwelijkheid waarbij de balans is doorgeslagen naar de vertrouwelijkheid is de al eerder genoemde discussie rond de wet op het EPD. Natuurlijk is het voor de patiënt belangrijk dat zijn privacy wordt gerespecteerd en dat zijn medische gegevens niet misbruikt worden. Als dit echter te veel wordt nagestreefd dan zal de uitwisseling van medische gegevens tussen zorgverleners niet mogelijk zijn. Dit zal de medische zorg van de patiënt niet ten goede komen. Zeker zal dit gelden bij acuut medisch ingrijpen en bij medisch complexe aandoeningen waar een interdisciplinaire aanpak vereist is. Het niet kunnen delen van informatie kan dan de kwaliteit van de zorg onder druk zetten en zelfs de veiligheid van de patiënt in gevaar brengen (Fernando & Dawson, 2009). In het zoeken naar de balans tussen flexibiliteit en standaardisatie gaat het om het vinden van de juiste balans tussen standaardisatie zonder dat dit leidt tot starheid. Is de standaard te vrij en kan te veel een eigen invulling aan de standaard worden gegeven dan ontstaat het gevaar op interoperabiliteitsproblemen (Louwerse, 2008). Bentzen stelt dat het vakgebied radiotherapie gekenmerkt wordt door snelle technologische ontwikkelingen (Bentzen, 2004). Als nieuwe technologische ontwikkelingen pas kunnen worden geïmplementeerd nadat de relevante standaarden hierop zijn aangepast kan dat een remmende werking hebben. Om een veilige implementatie van toekomstige ontwikkelingen in de gezondheidszorg mogelijk te maken zal deze balans gevonden moeten worden. Het is aan de verschillende betrokken partijen om invulling te geven aan deze problematiek. De overheid heeft als verantwoordelijkheid om de juiste randvoorwaarden te scheppen om dit mogelijk te maken, aan de gebruikers en de leveranciers de taak om te komen tot een algemeen geaccepteerde concensus.


pagina 89 van 131

pagina 90 van 131


7 Conclusie en aanbevelingen Conclusies •

Technisch interoperabiliteitsproblemen komen nog zelden voor. De huidige interoperabiliteitsproblemen begeven zich op het tactische en semantische vlak.

•

Om bij het oplossen van deze problemen niet te verzanden in ad-hoc oplossingen is een lange termijn visie noodzakelijk.

•

Voor de afdeling van het VUmc zijn geen grote interoperabiliteitsproblemen te verwachten bij hun groei naar een multi-locatie afdeling. Wel moet zorg besteed worden aan de verbinding tussen beide locaties, dit is een afweging tussen kosten en risico’s.

•

Op het moment maakt de afdeling radiotherapie nog gebruik van enkele papieren componenten, als op twee locaties gewerkt wordt zou dit problemen kunnen leiden dat de vereiste informatie niet op de juiste plaats beschikbaar is.

•

De interoperabiliteitsproblemen die de afdeling nu ondervindt zijn voor een groot deel gedekt door bestaande of nog te ontwikkelen profielen van de IHE.

Aanbevelingen aan de afdeling radiotherapie VUmc Ten aanzien van het werken op twee locaties: •

voor de papieren componenten zouden elektronische equivalenten ontwikkeld moeten worden;

•

nagegaan dient na te worden op welke wijze de redundant uitgevoerde verbinding tussen het VUmc en haar satellietlocatie in Hoorn het beste uitgevoerd kan worden;

•

in een standaard operating procedure zou geformuleerd moeten worden hoe gehandeld moet worden bij het wegvallen van de gehele verbinding tussen het VUmc en de satellietlocatie;

•

het VUmc zou aansluiting moeten zoeken bij regionale initiatieven om gegevensuitwisseling met het Westfries Gasthuis of andere ziekenhuizen van het Esperanz verband mogelijk te maken.

Ten aanzien van het versterken van interoperabiliteit in het geheel: •

de afdeling zou een actieve rol dienen te spelen bij de activiteiten van (de Nederlandse afdeling van) de IHE;

•

de afdeling zou dienen te onderzoeken op welke wijze de integratieprofielen van de IHE geimplementeerd zouden kunnen worden op de afdeling;

•

bij de aanschaf van nieuwe apparatuur gebruik te maken van de ontwikkelde IHEprofielen voor het definiëren van het pakket van eisen.

Conclusie en aanbevelingen

pagina 91 van 131

Ten aanzien van algmene aspecten: •

de vervaardigde UML-modellen zou de afdeling kunnen gebruiken om transparantie te krijgen in de activiteiten en verantwoordelijkheden van de verschillende professionals;

•

de toegangsautorisatie voor patiëntgegevens analyseren en hier beleid voor te formuleren.

Aanbevelingen IHE •

de IHE zou zich meer moeten profileren naar de Nederlandse radiotherapie afdelingen om een grotere participatie te bewerkstelligen;

•

het domein Radiation Oncology van de IHE zou stringenter moeten zijn in de naamgeving van de ontwikkelde integratieprofielen.

Aanbeveling ten behoeve van het platform “ICT in de radiotherapie •

het platform “ICT in de radiotherapie” zou na moeten gaan hoe haar leden dan wel hoe het platform als geheel een actieve bijdrage kan leveren aan het ontwikkelproces van de IHEintegratieprofielen voor het domein Radiation Oncology.

pagina 92 van 131


Literatuurlijst Abdel-Wahab, M., Rengan, R., Curran, B., Swerdloff, S., Miettinen, M., Field, C., et al. (2010). Integrating the healthcare enterprise in radiation oncology plug and play--the future of radiation oncology? Int J Radiat Oncol Biol Phys, 76(2), 333-336. Banfai, B., Ulrich, B., Torok, Z., Natarajan, R., & Ireland, T. (2009). Implementing an HL7 version 3 modeling tool from an Ecore model. Stud Health Technol Inform, 150, 157-161. Bekkum, M. v., & Verhoosel, J. (2009). Inventarisatie ICT-standaarden voor Zorg Op Afstand in de Cure (No. 35197): TNO. Benson, T. (2007). Prevention of errors and user alienation in healthcare IT integration programmes. Inform Prim Care, 15(1), 1-7. Benson, T. (2010). Principles of Health Interoperability HL7 and SNOMED - The Book (First edition ed.). Londen: Springer. Bentzen, S. M. (2004). High-tech in radiation oncology: should there be a ceiling? Int J Radiat Oncol Biol Phys, 58(2), 320-330. Bentzen, S. M. (2005). Radiation therapy: intensity modulated, image guided, biologically optimized and evidence based. Radiother Oncol, 77(3), 227-230. Boeije, H. (2005). Analyseren in kwalitatief onderzoek (Vol. 1e druk). Den Haag: Lemma uitgevers. Bosch, W., Curran, B., & Swedloff, S. (2010). IHE-RO: Interoperable Data Standards for Radiation Oncology. Paper presented at the ICRR 2010, Amsterdam. Bosman, E.-J., & Raghoebier, S. (2009). Internship report - Radiotherapy. University of Amsterdam, Amsterdam. Brian, S. (2010, 29-10-2011). Radiation Oncology Workflow Exchange with HIS. Retrieved 2-5-2011, 2011, from http://wiki.ihe.net/index.php?title=Radiation_Oncology_Workflow_Exchange_ with_HIS Brigl, B., Hubner-Bloder, G., Wendt, T., Haux, R., & Winter, A. (2005). Architectural quality criteria for hospital information systems. AMIA Annu Symp Proc, 81-85. Channin, D. S. (2001). Integrating the Healthcare Enterprise: a primer. Part 2. Seven brides for seven brothers: the IHE integration profiles. Radiographics, 21(5), 1343-1350. Channin, D. S., Parisot, C., Wanchoo, V., Leontiev, A., & Siegel, E. L. (2001). Integrating the Healthcare Enterprise: a primer: Part 3. What does IHE do for ME? Radiographics, 21(5), 1351-1358. Ciottl, V. (2010). Generation HL7. Of the 15 founding fathers of HL7, just one remains today, leaving many to question whether interoperability is attainable. Healthc Inform, 27(1), 48. Clunie, D. A. (2009). Medical Image Format FAQ. Retrieved 9-9, 2009, from http://www.sph.sc.edu/ comd/rorden/dicom.html Curran, B. (2007, 4-4-2011). IHE - Radiation Oncology. Retrieved 5-5-2011, 2011, from http://wiki.ihe. net/index.php?title=Radiation_Oncology Dicom validation toolkit. (2010). Retrieved 4-6, 2011, from http://www.dvtk.org/modules/wiwimod/ index.php?page=DVTk&cmenu=home E-health in zicht. (2002). Zoetermeer: Raad voor Volksgezondheid en Zorg. Englebardt, S. P., & Nelson, R. (2002). Health Care Informatics - an interdisciplinairy approach. St. Louis, Missouri: Mosby. Eriksson, H.-E., & Penker, M. (2000). Business Modeling with UML. In T. Hudson (Eds.), Business PatConclusie en aanbevelingen

pagina 93 van 131

terns at Work Fernando, J. I., & Dawson, L. L. (2009). The health information system security threat lifecycle: an informatics theory. Int J Med Inform, 78(12), 815-826. Field, C. (2007, 3-10-2010). IHE-RO Use case Anonymization. Retrieved 5-5-2011, 2011, from http:// wiki.ihe.net/index.php?title=IHERO_UseCase_Anonymization Henderson, M. (2007). HL7 Messaging (Second edition ed.): OTech Inc. Henderson, M., Behlen, F. M., Parisot, C., Siegel, E. L., & Channin, D. S. (2001). Integrating the healthcare enterprise: a primer. Part 4. The role of existing standards in IHE. Radiographics, 21(6), 1597-1603. HIMMS. (2005). Interoperability definition and background: HIMMS. Hoogendoorn, S. (2010). Pragmatisch modelleren met UML 2.0 (10e druk ed.). Amsterdam: Pearson eduction. Hutjes, J. (2000). De casestudy als strategie in het toegespast onderzoek. In F. Wester, A. Smaling & L. Mulder (Eds.), Praktijkgericht kwalitatief onderzoek. Bussum: Cothino. Huttink, H., & Mekenkamp, H. (2011). Digitale beelduitwisseling in de regio’s. De stand van zaken. In Nictiz (Ed.). Den Haag: Nictiz. IHE Radiation Oncology test tool. (2010). Eindhoven: Humiq. IKA. (2009). Videoconferencing verantwoording algemene ziekenhuizen. Amsterdam: Integraal Kankercentrum Amsterdam. Image Fusion (FUS) Integration profile. (2006). Integrating the Healthcare Enterprise. Image Registration (REG) Integration Profile. (2007). Integrating the Healthcare Enterprise. Jong de, A., Vandenbroele, H., Glorieux, M., Maesschalk, L., & Visser, M. (2008). Inleiding wetenschappelijk onderzoek voor het gezondheidsonderwijs (Derde druk ed.). Maarssen: Elsevier gezondheidszorg. Knaup, P., & Dickhaus, H. (2009). Perspectives of medical informatics: advancing health care requires interdisciplinarity and interoperability. Special topic on the occasion of the 35th anniversary of the Heidelberg/Heilbronn curriculum of medical informatics. Methods Inf Med, 48(1), 1-3. Kluge, E. H. (2007). Secure e-Health: managing risks to patient health data. Int J Med Inform, 76(5-6), 402-406. Law, M. Y., & Liu, B. (2009). Informatics in radiology: DICOM-RT and its utilization in radiation therapy. Radiographics, 29(3), 655-667. Louwerse, K. (2008). Hoe kunnen we elkaar blijven begrijpen in de zorgsector? In S. Zwienink & P. Wisse (Eds.), Eerlijk zullen we alles delen - verkenningen naar interoperabiliteit: GBO.Overheid / Forum standaardisatie. NEMA. (2008). Part 3: Information Object Definitions. Rosslyn, Virginia: National Electrical Manufacturers Association. Object gericht denken. (2010). (Vijfde editie ed.): Capgemini Educational services B.V. Oosterwijk, H. (2005). DICOM Basics (Third edition ed.). Aubrey TX: O’tech Inc. Paterson, G. (2003, 23 november 2003). HL7 V3 and the Flow of Health Information. Introduction to HL7 Retrieved 10-11-2011, 2011, from http://healthinfo.med.dal.ca/hl7intro/963/1027/1027. html Pluis, R. (2005). Het ISO-OSI‐model en het TCP/IP-‐protocol in hoofdlijnen. Firewalls (pp. 19-33): Platform informatiebeveiliging.

pagina 94 van 131


Radiotherapy risk profile. (2008). Geneva: World Health Organization. Seelentag, W. (2003, 13-6-2003). Educational course on DICOM RT. Retrieved 30-11, 2009, from http:// www.sgsmp.ch/sem03a-e.htm#program Siegel, E. L., & Channin, D. S. (2001). Integrating the Healthcare Enterprise: a primer. Part 1. Introduction. Radiographics, 21(5), 1339-1341. Stap, R., & Verhoosel, J. (2007). De Europese norm EN 13606 (No. 035.31927/01.01). Den Haag: TNO. Technical Framework. (2008). Integrating the Healthcare Enterprise. Unified Modeling Language. (2010). (Vijfde editie ed.): Capgemini Educational services B.V. Verhoeven, N. (2010). Onderzoeken doe je zo. Den Haag: Lemma uitgevers. Verschuren, P., & Doorewaard, H. (2000). Het ontwerpen van een onderzoek (Derde druk ed.). Utrecht: Lemma b.v. Vries, R. d., & Vleeschhouwe, B. d. (2010). Internship - Department of Obstetrics & Gynaecology. University of Amsterdam, Amsterdam. Wallis, J. (2006). PET/CT Image fusion headed for PACS. Warmer, J., & Kleppe, A. (2008). Praktisch UML (Vierde editie ed.). Amsterdam: Pearson Education. Wendt, T., Haber, A., Brigl, B., & Winter, A. (2004). Modeling Hospital Information Systems (Part 2): using the 3LGM2 tool for modeling patient record management. Methods Inf Med, 43(3), 256-267. Wiggins, R. H., 3rd, Davidson, H. C., Harnsberger, H. R., Lauman, J. R., & Goede, P. A. (2001). Image file formats: past, present, and future. Radiographics, 21(3), 789-798. Winter, A., Brigl, B., Funkat, G., Haber, A., Heller, O., & Wendt, T. (2005). 3LGM(2)-Modelling to Support Management of Health Information Systems. Stud Health Technol Inform, 116, 491-496. Winter, A., Brigl, B., Funkat, G., Haber, A., Heller, O., & Wendt, T. (2007). 3LGM2-modeling to support management of health information systems. Int J Med Inform, 76(2-3), 145-150. Winter, A., Brigl, B., & Wendt, T. (2001). A UML-based ontology for describing hospital information system architectures. Stud Health Technol Inform, 84(Pt 1), 778-782. Winter, A., Brigl, B., & Wendt, T. (2003). Modeling hospital information systems. Part 1: The revised three-layer graph-based meta model 3LGM2. Methods Inf Med, 42(5), 544-551. Zwienink, S. (2008). Eerlijk zullen we alles delen. In S. Zwienink & P. Wisse (Eds.), Eerlijk zullen we alles delen - verkenningen naar interoperabiliteit: GBO.Overheid / Forum standaardisatie.


pagina 95 van 131

pagina 96 van 131


Bijlage 1: Nederlandse vragenlijst

pagina 97 van 131

pagina 98 van 131

pagina 99 van 131

pagina 100 van 131

pagina 101 van 131

pagina 102 van 131

pagina 103 van 131

pagina 104 van 131

pagina 105 van 131

pagina 106 van 131

Bijlage 2: Engelse vragenlijst

pagina 107 van 131

pagina 108 van 131

pagina 109 van 131

pagina 110 van 131

pagina 111 van 131

pagina 112 van 131

pagina 113 van 131

pagina 114 van 131

pagina 115 van 131

pagina 116 van 131

Bijlage 3: Interview protocol Achtergrond De afdeling radiotherapie van het VUmc in Amsterdam zal in 2012 een satelliet afdeling bij het Westfries Gasthuis in Hoorn openen. In opdracht van de afdeling radiotherapie van het VU medisch centrum wordt onderzoek gedaan naar interoperabiliteitsproblemen. Het is voor de afdeling onduidelijk op welke wijze zij het best deze interoperabiliteitsproblemen in de toekomst kan voorkomen. De afdeling ervaart al de nodige problemen, maar zij verwacht door de opening van de satelliet afdeling een toename hiervan. Het onderzoek wordt uitgevoerd door Jelle Scheurleer in het kader van zijn master thesis onderzoek. Jelle Scheurleer heeft geen rol als belanghebbende in dit onderzoek. Het interview maakt deel uit van het algemeen explorerende deel van het onderzoek. Voor het interview is aan alle afdelingen radiotherapie in Nederland een vragenlijst verstuurd. Door middel van de vragenlijst is een beeld gekregen van de complexiteit van de afdelingen, de interoperabiliteitsproblemen die de afdeling ervaren en de strategieën die afdelingen gebruiken in het ondervangen van de problemen die zij ervaren. De onderzoeksvragen van dit deel zijn: 1. Welke interoperabiliteitsproblemen zijn actueel voor afdelingen radiotherapie? 2. Welke strategieën worden afdelingen gebruikt om interoperabiliteitsproblemen te voorkomen? 3. Welke afdelingen radiotherapie maken een vergelijkbare ontwikkeling door als de afdeling radiotherapie van het VUmc en wat kan van hun aanpak geleerd worden? 4. Welke afdelingen radiotherapie in het buitenland lopen voorop in de aanpak van interoperabiliteitsproblemen en kunnen een voorbeeld zijn voor de afdeling radiotherapie van het VUmc? Van de 21 afdelingen radiotherapie zijn vijf afdelingen geselecteerd voor het afnemen van een interview. Dit zijn de volgende afdelingen: • Universitair Medisch Centrum Nijmegen St. Radboud, Nijmegen (UMCN) • Algemeen Medisch Centrum, Amsterdam (AMC) • Verbeeten Instituut, Tilburg • Erasmus Medisch Centrum, Rotterdam (ErasmusMC) Het AMC, het Verbeeten Insituut, het ErasmusMC zijn geselecteerd door hun ervaring met het werken op meerdere locaties. Het UMCN is geselecteerd vanwege het feit dat zij haar zorgproces heeft laten modelleren.

pagina 117 van 131

Doel van het interview Het doel van het interview is tweeledig: • het levert informatie op die voor de opdrachtgever relevant is om zijn voornemen tot het opzetten van de satelliet afdeling verder te concretiseren en maatregelen te nemen om interoperabiliteitsproblemen te voorkomen. • het levert informatie op die voor de onderzoeker van belang is om te bepalen welke beleving • professionals hebben bij interoperabiliteitsproblemen en hoe deze op lange termijn voorkomen zouden moeten worden.

Werkwijze per interview Het interview zelf bestaat uit vier onderdelen: 1. Kennismaking interviewer–geïnterviewde ◊ Kort voorstellen ◊ Doel van het project uitleggen ◊ Toestemming opname van het gesprek ◊ Toestemming tot openbaarheid 2. Inhoud interview ◊ Deel 1: Verduidelijking reactie enquête ◊ Deel 2: vragen op het gebied van het werken op twee locaties, interoperabiliteitsproblemen, strategie en de rol van IHE. 3. Afsluiting

Kennismaking Mijn naam is Jelle Scheurleer in het kader van mijn master studie “Radiation Oncology” aan de Hogeschool Inholland voer ik een onderzoek uit naar interoperabiliteitsproblemen binnen het vakgebied radiotherapie. De afdeling radiotherapie van het VUmc is opdrachtgever in dit onderzoek. Ik zal u een aantal vragen stellen. Wanneer er wordt overgegaan naar een ander onderwerp zal dit worden vermeld. De tijd die voor het interview is uitgetrokken is ongeveer één uur. Ik zal even uitleggen hoe dit interview zal verlopen. Ik zal een aantal vragen stellen over …. . Het gaat hierbij om uw persoonlijke mening. Verkeerde of foute antwoorden zijn dan ook niet mogelijk: het gaat om wat u ervan vindt. Neemt u rustig de tijd die u nodig vindt om de vragen te beantwoorden. Voelt u zich vooral vrij om uit te weiden. Als er onderwerpen zijn die voor u belangrijk zijn, maar die voor uw gevoel niet of onvoldoende aan bod zijn gekomen, dan bent u van harte welkom om dat tevens te vertellen. Voor de verwerking van de resultaten wil ik dit interview graag opnemen. Heeft u hier bezwaar tegen? Indien u tijdens het interview zaken ter sprake brengt die vertrouwelijk zijn, zou ik u willen vragen dat kenbaar te maken. Dat kunt u tijdens het gesprek doen of na afloop van het gesprek.

pagina 118 van 131

Na het interview zal ik van het interview een verslag maken en dat aan u opsturen. U kunt dan eventueel nog aanvullingen of commentaar geven. Om de gegevens die in het interview aan bod komen te kunnen gebruiken in mijn onderzoeksverslag zou ik graag u toestemming willen. Hiervoor zal ik zal een verklaring bij het verslag van het interview bijvoegen. Ik zou u willen vragen om deze te ondertekenen en terug te sturen indien u akkoord gaat.

Opname en verslaglegging van het interview Indien toestemming wordt gegeven dan wordt het interview opgenomen. Van elk interview wordt een verslag gemaakt waarin in elk geval wordt vermeld: • de namen van de aan- en afwezige leden; • de namen en functies van eventuele andere aanwezigen; • een zakelijke weergave van het besprokene. Na het afsluiten van het onderzoek worden de opnames vernietigd.

Openbaarheid Vertrouwelijkheid Met informatie die niet nadrukkelijk openbaar is, wordt vertrouwelijk omgegaan. Indien een respondent hier uitdrukkelijk toestemming voor geeft door middel van een ondertekende verklaring, wordt de inhoud gebruikt voor het onderzoeksverslag. Als de respondent geen toestemming geeft dan mogen de resultaten niet terug te voeren zijn tot de persoon of het instituut.

Interview vragen Deel 1: Verduidelijking enquête Dit deel wordt ingevuld afhankelijk van het te bezoeken instituut. Een exemplaar van de respons wordt op papier mee genomen en wordt doorgenomen. Vragen die verduidelijking behoeven worden tijdens de voorbereiding gemarkeerd. Deel 2: Verdieping Het werken op twee locaties (indien van toepassing) 4. Welke werkzaamheden worden uitgevoerd op de andere locatie. 5. Hoe zorgt u voor voldoende deskundigheid op de tweede locatie. 6. Is er een klinisch fysicus aanwezig op de andere locatie? 7. Hoe wordt omgegaan met problemen tijdens een bestralingssessie? 8. Welke problemen in het zorgproces bent u tegengekomen? 9. Heeft u een noodprocedure wanneer connectiviteit tussen de twee locaties verloren is? 10. Beschikt u over de mogelijkheid voor videoconferencing? ◊ Waarom wel/ waarom niet? ◊ Waarvoor wordt de verbinding gebruikt? ◊ Hoe is dit vorm gegeven 11. Hoe waarborgt u dat gegevens van een patiënt op de juiste plaats beschikbaar zijn? 12. Hoe is de netwerkverbinding tussen beide locaties geregeld? 13. Is er een fysieke verbinding tussen het netwerk van Ziekenhuis [A] en Ziekenhuis [B]? 14. Zo ja? Hoe is de veiligheid gewaarborgd van patiëntengegevens? 15. Patiënt identificatie hoe is die geregeld?

pagina 119 van 131

16. Heeft u het zorgproces gemodelleerd? ◊ Zo ja: Waarom heeft u dat gedaan? ◊ Hoe heeft u het gedaan? Wie? Welke taal? Wat wel / wat niet? ◊ Wat heeft het opgeleverd? ◊ Heeft u kwetsbaarheden kunnen identificeren? Kunt u een voorbeeld hiervan geven? ◊ Zo nee: Waarom heeft u het niet gedaan? ◊ Heeft u behoefte hier aan? Interoperabiliteitsproblemen 17. Verduidelijken van de interoperabiliteitsproblemen. 18. Welke interoperabiliteitsproblemen verstoren het gewenst proces het meest 19. Hebben interoperabiliteitsproblemen in het verleden geleidt tot kwaliteitsbreuken, bijnafouten of fouten? 20. Zo ja, kunt u concrete voorbeeld beschrijven? 21. Uit de enquête die ik gehouden heb komen nog al wat DICOM-RT gerelateerde interoperabiliteitsproblemen. 22. Ervaart u of heeft u die problemen ook ervaren? 23. Wat zou naar uw mening moeten gebeuren om deze problemen echt op te lossen? 24. Uit de enquête die gehouden is, komen nog al wat interoperabiliteitsproblemen tussen de koppeling van tussen RT-systemen en het ZIS 25. Ervaart u of heeft u die problemen ook ervaren? 26. Wat zou naar uw mening moeten gebeuren om deze problemen echt op te lossen? Strategie 27. Welke strategie hanteert u bij het voorkomen van interoperabiliteitsproblemen? 28. Welke strategie hanteert u bij het oplossen van interoperabiliteitsproblemen? 29. Werken de strategieën voor uw afdeling? 30. Zou u uw mening willen geven over de volgende stellingen 31. “Single-vendor zijn helpt interoperabiliteitsproblemen te voorkomen” 32. Zou u uw mening willen geven over de volgende stellingen: 33. “Standaarden helpen om interoperabiliteitsproblemen te voorkomen” Integrating the Healthcare Enterprise 34. In hoeverre bent u bekend met de IHE 35. Wat is in uw ogen de werkwijze van de IHE 36. Is de werkwijze van de IHE in uw ogen succesvol 37. Hoe komt dat? 38. Wat zou aan de werkwijze van de IHE verbeterd kunnen worden? 39. Uw afdeling is [wel/niet] betrokken bij de IHE. Waarom is dat zo? 40. Achterstand radiotherapie ten opzichte van radiologie,

pagina 120 van 131

Afsluiting 41. Ik interview respondenten van vijf afdelingen in Nederland en een aantal expert uit het bedrijfsleven en van de IHE. Is er iemand waarvan u vindt dat ik hem zeker zou moeten uitnodigen voor een interview? 42. Zijn er nog vragen die u verwacht had, maar die ik niet gesteld heb?

pagina 121 van 131

pagina 122 van 131

Bijlage 4: Activiteitsdiagram “Voorbereiding” Huidige situatie

pagina 123 van 131


pagina 124 van 131

Bijlage 5: Activiteitsdiagram “uitvoering” Huidige situatie

pagina 125 van 131


pagina 126 van 131

Bijlage 6: Het 3LGM2-model - de domeinlaag

pagina 127 van 131

pagina 128 van 131

Bijlage 7: Het 3LGM2-model - de applicatielaag

pagina 129 van 131

pagina 130 van 131

Bijlage 8: Het 3LGM2-model - de fysieke laag

pagina 131 van 131

INTEROPERABILITEIT IN RADIOTHERAPIE. Hogeschool Inholland. Jelle Scheurleer juni 2011

Recommend Documents