Datadeling i helsesektoren — noen erfaringer

Hvordan får vi IT-løsninger i helsesektoren til å snakke bedre sammen? Det satses mye på bedre samhandling og informasjonsdeling, med nye tjenester som Pasientens journaldokumenter, Pasientens prøvesvar og Pasientens måledata. Et viktig virkemiddel som ofte trekkes fram for å få til dette er standardisering. Her vil jeg fortelle litt om konkrete erfaringer om hva som fungerer godt og dårlig i praksis når man skal utveksle data mellom løsninger fra mange ulike leverandører, spesielt hvilke utfordringer jeg har sett med å få til god standardisering i praksis.

Jeg vil trekke fram to eksempler: Automatisert behandling av blåreseptsøknader hos Helsedirektoratet, og Velferdsteknologisk knutepunkt (VKP) hos NHN.

Forutsetninger

Det er noen forutsetninger i helsesektoren som er viktig å være klar over og som gjør at det som fungerer i praksis ikke nødvendigvis er det samme som den «ideelle» løsningen: Sektoren består av mange små og store aktører (kommuner, fastleger, sykehus) som stort sett hver for seg anskaffer sine egne fagløsninger. På samme måte består leverandørmarkedet for IT-løsninger til helsesektoren av mange store og små leverandører, med stor variasjon i både kapasitet og endringshastighet. Viljen til å stille strenge felles krav til leverandørene er liten, derfor er også variasjonen stor.

Fagløsningene jeg vil snakke om her er av to typer:

Elektronisk pasientjournal (EPJ) er helsepersonells hovedarbeidsverktøy for dokumentasjon, informasjonsdeling og beslutningsstøtte i pasientbehandlingen, og skal inneholde all relevant pasientinformasjon på ett sted.

Velferdsteknologi (VFT) er samlebegrepet for teknologiske løsninger — som sensorer, trygghetsalarmer, medisindispensere og digitale kommunikasjonsverktøy — som brukes i forebygging, behandling, oppfølging og pleie innen helse- og omsorgssektoren, ofte i pasientens eget hjem eller på en institusjon. Velferdsteknologi omfatter blant annet trygghetsalarmer, digitale medisindispensere, lokalisering og teknologi for digital hjemmeoppfølging. Teknologien består typisk av utstyr der pasienten befinner seg (f.eks. måleutstyr eller alarmer) og løsninger for helsepersonell eller andre ansatte som følger opp pasientene.

Eksempel 1: “Blåresept”

På Helsedirektoratet jobbet vi med automatisering av individuelle søknader om legemidler på blå resept. Søknadene sendes av legen på vegne av pasienten, og opprinnelig ble dette gjort fra legenes ulike pasientjournalløsninger. Søknadsløsningen var basert på meldingsutveksling med et standard meldingsformat («M2»). Alle EPJ-leverandørene utviklet da skjema for registrering og innsending av slike søknader som en integrert del av legens arbeidsflate, og valideringen av søknadsinnholdet var stort sett lokal og dermed litt ulik for hver EPJ.

M2 var et standardisert meldingsskjema skreddersydd for dette formålet, men ulike implementasjoner, ulik tolkning av standarden og varierende strenghet i valideringene gjorde at det var mye variasjon i hvordan skjemaet ble fylt ut og til dels dårlig datakvalitet. Eksempelvis var det nødvendige felter som ikke ble fylt ut, eller legene la viktig informasjon inn som fritekst i kommentarfelter i stedet for i de strukturerte feltene som var beregnet for formålet. Dette kunne vært forbedret ved å innføre strengere sentral validering, men dette ble ikke gjort av ulike grunner: Pga. forsinkelse i meldingsutvekslingene ville det ta tid for valideringsfeil ble meldt tilbake til legen, og av hensyn til pasienten ønsket man ikke å avvise søknader.

En annen utfordring var endringshastigheten hos leverandørene: Ved endringer og utvidelser i søknadsskjemaet, måtte alle løsningene oppdateres av ulike leverandører, og dette skjedde ikke samtidig. Ved ny skjemaversjon tok det flere år fra versjonen var publisert til alle løsninger støttet ny versjon, og søknadsmottaket måtte derfor håndtere både gammel og ny versjon, i praksis tre ulike versjoner i parallell. Regelverksendringer som krevede nye felter i søknaden (for eksempel når det ble innført strengere vilkår for støtte for opioider), tok derfor mange år å få fullstendig gjennomført i praksis.

Resultatet var at det ble vanskelig å oppnå høy automatiseringsgrad — unødvendig mange søknader måtte behandles manuelt behandling.

Konsekvensen ble at vi i 2018 startet utvikling av en ny løsning, basert på API, dynamisk generert søknadsskjema og sentral validering med umiddelbar tilbakemelding, slik at feil kunne rettes opp med en gang. Automatiseringsgraden økte kraftig, og den meldingsbaserte løsningen er nå faset ut. Skjemadefinisjonen M2 ble dermed forkastet, men ny løsning har beholdt de mest sentrale enkeltelementene, som kodeverk for legemiddel/virkestoff, diagnosekoder, identifikasjon av lege og pasient osv.

Den nye Blåresept-løsningen har vært vellykket, spesielt sett fra “søknadsbehandlerens” side (dvs. Helsedirektoratet/Helfo). Samtidig illustrerer den nye løsningen et annet problem: Den tilbyr et API som alle journalløsninger kan integreres mot, men så langt har ingen leverandører valgt å gjøre dette. Grunnen er at dette krever en del nyutvikling, og noe som enten må bestilles og finansieres av kundene (og de er mange og til dels små), eller så må leverandørene selv prioritere det som egenfinansiert produktutvikling, i konkurranse med andre behov. Alternativt må «noen» sentralt stille krav. Resultatet er at legene må sende blåresept-søknader fra en egen portal, Helseaktørportalen, som ikke er integrert i deres vanlige arbeidsflate.

Eksempel 2: Velferdsteknologisk knutepunkt (VKP)

Den typiske situasjonen ved bruk av velferdsteknologi er at helsepersonell og andre tjenesteytere følger opp pasienter i en egen løsning, adskilt fra pasientjournalen. Det er behov for toveis integrasjon mellom velferdsteknologi og EPJ, og VKP er et bindeledd som sørger for denne integrasjonen på en leverandøruavhengig måte. Med andre ord, i stedet for at alle velferdsteknologi-løsninger skal integrere mot alle EPJ-er (dvs. en stor mengde enkeltintegrasjoner), så trenger de kun å integrere mot én, sentral tjeneste, VKP.

De typiske brukstilfellene VKP støtter er:

• En hendelse skjer ute hos pasienten, f.eks. at pasienten aktiverer trygghetsalarmen eller melder inn en eller flere målinger som er utenfor normalområdet. Personellet varsles om dette i sin velferdsteknologiløsning, følger opp hendelsen og skriver et oppfølgingsnotat. Denne informasjonen journalføres i kommunens EPJ, via VKP.
• Velferdsteknologiløsningen etterspør oppdatert informasjon om en eller flere pasienter fra kommunens EPJ (f.eks. kontaktinformasjon, pasientens tjenester, besøksplan osv.).

VKP er for øyeblikket integrert med 15–20 ulike velferdsteknologiløsninger og 4–5 EPJer. For hver enkelt som bruker VKP, fungerer denne som et bindeledd mellom kommunens velferdsteknologi-løsninger og kommunens EPJ.

Det er utfordrende å håndtere så mange ulike løsninger fra ulike leverandører. En nøkkel til å få dette til er et felles API mot velferdsteknologiløsningene, som dermed driver fram samordning og standardisering.

Virkemiddel for standardisering

De to «sidene» av VKP illustrerer en viktig forskjell:

• Alle kall, både ved journalføring til EPJ og oppslag av informasjon fra EPJ, initieres fra velferdsteknologiløsningen. Kallene går dermed til et felles API i VKP. APIet fungerer da som en “portvakt” som sikrer at alle velferdsteknologiløsningene følger en felles standard. Felles validering i VKP gjør at kall som ikke følger standarden blir avvist.
• EPJene er i denne sammenhengen “passive” mottakere av kall, både ved journalføring og oppslag. Vi har dermed ingen mulighet til å “tvinge” disse til å følge et spesielt format. VKP må derfor bruke de ulike EPJenes proprietære APIer. Hver enkelt EPJ har sitt eget format, og VKP må “oversette” mellom standardformatet i “velferdsteknologi-enden” og proprietært format for den konkrete EPJen.

Hvis EPJ-leverandørene skal standardisere på felles APIer, må noen kravstille og evt. bestille dette, i utgangspunktet hver enkelt kommune som er kunde. Og selv om man hadde fått dette til, ville det vært en svakere grad av standardisering, når dette ikke «påtvinges» gjennom felles API og validering (fordi det alltid vil være variasjoner). Et alternativ er å “snu integrasjonen”, så EPJene også gjør kall til VKP (etterspørre journalnotater, avlevere oppdatert informasjon) og dermed må bruke et felles API.

FHIR

VKPs felles API mot velferdsteknologi-løsningene er basert på FHIR. Dette er en internasjonal standard, som er ment å dekke bredt. Det er en fordel å kunne gjenbruke utprøvde definisjoner, men det er også utfordringer med å basere seg på definisjoner som er ment å dekke mange ulike brukstilfeller på internasjonal basis. Definisjonene er ofte veldig generelle, noe som gir stort rom for tolkning og ulike valgmuligheter, og er ikke nødvendigvis tilpasset virkeligheten i norsk helsevesen (spesielt i kommunene). VKP var tidlig ute med å ta i bruk FHIR og vi har gjort mange erfaringer siden starten. Det er spesielt to problemstillinger vi har sett:

Tolkningsrom og valgmuligheter

FHIR-definisjonene bruker ofte generelle begreper og må tolkes i den konkrete sammenhengen. Det er ulike måter å bruke de samme definisjonene på, fordi de skal dekke så bredt. Dvs. at det blir mange valgmuligheter som dermed gir stor mulighet for variasjon når mange aktører skal lage løsninger hver for seg. Ved å tilpasse definisjonene til VKPs behov, og stramme inn på input-valideringen har vi etter beste evne gjort APIet mer konkret og redusert mulighetsrommet, men har ikke alltid fått til dette godt nok — vi har lært underveis. Det har flere ganger dukker opp overraskelser i form av at leverandører bruker FHIR på måter vi ikke har sett for oss eller ikke tatt høyde for, og vi har ikke alltid vært “strenge” nok til å unngå unødvendig variasjon.

En av EPJene vi jobber med, Helseplattformen, har FHIR-baserte APIer. Men Helseplattformen bruker FHIR på en annen måte enn det VKP gjør, så her er det også behov for oversettelse.

FHIR, helsefag og forståelighet

FHIR inneholder et bibliotek av definisjoner som kan gjenbrukes og tilpasses. Noen definisjoner passer godt til det vi vil beskrive, eksempelvis fungerer FHIR Observations godt for å representere målinger som pasienten gjør hjemme ved digital hjemmeoppfølging (selv om representasjonen blir omfangsrik og ikke veldig rett fram å lese).

På andre områder er det dårligere match. Hva betyr f.eks. EpisodeOfCare, og hvor lett er det å forstå at dette representerer en kommunal helsetjeneste? Når kommuner og leverandører bruker ulike begreper og beskriver ting ulikt, er det ikke tvil om at vi trenger å samordne og standardisere. Men noen ganger ender vi opp med resultater som er vanskeligere å forstå. Det kan virke som vi går fra ulike dialekter av norsk til å standardisere på esperanto. Vi går fra språk med variasjoner, men som vi stort sett forstår, til noe som er felles, men mye vanskeligere å forstå.

Når representasjonen ikke passer godt med dagligspråket og helsefaglige uttrykk som brukes i kommunene, fører dette utfordringer for alle parter, noe vi ofte har erfart i praksis:

• Når modellen vår ikke er “selvforklarende”, fører det til merarbeid i form av mye ekstra kommunikasjon med både leverandører og kommuner. Til gjengjeld medfører en felles tjeneste ikke bare teknisk samordning, men også ett felles kontaktpunkt for avklaringer
• Utviklerne, både de som lager VKP og de som kobler seg til VKP, må forholde seg både til to ganske ulike språk: både et helsefaglig språk og FHIR, noe som medfører mentale “mappinger” og muligheter for misforståelser.
• Dette gjør både utvikling og vedlikehold mer krevende og øker faren for feil og mangler.

Hvordan kan vi forbedre dette? Utvikling av fagløsninger og tilhørende integrasjoner krever tett samarbeid mellom IT og helse- og omsorgsfaget. For at dette skal fungere godt, må begge parter kunne snakke samme språk. Det betyr at vi trenger et felles domenespråk som er godt tilpasset den virkeligheten vi jobber med. Det er en balansegang mellom å være veldig spesifikk (f.eks. tilpasset norsk “kommunespråk”) og veldig generell (f.eks. basere seg på internasjonale standarder, noe som kan gjøre det enklere å ta i bruk løsninger for utenlandske leverandører). I en virkelighet med så mye fagspråk og der det er så viktig å behandle informasjonen godt og riktig, tror jeg vi bør legge stor vekt på forståelighet og “treffsikkerhet”. Vi har også sett utfordringene med å ta i bruk “hyllevare” som ikke er tilpasset norsk virkelighet, så det er gode grunner til å ikke generalisere for mye.

Oppsummering

Standardisering er viktig. Med gode standarder skulle man tro at alt blir likt og at man unngår misforståelser. I praksis er det ikke like enkelt. Her er noen hovedpunkter fra mine erfaringer:

Variasjon — med mange ulike leverandører er det vanskelig å unngå variasjon fullsteding. Ulike implementasjoner medfører ofte forskjeller.

Versjoner — det vil alltid oppstå behov for endringer og å oppdatere en standard til ny versjon. Det er umulig å få alle leverandører til å oppdatere samtidig, så ulike versjoner må kunne håndteres.

Virkemidler — For å samordne i praksis i en så sammensatt verden med vanskelige styringslinjer, trengs det gode virkemidler. Det jeg har sett fungere i praksis er felles tjenester med felles validering og et sentralt punkt å håndtere variasjoner og ulike samtidige versjoner. Da kan all logikken for å kompensere for variasjon og ulike versjoner samles på ett sted.

Forståelighet — et domenespråk og representasjon som er godt tilpasset norsk virkelighet er nødvendig for å legge til rette for god kommunikasjon og å unngå feil.

Målet vårt er å utveksle informasjon slik at den forstås på samme måte av alle parter. Standardisering er et virkemiddel for å oppnå dette, men ikke en løsning eller et mål i seg selv. Den viktigste standarden er den som fungerer i praksis. Dette kan ikke “vedtas”, det må bevises i praksis.