Innehåll

...

Projektinformation

Denna wikisida är avsedd att utgöra grunden till en implementationsguide som beskriver ett rekommenderat sätt att tillämpa den svenska Patientdatalagen (PDL) i openEHR-baserade system på ett gemensamt leverantörsoberoende sätt.

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

Status

DEV

Versionshistorik

...

Notera att samtliga rekommendationer eller direktivenbart gäller information som ska utvärderas enligt PDL. Alltså gäller det har de inte anpassats till t.ex. information som är uppmätt och registrerad av patienten själv utan initiering från hälso- och sjukvården, eller information inom SOL SoL.

Relaterade dokument

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.

...

En introduktion till openEHR finns på https://openehr.org/about/what_is_openehr. Exempel på SFMIs SFMIs svenska kurser och presentationer (inklusive videoinspelningar och presentationsbilder) om openEHR finns i form av https://discourse.openehr.org/t/digital-utbildningsserie-om-openehr-nov-2020-jan-2021/1105 och https://discourse.openehr.org/t/openehr-vitalis-2021/1512

...

Varje elektronisk journalhandling är knuten till en viss vårdgivare som ansvarar för de handlingar som upprättas eller inkommer i sin verksamhet. Om en verksamhet upphör eller om journal-handlingarna av annan anledning ska omhändertas, ska vårdgivaren se till att verksamhetens patientjournaler tas om hand på ett sådant sätt att obehöriga inte kan få del av uppgifter om patienterna. Det innebär bland annat att vårdgivaren behöver beakta de regler som gäller för att bevara journalhandlingar. Journalhandlingar som efter beslut ska arkiveras ska bevaras minst 10 år.

Begrepp

...

HSA-id består av två delar. En del som identifierar utfärdande organisation och en del som identifierar det unika objektet (t.ex. en anställd eller en vårdavdelning). Strukturen för ett HSA-id ser ut på följande sätt: SE<organisationsnummer för utfärdande organisation>-<löpnummer för objekt> Löpnummer kan bestå av både bokstäver och siffror (max 31 tecken totalt). Se den implementationsguiden för HSA-identitet och Organisationsnummer för detaljer samt exempeltabellen längre ner i dokumentet, som även innehåller exempel med en enskild näringsidkare som har avtal med region och i samband med det fått ett HSA-id tilldelat därifrån.

Specialfall:

• S.k. “tredjepartsanslutna” små aktörer skaffar ofta HSA-id etc. via ombud som t.ex. Svensk e-identitet.

• Ibland har en enhet varit både vårdgivare och vårdenhet, vilket inte längre rekommenderas (krångligt vid expansion till fler enheter)

• Det finns även “Privat-Privat” = inga avtal med regioner, de är i dagsläget vanligen inte med i sammanhållen journalföring

• Ett extra lurigt case när specialfall är privatläkare som har både “privat-privata” patienter och patienter på uppdrag/avtal med region och lagrar data från båda kategorierna i i samma system.

Utöver PDL kan dessa attribut behövas vid arkivering. (Standardiserad arkivering kanske blir ämnet för en framtida separat openEHR-implementaitonsguideimplementationsguide).

Lagring av PDL-relaterade grundattribut

...

En viktig aspekt av att utvärdera åtkomst till patientinformation är att rätt metadata finns sparad i den. Utvärdering av åtkomst utgår från läsarens kontext (varifrån det läses och i vilket syfte) samt patientinformationens kontext (vilken organisation eller process den tillhör). Mer information om regelutvärdering vid åtkomst till patientinformation finns i Ineras dokument Behörighetsmodell för vård och omsorg som nedan nedanstående illustration är hämtad från.

...

Alla journalanteckningar i openEHR lagras inuti objektstrukturer av typen COMPOSITION. Förenklat kan man se COMPOSITION som en sorts “kuvert” eller dokumenthuvud med kontextuell information. Följande attribut från openEHR är aktuella för att utvärdera åtkomst ur PDL-perspektiv:

...

• COMPOSITION.context → EVENT_CONTEXT.health_care_facility BÖR ange den mest granulära eller exakta (under)enhet/mottagning som är möjlig och lämplig, om sådan finns, annars MÅSTE man åtminstone ange vårdenhet (ur PDL-perspektiv), eftersom innehållet i detta attribut kan förväntas vara det som visas i många användargränsnitt samt används för vissa sorters filtreringar i gränssnitt. Se detaljer i stycket Fördjupning om health_care_facility nedan.

  • Exempel - diabetessköterskemottagningen hos Vårdcentralen Villastaden: Distriktssköterskemottagning vid Brandbergens vårdcentral, med HSA-id SE2321000016-14LF

Förväxlingsrisker - Andra relaterade fält i openEHR vars funktion inte används för utvärderinga v utvärdering av åtkomst enligt PDL och som inte ska förväxlas med ovanstående är exempelvis:

• COMPOSITION.composer som MÅSTE ange dokumentets författare, som ansvarar för innehållet kliniskt (t.ex. en lägareläkare) och kan vara annan än den den inloggade användare (t.ex. vårsaministratörvårdaministratör) som i praktiken faktiskt lagrar det).

• EVENT_CONTEXT.location beskriver är en fysisk plats, t.ex. ett visst rum, operationssal - inte en organisatorisk enhet. Detta frivilliga fält FÅR användas och kan vara av intresse exempelvis vid smittspårning eller annan uppföljning, men är alltså inte relevant för åtkomstkontroll enligt PDL.

• Teknisk information: För varje uppdatering av en COMPOSITION som görs MÅSTE info om inloggad användare (vanligen användarnamn) sparas i attributet VERSION.commit_audit → AUDIT_DETAILS.committer

• Elektronisk (kryptografisk) signering av journalanteckning FÅR göras, vid behov, på versionshanterad COMPOSITION-nivå via ORIGINAL_VERSION.attestations som beskrivs i openEHRs “Change Control Package“. I svenska journalsystem görs sällan sådan signering idag.

Diagram och klassbeskrivningar

...

Källa: https://specifications.openehr.org/releases/RM/latest/ehr.html#_ehr_information_modelImage Removed
.
Notera att PARTY_IDENTIFIED, PARTY_PROXY och PARTICIPATION detaljeras mer i nästa bild.

Image Added
Källa: https://specifications.openehr.org/releases/RM/latest/common.html#_common_information_model

...

• 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 PDLReferensmodellen erbjuder inga enhetselement på Entry, men utifall att enheter ingår i den arketyp som ligger till grund för en Entry så kommer de inte att utvärderas

• Specialfall: I användningsfall där personal från flera vårdenheter naturligt dokument 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 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 andra fasen av arbetet med implementationsguiden.).

  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.

     1. Rekommendation (BÖR) för gemensamma dokument - 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 delmängd informationsdelmängd (t.ex. boendesituation) - Patientsäkerhetsperspektiv bör övervägaä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.

     2. Analogi… papper + bild på versioned compositions

  4. 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) ägs rimligen BÖR ägas av avsändaren. Mottagaren bör 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 ägs BÖR remissvaret ägas av den som genomför testet/tjänsten (t.ex. labbet) och ett riktat utlämnande görs BÖR göras till remittenten (som kan FÅR välja att skape skapa en kopia av informationsinnehållet i sitt eget system och då äger kopian).

Anchor
hcf hcf

Fördjupning om health_care_facility

• Som nämndes tidigare sparas den mest specifika enheten där vården bedrivs under COMPOSITION.context → EVENT_CONTEXT.health_care_facility. Detta attribut är av typen PARTY_IDENTIFIED, se föregående UML-diagram, för detta gäller:

  • Normalfall: HSA-id för den mest specifika enheten MÅSTE anges som ett element i listan PARTY_IDENTIFIED.identifiers, som är en lista med objekt av typen DV_IDENTIFIER (se bild med tabell ovan) i enlighet med Implementationsguide för HSA-id och Organisationsnummer

  • Specialfall: Undantaget är de fall (t.ex. vissa riktigt små verksamheter) som inte har HSA-idn eller vårdavdelningar, i det fallet kan FÅR den minsta enheten vara själva Vårdgivaren (), i dessa fall MÅSTE istället vårdgivarens organisationsnummer finnas i PARTY_IDENTIFIED.identifiersi enlighet med Implementationsguide för HSA-id och Organisationsnummer

  • Fler identifierare för den mest specifika enheten FÅR anges vid behov i listan med DV_IDENTIFIER-objekt.

  • Namnet på enhet enheten FÅR anges via EVENT_CONTEXT.health_care_facility → PARTY_IDENTIFIED.name

    • Om namn på enhet anges så MÅSTE det vara det namn som gällde på enheten vid händelsen som föranledde dokumentet (det ska alltså inte uppdateras i den redan sparade journalanteckingen om enheten senare byter namn)

    • Ett alternativ till att spara information om namn på enheten är att slå upp det i en versionshanterad katalogtjänst som kan ange dåvarande (och kanske även nuvarande) namn på enheten.

    • Notera att det generellt är att rekommendera att kunna visa upp enhetsnamn som gällde vid tidpunkt för en händelse i ett användargränssnitt, utifrån ett PDL-perspektiv anses det dock tillräckligt om HSA-identiteten är känd.

    • Att utreda: Bör vi rekommendera att mer än den mest specifika enhetens interna katalognamn ska anges? Ska det t.ex. stå bara "Distriktssköterskemottagning" (som i HSA-katalogen), eller något mer beskrivande som "Distriktssköterskemottagning, Brandbergens vårdcentral"

Anchor
vg_ve vg_ve

Fördjupning om Vårdgivare och Vårdenhet

Det MÅSTE gå att ta reda på hos vilken Vårdenhet och Vårdgivare en COMPOSITION skapades (avseende PDL-tillämpning). Implementationsguiden styr/begränsar inte hur Vårdenhet och Vårdgivare enligt HSA sparas och tillämpas inuti ett enskilt openEHR-baserat system utan beskriver istället via vilka logiska sökvägar i en COMPOSITION informationen om vårdgivare/vårdenhet MÅSTE kunna nås om den exporteras (t.ex. bulkexport vid systembyte eller arkivering) eller om den exponeras via API till externa system (t.ex. via anropen /ehr/{ehr_id}/composition eller /query/... i openEHRs officiella REST-API. Internt FÅR detta tekniskt lösas på valfritt sätt, exempelvis genom att:

...

...

Exemplet nedan är i ett av openEHRs förenklade format: structSDT genererat via EhrScape https://www.ehrscape.com/api-explorer.html

...