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:

• Internationella diskussioner i openEHRs forum och andra källor (generellt om området)

  • https://discourse.openehr.org/t/patient-alert-archetypes/1947

  • https://discourse.openehr.org/t/revisiting-adverse-reactions/1855

  • https://ckm.openehr.org/ckm/projects/1013.30.36 - projektet “Warnings and alerts”

  • https://www.atomicainformatics.com/archetypical/2014/07/16/therapeutic-precautions-are-the-new-black?rq=alert

• Svensk diskussioinstråd i openEHRs forum (specifikt för Sverige, t.ex. tillämpning av Socialstyrelsens infospec) - här finns även inlägg med Norska erfarenheter

• openEHRs biliotek av arketyper https://ckm.openehr.org/ckm/ (CKM)

• openEHRs tekniska specifikationer https://specifications.openehr.org/

• Ursprungligt förslag, se 2022-01-21 Agenda & mötesanteckningar (förvaltningssmöte)

• Projektets kort i svenska openEHR-förvaltningens kanbantavla: SWE-anslagstavla - Agil-anslagstavla - openEHR JIRA (atlassian.net)

• Implementationsguiden för PDL i openEHR kommer hänvisa till detta projekt avseende uppmärksamhetsinformation.

Tankar fångade innan projektdtart:

• I samband med läkemedelsrelaterad uppmärksamhetsinformation bör vi ta en titt på om vi i samarbete med Genomic Medicine Sweden (GMS) område https://genomicmedicine.se/farmakogenomik/ och GMS-delprojektet “Skalbara informatiklösningar” kan utforma modeller (templates och kanske beslutsregler) som kan ligga till grund för sådant som tas upp i artikeln https://lakartidningen.se/klinik-och-vetenskap-1/artiklar-1/temaartikel/2021/05/farmakogenomik-individuell-anpassning-av-lakemedel-och-dos/ figur 2 9 den artikeln visar en tänkt översikt i journal, men den kan sannolikt åskådliggöras även inom befintlig uppmärksamhetssignal på ett bra sätt. //Mvh, @Erik Sundvall

• …

Projektlogg/status

2023-09-28 Möte

Deltagare

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

Anteckningar

• gått genom kommentarer på Uppmärksamhetsinformation i openEHR - openEHR Clinical - Confluence (atlassian.net) och kollat genom arketypen utifrån dem

  • ändrat från bör till ska

  • uppdaterat mappning för adverse reaction risk i Uppmärksamhetsinformation i openEHR - openEHR Clinical - Confluence (atlassian.net) (men insåg sedan att en ny version 2 av adverse reaction risk arketypen har släppts och att vi bör hämta in den)

  • säkerställt att urvalen finns angivna i templaten för särskild vårdrutin och överkänslighet

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

• Claudia presenterar skalet för implementationsguiden: Uppmärksamhetsinformation i openEHR - openEHR Clinical - Confluence (atlassian.net)

• Beslutade att alla läser genom och kommenterar inför mötet om 2 veckor. Sedan går vi genom kommentarer på mötet den 19/9

Ä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

• Utifrån muralen sätter vi in oss i de arketyper som norrmännen har använt och som pekas ut i muralen,

  • Vi kollar närmare på: Kritisk informasjon i Kjernejournal - Tankekart, Kritisk informasjon i Kjernejournal - Enkel visning och Kritisk informasjon i Kjernejournal - Hierarki

    • Mycket av designen/strukturen kan återanvändas i det svenska arbetet

    • Förslag från Erik: Koder för intubationsproblem finns i SoS UMI-spec, men djupare detaljer om intubationsproblem kanske ska vara en separat rekommendation och templateförslag? Lämpligen delvis baserad på SFAIs https://sfai.se/riktlinje/lankar/dokument-med-medicinska-rad/anestesiproblemkort/ se https://sfai.se/wp-content/uploads/files/instruktion_anestesiproblemkort%20.pdf

    • Det finns möjlighet i den norska modelleringen att uttrycka att man aktivt undersökt/frågat/konstaterat att det inte finns någon överkänslighet överhuvudtaget, vilket inte finns på samma sätt i Socialstyrelsens specifikation.

• Beslut: Börja modellera experimentell template i en branch under modellbibliotek: GitHub - modellbibliotek/CKM-mirror at UMI-warning-info. Om inte alla ingående arketyper redan finns på Svenska ännu så kan vi börja göra templaten på engelska.

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 https://github.com/modellbibliotek/CKM-mirror/tree/UMI-warning-info . Detta görs genom att följa stegen nedan:

  • Logga in i Archetype Designer (openehr.org)

  • Skapa ett nytt repository i Archetype Designer med uppgifter enligt nedanstående skärmdump

  • 

  •  

• 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

      • formulering i tjänstekontraktet GetAlertInformation från rivta-domains / riv.clinicalprocess.healthcond.description — Bitbucket

      • Rikards presentation vid SNOMED CT Expo: Hypersentitivity (Life threatening, Harmful, Bothersome), Diagnoses, Treatments, Contagious, Non standard procedures

      • FHIR? → Rikard skickade relaterade FHIR-profiler för IPS

        • https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-AllergyIntolerance-uv-ips.html

        • https://build.fhir.org/ig/HL7/fhir-ips/ipsStructure.html

  • 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

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

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

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 https://specifications.openehr.org/releases/RM/latest/common.html#_link_class

  • Citation-arketypen https://ckm.openehr.org/ckm/archetypes/1013.1.721

• 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

          • Medication details.name

          • Medication details.form

      • 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 https://discourse.openehr.org/t/coding-archetype-concepts-and-nodes-using-terminology/347/4?u=erik.sundvall

      •  

Tabell till förslag 3a:

Tabell till förslag 3b:

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

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

https://ckm.openehr.org/ckm/archetypes/1013.1.2593

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

• Fortsätter med Behandling och resonerar att arketypen Medication order (eftersom vi vill flagga för behandlingen från och med den punkten att behandlingen har ordinerats) för de flesta behandlingar som finns med i urvalet, men funderar om dialysbehandling och bipap faller inom scopet för arketypen

• Funderingar om man ska göra avsteg från ovanstående för dialysbehandling och bipap-behandling och använda Procedure arketypen för dessa två

• Bipap - finns kva-koder, se nedan

  • DG-001 Inledande av akutbehandling med luftvägsmottryck CPAP eller BilevelPAP - KVÅ - Internetmedicin

  • DG-027 Inledande av långtidsbehandling med luftvägsmottryck CPAP eller BilevelPAP - KVÅ - Internetmedicin

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:

• Norska förslag: Uppmärksamhetsinformation i openEHR - openEHR affiliates / openEHR.se - openEHR inlägg #7

• Alexandras mail:
  ”Min idé från början liknar den som är beskriven av Heather Leaslie Therapeutic Precautions are the 'new black'! — Atomica Informatics

  Här är mina tankar kring möjliga arketyper vi kan använda listat efter strukturen i specifikationen.

  Själva listan kan vara Composition openEHR-EHR-COMPOSITION.problem_list.v2

  Medicinsk tillstånd och behandling
  Annat medicinsk tillstånd

  Behandling
  openEHR-EHR-INSTRUCTION.medication_order.v3
  jag är inte säcker men kanske kan det vara tillåten att använda SectionopenEHR-EHR-SECTION.medication_list.v0

  Förekomst av implantat and Förekomst av transplantat
  openEHR-EHR-EVALUATION.problem_diagnosis.v1
  openEHR-EHR-ACTION.procedure.v1
  Physical examination findings openEHR-EHR-OBSERVATION.exam.v1

  Vårdrutinavikelse
  Här har jag inte hittat något passande. Det verkar att vi behöver tänka någon ny arketyp med inriktning Admin (administrative legal info) eftersom informationen i sig har inget med själva medicinska behandlingen att göra direkt.

  Överkänslighet
  som Björn Naess säger skriver på Uppmärksamhetsinformation i openEHR - openEHR affiliates / openEHR.se - openEHR den klassiska:
  openEHR-EHR-EVALUATION.adverse_reaction_risk.v1
  och även en Section openEHR-EHR-SECTION.adverse_reaction_list.v0

  Smitta
  Förekomst av smittämne och Förekomst av smittsam sjukdom hos gravid
  här är jag lite osäker och behöver allas bidrag till diskussionen

  Har ni frågor, funderingar och/eller kommentar är ni välkomna att lämna de på denna sida annars kan vi ta upp de senare efter”

• Sep 29, 2022
  Jag (Ann-Sofi) har, med inspiration av det norska arbetet, tagit fram ett arbetsdokument i Mural där jag har klippt in information samt länkar från Socialstyrelsens dokument, OpenEHR samt det norska förslaget.
  Jag har kommenterat och lagt in förslag på hur vi skulle kunna mappa stora delar av informationen. Se muralen som vårt gemensamma arbetsdokument, där vi alla kan bidra med tankar och kommentarer:
  Förslag på mappning UMI/OpenEHR

För er som inte har arbetat med Mural tidigare kommer här en kort instruktion:

• 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