Domínios de interfaces OMA

Os domínios OMA são facilidades verticais direcionadas a um segmento de mercado específico. Cada domínio CORBA fornece interfaces padronizadas que abordam questões pertinentes de um modelo de negócios em particular.

Atualmente, existem nove forças tarefas atuando em domínios específicos de mercado. Existem forças tarefas especializas em domínios de negócio, finanças, comércio eletrônico, manufaturamento, medicina, telecomunicações, transportes, e utilidades são alguns exemplos.

4.5.1 HealhCare DTF (HealthCare Domain Task Force)

O domínio vertical pertinente a este trabalho é o HealhCare DTF. Inicialmente chamado CORBAMed, o HealhCare DTF compreende diversas especificações relacionadas a indústria médica e representa vendedores, fornecedores de planos de saúde e usuários finais. Ele define interfaces padronizadas entre serviços médicos relacionados. Estas interfaces fornecem uma interoperabilidade adicional para que aplicações que utilizem o padrão CORBA de maneira transparente.

A primeira especificação produzida pelo HealhCare DTF foi direcionada para a padronização de interfaces e integração de sistemas identificação única de pacientes. A seguir será apresentada uma visão geral sobre a mesma.

4.5.1.1 PIDS (Person Identification Service)

A especificação PIDS define um modelo de referência baseado em interfaces CORBA para o gerenciamento de identificadores de pacientes. Especificamente o PIDS visa prover as seguintes funcionalidades:

§ Suporte de IDs em um particular domínio e a correlação de IDs entre múltiplos domínios.

§ Suporte à busca e pareamento de informações de pacientes de maneira interativa e também automatizada, independente dos mecanismos de relacionamento utilizados. § Suporte para criação de federações de PIDS em uma topologia independente.

§ Prover suporte para que implementações de PIDS apliquem políticas de confidencialidade e mecanismo de segurança.

§ Definir níveis de conformidade abrangendo diferentes graus de sofisticações, de sistemas de identificação somente para consulta a federações de sistema de identificação.

A figura 8 descreve os elementos estruturais básicos do modelo de identificação do PIDS.

O Domínio de ID é o bloco básico do modelo PIDS. Um Domínio ID mantém um identificador único (ID) para identidade de pessoas representadas no Domínio ID. Idealmente, existe um e apenas um ID por pessoa, mas na realidade podem existir IDs duplicados onde uma pessoa pode mais de um ID em um mesmo domínio. Para consistência interna, o Domínio ID não pode atribuir duas pessoas para o mesmo ID, caso contrário o sistema não poderá distinguir entre duas entradas de duas pessoas diferentes. O ID é um mecanismo de controle interno e poderá ou não ser utilizado externamente. Desta forma, o ID e seu domínio, juntos, constituem um ID único para uma pessoa.

Na especificação dos PIDS, várias interfaces são detalhadas. As duas mais diretamente utilizadas são IdentifyPerson e ProfileAcess. A interface IdentifyPerson é

provê basicamente um meio de consulta onde se envia características para serem correlacionadas no Domínio ID e recebe-se uma lista de candidatos como resultado. A interface ProfileAccess pode ter a funcionalidade de uma consulta ou atualização usada

Domínio de Correlação

Domínio ID Domínio ID

Domínio ID

para enviar um ID para uma pessoa específica e para receber o perfil desta pessoa. Um perfil é um conjunto de características contendo valores da pessoa para suas respectivas características.

A unidade estrutural coordenadora do modelo PIDS é o Domínio de Correlação. O Domínio de Correlação permite acesso aos perfis correlacionados dos IDs em todos os Domínios ID participantes. O Domínio de Correlação será portanto um bloco de ligação que complementará os existentes Domínios ID, servindo como meio para que um Domínio de ID aumente seu escopo, interagindo com outros Domínio de ID. O Domínio de Correlação define duas interfaces: load_profiles e get_corresponding_id. A primeira é utilizada para adicionar e correlacionar perfis de um paciente. A segunda é utiliza para obter um conjunto de IDs relacionados a um mesmo paciente.

O Domínio de Correlação pode correlacionar tanto um Domínio ID quanto outros Domínios de Correlação, o que permite a construção de estruturas hierárquicas. Como um Domínio ID pode participar de mais de um Domínio de Correlação é também possível a construção de estruturas pares.

4.5.1.2 Aplicação do PIDS para integração de servidores de imagens

O modelo PIDS provê um framework para a manutenção de identificadores únicos de pacientes entre diversas organizações. Entretanto, é importante ressaltar que, o modelo consiste basicamente em um conjunto de interfaces descritas em IDL, que definem wrappers para sistemas de identificação já existentes. Ou seja, não é abordada a resolução do problema em si, que é correlacionar identificadores de diferentes organizações, um problema de relacionamento de registros.

O modelo proposto para o Domínio ID foge do escopo deste trabalho. Como detalhado no capítulo sobre relacionamento de registros, para alimentar o sistema de identificação do Portal de Teleradiologia é que desejável que os participantes possuam os sistemas HIS e RIS integrados. O desenvolvimento de um gerenciador de identificadores para atender as interfaces definidas no Domínio ID representa uma tarefa além da simples integração HIS/RIS.

Por outro lado, os requisitos para a implementação das interfaces do Domínio de Correlação vão de encontro ao modelo proposto neste trabalho. As interfaces load_profiles e get_corresponding_id podem ser mapeadas facilmente para funções já requeridas no sistema MPI do Portal de Teleradiologia. Desta forma, tem-se que a

conformidade com o Domínio de Correlação requer pouca modificação no modelo proposto neste trabalho. Além disso, a especificação PIDS é o modelo referência para o sistema de identificação do cartão SUS. Desta forma, a implantação das interfaces para o Domínio de Correlação garant irão a interoperabilidade futura com este sistema.