Ikke la gamle journalsystemer definere fremtidens helse-IT

Håkon Haaheim og Mona Stedenfeldt skriver i Dagens Medisin at helsetjenesten må investere i åpen infrastruktur, standarder og API-er som gjør at systemene kan samarbeide. Jeg er helt enig. Men fra den andre siden av bordet, som en av dem som faktisk bygger et nytt norsk journalsystem, ser jeg samtidig en utvikling som bekymrer meg: Vi snakker mer om åpne API-er, mens stadig mer av selve arbeidsflaten flyttes ut av journalsystemene og over i applikasjoner kontrollert av det offentlige.  

⁠Helsetjenesten må investere i åpen infrastruktur – Dagens Medisin

Jeg forstår hvorfor dette skjer. Norske EPJ-er har gjennom mange år blitt store og tunge systemer hvor selv relativt små endringer kan kreve lange utviklings- og utrullingsløp. Samtidig har terskelen for nye aktører vært høy. Det er ikke bare å lese en API-beskrivelse og koble seg på. Leverandører skal gjennom avtaler, sikkerhetskrav, testmiljøer, samsvarstester, kodegjennomganger og produksjonsgodkjenninger. Mye av dette er nødvendig når vi håndterer noen av de mest sensitive opplysningene vi har. Problemet oppstår når summen av gamle systemer og tunge prosesser gjør endringstakten så lav at staten konkluderer med at den må bygge brukeropplevelsen selv.

Vanlig arkitektur i IT-bransjen

NAVs egen utredning «Nå snakker vi!» illustrerer dette svært godt. Der vurderes en API-basert modell opp mot blant annet SMART on FHIR. NAV beskriver utviklingsomfanget hos EPJ-leverandørene ved API-modellen som «meget stort», fordi hver leverandør må utvikle funksjonalitet, brukergrensesnitt, support og videreutvikling. NAV vurderer samtidig sin egen endringsevne i denne modellen som svært lav. Med SMART on FHIR kan NAV i større grad eie applikasjonen selv og dermed endre den raskere. Det er en forståelig konklusjon.  

Men her ligger også problemet. Når det offentlige bygger applikasjonen, bestemmer det ikke lenger bare hvordan data skal utveksles og hvilke sikkerhetskrav som gjelder. Det bestemmer også hvordan legen skal utføre arbeidet. For helsepersonellet betyr det at funksjonaliteten stadig oftere kan bli noe journalsystemet åpner, i stedet for noe journalsystemet integrerer sømløst i arbeidsdagen.

Det er synd, for moderne programvare bygges ikke slik fordi API-er er en ny og eksperimentell idé. API-first har vært vanlig arkitektur i IT-bransjen i mange år. I et moderne system er det helt normalt at funksjoner eksponeres gjennom kontrollerte API-er, med autentisering, autorisasjon, logging og tydelige datakontrakter. Det samme gjør det relativt enkelt å koble på nye tjenester når de blir tilgjengelige. Norsk helsenett gjør allerede dette på flere områder. Pasientens kritiske informasjon integreres eksempelvis gjennom API slik at informasjonen kan vises direkte i leverandørens egen EPJ. Pasientens journaldokumenter kan også integreres direkte i journalsystemet gjennom API.  

Det er slik jeg mener vi bør tenke mer, ikke mindre.

For målet bør være at legen ikke merker integrasjonen. Hvis legen allerede har pasienten åpen, kjenner journalsystemet konsultasjonen, behandleren og konteksten. En sykmelding, henvisning eller annen offentlig tjeneste burde kunne bli en naturlig del av den samme arbeidsflyten. Én leverandør kan kanskje løse oppgaven med ti klikk, en annen med tre. En tredje kan automatisere store deler av den. Det er akkurat denne konkurransen vi mister dersom alle må bruke den samme ferdige arbeidsflaten.

Dette er også et lite stikk til oss EPJ-leverandører. Når myndighetene opplever at en sikkerhetsendring eller et nytt grensesnitt tar måneder eller år å få implementert, er det ikke vanskelig å forstå hvorfor de mister tålmodigheten. Vi kan ikke samtidig kreve åpne API-er og bruke år på å ta dem i bruk. Det finnes fortsatt systemer hvor arbeidsprosesser og tekniske kompromisser henger igjen fra en helt annen generasjon IT. At helsepersonell fortsatt må leve med omveier, etterregistrering og automatiserte prosesser som blant annet signerer journalinnhold i etterkant, bør være et varsko om hvor langt enkelte deler av markedet har fått lov til å henge etter.

Norsk helsenett skrev selv i Dagens Medisin i sommer at Helse-Norge trenger både felles infrastruktur og et levende marked, og at deres oppgave er å legge til rette for at andre kan utvikle bedre løsninger. Det er etter min mening riktig rollefordeling.  

Handler om bedre systemer

Dette blir enda viktigere når EHDS kommer. Fremtidens journalsystemer må være bygget for strukturert datautveksling, interoperabilitet og stadig nye tjenester. For nye plattformer er ikke dette nødvendigvis et gigantisk ombyggingsprosjekt. Dersom arkitekturen er laget for det fra starten, kan nye API-er kobles på og egne data eksponeres kontrollert uten at hele systemet må bygges om.

Derfor mener jeg heller ikke at NAV skal slutte med SMART on FHIR. Det kan være en svært god standardløsning, særlig for systemer som ellers ville brukt lang tid på å bygge funksjonaliteten selv. Men den bør ikke bli et argument mot å tilby de underliggende tjenestene gjennom gode API-er der det er mulig.

La den offentlige applikasjonen være standardløsningen. La sikkerhetskravene være strenge. La leverandørene gjennomgå testing og godkjenning før de slipper til.

Men gi samtidig de leverandørene som faktisk kan og vil, muligheten til å bygge en bedre og mer sømløs arbeidsflyt.

For åpne API-er handler ikke bare om at data kan flyttes mellom systemer. De handler om at helsepersonell skal kunne få bedre systemer.

Vi bør ikke bygge morgendagens helse-IT rundt begrensningene i gårsdagens journalsystemer.

Interessekonflikter: Innleggsforfatteren er selv gründer og utvikler av et journalsystem beregnet på det norske markedet.