Innehåll

Status

DEV

Versionshistorik

...

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.

...

...

...

• 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.identifiersi enlighet med Implementationsguide för HSA-id och Organisationsnummer

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

  • Namnet på 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".

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

...