Teknologisk fremtidssikring af MedCom- kommunikationen

(1)

Deloitte Consulting

kommunikationen

Delprojekt 3 i MedCom8

13. september 2012

(2)

 Indledning

 Kortlægning

 Scenarieskitser

(3)

Indledningen indeholder en kort beskrivelse af baggrund og fokus for

projektet ’Teknologisk fremtidssikring af MedCom-kommunikationen’

(4)

 Som en del af MedCom8 er der igangsat et delprojekt under

overskriften teknologisk fremtidssikring af MedCom-kommunikationen.

 Fokus i delprojektet er på de kommunikationselementer, som er en del af MedCom’s ansvarsområde: Meddelelsesstandarderne, VANS-

nettet, SDN, ’hotel’-løsninger, E-Journal og P-Journal.

 Projektets formål er:

– At udarbejde en beskrivelse af den nuværende tekniske infrastruktur for de kommunikationselementer, som MedCom har ansvaret for herunder

governance og organisering.

– At udarbejde et indledende forslag til fremtidssikring af MedCom’s infrastruktur, som kan tjene som beslutningsgrundlag for om der skal opstilles en mere konkret plan for en sådan fremtidssikring

– At etablere en plan for fremtidssikringen, i det omfang MedCom’s

styregruppe og NSI beslutter dette baseret på beslutningsoplægget. I givet

fald vil realiseringen af en fremtidssikring skulle gennemføres i et antal

projekter under MedCom9.

(5)

 Nærværende dokument indeholder et udkast til afrapportering på kortlægningsarbejdet.

 Kortlægningen systematiserer observationer indsamlet igennem interviews med en række centrale aktører og interessenter sundhedssektoren. Kortlægningen har taget udgangspunkt i følgende temaer:

1. Ændrede behov og krav fra sektoren

2. Organisation og styring i og omkring MedCom 3. Arkitektur og teknologi i forbindelse MedCom’s

standarder, løsninger og netværk

4. Udfordringer i forhold til fremtidssikring af MedCom’s datakommunikation

 På de følgende sider præsenteres en standardiseret

beskrivelse for hver kommunikationskomponent (jf. opdrag).

 Dette involverer en generel introduktion af hver komponent, samt en redegørelse for punkterne 2, 3 og 4 i denne

oversigt.

 På baggrund af kortlægningsarbejdet etableres et antal scenarier for MedCom's’ fremtidige virke. Disse scenarier kan efterfølgende uddybes og lægges ud i et roadmap.

3. Arkitektur og teknologi 2. Organisation

og styring 1. Ændrede behov

og krav fra sektoren

4. Udfordringer i forhold til fremtidssikring

5. Scenarier

6. målbillede og roadmap

(6)

Kortlægningen indeholder dokumentationen af den gennemførte

kortlægning af MedCom’s kommunikationselementer

(7)

De to netværk VANS og Sundhedsdatanettet er helt centrale i forhold til transport af sundhedsdata i Danmark. MedCom står selv bag Sundhedsdatanettet, hvorimod VANS-nettet primært kontrolleres af leverandørerne KMD og Evenex. MedCom står for en række standarder, der benyttes i kommunikation over de to netværk. MedCom har desuden været drivkraft i en række opsamlingssteder af data til specifikke formål; herunder E- og P-journal, WebReq samt RefHost/RefParc.

Kommune Kommune Region

Region Privat

praksis Privat praksis

Sundhedsdatanettet

Sund-

hed.dk Borger

Borger Borger

VANS

Region Region

Statslige aktører

(SST, LMS)

Kommune Privat

praksis Region

Hoved- staden

WebReq RefHost /RefParc

E- og P- journal

Borger

(8)

VANS

VANS står for Value Added Network Services og er en meddelelsesbaseret / postkassebaseret kommunikationsform (asynkron kommunikation). Alle aktører i det danske sundhedsvæsen har en postkasse hos en af to leverandører (KMD og Evenex) og aktørerne kan sende beskeder til andre aktørers postkasser samt modtage beskeder sendt til egen postkasse.

Beskederne omfatter blandt andet recepter, henvisninger, laboratorierekvisitioner og epikriser.

 VANS netværket er opbygget omkring to private leverandører KMD og Evenex.

 Hver bruger er forbundet til én leverandør og de to leverandørerne har desuden en indbyrdes forbindelse.

 Beskeder til leverandørens egne kunder fordeles umiddelbart ved ankomst. Hvis leverandøren ikke har modtageren som kunde, videresendes beskeder til den anden leverandør.

 Endvidere er leverandørerne opsamlingsstationer i forhold til hotelløsningerne for rekvisitioner og henvisninger, således at beskeder af denne type opsamles og sendes til relevant hotel.

VANS

KMD Evenex

Bruger 3 Bruger 2

Bruger 1

KMD-kunder

Bruger 6 Bruger 5

Bruger 4

Evenex-kunder

WebReq RefHost/

RefParc

Hotelløsning

(9)

Kilde: Region Midtjylland har udarbejdet denne figur som del af internt kortlægningsarbejde

Eksempel på VANS-tilslutning

Som beskrevet på forrige side består det samlede VANS-net af en række sammenkoblede systemer. Eksemplet på denne side viser flere detaljer i VANS-forbindelsen til Henvisningshotellet og lægevagten med udgangspunkt i Region Midtjyllands EDI-server.

 Dette eksempel illustrerer det store antal potentielle fejlkilder, som opstår i et distribueret net, hvor mange aktører har

ansvaret for hver deres del.

 Eksempelvis afgøres den samlede overførselshastighed mellem to parter af mange forskellige konfigurationer undervejs i forsendelsen.

 Tilsvarende er der mange

steder, man kan igangsætte

fejlsøgning, hvis beskeder ikke

når frem.

(10)

VANS

Organisation og styring

• VANS-netværket drives i dag af to kommercielle leverandører

VANS drives af KMD og Evenex, som aktørerne i sundhedssektoren tegner aftale med om tilslutning. Aftalen er typisk indirekte gennem aktørens applikations leverandør (fx har leverandørerne af praksissystemer aftaler med en af de to VANS leverandører)

• VANS-brugerne er alle aktører i sundhedssektoren

Alle parter i den danske sundhedssektor anvender netværket herunder kommuner, regioner, praksisser, hospitaler og laboratorier.

• MedCom foretager basal test af VANS-leverandører

MedCom foretager certificering af de to leverandører i forhold til den grundlæggende funktionalitet på deres netværk. Testen inkluderer kontrol af leverandørernes mapningstabeller samt en kontrol af modtagelse og afsendelse af VANSEnvelope (testskemaet er senest opdateret i april 2011).

• MedCom specificerer beskeder

MedCom specificerer beskeder i samspil med brugerne, softwareleverandører og VANS-leverandørerne løbende nye beskedtyper til brug for VANS-netværket.

• MedCom medvirker i forbindelse med fejlsøgning

MedCom har ikke en formaliseret supportrolle i forbindelse med VANS-nettet, men har alligevel løbende bistået parterne med fejlsøgning.

Arkitektur og teknologi

• VANS er et asynkront en-til-en meddelsessystem

VANS er et meddelelsesbaseret system, hvor kommunikation sker ved asynkron transport af standardiserede EDIFACT og XML-beskeder, der sendes mellem netværkets aftagere (en-til-en) via en postkasse-lignende funktionalitet.

• VANS kommunikation sker via centrale servere

Brugernes systemer kommunikerer med VANS-leverandørerne ved brug af en række forskellige protokoller typisk FTP, SFTP eller MQ-BUS. Selve netværket er baseret på kommercielle internetopkobling (fx ADSL), hvor de enheder, der er placeret hos brugerne, kommunikerer via egen softwareleverandør med de centrale servere hos en af de to leverandører.

• Autentifikation benytter brugeren lokationsnummer

VANS-leverandørerne autentificerer brugerne ved en kombination af brugernavn, kodeord og lokationsnummer. Omvendt den udbredte praksis i offentlige systemer benyttes ikke Digital Signatur.

(11)

VANS

• Information om modtager-lokation findes i selve beskeden

På VANS-nettet sker routningen af besked til modtager efter opslag af routningsinformation (fx modtager-lokation) i beskedens header. Fordi routningsinformationen er pakket ind i selve beskeden og ikke findes som metadata, skal knudepunkterne i netværket skal udpakke beskederne, læse og videresende.

• Særligt driftsmønster giver potentiale for lange transporttider i netværket

Netværket er kendetegnet ved et særligt driftsmønster, hvor afsendersystemerne typisk kun kommunikerer med deres leverandør med intervaller på 5-12 minutter. Beskederne overføres direkte til modtagerens postkasse hos leverandøren, eller videresendes til den anden VANS-leverandør, hvis denne benyttes af modtageren. Beskedmodtagerens system foretager opkald med tilsvarende minutintervaller og henter derved beskeder fra postkassen hos egen leverandør. Heraf følger en øget samlet transmissionstid, i forhold til hvis data blev udvekslet direkte mellem afsender og modtager.

Brugernes egne it-systemer kan medvirke til forsinket kommunikation. I en række kommuner, der er KMD-kunder, benyttes et såkaldt KFS-system i kommunikationen med VANS. KFS har traditionelt været konfigureret til at operere i intervaller på 30 minutter.

• Ingen central lagring af data

VANS-nettet tilbyder ikke nogen lagring eller registrering af data eller metadata. Til udvalgte formål er der dog opstillet udtræksservere hos VANS-leverandørerne, som kommunikerer med Henvisningshotellet, WebReq, apotekernes receptserver m.fl.

Udfordringer i forhold til fremtidssikring

• Akutte henvisninger kan give problemer i forhold til kommunikationshastighed

Brugen af VANS giver særligt udfordringer i sammenhænge hvor, der er krav om hurtig overførsel af data. Dette behov findes eksempelvis i forbindelse med akutte henvisninger og accelererede pakkeforløb (fx kræftpakker). I sådanne sammenhænge kan VANS ofte have svært at leve op til krav om høj hastighed. Problematikken bliver løbende mere aktuel i takt med udbredelse af disse pakkeforløb.

I forlængelsen af ovenstående peges på muligheden for at indføre prioriteret kommunikation, som en løftestang til at sikre, at vigtige data kommer hurtigt frem.

• Ændrede behandlingssmønstre fordrer både øget kommunikationshastighed og fælles data

Ændringer i behandlingsmønstrer fx på grund af større samarbejde mellem primær og sekundær sektor samt større brug af ambulatorieforløb, medfører ændrede behov for it-understøttelse; herunder eksempelvis ønske om, at data deles i stedet for at blive sendt frem og tilbage i mellem parterne. Det foreslås fra nogle aktører, at der i højere grad satses på central lagring af data.

(12)

VANS

• Et stort antal aktører gør det vanskeligt at placere ansvar

Det er desuden problematisk, at der ikke findes noget formel specifikation af hvor lang transmissionstiden må være. Fravær af en formel tidsgrænse gør det svært at konstatere, om der er tale om driftsproblemer, når en besked ikke kommer igennem til modtageren som forventet. Det er vanskeligt at placere ansvaret i denne forbindelse, når afsender og modtager kan være forbundet via fagsystemer fra forskellige leverandører (fx lægesystemer, EOJ- eller EPJ-systemer) til en af de to VANS- leverandører.

Brugere af VANS-nettet beretter om at beskeder i nogle tilfælde slet ikke ankommer. Der peges på, at der er behov for nogen, som tager et samlet tværgående ansvar for ’VANS’ (end-to-end).

• Manglende implementering af kvitteringsbeskeder (positiv/negativ)

Der er ikke implementeret kvitteringsbeskeder (positiv/negativ) for alle dele VANS-nettet. Det gælder både afsendelse af kvitteringer men også håndteringen i brugersystemerne af negative kvitteringer. Der er et stort ønske om fuld udbredelse af modtagelseskvitteringer, da dette vil kunne muliggøre væsentlige optimeringer af de nuværende arbejdsgange.

• Teknologien opleves udskiftningsmoden

Af nogle parter opleves VANS-teknologien som udskiftningsmoden og ikke som kandidat til en fremtidig transportmekanisme i nye sundheds-it-løsninger. Dette kan blandt andet begrundes med at man baserer sig på MedCom’s dialekter af EDIFACT standarder, som ikke understøttes af kommercielle værktøjer, hvilket resulterer i et meget begrænset antal mulige

leverandører. Dette er delvist afhjulpet af MedCom dannelsen af EDIXML-beskeder, der kan sendes over VANS.

Der findes ikke nogen løsninger fra udenlandske leverandører, der som udgangspunkt implementerer EDIFACT som transportlag.

• Manglende centrale adresseopslag fører til fejlforsendelse

Der ligger ikke noget centralt adresseopslag til grund for beskedudvekslingen på VANS. VANS-leverandørerne og

leverandører af fx læge- og EOJ-systemer vedligeholder egne lister over gyldige lokationsnumre (brugere) på VANS. I disse lister registreres det også, hvilke beskeder hver lokation er i stand til at modtage. Det giver tilbagevende problemer med fejlforsendelser og tidsspilde i VANS-trafikken, når parterne har forskellige lokationsoplysninger. Endvidere giver det

udfordringer i forhold til den løbende synkronisering med SOR bl.a. på grund af datakvaliteten i SOR og idet der ikke udstilles en online-snitflade, som kan anvendes til direkte sytem-til-system opslag/integration.

• Tidsstempler er baseret på lokale ure og ikke en fælles tidsserver

Det foreslås af nogle parter, at der bør oprettes en central tidsserver, der kan levere klokkeslæt til tidsstempler i

beskedheaderen på VANS-besked. I den nuværende situation benytter parterne tidsstempler fra egne systemer, der ikke er synkroniserede, hvorved der blandt andet kan opstå usikkerhed om det egentlige tidsforbrug mellem afsendelse og

modtagelse af beskeder.

(13)

VANS

• Mulighed for at abonnere på CPR-numre

Det nævnes af enkelte parter som et ønske til fremtidig funktionalitet, at man kan abonnere på nye data om et givent CPR- nummer. Det står i kontrast til de nuværende situation på VANS, hvor en besked sendes til en bestemt modtager på nettet, og derefter ikke findes på nettet. Denne abonnement-idé eksempelvis kombineres med en ny fælles fordelingsmotor til VANS.

• Ingen reel konkurrenceudsættelse

Det påpeges, at der ikke reelt er nogen konkurrence mellem de to VANS-leverandører. Der peges på en alternativ strategi som den, der er valgt for NSP, hvor ejerskabet til infrastrukturen ligger ved kunden, hvorimod drift, support og vedligehold outsources. Et løbende udbud af sådanne aftaler vil give en mere reel konkurrenceudsættelse og resultere i mere

tilfredsstillende service og lavere priser.

(14)

Sundhedsdatanettet - SDN

 SDN er opbygget omkring et nationalt knudepunkt som brugerne enten er direkte tilkoblet eller forbundet til via faste forbindelser/egen MPLS eller VPN. Knudepunktet er firewall- baseret og router trafik videre i mellem parter, der har indgået en passende aftaler i aftalesystemet, som er et elektronisk servicekatalog indeholdende SLA-oplysninger om hver enkelt service.

 Hos de parter der er tilkoblet SDN-MPLS er der opstillet en såkaldt kant-router, der får en routningstabel opdateret fra centralt hold. Derved opnås, at de samme sikkerhedsregler er gældende på det distribuerede netværk og at trafikken kan gå direkte mellem parternes kant-routere og ikke behøver at gå gennem samme fysiske knudepunkt

 Sundhedsdatanettet medvirker til at dække flere forskellige kommunikationsbehov i sektoren; herunder fx EPJ-data, Laboratorieportalen, RefHost, videokonferencer,

indberetninger, CPR-opslag og opslag af ydere.

 SDN benyttes til at indhente data til mange danske sundhedssystemer; herunder E-Journal,

Vaccinationsregister, Interregionalt Billedindeks, Sundhed.dk, Nationalt PatientIndeks (NPI). Derudover er SDN vært for den Nationale Service Platform (NSP), som aktuelt udbyder det Fælles MedicinKort som web service.

SDN er oprindeligt etableret som supplement til VANS, med det formål at håndtere kommunikationsbehov, der ikke passer ind i det asynkrone paradigme, der ligger til grund for VANS. SDN løser endvidere en fælles udfordring med sikker

kommunikation på tværs af sektoren herunder verifikation, idet netværket er krypteret og omfatter et aftalesystem, som sikrer, at der er indgået aftaler mellem de parter der ønsker at kommunikere over netværket.

Kilde: MedCom

(15)

Sundhedsdatanettet - SDN

• Sundhedsdatanettet finansieres af de tilsluttede parter

MedCom er udbyder af Sundhedsdatanettet og tilbyder det til aktørerne i sundhedsvæsenet gennem indgåelse af en samarbejdsaftale mellem MedCom og den pågældende aktør. Hovedprincippet i finansieringen af netværket er, at de tilsluttede parter skal dække udgifterne til netværket. Endvidere gælder det, at den enkelte aktør er efter indgåelse af aftale selv ansvarlig for at etablere og drive en forbindelse til Sundhedsdatanettets knudepunkt.

• SDN er underlagt MedCom’s styregruppe

Beslutninger om videreudvikling og nye tiltag på Sundhedsdatanettet træffes af MedCom’s styregruppe.

• Aftalesystemet administrerer adgange

Sundhedsdatanettet er omfattet af det såkaldte aftalesystem, hvor parter både kan anmode om adgang andre parters netværk – og selve give tilladelse til andre adgang til eget netværk.

• Den tekniske drift er todelt

Den tekniske drift af Sundhedsdatanettets er aktuelt delt mellem to leverandører NETIC og NetDesign. NETIC håndterer DNS og aftalesystemet imens NetDesign har ansvar for tilslutningsaftaler og teknisk routersupport.

• SDN forbinder adskilte netværk

SDN udgør transportlaget i netværkskommunikationen mellem alle tilkoblede brugere i sundhedssektoren. SDN er baseret på IP og tilbyder som sådan online/synkron kommunikation i mellem systemer placeret i adskilte netværk.

• Flere tilkoblingsmuligheder

SDN er et nationalt knudepunkt opbygget omkring to datacentre, som brugerne enten er direkte tilkoblet eller forbundet til via MPLS eller VPN. På baggrund af de aftaler, der er oprettet mellem forskellige brugere i aftalesystemet, tilføjes automatisk routing-regler SDN’s firewall, så de relevante data kan transmitteres i mellem parterne.

• Kant-router

De tilkoblede parter at få opstillet en såkaldt kant-router, der får en routningstabel opdateret fra centralt hold. Derved opnås, at trafikken kan gå direkte mellem parternes kant-routere og ikke behøver at gå gennem samme fysiske knudepunkt.

• SDN benytter hardware kryptering

Al trafik der passerer internt i Sundhedsdatanettet er omfattet af hardwarekryptering. Ansvaret for at data håndteres sikkert påhviler brugerne selv, frem til SDN kant-routeren.

• Ansvar for adgange er distribueret

Forbindelse via SDN giver adgang fra det kaldende netværk til en række pre-definerede services på det kaldte netværk. Det kontrolleres fra serviceaftagerens netværk, hvem der kan kalde, i mens det er serviceudbyderens regler, der bestemmer hvem, der reelt gives adgang.

(16)

Sundhedsdatanettet - SDN

• Aftalesystemet skal forpligte mere

Aftalesystemet lader til rent teknisk at fungere tilfredsstillende, der er derimod en udfordring i at få alle tilkoblede

organisationer til hurtigt at besvare anmodninger om dataadgang. Der kunne være behov for at styrke den organisatoriske opbakning omkring aftalesystemet, og derved sikre at tilladelser gives hurtigere.

• Stigende krav til kapacitet

Fremadrettet vil kravene til netværkskapacitet på Sundhedsdatanettet stige. Derfor er der behov løbende overvågning af udviklingen i trafikmængden, så man kan imødegå eventuelle kapacitetsproblemer.

• Manglende support

Brugerne udtrykker, at der mangler en samlet support hvor man hurtigt kan få hjælp til problemer med Sundhedsdatanettet.

Det forslås videre at supportfunktionen kunne holde et centralt overbliksbillede over aktuel connectivity i hele nettet, for at kunne løse problemer proaktivt.

• Brugere har problem med egen opsætning

Flere brugere oplever problemer med NAT konfiguration på egne routerer i forbindelse med første tilkobling til SDN og ved ændrede centrale konfigurationer.

• Ingen central UDDI

Aftalesystemet indeholder lister over udstilles services, men 1) kvaliteten afhænger af at den enkelte serviceudbyder har dokumentere tilstrækkeligt og 2) aftalesystemet er primært et administrativt system og ikke fokuseret på programmatisk opsalg / webservice-integration (UDDI).

(17)

- 17 -

Standarder

MedCom har igennem en længere årrække været

toneangivende i arbejdet med at udvikle og vedligeholde standarder til brug i dansk sundheds-it. Dette arbejde har hovedsagligt været orienteret i mod databærende

standarder, der på kan bruges til at overføre velstrukturerede data i mellem it-systemer.

Arbejdet med standardisering omfatter blandt andet følgende:



EDIFACT/EDIXML benyttes ved overførsel af data på VANS- nettet. De nyere standarder findes kun i XML-versioner. Til forsendelse af binære data benyttes MedBin formatet, som er en specifik EDIFACT-besked.



Den Dynamiske Blanket (DDB) som er anvendt i forbindelse med Genoptræningsplaner og LÆ-blanketter til kommunal udveksling af data mellem lægepraksisser og sociale myndigheder.



Standarder for E-journal og P-Journal (SUP-standarden)



PLO-formatet/FNUX (Fælles nationalt udvekslingsformat i XML), som benyttes til udveksling af patientjournaler

forbindelse med at en borger skifter til en læge, som benytter et andet lægesystem.



Den gode webservice (DGWS) som definerer nogle

retningslinjer for hensigtsmæssig brug af SOAP webservices i sundhedssektoren. DGWS er udviklet af MedCom, men ejerskabet ligger i dag ved NSI.

Område

EDIFACT EDIXML Webservice Dynamiskblanket PLO/FNUX Hotelløs-ninger

Henvisning X X X

Rekvisitioner og svar X X X X

Epikriser X X

Korrespondancemeddelelse X X

Receptfornyelse X X

Bookingsvar X X

Genoptræningsplan X X

Indlæggelsesrapport X

Plejeforløbsplan X

Melding om færdigbehandling X

Udskrivningsrapport X

Indlæggelsesadvis og svar X X

Udskrivningsadvis X

Fødselsanmeldelse X X

Børnedatabaseindberetning X X

Kommunale attester X X

Kroniker datasæt X X

Afregning X

Recepter X X

Udveksling af komplet

lægejournal X

Det Fælles Medicinkort (FMK) X

Inspiration: MedCom – Dorthe Skou Lassen

(18)

Standarder

På figuren til højre er det illustreret, at begrebet standarder kan knyttes til flere forskellige elementer. Opstillet som en ’stack’, kan dette groft opdeles på følgende måde:

 Standarder for netværk (fx VANS) med overliggende tekniske kommunikationsstandarder (fx EDIFACT eller WS).

 Standarder for beskeder, klassiske MedCom standarder, som vil kunne opdeles i datastandarder og indholdsmæssige standarder.

Netværk (VANS, SDN) Transport standard (fx EDIFACT, MQ, WS, FTP) Sundhedsfaglig datastandard (fx EDIFACT/XML, HL7, FNUX , SUP) Sundhedsfaglig indholdsmæssig standard (nomenklarturer, klassifikationer fx IDC10

og SNOMED) Brugersystemer (fx E-journal, EPJ, EOJ)

SDN / VANSMedCom Std.

(19)

Standardiseringsarbejde i international sammenhæng

Standardiseringsarbejdet i den danske sundhedssektor; herunder MedCom’s arbejde har blandt andet været udført med skelen til danske og internationale standardinitiativer af forskellig karakter. Denne liste sammenstiller udvalgte af disse initiativer, som dels er refereret i NSI’s referencearkitektur for standarder - og dels blev nævnt af aktører den overståede interviewrunde.

Standard Type Beskrivelse

HL7 CDA Sundhedsdata-

format

HL7 CDA er en XML-baseret datastandard, der på semantisk og strukturelt niveau definerer opbygning af dokumenter til udveksling af kliniske data.

HL7 CCOW Styring af datakontekst

HL7 CCOW bruges til at opbygge en fælles kontekst på tværs af underliggende og adskilte systemer, så man fx som

sundhedsprofessionel kan trække data til en samlet visning om en bestemt patient fra mange kilder. Dette kan opfattes som en udvidet single sign-on mekanisme.

IHE EUA Profilering af HL7 CCOW

IHE (Integrating the Health Enterprise) har udarbejdet en formel profilering af HL7-CCOW, der kaldes EUA (User Authentication).

Profilen specificerer i detaljer hvordan single sign-on kan implementeres i henhold til HL7-CCOW.

IHE XDS Mekanisme til udveksling af dokumenter

XDS (Cross-Enterprise Document Sharing) håndterer registrering og udsendelse patientdata samt dataadgang på tværs af sundhedssystemer. XDS ligger til grund på det danske Nationale Patient Indeks (NPI) og det kommende nationale billedindeks. Det indgår desuden i flere andre telemedicinske sammenhænge.

epSOS System til

udveksling af data

epSOS (Smart Open Services for European Patients) er et nyt europæisk system til udveksling af patientdata med fokus på medicinrecepter, der blandt andet anvender HL7 CDA og IHE XDS.

Continua Health Alliance

Sammenslutning af producenter

Continua Health Alliance er en sammenslutning primært bestående af store teknologiprocenter. Organisationen arbejder blandt andet med at etablere industristandarder til brug for telemedicinområdet; idet de løbende certificerer teknologiprodukter (fx smart phones og måleudstyr), der lever op til deres krav.

ICD10 Klassifikations- system

Et klassifikationssystem for sygdomme udarbejdet af WHO.

ICD10 har været anvendt i Danmark siden 1995 i Sundhedsvæsnets Klassifikationssystem (SKS). I den danske profilering af ICD10 udvides koderne med underkoder.

SNOMED Klassifikations- system

SNOMED er et internationalt medicinsk klassifikationssystem, der blandt andet tilbyder en kobling mellem lidelser og kropsdelene hvor lidelserne optræder (multiaksial ). Sundhedsstyrelsen er ansvarlig for løbende oversættelse og tilpasning af SNOMED til danske forhold.

OIO-XML XML profilering OIO-XML er en dansk XML dialekt med tilhørende nationalt repositorium med specifikke standarder for mange forskellige sektorer.

OIOXML benyttes som grundlag for EDIXML til dataudveksling i VANSEnvelope via VANS-nettet.

(20)

Standarder: Rapport om standarder og referencearkitektur vedr. sundheds-it området

 Det foreslås i rapporten, at følgende områder prioriteres i arbejdet med standarder og referencearkitektur:

– Nationalt patientindeks / Regionalt billedeindeks

– Fælles model for indberetning og genbrug af data i nationale sundhedsregistre – Telemedicin og hjemmemonitorering

 Rapporten påpeger, at referencearkitektur bør udpege de strategiske valg i forhold til standarder for definition af asynkron kommunikation samt standard for transport af asynkron kommunikation. MedCom’s EDI og VANS-baserede

kommunikation udpeges som de facto-standarden. Samtidig er forventningen, at der i forbindelse med arbejdet med ’T02 Overførelse af beskeder’ i 2012 vil skulle træffes de nævnte strategiske valg, som sandsynligvis vil række udover de facto-standarden.

 I sammenhæng med rapporten har NSI kortlagt og kategoriseret de nuværende anvendte standarder i sundhedssektoren. Kortlægningen er samlet i et

Standardkatalog.

– 162 MedCom standarder er registreret i kataloget, heraf 77 som

”anbefalet” og 50 som ”anvendelig”.

(21)

Standarder

• MedCom skaber konsensus

MedCom’s rolle i forhold til standardiseringsarbejdet er at vedligeholde eksisterende standarder og skabe nye, hvis det er påkrævet. Arbejdet handler i vid udstrækning om at finde konsensus i mellem interessenter inden for det enkelte faglige område, hvilket blandt andet sker igennem inddragelse af brugergrupper.

• MedCom specificerer beskeder

Det er i sidste ende MedCom, der specificerer selve standarden i forhold til struktur og semantik. Dette arbejde finder ofte sted i delprojekter, hvor nye faglige områder inddrages.

• MedCom certificerer it-systemer til brug af standarder

En anden væsentlig del af MedCom’s arbejde består i at certificere it-systemer til at tage standarderne i anvendelse.

MedCom vedligeholder lister, der viser systemernes grad af kompatibilitet med de forskellige standarder.

• De første standarder i EDIFACT

De oprindelige MedCom-standarder er baseret på EDIFACT-meddelelser, som er tekst i en veldefineret struktur. Den grundlæggende EDIFACT syntaks har sin baggrund inden for e-handelsområdet.

• Overgang til EDIXML

Siden 2003 har MedCom sideløbende med EDIFACT-beskederne udarbejdet de såkaldte EDIXML-beskeder, som er baseret på OIO-XML. EDIXML-beskederne er struktureret således, at XML-indholdet er indlejret i EDIFACT-format. Nyere MedCom standarder er udelukkende defineret i EDIXML.

• Udbygning med webservices

MedCom har fra 2006 opereret med Den Gode Webservice (DGWS) som fælles grundlag for en række SOAP webservices til synkron dataudveksling i sektoren. Blandt andet benyttes DGWS af Børnedatabasen, der bestyres af KL. Herudover tilbydes en række services baseret på DGWS udstillet på den Nationale Sundhedsplatform; blandt andet Det Fælles Medicinkort (FMK), cpr-opslag, cpr-abonnementsservice og opslag i autorisationsregister.

(22)

Standarder

• Ingen tilbagevendende certificering

MedCom’s certificering gennemføres som regel kun en gang når et system har implementeret en ny standard. Nogle regioner udtrykker at tilbagevendende certificering bør finde sted hver gang et system eller en standard ændres. Kun på denne måde kan fuld kompatibilitet sikres.

• Vanskelig sammensætning af brugergrupper

MedCom’s udvælgelse af medlemmer til brugergrupper kritiseres for at være vanebetonet, således at det ofte er de samme aktører der opnår indflydelse. Regionerne ønsker sig at være med til sikre at det er de rigtige repræsenterer dem. En problematik i denne sammenhæng er at nye standarder ofte bliver et udtryk for laveste fællesnævner, fordi brugergrupperne har så forskellige indbyrdes syn på hvad, der skal inddrages i standarderne.

• Ingen fælles datamodel

Flere aktører i og uden for MedCom udtrykker bekymring for, at der ikke findes en samlet datamodel for MedCom’s standarder. Dette bidrager til en opfattelse af, at arbejdet starter forfra hver gang et nye område inddrages. Der er tilsyneladende en tendens til at hvert projekt er meget drevet at enkelt personerne hos MedCom.

• Manglende metadata til sikkerhedshåndtering

De nuværende standarder indeholder utilstrækkelig metadata til at muliggøre optimal sikkerhedshåndtering. Eksempelvis mangler der kontekstinformation, der tillader modtagersystemer at knytte modtagne data til registreringer af bestemte patientforløb og begivenheder. Derudover skal afsender og modtager af data være præcist identificeret ud fra officielle koder og ikke ud fra modtagesystemets tolkning af afdelingsnavne i fritekstfelter.

• Større fokus på internationale standarder

Det udtrykkes fra flere sider at MedCom i fremtiden bør prioritere anvendelse af internationale standarder højt. Det er forventningen hos nogle regioner og kommuner, at dette vil kunne give højere kvalitet og større ensartethed i fremtiden. Det betones dog at en overgang til eksempelvis HL7 bør ske gradvis, idet bagudkompatibilitet sikres. HL7 CDA benyttes i dag i mange leverandørsystemer.

(23)

Standarder

• OIO-XML og EDIXML begrænser konkurrencen

Det nævnes at flere internationale leverandører vil kunne byde på opgaver, hvis man fjernede krav om specifikke danske standarder så som OIO-XML. Desuden mener nogle, at det er uholdbart fremadrettet at benytte EDIXML, der er EDIFACT som indpakning til OIO-XML, da det er både forældet og ukendt udenfor Danmark. Ved at bede leverandørerne om at udvikle til disse standarder modarbejder man den generelle markedsudvikling og udelukker sig selv fra at benytte internationalt standardiserede beskeder og løsninger.

• Problematisk ændringsstyring

Det nævnes fra flere sider at MedCom skal styrke deres indsats i forhold ændringsstyring og versionsstyring af egne standarder. Der er behov en professionalisering af området blandt andet for at sikre klar kommunikation omkring ændringer og gældende versioner af standarder.

• Det tager lang tid at udvikle og implementere nye eller ændrede standarder

Der findes et ønske om at standarder skal være tilpas fleksible til at der hurtigt kan implementeres ændringer, som resultat af nye politiske beslutninger. Det er en udbredt holdning i sektoren, at der går for lang tid fra, at man går i gang med at danne eller ændre standarder til, at standarden kan tages i anvendelse på fx klinikker og hospitaler.

• Konsensus tager lang tid

Som nævnt har MedCom spillet en væsentlig rolle i at skabe konsensus mellem forskellige parter i sektoren. Denne tilgang kritiseres af enkelte parter for at være for tidskrævende. Der foreslås en alternative udviklingsmodel, som er i højere grad er baseret på pilot-projekter med enkelte parter.

(24)

E-Journal og P-Journal

 E-journal indeholder PAS-data samt EPJ- data fra alle landets offentlige sygehus herunder:

– Cave

– Notater (fra skadestue, i patientjournalen og epikriser) – Procedurer (fx indgreb) – Diagnoser (ICD10) – Medicinoplysninger

– Prøveresultater (røntgenbeskrivelser, blodprøvesvar) *

– Medicin-data *

 Både for E- og P-journal overføres data som XML batchmæssigt hvert døgn via FTP. Data er baseret på SUP-standarden.

*) fra en tredjedel af sygehusene

E-journal udstiller en samlet oversigt over borgeres behandlinger og diagnoser samt øvrige informationer optaget i forbindelse med deres indlæggelse eller ambulante behandling på regionernes sygehuse. Efter planen suppleres E-Journal i løbet af 2012 med P- Journal data, som indeholder klinisk information fra almen praksis og speciallægepraksis. Data i journalsystemerne stilles til rådighed for borgeren selv og for borgerens egen læge samt øvrige praktiserende læger via Sundhed.dk. Sygehusansatte har desuden også adgang til data via Sundhedsdatanettet.

Dataopsamling

SUP SUP

Kilde: MedCom – Jens Rahbek Nørgaard

(25)

E-Journal og P-Journal

• Samarbejdet på tværs af sektoren

E-journal er etableret i samarbejde mellem Danske Regioner, Sundhed.dk og MedCom, som en videreførelse af det tidligere SUP-projekt. Efter planen suppleres E-Journal i løbet af 2012 med P-Journal, som tilbyder klinisk information fra almen praksis og speciallægepraksis.

• Underlagt Sundhedsjournalens styregruppe

MedCom er ansvarlig for projektledelse og drift af både E-journal og P-journal. Arbejdet med systemer er forankret i Sundhedsjournalens styregruppe.

• Forskelligartede dataleverancer

Det er forskelligt fra region til region hvilke typer af data, der stilles til rådighed for e-journal – fra alle offentlige sygehuse leveres dagligt data om blandt andet diagnoser, kontakter, behandlinger og notater for patienter.

• E-journal som del af Sundhed.dk

E-journal er bygget ind i den nationale portal Sundhed.dk som en portalvisning af data til borgere og praktiserende læger. E- journal er indlejret i Sundhed.dk som en frame og altså ikke fuld integration. Data i E-journal er desuden tilgængelige via Sundhedsdatanettet fra landet sygehuse via sygehussystemerne.

• Data overføres dagligt

Patientdata fra EPJ- og PAS-systemer baseret på SUP-specifikationen hentes en gang i døgnet til e-journals centrale database. Data overføres batchmæssigt med FTP-forsendelser via Sundhedsdatanettet.

• Logning af adgange

Alle læger har adgang til at se patientens data. Derfor er der indført logning af visninger, så borgere kan se hvilke læger, der har læst deres journal-oplysninger.

(26)

E-Journal og P-Journal

• Distribuerede datakilder giver deling af dataansvar

Både i den nuværende og den fremtidige løsning ligger data distribueret i et større antal databaser og systemer, hvilket har fra nogle aktører netop har været et kritikpunkt. Når data er distribueret vanskeliggøres eksempelvis fremskaffelse af historiske data til brug for evt. klagesager. Derudover bliver ansvaret for opdateringer og kvalitetssikring af data også distribueret, og det kan blive svært at garantere en ensartet kvalitet.

• Systemet kører for langsomt

E-journal bliver kritiseret for at være langsomt at arbejde med hos praksislæger i en grad, der gør at læger, så vidt muligt fremskaffer data fra andre kilder.

• Svag integration med national løsning

Visningsdelen af E-journal bliver kritiseret for at passe dårligt ind i Sundhed.dk’s grafiske layout.

• Sundhedsjournalen som visning

E-journal og P-journals visningsdel bliver overflødiggjort i forbindelse med lanceringen af Sundhedsjournalen er et tiltag fra Sundhed.dk, som udover E- og P-journaldata vil kunne præsentere data fra eLPR, PEM, Laboratorieportalen og

Donorregistret. Sundhedsportalen forventes klar i slutning af 2013. Data til Sundhedsjournalen fremsøges ved hjælp af det Nationale Patient Index og gøres tilgængelige for sundhedsprofessionelle og borgere i fagsystemer og på Sundhed.dk. I denne sammenhæng indgår Nationale Service Platform både i forhold til dataintegration og sikkerhed.

• Samtykke håndteres i et samspil med forskellige lokale løsninger

Det påpeges at sikkerheden omkring patientsamtykke i E-journal håndteres i et samspil med forskellige lokale løsninger, og at dette giver en række udfordringer. Nogle parter angiver i forsendelsen om patienten har givet samtykke eller ej, mens andre undlader at sende, hvis ikke der er samtykke. Således kan det blive et fortolkningsspørgsmål, om patienten reelt ønsker at give samtykke. Endvidere er løsningerne ikke indrettet til at håndtere ændring i patientens samtykke over tid.

Sådanne ændringer må håndteres ad hoc ved manuelt at tage kontakt til de aktører, der ejer data.

(27)

Hotelløsninger



Aktuelt findes der

– Henvisningshotellet (RefHost/RefParc) som benyttes til at oprette henvisninger af patienter til videre undersøgelse og behandling.

Eksemplet i figuren viser hvordan en patient henvises til kiropraktor.

– WebReq som benyttes til at bestille prøve fra laboratorier.

– Laboratorieportalen som er indbygget i Sundhed.dk og benyttes til at udstille prøvesvar fra danske laboratorier.



Hotelløsningerne benytter en kombination af nyere og ældre teknologi i koblingen af web-løsninger med det lukkede VANS- net. På figuren ses et eksempel på hvordan denne udveksling af data finder sted i forbindelse med Henvisningshotellet.

– På baggrund af lægens indtastninger og valg danner

Henvisningshotellet Ref01/Ref06 EDI-meddelelser, som sendes via VANS-nettet til RefHost. Når patienten henvender til sig vedrørende henvisningen fremsøges den på webhotellet.

– Fra indeværende år findes alle henvisninger på RefHost, uanset om de er sendt direkte mellem to parter.



Hotelløsninger er kendetegnet ved at være interaktive. Dette er i kontrast til E- og P-journal, som udelukkende samler og præsenterer data.

Ordet hotelløsning benyttes som samlebetegnelse for en række web-baserede løsninger, som MedCom har fået udviklet til at håndtere bestemte typer af oplysninger som kommunikeres på VANS-nettet. Fælles for løsningerne er at brugertypen er sundhedsprofessionelle og at brugen er interaktiv. Det vil sige at brugeren træffer valg og tilføjer information, som indgår i et undersøgelses- eller behandlingsforløb for en patient.

Eksempel på VANS-kommunikation Kilde: MedCom

(28)

Hotelløsninger

• Hotelløsninger til specifikke behov

De eksisterende hotelløsninger er vid udstrækning opstået som svar på specifikke behov i sektoren, som MedCom selv har identificeret eller er blevet gjort opmærksom på af andre parter.

• MedCom står bag hoteller

MedCom er drivende kraft i udvikling og drift af løsningerne. Der benyttes løbende inddragelse af interessenter i form af brugergruppemøder.

• Separate løsninger

Hotelløsningerne er enkeltstående web-portaler, der er udviklet i separate forløb uden fælles krav til funktionelt eller grafisk design.

• Adgang via webbrowser

WebReq og Henvisningshotellet tilgås i webbrowser i det adgangen gives ved hjælp af Digital signatur. Lægesystemerne er i vid udstrækning integreret med hotellerne således at ydernummer, adgangskode, initialer og patienter stamoplysninger automatisk overføres fra lægesystemet til hotellerne.

• Laboratorieportalen indlejret i Sundhed.dk

Adgangen til Laboratorieportalen sker igennem Sundhed.dk, hvor løsningen er indlejret som frame.

• Hoteller kommunikerer med VANS

Indholdet til hotelløsningerne udveksles med VANS-nettet, idet VANS-leverandørerne har systemer til at hente og sende specifikke beskedtyper, som er relevante for hver af hotelløsningerne.

(29)

Hotelløsninger

• Ingen formaliseret arkitektur for hotelløsninger

MedCom har ingen klare arkitekturprincipper, der ligger til grund for valg af arkitektur og teknologi i forbindelse med nye tiltag. En konsekvens heraf kan blive ustruktureret genbrug, der viderefører uhensigtsmæssigheder fra tidligere systemer.

Det nævnes af flere aktører, at fremtidige løsninger bør konstrueres mere ensartet både med hensyn til brug af standarder, udseende og bagvedliggende it-arkitektur. Dette vil dels gøre vedligeholdelse og eventuel fremtidig sammenkobling enklere, og dels vil det lette brugernes forståelse.

NSI har i samarbejde med parterne formuleret en referencearkitektur for deling af dokumenter og billeder, som dækker hoteller indeholdende beskeder. Denne referencearkitekturen peger på IHE XDS repositories som datalagre.

• Manglende koordinering fører til spildt arbejde

I dag indgår Laboratorieportalen som frame i Sundhed.dk. I følgende eksisterende planer skal portalen integreres fuldt i Sundhed.dk som del af arbejdet med den kommende Sundhedsjournal. Dette er et eksempel på aktiviteter, der kunne koordineres bedre for at undgå dobbeltarbejde og spild ved gentaget integration og genudvikling.

• Hotelløsninger virker ikke i alle browsere

Hotelløsningerne WebReq og Henvisningshotellet er blevet kritiseret for kun at virke fejlfrit i bestemte internet browsere;

eksempelvis Internet Explorer 7 og 8. NSI udtrykker, at en kommende national referencearkitektur for webapplikationer bør adressere teknologivalg og henvise til nationale standarder for valg af platform.

(30)

Overblik over dataløsninger

Anvendelse og datakilder Koblinger til netværk og andre systemer

WebReq • Praktiserende læger indtaster. Systemet giver overblik over hvilke ydelser, der udbydes hvor. Data indtastes normalt direkte i WebReq.

• Systemet videresender rekvisitioner i MedCom standarden Req01 som enten EDIFACT eller EDIXML. Desuden får lægen direkte svar (RPT01) via VANS.

• Data kan tilgås i webløsning af praksislæger og laboratorier via dybt link i eget system (fx lægesystem) til en specifik patients oplysninger.

• Forbindelsen sker via det åbne internet og adgangen begrænses ved hjælp af Digital Signatur.

• Rekvisitioner afsendes fra WebReq via opkobling til VANS-nettet.

• WebReq udstiller desuden et antal web services via SDN, som kan benyttes af lægesystemer.

• WebReq indeholder et link til Laboratorieportalen.

RefHost/

RefParc

• Lægerne sender data fra egne lægesystemer ud i VANS-nettet. Fra VANS-netværket fremsøges relevant data til RefHost med en udtræksserver hos VANS-leverandøren.

• Læger kan desuden indtaste henvisninger direkte på RefHost hjemmesiden.

• Systemet modtager MedCom standarderne: Ref01 og Ref06

• Praksislæger sender data via opkobling til VANS-nettet.

• Data kan tilgås i webløsning af specialpraksisser – her sker login med Digital Signatur.

E-journal /P-journal

• E-journal-data kommer EPJ systemer fra landets offentlige sygehuse.

• P-journal-data kommer fra lægepraksisser og speciallægepraksisser via DAK-E’s database.

• Data er baseret på SUP standarden.

• Data overføres fra kildesystemer batchmæssigt via SDN en gang i døgnet til E- journals databaser via eksempelvis FTP.

• Data tilgås via Sundhed.dk login sker via NemId (borger) eller Digital Signatur (praksis)

• Sygehusansatte kan tilgå data via SDN fra eget EPJ, der åbner et dybt link til en specifik patients data baseret på CPR, brugernavn og afdeling. Disse data gemmes i log.

Laboratorie- portalen

• Data kommer fra biokemiske og mikrobiologiske laboratorier samt fra PatoBanken, når det gælder patologiske data.

• Data fremsøges ved online forespørgsel til laboratorier, som udstiller en webservice til formålet. Data er distribueret i hele landet.

• Indgående data er baseret på: RPT01, DGWS og KKA.

• Udgående data er baseret på: RPT01, XRPT05 og DGWS.

• Data kan webløsning indlejret på Sundhed.dk

• Løsningen kan også tilgås via link fra WebReq.

• Patientsøgning sker ved indtastning af CPR.

• Data hentes fra kildesystemer via SDN vha. eksempelvis FTP.

Denne side giver et overblik over de løsninger, som MedCom i dag udbyder, idet der fokuseres på datakilder og relationer til

øvrige løsninger og netværk.

(31)

Scenarieskitser indeholder skitser til scenarier baseret på den gennemførte kortlægning, og de tager udgangspunkt i fire

nøglespørgsmål for fremtidige udvikling af MedCom

(32)

af scenarier

I forbindelse med interviewrunden er det indsamlet følgende observationer, der går på tværs af MedCom’s arbejde med standarder, løsninger og netværk.

 MedCom’s rolle i sektoren er uklar – særligt set i lyset af de seneste års justering af organiseringen i sektoren MedCom har både organisatoriske og tekniske relationer til en lang række aktører i sundhedssektoren. Disse relationer varetages generelt af de berørte MedCom-projekter og ikke på baggrund nogen formaliseret strategi. Dette kan bidrage til en opfattelse af uklarhed omkring MedCom’s rolle i sektoren. Dette leder til manglende strategisk forankring af

MedCom’s arbejde hos centrale aktører i sektoren.

 Udbredelse af løsninger og standarder er en udfordring

MedCom høster stor anerkendelse for arbejdet med at udbrede standarder og løsninger herunder både nye og

ændringer. Der hersker en opfattelse i sektoren af, at der går for lang tid fra en idéstadiet til færdig udrulning, når et nyt fagområde skal digitaliseres, eller der skal ændres ved eksisterende standarder. Der peges samtidig på, at MedCom ikke kan takle udfordringerne alene i forhold til at drive udbredelsen. Dette skyldes at deres styringsmæssige værktøjskasse i forhold til at sikre, at parterne og leverandører i sektoren implementerer nye løsninger er relativt begrænset.

 Øget krav om varetagelse af driftsopgaver

MedCom er i udgangspunktet en projektorganisation og det opleves af de fleste parter, at det også er her MedCom har

sit primære fokus. Der er dog i højere og højere grad også driftsopgaver knyttet til de løsninger og standarder som

MedCom frembringer, og disse bør prioriteres højere enten inden for eller uden for MedCom’s organisation.

(33)

af scenarier (fortsat)

I forbindelse med interviewrunden er det indsamlet følgende observationer, der går på tværs af MedCom’s arbejde med standarder, løsninger og netværk.

 Behov for hurtigere og mere stabil kommunikation

Flere aktører peger på, at den største udfordring for VANS-nettet i dag handler om svingende kommunikationshastighed og manglende stabilitet. Der er behov for hurtig og sikker transport af information, hvor beskeder ikke bliver væk, og hvor der er bedre muligheder for fejlfinding.

 Flere tekniske integrationer

Der anvendes i dag en flerhed af tekniske integrationsmønstre på tværs af sektoren (fx FTP, SFTP, MQ, WS). Det er uklart om dette er et selvstændigt problem, eller om det i virkeligheden handler om kommunikationsproblemer i transporten af beskeder.

 Behov for internationale standarder og større ensartethed

Der er bred enighed om at kommunikationen i sektoren skal standardiseres yderligere igennem valg af internationale standarder. Dette skal blandt andet sikre tværgående datamæssig interoperabilitet bredt mellem systemer i sektoren.

Specifikt i forhold til MedCom’s arbejde skal dette understøtte implementering af en fælles datamodel på tværs af MedCom-standarder.

 Behov for nye kommunikationsmønstre

Der udtrykkes fra flere sider ønske om understøttelse af mere komplekse kommunikationsmønstre end det som understøttes af VANS (ikke ’bare’ en-til-en beskeder). Henvisningshotellet og WebReq er eksempler på, at man har dækket nogle behov for at kommunikere til flere modtagere på en gang.

 Uklare rolledeling giver overlappende centrale løsninger

I de senere år har aktører i sektoren udarbejder centrale løsninger, som på en række punkter overlapper mht. hvilke

opgaver, de skal løse. Der er behov for at sikre større sammenhæng og mindske overlap imellem centrale løsninger (fx

flere laboratoriesvar-løsninger, journal-løsninger).

(34)

centrale scenariespørgsmål

Med udgangspunkt i den gennemført kortlægning herunder de identificerede centrale udfordringer jf.

forrige side, er nedenstående fire centrale scenariespørgsmål for fremtidssikring af MedCom’s kommunikationskomponenter formuleret.

Spørgsmål 1 Spørgsmål 2 Spørgsmål 3 Spørgsmål 4

Hvilke teknologiske mønstre skal udgøre fundamentet for transport af data mellem parterne i sektoren?

Hvilke standarder skal anvendes som

udgangspunkt for kommunikationen i sektoren?

Hvilke opgaver skal MedCom løse?

Hvordan sikres nødvendig synkroniseret udvikling af kommunikationen i

sektoren?

På de følgende sider besvares hvert spørgsmål ud fra to forskellige scenarieperspektiver. Det ene perspektiv handler om optimering af de nuværende løsninger og strukturer, hvor det andet perspektiv beskriver en mere grundlæggende

forandring.

Der er naturligvis også (mindst) endnu et perspektiv, nemlig et perspektiv med fokus på videreførelse af den nuværende situation. Deloitte har dog valgt ikke at beskrive dette basisscenarie, idet det er vurderingen, at det ikke vil være realistisk eller hensigtsmæssigt at foretage en sådan lineær fremskrivning af den nuværende situation.

Det er oplagt at besvarelserne til ét spørgsmål kan påvirke hvilke valg der er relevante ved besvarelse af de øvrige

spørgsmål. Dette afspejler kompleksiteten af aktuelle situation i sundhedssektoren, hvor MedCom har mange

forskelligartede roller og står som ejer af både standarder, systemer og et datanetværk.

(35)

transport af data mellem parterne i sektoren?

Optimeringsscenariet tager udgangspunkt i det eksisterende billede, og VANS-nettet er forsat centralt forhold til store dele af kommunikationen. Forandringsscenariet søger at løse en række nuværende udfordringer samlet ved at gennemføre et teknologisk løft af kommunikationen; herunder en gradvis overgang til brug af SDN og NSP til transport af sundhedsdata.

Nuværende situation og centrale udfordringer Optimering Forandring

• Kommunikationen i sektoren er i overvejende grad baseret på en-til-en beskedkommunikation med udgangspunkt i EDI-teknologi (VANS).

• Der er et stigende behov for mange-til-mange kommunikation

• Hastighed og muligheder for fejlsøgning opleves som problematiske.

• Webhoteller opsamler data, på en række områder hvor en-til-en kommunikation ikke opfylder forretningsbehov.

• Begrænset konkurrenceudsættelse af VANS-nettet og anvendelse af proprietære standarder.

• VANS fastholdes som grundlæggende teknologi til kommunikation i sektoren.

• Der gennemføres en række optimeringsprojekter med fokus på optimering af sende/hente-intervaller på tværs af parterne.

• Ud fra fælles arkitekturprincipper etableres der hotelløsninger for de kommunikationsstrømme, som umiddelbart ikke kan understøttes med en-til-en beskeder.

• Den eksisterende VANS-kommunikation flyttes til Den Nationale Serviceplatform (NSP). NSP’en udvides i den forbindelse ift. at kunne håndtere asynkron en-til-en kommunikation.

• Der defineres webservice og XML-snitflader for alle relevante MedCom-standarder. Eksisterende MedCom- standarder konverteres.

• Datafangst til eksisterende hotelløsninger tilrettes til den ændrede kommunikationsform

Fordele • Da dette valg tager afsæt i den nuværende teknologiske

løsning, vil det være der være få krav til nyudvikling.

• Leverandørerne af nuværende systemer (fx EPJ og EOJ) kender snitfladerne og vant til gradvis udbygning med nye fagområder.

• Man bevarer de eksisterende MedCom-standarder og undgår dermed re-implementation.

• Adgang til at benytte flere leverandører og

internationale standardløsninger og åbne standarder vil give mulighed for økonomiske besparelser.

• Overgang til SDN og NSP vil gøre det lettere at indføre dækkende end-to-end SLA’er.

• Nye centrale dataløsninger vil kunne bygges direkte ind i løsningen vha. SDN og NSP, dette vil gøre det lettere at strømline datafangst og løsningsarkitektur.

• Der kan kommunikeres bredere og til flere modtagere end med den nuværende beskedkommunikation.

Ulemper • Der vil forsat ikke være et samlet forpligtende SLA-

apparat, der dækker hele kommunikationen fra afsender til modtager.

• Fortsat brug af EDIFACT som transport standard vil begrænse de mulige fordele ved skift til internationale indholdsstandarder (fx HL7).

• Webhoteller og tilsvarende centrale opsamlingssteder vil forsat skulle kompensere for manglende muligheder ved den besked-baserede kommunikation, som VANS repræsenterer.

• I forhold til drift af VANS-nettet vil der fortsat kun være to aktører, så konkurrencen er begrænset.

• Behov for udvikling af nye systemer på NSP’en til håndtering af den dataudveksling, der i dag køres på VANS.

• Det vil kræve store ressourcer at gennemføre konvertering af MedCom’s eksisterende standarder.

(36)

kommunikationen i sektoren?

I optimeringsscenariet foretages en pragmatisk og langstrakt overgang til en valgt international standard, idet al nyudvikling baseres på en valgt standard med tilhørende datamodel. I forandringsscenariet foretages en hurtigere overgang til den valgte internationale standard og der foretages samtidig et oprydnings- og konverteringsarbejde i forhold til MedCom’s portefølje af eksisterende standarder.

• MedCom har over tid etableret en stor portefølje af standarder, som i dag udgør en central komponent i den tværsektorielle kommunikation i sektoren.

• Der findes ikke en samlet datamodel for porteføljen af standarder, som sikre ensartethed på tværs.

• Standarderne er ikke baseret på aktuelle

internationale standarder (fx HL7 eller IHE). Det er dog MedCom’s vurdering, at en-til-en konvertering til eksempelvis HL7 er mulig i de fleste

sammenhænge.

• MedCom’s standardiseringsfokus har primært været på strukturen af beskeder og ikke i så høj grad på standardisering (kodificering) af de enkelte dataelementer.

• Gradvis overgang til valgte internationale sundhedsfaglige standarder. Der benyttes en lang overgangsperiode.

• Etablering af samlet arkitektur og datamodel på tværs af de faglige områder, MedCom arbejder med.

• Nye standarder etableres på baggrund af valgte internationale standarder, men indpakningen vil benytte EDIFACT (jf. teknologisk mønster) i samme omfang som i dag.

• I forhold til MedCom’s eksisterende portefølje foretages ingen proaktiv konvertering eller opdatering. Nye og gamle standarder vil skulle sameksistere.

• Gradvis overgang til valgte internationale sundhedsfaglige standarder, dog inden for en forholdsvis kort overgangsperiode i forhold til ibrugtagning af valgte standard.

• Gennemførelse af oprydnings-

/konverteringsprojekter i forhold til MedCom's portefølje af nuværende standarder

• Etablering af samlet arkitektur og datamodel på tværs af de faglige områder MedCom arbejder med

• Der indføres øget kodificering af dataindhold / dataelementer.

• Etablering af central mapning og

konverteringsmotor, som kan levere data i forskellige standarder

Fordele • Fortsat anvendelse af de eksisterende løsninger

og standarder, som virker og understøtter de umiddelbare behov for kommunikation.

• Stor og relativ hurtig internationalisering af datakommunikationen i sektoren, hvilket vil understøtte en åbning af det danske marked for internationale leverandører.

Ulemper • Det kan blive svært at holde momentum i

udbygning af nye standarder, fordi de

eksisterende standarder vil udgøre størstedelen af porteføljen i en længere årrække fremover.

• Der vil være en risiko for, at en relativ hurtig konvertering vil være mindre værdiskabende sammenlignet med en mere pragmatisk case-by- case tilgang.

(37)

• MedCom er startet som en projektorganisation og drives fortsat i dag som sådan.

• MedCom leverer i dag standarder, netværk (SDN) og dataløsninger (fx hotelløsningerne). Endvidere har MedCom en mere uforpligtende supportrolle / koordinerende rolle i forhold til VANS.

• MedCom varetager i dag eller forventes at varetage driftsopgaver på en række områder (fx drift af standarder, SDN, hotelløsninger og journalløsninger).

• Der opleves et stærkt behov for at give driftsopgaverne et organisatorisk løft herunder foretage en

professionalisering.

• MedCom har historisk haft en de facto rolle i forhold til at formulere strategi og rammer – særligt inden for standarder. Med etableringen af NSI og NSI’s arbejde med strategier og standarder vil NSI komme til at varetage en centrale rolle ift. strategi og rammer på området.

• Tydelig adskillelse af driftsopgaver og projektopgaver internt i MedCom herunder både organisatorisk og økonomisk / styringsmæssigt . Drift omfatter både traditionel it-drift men også drift / forvaltning af standarder

• En professionalisering af håndteringen af driftsopgaverne.

• Sikring af koordinering af både driftsaktiviteter og rammer/strategi på tværs af sektoren; herunder med NSI og Sundhed.dk.

• Aktivt indspil i forhold til sundheds-it strategiarbejdet på nationalt plan med udgangspunkt i den omfattende praktiske erfaring og faglige indsigt.

• MedCom fokuserer sine aktiviteter omkring projekt og udviklingsopgaver. Særligt for standardområdet fastholdes og styrkes arbejdet omkring drift (fx ændringsstyring, certificering og opdatering i forhold til nye versioner af valgte internationale standarder).

• Etablering af særskilt driftsorganisation, som varetager centrale tekniske driftsopgaver i sundhedssektoren herunder Sundhedsdatanettet, NSP og centrale dataløsninger.

• Sikring af koordinering af både driftsaktiviteter og rammer/strategi på tværs af sektoren; herunder med NSI og Sundhed.dk.

.

Fordele • En optimering inden for de eksisterende organisatoriske

rammer og strukturer vil repræsentere en mindre ændring og vil samlet udgøre den mindste risiko.

• En organisatorisk ’tæthed’ mellem udvikling / projekter og driftsopgaver vil understøtte sammenhæng og vidensoverførsel inden for MedCom's ydelsesområder.

• En særskilt driftsorganisation vil i høj grad understøtte et øget fokus på driftsopgaverne, som i dag ikke opleves som tilstrækkeligt højt prioriterede og professionelle.

Ulemper • Der er risiko for, at en fortsat spredt organisering af

centrale driftsopgaver på tværs i sektoren ikke vil kunne give det nødvendige fokus og kvalitet

• Risiko for at viden og sammenhæng mellem en særskilt driftsorganisation og fx MedCom som

projektorganisation forsvinder eller bliver for svag.

• Der skal etableres et nyt styringsmæssigt og budgetmæssigt setup, som sikrer de nødvendige rammer for en ny særskilt driftsorganisation, hvilket kan vise sig vanskeligt.

I optimeringsscenariet bibeholder MedCom den nuværende opgaveportefølje, idet der foretages en opdeling af projekt og driftsopgaver kombineret med professionalisering af drift herunder drift/forvaltning af eksisterende standarder. I