Delprojekt 3 i MedCom8

(1)

Teknologisk fremtidssikring af MedCom- kommunikationen

Delprojekt 3 i MedCom8

Deloitte Consulting

23. oktober 2012

(2)

Projekt Teknologisk fremtidssikring af MedCom-kommunikationen

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

overskriften Teknologisk fremtidssikring af MedCom-kommunikationen.

 Fokusset i delprojektet er på de kommunikationselementer, der er en del af MedComs ansvarsområde: Meddelelsesstandarderne, VANS- nettet, SDN, hotellø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.

– Udarbejde et indledende forslag til fremtidssikring af MedComs infrastruktur, der kan tjene som beslutningsgrundlag for, om der skal opstilles en mere konkret plan for en sådan fremtidssikring.

– Etablere en plan for fremtidssikringen, i det omfang MedComs 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.

(3)

- 3 -

Indhold



Dette dokument indeholder afrapportering af kortlægnings- og scenariearbejdet, jf. markering A og B i figuren til højre.



Kortlægningen systematiserer observationer indsamlet gennem interview med en række centrale aktører og interessenter i 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 MedComs standarder, løsninger og netværk

4. Udfordringer i forhold til fremtidssikring af MedComs 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 punkt 2, 3 og 4 i denne oversigt.



På baggrund af kortlægningsarbejdet etableres et antal scenarier for MedComs fremtidige virke.



Jævnfør opdraget på forrige side var den oprindelige plan, at projektet skulle afsluttes ved opstilling af et egentligt roadmap.

Det er i stedet besluttet at strække projektet tidsmæssigt frem til MedComs styregruppemøde 15. november 2012 og i denne periode udbygge scenarierne med fokus på at understøtte styregruppemødet.

3. Arkitektur og teknologi 2. Organisation

og styring 1. Ændrede behov

og krav fra sektoren

4. Udfordringer i forhold til fremtidssikring

5. Scenarier

6. MedCom strategiseminar (styregruppemøde 15. november 2012)

A. Kortlægning

B. Scenarier

(4)

A. Kortlægning

Kortlægningen indeholder dokumentationen af den gennemførte

kortlægning af MedComs kommunikationselementer

(5)

- 5 -

MedComs kommunikationskomponenter i den danske sundhedssektor

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 primært kontrolleres af leverandørerne KMD og Evenex. MedCom står for en række standarder, der benyttes i kommunikationen over de to netværk. MedCom har desuden været drivkraft i en række opsamlingssteder af data til specifikke formål, herunder E-Journal, P-Journal, WebReq og RefHost/RefParc.

Kommune Kommune Region

Region Privat

praksis Privat praksis

Sundhedsdatanettet

Sund-

hed.dk Borger

Borger Borger

VANS

Region Region

Statslige aktører

(SST og LMS)

Kommune Privat

praksis Region

Hoved- staden

WebReq RefHost/

RefParc

E-Journal og P-Journal

Borger

(6)

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 og modtage beskeder sendt til egen postkasse.

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

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

 Hver bruger er forbundet til én leverandør, og de to leverandører 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å 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

(7)

- 7 -

VANS

Organisation og styring

• VANS 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 applikationsleverandør (for eksempel har leverandørerne af praksissystemer aftaler med en af de to VANS-leverandører).

• Alle aktører i sundhedssektoren er koblet til VANS

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 en basal test/certificering af de to leverandører i forhold til den grundlæggende funktionalitet på deres netværk. Testen inkluderer kontrol af leverandørernes mapningstabeller og kontrol af modtagelse og afsendelse af VANSEnvelope (testskemaet er senest opdateret i april 2011).

• MedCom specificerer beskeder

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

• MedCom medvirker i forbindelse med fejlsøgning

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

Arkitektur og teknologi

• VANS er et asynkront en til en-meddelelsessystem

VANS er et meddelelsesbaseret system, hvor kommunikation foregår ved asynkron transport af standardiserede EDIFACT- og XML-beskeder, der sendes mellem netværkets aftagere (en til en) via en postkasselignende funktionalitet. VANS tilbyder mulighed for at foretage prioriterede forsendelser.

• VANS-kommunikation foregår 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å kommerciel 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 brugerens 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.

(8)

VANS

• Information om modtagerlokation findes i selve beskeden

På VANS foregår routingen af beskeden til modtageren efter opslag af routinginformation (fx modtagerlokation) i beskedens header. Fordi routinginformationen er pakket ind i selve beskeden og ikke findes som metadata, skal knudepunkterne i netværket udpakke og læse i beskederne, inden de kan videresendes.

• 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 tilbyder ikke lagring eller registrering af data eller metadata. Til udvalgte formål er der dog opstillet udtræksservere hos VANS-leverandørerne, der 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 især udfordringer i sammenhænge, hvor der er krav om hurtig overførsel af data. Dette behov findes eksempelvis i forbindelse med akutte henvisninger. I sådanne sammenhænge kan VANS ofte have svært ved at leve op til krav om høj hastighed. I forlængelse 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 behandlingsmønstre fordrer både øget kommunikationshastighed og fælles data

Ændringer i behandlingsmønstre, for eksempel på grund af mere samarbejde mellem primær og sekundær sektor samt mere 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 mellem parterne. Det foreslås fra nogle aktører, at der i højere grad satses på central lagring af data.

(9)

- 9 -

VANS

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

Det er desuden problematisk, at der ikke findes en 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æge-, EOJ- eller EPJ-systemer) til en af de to VANS-leverandører.

Brugere af VANS beretter om, at beskeder i nogle tilfælde slet ikke ankommer. Der peges på, at der er behov for nogen, der 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 af VANS. Det gælder afsendelse af kvitteringer, men også håndteringen i brugersystemerne af negative kvitteringer. Der er et stort ønske om fuld udbredelse af modtagelses- kvitteringer, 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å MedComs dialekter af EDIFACT- standarder, der ikke understøttes af kommercielle værktøjer, hvilket resulterer i et meget begrænset antal mulige

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

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

• Manglende centrale adresseopslag fører til fejlforsendelse

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

leverandørerne af eksempelvis læge- og EOJ-systemer vedligeholder egne lister over gyldige lokationsnumre (brugere) på VANS. På disse lister registreres det også, hvilke beskeder hver lokation er i stand til at modtage. Det giver tilbagevendende problemer med fejlforsendelser og tidsspilde i VANS-trafikken, når parterne har forskellige lokationsoplysninger. SOR er valgt som den fremadrettede adressebog grundet datakvaliteten i SOR, og idet der ikke udstilles en onlinesnitflade, der kan anvendes til direkte system til system-opslag/integration, anvendes SOR kun meget begrænset i denne sammenhæng.

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

Nogle parter foreslår, at der 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.

(10)

VANS

• Mulighed for at abonnere på hændelser

Enkelte parter nævner det som et ønske til fremtidig funktionalitet, at man kan abonnere på hændelser, for eksempel den hændelse, at der ankommer nye data om et givet CPR-nummer. Det står i kontrast til den nuværende situation på VANS, hvor en besked sendes til en bestemt modtager på nettet og derefter ikke findes på nettet. Denne abonnement-ide kan for eksempel kombineres med en ny fælles fordelingsmotor til VANS.

• Ingen reel konkurrenceudsættelse

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

udsættelse og muligvis resultere i mere tilfredsstillende service og lavere priser.

(11)

- 11 -

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

Eksempel på VANS-tilslutning i Region Midtjylland

Som beskrevet på forrige side består det samlede VANS 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.

- 11 -

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

 Region Midtjylland har igangsat en generel reduktion af VANS-

sende/modtage-intervaller til 1 minut. Til en start fokuseres på undersøgelse af gennemløbs- hastigheder for henvisninger til hospitaler fra lægevagt og akutklinikker.

 Figuren viser det store antal potentielle fejlkilder, der opstår i et distribueret net, hvor mange aktører har ansvaret for hver deres del.

 Som følge heraf er der mange

steder, hvor man kan igangsætte

fejlsøgning, hvis beskeder ikke når

frem.

(12)

Eksempel på VANS-tilslutning i Region Hovedstaden

Som nævnt består det samlede VANS af en række sammenkoblede systemer. Eksemplet på denne side viser detaljer i VANS-forbindelsen med udgangspunkt i Region Hovedstadens optegnelser.

Kilde: Region Hovedstadens egen optegnelse

(13)

- 13 -

Sundhedsdatanettet (SDN)

 SDN er opbygget omkring et nationalt knudepunkt, som brugerne er enten direkte tilkoblet eller forbundet til via faste forbindelser/egen MPLS eller VPN.

Knudepunktet er firewallbaseret og router trafik videre mellem parter, der har indgået passende aftaler i aftalesystemet. Aftalesystemet 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 kantrouter, der får en routingtabel 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 kantroutere og ikke behøver at gå gennem samme fysiske knudepunkt.

 SDN medvirker til at dække flere forskellige

kommunikationsbehov i sektoren, herunder E-Journal, Vaccinationsregister, Interregionalt Billedindeks, Sundhed.dk og Nationalt Patientindeks. Derudover er SDN vært for NSP, der aktuelt udbyder Det Fælles Medicinkort som webservice.

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, der sikrer, at der er indgået aftaler mellem de parter, der ønsker at kommunikere over netværket.

Kilde: MedCom

(14)

Sundhedsdatanettet (SDN)

• SDN finansieres af de tilsluttede parter

MedCom er udbyder af SDN og tilbyder det til aktørerne i sundhedsvæsnet 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 efter indgåelse af aftale selv er ansvarlig for at etablere og drive en forbindelse til SDN’s knudepunkt.

• SDN er underlagt MedComs styregruppe

Beslutninger om videreudvikling og nye tiltag på SDN træffes af MedComs styregruppe efter indstilling fra MedCom.

• Aftalesystemet administrerer adgange

SDN er omfattet af det såkaldte aftalesystem, hvor parter kan både anmode om adgang til andre parters netværk – og selv give tilladelse til andres adgang til eget netværk (specifikke servere og porte).

• Den tekniske drift er todelt

Den tekniske drift af SDN er aktuelt delt mellem to leverandører, NETIC og NetDesign. NETIC håndterer DNS og aftalesystemet, og 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 mellem systemer placeret i adskilte netværk, samtidig med at der vil kunne implementeres asynkron beskedkommunikation oven på SDN (fx e-mail).

• Flere tilkoblingsmuligheder

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

• Opstilling af kantrouter

De parter, der kobles op via SDN-MPLS, får opstillet en såkaldt kantrouter, der får en routingtabel opdateret fra centralt hold.

Derved opnås, at trafikken kan gå direkte mellem parternes kantroutere og ikke behøver gå gennem samme fysiske knudepunkt.

(15)

- 15 -

Sundhedsdatanettet (SDN)

• SDN benytter hardwarekryptering

Al trafik, der passerer internt i SDN via faste forbindelser eller SDN-MPLS, er ikke krypteret, hvorimod trafik, der passerer internettet via VPN, krypteres (primært hardwarekryptering). Ansvaret for, at data håndteres sikkert, påhviler brugerne selv frem til SDN-kantrouteren. Generelt anbefales det, at udstillede services bruger SSL, så der sikres end to end-sikkerhed.

• Ansvar for adgange er distribueret

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

(16)

Sundhedsdatanettet (SDN)

• Den initiale oprettelse af aftaler i aftalesystemet bør understøttes bedre organisatorisk

Parternes tilbagemelding er, at aftalesystemet rent teknisk fungerer tilfredsstillende. Imidlertid er der en udfordring i at få alle tilkoblede organisationer til hurtigt at besvare anmodninger om dataadgang gennem aftalesystemet. 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å SDN stige (for eksempel øget anvendelse af video samt overførsel af mange og store billeder). Derfor er der behov for 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 parterne hurtigt kan få hjælp til problemer med SDN. Det foreslås, at supportfunktionen kunne vedligeholde et centralt overbliksbillede over aktuel connectivity på hele nettet for at kunne løse problemer proaktivt.

• Brugere har problemer med egen opsætning

Flere brugere oplever problemer med NAT-konfiguration (Network Adresse Translation) på egne routere i forbindelse med første tilkobling til SDN og ved ændrede centrale konfigurationer.

• Mangelfulde beskrivelser af services, der udbydes via SDN

Aftalesystemet indeholder lister over udstillede services, men kvaliteten af beskrivelsen af den enkelte service afhænger af, at den enkelte serviceudbyder (fx en region) har dokumenteret tilstrækkeligt. Ofte er beskrivelsen af en service så mangelfuld i aftalesystemet, at man kun kan komme i gang med benytte den, hvis man kontakter udbyderen direkte.

(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 mod databærende

standarder, der kan bruges til at overføre mere eller mindre strukturerede data mellem it-systemer i sektoren.

Arbejdet med standardisering omfatter blandt andet følgende:



EDIFACT/EDIXML benyttes ved overførsel af data på VANS.

De nyere standarder findes kun i XML-versioner. Til

forsendelse af binære data benyttes MedBin-formatet, der er en specifik EDIFACT-besked.



Den Dynamiske Blanket (DDB), der 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), der benyttes til udveksling af patientjournaler, i forbindelse med at en borger skifter til en læge, der benytter et andet lægesystem.



Den Gode Webservice (DGWS), der 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 Hotel-løsninger

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 X

Fødselsanmeldelse X X

Børnedatabaseindberetning X

Kommunale attester X X

Kronikerdatasæt X X

Afregning X

Recepter X X

Udveksling af komplet

lægejournal X

Det Fælles Medicinkort X

Inspiration: Dorthe Skou Lassen, MedCom

(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, der vil kunne opdeles i datastandarder og indholdsmæssige standarder.

Netværk (SDN og VANS) Transportstandard (fx EDIFACT, MQ, WS og FTP)

Sundhedsfaglig datastandard (fx EDIFACT/XML, HL7, FNUX og SUP) Sundhedsfaglig indholdsmæssig standard

(nomenklaturer og klassifikationer, fx IDC10 og SNOMED)

Brugersystemer (fx E-Journal, EPJ og EOJ)

SDN/VANSMedCom-standard

(19)

- 19 -

Standardiseringsarbejde i international sammenhæng

Standardiseringsarbejdet i den danske sundhedssektor, herunder MedComs arbejde, har blandt andet været udført med skelen til danske og internationale standardinitiativer af forskellig karakter. Med det formål at give et summarisk overblik sammenstiller denne liste udvalgte af disse initiativer, der dels er refereret i NSI’s referencearkitektur for standarder, dels blev nævnt af aktører i forbindelse med denne kortlægning.

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 som sundheds- professionel for eksempel kan trække data til en samlet visning om en bestemt patient fra mange kilder eller sikre, at flere forskellige systemer viser data om den samme patient samtidigt (synkronisering på personnummer). 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 anvendes i det danske Nationalt Patientindeks-projekt og det kommende nationale billedindeks. XDS 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 den løbende certificerer teknologiprodukter (fx smartphones og måleudstyr), der lever op til organisationens 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 de kropsdele, hvor lidelserne optræder (multiaksial). Sundhedsstyrelsen er ansvarlig for løbende oversættelse og tilpasning af SNOMED til danske forhold (dansk profilering).

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

OIO-XML benyttes som grundlag for EDIXML til dataudveksling i VANSEnvelope via VANS.

(20)

Standarder: rapporten Standarder og referencearkitekturer vedr. sundheds-it området

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

– Nationalt Patientindeks/regionalt billedindeks.

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

– Telemedicin og hjemmemonitorering.

 Rapporten påpeger, at referencearkitekturer bør udpege de strategiske valg i forhold til standarder for definition af asynkron kommunikation samt standarder for transport af asynkron kommunikation. MedComs EDI- og VANS-baserede kommunikation udpeges som de facto-standarden. Samtidig er det

forventningen, at der i forbindelse med arbejdet med ‘T02 Overførelse af

beskeder’ i 2012 vil skulle træffes de nævnte strategiske valg, der sandsynligvis vil række ud over 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)

- 21 -

Standarder

• MedCom skaber konsensus

MedComs 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 mellem interessenterne/parterne inden for det enkelte faglige område, hvilket blandt andet foregår gennem 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 at bruge af standarder

En anden væsentlig del af MedComs 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, der er tekst i en veldefineret struktur. Den grundlæggende EDIFACT-syntaks har sin baggrund inden for e-handels-området.

• Overgang til EDIXML

Siden 2003 har MedCom sideløbende med EDIFACT-beskederne udarbejdet de såkaldte EDIXML-beskeder, der 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å NSP, blandt andet Det Fælles Medicinkort, CPR-opslag, CPR- abonnementsservice og opslag i autorisationsregister.

(22)

Standarder

• Ingen tilbagevendende certificering

MedComs certificering gennemføres som regel kun én 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

MedComs udvælgelse af medlemmer til brugergrupper kritiseres for at være vanebetonet således, at det ofte er de samme aktører/enkeltpersoner, der opnår indflydelse. Regionerne ønsker i højere grad selv at udpege deltagere til forskellige MedCom-grupper.

• Ofte er laveste fællesnævner styrende

Nye standarder bliver ofte et udtryk for laveste fællesnævner især i forhold til struktureringsgrad, fordi brugergrupperne har så forskellige indbyrdes syn på, hvad der skal inddrages i standarderne, og hvilket niveau af strukturering det giver mening at indarbejde 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 MedComs standarder. Dette bidrager til en opfattelse af, at arbejdet starter forfra, hver gang et nyt område inddrages. Der er

tilsyneladende en tendens til, at hvert projekt er meget drevet af enkeltpersoner hos MedCom og ikke nødvendigvis har blik for, hvordan delområder på tværs af MedCom-standarderne tidligere er beskrevet og struktureret.

• Manglende metadata til sikkerhedshåndtering

De nuværende standarder indeholder utilstrækkelige 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 (hvilket nogle steder er tilfældet i dag).

• 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 overgang til eksempelvis HL7 eller IHE bør foregå gradvis, samtidig med at bagudkompatibilitet sikres. HL7 CDA benyttes i dag i mange leverandørsystemer.

(23)

- 23 -

Standarder

• OIO-XML og EDIXML begrænser konkurrencen

Det nævnes, at flere internationale leverandører muligvis vil have lettere ved at byde på opgaver i Danmark, 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 uden for 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 sin indsats i forhold til ændringsstyring og versionsstyring af egne standarder. Der er behov for en professionalisering af området blandt andet for at sikre klar kommunikation omkring ændringer og gældende versioner af standarder, etablering og kommutation af et samlet roadmap for udviklingen af standarder osv.

• 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, for eksempel som resultat af nye politiske beslutninger. Det er en udbredt holdning i sektoren, at der går for lang tid, fra man går i gang med at danne eller ændre standarder, til standarden kan tages i anvendelse på eksempelvis klinikker og hospitaler. Samtidig er der dog en anerkendelse af, at MedCom i den forbindelse kun indgår som én aktør ud af mange (fx kommuner, regioner, staten og leverandører), der alle har et delansvar for hastigheden, hvormed ændringer kan implementeres.

• 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 alternativ udviklingsmodel, der i højere grad er baseret på pilotprojekter med enkelte parter og efterfølgende tvangsudrulning. På den anden side påpeger andre aktører, at netop MedComs tilgang med et stort fokus på konsensus skaber opbakning og engagement i projekterne.

(24)

E-Journal og P-Journal

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

– Cave

– Notater (herunder epikriser) – Procedurer (fx indgreb) – Diagnoser (ICD10) – Medicinoplysninger*

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

 For både E-Journal 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 cave, behandlinger, diagnoser og notater 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, der indeholder klinisk information fra almen praksis og speciallægepraksis. Data i journalsystemerne stilles til rådighed for borgerne selv og for borgerens egen læge samt øvrige praktiserende læger via Sundhed.dk. Sygehusansatte har desuden også adgang til data via SDN.

Dataopsamling

SUP SUP

Kilde: Jens Rahbek Nørgaard, MedCom

(25)

- 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, der 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 systemerne er forankret i Sundhedsjournalens styregruppe.

• Forskelligartede dataleverancer

Det er forskelligt fra region til region hvilke typer data, der stilles til rådighed for E-Journal – fra alle offentlige sygehuse leveres dagligt – som minimum – data om cave, behandlinger, diagnoser og notater for patienter. 1/3 af sygehusene leverer desuden data om laboratoriesvar og medicin.

• 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 er altså ikke fuldt integreret. Data i E-Journal er desuden tilgængelige via SDN fra landet sygehuse via sygehusenes fagsystemer (EPJ/PAS).

• Data overføres dagligt

Patientdata fra EPJ- og PAS-systemer baseret på SUP-specifikationen hentes én gang i døgnet til E-Journals centrale database. Data overføres batchmæssigt med FTP-forsendelser via SDN.

• Logning af adgange

Alle sygehusklinikere og praksislæger som har en patient i behandling har adgang til at se patientens data. Denne adgang logges, hvilket danner baggrund for auditering af anvendelsen og visning i MinLog, hvor patienten kan se hvilke

sundhedsprofessionelle, der har læst/set deres journaloplysninger.

(26)

E-Journal og P-Journal

• Distribuerede datakilder giver deling af dataansvar og uensartet datakvalitet

I E-Journal ligger data i en national database men modtager data fra en række regionale databaser, hvilket fra nogle aktører netop har været et kritikpunkt. Når fødedata til E-Journal er distribueret, bliver ansvaret for opdateringer og kvalitetssikring af dataleverancen også distribueret, og det kan blive svært at garantere en ensartet leverance og 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- og P-Journals visningsdel bliver overflødiggjort i forbindelse med lanceringen af Sundhedsjournalen, der er et tiltag fra Sundhed.dk, som ud over E- og P-Journal-data vil kunne præsentere data fra eLPR, PEM, Laboratorieportalen og Donorregistret. Sundhedsportalen forventes klar i slutningen af 2013. Data til Sundhedsjournalen fremsøges ved hjælp af Nationalt Patientindeks og gøres tilgængelige for sundhedsprofessionelle og borgere i fagsystemer og på Sundhed.dk. I denne sammenhæng indgår NSP i forhold til både 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 der ikke er givet 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)

- 27 -

Hotelløsninger

 Aktuelt findes der:

– Henvisningshotellet (RefHost/RefParc), der benyttes til at oprette henvisninger for patienter til videre undersøgelse og behandling. Figuren viser, hvordan en patient henvises til eksempelvis fysioterapeut.

– WebReq, der benyttes til at bestille prøver fra laboratorier.

– Laboratorieportalen, der 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 webløsninger med det lukkede VANS. På figuren ses et eksempel på, hvordan denne udveksling af data finder sted i

forbindelse med Henvisningshotellet.

– Praksislægen indtaster de relevante oplysninger i eget system eller i

Henvisningshotellets grænseflade. På den baggrund dannes de krævede EDI- meddelelser, fx REF01 eller REF06, der stilles til rådighed i Henvisningshotellet.

– Når patienten henvender 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-Journal og P-Journal, der udelukkende samler og præsenterer data.

Ordet hotelløsning benyttes som samlebetegnelse for en række webbaserede løsninger, som MedCom har fået udviklet til at håndtere bestemte typer oplysninger, der kommunikeres på VANS. 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, der 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 i 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 parterne.

• 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 webportaler, 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, og adgang gives ved hjælp af Digital Signatur. Lægesystemerne er i vid udstrækning integreret med hotellerne således, at ydernummer, adgangskode, initialer og patienters stamoplysninger

automatisk overføres fra lægesystemet til hotellerne.

• Laboratorieportalen indlejret i Sundhed.dk

Adgangen til Laboratorieportalen foregår gennem Sundhed.dk, hvor løsningen er indlejret som frame.

• Hoteller opsamler data på VANS

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

(29)

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

Flere aktører nævner, at fremtidige løsninger bør konstrueres mere ensartet med hensyn til både 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, der dækker hoteller indeholdende beskeder. Denne referencearkitektur peger på IHE XDS-repositories som datalagre.

• Historiske eksempler på parallelt arbejde

I dag indgår både Laboratorieportalen og Laboratoriesvar i Sundhed.dk. Denne tilstedeværelse af løsninger med overlappende funktionsområde indikerer ifølge nogle aktører et behov for bedre koordination mellem organisationerne i sektoren.

• Hotelløsninger virker ikke i alle browsere

Hotelløsningerne WebReq og Henvisningshotellet er blevet kritiseret for kun at virke fejlfrit i bestemte internetbrowsere, fx 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.

• WebReq sender og modtager REQ01-standarden og sender endvidere REQ03-standarden.

• WebReq håndterer desuden XREQ01-standarden ved hjælp af webservice på SDN – både udgående og indgående.

• 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 foregår via det åbne internet, og adgangen begrænses ved hjælp af Digital Signatur.

• Rekvisitioner afsendes fra WebReq via opkobling til VANS.

• WebReq udstiller desuden et antal webservices via SDN, der kan benyttes af lægesystemer.

• WebReq indeholder et link til Laboratorieportalen.

RefHost/

RefParc

• Lægerne sender data fra egne lægesystemer ud i VANS. Fra VANS fremsøges relevante 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, REF02, REF06, REF07, REF08, REF10 og REF12.

• Praksislæger sender data via opkobling til VANS.

• Data kan tilgås i RefHost af specialpraksisser, sygesikringskontorer, hospitalsafdelinger, visitationskontorer og kommuner – her foregår login med Digital Signatur eller med anden form for system til system-adgang.

• Særligt autoriserede administratorer har adgang til statistik og logopslag.

E-Journal/

P-Journal

• E-Journal-data kommer fra PAS- og 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 én gang i døgnet til E-Journals databaser via eksempelvis FTP.

• Data tilgås via Sundhed.dk loginbaseret på 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-nummer, brugernavn og afdeling. Disse data gemmes i log.

Laboratorie- portalen

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

• Data fremsøges ved onlineforespørgsel til laboratorier, der 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 ses i webløsning indlejret på Sundhed.dk.

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

• Patientsøgning foregår ved indtastning af CPR-nummer.

• Data hentes fra kildesystemer via SDN ved hjælp af eksempelvis FTP.

Denne side giver et overblik over de dataløsninger, som MedCom udbyder i dag. Der fokuseres på datakilder og relationer

til øvrige løsninger og netværk.

(31)

- 31 -

B. Scenarieskitser

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

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

(32)

Identificerede centrale udfordringer som udgangspunkt for opstilling af scenarier

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

 MedComs rolle i sektoren er uklar – især 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 af en formaliseret strategi. Det kan bidrage til en opfattelse af uklarhed omkring MedComs rolle i sektoren. Dette leder til manglende strategisk forankring af MedComs arbejde hos centrale aktører i sektoren.

 Udbredelse af standarder og løsninger er en udfordring

MedCom høster stor anerkendelse for arbejdet med at udbrede standarder og løsninger, herunder både nye standarder og løsninger og ændringer. Der hersker en opfattelse i sektoren af, at der går for lang tid fra idestadie til færdig udrulning, når et nyt fagområde skal digitaliseres, eller når der skal ændres ved eksisterende standarder. Der peges samtidig på, at MedCom ikke kan takle udfordringerne alene i forhold til at drive udbredelsen. Det skyldes, at MedComs styrings-

mæssige værktøjskasse er begrænset i forhold til at sikre, at parterne og leverandørerne i sektoren implementerer nye løsninger.

 Øget krav om varetagelse af driftsopgaver

MedCom er som udgangspunkt en projektorganisation, og de fleste parter oplever, 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 MedComs organisation.

 Behov for hurtigere og mere stabil kommunikation

Flere aktører peger på, at den største udfordring for VANS 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 mulighed for fejlfinding.

(33)

- 33 -

Identificerede centrale udfordringer som udgangspunkt for opstilling af scenarier

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

 Flere tekniske integrationer

Der anvendes i dag en flerhed af tekniske integrationsmønstre på tværs af sektoren (fx FTP, SFTP, MQ og 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 gennem valg af internationale standarder. Dette skal blandt andet sikre tværgående datamæssig interoperabilitet bredt mellem systemer i sektoren.

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

 Nye kommunikationsmønstre stiller øgede krav

Der udtrykkes fra flere sider ønske om understøttelse af mere komplekse kommunikationsmønstre end det, der

understøttes af VANS (ikke bare en til en-beskeder). Henvisningshotellet og WebReq er eksempler på, at MedCom har medvirket til at dække nogle behov for at kommunikere til flere modtagere på én gang.

 Uklar rolledeling giver overlappende centrale løsninger

I de senere år har aktører i sektoren udarbejdet centrale løsninger, der på en række punkter overlapper med hensyn til,

hvilke opgaver de skal løse. Der er behov for at sikre større sammenhæng og mindske overlap mellem centrale løsninger

(fx flere laboratoriesvarløsninger og journalløsninger).

(34)

Fremtidssikring af MedComs kommunikation med udgangspunkt i fire centrale spørgsmål

Med udgangspunkt i den gennemførte kortlægning, herunder de identificerede centrale udfordringer jævnfør forrige side, er nedenstående fire centrale scenariespørgsmål for fremtidssikring af MedComs 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, og det andet perspektiv beskriver en mere grundlæggende forandring.

Optimeringstiltag og forandringstiltag kan kobles på tværs af de fire spørgsmål. Men det er oplagt, at besvarelserne af ét spørgsmål kan påvirke, hvilke valg der er relevante ved besvarelse af de øvrige spørgsmål. Dette afspejler kompleksiteten af den aktuelle situation i sundhedssektoren, hvor MedCom har mange forskelligartede roller og står som ejer af både standarder og systemer og et datanetværk.

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.

(35)

- 35 -

transport af data mellem parterne i sektoren?

Optimeringsscenariet tager udgangspunkt i det eksisterende billede, og VANS er fortsat 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 mulighed for fejlsøgning opleves som problematisk.

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

• Begrænset konkurrenceudsættelse af VANS 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.

• Der gennemføres projekter, der styrker og udbreder lokationsopslag baseret på centrale data, fx ved udbygning af SOR til at matche sektorens samlede behov. Dette kan ske igennem en orientering af SOR mod internationale standarder.

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

• Den eksisterende VANS-kommunikation flyttes til NSP. I den forbindelse udvides NSP’en i forhold til at kunne håndtere asynkron en til en-kommunikation.

• Alle fremtidige kommunikationstiltag bygges omkring NSP og Nationalt Patientindeks (NPI).

• 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 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 reimplementation.

• VANS-leverandørerne tilbyder i dag mulighed for at gensende beskeder efter behov.

• Adgang til at benytte flere leverandører og

internationale standardløsninger og åbne standarder.

• 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 ved hjælp af SDN og NSP/NPI. Dette vil gøre det lettere at strømline datafangst og en løsnings- arkitektur i tråd med den af NSI valgte arkitektur på sundhedsområdet.

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

Ulemper • Der vil fortsat ikke være et samlet forpligtende SLA-apparat,

der dækker hele kommunikationen fra afsender til modtager.

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

• Webhoteller og tilsvarende centrale opsamlingssteder vil fortsat skulle kompensere for manglende muligheder ved den beskedbaserede kommunikation, som VANS repræsenterer.

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

• Behov for væsentlig nyudvikling af systemer på NSP og NPI til håndtering af den dataudveksling, der i dag køres på VANS.

• Det vil kræve omfattende ressourcer at gennemføre konvertering af MedComs eksisterende standarder.

• Der findes i dag begrænset mulighed for support ved brug af SDN. En udvidet supportorganisation skal etableres for at understøtte intensiveret brug af SDN.

• Der findes ikke registrering af, hvilket indhold der sendes over SDN. Hvis noget skal gensendes, er det op til parterne at koordinere.

(36)

kommunikationen i sektoren?

I optimeringsscenariet foretages en pragmatisk og langstrakt overgang til en valgt international standard, og 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 MedComs portefølje af eksisterende standarder.

Nuværende situation og centrale udfordringer Optimering Forandring

• MedCom har over tid etableret en stor portefølje af standarder, der 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, der sikrer ensartethed på tværs.

• Standarderne er ikke baseret på aktuelle

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

sammenhænge.

• MedComs 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 MedComs 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-/konverterings- projekter i forhold til MedComs 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 konverterings- motor, der kan levere data i forskellige standarder.

Fordele • Fortsat anvendelse af de eksisterende løsninger

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

• Omfattende og relativt 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

udbygningen 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 risiko for, at en relativt hurtig konvertering vil være mindre værdiskabende sammenlignet med en mere pragmatisk case by case-tilgang.