BS: Værdiskabelse I sundhedsvæsenet gennem IT (Forklaring af værdi). JS: Den diskussion er jeg jo jævnligt inde i og det er fordi jeg tror på at det med at skabe værdi for IT altså en væsentlig del af at have IT med i sundhedsvæsenet er, at patienten får direkte og umiddelbar adgang til egne oplysninger fordi så kan de bruge dem til noget, hvis de har lyst. De kan lade være hvis ikke de har lyst. De kan få ubehagelige oplevelser fordi de ikke kan læse det der står fordi det er noget sær latin eller det bare er skrevet på en mærkelig indforstået måde. Eller de kom til at se noget de ikke ønskede at vide noget om. Men jeg tror på, at værdien for borgerne ligger i at man har direkte og umiddelbar adgang. Så jeg synes jo grundlæggende at vi skal lukke op for den der EPJ, for vi har lukket op for booking systemet. Så de kan se hvilke bookinger de har. Vi har en E-journal, som forsinker tingene i 3 uger før man kan se de sidste. 2 uger på noget og 3 uger på andet. Jeg synes man skal lave det om. Jeg synes så snart de kommer ind i de systemer så bør borgeren også have adgang til data omkring dem. BS: Jeg kan forestille mig at forsinkelsen måske også har noget at gøre med at lægerne gerne vil hav lov at tjekke op på det de har skrevet før det kommer ud? JS: Åh jo, men det er jo heller ikke sådan at hvis lægen skal ha kontrolleret sit eget skriv, at det skal ud før det er kontrolleret næ næ. Lægen skriver og godkender det, så er det ude med det samme, men hvis lægen ikke har godkendt det, hvis det er en kladde, så er det ikke ude. Men min pointe er, at jeg synes vi skal give adgang direkte umiddelbart til patienten. BS: Det er så patienten, hvis det så skal give værdi for dig som leder? Det giver vel også værdi for patienten ikke? I og med at du får flere og bedre oplysninger omkring din virksomhed, som du skal drive hvis vi skal se det som en virksomhed. JS: Jo jo jo, det giver da meget stor værdi for patienterne, at vi har skrevet nogle ordentlige oplysninger ind i IT systemerne. Når vi snakker IT her så snakker vi software vi snakker ikke infrastruktur? BS: Nej. JS: Så giver det da væsentlig værdi, at jeg kan se hvad der er lavet tidligere. **** Standardisering som værdiskabende *** BS: Kan du give et eksempel på noget (IT) der enten er fremmende eller hæmmende for dit arbejde? JS: Hvis man nu ser på sammenligner - Nej der er flere niveauer. For det første, det at vi anvender den samme teknologi, altså det samme software til registrering f.eks EPJ- på flere steder. Det giver en væsentlig værdi. En meget væsentlig værdi når der kommer en patient fra Århus ned til os, at vi kan se hvad de har lavet og vi kan fortsætte på deres arbejde. Det giver højere kvalitet i det vi laver. Det giver højere hastighed fordi vi har det det samme sted og det er umiddelbart tilgængeligt. Så det giver både hastighed og kvalitet. Det effektivisere og det giver øget kvalitet.
BS: Og hvis du får en ny medarbejder fra Århus, så skal han ikke til at sætte sig ind i noget nyt? JS(4:02): Så det giver også den der kvalitet at man ikke skal indlære nye systemer det er en særlig organisatorisk kvalitet. Så det giver masser af værdi for organisationen. Det er en af de ting vi kan se i den her region især fordi vi bygger jo efter den tese en opgave, har vi kun et system til i den her region. Dvs. patientoplysninger vi har kun et system til det og det er det samme det har vi arbejdet på i 15 år. Nu har vi kun et. Klinisk logistik det at holde styr på processerne og afvikling på dagen der har vi kun et system. Dette er vi også med på. Booking af opgaver planlægning der har vi kun et system. Der er vi noget længere væk og det er fordi så kører øjenlægerne sku deres eget booking-system. Så kører onkologerne, pludselig viser det sig, deres eget booking system i ambulatoriet, så de skal piskes. Og så alt det der radiologi de booker jo på livet løs. Det hænger ikke sammen med booking det gør de i deres eget system. Så det med at stille det til rådighed, både for patienter og personale. Det er da svært at planlægge et rigtig godt forløb for en patient, hvor man kan sige nu vil jeg gerne forløbs-booke et større udredningsforløb. Jeg kan tilbyde dig den her dag den her dag og den her dag siger du ja til dem jaok. Så siger patienten, mn jeg skal lige huske at sige at jeg har det der med et røntgenbillede jeg har tid til et røntgen billede for det er der nogen der har bestilt. Ah shit siger lægen. Det kan jeg jo ikke se i det her system fordi det ligger i et andet. Åååhh så skal man huske det. Så kollidere det. Dårlig planlægnings-mode (?). **** Standardisering også af anvendelse (registreringspraksis) som værdiskabende *** Irritation, dårlig kvalitet, mangel på effektivitet. Det er eksempler på hvilken værdi det skaber på kvalitet og på effektivitet at have et system og have defineret at det er fælles og være helt skarp på hvad det er vi bruger dem til. Altså det er også billigere i udvikling og drift og vedligehold og oplæring. BS: Det er områder der er fælles med andre større organisationer, som Grundfos og andre, nemlig det man kalder enterprise arkitektur. Hvor man siger hvad er det vi kan standardisere for det er sikkert ikke alt der kan, men så skal man være bevidst om hvad der kan. JS: Jeg har jo talt enterprise arkitektur med Henrik Hammer Hjort i flere år. Det mangler der noget på. Der har været en lille brist i den her region, men meget mere i andre. I de senere år har vi truffet nogle væsentlige beslutninger i retning af enterprise arkitektur. BS: Det var der også behov for. **** Eksempler på manglende Standardisering - øjenlæger*** JS: Det var der meget stor behov for. Meget stort og vi er ikke færdige endnu. Altså hvorfor har øjenlægerne deres eget EPJ system? BS: Du mener øjenlægerne på hospitalerne?
JS: På hospitalerne. Så har de købt et praksis system som de har gået og bygget videre på. Så kører de med det. EMAR. Og så viser det sig fandme at de har et andet praksis-system ude i Vestjylland. Nu vil de også til at lave integration til FMK de vil også gerne lige udvikle noget hist og her. Hold op med det. BS: Her må det være regionsledelsen der mandat til at gå ud og sige sådan og sådan. JS(8:00): Faktisk så var det sådan at på det sidste styregruppemøde for IT hvor det var oppe, at nu skulle vi have ét øjenlægesystem. Der var jeg nød til at være chefarkitekt og sige jeg forstår ikke den her beslutning vi er ved at tage, om at vi vil have 2 EPJ-systemer. Et for øjenlæger og et for alle andre. Hvor er Enterprise Arkitekture i det? Vi har bekendt os til det som det største princip, nu fremlægger vi det her forslag så kommer IT afdeling inklusiv chefarkitekten og siger puha det er slemt når det er nogen udefra der skal komme og sige vi ikke følger vores egen arkitektur. Det blev taget af dagsordenen, fordi det skal lige kigges på igen. Så, så skrappe er vi blevet. Og det er godt. Så jeg tror på enterprise arkitektur. BS: Ja, det gør jeg også. Men man skal bare være intelligent omkring det. Man kan ikke nødvendigvis tage en hyldefigur og banke ned over. JS: Nej nej, ikke beton-stalinisme. BS: Man skal ud og undersøge for hver enkelt f.eks. de der øjenlæger er der en grund til at de gør det de gør. Er der vægtige grunde til at de gør det de gør? JS: Det er der da nok. Og derfor kan vi sagtens lave en undtagelse. Vi skal bare helt sikker på at vi har analyseret det i bund først. Vi har et princip, og det princip er vi intelligente nok til at fravige når der er gode grunde til det. Der er ingen grund til at gøre det hvis der ikke er gode grunde. ** BS: Jeg havde interview med Mogens Ensigsig chefstrateg. JS kender ham de er begge fra Århus amts tiden. ** BS: Har du oplevet nogle logikker (institutionelle) der kolliderer og hvor f.eks. IT udvikling kommer i klemme.? F.eks. det er én af disse logikker der bliver benyttet til udvikling af IT? På bekostning af f.eksk. klinikere? ** Logikker: Stabilitet kontra udvikling. Systemer bliver for store og komplekse. ** JS: Nogen gange kan man jo opleve, at klinikernes logik er, f.eks. nu skal vi ha udviklet et nyt system. Det kan da ikke være så svært. Send bud efter en leverandør der har forstand på det her område, sæt nogle klinikere på opgaven. Få dem til at lave det og så er det sådan det skal være. Så kan det støde på en anden logik forretningslogikken i IT afdelingen der siger, her har vi så mange projektledere og de arbejde efter denne metode ITIL eller og det er meget godt at i ude ved jer siger at det er der en stor besparelse eller en væsentlig kvalitetsforbedring ved at lave sådan et system eller ændre på det eksisterende, men vi har ikke nogen ledige projektledere eller Det kan vi sørme ikke gå i gang med nu fordi ifølge ITIL principperne skal vi gøre sådan og sådan så det kan vi først kigge på om et stykke tid.
Det er en af de der forskellige logikker og de kolliderer helt klart. Og klinikken forsøger jævnligt at sige Åhh kan vi ikke omgå det der system og så bare komme videre. ** Manglende udvikling og langsommelige uvikings-processer ** BS: Fordi de føler det går for langsomt? JS(15:25): Ja ja, de føler det går for langsomt. Det er en af de risici der er ved store IT organisationer, at der så der bliver en tiltagende enterti jo større man bliver. Altså jo flere ikke antal mand men jo større systemer man skal drive. De bliver jo mere og mere komplekse. De starter som små systemer og så bliver de mere og mere omfattende, mere og mere komplekse og mere og mere vanskelige at drive. Mere og mere komplekse at lave ændringer i. Dyre og dyre at lave ændringer i. Dyre og dyre at vedligeholde fordi de bliver større og det gør jo at til sidst så sidder Åh jeg havde en fed diskussion en gang med 100 mennesker som publikum nede i middelfart sammen med IT-chefen i Syd, Søren, hvor jeg var fanden og han var gud. Han var IT afdeling og jeg var kunde. Til sidst så ender IT afdelingen med at sige t i kan faktisk ikke få opgraderet jeres IT, fordi der er en væsentlig risiko hver gang vi skal gøre det. Så det skal gøres så sjældent som muligt af hensyn til stabiliteten og i forlanger stabilitet. Så nu skal i få stabilitet, så får i bare ingen udvikling. Den smule udvikling der sker, der går alle kræfterne til at lave teknologisk tingel tangel i bunden der sikrer stabiliteten. Der bliver ingen klinisk udvikling. Der bliver ingen værdiskabelse for personalet ud over stabiliteten i det man har. BS: Det er jo et interessant punkt. Stabilitet kontra udvikling. JS: IT og klinikken vil have stabilitet, men klinikken vil også have udvikling. Der bliver en konfrontation mellem behovet for stabilitet og behovet for udvikling. Og hvis man ikke passer på så taber udviklingen. Det giver stabile systemer - der dør. De ophører med at eksistere fordi de ikke bliver udviklet. BS: Den var interessant. Det vil jo være en interessant øvelse at disse to modsat rettede ting til at spille bedre sammen. JS: Men den er stor. Nu har jeg været med i så mange år så jeg har set det gå fra at være lille også samarbejdet med Systematic, fra at være nå vi sætter da bare 5 programmører og 5 klinikere og så laver vi noget. Så når der er gået 6 uger så vi vidste ikke det hed scrum vi hoppede bare ud i det. Så gik de hjem og kodede noget så fandt de selv på en god ide efter at have snakket med os så kodede de det også. Så viste de det frem. Så sagde vi ja det og det, men det er noget skrammel lav det sådan her. Så gik de videre. Det er den måde akut-appen er udviklet på. Man er gået tilbage til gammeldags hurtig og tæt udvikling. BS: Ja og det er jo ikke gammeldags for regionen den her ser ud til at være ny? JS: Den er ny. Det er en prøvehandling Akut-appen. Og det er jo fordi vi frustreres over at udviklingen er sådan noget med at første skal vi finde en projektleder. Så skal der være penge til en forundersøgelse, det skal prioriteres 2 gange om året. Så bliver det sådan et vandfald ja. Og det kommer til at ta.
Desværre kan vi ikke nå mere, da jeg skal til det telefonmøde.