Når bør du bruke FHIR

[thomiz]

Opprette en side som forklarer use-cases hvor HL7 FHIR standarden egner seg for bruk.

• Spesielt knyttet til integrasjonsmønstre
  • Eksempler på gode use-case
• Noen eksempler på use-case der HL7 FHIR kan være utfordrende å anvende

[thomiz]

Input på NHN sin "FHIR not to FHIR" diskusjon rundt helsekort for gravide.

Feedback received so far:

The deadline for feedback is Monday October 7th.

Webmed ved Jarle Hjortland

Fra WebMed sitt standpunkt er ikke FHIR vs OpenAPI viktig og absolutt ikke en faktor i om dette blir en suksess. Jeg har sett over API forslagene og så klart er openapi er lettere å komme i gang med enn FHIR, men for oss så bruker vi også FHIR i mange andre sammenhenger så det er ikke viktig. Vi får ikke igjen for investeringen i denne standarden om ikke også andre partnere følger anbefaling (Retningslinje) fra HDir om å bruke FHIR.

Anonym

Jeg jobber med FHIR i forbindelse med SFM, og opplever det som tungt og kostbart. Hvis dere kunne kombinere fordelene og ulempene i et nytt proprietært format, tror jeg det ville vært det beste: Problemer m/FHIR:
For mange felt: FHIR har mange felt, og i SFM er det vanskelig å få oversikt over hva som er relevant og ikke. Det gir mye merarbeid å kartlegge og prøve ut. Det er mye overflødig som skaper støy og merarbeid. Feltene har ofte tvetydige navn.
Mangler uttømmende eksempler: Siden det er mange felt som ikke er relevante, og vi ikke har uttømmende eksempler på API-svar å forholde oss til, er det vanskelig å sikre at vi gjør det riktige og dekker riktige scenarier med data vi kan motta.
Extensions er tunge: 40-50% av dataene vi faktisk trenger i vårt EPJ ligger i extensions. Disse er fryktelig tunge å jobbe med - og hva er poenget med en " standard" om den bare dekker 60% av dataene?
SFM-spesifikke problemer:
Mange ulike personidentifikatorer som er i bruk og er gyldige flere steder.
Synkroniseringsmekanismen: at vi må pushe data i mange ulike situasjoner fra EPJ-et, selv når ingen bruker SFM, er tungt å implementere.
Altfor lite støtte for maskin-til-maskin-tokens, noe som har ført til månedsverk med workarounds.
Mye data: FHIR bundles er enorme. Vi teller tusenvis av linjer for å hente ut noen få datapunkter.
Fordeler m/FHIR:
Enkel testing: Å kunne fange en JSON-bundle og bruke den i interne tester er veldig praktisk.
Forslag:
Ikke bruk FHIR: Lag et proprietært format fordi dere kan holde det enkelt - skjær ned så mye dere kan, og legg heller ting tilbake om dere tar vekk for mye. Kutt bort alle overflødige felter.
Enkle ID-er: Ha én ID for person, én ID for svangerskapskort etc. Ha et separat endepunkt for å slå opp disse på FNR, DNR etc. Det er mye lettere for oss om det er en felles intern ID vi kan normalisere koden rundt.
Bruk JSON: Slik at vi lett kan fange API-svar til bruk i egne tester.
Valideringsskjema: Lag et skjema som kan brukes til å validere JSON.
Synkronisering kun ved behov: Hvis dere trenger å synce data fra EPJ, gjør det på det tidspunktet man skal bruke API-et. For SFM skulle jeg ønske at vi kunne sende siste versjon av pasienter/practitioners i det øyeblikket vi åpner en portal.
Takk for at dere stiller spørsmålet og åpner for tilbakemeldinger. Vi er flere som river oss i håret over FHIR i forbindelse med SFM.

Tilbakemelding på DHG fra Omda ved Sassan

Fra et teknisk perspektiv er det for oss i Omda likegyldig om API’et bygges med FHIR som rammeverk, eller om det etableres et proprietært REST-API. Imidlertid mener vi at man bør benytte FHIR fra dag 1.
Omda forstår egentlig ikke hvorfor det er lagt opp til at man skal gjøre et slikt valg. Direktoratet for e-helse har en anbefaling om bruk av FHIR i denne type samhandlingsløsninger fra 2019, oppdatert i 2023. https://www.ehelse.no/standardisering/standarder/anbefaling-om-bruk-av-hl7-fhir-for-datadeling/ Vi har tillit til at de som har bidratt til utarbeidelse av denne anbefalingen har gjort et godt stykke arbeid og støtter denne anbefalingen fullt ut. Å lage et proprietært API for å komme fort i gang, for deretter å «oppgradere» til FHIR virker meningsløst. Vi regner med at alle involverte aktører her har erfaring med FHIR, og relativt raskt kommer i gang for å ta i bruk ett, eller et sett med nye grensesnitt. Det blir dobbeltarbeid, og merkostnad for alle parter.
Som andre har påpekt, er det andre momenter enn selve API-formatet som er viktigere i dette arbeidet for å lykkes. Å identifisere hvilke brukstilfeller og prosesser som skal støttes, hvilke kjøreregler gjelder for ajourhold av dataelementer som kan registreres av flere aktører (master data, sporbarhet), hvilke datasett utveksles (alt i ett, eller separate tjenester med subsett av informasjonsmodellen), osv. Videre ble det vel også nevnt at deler av informasjonsmengden i helsekortet også måtte samhandle med andre tjenester hos NHN, så da må man jo benytte FHIR uansett.
Hva gjelder modellering og profilering av svangerskap (og helsekortdata) i FHIR format, så er vi ikke først i verden. NHS har lagt ned et betydelig arbeid her (https://nhsconnect.github.io/FHIR-Maternity-Record/index.html) som det er mulig å bygge på. Vi i Omda har benyttet denne for å mappe vår interne informasjonsmodell til FHIR og opplever at det går helt fint, men at det selvsagt er noen extensions som må til for å få plassert alle dataelementer.