edelivery Sven Rostgaard Rasmussen Digitaliseringsstyrelsen, INT MedCom, den 12. december 2018

Transkript

1 edelivery Sven Rostgaard Rasmussen Digitaliseringsstyrelsen, INT MedCom, den 12. december 2018

2 Agenda 1. Baggrund for edelivery 2. Hvad er edelivery 3. edelivery arkitektur og teknik 4. Sammenfatning 2

3 1. Baggrund for edelivery Stigende brug af data i forvaltning og sagsbehandling Automatisering af forretningsprocesser Behov for sammenhængende løsninger på tværs af myndigheder samt mellem private virksomheder og myndigheder øger markant behov for udveksling af data Automatiserings af processer sætter fokus på interoperabilitet Tværgående processer mellem organisationer stiller juridiske krav til gyldighed og uafviselighed Cyber trusler og krav om databeskyttelse medfører øgede krav til sikkerhed Eksempler på anvendelse: MedCom, Digital Post, NemHandel (PEPPOL) 3

4 2. Hvad er edelivery edelivery udspringer i europæisk kontekst edelivery er på vej frem med stærk backing fra EU - bl.a. for at sikre det digitale marked Implementeret i NemHandel (gennem PEPPOL) og flere andre sammenhænge (BRIS, ejustice m.m.) Designet til at være lovgivningsnært (eidas) - og ud fra principper for interoperabilitet edelivery i kontekst af FODS - Forankret i Initiativ 8.1 Gode data og effektiv datadeling Mønster er en del af Referencearkitektur for deling af data og dokumenter For-analyse har sat edelivery i en dansk kontekst og afklaret, at der ser ud til at være potentiale i at anvende edelivery i Danmark (med udgangspunkt i cases: NemHandel, MedCom, Digital Post) edelivery sætter rammerne men der er brug for en konkret, national implementering Hvordan kan en fællesoffentlig implementering af et dansk, edelivery netværk se ud? 4

5 Hvad er edelivery? CEF Digitale infrastrukturer: PARTY PARTY eid edelivery PARTY PARTY einvoicing esignature PARTY PARTY etranslation Other DSI s (*) CEF Connecting Europe Facility edelivery enables you to securely exchange data and documents 5

6 3.1 Delagenda: Teknisk analyse af edelivery 1. Hvordan virker et edelivery-netværk? 4 corner model Hvordan sendes en Meddelelse gennem edelivery? Centrale begreber 2. Hvordan skal det bygges? Hvilke nye, fælles komponenter? Hvordan etableres god sikkerhed? Hvilke registre kan anvendes til adressering? 3. Hvordan kan det tages i brug? Påvirkning af eksisterende systemer? Access Point-indpakninger og Service provideres rolle edelivery i forhold til øvrige netværk 6

7 3.1.1 Grundstruktur i et 4-corner edelivery-netværk AFSENDER MODTAGER In the 4 corner model, the backend systems Deltager A C1 C4 Deltager B of the users don t exchange data directly with System System each other but do this through Access Points. These Access Points are conformant to the Connector C2 Access Point SEND ACKNOWLEDGE Netværk MODTAG C3 Access Point Connector same technical specifications and therefore capable of communicating with each other. As a result, users can easily and safely exchange data even if their IT systems were developed independently from each other. Fleksibel model, der er sikker, skalerbar og understøtter eksisterende løsninger 7 Kilde: CEF Digital,

8 3.1.1 Eksempel: Forsendelse i kontekst af designvalg Skadestueepikrise 3: Tjek at SMP- og certifikater er af typen FOCES og ikke er udløbet eller revoked. Meddelelse: 1: Skadestueepikrise skal sendes til patientens praktiserende læge. Dennes Deltager-ID (her GLN-nr.) slås op i SOR. Meddelelse af typen Skadestueepikrise dannes og adresseres til GLN Korsbæk skadestue Sundhedsplatformen Nem Log-In 4: Tjek at SMP- og certifikater er på Trust list for Dansk edelivery. DK edel PKI Hansens Patient- System Dr. Hansen HEADER: MODTAGER: 0088: TYPE: SKADESTUEEPIKRISE PROCES: UDSKRIVELSE_SIMPEL TRANSAK.ID: XYZ123 PAYLOAD: <EPIKRISE I MEDCOM-FORMAT> 2: Tjek, om GLN kan modtage Skadestueepikrise: Opslag på <MD5-encoded Deltager-ID>.edelivery.dk Service Provider 1 Meddelelse Service Provider 2 7: Dr. Hansens system modtager Meddelelsen og parser payload ud fra den angivne TYPE edeliverykomponent Svar fra SMP: PROCES: UDSKRIVELSE_SIMPEL TYPE: SKADESTUEEPIKRISE ENDPOINT: <CERTIFIKAT PÅ VANS2 > <SIGNERET AF SMP> 8 DNS SML SMP 5: Adresser (udfyld kuvert), krypter, signer og afsend Meddelelse 6: VANS 2 verificerer VANS 1 s certifikat. På protokolniveau sendes signeret/krypteret kvittering, som VANS 1 verificerer 0: Dr. Hansen indgår aftale med VANS 2 om, at VANS 2 er service provider for MedCom-forsendelser til ham (GLN ). En VANS 2 admin registrerer dette i Dansk edelivery. SMP opdaterer SML, der herefter opdaterer DNS Alm. system Anden infrastruktur Disclaimer: Eksemplet er forsimplet og ikke nødvendigvis forretningsmæssigt dækkende eller 100% korrekt

9 3.1.1 Centrale begreber Skadestueepikrise Meddelelse: edelivery-standarden: Definerer standard for kapabilitetslookup samt udvekslingen af Meddelelser Korsbæk skadestue Sundhedsplatformen Nem Log-In DK edel PKI Hansens Patient- System Dr. Hansen HEADER: MODTAGER: 0088: TYPE: SKADESTUEEPIKRISE PROCES: UDSKRIVELSE_SIMPEL TRANSAK.ID: XYZ123 PAYLOAD: <EPIKRISE I MEDCOM-FORMAT> Service Provider 1 Meddelelse Service Provider 2 edeliverykomponent Svar fra SMP: PROCES: UDSKRIVELSE_SIMPEL TYPE: SKADESTUEEPIKRISE ENDPOINT: <CERTIFIKAT PÅ VANS2 > <SIGNERET AF SMP> 9 DNS SML SMP Disclaimer: Eksemplet er forsimplet og ikke nødvendigvis forretningsmæssigt dækkende eller 100% korrekt Et edelivery-baseret netværk er: - edelivery-standarden i midten - Et sæt af Deltagere - En aftalt adresseringsmetodik (register + kuvert) - En aftalt sikkerheds-infrastruktur (PKI) - Et aftalt sæt af Meddelelsestyper og Processer - En lukket klub for godkendte er og Deltagere Alm. system Anden infrastruktur

10 3.1 Delagenda: Teknisk analyse af edelivery 1. Hvordan virker et edelivery-netværk? 4 corner model Hvordan sendes en Meddelelse gennem edelivery? Centrale begreber 2. Hvordan skal det bygges? Hvilke nye, fælles komponenter? Hvordan etableres god sikkerhed? Hvilke registre kan anvendes til adressering? 3. Hvordan kan det tages i brug? Påvirkning af eksisterende systemer? Access Point-indpakninger og Service provideres rolle Dansk edelivery i forhold til øvrige netværk 10

11 3.1.2 Nye, fælles komponenter til edelivery Deltagere i nettet skal bygge Access Points; rekvirere et FOCEScertifikat samt registrere dette hos Dansk edelivery Korsbæk skadestue Sundhedsplatformen Ny infrastrukturkomponent er anker på Trust list af godkendte certifikater Nem Log-In DK edel PKI Hansens Patient- System Dr. Hansen Meddelelse: HEADER: MODTAGER: 0088: TYPE: SKADESTUEEPIKRISE PROCES: UDSKRIVELSE_SIMPEL TRANSAK.ID: XYZ123 PAYLOAD: <EPIKRISE I MEDCOM-FORMAT> Service Provider 1 Meddelelse Service Provider 2 Ny fælles komponent edeliverykomponent Svar fra SMP: PROCES: UDSKRIVELSE_SIMPEL TYPE: SKADESTUEEPIKRISE ENDPOINT: <CERTIFIKAT PÅ VANS2 > <SIGNERET AF SMP> 11 DNS SML SMP Den eksisterende EU-SML genbruges (med nyt name space, fx *.edelivery.dk) Disclaimer: Eksemplet er forsimplet og ikke nødvendigvis forretningsmæssigt dækkende eller 100% korrekt Der laves én ny, fælles dansk SMP, der registrerer og udstiller Deltagernes kapabiliteter Øvrig komponent Alm. system Anden infrastruktur

12 3.1.2 Etablering af god sikkerhed i edelivery End to end security mellem Corner 1 og 4: - Håndteres aftalestyret, evt. domænereguleret - Mulighed for signering/kryptering af Meddelelser end to end AFSENDER MODTAGER Deltager A C1 C4 Deltager B Inner security mellem Corner 1 og 2: Håndteres mellem Deltager og Service provider System C2 C3 System Inner security mellem Corner 3 og 4: Håndteres mellem Deltager og Service provider Connector Access Point SEND MODTAG Access Point Connector ACKNOWLEDGE Netværk 12 Cross party security mellem Corner 2 og 3: - edelivery leverer med AS4-profilen et state of the art sikkerhedsniveau - Certifikater er FOCES-baserede (kendt identitet, fungerende PKI-infrastruktur) - Forventes nødvendigt på sigt at åbne for øvrige PKI-infrastrukturer som konsekvens af EU-krav (eidas-forordningen)

13 3.1.2 Adressering En Afsender er ansvarlig for at adressere sin Meddelelse til en registreret Modtager Adressering kan ske inden for rammerne af: SOR Sundhedsvæsenets Organisationsregister (sundhedsdomænet) CVR-registreret (Digital Post-domænet) Dvs. at Modtager identificeres primært ved: GLN-nr. CVR-nr. edelivery tilbyder ikke søgefunktionalitet til at finde en specifik Modtager, fx baseret på navn. Sådanne adresseregisterservices kan evt. tilbydes af domæner, implementeret centralt eller hos en Service Provider 13

14 3.1 Delagenda: Teknisk analyse af edelivery 1. Hvordan virker et edelivery-netværk? 4 corner model Hvordan sendes en Meddelelse gennem edelivery? Centrale begreber 2. Hvordan skal det bygges? Hvilke nye, fælles komponenter? Hvordan etableres god sikkerhed? Hvilke registre kan anvendes til adressering? 3. Hvordan kan det tages i brug? Påvirkning af eksisterende systemer? Access Point-indpakninger og Service provideres rolle Dansk edelivery i forhold til øvrige netværk 14

15 3.1.3 Påvirkning af eksisterende systemer edelivery er agnostisk i forhold til indholdet af meddelelser 4 corner-modellen gør det let at integrerer eksisterende systemer Nødvendige informationer til håndtering af forsendelse i edelivery: Modtager-id Meddelelsestype Meddelelsesindhold De fleste systemer kan tilsluttes med ingen eller få tilretninger Evt. formatkonverteringer eller andre nødvendige tilpasninger kan håndteres ved tilslutningen til et Access Point edelivery håndterer interoperabilitet for routing, afsendelse, modtagelse og sikkerhed 15

16 3.1.3 Typiske indpakninger af Access Points 1. Fagsystemer tilføjer a. Eksempler: Postsystemer, økonomisystemer, lægepraksissystemer b. Betjener mange deltagere inden for specifikt domæne/forretningsbehov 2. Deltagers eget a. Sparer et integrationslag b. Måske mere relevant for store end for små? 1 or sever al Party A Backend NOTIFY ORIGINAL SENDER C1 C2 3. Service providers a. Gør onboarding nemmere afskærmer eksisterende løsninger b. Mulighed for brug af eksisterende integrationer Connector Access Point SEND RECEIVE Message Exchange Protocol ACKNOWLEDGE c. Kan integrere til ét eller flere edelivery-netværk med ét interface til C1/C4 d. Kan understøtte formatkonvertering/transformation, logning og øvrige value adds 16

17 3.1.3 Eksempel: Brug af Dansk edelivery sammen med PEPPOL, set fra en kommunes perspektiv MedCom platform Fordele for kommune: Kommune Mapning Log Data - Ét multi-purpose integrationspunkt Service provider X MedCom (tracket) MedCom (direkte) Service provider Y Sygehus Læge Frandsen Etc. - Én type integration - Én fælles sikkerhedsstandard - Central systemforvaltning af Dansk edelivery Post Fakturaer Indkøbs-ordrer Dansk Asfalt PEPPOL Dansk edelivery Digital Post e-trade" (service provider) Lyreco Etc. 17

18 3.1.3 Understøttelse af Digital Post skitse af muligheder for brug af edelivery Nedenfor er vist muligheder for brug af edelivery til at understøtte de klassiske forsendelsesmønstre i Digital Post Enhver fremtidig brug af edelivery i Digital Post-regi vil skulle besluttes i Digital Post-domænet Digital Post i dag Muligheder for fremtidig edelivery-understøttelse Digital Post Digital Post Afsender Meddelelse Aut. videresendelse Posthotel Meddelelse (portal) Modtager Afsender Meddelelse Aut. videresendelse Posthotel Meddelelse (portal) Modtager Meddelelse (aut., ) Service provider Afsendelse (via edelivery) Modtagelse (via. edelivery) Service provider 18 Klassisk forsendelse/videresendelse edelivery-understøttet afsendelse edelivery-understøttet videresendelse

19 4 Sammenfatning de vigtigste argumenter for anvendelse af edelivery Forbedret interoperabilitet Ved anvendelse af en fælles standard er det nemmere at udveksle meddelelser Service registeret (SMP) understøtter unikt publicering af services og processer samt versionering Høj sikkerhed AS4 profilen er "State of art" med EU valideret høj sikkerhed (ENISA) Fælles styring giver basis for monitorering af trusselsbillede og mitigeringstiltag Økonomisk attraktiv Genbrug af én løsning til mange formål Bedre konkurrence på løsninger uden "vendor lock-in" 19

20 20 Tak for i dag!