Skip to main content
Aktuelt

Egde om FHIR i 2023

Skrevet av Andy Harrison den . Publisert i Aktuelt, eHelse.

Dette er den første av en serie på 3 artikler om helsedatastandarder:

  1. Egde om FHIR i 2023 – vår reise med HL7® FHIR® (denne artikkelen)
  2. Hjemme og borte – den internasjonale pasientoversikten og internasjonal pasienttilgang
  3. Helsedatastandarder, terminologi og AI-eksperimentering

 

Helsedatastandarder igjen! Det er flere år siden jeg (Andy Harrison) sist skrev om innføringen av HL7® FHIR® (Fast Health Interoperability Resources), en standard som allerede da hadde vært 9 år under utvikling. Så man skulle kanskje tro at HL7 FHIR® er ferdig utviklet og utbredt i bransjen. Dessverre ser det ut til at innføringen av standarder følger en svært menneskelig tidsskala, og i så måte er FHIR® ikke engang en tenåring i 2023.

Ifølge det ærverdige British Standards Institute er standarder «den destillerte visdommen til mennesker med ekspertise på området og som kjenner behovene til organisasjonene de representerer». Og siden en standard er en omforent måte å gjøre noe på, vil en helsedatastandard alltid bli påvirket av det eneste vi alle kan være enige om: at våre behov er litt annerledes enn deres behov (uansett hvem «de» er).

Et tegn på at FHIR er blitt mer modent, kan man se av sammensetningen av foredragene på de internasjonale HL7®FHIR® DevDays i Amsterdam nylig, sammenlignet med for 3-4 år siden. Foredragene handlet mindre om eksperimentell programvareutvikling og mer om praktiske brukstilfeller og implementeringer.

En sterk indikasjon på at FHIR® er i ferd med å modnes, er den nylige ratifiseringen av International Patient Summary (IPS) som en internasjonal standard (EN ISO 27269). Men mer om dette i en kommende artikkel.

I Egde fremmer og støtter vi standarder, men vi må også iverksette praktiske løsninger for kundene våre på en så effektiv måte som mulig. For oss er ikke bruk av standarder en akademisk øvelse. Det er viktig å dekke dagens behov og samtidig være forberedt på fremtiden, og det betyr at vi må ha fleksibilitet til å integrere med systemer som ble utviklet før FHIR ble født.

 

Kundenes behov for integrasjon

De fleste av våre kunder har behov for å integrere med eksisterende journalsystemer og andre nasjonale fellestjenester i helsesektoren. Mange av disse systemene har planer om FHIR-grensesnitt, og noen har allerede iverksatt dem. Å ha en ny versjon av et journalsystem tilgjengelig er imidlertid ikke det samme som at det er implementert og rullet ut i de regionale helsesystemene. Det er også noe som kan ta flere år å gjennomføre.

Vi har funnet ut at det mest praktiske vi kan gjøre, er å bygge en integrasjonsplattform, Egde Health Gateway, som vi bruker til å koble til nye og gamle plattformer. Dette har gjort det mulig for oss å tilby gjenbrukbare komponenter og korte leveringstider.

 

Vi har nå et produkt med en arkitektur og sikkerhet som er akseptert av Norsk Helsenett, og vi har moduler som gir tilgang til felles helseregistertjenester som Persontjenesten (person- og kontaktdata), Helsepersonellregisteret (helsefaglige data), Adresseregisteret, tjenester for identitets- og tilgangsstyring som HelseID eller BankID, samt tilganger til nasjonale eller tredjeparts tjenester som HelseNorge (pasientens portal), Pasientens prøvesvar (pasientens prøvesvar), VKP (velferdsteknologisk knutepunkt), EDI-meldingstjenester eller CheckWare sin Partner API.

Av disse er VKP og Pasientens prøvesvar FHIR-API-er, men FHIR er på vei med flere viktige journalleverandører og andre fellestjenester. Våre kunder vil være klare når det skjer.

 

Utviklerens erfaring

Et spørsmål som ofte stilles, er om datalagringen bør være FHIR. Det vanligste svaret her er «det kommer an på». FHIR ble først og fremst utviklet som et datautvekslingsformat. FHIR som datamodell kan være komplisert for en utvikler som er mer vant til relasjonsdatamodeller. Noen ganger opplever vi at den totale løsningen har forretningselementer som ikke enkelt kan mappes til FHIR-ressurser.

Det er tre typiske brukstilfeller:

  1. Kunden har allerede en backend og en datamodell. Her trenger vi ikke å lagre data lenger enn det som er nødvendig for å mappe dem til det ønskede integrasjonsformatet. Hvis kravet er et FHIR-API, eksponerer vi de spesifikke dataene som en FHIR-fasade.
  2. Forretningskravet dekkes delvis av FHIR. Her vil vi sannsynligvis opprette en tilpasset datamodell for backend-tjenesten ved hjelp av navnekonvensjoner som ligner på FHIR. Egde Health Gateway sørger deretter for tilkobling via en FHIR-fasade eller en EDI-meldingstjeneste etter behov.
  3. Forretningskravet passer til FHIR, og det finnes ingen eksisterende backend. Her vil vi sannsynligvis gå rett til en full FHIR-server og eksponere integrasjons-API-et som en FHIR-fasade.

Denne tilnærmingen har flere fordeler:

  • Den holder datamodellen enkel
  • Det forbedrer sikkerheten ved å minimere funksjonene til det offentlig eksponerte endepunktet.

 

Vi ser også at FHIR Rest API ikke er ideelt for kommunikasjon med en nett- eller mobilapp. For disse bruksområdene bruker vi Egde Health Gateway til å opprette en BFF («back-end for front-end» – ikke å forveksle med «best friends forever»). Dette er en standardbasert FHIR-modell som bruker Googles Protocol Buffers og FhirProto-implementering som er kompakt og effektiv for applikasjonsutvikling.

Jeg tok feil da jeg tidligere antydet at FHIR ennå ikke er en tenåring. Den er moden og begynner å finne seg selv i den virkelige verden. I menneskelige termer har den fullført sin mastergrad og begynner å gjøre nytte for seg i samfunnet. La oss si at den er dyrets svar på en 23-åring, noe som vil si at den er omtrent som en hest eller en flodhest. Andre dyr er tilgjengelige, bare ikke kall det et esel.