Vad innebär European Health Data Space (EHDS)

Introduktion

Denna blogg är en övergripande introduktion till EHDS och den arkitektur och infrastruktur som är framtagen inom ramen för My Health @ EU eHealth Digital Service Infrastructure

Electronic cross-border health services in the EU. I Sverige är ansvarig myndighet E-hälsomyndigheten (EHM).

Denna blogg fokuserar primärt på att skapa en förståelse för förordningen EHDS samt vad det innebär för Sveriges digitala strukturer för vård- och omsorg. I textrutorna ”Analys” lyfter jag fram utmaningar och otydligheter.

Förordningen EHDS kommer bli ett verktyg för att ”refaktorera” svensk infrastruktur för vård- och omsorgssektorn i Sverige. Drivande för detta är EHDS/MyHealth@EU definition ”national infrastructure (NI) som skall anslutas till MyHealth@EU. EHM ansvarar för att definiera infrastrukturen och kallar den ”Nationell digital infrastruktur” (NDI).

I kommande bloggar kommer vi fördjupa oss i vad den ”nya” nationella digitala infrastrukturen är och hur den förhåller sig till den som finns idag.

Reservation: Dokumentation kring EHDS och MyHealth@EU är mycket omfattande och har tagits fram under många år vilket har varit utmanande. Dokumentationen jag arbetat med är markerad som ”operation-ready” men är inte slutlig version.

EHDS har sitt ursprung från epSOS år 2010.

European Health Data Space (EHDS)

European Health Data Space (EHDS) är EU:s stora satsning på gränsöverskridande hälsodata. Det bygger vidare på tidigare initiativ som epSOS (2010) och MyHealth@EU. EHDS regleras av EU-fördragets artiklar 114 och 168 samt direktiv 2011/24/EU om patienters rättigheter i gränsöverskridande vård.

I Sverige har E-hälsomyndigheten rollen som nationell kontaktpunkt (NCPeH) för primär användning. För sekundär användning (HealthData@EU) förbereds en svensk nod inom ramen för SENASH.

Vad är syftet med EHDS?

Primär användning:

• Patientens behov – tillgång till sina 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 att stödja säker och effektiv vård.

Sekundär användning:

• Samhällets behov – tillgängliggöra data för forskning, statistik, innovation, maskinlärning(AI) och policyutveckling.

Gemensamma legala och tekniska ramverk:

• Gemensamma marknad - Skapa gemensamma krav på journalinformation (EHR) och därmed en gemensam marknad för journalsystem.

EHDS är en del av visionen om European Health Union och kopplar även till European Strategy for Data.

Bild: Illustrerar EHDS/MyHealth@EU övergripande arkitektur. Varje medlemsland ansluter kontaktpunkt – NCP som hanterar integration mellan medlemsländer. Vårdgivarnas journalsystem ansluts till nationell infrastruktur (NI). Hur nationell infrastruktur utformas avgörs av respektive medlemsland.

Analys:

EHDS arkitektur är ett steg mot EUs övergripande mål om en gemensam marknad och dataportabilitet. Samtidigt finns en risk att målen motverkas genom att data transformeras vid NCP (Vårdsystemen behöver inte anpassas mot standards).

Det går inte heller att utläsa hur EHDS/MyHealth@EU stödjer forskning. Indirekt kommer dock standardiserade dataformat och informationsmängder gagna forskning när åtkomst är möjlig.

Tidplan för EHDS/MyHealth@EU 

Det har varit svårt att hitta en detaljerad tidplan. T.ex. arkitektur och interoperabilitet specifikationer är markerade ”operation-ready” men det är inte tydlig hur och när dessa är fastslagna. En agil metodik tillämpas där leveranser kommer i ”waves”. Jag har uppfattat som att man nu påbörjar iteration (wave) 9 av 10.

• 2027-03-26 European Electronic Health Record Exchange Format (EEHRxF) fastslagen.

• 2029-03-26 förväntas EHDS/MyHealth@EU ”go-live” där medlemsländer stödjer prioriterade informationsmängder ”patient summary”, ”electronic prescriptions” och ”dispensations”.

  • Här ingår att anslutna vårdsystem (EHR systems) skall vara CE märkta för ovanstående gällande dataformat CDA/CCD eller EEHRxF samt loggnings komponent (common specifications under Art. 36).

• 2031-3-26 skall medlemsländer stödja ”medical images”, ”medical tests results” och ”discharge reports”.

  • Här ingår att anslutna vårdsystem (EHR systems) skall vara CE märkta för ovanstående dataformat CDA/CCD eller EEHRxF samt loggnings komponent.

Förkortningar

Förkortning	Betydelse
EHDS	European Health Data Space
MyHealth@EU	Infrastruktur för primär användning av hälsodata (patientvård)
HealthData@EU	Infrastruktur för sekundär användning av hälsodata (forskning, policy)
NCP / NCPeH	Nationell kontaktpunkt (eHealth); svensk gateway till EU-infrastrukturen
NDI	Nationell digital infrastruktur (svensk)
CDA	Clinical Document Architecture (HL7 standard)
FHiR	Fast Healthcare Interoperability Resources (HL7 standard)
XCA	Cross-Community Access (ITI-38/39)
XDR	Cross-Enterprise Document Reliable Interchange (ITI-41)
XCPD	Cross-Community Patient Discovery (ITI-55)
SMP	Service Metadata Publisher
SML	Service Metadata Locator
TLS	Transport Layer Security
SAML	Security Assertion Markup Language
TRC	Treatment Relationship Confirmation
IdA	Identity Assertion (HP Identity)
PN	Participating nation (Används i EHDS dokumentation)
NI	National infrastructure. Motsvarar NDI eller Inera Infrastruktru
HP	Healthcare Professional (Vårdgivare, används I EHDS dokumentation)
HCPO	Healthcare Professional Organization (Vårdgivare används I EHDS dokumentation)
EEHRxF	European Electronic Health Record Exchange Format.

Nationell kontaktpunkt (NCP)

Varje medlemsland etablerar och ansluter en s.k. kontaktpunkt (NCP). NCP ansvarar för att exponera EHDS/MyHealth@EU tjänster samt integrera mot lokal nationell infrastruktur (NI).

EHDS stödjer följande integrationsgränssnitt:

Integrationsprofil	Beskrivning
Söka patientuppgifter, Hämta patientuppgifter ITI-38 CrossGatewayQuery och ITI-39 CrossGatewayRetrieve (XCA) (epSOS-1 äldre version) ·      fetchDocumentRequest ·      fetchDocumentResponse (epSOS-2 ny version) ·      findDocument ·      Retrieve	Integrationsprofil för att lista och hämta informationsmängder enligt dataformat CDA/CCD..
Skicka patientuppgifter ITI-41 Provide and Register Document Set-b (XDR)	Integrationsprofil för att överföra (skicka/push) patientuppgifter till en vårdgivare inom EHDS/MyHealth@EU. Se även analys nedan.
Hämta unik patientidentifierare ITI-55 CrossCommunityPatientDiscovery (XCPD)	Tjänsten möjliggör för EU-land att hämta medborgarens unika patientidentitet.

Analys:

Integrationsprofilen “Skicka patientuppgifter” (XDR provideDataRequest) adresseras endast med landskod (ISO 3166-1 alpha-2 country code). I en svensk kontext kommer tjänsten att bli svår om inte omöjlig att stödja då adressering endast sker med patient-id(personnummer) och landskod. Integrationsprofilen stödjer inte att adressera en vårdgivare.

Det finns heller inget adresseringskoncept för att stödja detta behov inom EHDS/MyHealth@EU.

Söka patientuppgifter, Hämta patientuppgifter (XCA CrossGatewayQuery) förutsätter att en ”patientindex tjänst” (Engagemangsindex) med aggregerandetjänster finns tillgänglig inom den svenska nationella digitala infrastrukturen (NDI)

Övrigt:

En notifieringsfunktion beskrivs övergripande inom EHDS/MyHealth@EU. Det är dock oklart hur det skall fungera tekniskt samt vilken aktör som ansvarar för notifiering. I nuvarande version av arkitektur och interoperabilitet specifikationer är markerade ”operation-ready” används XCA, XDR och XCPD. I kommande versioner kan en REST arkitektur med FHIR (Xt-EHR/EEHRxF) bli aktuell. Det finns dock indikationer på att FHIR resurser kan skickas i samma SOAP WS mönster.

Tjänster - NCP

EHDS/MyHealth@EU tekniska regelverk specificerar protokoll för informationsöverföring mellan medlemsländers s.k. nationella kontaktpunkter (NCP). NCP är komponenten som hanterar trafik mellan Sveriges infrastruktur och EU-nätverket (eHealth Digital Service Infrastructure (DSI)). Genom NCPs tjänster kan vårdgivare söka, hämta och skicka patientuppgifter inom EHDS-anslutna medlemsländer.

Arkitekturen har följande övergripande komponenter:

• Data exchange – Tjänster för att stödja integrationsprofiler

  • SOAP 1.2 med WSDL 1.1 och WS-Security 1.3 (SAML Token Profile). Alla meddelanden måste följa WS-I Basic Profile 1.1 och WS-I Basic Security Profile 1.1.

• Security and trust services

  • Åtkomstkontroll för nyttjande av EHDS tjänster

  • TLS terminering

• Audit services

  • Loggning (Audit)

• Treatment Relationship

  • Vårdrelation

  • Tjänst som ”intygar” att vårdrelation finns vilket intygas av vårdgivaren. Detta överförs tekniskt genom Web Services Security UsernameToken Profile 1.0 eller SAML assertioner i WS-Security (Otydlig dokumentation kring vad som gäller)

• Semantisk mappning patientuppgifter mot standarder och kodverk

Analys:

Utifrån ett svenskt perspektiv kommer sannolikt ”semantisk mappning” inte skötas av centrala komponenter. Respektive vårdgivare och dess vårdsystem (tjänsteproducenter i NDI) kommer behöva hantera detta.

I nuvarande version av arkitektur och interoperabilitet specifikationer markerad ”operation-ready” används SOAP WS. I kommande versioner kan en REST arkitektur med FHIR (Xt-EHR/EEHRxF) bli aktuell.

Det är svårt att bedöma om FHIR ingår i slutlig produktionsversion då många länder verkar ha kommit lång med implementation och tester.

Säkerhet EHDS/MyHealth@EU 

Grunden för säkerhet inom EHDS/MyHealth@EU är tillitsbaserad (Circle of trust). Transportkryptering genom mTLS (Patientuppgifter skyddas under transport). Säkerhet baseras på klassisk ”certifikats tillit”.  

Transportnivå	All trafik går i TESTA-ng (EU-kommissionens privata myndighetsnät). Länkar kan skyddas med IPsec ESP och ovanpå detta TLS 1.2 (MUST) / TLS 1.3 (RECOMMENDED) med ömsesidig autentisering(m/TLS). Cipher-suites ska följa SOG-IS 2020.
Meddelandenivå (NCP-till-NCP)	WS-Security 1.3 används i SOAP-headern. Upp till tre SAML 2.0-assertioner kan förekomma: HP Identity Assertion (IdA), Treatment Relationship Confirmation (TRC) och ev. Next-of-Kin Assertion. Dessa länkas ihop via saml:Advice. Signering görs med NCP:s X.509-certifikat: Request (NCP-B → NCP-A): signera /Envelope/Body + /Envelope/Header/Security/Assertion. Response (NCP-A → NCP-B): signera /Envelope/Body. Signaturalgoritm: rsa-sha256 Digest: sha256 Canonicalization: Exclusive XML Canonicalization (xml-exc-c14n)
Meddelandenivå (vårdgivare-till-vårdgivare)	Meddelandekryptering “end-to-end” ska tillämpas. Meddelandet krypteras hos vårdgivaren som lagrar informationen (Detta område är inte helt tydligt i specifikationer, se analys nedan). RSA nycklar används för signering (ev kryptering)
Tillit till certifikat	Giltiga NCP certifikat utbytes som en del av bilateral anslutning och certifikatverifiering utförs av NCP genom att kontrollera om certifikatet är registrerat i ”trusted-list”. Certifikatets giltighet ska kontrolleras antingen med OCSP eller CRL (beroende på vilka protokoll CA erbjuder).
Åtkomstkontroll	NCP noden ansvar för åtkomstkontroll av inkommande och utgående trafik. Säkerställa inkommande och utgående trafik via EHDS/MyHealth@EU Säkerställa vårdpersonals identitet (tillit?) Vårdgivarens identitet, roll och ändamål styrks via SAML 2.0 / IHE XUA, inkl. Treatment Relationship Confirmation (TRC)  Eventuell vårdnadshavare/ombud (Next of Kin (NoK) assertion)
eID och autentisering	Hälso- och sjukvårdspersonal (HP) autentiseras nationellt och deras identitet bäddas in som SAML/XUA assertioner i WS-Security. eIDAS 2 (EUDI-wallet) introducerar ett nytt ramverk för stark autentisering på EU-nivå, men i EHDS används nationella autentiseringslösningar som integreras i NCP. Autentiserad vårdpersonals identitet skall bifogas vid anrop till NCP. Loggning

Analys:

Regelverket och specifikationer indikerar att information ska skyddas med s.k. “end-to-end” kryptering (vårdsystem-till-vårdsystem).

Krav: “securing electronic communications. In order to respect the dictates of the patient consent directive, endpoints of the encryption MUST be located within environments either controlled by the patient directly or by the professional healthcare organizations authorized by the patient for processing his/her medical data”

• I dokumentationen finns formuleringar om ”end-to-end message encryption” säkerhet (vårdgivare till vårdgivare), i praktiken är det transportnivån (TLS/IPsec) och WS-Security som används för att säkra kommunikation mellan NCPer. Denna lösning linjerar inte med säkerhetskraven.

  • End-to-end message encryption är inte implementerad i nuvarande  MyHealth@EU.

  • Jag har inte heller hittat några testfall för meddelandekryptering eller meddelandesignering.

• Det är inte heller lämpligt att rulla ut säkerhetsarkitektur som baseras på RSA. Krypto bör baseras på ECC även om ECC inte är Post-Quantum Cryptography (PQC) säkrat.

Det finns också utmaningar i Sverige. Här definieras sekretessgränser på vårdgivarnivå, medan EHDS-arkitekturen främst stödjer sekretess på nationell nivå.

• T.ex. kan inte centrala tjänster som semantisk mappning utföras på krypterad eller signerad information om försegling (kryptering/signering) sker på vårdgivarnivå.

• Centrala tjänster (Service registry) för att säkerställa riktighet inom EHDS haltar då publika nycklar endast publiceras per land och tjänst(integrationsprofil).

Hur ”Trusted-List” är implementerat är otydlig, men realiseras sannolikt genom användande av SMP där metadata som publika nyckel kan utbytas dynamiskt. En dedikerad CA för EHDS/MyHealth@EU skulle förenkla denna hantering avsevärt.

Informationsmängder

De informationsmängder som kan hanteras av EHDS definieras enligt HL7 CDA.

• Patient Summary

• ePrescription / eDispensation

• Laboratory Results

• Medical Images and Image Reports

• Hospital Discharge Reports

Enligt gällande dokumentation kommer formatet FHiR användas I framtiden. FHiR (Xt-EHR/EEHRxF) är på gång men ej drift än. I produktion används CDA.

Analys:

Enligt gällande dokumentation kan FHIR resurser enligt EEHRxF komma att implementeras i framtiden.

FHIR är primärt framtaget för en REST arkitektur. EHDS integrationsprotokoll är baserade på SOAP Webservice vilket innebär att funktionalitet begränsas kraftigt.

FHIR över SOAP fungerar, men:

• FHiR-resurser är designade för REST (CRUD-operationer, resurs-URL:er, HTTP-statuskoder).

• Länkade resursoperationer kommer inte vara möjliga.

• Man förlorar enkelheten och det rika stödet från REST-ekosystemet.

• Det kräver extra arbete för transaktioner, felhantering, identitet, service discovery och orkestrering.

• SOAP-varianten kan passa i stora organisationer med tung SOA-infrastruktur, men är sällan optimal för nya implementationer.

I nuvarande version ”operation-ready” tillämpas CDA.

 

Centrala EHDS tjänster – Service registry

Inom EHDS (eHealth DSI) finns en tjänst som dynamiskt hanterar metadata för medlemsländers NCP. Tjänsten ”Service registry” (baseras på Service Metadata Locator – SML och Service Metadata Publisher - SMP) lagrar metadata som teknisk adress och säkerhetsartefakter (certifikat för meddelandesignering) och dess servercertifikat.

Tjänsten är central(kritisk) för informationsutbyte mellan medlemsländer och används för att hämta mottagande NCP metadata som teknisk adress och certifikat (cache medges).

• Det är en federerad modell: DNS/BDXL → SMP → endpoints. BDXL/SMP följer eDelivery 2.0-specifikationerna

• Metadata signeras av EHDS/MyHealth@EU operatören för att säkerställa riktighet.

Enligt dokumentationen kan även metadata peka ut en SAML IdP som måste användas av anropande part. Detta är dock inte vidare dokumenterat hur det skall användas i praktiken.

Följande metadata är central:

Attribut	Beskrivning
ParticipantIdentifier	Medlemslandets unika identifierare. Ska följa formatet “urn:ehealth:” + country code + “ncpb-idp”   e.x. urn:ehealth:se:ncpb-idp
DocumentIdentifier	Identifierar vilken integrationsprofil som NCP stödjer enligt mönster: "urn:ehealth:" + interaction pattern + "::" + event name + "##"+EventID / Transaction and ProcessIdentifier as "urn:" + event name, Ex XCA Profile. urn:ehealth:RequestOfData::XCA::CrossGatewayQuery##ITI-38
ProcessIdentifier	Tjänstens URI Ex: urn:XCA::CrossGatewayQuery
Endpoint transportProfile	Tjänstens transportprofil. Referens till integrationsprofilens urn. ·      urn:ihe:iti:2013:xcpd ·      urn:ihe:iti:2013:xds ·      urn:ihe:iti:2013:xca ·      urn:ihe:iti:2013:xcf
EndpointURI	URL, teknisk adress till tjänsten.
Certificate	Tjänstens publika certifikat. Kan sannolikt användas för att identifiera NCP nodens publika nyckel(trusted list), verifiera tjänstens signaturer eller kryptera meddelanden.
X509Certificate	Dokumentation saknas men skulle kunna representera NCP nodens publika nyckel.

Analys:

SMP komponenten är central för dynamisk adressering och hämtning av metadata för mottagande NCP. SMP skapar en lös koppling för adressering och säkerhetsartefakter.

• Mottagarens tekniska adress och publika nyckel hämtas vilket är centralt för meddelandeöveringen och meddelandesäkerhet så som kryptering och signering (konfidentialitet, riktighet). 

Den metadatamodell som används inom EHDS stödjer inte end-to-end kryptering och signering i ett svenskt perspektiv (vårdgivarnivå). 

Kort om dynamisk adressering:

Inom eDelivery kallas detta ”dynamic discovery” (DNS → SMP → Endpoint).

1. Adressering använder NAPTR (Naming Authority Pointer) som är en typ av DNS-post som för att mappa en Participant Identifier till en faktisk adress(URL). URL leder till SMP tjänsten som hanterar NCP metadata

2. Anropande part kombinerar SMP URL med “documentidentifier” för att kunna hämta signerad metadata (endpoint URL, certifikat) för medlemslandets NCP och tjänst.  

Ex:

Participant Identifier = urn:ehealth:se:ncpb-idp

Document Identifier = urn:ehealth:RequestOfData::XCA::CrossGatewayQuery##ITI-38

Anslutning till EHDS/MyHealth@EU 

Anslutning till EHDS/MyHealth@EU sker bilateralt där varje medlemsland gör sin egen anslutning mot respektive medlemsländers NCP. End-to-end tester genomförs per informationsmängd:

• Patient Summary (PS)

• ePrescription (eP) / eDispensation (eD)

• Original Clinical Document (orCD)

• Laboratory Results Report (LRR)

Enligt ramverk sker tester koncentrerat under två veckor och ska säkerställa att riktiga användare (läkare, farmaceuter) i testmiljö kan söka, förstå och använda information från andra länder, och att hela infrastrukturen fungerar ihop.

Analys:

Det finns utmaningar med anslutningsförfarandet i en svensk kontext. Varje vårdgivare (region, kommun, privata aktörer) har sitt eget vårdinformationssystem. Informationsmängderna finns spridda i många system, inte i ett enhetligt journalsystem.

När Sverige ansluter sig till EHDS/MyHealth@EU  görs testerna mot ett specifikt vårdsystem som är anslutet.

I andra länder kan det vara så att det finns ett(1) nationellt journalsystem eller en central tjänst som samlar informationsmängder från alla vårdgivare. Vid E2E tester representerar det hela landets informationsinnehåll.

I Sverige uppstår följande risker och konsekvenser

• Begränsad täckning i testerna. Om endast ett svenskt journalsystem används vid tester riskerar man att bara verifiera en liten del av Sveriges variation i informationsmängder.

• Interoperabilitetsgap. Sverige kan uppvisa ”godkända tester” med ett system, men i praktiken uppstår problem när andra regioner/vårdgivare ska anslutas.

• Olika styrmodeller. Länder med centraliserad vårdinfrastruktur (t.ex. Estland, Finland) får enhetlig kvalitet och konsekvens i testning. Länder med decentraliserade system (t.ex. Sverige, Tyskland) måste lägga stora resurser på governance, testning i flera miljöer och nationell harmonisering.

Nationell infrastruktur

EHDS/MyHealth@EU noden NCP ska anslutas till respektive medlemslands lokala infrastruktur.

Varje medlemsland definierar sin nationella infrastruktur där vårdgivare (och andra kvalificerade aktörer) ansluts. Genom anslutningen möjliggörs informationsflöden inom EU via EHDS/MyHealth@EU. EHDS/MyHealth@EU reglerar inte direkt hur medlemsländers nationella infrastruktur skall utformas men indirekt via arkitekturens utformning kommer anpassningar vara nödvändiga.

E-hälsomyndigheten (EHM) kallar den ”Nationell digital infrastruktur” (NDI).

Utifrån ett EHDS/MyHealth@EU perspektiv behöver infrastrukturen (NDI) utformas för att stödja: 

• Anslutningsprocess

  • Ansluta vård- och omsorgsaktörers vårdsystem. Här ingår kundkännedom och avtalshantering vilket är en omfattande process. Speciellt om andra aktörer än vårdgivare med offentligt uppdrag skall anslutas.

• Regelverk och specifikationer

  • Säkerställa följsamhet till tillitsramverk, regelverk, och tekniska specifikationer för åtkomst via EHDS.

• Arkitektur för integration med vårdsystem.

• Stödtjänster

  • Katalogtjänst för hantering av vårdgivare och vårdpersonal.

  • Patientindex (Motsvarande Inera engagemangsindex*) – en tjänst för att hitta patientuppgifter i anslutna vårdgivarna vårdsystem. Detta möjliggör sökning baserat på patient id (personnummer).

  • Sammanställningstjänst (Motsvarande Inera Aggregerande tjänster*)

*SKR bolaget Inera AB ansvarar idag för den etablerade nationella infrastruktur som svensk vård är ansluten till. Där finns även tjänster som motsvarar behov som uppstår utifrån ett EHDS perspektiv.

EHM arbetar med NDI där svar på ovanstående behov sannolikt finns. Kommande blogginlägg kommer fokusera på hur NDI kan etableras samt hur Ineras infrastruktur löser dessa behov. Där kommer även Ineras nya arkitektur ”T2” analyseras.

Krav på vårdgivare och vårdsystem

Kraven på vårdgivare och vårdgivarnas system är omfattande utifrån ett informationsförsörjningsperspektiv. Offentligt finansierad vård har under många år använt Ineras infrastruktur där ”EHDS/MyHealth@EU motsvarande” informationsflöden hanteras.

För att anslutning till nationell digital infrastruktur skall vara möjlig behöver vårdsystem (journalsystem) anpassas.

• Autentisera vårdpersonal med 2-faktors inloggning enligt eIDAS2.

  • Stark autentisering (2-faktor enligt eIDAS2) av vårdpersonal skall tillämpas

• Stödja säkerhetsprotokoll (T.ex. stödja kryptering och signering av meddelanden end-to-end)

• Exponera vårdinformation enligt fastslagna dataformat och informationsstandards (common specification, EEHRxF)

• CE märkning.

Analys:

Vårdgivare som idag är anslutna till Ineras infrastruktur kommer med stor sannolikhet stödja EHDS med förhållandevis begränsad insats om Ineras infrastruktur kan återanvändas.

EHDS innebär stora möjligheter men också betydande utmaningar för Sverige. Sveriges  decentraliserade struktur är inte helt kompatibel med EHDS.

Det kommer kräva mer governance, men med rätt samordning kan EHDS bidra till både bättre vård och starkare forskningsförutsättningar.

 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.

Genom denna blogg vill jag belysa möjligheter och utmaningar inom EHDS och skapa en plattform för dialog om hur Sverige kan forma sin nationella infrastruktur i samklang med EU:s krav – till nytta för både vården, forskningen och medborgarna.