Ny it-strategi for RKKP

Transkript

1 Workshop 3, Teknologi i Sundhedsvæsenet DSKS årsmøde den 11. januar 2013 Ny it-strategi for RKKP - betragtninger til diskussion Cheflæge Paul D. Bartels, leder af RKKP

2 IT-strategi - KDB: Hva det/hvorfor det? Del af organisationsudvikling i RKKP: Eliminering af historisk/egnsbetingede forskelligheder i ITunderstøttelse af LKDB Opbygning/styrkelse af informatisk ekspertise i et KC Effektiviseringsgevinst stordriftsfordel Udskiftning eller udvikling af software

3 Implementering kvalitetsmonitorering - kvalitetsudvikling Indberetning af data Dataoverførsel NIP-database Dataanalyse i klinisk epidemiologisk enhed Centrale opgørelser af database/datakomplethed Kliniske processer, dokumentation Kvalitetsudvikling Feedback af data til afdeling: Hver måned/kvartal Feedback af justerede data: 1 gang årligt Offentliggørelse Regional klinisk audit National klinisk audit

4 Systemerne til understøttelse af kliniske databasers funktion i dag er principielt udviklet for år siden. Som led i strategien ønskes en bred vurdering af udviklingen på området, som bør munde ud i stillingtagen til spørgsmålet: Fortsættelse af det spor, der er lagt eller et egentligt udbud mhp. total fornyelse af området? Det implicerer meget mere end teknologivalg

5 Grundlag: Funktionalitet af fremtidens kliniske databaser Overordnet kontekst: Sundhedsvæsen under forandring Data fra klinisk registrering til fisketur i bouillabaisen Anvendelse: Kvalitetsudvikling, ledelse på alle niveauer, patient-borger empowerment, forskning, understøttelse af daglig klinisk praksis RAPID LEARNING HEALTHCARE SYSTEMS PATIENT CENTERED CARE Ledelse via BIG DATA Ikke traditionel medicinsk fedten rundt og command-and-control ledelse Efter princippet GRØN MAND GÅ _ RØD MAND STÅ?

6

7

8

9 Status It-strategi, hvordan? Proces Strukturerede høringer af centrale interessenter: Regioner, hospitals-/afdelingsledelser Kliniske repræsentanter Eksperter det er jer!

10 Status Strategien har indtil nu fået 4 fokusområder: Vision og styrende principper, gældende for: Inddata (indtastning, datafangst i nye og gamle kilder, epj) Præanalyse og analyse (klargøring og minimumsanalyse) Uddata (generisk model, generisk model++, offentlig formidling) Disse områder belyses mht. Væsentlige udfordringer og tendenser på kort, mellemlang og lang sigt Væsentlige relationer (ift. centrale it-tiltag, regionale epj samt øvrig sundheds-it) Væsentlige omkostninger (fx til licenser, ændringsønsker mv.)

11

12 Inddatering - lagring Skal opfylde krav om: Minimalt besvær for klinikken? 80 % af variable hentes i eksisterende systemer Nej! Det er ikke nok, der mangler; umiddelbar gevinst for klinikken? Passende kendt validitet

13 Analyse og uddateringsfunktioner Skal være løbende og tidstro (mål real time?) for alle kliniske kvalitetsdatabaser. Grundlag: Trend- og niveau analyser Skal bestå både i oplysninger om datakvalitet og resultater (patienter i registeret, variable i registeret og relevante beregninger) - GENNEMSKUELIGHED Herudover stigende behov for generel læring ved avancerede analyser på tværs af enheder comparative effectiveness/early warning/appropriateness Tilpasning til formål/målgruppe (ledelsesinformation, faglig udvikling, borgerinfo, MTV- comparative effectiveness)

14 Fleksibilitet Evnen til at tilpasse sig krav, dvs.: ændringer foretages indenfor meget kort tid og med et meget beskedent ressourceforbrug? Ad hoc problematikker og opgaver (IHI-lignende kampagner lokalt og nationalt) kan understøttes med meget kort varsel.

15 Særlige forhold omkring LPR og andre centrale registre Vi må konstatere, at den omstændelige inddatering og det ustabile output har medført, at den forventede aflastning af klinisk indsats i inddatering næppe holder stik. Samtidig er validitet og kvalitet af data på en række områder blevet reduceret. MEN Store forventninger til samarbejde med SSI og etablering af national platform for strukturerede sundhedsdata? Lovende erfaringer med anvendelse af LPR og Patobank i model for cancerdatabaser (DNKK-projektet)

16 Særlige forhold omkring EPJ Vi mangler at få svar på, om kravet om tidstrohed og fleksibilitet som forudsætning for anvendelse af data i kvalitetsudvikling overhovedet kan opfyldes med den nuværende teknologi (erfaringerne fra integrationsprojektet mellem Region Midtjyllands epj og anæstesidatabasen giver ikke anledning til optimisme) Har epj-projekterne i Danmark i tilstrækkelig grad overvejet kravene til ensartet semantik og strukturering, som også jf. international litteratur synes at være en forudsætning for anvendelse i tværgående forbedringsarbejde?

17 Styre-plangruppe januar 2013 Databaseprojekt herefter (Vi har prøvet det før kræft/hjerteområdet)

18 God fornøjelse

19 Ny definition af KDB Klinisk specificeret patientpopulation Klinisk specificerede variable Klinisk specificerede algoritmer Resten er bare støttefunktioner, som skal leveres af teknikere

20 Så kan vi lære det; Don't repeat the mistakes of the past Do not try to solve all clinical and translational research information technology problems in one framework. Do not worship standards over functionality. Do not try to have enterprise software adopted by fiat from above. Recognize that organizations that cannot afford ongoing staffing and help desk functions for software should not be expected to adopt software even if it is free or provides some income to the adopter. The acquisition cost is dwarfed by the support, maintenance, and integration costs.

21 Så kan vi lære det 2. Understand the basic truth about IT complexity; Increased functionality that is built at the expense of increased complexity is always at risk of: Delays in development Inability of local implementers and users to understand what has been built and how to use it, and Being overtaken by other approaches that have a better price-to-performance ratio (e.g., grid camputing versus web services).

22 Så kan vi lære det 3. Observe the informatics research and development "do's. Solve one significant challenge at a time. Use small, nimble, development teams led by domain experts. Keep development-to-implementation intervals short. Deploy software that can solve at least one problem that users or adapters care about within 12 months of adoption. Demonstrate success first with a smaller group of the most advanced sites and then let others follow. Create software that makes adoption of standards easier (not harder) than nonstandardized alternatives. Invest in simple interfaces between applications, not architectures. Allow intraorganizational and interorganizational needs and technologies to diverge as needed, to maximize productivity.