Construção de Serviços Web para Apoiar a Troca de Informações de Exames Radiológicos entre Instituições de Saúde

Transcrição

1 Construção de Serviços Web para Apoiar a Troca de Informações de Exames Radiológicos entre Instituições de Saúde D.F. Pires 1, W. F. Pimentel 1 1 Departamento de Ciência da Computação Faculdades COC Ribeirão Preto Resumo Este artigo explora as tecnologias Serviços Web e XML, e a plataforma Java com o objetivo de apoiar a troca de informações de exames radiológicos entre instituições de saúde, em particular clínicas médicas, hospitais e laboratórios que trabalham com exames computadorizados. São definidos serviços básicos relacionados à requisição e consulta de exames radiológicos feitas por médicos em seus consultórios ou hospitais, e recebimento, laudo e entrega desses exames pelos radiologistas. Para isso, foram desenvolvidos programas computacionais Java que implementam esses serviços. Os programas são divididos em módulos: o módulo cliente, composto de uma versão para clínicas médicas e de uma outra versão para laboratórios, e também o módulo servidor. Palavras-chave: Serviços Web, XML, imagens médicas, exames radiológicos, interoperabilidade. Abstract - This article explores Web Services and XML technologies, and the Java platform with the objective to support information exchange of radiological exams between health institutions, particularly medical clinics and laboratories that carry through computerized exams. Basic services are defined and are related to the solicitation and consultation of radiological examinations made by doctors in its offices or hospitals, and act of receiving, finding and delivery of these same examinations for the radiologists. For this purpose, Java programs had been developed, divided in modules: client module, made up of a version for medical clinics and one another version for laboratories, and also the server module. Key-words: Web Services, XML, medical images. radiological exams, interoperability Introdução A realidade no dia-a-dia de clínicas médicas, hospitais, centros de saúde e clínicas radiológicas apresenta um cenário de necessidade na troca de informações entre essas instituições de saúde, como por exemplo, troca de pacientes entre hospitais e clínicas médicas diferentes, e de modo particular, a solicitação pelos médicos de exames radiológicos a clínicas radiológicas ou às quaisquer estabelecimentos que oferecem esse tipo de serviço. Evidente também é que essas informações são trocadas, na maioria das vezes, utilizando-se de papéis, acarretando o surgimento de vários problemas, como perda de informações, ilegibilidade, demora no preenchimento, desorganização, dentre outros como dificuldade na recuperação e acesso às informações. Nesse contexto, esforços devem existir no sentido de se alterar a situação atual para que a troca de informações entre as instituições de saúde ocorra de maneira eletrônica. Assim, é motivador a construção de sistemas computacionais, padrões e especificações que dêem suporte à troca digital de informações, facilitando assim, a agilidade no atendimento de pacientes, o acesso às informações e a legibilidade dos dados. Exames radiológicos de diversas modalidades de aquisição como tomografia computadorizada, ressonância magnética, radiografia computadorizada, ultrasom e medicina nuclear, são realizados diariamente por clínicas especializadas mediante solicitações de médicos que precisam destes para a decisão do diagnóstico mais preciso de um paciente e também para o acompanhamento da evolução deste diagnóstico. Ao receberem estas solicitações, radiologistas e físicos executam o exame radiológico, obtêm os resultados (possivelmente uma imagem digital) e posteriormente avaliam esses resultados. Finalmente, constroem um relatório em papel, chamado de laudo, com observações do resultado do exame, anexando muitas vezes a esse laudo, a própria imagem em formato de filme. Em seguida, o resultado do exame é devolvido ao médico solicitante que também analisa o resultado, fazendo suas conclusões. O cenário apresentado anteriormente pode e deve ser auxiliado por programas computacionais que auxiliam na troca de informações dos exames radiológicos entre médicos e físicos/radiologistas localizados em instituições de saúde diferentes e distante geograficamente. Ainda, casos esses profissionais estejam utilizando algum software já existente, existe uma grande chance desses

2 programas não conseguirem trocar informações entre si. Assim, é necessário utilizar na implementação desses programas computacionais soluções tecnológicas que sejam independente de linguagem de programação ou plataforma computacional. E uma dessas soluções é a especificação Serviços Web, explorada neste artigo. O objetivo deste trabalho é a construção de Serviços Web em Java que suportem a troca de informações de exames radiológicos entre instituições de saúde. São descritos documentos XML chamados de WSDL e apresentados programas computacionais que implementam os serviços definidos no documento WSDL. A seção seguinte apresenta a metodologia a partir do contexto descrito anteriormente. Em seguida, é apresentado e descrito o documento WSDL criado para a construção dos Serviços Web. Nas outras seções do artigo são mostradas, nesta ordem, a descrição dos programas computacionais que criam os serviços web e os programas (módulo cliente e módulo servidor) que se utilizam desses serviços, os resultados obtidos até o presente momento, e finalmente, algumas considerações a respeito de trabalhos futuros, trabalhos relacionados e conclusões finais. Metodologia Para o desenvolvimento dos Serviços Web e dos programas computacionais que suportam a troca de informações de exames radiológicos entre instituições de saúde, foram necessários o levantamento bibliográfico e o estudo de algumas tecnologias e especificações, como: Web Service, XML (Extensible MarkUp Language), WSDL (Web Services Definition Language), SOAP (Service Object Access Protocol) e a linguagem de programação Java. Elas são descritas muito brevemente a seguir: Web Services [1] são provavelmente a tecnologia mais interessante para trocar informações pela Internet. Esses serviços são disponibilizados de tal forma que permitem que diferentes aplicações desenvolvidas em linguagens de programação também diferentes, mesmo utilizando distintas tecnologias e plataformas computacionais, possam se conectar de maneira padrão, e executem procedimentos remotos sobre o protocolo HTTP (Hypertext Protocol). Normalmente, Web Services são implementados utilizando-se da tecnologia SOAP e documentos estruturados XML, como a linguagem WSDL. XML [2] é uma linguagem de marcação caracterizada por possuir um conjunto de regras para a construção de documentos formatados permitindo assim a representação dos dados. O usuário da linguagem XML pode construir seus próprios nomes de elementos (tags) e atributos. XML é ao mesmo tempo uma meta-linguagem, por possibilitar a definição de recursos para que se definam gramáticas com conjuntos de elementos, atributos e regras de composição utilizando-se de documentos DTD (Document Type Definition) ou XML Schema. WSDL [3] é uma linguagem XML utilizada para definir os serviços web disponíveis, e assim, fornece substancialmente três tipos de informações essenciais para o usuário programador da aplicação que utilizará os serviços: o que é especificamente o serviço sendo disponibilizado, onde encontrar esses serviços e como chamá-los. WSDL define os serviços como um conjunto de endpoints, isto é, os pontos de acesso pelas aplicações clientes na Internet. Embora XML seja uma linguagem feita para a troca de dados, ela sozinha não é suficiente para o intercâmbio de informações através da Intranet. É necessário ter um protocolo que possa auxiliar no envio e recebimento das mensagens contendo documentos XML. É neste contexto que o protocolo SOAP [4] para troca de informações em um ambiente distribuído torna-se fundamental e aplicável no desenvolvimento de serviços Web. SOAP tem o propósito de fazer chamadas a procedimentos remotos utilizando o protocolo HTTP (ou outro protocolo padronizado da Web), com a grande vantagem de não impor restrições de algum tipo de implementação para os pontos de acesso, como fazem atualmente RMI, CORBA e DCOM. A linguagem Java [5] vem sendo muito utilizada nos últimos anos, principalmente no desenvolvimento de aplicações para a Web, por ser orientada a objetos e por propiciar às aplicações portabilidade e independência de plataforma, esta última uma característica marcante da arquitetura Internet. Especificamente em relação ao suporte Java para desenvolvimento de web services, várias empresas vêm desenvolvendo um conjunto de APIs (Application Program Interface) Java para tal, entre elas a Sun Microsystems 1 e Apache 2. A seção seguinte apresenta o documento WSDL criado e necessário para a descrição dos serviços web relacionados à troca de informações de exames radiológicos entre instituições de saúde. O Documento WSDL A Figura 1 a seguir apresenta a parte inicial do documento WSDL construído neste trabalho. Nesta parte, são definidos o endereço na Internet onde é possível de se encontrar os serviços web ( o local do

3 arquivo (jws) que apresenta o próprio documento WSDL ( jws) e qual namespace foi utilizado para a implementação do protocolo SOAP. Neste caso, foi utilizado o namespace da APACHE ( xmlns:apachesoap= A Figura 2 a seguir apresenta uma outro parte do documento WSDL ilustrando a definição de um dos serviços criados, o serviço requisitaexame. Esse serviço utiliza-se de uma mensagem chamada requisitaexamerequest, apresentada na figura. Também é possível encontrar na Figura 2 as partes que compõem a mensagem requisitaexamerequest e a ordem dos parâmetros que se deve passar quando se faz uma chamada à essa mensagem. Na próxima seção são apresentados os programas desenvolvidos e que implementaram os serviços descritos no documento WSDL apresentado nesta seção. A Implementação dos Serviços Web Para a implementação dos Serviços Web definidos no documento WSDL apresentado na seção anterior, foram definidas duas aplicações divididas em: módulo do servidor e o módulo do cliente. O módulo do servidor basicamente possui dois arquivos Java. O primeiro arquivo contém uma classe interface onde são definidos os 7 métodos ou serviços disponíveis, apresentando os tipos retornados, e número e tipo dos parâmetros que esses métodos recebem. Como <?xml version="1.0" encoding="utf-8"?> - <wsdl:definitions targetnamespace= xmlns=" xmlns:apachesoap=" xmlns:impl=" xmlns:intf=" xmlns:soapenc=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:xsd=" - <wsdl:types> - <schema targetnamespace= xmlns=" <import namespace=" /> - <complextype name="arrayofarrayof_xsd_anytype"> - <complexcontent> - <restriction base="soapenc:array"> <attribute ref="soapenc:arraytype" wsdl:arraytype="xsd:anytype[][]" /> </restriction> </complexcontent> </complextype> </schema> </wsdl:types> Figura 1 Parte inicial do documento WSDL que apresenta endereço dos Serviços Web e qual namespace SOAP utilizado <wsdl:message name="requisitaexamerequest"> <wsdl:part name="paciente" type="xsd:string" /> <wsdl:part name="convenio" type="xsd:string" /> <wsdl:part name="cod_pac" type="xsd:string" /> <wsdl:part name="medico" type="xsd:string" /> <wsdl:part name="crm" type="xsd:string" /> <wsdl:part name="clinica" type="xsd:string" /> <wsdl:part name="data_cons" type="xsd:string" /> <wsdl:part name="nro_consu" type="xsd:string" /> <wsdl:part name="exame" type="xsd:string" /> <wsdl:part name="cod_exam" type="xsd:string" /> <wsdl:part name="qtde" type="xsd:string" /> <wsdl:part name="nro_ch" type="xsd:string" /> <wsdl:part name="cid_10" type="xsd:string" /> <wsdl:part name="justificativa" type="xsd:string" /> <wsdl:part name="temp_problema" type="xsd:string" /> <wsdl:part name="urgencia" type="xsd:string" /> </wsdl:message>... <wsdl:porttype name="labserviceimpl"> - <wsdl:operation name="requisitaexame" parameterorder="paciente convenio cod_pac medico crm clinica data_cons nro_consu exame cod_exam qtde nro_ch cid_10 justificativa temp_problema urgencia"> <wsdl:input message="impl:requisitaexamerequest" name="requisitaexamerequest" /> <wsdl:output message="impl:requisitaexameresponse" name="requisitaexameresponse" /> </wsdl:operation> <wsdl:binding name="labserviceimplsoapbinding" type="impl:labserviceimpl"> <wsdlsoap:binding style="rpc" transport=" /> - <wsdl:operation name="requisitaexame"> <wsdlsoap:operation soapaction="" /> - <wsdl:input name="requisitaexamerequest"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded" /> </wsdl:input> Figura 2 Parte do documento WSDL que define o serviço requisitaexame

4 exemplo, foi definido o método requisitaexame, que recebe 16 variáveis do tipo String como parâmetro (paciente, convenio,,cod_pac, medico, crm, clinica, data_cons, nro_consu, exame, cod_exam, qtde, nro_ch, cid_10, justificativa, temp_problema, urgência). Esses parâmetros estão de acordo com o documento WSDL apresentado nas Figuras 1 e 2. O segundo arquivo é uma classe Java que implementa a interface do primeiro arquivo, isto é, implementa os 7 métodos definidos na interface. Esses métodos serão chamados nos programas do módulo cliente. O módulo cliente é composto de duas versões: a versão da clínica médica onde o médico faz solicitações e consultas de exames, e a versão do laboratório onde o radiologista ou físico verifica a presença de novas solicitações de exames, faz o laudo dos mesmos, associa um arquivo digital que representa a imagem do exame e devolve o resultado para o médico através do programa. A Figura 3 apresenta uma tela onde um médico pode requisitar um novo exame através do módulo cliente com versão para uma clínica médica. Essa requisição fica armazenada no banco de dados local do médico. A Figura 4 apresenta uma tela onde o radiologista pode consultar novas requisições de exames e que ainda não foram realizadas. Já a Figura 5 ilustra a situação onde o radiologista faz o laudo de um exame novo e anexa ao laudo o arquivo digital relacionado à imagem do exame. Ao final, o exame é devolvido ao médico através do programa. A Figura 6 apresenta uma tela onde o médico pode utilizar a versão da clínica médica para consultar se algum exame pendente está pronto. Com o exame realizado, o médico pode utilizar o sistema para consultar os resultados do exame, como ilustra a Figura 7. A próxima seção apresenta algumas discussões a respeito da implementação dos módulos cliente e servidor, e propõe trabalhos futuros. Figura 3 Tela para solicitação de um exame Discussão e Conclusões Com os serviços localizados e disponibilizados no módulo servidor, qualquer aplicação independente de linguagem de programação ou plataforma computacional pode implementar esses serviços conforme necessário, como fizeram as aplicações no módulo cliente. Como apresentado, este trabalho procurou abordar apenas as atividades consideradas básicas no tocante à troca de informações radiológicas entre instituições de saúde. Atividades relacionadas ao tratamento de imagens foram desconsideradas por fugir do escopo deste trabalho. Ainda, processos relacionados às empresas conveniadas para solicitação de exames serão definidas e implementadas em trabalhos futuros. Figura 4 Tela de consulta de novas requisições de exames

5 Figura 5 Tela para o radiologista fazer o laudo Figura 6 Tela para verificar se algum exame solicitado está pronto Utilização do padrão em saúde DICOM (Digital Imaging and Communications for Medicine) como formato das imagens digitais sendo transferidas pela Internet. Vários trabalhos vêm desenvolvendo aplicações com suporte a DICOM, a exemplo de [6] e [7]. Estudar a possibilidade de se alterar as aplicações do módulo cliente, tornandoas componentes de software, de modo que as mesmas possam ser utilizadas como um plug-in em softwares já existentes, como em um prontuário eletrônico de pacientes (PEP) e softwares laboratoriais e hospitalares. Verificar a possibilidade de desenvolver um módulo para as empresas conveniadas. E adicionar serviços relacionados no módulo servidor. Assim, um médico faz a solicitação do exame à conveniada, que por sua vez pode verificar em qual clínica laboratorial deve ser feito o exame ou ainda se aquele exame já foi feito anteriormente e representa um custo adicional para a conveniada. Procurar parceiros como laboratórios de exames computadorizados, clínicas médicas e conveniadas, que estejam dispostos a realizar testes e cooperar no aperfeiçoamento deste trabalho. Assim, será possível realizar testes que se aproximem ao máximo da realidade. Por fim, serão avaliados os resultados esperados e obtidos com trabalhos relacionados na literatura. Figura 7 Tela para consultar o laudo do radiologista A implementação das aplicações que compõem os módulos foi realizada utilizando-se do software APACHE 3 que suporta o desenvolvimento de Serviços Web, como o servidor AXIS, embora outros softwares poderiam ter sido utilizados, como o JWSDP (Java Web Service Development Pack) 1.3 da Sun Microsystems 4. O sistema gerenciador de banco de dados utilizado foi o MySQL 5. É importante salientar que todos esses softwares são gratuitos e de domínio público. Tendo concluído a implementação das dos módulos cliente (clínica médica e laboratório) e também do servidor, as próximas etapas deste trabalho serão: Agradecimentos Ao médico especialista Dr. Ricardo Halah, da SH Clínicas, de Ribeirão Preto, por ter nos auxiliado no esclarecimento de informações relevantes ao processo de pedido e envio de exames radiológicos entre laboratórios e clínicas médicas. Referências [1] David Booth. Web Services Architecture Working Group, W3C. Web Services Architeture [ ] Apr [2] Liam Quin. Extensible MarkUp Language. [ Nov [3] Roberto Chinnici. Web Services Description Language (WSDL). Version 2.0 Part 1: Core Language. [ Jun

6 [4] Nilo Mitra. SOAP Version 1.2 Part 0: Primer. [ Jun [5] James Gosling. Java Technology. [ Jun [6] Santos, M., Ruiz, E.E.S. Desenvolvimento de Aplicações DICOM com o Uso de Tecnologias Web: Um Servidor e Cliente DICOM. VIII Congresso Brasileiro de Informática em Saúde [7] Pisa, I.T. (2003), Midster: Uma Arquitetura de Compartilhamento de Imagens Médicas Baseada em Modelos Peer-to-Peer (P2P) e Serviços Web, Tese de Doutrado, Programa de Física Aplicada a Medicina e Biologia. Universidade de São Paulo (USP), Ribeirão Preto. Contato Laboratório de Sistemas de Computação (LSC) - Faculdades COC. Rua Abraão Issa Halack. dfpires@coc.com.br