Laboratorie forsøg med Forløbsplan arkitekturen version 2 Hosted implementering. ver

Transkript

1 Laboratorie forsøg med Forløbsplan arkitekturen version 2 Hosted implementering ver

2 Indhold Formål... 3 Laboratorietesten omfatter... 3 Resultat af laboratorietest... 3 Installation og opdatering af Forløbsplan arkitekturen... 3 Gennemgang af program komponenter for afdækning af nødvendige rettelser i henhold til nuværende godkendte arkitektur... 3 Gennemgang af SQL tabeller med henblik indhold/afstemning med de facto standarder... 4 Gennemgang af SQL tabeller med henblik på optimering... 4 Forslag til videre plan herunder pilotdrift... 5 Anbefalede ændringer/forbedringer... 5 Tidsplan... 5 Økonomi... 6 Opsætning i systemhus... 6 Drift og servicering... 6 Undervisning af klinikker honorering af klinikker... 7 Efterskrift... 7 PL-Forum 21. august Side 2

3 Formål: at sikre at teknikken i forløbsplanprojektet kan udvides til en løsning, der kan hostes hos de enkelte Lægesystem leverandører, samt at afdække svagheder, som bør imødegås før en egentlig pilotdrift. Opgavestiller: Medcom og PL-Forum Til nærværende dokumentation findes detaljebeskrivelse af ændringsønsker til såvel arkitektur som tabeller. Disse er udeladt, for at skabe en kortfattet og letlæselig rapport. Laboratorietesten omfatter installation og opdatering af Forløbsplan arkitekturen Test af arkitekturens virke med udgangspunkt i en hostet implementering gennemgang af program komponenter for afdækning af nødvendige rettelser i henhold til nuværende godkendte arkitektur gennemgang af SQL tabeller med henblik indhold/afstemning med de facto standarder gennemgang af SQL tabeller med henblik på optimering er ikke en test af nødvendige rettelser Resultat af laboratorietest Installation og opdatering af Forløbsplan arkitekturen Den nuværende installation (1.0.35) er installeret i hosting miljø på to adskilte servere, Microsoft SQL server x64 version (SQL Server 2012 SP3) Microsoft Windows Server standard 2012 R12 Internet Information Services 8 Installation og opdatering udført - installation testet. Konklusion: Installationen kan i sin nuværende form gennemføres, vi vil dog anbefale, at der bruges kræfter på: 1. Yderligere dokumentation af fejlsituationer 2. Højere grad af kontrol ved opdateringer herunder selektiv opdatering af SQL tabeller, med automatisering af versionsstyring. 3. Flere og mere udførlige fejlmeddelelser under installation 4. Mere brugerinformation under installationen Gennemgang af program komponenter for afdækning af nødvendige rettelser i henhold til nuværende godkendte arkitektur Vi har fået udleveret kildeteksten til alle projekter med relevante test projekter dog er der enkelte mangler, som gør at vi ikke kan oversætte kildeteksten til egentlig programmer så vi er begrænset til at teste på leverede færdig kompilerede programmer. Vi har gennemgået kildeteksten, og kodeeksemplerne er velvalgte der udestår dog dokumentation. I nærværende test har vi koncentreret os om en vurdering af nødvendige rettelser i henhold til nuværende funktionalitet i forhold til at afvikle denne hosted i Systemhusenes hosting centre. Konklusion: PL-Forum 21. august Side 3

4 Ved gennemgang af arkitekturen er der ikke fundet forhold, som vil vanskeliggøre brugen af nuværende arkitektur i et hostet miljø. Det vil være givtigt i et efterfølgende pilotprojekt at få dokumentationen mere skarp og skabe en håndbog for etablering i de enkelte systemhuse, med best practice for dette. DAK-E har allerede igangsat tiltag for håndtering af mindre variationer i en hostet implementering. Gennemgang af SQL tabeller med henblik indhold/afstemning med de facto standarder Gennemgang af SQL tabeller med henblik afdækning af eventuelle mangler i forhold til centrale registre og registrerings practice. Ved gennemgangen ønskes den enkelte registrering beriget med Cpr nummer på den ansvarlige for registreringen og ikke kun initialer. UUID for den enkelte registrerings enhed (klinisk enhed, eksempelvis en diagnose, et blodprøvesvar, et journalnotat) dette vil give mulighed for tilbagekaldelse af fejlagtige oplysninger- mulighed for synkronisering etc. Gennemgangen af tabeller gav anledning til en gennemgang af medicin registreringerne, som i den nuværende version er baseret på en før FMK opfattelse af ordinations paradigmet. Her har vi som en del af gennemgangen haft et møde DAK-E, og der er opnået en fælles opfattelse af hvad denne tabel bør indeholde. Det er den eneste registrering, hvor ens større omskrivning og logik tilpasning er ønskværdig. Konklusion: Gennemgangen stiller ønske om enkelte optionelle tilføjelser i tabelstrukturen, kun i håndtering af medicin ordinationer kræver en lidt større omskrivning. Det vil være naturligt kun at tilføje dette i version 2 implementeringen af Forløbsplaner. Gennemgang af SQL tabeller med henblik på optimering Helt generelt har vi et ønske om højere grad af validering og strukturering af tabellerne, således at fejl i standarder og indrapporteringer bliver fundet og rapporteret tilbage på så tidligt et tidspunkt som muligt. Der er et ønske om simplificering af felter og tilpasning af feltlængder. Det vil øge kvaliteten af indberetningerne. Dette vil også sikre en bedre performance og også mere pladsoptimal løsning i de centrale løsninger. Det vil ikke være nødvendigt at foretage disse her og nu, men vi anbefaler dog at der sættes valideringer op for dette så tidligt som muligt i forløbet. PL-Forum 21. august Side 4

5 Forslag til videre plan herunder pilotdrift Anbefalede ændringer/forbedringer Der er i det nuværende setup ikke forhold, der er forhindrer en pilot afprøvning af Forløbsplaner i en Systemhus hosted version. Vi vil dog anbefale, at der ovennævnte tabelændringer implementeres fra en start, herunder ny medicin registrering tilpasset FMK verdenen. Optimering af tabelstrukturer er ikke afgørende, og vil ikke være afgørende i en pilot fase. Konklusion På baggrund af ovenstående vil vi anbefale, at igangsætte udvikling og tilpasning af Medicin tabeller dokumentation / præcisering af eksempelkode og styrkelse af fejlhåndtering ved installation og op Tidsplan Med udgangspunkt i ovenstående vil vi foreslå en tidsplan som nedenstående Forløbsplan ver. 2 Sep Okt Nov Dec 2018 Jan Feb Marts Installations pakke og tabel ændringer Systemhus planlægning/varsling 1 Tabeludv. Install. Udvikling/Klargøring Systemhus 2 Teknik/udv. Pilot ver leverandører praksis Et succesfuldt forløb er dog betinget af, at vi får givet grønt lyst og varslet leverandørerne omkring såvel udvikling og tilpasning af installationspakker tabeller, som sikring af at systemleverandørerne varslet omkring tidsplanen og ovennævnte plan. Ovennævnte plan er således betinget af en beslutning senest med udgangen af august, ellers vil denne skulle parallel forskydes tilsvarende. PL-Forum 21. august Side 5

6 Økonomi Økonomien er ikke ændret væsentligt i forhold til tidligere estimater. Der skal allokeres tekniske ressourcer hos DAK-E til at bistå med dokumentation og beskrivelse af installationspakken. Der skal stilles ressourcer til rådighed for at fejlsikre opdaterings og installationspakker, samt gøre installationspakken mere sikker i forskellige miljøer. Ud over DAK-E s indsats vil det anslås, at der skal bruges 40 timer i alt kr ,- Opsætning i systemhus Her henviser vi til vores tidligere beregninger idet der her skal skelnes mellem en test installation og et egentligt driftsscenarie. Test installationen vil naturligvis kunne genbruges i det endelige Driftsscenarie. Drift og servicering Her henviser vi til tidligere beregninger PL-Forum 21. august Side 6

7 Undervisning af klinikker honorering af klinikker Det vil være hensigtsmæssigt for forankringen og etableringen af ovennævnte løsning at have en række undervisnings seancer hvor brugen gennemgås, her kunne brugere af den tidligere Forløbsplanløsning være gode erfarings repræsentanter. Efterskrift Forløbsplan projektet skaber mulighed for en lang række kvalitets tiltag, som kan byde ind med en række metoder til at give den enkelte borger adgang til at udveksle data med sin praktiserende læger. Designet skaber mulighed for, at selektivt at samle de nødvendige data, og kun disse i de enkelte klinikker, og rummer mulighed for at afgrænse dette i tid. Introduktionen af UUID baserede registreringer tillader, at data udvekslet med denne løsning kan kaldes tilbage, og løse nogle af de sikkerhedsmæssige udfordringer, som de kommende år vil byde på. Kombineret med en elektronisk samtykke arkitektur, skabes en grobund for en løsning, der sikrer borgerens tryghed omkring sundhedsdata og samarbejdet med den praktiserende læge. Løsningen i systemhusene sikrer en langt billigere udrulning og en mere dynamisk og lettere vedligeholdt platform. PL-Forum 21. august Side 7