Vårt hovedpasientdatasystem presenterer kliniske opplysninger om den enkelte pasient godt, men det har vært vanskelig å få oversikt over grupper av pasienter etter utvalg legen selv står for. Hos oss har ferdigdefinerte rapporter vist seg uegnet, fordi de som regel bare besvarte noen av spørsmålene. Straks det meldte seg nye spørsmål, kostet det så mye tid og/eller penger å få levert ny rapport at forsøket oftest ble oppgitt. Videre er klinisk informasjon lagret i ulike datasystemer og derfor vanskelig å sette sammen til en meningsfull helhet. Forsøk på å anskaffe såkalte datavarehusløsninger til vårt sykehus stoppet opp, blant annet pga. kostnadene. Flere sykehus i Sverige har i noen tid brukt det langt rimeligere elektroniske søkeverktøyet Qlikview (1). Programmet er utviklet ved Universitetet i Lund, og kan søke i mange ulike databaser for så å samle alle data på en plass- og minnebesparende måte (2). Søk i store datamengder skal gå raskt. Vi ønsket å beskrive erfaringene vi gjorde når vi brukte Qlikview til å samle data ønsket av to kardiologer ved vårt sykehus.
Materiale og metoder
To kardiologer spesifiserte hvilken klinisk informasjon de ønsket om pasienter innlagt ved kardiologisk post. Bortsett fra at informasjon bare skulle hentes fra allerede registrerte data og oppfattes som nyttig i egen klinisk praksis, ble det ikke stilt krav om dataønskene. Sammen med en IT-rådgiver (OS) med god kjennskap til sykehusets datasystem, en rådgiver ved Forsknings- og utviklingsavdelingen og en av forfatterne (EWN) møttes de tre ganger à 45 minutter.
Programmet henter data fra et stort spekter av datakilder (ODBC, OLE, XML, *.XLS, *.txt, osv.), for deretter å koble disse sammen i en egendefinert datamodell. Dataene trekkes ut av de opprinnelige kildene, slik at videre spørringer ikke blir en belastning for pasientdatasystemene. Data som ekstraheres, leses inn i datamaskinens minne og baserer seg på teknologi som QlikTech har kalt Associative Query Logic. Ekstraherte data lagres i filer, en for hvert uttrekk. Programmet kan prøves gratis i en periode (2).
Vi brukte data fra sykehusets pasientadministrative system (www.dips.no) og Akuttmedisinsk Informasjonssystem (AMIS). AMIS er et IT-støtteverktøy som benyttes ved de fleste akuttmedisinske kommunikasjonssentraler i sykehus samt ved legevaktsentraler og i ambulansetjenesten (www.helsekomponenter.no/).
Analysearbeidet foregikk i det tilgangsbegrensede sykehusnettverket. Qlikview-filen inneholdt avidentifiserte personopplysninger, men med en kode som gjorde det mulig for kardiologene å finne pasienten i det tilgangskontrollerte sykehusdatasystemet.
Resultater
Tabell 1 viser hvilken informasjon kardiologene ønsket samt eventuelle problemer med å få dem presentert i Qlikview. IT-rådgiver brukte 30 arbeidsdager på å sette seg inn i programmet, importere data fra de ulike pasientdatasystemer og presentere dem i én Qlikview-fil. Det tok ca. fire timer på en vanlig arbeidsdag å overføre data fra DIPS og AMIS til Qlikview. Overføringen skjedde til en tre år gammel PC (1.20 GHz Pentium III, m/512 MB RAM) på IT-avdelingen. Avlesningen foregikk parallelt med vanlig bruk av pasientdataystemet og uten reduksjon i ytelsen for det pasientadministrative systemet. Uthenting av data krevde ikke arbeid fra dataleverandørene og foregikk uavhengig av dem.
Tabell 1 Informasjon fra eksisterende datakilder ønsket av to kardiologer
|
Ønsket informasjon
|
Problem
|
Løsning
|
Demografiske data
|
Ingen
|
Alle ønskede data tatt med
|
|
|
|
Mortalitet
|
Finne riktige mortalitetsdefinisjoner og fremstille riktige data i Qlikview
|
Flere runder med diskusjon i gruppen. Ønskede data fremstilt til slutt
|
|
|
|
Innleggelse/Utskrivning
|
Ingen
|
Alle ønskede data tatt med
|
|
|
|
Tider
|
Ingen (utover definisjonsproblemer)
|
Et utvalg er tatt med
|
|
|
|
Ekko/dopplerdatabase
|
Databasen i ekko/dopplermaskinen GE Vivid 7 var lukket for oss
|
Ingen
|
|
|
|
Elektronisk EKG
|
Properitært lagringsformat. En samling binære data er lagret som én enhet i DIPS/Oracle. Leses ikke av Qlikview
|
Ingen. Eventuelt: 1) DIPS leser data ut til egne tabeller 2) Medit leverer tolkingsprogram av de binære data. Foreløpig ikke løst
|
|
|
|
Arbeids-EKG (AKG)
|
Kunne ikke lese data fra gammelt system
|
Ingen. (Nytt AKG installert i 2005 kan trolig eksportere data)
|
|
|
|
Myokardscintigrafi
|
Ikke koder, kun fritekstbeskrivelser
|
Ingen
|
|
|
|
Røntgen/ultralyd (eks. koronarangiografi)
|
Ikke lest inn i Qlikview-fil foreløpig, men skal gjøres
|
Utsatt foreløpig
|
|
|
|
Iskemisk EKG-overvåking med systemet MIDA
|
Data slettes fortløpende
|
Ingen
|
|
|
|
Laboratoriesvar
|
Laboratoriedata tilbake i tid er bare koblet til rekvirent og pasient. Dvs. ingen kobling til postopphold eller avdelingsopphold
|
Laget spørring som koblet laboratoriedata til postoppholdet tidsmessig
|
|
|
|
Fritekstsøk i alle journaler på en gang
|
DIPS har ikke gjort dette ferdig
|
Ingen
|
|
|
|
Luftambulansetransport-data
|
Lesing av data mulig, men PC er ikke i sykehusnett, og automatisk ekstrahering av data til Qlikview-fil er derfor vanskelig
|
Ingen
|
|
|
|
Akuttmedisinsk Informasjonssystem (AMIS)
|
Kobling til riktig pasient
|
Brukt personnummer som siden er kryptert
|
Til uthenting av data kjøpte vi en utviklerlisens (QlikView Enterprise 6) for kr 22 080 uten mva. Eier og leverandør av QlikView er QlikTech International AB (www.qliktech.com), mens SternerData AS er representant i Norge for QlikTech og QlikView, med hovedvekt på helsesektoren. I tillegg kostet rimeligste versjon for kardiologene til egne søk i ferdige filer ca. kr 3600 uten mva.
Den kardiologiske Qlikview-filen inneholdt data fra de første registreringene startet i Kommunedata Østlandet 1984 – 86, og data fra DIPS i perioden 1986 – 2004. 12 430 pasienter har vært innlagt ved kardiologisk post i disse 21 årene, fordelt på 26 287 opphold.
Det var satt 64 486 diagnoser, hvorav 24 816 var hoveddiagnoser. I ICD-9-kodeverket var de tre hyppigste hoveddiagnoser angina pectoris (n = 2958, 23 %), akutt myokardinfarkt (n = 2816, 22 %) og atrieflimmer (n = 939, 7 %). I ICD-10-kodeverket var de tre hyppigste hoveddiagnoser atrieflimmer og atrieflutter (n = 1211, 12 %), ustabil angina (n = 672, 7 %) og uspesifisert brystsmerte (n = 509, 5 %).
Det var utført 530 912 laboratorieanalyser de siste fem år. Det tok mindre enn ett sekund å finne at 28 619 hemoglobinmålinger var utført, og at 25-, 50- og 75-percentilverdi var henholdsvis 9, 8, 11,3 og 13,1 g/100 ml.
Data fra AMIS ble fremstilt på linje med data fra DIPS og ble blant annet brukt for å finne pasienter som ble fløyet videre med luftambulanse.
Qlikview-filen påviste flere steder mangelfull prosedyre- og diagnosekoding i det pasientadministrative systemet. Analysearbeidet krevde innføring i bruk av Qlikview og foregikk som kollokvier i analysegruppen. Legene klarte selv å gjøre søk, lagre kompliserte søk som bokmerker for gjenbruk og lage grafer og Pivot-tabeller. Søkeresultatene inkludert søkekriteriene lot seg eksportere til regnearket Excel automatisk. Analysegruppen diskuterte tilgangskontroll til egne pasientdata, bruk av definisjoner, tolking av data og formulering av presise spørsmål.
Diskusjon
Vi har beskrevet i hvilken grad et nytt verktøy hentet ut kliniske opplysninger fra flere ulike datakilder ved vårt sykehus i forhold til situasjonen før, nemlig ingen rapporter eller ferdigdefinerte rapporter. Vår studie er ikke en systematisk og vitenskapelig vurdering av verktøyet Qlikview. I utprøvingsfasen ønsket vi ikke å sette andre krav til innsamlingen av data enn at kardiologene selv antok de ville være nyttig i egen klinisk praksis. Arbeidet avdekket at flere kliniske data ikke ble lagret med dataanalyse for øye. Fritekstbeskrivelsene i myokardscintigrafien ble verken gruppert eller kodet og egnet seg dårlig for systematisk analyse. Dette ble først tydelig pga. analysearbeidet. Det ble også oppdaget at beskrivelser om PQ-tid, akser, ST-endringer etc. samt tolkinger fra elektroniske EKG, ikke kunne leses inn i et eksternt rapporteringsprogram, verken av oss eller av DIPS. Det er mulig å oversette data, men verken EKG-produsenten eller DIPS ønsket å prioritere dette. Vi mener at alle pasientdata bør være lagret på et allment kjent format, slik at sykehuset kan forvalte disse data uavhengig av leverandør. Legene er nå i større grad blitt opptatt av dataeksportmuligheter fra overvåkings- og undersøkelsesutstyr. Kardiologene ønsket videre å bruke en mulighet i DIPS til å søke i fritekst i alle de kardiologiske pasientjournaler samtidig for å finne ekkodopplerundersøkelser som ikke var prosedyrekodet. Foreløpig er ikke dette blitt prioritert av DIPS.
Uthenting av data slik vi gjorde uten hjelp av DIPS, AMIS eller eksterne datavarehus, gjør at leger kan få tilgang til egne pasientdata på en brøkdel av tiden og til en langt lavere pris. Tidsaspektet er i mange tilfeller avgjørende for om leger kommer til å bruke kliniske rapporter. Vi mener at sykehusene ikke må godta at det skal være opp til dataleverandører å bestemme om og når leger skal få tilgang til egne data. Dersom regionale helseforetak ønsker å sentralisere sin datadrift, må det av samme grunn ikke gå på bekostning av direkte tilgang til pasientdata ved eget sykehus.
I trange sykehusbudsjetter kan prisen være avgjørende for om det i hele tatt hentes ut data. Vi tror det var avgjørende for oss. I prøveperioden har vi klart oss med en minimumsløsning. Leverandøren anbefaler imidlertid sykehus med mange brukere å benytte en egen Qlikview-server. Det letter administrasjonen av uttrekkene og gjør det mulig å ivareta personvern og datasikkerhet i en høy grad. Prisen for server, én utviklerlisens og 20 brukere oppgis til ca. kr 200 000 uten mva.
Den kardiologiske Qlikview-filen kan oppdateres kontinuerlig. Søk kan også gjøres automatisk og regelmessig, og resultater utenfor oppgitte rammer kan varsles via e-post. Vi har ikke prøvd de mulighetene. Søk i en halv million laboratoriedata gikk raskt, men våre forsøk på å lese inn om lag 25 millioner rader med laboratoriedata fra 21 år oversteg de ca. 10 – 12 millioner rader som var kapasiteten for vår datamaskin. Alle våre laboratoriedata ville imidlertid kunne leses inn ved bruk av datamaskiner med 64-bits prosessor og operativsystem som kan utnytte et langt større minne. Det er med en slik løsning Tysklands legeforening skal bruke Qlikview for å analysere over to milliarder rader med individuelle lege- og pasientdata (3). Vi valgte hemoglobin som eksempel, fordi det var den analysen som ble hyppigst rekvirert av kardiologene og fordi en ny artikkel viser at hemoglobin er en kraftig og uavhengig prognostisk faktor ved akutte koronare syndromer (4).
I dag øker kravet om kvalitetssikring og forskning i sykehus. Norske sykehusleger sitter på en gullgruve av kliniske data i digitalisert form som legene er de beste til å tolke. Ofte ligger data lagret i forskjellige IT-systemer som ikke kommuniserer seg imellom, men vi har vist at data fra AMIS og DIPS lar seg søke i samtidig. Vi tror dette vil gjelde mange andre systemer også.
Bruk av Qlikview motiverte kardiologene til kvalitetssikring av prosedyre- og diagnosekoding for å få så nøyaktige data som mulig. Det ble også klart at diagnose- og prosedyrekodene vi fant, gjaldt hele oppholdet på medisinsk avdeling. Det går altså ikke an å koble prosedyre- eller diagnosekoder kun til oppholdet på kardiologisk sengepost med mindre pasientene ble lagt inn og utskrevet direkte derfra.
Ut fra erfaringene nevnt over tror vi at legers bruk av Qlikview ved sykehus bør begynne i små grupper hvor IT-kyndige deltar. Slike små kliniske analysesentre kan lære opp nye leger og sikre at data blir innsamlet og anvendt i henhold til personvern og datasikkerhet. Qlikview-filer kan deretter med fordel videreutvikles og deles som et dugnadsarbeid mellom sykehus, uten utgifter til royalties, IT-konsulenter eller programvareleverandører.