IT-løsning for håndtering af data i et klinisk forskningsprojekt

Transkript

1 IT-løsning for håndtering af data i et klinisk forskningsprojekt Christian Michael Kongens Lyngby 2009 IMM-B.Eng

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax IMM-B.Eng

3 Resumé Resumé Denne rapport dokumenterer udviklingen af et IT system med mulig anvendelse indenfor klinisk forskning baseret på medicinsk billedmateriale i DICOM I formatet. Projektets baggrund er en henvendelse til Siemens Healthcare fra en overlæge i kardiologi, som efterlyste et system til indsamling, registrering og opbevaring of ultralydsscanninger af hjertet, med henblik på analyse i et internationalt multicenter forskningsprojekt. De fundamentale krav til systemet er formuleret som værende: Sikker transport af anonymiserede data, understøttelse af arbejdsgange og en tilførelse af fordele sammenlignet med en nulløsning: At sende billedmaterialet på CD med kurer, efterfulgt at registrering og indlæsning af data i en ikke nærmere specificeret Workstation. Et system til at håndtere dette problem foreslås designet som et database-system med klientapplikationer til de 2 brugergrupper: Klinikere og forskere. Hertil kommer et support website. DICOM filer indeholder obligatoriske tags i headeren med personfølsomme data (navn, ID), og kan derfor ikke uproblematisk anvendes til forskning. Et kardinalpunkt i systemdesignet er derfor sikring af patienters anonymitet. Dette håndteres ved passende erstatning af obligatoriske (type 1) DICOM tags, samt fjernelse af andre ikke obligatoriske tags som kan indeholde sensitive informationer. Dette foregår inden data transmitteres til databasen. Desuden maskeres eventuel sensitiv information i billeddata ( burned in annotation ). Anonymisering efter at data er produceret gør det muligt at anvende data til forskningsprojekter uden at ændre sædvanlige arbejdsgange. Klientapplikationen til klinikerne må forventes at blive anvendes sjældent, og brugergrænsefladen er derfor designet med hensyn til dette. En usability test afslørede insufficient overskuelighed og manglende feedback fra systemet, hvilket er søgt imødegået. Yderligere usability tests med brugergrupperne er påkrævet for at sikre, at mål om brugervenlighed opnås. Skal udviklingen af systemet fortsætte må det endvidere vurderes, om opnåelse af nødvendige godkendelser fra myndighederne vil betyde, at det ikke er muligt at understøtte udstyr fuldt ud, grundet problematikken omkring private tags. I Digital Imaging and Communications in Medicine

4 ii

5 Indholdsfortegnelse Resumé... i 1 Baggrund Analyse Problemstillinger ved anonymisering af DICOM data Særlige vanskeligheder ved anonymisering af DICOM data Juridiske krav Brugervenlighed Kravspecifikation Funktionelle krav Design og implementering Udviklingsplatform og anvendt software Informationsflow Komponenter i klientapplikationerne Modifikation og udtræk af data i DICOM headere Brugergrænseflade Konklusion Appendiks A: Anonymiserings algoritme for et FDA og CE godkendt PACS system Appendiks B: Scripts til opsætning af MySQL database Referenceliste... 45

6 iv

7 KAPITEL 1 Baggrund 1 Baggrund Dette projekt blev startet op i min praktikperiode his Siemens Healthcare (dengang Siemens Medical Solutions) i vintersemesteret En overlæge i kardiologi havde henvendt sig til min virksomhedsvejleder for at forhøre sig om, muligheden for at tilvejebringe en IT baseret løsning til et konkret forskningsprojekt, som var i planlægningsfasen. Forskningsprojektet var internationalt med en amerikansk pacemaker producent som sponsor. Lægen som kontaktede Siemens var kandidat til at stå for projektets gennemførsel, og ønskede at kunne tilbyde en komplet løsning. Ikke blot på den kliniske side, men også den praktiske udfordring med indsamling og opbevaring af data. Det er denne praktiske udfordring som dette eksamensprojekt beskæftiger sig med. Det basale problem var således, set fra den tekniske side, indsamling af medicinske billeddata (specifikt ultralydsscanninger af hjertet) i DICOM II format og samt opbevaring af disse data i en 5-årig periode, hvorefter data skulle anvendes til forskning. Jeg arbejdede på projektet i begyndelsen af min praktikperiode, hvor min opgave var at undersøge løsningsmuligheder og fremkomme med et skitseret løsningsforslag, som kunne danne basis for en vurdering af rentabiliteten for Siemens Medical Solutions. Derpå blev en simpel interaktiv Power-point prototype præsenteret for kunden. I slutningen af praktikperioden (dec og januar 2008) arbejdede jeg på en prototype, som derpå blev demonstreret for den overlæge som havde kontaktet Siemens. Forskningsprojektet blev ikke realiseret, da, så vidt jeg har forstået, overlægen konkluderede, at projektet ikke så ud til at finde en snarlig afklaring mht. hvem der skulle være ansvarlige for gennemførslen, og at det mulige udbytte ikke stod i II Digital Imaging and Communications in Medicine

8 2 1 Baggrund fornuftig relation til den tid han investerede. Imidlertid udtrykte han stor interesse for den basale funktionalitet i prototypen hvor han så potentiale for et mere omfattende peer-review system. Det var et aktuelt problem på pågældende sygehus, at mange undersøgelser skulle gøres om ved overflytning af patienter fra andre sygehuse, da de ikke havde fælles PACS III eller en platform for diagnostik af ultralyds-sekvenser som er fuldt kompatibel med scanninger fra udstyr med forskellige producenter. Jeg valgte dog på et tidligere tidspunkt at gøre IT løsning for det kardiologiske forskningsprojekt til mit eksamensprojekt. Det var fra kundens side anslået at ca patienter skulle indgå i undersøgelsen, og at disse skulle udvælges på basis af en evaluering af fast-track undersøgelser i forskningsprojektets første år. Derpå skulle der laves årlig opfølgende ultralydsscanning i de følgende 4 år. Den økonomiske ramme blev baseret på anslåede priser for nulløsningen : Forsendelse af ultralydsundersøgelser på CD-ROM med kurer-post, samt katalogisering af data og at lægge det ind i det eller de systemer, som siden skulle anvendes til den kliniske analyse. Denne økonomiske ramme fastlagde den øvre grænse for omkostningerne ved udvikling og drift af en IT løsning til forskningsprojektet. Løsningsmodellen skulle udmærke sig ved at være billigere og eller tilføre væsentlige fordele sammenlignet med den ovenfor skitserede nulløsning. III picture archiving and communication system

9 KAPITEL 2 Analyse 2 Analyse 2.1 Problemstillinger ved anonymisering af DICOM data Anonymisering af DICOM header data er en opgave som kan løses via adskillige gratis og kommercielle løsninger. Alle løsninger fjerner type1 tags indeholdende sensitive informationer (PatientName og PatientID), men mange andre standardiserede tags kan indeholde information som indirekte kan identificere patienten. Type 3 tags såsom PatientsAddress PatientTelephoneNumbers og OtherPatientIDs må også anonymiseres. Private tags med datatypen PN (=Person Name) kan potentielt indeholde direkte identificerende information. Mange eksisterende løsninger går radikalt til værks ved at fjerne alle private tags, hvilket kan kompromittere de diagnostiske muligheder. I Appendiks A ses detaljer for anonymiseringsproceduren i det FDA (Food and Drug Administration, USA) og CE (EU) godkendte WebPAX system, som stilles gratis til rådighed af HeartIT 1. Det skal bemærkes at systemet tilsyneladende ikke understøtter DICOM standardens Part 10 fuldt, da en fuld undersøgelse med DICOMDIR ikke kan uploades, men blot de enkelte billeddatafiler. I det system som her designes vil DICOMDIR filen bestemme hvilke data der skal uploades, således at et helt studie bliver uploadet i den sammenhæng som det er tiltænkt. Citat fra Dicom part 10 2 : DICOMDIR File: A unique and mandatory DICOM File within a File-set which contains the Media Storage Directory SOP Class. This File is given a single component File ID, DICOMDIR.

10 4 2 Analyse Særlige vanskeligheder ved anonymisering af DICOM data BurnedInAnnotation tag med værdien YES, indikerer, at pixeldata indeholder tekst, som kan identificere patienten. Da dette tag er type 3 (ikke påkrævet) kan man ikke forvente at det anvendes af alle producenter. F.eks. anvender Acuson Sequoia serien af ultralydsscannere ikke dette tag, til trods for at Burned In Annotation altid er til stede i billeddata. Med Acuson Antares anvendes et privat tag til at indikere om der er burned-in graphics eller om denne information i stedet er placeret i et overlay. Det er derfor ikke muligt blot at ekskludere alle file-sets som ikke har Burned In Annotation tag et sat til NO, da man dermed afskærer sig fra at anvende data fra en stor del af det udstyr som er i daglig anvendelse på kardiologiske afdelinger. Burned in annotation må enten adresseres i forsøgsprotokollen eller håndteres med teknisk, som det tænkes implementeret i dette projekt. For at kunne automatisere fjernelse af burned in annotation kræves en præcis viden om hvor i billedet oplysningerne om patienten befinder sig. Er der tale om eksport direkte fra ultralydsudstyret til et Dicom File-set (typisk lagret på CD/DVD) kan Manufacturer og ManufacturerModelName i reglen anvendes til at identificere udstyret entydigt, og dermed kan det associeres med et koordinatsæt for maskering af pixeldata. Mere sikkert er det imidlertid at anvende Type1 tag et Implementation Class UID, som entydigt henviser til DICOM implementeringen som sidst modificerede billedet. Dette er et type 1 tag, og vil således altid være tilstede. Der introduceres der imidlertid et nyt problem når eksempelvis GE Vingmed billeddata eksporteres fra EchoPAC eller EchoPAC PC PACS systemer og ikke

11 2.1.1 Særlige vanskeligheder ved anonymisering af DICOM data 5 direkte fra modaliteten, idet både ManufacturerModelName og Implementation Class UID overskrives med PACS systemets værdier. Identifikation af billedproducerende udstyr. Identifikation af udstyret som producerede billeddata er vigtigt af flere årsager. For det første er der fjernelse af Burned In Annotation. For det andet må man for at få det fulde klinisk-diagnostiske udbytte af data i reglen anvende den fuldt kompatibel arbejdsstation, som understøtter udstyrets private tags. Et relevant eksempel er GE Vingmed, Vivid7 ekkokardiografi scanneren. Den anvendes i den afdeling hvor lægen, der efterlyste et system til håndtering af DICOM data i et klinisk forsøg, har sin daglige gang. Ifølge den seneste version af den offentligt tilgængelige DICOM conformance statement 3 anvendes BurnedInAnnotation tag et hvis billeddata indeholder information som kan identificere patienten, men modelnavn, der ellers sættes til Vivid7 af ultralydsscanneren overskrives hvis billeddata eksporteres fra EchoPAC eller EchoPAC PC Workstations, som det må formodes at være almen praksis. DeviceSerialNumber kan ikke bruges som alternativ identifikation af modellen, da det ikke anvendes. Implementation Class UID et overskrives ligeledes, som ellers er en præcis identifikation af den pågældende DICOM implementering. Dette betyder at der må kræves en direkte eksport fra apparaturet eller at alle GE Vingmed DATA med EchoPAC eller EchoPAC PC som modelnavn, skal maskeres med det samme rektangel for at kunne sikre korrekt anonymisering i tilfælde af BurnedInAnnotation. Det kræver yderligere undersøgelser for at finde ud af om denne strategi kan anvendes. Hvis den skal kunne anvendes skal annotationen findes i samme område af billedet uafhængigt af hvilken model der er tale om.

12 6 2 Analyse Det ser ud til at en entydig identifikator er StudyInstanceUID tag et (type 1), som beholder sit originale indhold trods eksport til en EchoPAC workstation. I de 2 datasæt jeg har testet (et fra 2001 og et fra 2008), som begge er eksporteret fra EchoPAC workstations, indgår tilstrækkelig information fra ImplementationClassUID i StudyInstanceUID tag et til at identificere udstyret som Vivid7. Dette gælder også for Acoson Sequoia serien. Det må dog undersøges om dette gælder generelt for Dicom implementeringer, da der ikke er et krav i DICOM standatden at StudyInstanceUID genereres på basis af ImplementationClassUID. Producentspecifikke løsninger kan altså næppe undgås. Fra Dicom Conformance statement for GE Vingmed Vivid7 4 : ImplementationClassUID: StudyInstanceUID: Unquely generated by equipment Fra Dicom Conformance statement for GE Vingmed EchoPAC PC 5 : ImplementationClassUID: StudyInstanceUID: Unquely generated by equipment Tag dump fra system (læst fra DICOMDIR og IMAGE headere): (GE Vingmed EchoPAC PC datasæt 2001) StudyInstanceUID: X.98 hvor X er 2 eller 6 (GE Vingmed EchoPAC PC datasæt 2008) StudyInstanceUID: (I dette datasæt forekom billeder hvor ImplementationClassUID ikke er overskrevet af EchoPAC PC og StudyInstanceUID var ) GE Vingmed Vivid3 6 har følgende opbygning af StudyInstanceUID: System Serial Number+.2.+examination unique ID received from archiving module.

13 2.2 Juridiske krav har same forhold til ImplementationClassUID som Vivid7. Vivid3 ImplementationClassUID er Det bør således være teknisk muligt at implementere StudyInstanceUID matchning med et passende regular expression, og dermed understøtte hele Vivid serien af ultralydsscannere på en forsvarlig måde mht. forekomst af BurnedInAnnotation. 2.2 Juridiske krav Til ethvert klinisk forskningsprojekt hvor der indgår personfølsomme informationer kræves en præcist defineret forsøgsprotokol, som skal godkendes af de relevante myndigheder. Når det drejer sig om et internationalt forskningsprojekt vil der typisk være tale om påkrævede godkendelser fra FDA(Food And Drug Administration) og CE (Conformité Européenne "European Conformity"). Først skal det gøres klart, at dette projekt alene drejer sig om den tekniske side af håndteringen af data, og det overlades til forskerteamet at opstille en protokol som tager sig af den humane interaktion. For dette projekt vil det være relevant at se på det amerikanske FDA, som opstiller en række konformitetskrav til systemer som opbevarer data elektronisk. (21 CFR Part 11) Elementer som indgår i dette er f.eks. password styring, password forældning og automatisk log-af. Desuden kræves omfattende logging af system interakationer, som viser hvem der har tilgået en ressource, hvornår, og i hvilken kontekst. Mht. sikring af patienters anonymitet, kræves der, når der drejer sig om medicinske billeddata i DICOM formatet, at tags i datafilernes headere ikke på nogen måde kan

14 8 2 Analyse identificere den person som data stammer fra. Dette er ikke en triviel udfordring, da DICOM standarden specificerer en række type 1 tags (påkrævede informationsfelter), som bl.a. omfatter patientens navn og ID, og dertil en række andre tags som mere indirekte kan identificere en patient. Det vil altså fra den tekniske side være påkrævet at sådanne informationer fjernes inden data kan indgå i et multi-center forskningsprojekt, medmindre forsøgsprotokollen er tilrettelagt således, at enhver scanning som bidrager til forskningsprojektet, på forhånd er anonymiseret. Dvs. patientnavn angives som f.eks. anonym og ID sættes til patientens tildelte randomiseringsnummer. En sådan fremgangsmåde er dog en ændring af arbejdsgangen ved en scanning, og den må eventuelt gentages hvis den var led i patientens diagnostiske udredningsforløb. Systemet som her udvikles vil imidlertid være designet til at kunne anvende standard scanninger i forskningsprojekter. Der kræves derfor en anonymisering af de data som skal indgå i forsøget. 2.3 Brugervenlighed Mange typiske danske brugere af en applikation som denne (læger) ville være i 50+ aldersgruppen. Ud fra egne observationer, inkluderende en usability test med en sygeplejerske som deltager, anvender denne aldersgruppe anvender ofte applikationer på en anden måde end designeren ville forvente. Eksempelvis dobbelt-klikker brugere på alle knapper og vil ofte klikke knapper gentagne gange hvis et respons ikke ses efter ganske kort tid (få sekunder). Denne adfærd skal tages med i vurderingen når krav til bruger interface og brugervenlighed specificeres. Der er i og for sig intet galt med denne adfærd. Brugerne forventer, helt rimeligt, at få anvendelig og forståelig

15 2.3 Brugervenlighed 9 feed-back fra applikationen, og at det fungerer som på samme måde som windows operativsystemet hvor man dobbeltklikker for at åbne en fil eller mappe. Hvis brugerne ikke bliver præsenterede for information om præcist hvad der foregår under procedurer med mærkbar latenstid på systemet vil mange blive irriterede eller nervøse. De kunne efterlyse svar på spørgsmål som: Har programmet udført den opgave, som jeg forventede? eller Er det sikkert at klikke på knappen nu, eller risikerer jeg at der opstår en fejl? Hvis en applikation anvendes sjældent, hvilket er tilfældet med denne applikation (en eller få gange årligt for klinikernes vedkommende), er det ydermere meget vigtigt at applikationen er så intuitiv som muligt at anvende, uanset brugergruppens karakteristik. Det er endvidere urealistisk at forvente, at læger uden videre vil afsætte tid til at sætte sig grundigt ind i anvendelsen af en ny applikation, og eventuelt også bruge tid på at genindlære systemets anvendelse på et senere tidspunkt. Derfor må det tilstræbes at applikationen understøtter de almindelige arbejdsgange i videst muligt omfang, at procedurer under anvendelsen af applikation er enkle, og at brugeren har sufficient information til at opgaven kan udføres. Dette projekt stræber efter at overholde følgende usability guidelines i design af funktionalitet og brugerinterface 7 : At centrere designet omkring brugeren At gøre brugerens valgmuligheder synlige, let forståelige og overskuelige. At give brugeren kontinuerlig feedback om hvad der sker på systemsiden. At give let forståelige og konstruktive fejlmeddelelser når der opstår problemer.

16 10 2 Analyse 2.4 Kravspecifikation Funktionelle krav Løsningsmodel Database server Forskerens interface Oprette konti for klinikere Gennemse statistik og indhold I database Inkludere eller afvise patienter Gennemse undersøgelser Klinikerens interface Se statistisk oversigt for egne patienter Oprette patienter I system Uploade data fra scanninger Gennemse undersøgelser Downloade undersøgelsesdata Et support website som tilbyder FAQ, instruktionsvideo, password management funktionalitet og kontaktinformationer er ligeledes en del af kravspecifikationen, men er endnu ikke implementeret.

17 KAPITEL 3 Design og implementering 3 Design og implementering 3.1 Udviklingsplatform og anvendt software Implementeringen er foretaget i Java (jre6) og er testet på WindowsXP operativsystemet. Databasen som er anvendt under udviklingen er MySQL 5.0. Implementeringen bygger i stor udstrækning på kodeeksempler fra det anvendte DICOM API: dcm4che, som er open-source og under LGPL licens. LGPL licencen tillader i modsætning til GPL kommerciel anvendelse og det er ikke påkrævet at distribuere kildekode med applikationen. LGPL licens samt kodeeksempler for transcoding, en simpel viewer og dicomdir manipulation gjorde dcm4che til et naturligt valg. Implementeringen anvender både version 1.4 og 2.0, da kodeeksempler ikke var tilstrækkelige i 2.0.

18 2 2 years 3 3 years 12 3 Design og implementering 3.2 Informationsflow Solution outline Information flow Researcher login create physician account Database Physician login request anon. patient ID upload evaluation study view statistics download evaluation study enroll or reject patient view patient status upload follow-up #1 upload follow-up #2 upload follow-up #3 upload follow-up #4 download multiple studies

19 3.3 Komponenter i klientapplikationerne Komponenter i klientapplikationerne Klientprogrammets komponenter i oversigt. Den aktuelle implementering afviger noget. DCMLoader Load DICOM obj Parse DICOM obj Exp./Imp. header Save to File Save to Memory DCManonymizer Read name/id Write name/id Transcoder Burned in annotation removal MessageDigest Calculate digests SQLAPI Query/commit Connect/disconn. Logger Action + timestamp FileHandler Browse dir/files Load & save Core Flow control Transfer control User feedback Utility Print, browserlaunch ImageViewer Play-stop Approve/Dismiss View record data ImageDataParser Load data Exp./imp. content Save data GfxLibrary Pixel format conv. Brightness/contrast GUI GUI components Selection handler Diagrammet viser den funktionelle organisation af java klasserne. GUI klassen indeholder opsætning af brugerinterface. Core klassen er ansvarlig for program-flow. SQLAPI klassen holder styr på forbindelsen til databasen og udfører queries, hovedsageligt fra Core. I Appendiks B ses scripts til opsætning af databasen. 3.4 Modifikation og udtræk af data i DICOM headere Et DICOM file-set kan indeholde en række hyppigt anvendte kliniske markører i DICOMDIR headeren. Herunder demografiske data såsom alder (fødselsdag), vægt,

20 14 3 Design og implementering rygestatus og etnicitet. Markører som alder, rygestatus og over- eller undervægt har meget ofte betydning for behandlingsresultat og prognose. Jeg har derfor planlagt at udtrække disse data fra DICOMDIR headerens Patient record og gemme dem i databasens tabel demograph (ikke implementeret i skrivende stund). Det giver god mening at have disse informationer direkte tilgængelige i databasen, således at der kan foretages specielle søgninger efter studier eller patienter med disse kliniske markører som parametre. Følgende tabeller indeholder udvalgte DICOM tags som kræver særlig opmærksomhed mht. anonymisering samt udtræk af demografiske data. PATIENT IDENTIFICATION TAG PLANLAGT AKTUELT MODULE Patient Name 0010,0010 Erstat Erstat Patient ID 0010,0020 Erstat Erstat (rand.#) (rand.#) Issuer of Patient ID 0010,0021 Ingen Ingen Other Patient IDs 0010,1000 Fjern Fjern Other Patient's Names 0010,1001 Fjern Fjern Patient's Birth Name 0010,1005 Fjern Ingen Patient's Mother's Birth Name 0010,1060 Fjern Ingen Medical Record Locator 0010,1090 Fjern Ingen

21 3.4 Modifikation og udtræk af data i DICOM headere 15 PATIENT DEMOGRAPHIC TAG PLANLAGT AKTUELT MODULE Patient's Birth Date 0010,0030 Fjern Ingen Patient's Birth Time 0010,0032 Fjern Ingen Patient's Sex 0010,0040 Kopier til DB Ingen Patient's Insurance Plan Code 0010,0050 Fjern Ingen Sequence Patient's Age 0010,1010 Kopier til DB Ingen Patient's Size 0010,1020 Kopier til DB Ingen Patient's Weight 0010,1030 Kopier til DB Ingen Patient's Address 0010,1040 Fjern Ingen Country of Residence 0010,2150 Kopier til DB Ingen Region of Residence 0010,2152 Fjern Ingen Patient's Telephone Numbers 0010,2154 Fjern Ingen Ethnic Group 0010,2160 Kopier til DB Ingen Occupation 0010,2180 Fjern Ingen Patient Comments 0010,4000 Fjern Ingen PATIENT MEDICAL MODULE TAG PLANLAGT AKTUELT Medical Alerts 0010,2000 Kopier til DB Ingen Contrast Allergies 0010,2110 Kopier til DB Ingen Smoking Status 0010,21A0 Kopier til DB Ingen Additional Patient History 0010,21B0 Fjern Ingen Pregnancy Status 0010,21C0 Ingen Ingen Last Menstrual Date 0010,21D0 Ingen Ingen Special Needs 0038,0050 Kopier til DB Ingen Patient State 0038,0500 Fjern Ingen

22 16 3 Design og implementering Visit Status Module TAG PLANLAGT AKTUELT Current Patient Location 0038,0300 Fjern Ingen Patient's Institution Residence 0038,0400 Fjern Ingen Visit Comments 0038,4000 Fjern Ingen Visit Admission Module TAG PLAN AKTUELT Referring Physician's Name 0008,0090 Fjern Ingen Referring Physician's Address 0008,0092 Fjern Ingen Referring Physician's Telephone 0008,0094 Fjern Ingen Numbers Referring Physician Identification 0008,0096 Fjern Ingen Sequence Admitting Diagnoses Description 0008,1080 Fjern Ingen

23 3.5 Brugergrænseflade Brugergrænseflade Interface som møder klinikeren efter gennemført login:

24 18 3 Design og implementering Højreklik i tabellen viser de optioner som er tilgængelige. Alternativt kan Options ikonerne anvendes. New patient record er et tooltip. Ved klik på ikonet tages brugeren til en skærm hvor en ny patient kan oprettes i systemet. Tabellens søjler Patient name og Patient ID fremkommer kun i klinikerens interface. Oplysningerne er gemt lokalt sammen med randomiserings ID. Dette er det eneste sted hvor patienter hvis data ligger i databasen kan identificeres.

25 3.5 Brugergrænseflade 19 Thumbnail oversigt for et uploaded studie:

26 20 3 Design og implementering Denne oversigt fremkommer når brugeren vælger view contents of selected study. Efter at et studie er lagt i databasen er oversigten tilgængelig fra forsker interfacet og fra den interfacet hos den kliniker, som uploadede studiet. På næste side ses den indbyggeede DICOM viewer med understøttelse af kontrast/lysstyrke justering og afspilning af videosekvenser. Baggrunden for at inkludere denne feature var, at klinikerne, som uploader data, kan verificere at eventuel burned in annotation er fjernet korrekt. Vieweren kan også aktiveres for gennemsyn af data i databasen ved klik på thumbnails fra både klinikerens of forskerens interface. Vieweren kan tjene et formål i en eventuel kommunikation mellem forsker og kliniker, således at man kan referere præcist til en sekvens i et studie. Vieweren er implementeret med option for gråtone- og 256 farvers palette repræsentationer for at tilgodese systemer med ringe beregningskraft. Palette repræsentationen beregnes med Xiaolin Wu s algoritme 8, som jeg har oversat fra C til Java.

27 3.5 Brugergrænseflade 21

28 22 3 Design og implementering

29 KAPITEL 4 Konklusion 4 Konklusion I problemformuleringen og kravspecifikationen opstilles en række målsætninger, hvoraf de vigtigste kan opsummeres i følgende punkter: At tilvejebringe en sikker og pålidelig it-løsning for indsamling, opbevaring og udtræk af data fra ultralydsskanninger i DICOM filformatet til et medicinsk forskningsprojekt. At løsningen understøtter normale arbejdsgange hos klinikere og teknisk personale, sådan forstået, at udførslen af en ultralydsskanning til forskningsprojektet ikke kræver ændring af sædvanlige procedurer, og at registrering af patienter i systemet, kommunikation mellem forskerholdet og klinikerne samt afsendelse af undersøgelsesdata ikke kræver nævneværdig forhåndsviden om it-løsningens betjening. At løsningen bibringer fordele sammenlignet med nulløsningen (CD ROM er kurer post, manuel indlæsning og katalogisering af data). Disse målsætninger er nået med varierende grad af succes. Applikationen er i skrivende stund på et avanceret prototype niveau. Alt fungerer principielt, men der mangler grundig testning og usability optimering. En usability-test med en praktiserende læge som testdeltager er planlagt kort efter indleveringen af denne rapport. Endvidere er Help & Support websitet ikke implementeret, og debug output fra klientprogrammet kan ikke slås fra. Applikationen lever i udgangspunktet op til målsætningen om understøttelse af den normale arbejdsgang hos klinikerne, idet den har et automatiseret anonymiserings- og randomiseringssystem. Ultralydsscannere i Acuson Sequoia serien, der altid anvender burned-in annotation som kan identificere patienten, anonymiseres automatisk ved hjælp af en prædefineret maskering af et rektangulært område i billeddata.

30 24 4 Konklusion Koordinater for et rektangel er gemt i databasen og associeret med producent og modelnavn. Under upload proceduren checkes der om et sådant rektangel er defineret. Findes modelnavn og producentnavn ikke i databasen får brugeren besked om, at udstyret ikke understøttes i øjeblikket. Dette krav (eksistens af producent og modelnavn i databasen alternativt anvendes StudyInstanceUID tag et som persisterer trods eksport fra Workstations som overskriver producent- og eller modelnavn) sikrer at uploads kun tillades hvis data kommer fra udstyr hvor eventuel burned-in annotation kan håndteres forsvarligt af systemet. For at holde udviklings- og driftsomkostninger på et lavt niveau er der i vidt omfang anvendt open-source software. GPL licensens krav om distribution af source-kode og begrænsninger af kommerciel udnyttelse er ikke aktuelt, da GPL licensen ikke omfatter applikationer som blot anvender en GPL open-source komponent uden modifikation. Dette er tilfældet for MySQL database connector en. dcm4che API et med kode eksempler er under LGPL licensen, som tillader kommerciel anvendelse. Kodeeksemplerne distribueret med dcm4che danner basis for kerne-komponenter i applikationen (modifikation af DICOMDIR, fjernelse af burned-in annotation fra billeddata og viewer komponenten). Der eksisterer en række værktøjer, både kommercielle og open-source, som kan batch-anonymisere og fjerne burned-in annotation. Som eksempel kan nævnes Santesoft s Sante Dicomander (Licenser koster 200$ pr bruger) eller versionen med grafisk brugerflade Sante DICOM Viewer PRO (300$ pr bruger). Sante Dicomander kunne givetvis konfigureres fil at batch-anonymisere billeddata forud for upload, men omkostningerne ved et stort antal brugere (eks 100) ville langt overstige omkostningen ved selv at implementere automatiseret header- og billeddataanonymisering, sådan som jeg har valgt.

31 25 Heart Imaging Technologies er en udbyder af web baserede PACS systemer, som inkluderer et system skræddersyet til kliniske forskningsprojekter. ( Anonymisering af sensitive DICOM tags håndteres automatisk. Heart Imaging Technologies tilbyder deres løsninger i Software as a service modellen (SaaS), hvilket giver den store fordel, at man blot behøver en web-browser for at se sine billeder hvor i verden man måtte befinde sig. Det ville også være nemt at bede en kollega om et hurtigt gennemsyn af en undersøgelse. HeartIT tilbyder også en gratis løsning hvor deling af DICOM filer og gennemsyn online er muligt. Imidlertid er det ikke umiddelbart realistisk at anvende denne løsning, medmindre der i tillæg udvikles software til at håndtere specialtilfælde med burned in annotation sådan som det vil være påkrævet for Acuson Sequoia serien af ultralydsscannere. En anden vigtig målsætning er kravet om usability, som jeg ønsker at fremhæve for mit produkt. Var jeg på et tidligere tidspunkt blevet klar over eksistensen af Heart Imaging Technologies SaaS produkter ville det have været oplagt at undersøge disse. Som et minimum ville jeg foretage en grundig test af den gratis WebPAX service for at foretage en sammenligning af kompatibilitet features og usability med mit produkt. I en kort test af WebPAX ser det umiddelbart ud til egne sig glimrende til hurtige peer-reviews af enkelt-filer. Dog var der et alvorligt usability-problem med mit andet sæt af testdata. Beskeden FAILED ANONYMIZATION som jeg fik med testdata fra en moderne GE ultralydsscanner (Vivid 7) giver ikke nogen konstruktiv information til brugeren. Testdata som ikke kunne anonymiseres (og derfor ikke blev gemt) var fra Siemens kontakts egen scanner. Det ser umiddelbart heller ikke ud til at en undersøgelse kan uploades i sin helhed (med DICOMDIR). En anden umiddelbar svaghed ved systemet i forhold til mit produkt er at data skal uploades inden anonymiseringen bliver foretaget. Havde denne del af processen været henvist til klient software ville spildtid kunne undgås og usikkerhed omkring hvad der sker med data i sådanne fejlsituationer kunne elimineres.