Nytt rapporteringsverktøy for klinisk praksis

Aktuelt
    ()

    sporsmal_grey_rgb
    Abstract
    Bakgrunn.

    Bakgrunn.

    Datasystemene ved vårt sykehus gir leger for liten oversikt over egne pasientgrupper. Ferdigdefinerte rapporter egner seg dårlig, og leveranse av nye rapporter fra datasystemene er tids- og kostnadskrevende. Vi ønsket å beskrive erfaringene vi gjorde når vi brukte et nytt verktøy for å hente ut kliniske opplysninger fra flere ulike datakilder ved vårt sykehus.

    Materiale og metoder.

    Materiale og metoder.

    To kardiologer spesifiserte hvilken klinisk informasjon de ville ha. Sammen med en IT- rådgiver med god kjennskap til sykehusets pasientadministrative datasystem, en rådgiver i fagavdelingen og førsteforfatteren møttes de tre ganger à 45 minutter. IT- rådgiveren brukte i tid 30 fulle arbeidsdager.

    Resultater.

    Resultater.

    Den kliniske informasjonen om kardiologiske pasienter ble presentert i en Qlikview-fil på 13 megabyte. Den inneholdt opplysninger om de 12 430 pasientene som hadde vært registrert innlagt på kardiologisk post 26 287 ganger de siste 21 år, samt disse pasientenes 530 912 laboratoriesvar de siste fem år. En del kliniske data var utilgjengelige fordi de ikke ble kodet eller lagret med systematisk bearbeiding for øyet. Noen databaser manglet eksportmuligheter, andre var kryptert av underleverandør.

    Fortolkning.

    Fortolkning.

    Qlikview vil kunne gi leger klinisk informasjon på tvers av mange ulike elektroniske pasientsystemer. Leger i sykehus med felles pasientsystemer vil kunne samarbeide og dele søk. Etter en oppbyggingsfase vil leger selv kunne søke etter informasjon uavhengig av normalarbeidsdager, dataprodusenters deltakelse og lokale IT- avdelingers prioriteringer.

    Abstract

    Background.

    A doctor’s tool for extracting clinical data from various sources on groups of hospital patients into one file has been in demand. For this purpose we evaluated Qlikview.

    Material and methods.

    Based on clinical information required by two cardiologists, an IT specialist with thorough knowledge of the hospital’s data system (www.dips.no) used 30 days to assemble one Qlikview file. Data was also assembled from a pre-hospital ambulance system.

    Results.

    The 13 Mb Qlikview file held various information on 12430 patients admitted to the cardiac unit 26 287 times over the last 21 years. Included were also 530 912 clinical laboratory analyses from these patients during the past five years. Some information required by the cardiologists was inaccessible due to lack of coding or data storage. Some databases could not export their data. Others were encrypted by the software company.

    A major part of the required data could be extracted to Qlikview. Searches went fast in spite of the huge amount of data. Qlikview could assemble clinical information to doctors from different data systems. Doctors from different hospitals could share and further refine empty Qlikview files for their own use. When the file is assembled, doctors can, on their own, search for answers to constantly changing clinical questions, also at odd hours.

    Artikkel

    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

    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

    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

    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.

    Manuskriptet ble godkjent 22.12. 2005.

    Oppgitte interessekonflikter:

    Erik Waage Nielsen har tidligere hatt en deltidsstilling i datafirmaet DIPS, som leverer sykehusets pasientdatasystem. Han har ingen økonomiske interesser i firmaet. De øvrige forfatterne har ingen oppgitte interessekonflikter.

    Oppgitte interessekonflikter: Se til slutt i artikkelen

    PDF
    Skriv ut

    Anbefalte artikler

    Laget av Ramsalt med Ramsalt Media