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

Transcrição

1 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

2 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

3 M5676p Soares, Sergio Ricardo Pereira Raciocínio baseado em casos para radiologia. Rio de Janeiro, 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: iii

4 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

5 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

6 AGRADECIMENTOS Agradeço a Deus por me dar forças e perseverança para concluir este curso. vi

7 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

8 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

9 LISTA DE FIGURAS Figura 2.1 Setores de um hospital Figura 2.2 Tipo de dados em um hospital ou clínica Figura 2.3 Sistemas de TI existentes em um hospital Figura 2.4 Protocolo DICOM e o padrão OSI Figura 2.5 Protocolo HL7 e um exemplo de algumas mensagens Figura 2.6 Setores e protocolos usados para troca de informações Figura 2.7 Sistemas normalmente usados para fornecer dados clínicos Figura 2.8 Setores e protocolos usados para troca de informações Figura 2.9 Fluxograma do tratamento de um paciente usando os SI Hospitalares Figura 2.10 Exemplo de prontuário eletrônico Figura Ciclo de funcionamento de um CBR Figura Ciclo de funcionamento de um CBR complexo Figura Casos selecionados de um CBR para defeitos em carros Figura Novo caso com um problema sem solução Figura Valores de similaridade Figura Valores de similaridade para cada atributo Figura 3.1 RIS com a estação de laudo especialista Figura 3.2 Diagrama do SI completo Figura 3.3 Diagrama do SI separado Figura Diagrama do SI para recolher casos Figura Tela Inicial após o login do cliente Turyon Figura Tela mostrando o paciente selecionado Figura Tela do laudo estruturado ix

10 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

11 TI - Tecnologia da Informação xi

12 Sumário 1 Introdução Tema Delimitação Justificativa Objetivos Objetivo Geral Objetivos específicos Metodologia Fundamentação Teórica Case Based Reasoning Técnicas de implementação de um CBR Exemplos de uso de CBRs Proposta de solução Módulo para recolher casos no formato DICOM Módulo de recuperação de casos Conclusão 56 Referências 57 Referências Consultadas 63 Referências da Web 64 xii

13 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

14 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

15 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 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 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

16 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

17 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

18 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

19 Figura 2.1 Setores de um hospital 7

20 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

21 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

22 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

23 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

24 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

25 Pode-se visualizar como este protocolo é estruturado na figura 2.5 Figura 2.5 Protocolo HL7 e um exemplo de algumas mensagens 13

26 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

27 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

28 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

29 Figura 2.8 Setores e protocolos usados para troca de informações 17

30 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 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

31 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

32 Figura 2.9 Fluxograma do tratamento de um paciente usando os SI Hospitalares 20

33 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 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

34 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

35 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

36 Figura 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 é uma forma exemplificada do processo, o uso de índices com valores definidos para a sua importância ajuda a classificação e 24

37 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 mostra o mesmo ciclo visto anteriormente, mas com a implementação destas novas funcionalidades. Figura Ciclo de funcionamento de um CBR complexo 25

38 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

39 é 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

40 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

41 Figura Casos selecionados de um CBR para defeitos em carros 29

42 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 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

43 Figura 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 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

44 Figura 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

45 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))/( ) = 28,2/32 = 0,88 Caso 2 Similaridade = ((10*0,8)+(1*0)+(0,4*1)+(10*0,95)+(10*0))/( ) = 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

46 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

47 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

48 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

49 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

50 momento. Neste aspecto, o médico especialista deve ter a preocupação de descrever corretamente os casos de sucesso. 38

51 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

52 Figura 3.1 RIS com a estação de laudo especialista 40

53 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

54 Figura 3.2 Diagrama do SI completo 42

55 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

56 Figura 3.3 Diagrama do SI separado 44

57 Com as duas partes do software definidas pode-se detalhar como cada uma funciona, mostrando exemplos do módulos já integrados 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 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 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 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

58 Figura 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

59 Figura 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 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

60 Figura 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

61 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

62 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 DCM4CHEE@ : q =CRANIO Resultado do comando 23:41:02,002 INFO - Association(1) initiated Socket[addr=/ ,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 DCM4CHEE@ :11112 in s 23:41:02,244 INFO - Send Query Request using /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

63 cuid= /study Root Query/Retrieve Information Model - FIND ts= /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 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=/ ,port=11112,localport=38270] 23:41:02,594 INFO - Released connection to DCM4CHEE@ :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 DCM4CHEE@ : q =CRANIO^ROTINA Resultado do comando 22:33:40,853 INFO - Association(1) initiated Socket[addr=/ ,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 DCM4CHEE@ :11112 in s 22:33:40,977 INFO - Send Query Request using /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 [ ] Study Date (0008,0030) TM #14 [ ] Study Time (0008,0050) SH #10 [ ] 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