I debatten om arkitektur for Akson kan det fremstå som om spørsmålet er plattform eller ikke. Slik er det ikke.
Snarere dreier det seg om hvor langt en skal gå i balansen mellom fleksibilitet og samordning i plattformarkitekturen for både Akson journal og Akson samhandling. Vi må også finne den rette balansen mellom funksjonalitet for helsepersonell og innbyggere og plattformegenskaper.
En konstruktiv debatt videre må gå inn i denne kompleksiteten.
Plattform med flere lag
Plattformbegrepet forstås ulikt, og for Akson lener vi oss på en definisjon fra forskningsmiljøer (lenken laster ned en PDF). Med plattform mener vi løsninger som kobler forskjellige brukergrupper sammen. De har et økosystem basert på en gjenbrukbar plattformkjerne, API og komplementære applikasjoner.
Plattformer kan bestå av flere lag. En gjenbrukbar kjerne, et lag med konfigurerbare applikasjoner fra plattformleverandøren, og et lag med applikasjoner fra tredjeparter med tettere brukerinvolvering – det Bendik Bygstad gjerne kaller lettvekts-IT.
Når man etablerer plattformer vil en på noen områder ønske løse koblinger og tillate innovasjon, mens plattformeieren på andre områder vil ha behov for å ta beslutninger på vegne av hele økosystemet.
Apples iPhone begynte for eksempel som et lukket økosystem, men tilpasset seg så ved å åpne for at eksterne kunne lage applikasjoner hvis de fulgte strenge regler. Android har tillatt mer innovasjon, inkludert det å bytte ut sentrale plattformtjenester.
Tilleggsapplikasjoner
Andre plattformer som Facebook, Youtube, Finn, Airbnb og Uber har hatt sterk kontroll over sitt eget brukergrensesnitt, men har gitt fleksibilitet til bidrag på andre områder.
_logo.svg.png){kind=logo}
I Akson skal det være mulig å tilby tilleggsapplikasjoner fra andre enn plattformleverandøren. Et viktig spørsmål er hvor grensene går mellom kjernefunksjonalitet og disse komplementære funksjonene, og hvilken fleksibilitet applikasjoner skal gis.
Både iPhone og Android-telefoner kommer med en samling applikasjoner fra plattformleverandøren. Når du åpner telefonen første gang så kan du ringe, tekste, sende e-post, surfe og installere flere applikasjoner gjennom plattformens butikk.
Vi tror at fremtidens elektroniske pasientjournalløsninger (EPJ) vil være tilsvarende. De vil komme med en samling sømløse applikasjoner som dekker primærbehovet til de fleste av brukerne, men få leverandører kommer til å kunne levere alt brukerne trenger alene.
Ikke hodeløs
For Akson anbefaler vi at plattformen må komme med applikasjoner som oppfyller de viktigste funksjonelle behovene som helsepersonell har, og som virker fra dag én. Videre må man kunne legge til eller eventuelt bytte ut applikasjoner for å oppfylle spesifikke brukergruppers ønsker om funksjonalitet.
Dette er en vanlig måte å bruke plattformer på, der Akson følger god praksis på plattformområdet. Akson legger opp til løse koblinger mellom plattformen og applikasjon, men ikke en hodeløs EPJ-plattform uten applikasjoner, slik Espen Andersen tar til orde for.
Plattformegenskaper er relevant både for EPJ og samhandlingsløsningen, og disse to vil bruke plattform på litt forskjellige måter. For noen av bruksområdene vil EPJ også være en slags applikasjon på samhandlingsplattformen, ved å tilpasse og filtrere informasjonen til den enkelte brukerens behov.
Ubesvarte spørsmål
Dessverre er plattformmodenheten på mange EPJ-systemer i dag lav. I Norge sliter kommuner og tredjeparter med å få tilgang til EPJ-enes lukkede økosystemer. Flere EPJ-leverandører omtaler sine løsninger som plattformer, men setter svært strenge krav til hvem som får tilgang.
Dette er ikke bare et problem i Norge, men i EPJ-markedet globalt. I anskaffelsene som kommunene skal gjøre blir det viktig å finne en leverandør eller leverandørkonstellasjon som kan tilby både nok sluttbrukerfunksjonalitet og nok plattformegenskaper.
Hvem som kan levere best på dette målbildet er det for tidlig å si, men vi vet at flere leverandører ønsker å ta utfordringen alene eller i et partnerskap med andre.
Det er også fortsatt ubesvarte spørsmål, for eksempel om hvilke åpne API som skal finnes og hvilke standarder som skal støttes? Hvordan løses personvernutfordringer som kanskje er spesielt viktige i helse? Hvordan sikrer man at applikasjoner er medisinsk forsvarlige?
Det er staket ut en kurs. Vi må begynne reisen, lære underveis og finne svar sammen med leverandørmarkedet og aktørene i helse- og omsorgssektoren.
