UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE …siaibib01.univali.br/pdf/Mauricio Rosa.pdf ·...
75
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO DESENVOLVIMENTO DE UMA METODOLOGIA COMPUTACIONAL PARA GERENCIAMENTO DE PRONTUÁRIOS OTOLOGICOS Área de Sistema de Informação por Maurício Rosa Eros Comunello, Dr. rer. nat. Orientador Vilson Heck Junior, Bacharel Co-orientador São José (SC), novembro de 2007
Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE …siaibib01.univali.br/pdf/Mauricio Rosa.pdf ·...
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UMA METODOLOGIA COMPUTACIONAL PARA GERENCIAMENTO DE PRONTUÁRIOS OTOLOGICOS
Área de Sistema de Informação
por
Maurício Rosa
Eros Comunello, Dr. rer. nat. Orientador
Vilson Heck Junior, Bacharel Co-orientador
São José (SC), novembro de 2007
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DESENVOLVIMENTO DE UMA METODOLOGIA COMPUTACIONAL PARA GERENCIAMENTO DE PRONTUÁRIOS OTOLOGICOS
Área de Sistema da Informação
por
Maurício Rosa Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Eros Comunello, Dr. rer. nat.
São José (SC), novembro de 2007
DEDICATÓRIA
Aos meus pais, que me deram à vida e me ensinaram a vivê-la com dignidade.
A minha namorada, por ser minha fonte de energia, de inspiração e de profundo amor.
AGRADECIMENTOS
Agradeço em primeiro lugar a Deus que iluminou o meu caminho durante esta caminhada.
Agradeço também a Amauri Nilo da Rosa meu pai, minha mãe Eliza Margarida da Rosa, minha irmã Daniela
Santos da Rosa e minha namorada Fernanda Nunes que mesmo sem conhecimento no assunto sempre me
deram muita força, me apoiando nos momentos de dificuldades.
Gostaria de agradecer a todas as pessoas que colaboram diretamente com este trabalho aos meus
orientadores Eros Comunello e Vilson Heck Junior pela grande caminhada juntos neste trabalho, a equipe
de design do Grupo Cyclops Luciana Fernandes e Aline Pickler, aos meus colegas de trabalho Saulo Murilo
Duarte, Maurício Teixeira Farias e Dickson Guedes pela ajuda e explicações em diversos assuntos e a Dr.
Cristina Dornelles pelos esclarecimentos durante o desenvolvimento deste.
Deixo também meus agradecimentos a Miguel Nunes e Maria Aparecida Nunes pela grande ajuda
que me deram na reta final desta caminhada.
ii
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................iv
LISTA DE FIGURAS ...............................................................................v
RESUMO ..................................................................................................vi ABSTRACT .............................................................................................vii 1 INTRODUÇÃO.....................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 2 1.1.1 Formulação do Problema ................................................................................. 2 1.1.2 Solução Proposta ............................................................................................... 3 1.2 OBJETIVOS ........................................................................................................ 3 1.2.1 Objetivo Geral ................................................................................................... 3 1.2.2 Objetivos Específicos ........................................................................................ 3 1.2.3 Escopo ................................................................................................................ 4 1.3 METODOLOGIA................................................................................................ 5 1.4 ESTRUTURA DO TRABALHO ....................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA .......................................................7 2.1 CENÁRIO MÉDICO .......................................................................................... 7 2.1.1 Fisiologia da orelha humana............................................................................ 7 2.1.2 Anatomia da Orelha ......................................................................................... 7 2.1.3 Otite Média ...................................................................................................... 11 2.1.4 Prontuários ...................................................................................................... 13 2.1.5 Prontuário Médico X Prontuário Eletrônico do Paciente .......................... 16 2.2 CENÁRIO COMPUTACIONAL .................................................................... 16 2.2.1 Prontuário Eletrônico do Paciente ................................................................ 16 2.2.2 AURIS .............................................................................................................. 19 2.2.3 Plataforma de Desenvolvimento Web ........................................................... 23 2.2.4 Banco de dados ................................................................................................ 26 2.2.5 Protocolação digital ........................................................................................ 27
3 DESENVOLVIMENTO .....................................................................29 3.1 PLANEJAMENTO............................................................................................ 30 3.2 LEVANTAMENTO DE REQUISITOS.......................................................... 30 3.2.1 Definição dos requisitos.................................................................................. 33 3.3 FUNCIONALIDADES DO PORTAL ............................................................. 35 3.4 MODELAGEM.................................................................................................. 35 3.4.1 Casos de Uso .................................................................................................... 36 3.4.2 Diagrama de classes ........................................................................................ 37 3.4.3 Diagrama de Banco de dados......................................................................... 39 3.5 PROTÓTIPO PHP ............................................................................................ 44
iii
3.5.1 Layout do protótipo ........................................................................................ 44 3.5.2 Implementação do protótipo.......................................................................... 44 3.6 CRONOGRAMA PLANEJADO X CRONOGRAMA EXECUTADO....... 45
4 RESULTADOS ...................................................................................48 4.1 AVALIAÇÃO DO PROTÓTIPO DESENVOLVIDO................................... 51
5 CONCLUSÃO.....................................................................................54 5.1 TRABALHOS FUTUROS................................................................................ 55
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................57
ANEXOS ..................................................................................................59
LISTA DE ABREVIATURAS
API Application Programming Interface ou Interface de Programação de Aplicativos
ASP Active Server Pages CSV Campos Separados por Vírgula BSD Berkeley Software Distribution HCPA Hospital de Clinicas de Porto Alegre HTML Hyper Text Markup Language ou Linguagem de Marcação de Hipertexto JSP Java Server Pages MVCC Multiversion Concurrency Control ou Controle de Concorrência
Multiversões OMC Otite Média Crônica PDAs Personal Digital Assistants ou Assistente Pessoal Digital PDDE Protocoladora Digital de Documentos Eletrônicos PDI Processamento Digital de Imagens PEP Prontuário Eletrônico do Paciente PHP PHP: Hypertext Preprocessor TCC Trabalho de Conclusão de Curso UFRGS Universidade Federal do Rio Grande do Sul UFSC Universidade Federal de Santa Catarina UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí URL Uniform Resourse Locator UTI Unidade de Terapia Intensiva SGDB Sistema Gerenciador de Banco de Dados SQL Structured Query Language ou Linguagem de Consulta Estruturada SSL Secure Sockets Layer
LISTA DE FIGURAS
Figura 1. Estrutura da metodologia. .....................................................................................................4 Figura 2. Corte semi-esquemático mostrando as orelhas externa, média e interna. ............................8 Figura 3. Tímpano saudável. ..............................................................................................................10 Figura 4. Tela de seleção do tímpano.................................................................................................20 Figura 5. Desenho da área aproximada na tela de seleção de perfuração. .........................................21 Figura 6. Área selecionada na tela de seleção de perfuração. ...........................................................21 Figura 7. Tela de definição dos quadrantes........................................................................................22 Figura 8. Tela final exibindo resultados da mensuração....................................................................23 Figura 9. Quantidade de domínios que utilizam PHP ........................................................................24 Figura 10. Estrutura bottom-up ..........................................................................................................29 Figura 11. Processo do negócio..........................................................................................................31 Figura 12. Diagrama de Classes.........................................................................................................38 Figura 13. Entidades pessoa, usuário, especialista e paciente............................................................39 Figura 14. Entidade protocolo. ...........................................................................................................39 Figura 15. Dados queixa.....................................................................................................................40 Figura 16. Modelagem do protocolo de primeira consulta. ...............................................................41 Figura 17. Modelagem do protocolo de revisão pré-operatória. ........................................................42 Figura 18. Modelagem do protocolo de descrição cirúrgica. .............................................................43 Figura 19. Modelagem do protocolo de revisão pós-operatória.........................................................44 Figura 20. Interface do Portal desenhada. ..........................................................................................48 Figura 21. Interface do Portal Implementada.....................................................................................49 Figura 22. Interface Funcionalidades Implementada. ........................................................................50 Figura 23. Interface Lista de Pacientes Implementada. .....................................................................50 Figura 24. Interface Cadastro do Protocolo de Primeira Consulta Implementada.............................51
RESUMO
ROSA, Maurício. Desenvolvimento de uma Metodologia Computacional para gerenciamento de Prontuários Otológicos. São José, 2007. 74 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade do Vale do Itajaí, São José, 2007. Devido à crescente abertura de acesso à informação advinda dos especialistas da área da saúde, cada vez mais os avanços tecnológicos têm se tornado uma realidade no seu cotidiano. A informação em saúde tornou-se mais acessível devido a esses os avanços tecnológicos possibilitando assim a sua ampla utilização e compartilhamento através da Internet. Porém, existe uma carência de soluções completas para a área da saúde ou para um setor específico da saúde, o que acaba por gerar uma série de pequenos softwares, que freqüentemente não fazem a integração das informações de uma maneira completa. Atualmente o grupo do Hospital de Clínicas de Porto Alegre (HCPA) que atua na área otológica, composta por especialistas de renome internacional, possuem um banco de casos de mais de 700 pacientes portadores de Otite Média Crônica. Este banco de casos é composto por uma série de protocolos os quais são armazenados em papel dificultando o acesso às informações dos pacientes. Partindo deste principio este trabalho de conclusão de curso apresenta uma metodologia computacional e a implementação de um protótipo de software com base na plataforma WEB. Esta metodologia computacional visa integrar o setor de Otologia com foco de assistência à Otite Média Crônica. Esse protótipo de software permite o acesso ao cadastro das informações dos protocolos de pacientes em um banco de dados, trazendo uma rápida recuperação de dados. O acesso às informações somente é permitido através de usuários cadastrados com senhas, o que traz segurança e sigilo, além da autenticidade dos dados por uso de uma assinatura digital. Informações dos protocolos de primeira consulta, revisão pré-operatório, revisão pós-operatório e descrição cirúrgica tornam-se acessíveis através deste protótipo de software. Especialistas da área otológica avaliaram empiricamente os resultados atingidos com o uso do protótipo de software e afirmaram que o mesmo auxiliará no cotidiano dos profissionais da saúde da área otológica. Palavras-chave: Otologia, Protocolos Médicos, Arquivo Médico Digital.
ABSTRACT
Due to increasing opening of access to information that coming of the specialists of the area of the health, each time more the technological advances have become a reality in its daily one. The information in health became more accessible due to these the technological advances thus making possible its ample use and sharing through the Internet. However, lack of complete solutions for the area of the health or a specific sector of the health exists, what it finishes for generating a small series of softwares, that frequent they do not make the integration of the information in a complete way. Currently the group of the Hospital of Clinics from Porto Alegre (HCPA) that it acts in the otological area, composed for specialists of international reputation, having possess a bank of cases of 700 carrying patients of Chronic Otitis Media. This bank of cases is composed for a series of protocols which are stored in paper making it difficult the access the information of the patients. Starting of this target, this work of course conclusion presents a computational methodology and the implementation of a software Prototype in basis platform WEB. This computational methodology aims at to integrate the sector of Otology with focus of assistance to the Chronic Otitis Media. This Prototype of software allows the access to it registers in cadastre of the information of the protocols of patients in a data base, bringing a fast recovery of data. The access the information is only allowed through users registered in cadastre with passwords, what it brings security and confidential, beyond the authenticity of the data for use of a digital signature. Information of the protocols of first consultation, revision pre-surgery, after-surgery revision and surgical description become accessible through this Prototype of software. Specialists of the otological area had empirically evaluated the results reached with the use of the software prototype and had affirmed that the same will assist in the daily one of the professionals of the health in otological area. Keywords: Otology, Medical Protocols, Digital Medical Archive
1 INTRODUÇÃO
Devido à crescente abertura de acesso à informação, advinda de especialistas da área da
saúde, principalmente por parte dos médicos em forma de colaboração, cada vez mais a Informática
vem sendo utilizada como ferramenta de apoio clínico. A cada dia aumenta o número de softwares
que são desenvolvidos para a medicina, apesar de que a maior parte destes corresponde a soluções
bastante específicas. Isto se pode apresentar como um problema, uma vez que existe a carência de
soluções completas a uma área ou setor específico da saúde, e geralmente torna-se necessário
agregar uma série de pequenos softwares, gerando problemas de integração entre eles.
Frente a estes desafios, a proposta deste trabalho de conclusão de curso foi desenvolver uma
metodologia computacional para ser implementada na plataforma Web e integrar o setor de
Otologia no que se refere à Otite Média Crônica. O setor que foi utilizado como referência é o
Centro de Otite Média do Brasil (Com.Br) do Hospital de Clínicas de Porto Alegre (HCPA) e
Universidade Federal do Rio Grande do Sul (UFRGS).
Segundo Bertulani (2006), o tímpano é uma importante parte integrante do sistema auditivo.
Ele é responsável por auxiliar a orelha média na conversão das ondas sonoras, conduzidas pela
orelha externa, em sinais mecânicos, que serão posteriormente convertidos para impulsos elétricos
pela orelha interna. Qualquer problema que venha a lesionar o tímpano pode ocasionar uma perda
auditiva condutiva. Dentre os problemas que podem afetar o tímpano, encontram-se diversas
patologias (COSTA & DORNELLES, 2006a), tais como: Otite Média Crônica (OMC) na forma de
Perfurações, Colesteatomas, Timpanoesclerose e Retração Timpânica. A OMC tem alta prevalência
e distribuição mundial, características que somadas lhe definem como uma “questão de saúde
pública”.
Para suprir algumas necessidades dos especialistas em OMC, da área de Otologia, um
sistema chamado AURIS (HECK JUNIOR et al, 2006) foi desenvolvido pelo grupo Cyclops
(UFSC). Através da utilização de técnicas avançadas de Processamento Digital de Imagens (PDI) e
análise de geometria, o sistema AURIS permite ao especialista mensurar patologias associadas à
OMC. Desse modo, os especialistas possuem uma ferramenta eficiente e de fácil manipulação para
a extração de informações quantitativas das patologias e não somente subjetivas como efetuado
anteriormente por métodos empíricos.
2
Com o desenvolvimento de uma metodologia computacional para gerenciamento dos
protocolos otológicos seria possível integrar as informações dos pacientes portadores de otite média
crônica com as informações provenientes do sistema computacional responsável por mensurações
de perfurações timpânicas, intitulado AURIS. As informações a serem cadastradas neste banco de
dados são provenientes dos protocolos de consultas e cirurgias, tais como, protocolos de primeira
consulta, pré-operatório, pós-operatório, descrição cirúrgicas, audiometrias e imagens provenientes
de exames de videotoscopia digital, além de dados demográficos do paciente como nome, endereço,
etc.
Outro beneficio que o desenvolvimento desta metodologia computacional traz é a
aproximação dos especialistas da área de Otologia ao acesso das informações através de tecnologias
computacionais utilizando conceitos Web. Dessa forma, o acesso às informações do paciente não
ficam restritas somente em um ambiente hospitalar, mas também em qualquer outro computador
conectado à internet. Tendo em vista esse acesso via Web, discussões e segunda opinião médica são
facilitadas e conseqüentemente incentivadas.
Segundo Netto et al (2005) os avanços tecnológicos têm tornado a informação em saúde
mais acessível, com a possibilidade de ampla utilização e compartilhamento de informação, com
destaque para o crescente uso e aplicação da internet. Surgiu o conceito de e-Health definido como
“um campo emergente da intersecção da informática médica, saúde pública e negócios, relativo a
serviços de saúde e informações transmitidas através da internet e tecnologias relacionadas.”
(COSTA, 2001).
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
O Grupo do Hospital de Clínicas de Porto Alegre que atua na área otológica é composta por
especialistas de renome internacional. Estes especialistas possuem um banco de casos de mais de
700 pacientes portadores de Otite Média Crônica. Este banco de casos é composto de imagens
digitais, bem como de uma série de protocolos os quais são armazenados em papel dificultando a
recuperação, acompanhamento, etc. dos pacientes. Comparações entre casos, recuperação e
cruzamento de informações são tarefas que demandam uma grande quantidade de tempo.
3
1.1.2 Solução Proposta
A proposta deste Trabalho de Conclusão de Curso foi desenvolver uma metodologia
computacional para a Otologia que contemple o prontuário eletrônico de paciente. Este prontuário
será composto dos protocolos: a) primeira consulta; b) pré-operatório; c) pós-operatório; d)
descrição cirúrgica; e e) protocolo de audiometria; bem como, dos dados resultantes do sistema
AURIS1. A validação desta metodologia computacional foi feita através do desenvolvimento de um
protótipo de sistema de software Web. Esta metodologia computacional permite a rápida
recuperação de dados do paciente, como histórico e evolução da patologia.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Desenvolver uma metodologia computacional para o gerenciamento de prontuários
otológicos e avaliá-la através da implementação de um protótipo de sistema de software Web que
abranja o prontuário eletrônico do paciente e seus protocolos.
1.2.2 Objetivos Específicos • Efetuar o levantamento do estado da arte do trabalho proposto;
• Fazer um estudo detalhado para a proposição de uma metodologia computacional para a
otologia, mais especificamente para o grupo de Otite Media Crônica do HCPA;
• Modelar conceitualmente a metodologia computacional com base nos padrões descritos
pela Engenharia de Software;
• Desenvolvimento dos protocolos (primeira consulta; pré-operatório; pós-operatório,
descrição cirúrgica; e protocolo de audiometria);
• Testar e avaliar esta metodologia computacional através do desenvolvimento de um
protótipo de sistema de software Web;
• Testar e avaliar o protótipo de sistema de software Web; e
• Documentar o desenvolvimento e os resultados do sistema.
1 Ver detalhes no capitulo 2
4
1.2.3 Escopo
A metodologia computacional aqui proposta permite através de um protótipo de sistema de
software Web o acesso on-line das mais diversas informações dos pacientes da área de Otologia,
como dados demográficos e visualização e cadastro dos mais diversos protocolos já devidamente
institucionalizados como: protocolos de primeira consulta, pré-operatório, pós-operatório e
descrição cirúrgica.
Existem sistemas de prontuário eletrônico de paciente que incorporam muitos dos aspectos
aqui propostos, no entanto são sistemas muito abrangentes e de forma alguma focados à otologia,
como é o caso do sistema aqui proposto.
Atualmente no contexto apresentado não existe nenhuma ferramenta computacional similar
ao AURIS, que permita extrair dados de perfuração e outras patologias timpânicas. Esta
metodologia computacional pretende fornecer aos especialistas além das informações provenientes
dos diversos protocolos, ser estruturada para integrar também as informações geradas pelo AURIS
como mostra a Figura 1.
Figura 1. Estrutura da metodologia.
O acesso a essas informações deverá utilizar os critérios de segurança na conexão e também
de protocolação digital (a ser fornecido por um terceiro).
Não faz parte deste trabalho, desenvolver um módulo para a administração de tabelas
auxiliares (cidades, estados), usuários, dentre outros.
5
1.3 Metodologia
A metodologia de pesquisa utilizada neste trabalho é do tipo aplicada sob o ponto de vista da
sua natureza, pois objetiva gerar conhecimentos para a execução prática dirigida à solução de
problemas específicos envolvendo verdades e interesses locais (SILVA, 2001). Dessa forma, foram
definidas três etapas para a conclusão do trabalho: pesquisa e estudo, desenvolvimento e testes e
publicação.
• Pesquisa e estudo: nessa parte do trabalho foram realizadas pesquisas conceituais da
literatura que tratam dos temas relacionados ao tema deste trabalho;
• Desenvolvimento e testes: com base nas pesquisas e estudos realizados, nessa etapa do
trabalho tem-se o desenvolvimento do Portal e em paralelo seus devidos testes; e
• Publicação do Portal: depois de desenvolvido e testado foi realizado a publicação do
Portal na rede para uso dos devidos usuários.
1.4 Estrutura do trabalho
Este documento está estruturado em quatro capítulos.
O Capítulo 1, Introdução, apresenta uma visão geral do trabalho, bem como objetivo geral e
objetivos específicos.
O Capítulo 2, Fundamentação Teórica, foi dividido em duas partes. A primeira parte é o
cenário médico, no qual são apresentados os conceitos básicos sobre a fisiologia da orelha humana e
otite média, assim como uma análise a respeito dos prontuários médicos. Na segunda parte deste
capítulo, o cenário computacional, são apresentados conceitos sobre prontuários eletrônicos, sobre o
sistema AURIS, o que é e como funciona, vantagens de usar o PHP como plataforma de
desenvolvimento Web, características do banco de dados a ser utilizado para o desenvolvimento
deste TCC, como os dados dos pacientes serão autenticados através protocolação digital usando a
ferramenta PDDE.
O Capítulo 3 apresenta a análise de requisitos do sistema a ser desenvolvido, incluindo sua
especificação e a sua modelagem em UML - Unified Modeling Language. Esse capítulo também
apresenta a modelagem diagrama de banco de dados e como foi feita a implementação do protótipo.
6
O Capitulo 4 apresenta os resultados obtidos com a implementação do protótipo bem como
uma avaliação feita junto aos especialistas do HCPA.
Concluindo, no Capítulo 5, apresenta-se a conclusão do trabalho.
O texto ainda inclui dois apêndices e três anexos que complementam as informações
apresentadas no trabalho.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo será apresentada uma análise dos aspectos conceituais da literatura que tratam
dos temas relacionados à pesquisa no intuito de fornecer embasamento teórico ao trabalho. Esta
seção do trabalho foi dividida em duas partes, cenário médico e cenário computacional. A primeira
parte apresenta os conceitos básicos sobre a fisiologia da orelha humana, a otite média e prontuários
médicos. Na segunda parte são apresentados conceitos sobre prontuários eletrônicos, sobre o
sistema AURIS, plataforma de desenvolvimento Web, banco de dados e protocolação digital.
2.1 Cenário Médico
2.1.1 Fisiologia da orelha humana
Segundo Costa (2005), a orelha humana normal pode distinguir cerca de 400.000 sons
diferentes. A audição funciona da seguinte maneira: o som propaga-se produzindo ondas sonoras
que se deslocam até atingir a orelha. O mecanismo da audição transforma estas ondas em sinais
elétricos que são transmitidas como mensagens, através do nervo auditivo para o cérebro que as
interpreta.
2.1.2 Anatomia da Orelha
Segundo Zorzetto (2006), o órgão vestibulococlear, mais conhecido como orelha é o
complexo morfofuncional, ou seja, um conjunto de órgãos que se relacionam entre si, responsável
pela sensibilidade ao som e aos efeitos gravitacionais. A orelha está abrigada na intimidade do osso
temporal, um osso par, que contribui para a parede lateral e para a base do crânio, e se difere
conforme a idade (COSTA, 2005). A orelha consiste em três partes: orelha externa, orelha média e
orelha interna, como mostra a Figura 2. Cada uma com suas próprias características estruturais e
funcionais indispensáveis para o bom funcionamento da orelha.
8
Figura 2. Corte semi-esquemático mostrando as orelhas externa, média e interna.
Fonte: Zorzetto (2006)
2.1.2.1 Orelha Externa
A orelha externa desempenha a função de coletar e encaminhar as ondas sonoras até a orelha
média (HUNGRIA, 2000). Segundo Costa (2005), a orelha externa consiste em duas partes, o
pavilhão auditivo e o meato acústico externo:
• O pavilhão da orelha ou pina, se projeta lateralmente à cabeça e é responsável pela
captação do som (ZORZETTO, 2006). Segundo Albernaz et al (1997), o pavilhão é
conectado ao crânio e ao couro cabeludo por três pequenos músculos extrínsecos: os
músculos anterior, posterior e superior. Zorzetto (2006) comenta que o pavilhão é
formado por uma placa irregular de cartilagem elástica e coberto de pele que lhe confere
forma peculiar.
9
• Meato acústico externo é um curto conduto que se dirige do exterior para o interior do
órgão e que se apresenta fechado na extremidade interna pela membrana do tímpano
(ZORZETTO, 2006). Esta membrana é fina e translúcida, separando a orelha externa da
orelha média (ALBERNAZ et al, 1997). Albernaz et al (1997) comenta, o meato
acústico externo tem formato estreito, alongado, angulado e estrangulado que tem por
finalidade proteger as estruturas mais internas da orelha, ao mesmo tempo em que
permite a chegada do som.
2.1.2.2 Orelha Média
A orelha média, comenta Hungria (2000), desempenha a função primordial de transmissão
da onda sonora. Para Zorzetto (2006) ela é formada por uma pequena câmara cheia de ar na porção
petrosa do osso, trata-se da porção mais complexa do osso temporal pela quantidade de estruturas
anatômicas que a ela se relacionam (COSTA, 2005). É também denominada cavidade timpânica ou
caixa do tímpano (ALBERNAZ et al, 1997). Zorzetto (2006) comenta que essa cavidade comunica-
se com a nasofaringe, parte nasal da faringe, por um canal chamado tuba auditiva, que segundo
Albernaz et al (1997) é responsável pelo arejamento da orelha média, fundamental para o bom
estado da mucosa e para a equalização da pressão da caixa do tímpano com o meio ambiente. Em
direção oposta à tuba, a cavidade timpânica liga-se também ao antro da mastóide e, assim, com as
células do processo mastóide do osso temporal (ZORZETTO, 2006).
A Cavidade Timpânica é fechada lateralmente pela membrana do tímpano, que serve como
limite entre a orelha média e o meato acústico externo. Essa membrana está voltada lateralmente
para frente e para baixo, como se captasse os sons refletidos do solo conforme se avança.
Distinguem-se nessa cavidade os seguintes limites: parede lateral, parede superior, parede inferior,
parede posterior e parede anterior (ZORZETTO, 2006).
Costa (2005) comenta que uma cadeia de três ossículos articulados, situados na cavidade
timpânica, estende-se da membrana do tímpano até a orelha interna e é responsável pela
transmissão das vibrações provocadas pelas ondas sonoras que incidem sobre a membrana
timpânica.
Zorzetto (2006) define esses ossículos como:
10
• Martelo: É o primeiro e maior ossículo da cadeia. Mede 8 ou 9 mm de comprimento. O
martelo é sustentado pela sua fixação na membrana do tímpano, pelo músculo tensor do
tímpano pelos ligamentos próprios e pela articulação com a bigorna;
• Bigorna: É o mais longo dos três ossículos. O corpo da bigorna é aproximadamente
cubóide e apresenta uma face articular revestida de cartilagem, em forma de sela, para se
articular com a face correspondente da cabeça do martelo no recesso epitimpânico; e
• Estribo: É o menor e mais medial elo da cadeia ossicular. Consiste na cabeça, na base e
em dois ramos ou cruras.
Albernaz et al (1997) comentam que o conjunto, membrana do tímpano e ossículos tem por
finalidade conduzir o som do meio externo para a orelha interna. Segundo Bertulani (2007)
auxiliando a orelha média na conversão das ondas sonoras conduzidas pela orelha externa em sinais
mecânicos que serão posteriormente convertidos para impulsos elétricos pela orelha interna, está o
tímpano. Este se liga aos ossículos responsáveis por transmitir o som para a cóclea (orelha interna).
Por esse motivo, o tímpano se torna uma parte integrante do sistema auditivo.
O tímpano mostrado na Figura 3 é resultado da captação que ocorre utilizando equipamento
de Otoscopia. Tal figura mostra que o tímpano é um pedaço de pele fina, em forma de cone,
semitransparente com aproximadamente 10 milímetros de espessura, localizado entre o canal
auditivo e a orelha média. (ZORZETTO, 2006)
Figura 3. Tímpano saudável.
Fonte: Heck et al (2006)
11
2.1.2.3 Orelha Interna
Zorzetto (2006) comenta que a orelha interna consiste em um intricado conjunto de
cavidades e canais no interior da porção petrosa do osso temporal, conhecidos como labirintos
ósseos, dentro dos quais existem delicados ductos e vesículas membranosas, designadas, no seu
conjunto, labirinto membranáceo, o qual contém as estruturas vitais da audição e do equilíbrio.
É na orelha interna que a vibração sonora se transforma em estímulo nervoso específico ao
nível do órgão de Corti, situado na cóclea, de onde é conduzido aos centros corticais da audição, em
que se consuma o fenômeno consciente da sensação sonora. (HUNGRIA, 2000)
2.1.3 Otite Média
Costa et al (2006) comentam que a otite média representa uma das doenças infecciosas que
mais prevalece, constituindo-se ainda hoje em um problema de saúde pública de caráter mundial.
O seu impacto é imenso devido ao processo inflamatório em si, o qual muitas vezes pode
extrapolar os limites do osso temporal, gerando complicações graves e mesmo fatais. Apesar de
todas as faixas etárias serem atingidas pela otite média, a população-alvo com maior risco de
adquirir a doença é a infantil, com um pico de prevalência máxima entre os 6 e os 36 meses,
coadjuvado por um outro pico de menor amplitude, entre os 4 e 7 anos. Há uma variação sazonal na
prevalência da otite média, com um aumento da incidência no inverno e no início da primavera
(COSTA et al, 2006).
Segundo Costa et al (2006), a otite média é definida como um processo inflamatório,
infeccioso ou não, ocupando focal ou generalizadamente a fenda auditiva. As malformações
craniofaciais e, especialmente, as fendas palatinas, constitui-se em fatores predisponentes
maiúsculos para a otite média.
O processo inflamatório inicia-se com uma lesão tecidual mais ou menos intensa. Nesse
processo ocorrem dois quadros sucessivos, um agudo e um crônico, comentam Costa et al (2006):
• Um agudo: Que se caracteriza pela formação de uma inflamação no tecido; Hungria
(2000) comenta que as otites médias agudas traduzem processos inflamatórios agudos na
orelha média. São desencadeadas, na sua totalidade, em virtude de infecções das fossas
nasais propagadas à orelha média através da tuba auditiva.
12
• Um crônico: A fase crônica da inflamação instala-se 36 a 48 horas após o estímulo
inflamatório (COSTA et al, 2006). As otites médias crônicas assinalam-se pela
persistência de uma perfuração da membrana timpânica através dos anos e pela presença
de exsudato mucocatarral, oriundo da orelha média, drenado através do meato acústico
externo (HUNGRIA, 2000).
A otite média crônica (OMC), segundo Costa & Dornelles (2006a) tem sido classificada em
dois grandes grupos: Otite Média Crônica Simples e Otite Média Crônica supurada.
A Otite média crônica simples é um termo que se aplica àqueles pacientes com perfuração
no tímpano, mas que conseguem deixar a orelha seca, isto é, sem infecção por um longo tempo ou a
infecção é fácil de ser tratada com medicamentos (DORNELLES, 2007). Segundo Hungria (2000) a
otite média crônica simples é quase sempre secundária a uma otite média aguda que se caracteriza
por um grau da moderada intensidade e cessa, geralmente, pela restauração dos tecidos inflamados a
um estado de quase normalidade, mas deixando como seqüela uma perfuração na parte tensa da
membrana do tímpano. O processo infeccioso crônico se restringe ao forro mucoso da orelha média,
em maior ou menor grau de intensidade. A área de infecção mucosa pode estender-se desde a
perfuração timpânica até o orifício faríngeo da tuba auditiva: é a infecção tubotimpânica crônica, a
clássica “otorréia tubária”, alimentada ou agravada pelos processos infecciosos ascendentes das vias
aéreas superiores e cavidades paranasais. No tratamento da otite média simples, todos esses fatores
patogênicos gerais devem ser devidamente tratados, além dos cuidados locais por meio de
curativos, cauterizações de tecido granuloso, instilações de preparos com base em antibióticos, cujo
uso não deve ser prolongado de modo a evitar a resistência bacteriana e, até, aparecimento de novos
germes.
A Otite média crônica supurada, ou seja, aquelas orelhas que mesmo com medicamentos e
cuidados não conseguem ficar sem infecção (supuração) (DORNELLES, 2007) é classificada, por
Costa & Dornelles (2006a) em: Colesteatomatosa e Não colesteatomatosa.
• A Otite média crônica supurada colesteatomatosa tem por definição o acúmulo de
tecido estratificado queratinizado no ouvido médio, o colesteatoma (HUNGRIA, 2000).
O colesteatoma não permite uma orelha saudável e, com seu crescimento outras
estruturas próximas podem ser acometidas (HUNGRIA, 2000). Os sintomas são a supurações
persistentes acompanhada muitas vezes por odor que exala mau cheiro (PIGNATARI & WECKX,
13
1999). A perda de audição e a otorréia são as complicações mais comuns, porém complicações
graves, intratemporais ou intracranianas podem surgir (COSTA & DORNELLES, 2006a).
• A Otite média crônica supurada não colesteatomatosa é mais freqüente em certas
populações e grupos raciais, podendo ocorrer devido à alteração do sistema imune ou
por pouca aeração da mastóide. É também um processo que pode se iniciar através de
uma otite média aguda que sofre uma perfuração e/ou otorréia persistente, lavando assim
a um quadro crônico (COSTA & DORNELLES, 2006b).
O tratamento das otites médias crônicas supuradas, de escolha é cirúrgico. A cirurgia
começa por uma incisão atrás da orelha média por onde se expõe a orelha e a mastóide. Para
realizá-la utiliza-se um microscópio cirúrgico e um micromotor com brocas. Com o micromotor se
limpa toda a doença existente na mastóide (osso atrás da orelha) e se expõe a cavidade timpânica,
local onde estão os ossículos da orelha (martelo, bigorna e estribo). Esta cirurgia se chama
mastoidectomia radical. Nesta cirurgia tem-se que adaptar o conduto auditivo externo tornando-o
maior. Isto se chama meatoplastia.
Um outro tipo de mastoidectomia pode ser feito quando a doença não está tão evoluída.
Chama-se timpanomastoidectomia e é basicamente a mesma cirurgia, porém tenta-se manter o
mecanismo da audição (DORNELLES, 2007).
2.1.4 Prontuários
Também chamado de prontuário do paciente, o prontuário médico é um elemento crucial no
atendimento à saúde dos indivíduos, e deve estabelecer as informações necessárias para garantir a
continuidade dos tratamentos prestados ao paciente. Portanto no local onde o paciente recebe seus
cuidados o prontuário representa o mais importante veículo de comunicação entre os membros da
equipe de saúde responsável pelo atendimento (MASSAD et al, 2003).
Costa (2001) comenta que o prontuário em papel vem sendo usado há milhares de anos, já
desde o tempo de Hipócrates. No século V a.C., Hipócrates estimulou os médicos a fazerem
registros escritos, dizendo que o prontuário tinha dois propósitos: refletir de forma exata o curso da
doença e indicar possíveis causas das doenças (MASSAD et al, 2003). E foi somente após
Hipócrates que a medicina teve sua transição do caráter mitológico para o uso do pensamento
14
lógico científico e o registro médico tornou-se prática entre os adeptos ao pensamento pós-
hipocrático (LOPES, 1999).
Um Prontuário Médico pode ser entendido como (Novaes, 1998; Slee, Slee e Schmidt, 2000;
Ministério da Saúde, 2001 apud COSTA, 2001):
• um conjunto de documentos padronizados, ordenados e concisos, destinados ao registro
dos cuidados médicos e paramédicos prestados ao paciente pelo hospital;
• um conjunto de informações coletadas pelos médicos e outros profissionais de saúde que
cuidaram de um paciente;
• um registro de saúde do indivíduo, contendo toda a informação referente à sua saúde,
desde o nascimento até a morte; e
• um acompanhamento do bem-estar do indivíduo: assistência, fatores de risco, exercícios
e perfil psicológico.
Massad et al (2003) comentam que as informações contidas no prontuário vão auxiliar na
continuidade e na verificação do estado evolutivo dos cuidados da saúde. Pode-se afirmar, portanto
que o sistema de saúde de um país, é determinado graças ao que se tem documentado em forma de
prontuário, pois nele é que são obtidas as informações sobre a saúde dos indivíduos que formam
uma comunidade e uma nação.
Para Van Ginneken e Moorman (1997 apud COSTA, 2001) o prontuário deve ter como
funções:
• suporte a fonte de informação clínica e administrativa para tomada de decisão e meio de
comunicação compartilhado entre todos os profissionais;
• um registro legal das ações médicas;
• suporte à pesquisa: estudos clínicos, epidemiológicos, avaliação da qualidade; e
• deve promover o ensino e gerenciamento dos serviços, fornecendo dados para
cobranças e reembolso, autorização dos seguros, suporte para aspectos organizacionais e
gerenciamento do custo.
15
Segundo Massad et al (2003), ao considerar o conteúdo do prontuário, vale destacar que
todo e qualquer atendimento em saúde pressupõe o envolvimento e a participação de múltiplos
profissionais: médicos, enfermeiros, nutricionistas, psicólogos, fisioterapeutas, entre outros. Além
disso, não raramente, as atividades de atendimento ao paciente acontecem em diferentes locais, tais
como: sala de cirurgia, enfermarias, ambulatórios, unidade de terapia intensiva (UTI), casa de
repouso, etc. Por esses motivos para a realização destas atividades são necessárias múltiplas
informações de diferentes fontes, que garantam a continuidade do processo de cuidado.
Massad et al (2003) defendem a idéia de um modelo tradicional de atendimento à saúde que
tem as seguintes características:
• Maior integração e gerenciamento do cuidado, ou seja, o atendimento tem que ser visto
como um todo, a informação integrada para permitir gerenciar e analisar de forma
contínua os sucessos e fracassos de atenção de saúde;
• Foco no atendimento é o nível primário, entendendo que os hospitais continuam a ser
um centro para diagnóstico e cuidado de problemas complexos e para procedimentos
cirúrgicos e cuidados intensivos. Muitos tratamentos podem e devem ser feitos em locais
com sofisticação tecnológica adequada para o que se pretende atender. Não adianta ter
mais recursos quando estes não são usados. Assim, vale o bom senso e o equilíbrio como
regras e valores orientadores;
• Pagamento do atendimento prestado é dirigido por melhor gerenciamento do processo de
atenção, onde o apropriado é melhor, encorajando a eficiência (custo - benefício) do
atendimento e na utilização de recursos;
• Procedimento médico é baseado na melhor prática, exigindo dos profissionais maior
competência e capacitação do profissional. Requer envolvimento e responsabilidade com
os avanços da profissão e manter-se atualizado é dever de cada profissional; e
• A equipe que atende é interdisciplinar, colaborativa, conduzida por uma organização
horizontal. Não existe um profissional que seja mais importante que outro, uma vez que
todos colaboram para que o paciente se restabeleça. O cliente dos serviços de saúde não
é o médico e sim, o paciente.
Este novo modelo de atendimento utiliza a informação e a integração como elementos
essenciais de organização. Neste aspecto, a estrutura computacional que surge oferecendo solução é
16
o chamado Prontuário Eletrônico do Paciente (PEP), que é uma forma proposta para unir todos os
diferentes tipos de dados produzidos em variados formatos, em épocas diferentes, feitos por
diferentes profissionais da equipe de saúde em distintos locais. Assim deve ser entendido como
sendo a estrutura eletrônica para manutenção de informação sobre o estado de saúde e o cuidado
recebido por um indivíduo durante todo seu tempo de vida (MASSAD et al, 2003).
2.1.5 Prontuário Médico X Prontuário Eletrônico do Paciente
Segundo Martha et al (2006), o PEP vem, cada vez mais, agregando novidades, como a
mobilidade. PDAs ( Personal Digital Assistants ou Assistente Pessoal Digital) e celulares estão cada
dia mais presentes na vida dos profissionais da saúde. A mobilidade é uma característica inerente à
atuação do médico.
O desafio do PEP atual é disponibilizar as informações que ele possui para o profissional da
saúde em qualquer lugar que ele necessite e a qualquer hora. O prontuário em papel apresenta
diversas limitações, tanto práticas como lógicas, sendo ineficiente para o armazenamento e
organização de grande número de dados de tipos diferentes apresentando diversas desvantagens em
relação ao prontuário eletrônico.
Para Costa (2001) são elas: o prontuário pode estar somente num único lugar ao mesmo
tempo, ilegibilidade, ambigüidade, perda freqüente de informação, multiplicidade de pastas,
dificuldade de pesquisa coletiva, falta de padronização, dificuldade de acesso e fragilidade do papel.
Costa (2001) comenta que um prontuário em papel bem estruturado apresenta algumas
vantagens, ainda que contestáveis, em relação ao eletrônico: facilidade para serem transportados,
maior liberdade na forma de escrever, facilidade no manuseio, não requer treinamento especial e
nunca fica “fora do ar”, referindo-se aos computadores.
2.2 Cenário Computacional
2.2.1 Prontuário Eletrônico do Paciente
Segundo Institute of Medicine (IOM, 1997 apud COSTA, 2001), o prontuário eletrônico do
paciente é um registro eletrônico que reside em um sistema especificamente projetado para apoiar
os usuários fornecendo acesso a um completo conjunto de dados corretos, alertas, sistemas de apoio
à decisão e outros recursos, como links para bases de conhecimento médico.
17
Para Computer-based Patient Record Institute define o prontuário eletrônico ressaltando que
um registro computadorizado de paciente é informação mantida eletronicamente sobre o estado de
saúde e os cuidados que um indivíduo recebeu durante toda sua vida (MASSAD et al, 2003).
O prontuário eletrônico é um meio físico, um repositório onde todas as informações de
saúde, clínicas e administrativas, ao longo da vida de indivíduo são armazenadas, e muitos
benefícios podem ser obtidos desde formato de armazenamento. Dentre eles, podem ser destacados:
acesso rápido aos problemas de saúde e intervenções atuais; acesso a conhecimento cientifico
atualizado com conseqüente melhoria do processo de tomada de decisão; melhoria de efetividade do
cuidado, o que por certo contribuiria para obtenção de melhores resultados e atendimento aos
pacientes; possível redução de custos, com otimização de recursos (MASSAD et al, 2003).
Segundo Sittig (1999 apud MASSAD et al, 2003) as vantagens do prontuário em formato
eletrônico são:
• Acesso remoto e simultâneo: vários profissionais podem acessar um mesmo prontuário e
de forma remota. Com a possibilidade de transição via Web, os médicos podem rever e
editar os prontuários de seus pacientes a partir de qualquer lugar do mundo;
• Legibilidade;
• Segurança de dados;
• Confidencialidade dos dados do paciente: o acesso ao prontuário pode ser dado por
níveis diretos dos usuários e este acesso ser monitorado continuamente.
• Flexibilidade de “layout”: o usuário pode usufruir de formas diferentes de apresentação
de dados;
• Integração com outros sistemas de informação: uma vez em formato eletrônico, os dados
podem ser integrados a outros sistemas de informação e bases de conhecimento, sendo
armazenados localmente ou à distância;
• Captura automática de dados: dados fisiológicos podem ser automaticamente capturados
dos monitores, equipamentos de imagens e resultados laboratoriais, evitando erros de
transcrição.
18
• Processamento contínuo dos dados: os dados devem ser estruturados de forma não
ambígua; os programas podem checar continuamente consistência e erros de dados,
emitindo alertas e avisos aos profissionais.
• Assistência à pesquisa: o dado estruturado pode facilitar os estudos epistemológicos;
• Saída de dados diferentes: o dado processado pode ser apresentado ao usuário em
diferentes formatos: voz, imagem, gráfico, impresso, e-mail e outros;
• Relatórios: os dados podem ser impressos de diversas maneiras de acordo com o
objetivo de apresentação; e
• Dados utilizados: por ser integrado, o PEP possui os dados atualizados.
McDonald e Barnett (1990 apud MASSAD et al, 2003) mencionam algumas desvantagens
importantes, são elas:
• Necessidade de grandes investimentos de hardware e software e treinamento;
• Os usuários podem não se acostumar com os procedimentos informatizados;
• Estar atento a resistências e sabotagens;
• Demora para ver o resultado do investimento;
• Sujeito a falhas tanto de hardware quanto de software; sistemas inoperantes por minutos,
horas ou dias que se traduzem em informações não disponíveis; e
• Dificuldade para a completa e abrangente coleta de dados.
Para Costa (2001) um prontuário de papel bem organizado pode ser melhor que um
prontuário informatizado mal estruturado. Mas também é fato que a computação bem empregada
nesse meio supera em qualidade, de forma indiscutível, o prontuário em papel, além de agregar um
número enorme de novos recursos.
2.2.1.1 Prontuário Eletrônico baseado na Web
Costa (2001) comenta que com a evolução dos equipamentos de imagem e sinais, cada vez
mais documentos de mídias diferentes têm sido agregados ao prontuário e, com isso, surgiu o
chamado Registro Médico Multimídia. Com a Internet, a realidade de um registro médico
19
multimídia tornou-se mais evidente e possível, criando-se a figura Prontuário Eletrônico do
Paciente baseado na Web.
O PEP baseado na Web traz outras vantagens em relação ao tradicional, conforme citadas
por Costa (2001): multimídia (gráficos, imagens, vídeo e som), flexibilidade para integração com
outros sistemas e sistemas legados, hipertexto: links para guidelines, jornais e fontes de
conhecimento médico, uso de browsers (baixo custo), mecanismos de visualização e navegação
usualmente mais adaptáveis e mais fáceis de usar, acessibilidade de vários locais, 24h por dia, 7
dias por semana, menor custo de desenvolvimento, comparado a tecnologias como cliente/servidor
ou mainframe; suporte à multiplataforma; facilidade de integração de dados dinâmicos com
documentos estáticos; manutenção centralizada, distribuição imediata;
2.2.2 AURIS
Segundo Heck Junior et al (2006) o software AURIS foi desenvolvido de acordo com as
especificações e requisitos de usabilidade definidos pela equipe do Centro de Otite Média do Brasil,
através da proposta de uma metodologia computacional para fins de desenvolvimento de uma
plataforma de auxílio ao diagnostico otológico. Esta metodologia simplifica os processos de
mensuração da extensão de cada uma das patologias descritas, de maneira a desenvolver métodos
rápidos e simples, sem perda de precisão.
Trata-se de um sistema computacional que não impõe considerável esforço adicional ao
protocolo de aquisição e diagnóstico. O sistema apresenta, a partir de testes preliminares, precisão e
simplicidade de uso.
O software foi concebido sob a forma de Wizard, que é uma execução interativa a qual tem
por função assessorar, passo a passo, o usuário a realizar o trabalho de seleção das áreas e dos
quadrantes.
Os processos anteriores de descrição da perfuração timpânica eram feitos por uma análise
visual e subjetiva do especialista, na qual o mesmo criava uma divisão imaginária dos quadrantes e
marcava os que consideravam afetados, bem como a forma em que se apresentava a perfuração,
podendo esta ser central ou marginal. O especialista então anota essas, dentre outras informações,
que julga necessário em um protocolo.
20
O modelo computacional foi desenvolvido baseado no processamento digital de imagens e
geometria. Nesse modelo, foram utilizadas inicialmente imagens extraídas de videotoscopias
digitais, geradas através de exames otoscópicos. Sendo estas imagens submetidas a alguns
conceitos, que vão desde a reconstrução de uma elipse, até a segmentação por crescimento de
regiões.
O modelo inicia com a seleção e abertura do arquivo contendo a imagem a ser analisada.
Tendo aberto a imagem ou selecionado o quadro de trabalho adequado, no caso de o arquivo for um
vídeo, o especialista então irá para a tela de seleção da região timpânica como mostra a Figura 4.
Figura 4. Tela de seleção do tímpano.
Fonte: Heck et al (2006)
Depois de o usuário selecionar a área do tímpano, o software executa a segmentação da
imagem, preparando a próxima etapa, onde ocorre a seleção da área de perfuração. A perfuração
geralmente possui formato irregular, por isso não é possível estimá-la de forma anatômica, como
ocorre com o tímpano.
Para a seleção da área perfurada, é feito um processo misto de seleção, baseado em um
desenho aproximado do especialista informando onde se encontra a perfuração. A Figura 5 mostra a
tela de seleção com um desenho estimado, feito por um especialista, sobre a área timpânica.
21
Figura 5. Desenho da área aproximada na tela de seleção de perfuração.
Fonte: Heck et al (2006)
Como mostra a Figura 6, o software automaticamente seleciona em uma sobreposição
translúcida na cor vermelha a imagem de trabalho exibindo a área selecionada.
Figura 6. Área selecionada na tela de seleção de perfuração.
Fonte: Heck et al (2006)
22
Depois da seleção das áreas de tímpano total e perfurado, o software inicia o processo de
definição dos quadrantes do tímpano. A Figura 7 mostra o eixo de quadrantes, que é composto de
duas linhas, onde inicialmente uma se encontra na posição horizontal e a outra na posição vertical e
as duas se cruzam no ponto central de cada uma.
Figura 7. Tela de definição dos quadrantes.
Fonte: Heck et al (2006)
De posse das áreas da perfuração e do tímpano, e conhecendo onde exatamente ocorre a
divisão dos quadrantes, o software faz a mensuração dessas áreas. Os resultados são exibidos em
uma tela final exibida na Figura 8, onde se encontra alguns outros recursos, tanto visuais para
aplicar à imagem resultante, quanto para salvar os resultados.
23
Figura 8. Tela final exibindo resultados da mensuração.
Fonte: Heck et al (2006)
A metodologia proposta mostrou, através do software desenvolvido e utilização inicial, uma
solução simples e prática à mensuração de perfurações timpânicas. Cada um dos passos do processo
é aplicado através de uma pequena interação com o usuário.
2.2.3 Plataforma de Desenvolvimento Web
Segundo Welling & Thomson (2003) o PHP é uma linguagem de desenvolvimento escrita
por desenvolvedores Web para desenvolvedores Web. PHP significa, PHP: Hypertext
Preprocessor.
Segundo Converse & Park (2003), Rasmus Lerdorf engenheiro de software, membro da
equipe Apache e o homem internacional do mistério – é o criador e a força propulsora original por
trás do PHP, a primeira parte do PHP foi desenvolvida para sua utilização pessoal no final de 1994.
No ano seguinte, ele montou um pacote chamado de Personal Home Page Tools, também
conhecido como PHP Construction Kit, em resposta à demanda de usuários que por acaso ou por
indicações deparavam-se com o seu trabalho. A versão 2 do PHP foi logo lançada sob o título do
PHP/FI e incluía o Form Interpreter, uma ferramenta para analisar sintaticamente consultas de SQL
(CONVERSE & PARK, 2003).
24
Welling & Thomson (2003) comentam que com as adições de Zeev Suraski e Andi
Gutmans, dois programadores israelenses pertencentes ao Technion, o Instituto Israelense de
Tecnologia, que desenvolveram os analisadores de sintaxe do PHP3 e do PHP4, era lançada em
1997 a versão 3 do PHP, primeira versão estável e parecida com a linguagem atual e que já era
utilizada por aproximadamente 50 000 sites. Também generalizaram e estenderam seus trabalhos
sob a rubrica de Zend.com.
Segundo Converse & Park (2003) o quarto trimestre de 1998 deu início a um período de
crescimento explosivo para o PHP, quando todas as tecnologias de código-fonte aberto ganharam
publicidade maciça. Em outubro de 1998, de acordo com a melhor suposição, mais de 100.000
domínios utilizavam o PHP de alguma forma. Apenas um ano depois, o PHP quebrou a marca de
um milhão de domínios e na primeira metade do ano 2000 com a versão 4ª versão do PHP, o
número tinha aumentado para quase dois milhões de domínios. Em outubro de 2002, já era utilizado
em mais de 9 milhões de domínios (WELLING & THOMSON, 2003). Em 2004 veio à nova versão
do PHP, o PHP5, onde a principal mudança foi uma nova API ( Application Programming Interface
ou Interface de Programação de Aplicativos) para orientação a objetos provida pelo Zend Engine 2
(PHP.NET, 2007). Atualmente como mostra a Figura 9 o PHP é utilizado por mais de 20 milhões
de domínios em todo o mundo.
Figura 9. Quantidade de domínios que utilizam PHP
Fonte: PHP.NET (2007)
25
O PHP é uma linguagem de criação de scripts do lado servidor que foi projetada
especificamente para a Web. Dentro de uma página HTML (HiperText Markup Language ou
Linguagem de Marcação de Hipertexto), você pode embutir código de PHP que será executado toda
vez que a página for visitada. O código PHP é interpretado no servidor Web e gera HTML ou outra
saída que o visitante verá (WELLING & THOMSON, 2003).
Segundo Welling & Thomson (2003) o Perl, Microsoft Active Server Pages (ASP), Java
Server Pages (JSP) e Allaire ColdFusion são alguns dos principais concorrentes do PHP, e em
comparação a esses produtos, o PHP tem muitas vantagens, como: alto desempenho, interfaces para
muitos sistemas diferentes de banco de dados, bibliotecas integradas para muitas tarefas comuns da
Web, baixo custo, portabilidade e disponibilidade de código fonte.
• Desempenho – O PHP é surpreendentemente veloz em sua execução, especialmente
quando compilado como módulo Apache no Unix (CONVERSE & PARK, 2003).
Welling & Thomson (2003) comentam que os benchmarks publicados pela empresa
Zend Technologies (http://www.zend.com), mostram o PHP superando o desempenho
dos concorrentes.
• Integração com banco de dados – O PHP tem conexões para muitos sistemas de banco
de dados como: MySQL, PostGreSQL, mSQL, Oracle, dbm, filePro, HyperWave,
Informix, Interbase e Sybase, entre outros. Utilizando o Open Database Connectivity
Standard (OBDC), você pode conectar-se a qualquer banco de dados que forneça um
drive OBDC (WELLING & THOMSON, 2003).
• Bibliotecas integradas – Segundo Welling & Thomson (2003) como o PHP foi
projetado para utilização na Web, ele tem muitas funções integradas para realizar muitas
tarefas úteis relacionadas a Web. Como por exemplo, gerar imagens, conectar-se a
outros serviços de rede, enviar e-mail, trabalhar com cookies e gerar documentos PDF,
tudo com apenas algumas linhas de código.
• Custo – Welling & Thomson (2003) comentam que o PHP é gratuito.
• Portabilidade – Segundo Welling & Thomson (2003), o PHP está disponível para
muitos sistemas operacionais diferentes, tais como sistemas operacionais do tipo Unix
gratuito como o Linux e o FreeBSD, versões comerciais do Unix como o Solaris e IRIX,
ou em versões diferentes do Microsoft Windows. Converse e Park (2003) comentam que
26
o PHP é compatível com os três mais importantes servidores Web, o Apache http Server
para Unix e Windows, o Microsoft Internet Information Server e o Netscape Enterprise
Server, também conhecido como iPlanet Server.
• Código-fonte - Welling & Thomson (2003) comentam é um produto Open Source, ou
seja, significa que você tem acesso ao código-fonte.
2.2.4 Banco de dados
O banco de dados utilizado para desenvolver este trabalho terá como propósito armazenar os
todos dados dos pacientes, desde os dados demográficos até informações dos diversos protocolos
referentes a otologia, para tal será utilizado o banco de dados PostgreSQL.
O sistema gerenciador de banco de dados objeto-relacional hoje conhecido por PostgreSQL,
é derivado do pacote POSTGRES escrito na Universidade da Califórnia em Berkeley. Com mais de
uma década de desenvolvimento, o PostgreSQL é atualmente o mais avançado banco de dados de
código aberto disponível.(OLIVEIRA, 2007).
Para Alecrim (2006) o Sistema Gerenciador de Banco de Dados (SGDB) PostgreSQL teve
seu início na Universidade de Berkeley, na Califórnia, em 1986. Na época, um programador
chamado Michael Stonebraker liderou um projeto para a criação de um servidor de banco de dados
relacionais chamado Postgres, oriundo de um outro projeto da mesma instituição denominado
Ingres. Essa tecnologia foi então comprada pela Illustra, empresa posteriormente adquirida pela
Informix. Porém, mesmo diante disso, dois estudantes de Berkeley, Jolly Chen e Andrew Yu,
compatibilizaram o Postgres à linguagem SQL (Structured Query Language ou Linguagem de
Consulta Estruturada). Este projeto recebeu o nome de Postgres95. Em 1996, quando o projeto
estava estável, o banco de dados recebeu o nome de PostgreSQL.
Oliveira (2007) comenta que o PostgreSQL é um SGBD objeto-relacional de código aberto,
é extremamente robusto e confiável, além de ser extremamente flexível e rico em recursos. Ele é
considerado objeto-relacional por implementar, além das características de um SGBD relacional,
algumas características de orientação a objetos, como herança e tipos personalizados.
O PostgreSQL é um banco de dados relacional e orientado a objetos. Um de seus atrativos é
possuir recursos comuns a banco de dados de grande porte, o que o deixa apto a trabalhar, inclusive,
27
com operações de missão crítica. Além disso, trata-se de um banco de dados versátil, seguro,
gratuito e de código aberto. (ALECRIM. 2006).
Para Oliveira (2007) o PostgreSQL é um programa distribuído sob a licença BSD ( Berkeley
Software Distribution), o que torna o seu código fonte disponível e o seu uso livre para aplicações
comerciais ou não.
Entre suas características, Alecrim (2006) comenta:
• Compatibilidade multi-plataforma, ou seja, pode ser executado em vários sistema
operacionais, como Windows, Mac OS X, Linux e outras variantes de Unix;
• Possui compatibilidade com várias linguagens, entre elas, Java, PHP, Python, Ruby, e
C/C++;
• Sua base de dados é de tamanho ilimitado, com tabelas com tamanho de até 32 TB;
• Quantidade de linhas de até 1.6 TB ilimitada;
• Campos de até 1 GB;
• Suporte a recursos como triggers, views, stored procedures, SSL (Secure Sockets
Layer), MVCC (Multiversion Concurrency Control ou Controle de Concorrência
Multiversões), schemas, transactions, savepoints, referential integrity e expressões
regulares; e
• Instruções em SQL, como indica o nome.
Estas vantagens apresentadas mostram que o PostgreSQL é apropriada para o
armazenamento das informações deste sistema de software.
2.2.5 Protocolação digital
A parte de protocolação a que se refere este trabalho será fornecido pela empresa BRy
Tecnologia através do Produto BRy PDDE (Protocoladora Digital de Documentos Eletrônicos).
Segundo BRy Teconologia (2007) a PDDE permite estabelecer uma âncora temporal à um
documento eletrônico. Isso pode ser utilizado para comprovar que um documento existia em uma
determinada data e não foi alterado deste então.
28
A protocoladora é um servidor de confiança que possibilita a garantia de entrega e
recebimentos de documentos como petições, protocolos, memorandos, circulares, comunicados,
exames, atestados, todos se mantendo eletronicamente. (BRY TECNOLOGIA, 2007).
A BRy PDDE garante a segurança nas transações eletrônicas, fornecendo meios de verificar
se um documento se mantém integro ou não desde o momento de sua protocolação.
BRy Tecnologia (2007) comenta que através do método chamado Método de Árvore
Sincronizada, a protocoladora implementa um algoritmo de datação e numeração seqüencial
inviolável, único no mundo, combinando data/hora com o encadeamento dos eventos/documentos,
tornando impossível fraudar o tempo e a relação de precedência entre eles, constituindo-se num
provedor de confiança com múltiplas funções, tais como: Integridade, irretroatividade, privacidade,
auditoria, hora legal brasileira, não-repúdio e verificação.
É um sistema computacional de usos especifico, instalado em um computador de alta
segurança e que presta o serviço de autenticar documentos eletrônicos. Esse sistema pode estar
instalado em uma empresa ou em um provedor de serviços. Opera respondendo a requisições de
assinatura digital e carimbo de tempo realizado por aplicações locais e remotas (BRY
TECNOLOGIA, 2007).
Segundo BRy Tecnologia (2007) a BRy PDDE é um sistema protocolador que garante a
existência de um documento eletrônico de forma totalmente confiável. Utiliza certificados digitais
ICP-Brasil, fonte externa para sincronismo de tempo de serviço de auditoria do sincronismo de
tempo fornecido pelo Observatório Nacional do Ministério de Ciências e Tecnologia.
3 DESENVOLVIMENTO
Com base nos objetivos do presente projeto deste TCC, este capítulo apresenta o modelo de
desenvolvimento para uma metodologia computacional que foi avaliada por um protótipo de
software web para auxiliar os especialistas da área médico otológica no seu dia-a-dia.
Para o desenvolvimento da metodologia computacional, foi primeiramente definida, através
de um planejamento, a seqüência de passos que seriam executados a fim de atingir o objetivo que
era a criação desta metodologia e sua avaliação através de um protótipo. Foi criada então uma
estrutura Bottom up apresentada na Figura 10, onde as atividades de base criariam aparatos
necessários à execução das demais atividades.
As três primeiras etapas da estrutura são compostas por: 1) planejamento, 2) levantamento
de requisitos e 3) modelagem; que definem a metodologia computacional, e as etapas 4) protótipo
PHP e 5) avaliação referem-se ao desenvolvimento do protótipo de software que visa avaliar a
metodologia proposta.
Figura 10. Estrutura bottom-up
Também para desenvolvimento da metodologia proposta para otologia foi utilizado como
base para o processo de desenvolvimento de software o modelo intitulado ICONIX. Bona (2002)
afirma que a metodologia ICONIX não é formada por um processo tão burocrático quanto ao
processo de desenvolvimento RUP - Rational Unified Process (ou Processo Unificado da Rational),
ou seja, não gera excesso de documentação. Sua pratica é simples, comparada com o Extreme
Programming (XP), tendo boa ênfase no processo de analise de software.
Para o modelo ICONIX é utilizado um conjunto mínimo de elementos UML, aplicando
somente para a modelagem os problemas mais comuns e caso necessário, outros elementos da UML
podem ser incorporados para auxiliar na modelagem (BONA, 2002).
30
O processo no ICONIX é dividido em dois grandes setores que podem ser implementados
paralelamente e recursivamente: modelo estático e modelo dinâmico. O modelo estático é formado
pelos diagramas de domínio e diagrama de classe, destinados à modelagem do funcionamento do
sistema. O modelo dinâmico detalha o usuário interagindo com o sistema através de ações (MAIA,
2006).
Neste trabalho fez-se o uso do diagramas de classes para o modelo estático e o diagrama de
casos de uso para o modelo dinâmico.
3.1 Planejamento
Durante a etapa de planejamento foram definidos os passos para o desenvolvimento e suas
respectivas datas. Nesta etapa foi também previsto o escopo do projeto, delimitando as
funcionalidades gerais do sistema e áreas afetadas do Com.Br.
Na definição das primeiras funcionalidades, foi então levantado que a metodologia pode ser
desenvolvida sobre qualquer plataforma, principalmente a Web. Ainda foram definidas também as
exigências quanto à segurança, sigilo, autenticidade e integração com o sistema de mensuração. No
que tange à segurança e o sigilo, observou-se que um usuário só deve ter acesso às informações
somente mediante o seu usuário e senha. No quesito autenticidade dos dados, foi sugerida que as
informações sejam protocoladas através de uma assinatura digital. Este processo torna esta
informação em um documento judicialmente válido. A forma que esta protocolação pode ocorrer
através de uma protocoladora PDDE é explicada na Seção 2.2.5 deste trabalho.
Também é importante ressaltar que esta metodologia deve ser preparada para integração
com o sistema de mensuração, bem como a integração com outros sistemas que possam oferecer
algum beneficio aos especialistas.
A seguir são apresentados os requisitos que foram identificados junto aos especialistas do
Hospital das Clinicas de Porto Alegre.
3.2 Levantamento de requisitos
Inicialmente através de reuniões com os especialistas do Hospital de Clínicas de Porto
Alegre, foi feito o levantamento do processo de negócio (Figura 11) para se capturar o vocabulário
por esses utilizado, visando à descoberta dos atores e casos de uso do sistema. Observou-se que este
31
processo de negócio é composto por diversos protocolos já utilizados pelos especialistas de forma
não automatizada.
Figura 11. Processo do negócio.
O grupo de pesquisa do HCPA recebe pacientes com otite média crônica virgem de
cirurgias. Atualmente é mantido o acompanhamento dos pacientes com protocolos preenchidos (em
papel) e arquivados em uma pasta para cada paciente. Em cada consulta de acompanhamento o
especialista separa a pasta do paciente para o registro das novas avaliações e comparação com as
anteriores.
No acompanhamento com o paciente os especialistas têm os seguintes protocolos que
podem ser preenchidos:
32
Protocolo de primeira consulta
O protocolo de primeira consulta é protocolo de inclusão do paciente no ambulatório de
pesquisa, constam nele os dados demográficos, clínicos e físicos do paciente. Este protocolo é
composto de 157 variáveis. Partes dessas variáveis, em alguns casos, podem ser preenchidas na
segunda consulta, pois algumas variáveis são provenientes da filmagem do tímpano que
dependendo da disponibilidade do aparelho podem ou não ser realizadas na primeira consulta.
Nesta etapa está inserido o uso do sistema AURIS (que mensura a perfuração timpânica,
utilizando a imagem obtida através da filmagem), pois parte das variáveis provém desta análise.
No caso de fenda platina, é preenchido um formulário diferenciado, mas que possui os
mesmos objetivos ( Mais detalhes ver Anexo I).
Protocolo de audiometria
O protocolo de audiometria é um exame de estado auditivo, é realizado sempre na primeira
consulta e depois anualmente até a cirurgia, no pós-cirúrgico realiza a primeira três meses após a
cirurgia e depois também anualmente.A audiometria gera dois gráficos, um para cada orelha. Cada
gráfico contempla a análise aérea e a análise óssea. Para cada análise, são utilizadas simbologias
especiais. A partir da curva gerada neste gráfico, é possível identificar o grau da perda auditiva e o
tipo de perda.
A digitalização deste protocolo traria diversas vantagens ao especialista, pois o gráfico
poderia ter diferenças de cores entre os níveis auditivos facilitando a visualização do seu grau.
A audiometria é realizada para avaliar a evolução auditiva do paciente, sendo que isso hoje é
avaliado visualmente. Com os gráficos digitalizados seria possível gerar um gráfico evolutivo do
paciente.
A timpanometria gera um gráfico definido por três variáveis (volume, complacência e
pressure) de acordo com a curva gerada neste gráfico, ela é classificada em A, B, C.
A audiometria vocal gera uma tabela com oito variáveis.
33
Protocolo pré-operatório
O protocolo de revisão pré-operatória é um protocolo de acompanhamento do paciente já
incluindo no ambulatório até que ele realize a cirurgia, a periodicidade (semana, mensal, bimestral,
semestral, anual) das consultas dependerá do quadro clínico do paciente, que será acompanhado por
este protocolo até a data da cirurgia. Nesta consulta é necessário o preenchimento do protocolo que
contém 10 variáveis. É possível que sejam realizadas diversas consultas pré-operatórias, pois hoje a
fila de espera para a operação está entre um e dois anos, e o acompanhamento deve ser realizado a
cada três meses. Ver protocolo Anexo II.
Protocolo de descrição cirúrgica
Protocolo de descrição cirúrgica e um protocolo que contem a descrição dos procedimentos
trans-operatórios. No ato da cirurgia, este protocolo deve ser preenchido. Ele contém 62 variáveis
conforme apresentado com maiores detalhes no Anexo III.
Protocolo pós-operatório
Protocolo de revisão pós-operatória trata o acompanhamento do paciente após a cirurgia,
obrigatoriamente acontece no 7º, 14º e 21º dias após a cirurgia e quantas mais vezes forem
necessárias, a periodicidade (semana, mensal, bimestral, semestral, anual) das consultas dependerá
do quadro clínico do paciente, o paciente será acompanhado neste protocolo pelo resto da vida. Se
ele realizar outra cirurgia receberá mais um protocolo, serão tantos protocolos pós-cirúrgicos
quantas forem as cirurgias realizadas. Este documento a ser preenchido durante consulta de retorno
da cirurgia, contendo 12 variáveis (vide Anexo IV).
A partir dessas informações, foram feitos os levantamentos dos requisitos entre funcionais e
não funcionais. Com estes requisitos foi possível definir melhor cada uma das funcionalidades da
metodologia construída e conhecer melhor as características do problema a ser tratado.
A seguir é apresentada a definição dos requisitos funcionais e não-funcionais para o sistema.
3.2.1 Definição dos requisitos
O objetivo desta etapa é definir os requisitos funcionais (recursos desejados para o sistema)
e não-funcionais (qualidades necessárias ao sistema), sendo que os requisitos podem ou não gerar
um caso de uso do sistema.
34
3.2.1.1 Requisitos Funcionais
A seguir tem-se a lista de requisitos funcionais definidos para o portal. Estes requisitos
foram definidos junto aos especialistas e orientadores e revisados pelos mesmos. Nos requisitos de
números 6,7,8,9 e 10 onde tem-se “manter” deve-se ler “Incluir/Alterar/Consultar”.
• RF001 - O portal deve permitir acesso somente com login e senha;
• RF002 - O portal deve permitir consulta dos prontuários;
• RF003 - O portal deve permitir a alteração dos dados demográficos;
• RF004 - O portal deve permitir o cadastro de novos usuários;
• RF005 - O portal deve permitir o cadastro de novos pacientes;
• RF006 - O portal deve permitir manter o protocolo de primeira consulta;
• RF007 - O portal deve permitir manter o protocolo de revisão pré-operatória;
• RF008 - O portal deve permitir manter o protocolo de descrição cirúrgica;
• RF009 - O portal deve permitir manter o protocolo de revisão pós-operatória;
• RF010 - O portal deve permitir manter o protocolo de audiometria;
• RF011 - O portal deve permitir armazenar arquivos multimídia;
• RF012 - O portal deve permitir o envio do prontuário via e-mail;
• RF013 - O portal deve permitir exportar arquivos no formato CSV - Campos Separados
por Vírgulas;
• RF014 - O portal deve permitir que outros sistemas enviem dados para armazenar;
• RF015 - O portal deve permitir a consulta de pacientes;
3.2.1.2 Requisitos Não Funcionais
Durante o levantamento de requisitos efetuado junto aos especialistas, identificaram-se os
seguintes requisitos não-funcionais que devem ser considerados dentro do contexto deste trabalho.
São estes:
• Confiabilidade: O sistema deve estar disponível 24 horas por dia, 7 dias por semana.
35
• Desempenho: Dever ser o mais estável possível, considerando que o sistema terá uso
diário por parte dos médicos. Isso também pode ser limitado pela velocidade de conexão
a Internet que o usuário possua.
• Segurança: O sistema deve fornecer controle de acesso por login e senha. Deve ser um
tópico bem estruturado, de forma a impedir o vazamento de qualquer informação do
sistema a pessoas não autorizadas.
• Ambiente: O sistema pode ser utilizado em qualquer ambiente, desde que esse possua
um computador com acesso a Internet e um navegador para acessar a URL - Uniform
Resourse Locator do sistema.
• Usabilidade: O sistema deve exibir vídeos no formato flash stream.
• Software: O sistema deve ser implementado em PHP. Os dados do sistema devem ser
guardados do banco de dados PostgreSQL. Os dados dos protocolos devem usar
protocolação digital.
3.3 Funcionalidades do Portal
Segundo a metodologia proposta por este TCC, o Portal é composto das seguintes
funcionalidades:
• Cadastro de novos usuários, estes podem ser especialistas, pacientes ou administradores;
• Atualização dos dados dos pacientes;
• Listagem dos pacientes;
• Consulta de pacientes;
• Cadastrar, listar e atualizar os protocolos, estes podem ser protocolo de primeira
consulta, protocolo de audiometria, protocolo de revisão pré-operatória, protocolo de
descrição cirúrgica e protocolo de revisão pós-operatória;
3.4 Modelagem
A partir dos requisitos funcionais e não funcionais, foi iniciado o processo de modelagem da
metodologia. Diagramas de casos de uso, diagramas de classes e diagramas de banco de dados.
Todos os diagramas foram criados dentro dos padrões UML 2.0.
36
Para o desenvolvimento da modelagem da metodologia aqui proposta foi usada à ferramenta
CASE Enterprise Architect na versão 6.1.
3.4.1 Casos de Uso
Para o desenvolvimento dos casos de uso primeiro foram definidos os atores do sistema.
• Paciente: é o elemento principal num prontuário. Neste armazena-se todas as
informações de saúde sobre o indivíduo.
• Especialista: é um dos principais usuários do sistema. Pode armazenar informações de
vários pacientes, além de poder cadastrar novos usuários para o sistema.
• Sistema Externo: qualquer elemento computacional externo que irá interagir com o
sistema (trocar informações).
Na seqüência é apresentada uma breve descrição dos casos de usos encontrados para o
sistema a partir dos requisitos exigidos, onde cada caso de uso pode estar associado a um ou mais
requisitos.
• Acesso ao Sistema: utilizado quando qualquer usuário for acessar o sistema;
• Cadastrar Novos Pacientes: o médico poderá acrescentar novos pacientes a sua lista
para que assim possa manter os prontuários destes pacientes;
• Cadastrar Novos Usuários: requisita a entrada dos dados básicos para o cadastro do
usuário no sistema. É importante a identificação do tipo de usuário: médico ou paciente;
• Entrada de dados Demográficos: manutenção dos dados demográficos: nome,
endereço, documentos entre outros;
• Registro de Protocolos: manutenção da lista de protocolos do paciente;
• Obter dados do Paciente: o sistema disponibiliza os dados do prontuário do paciente;
• Recebe Informações de Outros Sistemas: o sistema recebe mensagens (arquivos) de
outros sistemas para armazenar informações no prontuário do paciente;
• Seleciona o Paciente: o médico pode selecionar os pacientes de uma lista ou através de
mecanismos de busca (por nome, etc.) para então acessar o prontuário;
• Verifica Login e Senha: verificação se o login e senha informados estão corretos; e
37
• Visão resumida do Prontuário: um resumo do prontuário, somente com os dados
principais do paciente, é disponibilizado, com a opção via e-mail, ser enviado para outro
médico, e também com a opção de exportar os dados para arquivos no formato CSV
(Campos Separados por Vírgulas);
Os casos de uso com maiores detalhes, incluindo seus fluxos podem ser visto no Anexo V,
na qual esse anexo está formatado de acordo com os padrões de desenvolvimento do Grupo
Cyclops.
3.4.2 Diagrama de classes
A seguir é apresentado à modelagem de classes utilizadas na implementação deste sistema.
A Figura 12 mostra o diagrama de classes do Portal. No diagrama de classes é possível observar que
todo especialista ou paciente é um usuário que consequentemente é uma pessoa. Pode-se observar
também que todas as entidades dos protocolos possuem uma entidade pai “protocolo”, que possui
os atributos comuns a todos os protocolos, como data do protocolo, número do protocolo, dentre
outros. Essa entidade também depende das classes especialista e paciente.
Pode-se observar também neste diagrama que todas as entidades protocolos fazem uso de
diversas entidades auxiliares, algumas dessas são usadas por mais de um protocolo.
• Pessoa: entidade que contém os atributos comuns ao especialista e ao paciente;
• Usuário: entidade que herda os atributos de pessoa e contém atributos como login e
senha;
• Especialista: entidade que herda os atributos de pessoa, usuário e tem atributos
específicos do especialista como número do conselho, instituição, dentre outros;
• Paciente: entidade que herda os atributos de pessoa, usuário e tem atributos específicos
do paciente;
• Protocolo: entidade que depende das entidades especialista e paciente e também tem
atributos comuns a todos os protocolos;
• Primeira consulta, pré-operatório, descrição cirúrgica e pós-operatório: todas entidades
que contem os atributos do protocolo referente ao seu nome, estas entidades fazem o uso
de várias entidades auxiliares para completarem todos os atributos do protocolo;
38
Com o protocolo de classes definido foi então dado inicio a modelagem do diagramas de
banco de dados apresentado na próxima seção deste trabalho.
Figura 12. Diagrama de Classes.
39
3.4.3 Diagrama de Banco de dados
A seguir é apresentado o diagrama de banco de dados e a especificação de algumas
entidades. Devido o diagrama ser um pouco extenso, para um melhor entendimento do mesmo, ele
será apresentando em partes, estas divididas de acordo com os protocolos que foram automatizados.
O banco de dados foi modelado usando a ferramenta EMS Manager (Postgres).
Figura 13. Entidades pessoa, usuário, especialista e paciente.
A Figura 13 apresenta o diagrama com as entidades Pessoa, Usuário, Especialista e Paciente,
essas entidades contem os dados dos usuários do Portal. Onde, todo especialista ou paciente é um
usuário que obrigatoriamente é uma pessoa.
A seguir é apresentada a modelagem de cada um dos protocolos separados. Todos os
protocolos fazem relação com a entidade Protocolo (Figura 14), que é a entidade que se relaciona
com paciente, especialista, e também possui dados como número do protocolo e data do protocolo.
Figura 14. Entidade protocolo.
Durante o processo de modelagem verificou-se que muitos dos campos dos protocolos eram
preenchidos com alternativas sim ou não, deste modo esses campos foram agrupados em entidades
auxiliares, tornando-os registros dessas entidades. Como exemplo, tem se a entidade queixas, que é
40
utilizada nos protocolos de primeira consulta, protocolo de revisão pré-operatória e protocolo de
revisão pós-operatória. A Figura 15 mostra como os campos são preenchidos:
Figura 15. Dados queixa.
Sendo assim a entidade queixas foi criada com dois campos:
• id_queixa: identificador seqüencial da queixa; e
• de_queixa: descrição da queixa.
Assim essa entidade é relacionada com os protocolos que fazem uso dela e, se
posteriormente, precisar adicionar uma nova queixa é feito somente um novo registro na entidade,
não precisando modificar nada na aplicação do Portal. O que não ocorreria se cada queixa fosse um
campo da entidade, toda vez que precisasse inserir uma nova queixa teria que criar um novo campo
na entidade, o que conseqüentemente afetaria na aplicação do Portal.
Desse modo foram modeladas várias outras entidades, conforme são apresentadas nos
diagramas.
Também no processo de modelagem dos protocolos foram identificadas entidades que
poderiam ser utilizadas em mais de um protocolo, são elas:
• anamnese: relaciona com o protocolo de primeira consulta e com o protocolo de revisão
pré-operatória e possui dados como se possui otorréia, intensidade de perda auditiva,
dentre outros;
• queixas: relaciona com o protocolo de primeira consulta, com o protocolo de revisão
pré-operatória e com o protocolo de revisão pós-operatória, e possui dados das queixas
como otorréia, zumbido;
• acumetria: relaciona com o protocolo de primeira consulta e com o protocolo de revisão
pós-operatória e possui dados como variação da via aérea;
41
O protocolo de primeira consulta, como mostra a Figura 16, foi dividido em 14 partes:
Figura 16. Modelagem do protocolo de primeira consulta.
• primeira_consulta_anamnese: mantém as anamneses referentes ao protocolo preenchido;
• primeira_consulta_queixas: mantém as queixas referentes ao protocolo preenchido;
• primeira_consulta_acumetria: mantém as acumetrias referentes ao protocolo preenchido;
• revisao_sistemas: entidade auxiliar que mantém os dados das revisões de sistemas, como
uso de fumo, uso de álcool, dentre outros;
• primeira_consulta_revisao_sistemas: mantém as revisões de sistemas referentes ao
protocolo preenchido;
• primeira_consulta: mantém os dados do protocolo;
• hmp: entidade auxiliar que mantém os dados das hmp do sistema, como por exemplo, se
possui alergias, se já fez alguma cirurgia otológica;
• primeira_consulta_hmp: mantém as hmps referentes ao protocolo preenchido;
• diagnostico_patogenese: entidade auxiliar que mantém os dados dos diagnósticos
patogêneses;
• primeira_consulta_diagnostico_patogenese: mantém os diagnósticos patogêneses
referentes ao protocolo preenchido;
42
• otoscopia: entidade auxiliar que mantém os dados das otoscopias do sistema;
• primeira_consulta_otoscopia: mantém as otoscopias referentes ao protocolo preenchido;
• historico_familiar: entidade auxiliar que mantém os dados do histórico familiar do
sistema, como por exemplo se possui surdez; e
• primeira_consulta_historico_familiar: mantém os históricos familiares referentes ao
protocolo preenchido;
O protocolo de revisão pré-operatória (Figura 17) foi dividido em três entidades:
• pre_operatorio: mantém os dados principais do protocolo;
• pre_operatorio_anamnese: mantém as anamneses referentes ao protocolo preenchido; e
• pre_operatorio_queixas: mantém as queixas referentes ao protocolo preenchido.
Figura 17. Modelagem do protocolo de revisão pré-operatória.
O protocolo de descrição cirúrgica apresentado na Figura 18 foi dividido em nove
entidades:
• descricao_cirurgica: mantém os dados principais do protocolo;
• situacao: entidade auxiliar que mantém diversas situações da cadeia ossicular, como por
exemplo se está ausente, deslocada;
• ossiculos: entidade auxiliar que mantém os ossículos da orelha;
• colestetoma: entidade auxiliar que mantém os colestetomas que podem ser encontrados
para o protocolo;
43
• achados_trans_cirurgicos: entidade auxiliar que mantém os achados trans-cirúrgicos
encontrados para o protocolo como por exemplo tubo de ventilação;
• tecnica_cirurgica: entidade auxiliar que mantém as técnicas cirúrgicas aplicadas durante
a cirurgia;
• descricao_cirurgica_ossiculos_situacao: mantém para o protocolo o ossículo e qual
situação foi tomada durante o preenchimento do protocolo;
• descricao_cirurgica_colestetoma: mantém quais os colestetomas o protocolo possui; e
• descricao_cirurgica_achados: mantém quais achados o protocolo possui.
Figura 18. Modelagem do protocolo de descrição cirúrgica.
O protocolo de revisão pós-operatória foi dividido em cinco entidades na qual é
apresentado na Figura 19:
• pos_operatorio: mantém os dados principais do protocolo;
• sutura_retroauricular: entidade auxiliar que mantém as suturas retroauriculares;
• pos_operatorio_acumetria: mantém as acumetrias encontradas para o protocolo;
• pos_operatorio_sutura_retroauricular: mantém as suturas retroauriculares referentes ao
protocolo; e
• pos_operatorio_queixas: mantém as queixas referentes ao protocolo preenchido.
44
Figura 19. Modelagem do protocolo de revisão pós-operatória.
3.5 Protótipo PHP
Esta seção do trabalho mostra como foi feito a implementação das interfaces do protótipo, e
foi dividida em duas partes, a primeira explicando como foi desenvolvido o layout do Portal e a
segunda como foi implementado o protótipo, ou seja, como foi à divisão dos arquivos.
3.5.1 Layout do protótipo
A fim de atender os especialistas com uma interface amigável, ou seja, de fácil navegação
para os especialistas, o layout do protótipo, ou seja, o desenho das interfaces do portal foi
desenvolvido pela equipe de design do grupo Cyclops utilizando conceitos de ergonomia e
qualidade.
Após o desenho das interfaces se deu inicio à adequação das interfaces ao Portal, ou seja,
começou-se o processo de adequar as interfaces no formato de imagens para as interfaces
implementadas em arquivos no formato PHP para que estes já integrassem as funções necessárias
para a implementação do protótipo.
3.5.2 Implementação do protótipo
Nesta etapa explica-se como foi feita à implementação do protótipo.
45
Para um melhor entendimento e facilitação no caso de futuras manutenções, os arquivos
foram divididos em diretórios, na qual cada diretório é especificamente o que o arquivo deve fazer,
esses diretórios foram classificados em:
• _class: contém os arquivos das entidades do portal
• _configuracao: contém os arquivos de configuração de conexão ao banco de dados e
estilos css do Portal;
• _crtl: contém os arquivos que possuem as funções de acesso as classes do portal, além
de serem responsáveis pelas inserções, consultas e atualizações no banco de dados.
• _form: contém os arquivos de intefaces dos formulários, como: usuários, protocolos de
primeira consulta, revisão pré-operatória, descrição cirúrgica, revisão pós-operatória.
• _js: contém os arquivos que fazem as validações javascript do portal
• _list: contém os arquivos que fazem a listagem de dados, como por exemplo: lista de
pacientes, lista de protocolos de revisão pré-operatória.
• _save: contém arquivos que fazem chamadas para executar alguma ação de inserção e
atualização no banco de dados, sendo que estas ações são feitas pelos arquivos que se
encontram no diretório _ctrl.
• images: cotém os arquivos que são imagens do portal
3.6 Cronograma planejado X Cronograma executado
A seguir são apresentados os cronogramas feitos para o TCC I e II sendo a parte cinza o
cronograma planejado e a parte em azul o cronograma executado.
Cronograma de desenvolvimento para o TCC I
Atividade 03 / 07 04 / 07 05 / 07 06 / 07 07 / 07 1.1 planejado x X X X x X X X x X X x x x x X x x x X
1.1 executado x x X X X x X X x x x x X x x x X
1.2 planejado
1.2 executado
1.3 planejado
1.3 executado
2.1 planejado
2.1 executado
46
2.2 planejado
2.2 executado
5.1 planejado
5.1 executado
Lista de Atividades no TCC I:
• 1.1. Pesquisar e analisar soluções similares.
• 1.2. Determinar os requisitos exigidos pelo sistema.
• 1.3. Pesquisar os conceitos e tecnologias necessários à implementação do sistema.
• 2.1 - Realizar a Análise do Portal de Informações de Otologia
• 2.2 - Realizar o Projeto do Portal de Informações de Otologia
• 5.1 - Redigir o texto do TCC I
Cronograma de desenvolvimento para o TCC II Atividade 08 / 07 09 / 07 10 / 07 11 / 07 12 / 07 3.1 planejado x X X x x x x x x x X x X x x X x x x X
3.1 executado x x X x x x X
4.1 planejado
4.1 executado
4.2 planejado
4.2 executado
5.2 planejado
5.2 executado
5.3 planejado
5.3 executado
5.4 planejado
5.4 executado
5.5 planejado
5.5 executado
Lista de Atividades no TCC II:
• 3.1. Implementar o Portal de Informações de Otologia
• 4.1. Realizar testes blackbocks de funcionamento do Portal de Informações de Otologia
• 4.2. Realizar a validação do funcionamento do Portal de Informações de Otologia junto a
especialistas da UFRGS.
• 5.2. Redigir o texto do TCC II
47
• 5.3. Redigir um artigo científico
• 5.4. Redigir um manual de instalação
• 5.5. Redigir um manual de usuário
Conforme apresentado no cronograma previsto no TCC I, seguiu-se há risca o tempo
planejado para as atividades na maioria dos itens. Um atraso ocorreu apenas na atividade 2.2
(Realizar o Projeto do Portal de Informações de Otologia), mas não afetou o cronograma geral deste
trabalho. No TCC II ocorreu um atraso na atividade 3.1 (Implementar o Portal de Informações de
Otologia) por uma falha no não planejamento das correções necessárias após os testes.
4 RESULTADOS
O Portal de Otologia é um projeto que está sendo desenvolvido entre três universidades,
UNIVALI – Universidade do Vale do Itajaí – Campus São José, UFSC – Universidade Federal de
Santa Catarina através do grupo Cyclops e a UFRGS – Universidade Federal do Rio Grande do Sul
através do Hospital de Clínicas de Porto Alegre. Este projeto visa utilizar esta metodologia para
tornar o protótipo uma ferramenta de consulta diária junto ao grupo da UFRGS, para os
especialistas da área otológica.
Como mencionado anteriormente, o protótipo foi desenvolvido utilizando os conceitos Web,
o que traz vantagens e desvantagens inerentes à tecnologia, vantagens como: disponibilidade de
acesso de qualquer computador, sem necessidade de instalação prévia de algum software, facilidade
de backups dos dados, dados utilizados estão sempre atualizados e disponíveis; dentre outros.
Desvantagens como a não disponibilidade do servidor gera uma parada total do sistema, a não
conectividade dos computadores à Internet gera uma impossibilidade do trabalho.
Figura 20. Interface do Portal desenhada.
O Portal foi concebido basicamente em três partes: a) login no portal; b) o especialista tem a
opção de cadastrar novos usuários, manipular os protocolos sendo estes: protocolo de primeira
consulta, revisão pré-operatória, descrição cirúrgica, revisão pós-operatória e protocolo de
audiometria; e c) o especialista também possui a opção de fazer buscas de pacientes e protocolos.
49
Figura 21. Interface do Portal Implementada.
As interfaces foram concebidas seguindo o padrão estipulado pelos designers, o que tornou
essas interfaces bastante amigáveis aos usuários, segundo os especialistas da UFGRS. A Figura 20
mostra a interface de acesso ao Portal concebida pela equipe de design, e a Figura 21 apresenta a
interface implementada no Portal.
Depois de conectado ao sistema, o especialista tem acesso às diversas funcionalidades
mostradas na Figura 22, como cadastrar pacientes e fazer o registro dos protocolos para os mesmos.
Para manipulação dos protocolos seguiu se um padrão para facilitar a navegação para os
especialistas. Após se conectar no Portal o especialista deve escolher o protocolo desejado, a seguir
o Portal apresenta a lista de pacientes cadastrados, deve então selecionar o paciente desejado e
clicar no botão da ação que deseja executar, visualizar ou inserir um novo protocolo ou editar os
dados do paciente como pode ser visto na Figura 23.
50
Figura 22. Interface Funcionalidades Implementada.
Figura 23. Interface Lista de Pacientes Implementada.
51
No caso de protocolos extensos foi criada uma estrutura para que esse ficasse subdividido e
o especialista fosse respondendo aos poucos com a opção de ir expandindo o mesmo como pode ser
visto na Figura 24 o protocolo de primeira consulta.
Figura 24. Interface Cadastro do Protocolo de Primeira Consulta Implementada.
Todas as interfaces implementadas dos protocolos do Portal podem ser vistas com maiores
detalhes no Anexo VI.
A seguir é apresentada a avaliação do protótipo desenvolvido.
4.1 Avaliação do Protótipo Desenvolvido
A avaliação do protótipo desenvolvido dentro do escopo deste TCC intitulado Portal de
Otologia ocorreu através da sua utilização por especialistas do grupo Com.Br no seu cotidiano. O
seu acesso deu-se através dos servidores do laboratório de Telemedicina da UFSC.
Esta avaliação ocorreu de forma empírica, não sistemática, e foi considerada satisfatória
pelos avaliadores. Sobre esta avaliação opinaram quatro especialistas do grupo Com.Br. Estes
especialistas já possuíam experiência prévia com os protocolos em papel. Para a avaliação do
52
protótipo foram utilizados os diagramas de casos de uso, verificando se o protótipo era capaz de
atender foi proposto pela metodologia, bem como verificando se todos os requisitos funcionais e
não funcionais foram atendidos.
Durante uma semana os especialistas ficaram realizando os testes do protótipo, cadastrando
pacientes e manipulando os protocolos. A partir dos testes o grupo forneceu os feedbacks
necessários para a melhoria do protótipo desenvolvido, nestes foram levantados alguns
questionamentos.
Pequenas alterações na interface gráfica foram sugeridas principalmente nas terminologias
utilizadas, as quais foram prontamente alteradas. No entanto, nos quesitos usabilidade e
funcionalidades o Portal foi aprovado pelos especialistas.
Para os especialistas o protótipo fora considerado de fácil manuseio, ou seja, de fácil acesso
às funcionalidades e com uma interface limpa, porém não é objetivo deste trabalho discutir as
colocações dos especialistas em relação a interfaces.
Uma questão levantada pelos especialistas foi sobre a protocolação dos dados, que foi uma
das exigências em relação à autenticidade dos dados. Este módulo foi desenvolvido, mas não pode
ser testado devido à indisponibilidade de um equipamento PDDE para tais fins. A falta da
protocolação dos dados não afeta o funcionamento do protótipo.
Outro assunto abordado durante a avaliação, refere-se à administração dos dados, das tabelas
auxiliares, usuários, dentre outros. Como definido anteriormente no escopo deste trabalho, esta
funcionalidade não estará disponível nesta versão. Considerou-se que este módulo não afetaria num
primeiro momento a boa funcionalidade do protótipo do Portal. Isso se deve ao fato de que o
primeiro ambiente de aplicação foi controlado e teve um acompanhamento bem próximo, onde se
tem a consciência que para uma versão disponibilizada a outra instituição esse modulo é essencial.
Um dos requisitos do grupo Com.Br da UFRGS é a exportação de dados em um formato
específico que eles já vem utilizando com o sistema de geração de estatísticas SPSS. Existem duas
possibilidades para resolução deste requisito: 1) exportar os dados para um arquivo com o formato
que já vem sendo utilizado até o presente momento; e 2) propor uma nova estrutura de avaliação
estatística mais adequada e mais eficiente, sendo que esse implicaria em revisarmos todos os dados
anteriores. Este módulo também será concebido para uma versão posterior, sendo que este
atualmente não afeta o funcionamento do protótipo.
53
Uma avaliação sistemática está sendo planejada para o futuro próximo conforme pode ser
visto no capitulo de trabalhos futuros deste TCC. Para essa avaliação sistemática está previsto ser
aplicada a vários especialistas da área sendo esta, diretamente influenciada pela disponibilidade de
especialistas que o façam. Objetiva-se cruzar as informações resultantes desta avaliação com o
intuito de melhorar ainda mais esta metodologia e o protótipo de software desenvolvido.
Segundo os especialistas o protótipo teve um bom aproveitamento e atingiu as expectativas
esperadas.
Na próxima seção serão apresentadas as considerações finais deste trabalho.
5 CONCLUSÃO
Durante a avaliação da estrutura instalada no contexto do grupo de pesquisas em Otite
Média Crônica do HCPA, observaram-se às dificuldades dos especialistas em acompanhar a
evolução dos seus pacientes sem um sistema informatizado adequado as suas necessidades. Este
fato enfatizou a necessidade do desenvolvimento de uma ferramenta de software que possibilite
gerir esses dados. Observou-se também que estes especialistas discutem muitas vezes seus casos
com especialistas de outras instituições do Brasil e do exterior. Para essas discussões se faz
necessário levar os prontuários em papel. Tal situação salienta a necessidade de um sistema baseado
em tecnologias Web como forma de facilitar o dia-a-dia desses especialistas.
Diversas buscas no que tange o estado da arte foram efetuadas sendo que não foram
encontrados trabalhos com os propósitos propostos dentro do contexto deste trabalho. Um trabalho
similar foi encontrado, sendo este um sistema proprietário, que cobre alguns dos itens propostos por
este TCC. O sistema intitulado ONDB foi desenvolvido por uma empresa francesa (pode ser
encontrado no site www.ondb.org). Uma versão de demonstração desta ferramenta foi testada pelos
especialistas do HCPA durante o levantamento de requisitos, sendo que parte de suas funções foram
incorporadas neste projeto.
A questão de segurança é algo bastante discutido dentro do meio médico, o que se propôs
que, além de os dados ficarem armazenados no banco de dados, esses também deveriam ser
protocolados na PDDE na qual a mesma garante a existência de um documento eletrônico de forma
totalmente confiável.
Uma falha no levantamento de requisitos foi à clara definição no formato da exportação de
dados, essa falha fez com que este módulo fosse planejado e ser desenvolvido na próxima versão do
sistema. Essa decisão foi tomada devido à complexidade inerente, sendo que existem duas
possibilidades para esta solução, seguir o padrão adotado pelos especialistas até o presente
momento ou propor uma nova estrutura de avaliação estatística mais adequada e mais eficiente
conforme discutido com maiores detalhes na Seção 4.6 deste TCC.
O protocolo de audiometria, um dos requisitos para a metodologia não foi implementado no
protótipo devido a sua complexidade na geração de gráficos e cálculos para geração dos resultados.
Este protocolo esta em estudo e é previsto seu desenvolvimento nos trabalhos futuros.
55
Durante o processo de modelagem das classes do sistema e do diagrama de banco de dados
foram feitas diversas readequações e revisões devido à complexidade dos protocolos. Essas
readequações objetivavam uma melhoria na modelagem do conhecimento até então utilizado.
Com base em um layout concebido para os especialistas da área otológica, ou seja, uma
interface de fácil acesso as funcionalidades, foi desenvolvida toda a aplicação utilizando a
linguagem de programação PHP e os dados são armazenados em um banco de dados PostgreSQL.
A partir de uma avaliação empírica realizada pelos especialistas do HCPA, o protótipo
atingiu os objetivos e mostrou-se eficiente, atendendo os requisitos exigidos pelos especialistas.
Observou-se também que esse protótipo facilita o atendimento e acompanhamento do prontuário
dos pacientes.
Todos os resultados obtidos, bem como as sugestões, foram documentados durante o
processo de desenvolvimento deste TCC. Como forma de melhoria da atual versão do protótipo que
foi proposto, as sugestões sugeridas para um melhor funcionamento do Portal podem ser
encontradas na Seção 5.1 deste TCC.
5.1 Trabalhos futuros
Para melhor funcionamento do Portal são planejados alguns trabalhos:
• O protocolo de audiometria, devido a ser o mais complexo dos protocolos, pois nele é
feito o uso de gráficos e cálculos para gerar resultados, está em fase de desenvolvimento
e se tem o planejamento de estar pronto na próxima versão do sistema;
• A protocolação esta em fase de desenvolvimento e deverá estar pronta na próxima
versão do sistema, faltando apenas à realização de testes;
• Área de administração do Portal: este módulo se faz necessário para que os especialistas
possam alimentar as tabelas auxiliares, ter o controle de usuários, logs de alterações,
bem como um módulo que disponibilize um mural de informações;
• Exportação dos dados, como não se trata de uma simples exportação de dados como
tinha sido prevista nos requisitos, esta exportação deve preparar os dados para serem
importados por um programa de estatísticas chamado SPSS;
56
• Integração com o sistema AURIS, o sistema irá receber imagens e alguns dados de
mensuração vindos do AURIS.
• Realizar uma avaliação sistemática do protótipo desenvolvido.
REFERÊNCIAS BIBLIOGRÁFICAS
ALECRIM, Emerson. Banco de Dados Mysql e PostgreSQL. 2006. Disponível em: < http://www.infowester.com/> Acesso em: 18 de maio de 2007.
ALBERNAZ, Pedro Luiz Mangabeira; GANANÇA, Maurício Malavasi; FUKUDA, Yotaka; MUNHOZ, Mário Sérgio Lei. Otorrinolaringologia para o Clínico Geral. São Paulo, Fundo Editorial BYK, 1997, 262p.
BERTULANI, Carlos A. O Ouvido Humano, Disponível em: <http://www.if.ufrj.br/teaching/fis2/>. Acessado em: 08 de Julho de 2006.
BONA, Cristina. Avaliação de processos de software: um estudo de caso em XP e ICONIX. Dissertação de Mestrado. Universidade Federal de Santa Catarina. Programa de Pós Graduação em Engenharia de Produção. Florianópolis, 2002.
BRy Tecnologia. Protocolação Digital, Disponível em: <http:www.bry.com.br>. Acesso em: 10 de maio de 2007.
CONVERSE, Tim; PARK, Joyce. PHP – A Bíblia. Tradução da 2ª edição. Rio de Janeiro. Editora Campus, 2003.
COSTA, Cláudio Giulliano Alves da. Desenvolvimento e avaliação tecnológica de um sistema de prontuário eletrônico do paciente, baseado nos paradigmas da wolrd wide web e da engenharia de software. Dissertação de mestrado. Universidade Estadual de Campinas. Faculdade de Engenharia Elétrica e de Computação. Departamento de Engenharia Biomédica. Campinas, 2001.
COSTA, Guilherme Guerra Orcesi da. Anatomia do Osso Temporal. Faculdade de Medicina da Universidade de São Paulo. USP, 2005. Disponível em: <http://www.otorrinousp.org.br/>. Acessado em: 11 de Abril de 2007.
COSTA, Sady Selaimen; DORNELLES, Cristina de Carvalho; NETTO, Luciana Fick Silveira; BRAGA, Maria Elisa Luce. Aspectos gerais das otites médias. In Costa e colaboradores, Otorrinolaringologia – Princípios e Prática, 2ª edição, pp 254 a 273. – 2006.
COSTA, Sady Selaimen; DORNELLES, Cristina de Carvalho. Otite Média Crônica Não-Colesteatomatosa. In Costa e colaboradores, Otorrinolaringologia – Princípios e Prática, 2ª edição, pp 289 a 308. – 2006a.
COSTA, Sady Selaimen; DORNELLES, Cristina de Carvalho. Otite Média Crônica Colesteatomatosa. In Costa e colaboradores, Otorrinolaringologia – Princípios e Prática, 2ª edição, pp 309 a 333. – 2006b.
DORNELLES, Cristina de Carvalho. Informação e Consentimento Informado Sobre a Mastoidectomia. Divisão de Clínica Otorrinolaringológica - Hospital das Clínicas da Faculdade de Medicina da Universidade de São Paulo. Formulário de Consentimento de Cirurgia. São Paulo, 2007.
58
HECK JUNIOR, Vilson.; ABDALA, Daniel Duarte; COMUNELLO, Eros; WANGENHEIM, Aldo von.; DORNELLES, Cristina de Carvalho; COSTA, Sady Selaimen. Técnicas Computacionais para Acompanhamento e Mensuração de Patologias em Otologia - X Congresso Brasileiro de Informática em Saúde – 2006.
HUNGRIA, Hélio.Manual de Otorrinolaringologia. 8ª edição – Rio de Janeiro: Guanabara Koogan, 2000.
LOPES, Antonio Carlos. Primórdios da Medicina. Clínica médica – Passado, Presente, Futuro. São Paulo, Lemos Editorial e Gráficos Ltda, 1999.
MAIA, José Anízio. Construindo Softwares com Qualidade e Rapidez Usando ICONIX. Disponível em <http://www.guj.com.br>. Acessado em: 10 de setembro 2007.
MARTHA, Amilton Souza; SALOMÃO, Paulo Lisias; ROMANI, Renato; CAMPOS, Carlos José Reis de; SIGULEM, Daniel. Clinic web: PEP e interação com dispositivos móveis - X Congresso Brasileiro de Informática em Saúde – 2006.
MASSAD, Eduardo; MARIN, Heimar de Fátima; NETO, Raymundo Soares de Azevedo. O prontuário eletrônico do paciente na assistência, informação e conhecimento médico. Faculdade de Medicina de São Paulo. São Paulo, 2003.
NETTO, M.C.; RUIZ T.; CORRENTE, J.E.; DIAS, A. A evolução do computador e sua aplicação na saúde. Faculdade de Medicina de Botucatu. UNESP, 2005. Disponível em <http://www.sbis.com.br> . Acessado em: 22 de março de 2007.
OLIVEIRA, Halley Pacheco de. Documentação do PostgreSQL. Projeto de Tradução para o Português do Brasil. 2007. Disponível em: < http://sourceforge.net> Acesso em 20 de maio de 2007.
PHP.NET. PHP: Hypertex Preprocessor. Disponível em : <http:www.php.net> Acesso em 29 de abril de 2007.
PIGNATARY, Shirley N.; WECKX, Luc L. M.. Consenso Sobre Otite Média In Revista Brasileira de Otorrinolaringologia. Vol. 65 ed. 1 de Janeiro-Fevereiro. pp 03 a 27 – 1999. Acesso em 10 de abril de 2007. Disponível em: <http://www.rborl.org.br/.>
SILVA, Edna Lúcia da. Metodologia da pesquisa e elaboração de dissertação. 3.ed. rev. atual. Florianópolis: Laboratório de Ensino a Distância da UFSC, 2001. 121p.
WELLING, Luke; THOMSON, Laura. PHP e MySql – Desenvolvimento Web. Tradução da Segunda Edição. Rio de Janeiro. Editora Campus, 2003.
ZORZETTO, Neivo Luiz. Anatomia da Orelha. In Costa e colaboradores, Otorrinolaringologia – Princípios e Prática, 2ª edição, pp 23 a 60. - 2006
ANEXOS
ANEXO I
PROTOCOLO DE PRIMEIRA CONSULTA
ANEXO II
PROTOCOLO PRÉ-OPERATÓRIO
ANEXO III
PROTOCOLO DE DESCRIÇÃO CIRÚRGICA
ANEXO IV
PROTOCOLO PÓS-OPERATÓRIO
ANEXO V
DETALHAMENTO DOS CASOS DE USO
ANEXO VI
DETALHAMENTO DAS INTERFACES DO PORTAL
