Nível federado

No nível federado está o esquema federado, que contém a integração dos múltiplos esquemas de exportação. A arquitetura do Portal de Teleradiologia apresenta duas características que o distinguem de uma arquitetura federada convencional. A primeira é total uniformização entre as entidades obtidas do esquema de exportação. O modelo de informação especificado pelo padrão DICOM permite manter a mesma descrição da estrutura dos dados entre o esquema federado e de exportação. A outra característica é a replicação de parte das instâncias dos bancos de imagens locais,

especificamente são mantidos os atributos relacionados à identificação do paciente e estudo. Como já discutido anteriormente, esta replicação é necessária para manter o sistema MPI e o mecanismo de controle de acesso no sistema federado.

O esquema federado também inclui informações sobre a distribuição dos dados, que são obtidas durante a etapa de integração. Estas informações constituem basicamente os parâmetros necessários para estabelecimento da associação DICOM com os servidores locais. Abaixo está um trecho do arquivo de configuração do CyclopsDICOMServer em sintaxe XML para uma entidade de aplicação cliente.

<dicom>

<AETitle>Olho</AETitle>

<label>DCMServer Client running on Olho</label> <host>olho.lisha.ufsc.br</host>

<address>#[150 162 62 212]</address> <port>4007</port>

</dicom>

As instâncias dos bancos locais são atualizadas pelas notificações enviadas pelas entidades de aplicação de exportação de cada integrante da federação. Somente após a notificação ser recebida pelo sistema federado, é que um estudo local estará disponível para compartilhamento com os demais integrantes da federação. A notificação contém o IOD Basic Study Content Notification estendido com informações adicionais do paciente. Os atributos deste IOD irão ser armazenados no catálogo do sistema federado e utilizados durante a construção das consultas distribuídas.

Os identificadores do paciente serão utilizados pelo sistema MPI para geração de um identificador único para paciente. Este identificador irá referenciar todos os registros de atributos identificados como pertencentes a um mesmo paciente. A figura 11 apresenta um modelo entidade-relacionamento descrevendo a estrutura das informações mantidas no nível federado. As rotinas de relacionamento de registros do sistema MPI são efetuadas em dois momentos pelo sistema MPI: após novos estudos sobre um paciente serem enviados através de uma notificação e quando consultas são realizadas fornecendo apenas dados do pacientes. Estes rotinas possuem requisitos diferentes. A primeira rotina deve priorizar a precisão em detrimento ao tempo de processamento. O processamento pode ser realizado em uma máquina dedicada e/ou em batch. Interações

manuais são previstas para decisão final sobre o relacionamento de dois registros. Ao receber a notificação de um novo paciente de uma entidade de aplicação de exportação, o sistema poderá gerar um identificador único temporário para este paciente. Posteriormente este identificador poderá ser substituído pelo sistema MPI ou efetivado como definitivo. A rotina de relacionamento de registros executada quando um cliente consulta um paciente sem enviar seu identificador como parâmetro deve priorizar o

Figura 12: Modelo entidade -relacionamento do esquema federado

Identificador Único relaciona 1 Paciente N Estudo armazenado em 1 Banco DICOM 1 possui 1 N

tempo de resposta em detrimento à precisão. O retorno de mais de um registro candidato ao cliente é aceitável.

A comunicação de dados no nível federado é realizada através de dois mecanismos distintos. Os clientes do sistema utilizam a arquitetura CORBA, através da invocação de operações para consulta, busca e inserção nos objetos CORBA do sistema federado. Para a associação com servidores DICOM, o sistema federado implementa as classes de serviço Storage e Query/Retrive como SCU e Basic Study Content Notification como SCP.

Dois processadores estão presentes no nível federado: um processador de transformação e um processador de construção. Ambos são implementados em um único objeto servant associado ao objeto CORBA invocado pelo cliente. A rotina que representa o processador de transformação no servant é responsável por receber as requisições de procedimento remoto CORBA e transformá-las nas primitivas de requisição para os servidores DICOM. Após as primitivas de confirmação serem recebidas da máquina de protocolos DIMSE, o processador de transformação realiza o marshalling do conjunto de dados do IOD e o retorna para o cliente. Para otimizar a comunicação entre os objetos CORBA do cliente e do nível federado, é utilizado o serviço de notificação de eventos. Neste caso o objeto CORBA do cliente associa-se ao canal de eventos localizado no sistema federado como consumidor e o objeto CORBA que encapsula o processador de construção associa-se como fornecedor de eventos. Desta forma, cada IOD recebido por uma associação DICOM gera um evento que é enviado ao cliente. A rotina do servant que implementa o processador de construção consulta os registros sobre os servidores DICOM componentes associados aos estudos associados e gera um conjunto de primitivas de requisições DIMSE. A manutenção das instâncias dos elementos de consulta do sistema, no caso os atributos de pacientes e estudos, elimina a necessidade de técnicas complexas para otimização de consultas e localização dos dados em sistemas federados [ZH01].

Como já referenciado anteriormente, o nível federado comporta uma CA para administração das chaves públicas usadas para identificação dos clientes e provedores de dados. Toda a comunicação de dados mediada pelo sistema federado, entre clientes e servidores DICOM é realizada utilizando o TLS como provedor de canal seguro.