MEDCOM Rambøll Management Consulting PETH/MTHAS/OVI
01-03-2019
Oplæg til evaluering af POC for modernisering af MedCom infrastruktur
Indhold
0 Om denne version ... 4
1 Indledning ... 4
2 Formål med projektet ... 4
2.1 Den nuværende situation (baggrund) ... 4
2.2 Formålet med projektets løsning ... 4
2.3 Projektets bidrag til strategiske mål ... 5
2.4 Den fremtidige situation efter indførelse af løsningen ... 5
2.5 Situationen hvis projektet ikke gennemføres (business as usual) ... 6
2.6 Alternative løsningsscenarier (Vurdér) ... 6
3 Afgrænsning ... 7
4 Status for eDelivery i international og national kontekst ... 7
5 Teknisk løsning ... 8
5.1 Overblik ... 8
5.2 Beskrivelse af de 4 varianter, der er afprøvet i POC ... 10
6 Deltagernes erfaringer og evaluering ... 19
6.1 Generelt ... 19
6.2 Koncepter ... 20
6.3 Teknik ... 20
6.4 Praktisk ... 20
6.5 Proces ... 21
7 Omkostninger til eDelivery og datadeling ... 21
7.1 Oversigt ... 21
7.2 Faseopdeling ... 21
7.3 Generelle omkostningsdrivere ... 22
7.4 Forberedelse ... 22
7.5 Centrale komponenter ... 22
7.6 Decentrale komponenter ... 22
7.7 Projektomkostninger ... 24
7.8 Governance ... 24
7.9 Drift ... 24
7.10 Øvrige forhold der kan påvirke omkostningerne ... 24
7.11 Gevinster ... 26 Hvis du har brug for at læse dette dokument i et keyboard eller skærmlæservenligt format, så klik venligst på denne knap.
8 Samlet evaluering ... 26
8.1 Hurtig, stabil og sikker overlevering af relevante datasæt ... 27
8.2 Stille relevante data til rådighed for onlinedeling på forespørgsel ... 27
8.3 Omlægning til datadeling ... 27
8.4 Deling af data på sundhed.dk og mobile platforme ... 27
8.5 Sundhedsfaglige og arkitekturmæssige valg ved overgangen til eDelivery og datadeling ... 28
8.6 Samlet konklusion og anbefaling... 28
1 Indledning ... 4
2 Formål med projektet ... 4
2.1 Den nuværende situation (baggrund) ... 4
2.2 Formålet med projektets løsning ... 4
2.3 Projektets bidrag til strategiske mål ... 5
2.4 Den fremtidige situation efter indførelse af løsningen ... 5
2.5 Situationen hvis projektet ikke gennemføres (business as usual) ... 6
2.6 Alternative løsningsscenarier (Vurdér) ... 6
3 Afgrænsning ... 7
4 Status for eDelivery i international og national kontekst ... 7
5 Teknisk løsning ... 8
5.1 Overblik ... 8
5.2 Beskrivelse af de 4 varianter, der er afprøvet i POC ... 10
6 Deltagernes erfaringer og evaluering ... 19
6.1 Generelt ... 19
6.2 Koncepter ... 20
6.3 Teknik ... 20
6.4 Praktisk ... 20
6.5 Proces ... 21
7 Omkostninger til eDelivery og datadeling ... 21
7.1 Oversigt ... 21
7.2 Faseopdeling ... 21
7.3 Generelle omkostningsdrivere ... 22
7.4 Forberedelse ... 22
7.5 Centrale komponenter ... 22
7.6 Decentrale komponenter ... 22
7.7 Projektomkostninger ... 24
7.8 Governance ... 24
7.9 Drift ... 24
7.10 Øvrige forhold der kan påvirke omkostningerne ... 24
7.11 Gevinster ... 26
8 Samlet evaluering ... 26
8.1 Hurtig, stabil og sikker overlevering af relevante datasæt ... 27
8.2 Stille relevante data til rådighed for onlinedeling på forespørgsel ... 27
8.3 Omlægning til datadeling ... 27
8.4 Deling af data på sundhed.dk og mobile platforme ... 27
8.5 Sundhedsfaglige og arkitekturmæssige valg ved overgangen til eDelivery og datadeling ... 28
8.6 Samlet konklusion og anbefaling... 28
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 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.
32 Formål med projektet
3.12.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
3.22.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
• 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
Formateret: Ikke Fremhævning
Formateret: Ikke Fremhævning
3.32.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.
3.42.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.
Formateret: Ikke Fremhævning
Formateret: Ikke Fremhævning
Formateret: Ikke Fremhævning Formateret: Ikke Fremhævning
Formateret: Ikke Fremhævning
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.
3.52.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 bilag1.
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.
3.62.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
1I bilag til PID.
Formateret: Ikke Fremhævning
Formateret: Ikke Fremhævning Formateret: Ikke Fremhævning
Formateret: Ikke Fremhævning
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 (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.
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.
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 2016-2020 under initiativ 8.1 Gode data og effektiv datadeling. Der er
Formateret: Ikke Fremhævning
Formateret: Ikke Fremhævning
Formateret: Ikke Fremhævning
Formateret: Skrifttype: Fed
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
6.15.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
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.
Formateret: Ikke Fremhævning
Formateret: Ikke Fremhævning
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.
6.1.1 POC’ens forudsætninger 5.1.1 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 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.
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.
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-
Formateret: Skrifttype: Fed
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 point- installation 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.
6.25.2 Beskrivelse af de 4 varianter, der er afprøvet i POC Herunder beskriver MedCom detaljeret, hvilke varianter der er afprøvet.
6.2.15.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.
Formateret: Skrifttype: Calibri, 11 pkt
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. 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.
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.
6.2.25.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.
RegionSyd
Ansat Cosmic PLSP
Send XDIS91
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)
getAddress (PLSP, distribution)
Figur 4 - Sekvensdiagram af 4-corner modellen
6.2.35.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
- 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.
RegionSyd
Ansat Cosmic C1_1
C1_1 PLSP
C3_1
Send XDIS91
Send XDIS91
AS4(Ack)
KMD AP
C1_2 GW AP
C2_2
Send AS4(SBDH(XDIS91))
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)
getAddress (Cosmic, opkomst)
Figur 6 - Sekvensdiagram af 3-corner modellen
6.2.45.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.
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.
6.2.55.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.
Figur 8 Sekvensdiagram af datadeling på forespørgsel – Dokumentdelingsservicen (DDS)
6.2.65.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
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()
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.
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/12-2018. Evalueringerne baseres på skriftlige tilbagemeldinger og afholdt fokusgruppemøde.
7.16.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
Send XDIS91
AS4(Ack)
KMD AP GW AP
Send AS4(SBDH(XDIS91))
Set FHIR.Communi-
cation(XDIS91)
GW
Send AS4(SBDH(XDIS91))
NAS
SetNotification (MedCom-Message, FHIR-Hotel)
Abonnent
system RegSyd Ansat
ReadTopic(MedCom-Message, FHIR-Hotel, Patient)
Get FHIR.Communi-
cation(XDIS91) Notify(NewMessage)
GetMessage()
7.26.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 advisnotifikation2, 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.
7.36.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. 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.
7.46.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-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.
2Begrebet ”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.
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.
7.56.5 Proces
I indeværende afsnit beskrives deltagernes evalueringer af Medcoms proces i forbindelse med planlægning og afholdelse af POC, herunder Connectathon d. 12/12-2018.
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.
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?>
8.17.1 Oversigt
8.27.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.
8.37.3 Generelle omkostningsdrivere
Nogle generelle omkostningsdrivere skyldes høje og stigende krav til - Sikkerhed (fortrolighed)
- 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.
8.47.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.
8.57.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 adviseringnotifikationer 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.
8.67.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
- En lokal hub som Cloverleaf - Decentral/lokal instans af NSP - Af ekstern leverandør (som VANS)
- 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 advisnotifikation. En omlægning fra EDIFACT til eDelivery er en mere begrænset opgave med skift af protokoller end skiftet til advis-
baseretnotifikationsbaseret, 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å adviseringnotifikationer.
8.77.7 Projektomkostninger
Projektomkostninger vedrører primært interne medarbejdere til projektledelse og -gennemførelse. Der vil desuden være omkostninger til konsulenter til udbud.
8.87.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.
8.97.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.
8.107.10 Øvrige forhold der kan påvirke omkostningerne
I det følgende gennemgås en række forhold, som også kan påvirke omkostningerne.
8.10.17.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.
8.10.27.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
Formateret: Skrifttype: Calibri, 11 pkt Formateret: Indrykning: Venstre: 1,27 cm
EU har etableret en SML, som i første omgang forventes at kunne dække behovet for Danmark også.
SMP adressekataloget forventes etableret nationalt af Digitaliseringsstyrelsen som led i
implementeringen af eDelivery. Om nødvendigt kan der her på sigt etableres en sundheds SMP, men i første omgang skønnes det ikke nødvendigt.
Der skønnes ikke omkostninger hertil for sundhedsområdet.
8.10.37.10.3 Eksisterende komponenter
Den moderniserede infrastruktur med gateway og repository vil anvende en række eksisterende komponenter, bl.a.
- Adviseringsservice (NAS) på NSP - Sikkerhedsinfrastrukturen på NSP - SOR, CVR
Der kan være omkostninger til anvendelse af disse komponenter, fx øget belastning af adviseringsservice.
8.10.47.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.
8.10.57.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.
8.10.67.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 test og implementering af nye standarder, da Access Points er indholdsagnostiske. Dog kan implementering af Connectorer betyde omkostninger.
8.10.77.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.
