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.
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. | |
| COMPOSITION.context → EVENT_CONTEXT.other_context MÅSTE innehålla template … |
|
| COMPOSITION.context → EVENT_CONTEXT.health_care_facility BÖR 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) |
| COMPOSITION.context → EVENT_CONTEXT.health_care_facility som anger den specifika enheten MÅSTE ha en identifierare angiven som ett element i listan PARTY_IDENTIFIED.identifiers. |
|
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 (träd). Detta beskrivs mer detaljerat i stycket Fördjupning om Vårdgivare och Vårdenhet 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 (se bild med tabell ovan) 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)
Detta krav kan komma att breddas i senare version med instruktioner om internationella vårdgivare etc.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 (t.ex. ett mer mänskligt läsbart alias) som "Distriktssköterskemottagning, Brandbergens vårdcentral".
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:
COMPOSITION.composer som MÅSTE ange dokumentets författare, som ansvarar för innehållet kliniskt (t.ex. en läkare) och kan vara annan än den den inloggade användare (t.ex. vårdaministratör) som i praktiken faktiskt lagrar det.
EVENT_CONTEXT.location beskriver en fysisk plats, t.ex. ett visst rum, operationssal - inte en organisatorisk enhet. Detta frivilliga fält FÅR användas och kan vara av intresse exempelvis vid smittspårning eller annan uppföljning, men är alltså inte relevant för åtkomstkontroll enligt PDL.
Teknisk information: För varje uppdatering av en COMPOSITION som görs MÅSTE info om inloggad användare (vanligen användarnamn) sparas i attributet VERSION.commit_audit → AUDIT_DETAILS.committer
Elektronisk (kryptografisk) signering av journalanteckning FÅR göras, vid behov, på versionshanterad COMPOSITION-nivå via ORIGINAL_VERSION.attestations som beskrivs i openEHRs “Change Control Package“. I svenska journalsystem görs sällan sådan kryptografisk signering idag, utan snarare signeringsmarkering realiserad via ett ja/nej i en databas.
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.
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. (Vårdepisod etc. utreds i implementationsguiden .)
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).
Fördjupning om Vårdgivare och Vårdenhet
Det MÅSTE gå att ta reda på hos vilken Vårdenhet och Vårdgivare en COMPOSITION skapades (avseende PDL-tillämpning). Implementationsguiden styr/begränsar inte hur Vårdenhet och Vårdgivare enligt HSA sparas och tillämpas inuti ett enskilt openEHR-baserat system utan beskriver istället via vilka logiska sökvägar i en COMPOSITION informationen om vårdgivare/vårdenhet MÅSTE kunna nås om den exporteras (t.ex. bulkexport vid systembyte eller arkivering) eller om den exponeras via API till externa system (t.ex. via anropen /ehr/{ehr_id}/composition eller /query/... i openEHRs officiella REST-API. Internt FÅR detta tekniskt lösas på valfritt sätt, exempelvis genom att:
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 nedan
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.
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.v0 som läggs under attributet i COMPOSITION.context → EVENT_CONTEXT.other_context. Vid tidpunkten för skapande av denna implementationsguide så pågår internationell review av organisation-arketypen, men den anses vara lämplig för det här användningsfallet. Den senaste svenska översättningen ligger i en “branch” på
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.
Vårdenhet
Vårdenhetens identifierare: Om vårdenheten har ett HSA-id MÅSTE detta anges som en av identifierarna på sökvägen openEHR-EHR-CLUSTER.organisation.v0/items[at0003] Identifier (Identifierare) i enlighet med Implementationsguide för HSA-id och Organisationsnummer. Själva HSA-idt för vårdenheten, t.ex. SE2321000040-4JVV för Medicinska specialistkliniken, läggs vid användning i system i referensmodellens attribut DV_IDENTIFIER.id (som inte syns i skärmbilden nedan).
Om HSA-id för vårdenheten saknas så MÅSTE vårdenheten kunna identifieras med en (globalt?) unik beständig identifierare (på sökvägen angiven ovan) och även DV_IDENTIFIER.type MÅSTE anges (alltså inte vara tom) samt vara skild från identitetstypen som anges för HSA-id i Implementationsguide för HSA-id och Organisationsnummer.
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 - Lämnas tom om en globalt unik identifierare (förutom HSA-ID) används.
- DV_IDENTIFIER.id = http://id.dinplastik.se/ansiktsavdelningen
Om det finns flera vårdenheter hos hos vårdgivaren så måste vårdenheterna alltså identifieras på ett sätt som gör att de kan skiljas åt.
Detta krav kan komma att ändras i senare version med instruktioner om internationella vårdgivare etc.Vårdenhetens namn (vid dokumentationstillfället), t.ex. Brandbergens vårdcentral MÅSTE anges i openEHR-EHR-CLUSTER.organisation.v0/items[at0001] Name (Namn) 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.
Att det är just rollen vårdenhet som avses MÅSTE visas genom att via sökvägen openEHR-EHR-CLUSTER.organisation.v0/items[at0004] Role (Roll)
Role (Roll) är av typen DV_CODED_TEXT, följande gäller dess attribut
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 … , 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 (använd Snomed CT begrepps-id istället)
Vårdgivare
Vårdgivarens identifierare: Vårdgivare MÅSTE identifieras med Organisationsnummer på sökvägen openEHR-EHR-CLUSTER.organisation.v0/items[at0003] Identifier (Identifierare) i enlighet med Implementationsguide för HSA-id och Organisationsnummer. Själva organisationsnumret, t.ex. 232100-0040 för Region Östergötland, läggs då vid användning i fältet DV_IDENTIFIER.id (som inte syns i template-skärmbilden nedan).
Detta krav kan komma att breddas i senare version med instruktioner om internationella vårdgivare etc.Vårdgivarens HSA-id eller andra relevanta identifierare BÖR också anges som ytterligare identifierare (utöver det obligatoriska organisationsnumret beskrivet ovan) på sökvägen openEHR-EHR-CLUSTER.organisation.v0/items[at0003] Identifier (Identifierare)
Vårdgivarens namn (vid dokumentationstillfället), t.ex. Region Östergötland, MÅSTE anges i openEHR-EHR-CLUSTER.organisation.v0/items[at0001] Name (Namn) i fältet DV_TEXT.value (eftersom arketypen i dagsläget kräver detta), själva PDL-utvärderingen MÅSTE dock baseras endast på identifieraren, inte på namnet.
Att det är just rollen vårdgivare som avses MÅSTE visas genom att via sökvägen openEHR-EHR-CLUSTER.organisation.v0/items[at0004] Role (Roll),
Role (Roll) är av typen DV_CODED_TEXT, följande gäller dess attribut
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 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.
Exempel på grundattribut och mallar/templates
Exempelmallar (templates) finns i 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)
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 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 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"
}
]
}
]
}
}
Filtrering och utvärdering baserat på lagrade grundattribut och spärrar
Bakgrundsmaterial från Inera om spärrtjänster: “SAD - Spärr” samt “Användarhandbok Spärradministration”.
Tabellen nedan och dess ID/radnummer används för att klargöra de omfång som olika AQL-frågor gäller. (Se bakgrundskapitlet för mer information om omfång och spärrar.)
ID | Förutsättningar på att öka omfång | Exempel på fråga |
|---|---|---|
00 | Information ej kräver aktivt val | Finns dokument för patienten där vårdenhet är samma som användarens vårdenhet? |
01 | Aktivt val för att få se vart ytterligare ospärrad information finns inom vårdgivaren | Finns det för patienten ospärrade vårdenheter med dokument inom vårdgivaren, där vårdenheten inte är användarens vårdenhet men vårdgivaren är användarens vårdgivare? |
02 | Aktivt val för att visa information inom vårdgivaren | Vilka dokument finns baserat på ett urval av ospärrade vårdenheter, där vårdgivaren är användarens vårdgivare? |
03 | Aktivt val för att få se att det finns spärrad information inom vårdgivaren | Finns det för patienten spärrade vårdenheter med dokument inom vårdgivaren, där vårdenheten inte är användarens vårdenhet men vårdgivaren är användarens vårdgivare? |
04 |
| N/A |
05 | Aktivt val att visa vald spärrad information inom vårdgivaren | Vilka dokument finns baserat på ett urval av spärrade vårdenheter, där vårdgivaren är användarens vårdgivare? |
06 | Aktivt val för att få se att det finns ospärrade uppgifter hos annan vårdgivare | Finns det för patienten ospärrade vårdenheter med dokument inom en vårdgivare, där vårdgivaren inte är användarens vårdgivare? |
07 | Kontroll att Samtycke till Sammanhållen Journalföring existerar för patient. Om detta ej finns så måste ett samtycke inhämtas och registreras för patienten. | N/A |
08 | Aktivt val för att visa valda ospärrade uppgifter inom annan vårdgivare | Vilka dokument finns baserat på ett urval av ospärrade vårdenheter hos annan vårdgivare? |
09 | Aktivt val att visa hos vilka andra vårdgivare det finns spärrade uppgifter för en patient | Finns det för patienten spärrade vårdenheter med dokument inom en vårdgivare, där vårdgivaren inte är användarens vårdgivare? |
10 | Registrera att vårdapplikationen har visat vilka vårdgivare som har spärrad information för patienten vid rådande nödsituation. Det krävs även ett aktivt samtycke för att visa vårdenheter hos en annan vårdgivare. | N/A |
11 | Kontakt behöver tas och den andra vårdgivaren kan, efter egen bedömning, välja att häva spärren tillfälligt. Försök att hämta informationen kan då göras på nytt | N/A |
12 | Passera samtycke till sammanhållen journalföring på grund av rådande nödsituation | N/A |
13 | Sammanslagning av 00, 01, 03, 06, 09 | Hämta alla vårdenheter där patienten har dokument, segmentera dessa vårdenheter enligt VE, VG, SJF utifrån användarens medarbetareuppdrag. Varje vårdenhet behöver annoteras med om den är spärrad eller ej. |
14 | Sammanslagning/förenkling av 00, 02, 05, 08 | Vilka dokument finns baserat på ett urval av vårdenheter? |
AQL-fråga och svar behöver uppdateras om strukturändringsförslaget 2022-02-08 genomförs
Sammanhang och förutsättningar
samtycke/nödsituation finns om frågan gäller att läsa innehåll i jourjalanteckning ELLER
systemet vill lista antal dokument på en vårdenhet/vårdgivare om frågan gäller att kolla förekomst eller räkna (ospärrade) anteckningar
Vi beskiver inte engegemansindex här… utan tittar främst på en enskild CDR (jfr VGRs bild och funktion) där det kan finnas data från flera vårdgivare (dock sannolikt långt ifrån alla som har info om denna patient)
Spärrtjänst anropas - det man får som svar är en lista på HSAIDn som representerar spärrade enheter och vårdgivare samt typ av spärr (inre resp yttre spärr)
informationCareUnitId | HsaId | Anger HSA-id för den vårdenhet som informationen tillhör. Anges ej för yttre spärrar. | 0..1 |
informationCareProviderId | HsaId | Anger HSA-id för den vårdgivare som informationen tillhör. | 1 |
blockType | BlockTypeType
| Enumerationsvärde som anger om spärren är en inre (inom vårdenhet) eller yttre (inom vårdgivare). | 1 |
Värdemängd för BlockTypeType
"Inner" | Representerar en inre spärr (inom vårdenhet). |
"Outer" | Representerar en yttre spärr (inom vårdgivare). |
Den inre spärren (för en vårdenhet) blir automatiskt även en yttre spärr
https://rivta.se/tkview/#/domain/informationsecurity:authorization:blocking
Konstruera lista till AQL-filtrering och till GUI som listar spärrlista
Vårdgivare 1 AND (ev inkluderade vårdenheter hos vg1 BUT NOT exkluderade vårdenheter hos vg1 )
OR
Vårdgivare 2 AND (ev inkluderade vårdenhet hos vg2 BUT NOT exkluderade vårdenheter hos vg2)
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.
Förprocessning
Spärrtjänsten returnerar (informationCareUnitId, informationCareProviderId, blockType)
Förprocessning av svar från spärrttjänsten krävs för att välja ut vilka enheter i denna CDR som är spärrade
Variabler/variabellistor som kommer ut ur förprocessning
care_unit_of_user - HSA-ID
care_provider_of_user - Organisationsnummer
Lista:
externally_blocked_care_providers* används för processning av yttre spärrar av hel vårdgivare.Lista:
blocked_care_unitsanvänds för inre (och automatiskt även yttre) spärrar av enskilda vårdenheter.
Notera att varken care_unit_of_user eller care_provider_of_user får finnas i spärrlistorna efter förprocessningen, om de är listade av spärrtjänsten måste de alltså tas bort ur listan innan den infogas i AQL-frågan.
*) omvandlad till organisationsnummer (kan ha varit HSA-ID som input från tjänsten)
Varning: Den förenklade (relativt effektiva) lösningen nedan förutsätter att blocked_care_unit är globalt unik, alltså att exakt samma vårdenhets-id inte får finnas hos mer än en vårdgivare. Om man t.ex. använder HSA-ID så stämmer detta automatiskt. Om det inte är unikt behöver någon annan typ av filtrering läggas till, t.ex. en mer avancerad AQL-fråga eller efterprocessning.
TODO: Sannolikt kommer vi ändra text i tidigare avsnitt och kräva globalt unika vårdenhets-id
En öppen fråga som letar pulsmätningar över 10 slag/minut utan PDL-koll alls, visar den totala mängden matchande exempel i testdatabasen:
Om patienten inte har några spärrar alls så motsvarar detta fall 02, där allt hos vårdgivaren “Stockholms läns sjukvårdsområde“ listas:
SELECT obs/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude AS pulse_rate,
cu/items[at0001]/value AS cu_name,
cu/items[at0003]/value AS cu_id,
cu/items[at0004]/value/defining_code/code_string AS cu_role,
cp/items[at0001]/value AS cp_name,
cp/items[at0003]/value AS cp_id,
cp/items[at0004]/value/defining_code/code_string AS cp_role
FROM EHR e
CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.encounter.v1]
CONTAINS (
OBSERVATION obs[openEHR-EHR-OBSERVATION.pulse.v2] -- exempel på klinisk data
AND
CLUSTER cu[openEHR-EHR-CLUSTER.organisation.v0] -- Vårdenhet (cu)
CONTAINS CLUSTER cp[openEHR-EHR-CLUSTER.organisation.v0] -- vårdgivare (cp) nästlad som "parent organisation"
)
WHERE pulse_rate > 10 -- exempel på kliniskt villkor för dataurval
AND
(cp_role = "143591000052106" AND cp/items[at0003]/value/id = "232100-0016" ) -- vårdgivarfilter
OFFSET 0 LIMIT 10Vilket ger nedanstående svar, där vi även har valt detaljerad vy i frågeverktygets gränssnitt för att även visa identifierarnes typ:
Fall 00: …och om “vårdenhetsfiltret” också läggs till och sätts till “Brandbergens vårdcentral“ så ser “WHERE” delen av frågan ut så här…
…vilket ger följande urval:
och samma resultat i verktygets “raw”-format