Ja ni vet så klart bättre och låt oss hoppas att de statliga systemen blir framgångsrika.
Ja, alltså, jag jobbar ju med detta. Både som läkare i den faktiska vården som användare av systemen och som klinisk representant i konfiguration av vårt specialistsystem. Dessutom, som sagt, en rätt lång period i en upphandling motsvarande den som i VGR och Skåne resulterade i Millennium. Jag har jobbat med ett relativt stort urval av journalsystem, inklusive papper. Jag har under hela tiden haft ett intresse för datasystem och datahantering vilket också gjort att jag varit uppmärksam på hur systemen beter sig.
På den lilla fritid jag inte har längre så gillar jag också programmering.
Så ja, jag tycker mig veta ganska väl vad jag pratar om. Det tycker min arbetsgivare också som låter mig spendera en hel del av min arbetstid med dylika uppgifter (men det är ju regionen, och de har omvittnat dåligt omdöme vad gäller IT).
Om du läser hela det långa inlägget så har jag inte heller förespråkat ett statligt "system". Jag har, sedan jag började reflektera över den här problematiken under läkarutbildningen för knappt 20 år sedan, haft samma uppfattning. Den är att datalagret ska vara centralt och statligt, likaså styrningen av APIer. Frontend kan man få bygga själv, eller använda något som utvecklas gemensamt för en, flera eller alla regioner. Denna uppfattning innehas av många andra inom branschen, inklusive tyngre aktörer. Dock inte det privata näringslivet, då de gärna vill sälja sina färdiga paketlösningar. Speciellt då Oracle och EPIC.
På den lilla fritid jag inte har längre så gillar jag också programmering.
Så ja, jag tycker mig veta ganska väl vad jag pratar om. Det tycker min arbetsgivare också som låter mig spendera en hel del av min arbetstid med dylika uppgifter (men det är ju regionen, och de har omvittnat dåligt omdöme vad gäller IT).
Om du läser hela det långa inlägget så har jag inte heller förespråkat ett statligt "system". Jag har, sedan jag började reflektera över den här problematiken under läkarutbildningen för knappt 20 år sedan, haft samma uppfattning. Den är att datalagret ska vara centralt och statligt, likaså styrningen av APIer. Frontend kan man få bygga själv, eller använda något som utvecklas gemensamt för en, flera eller alla regioner. Denna uppfattning innehas av många andra inom branschen, inklusive tyngre aktörer. Dock inte det privata näringslivet, då de gärna vill sälja sina färdiga paketlösningar. Speciellt då Oracle och EPIC.
Undrar hur många miljarder kronor som hade sparats om min mor fått jobba kvar på journalarkivet...tommib skrev:
Det hade definitivt inte varit en besparing. Trots allt gnäll om systemen så sparar de tid jämfört med pappersjournaler. De möjliggör också en helt annan nivå av uppföljning och forskning.
Det som skulle spara pengar vore om vi inte försökte göra mer än vi gjorde förut. Men det vill vi i en del avseenden, och inte i en del andra (om du frågar mig).
En stor del av klagomålen handlar om att vi är inne på andra eller tredje generationen av system. De första var väldigt basala och handlade framför allt om remisser och svar (röntgen, labdata). Därefter kom journalen, som i löptext. Parallellt, eller efter, kom bokningar och beläggning. Detta växte i många fall fram organiskt vilket gjorde att det var hyfsat anpassat efter de faktiska behoven. Ok på frontend i många fall men en jävla röra rent ut sagt i backend.
Det specialistsystem jag jobbat med är också något som vuxit evolutionärt, men i andra länder och för betydligt mindre installationer. Därför saknas massa saker och man ser tydligt de digitala lager som byggts upp för att hantera nya önskemål.
De systemen vi pratar om nu, Millennium (och lite EPIC) är faktureringssystem och vårdsystem för en helt annan verksamhet än den vi bedriver och de är inte anpassningsbara. Därför blir det problem.
Det som skulle spara pengar vore om vi inte försökte göra mer än vi gjorde förut. Men det vill vi i en del avseenden, och inte i en del andra (om du frågar mig).
En stor del av klagomålen handlar om att vi är inne på andra eller tredje generationen av system. De första var väldigt basala och handlade framför allt om remisser och svar (röntgen, labdata). Därefter kom journalen, som i löptext. Parallellt, eller efter, kom bokningar och beläggning. Detta växte i många fall fram organiskt vilket gjorde att det var hyfsat anpassat efter de faktiska behoven. Ok på frontend i många fall men en jävla röra rent ut sagt i backend.
Det specialistsystem jag jobbat med är också något som vuxit evolutionärt, men i andra länder och för betydligt mindre installationer. Därför saknas massa saker och man ser tydligt de digitala lager som byggts upp för att hantera nya önskemål.
De systemen vi pratar om nu, Millennium (och lite EPIC) är faktureringssystem och vårdsystem för en helt annan verksamhet än den vi bedriver och de är inte anpassningsbara. Därför blir det problem.
Det är jag givetvis medveten om.C cpalm skrev:
Jag menar att informationen ska vara krypterat och att man ska logga vem som läser vilken information.
Har man obegränsad behörighet så hjälper inte kryptering.C cpalm skrev:
Man kan kryptera information i en databas så att en databasadministratör inte kan läsa informationen, men ändå göra sitt arbete.
Förstår hur du tänker, men det är generellt inte så det funkar. "Databasmotorn" måste i praktiken jobba med datat i klartext för att kunna göra sitt jobb.Fairlane skrev:
En bra sak är att man kan få ut alla provtagningar från journalen i ett excelark här i regionen, men även i grafer, etc, för att se hur värden kanske förändrats då jag går under årlig kontroll. Får resultat från 2017 och framåt. Så visst utvecklas vården
Delvis sant, beroende på vad den ska göra. Det innebär dock inte att DBA automatiskt kan se allt och framförallt inte utan att det skapas en logg på det.C cpalm skrev:
Det är lite fånigt att ha smartcard-inloggning, rollbaserad behörighetskontroll och loggning som sänds till logganalys, om man vill se någons journal om man kommer via det grafiska gränssnittet och sen lägga allt fullt läsbart för tekniker, utan någon kontroll eller logg.
Millenium i VGR och Skåne är iofs samma grundsystem, men det är konfigurerat väldigt olika. Att Andreas Thörneby hade så många steg i sin beskriving beror på dåligt konfigurerat system. Samt att en hel del av sakerna som är engångshändelser, tex registrering av överkänslighet.Detta med Millennium är intressant.
Man säger att det var omöjligt att förutse och de andra sedvanliga flosklerna. Jag har påstått sedan ca 2018 att det systemet aldrig kommer kunna fungera i en svensk kontext. Det har man vetat i VGR också inom diverse grupper läkare. Jag fick för länge sedan ta del av en intressant presentation "för internt bruk" där en rad stora namn var av åsikten att om detta system införs kan vi inte längre garantera patientsäkerheten. I VGR valde man då bort den delen av Millennium, vilket man inte gjorde i Skåne. Det tråkiga för resten av VGR är att resten av Millennium är lika kass.
Det är ett faktureringsprogram i botten, inget annat. På det har man bultat på patientdelen. Det stämmer inte att alla får samma gränssnitt, det finns lite olika sätt att presentera information. Det är bara det att alla är usla. Systemet är i stora stycken hårdkodat och processerna går inte att anpassa till en svensk kontext. Ta bara exemplet som florerade på Twitter med distriktsläkaren som behövde 73 (eller vad det var) klick för att förnya ett recept. Flera steg i den processen var irrelevanta för en svensk kontext eller skulle varit automatiserade från kontexten i programmet. Att det fortfarande, efter så många år av utvecklingsarbete är så uselt säger allt. Man kan inte anpassa systemet, utan planerade att anpassa verksamheten efter systemet.
I princip finns det två stora drakar på marknaden. EPIC och Millennium. Därutöver finns ett gäng mindre (men stora för Sverige) system. I USA går många stora aktörer över till EPIC, som är marginellt bättre än Millennium men inte särskilt tilltalande det heller. Det är också extremt dyrt att drifta och en uttalad strategi från deras VD är att det ska vara omöjligt att byta från EPIC pga datalagret. En massiv röd varningsflagga gällande EPIC är att de stämmer folk som lägger upp skärmdumpar. Därför är det svårt att hitta information om hur det fungerar och ser ut. Om man inte vill visa upp sitt program för de tänkta slutanvändarna öppet så har jag en ganska bra gissning om vad problemet är. Anledningen till att man kör dessa system i USA är deras väldigt speciella sjukvårdsmarknad med försäkringsbolag och bolagsdrivna sjukhus. Statistik och ekonomi är helt enkelt extremt välutbyggt (för att man började med den delen) och genererar fina rapporter och räkningar till sjukhusledningen. Patientdelen, nja... Jag ska för ärlighets skull säga att jag inte jobbat i något av systemen och inte heller sett enormt mycket av EPIC. Millennium har jag sett "live" och jag var inte imponerad. Alls. Jag såg också bilder av det i våras på Vitalis (en stor mässa för IT i vården). Att inte ha ett livesystem som man får leka runt i på en mässa av den digniteten är, för att säga det lite snällt, anmärkningsvärt. De var ett halvår från produktionssättning, då borde de kunnat visa upp sitt testsystem. Detta kan jämföras med Cosmic som hade en stor monter där man fick testköra deras olika system och laborera med dem i olika roller.
Angående att upphandlingen skulle varit riggad för Milennium så tror jag inte det. Däremot var den riggad för ett stort system som innehöll allt. Det var nämligen motsvarande upphandling i Stockholm också, där jag arbetade heltid tio månader. Jag skrev rätt mycket kravspecifikationer och fick hela tiden order om att dumma ner dem och göra dem mindre specifika, tills det mesta kokade ner till att "det ska vara lätt att göra rätt". Om man har sådana kravspecifikationer (lite överdrivet) så får man skit. Jag och en kollega bokade möte med projektledningen och redovisade vår kritik mot projektet i form av en punktlista. Den största var väl att det överhuvudtaget inte var verksamhetsdrivet (vi fick instruktioner om vad vi skulle skriva och det skulle passa in i en dysfunktionell modell som inte kunde resultera i ett fungerande system). Lyckligtvis lades detta projekt ner under pandemin, i tysthet.
Nu har man i Stockholm gjort en ny upphandling. Den är överklagad i flera varv men beslut borde komma i Januari (skulle kommit i Maj 2024). Ett delprojekt är dock vad jag förstår tilldelat, om en integrationsplattform som ska knyta ihop ett antal delsystem som ska göra olika saker. Stockholm har nämligen valt att gå en annan väg, vilket jag tror är synnerligen klokt. Tyvärr gick kontraktet för integrationsplattformen till Tieto, som har gjort en liknande produkt tidigare för Region Örebro som jag hade den stora olyckan att arbeta med helt kort. Den var horribel. Förhoppningsvis lärde de sig något från den erfarenheten.
Angående vad läkare och sjuksköterskor vill ha så vill naturligtvis alla att systemet ska vara perfekt anpassat till just det jag gör. Problemet är att det finns så stor variation i vad folk gör och att folk i vården generellt är usla på att beskriva sina arbetsprocesser. Det är i praktiken omöjligt att alla ska få sin egen nischade applikation. Det man måste åstadkomma är att alla jobbar mot samma data och att man kan ha anpassade vyer i ett eller flera system som fungerar tillräckligt bra för det man ska göra. Detta finns det i stort sett möjlighet till idag i våra nuvarande system i Stockholm. Tyvärr ska huvudjournalsystemet (TakeCare) avvecklas och ersättas. Som slutanvändare är det bra, bästa av många som jag har jobbat med. För adminsidan är det mindre bra och vissa grejer är otroligt klumpiga. Databasen t.ex. är just en platt fil från början, en per patient. TakeCare är egentligen ett förvuxet labdatasystem och det märks när man gräver i det. Dock är det framjobbat under trettio år för vårdens specifika behov och löser många saker väldigt bra nu. I praktiken är det ett plattformssystem redan, det bara döljs i stor utsträckning för slutanvändaren (men man ser det när man vet var man ska titta).
I en drömvärld så skulle vi ha gemensam patientdata på nationell nivå. I någon mån kanske också viss administrativ data (inläggning, utskrivning, vårdprocesser, bokade besök mm) men det är inte säkert att detta skulle vara bra att ha nationellt (så länge vi har det sjukvårdssystem vi har). Mot denna data får man jobba med vilket system man behagar, bara man pratar via samma väldefinierade API. Problemet med detta är just att definiera datastrukturerna och APIet. Ja, det är mycket svårare än alla tror. Inklusive Anna_H och AndersMalmgren
Senaste åren har jag jobbat med ett specialistsystem för anestesi och intensivvård. Det är nu infört på Danderyd och kommer införas på SöS i vinter samt Karolinska i vår. Det är funktionellt men har enorma brister pga kass programmering av de som gjort det. Vissa designbeslut är för mig fullkomligt obegripliga men vad ska man göra. Exportera den här helt centrala siffran? Nej, den är inte åtkomlig för skriptmotorn eller integrationsmotorn. Varför? Ingen vet. Systemet är också regionalt men klarar inte av anpassning på vårdenhetsnivå vilket leder till att alla får köra i stort sett samma konfiguration utan möjlighet till lokal anpassning mer än på vissa väldigt speciella enheter. Det gör det långsammare och klumpigare än vad det behöver vara.
Nåväl, vi får väl se vad Region Stockholm till slut gör vad gäller huvudjournal. Jag hoppas det blir Cosmic, mest för att alla andra redan har det. Då blir det en de facto standard och kan driva mot ett nationellt system på sikt.
Vad gäller VGR och Skåne så tror jag att de kommer begrava sina Millenniumbaserade system. De kommer försöka göra det tyst och de måste byta ut massa människor i ledningen först för att rädda en del ansikten men jag tror inte att det någonsin kommer att tas i skarp drift. Systemet är helt enkelt för dåligt i grunden och icke anpassningsbart i tillräcklig grad. För kollegornas skull i de regionerna hoppas jag att jag har rätt...
VGR startade sitt projekt efter Skåne, och tog det live före Skåne. VGR var inte redo.
Ca 50 procent hade gjort utbildningen (som jag antar är obligatorisk)
Utbildningsmiljön var inte på plats.
Man hade inte byggt ordinationsmallar för läkemedel. Osv osv
Nä, precis, men då är det behörighetskontroll (i databasen) som förhindrar den åtkomsten, inte kryptering.
Ja, det vet jag naturligtvis. Det är just basen, Millennium. I Region Skåne heter det faktiskta projektet/systemet SDV och i VGR vet jag inte om det har ett egennamn (har dock för mig att jag sett något). Jag misstänkte också att det var ett worst case scenario som visades men likafullt är där delar som överhuvudtaget inte ska dyka upp, t.ex. om patienten är förmånsberättigad. Även överkänslighet är en typisk amerikansk CYA, att man måste ta ställning. Om patienten inte har en överkänslighet behöver jag inte registrera något i vårt nuvarande system. Givetvis är det något man kollar innan man förskriver men att behöva registrera ett negativt svar är ett typexempel på just medikolegalt extraarbete.
Grejen är att jag tror (med visst fog) att Millennium inte går att konfigurera på ett bra sätt för svensk sjukvård alldeles oavsett hur mycket tid eller resurser man lägger på det. Det jag fått se mycket av, Intensivvårdsmodulen, var så erbarmligt dålig att jag konstaterade att jag måste byta region om det införs.
Som jag skrev tidigare, på Vitalis i Maj 2024 kunde (eller ville) VGR inte visa livesystemet. Jag frågade. Det är ytterst anmärkningsvärt. De borde inte produktionssatt systemet, men det var väl som vanligt massor av prestige inblandat samt "vi hade ingen aaaaning, ingen har berättat för oss".
Utbildningen stämde inte med produktionssystemet, det har rapporterats av många. Även det en stor varningsflagga. Ja, det kan finnas små skillnader men inte så stora som verkar ha förelegat här.
Tror du att Skåne är redo? Kan man bli redo? Jag tror inte det.
Grejen är att jag tror (med visst fog) att Millennium inte går att konfigurera på ett bra sätt för svensk sjukvård alldeles oavsett hur mycket tid eller resurser man lägger på det. Det jag fått se mycket av, Intensivvårdsmodulen, var så erbarmligt dålig att jag konstaterade att jag måste byta region om det införs.
Som jag skrev tidigare, på Vitalis i Maj 2024 kunde (eller ville) VGR inte visa livesystemet. Jag frågade. Det är ytterst anmärkningsvärt. De borde inte produktionssatt systemet, men det var väl som vanligt massor av prestige inblandat samt "vi hade ingen aaaaning, ingen har berättat för oss".
Utbildningen stämde inte med produktionssystemet, det har rapporterats av många. Även det en stor varningsflagga. Ja, det kan finnas små skillnader men inte så stora som verkar ha förelegat här.
Tror du att Skåne är redo? Kan man bli redo? Jag tror inte det.
Satt nu och läste lite i VGRs sida om Millennium och jag hoppas verkligen att detta är ett fel, eller att det finns ett verifieringssteg på vägen.
"Information överförs inte bara från den medicintekniska utrustningen till Millennium utan kan också ske åt andra hållet. Till exempel kan ordinationsinformation skickas från Millennium till en infusionspump."
Detta diskuterade vi 2017 i Region Stockholm. Apotekaren som var ansvarig för den delen tyckte det verkade jättesmidigt. Sen berättade jag om Stuxnet och några andra exploits. Efter det var hon inte lika intresserad av att kunna styra läkemedelspumpar från något annat än knapparna på pumpen.
Föreställ er situationen där läkemedelspumparna helt plötsligt börjar ge 100 ggr för hög dos, eller stoppar. Det blir inte toppen...
"Information överförs inte bara från den medicintekniska utrustningen till Millennium utan kan också ske åt andra hållet. Till exempel kan ordinationsinformation skickas från Millennium till en infusionspump."
Detta diskuterade vi 2017 i Region Stockholm. Apotekaren som var ansvarig för den delen tyckte det verkade jättesmidigt. Sen berättade jag om Stuxnet och några andra exploits. Efter det var hon inte lika intresserad av att kunna styra läkemedelspumpar från något annat än knapparna på pumpen.
Föreställ er situationen där läkemedelspumparna helt plötsligt börjar ge 100 ggr för hög dos, eller stoppar. Det blir inte toppen...
Tyvärr är det så.Alfredo skrev:
Påpekar man hur korkat det är för leverantören så säger dem bara att det inte är någon som har beställt något annat.
Påpekar man det för beställaren så förstår de inte vad man pratar om.
Du kan kryptera fält så att innehållet är oläsligt för DBA även om en DBA kan nå tabellen.C cpalm skrev: