Dokument

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:

Open

Karolinska sjukhusets Strategi för digitalisering & AI relaterar i flera av sina delar direkt och indirekt till datadrivet tänk och vårddataplattform

Open

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:

Open

Material från Karolinskas/Stockholm/Gotlands upphandloing av openEHR-system och tjänster finns länkade från https://discourse.openehr.org/t/karolinska-stockholm-procurement-of-digital-health-platform-cdr-tools-services-consultants/4457

Sedan finns tre varianter av integrationsstrategier som tbeskrevs 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ågor och svar om införande av openEHR och relaterade erfarenheter

Sammanvävd version. Nedanstående AI-sammanfattning från mötestranskriptioner har snabbgranskats och förtydligat manuellt (vissa rättningsbhov kann finnas kvar). Denna fil kombinerar det befintliga innehållet från ursprungliga wikisidan (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 men omformatterats i “wikisvar” nedan.

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 samtidigt för vårdgivare på et tydligare sätt. 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”? 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 (som för klassiska journalsystem) 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 det ingen passande arketyp kan man snabbt bygga en egen (eller en kluster-arketyp med t.ex. fler detaljer, som jackas in i en befintlig arketyp). 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 görokrati / doocracy – den som tar tag i modelleringen driver den framåt och bestämmer därmed en hel del av riktningen.

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.

• 3. Resursen Patient (med en egen FHIR-profil) används flitigt t.ex. 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:

1. myndighetsrapporteringar

2. kvalitetsregister

3. 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 och andra vårdgivare använder samma arketyper och liknande templates kan man mellan dem dela exportskript för data som ska till kvalitetsregister och myndigheter (alltså dela på arbetsbördan).

• 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 ca 50 % av de nationella kvalitetsregistren och har en strategi där plattformen succesivt får en central roll.

• 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.
  [Tillägg April 2026: “EHR slices” med FHIR, openEHR och openEHR-FHIR-mappningar inuti FHIR implementation guides diskuteras nu, kopplat till bl.a. EHDS]

• Australien använder openEHR-modeller som kärna för klinisk konsensus (levernatörsneutralt) och bygger sedan FHIR-profiler ovanpå – ett framgångsrikt mönster.

Från möte 2: I Symphony-projektet (EU/ITEA/Vinnova, 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 andra register.

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älsokonton, 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 https://github.com/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 och bedriver försäljning i andra regioner/länder. Ytterligare leverantörer har tillkommit på marknaden efter upphandlingen

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

• "ePatient Dave" nämns som exempel på en 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). Allt behöver inte var hyperstrukturerat, vissa saker är lämpligare att fånga i fritext. Se även https://youtu.be/7DCe2LpM7xo   16 minuter, på engelska med Silje Ljosland Bakke

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 som inte använder openERH internt kan andra standarder (IHE, OMOP, FHIR etc) 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å wikisidanProcurement 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 – https://discourse.openehr.org/t/the-swedish-openehr-platforms-and-tools-rfi-2023/3840 – den inkluderar en slutrapport och länkar till videoinspelningar av demonstrationer från flera olika leverantörer.

• Allt om Stockholms senaste openEHR-upphandlingar (inklusive krav) och en del avrop från resulterande ramavtalet finns i diskussiontråden https://discourse.openehr.org/t/karolinska-stockholm-procurement-of-digital-health-platform-cdr-tools-services-consultants/4457

• Region Östergötland genomförde en RFI 2020 inspelningar länkas från t.ex. inlägget https://discourse.openehr.org/t/swedish-openehr-procurements-rfis/247/9 en del andra uppohandlingsrelaterade erfarenheter delas i diskussionstråden

• En del personliga tankar om upphandlingar finns i presentationen https://docs.google.com/presentation/d/1NZjqsCdQhIox6Zjp3UWlRtiQoFZjt0Ex/edit?usp=sharing&ouid=112660550613841635682&rtpof=true&sd=true av @Åsa Skagerhult (då Region Östergötland) och @Erik Sundvall (Karolinska), inklusive tänkbara alternativa upphandlingsformer på t.ex. bild 19 till bild 21.

• Katalonien har publicerat information om många av sina upphandlingar sök t.ex. på RFI i openEHRs forum https://discourse.openehr.org/

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 utanfö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 “DIS”) 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 https://www.linkedin.com/in/inger-malmgren-7b4b48116/, 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 som innehåller uppdraget att testa metoder och beräkna kostnad för leverantörsbyte av formulärdelen. Krav ställs på att formulärformat ska vara öppna och inspekterbara (vid upphandlingstillfället fanns ingen standard för det och inte tillräckligt många bra opensource-alternativ).

• MedBlocks UI (https://github.com/medblocks/medblocks-ui) 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 (och mellan vårdgivare) – 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 många nya integrationer ska gå via CDR:n, när så är lämpligt. 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.

Uppdatering i April: Informationsstrategin finns nu länkad längre upp på denna sida

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å typ av data:

• 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 tidigare).

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 projekt HiGHmed och ett spanskt företag (Veratech) har gjort omfångsrika mappningar (FHIR ↔ 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 (FHIRBridge 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 ofta 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 programvaruleverantör (Ocean Health Systems) – 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-projekt) har implementerat detta. @Severin Kohler (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", "Severing Kohler", "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 som Karolinska råkade ut för leverantören hade gjort ett misstag i konfiguration).

• Patient Orchestrator: En transaktionsbaserad komponent (som enligt kontraktet ska släppas som Open Source) 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 m.m.) byggs baserade på openEHR-templates i Alltid Öppet-appens administrationsgränssnitt (där det redan fanns en fomulärbyggarfunktion som relativt enkelt kompletterades med openEHR-stöd). Patienten fyller i → appen sparar i sitt format (som nu även innehåller kopplingar till openEHRs förenklade “FLAT”-format) + skickar en openEHR-COMPOSITION till CDR:n → kliniker ser data via översikts-applikation (webappen MBÖ) som ställer AQL-frågor mot CDR:n → kliniker klickar sammanfattningsknapp och en sammanfattande journalanteckning genereras och skrivs till TakeCare → kliniker går in och kontrollerar, kompleterrar vid behov och signerar i TakeCare.

• CytoDos-exemplet: Data flödar via datalager via Kafka, konverteras till openEHR och lagras i CDR:n (EHRbase kördes under en övergångsperiod innan leverantörsbyte). FEEDER_AUDIT i openEHR används för att spåra/lagra datans ursprung och källsystemets identifierare för datapunkten och möjliggör därmed uppdateringar vid eventuella nya versioner av källdata.

• Uthopp (context launch): Från översikts-applikationen (MBÖ) kan man hoppa ut till labbsystem, till TakeCare-anteckningar m.m. via kontextlänkar. Och från TakeCare kan man hoppa till översikts-appen.

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 och har genomfört en lyckad PoC, se detaljerade presentationer, källkod m.m. via https://github.com/regionstockholm/poc_tc2openEHR

Open

Illustration från sammanfattande poster/artikel A13 i https://link.springer.com/article/10.1186/s12919-026-00367-3#Sec51 se även Github-länk ovan för mer detaljer i länkade presentationer

• Strukturerad data (läkemedel m.m.) mappas "den snygga vägen" direkt till passande internationella 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 byggdes som härmar gamla journalsystemets utseende (sökordsnavigering, med samma sorts filter) men läser från CDR:n. Målet: släcka gammalt system först för att sänka kostnader och underhåll/säkerhetssrisker och sedan 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 och sköta konverteringen; andra kan sedan använda det färdiga resultatet (konverterad data) 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.e.x med formulärbyggar-stöd) – t.ex. för ett nytt behov eller litet "vildsystem" (Excel-baserat register, nischsystem etc. kallas “feral systems” på engelska) eller något annat som ändå ska avvecklas. Då slipper man extra 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 i Stockholm innehålla "3,7 mmol" eller "krossat provrör"). Börja hellre med ett tydligt avgränsat formulär eller import av väldigt välordnad data.

• 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 på tiden 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. (Det ryktas att Stockholm kan komma att mellanlagra Obstetrix-data i openEHR-format.)

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 med bock vid namnet, status "Published" samt pågående arbete och föreslagna arketyper) och dels inkubatorer – projektspecifika ytor där ett par informatiker kan labba och testa och status kan vara väldigt varierande.

• 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 samt ev. om den ligger i inkubator.

• Ö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” (grenar) och föreslå ändringar men inte ändra på officiellt innehåll (utan särskilt tilldelade rättigheter).

Fråga 23 – Symphony-projektet (konkret multi-system-integration)

Möteskomplettering (möte 2):

Symphony var ett EU/ITEA/Vinnova-finansierat projekt kring prostatacancer med final review mars 2026. Demonstrerade hur man kopplar ihop:

• Patientrapporterade data (Cuviva och REgion Stockholms invånarapp Alltid Öppet)

• Radiologibedömningsformulär (Sectra)

• Data från TakeCare

• Beslutsstöd (Cambio)

• MDK-dashboard (multidisciplinär konferens) sammanställde automatiskt data från källor och visade kategorisering från beslutsstöd.

Nyckelprincip: modellera med openEHR från början och skjut ut templates till respektive källsystem så långt det går rean i “design time”. Sectra har byggt stöd för att importera openEHR-templates och generera formulär med inbyggda sökvägar → data kan exporteras i openEHR-format direkt (och lagras i legacy-format parallellt). Samma approach användes i den Stockholmsägda patient-appen Alltid Öppet. Leverantörerna valde båda att anävnda openEHRs förenklade JSON “FLAT” format som output och WebTemplate JSON som “schema” input i fomulärbyggaren vid formulärförfattande,se info om båda i https://specifications.openehr.org/releases/ITS-REST/development/simplified_formats.html

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 kvalitetsmärkning/klassning.

• Kliniska översikter kan markera data med lägre tillförlitlighet visuellt (t.ex. färgkodning/mönster/ikon).

• 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 (juridiskt olika lagrum) – t.ex. att den inte är gramskad/underskriven av vårdpersonal. Man undersöker hur man sätter "varningsflaggor" i översikter för data med lägre kvalitetssäkring. Läkare har sagt att de heller har möjlighet att gräva i all data så länge den är flaggad och själva bedöma snarare än att bara visas färre datapunkter med förmodat högre kvalitet.

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 (och arketyper) blir delbara. En region kan fokusera på ett område och andra kan granska och återanvända deras arbete.

• Exempel: Region Östergötaland (via ASHA-projektet) modellerar ekokardiografi → Stockholm planerar använda det. Stockholm har modelleratsaker om bröstcancer och prostatacancer → 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 i längden 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. (Kvalitetsarbete och engagerad klinisk personal lik den som idag driver kvalitetsregister behövs fortfarande, men kanske då istället fokuserar mer på hur man borde journalföra i källan och på att hjälpas åt med sökfrågor än på att klura på vilka nya variabler man kan önska få exporterade.)

• En ny satsning från Cambios bygger succesivt in openEHR under huven av Cosmic. Kundgruppen Cosmic (KGC) bör kunna använda detta för att modellera gemensamt på sikt.

Fråga 26 – Cambio Cosmic och openEHR

Möteskomplettering (möte 2, Mikael Nyström/Erik Sundvall):

• Cambio har en satsning 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").

• 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 ASHA-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.

• Cambio Open Services (https://developer.openservices.cambio.se/ och https://www.cambio.se/vi-erbjuder/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.

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 XML- eller 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 fokuserad 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: I förslag till nästa version av openEHR:s referensmodell (Thomas Beale m.fl. arbetar med detta) kan få förbättrat/förenklat 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 om inte andra lagar trumfar offentlighetsprincipen. (EHDS och dess följder kan dock ändra lagstiftning se nedan.)

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

• Sebastian Iancus AI-plugin, MCP-server etc – 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 https://discourse.openehr.org/t/openehr-assistant-plugin-set-for-ai-agents/16729 (2) MCP för interaktion med openEHR-system (generera testdata, instanser etc.). https://discourse.openehr.org/t/openehr-assistant-mcp-server/11701

• DeepWiki – indexerar GitHub-repositories och gör dem sökbara för AI-agenter via MCP. openEHR:s specifikationer finns på deepwiki.com/openehr och arketyperna (CKM-mirror) på 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. Eller ännu hellre använda Cadasto/Sebastian Iancus MCP och agent “skills/plugin”

• Agent Skills (agentskills.io) – 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 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 inklusive 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 sammanhang, å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, se länkar i Möten nationellt arbete :

• 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 SFMI.

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