Rambøll Management Consulting PETH/MTHAS/OVI Oplæg til evaluering af POC for modernisering af MedCom infrastruktur

Transkript

1 MEDCOM PETH/MTHAS/OVI Rambøll Management Consulting Oplæg til evaluering af POC for modernisering af MedCom infrastruktur Indhold 0 Om denne version Indledning Formål med projektet Den nuværende situation (baggrund) Formålet med projektets løsning Projektets bidrag til strategiske mål Den fremtidige situation efter indførelse af løsningen Situationen hvis projektet ikke gennemføres (business as usual) Alternative løsningsscenarier (Vurdér) Afgrænsning Status for edelivery i international og national kontekst Teknisk løsning Overblik Beskrivelse af de 4 varianter, der er afprøvet i POC Deltagernes erfaringer og evaluering Generelt Koncepter Teknik Praktisk Proces Omkostninger til edelivery og datadeling Oversigt Faseopdeling Generelle omkostningsdrivere Forberedelse Centrale komponenter Decentrale komponenter Projektomkostninger Governance Drift Øvrige forhold der kan påvirke omkostningerne Gevinster

2 8 Samlet evaluering 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 Samlet konklusion og anbefaling Indledning Formål med projektet Den nuværende situation (baggrund) Formålet med projektets løsning Projektets bidrag til strategiske mål Den fremtidige situation efter indførelse af løsningen Situationen hvis projektet ikke gennemføres (business as usual) Alternative løsningsscenarier (Vurdér) Afgrænsning Status for edelivery i international og national kontekst Teknisk løsning Overblik Beskrivelse af de 4 varianter, der er afprøvet i POC Deltagernes erfaringer og evaluering Generelt Koncepter Teknik Praktisk Proces Omkostninger til edelivery og datadeling Oversigt Faseopdeling Generelle omkostningsdrivere Forberedelse Centrale komponenter Decentrale komponenter Projektomkostninger Governance Drift Øvrige forhold der kan påvirke omkostningerne Gevinster Samlet evaluering Hurtig, stabil og sikker overlevering af relevante datasæt

3 8.2 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 Samlet konklusion og anbefaling

4 1 Om denne version Afsnit markeret med gråt er kopieret fra PID. 21 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 Projektet er en del af arbejdet med indsatsen Bedre, hurtigere og mere sikker digital kommunikation mellem sektorer i Strategi for digital sundhed Formål med projektet 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 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 At understøtte hurtig, stabil og sikker overlevering af relevante datasæt, når patientansvaret entydigt skifter mellem sektorer At opsamle og dele data fra borgerens eget hjem og stille data til rådighed for borgeren selv, bl.a. på sundhed.dk og mobile platforme 4

5 Projektets bidrag til strategiske mål Projektet udgør den praktiske udmøntning af initiativ 2.1 i Strategi for Digital Sundhed : Bedre, hurtigere og mere sikker digital kommunikation mellem sektorer, hvor det fremgår: Gennem de seneste å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 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

6 Eksempel 4: Region X er på vej i udbud med sin EPJ-løsning og ønsker derfor ikke at omlægge Adviskommunikationen 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 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 1. 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 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 1 I bilag til PID. 6

7 43 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 ( ): 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. 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 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. Formateret: Skrifttype: Fed Opsamling af data blev afgrænset til et centralt repository, mens andre varianter ikke indgik i afprøvningen. Det i PID en definerede formål At opsamle og dele data fra borgerens eget hjem og stille data til rådighed for borgeren selv, bl.a. på sundhed.dk og mobile platforme var en del af initiativet omkring projektet Matis og indgik ikke POC. 54 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 under initiativ 8.1 Gode data og effektiv datadeling. Der er 7

8 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. 65 Teknisk løsning 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 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. 8

9 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 POC ens forudsætninger Beskrivelse af proces for POC Processen for POC en havde som sit primære fokus at skabeindledtes med et møde med den IT-faglige arbejdsgruppe, hvortil indkaldtes sundheds-it professionelle fra regioner, kommuner og implementere en helhedsorienteret arkitektur, hvori forskellige datadelingsparadigmer kunne afprøvesstatslige organisationer, samt repræsentanter for VANS-leverandørerne, MedCom og vises ved så vidt muligt at sætte allerede kendte komponenter Trifork. Disse leverede et input til POC en som sammen i en ny sammenhæng og dermed understøtte PID ens fokus på at afprøve en måde at lave glidende overgangmed MedComs eget input, som bl.a. var stærkt inspireret fra sin deltagelse i edelivery arbejdsgruppen under DIGST, blev kondenseret til POC ens grundlag. Dette blev samarbejdsgrundlaget mellem Trifork og MedCom og blev løbende justeret ift. resultatet af Triforks arbejde. Triforks arbejde med komponenterne i POC en blev i starten fokuseret på datadeling påved videregivelse i form af den velkendte meddelelsesudvekslingspraksis og af meddelelser via edelivery, for at undersøge om disse kunne blive et fornuftigt fundament for datadeling på forespørgsel, som. Der blev afprøvet både open source Access-point komponenter ift. 4- og 3-corner modeller, samt en open source SMP, begge viste sig robuste nok til POC ens formål. For at fuldende edelivery-setup et indpakkedes meddelelser fra afsender i Standard Business Document Header, SBDH, hvori relevante forsendelses metadata blev registreret sammen med relevante metadata for delingsservicerne. Herefter fokuseredes på at gateway en og dens funktion ift. dels at formidle meddelelser videre til 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 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. direkte modtager, og dels at orkestrere datadeling på forespørgsel via hhv. DDS og en FHIR server, og dels at registrere hændelserne i NAS en med henblik på abonnement for systemer, der kan håndtere dette. I denne del sikredes ligeledes, at gateway en ville kunne lave simple XSLT-mapninger til hhv. baseret på konfigurationsoplysninger i databasen. Formateret: Skrifttype: Fed I denne del fokuseredes ligeledes på at etablere den valgte open source baserede HAPI FHIR-server, hvortil korrespondancemeddelelser skulle sendes indpakket og Base-64 encoded i en FHIR Communication ressource. Snitfladerne til DDS og NAS blev etableret, hvorefter det blev afprøvet at hele setup et fungerede fra afsendelse af GGOP fra afsender til primær modtager med udtagelse af kopi til DDS med metadata ekstraheret fra SBDH. Tilsvarende afprøvning med Korrespondance meddelelsen fra afsendelse fra afsender til primær modtager med udtagelse af kopi til FHIR-server med metadata ekstraheret fra SBDH. Samtidig med udviklingsfasen med Trifork etableredes samarbejdsaftaler med en udvalgt skare af aktører til live afprøvning i Syddansk Sundhedsinnovations Colab Plug n Play facilitet i Forskerparken. Målet var at lave et live-arrangement i Colab Plug n Play, hvor deltagerne kunne vise for et indbudt publikum af interessenter, at de var i stand til at indgå i moderniseret datadeling ved videregivelses- 9

10 setup eksemplificeret ved edelivery og et tilsvarende setup vedrørende datadeling på forespørgsel, bundet sammen af Triforks edelivery access-point og MedCom Gateway. De parter, det lykkedes at lave samarbejdsaftaler med var: - Region Syddanmark med henblik på at stille ressourcer og en EPJ-installation til rådighed for afsendelse af meddelelser - KMD og TrueCommerce med henblik på at stille ressourcer og en edelivery access pointinstallation til rådighed for afsendelse og modtagelse af meddelelser - PLSP med henblik på at stille ressourcer og en PLSP-installation samt en edelivery access point-installation til rådighed for modtagelse af meddelelser og hentning af meddelelser via delingsservices - Sundhed.dk med henblik på at stille ressourcer og en sundhed.dk-installation til rådighed for hentning af meddelelser via delingsservices I slutfasen frem mod Connectathon etableredes med disse parter et samarbejdsforum under MedComs projektledelse med henblik på at få parterne til at kunne indtage deres respektive rolle i hele flowet, få etableret samarbejde med deres nære kommunikationsparter under Triforks guidning på det tekniske setup. Til lejligheden havde MedCom udarbejdet et udførligt sæt af meget tekniske use-cases, som gjorde det klart for parterne, hvilke opgaver de skulle udfylde under Connectathon. Henover de tekniske use-cases lavede Syddansk Sundhedsinnovation flere små user-stories, som skulle gøre det muligt også at præsentere det tekniske indhold af POC en i en mere analog og menneskelig version med en patient, som blev udskrevet fra en sygehusafdeling til ankomst i hjemmet over aftaler om genoptræning hos hhv. praktiserende læge og kommunens terapi-afdeling. I den sidste uge op til Connectathon blev setup et afprøvet og justeret til i Colabs Plug n Play facilitet. Pga. tidspresset blev enkelte steps foretaget via manuel håndtering, men de centrale dele af setup et blev afviklet uden manuel indblanding. PLSP viste som eneste part et fuldt integreret system uden manuel indblanding. Selve Connectathon blev afviklet med et indbudt publikum af interessenter, hvor formiddagen havde fokus på videregivelse ved meddelelse og edelivery, eftermiddagen fokus på videregivelse på forespørgsel og forløb som planlagt bortset fra et enkelt problem med DDS, heldigvis var der gemt data fra mandagens generalprøve, så indhold fra DDS alligevel kunne vises, om end det ikke var helt live Beskrivelse af de 4 varianter, der er afprøvet i POC Herunder beskriver MedCom detaljeret, hvilke varianter der er afprøvet 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 GLNmodtagers 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. Formateret: Skrifttype: Calibri, 11 pkt 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 SORkapabiliteterne og deres egne adresseregistreringer. 10

11 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 ikke direkte forskelligt i hhv. 4- og 3-corner modellerne, men anvendes 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 enhub ens AP 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. CDAversion 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. 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 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). 11

12 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. RegionSyd Ansat Cosmic KMD AP SMP PLSP AP PLSP Send XDIS91 Send XDIS91 getaddress (PLSP, distribution) Send AS4(SBDH(XDIS91)) AS4(Ack) getaddress (PLSP, distribution) Send SBDH(XDIS91) Send SBDH(XCTL03) Send SBDH(XCTL03) Send AS4(SBDH(XCTL03)) AS4(Ack) Figur 4 - Sekvensdiagram af 4-corner modellen 12

13 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 - 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) 13

14 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. 14

15 RegionSyd Ansat Cosmic C1_1 C1_1 KMD AP C1_2 SMP GW AP C2_2 PLSP AP C3_2 PLSP C3_1 Send XDIS91 Send XDIS91 getaddress (PLSP, opkomst) Send AS4(SBDH(XDIS91)) AS4(Ack) getaddress (PLSP, distribution) getaddress (Cosmic, opkomst) Send AS4 (SBDH(XDIS91)) AS4(Ack) getaddress (Cosmic, opkomst) Send AS4(SBDH(XCTL03)) AS4(Ack) Send SBDH(XDIS91) Send SBDH(XCTL03) Send AS4(SBDH(XCTL03)) Send SBDH(XCTL03) AS4(Ack) Figur 6 - Sekvensdiagram af 3-corner modellen 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. 15

16 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 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. 16

17 Abonnent RegSyd Ansat Cosmic KMD AP GW AP GW DDS system Ansat NAS Send GGOP Send GGOP Send AS4(SBDH(GGOP)) AS4(Ack) Send AS4(SBDH(GGOP)) ProvideAnd- Register- DocumentSet (GGOP) SetNotification (MedCom-Message, DDS) ReadTopic(MedCom-Message, FHIR-Hotel, Patient) Notify(NewMessage) GetMessage() RerieveDocumentSet(GGOP) Figur 8 Sekvensdiagram af datadeling på forespørgsel Dokumentdelingsservicen (DDS) 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. 17

18 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. 18

19 Ansat Abonnent system RegSyd Ansat Cosmic KMD AP GW AP GW FHIR Hotel NAS Send XDIS91 Send XDIS91 Send AS4(SBDH(XDIS91)) AS4(Ack) Send AS4(SBDH(XDIS91)) SetNotification (MedCom-Message, FHIR-Hotel) ReadTopic(MedCom-Message, FHIR-Hotel, Patient) Notify(NewMessage) GetMessage() Set FHIR.Communication(XDIS91) Get FHIR.Communication(XDIS91) Figur 10 Sekvensdiagram af datadeling på forespørgsel MedCom Meddelelseshotel (FHIR) 76 Deltagernes erfaringer og evaluering Nedenfor beskrives evalueringer og vurderinger fra deltagerne i POC, herunder Connectathon d. 12/ Evalueringerne baseres på skriftlige tilbagemeldinger og afholdt fokusgruppemøde 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. 19

20 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 advisnotifikation 2, 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 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. Der er desuden nogle forhold, der er, eller er ved at blive afprøvet i andre sammenhænge end denne POC. Andre forhold, såsom fejlhåndtering, er i skrivende stund ikke afprøvet 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-baseretnotifikationsbaseret 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-baseretnotifikationsbaseret meddelelsesudvekslingsmodel ikke er afprøvet, og det kan også forventes at bidrage til at øge processerne hos modtagerne. 2 Begrebet Notifikation anvendes her i stedet for begrebet Advis, eftersom Advis har nogle sundhedsfaglige betydninger, der ikke er en del af det ønskede budskab i denne rapport. Dog er Advis anvendt hidtil i rapporten, eftersom afsnittene 1 til 4 baseres på materiale fra PID en, hvori begrebet indgik. 20

21 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 Proces I indeværende afsnit beskrives deltagernes evalueringer af Medcoms proces i forbindelse med planlægning og afholdelse af POC, herunder Connectathon d. 12/ 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/ 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. 87 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. <Der er udarbejdet foreløbige tal. Skal tal indarbejdes nedenfor?> Oversigt 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 21