Sammenhængende it på Sundhedsområdet

Devoteam Consulting A/S T u b o r g P a r k v e j 1 0 D K - 2 9 0 0 H e l l e r u p C o p e n h a g e n, D e n m a r k T e l + 4 5 3 9 4 5 0 7 0 0 F a x + 4 5 3 9 4 5 0 7 7 7 E - m a i l i n f o @ d e v o t e a m. d k Sammenhængende it på Sundhedsområdet Relation til EPJ udviklingen 4. januar 2007

Devoteam Consulting A/S Dette dokument er udarbejdet for Devoteam Consulting A/S. Devoteam Consulting A/S har ret til at kopiere og distribuere dette dokument. Enhver anden kopiering og distribution må kun finde sted efter aftale parterne imellem. Enhver kopi skal være forsynet med rapportens titel, dato og denne notits.

Indholdsfortegnelse 1. Indledning...2 2. Ledelsessammenfatning...3 2.1. Baggrund... 3 2.2. Hovedanbefalinger... 5 2.2.1. A: Etablering af fælles infrastruktur, sikkerhedsløsning og et antal fælles services... 5 2.2.2. B: Anvendelse af fælles EPJ Software platform komponenter... 7 2.2.3. C: Overgang til flere fælles EPJ er... 9 3. Udgangspunkt - overordnet set...10 3.1. Generelt... 10 3.2. Behov for mere sammenhængende it-understøttelse... 11 3.3. Generel forståelse for trinvis udvikling på EPJ området... 14 3.4. Et antal kørende projekter er første skridt... 15 3.4.1. Receptserver projektet... 16 3.4.2. Ordinationsservice... 17 3.4.3. Integration af hjemmesygeplejens EOJ system... 17 3.4.4. SOSI projektet... 18 3.4.5. Andre projekter... 18 3.5. Implementeringsovervejelser (ref. kapitel 6)... 19 4. Initiativ A: National on-line infrastruktur...20 4.1. Etablering af on-line infrastruktur... 20 4.2. Første trin 2007... 21 4.3. Næste trin - 2008 og frem... 22 5. Initiativ B: Fælles EPJ software platform komponenter...25 5.1. Regional EPJ infrastruktur skal etableres... 26 5.2. Første trin - "Smal" EPJ platform (gateway) - 2007... 29 5.3. Næste trin - 2008 og frem... 29 5.3.1. Der skal defineres fælles udvekslingssemantikker... 30 6. Initiativ C: Overgang til et antal fælles EPJ-er...34 6.1. Første trin (til implementering i 2007/8)... 35 6.2. Følgende trin 2008 og frem... 35 Bilag 1. Open Source strategi er en attraktiv mulighed...37 Bilag 2. Ordliste...39 38000 v1 1 / 4 3

1. Indledning Dette notat er udarbejdet af Devoteam Consulting. Notatet skitserer forslag til konkrete udviklingstrin på EPJ området, som Devoteam Consulting finder relevante og nødvendige at forholde sig til i relation til det nationale initiativ omkring Sammenhængende it på sundhedsområdet. 1 Formålet er at perspektivere og operationalisere mulige trin for EPJ udviklingen i regionerne. Dette gøres på baggrund af tilbagemeldinger og erfaring fra konkrete projekter og fra regionerne. Målet er, at notatet skal være en inspiration for regionerne, således at deres egen EPJ udvikling kan afstemmes med de anbefalede fælles tiltag - uden at det nødvendiggør at igangværende EPJ projekter stoppes. I kapitel 6 i analyserapporterne 1 er dokumenteret et antal implementeringsovervejelser mht. den tekniske implementering. Det er i vid udstrækning disse overvejelser, kombineret med den konkrete dialog med projekter og parter, som ligger til grund for de supplerende anbefalinger i dette notat. Notatet er teknisk af natur, men det er tilstræbt at gøre beskrivelsen så tilgængelig som muligt. Der er således formuleret en kort ledelsessammenfatning og der er i flere af de indledende afsnit fokuseret på gevinster og fordele ved de beskrevne initiativer og udviklingstrin. Til støtte er der i bilag 2 udarbejdet en ordliste med en kort forklaring af de termer og forkortelser, der anvendes i notatet. 1 "Sammenhængende it på sundhedsområdet - Oplæg til nationalt initiativ, Analyserapport - arkitektur v. 3". Udarbejdet af Devoteam Consulting for Indenrigs- og Sundhedsministeriet i foråret 2006 38000 v1 2 / 4 3

2. Ledelsessammenfatning 2.1. Baggrund Regionernes nuværende EPJ projekter har det primære formål at give klinikerne en god it-understøttelse i deres arbejde med patienterne. Dette involverer mange forskellige it-systemer, såvel nye som eksisterende. Derfor skal der lægges en stor indsats i teknisk integration af mange forskellige systemer, således at EPJ løsningen for klinikeren fremtræder så integreret og sammenhængende som teknisk muligt. Kommunikation med andre aktørers it-systemer er hidtil primært blevet varetaget af den meddelelsesbaserede, asynkrone kommunikation baseret på MedCom standarderne, og dette har tilfredsstillet behovet i de tilfælde, hvor der er tale om en bestilling eller et "overdragelsesdokument", hvor én aktør enten bestiller en ydelse hos, eller overdrager en behandling til, en anden, på forhånd udvalgt aktør. I de senere år er dette kommunikationsparadigme blevet suppleret med et antal projekter, hvor der stilles krav om on-line opslag i, eller opdatering af, fælles registre og services (krav om at der etableres en sikker og hurtig system-system integration, klinikeren kan ikke vente på at de ønskede informationer først fremsendes efter den aktuelle kliniske proces er afsluttet og det samlede beslutningsgrundlag derfor først er til rådighed på et senere tidspunkt). Dette kommunikationsmønster betegnes som et synkront kommunikationsmønster. Gevinster ved synkront mønster og "on-line" integration: Hurtigere og lettere adgang til kritiske data på tværs af aktører, væsentlige besparelser i dobbeltregistrering, manuel indhentning af information på papir Øget datakvalitet, muligt at reducere redundante data. Flere aktører får adgang til de samme data Understøtter tværgående samarbejde og workflow Den historisk betingede udvikling af mange forskellige systemer, det stigende behov for integration mellem disse systemer og kombinationen af det asynkrone og synkrone kommunikationsmønster, har medført en integrationsinfrastruktur, som er meget kompleks og dyr at videreudvikle og vedligeholde. Uden at gå i de enkelte detaljer, illustrerer Figur 1, hvor kompleks strukturen er. 38000 v1 3 / 4 3

EPJ system Region 1 M1 M2 M3 M4 I1 I2 I3 EPJ system Region 2 M1 M2 M3 M4 I1 I2 I3 EPJ system Region 3 M1 M2 M3 M4 I1 I2 I3 EPJ system Region 4 Mange forskellige EPJ systemer, er, M1 M2 M3 M4 integrationer og platforme I1 I2 I3 EPJ system Region 5 M1 M2 M3 M4 I1 I2 I3 Meddelelsesbaseret udveksling af data giver ikke mulighed for on-line adgang til data og services Mangler Sikkerheds service Overvågning Katalog MedCom VANS netværk Baseret på Internettet. Tilgængelighed og kapacitet er ikke tilstrækkelig. Sikker on-line drift kræver dedikeret bredbåndsnet Sundhedsdatanettet Praksis Praksis systemer Praksis 11forsk. systemer systemer systemer EOJ Praksis systemer Praksis 4 forsk. systemer systemer systemer Apoteks Praksis systemer Praksis 3 forsk. systemer systemer systemer Nye kommunale sundhedscentre Behov Fælles for on-line adgang services: til fælles services og data Fælles service Medicinprofilen Fælles service Receptserver Info services sundhed.dk Internettet Løsninger skal udvikles Figur 1 Nuværende integrations infrastruktur Initiativet omkring "Sammenhængende it på Sundhedsområdet" adresserer som et centralt tema, behovet for en bedre sammenhæng på tværs og dermed en modernisering og harmonisering af den infrastruktur og it-arkitektur, som direkte understøtter dette. Konkret foreslås dette realiseret gennem flg. initiativer: A: National on-line infrastruktur med fælles sikkerhedsløsning og integrationskomponenter, for alle aktører på sundhedsområdet. Etablering af og tilslutning til et antal nationale eller fælles services. B: Harmonisering og standardisering af EPJ platforms elementer, så integration til den nationale infrastruktur og services samt genbrug befordres bedst muligt. C: Bedste praksis udbredelse af EPJ er, baseret på fri konkurrence og veldefinerede snitflader. Yderligere initiativer: Integration af kommunernes sundhedscenter og EOJ løsninger til den nationale infrastruktur og de fælles services samt evt. koordineret anskaffelse og implementering. Integration af lægepraksis systemer til den nationale infrastruktur og de fælles services samt evt. koordineret anskaffelse og implementering. Dette kan illustreres ved Figur 2, som angiver hovedområder og snitflader. 38000 v1 4 / 4 3

Lev. EPJ EPJ delsystem Myndigheds Kommunale infrastrukturer EOJ infrastruktur & platform EPJ infrastruktur & platform Regionale infrastrukturer Læge praksis system National on-line infrastruktur og sikkerhedsløsning Private platforme Nationale services fx PEM, LPR Fælles services fx sundhed.dk SUP Figur 2: Infrastruktur kontekst Dette notat belyser, og uddyber, hvorledes de tre første initiativer influerer på EPJ udviklingen i regionerne og indeholder et antal konkrete anbefalinger til en trinvis udvikling, som tilgodeser såvel den regionale EPJ udvikling som de tværgående nationale tiltag. 2.2. Hovedanbefalinger 2.2.1. A: Etablering af fælles infrastruktur, sikkerhedsløsning og et antal fælles services Devoteam Consulting anbefaler, at der på vegne af alle aktører etableres en fælles arkitektur og infrastruktur ( tekniske rammebetingelser ), som skal leve op til følgende krav: 1. Hurtig online kommunikation, som kan sikre klinikerne korte svartider, når de skal hente, eller aflevere, data udenfor eget system. 2. Fortsat understøttelse af meddelelsesbaseret kommunikation for de anvendelsesmønstre, hvor dette paradigme er tilstrækkeligt. 3. Fælles sikkerhedsløsning på nationalt plan, som beskytter mod utilsigtet anvendelse og videregivelse af fortrolige data. 4. Adgang til opdaterede data og reduceret omfang af redundante data. 5. Klare og veldokumenterede snitflader, jfr. OIOXML standarderne, således at det er lettere at koble aktører fra andre sektorer på de fælles systemer. 6. Teknisk enkel adgang for klinikere til nationale services og fælles services, dvs. mulighed for at integrere fælles services i lokale løsninger. 38000 v1 5 / 4 3

7. De enkelte myndigheder og aktører udbyder fælles, sundhedsrelaterede services, svarende til myndighedernes ansvarsområder eller også konkret som et fælles tiltag, hvor flere aktører går sammen. Det foreslås at etableringen sker i to trin: Trin 1: Vil give klinikere on-line adgang til de eksisterende nationale services (er i dag ikke fuldt tilgængelige for alle aktører) kombineret med en fuld udrulning af SOSI sikkerhedsløsningen. Konkret foreslås følgende hovedindhold af første trin: Nuværende Sundhedsdatanet anvendes som transmissionsnet. Medicinprofil/Medicinkort/Receptserver implementeres som planlagt som national service. Eksisterende kontakt LPR register/drg register implementeres som national service. National sikkerhedsløsning fra SOSI implementeres hos alle aktører. OIOXML standarder skal implementeres i takt med de enkelte projekters behov og afstemning af standarderne skal varetages i et sektorstandardiseringsorgan, således som anbefalet af IT- og Telestyrelsen. Næste trin: Som næste trin anbefaler Devoteam Consulting, at der anskaffes en højhastigheds infrastruktur ("Sundhedsdatanet II") med overvågning, monitorering og logning, således at klinikerne kan garanteres acceptable svartider. Endvidere anskaffes en gateway/integrationsplatform, som indeholder en række standard værktøjer og er og som derved kan udgøre en fælles reference software platform for gateway funktionalitet og SOSI Open Source komponenter. Denne integrationsplatform kan genbruges af flere aktører og bør derfor stilles gratis til rådighed som en fælles infrastruktur komponent. Udover etablering af den forbedrede infrastruktur foreslås det, at følgende nye fælles services vurderes: o Fælles medicinordinationssystem for praktiserende læger. o CAVE server o Stamdata server/indeks server (CPR, CVR, autorisationsregister, mv.) o Laboratorie svar server o Interaktionsdatabase o Epikrise server 38000 v1 6 / 4 3

o Tværfaglig fællesjournal (på tværs af primær og sekundær sektor) o E-Journal (udvalgte dele af sygehus journal) o Det kommende F-LPR register. Videreudbygningen af den nationale infrastruktur består således af to hovedelementer: a) forbedring af selve infrastrukturen, og b) tilføjelse af nye nationale fælles services. 2.2.2. B: Anvendelse af fælles EPJ Software platform komponenter Analyserne indikerer, at der kan opnås ikke uvæsentlige besparelser gennem et samarbejde mellem regionerne om etablering af et fælles sæt EPJ SW-platform komponenter. SOSI projektet er et godt eksempel på, at de samme er genbruges i flere regioner. Den fælles SW-platform er den langsigtede strategi, og de nuværende EPJ løsninger i regionen tilpasses gradvist og der iværksættes en konvergens af de indsatser, som i dag foregår regionalt, således at den langsigtede strategi følges. Hermed kan udviklingsomkostningerne til platform, til EPJ er og til integrationer gradvist reduceres, idet dobbeltudvikling af centrale dele kan undgås. Med denne strategi vil det ikke være nødvendigt at "skrotte" nuværende EPJ løsninger, men derimod løbende tilpasse dem til de fælles komponenter og på sigt erstatte dem. Etableringen af en fælles EPJ SW-platform kan indebære flere gevinster: Klinikerne vil, via den fælles infrastruktur og sikkerhedsløsning, få online adgang til relevante eksterne kilder. Tilpasning til de samme semantiske begreber for så vidt angår informationer, som skal deles med andre ("udvekslings semantik"). Fælles tilgang til standardisering. Der indføres en mere ensartet brug af standarder, som udover IT- og Telestyrelsens anbefalinger og OIOXML retningslinierne også kan omfatte anbefalinger omkring den lokale logiske datamodel, udvekslings semantikken og mapningen mellem fx G-EPJ og HL7. Øget konkurrence på EPJ-er og EPJ-delsystemer. Fælles EPJ SWplatform komponenter åbner mulighed for, at forskellige leverandører kan udvikle og tilbyde software og delløsninger til sygehusene. Besparelser på udvikling af integrationer. Udvikling og vedligeholdelse kan billiggøres betydeligt ved at disse udvikles til den fælles integrationsplatform 38000 v1 7 / 4 3

eller de fælles EPJ SW platform komponenter, idet antallet af forskellige integrationer kan nedbringes markant. En væsentlig indsats og udfordring i regionerne er at etablere en sammenhængende regional EPJ infrastruktur, som på en god og optimal måde kan integrere såvel nye som eksisterende EPJ delsystemer. Også her anbefales en trinvis tilgang: Trin 1: Som det første trin forslår Devoteam en såkaldt Smal EPJ platform, der udelukkende har til formål at sikre at klinikerne kan kommunikere fra eksisterende 2. generations EPJ systemer til nationale services (implementeres i 2007). Dette vil konkret omfatte følgende elementer: Simpel integrations arkitektur, gateway komponent som indeholder snitflader mod de fælles nationale services. SOSI komponentbibliotek anvendes og integreres til den eksisterende sikkerhedsløsning i regionen. Understøttelse af OIOXML snitfladerne op mod de nationale services. Den regionale brugerdatabase kopierer nødvendige brugerinformationer til den nationale SOSI Identity Provider. Evt. øvrige Open Source komponenter. Næste trin: Afhængigt af status og udbredelse af eksisterende 2. generations EPJ bør der planlægges med en udbygning og harmonisering, som adresserer følgende fokusområder: Specifikation af den del af EPJ data, som bør kunne deles med andre aktører ( fælles udvekslingssemantik for EPJ data). Udvikling af "connectorer" til et antal standard EPJ er og systemer på markedet, samt disses tilpasning til connectorerne. Udarbejdelse af nødvendige OIOXML snitflader til nationale og fælles services (sektorstandardisering) Fastlæggelse af anvendelsen af HL7 MIM'er, samt andre standarder som HIMSS og IHE Fastlæggelse af G-EPJ og Sundterm terminologi anvendelsen. 38000 v1 8 / 4 3

2.2.3. C: Overgang til flere fælles EPJ er I takt med harmoniseringen og standardiseringen af EPJ infrastruktur og platforms elementer (især "connectorerne", udvekslingssemantikken og sikkerhedsløsningen) vil det blive lettere for leverandører at anvende den fælles software platform og den fælles infrastruktur. Og det vil blive lettere for nye innovative virksomheder at udvikle nye EPJ er. Dette giver basis for følgende: Konkurrence på EPJ er/delsystemer, hvor alle regioner er kunder. Bedste praksis udvælgelse og genbrug af de opnåede erfaringer Gradvis migrering fra eksisterende EPJ løsninger Integration til platform baseres primært på internationale standarder Det er vigtigt, at innovationen og konkurrencen på området støttes bedst muligt, hvilket bl.a. kan ske via rammeudbud, konkurrenceudbud mv. Trin 1: Det første trin anbefales kun at omfatte den tilpasning af de relevante eksisterende brugerer, som giver brugeren/et adgang til de nationale services og den fælles sikkerhedsløsning. I praksis skal regionerne derfor etablere en gateway funktionalitet med SOSI understøttelse og træk på Medicinprofil/receptserver og LPR/DRG oplysninger. Derfor kan igangværende EPJ implementeringer fortsætte, såfremt denne tilpasning tilføjes til projekterne. Følgende trin: De næste trin kan passende planlægges og afklares i løbet af 2007. For hver af regionerne skal der, med udgangspunkt i de eksisterende leverandør kontrakter, fastlægges pejlemærker for fælles løsninger (er) i forbindelse med næste runde af EU-udbud af videre drift/udbygning af EPJ-løsninger. Dette giver leverandørerne mulighed for gradvist at tilpasse sig de nationale services og standarder, på tilsvarende måde, som leverandørerne af EOJ systemerne til kommunerne nu har iværksat en tilpasning til at hjemmesygeplejens Medicinkort fremover ligger centralt i Medicinprofilen /Receptserveren. 38000 v1 9 / 4 3

3. Udgangspunkt - overordnet set 3.1. Generelt Som kortlagt af EPJ-Observatoriet er de fleste amter/regioner kommet langt med indførelsen af 2. generations EPJ. Disse projekter har til formål primært at give klinikerne en god it-understøttelse i det kliniske arbejde med patienterne. Men der lægges også en meget stor indsats i at integrere eksisterende EPJ systemer og komponenter, således at EPJ løsningen i regionen for klinikeren er så integreret og sammenhængende som teknisk muligt. En god it-understøttelse til klinikerne i deres daglige arbejde er den altoverskyggende udfordring for regionernes EPJ implementering, også på grund af integrationen af de tidligere amtslige løsninger. I de senere år er det blevet suppleret med et antal nationale projekter, som stiller krav om at der etableres en sikker og hurtig integration til udvalgte nationale services og registre (System-system integration, som ikke umiddelbart er synlig for klinikeren). Eksempler på dette er: sundhed.dk's integration til eksisterende registre og fødesystemer. Giver lettere adgang til relevant information for klinikeren. Receptserverens integration til apotekssystemer og lægepraksissystemer. Forbedrer kvaliteten i recepter og gør det muligt for læger og hjemmesygepleje at se såvel ordineret som udleveret medicin. Medicinprofilens integration til de kommunale omsorgssystemer, således at kommunikation mellem hjemmesygepleje, apotek og læge automatiseres. Medicinprofilens integration til EPJ mediciner, således at sygehuslæger får adgang til al information om ordineret og udleveret medicin. Hidtil har de enkelte amter/regioner udviklet egne it-løsninger, hvor hver løsning adresserer samme kliniske behov. Dette har medført, at der på markedet er flere løsninger, der kan dække det samme behov. Dette giver konkurrence, men omkostningsmæssigt vil der være potentiale i at udvide graden af genbrug, såvel på udviklingsomkostningerne som på driftsomkostninger. Danmark er forholdsvis langt fremme med det tværsektorielle samarbejde. Det er primært understøttet af udvekslingen af EDIFACT meddelelser, som typisk fungerer som en slags bestilling eller "overdragelsesdokument", når én aktør enten bestiller en ydelse hos, eller overdrager en behandling til, en anden aktør. 38000 v1 1 0 / 4 3

Behovet for integration til andre aktører forventes at stige i fremtiden. Dette hænger sammen med at diagnostik, behandling og pleje i øget omfang vil involvere aktører udenfor det sygehus, hvor patienten er indlagt. Dette er fx tværgående kliniske servicefunktioner på andre sygehuse til diagnosticering, men også overgange mellem primær sektor, kommunal sektor og sygehuse i behandlings- og plejeforløbet. Dette forudsætter, at en række nøgledata og beslutningsdata kan deles og gøres tilgængelige for de forskellige aktører, som deltager i diagnostik, behandling og pleje af patienten. Dette skal selvfølgelig ske under striks adgangskontrol. 3.2. Behov for mere sammenhængende it-understøttelse Som beskrevet i analyserapporterne 1 menes med en mere sammenhængende itunderstøttelse de infrastrukturelle 2 og it-arkitekturmæssige 3 rammebetingelser, som skal sikre at de forskellige it-systemer kan arbejde bedre sammen (systemsystem integration). Den kliniske it-understøttelse i EPJ erne påvirkes således kun indirekte, fx hvor en ny integration giver klinikeren adgang til kliniske data fra andre it-systemer, eller en sammenhængende sikkerhedsløsning (fx single sign-on) giver væsentlige lettelser i klinikernes anvendelse af it (klinikeren behøver ikke logge ind på 3-4 forskellige systemer med forskellige passwords og klinikeren behøver ikke at genindtaste nødvendige stamdata mv.). Og endeligt adresserer initiativerne 1 ikke alene EPJ området, men det samlede sundhedsområde, som illustreret i figur 1 nedenfor. Her er tale om såvel en national infrastruktur, 5 regionale og et stort antal kommunale infrastrukturer suppleret med et stort antal private systemer og platforme. 2 Ved infrastruktur menes netværk, platforme, sikkerhedskomponenter, overvåpgningskomponenter, middleware, kommunikationsprotokoller, integrationssnitflader og semantik. 3 Ved it-arkitektur forstås primært de principper, modeller, mønstre og standarder, som IT-og Telestyrelsen anbefaler i deres Hvidbog og Håndbog for it-arkitektur i det offentlige. 1 "Sammenhængende it på sundhedsområdet - Oplæg til nationalt initiativ, Analyserapport - arkitektur v. 3". Udarbejdet af Devoteam Consulting for Indenrigs- og Sundhedsministeriet i foråret 2006 38000 v1 1 1 / 4 3

Lev. EPJ EPJ delsystem Myndigheds Kommunale infrastrukturer EOJ infrastruktur & platform EPJ infrastruktur & platform Regionale infrastrukturer Læge praksis system National on-line infrastruktur Private platforme Nationale services fx PEM, LPR Fælles services fx sundhed.dk Figur 3: Kontekst med mange aktørområder og fokus på infrastruktur og sammenhænge (gateway) betyder, at der er behov for en eller flere integrationer mellem forskellige it-infrastrukturer. Figur 1 illustrerer følgende centrale forhold: I snitfladerne mellem de forskellige it-miljøer skal etableres Gateway funktionaliteter, som gør det muligt for systemer og brugere at tilgå services hos andre på en sikker, hurtig og integreret facon (det skal helst ikke forudsætte at klinikerne skal logge ind på et nyt system, for at kunne hente eventuelle data). Dette omfatter bl.a. nationale fælles services forstået som it-løsninger og data, som de centrale myndigheder stiller til rådighed for de øvrige aktører og som dermed gerne skal kunne integreres med aktørernes egne systemer. Eksempler herpå er Medicinprofilen og Receptserveren. Andre fælles services forstået som it-løsninger og data, som flere parter er enige om at stille til rådighed for hinanden. Eksempler herpå er SUP og sundhed.dk's services målrettet de sundhedsprofessionelle. På regionalt plan implementeres for øjeblikket regionale EPJ infrastrukturer og platforme, som dels skal understøtte alle lokale er, delsystemer, fødesystemer og hertil hørende integrationer og sikkerhedsløsning. På kommunalt plan er etableret elektroniske omsorgsløsninger og infrastrukturer, hvor brugerne hyppigt har behov for en hurtig og sikker adgang til Medicinprofilen og Receptserveren. Hjemmesygeplejens medicinkort er fremover en del af Receptserveren, således at det hermed er muligt for praktiserende læger, apoteker og sygehuslæger dels at se indholdet og dels at samarbejde om indholdet i Medicinkortet. 38000 v1 1 2 / 4 3

For praktiserende læger giver integration til Receptserver, Medicinkort og Medicinprofilen væsentlige lettelser i kommunikationen med hjemmesygeplejen og apotekerne. On-line adgangen til Medicinprofilen, interaktionsdatabasen, lægemiddelkataloget og på et senere tidspunkt også det planlagte ordinations forventes at medføre væsentlige lettelser for den praktiserende læge. Integration mellem et klinisk bruger og en national service (eller anden fælles service) vil altid involvere flere lag af infrastrukturer, platforme og komponenter. Fx kræver integration af Medicinprofil (PEM) data i et EPJ medicin involvering og tilpasning af: to it-systemer (bruger og eventuelt også service udbyderens system), to niveauer af infrastrukturer og sikkerhedsløsning, det nationale niveau og det regionale niveau, en gateway, der indbyrdes forbinder de to infrastrukturer. Dette er illustreret i figuren nedenfor. Kommunikation mellem bruger og national service involverer brugeret, den nationale service, gateway og to uafhængige infrastrukturer. Lev. EPJ EPJ delsystem Myndigheds Kommunale infrastrukturer EOJ infrastruktur & platform EPJ infrastruktur & platform Regionale infrastrukturer Læge praksis system National on-line infrastruktur Private platforme Nationale services fx PEM, LPR Fælles services fx sundhed.dk Figur 4: Integration mellem bruger og national service kræver involvering af flere infrastrukturer og platforme. Det er klart at jo flere standardiserede snitflader og komponenter der anvendes, og jo mere genbrug af de samme infrastruktur komponenter der kan opnås, desto billigere vil det blive at udvikle, vedligeholde og drifte de forskellige integrationer. 38000 v1 1 3 / 4 3

Med udgangspunkt i denne sammenhæng skitseres Devoteam Consulting's konkrete forslag til mulige udviklingstrin på EPJ området, som vi mener vil give mening for de enkelte regioner i forskellig takt. Efter en gennemgang af et antal kørende projekter, som peger i samme retning, konkretiseres anbefalingerne ud fra en EPJ synsvinkel. Der anvendes samme struktur som i analyserapporterne, dvs. med fokus på tre initiativer, der berører EPJ området: Initiativ A: National online infrastruktur for sundhedssektoren Initiativ B: Fællesregional EPJ SW platforms komponenter Initiativ C: Overgang til fælles EPJ er og delsystemer 3.3. Generel forståelse for trinvis udvikling på EPJ området På baggrund af den løbende dialog med en række aktører og deltagelse i et antal konkrete projekter er det Devoteam's vurdering, at der langt hen ad vejen er basis for enighed omkring EPJ udviklingen. Der er tilsyneladende ret bred enighed om de overordnede principper i den langsigtede strategi (kan populært benævnes 3. generations EPJ ), hvor der skal tilstræbes en yderligere tværgående harmonisering og integration på tværs. Men det forudsætter, at de nuværende udfordringer i 2. generations projekterne løses og at der hurtigst muligt opbygges erfaring fra klinikernes anvendelse af systemerne. Devoteam Consulting's vurdering er, på baggrund af dialogen med udvalgte aktører og leverandører, at alle kørende EPJ-projekter kan drejes i den rigtige retning, således at ingen af projekterne vil være spildt og der er derfor heller ingen grund til at stoppe dem helt. Dette kan ske ved, at der i de eksisterende systemer tilføjes snitflader til den fælles infrastruktur, de fælles services og sikkerhedsløsning, i form af gateways, som konverterer data og protokoller mellem det regionale miljø og de fælles services. Gateway funktionalitet er software, som kører på en integrationsplatform. Med udgangspunkt i en gateway-løsning kan der gradvist etableres integrationer på tværs af aktører, og på sigt (3. generations EPJ) vil det så give mening af harmonisere yderligere - også på platforms- og niveau. 38000 v1 1 4 / 4 3

Det er Devoteam Consultings vurdering, at flere af de berørte parter gerne vil med i en konstruktiv dialog rundt om bordet med sigte på at fastlægge en fælles strategi og fælles løsningselementer, dels internt i de enkelte og dels på tværs af regioner. 3.4. Et antal kørende projekter er første skridt I sundhedssektoren har været gennemført rigtig mange projekter med fokus på system-system integration. De fleste har primært omfattet forskellige interne systemer på et sygehus eller i et amt, eller har været baseret på afsendelse/modtagelse af EDIFACT meddelelser baseret på MedCom standarderne. De senere år har en række projekter også omfattet on-line integration af itsystemer på tværs af aktører. Ved on-line integration forstås, at brugeren/klinikeren under selve interaktionen med det lokale it-system har behov for at anvende funktioner, eller hente/opdatere data fra en kilde, uden for eget it-system - og at dette foregår uden væsentlige forringelser i svartider. En række af disse tværgående projekter og løsninger udgør et udmærket startgrundlag for en mere sammenhængende it-arkitektur på tværs af aktørerne og det er vigtigt at udnytte resultaterne fra herfra. Centrale projekter er: Forskellige integrationsprojekter realiseret i sundhed.dk regi. Medicinprofilen /receptserveren hos LMS Integration af Medicinprofil/receptserver med de kommunale omsorgssystemer (EOJ). Integration af Medicinprofilen/receptserver med sygehusenes EPJ systemer (SOSI projektet). I relation til strukturen i figur 3 vises nedenfor i figur 5, hvorledes disse projekter hver især bygger (eller forudsætter) en sammenhængende infrastruktur og itarkitektur. Og iværksættes der ikke en fælles infrastruktur opbygning og arkitektur etablering, risikerer disse projekter at gå i drift som isolerede "øer", som ikke hænger sammen, ikke anvender de samme standarder, services og er og dermed ikke kan være grundlag for kommende nye fælles integrationer på tværs af aktører. 38000 v1 1 5 / 4 3

Hjemmesygeplejens integration til Medicinprofilen Myndigheds Lev. EOJ infrastruktur & platform EPJ medicin EPJ delsystem EPJ infrastruktur & platform Receptserver projektet National on-line infrastruktur SOSI projektet Læge praksis Læge system praksis Læge system praksis Læge system praksis system VANS Net LMS Medicinprofil Receptserver sundhed.dk Internet Borger & Sundhedsprofessionelle Apoteks system Apoteks system Apoteks system Apoteks system sundhed.dk services Figur 5: Eksisterende projekter realiserer hver for sig elementer af en sammenhængende arkitektur. De ovenfor viste projekter er ikke en komplet oversigt over relevante projekter, men skal opfattes som gode og vigtige eksempler på on-line system-system integration. I det følgende beskrives de enkelte projekter kort. 3.4.1. Receptserver projektet Projektet har til formål dels at give et mere komplet billede af en patients medicinering i Medicinprofilen (så også ordinationer kommer med), dels at sikre kvaliteten i receptindhold og dels at stille information om ordineret medicin til rådighed for flere parter end blot den enkelte involverede læge og det adresserede apotek. Projektet dækker system-system integration mellem et antal forskellige systemer, Lægemiddelstyrelsens Medicinprofil/receptserver, apotekernes receptur systemer, hjemmesygeplejens omsorgssystemer og lægepraksissystemerne hos de praktiserende læger. I dette projekt er realiseret følgende system-system integrationer: 38000 v1 1 6 / 4 3

Integration mellem Medicinprofil/Receptserver og alle apotekssystemer (3 forskellige leverandører og 4 forskellige apotekssystemer) via OIOXML 4 snitflade. Integration til VANS (Value Added Network Services) netværk fra leverandørerne KMD og Progrator. Integrationen omfatter EDIFACT og XML modtagelse af alle elektroniske recepter udstedt af lægepraksis systemer. 3.4.2. Ordinationsservice Som en naturlig videreudvikling af Receptserveren er det planlagt at tilbyde faciliteter for lægen, som gør det muligt for ham at gennemføre en komplet ordinationsproces. Dette ordinations bygger på Medicinprofilen/receptserveren, har adgang til LMS's interaktionsdatabase og lægemiddelkatalog og tilbyder den praktiserende læge alle nødvendige beslutningsstøtte værktøjer til gennemførelse af ordinationen. Servicen vil blive stillet til rådighed både som en Webservice, der kan integreres i et lokalt praksissystem og som en HTML grænseflade. Adgangen forudsætter digital signatur og billetudstedelse jfr. SOSI specifikationerne (se nedenfor). Denne ordinationsservice kan dermed være fælles for alle praktiserende læger i landet, og vil kunne udvides til også at kunne dække væsentlige behov hos sygehuslægerne. 3.4.3. Integration af hjemmesygeplejens EOJ system Hjemmesygeplejens adgang til Medicinprofilen/receptserveren tjener følgende overordnede formål: At forbedre kommunikationen mellem hjemmesygeplejen, praktiserende læge, apotek og sygehus og erstatte de mange papirbaserede/telefonbaserede dialoger med elektronisk kommunikation. At lette arbejdsgangene og give hjemmesygeplejerne et hurtig overblik over aktuel medicinering, ordineret medicin, bestilt medicin og leveret medicin. Etablere et "fælles" medicinkort, som kan deles mellem læger og hjemmesygepleje. Konkret består opgaven i realiseringen af det fælles medicinkort på Medicinprofilen/receptserveren, integration af denne med 4 forskellige EOJ leverandørers systemer samt optimering af hjemmesygeplejens arbejdsgange og ko mmunbikation med de andre aktører. 4 OIOXML er IT- og Telestyrelsens metode til specifikation, dokumentering og konsolidering af XML snitflader og semantik i snitfladerne mellem it-systemer hos forskellige offentlige myndigheder. 38000 v1 1 7 / 4 3

3.4.4. SOSI projektet SOSI projektet (Service Orienteret System Integration) er et pilotprojekt etableret i et samarbejde mellem Amtsrådsforeningen, Ribe Amt (formandskab), Københavns Amt og Lægemiddelstyrelsen. I projektets styregruppe indgår endvidere ITog Telestyrelsen samt de involverede leverandører. SOSI projektet går i korthed ud på: Medicinprofilens og Receptserverens services stilles til rådighed for sygehusenes brugere af EPJ systemer. EPJ mediciner indberetter dagligt medicineringsinformation til Medicinprofilen, via system-system overførsler. Klinikernes forbindelse til Medicinprofilen sker via en sikker infrastruktur (en fleksibel single sign-on sikkerhedsløsning), som baserer sig på Web service integration, billetudstedelsesmekanisme (fælles Identity Provider) og anvendelsen af OCES certifikater. Data udveksles baseret på publicerede OIOXML snitflader. SOSI komponenterne (en SOSI komponent er Open Source software, som gratis kan stilles til rådighed for alle) kan anvendes i alle regioner og med en begrænset indsats kan disse integreres med eksisterende EPJ platform og medicin. KL støtter sikkerhedsløsningen og planlægger at EOJ systemer også skal anvende SOSI komponenterne. På sigt er det også oplagt, at kommende Lægepraksissystemer også anvender SOSI komponenterne, således at der kan etableres en sikker system-system integration mellem nationale services og lægepraksis systemerne. 3.4.5. Andre projekter Af andre system-system integrationsprojekter, som adresserer den tværgående online kommunikation kan nævnes: SUP databaser (Standardiseret Udtræk fra Patientdata) er et eksempel på etablering af en fælles service (data repository), som stiller EPJ data til rådighed on-line for andre sygehuse og for de praktiserende læger. SUP anvendes på en række sygehuse i dag. sundhed.dk's integration af 11 amters laboratoriesvar, således at disse, via en brugergrænseflade, kan stilles til rådighed for sundhedsprofessionelle. Den konkrete udbredelse og anvendelse er Devoteam ubekendt sundhed.dk's pilotprojekt omkring integration af lokale brugerkataloger (indeholder registrering af bruger ident og roller) og sundhed.dk's brugerkatalog. Snitflader er beskrevet og afprøvet. Når SOSI projektet skal udbredes som en 38000 v1 1 8 / 4 3

national sikkerhedsløsning, har dette projekt behov for et nationalt on-line brugerkatalog (som fødes af de lokale brugerkataloger) med en fælles struktur og syntax for roller, bruger ID mv. 3.5. Implementeringsovervejelser (ref. kapitel 6) Initiativerne i analyserapporterne 1 er kun identificeret og beskrevet på et overordnet niveau. Devoteam Consulting anbefaler en analyse på et mere konkret niveau og med udgangspunkt i en gennemgang af den aktuelle status og arkitektur for EPJ i hver af regionerne. I den forbindelse anbefaler Devoteam Consulting, at bl.a. følgende temaer belyses: Snitflader og roller for delsystemer Overvejelser ved valg af EPJ-platforms er og EPJ infrastruktur Anvendelsen af OpenSource strategi som i SOSI projektet (se Bilag 1) Nedbrydning af systemkompleks i mindre delområder og mindre delprojekter, herunder gennemførelse af Proof-of-Concept (PoC) forløb og pilotprojekt forløb (som i SOSI). De indledende overvejelser og anbefalinger om implementeringen fremgår af afsnit 6 i analyserapporterne. I det følgende er dette operationaliseret yderligere og illustreret ved nogle udviklingstrin. Men kendskab til rapporterne og her især afsnit 6 er en forudsætning for bedre at kunne forstå de følgende afsnit. 1 "Sammenhængende it på sundhedsområdet - Oplæg til nationalt initiativ, Analyserapport - arkitektur v. 3". Udarbejdet af Devoteam Consulting for Indenrigs- og Sundhedsministeriet i foråret 2006 38000 v1 1 9 / 4 3

4. Initiativ A: National on-line infrastruktur 4.1. Etablering af on-line infrastruktur Ud fra de konkrete projekters akutte behov (især SOSI og Medicinprofilen) samt en vurdering af, at behovene for mere tværgående kommunikation vil øges i de kommende år, anbefaler Devoteam Consulting, at der etableres en fælles arkitektur og infrastruktur ( tekniske rammebetingelser ), som skal leve op til følgende krav: 1. Hurtig online kommunikation, som kan sikre klinikerne korte svartider, når de skal hente, eller aflevere, data udenfor eget system. 2. Fælles sikkerhedsløsning på nationalt plan, som beskytter mod utilsigtet anvendelse og videregivelse af fortrolige data. 3. Adgang til opdaterede data og reduceret omfang af redundante data. 4. Klare og veldokumenterede snitflader (jfr. OIOXML standarderne), således at det er lettere at koble aktører fra andre sektorer på de fælles systemer. 5. Teknisk enkel adgang for klinikere til nationale services og fælles services, dvs. mulighed for at integrere fælles services i lokale løsninger. 6. Klinikernes samarbejde med andre aktører i det enkelte patientforløb understøttes af it. I relation til den overordnede kontekst i figur 3 er omfanget af initiativ A illustreret i nedenstående figur. Lev. EPJ EPJ delsystem Myndigheds Kommunale infrastrukturer EOJ infrastruktur & platform EPJ infrastruktur & platform Regionale infrastrukturer Læge praksis system Private platforme National on-line infrastruktur Nationale Fælles services fx services PEM, LPR fx sundhed.dk Initiativ A dækning Figur 6: Initiativ A dækning Det anbefales, at følgende infrastruktur etableres: 38000 v1 2 0 / 4 3

Højhastighedsnet, som forbinder alle aktørers systemmiljøer. Netværket skal sikre korte svartider (1-3 sekunder) ved forespørgsler og et sikkert serviceniveau mht. tilgængelighed, båndbredde mv. Løser behovet i pkt. 1 og 3 angivet ovenfor. Højhastighedsnettet kan realiseres som en opgradering af det nuværende Sundhedsdatanet, således at der kan garanteres en høj båndbredde, korte forsinkelser (få 100 ms.) på transport af meddelelser, en garanteret meget høj tilgængelighed døgnet rundt og en overvågningsmekanisme, der hele tiden gør det muligt at identificere potentielle fejl og flaskehalse. Det nuværende EDI- FACT /XML VANS Net (fra KMD og Progrator) kan ikke anvendes til online transaktioner, da meddelelser i dette netværk typisk er forsinket flere minutter. Fælles sikkerhedsløsning og replikerede brugerdatabaser baseret på SOSI projektets resultater. Herunder især Identity Providere og OCES certifikathåndteringen. Adresserer behovet i pkt. 2 ovenfor. Integrations software, som implementerer gateway funktionalitet, som kan genbruges af flere aktører. Gateway funktionalitet skal udvikles til såvel de nationale services som til de regionale EPJ platforme. Gateway software bør stilles til rådighed som Open Source (dvs. gratis), således at dette kan anvendes af flere leverandører, enten til installation på integrationsplatformen eller på EPJ platformen (afhængig af lokal teknisk arkitektur). Adresserer behovet angivet i pkt. 4 og 5 ovenfor. Integrationsplatforme i den fælles infrastruktur varetager også overvågning, logning, sikkerhed og afvikler gateway software. Adresser pkt. 1 ovenfor. Aktuel integration til et antal fælles og nationale services og publicering af disse via OIOXML snitflader. Adresserer behovet i pkt. 4 og 6 ovenfor. Denne on-line infrastruktur foreslås etableret i to tempi, således som skitseret nedenfor. 4.2. Første trin 2007 I det første trin i 2007 vil alle klinikere få adgang til de eksisterende nationale services (er i dag ikke fuldt tilgængelige for alle aktører) kombineret med en fuld udrulning af SOSI komponenterne, således at sikkerhedsløsningen genbruges på tværs. Konkret foreslås følgende indhold af første trin i initiativ A: Medicinprofil/Medicinkort/Receptserver implementeres som planlagt som national service. 38000 v1 2 1 / 4 3

Eksisterende kontakt LPR register/drg register implementeres som national service. National sikkerhedsløsning fra SOSI implementeres hos alle aktører. SOSI Indentity Provider (den service som i pilotprojektet varetages af TDC) etableres som national service. EPJ integration vha. SOSI Open Source er. EOJ integration vha. SOSI Open Source er. Nuværende Sundhedsdatanet anvendes som transmissionsnet. Dvs. fortsat anvendelse af VPN (Virtual Private Network) forbindelser over internettet, med dertil hørende lavere service levels mht. tilgængelighed, båndbredde og svartider. OIOXML standarder skal implementeres i takt med de enkelte projekters behov og afstemning af standarderne skal varetages i et sektorstandardiseringsorgan, således som anbefalet af IT- og Telestyrelsen. Ovenstående trin er i vid udstrækning baseret på eksisterende og vedtagne projekter, dog skal følgende besluttes: SOSI sikkerhedsløsningen introduceres som den nationale sikkerhedsløsning inden for det samlede sundhedsområde, inkl. omsorgsområdet og lægepraksis området. LPR/DRG registeret stilles til rådighed baseret på en SOSI sikkerhedsløsning. Der skal nedsættes en beslutningsdygtig sektorstandardiserings udvalg, som kan støtte, konsolidere og afstemme de forskellige projekters OIOXML standardisering. Under alle omstændigheder skal det sikres, at alle faciliteterne i første trin (2007) kan videreføres i næste trin (2008 og frem). 4.3. Næste trin - 2008 og frem Som næste trin anbefaler Devoteam Consulting, at der i løbet af 2007 specificeres og anskaffes en højhastigheds infrastruktur ("Sundhedsdatanet II") med overvågning, monitorering og logning, således at klinikerne kan garanteres acceptable svartider. Endvidere anskaffes en SOA 5 integrationsplatform, som indeholder en række standard værktøjer og er og som derved kan udgøre en fælles reference software platform for gateway funktionalitet og SOSI Open Source komponenter. Denne integrationsplatform kan genbruges af flere aktører og bør derfor stilles gratis til rådighed som en fælles infrastruktur komponent. 5 Service Orienteret Arkitektur 38000 v1 2 2 / 4 3

En nærmere behovsanalyse skal fastlægge hvilke funktioner, som fællesskabet vil få glæde af. Men Devoteam anbefaler at følgende elementer bør indgår i løsningen: Netværk, som i modsætning til i dag, ikke er baseret på VPN og Internet, men derimod lukkede faste kredsløb. HL7 6 standarderne anvendes som grundlag for fastlæggelse af udvekslingsstandarder (HL7 indpakker og transporterer data) og er udgangspunkt for specifikation af snitflader, som overholder OIOXML retningslinierne (dermed kan et stort antal internationale systemer lettere integreres). Etablering af et fælles servicekatalog og fælles styring af de ressourcer og services, som stilles til rådighed på den fælles infrastruktur. Integration til X antal fødesystemer på sygehusene. Med en HL7 baseret integration på den fælles integrationsplatform kan disse fødesystemer og deres integrationer direkte understøttes af selve infrastrukturen - og dermed genanvendes på tværs af sygehuse/regioner. Etablering af et antal yderligere nationale services. På basis af prioriteringerne i den nationale it-strategi samt de kliniske behov på såvel sygehusområdet, primærsektoren og den kommunale plejesektor skal fastlægges hvilke nationale og fælles services som bør introduceres. Eksempler er: o Fælles medicinordinationssystem for praktiserende læger. o CAVE server o Stamdata server (CPR, CVR, autorisationsregister, mv.) o Laboratorie svar server o Interaktionsdatabase o Epikrise server o Tværfaglig journal (primær sektor, kommunal sektor, sygehuse) o E-Journal (udvalgte dele af sygehus journal) o Det kommende F-LPR register. Videreudbygningen af den nationale infrastruktur består således af to hovedelementer: a) forbedring af selve infrastrukturen, og b) tilføjelse af nye nationale fælles services. Dette er søgt illustreret i figuren nedenfor. 6 Standard fra den amerikanske standardiseringsorganisation Health Level 7 38000 v1 2 3 / 4 3

Lev. EPJ EPJ delsystem Myndigheds Kommunale infrastrukturer EOJ infrastruktur & platform EPJ infrastruktur & platform Regionale infrastrukturer Læge praksis system Private platforme National on-line infrastruktur PEM/ sundhed.dk receptserver F-LPR LPR/DRG Epikrise Cave server server Initiativ A udbygning Figur 7: Initiativ A udbygning 38000 v1 2 4 / 4 3

5. Initiativ B: Fælles EPJ software platform komponenter Analyserapporten peger på, at der kan opnås besparelser gennem et samarbejde mellem regionerne om etablering af et fælles sæt EPJ SW-platform komponenter, som med fordel kan fungere som et softwaremæssigt fundament for EPJ er/ delsystemer og som en adgangsvej (gateway) til den fælles on-line infrastruktur, de fælles services og systemer hos andre aktører. SOSI projektet er et godt eksempel på, at de samme er genbruges i flere regioner. Den fælles SW-platform opbygges gradvist og der iværksættes en konvergens af de indsatser, som i dag foregår regionalt. Hermed kan udviklingsomkostningerne til platform, til EPJ er og til integrationer gradvist reduceres, idet dobbeltudvikling af centrale dele kan undgås. I relation til figur 3 adresserer initiativ B det område, som er angivet i figuren nedenfor. Lev. EPJ EPJ delsystem Myndigheds Kommunale infrastrukturer EOJ infrastruktur & platform EPJ infrastruktur & platform Fælles komponenter Initiativ B dækning Læge praksis system National on-line infrastruktur Private platforme Nationale services fx PEM, LPR Fælles services fx sundhed.dk Figur 8: Fokusområde for initiativ B Etableringen af en fælles EPJ SW-platform indebærer flere gevinster: Klinikerne vil få online adgang til relevante kilder og det giver et bedre grundlag for diagnostik, behandling og pleje. Samtidig vil der være mere ensartet brug af regionale ressourcer, data og services. Ajourførte data og øget datakvalitet. Centrale og kritiske data lagres et fælles sted i regionen, således at disse data er tilgængelige for alle delsystemer og er. Unødig kopiering og vedligeholdelse af de samme data i flere systemer kan dermed undgås, hvilket vil øge datakvaliteten. 38000 v1 2 5 / 4 3

Tilpasning til de samme semantiske begreber for så vidt angår informationer, som skal deles med andre ("udvekslings semantik"). Fælles tilgang til standardisering. Der indføres en mere ensartet brug af standarder, som udover IT- og Telestyrelsens anbefalinger og OIOXML retningslinierne også kan omfatte anbefalinger omkring den lokale logiske datamodel, udvekslings semantikken og mapningen mellem fx G-EPJ og HL7. Øget konkurrence på EPJ-er og EPJ-delsystemer. Fælles EPJ SWplatform komponenter åbner mulighed for, at forskellige leverandører kan udvikle og tilbyde software og delløsninger til sygehusene. Der ved vil det være sikret, at disse løsninger er korrekt integreret med de regionale og nationale services og realiseret i overensstemmelse med de fælles standarder fastlagt af de enkelte komponenter i SW-platformen. En OpenSource implementering, som udbredes til alle regioner, vil gøre det forretningsmæssigt attraktivt for leverandører at tilbyde nye løsninger, idet de samme løsninger så kan genanvendes uden væsentlige tilpasninger i alle regioner. OpenSource strategien belyses yderligere i bilag 1. Besparelser i omkostninger til sikkerhedsløsninger. Der kan opnås besparelser i både anskaffelse og vedligeholdelse af sikkerheds software ved at bruge den samme sikkerhedsmodel (og de samme sikkerhedskomponenter) som anvendt i den nationale sikkerhedsløsning. Besparelser på udvikling af integrationer. Udvikling og vedligeholdelse kan billiggøres betydeligt ved at disse udvikles til den fælles integrationsplatform eller de fælles EPJ SW platform komponenter, idet antallet af forskellige integrationer kan nedbringes markant. 5.1. Regional EPJ infrastruktur skal etableres En væsentlig indsats og udfordring i regionerne er at etablere en sammenhængende EPJ infrastruktur, som på en god og optimal måde kan integrere såvel nye som eksisterende EPJ delsystemer. Udfordringerne her er på mange måder væsentligt større end for den nationale infrastruktur, idet den regionale infrastruktur skal kunne understøtte den meget kritiske daglige produktion for mange tusinde medarbejdere. Også her er der behov for et højhastighedsnet, som kan udgøre back-bone nettet for alle systemer, en fælles sikkerhedsløsning samt en lang række fælles services, databaser og registre, som tidstro skal være tilgængelige for klinikerne. 38000 v1 2 6 / 4 3

Lev. EPJ EPJ delsystem Myndigheds Kommunale infrastrukturer EOJ infrastruktur & platform Regional back-bone net med fælles services/komponenter Initiativ B dækning Læge praksis system National on-line infrastruktur Private platforme Nationale services fx PEM, LPR Fælles services fx sundhed.dk Figur 9: Hver region har behov for at etablere sin egen højhastigheds infrastruktur Derfor skal der i regionen fastlægges meget håndfaste principper og standarder for tilslutning og håndtering af EPJ er og EPJ delsystemer og en regional EPJ udvekslingssemantik skal fastlægges, således at alle delsystemer, som skal udveksle data med andre systemer, anvender de samme begreber. Og endelig skal udvikles gateways til nationale services og andre fælles services. Dette behov er eksemplificeret ved figuren nedenfor, som er en konkretisering og et eksempel, som går videre end de mere generaliserede figurer i analyserapporterne. De enkelte elementer i figuren skal kun opfattes som eksempler, den konkrete realisering vil variere fra region til region. 38000 v1 2 7 / 4 3