Inera Core Implementation Guide
0.2.0 - ci-build Sweden

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

TGP (Tillg??nglig Patient) Architecture

Tillgänglig patient (TGP) i FHIR/SMART-baserad arkitektur

Syfte och målbild

Funktionen Tillgänglig patient (TGP) ska bidra till att:

  • vårdpersonal bara kan ta del av uppgifter via sammanhållen journalföring om patienten redan har en journal hos den egna vårdgivaren/vårdenheten, och
  • det går att i efterhand visa att denna kontroll gjordes vid varje åtkomstförsök (loggbarhet/bevisbarhet).

I en modern FHIR/SMART-baserad arkitektur vill vi uppnå samma integritetsstärkande effekt som dagens TGP, men:

  • utan att vara beroende av ett nationellt, centralt index om det inte behövs, och
  • med möjlighet att använda etablerade mekanismer som OAuth2 / OpenID Connect / SMART on FHIR för att bära TGP-beslutet.

Detta avsnitt beskriver två arkitekturalternativ:

  1. Alternativ 1 – NPÖ som SMART-app (implicit TGP)
  2. Alternativ 2 – NPÖ/FHIR-hub med separat TGP-API och token-claim

Detaljer kring loggning (AuditEvent), juridik och PDL ligger utanför denna sida och tas upp i särskilda vägledningar.

Alternativ 1 – NPÖ som SMART-app (implicit TGP)

I detta alternativ ses NPÖ (eller motsvarande sammanhållen visning) som en SMART-app som startas direkt från det lokala journalsystemet. Idén är:

Om användaren redan har öppnat en journal för patienten i EHR:et, så är kravet ”tillgänglig patient” uppfyllt.
EHR:et intygar detta genom att ge NPÖ ett access-token med patientkontext.

Grundidé

  • Ingen central lista/index över patient–vårdgivare-relationer behövs.
  • Det lokala EHR:et (eller dess Authz-server) ansvarar för:
    • att bara ge NPÖ startknapp/token om patienten har en lokal journal,
    • att logga TGP-beslutet lokalt,
    • att sätta rätt patientkontext i SMART-token (launch/patient, patient-claim).
  • NPÖ/FHIR-hub förlitar sig på att ett giltigt token med patientkontext inte kan uppstå utan att TGP-kriteriet är uppfyllt.

Flöde (översikt)

  1. Vårdanvändaren öppnar en patientjournal i EHR hos vårdgivare X.
  2. Användaren klickar på “Öppna NPÖ” i EHR:et.
  3. EHR:ets Authz-server:
    • verifierar behörighet,
    • kontrollerar (implicit) att patienten har journal hos X (detta är redan ett krav för att journalvyn ska vara öppen),
    • loggar detta lokalt (t.ex. AuditEvent),
    • utfärdar ett SMART/OAuth-token till NPÖ med:
      • patient = <lokalt patient-id eller personnummer>
      • tenant / organization = HSA-id för vårdenhet/vårdgivare
      • scopes t.ex. patient/*.rs.
  4. NPÖ startas i rätt patientkontext och gör därefter sina FHIR-anrop mot andra vårdgivare, med egna spärr- och samtyckeskontroller.

PlantUML – Sekvensdiagram (NPÖ som SMART-app)

```plantuml @startuml title TGP via SMART EHR Launch (NPÖ som app)

actor "Vårdanvändare" as User participant "Lokalt journalsystem\n(EHR + Authz Server)" as EHR participant "NPÖ-klient\n(SMART-app)" as NPO participant "NPÖ/FHIR-hub\n(FHIR + spärr/Consent)" as Hub participant "Andra vårdgivare\n(FHIR/TKB-källor)" as Sources

User -> EHR : Öppna patientjournal (P)\n(lokal behörighetskontroll) activate EHR

User -> EHR : Klicka 'Öppna NPÖ' EHR -> EHR : Kontrollera att P har journal\n(TGP-krav uppfyllt lokalt) EHR -> EHR : Logga TGP-beslut\n(AuditEvent lokalt)

EHR -> NPO : Starta SMART-app\n(OIDC auth + token med patient=P,\n tenant=Vårdenhet X) deactivate EHR

activate NPO NPO -> Hub : FHIR-anrop för P\n(inkl. token från EHR) activate Hub

Hub -> Hub : Kontrollera egna policyer\n(spärr, samtycke, loggning) Hub -> Sources : Hämta journaluppgifter för P\n(via FHIR/TKB-adaptrar) Sources –> Hub : Kliniska data (FHIR/TKB) Hub –> NPO : Resultat (FHIR Bundle)

deactivate Hub NPO –> User : Visa NPÖ-data för P deactivate NPO

@enduml

F�rdelar

  • Stark integritetsmodell utan centralt index relationen bevisas genom att NP� bara kan startas fr�n en aktiv patientjournal.
  • TGP-integriteten ligger d�r sanningen finns: i det lokala EHR:et.
  • Genomt�nkt utnyttjande av etablerade SMART-mekanismer (patientkontext, scopes).

Nackdelar / Begr�nsningar

  • Fungerar b�st om NP� alltid startas fr�n journalsystemet (EHR Launch). Frist�ende NP�-inloggning med "skriv in personnummer" blir sv�rare att f�rena med samma TGP-garanti.
  • Kr�ver att alla EHR:er exponerar ett SMART-kompatibelt launch-fl�de.

Alternativ 2 NP�/FHIR-hub med separat TGP-API och token-claim

I detta alternativ finns en separat TGP-komponent per v�rdgivare, men utan centralt index. NP�/FHIR-hub:

  • �r inte n�dv�ndigtvis en SMART-app,
  • kan anropas fr�n olika klienter (regional portal, frist�ende NP�, etc.),
  • anv�nder en TGP-tj�nst eller TGP-forward f�r att verifiera patientrelation innan sammanh�llen journalf�ring sker.

Grundid�

Varje v�rdgivare exponerar antingen:

  • en TGP-API (t.ex. REST/FHIR) som NP�/FHIR-hub kan fr�ga, eller
  • en lokal auth-komponent som ger ett token-claim tgp=true f�r given patient.

NP�/FHIR-hub kr�ver att:

  • antingen ett TGP-claim finns i tokenet, eller
  • ett positivt svar fr�n TGP-API erh�lls,

innan den sl�pper igenom anrop mot andra v�rdgivare.

Loggning kan ske b�de i TGP-komponenten och i NP�/FHIR-hub.

Fl�desvarianter

Det finns tv� n�rliggande varianter:

Token-baserat (TGP som claim)

  • Inloggning/�tkomst till NP� sker via en IdP/Access Gateway som f�rst anropar lokal TGP-tj�nst.
  • Om TGP s�ger JA f�r patient P hos v�rdenhet X ges ett token med t.ex.:
    • tgp=true
    • tgp_patient=<personnummer>
    • tgp_organization=<HSA-id>.
  • NP�/FHIR-hub kontrollerar att claim finns innan den g�r vidare.

API-baserat (NP� anropar TGP direkt)

  • NP�/FHIR-hub tar emot anv�ndarens f�rfr�gan om patient P.
  • Hubben anropar TGP-API hos v�rdgivarens TGP-komponent:
    GET /tgp?patientId=P&careUnit=X
  • Vid JA loggas beslutet och NP� forts�tter med sp�rr/Consent-kedjan.
  • Vid NEJ stoppas anropet, och anv�ndaren f�r ett meddelande om att patienten inte �r tillg�nglig.

PlantUML �versikt (API-baserad variant)

``plantuml @startuml title TGP med separat TGP-API och token-claim

actor "V�rdanv�ndare" as User participant "Klient\n(NP� UI / Portal)" as Client participant "NP�/FHIR-hub" as Hub participant "TGP-tj�nst\nhos v�rdgivare X" as TGP participant "Auth/IdP\n(v�rdgivare X)" as IdP participant "Andra v�rdgivare\n(FHIR/TKB-k�llor)" as Sources

User -> Client : Logga in och v�lj patient P Client -> Hub : F�rfr�gan om NP�-data f�r P

activate Hub Hub -> IdP : Verifiera anv�ndare & v�rdgivare IdP –> Hub : JWT/OAuth-token\n(ev. med tgp-claim=false/ej satt)

' Steg 1: Kontrollera TGP Hub -> TGP : Kontrollera 'Tillg�nglig patient'\n(P, v�rdgivare/v�rdenhet X) activate TGP TGP -> TGP : Kontroll i lokalt journalsystem\n(finns journal/relation f�r P?) TGP -> TGP : Logga TGP-beslut\n(AuditEvent lokalt) TGP –> Hub : Svar: JA / NEJ deactivate TGP

Hub -> Hub : Om NEJ: avbryt och returnera\nOperationOutcome 'ingen lokal journal' Hub –> Client : (NEJ) Visa felmeddelande\n"Patient ej tillg�nglig" deactivate Hub

== Vid JA ==

activate Hub Hub -> Hub : Markera TGP-uppfyllt\n(ev. uppdatera internt token/claim) Hub -> Sources : H�mta kliniska data f�r P\n(via FHIR/TKB) Sources –> Hub : Kliniska data (FHIR) Hub –> Client : (JA) Visa NP�-data f�r P deactivate Hub

@enduml ``

F�rdelar

  • Fungerar �ven n�r NP� inte startas inifr�n journalsystemet (t.ex. frist�ende portal).
  • V�rdgivaren beh�ller lokal kontroll �ver hur TGP-beslut fattas (vilka typer av kontakter, v�rdenheter, journalstatus etc. som r�knas).
  • TGP kan fungera som en �teranv�ndbar policy-komponent f�r fler tj�nster �n NP� (andra FHIR-hubbar, analytics-portaler etc.).

Nackdelar / Begr�nsningar

  • Kr�ver en extra TGP-komponent per v�rdgivare och ett standardiserat API eller token-claimformat.
  • Introducerar en ytterligare n�tverksrunda i �tkomstkedjan.
  • Kr�ver tydlig ansvarsf�rdelning f�r loggning och felscenarier (t.ex. n�r TGP �r nere).

J�mf�relse och rekommendationer

Aspekt Alternativ 1 NP� som SMART-app Alternativ 2 NP�/FHIR-hub + TGP-API
Centralt index kr�vs? Nej Nej (kan kompletteras om man vill)
Var g�rs TGP-bed�mningen? I EHR/IdP f�re SMART-launch I separat TGP-tj�nst/IdP
Startpunkt f�r NP� Fr�n �ppnad journal i EHR Fr�n EHR eller frist�ende portal
Token/claim-hantering SMART patientkontext i launch-token Eget tgp-claim eller API-svar
Loggning Prim�rt lokalt i EHR/IdP B�de i TGP-komponent och NP�-hub
Komplexitet i NP�-hub L�gre (f�rlitar sig p� SMART) H�gre (m�ste tala TGP-API)

Rekommenderad inriktning

F�r renodlade FHIR/SMART-milj�er och nya klienter:
Alternativ 1 (NP� som SMART-app) �r arkitektoniskt renast och kr�ver minst speciallogik.

F�r blandade milj�er med flera klienttyper, frist�ende portaler och behov av en gemensam TGP-policy f�r m�nga tj�nster:
Alternativ 2 (NP�/FHIR-hub med TGP-API) ger st�rst flexibilitet och kan samexistera med befintlig TGP-implementering.

B�da alternativen uppfyller grundid�n med TGP:

Att styrka och logga att det finns en journalrelation hos den v�rdgivare/v�rdenhet som beg�r uppgifter, innan sammanh�llen journalf�ring initieras.

De kan dessutom kombineras t.ex. genom att NP� b�de kan startas via SMART-launch (implicit TGP) och vid behov kan verifiera TGP via ett API i s�rskilda, frist�ende anv�ndningsfall.

Referenser