Version 1-PDL i openEHR
Innehåll
- 1 Innehåll
- 2 Status
- 3 Versionshistorik
- 4 Begrepp
- 5 Relaterade dokument
- 6 Bakgrund
- 7 Juridiska krav
- 8 Lagring av PDL-relaterade grundattribut
- 9 Appendix A: Medverkande och arbetssätt
- 9.1 Arbetssätt
- 9.2 Nationell arbetsgrupp
- 9.3 Remiss
- 10 Appendix B: PDL-intressanta delar i openEHRs specifikationer
Status
DEV
Versionshistorik
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 |
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 |
---|---|
kontroll av uppgiven identitet | |
stark autentisering | kontroll av uppgiven identitet på två olika sätt |
person eller personer som i sitt yrke utför hälso- och sjukvård | |
system som insamlar, bearbetar, lagrar eller distribuerar och presenterar information | |
en eller flera journalhandlingar som rör samma patient | |
statlig myndighet, region, kommun, annan juridisk person eller enskild näringsidkare som bedriver hälso- och sjukvårdsverksamhet | |
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. |
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 |
---|---|---|
| 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 i COMPOSITION.context → EVENT_CONTEXT.other_context MÅSTE göras genom att inkludera en template som motsvarar den som specificeras i denna implementationsguide. | |
| 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. | |
| COMPOSITION.context → EVENT_CONTEXT.health_care_facility FÅR INTE användas för utvärdering av åtkomst ur PDL-perspektiv. | |
| 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 |
---|---|
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:
|
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:
Exempel baserat på URI för en (påhittad) privat-klinik:
|
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):
|
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 |
|
---|---|---|
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:
|
|
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:
|
|
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:
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):
|
|
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.
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:
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.
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.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 | HSA-id | Funktion |
---|---|---|---|
Stockholms läns sjukvårdsområde | 232100-0016 | SE2321000016-2GJS | Vårdgivare |
Brandbergens vårdcentral |
| SE2321000016-1003 | Vårdenhet (Vårdcenral) |
Distriktssköterskemottagning (vid Brandbergens vårdcentral) |
| SE2321000016-14LF | |
Täby Vårdcentral |
| SE2321000016-150H | Vårdenhet (Vårdcenral) |
Beroendecentrum Stockholm |
| SE2321000016-15FL | Vårdenhet |
Namy Nursington |
| SE2321000016-7ABC | Distriktssköterska |
Urban Uskman |
| SE2321000016-1CBA | Undersköterska (medverkade) |
Danderyds Sjukhus AB | 556575-6169 | SE2321000016-1K2W | Vårdgivare |
Ortopedkliniken |
| SE2321000016-1K6Q | Vårdenhet |
Vårdavdelning 14 gynekologi |
| 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 |
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
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) ochEVENT_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
…