Innehållsförteckning

Introduktion

FHIR står för Fast Healthcare Interoperability Resources och är en standard för att etablera interoperabel samverkan kring informationsutbyte av hälsodata. Standarden i sig består i princip av en grundstruktur av resurser, en metodik för hur man skapar anpassningar av resurser, samt ett ekosystem kring hur man hanterar och kommunicerar kring FHIR-baserade tjänster.

Standarden har anammats i USA samt i flera europeiska länder och tack vare dess breda utbredning håller det på att skapas ett ekosystem kring standarden. I Sverige skapas nationella profiler av FHIRs resurser av HL7 Sverige. Flera leverantörer av vårdinformationssystem inför utökat stöd för FHIR, samtidigt som man kommunicerar att FHIR-standarden är det sätt på vilket man primärt önskar kommunicera med ekosystemet runt vårdinformationssystemen. E-hälsomyndigheten har anammat FHIR för sina nya gränssnitt för Nationella Läkemedelslistan (NLL).

Mycket pekar på att FHIR även i Sverige kommer bli en viktig standard för utbyte av vårdinformation och med T2 - FHIR ges stöd kring hur kommunal och regional vård och omsorg kan närma sig standarden.

HL7 Sverige ansvarar för att ta fram FHIR-basprofiler anpassade för en svensk kontext. De basprofiler som finns publicerade av HL7 Sverige bör i allra högsta mån ligga som grund för de profileringarna som sen tas fram inom ramarna för en viss informationsfederation.

Läsanvisningar

Vägledning T2 FHIR läses med fördel efter det att läsaren gjort sig bekant med de grundläggande koncepten från T2 – referensarkitektur för interoperabilitet inom svensk välfärd (T2 - välfärden) och T2 – referensarkitektur för interoperabilitet inom svensk vård och omsorg (T2 - vård och omsorg). Vägledningen bygger vidare på resultatet i dessa referensarkitekturer, så många av de begrepp som används här härstammar därifrån.

Goda kunskaper inom interoperabilitetsstandarden HL7 FHIR (nedan refererat till som FHIR) och dess uppbyggnad är också en förutsättning för att läsaren ska kunna tillgodogöra sig innehållet i vägledningen. Den version av standarden som belysts i den här vägledningen är version 4.0.1 - R4.

Syfte med vägledningen

Syftet med vägledningen är att den som arbetar med arkitektur och som avser att etablera en FHIR-baserad integration utifrån referensarkitekturen T2 - vård och omsorg, ska kunna få stöd i vägval kring hur tillämpliga byggblock kan användas för att realisera de mönster som beskrivs i referensarkitekturen. Fokus är på de delar av integrationsbehoven där FHIR kan bidra och hur detta kan gå till. Vägledningen kan också fungera som underlag för att fatta beslut om vilka gemensamma stödtjänster i realiserad infrastruktur som ska erbjudas via FHIR-gränssnitt.

Avgränsning

Vägledning T2 FHIR avser inte hantera frågor kopplat till organisatoriskt ansvar. Vilken aktör som bör besluta om vad som ska gälla i olika avseenden för olika kontexter berörs. Inte heller adresseras specifika behov kring hur viss information ska representeras med hjälp av FHIR-standarden.

Sammanfattning

Vägledning T2 FHIR är en utredning av hur standarden HL7 FHIR lämpar sig för att realisera vissa byggblock i T2 - välfärdens arkitekturella modell. Sammanfattningsvis konstaterar utredningen att det inte finns några byggblock där FHIR är självklar grund för realisering.

Nedan redovisas resonemang, problematisering och möjliga lösningar kring användning av FHIR i realisering av vissa byggblock från T2 - välfärdens arkitekturella modell.

För att hantera de befintliga resursernas svagheter för att realisera stödtjänster så går det att tänka sig att antingen skapa nya FHIR resurser eller arbeta med extensions. Om detta är den rätta vägen att gå behöver isåfall utredas och då kanske främst utifrån ett implementatörsperspektiv.

Ett alternativ är att utforma stödtjänsterna på andra API-standards, men även detta behöver då utvärderas utifrån implementatörernas perspektiv.

Arkitekturvägledning

Nedan presenteras resonemang kring lämpligheten att använda FHIR-standarden för att realisera byggblock. Utgångspunkten är de mönster och centralt realiserade digitala stödtjänster som finns beskrivna i T2 - vård och omsorg. Exempel för att belysa resonemangen som behöver föras vid realisering av dessa digitala stödtjänster inkluderas i de fall FHIR-standarden inte självklart svarar mot behoven som den digitala tjänsten har. Notera att texten nedan inte är en instruktion till hur de digitala lösningarna ska utformas utan snarare är till för att belysa utmaningar med att tillämpa FHIR-standarden i de aktuella fallen.

Mönster

T2 - välfärden beskriver aktörsmönster, informationsutbytesmönster och samverkansmönster som är tillämpliga oavsett verksamhetskontext där samverkan ska ske. FHIR kan användas som interoperabilitetsstandard för samtliga av dessa mönster och interaktioner.

FHIR erbjuder metoder för informationsutbyte som kan användas för att realisera de informationsutbytesmönster som beskrivs i T2 - välfärden.

Gällande samverkansmönstren kan en del av arkitekturbyggblocken realiseras med FHIR-standarden. En genomgång av dessa byggblock följer nedan.

Byggblock och digitala stödtjänster

T2 - välfärden beskriver ett antal byggblock som behövs för interoperabel samverkan. T2 - vård och omsorg redovisar hur dessa byggblock kan användas för att skapa gemensamt realiserade digitala stödtjänster.

Denna vägledning belyser hur FHIR i vissa fall kan tillämpas för byggblock och gemensamt realiserade stödtjänster:

• Informationsaggregering (byggblock)

• Informationslokalisering (byggblock)

• Tjänstekatalog (realisering av byggblocken Tjänstesökning och Tjänsteregistrering)

• Verksamhetsförmågekatalog (byggblock)

• Interoperabilitetsspecifikation (byggblock)

• Teknisk interoperabilitetsspecifikation (byggblock)

• Semantisk interoperabilitetsspecifikation (byggblock)

Informationsaggregering

T2 - vård och omsorg beskriver tre mönster för informationsaggregering som alla går att realisera med hjälp av FHIR:

• Hämta information från alla möjliga källor, aggregera själv.

• Hämta information från källor givna av informationsindex, aggregera själv.

• Hämta aggregerad information från aggregerande tjänst, vilken i sin tur frågar källor givna av informationsindex.

Om aggregeringen sker i en aggregerande tjänst kan FHIR-resursen Bundle användas för att sammanställa det aggregerade svaret till API-klienten. Bundle-resursen kan också i sig innehålla Bundle-resurser vilket ger möjligheten att hålla ihop resurser från en FHIR-server inom en aggregerad last.

Vid klientaggregering ansvarar klienten själv för att sammanställa svaren från de olika digitala tjänsterna och kan då själv ta beslut om till exempel responsiv presentation, paging och felhantering.

I alla exempel där information aggregeras finns behov av att lokalisera relevanta källor. Detta kan göras genom realisering av byggblocket Informationslokalisering.

Informationslokalisering

Informationslokalisering handlar om att aktörer ska kunna identifiera var det finns befintlig information som behövs vid ett visst tillfälle. Förutsättningar kring att lokalisera information är beroende av informationstyp och lagrum.

Informationslokalisering som byggblock går att realisera på en mängd olika sätt och med olika skärning. Detta beskrivs i detalj i T2 VO - Teknisk vy. Informationslokalisering kan vara patientcentrisk (till exempel “hitta en patients bokade tider”) eller orienterad kring något annat verksamhetskoncept (till exempel “hitta lediga tider av en viss sort hos en viss vårdgivare”).

För Informationslokalisering i ett sammanhang där inblandade API:er redan är kända och antal anrop är få kan hela FHIR:s ramverk för sökning anses vara lämpligt att hänvisa till. I praktiken innebär det att API:erna anropas med en förfrågan om information direkt utan att en informationssökning gjorts i ett separat index.

En rad frågeställningar uppstår då man vill exponera ett informationsindex med hjälp av FHIR. Standarden har ingen dedikerad resurs för indexposter och ger heller ingen vägledning till hur man ska etablera ett index. Däremot kan man, om behoven man har av indexering matchar väl med FHIR:s resurser, kunna använda dessa som indexposter.

Frågeställningar att beakta vid realisering av gemensamt index

• Utvärdera vilken typ av index som behövs utifrån de varianter som presenteras i T2 - vård och omsorg.

• Identifiera den information som är central att lokalisera utifrån.

  • Se om det finns en resurs i FHIR som möter behovet.

  • Om behovet spänner över fler än en resurs, säkerställ att det finns sätt i standarden att länka samma dem med varandra.

• Ofta har man behov av att koppla samman informationsförekomst till en organisation. Den kopplingen är långt ifrån självklar i FHIR då inte alla resurser har en direkt koppling till en Organization-resurs.

• För att knyta samman informationen till en organisations tekniska anslutningspunkt kan resursen Endpoint vara intressant att titta närmare på. Endpoint har dock begränsade kopplingar till andra resurser vilket gör att den inte är lämplig för alla typer av index. Den tillhandahåller däremot en direkt koppling till den tekniska URLen vilket annars behöver lösas ut genom byggblocket Tjänstesökning.

• Avgränsa resursen/resurserna till att enbart innehålla den för behovet väsentliga informationen

  • Använd FHIR:s profileringsstöd för att minimera mängden information som behöver ligga i den eller de komponenter som realiserar byggblocket Informationslokalisering. För närmare beskrivning av hur Inera rekommenderar att profileringen utförs hänvisas till Profileringsanvisning.

Exemplifiering av olika index

Nedan följer ett antal exempel med tillhörande resonemang som kan användas som stöd vid arkitekturella beslut.

Tunt patientinformationsindex

Detta är ett exempel på ett index där det räcker att veta att en patient haft ett engagemang någonstans, oavsett typ. I det fallet skulle en ansats med FHIR kunna vara att profilera resursen Patient till att enbart innehålla attributet Patient.identifier. Utmaningen här är att sen koppla det till en organisation eller ett system eftersom de kopplingar till resursen Organization som finns i Patient-resursen i FHIR har en snävare semantik än den som efterfrågas här (vem som är General Practitioner respektive vem som är ägare/förvaltare av patientens journal). FHIR-resurser saknar i allmänhet koppling till URLer. Det är enbart i infrastrukturresurserna Endpoint och CapabilityStatement som URLer finns.

Slutsatsen blir att Patient-resursen för att kunna vara tillämpbar för detta syfte kräver att man lägger på en extension för att täcka in det informationsbehov som naturligt saknas i resursen.

Patients bokade tider

Detta är ett exempel på ett index där man vill veta vilka bokade tider som finns för en viss patient. I det fallet behöver sannolikt ett antal olika resurser i FHIR kombineras för att representera den information som krävs för att indexet ska fungera. Det kan lösas på olika sätt i FHIR, men ett förslag skulle kunna vara:

Om man vill kunna använda indexet i lokalisering som är centrerat kring annat än patient så behöver indexposten utökas med de attribut som är relevanta, till exempel:

Sammantaget krävs i det här fallet fyra olika resurser (Appointment, Patient, HealthcareService och Organization) för att representera indexposten “patienten har en bokad tid hos den här organisationen”.

Lediga tider av en viss typ

Detta är ett exempel på ett index där man vill veta vilka lediga tider av en viss typ som finns tillgängliga. Syftet är att utifrån det kunna visa lediga tider inför en bokning. FHIR har en modell för att lösa ut hela flödet kring tidbokning som man i det här fallet får hoppa in i mitten av:

FHIR tänker sig ett schema (Schedule) med ett antal bokningsbara tider i (Slot). När dessa bokas görs det genom att en bokning (Appointment) skickas in varpå en bekräftelse/ett svar (AppointmentResponse) skickas till den som bokat.

I det här fallet skulle indexet kunna innehålla Slot-resurser, sannolikt i kombination med dess respektive Schedule-resurs som man använder för att peka ut vilken typ av verksamhet som indirekt bedrivs på den lediga tiden (Schedule.serviceCategory, Schedule.serviceType respektive Schedule.specialty). Därtill behövs sannolikt även en koppling till utförande organisation, vilket i sin tur görs genom att koppla Schedule mot HealthcareService som i sin tur kopplas till en Organization.

Tjänstekatalog

En tjänstekatalog är en realisering av byggblocken Tjänstesökning och Tjänsteregistrering.

Tjänstesökning och Tjänsteregistrering tillhandahåller förmågan att utforska vilka organisationer som erbjuder relevanta digitala tjänster för ett visst syfte, hur tjänsterna ska registreras, adresseras samt hur de ska användas (tjänstens utformning).

Digitala tjänster kan behöva utforskas utifrån några huvudsakliga perspektiv:

• Vilka digitala tjänster finns för en viss organisation.

• Vilka organisationer tillhandahåller en viss digital tjänst.

• Vilken teknisk anslutningsadress har en specifik digital tjänst hos en viss organisation.

De två förstnämnda perspektiven behöver som regel kunna antingen returnera metadata som beskriver tjänstens utformning i mer detalj och användning alternativt returnera en referens till var utökad information om den digitala tjänsten kan hämtas.

Frågeställningar att beakta vid realisering av en tjänstekatalog

När FHIR ska utvärderas som lämpligt för realisering av en tjänstekatalog, behöver följande frågeställningar utforskas:

• Hur kan digitala tjänster beskrivas?

• Finns det möjlighet att beskriva vilka organisationer som stödjer en digital tjänst?

• Hur kan teknisk anslutningsadress representeras i FHIR?

• Hur kan en FHIR-servers förmågor/egenskaper representeras?

Beskrivning av FHIR-resurser som kan användas för att realisera en tjänstekatalog

ImplementationGuide

ImplementationGuide är en FHIR-resurs som kan användas för att beskriva digital tjänster. Resursen beskriver en uppsättning regler för hur ett visst interoperabilitets- eller standardproblem löses - vanligtvis genom användning av FHIR-resurser. Denna resurs används för att samla alla delar av en interoperabilitetsspecifikation till en logisk helhet och för att publicera en maskintolkningsbar definition av alla delar.

Det finns inget attribut i resursen ImplementationGuide för att beskriva vilka organisationer som stödjer interoperabilitetsspecifikationen. Ett tillvägagångssätt för att möjliggöra kopplingen mellan organisation och digital tjänst är att skapa en extension för Organization kopplat till ImplementationGuide.

Realiseringen av en interoperabilitetsspecifikation kan göras på olika nivåer utefter behov. Exempelvis en interoperabilitetsspecifikation som beskriver hur den digitala tjänsten för Tidbokning löses genom användning av FHIR-resurser. Om det framkommer att konsumenter sällan stödjer alla delar av en interoperabilitetsspecifikation kan det vara värt att istället skapa flera interoperabilitetsspecifikationer för de olika delarna. Exempelvis separata interoperabilitetsspecifikationer för att Boka tid, Avboka tid, Omboka tid, Hitta lediga tider osv.

CapabilityStatement

Resursen CapabilityStatement dokumenterar en uppsättning förmågor hos en FHIR-server. Resursen används för att:

1. Beskriva krav på en FHIR-server
   CapabilityStatement.kind = Requirements

2. Beskriva förmågor som hanteras av en viss mjukvara som tillhandahåller en FHIR-server
   CapabilityStatement.kind = Capability

3. Beskriva vad en specifik FHIR-server hanterar för förmågor
   CapabilityStatement.kind = Instance

För frågeställningen “Vilka digitala tjänster erbjuder en viss organisation” är det den specifika FHIR-servern som behöver kunna svara på vilka digitala tjänster den hanterar. Därav är det typen Instance som är av intresse.

Resursen kan bära information om vilka ImplementationGuides som FHIR-servern stöder. Det gör att man utifrån en samling CapabilityStatements kan söka fram vilka FHIR-servrar som stöder vilka ImplementationGuides. Utifrån en sån samling kan man ta reda på vilka tekniska anslutningspunkter som har stöd för till exempel vissa ImplementationGuides, eller identifiera FHIR-servrar utifrån andra parametrar som kan representeras i resursen. Vilka behov man har att söka fram FHIR-servrar utifrån kan sannolikt vara olika i olika situationer.

Endpoint

Endpoint är en resurs som beskriver tekniska detaljer kring en teknisk anslutningspunkt. Om den kopplas till en organisation kan det representera kopplingen mellan organisationen och dess tekniska anslutningspunkt. Resursen har i sitt standardutförande enbart en koppling till resursen Organization i egenskap av organisationen som managerar den tekniska anslutningspunkten. Koppling tillbaka till organisationen som exponerar digitala tjänster genom den tekniska anslutningspunkten saknas i standarden, så den behöver i såna fall läggas till genom exempelvis en extension. En annan möjlighet är att koppla samman Organization och Endpoint i en Bundle-resurs.

Extension

Möjligheten att utöka FHIR-resurser genom tillägget av en extension finns alltid, och teoretiskt skulle man kunna tänka sig att den mekanismen används på andra resurser för att på konstgjord väg tillhandahålla en möjlighet att representera teknisk anslutningsadress som exempelvis URLer. Huruvida detta är lämpligt eller ej måste avgöras i fall till fall. Värt att notera är dock att den typen av tillägg ofta kan vara svåra för de system som ska implementera lösningen att realisera. Beroende på hur tjänstekatalogen tekniskt ska realiseras i det enskilda fallet kan man också hamna i situationer där informationen om den digitala tjänsten behöver uppdateras väldigt ofta eller med väldigt många olika poster. Det bör man ha i åtanke även om det på pappret ser ut som en bra lösning att koppla på teknisk anslutningsadress på en resurs.

Summering

Resurserna CapabilityStatement samt Endpoint är de resurserna i FHIR som bär information om en teknisk adress genom URLer. Det medför att om man vill representera den tekniska anslutningsadressen med FHIR-resurser måste man använda en av dessa två.

Hur digital tjänst och teknisk anslutningsadress kan representeras i FHIR är tydligt. Det som däremot blir utmaningen är hur man på ett ändamålsenligt sätt kopplar detta mot verksamheten, typiskt representerad genom exempelvis Organization och Practitioner.

Exemplifiering av tjänstekataloger

Nedan följer ett antal exempel med tillhörande resonemang för hur man kan realisera en tjänstekatalog och dess innehåll:

ImplementationGuide-katalog

En katalog som helt eller delvis realiseras i FHIR och som innehåller information om organisation, ImplementationGuide och teknisk anslutningsadress. Både ImplementationGuide och teknisk anslutningsadress laddas upp via en FHIR-servers CapabilityStatement.

Genom att skapa en extension för att koppla Organization till ImplementationGuide kan katalogen helt realiseras i FHIR. Alternativet är att skapa en proprietär katalog som inte realiseras genom FHIR.

En enkel realisering av Tjänstesökning för 1177 Tidbok skulle kunna realiseras genom konfiguration i 1177 Vårdguidens e-tjänster

För att en mottagning (organisation i det här sammanhanget) ska vara tillgänglig för ny-, om- respektive avbokning i 1177 Tidbok måste respektive bokningsaktivitet vara aktiverad i 1177 Vårdguidens e-tjänster. För respektive aktivering av bokningsaktivitet kan ett fält för “sökväg till FHIR-servern” introduceras. Om det finns en “sökväg till FHIR-servern” konfigurerad så innebär det att mottagningen stödjer att FHIR stödjs för att utföra bokningsaktiviteten. I det fallet behövs ingen FHIR-resurs för att bära information om vilken organisation som stöder vissa digitala tjänster.

En organisation per FHIR-server

CapabilityStatement-resursen möjliggör kopplingar till ImplementationGuides. Varje CapabilityStatement representerar en FHIR-server. Att då koppla ImplementationGuides till de organisationer som ligger bakom FHIR-servern blir svårt. Att avkräva en unik CapabilityStatement per organisation skulle lösa ut det problemet, och dessutom möjliggöra att en unik teknisk anropsadress skapas upp per organisation (till exempel https://api.fhirserver.se/organisation/ istället för https://api.fhirserver.se). Kopplingen till den bakomliggande organisationen kan då göras genom antingen CapabilityStatement.publisher eller CapabilityStatement.custodian.

Nackdelen blir att det system som genererar CapabilityStatement-resurser behöver göra det på ett sätt som inte är i enlighet med hur standarden avser att det ska göras. Det saknas också stöd för den typen av generering i de publika kodbiblioteken som HL7 stöttar (HAPI). Det är sannolikt en lösning på problemet som förflyttar komplexiteten från den gemensamma lösningen till att landa hos de anslutande parterna.

Verksamhetsförmågekatalog

Byggblocket syftar till att beskriva en organisations verksamhetsförmåga. Med verksamhetsförmåga inom vård- och omsorg kan åsyftas vårdtjänster eller administrativa tjänster så som ultraljudsundersökningar, provtagning eller vaccinationer men även att man erbjuder tidbokning eller kan ta emot remisser.

Frågeställningar att beakta vid realisering av byggblocket

När FHIR ska utvärderas som lämpligt för realisering av en verksamhetsförmågekatalog, behöver följande frågeställningar utforskas:

• Hur kan verksamhetsförmågor representeras i FHIR?

Beskrivning av FHIR-resurser som kan användas för att realisera byggblocket

Resursen HealthcareService används för att beskriva en enskild vårdtjänst eller kategori av tjänster som erbjuds av en organisation på en plats. Vanliga exempel på HealthcareService-resurser är: 

• Klinisk neuropsykolog

• Fotvårdstjänst

• Avlastningsvård ges på ett äldreboende eller vandrarhem

• 24-timmars kristelefonrådgivning

• Vård i hemmet

Det centrala attributet i HealthcareService-resursen är HealthcareService.type som används för att genom kodade värden representera typen av vårdtjänst. När man profilerar HealthcareService kan man knyta .type till ett ValueSet med en uppsättning kodade vårdtjänster. Inom till exempel Ineras Utbudstjänst har ett arbete gjorts för att strukturera upp vårdtjänster i ett kodverk. Detta kodverk (eller andra om Utbudstjänstens kodverk inte räcker till) blir då bärare av informationen om vilka vårdtjänster som tillhandahålls.

En koppling mellan HealthcareService och Organization finns också vilket gör det möjligt att knyta an en vårdtjänst till en enskild organisation.

En koppling mellan HealthcareService och Endpoint-resursen finns också, vilket i sin tur skulle kunna användas för att koppla samman vårdtjänsten med en teknisk anropspunkt i attributet Endpoint.address. Denna möjlighet innebär inte att HealthcareService ska ha koppling till Endpoint-resursen i verksamhetsförmågekatalogen, men det är möjligt om det anses lämpligt i realiseringen.

Interoperabilitetsspecifikation

Byggblocket Interoperabilitetsspecifikation är en sammanfattande artefakt som beskriver de olika interoperabilitetsaspekterna för ett visst behov av samverkan. Syftet med samverkan ska alltid framgå av specifikationen.

Frågeställningar att beakta vid realisering av byggblocket

Byggblocket Interoperabilitetsspecifikation samlar samtliga krav och beskriver förutsättningar som behöver vara uppfyllda för att samverkan inom en informationsfederation ska kunna uppnås. Det innefattar allt från de legala förutsättningarna för informationsutbytet, beskrivningar av samverkande aktörer och avtal, ingående krav på teknisk lösning och beskrivning av verksamhetslasten som behöver utbytas. Formellt uttryckt täcker Interoperabilitetsspecifikation in de legala, organisatoriska, tekniska och semantiska interoperabilitetsområdena.

Beskrivning av FHIR-resurser som kan användas för att realisera byggblocket

Byggblocken Teknisk Interoperabilitetsspecifikation samt Semantisk Interoperabilitetsspecifikation bedöms vara lämpliga att realisera genom FHIR-standarden. Dessa beskrivs i separata kapitel i vägledningen.
För byggblocken Legal Interoperabilitetsspecifikation och Organisatorisk Interoperabilitetsspecifikation är det inte självklart hur FHIR-standarden kan eller bör tillämpas.

Teknisk interoperabilitetsspecifikation

Byggblocket Teknisk interoperabilitetsspecifikation är en specialisering av byggblocket Interoperabilitetsspecifikation med fokus på den tekniska interoperabiliteten. Specifikationen beskriver tekniska förutsättningarna för informationsutbyte, både avseende applikation och infrastruktur. Tillämpliga tekniska standarder pekas ut och deras tillämpning specificeras.

Frågeställningar att beakta vid realisering av byggblocket

Byggblocket i sig belyser tekniska krav på interoperabilitet på ett sätt som går bredare än vad FHIR i sig hanterar. Vilka delar av den tekniska interoperabiliteten som ska beskrivas var saknar tydliga svar i standarden.

Beskrivning av FHIR-resurser som kan användas för att realisera byggblocket

Givet att man väl beslutat om att FHIR-standarden ska användas finns ett antal resurser som skulle kunna vara tillämpliga för att dokumentera och beskriva tekniska krav för samverkan. I FHIR är det främst ImplementationGuide och CapabilityStatement som kan användas för att realisera byggblocket Teknisk interoperabilitetsspecifikation.

ImplementationGuide

Resursen ImplementationGuide är en uppsättning regler för hur ett visst interoperabilitets- eller standardproblem löses - vanligtvis genom användning av FHIR-resurser.

I den här kontexten så är avgränsningen de tekniska gränssnitten för kommunikation mellan system som behöver utbyta information. Dessa kan beskrivas i en ImplementationGuide, men då den resursen saknar beskrivning av vilket innehåll den ska ha och hur det ska vara strukturerat behöver överenskommelser göras på organisationsnivå kring hur dessa ska tas fram och se ut.

CapabilityStatement

Resursen CapabilityStatement tillhandahåller möjligheten att beskriva tekniska krav på en FHIR-server. Detta görs genom att attributet CapabilityStatement.kind sätts till Capability eller Requirements beroende på om det är en förmåga på en viss produkt som beskrivs eller en kravbild på en FHIR-server. Informationen som kan representeras i resursen innefattar bl.a:

• version av FHIR-standarden

• säkerhetsparametrar

  • OAuth

  • SMART-on-FHIR

  • NTLM

  • Basic

  • Kerberos

  • Certificates

• om FHIR-servern exponerar RESTful-endpoints

  • vilka resurser som exponeras

    • vilka profiler på resurserna som FHIR-servern stöder

    • vilka frågeparametrar som FHIR-servern stöder per resurs

  • vilka interaktioner stöds

• om FHIR-servern stöder Messaging-paradigmet

  • vilka protokoll som stöds

  • vilka meddelanden som stöds, och i vilken roll (sender eller receiver)

• om FHIR-servern stöder Document-paradigmet

Semantisk interoperabilitetsspecifikation

Byggblocket Semantisk interoperabilitetsspecifikation är en specialisering av byggblocket Interoperabilitetsspecifikation med fokus på den semantiska interoperabiliteten. Specifikationen beskriver hur en tjänstekonsument och en tjänsteproducent ska tolka innehållet i informationsutbytet i syfte att meningen i det budskap som förmedlas inte ska bli förvanskat. Även semantik (innehåll) och syntax (struktur) beskrivs.

FHIR har resurser som används för att strukturera och bära informationen. Dessa kan i sin tur relateras mot andra semantiska koncept beskrivna utanför standarden genom exempelvis resursen ConceptMap. Inom FHIR:s datastruktur finns möjlighet att koppla urval av kodade värden mot element (termbindning) genom mekanismer inom profileringen.

Beskrivning av FHIR-resurser som kan användas för att representera informationen

Det finns flera resurser i FHIR som i kombination kan användas för att realisera byggblocket Semantisk interoperabilitetsspecifikation. Dessa resurser dokumenterar den information som är relevant för en tjänstekonsument och en tjänsteproducent för att tolka innehållet och användningen av en resurs eller en digital tjänst.

DomainResource

Den semantiska interoperabiliteten beskrivs i FHIR delvis genom den dokumentation som finns om en resurs. Resurser i FHIR beskrivs övergripande med FHIR-resursen DomainResource som är en mänskligt läsbar representation av resursen.

StructureDefinition

Resursen StructureDefinition används för att beskriva innehållet och strukturen i resurser, datatyper och de underliggande infrastrukturtyperna för FHIR samt regler för användning. Resursen StructureDefinition listar attribut (element) som ingår i en resurs. Varje attribut beskrivs i sin tur av FHIR-resursen ElementDefinition.

ElementDefinition

Resursen ElementDefinition definierar ett attribut i en FHIR-resurs eller en extension. Definitionen innehåller information som:

• namn

• kardinalitet

• datatyp

• beskrivning av användning

• krav för användning

  • Qbegränsningar för användande

• terminologibindning

ImplementationGuide

I kombination med beskrivningen av resursen kan även FHIR-profilen ImplementationGuide användas för att övergripande beskriva den semantiska interoperabiliteten på en nivå som är relevant för implementationsguidens ändamål.