Sistema de Gerenciamento de Dados Multimídia e Alfanuméricos de

Sistema de Gerenciamento de Dados Multimídia e Alfanuméricos de uma
UTI Neo−Natal baseado em Padrões
Adriano J. Holanda1, Luiz A. Bailão2,Ivan T. Pisa3, Evandro E. S. Ruiz4
1,3,4Grupo
de Computação de Imagens Médicas − ImagCom, Departamento de Física e Matemática
(DFM), Faculdade de Filosofia, Ciências e Letras de Ribeirão Preto (FFCLRP),
Universidade de São Paulo (USP), Brasil
2
Maternidade Sinhá Junqueira
Ribeirão Preto−SP, Brasil
Introdução
A adoção de padrões internacionais na
construção de sistemas de informação para a área
de saúde tem se tornado fundamental para
integração dos diversos sistemas existentes. Esta
integração é necessária para que o paciente tenha
acesso aos seus dados independentemente do
local de atendimento.
O uso de padrões para a codificação e
classificação
das
observações
clínicas
e
laboratoriais, e para especificação das interfaces e
estrutura de dados dos componentes aumenta a
interoperabilidade entre os sistemas de arquitetura
aberta, diminuindo a redundância e o custo de
armazenamento dos dados. Isto proporciona
acesso eficiente a uma maior quantidade de dados
para a extração da informação necessária às
observações, aumentando a produtividade do
profissional e a confiabilidade da análise.
Metodologia
O objetivo do nosso trabalho é construir um
sistema de gerenciamento de dados médicos,
contendo imagens e dados alfanuméricos utilizando
padrões para o registro e transporte dos dados e
para a construção dos componentes do sistema.
O sistema será implantado na Unidade de
Terapia Intensiva (UTI) Neo−Natal da Maternidade
Sinhá Junqueira de Ribeirão Preto−SP.
O processo utilizado para a construção do
sistema está sendo o RUP (Rational Unified
Process), cujas fases são divididas em: análise de
requisitos, casos de uso, análise e design,
implementação e teste [1].
Os requisitos do sistema foram coletados e
analisados e os casos de uso foram especificados
com a ajuda dos profissionais da área.
Com os casos de uso documentados deu−se
início à análise e design do sistema, que foram
documentados utilizando os diagramas da UML
(Unified Modeling Language) [2].
O sistema foi dividido em módulos, sendo
que o design do sistema está seguindo o modelo de
componentes proposto pela Força Tarefa para o
Domínio de Saúde (Healthcare Domain Task Force
− HDTF) da OMG (Object Management Group) que
provê especificações e estrutura de dados de
componentes para o domínio médico utilizando o
padrão CORBA (Common Object Request Broker)
[3]. Os módulos são listados abaixo e para os que
seguem as especificações CORBA de serviços
para a área médica (3, 4, 6), a abreviatura do
serviço está indicada entre parênteses:
(1) Interface gráfica;
(2) Lógica específica do domínio (no caso UTI Neo−
Natal);
(3) Serviço de identificação do paciente (HTDF−
PIDS) [4];
(4) Serviço de acesso às observações clínicas e
laboratoriais (HTDF−COAS) [5];
(5) Serviço de acesso às imagens clínicas, que
especificamente constitui o acesso às imagens
ultrassonográficas;
(6) Serviço de segurança (CORBAsec) [6].
Com o objetivo de reduzir o tempo de
construção do sistema, aproveitando os benefícios
da padronização e construção de software
orientado a objetos, foi feita uma pesquisa de
implementações do padrão CORBA para os
serviços listados, visando a sua reutilização. Serão
testadas as implementações já existentes dos
serviços da HDTF, principalmente do projeto
OpenEMed [7]. A implementação do PIDS já foi
testada e será utilizada como serviço de
identificação de pacientes.
As interfaces gráficas, a lógica do domínio e
as interfaces entre os módulos estão sendo
implementadas utilizando a linguagem de
programação Java, sendo que os dados serão
armazenados no sistema gerenciador de banco de
dados (SGBD) relacional−objeto PostgreSQL [8]. A
comunicação das aplicações com o banco de
dados está sendo feita utilizando o mapeador
relacional−objeto ObjectBridge [9] que utiliza a
interface JDBC (Java DataBase Connectivity) [10]
para comunicar−se com o banco de dados e
realizar persistência dos objetos Java.
As doenças e causas de morte serão
codificadas segundo o Catálogo Internacional de
Doenças (CID−10) para armazenamento no
sistema.
As observações laboratoriais (exames
complementares) serão codificadas segundo a
base de dados LOINC (Logical Observation
Identifiers Names and Codes) que agrupa nomes e
códigos para identificação de observações clínicas
e laboratoriais [11].
Discussão e conclusões
O uso de padrões para a construção de
sistemas de informação da área de saúde ajuda a
reduzir os custos de aprendizado, implantação e
interoperação. O fato de utilizar implementações já
existentes para as especificações de serviços do
padrão CORBA propicia a construção de sistemas
em um tempo menor, permitindo que o foco esteja
voltado para a lógica e implementações específicas
do domínio onde se está trabalhando.
Para que isso seja possível, os componentes
devem ser implementados com baixo nível de
acoplamento, ou seja, os componentes devem
operar de maneira independente, possibilitando
também que eles sejam extensíveis, integrando
outros componentes específicos sem prejudicar o
funcionamento dos já existentes.
Apesar de todo o esforço na tentativa de
padronizar as interfaces do sistema e permitir a
interoperabilidade, a integração ou reutilização de
componentes não uma tarefa fácil. Nos testes com
a implementação PIDS do projeto OpenEMed
tivemos que alterar a configuração dos dados que
seriam armazenados no banco de dados para
ajustar à lógica do domínio da UTI neo−natal, que
possui dados específicos para a identificação do
paciente. Porém, este esforço é pequeno quando
comparado ao esforço de implementação,
comprovando que a padronização ajuda a reduzir o
tempo que seria gasto com o aprendizado de novas
estruturas de dados e terminologias.
Referências
[1] Jacobson, I., Booch, G., Rumbaugh, J. (1998),
The Unified Software Development Process,
Addison Wesley Longman.
[2] Rumbaugh, J., Jacobson, I., Booch, G. (1999),
The Unified Modelling Language, Addison
Wesley Longman.
[3]
Object
Management
Group
(OMG).
[http://www.omg.org/].
[4] Person Identification Service Specification, v.
1.1.
[http://www.omg.org/technology/documents/for
mal/person_identification_service.htm].
[5] Clinical Observations Access Service, v. 1.0.
[http://www.omg.org/technology/documents/for
mal/clinical_observation_access_service.htm].
[6]
Security
Service,
v.
1.8.
[http://www.omg.org/technology/documents/for
mal/security_service.htm]
[7] Kilman, D.G., Forslund, D.W. (1997), “An
International Collaboratory Based on Virtual
Records”, Commun. ACM, v. 40, n. 8, p. 111−
117.
[8] PostgreSQL − Object−Relational DataBase
Management
System.
[http://www.postgresql.org/].
[9] ObjectBridge − Object Relational Bridge Project.
[http://sourceforge.net/projects/objectbridge/].
[10] JDBC − Java DataBase Connectivity.
[http://java.sun.com/products/jdbc/].
[11] LOINC − Logical Observation Identifiers Names
and Codes. [http://www.regenstrief.org/loinc/].
Agradecimentos
Agradecemos à CAPES e CNPq pelo apoio
financeiro.
Contato
Adriano de Jesus Holanda
Estudante de Doutorado
Física Aplicada à Medicina e Biologia
Departamento de Física e Matemática
Faculdade de Filosofia, Ciências e Letras de
Ribeirão Preto − USP
Av. Bandeirantes, 3900
CEP: 14040−901 − Ribeirão Preto, SP
Fone: (16) 602−3774
Email: [email protected]