Kommentarer till promemorian ”Vägval för en nationell digital infrastruktur för hälsodata baserad på standarder”
Introduktion
openEHR Sverige har genomfört ett öppet möte för intresserade för att samla in kommentarer till promemorian ”Vägval för en nationell digital infrastruktur för hälsodata baserad på standarder – En diskussionspromemoria från Utredningen om infrastruktur för hälsodata som nationellt intresse (S 2022:10)”. Kommentarerna nedan är en sammanställning av det som framkom under mötet.
Generellt
OpenEHR Sverige anser att det är ett lovvärt initiativ att komma överens om en nationell digital infrastruktur för hälsodata baserad på standarder.
Omfattning av normering av information
Vi tolkar promemorian som att den föreslår att den huvudsakliga interoperabiliteten i Sverige ska bygga på HL7 FHIR. Det ska göras genom att det tas fram nationella HL7 FHIR-profiler som används för att överföra information mellan de olika informationssystemen.
Om de nyttor som promemorian beskriver ska uppnås så måste dessa profiler vara förhållandevis detaljerade och normerande över den information som ska utbytas med hjälp av profilerna. Vi ser då att dessa profiler kommer att bli svåra och kostsamma att implementera eftersom de, tvärt emot vad promemorian argumenterar för, kommer att påverka de interna informationsmodellerna i informationssystemen. Långt ifrån all information kommer nämligen att vara möjlig att mappa mellan de olika interna informationsmodellerna i informationssystemen och HL7 FHIR-profiler.
Det blir då en risk att det i praktiken bara blir den begränsade informationen där informationsmodellerna i HL7 FHIR-profilerna och informationssystemen matchar varandra som implementeras och kommer att vara möjlig att överföra mellan olika informationssystem. Den resterande informationen kommer då inte att gå att överföra mellan informationssystemen. I sådana fall skulle inte de nyttor som beskrivs i promemorian uppnås.
Implementation av HL7 FHIR-profiler i informationssystem
Vi uppfattar att valet av HL7 FHIR som interoperabilitetsstandard i promemorian beror på att de informatiska aspekterna av informationsöverföring inte har utretts. Vår erfarenhet är att HL7 FHIR främst är ett ramverk och att det är de profiler som skapas utifrån HL7 FHIR:s resurser under det informatiska arbetet "profilering" som skapar referensmodellen för informationsöverföringen. Problemet är bara att det för samma användningsfall är mycket lätt att under profileringen skapa profiler som är ganska olika. Det här gäller särskilt om man har olika informationssystem i åtanke under profileringen, vilket är vanligt. Den referensmodell som skapas med HL7 FHIR blir därför inte så stabil och mer beroende av respektive profilering än av respektive användningsfall. Det är huvudsakligen på så sätt som HL7 FHIR-profiler blir svåra och kostsamma att implementera i informationssystem.
Vi ser inte heller att HL7 FHIR-profiler som är detaljerade och normerande skulle vara enklare att införa än dagens tjänstekontrakt. För tjänstekontrakten uppfattar vi att det är ett större problem att deras informationsmodell inte alltid överensstämmer med informationsmodellerna i de informationssystem vi använder idag och att det därför ofta behöver göras mindre eleganta informatiska lösningar, för att kunna kommunicera via tjänstekontrakt. Det här problemet kommer att vara det samma för HL7 FHIR-profiler.
Implementation av normerande informationsdesign
Utifrån de ovan beskrivna svårigheterna ser vi därför att det inte är lika enkelt att implementera HL7 FHIR i ett informationssystem som det beskrivs i promemorian. Vi skulle även vilja påstå att det inte heller är lika svårt att implementera openEHR som promemorian påstår. Behöver man ändå specificera informationsdesignen för informationsöverföring på ett detaljerat och normerat sätt så är det snarare ett stöd att specificera inmatnings- och lagringsformatet med openEHR än överföringsformatet med HL7 FHIR.
Svårt för kliniker att ge återkoppling på HL7 FHIR-profiler
HL7 FHIR är inte tänkt för journaldokumentering, utan för informationsöverföring och API-specifikation, och är därför svårt för kliniskt verksamma personer att förstå men någorlunda enkelt att förstå för API-programmerare. Däremot är openEHR tänkt för journaldokumentering och därför någorlunda lätt för kliniskt verksamma personer att förstå, men samtidigt även någorlunda lätt för API-programmerare att förstå.
Eftersom informationsmodeller uttryckta i openEHR är möjliga att förstå för kliniskt verksamma personer är det lätt att få vägledning av dem om hur informationsmodellerna passar den kliniska verksamheten. Däremot är informationsmodeller uttryckta i HL7 FHIR svåra att förstå för kliniskt verksamma personer och det blir då svårt att få vägledning av dem om hur informationsmodellerna passar den kliniska verksamheten. Det är därför större risk att informationsmodeller uttryckta i HL7 FHIR inte fångar hälso- och sjukvårdens behov på ett korrekt sätt. Det gäller särskilt inom områden där det är en människa (t.ex. via inmatning i journalmallar) och inte en maskin (t.ex. labbutrustning) som framställer informationen. På så sätt blir det lätt att missa slutanvändarnas perspektiv. Vi tycker att den här aspekten tappas bort i promemorian.
Vårdgivarna vill samarbeta och openEHR hjälper även i dagens källsystem
Vi uppfattar inte heller att vårdgivarna är negativa till att samarbeta kring gemensamma inmatningsformat, vilket promemorian tycks anse är fallet. De vill snarare samarbeta, bara de har en bra möjlighet att göra det. Goda exempel är både openEHR-samarbetet och den nationella kunskapsstyrningen. Därför bör inte normering av inmatningsformat ses som något stort intrång hos vårdgivarna.
Det tar idag mycket tid att skapa bra, kliniskt förankrade, inmatningsformat (tillämpade detaljerade informationsmodeller som journalsystemsmallar m.m.) i de svenska vårdgivarnas journalsystem. De som jobbar med detta vill både kunna samarbeta om framtagandet och kunna återanvända mallar/modeller som andra har gjort. Svenska patienter är inte särskilt unika, så man vill (för att spara tid och öka jämförbarhet) även kunna återanvända genomarbetade internationella modeller som openEHR:s granskade arketyper.
Det har i svenska system ofta saknats möjlighet till konkret delning (import/export) av konfigurationsunderlag av inmatningsformat/mallar, men detta skulle kunna införas på ett för vårdpersonal och journalsystemsadministratörer begripligt sätt med hjälp av openEHR.
Man behöver inte totalrenovera lagringen i källsystemen för att kunna använda openEHR-templates som konfigurationsunderlag och göra export av data i openEHR-format möjlig. Svenska exempel på där inget av källsystemen var openEHR-baserat från början:
Mallar i journalsystemet TakeCare, testades i Standin 3, se http://dx.doi.org/10.3233/SHTI190645 (Manuell mallkonfiguration baserad på openEHR-template-sökvägar, dataexport från TakeCare som openEHR “FLAT” JSON). Samma artikel visar hur sökordsmallar i Cerner Millenium, Cambio COSMIC och Melior kan konfigureras och användas på liknande sätt.
Inmatningsformulär i Sectra IDS7, se https://cancercentrum.se/globalassets/vara-uppdrag/kunskapsstyrning/kvalitetsregister/slutrapport_openehr.v1.3.pdf. Sectras formulärverktyg läste in openEHR Webtemplate och exporterade openEHR flat JSON till en openEHR CDR hos Region Östergötland. Regionen skickade med openEHR:s “kanoniska” format vidare till en CDR hos RCC där informationen kan återanvändas till flera olika kvalitetsregister samt applikationer.
Patientformulär i Region Stockholms invånar-app “Alltid Öppet” kan nu (sedan Q4 2023) baseras på openEHR Webtemplate som läses in i formulärredigeringsverktyget. Patientdata exporteras sedan via “FLAT” JSON till Regionens/Karolinskas CDR och används i bl.a. översiktsvyer.
Införandet av Snomed CT
Det borde även tas upp i promemorian att openEHR med hjälp av arketyper och templates kan underlätta införandet av Snomed CT, eftersom arketyperna och templatesen kan hjälpa till att peka ut lämpliga Snomed CT-begrepp att använda i inmatningssituationerna.
Avsnitt 2.3.2
Värt att påpeka är att både openEHR och Snomed CT har inbyggt stöd för olika språk och det är därför en fördel att använda någon av dessa standarder för standardisering av det svenska språket i informationsspecifikationerna.
Avsnitt 2.4
Vi uppfattar inte att ”FHIR nu tydligt har etablerats som den främsta standarden för interoperabilitet”. Globalt är det snarare fortfarande HL7 version 2, som har mycket lite gemensamt med HL7 FHIR, som används för informationsöverföring och i Sverige snarare tjänstekontrakten som används för informationsöverföring. Generellt handlar interoperabilitet inte bara om informationsöverföring, även om promemorian främst tar upp den aspekten. Utifrån ett generellt interoperabilitetsperspektiv är det snarare olika standarder som är relevanta utifrån olika aspekter av interoperabilitet. HL7 FHIR är nästan bara relevant för informationsöverföring.
Avsnitt 2.4.1
”Template” i stället för ”mall”
Vi rekommenderar nu för tiden användning av termen ”template” även på svenska och inte termen ”openEHR-mall” eller ”mall”. Termen ”mall” har nämligen visat sig lätt leda till missförstånd, eftersom det är en term med många möjliga betydelser.
openEHR-baserade CDR i regionerna
Vi håller med om omvärldsanalysen att ”En majoritet av, om inte alla, regionerna i Sverige planerar att på sikt att ha Clinical Data Repository (CDR) i openEHR-format i sin journalsystemsmiljö.” Vi tycker därför att det vore rimligt att openEHR ges en mer framträdande roll i analysen. Detta gäller även angående att använda openEHR som överföringsformat för lämpliga användningsfall.
Det pågår exempelvis ett projekt med lagring och överföring av data om cytostatikabehandlingar från Region Stockholm. Behandlingsinformation extraheras från Cytodos-systemets proprietära lagring (via “mappning”) och sparas för återanvändning (tänk livslång journal) i openEHR-CDR:en i regionens vårddataplattform. Därefter överförs kopior i openEHR:s kanoniska format till en CDR hos RCC/INCA där samma rika data kan användas till applikationer som Individuell Patientöversikt (IPÖ) samt delar kopieras till flera olika kvalitetsregister hos RCC. Detta är ett exempel där både vårdgivare och kvalitetsregisterorganisationer vill lagra data i ett leverantörsoberoende openEHR-format och där ett användande av HL7 FHIR för överföring bara skulle ha medfört ytterligare mappningar.
Nya arketyper och templates
Att nya projekt skapar nya arketyper för nya kliniska områden och nya templates för nya inmatningsfall är helt i linje med openEHR:s design. Det motsvaras ungefär av att man i HL7 FHIR skapar nya profiler. De arketyper som skapas och genomgår den internationella reviewprocessen är dock förhållandevis stabila och det är först om olika arketyper skapas för samma typ av information som det uppstår problem.
Det är via templates som det definieras vilken information som ska dokumenteras i en viss situation. Därför behöver inte alla dokumentera lika även när openEHR-specifikationerna följs. openEHR är både en implementationsnära och en dokumentationsnära standard.
Designen bakom arketyper och templates bygger även på en maximal informationsmodell som sedan krymper på ett förutsägbart sätt vid användning och därför blir den information som skapas utifrån informationsmodellen lätt att arbeta med. Det här kan jämföras med många andra informationsdesigner som bygger på en minimal informationsmodell som sedan växer på oförutsägbara sätt och därför blir den information som skapas utifrån informationsmodellen förhållandevis svår att arbeta med.
Byte av openEHR-baserade CDR
Det har gjorts storskaliga byten mellan olika openEHR Clinical Data Repositories, och det finns flera exempel på där applikationer från olika aktörer använder samma CDR så meningen ”Om, och i så fall i vilken mån, denna förhoppning faktiskt uppfylls återstår att se då ingen större aktör ännu har gjort ett fullständigt byte av applikationsleverantör inom en openEHR-baserad journalsysteminfrastruktur.” är inte helt korrekt.
Vi förstår inte heller vilken “förhoppning” ni menar att någon påstått ska kunna uppfyllas och har svårt att spåra utsagan, eftersom den är ett referenslöst påstående. För att flera applikationer ska kunna använda exakt samma API och data (t.ex. för “byte av applikationsleverantör” eller gemensam dataanvändning) så krävs det ju att man är överens om detaljerna oavsett om man använder openEHR, HL7 FHIR eller någon annan standard. Detta uppstår vanligen när man tagit fram openEHR-templates eller HL7 FHIR-profiler i samarbete mellan aktörerna, vanligen i en organisation, region eller ett land. (Dessutom behöver terminologianvändningen i vara överenskommen.)
All data i openEHR-format?
Promemorian argumenterar för att ”all kliniska data är i openEHR-format” för att sedan konstatera att det är svåruppnåeligt. Promemorian argumenterar dock inte för att all kliniska data ska vara överförbart i HL7 FHIR-format, vilket är minst lika svåruppnåeligt. Det är inte heller alla typer av journalinformation som vinner på att hanteras i openEHR-format, utan det är främst de klassiska journalanteckningarna som vinner på openEHR-format. Bokningar och liknande information har inte lika stor relevans att hanteras i openEHR-format. Uttalandet om all kliniska data i openEHR-format blir därför konstigt.
HL7 FHIR-överföring för openEHR-baserade informationssystem
Att det finns leverantörer som planerar att implementera informationsöverföring via HL7 FHIR från openEHR-baserade informationssystem beror inte på HL7 FHIR:s överlägsenhet till informationsöverföring. Det handlar snarare om att skapa en möjlighet att vara kompatibel med proprietära informationssystem som inte använder openEHR. När två openEHR-baserade system kommunicerar med varandra så blir det bara onödigt merarbete att blanda in HL7 FHIR.
openEHR standardiserar inmatningsformat
Det är främst inmatnings- eller informationsfångstformatet som standardiseras med hjälp av openEHR och inte nödvändigtvis lagringsformatet. Lagringsformatet kan lösas på valfritt sätt och det används en mängd olika tekniker. openEHR-arketyper och templates kan även användas som konfigurationsunderlag (och överföringsformat) för informationssystem som inte implementerar openEHR internt. (Se exempel i stycket “Vårdgivarna vill samarbeta och openEHR hjälper även i dagens källsystem" ovan.)
Låta HL7 FHIR-profilering specificera openEHR-modellering är en dålig idé
Att begränsa så att innehållet i openEHR-arketyper och templates måste uppfylla nationella HL7 FHIR-profiler skulle bli en stor begränsning ifall profilerna är detaljerade och normerande och skapas innan man tittat på motsvarande openEHR-modellering. Det finns då nämligen en stor risk att de internationella arketyperna inte kan användas, vilket skulle avsevärt fördyra ett införande av openEHR i Sverige. Dessutom skulle internationell jämförbarhet och återanvändningsmöjlighet för information och applikationer minska. Eftersom det är openEHR som specificerar informationsinmatningen, som kommer först i informationskedjan, så är det rimligast att börja med openEHR-arketyper och -templates och sedan specificera HL7 FHIR-profiler utifrån dem. (Det gäller särskilt för dokumentationsnära användningsfall.)
Vi håller därför inte med om promemorians uttalande ”Däremot konstaterar utredningen att arbetet med nationell och internationell standardisering genom openEHR är lovvärt, och ser inte att bransch- och/eller tvär-regionala samarbeten på något sätt omkullkastas av krav på interoperabilitet med hjälp av FHIR.”.
Informationsinmatningssituationerna konfigureras med templates
Eftersom de olika inmatningssituationerna kan konfigureras med templates i openEHR så förstår vi inte hur vårdgivarnas autonomi skulle begränsas av ett införande av openEHR om det samma inte är fallet med ett införande av HL7 FHIR.
Samarbete kring informationsstandardisering
Som vi har skrivit om tidigare pågår det redan mycket bra samarbete mellan olika aktörer i Sverige om att standardisera informationshanteringen inom hälso- och sjukvården. En större standardisering, med hjälp av till exempel openEHR, ska därför inte vara ett problem bara alla relevanta aktörer är med och tar fram specifikationerna.
Vi uppfattar även en strävan inom vissa vårdgivare att kunna dokumentera mer internationellt jämförbart för att lättare kunna göra studier och ta fram bra statistik. I de fallen erbjuder openEHR:s internationella arketyper ett betydligt bättre stöd än HL7 FHIR:s internationella resurser.
Livslång patientjournal
Det stämmer att det inte är lätt att skapa en livslång patientjournal med hjälp av openEHR. Men det kan vara värt att nämna att det skulle vara betydligt svårare att göra det med hjälp av HL7 FHIR, vilket inte framgår av promemorian. För varje bit som faktiskt standardiseras med hjälp av openEHR bygger man däremot steg för steg en långsiktigt lagringsbar leverantörsoberoende “livslång journal”.
Avsnitt 2.4.2
Det finns även samarbeten mellan openEHR och OMOP och verktyg för att översätta openEHR till OMOP. Se t.ex. https://doi.org/10.1016/j.jbi.2023.104437 och https://github.com/SevKohler/Eos.
Avsnitt 2.4.3
Det finns även samarbeten och synergier mellan openEHR och DICOM. Det tyska HiGHmed projektet använder t.ex. kombinationen openEHR och DICOM och lagrar även DICOM-metadata i openEHR. OpenEHR-arketypen “Imaging examination result” (https://ckm.openehr.org/ckm/archetypes/1013.1.1494) är utvecklad med både DICOM och FHIR som underlag. Precis som i det ovan nämnda patologiprojektet med RCC och Sectra så kan openEHR bidra till att system som använder DICOM SR (Structured Reporting) kan strukturera rapporten mer återanvändbart för efterföljande delar av vårdprocessen med hjälp av openEHR än dagens ofta ad hoc-baserade strukturer i SR.
Avsnitt 3.4
Värt att påpeka är att HL7 FHIR Terminology Service visserligen är en del av HL7 FHIR-specifikationerna, men har förhållandevis lite gemensamt med de övriga delarna av HL7 FHIR-specifikationerna och används även bland annat av openEHR-baserade system för terminologitjänster. Det här är ett bra exempel på kombinationen av openEHR och FHIR för olika ändamål i ett ekosystem varken openEHR, FHIR eller Snomed CT täcker ensamma alla behov för informationsutbyte i ett land.