Projektinitieringsdokument v Modning af telemedicinsk infrastruktur Del 1 - Standarder og NSP services. SDS opgaver

Transkript

1 Projektinitieringsdokument v. 1.1 Modning af telemedicinsk infrastruktur Del 1 - Standarder og NSP services SDS opgaver 16. marts 2016

2 Indhold 1 STAMDATA FORRETNINGENS FORMÅL MED PROJEKTET SCOPE OG AFGRÆNSNINGER MÅL OG SUCCESKRITERIER ØKONOMISKE HOVEDTAL OG FINANSIERING GEVINSTER TEKNISK LØSNING LEVERANCER ORGANISERING TIDSPLAN KVALITET RISICI KOMMUNIKATION TOLERANCER RAPPORTERINGSKRAV REVISIONSHISTORIK BILAG... 18

3 1 Stamdata Stamdata Projektnavn Modning af telemedicinsk infrastruktur (SDS del) Standarder og NSP services PM ordre nr. Projektleder Projektets primære formål Nuværende fase Ivan Lund Pedersen Telemedicinsk Infrastruktur på TRL-8 Projektstart 2 Forretningens formål med projektet 2.1 Den nuværende situation (baggrund) I økonomiaftalen 2016 (ØA16) mellem regeringen, regionerne og kommunerne er det aftalt, at parterne inden udgangen af 2019 vil tilbyde telemedicinsk hjemmemonitorering til borgere med KOL i hele landet. Arbejdet med at organisere og implementere den telemedicinske behandling forankres i fem landsdelsprogrammer under ledelse af regioner og kommuner, og med konkret ophæng i de lokale sundhedsaftaler. I perioden 2012 til 2015 er der gennemført flere initiativer på det telemedicinske område, der i større eller mindre omfang har medvirket til at etablere elementerne i en national telemedicinsk it-infrastruktur. Analyser har vist, at denne infrastruktur inklusiv de standarder og komponenter, som infrastrukturen benytter sig af, er på et Technology Readiness Level (TRL) 6. I 2011 og 2013 udarbejdede National Sundhed-it tekniske retningslinjer 1 for, hvordan helbredsdata bør deles tværsektorielt og hvordan helbredsdata opsamlet på udstyr i borgeren eget hjem kan opsamles via it-snitflader og internationale it-standarder. Den nationale itinfrastruktur skal overholde referencearkitekturerne og skal spille tæt sammen med de sundheds-it systemer, som regioner, kommuner og praksislæger anvender i det daglige arbejde ifm. håndtering af telemedicinske KOL-patienter. 2.2 Formålet med projektets løsning Som en del af ØA16-aftalen om landsdækkende udbredelse af telemedicinsk hjemmemonitorering til borgere med KOL er det besluttet, at der skal etableres en moden national itinfrastruktur, defineret som TRL niveau 8. Projektet skal bringe den samlede infrastruktur der er nødvendig for Telemedicinsk behandling af KOL patienter op på TRL niveau 8 inden Gradueringen i modenhed efter TRL skalaen består af en lang række faktorer, men de mest afgørende for projektet er at infrastrukturen og den udstillede funktionalitet skal være brugt i daglig drift eller noget, der kan sammenlignes med produktionslignende forhold. Derfor går projektet efter, at ibrugtage infrastrukturen i en pilotimplementering i et afgrænset område og i en afgrænset periode, men med rigtige patienter og rigtige data via fagsystemer, der anvendes i dagligdagen i det område hvor piloten gennemføres. Hovedparten af aktiviteterne før sommer 2016 er tekniske modningsøvelser, der afsluttes med en brugertest i et laboratorie setup, medens al aktivitet fra sommer og resten af året er forberedelse og gennemførelse af den afgrænsede pilot under produktionsvilkår. 1 ref. Ark. For opsamling af billeder og dokumenter og link & ref. Ark. For opsamling af helbredsdata hos borgeren. side 2 af 19

4 2.3 Projektets bidrag til strategiske mål Teknisk: Projektet skal levere nationale services til det telemedicinsk område, som det er nemt, sikkert og omkostningseffektivt at koble sig op på via lokale it-løsninger. Infrastrukturen vil tilbyde en række it-services, der tillader, at datadelingen kan foregå på en sikker og effektiv måde. Infrastrukturen vil endvidere introducere og implementere en række internationale itstandarder, der ikke tidligere har været i drift i Danmark. Infrastrukturen vil dermed på relevante områder styrke Danmarks position internationalt inden for sundheds-it. Sundhedsfaglig: Infrastrukturen vil medvirke til, at alle relevante sundhedsfaglige (og andre relevante personer) kan få sikker adgang til hjemmemonitoreringsdata på KOL 2 området. Adgangen skal sikre det bedste beslutnings- og monitoreringsgrundlag for alle involverede sundhedspersoner, borgeren selv og andre som borgeren ønsker at inddrage i behandling og pleje. 2.4 Den fremtidige situation efter indførelse af løsningen Efter gennemførelse af nærværende projekt, vil der på sundhedsområdet i Danmark være etableret en moden og velafprøvet national telemedicinsk it-infrastruktur. I den forbindelse vil andre relevante områder blive udviklet i det omfang det har relevans ift. telemedicinsk hjemmemonitorering. Fx har patientrapporterede oplysninger fra en række af de forudgående telemedicinske projekter været nævnt som en vigtig informationskilde for de sundhedsfaglige i sammenhæng med måledata i hjemmemonitorering af patienter med KOL. 2.5 Situationen hvis projektet ikke gennemføres (business as usual) Som nævnt ovenfor har analyser vist, at den nuværende telemedicinske infrastruktur vurderes at opfylde kravene på TRL-6. De nuværende løsninger vurderes således ikke at være modne til at kunne bære en fuld national udbredelse, idet: - der er risiko for, at infrastrukturen ikke indeholder de funktioner som leverandører på det telemedicinske område efterspørger for at kunne skabe brugervenlige og effektive it-værktøjer til sundhedsprofessionelle brugere - de nuværende løsninger ikke i fornødent omfang overholder nationale og internationale standarder, hvilket kan medvirke til at skabe et lukket dansk marked og dermed kan medvirke til at reducere den reelle konkurrence på markedet og mulighederne for at anskaffe standardløsninger - der er risiko for, at de nuværende løsninger ikke belastningsmæssigt kan holde til en national udbredelse med mange tusinde brugere og store mængder af data og derfor vil give kortere eller længere driftsudfald - og endelig fordi de fornødne sikkerhedsfunktioner endnu ikke er indarbejdet i løsningerne, hvilket gør det sikkerhedsmæssigt uforsvarligt at foretage udrulningen på nuværende infrastruktur. 2.6 Alternative løsningsscenarier Der er ikke afdækket alternative løsningsscenarier. 2 Infrastrukturen begrænses dog ikke til KOL området side 3 af 19

5 3 Scope og afgrænsninger Det samlede modningsprojekt opdeles i 8 delprojekter og opdeles i 4 projektfaser. Hver delprojekt har en entydig ansvarlig organisation, medens det konkrete udførende arbejde i delprojekterne kan være uddelegeret til andre organisationer/firmaer. Nedenstående figur viser det samlede projekts opdeling i delprojekter. Figur 1 - Opdeling i delprojekter med ansvarlige organisationer Tabel 1 - Områder som er ikke medtages i projektet. side 4 af 19

6 Afgrænsning Beskrivelse af afgrænsning Begrundelse for afgræsning Min-Log modning BRS modning Parternes indretning af dokumentdelingsdomæner Lokale opsamlingsplatforme Projektet er afhængig af en velfungerende udgave af den såkaldte Min-Log komponent på NSP. Servicen betragtes som værende moden og der planægges ikke yderligere modningstiltag i nærværende projekt Projektet er ligeledes afhængig af velfungerende udgave af Behandlingsrelationsservicen (BRS). Der er ikke afsat midler til modning af denne service i projektet. Nærværende projekt forholder sig ikke til den generelle opdeling og etablering af affinitetsdomæner, men fokuserer alene på modning af infrastruktur og tilhørende services og standarder, og skaber et sæt minimumsregler for affinitetsdomænet omkring KIH databasen. Der gennemføres ikke modningsaktiviteter på lokale opsamlingsenheder eller lokale opsamlingsplatforme. MinLog er allerede taget i brug af FMK programmet og er trykprøvet i MinLog1 projektet i 2014/2015. Det er endnu ikke afgjort hvorledes behandlingsrelationsservicen skal anvendes i dette projekt. Der optages derfor en risiko for, at servicen ikke har den fornødne modenhed til at imødekomme ønskerne for optimal anvendelse i nærværende projekt. Dette arbejde er allerede igangsat med SDS som tovholder. I de gennemførte store skala-afprøvninger (KIH og OpenTele) er der afprøvet to versioner af opsamlingsplatformen OpenTele. Den første blev vurderet til at være på TRL 7 niveau. Den anden version af OpenTele og de andre kommercielle opsamlingsplatformen på markedet vurderes som modne (TRL8). 4 Mål og succeskriterier Projektets mål Beskrivelse Succeskriterier 1. De nationale standarder modnet. (Delprojekt 1) 2. Dokumentdelingsservicen og samtykkeservicen på TRL 7 (Delprojekt 2) 3. Driftsoverdragelse af NSP services og nationalt indeks (delprojekt 7) Der skal etableres flere nationale standarder/profiler som parterne på blandt andet dokumentdelingsområdet fremadrettet skal benytte sig af. Dokumentdelingsservicen (DDS) og Samtykkeservicen skal modnes til TRL 7 inden sommer Sundhed.dk skal etablere en borgervendt brugergrænseflade til administrations af samtykker / frabedelse af indsigt. Dokumentdelings og samtykke services lægge i produktion via standard procedurerne for service publicering på NSP. Der gennemføres et udbud efter et nationalt indeks. Standarder udarbejdet, har gennemgået høring og indarbejdet i standardkataloget i endelig version. DDS og Samtykke kvalitetssikret og brugertestet i et laboratorie setup. Samtykke grænseflade tilgængelig på SDK s testmiljøer. Dokumentdelingsservice og samtykke service tilgængeligt i NSP produktionsmiljøer. Samtykke Gui publiceret på SDK s produktionsmiljøer side 5 af 19

7 Aftale med leverandør af indeks funktionalitet underskrevet. side 6 af 19

8 5 Økonomiske hovedtal og finansiering Finansiering er sikret gennem ØA16, hvori der er afsat 5. mio. kroner til projektaktiviteter i 2016 og 1,2 mio. til løbende drift af indeks og services ift. deling af data fra KIH databasen fra 2017 og frem. Som udgangspunkt dækker budgettet til det enkelte delprojekt udgifterne til de leverancer der er planlagt i det pågældende delprojekt. Nedenstående tabel giver en oversigt over udmøntningen af budgettet for SDS opgaver i 2016 fordelt på arbejdspakker i de 3 delprojekter SDS er ansvarlige for. Dertil skal lægges en post til generelle tværgående aktiviteter i form af bl.a. ekstern projektledelse på tværs af de 3 dele af det samlede modningsprojekt. Delprojekt / arbejdspakke Budget mio. kr. for arbejdspakker Budget mio. kr. for delprojekter Standarder og arkitektur 0,4 AP 1 - Nationale arkitekturleverancer som består af: 0,4 - IHE metadata-dk profil Dansk profil der specificerer hvorledes vi i Danmark specificerer metadata i de relevante internationale IHE profiler. - PHMR-DK profil Dansk profil af HL7 til kommunikation af telemedicinske målinger mv. - HL7 - Questionnaire profil Dansk profil af HL7 questionnaires - OID vejledning Opfølgning på guide/regler/principper OID for dansk anvendelse ifm. HL7/IHE - Lokale domæneregler for Telemedicin domænet Opstilling af de regler der skal gælde for anvendelse, dokumenttyper, metadata etc. i det telemedicinske domæne. Underlagt de nationale domæne regler som defineres mellem parterne eksternt for projektet 3 - Arkitekturbeslutninger ift. KIH tilpasninger Fastlæggelse af de ændringer man ønsker at foretage på KIH databasen for at bringe den i overenstemmelse med anbefalingerne fra review. 3 IHE wiki: An XDS Affinity Domain is a group of healthcare enterprises that have agreed to work together using a common set of policies and share a common infrastructure side 7 af 19

9 Delprojekt / arbejdspakke Budget mio. kr. for arbejdspakker Budget mio. kr. for delprojekter Delprojekt 2- NSP teknisk modning 2,45 AP 2 Performancetests NSP 0,6 Dokumenteret og godkendt peformancetest af NSP services med opkobling til et XDS repository AP 3 NSP udviklingsaktiviteter 0,6 Tilpasninger på basis af fund efter performance test og review implementeret AP 4 Brugerhistorier og analyser som består af: 0,44 Desk research efter brugerhistorier der danner grundlag for interviews med 5 basale usecases Interviews og efterfølgende analyse af disse der danner grundlaget for en første workshop med de sundhedsprofessionelle. Workshop med sundhedsprofessionelle hvor de kvalificerede usecases gennemgås og bearbejdes. Dette danner grundlaget for en afsluttende workshop, hvor både de sundhedsprofessionelle og deltagende leverandører deltager. Arbejdet udføres af 2 medarbejdere fra Alexandra Instituttet. Workshoppen forventes afholdt ultimo april/primo maj i colab i Odense. AP 5 Samtykke GUI (SDK) 0,61 Der udarbejdes et brugerinterface på Sundhed.dk (SDK) til Samtykke servicen i 3 iterationer, der sætter os i stand til at gennemføre brugertest før sommer. Arbejdet gennemføres ved at hyre eksterne udviklere til at arbejde på SDK s platform. Hen over sommer er det forventningen, at SDK selv færdiggør brugerfladen og produktionsmodner den endeligt. side 8 af 19

10 Delprojekt / arbejdspakke AP 6 Anvender integration & brugertest Budget mio. kr. for arbejdspakker 0,2 Budget mio. kr. for delprojekter Denne arbejdspakke skal levere hele aftalegrundlaget for piloten og indledende brugertest. Målet er en pilot i en kommune med deltagelse af en afdeling fra regionen og deltagelse af 1-2 praktiserende læger. Patientkategorien er KOL patienter, der hjemmemonitorerer og man skal sammen fastlægge et scope (antal patienter, antal brugere, varigheden af piloten). Det indebærer afklaringer af mulige kandidater ift. at deltage som pilot, indgåelse af aftaler, klarlæggelse af scope for pilot, samt indgåelse af aftaler med leverandørerne der skal deltage i pilotområdet. Kommuner i Region Sjælland og Region Hovedstaden er udelukket pga. travlhed i de to regioner med sundhedsplatformen. SDS har indledende dialog over noget tid med Frederikshavns kommune, Horsens Kommune og Langeland Kommune. Intet er afgjort, men det virker mest realistisk at få et pilotområde op at køre i Frederikshavn. Denne arbejdspakke skal også forberede og gennemføre de nødvendige brugertest og opstarte leverandørernes integrationer til Dokumentdelings servicen. Brugertest forventes afviklet i juni måned, men tidsplanen er ambitiøs, så der er ikke meget der skal gå galt før brugertest først kan gennemføres efter sommer. Finansieringen til selve anvender-integrationen hentes fra arbejdspakkerne i Medcoms del af projektet (AP 10,11, og 12). Delprojekt 7 - driftsoverdragelse NSP 0,9 AP 15 Indeks udbud 0,8 Der skal etableres en ny indeks-komponent fra , hvor aftalen om det nuværende indeks udløber. Denne kan skaffes enten via et udbud, via leasing under eksisterende driftsaftaler eller ved at en region stiller indeks funktionalitet til rådighed. Estimatet er lavet ud fra situationen hvor man gennemfører et udbud. side 9 af 19

11 Delprojekt / arbejdspakke AP 16 Connectathon Budget mio. kr. for arbejdspakker 0,1 Budget mio. kr. for delprojekter Som en del af afslutningen af projektet og verifikation af modenheden foreslås det, at de deltagende leverandører af integrationer og selve infrastrukturen tager på Connecthaton efter piloten. Der er connecthatons i januar i USA og i april i Europa. Estimatet dækker kun den hjemlige forberedelse, og ikke selve deltagelsen den vil skulle brugerfinansieres. AP 17 Projektafslutning 0 Afslutningen af projektet og overgang til udbredelse er en meget vigtig proces, hvor efterspørgslen på certificerede løsninger vil være afgørende for at leverandørerne vil gå ind i udbredelsesprocessen. Teknisk projektledelse (frem til sommer 2016) 0,6 0,6 Rejser, mødeforplejning, workshops 0,1 0,1 I alt for SDS-relaterede aktiviteter 4,45 4,45 Buffer 0,55 0,55 6 Gevinster Da det er et forudsætningsprojekt, der leverer produkter til anvendelse for landsdelsprogrammerne er der ikke foretaget gevinstestimeringer koblet til infrastrukturprojektets aktiviteter. side 10 af 19

12 7 Teknisk løsning Den tekniske løsning består af services på den nationale serviceplatform som udstilles på Sundhedsdatanettet, af et underliggende indeks samt et repository til hjemmemonitorerings data og PRO skemaer (KIH databasen). Endelig vil man i projektet integrer fra mindst et fagsystem fra hver sektor til denne infrastruktur. Figur 2 - Scope for modningsprojektes del 1 & Markedsundersøgelse Forudsætningerne for projektet er, at der skal ske en modning af den eksisterende telemedicinske infrastruktur. Der skal derfor ikke ske anskaffelser, der fordrer særlig afdækning af markedsløsninger. Leverandører inddrages i pilotafprøvning for bl.a. at sikre sammenhæng til markedsløsninger, ligesom der sker en begrænset afdækning af forretningsbehov i forbindelse med gennemførelse af modningsprojektet. 7.2 Teknisk løsning Den del af den telemedicinske infrastruktur som modnes i projektet er illustreret med grønt i figur 2. Adgangen fra fagsystemerne til data fra KIH databasen tænkes standardiseret i henhold til reference arkitekturen ved at til dataadgangen sker via services på den nationale serviceplatform. Det er en enkelt service (Dokumentdeling) fagsystemerne skal koble op til, hvorefter de får adgang til de repositories der er koblet op dokumentdelingsservicen. side 11 af 19

13 I del 2 af projektet modnes KIH-databasen, som kommer til at indeholde målingsdata fra borgerne samt besvarede PRO spørgeskemaer. Infrastrukturen er indifferent ift. hvilken opsamlingsplatform man vælger, blot den overholder snitfladestandarderne, der er fastlagt i referencearkitekturen for opsamling af helbredsdata 4. En konkretisering af referencearkitekturerne fremgår af figur 3, hvor et skematisk flow af data fra måleenheden i borgerens hjem til et givent fagsystem, når referencearkitekturerne overholdes illustreres. I figuren er de opsamlingsplatforme som kendes i Danmark i dag medtaget samt de eksisterende elementer af referencearkitekturen for deling af dokumenter og billeder (KIH og NSP) og disses danske profileringer. Figur 3 Oversigt over services og sammenhænge i den telemedicinske infrastruktur. Standarder for flow af data fra måleudstyr til anvendersystem/snitfladestandarderne fremgår nederst i figuren. 7.3 Integrationer De tekniske krav til integrationer fra anvendersystemer til dokumentdelings servicen, fremgår af dokumentation af dokumentdelings servicen som kan findes via nedenstående link: Test Se beskrivelsen af arbejdspakkerne afsnit side 12 af 19

14 8 Leverancer Projektets processer følger statens it-projektmodel/prince2 dog tilpasset projektets omfang og budget. Konkret betyder det: - at projektet ledes af en projektleder og forankres i en styregruppe - at projektet ledes med udgangspunkt i Projektinitieringsdokumenter (PID) der godkendes af styregruppen i forbindelse med projektinitiering. - at styregruppen har det formelle ansvar for fremdrift, risikohåndtering og kvalitet i projektet og skal sørge for eskalation over projektniveau. - at der som udgangspunkt kun afvigelsesrapporteres baseret på fastlagte tolerancer for afvigelse i tid, budget, omfang, risiko og kvalitet. 8.1 Leverancer og afhængigheder Se bilag 1 tidsplan og den overordnede beskrivelse af arbejdspakkerne i afsnit 5. 9 Organisering 9.1 Projektorganisation Nærværende projekt er en del af en større portefølje under ledelse af den Fællesoffentlige porteføljestyregruppen for landsdækkende udbredelse af telemedicin. Porteføljestyregruppen har regionalt/kommunalt formandskab. side 13 af 19

15 Sundhedsdatastyrelsen er ansvarlige for delprojekterne 1,2 & 7 og de tilhørende leverancer. Medcom er ansvarlige for leverancer fra delprojekt 3 til og med 6. Region Midt er ansvarlig for leverancer fra delprojekt Styregruppe Styregruppen ledes af Sundhedsdatastyrelsen og besættes jf. kommissoriet for styregruppen. Styregruppen sekretariatsbetjenes af Sundhedsdatastyrelsen. Styregruppen for det samlede modningsprojekt fungerer også som styregruppe for de enkelte delprojekter. side 14 af 19

16 9.3 Projektleder og projektgruppe Figur 4 - Forslag til projektorganisering 10 Tidsplan [Henvisning til tidsplan i bilag, men overordnede milepæle bør skrives ind her] 11 Kvalitet Som udgangspunkt udsættes alle leverancer for review (uformelt review, peer review eller egentlig høring) for at produkterne kan godkendes af styregruppen. Hvilke kvalitetssikringstiltag, der er er tale om, afhænger af vigtigheden og rækkevidden af produktet, dvs. i hvor høj grad produktet har indflydelse på projektet, løsningen eller på hele løsningsområdet som sådan. Leverancer klassificeres således: Klasse I leverancer: Meget vigtige og langtrækkende produkter, der både påvirker projektet, projektets leverancer og løsningsområdet som sådan, f.eks. beslutning om sammensætning af national infrastruktur, ændring i domæneinddeling eller lignende. Disse produkter bør undergå peer review og høring blandt væsentlige interessenter og/eller inddragelse af relevante råd og organer. Klasse II leverancer: Vigtige leverancer med nogen rækkevidde, der påvirker projektet og projektets leverancer, side 15 af 19

17 f.eks. løsningsspecifikke arkitekturbeslutninger. Disse produkter skal undergå peer review, dvs. review hos peers, der ikke har medvirket til udfærdigelse af det pågældende produkt. Klasse III leverancer: Leverancer med lille rækkevidde, der muligvis påvirker projektet, men ikke projektets produkter, f.eks. ledelsesprodukter eller lignende. Disse produkter bør undergå uformelt review (korrekturlæsning) Kvalitetsplanlægning leverance Klassifikation Kvalitetstiltag IHE metadata-dk profil I Review+Høring HL7 PHMR-DK profil I Review+Høring HL7 Questionnaires I Review+Høring OID vejledning Katalog med telemedicinske bruger historier Arkitekturbeslutninger Lokale domæneregler DDS og NSP Samtykkeservice i endelig idriftsat version Samtykke brugergrænseflade. Udbud af national dokumentdelingsindeks Performancestrategi og performancetestplan Performancetestrapport II II I II I I II III III Peer Review Peer Review og workshops Peer review og godkendelse hos arkitekturfunktioner Peer review Kvalitetssikring hos NSP operatør Testes gennem pilotdriften Peer review Review Review 11.2 Kvalitetskontrol og kvalitetssikring Det er projektlederens ansvar at sikre, at alle leverancer gennemgår den fornødne kvalitetssikring. Dette sikres gennem hyppige opfølgninger på projektets fremdrift og status på leverancernes kvalitetssikring. Det er styregruppens ansvar at afvise leverancer, der ikke har gennemgået den fornødne kvalitetssikring. Specielt ift. brugerhistorierne i AP 4 brugerhistorier og analyser vil der bliver stor vægt på at de brugere der interviewes og/eller deltager i workshops har så bred en erfaringsgrundlag som muligt. Her er det afgørende at landsdelsprogrammerne spiller ind med medarbejdere er både har indsigt og mandat til at være med til at foretage kvalitetssikringen og afgrænsningen. 12 Risici Det er projektlederens ansvar at vedligeholde en risikolog (risikoregister) gennem hele projektforløbet. Risikologgen opdateres som udgangspunkt hver 14. dag. side 16 af 19

18 Projektets overordnede risikoprofil er HØJ / RØD. Der er adskillige risici, der vurderes både at være meget sandsynlige og have ganske store konsekvenser for projektet og projektets leverancer. Her nævnes de væsentligste: 1. Det kan vise sig vanskelligt for projektet at finde pilotafprøvningspartnere blandt klinikere og dermed afledt hos leverandører. Dette vil i bedste fald medføre forsinkelser i projektet, i værste fald at man helt må opgive pilotafprøvningen, hvormed det ikke bliver muligt at opnå TRL Der er i Danmark endnu ikke foretaget storskala-afprøvninger på anvendelse af IHE dokumenter som grundlag for deling af telemedicinske data. Der er således en risiko for at parterne i projektet finder, at andre og bedre integrationsmønstre bør anvendes, hvilket kan ændre på omfanget af nærværende projekt. 3. Der er en stor afhængighed mellem modningen af telemedicinsk infrastruktur og de fem landsdelsprogrammer. Tidsplanen for infrastrukturprojektet fordrer en acceleret proces frem mod ultimo Dette udfordrer derfor hvorvidt de enkelte landdelsprogrammers tidsplaner, ønsker og behov når at blive fastlagt og inkluderet i modningsprojektet. Dette vil betyde at der efterfølgende (efter 2016) vil kunne opstå behov og krav hos de enkelte landsdelsprogrammer der ikke tidligere i processen har været klarlagt og udtrykt. Den vil blive udarbejdet en endelig risikoanalyse som vil blive eftersendt til styregruppen 13 Kommunikation Da projektet er en del af en større portefølje, udfærdiges der ikke en egentlig kommunikationsplan for projektet. Det overlades til porteføljesekretariatet at udfærdige den overordnede kommunikationsplan for at sikre tilfredsstillende kommunikation med de væsentligste interessenter. Projektet har dog særlig fokus på at 1) nuværende og kommende leverandører på telemedicinsområdet og 2) parternes it-arkitekturråd. Begge disse interessenter involveres i nærværende projekt gennem direkte aktivitet (leverandører udfører aktiviteter der ledes af projektet og parternes it-arkitekturråd kan få plads i den rådgivende arkitekturgruppe under styregruppen). Desuden er der stærkt fokus på koordinering med landsdelsprogrammerne, bl.a. etableres der formel kontakt til den/de netværksgrupper som nedsættes ifm. landsdelsprogrammerne. 14 Tolerancer Projektet afvigelsesledes med følgende tolerancer: - Tid: 5% Projektleden eskalerer til styregruppen såfremt der er tegn på overskridelse på 5% af fasens/sporets afslutningstidspunkt. - Økonomi: 5% Projektleden eskalerer til styregruppen såfremt der er tegn på overskridelse på 5% af fasens/sporets budget. Evt. overskud fra tidligere faser må ikke uden styregruppens godkendelse indregnes i en fases budget. - Kvalitet: Nul-tolerance Projektlederen skal eskalere til styregruppen øjeblikkeligt, såfremt der ses tegn på ne- side 17 af 19

19 gativt skred i kvalitet af de planlagte produkter/leverancer. [Der udestår specificering af kvalitetsmål i afsnit 11.1/11.2 som er forudsætning for nul-tolerance ift. kvalitet] - Risici: Risikoværdi >= 15 Risikoværdien beregnes som sandsynlighed x konsekvens, hvor hver af disse vurderes på en 1-5 skala (5 højest). Alle identificerede risici, hvor risikoværdien er større end eller lig 15 skal øjeblikkeligt eskaleres til styregruppen, med indstilling om risikoaktion (modforanstaltning, reduktion, overdragelse, nødplan eller lignende) og evt. en indstilling om hvilket styregruppemedlem, der skal være ejer af risikoen, og dermed have ansvaret for at følge denne risiko på et styringsniveau. 15 Rapporteringskrav Der rapporteres løbende til projektets styregruppe. Rapportering til porteføljestyregruppen fastlægges når kravene fra porteføljeledelsen tilgår. 16 Revisionshistorik Revisionsdato Version Ændringer Ændringer markeret? Forfatter Udkast til samlet PID (lettere reduceret) Input fra JAP og ILP indarbejdet Input fra mødet mellem SDS og Medcom indarbejdet Tilpasset leverance numre ift. tilpasset gant Omlagt til SUM skabelon og tilrettet ift. revideret tidsplan Gennemskrevet efter ny opgave opdeling og navngivning. 17 Bilag Nej Ja Ja Ja Nej Nej Bilag 4.1: Udkast til projektplan for det samlede projekt Bilag 4.2: Foreløbig risikoanalyse (risikoregister) (eftersendes) Bilag 4.3: Opsummering af aktiviteter i AP 4 Beskrivelse af brugerhistorier JRI JRI JRI ILP ILP ILP side 18 af 19