Sammenhængende it på Sundhedsområdet

(1)

Sammenhængende it på Sundhedsområdet

4. januar 2007

Relation til EPJ udviklingen

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

(2)

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.

(3)

38000 v1 1 / 4 3

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

(4)

38000 v1 2 / 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”.¹

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æl- les tiltag - uden at det nødvendiggør at igangværende EPJ projekter stoppes.

I kapitel 6 i analyserapporterne¹ 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

(5)

38000 v1 3 / 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øsnin- gen 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.

(6)

38000 v1 4 / 4 3

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 moderni- sering og harmonisering af den infrastruktur og it-arkitektur, som direkte under- støtter dette.

Konkret foreslås dette realiseret gennem flg. initiativer:

• A: National on-line infrastruktur med fælles sikkerhedsløsning og integra- tionskomponenter, 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 moduler, 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.

Praksis systemer Praksis systemer Praksis systemer Praksis systemer Praksis systemer Praksis systemer Praksis systemer

EOJ systemer

Apoteks systemer

MedCom VANS netværk

Fælles service

Medicinprofilen

Info services

Receptserver sundhed.dk Fælles on-line

services:

Sikkerheds service Overvågning

Katalog

Sundhedsdatanettet

Nye kommunale sundhedscentre

M1 M2 M3

I1 I2 I3

M4 EPJ system – Region 1

M1 M2 M3

I1 I2 I3

M1 M2 M3

I1 I2 I3

M1 M2 M3

I1 I2 I3

M1 M2 M3

I1 I2 I3

M4 EPJ system – Region 4 Mange forskellige EPJ systemer, moduler, integrationer og platforme

Meddelelsesbaseret udveksling af data – giver ikke mulighed for on-line adgang til data og services

Behov for on-line adgang til fælles services og data

Løsninger skal udvikles Baseret på Internettet.

Tilgængelighed og kapacitet er ikke tilstrækkelig. Sikker on-line drift kræver dedikeret bredbåndsnet

11forsk.

systemer 4 forsk.

systemer 3 forsk.

systemer

Internettet Mangler

Praksis systemer Praksis systemer Praksis systemer Praksis systemer Praksis systemer Praksis systemer Praksis systemer

EOJ systemer

Apoteks systemer

MedCom VANS netværk

Fælles service

Medicinprofilen

Info services

Receptserver sundhed.dk Fælles on-line

services:

Sikkerheds service Overvågning

Katalog

Sundhedsdatanettet

Nye kommunale sundhedscentre

M1 M2 M3

I1 I2 I3

M1 M2 M3

I1 I2 I3

M1 M2 M3

I1 I2 I3

M1 M2 M3

I1 I2 I3

M4

M1 M2 M3

I1 I2 I3

M1 M2 M3

I1 I2 I3

M4

M1 M2 M3

I1 I2 I3

M4 EPJ system – Region 4 Mange forskellige EPJ systemer, moduler, integrationer og platforme

Meddelelsesbaseret udveksling af data – giver ikke mulighed for on-line adgang til data og services

Behov for on-line adgang til fælles services og data

Løsninger skal udvikles Baseret på Internettet.

Tilgængelighed og kapacitet er ikke tilstrækkelig. Sikker on-line drift kræver dedikeret bredbåndsnet

11forsk.

systemer 4 forsk.

systemer 3 forsk.

systemer

Internettet Mangler

Figur 1 Nuværende integrations infrastruktur

(7)

38000 v1 5 / 4 3

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 anvendel- sesmø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.

National on-line infrastruktur og sikkerhedsløsning EOJ

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

Fælles services fx sundhed.dk

SUP Nationale

services fx PEM, LPR

GW GW

GW Læge

praksis system

Regionale infrastrukturer Kommunale infrastrukturer

Private platforme

National on-line infrastruktur og sikkerhedsløsning EOJ

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

Fælles services fx sundhed.dk

SUP Nationale

GW GW

GW Læge

praksis system

Private platforme

Figur 2: Infrastruktur kontekst

(8)

38000 v1 6 / 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 udrul- ning af SOSI sikkerhedsløsningen. Konkret foreslås følgende hovedind- hold 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 sek- torstandardiseringsorgan, således som anbefalet af IT- og Telesty- relsen.

Næste trin:

Som næste trin anbefaler Devoteam Consulting, at der anskaffes en højha- stigheds 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 moduler 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

(9)

38000 v1 7 / 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 hovedele- menter: a) forbedring af selve infrastrukturen, og b) tilføjelse af nye nationale fæl- les 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 moduler genbruges i flere regioner.

Den fælles SW-platform er den langsigtede strategi, og de nuværende EPJ løsnin- ger 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 moduler 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øs- ninger, 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-moduler og EPJ-delsystemer. Fælles EPJ SW- platform 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

(10)

38000 v1 8 / 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ængen- de 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 brugerinformatio- ner 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øl- gende 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 moduler 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.

(11)

38000 v1 9 / 4 3

2.2.3. C: Overgang til flere fælles EPJ moduler

I takt med harmoniseringen og standardiseringen af EPJ infrastruktur og platforms elementer (især "connectorerne", udvekslingssemantikken og sikkerhedsløsnin- gen) 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 virksomhe- der at udvikle nye EPJ moduler.

Dette giver basis for følgende:

• Konkurrence på EPJ moduler/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å modulområ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 brugermoduler, som giver brugeren/modulet 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 leveran- dør kontrakter, fastlægges pejlemærker for fælles løsninger (moduler) 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 Medicin- kort fremover ligger centralt i Medicinprofilen /Receptserveren.

(12)

38000 v1 1 0 / 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 altoverskyg- gende 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. For- bedrer 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 medicinmoduler, 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 om- kostningsmæ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 fun- gerer 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.

(13)

38000 v1 1 1 / 4 3

Behovet for integration til andre aktører forventes at stige i fremtiden. Dette hæn- ger 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å overgan- ge mellem primær sektor, kommunal sektor og sygehuse i behandlings- og pleje- forlø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¹ menes med en mere sammenhængende it- understøttelse de infrastrukturelle² og it-arkitekturmæssige³ rammebetingelser, som skal sikre at de forskellige it-systemer kan arbejde bedre sammen (system- system integration). Den kliniske it-understøttelse i EPJ modulerne påvirkes såle- des 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 ¹ 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.

2Ved infrastruktur menes netværk, platforme, sikkerhedskomponenter, overvåpgningskomponen- ter, middleware, kommunikationsprotokoller, integrationssnitflader og semantik.

3Ved it-arkitektur forstås primært de principper, modeller, mønstre og standarder, som IT-og Te- lestyrelsen anbefaler i deres Hvidbog og Håndbog for it-arkitektur i det offentlige.

(14)

38000 v1 1 2 / 4 3

GW (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 funktio- naliteter, 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 moduler, 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 Medi- cinprofilen 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.

National on-line infrastruktur EOJ

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

Fælles services fx sundhed.dk Nationale

GW GW

GW Læge

praksis system

Private platforme

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

GW GW

GW Læge

praksis system

Private platforme

Figur 3: Kontekst med mange aktørområder og fokus på infrastruktur og sammenhænge

(15)

38000 v1 1 3 / 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, interaktionsdataba- sen, lægemiddelkataloget og på et senere tidspunkt også det planlagte ordinationsmodul forventes at medføre væsentlige lettelser for den praktiserende læ- ge.

Integration mellem et klinisk brugermodul og en national service (eller anden fæl- les service) vil altid involvere flere lag af infrastrukturer, platforme og komponenter.

Fx kræver integration af Medicinprofil (PEM) data i et EPJ medicinmodul involvering og tilpasning af:

• to it-systemer (brugermodul 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.

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 bil- ligere vil det blive at udvikle, vedligeholde og drifte de forskellige integrationer.

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

GW GW

GW Læge

praksis system

Private platforme

Kommunikation mellem brugermodul og national service involverer brugermodulet, den nationale service, gateway og to uafhængige infrastrukturer.

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

GW GW

GW Læge

praksis system

Private platforme

Kommunikation mellem brugermodul og national service involverer brugermodulet, den nationale service, gateway og to uafhængige infrastrukturer.

Figur 4: Integration mellem brugermodul og national service kræver involvering af flere infrastrukturer og platforme.

(16)

38000 v1 1 4 / 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 moduler 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 til- stræ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æl- les 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 har- monisere yderligere - også på platforms- og modulniveau.

(17)

38000 v1 1 5 / 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å afsendel-

se/modtagelse af EDIFACT meddelelser baseret på MedCom standarderne.

De senere år har en række projekter også omfattet on-line integration af it- systemer på tværs af aktører. Ved on-line integration forstås, at bruge-

ren/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 start- grundlag 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 it- arkitektur.

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 moduler og dermed ikke kan være grundlag for kommende nye fælles integrationer på tværs af aktører.

(18)

38000 v1 1 6 / 4 3

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 Medicinpro- filen (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:

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

medicin modul

sundhed.dk Medicinprofil

Recept- server

GW GW

Læge praksis

system VANS

Net Læge

praksis system

Læge praksis system

Apoteks system

Apoteks system Apoteks

system Receptserver

projektet

LMS Hjemmesyge-

plejens integration til Medicinprofilen

SOSI projektet

Internet

Borger

&

Sundhedsprofessionelle

sundhed.dk services National on-line

infrastruktur EOJ

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

medicin modul

sundhed.dk Medicinprofil

Recept- server

GW GW

Læge praksis

system VANS

Net Læge

praksis system

Læge praksis system

Apoteks system

Apoteks system Apoteks

system Receptserver

projektet

LMS Hjemmesyge-

plejens integration til Medicinprofilen

SOSI projektet

Internet

Borger

&

Sundhedsprofessionelle

sundhed.dk services

Figur 5: Eksisterende projekter realiserer hver for sig elementer af en sammenhængende arkitektur.

(19)

38000 v1 1 7 / 4 3

• Integration mellem Medicinprofil/Receptserver og alle apotekssystemer (3 forskellige leverandører og 4 forskellige apotekssystemer) via OIOXML⁴ snit- flade.

• 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 facili- teter for lægen, som gør det muligt for ham at gennemføre en komplet ordinati- onsproces. Dette ordinationsmodul 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 syge- huslæ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 dialo- ger 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å Medicinprofi- len/receptserveren, integration af denne med 4 forskellige EOJ leverandørers systemer samt optimering af hjemmesygeplejens arbejdsgange og ko mmunbikation med de andre aktører.

4OIOXML er IT- og Telestyrelsens metode til specifikation, dokumentering og konsolidering af XML snitflader og semantik i snitfladerne mellem it-systemer hos forskellige offentlige myndigheder.

(20)

38000 v1 1 8 / 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øben- havns Amt og Lægemiddelstyrelsen. I projektets styregruppe indgår endvidere IT- og 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 medicinmoduler indberetter dagligt medicineringsinformation til Medi- cinprofilen, 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 be- grænset indsats kan disse integreres med eksisterende EPJ platform og medicinmodul.

• 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 on- line 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

(21)

38000 v1 1 9 / 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¹ 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 bely- ses:

• Snitflader og roller for delsystemer

• Overvejelser ved valg af EPJ-platforms moduler 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 for- lø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.

(22)

38000 v1 2 0 / 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 under- støttes af it.

I relation til den overordnede kontekst i figur 3 er omfanget af initiativ A illustreret i nedenstående figur.

Det anbefales, at følgende infrastruktur etableres:

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

GW GW

GW Læge

praksis system

Private platforme Initiativ A dækning

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

GW GW

GW Læge

praksis system

Private platforme

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

GW GW

GW Læge

praksis system

Private platforme Initiativ A dækning

Figur 6: Initiativ A dækning

(23)

38000 v1 2 1 / 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 serviceni- veau 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 on- line transaktioner, da meddelelser i dette netværk typisk er forsinket flere mi- nutter.

• Fælles sikkerhedsløsning og replikerede brugerdatabaser baseret på SOSI projektets resultater. Herunder især Identity Providere og OCES certifikathåndte- ringen. 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 ud- rulning 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.

(24)

38000 v1 2 2 / 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 moduler.

• EOJ integration vha. SOSI Open Source moduler.

• 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 sektorstandardiserings- organ, 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åg- ning, monitorering og logning, således at klinikerne kan garanteres acceptable svartider.

Endvidere anskaffes en SOA⁵ integrationsplatform, som indeholder en række standard værktøjer og moduler 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.

5Service Orienteret Arkitektur

(25)

38000 v1 2 3 / 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øsnin- gen:

• Netværk, som i modsætning til i dag, ikke er baseret på VPN og Internet, men derimod lukkede faste kredsløb.

• HL7⁶ standarderne anvendes som grundlag for fastlæggelse af udvekslings- standarder (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 genan- vendes 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. Eksem- pler 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 hovedele- menter: a) forbedring af selve infrastrukturen, og b) tilføjelse af nye nationale fæl- les services.

Dette er søgt illustreret i figuren nedenfor.

6 Standard fra den amerikanske standardiseringsorganisation Health Level 7

(26)

38000 v1 2 4 / 4 3

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

sundhed.dk PEM/

receptserver

GW GW

GW Læge

praksis system

Regionale infrastrukturer

Kommunale infrastrukturer

Private platforme

Initiativ A udbygning

LPR/DRG

Cave server Epikrise server

F-LPR GW

GW GW

GW National on-line

infrastruktur EOJ

infrastruktur

& platform

EPJ infrastruktur &

platform

GW GW

Myndig- heds modul

Lev.

modul

EPJ delsystem EPJ

modul

sundhed.dk PEM/

receptserver

GW GW

GW Læge

praksis system

Regionale infrastrukturer

Kommunale infrastrukturer

Private platforme

Initiativ A udbygning

LPR/DRG

Cave server Epikrise server

F-LPR GW

GW GW

GW

Figur 7: Initiativ A udbygning