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

Version

Datum

Uppdatering

Ansvarig

0.1.0

Första version för internremiss

Den första remissomgången börjar här och avser kapitlen

  • Bakgrund

  • Lagring av PDL-relaterade grundattribut

  • Filtrering och utvärdering baserat på lagrade grundattribut

Samtidigt är implementationsguiden för HSA-identitet och Organisationsnummer ute på remiss

Bakgrund [REMISSEN BÖRJAR HÄR]

Denna implementationsguide har tagits fram i samarbete mellan flera vårdgivare och systemleverantörer aktiva i Sverige (se appendix). Implementationsguiden syftar till att beskriva hur openEHR kan användas i tillämpningen av Patientdatalagen på ett gemensamt leverantörsoberoende sätt.

Notera att samtliga rekommendationer eller direktiv gäller information som ska utvärderas enligt PDL. Alltså 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.

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.

Detta dokument hänvisar även på flera ställen till implementationsguiden om HSA-identitet och Organisationsnummer samt till olika delar av openEHRs tekniska specifikationer.

Guiden refererar även till termer och begrepp definierade inom HSA som går att finna vidare information på Öppen info: Katalogtjänst HSA

En introduktion till openEHR finns på https://openehr.org/about/what_is_openehr. 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

Juridiska krav

Patientdatalag (2008:355) reglerar behandling av personuppgifter, journalföring, sekretess samt åtkomst till journalhandlingar i Sverige. Lagen kompletteras av Socialstyrelsens föreskrifter om journalföring och behandling av personuppgifter i hälso- och sjukvård (HSLF-FS 2016:40). De huvudsakliga lagkraven som instruktionen omfattar beskrivs nedan.

Generellt om Journalföring

Bestämmelsen om skyldighet till journalföring innebär att all information som en hälso- och sjukvårdspersonal tillför journalen ska journalföras på den vårdenhet där vården utförs. En användare kan därmed inte journalföra på en annan vårdenhet än där vårdkontakten skett. Vårdgivaren ska säkerställa att åtgärder kan härledas till en användare i informationssystem.

Stark Autentisering – vem du är

Informationssystem som behandlar personuppgifter har krav på stark autentisering med användning av e-legitimation vid inloggning. Kravet gäller även den enskildes åtkomst till sina journalhandlingar.

Behörighetsstyrning och åtkomst – vad du får göra

Den som arbetar hos en vårdgivare får ta del av dokumenterade uppgifter om en patient endast om denne deltar i vården av patienten eller av annat skäl behöver uppgifterna för sitt arbete inom hälso- och sjukvården, så kallad inre sekretess. Bestämmelserna innebär i stora drag att journalinformation om en patient ska lagras och vara åtkomlig på tre nivåer där användaren i första hand får åtkomst till information som tillhör den vårdenhet där vårdrelationen finns. Efter aktivt val kan information från annan vårdenhet hos samma vårdgivare göras åtkomlig. Slutligen kan användaren efter ytterligare aktivt val och med patientens samtycke få åtkomst till information, som inte är spärrad, hos annan vårdgivare via regelverket för sammanhållen journalföring. Vårdgivaren ansvarar för att det i loggar framgår vilka åtgärder som har vidtagits med uppgifter om en patient. Ett aktivt val för att få tillgång till uppgifter om en patient är ett exempel på en åtgärd som ska loggas.

Åtkomst kan även tilldelas per vårdprocess där information inom en vårdprocess från flera vårdenheter kan ges inom samma vårdgivare utan föregående aktiva val. Avgränsningen av en vårdprocess är funktionell och inte organisatorisk såsom beträffande vårdenhet.

Åtkomstkontroll och logguppföljning – säkerställa att åtkomster är rimliga

Vårdgivare ansvarar för att åtkomster till personuppgifter loggas och att det av loggarna framgår patient, användare som tagit del av uppgifterna, vilka åtgärder som vidtagits, vid vilken tidpunkt samt vårdenhet eller vårdprocess. Vårdgivaren ansvarar även för att systematiska och återkommande stickprovskontroller av loggar genomförs och dokumenteras.

Patientens rätt att se vem som läst sina uppgifter

Vårdgivare är skyldiga att på begäran lämna ut uppgifter om åtkomster till en patients information, där ska det framgå vid vilken tidpunkt, samt från vilken vårdenhet åtkomsten gjorts. Informationen ska vara utformad så att patienten kan bedöma om åtkomsten varit befogad eller inte. 

Patientens möjlighet att begränsa vårdens tillgång till sin information genom spärrar och samtycke

En patient kan motsätta sig att uppgifter om honom eller henne är tillgängliga genom elektronisk åtkomst för den som arbetar vid en annan vårdenhet eller inom en annan vårdprocess hos samma vårdgivare. I sådana fall ska uppgiften genast spärras. Uppgift om att det finns spärrade uppgifter får vara tillgänglig för andra vårdenheter eller vårdprocesser. En spärr får hävas av en behörig befattningshavare hos vårdgivaren om patienten samtycker till det. Spärren kan också hävas av en annan vårdenhet eller vårdprocess, till exempel akutmottagningen, om patientens samtycke inte kan inhämtas och informationen kan antas ha betydelse för den vård eller behandling som patienten oundgängligen behöver, så kallad nödöppning.

Systemet ska vara uppbyggt så att behörig användare i steg 1 får tillgång till information om vilken eller vilka vårdenheter eller vårdprocesser som har spärrade uppgifter om patienten. Steg två innebär att behörig användare, genom att denne kan se vid vilken eller vid vilka vårdenheter eller vårdprocesser uppgifter har spärrats, kan bedöma om de spärrade uppgifterna kan antas ha betydelse för vården av patienten. Endast uppgifter som kan antas ha en sådan betydelse får hävas.

Sammanhållen journalföring

Sammanhållen journalföring innebär att vårdgivare under vissa förutsättningar kan få direktåtkomst till varandras elektroniska journalhandlingar. Den sammanhållna journalföringen innebär alltså inte att hälso- och sjukvårdspersonal som arbetar hos en vårdgivare ska föra anteckningar i en annan vårdgivares journalhandlingar. Patienten har rätt att spärra åtkomst för andra vårdgivare. En sådan spärr får endast hävas av patienten själv eller vid en akut nödsituation. Om vårdgivaren bedömer att de spärrade uppgifterna kan antas ha betydelse för den vård som patienten oundgängligen behöver, ska en begäran om åtkomst göras hos den vårdgivare som har spärrat uppgifterna.

Kvalitetsregister

Med kvalitetsregister avses en automatiserad och strukturerad samling av personuppgifter som inrättats särskilt för ändamålet att systematiskt och fortlöpande utveckla och säkra vårdens kvalitet. Personuppgifter får inte behandlas i ett nationellt eller regionalt kvalitetsregister, om den enskilde motsätter sig det. Om den enskilde motsätter sig personuppgiftsbehandlingen sedan den påbörjats, ska uppgifterna utplånas ur registret så snart som möjligt.

Omhändertagande av journalhandlingar

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

Begrepp (inkl. ev. länk till SoS termbank)

Beskrivning

autentisering

kontroll av uppgiven identitet

stark autentisering

kontroll av uppgiven identitet på två olika sätt

hälso- och sjukvårdspersonal

person eller personer som i sitt yrke utför hälso- och sjukvård

informationssystem

system som insamlar, bearbetar, lagrar eller distribuerar och presenterar information

patientjournal

en eller flera journalhandlingar som rör samma patient

vårdgivare

statlig myndighet, region, kommun, annan juridisk person eller enskild näringsidkare som bedriver hälso- och sjukvårdsverksamhet

vårdenhet

organisatorisk enhet som tillhandahåller hälso- och sjukvård [definition enligt SoS termbank].

I denna implementationsguide avser “vårdenhet” specifikt den enhetsnivå som i juridisk/PDL-mening används för att utvärdera inre sekretess. Exempelvis en klinik eller den samling underenheter som kallas “Spärrgrupp” i journalsystemet TakeCare i Region Stockholm.

kopplad/ingående enhet

En kopplad/ingående enhet kan beskrivas som underliggande objekt till en vårdenhet, används ex för fall där en vårdenhet omfattar flera verksamheter/enheter med olika arbetsplatskoder. Vanligt förekommande exempel på vårdenhet med ingående enheter är en klinik med underliggande avdelningar, eller hemsjukvård inom en kommun med underliggande geografiska områden eller boenden.

Mer information och regelverket runt kopplade enheter finns i Ineras handbok för HSA administratörer 2.2.1

den mest specifika enheten

Vad den mest specifika enheten, där vården bedrivs, är kommer variera beroende på verksamhet.

I denna implementationsguide används begreppet “mest specifika enheten“ t.ex. i beskrivning av hur openEHRs EVENT_CONTEXT.health_care_facility ska fyllas med innehåll.

I journalsystemet Cambio Cosmic motsvaras den mest specifika enheten ofta av det som kallas “Vårdande enhet”

I många fall är det samma enhetsnivå som kallas “kopplad/ingående enhet” i denna tabells begreppsbeskrivning ovan.

vårdprocess

process avseende hälso- och sjukvård som hanterar ett eller flera relaterade hälsoproblem eller hälsotillstånd i syfte att främja ett avsett resultat

PDL-illustrationer

Bild från TietoEvry

Bild från slutrapport Patientdatalagen i praktiken (PDLiP) publicerad av Center för eHälsa i samverkan (CEHIS) 6 maj 2011. Finns uppladdad som bilaga till denna implementationsguide.

HSA-ID

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 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:

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

Lagring av PDL-relaterade grundattribut

Introduktion

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 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:

Den mest specifika enheten där vården bedrivs anges separat och används ofta som information i användargränssnitt:

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

Diagram och klassbeskrivningar

I nedanstående UML-diagram och klassbeskrivningar är viktiga delar för PDL-hanteringen markerade med gul överstrykning. Hur de används för PDL beskrivs i avsnitten efteråt.

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


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

Källa: https://specifications.openehr.org/releases/RM/latest/data_types.html#_overview_3

Dokumentation gemensam för flera vårdenheter (eller vårdgivare)

Fördjupning om health_care_facility

Fördjupning om Vårdgivare och Vårdenhet

Diskussionsfråga i remiss

I nära anslutning till remissutskicket dök två alternativa implementationsförslag upp som inte hunnit utredas i detalj:

  1. Bör vi skapa en egen svensk specialisering av arketypen Organisation som tar hand om både vårdenhet och vårdgivare på ett smidigt och vältypat sett i en och samma arketyp…

  2. …eller om man inte gör en egen arketyp (enl. punkt #1) bör vi då istället nästla en instans av “Organisation“ för Vårdgivare som “Överordnad organisation“ i Vårdenhetens instans av “Organisation”-arketypen? (Alltså så att Vårdgivar-instansen ligger “inuti” Vårdenhet-instansen istället för bredvid i hierarkin.) En fördel är att det då blir mer differentierade sökvägar och

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:

På liknande sätt kan vårdgivarens och vårdenhetens namn tekniskt sett slås upp i en versionshanterad katalog (istället för att lagras) om den som designar systemet så önskar, men vid data export samt exponering via API MÅSTE namnen kunna nås via de nedan beskrivna logiska sökvägarna.

När Vårdenhet och Vårdgivare i en COMPOSITION exponeras/exporteras så MÅSTE informationen logiskt sett ligga i två separata instanser av arketypen openEHR-EHR-CLUSTER.organisation.v0 som läggs under attributet i COMPOSITION.context → EVENT_CONTEXT.other_context. Vid tidpunkten för skapande av denna implementationsguide så är ovanstående arketyp under review, men den anses vara lämplig för det här användningsfallet.

Exempel på grundattribut

Exempelmallar (templates) finns i https://github.com/modellbibliotek/Arbetsyta-openEHR/tree/master/local i form av filerna

Värden från tabellen nedan används i efterföljande exempel. Kursiverade uppgifter i tabellen är påhittade.

Namn

Org nr
(för enskild firma = PNR)

HSA-id

Funktion

Stockholms läns sjukvårdsområde

232100-0016

SE2321000016-2GJS
(Behöver ej anges, men har angetts i ett exempel nedan)

Vårdgivare

Brandbergens vårdcentral

SE2321000016-1003

Vårdenhet (Vårdcenral)

Distriktssköterskemottagning (vid Brandbergens vårdcentral)

SE2321000016-14LF

Den mest specifika enheten

Täby Vårdcentral

SE2321000016-150H

Vårdenhet (Vårdcenral)

Namy Nursington

SE2321000016-7ABC

Distriktssköterska
(“Composer” ansvarig för journalanteckningen)

Urban Uskman

SE2321000016-1CBA

Undersköterska (medverkade)

Danderyds Sjukhus AB

556575-6169

SE2321000016-1K2W

Vårdgivare

Ortopedkliniken
(vid Danderyds Sjukhus AB)

SE2321000016-1K6Q

Vårdenhet

Ajda's Medicinska Fotvård EN

790127-1111

Vårdgivare (Enskild firma)

Ajda's Medicinska Fotvård

SE2321000016-DGM1

“Vårdenhet”

Ajda Nnamn

SE2321000016-2222

Fotvårdsterapeut

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

{
  "pdl-test-1": {
    "_uid": [
      "e34ef1a9-7994-48cd-b1e5-d7481648b8e8::stockholm.ehrscape.com::1"
    ],
    "language": [
      {
        "|code": "en",
        "|terminology": "ISO_639-1"
      }
    ],
    "territory": [
      {
        "|code": "en",
        "|terminology": "ISO_3166-1"
      }
    ],
    "context": [
      {
        "care_provider": [
          {
            "name": [
              "Stockholms läns sjukvårdsområde"
            ],
            "identifier": [
              {
                "|id": "232100-0016",
                "|type": "urn:oid:2.5.4.97"
              }
            ],
            "role": [
              {
                "|code": "1.2.752.29.6.10",
                "|value": "Vårdgivare",
                "|terminology": "urn:oid"
              }
            ]
          }
        ],
        "care_provider_subunit": [
          {
            "name": [
              "Brandbergens vårdcentral"
            ],
            "identifier": [
              {
                "|id": "SE2321000016-1003",
                "|type": "urn:oid:1.2.752.29.4.19"
              }
            ],
            "role": [
              {
                "|code": "1.2.752.29.6.13",
                "|value": "Vårdenhet",
                "|terminology": "urn:oid"
              }
            ]
          }
        ],
        "start_time": [
          "2021-12-21T01:19:46.693335+01:00"
        ],
        "setting": [
          {
            "|code": "238",
            "|value": "other care",
            "|terminology": "openehr"
          }
        ]
      }
    ],
    "pulse_heart_beat": [
      {
        "any_event": [
          {
            "rate": [
              {
                "|magnitude": 99,
                "|unit": "/min"
              }
            ],
            "time": [
              "2021-12-21T01:19:46.693335+01:00"
            ]
          }
        ],
        "method": [
          {
            "|code": "at1033",
            "|value": "Auscultation",
            "|terminology": "local"
          }
        ],
        "body_site": [
          {
            "|code": "at1038",
            "|value": "Radial Artery - Left",
            "|terminology": "local"
          }
        ],
        "language": [
          {
            "|code": "en",
            "|terminology": "ISO_639-1"
          }
        ],
        "encoding": [
          {
            "|code": "UTF-8",
            "|terminology": "IANA_character-sets"
          }
        ]
      }
    ],
    "category": [
      {
        "|code": "433",
        "|value": "event",
        "|terminology": "openehr"
      }
    ],
    "composer": [
      {
        "|name": "regionstockholm"
      }
    ]
  },
  "ctx": {
    "generic_fields": {}
  }
}

Exemplet nedan är ett manuellt redigerat (ofärdigt och overiferat) exempel som avser visa mer om composer, health_care_facility, participation samt en vårdgivare som angett ett extra HSA-id utöver det obligatoriska organisationsnumret.

{
  "ctx/language": "sv",
  "ctx/territory": "SE",
  "ctx/composer_name": "Namy Nursington", 
  [TODO: +ID?]
  "ctx/id_namespace": "HOSPITAL-NS",
  "ctx/id_scheme": "HOSPITAL-NS",
  "ctx/participation_name": "Urban Uskman",
  [TODO: +ID?]
  "ctx/participation_function": "performer",
  "ctx/participation_mode": "face-to-face communication",
  "ctx/participation_id": "198",
  "ctx/health_care_facility|name": "Distriktssköterskemottagning, Brandbergens vårdcentral",
  "ctx/health_care_facility|id": "SE2321000016-14LF",
  "pdl-test-1": {
    "context": [
      {
        "care_provider": [
          {
            "name": [
              "Stockholms läns sjukvårdsområde"
            ],
            "identifier": [
              {
                "|id": "232100-0016",
                "|type": "urn:oid:2.5.4.97"
              }
              {
                "|id": "SE2321000016-2GJS",
                "|type": "urn:oid:1.2.752.29.4.19"
              }         
            ],
            "role": [
              {
                "|code": "urn:oid:1.2.752.29.6.10",
                "|value": "Vårdgivare"
              }
            ]
          }
        ],
        "care_provider_subunit": [
          {
            "name": [
              "Brandbergens vårdcentral"
            ],
            "identifier": [
              {
                "|id": "SE2321000016-1003",
                "|type": "urn:oid:1.2.752.29.4.19"
              }
            ],
            "role": [
              {
                "|code": "1.2.752.29.6.13",
                "|value": "Vårdenhet"
              }
            ]
          }
        ]
      }
    ],
    "pulse_heart_beat": [
      {
        "any_event": [
          {
            "rate": [
              {
                "|magnitude": 112,
                "|unit": "/min"
              }
            ]
          }
        ],
        "method": [
          {
            "|code": "at1032"
          }
        ],
        "body_site": [
          {
            "|code": "at1038"
          }
        ]
      }
    ]
  }
}

Filtrering och utvärdering baserat på lagrade grundattribut

Nedanstående exempel på AQL-sökfråga söker fram alla pulsmätningar som passerar tillgångsfiltreringen baserad på vårdgivare eller vårdenhet.

SELECT org/items[at0001]/value/value AS OrgName,
       org/items[at0003]/value/id AS Orgid,
       org/items[at0004]/value/value  AS RoleType,
       org/items[at0004]/value/defining_code/code_string AS role_type_oid,
       j/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude AS Rate,
       c/uid/value as comp_id,
       e/ehr_id/value as ehr_id
FROM EHR e
CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.encounter.v1]  
CONTAINS (CLUSTER org[openEHR-EHR-CLUSTER.organisation.v0] 
    and OBSERVATION j[openEHR-EHR-OBSERVATION.pulse.v2])  

WHERE role_type_oid = "1.2.752.29.6.13" -- Exempel 1: Vårdenhet
-- WHERE role_type_oid = "1.2.752.29.6.13" AND Orgid = "SE2321000016-1003" -- Exempel 2: Vårdenhet = SE2321000016-1003 (Brandbergens VC) 

-- WHERE role_type_oid = "1.2.752.29.6.10" -- Exempel 3: Vårdgivare
-- WHERE role_type_oid = "1.2.752.29.6.10" AND Orgid = "232100-0016" -- Exempel 4: Vårdgivare = 232100-0016 (Stockholms läns sjukvårdsområde)

OFFSET 0 
LIMIT 25

Exempelsvar 1:

Exempelsvar 2:

Exempelsvar 3:

Exempelsvar 4:

I en produktionsinstallation kan man lämpligen välja att parametrisera id (sätta via variabler) för vårdgivare och vårdenhet.

Den första remissomgången slutar här och avsåg kapitlen

  • Bakgrund

  • Lagring av PDL-relaterade grundattribut

  • Filtrering och utvärdering baserat på lagrade grundattribut

Texten nedan är inte redo för extern granskning ännu men får givetvis kommenteras om intresse finns.

Spärr, hävande av spärr och undantag
[REMISSEN SLUTAR FÖRE DENNA RUBRIK]

Bakgrundsmaterial från Inera: “SAD - Spärr” samt “Användarhandbok Spärradministration”.

Information som är olämplig att spärra

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

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

Frågeformulär om läkemedelsanvändning

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

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

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

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.)

Uppmärksamhetsinformation - Socialstyrelsen - excel: https://www.socialstyrelsen.se/globalassets/sharepoint-dokument/artikelkatalog/klassifikationer-och-koder/2020-12-7122-bilaga-3.xlsx

Motsvarande refsets för de Snomed-relaterade urvalen som nämns i excel-arket:

RefSet id

Preferred Term 

Fully specified name

59841000052105

urval implantat, uppmärksamhetsinformation

 Implants, alert information reference set (foundation metadata concept)

59851000052108

urval smittämnen, uppmärksamhetsinformation

 Contagions, alert information reference set (foundation metadata concept)

59861000052106

urval transplantat, uppmärksamhetsinformation

 Transplants, alert information reference set (foundation metadata concept)

60691000052103

urval visshetsgrad, uppmärksamhetsinformation

 Degree of certainty, alert information reference set (foundation metadata concept)

59831000052104

urval behandlingar, uppmärksamhetsinformation

 Treatments, alert information reference set (foundation metadata concept)

59811000052109

urval allvarlighetsgrad, uppmärksamhetsinformation

 Degree of severity, alert information reference set (foundation metadata concept)

60661000052106

urval smittsamma sjukdomar, uppmärksamhetsinformation

 Contagious diseases, alert information reference set (foundation metadata concept)

59821000052101

urval medicinska tillstånd, uppmärksamhetsinformation

 Medical conditions, alert information reference set (foundation metadata concept)

59881000052100

urval särskilda vårdrutiner, uppmärksamhetsinformation

 Non-standard care procedures, alert information reference set (foundation metadata concept)

59871000052102

urval kemikalieöverkänsligheter, uppmärksamhetsinformation

 Hypersensitivities to chemicals, alert information reference set (foundation metadata concept)

59901000052102

urval födoämnesöverkänsligheter, uppmärksamhetsinformation

 Food hypersensitivities, alert information reference set (foundation metadata concept)

Tabellen sammanställd 2021-11-23 av Mikael nyström

Logguppföljning

Åtkomstkontrollerna ska göras systematisk och återkommande (4 kap. 3 § PDL). Hur ofta det behöver göras kan exempelvis bero på verksamhetens omfattning, antalet personer med åtkomst, hur behörigheterna delas ut och hur omfattande kontrollerna är. Det är nödvändigt att kontrollerna görs regelbundet och omfattar en så hög andel av logghändelserna att det blir en effektiv kontroll.

(ovan från: https://www.socialstyrelsen.se/regler-och-riktlinjer/foreskrifter-och-allmanna-rad/konsoliderade-foreskrifter/201640-om-journalforing-och-behandling-av-personuppgifter-i-halso--och-sjukvarden/ )

Metod

I en instruktion för vart i informationsmodellen information tillhörande en PDL-loggpost inhämtas i OpenEHR’s informationsmodell så bör loggranskarens uppgift och vilka analyser denne väntas utföra tas i beaktning.

Därtill är finns Ineras redan definierade informationsmodeller i RIV (regelverk för interoperabilitet inom vård och omsorg, rivta.se). Det är vanligt krav på ineteroperabilitet med RIV tjänstekontrakt ställs vid upphandlingar av IT-stöd i det offentliga vård-Sverige.

Dessa är de två perspektiv som beskrivs nedan.

OBSERVATION:

  1. Det ser ut att finnas ett antagande att utifrån en eller flera PDL-loggposter kunna göra åtminstone de initiala analyser som lagen kräver, utan att behöva gå in i källsystemet. Ineras beskrivning av loggpost medger inte härledning tillbaka till källinformationen. Det som anges är tidpunkt, aktivitet, resurstyp medarbetarens och patientens identitet. Spårbarhet tillbaka till källinformationen kräver manuellt arbete och därtill vara svår att fastställa.

  2. Förväntan på analyser som ska genomföras vid loggranskning kräver ingående kunskap om och direkt närhet till den aktuella verksamheten. Granskning av loggposter för PDL i med hjälp av Ineras loggtjänst kräver ytterligare informationsinhämtning enl resonemang punkt 1.

ATT UTREDA:

  1. Kan loggar beskrivet för OpenEHR uppfylla de krav som ställs för att kunna loggranska PDL enl. lag?

    1. Kan dessa loggar användas oförändrat för loggranskning för PDL (se exempel på kriterier för analys nedan)?

  2. Går det med OpenEHR loggar skapa upp PDL loggposter enl. Ineras RIV anvisningar?

    1. Behöver PDL-loggar enl. Ineras datadefinition skapas utifrån en samling mer detaljerade loggar från OpenEHR?

    2. Går det att skapa instruktioner för hur översättning av kodverk för Aktivitetstyp, Aktivitetsnivå och Resurstyp ska ske till aktiviteter och informationsmängder i OpenEHR?

    3. OM det är önskvärt att kunna gå från en PDL logg och spåra relevanta OpenEHR loggar, vilka rekommendation ska ges?

VGR Rutin för loggranskning SU

Nedan texter från VGR får agera exempel som beskriver vad en loggranskning kan innebära.

Texterna är hämtade från: https://alfresco.vgregion.se/alfresco/service/vgr/storage/node/content/8947/Loggranskning.pdf?a=false&guest=true

Behörighet

Den som har rätt att utdela behörighet har även en skyldighet att granska loggen. Respektive verksamhetschef ansvarar för granskningen av loggen för sina medarbetare. I de fall då verksamhetschef väljer att delegera handläggningen av loggranskning till annan medarbetare ska delegeringen vara dokumenteras.

Kontroll vid misstanke

Om det finns misstanke om missbruk av behörigheten till patientuppgifter ska en loggranskning genomföras. Det kan också finnas skäl att göra en granskning av loggen för en speciellt sekretess- känslig patient eller vårdtillfälle.

Loggranskning

Vid tolkning av en logg ska följande beaktas:

Kommentar: Här ges exempel där ytterligare informationsmängder utöver det som finns i loggposten behövs för att tolka loggposten, det kan handla om:

Loggranskning vid nödöppning och forcerad spärr

Exempel på granskningskriterier från SALA (Systematisk Automatisk Logg Analys)

I detta utbildningsmaterial för SALA så ges ytterligare exempel på olika granskningsförfaranden för TakeCare (bild 19-23): https://alfresco-offentlig.vgregion.se/alfresco/service/vgr/storage/node/content/workspace/SpacesStore/e4bfb070-8003-4315-a52e-92da06e29e91/Åhörarmaterial SALA 191203.pdf?a=false&guest=true

Ineras format för PDL-loggar

Inera har beskrivit loggranskningstjänster i sin referensarkitektur RIV: https://rivta.se/tkview/#/domain/informationsecurity:auditing:log.

Ineras informationsmodell får anses vara en referens på vad en PDL-loggpost bör innehålla i det enklaste fallet.

Ett antal fält refererar till Ineras kodverk, en samlingssida för dem återfinns här: https://inera.atlassian.net/wiki/spaces/KINT/pages/2648506471/Kodverk+och+urval+i+de+nationella+tj+nstekontrakten

Log

Datatyp som representerar en loggpost enligt PDL. Datatypen beskriver grundformatet för en loggpost.

Fältet logId är normalt ett UUID och ska vara globalt unikt. 

<xs:complexType name="LogType">
        <xs:annotation>
            <xs:documentation>
                Datatyp som representerar en loggpost enligt PDL. Datatypen beskriver grundformatet för en loggpost.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="logId" type="tns:Id"/>
            <xs:element name="system" type="tns:SystemType"/>
            <xs:element name="activity" type="tns:ActivityType"/>
            <xs:element name="user" type="tns:UserType"/>
            <xs:element name="resources" type="tns:ResourcesType"/>
            <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
        </xs:sequence>
    </xs:complexType>

System

Datatyp som representerar ett system i loggposten. Det system som skapar loggposten.

Kommentar: SystemId är ett HSA-ID som logiskt identifierar en vårdapplikation. Det finns här inget som kan härleda loggen tillbaka till en specifik byggsten av en vårdapplikation, exempelvis en specifikt tjänst eller en fysisk server.

<xs:complexType name="SystemType">
        <xs:annotation>
            <xs:documentation>
                Datatyp som representerar ett system i loggposten. Det system som skapar loggposten.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="systemId" type="tns:HsaId"/>
            <xs:element name="systemName" type="tns:SystemName" minOccurs="0"/>
            <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
        </xs:sequence>
    </xs:complexType>

Aktivitet

Datatyp som representerar vilken typ av aktivitet som utförts, på vilken nivå, tidpunkt samt syftet med aktiviteten.

Aktivitet är på en hög nivå, det finns inget i i Ineras datastruktur som gör det möjlighet att härleda en PDL Log till en samling systemloggar som beskriver aktiviteten i källsystemet.

Aktivitetstyp kan vara följande

läsa, skriva, signera, utskrift, vidimera, radera/makulera

Aktuellt kodverk finns här: https://inera.atlassian.net/wiki/download/attachments/3615655/Kodverk inforesursaktivitetstyp.xlsx?version=2&modificationDate=1520940201822&cacheVersion=1&api=v2

Aktivitetsnivå kan vara följande

Övergripande, Övergripande inom resurstyp, Detaljerad

Syfte kan vara följande (motsvarar medarbetareuppdragets syfte)

Vård och behandling, Administration, Kvalitetssäkring, Kvalitetsregister, Annan dokumentation enligt lag, Statistik

<xs:complexType name="ActivityType">
        <xs:annotation>
            <xs:documentation>
                Datatyp som representerar vilken typ av aktivitet som utförts, på vilken nivå, tidpunkt samt syftet med aktiviteten.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="activityType" type="tns:ActivityTypeValue"/>
            <xs:element name="activityLevel" type="tns:ActivityLevel" minOccurs="0"/>
            <xs:element name="activityArgs" type="tns:ActivityArgs" minOccurs="0"/>
            <xs:element name="startDate" type="xs:dateTime"/>
            <xs:element name="purpose" type="tns:PurposeDescription"/>
            <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
        </xs:sequence>
    </xs:complexType>

Användare

Datatyp som representerar användaren som utfört aktivitet, tillika ägare av loggpost.

Kommentar: Assignment är namnet på ett medarbetaruppdrag. det finns inget HSA-ID som identifierar det specifika medarbetareuppdraget. 

 <xs:complexType name="UserType">
        <xs:annotation>
            <xs:documentation>
                Datatyp som representerar användaren som utfört aktivitet, tillika ägare av loggpost.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="userId" type="tns:HsaId"/>
            <xs:element name="name" type="tns:UserName" minOccurs="0"/>
            <xs:element name="personId" type="tns:IIType" minOccurs="0"/>
            <xs:element name="assignment" type="tns:Assignment" minOccurs="0"/>
            <xs:element name="title" type="tns:UserTitle" minOccurs="0"/>
            <xs:element name="careProvider" type="tns:CareProviderType"/>
            <xs:element name="careUnit" type="tns:CareUnitType"/>
            <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
        </xs:sequence>
    </xs:complexType>

Resurs

Datatyp som representerar en resurs i loggposten. Det finns inte heller här utrymme för en referens där man från en PDL-log kan utan manuellt arbete att härleda till en specifik resurs i källsystemet som var aktuell.

Resurstyp

Exempel på resurstyper:

Kod

Beskrivning

dia

Inormationsmängd diagnos

dia-dia

Diagnos

dia-dia-kod

Diagnoskod

dia-dia-typ

Diagnostyp

dia-dia-dbe

Diagnosbeskrivning

dia-dia-dbe-kod

Diagnosbeskrivning kod

dia-dia-dbe-txt

Diagnosbeskrivning text

dia-dia-tid

Händelsetidpunkt

pad

Informationsmängd PADL

osv…

Finns många fler koder, aktuellt kodverk återfinns här: https://inera.atlassian.net/wiki/download/attachments/3615655/KV Informationstyp2.xlsx?version=1&modificationDate=1616135538325&cacheVersion=1&api=v2

<xs:complexType name="ResourceType">
        <xs:annotation>
            <xs:documentation>
                Datatyp som representerar en resurs i loggposten.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="resourceType" type="tns:ResourceTypeValue"/>
            <xs:element name="patient" type="tns:PatientType" minOccurs="0"/>
            <xs:element name="careProvider" type="tns:CareProviderType"/>
            <xs:element name="careUnit" type="tns:CareUnitType" minOccurs="0"/>
            <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
        </xs:sequence>
    </xs:complexType>

Patient

Datatyp som representerar en patient i en resurs.

IIType beskrivs som att det kan vara olika typer av patient id. Exempelvis personnummer, reservnummer, samordningsnummer, nationellt reservnummer. Flera förekomster av patient id kan inkluderas.

 <xs:complexType name="PatientType">
        <xs:annotation>
            <xs:documentation>
                Datatyp som representerar en patient i en resurs.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="patientId" type="tns:IIType"/>
            <xs:element name="patientName" type="tns:PatientName" minOccurs="0"/>
            <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
        </xs:sequence>
    </xs:complexType>

Vårdgivare

Datatyp som representerar en vårdgivare.

<xs:complexType name="CareProviderType">
        <xs:annotation>
            <xs:documentation>
                Datatyp som representerar en vårdgivare.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="careProviderId" type="tns:HsaId"/>
            <xs:element name="careProviderName" type="tns:CareProviderName" minOccurs="0"/>
            <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
        </xs:sequence>
    </xs:complexType>

Vårdenhet

Datatyp som representerar en vårdenhet.

<xs:complexType name="CareUnitType">
        <xs:annotation>
            <xs:documentation>
                Datatyp som representerar en vårdenhet.
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="careUnitId" type="tns:HsaId"/>
            <xs:element name="careUnitName" type="tns:CareUnitName" minOccurs="0"/>
            <xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
        </xs:sequence>
    </xs:complexType>

Framtida och relaterat arbete

Denna version av implementationsguiden (resultat av fas 1) innehåller ännu inte delar om vårdepisod/vårdprocess/hälsoärende och styrning av åtkomst baserat på det - sådant arbete kommer sannolikt påbörjas i December 2021 (fas 2) och sedan uppdateras denna implementationsguide. En tredja fas

Föra att på ett konsekvent leverantörsoberoende sätt definiera och välja ut uppmärksamhetsinformation och aktuell läkemedelsanvändning (som ofta undantas från spärr) bör gemensam svensk förvaltning av t.ex. en uppsättning AQL-frågor och terminologiurval övervägas. Förslagsvis görs detta som en del av den nationella openEHR-förvaltningen.

En separat framtida implementationsguide för arkivering av journalhandlingar bör skrivas för att underlätta PDLs krav på långsiktigt omhändertagande av journalhandlingar. En sådan guide bör åtminstone visa hur data från openEHR-baserade journalsystem arkiveras enligt svenska krav, men om tid finns får den gärna även visa hur man kan använda openEHR-baserade system och t.ex. Integration Information Model (openehr.org) för att importera/arkivera data på ett sökbart sätt även från system som inte baseras på openEHR.

Under arbetet kom vi (orelaterat till PDL) även på att https://discourse.openehr.org/t/svensk-tillampning-av-setting/1985 behövs.

Avslutning

Appendix A: Medverkande och arbetssätt

Arbetssätt

Arbetet initierades från den svenska openEHR-förvaltningen (2021-mm-dd) och har genomförts huvudsakligen via 90-minuters distansmöten på tisdagsförmiddagar.

I en första arbetsfas behandlades det som behövs för att behörighetsstyrning och åtkomst baserat på vårdenhet och vårdgivare (som är det som främst stöds i de flesta av dagens journalsystem). En stor del av detta rörde hur vårdenhet, vårdgivare m.m. lagras och sedan används för filtrering.

Första arbetsfasen innefattade även stöd för att med hjälp av arketyper och AQL definiera och välja ut uppmärksamhetsinformation och aktuell läkemedelsanvändning. Orsaken till detta är att sådan information vanligen ska undantas från spärr och därför behöver kunna särskiljas på ett konsekvent sätt.

Implementerbara och praktiskt användbara definitioner av vårdepisod/vårdprocess/hälsoärende är komplicerade och rekommendationer om vilka av openEHRs mekanismer som kan/bör rekommenderas för PDL-aspekterna av dessa tas/togs upp i andra fasen av författandet.

Rekommendationerna efter första fasen av arbetet baserades på att den nationella spärrtjänsten användes som “system of record” (master) för patientens önskemål angående spärr. En potentiell tredje fas kan omfatta de ytterligare openEHR-strukturer (samtycken, önskemål om spärr m.m.) som behövs om journalsystemet istället ska vara “system of record” (master) för patientens önskemål angående spärr och spegla aktuella önskemål via API till nationella spärrtjänsten.

Att bestämma: Ska loggning in i någon fas?

Nationell arbetsgrupp

Remiss

Appendix B: PDL-intressanta delar i openEHRs specifikationer

Exempel på dokumentation från openEHR-specifikationerna:

…

Appendix C: Saker att ev. arbeta in i andra stycken senare

Stryk vartefter det arbetats in i andra delar. Detta appendix

Exempel på vad en vårdgivare behöver uppfylla i en openEHR-baserad plattformslösning. [Källa: Region Stockholm]

….