Indhold 0

(1)

MEDCOM Rambøll Management Consulting PETH/MTHAS/OVI

08-02-2019

Oplæg til evaluering af POC for modernisering af MedCom infrastruktur

Indhold

0 Om denne version ... 3

1 Indledning ... 3

2 Formål med projektet ... 3

2.1 Den nuværende situation (baggrund) ... 3

2.2 Formålet med projektets løsning ... 3

2.3 Projektets bidrag til strategiske mål ... 4

2.4 Den fremtidige situation efter indførelse af løsningen ... 4

2.5 Situationen hvis projektet ikke gennemføres (business as usual) ... 5

2.6 Alternative løsningsscenarier (Vurdér) ... 5

3 Afgrænsning ... 6

4 Status for eDelivery i international og national kontekst ... 6

5 Teknisk løsning ... 6

5.1 Overblik ... 6

5.2 Beskrivelse af de 4 varianter, der er afprøvet i POC ... 8

6 Deltagernes erfaringer og evaluering... 16

6.1 Generelt ... 16

6.2 Koncepter ... 17

6.3 Teknik... 17

6.4 Praktisk ... 17

6.5 Proces ... 17

7 Omkostninger til eDelivery og datadeling ... 18

7.1 Oversigt ... 18

7.2 Faseopdeling ... 18

7.3 Generelle omkostningsdrivere ... 18

7.4 Forberedelse ... 19

7.5 Centrale komponenter ... 19

7.6 Decentrale komponenter ... 19

7.7 Projektomkostninger ... 20

7.8 Governance ... 21

Hvis du har brug for at læse dette dokument i et keyboard eller skærmlæservenligt format, så klik venligst på denne knap.

(2)

8 Samlet evaluering ... 23

8.1 Hurtig, stabil og sikker overlevering af relevante datasæt ... 23

8.2 Stille relevante data til rådighed for onlinedeling på forespørgsel ... 23

8.3 Omlægning til datadeling ... 24

8.4 Deling af data på sundhed.dk og mobile platforme ... 24

8.5 Sundhedsfaglige og arkitekturmæssige valg ved overgangen til eDelivery og datadeling .... 24

8.6 Samlet konklusion og anbefaling... 24

(3)

0 Om denne version

Afsnit markeret med gråt er kopieret fra PID.

1 Indledning

Indeværende notat evaluerer den tekniske afprøvning af modernisering af den infrastruktur, der ligger til grund for landsdækkende anvendelse af MedCom standarder til løftelse af kvaliteten af

dataudvekslingen, både indenfor og på tværs af sektorer. Notatet evaluerer således på

projektet ”Modernisering af infrastruktur POC”, beskrevet i PID af 27. februar 2018. Projektet er en del af arbejdet med indsatsen ”Bedre, hurtigere og mere sikker digital kommunikation mellem sektorer” i Strategi for digital sundhed 2018-2022.

2 Formål med projektet

2.1 Den nuværende situation (baggrund)

Samtlige sygehuse, laboratorier, kommuner, apoteker og praksisydere anvender rutinemæssigt

MedCom kommunikation i det daglige samarbejde. MedComs standarder er indarbejdet i mere end 150 IT-systemer, og der udveksles månedligt ca. 5,5 millioner MedCom dokumenter mellem parterne.

MedCom kommunikationen bestod oprindeligt kun af EDIFACT beskeder udvekslet via det

kommercielle VANS-net. I takt med den teknologiske udvikling og fællesoffentlige beslutninger er der løbende gennemført moderniseringer af både standarder og distributionsmetoder. MedComs

standarder anvendes således aktuelt på fire forskellige måder, der sameksisterer parallelt:

1) EDI/OIOXML beskeder sendes via VANS-nettet (fx epikriser og genoptræningsplaner) 2) EDI sendes til central database, hvorfra der videresendes (fx henvisningshotellet) 3) OIOXML dokumenter udstilles via webservice direkte på Sundhedsdatanettet (fx

laboratorieområdet)

4) OIOXML- og HL7-dokumenter deles online via centralt repository og den Nationale Service Platform (fx hjemmemonitorerings -og PRO data)

En stor del af den tværsektorielle dataudveksling foregår imidlertid stadig som standardiserede beskeder via VANS-nettet. Den danske sundhedssektor står samtidig overfor organisatoriske ændringer, der fordrer et understøttende paradigmeskifte i MedCom kommunikationen:

• Færre, højt specialiserede sygehuse med kortvarige patientløb og hurtig overlevering af patienter til opfølgning i kommuner og praksissektoren

• Tæt og parallelt samarbejde mellem kommuner, praksissektor og specialister på sygehuse om behandling, pleje og omsorg

• Patienter og borgere, der fra eget hjem i stigende grad aktivt tager del i håndteringen af egen helbredssituation

2.2 Formålet med projektets løsning

Samlet set er formålet at afprøve en modernisering af den infrastruktur, der ligger til grund for

landsdækkende anvendelse af MedCom standarder, for at løfte kvaliteten af dataudvekslingen. Konkret anvises og afprøves MedCom kommunikationens muligheder for

• At stille relevante data til rådighed for onlinedeling på forespørgsel fra sundhedsfaglige parter i samarbejde om patient- og borgerforløb

(4)

2.3 Projektets bidrag til strategiske mål

Projektet udgør den praktiske udmøntning af initiativ 2.1 i Strategi for Digital Sundhed 2018-2022:

Bedre, hurtigere og mere sikker digital kommunikation mellem sektorer, hvor det fremgår:

Gennem de seneste 15-20 år er der sket en gennemgribende digitalisering af de mest almindelige beskeder, der sendes mellem sundhedsvæsenets sektorer, fx henvisninger og recepter. For borgere har det styrket sammenhængen i sundhedsvæsenets indsats, da relevante oplysninger om fx en plejehjemsbeboer lettere kan fremsendes til regionen, hvis borgeren kommer på hospitalet. For at understøtte hurtigere, mere sikker og fleksibel kommunikation har initiativet til formål at gennemføre en modernisering af det tekniske grundlag for kommunikationen, så der frem for punkt-til-punkt kommunikation, hvor kommunikationen sker fra én bestemt afsender til én bestemt modtager, igangsættes en omlægning til online deling af data og mere tidssvarende og mere sikre teknologiske platforme.

2.4 Den fremtidige situation efter indførelse af løsningen

Når moderniseringen af infrastrukturen er gennemført, er der skabt teknisk sammenhæng mellem den allerede udbredte meddelelsesbaserede MedCom kommunikation og de nye muligheder for online deling af data, baseret på næste generation af MedCom standarder.

Den tekniske sammenhæng sikrer

1. Mulighed for at kombinere meddelelseskommunikation med datadeling

2. Mulighed for omlægning af kommunikationsmønstre fra meddelelseskommunikation til datadeling

3. Mulighed for deling af data på portaler og mobile enheder

4. Mulighed for glidende migrering fra meddelelseskommunikation til datadeling

Figur 1 eDelivery overblik

Eksempel 1:Sygehuset kan fortsat fremsende en børneepikrise direkte til barnets praktiserende læge (meddelelseskommunikation), som afslutning på et indlæggelsesforløb og overlevering af barnet til opfølgning hos egen læge. Men det vil samtidig være teknisk muligt for den kommunale sundhedspleje på eget initiativ at hente den samme epikrise på forespørgsel (datadeling). Løsningen kombinerer meddelelseskommunikation med datadeling.

Eksempel 2: Alle relevante dele af kommunen kan abonnere på adviseringsservice, der indeholder opdateret information om en borgers indlæggelsesstatus på sygehuset. Advis-informationen autogereres på baggrund af sygehusets tidstro administrative registreringer. Løsningen er en omlægning af den allerede udbredte advis-kommunikation fra sygehuse til kommuner fra meddelelseskommunikation til datadeling.

Eksempel 3: Alle meddelelser og datadelingsservices gøres via infrastrukturen tilgængelige til udstilling af data på portaler og mobile enheder. Eksempelvis kan epikriser blive en integreret del af Sundhedsjournalen på sundhed.dk og samtidig stilles til rådighed for borgerrettede APPs.

(5)

Eksempel 4: Region X er på vej i udbud med sin EPJ-løsning og ønsker derfor ikke at omlægge Advis- kommunikationen fra meddelelseskommunikation til datadeling, før den nye EPJ-løsning er anskaffet og fuldt implementeret. Region Y er imidlertid sammen med områdets kommuner klar til en

koordineret omlægning til datadeling. Kommunernes borgere indlægges både i Region X og Y og der er derfor brug for, at Region X’s meddelelsesbaserede advis’er i infrastrukturen gøres tilgængelige for datadeling, så kommunerne kan udfase modtagelse af advis-meddelelser og omlægge til datadeling.

Løsningen muliggør, at den koordinerede omlægning sættes i gang, selvom ikke alle parter er klar samtidig.

2.5 Situationen hvis projektet ikke gennemføres (business as usual)

Den tværsektorielle udveksling af sundhedsdata i Danmark foregår p.t. i parallelle infrastrukturer, der af historiske årsager ikke hænger sammen: Den meddelelsesbaserede dataudveksling foregår fortsat primært i det kommercielle VANS-net. Delingen af medicindata foregår via det Fælles Medicin Kort (FMK) på den Nationale Service Platform (NSP). Delingen af hjemmemålinger, Patient Rapporterede oplysninger (PRO) og data omkring ”komplekse patientforløb” er planlagt til at foregå via

dokumentdelingsservicen på NSP’en. Overblik over den historiske udvikling findes i bilag¹.

Hvis ikke der gennemføres en konsolidering af den samlede infrastruktur, der sikrer en sammenhæng mellem de parallelle infrastrukturer, vil det være umuligt at foretage en glidende overgang fra gammel til ny infrastruktur. Derved vil den efterspurgte modernisering af den daglige/rutinemæssige

dataudveksling forudsætte høj grad af koordinering mellem alle regioner, kommuner og praksisydere, der sikrer, at alle parter flytter infrastruktur indenfor få uger (”big bang implementering”).

Hvis en målrettet oplægning til datadeling helt undlades, risikeres det, at der suboptimeres med etablering af lokale, tværsektorielle infrastrukturinitiativer, der vil betyde, at IT leverandører, der leverer løsninger til flere steder i landet, vil være tvunget til at sikre, at i øvrigt identiske IT løsninger kan anvende forskellige infrastrukturer og metoder til tværsektoriel dataudveksling. Manglende enighed på landsplan om den fremtidige infrastruktur til tværsektoriel udveksling og deling af data vil således hæmme udbredelse af den nye generation af landsdækkende MedCom standarder og dermed udhule økonomiske og forretningsmæssige gevinster ved de seneste 25 års fælles indsats for storskala ibrugtagning af tværsektoriel dataudveksling.

2.6 Alternative løsningsscenarier (Vurdér)

Det foretrukne løsningsscenarie introducerer en fællesoffentligt anskaffet ”MedCom gateway” som en nyt, central infrastruktur-komponent, der skal virke i tæt sammenhæng med eksisterende

infrastrukturer i regioner, kommuner, praksissektor, samt VANS, NSP og SDN. Dermed centraliseres en række funktioner, der alternativt kunne løses decentralt. Den centralistiske tilgang forudsætter afklaring af juridiske og informationssikkerhedsmæssige forudsætninger og politiske opbakning til offentlig hjemtagning af dataudvekslingsopgaver, der alternativt kan løses i et kommercielt marked, med flere private leverandører.

En alternativ og mere decentral/distribueret datadelingsløsning er fravalg af følgende årsager:

• Manglende mulighed for glidende migrering til moderne kommunikationsmetoder, uden at alle parter skal opretholde 2 metoder til landsdækkende udveksling af data

• Manglende mulighed for central mapning mellem MedCom’s EDIFACT, OIO-XML og HL7 standarder, der er en forudsætning for glidende udfasning af EDIFACT

• Manglende mulighed for central opsamling af statistiske oplysninger til brug for opfølgning på anvendelsen af MedCom standarder og dermed opfølgning på landsdækkende

implementeringsgrad.

• Risikoen for distribueret/fragmenteret overblik over driftsstatus

• Forudsætter 24/7 drift hos alle involverede systemer og tæt koordinering af servicevinduer

(6)

3 Afgrænsning

Modernisering af infrastruktur POC er 1 af 3 initiativer, der samlet set udgør en modernisering af MedCom kommunikationen, der er en central del af visionen for MedCom11 arbejdsprogrammet (2018-2019):

• Afprøvning af og roadmap for moderniseret udgave af MedCom kommunikationen, med særlig vægt på sikker deling af patientdata ved brug af internationale standarder

De 3 moderniseringsinitiativer er:

• Modernisering af Infrastruktur POC med fokus på mulighed for datadeling

• Standarder: Ibrugtagning af HL7 og roadmap for udfasning af EDIFACT

• Governance: Kvalitetsstyring af standardiseringsprocesser

Modernisering og kvalitetsstyring af standarder indgår løbende i MedComs portefølje, underlagt Sundhedsdatastyrelsens myndighedsopgave og arbejdet i det Rådgivende Udvalg for Standarder og IT Arkitektur (RUSA) og indgår dermed ikke i ”Modernisering af infrastruktur POC”.

Landsdækkende implementering af en moderniseret MedCom infrastruktur forventes at være en mangeårig proces og er derfor ikke en del af ”Modernisering af infrastruktur POC”. Projektets ambition er alene at fremskaffe et beslutningsgrundlæg for et efterfølgende implementeringsprojekt, baseret på praktiske erfaringer. Den egentlige videreudvikling af den nationale infrastruktur sker således

efterfølgende. Finansiering og beslutning om systemejerskab forventes fastlagt i forbindelse med økonomiaftalerne for 2020 mellem Regeringen, Danske Regioner og KL.

Supplering af de tekniske kvitteringer der anvendes i dag, med applikationskvitteringer, der sikrer at beskedudvekslingen ikke blot teknisk er sket, men at den modtagende applikation desuden har modtaget og accepteret den fremsendte meddelelse, er ikke inkluderet i dette moderniseringsprojekt, da det skønnes for omkostningstungt at skulle implementere i samtlige applikationer der integreres tværsektorielt i det danske IT-sundhed landskab.

4 Status for eDelivery i international og national kontekst

eDelivery-arkitekturen er udviklet og afprøvet gennem flere EU-projekter med deltagelse af adskillige medlemslande, herunder Danmark, som bl.a. deltager i PEPPOL (e-Faktura og e-Handel) og BRIS (The Business Registers Interconnection System). Arkitekturen har vist, at den kan løse behov for sikker udveksling af data og dokumenter på flere områder/domæner.

I Danmark arbejdes der med at forberede eDelivery-arkitekturen i regi af Den fællesoffentlige digitaliseringsstrategi 2016-2020 under initiativ 8.1 Gode data og effektiv datadeling. Der er

udarbejdet en analyserapport om eDelivery, der peger på, at eDelivery er velegnet til ”videregivelse ved meddelelse” svarende til beskedfordeling.

Erhvervsstyrelsen forventes at stille krav om eDelivery i en kommende bekendtgørelse om eFakturering, ligesom eDelivery forventes at indgå i næste generation Digital Post.

5 Teknisk løsning

5.1 Overblik

Modernisering af infrastruktur består af to store omlægninger

• Én samlet mere hurtig og sikker kommunikationsvej end det nuværende VANS

• Mulighed for datadeling fremfor beskedudveksling

(7)

Figur 2 eDelivery overblik Kommunikationskanal:

Den nuværende beskedudveksling udskiftes successivt med en hurtigere og mere sikker

kommunikationsvej, ved en række tiltag der erstatter de nuværende integrationer hos dels VANS og i de involverede organisationer. Opkoblingen til den nye MedCom gateway sker enten med DGWS via sundhedsdatanettet (og senere IDWS når denne er klar til at erstatte DGWS), eller alternativt fra de eksisterende VANS-operatører med AS4-standarden.

For at sikre så kort en kommunikationsvej som muligt, forsøges der etableret integrationer fra MedCom gateway så nært på de brugervendte applikationer som muligt. Ved overgang fra filbaseret udveksling via VANS, der erstattes med webservicekald via sundhedsdatanettet, overflødiggøres VANS-kvitteringer. De tekniske negative og positive kvitteringer bevares.

Princippet med asynkron integration bevares, med et centralt ”posthus”, idet samtlige

kommunikerende parter ikke driftsmæssigt er kørende 24/7. Import af beskeder kan foretages som i dag på anfordring, eller der kan modtages advisering om nye beskeder med brug af en revideret udgave af den nuværende adviseringsservice på NSP, eller en tilsvarende parallelt kørende ny adviseringsservice.

Med etablering af en central MedCom gateway simplificeres monitorering og statistik, der bl.a. giver en bedre mulighed for opfølgning på den kommunikation, der måtte fejle.

Det danske IT-sundheds landskab er komplekst, med mange systemer fordelt i mange organisationer, hvorfor der til stadighed vil være behov for at håndtere overgange, hvor blot en del af systemerne understøtter nye/reviderede standarder. For at lette implementeringer af ny funktionalitet, udvikles der en central mulighed for mapning mellem forskellige versioner af standarder. Dette betyder, at for nogle revideringer af standarder der ikke er radikalt anderledes end den forrige version, vil det være muligt for de pilotafprøvende systemer at ibrugtage den nye version, uden at samtlige

kommunikerende parter tilsvarende har implementeret understøttelse af den nye version.

SOR rummer information om hvilke standarder en kommunikerende part kan afsende og modtage, men det er ikke muligt at differentiere hvilke versioner det drejer sig om. Dette er der behov for, hvorfor en sådan hvem-kan-hvad oversigt udvikles som del af dette projekt.

Datadeling:

For de informationer det måtte være relevant, der i dag sendes med beskedbaseret udveksling mellem to parter, kan det muliggøres at dele disse informationer med andre sundhedsfaglige parter der har legitim ret til disse informationer. Adgangsgivningen er her et helt central spørgsmål, der løses i de nationale komponenter på NSP for samtykke, behandlingsrelation og logning.

De standarder den beskedbaserede udveksling er baseret på er i dag EDIfact og OIOXML, mens der sideløbende med dette moderniseringsprojekt for infrastrukturen afprøves en overgang til HL7 FHIR.

Uanset format er tanken at mappe informationer til et dokument i HL7 CDA og uploade dokumentet til dokumentdelingsservicen på NSP, med registrering af metadata i IHE XDS registry.

(8)

5.1.1 POC’ens forudsætninger

POC’en havde som sit primære fokus at skabe og implementere en helhedsorienteret arkitektur, hvori forskellige datadelingsparadigmer kunne afprøves og vises ved så vidt muligt at sætte allerede kendte komponenter sammen i en ny sammenhæng og dermed understøtte PID’ens fokus på at afprøve en måde at lave glidende overgang mellem datadeling på videregivelse i form af den velkendte

meddelelsesudvekslingspraksis og datadeling på forespørgsel, som den f.eks kendes fra NSP’en.

Styregruppen for POC’en udtrykte på sit første møde i august et klart ønske om at fokusere på innovationsaspektet frem for sikkerhedsaspektet i afprøvningen, hvorfor alle sikkerhedsmekanismer blev nedtonet, hvor dette kunne give benspænd ift. at nå i mål med også den praktiske afprøvning inden nytår 2018. Dette betød bl.a. at det ikke var vigtigt at anvende certifikater i eDelivery meddelelsesudvekslingen, og at der ikke fokuseredes på at etablere en sikkerhedsmæssig kontekst omkring afprøvning REST-baserede services i forbindelse med FHIR-serveren.

5.2 Beskrivelse af de 4 varianter, der er afprøvet i POC

Herunder beskriver MedCom detaljeret, hvilke varianter der er afprøvet.

5.2.1 POC’ens eDelivery fundament

MedComs tilgang til eDelivery var i forberedelsen af POC’en at afprøve om CEF’s (EU’s Connecting Europe Facility) open source-komponenter i denne model, Domibus AP (Access Point) og SMP (Service Metadata Provider), kunne tages i anvendelse. Vi undlod bevidst at arbejde med SML (Service

Metadata Locator), da dens funktion i princippet udelukkende er at udpege, hvilken SMP en given GLN- modtagers kapabiliteter er registreret i. Komponenterne viste sig at være ganske anvendelige og robuste, hvorfor de blev grundstenene i POC’en. Vi anvendte generelt i POC’en en generisk modtageradresse, således at der i princippet kan sendes en hvilken som helst dokumenttype (meddelelsestype) i dette setup. I en produktionsmoden verden ville registreringerne i SMP være meget specifikke ift. meddelelsestype.

SML og SMP anvendes i sammenhæng normalt til at håndtere de dynamiske opslag, hvor først SML og dernæst den korresponderende SMP kaldes for en given GLN-enhed. SMP udgør i praksis en udvidet adressebog ift. eksempelvis SOR, hvor en kombination af ”partnerskabstabellen” i SOR og de

eksisterende VANS-leverandørers konfigurationer af fysiske adresser for en given GLN-enhed udgør en for alle brugere af SMP transparent kapabilitetsregistrering. Til sammenligning synkroniserer backend systemer i dag med SOR med jævne mellemrum, nogle dagligt andre ugentligt eller sjældnere, således at en given GLN-modtagers kapabiliteter kan slås op her, mens man overlader til VANS at håndtere de fysiske adresseringer via VANS leverandørernes egne konfigurationer af koblingen mellem SOR- kapabiliteterne og deres egne adresseregistreringer.

Vi anvendte 2 typer registreringer i SMP, ”opkomst” og ”distribution”, således at både 4- og 3-corner modellerne kunne afprøves. ”Distribution” anvendes forskelligt i hhv. 4- og 3-corner modellerne, i 4- corner modellen som den direkte adresse til modtager, mens den i 3-corner modellen anvendes som den del af flowet, som sker fra Gateway’en/Hub’en frem til slutmodtager. ”Opkomst” anvendes kun i 3- corner modellen til at håndtere den første del af flowet, hvor den første opkomst af en meddelelse på eDelivery infrastrukturen skal sendes frem til den intermediære part i flowet, Gateway’en. Gateway’ens fysiske adresse, C2s AP, vil i 3-corner sammenhæng altså altid repræsentere en opkomst-adresse, mens C3s AP altid vil repræsentere distribution-adressen.

Generelt anvendte vi MedComs Genoptræningsplans-meddelelse (GGOP) Korrespondance-meddelelse (XDIS91) og Positiv Kvitterings-meddelelse (XCTRL03) alle i xml-format. Disse meddelelser var udvalgt, fordi de i løbet af POC’ens udviklingstid potentielt ville være tilgængelige som hhv. CDA- version og FHIR-version ifm. andre projekter, som MedCom var involveret i. CDA versionen af GGOP blev i denne sammenhæng skabt ud fra en relativ primitiv xslt transformering af GGOP’en,

tilstrækkelig dog til at kunne opfylde CDA standarden, OIOXML’en XDIS91 nåede ikke at blive færdig som FHIR version, og den blev derfor i afprøvningen blot ”transformeret” (dvs. indpakket) i en FHIR Communication ressource, som blev sendt til FHIR serveren, og derfra kunne hentes og udpakkes igen som OIOXML. Formålet her var ikke at afprøve REST baserede kald ifm. datadeling på forespørgsel, og derfor blev der ikke gjort mere ud af transformationsdelen.

(9)

Udeladelse af en SML viste sig i praksis at betyde, at de dynamiske opslag i SMP ikke blev helt så dynamiske som forventet, idet det snarere blev en dynamisk synkronisering af alle registreringer i SMP end et direkte opslag på det enkelte GLN-nummers kapabiliteter. Dette kan gå i et test setup, men ville naturligvis skulle implementeres korrekt i et produktions-setup.

5.2.2 Afprøvning af eDelivery’s 4-corner model

eDelivery’s 4 corner model er grundmodellen i eDelivery infrastrukturen og den model, der er mest sammenlignelig med den eksisterende VANS infrastruktur.

I udviklingen af POC’en sattes en testapplikation1 (C1) til at sende en XDIS91 pakket ind i eDelivery’s SBDH-Konvolut (Standard Business Document Header) via en Domibus instans kaldet Red (C2) til en anden Domibus instans kaldet Blue (C3) og videre til en modtagende testapplikation2 (C4). Red (C2) slog testapplikation2s ”distribution” modtageradresse (Blue (C3)) op i SMP, sendte SBDH(XDIS91) pakket krypteret ind i AS4, modtog behørigt sin AS4-kvittering, hvorefter Blue (C3) videregav SBDH(XDIS91) til den modtagende testapplikation2 (C4). Testapplikation2 (C4) tilhørende Blue (C3) agerede på kravet om positiv kvittering og sendte derfor en SBDH(XCTRL03) den modsatte vej via Blue (C3), som slog Testapplikation1s ”distribution” modtageradresse op i SMP og sendte tilsvarende SBDH(XCTRL03) pakket krypteret ind i AS4, Red (C2) svarede med en AS4-Ack og videregav

SBDH(XCTRL03) til den oprindeligt afsendende testapplikation (C1).

Figur 3 - CEF's eDelivery 4-corner model

Dette er simuleringen af en helt normal meddelelsescyklus i VANS-nettet blot tilført dynamisk opslag i SMP og anvendelse af åbne internationale standarder, alle sammen specificeret i OASIS-regi.

I Connectathon-setuppet agerede RegionSyds Cosmic Applikation i produktion C1 med en tilhørende Domibus-instans, C2, opereret af KMD. Herimellem anvendte RegionSyd og KMD deres sædvanlige Cloverleaf og VANS-setup. Modtagende parter (C4) udgjordes af hhv. PLSP og MedComs Testcenter, PLSP (C4) repræsenteret af MultiMed, med egenudviklet Access Point (C3) (videreudviklet fra en Peppol Access Point baseret på AS2) og MedComs Testcenter (C4) med et TrueCommerce Domibus baseret Access Point (C3).

I ”Figur 4 - Sekvensdiagram af 4-corner modellen” ses flowet grafisk af denne kommunikation.

(10)

RegionSyd

Ansat Cosmic PLSP

Send XDIS91

AS4(Ack)

KMD AP PLSP AP

Send AS4(SBDH(XDIS91))

Send SBDH(XDIS91) Send SBDH(XCTL03)

Send AS4(SBDH(XCTL03)) AS4(Ack) Send SBDH(XCTL03)

SMP

getAddress (PLSP, distribution)

Figur 4 - Sekvensdiagram af 4-corner modellen

5.2.3 Afprøvning af eDelivery’s 3-corner model

Formålet med afprøvning af 3-corner modellen, som i princippet ”blot” er 2 4-corner modeller sat sammen, er at kunne indsætte en gateway, som kan agere på en række forskellige måder, alt efter hvilket udbytte man vil have af en sådan enhed. Gateways kan bruges som integratorer mellem 2 forskellige net, oversætte formater fra afsender til modtager, opsamle statistik, centralt overvåge nettrafikken, kopiere meddelelser til brug i anden sammenhæng såsom datadeling. Man skal i dette eDelivery setup skifte forståelse af corner-betegnelserne, idet de ikke optræder med samme logik som i 4-corner modellen. Backendsystemet og dets AP smelter sammen til C1 hhv. C3 i

modtagersituationen, mens Hub/Gateway får betegnelsen C2.

Der etableres altså 2 4-corner scenarier, hvor C1 interagerer direkte med C2, og hvor C2 interagerer direkte med C3. Det eneste, der adskiller de 2 scenarier, er at man i SMP søger efter hhv. ”opkomst”- adresser og ”distribution”-adresser. Selvom et sekvensdiagram ser mere uoverskueligt og komplekst ud, er der intet uoverskueligt i det praktiske, som hver enkelt part skal foretage sig.

En mere kompleks version af det ovenfor beskrevne følger her, hvor den detaljerede beskrivelse af sekvensdiagrammet udfoldes. Det følgende kræver tungen lige i munden!

I det følgende betegnes Backendsystem og AP hhv. C1_1 og C1_2 i afsendersituationen, Gateway og dens AP betegnes hhv. C2_1 og C2_2, mens modtagersystemets backend og AP betegnes C3_1 og C3_2.

For at kunne adressere korrekt i 3-corner modellen, opererer en modtager, som tidligere nævnt, med både en ”opkomst” adresse og en ”distribution” adresse, hvor den første bruges første gang en meddelelse optræder i eDelivery-infrastrukturen, mens ”distribution” bruges, når den samme meddelelse videreformidles i infrastrukturen.

I udviklingen af POC’en sattes

- testapplikation1 (C1_1) til at sende en XDIS91 pakket ind i eDelivery’s SBDH-Konvolut (Standard Business Document Header) via Red (C1_2)

- Red (C1_2) slog testapplikation2s ”opkomst” modtageradresse for XDIS91, dvs. Gateway’ens AP (C2_2) op i SMP

- Red (C1_2) sendte SBDH(XDIS91) pakket krypteret ind i AS4 til Gateway’ens AP (C2_2) og modtog behørigt sin AS4-kvittering derfra

(11)

- Gateway’ens AP (C2_2) slog testapplikation2s ”distribution” modtageradresse for XDIS91, dvs.

Blue (C3_2) op i SMP

- Gateway’ens AP (C2_2) sendte SBDH(XDIS91) pakket krypteret ind i AS4 til Blue (C3_2) og modtog behørigt sin AS4-kvittering derfra

- Blue (C3_2) sendte SBDH(XDIS91) videre til en modtagende testapplikation2 (C3_1)

- testapplikation2 (C3_1) sendte herefter en Positiv kvittering (XCTRL03) pakket ind i eDelivery’s SBDH-Konvolut (Standard Business Document Header) via Blue (C3_2)

- Blue (C3_2) slog testapplikation1s ”opkomst” modtageradresse for XCTRL03, dvs. Gateway’ens AP (C2_2) op i SMP

- Blue (C3_2) sendte SBDH(XCTRL03) pakket krypteret ind i AS4 til Gateway’ens AP (C2_2) og modtog behørigt sin AS4-kvittering derfra

- Gateway’ens AP (C2_2) slog testapplikation2s ”distribution” modtageradresse, dvs. Red (C1_2) op i SMP

- Gateway’ens AP (C2_2) sendte SBDH(XCTRL03) pakket krypteret ind i AS4 til Red (C1_2) og modtog behørigt sin AS4-kvittering derfra

- Red (C3_2) sendte SBDH(XCTRL03) videre til den modtagende testapplikation2 (C1_1)

Figur 5 - CEF's edelivery 3-corner model

I Connectathon-setuppet agerede RegionSyds Cosmic Applikation i produktion C1_1 med en tilhørende Domibus-instans, C1_2, opereret af KMD. Herimellem anvendte RegionSyd og KMD deres sædvanlige Cloverleaf og VANS-setup. Gateway’ens AP udgør som i udviklingsforløbet C2_2. Modtagende parter udgjordes af hhv. PLSP (C3_1) og MedComs Testcenter (C3_1), PLSP (C3_1) repræsenteret af

MultiMed, med egenudviklet Access Point (C3_2) (videreudviklet fra en Peppol Access Point baseret på AS2) og MedComs Testcenter (C3_1) med et TrueCommerce Domibus baseret Access Point (C2_2).

I ”Figur 6 - Sekvensdiagram af 3-corner modellen” ses flowet grafisk af denne kommunikation.

(12)

RegionSyd

Ansat Cosmic ^C1_1

C1_1 PLSP

C3_1

Send XDIS91

AS4(Ack)

KMD AP

C1_2 GW AP

C2_2

Send SBDH(XDIS91) Send SBDH(XCTL03)

Send AS4(SBDH(XCTL03)) AS4(Ack) Send SBDH(XCTL03)

PLSP AP C3_2

Send AS4 (SBDH(XDIS91))

AS4(Ack)

Send AS4(SBDH(XCTL03)) AS4(Ack)

SMP

getAddress (PLSP, opkomst)

getAddress (PLSP, distribution)

getAddress (Cosmic, opkomst)

Figur 6 - Sekvensdiagram af 3-corner modellen

5.2.4 POC’ens datadeling på forespørgselsfundament

POC’ens datadelingsfundament er eDelivery 3-corner infrastruktur, som skaber muligheden for at lave den glidende overgangsløsning mellem datadeling ved videregivelse og datadeling på forespørgsel ved at stille en Gateway til rådighed for at viderebehandle de ankomne meddelelser på Gateway’ens AP.

Gateway’en giver hermed på baggrund af en intern konfiguration mulighed for

- at route meddelelser til en hvilken som helst service som gateway’en understøtter - at transformere meddelelser fra et format til et andet.

I POC’en er transformationer fra OIOXML til hhv. HL7 CDA og HL7 FHIR udvalgt til 2 forskellige platforme for datadeling på forespørgsel, XDS repræsenteret ved den på NSP velkendte

Dokumentdelingsservice (DDS) og FHIR repræsenteret ved en til lejligheden oprettet FHIR server.

I DDS-sammenhæng ønskede vi at afprøve dels, at vi kunne transformere en OIOXML til HL7 CDA, registrere den via DDS’ens XDS-infrastruktur, notificere National Adviseringsservice (NAS) herom og dels at gøre den tilgængelig for systemer, der abonnerer på NAS’en.

Tilsvarende ønskede vi i FHIR setup’et med en meget simpel FHIR-transformation at bringe REST paradigmet i spil og vise, at integration af FHIR kombineret med NAS vil kunne laves ligeså sømløst som DDS/NAS kombinationen vel vidende, at der er en række sikkerhedsmæssige aspekter, der skal løses, før det er realiserbart i produktion.

Formålet med at gøre meddelelserne tilgængelige på de 2 platforme, var foruden at gøre dem tilgængelige for de kliniske systemer i regioner, kommuner og hos praktiserende læger også at gøre det muligt for patienten og pårørende selv at kunne se dem på sundhed.dk

Sundhed.dk’s rolle i infrastrukturen var derfor på baggrund af det anvendte cpr-nr. at hente de delte data og præsentere dem for brugeren i deres brugergrænseflade.

(13)

Vi har i POC’en ikke taget stilling til hvilke meddelelser, der er egnet til hverken den ene eller den anden form for datadeling på forespørgsel, blot vise, at det kan gøres ved at tage udgangspunkt i det velkendte meddelelsesparadigme og aktivere datadelingsparadigmet derfra.

Vi har heller ikke forholdt os til, hvor et givent meddelelseshotel bedst implementeres, men blot at det kan realiseres, og at det bør underlægges nøjagtig de samme sikkerhedsmæssige forordninger som DDS og de øvrige komponenter på NSP.

5.2.5 Datadeling på forespørgsel – Dokumentdelingsservicen (DDS)

I POC’ens datadelingsscenarier via DDS og NAS opererede vi med GGOP som meddelelsestype og lod den afsende fra Corner 1 i eDelivery infrastrukturen til Gateway’ens AP i Corner 2, hvorfra den blev sendt til selve Gateway’en. Gateway’en lagrer og transformerer meddelelsen til CPD-DK, nyudviklet HL7 CDA til ”Planer og indsatser” i Patientoverbliksprojektet. Herefter sendes den via XDS-servicen ProvideAndRegisterDocumentSet til DDS, og efterfølgende notificeres NAS med et i dette opsæt simpelt datasæt indeholdende CPR-nr., kommune og meddelelsestype, så det efterfølgende er muligt at udsøge dokumentet i DDS. Brugere af NAS, der abonnerer på meddelelser med netop dette indhold, vil efterfølgende hente NAS-beskeden ned og på baggrund af indholdet i denne afgøre, at der skal hentes et dokument i DDS.

Figur 7 Datadeling på forespørgsel – Dokumentdelingsservicen (DDS)

I POC’en var det stadig RegionSyds Cosmic produktionsinstallation, som agerede corner 1 og afsendte GGOP originalmeddelelsen frem til gateway’en i corner 2 via det tidligere beskrevne setup for eDelivery 3-corner modellen. Gateway’en udførte det ovenfor beskrevne setup ift. at få registreret den

transformerede CPD-DK i hhv. DDS og notifikation herom i NAS.

Sundhed.dk hentede dokumentet i DDS og kunne vise dette via det generelle stylesheet for CDA, cda.xsl.

PLSP agerede abonnent på NAS og kunne konstatere, at dokumentet var registreret i DDS, men eftersom der ikke var en økonomisk aftale med PLSP om at hente meddelelsen i DDS, måtte vi nøjes med det.

MedComs Testcenter havde som sundhed.dk ikke abonnement på NAS’en, men kunne i lighed med sundhed.dk udsøge meddelelserne i DDS og præsentere dem via det generelle stylesheet for CDA, cda.xsl.

(14)

Figur 8 Sekvensdiagram af datadeling på forespørgsel – Dokumentdelingsservicen (DDS)

5.2.6 Datadeling på forespørgsel – MedCom Meddelelseshotel (FHIR)

I POC’ens datadelingsscenarier via MedComs Meddelelseshotel og NAS opererede vi både med GGOP og Korrespondancemeddelelse som meddelelsestyper og lod disse afsende fra Corner 1 i eDelivery infrastrukturen til Gateway’ens AP i Corner 2, hvorfra de blev sendt til selve Gateway’en. Gateway’en lagrede og ”transformerede” (rettere indpakkede) meddelelserne til FHIR Communication-ressourcer.

Herefter sendtes de til MedComs Meddelelseshotel baseret på HAPI open source implementation af en FHIR server.

Efterfølgende notificeres NAS i lighed med DDS setup’et med et i dette opsæt simpelt datasæt indeholdende CPR-nr, kommune og meddelelsestype, så det efterfølgende er muligt at udsøge ressourcerne på FHIR-serveren. Brugere af NAS, der abonnerer på meddelelser med netop dette indhold, vil efterfølgende hente NAS-beskeden ned og pba indholdet i denne afgøre, at der skal hentes ressourcer i Meddelelseshotellet. Abonnenten vil derefter hente disse ressourcer og præsentere dem i sit system.

Ansat Cosmic DDS

Send GGOP

AS4(Ack)

KMD AP GW AP

Send AS4(SBDH(GGOP))

ProvideAnd- Register- DocumentSet

(GGOP)

GW

Send AS4(SBDH(GGOP))

NAS

SetNotification (MedCom-Message, DDS)

Abonnent

system RegSyd Ansat

ReadTopic(MedCom-Message, FHIR-Hotel, Patient)

RerieveDocumentSet(GGOP) Notify(NewMessage)

GetMessage()

(15)

Figur 9 Datadeling på forespørgsel – MedCom Meddelelseshotel (FHIR)

I POC’en var det stadig RegionSyds Cosmic produktionsinstallation, som agerede corner 1 og afsendte hhv. GGOP og XDIS91 originalmeddelelserne frem til gateway’en i corner 2 via det tidligere beskrevne setup for eDelivery 3-corner modellen. Gateway’en udførte det ovenfor beskrevne setup ift. at få registreret de transformerede ressourcer i hhv. Meddelelseshotellet og notifikation herom i NAS.

Sundhed.dk hentede ressourcerne på FHIR-hotellet og kunne vise dette via de dedikerede stylesheets for MedComs OIOXML meddelelser.

PLSP agerede abonnent på NAS og kunne konstatere, at dokumentet var registreret i FHIR-hotellet, og derefter kunne PLSP hente meddelelserne og præsentere dem for sine brugere.

Tilsvarende var det muligt for sundhed.dk at udsøge de nytilkomne FHIR-ressourcer i meddelelseshotellet og præsentere dem for sine brugere via MedComs OIOXML stylesheets.

MedComs Testcenter havde som sundhed.dk ikke abonnement på NAS’en, men kunne i lighed med sundhed.dk udsøge meddelelserne i FHIR-hotellet og præsentere dem via MedComs eget stylesheet.

(16)

Figur 10 Sekvensdiagram af datadeling på forespørgsel – MedCom Meddelelseshotel (FHIR)

6 Deltagernes erfaringer og evaluering

Nedenfor beskrives evalueringer og vurderinger fra deltagerne i POC, herunder Connectathon d.

12/12-2018. Evalueringerne baseres på skriftlige tilbagemeldinger og afholdt fokusgruppemøde.

6.1 Generelt

Dette afsnit indeholder deltagernes generelle betragtninger i forbindelse med POC.

Der lægges af flere deltagere vægt på, at man fra POC ikke entydigt kan slutte et fremtidigt målbillede, eftersom øvelsen har vist hvad der kan lade sig gøre, ikke hvad der bør lade sig gøre.

Således har POC, jf. sit formål, genereret viden til udforskning af mulighedsområdet. Der findes desuden flere mulige varianter til implementering af repository funktionen, som ikke er blevet afprøvet.

Der beskrives megen kompleksitet i forholdene lokalt fra back-end/kildesystemer til Access Point og fra Access Point til aftagersystem, som kan have en effekt på en implementering i et produktionsmiljø.

Eksempelvis i regioner med mange systemer koblet til en regional hub på varierende måder, og muligvis i længere kæder, kan der være tale om kompleksiteter, der kan gøre en eventuel omlægning omkostningstung.

I POC blev der desuden foretaget nogle fravalg, som af nogle deltagere adresseres som manglende i forbindelse med at kunne træffe tilstrækkeligt funderede beslutninger på baggrund af POC.

Fravælgelsen af dynamisk adressering vurderes af enkelte som en mangel i forbindelse med

evalueringen af eDelivery, da et pålideligt routingregister beskrives som en nødvendighed i en eventuel implementering. Det var ligeledes blevet besluttet at nedtone sikkerhedsaspektet i afprøvningen, hvorfor certifikater i eDelivery ikke blev afprøvet til grundighed. Håndtering af fejl, der i nogle scenarier kan blive ganske komplekst, var ikke en del af afprøvningen, og beskrives som et element, der kan besværliggøre evaluering af særligt omkostningsaspektet i en eventuel implementering.

Ansat Cosmic FHIR

Hotel

Send XDIS91

AS4(Ack)

KMD AP GW AP

FHIR.Communi-Set cation(XDIS91)

GW

NAS

SetNotification (MedCom-Message, FHIR-Hotel)

Abonnent

system RegSyd Ansat

ReadTopic(MedCom-Message, FHIR-Hotel, Patient)

Get FHIR.Communi-

cation(XDIS91) Notify(NewMessage)

GetMessage()

(17)

6.2 Koncepter

Dette afsnit indeholder deltagernes evaluering og vurdering af de afprøvede varianter som koncepter.

Som koncept vurderes eDelivery positivt af deltagerne. Overgang til en eDelivery-baseret infrastruktur (dvs. det tekniske aspekt af en implementering) vurderes relativt overkommeligt.

4-corner modellen vurderes mest i overensstemmelse med den eksisterende EDI/VANS infrastruktur.

Denne model vurderes bedst til håndtering af (tids)kritiske beskeder, eftersom disse sendes direkte til modtageren.

3-corner modellen (med gateway) vurderes som en udmærket løsning til mindre (tids)kritiske beskeder, men introducerer et ”Single-Point-of-Failure”, dvs. en svaghed i tilfælde af, at gateway’en går ned. Det benævnes derudover, at punkt-til-punkt fleksibiliteten fra 4-cornermodellen ikke udnyttes i denne model.

Der var enighed om, at POC har vist, at datadeling er mulig med en kombination af en 3-corner-model og et centralt repository, som både understøtter CDA og FHIR.

Datadeling med advis, både gennem den eksisterende Dokumentdelingsservice (DDS) og Medcom Meddelelseshotel (FHIR), blev af deltagerne udfordret som løsning på baggrund af introduktionen af et ”Single-Point-of-Failure”. Derudover vurderede flere deltagere, at denne konceptuelle løsning vil komme til at stille krav til forretningsmæssige forandringer, dels i it-afdelinger og muligvis hos klinikere ligeså, afhængig af, hvordan den udformes.

6.3 Teknik

Dette afsnit indeholder deltagernes evaluering og vurdering af de afprøvede varianter ud fra et teknisk perspektiv.

De tekniske standarder og værktøjer inddraget i afprøvning vurderes tilstrækkeligt modne og klar til anvendelse. En implementering vil stille krav til SMP, hvis det skal fungere effektivt, herunder et behov for konstant opdatering.

6.4 Praktisk

Dette afsnit indeholder deltagernes evaluering og vurdering af de afprøvede varianters konsekvenser ved implementering i det praktiske arbejde.

POC tager ikke stilling til de forretningsmæssige omlægninger, der potentielt affødes af hver variant af løsning, hvorfor det af deltagerne beskrives svært at evaluere konsekvenserne ved implementering i praksis. Afhængigt af måden, hvorpå der implementeres, kan der potentielt være tale om store forandringer i forretningsgangene.

Deltagerne pegede på, at en advis-baseret meddelelsesudvekslingsmodel vil medføre flere processer hos modtagere af meddelelser, og at dette ikke er afprøvet i dybden i POC. Her udestår der et arbejde med at afklare kompleksitet og ressourceforbrug til en sådan omlægning.

Hertil kommer at kvitteringsflowet ved en advis-baseret meddelelsesudvekslingsmodel ikke er afprøvet, og det kan også forventes at bidrage til at øge processerne hos modtagerne.

Overvågning, sporing af meddelelsernes ruter samt fejlhåndtering skal indgå i det videre arbejde. I dag skifter regionerne/sygehusene til manuelle nødprocedurer, hvis meddelelser er forsinket/stopper i mere end 2 timer. Jo flere led der er i kæden – jo sværere er det at sikre overvågning og sporing.

(18)

Der er blandt deltagerne enighed om, at det generelt har været en god og professionel proces, der har været velfaciliteret af Medcom. Særligt fremhæves evnen til at inddrage tre konkurrerende

leverandører og få dem til at arbejde sammen med åbne kort som en succes. Der beskrives

gennemgående et godt samarbejde, og der roses for let tilgængelig bistand fra Medcom og Trifork.

Til Connectathon d. 12/12-2018 beskrives af nogle deltagere et ønske om mindre fokus

på ”show”/rollespil, hvilket karakteriseres som underholdende, men ikke den mest effektive brug af tid. Alternativt kunne nogle af de fravalgte elementer af prøvningen muligvis være inddraget, såsom afklaring af mulige løsninger til håndtering af fejl.

En deltager beskriver, at den første demo generalprøve viste, at der var nogle detaljer i demo-forløbet og i det tekniske setup, der skulle justeres. Det kunne have givet værdi at afholde en sådan prøve tidligere i forløbet.

Connectathon vurderes som en effektiv måde at afslutte forløbet på, da det tvang deltagerne til at få ”knyttet enderne sammen” og levere det, der var behov for, da eventuelle løse ender ellers var blevet udstillet.

7 Omkostninger til eDelivery og datadeling

Det indgår i PID, at der som del af erfaringsopsamlingen ønskes vurdering af

- Centrale omkostninger til etablering og drift af den moderniserede infrastruktur

- Decentrale omkostninger i regioner, kommuner og praksissektor til etablering og drift af tilslutning til den moderniserede infrastruktur

Deltagerne påpeger, at det er vanskeligt at bidrage med skøn over omkostningerne, da POC havde mange fravalg, som kan påvirke omkostningerne, ligesom erfaringsopsamlingen viser, at der skal træffes en række arkitekturmæssige valg, der hver vil på virke omkostningerne ved at overgå til eDelivery.

I det følgende beskrives en række forhold, som vil påvirke omkostningerne. Det bygger dels på deltagernes bidrag, dels på Medcoms og Rambølls analyser.

7.1 Oversigt 7.2 Faseopdeling

Omkostningerne vil være påvirket af, hvordan implementeringen gennemføres, og hvor længe implementeringsperioden varer.

Følgende faser i implementeringen vil bidrage til omkostningerne:

a) Forberedelse (her gennemføres analyser og yderligere proof-of-concepts ligesom målbillede og arkitekturer fastlægges)

b) Etablering af de centrale komponenter med

o Central MedCom Gateway med Access Point o MedCom Repository

c) Overgangsfase. I denne fase etableres decentrale Access Points med en eller flere Connectors, der forbinder fagsystemer med Access Point. I perioden er der parallel drift i VANS og

eDelivery.

d) Driftsperiode eDelivery og datadeling.

7.3 Generelle omkostningsdrivere

Nogle generelle omkostningsdrivere skyldes høje og stigende krav til - Sikkerhed (fortrolighed)

(19)

- Pålidelighed (sikkerhed for at data når frem til modtager) - Tilgængelighed (oppetid og dermed tilstrækkelig skalering)

Alle disse dimensioner påvirker i meget høj grad omkostningerne til de løsninger, der skal etableres, også ud over de forhold, der dækkes af eDelivery.

eDelivery kan implementeres med EU's Open Source produkter, hvilket alt andet lige betyder lavere softwareomkostninger til indkøb eller udvikling. POC har dog vist, at der er behov for en del udvikling for at få disse produkter modnet til de forventede krav til sundheds-it.

7.4 Forberedelse

I forberedelsesfasen skal der gennemføres en række analyser og udviklingsarbejder, evt. som proof- of-concepts, som sammen med et arkitekturarbejde skal udarbejdet et målbillede og beskrive infrastrukturen så detaljeret, at det kan danne grundlag for etableringen. POC og deltagernes tilbagemeldinger har vist et behov for en lang række designbeslutninger og modelvalg, som skal gennemføres i forberedelsen. Der vil være udgifter til projektledelse af forberedelsesfasen.

7.5 Centrale komponenter

For at tilgodese behovet for trinvis overgang og datadeling skal der etableres en gateway, der kan håndtere op mod 100 mio. meddelelser pr år (pt. 80 mio. meddelelser). Gatewayen implementeres som en logisk del af den Nationale Serviceplatform (NSP), for at drage fordel af dennes infrastruktur fx med hensyn til sikkerhed.

Omkostningerne til gateway vil være påvirket af hvilke opgaver den skal udføre. Skal den gennemføre mapping mellem standarder, skal den route beskeder efter forskellige regler, eller vil der kun være t begrænset antal opgaver.

Hvis behovet for datadeling kun gælder for en del af meddelelserne, giver eDelivery mulighed for direkte forsendelse fra afsender til modtager, hvilket vil reducere omkostningerne.

Til at lagre indholdet af meddelelser skal der etableres et repository (eller flere) til meddelelserne.

Dette repository skal ligesom gateway implementeres som en logisk del af den Nationale

Serviceplatform (NSP), for at drage fordel af services som advisering og datadeling. Der vil være behov at udvide NSP med snitflade til FHIR.

Omkostningerne til repository vil være påvirket af, om der skal være et eller flere (decentrale eller indholdsbestemte). Selvom der er tale om store mængder meddelelser, er de tekstbaserede, så datamængden forventes ikke at være omkostningsdrivende.

Der stilles høje krav til oppetid til både gateway og repository, da de vil udgøre en single point of failure, der kan stille krav til to-center-drift og hot failover. Dette vil øge omkostningerne betydeligt.

7.6 Decentrale komponenter

eDelivery-arkitekturen lever op til kravet om løst koblede komponenter med brug af Access Points og lokale connectors.

Omkostningsdrivere er

- Udgift til det enkelte Access Point - Antal Access Points

- Udgift til Connector - Antal Connectors

Access points kan implementeres på flere måder, fx i forbindelse med - Et lokalt system i en organisation

(20)

- Af systemleverandør, som leverer et Access point til et system, der anvendes af flere kunder, fx en lægepraksissystemleverandør

De 5 regioner, som årligt sender ca. 60 mio. beskeder, har hver adskillige fagsystemer, som er afsender og modtager. Disse fagsystemer sender og modtager i dag beskeder via regionens centrale hub (fx Cloverleaf), hvorfra de gennem en VANS-leverandør transporteres på VANS-nettet.

Fagsystemerne sender/modtager i forskellige formater, som konverteres efter behov i hub eller hos VANS-leverandør. Mulige løsninger med eDelivery er fortsat at have leverandører, der varetager de opgaver, som VANS-leverandørerne i dag udfører, eller at hjemtage disse opgaver. Det vil påvirke omkostningerne, hvis regionerne vælger at etablere en struktur med Access Points i forbindelse med det enkelte fagsystem og dermed opnå kortere vej mellem dem. Under alle omstændigheder skal regionernes Access Points kunne håndtere meget store trafikmængder med høj oppetid og håndtering af mange forskellige typer beskeder.

De 98 kommuner, som årligt sender mere end 4 mio. beskeder, har en række fagsystemer, som afsendere og modtagere. Der sker i disse år en konsolidering af disse fagsystemer til nogle få suiter med mange funktioner. For kommunerne er mulige løsninger at have eDelivery-leverandører, at hjemtage opgaven eller at lade fagsystemleverandøren stå for Access Point. På grund af kommunernes meget forskellige størrelser, forventes der valgt forskellige løsningsmodeller.

De 2.700 praktiserende læger og speciallæger anvender 14 praksissystemer, hvoraf kun 8 har større udbredelse. Praksissystemerne har slået sig sammen i Praksissektorens Serviceplatform (PLSP). Mulige løsninger med eDelivery er, at hvert praksissystem har en eDelivery-leverandør, at praksissystemet hjemtager opgaven med at stå for Access Point, eller at PLSP løser opgaven. Det er næppe realistisk, at den enkelte praksis selv løser opgaven.

For de mange tusinde fysioterapeuter, fodterapeuter og andre gælder sandsynligvis, at de får leveret it, og at disse it-leverandører enten selv vil stå for Access Point eller vil få det leveret af en eDelivery- leverandør.

De nuværende VANS-leverandørerne (Multimed, TrueCommerce og KMD) skal have Access Points til VANS bridges, så de kan håndtere både eDelivery og EDI i overgangsperioden.

I den praktiske implementering kan der forventes andre tilgange, når leverandørmarkedet udvikler tilbud til implementering af eDelivery. Fx kan kommunernes omkostninger blive påvirket, hvis de vælger en fælles løsning i KOMBIT-regi.

Omkostningerne til decentral implementering vil være påvirket af, om der regnes med ændringer i kilde- og anvendersystemer for at tilpasse til ændringer i standarder, eller om alle ændringer forventes at kunne mappes fra eksisterende standarder til nye standarder.

Omkostninger til decentral implementering vil være påvirket af overgangsperiodens længde, idet en kort overgangsperiode vil øge omkostningerne.

I overgangsperioden vil der være driftsudgifter til de centrale komponenter og driftsudgifter til både EDI og eDelivery i MedCom, hos VANS-leverandører og hos aktørerne.

Deltagerne peger på, at der vil være omkostninger til at omlægge mange fra

meddelelseskommunikation til datadeling med advis. En omlægning fra EDIFACT til eDelivery er en mere begrænset opgave med skift af protokoller end skiftet til advis-baseret, der forventes at kræve etablering af nye komponenter/funktioner. Hertil kommer, at der vil være løbende omkostninger til at vedligeholde abonnementer på advisering.

7.7 Projektomkostninger

Projektomkostninger vedrører primært interne medarbejdere til projektledelse og -gennemførelse. Der vil desuden være omkostninger til konsulenter til udbud.

(21)

7.8 Governance

Den overordnede governance af eDelivery varetages af Digitaliseringsstyrelsen, men der kan forventes omkostninger til governance-opgaver på sundhedsområdet.

Det kan omfatte

- servicering af anvenderne med support og certificering for bl.a. at sikre en god og hurtig ibrugtagning.

- udarbejdelse af vedligeholdelse af særlige regler for sundhedsområdet, fx i forhold til sikkerhed.

- overvågning af udviklingen i anvendelse, sikkerhedsforhold, styring af oprydning

For modernisering af infrastrukturen kan dette bygge på MedComs nuværende tilbud og aktiviteter, idet der dog i en overgangsperiode vil være behov for dels at opbygge en governanceorganisation for eDelivery og forsatte arbejdet med den nuværende infrastruktur for til slut at udfase den. Udgifterne er overvejende til internt personale.

I etableringsperioden skal governance forberedes. I overgangsperioden er der udgifter til projektleder og fageksperter, der kan bidrage til gennemførelsen af governance og dialogen med parterne.

7.9 Drift

Der vil være driftsomkostninger til de centrale komponenter. De vil stige i løbet af overgangsfasen til de når et mere stabilt niveau i driftsperioden.

De decentrale driftsomkostninger skal dække driften af Access Points i form af betaling til tjenesteydere eller parternes egne omkostninger. Omkostningerne vil være påvirket af

sundhedssektorens forventede høje krav til sikkerhed, at der vil være tale om håndtering af flere typer standarder, og at markedet for sundheds Access Points vil være langt mindre end markedet for

eFakturering.

7.10 Øvrige forhold der kan påvirke omkostningerne

I det følgende gennemgås en række forhold, som også kan påvirke omkostningerne.

7.10.1 Organisatorisk implementering i klinikken

Der er tale om en teknisk implementering, der bygger på MedCom kommunikation, som gennem flere års arbejde er indarbejdet hos det offentliges aktører.

Det antages, at den ny infrastruktur kan implementeres med meget få og små ændringer i brugernes rutiner og brugergrænseflader (fx adressering, som i dag sker med SOR og lokationsnumre, og hvor det antages at det med eDelivery kan ske med samme brugergrænseflade).

På det grundlag regnes der ikke med omkostninger til oplæring af det personale, der anvender fagsystemerne.

7.10.2 Det centrale adressekatalog - SMP og SML

Der skal etableres et adresseregister, som parterne kan anvende til at slå modtageradresser op. Et adresseregister kan evt etableres med hel eller delvis brug af SOR og CVR.

SMP - Service Metadata Publisher: beskriver, hvad min Modtager er i stand til – og hvor (på hvilken IP- adresse) Modtagers Access Point er?

SML - Service Metadata Locator: Hvor kan jeg finde metadata om min Modtager? Hvordan er adressestrukturen?

Adressekataloget etableres nationalt af Digitaliseringsstyrelsen som led i implementeringen af eDelivery.

Der skønnes ikke omkostninger hertil for sundhedsområdet.

(22)

- Sikkerhedsinfrastrukturen på NSP - SOR, CVR

Der kan være omkostninger til anvendelse af disse komponenter, fx øget belastning af adviseringsservice.

7.10.4 Kompetenceudvikling

Der kan forventes behov for kompetenceudvikling i regioner, kommuner og hos andre, der skal overgå til eDelivery.

Omfanget af kompetenceudvikling vil afhænge af, i hvilket omfang der skal ske ændringer i organisationerne.

7.10.5 Borgerrettede komponenter

Borgeres/patienters adgang til egne data i løsningen kræver tilpasninger i sundhed.dk og tilpasning/udvikling af apps til mobile enheder.

Der arbejdes i sundhedssektoren med flere løsninger til borgere, fx Min Læge.

Der vil være udgifter til tilpasning/udvikling af apps.

7.10.6 Standarder

Modernisering af infrastrukturen omfatter ibrugtagning af HL7 og roadmap for udfasning af EDIFACT, ligesom den modernisering, som POC’en omhandler, også medfører et behov for modernisering af standarder eller nye standarder.

I et vist omfang kan nye standarder implementeres uden indholdsmæssige ændringer, således at overgangen til nye standarder kan implementeres uden ændringer i kilde- og anvendersystemer.

Med indførelse af eDelivery forventes der bedre mulighed for implementering af nye standarder, da Access Points er indholdsagnostiske. Dog kan implementering af Connectorer betyde omkostninger.

7.10.7 Jura

Som udgangspunkt forventes der ikke at være juridiske barrierer for implementering af en moderniseret infrastruktur som beskrevet. Dels fordi den ny infrastruktur i al væsentlighed er en videreførelse af den nuværende infrastruktur, og fordi den ændrede sundhedslov lægger op til videre muligheder for deling af data.

På nogle områder kan der være behov for juridiske afklaringer:

- Den moderniserede infrastruktur lægger op til øgede muligheder for datadeling – her kan der være behov for at fastlægge muligheder og begrænsninger

- Hvad sker der med ansvarsfordeling og ansvarsoverdragelse, hvis der vælges en model med overgang fra forsendelse til datadeling?

- Muligheder og begrænsninger i udveksling på tværs af sundheds- og andre domæner Udgifter til juridiske analyser vil afhænge af scope og omfang.

7.11 Gevinster

Ved modernisering af MedCom infrastruktur forventes en række kvalitative gevinster. I indeværende afsnit skitseres de strategisk vigtigste og mest sandsynlige.

Modernisering af infrastrukturen forventes at styrke digitalt samarbejde på tværs af sektorer, hvilket særligt vil gøre en forskel i tværgående processer. Et eksempel herpå er skabelse af mere glidende overgange mellem sektorer i forbindelse med komplekse tværgående patientforløb, dvs. patientforløb hvor patienten skiftevis interagerer med private praksisser, det kommunale og det regionale

sundhedsvæsen. Glidende overgange ifm. komplekse patientforløb, og dermed oplevelsen af at møde ét sundhedsvæsen, er en central del af Sammenhængsreformens digitaliseringsspor ”Digital Service i Verdensklasse”. Forbedret understøttelse af interoperabilitet mellem organisationer på tværs af

sektorer forventes således at skabe bedre opgaveløsning i sundhedsvæsenet, resulterende i reduktion i antal indlæggelser, kortere liggetid samt færre besøg hos praktiserende læge og ambulant.

(23)

Modernisering af infrastrukturen vil fremadrettet give mulighed for hurtigere implementering af forandringer – tekniske som forretningsmæssige. eDelivery, som effektivt understøtter

Referencearkitekturen for deling af data og dokumenter (EIRA)’s mønster ”Videregivelse ved

meddelelse”, vurderes at medføre styrkede muligheder for genbrug af allerede etablerede løsninger, og forventes således at skabe færre omkostninger til udvikling af nye løsninger og efterfølgende drift.

eDelivery er en skalérbar løsning, der baserer sig på et standardiseret netværk, som kan genbruges i alle organisationer.

Som følge af implementeringen af eDelivery som mere moderne teknologi i MedComs infrastruktur, ses en række gevinster. Eftersom eDelivery baseres på open source-komponenter og velafprøvede

internationale standarder, har dette netværk lavere adgangsbarrierer end VANS og vurderes at mindske leverandørafhængighed, medførende lavere priser og øget fleksibilitet i services. Derudover anses eDelivery for værende pålideligt netværk til forsendelse og sikker levering af dokumenter.

Sikkerheden baseres på udveksling af digitale certifikater og juridiske aftaler. eDelivery-arkitekturen overholder ydermere juridiske krav fastsat i eIDAS-forordningen om tillidstjenester på området (Registered eDelivery services). eDelivery arkitekturen understøttes af EU gennem centrale tjenester, governance og støtte til udbredelse. eDelivery er desuden på vej til udbredelse i Danmark, hvorfor det med sandsynlighed vil være en fordel for MedCom at være på forkant med den teknologiske udvikling på området.

8 Samlet evaluering

På grundlag af PIDs Mål og succeskriterier samt Evaluering og gevinster samles evalueringen i følgende temaer

- Hurtig, stabil og sikker overlevering af relevante datasæt - Stille relevante data til rådighed for onlinedeling på forespørgsel - Omlægning til datadeling

- Deling af data på sundhed.dk og mobile platforme

- Sundhedsfaglige og arkitekturmæssige valg ved overgangen til eDelivery og datadeling Disse temaer har sammenhæng med initiativ 2.1 Bedre, hurtigere og mere sikker digital kommunikation mellem sektorer i Strategi for digital sundhed 2018-2022.

8.1 Hurtig, stabil og sikker overlevering af relevante datasæt

POC har vist, at protokoller og værktøjer fra EU’s eDelivery og fællesoffentlige standarder kan levere hurtig, stabil og sikker overlevering af relevante datasæt i en infrastruktur, der kan afløse den nuværende Medcom kommunikationsinfrastruktur.

I POC blev der afprøvet flere modeller for overlevering af data, som alle kan indgå i overvejelserne om en moderniseret infrastruktur, jf. afsnit 5.2. Der vil være behov for, at der træffes sundhedsfaglige og arkitekturmæssige valg af model(er).

Hvor meget kæderne fra afsender til modtager vil blive reduceret ved overgang fra VANS til eDelivery og datadeling, vil afhænge af, hvilke arkitekturvalg, der træffes nationalt og decentralt.

8.2 Stille relevante data til rådighed for onlinedeling på forespørgsel

I POC blev der afprøvet opsamling af meddelelser i et centralt repository, som en mulig løsning på online deling af data.

Denne model har vist sig at kunne anvendes, både til deling af data med udsendelse af advis og hvor datadeling sker ved dataanvenders forespørgsel.

Deltagerne peger på, at der i en fremtidig datadeling kan anvendes andre modeller, fx med flere centrale repositories eller ved decentrale repositories.

(24)

Også her vil der være behov for at der træffes sundhedsfaglige og arkitekturmæssige valg af model(er).

8.3 Omlægning til datadeling

I POC indgik undersøgelse af mulighed for at omlægge kommunikationsmønstre 100% fra

meddelelseskommunikation til datadeling, da dette tema indgår som en del af initiativ 2.1 i Strategi for digital sundhed 2018-2022.

Det vil indebære en model, hvor alle meddelelser opsamles i et eller flere repositories, hvor der er advis til modtager, og hvor modtager derefter henter meddelelsens indhold i repository.

Deltagerne stillede var skeptiske over for denne model med 100% overgang til datadeling, da den ville stille store krav til modtagernes it-infrastruktur, it-systemer og forretningsgange, som skal omlægges fra den nuværende beskedmodel til en advismodel. Dette vurderede flere deltagere ville betyde meget store omkostninger.

Deltagerne stillede dermed spørgsmålstegn ved dele af indholdet i initiativ 2.1.

POC testede kun dele af advis-modellen, og der er derfor behov for at indhente yderligere erfaringer, og der er derfor behov for yderligere afklaring på dette område, særligt i forhold til decentrale omkostninger til modellen.

8.4 Deling af data på sundhed.dk og mobile platforme

POC viste, at deling af data på sundhed.dk og mobile platforme er mulig med eDelivery i kombination med værktøjer fra HL7. Datadelingsservice (DDS) på NSP blev anvendt ligesom en FHIR-løsning blev afprøvet.

Hvor DDS er en kørende service på NSP med anvendelse af nationale sikkerhedsstandarder, udestår der et arbejde med at modne FHIR og REST med nationale standarder, således at mobile platforme kan anvende data med tilstrækkelig sikkerhed.

8.5 Sundhedsfaglige og arkitekturmæssige valg ved overgangen til eDelivery og datadeling

Som deltagernes vurdering og MedComs og Rambølls analyser viser, skal der træffes en række sundhedsfaglige og arkitekturmæssige valg både nationalt og decentralt ved overgangen til eDelivery og datadeling.

Det kan ske i sammenhæng med arbejdet med ”Langsigtet målbillede for den fælles it-infrastruktur”.

8.6 Samlet konklusion og anbefaling

På baggrund af POC og evalueringen anbefaler styregruppen

- At der arbejdes på at implementere eDelivery og datadeling på en måde, der muliggør en fleksibel og trinvis migrering fra VANS til eDelivery

- At dette implementeres med datadeling i et centralt besked-repository for bedst at understøtte overgangen

- At der sker en afklaring og beslutningstagen vedrørende de forhold, der er beskrevet i evalueringen.

- At der gennemføres yderligere afprøvning og udvikling