Projektinitieringsdokument (PID) [ Min læge -app] [ ]

Transkript

1 Projektinitieringsdokument (PID) [ Min læge -app] [ ]

2 Indhold 1 STAMDATA FORMÅL MED PROJEKTET AFGRÆNSNING MÅL OG SUCCESKRITERIER BUDGET EVALUERING OG GEVINSTER TEKNISK LØSNING ORGANISERING TIDS- OG MILEPÆLSPLAN LEVERANCER KVALITET RISICI INTERESSENTER KOMMUNIKATION INFORMATIONSSIKKERHED OVERDRAGELSE FRA PROJEKT TIL DRIFT TOLERANCER REVISIONSHISTORIK BILAG

3 Forord inden udfyldelse af PID Som udgangspunkt skal alle punkter udfyldes i PID en. Det er intentionen, at PID en skal beskrive projektet bredt samt give projektlederen mulighed for at se projektet fra flere forskellige perspektiver. Der kan være punkter, som ikke er relevante for alle projekter. Hvis der er et eller flere punkter, som ikke er relevante for det aktuelle projekt, så notér begrundelsen under punktet i PID en. Lad være med at opfinde emner, der tilpasser projektet til PID en. Når PID en godkendes er der sikkerhed for grundige overvejelser omkring projektet inden igangsættelse. 2

4 1 Stamdata Stamdata Projektnavn Min læge -app (version 1) Projektleder Projektets primære formål Martin Bagger Brandt (assisteret af Mikkel Schou-Nielsen) At udvikle og lancere en app, som understøtter dialog og koordinering mellem praktiserende læge og patient. 2 Formål med projektet 2.1 Den nuværende situation (baggrund) De fleste læger tilbyder i dag deres patienter mulighed for tidsbestilling og e-konsultation på deres hjemmeside. Hjemmesidens funktioner afhænger af, hvad den enkelte læges systemhus udbyder. Nogle systemhuse tilbyder en app til patienterne, men hovedparten gør ikke. Samlet set har det mobile område ikke været højt prioriteret i digitaliseringen af almen praksis. I rapporten Digital Almen Praksis beskrives den nuværende situation således 1 : Patienter kan tilgå den almene praksis gennem et website, som den enkelte klinik har oprettet og vedligeholder. Websitets layout og funktionalitet varierer afhængigt af klinikkens praksissystem og klinikkens specifikke konfigurationsvalg. Der logges på de enkelte løsninger med websitespecifikke passwords, og der benyttes således ikke NemID. For en del websites gælder det desuden, at login er personafhængigt, hvilket medfører, at forældre skal oprette og administrere særskilte login og passwords for deres børn. Enkelte praksissystemer tilbyder også adgang til websitets funktioner via en mobilløsning. 2.2 Formålet med projektets løsning Formålet med projektet er at understøtte den nære dialog og koordinering mellem den praktiserende læge og patienten digitalt, så patienten bliver mere selvhjulpen og får mindre behov for at konsultere lægen i klinikken eller via telefon. Hensigten er at give patienterne (særligt målgrupperne hverdagssyge og børnefamilier ) 2 et ensartet mobilt tilbud på tværs af lægehuse og disses systemhuse via én mobil app. De tilbud, som i varierende grad og form er tilgængelige via lægehusenes hjemmesider, stilles til rådighed for patienterne på en mobil og tidssvarende måde, uafhængigt af lægernes leverandørvalg. 2.3 Projektets bidrag til strategiske mål Projektet bidrager direkte til 3 af de 5 mål i Strategi for Digital Sundhed : #1: Borgeren som aktiv partner, #2: Viden til tiden, og #4: Tillid og sikkerhed om data. Projektet er skrevet ind i strategien som en konkret indsats under overskriften Lægen i lommen 4. Denne indsats beskrives således: De praktiserende læger tilbyder i dag e-konsultationer og tidsbestilling via deres hjemmesider, men løsningerne varierer fra læge til læge, og der er gode muligheder for at udbygge med ny funktionalitet. Med en fælles app til almen praksis bygges der oven på de eksisterende løsninger i en ny digital kanal til kommunikation med egen læge, så borgerne uanset hvilken praktiserende læge de har har let og fleksibel adgang til tidsbestilling, receptfornyelse og e- konsultationer med almen praksis. App en vil kunne hjælpe med bl.a. påmindelser om medicin 1 Digital Almen Praksis 2017, side Disse defineres i Digital Almen Praksis 2017, side Se Strategi for Digital Sundhed 2018, side 18. Se også side 4 Ibid, side 26. 3

5 og vaccinationer og med funktioner som fx videokonsultationer og mulighed for at sende billeder. Kun en delmængde af de nævnte funktioner indgår i version 1 af app en. Øvrige funktioner planlægges til senere versioner. 2.4 Den fremtidige situation efter indførelse af løsningen Patienter, der kan betjene sig selv, har nem og fleksibel adgang til egen læge gennem en mobil app. Patienten kan skrive til klinikken, bestille tid, receptforny, uploade ordinerede hjemmemålinger og har overblik over egen status hos lægen. Klinikken kan gennem app en kommunikere ukomplicerede svar, skrive til patienten, stille patienten spørgsmål, ordinere hjemmemålinger, tilbyde videokonsultation og notificere patienten efter behov, enten automatisk eller manuelt. Herudover har patienten adgang til nationale egne sundhedsdata fx FMK, Vaccinationsregistret m.m. Almen praksis oplever færre telefoniske henvendelser og fysiske konsultationer fra de selvhjulpne patienter. Samtidigt hermed er der mindre behov for at almen praksis aktivt skal kontakte de selvhjulpne patienter, da disse har et godt overblik over egen situation. Det er forventningen, at første version af app en lanceres i december Det må dog påregnes, at 2019 skal bruges til fuld udbredelse. Dermed vil app en forventeligt først være tilgængelig for hovedparten af landets borgere i løbet af Første version vil indeholde funktioner, som nogenlunde svarer til de eksisterende funktioner på lægernes hjemmesider. I version 2 (som efter planen udvikles i 2019) vil introducere funktioner, som aktuelt ikke er tilgængelige for patienterne. Herunder nogle af de funktioner, som nævnes i slutningen af afsnit 2.3. Før- og efterbilledet kan visualiseres således: Pointen med figuren er, at visse systemhuse aktuelt udbyder hjemmesider (og evt. app eller mobil udgave af hjemmesiden), som indeholder hhv. rigere og ringere funktionalitet end app en i version 1. Dette er et nødvendigt ambitionsniveau, hvis vi skal have en realistisk chance for lancering i december App en i version 2 kan bygge oven på denne baseline, og dermed introducere funktioner, som patienterne ikke aktuelt har adgang til. I løbet af 2019 vil dette medføre et behov for at at overveje det samlede kanaludbud til patienterne. 2.5 Situationen hvis projektet ikke gennemføres (business as usual) Hvis projektet ikke gennemføres, vil nogle læger (og deres respektive systemhuse) opretholde den begrænsede mobile understøttelse, som findes i dag. Andre systemhuse vil forventeligt på egen hånd opruste på app s og mobile/responsive løsninger. På sigt vil hovedparten af patienterne i kraft af markedsmæssig udvikling og konkurrence forventeligt få adgang til en app eller 4

6 en responsiv udgave af lægens hjemmeside. Kvalitet og tidsperspektiver i dette vil afhænge af konkurrencen mellem leverandørerne. 2.6 Alternative løsningsscenarier Alternativ 1 ( 0-scenariet ): Man kunne lade udviklingen afhænge af lægernes efterspørgsel og leverandørernes konkurrence, og blande sig helt udenom, jf. afsnit 2.5. Alternativ 2: Man kan udarbejde en fælles kravspecifikation, og så formidle en funktionel bestilling til alle leverandører. Sådan at de hver især udvikler deres egen app med saltvandsindsprøjtning i form af delvis PLO-baseret og offentlig betaling. Som alternativ til at lave en fælles app baseret på en fælles infrastruktur på tværs af leverandørerne. 3 Afgrænsning Det skal afklares i regi af projektets styregruppe, om udrulningen til de enkelte systemhuse skal anses som en del af etableringsprojektet, eller om der skal defineres et selvstændigt udbredelsesprojekt i 2. halvdel af 2018 og i Følgende funktioner, nævnt i Stategi for Digital Sundhed 2018, vil ikke indgå i v1: App en vil kunne hjælpe med bl.a. påmindelser om medicin og vaccinationer og med funktioner som fx videokonsultationer og mulighed for at sende billeder. Disse funktioner vil formentlig indgå i v2 (dette er endnu ikke klarlagt). En afgrænsning af v1 s funktionalitet er nærmere beskrevet i specifikation for app og plsp v1. Se denne vedlagt som bilag 1. 4 Mål og succeskriterier Projektets mål Beskrivelse Succeskriterier 1. App-kontrakt v1 Det er planen, at indgå kontrakt med app-leverandør efter konkurrencepræget dialog. 2. Lancering af app v1 Det er planen, at første udgave af app en lanceres i december Systemhusenes opkobling Alle systemhuse, som er partnere i PLSP A/S skal koble op til den kommende snitflade på PLSP. 4. Download af app Vi kan/skal beslutte et ambitionsniveau for antal downloads af app en. Fx i juni 2019 og igen i december Patienternes tilfredshed Vi kan/skal beslutte et ambitionsniveau for rating af app en i relevante app-stores på givne tidspunkter. 6. Lægernes tilfredshed Vi kan/skal beslutte en metode til at vurdere, om lægerne er tilfredse med app en på givne tidspunkter. At kontrakten er indgået senest i juni At v1 af app en er lanceret senest i december At alle systemhuse er koblet op på et givet tidspunkt. At antal downloads er # i juni 2019 og ## i december At app en opnår # stjerner i Apple Appstore og ## stjerne i Google Play. Og holder dette niveau. At lægerne på forespørgsel tilkendegiver en tilfredshed på et givet niveau på et givet tidspunkt. 5

7 5 Budget Hermed overordnet budgetramme for den samlede projekt; Fra anskaffelse og etablering år 1 og 2 og efterfølgende vedligeholdelse fra år 2 og frem. Tabel 1 viser de opstillede estimater og fordelingen af finansieringen mellem SUM og PLO. Tabel 1 Etablering år 1 og 2 Drift, år 2 og frem (vedligehold/support/videreudvikling) Min læge (frontend) PLSP struktur National infrastruktur LPS og øvrige kilder til opkobling til datadeling 6

8 7

9 6 Evaluering og gevinster 6.1 Strategi for gevinstrealisering / Effektiviseringsgevinster Evaluering af projektet vil følge de beskrevne milepæle i tidsplanen, således forstået, at der følges op på hvorvidt milepælene nås, og hvis ikke, hvordan det ved korrigerende handlinger vil kunne lykkes at nå de enkelte milepæle. Gevinstrealisering og effektiviseringsgevinst vil være i form af øget kvalitet og mange flere patienter, der bliver mere selvhjulpne og med meget fleksibel adgang til almen praksis og egne sundhedsdata gennem en app - lige ved hånden. Personalet i praksis vil med ganske få klik kunne kommunikere fx ukomplicerede prøvesvar på en enkelt og for patienten forståelig måde, så yderligere nødvendig kontakt mellem patient og praksis bliver holdt på et minimum. Klinikken kan bestille hjemmemålinger hos patienten, der så kan uploade hjemmemålinger, som registres i lægens journal. Dette er principper, som vil gøre de mere ukomplicerede konsultationer digitale og asynkrone i stedet for den traditionelle konsultation, der er helt face to face i klinikken eller via telefon. Det skal overvejes, om man ønsker at måle om brugen af app en giver færre opkald til klinikken og mindre behov for, at klinikken kontakter patienterne direkte og i stedet notificerer patienten gennem app en. Alternativt laves en spørgeskemaundersøgelse blandt patienter og læger, som måler patienternes og lægens oplevelse af den implementerede løsning. Et andet alternativ kunne være at måle brugen af app en indirekte gennem den tekniske anvendelse af kommunikationslagene mellem app en og de enkelte praksis. 6.2 Økonomisk gevinst Der forventes principielt ikke økonomiske gevinster i dette projekt. Dog kan der blive tale om frigivelse af tid i almen praksis, som kan bruges til andre opgaver. Der er ikke udarbejdet businesscase på projektet 6.3 Kvalitetsløft og ikke-økonomiske gevinster Projektet forventes at give et kvalitets- og serviceløft for både patienten og almen praksis. Uanset hvilken læge en patient henvender sig til, vil patienten opleve en ensartet og samlende kommunikationskanal i forhold til almen praksis, hvor patienten i modsætning hertil i dag oplever forskellige digitale indgange, afhængigt af hvilken klinik patienten skal have fat i eller hvilke funktioner og oplysninger, der ønskes adgang til. Tilsvarende forventes klinikkerne også at kunne høste den gevinst efter den første indkøringsperiode at spare tid på unødvendige kontakter (fx besvarelse af opkald vedr. genbestilling af i forvejen gyldige henvisninger) og i stedet bruge den tid på de patienter, der møder op i klinikken og ikke kan benytte den nye teknologi/kanal. I Deloitte-rapporten omtales disse to gevinster for hhv. de digitaliseringsparate patienter og lægerne på denne måde: Gevinsterne ved denne løsning er primært for de patienter, der kan betjene sig selv. De får en mere fleksibel adgang til almen praksis og egne sundhedsdata. Upload af måleresultater indebærer både kvalitetsmæssige og behandlingsmæssige fordele for både patienten og klinikken. Henvendelser om fornyelse af recepter, spørgsmål til ukomplicerede prøvesvar og inddatering af måleresultater forventes reduceret, hvilket vil frigøre tid i klinikken. (kilde: Digital almen praksis side 66) 7 Konceptuel løsningsbeskrivelse Løsningen kan konceptuelt visualiseres således: 8

10 Der etableres en app-løsning (en native app til ios og en native app til Android), baseret på en fælles serviceplatform, som etableres af primærsektorens leverandører i fællesskab. Mere specifikt de leverandører, som indgår som partnere i PLSP A/S. Der er udarbejdet udkast til app-specifikation og datamæssig specifikation af PLSP snitflader, som nærmere definerer det løsningsmæssige set-up. Disse vedlægges som bilag 1 og 2. App en baseres endvidere på forretnings- og registerservices fra NSP. Den vil mere specifikt udnytte eksisterende services til NemID/eMobility, Medicinkort, CPR-register og Yderregister. Der vil formentlig være brug for tilpasning af de eksisterende snitflader. Dette skal aftales nærmere mellem projektets parter. Der er lavet en første vurdering af, hvilke nationale services, app en kan trække på. Denne vedlægges som bilag Test Endnu ikke beskrevet. [Beskriv overordnet strategi for test, herunder brugerinddragelse af projektets løsning.] 8 Organisering 8.1 Projektorganisation Projektorganiseringen ser således ud i overblik: 9

11 I det følgende beskrives roller og bemanding for de enkelte instanser i organiseringen. 10

12 Programstyregruppe App-projektet er forankret under programstyregruppen for Digital Almen Praksis som hører til i Medcoms arbejdsprogram for Sundhedsministeriet har formandskabet i programstyregruppen (v. Nanna Skovgaard), og MedCom er ansvarlig for programledelse (v. Tom Høg Sørensen). Yderligere information om programmet og rapporten vedr. Digital Almen Praksis findes via nedenstående links. Link: Program for Digital Almen Praksis (MedCom) Link: Rapport om fremtidens digitale lægepraksis PLO s It- og Dataudvalg PLO s It- og Dataudvalg varetager det lægefaglige kundeperspektiv ift. (1) app en funktionelle indhold, samt (2) de forhold som vedrører datasikkerhed og fortrolighed i app en og den underliggende infrastruktur. Trine Jeppesen og Niels Ulrich Holm fra udvalget indgår i projektstyregruppen og projektgruppen efter behov. Link: Oversigt over medlemmer i PLO s It- og Dataudvalg Projektstyregruppe Der er etableret en dedikeret projektstyregruppe for app-projektet, hvor både PLO, Sundhedsministeriet, Sundhedsdatastyrelsen og MedCom er repræsenteret. Formandskabet varetages af PLO s direktør Jonatan Schloss. Fra Sundhedsministeriet og Sundhedsdatastyrelsen deltager Kontorchef Nanna Skovgaard, Stine Sønderby Bonde og Anders Brahms. Fra MedCom deltager programleder Tom Høg Sørensen. De nævnte medlemmer fra It- og Dataudvalget indgår efter behov. Jørgen Granborg indgår som repræsentant for PL-forum og PLSP. Projektgruppe PLO er ansvarlig for projektledelsen v. Martin Bagger Brandt og ekstern konsulent Mikkel Schou-Nielsen. Endvidere deltager ekstern konsulent Lene Ærbo som projektleder for Sundhedsministeriet og Sundhedsdatastyrelsen (SDS). Muligvis vil endnu en deltager fra SDS blive udpeget til projektgruppen. De nævnte medlemmer fra It- og Dataudvalget indgår efter behov. Jørgen Granborg indgår som repræsentant for PL-forum og PLSP. 9 Tids- og milepælsplan Nedenfor opsummeres de mest væsentlige milepæle i projektet. Bemærk, at der kun angives deadline for milepælens indfrielse. Starttidspunkter og udstrækning for projektets aktiviteter fremgår af tidsplan under næste afsnit. 9.1 Milepælsplan De centrale milepæle i tidsplanen er følgende: ID Milepæle Deadline M1 Godkendelse af scope for Min læge -app v M2 Projekt- og finansieringsgrundlag på plads M3 Teknisk og forvaltningsmæssig afklaring vedr. PLSP M4 Teknisk og forvaltningsmæssig afklaring vedr. nationale services M5 Konkurrence, valg og kontrakt med leverandør(-er) til app en M6 Agil specificering, udvikling og dokumentation af PLSP

13 M7 Integration, tilpasning og test ift. relevante nationale services M8 Agil specificering, udvikling og dokumentation af app v M9 Test, dokumentation og godkendelse af app v M10 Release af app v1 på relevante platforme M11 Lancering og kommunikation Bemærk: M1-M7 er allerede tidsmæssigt udfordret. Hvis disse milepæle ikke holder, kan vi hurtigt stå i en situation, hvor den samlede tidsplan ikke holder. 9.2 Tidsplan Milepælsplanen kan give indtryk af en meget trinvis og opdelt fremgangsmåde. Imidlertid kan det tydeligt ses af den mere detaljerede tidsplan, at der arbejdes parallelt med en række aktiviteter, som er nødt til at foregå samtidig. Link til tidsplan (smartsheet) 10 Leverancer 10.1 Hovedleverancer og afhængigheder ID Leverance Bekrivelse Leveringstidspunkt Afhængigheder 1.1 Kontrakt med PLSP A/S En kontrakt som bærer bestillingen af PLSP-udvikling til app v1 1.2 Konkurrencegrundlag Relevante specifikationer og snitfladebeskrivelser til app, PLSP og NSP. Herunder også brugerhistorier og prototype. 1.3 Kontrakt med app-leverandør En kontrakt som bærer bestillingen af app-udviklingen (ios og Android). 2.1 PLSP-snitflade mod app Den snitflade som formidler data og forespørgsler mellem (test) PLSP og app'en. 2.2 PLSP-snitflade mod app En driftsmoden udgave af 2.1, som er tilgængelig i produktion (produktion) 2.3 PLSP-snitflade mod lægesystem Den snitflade som formidler data og forespørgsler mellem (test) PLSP og lægesystemerne. 2.4 PLSP-snitflade mod lægesystem (produktion) En driftsmoden udgave af 2.3, som er tilgængelig i produktion , 4.1, Nationale services tilgængelige Den snitflade som formidler data og forespørgsler mellem for app NSP og app'en. Evt. via PLSP-proxy. 3.1 "Min læge"-app (ios v1) Selve app-leverancen til ios Alle 3.2 "Min læge"-app (Android v1) 4.1 Udrulning 1: Lægesystemer Udrulning 2: Lægesystemer 6-# Selve app-leverancen til Android Alle Udrulning til fire systemhuse Udrulning til yderligere # systemhuse Der er udarbejdet en mere udtømmende beskrivelse af leverancer og resultater i første halvår Denne er vedlagt som bilag 4. Endvidere er udarbejdet brugerhistorier for app ens funktionalitet i v1. Der er også udarbejdet en prototype til app en. Den er endnu ikke fuldt synkroniseret med brugerhistorierne. 12

14 11 Kvalitet Endnu ikke beskrevet Kvalitetsplanlægning [Beskriv projektets kvalitetskrav, herunder hvad der skal kontrolleres i projektet, kvalitetsaktiviteterne til gennemførelse af denne kontrol og en plan for, hvornår kontrollen skal finde sted. Udfyld nedenstående skema ift. projektets leverancer/produkter.] Leverance/produkt Kvalitetskrav Kvalitetsaktivitet Kontroldato Ansvar [Angiv navn på leverance/produktkravtrol [Angiv kvalitets- [Angiv dato for kon- af kvalitet] [Angiv primær aktivitet, hvori kvalitetskontrol indgår] [Angiv navn eller initialer på ansvarlig for kvalitetskontrol] 11.2 Kvalitetskontrol [Her beskrives processer for, hvordan man i projektet vil måle, registrere og vurdere kvaliteten af projektets leverancer. Typisk beskrives de standarder, skabeloner og kvalitetsmetode, der følges. Mange organisationer har dette defineret for organisationen som helhed, hvorved der kan henvises til generelle standarder og skabeloner.] 11.3 Kvalitetssikring [Beskriv hvordan man i projektet sikrer, at kvalitetsplaner følges og kontroller udføres altså tjek af, om kvalitetskontrol udføres. Beskriv, hvilket ansvar styregruppen har for kvalitetssikring og beskriv, hvilke eksterne organer, som projektet vil blive kvalitetssikret af. Eksterne organer kan fx være It-projektrådet eller ekstern revision.] 12 Risici Her angives et udvalg af risici fra projektets risikolog. De risici, som scorer højest på konsekvens er medtaget her. De id er, som angives i tabellen nedenfor, refererer til id er og kategorier i risikologgen. Risikologgen er tilgængelig via dette link. Risiko Konsekvens Ejer 1.3: Hvis vi skal gennemføre konkurrence på app-udviklingen 3.1: Hvis den PLSP-baserede infrastruktur ikke er etableret og moden 3.2: Hvis ikke alle partnere i PLSP A/S bakker op om PLSP-konceptet 3.3: Hvis systemhuse ikke afsætter tid og ressourcer integration med PLSP-snitflader 4.1: Hvis de NSP-baserede forretnings- og registerservices ikke er understøtter app'ens behov 5.3: Hvis der ikke er klar ansvarsdeling og aftalte procedurer for test og godkendelse kan det presse eller vælte tidsplanen. kan det medføre, at app-leverandøren ikke kan udvikle app'en. kan det medføre, at vi udvikler en infrastruktur som reelt ikke er fælles. har vi reelt ikke grundlag for en fælles infrastruktur for app'en. kan det medføre funktionelle kompromis'er, forsinkelser eller behov for at flytte krav fra NSP til PLSP. kan det medføre usikkerhed ift. vurdering af PLSP-modenhed og app-lancering. Projekt PLSP PLSP PLSP SDS PLO, PLSP 13

15 Ad 1.3: Konkurrenceproces Modforanstaltningen til denne risiko er, at definere et så kortfattet og fleksibelt konkurrenceforløb som muligt. Men der er fortsat risiko for, at den angivne konsekvens kan indtræffe. Ad 3.1: PLSP-etablering Denne risiko er den mest afgørende for projektet. Den kan potentielt medøre, at projektet ikke kan gennemføres. Modforanstaltningen er pres og nærhed ift. udvikling og etablering af PLSPinfrastrukturen. Tid og ressourcer til denne indsats kan ikke underprioriteres. Ad 3.2: PLSP-opbakning Denne risiko relaterer til 3.1. Modforanstaltningen er løbende at deltage i møder med systemleverandørerne, og hele tiden at følge op på, om de enkelte systemhuse tjekker ind og bidrager til PLSP-fællesskabet. Ad 3.3: PLSP-integration Denne risiko indtræffer først i forbindelse med udrulning til systemhusene. Modforanstaltningen indebærer de samme aktiviteter som 3.1 og 3.2. Pres, nærhed og konkrete aftaler med de enkelte systemhuse om tidspunkt og vilkår for deres opkobling. Betalingen til de enkelte systemhuse er et afgørende redskab. Ad 4.1: NSP-services Der har allerede vist sig udfordringer vedr. mulighederne for at genbruge emobility-komponenten fra Medicinkort-app en i Min læge -app en. Vi arbejder på forudsætninger om at anvende relevante services fra NSP. Men der kan visse sig praktiske udfordringer og funktionelle begrænsninger i at gøre dette. Her kan modforanstaltningen være, at PLSP-infrastrukturen kommer til at løfte nogle af de opgaver, som vi i udgangspunktet forventede skulle baseres på NSP-services. Dette vil oplagt påvirke tidsplanen negativt. Ad 5.3: Ansvarsdeling Denne risiko indtræffer først på det tidspunkt, hvor der foreligger PLSP-snitflader at teste på. Modforanstaltningen er, at stille klare krav og lave aftaler med PLSP A/S om test og godkendelse af PLSP-leverancerne.A 14

16 13 Interessenter Interessentlandkortet afspejler omfanget af indflydelse og medvirken i projektets gennemførsels, frem mod release af første version. Den øvre del viser de parter/organisationer, der har høj indflydelse på projektet. Disse parter deltager i hhv. den operationelle projektgruppe, projektets styregruppe eller i programstyregruppen for Digital almen praksis. En rækker organisationer har lav deltagelse i projektet og samtidig lav indflydelse på selve gennemførslen (nedre venstre højre). Disse parter håndteres ad hoc og/eller evt. ved invitation til et informationsmøde primo Q4. To parter har lav indflydelse på selve projektets fremdrift og samlede udformning, men samtidig vigtige parter ift. få udvalgte funktioner i app en. De placeres derfor med høj medvirken, men med lav indflydelse. Projektet vil håndtere deres medvirken via enten samarbejdsaftaler eller anden aftale, der kan sikre brugen af deres tekniske indholdsleverance. 14 Kommunikation Endnu ikke beskrevet. [Se evt. kommunikationspolitikken for at orientere dig om brug af virkemidler og budskaber. Den finder du på t-drevet i denne mappe] 14.1 Hovedbudskaber [Redegør for de væsentligste budskaber i projektet, korriger skemaet, hvis der er andre områder med central interesse for projektet] Budskaber Projektets vision og strategi: [Hvorfor gør vi det? Hvad får vi ud af projektet? Hvad sker der, hvis projektet ikke iværksættes?] 15

17 Projektets indhold: Resultater og gevinster: It-løsningen: [Projektets omdrejningspunkt, faser, deltagere og ressourcer.] [Hvilke effekter vil projektet have ift. den måde, vi gør tingene på i dag? Hvilke konkrete gevinster skal projektet høste?] [Hvad består løsningen i? Hvilke data håndteres? Hvordan virker den? Kommer der uddannelse til brugerne?] 14.2 Formidling af budskaber til interessenter/målgrupper [Skabelon til kommunikationsplan finder du i denne mappe på t-drevet. Kan evt. vedlægges som bilag til PID] 14.3 Evaluering af kommunikation [Hvordan skal kommunikationsindsatsen evalueres, hvor tit og hvornår? Der bør evalueres på områder som Hvor let er det at forstå kommunikationen, Bliver skriftligt materiale anvendt? Værktøjer der anvendes: f.eks. Enalyzer (elektroniske spørgeskemaer), Google Analytics (se hvor mange gange en brochure downloades, en side besøges mv.), inddrag projektgrupper til at evaluere på kommunikation (og andet) i projektet] 15 Informationssikkerhed Det forventes at løsningen skal anvende det sikkerheds setup, som udstilles af Sundheds Data Styrelsen på Den Nationale Service Platform (NSP). Der skal tages stilling til, hvorledes borgeren evt. skal have mulighed for at give samtykke til åbning af adgang til dennes data hos egen læge. Dette skal afklares i specificeringsfasen Sikkerhedsmæssig risikovurdering [Udover de risici, der vedrører de projektmæssige hændelser, skal der udarbejdes en liste over risici, som relaterer sig til sikkerheden i og omkring it-løsningen. I dette afsnit gengives væsentligste konklusioner fra den sikkerhedsmæssige risikovurdering, herunder væsentligste udfordringer, mitigerende handlinger, samt hvordan sikkerhedsmæssige risici procesmæssigt håndteres. Sikkerhedsmæssige risici skal være indeholdt i risikoregister for projektet.] Se værktøjskassen Sikkerhedsmæssig risikovurdering 15.2 Konsekvensvurdering for privatlivet [Såfremt at løsningen behandler personoplysninger fremhæves væsentligste konklusioner af PIA analyse, mitigerende handlinger samt beskrivelse af evt. samarbejde med Datatilsynet i denne forbindelse. Risici relateret til konsekvenser for privatlivet skal være indeholdt i risikoregisteret.] Se i værktøjskassen under Pia (Private Impact Assessment) 16 Overdragelse fra projekt til drift Endnu ikke beskrevet Overdragelse af leverancer fra projekt til drift [Hvilke opgaver ligger efter projektet tilbage i MedCom (fx husning af en standard, drift, support eller videre udbredelse og hvilke opgaver ligger tilbage i regioner, kommuner, osv.] I værktøjskassen finder du skema og tjekliste til Overdragelse til drift. 16

18 16.2 Driftsansvarlige pid min læge app.docx [Kun relevant, hvis projektet indebærer en egentlig driftsløsning (fx VDX, sårjournal, KIH database, Lab portal el.lign.) Angiv ansvarlige ift. den efterfølgende drift af projektet. Som minimum angives ansvarlig til overtagelse fra forretningen system- og forvaltningsejer, og medmindre systemet driftes eksternt angives også teknisk ansvarlig fra driften platformsejer.] Rolle Navn og titel Enhed Systemejer (forretning) Platformsejer (teknisk drift) [Tilføj yderligere roller efter behov.] 17 Tolerancer Endnu ikke beskrevet. [Udfyld nedenstående skema med tolerancer. Såfremt der ikke opereres med tolerancer, anføres det i tabellen. Ingen tolerancer betyder, at alle afvigelser skal behandles af styregruppen.] Toleranceområde Projektudgifter: Interne ressourcer: Tid: Afvigelser og ændringer godkendes af: Råderum for projektleder [Indsæt grænsen for projektlederens råderum inden for budgetrammen i kr. og %. Såfremt tolerancerne er forskellige på udgiftstyper eller faser beskrives dette.] [Indsæt grænsen for projektlederens råderum i timer/årsværk eller i %. Såfremt tolerancerne er forskellige på roller, enheder eller faser beskrives det.] [Indsæt grænsen for projektlederens råderum i tid eller i % af tiden. Såfremt tolerancerne er forskellige på faser eller dele af projektplanen beskrives det.] Styregruppe [indsæt eventuelt anden godkendende instans.] 18 Revisionshistorik [Udfyld nedenstående skema ved ændringer i PID.] Revisionsdato Version Ændringer Ændringer markeret? Forfatter Klar til første behandling i styregruppe Nej MSN, MBB Gennemskrivning Nej MSN, MBB Opstart Nej MSN 19 Bilag Referencer Link: Program for Digital Almen Praksis (MedCom) Link: Rapport om fremtidens digitale lægepraksis Link: Oversigt over medlemmer i PLO s It- og Dataudvalg Link: Klikbar prototype Link: Brugerhistorier i Smartsheet Link: Tidsplan i Smartsheet 17

19 Link: Risikolog i Smartsheet Bilag 1. Specifikation af App v1 og PLSP-understøttelse af denne (udkast). 2. Tidligt udkast vedr. PLSP-snitflader (oplæg til kommende PLSP-seminar). 3. Kildeafdækning af app-relevante nationale services (Lakeside). 4. Forventede leverancer og resultater i første halvår af Figurer fra PID-dokument. 18