Innehåll

Status

DEV

Versionshistorik

Version	Datum	Uppdatering	Ansvarig

Version	Datum	Uppdatering	Ansvarig
0.1.0		Första version för internremiss
0.2.0	2021-12	Inför första remissrundan	PDL-arbetsgruppen
0.3.0 (wiki v74)	2022-02-08	Förslag till ändrad kodning av roll (från OID till samma Snomed-begrepp som svenska FHIR-profilerna planerar införa) samt ändrad hierarki (enl förslag #2 i remissens diskussionsfrågor) har markerats och alternativa skrivningar påbörjats.	PDL-arbetsgruppen via Erik Sundvall
0.4.0	2022-03-29	Ny version efter remissomgång 1	PDL-arbetsgruppen

Begrepp

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

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

Relaterade dokument

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

Relaterade dokument som hänvisas till i denna guide:

Implementationsguide: HSA-identitet och Organisationsnummer
Termer och begrepp definierade inom HSA som går att finna på Öppen info: Katalogtjänst HSA
Olika delar av openEHRs tekniska specifikationer.

Bakgrund

Denna implementationsguide har tagits fram i samarbete mellan flera vårdgivare och systemleverantörer aktiva i Sverige (se Appendix A). Implementationsguiden syftar till att beskriva hur openEHR kan användas i tillämpningen av Patientdatalagen (PDL) 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 exempelvis information som är uppmätt och registrerad av patienten själv utan initiering från hälso- och sjukvården, eller information inom SoL.

Juridiska krav

För juridiska krav se: Juridiska krav - Patientdatalagen

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.

Övergripande krav

Nedan listas alla de krav som ställs av denna implementationsguide på lagring av PDL-relaterade grundattribut.

Krav-ID	Beskrivning	Fördjupnings-avsnitt

Krav-ID	Beskrivning	Fördjupnings-avsnitt
	COMPOSITION.context → EVENT_CONTEXT.other_context MÅSTE ange vårdenhet och vårdgivare som ska användas för utvärdering av åtkomst ur PDL-perspektiv.	Lagring av vårdenhet och vårdgivare
	Lagring av vårdenhet och vårdgivare i COMPOSITION.context → EVENT_CONTEXT.other_context MÅSTE göras genom att inkludera en template som motsvarar den som specificeras i denna implementationsguide.	Template för lagring av vårdenhet och vårdgivare
	Vid tillämpning av arketypen “Care Unit” ska kraven som detaljeras i kapitlet Template för lagring av vårdenhet och vårdgivare följas.
	COMPOSITION.context → EVENT_CONTEXT.health_care_facility MÅSTE ange den mest specifika enheten där vården bedrivs, om sådan finns, annars MÅSTE vårdenhet anges.	Lagring av den mest specifika enheten
	COMPOSITION.context → EVENT_CONTEXT.health_care_facility FÅR INTE användas för utvärdering av åtkomst ur PDL-perspektiv.	Lagring av den mest specifika enheten
	Information från olika vårdenheter FÅR INTE journalföras inom ramen för samma COMPOSITION vid ett och samma tillfälle om de ur PDL-synpunkt borde ha journalförts hos olika vårdenheter.	Dokumentation gemensam för flera vårdenheter (eller vårdgivare)
	Flera ENTRY-objekt (t.ex. mätvärden) från olika vårdenheter FÅR INTE blandas i samma COMPOSITION-version om de ur PDL-synpunkt borde ha journalförts hos olika vårdenheter.	Dokumentation gemensam för flera vårdenheter (eller vårdgivare)

Fördjupning

Lagring av vårdenhet och vårdgivare

Följande attribut från openEHR är aktuella för att utvärdera åtkomst ur PDL-perspektiv:

COMPOSITION.context → EVENT_CONTEXT.other_context, konfigurerad med minst två instanser av arketypen Organisation så att “PDL-mässig” vårdenhet och vårdgivare lagras i varsitt attribut.

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. Internt FÅR detta tekniskt lösas på valfritt sätt, exempelvis genom att:

spara aktuell vårdgivare och vårdenhet vid lagringstillfället explicit i varje COMPOSITION.context → EVENT_CONTEXT.other_context, konfigurerad med två nästlade instanser av arketypen Organisation på sättet som detaljeras i efterföljande avsnitt
eller genom att teknsikt/fysiskt bara spara COMPOSITION.context → EVENT_CONTEXT.health_care_facility och utifrån detta vid behov (t.ex. vid export eller extern API-exponering) slå upp vårdgivare och vårdenhet i en versionshanterad katalog och sedan (t.ex. via en fasad) exponera/exportera detta på sättet som detaljeras nedan

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.

Template för lagring av vårdenhet och vårdgivare

När vårdenhet och vårdgivare i en COMPOSITION exponeras/exporteras så måste informationen logiskt sett ligga i nästlade instanser av arketypen openEHR-EHR-CLUSTER.organisation.v1 som läggs under attributet i COMPOSITION.context → EVENT_CONTEXT.other_context.

Organisation-arketypen används dels för vårdenhet och dels en gång till nästlad inuti vårdenheten under attributet “Överordnad organisation” för att även beskriva vårdgivaren, se bild nedan.

Templaten finns att hämta här:

Vårdenhet

Nedan listas de krav som ställs på innehållet för varje attribut i templaten.

Attribut	Krav

Attribut

Krav

Namn

(openEHR-EHR-CLUSTER.organisation.v1/items[at0001] Name)

Vårdenhetens namn (vid dokumentationstillfället) MÅSTE anges i fältet DV_TEXT.value (eftersom arketypen i dagsläget kräver detta), själva PDL-utvärderingen baseras dock endast på identifieraren, inte namnet.

Exempel:

DV_TEXT.value = Brandbergens vårdcentral

Identifierare

(openEHR-EHR-CLUSTER.organisation.v1/items[at0003] Identifier)

Om vårdenheten har ett HSA-id MÅSTE detta anges som en av identifierarna i enlighet med Implementationsguide för HSA-id och Organisationsnummer. Själva HSA-idt för vårdenheten läggs vid användning i system i referensmodellens attribut DV_IDENTIFIER.id.

Om vårdenheten inte har ett HSA-id MÅSTE vårdenheten kunna identifieras med en unik beständig identifierare.

Exempel baserat på HSA-ID för Täby Vårdcentral:

DV_IDENTIFIER.type = urn:oid:1.2.752.29.4.19 (Markör för att det id-attributet innehåller ett HSA-ID)
DV_IDENTIFIER.id = SE2321000016-150H

Exempel baserat på URI för en (påhittad) privat-klinik:

DV_IDENTIFIER.type - FÅR lämnas tom om en globalt unik identifierare (förutom HSA-ID) används.
DV_IDENTIFIER.id = http://id.dinplastik.se/ansiktsavdelningen

Roll

(openEHR-EHR-CLUSTER.organisation.v1/items[at0004] Role)

Vårdenhetens roll MÅSTE anges för att kunna identifiera vilken typ av organisation som avses.

Attributet Role (Roll) är av typen DV_CODED_TEXT, följande gäller för dess attribut (se även bild nedan):

DV_CODED_TEXT.defining_code.code_string MÅSTE sättas till 43741000 (Snomed CT begrepps-id för rollen vårdenhet)
DV_CODED_TEXT.defining_code.terminology_id MÅSTE sättas till http://snomed.info/sct/900000000000207008, dvs. SNOMED CT international edition (core module).
DV_CODED_TEXT.value BÖR sättas till Vårdenhet i en svenskspråkig journalanteckning, men FÅR INTE användas som bas för utvärdering av åtkomst enligt PDL.

Vårdgivare

Nedan listas de krav som ställs på innehållet för varje attribut i template för lagring av vårdgivare.

Attribut	Krav

Attribut

Krav

Namn

(openEHR-EHR-CLUSTER.organisation.v1/items[at0001] Name)

Vårdgivarens namn (vid dokumentationstillfället), MÅSTE anges i fältet DV_TEXT.value (eftersom arketypen i dagsläget kräver detta), själva PDL-utvärderingen baseras dock endast på identifieraren, inte på namnet.

Exempel:

DV_TEXT.value = Region Östergötland

Identifierare

(openEHR-EHR-CLUSTER.organisation.v1/items[at0003] Identifier)

Organisationsnummer MÅSTE anges som en av vårdgivarens identifierare i enlighet med Implementationsguide för HSA-id och Organisationsnummer. Själva organisationsnumret läggs då vid användning i fältet DV_IDENTIFIER.id.

Om vårdgivaren har ett HSA-id eller annan relevant identifierare BÖR detta anges som ytterligare identifierare utöver det obligatoriska organisationsnumret.

Exempel på organisationsnummer:

DV_IDENTIFIER.type = urn:oid:2.5.4.97 (Markör för att det id-attributet innehåller ett svenskt organisationsnummer enligt SKV 709)
DV_IDENTIFIER.id = 232100-0040

OM Tillägg 2023-07-19 genomförs så ska denna rad läggas till för organisationsnummer och (det kursiverade i) ovanstående “Identifierare“-rad ska då ändras till att endast gälla HSA-id eller eventuella andra identifierare som inte är Organisationsnummer.

Organisationsnummer

(openEHR-EHR-CLUSTER.organisation.v1/items[at0003] Organisational number)

Organisationsnummer MÅSTE anges som en av vårdgivarens identifierare i enlighet med Implementationsguide för HSA-id och Organisationsnummer. Själva organisationsnumret läggs då vid användning i fältet DV_IDENTIFIER.id.

Exempel på organisationsnummer:

DV_IDENTIFIER.type = urn:oid:2.5.4.97 (Markör för att det id-attributet innehåller ett svenskt organisationsnummer enligt SKV 709)
DV_IDENTIFIER.id = 232100-0040

OM ändringen införs så blir strukturen så här:

Roll

(openEHR-EHR-CLUSTER.organisation.v1/items[at0004] Role)

Vårdgivarens roll MÅSTE anges för att kunna identifiera vilken typ av organisation som avses.

Attributet Role (Roll) är av typen DV_CODED_TEXT, följande gäller för dess attribut (se även bild nedan):

DV_CODED_TEXT.defining_code.code_string MÅSTE sättas till 143591000052106 (Snomed CT begrepps-id för rollen vårdgivare).
DV_CODED_TEXT.defining_code.terminology_id MÅSTE sättas till http://snomed.info/sct/45991000052106, dvs. SNOMED CT Sweden NRC maintained module.
DV_CODED_TEXT.value BÖR sättas till Vårdgivare i en svenskspråkig journalanteckning, men FÅR INTE användas som bas för utvärdering av åtkomst enligt PDL.

Lagring av den mest specifika enheten

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

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, 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.
- Exempel: Distriktssköterskemottagning vid Brandbergens vårdcentral, med HSA-id SE2321000016-14LF
COMPOSITION.context → EVENT_CONTEXT.health_care_facility är av typen PARTY_IDENTIFIED, för detta attribut gäller:
- Normalfall: En identifierare 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 i enlighet med Implementationsguide för HSA-id och Organisationsnummer. Om enheten har ett eget HSA-id MÅSTE detta anges som en av identifierarna. Om HSA-id saknas för den egna enheten eller vårdenhet som den ingår i, men ändå ett organisationsnummer finns så MÅSTE organisationsnummer anges som en av identifierarna (se specialfall nedan)
- Specialfall: Undantaget är de fall (t.ex. vissa riktigt små verksamheter) som inte har HSA-idn eller vårdavdelningar, i det fallet FÅR den minsta enheten vara själva vårdgivaren, i dessa fall MÅSTE istället vårdgivarens organisationsnummer finnas i PARTY_IDENTIFIED.identifiers i 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å 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.
  - Eftersom health_care_facility ofta används som läsbart namn i användargränssnitt rekommenderar vi att mer information än den mest specifika enhetens interna katalognamn anges utifall detta är otydligt. Om det t.ex. står bara "Distriktssköterskemottagning" i HSA-katalogen så rekommenderar vi något mer beskrivande som "Distriktssköterskemottagning, Brandbergens vårdcentral".

Diagram och klassbeskrivningar

I nedanstående UML-diagram och klassbeskrivningar är viktiga delar för PDL-hanteringen markerade med gul överstrykning.

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: Data Types 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)

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

Exempel på grundattribut och mallar/templates

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

care_unit.t.json - En “cluster”-template för Vårdenhet inklusive Vårdgivare som “Parent organisation”, baserad på två nästlade instanser av arketypen “Organisation”)
PDL-test-1.t.json - Ett sammansatt litet exempel med en “composition“-arketyp för pulsmätning som även inkluderar ovanstående “care_unit.t.json”-template)

Tillägg 2023-07-19: @Iago Corbaland @Erik Sundvall had a meeting based on Cambio’s and Karolinska’s implementation experiences and are suggesting an updated version (v2) of the care unit template. We suggest specific names for identifier node level siblings when both orgnaisation number and HSA-id of a care provider are used at the same time. (In openEHR data, node-level siblings with the same at-code must have different names/labels to avoid collision.) Some testing remains to be done before changing the template from alpha status to release-candidate status. This PDL implementation guide (both text and examples) will need to be ajusted. An example tempate is available in https://github.com/modellbibliotek/CKM-mirror/blob/pdl-test/local/pdl/Care%20unit%20v2.t.json The change (addition of a new node) is highlighted in light blue below:

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

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)
Beroendecentrum Stockholm		SE2321000016-15FL	Vårdenhet
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
Vårdavdelning 14 gynekologi (vid Danderyds Sjukhus AB)		SE2321000016-1K54	Vårdenhet
Annas Medicinska Fotvård EN	790127-1111		Vårdgivare (Enskild firma)
Annas Medicinska Fotvård		SE2321000016-DGM2	“Vårdenhet”
Anna Nnamn		SE2321000016-2222	Fotvårdsterapeut

PDL-fälten (Vårdgivare+Vårdenhet) visas i ovanstående experiment som ändringsbara av slutanvändaren, men kommer normalt sett sättas av systemet baserat på inloggad användare och inte vara ändringsbara. I många användningsfall kommer de fälten vara dolda och inte ens visas för slutanvändaren.

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 samt tillägget 2023-07-19 genomförs

OLD INVALID EXAMPLE!!!
{
  "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.

Behöver uppdateras om strukturändringsförslaget 2022-02-08 samt tillägget 2023-07-19 genomförs

OLD INVALID EXAMPLE!!!
{
  "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"
          }
        ]
      }
    ]
  }
}

Appendix A: Medverkande och arbetssätt

Arbetssätt

Arbetet initierades från den svenska openEHR-förvaltningen under 2021 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:

Delar av https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html
- Kap 7 “Security and Confidentiality”
- Om COMPOSITIONs och dess hantering
  - Avsnitt 4.2.4 + 4.3.* i EHR Information Model (openehr.org)
  - Kap 5 i EHR Information Model (openehr.org) notera t.ex. attributen COMPOSITION.composer (avsnitt 5.2.2) och EVENT_CONTEXT.health_care_facility (avsnitt 5.2.3.5)
Delar av https://specifications.openehr.org/releases/RM/Release-1.1.0/common.html t.ex.
- Lagring av inloggad användare i VERSION.(commit_)audit.committer se VERSION-klassen (avsnitt 6.5.2 m.m.) och AUDIT_DETAILS-klassen (avsnitt 4.36)
- 4.3.5 PARTICIPATION
- 4.3.1. PARTY_PROXY
Delar av https://specifications.openehr.org/releases/BASE/latest/base_types.html Här kanske HSA-ID kan landa? Se t.ex.
- 5.4.14. OBJECT_REF
- 5.4.15. PARTY_REF

…

openEHR Sweden

Version 1-PDL i openEHR