Nationella informatonsmängder i olika format
Bakgrund
Idag hanteras information om en individ ofta i olika informationssystem vilket kan försvåra för organisationer att dela data med varandra, även inom enskilda organisationer, exempelvis sjukhus. Nationella informationsmängder kan fungera som en gemensam referens för hur information kan struktureras för att kunna tillgängliggöras eller ge tillgång/åtkomst till den dokumenterade informationen inom och mellan olika informationsmil-jöer. På detta sätt kan NIM:ar användas för att överbrygga barriärer som it-stöden ofta stöter på och bidra till att information tolkas lika när den delas mellan verksamheter och system. NIM:ar styr inte hur den underliggande databasstrukturen ser ut eller ska fungera. De beskriver hur informationen (innehållet) kan dokumenteras på ett enhetligt sätt. Vår utgångspunkt har varit att använda NIM:ar som grund för att möjliggöra att flertalet kommunikationsformat kan användas för att utbyta information med bibehållen innebörd, oberoende av format. Detta arbete har gjorts för att verifiera detta antagande. Nedan finns beskrivningar utifrån två olika kommunikationsstandarder.
Figur 1 Gemensamma beskrivningar som utgångspunkt
FHIR
Allmänt om användning av FHIR för NIM
Arbetet som ligger bakom denna rapport syftar bl.a.nd annat till att testa möjligheten att använda FHIR-profiler som format för NIM:ar och konstruera ‘beta’-profiler i FHIR för ett antal NIM:ar. Denna rapport beskriver de upptäckter och erfarenheter som gjorts längs vägen.
Sammanfattningsvis kan vi konstatera att NIM:ar lämpar sig väl för att ligga till grund för utveckling av FHIR-profiler. Användning av FHIR-profilering som en del i NI/NIM-processen kan också ge flera fördelar utan en stor arbetsinsats.
Kort om FHIR
FHIR som standard är en relativt tillåtande modell som ger möjlighet att uttrycka många delar av verksamheters behov av informationsdelning (speglad i dokumentation i verksamhetssystem, NIM). För specifika syften skapas FHIR-profiler, som då specialiserar (primärt via constraints och extensions) standardmodellen för det uttryckta syftet.
FHIR är en standard som innefattar såväl en informationsmodell som applikationsspecifikationer och protokoll för dess användning. Den som bygger en tillämpning är fri att använda valfri teknik. En Informationsspecifikation för NIM kan effektivisera i implementationsfasen för att uttryckas med beskrivningar som ingår i FHIR-formatet.
Reflektioner under arbetet
Nedan beskrivs några iakttagelser som har gjorts under arbetet och som tycks gälla generellt för informationsmodellerna. I många fall finns inte självklara “rätt” eller “fel” utan bedömningar behöver göras om vad som är den bästa lösningen.
Terminologibindningar
Eftersom FHIR är en implementationsnära standard, ligger det nära till hands att varje terminologibindning ska vara ‘resolvable’ (möjlig att slå upp i realtid) av ett system i så hög grad som möjligt. FHIR uppmanar således till att inte bara ange ett kodverk med exempelvis en OID, utan att det också ska finnas en faktisk URI som tillämpningen kan använda för att t.ex. validera koder eller hämta hem urval. Värdet av att ha en terminologitjänst med denna förmåga är således något som aktualiseras med användning av FHIR.
Värdelistor och ConceptMaps
Tydliga bindningar till urval för attributvärden är en viktig del av att uppnå semantisk interoperabilitet. Ofta kan sådan bindning göras fritt i FHIR och således anpassas efter NIM. I vissa fall har FHIR en föreslagen tydligare bindning än NIM, för att öka möjligheten till interoperabilitet. Emellanåt har FHIR-modellen fasta bindningar.
Om en absolut överensstämmelse med NIM-värdelistorna krävs för ett visst FHIR-attribut, så behöver det skapas en egen extension för det attributet och att den egna värdelista binds dit. Man kan sedan skapa en mappning (med FHIR:ConceptMap) mellan det nya attributet och originalet i FHIR-modellen, vilket då medger en ‘fallback’ för interoperabilitet inom FHIR-standarden. I den första versionen av NIM-profiler har dock dessa utökningar (extensions) och tillhörande ConceptMaps inte skapats, utan mappning har gjorts mot existerande FHIR-värdelistor.
Mognad hos FHIR-resurser
När man väljer en FHIR-resurs eller en publicerad NIM-profil, så bör en bedömning göras av mognadsgraden hos resursen/profilen som man vill utgå från. En resurs eller profil som till synes skulle passa bra, men har en låg mognad, eller fortfarande bedöms vara otestad som profil, är inte självklart rätt val. För NIM-profilerna användes t.ex. inte FHIR BodyStructure för att representera Kroppsstruktur. Istället har attributet bodySite använts, som visserligen inte är lika uttrycksfullt, men har en högre mognadsgrad vilket medför att det är större sannolikhet att det finns stöd i applikationer som man vill kommunicera med.
Composition eller referenser
För att beskriva ett gemensamt behov kan det i vissa sammanhang vara motiverat att använda FHIR Compositions för att skapa entydiga modeller. I denna första version av NIM-profiler har användandet av Compositions dock undvikits, till förmån för användning av resursmodeller med korsrefe-renser. Detta möjliggör högre grad av löst kopplad men länkad data och undvikande av inlåsning i dokumentbaserade Compositions.
Inkluderande av extern profilinformation
För att beskriva ett gemensamt behov kan det i vissa sammanhang vara motiverat att använda FHIR Compositions för att skapa entydiga modeller. I denna första version av NIM-profiler har användandet av Compositions dock undvikits, till förmån för användning av resursmodeller med korsreferenser. Detta möjliggör högre grad av löst kopplad men länkad data och undvikande av inlåsning i dokumentbaserade Compositions.
Konklusioner
Arbetet visar att NIM:ar fungerar väl som utgångspunkt för att skapa FHIR-profiler enligt FHIR R4. Bakomliggande referensmodeller, NI respektive HL7 RIM korresponderar väl med den internationella adoptionen av FHIR. Många scenarion och informationsmodeller går att åstadkommas med FHIR utan att modellen behöver förändras särskilt mycket.
FHIR utvecklas vidare med nya områden, och med nya versioner av resurser som tagits fram i brett samarbete vilket borgar för att även nya NIM:ar med hög sannolikhet kommer att finna god täckning i FHIR- modellen.
De som använder NIM i utvecklingen av tillämpningar skulle sannolikt ha mycket stor nytta av vidhängande FHIR-profiler. NIM som företeelse skulle med stöttning av FHIR troligen kunna få en ännu större betydelse i det nationella arbetet mot ändamålsenlig informationsstruktur.
Vi har visat hur externa profiler (Nationella Läkemedelslistan användes som exempel) kan refereras i NIM-profilerna. Detta skulle också gälla nationella bas-profiler, om/när dessa tas fram och publiceras. Det gör att NIM-profilernas status kan hållas stabil i ett ekosystem av andra nationella profiler.
OpenEHR
Allmänt om användning av OpenEHR för NIM
Arbetet syftar bl.a. till att testa möjligheten att använda OpenEHR:s arketyper och templates (mallar) som tekniskt format för att representera NIM:arnas informationsinnehåll samt att ta fram ett antal exempel. Denna rapport beskriver de erfarenheter som gjorts längs vägen.
Sammanfattningsvis kan vi utifrån arbetet konstatera att OpenEHR arke-typer och templates kan representera informationsinnehållet i NIM:ar.
Kort om OpenEHR
OpenEHR är en öppen standardspecifikation inom hälsoinformatik som beskriver hantering och lagring, hämtning och utbyte av hälsodata i elektroniska hälsoposter. OpenEHR är uppbyggd av Reference Model (RM), Archetype Model Component (AM) och Archetype object Model (AOM). RM är en modell där grundläggande element och sambanden mellan dessa anges och som används för att definiera arketyper. AOM är en grundmodell för representation av arketyper (objektorienterad notation).
Reflektioner under arbetet
Nedan beskrivs några iakttagelser som har gjorts under arbetet.
Mappning
För att utreda hur NIM:ar kan representeras i OpenEHR:s arketyper har det genomförts ett mappningsarbete mellan ett antal NIM:ar och arketyper. Mappningsarbetet har inneburit att hitta en arketyp som kan uttrycka informationen som en NIM gör. I detta syfte har NIM:ens utformning jämförts med arketypens utformning för att sedan kunna identifiera likheter eller skillnader.
Observationer
En av observationerna som har gjorts under arbetet är att det inte alltid är möjligt att mappa en NIM ett till ett mot en arketyp, men att det snarare krävs att flera arketyper behöver kombineras ihop för att representera en NIM.
Våra observationer visar även följande som vi har stött på under arbetet.
• Arketyper kan innehålla fler attribut än NIM:en
• Arketyper kan innehålla färre attribut än NIM:en
• NIM-attributens datatyp och kardinalitet stämmer inte alltid överens med arketypens
• NIM-attributens terminologibindning stämmer inte alltid överens med arketypens
• Arketypens namn speglar inte 100% NIM:ens innebörd men attributen i arketypen mappar mot NIM:ens attribut.
• Arketypens alla attribut finns inte i ‘’Map mind:en’’ de obligatoriska attributen hamnar under en egen flik som kallas för ‘’Reference model’’.
Konklusioner
Vi kan utifrån arbetet konstatera att OpenEHR arketyper (arketyper eller arketyper i templates) kan representera den information som definieras i NIM:ar.