Opsamling fra Markedsdialog forud for anskaffelse af ny løsning til telemedicinsk sårvurdering

Transkript

1 Opsamling fra Markedsdialog forud for anskaffelse af ny løsning til telemedicinsk sårvurdering Dette dokument opsamler de hovedindtryk, som projektledelsen for ny løsning til telemedicinsk sårvurdering har opsamlet i løbet af markedsdialogen med 7 leverandører den november Alle dialoger tog udgangspunkt i en udsendt beskrivelse af nuværende Sårjournal og forventninger til projektet (vedhæftet) samt nedenstående dagsorden. Punkt Emne Ansvarlig 1. Velkomst og præsentation af deltagere Alle 2. Formål med markedsdialogen introduktion til ny løsning til telemedicinsk sårvurdering herunder samlet tidsplan, omfang og samlet anskaffelsessum inkl. forventet drift og vedligehold, og kundens it-miljø 3. En ny løsning til telemedicinsk sårvurdering herunder: a) Brug af en fælles løsning eller to målrettede løsninger til hhv. borger/medarbejder b) Brug af infrastrukturens snitflader, herunder brug af FHIR, og lagring af sårbilleder c) Brug af BFF modellen for en ny løsning til telemedicinsk sårvurdering d) Er brug af jeres evt. eksisterende løsninger mulig? e) Vedligehold, drift, support, i forhold til hele økosystemet f) Ejerskabs- og licensforhold, og økonomisk ramme Telesår Leverandøren 4. Øvrige observationspunkter fra leverandøren a) Funktionelle/Non-funktionelle områder b) Udbudsmæssige områder 5. Forventet proces for anskaffelse af en ny løsning til telemedicinsk sårvurdering 6. Eventuelt Leverandøren Telesår Bilag: Oplæg til markedsdialog vedrørende kommende løsning til telemedicinsk sårvurdering (eftersendes) 1

2 Kort om dialogmøderne Dialogen blev gennemført med 7 forskellige virksomheder, hvoraf nogle har eksisterende telemedicinske løsninger. Den fremsendte dagsorden blev gennemført, men ikke i stringent rækkefølge af hensynet til en smidig og frugtbar dialog. Ordregivers hovedindtryk, der angives i det følgende, er efterfølgende grupperet under de dagsordenspunkter hvor de oftest optrådte. Hovedindtryk vedrørende dagsordenspunkt 3.a (Brug af en fælles løsning eller to målrettede løsninger til hhv. borger/medarbejder) Billeder der optages på devices ikke bør lagres permanent (fx i enhedens fotobibliotek). Webløsninger er lettere at deploye, men at der kan være en udfordring med offline funktionalitet. Visningsmæssigt er det vigtigt at borger og medarbejder ser det samme, hvilket peger i retning af 1 løsning. Dette kan dog til dels løses med genbrug af komponenter. Der er forskel på behovene i forbindelse med at optage billeder og indsende, og at se på billeder og kommunikere om dem, hvilket peger på flere løsninger med målrettet funktionalitet. En native app (til en smartphone eller tabletklient) kræver (i modsætning til HTML5 apps), at man kan spille sammen med alle kommuner/regioner MDM systemer. Der opleves ofte udfordringer med MDM systemer generelt (men ikke i selve de apps, der skal styres). En native app giver typisk en bedre brugeroplevelse end HTML5 apps (man kan mere i en native app). Apps skal dog godkendes hvilket forsinker og komplicerer udrulning (især på Apple). En native app tager op imod 4 gange længere at udvikle end en HTML app. Off-line storage i webbrowsere på mobile enheder er begrænset, så man kan ikke lagre et ret stort antal ikke afsendte billeder. Understøttelse af BOYD (Bring Your Own Device) giver udfordringer (f.eks. mange forskellige skærmstørrelser, en løsning skal tilpasse sig til). Den bedste måde at inddrage praktiserende læger er ved tidlig inddragelse. Den praktiserende læge er ofte den første behandlingsansvarlige. Hvis praktiserende læger skal involveres, skal det kunne ske fra den praktiserende læges primære system. En praktiserende læge har meget få minutter til hver patient, så en praktiserende læges brug af to systemer (eget praksissystem og sårløsning) er dermed ét system for meget. Den bedste måde at få praktiserende lægers systemer inddraget er ved at lave små komponenter, som er lette at anvende. En eller flere leverandører anbefalede: To apps, så brugergrænsefladen kan målrettes hver af de to profiler (borger hhv. medarbejder). Dog anbefales så stort teknisk og UX genbrug som muligt. Lav apps som HTML5, evt. med brug af biblioteker fra android/ios hvor nødvendigt. 2

3 Kun at udvikle én app med forskellige rettigheder bl.a. for at sikre, at klinikere er i stand til at hjælpe borgere. Distribution via app stores evt. via MDM systemer til klinikere. Ikke at lave HTML5 app, da de ofte mangler samme lækre fornemmelse som native apps. Man kan overveje at anvende WebRTC/getUserMedia eller anden teknologi til at sikre, at billeder ikke placeres i enheders fotobiblioteker. Man udvikler apps som HTML5 og kompilerer til hhv. ios og Android. Ordregivers investering i grundigt arbejde med brugergrænsefladen og brugeroplevelsen giver mange ganges afkast i en bedre løsning, så dette bør gennemføres, evt. i en tilstrækkelig lang afklaringsfase. Hovedindtryk vedrørende dagsordenspunkt 3b (Brug af infrastrukturens snitflader, herunder brug af FHIR, og lagring af sårbilleder) En FHIR-baseret snitflade udstiller relevante ressourcer, der vil kunne anvendes til at realisere en løsning til telemedicinsk sårvurdering. Brug af en FHIR fra en telemedicinsk infrastruktur er nemmere at forstå og anvende mod mobile devices og browsere end de traditionelle HL7 snitflader. FHIR har modenhedsgrad på de enkelte dele af snitfladerne, så anvendere ved hvor snitfladen forventes at være stabil standardiseringsmæssigt. Man bør stille krav til leverandørerne om, hvorledes FHIR skal anvendes. KHI/DDS ikke understøtter billeder hensigtsmæssigt for nuværende. Fagsystemer bør integreres via en FHIR snitflade, fx indirekte via en integration til FUT infrastrukturen. I relation til patientjournaler eller omsorgsjournaler, at specialsystemer som Sårløsningen skal bistå journalen (der dermed trækker på disse specialsystemer ). Brugen af FUT giver mulighed for at lave mere tværgående (telesundheds) løsninger. Der må forventes intensiv dialog med infrastrukturens leverandør bl.a. om kald for at optimere performance. Man bør optimere efter læsning af billeder frem for skrivning, da skrivning kun sker 1 gang, men læsning vil ske mange gange. Løsningen bør integreres med EOJ/EPJ (fx via FUTs infrastruktur), og at FUT skal tilbyde et lag, som giver (yderligere) sammenhæng via Dokumentdelingsservicen (når denne understøtter deling af billeder). Praktiserende læger er for nuværende ikke en del af FUTs brugerstyring. Det er ordregivers ansvar at sikre, at FUT infrastrukturen indeholder tilstrækkelig funktionalitet. Som (løsnings)leverandør bør man have mulighed for at lave add-ons til infrastrukturen, hvis denne bliver en flaskehals. 3

4 En kommende telemedicinsk løsning til sårvurdering bør trække på generisk funktionalitet i en telemedicinsk infrastruktur, til fx billedbehandling og beslutningsstøtte. Leverandører af løsninger skal supporteres af leverandøren af FUTs infrastruktur. Flere leverandører anbefalede FHIR, da det er bedste bud for nuværende. Man bemærkede dog, at skal udvises påpasselighed med FHIR extensions (dvs. egne udvidelser). Hovedindtryk vedrørende dagsordenspunkt 3c (Brug af BFF modellen for en ny løsning til telemedicinsk sårvurdering) Bag det fremsendte materiale ligger en grundlæggende antagelse om, at FUT infrastruktur er idriftsat. Der er mange gode intentioner i FUTs infrastruktur, men risiko for, at den ikke er åben. Ordregiver bør bistå med at sikre at FUT udstiller en (afprøvet) åben snitflade. På (længere) sigt bør brugergrænsefladen til medarbejdere i FUT forsvinde, da den bør ligge i EOJ, EPJ eller lægepraksissystemer. En eller flere leverandører anbefalede følgende: BFF er gøres så tynde som muligt og derfor indeholde så lidt forretningslogik som muligt. Projektet tager aktivt stilling til, hvilke billedformater der skal anvendes i løsningen (konkret er f.eks. PNG formatet velegnet). Ordregiver bør overveje at lave en open source løsning, evt. uden om udbud mv. Man anvender nuværende medarbejderløsning til generiske opgaver, så Sårløsningen kun skal udvikles til specifikke opgaver til telemedicinsk sårvurdering. Hovedindtryk vedrørende dagsordenpunkt 3d (Er brug af jeres evt. eksisterende løsninger mulig?) Der findes eksisterende løsninger som kan anvendes. Sårløsningen kan realiseres som en Add-on til FUTs KOL løsning. Sårløsningens behov overlapper i stor stil med FUT funktionaliteterne og dermed store muligheder for genbrug. Det forventes at være muligt at genbruge store dele af en KOL løsning. Nogle leverandører forventer at tilpasse deres eksisterende app/telesundhedsløsning. Hovedindtryk vedrørende dagsordenspunkt 3e (Vedligehold, drift, support, i forhold til hele økosystemet) 4

5 Vedligehold, drift og support bør være tre-delt, svarende f.eks. til den model der anvendes i FUT rammeaftalen. Det man udvikler, varetager man som leverandør selv ansvaret for. Varetagelse af support af superbrugere er gængs. Man vil helst ikke supportere borgere direkte. Drift af dele af løsningen ved FUTs Infrastruktur giver kompleksitet der skal håndteres, f.eks. fornødne rettigheder til at styre driften af egen løsning. Hovedindtryk vedrørende dagsordenspunkt 3f (Ejerskabs- og licensforhold, og økonomisk ramme) Det vil være hensigtsmæssigt at anvende FUT rammeaftalen til anskaffelsen. Evt. kan ordregiver se på SKI aftalerne. Den tynde Sårløsning (dvs. en løsning 100% baseret på en FUT infrastruktur) kan nok ikkw sælges andre steder end i Danmark. Der bør være sondring mellem kundespecifikt og standardprogrammel. Leverandøren gerne vil have ejerskab/anvendelseret til løsningen, da de forventer at kunne afsætte den i udlandet. Hvis/når FUT infrastrukturen er moden, giver kortere kontraktlængder for en sårløsning mere mening (men indtil da vurderes 4 år passende). Nogle leverandører foretrækker at levere som SaaS (Software as a Service). Licenser betales (ofte) efter en trappemodel for antal aktive brugere. En volumenlicensmodel kan give incitament til dårligere udnyttelse af løsningen frem for en model hvor prisen ikke afhænger af antal borgere. En eller flere leverandører anbefalede følgende: Man bør vælge kun at kravspecificere den allermest basale løsning, og udvikle resten på optioner i agilt forløb. Få udviklet under Open Source licens for øge mulighederne for genbrug. Anvend FUTs ejerskabsmodel. Hovedindtryk vedrørende dagsordenspunkt 4a Øvrige observationer Funktionelle/Non-funktionelle områder Udrulning hos modtagerne kan gøres inkrementelt f.eks. ved styring via sikkerhedsroller hvilken funktionalitet en (gruppe af) modtagere kan tilgå. Der bør anvendes (forretnings)standarder når beregninger af sårareal foretages (er det f.eks. skorpe- eller rødmekanten der bruges). 5

6 Hovedindtryk vedrørende dagsordenspunkt 4B Øvrige observationer Udbudsmæssige områder Der bør være mulighed for intensiv afklaringsfase på 3-5 uger, hvor leverandøren kan sætte sig ind i og afklare krav mv. En eller flere leverandører anbefalede følgende: Start med en udgave af løsningen med mindre funktionalitet end nu, for at få den hurtigt i drift, og udbyg derefter med dét der er mest brug for. Overvej at bede leverandørerne om at stille op til en demonstration i forbindelse med anskaffelsen. 6