Arbetsmaterial UMI i openEHR

Owned by Claudia Ehrentraut
Last updated: 30-Apr-2024 by Claudia Ehrentraut
56 min read

Projektinformation

Denna wikisida är avsedd att utgöra grunden till en implementationsguide som beskriver ett rekommenderat sätt att journalföra/lagra uppmärksamhetsinformation i openEHR-baserade system på ett gemensamt leverantörsoberoende sätt. Ett mål är att åtminstone täcka in hur olika delar av openEHR (t.ex. referensmodell, arketyper och templates) kombinerade med terminologiurval etc. kan tillgodose kraven/informationsinnehållet i Socialstyrelsens informationsspecifikationer för uppmärksamhetsinformation.

Relaterade resurser:

Tankar fångade innan projektdtart:

Projektlogg/status

2024-05-14 Nationellt Arbetsmöte

Deltagare

Agenda

2024-04-30 Nationellt Arbetsmöte

Deltagare

  • @Ann-Sofi Avindell @Ruth Lochan Winton @Joana Vicente @Claudia Ehrentraut @Rikard Lövström

  • @maria.h.berggren & Vivéca Busck Håkans för EHM

Agenda

E-hälsomyndigheten deltar för att ge feedback på implementationsguiden för uppmärksamhetsinformation

Anteckningar

  • Gruppen återkopplade nedanstående till EHM

  • Gått genom EHM:s kommentarer, Claudia antecknade dem i separat fil (får inte spridas) som kan gås genom vid nästa möte

2024-04-16 Nationellt Arbetsmöte

Deltagare

@Ann-Sofi Avindell , @Joana Vicente @Hans Natvig @Ruth Lochan Winton @Claudia Ehrentraut

Agenda

  • Kolla på Rikards översättningsförslag för Adverse reaction risk, Clinical Knowledge Manager (openehr.org)

  • Kolla på övriga remissvar: SFMI, SKR

  • Disutera refuted/resolved utifrån Rikards formuleringar ovan

Anteckningar

Att göra

  • Claudia och Hans fixar kommentarer i ig:en

  • Kolla på Rikards översättningsförslag och formuleringar på nästa möte i maj

2024-04-02 Nationellt Arbetsmöte

Deltagare

@Joana Vicente @Hans Natvig @Ruth Lochan Winton @Claudia Ehrentraut @Rikard Lövström @Anders Thurin @Ann-Sofi Avindell @Erik Sundvall @David Wetterbro

Anteckningar

  • Rikard skapar förslag på översättning för Adverse reaction risk, Clinical Knowledge Manager (openehr.org), utifrån befintlig påbörjat översättning. Övriga kollar genom förslaget när det är framtagit.

  • Gått genom Sanna Åsbergs och David Wetterbros kommentarer:

    • Övergripande

      • Skulle underlätta om logiken exemplifieras i ett formulär men det kanske är svårt eftersom det inte finns ett standardiserat format?

        • Ta fram formulär utifrån templaten, med referens till verktyg som kan användas och skärmdumpar

      • Vi skulle hellre se länkar till arketyperna än referenser.

        • Fixar

      • Går det att presentera vilka urval som ska användas tydligare? Exempel Other medicial condition.condition ska sättas till Annat medicinskt tillstånd.värde. Eller bara någon kort rad inledningsvis att först kommer beskrivningen av fältet i arketypen och sen fältet i NI-modellen.

        • Beskriv tydligare var urvalen kan hittas i IG

      • Dokumentet i sig beskriver en rekommendation men varje del innehåller ett antal SKA. Går det inledningsvis förtydliga att implementationsguiden är en rekommendation men om man vill implementera helt utifrån guiden så finns det vissa måsten?

        • Fixar

    • Health summary-arketyp

      • Bör composition-arketypen beskrivas i texten?

        • Fixar

    • medical_treatment_category.v0

      • Går det förtydliga var den arketypen återfinns och hur man ska hantera den innan den finns i CKM:en? Finns det något tänk för hur arketyper som ingår i implementationsguider i framtiden ska hanteras till dess att de landar i CKM:en?

        • Fixar

    • Annat medicinskt tillstånd

      • Hur gick resonemanget gällande refuted vs resolved?

        • @Rikard Lövström tar fram en formulering utifrån

          • image-20240402-125559.png

            För att beteckna att ett omnämnt problem nu inte längre var ett problem så tänker vi oss att det är ett kliniskt ställningstagande att efter närmare eftertanke alternativt kompletterande utredning, konstatera att problemet inte längre är ett problem. 

             

            Vi valde då termen "refuted" som lämpligaste term för att den mer liknade ett aktivt ställningstagande kring att det nämnda problemet nu inte längre var ett problem. 

             

            ("Resolved" hade mer antytt att det bara var ett löst problem i största allmänhet, inte säkert någon tydlig klinisk beslutsprocess bakom det.)

Att göra

 

Remissvar

Nedan bifogas de remissvar som har kommit in:

  • SKR till contact@openehr.se

  • SFMI till contact@openehr.se

  • E-hälsomyndigheten till claudia.ehrentraut@regionstockholm.se / contact@openehr.se

  • David Wetterbro och Sanna Åsberg (Region Östergötland) till claudia.ehrentraut@regionstockholm.se

2024-03-19 Nationellt Arbetsmöte

Deltagare

@Joana Vicente @Hans Natvig @Ruth Lochan Winton @Claudia Ehrentraut

Anteckningar

  • Informerat om att översättningsgruppen sa att vi kan skicka in förslag på översättning till dem.

  • Skapat ny branch med senaste översättningsförslag (dvs Rikards förslag samt justeringar från mötet den 5/3) utifrån revision 10 i trunken, se Clinical Knowledge Manager (openehr.org)

Att göra

  • Claudia skickar förslag på översättning till översättningsgruppen (via Åsa) → fixat

2024-03-05 Nationellt Arbetsmöte

Deltagare

@Joana Vicente @Hans Natvig @Rikard Lövström @Anders Thurin @Ruth Lochan Winton @Claudia Ehrentraut

Anteckningar

  • Gått genom Claudias kommentarer på Rikards översättning, se nedan:

    • Purpose

    • Use

      • Undergoing a regular treatment such as radiation therapy or dialysis;

      • Nuvarande: genomgår behandling med strålbehandling eller dialys

      • Förslag: är under pågående strålbehandling eller dialys

    • Misuse

      • Not to be used to record advance directives for care or personal preferences of the individual. 

      • Nuvarande: Ska inte användas för att dokumentera avancerade direktiv av behandling eller för att registrera individens personliga preferenser.

      • Förslag: Ska inte användas för att dokumentera individens önskemål om vård och behandling.

    • Condition

      • Identification, by name, of a condition or state.

      • Nuvarande: Namnet på tillståndet eller statusen.

      • Förslag: Benämning av tillståndet eller statusen.

    • Status

      • 1)

        • Clinical systems may choose not to display Precaution entries with a 'Refuted' status in the Precaution list.

        • Nuvarande: Kliniska system kan välja att inte visa anteckningar om försiktighetsåtgärder med statusen 'Avfärdad' i en lista med försiktighetsåtgärder. 

        • Förslag: Kliniska system kan välja att inte visa anteckningar för observandum som har status 'Avfärdad' i en lista med observanda. 

      • 2)

        • However, 'Refuted' may be useful for reconciliation of the Precaution list or when communicating between systems. 

        • Nuvarande: Emellertid kan 'Avfärdad' vara användbar vid sammanställning av listor med försiktighetsåtgärder eller vid kommunikation mellan system. 

        • Förslag: Emellertid kan 'Avfärdad' vara användbar vid sammanställning av listor med observanda eller vid kommunikation mellan system. 

      • 3)

 

Att göra

2024-02-20 Nationellt Arbetsmöte

Deltagare

@Joana Vicente @Ann-Sofi Avindell @Claudia Ehrentraut

Anteckningar

  • Info om att remissen är utskickad den 20/2 till nedanstående mottagare.

  • Kom överens om att vi använda arbetstiden för att läsa genom Rikards förslag på översättning som finns under Clinical Knowledge Manager (openehr.org) och gå genom den på nästa möte

  • Vi noterade att det har kommit en ny version av Precaution-arketypen, dvs. 1.1.0, se Clinical Knowledge Manager (openehr.org) där “Additional details slot” blev tillagt. Inom ramen för detta stängdes Rikards branch med förslag på översättningar, se Clinical Knowledge Manager (openehr.org). Vi behöver skapa en ny branch utifrån version 1.1.0 och lägga in översättningar där när vi har gått genom dem. Vi behöver lägga till en översättning för “Additional details slot”.

    • image-20240220-144715.png

    • Förslag på översättning Claudia:

      • Additional details = Ytterligare information

      • Additional structured details about the precaution. = Ytterligare strukturerad information om observandumet.

      • Comment: For example: clinical evidence supporting the precaution. = Kommentar: Till exempel: kliniska bevis som stöder observandumet.

Anteckningar

  • Läsa genom Rikards förslag på översättning

  • Claudia bokar nytt tillfälle om två veckor

  • Claudia tar fram förslag på översättning för Additional details

2024-01-23 Nationellt Arbetsmöte

Deltagare

@Joana Vicente @Hans Natvig @Ruth Lochan Winton @Claudia Ehrentraut

Anteckningar

Att göra

  • Claudia kollar med Erik hur vi bäst delar templaten för granskning

  • Claudia skickar IG på remiss när hon har kolla med Erik

2024-01-10 Remissunderlag utifrån svar från Erik gällande PDL-remiss

Mejladresser som Erik skickade:

 

Fler mejladresser utifrån nedanstående förslag:

 

Förslag på inlägg

 

Förslag på mejl med rubrik: “Inbjudan till remiss avseende hantering av uppmärksamhetsinformation i openEHR”

 

Inbjudan

Du inbjuds härmed att senast 2024-02-29 (2024-03-31) i en remissrunda komma med synpunkter och förbättringsförslag avseende en implementationsguide och tillhörande openEHR-template som beskriver hanteringen av uppmärksamhetsinformationen i openEHR utifrån aktuell version 5.1 (juni 2022) av Socialstyrelsens informationsspecifikation för uppmärksamhetsinformation. Implementationsguiden har tagits fram av den nationella arbetsgruppen för UMI i openEHR som består av representanter från flera aktörer, t.ex. regioner och systemleverantörer och som är en del av openEHR Sverige.

Implementationsguiden finns på efterföljande wikisida: Uppmärksamhetsinformation i openEHR - openEHR Clinical - Confluence (atlassian.net)

Filer, genererade från ovanstående wikisida 2024-01-xx, för de som föredrar att kommentera och svara via Word eller PDF:

  • Länk word (x MB)

  • Länk PDF (x MB)

 

Hur du svarar

Feedback kan ges på den kombination av följande sätt du är mest bekväm med:

  • Svara via inlägg i denna diskussionstråd (även filer kan laddas upp här)

  • Om du har/skaffar inlogg till wikisidan: Svara genom att korrigera småfel direkt i wikisidan, eller markera text och använd kommentarsfunktionen om dit förslag är mer av en diskussionspunkt.

  • Maila kommenterad/ändringsmarkerad word- eller PDF fil till claudia.ehrentraut@regionstockholm.se

Framtid

Synpunkter från remissrundan kommer att användas för att förbättra implementationsguiden och tillhörande openEHR-templaten. Vid behov kommer ytterligare en remissrunda att genomföras.

2024-01-09 Nationellt Arbetsmöte

Deltagare

@Ann-Sofi Avindell @Rikard Lövström @Hans Natvig @Ruth Lochan Winton @Anders Thurin @Mikael Nyström @Claudia Ehrentraut

Agenda

  • Inleda remissprocessen för UMI:s implementationsguide (utifrån input från översättningsgruppen) samt fortsätta arbetet med översättningarna parallellt

  • Kolla på nytt förslag på översättning av Precaution (det fanns en översättning sedan tidigare men Rikard (framför allt), Joana, Ann-Sofi och Claudia har skapat ett nytt förslag på översättning utifrån den). För att se översättningen, gå in på Clinical Knowledge Manager (openehr.org) och välj Swedish. Förslag på översättning finns under Nytt förslag/Förslag/Rikards förslag)

  • Bestäm hur vi gå vidare med översättning för Adverse Reaction Risk och Medication.

Anteckningar

  • Remiss IG

    • fixat sista kommentarer i Uppmärksamhetsinformation i openEHR - openEHR Clinical - Confluence (atlassian.net)

    • diskuterat vilka mottagare som IG remissen ska skickas till

      • till openEHR Sverige

      • alla vi kunde komma på som kan ha något intressant att säga. → kolla med Erik S

        • myndigheter

        • swedish medtech

        • informatiknätverket inom regionen

        • kunskapsstyrningen

      • övriga förslag på remissinstanser som fanns med i IG:en

        • Organisationer som varit inblandade i framtagandet?

        • SFMI

        • E-hälsomyndigheten

        • NAG Strukturerad vårdinformation

        • Socialstyrelsen

        • Swedish MedTech?

        • IKT Norge

        • Helse Väst

        • Helse Sör

        • Helse Nor

        • Silje, Vebjörn…

      • Förslag på remissinstanser, i bokstavsordning (utöka/redigera gärna listan) i enlighet med SWE-anslagstavla - Agil-anslagstavla - openEHR JIRA (atlassian.net)

        • eHälsomyndigheten

        • Informella grupper

          • svenska ehälsonätverket

          • openEHRs “community” via forum etc.

        • SFMI (och ev. sektioner av SLS som SFMI bedömer relevanta)

        • Socialstyrelsen

        • Sveriges Kommuner och Regioner (SKR) inkl.

          • INERA

          • Kunskapsstyrningen

        • Swedish Medtech

        • Vårdförbundets sektion för hälsoinformatik

        • F.d. deltagare i möten om Nordic openEHR collaboration

        • Svenska openEHR-förvaltningens deltagare

        • Inlägg i svenska inkubatorn på CKM

  • Översättning Precaution

    • Rikard har skapat en uppdaterad översättning. Behöver granskas av arbetsgruppen

 

Att göra

Arbetsgruppen kollar på Rikards uppdaterad översättning
Claudia kollar med Erik S om vilka som har varit med i PDL remissen
@Ann-Sofi Avindell och Claudia fixar återstående kommentarer i IG:en

2023-12-08 Nationellt Arbetsmöte

Deltagare

@Claudia Ehrentraut @Rikard Lövström @Ann-Sofi Avindell @Joana Vicente

Anteckningar

  • Fortsatte med att gå genom översättningen av Precaution

    • Funderade om vi ska använda EVALUATION.advance_care_directive istället för EVALUATION.precaution för när patienten uttrycka önskemål om behandlingar, pga misuse “Not to be used to record advance directives for care or personal preferences of the individual. Use EVALUATION.advance_care_directive for this purpose.” i Clinical Knowledge Manager (openehr.org) → eller var det så att EVALUATION.advance_care_directive ska användas för primärdokumentation och EVALUATION.precaution för sekundärdokumentation?

    • Både unik och idosynkratisk för individen avser att det är specifik för individen.

    • Funderat på översättning av Resolved - Ska det vara upphört, löst eller något annat

2023-12-04 Nationellt Arbetsmöte

Deltagare

@Claudia Ehrentraut @Rikard Lövström @Sofia Lång Janstad

Anteckningar

  • Sofia är med och förklarar hur hon har jobbat med översättning kring Medical Device.

    • Kollat på material under Översättning - openEHR Clinical - Confluence (atlassian.net)

    • Arbetssätt för att hämta in synpunkter kring översättning från verksamhetskunniga: Skapat en peliminär översättning i CKM, lagt över till ett word-dokument skickat ut till verksamhetskunniga och bett att kommentera i dokumentet, sedan bokat uppföljningsmöte för att diskutera kommentarerna.

      •  

  • Påbörjat en branch för översättning av Precaution-arketypen: Clinical Knowledge Manager (openehr.org)

Att göra

2023-11-14 Nationellt Arbetsmöte

Deltagare

@Claudia Ehrentraut @Mikael Nyström @David Wetterbro @Rikard Lövström @Anders Thurin @Joana Vicente

Anteckningar

  • Anpassa beskrivning av logiken i IG, behöver inte nämna användaren

  • Diskussion kring skillnad mellan aktiv substans och hjälpämne, relation till NSL-id, det finns substanser som är både och hur tar vi hand om det? skiljer id nummret om det är aktiv substans eller hjälpämne? diskussion när Rikard ansluter till mötet- framgår från NSL id om substans är aktiv eller hjälpämne? behöver mer information om detta

  • Diskussion kring prestandan när NSL-id behöver kollas upp för hjälpämne.

Att göra

  • @Claudia Ehrentraut Uppdattera logik text mer generisk inte fokusera på användarperspektivet

  • @David Wetterbro uppdattera översiktsbilden

  • @David Wetterbro Översättning inte klar går via CKM verifiera om det finns påbörjat översättning

  • Läsa genom IG.

2023-11-28 Projektarbetsmöte

Deltagare

@Claudia Ehrentraut @Rikard Lövström @Hans Natvig @Joana Vicente

Anteckningar

Vi behöver uppdatera nya bilder utifrån senaste template
Lägg till Beskrivning på Begreppen samt källa
Länk till CKM för förklaring av arketyper
Lägga till ngt om use/misuse under Hantering av uppmärksamhetsinformation i openEHR, en egen rubrik- arbetsnamn: Template och Arketyper
Lägga till figurtitlar på alla bilder

2023-11-13 Projektarbetsmöte

Deltagare

@Claudia Ehrentraut @Rikard Lövström @Hans Natvig @Joana Vicente

Anteckningar

  • Diskutera vidare logiken:

    • Fortsätt formulera logiken i implementations guide.

    • Diskussion kring engång- dubbelinmatning

      • dubellinmattning, behandling anges i läkemedelmodul plus, dubbelinmatning där det anges ATC kod (UMI-modul-välja läkemedelsbehandling i condition och ange medical treatment category från listan, som representera ATC koderna från socialstyrelsen)

      • engångsinmatning- läkemedel ordineras i läkemedelsmodul, hämtas upp till UMI-modulen eftersom det läkemedel ingår i ATC koder i listan

      • Logiken kan vara annorlunda om det handlar om engångs- eller dubbelinmanting. Beskrivning anges i implementationsguide

      • NULÄGE - BEHANDLING LÄKEMEDEL
        Steg 1: vi ordinerar en läkemedelsbehandling i läkemedelsmodulen i en arketyp som motsvarar läkemedelsinformation.
        Regelverk 1: vi har en regel som söker fram steg 1-arketyper som innehåller ATC-koder som matchar Socialstyrelsens specifikation för behandlingar som ska flaggas som uppmärksamhetsinformation. Till exempel Waran som har ATC-kod B01AA03. Regelverket kan automatiskt se till att en steg 2-arketyp nedan skapas. Helst skulle den informationen automatgenereras men i värsta fall måste informationen i steg 2-arketypen skapas manuellt.
        Steg 2: i ett läge då vi behöver dubbeldokumentera så väljer vi här typ av behandling (exempel dialys eller läkemedel) för att begränsa urvalet i GUI. Om vi automatgenererar med hjälp av Regelverk 1 så behöver vi inte den informationsmängden i arketypen. Efter typ av behandling väljs exakt behandling ur en lista (exempel listan med dialys i, eller listan med läkemedelsbehandlingar som ska flaggas för).
        Regelverk 2: regelverket går igenom informationen i alla instanser av steg 2-arketyper. Finns det sådana av typen behandling så ska den motsvarande delen av UMI-symbolen tändas upp.
        Tändning av symbolen: den upptända variant av UMI-symbolen som väljs beror på vilka fält som regelverk 2 angav skulle vara upptända.

    • I en automatiserad variant behöver användaren bara ange steg 1-arketypen, alla följande steg kan automatiseras. Så Steg 2-arketyperna skulle i princip kunna tas bort i framtiden och ersättas av ett regelverk från steg 1-arketyp till tändning av symbolen. Dock tror vi att vårdens organisation och nivå av implementering av strukturerade it-system är sådan att detta kommer att dröja.

    • Diskussion om medical treatment category fält behövs i dubbelinmatning, det krävs om dokumentation saknas om patienten hos en vårdgivare

    • Val av läkemedel kan sker via ATC-grupp och i medikation del välja en läkemedel från listand. Alternativ är att inte gå via ATC grupp, att välja substans

Att göra

  • Kan en template bädda in inmatningslogiken?

2023-10-30 Projektarbetsmöte

Deltagare

@Claudia Ehrentraut @Rikard Lövström @Joana Vicente

Anteckningar

  • Beskriva flöde från primär arketyp till sekundär arketyp till presentationen. Bra om vi kan beskriva ett exempel och beskriva processen eller flödet från primär dokumentationen, sekundär dokumentationen och presentation i symbolen.

Beslut: att göra klart modellering innan beskrivning av flödet.

  • Logik diskussion:

    • hypersensitivites och allergies- adverse reaction risk, om en kategorin anges begränsas val av substance (kan termbindas till ATC kod)- detta behöver beskrivas.

    • Logik beskrivning anges i implementationsguiden.

  • Diskussion kring läkemedelsbehandling och överkänslighet kring kategori och substans

 

Att göra

  • Fortsätta diskussionen kring logiken

  • Beskriva ett exempel och beskriva processen eller flödet från primär dokumentationen, sekundär dokumentationen och presentation i symbolen.

2023-10-31 Nationellt Arbetsmöte

Deltagare: @Claudia Ehrentraut @Rikard Lövström @Anders Thurin @David Wetterbro @Erik Sundvall @Hans Natvig @Ann-Sofi Avindell @Joana Vicente

  • Vi går igenom vad som gjorts hittills och alla är överens om att det är korrekt

  • Hypersensitivity - Onset of last reaction
    Vi tar bort alla möjligheter att registrera datatyper av tidsangivelser förutom DateTime.
    Vi sätter även Pattern till AnyDateTime för att det ska gå att säga mer eller mindre specifika tider.

  • Contagion.Contagious disease.Review date & Last Updated stryker vi då ej del av SoS Specifikation

  • Conditions and Treatments stryker vi Review date och Last updated på både Other Medical Condition och Treatment, då ej del av SoS Specifikation

Diskussion

  • Pga att vi har termer från olika terminologier så föreslår vi i nuläget att man hanterar detta på formulärnivå (dvs i en formulärbyggare).

2023-10-30 Projektarbetsmöte

Deltagare

@Claudia Ehrentraut @Rikard Lövström @Anders Thurin @Joana Vicente

Anteckningar

Gått genom formuläret och tidpunkter:

  • Constrains-available types- onset of last reaction. Önskvärt med flexibelt datatyp, strängt?

Beslut: diskutera tidspunkter i större grupp.

Kardinaliteter:

  • Gått genom det som diskuterats den 2023-10-23

  • Kardinalitet för substance: behöver ange inaktiv/aktiv kardinalitet 0-1 till 1-1

    • category: ska den anges av användaren? Ibland kan systemet förfylla kategorin. Ändras till obligatorisk annars kan en läkemedel anges och ingen information finns om att dte är en läkemedel det handlar om. Anges som 0-1 och 1-1

  • Adverse reaktion risk anges som flera, det kan finnas flertal reaktioner. 0-*

  • Gått genom Carrier- Tidsfråga om protocol-period start/end Socialstyrelsen önskar en interval, Anges valid period start till obligatorisk, Valid period end ej obligatorisk.

  • Gått genom Other medical conditions- Protocol, aktiverar period start inaktiverar period end. "Annat medicinskt tillstånd" behöver endast en enda tidpunkt (när det konstaterades) eftersom det är en typ av tillstånd som i princip är bestående när de väl har upptäckts.

  • Medication details- form är icke obligatorisk, eftersom med ATC koder eller NSL koder, formen är inte relevant. Om läkemedelsprodukt väljs, ska form anges.

Beslut: form ska inte vara med i arketyp 2.

  • Implantat- En tidpunkt finns sätter valid period start till 1 och släcker valid period end.

  • Hypotes: Vi kommer att ha en typ av regel ("Regel typ 1") som summerar flera instanser av dokumentation från "Arketyp steg 1" till en "Arketyp steg 2". Vi kommer också att ha en typ av regel ("Regel typ 2") som summerar flera instanser av "Arketyp steg 2" för att om någon av dessa finns, så ska symbolen tändas på den platsen.

    Exempel: behandling med dialys plus blodförtunnande läkemedel hos två olika vårdgivare ger fyra instanser av Arketyp 1 som sedan summeras till varsin Arketyp 2 för dialys respektive blodförtunnande läkemedelsbehandling. Dessa två instanser av Arketyp 2 summeras ihop av Regel nivå 2 för att säga att den delen av symbolen ska tändas upp.

  • Non standard care procedures: Valid period end släcks. Review date kanske inte behövs i normalfallet men i vissa situationer kan det vara relevant (till exempel vid beslut om särskild vårdrutin av typen återupplivning, exempel "Noll HLR"/ingen hjärlungräddning).

    • Om beslut: förklarande kommentar i skriven text måste finnas. Smitta har dekats ut i två, förslag att göra en kopia av detta, Precaution (decision) och Precaution (Information) läggs till och comment släcks ner.

    • Om särskild vårdrutin="information" räcker det i sig. Om särskild vårdrutin="beslut" måste det kompletteras med en text (Comment alternativt länk till journalnotat, typ).

Att göra

  • Fråga sociastyrelsen om tidpunkten för reaktion?

  • Diskutera tidpunkter i större grupp, eftersom det är ett generellt sätt att ser på dokumentation; Se över om vi behöver review date och last updated.- diskuteras den 2023-10-31?

  • Fråga till Erik: hur styr vi urvalet för "Substans" utifrån angiven/inmatad "Category"? (ATC-->ATC-koder; Aktiv läkemedelssubstans-->NSLid för aktiva substanser; Hjälpämne-->NSLid för hjälpämne; kemikalie-->Snomed CT-kod ur urvalet för kemikalier överkänslighet

2023-10-23 Projektarbetsmöte

Deltagare

@Claudia Ehrentraut @Rikard Lövström @Anders Thurin

Anteckningar

Gått genom kardinaliteter

  • Vi har inte mappat attributet Överkänslighetstillstånd.värde (som har kardinalitet 1 i UMI specifikationen) till något attribut i arketypen. Anser att en “förekomst” av information som är strukturerat utifrån arketypen Adverse reaction risk-arketypen implicerar att risk för överkänslighet föreligger

  • Ändrat kardinalitet för Active/inactive status, verification status, criticality och onset of last reaction

    • Överkänslighetstillstånd.visshetsgrad anges enbart med 0..1 i UMI specifikationen men bör vara 1..1 → ändrat i arketypen utifrån det

    • Flöde för statusar av överkänslighet:

      • 1. överkänslighet misstänkt → Verification status = unconfirmed; Active/inactive status = active

      • 2. överkänslighet bekräftat/verifierad → Verification status =confirmed; Active/inactive status = active

      • 3. överkänslighet utesluten/motbevisat → Active/inactive status = inactive (arketypen som sådan inaktiv)

    • Kommentar Rikard: Det här är ett exempel på att "arketyp steg 1" kan vara först en instans av "överkänslighet har konstaterats", sen en instans av "överkänslighet har motbevisats" och en regel i regelverket (från arketyp steg 1 till arketyp steg 2) som säger att de två instanserna ska summeras och att den sistnämnda ska gälla och att i det exemplet ska inte en arketyp i steg 2 skapas (dvs ingen överkänslighet ska rapporteras/presenteras som UMI).)

 

Mappning av tid (vi bör ha en grundmappningtänk vad gäller tider, inkl. precision av tidsangivelse):

  • Vi har fem eller sex tidsbegrepp (minst) så frågan är hur de ska mappas?

    1. Händelsens tidpunkt i verkligheten.

    2. Händelsen observeras av patienten. → relevant gällande överkänslighet

    3. Händelsen observeras av HoS-personal → relevant gällande överkänslighet

    4. Patienten berättar om händelsen för HoS-personal (i de fall reaktionen inte sker under HoS-personalens observation).

    5. Händelsen dokumenteras av HoS-personalen. (t.ex. vid diktat)

    6. Händelsens dokumentation hamnar i journalsystemet.

  • “Onset of last reaction”/”Onset of first reaction” bör vara så nära källan som möjligt. Både onset of first reaction och last reaction mappar in mot definitionen av attributet tid i UMI-specen. Fångar inte vem som observerade, men kanske inte så viktigt i sekundärdokumentation. Båda tidpunkter bör finnas tillgängliga i arketypen, användningen beror på patientfall, last reaction ska anges (men bör tillåta ospecifik/diffus tid, t.ex. enbart år)

Att göra

  • Fortsätt se över kardinaliteter

    • i Adverse reaction risk för Substance

  • Behöver diskutera hur man kan ange olika tidpunkter i openEHR, vad är tillåtet

2023-10-17 Projektarbetsmöte

Deltagare

@Joana Vicente @Claudia Ehrentraut @Ruth Lochan Winton @Mikael Nyström @Erik Sundvall @Rikard Lövström @Anders Thurin

Anteckningar

@Claudia uppdattera gruppen om senaste veckornas arbetet. Informerar att Norska arketyper har använts för att jamföra moddelering ifrån svensk kontext. Fortsätter informerar om beslut kring implantation, transplantation, har socialstyrelsen tagit arbetsflöde till hänsyn. Implantat under kondition, respektive transplantat ska kodas med snomedct koder.

Allmänna kommentarer/återkoppling

  • Kolla med Erik varför man i mind map'en inte ser alla attribut Adverse reaction risk v2 - eventuellt bugg i CKM, nu synliga

  • Kolla med Erik att få in version 2 av adverse reaction risk i vår branch.- löst

  • Varför står det 0…0? Lite konstigt rent generellt lite förvirrande med kardinaliteterna:-, 0.0 det är en knapp för att göra det 0.0, om det är aktiverat till 0.1, om man ändrar vyn till tabellen kan man se notes till vissa occurences.

  • Under Uppmärksamhetsinformation Behandling har vi svårt att veta hur man skulle kunna ange ett subset för de koder som man “får ange” i UMI, troligen under http://Medication.Details.name , där vill vi ha ett subset. Senare i mötet hittade vi detta, där det finns ett subset, men vi behöver nog förstå hur det kommer att fungera: - under behandling kan vi ange olika saker, delvis tar ställning till dialys bla annat, om läkemedelsbehandling väljs ska man ange läkemedelsval, det kommer ligga i formuläret logiken.- kan anges som annotation i formuläret, medication val ska endast synas när medication valts. Logiken måste anges i texten om inte annat. Läkemedelsnamnet samt ATC kod kan användas. Man kan endast ange läkemedel som ingår i utpekad ATC grupper. I så fall akn det byta plats på de så uppslagen till terminologi server görs och läkemedel namnet kan knappas in. Detta ligger under medication details, en formulär kan flytta runt men ska kategorin ligga under mediciner? Uppmärksamhetsinfomration, pågående behandling och öbverkänsligheten tänder varningen, i templatet är detta under treatment så det är bra, det kan gå att lösa detta så. Behandlingskategori är egen bygd den är både på engelska och svenska kan vara bra att ha det på engelska. @Rikard Lövström ansluter till möte. För användare under medication details anges ATC koder som är underliggande till godkända grupper, begränsning är att inte alla ATC koder kan användas. All information ska inte finnnas i arketypen det räcker att veta vilken produkt det handlar om. Produkterna kommer mot termbaser. @Anders Thurin ansluter till möte, det diskuteras klassifikation för läkemedelorsak, det kommer i primärdokumentation. ATC kod eller NPL id eller substand kod/id som är information som ska användas här, resten av information ska plockas ut från andra instanser. Finna det mappning mellan NPL och ATC? om detta är steg 2, vad ska tändas up, arketyp 2 ska presentera informationen med information som leder till produkten som har överkänslighet. i nuläget hämtas inte denna information från primär dokumentation. ATC koderna ska väljas endast frn de förbestämda grupper. Template är inte kopplat till terminologitjänst, utskrivna läkemedel kan hämtas eller kopplas. Detta ska inte göras för implementationsguide men bör nämnas i implementationsguiden. I ATC kodning under name, det är termlistor men annars kan man ange sträng (regularexpression, strängen måste börja med ATC..). Finns olika alternativer, integrationskoden eller formulärkoden, lämna det till implementationen och samla in återkoppling.

  • L03A och L04 är separat ska de delas upp? Om de är updelade är det lättare att kommunicera med terminologiservern. Redigera texten alltid i originalt språkvariant.

  • Varför är det ibland External- och ibland Internal coded?- Det finns interna arketyper, det kan funka med reload, växla språk från engelska till svenska.

  • ska non standard care procedure och hiper sensitivity lyftas upp till andra arketyper? det kan man göra.

  •  

Att göra

  • Se över kardinaliteter, genom att använda formuläret

  • Kolla genom Koden B01A

  • Uppmärksamhetsinformation Behandling- Behöver beskriva lite logik kring behandling, och byta/uppdatera bilder i implementationsguiden

  • Arbete kvar i att översätta/byta språk, bra om arketyper finns på engelska

  • Översätta version 2 av precaution arketypen, adverse reaction risk

  • Vi har inte mappat mot vilken tidpunkt ska det mappas onset last reaction/first reaction.

2023-10-13 Möte

Deltagare

@Joana Vicente @Rikard Lövström @Claudia Ehrentraut @Hans Natvig

Anteckningar

@Claudia fortsätter uppdattera arketypen och går genom implantat delen

Under mötet fortsätter vi gå igenom inkomna kommentarer på Uppmärksamhetsinformation i openEHR - openEHR Clinical - Confluence (atlassian.net) och kollat igenom arketypen utifrån dem samt gjort följande:

  • implantat condition ska sättas till förekomst av implantat.värde

  • Primär dokumentation ange lokalisering av implantat i kroppen planeras att lägga in en extension för kroppsstruktur, i arketypen

  • Vi väljer Snomed CT koder eftersom det kan användas som urval , ICD10 inte gjort för primär dokumentationen, mappningar finns mellan Snomed CT och ICD10.

  • Implantat/transplantat beslut om att sekundär informationen (det som är relevant är konstanterat förekomst av implantat) , implantation är dokumenterat i primär dokumentation, det som tänder symbolen är sekundär infomrationen.

Allmäna kommentarer

  • Bra om uppmärksamhets signal visas i andra system (RIS, ORBIT..)

2023-10-06 Möte

Deltagare

@Ann-Sofi Avindell @Joana Vicente @Rikard Lövström @Claudia Ehrentraut

Anteckningar

@Claudia har uppdaterat till version 2 av arketypen

Under mötet fortsätter vi gå igenom inkomna kommentarer på Uppmärksamhetsinformation i openEHR - openEHR Clinical - Confluence (atlassian.net) och kollat igenom arketypen utifrån dem samt gjort följande:

  • Släckt Condition.status.Resloved i Other Medical Condition samt uppdaterat implementationsguiden

  • Extension.Medical.details samt Extension.Medical.details.form från anser vi ska vara kvar eftersom vi i framtiden kan vilja ange det. Vi tar bort kommentaren och lämnar arketypen oförändrad.

  • Extension.Medical.details.description släcker vi i arketypen

  • För att kunna fånga beskrivning i beslutet:

    …så tänder vi Comment:

     

 

  • Vi har uppdaterat några av de länkhänvisningar som finns i dokumentet samt lagt till länkar till alla relevanta arketyper under kapitlet Referenser.

Assistans behövs

  • L03A Immunstimulerande medel och L04 Immunsuppressiva medel ligger på samma rad i:

    och detta är inte korrekt, det borde vara 2 separata val. Men vi får inte ändra det?
    I samma urval finns B01A och den ska tas bort, men vi får inte heller göra det.

Allmäna kommentarer

  • Vår version 1 av detta arbete täcker bara Sverige och detta kan få resultat i vad vi väljer att släcka.

  • Vi skulle behöva gå igenom all namnsättning och se till att vi är konsekventa med hur vi ändrar. Detta behöver gås igenom vid tillfälle.

  • Bilden över arketypshierarkin behöver uppdaterats, så att det syns att det är version 2 som används.

 

2023-09-29 Möte

Deltagare

@Ann-Sofi Avindell @Joana Vicente @Rikard Lövström @Claudia Ehrentraut

Anteckningar

  • Vi har gått genom kommentarer på Uppmärksamhetsinformation i openEHR - openEHR Clinical - Confluence (atlassian.net) och kollat genom arketypen utifrån dem och gjort följande:

    • Ändrat koden för Förekomst av smittämne till 64301000052105 |blodsmitta hos gravid| med kommentaren att det är sekundärinformation. I framtiden kommer det att behöva finnas en formel för vilka koder (gravid + positivt HIV test tex) som triggar denna.

    • Lagt till urvalet 59821000052101 |urval medicinska tillstånd, uppmärksamhetsinformation| under Condition i Annat medicinskt tillstånd (@Claudia Ehrentraut fixar efter mötet → CE: fixat)

    • I:

      tagit bort : LD_Drug treatment with optional specific substance information (Alt 1b) &

      OLD_Treatment (non drug)

    • Döpt om Treatment (NEW combined) till Treatment


  • Saker att komma ihåg:

    • Se över alla kardinaliteter.

  • Här behöver vi assistans:

    • Under Uppmärksamhetsinformation Behandling har vi svårt att veta hur man skulle kunna ange ett subset för de koder som man “får ange” i UMI, troligen under Medication.Details.name, där vill vi ha ett subset. Senare i mötet hittade vi detta, där det finns ett subset, men vi behöver nog förstå hur det kommer att fungera:



    • Varför står det 0…0? Lite konstigt rent generellt lite förvirrande med kardinaliteterna:

       

    • Varför är det ibland External- och ibland Internal coded?

 

2023-09-28 Möte

Deltagare

@Ann-Sofi Avindell @Hans Natvig@Joana Vicente @Rikard Lövström @Claudia Ehrentraut

Anteckningar

Att göra

  • Kolla med Erik varför man i mind map'en inte ser alla attribut Adverse reaction risk v2

  • Kolla med Erik att få in version 2 av adverse reaction risk i vår branch.

2023-09-19 Möte

Deltagare

@Ann-Sofi Avindell @Erik Sundvall @Hans Natvig@Joana Vicente @Mikael Nyström

@Rikard Lövström David Wetterbro @Claudia Ehrentraut

Anteckningar

  • gått genom kommentarer och svaret på Uppmärksamhetsinformation i openEHR - openEHR Clinical - Confluence (atlassian.net)

  • kommit överens att första versionen av implementationsguiden matchar socialstyrelsens nuvarande specifikation

  • kommit överens om två arbetsmöten för att uppdatera templaten utifrån genomgången av kommentarerna i implementationsguiden. Möten är inbokade torsdag 28/9 10-11:30 och fredag 29/9 15-16:30 (just nu är Rikard, Joana, Hans och Claudia inbokade. Fler som vill ansluta kan höra av sig till Claudia

Att göra

  • boka nytt möte om 4 veckor

  • uppdatera templaten under inbokade arbetsmöten

  • David uppdaterar bilden

2023-09-05 Möte

Deltagare

@Ann-Sofi Avindell @Erik Sundvall @Hans Natvig@Joana Vicente @Mikael Nyström

@Rikard Lövström Susanna Jönsson @Thérèse Högberg Mårder @Claudia Ehrentraut

Anteckningar

 

 

Äldre anteckningar

2022-02-02 Info

Inväntar koordinerat datumförslag för uppstartsmöte

2022-05-16 Info

Första arbetsmöte planeras den 2022-05-31

2022-05-31 Möte

Deltagare

  • Susanna Jönsson, @Alexandra Saraiva Leao, @Carina Sandell @Emma Molin @Erik Sundvall @Claudia Ehrentraut @Ann-Sofi Avindell @Mikael Nyström @David Wetterbro, …

Anteckningar

  • Presentation av deltagare. Info om att verion 5.1 av SoS UMI-dokumentation kommer inom någon vecka och vilka ändringar som ingår. Diskussion om mål och angrepssätt (turordning av arbete) se rubriker och text i dokumentet nedan. Beslutar ha möten tisdagar jämna veckor 15:30-17:00, 14 juni sista före sommaren. 23 Aug första efter sommaren, Läxa till nästa möte kolla länkar ovan och leta tänkbara arketyper att använda + fråga Norge.

2022-06-14 Möte

Deltagare

@Anette Larsson @Mikael Nyström @Ann-Sofi Avindell @Claudia Ehrentraut @Erik Sundvall

Anteckningar

  • Börjar dokumentera tankar från tidigare möte i implementationsguiden nedan. @Ann-Sofi Avindell börjar uppdatera tabellen över terminologiurval i dokumentet nedan.

2022-08-23 Möte

Deltagare

@Emma Molin @Mikael Nyström @Ann-Sofi Avindell @Alexandra Saraiva Leao @Anette Larsson @Erik Sundvall

Anteckningar

  • Beslutat att försöka arbeta med en “ben” i taget då de har väldigt olika innehåll.

  • Diskussion kring “Annat medicinskt tillstånd”: openEHR-EHR-EVALUATION.problem_diagnosis.v1 verkar vara den mest passande då allt som, enligt SoS info spec, klassas som “Annat medicinskt innehåll” är diagnoser. För att kunna veta om en diagnos är aktuell eller inte är en hypotes att vi kan använda attributet “Date/time of resolution”. Att kunna veta om en diagnos är aktuell eller inte är nödvändigt för att kunna avgöra om diagnosen ska trigga att uppmärksamhetssignalen tänds eller inte.

  • Diskussion kring andra huvudgrupper: Kommer inte bli lika enkelt att modellera dessa. Exempelvis diskuterades Förekomst av transplantat där det finns olika sätt att uttrycka förekomsten av transplantat, både med diagnoser och substanser som inte kommer kunna täckas av samma arketyp.

2022-09-06 Möte

Deltagare

@Claudia Ehrentraut @Mikael Nyström @Alexandra Saraiva Leao

Anteckningar

  • Diskussion kring vilka kodsystem ska man gå efter vid modellering: ICD-10, ATC eller SNOMED CT. SoS specifikation har ingen one-to-one mappning från ett kodsystem till ett annat. ICD-10 kommer att ersättas med ICD-11. SNOMED CT ger bättre förutsättningar till interoperabilitet (lokalt, nationellt och internationellt). Tänk utanför boxen på nästa generationssystem.

  • Förslag på uppgifter till nästa möte:

    • Fördjupa sig mer i SoS specifikation kring information i del Medicinskt tillstånd och behandling, subgrupper: Annat medicinskt tillstånd, Behanling.

    • Gå igenom texten under rubrik Medicinskt tillstånd och behandling, ändra och lägg till egna idéer i ämnet.

2022-09-23 Möte

Deltagare

@Emma Molin @Mikael Nyström @Ann-Sofi Avindell @Erik Sundvall @Claudia Ehrentraut Rikard Lövström

Anteckningar

  • Ann-Sofi presenterar arbetet på Förslag på mappning UMI/OpenEHR • Cambio Healthcare Systems (mural.co)

    • Alla håller med om att Adverse Reaction Risk är rimlig att använda för överkänslighet

    • Lång diskussion kring användning av Adverse Reaction Risk och des underliggande “gren” Reaction Event och vilka attribut som mappar mot varandra i arketyp och Socialstyrelsens specifikation

      • Fältet status = “Observerad förekomst” (hårdkodat) i Socialstyrelsens modell tolkar vi är mera till för att konfigurera SoS/NI-modellen Observation till det av modellerinsgsteknikens alternativ som ligger ungefär närmast vad UMI behöver. Vi behöver alltså inte nödvändigtvis mappa det till openEHR-arketypens fält “Status”-

      • Allvarlighetsgrad i Socialstyrelsens modell har ingen direkt motsvarighet i arketypens översta (generella) nivå men kan däremot mappas mot “Severity of reaction” där det finns 3 värden för den (Mild, Moderate, Severe). I arketypens översta nivå finns attributet Criticality (med värdena Low, High). → Vi skulle kunna skapa en utökning/specialicering? (Klurar på det nästa gång)

      • Det kan vara lämpligast att tända signalen utifrån de övre nivån i arketypen, inte utifrån “reaction event” (som snarare bildar historiken)

    • Diskussion kring till vilken grad vi behöver förhåller oss till Socialstyrelsens specifikation (Ann-Sofi: regioner anser att de måste följa specen, Rikard: specen är minimala grunden, ska följas men kan utökas)

2022-10-18 Möte

Deltagare

@Anette Larsson @Carina Sandell @Erik Sundvall @David Wetterbro @Emma Molin @Mikael Nyström @Claudia Ehrentraut

Anteckningar

2022-11-01 Möte

Deltagare

@Carina Sandell @Erik Sundvall @David Wetterbro @Anette Larsson @Anders Thurin @Claudia Ehrentraut@Rikard Lövström

Anteckningar

  • För att modellera UMI openEHR behöver ens personliga Archetype Designer-profil anslutas till repository:t . Detta görs genom att följa stegen nedan:

  • Under mötet började vi bygga vår modell utifrån hur norrmännen har gjort Clinical Knowledge Manager (arketyper.no), dvs.:

    • Börjar med att skapa en template utifrån health summary (kanske kommer ändras senare - gärna till någon arketyp av typen “persistent” istället för “event” - exempelvis )

    • Skapar sektioner (SECTION) utifrån huvudgrupperna i Socialstyrelsens informationsspecifikation för uppmärksamhetsinformation Uppmärksamhetsinformation - Socialstyrelsen (openEHRs SECTIONs är mest för läsbarheten, men kan påverka sökvägar i AQL frågor om man inte tänker sig för vid frågeformulerandet.)

    • Börjar med engelska versionen av health summary

      • engelska formuleringar utifrån

    • Kollar sedan om det finns en svensk översättning av health summary, genom att kolla på Clinical Knowledge Manager (openehr.org). Hittar den svenska översättningen för health summary som Elham hade påbörjat. Exportera den som ADL och importera den i arketypdesigner

    • Fortsätter sedan modellering på svenska

    • Lägger till arketypen adverse reaction risk under Överkänslighetssektionen

      • Intermediate saknas, anpassade alternativ under “criticality” till nedanstående, kommer behöva mappas till originalen low och high vid vissa sorters internationell användning:

        • 442452003 | livshotande |

        • 59021000052107 | skadlig |

        • 59031000052109 | besvärande |

 

2022-11-15 Möte

Deltagare

@Emma Molin @Ann-Sofi Avindell @Erik Sundvall @David Wetterbro @Carina Sandell @Claudia Ehrentraut Rikard Lövström

Anteckningar

  • Kort genomgång över vad vi gjorde senast

  • Attribut: criticality/allvarlighetsgrad Koder under (Criticality) mappar inte mot Socialstyrelsens urval för allvarlighetsgrad (besvärande, skadlig, livshotande): mellannivån skadlig saknas

    • Alternativ:

      • (1) Lägg till skadlig/mellan i urvalet under internal coding för attributet Criticality som del i en arketyp-specialisering (specilization)

        • Nackdel med (1): risk att internationella beslutsstöd eller forskningsstudier (via AQL etc) missar att den svenska mellan-nivån finns (de får sökträffar bara på höga och låga nivån)

      • (2) Skapa ett parallellt attribut med svensk variant av Criticality, dvs. Allvarlighetsgrad UMI som del i en arketyp-specialisering (specilization) och säg åt systemen att vid datalagring spara ner data i båda grenarna (mappa svenska mellan-nivån till internationella “hög”)

        • Nackdel med (2): i svensk journaldokumentation skulle det hamna två allvarlighetsgrader (dubbla attribut) i sparad journaldata vilket kan förvirra svenska användare vid läsning av journalinnehåll utan specialanpassat GUI som döljer den internationella “dubbellagrade” varianten.

      • (3 - vald f.n.) Använda sig av external coding i arketypen för attributet Criticality (Allvarlighetsgrad), där vi definierar Snomed-koderna enligt Socialstyrelsens spec (442452003 | livshotande |, 59021000052107 | skadlig | , 59031000052109 | besvärande |) så att dessa kan användas i templaten.

        • Nackdel: risk att internationella beslutsstöd eller forskningsstudier (via AQL etc) missar den svenska kodningen, men det borde upptäckas eftersom de inte får några träffar alls.

        • Konsekvens: vid mappning till internationell FHIR- eller openEHR-modell/API/tjänst utan stöd för mellan-nivå får man se till att mellan-nivån mappar upp till “hög”.

  • Attribut: category/kategori

    • Urval innehåller koderna mat, läkemedel och annat. Enligt UMI specen ska man enbart uppmärksamma för läkemedel (aktiv substans och kemikalier.

    • Alternativ

      • (1) Använd Medication för läkemedelsprodukt, hjälpämne i läkemedel och aktiv substans och Annat för Kemikalie. I templaten skulle man kunna förbjuda användningen av mat

        •  

      • (2 - vald f.n.) Gör en external koding med egna Snomed kategorier

        •  

    • Den nationella specifikationen från Socialstyrelsen stöder både markering av enskilda ämnen och hela (läkemedels)produkter. Variant 1 & 2 ovan gäller ämnen. I en template kan man köra alternativa grenar, t.ex. när man vill sätta olika strukturer eller tillåtna värden. Lägger vi till en parallell gren för produkter (utöver grenen för ämnen) så kan det bli såhär:

      Eftersom bara ett värde för kategori finns i produkt-grenen kan vi passa på att sätta det som default också. Det kan finnas fler skillnader mellan grenen för ämne respektive grenen för produkt, det kan vi undersöka vid nästa möte.

Att göra

Skapa svensk översättning av arketypen adverse reaction risk
Lobba för internationellt att medication förfinas
Lägg till aktiv substans, läkemedels i Snomed
Senare, skapa separat template (ej UMI) om födoämnesallergier, kanske som ett appendix eller separat kapitel i implementationsguiden

2022-11-29 Möte

Deltagare

@Ann-Sofi Avindell, @Claudia Ehrentraut, @Rikard Lövström, @Mikael Nyström, @Carina Sandell, @Erik Sundvall, @Anders Thurin och @David Wetterbro.

Anteckningar

  • Vi repeterade lite av vad som gjorts senaste gångerna för deltagare som inte varit med senaste gångerna.

  • Under tiden Erik var borta passade övriga på att se till att alla kan koppla ihop branchen där UMI-arbetet finns modellbibliotek/CKM-mirror at UMI-warning-info (github.com) med repositoryt som var och en behöver skapa i Archetype Designer, se uppdaterad skärmdump under mötesanteckningar för den 2022-12-01

  • Diskussion om prioriteringsordning av kategorier som man väljer att beskriva ämnet/produkten som orsakar reaktion. Ett gränssnitt bör kunna bygga på följande tågordning:

    • I första hand, om specifikt ämne (t.ex. aktiv substans eller hjälpämne) är känt, välj det ämnet. (Visa lista på NSL-id:er (Nationellt substansregister för läkemedel, NSL | Läkemedelsverket (lakemedelsverket.se)). Det kan i gränssnitt ges ett val mellan t.ex. aktiv substans kontra hjälpämne, som ger mer förfinade urval i listor)

    • I andra hand (om ämnet inte är känt) välj istället produkt så exakt som möjligt (Visa lista på NPL-id:er (Nationellt produktregister för läkemedel, NPL | Läkemedelsverket (lakemedelsverket.se))

    • I tredje hand (om produkt inte är känd) välj istället grupp/kategori av läkemedel baserat på ATC-kod (Visa lista på ATC-koder)

    • Beskrivning av gränssnittsfunktionen för växling mellan ovanstående kategorier/listor ligger sannolikt i formulärdefinitionen (alltså inte i själva templaten). I sparad data förväntar man sig dock att koden kommer ur det kodverk som hör till den kategori av ovanstående som man har valt

  • Diskussion kring att Överkänslighetstillstånd.tid i Socialstyrelsens informationsspecifikation för uppmärksamhetsinformation är otydligt, dvs. vad som menas med observerades (när patienten observerade tillståndet eller när hälso- och sjukvårdspersonalen observerade det?)

    •  

  • En del ändringar av svenska översättningen i arketypen föreslogs under mötet, vi ändrade rubriker i templaten som ett sätt att komma ihåg dem. (Gränssnittet i Archetype designer visar smidigt vad som ändrats). Todo: Vi behöver senare se till att uppdatera svenska översättningen av arketypenen Adverse reaction risk i CKM!

  • Det förslogs att Cambio testar att ladda in de aktuella kodverket (NSL, NPL, ATC) i sin terminologiserver och att vi testar att i Cambios formulärverktyg bygga ett dynamiskt formulär som beroende på t.ex. val av kategori ger möjlighet att välja/söka kod bara i vald kategori. Samma sak kan senare testas i andra leverantörers lösningar. Todo: Det är viktigt/värdefullt att vi i implementationsguiden dokumenterar vilken logik som förväntas av ett gränssnitt.

  • Versionsnumrering för template diskuterades. Innan templates börjar användas skarpt bör man ha ökat version till 1.0.0 eller högre och börja följa Semantic Versioning (semver.org) Så länge man håller sig på version 0.*.* så kan stora förändringar förekomma utan att “major”-version ändras. Se även Kapitel 4 om versionshantering i Archetype Identification (openehr.org)

Att göra

Dokumentera vilken logik som förväntas av ett gränssnitt.

 

2022-12-13 Möte

Deltagare

@Ann-Sofi Avindell, @Claudia Ehrentraut, @Rikard Lövström, @Mikael Nyström, @Carina Sandell, @Emma Molin

Anteckningar

  • Vi listar ut hur man skapar ny gren genom att clona en befintlig gren

  • Diskuterat användning av kategori

    • om kategorierna skulle uppdateras, t.ex. om födoämnen läggs till igen, så skulle man behöva lägga till en kategori för det interna kodverket, och därmed skapa en ny version av templaten.

  • Diskuterat Substance/Substans

    • Hur kan vi peka ut att vi vill kunna använda NSL-id:erna eller snomed-koder för substans, resp. NPL-id?

    • Kan man uttrycka substans utan att speca kategori?

    • hur kan man styra till rätt urval för substans utifrån den kategorin som man valde?

    • Ska vi verkligen ange NPL-id för läkemedelsprodukt under Substans? Ja, arketypen verkar enligt den engelska texten under comment tillåter läkemedelsprodukt (se skärmdump nedan) → Vi har uppdaterat Description för Substans under Biverkningsrisk (ämne/substans), resp. Biverkningsrisk (produkt) men information om att enbart substanser, resp. läkemedelsprodukter ska anges

      •  

    • Hur relaterar man substans mot angivelse av reaktionshändelse.Specifikt ämne?

      • Substans - obligatorisk, använd om man inte kan registrera någon specifik händelse

      • reaktionshändelse - inte obligatoriskt, använd Specifikt ämne om specifik händelse/flera händelser kan registreras

    • Vad är en substance class/ämnesklass som ska kunna anges under Substans? Syftar det åt ATC-grupper? Rikard tycker inte att det är en effektiv väg att bygga på någon logik kring ATC-koder

  • Förslag

    • Diskutera i början på nya året hur vi vill jobba vidare med UMI. Funkar det som vi jobbar idag eller bör vi göra på andra sättet?

  • Ha flera templates

    • en som är helt kompatibel med SoS men i övrigt väldigt tillåtande

    • en till template som ärver av ovanstående men som är begränsat exakt till det som SoS infospec kräver

Att göra

Svara på frågorna under anteckningar

 

2023-01-10 Möte

Deltagare

@Emma Molin @Ann-Sofi Avindell @Erik Sundvall@Mikael Nyström @Claudia Ehrentraut Rikard Lövström, Daniel Karlsson

Anteckningar

  • Liten sidodiskussion om negation och negativa fynd. Finns minst två olika behov kring detta:

    1. Att kunna “släcka” en tidigare “tänd” del av UMI

    2. Att (som i norrmännens template) aktivt kunna notera frånvaron av något (t.ex. en allergi

  • Daniel nämner fynd från tidigare UMI-diskussioner

    • Det behövs regler/regelspråk (inte bara dokumentationsmodell och terminologiurval) för att kunna göra bra UMI-stöd för saker som

      • Antikoagulantia - kvarstående behandlingseffekt 10 dagar efter behandlingsstopp

      • Leomycin ger livslång överkänslighet mot syrgas

  • Diskussion om vad vi tillför (utöver existerande tjänstekontrakt) genom att bara skapa templates etc för sekundärinformation. Främst möjligheten att spara detta på standardiserat sätt i CDR hos enskilda vårdgivare. Mer kliniskt intressant funktionellt tillskott blir snarare det som nedan beskrivs som sprint 2-3

  • Diskussion om att även bredare område än det som täcks av SoS UMI-spec är intressanta att journalföra på liknande sätt, t.ex. födoämnesallergi och mer info om smitta

  • Diskussion om länkning från sekundär- till primär-information

    • LINK i RM

    • Citation-arketypen

  • Diskuterat hur vi fortsätter arbetet:

    • Ha flera “sprintar”

      • Sprint #1 sekundär information

      • Sprint #2 primär information

      • Sprint #3 regler/algoritmer för att kunna gå från primär till sekundär information

    • Börja med Sprint #1 sekundär information

      • Dela upp arbetet i mindre bitar utifrån typer av uppmärksamhetsinformation Överkänslighet, Smitta, Särskild vårdrutin och Medicinsk tillstånd och behandlingar

      • Två grupper

        • Grupp 1: Smitta, Medicinsk tillstånd och behandlingar

          • Erik

          • Daniel

          • Ann-Sofi

          • Claudia - koordinator

          • Anders

          •  

        • Grupp 2: Överkänslighet (fortsätt med befintlig template), Särskild vårdrutin

          • Mikael

          • Emma - koordinator

          • Rikard

          • Carina

          • David

          • Anette

      • Varje grupp kommer fram till ett eget mötesschema under de närmaste två veckorna. Återrapport om 2 veckor, se schema på openEHR tisdageftermiddagsmöte

    • Notera att Daniel.Karlsson har ny epostadress @ehalsomyndigheten.se

    • UMI-spec nås nu även via NGS: Informationsspecifikation för uppmärksamhetsinformation - Version 5.1 | Nationella gemensamma specifikationer (ehalsomyndigheten.se)

 

2023-01-13 Möte (Grupp 2)

Deltagare

@Emma Molin @Mikael Nyström Rikard Lövström

Anteckningar

  • Vi slutförde template för Överkänslighet

    • Vi har lagt till kommentarer på vissa attribut för att förtydliga vad som gäller för det attributet eller om vi behöver diskutera det ytterligare.

    • Fundering kring ATC-koder - Finns det en svensk version med koder som inte finns i WHOs?

    • Mikael har tagit på sig att kolla upp hur vi kan terminologibinda för Substans.

    • Attributet Negation från SoS har lagts till under visshetsgrad genom att man anger koden för “Refuted”/”Vederlagt”.

    • Attributet “Visshetsgrad inkl Negation” kommer behöva byta namn men heter så nu för att man ska förstå vad den innehåller.

    • Vi kom fram till att attributet “Status” från SoS inte behöver finnas med och lagras då det alltid är detsamma. Detta är dock en regel som man behöver känna till vid behov.

  • Vi påbörjade template för Särskild vårdrutin

    • Diskussion kring vilken arketyp som ska användas. Vi landade i att Advance care directive borde kunna användas för alla koder i SoS:s två urval.

2023-01-17 Möte (Grupp 2)

Deltagare

@Emma Molin @Mikael Nyström Rikard Lövström @Carina Sandell @Anette Larsson

Anteckningar

Nu påbörjar vi arbete med särskild vårdrutin och har valt arketypen Advance care directive att utgå ifrån. Den finns inte på svenska [2023-01-23 lade upp kort om det i SWET-tavlan] och när de importerade den så försvann svenskafliken. Mikael tror att det gå att göra något åt detta via källkoden. [Grupp 1 gjorde “fusk-översättning”, se nanteckning från 2023-01-23 nedan].

Enligt Mikael kanske vi inte kan använda arketypen till allt vi önskar, det står explicit under misuse att den inte ska användas till de exempel vi tänkt.

Diskussion om vi ska använda två olika arketyper för detta, eller kanske skapa en egen. Vi hittar ingen som täcker båda behoven som redan finns. Advance care directive och Advance intervention desicions kompletterar varandra.

Haken att gå vidare med Advance intervention desicions är att det inte uttryckligen pekar på att även vårdpersonals beslut inkluderas under purpose.

Kommer directive från patienten och decisions från vården? Vi måste kunna lagra information från båda hållen.

Urval från SoS informationsspecifikation:

59881000052100 |urval särskilda vårdrutiner, uppmärksamhetsinformation|   

103491000052103 |urval särskilda vårdrutiner utifrån fattade beslut, uppmärksamhetsinformation|

60781000052105 |hotbild mot patient|

713670002 |deltar i klinisk läkemedelsprövning|

185923000 |patienten deltar i klinisk prövning|

699128009 |avböjt transfusion av blodprodukt|

60761000052104 |avböjt autolog blodtransfusion eller cell saver|

89666000 |hjärt-lungräddning|

78823007 |livsuppehållande behandling|

103735009 |palliativ vård|

133571000052106 |utfärdande av förskrivningsrestriktion|

306103005 |hänvisning till specifik vårdenhet|

 

Dokumentation

Beslut om Särskild vårdrutin

Fattat av: Patient/vårdpersonal/vårdpersonal från annan region/privat vårdgivare

Angående: Något av de 10 valen

Det enda scenario som inte tillåts är att patienten själv inte får besluta att 133571000052106 |utfärdande av förskrivningsrestriktion| inte längre ska gälla.

 

2023-01-16 Möte (Grupp 1)

Deltagare

@Erik Sundvall @Ann-Sofi Avindell @Anders Thurin @Claudia Ehrentraut

Anteckningar

  • Påbörjat arbete med Smitta

  • Diskuterat användning av koden “blodsmitta hos gravid”

    • Alternativ A: vill vi ha med modellering med denna kod från specen/tjänstekontraktet i vår openEHR modell? Verkar vara en unikt svensk Snomed-kod som har skapats i den svenska Snomed CT upplagan

      •  

    • Alternativ B: …eller vill man dela på informationen blodsmitta och graviditet (en precaution för vardera “blodsmitta” och “graviditet“ och sedan ha sammanslagningslogik när man måste skicka det via nuvarande tjänstekontrakt med beslutade koden “blodsmitta hos gravid” eller ska tända nationella symbolen).

      • Orsaker till att vid lagring av sekundärinformation vilja dela upp i graviditet respektive blodsmitta

        • Andra lokala varningssystem än UMI (och aktivering av beslutsregler) kommer ha intresse av både graviditet och blodsmitta oberoende av varandra

        • Det blir semantiskt tydligare/rimligare att släcka precaution för själva graviditeten (med hjälp av statusen “resolved”) när graviditeten upphör än att släcka “blodsmitta hos gravid”.

      • det finns snomedkod för “patienten är gravid för närvarande”, borde ligga under tillstånd, snarare än smitta

      • det finns snomedkod för “bärare av infektionssjukdom” med underliggande koder…

      • …men det verkar inte finnas någon uppenbar kod för blodsmitta i Snomed CT.

        • Fråga: borde det skapas en Snomed-kod för det? Anders påpekar att det inte är en allt för stor (uppräkningsbar) lista av sjukdomar som nästan enbart sprids genom blodblandning.

        • [Tanke efter mötet, från Erik: Ett urval för blodsmitta kunde vara intressant att skapa - om inte annat så kan det användas i de beslutsregler som ska användas för att trigga flaggning av blodsmitta.]

      • I Cosmic och TakeCare anges enbart information om blodsmitta i UMI-modulen, ingen närmare information om vilken typ av blodsmitta [Tillägg Claudia efter mötet: I TakeCare finns ett sökord för blodsmitta som är av typ fritext, huruvida mycket den används samt i vilka mallar är oklart]. Även Socialstyrelsen anser att information om att blodsmitta föreligger räcker för UMI, utan att närmare specificera vilken typ av UMI

        • Alltså behövs sannolikt i nuläget ingen mer specifik angivelse i sekundärinformationen för UMI än att det finns blodsmitta (utan att ange exakt vilken).

      • [tillägg Claudia efter mötet: Översikt - Vårdhandboken (vardhandboken.se) ger en översikt över blodburen smitta. Det finns en Snomed CT qualifier value 420014008 |blodburen överföring| som kanske kan vara intressant i kombination med 235871004 |bärare av hepatit B|, 235872006 |bärare av hepatit C|, resp. 699433000 |HIV-bärare (humant immunbristvirus)|

  • Kollat på Förslag på mappning UMI/OpenEHR • Cambio Healthcare Systems (mural.co) och Clinical Knowledge Manager (arketyper.no) för att se vilken arketyp/template Norge använde för att modellera smitta → Norge använder arketypen Evalutation.precaution.v1 - Precaution verkar lämplig för sådan “sekundärinformation” som vi nu försöker fånga.

  • Vi skapar en ny template för Smitta som heter “Contagion” - för närvarande lagrad i https://github.com/modellbibliotek/CKM-mirror/blob/UMI-warning-info/local/Contagion.t.json

    • vi börjar templaten utgående från arketypen Ad hoc heading

    • tanken är att denna ska ersätta Ad hoc heading “Contagion Smitta” i Medical Alert Information-templaten där överkänslighet finns

  • Diskussion om vi ska dela på smittsam sjukdom och smittämne eller om vi ska slå ihop dem

    • framtagna förslager delar på dem på samma sätt om Socialstyrelsen gjort eftersom vi gissar på att

      1. Det vid uppdateringar av Socialstyrelsens UMI-spec kan komma fler saker under respektive kategori

      2. Man kan vilja ha hjälp av uppdelningen när man bygger användargränssnitt, efterosm man kan vilja designa UI och formulera sig olika för de olika kategorierna

    • använd Precaution.condition för att hantera värde från i UMI infospecen, se nedan

    • använd statusar under Precaution.status för att hantera status och det som modelleras med negation i UMI infospecen, se nedan

    • Smittsam sjukdom - Contagious disease

      • Precaution.condition - sätt till Förekomst av smittsam sjukdom.värde, dvs. blodsmitta hos gravid (välj external coded, välj local terms) → Inte färdigutredd om det ska vara så

      • Precaution.status

        • active = Förekomst av smittsam sjukdom.status = observerad förekomst & Förekomst av smittsam sjukdom.negation = falsk

        • resolved = Förekomst av smittsam sjukdom.status = observerad förekomst & Förekomst av smittsam sjukdom.negation = sant (barnet är inte längre gravid)

        • refuted = Förekomst av smittsam sjukdom.status = observerad förekomst & Förekomst av smittsam sjukdom.negation = sant

      • Smittämne - Carrier

        • Precaution.condition - sätt till Förekomst av smittämne.värde, t.ex. MRSA (välj local terms, använd Snomed-koder för smittämnen i sekundär dokumentationen, ICD-10 koder kan vara relevanta för att hämta information från primär dokumentation)

        • Precaution.status

          • active = Förekomst av smittsam sjukdom.status = observerad förekomst & Förekomst av smittsam sjukdom.negation = falsk

          • resolved = Förekomst av smittsam sjukdom.status = observerad förekomst & Förekomst av smittsam sjukdom.negation = sant (barnet är inte längre gravid)

          • refuted = Förekomst av smittsam sjukdom.status = observerad förekomst & Förekomst av smittsam sjukdom.negation = sant

 

2023-01-18 Möte (Grupp 1)

Deltagare

@Erik Sundvall @Anders Thurin @Claudia Ehrentraut

Anteckningar

  • Frågor till grupp 2

    • Vilket alternativ (A eller B), se anteckning från grupp ovanför, gällande Smitta är att föredra?

    • Vad är syfte för openEHR-modelleringen av sekundärinformationen?

      • Är den bara till för att tända det som specificeras i nuvarande version av SoS UMI-signal?

      • Är den också till för att hitta nationellt gemensamma sätt att journalföra en del annan uppmärksamhets-relaterad sekundärinformation? (T.ex. generell flagga för pågående graviditet?)

  • Diskuterat länkningsalternativ till journalanteckning med bakomliggande info

    • Alternativ 1 Använda Precaution.data.evidence för att länka till journalanteckningen som ligger till grunden för att man har angett smittan, under Rm.Attributes listas LINK (från RM) som möjlighet

    • Alternativ 2 Använda arketypen CLUSTER.citation.v0 - lägger till under Precaution.protocol.extension → Citation-arketypen behöver översättas till svenska

  • Fortsatt på Smitta

    • Använd Precaution.protocol.Valid period start sätts till det tidpunktet då smittämnet/smittsamma sjukdomen observarades . Ha kvar Valid period end, som kan sättas när man ändrar status till resolved eller refuted. Behåller övriga datum

    • Länkat in vår template Contagion i template Medical Alert Information

  • Påbörjat Medicinska tillstånd och behandlingar

    • Skapat ny template Conditions and treatments

    • Kollat i Clinical Knowledge Manager (arketyper.no) EVALUTATION.precaution.v1 och EVALUTATION.problem_diagnosis.v1

    • Finns även arketypen

      • EVALUTATION.Medical device summary.v0

      • CLUSTER.Medical device

 

2023-01-20 Möte (Grupp 1)

Deltagare

@Erik Sundvall @Claudia Ehrentraut @Daniel Karlsson @Ann-Sofi Avindell

Anteckningar

  • Fortsätter med Medicinska tillstånd och behandlingar

    • Annat medicinskt tillstånd

      • är vissa av de tillstånd som listas under andra medicinska tillstånd övergående

      • EVALUTATION.problem_diagnosis.v1 - under status finns möjlighet att använda problem diagnosis qualifier-arketypen som innehåller current/past eller aktive/inaktive som skulle kunna användas för att indikera att tillståndet inte längre är aktuellt

      • modellera arketyper EVALUTATION.problem_diagnosis.v1

    • Behandling

      • modellera två alternativ utifrån precaution (som norrmännen) och procedure arketyperna

  • Diskussion

    • Kort diskussion hur vi ska hantera de fallen där det finns ICD-10 och Snomed CT koder? Tanken är att använda Snomed-koder för sekundärinformation men ICD-10 kan användas för primärinformation

    • Diskuterar blodsmitta → Daniel kollar om man kan lägga till blodsmitta, kan vara svårt då det inte bara är blod men även slemhinnor

  • Frågor till grupp 2

    • Hur ska vi hantera statusar och tid, t.ex. när man vill släcka information?

    • ska vi ha med kommentarer eller inte?

    • hur ska vi göra med pekning till primärinformationen?

 

 

2023-01-23 Möte (Grupp 1)

Deltagare

@Erik Sundvall @Claudia Ehrentraut @Anders Thurin

Anteckningar

  • Överkänslighet

    • Arbetet för Överkänslighet som gjordes på svenska syns inte längre eftersom att i en annan del av templaten så har arketypen för Särskild vårdrutin, dvs. Advance care directive, lagts till och den saknade svensk översättning. Vi lade nu till en svensk “fusk”-översättning för arketypen, d.v.s. i Archetype Designer lade vi till svenska som möjligt språk utan att genomföra faktisk översättning, då blir fältnamnen i stil med “* Fieldname (en)”.
      Efter det kom den svenska översättningen för Överkänslighet tillbaka, dock enbart Biverkninsrisk (ämne/substans).
      Biverkningsrisk (produkt) enligt anteckningen (och tillhörande screenshots) från den 2022-11-15 hade fallit bort. Vi återställde indelningen enligt hur den är specat i 2022-11-15. Uppdaterade även kommentarer för substans under Biverkninsrisk (ämne/substans) och Biverkningsrisk (produkt)

    •  

  • Fortsätter med Medicinska tillstånd och behandlingar

    • Behandling

      • Behöver kunna ange läkemedelsprodukt eller aktiv substans (med NSL-id eller ATC kod) för läkemedelsbehandling

      • Arketypen Medication details skulle kunna användas för det.

      • Lite oklart vilket läkemedel som ska anges

      • Skapar två alternativ

        • Alternativ 1

          • 1a) arketyp Precaution för de behandlingar som ligger under Uppmärksamhetsinformation Behandling (1.2.752.116.3.1.16.1.2)

            • Precaution.condition = typ av behandling

            • Precaution.status = status för behandling

            • Precaution.evidence = pekar till primärdata

          • 1b) arketyp Precaution och Medication details under Treatment.protocol.extension för läkemedelsbehandling

        • Alternativ 2

          • 2 a) arketyp Procedure för de behandlingar som ligger under Uppmärksamhetsinformation Behandling (1.2.752.116.3.1.16.1.2)

          • 2 b) arketyp Medication management för läkemedelsbehandling

          • To do: Om dessa ACTION-baserade arketyper ska användas så behöver vi avgöra vilka statusar av de som finns i arketypen som är relevanta i sekundärdokumentation, vi har börjat med att plocka bort några som vi inte anser vara relevanta för att tända uppmärksamhetssignal

        • Att blanda (potentiellt sinsemellan osynkade) terminologisystem i vallistor för samma begrepp på template-nivå brukar inte rekommenderas i openEHR-sammanhang (förekommer dock i FHIR)

        • Alternativ 3 - en variation av alternativ 1 där vi jämkat ihop SoS olika modelleringstekniker till två konsekventa grenar - sannolikt lättast med prec:

          • 3a - ett templateavsnitt för läkemedelsbehandlingar, endast ATC-kodad baserade på en och med “användarvänliga” etiketter baserade på en koombination av Kolumn A i SoS spec och ATC-namn. Se tabell nedan.

          • 3b - ett annat templateavsnitt för övriga behandlingar, Snomed CT-kodade. Se tabell nedan.

        • Alternativ 4 - specialiserad terminologibunden precaution-arketyp med lokala/interna “at”-koder som därmed är defining_code på arketypnivå och kan mappas (samtidigt) till flera olika terminologier (ATC, ICD-10, Snomed CT) - vill man då ha med de externa terminologikoderna i journaladata så får man nyttja “mappings”, se .t.ex. Ians inlägg, #3 i

        •  

Tabell till förslag 3a:

ATC-kod/grupp

Namn i template (förslag)

Kommentar

 

ATC-kod/grupp

Namn i template (förslag)

Kommentar

 

B01A

Antikoagulantiabehandling

Skall ej användas för nyregistrering, finns för att tillåta gammal data som var grövre indelad i tidigare version av nationell specifikation

 

B01AA

Antikoagulantiabehandling, Vitamin K-antagonister 

 

 

B01AA03

Antikoagulantiabehandling, Warfarin 

Medicinsk fråga skiljer sig Warfarin från andra Vitamin K-antagonister i varningssammanhang? (Typ längd på kvarvarande effekt eller något?)
Besvarad: Det skiljer sig ej, kan slås ihop med “Vitamin K-antagonister” och läkemedelsnamn anges i annat fält.

 

B01AB

Antikoagulantiabehandling, Heparingruppen

 

 

B01AE

Antikoagulantiabehandling,  Direkt trombinhämmande medel

 

 

B01AF

Antikoagulantiabehandling, Direktverkande faktor Xa-hämmare

 

 

L01

Cytostatikabehandling

(Enl ATC Antineoplastiska medel) Ok att avvika från ATC-namn för att öka förståelse? Besvarad: JA

 

L03A

Immunstimulerande behandling

Ok att dela upp dessa (från specens immunomodulerande) så att man kan skilja på grenarna i ATC när man gör gränssnittslogik?

 

L04

Immunsuppressiv behandling

 

[Väljs dynamiskt av formulärlogik?]

Läkemedelsbehandling ÖVRIG??

Behövs den möjligheten för nationell SoS-specad uppmärksamhetssignal? Eller bara för annan bredare template?

 

Tabell till förslag 3b:

Snomed CT-kod

Namn i template (förslag)

Kommentar

 

Snomed CT-kod

Namn i template (förslag)

Kommentar

 

243142003

BiPAP-behandling

Medicinsk fråga:
Har SoS spec verkligen täckt allt relevant inom “Beroende av icke-invasiv ventilation“ med hjälp av Snomed-koden 243142003 |BiPAP-behandling|? Är CPAP, syrgastillförsel m.m. irrelevant? Vore inte alla koder under 152921000119101 | Dependence on respiratory device (finding) | relevanta om vårdpersonal har bedömt att de ska med i uppmärksamhetsinfo för den enskilda patienten. T.ex. så har väl många KOL-patienter syrgaskoncentratorer hemma utan att ha BiPAP.

Besvarad: det är inte syrebrist som är problemet utan motsatsen - BiPAP-patienter kan inte ges syrgas på normal/rutinmässigt sätt, de kan hamna i kolsyrenarkos etc då.

 

385971003

dialysbehandling

 

 

2023-01-24 Möte

Deltagare

@Erik Sundvall@Anders Thurin @David Wetterbro @Rikard Lövström @Claudia Ehrentraut

Agenda

  • Vill vi ha hjälp av B3 för att översätta/uppdatera befintliga översättningar av de arketyper som vi har identifierat?

  • Respektive grupp presenterar sitt arbete

  • Lägg till arketyper som behöver översättas i Agil-anslagstavla - openEHR JIRA (atlassian.net)

 

Anteckningar

  • Status grupparbete

    • Grupp 1 har inte blivit klart med alla delar under medicinska tillstånd och behandlingar. Det bestämdes på mötet att gruppen har 1-2 egna möten inför nästa gemensamma möte. Fritt fram för andra att vara med om så önskas.

    • Grupp 2 känner att de har kommit så långt de kunde och är klara för att presentera och diskutera sitt arbete för hela gruppen

  • Respektive grupp presenterar sitt arbete

    • Kommer överens att vi kör en presentationsrunda av vad arbetsgrupper har kommit fram till när flera är med, dvs. förhoppningsvis mötet om 2 veckor.

  • Går genom frågor från grupp 1

    • Vilket alternativ (A eller B), se anteckning 2023-01-16 (grupp 1) ovanför, gällande Smitta är att föredra?

      • För denna modellering av sekundärinformation med syfte att tända UMI, kör alternativ A. Konsekvans: “resolved” gäller då hela kombinationen blodsmitta hos gravid

      • Detta hindrar inte att vi i nationella samarbetet (senare) även tar fram modeller (t.ex. en bredare template) med mer generellt syfte och gör olika “precaution” för blodsmita respektive graviditet.

    • Vad är syfte för openEHR-modelleringen av sekundärinformationen? Är den bara till för att tända det som specificeras i nuvarande version av SoS UMI-signal? Är den också till för att hitta nationellt gemensamma sätt att journalföra en del annan uppmärksamhets-relaterad sekundärinformation? (T.ex. generell flagga för pågående graviditet?). Beslut:

      • börja med att ha SoS UMI-signal som scope

      • i ett nästa steg kolla på möjlighet att modellera annan uppmärksamhets-relaterad sekundärinformation, t.ex. graviditet och uppmärksamhetsinformation som inte anses som sådan längre enligt senaste version av SoS spec (t.ex. födoämnen). Ha flera ‘lager’ av sekundärinformation där det är lämpligt?

    • Hur ska vi hantera statusar och tid, t.ex. när man vill släcka information?

      • Ha tid för onset men statusar för att släcka? Vi ändrade i grenen “other medical condidion” i (sub)templaten “Condidions and treatments”:

    • ska vi ha med fält för kommentarer eller inte? (De finns ofta i journalsystemen.) → hanns inte med

    • hur ska vi göra med pekning till primärinformationen? → hanns inte med

  • Ny fråga: ska vi (som norrmännen) fortsätta använda problem/diagnosis för medicinska tillstånd. Eller ska vi använda precaution-arketypen för detta UMI-sekundär-data-ändamål när vi ändå har tagit bort det mesta ur “Problem/Diagnosis”?

  • Vill vi ha hjälp av B3 för att översätta/uppdatera befintliga översättningar av de arketyper som vi har identifierat? → hanns inte med

  • Lägg till arketyper som behöver översättas i Agil-anslagstavla - openEHR JIRA (atlassian.net) → hanns inte med

 

2023-02-02 Möte (Grupp 1+RL)

Deltagare

@Rikard Lövström @Daniel Karlsson @Erik Sundvall

Anteckningargenda

  • För behandling:

    • Alternativ 3a+3b (som var en variant på “Precaution”-baserade 1a+1b ) valdes som lämpliga för sekundärinformation. Övriga modelleringsvarianter (2a+2b = Instruction+Action) rensades bort ur template. Terminologiurval för behandlingar och läkemedelsbehandlingar lades in i templaten och sparades (se exempel nedan). Terminologiurval för läkemedelsdetaljer bör komma ur terminologiserver (för många för att rymmas bra inbakade template).

  • Vi kom fram till att ett fjärde generellt projekt-steg kan behöva modelleras (efter tidigare identiferade 1. Sekundärinfo, 2. primärinfo & 3.beslutsregler primär--> sekundär), nämligen 4. regler för hur man tänder signal om det finns en kombination av information från det lokala systemet och info från nationella API/tjänstekontrakt. Kan vara extra klurigt vad gäller att våga “släcka” signaldelar när det t.ex. kan vara en kombination av läkemedel i en grupp (t.ex cytostatika) och man får extern info om att något upphört.

2023-02-07 Möte

Inställt.

2023-02-21 Möte

Deltagare

@Emma Molin @Erik Sundvall @Mikael Nyström @David Wetterbro @Carina Sandell @Rikard Lövström @Claudia Ehrentraut

Agenda

  • Presentera det vi har gjort i respektive grupp

  • Gå genom resterande/nya frågor

    • ska vi ha med kommentarer eller inte?

    • hur ska vi göra med pekning till primärinformationen?

    • ska vi använder problem/diagnosis för medicinska tillstånd. Eller ska vi använda precaution-arketypen

  • Vill vi ha hjälp av B3 för att översätta/uppdatera befintliga översättningar av de arketyper som vi har identifierat? Lägg till arketyper som behöver översättas i Agil-anslagstavla - openEHR JIRA (atlassian.net)

 

Anteckningar

  • Presentera det vi har gjort i respektive grupp

    • grupp 2

      • tog bort adverse reaction risk (produkt) medvetet för att de ansåg att kategori avgör om det är ett produkt eller inte (grupp 1 hade lagt till det igen felaktigt) → bör tas bort igen

      • lite fundersamt vilken arketyp som ska användas men kom fram till att advance care directive skulle kunna fungera

    • grupp 1

      • dela på blodsmitta och gravid eller inte, förmodligen landa i att inte dela → behöver ändra urvalet för Smittsam sjukdom till blodsmitta hos gravid

      • ska vi dela på smittämne och smittsam sjukdom

      • behandling, frågan om avbruten och utförd behövs separat eller ska man klumpa ihop dem.?

      • rätta behandling (ej läkemedel) giltlig till giltig

      • nu används ATC-koder under tillstånd för att uttrycka behandlingar, fast att ATC-koder i sig inte representerar behandlingar

        • vi skulle hellre vilja använda snomedkoder för behandlingar, men det finns inte för alla i 2022-6-8059-kodverkslista.xlsx (live.com)

        • i en tidigare version av kodverkslistan fanns Snomedkoder för fler behandlingar, se nedan

        • utifrån vilket perspektiv ska vi se på information? vad ska den användas till hur detaljerad ska den vara?

        • för användaren bör det enligt Rikard räcka om användaren ser en kombination av kolumn A och E, dvs det räcker att se information om att det är en antikoagulantiabehandling och vilken typ av ATC kod som ligger det grunden

        • slå ihop Behandling och Läkemedelsbehandling och lägg till Snomedkod för läkemedelsbehandling under Behandling.tillstånd

        • om man kan särskilja på hög- och lågdos för cytostatikabehandlingar så skulle det räcka att enbart uppmärksamma högdos cytostatikabehandlingar, se vetenskaplig referens Rikard

        • skapa en specialiserad arketyp?

          • @Erik Sundvall eller @Mikael Nyström kompletterar med hur denna skulle se ut

    • övriga kommentarer under presentationen

      • kommentar - Cambio ska inte längre ha med kommentar

 

Att göra

@Erik Sundvall fortsätter lite med att slå ihop Behandling och Läkemedelsbehandling
Grupp 2 försöker får till ett extra möte innan nästa gemensamma möte

 

 

2023-02-24 Möte grupp 2

Närvarande: @Carina Sandell @Emma Molin @Rikard Lövström

Beslut

  • Från patient

  • Från vårdpersonal 

Resonemang: Kan man tillåta två urval?

Behöver de skiljas åt eller vara på samma ställe?

 

Patientens beslut/vilja:

185923000 | patienten deltar i klinisk prövning

|699128009 |avböjt transfusion av blodprodukt

|60761000052104 |avböjt autolog blodtransfusion eller cell saver

 

Vårdpersonalens beslut:

60781000052105 |hotbild mot patient|

713670002 |deltar i klinisk läkemedelsprövning|

185923000 | patienten deltar i klinisk prövning|

89666000 |hjärt-lungräddning|

78823007 |livsuppehållande behandling|

103735009 |palliativ vård|

133571000052106 |utfärdande av förskrivningsrestriktion|

306103005 |hänvisning till specifik vårdenhet|

 

Begreppen i urvalet är inte alltid tydligt formulerade.

Vi skulle kunna anmärka att detta inte räcker som information om beslut, men vi kommer inte vidare mot SoS.

Vi tar istället de tio begreppen så att de passar in i templates.

 

Kandidat: Advanced care directive

I advanced care directive finns start och end time.

Finns inget passande attribut för negation men kan kontrolleras genom att ha start och end time. Om end time är närvarande så ska beslutet ses som att det upphört.

Denna arketyp kan vi använda för vissa av alternativen i urvalet - den har en självklar plats och återspeglar hjärt- lungräddning.

Kan även användas för livsuppehållande behandling, men den är bara möjlig att använda för livräddande åtgärder.

Men vi behöver ha lösning för de kvarvarande alternativen.

 

Ny kandidat: Precaution

Förslag från Rickard att kalla den för "Försiktighetsmått".

Vi har en hypotes om att vi kan få in alla koderna ovan i denna arketyp och har nu modellerat detta. Vi föredrar att vi kan få in allt i en och samma arketyp för särskild vårdrutin.

 

Beskrivning hamnar under Kommentar.

 Resonemang om Status

Active - Bifall - JA

Refuted - Ej Bifall - NEJ

Vi tar bort Resolved

 

2023-03-07 Möte

Deltagare

@Emma Molin @David Wetterbro @Daniel Karlsson @Rikard Lövström @Rikard Lövström

Anteckningar

  • Diskussion om huruvida precaution-arketypen kan användas för att dokumentera särskilda vårdrutin, främst utifrån vad som står i MISUSE för arketypen.

    • Resonemang: Vårt syfte med användningen av arketypen är att uppmärksamma att exempelvis ett beslut om att inte genomföra hjärt- och lungräddning finns och inte att primärdokumentera detta beslut så kan vi besluta just nu att det är ok att använda denna arketyp.

    • Diskuterat vidare att Advance intervention decisions

  • Måste bli tydligt i implementationsguiden att status aktiv och refuted innebär att signalen ska vara tänd eller släckt

  • Resonerat att vi kör på att använda Precaution för alla typer av uppmärksamhetsinformation, förutom överkänslighet

Att göra

2023-03-21 Möte

Deltagare

@Carina Sandell @Mikael Nyström @Erik Sundvall @Rikard Lövström @Claudia Ehrentraut

Agenda

  • förankra resonemang om att använda precaution med övriga i gruppen

    • medhåll från närvarande att använda precaution, resonemang

      • arketypen kan användas i det syftet

      • lättare för utvecklare att enbart använda två arketyper

      • fördel med att använda problem/diagnosis enbart i sitt tilltänkta sammanhang

  • fatta/slå fast beslut i ett antal frågor, se förslag nedan

  • se över användningen av status, tidpunkter, evidence/citation och comment när precaution används för de olika typer av uppmärksamhetsinformation.

    • Status

      • I UMI-specen

        • status = observerad förekomst & negation = sant/falskt (Smittsam sjukdom, Smittämne, Överkänslighet, Information som kan leda till särskild vårdrutin, Annat medicinskt tillstånd, Förekomst av implantat, förekomst av transplantat)

        • bifall = sant/falskt (Beslut som kan leda till särskild vårdrutin)

        • status = pågående, utförd, avbruten (Behandling)

        • status = utförd (Implantation, Transplantation, Avlägsnande av implantat)

      • Precaution-arketyp

        • Active [The precaution is currently active.]

        • Resolved [The previously asserted precaution has been clinically reassessed and considered no longer to be an active risk.]

        • Refuted [The precaution has been clinically reassessed or has been disproved with a high level of clinical certainty by testing.]

      • Förslag

        • observerad förekomst & negation = sant → Resolved/Refuted

        • observerad förekomst & negation = falskt→ Active

    • Evidence

      • Förslag: Länk till journalanteckning?

    • Category

    • Comment

Anteckningar

  • förankra resonemang om att använda precaution med övriga i gruppen

    • medhåll från närvarande att använda precaution, resonemang

      • arketypen kan användas i det syftet

      • lättare för utvecklare att enbart använda två arketyper

      • fördel med att använda problem/diagnosis enbart i sitt tilltänkta sammanhang

  • fatta/slå fast beslut i ett antal frågor, se förslag nedan

    • se beslut nedan

  • se över användningen av status, tidpunkter, evidence/citation och comment när precaution används för de olika typer av uppmärksamhetsinformation.

    • Category

      • Beslut: Behövs ej, släck → uppdaterat template utifrån det

    • Comment

      • Beslut: Släck → uppdaterat template utifrån det

        • finns inte i SoS spec

        • vi vill länka till primärdokumentation

        • även tjänstekontraktet (GAI 3.0) ska förmodligen ändras till att kunna hantera referenser istället för kommentarer, se information från Thomas Siltberg kring kontraktet från den 2023-03-13: “Möjligheten att referera till andra journalposter kommer troligtvis införas vilket ger möjligheten att referera till en journaldokumentation i stället för att inkludera en kommentar.”

 

Att göra

2023-04-04 Möte

Deltagare

@Carina Sandell @Rikard Lövström @Claudia Ehrentraut @Emma Molin @Thérèse Högberg Mårder @Erik Sundvall

Anteckningar

  • Kan vi testa vår template på något sätt? Vi kan använda Cambios CKM och formulär i visningsläge för att kunna se om vi kan hitta några eventuella problem. Efter att ha skapat lite data för testpatienter så skulle vi kunna kolla på hur vi skulle kunna hämta upp informationen för att tända UMI-signalen. @Emma Molin kollar upp detta och förbereder.

  • Evidence/citation

    • Se alternativ beskrivna i mötesanteckningar 2023-01-18.

    • Att kunna länka till journalanteckningen, primärdokumentationen.

    • LINK-attributet kan innehålla en lista med objekt av klassen LINK som endast kan peka inom en openEHR kontext.

    • I citation kan man peka på vilken url som helst.

    • Vi plockar bort Evidence nu i ett första skede (då det inte finns med i Socialstyrelsens spec) för att kunna testa minsta möjliga.

    • Längre fram kommer vi behöva länkar till primärdokumentationen. Inget beslut har tagits huruvida vi kommer använda evidence eller citation.

  • Vi borde bjuda in Thomas Siltberg i framtiden för att kunna diskutera tankar kring Ineras tjänstekontrakt och länkar.

  • Status - Förslag:

    • observerad förekomst & negation = sant → Resolved/Refuted

    • observerad förekomst & negation = falskt→ Active

    • Men det är oklart hur vi ska göra om pilarna går åt andra hållet. Resolved är mer passande för ändamålet. Behöver kollas på.

 

2023-05-02 Möte

Deltagare

@Rikard Lövström @Claudia Ehrentraut @Thérèse Högberg Mårder @Erik Sundvall @Daniel Karlsson

Anteckningar

  • Emma är inte med, kollar med henne nästa gång kring att testa templaten i Cambios miljö

  • Bjud in Thomas Siltberg för att diskutera kommentarer och länkning till grunddokumentation

  • Scope-diskussion

    • Tar vi fram templaten enbart för att fungera inom openEHR-system eller ska vi hantera scenariot?

    • Ska vi enbart utgå ifrån Socialstyrelsens

  • Vägvalsdiskussion

    • Ska vi i nästa steg ta fram ett utökat scope - vad skulle vi då vilja komplettera med? Eller ska vi börja titta på hur vi kan hämta nuvarande UMI ifrån primärdokumentation?

    • Ingen tydlig preferens mot det ena eller andra

    • Började diskutera utökat scope

      • Vad avser ett utökat scope?

        • strukturera information som ofta kan påverka en process eller bedömning?

        • viktig medicinsk information?

        • information som “folk” förväntar sig ska finnas?

        • Beslut: ta med information i ett utökat scope som i den senaste version av UMI har fallit bort (har varit med tidigare i SoS specifikation för UMI), då man inte kunnat ställa sig bakom dem juridiskt på nationell nivå och därmed har inte Socialstyrelsen tagit med dem

          • Födoämnen

          • Andra former av smitta: hepatit, hiv, kroniska bärare av salmonella

          • våldsam patient

 

Att göra

 

2023-05-09 Extramöte

Deltagare

@Rikard Lövström @Claudia Ehrentraut @Anders Thurin

Anteckningar

  • Medicinska tillstånd och behandlingar

    • Urval under Annat medicinskt tillstånd - använd EVALUTATION.problem_diagnosis.v1

      • Funderingar kring hur man bör dokumentera AV-fistel, spelar lokalisation och lateralitet roll? Åtgärd: anlagt fistel. Påbörjad dialysbehandling

      • Funderingar kring granularitet för koagulationsrubbningar, påverkar refset och termbindning

    • Behandling - skulle vi kunna använda medication order arketypen? Diskuterade även medication management.

 

2023-05-11 Extramöte

Deltagare

@Rikard Lövström@Thérèse Högberg Mårder @Claudia Ehrentraut

Anteckningar

Att göra

  • fortsätta med övriga informationsmängder i UMI

2023-05-16 Möte

Deltagare

@Erik Sundvall @Rikard Lövström (kortare tid) @Daniel Karlsson (kortare tid) @Claudia Ehrentraut Thomas Siltberg (Inera)

Agenda

  • Thomas Siltberg är med för att prata om tjänstekontraktet

  • Prata om Rikards mejl

  • Beslut på extramötet: använd av icd-10 koder och kvåkoder vs. snomed ct

Anteckningar

  • Synk kring tjänstekontrakt

    • Inera tänkte ta fram en utkast där de beskriver hur referenser ska funka - inte påbörjat

      • Referensinformation

        • namnrymd för tjänstekontraktet (uri, som förmodligen kommer vara icke-resolvable)

        • version av tjänstekontraktet

        • id till objektet, t.ex. till specifik journalanteckning

      • Kommer läggas till i ‘generella delen av kontraktet’, fler referenser möjliga kontraktet

      • Idag görs referenser på olika sätt i olika tjänstekontraktet, se ReferredInformationType i rivta-domains / riv.clinicalprocess.activity.actions / schemas / core_components / clinicalprocess_activity_actions_1.2.xsd — Bitbucket för hur det görs i GetActivity-kontraktet v 1.2

      • Diskuterar frågan om referensen bör representeras som en URI? Önskemål från openEHR Sverige:

        • ensträngs-URI

        • ha en URI som är resolvable

    • Planeras komma i version 3.0 av kontraktet, men skulle kunna komma i en minoruppdatering av version 2.0

    • Något som verkar ställa till det är att vissa tjänsteproducenter inte producerar persistenta id:en för objekten

    • Kommentar

      • Finns inga planer på Inera att lägga till kommentar

      • Oklar användning av kommentar

        • Skulle man kunna ta ut statisk kring det.

      • Skulle man kunna tänka sig att ett system sammanställer information

Att göra

  • Thomas återkommer med utkastet på hur referensinformation ska hanteras när Inera har kommit längre i arbetet.

 

2023-05-30 Möte

Deltagare

@Rikard Lövström @Mikael Nyström @Claudia Ehrentraut

Agenda

  • Prata om Rikards mejl

  • Beslut på extramötet: använd av icd-10 koder och kvåkoder vs. snomed ct

  • fortsätta med övriga informationsmängder i UMI

Anteckningar

  • Finns flera sätt att primärdokumentera, ska vi fånga alla alternativ? Bör kanske nöja oss med att enbart peka ut de vanligaste i vårt arbete

  • Diskutera att paketera sekundärdokumentation och ha en bilaga

 

Att göra

  • Claudia börjar skriver ihop implementation guide för sekundärinformation, skickar ut utkast till alla

 

Beslut

Beslut som har fattats av projektgruppen 2023-03-21:

  1. Skapa en första template som realiserar Socialstyrelsens informationsspecifikation version 5.1, ta hänsyn till kommentar och länkning till grunddokumentation
  2. Använd arketypen Adverse reaction risk för Överkänslighet för sekundärdokumentation
  3. Använd arketypen Precaution för Smitta, Medicinska tillstånd och behandlingar och Särskild vårdrutin för sekundärdokumentation

 

 

 

 

 

 

Övrig information

 

Rikards mejl

Hej!

Jag fick ju i uppdrag att titta närmare på det som närapå skulle kunna vara uppmärksamhetsinformation men åtminstone inte exakt nu finns inkluderat i informationsspecifikationen på Socialstyrelsen.

 

Jag skickar denna avrapportering till er som var med och diskuterade frågan på mötet, så jag tänkte att vi kunde ta upp frågan på ett kommande möte för att resonera kring vad av detta som eventuellt ska adderas till våra minnesanteckningar.

Kandidater till att inkluderas i uppmärksamhetsinformation:

  1. Bärare av smittsam sjukdom

Det skulle potentiellt kunna vara "blodsmitta" inklusive bärare av HIV, hepatit B eller hepatit C.

  

Potentiellt övergripande Snomed CT-begrepp:

66598005 |bärare av infektionssjukdom|

I praktiken har det avgränsats till
64301000052105 |blodsmitta hos gravid|

eftersom det där bedömdes att en smitta hos den ena delen av den gravidas kropp kan spridas till en annan del (fostret) om man inte tillämpar åtgärder för att minska den risken.

  1. Hotbild

Här var det länge en diskussion åt båda håll, både om patienten hade uttalat hot (vilket torde dokumenteras som finding i journalen under alla omständigheter, till exempel med begreppet 284614009 |hotfullt beteende|) eller om det finns uttalade hot mot patienten. Det har funnits ett resonemang om att det tidigare inte leder till någon fördel för patienten och att patienter ska hanteras med lika "lågaffektivt beteende" från vården oavsett patientens problematik.

Därför har man hittills valt att inte lyfta upp denna dokumentation som uppmärksamhetsinformation utan stannat vid situationen då det finns en hotbild riktad mot patienten, 60781000052105 |hotbild mot patient|

  1. Födoämnesöverkänslighet

Den nationella referensgruppen valde vid något av sina årliga möten (kan det ha varit maj 2020? Eller möjligen 2019??) att exkludera födoämnesöverkänslighet från Socialstyrelsens specifikation av uppmärksamhetsinformation.

Det fanns ett tag ett kvarstående uppdrag att skapa en struktur för denna dokumentation ändå, och det skapades till och med Snomed CT-urval 69091000052104 |urval agens överkänslighet mot födoämnen| som dock inte är fyllt med några begrepp. En arbetsversion av en uppräkning i Excel bifogas. Jag är osäker på om det är den senaste versionen som ens jag har (jag vet att vi har tittat på uppdelningen av födoämnen i detalj senare än detta underlag producerades) men det var den version jag kunde hitta i nuläget.

 

I nuläget känner jag inte till diskussionen om uppmärksamhetsinformation på Socialstyrelsen och det finns heller inte kvar några av de tidigare diskussionsunderlagen på Socialstyrelsens hemsida.

En liten kommentar om viktiga medicinska data (VMD) är att det inte riktigt fick fäste i de förberedande diskussionerna. Främsta motiveringen var nog att det skulle vara svårt att avgränsa VMD mot annan journalinformation, betydligt svårare än uppmärksamhetsinformation.

Det fanns också tankar om att situationsanpassa uppmärksamhetsinformation så att ett filter med relevant information för situationerna: läkemedelsordination, intubation, matservering, hjärt-lungräddning, akut omhändertagande osv. Dock blev det nedröstat av referensgruppen på grund av huvudsakligen två skäl: det ena att det var svårt att närma sig ett standardiserat urval situationer, det andra att det var svårt att säga att inte all uppmärksamhetsinformation ändå skulle vara relevant att visa upp i varje sådan föreslagen situation.

Det finns säkert fler saker som diskuterats för att ingå i UMI men det är dessa jag kommer på, i brist på tidigare dokumentation. Tidigare specifikationer finns alltså inte längre publicerade på Socialstyrelsens hemsida.

 

Min allmänna reflektion är att det nog är klokt att så långt möjligt inte utöka UMI-specifikationen på egen hand utan istället se till att den informationsmängd man vill addera både struktureras på ett lika bra sätt i dokumentationen men också visas upp i en så lämplig kontext/situation som möjligt ändå, utan att gå via UMI-specifikationen och UMI-symbolen så att säga.

 

Det kanske istället kan vara ett sätt att fortsätta strukturera upp information utanför just UMI-avgränsningen i patientjournalen?

 

Jag diskuterar gärna innehållet i mailet vidare vid lämpligt tillfälle :-)

Mvh Rikard

 

 

Gammal text i implementationsguiden

Medicinskt tillstånd och behandling

Annat medicinskt tillstånd

Denna undergrupp innefattar en lista med diagnoser som anses att vara allvarliga och viktiga att ta hänsyn till i behandling av en patient. Diagnoserna presenteras i två internationella format: ICD-10 och SNOMED CT. I dagsläget (år 2022) är det vanligare att använda ICD-10 för att dokumentera (representera) diagnoser i elektroniska system för sjukvården än SNOMED CT, därför anses det att vara lämpligt rekommendera att använda ICD-10 för implementering av specifikationen för undergruppen Annat medicinsk tillstånd i första hand.

Tända signalen

När man registrerar diagnos med ICD-10 koden ur listan enligt specifikationen i PRIMÄR eller (/och) SEKUNDÄR källan, signalen = “benet” i symbolen ska tändas.

Släcka signalen

Det finns ingen känd rutin i vården just nu för att avsluta diagnoser som inte är aktuella längre……. DISKUSSION MED FLERA BEHÖVS…… se avsnitt Regler för att trigga eller föreslå UMI

(…..a primary diagnosis to one clinician may be a secondary one to another specialist; an active problem can become inactive (or vice versa) and this can impact the safe use of clinical decision support. In general these qualifiers should be applied locally within the context of the clinical system, and in practice these statuses should be manually curated by clinicians to ensure that lists of Current/Past, Active/Inactive or Primary/Secondary Problems are clinically accurate.)

*En möjlighet att hålla listan uppdaterad är att skapa ett stödsignal med regel att en gång om året det kommer upp meddelande där man ber att ta ställning till en diagnos, till ex. aktiv/ej aktiv. Regel kan baseras på “Last updated“ i protocol-delen av Problem/Diagnosis-arketypen:

 

Arketyper
COMPOSITION

openEHR-EHR-COMPOSITION.problem_list.v2 - a persistent and managed list of any combination of diagnoses, problems and/or procedures that may influence clinical decision-making and care provision for the subject of care.

Denna COMPOSITION kan vara lämpligt att använda som en gemensam “container” för SEKUNDÄR källa

ENTRY

openEHR-EHR-EVALUATION.problem_diagnosis.v1 - details about a single identified health condition, injury, disability or any other issue which impacts on the physical, mental and/or social well-being of an individual.

 

Behandling

Förekomst av implantat/Implantat

Förekomst av transplantat/Transplantat

 

Primära” och “sekundära” källor till UMI - och turordning i utredning

Källor till uppmärksamhetsinformation “dubbeldokumenteras” ofta i dagens journalsystemsystem.

  • Vi väljer att som arbetsnamn i denna guide kalla dokumentation av en ursprunglig händelse, exempelvis en läkemedelsförskrivning eller journalanteckning om en (misstänkt allergisk) reaktion, för “primära källor”

  • Vi väljer att kalla samlande underhållna listor och specialdesignade strukturer för UMI “sekundära källor”

Fördelar med att definiera och tillhandahålla speciella sekundära källor är bl.a. att:

  • det blir tekniskt lätt att bygga varningssystem och sammanhållen export eller delning av UMI

  • …

Nackdelar med att definiera och tillhandahålla speciella sekundära källor är bl.a. att:

  • det finns mycket stor risk att sekundärkällorna inte hålls uppdaterade om detta underhåll behöver göras manuellt av all personal som journalför sådant som kan vara UMI-relaterat. Detta är en patientsäkerhetsrisk som finns i många av dagens system.

  • …

I projektet väljer vi att först titta på informationsstrukturer m.m. för sekundära källor, och därefter titta på primära samt därefter regler för att skapa/uppdatera sekundära källor baserat på primära. Motiveringar:

  • Definition av sekundära källor ger snabba delresultat med faktisk nytta i dagens UMI för NPÖ och export/visning i vårdens olika IT-system

  • Uppdatering av sekundära källor är ett tänkbart mål (output) för regler som använder primära källor som input och bör definieras innan sådan a regler byggs.

  • Ibland finns inte primärkällan för en känd UMI, t.ex. allergi, alls i det aktuella systemet utan har förts in manuellt. Sådant behöver kunna representeras och underhållas.

  • …

Regler för att trigga eller föreslå UMI

Ett bra system för att visa UMI kommer behöva kunna förhålla sig till både primära och sekundära källor. Detta kan ske på flera olika vis, exempelvis med beslutsregler för att:

  1. tända/trigga varningar direkt baserat på en kombination av primära och sekundära källor

  2. eller genom att baserat på primära källor automatiskt uppdatera (eller föreslå manuell uppdatering av) sekundära källor och tända/trigga varningar baserat på de sekundära källorna.

  3. …

Om alternativ 2 ovan används bör sannolikt automatiskt framtagna men manuellt ännu ej hanterade förslag till uppdatering tända någon typ av varning (t.ex. en om “ostrukturerad” UMI)-

 

 

Förslag på arketyper/templates att basera sekundära UMI-källor på

Se:

  • zooma genom att skrolla på musen

  • dubbelklicka eller använd vänstermenyn:

för att lägga till kommentarer på Post-its. Skriva gärna dina initialer på lapparna så att vi vet vem som skrivit vad

  • öppna länkar genom att klicka på Open link rutan:

  • navigera antingen genom högermenyn (Outline):

eller utgå från det norska förslaget i mitten och följ de färgade pilarna till de olika områdena. Eller klicka och dra för att flytta ytan.
(fråga mig gärna om det skulle vara oklart)

Senaste versioner av Informationsspecifikation för uppmärksamhetsinformation:

Version 5.0 (publicerad 2021-12-15) Kodverklista. Informationsspecification, v.5.0

Version 5.1 (publ. 2022-06-29) Kodverklista. Informationsspecification, v.5.1

Motsvarande refsets/OIDs för de Snomed-relaterade urvalen som nämns i Kodverklistan, v. 5.1:

Symbol

Huvudgrupp

Undergrupp

RefSet id

Preferred Term 

Fully specified name

 

Medicinska tillstånd och behandlingar

Annat medicinskt tillstånd

59821000052101

urval medicinska tillstånd, uppmärksamhetsinformation

 Medical conditions, alert information reference set (foundation metadata concept)

Behandling

59831000052104

urval behandlingar, uppmärksamhetsinformation

 Treatments, alert information reference set (foundation metadata concept)

Förekomst av implantat
Implantat

59841000052105

urval implantat, uppmärksamhetsinformation

 Implants, alert information reference set (foundation metadata concept)

Förekomst av transplantat
Transplantat

59861000052106

urval transplantat, uppmärksamhetsinformation

 Transplants, alert information reference set (foundation metadata concept)

113471000052100*

urval förekomst av transplantat, uppmärksamhetsinformation

Presence of transplant, alert information reference set (foundation metadata concept)

 

Smitta

Förekomst av smittämne

59851000052108

urval smittämnen, uppmärksamhetsinformation

 Contagions, alert information reference set (foundation metadata concept)

Förekomst av smittsam sjukdom

60661000052106

urval smittsamma sjukdomar, uppmärksamhetsinformation

 Contagious diseases, alert information reference set (foundation metadata concept)

 

Överkänslighet

 

Allvarlighetsgrad

59811000052109

urval allvarlighetsgrad, uppmärksamhetsinformation

 Degree of severity, alert information reference set (foundation metadata concept)

 

Visshetsgrad

60691000052103

urval visshetsgrad, uppmärksamhetsinformation

 Degree of certainty, alert information reference set (foundation metadata concept)

Kemikalie

59871000052102

urval kemikalieöverkänsligheter, uppmärksamhetsinformation

Hypersensitivities to chemicals, alert information reference set (foundation metadata concept)

Aktiv substans

OID:
ATC: 2.16.840.1.113883.6.73
NSL: 1.2.752.129.5.1.45

Hjälpämne läkemedel

OID:
NSL: 1.2.752.129.5.1.45

Läkemedelsprodukt

OID:
NPL: 1.2.752.129.2.1.5.1

 

Särskild vårdrutin

 

 

59881000052100

urval särskilda vårdrutiner, uppmärksamhetsinformation

 Non-standard care procedures, alert information reference set (foundation metadata concept)

 

103491000052103*

urval särskilda vårdrutiner utifrån fattade beslut, uppmärksamhetsinformation

Non-standard care procedures due to made decisions, alert information reference set (foundation metadata concept)

  • nytillkomna RefSet ID i senaste version

Tabellen sammanställd 2021-11-23 av Mikael Nyström

Uppdaterad 2022-08-16 av Alexandra Saraiva Leao

Uppdaterad 2022-08-23 av A-S Avindell