Från semantik till teknik

Idag försvåras delning av hälsodata genom att information kan ligga i flera olika system som saknar integrationer mellan varandra. Detta kan ske mellan vårdgivare, men också inom ett och samma 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 informationsmiljöer. På detta sätt kan NIMar 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.

NIMar styr inte hur den underliggande databasstrukturen ser ut eller ska fungera. De beskriver hur informationen (innehållet) kan dokumenteras på ett enhetligt sätt. När it-stöden utvecklas eller byts ut måste informationen i it-systemen vara beständig över olika tekniska lösningar, och därför ger det störst nytta att Socialstyrelsen fortsätter att fokusera på informationen i patientjournaler och personakter, inte tekniska lösningar. Utgångspunkten bör vara att NI ska fungerar som en lägstanivå, utifrån vilken verksamheter (som beställare) och it-systemleverantörer sedermera kan bygga utökad och önskad funktionalitet till exempel i form av tekniska profiler som FHIR.

Användning av NIM för FHIR

För att underlätta interoperablitet bör terminologibindningar vara enkelt åtkomliga och värdelistor tydligt kopplade till attribut.

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.

Arbetet som ligger bakom denna rapport syftar bland annat till att testa möjligheten att använda FHIR-profiler som format för NIMar och konstruera ‘beta’-profiler i FHIR för ett antal NIMar. Denna rapport beskriver de upptäckter och erfarenheter som gjorts längs vägen.

Sammanfattningsvis kan vi konstatera att NIMar 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.

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.

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 korsreferenser. 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.

Användning av NIM för 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).

Användning av NIM för OpenEHR

Arbetet syftar bland annat 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.

Frågor och svar

Varför bör vi inte endast utgå från tekniska standarder?

Semantik är avgörande för att säkerställa att data som utbyts via FHIR är konsekvent och korrekt förstådd av alla inblandade parter. Det underlättar standardisering, förbättrar informationshantering, stödjer automatisering, höjer kvaliteten och säkerheten i vården, och säkerställer kompatibilitet med befintliga system. Därför är det inte tillräckligt att använda FHIR utan att också beakta semantiken.

Innan mer tekniska standarder tas i bruk kan det dock krävas anpassningar, och det är här NI/NIM kommer in som vägledning för gemensamma beslut. Användningen av NI/NIM säkerställer att de anpassningar som görs är i linje med juridiska och nationellt överenskomna rekommendationer, vilket underlättar ett samordnat och juridiskt korrekt informationsutbyte. Utan denna NIMar kan verksamheter stå ensamma i att säkerställa juridisk följsamhet och korrekt hantering av informationen.

Hur kan vi utgå från en NIM vid en FHIR-implementation?

NIM “Annan person” som exempel så skulle en FHIR-implementation kunna se ut på ungefär följande sätt:

ValueSet: NIMRelationType 
Title: "Typ av relation till vård- och omsorgstagare" 
* include http://snomed.info/sct#59991000052106 "Anhörig" 
* include http://snomed.info/sct#59981000052109 "Närstående" 
* include http://snomed.info/sct#60121000052105 "Förmyndare" 
* include http://snomed.info/sct#60091000052109 "Målsägande" 
* include http://snomed.info/sct#60081000052107 "God man" 
* include http://snomed.info/sct#60111000052102 "Förvaltare" 
* include http://snomed.info/sct#60101000052104 "Vårdnadshavare" 
 
Profile: NIMAnnanPerson 
Parent: RelatedPerson 
Title: "AnnanPerson" 
Description: "Används för att beskriva person som på något sätt kan vara relaterad till patienten men som inte är hälso- och sjukvårdspersonal" 
 
* name.family MS 
* name.given MS 
* patient MS 
* relationship MS 
* relationship from NIMRelationType (required) 
 
Mapping: NIMAnnanPersonMapping 
Source: NIMAnnanPerson 
Target: "https://informationsstruktur.socialstyrelsen.se/NIM-AnnanPerson" 
* name.given -> "Förnamn" 
* name.family -> "Efternamn" "Notera att enligt NIM:en kan det finnas flera  familjenamn, medans FHIR endast tillåter ett. Detta är ett problem som behöver lösas, och som HL7 Sverige har ett förslag för i sina basprofiler." 
* relationship -> "Relation"

Här har vi avgränsat vilka fält i RelatedPerson som är av intresse, begränsat vilka begrepp som kan användas för att beskriva typen av relation samt skapat en enkel referens till NIM:en i form av mapping som bakas in i FHIR-profilen när denna skapas.

Senast uppdaterad:
Publicerad: