Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, tilbud mm via telefon, SMS og email. I nyhedsbreve og mails fra Teknologiens Mediehus kan findes markedsføring fra samarbejdspartnere.
kronikken blog

Tør vi prøve nye veje til udvikling af Elektronisk Patient Journal?

Der har i de sidste par måneder være flere indlæg om, hvad Danmark kan lære af Kaiser Permanente (KP). I de forskellige indlæg fremhæves flere elementer, og alle nævner, at KP har et fuldt integreret it-system, der sikrer, at sundhedspersonalet altid har den information, de skal bruge på tværs af sektorer.

KP betjener 8,6 mio. medlemmer. Dvs. en leverandør af sundhedsydelser med flere kunder end indbyggere i Danmark, med en fælles it-basis - beundringsværdigt!

At købe KP's it-suite til Danmark vil blive overordentligt dyrt. Men der er måske også en anden vej for sundheds-it udviklingen i Danmark, der giver samme mulighed for fokuseret udvikling på fælles systemer. Veterans affairs (VA) i USA betjener 33 mio veteraner og har ligeledes foretaget markante forbedringer hvor eet fælles system, VistA, også er en krumtap i ændringerne, der på mange områder har bragt VA blandt de bedste sundhedsordninger i USA. Systemet er lagt ud til fælles eje og bruges mange steder i verden.

I det følgende er givet et bud på denne nye udviklingsvej, der potentielt kan give gevinster på flere fronter for Danmark. Men det kræver at flere interessenter flytter sig ud af deres komfort zone og samarbejder for optimal ressourceudnyttelse i vores sundhedsvæsen og dermed det fælles bedste.

Den nye udviklingsvej i dansk sammenhæng hedder fælles national OpenSource EPJ-udvikling til de store centrale systemer, der udgør EPJ- landskaberne. I første omgang med fokus på de systemer, der har specielle danske krav til arbejdsgange og registreringer. Kandidater er dermed PAS (patient administrativt system), notatmodul, booking og rekvisition/svar. Disse systemer skal desuden for flere regioner i udbud indenfor en årrække og muligheden for at afprøve nyt, er dermed nu tilstede.

Disse udbud resulterer ofte i monopol lignende tilstande der fastlåser og fordyrer. Men en fælles national OpenSource EPJ-udvikling skal styres.

Principperne kan være:

  • at der kun udvikles på et fælles system for alle regioner.
  • at udviklingen kickstartes ved, at regionerne i fællesskab efterspørger et færdigudviklet produkt som leverandøren er villig til at stille til rådighed som OpenSource efter fx en initial købssum eller de første 5 års service- og vedligehold.
  • at videreudviklingen baserer sig på internationale standarder og snitflader der muliggør salg af ydelser som service & vedligehold og tilhørende funktionalitetsmoduler med gadgets internationalt, for alle leverandører
  • udskiftningstiden til de nye systemer for regionerne bør være op til fx 5 år af hensyn til afskrivning af på de investeringer der er foretaget i flere regioner
  • Hvor der er gode kommercielle produkter på markedet, skal disse kunne integreres med OpenSource porteføljen.

Gode grunde til at komme i gang med fælles national OpenSource EPJ-udvikling:

Vi foreslår fælles national OpenSource EPJ-udvikling, fordi det er den udviklingsvej, der med størst sandsynlighed fortsat kan sikre konkurrence mellem de få leverandører, der er på det danske marked og sikring af danske udviklingsarbejdspladser for de pågældende systemer. Manglende konkurrence på flere af systemerne til sundhedssektoren er et problem og vil med de fælles udbud, der planlægges i regionerne/RSI regi, yderligere blive aktualiseret. Potentielt ender regionerne med en eller to leverandører, der udviser interessere for det beskedne danske marked og de 2 leverandører vil have monopol mange år frem i tiden.

Fælles national OpenSource EPJ-udvikling fordi det sandsynligvis også sikrer, at danske og skandinaviske leverandører har en overlevelseschance på sigt. Markedet er i en situation hvor det er "vind eller forsvind" fra det danske marked. Leverandørernes indtjening kan fremadrettet være baseret på betaling pr. udviklingstime for de leverandører, der har de bedste ideer indenfor forskellige funktionsområder. Også den overordnede styring kan være delvist udliciteret.

Den samlede økonomi der er tilrådighed til sundheds-it forventes at være uændret. Dvs. muligheden for fortjenste er tilstede, men potientelt med en anden fordeling mellem leverandørene.

**Fælles national OpenSource EPJ-udvikling **fordi regionerne funktionalitetsmæssigt kan komme meget længere ved fælles udviklingsindsats, hvor den samme funktionalitet ikke udvikles flere steder. For nuværende foregår udviklingen med et parallelt og ikke koordineret ressourceforbrug i regionerne. Hvis regionerne varetager forskellig funktionalitetsudvikling på de fælles OpenSource systemer og adderer det til de fælles systemer vil systemernes funktionalitet kunne øges med samme ressourceindsat som for nuværende.

**Fælles national OpenSource EPJ-udvikling **fordi it til sundhedsvæsenet ikke får tilført flere penge til udvikling, hverken i regionerne eller af staten (der spares alle steder i disse år og it viser ikke resultater, der tilsiger nye store investeringer). Dvs. vi må gøre mere med det vi har, hvilket er lig med optimering af ressourceforbruget både hos regionernes it-organisationer og ifbm. implementeringen i klinikken.

**Fælles national OpenSource EPJ-udvikling **fordi vi med bedre udnyttelse af udviklingsressourcer kan kanalisere de nødvendige ressourcer til afprøvning af nye innovative ideer. Fx som nye systemer til kronikerområdet, der muliggør journalføring i samme system fra både patient/pårørende, praktiserende læge, kommune og hospital. Flere af de nye innovative ideer kan udvikles sammen med gadgets (applikationer til mobiler, monitoreringsapparater mv.).

**Fælles national OpenSource EPJ-udvikling **fordi udvikling af innovativ funktionalitet kræver omfattende udviklings- og aftestningsforløb med brugerne, der både kan være patienter, pårørende, hospitalsansatte, hjemmehjælpere, praktiserende læger. Iterative usability studies og ordentlige aftestningsforløb tildeles oftest ikke tilstrækkelige ressourcer i dag, fordi det kræver flere ressourcer, end der ofte er til rådighed - hvilket udfordringerne med brug af EPJ i regionerne viser. De sundhedsprofessionelle bliver færre i de år, der kommer, derfor skal deres nødvendige deltagelse i udviklingsaktiviteter målrettes.

**Fælles national OpenSource EPJ-udvikling **fordi registrering og udveksling af data baseret på samme datamodel vil give os en enestående mulighed for opfølgning på kvalitet og udgøre en guldgrube af forskningsdata. Målsætningen er at data kun indtastes en gang og i kun et system. Det bør gælde for alle dele af sundhedssektoren.

**Fælles national OpenSource EPJ-udvikling **fordi OpenSource giver mulighed for, at alle, der har interesse, kan deltage i udvikling af små applikationer, der kan hjælpe en selv, ens forældre, andre pårørende eller hvem der nu er patient. Ved at slippe de kreative kræfter løs i form af hjemmeprogrammører, studerende og andre med interesse for området, får vi lagt kimen til udviklingsressourcer der ikke tidligere har været i spil. LEGOs inddragelse af brugere i udviklingen af Mindstorm kan tjene som eksempel.

**Fælles national OpenSource EPJ-udvikling **fordi Veterans Affairs i USA har vist vejen tidligere med deres VisatA OpenSource produkt. Dele af systemet er oversat til dansk og har vist sit potentiale til forbedring af en ambulatoriefunktion.

**Fælles national OpenSource EPJ-udvikling **fordi implementering af et fælles system vil reducere undervisningsmængden væsentligt ved rotation af medarbejdere i sundhedsvæsenet. Implementering koster altid minimum 1 time for at lære basisfunktionalitet i et nyt system og nok så vigtig at gamle arbejdsgange skal aflæres i forbindelse med indførelse af nye.

**Fælles national OpenSource EPJ-udvikling **fordi Danmark er ved at tabe vores forspring omkring brug af it i sundhedsvæsenet. Vi har i mange år solet os i den succes, som Medcom har givet med udveksling af meddelser mellem primær og sekundærsektor. Men mulighederne og ønskerne er væsentligt større i dag. Medcoms succes har bl.a været, at alle parter var enige om en måde at udveksle information på. Der er tid til at tage tilsvarende nye skridt nu.

Denfælles national OpenSource EPJ-udvikling, som er beskrevet ovenfor, tager primært udgangspunkt i EPJ på hospitaler. Dette er bevidst, idet der bør startes fokuseret. Hospitalerne udgør også en forholdsvis overskuelig interessegruppe med 5 regioner. Men perspektivet kan og bør også videreføres i de øvrige dele af sundhedssektoren. Dermed åbner de samme muligheder sig som hos Kaiser Permanente og Veterans Affairs.

Af Søren Zachariassen, sektionsleder, Civilingeniør og Martin Sølvkjær, IT-chef, læge, Merk. Dat., MPA

sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Det er en god ide, men hvorledes undgår vi at der går totalt rejsekort i det fordi alle mulige skal ind over ?

Håndplukker vi et "arkitekturråd" og giver dem autokratisk magt eller hvad ?

Poul-Henning

  • 0
  • 0

Modellen som fx W3C kører efter er rimeligt demokratisk, men tung. Et arkitekturråd lyder som en bedre ide - hvis ikke vi kan få PHK som enevældig hersker :)

Glimrende og perspektivrig kronik - lad det blive virkelighed!

  • 0
  • 0

.. men hvorledes undgår vi at der går totalt rejsekort i det fordi alle mulige skal ind over ?
Poul-Henning

Problemet eksisterer i dag også selvom der er tale om proprietære systemer. Enhver der har været med i "governance processer" ved at det er svært, da der skal kvalificeres, udvælges, innoveres og prioriteres.
Så min bud:
1. ved at tage et system, der har bevist sin værdi i forvejen - dvs ved at vi arbejder evidensbaseret.
2. ved et udbud overtager man rettighederne og koden af systemet
3. der udbydes en funktion, der på åremålskontrakt kan varetage vurdering og indslusning af moduler i rammeværket, så innovative tiltag indarbejdes, kan prioriteres andetsteds og kvalitetssikres
4. der er en overordnet prioriteringsfunktion, som prioriterer de midler, der er til rådighed for den samlede funktion (det er vel stat, regioner og kommuner, der skal have deltagere)
5. der etableres kompetenceklynger, der opbygger viden, evner og arbejder målrettet på løsninger
6. de faglige selskaber (læger, sygeplejersker, terapeuter, sekretærer mv) nedsætter grupper, der fungerer i 2 roller: rådgivende og som revisionsparter
Det sikrer at der både kan udvikles og innoveres i store centrale funktioner samtidig med at decentrale kræfter kan "komme til". Det er jo ofte sidstnævnte, som er tæt på brugen, der kan få ideer, som hjælper dagligdagen.
De nye teknologiformer i form af Apps og browserteknologier vil presse store ufleksible systemer ved små, hurtige, nyttige løsninger.

  • 0
  • 0

Kan man ikke foreslå "Danmark" sygeforsikringen, at de i lighed med andre gode formål støtter dette projekt med 5 mio. Bare for at komme igang.
/jakob

  • 0
  • 0

Jeg har også længe gået med samme tanker og har også tidligere foreslået det til Bent Hansen i Region Midtjylland.

Men jeg synes ikke man skal overtage kode og rettigheder ved udbud? Det giver da ikke mening.

Jeg synes man i Statens IT regi, eller lignende central placering, skulle have et overordnet ansvarligt arkitekturråd som PHK foreslår det.

Hele koden skal være være tilgængelig for alle i et central repository, som Statens IT er ansvarlig for.

På den måde vil de enkelte regioner/kommuner kunne udbyde mindre udviklingsopgaver som vil kunne varetages af alt fra små lokale udviklingshuse til store mastodonter som CSC.
Jeg mener IKKE at hele det forkromede "EPJ" skal udbydes som en samlet opgave - men at det skal deles op så der kan være flere aktører der kan bidrage samtidig og så man som region/kommune ikke er låst fast hvis en leverandør ikke lever op til forventningerne.

Samtidig skal det være et krav at systemet skal på opbygges på en sådan måde at driften af systemet ikke er fastlåst til en bestemt udbyder. Hvert 3-5 år skal driften af systemet i udbud, f.eks. med kravet om at det placeres i minimum 2 hostingcentre i hver deres landsdel.

  • 0
  • 0

selv statens forkromede EPJ projekt har rejsekort skrevet med store bogstaver på sig...

Mest fordi de firmaer der er indlejret i driften af sundhedssystemerne ikke har nogen fordel af det.

Dvs. at branchen som helhed ikke kan se noget formål med at deltage i implementeringen af de finurlige procedure detajler som alle hospitaler har.

At fjerne disse vil kræve omlægning af alle procedure og dermed nedlægning af ikke centrat micromanaged selvstyre... (plus et årelangt arbejde med at dokumentere og diskutere hvordan man skal gøre alt ned til detaljen fra et sundhedsfagligt synspunkt)

Og dem som "know how" hvordan man levere drift og udvikling til den ormerede af regler og små kongedømmer der findes i det ganske danske sundhedsland består af de har intet encitament til at hjælpe... mm de prøver at gøre sig selv arbejdtsløse...

Samtidigt er det danske sundheds software landskab særdeles modstands dygtigt mht forandring... Jeg har personligt pitchet et foreslag hvor man brugte sundhed.dk som det sted hvor borgeren loggede ind for at kommunikere med deres praktiserende læge i årevis og det har nu endeligt kommet så langt at det er kommet med i et større indstilling som en mulighed... for det er så smart at hver udvikler laver deres eget hjemmekogte webløsning til at opbevare fortrolig patient kommunikation på internettet, istedet for at det sted hvor alle kan loge ind med digital signatur og nemid. Sundhed.dk havde faktisk en sikker webmail funktion men den faldt som offer ved den sidste store drifts flytning (jup for webmail det er svært).

Men lad os skue tilbage i historien:

"Men læge og it-chef på Bisbebjerg Hospital, Martin Sølvkjær, tror på, at det kan gøres billigere og bedre ved overalt at indføre det amerikanske open source-system til patientjournaler VistA, som hospitalet lige nu er ved at teste på klinikken for kønssygdomme.

»For 10 milliarder kroner kan vi komme meget, meget langt med VistA. Jeg tror på, at man kan dække hele sundhedsvæsenet i hele landet med et fælles system og stadig have penge tilovers,« siger Martin Sølvkjær.

Han understreger, at systemet endnu ikke er taget i brug og afprøvet i daglig drift herhjemme, så hans tro er baseret på erfaringerne indtil nu – som har været positive. Til gengæld har det politisk krævet lidt kamp at få lov til at forsøge med et open source-system.

»Modtagelsen har ikke været overstrømmende entusiastisk,« konstaterer Martin Sølvkjær tørt uden at ville uddybe det nærmere."

Hvordan gik det forsøg for 3 år siden ?

Tea and dumplings eller fik du samme behandling som Uni-C da de tilbød uden betaling at oprette et mail baseret sundhedsdatanet hvor den enkelte besked ikke koster noget.

Uni-C fik den korte ende af pinden da de såkalde WAN leverandøre erklærede at hvis det var noget Danmark ville satse på så ville de trække sig fra markdet med øjeblikkelig virkning... Resultatet blev at vi idag har et netværk af FTP servere (læg mærke til at det ikke er SFTP servere) der synkronisere mapper mellem de store leverandøre og hver besked stadig koster 25 øre... 25 øre for en mail i 2011...

Var der nogen af de leverandøre der arbejder i sundhedsbranchen der gik ind og tilbød support og drift ? eller var de begrænset af at folk der har nattevagt i driftsafdelinger ofte arbejder for firmaer der betale løn og generelt prøver at tjene penge ? (som ved at levere en løsning de selv har udvilket ? vendor lock in ved at koble drift og produkt sammen er en effektiv måde at sikre sin indtægt).

Alt i alt lyder VistA som noget der er fantastisk men big bang løsninger er der mange der har fundet ud af ikke er heldige og en ting er hvis du skal vente lidt tid på at få dit hussalg tinglyst, men hvis du er bevidsløs på en skadestue så håber man at det ikke er der der er launch party for Amanda IV/Tinglysning/Rejsekortet...

En meget mere gennemførbar løsning som jeg har kommet med her tidligere er en central transaktionsserver. Denne er så at sige et central nav der binder de forskellige regioner eller sygehuse i regionerne sammen ved at holde øje med om de faktisk opretholder deres behandlings aftaler samt lever basale info så som medicin overfølsomhed og nuværende behanders kontakt info samt sikre at ens egen læge kan følge med (ved samtykke selvfølgeligt) om man skrider planmægsigt gennem sin kraftpakke osv.

Dette kan opnås ved at de enkelte sygehus systemer via de standard beskedtyper der findes idag kan indsende og modtage informationer fra serveren og hvis man fx flytter region så vil man dukke op på listen over patienter der skal behandles på den afdeling der tar sig af ens specifikke diagnosekode i ens nye region uden at man skal via sin nye læge og vente på at blive visiteret i den nye region osv osv osv. Det enste der vil kræves der er at ens nye addresse bliver registreret i den centrale transaktions server.

Denne løsning vil kunne rulles gradvist ud (ved i behandlings område pakker eller på enkelt behandlings niveau bliver inkluderet i serverens behandlings overvågnings scope).

Den vil IKKE kræve at man skifter alt ud for at det virker og de firmaer der står for driften på det enkelte sygehus vil ikke stå uden arbejde i morgen.

Dermed vil man kunne køre et skyggepilot projekt op parallelt med at de nuværende systemer køre videre. Derved vil man kunne få en indikation om det er noget der virker før man lader folke livs afhænger af det.

Hvis det så virker og scaler så vil man langsomt kunne klone de nuværende procedure over, fejlteste dem og så en dag når begge systemer har virket sideløbende et stykke tid slukke for det gamle besked baserede system.

Besked baseret system: eksempel, din læge sender dig til special læge der henviser dig til et hospital.
Hospitalet finder en knude de fjerner og sender besked om det til speciallægen da det er der henvisningen til hospitalet oprinder fra. Din egen læge (der er primært ansvarlig for din samlede behandling) får derimod kun besked hvis special lægen sender svaret videre.

Det kan virke men der er mange muligheder for at beskeder og patienter forsvinder mellem sprækkerne da man kun er forpligtiget til at bekymre sig til at man har modtaget positiv kvitering.

Der er ingen indbyggede korrektions procedure hvis fx en besked kommer til en forkert modtager og da der er mange systemer der ikke sender kvitering på modtagnebeskederne og ikke holder styr på at beskederne de sender bliver kviteret.

Desuden er der ingen systematisk patient orienteret forløbs kontrol over behandlingspakke niveau.

Denne opgave vil en central transaktions database kunne håndtere og samtidigt er det muligt at implementere det uden big bang løsninger.

mvh
Jakob

  • 0
  • 0

at udviklingen kickstartes ved, at regionerne i fællesskab efterspørger et færdigudviklet produkt

Den kan hurtigt gå hen og slå projektet ihjel, som et godt open source projekt.
lokal forankring, fra de parter der i første omgang skal anvende systemet er bindende nødvendigt - og ikke som "referater og møder" - men med lokale udviklere, så systemet hurtigt kan komme ud og blive afprøvet, og som kan arbejde for at lige præcis det behov de har, også kan komme med - det bliver hurtigt dyrt, hvis systemet ikke har fået tænkt modularitet og fleksibilitet ind fra starten af.

At det så ikke bliver et kludetæppe - skal sikres af noget central styring, der har et godt overblik for hvordan modularitet og fleksibilitet sikres.

  • 0
  • 0

"Et arkitekturråd lyder som en bedre ide"

Det gør det umiddelbart.
Desværre udvikler den slags sig altid til verdensfjerne elfenbenstårne.

  • 0
  • 0
  • at udviklingen kickstartes ved, at regionerne i fællesskab efterspørger et færdigudviklet produkt

Formuleringen med ”et færdigudviklet produkt” kunne have været ”det funktionalitetsmæssige bedste og mest fleksible produkt i forhold til prisen.”

Fordi et EPJ produkt kontinuerligt skal udvikle sig. Der vil hele tiden kunne adderes yderligere funktionalitet efterhånden som viden, behandlingsmuligheder og organisering i sundhedsvæsen ændre sig.
Det er denne videreudvikling af basis systemet og nye funktionalitets moduler, det er væsentligt at så mange som muligt kan deltage i og ikke kun de 1-2 leverandører der vil være på det danske marked om nogle år. I videreudviklingen ligger nemlig en væsentlig investering i systemernes levetid.
Udviklingen skal selvfølgelig foregå iterativt sammen med brugerne.

Og ja sporene skræmmer hos nogle af de mindre succesfulde IT projekter der bliver nævnt i debatten. Men dette OpenSource projekt foreslås ikke startet fra et blankt stykke papir, som flere af de andre projekter er. Det produkt der vælges, forventes at kunne tilfredsstille de væsentligste funktionalitets behov og dermed er man allerede godt i gang (det sikres selvfølgeligt også at systemet kan skalere med fornuftige svartider)

Måden at foretage en afprøvningen af OpenSource tanken kunne fx være ved at gå i EU-udbud via konkurrencepræget dialog. Derved kan leverandørernes villighed til at deltage i en OpenSource udvikling afprøves. Enkelte potentielle leverandører har udvist interesse.

Desuden bør man vel ikke lade sig skræmme af en udfordring? Hvis Veterans Affairs i USA har drevet en OpenSource udvikling i flere år, så kan vi vel også i Danmark – eller skal vi bare give op på forhånd?

  • 0
  • 0