Metode for utvikling av HL7 FHIR områdeprofiler

Innledning

Veilederen beskriver en metode for hvordan norske områdeprofiler for HL7 FHIR skal utvikles, normeres og vedlikeholdes.

Formål og bruksområde

Veilederen beskriver hvordan HL7 FHIR kan tilpasses norske anvendelser, behov og krav. Metoden er en åpen og smidig prosess som skal sikre at profilene holder høy kvalitet og forankres hos alle relevante aktører i sektoren. De ferdige områdeprofilene blir publisert som normerende produkter (veiledere, retningslinjer og standarder).

Metoden er basert på utviklingsmetoden for HL7 FHIR, Direktoratet for e-helses forvaltningsmodell for normerende produkter og profileringshierarkiet for HL7 FHIR i Norge. Metoden viser hvordan områdeprofiler kan utvikles med en smidig utviklingsmetode. Den er publisert som et normativt produkt av typen veileder, se beskrivelse av normeringsnivå og dokumenttyper på ehelse.no. Utviklingen av områdeprofiler utføres av aktører i sektoren og normeringen av områdeprofilene utføres i henhold til Direktoratet for e-helses forvaltningsmodell.

Gjelder for

Målgruppen for metoden er aktører i norsk helse- og omsorgssektor som utvikler samhandlingsløsninger basert på standarden HL7 FHIR.

Krav i dokumentet

Kapitlene 'Prinsipper' og 'Metodebeskrivelse' betraktes som kravdelen av dokumentet. Kravdelen inneholder krav til dokumentasjon av, forankring av og innhold i de endelige implementasjonsguidene. Kravene som stilles i denne delen av metoden må tilfredstilles om implementasjonsguiden skal normeres som en områdeprofil.

Forvaltning av metoden

Metoden vil revideres etter hvert som sektoren får mer erfaring med bruk av HL7 FHIR standarden generelt og utvikling/bruk av områdeprofiler spesielt. For å se utkast eller gi innspill til neste versjon av veilederen, gå til GitHub til HL7 Norge.

Smidig utvikling av områdeprofiler

Utviklingen av en områdeprofil vil ofte skje i sammenheng med utviklingen av programvare/tjeneste som skal løse et samhandlingsbehov. Utviklingsarbeidet vil være smidig, dvs. det vil foregå før, under og etter at hele eller deler av områdeprofilen er normert. Utvikling, test og driftssetting av programvareproduktet trenger ikke være en del av utviklingsprosjektet for områdeprofilen, men i mange tilfeller vil disse være tett sammenkoblet eller del av samme prosjekt.

Definisjon områdeprofil

En nasjonal områdeprofil:

• tilpasser internasjonale FHIR-ressurser for samhandling i en definert anvendelse
• representerer informasjonsstrukturer som kan gjenbrukes på tvers av implementasjoner for det definerte anvendelsesområdet
• kan benyttes direkte i en implementasjon eller profileres ytterligere

Prinsipper

Følgende prinsipper gjelder for utvikling av områdeprofiler:

1: Anvendelsen for områdeprofilen er tydelig definert

Den konkrete anvendelsen for områdeprofilen må være tydelig definert og knyttet til samhandling. Anvendelsen kan være spesifikk eller mer generell.

2: Områdeprofiler er basert på basisprofiler der de finnes

Områdeprofiler skal gjenbruke tilpasninger gjort i nasjonal basisprofil for ressursen dersom disse finnes.

3: Profilene defineres ut fra anvendelsen

Detaljnivå er avhengig av behovene for gjenbruk i implementerte profiler. Detaljnivå er også avhengig av felles samhandlingsbehov for anvendelsen.

4: Områdeprofiler er utarbeidet basert på metode for områdeprofiler

Områdeprofiler skal følge prosess for utvikling og forvaltning av områdeprofiler med de innspillsrunder og forankringsprosesser som er beskrevet.

5: Områdeprofiler er uavhengige av samhandlingsmodell

Områdeprofiler representerer standardisering av innhold og skal som hovedregel kunne benyttes uavhengig av samhandlingsmodell (datadeling, meldingsutveksling, dokumentdeling, notifikasjon etc).

6: Områdeprofiler er basert på relevante internasjonale spesifikasjoner

Dersom det finnes relevante internasjonale spesifikasjoner for det aktuelle anvendelsesområdet skal disse vurderes brukt. Dersom det finnes flere internasjonale spesifikasjoner som kan benyttes for det relevante området, bør det gjøres en vurdering av relevans, marked, bruk av kodeverk etc for å bestemme hvilken spesifikasjon som er mest egnet som utgangspunkt for bruk i Norge.

7: En områdeprofil skal benytte must-support for informasjonselementerer

Must-support betyr at fagsystemer skal støtte og kunne behandle informasjon for disse elementene. Den enkelte implementasjonsguide bør beskrive spesifikt hvilke krav som følger av must-support. Ulike anvendelser kan ha ulike krav til must-support-elementer.

8: Områdeprofiler kan beskrive valgfrie utvidelser (extensions).

En områdeprofil kan angi valgfrie utvidelser som er aktuelle for gjenbruk for den gitte anvendelsen selv om den ikke er aktuell for alle implementasjoner. Dette bidrar til gjenbruk og konsistent bruk av utvidelser for det aktuelle anvendelsesområdet.

9: Områdeprofiler navngis alltid med prefix no-domain

Områdeprofiler skal navngis etter følgende struktur no-domain-<område>-<ressurs>-<kvalifikator>. Et eksempel på navn på en områdeprofil er no-domain-VitalSigns-Observation-bloodpressure.

10: Områdeprofiler skal publiseres som en implementasjonsguide

Implementasjonsguiden beskriver hvordan områdeprofilene for et gitt anvendelsesområde skal brukes. Områdeprofiler dokumenteres i henhold til beste praksis for implementasjonsguide.

11: Områdeprofiler skal utvikles og vedlikeholdes på en åpen plattform

Nasjonale områdeprofiler og implementasjonsguider er leverandør- og løsningsnøytrale. Kildekoden skal utvikles og forvaltes på en åpent tilgjengelig plattform som gjør det mulig for alle interesserte å delta.

Metodebeskrivelse

Metoden tar utgangspunkt i fasene som er beskrevet i forvaltningsmodellen for normerende produkter og beskriver hvilke oppgaver som må gjennomføres i hver av fasene når områdeprofiler skal utvikles.

Behov og krav

Behovene for områdeprofiler identifiseres hovedsakelig av virksomhetene i sektoren. En viktig oppgave i denne fasen er å beskrive anvendelsesområdet og beskrive problemstillingen områdeprofiler kan løse. Beskrivelsen ligger til grunn for gjenbruk av andre. Når behov og krav beskrives er det spesielt viktig å beskrive behov til informasjonsutveksling og elektronisk samhandling. Kravene som beskrives for profilene og implementasjonsguiden må dekke behovene som er identifisert.

I de fleste tilfeller er det behov for å forankre arbeidet med flere aktører i sektoren samt HL7 Norge og Direktoratet for e-helse. For at et sett med områdeprofiler skal utvikles må behovene drøftes med flere parter for å sannsynliggjøre at behovene er felles for sektoren og ikke bare gjelder én aktør. Ved iterativ gjennomføring vil fasen gjentas flere ganger. Hovedformålet blir da å prioritere og beskrive behovene og kravene for oppgavene som skal gjennomføres i denne iterasjonen.

Utrede

Prosjektet utredes i henhold til utredningsinstruksen. Omfanget av tiltaket (dvs. områdeprofilen) påvirker hvor omfattende utredningen blir. Utredningen kan utføres i en eller flere iterasjoner.

Utredningen skal ha et spesielt fokus på hvordan en norsk områdeprofil som dekker kravene passer sammen med internasjonale spesifikasjoner (som standarder) og om det er behov for nasjonale tilpasninger.

I tillegg til spørsmålene i utredningsinstruksen må følgende spørsmål besvares:

• Er arbeidet forankret i nasjonal styringsmodell?
• Hva er anvendelsens omfang? Vekte mellom spesialisering og generalisering.
• Hva finnes fra før, nasjonalt og internasjonalt?
  • Finnes allerede områdeprofil som dekker behovet i denne anvendelsen? Er det behov for profilering utover eventuell basisprofil for dette bruksområdet?
  • Er det behov for utvidelser? Finnes disse fra før?
  • Eksisterer standarder utover HL7 FHIR som er i bruk i Norge og dekker behovet?
• Er det potensiale for gjenbruk i andre prosjekter for (deler av) profileringen for den gitte anvendelsen?
  • Hvilke profilerte elementer er aktuelle for gjenbruk for gitt anvendelse?
  • Finnes det andre tilliggende områder man bør vurdere samordning med?

På bakgrunn av utredningen besluttes det om det skal gjennomføres et utviklingsarbeid og i hvilken grad dette skal basere seg på eksisterende spesifikasjoner.

Utvikle

Det skal under utviklingen av områdeprofilen dokumenteres hvordan behov og krav dekkes. En normert områdeprofil vil i de fleste tilfeller bestå av en implementasjonsguide som beskriver FHIR conformance-ressurser og hvordan disse er tilpasset og benyttet for å dekke kravene.

Utviklingen av produktet må gjennomføres i samarbeid med sektoren. Det er naturlig at det er et enkelt prosjekt som leder arbeidet.

Det må beskrives en plan for kvalitetssikring og test, inkludert testprosedyrer og verktøy.

Høringer, arbeidsmøter og innspillsrunder må planlegges i denne fasen. Normeringsnivået som er ønsket for områdeprofilen kan påvirke behovene for kvalitetssikring. For eksempel skal alle anbefalte eller obligatoriske standarder på høring.

Hvis det skal utvikles programvare som skal ta i bruk områdeprofilene, så skal utviklingen av funksjonalitet i programvareproduktet gjennomføres i denne fasen. Kvalitetssikringen av et eventuelt programvareprodukt må beskrives i et eget plandokument.

Hovedoppgaver i denne fasen:

• Utarbeide implementasjonsguide
  • Beskrive kontekst for samhandling
  • Hvilke profilerte elementer er aktuelle for gjenbruk for gitt anvendelse?
  • Valg av eventuell tilpasning til internasjonal IG
  • Valg av kodeverk og terminologi
  • Implementasjonsguiden bør skrives på engelsk
• Utvikling av conformance-ressurser
  • Dokumentasjon av conformance ressursene bør være en del av conformance ressursene
  • Conformance ressurser bør dokumenteres på engelsk
• Utarbeide plan og verktøy for kvalitetssikring – validering, utvikle eksempler, testprosedyrer for programvareproduktet
• Utarbeide plan for workshoper, innspillsrunder og eventuelt høring
• Utvikle programvare som tar i bruk profilene

Utprøve og evaluere

Testing og evaluering av områdeprofilen må gjennomføres i henhold til plan for kvalitetssikring, beskrevet i utviklingsfasen. Eventuelle programvareprodukter må testes i henhold til testplan.

Hovedoppgaver i denne fasen:

• Kvalitetssikring av normerende produkter kan gjennomføres med standardimplementasjoner for validering og tilgjengelige FHIR servere basert på åpen kildekode.
• Erfaringer fra utvikling og utprøvingsfasen håndteres som feilretting eller legger grunnlag for nye behov som kan utvikles i senere iterasjoner.
• Produkter som skal normeres går igjennom en innspillsrunde eller høring, og kan eventuelt ferdigstilles i denne fasen (gjøres klar til publisering).
• Virkemidler for at sektoren skal ta de normerende produktene i bruk beskrives. Hvis det er nødvendig med samtidig innføring må det utarbeides en plan for hvordan en innføring skal gjennomføres. Eventuelle grensesnitt som er utvikles kan også omfattes av denne planen.
• Ny funksjonalitet utviklet i eventuelle programvareprodukt utprøves og evalueres. Det må besluttes om programvareproduktet holder god nok kvalitet til at ny funksjonalitet kan realiseres.
  • Der områdeprofiler ikke utvikles samtidig med et programvareprodukt må profilene kvalitetssikres og evalueres av andre prosjekter som tar i bruk profilene i faktiske produkter, tester disse og gir tilbakemeldinger om behov for endringer/feilrettinger i profilene.

Realisere

Hovedoppgaver i denne fasen:

• Områdeprofilen(e) publiseres som en implementasjonsguide i henhold til forvaltningsmodellen og valgt normeringsnivå.
• Informere om områdeprofilene i henhold til prosessbeskrivelser i forvaltningsmodellen og HL7 Norges informasjonskanaler.
• Hvis en områdeprofil utvikles i sammenheng med et programvareprodukt må ny funksjonalitet settes i drift.
• Det må settes i gang arbeid for at relevante eksterne aktører skal ta i bruk profilene og/eller grensesnittet som er utviklet i henhold til plan for realisering, innfasing og utbredelse.

Normere

Normering foregår i henhold til Direktoratet for e-helses forvaltningsmodell

Hovedoppgaver i denne fasen:

• Bestemme modenhetsnivå på profilene ut fra erfaringer fra faktiske implementasjoner
• Beskrive en plan for vedlikehold av normerende produkter

Vedlikehold og forvaltning av områdeprofiler

Som hovedregel gjennomføres vedlikehold og forvaltning av områdeprofiler etter den samme metoden som utviklingen. Det betyr at fasene kan benyttes også i et forvaltningsløp for områdeprofiler. Vedlikehold og forvaltning gjennomføres av en rolle som kalles "ansvarlig forvalter". Den ansvarlige forvalteren må være en profesjonell part som en organisasjon, eller vedvarende interessegruppe. Ansvarlig forvalter kan fordele oppgaver som f.eks. daglig vedlikehold til andre etter avtale.

1. Behov og krav: Det identifiseres nye behov og krav som påvirker programvareproduktet og/eller områdeprofilen. Behovene for endring forankres i henhold til styringsmodellen for områdeprofilene.

1. Den ansvarlige forvalteren må systematisk motta og dokumentere endringsønsker/bugs, gjennomføre en åpen prosess om behandling av endringsønsker og implementere nødvendige endringer i områdeprofiler.
2. Det anbefales å forvalte områdeprofiler og håndtere bugs/endringsønsker i åpne prosjekter på Github som Issues og pull requests.

2. Utrede: Det utredes hvorvidt de nye kravene bør prioritere en nyutvikling/endring i programvareprodukter og normerende produkter

1. Ansvarlig forvalter må forankre behovet for endringer i områdeprofilene hos relevante aktører og i henhold til forvaltningsmodell for normerte produkter
2. Dersom flere programvareprodukter baserer seg på områdeprofilene må forslag til endringer drøftes med aktørene som blir berørt

3. Utvikle: Endringer i programvareprodukter og normerende produkter utvikles og gjøres klar for testing og evaluering

1. Ansvarlig forvalter må sørge for profiler, implementasjonsguider og programvareprodukter utvikles i henhold til feilrettinger og endringsønsker der det foreligger beslutning om å gjennomføre endring
2. Det må utarbeides plan for testing og evaluering for å undersøke om endringen fungerer etter hensikten

4. Utprøve og evaluere: Det gjennomføres testing, evaluering, innspillsrunder og eventuelle høringer hvis det vurderes som nødvendig grunnet endringens størrelse

1. Ansvarlig forvalter må sørge for at testing, evaluering og innspillsrunder og eventuelle høringer gjennomføres

5. Realisere: De nye/oppdaterte områdeprofilene publiseres og programvareløsninger oppdateres.Det arbeides med at de oppdaterte spesifikasjonene skal tas i bruk i sektor i henhold til plan

1. Ansvarlig forvalter sørger for publisering

6. Normering: Direktoratet for e-helse normerer den oppdaterte/nye områdeprofilen. Områdeprofiler som erstattes av nye må ha en plan for utfasing.

1. Ansvarlig forvalter foreslår for Direktoratet for e-helse at ny versjon bør normeres
2. Ansvarlig forvalter kan også foreslå utfasing av eldre versjoner av den aktuelle områdeprofilen

Bruk og forvaltning av metoden

Metoden som er beskrevet kan anvendes smidig gjennom kontinuerlige iterasjoner og det er forventet at metoden må tilpasses etter behov i det enkelte utviklingsprosjekt. Metoden må tilpasses utviklingsprosjektet avhengig av prosjektets størrelse og kompleksitet. En viktig egenskap ved prosjektene som vurderes er om det skal utvikles dokumentasjon som skal testes av eksterne programvareprodukter, eller om prosjektet også skal inkludere utvikling av programvare som skal ta profilene i bruk. Slike valg vil påvirke innhold og detaljeringsnivå i de forskjellige fasene.

Iterativ bruk av metoden

Metoden er beskrevet for at den skal være enkel å benytte flere iterasjoner ved gjennomføringen av et prosjekt. Ved iterativ tilnærming må resultatet av realiseringen i forrige iterasjon legge grunnlaget for arbeidet i neste iterasjon.

I fasen «behov og krav» er det fokus på å styre aktiviteten i riktig retning basert på erfaringer fra tidligere iterasjoner. Erfaringsmessig kan både behov og krav endres basert på erfaringer som gjøres underveis i utviklingsarbeidet. Endringer i behov og krav vil påvirke spesifikasjon og det ferdig implementerte produktet. Fasen må også inneholde en prioriteringsaktivitet hvor oppgaver som skal løses i neste iterasjon/sprint diskuteres og arbeidet i neste iterasjon planlegges.

De forskjellige iterasjonene kan ha fokus på hele eller deler av modellen. I en kravfase kan man for eksempel ha stort fokus på behov, krav og utvikling av kravspesifikasjon og profiler. I en realiseringsfase fokuserer prosjektet på å klargjøre kravbeskrivelsen for implementasjon og har fokus på testing og realisering av en løsning som skal tilby funksjonaliteten som er beskrevet i kravene.

Forvaltning av metoden

Metode for utvikling av områdeprofiler skal forvaltes og videreutvikles som et samarbeid mellom alle aktører i sektoren og forankres med HL7 Norge og Direktoratet for e-Helse gjennom en åpen prosess og via åpne kanaler slik det slås fast i Prinsipp 11.

Vedlikehold og forvaltning av metoden gjennomføres etter metode for utvikling av områdeprofiler. Det betyr at fasene metoden beskriver kan benyttes også i et forvaltningsløp for selve metoden. Ansvarlig forvalter er Direktoratet for e-helse, men hele sektoren må gi innspill til endringer etterhvert som de opparbeider seg erfaringer med bruk av metoden.

Normert versjon av metoden og utviklingsversjon

Metoden som er publisert på denne nettsiden er normert av Direktoratet for e-helse og gjenspeiler den kvalitetssikrede og normative beskrivelsen av metoden.

Samtidig vil det eksistere en utviklingsversjon av metoden på HL7 Norges GitHub. Denne vil bli oppdatert løpende etter innspill fra sektor etter som man får erfaringer med bruk. Ved store forskjeller mellom normert versjon og utviklingsversjon vil endringene fra utviklingsversjonen bli inkludert i den normerte, og en revidert utgave vil bli publisert på ehelse.no.

Modenhetsnivå og normeringsnivå for områdeprofiler

Metoden for områdeprofiler tar i bruk modenhetsnivå og normeringsnivå for å muliggjøre iterativ utvikling av områdeprofiler. Normeringsnivåene definert i forvaltningsmodellen gjør det mulig å utvikle normerte produkter med lavere normeringsnivå som siden kan utvikles til retningslinjer og anbefalte/obligatoriske standarder når aktørene får erfaringer fra implementasjon og bruk av områdeprofilene.

Modenhetsnivåene definert av HL7 International beskriver hvordan man kategoriserer modenheten til enkeltartefakter i en spesifikasjon. Metoden beskriver hvordan modenhetsnivåene benyttes for å utvikle og skaffe erfaringer med deler av et artefakt og synliggjør nivået av erfaring knyttet til hvert enkelt artefakt i implementasjonsguiden. Metoden beskriver også hvilket modenhetsnivå som kreves for å publisere et artefakt på et gitt normeringsnivå.

Bruk av normeringsnivå for områdeprofiler

Direktoratet for e-helse publiserer normerende produkter innenfor fire definerte normeringsnivå. Nivåene er definert ut fra krav til kvalitetssikring, forankring og kunnskapsgrunnlag for produktet. Det er naturlig at normeringen av områdeprofiler gjennomføres i henhold til de definerte normeringsnivåene. Normeringsnivåene og kravene til normerende produkter som skal falle inn under de forskjellige nivåene er beskrevet i forvaltningsmodellen for normerende produkter.

For områdeprofilene vil betydningen av normeringsnivåene være:

Veileder: En områdeprofil som er publisert som veileder betyr at virksomheter og prosjekter som utvikler eller anskaffer løsninger hvor anvendelsesområdet faller helt eller delvis innenfor en eller flere områdeprofiler bør vurdere å benytte de publiserte områdeprofilene for samhandlingsløsninger.

Retningslinje: En områdeprofil som er publisert som retningslinje betyr at de delene av løsningen som hvor anvendelsesområdet faller helt eller delvis innenfor omfanget av en eller flere områdeprofiler skal følge disse. Det kan aksepteres at det ved særlige og godt begrunnede omstendigheter kan likevel føre til at deler av områdeprofilen ikke tas i bruk for løsningen.

Anbefalt standard: En områdeprofil som er publisert som anbefalt standard betyr at løsninger i tilknytning til det definerte anvendelsesområdet skal benytte standarden med mindre det er svært gode grunner til å ikke gjøre det.

Obligatorisk standard: En områdeprofil som er publisert som obligatorisk standard betyr at den er hjemlet i forskrift. En obligatorisk standard skal følges med mindre det er gitt unntak med hjemmel i forskriften. En løsning hvor deler av anvendelsesområdet faller inn under det definerte området for en områdeprofil må virksomheten som har ansvar for prosjektet følge standarden eller søke om unntak fra forskriften.

Krav til modenhetsnivå for områdeprofiler

HL7 International benytter modenhetsnivå for å angi hvor godt en del av en standard er testet og utprøvd. I forbindelse med utarbeidelse og normering av områdeprofiler skal modenhetsnivåer benyttes for å angi hvordan de forskjellige delene av områdeprofilen, typisk definerte profiler og utvidelser, er utprøvd i praktisk bruk. Modenhetsnivået for hvert artefakt defineres som en del av implementasjonsguiden.

Kartlegging og vedlikehold av modenhetsnivå

For å kartlegge hvilket modenhetsnivå et artefakt har må aktøren som forvalter artefaktet kartlegge hvordan denne er implementert, testet og tatt i bruk i egen organisasjon og av andre aktører. Det anbefales at kartleggingen gjennomføres i samarbeid med HL7 Norge og Direktoratet for e-helse. Etter hvert som områdeprofilen utvikles og tas i bruk av flere aktører vil modenhetsnivået øke. Dette signaliserer at flere virksomheter har gjennomført flere implementasjoner og har profilene i test og drift, slik at profilene har høyere modenhet.

Modenhetsnivå for norske områdeprofiler

Beskrivelsen av modenhetsnivå for de norske områdeprofilene bygger på HL7 International sine modenhetsnivå men er en omskrivning av disse for norske forhold.

Flere av modenhetsnivene krever at det er gjennomført forankring og sendt informasjon til HL7 Norge og Direktoratet for e-helse.

Enkelt-artefakter i en Implementasjonsguide kan ha forskjellige modenhetsnivå. En IG som skal normeres må minst inneholde artefakter av nødvendig modenhet for å normeres på et gitt normeringsnivå.

Kravkategorier i European Interoperability Framework 2.0

European Interoperability Framework 2.0 (EIF) viser hvilke lag som må på plass for å oppnå samhandlingsevne. Det kan finnes norske og internasjonale krav som skal eller bør følges når man utvikler en områdeprofil og implementasjonsguide. Dette skal kartlegges som en del av fasen Utrede.

Se også Rammeverk for digital samhandling hos Digitaliseringsdirektoratet om EIF.

Juridisk samhandlingsevne

Finnes det juridiske krav til hva som skal overføres? Juridiske krav kan omhandle og legge føringer for alle underliggende lag. Eksempel er krav om foreldresamtykke for barn under 16 år ved henvisning til spesialisthelsetjeneste, jamfør pasient- og brukerrettighetsloven § 4-4 første ledd. Dokumentasjonen bør oppgi juridiske relevante krav.

Organisatorisk samhandlingsevne

Baserer anvendelsen seg på en allerede dokumentert forretningsprosess? Skal den svare ut et identifisert samhandlingsområde? Eksempel er veiledere fra Helsedirektoratet og prosessbeskrivelse for E-resept. Dokumentasjonen skal inneholde en beskrivelse av anvendelsen, og skal referere eller gjengi eventuelle dokumenterte forretningsprosesser hvis de er lagt til grunn.

Semantiske samhandlingsevne

Områdeprofilene vil ofte basere seg på eksisterende informasjonsmodeller og kodeverk/terminologi.

Forretningsprosessen over vil også kunne gi bestemte krav til innholdet som skal utveksles.

Eksempler er HL7 FHIR (implisitt), IPS, IDMP, OpenEHR Archetypes, SNOMED CT og ICPC-2. Dokumentasjonen skal oppgi hvilke semantiske standarder eller spesifikasjoner som ligger til grunn. Den bør også oppgi om områdeprofilen etterstreber å støtte en standardisert informasjonsmodell 1:1, er en utvidelse/innskrenkelse eller er brukt som generelt underlag (inspirasjon).

Teknisk samhandlingsevne

Områdeprofiler er agnostiske med tanke på teknisk utveksling, utover at det er HL7 FHIR JSON/XML (implisitt). Krav til teknisk samhandlingsevne dokumenteres ikke, men finnes i de respektive samhandlingsarkitekturene (datadeling, dokumentdeling, meldingsutveksling).

Områder

Et sentralt konsept i forbindelse med områdeprofilering i HL7 FHIR definisjonen av områdene som en områdeprofil skal virke innenfor. Følgende to rammeverk bør benyttes for å kategorisere og beskrive områdene for områdeprofilering;

Samhandlingsområder

I arkitekturarbeidet eksisterer det flere rammeverk for å kategorisere og beskrive ulike områder for samhandling. Produsenter av områdeprofiler må kunne beskrive hvilket samhandlingsområde anvendelsen sorterer innenfor og beskrive sammenhengen med andre samhandlingsområder. Samhandlingsområdet beskrives i implementasjonsguiden.

Eksempler på samhandlingsområder: Rapportering, Klinisk oppsummering, Tjenestekatalog, Planer, Innbyggers opplysninger og ønsker og Legemidler og vaksiner.

FHIR Composition Framework

HL7 FHIR-standarden kategoriserer ressursene og deler disse inn i en lagdelt struktur:

1. Foundation Resources (Security, Conformance, Terminology, Documents, Other)
2. Base Resources (Individuals, Entities, Workflow, Management)
3. Clinical Resources (Clinical, Diagnostic, Medications, Care Provision, Request & Response)
4. Financial Resources (Support, Billing, Payment, General)
5. Specialized Resources (Public and Health & Research, Definitional Artifacts, Clin. Dec. Support, Quality Reporting)
6. Resource Contextualization (Profiles, Graphs)

Områdeprofiler bør settes inn i sammenhengen med FHIR Composition Framework og forklare hvorfor nettopp dette settet med ressurser benyttes for å løse samhandlingen innen området. Det må også forklares hvordan området relaterer seg til andre nærliggende og beslektede områder.

Bakgrunn

Strategisk retning innen normering

Internasjonale standarder og internasjonalt samarbeid om e-helse er og vil bli mer aktuelt i fremtiden. Direktoratet for e-helses rapport Utviklingstrekk 2020 peker på at utfordringer innen helsesektoren er sammenfallende for flere land og at det er viktig å være med i internasjonalt standardiseringsarbeid for å utvikle, lære og bidra til felles løsninger.

Direktoratet for e-helse har tidligere utarbeidet en strategi som er beskrevet i Plan for e-helse 2019-2022 med de tre fokusområdene nasjonal styring, standardisert informasjonsinnhold og internasjonale standarder. Veikart og planer for e-helsestandarder 2018-2022 følger opp strategien gjennom å beskrive tiltak innenfor internasjonale standarder for datadeling og dokumentdeling.

Direktoratets anbefalinger

I 2019 ble det utgitt retningslinje hvor direktoratet anbefaler bruk av FHIR for datadeling. Samme år ble også 13 FHIR basisprofiler utviklet i samarbeid mellom sektor, HL7 Norge, og Direktoratet for e-helse normert som anbefalt standarder i referansekatalogen.

Det er også arbeidet med prinsipper og tiltak for nasjonal styring og forvaltning av FHIR. FHIR er en viktig standard som nå tas i bruk i mange sammenhenger, og arbeidet med denne vil også fungere som utprøvingsarena for prosesser, rutiner og koordinering med andre internasjonale standarder.

Metodegrunnlag

Forslaget til metode bygger i hovedsak på eksisterende metoder innen normering, arkitektur og programvareutvikling.

Smidig tilnærming

Det er et ønske om å modernisere hvordan programvareutviklingen og normeringen blir gjennomført i helsesektoren. Det er et mål at normeringsaktiviteter i større grad er basert på dokumenterte behov i sektoren, og hvor sektoren er motivert til å delta i normeringsarbeidet både i standardiseringsorganisasjoner (som HL7 Norge) og i samarbeid med Direktoratet for e-helse. Dette betyr at normeringsarbeidet må henge sammen med utviklingsprosjekter i sektoren og følge en smidig tilnærming hvor normeringsproduktene leverer verdi til sektor underveis i utviklingsløpet og blir videreutviklet og komplettert i videre iterasjoner.

Smidig tilnærming betyr at normeringsproduktene eller deler av disse må utvikles, testes og settes i drift i løpet av en sprint slik at man kan evaluere hvordan produktet fungerer i praksis. Dette vil vanligvis være avhengig av at normeringsaktiviteten er koblet til en utviklingsaktivitet.

Forvaltningsmodellen

Forvaltningsmodell for normerende produkter beskriver hvordan Direktoratet for e-helse skal utvikle og forvalte normerende produkter.

Metode for utvilkling av HL7 FHIR områdeprofiler beskriver hvordan utviklingen av områdeprofiler forholder seg til forvaltningsmodellen og omvendt.

HL7 FHIR utviklingsmetode

HL7 International benytter i utviklingen av HL7 FHIR selv en form for iterativ metode. Standarden blir normert over flere år og det er i skrivende stund bare deler av standarden som anses som normativ. I utviklingen av en metode for områdeprofiler er det derfor naturlig å gjenbruke de samme mekanismene for standardisering som HL7 benytter i utviklingen av FHIR, blant annet maturity model.

Profileringsnivåer for HL7 FHIR i Norge

I Norge arbeides det med profilering av HL7 FHIR på flere grader av detaljering. Øverst i det norske profileringshierarkiet har vi norske basisprofiler som skal sammenfatte omforente krav til hvordan FHIR ressurser skal benyttes i Norge uavhengig av anvendelsesområde. Disse profilene er åpne og inneholder bare det alle aktører er enige om med hensyn til koding og navngivning av ressurser og navnerom. De norske områdeprofilene er ment som et profileringsnivå under basisprofilene og har som formål å presisere bruk av HL7 FHIR innen et bestemt anvendelsesområde. Prosjekter og implementasjoner kan deretter velge å profilere implementerte profiler knyttet til en konkret implementasjon. Disse kan inneholde spesifikke krav som bare gjelder innenfor en virksomhet.

Prosjektveiviseren

Metoden baserer seg på Digitaliseringsdirektoratets veileder for bruk av smidig metode for programvareutvikling, Prosjektstyring og smidig utviklingsmetodikk. Digitaliseringsdirektoratets veileder beskriver hvordan smidig kan benyttes i alle prosjektets faser og beskriver eksempler på epos og hvordan de forskjellige fasene i prosjektmodellen kan deles inn i flere sprinter/iterasjoner.

Termer og definisjoner

Ansvarlig forvalter

Ansvarlig forvalter beskriver en aktør som tar ansvar for forvaltningen av et normerende produkt i form av en områdeprofil. Aktøren har hovedansvaret for å følge opp og sørge for fremdrift i utviklingen og vedlikeholdet av kildekode (FHIR conformance ressurser) og dokumentasjon i form av Implementasjonsguide. Aktøren har også ansvar for å melde fra til Direktoratet for e-Helse når en ny hovedversjon av produktet skal normeres i henhold til forvaltningsmodellen.

Conformance ressurs

Alle HL7 FHIR artefakter som beskriver semantiske krav til en HL7 FHIR implementasjon.

HL7 FHIR

Fast Healthcare Interoperability Resources. Standard for samhandling med helseopplysninger ved hjelp av ressurser utviklet og normert av organisasjonen HL7 International.

Implementasjonsguide (IG)

Spesifikasjon som beskriver om hvordan den semantiske samhandlingen skal løses for en bestemt anvendelse.

Normerende produkter

Veiledere, retningslinjer og standarder som Direktoratet for e-helse har fastsatt. De kan omhandle internasjonale standarder, kodeverk, klassifikasjoner, terminologi, arkitektur, informasjonssikkerhet mv. Produktene kan utvikles og forvaltes av både Direktoratet for e-helse og andre organisasjoner, men det er Direktoratet for e-helse som setter normeringsnivå.

I forbindelse med normering av områdeprofiler vil et normerende produkt være en bestemt versjon av en implementasjonsguide som beskriver områdeprofilen for en anvendelse.

Profil

I denne sammenhengen betegner en profil en HL7 FHIR profil. En FHIR profil er en av HL7 FHIR artefaktene som benyttes for å beskrive semantiske krav til samhandlingen for en bestemt anvendelse. Sammenhenger mellom profiler og andre HL7 FHIR conformance ressurser er beskrevet i en Implementasjonsguide.

Kontakt