Inera Core Implementation Guide - Local Development build (v0.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

TKB Header Metadata Mapping

TKB Header Metadata Mapping

JoL-kontrakten använder en gemensamt definierad uppsättning attribut för metadata i patientSummaryHeader i äldre tjänster, HeaderType i nyare JoL-tjänster.
I FHIR sprids motsvarande information ut över flera resurser (t.ex. Patient, Organization, kliniska resurser, Provenance, Consent) och över resursers egna metadata (meta.*).

Denna sida:

1. Visar ett samlat exempel på hur metadata hanteras i JoL-headern, även känd som patientSummaryHeader.
2. Ger en sammanfattande tabell över hur varje del av headern tas om hand i FHIR.
3. Fördjupar sedan de olika områdena (författarskap, informationsägarskap, signatur, spärr/sekretess, menprövning) i egna avsnitt.

Översikt

Denna sida beskriver hur metadata från TKB-tjänsternas header-strukturer mappas till FHIR-resurser. Tjänstekontrakt använder centraliserade header-strukturer för metadata (patientSummaryHeader i äldre tjänster, HeaderType i nyare JoL-tjänster), medan FHIR distribuerar metadata över flera element och resurser.

Exempel: komplett patientSummaryHeader (äldre tjänster)

<patientSummaryHeader>
  <!-- PatientSummaryHeaderType -->

  <!-- Lokalt dokument-id i källsystemet -->
  <documentId>
    <root>1.2.752.129.2.1.2.1</root>
    <extension>PSH-2025-11-24-0001</extension>
  </documentId>

  <!-- HSA-id för källsystemet -->
  <sourceSystemHSAId>
    <root>1.2.752.129.2.1.4.1</root>
    <extension>SE5565594230-ABCD</extension>
  </sourceSystemHSAId>

  <!-- Titel och tidpunkt för sammanställningen -->
  <documentTitle>Patientsammanfattning – vårdkontakt 2025-11-24</documentTitle>
  <documentTime>2025-11-24T14:35:00</documentTime>

  <!-- Patientens person-id -->
  <patientId>
    <root>1.2.752.129.2.1.3.1</root>
    <extension>191212121212</extension>
  </patientId>

  <!-- Tidpunkt som används vid jämförelse av spärrar/block (NPÖ) -->
  <blockComparisonTime>2025-11-24T14:35:00</blockComparisonTime>

  <!-- Indikerar om uppgifterna är godkända att visas för patienten -->
  <approvedForPatient>true</approvedForPatient>

  <!-- Lokalt vårdkontakt-id i källsystemet -->
  <careContactId>
    <root>1.2.752.129.2.1.2.1</root>
    <extension>CC-2025-11-24-0001</extension>
  </careContactId>

  <!-- Indicator för ogiltigförklarat dokument -->
  <nullified>false</nullified>
  <!-- nullifiedReason utelämnas när nullified = false -->

  <!-- LegalAuthenticatorType -->
  <legalAuthenticator>
    <signatureTime>2025-11-24T14:40:00</signatureTime>

    <!-- HSA-id för den som signerat -->
    <legalAuthenticatorHSAId>
      <root>1.2.752.129.2.1.4.1</root>
      <extension>SE2321000016-9999</extension>
    </legalAuthenticatorHSAId>

    <legalAuthenticatorName>Karin Karlsson</legalAuthenticatorName>
    <legalAuthenticatorRoleCode
        code="LÄK"
        codeSystem="1.2.752.129.2.2.1.4"
        displayName="Leg. läkare"/>

    <!-- Informationsägande vårdenhet/vårdgivare i signatursammanhang -->
    <careUnitHSAId>SE2321000016-A001</careUnitHSAId>
    <careGiverHSAId>SE2321000016-0000</careGiverHSAId>
  </legalAuthenticator>

  <!-- HealthcareProfessionalType -->
  <accountableHealthcareProfessional>
    <authorTime>2025-11-24T14:30:00</authorTime>

    <!-- HSA-id för ansvarig vårdpersonal -->
    <healthcareProfessionalHSAId>
      <root>1.2.752.129.2.1.4.1</root>
      <extension>SE2321000016-123456</extension>
    </healthcareProfessionalHSAId>

    <healthcareProfessionalName>Anna Andersson</healthcareProfessionalName>
    <healthcareProfessionalRoleCode
        code="LÄK"
        codeSystem="1.2.752.129.2.2.1.4"
        displayName="Leg. läkare"/>

    <!-- Vårdenhet (HSA-id) -->
    <healthcareProfessionalCareUnitHSAId>
      <root>1.2.752.129.2.1.4.1</root>
      <extension>SE2321000016-A001</extension>
    </healthcareProfessionalCareUnitHSAId>

    <!-- Vårdgivare (HSA-id) -->
    <healthcareProfessionalCareGiverHSAId>
      <root>1.2.752.129.2.1.4.1</root>
      <extension>SE2321000016-0000</extension>
    </healthcareProfessionalCareGiverHSAId>

    <!-- OrgUnitType -->
    <healthCareProfessionalOrgUnit>
      <orgUnitHSAId>
        <root>1.2.752.129.2.1.4.1</root>
        <extension>SE2321000016-B002</extension>
      </orgUnitHSAId>
      <orgUnitName>Vårdcentralen Centrum</orgUnitName>
      <orgUnitTelecom>+4681234567</orgUnitTelecom>
      <orgUnitEmail>vardcentralen.centrum@example.se</orgUnitEmail>
      <orgUnitAddress>Exempelgatan 1, 111 11 Stockholm</orgUnitAddress>
      <orgUnitLocation>Stockholm</orgUnitLocation>
    </healthCareProfessionalOrgUnit>
  </accountableHealthcareProfessional>
</patientSummaryHeader>

Exempel: JoL HeaderType (nyare tjänster)

<!--
    Example instance of HeaderType for JoL (Journal- och Läkemedel)
    Version: JoL Header Fältregler_v2.3
-->

<header xmlns="urn:riv:clinicalprocess:healthcond:common:headers:2"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <!-- ============================= -->
    <!-- Access Control Header section -->
    <!-- ============================= -->
    <accessControlHeader>
        <!-- Accountable healthcare provider (caregiver) -->
        <accountableHealthcareProviderId>
            <root>1.2.752.129.2.1.4.1</root>
            <extension>SE2321000016-0000</extension>
        </accountableHealthcareProviderId>

        <!-- Accountable care unit -->
        <accountableCareUnitId>
            <root>1.2.752.129.2.1.4.1</root>
            <extension>SE2321000016-A001</extension>
        </accountableCareUnitId>

        <!-- Patient identifier (personnummer) -->
        <patientId>
            <root>1.2.752.129.2.1.3.1</root>
            <extension>191212121212</extension>
        </patientId>

        <!-- Original patient ID (if applicable, e.g., before merge) -->
        <originalPatientId>
            <root>1.2.752.129.2.1.3.1</root>
            <extension>191010101010</extension>
        </originalPatientId>

        <!-- Care process identifier (local episode or workflow id) -->
        <careProcessId>
            <root>1.2.752.129.2.1.2.1</root>
            <extension>CP-20251124-001</extension>
        </careProcessId>

        <!-- Block comparison time (for access control evaluation) -->
        <blockComparisonTime>20251124143000</blockComparisonTime>

        <!-- Approved for patient access -->
        <approvedForPatient>true</approvedForPatient>
    </accessControlHeader>

    <!-- ============================= -->
    <!-- Source system identification  -->
    <!-- ============================= -->
    <sourceSystemId>
        <root>1.2.752.129.2.1.4.1</root>
        <extension>SE5565594230-ABCD</extension>
    </sourceSystemId>

    <!-- ============================= -->
    <!-- Record section                -->
    <!-- ============================= -->
    <record>
        <!-- Local record/document identifier -->
        <id>
            <root>1.2.752.129.2.1.2.1</root>
            <extension>REC-20251124-0001</extension>
        </id>

        <!-- Time when this record was created in the source system -->
        <timestamp>20251124143500</timestamp>
    </record>

    <!-- ============================= -->
    <!-- Author (responsible person)   -->
    <!-- ============================= -->
    <author>
        <id>
            <root>1.2.752.129.2.1.4.1</root>
            <extension>SE2321000016-123456</extension>
        </id>
        <name>Anna Andersson</name>
        <timestamp>20251124143000</timestamp>
        <byRole>
            <code>LÄK</code>
            <codeSystem>1.2.752.129.2.2.1.4</codeSystem>
            <displayName>Leg. läkare</displayName>
        </byRole>
        <orgUnit>
            <orgUnitId>
                <root>1.2.752.129.2.1.4.1</root>
                <extension>SE2321000016-A001</extension>
            </orgUnitId>
            <orgUnitName>Vårdcentralen Centrum</orgUnitName>
            <orgUnitTelecom>+4681234567</orgUnitTelecom>
            <orgUnitEmail>vardcentralen.centrum@example.se</orgUnitEmail>
            <orgUnitAddress>Exempelgatan 1, 111 11 Stockholm</orgUnitAddress>
        </orgUnit>
    </author>

    <!-- ============================= -->
    <!-- Signature (legal authenticator) -->
    <!-- ============================= -->
    <signature>
        <id>
            <root>1.2.752.129.2.1.4.1</root>
            <extension>SE2321000016-9999</extension>
        </id>
        <name>Karin Karlsson</name>
        <timestamp>20251124144000</timestamp>
        <byRole>
            <code>LÄK</code>
            <codeSystem>1.2.752.129.2.2.1.4</codeSystem>
            <displayName>Leg. läkare</displayName>
        </byRole>
    </signature>

</header>

Sammanfattande mapping av TKB headers till FHIR

Tabellen nedan visar var respektive del av TKB-headrarna tas om hand i FHIR-modellen. De senare avsnitten på sidan går in i detalj.

Not: De kliniska FHIR-resurserna bär endast den metadata som behövs för normal användning (identifierare, källsystem, författare, ägande organisation, säkerhetsetiketter). Full härledning, signaturer och spLiärrregler ligger i separata resurser: Provenance och Consent.

Författarskap: Resource Metadata vs Provenance

TKB Headers: accountableHealthcareProfessional och author/signature

I tjänstekontrakt uttrycks författarskap i form av:

• Vem: Ansvarig vårdpersonal (HSA-id, namn, roll)
• När: Tidpunkt för registrering/autentisering
• För vilken organisation: Vårdenhet och vårdgivare

PatientSummaryHeader (äldre): Använder accountableHealthcareProfessional och legalAuthenticator

JoL HeaderType (nyare): Strukturerar detta tydligare med:

• author = den som skapar/registrerar informationen
• signature = den som juridiskt autentiserar informationen
• accessControlHeader = informationsägare (vårdgivare/vårdenhet)

Dessa roller mappas till obligatoriska Provenance.agent-poster i FHIR.

FHIR Mapping: två parallella spår

1. Resursens egna element

Varje FHIR-resurs har inbyggda metadatafält för grundläggande spårbarhet:

Författarskap på dokumentnivå (journalanteckning som Composition):

• Composition.author → PractitionerRole
  • PractitionerRole.practitioner = personen (healthcareProfessionalHSAId)
  • PractitionerRole.organization = vårdenheten (healthcareProfessionalCareUnitHSAId)
• Composition.date = tidpunkt för dokumentation (authorTime)

Exempel (Composition):

Se Composition-patient-summary-example.json

Författarskap på innehållsresurser (Observation/Condition/Procedure etc.):

Använd respektive resursfält där det finns:

• Condition.recorder eller Condition.asserter
• Observation.performer
• Procedure.performer.actor

Exempel (Condition):

Se Condition-diagnosis-123.json

2. Provenance-resurs för fullständig härledning

För att bevara komplett TKB-header-information skapas en separat Provenance-resurs. JoL-headern tydliggör särskilt vilka roller som ska dokumenteras:

Obligatoriska Provenance.agent-roller från JoL header:

Exempel:

Se Provenance-prov-diagnosis-123.json

Nyckelskillnad mellan patientSummaryHeader och JoL header:

• PatientSummaryHeader: accountableHealthcareProfessional kombinerar author-rollen med ägarskap
• JoL HeaderType: Separerar tydligt author (skapare) från signature (autentiserare) och accessControlHeader (ägare)

Detta ger i FHIR:

• En tydligare separation av Provenance.agent-roller
• Bättre stöd för olika arbetsflöden (t.ex. transkribering där author ≠ legal authenticator)

mXDE-liknande Provenance för derivation från TKB/JoL

När FHIR-resurser inte skapas direkt i journalsystemet utan härleds från TKB/JoL-svar via en mellanliggande tjänst (t.ex. NPÖ eller en TKB-adapter), är det viktigt att skilja på:

1. Kliniskt författarskap – vem som dokumenterat och signerat uppgifterna.
2. Teknisk derivation – att FHIR-resurserna har dekomponerats ur ett källdokument/block.

IHE-profilerna för Mobile Cross-Enterprise Document Data Element Extraction (mXDE) definierar en särskild Provenance-profil (IHE.ITI.mXDE.Provenance) för just denna derivation. I korthet:

• Det finns en Provenance per dekomponerat TKB/JoL-svar.
• target pekar på alla FHIR-resurser som härletts ur svaret (Condition, Observation, Composition m.fl.).
• entity.role = source och entity.what pekar på en DocumentReference som representerar TKB/JoL-svaret.
• activity är satt till Derivation (w3c provenance-activity-type).
• policy sätts till en välkänd URI (i mXDE: urn:ihe:iti:mxde:2023:document-provenance-policy) som anger att resurserna är dekomponerade ur ett dokument.
• agent innehåller en tydlig assembler-roll (provenance-participant-type = assembler) för den tjänst (Device/Organization) som gjort TKB/JoL → FHIR-transformen.

I en svensk kontext kan detta mönster återanvändas även om infrastrukturen inte är formellt profilerad som mXDE:

• Varje TKB/JoL-header som ger upphov till FHIR-resurser får en derivations-Provenance.
• Kliniskt författarskap (author, signature, informationsägare via accessControlHeader) hanteras antingen:
  • som separata Provenance-resurser, eller
  • som ytterligare agent-poster i samma Provenance, så länge mönstret ovan (policy, activity, assembler, entity) uppfylls.

Exempel: mXDE-kompatibel Provenance för TKB-dekomposition

{
  "resourceType": "Provenance",
  "id": "prov-tkb-psh-20251124-0001",
  "meta": {
    "profile": [
      "https://profiles.ihe.net/ITI/mXDE/StructureDefinition/IHE.ITI.mXDE.Provenance"
    ]
  },
  "policy": [
    "urn:ihe:iti:mxde:2023:document-provenance-policy"
  ],
  "activity": {
    "coding": [{
      "system": "http://hl7.org/fhir/w3c-provenance-activity-type",
      "code": "Derivation",
      "display": "Derivation"
    }]
  },
  "recorded": "2025-11-24T14:35:00+01:00",
  "target": [
    { "reference": "Composition/patient-summary-20251124" },
    { "reference": "Condition/diagnosis-123" },
    { "reference": "Observation/lab-456" }
  ],
  "agent": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
        "code": "assembler",
        "display": "Assembler"
      }]
    },
    "who": {
      "reference": "Device/inera-tkb-adapter",
      "display": "Inera TKB→FHIR adapter"
    }
  }],
  "entity": [{
    "role": "source",
    "what": {
      "reference": "DocumentReference/tkb-psh-20251124-0001",
      "display": "TKB patientSummaryHeader 2025-11-24"
    }
  }]
}

Detta mönster kan kombineras med ytterligare Provenance-resurser för kliniskt författarskap:

Derivations-Provenance (mXDE-liknande):

• Beskriver att FHIR-resurserna härletts från TKB/JoL-svar
• activity = Derivation
• agent:assembler = TKB-adaptertjänsten
• entity.what = DocumentReference för TKB-svaret

Klinisk Provenance (författarskap):

• Beskriver vem som skrev/signerade/äger informationen
• agent[type=author] = ansvarig vårdpersonal
• agent[type=legal] = juridisk autentiserare
• agent[type=custodian] = informationsägande vårdgivare

Riktlinjer för författarskap

Informationsägande Vårdenhet och Vårdgivare

TKB Header-element

<healthcareProfessionalCareUnitHSAId>SE2321000016-A001</healthcareProfessionalCareUnitHSAId>
<healthcareProfessionalCareGiverHSAId>SE2321000016-0000</healthcareProfessionalCareGiverHSAId>
<legalAuthenticator>
  <signatureTime>2025-11-24T14:35:00</signatureTime>
  <careUnitHSAId>SE2321000016-A001</careUnitHSAId>
  <careGiverHSAId>SE2321000016-0000</careGiverHSAId>
</legalAuthenticator>

FHIR Mapping

Organisation-hierarki

Vårdgivare:

Se Organization-caregiver-0000.json

Vårdenhet:

Se Organization-unit-a001.json

Vårdgivare som gjort uppgifter tillgängliga

För scenarier där en vårdgivare delar information från en annan vårdgivare (t.ex. nationell sammanhållen journalföring):

Provenance med custodian:

Se Provenance-disclosure.json

Juridisk Autentisering av Journaluppgifter

TKB: legalAuthenticator

I TKB representerar legalAuthenticator den person som juridiskt autentiserar informationens korrekthet – t.ex. en läkare som undersöker en patient, dikterar en anteckning och sedan bekräftar dess riktighet genom att "signera" den (juridiskt sett). Detta är inte nödvändigtvis samma sak som en digital/kryptografisk signatur, även om de kan sammanfalla.

<legalAuthenticator>
  <signatureTime>2025-11-24T14:40:00</signatureTime>
  <legalAuthenticatorHSAId>
    <root>1.2.752.129.2.1.4.1</root>
    <extension>SE2321000016-9999</extension>
  </legalAuthenticatorHSAId>
  <legalAuthenticatorName>Karin Karlsson</legalAuthenticatorName>
  <legalAuthenticatorRoleCode
      code="LÄK"
      codeSystem="1.2.752.129.2.2.1.4"
      displayName="Leg. läkare"/>
</legalAuthenticator>

FHIR Mapping: Provenance med legal authenticator

I FHIR representeras juridisk autentisering genom en Provenance-resurs med en agent av typen legal.

JoL header-mappning:

• signature.id → Provenance.agent[type=legal].who (Practitioner)
• signature.name → Practitioner.name
• signature.timestamp → Provenance.occurred eller Provenance.signature.when
• signature.byRole → PractitionerRole.code

Om journaluppgiften även är digitalt signerad kan Provenance.signature användas, men det är inte ett krav för juridisk autentisering.

Exempel med digital signatur:

Se Provenance-prov-signed-diagnosis.json

Viktiga aspekter:

• agent.type = legal = juridiskt ansvarig för autentiseringen (OBLIGATORISK)
• occurred eller recorded = tidpunkt för den juridiska autentiseringen
• signature.when = tidpunkt för digital signering (OM digital signatur används)
• signature.who = signerande person (HSA-id) (OM digital signatur används)
• signature.onBehalfOf = vårdenhet/vårdgivare (OM digital signatur används)
• signature.data = kryptografisk signatur i Base64 (OM digital signatur används)

Not: En journalanteckning kan vara juridiskt autentiserad utan att vara digitalt signerad. Det juridiska ansvaret fastställs genom Provenance.agent[type=legal], medan Provenance.signature endast används när det faktiskt finns en kryptografisk signatur.

Spärr och Sekretess

Översikt

I FHIR vill vi stödja tre kompletterande mönster för spärr som motsvarar hur patientSummaryHeader används idag (inklusive t.ex. blockComparisonTime):

1. Spärr i producerande system
   – journalsystemet tillämpar spärrreglerna och markerar resurser med säkerhetsetiketter.

2. Spärr som domänobjekt (Consent)
   – inre och yttre spärr representeras som Consent-resurser som beskriver reglerna snarare än varje enskild resurs.

3. Mellanliggande spärrtjänst
   – t.ex. NPÖ-liknande tjänst som, utifrån patient, informationsägare, konsument och tidpunkt (t.ex. blockComparisonTime), utvärderar alla relevanta spärrar och tillfälliga hävningar och markerar om information skall anses spärrad.

De kliniska resurserna innehåller så lite spärrinformation som möjligt (säkerhetsetikett + ev. referens till Consent). Själva regelverket ligger i spärrtjänstens logik och i de Consent-resurser som den förvaltar.

Mönster 1 – Spärr i producerande system (FHIR-native)

Producenten (journalsystemet) tillämpar spärrreglerna lokalt. I FHIR-API:t syns det genom:

• att resurser märks med lämpliga security labels i meta.security, och
• att resurser vid behov refererar till en Consent som beskriver den aktuella spärren.

Exempel:

Se Condition-blocked-diagnosis.json

Här gör journalsystemet själv bedömningen att resursen inte ska lämnas ut i vissa situationer. Vilka situationer det är framgår av en Consent som beskriver spärren.

Mönster 2 – Spärrar lagrade som Consent (inre och yttre spärr)

Alla regler om inre/yttre spärr lagras som Consent. Kategorin skiljer de olika typerna:

• inner-block – spärr inom vårdgivare
• outer-block – spärr vid sammanhållen journalföring / patientöversikt

Exempel:

Se Consent-block-inner-123.json

All detaljerad information (vem som beslutat, juridiskt stöd, tidsperiod, osv.) ligger i Consent. Kliniska resurser behöver bara veta att de är spärrade och, om det behövs, vilken Consent som gäller.

Mönster 3 – Spärrtjänst/policymotor för NPÖ och liknande

En mellanliggande tjänst (NPÖ eller motsvarande) gör inga egna tolkningar av lag och policy, utan använder en spärrtjänst som utvärderar alla relevanta Consent:

Input: patient, informationsägare (vårdgivare/vårdenhet), konsumerande aktör, syfte, tidpunkt (t.ex. från blockComparisonTime i headern)

Output: om informationen ska anses spärrad eller inte, samt vilka Consent som faktiskt användes

En möjlig FHIR-nära operation:

POST /Consent/$evaluate-block

Request (exempel):

{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "patient",   "valueReference": { "reference": "Patient/191212121212" } },
    { "name": "owner",     "valueReference": { "reference": "Organization/caregiver-0000" } },
    { "name": "requester", "valueReference": { "reference": "Organization/npo-consumer-01" } },
    { "name": "purpose",   "valueCode": "npo-view" },
    { "name": "occurrence","valueDateTime": "2025-11-24T14:35:00+01:00" }
  ]
}

Svar:

{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "isBlocked",            "valueBoolean": true },
    { "name": "hasTemporaryOverride", "valueBoolean": false },
    {
      "name": "appliedConsent",
      "valueReference": { "reference": "Consent/block-outer-456" }
    }
  ]
}

Logiken i spärrtjänsten är:

• om minst en spärr (inre eller yttre) är helt applicerbar → isBlocked = true,
• om det dessutom finns minst en tillfällig hävning som gäller den aktuella aktören → isBlocked = false för det här tillfället.

Denna operation kan användas av alla konsumenter som själva inte kan eller bör tolka alla spärrregler.

Svarsmönster: Bundle + OperationOutcome när uppgifter spärras

Vid sökning i NPÖ eller liknande där vissa resurser spärras används en searchset-Bundle enligt FHIR-mönstret:

• synliga resurser som vanliga entry med search.mode = "match"
• en eller flera OperationOutcome-resurser som entry med search.mode = "outcome" för att indikera att information har filtrerats bort
• eventuellt en sammanfattande Bundle.extension som bara säger att spärrade uppgifter finns (inte exakt vad)

Mönstret med search.mode = "outcome" och issue.code = "suppressed" följer FHIR-praxis för att indikera att information filtrerats bort utan att avslöja detaljer.

{
  "resourceType": "Bundle",
  "type": "searchset",
  "total": 5,
  "entry": [
    {
      "fullUrl": "https://npo.example.se/fhir/Condition/visible-condition-1",
      "search": { "mode": "match" },
      "resource": {
        "resourceType": "Condition",
        "id": "visible-condition-1"
      }
    },
    {
      "fullUrl": "https://npo.example.se/fhir/OperationOutcome/block-info",
      "search": { "mode": "outcome" },
      "resource": {
        "resourceType": "OperationOutcome",
        "id": "block-info",
        "issue": [{
          "severity": "information",
          "code": "suppressed",
          "details": {
            "text": "Vissa uppgifter har spärrats för denna förfrågan."
          },
          "extension": [{
            "url": "https://inera.se/fhir/core/StructureDefinition/applied-consent",
            "valueReference": {
              "reference": "Consent/block-outer-456"
            }
          }]
        }]
      }
    }
  ],
  "extension": [{
    "url": "https://inera.se/fhir/core/StructureDefinition/blocked-resources-summary",
    "extension": [
      { "url": "hasBlockedResources", "valueBoolean": true },
      { "url": "blockedCount",       "valueUnsignedInt": 4 }
    ]
  }]
}

Om all information spärras kan tjänsten i stället svara med HTTP 403 och ett ensamt OperationOutcome i svaret.

Sammanfattning: representation av inre/yttre spärr

Menprövningsflaggan (Spärrflagga för Patientåtkomst)

Översikt

Menprövningsflaggan avser situationer där patientens åtkomst till sin egen information behöver begränsas, ofta tillfälligt, för att undvika skada eller missförstånd. Tekniskt är detta en särskild form av spärr där målgruppen är patienten (patientportal, nationell e-tjänst) snarare än andra vårdgivare.

Fältet approvedForPatient i patientSummaryHeader kan ses som ett grovt beslut: är denna sammanställning tänkt att vara synlig för patienten eller inte? I FHIR bryts detta ned till:

• en eller flera Consent-resurser som dokumenterar beslutet, och
• säkerhetsetiketter (meta.security) på de resurser som faktiskt inte ska exponeras för patienten.

Vi vill undvika att sprida detaljer om vem som fattat beslutet och varför som extensions på varje klinisk resurs. I stället:

• dokumenteras beslutet som en Consent, och
• kliniska resurser får en enkel säkerhetsetikett + ev. referens till denna Consent.

Canonical representation – Consent för patientåtkomst

Menprövningen dokumenteras som en Consent med en svensk kategori för "begränsa patientåtkomst" och med en tidsperiod där begränsningen gäller.

Se Consent-restrict-patient-access-123.json

Här finns alla detaljer om menprövningen samlade i en resurs som är enkel att logga, revidera och visa för behörig personal – men som inte behöver exponeras i patientportalen.

Resursnivå – säkerhetsetiketter för patientåtkomst

De kliniska resurser som omfattas av menprövning markeras med säkerhetsetiketter som patientportaler kan filtrera på:

• en standardkod som betyder "visa inte för patienten" (t.ex. NOPATIENT), och
• eventuellt en svensk kod som preciserar kontexten.

Exempel:

Se Observation-pending-cancer-diagnosis.json

En patientportal kan ha en mycket enkel regel:

• Filtrera bort alla resurser där meta.security innehåller NOPATIENT.

Om vårdgivaren behöver se varför begränsningen finns kan den länkas tillbaka till motsvarande Consent-resurs. Detaljer om vem som satt flaggan, motivering, tidsgräns osv. ligger där – inte som spridda extensions på varje klinisk resurs.

Menprövning via spärrtjänsten

Samma spärrtjänst som utvärderar inre/yttre spärr kan också hantera menprövning:

• Konsument = patientportalens klient/organisation
• Purpose = t.ex. patient-view

Tjänsten utvärderar Consent av typen restrict-patient-access och avgör om information ska döljas eller inte.

Det gör att:

• tillfälliga hävningar (t.ex. efter kliniskt samtal) kan modelleras som nya Consent-poster eller ändrad period,
• samma policylogik kan återanvändas oavsett om åtkomsten avser NPÖ, lokal journal eller patientportal.

Rekommenderat mönster för menprövning

Detta ger:

• tydlig separation mellan kliniskt innehåll, åtkomstregler och teknisk policy-utvärdering,
• minimal mängd spärrrelaterad metadata på de kliniska resurserna,
• en enhetlig modell för inre/yttre spärr och menprövningsflagga i både producent- och NPÖ-perspektiv.

Sammanfattning: Metadata-strategi

Designprinciper

Separation of Concerns

• Resurser = kliniskt innehåll + grundläggande metadata
• Provenance = fullständig härledning och juridiskt ansvar
• Consent = åtkomstkontroll och patientdirektiv

Obs: AuditEvent och loggning

Denna sida beskriver semantisk härledning (Provenance) och åtkomstregler (Consent, meta.security). Tekniska loggar av vem som anropat TKB/JoL-tjänster och NPÖ rekommenderas hanteras separat med AuditEvent (t.ex. enligt IHE Basic Audit Log Patterns). Vi försöker hålla Provenance fri från detaljer som primärt hör hemma i loggning.

Sökbarhet

• Grundläggande metadata i resursen (t.ex. recorder, performer)
• Utökad härledning via Provenance-länkar
• Security labels för snabb åtkomstkontroll

Svensk kontext

• HSA-id för organisation och personal
• Vårdgivare/vårdenhet-hierarki via Organization.partOf
• Inre/yttre spärr via Consent med svenska kategorier

Implementationsvägledning

Referenser

• FHIR Provenance Resource
• FHIR Consent Resource
• FHIR Security Labels
• IHE ITI mXDE – Mobile Cross-Enterprise Document Data Element Extraction
• IHE ITI mXDE – mXDE Provenance Profile
• IHE Basic Audit Log Patterns (BALP)
• Swedish HSA-id
• Patientdatalagen (PDL)