2023-04-18 Arbetsmöte

Översättningsanslagstavlan

Svenska översättningsanslagstavlan

Mötesanteckningar

Arbetet med laboratoriearketyper fortsätter, håller på med AnalyteResult, när det är gjort är hanteringen av synpunkter klart och arketyperna kan gå ut på en till remiss.

Dubbelkolla om openEHR Sweden Translation - Agil-anslagstavla - openEHR JIRA (atlassian.net) är prioriterad, borde vara det. Förslag att göra det på ett möte och skicka ut mejl till alla för att skriva när vi går genom backloggen och att det finns möjlighet att påverka

Översättning av organisation behöver prioriteras upp för [SWE-20] PDL och openEHR - openEHR JIRA (atlassian.net), finns redan på SWET-anslagstavla - Agil-anslagstavla - openEHR JIRA (atlassian.net)

Projektanslagstavlan

Svenska projektanslagstavlan

Anteckningarna finns i respektive jiraärende.

Övrigt

14:00-15:00

Signering

Se förväntade deltagare →

@Anders Thurin @Anette Larsson @Emma Molin @Erik Sundvall @Joakim Hedlund @Jörgen Kuylenstierna @Mikael Nyström

Deltagare: @Anette Larsson @Emma Molin @Erik Sundvall @Jörgen Kuylenstierna @Mikael Nyström

Vi tittade på klasserna ATTESTATION AUDIT_EVENT m.m. i kapitel 4 av https://specifications.openehr.org/releases/RM/latest/common.html#_generic_package

Open

…samt på de olika koderna som fanns i openEHRs interna openEHR-vokabulär för att koda dessa…

• AUDIT_DETAILS.change_type , se vokabuläret attestation_reason (där finns bara de två valen 240|signed respektive 648|witnessed. Arvetshypotesen är att vi bör använda signed för alla typer av signeringar, dubbel/kontrasigneringar m.m. samt att witnessed ska användas främst för att indikera att man sett något t.ex. att man har läst och förstått (vidimerat?) ett labbsvar

• ATTESTATION.reason, se vokabuläret audit_change_type som för närvarande innehåller nio olika koder, där 666|attestation verkar rimligast att använda för både signeringar och vidimeringar, sannolikt kan 249|creation vara aktuellt i de fall där man gör allt på en gång direkt när objektet (t.ex. en COMPOSITION skapas och lagras)

Open

Om något ska dubbel/kontrasigneras eller en legitimerad läkare ska signera något som en student gjort så är arbetshypotesen att vi helt enkelt kan ha ytterligare en instans av ATTESTATION-klassen till det objekt som ska signeras (vanligen en COMPOSITION).

För att hålla reda på vilken roll olika personer har både före och i samband med signering föreslås att EVENT_CONTEXT.participations används med PARTICIPATION.function satt med hjälp av eller inspirerat av lämpliga delar av något ur:

• http://build.fhir.org/valueset-participation-role-type.html

• https://terminology.hl7.org/5.1.0/CodeSystem-provenance-participant-type.html#provenance-participant-type-attester

Alltså t.ex. att när en student skapar en anteckning så läggs samtidigt en PARTICIPATION med där man anger id på den ansvarige handledande läkaren samt sätter handledarens roll till HL7s verifier (eller legal) eller motsvarande.

För att man ska kunna implementera ett system som exempelvis flaggar upp saker som behöver dubbelsigneras av en viss (t.ex. handledande) läkare får man (AQL-)fråga efter de COMPOSTIONs där denne läkares id finns med verifier-roll (eller liknande) och som samtidigt inte redan har en kopplad ATTESTATION.comitter med läkarens id. Vi hoppas motsvarande resonemang kan funka för andra typer av dubbla signeringar.

I sammanhanget tänkte vi även på att det kan vara lämpligt att använda PARTICIPATION.function = enterer för att ange vem som skrivit in det hela om det ä'r någon annan än den som står som COMPOSITION.composer, t.ex. en medicinsk sekreterare som skrivit in ett citat.

Förslag på saker att göra:

P.S. Vi tittade även litet på att vid en students signerar samtidigt skapa en ytterligare en ATTESTATION med ATTESTATION.is_pending=true som en möjlighet att t.ex. markera upp att en handledare borde signera, men kom fram till att istället förespråka huvudalternativet med EVENT_CONTEXT.participations som lättare kan skapas tidigare i dokumentationsprocessen (om så önskas) och dessutom har bredare möjligheter och förklaringskraft i form av PARTICIPATION.function och PARTICIPATION.mode.

[SWE-84] Implementationsguide för vidimering/signering? - openEHR JIRA (atlassian.net)

15:30-17:00

UMI

@Mikael Nyström @Erik Sundvall
@Emma Molin
@Ann-Sofi Avindell @David Wetterbro @Daniel Karlsson @Carina Sandell
@Anette Larsson
@Anders Thurin
@Rikard Lövström
@Claudia Ehrentraut

Uppmärksamhetsinformation i openEHR - openEHR Clinial - Confluence (atlassian.net)