Arbetsmaterial UMI i openEHR
- 1 Projektinformation
- 2 Projektlogg/status
- 2.1 2023-09-28 Möte
- 2.2 2023-09-19 Möte
- 2.3 2023-09-05 Möte
- 2.4 2022-02-02 Info
- 2.5 2022-05-16 Info
- 2.6 2022-05-31 Möte
- 2.7 2022-06-14 Möte
- 2.8 2022-08-23 Möte
- 2.9 2022-09-06 Möte
- 2.10 2022-09-23 Möte
- 2.11 2022-10-18 Möte
- 2.12 2022-11-01 Möte
- 2.13 2022-11-15 Möte
- 2.14 2022-11-29 Möte
- 2.15 2022-12-13 Möte
- 2.16 2023-01-10 Möte
- 2.17 2023-01-13 Möte (Grupp 2)
- 2.18 2023-01-17 Möte (Grupp 2)
- 2.19 2023-01-16 Möte (Grupp 1)
- 2.20 2023-01-18 Möte (Grupp 1)
- 2.21 2023-01-20 Möte (Grupp 1)
- 2.22 2023-01-23 Möte (Grupp 1)
- 2.23 2023-01-24 Möte
- 2.24 2023-02-02 Möte (Grupp 1+RL)
- 2.25 2023-02-07 Möte
- 2.26 2023-02-21 Möte
- 2.27 2023-02-24 Möte grupp 2
- 2.28 2023-03-07 Möte
- 2.29 2023-03-21 Möte
- 2.30 2023-04-04 Möte
- 2.31 2023-05-02 Möte
- 2.32 2023-05-09 Extramöte
- 2.33 2023-05-11 Extramöte
- 2.34 2023-05-16 Möte
- 2.35 2023-05-30 Möte
- 2.36 Beslut
- 3 Övrig information
- 3.1 Rikards mejl
- 4 Gammal text i implementationsguiden
- 4.1.1 Medicinskt tillstånd och behandling
- 4.1.1.1 Annat medicinskt tillstånd
- 4.1.1.1.1 Tända signalen
- 4.1.1.1.2 Släcka signalen
- 4.1.1.1.3 Arketyper
- 4.1.1.1.3.1 COMPOSITION
- 4.1.1.1.3.2 ENTRY
- 4.1.1.2 Behandling
- 4.1.1.3 Förekomst av implantat/Implantat
- 4.1.1.4 Förekomst av transplantat/Transplantat
- 4.1.1.1 Annat medicinskt tillstånd
- 4.1.1 Medicinskt tillstånd och behandling
- 4.2 Primära” och “sekundära” källor till UMI - och turordning i utredning
- 4.3 Regler för att trigga eller föreslå UMI
- 4.4 Förslag på arketyper/templates att basera sekundära UMI-källor på
- 4.5 Senaste versioner av Informationsspecifikation för uppmärksamhetsinformation:
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
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:
Att kunna “släcka” en tidigare “tänd” del av UMI
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
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
Det vid uppdateringar av Socialstyrelsens UMI-spec kan komma fler saker under respektive kategori
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:
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?) |
|
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 |
|
---|---|---|---|
243142003 | BiPAP-behandling | Medicinsk fråga: 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
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
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.2Diskuterar 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:
- Skapa en första template som realiserar Socialstyrelsens informationsspecifikation version 5.1, ta hänsyn till kommentar och länkning till grunddokumentation
- Använd arketypen Adverse reaction risk för Överkänslighet för sekundärdokumentation
- 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:
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.
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|
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:
tända/trigga varningar direkt baserat på en kombination av primära och sekundära källor
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.
…
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 InformaticsHä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åndBehandling
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.v0Fö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.v1Vå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.v0Smitta
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 diskussionenHar 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
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 | 59841000052105 | urval implantat, uppmärksamhetsinformation | Implants, alert information reference set (foundation metadata concept) | ||
Förekomst av 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: | ||||
Hjälpämne läkemedel | OID: | ||||
Läkemedelsprodukt | OID: | ||||
| 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