Innehåll

...

F.n. finns en del info på tillhörande kort i svenska openEHR-förvaltningens kanbantavla.

Status

DEV

Versionshistorik

...

Läs först startsidan “Implementationsguider” som bl.a. beskriver vad dokumentstatus som DEV och rekommendationer som MUST (MÅSTE), MUST NOT (FÅR INTE), SHOULD (BÖR) etc. betyder i praktiken.

...

• implementationsguiden om HSA-identitet och Organisationsnummer samt till olika delar av openEHRs tekniska specifikationer.

• Hälsoärende

• Uppmärksamhetsinformation

• Läkemedelsinfomation (ej påbörjad, därmed ej länkad)

...

• Normalfall: Originalinformation från olika vårdenheter (och därmed inte heller olika vårdgivare) FÅR INTE journalföras inom ramen för samma COMPOSITION vid ett och samma tillfälle utifall de ur PDL-synpunkt borde ha journalförts hos olika vårdenheter (där vården har utförts). Flera ENTRY-objekt (t.ex. mätvärden och bedömningar) från olika vårdenheter FÅR INTE blandas i samma COMPOSITION-version om de normalt borde ha journalförts (och t.ex. signerats) på olika vårdenheter

  • Orsak: Detta beror på att COMPOSITION i denna implementationsguide används som en lägsta nivå för lagring av PDL-relaterade attribut och för utvärdering av åtkomst enligt PDL

• Specialfall: I användningsfall där personal från flera vårdenheter naturligt dokumenterar gemensamt (t.ex. under en multidisciplinär konferens, eller i gemensamma dokument om boendesituation, uppmärksamhetsinformation etc.) så MÅSTE detta lösas på ett sätt så att informationsägandet och ansvaret kan spåras. Exempel:

  1. Multidisciplinär konferens med flera dokument från olika källor: Låt varje ingående dokument lagras och uppdateras av respektive vårdenhet och håll ihop dem med andra konstruktioner som en gemensam FOLDER eller med länkar (LINK) från ett samlingsdokument. Alternativt, håll ihop dokumenten genom att markera dem som tillhörande samma vårdepisod/vårdprocess/hälsoärende. (Vårdepisod etc. utreds i implementationsguiden Hälsoärende och OpenEHR Sammanhållen information från vårdprocesser i openEHR (arbetsmaterial).)

  2. Multidisciplinär konferens med ett gemensamt dokument där flera kan skriva samtidigt: Låt en vårdenhet vara huvudansvarig för anteckningen och lagra ner den enheten som skapare ur PDL-synpunkt. För att ange informationskällor till olika delar av det gemensamma dokumentet kan
     fältet provider i ENTRY-klassen användas, dessa “provider”-fält kommer dock ej användas för att utvärdera åtkomst enligt PDL. Se till att andra enheter som behöver se informationen kan göra det, genom sammanhållen journalföring eller aktiva val inom egna vårdgivaren.

  3. Ett gemensamt dokument (t.ex. om boendesituation eller uppmärksamhetsinformation) som över tid (men inte samtidigt) uppdateras av personal från flera vårdenheter: Att utreda: Beroende på det gemensamma dokumentets syfte och hur vårdgivaren har strukturerat sina vårdenheter och deras gemensamma dokument kan olika lösningar tänkas avseende dokumentets ägare ur PDL-perspektiv. Det är inte nödvändigtvis alltid lämpligt att automatiskt ändra det delade dokumentets informationsägare (vårdenhet & vårdgivare) till den som senast uppdaterade/sparade det.
     Stark rekommendation: Användargränssnitt som visar information från gemensamma dokument BÖR (om information finns) visa ATT det finns information från andra vårdenheter (och vårdgivare?) för denna informationsdelmängd (t.ex. boendesituation) även om ingen aktivt val har gjorts. Det BÖR i gränssnittet sedan vara mycket enkelt att göra ett aktivt som visar denna information även från andra vårdenheter eller vårdgivare. Patientsäkerhetsperspektivet bör väga tyngst.

• Remiss som skickas mellan vårdenheter eller vårdgivare: Utgående remiss (t.ex. baserad på COMPOSITION-arketypen Request for service innehållande INSTRUCTION-arketypen Service request) BÖR ägas av avsändaren. Mottagaren BÖR implicit ges tillstånd att läsa. Om mottagaren gör en kopia av inkommande remissinnehåll i sitt eget system ägs denna innehållskopia av mottagare. På motsvarande sätt BÖR remissvaret ägas av den som genomför testet/tjänsten (t.ex. labbet) och ett riktat utlämnande BÖR göras till remittenten (som FÅR välja att skapa en kopia av informationsinnehållet i sitt eget system och då äger kopian).

...

...

Exemplet nedan är i ett av openEHRs förenklade format: structSDT genererat via EhrScape https://www.ehrscape.com/api-explorer.htmlBehöver uppdateras om strukturändringsförslaget 2022-02-08 genomförs

...

Att en patient är allergisk mot något eller tar vissa mediciner är viktigt för hälso- och sjukvårdspersonal som vårdar en patient som inte kan göra sig förstådd (t.ex. är medvetslös). Spärr av sådan information kan i värsta fall leda till skada eller död i en akut situation. För att förhindra detta finns en möjlighet att undanta läkemedels- och uppmärksamhetsinformation från spärr i den nationella spärrtjänsten. Patienten ges därför möjlighet att välja om spärr ska omfatta även läkemedel och/eller uppmärksamhetsinformation..

Läkemedel

Beslut - om ikryssat, undanta dessa från spärr:

När läkemedelsinformation sparas ner så MÅSTE ATC-kod anges som defining_code i en DV_CODED_TEXT i fältet “Medication item” arketyperna Medication order eller Medication Management samt fältet “Medication item name” i arketypen  Medication statement.

Att göra: kolla övriga arketyper listade nedan

...

Image RemovedImage Removed

Samma mönster MÅSTE användas i fältet “Substance” i arketypen Adverse reaction risk när den används för att ange läkemedelsöverkänslighet

...

Att göra: Lägg in motsvarande svenska bilder/screenshots när de är översättningsgranskade

-var?-

Grunddata om läkemedel som bör kunna hittas med t.ex. AQL

• Medication order

• Medication management

• Medication statement (FHIR) - t.ex. för import från andra system

• Medication summary - historisk livstidsanvändning av enskilda läkemedel

Frågeformulär om läkemedelsanvändning

• Medication screening

Behållare för grunddata eller frågeformulär om läkemedel

• Medication list (Composition) och dess innehåll

• Prescription (Composition)

• Medication list (Section - de delar som ligger där)

Detaljerade “CLUSTER”-arketyper som sannolikt ingår som delkomponenter i någon av ovanstående

• CLUSTER.medication.v1

• CLUSTER.medication_authorisation.v0

• CLUSTER.medication_order_summary.v0

• CLUSTER.medication_supply_amount.v0

Att göra (noterat efter remissutskick): Ett antal läkemedelsrelaterade arketyper ändrade status i CKM på julafton, kolla vad som behöver uppdateras i texten ovan baserat på ändringarna:

...

Övrigt

• Ej diskuterat: Använda någon särskild folder för läkemedelsrelaterad infomration?

• Att utreda: Hur göra med Adverse reaction ang läkemedel?

Att utreda:

Ska vi i denna implementatioshandbok bidra med anvisningar om Snomed-urval relaterade till läkemedelsadministration, t.ex. om administrationssätt m.m.?

Uppmärksamhetsinformation (medicinska varningar etc.)

...