UNIVERSIDADE FEDERAL FLUMINENSE MARCOS · PDF file1 Esquema de arquitetura em uma...
120
UNIVERSIDADE FEDERAL FLUMINENSE MARCOS MONSORES TERRA PROJETO DE UM SISTEMA DE GERENCIAMENTO DE DADOS MÉDICOS Niterói 2011
Transcript of UNIVERSIDADE FEDERAL FLUMINENSE MARCOS · PDF file1 Esquema de arquitetura em uma...
UNIVERSIDADE FEDERAL FLUMINENSEMARCOS MONSORES TERRA
PROJETO DE UM SISTEMA DE GERENCIAMENTO DE DADOS MÉDICOS
Niterói2011
MARCOS MONSORES TERRA
PROJETO DE UM SISTEMA DE GERENCIAMENTO DE DADOS MÉDICOS
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do Título de Tecnólo-
go em Sistemas de Computação.
Orientadora:Fernanda Gonçalves de Oliveira
NITERÓI2011
MARCOS MONSORES TERRA
PROJETO DE UM SISTEMA DE GERENCIAMENTO DE DADOS MÉDICOS
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do Título de Tecnólo-
go em Sistemas de Computação.
Niterói, 25 de junho de 2011.
Banca Examinadora:
_________________________________________
Fernanda Gonçalves de Oliveira, Msc. – Orientadora
UFF - Universidade Federal Fluminense
_________________________________________
Diego Gimenez Passos, Msc. – Avaliador
UFF - Universidade Federal Fluminense
AGRADECIMENTOS
A Deus, que sempre iluminou a minha cami-
nhada.
A minha orientadora Fernanda Oliveira
pelo estímulo e atenção que me concedeu
durante o curso.
Aos Colegas de curso pelo incentivo e troca
de experiências.
A todos os meus familiares e amigos pelo
apoio e colaboração.
“A Escola é uma arena onde grupos sociais
lutam por legitimidade e poder”.
Dinair Leal da Hora
RESUMO
A motivação para este trabalho está baseada em um exemplo do uso de um banco de dados objetivando subsidiar informações para um levantamento das questões re-lacionadas com a situação do atendimento médico hospitalar. Tais informações pos-sibilitam a exibição de relatórios sobre diversas questões, como: quantidade de diag-nóstico de determinada doença em uma área num dado período; quantidade de mé-dicos de uma especialidade em uma determinada região; consulta por médico com acesso ao sistema, consulta pelo histórico do paciente que está sendo atendido; en-tre outras.Este trabalho consiste no projeto de um sistema que tem por objetivo o gerencia-mento do atendimento médico, registrando o histórico dos pacientes como consultas e procedimentos em um banco de dados para futuras consultas por profissionais da área e levantamento de informações estatísticas. Primeiramente, temos um banco de dados com tabelas onde ficam registrados os cadastros de médicos, pacientes, históricos de consultas, procedimentos e outros. Utilizando esse banco temos uma aplicação que seria utilizada por médicos e outros profissionais da área de saúde. Como interface com o usuário, haveria: uma tela com um formulário para consulta e preenchimento do histórico do paciente, dados de consultas e procedimentos (pedi-dos de exames, cirurgias, etc); uma tela que exibe cadastros de médicos, de pacien-tes, de instituições; telas para consultas e exibição de relatórios estatísticos; telas para cadastramento de médicos, pacientes, instituições, entre outros.
Palavras-chaves: Banco de Dados, Saúde, Aplicação Web.
ABSTRACT
The motivation for this work is based on an example of using a database aiming to support information for a survey of issues related to the situation of health care hospi-tal. Such information enables the display of reports on various issues as: number of diagnostics for a particular disease in an area within a given period, an amount of doctors of a given specialty in a particular region; querying a medical doctor with ac-cess to the system, querying the patient's history, among others.This work consists in designing a system that aims to manage appointments, recor-ding the history of patients as medical consultations and procedures in a database for future reference for professionals and a survey of statistical information. First, we have a database with tables where the entries are recorded by doctors, patients, his-torical consultation, and other procedures. Using this database we have an applica-tion that would be used by doctors and other health professionals. As user interface, there would be: a screen with a form to query and fill the patient's history, with data queries and procedures (requests for examination, surgeries, etc.), a screen that dis-plays entries from doctors, patients, institutions; screens for queries and view statisti-cal reports; screens for registration of doctors, patients, institutions, among others.
Key words: Database, Healthcare, Web Application.
LISTA DE ILUSTRAÇÕES
1 Esquema de arquitetura em uma camada.............................................................25
2 Esquema de arquitetura em 2 camadas................................................................25
3 Esquema de arquitetura em 3 camadas................................................................26
4 Diagrama de Casos de Uso...................................................................................35
5 Diagrama de Classes Conceitual...........................................................................58
6 Diagrama de sequência – Atendente cadastra paciente.......................................59
7 Diagrama de sequência - Paciente consulta rede credenciada............................60
8 Diagrama de sequência - Médico cadastra prontuário do paciente......................61
9 Diagrama de sequência - Pesquisador faz consultas estatísticas........................62
10 Diagrama de sequência - Administrador cadastra de profissionais de saúde... .63
11 Diagrama de sequência - Médico acessa prontuário..........................................64
12 Diagrama de sequência - Cadastramento/alteração de senha...........................65
13 Descrição dos componentes de um modelo de banco de dados........................67
14 Modelo do Banco de Dados.................................................................................68
15 Tela principal........................................................................................................73
16 Tela inicial do paciente........................................................................................74
17 Tela de menu de busca de rede credenciada.....................................................74
18 Tela de busca de médicos por especialidade.....................................................75
19 Tela de busca de médicos por nome...................................................................75
20 Tela de busca por instituição...............................................................................76
21 Tela de login do paciente.....................................................................................76
22 Tela para o paciente cadastrado.........................................................................77
23 Tela de login do profissional de saúde................................................................78
24 Tela inicial do administrador................................................................................79
25 Tela de visualização/alteração de cadastro de profissional................................79
26 Tela de cadastramento de novo profissional.......................................................80
27 Tela de menu de visualização de mensagens....................................................80
28 Tela de cadastramento/alteração de senha........................................................81
29 Tela de manutenção de tabelas..........................................................................81
30 Tela inicial do médico..........................................................................................82
31 Tela de cadastramento de prontuário..................................................................83
32 Tela de cadastramento de autorização de acesso a um prontuário...................83
33 Tela de acesso ao prontuário..............................................................................84
34 Tela inicial do atendente......................................................................................85
35 Tela de inserção de parâmetro de busca para vis./alteração de cadastro.........85
36 Tela de visualização/alteração de cadastro do paciente.....................................86
37 Tela de cadastramento de paciente....................................................................86
38 Tela de cadastramento de senha........................................................................87
39 Tela de alteração de senha.................................................................................87
40 Tela inicial de pesquisa........................................................................................88
41 Tela de pesquisa por diagnóstico........................................................................89
42 Tela de pesquisa por evento................................................................................89
43 Tela de pesquisa por prescrição..........................................................................90
44 Tela de pesquisa por quantidade de médicos.....................................................90
45 Tela de pesquisa por quantidade de pacientes...................................................91
46 Tela de cadastramento de tipo de evento...........................................................93
47 Tela com cadastramento de doença...................................................................94
48 Tela com cadastramento de medicamento..........................................................94
49 Tela de cadastramento de instituição..................................................................95
50 Tela seguinte ao cadastramento com sucesso...................................................96
51 Tela mostrando mensagem de erro por uma inserção de senha errada............97
52 Tela mostrando cadastramento com sucesso de um profissional......................98
53 Tela mostrando o preenchimento do prontuário (parte de cima do formulário)..99
54 Tela mostrando o preenchimento do prontuário (continuação do formulário).. . .100
55 Tela mostrando o resultado de uma busca por médicos....................................101
56 Tela mostrando a visualização de um cadastro pelo próprio paciente...............101
57 Tela mostrando a visualização do próprio prontuário..........................................102
58 Tela com resultado de uma pesquisa por diagnóstico........................................103
59 Tela exibindo o resultado de uma pesquisa de ocorrência de um evento..........104
60 Tela exibindo resultado de pesquisa de prescrição de um medicamento..........104
61 Tela com resultado da pesquisa da quantidade de médicos no estado.............105
LISTA DE ABREVIATURAS E SIGLAS
CADSUS - Sistema de Cadastramento de usuários do SUS.
CASE - Computer-Aided Software Engineering - Engenharia de Software Assistida
por Computador.
CNES - Cadastro Nacional de Estabelecimentos de Saúde.
CFM – Conselho Federal de Medicina.
CNPq - Conselho Nacional de Desenvolvimento Científico e Tecnológico.
DATASUS - Departamento de Informática do SUS.
FNS – Fundação Nacional de Saúde.
HOSPUB - Sistema Integrado de Informatização de Ambiente Hospitalar
HTML - HyperText Markup Language, (Linguagem de Marcação de Hipertexto)
HTTP - HyperText Transfer Protocol (Protocolo de Transferência de Hipertexto )
IDE - Integrated Development Environment (Ambiente Integrado de Desenvolvimen-
to)
JSP – Java Server Pages
PSF - Programa Saúde da Família.
PEP – Prontuário Eletrônico do Paciente.
SGBD – Sistema de Gerenciamento de Banco de dados
SIAB - Sistema de Informação da Atenção Básica.
SISAIH - Sistema Gerador do Movimento das Unidades Hospitalares.
SIASUS - Sistema de Informação Ambulatorial do Sistema Único de Saúde.
SNIS - Sistema Nacional de Informações em Saúde .
SQL - Linguagem de Consulta Estruturada, do inglês Structured Query Language.
SUS - Sistema Único de Saúde.
TABNET - Ferramenta de Tabulação do DATASUS via Internet.
UFRJ – Universidade Federal do Rio de Janeiro.
UNICAMP – Universidade Estadual de Campinas.
SUMÁRIO
RESUMO......................................................................................................................6
ABSTRACT .................................................................................................................7
LISTA DE ILUSTRAÇÕES...........................................................................................8
LISTA DE ABREVIATURAS E SIGLAS.....................................................................10
1 INTRODUÇÃO ......................................................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA .............................................................................. 16
2.1 INFORMÁTICA E SAÚDE NO BRASIL ............................................................. 16
2.2 PRONTUÁRIO ELETRÔNICO DO PACIENTE - PEP ...................................... 19
2.3 SISTEMAS DE BANCO DE DADOS ................................................................. 21
2.4 APLICAÇÕES WEB. .......................................................................................... 23
2.4.1 CONCEITO. ................................................................................................ 23
2.4.2 ARQUITETURA EM CAMADAS ................................................................. 24
2.4.3 CAMADA DE ARMAZENAMENTO ............................................................. 26
2.4.4 CAMADA DE APRESENTAÇÃO, LINGUAGEM HTML E JSP .................. 27
2.4.5 CAMADA DE APLICAÇÃO E A LINGUAGEM JAVA ................................. 28
2.4.5.1 SERVLETS ........................................................................................... 29
2.4.5.2 SERVIDOR DE APLICAÇÃO E SERVLET CONTAINER ................... 29
2.4.5.3 FERRAMENTA PARA DESENVOLVIMENTO EM JAVA. .................. 30
3 ESPECIFICAÇÃO DO PROJETO ............................................................................ 31
3.1 OBJETIVO E APRESENTAÇÃO DO SISTEMA ............................................... 31
3.2 REQUISITOS DO SISTEMA ............................................................................. 32
3.2.1 FUNCIONAIS .............................................................................................. 32
3.2.2 NÃO FUNCIONAIS ..................................................................................... 33
3.3 CASOS DE USO ................................................................................................ 33
3.3.1 IDENTIFICAÇÃO DOS ATORES ................................................................ 34
3.3.2 DIAGRAMA DE CASOS DE USO .............................................................. 34
3.3.3 LISTA DOS CASOS DE USO ..................................................................... 36
3.3.4 DESCRIÇÃO DOS CASOS DE USO ......................................................... 37
3.4 DIAGRAMA DE CLASSES CONCEITUAL ........................................................ 57
3.5 DIAGRAMAS DE SEQUÊNCIA ......................................................................... 59
3.5.1 ATENDENTE CADASTRA PACIENTE: ..................................................... 59
3.5.2 PACIENTE CONSULTA REDE CREDENCIADA: ...................................... 60
3.5.3 MÉDICO CADASTRA PRONTUÁRIO DO PACIENTE. ............................. 61
3.5.4 PESQUISADOR FAZ CONSULTAS ESTATÍSTICAS. ............................... 62
3.5.5 ADMINISTRADOR CADASTRA DE PROFISSIONAIS DE SAÚDE. ......... 63
3.5.6 MÉDICO ACESSA PRONTUÁRIO DO PACIENTE. .................................. 64
3.5.7 CADASTRAMENTO/ALTERAÇÃO DE SENHA. ........................................ 65
3.6 MODELO DO BANCO DE DADOS ................................................................... 66
3.7 DESCRIÇÃO DAS CLASSES ........................................................................... 69
3.7.1 A CLASSE CONEXÃO, A CLASSE PESQUISA E AS CLASSES COR-
RESPONDENTES AS TABELAS DO BANCO DE DADOS. ............................... 69
3.7.2 OS SERVLETS ........................................................................................... 71
3.8 TELAS ................................................................................................................ 72
3.8.1 TELA PRINCIPAL. ...................................................................................... 72
3.8.2 TELAS RELACIONADAS AO PACIENTE .................................................. 73
3.8.3 TELAS DE ACESSO PELO PROFISSIONAL ............................................ 77
4 REALIZAÇÃO E RESULTADO DOS TESTES ........................................................ 92
4.1 PREPARAÇÃO DAS TABELAS AUXILIARES. ................................................ 92
4.2 CADASTRAMENTO DE PACIENTES E OUTROS TESTES RELATIVOS AO
ATENDENTE. .......................................................................................................... 96
4.3 CADASTRAMENTO DE PROFISSIONAIS DE SAÚDE ................................... 97
4.4 CADASTRAMENTO DE PRONTUÁRIOS E INSERÇÃO DE DADOS ............. 98
4.5 TESTES RELATIVOS AO PACIENTE ............................................................ 100
4.6 TESTES RELATIVOS A PESQUISA ............................................................... 102
4.7 ANÁLISE DOS RESULTADOS ....................................................................... 105
5 CONCLUSÕES E TRABALHOS FUTUROS ......................................................... 107
REFERÊNCIAS BIBLIOGRÁFICAS.........................................................................109
APÊNDICE..............................................................................................................111
14
1 INTRODUÇÃO
A proposta deste trabalho é implementar um sistema de banco de dados
que permite uma administração do atendimento médico com acesso via web para
uso por profissionais da área. Com este sistema poderíamos coletar dados como
quantidade de profissionais específicos numa área, relação de médico por pacien-
tes, quantidade de diagnóstico de uma doença em uma área num período dado, en-
tre outras funcionalidades. O sistema proposto compõe-se basicamente de um ban-
co de dados e uma interface via web com o usuário, onde temos o cadastro de paci-
entes e profissionais de saúde. O profissional irá interagir com este sistema, cadas-
trando pacientes, criando prontuários, realizando pesquisas estatísticas e outras
consultas.
A motivação deste trabalho baseia-se no fato de que o Brasil, como um
país de dimensões continentais, até atualmente, encontra dificuldades em oferecer
um meio de colher dados em tempo real com base em informações de diagnósticos
e procedimentos, além de somente cadastro, o que colaboraria para uma rede de
atendimento compatível com a necessidade da população. Conforme SIGULEM [20]
“Os sistemas de informação em saúde podem monitorar o processo de assistência à
saúde e aumentar a qualidade da assistência ao paciente por auxiliar no processo
de diagnóstico ou na prescrição da terapia, por permitir a inclusão de lembretes clíni-
cos para o acompanhamento da assistência, de avisos sobre interações de drogas,
de alertas sobre tratamentos duvidosos e desvios dos protocolos clínicos.”
A informática na saúde é uma poderosa ferramenta de coleta de dados
para subsídio de pesquisas da qualidade do atendimento, avanço de programas,
acompanhamento da evolução de epidemias, e muitas outras possibilidades ofereci-
das por este valioso recurso.
No Capítulo 2 abordaremos algumas técnicas e aspectos teóricos que en-
volvem a tecnologia utilizada no projeto. Inicialmente expomos um perfil da informati-
15
zação da saúde pública e uma descrição do que seria um prontuário eletrônico, prin-
cipal elemento de fonte de dados para o projeto, suas restrições quanto a legislação
em vigor, e possíveis alternativas. Finalizando o capítulo, faremos um breve concei-
to sobre banco de dados e aplicativos para web, principais objetos de construção do
projeto.
O Capítulo 3 é dedicado a especificação do projeto, onde descreveremos
os requisitos do sistema, seus casos de uso, o diagrama de classes, o diagrama de
sequência, o mapeamento relacional e as telas da interface.
Em seguida, relataremos no Capítulo 4 os testes feitos em detalhes e dis-
cutiremos seus resultados, soluções alternativas ou ajustes que podem ser feitos.
Finalmente, no Capítulo 5, temos as conclusões sobre o projeto realizado
apontando seus benefícios, possíveis complementos e indicação de trabalhos futu-
ros.
16
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo faremos uma descrição teórica sobre uma aplicação web e
os componentes que a compõe, como banco de dados, a linguagem Java e o HTML,
usados pra construir as funcionalidades deste sistema. Iniciaremos este capítulo
com um histórico da relação da informática com a saúde no Brasil, seus desafios e
soluções, como o Prontuário Eletrônico do Paciente (PEP), base de fornecimento de
dados para o sistema proposto.
2.1 INFORMÁTICA E SAÚDE NO BRASIL
A informática aplicada à medicina entrou no Brasil com um certo atraso
em relação aos EUA e Europa. No início dos anos 70 teve início em alguns centros
universitários como o Hospital da Universidade Federal do Rio de Janeiro – UFRJ.
Passou por nova evolução a partir de 1983 com a criação de grupos especificamen-
te dedicados a esta área de pesquisa, como a fundação no Rio Grande do Sul pela
Dra. Mariza Klück Stumpf, do primeiro curso de informática voltada para alunos e
pós-graduandos de medicina e também a fundação do Núcleo de Informática Biomé-
dica da UNICAMP pelo Dr. Renato Sabbatini. Através do CNPq e outros órgãos, o
Governo Federal efetuou um estudo em 1988 visando um Plano Nacional de Desen-
volvimento da Informática em Saúde (que ficou engavetado) [1].
Com o Decreto Presidencial nº 100 de 16 de abril de 1991 foi criada a
Fundação Nacional de Saúde – FNS, momento em que foi definido o Departamento
de Informática do SUS – DATASUS, como parte integrante da estrutura da FNS.
Segundo o Decreto nº 7.336 [2], de 19 de outubro de 2010, que trata da
Estrutura Regimental do Ministério da Saúde compete ao Departamento de Informá-
tica do SUS:
17
I - fomentar, regulamentar e avaliar as ações de informatização do SUS, di-recionadas à manutenção e ao desenvolvimento do sistema de informações em saúde e dos sistemas internos de gestão do Ministério da Saúde;II - desenvolver, pesquisar e incorporar produtos e serviços de tecnologia da informação que possibilitem a implementação de sistemas e a disseminação de informações necessárias às ações de saúde, em consonância com as di-retrizes da Política Nacional de Saúde;III - manter o acervo das bases de dados necessários ao sistema de infor-mações em saúde e aos sistemas internos de gestão institucional;IV - assegurar aos gestores do SUS e aos órgãos congêneres o acesso aos serviços de tecnologia da informação e bases de dados mantidos pelo Mi-nistério da Saúde;V - definir programas de cooperação tecnológica com entidades de pesquisa e ensino para prospecção e transferência de tecnologia e metodologia no segmento de tecnologia da informação em saúde, sob a coordenação do Secretário-Executivo; e VI - apoiar os Estados, os Municípios e o Distrito Federal na informatização das atividades do SUS.
O DATASUS disponibiliza informações que podem servir para subsidiar
análises objetivas da situação sanitária, tomadas de decisão baseadas em evidên-
cias e elaboração de programas de ações de saúde, através de sistemas desenvol-
vidos, alguns com abrangência regional, outros de abrangência nacional.
A integração sistêmica das aplicações, base para a construção do Siste-
ma Nacional de Informações em Saúde (SNIS), qualifica o avanço na produção e uti-
lização das informações.
Alguns exemplos de aplicativos disponibilizados pelo DATASUS:
SIASUS - O aplicativo de natureza operacional, é processado nas Unida-
des Ambulatoriais, tem a finalidade de garantir o registro dos quantitativos e valores
a serem pagos aos prestadores de serviços, produzindo informações locais que são
consolidadas a nível nacional.
CADSUS - Sistema de Cadastramento de usuários do SUS, auxilia a ges-
tão do Sistema Único de Saúde e contribui para o aumento da eficiência no atendi-
mento direto ao usuário. Tem abrangência municipal e estadual.
CNES - Cadastro Nacional de Estabelecimentos de Saúde, sistema que
gerencia a base de informações sobre as instituições da rede de saúde.
SIAB - Sistema de Informação da Atenção Básica, implantado para o
acompanhamento das ações e dos resultados das atividades realizadas pelas equi-
pes do Programa Saúde da Família – PSF.
18
HOSPUB - Sistema Integrado de Informatização de Ambiente Hospitalar,
é uma ferramenta para prestar informações para subsidiar os diferentes níveis hie-
rárquicos que compõem o SUS, no processo de planejamento, de operação ou de
controle das ações em saúde.
SISAIH - Sistema Gerador do Movimento das Unidades Hospitalares, utili-
zado mensalmente pelas unidades hospitalares para transcrição e envio dos dados
das autorizações de internações hospitalares às secretarias de saúde.
TABNET - Ferramenta de Tabulação do DATASUS, para uso de gestores,
estudiosos e público interessado da área da saúde que objetivam obter e analisar,
com rapidez e objetividade, os dados dos sistemas de informações do SUS.
Os sistemas disponíveis pelo DATASUS hoje não provêm os dados em
tempo real, que geralmente os transitam periodicamente até os sistemas que cole-
tam estes dados e atualizam suas próprias bases, como o TABNET. Não há uma
maior especificação dos dados coletados no que se refere a diagnósticos, resultado
de uma legislação restrita quanto ao gerenciamento do prontuário do paciente. A in-
formação hoje, em sua maioria, se baseia principalmente nos procedimentos regis-
trados nas unidades hospitalares em detrimento as consultas realizadas por profis-
sionais de saúde em seus consultórios.
Essa situação pode ser revertida com duas principais mudanças: primeiro,
uma regulamentação quanto a disponibilização dos dados do prontuário do paciente
em rede, por exemplo. Em segundo, necessitaremos de uma padronização dos pro-
cedimentos de consulta, de modo que o sistema receba com coesão os dados de
toda parte do país. Conforme Loureiro, “a construção de um Sistema Nacional de In-
formações em Saúde constitui-se em um processo muito mais político social e eco-
nômico do que técnico” [3, pág. 3], pois existem vários estudos e propostas tanto no
ambiente acadêmico quanto na iniciativa privada.
E o propósito deste trabalho é apresentar um exemplo de sistema, que
funcionaria em um ambiente web, apresentando dados em tempo real e proporcio-
nando um gerenciamento mais preciso da situação do atendimento médico.
19
2.2 PRONTUÁRIO ELETRÔNICO DO PACIENTE - PEP
O Conselho Federal de Medicina – CFM – por meio da Resolução CFM nº
1.638/2002, define em seu Art. 1º [4] o prontuário médico como “documento único
constituído de um conjunto de informações, sinais e imagens registradas, geradas a
partir de fatos, acontecimentos e situações sobre a saúde do paciente e a assistên-
cia a ele prestada, de caráter legal, sigiloso e científico, que possibilita a comunica-
ção entre membros da equipe multiprofissional e a continuidade da assistência pres-
tada ao indivíduo”.
O prontuário do paciente foi criado por médicos e enfermeiros para garan-
tia de armazenamento dos fatos e eventos clínicos sobre cada indivíduo de forma
que todos os demais profissionais envolvidos no processo de atenção de saúde po-
deriam também ter acesso as mesmas informações [5].
Institute of Medicine descreve o prontuário eletrônico do paciente como
“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 co-
nhecimento médico” [6].
Van Bemmel [7] compara as vantagens do prontuário em papel e baseado
em registro eletrônico da seguinte forma:
•Prontuário em papel: pode ser facilmente carregado; maior liberdade de esti-
lo ao fazer um relatório, facilidade para buscar um dado; não requer treino
especial, não “sai do ar” como ocorre com computadores.
•Prontuário eletrônico: simultâneo acesso em locais distintos; legibilidade; va-
riedade na visão do dado; suporte de entrada de dado estruturada; ofere-
ce apoio à decisão; apoio a análise de dados; troca eletrônica de dados e
compartilha o suporte ao cuidado.
Citamos ainda como vantagens do formulário eletrônico segundo Sittig [8]:
•Acesso remoto e simultâneo de vários profissionais a um mesmo prontuário.
Com o uso da Web, médicos podem acessar e acrescentar dados no
prontuário do paciente de qualquer lugar do mundo.
20
•Boa legibilidade dos dados, se comparado aos registros feitos à mão nos
prontuários em papel.
•Maior segurança dos dados, uma preocupação frequente que pode ser reso-
lvida com um sistema de backup.
•Melhor confidencialidade dos dados, através do acesso ao prontuário poden-
do ser dado por níveis de direitos de usuários e do acesso monitorado
continuamente por auditorias.
•O usuário pode usufruir de formas diferentes de apresentação dos dados, vi-
sualizando em ordem cronológica crescentes ou não, orientado ao proble-
ma e orientado à fonte.
•Integração com outros sistemas de informação.
•Possibilidade de captura automática de dados, oriunda de monitores, equipa-
mento de imagens e resultados laboratoriais, evitando erros de descrição.
Diante das vantagens do Prontuário Eletrônico do Paciente – PEP, surgem
os obstáculos quanto a sua implantação [9]. Os principais são:
•Falta de padronização dos sistemas, que inviabiliza muito do que pode ser
disponibilizado, como alertas, sistemas de apoio à decisão, pesquisas clí-
nicas e outros;
•Dificuldade de trabalho com dados estruturados por parte dos profissionais
de saúde em face a facilidade com o texto livre adotado nos prontuários
em papel.
•Falta de infra-estrutura necessária para o intercâmbio de dados com seguran-
ça entre os sistemas envolvidos, e podem ser necessários adoção de pa-
drões de comunicação, leis e regras que regulamentam a transmissão dos
dados, especialistas em sistemas de PEP, e redes locais, regionais e na-
cionais.
•Dificuldade em relação a segurança, pois o PEP será acessível e manipulado
por vários profissionais em lugares distintos.
•Aspectos legais: falta de regulamentação sobre o uso do meio eletrônico
como forma de armazenamento dos dados e uso de senha eletrônica.
21
Ainda com relação ao aspecto legal, deve-se acrescentar que a legislação
vigente no Brasil, impõe sérias restrições quanto ao compartilhamento de informa-
ções relativas ao prontuário do paciente. Podemos citar como exemplo a Resolução
do CFM nº 1.605/00 nos seus artigos 1º ao 6º [10]:
Art. 1º - O médico não pode, sem o consentimento do paciente, revelar o conteúdo do prontuário ou ficha médica. Art. 2º - Nos casos do art. 269 do Código Penal, onde a comunicação de doença é compulsória, o dever do médico restringe-se exclusivamente a co-municar tal fato à autoridade competente, sendo proibida a remessa do prontuário médico do paciente. Art. 3º - Na investigação da hipótese de cometimento de crime o médico está impedido de revelar segredo que possa expor o paciente a processo criminal. Art. 4º - Se na instrução de processo criminal for requisitada, por autoridade judiciária competente, a apresentação do conteúdo do prontuário ou da ficha médica, o médico disponibilizará os documentos ao perito nomeado pelo juiz, para que neles seja realizada perícia restrita aos fatos em questiona-mento. Art. 5º - Se houver autorização expressa do paciente, tanto na solicitação como em documento diverso, o médico poderá encaminhar a ficha ou pron-tuário médico diretamente à autoridade requisitante. Art. 6º - O médico deverá fornecer cópia da ficha ou do prontuário médico desde que solicitado pelo paciente ou requisitado pelos Conselhos Federal ou Regional de Medicina.
.
No projeto objeto deste trabalho, partindo da premissa baseada no decre-
to 1.605/00 mencionado acima, consideramos que o Prontuário Eletrônico do Paci-
ente – PEP, pertence ao paciente sob guarda do médico autorizado. Assim, o paci-
ente será o possuidor de uma senha ou código de autorização criada no momento
da implantação de seu PEP, que será fornecida ao profissional de saúde no momen-
to da autorização de acesso deste ao seu prontuário.
2.1 SISTEMAS DE BANCO DE DADOS
Os bancos de dados e os sistemas de banco de dados, são componentes
essenciais da sociedade moderna. Seja no acesso a nossa conta bancária, uma
compra de produtos via Internet, uma compra de passagem aérea, num acesso a
uma biblioteca informatizada, entre outros, estamos nos deparando com o uso de
um banco de dados [11, pág. 3].
22
Segundo Elmasri e Navathe [11, pág. 4], “um banco de dados é uma cole-
ção de dados relacionados. Os dados são fatos que podem ser gravados e que pos-
suem um significado implícito.”
Um Sistema Gerenciador de Banco de Dados – SGBD – é um conjunto de
programas cuja finalidade é permitir aos usuários criar e manter um Banco de Dados
- BD. O SGBD é, portanto, um sistema de software com propósito geral que facilita
os processos de definição, construção, manipulação e compartilhamento de bancos
de dados entre vários usuários e aplicações. A definição de um banco de dados im-
plica especificar os tipos de dados, as estruturas e as restrições para os dados a se-
rem armazenados em um banco de dados [11, pág. 4].
Os SGBD surgiram no início da década de 70 com o objetivo de facilitar a
programação de aplicações de BD. A partir da década de 80 e devido ao baratea-
mento das plataformas de hardware/software para executar SGBD relacional, este
tipo de SGBD passou a dominar o mercado, tendo se convertido em padrão interna-
cional. Além do SGBD relacional, as pesquisas na área de BD também tiveram
como resultado, um conjunto de técnicas, processos e notações para o projeto de
BD. O projeto de banco de dados, que antes era feito com técnicas empíricas por
alguns poucos especialistas no SGBD específico, é executado hoje com ajuda de
técnicas padronizadas e suportadas por ferramentas CASE. Formou-se ao longo do
tempo um conjunto de conhecimentos sobre projeto de BD que é largamente aceito
e passível de ser dominado por qualquer profissional de informática [12].
Existe no mercado uma variedade de SGBD, como o Oracle, o IBM Infor-
mix, o Firebird, o SQL-Server, PostgreSQL, e outros. Adotaremos em nosso projeto,
o MySQL, um SGBD gratuito, multiplataforma, de ampla utilização.
Um SGBD utiliza uma linguagem própria para que possibilite a criação,
atualização e consulta dos dados armazenados, normalmente esta linguagem é
composta por três partes: linguagem de definição de dados, que aborda os coman-
dos de criação de tabelas; linguagem de manipulação de dados, relativa aos coman-
dos de atualização e seleção; e por fim a linguagem de controle de dados, que são
comandos para controlar o acesso de usuários ao sistema. A principal linguagem uti-
lizada pelos SGBD é o SQL - Structured Query Language ou Linguagem de Consul-
23
ta Estruturada, uma linguagem que possui simplicidade em sua sintaxe e facilidade
de uso.
Normalmente, um projeto de banco de dados ocorre em três etapas: mo-
delagem conceitual, projeto lógico e projeto físico [12].
Na modelagem conceitual, procuramos identificar os requisitos de infor-
mação de um banco de dados. A forma mais usual nesse caso é uma modelagem
Entidade-Relacionamento - ER. Na etapa seguinte, o projeto lógico, implementamos
a definição a nível do SGBD, dos requisitos identificados na modelagem conceitual.
Para isso transformamos o modelo ER em Relacional, criando tabelas, definindo
chaves, entre outros. No projeto físico, definimos os parâmetros de acesso físico ao
banco de dados, onde sempre se procura otimizar o desempenho de todo o sistema.
Há muitas ferramentas disponíveis no mercado que auxiliam tanto na mo-
delagem conceitual quanto na transformação para o modelo relacional. Uma delas é
o MySQL WorkBench, um software gratuito, que será usado neste projeto.
2.2 APLICAÇÕES WEB.
Nesta subseção, descreveremos o que é uma aplicação ou sistema web,
algumas de suas possíveis arquiteturas e os meios para sua construção como a lin-
guagem Java, o HTML e o sistema gerenciador de banco de dados. Analisaremos
em mais detalhes uma arquitetura em três camadas, como aquela que será usado
em nosso projeto.
2.2.1 CONCEITO.
Segundo uma definição da empresa Oracle, “uma aplicação web é uma
extensão dinâmica de um servidor web ou de aplicação” [13]. Isto é, de uma forma
simples, descrevemos uma aplicação web como uma página da internet, que no lu-
gar de apresentar informação estática, oferece o recurso da interação com o usuá-
24
rio. Podemos nos referir também ao termo Sistemas Web, que tem uma conotação
mais ampla, englobando um grupamento de aplicações web utilizadas para um de-
terminado fim.
Ainda podemos definir uma aplicação web, como um programa que em
vez de ser baixado e instalado no computador do usuário para poder ser acessado,
roda diretamente pelo navegador, quando o usuário acessa a página específica do
programa. As aplicações web também podem ter seu uso no conceito de Computa-
ção em Nuvem, onde existe a proposta de trocar a guarda de dados e aplicativos em
seu próprio computador pelo acesso a aplicações e arquivamento de dados em ser-
vidores na Web.
Para compreensão do funcionamento de uma aplicação deste tipo, preci-
samos conhecer como é a arquitetura de um sistema web.
Conforme Varoto, “a arquitetura de software define o que é o sistema em
termos de componentes computacionais e os relacionamentos entre estes compo-
nentes”[14]. A arquitetura de software nos mostra o sistema de uma forma abstrata,
sem levar em conta os detalhes interiores de sua estrutura.
Segundo Vasconcelos, “a arquitetura enfatiza a organização global do sis-
tema, definindo a sua topologia e permitindo que desenvolvedores voltem a sua
atenção para os requisitos funcionais e não-funcionais que precisam ser atendidos,
antes de se aterem ao projeto das estruturas de dados e algoritmos” [15]. A arquite-
tura de software se baseia numa forma simplificada de escrever a estrutura de todo
o sistema, organizando-o de forma a identificar todas as funcionalidades, antes de
entrar nos detalhes de cada um dos seus componentes.
2.2.2 ARQUITETURA EM CAMADAS
Os sistemas web se baseiam na arquitetura cliente-servidor, onde o servi-
dor contém as páginas e os aplicativos e o cliente faz uso deste conteúdo através de
um navegador web, do outro lado da interação.
25
Este tipo de arquitetura é normalmente construída pelo uso do padrão de
camadas. O número de camadas, tendo como referência o lado do servidor, tem sua
variância em função da complexidade do sistema.
Na arquitetura de uma camada, temos somente a camada de armazena-
mento no lado do servidor, sendo esta acessada diretamente pelo cliente. A Ilustra-
ção 1 mostra a arquitetura de uma camada.
A arquitetura de duas camadas é composta pela camada de armazena-
mento, e apresentação no lado do servidor. O cliente não acessa mais diretamente o
BD, e sim por uma tela de apresentação, como uma página web. A Ilustração 2 mos-
tra o esquema de uma arquitetura em duas camadas.
Ilustração 1: Esquema de arquitetura de uma camada.
Ilustração 2: Esquema de arquitetura em 2 camadas.
26
Por fim, na arquitetura de três camadas, que será usada neste projeto,
além das camadas de armazenamento e de apresentação, temos uma camada de
aplicação, para tratar os dados vindos da camada de apresentação para a camada
de armazenamento, e vice-versa, tratando os dados do armazenamento para ser en-
tregue a camada de apresentação. A Ilustração 3 mostra o esquema desse tipo de
arquitetura.
2.2.3 CAMADA DE ARMAZENAMENTO
Nesta camada encontramos as tabelas com os dados a serem armazena-
dos e que serão manipulados pela camada seguinte(camada de aplicação, no caso
de uma estrutura em 3 camadas). É onde encontramos o sistema de banco de da-
dos.
Com relação a camada de armazenamento deste projeto, como mencio-
nado anteriormente, usaremos o MySQL WorkBench e o MySQL versão 5, para mo-
delagem, implantação e gerenciamento do banco de dados.
Ilustração 3: Esquema de arquitetura em 3 camadas
27
2.2.4 CAMADA DE APRESENTAÇÃO, LINGUAGEM HTML E JSP
A camada de apresentação é onde os dados são formatados, apresenta-
dos ao cliente no seu navegador, e também recebidos do cliente.
Para a camada de apresentação, usaremos a linguagem HTML - Hyper-
Text Markup Language(em português: Linguagem de Marcação de Hipertexto). O
HTML, é uma linguagem utilizada para escrever páginas da Web.
O HTML se baseou no SGML (Standard Generalized Markup Language ),
um sistema de processamento de documentos bem maior, e devido a esta herança,
é uma linguagem para descrição da estrutura de um documento e não sua verdadei-
ra apresentação [16]. As páginas escritas em HTML são arquivos de texto simples, e
contém:
•O texto da própria página;
•Tags HTML que indiquem os elementos de página, estrutura, formatação, lin-
ks de hipertexto para outras páginas ou mídia incluída.
As tags geralmente tem a seguinte apresentação:
<nomedaTag> Texto afetado </nomedaTag>
O HTML ainda tem recursos de compartilhamento de sua estrutura com
outras linguagens, como um código javascript, por exemplo.
Uma página JSP – Java Server Pages nada mais é que um arquivo base-
ado em HTML, com a extensão .jsp. É uma tecnologia que permite escrever o códi-
go Java dentro da página HTML, para podermos adicionar comportamento dinâmico,
com declaração de variáveis, condicionais (if), loops (while, for, etc), entre
outros[17]. Para escrever código Java na página JSP, basta escrevê-lo entre as tags
< % e %>. Esse tipo de código é chamado de scriptlet. A página JSP será usada
neste projeto para preparar os dados vindos da camada de aplicação(manipulados
pelo servlets) para apresentação ao cliente via navegador, como também preparar
dados recebidos dos clientes a serem repassados a camada de aplicação(servlets).
28
2.2.1 CAMADA DE APLICAÇÃO E A LINGUAGEM JAVA
É a camada intermediária entre a camada de apresentação e a camada
de armazenamento, onde há o tratamento dos dados.
Para construção da camada de aplicação usaremos a linguagem Java. O
Java é uma linguagem orientada a objetos, independente de plataformas e
segura[18].
A história do Java remonta a 1991, quando um grupo de engenheiros da
Sun, quis criar uma pequena linguagem de computador que pudesse ser utilizada
para dispositivos de consumidor, como receptores de TV a cabo. Como estes dispo-
sitivos não tem muita potência ou memória, a linguagem teria de ser pequena e com
um código bem robusto. Chamaram inicialmente a linguagem de “Oak”, mas como
perceberam que já existia uma linguagem com este nome, mudaram pra Java. O
projeto não despertou interesse dos fabricantes, o que levou a Sun a voltar para ou-
tras possibilidades, e acertadamente encontrou uma aplicação para a linguagem: o
uso para aplicações na web [19]. A linguagem Java então, encontrou grande aceita-
ção por parte de desenvolvedores de aplicações para web.
Diferente das linguagens convencionais que são compiladas para o códi-
go nativo, o Java é compilado para um bytecode que é executado em uma máquina
virtual. Isso garante que o programa feito em java execute em qualquer plataforma,
desde que esta tenha instalada a máquina virtual.
O Java é uma linguagem orientada a objetos, isto é, funções e dados es-
tão juntos, construindo um objeto. Enquanto na programação estruturada temos uma
preocupação com o algoritmo e sua execução em sequência, no padrão de orienta-
ção a objetos temos classes de objetos que possuem atributos e executam métodos.
A sintaxe da linguagem é similar ao C/C++. Em uma descrição simplifica-
da, as classes são representadas da seguinte forma:
NomedaClasse {
Atributos da classe;
metodosDaClasse (parâmetros){
29
}
}
O programa em java se inicia no método Main que pode fazer parte de
qualquer classe de escopo público. A seguir, um exemplo de uso do método main:
public class OlaMundo{
public static void main(String[] args) {
System.out.println(“Olá Mundo!”);
}
}
2.2.1.1 SERVLETS
O nome servlet vem da ideia de um pequeno servidor (“servidorzinho”, em
inglês) cujo objetivo é receber chamadas HTTP, processá-las e devolver uma res-
posta ao cliente. É um objeto Java que recebe tais requisições (request) e produz
algo (response),como uma página HTML dinamicamente gerada [17]. O servlet será
usado neste projeto para manipulação dos dados nas camadas de aplicação.
2.2.1.2 SERVIDOR DE APLICAÇÃO E SERVLET CONTAINER
Servidor de aplicação é um software que implementa um conjunto de es-
pecificações do Java, que atendem a requisitos não-funcionais, como persistência
em banco de dados, transação, acesso remoto, web services, gerenciamento de th-
reads, gerenciamento de conexões HTTP, cache de objetos, gerenciamento da ses-
são web, balanceamento de carga, entre outros.
A vantagem de usar um servidor de aplicação é facilitar e dar suporte ao
desenvolvimento de aplicações em Java, proporcionando ao desenvolvedor a como-
30
didade de só focar nos requisitos funcionais do sistema. Não precisa, por exemplo,
de escrever um código em detalhes para acessar uma conexão, serviço que o servi-
dor de aplicação oferece.
Existem vários servidores de aplicação no mercado, como o Jboss, o
GlassFish, o Apache Geronimo, o SAP, entre outros.
Há casos em que não temos a necessidade de todas as características de
um servidor de aplicação, e sim de somente algumas específicas, como de especifi-
cações voltadas para o desenvolvimento Web. Dessa necessidade surgiu o Servlet
Container, um servidor que suporta essas funcionalidades, mas não todas do Java
EE [17].
Neste projeto será usado o Apache TomCat versão 7.0, um servlet contai-
ner gratuito e de ampla utilização no mercado de trabalho.
2.2.1.3 FERRAMENTA PARA DESENVOLVIMENTO EM JAVA.
IDE, do inglês Integrated Development Environment ou Ambiente Integra-
do de Desenvolvimento, é um programa de computador que reúne características e
ferramentas de apoio ao desenvolvimento de software com o objetivo de agilizar
este processo. Existem várias ferramentas para desenvolvimento em Java no mer-
cado, como o NetBeans, o BlueJ e o Eclipse.
Neste projeto será usado o Eclipse IDE for Java EE Developers versão
1.3.2, uma IDE para desenvolvimento Java gratuita e largamente utilizada por de-
senvolvedores. Será usada a linguagem Java na sua versão 1.6.0 (Java 6).
31
3 ESPECIFICAÇÃO DO PROJETO
Neste capítulo abordaremos uma apresentação em detalhes do projeto,
como seu objetivo, requisitos funcionais e não funcionais, casos de uso, diagrama
de classes, diagramas de sequência, o modelo de banco de dados e as telas de
apresentação.
3.1 OBJETIVO E APRESENTAÇÃO DO SISTEMA
O sistema tem como propósito, gerenciar dados médicos e fornecer dados
para pesquisas estatísticas, com acesso via web, feito tanto por pacientes quanto
profissionais de saúde. Os pacientes podem consultar a rede credenciada, visualizar
seu cadastro e seu prontuário. Os médicos poderão criar um prontuário, consultar
dados, desde que autorizados pelo paciente, e ainda, inserir novos dados neste. O
pesquisador na área da saúde com acesso a este sistema poderá realizar pesquisas
baseadas em dados coletados dos prontuários sem vínculo aos dados pessoais de
seus proprietários.
O sistema será construído em uma arquitetura de três camadas como de-
finidas no Capítulo 2:
Camada de armazenamento: Composta por um banco de dados centrali-
zado para armazenamento dos dados cadastrais e prontuários dos pacientes, e da-
dos cadastrais de profissionais e instituições conveniadas a rede. Será construído
usando o SGBD MySQL e modelado pelo MySQL WorkBench.
Camada de aplicação: Camada intermediária entre a apresentação e o
armazenamento, responsável pelo tratamento dos dados recebidos das camadas
seguintes. Será composta pela classe que fará conexão com o banco de dados,
classes que espelham as entidades do modelo de classes e receberão dados do
32
SGBD e classes que irão tratar as requisições da camada de apresentação proces-
sá-las e gerar respostas (servlets). Utilizando a linguagem Java para construção
desta camada, foram implementadas classes correspondentes as tabelas do banco
de dados, com métodos para tratamento dos dados de acordo com as regras de ne-
gócio, e implementados os servlets, que são as classes para tratamento das requisi-
ções e respostas à camada de apresentação e à camada de armazenamento. No
Apêndice A e B são mostrados trechos de códigos de algumas destas classes.
Camada de apresentação: Camada onde os dados serão exibidos ao cli-
ente via navegador e também os dados serão colhidos do cliente. Será composta
por páginas HTML, no caso de não haver necessidade de tratamento dos dados
para exibição e envio a camada de aplicação, e páginas JSP, no caso contrário.
Estas três camadas ficarão num servidor único a ser acessado via web.
Para gerenciamento das camadas de aplicação e apresentação usaremos o servidor
TomCat.
3.2 REQUISITOS DO SISTEMA
A seguir apresentaremos os requisitos do sistema, como os funcionais,
que descrevem as funcionalidades do sistema (o que o sistema tem de fazer), e os
não funcionais que descrevem qualidades do sistema (em geral se relacionam com
padrões de qualidade como confiabilidade, performance, robustez, etc.). Os requisi-
tos foram selecionados de acordo com a pesquisa levantada para este projeto.
3.2.1 FUNCIONAIS
Listamos abaixo alguns dos requisitos funcionais do sistema:
•O sistema deve permitir o cadastro de pacientes e profissionais de saúde.
•O sistema deve impedir que o paciente altere o próprio cadastro.
33
•O sistema deve permitir a criação de prontuário de pacientes pelos médicos.
•O sistema deve permitir a inserção de dados no prontuário do paciente.
•O sistema deve impedir que o médico insira dados em seu próprio prontuário.
•O sistema deve impedir que os dados inseridos no prontuário sejam alterados.
•O sistema deve impedir que paciente e profissional tenham mais de um cadastro.
•O sistema deve impedir que o paciente tenha mais de um prontuário.
•O sistema deve permitir consultas estatísticas sobre dados de prontuários.
3.2.1 NÃO FUNCIONAIS
Nesta seção, listamos alguns exemplos de requisitos não funcionais do
sistema:
•O sistema deve ter acesso via web.
•O sistema deve ter segurança contra violação de dados.
•O sistema deve ter interface amigável.
3.1 CASOS DE USO
Casos de uso é a descrição das interações entre os usuários e o sistema.
A seguir descreveremos em detalhes os casos de uso relacionados ao nosso siste-
ma bem como os atores relacionados:
34
3.1.1 IDENTIFICAÇÃO DOS ATORES
Atores são os elementos que interagem com o sistema nos casos de uso,
podem ser pessoas, dispositivos ou outros sistemas.
Paciente – Fonte de dados para o sistema, objeto principal de consulta.
Médico – Principal contato com o paciente, quem inicia o prontuário do
mesmo.
Pesquisador – Assim denominado aqui, seria o profissional de saúde que
teria o acesso aos dados de forma estatística, sem conotação individual.
Atendente – Com acesso limitado a partes do cadastro de pacientes e
médicos.
Administrador – Quem gerencia o cadastro dos profissionais e monitora
os alertas no sistema.
Profissional – Uma generalização para médico, pesquisador, atendente e
administrador.
3.1.2 DIAGRAMA DE CASOS DE USO
É uma representação gráfica dos casos de uso. Na Ilustração 4 mostra-
mos o diagrama de casos de uso do sistema.
Ilustração 4: Diagrama de casos de uso
36
3.1.3 LISTA DOS CASOS DE USO
C1 – Acesso ao sistema - profissional.
C2 – Atendente consulta cadastro.
C3 – Atendente cadastra paciente.
C4 – Cadastramento/alteração de senha.
C5 – Administrador cadastra profissionais de saúde.
C6 – Administrador consulta/altera cadastro de profissionais de saúde.
C7 – Paciente consulta rede credenciada.
C8 – Paciente acessa o sistema.
C9 – Paciente consulta cadastro.
C10 – Medico cadastra prontuário do paciente.
C11 – Paciente autoriza medico acesso a seu prontuário.
C12 – Paciente consulta próprio prontuário.
C13 – Médico acessa prontuário do paciente.
C14 – Pesquisador faz consultas estatísticas.
C15 – Administrador monitora alertas do sistema.
37
3.1.1 DESCRIÇÃO DOS CASOS DE USO
C1- Acesso ao sistema - profissional.
Objetivo: Garantir ao profissional acesso às funcionalidades do sistema.
Atores: Profissional - atendente, médico, pesquisador e administrador.
Pré-condições: usuário precisa ter cadastro no sistema.
Trigger: Acesso à tela inicial do sistema.
Fluxo principal:
1 – O usuário (profissional), acessa a tela inicial do sistema;
2 – O usuário clica no botão de acesso a profissional;
3 – O usuário insere matrícula e senha nos respectivos campos e cli-
ca no botão específico;
4 – O sistema realiza a autenticação do usuário;
4.1 – Se autenticação bem sucedida exibe tela principal específica
ao profissional.
4.2 – Se autenticação mal sucedida exibe mensagem de erro.
Fluxo alternativo: Não há.
Extensões: O sistema no item 4 verifica o tipo de profissional para abrir a
tela principal específica.
Pós-condições: O sistema deve exibir a tela principal específica ao profis-
sional.
Regras de Negócio:
RN1 – O profissional deve ter cadastro e senha.
RN2 – O paciente não pode ter acesso a tela principal específica do
profissional, sendo identificado no item 4 do fluxo principal.
38
C2 - Atendente consulta / altera cadastro do paciente.
Objetivo: Permitir a consulta e alteração do cadastro do paciente pelo
atendente.
Atores: Atendente.
Pré-condições: Caso de uso C1 bem sucedido.
Trigger: Clique no botão de consulta a cadastro.
Fluxo principal:
1 – O usuário (Atendente) clica no botão de consulta a cadastro.
2 – O sistema exibe a tela com os campos.
3 – O usuário seleciona a opção de consulta (por nome ou por matrí-
cula).
4 – O usuário insere os dados de consulta nos campos (matrícula ou
nome).
5 – O sistema processa a consulta.
5.1– Se encontrado, o sistema exibe a tela do cadastro.
5.1.1 – Se necessário, o usuário faz as alterações nos
campos e clica em salvar.
5.2– Se não encontrado:
5.2.1 – Se não encontrado, exibir também na mensagem
de erro pergunta se deseja cadastrar o novo paciente:
5.2.1.1 – Se confirmado, vai para caso de uso C3.
5.2.1.2 – Se não, volta para o item 2.
Fluxo alternativo: Não há.
Extensões: Caso de uso C3.
Pós-condições: O sistema deve exibir a tela com a consulta do cadastro
solicitado, e salvar as alterações.
39
Regras de Negócio:
RN1 – O paciente deve estar cadastrado no sistema.
RN2 – O usuário deve estar logado ao sistema.
RN3 – Os campos exibidos devem estar limitados ao autorizado
para o profissional Atendente.
RN4 – O atendente não pode alterar o campo matrícula.
C3 - Atendente cadastra paciente
Objetivo: Permitir o cadastro de um novo paciente.
Atores: Atendente.
Pré-condições: O atendente deve ter executado o caso de uso C1, o pa-
ciente não deve ter cadastro.
Trigger: Clicar no botão de cadastro de pacientes ou Caso de uso C2
item 5.2.1.1
Fluxo principal:
1 – O usuário (atendente) clica no botão de cadastro de pacientes.
2 – O sistema exibe uma tela com campos para preenchimento.
3 – O usuário insere as informações nos respectivos campos.
4 – O sistema executa a busca e exibe resultado:
4.1 – Se não encontrado cadastro: salva os dados e cria o ca-
dastro.
4.1.1 – O usuário clica em cadastrar senha - vai para o
caso de uso C4.
4.1.2 - O usuário clica em voltar.
40
4.2 – Se encontrado cadastro, exibe mensagem com lista para
verificação:
4.2.1 – Se paciente consta na lista:
4.2.1.1– O usuário clica em ir a página de
consulta/alteração - vai para caso de uso C2.
4.2.1.2– O usuário clica em voltar.
Fluxo alternativo:
A1:
1 – Caso de uso C2 item 5.2.1.1
2 – O sistema exibe tela para cadastramento.
3 – O usuário insere os dados e clica em salvar.
4 - vai para caso de uso C4.
A2 :
1 – Fluxo principal até o item 4 e seus sub-itens.
2 – O usuário verifica os dados e não havendo dados a alterar, clica
em sair.
Extensões: caso de uso C4.
Pós-condições: Deve ser exibida uma tela de cadastramento do pacien-
te.
Regras de Negócio:
RN1 – Só deve haver um cadastro por paciente.
RN2 – O usuário precisa estar logado para fazer o cadastro.
C4 – Cadastramento/alteração de senha.
Objetivo: Permitir o cadastramento e a alteração da senha.
41
Atores: Usuário autorizante (Atendente, Administrador) e cliente (pacien-
te, profissional)
Pré-condições: Caso de uso C1 bem sucedido, Cliente (paciente ou pro-
fissional) com cadastro no sistema.
Triggers: Clicar no link de cadastramento/alteração de senha de paciente;
caso de uso C3- item 6 do fluxo principal ou item 4 do fluxo alternativo A1;
ou caso de uso C5 item 6.
Fluxo principal:
1 – O usuário (autorizante) clica no botão de cadastro/alteração de
senha de paciente.
2 – O sistema exibe uma tela com campos de matrícula, senha, con-
firmação de senha, matrícula de usuário, senha de usuário autori-
zante e uma caixa de checagem de alteração:
2.1 – Se o usuário não selecionar a caixa de checagem:
2.1.1 – O cliente preenche os campos matrícula, senha e
confirmação de senha e clica em cadastrar.
2.1.2 – O usuário preenche os campos matrícula de usuá-
rio e senha de usuário.
2.1.3 – Vai para o item 3.
2.2 - Se o usuário seleciona a caixa de checagem de alteração:
2.2.1 – O Sistema exibe na mesma tela ainda os campos
de senha anterior e mais um de checagem de alteração
sem senha anterior:
2.2.1.1– Se caixa de checagem de alteração sem se-
nha não for selecionada:
2.2.1.1.1 - O cliente preenche os campos matrí-
cula, senha anterior, senha e confirmação de
senha e clica em cadastrar.
2.2.1.1.2 – Vai para o item 4.
42
2.2.1.2 – Se caixa de checagem de alteração sem
senha for selecionada:
2.2.1.2.1 - O cliente preenche os campos ma-
trícula, senha e confirmação de senha.
2.2.1.2.2 – O usuário preenche o campo matrí-
cula de usuário, senha e clica em cadastrar.
2.2.1.2.3 – Vai para o item 3.
3 – Se caixa de checagem de alteração sem senha selecionada ou
caixa de checagem de alteração não selecionada:
3.1 – Se senha usuário confere, trata senha do paciente:
3.1.1 – Se senha nova dentro dos parâmetros e igual
campo senha confirmação, salva senha nova.
3.1.2 – Se não, exibe mensagem de erro, volta para o
item anterior ao desvio (2.1.3 ou 2.2.1.2.1).
3.2 – Se não, exibe mensagem de erro e vai para item anterior
a este desvio (2.2.1.2.2 ou 2.1.2).
4 – Se caixa de checagem de alteração sem senha não seleciona-
da:
4.1 – O sistema verifica senha anterior:
4.1.1 – Se senha anterior confere, trata senha nova:
4.1.1.1 – Se senha nova dentro dos parâmetros e
igual campo senha confirmação, salva senha.
4.1.1.2 – Se não, exibe mensagem de erro, volta ao
item 2.2.1.1.1.
4.1.2 – Se senha anterior não confere, exibe mensagem
de erro, volta ao item 2.2.1.1.1.
5 – O usuário clica em voltar.
Fluxo alternativo:
A1:
43
1 – Caso de uso C3 - item 6 do fluxo principal.
2 – O sistema exibe uma tela com campos de matrícula, senha, con-
firmação de senha, senha de usuário autorizante.
3 – O cliente preenche os campos matrícula, senha e confirmação
de senha e clica enter.
4 – O usuário preenche os campos matrícula de usuário e senha de
usuário.
5 – Se senha usuário confere, trata senha do paciente:
5.1 – Se senha nova dentro dos parâmetros e igual campo se-
nha confirmação, salva senha nova, vai para o item 7.
5.2 – Se não, exibe mensagem de erro, volta para o item 3
6 – Se não, exibe mensagem de erro e vai para item anterior 4.
7 – O usuário clica em voltar.
A2:
1 – Caso de uso C3 - item 4 do fluxo alternativo A1.
2 – vai para o item 2 do A1 do fluxo principal deste caso de uso (C4).
A3:
1 – Caso de uso C5 – item 6.
2 – vai para o item 2 do A1 do fluxo principal deste caso de uso (C4).
Extensões: não há.
Pós-condições: O sistema deve salvar a nova senha do paciente ou exi-
bir mensagem de erro.
Regras de Negócio:
RN1 – O Cliente (paciente ou profissional) deve ter cadastro.
RN2 – No cadastramento e alteração sem senha anterior, o usuário
deve colocar sua senha autorizando.
RN3 – O cadastramento de senha de profissional só pode ser feito
pelo administrador.
44
RN4 – O cadastramento de senha do paciente é feito pelo atendente.
C5 - Administrador cadastra Profissional.
Objetivo: Cadastrar o profissional.
Atores: Administrador.
Pré-condições: Administrador conectado ao sistema (Caso de uso C1).
Trigger: clicar no botão de cadastro de Profissional.
Fluxo principal:
1 – O usuário (administrador) clica no botão de cadastro de profissio-
nal.
2 – O sistema exibe uma tela com campos para preenchimento (in-
clusive um link para busca de matrícula pelo nome se não souber).
3 – O usuário insere as informações nos campos e clica em cadas-
trar.
4 – O sistema executa a busca e exibe resultado:
4.1 – Se não encontrado cadastro profissional, salva os dados
e cria o cadastro, exibindo link para o caso de uso C4.
4.2 – Se encontrado cadastro, exibe mensagem de erro – pro-
fissional já cadastrado.
4.3 – Se não encontrado cadastro profissional, nem de pacien-
te, exibe mensagem de erro
5 – O usuário clica em voltar.
Fluxo alternativo: não há.
Extensões: Caso de uso C4.
Pós-condições: O sistema deve salvar o novo cadastro.
Regras de Negócio:
45
RN1 – Somente o administrador pode cadastrar/atualizar o profissio-
nal.
RN2 – Cada profissional só pode ter um cadastro.
C6 - Administrador consulta/altera cadastro de profissionais de saúde.
Objetivo: Consulta/alteração do cadastro de um profissional existente.
Atores: Administrador.
Pré-condições: Caso de uso C1; profissional com cadastro no sistema.
Trigger: Clicar no link consulta/altera cadastro profissional.
Fluxo principal:
1 – O usuário (administrador) clica no botão de consulta/altera ca-
dastro de profissional.
2 – O sistema exibe a tela com os campos (inclusive um link para
busca de matrícula pelo nome se não souber).
3 – O usuário insere a matrícula no campo e clica em visualizar.
4 – O sistema processa a consulta.
4.1– Se encontrado o sistema exibe a tela do cadastro.
4.1.1 – O usuário faz as alterações e clica em salvar.
4.1.2 – O usuário clica em voltar.
4.2– Se não encontrado, exibir também na mensagem de erro
pergunta se deseja cadastrar o novo profissional:
4.2.1.1 – Se confirmado vai para caso de uso C5.
4.2.1.2 – Se não, volta para o item 2.
5 – O usuário clica em voltar.
Fluxo alternativo: Não há.
46
Extensões: Caso de uso C5.
Pós-condições: O sistema deve exibir a tela de cadastro.
Regras de Negócio:
RN1 – O administrador precisa estar logado no sistema
RN2 – O profissional precisa ter cadastro.
C7 - Paciente consulta rede credenciada.
Objetivo: Permitir a consulta da rede de atendimento pelo paciente.
Atores: Paciente.
Pré-condições: não há.
Trigger: Paciente clica na opção de consulta a rede credenciada.
Fluxo principal:
1 – O usuário (paciente) entra na tela inicial.
2 – O usuário clica na opção de consulta a rede credenciada.
3 – O sistema exibe uma tela com as opções de pesquisa de médi-
cos por nome, especialidade e pesquisa por instituições.
3.1 – Se selecionado busca por especialidade o sistema exibe
uma tela com os campos.
3.1.1 – O usuário preenche os campos, seleciona a espe-
cialidade e clica em pesquisar. Vai para o item 4.
3.2 – Se selecionado busca por nome, o sistema exibe uma
tela com o campo para inserir o nome do médico.
3.2.1 - O usuário preenche o campo e clica em pesquisar.
Vai para o item 4.
3.3 – Se selecionado busca por instituição, o sistema exibe
uma tela com o campo de nome de instituição.
47
3.3.1 - O usuário preenche o campo e clica em pesquisar.
Vai para o item 4.
4 – O sistema processa a consulta e exibe lista com o resultado.
4.1 – Se for consulta a médico:
4.1.1 - O usuário seleciona na lista.
4.1.2 – O O sistema exibe mais detalhes do médico sele-
cionado:
4.2 – Se for consulta a instituição, o sistema exibe uma lista
com o resultado ou mensagem de erro se não encontrar.
5 – O usuário clica em voltar.
Fluxo alternativo: Não há.
Extensões: Não há.
Pós-condições: O sistema exibe dados do médico ou instituição pesqui-
sados.
Regras de Negócio:
RN1 – O paciente pode consultar os dados da rede credenciada
mesmo sem cadastro e senha.
C8 - Paciente acessa o sistema.
Objetivo: Permitir ao paciente acesso a telas restritas a paciente cadas-
trado.
Atores: Paciente.
Pré-condições: Paciente deve ter cadastro.
Trigger: Paciente clica em “Acesso a paciente cadastrado”.
Fluxo principal:
1 – O usuário (paciente) clica no botão de acesso a paciente.
48
2 – O usuário clica em “Acesso a paciente cadastrado”.
3 – O sistema exibe uma tela com campos matrícula e senha.
3 – O usuário preenche os campos e clica no botão entrar.
4 – O sistema faz a autenticação:
4.1 – Se com sucesso abre a tela com as opções.
4.2 – Se não, exibe mensagem de erro.
5 – O paciente clica em voltar.
Fluxo alternativo: Não há.
Extensões: Não há.
Pós-condições: O sistema deve exibir tela de acesso a paciente cadas-
trado.
Regras de Negócio:
RN1 – O paciente deve estar cadastrado.
C9 - Paciente consulta cadastro.
Objetivo: Permitir ao paciente consultar seu próprio cadastro.
Atores: Paciente.
Pré-condições: Caso de uso C8 bem sucedido.
Trigger: Clicar no link de consulta ao próprio cadastro na tela de acesso a
paciente cadastrado.
Fluxo principal:
1 – O usuário (paciente) clica no link de consulta a seu cadastro.
2 – O sistema exibe tela com os dados do seu cadastro.
2.1 – Se detectar algo inconsistente, o usuário pode clicar no
link de envio de mensagem e comunicar a inconsistência.
49
3 – O usuário clica em voltar.
Fluxo alternativo: não há.
Extensões: não há.
Pós-condições: O sistema emite tela com cadastro do paciente.
Regras de Negócio:
RN1 – O paciente precisa ter cadastro e senha para fazer a consulta.
RN2 – O paciente não pode alterar dados do seu cadastro.
RN3 – Se verificada uma divergência, o paciente pode enviar uma
mensagem notificando.
C10 - Médico cadastra prontuário do paciente.
Objetivo: Permitir ao médico o cadastro do prontuário do paciente.
Atores: Médico.
Pré-condições: O paciente precisa ter cadastro no sistema, o médico pre-
cisa estar logado no sistema (Caso de uso C1 bem sucedido).
Trigger: Médico clica em cadastrar prontuário.
Fluxo principal:
1 – O médico clica em cadastrar prontuário.
2 – O sistema exibe uma tela com campo de matricula do paciente,
matrícula do médico e senha.
3 – O médico preenche os campos: matrícula do paciente, sua matrí-
cula e sua senha.
4 – O sistema verifica se o prontuário relativo a matrícula informada
existe, e se sua senha/matrícula está correta:
4.1 – Se existir, exibe mensagem de erro.
50
4.2 – Se a matrícula do médico ou sua senha estiver incorreta,
exibe mensagem de erro.
4.2 – Se não existir prontuário e senha e matrícula do médico
estiverem corretas, o sistema cadastra uma linha de criação do
prontuário no banco de dados.
5 – O sistema exibe confirmação com o número e código de autori-
zação.
6 – O médico informa ao paciente o número e o código de autoriza-
ção.
7 – O médico clica em voltar.
Fluxo alternativo: Não há.
Extensões: não há.
Pós-condições: O sistema deve exibir tela de cadastramento e salvar os
dados.
Regras de Negócio:
RN1 – O paciente só pode ter um prontuário.
RN2 – O médico não pode cadastrar seu próprio prontuário.
C11 - Paciente autoriza médico acesso a seu prontuário.
Objetivo: Permitir o acesso pelo médico ao prontuário do paciente.
Atores: Médico.
Pré-condições: O paciente precisa ter prontuário criado, e ter o código de
autorização; O médico precisa estar logado no sistema.
Trigger: O médico clica em autorizar prontuário.
Fluxo principal:
1 – O médico clica em autorizar prontuário.
51
2 – O sistema exibe tela com campos matrícula, código de autoriza-
ção, matrícula do médico e senha.
3 – O médico preenche os campos sua matrícula, sua senha e com
dados fornecidos pelo paciente.
4 – O sistema verifica os dados:
4.1 – Se confirmado, o sistema cadastra a autorização de aces-
so ao prontuário.
4.2 – Se não, exibe mensagem de erro.
5 – O médico clica em sair.
Fluxo alternativo:
A1: (paciente impossibilitado de dar o código)
1 – O médico clica no link de cadastramento sem código de autoriza-
ção.
2 – O sistema exibe tela com campos matrícula, código de autoriza-
ção e matrícula do responsável.
3 – O médico preenche os campos com dados matrícula e com o có-
digo especial de autorização que já possui.
4 – O sistema verifica os dados:
4.1 – Se confirmado, o sistema cadastra a autorização de aces-
so ao prontuário e imprime autorização especial a ser assinada
pelo próprio ou por responsável.
4.2 – Se não, exibe mensagem de erro.
5 – O médico clica em sair.
Extensões: o sistema pode imprimir um documento de autorização tam-
bém no fluxo principal.
Pós-condições: O sistema deve cadastrar a autorização pra acesso ao
prontuário.
Regras de Negócio:
52
RN1 – O médico que cria o prontuário já possui automaticamente au-
torização.
RN2 – A autorização deve se dar uma só vez somente.
C12 - Paciente consulta próprio prontuário.
Objetivo: Permitir ao paciente consultar o próprio prontuário.
Atores: Paciente.
Pré-condições: Caso de uso C8 bem sucedido
Trigger: O paciente clica na opção de visualizar o próprio prontuário.
Fluxo principal:
1 - O usuário (paciente) clica na opção de visualizar o próprio prontu-
ário.
2 – O sistema exibe o prontuário do paciente ou tela de erro se não
existir.
3 – O usuário clica em voltar.
Fluxo alternativo: Não há.
Extensões: Não há.
Pós-condições: O sistema deve exibir o prontuário do paciente.
Regras de Negócio:
RN1 – O paciente pode consultar somente seu próprio prontuário.
RN2 – O paciente não pode alterar seu prontuário.
53
C13 - Médico acessa prontuário do paciente.
Objetivo: Permitir o acesso ao prontuário do paciente pelo médico.
Atores: Médico.
Pré-condições: O médico precisa estar logado (caso de uso C1 bem su-
cedido); O médico precisa estar autorizado pelo paciente (caso de uso
C11 bem sucedido).
Trigger: O médico clica na opção de acesso ao prontuário do paciente em
sua tela principal.
Fluxo principal:
1 - O médico clica na opção de acesso ao prontuário do paciente em
sua tela principal.
2 – O sistema exibe uma tela com campo para matrícula do paciente,
matrícula do médico e senha.
3 – O médico preenche os campos e clica em visualizar.
4 – O sistema verifica se o médico tem autorização para o paciente
informado:
4.1 – Se sim, exibe tela de opção de visualização, vai para o
item 5.
4.2 – Se não, exibe mensagem de erro, vai o item 2.
5 – O médico seleciona a opção na tela de visualização/inserção:
5.1 – Se visualização de todo o prontuário, o sistema exibe tela
com o prontuário.
5.2 - Se visualização por evento específico, o sistema exibe
tela com campos para pesquisa:
5.2.1 – O médico seleciona o evento e clica em pesquisar.
5.2.2 – O sistema exibe o resultado da pesquisa.
5.2.3 – O médico clica em voltar.
54
5.3 – Se inserção de dados, o sistema exibe tela com campos
para inserção.
5.3.1 – O médico preenche os campos.
5.3.1.1 – Se retificação de registro anterior, o médico
também preenche no campo descrição de evento
que o registro inserido retifica um registro anterior,
identificado pelo seu número.
5.3.2 – O médico clica em salvar.
6 – O médico clica em voltar.
Fluxo alternativo: não há.
Extensões: não há.
Pós-condições: O sistema deve exibir o prontuário do paciente.
Regras de Negócio:
RN1 – O Sistema não pode permitir alteração de dados no prontuá-
rio, só inserção de novos.
RN2 – O médico precisa estar autorizado para acessar o prontuário
do paciente.
RN3 – O médico não pode inserir dados em seu próprio prontuário.
C14 - Pesquisador faz consultas estatísticas.
Objetivo: Permitir ao pesquisador fazer consultas estatísticas.
Atores: Pesquisador.
Pré-condições: Pesquisador deve ter realizado o caso de uso C1 com
sucesso.
Trigger: Pesquisador realiza caso de uso C1 com sucesso.
Fluxo principal:
55
1 – O pesquisador realiza caso de uso C1 com sucesso.
2 – O sistema exibe as telas com opções de pesquisa.
3 – O pesquisador seleciona a opção desejada.
4 – O sistema exibe tela com campos para inserção de parâmetros.
5 – O pesquisador preenche os campos e clica em executar.
6 – O sistema processa a pesquisa e exibe tela com resultados.
7 – O pesquisador clica em voltar ou sair.
Fluxo alternativo: não há.
Extensões: Opção de impressão da pesquisa.
Pós-condições: O sistema exibe o resultado da pesquisa.
Regras de Negócio:
RN1 – O sistema não pode exibir dados cadastrais entre os dados
pesquisados.
RN2 – A pesquisa não pode se resumir a um paciente.
RN3 – O sistema não pode exibir dados com informações confiden-
ciais e que identifiquem um paciente.
C15 - Administrador monitora alertas do sistema.
Objetivo: Permitir ao Administrador verificar as mensagens salvas no sis-
tema.
Atores: Administrador.
Pré-condições: Administrador realiza caso de uso C1 com sucesso.
Trigger: O Administrador clica na opção de verificação de mensagens.
Fluxo principal:
1 – O administrador clica na opção de verificação de mensagens.
56
2 – O sistema exibe uma tela com as opções de verificação de men-
sagens.
3 – O administrador clica na opção desejada.
3.1 – Se visualizar todas as mensagens, o sistema exibe tela
com as mensagens.
3.2 – Senão, vai para o item 4.
4 – O sistema exibe tela correspondente com campos para pesquisa.
5 – O administrador preenche os campos e clica em enviar.
6 – O sistema exibe tela com mensagens.
7 – O administrador verifica as mensagens:
7.1 – Se destinada a outro profissional, encaminha mensagem.
7.2 - Se de sua competência, após resolução, dá baixa.
8 – O administrador clica em sair.
Fluxo alternativo: não há.
Extensões: não há.
Pós-condições: O sistema exibe tela com mensagens.
Regras de Negócio:
RN1 – O administrador precisa estar logado ao sistema
57
3.1 DIAGRAMA DE CLASSES CONCEITUAL
O diagrama de classes conceitual representa as principais classes que
compõe a camada de aplicação do sistema. O objetivo destas classes é processar
os dados de acordo com as regras de negócios estabelecidas no levantamento dos
requisitos e dos casos de uso.
Apresentamos na Ilustração 5 uma modelagem conceitual das classes do
sistema, mostrando as principais classes, e os relacionamentos entre elas. Por sim-
plificação e melhor visualização da ilustração, foram omitidos alguns atributos e ope-
rações de classe, ficando os mais representativos. Pelo mesmo motivo, foram omiti-
das algumas classes de manipulação de dados da camada de aplicação como ser-
vlets e a classe de conexão com o SGBD que é acessada por todas as classes do
diagrama.
As classes no diagrama são representadas por uma caixa dividida em três
partes: a superior contém o nome da classe, a intermediária é reservada aos atribu-
tos da classe, e a parte inferior contém os principais métodos desta classe. Os rela-
cionamentos são representados por linhas que podem apresentar alguns símbolos
de acordo com o tipo de associação. Junto a esta linha temos um nome descreven-
do a associação, como por exemplo, na associação entre a classe Profissional e a
classe Instituição, temos o relacionamento “está lotado”, que mostra que um profis-
sional trabalha em uma determinada instituição (de acordo com a cardinalidade re-
presentada pelos números nas extremidades da linha de associação). A generaliza-
ção neste diagrama pode ser vista na classe Profissional, que é uma generalização
das classes Médico, Pesquisador, Atendente e Pesquisador. A classe Profissional
também é uma especialização da classe Pessoa. Estas generalizações/especializa-
ções são representadas por um triângulo na extremidade da linha de associação jun-
to a classe mais geral.
Ilustração 5: Diagrama de classes conceitual
59
3.2 DIAGRAMAS DE SEQUÊNCIA
Apresentamos nesta seção alguns diagramas de sequência dos casos de
uso mais complexos como: Atendente cadastra paciente; Paciente consulta rede
credenciada; Médico cadastra prontuário do paciente; Pesquisador faz consultas es-
tatísticas; Administrador cadastra de profissionais de saúde; Médico acessa prontuá-
rio do paciente.
3.2.1 ATENDENTE CADASTRA PACIENTE:
O diagrama presente na Ilustração 6, mostra a interação do atendente
com o sistema para fazer o cadastramento do paciente como descrito no caso de
uso C3 na Subseção 3.3.4.
Ilustração 6: Diagrama de sequência - Atendente cadastra paciente
60
3.2.2 PACIENTE CONSULTA REDE CREDENCIADA:
Na Ilustração 7 mostramos de uma forma simplificada a interação do paci-
ente com o sistema na consulta da rede credenciada buscando dados sobre médi-
cos e instituições, como descrito no caso de uso C7 na Subseção 3.3.4.
Ilustração 7: Diagrama de sequência - Paciente consulta rede credenciada
61
3.2.3 MÉDICO CADASTRA PRONTUÁRIO DO PACIENTE.
Na Ilustração 8 é mostrada a interação entre médico, paciente e sistema,
no cadastramento do prontuário do paciente, simplificando o descrito no caso de uso
C10 na Subseção 3.3.4.
Ilustração 8: Diagrama de sequência - Médico cadastra prontuário do paciente.
62
3.2.4 PESQUISADOR FAZ CONSULTAS ESTATÍSTICAS.
O diagrama de sequência na Ilustração 9, mostra a interação do pesqui-
sador com o sistema executando pesquisas estatísticas. Representação do caso de
uso C14 na Subseção 3.3.4.
Ilustração 9: Diagrama de sequência - Pesquisador faz consultas estatísticas.
63
3.2.5 ADMINISTRADOR CADASTRA DE PROFISSIONAIS DE SAÚDE.
O diagrama mostrado na Ilustração 10 refere-se a interação entre o admi-
nistrador e o sistema, no cadastramento de um profissional de saúde, relatado em
detalhes no caso de uso C5 da Subseção 3.3.4.
Ilustração 10: Diagrama de sequência - Administrador cadastra profissional
64
3.2.6 MÉDICO ACESSA PRONTUÁRIO DO PACIENTE.
No diagrama de sequência exibido na Ilustração 11 temos a representa-
ção simplificada do caso de uso C13 da Subseção 3.3.4, que descreve a interação
do médico com o sistema quando ocorre o acesso ao prontuário do paciente.
Ilustração 11: Diagrama de sequência - Médico acessa prontuário
65
3.2.7 CADASTRAMENTO/ALTERAÇÃO DE SENHA.
A Ilustração 12 mostra de maneira simplificada a interação entre o profis-
sional, o paciente ou outro profissional, e o sistema no cadastramento ou alteração
da senha conforme detalhado no caso de uso C4 da Subseção 3.3.4.
Ilustração 12: Diagrama de sequência - Cadastramento/alteração de senha
66
3.3 MODELO DO BANCO DE DADOS
O modelo de banco de dados representa a camada de armazenamento
que compõe a arquitetura do sistema web deste trabalho. O objetivo desta camada é
armazenar os dados cadastrais e prontuários dos pacientes, além de dados cadas-
trais de profissionais e instituições conveniadas a rede.
Optou-se para este projeto, a implementação de uma arquitetura cliente-
servidor centralizada. Em comparação com uma arquitetura descentralizada, tem-se
a vantagem de oferecer dados em tempo real e ter um desenvolvimento mais fácil e
simples, mas com a desvantagem de dependência maior da rede, em que uma falha
pode comprometer a transferência, arquivamento e busca dos dados. Em contrapar-
tida, em uma base descentralizada (como exemplo, em cada instituição) temos a
vantagem de nos reguardarmos de problemas de rede, com a transferência periódi-
ca de informação, o que compromete o levantamento dos dados em tempo real.
A Ilustração 14 mostra a modelagem do banco de dados do sistema.
Cada caixa na ilustração, representa uma tabela no banco de dados e cada campo é
um atributo, sendo que cada tabela possui sua chave primária, representada por um
simbolo de uma chave dourada, e possivelmente chaves estrangeiras, representa-
das por um símbolo de um losango vermelho. O esquema mostrado na Ilustração 13
ajuda o entendimento do modelo.
67
Ilustração 13: Descrição dos componentes de um modelo de banco de dados
Ilustração 14: Modelo de banco de dados
69
3.4 DESCRIÇÃO DAS CLASSES
Basicamente, neste sistema existem dois tipos de classes: as classes cor-
respondentes as tabelas no banco de dados, e os servlets. Estas classes compõem
a camada de aplicação do sistema, responsável pelo processamento dos dados en-
tre a camada de apresentação e a de armazenamento. Optou-se em colocar em to-
das as classes correspondentes ao BD, métodos de inserção, busca, e atualização
junto ao banco de dados, em vez de criar classes separadas para esta função (as
chamadas classes DAO). Tal prática visa facilitar a implementação do programa,
mas tem como consequência um prejuízo a reutilização.
3.4.1 A CLASSE CONEXÃO, A CLASSE PESQUISA E AS CLASSES CORRES-
PONDENTES AS TABELAS DO BANCO DE DADOS.
•Conexão – Classe responsável pela conexão com o banco de dados.
•Pesquisa – Classe responsável pela execução de pesquisas estatísticas.
•Pessoa – Classe correspondente a tabela Pessoa no banco de dados. Esta
classe é a base do cadastramento de pacientes e profissionais, possuindo
os atributos relativos ao cadastramento, como nome, identidade, endere-
ço, data de nascimento, entre outros. O cadastro do paciente corresponde
a esta classe.
•Profissional – Classe correspondente a tabela ProfissionalSaude no banco de
dados. É uma extensão da classe Pessoa. Possui atributos que a espe-
cializam em relação a classe superior, como matrícula de funcionário, es-
pecialidade, código da função (atributo que identifica a especialização na
tabela Profissional – se o mesmo é médico, pesquisador, administrador ou
atendente), entre outros.
70
•ProfissionalSaude_diaHorarioAtend – Classe correspondente a tabela de
mesmo nome no banco de dados. Representa o relacionamento entre as
classes ProfissionalSaude e DiaHorarioAtend. Este relacionamento se fez
necessário porque um profissional (médico) pode ter horários diferentes
de atendimento em dias diferentes da semana.
•DiaHorarioAtend – Classe correspondente à tabela DiaHorarioAtend no ban-
co de dados. Recebe a combinação de dias da semana e horários de
atendimento.
•Prontuario – Classe correspondente à tabela Prontuario no BD. Possui atribu-
tos com campos para preenchimento de dados de prontuário, como tipo
de evento (pode ser consulta, realização de exame, procedimento cirúrgi-
co, entre outros), descrição do evento, diagnóstico, prescrição, data do
evento, anamnese (anotação do histórico do paciente), matrícula do paci-
ente (chave estrangeira na tabela Prontuario), entre outros. Cada inserção
na tabela Prontuario, corresponde a uma linha desta tabela, sendo que a
criação do prontuário sempre é a primeira linha correspondente a determi-
nada matrícula de paciente, implantada com código de evento 1 – criação
de prontuário, pelo servlet CadProntuario. No Apêndice A mostramos um
trecho de código em Java desta classe.
•Prontuario_autorizacao – Classe que corresponde à tabela de mesmo nome
no banco de dados, usada para cadastrar as autorizações de acesso ao
prontuário do paciente. Possui atributos que referenciam a matrícula do
paciente e do médico autorizado.
•Medicamento – Classe correspondente à tabela Medicamento no banco de
dados. O atributo código de medicamento corresponde a uma chave es-
trangeira na tabela Prontuario (colunas relativas a prescrição).
•Doenca – Classe que corresponde à tabela Doenca no BD. Também possui
atributos que correspondem a chave estrangeira na tabela Prontuario (co-
luna de diagnóstico).
•TipoEvento – Classe correspondente à tabela TipoEvento no banco de da-
dos. Utilizada no preenchimento do campo de tipo de evento no prontuá-
rio.
•Instituicao – Classe correspondente à tabela Instituicao no banco de dados.
Utilizada no cadastramento da instituição da rede de atendimento. Possui
71
um atributo que associa a classe Profissional – o código da instituição re-
presenta o atributo de lotação do profissional.
•Mensagem – Classe correspondente à tabela Mensagem no BD. Utilizada
para registro de mensagens entre o paciente e o profissional.
3.4.1 OS SERVLETS
•BuscaRedeCred – Classe utilizada no tratamento da busca de médicos e ins-
tituições da rede.
•VisualizaProfAgenda – Classe utilizada para montar visualização dos deta-
lhes de horário do médico selecionado na busca da rede credenciada.
•VisualizaCadEPront – Classe utilizada na visualização do cadastro e do pron-
tuário do próprio paciente.
•CadastraP – Classe utilizada para cadastramento de pessoas (pacientes e
profissionais).
•CadastraF – Classe utilizada para cadastramento de profissionais.
•VisualizaAlteraF – Classe utilizada para visualizar e alterar o cadastro do pro-
fissional.
•VisualizaAlteraP – Classe utilizada para visualizar e alterar o cadastro do pa-
ciente.
•CadProntuario – Classe utilizada no cadastramento do prontuário do pacien-
te.
•CadastraAutorizacao – Classe utilizada para cadastrar a autorização de aces-
so ao prontuário do paciente.
•AcessaPront – Classe utilizada no acesso ao prontuário.
•EnviaMsg – Classe utilizada para o envio de mensagens.
•PesquisaMsg – Classe utilizada para busca de mensagens recebidas.
•TrataMsg – Classe utilizada para tratamento das mensagens. Uma mensa-
gem recebida pode ser baixada ou repassada a outro profissional.
•TrataSenha – Classe utilizada no cadastramento e alteração de senha do pa-
ciente e do profissional.
72
•TrataLogin – Classe utilizada na autenticação do acesso do paciente cadas-
trado.
•TrataLoginF – Classe utilizada na autenticação do acesso do profissional.
Neste servlet, o sistema identifica também o tipo de profissional e abre a
página de acesso específica a ele.
•TratarPesquisa – Classe que verifica a solicitação de pesquisa da camada de
apresentação e chama o método correspondente na classe Pesquisa. No
Apêndice B mostramos um trecho de código em Java desta classe.
•TrataTabelas – Classe responsável pela inserção de dados nas tabelas,
Doenca, Medicamento, TipoEvento, ProfissionalSaude_diaHorarioAtend, e
Instituicao.
3.1 TELAS
As telas de um sistema compõem a camada de apresentação, como prin-
cipal interface com o usuário. Devem ter aparência amigável e boa funcionalidade,
pois através delas que o usuário visualizará os dados. Neste projeto, as telas são vi-
sualizadas através do navegador e, para tanto, são construídas em HTML e JSP.
Nesta seção apresentamos as telas do sistema e suas atribuições.
3.1.1 TELA PRINCIPAL.
A tela inicial do sistema é o ponto de partida tanto para profissionais quan-
to para pacientes. No lado esquerdo encontramos um botão de acesso a paciente e
um botão de acesso a profissional e abaixo, um link para voltar a página inicial. Este
menu lateral esquerdo sempre estará visível. A ilustração 15 mostra a tela principal.
73
3.1.2 TELAS RELACIONADAS AO PACIENTE
As ilustrações mostradas nesta seção referem-se às telas de acesso feito
pelo paciente no sistema. A Ilustração 16, mostra a tela inicial assim que clicamos
no botão de acesso ao paciente. A Ilustração 17 mostra o menu de busca da rede
credenciada, que pode ser feito mesmo sem ter cadastro no sistema, com as telas
relativas a cada opção de busca, representadas nas Ilustrações 18, 19, e 20. Na
Ilustração 21 temos a tela de login do paciente cadastrado, que é acessada quando
selecionamos o link acesso a paciente cadastrado na tela mostrada na Ilustração 16,
que redireciona à página mostrada na Ilustração 22. As telas oriundas de acesso a
visualização do cadastro e visualização do prontuário serão mostradas na seção 4.5
do Capítulo 4, como resultado dos testes.
Ilustração 15: Tela principal
74
Ilustração 16: Tela inicial do paciente
Ilustração 17: Tela de menu de busca de rede credenciada
75
Ilustração 18: Tela de busca de médicos por especialidade
Ilustração 19: Tela de busca de médicos por nome.
76
Ilustração 21: Tela de login do paciente.
Ilustração 20: Tela de busca por instituição
77
3.1.3 TELAS DE ACESSO PELO PROFISSIONAL
Esta seção mostra as telas relativas ao acesso feito pelo profissional. A
Ilustração 23 mostra a tela de login do profissional de saúde mostrada assim que há
o clique no botão de acesso profissional. O profissional preenche os campos de ma-
trícula e senha e clica em entrar. Então, o sistema efetua a autenticação e reconhe-
ce pela matrícula o tipo de profissional (administrador, médico, atendente ou pesqui-
sador). Em caso de autenticação com sucesso, exibe a tela inicial correspondente
ao profissional.
Ilustração 22: Tela para o paciente cadastrado.
78
No caso do profissional ser um administrador, sua tela inicial após o login
será como a mostrada na Ilustração 24. Esta tela descreve um menu com opções re-
lativas ao seu acesso. O primeiro link abre uma tela relativa a visualização e altera-
ção do cadastro de um profissional, mostrada na Ilustração 25. Abaixo deste link te-
mos um outro que direciona a uma tela de cadastramento de profissional mostrada
na Ilustração 26. Em seguida, um link para uma tela de monitoramento de mensa-
gens, mostrada na Ilustração 27. Por fim, temos dois links, um para cadastra-
mento/alteração de senha, mostrado na Ilustração 28 e outro para manutenção de
tabelas que é usado pelo administrador para inclusão de novos tipos de eventos de
prontuário, atualizar a tabela medicamento, entre outras funções. Sua tela é mostra-
da na Ilustração 29.
Ilustração 23: Tela de login do profissional de saúde.
79
Ilustração 24: Tela inicial do administrador.
Ilustração 25: Tela de visualização/alteração de cadastro de profissional.
80
Ilustração 26: Tela de cadastramento de novo profissional.
Ilustração 27: Tela de menu de visualização de mensagens
81
Ilustração 28: Tela de cadastramento/alteração de senha.
Ilustração 29: Tela de manutenção de tabelas.
82
Se o profissional logado no sistema for um médico, será mostrada uma
tela inicial como a da Ilustração 30. Esta tela consiste em um menu com links para
uma tela de cadastramento de prontuário, mostrada na Ilustração 31, para uma tela
de cadastramento de autorização de acesso ao prontuário de um paciente, mostrada
na Ilustração 32, e para telas de visualização de prontuários e de mensagens, mos-
tradas nas Ilustrações 33 e 27 respectivamente. A tela com o prontuário só é exibida
depois de confirmação positiva de autorização do médico de acordo com a matrícula
e senha inserida por este na tela de visualização de prontuário.
Ilustração 30: Tela inicial do médico.
83
Ilustração 31: Tela de cadastramento de prontuário.
Ilustração 32: Tela de cadastramento de autorização de acesso a um prontuário.
84
Para o profissional atendente logado no sistema, é exibida a tela mostra-
da na Ilustração 34. Esta tela possui três links. O primeiro deles direciona para uma
tela de parâmetros de busca para visualização e alteração do cadastro do paciente,
mostrada na Ilustração 35, que leva a uma tela seguinte com campos para visualiza-
ção e alteração, mostrada na Ilustração 36. O link seguinte no menu inicial do aten-
dente abre uma tela de cadastramento de paciente, mostrada na Ilustração 37. Fi-
nalmente temos um link para uma tela de cadastramento e alteração de senha que é
a mesma tela exibida ao administrador.
Acrescentamos que algumas opções da tela de cadastramento/alteração
de senha não funcionam para o atendente, como o cadastramento de senha de pro-
fissional. Para tanto exige-se que a matrícula do autorizante inserida seja de um ad-
ministrador. A tela de cadastramento de senha de paciente seguinte ao menu exibi-
do na ilustração 28 é mostrada na Ilustração 38. A tela de alteração de senha é mos-
trada na Ilustração 39. As telas relativas ao cadastramento e alteração de senha de
profissional são similares, diferenciando na senha do autorizante conferida pelo sis-
tema. A tela de cadastramento e consulta a cadastro de paciente também é acessa-
Ilustração 33: Tela de acesso ao prontuário.
85
da pelo administrador, pois antes de ser um profissional, todos são “pacientes” e
este cadastro serve de base para o cadastro pessoal do profissional.
Ilustração 34: Tela inicial do atendente.
Ilustração 35: Tela de inserção de parâmetro de busca para visualização/alteração de cadastro
86
Ilustração 36: Tela de visualização/alteração de cadastro do paciente.
Ilustração 37: Tela de cadastramento de paciente.
87
Ilustração 38: Tela de cadastramento de senha.
Ilustração 39: Tela de alteração de senha.
88
Finalmente, a tela inicial referente ao pesquisador é mostrada na Ilustra-
ção 40. Existe uma infinidade de opções possíveis de pesquisas em relação aos da-
dos do sistema, mas por questões de prazo e complexidade limitou-se o sistema a
cinco opções básicas mostradas no menu da tela inicial do pesquisador. O primeiro
link mostra uma tela de pesquisa por diagnóstico, mostrada na Ilustração 41, que
tem como resultado o diagnóstico de uma doença numa região selecionada num pe-
ríodo de tempo dado. O link seguinte leva a uma tela de busca, mostrada na Ilustra-
ção 42, que tem por objetivo realizar uma pesquisa de frequência de um determina-
do evento selecionado ocorrido no cadastro dos prontuários em uma abrangência e
períodos dados. O próximo link abre uma tela, mostrada na Ilustração 43, que resul-
ta em uma pesquisa de ocorrências de prescrição de um determinado medicamento
em um período dado e em uma abrangência selecionada. Em seguida temos o link
que leva a uma tela, mostrada na Ilustração 44, que realiza uma pesquisa de quanti-
dade de médicos e sua proporção em relação ao números de pacientes em uma
abrangência selecionada. Por fim, temos um link que referencia uma tela, mostrada
na Ilustração 45, que faz uma pesquisa em relação a quantidade de pacientes.
Ilustração 40: Tela inicial de pesquisa
89
Ilustração 41: Tela de pesquisa por diagnóstico.
Ilustração 42: Tela de pesquisa por evento.
90
Ilustração 44: Tela de pesquisa por quantidade de médicos.
Ilustração 43: Tela de pesquisa por prescrição.
91
Ilustração 45: Tela de pesquisa por quantidade de pacientes.
92
4 REALIZAÇÃO E RESULTADO DOS TESTES
Os testes internos, que consistem em testes dos módulos que compõe o
sistema, foram feitos a medida que avançava a implementação do projeto, com pe-
quenas execuções isoladas dos módulos construídos com resultado satisfatório.
Para os testes externos, que são os testes de funcionamento do sistema,
elaborou-se um roteiro com uma sequência de casos de testes para avaliar o funcio-
namento do sistema:
•Inclusão de dados em tabelas auxiliares para subsídio das outras atividades, como
a tabela de tipo de eventos, a tabela doença, a tabela medicamento, entre outras da
tela mostrada na Ilustração 29.
•Cadastramento de pacientes fictícios e outros testes relativos ao atendente.
•Cadastramento de profissionais de saúde fictícios e outros testes relativos ao admi-
nistrador.
•Cadastramento de prontuários fictícios para todos os pacientes.
•Inserção de dados em prontuário em pelo menos 40% dos pacientes cadastrados.
•Testes de consulta a prontuários.
•Testes relativos ao paciente.
•Testes relativos a pesquisa.
•Conclusão e análise dos resultados.
93
4.1 PREPARAÇÃO DAS TABELAS AUXILIARES.
A preparação das tabelas auxiliares é uma tarefa executada pelo adminis-
trador, a partir da tela mostrada na Ilustração 29, que contém os links para as telas
de inserção de dados nestas tabelas. A tela relativa ao preenchimento do tipo de
evento é mostrada na ilustração 46 e as telas relativas ao cadastramento de doença
e de medicamentos são mostradas nas Ilustrações 47 e 48, respectivamente.
Ilustração 46: Tela de cadastramento de tipo de evento.
94
Ilustração 47: Tela com cadastramento de doença.
Ilustração 48: Tela com cadastramento de medicamento.
95
Este caso de teste visa verificar a correta inserção dos dados nas respecti-
vas tabelas relacionadas em cada tela. Estas tabelas são referências para o preen-
chimentos dos campos de diagnóstico (tabela doença), prescrição (tabela Medica-
mento) e evento (tabela Tipo de Evento) na tabela Prontuário.
Foram cadastrados doze tipos de eventos relacionados a inserção em
prontuário, quinze doenças na tabela correspondente e dez inserções na tabela de
medicamentos. Nesta mesma tela de manutenção de tabelas temos um link para ca-
dastramento de instituição. Foram cadastradas seis instituições na tela, mostrada na
Ilustração 49. O sistema, em todas estas inserções, se comportou de forma espera-
da.
Ilustração 49: Tela de cadastramento de instituição.
96
4.2 CADASTRAMENTO DE PACIENTES E OUTROS TESTES RELATIVOS AO
ATENDENTE.
Foram cadastrados 72 pacientes distribuídos em algumas cidades de es-
tados diferentes. O sistema se comportou como esperado nesta operação. Um
exemplo da tela de confirmação de cadastramento efetuado é mostrado na Ilustra-
ção 50. Em seguida, os testes com cadastramento e alteração de senha foram efe-
tuados com regularidade pelo sistema.
Ilustração 52: Cadastramento de um paciente.Ilustração 50: Tela seguinte ao cadastramento com sucesso.
97
4.3 CADASTRAMENTO DE PROFISSIONAIS DE SAÚDE
Foram efetuados cadastramento de quinze profissionais de saúde, sendo
onze médicos, um atendente, dois administradores e um pesquisador. Mais uma vez
o sistema se comportou como esperado, inclusive quando forçado algum erro. Com
a digitação de uma matrícula errada ou de uma senha em branco, por exemplo, emi-
te-se a devida mensagem de erro. Foram cadastrados ainda, horários de atendimen-
to para todos os médicos existentes no sistema usando a tela de manutenção de ta-
belas mostrada na Ilustração 29. A Ilustração 51 mostra uma tela exibida após a di-
gitação de uma matrícula errada no cadastramento de senha. A ilustração 52 mostra
uma tela gerada pelo cadastramento de um profissional com sucesso.
Ilustração 51: Tela mostrando mensagem de erro por uma inserção de senha errada.
98
4.4 CADASTRAMENTO DE PRONTUÁRIOS E INSERÇÃO DE DADOS
Foram cadastrados prontuários para todos os pacientes, e feitas inser-
ções de dados em aproximadamente 45% dos prontuários. Avaliando o desempenho
do sistema, apontamos uma possível melhoria futura, como a exibição de campos
de inserção de dados em prontuário de acordo com o evento escolhido e não o pron-
tuário todo, como por exemplo, a não exibição do campo de prescrição, no caso do
evento ser a realização de um exame. Foi escolhido no momento a exibição de to-
dos os campos por motivo de praticidade de construção e aproveitamento dos cam-
pos presentes para registro de informações secundárias, evitando vários registros ao
mesmo tempo. As Ilustrações 53 e 54 mostram o preenchimento de uma inserção de
dados em um prontuário. Na Ilustração 53, temos o início do formulário do prontuário
com o campo matrícula do paciente (já preenchido pelo sistema), um campo para
Ilustração 52: Tela mostrando o resultado do cadastramento com sucesso de um profissional.
99
seleção do evento, um campo para descrição do evento. Na Ilustração 54, temos
três campos de cadastramento de códigos de doenças e um campo para descrição
do diagnóstico. Continuando este formulário ainda existem campos para inserção de
códigos de medicamentos prescritos ou administrados, um campo para descrição da
prescrição, e um campo de anamnese (descrição de histórico do paciente).
Ilustração 53: Tela mostrando o preenchimento do prontuário (parte de cima do formulário).
100
4.5 TESTES RELATIVOS AO PACIENTE
Os testes relativos às telas referentes ao paciente foram feitos através de
uma busca da rede credenciada com base nos dados já cadastrados, e pela visuali-
zação de cadastro e prontuário de paciente cadastrado. Com relação a busca por
rede credenciada, pode-se apontar melhorias futuras como a adição de um botão ao
lado de cada médico relacionado na lista de resultado da pesquisa para fazer agen-
damento de consulta, por exemplo. A Ilustração 55 mostra o resultado de uma busca
por um médico e as Ilustrações 56 e 57 mostram as visualizações de um cadastro e
de um prontuário, pelo próprio paciente.
Ilustração 54: Tela mostrando o preenchimento do prontuário (continuação do formulário).
101
Ilustração 55: Tela mostrando o resultado de uma busca por médicos.
Ilustração 56: Tela mostrando a visualização de um cadastro pelo próprio paciente.
102
4.6 TESTES RELATIVOS A PESQUISA
Para construção dos casos de testes, levamos em conta a preocupação
em não se limitar a um único prontuário nem exibir dados cadastrais de clientes, pro-
curando respeitar o sigilo da informação relativa ao prontuário. A pesquisa estatística
foi implementada com base em uma contagem do item pesquisado (diagnóstico de
uma doença, prescrição de um medicamento, etc.) e em seguida comparando com
um total de referência (população numa abrangência dada, totais dos itens pesqui-
sados, entre outros). Como exemplo, temos a Ilustração 58 que mostra o resultado
de uma pesquisa de diagnóstico da doença dengue (código CID A90) em um deter-
minado período. A primeira linha do resultado mostra a quantidade de ocorrência en-
contrada, a linha seguinte a porcentagem em relação a população de pacientes exis-
tente dentro da abrangência pesquisada, neste caso, nacional.
Ilustração 57: Tela mostrando a visualização do próprio prontuário (a visualização total é feita usando
a barra de rolagem à direita)
103
Nas pesquisas por abrangência menor que nacional (como em uma cida-
de, por exemplo), além da comparação percentual com o total da cidade, foi incluída
referência a abrangências maiores, como UF e nacional, neste caso. A Ilustração 59
mostra o resultado de uma pesquisa por um evento (no caso, uma consulta) em uma
determinada cidade num período, que exemplifica esta situação. A tela mostra que
foi feita uma consulta médica a paciente neste período, na cidade dada. O resultado
foi de acordo com a quantidade de dados cadastrados no sistema. Nas Ilustrações
60 e 61 mostramos os resultados de pesquisas de ocorrência de prescrição de um
medicamento e a quantidade de médicos em um estado, respectivamente.
Uma melhoria que pode ser observada nesta seção é a inclusão futura de
exibição de gráficos e exportação dos dados para planilhas, como o Excel.
Ilustração 58: Tela com resultado de uma pesquisa por diagnóstico.
104
Ilustração 59: Tela exibindo o resultado de uma pesquisa de ocorrência de um evento
Ilustração 60: Tela exibindo resultado de pesquisa de ocorrência de prescrição de um medicamento.
105
4.7 ANÁLISE DOS RESULTADOS
Forma feitas exaustivas consultas, inserções e manipulação de dados jun-
to ao sistema, para observar o comportamento do mesmo. Em todos os casos, des-
de busca de rede credenciada a pesquisa para análise de dados, foram provocados
erros como: deixar campos necessários em branco, números de matrículas inexis-
tentes, senhas erradas. Nestas situações, o sistema se comportou como esperado
sempre exibindo a mensagem de erro de acordo com a inconsistência detectada,
como mostra o exemplo na Ilustração 53.
Procurou-se registrar à parte todos os dados relevantes inseridos no sis-
tema pelos casos de teste, como quantidade de médicos, pacientes, tipos de even-
tos, e outros dados cadastrados. Assim, foi possível conferir se o resultado de uma
Ilustração 61: Tela com resultado da pesquisa da quantidade de médicos no estado.
106
pesquisa no sistema corresponde ao valor deste registro. Mais uma vez foi observa-
do o comportamento esperado pelo sistema, mostrando os dados de acordo com o
existente.
Em uma avaliação global, o sistema apresentou um comportamento satis-
fatório, com um bom desempenho, revelando a praticidade de uma aplicação web,
que é operar um sistema sem a necessidade de instalação de um programa na má-
quina cliente, bastando um computador com um navegador instalado.
107
5 CONCLUSÕES E TRABALHOS FUTUROS
As aplicações web mostram-se uma tecnologia promissora de construção
de software para uso em rede. Oferecem a praticidade única de estar pronta para
uso assim que acessada por um navegador, sem levar em conta a vantagem econô-
mica de evitar maiores gastos com softwares que seriam instalados em cada máqui-
na para acessar uma aplicação que não fosse web.
A vantagem de uma arquitetura centralizada de uma aplicação em rede,
está principalmente no acesso a dados em tempo real. Por essa qualidade, optou-se
neste projeto, por utilizar este tipo de arquitetura. O principal problema desta arquite-
tura, está na estrutura exigida para evitar problemas de conexão, administrar garga-
los no trânsito de dados, e outros que podem ser resolvidos com mais facilidade por
uma arquitetura descentralizada. Como uma alternativa, poderíamos ter uma arqui-
tetura descentralizada com os dados sendo armazenados em servidores regionais e
com um servidor global fazendo a coordenação, redirecionando os pedidos aos ser-
vidores adequados. Mas podemos também ter uma arquitetura híbrida, com a parte
que for de interesse de disponibilidade em tempo real em uma base centralizada, ao
passo que as outras em que não se tenha essa exigência possam utilizar-se da ar-
quitetura descentralizada. Acrescenta-se ainda a excelente qualidade atualmente
dos softwares de distribuição gratuita, como o SGBD MySQL e o Eclipse. Seria invi-
ável construir um sistema sem o suporte destes programas e também sem um servi-
dor de aplicação.
Como último comentário em relação ao projeto, o prazo para desenvolvi-
mento se mostrou um desafio a execução do mesmo. Conseguir um produto de qua-
lidade depende, e muito, de um prazo adequado, o que deve ser prioritariamente ne-
gociado com o cliente. Uma falha na apuração do cronograma se reverte em um pro-
duto defeituoso longe de cumprir as características para qual foi designado. No caso
deste projeto, foram incontáveis, por vezes, as ideias de aprimoramento de uma ou
108
outra funcionalidade, mas, pelo prazo escasso, tiveram de ser abandonadas. Por
fim, temos no resultado deste, um produto que atende ao que foi proposto.
Como trabalhos futuros relacionados a este sistema podemos citar: a me-
lhora gráfica da interface, a inclusão futura de exibição de gráficos e exportação dos
dados para planilhas(como o Excel) nos resultados das pesquisas, adição de outros
tipos de pesquisa (feita pelo pesquisador), a inclusão de funcionalidades em relação
a planos de saúde, a exibição de campos de preenchimento no formulário do prontu-
ário de acordo com o evento, a inclusão de uma funcionalidade de agendamento de
consulta, entre outros.
Após a conclusão deste projeto e, consequentemente, desta graduação
pretendo realizar uma pós graduação voltada a sistemas orientado a objetos, e tam-
bém com um pouco mais de ambição, realizar um mestrado na área de computação
em nuvem, redes, ou inteligência artificial. Hoje trabalho com manutenção de softwa-
re em uma grande empresa e já uso o conhecimento que adquiri neste curso, e pre-
tendo continuar atuando nesta área de desenvolvimento.
109
REFERÊNCIAS BIBLIOGRÁFICAS
1. SABBATINI, Renato M.E. História da Informática em Saúde no Brasil <http://www.informaticamedica.org.br/informaticamedica/n0105/sabbatini.htm
>, acesso em 16 de abril de 2011.
2. PRESIDÊNCIA DA REPÚBLICA – CASA CIVIL. Decreto nº 7.336, de 19 de outubro de 2010 Art. 7º. Disponível em <http://www.planalto.gov.br
/ccivil_03/_Ato2007-2010/2010/Decreto/D7336.htm#art8> , acessado em 16
de abril de 2011.
3. Loureiro, S. Sistema Único de Informação em Saúde?: Integração dos da-dos da Assistência Suplementar à Saúde ao Sistema SUS. ANS , 2003.
4. CFM, Conselho Federal de Medicina – CFM. Resolução CFM nº 1.638/2002 <http://www.portalmedico.org.br/resolucoes/cfm/2002/1638_2002.htm>, aces-
so em 16 de abril de 2011.
5. SLEE, V.; SLEE, D.; SCHMIDT, H.J The endangered medical record – en-
suring its integrity in the age of informatics, Saint Paul, Minnesota, Tringa
Press, 2000.
6. DICK, R.S.; STEEN, E.B.; DETMER, D.E. The Computer-based Patient Re-
cord - An Essential Technology for Health Care (edição revisada). Institute
of Medicine (IOM), Washington, DC: National Academy Press, 1997.
7. VAN BEMMEL J.; MUSEN M.. Handbook of Medical Informatics. Springer
Verlag, Stuttgart, 1997
8. SITTIG, D.F. Advantages of computer-based medical records. Informa-
tics Review. Jan, 1999. < http://www.informaticsreviewcom/thoughts/advanta-
ges.html>. Acessado em 16 de abril de 2011.
9. DICK, R.S., STEEN, E.B., DETMER,D.E. The Computer-based Patient Re-
cord – An Essential Technology for Health Care. Washington, DC: National
Academy Press, 1997.
10.CONSELHO FEDERAL DE MEDICINA - CFM. Resolução nº 1.605/00,dispo-
nível em <http://www.saude.sc.gov.br/geral/orgaos_vinculados/samu/porta-
110
rias_resolucoes/ResolucaoCFM1605-00.htm>, acesso em 16 de abril de
2011.
11.ELMASRI, Ramez. Sistemas de banco de dados, São Paulo, Pearson Addi-
son Wesley, 2005, p. 3-4.
12.HEUSER, Carlos A. Projeto de Banco de Dados, Instituto de informática da
UFRGS, 4ª Edição, Sagra, 1998.
13.ORACLE. Getting Started with Web Applications, <http://download.ora-
cle.com/javaee/1.4/tutorial/doc/WebApp.html> acesso em 18 de abril de 2011.
14.VAROTO, Ane Cristina. Visões em arquitetura de software. Dissertação de
Mestrado. IME-USP, São Paulo, SP – Brasil, 2002.
15.VASCONCELOS, A. P. V., Uma Abordagem para Recuperação de Arquite-tura de Software Visando sua Reutilização em Domínios Específicos.
Exame de Qualificação, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, 2004.
16.LEMAY, Laura. Aprenda a criar páginas da Web com HTML e XHTML, São
Paulo, Pearson Education, cap. 3, 2002.
17.CAELUM. Apostila FJ-21, Java para Desenvolvimento Web, <www.cae-
lum.com.br>, acesso em 15 de abril de 2011.
18.CADENHEAD, Rogers. Aprenda em 21 dias Java2, Rio de Janeiro, Elsevier,
pág. 4, 2005
19.HOSTMAN, Cay S.; CORNELL, Gary. Core Java, Volume 1: Fundamentos,
São Paulo, Pearson, pág. 5, 2010
20.SIGULEM, Daniel. Um Novo Paradigma de Aprendizado na Prática Médica da UNIFESP/EPM. São Paulo, 1997. 177p./ Tese (Livre–Docência) – Univer-
sidade Federal de São Paulo – Escola Paulista de Medicina.
111
APÊNDICE
APÊNDICE A – TRECHO DE CÓDIGO EM JAVA DA CLASSE PRONTUÁRIO
(...)
class Prontuario {private int idPront;private int paciente;private Date dataCriacao;private int medicoGravacao;private Date dataEvento;private int codEvento;private String nomeEvento;private String descEvento;private String disgnostico1;private String disgnostico2;private String disgnostico3;private String descDiagnostico;private int presc1;private int presc2;private int presc3;private int presc4;private String descPrescricao;private String anamnese;
// construtor de para inserção:
public Prontuario() {}
// inserir no BD public void insereBD() throws SQLException, ParseException {
Connection conecta = new Conexao().getConnection();String sql = "insert into prontuario(idProntuario, Paciente,
DataCriacao," + "Medicogravacao, DataEvento, CodEvento, NomeEvento, DescEvento," + " Diagnostico1, Diagnostico2, Diagnostico3, DescDiagnostico, Presc1, " + "Presc2, Presc3, Presc4, DescPrescricao, Anamnese ) " + "values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)";
java.sql.Date datCri = new java.sql.Date( this.getDataCriacao().getTime());
java.sql.Date datEve = new java.sql.Date( this.getDataEvento().getTime());
112
try {// prepara os dados
PreparedStatement stm = conecta.prepareStatement(sql);stm.setInt(1, this.getIdPront());stm.setInt(2, this.getPaciente());stm.setDate(3, datCri);stm.setInt(4, this.getMedicoGravacao());stm.setDate(5, datEve);stm.setInt(6, this.getCodEvento());stm.setString(7, this.getNomeEvento());stm.setString(8, this.getDescEvento());stm.setString(9, this.getDisgnostico1());stm.setString(10, this.getDisgnostico2());stm.setString(11, this.getDisgnostico3());stm.setString(12, this.getDescDiagnostico());stm.setInt(13, this.getPresc1());stm.setInt(14, this.getPresc2());stm.setInt(15, this.getPresc3());stm.setInt(16, this.getPresc4());stm.setString(17, this.getDescPrescricao());stm.setString(18, this.getAnamnese());
// executastm.execute();stm.close();
} catch (SQLException e) {throw new RuntimeException(e);
}conecta.close();
}
(...)
// recupera todo prontuario do paciente testarpublic List<Prontuario> recuperaTudoBD() throws SQLException {
Connection conecta = new Conexao().getConnection();String sql = "Select * from prontuario p where p.Paciente= ?";List<Prontuario> pront = new ArrayList<Prontuario>();try { PreparedStatement stm = conecta.prepareStatement(sql); stm.setInt(1, this.getPaciente()); ResultSet rs = stm.executeQuery();
while (rs.next()) { Prontuario p = new Prontuario(); p.setIdPront(rs.getInt("idProntuario")); p.setPaciente(rs.getInt("Paciente"));
113
p.setDataCriacao(rs.getDate("DataCriacao")); p.setMedicoGravacao(rs.getInt("Medicogravacao")); p.setDataEvento(rs.getDate("DataEvento")); p.setCodEvento(rs.getInt("CodEvento")); p.setNomeEvento(rs.getString("NomeEvento")); p.setDescEvento(rs.getString("DescEvento")); p.setDisgnostico1(rs.getString("Diagnostico1")); p.setDisgnostico2(rs.getString("Diagnostico2")); p.setDisgnostico3(rs.getString("Diagnostico3"));
p.setDescDiagnostico(rs.getString("DescDiagnostico")); p.setPresc1(rs.getInt("Presc1")); p.setPresc2(rs.getInt("Presc2")); p.setPresc3(rs.getInt("Presc3")); p.setPresc4(rs.getInt("Presc4"));p.setDescPrescricao(rs.getString("DescPrescricao")); p.setAnamnese(rs.getString("Anamnese")); pront.add(p);}rs.close();stm.close();
} catch (SQLException j) {throw new RuntimeException(j);
}conecta.close();return pront;
}
//(...) = linhas de código não mostrada
114
APÊNDICE B – TRECHO DE CÓDIGO EM JAVA DA CLASSE TRATAPESQUISA
/** * Servlet implementation class TratarPesquisa */@WebServlet(description = "Processar a pesquisa solicitada pela página de pesquisa", urlPatterns = { "/TratarPesquisa" })public class TratarPesquisa extends HttpServlet {
private static final long serialVersionUID = 1L; public TratarPesquisa() { super(); // TODO Auto-generated constructor stub }
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
// TODO Auto-generated method stubPrintWriter out = response.getWriter();
String opera = request.getParameter("oper");int oper = Integer.parseInt(opera);String abrange = request.getParameter("abangencia");int abrangencia = Integer.parseInt(abrange);String UF = request.getParameter("UF");String UF3 = request.getParameter("UF3");String cidade = request.getParameter("cidade");Pesquisa pq = new Pesquisa();int totalCompara1 = 0;int totalCompara2 = 0;int totalCompara3 = 0;int resultadoAux = 0;Date inicio = null;Date fim = null;
switch (oper){case 1:{// pesquisa doença
int DataEcidOK = 0; String codigocid = request.getParameter("codDoenca"); String dinicio2 = null; String dfim2 = null; if (codigocid == ""){
115
out.println("<HTML><body bgcolor =\"#AFEEEE\">");out.println("<p> Codigo CID não informado</P>");out.println("<br><a href
= \"pesq.jsp\">Voltar.</a><br>");out.println("</body></HTML>");
} else{
String dinicio = request.getParameter("inicio");String dfim = request.getParameter("fim");if (dinicio == "" && dfim == ""){ out.println("<HTML><body bgcolor =\"#AFEEEE\">"); out.println("<p> Datas devem ser informadas!
</P>"); out.println("<br><a href
= \"pesq.jsp\">Voltar.</a><br>"); out.println("</body></HTML>");}else{ dinicio2 = dinicio; dfim2 = dfim; SimpleDateFormat df = new
SimpleDateFormat("dd/MM/yyyy"); try { inicio = df.parse(dinicio); fim = df.parse(dfim); } catch (ParseException e) {
// TODO Auto-generated catch blocke.printStackTrace();
}DataEcidOK = 1;
}}if (DataEcidOK == 1){ switch (abrangencia){
case 1:{// nacionalint qtdePaciente = 0;
int resultok = 0;resultadoAux = pq.pesquisarDiagnostico(
codigocid, inicio, fim);totalCompara1 =
pq.pesquisarTotalPessoas();if (totalCompara1 < 0){ out.println("<HTML><body bgcolor
=\"#AFEEEE\">"); out.println("<p> Falha na pesquisa por
pacientes!</P>");
116
out.println("<br><a href = \"pesq.jsp\">Voltar.</a><br>");
out.println("</body></HTML>");}else{ qtdePaciente = 1;}if (resultadoAux < 0){ out.println("<HTML><body bgcolor
=\"#AFEEEE\">"); out.println("<p> Falha na pesquisa por
diagnóstico!</P>"); out.println("<br><a href = \"pesq.jsp\">Voltar.</a><br>"); out.println("</body></HTML>");}else{ resultok = 1;}float porcentagem = (((float)resultadoAux
/(float)totalCompara1)*100 );if (resultok == 1 && qtdePaciente == 1){ out.println("<HTML><body bgcolor
=\"#AFEEEE\">"); out.println("<p> Resultado da pesquisa
"+ codigocid +":<br><br><br>" + "Quantidade de diagnósticos : "+ resultadoAux + "<br><br>" +"Equivalente a "+ porcentagem + "% da população abrangida. <br><br>" + "Período Pesquisado : "+ dinicio2 +" a "+ dfim2 +"<br><br></P>");
out.println("<br><a href = \"pesq.jsp\">Voltar.</a><br>"); out.println("</body></HTML>");}
} break;
case 2:{// UF int qtdePaciente = 0; int resultok = 0; resultadoAux = pq.pesquisarDiagnosticoUF( codigocid, inicio, fim, UF); totalCompara1 = pq.pesquisarTotalPessoas();
117
totalCompara2 = pq.pesquisarTotalPessoasUF(UF);
if (totalCompara1 < 0 || totalCompara2 < 0){out.println("<HTML><body bgcolor =\"
#AFEEEE\">");out.println("<p> Falha na pesquisa por
pacientes!</P>");out.println("<br><a href = \"pesq.jsp\">Voltar.</a><br>");out.println("</body></HTML>");}
else{qtdePaciente = 1;
} if (resultadoAux < 0){
out.println("<HTML><body bgcolor =\"#AFEEEE\">");
out.println("<p> Falha na pesquisa por diagnóstico!</P>");
out.println("<br><a href = \"pesq.jsp\">Voltar.</a><br>");out.println("</body></HTML>");}else{ resultok = 1;}float porcentagem = 0;float porcentagemUF = 0;if (resultadoAux != 0){ porcentagem = (((float)resultadoAux /
(float)totalCompara1)*100 ); porcentagemUF = (((float)resultadoAux
/(float)totalCompara2)*100 );}else{ porcentagem = 0; porcentagemUF = 0;}if (resultok == 1 && qtdePaciente == 1){ out.println("<HTML><body bgcolor
=\"#AFEEEE\">"); out.println("<p> Resultado da pesquisa
"+ codigocid +":<br><br><br>" +"Quantidade de diagnósticos : "+ resultadoAux + "<br><br>" +
118
"Equivalente a "+ porcentagem + "% da população nacional abrangida.<br>" + "Equivalente a "+ porcentagemUF + "% da população estadual abrangida.<br><br>" +"Período Pesquisado : "+ dinicio2 +" a "+ dfim2 +"<br><br></P>");
out.println("<br><a href = \"pesq.jsp\">Voltar.</a><br>");
out.println("</body></HTML>"); }
}break;
// entra aqui códigos relativos ao case 3 e 4//(...) = linhas de código não mostradas
case 2:{// eventoString tpEv = request.getParameter("tipoEvento");int DataEeventOK = 0;String dinicio2 = null;String dfim2 = null;int tipoEvento = Integer.parseInt(tpEv);TipoEvento Te = new TipoEvento();try {
Te.recuperaPorCodBD(tipoEvento);} catch (SQLException e1) {
// TODO Auto-generated catch blocke1.printStackTrace();
}String dinicio = request.getParameter("inicio");String dfim = request.getParameter("fim");if (dinicio == "" && dfim == ""){ out.println("<HTML><body bgcolor =\"#AFEEEE\">"); out.println("<p> Datas devem ser informadas!
</P>"); out.println("<br><a href= \"pesq.jsp\" > Voltar.
</a><br>"); out.println("</body></HTML>");}else{ dinicio2 = dinicio; dfim2 = dfim; SimpleDateFormat df = new SimpleDateFormat
("dd/MM/yyyy");
119
try {inicio = df.parse(dinicio);fim = df.parse(dfim);} catch (ParseException e) { // TODO Auto-generated catch block
e.printStackTrace();}DataEeventOK = 1;
}if(DataEeventOK == 1){
switch (abrangencia){ case 1:{ // nacional int qtdePaciente = 0; int resultok = 0; resultadoAux = pq.pesquisarEvento(
tipoEvento, inicio, fim); totalCompara1=pq.pesquisarTotalPessoas(); if (totalCompara1 < 0){
out.println("<HTML><body bgcolor =\"#AFEEEE\">");
out.println("<p> Falha na pesquisa por pacientes!</P>");
out.println("<br><a href = \"pesq.jsp\">Voltar.</a><br>");out.println("</body></HTML>");
} else{
qtdePaciente = 1;}
if (resultadoAux < 0){out.println("<HTML><body bgcolor =\"
#AFEEEE\">");out.println("<p> Falha na pesquisa por
evento!</P>");out.println("<br><a href= \"pesq.jsp\"
>Voltar.</a><br>");out.println("</body></HTML>");
} else{
resultok = 1; } float porcentagem = (((float)resultadoAux /
(float)totalCompara1)*100 ); if (resultok == 1 && qtdePaciente == 1){
out.println("<HTML><body bgcolor =\"
120
#AFEEEE\">");out.println("<p> Resultado da pesquisa
<br><br><br>" +"Quantidade de resultados para "+ Te.getNomeEvento() +" : "+ resultadoAux + "<br><br>" +"Equivalente a "+ porcentagem + "% da população abrangida. <br><br>" + "Período Pesquisado : "+ dinicio2 +" a "+ dfim2 +"<br><br></P>");
out.println("<br><a href= \"pesq.jsp\" >Voltar.</a><br>");
out.println("</body></HTML>"); } }
break;
// entra aqui códigos relativos ao case 3 e 4, etc.//(...) = linhas de código não mostrada
* @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
*/protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {// TODO Auto-generated method stub
}/** * @see HttpServlet#doPost(HttpServletRequest request,
HttpServletResponse response) */protected void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {// TODO Auto-generated method stub
}}
