In de serie eHealth op de werkvloer spreekt SmartHealth met zorgprofessionals die dagelijks te maken hebben met eHealth toepassingen. Veel van die technologische innovaties betekenen op papier efficiënter werken, kwaliteitsverbetering of kostenverlaging. Maar in de praktijk zijn er vaak genoeg obstakels te overwinnen. Een kwestie van tussen droom en daad? Deze week: John van den Dobbelsteen, onderzoeksleider van digitale operatieassistent DORA op de TU Delft.
“Op onze afdeling Biomechanical Engineering ontwikkelen we medisch instrumentarium. Daarvoor moet je ook weten hoe het er aan toegaat in de OK. Dat was de reden om in 2007 met Emiel Verdaasdonk als promovendus een observatiestudie te doen in de OK.
"Dat kost zoveel tijd, we moeten al zoveel papierwerk doen"
We kwamen erachter dat er van alles mis ging met de apparatuur. Vaak heel praktische zaken, zoals de afwezigheid van een bepaald instrument of het ontbreken van een juiste aansluiting. Om dit voor te zijn – en zo het aantal incidenten rondom foutieve OK processen te verminderen – vroegen we de omloop (assistenten) om met potlood een papieren checklist af te lopen en zo binnen 2 minuten de OK te controleren op de belangrijkste onderdelen."
"Dat stuitte op veel weerstand van hun kant: dat kost zoveel tijd, we moeten al zoveel papierwerk doen. Een beetje overdreven, maar ze hadden er duidelijk geen zin in. Toen zijn we bij onszelf te rade gegaan: wij zijn een technische universiteit, kunnen we geen automatische checklist ontwikkelen? Die van te voren de OK controleert en aan het personeel een seintje geeft als er iets niet in orde is? Een leuk idee, maar de uiteindelijke realisatie bleek een stuk ingewikkelder.” Aan het woord is John van den Dobbelsteen, hij is vanuit de TU in Delft betrokken als onderzoeksleider voor de digitale operatieassistent DORA (Digital Operating Room Assistant). De zwarte doos in een vliegtuig, daar is DORA mee te vergelijken.
Van twee walletjes eten
“In 2009 kregen we een subsidie van de overheid in het kader van maatschappelijk verantwoord innoveren. Daarmee hebben we een kleine start gemaakt in ons onderzoek of het makkelijk en toegestaan is om door middel van camera’s van alles te registeren in de OK. Dat viel tegen: wij hadden onderschat hoe hinderlijk men de camera’s zou vinden. Ook allerlei privacy issues kwamen opeens naar boven.”
In 2010 krijgt het onderzoeksteam nog een grote subsidie van de provincie Zuid-Holland. Dat geld wordt gebruikt om te zien wat voor sensoren of technologieën ingezet zouden kunnen worden om automatisch activiteiten op de OK te registeren, vertelt Van den Dobbelsteen. “Eigenlijk zou je zeggen dat het door onze combinatie van zorg en techniek gemakkelijk is om financiering te krijgen,
"Je zou denken dat het makkelijk is om financiering te krijgen, maar het tegendeel blijkt waar te zijn"
we kunnen immers van twee walletjes eten. Het tegendeel blijkt waar te zijn. In Nederland heb je ZonMW als grote subsidieverstrekker in de zorg en STW als subsidievertrekker in de technologie. ZonMW geeft graag subsidie aan partijen die patiëntgebonden onderzoek doen, bijvoorbeeld naar de ontwikkeling van medicijnen voor kanker, maar niet voor technologieontwikkelingen om OK processen beter te maken. STW geeft subsidie voor allerlei high tech ontwikkelingen, maar een sensor die ook al in kleding wordt gebruikt is niet echt high tech. Daar vallen we dus ook buiten de boot. We praten inmiddels ook wel met zorgverzekeraars, die hebben er namelijk wel baat bij als de zorg efficiënter wordt en er minder fouten worden gemaakt. Maar dat zit nog in de verkenningsfase.”
Project DORA: een kruising tussen zorg en techniek (foto: Flickr Ruhrfisch)
Uit de subsidie van de provincie Zuid-Holland in 2010 komen drie projecten voort bij het Reinier de Graaf ziekenhuis in Delft, Het Oogziekenhuis Rotterdam en het LUMC in Leiden. De ziekenhuizen betalen de ontwikkelingskosten voor de digitale operatieassistent deels zelf. “Alle drie hebben ze een verschillend accent en kijken ze naar een ander deel van het operatie-traject. Bij Reinier de Graaf ligt de focus op de apparatuur, in het Oogziekenhuis op de patiënten en in het LUMC zijn we aan de slag gegaan met het exact monitoren van het verloop van de operatie. Alle drie de zaken zijn belangrijk om een systeem op te zetten dat het hele operatieve traject kan volgen, monitoren en vellig maken, maar we kunnen niet met drie trajecten tegelijkertijd aan de slag. De naam DORA is gaandeweg dus meer een algemene noemer geworden voor deze activiteiten. Uiteindelijk hopen we dat alles geïntegreerd wordt in één systeem.”
RFID tags en sensoren in de OK
In het Reinier de Graaf ziekenhuis is de geautomatiseerde checklist in ontwikkeling. Is de infuus pomp aanwezig? En is de onderhoudscyclus daarvan nog up-to-date? Dat zijn dingen die een arts voor iedere operatie zelf moet controleren, door op een sticker op het apparaat te kijken. In de praktijk gebeurt dat volgens Van den Dobbelsteen te weinig. “Met een systeem waarbij alle apparaten in de OK voorzien zijn van een RFID tag – zoals het alarmsysteem van kleding in een winkel – kan er gecontroleerd worden of een apparaat aanwezig is in de OK. En door een koppeling met het onderhoudssysteem van het ziekenhuis wordt ook direct zichtbaar of er recente incidenten gemeld zijn en of de problemen zijn opgelost.”
RFID via Wired
In het Oogziekenhuis ligt de focus op de patiëntenstroom. Jaarlijks worden er zo’n 40.000 staaroperaties uitgevoerd in het Rotterdamse ziekenhuis, een routine ingreep die zo’n twintig minuten in
"De ingreep zelf duurt 20 minuten, maar patiënten zijn minimaal 5 uur in het ziekenhuis aanwezig"
beslag neemt, slechts drie man personeel en een beperkte hoeveelheid apparatuur nodig heeft. Op dat vlak valt er weinig winst te behalen. “Hoewel de ingreep een paar minuten duurt, spendeert een patiënt zo’n vijf uur in het ziekenhuis. Omkleden, wachten, lokale anesthesie. Tussen al die stappen gaat veel tijd verloren: het werkt inefficiënt als het personeel hun patiëntenstromen niet goed op elkaar kan afstemmen. Daarom testen we met RFID aan een polsbandje, waarmee we op een scherm zichtbaar maken welke patiënt zich waar bevindt en waar ze naartoe gebracht kunnen worden: onderlinge telefoontjes hoeven zo niet meer te worden gepleegd. Daar zit voor het Oogziekenhuis dus het rendement.”
Foute OK planning
Bij het LUMC ligt dat weer ergens anders. In een academisch ziekenhuis worden vaak complexe operaties gedaan, die qua tijdsbestek lastig te voorspellen zijn. ’s Ochtends wordt er ingepland hoe lang een operatie – volgens de behandeld arts – zal duren en daar wordt de rest van de planning op gebaseerd. “Maar artsen kunnen zichzelf best overschatten, wij zien in de praktijk dat de operatieduur bijna altijd langer is dan wat er van te voren wordt geschat. Die OK planning is dus eigenlijk aan het begin van de dag al verkeerd. Er zijn 25 OK’s, alle patiënten zijn verschillend en zelfs standaardoperaties kunnen uiteindelijk toch minder standaard uitpakken. Dit alles zorgt ervoor dat de planner van OK naar OK moet rennen om te kijken wie hoe lang nog bezig is en zijn planning constant aan moet passen aan de nieuwe situatie: een hectische taak en een hels karwei.”
Dus wordt een onderdeel van DORA in het LUMC ingezet om het verloop van de operatie te registeren. Dit gebeurt onder andere door bij te houden welke instrumenten er worden gebruikt.
"De OK-planning loopt soms aan het begin van de dag al achter"
Een apparaat om bloedvaten dicht te branden wordt bijvoorbeeld vaak in een bepaalde fase van een specifieke operatie gebruikt. “Al die apparaten maken geluid, een heel specifiek toontje, en dat registeren wij met een microfoon. Zo kunnen wij precies detecteren welk apparaat er op dat moment in gebruik is. Afhankelijk van de operatie stellen we vervolgens vast dat dat specifieke apparaat normaal zo’n 30 minuten voor het einde van de operatie gebruikt wordt – en zo kan het team van de volgende operatie een seintje krijgen.”
DORA in het Reinier de Graaf Ziekenhuis
In een OK in het LUMC zijn inmiddels verschillende sensoren geplaatst, waardoor een microfoon, een lichtsensor – het licht gaat tijdens een operatie soms uit als informatie van een videobeeld gehaald wordt – en een sensor om de blauwe doek te detecteren die over de patiënt ligt. Deze sensoren staan 24 uur aan en verzamelen dus constant relevante informatie. “Deze informatie moeten wij vervolgens registeren, zodat wij op den duur precies kunnen bepalen welke trigger – geluid of licht of allebei – de beste voorspeller is voor het einde van de operatie en wat de betrouwbaarheid is daarvan.”
Verouderde ziekenhuisinformatiesystemen
Van den Dobbelsteen noemde het al eerder: al tijdens de eerste onderzoeken kwam naar voren dat privacy een obstakel vormde in de ontwikkeling van DORA. “Patiënten hebben geen problemen met een camera in de OK – ze liggen toch volledig afgedekt – maar artsen vinden het wel vervelend. Weinig mensen vinden het leuk om een camera op zich gericht te krijgen tijdens het werk, maar in de zorg en specifiek in die OK setting gaat dat nog wel verder. Er komen nog steeds regelmatig berichten naar buiten dat er doden vallen door onnodige fouten. Hoewel het 9 van de 10 keer een samenloop van ongelukkige omstandigheden is en niet één iemand de schuld heeft, kun je wel worden vervolgd worden voor zo’n sterfgeval. Die camera idee creëert wel wat weerstand.”
Ook de uiteenlopende informatiesystemen van de ziekenhuizen werken niet bevorderlijk. “De OK planning wordt gedaan met een product van leverancier X, voor het monitoren van de
"De dokter, de technische dienst en assistenten: we hebben met veel verschillende mensen en afdelingen te maken"
onderhoudsstatus van de apparatuur wordt weer een ander softwarepakket gebruikt. Die systemen zijn niet aan elkaar gekoppeld, terwijl dat voor ons vaak wel noodzakelijk is. Het komt erop neer dat de huidige infrastructuur van ziekenhuizen verouderd en nog niet gestandaardiseerd is en dat staakt de implementatie van onze projecten wel. Gelukkig loopt het wel een beetje samen op: ziekenhuizen die een nieuw systeem aanschaffen willen wel dat het praat met DORA, dus in zekere zin stimuleert ons project weer een beetje die standaardisatie.”
De langdurige en intensieve testen die het onderzoeksteam uit moet voeren voordat de sensoren eindelijk binnengebracht kunnen worden in de OK is volgens Van den Dobbelsteen ook een uitdaging. Tenslotte noemt hij de betrokkenheid van zoveel verschillende afdelingen en zorgprofessionals. “Wij hebben niet alleen te maken met de dokter, maar ook de technische dienst, de verpleegkundigen, assistenten op de OK, sterilisatiedienst; je komt in aanraking met zo’n beetje elke afdeling in het ziekenhuis en ze hebben allemaal wel iets te zeggen. Het is niet zo dat één afdeling de baas is over de andere, dus je moet ook nog eens flink lobbyen om iedereen te enthousiasmeren en te overtuigen van het nut van het project voor hun eigen activiteiten.” Wel helpt het volgens Van den Dobbelsteen als je binnen het ziekenhuis een persoon met aanzien hebt die als een soort ambassadeur voor je kan optreden. “Bij het LUMC hebben we al jaren goed contact met gynaecoloog Frank Willem Janssen. Hij is daar ook echt de kartrekker van ons project.”
Een nog slimmere DORA
Het onderzoeksteam praat regelmatig met andere ziekenhuizen, zoals het Erasmus MC, Sint Antonius en het UMC Utrecht, omdat zij ook graag pilots willen doen met OK monitoring. Daarnaast worden de bestaande projecten verder uitgebreid, met bijvoorbeeld een just in time delivery service in het Reinier de Graaf ziekenhuis, een app om wachtende familieleden op de hoogte te houden in het Oogziekenhuis en voor het nog nauwkeuriger meten van processen in het LUMC.
"We zijn blij dat we nu al op een paar plekken data mogen verzamelen"
Op den duur moet Dora nog veel meer functionaliteiten krijgen, want Van den Dobbelsteen wil dat de operatie assistent nog slimmer wordt. “We hopen met ons systeem de operatie straks zo goed te kunnen volgen, dat we ook automatisch kunnen registeren en een melding geven, dat er wordt afgeweken van het bedoelde proces waar door het onveilig wordt voor de patiënt. Daarvoor hebben we op dit moment alleen nog veel meer informatie nodig: als een dokter bewust – er zijn nu eenmaal veel variabelen – afwijkt van de standaardoperatie dan moeten wij geen alarm laten afgaan. We moeten nog veel meer informatie verzamelen. We zijn blij dat we al bij enkele ziekenhuizen onze systemen hebben mogen installeren zodat we daar data vandaan kunnen halen.
Alle afleveringen lezen van eHealth op de werkvloer? Klik dan op deze overzichtpagina
[accordion]
[acc title="Fotocredits:"]http://www.flickr.com/people/stmaartenpiloot/[/acc]
[/accordion]
wellicht ook interessant
Beste Marc,
Ten aanzien van standaarden kan ik een eind meegaan met je gedachten. Maar niet helemaal. Ten eerste gooi je e.e.a. op een grote hoop en ten tweede mis ik in je lijstje bepaalde typen standaarden.
Laten we beginnen te pogen e.e.a. te ontwarren. Ik ga bij discussies over standaarden uit van de volgende vijftrap:
1. Wetgeving, zoals Nederlandse wetten en Europese directives. Kern is: hier moet je je aan houden, maar vaak zijn ze erg abstract en vragen nadere regeling.
2. Normen. In allerlei (wettelijke) verdragen is vastgelegd dat normen op nationaal, Europees en internationaal niveau de aangewezen instrumenten zijn om de vaagheid en abstractie van wetten nader te regelen. Een norm heeft een maximale houdbaarheid van 5 jaar en wordt dan per definitie gereviseerd.
Doel van normen is om dus wetten nader in te kleuren of te regelen op basis van consensus.
Nadat een norm is vastgesteld - dus de afspraken na diverse stemronden zijn bevestigd - geldt dat een Nederlandse norm en een CEN norm per definitie voor Nederland geldig zijn. Er is nog wel enige vrijheid om soms niet aan een norm te voldoen, of om een equivalent te kiezen (Dit is bijvoorbeeld van toepassing bij NEN 7510 informatiebeveiliging in de zorg en ISO 27001).
Een essentieel gegeven bij een norm is dat een wetgever er expliciet naar kan verwijzen, zoals inderdaad naar de NEN 7510 in de Wet op het gebruik van het Burger Service Nummer in de zorg.
In het geval van NEN 7510 heb jij dus gewoon niets te kiezen, omdat we met zijn allen hebben afgesproken dat het BSN met alle veiligheidsmaatregelen moet worden bewaakt.
3. Standaarden. Je noemt er een aantal van officieel erkende standaardisatie organisaties zoals WHO (ICD-10, ICF), HL7 (HLv2, HL7 v3, EHR-S FM, CDA, FHIR) en een aantal clubs van vrijwilligers die gedreven een standaard bijhouden (zoals rondom HTML). De route van standaarden is soms iets sneller en deze houden in de regel (bv bij HL7) het drie jaar vol voor een herijking plaatsvindt.
4. Specificaties. Naast het beheer van standaarden zoals SnomedCT, beheert Nictiz een groot aantal specificaties van data, toegepaste codes, waardensets, templates, HL7 v3 implementatiegidsen, schema's etc. Dit zijn naar de letter van de materie op zichzelf geen standaarden (en zeker ook geen normen), maar wel specificaties op basis waarvan een collectie van standaarden voor een toepassing bij elkaar gebracht worden. En omdat hier met een aantal partners in het veld afspraken over worden gemaakt en bovendien er een nieuw label "informatie standaard" aan wordt gegeven, die bovendien ook nog eens gelegitimeerd wordt ontstaat een nieuw type standaard.
Dit wijst overigens op een ander aspect waar je aan voorbij gaat: een standaard komt nooit alleen. Ik kom daar zo op terug.
5. Ad hoc oplossingen. Hier verschillen we niet van mening. Een wet is vaak te vaag, een norm specificeert meer, een standaard biedt veel maar nooit alles en specificaties zijn altijd ontoerijkend voor alle use cases. Dan is het nog steeds mogelijk om een standaard te volgen om je aanvullingen te maken, hetgeen garandeert dat je ad hoc aanvulling in ieder geval op dezelfde manier kan worden gebruikt. Zo is de Detailed Clinical Model uitgevonden om hergebruik van domein 1 naar domein 2 te bevorderen, maar vooral om op een nagenoeg complete set specificaties nog net even
dat unieke stukje extra in te vullen. Een principe dat FHIR terecht heeft overgenomen van HL7 Patient Care in de Care Provision modellering.
Je snapt het al: ik denk dat je je een te grote mate van vrijheid toerekent in relatie met standaarden. Doordat je niet uit elkaar houdt wat wettelijk is geregeld (op basis van oplossingen voor problemen in het verleden waar we ook in de toekomst waarde aan zullen hechten), wat als standaard kan helpen om van elkaar te leren en gezamenlijk profiteren en welke ad hoc zaken wenselijk zijn, zou je mensen op het verkeerde been kunnen zetten. M.a.w. ja je moet je use case blijven bedienen. Maar pas wel op waar je van de norm of van de standaard gaat afwijken zonder een equivalent er naast te zetten.
Het tweede is dat je typen door elkaar haalt. Ik gebruik ook hier toevallig 5 soorten: zorginhoudelijke standaarden (richtlijnen) die zorgverleners richting geven aan hun handelen. Terminologieen die helpen om het potjeslatijn voor ieder begrijpelijk te krijgen, informatiemodellen die helpen om elektronische patienten dossiers, berichten etc goed te modelleren en maken, workflow die helpt om processen helder te krijgen, inclusies interacties zoals in ketenzorg en tot slot de technische standaarden zoals XML, HTML, (technische) beveiligingsmaatregelen.
Een standaard komt nooit alleen: de essentie is dat een concurrent gebruik goed wordt doordacht. En dat is normaliter mijn taak als informatie architect: de business (richtlijnen), processen, informatie en technologie zo stroomlijnen dat zoveel mogelijk use cases met zo precies mogelijke instrumenten tegen zo laag mogelijke kosten en toekomstvast worden bereikt. En willekeurig een use case uit zulk een stack trekken en voor een subdeel een mini oplossing realiseren kan voor het grote geheel grote gevolgen hebben. (Je kent vast de analogie van het verbouwen van een huis waar een draagbalk per ongeluk wordt verwijderd).
De kunst is dus vooral om de juiste normen, standaarden, specificaties te kiezen, te harmoniseren in een fatsoenlijke architectuur en de consistentie te bewaken. Ik volg Alexander dan ook helemaal met zijn gruwel ten aanzien van bedenk zelf wel wat. Hou vooralsnog overzicht op je architectuur en pas goed op met welke steen je uit het geheel haalt voor iets nieuws wat tot ongewisse resultaten kan leiden.
Leuk om te lezen hoe ik, werkend binnen het gemeentedomein, een medestander uit een ander domein vind. Dat standaarden nuttig en nodig kunnen zijn staat buiten kijf. Maar het is tenenkrommend om te zien hoe mensen, ook/juist zonder vakkennis, denken dat toepassen van standaarden per definitie de beste keuze is. Iets dat hardnekkig volgehouden wordt, zelfs in situaties waarin het falen daarvan overduidelijk is.
Al jaren geleden heb ik in een stukje beschreven hoe het me niet lukte om een complexe gemeentestandaard vereenvoudigd te krijgen (http://dienstgericht.tumblr.com/post/51167367131/standaardiseer-met-mate). Nu, jaren later, is de discussie hierover (gelukkig) opnieuw opgestart omdat gemeente Den Haag heeft geconstateerd dat toepassen van de standaard in zijn huidige vorm voor hen niet gaat werken.
Mijn "lessons learned" zijn dat het veel belangrijker is dat afspraken breed worden toegepast dan dat het met een mooie strik er omheen tot standaard is benoemd. Ondanks alle inspanningen en investeringen zijn SOAP en XML door REST en JSON rechts ingehaald. Gewoon omdat ze eenvoudiger en meer gebruikt zijn. En zo hoort het.
Klopt. Goede blog van je ook, trouwens.
Ben ook zijdelings betrokken geweest bij de overheid, ook de 'pas toe of leg uit' lijst (oppositie gevoerd tegen delen daarvan), en zeker, daar worden ook teveel complexe standaarden gestapeld zonder noodzaak. Wat leidt tot onnodige kosten. Helaas is zeker in overheidsland de rugdekking van 'het is toch een standaard' vaker belangrijker dan de efficiëntie en effectiviteit.