Läkarkåren producerar och manipulerar en enorm mängd digitala data för vilka datoriserad arkivering, bearbetning och analys behövs. Rutnätsinfrastrukturer är lovande när det gäller att hantera de utmaningar som uppstår i fleranvändarsystemet. Dessa begränsningar begränsar ofta användningen av rutnät för att manipulera känsliga medicinska data. Detta dokument beskriver vår design av ett medicinskt datahanteringssystem som utnyttjar de avancerade glite datahanteringstjänster, som utvecklats inom ramen för EGEE-projektet, för att uppfylla de stränga behoven hos den medicinska världen. Det säkerställer medicinskt dataskydd genom strikt dataåtkomstkontroll, anonymisering och kryptering. Åtkomstkontrollen på flera nivåer ger den flexibilitet som krävs för att genomföra komplexa medicinska användningsfall. Dataanonymisering förhindrar exponering av de flesta känsliga data för obehöriga användare, och datakryptering garanterar dataskydd även när det lagras på avlägsna platser. Dessutom tillhandahåller den utvecklade prototypen ett gränssnitt för Grid Storage Resource Manager (SRM) till vanliga medicinska DICOM-servrar, vilket möjliggör öppen tillgång till medicinska data utan att störa medicinsk praxis. Nyckelord Säker lagring av rutnät · glite middleware · Medicinsk datahantering Sammanhang Många vetenskapliga områden drar nytta av stora och distribuerade lagringsmöjligheter som tillhandahålls av Grid-infrastrukturer. Utöver fysiska lagringsresurser underlättar EGEE [16] Grid-datahanteringssystemet manipulering av stora datavolymer och ger hög funktionalitet såsom datadistribution, replikering och optimerad åtkomst. För att bygga ett datahanteringssystem som kan anpassa sig till de heterogena datalagringsresurserna (disk, band, silos...) har Gridgemenskapen antagit standardgränssnitt för att virtualisera de underliggande resurserna. I synnerhet har glite [22], nästa generations EGEE middleware, antagit gränssnittet för lagringsresurshanterare [28] som standard inom ramen för Open Grid Forum [27]. SRM:s främsta uppgift är att ge effektiv tillgång till stora datavolymer. Den tillhandahåller bland annat förhämtning av datafiler som registrerats vid sekundär lagring, hantering av lagringsutrymme och bokning av lagringsresurser. Det ger dock ingen åtkomstkontroll eller skydd av uppgifter som allvarligt begränsar dess användbarhet för tillämpningar som manipulerar känsliga uppgifter. I detta dokument tar vi upp problemet med känslig datahantering på EGEE Grid infrastruktur och vi introducerar en datahanteringstjänst utformad för att hantera medicinska register på Grids. Vi motiverar först vårt tillvägagångssätt genom en fördjupad kravanalys av datahantering inom det medicinska området (avsnitt 2). Vi introducerar sedan en uppsättning glitetjänster som är utformade för att implementera säker datalagring (avsnitt 3) baserat på denna analys. De tillåter finkornig åtkomstkontroll för applikationsdata och metadata med hjälp av vanliga Grid-koder och de tillhandahåller funktioner för kryptering/dekryptering i realtid. Vi föreslår slutligen en programvara arkitektur för att genomföra en medicinsk datahantering (MDM) tjänst (avsnitt 4). Vårt förslag ger tillgång till medicinska källor för Grid-tjänster och användare samtidigt som vi tar hänsyn till de begränsningar som är relaterade till klinisk praxis. I synnerhet patientintegritet garanteras, data plats upprätthålls i förvärvscentra, och det normala kliniska dataflödet bevaras. En implementering av dessa tjänster gränssnitt till EGEE middleware slutligen visas. Verklig medicinsk användning diskuteras i avsnitt 5 och prestanda rapporteras i avsnitt 6. Att bygga ett Grid-gränssnitt för medicinsk lagring är av stort intresse för den medicinska bildmiljön och vissa system har nyligen rapporterats. TRENCADIS medicinal data manager [10] är till exempel en WSRF-kompatibel middleware utformad för att dela, söka och behandla medicinska bilder och strukturerade radiologiska rapporter. Det är ett av de första exemplen på ett helt integrerat Grid-system som tar hänsyn till infödda medicinska bildgränssnitt, säkerhetsbegränsningar och medicinska ontologier. Jämfört med den medicinska datahanteraren som presenteras i detta dokument, är det inte gränssnitt mot ett distribuerat datahanteringssystem och det kan därför inte användas öppet av Grid Ett säkert Grid medicinska DM gränssnitt till glite 47 program gränssnitt till datahantering middleware. Lagringsresursmäklaren middleware [7] används också inom ramen för BIRN [8]-projektet för lagring och behandling av stora mängder distribuerade medicinska data. Den innehåller ett distribuerat filhanteringssystem och kan manipulera metadata som är associerade till filer. Men det är inte gränssnitt mot infödda kliniska lagring till skillnad från vårt system. Säkerhetsaspekterna avseende dataåtkomstkontroll och skydd som är avgörande för medicinska system har noggrant studerats på distribuerade miljöer som Grids [29]. En konsensus verkar uppstå från gemenskapen för att använda delade hemliga nyckelkrypteringsalgoritmer för dataskydd [9, [33] [34] [35] 37]. De ger ett robust och säkert krypteringsramverk. Dataåtkomstkontroll är en mer kontroversiell punkt. Rollbaserad åtkomstkontroll (RBAC) [20] är ett flexibelt paradigm som kan hantera komplexa användningsfall som påträffas inom det medicinska området. Enskilda användare tilldelas roller, som representerar samlingar av behörigheter, beroende på vilka uppgifter de förväntas utföra. Varje användare och varje behörighet kan tilldelas flera roller. Många behörighetsuttrycksspråk (t.ex. XACML [38]) och protokoll för att bekräfta tillstånd (t.ex. SAML [30]) har föreslagits. Inom ramen för EGEE:s nätinfrastruktur identifieras användarna genom X509-certifikat. Roller tilldelas användare genom en virtuell organisation medlemskapstjänst (VOMS) [2]. Själva åtkomstkontrollen genomförs i olika VOMS-medvetna datahanteringssystem baserade på åtkomstkontrolllistor (ACL). Medical Data Management Requirements Analysis Det medicinska samfundet använder rutinmässigt kliniska bilder och tillhörande medicinska data för diagnos, interventionsplanering och uppföljning av terapi. Medicinska bilder producerar ett ökande antal digitala bilder för vilka datoriserad arkivering, bearbetning och analys behövs [21, 26]. Bildnätverk har blivit en viktig del av den dagliga kliniska praktiken under årens lopp. Med deras uppkomst har behovet av standardiserade medicinska dataformat och utbytesförfaranden ökat [5]. Därför antogs den digitala avbildningen och kommunikationen inom medicinen [14] av ett stort konsortium av leverantörer av medicintekniska produkter. Bildarkivering och kommunikationssystem (PACS) [24], manipulera DICOM-bilder och ofta andra medicinska data i egenutvecklade format, föreslås av leverantörer av medicintekniska produkter för hantering av kliniska data. PACS är ofta egenutvecklade lösningar som är svagt standardiserade. PACS kan i olika grad integreras med det sjukhusinformationssystem (HIS) som innehåller administrativ information om patienter och med de radiologiska informationssystem (RIS) som innehåller ytterligare information för radiologiavdelningarna. DICOM-standarden, PACS, RIS och HANS har utvecklats med kliniska behov i åtanke. De underlättar den dagliga vården av patienterna och de medicinska administrativa förfarandena. Deras användning på andra områden är dock mycket begränsad. Gränssnittet mot datorinfrastrukturer saknas nästan helt i synnerhet. Dessutom tar nuvarande PACS knappast upp medicinska datahanteringsbehov bortom kliniska centras administrativa gränser, medan patientjournalerna ofta är spridda brett över många medicinska webbplatser som har varit involverade i patientens vård. Många medicinska bild förvärv enheter svagt överensstämmer med DICOM-standarden, vilket knappt döljer heterogeniteten i dessa system. DICOM-standarden omfattar bland annat ett bildformat och ett protokoll för bildkommunikation. En DICOM-bild innehåller vanligtvis en skiva (en 2D-bild) förvärvad med hjälp av någon medicinsk avbildning modalitet (MRI, CT-scan, PET, SPECT, ultraljud, röntgen...[1]). En DICOM-avbildning kan innehålla en multi-slice datauppsättning, men detta förekommer sällan. En DICOM-bild innehåller både bilddata i sig och en uppsättning ytterligare information (eller metadata) som beskriver bilden, patienten, förvärvsparametrarna och radiologiavdelningen. DICOM metadata lagras 48 J. Montagnat et al. i fält. Varje fält identifieras genom en unik tagg som definieras i DICOM-standarden. Ett visst fält kan finnas eller saknas beroende på vilken bildbild som skapade bilden. Standarden är öppen och tillverkare av bildenheter tenderar att använda sina egna fält för olika typer av information. Ett par fält (t.ex. bildstorlek) är obligatoriska men erfarenheten visade att överraskningar bör förväntas när man analyserar en DICOM-bild. Själva bilden lagras vanligtvis som rådata. De flesta avbildningsenheter producerar ett intensitetsvärde per bildpixel, kodat i ett 12 bitars format. Andra format kan förekomma såsom 16 bitars data eller förlustfri JPEG. De flesta (rimligt moderna) apparater för medicinsk bild förvärv är DICOM kunder. DICOM-servrar är datorer med back-ends på disk och/eller band som kan lagra och hämta DICOM-avbildningar. DICOM-protokollet definierar kommunikationsprotokollet mellan DICOM-servrar och kunder. DICOM-standarden definierar i synnerhet ett medicinskt dataformat (del 10), meddelanden och protokoll (del 7) och säkerhetshanteringsprofiler (del 15). Dataformatet säkerställer oberoendet från DICOM-applikationen och medialagringen. Det innehåller dock inga bestämmelser om lagring. DICOM-servrar implementerar sin egen policy för datalagring. Data kan skickas eller hämtas från en DICOM-kompatibel server med hjälp av DICOM-protokollet och standardmeddelanden för att skjuta bilder till servern eller för att få dem från servern. DICOM-standarden tar inte upp säkerhetspolitiska frågor, även om den nämner att "tydligt iakttagande av lämpliga säkerhetsstrategier är nödvändigt för alla säkerhetsnivåer". Standarden tillhandahåller endast mekanismer som kan användas för att genomföra säkerhetsstrategier när det gäller utbyte av DICOM-objekt mellan DICOM-tillämpningar som uppfyller kraven. Det är upp till ansökningarna att komma överens om den önskade säkerhetsnivån. Man ska inte se en DICOM datauppsättning som en uppsättning filer. Som nämnts ovan innehåller en enda DICOM-bild vanligtvis bara en bildskiva. I praktiken, under en läkarundersökning (en DICOM studie), en radiolog förvärvar flera 2D och 3D bilder, som omfattar hundratals eller till och med tusentals skivor. En studie är uppdelad i en eller flera serier och varje serie består av en uppsättning skivor (som kan staplas för att montera en volym när de tillhör samma 3D-bild). Varje skiva identifieras unikt i sin serie med hjälp av en unik instansidentifikation för SOP. Observera att det ofta inte finns någon uppfattning om 3D-avbildning kodad i DICOM-formatet: en serie kan innehålla en uppsättning skivor som komponerar flera 3D-avbildningar. Hur en DICOM-server lagrar dessa datamängder på disk är irrelevant precis som hur en databas lagrar sin tabell oftast inte är känd av användarna: den medicinska användaren utsätts aldrig för DICOM lagring och behöver inte veta om olika filer används för varje DICOM skiva, serie, studie, etc. Metadata ingår i DICOM-bildhuvuden, vilket gör det svårt att söka och manipulera. En DICOM-server extraherar ofta bildernas metadata och lagrar den i en databas för att underlätta datasökningen. DICOM:s säkerhetsmodell försvagas av dess flexibilitet. Den tillhandahåller tekniska medel för att genomföra säkerhet (som bygger på befintliga standarder för datakryptering) men den upprätthåller ingen säkerhetspolitik. Det är upp till DICOM ansökan att förhandla om en nivå av säkerhet avtal. DICOM-filer kan mycket väl lagras och transporteras okrypterade, exponera känsliga data. DICOM-serverns säkerhetsmodell är baserad på en perapplicering: alla användare som har tillgång till någon DICOM-klientapplikation kan få tillgång till den information som servern exponerar för denna specifika applikation. DICOM-servrar använder slumpmässiga filnamn utan någon anslutning till patientinformationen och en egenutvecklad datalagringspolicy. För att klara av dessa begränsningar av dataskyddet genomförs säkerheten ofta på sjukhusen genom att man isolerar bildnätverket från omvärlden. Varje enhet för bildinhämtning är en potentiell DICOM-kompatibel medicinsk bildkälla. I en radiologiavdelning kan en eller flera DICOM-servrar konfigureras för att centralisera data som förvärvats på denna webbplats. Medicinska data sprids naturligt över de olika förvärvsplatserna. I klinisk praxis har läkare inte direkt tillgång till bildfiler. De identifierar data genom tillhörande metadata såsom patientens namn, förvärv En säker Grid medicinsk DM gränssnitt till glite 49 datum och radiolog namn. Uppgifterna överförs huvudsakligen för visualiseringsändamål. Läkaren skannar snabbt skivor stacken i DICOM studien och fokuserar på de skivor han eller hon är intresserad av. Under de senaste decennierna, med den ökande tillgången på digitala medicinska data, har många medicinska databehandling och analysalgoritmer utvecklats, vilket möjliggör datoriserade medicinska applikationer som gynnar patienten och hälso- och sjukvårdspersonal. Även om den medicinska bildanalysgemenskapen delar samma datakällor, har den andra krav på medicinska system än hälso- och sjukvården. Många algoritmer utvecklas för att behandla och producera 3D-avbildningsfiler: DICOM-skivor bör extraheras från DICOM-servern och monteras i en enda volym innan de behandlas som en sammanhängande 3D-datauppsättning. 3D-avbildningar exporteras till diskfiler för efterbehandling och enkel användning. Olika 3D medicinska bildformat kan användas för att stapla olika DICOM skivor i en enda bildvolym (den vanligaste är analys filformat). Bilder identifieras också ofta genom metadata, även om frågorna inte nödvändigtvis är för nominativa data men ofta relaterade till förvärvstyp eller organ region. Med tanke på att bildservrar och 3D-filformat är heterogena behövs ofta ett gemensamt förfarande för åtkomst till alla medicinska datakällor. Med tanke på den enorma mängd medicinska data som produceras inom sjukhusen och kostnaden för medicinsk databehandling (särskilt bildanalysalgoritmer), har rutnät visat sig vara mycket användbara infrastrukturer för ett stort antal medicinska tillämpningar [25]. Rutnät tillhandahåller dataresurser och arbetsbelastningssystem som underlättar spridning och användning av applikationskoder. Dessutom tillhandahåller rutnät distribuerade datahanteringstjänster som är väl lämpade för hantering av medicinska data geografiskt spridda över olika vårdcentraler [6, 11, 12, 19, 23]. Befintliga Grid middlewares hanterar dock ofta bara datafiler och tillhandahåller inte tjänster på högre nivå för att manipulera medicinska data. Medicinska data måste ofta överföras manuellt och omvandlas från sjukhuskällor till rutnätslagring innan de behandlas och analyseras. Sådana manuella ingrepp är tråkiga och begränsar den systematiska användningen av Grid-infrastrukturer: vissa medicinska tillämpningar såsom statistiska atlaskonstruktioner eller epidemiologiska studier kan kräva manipulering av tusentals bilder. I dessa fall är manuella ingrepp oåtkomliga på grund av storleken på datamängderna och användningen av rutnät är endast möjlig om registrering av medicinska bilder utförs automatiskt. Förordningar som är tillämpliga på läkarjournaler i europeiska länder (och många andra) säkerställer en extremt strikt åtkomstkontroll av medicinska uppgifter och skydd av patienternas privatliv. I klinisk praxis uppnås detta ofta genom att isolera bildnätverket från omvärlden. Hantering av medicinska data och införande av privata tillämpningar för behandling av medicinska data på rutnät kan inte förutses utan att visa en mycket hög säkerhetsnivå i enlighet med gällande standarder och praxis för hantering av kliniska data. Alla medicinska data bör betraktas som känsliga för att bevara patientens integritet. Nominativa medicinska journaler är naturligtvis de mest kritiska uppgifterna och därför bör ingen bindning mellan nominativa data och bilder vara möjlig för icke-ackrediterade användare. Endast läkare som deltar i en patientvård ska ha tillgång till data från denna patient. På ett rutnät förvärrar datadistributionen säkerhetsproblemen. För att säkerställa patienternas integritet bör huvudet på alla DICOM-avbildningar som skickas av en DICOM-server tas bort, åtminstone delvis, för att säkerställa patienternas anonymitet. Alla bilder som lagras utanför källcentret bör krypteras för att säkerställa att icke-ackrediterade användare inte kan läsa bildinnehållet.  Den första nyckeln till framgången med den systematiska spridningen av algoritmer för medicinsk bildbehandling är att tillhandahålla en datahanterare som: - Ger tillgång till medicinska datakällor för datorbehandling utan att störa den kliniska praxisen. -Säkerställer öppenhet så att tillgång till medicinska data inte kräver några särskilda användarinterventioner. -Säkerställer en hög nivå av dataskydd för att respektera patienternas integritet och datasekretess begränsningar. Systemet för uppgiftsskydd måste vara tillräckligt flexibelt för att möjliggöra komplexa scenarier för hantering av medicinska uppgifter som involverar många aktörer. Nästa session beskriver ett medicinskt datahanteringssystem som vi har utformat för att underlätta tillgång till och behandling av medicinska data på ett rutnät. Det är kompatibelt med DICOM kliniska servrar på ena sidan och gränssnitt mot EGEE Grid data management system på den andra sidan. Säker datalagring EGEE-projektet använder för närvarande glite middleware [22] på sin produktionsinfrastruktur. gLite bygger på GLOBUS2, Condor och andra tjänster som utvecklats inom det europeiska DataGrid-projektet [15]. Vår medicinska datahanteringstjänst (MDM) är starkt sammankopplad med glite. Glite middleware tillhandahåller arbetsbelastningshanteringstjänster för att skicka datauppgifter till Grid-infrastrukturen och datahanteringstjänster för hantering av distribuerade filer. Datahanteringen bygger på en uppsättning lagringselement som är lagringsresurser som distribueras av de olika platser som deltar i infrastrukturen (för närvarande mer än 190 platser som distribueras över hela Europa och utanför). Alla lagringselement exponerar ett gemensamt gränssnitt för interaktion med de andra middleware-tjänsterna: gränssnittet för lagringsresurshanterare (SRM) som standardiseras inom ramen för Open Grid Forum. SRM hanterar lokala data på filnivå. Det erbjuder ett gränssnitt för att skapa, hämta, stifta, eller förstöra filer bland annat. Den genomför inte dataöverföring av sig själv. Ytterligare tjänster som GridFTP [3] eller gLiteIO [18] finns samexisterande inom lagringselement för att tillhandahålla överförings- och dataåtkomstkapacitet. Utöver lagringsresurser innehåller glite datahanteringssystem en filkatalog (FiReMAN -filreplikationshanterare [17] ) som erbjuder en unik ingångspunkt för filer som distribueras på alla rutnätslagringselement. Varje fil är unikt identifierad genom en globalt unik identifierare (GUID). Filkatalogen innehåller tabeller som associerar GUID:er till filplatser. Av effektivitets- och feltoleransskäl kan filer kopieras på olika platser. Således kan varje GUID associeras till flera fysiska kopior av samma logiska fil som finns på olika platser och identifieras av olika platsberoende lagring URL (SURL). För att underlätta manipulation av användare, kan mänskliga läsbara logiska filnamn (LFN) vara associerade till varje logisk fil (varje GUID). Filkatalogen FiReMAN associerar också metadata till registrerade filer. Vissa metadata är obligatoriska (systemmetadata såsom filkontrollum). Ytterligare metadata kan definieras av användarna för tillämpningsbehov. I synnerhet kan ACL:er vara associerade till varje fil. De identifierar på ett finkornigt sätt (per enskild användare och/eller per grupp) åtkomsträttigheter för varje fil. Dessa åtkomsträttigheter omfattar en rik uppsättning funktioner: de inkluderar fillista, läs- och skrivfunktioner, tillhörande metadata läs- och skrivfunktioner och åtkomstkontrollmodifiering. Användarna identifieras individuellt genom sitt certifierade namn (DN) som det hänvisas till i ACL. Filer nås med hjälp av gliteIO [18]. gLiteIO är en klient/serverbaserad datautbytestjänst. Kunden, installerad på någon Grid klient värd (användargränssnitt eller anställda noder) är ingångspunkten till datahanteringssystemet. Den tar emot förfrågningar om filåtkomst och kontaktar en gLiteIO-server. GliteIO-servern iscensätter sedan begäran. Den kontaktar först FiReMAN-filkatalogen för att kontrollera ett säkert Grid medicinsk DM gränssnitt till gLite 51 filåtkomstbehörigheter och identifierar den fysiska server som berörs av begäran. Den hanterar sedan filöverföringen. GliteIO-servern, som är den enda inmatningspunkten till datahanteringssystemet, säkerställer att all dataåtkomst är korrekt auktoriserad. gLiteIO är också rätt plats för att orkestrera ytterligare tjänster såsom datakryptering/dekryptering i realtid. Den använder standard symmetrisk nyckelalgoritm AES chiffer som finns i OpenSSL-distributionen för detta ändamål. AES analyseras grundligt och erkänns robust av säkerhetsgemenskapen. Krypteringsnycklarna lagras i en specifik uppsättning servrar som heter Hydra. Hydra ger kontrollerad åtkomst till krypteringsnyckeln (genom certifikat DN-baserade ACL, på samma sätt som vad som görs för filer) och säker kommunikation till begäraren. Dessutom utnyttjar Hydra Shamirs hemliga delningssystem [36] för att förbättra säkerheten och tillförlitligheten hos denna tjänst. Shamirs system består i att dela upp nycklar i n-fragment som lagras på olika platser. Endast m (med m < n) fragment behövs för att rekonstruera en komplett nyckel. Att äga mindre än m nyckelfragment ger dock ingen information om hela nyckeln. Därför är systemet både motståndskraftig mot attacker (minst m nyckel butiker måste äventyras för en angripare för att kunna rekonstruera en nyckel) och tillförlitlig (frånkoppling eller förlust av ett begränsat antal servrar hindrar inte nyckeln rekonstruktion). Hydra-servrarna som har nyckelaktierna är helt identiska när det gäller gränssnitt och funktionalitet. Dessutom kan gliteIO parametriseras för att aktivera eller inaktivera data och styrflöden kryptering självständigt. I vår inställning avaktiveras dataflödeskryptering eftersom datafiler krypteras för lagring och redan transporteras krypterade. Detta undviker att införa en extra overhead med nätverkskryptering. Omvänt krypteras styrflödet så att användarens önskemål inte avslöjas. Patientjournaler som innehåller personuppgifter är den känsligaste typen av medicinska uppgifter. Därför bör metadata som är kopplade till medicinska bilder kontrolleras minst lika hårt som själva bilddatan. Metadata behöver lagras i en databas snarare än i bildfilhuvudena för att dra nytta av databassystemets finkorniga åtkomstkontroll över data och för att förbättra flexibiliteten och prestandan hos frågor. Tjänsten glite AMGA [4] är ett säkert gränssnitt till traditionella databasers back-ends (MySQL, Postgres, Oracle). AMGA implementerar glitestandardgränssnittet för metadatalagring. Det möjliggör finkornig åtkomstkontroll genom Grid-certifikat med DN-baserade ACL. Per bord finns åtkomstkontroll och kolumnåtkomst kan begränsas genom specifika tabellvyer. AMGA har testats grundligt och uppvisar utmärkta prestanda [31].
Medical Data Manager (MDM) REF är en datahanteringstjänst utformad för att hantera medicinska bilder på Grids, starkt baserad på glite middleware.
A Secure Grid Medical Data Manager Interfaced to the gLite Middleware
{'venue': 'Journal of Grid Computing', 'journal': 'Journal of Grid Computing', 'mag_field_of_study': ['Computer Science']}