-svg.png){kind=small}
Introduktion till Sveriges nya digital infrastruktur (NDI)
- Marco de Luca
- Sep 23
- 21 min read
Updated: Sep 25
Sammanfattning
Sverige står inför en av de största förändringarna inom e-hälsa på decennier. Sveriges nya Nationella Digitala Infrastrukturen (NDI) ska möjliggöra säker och effektiv delning av hälsodata mellan alla vårdgivare, apotek, myndigheter och även aktörer inom social trygghet och kostnadsersättning. NDI ersätter sannolikt stora delar av dagens infrastruktur (t.ex. Ineras tjänsteplattform, infrastruktur och stödtjänster) och bygger på nya integrationsmönster, säkerhetsarkitektur och regelverk.
Översikt över vad som är på gång:
Obligatorisk anslutning: Alla ca 18 000 vårdgivare – både offentliga och privata – måste ansluta, liksom aktörer inom social trygghet (Vilka kan ansluta, se deltagarmodell).
Nya integrationsmönster: Peer-to-peer-kommunikation, sannolikt baserad på HL7 FHIR/REST ersätter central hubb – minskar sårbarhet men ställer höga krav på starka federations- och tillitsramverk.
Ny säkerhetsmodell: En kedja av tillit med stark autentisering, signering, kryptering och spårbarhet införs – dock utan ett heltäckande EU-gemensamt end-to-end-skydd.
Tillgångstjänster: Både patienter och vårdpersonal får nya tjänster som ger åtkomst till prioriterade informationsmängder – exempelvis journaler, recept och labbsvar – från samtliga vårdgivare.
Stor påverkan på system: Journalsystem och andra EHR-lösningar måste anpassas för att hantera nya integrationsmönster, digital signering, spärrhantering, fullmakter och nya API-profiler.
Det här får du med dig:
Vad Sveriges nya digitala infrastruktur (NDI) innebär och hur den kopplas till EU:s förordning om det europeiska hälsodataområdet (EHDS).
Vilka stödtjänster och komponenter som planeras för att möjliggöra säkert och effektivt informationsutbyte.
Hur rättsliga förutsättningar och regelverk påverkar vårdgivare, leverantörer och myndigheter.
Vilka utmaningar som finns, och vilka möjligheter en gemensam arkitektur kan skapa.
Inledning
I den här bloggen analyserar jag E-hälsomyndighetens (EHM) arbete med att etablera en nationell digital infrastruktur (NDI) kopplad till EHDS. Sammantaget innebär detta sannolikt den största förändringen inom svensk e-hälsa på mycket länge.
En helt ny arkitektur kommer att påverka alla Sveriges ca 18 000 vårdgivare samt ett stort antal system- och tjänsteleverantörer. Uppskattningsvis finns 80–140 leverantörer vars system kommer behöva anpassas för EHDS och anslutas till NDI.
Texten riktar sig till dig som är verksam inom hälso- och sjukvård, offentlig sektor eller leverantörsledet. Syftet är att ge en översikt över den arkitektur som nu växer fram, och vad den innebär i praktiken för både vårdgivare, systemleverantörer och beslutsfattare.
Jag utgår enbart från offentligt tillgängligt material. Analysen bygger därför på kända fakta om NDI och EHDS, kompletterat med kvalificerade antaganden där källorna lämnar luckor.
Arkitektur för Sveriges nya digitala infrastruktur (NDI)
I samband med Sveriges anslutning till EHDS/MyHealth@EU etablerar E-hälsomyndigheten en nationell digital infrastruktur (NDI) som ska möjliggöra säker och effektiv delning av patientuppgifter mellan både privata och offentliga aktörer. NDI skall stödja EHDS-förordningen men också lägga gunden för en generell infrastruktur som omfattar all vård.
EHDS är framtagen för att stödja:
Primär användning:
Patientens behov – tillgång till egna journaluppgifter oavsett var i EU vården ges.
Vårdens behov – rätt information, vid rätt tid, på rätt plats för en säker och effektiv vård.
Sekundär användning:
Samhällets behov – tillgängliggöra data för forskning, statistik, innovation och policyutveckling.
Gemensam legala och tekniska ramverk:
Gemensamma marknad - gemensamma krav på journalinformation (EHR) och därmed en gemensam marknad för journalsystem.
EHDS förordningen innebär att Sveriges befintliga e-hälsoinfrastruktur behöver moderniseras. Infrastrukturen kallas “Nationell digital infrastruktur” – NDI.
Sveriges nuvarande digitala infrastruktur
Inera AB är ett digitaliseringsbolag, som på uppdrag av Sveriges kommuner och regioner (SKR) utvecklar infrastruktur och tjänster för vård, omsorg och välfärd. De ansvarar för en mängd nationella digitala tjänster inklusive 1177 Vårdguiden, Nationell Patientöversikt (NPÖ) och SITHS-lösningar, samt digitala invånar- och vårdgivartjänster
Tillsammans med regionerna har Inera etablerat en gemensam infrastruktur och arkitektur genom T-boken, som innehåller Regelverk för interoperabilitet inom vård och omsorg samt tekniska anvisningar (RIV-TA). Se https://www.rivta.se/documents.html
Denna infrastruktur hanterar omkring 500 miljoner anrop per år.
Infrastrukturen: ”Nationella tjänsteplattformen” - Kontaktpunkt (hub) för integration
Den Nationella tjänsteplattformen (NTjP) fungerar som en central hubb för integration mellan tjänstekonsumenter och tjänsteproducenter. Det saknas i dag offentlig statistik över vårdgivares anslutningsgrad till infrastrukturen.
Tjänsteproducenter
Är aktören som levererar information via tjänstekontrakt (API).
En tjänsteproducent kan vara en ”Regional tjänsteplattform” eller ett system.
Bakom en regional tjänsteplattform kan det finnas en eller flera tjänsteproducenter.
Det finns ca 487 tjänsteproducenter.
Tjänstekonsument
Är aktören som hämtar information via tjänstekontrakt (API). Det kan vara ett system t.ex. vårdsystem (EHR) eller en e-tjänst inom 1177.
Logisk adress
Identifierar tjänsteproducenter. Det kan vara en verksamhetsadress (t.ex. en vårdgivare) eller en systemadress. I tjänsteplattformens adresseringskatalog finns 25 200 sk logiska adresser.
Tjänstekontrakt (API)
Det finns idag 291 tjänstekontrakt (Service Contract enligt WSDL-formatet).
Infrastruktur: Katalog - Hälso- och Sjukvårdens Adressregister (HSA)
HSA är en elektronisk katalog med kvalitetsgranskade uppgifter om organisationer och personer inom vård och omsorg i Sverige. Katalogen omfattar över 5 000 vårdgivare och vårdpersonal.
Aktörer kan göra direktanslutningar eller använda ett ombud (tjänsteleverantör)
Även för HSA saknas det officiell statistik över användning eller anslutningsgrad.
Tjänsteadresseringskatalog (TAK)
TAK är en tjänst som möjliggör kommunikation mellan tjänsteproducenter och tjänstekonsumenter via NTjP. För att kommunikationen ska fungera krävs en så kallad “takning” som ger tjänstekonsumenten rätt att anropa en tjänsteproducent med stöd av en logisk adress.
Engagemangsindex (EI)
EI är en stödtjänst som visar i vilka system patientuppgifter finns lagrade. Alla tjänsteproducenter som exponerar tjänstekontrakt måste uppdatera EI när nya patientuppgifter tillkommer i deras system. Exempel: “Vilka tjänsteproducenter innehåller labbsvar för patienten?”
Aggregerande tjänst
Tjänst som sammanställer information från flera tjänsteproducenter.
Exempel ”Sammanställer patientens labbsvar från alla tjänsteproducenter”
PKI - SITHS CA för system och vårdpersonal e-legitimationer
SITHS är Ineras ”public key infrastructure” (PKI) där HSA registrerade personer eller system (funktioner) kan få ett certifikat (X509).
All nationell system-till-systemkommunikation identifieras med hjälp av SITHS certifikat.
Inera tillhandahåller dessutom en identitet provider (IdP) för autentisering av vårdpersonalens e-legitimationer.
E-tjänster
Genom varumärket 1177 erbjuds ett stort antal digitala tjänster för både vårdpersonal och invånare.
Exempel på tjänster som erbjuds:
Kommunikationstjänster/Meddelandetjänster med vården
Tidbokning
Journalinformation
Läkemedelstjänster
Provhantering
Hälsodeklarationer (Formulär) inför vårdbesök
Stöd och behandling - KBT behandling
Hjälpmedelsbeställning
Högkostnadsskydd
Intygstjänster
Statistik från Inera visar att det finns ca 10 miljoner registrerade användarkonton.
Analys: Ineras arkitektur och infrastruktur är etablerad sedan många år. Infrastrukturen skulle mycket väl kunna utgöra bas för ”NDI”. En begränsande faktor är att endast offentligt finansierad verksamhet kan ansluta och använda infrastrukturen enligt ägardirektiv.
Enligt ägardirektiv gäller:
Det innebär alltså att för att en aktör ska kunna bli kund krävs att den ligger inom ägarnätverket – eller är underställd dem (t.ex. kommunala bolag) – och att tillgång till tjänster följer dessa begränsningar.
Ägardirektivet gör att Ineras infrastruktur sannolikt inte blir Sveriges nya digitala infrastruktur (NDI). Ineras infrastruktur skulle mycket väl kunna utgöra kontaktpunkt för anslutna kunder (anpassning krävs). |
Nationell digital infrastruktur (NDI).
E-hälsomyndigheten (EHM) arbetar med en ny nationell digital infrastruktur (NDI). När den tas i bruk ska NDI skapa förutsättningar för olika system och aktörer att dela (utbyta) information med varandra. Huvudsyftet är att underlätta säker och effektiv delning av hälsodata.
I detta avsnitt beskriver jag arkitekturen övergripande samt dess kända beståndsdelar.
NDI innebär att aktörer integreras på ett helt nytt sätt, jämfört med den nuvarande infrastrukturen från Inera.
Nationell digital infrastruktur och integrationsarkitektur
Avtal mellan deltagande parter
IT-säkerhetskrav för säkerhetsprotokoll
Regler för informationssäkerhet
Integrationsprofiler
Nya stödtjänster för informationslokalisering och tjänsteadressering
Anslutningsförfarande med kundkännedomsprocesser
Test och valideringskoncept av tekniska specifikationer och protokoll.
Deltagarmodell
NDI är utformad för att omfatta hela vårdsektorn – både offentliga och privata aktörer – samt vissa myndigheter, aktörer inom social trygghet och inom sektorn för tjänster för kostnadsersättning. Enligt min bedömning kommer följande typer av organisationer kunna ansluta:
Vårdgivare
Samtliga offentliga och privata vårdgivare i Sverige som hanterar hälsodata. Detta gäller oavsett finansieringsform; även privata vårdgivare kommer att behöva göra patientdata tillgänglig via infrastrukturen.
Regioner och kommuner
Dessa ansvarar för merparten av hälso- och sjukvården samt äldreomsorgen.
Kommunalt självstyre påverkas, men NDI innebär anslutningsskyldigheter
Kommuner/regioner i rollen som huvudmän för socialtjänst – t.ex. ekonomiskt bistånd och äldreomsorg där hälsodata kan vara relevant (Om nationell reglering kommer på plats kan även socialtjänsten omfattas)
Statliga myndigheter
E-hälsomyndigheten (MDH – Myndighet för digital hälsa) föreslås bli huvudansvarig för infrastrukturen och centrala tillgångstjänster.
Socialstyrelsen, Läkemedelsverket, IVO och andra myndigheter kan få särskilda roller, t.ex. register, tillsyn, kodverkshantering.
Apotek och läkemedelsaktörer
Behöver ansluta för att hantera e-recept och läkemedelsrelaterad rapportering.
Patienttjänster
Tillgångstjänster för patienter (t.ex. 1177 men även privata e-hälsotjänster) ska kunna ansluta för att ge patienter tillgång till sina hälsodata och rättigheter enligt EHDS .
Sedan finns det ”aktörer i sektorn för social trygghet samt i sektorn för tjänster för kostnadsersättning” som borde kunna innebära:
·Försäkringskassan – hanterar sjukpenning, rehabiliteringsersättning, aktivitetsersättning m.m.
Pensionsmyndigheten – när det gäller vårdrelaterade pension- eller ersättningssystem.
Arbetsförmedlingen – vid samordning av insatser.
Privata försäkringsbolag – t.ex. Folksam, Skandia, Trygg-Hansa, som erbjuder sjukvårdsförsäkring eller olycksfallsförsäkring.
AFA Försäkring – arbetsmarknadens försäkringsbolag för arbetsskador och sjukförsäkring.
Systemleverantörer (t.ex. journalsystem, labsystem, bildhantering/PACS, läkemedelslösningar, tillgångstjänster m.fl.) – Behöver anpassa sina produkter till NDI:s tekniska och juridiska krav. Deras lösningar kan behöva verifieras eller certifieras för användning inom NDI.
Nationell digital infrastruktur och arkitektur
Integrationsmönster
Den nya arkitekturen bygger på en distribuerad ”peer-to-peer”-modell, vilket innebär att parterna integrerar direkt med varandra.
En API-konsument anropar respektive deltagares API-producenter (kontaktpunkter). Informationsägaren – exempelvis en vårdgivare – ansvarar för att självständigt utforma sin API-infrastruktur.
Varje NDI-deltagande (t.ex. vårdgivare) ansluts mot NDI via en eller flera kontaktpunkter.
Deltagaren ansluter därefter sina komponenter, såsom EHR-system till den lokal infrastruktur.
Analys: NDI:s integrationsmönster skiljer sig tydligt från Ineras nuvarande infrastruktur, där en central hubb (tjänsteplattformen) ”terminerar” trafiken mellan konsument och producent. I NDI-modellen anropar konsumenten producenten direkt.
|
Patientdataindex
Patientdataindex (PDI) är en stödtjänst som innehåller information om vilka NDI-deltagare (organisationer) som lagrar patientens uppgifter inom infrastrukturen.
Exempel:
1. Konsument: Söker efter indexposter för patient ”Tolvan”
2. PDI: Returnerar indexposter med information om vilken vårdgivare som lagrar patientens uppgifter (i detta fall patienten ”Tolvan”).
Meddelandemodell patientdataindex
Indexpost
Unik identifierare av post med en registreringstidpunkt
Vårdgivare (informationsägaren)
Aktör (NDI) deltagare som lagrar information om patienten.
Registrerande komponent
Representerar det EHR system som lagrar informationen.
Här finns en platshållare för ett signeringscertifikat. Det finns ingen ytterligare information om hur signering skall fungera i nuvarande version.
Analys Patientindex har vid en första anblick samma övergripande funktion som Ineras ”Engagemangsindex”. Vid närmare granskning framträder flera skillnader som påverkar implementeringen av både kontaktpunkter samt EHR system.
Avsaknad av informationstyp i indexposter
Platshållare för certifikat
Registrerande komponent och systemlandskap
Slutligen gäller att alla NDI-deltagare som producerar patientuppgifter måste använda och löpande uppdatera Patientdataindex. |
Tjänsteadresseringskatalog (NTK)
Tjänsteadresseringskatalogen (NTK) är NDI:s gemensamma katalog för tillgängliga API:er och deras anropsadresser. Adresseringen är verksamhetsbaserad, vilket innebär att organisationens eller vårdgivarens (informationsägarens) identitet används som nyckel.
Varje aktör ansvarar för att hålla sin egen information uppdaterad i katalogen, och den informationen blir sedan tillgänglig för alla andra aktörer via NTKs APIer.
Katalogen innehåller uppgifter om anropsadresser för kontaktpunktens exponerade API:er. Informationen måste löpande hållas uppdaterad av deltagande organisationer.
Tjänsteadressering innebär att en konsument, baserat på ett identitetsbegrepp – exempelvis informationsägarens id (till exempel organisationsnummer) – hämtar den metadata som krävs för att kunna anropa en tjänsteproducent.
Analys: En NDI-deltagare kan registrera flera kontaktpunkter som hanterar samma API-utbud. Detta ger flexibilitet men innebär samtidigt att konsumerande parter kan behöva göra fler anrop för att hämta information.
I EHDS-infrastrukturen används standarden OASIS Business Document Metadata Service Location Version 1.0 (BDX-Location-v1.0) samt SMP (Service Metadata Publisher) OASIS SMP 2.0, tillsammans med SML/SMP för tjänstekatalog och dynamisk adressering.
Även DIGG:s digitala tjänst Säker digital kommunikation (SDK) använder SML/SMP för dynamisk adressering. Där innehåller SMP dessutom säkerhetsmetadata, bland annat nodernas publika nycklar. |
Informationsaggregerande
Alla NDI deltagare med behov av informationsaggregering behöver utveckla stöd för detta. Informationsaggregering sker genom att konsumenten använder Patientdataindex (PDI) för att identifiera vilka vårdgivare (informationsägare) som lagrar patientens uppgifter. Konsumentsystemet hämtar därefter de tekniska adresserna för dessa vårdgivare från tjänstekatalogen (NTK).
Informationsaggregering, det vill säga sammanställning av information, kommer sannolikt att vara ett vanligt mönster ur ett verksamhetsperspektiv.
Inom EHDS/NCP finns en aggregerandetjänst som en del av ”Tillgångstjänster”.
Bild: Illustrerar översiktligt hur en konsument använder PDI för att sammanställa/aggregera information.
Förutsättningar:
Informationsaggregering sker genom:
Konsument: Lokalisera information genom anrop mot Patientdataindex (PDI). ”Var finns information om patient Tolvan Tolvansson”
Patientdataindex: Returnerar lista med indexposter som innehåller
Vårdgivare (organisationsnummer) som lagrar patientuppgifter
Patient-id (personnummer, samordningsnummer, nationellt reservnummer och utländska personidentifierare inom EU))
Registrerande system (EHR) publik nyckel (signeringscertifikat)
Registreringstidpunkt
Konsument: För varje indexpost hämtas information om producent(kontaktpunkt) från tjänsteadresseringskatalog (NTK).
API utbud (API definitioner som representerar olika informationstyper)
Endpoint (teknisk adress)
Vårdgivare
Illustrerande sekvensdiagram:
Konsument: Anropar varje producent(kontaktpunkt)
Producent:
Kontrollerar mot lokal och nationell spärrfunktion.
Signerar information (Registrerande komponent dvs EHR)
Producent: Returnerar information
Tjänstekonsument: Sammanställer information från alla tjänsteproducenter.
Kontrollerar informationens signatur.
Analys: E-hälsomyndigheten skriver: ”Givet den information som idag finns till förfogande från olika EU-projekt, främst Xt-EHR, gällande hur patientöversikterna ska sammanställas (aggregeras) bedömer myndigheten att det inte finns skäl att i dagsläget etablera en nationell aggregeringsfunktion inom ramen för den nationella digitala infrastrukturen. Det blir den konsumerande tjänstens ansvar att göra en eventuell sammanställning.”
Detta innebär en tydlig skillnad jämfört med Ineras arkitektur, där aggregerande tjänster finns etablerade. I praktiken blir dock skillnaden liten(eller ingen alls), eftersom endast Inera har haft möjlighet att använda de befintliga aggregerande tjänsterna.
Det finns generella utmaningar med att sammanställa information från många olika källor. Faktorer som svarstider, avbrott och störningar påverkar tjänstekonsumenten oavsett var den aggregerande funktionen är placerad. Speciellt I en federation med många producenter.
Slutsatsen är att alla vårdsystem som behöver sammanställa patientuppgifter själva kommer att behöva utveckla aggregerande tjänster. |
Integrationsprofiler
Integrationsprofiler, eller API-specifikationer som beskriver API:er, kommer att tas fram genom det Nationella rådet för interoperabilitet. Efter remissförfarande fastställs dessa som Nationella gemensamma specifikationer (NGS).
Analys: Rapportens skrivningar indikerar att endast specifikationer som är fastställda enligt NGS, samt EHDS-specifikationer (t.ex. European Electronic Health Record Exchange Format – EEHRxF), får användas inom NDI.
Detta skiljer sig från Ineras infrastruktur, som tillåter användning av nationellt förvaltade (Inera), externt förvaltade och applikationsspecifika integrationsprofiler (tjänstedomäner).
Konsekvensen kan bli att parallella infrastrukturer måste byggas för de specifikationer eller tjänstedomäner(behov) som inte kvalificeras eller förvaltas enligt NGS. Med tanke på de betydande investeringar som både leverantörer och vårdgivare behöver göra, framstår denna typ av begränsning som problematisk. Den riskerar att leda till:
|
Grunddata personal
Individer med legitimation eller yrkesbevis finns registrerade i HOSP.
Andra viktiga uppgifter om personal är vilken organisation personen är anställd hos, vilken roll personen har samt vilka behörigheter och befogenheter som gäller.
Socialstyrelsen för register över legitimerad hälso- och sjukvårdspersonal.
Analys För att upprätthålla en hög nivå av informationssäkerhet, bland annat genom korrekt behörighetsstyrning, krävs kvalitetssäkrade personaluppgifter.
Det är dock inte tydligt hur behörighetshantering ska ske inom NDI, utöver att åtkomstbeslut enligt nuvarande skrivningar fattas av informationsägaren.
Jag har inte funnit relevant dokumentation i området och har därför inte kunnat fördjupa analysen ytterligare. |
Grunddata organisation
För grunddata om organisationer har E-hälsomyndigheten identifierat behovet av en nationell källa som täcker samtliga aktörer som ska dela information inom NDI. Katalogen behöver omfatta alla organisationer som kan anslutas enligt NDI:s deltagarmodell.
Jag har inte fördjupat analysen i detta område, men sannolika grunddatadomäner är:
Företag – Bolagsverket (bolagsverket.se)
Hälsa, vård och omsorg – E-hälsomyndigheten (ehalsomyndigheten.se)
E-hälsomyndigheten ska ta fram en katalogtjänst som utgör den nationella källan för grunddata om organisationer inom NDI:s deltagarmodell.
Analys: En kvalitetssäkrad katalog med alla NDI-anslutna organisationer är en förutsättning för att informationsutbyte ska fungera mellan aktörerna inom NDI.
Här kan E-hälsomyndigheten dra stor nytta av EU-förordningen eIDAS (EU 2024/1183), som möjliggör e-underskrifter (avancerade eller kvalificerade). Detta skapar bättre förutsättningar för självservice.
Organisationer kommer att behöva underhålla sin information via ett administrationsgränssnitt eller genom integration – här kan det finnas möjligheter att återanvända HSA. |
Spärr och opt-out
”Utgångspunkten i EHDS-förordningen är att åtkomst till patientens hälsodata inte kräver patientens samtycke, men att patienten kan begränsa (spärra) tillgången eller, om nationell rätt medger det, helt motsätta sig datadelning (så kallad opt-out). Det faktum att patienten har begränsat (spärrat) tillgången ska inte vara synligt för vårdgivare”.
Typer av spärrar:
Lokal spärr – lagras hos den informationsägare som förfogar över de spärrade uppgifterna.
Allmän spärr (opt-out) - är generella och inte knutna till en enskild informationsägare. Dessa ska lagras både centralt i ett nationellt spärrregister och lokalt hos samtliga berörda informationsägare.
Analys: NDI inför ett nytt synsätt på spärrhantering: spärrad information ska aldrig lämna producenten (det lokala vårdsystemet). I Sverige finns redan ett spärrkoncept som ligger nära EHDS-kraven, men dagens infrastruktur fungerar annorlunda – där är det konsumerande system som ansvarar för att filtrera bort spärrad information.
För att stödja administration och tillämpning av spärrhantering kommer nya integrationsmönster att införas:
Det nya spärrkonceptet och de tillhörande mönstren kommer att kräva anpassningar i samtliga vårdgivares EHR-system. |
Fullmakt och företrädare (Fullmaktstjänster för patienters ombud)
Vårdnadshavare – Information tillhandahålls via Skatteverket
Ställföreträdarregister – Innehåller uppgifter om rättsliga företrädare
Patientens fullmakter - hanteras genom tjänsten ”Mina ombud”
Tjänsten utformas för att stödja behov inom tillgångstjänster (t.ex. e-tjänster inom 1177), men ska även kunna användas av vården generellt.
Vårdgivare ska bistå patienter med att registrera fullmakter. Denna funktion är ännu inte närmare specificerad, och den tekniska påverkan är därför svår att bedöma.
Analys: Behovet av fullmaktstjänster som stödjer patienten har funnits så länge jag har arbetat inom e-hälsoområdet.
Fullmaktstjänsterna kommer sannolikt att ha stor påverkan på vårdgivarnas vårdsystem, åtkomstkontroll kommer behöva verifiera “fullmakt” mot ett centralt system.
Tjänsten Mina ombud förvaltas idag av Bolagsverket men ska enligt uppgift överföras till DIGG. Huruvida tjänsten är anpassad för vårdens specifika behov har jag inte hunnit bedöma. |
Tillgångstjänster
Hälso- och sjukvårdspersonals tillgångstjänst
Tjänsten ska ge vårdpersonal tillgång till minst de prioriterade EHDS-profilerna från alla vårdgivare i Sverige – både offentligt finansierade och privata utan offentlig finansiering – samt från vårdgivare i andra EU-länder.
Ineras Nationell patientöversikt (NPÖ), som i dag fungerar som Ineras tillgångstjänst, stödjer redan i viss utsträckning de prioriterade informationsmängderna enligt EHDS.
EHDS- profil | NPÖ – faktiska tjänstekontrakt | Kommentar / gap |
Patient Summary | GetDiagnosis v2 (diagnoser) GetCareDocumentation (journalanteckningar) GetActivities (åtgärder / vårdåtgärder) GetMedicationHistory (läkemedelslista, ordinationer) GetVaccinationHistory (vaccinationer) GetAlerts (varningar, inkl. allergier) | Samlar centrala delar, men EHDS kräver en sammanhållen Patient Summary i EEHRxF/FHIR. |
ePrescription / eDispensation | GetMedicationHistory (läkemedelslista/ordinationer) GetPrescription (receptinformation, kopplat till E-hälsomyndigheten) | Ordinationer/dispensationer hanteras, men behöver harmoniseras semantiskt med EHDS profiler (t.ex. ordination vs. expedition). |
Laboratory Results | GetLaboratoryOrderOutcome (labbsvar) GetLaboratoryOrder (beställningar) | God mappning till EHDS Laboratory Results. Kräver kodverksharmonisering |
Medical Images & Image Reports | GetImagingOutcome (radiologisvar, bild- och funktionsmedicin) GetDocument (för åtkomst till bildrelaterade dokument) | Rapporter stöds. EHDS kräver både bildfiler (DICOM) och strukturerade rapporter. |
Hospital Discharge Reports | GetCareDocumentation (journalanteckningar, inkl. epikriser) GetDocument (för utskrivningsdokument) | Epikriser kan hämtas, men behöver paketeras i EHDS-format (FHIR Composition/DocumentReference). |
Därutöver stödjer Ineras NPÖ följande informationsmängder:
GetCareContacts v3 (vårdkontakter, besökshistorik)
GetCareEvent v2 (vårdhändelser)
GetReferralOutcome v1 (remissvar)
GetRequestStatus, (Remissstatus)
GetCarePlans v2 (vårdplaner)
GetDocument v3 (generiska dokument, t.ex. PDF, intyg)
GetClinicalTrialParticipation v1 (deltagande i studier)
Analys: Det finns risk för både dubblering och gap mellan de informationsmängder som tillgängliggörs i Ineras NPÖ och i E-hälsomyndighetens framtida tillgångstjänst.
Skillnader mellan tjänsterna: NPÖ (befintlig tillgångstjänst) – omfattar fler informationsmängder, men endast från offentligt finansierade vårdgivare. EHM:s tillgångstjänst (ny) – kommer initialt sannolikt omfatta färre informationsmängder, men inkludera både privata och offentligt finansierade vårdgivare.
|
Patientens tillgångstjänst
E-hälsomyndigheten kommer sannolikt (min tolkning av deras rapport) att utveckla en egen version av 1177-konceptet. Den ska ge patienter tillgång till prioriterade informationsmängder (EHDS-profiler) och innehålla funktioner som:
Tillgång till hälsodata (initialt de prioriterade EHDS-informationsmängderna)
Ladda ner en kopia
Föra in egna uppgifter
Begära rättelse
Dataportabilitet
Spärra hälsodata
Få information om vårdpersonals åtkomst
Utse ombud
Opt-out (om Sverige inför detta)
Föra in egna uppgifter
Denna funktion kräver att vårdgivarnas system kan ta emot meddelanden i någon form av inkorg. I dagsläget finns ingen integrationsprofil framtagen för detta.
Systemen hos vårdgivarna behöver kunna anpassas för att:
ta emot begäran,
meddela patienten status på begäran,
korrespondera med patienten kring begäran.
Funktionen är än så länge endast översiktligt beskriven. Troligen behöver vårdgivare och patient kommunicera direkt för att en rättelse ska kunna genomföras. Någon särskild patientkommunikationstjänst är inte beskriven i nuvarande version.
Dataportabilitet
Tjänsten ska möjliggöra att patienten tillfälligt delar eller överför sina uppgifter mellan vårdgivare och inom sektorer som social trygghet eller kostnadsersättning. Här kan även nya aktörer integreras, exempelvis myndigheter och privata försäkringsbolag som hanterar ersättning för vårdtjänster via sjukvårdsförsäkringar.
För dataportabilitet behöver tjänsten stödja att patienten kan:
skapa ett urval av uppgifter (hela eller delar),
välja mottagare,
initiera överföring eller delning,
få status på förfrågan (accepterad eller avvisad överföring).
Analys: Det finns risk för både dubblering och gap mellan informationsmängderna i E-hälsomyndighetens tillgångstjänst för patienter och i 1177 Journalen.
Dataportabilitet och ”Föra in egna uppgifter” ger patienten möjlighet att begära att information flyttas eller kopieras till en annan vårdgivare. De arkitekturmönster och stödtjänster som hittills definierats (observera att specifikationerna ännu inte är fastställda) förhindrar inte sådan överföring mellan vårdgivare. Däremot saknas i dag stödtjänster och mekanismer som underlättar denna typ av överföring. För att möta behoven behöver arkitekturen:
|
Säkerhet
EHDS säkerhetskrav som påverkar NDI
EHDS ställer krav som påverkar utformningen av NDI:s säkerhetsarkitektur. Dokumentationen är omfattande och kraven är inte alltid entydiga, särskilt inom området end-to-end-säkerhet. Centrala specifikationer är:
eHDSI Security Services v7.0.0 (åtkomstkontroll, loggning)
eHDSI Section I – Security Policies v7.0.0
eHDSI Section II – Security Services v7.0.0
eHDSI Requirements Catalogue v9.0.0 OR
eHDSI SAML Profile v9.0.0 (attribut för vårdpersonal och roll)
Cryptographic Algorithms v9.0.0 (algoritmval, miniminivåer)
The security policy: eHDSI requires an end-to-end security, from the Health Professional in the country of Treatment, to the medical information located in the Country of Affiliation, ensuring the confidentiality, integrity and availability of the exchanged information.
As an important note, in all eHDSI documentation (specifications, frameworks), the use of the term end-to-end encryption, implicitly refers to the end-to-end security, and does not imply an uninterrupted chain of encryption. Each Member State has the responsibility to implement the appropriate and feasible technical solution to fulfil the eHDSI Security Policies and objectives. |
eHDSI:s säkerhetspolicy kräver end-to-end-säkerhet från vårdpersonal i behandlingslandet till den medicinska informationen i hemlandet. Syftet är att säkerställa konfidentialitet, integritet och tillgänglighet.
Viktigt är att begreppet end-to-end encryption i dokumentationen avser end-to-end security i bred mening, och inte en obruten kedja av kryptering. Varje medlemsstat ansvarar för att implementera en tekniskt lämplig och genomförbar lösning för att uppfylla säkerhetspolicyn.
MyHealth@EU Requirements Catalogue innehåller även krav som bedöms påverka NDI:s säkerhetsarkitektur, bland annat:
· 11.01.01 Ensure confidentiality of the services, data and systems
· 11.01.02. Ensure integrity of the exchanged data
· 12. Ensure the non-repudiation of the exchanged data
· 12.01. Handle the non-repudiation mechanism
Säkerhet inom NDI
E-hälsomyndigheten (EHM) har ännu (per 2025-09-17) inte publicerat detaljer om säkerhetsarkitekturen för NDI. Rapporten Genomförandet av en nationell digital infrastruktur för hälso- och sjukvård och EHDS primäranvändning anger dock att EU-rättsliga och nationella regleringar kommer att beaktas
NIS2-direktivet – krav på styrning, riskhantering, robust cybersäkerhet och leverantörskedjor.
GDPR – särskilda krav då NDI hanterar känsliga personuppgifter (hälsodata).
CER-direktivet – motståndskraft för samhällsviktig infrastruktur.
Säkerhetsskyddslagen (2018:585) – kan bli aktuell då NDI sannolikt omfattar säkerhetskänslig verksamhet.
MSB:s föreskrifter för cybersäkerhet – t.ex. MSBFS 2020:7 och kommande för NIS2.
E-hälsomyndigheten betonar dessutom att:
Uppgifter som behandlas får inte läcka, förvanskas eller förstöras.
Information och system kan behöva klassificeras enligt säkerhetsskyddslagen.
Min tolkning:
End-to-end-säkerhet ska tillämpas mellan vårdpersonal och EHR-system (konsument och producent), även om kedjan i praktiken bryts vid olika noder (t.ex. NCP eller NDI). Ett heltäckande EU-gemensamt PKI-baserat end-to-end-koncept är inte realistiskt i dag. I stället används en chain of trust-modell. EHDS-arkitekturen innehåller inte heller stöd för ett gemensamt end-to-end-koncept på EU nivå.
En modern säkerhetsarkitektur behöver därför ha tekniskt stöd för att upprätthålla hög grad av riktighet och konfidentialitet. Utifrån kravbilden kan det vara relevant att definiera två nivåer av meddelandeskydd:
EU-meddelandeskydd – meddelandesignering och -kryptering mellan NCP:er (SOAP, WS-Security, XML-signaturer) mellan medlemsländer.
NDI-meddelandeskydd – säkerhetsmekanismer för att skydda riktighet och konfidentialitet mellan deltagarnas kontaktpunkter, inklusive EHDS NCP mellan NDI deltagare.
Analys: Även om detaljerna ännu inte är publicerade är det sannolikt att säkerhetskraven på NDI blir mycket höga.
NDI bör bygga på ett zero trust-paradigm, men kommer sannolikt i praktiken baseras på en chain of trust-modell, liknande MyHealth@EU.
Sammanfattningsvis kommer säkerhetsarkitekturen att behöva omfatta: Följsamhet till ISO/IEC 27000-serien, särskilt CIA-triaden för informationssäkerhet:
Krav på non-repudiation och kryptografisk integritetssäkring (stöd finns delvis genom publicerade signeringscertifikat i PDI, men motsvarande koncept för kryptering på innehållsnivå saknas i nuläget)
Mycket talar för att NDI kommer baseras på HL7 FHIR. FHIR:s REST-baserade arkitektur innebär att säkerhet i första hand hanteras via TLS/mTLS och OIDC/OAuth2. Till skillnad från SOAP/WS-Security saknas dock inbyggda mekanismer för meddelandesignering och kryptering på innehållsnivå. |
Behörighetsstyrning och åtkomstbeslut
Det finns ännu ingen publicerad information om hur behörighetsstyrningen i NDI kommer att utformas. Eftersom NDI behöver stödja informationsåtkomst i enlighet EHDS utgår jag därför från den modell för behörighetsstyrning och åtkomstbeslut som definieras inom EHDS säkerhetsarkitektur.
Vid informationsägarens åtkomstbeslut (punkt 3 i illustrationen) kommer sannolikt följande information att vara tillgänglig:
Integrationsprofil
API-definition
Attribut
patientens identitet
vårdpersonalens identitet
vårdpersonalens roll
på vems uppdrag personalen agerar (OnBehalfOf)
vårdgivarens identitet
typ av vårdgivare
syfte (Treatment, Emergency)
plats (Point of Care)
EHR-system-ID
digital signatur
Åtkomstbeslut:
Informationsägaren fattar alltid beslut om åtkomst.
Spärrar och opt-out kontrolleras alltid innan utlämnande (nationell och lokal spärrlista).
Analys: EHDS Security Services (Section II) och SAML Profile definierar hur behörighetsattribut för vårdpersonal och patienter ska överföras. I praktiken sker detta via SAML-assertioner.
Om arkitekturen baseras på REST/HL7 FHIR överförs behörighetsattribut i stället via claims i OAuth2 access tokens. Informationsägaren (exempelvis en vårdgivare) fattar då åtkomstbeslutet baserat på dessa attribut, samt på patientens spärrar och eventuella opt-out. Detta skapar förutsättningar för en konsekvent behörighetsstyrning inom hela federationen.
Behörighetsattribut behöver vidarebefodras till komponenten som fattar åtkomstbeslut.
Det är ännu inte specificerat om digitala signaturer mellan konsument och producent ska implementeras, men det framstår som mycket sannolikt(för att säkerställa riktighet.
Vid interna anrop inom NDI kan de behörighetsstyrande attributen sannolikt valideras. Vid externa anrop via EHDS/NCP är detta inte möjligt, vilket innebär att informationsägaren i praktiken behöver förlita sig på EHDS och NDI:s säkerhetsarkitektur.
Samtliga vårdsystem (EHR) auktorisationskompoment kommer därför behöva anpassas till de säkerhetsprotokoll och den behörighetsmodell som definieras inom NDI. |
Tillitsramverk och regelverk för deltagare
Det finns ännu ingen publicerad information om vilka regelverk som ska gälla för deltagare i NDI. Baserat på erfarenheter från Säker digital kommunikation (SDK), som är utformat för att hantera känsliga personuppgifter, kan tillitsramverket och regelverken förväntas innehålla följande:
Regelverk för deltagare
Anslutningsavtal
Roller och ansvar mellan parter
Informationssäkerhetskrav
Tekniska säkerhetskrav
Anslutningsprocess
Incidenthantering
Efterlevnad
Regelverk för tjänsteleverantörer
Tekniska specifikationer
Tekniska säkerhetskrav
Processer för anslutning och validering
Säkerhetsprotokoll för deltagande i NDI
Det här området behandlas inte i detalj i denna blogg, men jag kommer återkomma i framtida inlägg. Viktiga frågor att belysa framåt är bland annat:
Säkerhetsprotokoll för samverkan inom en federation som NDI
Identifiering av organisationer, API-konsumenter och API-producenter
Överföring av behörighetsgrundande information för lokala åtkomstbeslut
Validering av avsändare och mottagare
Onboarding – tillträde till NDI
Offboarding – avstängning från NDI
Nyttjande av PKI inom NDI (tillit och ev identifiering)
Avslutning
NDI är fortfarande under uppbyggnad och E-hälsomyndigheten befinner sig i ett tidigt skede. Det är naturligt att inte alla specifikationer ännu är fastställda och publicerade. Per den 17 september 2025 återstår cirka 912 arbetsdagar till planerad go-live den 26 mars 2029 (för primär användning).
En central fråga är vad go-live kommer att innebära i praktiken:
Att alla 18 000 vårdgivare kan ansluta?
Eller att samtliga faktiskt är anslutna?
För att leverantörer ska hinna anpassa sina system och vårdgivare sina verksamheter behöver följande områden prioriteras:
Regelverk och specifikationer
Fastställande av grundläggande säkerhetsarkitektur
Fastställande av samverkansarkitektur
Framtagande av tillitsramverk och regelverk för deltagare
Anslutning
Utveckling av anslutningsförfarande med kundkännedomsprocess
Testverktyg och testmiljöer
Tydliga test- och anslutningsförfaranden
Certifieringskoncept för leverantörslösningar
Migrering
Framtagande av en strategi för övergång från Ineras till E-hälsomyndighetens infrastruktur. Rapporten Genomförandet av en nationell digital infrastruktur för hälso- och sjukvård och EHDS primäranvändning indikerar att NDI ska ersätta Ineras nuvarande lösningar.
Aktörer som redan är anslutna till Ineras arkitektur kommer sannolikt behöva vidmakthålla dubbla lösningar under en period.
Alternativt kan Ineras infrastruktur anpassas för att fungera som kontaktpunkt för anslutna organisationer.
Gemensamma komponenter och självservice
Koncept för självservice genom administrationsgränssnitt och API:er
Automatiserade processer för anslutning och validering
Effektiva metoder för att deltagare ska kunna administrera metadata
Organisationer som ska delta i NDI kommer sannolikt behöva 1–2 års förberedelsetid för att anpassa sina verksamhetssystem och processer. NDI kommer att få stor påverkan på systemen, och i viss mån även på verksamhetsprocesserna, beroende på hur olika tjänster ska stödjas i praktiken, till exempel:
Föra in egna uppgifter
Fullmakt och företrädare
Grunddata organisation
Om författaren
Jag heter Marco de Luca och arbetar som senior lösningsarkitekt med över 25 års erfarenhet av att utveckla och införa nationella digitala infrastrukturer. Min bakgrund omfattar framtagande och förvaltning av Säker Digital Kommunikation (SDK), interoperabilitet, informationssäkerhet och systemintegration, ofta i nära samarbete med myndigheter, regioner och europeiska initiativ såsom CEF eDelivery.
Jag är certifierad IT-arkitekt och certifierad chefsarkitekt via Dataföreningen och har under många år lett arbetet med att utforma regelverk, tekniska specifikationer och strategier som gör det möjligt för offentlig sektor att dela information på ett säkert och tillförlitligt sätt. Jag har lång erfarenhet av e-hälsoarbete i roller inom Inera, där jag bidragit till utveckling och förvaltning av den nationella infrastrukturen och tjänster som 1177. Det har gett mig en djup förståelse för hur digitala lösningar kan stärka både vården och medborgarnyttan.
