forma formula então -assim um

UNIVERSIDADE ESTADUAL DO CEARÁ
INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIAS E
TECNOLOGIA DO CEARÁ
CONVÊNIO COM A UNIVERSIDADE FEDERAL DO RIO DE
JANEIRO
SÉRGIO RICARDO PEREIRA SOARES
RACIOCÍNIO BASEADO EM CASOS PARA RADIOLOGIA
RIO DE JANEIRO – RJ
2011
SÉRGIO RICARDO PEREIRA SOARES
RACIOCÍNIO BASEADO EM CASOS PARA RADIOLOGIA
Dissertação apresentada ao Curso de Mestrado
Profissional em Computação Aplicada da
Universidade Estadual do Ceará, como requisito
parcial para a obtenção do grau de Mestrado em
Computação
Orientador: Dr. Flávio Luiz de Mello
RIO DE JANEIRO – RJ
2011
ii
M5676p
Soares, Sergio Ricardo Pereira
Raciocínio baseado em casos para radiologia.
— Rio de Janeiro, 2011.
65 p. : il.
Orientador: Dr. Flávio Luiz de Mello.
Dissertação (Mestrado em Computação
Aplicada) – Universidade Estadual do Ceará,
Ciências Tecnológicas, Instituto Federal de
Educação Ciências e Tecnologia do Ceará, Próreitoria de Ensino / Pós-Graduação. Universidade
Federal do Rio de Janeiro, Escola Politécnica.
1. Tecnologia da Informação. 2. Raciocínio
Baseado em Casos. 3. Sistema de Informação
Hospitalar. I. Universidade Estadual do Ceará,
Ciências Tecnológicas. II. Instituto Federal de
Educação Ciências e Tecnologia do Ceará, Próreitoria de Ensino / Pós-Graduação. III.
Universidade Federal do Rio de Janeiro, Escola
Politécnica.
CDD: 004.11
iii
SÉRGIO RICARDO PEREIRA SOARES
RACIOCÍNIO BASEADO EM CASOS PARA RADIOLOGIA
Dissertação apresentada ao Curso de Mestrado
Profissional em Computação Aplicada da
Universidade Estadual do Ceará, como requisito
parcial para a obtenção do grau de Mestrado em
Computação
Defesa em: 04/08/2011
BANCA EXAMINADORA
________________________________________________
Flávio Luiz de Mello, DSc (UFRJ)
Presidente (Orientador)
________________________________________________
Antônio Alberto Fernandes de Oliveira, DSC (UFRJ)
Membro Externo
________________________________________________
Airton Fontenele Sampaio Xavier, DSC (UFC)
Membro Interno
iv
Este trabalho é dedicado aos meus pais que sempre me apoiaram e me
incentivaram ao longo da minha vida e a minha esposa que sempre esteve ao meu
lado nas horas mais difíceis.
v
AGRADECIMENTOS
Agradeço a Deus por me dar forças e perseverança para concluir este curso.
vi
RESUMO
Nos últimos 30 anos a nossa capacidade de gerar e armazenar dados cresceu
exponencialmente, obrigando o desenvolvimento de várias técnicas de computação. Em
um primeiro momento estas técnicas estavam voltadas para a área empresarial, mas hoje
os hospitais e clínicas estão na mesma situação devido ao avanço da tecnologia deste
setor nas ultimas décadas.
Serão expostas as técnicas de mineração de dados desenvolvidas para a área
empresarial que estão sendo aplicadas com algumas modificações na área médica.
Inicialmente foi introduzida uma parte teórica e posteriormente exemplos de uma série
de aplicações na área médica. Estas técnicas podem ser resumidas em três grandes
aplicações, que são: programas de tomada de decisão, mineração de dados clínicos e
raciocínio baseado em casos armazenados.
Foram mostradas as razões do pouco desenvolvimento para a área de TI neste
setor, não esquecendo as vantagens que um investimento maior irá trazer para os
pacientes, médicos e para o próprio hospital ou clínica.
vii
ABSTRACT
In the last 30 years our capacity of generate and store data grew almost to
infinity and forced the development of new techniques in the computer science field. In
a first moment, these techniques were applied to the business field, but today hospitals
and clinics have the same problems because of the fast development in this field in the
last decades.
In this text, data mining techniques used in the business field that are applied,
with little modifications, in the healthcare sector, will be exposed. At the beginning, this
study will introduce the theoretical part followed by some examples and studies in
healthcare. These techniques can be summarized in three major applications that are:
decision maker software, data mining in clinical data and case based reasoning.
Also, this study demonstrates the reasons why the healthcare sector don’t have
much development when compared to the business field, and it tries to show the
advantages of the use of this techniques to the doctors, patients and hospitals.
viii
LISTA DE FIGURAS
Figura 2.1 – Setores de um hospital
...................................
Figura 2.2 – Tipo de dados em um hospital ou clínica
....................
07
09
Figura 2.3 – Sistemas de TI existentes em um hospital . . . . . . . . . . . . . . . . . . . .
10
Figura 2.4 – Protocolo DICOM e o padrão OSI . . . . . . . . . . . . . . . . . . . . . . . . .
12
Figura 2.5 – Protocolo HL7 e um exemplo de algumas mensagens
13
..........
Figura 2.6 – Setores e protocolos usados para troca de informações . . . . . . . . . .
14
Figura 2.7 – Sistemas normalmente usados para fornecer dados clínicos . . . . . .
15
Figura 2.8 – Setores e protocolos usados para troca de informações . . . . . . . . . .
17
Figura 2.9 – Fluxograma do tratamento de um paciente usando os SI
Hospitalares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Figura 2.10 – Exemplo de prontuário eletrônico
.........................
21
Figura 2.1.1 – Ciclo de funcionamento de um CBR . . . . . . . . . . . . . . . . . . . . . .
24
Figura 2.1.2 – Ciclo de funcionamento de um CBR complexo
..............
25
Figura 2.2.1 – Casos selecionados de um CBR para defeitos em carros . . . . . . .
29
Figura 2.2.2 – Novo caso com um problema sem solução
.................
30
................................
31
Figura 2.2.3 – Valores de similaridade
Figura 2.2.4 – Valores de similaridade para cada atributo
..................
32
.....................
40
Figura 3.2 – Diagrama do SI completo
................................
42
Figura 3.3 – Diagrama do SI separado
.................................
44
Figura 3.1.1 – Diagrama do SI para recolher casos . . . . . . . . . . . . . . . . . . . . . . .
45
Figura 3.1.2 – Tela Inicial após o login do cliente Turyon
.................
46
....................
47
..............................
48
Figura 3.1 – RIS com a estação de laudo especialista
Figura 3.1.3 – Tela mostrando o paciente selecionado
Figura 3.1.4 – Tela do laudo estruturado
ix
LISTA DE SIGLAS E ABREVIATURAS
CBR - Case Based Reasoning
DICOM - Digital Image COmmunication in Medicine
DM - Data Mining
DW - Data Warehouse
EDIS - Emergency Department Information System
HIS - Hospital Information System
HL7 - Health Level 7
IP – Internet Protocol
KDD - Knowledge Discovery in Database
KS - Knowledge Structures
LIS - Laboratory Information System
NEMA - National Electrical Manufacturers Association
OSI - Open System Interconnection
PACS - Picture Archiving and Communication System
RIS - Radiological Information System
RM - Ressonância Magnética
ROI - Region Of Interest
SQL - Structured Query Language
x
TI - Tecnologia da Informação
xi
Sumário
1
Introdução
1.1 - Tema
1
...........................................
1.2 - Delimitação
......................................
1
1.3 - Justificativa
......................................
2
........................................
3
1.4 - Objetivos
1.4.1 - Objetivo Geral
..................................
1.4.2 - Objetivos específicos
1.5 - Metodologia
2
..............................
.....................................
Fundamentação Teórica
2.1 - Case Based Reasoning
..............................
2.3 - Exemplos de uso de CBRs
3
4
21
...............
27
...........................
36
Proposta de solução
39
3.1 - Módulo para recolher casos no formato DICOM
4
3
6
2.2 - Técnicas de implementação de um CBR
3
1
..........
45
3.2 - Módulo de recuperação de casos . . . . . . . . . . . . . . . . . . . . . .
48
Conclusão
56
Referências
57
Referências Consultadas
63
Referências da Web
64
xii
1 - Introdução
1.1 – Tema
Este trabalho aborda as técnicas de raciocínio baseado em casos (CBR [27])
aplicados ao processo de tomada de decisão de médicos que trabalham no setor de
radiologia de um hospital ou clínica.
1.2 – Delimitação
O foco deste trabalho é mostrar as diferentes técnicas que estão sendo
aplicadas no setor de saúde para diminuir ou evitar erros médicos, bem como, o
sofrimento dos pacientes. Para melhor elucidarmos as diferenças entre os setores de
TI de um hospital e de uma empresa, colocamos alguns pontos relevantes que
caracterizam as dificuldades específicas do setor hospitalar. Resaltando o fator de
investimento e as suas diferentes prioridades. Foram citados exemplos de uso e foi
exposta a teoria pertinente de forma a compreender as diferenças entre este setor e
os demais existentes. Algumas técnicas apresentadas dependem do uso de
matemática e de técnicas de inteligência artificial que estão fora do escopo deste
trabalho, e portanto não foram definidas na sua totalidade. O resultado final é um
software que permite que os médicos radiologistas armazenem diagnósticos de
forma estruturada e inteligente sob o ponto de vista computacional.
1
1.3 – Justificativa
A capacidade da medicina de gerar e coletar dados nos últimos anos sofreu
um aumento incrível. Diversos fatores contribuíram para isto tais como o uso de
códigos de barra em larga escala e a informatização de escritórios, empresas e
órgãos públicos. Os sistemas de coleta e digitalização de dados e comunicações
também contribuíram de forma significativa. Hoje, por exemplo, temos sensores
coletando dados de forma remota e automática gerando uma quantidade enorme de
informação transmitida via satélite diretamente a computadores que vão processar e
gerar algum conhecimento útil. Não podemos esquecer também a popularização da
internet que cresce a cada dia, gerando diversos dados de usuários e transações feitas
online pelo mundo inteiro.
Esta quantidade enorme de informação fez surgir à necessidade de técnicas
novas de processamento de dados de forma a retirar automaticamente informações
úteis e produzir algum conhecimento. A habilidade do ser humano para analisar e
entender grandes conjuntos de dados está distante da sua habilidade de acumular e
armazenar esses dados. A partir desta diferença, surgiu a necessidade de criar
técnicas que ficaram conhecidas como Mineração de Dados (Data Mining) [19] e
popularmente são chamadas de KDD (Knowledge Discovery in Databases) [19] que
para o português pode ser traduzido como descoberta de conhecimento em banco de
dados
Na área médica em particular são gerados muitos dados sobre pacientes,
hospitais, doenças e técnicas de tratamento, isto gera uma necessidade cada vez
maior do uso de técnicas de data mining [19]. Analogamente na área de radiologia,
a quantidade de imagens também é cada vez maior e o médico necessita consultar
casos anteriores bem como publicações da área de forma a conseguir gerar um laudo
sobre a doença. No início o setor gerava apenas algumas imagens de raios-X. Hoje o
exame de apenas um paciente de ressonância magnética de mama gera 2000
imagens, por exemplo.
2
Várias técnicas estão sendo desenvolvidas de forma a melhorar a
manipulação dos dados nesta área. No início dos anos 70 foram usadas técnicas de
inteligência artificial (IA) para gerar conhecimento através de dados estatísticos
sobre doenças. Nos anos 80 estes esforços evoluíram para técnicas de CBR [27]
(Case Based Reasoning) ou traduzido como Conhecimento Baseado em Casos. Este
método consiste em armazenar casos anteriores para gerar padrões de tratamento e
diagnóstico de doenças para tentar acertar o diagnostico da doença atual de um
paciente. As técnicas de CBR [27] usadas procuram trabalhar da mesma forma que
um médico experiente. Usando o conhecimento adquirido em casos anteriores
procura-se diagnosticar o caso atual.
1.4 – Objetivos
1.4.1 - Objetivo Geral:
Construir um sistema de informação (SI) que forneça uma busca
retrospectiva de informação em um repositório de casos radiológicos que ajude o
médico radiologista na sua rotina de trabalho. Este sistema será integrado ao sistema
de imagens já existente na clínica ou hospital e fornecerá detalhes de casos
anteriores ao médico que vai usá-lo
1.4.2 - Objetivos Específicos:
1) Criar a estrutura de armazenamento dos casos que suporte o protocolo
DICOM [2] (Digital Imaging Communications in Medicine) adotado no setor de
radiologia. Este sistema é mais conhecido como PACS [1] e facilitará a entrada de
3
casos no repositório pois os dados não precisarão ser transformados para serem
armazenados;
2) Criar um sistema de entrada de laudos estruturados, que junto com as
imagens correspondentes, possam ser armazenados no PACS [1] para posterior
consulta;
3) Definir um sistema de busca no repositório que use palavras-chave
fornecidas pelo médico e que retorne dados relevantes em forma de hiperlinks a
serem consultados. Cada hiperlink mostrará o laudo e as imagens correspondentes
ao caso em questão;
1.5 – Metodologia
O modelo atual do SI foi concebido após dialogar com diversos médicos
radiologistas sobre a hipotética construção de um banco de casos radiológicos.
Inicialmente o SI seria composto apenas dos laudos gerados por médicos e
armazenados apenas no formato texto. Contudo, todos eles foram muito categóricos
em afirmar que sem as imagens, o laudo armazenado teria muito pouco valor para
ajudá-los em futuros casos. Neste sentido, o conceito do SI sofreu uma mudança
significativa em sua concepção original, pois o mesmo deveria dar suporte ao
armazenamento de imagens também. Deste modo optou-se por uma solução de
código aberto, que por trabalhar com o protocolo DICOM [2], permite o
armazenamento do laudo na sua plenitude, isto é , textos e imagens. Neste caso o
desafio passou a ser, a busca e conversão dos dados em DICOM [2], para um
formato mais fácil de fazer a recuperação dos casos usando palavras-chave. A
solução foi um conjunto de ferramentas que compõe o programa DICOM [2] usado.
4
Elas fazem a busca por parâmetros primários primeiro e depois converte os laudos
encontrados para XML[3], para que mais detalhes possam ser encontrados.
Para que o SI pudesse ser integrado em um sistema hospitalar, ou mesmo em
alguma clínica, foi estudada a arquitetura dos sistemas usados nestes setores. Além
disto os protocolos DICOM [2] e HL7 [4] foram estudados de forma parcial apenas
para expor o funcionamento deles.
5
2 – Fundamentação Teórica
Para entender o processo de coleta de dados empregado no sistema de
informações
dedicado
à
médicos
radiologistas,
deve-se
compreender
o
funcionamento de um hospital ou clinica, bem como quais os setores e como os
sistemas se comunicam entre si. Na figura 2.1 são apresentados os setores mais
comuns de um hospital. O foco de estudo deste trabalho concentra-se na área de
radiologia, mas vários outros setores fornecem informações que ajudam o médico
quanto está gerando o laudo radiológico.
6
Figura 2.1 – Setores de um hospital
7
Os diversos setores de um hospital produzem uma quantidade abundante de
dados, o que sugere a necessidade de classificá-los de modo a definir sua
disponibilidade no ambiente de TI hospitalar:
a) Dados Administrativos – Existentes em qualquer grande empresa e já
bastante conhecidos em outros setores industriais e de serviços.
b) Dados Financeiros – Possuem as mesmas características dos dados
administrativos e já são bem conhecidos em ambientes empresariais.
c) Dados Clínicos - Estes dados são particulares do setor médico e pouco
estudados até o momento. Podem ser formados por informações de diversos
setores diferentes em um hospital, e ainda, podem estar concentrados em um
sistema de informação conhecido como prontuário eletrônico.
Para detalhes sobre os dados administrativos e financeiros e como mapeá-los
consultar o artigo “O Mapeamento de um processo administrativo do Departamento
financeiro na controladoria de uma empresa do segmento veterinário” [5].
No ambiente hospitalar estes três tipos de dados necessitam trocar
informações entre si, como mostra a figura 2.2. Como exemplo desta troca, pode-se
citar o caso de um paciente que faz um exame de tomografia ou ressonância
magnética e necessita de contraste. Na maioria dos exames não é necessário o uso
de contraste, portanto esta informação deve ser gerada após gerar algumas imagens
do paciente e a análise do médico radiologista. Quando o contraste é necessário o
setor administrativo e o financeiro tem que receber esta informação para que o
estoque seja reposto e para que o valor seja cobrado do paciente ou plano de saúde.
8
Figura 2.2 – Tipo de dados em um hospital ou clinica
Para que estes sistemas possam trocar informações de forma padronizada,
foram definidos protocolos específicos para este setor.
Na figura 2.3 pode-se visualizar como os setores foram segmentados. As
siglas dos sistemas mais comuns, são enumeradas a seguir :
EDIS – Emergency Department Information System. Traduzido para SI do
departamento de emergência
LIS – Laboratory Information System. Traduzido para SI do Laboratório do
hospital.
9
RIS – Radiological Information System. Traduzido para SI da Radiologia
HIS – Hospital Information System. Traduzido para SI Hospitalares
Figura 2.3 – Sistemas de TI existentes nos hospitais
10
Para que estes sistemas possam trocar informações de forma padronizada,
foram adotados como padrão de mercado pela NEMA e outras instituições
organizadoras, dois protocolos principais de comunicação, resumidos a seguir:
a) DICOM – Que significa Digital Image COmmunication in Medicine
pode ser entendido através da compreensão do padrão OSI [6] para comunicação
em redes de computadores ilustrado na figura 2.4. O DICOM [2] se apoia no
protocolo TCP/IP [7] que é muito usado na comunicação de computadores
ligados na internet. Ele é um protocolo orientado a conexão e necessita de um
endereço IP para identificação de cada maquina ligada na rede. Um pacote é
criado com o endereço de destino e apenas o computador que está identificado
com este endereço processa o pacote. O protocolo DICOM [2] foi adotado como
padrão na área de imagem radiológica e é amplamente usado pelos fabricantes
de aparelhos de diagnóstico por imagem. Ele possui um mecanismo de
segurança o qual os computadores só podem se comunicar caso os mesmos
tenham sido previamente configurados nos dois computadores e identificados
por tags chamadas AE_Tile, bem como suas respectivas portas de comunicação
utilizadas para prover o serviço. Caso um destes elementos não possua a
configuração correta, a comunicação é desfeita.
Pode-se visualizar como este protocolo é estruturado na figura 2.4
11
Figura 2.4 – Protocolo DICOM e o padrão OSI
b) HL7 – Health Level 7 - pode ser definido usando o padrão OSI [6]
para comunicação em redes de computadores na figura 2.5. Este protocolo
possui um conjunto de mensagens padronizadas para troca de informações e
também usa o protocolo TCP/IP [7].
12
Pode-se visualizar como este protocolo é estruturado na figura 2.5
Figura 2.5 – Protocolo HL7 e um exemplo de algumas mensagens
13
Uma vez entendidos os protocolos de comunicação, pode-se alterar a figura
2.3, adicionando uma referência aos protocolos utilizados por cada setor hospitalar,
tal como ilustrado na figura 2.6.
Note que os setores que necessitam de imagens usam sempre o protocolo
DICOM [2].
Figura 2.6 – Setores e protocolos usados para troca de informações
14
Com os setores de TI hospitalares bem definidos pode-se verificar quais são
os mais importantes para gerar os dados clínicos que os médicos necessitam para
fazer o laudo final do paciente. Na figura 2.7 a seguir, verifica-se que o HIS e por
muitas vezes o setor de LIS, são os principais sistemas usados para fornecer as
informações. Em casos que o paciente chega na emergência pode ser que o setor
EDIS, se existir, também será usado.
Figura 2.7 – Sistemas normalmente usados para fornecer dados clínicos
15
Neste momento já é possível ter uma visão macro dos sistemas hospitalares,
reconhecer quais os sistemas contribuem com dados clínicos, e por este motivo
pode-se concentrar no setor que é o mais importante para o sistema final que está
sendo criado. Como este trabalho é focado no setor de radiologia é necessário
verificar as particularidades do sistema RIS [13]. Note que também necessitamos do
apoio dos sistemas HIS e algumas vezes do LIS para que o laudo possa ser gerado,
pois eles fornecem dados clínicos importantes. Isto fica ilustrado na figura 2.8 e
pormenorizado a seguir.
16
Figura 2.8 – Setores e protocolos usados para troca de informações
17
O SI RIS (Radiological Information System) depende de informações vindas
do PACS [1] e da estação de laudo que está diretamente conectada a ele. Este
sistema suporta as seguintes funções básicas:
a) Registro do Paciente e marcação de exames
b) Controle de documentos do paciente, como pedido médico e exames
anteriores.
c) Scanner integrado para digitalizar documentos dos pacientes
d) Controle de laudos de exames
e) Laudo e assinaturas eletrônicas
f) Envio do laudo por fax ou e-mail para o médico solicitante ou
paciente
O PACS [1] (Picture Archiving and Communication System) é responsável
por guardar e gerenciar as imagens das modalidades digitais. Muitas vezes ele
possui digitalizadores (scanners) de filmes para que modalidades não digitais
possam usar os seus serviços. As funções básicas são diminuir a impressão de filmes
e disponibilizar as imagens remotamente para médicos ou pacientes (PACS web).
As modalidades digitais são formadas pelos aparelhos que geram a imagem
do paciente e disponíveis principalmente nos aparelhos listados a seguir:
a) Raios-X digitais
b) Tomografia computadorizada
c) Ressonâncias magnéticas
d) Mamógrafos digitais
e) Medicina nuclear
Por último tem-se o HIS (Hospital Information System) que controla a parte
administrativa e financeira das clínicas e hospitais e costuma integrar o CIS
(Clinical Information System) que implementa o prontuário eletrônico do paciente
entre outras funções. Em alguns casos o CIS é separado do HIS para que as
informações clínicas e o estado atual dos pacientes sejam monitorados mais
facilmente.Isto ocorre por que passa a existir um sistema dedicado somente a estas
informações.
18
Adicionalmente, é necessário verificar como estes sistemas funcionam
quando um paciente chega no hospital para fazer um exame. No fluxograma da
figura 2.9 pode-se ter uma ideia de como os diversos sistemas participam a cada
momento.
19
Figura 2.9 – Fluxograma do tratamento de um paciente usando os SI
Hospitalares
20
O Prontuário eletrônico [28] organiza todas as informações pertinentes ao
paciente e pode ser definido pela figura 2.10 a seguir.
Figura 2.10 – Exemplo de prontuário eletrônico
2.1 - Case Based Reasoning
Com os sistemas de TI hospitalares definidos, procura-se definir a teoria do
raciocínio baseado em casos que define o SI que é o objetivo deste trabalho.
Fazendo uma analogia ao ser humano que está sempre aprendendo com a
suas experiências, seja através da observação de outras pessoas, seja avaliando seus
próprios erros. Este aprendizado permite que ele consiga resolver problemas novos
baseando-se em suas experiências anteriores ou em situações parecidas que ele já
tenha vivenciado. O conceito de CBR [27] (Case Based Reasoning) procura ampliar
21
esta habilidade do ser humano catalogando casos ocorridos anteriormente,
permitindo que o usuário consulte esta base de dados para tentar solucionar o
problema atual que está enfrentando. Ele tem a mesma função da pessoa experiente
que é consultada quando se tem alguma dúvida, e pode ser empregado em diversas
áreas para ajudar pessoas a adquirem conhecimento ou permitir que resolvam
problemas mais facilmente.
Neste trabalho, CBR [27] é abordado como ferramenta de apoio para a área
diagnóstico médico. O usuário fornece ao programa os detalhes da situação atual do
paciente e ele consulta casos semelhantes de sucesso armazenados anteriormente no
sistema. Baseado nestes casos, o médico consegue decidir mais facilmente o que
fazer.
O CBR [27] da mesma forma que o ser humano, depende muito da
quantidade e da qualidade dos casos de sucesso armazenados previamente no
repositório. A implementação de sistemas deste tipo, e do seu sucesso, vai depender
também da forma como for projetado o sistema de busca e a comparação dos casos
no banco de dados formado pelos casos de sucesso. Caso o sistema mostre muitos
casos não irá produzir um ganho significativo por que o médico terá que olhar
diversas situações e provavelmente ficará confuso. Se ele mostrar poucos,
provavelmente não irá ajudar em nada.
O CBR [27] pode ser usado de diferentes formas e pode ser particular para
cada setor da área médica, tornando mais fácil a busca e comparação dos casos.
O ciclo de funcionamento de um CBR [27] como descrito por Aamodt &
Plaza[20] é mostrado na figura 2.1.1, e envolve um ciclo de quatro processos para
atualização contínua de casos e o aumento de conhecimento:
a) Recuperação: Com as características inseridas para o novo problema, o
processo procura na base de dados os casos que mais se parecem com a
descrição
apresentada. Nesta etapa do processo
é muito importante
disponibilizar ferramentas de refino da busca, para diminuir o número de casos
22
se ele for muito grande ou para mostrar os casos com apenas algumas
características do problema atual (similares).
b) Reutilização: As informações do caso recuperado servem para resolver o
problema descrito. É feita, então, a reutilização da solução do caso recuperado e
a solução é testada. Se ela servir parcialmente, os dados do caso recuperado são
carregados no novo caso, e o próximo processo (revisão) faz as modificações
necessárias e armazena o caso no processo final de retenção. Se o caso for
idêntico, o ciclo termina neste processo.
c) Revisão: Este processo ocorre quando o caso recuperado difere um pouco
do caso atual ou não existem casos similares anteriores. Se for similar, as
diferenças são avaliadas e o caso é adaptado para a nova situação. Se não for
similar, é necessário encontrar uma solução para que ele seja armazenado, ou um
novo processo de reutilização pode ser feito com outras características para
verificar se algum caso similar aparece.
d) Retenção: Este processo armazena os casos novos que foram
solucionados no repositório de casos para ser usado em futuras consultas. O
sistema irá decidir qual informação armazenar e de que forma, para facilitar a
consulta posterior.
23
Figura 2.1.1 – Ciclo de funcionamento de um CBR
Fonte: Aamodt & Plaza[20]
Em resumo, o processo de CBR [27] consiste em verificar se existe um caso
idêntico ao descrito pelo usuário, caso contrário ele faz pequenas modificações e
adapta o caso mais próximo para a realidade do atual. Se esta adaptação resolver o
problema, ele armazena a solução como um caso novo e aumenta a experiência do
sistema.
O ciclo mostrado na figura 2.1.1 é uma forma exemplificada do processo, o
uso de índices com valores definidos para a sua importância ajuda a classificação e
24
permite um melhor funcionamento na recuperação e retenção de casos. Isto será
definido no parágrafo a seguir, quando forem definidos os passos de implementação
de um CBR [27].
Todavia, em sistemas complexos, o modelo apresentado no parágrafo
anterior é muito simples e não produz bons resultados por que normalmente falha na
recuperação e retenção de casos. Para que este sistema consiga um bom desempenho
e alto grau de assertividade, é necessário introduzir o conceito de estruturas de
conhecimento
(KS
–
Knowledge
Structures)
aos
processos
explanados
anteriormente. Estas estruturas fazem uso de índices e regras pré-definidas para
poder melhor classificar e comparar os casos. A figura 2.1.2 mostra o mesmo ciclo
visto anteriormente, mas com a implementação destas novas funcionalidades.
Figura 2.1.2 – Ciclo de funcionamento de um CBR complexo
25
Seguindo o diagrama da figura 2.1.2, esta nova metodologia pode ser
descrita pelos processos a seguir:
a) Atribuição de índices: Neste processo são atribuídos índices para as
características informadas do caso de modo a permitir uma posterior comparação
no banco de casos solucionados.
b) Recuperação: Este processo funciona quase da mesma forma que no
modelo antigo, só que agora ele recorre aos índices adicionados ao caso e
compara com índices no banco de casos solucionados. Além disso, ele compara
também com as regras de similaridades pré-estabelecidas ou aprendidas pelo
conhecimento prévio de outros casos. Isto facilita a recuperação de casos mais
parecidos com o atual.
c) Reutilização: Da mesma forma que a etapa anterior a diferença para este
modelo é apenas a utilização de regras de reutilização pré-estabelecidas ou
geradas com a interação do usuário.
d) Teste da solução : Neste ponto a solução recuperada é testada para
verificar se resolve o problema e o algoritmo pode seguir dois caminhos
diferentes:
d1) A solução resolve o problema: Nesta situação, o algoritmo
se comporta quase como no modelo anterior. A única diferença é que são
atribuídos novos índices para indicar que este caso soluciona o caso em
questão
d2) A solução não resolve o problema: Nesta situação, são
descritas as diferenças entre o caso atual e o recuperado. São geradas
novas regras de similaridade, que modificam as regras de indexação, para
que no próximo caso a chance de erro na recuperação seja minimizada. É
feito então um processo de revisão da solução do caso de acordo com as
regras pré-estabelecidas ou com a interação do usuário e o caso revisado
26
é testado novamente. Se a solução não resolver o problema, torna-se
necessário a revisão do caso outra vez.
e) Retenção: Este processo armazena os casos novos que foram
solucionados no repositório de casos para ser usado em futuras consultas. O sistema
irá armazenar todos os dados do caso e todos os índices e regras que foram criados
nas etapas anteriores, para facilitar a recuperação em casos novos.
Neste novo conceito, as estruturas de conhecimento (KS) armazenam
experiências de casos anteriores e ajudam o sistema a convergir para um melhor
resultado. Os índices e regras são pré-estabelecidos no projeto do CBR [27], mas em
certos casos a interação do usuário pode ajudar a criar ou modificar estas regras.
Esta interação é armazenada, também, através dos índices e o novo conhecimento é
armazenado para uso futuro. Com este sistema o CBR [27] consegue aprender e
acertar a solução dos casos mais vezes.
A implementação de um sistema de índices utiliza recursos de inteligência
artificial e não faz parte do escopo deste trabalho, portanto não será descrita.
2.2 – Técnicas de implementação de um CBR
Existem quatro técnicas principais para implementar um CBR [27] citadas
por I Watson [16]:
a) CBR usando a técnica de Nearest neighbour
A técnica de Nearest neighbour, ou vizinho mais próximo, é uma das mais
usadas para implementar um CBR [27]. Ela funciona determinando valores para os
atributos de cada caso armazenado anteriormente (base de conhecimento
acumulado), de acordo com a similaridade com o caso atual que queremos resolver.
A cada novo caso os valores são recalculados para definir valores de similaridades
novos relacionados com o caso atual.
27
Esta técnica pode ser definida pela fórmula a seguir:
Onde:
T - Caso que queremos resolver
S – Caso armazenado para o qual o valor está sendo calculado
n – Número de atributos do caso
i – Índice que determina qual atributo do caso está sendo calculado
W – Valor que determina a importância deste atributo (peso)
De forma a ilustrar esta técnica pode-se definir um exemplo simples de
aplicação da formula definida. O CBR usado para o exemplo foi feito para
diagnosticar problemas em carros e dois casos foram recolhidos para serem
comparados com um problema novo. Os casos estão definidos na figura 2.2.1.
28
Figura 2.2.1 – Casos selecionados de um CBR para defeitos em carros
29
Baseado na estrutura dos casos selecionados é definido um novo problema,
na figura 2.2.2, para ser comparado e verificar como a formula definida ajuda a
calcular a similaridade entre o problema e os casos.
Figura 2.2.2 – Novo caso com um problema sem solução
Para que a formula seja usada corretamente, o peso da similaridade deve ser
definido para cada atributo do problema junto com o grau de importância. Estes
valores são definidos quando um novo caso deve ser comparado com os casos
previamente armazenados.
Para definir e poder calcular a similaridade usamos um número real entre
zero e um, sendo 0 nenhuma similaridade e 1 muito similar. Nos exemplos da figura
2.2.3é verificado o funcionamento deste processo.
30
Figura 2.2.3 – Valores de similaridade
Os valores de similaridade devem ser calculados para cada atributo do caso.
Após isto são definidos os valores para a importância de cada atributo. Pode-se ter
uma ideia de como isto é feito usando os casos já definidos. Na figura 2.2.4 cada
caso é comparado com o problema (caso novo) e os valores de similaridade para
cada atributo são calculados seguindo o padrão definido anteriormente na figura
2.2.3.
31
Figura 2.2.4 – Valores de similaridade para cada atributo
De forma a verificar qual caso é mais similar ao problema proposto, deve-se
atribuir valores de importância para cada atributo do problema e o valor final será
calculado usando a formula já definida. Pode-se definir que o atributo mais
32
importante tenha um valor igual a dez e que o menos importante tenha o valor igual
a um.
Analisando o caso pode-se definir que os atributos importantes para
comparação são:
a) Problema
b) Voltagem da bateria
c) Estado das lâmpadas
Estes atributos terão peso igual a dez e os demais atributos terão peso igual a
um. Com estes valores definidos pode-se calcular o valor de similaridade para cada
caso em relação ao problema proposto, tal como indicado pela equação 2.1.
Caso 1
Similaridade =
((10*0,8)+(1*0,6)+(1*0,6)+(10*0,9)+(10*1))/(10+1+1+10+10)
= 28,2/32 = 0,88
Caso 2
Similaridade =
((10*0,8)+(1*0)+(0,4*1)+(10*0,95)+(10*0))/(10+1+1+10+10)
= 17,9/32 = 0,56
Pelos valores calculados verifica-se que o caso 1 é mais similar ao problema
que o caso 2. Verificando os atributos nota-se que o fato da lâmpada estar quebrada
diminuiu o valor final da similaridade do caso 2.
33
b) CBR usando a técnica de Indução
Os algoritmos de indução funcionam através da identificação de padrões
entre os casos armazenados (base de conhecimento acumulado), separando-os em
grupos (clusters) de acordo com os padrões identificados. Cada cluster agrupa os
casos que contém a mesma característica, ou ainda, uma característica muito
semelhante.
Para uso desta técnica no CBR [27], necessitamos que pelo menos uma
característica do caso a ser resolvido seja fornecida, para que a indução possa ser
feita nos casos armazenados.
O algoritmo mais usado para indução é o ID3 [17] que monta árvores de
decisão de acordo com o histórico dos casos armazenados.
c) CBR usando a lógica Fuzzy
A lógica fuzzy facilita a implementação de um CBR [27] por que implementa
o processamento simbólico. Podemos usar termos como excelente, bom, ruim e
fraco para classificar um atributo. Não existe a limitação da lógica comum que
implementa apenas o falso ou verdadeiro. Esta característica ajuda na recuperação
de casos por que podemos achar soluções próximas do caso atual pesquisando
situações similares. O excelente seria a solução perfeita para o caso, mas o bom,
pode fornecer informações que ajudem a resolvê-lo também.
A lógica fuzzy facilita a entrada de dados para o caso a ser armazenado, por
que podemos usar termos que facilitam o especialista a descrever a solução.
Podemos classificar pacientes pela idade usando termos como bebê, criança,
adolescente, adulto, meia idade e idoso. Para cada termo definimos uma faixa etária,
o adolescente poderia ser definido como entre 14 e 20 anos. Com estas definições a
pesquisa posterior seria facilitada. Podemos achar doenças de acordo com estes
termos definidos. Se ela for um ataque cardíaco é muito difícil de acontecer antes da
meia idade, então o sistema mostraria apenas os casos referentes ao pacientes de
meia idade e de idosos.
34
Outro uso da lógica fuzzy ocorre quando temos que comparar atributos de
escalas numéricas diferentes. Quando aplicamos o processamento simbólico este
problema desaparece pois o especialista pode definir se aquele valor é grande,
médio ou pequeno sem se preocupar com as diferenças de escala.
d) CBR usando a tecnologia de banco de dados
A forma mais simples de implementar um CBR [27] consiste em usar a
própria tecnologia dos bancos de dados, a linguagem SQL [10]. A grande limitação
desta técnica é conseguir descrever as características do caso a ser resolvido no
formato SQL [10] para que seja possível procurar soluções nos casos armazenados.
Esta técnica dificulta o uso do conceito de similaridade para procurar os casos, por
que normalmente consultas SQL [10] procuram exatamente os dados fornecidos
com poucas variações. Portanto esta técnica é bem limitada e deve ser empregada
apenas em sistemas em que o CBR [27] não necessite de recursos avançados de
recuperação de casos.
Para auxiliar a implementação de um CBR [27] é possível utilizar
frameworks que consistem de um conjunto de classes criadas em uma linguagem
específica que ajuda o desenvolvimento de software. Como exemplo de programa
para implementar um CBR [27], existe o jCOLIBRI [18] que oferece várias classes
específicas para o desenvolvimento de aplicações deste tipo. Ele é open source [14]
e a comunidade está sempre acrescentando novas funções, tornando-o importante no
setor de inteligência artificial voltada para CBR [27]. Ele tem o seu funcionamento
orientado a objeto, tornando fácil a construção de novas aplicações.
35
2.3 – Exemplos de uso de CBRs
A seguir, listaremos alguns exemplos de sistemas já em funcionamento em
hospitais e clínicas no mundo:
a) Suporte a diagnóstico
Problemas Cardíacos (CASEY) [26]
Problemas Pulmonares (MEDIC) [26]
Síndromes Dismórficas (GS.52) [26]
Funções do Fígado (ICONS) [26]
Ultrassonografia (FM Ultranet) [26]
Histopatologia (IDEM) [26]
Resultado de biópsia de mama (BI-RADS) [26]
b) Suporte Terapêutico
Diabético dependente de insulina
Hipotireoidismo
Síndrome coronariana aguda
Tratamento de Asma – ADEMA
Suporte para tratamento com antibióticos
Monitoramento de transplantes: Rim e medula óssea
36
c) Estratificação de risco
Síndrome coronariana aguda
Recorrência de câncer colorretal (CARES)
d) Treinamento Médico
e) Planejamento do Tratamento do paciente
Enfermaria (FLORENCE)
e) Melhora dos programas de saúde
Uma central de ajuda que previna problemas de saúde ocupacionais
f) Recomendação de programas de dieta e confecção de cardápios
particulares para cada doença
Os Sistemas de CBR [27] permitem a utilização do conhecimento
especialista no apoio a decisões de diagnóstico, devido à compatibilidade natural
desses sistemas com os repositórios de dados disponíveis nos hospitais e clínicas.
Eles permitem a extração, organização e reutilização do conhecimento armazenado
como ferramenta de apoio para diagnóstico de novos casos.
A utilização deste sistema fica limitado apenas ao acesso às bases de dados
completas, corretas e confiáveis que contenham entre as informações armazenadas,
a descrição completa de casos e das soluções que foram aplicadas em algum
37
momento. Neste aspecto, o médico especialista deve ter a preocupação de descrever
corretamente os casos de sucesso.
38
3 – Proposta de Solução
Para construir este sistema de apoio a decisão foi necessário dividir o
problema em duas partes. A primeira é construir o repositório que aceite as imagens
no formato DICOM [2] e que possa gerar prontuários que serão armazenados no
mesmo paciente. O sistema pode receber os prontuários já prontos em formato
DICOM [2] ou pode gerar e armazenar no paciente que está sendo analisado.
A segunda parte é o mecanismo de busca que fará a recuperação dos casos já
armazenados de acordo com palavras-chave fornecidas pelo médico que está
consultando o sistema.
Utilizando a figura 2.8, que mostra uma visão detalhada do setor de RIS
[13], pode-se definir o local que o sistema de apoio a decisão será conectado
conforme mostrado na figura 3.1.
39
Figura 3.1 – RIS com a estação de laudo especialista
40
O sistema de informações resultante deste trabalho receberá casos completos
para serem armazenados. Quando o sistema atingir uma massa de dados
significativa, será feita uma pesquisa com os médicos do setor de radiologia para
verificar o que pode ser melhorado e se o sistema de informações gerado foi útil.
Os casos serão armazenados por médicos radiologistas através do envio das
imagens e do laudo estruturado para um servidor DICOM [2]. O laudo estruturado
irá possuir campos para o cadastro de palavras-chave que ajudem a recuperação
posterior quando for necessária a consulta.
O servidor DICOM [2] será formado por programas com o código aberto no
padrão GPL [14] e será de livre uso depois de pronto. O sistema final seguirá o
padrão do diagrama da figura 3.2, explicado em mais detalhes a seguir.
41
Figura 3.2 – Diagrama do SI completo
42
O servidor PACS [1] dedicado usará um computador com sistema
operacional Linux [12] e o software gerenciador de banco de dados MySQL [11]
como sistema gerenciador de banco de dados.
O conjunto de utilitários (Framework) DCM4CHEE [8] usa o Java [9] como
linguagem de programação e fornece os serviços compatíveis com o protocolo
DICOM [2] usado na área médica. O uso deste protocolo foi necessário para facilitar
a entrada de dados no servidor sem nenhuma conversão das imagens. Elas serão
fornecidas pelas modalidades ou através de outro servidor PACS [1] disponível no
local.
Desta forma, o software final pode ser separado em duas partes definidas a seguir:
a) Servidor PACS [1] dedicado (DCM4CHEE [8]) que armazena as imagens
e os laudos no formato DICOM [2] e pelo software Turyon DCM4CHEE Lite
Viewer [21] e que oferece a opção de visualização das imagens e confecção do
laudo no formato DICOM [2], conhecido como laudo estruturado ou Structured
Report – SR [15]. Pode-se definir esta parte como o módulo que recolhe os casos
completos, no formato DICOM [2], para formar o repositório.
b) Conjunto de ferramentas disponíveis no pacote DCM4CHE [8] que
oferecem suporte a recuperação de casos usando palavras-chave. Estas ferramentas
também convertem casos DICOM [2] recuperados em XML [3], facilitando uma
busca avançada Pode-se ainda recuperar os casos usando comandos SQL [10] para
acessar diretamente o banco de dados do framework DCM4CHEE [8]. Como última
opção, sugere-se usar uma ferramenta desenvolvida para o DCM4CHEE [8] que
acessa o banco de dados usando o suporte do framework. Cada opção tem suas
dificuldades e serão detalhadas no capítulo 3.2. Pode-se definir esta parte como o
módulo de recuperação de casos
Na figura 3.3 podem ser verificadas as duas partes do sistema de
informações.A área hachurada, define a fronteira da primeira parte da arquitetura do
sistema responsável pela coleta e persistência dos dados.
43
Figura 3.3– Diagrama do SI separado
44
Com as duas partes do software definidas pode-se detalhar como cada uma
funciona, mostrando exemplos do módulos já integrados.
3.1 -Módulo para recolher casos no formato DICOM
O cliente PACS [1] dedicado será usado pelo médico radiologista para entrar
com a anotação semântica sobre os casos, bem como inserir as palavras-chave que
serão usadas pelo programa de busca posteriormente em uma consulta. Ele é
baseado em outro software de código aberto chamado Turyon DCM4CHEE Lite
Viewer [21] que permite visualizar as imagens e criar um laudo estruturado.
Na figura 3.1.1 são definidos os módulos do software Turyon [21] , para
facilitar o entendimento do seu funcionamento. Em um computador servidor com o
PACS [1] DCM4CHee [8] instalado, o software Turyon instala um servidor para
que o cliente possa ser acessado de qualquer lugar da internet.Pode-se usar ainda
uma conexão VPN se um roteador que forneça este serviço for usado. Isto fornecerá
maior segurança na conexão e troca de dados.
Figura 3.1.1 – Diagrama do SI para recolher casos
O médico conecta o cliente no servidor usando um login e uma senha que
esteja cadastrado no servidor Turyon. Ele pode ter acesso a alguns exames
destinados ao seu login ou a todos, dependendo do que foi configurado em seu perfil
de usuário . Após a conexão o médico vai obter a tela da figura 3.1.2.
Ainda nesta figura, ressalta-se a configuração do protocolo DICOM [2] para
o PACS dedicado, na parte de baixo da tela através dos campos AE, IP e Port.
45
Figura 3.1.2 – Tela inicial após o login do cliente Turyon
Depois de selecionar o paciente desejado o médico pode visualizar as
imagens disponíveis e gerar o laudo usando o botão reporting. Isto pode ser
visualizado na figura 3.1.3.
46
Figura 3.1.3 – Tela mostrando o paciente selecionado
Quando o médico seleciona o botão reporting, outra tela é aberta
possibilitando que ele faça o laudo, que depois será gravado no formato Structured
Report (SR) [15] definido no padrão do protocolo DICOM [2] junto com as imagens
do paciente. Isto permite uma fácil recuperação do caso pela segunda parte do
programa. Na figura 3.1.4 podemos ter uma ideia dos campos que o médico vai ter
disponível para fornecer informações sobre o paciente. Quando o botão send é
selecionado o laudo é armazenado no PACS [1] dedicado.
47
Figura 3.1.4 – Tela do laudo estruturado
3.2 -Módulo de recuperação de casos
O módulo de recuperação deve começar verificando a estrutura do banco de
dados do DCM4CHEE [8], que está disponível no link [26], para saber quais
campos devem ser pesquisados durante a busca. A estrutura não foi definida aqui
por ser muito complexa e contêm diversos campos que não usaremos.
Após verificar a estrutura do banco de dados e as ferramentas disponíveis no
framework, 3 métodos distintos para busca foram definidos e detalhados a seguir:
a) A recuperação pode ser feita acessando diretamente o banco de dados do
DCM4CHEE [8] usando o comando SQL Full-Text Search (FTS) [20] na coluna
que armazena os dados do laudo estruturado. Após a recuperação os dados serão
transformados em uma página através da linguagem XML[3]. Este método é
48
arriscado, pois se o comando em SQL [10] for feito de forma errada pode alterar o
banco de dados e danifica-lo. Além disto ele não está obedecendo ao padrão
DICOM [2], o que pode dificultar qualquer outra operação como por exemplo a
visualização das imagens.
b) A recuperação pode ser feita usando-se a ferramenta JPDBI [22]
disponível no framework DCM4CHEE[8]. Ela acessa o banco de dados SQL [10],
mas não de forma direta, o que pode evitar qualquer dano aos casos já armazenados.
Usando-se a opção o extended query pode-se buscar palavras-chave no campo que
armazena o laudo estruturado e a ferramenta retorna os pacientes encontrados. Com
a lista de pacientes podemos usar outro comando disponível no framework dcm2xml
[23] para gerar as páginas que serão consultadas pelos médicos. Nos links gerados
será utilizado o protocolo WADO [25] para visualizar as imagens do caso
selecionado.
c) A recuperação pode ser feita usando-se a parte da anatomia do corpo que o
médico solicitou, através do comando dcmqr [24] disponível no framework e depois
converter os casos recuperados para XLM [21] através do comando dcm2xml [23].
Neste formato pode-se fazer a busca das palavras-chave no laudo e eliminar os casos
que não possuam as características desejadas. Os links gerados pelo XML[3] após a
seleção vão usar o protocolo WADO[25] para visualizar as imagens do caso
selecionado.
Sob esta ótica, optou-se pelo terceiro método de recuperação de dados por
que ele faz todas as operações sem usar comandos que acessem diretamente o banco
de dados do framework DCM4CHEE[8]. Isto diminui o risco de corromper as
informações armazenadas.
Este método porém apresenta um problema, ele depende do correto
preenchimento dos dados quando o exame é realizado. Em testes feitos com exames
fornecidos por diferentes clínicas, ficou evidente que um padrão de preenchimento
dos campos não é seguido, dificultando a recuperação de casos. Como exemplo
prático foi feita uma busca em campo do formato DICOM [2] “Study description”
para exames de crânio e o resultado da consulta não mostrou todos os exames de
crânio disponíveis no repositório. Isto aconteceu por que em alguns exames o campo
49
Study description estava preenchido com “Angio cranio” e não apenas como crânio.
Isto demonstra claramente que existe um problema de semântica particular a cada
clínica ou hospital que dificulta a recuperação dos casos e para isto ser resolvido,
um padrão de preenchimento dos exames deve ser adotado.
De forma a tentar contornar este problema usou-se outro campo DICOM [2]
“Body part examined” e foi feita a consulta com a palavra “HEAD”, o resultado foi
nulo. Verificou-se que em todos os exames disponíveis no repositório, este campo
não estava preenchido. Este fato mostrou novamente, que não existe padrão de
preenchimento correto quando o exame é realizado.
Para ilustrar o que aconteceu durante os testes, uma parte do resultado das
consultas usando o comando dcmqr [24] é mostrado a seguir. Note que o nome dos
campos foram substituídos por números que são definidos pelo padrão DICOM [2]
como tags. A conversão foi feita acessando uma listagem disponível no site Dicom
Tags [29]
a) Consulta apenas com a palavra CRANIO no campo Study Description
(0008,1030)
root@led:~/dcm4che/bin# ./dcmqr [email protected]:11112
-q 00081030=CRANIO
Resultado do comando
23:41:02,002 INFO - Association(1) initiated
Socket[addr=/192.168.0.103,port=11112,localport=38270]
23:41:02,047 INFO - DCM4CHEE(1): A-ASSOCIATE-RQ DCM4CHEE <<
DCMQR
23:41:02,110 INFO - DCM4CHEE(1): A-ASSOCIATE-AC DCMQR >>
DCM4CHEE
23:41:02,113 INFO - Connected to [email protected]:11112 in 0.224 s
23:41:02,244 INFO - Send Query Request using 1.2.840.10008.5.1.4.1.2.2.1/Study
Root Query/Retrieve Information Model - FIND:
(0008,0020) DA #0 [] Study Date
(0008,0030) TM #0 [] Study Time
(0008,0050) SH #0 [] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,1030) LO #6 [CRANIO] Study Description
(0020,000D) UI #0 [] Study Instance UID
(0020,0010) SH #0 [] Study ID
(0020,1206) IS #0 [] Number of Study Related Series
(0020,1208) IS #0 [] Number of Study Related Instances
23:41:02,253 INFO - DCM4CHEE(1) << 1:C-FIND-RQ[pcid=1, prior=0
50
cuid=1.2.840.10008.5.1.4.1.2.2.1/Study Root Query/Retrieve Information Model FIND
ts=1.2.840.10008.1.2/Implicit VR Little Endian]
23:41:02,512 INFO - DCM4CHEE(1) >> 1:C-FIND-RSP[pcid=1, status=0H]
23:41:02,513 INFO - Received 0 matching entries in 0.401 s
23:41:02,513 INFO - DCM4CHEE(1) << A-RELEASE-RQ
23:41:02,593 INFO - DCM4CHEE(1) >> A-RELEASE-RP
23:41:02,593 INFO - DCM4CHEE(1): close
Socket[addr=/192.168.0.103,port=11112,localport=38270]
23:41:02,594 INFO - Released connection to [email protected]:11112
Note que o resultado da consulta foi nulo, por que não existe nenhum
exame com este campo preenchido apenas como CRANIO.
b) Consulta com a palavra CRANIO^ROTINA no campo Study Description
(0008,1030). A palavra foi definida depois de consultar os exames e
verificar os valores usados pelo usuário para este tipo de exame.
root@led:~/dcm4che/bin# ./dcmqr [email protected]:11112
-q 00081030=CRANIO^ROTINA
Resultado do comando
22:33:40,853 INFO - Association(1) initiated
Socket[addr=/192.168.0.103,port=11112,localport=55494]
22:33:40,863 INFO - DCM4CHEE(1): A-ASSOCIATE-RQ DCM4CHEE <<
DCMQR
22:33:40,873 INFO - DCM4CHEE(1): A-ASSOCIATE-AC DCMQR >>
DCM4CHEE
22:33:40,875 INFO - Connected to [email protected]:11112 in 0.103 s
22:33:40,977 INFO - Send Query Request using 1.2.840.10008.5.1.4.1.2.2.1/Study
Root Query/Retrieve Information Model - FIND:
(0008,0020) DA #0 [] Study Date
(0008,0030) TM #0 [] Study Time
(0008,0050) SH #0 [] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,1030) LO #14 [CRANIO^ROTINA] Study Description
(0010,0010) PN #0 [] Patient's Name
(0020,000D) UI #0 [] Study Instance UID
(0020,0010) SH #0 [] Study ID
(0020,1206) IS #0 [] Number of Study Related Series
(0020,1208) IS #0 [] Number of Study Related Instances
22:33:41,026 INFO - Query Response #1:
(0008,0005) CS #10 [ISO_IR 100] Specific Character Set
(0008,0020) DA #8 [20100707] Study Date
(0008,0030) TM #14 [200852.125000] Study Time
(0008,0050) SH #10 [0162117001] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,0054) AE #8 [DCM4CHEE] Retrieve AE Title
(0008,0056) CS #6 [ONLINE] Instance Availability
(0008,1030) LO #14 [CRANIO^ROTINA] Study Description
(0010,0010) PN #26 [JONH DOE] Patient's Name
51
(0020,000D) UI #48 [1.2.840.55555.1997879323.20100707195449409.10885] Study
Instance UID
(0008,0005) CS #10 [ISO_IR 100] Specific Character Set
(0008,0020) DA #8 [20100708] Study Date
(0008,0030) TM #14 [133007.984000] Study Time
(0008,0050) SH #10 [0162173301] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,0054) AE #8 [DCM4CHEE] Retrieve AE Title
(0008,0056) CS #6 [ONLINE] Instance Availability
(0008,1030) LO #14 [CRANIO^ROTINA] Study Description
(0010,0010) PN #30 [JONH DOE] Patient's Name
(0020,000D) UI #48 [1.2.840.55555.1997879323.20100708131953315.11231] Study
Instance UID
(0020,0010) SH #6 [10905] Study ID
(0020,1206) IS #2 [5] Number of Study Related Series
(0020,1208) IS #4 [110] Number of Study Related Instances
(0088,0130) SH #0 [] Storage Media File-set ID
(0088,0140) UI #0 [] Storage Media File-set UID
(0020,1206) IS #2 [14] Number of Study Related Series
(0020,1208) IS #4 [419] Number of Study Related Instances
(0088,0130) SH #0 [] Storage Media File-set ID
(0088,0140) UI #0 [] Storage Media File-set UID
22:33:41,030 INFO - Query Response #2:
(0008,0005) CS #10 [ISO_IR 100] Specific Character Set
(0008,0020) DA #8 [20100708] Study Date
(0008,0030) TM #14 [133007.984000] Study Time
(0008,0050) SH #10 [0162173301] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,0054) AE #8 [DCM4CHEE] Retrieve AE Title
(0008,0056) CS #6 [ONLINE] Instance Availability
(0008,1030) LO #14 [CRANIO^ROTINA] Study Description
(0010,0010) PN #30 [MARY DOE] Patient's Name
(0020,000D) UI #48 [1.2.840.55555.1997879323.20100708131953315.11231] Study
Instance UID
(0020,0010) SH #6 [10905] Study ID
(0020,1206) IS #2 [5] Number of Study Related Series
(0020,1208) IS #4 [110] Number of Study Related Instances
(0088,0130) SH #0 [] Storage Media File-set ID
(0088,0140) UI #0 [] Storage Media File-set UID
22:33:41,034 INFO - Query Response #3:
(0008,0005) CS #10 [ISO_IR 100] Specific Character Set
(0008,0020) DA #8 [20100707] Study Date
(0008,0030) TM #14 [164228.906000] Study Time
(0008,0050) SH #10 [0162084801] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,0054) AE #8 [DCM4CHEE] Retrieve AE Title
(0008,0056) CS #6 [ONLINE] Instance Availability
(0008,1030) LO #14 [CRANIO^ROTINA] Study Description
(0010,0010) PN #20 [MARY DOE] Patient's Name
(0020,000D) UI #48 [1.2.840.55555.1997879323.20100707162302284.10694] Study
Instance UID
(0020,0010) SH #6 [10824] Study ID
(0020,1206) IS #2 [14] Number of Study Related Series
(0020,1208) IS #4 [418] Number of Study Related Instances
(0088,0130) SH #0 [] Storage Media File-set ID
(0088,0140) UI #0 [] Storage Media File-set UID
52
22:33:41,038 INFO - Query Response #4:
(0008,0005) CS #10 [ISO_IR 100] Specific Character Set
(0008,0020) DA #8 [20100707] Study Date
(0008,0030) TM #14 [171926.000000] Study Time
(0008,0050) SH #10 [0162095901] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,0054) AE #8 [DCM4CHEE] Retrieve AE Title
(0008,0056) CS #6 [ONLINE] Instance Availability
(0008,1030) LO #14 [CRANIO^ROTINA] Study Description
(0010,0010) PN #38 [Mary DOE] Patient's Name
(0020,000D) UI #48 [1.2.840.55555.1997879323.20100707170254472.10745] Study
Instance UID
(0020,0010) SH #6 [10824] Study ID
(0020,1206) IS #2 [12] Number of Study Related Series
(0020,1208) IS #4 [257] Number of Study Related Instances
(0088,0130) SH #0 [] Storage Media File-set ID
(0088,0140) UI #0 [] Storage Media File-set UID
22:33:41,041 INFO - Query Response #5:
(0008,0005) CS #10 [ISO_IR 100] Specific Character Set
(0008,0020) DA #8 [20100707] Study Date
(0008,0030) TM #14 [174303.312000] Study Time
(0008,0050) SH #10 [0162100801] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,0054) AE #8 [DCM4CHEE] Retrieve AE Title
(0008,0056) CS #6 [ONLINE] Instance Availability
(0008,1030) LO #14 [CRANIO^ROTINA] Study Description
(0010,0010) PN #30 [JONH DOE] Patient's Name
(0020,000D) UI #48 [1.2.840.55555.1997879323.20100707172745378.10769] Study
Instance UID
(0020,0010) SH #6 [10824] Study ID
(0020,1206) IS #2 [9] Number of Study Related Series
(0020,1208) IS #4 [186] Number of Study Related Instances
(0088,0130) SH #0 [] Storage Media File-set ID
(0088,0140) UI #0 [] Storage Media File-set UID
22:33:41,043 INFO - DCM4CHEE(1) >> 1:C-FIND-RSP[pcid=1, status=0H]
22:33:41,043 INFO - Received 5 matching entries in 0.169 s
22:33:41,043 INFO - DCM4CHEE(1) << A-RELEASE-RQ
22:33:41,045 INFO - DCM4CHEE(1) >> A-RELEASE-RP
22:33:41,046 INFO - DCM4CHEE(1): close
Socket[addr=/192.168.0.103,port=11112,localport=55494]
22:33:41,047 INFO - Released connection to [email protected]:11112
Note que desta vez usamos a semântica definida pelo o usuário e
conseguimos todos os resultados pertinentes à consulta.
c) Consulta com a palavra CRANIO* no campo Study Description
(0008,1030). Desta vez usando o caractere * foi solicitado ao programa
de busca procurar tudo que contenha a palavra crânio, incluindo exames
que apresentem alguma informação extra depois da palavra definida. O
resultado da consulta no texto a seguir foi simplificado e exibe apenas os
53
dois casos novos que apareceram no resultado, já que os outros 5 são
comuns ao item b).
./dcmqr [email protected]:11112 -q 00081030=CRANIO*
Resultado do comando
23:06:37,842 INFO - DCM4CHEE(1) >> 1:C-FIND-RSP[pcid=1
ts=1.2.840.10008.1.2/Implicit VR Little Endian, status=ff00H]
23:06:37,844 INFO - Query Response #6:
(0008,0005) CS #10 [ISO_IR 100] Specific Character Set
(0008,0020) DA #8 [20100708] Study Date
(0008,0030) TM #14 [113733.953000] Study Time
(0008,0050) SH #10 [0162154201] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,0054) AE #8 [DCM4CHEE] Retrieve AE Title
(0008,0056) CS #6 [ONLINE] Instance Availability
(0008,1030) LO #14 [CRANIO^OUVIDO] Study Description
(0020,000D) UI #48 [1.2.840.55555.1997879323.20100708112455503.11162] Study
Instance UID
(0020,0010) SH #4 [5957] Study ID
(0020,1206) IS #2 [9] Number of Study Related Series
(0020,1208) IS #4 [166] Number of Study Related Instances
(0088,0130) SH #0 [] Storage Media File-set ID
(0088,0140) UI #0 [] Storage Media File-set UID
23:06:37,848 INFO - Query Response #3:
(0008,0005) CS #10 [ISO_IR 100] Specific Character Set
(0008,0020) DA #8 [20100708] Study Date
(0008,0030) TM #14 [120335.125000] Study Time
(0008,0050) SH #10 [0162159801] Accession Number
(0008,0052) CS #6 [STUDY] Query/Retrieve Level
(0008,0054) AE #8 [DCM4CHEE] Retrieve AE Title
(0008,0056) CS #6 [ONLINE] Instance Availability
(0008,1030) LO #24 [CRANIO^CRISE CONVULSIVA] Study Description
(0020,000D) UI #48 [1.2.840.55555.1997879323.20100708115458628.11195] Study
Instance UID
(0020,0010) SH #6 [10824] Study ID
(0020,1206) IS #2 [16] Number of Study Related Series
(0020,1208) IS #4 [729] Number of Study Related Instances
(0088,0130) SH #0 [] Storage Media File-set ID
(0088,0140) UI #0 [] Storage Media File-set UID
23:06:37,867 INFO - DCM4CHEE(1) >> 1:C-FIND-RSP[pcid=1, status=0H]
23:06:37,867 INFO - Received 7 matching entries in 0.195 s
23:06:37,868 INFO - DCM4CHEE(1) << A-RELEASE-RQ
23:06:37,870 INFO - DCM4CHEE(1) >> A-RELEASE-RP
23:06:37,870 INFO - DCM4CHEE(1): close
Socket[addr=/192.168.0.103,port=11112,localport=37963]
23:06:37,872 INFO - Released connection to [email protected]:11112
Note que apenas uma pequena modificação na palavra usada para a
consulta retornou como resultado, mais dois exames que estão
relacionados com a mesma parte do corpo
54
d) Consulta com a palavra HEAD no campo Body Part Examined
(0018,0015). Esta consulta foi uma tentativa de obter todos os exames
referentes a uma determina parte do corpo sem ter que seguir a semântica
definida de forma diferente para cada usuário.
root@led:~/dcm4che/bin# ./dcmqr [email protected]:11112 q 00180015=HEAD
Resultado do comando
23:41:49,809 INFO - DCM4CHEE(1) >> 1:C-FIND-RSP[pcid=1, status=0H]
23:41:49,809 INFO - Received 10 matching entries in 0.437 s
23:41:49,809 INFO - DCM4CHEE(1) << A-RELEASE-RQ
23:41:49,827 INFO - DCM4CHEE(1) >> A-RELEASE-RP
23:41:49,828 INFO - DCM4CHEE(1): close
Socket[addr=/192.168.0.103,port=11112,localport=41557]
23:41:49,829 INFO - Released connection to [email protected]:11112
De forma a simplificar o texto, foi colocado apenas a informação que
aparece no final, onde aparece um total de dez exames. Após uma consulta na
quantidade de exames disponíveis no repositório, verificou-se que este comando listou
todos os pacientes disponíveis. Isto ocorreu por que o campo estava com valor nulo.
55
4 – Conclusão
Neste trabalho foram abordadas técnicas de raciocínio baseado em casos e
como elas podem ser aplicadas para a área de saúde. Estas técnicas estão sendo
aplicadas na área médica de forma a mapear e transmitir conhecimento por toda a
comunidade. No Brasil, muito pouco está sendo feito e este é um campo
relativamente novo em outros países. Mas conforme os exemplos mostrados é cada
vez mais difícil não usar estas técnicas nos dias de hoje. Os diagnósticos podem ser
feitos em tempos mais curtos e erros médicos diminuídos drasticamente.
Com a queda dos custos de TI, é inevitável que ocorra na área médica o
mesmo que aconteceu na área empresarial, e em pouco tempo teremos um sistema
integrado de dados clínicos e hospitalares para pesquisa e controle de doenças. O
setor de TI não será mais visto como um custo desnecessário, mas como uma
ferramenta que ajuda o negócio e traz benefícios para médicos e pacientes.
O conceito do sistema gerado mostrou-se importante para médicos
radiologistas que já faziam um arquivo de casos pessoal, utilizando-se de cds e
imagens impressas. O problema que eles enfrentam é achar a informação de forma
rápida e organizada, que é resolvido pelo sistema de informações proposto.
Futuramente o sistema de recuperação de casos pode evoluir e usar técnicas
mais avançadas de CBR [27] tornando-se mais inteligente e mais útil para os
médicos radiologistas. A base para o sistema pode continuar sendo a mesma, já que
ela segue o padrão DICOM [2] e pode ser facilmente integrado em qualquer sistema
de TI hospitalar. O grande problema para que isto ocorra ainda vai continuar sendo
o padrão de preenchimento dos exames e a semântica usada quando o exame é
realizado, mas isto pode ser contornado com técnicas avançadas de busca que são
usadas amplamente para a procura de páginas na internet
56
Referências
[1] WIKIPÉDIA, Picture archiving and communication system.
http://en.wikipedia.org/wiki/Picture_archiving_and_communication_system
Acesso em 10/03/2011
[2] WIKIPÉDIA, Digital Imaging and Communications in Medicine.
http://en.wikipedia.org/wiki/Dicom
Acesso em 10/03/2011
[3] WIKIPÉDIA, Extensible Markup Language.
http://en.wikipedia.org/wiki/Xml
Acesso em 10/03/2011
[4] Introduction to HL7
http://www.hl7.com.au/FAQ.htm
Acesso em 10/03/2011
[5] PINTO, Jefferson de Souza, ANHOLON, Rosley FUNDATO, Eliane Araujo,
ARAUJO, Elisiete, ROMANO, Sonia Aparecida. O Mapeamento de um processo
administrativo do Departamento Financeiro na Controladoria de uma Empresa do
Segmento Veterinário
http://www.aedb.br/seget/artigos07/1101_Artigo%20Final%20Seget.pdf
Acesso em 10/03/2011
57
[6] WIKIPÉDIA, Open Systems Interconnection model.
http://en.wikipedia.org/wiki/OSI_model
Acesso em 10/03/2011
[7] WIKIPÉDIA, TCP/IP model
http://en.wikipedia.org/wiki/TCP/IP_model
Acesso em 10/03/2011
[8] DCM4CHEE REFERENCE DOCUMENTATION Version: 2.9.1
http://www.dcm4che.org/docs/reference/dcm4chee/pdf/dcm4chee-ref.pdf
Acesso em 10/03/2011
[9] WIKIPÉDIA, Java (programming language)
http://en.wikipedia.org/wiki/Java_(programming_language)
Acesso em 10/03/2011
[10] WIKIPÉDIA, Structured Query Language
http://en.wikipedia.org/wiki/SQL
Acesso em 10/03/2011
[11] MYSQL – Open Source Database Manager
http://www.mysql.com/
Acesso em 10/03/2011
58
[12] The Slackware Linux Project
http://www.slackware.com/
Acesso em 10/03/2011
[13] RIS - Radiology Information System
http://searchhealthit.techtarget.com/definition/Radiology-Information-System-RIS
Acesso em 10/03/2011
[14] Free Software x GNU x Open Source x GPL
http://www.hardware.com.br/faq/linux-sl/free-software-gnu-open-source-gpl.html
Acesso em 10/03/2011
[15] SOLOMON, Harry. DICOM Structured Reporting Overview
http://reportingwiki.rsna.org/images/0/00/RSNA_Reporting_Forum_Solomon.pdf
Acesso em 10/03/2011
[16] WATSON, Ian. Case-based reasoning is a methodology not a technology, AICBR, University of Salford (1999).
http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6V0P-3X7NCCHF&_user=10&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000050221&
_version=1&_urlVersion=0&_userid=10&md5=788c6ceb944fa13fb04e73b1665e9dfc#
m4.1
Acesso em 10/03/2011
59
[17] SILVA, Fernando Moreira, MORAIS, Misael Elias, FLEURY, Cláudio Afonso.
Implementação do Algoritmo ID3 de Quinlan, aplicado à meteorologia.
http://www.criatividadecoletiva.net/cbm-files/20a313e9c61b817866059d69b9e0365956.doc
Acesso em 10/03/2011
[18] jCOLIBRI, CBR Framework.
http://gaia.fdi.ucm.es/projects/jcolibri/
Acesso em 10/03/2011
[19] LIMA, Rodrigo Sucupira A. Data Mining e KDD.
http://www.nugen.uece.br/arquivos/apresentacoes/jornada_bf3/data_mining_kdd.pdf
Acesso em 10/03/2011
[20] FAVA, Vitor. Utilizando Full-Text Search
http://www.devmedia.com.br/post-18550-Utilizando-Full-Text-Search.html
Acesso em 10/03/2011
[21] Turyon Light Viewer
http://www.turyon.com/index.php
Acesso em 10/03/2011
[22] KARADJI, Kianusch Sayah. jpdbi - Display and optionally manipulate
DCM4CHE Database entries
http://www.dcm4che.org/confluence/display/ee2/jpdbi
Acesso em 10/03/2011
60
[23] EVANS, Damien. DCM2XML tool
http://www.dcm4che.org/confluence/display/d2/dcm2xml
Acesso em 10/03/2011
[24] EVANS, Damien. DCMQR tool
http://www.dcm4che.org/confluence/display/d2/dcmqr
Acesso em 10/03/2011
[25] WADO - Web Access to DICOM Persistent Objects
http://wiki.medicalconnections.co.uk/wiki/WADO
Acesso em 10/03/2011
[26] QI, Qiufen.Application of CBR in Healthcare, Dalhousie University.
http://web.his.uvic.ca/rle/2004/QQi.ppt
Acesso em 10/03/2011
[27] AAMODT, Agnar, PLAZA, Enric. Case-Based Reasoning: Foundational Issues,
Methodological Variations, and System Approaches.
http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=29B468223A73275E9A4C0C1
69B5DFA5A?doi=10.1.1.15.9093&rep=rep1&type=pdf
Acesso em 10/03/2011
[28] WIKIPÉDIA, Prontuário eletrônico.
http://pt.wikipedia.org/wiki/Prontuário_Eletrônico
Acesso em 10/03/2011
61
[29] The Sudbury Neutrino Observatory - Dicom Tags
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/DICOM.html
Acesso em 10/03/2011
62
Referências Consultadas
HÜLLERMEIER, Eyke – Case-Based Approximate Reasoning, University of
Magdeburg, Germany, Springer (2007), ISBN 978-1-4020-5694-9
LENZ, Mario, BARTSCH-SPÖRL, Brigitte, BURKHARD, Hans-Dieter, WESS, Stefan
– Case-Based Reasoning Technology. From Foundations to Applications, Springer
(1998), ISBN 3-540-64572-1
PIANYKH, Oleg S. - Digital Imaging and Communications in Medicine (DICOM). A
Practical Introduction and Survival Guide, Department of Radiology, BIDMC,
Harvard Medical School (2008), ISBN 978-3540745709
TANENBAUM, Andrew S. – Redes de Computadores, Tradução da terceira edição,
Editora Campus (1997), ISBN 85-352-0157-2
63
Referências da WEB
KOTON, Phyllis - Using Experience in Learning and Problem solving
http://groups.csail.mit.edu/medg/ftp/koton/using%20experience%20in%20learning%20
and%20problem%20solving.pdf
Acesso em 10/03/2011
MURPHY,Jeannette - Facilitator of the Future, University College London, Medical
School
http://www.primis.nhs.uk/Presentations/Presentations2005/plenaryfacilitatorofthefuture.pps
Acesso em 10/03/2011
NEMA – National Electrical Manufacturers Association
http://www.nema.org/
Acesso em 10/03/2011
64