Recuperação de Exames em Sistemas de Informação Hospitalar com Suporte a Busca de Imagens Baseada em Conteúdo

Transcrição

1 Recuperação de Exames em Sistemas de Informação Hospitalar com Suporte a Busca de Imagens Baseada em Conteúdo Myrian R. B. Araujo 1, Caetano Traina Jr 2, Agma Traina 3, Paulo M. A. Marques 4 1,2, 3 Grupo de Bases de Dados e Imagens (GBDI), Instituto de Ciências Matemáticas e de Computação (ICMC ), Universidade de São Paulo (USP), Brasil 4 Centro de Ciências das Imagens e Física Médica do Hospital das Clínicas (CCIFM-HC), Faculdade de Medicina de Ribeirão Preto (FMRP), Universidade de São Paulo (USP), Brasil Resumo - Este artigo ilustra como manter imagens médicas em uma base de dado relacional, satisfazendo os mecanismos de armazenamento de um PACS (Picture Archivind and Communication System). Incluindo habilidade de responder consultas por similaridade baseada no conteúdo da imagem, obtendo uma rápida recuperação das imagens baseada em uma estrutura de índice. Um conceito importante é a definição da função distância baseada nas características que foram extraídas das imagens quando as imagens foram armazenadas na base. Uma extensão da linguagem SQL possibilita a construção de um interpretador que intercepta os comandos estendidos e os traduzem para SQL padrão, permitindo obter vantagens em qualquer servidor de banco de dados relacional. Experimentos realizados com a implementação de um protótipo usando estes conceitos, responderam consultas com tempo até 20 vezes mais rápido, quando comparado com os servidores relacionais existentes. Além disso, este sistema é o primeiro a integrar recuperação baseada em conteúdo com uma base de dados relacional em uma arquitetura aberta podendo ser integrado em qualquer base de dados operacional ou administrativa de um HIS (Hospital Information Systems). Palavras-chave: Sistemas de Informação Hospitalar, Recuperação de imagens baseada em conteúdo. Abstract - This paper shows how to support medical images in a relational database, so it can fulfill the requirem ents to be used as the storage mechanism of a PACS (Picture Archivind and Communication System). This support includes the ability to answer sim ilarity queries based on the image content, providing fast image retrieval based on indexing structures. The main concept allowing this support is the definition of distance functions based on features, which are extracted from the images as they are stored in the database. An extension to the SQL language enables the construction of an interpreter that intercepts the extended commands and translate them to standard SQL, allowing to take advantage of any relational database server. We describe experiments made with a prototype implemented using these concepts, which allowed answering queries up to 20 times faster than using only existing relational servers. In addition, this is the first system to integrate content-based image retrieval with a relational database in an open architecture that can be integrated to existing operational or administrative databases of one HIS (Hospital Information Systems). Key-words: Hospital Inform ation Systems, Content-based Retrieval of Images. Introdução Bases de dados relacionais armazenam grande quantidade de informações em tabelas compostas por atributos de vários tipos, o emprego destas bases conduz a sistemas de informação flexíveis, expansíveis e de fácil manutenibilidade. Infelizmente, bases de dados relacionais não suportam imagens adequadamente. Imagens são armazenadas, nestes sistemas, como dados do tipo Binary Large Objects - Blobs, permitindo que as mesmas sejam recuperadas por meio de atributos textuais ou numéricos a elas associadas. Porém, isto não é suficiente para um grande número de sistemas que lidam com imagens, por exemplo, aplicações médicas como HIS (Hospital Information Systems) que manipulam vários tipos de imagens provenientes de exames como raios x, tomografia, ressonância magnética, etc., ou seja, sistemas de informação radiológica. Para análises médicas é mais importante recuperar imagens que são similares a uma dada imagem. Isto ocorre

2 quando um médico necessita comparar casos anteriores ou para verificar o diagnóstico. Então, as imagens devem ser eficientemente armazenadas e recuperadas por técnicas adequadas baseada no conteúdo da imagem. Para satisfazer as necessidades de sistemas de recuperação baseado no conteúdo da imagem, uma extensão da linguagem SQL (Structured Query Language) foi desenvolvida [1]. Esta extensão foi projetada para ser naturalm ente integrada em aplicações que executam operações que já existem e acessam dados tradicionais como sistemas de prontuário m édico eletrônico, sistemas de cadastro de paciente, sistemas administrativos entre outros. Assim, o SQL padrão deve ser estendido para perm itir a construção e/ou ampliação de aplicações que já acessam dados tradicionais (textos e números) para permitir que estas possam suportar dados como imagens. Por esta razão, é impossível adotar sistemas como o QBIC [2] que não permite a interação com outras aplicações já em operação em um HIS. Um enfoque usualmente dado para aplicações que lidam com grandes conjuntos de imagens é arm azena-las em um repositório comum. Um exemplo é o sistema PACS (Picture Archiving and Communication System) baseado no form ato DICOM (Digital Imaging and Communications in Medicine) [3] usado em muitos hospitais com grande aceitabilidade [4]. Nestes sistemas, as im agens são etiquetadas no form ato DICOM e armazenadas no núcleo de armazenamento do sistema. As imagens provenientes de diferentes tipos de exames e/ou diferentes equipamentos são armazenadas juntas e classificadas por conjuntos individualmente etiquetados para cada imagem. Este enfoque é adequado para distribuir imagens, porque para cada arquivo que contém uma imagem tem-se a identificação de sua aquisição, dados do paciente e outros dados pertinentes. Então a informação nunca é perdida. Porém, este enfoque não é adequado para executar operação de recuperação de imagens, pois para cada requisição de um subconjunto de imagens é necessária uma leitura seqüencial de todo o conjunto imagem. Geralm ente um software de aplicação médica é projetado para processar imagens originárias de um equipamento específico ou de tipos de exam es, então a solicitação de procurar por um conjunto de imagens para ser processada por uma aplicação específica é uma operação muito comum. No entanto, a leitura de grandes conjuntos de todas as características das imagens armazenadas é uma operação custosa. Então o PACS extrai valores de etiquetas específicas para cada im agem quando estas estão sendo armazenadas no sistema, dentro de tabelas de diretórios. Quando uma consulta solicita imagens baseadas nos valores das etiquetas, os diretórios são usados para selecionar as imagens solicitadas, acelerando o processo de respostas da consulta. Porém, a escolha de qual etiqueta que deve ser mantida nos diretórios é ineficiente, tornando todo o sistema inflexível, difícil de melhorar ou expandir, e difícil de efetuar manutenção. Além disso, operações de seleção de imagens usando técnicas de recuperação baseada em conteúdo são operações ortogonais em relação as operações de seleção de imagens usando o método baseado em etiquetas, resultando na duplicação de esforços, reduzindo assim a eficiência e a flexibilidade do sistema [5]. Este artigo mostra como melhorar os gerenciadores de bases de dados relacionais para suportar imagens. O sistema proposto pode ser usado com o base de mecanismos de armazenam ento de um PACS através da extensão do SQL padrão. Adicionando ao sistema resultante não somente as propriedades desejadas de flexibilidade, expansibilidade e alta m anutenibilidade fornecida pelo sistema relacional; mas também a consistência da distribuição de imagens presente no PACS e no formato DICOM e o suporte eficiente para operações de recuperação de imagens baseada em conteúdo, tendo-se também o cuidado de projetar a extensão SQL de forma a m inim izar as m odificações da linguagem e ao mesmo tempo maximizando o poder para expressar condições de recuperação de imagens. Os sistemas PACS foram construídos para centralizar o armazenamento de imagens, fornecendo uma forma de recupera-las baseada em protocolos bem definidos, e para distribuí-los para client workstation. Estes sistemas não são projetados para serem integrados como outros sistemas existentes, então não é natural incorporar-los em outras aplicações que já existem em um centro médico. Por outro lado, estes sistemas são usualmente construídos usando sistemas de base de dados relacionais, o que facilita a integração com diferentes sistemas que usam a linguagem de acesso relacional padrão, o SQL. Como os SGBD (Sistema de Gerenciam ento de Bancos de Dados) não dão suporte a operação de recuperação de imagem baseada no conteúdo da imagem, foi desenvolvida a camada CIRCE (Content-based Image Retrieval Core Engine), que monitora o fluxo de comunicação entre as aplicações e o servidor da base de dados. Esta comunicação é realizada por meio da versão estendida do SQL padrão. Esta extensão foi desenvolvida de modo a possibilitar a

3 armazenagem de imagens como um novo tipo de dado (o tipo image) permitindo a indexação e recuperação das imagens baseadas em seus conteúdos através de operadores de similaridade. Resumidamente, a Tabela 1 salienta os pontos principais em alguns dos sistemas com suporte a imagens. Vale ressaltar que o trabalho aqui descrito faz parte de um projeto maior do qual participam os grupos de pesquisa: GBDI (Grupo de Bases de Dados e Imagens) do ICMC -U SP (Instituto de Ciências Matemáticas e de Computação) e o CCIFM-HC (Centro de Ciências das Imagens e Física Médica do Hospital das Clínicas) da FMRP- USP (Faculdade de Medicina de Ribeirão Preto). Tabela 1 Sistemas com suporte a imagens Sistemas PACS QBIC CIRCE Metodologia Imagens Recuperação Arquitetur a Imagens são Baseado no Fechada armazenada form ato s juntas e DICOM etiquetadas Dados extraídos das imagens Tipo imagem usado como um tipo nativo no SGBD Imagem baseada em conteúdo Imagem baseada em conteúdo Fechada Aberta A recuperação de imagens baseada no conteúdo das mesmas é um processo que requer muito tempo de processam ento. Então geralmente as com parações entre as imagens são feitas por meio de um conjunto de características (extraídas das imagens que descrevem a imagem) e não através da própria imagem. Tais características podem ser fornecidas por especialistas. Porém, usando-se algoritm os autom áticos com a finalidade de obter tais características melhores resultados são alcançados, eliminado-se a subjetividade do processo, permitindo também o processamento de um a grande quantidade de dados. Um extrator é um algoritmo de processam ento de imagem que, aplicado sobre uma im agem, extrai um conjunto numérico de valores, usados para descrever a im agem. Um vetor de característica é um subconjunto de valores extraídos por um ou mais extratores sobre uma imagem. Vetores de característica podem ser usados para comparar pares de imagens, permitindo uma filtragem preliminar sobre o conjunto de imagens. Se uma nova imagem é armazenada na base de dados, um ou mais extratores obtém os vetores de características desta imagem, os quais são armazenados como atributos numéricos junto com a imagem. Quando as imagens precisam ser recuperadas, o m ecanismo de busca tenta encontrar as imagens mais similares, comparando as com as imagens solicitadas na consulta. Isto é feito usando-se o vetor de característica das imagens armazenadas e das imagens fornecidas para a consulta. Para suportar recuperação de imagens baseada na similaridade do conteúdo da imagem, é necessário definir o que significa similaridade. Isto é feito por meio da DF() (Distance Function). Uma função de distância métrica sobre duas imagens, ou seja, DF() é um algoritmo que compara os vetores de característica das duas imagens satisfazendo propriedades algébricas bem definidas (não negatividade, simétria e desigualdade triangular) em um domínio m étrico, e retorna um valor não negativo que é m enor quanto mais similar as imagens são. Como a DF() é construída usando vetores de característica, estes podem ter um a ou m ais DF() associadas para um dado conjunto de imagens. Por exemplo, uma DF() baseada no histograma [6], histograma métrico [7], no número de ocorrências do objeto [8], etc. Cada DF() usa um vetor de característica. Os operadores de comparação de sim ilaridade mais utilizados para recuperar imagens são os operadores: k-nearest neighbor e range. Dada uma imagem referência Ref i, o operador k-nearest neighbor retorna as k imagens m ais similares à imagem Ref i, e o operador range retorna as im agens m ais sim ilares a Ref i segundo um raio de abrangência dado. Para suportar este tipo de consultas, a extensão do SQL criada permitiu a definição dos seguintes conceitos: a definição de um tipo de dados imagem como um tipo nativo; a definição de vetores de características e a DF() correspondente; condições de sim ilaridade baseada nos operadores k-nearest neighbor e range; e a criação de estruturas de índices baseada nos vetores de característica e na DF(). Um dos principais conceitos é o fato de considerar imagens como outro tipo de dado nativo suportado pelo SGBD. Portanto as imagens são armazenadas como atributos em qualquer relação que as requer onde cada relação pode ter qualquer número de atributos do tipo image. Por exemplo, considere um registro de paciente que armazene em um a relação chamada Paciente atributos pertinente ao paciente e entre estes dois atributos

4 do tipo imagem: o atributo Foto e o atributo RaiosxPulmão. Imagens são declaradas usando o novo tipo de dado image no comando de criação da tabela. A arquitetura geral do CIRCE é ilustrada na Figura 1. Esta figura mostra três bases de dados: a base ADB (Application Database), IPV (Images and Parameter Values) e IDD (Image Data Definition) - apesar de todas serem fisicam ente constituídas da mesma base de dados. A base ADB corresponde a bases de dados de aplicações já existentes, tal como a base de dado adm inistrativa do hospital ou o tradicional sistema de cadastramento de registros de pacientes. As aplicações existentes não suportam imagens, então os atributos armazenados nas relações da base ADB são somente numéricos e/ou textos. A ADB pode ser consultada usando ou a SQL padrão ou a SQL estendida. No entanto, quando uma aplicação perm ite o suporte a imagens, esta aplicação deve usar o SQL estendido através do CIRCE. Figura 1 Arquitetura CIRCE Se um comando query (consulta) usa som ente atributos que não são do tipo image, o comando é m andado diretamente para o ADB. Se um atributo do tipo image está envolvido no comando query, CIRCE usa as bases de dados IPV e IDD, junto com as estruturas de indexação métrica e os parâmetros extraídos das imagens, para modificar o comando query, efetivamente implementando a recuperação de imagens baseada no conteúdo das mesmas. A estrutura de indexação usada é a Slim-tree [9], a estrutura de acesso m étrico m ais eficiente atualm ente. As bases de dados IPV e IDD mantêm informações sobre cada atributo imagem definido na aplicação. Para cada atributo uma nova relação é criada na base IPV, contendo dois atributos: um atributo blob armazenado realmente a imagem, e um identificador da imagem (ImId) criado autom aticamente pelo sistema. O identificador é um código numérico, único para cada imagem na base de dados, indiferente da relação ou atributo onde ele é armazenado. Todo comando create table envolvendo atributo imagem é modificado, colocando-se um tipo num érico no lugar do tipo de dado image, em seguida este comando modificado é enviado para o ADB. A correspondente relação da base de dados IPV é chamada após a concatenação da tabela e nomes dos atributos do atributo imagem original. Desta forma, as ocorrências destes atributos em com andos query são interceptadas pelo CIRCE e transformadas adequadamente. Por exemplo, a tabela Paciente com dois atributos do tipo image gera duas relações na base IPV. As relações Paciente_Foto e Paciente_RaiosxPulmão, cada relação com dois atributos: a imagem e o ImId. A comparação de duas imagens requer a definição de um a DF(). Isto é feito através de um único comando no SQL estendido: o comando create metric. Esta é a parte da DDL (Data Definition Language) do SQL. Cada DF() é associada com pelo menos um atributo imagem, e um atributo im agem pode ter qualquer número de DF(). Atributos imagem que não têm uma DF() não podem ser usados em condições de busca, então estes só são armazenados e recuperados na forma usual. No entanto, se uma ou mais DF() é(são) definida(s), esta(s) pode(m) ser usada(s) nas condições de busca baseada no conteúdo da imagem e nos m étodos de indexação m étricos. Uma DF() associa um ou mais extratores e um subconjunto de características recuperadas por eles. Consideram-se somente as características numéricas ou vetores de números. Quando a DF() é definida para um atributo imagem, a relação correspondente na base IPV é modificada para adicionar elementos do vetor de característica como atributos numéricos. A base IDD é o esquema para atributos imagem, e armazena informações sobre os extratores e seus parâmetros. Assim a base de dados guia o sistema para armazenar e recuperar atributos na base IPV. Quando uma relação envolvendo atributos do tipo image é armazenada, cada imagem é processada pelo conjunto de extratores no módulo XP (Parameter Extractors), seguindo as definições de recuperação da base IDD. Após esta operação, seu ImId é criado e armazenado, junto com a imagem e o vetor de característica, na base IPV. A relação original é armazenada na ADB, trocandose as imagens pelos correspondentes identificadores ImId. Índices podem ser criados para cada imagem usando a DF() definida para eles. Se uma nova imagem é armazenada em um atributo que

5 pode ser indexado, o vetor de característica é usado para indexar a imagem. Quando um atributo imagem é indexado, uma Slim-tree deve ser criada para cada métrica definida para este atributo. Isto possibilita a recuperação de im agens baseadas em m ais de um critério de similaridade, permitindo ao usuário escolher qual é o critério necessário para responder cada consulta. Cada Slim-tree armazena o ImId e o vetor de característica extraído para cada imagem. Permitindo a execução de procedimentos de busca de k-nearest neighbors e range usando os vetores de características como entrada e retornando o conjunto de ImId que responde a consulta. Por m eio destes identificadores (ImId) a base IPV é utilizada para recuperar as imagens reais que, são passadas como resposta da requisição solicitada. base não estava preparada para que as consultas fossem realizadas utilizando-se a DF()). Porém, mais importante que a expressiva redução do tem po requerido no processamento total, é o fato de que as operações de consulta podem ser desempenhadas usando-se a extensão da linguagem de consulta que foi desenvolvida. Resultados CIRCE foi implementado usando a linguagem C++ utilizando o ambiente de programação C++Builder da Borland, rodando no sistema operacional MS-Windows NT acessando um servidor de banco de dados Oracle. A máquina servidor utilizada foi um IBM NteInfinity com 256 MBytes de memória e discos SCSI, com um processador Pentium III 800 Mhz. A máquina cliente foi um Pentiun III 750 Mhz com 256 MBytes de memória, conectada ao servidor através de um link Ethernet 100 Mhz. Para a medida de desempenho obtida, foi modificada uma aplicação existente que busca um conjunto de doença específica. A versão original recupera todo o conjunto de tomografias da cabeça com o auxílio do servidor Oracle usando SQL padrão, e então pré-processa cada imagem usando filtros baseados em histogramas. Usandose um conjunto de 5049 tomografias da cabeça (~2gBytes de disco), o total de tempo obtido na resposta foi aproxim adamente de quatro horas. Na versão modificada, uma DF() foi criada utilizandose a arquitetura CIRCE, usando-se o extrator histograma métrico. A fase de pré-processamento da aplicação foi removida, recuperando-se as imagens através de comandos SQL modificado, usando-se o operador de similaridade range query para recuperar as imagens e o histograma métrico como filtro inicial. Trabalhando no mesmo conjunto de tomografias, o tempo total obtido para a resposta caiu para 10 minutos, selecionando-se ainda as mesmas imagens anteriores. O tempo de resposta da consulta foi até 20 vezes m ais rápido. Vale observar que o tempo para extrair o histograma métrico e para criar a estrutura de índice Slim-tree tomou 25 minutos (uma vez que a Figura 2 Recuperação de atributos do tipo image Para suportar o desenvolvimento de aplicações que usam o SQL estendido, foi desenvolvida uma nova versão da ferramenta ISQL (Interactive-SQL) a ferramenta IISQL (Imageenabled Interactive-SQL). Com o a ISQL, a ferramenta IISQL apresenta uma janela onde o usuário pode digitar comandos da linguagem SQL estendida, e a outra janela onde os atributos textuais e numéricos são mostrados como resultado de uma consulta. Porém, a ferramenta IISQL adiciona a interface ISQL uma nova janela, onde os atributos do tipo image de uma relação selecionada podem ser visualizados. A Figura 2 ilustra um a tela da ferramenta IISQL mostrando uma consulta simples sobre a relação patient. Discussão e Conclusões Este artigo descreveu como uma poderosa extensão pode ser feita com poucas modificações na linguagem relacional padrão SQL. Um protótipo foi implem entado e conectado a uma base de dado relacional usado em um centro radiológico em um grande hospital. A abordagem adota no sistema CIRCE oferece o suporte à recuperação baseada em conteúdo de imagens em uma arquitetura aberta. Pois perm ite utilizar qualquer gerenciador relacional comercial que ofereça o suporte à armazenagem de imagens como cam pos longos, e

6 não exige alterações nos esquemas dos aplicativos já existentes num ambiente hospitalar, habilita o suporte à imagens com um mínimo de impacto na estrutura já existente. Resultados preliminares obtidos constatam também que o tempo de resposta é bom, tendo até agora se mostrado sistematicamente melhor do que o obtido por sistemas de arquitetura fechada. Agradecimentos Os autores agradecem à FAPESP e ao CNPq o suporte financeiro para a realização deste trabalho. Referências [1] Araujo, M. R. B., Traina, A., Traina, C. J., (2002), Extending SQ L to Support Image Contentbased Retrieval, in IASTED ISDB, Tokyo, Japan. [2] Flickner, M., Sawhney, H., Niblack, W., Ashley, J., Huang, Q., Dom, B., Gorkani, M., Hafner, J., Lee, D., Petkovic, D., Steele, D., Yanker (1995), Query by Image and Video Content: The QBIC System, IEEE Computer, vol. 28, p [3] Horiil, S.C. (1994), DICOM: An introduction to the standard, Disponível na URL: COMIntro.html. [4] Cao, X., Huang, H. K. (2000), Current Status and Future Advances of Digital Radiography and PACS, IEEE EMBMag, vol. 9, p [5] Araujo, M. R. B., Traina, C. J., Traina, A., Bueno, J. M., Razente, H. L. (2002), Extending Relational Databases to Support Content-based Retrieval of Medical Images, in IEEE CBMS, Maribor, Slovenia, p [6] Brunelli, R., Mich, O. (1999), On the Use of Histograms for Image Retrieval, IEEE ICMCS, Florence, p [7] Traina, A., Traina, C. Jr., Bueno, J. M., Marques, P. M. A. (2002), The Metric Histogram: A New and Efficient Approach for Content-based Image Retrieval, in IFIP VDB, Brisbane, Australia. [8] Comunello, E.,Wangenheim, A. V., Barreto, J.M., Borges, P.S., Wille, P.R., Bittencourt, P.C., Krechel, D., Faber, K. (1999), CT Scans with Neurocysticercosis in Epileptics Patients: A Computer-Based Method for Detection and Quantification, in 12th IEEE CBMS'00, Stamford, CO, p [9] Traina, C. Jr., Traina, A., Faloutsos, C., Seeger, B. (2002), Fast Indexing and Visualization of Metric Datasets Using Slim-trees, IEEE TKDE, vol. 14, p Contato 1,2, 3 Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo ICMC/USP Av. do Trabalhador São-Carlense, CEP São Carlos (SP) [mrenata caetano agma]@icmc.usp.br 4 Centro de Ciências das Im agens e Física Médica FMRP/USP Rua Marechal Deodoro, Ribeirão Preto (SP) pmarques@fmrp.usp.br