Sundhedsplatformen prækonfigureret til amerikanske tilstande: »Det kommer fra en helt anden verden«

Illustration: REDPIXEL.PL/Bigstock
Sundhedssystemet fra Epic kommer med hundredvis af inkonsistente og usammenhængende klassifikationer, fortæller forretningsarkitekt.

Det er langtfra blot et spørgsmål om oversættelse, når det amerikanskudviklede sundhedssystem Epic implementeres i Danmark under den favnende titel Sundhedsplatformen.

Platformen skal i år og næste år indføres på samtlige hospitaler i Region Sjælland og Region H.

Epic-systemet giver mange muligheder - men er også dybest set indstillet til en helt anden måde at drive et sundhedsvæsen på, fortæller klinisk forretningsarkitekt Gert Galster ved e-sundhedskonferencen Sundhedsobservatoriet.

Læs også: Nyt sundheds-it-system har haft mere end 9000 fejl på to uger

»Det afspejler en anden kultur, en anden struktur og nogle andre arbejdsgange. Det kommer fra en anden verden - og det giver udfordringer,« forklarer han.

En af udfordringerne ses i de forskelle, der er mellem terminologierne i Danmark og på den anden side af Atlanten, fordi systemet er leveret prækonfigureret til amerikanske tilstande.

Epic-systemet bruger sundhedsfaglige klassifikationer til indrapportering og til at hjælpe læger med at tage beslutninger. I USA importeres klassifikationerne fra en tredjepart - virksomheden IMO - i et format, der er komplekst, uigennemsigtigt og proprietært, fortæller Gert Galster.

»Man kunne forestille sig, at der ville være en sådan data-leverandør i Danmark. Det var der ikke,« fortæller forretningsarkitekten, der af samme grund blev del af en 'hastigt nedsat' arbejdsgruppe, der skulle konfigurere systemet til den danske virkelighed.

Læs også: Professor, læge og CIO om amerikansk klikhelvede: 40 pct. af lægerne har lyst til at sige op

Gruppen har fodret Sundhedsplatformen med data fra Sundhedsvæsenets Klassifikations System (SKS), der blandt andet dikterer, hvordan data skal meldes ind til nationale registre.

SKS-kategorierne er dog lavet til indrapportering og afregning - og ikke til at dokumentere, hvad der egentlig er sket med patienterne, og hvilken diagnose de har fået.

»For eksempel kan kategorier som hovedtraume og diabetes ikke udtrykkes i SKS,« forklarer Gert Galster.

SKS-begreberne måtte derfor suppleres af en bunke kliniske termer, som lukkede hullerne.

Læs også: Regionsdirektør: Lægerne må vænne sig til at diktafonen skal skrottes til fordel for it-systemer

Epic giver beslutningsstøtte til læger - blandt andet ved at trække på terminologisystemet SnomedCT.

»Hvis vi har en diagnose, og den kan udtrykkes med et SKS-begreb, som er mappet til et begreb i SnomedCT, så kan systemet give beslutningsstøtte,« forklarer Gert Galster.

Det eneste problem med strategien var, at ingen før havde mappet diagnoserne i SKS-ordbogen til SnomedCT-systemet. Af samme grund måtte arbejdsgruppen manuelt mappe 20.000 begreber i SKS til SnomedCT og indføre det i systemet med et Excel-ark.

»Det lyder måske fragilt, men det adskiller sig ikke fra resten af byggeriet: Excel-ark fylder rigtig meget i Sundhedsplatformen,« bemærker Gert Galster.

Læs også: Sundheds-it i luften på en weekend: »Det er en ny måde at implementere på«

Ud over de grundlæggende klassifikationsdata har Epic hundredvis af småklassifikationer, der ifølge systemarkitekten er uden sammenhæng og konsistens.

»Det viser sig, at der i USA er tre forskellige sygeplejersker med forskellige rettigheder og adgange. Dem slår vi i Danmark sammen til én med de rettigheder, vi ønsker. Og den øvelse har vi lavet igen og igen for de her småklassifikationer,« forklarer Gert Galster.

»Der er en helt klar terminologisk og klassificeringsmæssig udfordring,« fortsætter han og tilføjer:

»Selv efter fire måneder dukker der stadig spændende ting op.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (50)
Bent Jensen

Dem slår vi bare sammen.
"»Det viser sig, at der i USA er tre forskellige sygeplejerske med forskellige rettigheder og adgange. "

Hvorfor det, der findes mange former for sygeplejersker ?

Portøre, Fysioterapeut, Læge Sekretær, Kantine Personale, Rengørings Personale

Er de også oprettet og har forskellig rettigheder. Eller får alle bruger bare fuldt rettighed til alt, uden logning, det er jo også langt det nemmeste ?

Alle de overstående har jo også brug for data, som Kantinen der skal lave mad til bestemte grupper, Rengørings personalet skal vide om nogen er Isoleret, eller om operationsstuer skal bruges. Portøre skal vide hvor personer skal hen og til hvad. Eller er det slet ikke tænkt ind i systemet, og der køre noget separat til det, som ikke taler med det nye system ?
Hvis det er tilfældet, så er det ikke et nyt smart system, men bare noget nyt andet bras. Som kun er købt, så ledelsen nemmere kan få de data ud, som giver dem bonus.

"Udover den grundlæggende klassifikationsdata har Epic hundredevis af småklassifikationer, der ifølge systemarkitekten er uden sammenhæng og konsistens."

Så vi køber og indfaser et system der fra starten, er alt for bøvlet, og fyldt med gammel unødvendigt kode. Men vi som konsulenter, score kassen på tilretning her fra, og til system bliver skrottet.

Hvem har besluttet at det var netop Epic som skulle bruges, det lyder ikke som det, der giver flest tilfredse bruger. Og mange andre lande og hospitaler har brændt fingerne. Og hvad er det smarte ved en samlet sundhedsplatform, som under 1/3 af af landet bruger, eller er resten bare ikke så dumme. Men dette system. bliver der hvis slet ikke råd til et supersygehus på Sjæland ?

Men vi må formode at alle tilretning som disse og lignende er betalt af leverandøren, Sådan tilretninger og fejl kommer jo ikke som nogen overraskelse. Ellers skulle de mennesker som har lavet kontrakten fyres.

Man kunne også spørge om det er samme system, som betyder at 40% af lægerne i USA har tænkt sig at stoppe eller har det svært med at stå op til jobbet om morgen.

Om man har betalt for meget for system " Epic's leader, currently serving as CEO. Forbes estimates her net worth at $3 billion and put her at No. 243 on the magazine's annual list of the richest people in America."

Eller en helt masse andre ting, når man nu var igang om en artikel om Epic i Danmark. Her er der 10 spørgsmål til "Professoren" eller forretningsarkitekten .

http://www.beckershospitalreview.com/lists/10-things-to-know-about-epic....

Men vi kommer jo ikke til at betale det dobbelt for Epic, det er jo noget som leverandøren i følge kontrakten må betale for ikke ?

http://www.hospitalemrandehr.com/2015/08/24/nyc-hospitals-face-massive-p...

Og vi kommer ikke til at opleve det samme i Danmark

http://www.motherjones.com/politics/2015/10/epic-systems-judith-faulkner...

Bent Jensen

»Selv efter fire måneder dukker der stadig spændende ting op.«

Som nye muligheder, eller fejl der slår mennesker ihjel. Eller bare noget som bliver dyrt ?

Med hensyn til "10-things-to-know-about-epic...." så er det som her, også kommentaren der nogen gange kan være det væsentlige.

René Nielsen

»Det viser sig, at der i USA er tre forskellige sygeplejerske med forskellige rettigheder og adgange. Dem slår vi i Danmark sammen til én med de rettigheder, vi ønsker. Og den øvelse har vi lavet igen og igen for de her småklassifikationer,« forklarer Gert Galster.

Ikke for at være spydig, men er manden virkelig forretningsarkitekt?

En forretningsarkitekt bør vide at det svære lave den slags systemer ikke er det funktionelle, men udvikle sikkerheden, logs mv. På nydansk også kaldet Compliance.

Man skal med andre ord sikre at folk får den information de har brug for, men heller ikke mere og at der logges automatisk, således at man efterfølgende kan se "hvem gjorde hvad og hvornår".

Måske er han citeret forkert, men på mig lyder det som om, at hele Compliancekonceptet bliver bombet tilbage til stenalderen, med de ændringer han beskriver.

Anne-Marie Krogsbøll

Det lyder godt nok meget lidt betryggende - enorme mængder af muligheder for fejl i "oversættelsen" fra danske til amerikanske tilstande - som for mig at se ikke vil kunne undgå at være til alvorlig fare for patientsikkerheden - og datasikkerheden?

Når man har valgt et system, der fra starten tydeligvis sikke er gearet til det danske sundhedsvæsen (det må man vel have vidst?), kan det så tænkes, at det er fordi, der er kræfter i kulissen, der arbejder på, at det danske sundhedsvæsen skal ende med at ligne det amerikanske?

Og kan kyndige folk her hjælpe med at opklare, om dette umiddelbart temmelig ukloge valg af system kan have sammenhæng med de talrige forsøg på at tilegne sig vore sundhedsdata - ikke til brug for god behandling, men til brug for diverse forskningsprojekter og offentlig-private samarbejder, hvor data kan mines til økonomiske formål?

Der er stærke lobbyister med store pengetanke i gang med konstante offensiver: http://jyllands-posten.dk/debat/breve/ECE9079048/frigiv-sundhedsdata/
Kan nogle af disse have været medbestemmende i kulisserne mht. valg af dette tilsyneladende meget lidt gennemtænkte system? Kan det tænktes, at dette system passer perfekt til medicinalindustriens behov for datamining, så de ikke skal håndtere for mange systemer, mere end det passer til det lægefaglige arbejde i dagligdagen?

Eller er der virkeligt beslutningstagere, der med åbne øjne og fuldt informerede har valgt denne platform, og har ment, at de beskrevne tilstande ikke udgjorde noget stort problem?

Jeg bliver helt dårlig, når jeg læser ovenævnte artikel - det er svært ikke at falde i konspirationsteorigrøften. Gid jeg vidste, hvor det er man skal søge om aktindsigt i beslutningsprocessen uden at skulle bruge alt for mange kræfter på det.

Vi går barske tider i møde, hvis vi er så letsindige at blive syge og få brug for vores sundhedsvæsen fremover.....

Jesper Bergqvist

Ja, groft sagt er konklusionen er at enten er beslutningstagerne dumme eller onde.

Enten har man ikke gennemtænkt de sundhedskulturelle forskelle på det amerikanske og danske sundhedsvæsen, eller også har man bevidst valgt et system med de ovenstående problemer for at kunne høste strukturerede data på de danske patienter mhp forskning/videresalg/whatever.

Det ene udelukker ikke det andet, og jeg ved faktisk ikke hvad der er mest skræmmende...

Jesper Bergqvist

Mht beslutningsprocessen, er opgaven blevet sendt ud i licitation med ufravigelige krav til de systemer, som leverandørerne måtte byde ind med.

F.eks. Single-sign on, systemet skal have kørt på et stort antal klienter stabilt i lang tid, etc.

5 leverandører bød ind, og 3 af dem kom videre til en endelig udskillelse.

ca 1000 klinikere fra Region H og Region Sjælland blev inviteret til at se en præsentation af de 3 systemer, og give karakterer til systemerne ud fra et simpelt karaktersystem.
Disse betragtninger ville så blive taget med, når regionsledelserne traf en endelig beslutning.

Angiveligt gjorde EPIC (som står bag sundhedsplatformen) suverænt det bedste indtryk af de 3 "finalister", som blev set af klinikerne og regionsledelserne.

Dog har der ikke været tale om "hands-on" testing, men kun opsatte præsentationer.

Flere leverandører af mere enkle og brugervenlige systemer har udvist interesse for opgaven, (bl.a. Midt-EPJ og Cosmic, der bruges i 2 andre af landets regioner) men blev sorteret fra på kravet om at have kørt på et stort nok antal servere.

Slutteligt har det været regionsledelserne, der har truffet den endelige beslutning.

Sundheds-IT er meget komplekst, og der er også den reelle mulighed at EPIC/Sundhedsplatformen faktisk er det bedste/mindst ringe system man kan få pt.
(I hvert fald ud fra de krav, regionerne har stillet)

Allan Astrup Jensen

Hele lægestanden, på nær dem der er ansat på privathospitaler, må sige fra og boykotte dette system designet til betalings og forsikringssundhedssystemer og ikke har nogen nytte for patienterne i vort offentligt betalte sundhedssystem. Dette vil betyde, at systemet nødvendigvis bliver skrottet, hvis lægerne står sammen.

Jesper Frimann

Ikke for at være spydig, men er manden virkelig forretningsarkitekt?


Hvis du ser på mandens linkedin profil, så ser han så absolut ud til at kvalificere sig til at være Sundheds forretnings arkitekt++.
Og det funktionelle er jo netop det en forretnings arkitekt's skal have check på. Sikkerheds spørgsmålet er måske nok delt mellen forretnings arkitekten og så en sikkerhedsarkitekt. Det du beskriver med logs mv. er nok mest en Sikkerheds arkitekts område.
Mens det at formelt specificere de faglige behov, og lovmæssige behov for sikkerhed nok ville ligge hos en Forretnings arkitekt.

Tja ja..

// Jesper

Rene Madsen

Flere leverandører af mere enkle og brugervenlige systemer har udvist interesse for opgaven, (bl.a. Midt-EPJ og Cosmic, der bruges i 2 andre af landets regioner) men blev sorteret fra på kravet om at have kørt på et stort nok antal servere.

I den forbindelse, spurte man så ind til om det kunne lade sig gøre at få disse systemer til at køre på flere servere?
Bør spørgsmålet ikke hellere være om det kan skalere horizontalt og vertikalt, frem for om det kan køre på et stort antal servere?
Bør spørgsmålet ikke også være om det kan køre i redundant tilstand, på 3 nodes, så man undgår split-brain?

Spurte man de regioner der bruger systemerne allerede, hvad deres erfaringer er og hvad medarbejderne der rent faktisk bruger det i det daglige syntes om systemerne?

Thorkild Bach

Er det muligheden for en landsdækkende EPJ (Elektronisk PatientJournal), der ødelægges ved at de enkelte regioner indgår hver sine aftale uden koordinering?
I så fald er der vel grund til at få stoppet sådanne misgerninger.

Gert Galster

Kære polemikere,
Mangel på fakta og indsigt har jo aldrig været en hindring for en god debat, og der bliver som sædvanligt her rejst mange gode og spændende spørgsmål. Nogle af dem endda relevante i forhold til emnet.
I forhold til udgangspunktet - artiklen - er der to punkter, som har godt af en uddybning:

Hvis vi har en diagnose, og den kan udtrykkes med et SKS-begreb, som er mappet til et begreb i SnomedCT, så kan systemet give beslutningsstøtte.

Systemet kan give mange forskellige slags beslutningsstøtte. Evnen til at give beslutningsstøtte var - og er - en højt vurderet egenskab ved Epic-systemet. Det, der her er tale om, er diagnose-relateret beslutningsstøtte. Altså beslutningsstøtte, som tager udgangspunkt i, at patienten har en given diagnose(type). De andre slags beslutningsstøtte kræver ikke mapping til diagnoser.

Det viser sig, at der i USA er tre forskellige sygeplejerske med forskellige rettigheder og adgange. Dem slår vi i Danmark sammen til én med de rettigheder, vi ønsker. Og den øvelse har vi lavet igen og igen for de her småklassifikationer.

Sygeplejerskerne er blot et eksempel. Pointen er, at det amerikanske sundhedssystem har et meget stratificeret personale. Epic-systemet understøtter, at enhver lille personalegruppe har specifikke rettigheder, dens arbejdsopgaver er understøttet af specifikke funktionaliteter, og it-systemet sætter tydelige rammer omkring personalegruppens meget begrænsede muligheder. I det danske sundhedsvæsen, hvor der er færre og bredere personalegrupper, må systemets understøttelse af funktionalitet derfor være bredere. I forhold til den amerikanske konfiguration må man altså slå personalegrupper sammen for at afbilde den danske virkelighed. En bredere personalegruppe skal selvfølgelig have flere frihedsgrader og bredere funktionalitetsunderstøttelse, hvilket både stiller krav til en forståelse af personalegruppens arbejdsgange og systemets muligheder for at understøtte/begrænse dem.

Jesper Bergqvist

Jeg har ikke en superdetaljeret information om de enkelte, tekniske spørgsmål, der blev stillet i processen.
Kravet om størrelse var indført for at undgå at spilde tid på et system "bygget i garagen", som fungerer på lille skala, men crasher, når det skaleres op.

Mht erfaringer fra andre regioner, har der fra Region H og Sjællands side ikke været nogen interesse i at adaptere de andre regioners systemer.
Det kan virke bizart, men bag kulisserne har det i en del år været et prestigeprojekt for Region H at have deres "eget" IT-system, der gerne skulle være større, finere (dyrere?) end de andre regioners, for bagefter at få det udrullet over hele DK.
I den politiske prestige-kontekst giver det ingen mening at storebror hopper med på de små søskendes systemer.

Jesper Bergqvist

Den mere stratificerede tilgang til sundhedsvæsenet i USA slår også igennem ifm forsøget på at lave glidende patientforløb i DK.
Ambulatorier, sengeafdelinger og operationsgange er i EPIC helt separate søjler, der kun vanskeligt kommunikerer med hinanden.
Det har således krævet besværlige workarounds f.eks. at ordinere ambulante undersøgelser, der skal udføres efter en patient er udskrevet fra en sengeafdeling, imens patienten stadig er indlagt.
Eller at ordinere medicin, der skal gives under indlæggelsen til en planlagt operation, når patienten møder op i ambulatoriet for at blive gjort klar til operation.
Begge ovenstående eksempler er fuldstændigt almindelige og gængse arbejdsgange på mange afdelinger, og overgangen til EPIC har således tvunget en til at enten omlægge faste, indarbejdede rutiner, eller bruge tid på lappeløsninger.
Det er også derfor produktionen i regionen er gået kraftigt ned, og næppe når op på samme niveau som før EPIC i overskuelig fremtid

René Nielsen

Og det funktionelle er jo netop det en forretnings arkitekt's skal have check på. Sikkerheds spørgsmålet er måske nok delt mellen forretnings arkitekten og så en sikkerhedsarkitekt. Det du beskriver med logs mv. er nok mest en Sikkerheds arkitekts område.


Nu skal vi ikke have en lang diskussion om dette her, men set fra min stol mangler manden kendskab til hvordan store systemer er skruet sammen.

Han er - set udefra - ikke egnet til en overordnet arkitektrolle, fordi han nødvendigvis må have overlappende viden ind i tilstødende områder. Han behøver f.eks. ikke være ekspert i autorisationer mv. men han skal vide nok til at han ikke saboterer autorisationskonceptet med "sin løsning" og til at vide hvornår andre skal spørges før han forsætter med "sin løsning".

Det er da logik for burhøns at systemet ikke virker når såkaldte forretningsarkitekter bygger hver deres kongerige uden hensyn til det overordende flow og herunder sideordnede funktioners behov.

Vent og se! Om et par år kommer der en nyhed om at der ikke er styr på compliance/sikkerheden i EPJ-systemet og at man kan "se for meget". Til den tid - kan du/i tage dette indlæg "frem fra skuffen".

Søren Neermark

Den danske kontaktmodel til patientregistrering er unik i international sammenhæng. Det udfordrer alle leverandører der vil lave EPJ-systemer i Danmark og ville være kommet uanset leverandørvalg. F.eks. var Region Syddanmark (Cosmic) nødt til at betale 4 mio. kroner i efteråret til OUHs sekretærer til at inddække de merudgifter der var til færdigregistrering af patientforløb i forbindelse med årsafslutningen for 2015, således at hospitalet kunne få (korrekt) afregning for deres aktivitet. Her var der tale om en relativ simpel fejl.

Forskellen fra Cosmic til SP, er SP i langt højere grad satser på at spare på sekretærerressourcer ved at ligge registreringsopgaverne over på sygeplejersker og læger og til automatisering, blandt andet ved hjælp af de mapningstabeller i de nævnte excelark og SnomedCT, som automatisk skal indsamle oplysningerne når behandlerne klikker i journalen. Det gør at alle kliniske personalegrupper nu skal have en meget større indsigt i hvorledes den danske kontaktmodel fungerer og administreres. Det kan være meget udfordrende at lære for personalet om dette, når vi taler om grupper, som primært har deres fokus på patientbehandlingen og ikke registreringspraksis.

Systemet (SP) er desuden meget mere ambitiøst i forhold til automatisering af kodning og levering af data til diverse databaser (Cancerregisteret, Fødselsdatabasen mfl.) end de øvrige EPJ-systemer i DK. Med det højere ambitionsniveau kommer også en øget risiko for at noget ikke går godt, men potentialet er stort hvis det lykkedes da data bliver mere tidstro.

Kontaktmodellen bruges til en lang række ting og udgør "patientens røde tråd" i EPJ-systemerne. Det defineres om patienten er henvist til ambulant behandling, henvist til indlagt behandling, i ambulant behandling, indlagt eller skadestuepatient. Dette lyder jo umiddelbart meget enkelt, men i praksis bliver det meget komplekst, hvis patienten har forløb på fire afdelinger som alle er på forskellige steder i forløbet (HA, HI, A, S). Stort set alle supplerende data (blodprøver, patologi, røntgen, medicin, diagnoser og operationer) skal knyttes korrekt til forløbene. Problemer med kontaktmodellen vil derfor give en lang række problemer for de andre systemer, hvis de ikke kan knyttes korrekt til patienternes forløb. Hermed øges risikoen for fejl eller at væsentlige oplysninger ikke er synlige på det rigtige tidpunkt for behandlerne eller at der er for mange irrelevante oplysninger. Men igen vi har ikke nogen officielle udmeldinger vedr. dette fra SP-programmet, så det er ikke sikkert at det overhovedet er et problem.

Sundhedsplatforms-programmet har dog erkendt at uddannelsen ikke helt havde den ønskede standard ved implementering på HGH og et af de kurser som nu især udbydes, er netop undervisning i den danske kontaktmodel for at mindske problemerne på de efterfølgende hospitaler. Dette kan tyde på at der er en række problemer med det dette - omfanget ved vi dog ikke noget om endnu og kan blot være et mindre problem.

Det bliver spændende at se hvorledes implementeringen på Rigshospitalet kommer til at forløbe (12 dage), da vi her taler om Danmarks mest komplekse patienter set ud fra et registreringssynspunkt og rent behandlingsmæssigt. Går det godt på RH, går det godt også alle andre steder i de to regioner. Forhåbentlig har man fået forbedret uddannelsen og Sundhedsplatformens kode så meget, at vi ikke ser den samme uro som på Herlev/Gentofte.

Mads Bendixen

Er det muligheden for en landsdækkende EPJ (Elektronisk PatientJournal), der ødelægges ved at de enkelte regioner indgår hver sine aftale uden koordinering?
I så fald er der vel grund til at få stoppet sådanne misgerninger.


Hvis ikke man allerede har skrinlagt ideen om et fælles dansk EPJ, så kan man godt pakke den væk det næste lange stykke tid. Så vidt jeg har forstået er man endnu ikke færdig med sammenlægningen fra amter til regioner. At ligge endnu et lag på toppen giver ingen værdi, når man ikke har ryddet op i bunden efter sidste omgang.
Der er rigtig meget "gæld" man skal have afviklet inden man optager et nyt "lån".

Anne-Marie Krogsbøll

Gert Galster:
Tak for uddybning:
Fra artiklen:
"Epic-systemet giver mange muligheder - men er også dybest set indstillet til en helt anden måde at drive et sundhedsvæsen på, fortæller klinisk forretningsarkitekt Gert Galster ved e-sundhedskonferencen Sundhedsobservatoriet."

Og hvorfor har man så valgt et system, der er indstillet til et helt anden måde at drive sundhedsvæsen på?

Mht beslutningsprocessen, er opgaven blevet sendt ud i licitation med ufravigelige krav til de systemer, som leverandørerne måtte byde ind med.


Jesper Bergquist:
Tak for uddybning. Forstår jeg din kommentar ret? - Kan man mistænke, at de ufravigelige krav og de opsatte præstationer på forhånd har været skræddersyet til at få et bestemt resultat, altså at man på forhånd har ønsket, at et bestemt af systemerne skulle klare sig bedst?

Mads Bendixen
Jørgen A Thomsen

Og hvorfor har man så valgt et system, der er indstillet til et helt anden måde at drive sundhedsvæsen på?

En af de største synder ved systemudvikling er ukritisk at implementere en eksisterende forretningsgang uden først at se på, hvordan den kan forenkles og effektiviseres. Resultatet bliver ofte et komplekst rod, nu bare via IT.

Men selvfølgelig skal man ikke vælge et 'standardsystem', hvis det er baseret på en forretningsgang, der ikke er udtryk for en forenklet og effektiv tilgang til det eksisterende.

Anne-Marie Krogsbøll

J A Thomsen

Men selvfølgelig skal man ikke vælge et 'standardsystem', hvis det er baseret på en forretningsgang, der ikke er udtryk for en forenklet og effektiv tilgang til det eksisterende.


Det er svært at se, at det skulle være en god løsning at vælge et system baseret på et andet lands eksisterende, men helt anderledes, forretningsgang, og tro, at dette system så uden store problemer ville passe godt til danske forhold - med mindre man altså faktisk har planer om at indføre dette andet lands forretningsgang i Danmark. Mon man har/har haft sådanne planer?

Jesper Bergqvist

Og det er der, man muligvis har skåret nogen kritiske hjørner af i dette tilfælde. Regionerne har meldt åbent ud, at det ikke er "Rolls Royce"-modellen der er blevet købt, men en billigere standard model, hvor mange indstillinger er som de kommer fra producenten. (Altså tilpasset amerikanske arbejdsgange).
De ændringer, der efterfølgende ønskes, skal så laves af regionernes personale, uddannet af Epic.
Det tager længere tid, og bliver nok aldrig så godt, som hvis man havde brugt penge på at tilpasse systemet inden implementeringen...

Thorkild Bach

Hvis man ikke KAN eller VIL indføre en dansk EPJ, hvorfor så i alverden foregøgle noget som helst?
Hvad skal man så med alle disse systemer? Er det alene til ære for DJØF'ere, der skal have et nyt kontrolsystem inden for sundhedsvæsnet?

Thorkild Bach

Gert Galster: Tak for dine informationer.
Hvis jeg forstår det rigtigt, så har man med indførelse af amerikanske systemer med åbne øjne indført systemer, der IKKE KAN fungere med danske aktører inden for sundhedssektoren?
Hvis dette er rigtigt, hvad kan man så gøre for at fjerne disse skadelige personer - og hvad kan man gøre for at indføre systemer, som passer til det danske sundhedsvæsen?
Er indførelsen af de amerikanske systemer alene til ære for DJØF'ere og deres mulighed for at bestemmer over sundhedssystemet?

Jesper Frimann

Nu skal vi ikke have en lang diskussion om dette her, men set fra min stol mangler manden kendskab til hvordan store systemer er skruet sammen.


Det ofentlige bekender sig til oio som arkitektur framework. Det er et....ja view/flavor af TOGAF. Her er en Entreprise arkitekt for business. .også kaldet en forretnings arkitekt jo en der forstår forretningen. .i dette tilfælde sundheds sektoren.
Så han/hun vil typisk beskrive/modellere forretnings processer og beskrive roller formelt. Sagt med andre ord lave en formel model af forretningen,måske i samarbejde med en enterprise arkitekt. Det skal så siges at man bruger flere arkitekt titler i artiklen om manden 😁 så man kan godt lige komme lidt i tvivl om hvad der menes
// jesper

Anne-Marie Krogsbøll
Gert Galster

Og hvorfor har man så valgt et system, der er indstillet til et helt anden måde at drive sundhedsvæsen på?

Det har man, fordi systemet i et udbud er blevet vurderet til at være det bedste. En væsentlig faktor i denne vurdering var, at kunden - i modsætning til ved andre systemer - havde meget omfattende muligheder for selv at konfigurere systemet. Og det er præcis det, som man er i fuld gang med: Der konfigureres på livet løs.

Hvis jeg ser bort fra de konspirationsteoretiske vidtløftigheder og i stedet ser på den saglige del af debatten, har I vidtgående misset pointen:

Selvfølgelig er systemet fra starten konfigureret til USA-brug. Det interessante er størrelsen af det nødvendige konfigurationsarbejde, som hænger nøje sammen med, at der på flere niveauer er forskel på USA og Danmark - både hvad angår sundhedsvæsen og softwarehåndtering.
Med et så konfigurerbart system er spørgsmålet ikke så meget om, hvorvidt systemet vil kunne konfigureres til en tilfredsstillende løsning, men i langt højere grad om, hvor langt tid og hvor stor indsats der skal til, for at gøre det.

Anne-Marie Krogsbøll

Tak for svar, Gert Galster.

...har I vidtgående misset pointen:


Det interessante er størrelsen af det nødvendige konfigurationsarbejde, som hænger nøje sammen med, at der på flere niveauer er forskel på USA og Danmark - både hvad angår sundhedsvæsen og softwarehåndtering.


.....men i langt højere grad om, hvor langt tid og hvor stor indsats der skal til, for at gøre det.


Netop - det tror jeg faktisk netop, vi har forstået. Og med så omfattende indsats, som det lyder til at kræve, er risikoen for fejl vel tilsvarende stor - hvilket vel både indebærer risici ifm. patientbehandling og mht. risikoen for store ekstraudgifter.

Man kan stadig være nysgerrig efter, hvad det konkret er, dette system kan, som alternativerne ikke ville kunne bringes til at gøre.

F.eks. kunne jeg være nysgerrig efter, om EPIC indeholder andre og mere omfattende muligheder for kodning og udtræk af patientdata - evt. personidentificerbare - til forskning end de øvrige muligheder?

Søren Neermark

@Anne

Der er ikke nogen tvivl om at en højere strukturering af data vil give bedre muligheder for kodning og dataudtræk - det er jo netop formålet med Sundhedsplatformen!

Struktureringen er selvfølgelig under forudsætning af at det altså lykkedes med mapningen if. til SNOMEDCT/SKS til det ønskede niveau - ellers bliver det bare mere garbage in/garbage out.

F.eks. har SP for øjeblikket en udfordring med udskrivningsbrevene fra de praktiserende læger som nu indeholder for meget irrelavant information, hvis man bruger den automatiske funktion til dannelse af udskrivningsbreve. Derfor skriver visse læger selv en resume, hvilket jo er uhensigtmæssigt set ud fra et ressourceperspektiv, men det bliver forhåbentligt snart løst.

En del af udfordringen er at lære systemet hvilke negative fund der er vigtige og hvilke der ikke er vigtige. F.eks. kan det være vigtigt om en psykiatrisk patient ikke var selvmordstruet ved indlæggelse, mens det er ligemeget for Fru. Hansen med diabetisk fodsår. Disse mapninger kan hurtigt blive meget komplekse og ressourcetunge at vedligeholde.

I forhold til udtræk af data på personniveau:

Der er rigelige rapportmuligheder "indenfor" systemet, hvor der kan "bores" ned på personniveau, hvis man har de rette adgange (dvs. at man har patienten i behandling!).

I Sundhedsplatformen er alle data struktureret i MS SQL-database kaldet Clarity, som eftersigende skulle bestå af potentielt op til 18.000 subtables.

Jeg ved ikke hvem der har adgang til disse data, men jeg kan forestille mig at de bliver svære at komme i nærheden af, medmindre man har et klart defineret videnskabeligt projekt omfattet af Sundhedslovens §43, godkendelser fra datatilsyn, Sundhedsstyrelse og muligvis også etisk råd. Det er helt det samme som de regler der gælder nu - så ikke noget der kræver at man finder sølvpapirshatten frem (hvis den altså ikke allerede er fremme og foldet!).

En nærmere uddybning af spørgsmålene stillet i kommentarfelterne kan måske besvares af nedenstående links. Herudover kan man løbende følge med på twitter under #sundhedsplatformen.

Links:
Politikerspørgsmål omkring en lang række emner relateret til Sundhedsplatformens funktion og implementering:
http://tinyurl.com/jy5vovc

Omkring gevinster læs evt her (side 33 og frem):
http://tinyurl.com/judree6

Omkring funktioner i Sundhedsplatformen:
http://tinyurl.com/gul93cw

Statusrapport vedr. implementering af Sundhedsplatformen (side 74-80 fra 25.august 2016):
http://tinyurl.com/zbv9nfg

Timo Jensen

Som sædvanlig er vi i Danmark verdens bedste. Det kan derfor ikke undre at man bruger millioner på at ændre et fungerende system, til et dansk system.

Kunne det, teoretisk, tænkes at dansk sundhedspersonale for en gangs skyld kunne lære af udlandet? Og bruge STANDARDSOFTWAREN?

Enhver tilpasning vender tilbage som dyrt vedligehold. Det ved udviklerne, det ved leverandørerne. Der skal derfor en politisk vilje til, hvis vi skal have mere effektivt IT i Danmark. Det er ikke forventeligt at markedet vil undergrave sig selv, og slagte den guldkalv de har bygget,

Anne-Marie Krogsbøll

Kunne det, teoretisk, tænkes at dansk sundhedspersonale for en gangs skyld kunne lære af udlandet? Og bruge STANDARDSOFTWAREN?


Kan det lade sig gøre uden at indføre det amerikanske sundhedssystem i Danmark?

I øvrigt er det vel ikke sundhedspersonalet, der har besluttet, at softwaren skal tilpasses? Det er vel nogle politiske beslutningstagere, der har besluttet, hvad systemet skal kunne?

Gert Galster

@Timo:

Kunne det, teoretisk, tænkes at dansk sundhedspersonale for en gangs skyld kunne lære af udlandet? Og bruge STANDARDSOFTWAREN?

Når der nu ovenfor - helt korrekt - er anført, at den danske kontaktmodel er internationalt unik og at indberetning i henhold til den er selve grundstammen for dansk afregning, så er det svært ikke at stille spørgsmålet:
Hvad hulen er det for STANDARDSOFTWARE du har en forestilling om, vil kunne fungere her?

Gert Galster

@Anne-Marie:

Kan det lade sig gøre uden at indføre det amerikanske sundhedssystem i Danmark?


Det spørgsmål er for unuanceret til sådan bare lige at kunne besvares. Man kunne i Danmark let have en langt simplere indberetningsmodel end den danske kontaktmodel uden at have den amerikanske betalingsmodel. Jeg gætter på, at det er det, du egentlig spørger om.

Thorkild Bach

Jeg synes stadig, at der mangler fokus på problemet: Hvordan kan vi sikre, at der opnås en eller anden form for EPJ, der kan benyttes af ALLE inden for sundhedsvæsnet i Danmark - i ALLE regioner på samme tid.
Er der nogen, der kan beskrive, hvordan dette fungerer - kan fungere inden for de skitserede systemer?

Anne-Marie Krogsbøll

Jeg gætter på, at det er det, du egentlig spørger om.


Nej - det jeg egentligt spørger om, er det, du vist kalder fantasifulde konspirationsteorier (eller noget i den retning): Har man haft en skjult hensigt med at vælge EPIC fremfor alternative modeller, som faktisk er bygget til danske forhold?

Har man netop ønsket at tvinge det danske sundhedsvæsen til at fungere mere i retning af det amerikanske - via en trojansk hest i skikkelse af en tilsyneladende neutral, upolitisk sundhedsplatform, i stedet for at man havde taget denne ideologiske kamp i det åbne, hvor man måske kunne have svært ved at vinde gehør i befolkningen for en sådan kursændring?

Jeg synes, at du svarer lidt som "katten om den varme grød" - men det kan da være mig, der ikke kan få indstillet antennerne rigtigt i denne sag.

Anne-Marie Krogsbøll

Gert Galster:
Jeg glemte et spørgsmål:

Du har nævnt, at en af grundene til at vælge EPIC, var de mange konfigurationsmuligheder. Men hvad er det, man så gerne vil bruge disse til, som alternativerne ikke ville kunne levere? Hvilke muligheder er det, der manglende i de andre platforme?

Det er jo ikke et mål i sig selv at have mange konfigurationsmuligheder, hvis man faktisk ville have kunnet klare sig med de konfigurationsmuligheder, der var i de alternative systemer. Så hvad er det, de mange konfigurationsmuligheder i EPIC kan tilføre, som de øvrige platforme ikke kan? Nævn gerne helt konkrete funktioner, som man har ønsket, da et svar i retning af "Det giver flere valgmuligheder" jo ikke rigtigt er et svar på, hvad man faktisk ønsker, som de øvrige ikke kunne levere.

Mads Bendixen
Anne-Marie Krogsbøll

Tak, Mads Bendixen, det er så altså her, jeg bliver klogere. Ikke så dårligt en fredag morgen :-)

Men er det så heller ikke rigtigt forstået, at der er alternativer, der faktisk har fungeret i det danske sundhedsvæsen, jævnfør Jesper Bergquists kommentar ovenfor?

Flere leverandører af mere enkle og brugervenlige systemer har udvist interesse for opgaven, (bl.a. Midt-EPJ og Cosmic, der bruges i 2 andre af landets regioner) men blev sorteret fra på kravet om at have kørt på et stort nok antal servere.


I givet fald er det disse, jeg mener mht. alternative platforme, der allerede er tilpasset til danske forhold.

Mads Bendixen

I givet fald er det disse, jeg mener mht. alternative platforme, der allerede er tilpasset til danske forhold.


Det er der. Men om de er billigere eller bedre ved jeg ikke. Det kan også være nyere versioner af "modersoftwaren" der er budt ind med, som så skal tilpasses på ny.

Men MidtEPJ og COSMIC har heller ikke været uden problemer, f.eks.:
https://www.datatilsynet.dk/nyheder/nyhed/artikel/kritik-af-region-midtj...
http://www.computerworld.dk/art/226810/derfor-er-epj-heftigt-forsinket-i...

De er "indkøbt" for 6-7 år siden, så der kan desuden være andre tekniske grunde til at fravælge dem. F.eks. at de kun kører på ældre server OS versioner, som man ikke vil basere et nyt system på.

Gert Madsen

Nedlæg regionerne


Det er lidt som den amerikanske valgkamp.
Det vigtigste argument for at beholde regionerne, er sundhedsstyrelsens historik.

Hvordan kan det iøvrigt være, at vi i en tid, hvor man erkender fordelene ved Agil og stadig udvikling, absolut vil pege på vandfaldsmodellen for såvel IT, som arbejdsgange ?

Man kan jo ikke bevæge sig ind på en hospitalsafdeling, uden at falde over lavthængende frugter, og alligevel er al fokus på et monster som fælles EPJ.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017