EPJ - Elektronisk Patientjournal   Home    English 

Uvis - lokal tilpasning   Anonymisering af en stor patientdatabase   EPIC anskaffelsen  

2003: Fyns Amt EPJ

I 2003 skulle Fyns Amt anskaffe et nyt EPJ-system. De havde hørt om task-metoden til at formulere krav - og fordelen fremfor use-cases, der ellers var på mode. Vi etablerede et samarbejdede, hvor jeg stod for datamodellen og task - de to centrale dele af kravene. Resultatet var en succes for Amtet. Desuden blev resultatet i 2007 fundamentet for SL-07, de problem-orienterede krav. SL-07 bruger netop et EPJ-system som gennemgående eksempel, men har tilføjet mange krav til 2003-udgaven: integrationskrav, svartidskrav, brugervenlighedskrav, forretningsmæssige mål, tildelingskriterier, mv. I en typisk SL-07 kravspecifikation er task og datamodel ca. halvdelen.

2005: IT arkitektur for EPJ - er principper nok?

Regeringen havde besluttet at de eksisterende 14 amter i 2006 skulle slås sammen til 5 regioner. Hvert amt havde sine egne hospitaler. Hvad skulle man gøre med hospitalerne i de nye regioner? I april 2005 udgav Amtrådsforeningens IT-arkitekturudvalg et skrift om Fælles arkitekturprincipper for EPJ (Elektroniske Patientjournaler). En række organisationer blev bedt om kommentarer, og jeg var en af dem der sendte et svar (Hent svaret (pdf).

Hovedproblemet, som jeg så det, var at de forslag udvalget kom med, slet ikke løste de alvorlige problemer der var på området, fx at systemerne skulle udveksle data og at leverandørerne ikke måtte få monopol. Jeg hørte aldrig noget fra udvalget, men i oktober 2005 ringede Henning Mølsted fra Ingeniøren og bad om et interview. Hans artikel blev startskudet til en mediestorm, der startede med det konkrete problem, men hurtigt blev til mudderkastning om at nogle sagde at EPJ slet ikke duede, og andre at det virkede fortræffeligt. Som sædvanlig skyldtes uenigheden at man ikke snakkede om det samme. Nogle talte om de store problemer der endnu ikke var løst, mens andre talte om de der var løst, fx med delsystemet til medicinering.

Ved EPJ-konferencen på Nyborg Strand, oktober 2005, fortalte Esben Dalsgaard fra udvalget at han sådan set var enig i mine kommentarer, men at han ikke mente det var udvalgets kommisorium at gøre noget ved det. Han har desværre nok ret. Vigtige problemer i det offentlige falder tit mellem to stole, så alle mener det er nogle andres ansvar. IT-arkitektur er åbenbart et eksempel på det.

2006: Vurdering af fremtidens EPJ platforme

I begyndelsen af 2006 diskuterede man i Indenrigs- og Sundhedsministeriet, samt i amter og regioner, hvordan man skulle få Danmarks mange forskellige elektroniske patientjournaler (EPJ-systemer) til at hænge sammen. Jeg var indblandet i debatten på flere måder, og i juni 2006 frigav jeg et notat om økonomien og andre aspekter i de forskellige løsninger. Der var tre hovedløsninger på banen: (1) Sammenlægning af systemerne i hver af de 5 nye regioner. (2) Sammenkobling af dem via SOA (Service-orienteret arkitektur). (3) Overfør alle data fra de eksisterende systemer til en ny fælles platform, som grundlæggende var en fælles database. På den fælles platform skulle man gradvis opbygge flere brugergrænseflader tilpasset de mange lægefaglige specialer.

En af misforståelserne der havde blokeret for arbejdet var, at man troede at hvert medicinsk speciale skulle have sit eget system med sin egen database. Det med at den samme database kunne have flere brugergrænseflader var ufatteligt.

Hvad ville hver af løsningerne koste? Overraskende viste det sig, at det var 2-3 gange dyrere at sammenkoble det man havde (løsning 1 og 2), end at anskaffe en fælles platform.

Jeg så på andre faktorer end økonomi, fx datakonvertering, behov for IT specialister, uddannelse og flytning af personale, anskaffelse af nye moduler eller udstyr, leverandørmonopol. Alt pegede på en fælles platform. Desuden skitserede jeg en tidsplan for løsning 3.

Detaljerne om løsningen findes her: Download (pdf)
De økonomiske beregninger er her: Regnearket bag udregningerne (xlsx).

Så hvad besluttede man at gøre? Ingenting. Hver region lavede lidt lokale ændringer. Først i 2013 skete der noget: Region Hovedstaden og Region Sjælland købte EPIC (kaldt Sundhedsplatformen) og gjorde den til platform for al EPJ på 17 hospitaler. Se Anskaffelse af EPIC nedenfor.

Patientjournal med lab resultater og patient ydelser
Patientjournal med lab resultater og patient ydelser

2007: Grafisk patientjournal-system som kan tilpasses lokalt - Uvis

I 2007 fik jeg bevilling til et projekt der skulle udvikle et værktøj (Uvis) så IT-interesserede brugere selv kunne udvikle interaktive, grafiske brugergrænseflader. Vi antog at disse brugere forstod regneark, men ikke var programmører. Vi skulle også bevise at det kunne bruges til EPJ-systemer, sådan at man i den enkelte hospitalsafdeling selv kunne udvikle sine skærmbilleder. Da vi startede Uvis projektet i 2007, baserede vi det på Windows .NET. På det tidspunkt var web'en ikke egnet til grafisk data-visualisering. Det har ændret sig siden med HTML 5.

I 2011 havde vi en fungerende prototype af hele systemet, og vi havde testet at slutbrugere på regnearksniveau kunne bruge værktøjet til udvikling. Vi havde vist Uvis til flere leverandører af EPJ-systemer og til nogle software-huse. De kunne se potentialet, men deres nuværende fokus var at udvide deres produkter til web og mobiltelefoner. Det var ikke klart hvordan Uvis kunne flyttes til disse platforme. Nogle af leverandørerne sagde at hvis systemet havde været til web eller mobil, ville de bruge det med det samme. Se mere om Vistool eller prøv det selv: Data visualization and EHR

2013: Anonymisering af en stor EPJ-database

Som del af Uvis projektet anonymiserede vi en relationel database med 300.000 journaler. Det var meget sværere end vi havde forestillet os. Struktureret data i tabellerne var relativt let, men person-identifikationer kunne også skjule sig i fritekst-notater. Desuden skulle vi sikre data-konsistens, sådan at data stadig gav et korrekt billede af patientens forløb: Preserving medical correctness . . .(pdf, 13 pages, 2016)

2014: Alt medicinsk data

Bevillingen til Uvis-projektet udløb i 2013, men Lauesen og Søren Lippert (tidligere hjertekirurg) fortsatte på egen hånd. Vi udviklede vores egen version af en fuld EPJ-database - blot for at bevise at det er muligt at dække medicinsk data for alle specialer med et beskedent antal tabeller. Andre EPJ-systemer har over hundrede tabeller.

I 2014 omfattede vores EPJ-database alle slags klinisk data: 27.000 diagnoser, 17.000 slags laboratorieprøver, 17.000 slags kliniske aktiviteter (fx røntgen-billeder), tabeller over kliniske brugere og organisationer. Tabellen over medicintyper er udbygget med en tabel over 13.000 præparater med handelsnavne. Patient-specifikt data er dækket af 10 tabeller. En ting vi ikke forsøgte, var at dække afregning og betaling. I alt består systemet af 26 tabeller, inkl. simple tabeller så som en liste af "haster"-koder.

Figuren viser en patients livslinie inkl. lægens notater, diagnoser, medicin, laboratorieprøver og andre slags ydelser. Ydelser med et numerisk resultat bliver automatisk vist som en simpel lineær graf, andre ydelser som bokse. Nogle ydelser kan blive vist på en speciel måde når man klikker på boksen. Der er flere skærmbilleder, fx til at ordinere medicin eller bestille ydelser. I alt er der ca. 20 skærmbilleder. Alt er lavet med Uvis - og uden programmering.

Problemer ved anskaffelsen af EPIC (Sundhedsplatformen)

I 2013 underskrev Region Hovedstaden og Region Sjælland en kontrakt med det amerikanske firma EPIC, om levering og drift af EPJ-systemer til regionernes 17 hospitaler og 40.000 kliniske medarbejdere. EPIC havde vundet en udbudsforretning, hvor 3 leverandører havde sendt et tilbud. Systemet blev kaldt "Sundhedsplatformen". Det blev sat i drift på de første hospitaler midt i 2016 og de sidste hospitaler i slutningen af 2017 - på den lovede tid og til den lovede pris.

Men mange brugere var utilfredse med systemet, produktiviteten gik ned på mange klinikker, og ved udgangen af 2019 var der stadig ingen rapporter om økonomiske gevinster. Rygterne sagde at man havde valgt det forkerte system. Hvad gik galt? Det korte svar er: Mange ting. Fx havde man brugt forkerte tildelingskriterier, selvom de på papiret så fine ud. Man satte systemet i drift for tidligt og justerede ikke processen. Man planlagde ikke de nye arbejdsopgaver for de enkelte klinikker. Man satte systemet i drift med utilstrækkelig støtte og uddannelse. Du kan se detaljerne i disse rapporter:

2020: Soren Lauesen: Damages and damage causes in large government IT projects. Damage case stories, 59 pages (pdf). Denne rapport undersøger 5 store offentlige IT-projekter der er gået galt. EPIC er kapitel 5.

2017: Søren Lauesen: Hvorfor EPIC blev valgt og konsekvenserne. Denne rapport undersøger hvorfor kunden valgte EPIC, og hvorfor man ikke opdagede at arbejdet med det nye system ville gå meget langsommere på flere områder. Hent rapport (pdf, dansk)

2017: Søren Lauesen: Tidsstudie af EPIC i klinikken: Rapporten indeholder Lauesens detaljerede tidsstudie af konsultationer på en endokrinologisk klinik der havde brugt EPIC ca. et år. Ca. 40% af tiden gik med at lægen klikkede og tastede uden at der samtidig var patient-kontakt. Ca. 30% af tiden kiggede læge og patient sammen på skærmen (fint). Ændring af patientens medicinordination tog 25 klik. Den gennemsnitlige observerede konsultationstid var ca. 18 minutter. Afdelingen regner dog med 15 minutter. Med det gamle system var den 10 minutter. Tidsstudie (pdf, dansk)

2017: Oliver Metcalf-Rinaldo and Stephan Mosko Jensen: Learnings from the implementation of Epic. Disse rapporter beskriver de mange ting der gik galt, da man anskaffede EPIC, fx manglende brugertræning, langsom opdatering af patientens medicinoplysninger, ordinationer der forsvinder. Learnings from Implementation of EPIC (pdf, 54 sider),   Appendix (pdf, 27 sider)