4.3.1 Procedimentos Metodol´ogicos
Os procedimentos metodol´ogicos empregados para o desenvolvimento do modelo que esta sendo proposto iniciaram com a revis˜ao da literatura, bus- cando embasar `as escolhas que foram realizadas com o que h´a de mais atual nas bases de conhecimento nacionais e internacionais. Ap´os isto, houve uma etapa de especificac¸˜ao e an´alise sobre as partes do modelo, onde baseados no modelo conceitual atual e sua consequente arquitetura, somada a entrevistas com especialistas pˆode-se conceber um modelo conceitual para o armazena- mento e recuperac¸˜ao das imagens m´edicas.
Desta foram, baseando-se no modelo conceitual proposto, foi desen- volvida uma arquitetura computacional que cobriu a totalidade do modelo conceitual. Esta arquitetura foi desenvolvida utilizando-se de componentes que tˆem func¸˜oes espec´ıficas e bem determinadas na operac¸˜ao da arquite- tura. Para a avaliac¸˜ao da arquitetura proposta, foi elaborado um estudo de caso onde o modelo, figurado atrav´es da arquitetura, foi implantando em um cen´ario real. Desta forma houve uma etapa de verificac¸˜ao para determinar a efetividade do modelo proposto para o que ele se propˆos. Esta ´ultima fase ser´a apresentada no Cap´ıtulo 5, onde ser´a apresentada a validac¸˜ao da arquitetura proposta.
4.3.2 Modelo Conceitual
Dado o contexto apresentado, nesta sec¸˜ao ´e detalhado o modelo con- ceitual para persistˆencia de exames m´edicos baseados em imagens DICOM. Na Figura 26 ´e poss´ıvel visualiz´a-lo em detalhes. Uma das importantes carac- ter´ısticas deste novo modelo ´e a adaptabilidade e flexibilidade para integrac¸˜oes a modelos mais tradicionais, visto que com pouco esforc¸o pode-se adaptar a sistemas de Telemedicina, RIS, HIS ou PACS. Ainda, como complemento, a partir desta integrac¸˜ao, toda a parte superior de modelos tradicionais de sis-
temas de informac¸˜ao ou conhecimento permanece exatamente com seu modo de operac¸˜ao, n˜ao havendo impacto para os usu´arios em geral.
Figura 26: Modelo Conceitual de Armazenamento Proposto. Dessa forma, as camadas relacionadas a equipamentos m´edicos, usu´a- rios em geral, interfaces, camada de imagens, camada de aplicac¸˜ao e interpre- tador de comandos j´a foram dissertadas e na concepc¸˜ao deste novo modelo, elas n˜ao ser˜ao alteradas, visto que um dos requisitos para uma boa aceitac¸˜ao de um novo modelo de armazenamento ´e a adaptabilidade a modelos pr´e- existentes, desta forma, atendendo a este importante crit´erio. Nesta proposta de modelo foram criadas as camadas de indexac¸˜ao, hierarquizac¸˜ao, virtual de acesso, paralelizac¸˜ao, serializac¸˜ao, distribuic¸˜ao de dados, virtual de acesso e por fim a camada de armazenamento.
A Camada de Indexac¸˜ao foi concebida no sentido de indexar os me- tadados advindos do servidor de imagens, visto que isto ´e um requisito muito importante para um sistema desta natureza. Nessa camada est˜ao implementa- das func¸˜oes de busca (C-Find) e recuperac¸˜ao (C-Get e C-Move) de de alto n´ıvel para que os desenvolvedores da aplicac¸˜ao possam us´a-las de forma mais usual. Vale ressaltar que em um cen´ario cl´assico, os desenvolvedores integrariam sua aplicac¸˜ao usando conectores e interfaces, da linguagem de programac¸˜ao, aos sistema gerenciadores de bancos de dados relacionais.
A Camada de Hierarquizac¸˜ao ´e respons´avel por receber os dados advindos do servidores de imagens, entre eles os metadados (desconstru´ıdos) e hierarquiz´a-los dentro do formato de dados especificado. Ela tem func¸˜ao de proporcionar preservac¸˜ao dos dados, acesso randˆomico, portabilidade e multiplataforma. Num conceito de mais alto n´ıvel, nesta camada que esta localizado a modelagem do sistema de armazenamento de dados, onde h´a descritores que indicam como determinado metadados vai ser hierarquizado e em que ponto da hierarquia, para posteriormente ser armazenado.
A Camada Virtual de Arquivos pode ser visualizada na Figura 27. Este ´e um componente do modelo que tem a func¸˜ao de tratar as operac¸˜oes de entrada e sa´ıda (I/O) em baixo n´ıvel, de forma que a aplicac¸˜ao possa ler e gravar dados utilizando variados recursos de armazenamento de dados. Esta camada serve no modelo como uma interface entre as camadas inferiores e superiores, intermediando as operac¸˜oes de armazenamento, nos meios que forem declarados. Como exemplo, nesta camada que o MPI-IO pode ser integrado, abstraindo assim a complexidade de desenvolver para este tipo de sistema de armazenamento paralelo.
A Camada de Paralelizac¸˜ao e Camada de Serializac¸˜ao s˜ao as cama- das que determinam qual tipo de escrita e leitura ser´a realizada para o modelo como um todo. Neste caso, ´e poss´ıvel realizar escritas de forma paralela, divi- dindo os dados em partes e gravando simultaneamente em diferentes partes de um agregado computacional. Por outro lado, na camada de serializac¸˜ao esta usa tipos comuns de escrita e leitura, que pode ser tanto usada para agrega- dos computacionais, como tamb´em em sistemas de arquivos convencionais. Para este modelo, esta sendo uma abordagem distribu´ıda, entretanto, devido aos quesitos de flexibilidade j´a expostos, ´e poss´ıvel tamb´em usar o mesmo modelo de forma local, em um ´unico nodo computacional ou reposit´orio de dados.
A Camada de Distribuic¸˜ao de Dados ´e a respons´avel por gerenciar a distribuic¸˜ao dos dados no ambientes distribu´ıdos aplicados nas arquiteturas advindas deste modelo. A func¸˜ao ´e abstrair dos desenvolvedores as tarefas de alocac¸˜ao de dados nos nodos. Este ´e uma camada intermedi´aria que serve como interface entre os m´etodos de gravac¸˜ao e leitura (serial ou paralelo) e
Figura 27: Camada Virtual de Arquivos
os sistemas de arquivos distribu´ıdos que persistem de fato os exames. A Camada Virtual de Acesso tem a func¸˜ao de intermediar as soli- citac¸˜oes de distribuic¸˜ao de dados e os nodos computacionais onde os dados realmente est˜ao armazenados. Neste camada est˜ao alocados middlewares dos sistemas de arquivos distribu´ıdos que intermediar˜ao os processos de gravac¸˜ao ou recuperac¸˜ao de dados. Por fim, a Camada de Armazenamento tem a func¸˜ao de servir de backend para os dados. Nela de fato que os objetos DI- COM, j´a hierarquizados s˜ao armazenados. Nesta camada est˜ao localizados os agregados computacionais, servidores de dados, sistemas de armazenamento de dados (storages).
A func¸˜ao geral das camadas expostas ´e expressar, de forma concei- tual, como um sistema de armazenamento hier´arquico ´e constitu´ıdo. Mode- los como estes servem de base para concepc¸˜ao e posterior desenvolvimento de arquiteturas que o implementar˜ao na pr´atica para suportar cen´arios reais. Na Sec¸˜ao 4.4 uma arquitetura baseada neste modelo ser´a proposta, buscando implementar cada uma das camadas expostas, afim de validar o modelo que esta sendo proposto nesta tese.
4.3.3 Modelo de Dados e Indexac¸˜ao
Passada a etapa de construc¸˜ao do modelo conceitual de persistˆencia, da mesma forma que em um modelo tradicional, os dados devem ser modelados
antes de serem persistidos. Desta forma, notou-se a necessidade de definir um modelo de dados espec´ıfico para as imagens m´edicas. Para isto, foram realizadas reuni˜oes com especialistas em imagens m´edicas, t´ecnicos, gesto- res hospitalares e m´edicos para definir como seria o modelo que seria utili- zado. Assim, seguiu-se estreitamente a documentac¸˜ao do padr˜ao DICOM, com relac¸˜ao a estruturas e tipos de dados. Desta foi foi concebido o modelo de dados que ´e poss´ıvel ser visto na Figura 28.
Figura 28: Modelo de Dados Hier´arquicos.
Este modelo ´e constitu´ıdo em um grupo raiz (/), do pr´oprio mecanismo do HDF5, onde iniciam-se as operac¸˜oes de escritas e a hierarquia do arquivo. Logo abaixo, optou-se por determinar o hospital que o estudo esta sendo re- alizado. Neste ponto, ´e importante dizer que mesmo o paciente possa fazer m´ultiplos exames, em instituic¸˜oes distintas, o modelo de dados prevˆe esta ati- vidade e integrar´a o novo estudo ao prontu´ario do paciente. Isto ´e realizado atrav´es do sistema de links de datasets do HDF5.
Logo abaixo, esta localizado o paciente, com todos os seus metadados de identificac¸˜ao, como nome, n´umero de identificac¸˜ao, cart˜ao SUS, enderec¸o, nome da m˜ae e do pai, data de nascimento, entre outros. Um paciente pode ter um ou mais estudos, que cont´em uma ou mais series, que cont´em uma ou mais imagens. Cabe ressaltar aqui que este modelo usa metadados de identificac¸˜ao do estudo, da s´erie e da instˆancia em cada um dos pontos de hierarquia e que estes dados servem para localizar e ordenar os exames. Este modelo de dados tem como caracter´ıstica ser altamente flex´ıvel, podendo ser modifi- cado no momento da criac¸˜ao das estruturas do arquivo HDF5, n˜ao havendo implicac¸˜oes com o tamanho final do arquivo que ir´a persistir os exames.
Concomitante ao modelo de dados proposto, um modelo de indexac¸˜ao dos dados foi desenvolvido. Este modelo, exposto na Figura 29, foi desen-
volvido utilizando o mecanismo de indexac¸˜ao de documentos do CLucene, j´a apresentado anteriormente. O CLucene se apresenta como a escolha neste trabalho para a estrat´egia de utilizando ´ındices invertidos. Ainda, o CLucene se apresenta como uma escolha conveniente para indexac¸˜ao de conjuntos de dados HDF5, devido a suas semelhanc¸as de arquitetura, j´a apresentadas ante- riormente.
Na Figura 29 ´e poss´ıvel visualizar ainda como este processo de indexa- c¸˜ao ´e realizado. O processo inicia quando um objeto DICOM ´e desconstru´ıdo e os metadados repassados para o extrator de termos do CLucene que inicia a gerac¸˜ao dos documentos. Nesta etapa do processo s˜ao gerados trˆes documen- tos distintos, que est˜ao interligados entre si, que s˜ao relacionados aos estudo, a s´erie e a instˆancia (imagem). Uma informac¸˜ao importante ´e que s´o meta- dados selecionados s˜ao indexados, com objetivo de localizar os arquivos no sistema de persistˆencia.
Figura 29: Extrac¸˜ao dos Metadados e Gerac¸˜ao do ´Indice.
Os metadados indexados foram definidos de acordo com o padr˜ao DI- COM, sendo estes os obrigat´orios para sistemas de busca e recuperac¸˜ao de dados, de acordo com documentos da NEMA. Entre estes metadados, no n´ıvel do estudos s˜ao o StudyInstanceUID (identificac¸˜ao do estudo), Study- Date (data do estudo), StudyTime (hora do estudo), PatientID (identificac¸˜ao do paciente dono do estudo), PatientsName (nome do paciente). No n´ıvel da s´erie, os metadados indexados s˜ao o StudyInstanceUID (relac¸˜ao com o estudo), SeriesInstanceUID (identificac¸˜ao da s´erie), Modality (tipo de moda-
lidade da s´erie), SeriesNumber (n´umero da s´erie). Por fim, no n´ıvel da ima- gem, ou instˆancia, os metadados indexados s˜ao o StudyInstanceUID (relac¸˜ao com o estudo) SeriesInstanceUID (relac¸˜ao com a s´erie), SOPInstanceUID (identificac¸˜ao da instˆancia) e InstanceNumber (n´umero da instˆancia).
No final do processo de construc¸˜ao dos documentos CLucene, relaci- onados com os estudos, s´eries e instˆancias, os 3 documentos s˜ao indexados e o processo tem finaliza. Por fim, os metadados selecionados para comporem o esquema de indexac¸˜ao deste modelo podem ser estendidos ou ainda, modi- ficados, de acordo com a necessidade da aplicac¸˜ao, indexando novos termos, relacionados a metadados, que podem posteriormente serem recuperados pelo CLucene.