/
Frågor och svar om införande av openEHR och relaterade erfarenheter

Frågor och svar om införande av openEHR och relaterade erfarenheter

Syfte: Denna sida samlar frågor, svar och erfarenheter kring införande av openEHR. Skriv gärna in fler frågor i slutet av tabellen.

Planen är att avsätta (max) en timme, med start kl 16 under varje varannan-tisdags arbetsmötena (initialt) tre gånger famöver, med start under https://openehr.atlassian.net/wiki/x/DwCPxg

Anslutningsinfo: https://teams.microsoft.com/meet/36505223649573?p=FZf6hcDkNS95nRdwN0 (Mötes-ID: 365 052 236 495 73 Lösen: HC3ya6Ee)
Vi planerar att ha transkribering påslagen och från den sedan skapa en sammanfattning av respektive möte och att fyllla i de frågesvar som togs upp på mötet (därav separat teamsmöte från Region Stockholm).

Bakgrund: Karolinska har fått frågor från flera olika vårdgivare och vill gärna svara samlat.

Det efterfrågades eventuella strategier och dokument från KArolinska eller Region Stockholm. @Patrik Georgii-Hemming har varit högst involverad i att ta fram en informationsstrategi som vi ska försöka leta fram och dela här.
Det finns även en del annat som kan vara intressant t.ex. detta dokument som Karolinska ibland använder (hela eller delar av) i upphandlingssammanhang:

Sedan finns tre varianter av integrationsstrategi som togs fram i det gamla nationella StandIN-projektet och som återges bl.a. på bild 6 i https://drive.google.com/file/d/1UVQ-evYLhmePbc36QgGt-kqnn9YHZVA6/view?usp=sharing och mer detaljerat på engelska i bild 29-37 i https://docs.google.com/presentation/d/16D1UoanTX09mpBO3FokmHB_14xsuSk8h/edit?usp=sharing&ouid=112660550613841635682&rtpof=true&sd=true

#

Fråga

Svar

#

Fråga

Svar

1

Jag skulle vilja höra om ni gjort något i arketyper/templates för att förenkla för PDL, ex. alltid lagra vårdenhets och vårdgivares HSAID på någon specifik plats.

Ja! Se implementationsguiden https://openehr.atlassian.net/wiki/spaces/SWE/pages/1893105737 Som vi tror implementerats av åtminstone t.ex. Cambio och Tieto.

Grundtanken är att det vid dataexport eller systembyte ska gå att få med vårdgivare och vårdenhet på ett standardiserat sätt från alla leverantörer som implementerat detta.

2

Gärna också hur ni gjort med personnummer, om ni använder det som subjectId i openEHR eller om ni enbart sparar det i FHIR.

I Region Stockholms implementation har vi valt att INTE ha personnummer, reservnummer m.m. i CDRen (openEHR-delen) utan istället ha detta i FHIR-resursen “Patient” där vi då även håller en pekare till openEHRs ehr_id (basedad på UUID). Det blir lite bättre pseudonymiserad data i CDRen och tillhörande API-anrop, loggar, datauttag etc. så.

3

Vad anser ni gällande att ha ett starkt beroende till ODR, operational data repository? Hur hårt bunden till leverantören blir man?

[Antar att ODR = Operational Data Repository = vad vissa systemleverantörer kallar sin FHIR-server]

Om man ser till att använda riktiga FHIR-resurser och profiler så bör det gå fint att flytta till annan leverantör.

4

Hur resonerar ni kring informationsmängder som det inte finns arketyper för och som måste placeras i ODR?

 

5

Kopplingar mellan CDR och ODR 1. Vårdkontakter 2. Vårdtillfälle 3. Patient

Exempel från Region Stockholm:
1 & 2: FHIR-servern från Tieto/Better stöder alla resurser som ingår i den release man väljer att köra, vi kör nu med FHIR R4 men har ännu inte några tillämpningar som använder resurser för 1&2.

  1. Resursen Patient (med en profil) används flitigt som sammankopplande länk mellan t.ex. Personnummer (reservnummer etc) och openEHRs ehr_id

6

Hur ser ni på möjligheten till att en öppen plattform kan informationsförsörja

  1. Myndighetsrapporteringar

  2. Kvalitetsregister

  3. EHDS

 

7

Har ni sett några initiativ från TakeCare att röra sig mot OpenEHR?

CGM har gjort något inlägg på Linkedin etc. om att de skulle kunna ta till sig sådana standarder för TakeCare, men vi har inte sett något verkligt steg i den riktningen - om någon annan sett sådana steg länka/kommentera då gärna. …

Däremot jobbar Region Stockholm+Gotland aktivt med att kunna konvertera och lagra TakeCares innehåll i vårddataplattformen med hjälp av openEHR (klinisk data), FHIR (vårdnära asministration) och datalake/lakehouse (ekonomi, loggar m.m.) Se t.ex. presentationer länkade från https://github.com/regionstockholm/poc_tc2openEHR

8

Har Karolinska sett andra alternativ än Better när ni skaffade plattform för CDR?

Karolinska körde en tidig variant av Cambio Open Platform (Cambio's openEHR+FHIR) i två år först och bytte till Tieto/Better. Karolinska har även kört EHRbase i t.ex. kvalitetsregistrer-relaterade tillämpningar. Stockholms nuvarande ramavtal för grundplattform innehåller tre leverantörer varav Medblocks erbjudande är baserat på CDRen från EHRbase.

Det finns brtydligt fler leverantörer än dessa men flera av dem besvarade inte dåvarande upphandling. Andra klarade inte upphandlingskraven då, men har sannolikt förbättrat sina erbjudanden och drifterfarenheter och kanske skulle uppfylla kraven idag.

9

Vi har några kollegor som arbetar med andra perspektiv (mindre tekniska) - såsom Medarbetarpåverkan och patient perspektiv? Skulle ni kunna hjälpa oss med kontakter där?

Viktigt att ha med verksamheten från början - MDK-exempel…

Internationellt - finns engagerade människor med patientperspektiv.

Om man vill exponera patienten mer för patienten så kan man vilja visa på lite anpassade sätt…

10

Är er bild att OpenEHR är "defacto standard" eller har ni sett bra alternativ?

Om man vill ha öppna modeller för kliniska informationen INUTI systemen så finns det inte några tydliga konkurrenter med samma genomslag - konkurrensen är där snarare mot system med proprietära modeller. Modeller för mappning och överföring finns det bredare konkurrens om, t.ex. FHIR är ju ett seriöst alternativ.

11

Upphandlingstips?

Eftersom denna sida är på openEHR Sveriges wiki så är det viktigt att påpeka att openEHR Sverige inte lägger sig i eller har åsikter om upphandlingar.

På wikisidan https://openehr.atlassian.net/wiki/spaces/resources/pages/416514052 finns en (långt ifrån komplett) lista över upphandlingar med en hel del kravdokument som bilagor

Olika svenska Regioners och regionssamarbetens erfarenheter och tankar kan man hitta på t.ex. följande ställen:

12

Vem från inköp drev upphandling i Region Stockholm?

Inför senaste ramavtalet hade inköpsavdeliningen en konsult , Inger Malmgren https://www.linkedin.com/in/inger-malmgren-7b4b48116/, anlitad som var till god hjälp. Vid senare avrop från ramavtalet så har främst Jing Guan jing.guan@regionstockholm.se varit vår kontakt hos inköp.

13

Hur blir det med inlåsningseffeketer?

Sådant går att lindra. Data/journalinnehåll och applikationers anrop till CDRens API går vanligtvis fint att flytta mellan lösningar. I stockholm har t.ex. applikationer flyttats mellan lösningar från Cambio, Tieto/Better och EHRbase. Det man får se upp med är leverantörsberoenden kring sådant som inte är standardiserat, t.ex. sätt att bygga och visa fomulär, applikationer och översikter.

Region Stockholms avtal och införandeprojekt innhåller specifika delar för att lindra inlåsningseffekter. Vissa upphandlingskrav har resulterat i att lösningen från Tieto/Better börjat erbjuda alternativ som bättre följer standard, mer info kommer…

14

Hur stor del av integrationer av vårdinformation mellan regionala system sker med CDR som mål/källa och hur stor del sker direkt mellan system?

Dela strategidokument?

15

Hur stor del av integrationer till/från CDR sker via FHIR-API:er?

 

16

Hur ser ni på möjligheten att knyta närmare band till SKR:s kunskapsstyrning för att vara med och driva utvecklingen av open EHR-strukturer?

@Linda Aulin Lundeqvist @Sanna Åsberg kan berätta mer om openEHR i NAG Patologi - kanske nästa gång?

@Åsa Skagerhult: Det finns en NAG som jobbar med openEHR, piloter runt PAR/väntetider

17

i OpenEHR CKM finns det mappingsqueries för varje arketyp. Hur ser det ekosystemet ut. Tänker text ska mappningar "TakeCare" till OpenEHR 

 

18

Mer om mappningar openEHR - FHIR? Länkar

 

19

Mot bakgrund av presentationen ”Open Platform, Catalonia - Stockholm/Karolinska, current situation and system/cultural transformations”:

  • Hur realiseras gränssnitten mellan ”Digital Health Platform” och omgivande komponenter (Integrationsplattform, API-Gateway/motsvarande förmågor, tjänstekatalog, governance) ?

 

 

Redigering pågår av nedanstående AI-sammanfattnign från mötestranskriptioner

# Frågor och svar om införande av openEHR och relaterade erfarenheter > **Sammanvävd version.** Denna fil kombinerar det befintliga innehållet från [wikisidan](https://openehr.atlassian.net/wiki/spaces/SWE/pages/3520069676) (markerat **Wikisvar**) med kompletteringar från erfarenhetsutbytemötena 2026-02-17, 2026-03-03 och 2026-03-17 (markerat **Möteskomplettering**). Befintligt wiki-innehåll har bevarats i sin helhet. --- ## Fråga 1 – PDL (vårdenhet/vårdgivare HSAID) **Fråga:** Jag skulle vilja höra om ni gjort något i arketyper/templates för att förenkla för PDL, ex. alltid lagra vårdenhets och vårdgivares HSAID på någon specifik plats. **Wikisvar:** Ja! Se implementationsguiden *PDL i openEHR*. Som vi tror implementerats av åtminstone t.ex. Cambio och Tieto. Grundtanken är att det vid dataexport eller systembyte ska gå att få med vårdgivare och vårdenhet på ett standardiserat sätt från alla leverantörer som implementerat detta. **Möteskomplettering (möte 1):** Implementationsguiden har uppdaterats till **version 2** efter att implementatörer (bl.a. Cambio, Tieto) upptäckte justeringsbehov, t.ex. att stödja både organisationsnummer och HSA-ID för vårdgivare. Lösningen bygger på arketypen *Organisation* instansierad två gånger (en för vårdenhet, en för vårdgivare) med hierarkisk koppling (moderorganisation). Metoden bedöms nu som relativt stabil. --- ## Fråga 2 – Personnummer i openEHR vs. FHIR **Fråga:** Gärna också hur ni gjort med personnummer, om ni använder det som subjectId i openEHR eller om ni enbart sparar det i FHIR. **Wikisvar:** I Region Stockholms implementation har vi valt att INTE ha personnummer, reservnummer m.m. i CDR:n (openEHR-delen) utan istället ha detta i FHIR-resursen "Patient" där vi då även håller en pekare till openEHR:s ehr_id (baserad på UUID). Det blir lite bättre pseudonymiserad data i CDR:n och tillhörande API-anrop, loggar, datauttag etc. *Ingen väsentlig möteskomplettering.* --- ## Fråga 3 – Beroende till ODR / leverantörsinlåsning **Fråga:** Vad anser ni gällande att ha ett starkt beroende till ODR, operational data repository? Hur hårt bunden till leverantören blir man? **Wikisvar:** [Antar att ODR = Operational Data Repository = vad vissa systemleverantörer kallar sin FHIR-server] Om man ser till att använda riktiga FHIR-resurser och profiler så bör det gå fint att flytta till annan leverantör. **Möteskomplettering (möte 1):** Man blir *mindre* bunden än med ett vanligt journalsystem, åtminstone vad gäller datan. Det som *inte* är standardiserat (formulärverktyg, översikter m.m.) är den verkliga risken för inlåsning, men det är ett toppskikt – inte hela stacken. Se även fråga 13. --- ## Fråga 4 – Informationsmängder utan arketyper → ODR? **Fråga:** Hur resonerar ni kring informationsmängder som det inte finns arketyper för och som måste placeras i ODR? **Wikisvar:** *(Saknades på wiki.)* **Möteskomplettering (möte 1):** Det som avgör om information hamnar i openEHR-CDR:n eller FHIR-servern är *typen av information*, inte huruvida en arketyp finns. Journalhandling eller patientnära klinisk data → openEHR. Administrativ/demografisk data → FHIR. Finns ingen passande arketyp kan man snabbt bygga en egen (eller en kluster-arketyp som jackas in i en befintlig). Man behöver inte flytta data till FHIR bara för att arketypen saknas. Det rekommenderas att vara proaktiv: kolla internationellt om någon redan arbetar med området (via openEHR CKM, internationella forum, openEHR Sverige) innan man bygger helt själv. openEHR är en do-okrati – den som tar tag i modelleringen driver den framåt. --- ## Fråga 5 – Kopplingar mellan CDR och ODR **Fråga:** Kopplingar mellan CDR och ODR: 1. Vårdkontakter 2. Vårdtillfälle 3. Patient **Wikisvar:** Exempel från Region Stockholm: 1 & 2: FHIR-servern från Tieto/Better stöder alla resurser som ingår i den release man väljer att köra, vi kör nu med FHIR R4 men har ännu inte några tillämpningar som använder resurser för 1 & 2. Resursen Patient (med en profil) används flitigt som sammankopplande länk mellan t.ex. personnummer (reservnummer etc.) och openEHR:s ehr_id. *Ingen väsentlig möteskomplettering.* --- ## Fråga 6 – Öppen plattform → myndighetsrapportering, kvalitetsregister, EHDS **Fråga:** Hur ser ni på möjligheten till att en öppen plattform kan informationsförsörja myndighetsrapporteringar, kvalitetsregister, EHDS? **Wikisvar:** *(Saknades på wiki.)* **Möteskomplettering (möte 1–3):** openEHR-plattformen lämpar sig väl för detta: - Arketyper har rik metadata som beskriver avsedd användning, vilket underlättar exportmappning. - Om regioner använder samma arketyper och liknande templates kan man dela exportskript till kvalitetsregister och myndigheter (**dokumentera en gång, använd flera gånger**). - **Kvalitetsregister:** Region Stockholm har en tydlig strategi att klinisk information ska finnas i den egna plattformen (inte enbart i kvalitetsregistret) för att möjliggöra lokala kliniska beslutsstöd. Det utesluter inte att en kopia skickas till nationella register. Karolinska ansvarar för >50 % av de nationella kvalitetsregistren och har en strategi där plattformen har en kärnroll. - **EHDS:** openEHR-organisationen har blivit inbjuden att bidra på europeisk nivå till EHDS-specifikationerna för bättre klinisk koppling. openEHR förväntas få större påverkan på slutresultatet än vad de tidiga remisserna antydde. - **Australien** använder openEHR-modeller som kärna för klinisk konsensus och bygger sedan FHIR-profiler ovanpå – ett framgångsrikt mönster. Från möte 2: I Symfoni-projektet (EU, prostatacancer) demonstrerades konkret hur data från CytoDos kunde exporteras till kvalitetsregister via CDR:n. Man skickade originaldata i openEHR-format till bl.a. bröstcancerregistret och registret för dyra läkemedel. Från möte 3 (Mikael Nyström): EHDS håller på att "kasta upp mycket i luften" – det kan bli krav på att myndigheter ska driva privata hälsokonto, vilket skiljer sig kraftigt från nuvarande läge. Mycket spännande är på gång framöver. --- ## Fråga 7 – TakeCare → openEHR **Fråga:** Har ni sett några initiativ från TakeCare att röra sig mot openEHR? **Wikisvar:** CGM har gjort något inlägg på LinkedIn etc. om att de skulle kunna ta till sig sådana standarder för TakeCare, men vi har inte sett något verkligt steg i den riktningen – om någon annan sett sådana steg, länka/kommentera då gärna. Däremot jobbar Region Stockholm+Gotland aktivt med att kunna konvertera och lagra TakeCares innehåll i vårddataplattformen med hjälp av openEHR (klinisk data), FHIR (vårdnära administration) och datalake/lakehouse (ekonomi, loggar m.m.). Se t.ex. presentationer länkade från GitHub – regionstockholm/poc_tc2openEHR. **Möteskomplettering (möte 1):** Det är **CGM** (leverantör av TakeCare) som har uttalat planer på en nästa generations plattformsbaserad arkitektur, inte TakeCare i sig. Inget bekräftat att den nya plattformen bygger på openEHR. --- ## Fråga 8 – Alternativ till Better som CDR-plattform **Fråga:** Har Karolinska sett andra alternativ än Better när ni skaffade plattform för CDR? **Wikisvar:** Karolinska körde en tidig variant av Cambio Open Platform (Cambios openEHR+FHIR) i två år först och bytte till Tieto/Better. Karolinska har även kört EHRbase i t.ex. kvalitetsregisterrelaterade tillämpningar. Stockholms nuvarande ramavtal för grundplattform innehåller tre leverantörer varav Medblocks erbjudande är baserat på CDR:n från EHRbase. Det finns betydligt fler leverantörer än dessa men flera av dem besvarade inte dåvarande upphandling. Andra klarade inte upphandlingskraven då, men har sannolikt förbättrat sina erbjudanden ochdriver försäljning i andra regioner/länder. *Ingen väsentlig möteskomplettering.* --- ## Fråga 9 – Medarbetarpåverkan och patientperspektiv **Fråga:** Vi har några kollegor som arbetar med andra perspektiv (mindre tekniska) – såsom medarbetarpåverkan och patientperspektiv. Skulle ni kunna hjälpa oss med kontakter där? **Wikisvar:** Viktigt att ha med verksamheten från början – MDK-exempel… Internationellt finns engagerade människor med patientperspektiv. Om man vill exponera patienten mer för patienten så kan man vilja visa på lite anpassade sätt… **Möteskomplettering (möte 1):** - Internationellt har patienter deltagit i granskningar av arketyper och bidragit med synpunkter på vad som bör finnas i journalanteckningar. - "Patient David" nämns som aktiv röst för patientperspektivet inom openEHR-gemenskapen. - Hälso-Sverige (organisation) lyfts som bra resurs för patientperspektiv. - Region Uppsala arbetar med patientärenden/perspektiv kopplat till openEHR. - Viktig princip: låt verksamheten driva behoven snarare än IT – de mest framgångsrika initiativen har verksamheter som skriker efter stöd. - Avvägningen **strukturerad data vs. fritext** är kritisk i alla sådana initiativ (inte unikt för openEHR men viktigt att ha med sig). --- ## Fråga 10 – De facto standard / alternativ? **Fråga:** Är er bild att openEHR är "de facto standard" eller har ni sett bra alternativ? **Wikisvar:** Om man vill ha öppna modeller för kliniska informationen INUTI systemen så finns det inte några tydliga konkurrenter med samma genomslag – konkurrensen är där snarare mot system med proprietära modeller. Modeller för mappning och överföring finns det bredare konkurrens om, t.ex. FHIR är ju ett seriöst alternativ. **Möteskomplettering (möte 1):** Patrik Georgii-Hemming betonar att openEHR inte är svaret på *alla* behov. T.ex. för delning i europeiska forskningsprojekt kan **IHE** (Integrating the Healthcare Enterprise) vara relevant. Man bör inte "klämma ner allting" i openEHR utan välja rätt standard för rätt syfte. --- ## Fråga 11 – Upphandlingstips **Fråga:** Upphandlingstips? **Wikisvar:** Eftersom denna sida är på openEHR Sveriges wiki så är det viktigt att påpeka att openEHR Sverige inte lägger sig i eller har åsikter om upphandlingar. På wikisidan *Procurement of openEHR-related systems and services* finns en (långt ifrån komplett) lista över upphandlingar med en hel del kravdokument som bilagor. Olika svenska regioners och regionssamarbetens erfarenheter och tankar kan man hitta på t.ex. följande ställen: En RFI som flera regioner gjorde tillsammans – *The Swedish openEHR platforms and tools RFI 2023* – den inkluderar en slutrapport och länkar till videoinspelningar av demonstrationer från flera olika leverantörer. **Möteskomplettering (möte 1):** - Marknaden rör sig snabbt. Exenpel: **Code24** (Holland) började nyligen erbjuda sin plattform externt (i form av en spinoff under namnet Cadasto se https://www.cadasto.com/) efter många års intern användning; - **DIPS** (Norge) har visat upp sig i Svenska RFI-sammanhang, men oklart hur de vill agera utabför Norska marknaden. - Överväg **kortare avtalsperioder** än för traditionella journalsystem – marknaden utvecklas fort (inte minst med AI). - Ramavtal har nackdelen att nya leverantörer inte kan ansluta under perioden. Det finns alternativa upphandlingsformer (t.ex. dynamiska inköpssystem) som kan vara mer flexibla. - Åsa Skagerhult har kontaktat **Kammarkollegiet** om möjligheten till samordnad upphandling; svaret var att om *någon kan förvalta kraven* så kan man troligen utnyttja befintliga ramavtal. --- ## Fråga 12 – Vem från inköp drev upphandling i Region Stockholm? **Fråga:** Vem från inköp drev upphandling i Region Stockholm? **Wikisvar:** Inför senaste ramavtalet hade inköpsavdelningen en konsult, Inger Malmgren, anlitad som var till god hjälp. Vid senare avrop från ramavtalet har främst Jing Guan (jing.guan@regionstockholm.se) varit kontakt hos inköp. *Ingen väsentlig möteskomplettering.* --- ## Fråga 13 – Inlåsningseffekter **Fråga:** Hur blir det med inlåsningseffekter? **Wikisvar:** Sådant går att lindra. Data/journalinnehåll och applikationers anrop till CDR:ns API går vanligtvis fint att flytta mellan lösningar. I Stockholm har t.ex. applikationer flyttats mellan lösningar från Cambio, Tieto/Better och EHRbase. Det man får se upp med är leverantörsberoenden kring sådant som inte är standardiserat, t.ex. sätt att bygga och visa formulär, applikationer och översikter. Region Stockholms avtal och införandeprojekt innehåller specifika delar för att lindra inlåsningseffekter. Vissa upphandlingskrav har resulterat i att lösningen från en leverantör exekverar formulär som definierats i en annan leverantörs verktyg. **Möteskomplettering (möte 1–2):** - Det viktigaste att se upp med är **formulärverktyg** – de är respektive leverantörs USP och inte standardiserade. Cambio, Better m.fl. har sina egna. - Region Stockholm har i sitt införandeprojekt en milstolpe för att **beräkna och testa kostnad för leverantörsbyte** av formulärdelen. Krav ställs på att formulärformat ska vara öppna och inspekterbara. - **FormBlocks** nämns som ett open source-alternativ för formulärgränssnitt, men inga riktigt smidiga open source-formulärbyggare finns ännu. - Jämförelse: alternativet till openEHR (köpa traditionellt journalsystem) innebär inlåsning av *hela stacken* – data, API:er, formulär – inte bara formulärskiktet. - I openEHR-system kan man flytta templates mellan test/acceptans/produktion på ett disciplinerat sätt – vilket inte är möjligt i t.ex. TakeCare eller Cosmic (i deras äldre setup) där mallar ofta måste byggas om manuellt. Denna DevOps-mognad minskar inlåsningen ytterligare. --- ## Fråga 14 – Andel integrationer via CDR vs. direkt system-till-system **Fråga:** Hur stor del av integrationer av vårdinformation mellan regionala system sker med CDR som mål/källa och hur stor del sker direkt mellan system? **Wikisvar:** Dela strategidokument? **Möteskomplettering (möte 1–3):** I dag är de flesta integrationer i Region Stockholm fortfarande traditionella punkt-till-punkt med TakeCare i mitten. Strategin är att nya integrationer ska gå via CDR:n. Där det ändå krävs formatkonvertering försöker man passa på att lagra data i CDR:n på vägen. Region Stockholms IT-strategi och informationsstrategi kan delas som offentliga handlingar vid intresse. Från möte 2: Erik Frumerie (VGR) efterfrågade strategidokumenten igen. Patrik Georgii-Hemming bekräftade att de är offentliga handlingar som bör kunna delas. Åsa Skagerhult erbjöd sig att följa upp vid nästa fysiska möte. Från möte 3: VGR-representant följde upp frågan om integrationsstrategi-dokumentet en tredje gång. Erik Sundvall sökte på Karolinskas intranät under mötet men hittade det inte. Sökning på Region Stockholms webb gav fel typ av "integration" (inte IT-integration). Frågan behöver fortfarande följas upp med Patrik Georgii-Hemming. --- ## Fråga 15 – Andel integrationer via FHIR-API:er **Fråga:** Hur stor del av integrationer till/från CDR sker via FHIR-API:er? **Wikisvar:** *(Saknades på wiki.)* **Möteskomplettering (möte 1–2):** I Region Stockholms implementation beror val av API på datatyp: - **Administrativ/demografisk data** (patient, organisation) → FHIR - **Klinisk journaldata** (patologisvar, radiologisvar etc.) → openEHR Integrationer använder ofta *båda*: t.ex. vid import från Sectras formulärsystem slås patienten upp via FHIR (personnummer → ehr_id) och det kliniska innehållet skrivs till CDR:n i openEHR-format. Man konverterar inte i onödan till FHIR som mellansteg om datakällan inte redan har FHIR-format. Notering: vid versionsbyten (FHIR R4 → R5) kan det bli stora ändringar, varför man för långlivad klinisk data föredrar openEHR-lagring. Från möte 2: Det underströks att man bör tänka efter vad mottagaren faktiskt använder – om mottagaren redan använder FHIR kan det vara smart att skicka FHIR direkt, men som grundprincip ska man inte omvandla data i onödan. --- ## Fråga 16 – SKR kunskapsstyrning **Fråga:** Hur ser ni på möjligheten att knyta närmare band till SKR:s kunskapsstyrning för att vara med och driva utvecklingen av openEHR-strukturer? **Wikisvar:** Linda Aulin Lundeqvist och Sanna Åsberg kan berätta mer om openEHR i NAG Patologi – kanske nästa gång? Åsa Skagerhult: Det finns en NAG som jobbar med openEHR, piloter runt PAR/väntetider. **Möteskomplettering (möte 1):** - Åsa Skagerhult och representanter från **VGR** (bl.a. Peter Hofman-Bang, Katarina från dataanalysenhet) har precis börjat ett arbete kring governance-delar. - **Sanna Åsberg** från Region Östergötland är involverad och har lång erfarenhet. - Leverantörer har uttryckt att openEHR-templates är lättare att översätta till implementationer i sina system jämfört med att utgå från UML-modeller (som kunskapsstyrningen ofta producerat). --- ## Fråga 17 – CKM mappings / FHIR-mappningar i arketyper **Fråga:** I openEHR CKM finns det mappings/queries för varje arketyp. Hur ser det ekosystemet ut? Tänker t.ex. på mappningar "TakeCare" till openEHR. **Wikisvar:** *(Saknades på wiki.)* **Möteskomplettering (möte 1–2):** Det finns påbörjat arbete med SNOMED CT- och FHIR-mappningar i CKM, men det har fastnat i granskningsprocessen. Ett tyskt team (bl.a. **Sebastian Iancu**) och ett spanskt företag har gjort omfångsrika mappningar (SNOMED CT ↔ openEHR) för många centrala arketyper. Dessa har inte officiellt lagts in i CKM ännu, men går att få tag på via andra kanaler. Det finns ett standardiserat **mappningsspråk mellan openEHR och FHIR** (FHIR Bridge m.fl. projekt). Terminologibindningar på fältnivå i arketyper är en separat mekanism som ofta är närmare kopplad till klinisk kontext och behöver göras på template-nivå snarare än i arketypen. Från möte 2 (Mikael Nyström/Erik Sundvall): - Det som ska in i CKM bör vara **internationellt relevant** – mappningar specifika för enskilda journalsystem (t.ex. TakeCare) hör inte hemma där. - CKM:s mappningsfunktion är relativt ny och har utvecklats av CKM:s programvaruteam – de som administrerar CKM har ännu inte fastställt regelverk för kvalitetsgranskning av mappningar. - Det saknas fastlagda riktlinjer ("best practice") för hur mappningar ska göras. - Ett kommande **openEHR+FHIR-even 12–13 maj i Dublin** kommer sannolikt ta upp mappningsfrågor, se https://discourse.openehr.org/t/converge-and-collaborate-dublin-may-12-13-st-patricks-day-announcement/11845 för detaljer. - Indiska **Medblocks** har också gjort verktyg/mappningar som kan vara användbara. --- ## Fråga 18 – Mer om mappningar openEHR ↔ FHIR **Fråga:** Mer om mappningar openEHR – FHIR? Länkar. **Wikisvar:** *(Saknades på wiki.)* **Möteskomplettering (möte 1–2):** Se även fråga 17. Det finns ett formellt **mappningsspråk/specifikation** för dubbelriktad mappning openEHR ↔ FHIR. Projekt som **FHIR Bridge** (bl.a. använt i EHRbase/Airbase-projekt) har implementerat detta. Sebastian Iancu (Tyskland) är en nyckelaktör i detta arbete. Specifikationen gör det möjligt att definiera bidirektionella transformeringar. Från möte 2: Det nämns att det finns kommersiella verktyg (t.ex. från "openEHR"-relaterade bolag) och open source-bidrag (Medblocks). Man kan mappa referensmodellens grundelement plus profil-/template-nivå. HL7/openEHR-konferensen maj 2026 i Dublin förväntas fördjupa dessa frågor. Sökord för den som vill läsa vidare: *"openEHR FHIR mapping specification"*, *"FHIR Bridge"*, *"Sebastian Iancu"*, *"Medblocks"*. --- ## Fråga 19 – Gränssnitt mellan Digital Health Platform och omgivande komponenter **Fråga:** Mot bakgrund av presentationen "Open Platform, Catalonia – Stockholm/Karolinska, current situation and system/cultural transformations": Hur realiseras gränssnitten mellan "Digital Health Platform" och omgivande komponenter (integrationsplattform, API-gateway/motsvarande förmågor, tjänstekatalog, governance)? **Wikisvar:** *(Saknades på wiki.)* **Möteskomplettering (möte 2):** Region Stockholm/Karolinska gav konkreta exempel med skärmdelning: - **Integrationsplattform:** Man använder bl.a. **Apache Kafka** för event-driven integration. Meddelanden läggs på en kö, konverteras i små jobb och skrivs till CDR:n. Kafka slukar stora volymer (inklusive oavsiktliga "DDoS-liknande" loggsituationer). - **Patient Orchestrator:** En open source-komponent framför CDR:n som hanterar uppslagning/skapande av patient. Man skickar in personnummer, den kollar FHIR-servern om patienten finns, skapar vid behov både FHIR Patient-resurs och openEHR EHR (med rollback-stöd), och returnerar ehr_id. - **Alltid Öppet-exemplet:** Patientrapporterade formulär (PROMs) byggs baserade på openEHR-templates i Alltid Öppet-appen. Patienten fyller i → appen sparar i sitt format + skickar en openEHR-komposition till CDR:n → kliniker ser data via bro-applikation som ställer AQL-frågor mot CDR:n → en sammanfattande journalanteckning genereras och skrivs till TakeCare. - **CytoDos-exemplet:** Data flödar via datalager med Kafka, konverteras till openEHR och lagras i CDR:n (EHRbase under en övergångsperiod). Feeder audit i openEHR används för att spåra datans ursprung och möjliggöra uppdateringar. - **Uthopp (context launch):** Från bro-applikationen kan man hoppa ut till labbsystem, till TakeCare-anteckningar m.m. via kontextlänkar. Erik Frumerie (VGR) understryker att det är just dessa *faktiska erfarenheter* bortom PowerPoint-pilar som är mest värdefulla att dela. --- # Nya frågor från mötena (ej på wikisidan) Nedanstående teman togs upp i mötena men täcks inte av befintliga frågor 1–19. --- ## Fråga 20 – Migreringsstrategier från legacy-system (t.ex. TakeCare) **Möteskomplettering (möte 2):** Region Stockholm planerar att konvertera all TakeCare-data till openEHR + FHIR: - **Strukturerad data** (läkemedel m.m.) mappas "den snygga vägen" direkt till passande arketyper/templates. - **Ostrukturerad data** (tusentals mallar/sökord) importeras med hjälp av **integrations-arketyper** som bevarar originalstrukturen (sökord, fritext, enheter etc.) i openEHR:s referensmodell – utan att modellera allt kliniskt korrekt från start. - En **bläddrings-app** byggs som härmar gamla journalsystemets utseende (sökordsnavigering, filter) men läser från CDR:n. Målet: släcka gammalt system först, städa/förbättra modellering successivt efteråt. - **MDR-klassning:** Konverteringen behöver hanteras enligt medicintekniska regler. En entitet (t.ex. Karolinska) kan klassa sin konverteringsprocess; andra kan sedan använda det färdiga resultatet utan att var och en behöver egen MDR-klassning. - Kvalitetsaspekt (Mikael Nyström): Om konverterad data ska användas i direkt patientvård måste den vara **exakt rätt** – annars fortsätter kliniker att titta i det gamla systemet och konverteringsarbetet går till spillo. --- ## Fråga 21 – Tips för att börja med openEHR som ny organisation **Möteskomplettering (möte 2):** - **Enklaste starten:** Bygg ett nytt formulär baserat på openEHR-templates från scratch – t.ex. för ett litet "vildsystem" (Excel-baserat register, nischsystem etc.) som ändå ska avvecklas. Då slipper man konverterings-problematik och lär sig rätt saker direkt. - **Undvik att börja med det svåraste:** Klinisk kemi (kemlab) verkar lockande men data är ofta dåligt strukturerad (samma fält kan innehålla "3,7 mmol" eller "krossat provrör"). Börja hellre med ett tydligt avgränsat formulär. - **Leverera nytta snabbt:** Välj ett case där verksamheten aktivt efterfrågar stöd. Lungcancer-formulär i Stockholm tog kort tid och verksamheten blev glad – kemlab drog ut utan synligt resultat. - **Det behöver inte vara allt-eller-inget:** Man kan göra informatik-nära tester utan att gapa över hela kedjan (integration, verksamhetsinvolvering, etc.) samtidigt. - **Kostnaden är hanterbar:** CDR-plattformar kostar ofta runt en euro/patient/år i de större licensmodellerna. Små vildsystem med få patienter blir därför billiga att migrera. - **Migration av ett litet system** fungerar som "generalrepetition" inför framtida migration av stora system. --- ## Fråga 22 – Navigera CKM (inkubatorer vs. officiellt innehåll) **Möteskomplettering (möte 2, Mikael Nyström):** - CKM innehåller dels **officiellt granskat innehåll** (publicerade arketyper, grön plupp, status "Published") och dels **inkubatorer** – projektspecifika ytor där ett par informatiker kan labba och testa. - Inkubatorer presenteras visuellt på samma sätt som officiellt innehåll och har historiskt indexerats av Google som likvärdiga → **nybörjare riskerar att förväxla dem**. - Gå via de officiella kanalerna i CKM och kontrollera status/plupp-färg. - Översättningar (t.ex. till svenska) kan finnas men ha varierande granskningsstatus. Strukturen ändras inte av översättningen. - CKM är skyddat mot oavsiktlig förstörelse: man kan skapa egna brancher men inte ändra officiellt innehåll. --- ## Fråga 23 – Symfoni-projektet (konkret multi-system-integration) **Möteskomplettering (möte 2):** Symfoni var ett EU-finansierat projekt kring prostatacancer med final review mars 2026. Demonstrerade hur man kopplar ihop: - Patientrapporterade data (Kiwa) - Radiologiformulär (Sectra) - Data från TakeCare - Patientgrupp-app (Region Stockholm) - Beslutsstöd (Cambio) - MDK-dashboard (multidisciplinär konferens) Nyckelprincip: **modellera med openEHR från början** och skjut ut templates till respektive källsystem. Sectra har byggt stöd för att importera openEHR-templates och generera formulär med inbyggda sökvägar → data kan spottas ur sig i openEHR-format direkt (och lagras i legacy-format parallellt). Samma approach användes i den Stockholmsägda patientgrupp-appen. --- ## Fråga 24 – Kvalitetsmärkning av data i CDR:n **Möteskomplettering (möte 2–3):** När data tar olika vägar in i CDR:n (direkt inmatning, import från legacy, konvertering via datalager) varierar kvaliteten. Region Stockholm diskuterar: - Använda openEHR:s **feeder audit** för att dokumentera datans ursprung och transformationskedja (källsystem, version av konverteringsverktyg, etc.). - Eventuellt använda **tags** (inbyggd funktion i openEHR) för kvalitetsklassning. - Kliniska översikter kan markera data med lägre tillförlitlighet visuellt (t.ex. färgkodning). - Diskussion pågår om huruvida det bör vara en skala (0–1), kategorier, eller enbart metadata om ursprung. Från möte 3: Kvalitetsmärkning diskuterades även i kontexten patientgenererad data. Region Stockholm har sagt att man vill kunna spara patientgenererad data i CDR:n men vill markera den på olika sätt – t.ex. att den inte är underskriven av vårdpersonal. Man undersöker hur man sätter "varningsflaggor" i översikter för data med lägre kvalitetssäkring. --- ## Fråga 25 – Template-delning och arbetsdelning mellan regioner **Möteskomplettering (möte 1–2):** - Poängen med openEHR:s standardiserade referensmodell är att templates blir delbara. En region kan fokusera på ett område och andra kan återanvända deras arbete. - **Exempel:** Region Västra Götaland (via ÅSA-projektet) modellerar ekokardiografi → Stockholm planerar använda det. Stockholm har gjort bröstcancer → andra kan ta del. - Om man använder samma arketyper och liknande templates kan man dela **exportskript**, **AQL-frågor** och **formulärkonfiguration**. - Arbetsdelningen kan till och med göra att man inte behöver klassiska kvalitetsregister: om flera regioner lagrar data på samma sätt kan man ställa sökfrågor (AQL) federerat istället. - Cambios nya OpenDi-satsning bygger openEHR under huven av Cosmic. Kundgruppen Cosmic (KGC) bör kunna använda detta för att modellera gemensamt. --- ## Fråga 26 – Cambio Cosmic och openEHR (OpenDi) **Möteskomplettering (möte 2, Mikael Nyström/Erik Sundvall):** - Cambio har en satsning (**OpenDi**) där nästa generations Cosmic kompletteras med en openEHR-plattform under huven. Journalsystemets användargränssnitt behålls ("ser ut som vanliga moderna varianter av Cosmic"). - Cambio Open Services exponerar redan idag vissa informationsmängder via FHIR (länk finns på deras webbplats). Läs-API:er finns för fler områden; skriv-åtkomst är mer begränsad. - **KGC/SUSSA-perspektiv:** För regioner med Cosmic kan detta bli en smidig väg in i openEHR – under ytan byter man databas successivt, men användarna ser samma gränssnitt. - Åsa Skagerhult: Inom ÅSA-projektet experimenteras med dual-databasmodellen (gamla Spider + nya openEHR-baserade) där klinisk personal läser och skriver till båda utan att märka skillnad. --- ## Fråga 27 – Arketyper för kontinuerlig glukosmätning (CGM) **Möteskomplettering (möte 3, Erik Sundvall/Mikael Nyström):** Fråga ställd av Ruth Alicia Lochan Winton: det fanns ingen specifik arketyp för blodglukos i internationella CKM. Svar: - Det **fanns** en arketyp för blodglukos förut, men den **togs bort**. Anledningen: om man skulle ha en arketyp per labbvärde skulle det bli tusentals arketyper som är väldigt lika varandra. Istället används **laboratorie-testresultat-arketypen** (`openEHR-EHR-OBSERVATION.laboratory_test_result.v1`) där man sätter analyt till glukos. - **Tidsserie-stöd:** openEHR:s observationsklass (klassen OBSERVATION i referensmodellen) är gjord just för tidsserier. Man kan lagra enskilda värden i en serie med valfritt intervall, samt sammanfattningar som medelvärde, min, max per tidsperiod. Exempel: under en lugn timme sparar man ett sammanfattat intervall, men under en episod med kraftiga svängningar kan man använda kortare perioder med tätare datapunkter. - **Waveform-arketyp:** För kompakta kontinuerliga mätningar (t.ex. en mätning/minut) finns en waveform-arketyp där man kan lagra en massa mätpunkter efter varandra utan stora JSON-strukturer. - **Länkning till externt system:** Alternativt kan man i openEHR lägga en länk som pekar till ett annat system som håller de exakta värdena, förutsatt att det finns ett bra sätt att adressera data i det systemet. - **CDR är främst för långtidslagring** (Mikael Nyström): openEHR:s CDR är fokuserat på det som ska vara kvar i 10+ år i journalen. Kontinuerliga realtidsserier som bara är viktiga "här och nu" är kanske inte optimala att lagra fullt ut i CDR:n, men sammanfattningar och kliniskt relevanta urval kan mycket väl sparas. - **Framtiden:** Nästa version av openEHR:s referensmodell (Thomas Beale m.fl. arbetar med detta) kan få förbättrat stöd för tidsserier. - **Arketyper i CKM** att titta på: *laboratory test result* (observation) med klustret *laboratory analyte result*, samt *self-reported data* (composition-nivå) om datan rapporteras av patienten. --- ## Fråga 28 – Patientgenererad data i openEHR-CDR (lagring och juridik) **Möteskomplettering (möte 3, Erik Sundvall/Mikael Nyström):** - Region Stockholm har beslutat att **patientgenererad data kan lagras i CDR:n**, men den ska **markeras särskilt** – den är inte underskriven av vårdpersonal och räknas inte nödvändigtvis som journalanteckning. - **PDL** (Patientdatalagen) reglerar *journalhandlingar*, inte CDR:n som sådan. Viss data i CDR:n kan räknas som journalhandling (och lyder under PDL), annan data gör det inte. Det viktiga är att hålla isär detta tydligt. - **Offentlighetsprincipen** kan begränsa offentlig förvaltning från att hantera privata hälsokonton – det som står i en myndighets datalager blir i princip offentlig handling. - **openEHR är lagstiftnings-agnostiskt** (Mikael Nyström): Som internationell specifikation kan openEHR inte ta spjärn mot nationell lagstiftning – standarden är designad för att fungera under många olika lagstiftningar. Man kan alltså bygga en CDR helt fokuserad på egenrapporterad data utan en enda journalhandling i den. - **Tre dimensioner att hålla isär:** (1) lagrum – vilken lag gäller för informationen, (2) format – t.ex. openEHR, (3) lagringsplats – lagras den tillsammans med journaldata eller separat? - **EHDS-påverkan:** EHDS kan komma att kräva att myndigheter driver privata hälsokonton, vilket skulle ändra förutsättningarna radikalt jämfört med nuläget. Se även fråga 6. --- ## Fråga 29 – AI-agenter och verktyg för openEHR **Möteskomplettering (möte 3, Erik Sundvall/Mikael Nyström/Nicklas Jonsson):** Området är ungt och rör sig snabbt. Följande nämndes: - **Archetype Companion** – en MCP-baserad kodagent för openEHR-modellerare. Publicerad på openEHR:s diskussionsforum: [Archetype Companion](https://discourse.openehr.org/t/archetype-companion-a-new-sidekick-for-openehr-modellers/11798). - **Sebastian Iancus MCP-server** – från början en enda MCP-tjänst för openEHR som nu bryts upp i två delar: (1) hjälp vid modellering och tänkande, (2) interaktion med openEHR-system (generera testdata, instanser etc.). Se [discourse.openehr.org/search?q=mcp](https://discourse.openehr.org/search?q=mcp). - **DeepWiki** – indexerar GitHub-repositories och gör dem sökbara för AI-agenter via MCP. openEHR:s specifikationer finns på [deepwiki.com/openehr](https://deepwiki.com/openehr) och arketyperna (CKM-mirror) på [deepwiki.com/openEHR/CKM-mirror](https://deepwiki.com/openEHR/CKM-mirror). Erik Sundvall rekommenderar att ställa in sin AI-agent att använda DeepWiki via MCP istället för att "chansa" med vanliga webbsökningar. - **Agent Skills** ([agentskills.io](https://agentskills.io/home)) – ett öppet format för att ge AI-agenter nya förmågor. Nicklas Jonsson ser framför sig openEHR-skills liknande t.ex. [awesome-legal-skills](https://github.com/lawvable/awesome-legal-skills) för juridik. - **Konkret AI-exempel (Erik Sundvall):** Använde AI för att generera ett TypeScript-skript som tar AQL-frågesvar och placerar dem i rätt celler i en HTML-tabell (för prostatacancer-rapporter). Fungerade väl tack vare att openEHR-arketyper är så väldefinierade att AI:n kunde förstå semantiken – trots svenska etiketter, engelska arketyper och engelska instruktioner. - **Historisk kontext (Mikael Nyström):** AI-baserade beslutsstödssystem inom sjukvård har funnits sedan 1960-talet (MYCIN m.fl.), men misslyckades ofta pga att inmatning var separat och systemen var långsamma. openEHR skapades delvis *just för att* ge ett bra strukturerat datalager som kan föda AI-tillämpningar. SNOMED CT uppstod av liknande skäl. Nu, med den senaste AI-vågen, börjar infrastrukturen (openEHR + SNOMED CT) äntligen möta kapaciteten i AI-modellerna. - **Källkritik-varning (Mikael Nyström, Erik Sundvall):** openEHR:s diskussionsforum importerade gamla e-postlistor → det finns innehåll från 2000 och framåt. Mycket har ändrats sedan dess. AI-agenter bör vara källkritiska och beakta ålder och avsändare av svar. --- ## Fråga 30 – openEHR Sverige: mötesformer, nordiskt samarbete och organisation **Möteskomplettering (möte 3, Åsa Skagerhult/Mikael Nyström/Erik Sundvall):** **Mötesformer:** - **Arbetsmöten:** Varannan tisdag kl. 13–17. Första timmen: genomgång av pågående ärenden ("JIRA-tavla"). Kl. 14–17: gemensamt arbete på nationell nivå – kan vara vad som helst (t.ex. erfarenhetsutbyte-möten som dessa). Man får boka upp sig. - **Förvaltningsmöten:** Varannan fredag (veckor utan arbetsmöte) kl. 13–14. Mer övergripande diskussioner – EHDS, interoperabilitet, Vitalis-planering, processdokumentation kring arketypmodellering, m.m. - Alla möten är **öppna för vem som helst**. Man behöver inte bidra – det är helt okej att bara lyssna. Kontakta **Mikael Nyström** för att få en mötesinbjudan (inbjudan ger tillgång till framtida möten; vidarebefordrad länk riskerar att inte förnyas). - Möteslänkar publiceras inte offentligt pga risk för spam-deltagare. **Nordiskt samarbete:** - **Nordiska möten** med roterande värdskap mellan Norge, Finland, Sverige och Island. Ca 1–2 gånger per termin (ambitionen är 2, men det blir ofta 1). Island har nyligen blivit medlemmar i openEHR International – "en ganska stor grej". **Vitalis-middag:** - Tradition med **openEHR-middag** på tisdagskvällen under Vitalis-konferensen, öppen för alla intresserade. Självkostnadspris, informellt umgänge med internationella gäster, systemleverantörer, regioner m.fl. Förra året deltog bl.a. Rachel Dunscombe (openEHR International). **Organisationsstruktur:** - **openEHR International** – baserat i Storbritannien som ett icke-kommersiellt företag (jämförbart med svensk stiftelse). Sköter det internationella arbetet. - **openEHR Sverige** – en affiliate till openEHR International, organiserad som arbetsgrupp under **Svensk förening för medicinsk informatik (SFMI)** för att slippa starta en ny förening. Alla som vill bidra är välkomna. Det finns planer på att openEHR Sverige även ska bli en arbetsgrupp under **SFM**. - **Resursbrist:** Det behövs mer stabila resurser och finansiering för att skala upp openEHR i Sverige. E-hälsomyndigheten har visst intresse men har ännu inte lyckats ordna finansiering.