Construção de Serviços Web para Apoiar a Troca de Informações

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. Pires1, W. F. Pimentel1
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
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 Microsystems1 e Apache2.
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 (http://200.210.60.62), o local do
1
2
http://java.sun.com
http://apache.org
arquivo (jws) que apresenta o próprio documento
WSDL
(http://200.210.60.62/axis/weblen/LabServiceImpl.
jws) e qual namespace foi utilizado para a
implementação do protocolo SOAP. Neste caso,
foi utilizado o namespace da APACHE (
xmlns:apachesoap=http://xml.apache.org/xmlsoap)
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=http://200.210.60.62:81/axis/weblen/LabServiceImpl.jws
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://200.210.60.62:81/axis/weblen/LabServiceImpl.jws"
xmlns:intf="http://200.210.60.62:81/axis/weblen/LabServiceImpl.jws"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
- <wsdl:types>
- <schema targetNamespace=http://200.210.60.62:81/axis/weblen/LabServiceImpl.jws
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
- <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="http://schemas.xmlsoap.org/soap/http" />
- <wsdl:operation name="requisitaExame">
<wsdlsoap:operation soapAction="" />
- <wsdl:input name="requisitaExameRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://DefaultNamespace"
use="encoded" />
</wsdl:input>
…
Figura 2 – Parte do documento WSDL que define o serviço requisitaExame
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
•
•
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.
Agradecimentos
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
3
do
software APACHE
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
4
Microsystems . O sistema gerenciador de banco
5
de dados utilizado foi o MySQL . É 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:
3
http://ws.apache.org
http://java.sun.com
5
http://www.mysql.com
4
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” [ http://www.w3.org/TR/ws-arch/ ]
Apr. 2004
[2] Liam Quin. “Extensible MarkUp Language”. [
http://www.w3c.org/XML]. Nov. 2002
[3] Roberto Chinnici. “Web Services Description
Language (WSDL). Version 2.0 Part 1: Core
Language”. [http://www.w3.org/TR/2004/WDwsdl20-20040326/]. Jun. 2004.
[4] Nilo Mitra. “SOAP Version 1.2 Part 0: Primer”.
[http://www.w3.org/TR/soap12-part0/].
Jun.
2004.
[5]
James
Gosling.
“Java
Technology”.
[http://java.sun.com]. Jun. 2004.
[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. 2002.
[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. E-mail: [email protected]