Aplicação de Padrões em um Sistema de Gerenciamento de Dados para uma UTI Neonatal Adriano J. Holanda 1, Luiz A. Bailão 2, Ivan T. Pisa 3, Evandro E. S. Ruiz 1 1 Grupo 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 3 Departamento de Informática em Saúde (DIS) Universidade Federal de São Paulo (UNIFESP) São Paulo-SP, Brasil Resumo Foi estudada a utilização de padrões na construção dos componentes e armazenamento de dados em um sistema de gerenciamento de dados para uma UTI Neonatal. Foi utilizado o padrão CORBA para a área da saúde (Healthcare Domain Task Force-HDTF) para a construção dos componentes e alguns sistemas de terminologias, dentre eles o CID10 e ICD9-CM, para a codificação do armazenamento de diagnósticos, causas de morte e procedimentos médicos. Além de possibilitar a utilização dos componentes separadamente devido ao baixo acoplamento destes, o sistema também demonstra alta interoperabilidade técnica, devido ao padrão de middleware CORBA, que possibilita a comunicação entre ambientes heterogêneos. A interoperabilidade semântica também é facilitada, com a troca de informações sendo feita utilizando CORBA-HDTF e sistemas de terminologias, reduzindo a ambigüidade dos termos compartilhados. Palavras chave: CORBA, Sistemas de Terminologia, Padrão, UTI Neonatal. Abstract It was studied the use of standards in the development of components and data storage for an ICU Neonatal data management system. It was used CORBA Healthcare Domain Task Force (HDTF) standard in the implementation of components and some terminological systems, like ICD10 and ICD9-CM, to standardize diagnostics, cause of death and medical procedures codification. Indeed to support the use of separated components due to low coupling, the system also demonstrates high technical interoperability, through the CORBA middleware standard, that supports the communication among heterogeneous environments. The semantic interoperability was improved with the possibility of exchange of information by the use of CORBA- HDTF and terminological systems, decreasing the ambiguity of shared terms. Key-words: CORBA, Terminological Systems, Standards, Neonatal ICU. Introdução Padronização dos componentes de software Os padrões de middleware existentes para a área da saúde tentam prover suporte sintático e semântico para a comunicação entre sistemas. O padrão CORBA-HDTF 1 (Healthcare Domain Task Force) para a área de saúde é baseado no paradigma de orientação a objeto, possuindo especificações de serviços 1 http://healthcare.omg.org (componentes) necessários em um ambiente de saúde. A padronização da sintaxe é obtida através da especificação das interfaces utilizando uma linguagem neutra de alto nível (IDL - Interface Definition Language), onde são definidos os atributos e operações a serem implementadas, e a partir da qual o mapeamento para outras linguagens de programação é realizado. A semântica referencial é obtida utilizando o serviço de identificação de pacientes [1] (PIDS - Person Identification Service) que permite a integração com outros sistemas de identificação formando o índice 1
mestre de pacientes. O serviço de acesso às observações clínicas [2] (COAS - Clinical Observation Access Service) utiliza o serviço de consulta léxica [3] (LQS - Lexicon Query Service) para fornecer acesso aos códigos, vocabulários e nomenclaturas médicos, e juntamente com a estrutura de dados especificada, tenta associar aos objetos e seus relacionamentos uma semântica conceitual. Sistema de terminologia A sintaxe e semântica da troca de informações médicas utilizando linguagem podem ser padronizadas utilizando um sistema de terminologia. Os sistemas de codificação ajudam a lidar com a enorme variabilidade das expressões e termos médicos, reduzindo a ambigüidade e relacionando os termos sinônimos. Frases como 'alto nível de açúcar' podem ser expressas de diversas formas utilizando sinônimos como 'hiperglicemia'. Com a utilização destes sistemas, estes conceitos podem ser representados por códigos que são independentes da linguagem natural. Porém, os sistemas de codificação existentes possuem diversas desvantagens, sendo a maioria delas relacionadas a falta de expressividade, especialmente os vocabulários uniaxiais como a versão 10 do Catálogo Internacional de Doenças (CID10) que enumera e agrupa todos os conceitos de interesse. Vocabulários como SNOMED (Systematized Nomenclature of Medicine) e MeSH (Medical Subject Headings) oferecem acesso multiaxial e permitem que o usuário utilize os códigos de várias categorias para representar conceitos complexos [4]. No entanto, devido à falta de representação explícita da semântica, os sistemas de codificação são inadequados para usos mais ambiciosos. Para este fim deve ser desenvolvido um sistema baseado em um modelo formal de conceitos médicos como o GALEN 2 (General Architecture for Languages Encyclopedia and Nomenclatures in Medicine) [5], para que seja possível gerenciar a semântica utilizando métodos computacionais [6]. Metodologia O objetivo deste trabalho foi estudar a aplicação de padrões para o registro e transporte dos dados e para a construção dos componentes de um sistema de gerenciamento de dados médicos, contendo imagens e atributos alfanuméricos. O sistema foi desenvolvido realizando a integração entre os pacotes mostrados na Figura 1. O pacote neucis implementa a interface gráfica e lógica do domínio de uma UTI Neonatal. Os pacotes pids, coas e lqs implementam as especificações PIDS, COAS e LQS, respectivamente. Todos os pacotes foram implementados usando a linguagem de programação Java. Eles podem ser utilizados de maneira separada, respeitando os relacionamentos de dependência. O usuário pode, por exemplo, utilizar a interface gráfica de identificação de pacientes, com os pacotes pids e tools, se acaso não desejar utilizar os sistema para armazenar as observações clínicas (COAS). Figura 1 - Diagrama de pacotes do sistema. O pacote tools fornece alguns frameworks necessários às implementações das especificações CORBA-HDTF. Os frameworks fornecem métodos para gerenciamento de banco de dados e serviços CORBA e algumas facilidades para manipulação de data e hora. Os frameworks devem ser configurados de acordo com o ambiente de implantação do sistema, o banco de dados e broker utilizados. Para o teste do acesso ao banco de dados 2 http://www.opengalen.org 2
foram utilizados os sistemas gerenciadores MySQL 3 e PostgreSQL 4. Para testar a comunicação com o middleware foram utilizados os brokers Orbacus 5 e OpenORB 6. Serviço de Identificação de Pacientes O pacote pids implementa as seguintes interfaces da especificação PIDS-HDTF (Figura 2): IdentificationComponent: ponto de acesso às interfaces descritas abaixo; IdentifyPerson: define funcionalidades para consulta de registros com valores especificados e seus respectivos pesos; CandidateIterator: iterador que agrupa o resultado de uma pesquisa, permitindo que parte do resultado fique armazenado no servidor, sendo entregue ao cliente quando requisitado; IdMgr: oferece funcionalidades para o gerenciamento de registros; ProfileAccess: fornece informações básicas sobre a identidade das pessoas; IdentityAccess: fornece acesso individual aos registros; Identity: encapsula um registro e seus atributos. utilizam uma referência a uma conexão JDBC 7 (Java DataBase Connectivity) para gerenciamento dos dados armazenados no banco. Serviço de Acesso às Observações Clínicas O pacote coas implementa as seguintes interfaces da especificação COAS-HDTF (Figura 3): AccessComponent: ponto de acesso às interfaces implementadas; QueryAccess: interface de consulta que retorna uma estrutura enviada do servidor para o cliente contendo as observações; BrowseComponent: interface de consulta que retorna uma referência ao objeto CORBA (ObservationRemote) que representa as observações no servidor; ObservationLoader: carrega as observações no servidor. Figura 3 Interfaces de acesso implementadas do padrão COAS. Figura 2 Interfaces de gerenciamento implementadas do padrão PIDS. As interfaces funcionais herdam os atributos e operações de IdentificationComponent, sendo que há referência para estas interfaces em IdentificationComponent. As implementações das interfaces funcionais As interfaces que representam as observações remotas (Figura 4) também foram implementadas: ObservationRemote: encapsula referência remota para as observações; AtomicObservationRemote: encapsula referência remota para observação com um único valor; CompositeObservationRemote: encapsula referência remota para observação composta. 3 http://www.mysql.com/ 4 http://www.postgresql.org/ 5 http://www.orbacus.com/ 6 http://openorb.sf.net/ 7 http://java.sun.com/products/jdbc/ 3
valores de obsevação. Para acessar as observações clínicas armazenadas no banco de dados as classes de acesso utilizam o mapeador objeto/relacional ObjectBridge 8 que utiliza a interface JDBC para comunicar-se com o banco de dados e realizar persistência dos objetos Java. Serviço de Consulta Léxica Figura 4 - Modelo de observações remotas acessadas por referência CORBA no cliente. Os valores das observações clínicas, que foram definidos como tipo ObservationValue (Figura 5), permitem armazenar os seguintes tipos de dados: Elementos codificados (CodedElement) permite armazenar códigos de algum sistema de codificação e que tenham representação única; Multimídia (Multimedia) - é o tipo de dados associado a elementos multimídia, tais como imagem, áudio, texto, vídeo, dentre outros; Faixa de valores (Measurement::Range) - tipo de dados que representa faixa de valores; Proporção (Measurement::Ratio) - tipo de dados que representa proporção; Numérico (Measurement::Numeric) - tipo de dados que representa observações numéricas como por exemplo resultados de exames laboratoriais; Texto (PlainText) - tipo de dados que representa as observações armazenadas como texto livre. Figura 5 Classes utilizadas para representar os O pacote lqs implementa a interface LexExplorer da especificação LQS-HDTF, que provê um subconjunto dos serviços de terminologia permitindo o mapeamento dos códigos armazenados para os conceitos. Os diagnósticos e causas de morte são representados armazenando os códigos do Catálogo Internacional de Doenças versão 10 (CID10) no serviço de consulta léxica. Para a representação dos procedimentos médicos está sendo utilizado uma tradução sistema ICD9-CM (International Classification of Diseases with Clinical Modifications). Interface Gráfica e Lógica do Domínio O pacote neucis encapsula os objetos que desenham a interface gráfica e representam a lógica do domínio de uma UTI Neonatal. Resultados O sistema mostrou-se compatível com os bancos de dados testados necessitando apenas algumas modificações nos arquivos de mapeamento do mapeador objeto-relacional, devido às diferenças dos tipos de dados entre os bancos. Não houve problemas de comunicação com os middlewares testados, necessitando apenas a troca de alguns parâmetros de configuração do framework gerenciamento de serviços CORBA para a troca do middleware. Na Figura 6 é mostrada a interface por onde são entrados os dados de identificação dos bebês que passaram pela UTI Neonatal. Através desta interface é possível adicionar, atualizar e excluir os perfis dos pacientes. Quando um novo perfil é adicionado, há a necessidade de se fazer a ligação 8 http://db.apache.org/ojb/ 4
do perfil do bebê com o de sua mãe, pois este ainda não possui nome. Por isso, um perfil pode ser procurado tendo como chave o registro da criança, o registro da mãe ou o nome da mãe. A Figura 8 mostra a interface de entrada das observações iniciais. As observações iniciais são realizadas no momento em que a criança entra na UTI neonatal, com os profissionais realizando algumas medidas e descrevendo algumas impressões iniciais. Quando o profissional seleciona o tipo de parto, por exemplo vaginal fórceps, o código equivalente ao tipo é armazenado no COAS, neste caso está sendo armazenado o código DNS:hl7.omg.org/I10/O81.0, onde DNS:hl7.omg.org/I10 é a representação do sistema de codificação CID10 e O81.0 é o código que representa o conceito Parto por fórceps baixo. Para saber qual o texto associado a cada código é necessário realizar uma consulta no LQS. Figura 6 Entrada de dados de identificação do paciente. A Figura 7 mostra a interface de gerenciamento das observações clínicas. Podem ser adicionadas as observações iniciais que o profissional fez do paciente, exames, imagens e texto livre descrevendo as impressões do profissional em um determinado instante. As observações podem ser carregadas de acordo com o perfil selecionado na interface de identificação ou pelo registro da criança na própria interface. Figura 8 Entrada das observações iniciais. A Figura 9 mostra a interface de consulta com o profissional avaliando as observações armazenadas. Figura 7 Gerenciamento das observações clínicas. 5
Figura 9 Visualização das observações requisitadas. Junto às observações, que podem ser simples ou compostas, estão sempre associados os horários de início e término da realização das observações e o código representando o tipo da observação, sendo que o significado de cada código pode ser obtido consultando o LQS. Discussão e conclusões A utilização do padrão CORBA para identificação do paciente (PIDS) permite que outros sistemas de domínios diferentes integrem seus registros com os armazenados pelo sistema implementado. A utilização do serviço de observações clínicas possibilita a padronização dos tipos e estrutura de dados das observações clínicas, bem como a interoperabilidade entre sistemas que possuem autorização de acesso e conheçam o padrão COAS. O serviço de consulta léxica LQS fornece especificação de interfaces e estrutura de dados para acesso aos sistemas de terminologia, oferecendo os benefícios da padronização de armazenamento de dados utilizando um sistema de terminologia, possibilitando a interoperabilidade semântica entre sistemas que possuam compatibilidade com os sistemas de terminologias utilizados. Um sistema A que deseja obter informações a respeito de um paciente pode requisitar ao COAS de um sistema B, as observações realizadas em um determinado período. Para saber quais sistemas de codificação foram utilizados, o sistema A pode consultar o LQS do sistema B. Se foram utilizados o CID10, ICD9-CM e o SNOMED, os códigos retornados serão DNS:hl7.omg.org/I10, DNS:hl7.omg.org/I9C e DNS:hl7.omg.org/SNM3, respectivamente. O sistema A pode consultar os códigos associados às observações recebidas junto ao LQS do sistema B para saber qual é o valor associado, recuperando a informação codificada. Agradecimentos Agradecemos à CAPES, CNPq e ao Departamento de Física e Matemática da FFCLRP- USP pelo apoio. Agradecemos também ao Departamento de Medicina Social da Faculdade de Medicina de Ribeirão Preto-USP pelo fornecimento da tradução do ICD9-CM. Referências [1] Object Management Group - OMG, Person Identification Service Specification (2001), v. 1.1. [http://www.omg.org/cgi-bin/doc?formal/2001-04- 04]. [2] Object Management Group - OMG, Clinical Observations Access Service (2001), v. 1.0. [http://www.omg.org/cgi-bin/doc?formal/2001-04- 06]. [3] Object Management Group - OMG, Lexicon Query Service (2000), v. 1.0. [http://www.omg.org/cgi-bin/doc?formal/2000-06- 31]. [4] Ingenerf, J., Reiner, J., Seik, B. (2001), Standardized terminological services enabling semantic interoperability between distributed and heterogeneous systems, International Journal of Medical Informatics, v. 64, n. 2-3, p. 223-240. [5] Rector, A.L., Solomon, W.D., Nowlan, W.A., Rush, T.W., Zanstra, P.E., Claansen, W.M.A. (1995), A terminology server for medical language and medical information systems, Methods of Information in Medicine, v. 34, n. 1-2, p. 147-157. [6] Rossi Mori, A., Consorti, F., Galeazzi, E. (1998), Standards to support development of terminological systems for healthcare telematics, Methods of Information in Medicine, v. 37, n. 4-5, p. 551-563. Contato Adriano de Jesus Holanda 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: aholanda@ffclrp.usp.br 6