Samtidskonflikten – historien om hvordan en alvorlig systemfeil i Epic blir til en brukerfeil
Samtidskonflikten, det at journalen i noen tilfeller ikke lar seg åpne når to eller flere vil se på den, som f.eks. når en pasient kommer til akuttmottaket og operasjonsavdelingen vil se på den samme journalen for å forberede seg, er en av de mer alvorlige problemene med Helseplattformen. På St Olav har det ført til at operasjonsavdelingen i mange tilfeller ikke får hentet fram informasjon om riktig blodtype slik at de må gi katastrofeblod.
I følge styredokumentene for HMN så opptrer konflikten hyppig slik at det er et daglig problem. HP sier at samtidskonflikten ikke lar seg løse før i november 2023, kanskje ikke før i 2024.
Samtidskonflikten er så alvorlig at Statens Helsetilsyn sier i sin rapport at videre utrulling av Helseplattformen bør stoppes inntil problemet er løst. For sykehusene er dette et helt avgjørende krav. For kommunene er ikke problemet like stort som på sykehus fordi kommunen ikke har det samme behovet for å se på samme pasient/journal samtidig fra ulike enheter.
For St Olav var samtidskonflikten en overraskelse, men for Epic har den vært kjent i mange år; det er bare slik systemet er, sier Epic, når de lanserer ulike workaround for å prøve å minimere ulempene.
I faglige artikler som ligger tilgjengelige på PubMed og Sciencedirec blir det pekt på at det er tidsdeling i MUMPS, databasen/programmeringsspråket som ligger i bunnen av Epic sin løsning som av og til kan skape problemer. MUMPS ble designet for å dele en database på en tidsdelt datamaskin i en tid hvor prosessorkapasiteten var begrenset og dataminne var dyrt. Tidssystemet fordeler minne og CPU-tid mellom de samtidige aktive oppgavene. I artiklene blir det henvist til at det er et problem med MUMPS database og tidssystemet slik at det kan oppstå konflikter eller inkonsistenser når flere prøver å endre eller lese de samme dataene samtidig. Dette kan føre til feil eller tap av data.
Problemet kan være sammensatt slik at i tillegg til problemene med MUMPS så kan det være medvirkende faktorer høyere opp i kjeden i designet av databasen eller applikasjonen. Uansett så synes problemet å ligge så dypt nede i Epics programvare at det vanskelig lar seg løse uten store kostnader og en stor omlegging av systemet. HP vet forhåpentligvis mer om årsakene.
Epics beskriver selv problemene i sine Tips&Triks. Problemene med låsing av journalen kan ifølge Epic oppstå i følgende situasjoner:
- Når to eller flere brukere ser på samme aktivitet for pasienten samtidig
- Når to eller flere brukere prøver å redigere den samme informasjonen
- Når noen henter opp pasientens journal så kan det oppstå en låsekonflikt slik at datamaskinen krasjer dersom du prøver å skrive inn informasjon som du ikke har fått tillatelse til å skrive inn, dvs journalen er låst av en tidligere bruker.
- Ved bruk av Epic og systemer som støtter det kliniske informasjonsystemet Connect Care (CIS), f.eks. ved hjemmeovervåking, kan det skje en låsing selv om den ene parten bare har skrivebeskyttet tilgang.
Feilene er alvorlige og utgjør en sikkerhetsrisiko for pasienten. Epic har ingen løsning på samtidskonflikten, men har forslag til workaround for å minimere at feilsituasjoner oppstår. På denne måten omdefineres feilen fra å være en systemfeil til å bli en brukerfeil.
Workaround betyr at brukeren får ansvaret for å finne ut om noen andre er inne på eller tenker å gå inn på samme informasjon. Dersom det er tilfelle så må brukerne kontakte hverandre og avklare seg imellom om hvem som har størst behov for tilgang. Ved tilfeller som nevnt i punkt 3 eller 4 må brukeren kontakte systemansvarlige for å få fjernet låsen.
Teknologibakgrunn
MUMPS, programeringsspråket og den hirarktisk databasen som ligger i bunnen av Epic, ble utviklet i 1966 for å løse problemer med store mengder data i flerbrukssystemer i helsesektoren. Fordelene med MUMPS er at den har en innebygget database som kan håndtere store mengder data raskt og effektivt, men ulempene med MUMPS er at det er uvanlige syntakser slik at det er lett for utviklere å gjøre feil, rett og slett fordi det du er vant til i andre programmeringsmiljøer ikke er slik i MUMPS. MUMPS mangler mange moderne funksjoner og biblioteker, det har dårlig støtte og dokumentasjon og det ble utviklet lenge før noen begynte å tenke på moderne brukergrensesnitt. Det finnes knapt noen andre miljøer enn Helseplattformen som bruker MUMPS i Norge.
For HP medfører blandingen av programeringsspråk og database at det blir veldig komplisert og dyrt å kunne skifte ut løsningen med en annen. Epic sier også at et samarbeid med Epic blir et livslangt forhold med de kostnader det medfører. De fleste er i dag enige om at det beste er å holde helsedata og applikasjoner adskilt. Helsedata og databaser har lang tidshorisont/levetid, mens applikasjoner og API-er inn mot helsedata har kort levetid og endres i takt med den teknologiske utviklingen.
Var problemet kjent?
Når problemene oppstod like etter innføringen på St Olav så ble de ansatte beskyldt for at det var brukerfeil og at de måtte trene mer. Først etter et Statens Helsetilsyn kom inn og bl.a. påpekte samtidighetskonflikten ble de ansatt tatt mer på alvor. I norske sykehus er det helt avgjørende å kunne dele informasjon samtidig.
Jeg tviler på at samtidighetskonflikten i Helseplattformen lar seg løse innen 2024. Problemene har vært omtalt i faglitteratur i mange år uten å bli løst slik at det ser ut til at problemene ligger dypt i programvaren fra Epic. For Epic vil det være for stor risiko å gjøre grunnleggende endringer som kan komme til å medføre andre potensielle nye problemer for den store kundemassen de har i sitt hjemland.
Løsningen som kommer fra Epic vil sannsynligvis være den samme som de har gitt til en del andre kunder med de samme problemene, en workaround, dvs en oppskrift på hva brukerne av systemet kan og ikke kan gjøre slik at feilsituasjonen oppstår færrest mulig ganger. På denne måten blir feilen og problemene den medfører adressert til legene, sykepleierne og helsearbeiderne i Midt-Norge.
Det er utrolig at ikke dette er blitt sjekket ut i kravspesifikasjonen. Dersom HP/HMN ikke kjente til problemene er det alvorlig, men dersom feilen har vært kjent internt uten at det er blitt informert om det til sykehusene og brukerne som skulle ta løsningen i bruk, så er det veldig alvorlig.
Hovedproblemet
Hovedproblemet med Helseplattformen er at de har valgt en gammel plattform som er designet i en annen tid og for et helt annet helsevesen. I USA er den viktigste funksjonen at systemet skal lage regninger og fakturaer. Dette betyr at hver eneste ting som gjøres med pasienten må registreres slik at de kan faktureres riktig. I Norden med vårt offentlige trygdefinansierte helsevesen er dette ikke et problem, vi kan bygge et system som er rettet mot å løse helseproblemene.
Intensjonene var gode, men helseplattformen blir aldri bra for Midt-Norge med den plattformen som ligger i bunnen. Systemet har mange feil, det er svært dyrt og det krever en omfattende konfigurering og tilpassing slik at det alltid blir en tidstyv. Et mer moderne grensesnitt ligger svært mange år fram i tid.
I første omgang skal mange tusen feil rettes, systemet skal optimaliseres og treningen skal intensiveres. I tillegg skal EPIC/HP lage et nytt system for fastlegen og et nytt system for røntgen. Det er nødvendig for å få opp aktiviteten på røntgen, men det er tvilsomt om fastlegene noen gang vil bruke den nye løsningen. Og hvorfor Midt-Norge skal bruke milliarder på å kaste ut velfungerende løsninger og erstatte nærmer 100 mindre løsninger med en løsning fra en leverandør har jeg vanskelig for å forstå.