Minha Tese - Rui Alexandre Januário SeverinoREVISADO 20-DezembroVisto

REPÚBLICA DE ANGOLA
MINISTÉRIO DO ENSINO SUPERIOR
UNIVERSIDADE KATYAVALA BWILA
Instituto Superior Politécnico
Telefone 272235758 – Telefax 272235758
Complexo da Cambanda
Caixa Postal 1725 – Benguela, Angola
DEPARTAMENTO DE ENSINO E INVESTIGAÇÃO DE INFORMÁTICA
APLICAÇÃO WEB PARA GESTÃO DO HISTORIAL CLÍNICO DOS
PACIENTES DO CENTRO MÉDICO “MEDP”
Nº______/2018
Rui Alexandre Januário Severino
BENGUELA
2018
Inovação – Investigação – Desenvolvimento
Região Académica II – Benguela e Kwanza Sul
REPÚBLICA DE ANGOLA
MINISTÉRIO DO ENSINO SUPERIOR
UNIVERSIDADE KATYAVALA BWILA
Instituto Superior Politécnico
Telefone 272235758 – Telefax 272235758
Complexo da Cambanda
Caixa Postal 1725 – Benguela, Angola
TRABALHO DE FIM DO CURSO PARA OBTENÇÃO DO GRAU DE
LICENCIATURA EM CIÊNCIAS DA COMPUTAÇÃO.
APLICAÇÃO WEB PARA GESTÃO DO HISTORIAL CLÍNICO DOS
PACIENTES DO CENTRO MÉDICO “MEDP”
AUTOR: Rui Alexandre Januário Severino
ORIENTADORA: Ms. Magali M. Matilla Belett
BENGUELA
2018
PENSAMENTO
“Só sei que nada sei”
Sócrates
I
DEDICATÓRIAS
Dedico este trabalho à minha querida, batalhadora e incansável mãe Maria
Isabel Januário, ao meu pai Lino Pedro Severino (que Deus o tenha); aos meus irmãos
Josemar Severino, Carlos Severino, Yolanda Severino; aos meus primos Djalma
Severino, Vandituva Limpinho, Eliza Limpinho; aos meus grandes amigos Jorge
Martinho, Eugénio Sobrinho, Osseno Miápia, Evanilsom Valente os aos meus colegas
do curso de Ciências da computação de 2013 á 2017.
II
AGRADECIMENTOS
Primeiro a Deus por permitir que até aqui eu tivesse saúde e forças pra vencer
todas a barreiras da vida me protegendo, aos meus familiares e amigos que me
apoiaram, aos meus colegas e professores sem esquecer o professor Dr. Miguel
Garay que desde cedo aceitou acompanhar este trabalho com bastante atenção, rigor
e dedicação corrigindo as minhas falhas sempre que as cometesse, e não menos
importante a docente Ms. Magali Belett que na ausência do professor Garay deu
continuidade no acompanhamento deste projecto. Sem esquecer o meu querido
padrinho que me ajudou quando passei por uma fase menos boa da minha vida, o
meu muito obrigado aos amigos das horas de lazer que entediam quando falhava um
compromisso com eles, por conta de ter que estudar pra prova no dia seguinte, a todos
que envolveram-se de forma directa ou indirecta para o êxito deste trabalho muito
obrigado.
III
RESUMO
O desenvolvimento acelerado das tecnologias de informação e comunicação
entre elas a informática, tem tido influência decisiva no sector da saúde. A gestão da
informação médica tornou-se hoje em dia uma necessidade eminente. Em um hospital
muitas vezes resulta num enorme trabalho entre os trabalhadores e os pacientes. Isto
se deve fundamentalmente porque em certas ocasiões é difícil encontrar informação
referente a um paciente, gerir consultas, análises e actualizar Historial Clínico. Além
disso toda esta informação não se encontra centralizada, o que provoca a sua possível
perda (Fuentes, 2015).
Este trabalho apresenta uma proposta de desenho e implementação de um
Sistema para Gestão do Historial Clínico dos pacientes do Centro Médico (MEDP). O
sistema usa ferramentas que permitam gerar interfaces web dinâmicas compatíveis
com os mais diversos navegadores, destacando-se a linguagem Java para web, e os
frameworks Hibernate e PrimeFaces. Com o propósito de alcançar um objectivo
principal e compreender o tema a ser desenvolvido foi realizado um estudo detalhado
de elementos teóricos e tecnológicos voltado a trabalhos com aplicações web, além
disso é apresentada também a descrição da solução proposta, e a exposição de um
caso de estudo que reflete o funcionamento da aplicação. Para o desenvolvimento
desta aplicação utilizou-se os métodos de indução e dedução, as técnicas de
investigação
como
observação,
entrevista,
pesquisa
documental,
pesquisa
bibliográfica, e questionário.
Palavras chaves: Historial Clínico, interfaces web, frameworks, centro de
saúde.
1
ABSTRACT
The accelerated development of information and communication technologies,
including information technology, has had a decisive influence on the health sector.
The management of medical information has now become an eminent necessity. In a
hospital often results in a huge job between the workers and the patients. This is fundamentally due to the fact that it is sometimes difficult to find information about a patient, to manage appointments, to analyze and to update the Clinical History. Moreover,
all this information is not centralized, which causes its possible loss (Fuentes, 2015).
This paper presents a proposal for the design and implementation of a System
for Management of the Clinical History of the patients of the Medical Center (MEDP).
The system uses tools that allow the generation of dynamic web interfaces compatible
with the most diverse browsers, highlighting the Java language for web, and the Hibernate and PrimeFaces frameworks. In order to achieve a main objective and to understand the theme to be developed, a detailed study of theoretical and technological
elements was carried out in order to work with web applications. In addition, a description of the proposed solution and the study that reflects the operation of the application.
For the development of this application were used the methods of induction and deduction, research techniques such as observation, interview, documentary research,
bibliographic research, and questionnaire.
Key words: Clinical History, interfaces web, frameworks, center of health.
2
LISTA DE ABREVIATURAS SIGLAS E ACRÓNIMOS
Asynchronous: (Assíncrono) tipo de comunicação com intervalo de tempo variável.
Ajax: (Asynchronous Javascript and XML) Técnica de desenvolvimento web para criar
aplicações interactivas que se executam no navegador, ao mesmo tempo mantem a
comunicação assíncrona com o servidor em segundo plano.
APIs: (Application Programming Interface) Interface de programação de aplicações.
É um conjunto de funções e procedimentos que oferece uma certa biblioteca para ser
utilizada por outro software como uma camada de abstração.
Consulta externa: É o atendimento por um médico a um paciente ambulatório.
DAO: (Data Acces Object) forma de Acesso a objectos de dados.
DDL: (Data Definition Language) Definição da linguagem de dados.
Framework: É uma estructura conceitual e tecnológica de suporte, definido
normalmente com artefactos ou módulos de software concretos para auxiliar o
desenvolvimento de outros softwares.
HTTP: Protocolo de transferencia de hipertexto. Protocolo de aplicação utilizado pela
Word Wide Web (WWW) para solicitar, transmitir e receber documentos Web.
HTML: Linguagem de marcação de hipertexto. Linguagem utilizada para escrever
documentos Web.
Javascript: linguagem de programação interpretada utilizada principalmente na
programação de páginas web.
J2EE: Edição Enterprise de Java 2. Conjunto de API especiais do Java, tais como
Enterprise JavaBeans (EJB) e Páginas de JavaServer (JSP).
JSP: Servidor de páginas do java.
MVC: Modelo Vista Controlador.
MDA: (Monochrome Display Adapter) placa de vídeo com um modo de texto de 25
linhas e 80 caracteres.
3
MEDP: Cada caracter representa as iniciais dos nomes dos proprietários do Centro
Médico MEDP.
Opensource: Softwares com licenças e código fonte livre.
OutrosServiços: serviços ambulatórios, e serviços auxiliares prestados pelo Centro.
RAM: (Random Acess Memory) Memória de acesso aleatório.
RIA: (Rich Internet Application) Aplicação de Internet.
RUP: (Rational Unified Process) Processo Unificado da Rational.
Serviços Ambulatórios: serviços prestados a pacientes não internados.
SIH: Sistemas de Informação Hospitalar, são aplicações de software personalizadas
e específicas, ajustadas as necessidades da instituição de saude implementada.
SGBDR: Sistema Gestor de Base de Dados Relacionais
SQL: (Structured Query Language) Linguagem de Consulta Estruturada.
TCP/IP: (Transmission Control Protocol/Internet) conjunto de protocolos para ligar
computadores diferêntes atraves de redes.
UML: (Unified Modeling Language) Linguagem Unificada de Modelagem. Modelo
padrão utilizado para análise e desenho de programas orientados a objetos.
Workflow: Fluxo de trabalho orientado pelo RUP.
WWW: (Word Wide Web) Rede de alcance mundial.
XML: (eXtensible Markup Language) Linguagem de Marcação extensível.
XHTML: (extensible HyperText Markup Language): Linguagem Extensível para
Marcação de Hipertexto.
4
ÍNDICE DE TABELAS
Tabela 1 – Tecnologias selecionadas para o desenvolvimento do sistema . 35
Tabela 2 - Actores do negócio ...................................................................... 39
Tabela 3 - Descrição do caso de uso do negócio solicitar consulta ............ 41
Tabela 4 - Descrição do caso de uso do negócio solicitar análise ............... 43
Tabela 5 – Descrição do caso de uso do negócio solicitar outros serviços .. 45
Tabela 6 – Descrição do caso de uso do negócio solicitar relatórios ........... 47
Tabela 7 – Trabalhadores do negócio .......................................................... 48
Tabela 8 – Atores do sistema ....................................................................... 54
Tabela 9 – Caso de uso do sistema autenticar usuário ................................ 58
Tabela 10 – Caso de uso do sistema gerir usuário...................................... 59
Tabela 11 – Caso de uso do sistema gerir serviços ..................................... 60
Tabela 12 – Caso de uso do sistema gerir paciente ..................................... 61
Tabela 13 – Caso de uso do sistema ver relatórios ...................................... 62
5
ÍNDICE DE FIGURAS
Figura 1 – Diagrama do padrão de um Sistema de Historial Clínico. .......... 20
Figura 2 - Esquema de representação da arquitetura MVC utilizando JSP .. 26
Figura 3 –Diagrama dos casos de uso do negócio ....................................... 40
Figura 4- Diagrama de actividade solicitar consulta ..................................... 42
Figura 5 - Diagrama de actividade solicitar análise ...................................... 44
Figura 6 – Diagrama de actividade solicitar outros serviços ......................... 46
Figura 7 – Diagrama de actividade solicitar relatório .................................... 47
Figura 8 – Modelo de objectos ..................................................................... 49
Figura 9 – Diagrama dos atores do sistema ................................................. 55
Figura 10– Diagrama dos casos de uso do sistema ..................................... 57
Figura 11 – Diagrama de sequência logar no sistema.................................. 63
Figura 12 – Diagrama de sequência registar novo paciente......................... 64
Figura 13 – Diagrama de sequência registar novo serviço ........................... 65
Figura 14 – Diagrama de sequência atender paciente ................................. 65
Figura 15 – Diagrama de comunicação logar no sistema ............................. 66
Figura 16 – Diagrama de comunicação registar novo paciente .................... 67
Figura 17 – Diagrama de comunicação registar novo paciente .................... 67
Figura 18 – Diagrama de comunicação atender paciente ............................ 68
Figura 19 – Diagrama de classes do sistema ............................................... 69
Figura 20 – Figura do modelo lógico da base de dados ............................... 70
Figura 21 – Interface de Login ..................................................................... 71
Figura 22 – Interface de usuário principal ..................................................... 72
Figura 23 – Interface de Erro por não preencher os campos obrigatórios .... 73
Figura 24 – Interface mostrando erros dos campos obrigatórios .................. 73
Figura 25 – Diagrama de Implantação da aplicação web ............................. 74
Figura 26 – Organigrama estrutural do centro médico medp ....................... 80
Figura 27 – Capa do bloco de relatório usado no centro MEDP ................... 81
Figura 28 – Página do bloco de relatório ...................................................... 81
Figura 29 – Questionário utilizado para coleta de informações .................... 82
6
Figura 30 – Fatura gerada ao salvar os serviços prestados ......................... 83
Figura 31 – Interface de login do sistema SIGELAR .................................... 84
Figura 32 – Interface pricipal do sistema SIGELAR...................................... 85
Figura 33 – Interface de acesso ao sistema ................................................. 86
Figura 34 – Interface Principal do sistema .................................................... 86
Figura 35 – Interface principal com nível de acesso Administrador .............. 87
Figura 36 – Interface principal com nível de acesso Recepcionista ............. 87
Figura 37 – Interface principal com nível de acesso Enfermeiro .................. 87
Figura 38 – Interface para gestão dos dados dos pacientes ........................ 88
Figura 39 – Interface prestar serviço ............................................................ 88
Figura 40 – Interface consultar serviços prestados ...................................... 89
Figura 41 – Interface de control de acesso ................................................... 89
Figura 42 – Interface ver o Historial Clínico de um paciente ....................... 90
7
ÍNDICE GERAL
Introdução..................................................................................................... 10
Objectivos Gerais ...................................................................................... 12
Objectivos Específicos ............................................................................. 12
Métodos de Investigação .......................................................................... 13
Técnicas de Investigação .......................................................................... 13
Contribuição Prática .................................................................................. 15
Capítulo 1: Fundamentos teóricos ......................................................... 17
Introdução ...................................................................................... 17
Historial Clínico de Pacientes ........................................................ 17
1.2.1 Historial Clínico Electrónico ........................................................... 18
1.2.2 Características do Historial Clínico Electrónico ............................. 19
1.2.3 Sistemas de Gestão de Historial Clínico Eletrónico ....................... 21
Metodologia, Linguagens e Ferramentas utilizadas ....................... 26
1.3.1 Metodologia de Desenvolvimento .................................................. 26
1.3.2 Linguagems de Programação ........................................................ 29
1.3.3 Linguagem de Modelagem ............................................................ 30
1.3.4 Ferramentas Case ......................................................................... 30
1.3.5 Servidores ...................................................................................... 31
1.3.6 Frameworks ................................................................................... 32
1.3.7 Ambiente de Desenvolvimento ...................................................... 33
1.3.8 Ferramentas Auxiliares .................................................................. 34
Resumo das técnologias selecionadas .......................................... 35
Conclusão do Capítulo................................................................... 36
Capítulo 2: Desenvolvimento do sistema .............................................. 37
Introdução ...................................................................................... 37
Modelo do Negócio ........................................................................ 37
2.2.1 Descrição do Negócio .................................................................... 38
8
2.2.2 Processos do Negócio ................................................................... 39
2.2.3 Actores do Negócio........................................................................ 39
2.2.4 Casos de Uso do Negócio ............................................................. 40
2.2.5 Trabalhadores do Negócio ............................................................. 48
2.2.6 Entidades do Negócio .................................................................... 49
2.2.7 Modelo de Objectos ....................................................................... 49
2.2.8 Descrição do Objecto de Automatização ....................................... 50
Requisitos do Sistema ................................................................... 51
2.3.1 Requisitos Funcionais .................................................................... 51
2.3.2 Requisitos não Funcionais ............................................................. 52
Análise e desenho do sistema ....................................................... 53
2.4.1 Modelagem do sistema .................................................................. 54
2.4.1.1 Actores do Sistema ........................................................................ 54
2.4.1.2 Casos de uso do sistema............................................................... 56
2.4.1.3 Diagrama dos casos de uso do sistema ........................................ 56
2.4.1.4 Descrição dos casos de uso de sistema ........................................ 58
2.4.2 Diagramas de Sequência ............................................................... 63
2.4.3 Diagramas de Comunicação .......................................................... 66
2.4.4 Diagrama de Classes..................................................................... 68
Modelo Lógico da Base de Dados ................................................. 70
Implementação .............................................................................. 70
2.6.1 Tratamento dos erros..................................................................... 72
Implantação ................................................................................... 74
Conclusão do Capítulo................................................................... 75
Conclusões ................................................................................................... 76
Recomendações ........................................................................................... 77
Referências Bibliográficas ............................................................................ 78
Anexos.......................................................................................................... 80
9
INTRODUÇÃO
Com o avanço das tecnologias de Informação e Comunicação (TIC´s) que têm
sido grandes responsáveis por mudanças na nossa sociedade. A informática sendo
uma ciência que faz o tratamento da informação de forma automática, eficiente e
rápida. Surge na medicina, à informática médica com o objectivo de prestar auxílio
aos profissionais da saúde, para melhorar a qualidade do atendimento sanitário.
No sector da saúde em Angola, esta realidade não foge à regra identificadose as tecnologías da informacão, e tornando-as uma aliada para aumentar a eficiência, e melhorar a qualidade na prestação de cuidados de saúde resultando em um
maior bem-estar da população. Neste sentido se apresenta um instrumento, o (HCE)
Historial Clínico Electrónico, que permite garantir que os pacientes recebam em tempo
oportuno, um conveniente e eficiente cuidado de saúde. O HCE é uma ferramenta que
oferece toda informação sobre o histórial do paciente, os protocolos clínicos e as recomendacões de estúdos específicos, gerando um incremento da eficiência na procura de antecedentes clínicos e o cuidado preventivo a ter em conta, contribuindo
também na redução das complicações incluindo erros na medicação.
Estes sistemas têm como objectivo fundamental aumentar a qualidade na
atenção ao paciente e os serviços de saúde, mediante a gestão da informação médica
e administrativa nos centros de saúde, para que os dados obtidos possam ser
aplicados nas áreas de investigação, clínica, docência, administração e ajudar a
diminuir custos e aumentar a produtividade.
O módulo de “Historial Clínico Electrónico” (HCE) é parte dos Sistemas de
Informação Hospitalar, que é a resposta informática no que denominamos de Historial
Clínico. Seguido com o propósito de desenvolver um sistema para gestão do Historial
Clínico dos pacientes do Centro Médico (MEDP) situado em Benguela no bairro dos
navegantes.
Este trabalho tem como propósito desenvolver uma Aplicação Web seguindo
o padrão de projectos MVC (Model-View-Controller). Esse padrão será usado para
facilitar a implementação e mesmo a manutenção, em termos de código, do sistema
10
a ser desenvolvido. Os dados para a modelagem do sistema são provenientes do
centro Médico (MEDP).
O Centro Médico MEDP é uma unidade de saúde privada destinada a
diagnosticar, medicar, e acompanhar a todo paciente que aflui aquela unidade de
saúde, com eficiência, dinamismo e qualidade ( ver organigrama anexo A ). O centro
conta com especialidades como clínica geral, genecologia/obstetrícia, pediatria,
oftalmologia, e nutrição. Extruturado em cinco áreas de serviço a descrever:

Área da recepção: É responsavel pela recepção dos pacientes,
encaminhamento, e cobrança aos pacientes dos serviços a estes prestados.

Área de enfermagem: É onde se faz a triagem e atendimento de emergência
aos paciêntes.

Área do laboratório: É responsavel pela coleta e análise das amostras.

Área do consultório médico: É onde os médicos consultam os paciéntes.

Área
da
farmácia:
É
responsavel
pela
venda
dos
fármacos
e
aconselhamento aos paciêntes na dosagem dos mesmos fármacos.
A escolha do tema deve-se ao facto de haver falhas, perdas e morosidade no
processo da gestão, pesquisa e armazenamento das informações relativas aos
pacientes do Centro Médico (MEDP), actividade que ocorre na Área da recepção e é
feita de forma manuscrita, e armazenada em vários blocos de registos preparados
para o efeito, criando alguns transtornos quando um dado é mal escrito, e por vezes
os blocos de registos terminam criando dificuldade no normal processo de
atendimento aos pacientes. Desta forma um método permitirá realizar as operações
de inserção, armazenamento e gestão dos dados dos pacientes, formando um
Historial Clínico Electrónico, que pode ser consultado toda vez que necessário, dando
surgimento ao seguinte Problema Científico: Como melhorar o processo de
armazenamento e gestão das informações geridas pelo centro médico MEDP, Sendo
o objeto de estudo os processos de cadastro e gestão, das informações com relação
aos pacientes do Centro Médico MEDP, onde o campo de ação serão um conjunto
de ferramentas de informação utilizadas no atendimento dos pacientes do Centro
Médico (recepção e enfermagem), bem como a seleção de tecnologias como Java,
11
JSF2, Prime Faces, Apache TomCat, entre outras que permitam levar a cabo a
implementação de uma solução web para a problemática existente. Para a resolução
do problema apresentado temos as seguintes variaveis.
Objectivos Gerais
Desenvolver um sistema para gestão do histórial clínico dos pacientes do
Centro Médico MEDP cituado na cidade de Benguela, a qual inclui informações dos
pacientes, das análises clínicas, resultados de consultas, e outros serviços
complementares realizados pelos pacientes.
Objectivos Específicos
1)
Estudar processos relacionados com Historial Clínico do Centro Médico.
2)
Estudar as ferramentas para o desenvolvimento da aplicação.
3)
Realizar a análise e desenho da aplicação para a gestão de Historial
Clínico dos pacientes do Centro Médico MEDP Benguela.
4)
Desenhar a base de dados que de suporte ao armazenamento de toda
informação.
5)
Desenvolver a aplicação web.
6)
Testar a aplicação.
Como valor prático da implementação do sistema para a gestão dos dados
pessoais e clínicos “dos pacientes do centro médico MEDP”, permitirá que a
informação dos pacientes que se encontram registados esteja centralizada. E desta
forma garantir o fluxo e a integração dos dados, bem como a possibilidade de gerar
relatórios adequados e actualizados da informação armazenada.
Será permitido também poder fazer constantes actualizações dos dados
sempre que necessário, proporcionando desta forma: maior exatidão e controle das
consultas, análises, e receitas preescritas a um determinado paciente. Facilitando o
trabalho do pessoal da direcção do Centro MEDP, bem como os profissionais de
saúde que tratam os pacientes do mesmo Centro. Além disto só poderá aceder ao
sistema, pessoal registrado com autorização prévia, fazendo o Login controlado por
12
um nome de usuário e uma contrassenha para poder ter acesso a toda informação
pertencente ao Centro.
Métodos de Investigação
Método é um conjunto de actividades sistemáticas e racionais que, com maior
segurança e economia, permite alcançar os objectivos, conhecimentos válidos e verdadeiros, traçando o caminho a ser seguido, detectando erros e auxiliando as decisões do cientista. (Maria & Andrade, 2003, p. 83). Para este trabalho em particular fezse o uso de dois métodos:
Método Dedutivo: A dedução parte do geral para o particular. O método
Dedutivo ajudou a fazer uma relação entre a hipótese de resolução do problema, criar
uma aplicações Web de gestão de dados de pacientes do centro médico MEDP com
outras aplicações de saúde ja existentes. Desta forma permitir também obter
informações a respeito das ferramentas adequadas a serem utilizadas.
Método Indutivo: A indução é a operação lógica que vai do particular ao
geral. O método indutivo caminha, na aproximação aos fenómenos para planos cada
vez mais abrangentes, indo das constatações mais particulares às leis e teorias
(conexão ascendente). A indução, ao contrário da dedução, não progride
simplesmente pelas relações entre as ideias. No raciocínio indutivo a generalização
deriva de observações de casos da realidade concreta. Ele necessita de informações
sobre factos. A indução tem como programa construir o discurso da ciência a partir
dos factos observados. (Ferreira, 2015).
Técnicas de Investigação
Face o campo do tema a ser investigado neste trabalho, foi necessário adoptar
as técnicas que proporcionassem a melhor coleta de informação possível, e que
tivessem níveis cientificamente aceites, tais como:
Observação: De acordo a finalidade e a forma como é executada, a
observação pode assumir diferentes configurações, conforme a classificação de
(Lakatos e Marconi 1988, p. 170):
13
Observação assistemática (não planejada);
Observação sistemática (planejada);
Observação não participante (sem envolvimento do objeto de observação);
Observação participante (com envolvimento do objeto de observação ou
pesquisa);
Observação individual;
Observação em equipa;
Observação laboratorial.
No processo da observação para além da constatação do modo de
funcionamento do centro, também permitiu avaliar as habilidades e criatividades dos
funcionários, quanto ao uso das novas tecnologias de comunicação.
Entrevista: Entrevista: É uma conversa orientada para um objectivo definido:
recolher, por meio do interrogatório do informante, dados para a pesquisa. Para este
caso, este método permitirá, mediante perguntas não estruturadas às entidades
responsáveis pela recepção, e enfermagem ajudou a perceber a forma como é feito
todo este processo de gestão das informações dos pacientes no centro médico MEDP
de formas a implementar o método, a fim de saber como e que tipo de informações
são requeridas aos pacientes, bem como deverá ser toda a estrutura do mesmo
método.
Pesquisa documental: A característica da pesquisa documental é que a
fonte de pesquisa de dados está restrita a documentos, escritos ou não, constituindo
o que se denomina de fontes primárias. Estas podem ser feitas no momento em que
o facto ou fenómeno ocorre, ou depois. (Maria & Andrade, 2003, p. 174). Alguns
documentos revisados na pesquisa se mostram nos anexos A1 e A2, permitindo desta
forma obter algumas informações qualitativas sobre o centro.
Pesquisa bibliográfica: A pesquisa bibliográfica, ou de fontes secundárias,
abrange toda bibliografia já tornada pública em relação ao tema de estudo, desde
publicações de boletins, jornais, revistas, livros, pesquisas, monografias, teses,
14
material etc., até meios de comunicação orais: rádio, filmes e televisão. A sua
finalidade é colocar o pesquisador em contato direto com tudo o que foi escrito, dito
ou filmado sobre determinado assunto, inclusive conferências seguidas de debates
que tenham sido transcritos por alguma forma, quer publicadas, quer gravadas. (Maria
& Andrade, 2003, p. 188).
Questionário: “É uma das técnicas usadas para obter informações dos
principais protagonistas no atendimento dos pacientes” (ver anexo B ). Esta técnica
permitiu obter uma informação detalhada e individual de cada trabalhador do centro
ligado as áreas de investigação de um modo particular, e de outros de um modo geral.
podendo cada um dar o seu parecer relacionado com as práticas realizadas na área
em que está ligado.
Contribuição Prática
O uso das técnicas de investigação acima descritas foram de grande
importância visto que atraves delas foi possivel colher toda informação com relação
ao tema proposto, o que possiblitou idealizar um sistema informático para a gestão da
informação, nas áreas encarregadas pela gestão das mesmas e organizar as mesmas
de formas que estejam centralizadas. Facto que permitirá o acesso as mesmas de
forma segura, fácil e rápida, ja que se manuseiam grandes quantidades de dados,
proporcionando melhoras na eficiência do registo, armazenamento e gestão das
informações relacionadas ao Historial Clínico dos pacientes do Centro Médico MEDP
em Benguela.
O presente trabalho investigativo está estruturado em 7 secções, tais como
Introdução, Capítulo 1, Capítulo 2, conclusões, recomendações, referências
bibliograficas e anexos.
O Capítulo 1, apresenta os Fundamentos Teóricos, mostrando a
caracterização e descrição de Historial Clínico (HC) e de Historial Clínico Eletrónico
(HCE), faz-se também a descrição dos métodos e das ferramentas utilizados no
desenvolvimento do software.
15
O Capítulo 2, fala sobre o Desenvolvimento do sistema, apresenta-se a
modelagem do negócio, dos requisitos funcionais e não funcionais do sistema, como
os casos de uso do negócio, os diagramas de actividades, e os casos de uso do
sistema e alguns elementos da implementação.
16
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS
Introdução
Segundo Merlin Almagro De la Noval a informática médica surge com o
objectivo de prestar serviços aos profissional da saúde, para melhorar a qualidade do
atendimento sanitário Por isto foram criados os Sistemas de Informação Hospitalar,
rui
definidos como “sistemas de informação orientados a satisfazer as necessidades de
geração de informação, para armazenar, processar e reinterpretar dados médicoadministrativos de qualquer instituição hospitalar” (Noval, 2015, p. 7).
No presente capítulo estão descritos todos elementos teóricos tais como, os
elementos relacionados com Historial Clínico, as ferramentas e as principais
tecnologias usadas no desenvolvimento da aplicação pretendida. Fazendo-se
também uma descrição do ambiente de desenvolvimento.
Historial Clínico de Pacientes
Historial Clínico é um conjunto de documentos que contem os dados,
avaliações e informações de qualquer índole, sobre a situação e evolução de um
paciente ao longo de um processo de assistência médica.
Entre os principais elementos de um Historial Clínico se encontram as
seguintes informações:

Dados pessoais: se regista a informação geral dos pacientes que vão ao
centro médico.

Dados de consultas realizadas: se regista a informação das consultas
feitas pelos pacientes registando resultados de laboratórios clínicos,
diagnósticos, observações feitas e tratamentos preescritos.
Segundo Sanchez diz que um Historial Clínico, é um registo que permite aos
especialistas de saude terem um control do percurso clínico dos pacientes. Mas a
ambiguidade que muitas vezes supõem, ao constante problema de espaço provocada
pela acumulação de registros médicos, o deterioramento do papel e a pouca
17
legibilidade se juntam a lista de inconvenientes, Aliados a falta de segurança destes
registros médicos, visto que não é possível saber quem consultou os documentos e
fez copias dos mesmos (Sanchez, 2010) (Serna, 2005).
A seguir se descreve algumas limitações práticas, logísticas e organizacionais
que um HC apresenta:
a) Acessiblidade: é uma entidade que normalmente conta com usuário
único, ja que so uma pessoa pode consultar a cada vez.
b) Pode ser muíto desorganizada: sendo isto nocivo para aqueles pacientes
mais graves, que a organização da sua informação é de extrema
importância.
c) O historial pode estar incompleto: podendo ser perdida, ou estar
incompleta quando neçessário.
d) Falta de segurança: não há um rasto de quem acedeu as informações,
não se sabe quem pegou, fotocopiou ou estraviou.
e) Complexidade na busca da informação: o tempo que é consumido ao
fazer uma busca de uma informação na sua maioria é demasiado.
Este conjunto de limitações podem ser melhoradas com a informatização do
(HC) Historial Clínico, com a implementação de um (HCE) Historial Clínico Eletrónico
que é um sistema informático que incrementa outras vantagens, como o potencial
para múltiplas vistas da informação dependentemente da necessidade do usuário. Se
permite que os dados podem ser representados não só como textos, mas também
mediante gráficos, listas, organigramas, entre outros. (Sanchez, 2010).
1.2.1 Historial Clínico Electrónico
Histórial clínico electrónico, é um conjunto de informações ordenada e detalhada que recompila cronológicamente todos os aspetos relativos a saúde de um paciente e a de sua família em um período determinado da sua vida; representa uma
base para conhecer as condições de saúde, as atenções médicas e os diferentes procedimentos executados pelas equipes médicas ao longo de um processo assistencial.
18
Actualmente o HCE é considerado uma peça chave para a prestação eficiente
dos serviços de saúde em especial, para garantir a qualidade do atendimento sanitário
e a segurança do paciente e do profissional de saúde. Por isto, a informação clínica
armazenada em HCE pode contribuir fortemente na investigação médica, na formação
dos professionais da saúde e melhorar o problema da saúde pública (Luna, 2012).
Classificação dos Históriais Electrónicos
Segundo o livro “Manual de Expediente Clínico Electrónico” da Dra. Gabriela
Villarreal Levy, Historial Clínico (Levy, 2011), tem uma grande variedade de aplicações
podendo serem classificados em:
Historial Clínico electrónico (HCE). Historial que relaciona a informação de
saúde de uma pessoa e que pode ser registado, compartido, gerido e consultado por
professionais de saúde autorizados dentro de uma organização de saúde.
Historial electrónico de saúde (EHS). Registo total da informação electrónica
relacionada com a saúde de um individuo, onde se armazena informação por parte de
mais de uma organização ou provedores de serviços de saúde.
Sistema de Informação Hospitalar (HIS). Sistema integral de informação desenhado para administrar os aspectos financeiros, clínicos e operativos de uma organização de saúde. Pode incluir ou estar conectado com um Historial Clínico Electrónico.
1.2.2 Características do Historial Clínico Electrónico
Actualmente existem no mercado uma grande quantidade de ofertas com respeito a Historiais Clínicos Electrónicos (HCE), que vão desde simples sistemas de
registro com pouca extruturação, à robustos e avançados sistemas electrónicos de
organização e gestão de informação. A escolha do HCE está ligada a necessidade
particular de cada profissional, mas é importante que o HCE escolhido tenha uma
estrutura padronizada.
O que se entende por estrutura padronizada? São padrões mundiais de uso
e intercambio de informação, o que permite a integração com outros sistemas, seja
19
uma rede de farmácias que aceitem o uso de ordens médicas padronizadas, um laboratório que possa entregar os resultados e ser integrados automáticamente ao HCE
de um paciente, uniformizando através do control do vocabulário médico utilizado para
poder realizar uma inteligente gestão da informação evitando os problemas de sinonímia médica (Levy, 2011).
A seguir, a figura 1 representa um diagrama padronizado de um Sistema de
Historial Clínico Electrónico e a sua interação com o pessoal das diferentes áreas de
uma Instituição de saúde, diagrama elaborado apartir de um modelo tirado do livro
“Manual de Expediente Clínico Electrónico”.
Figura 1 – Diagrama do padrão de um Sistema de Historial Clínico.
(fonte: wwwisis.ufg.edu.sv/wwwisis/documentos/TE acessado aos 17/08/2018)
Entre os potenciais benefícios do Historial Clínico electrónico encontramos:
a) Gestão do Historial Clínico único por paciente, garantindo a sua
padronização segundo as normas internacionais.
b) Comunicação com outros profissionais para a realização de consultas de
segunda opinião.
c) Ajuda na tomada de decisões, desenho de formulários para a captura,
processamento de dados e relatórios personalizados, bem como como
fazer uma análise estatística da informação armazenada.
20
Com o importante desenvolvimento das tecnologias da informação no ámbito
sanitário, e visto aqui indicadores que dão conta das grandes vantagem no uso delas,
o centro médico MEDP não ficou alheio a esta realidade, e quer adotar o uso de
sistemas de HCE, com objectivo de melhorar consideravelmente o processo de
atendimento aos seus pacientes e definir políticas eficazes para dar atenção aos
principais problemas de saúde que afectam a população de Benguela e não só.
1.2.3 Sistemas de Gestão de Historial Clínico Eletrónico
Após o autor ter feito um estudo sobre o que é um HCE e o que fazem, ilustrase exemplos de pesquizas sobre alguns softwares ja desenvolvidos com a finalidade
de gerir os processos levados a cabo em uma unidade sanitária e suas principais
características.
A seguir mostra-se algums sistemas disponiveis na internet, tais como:
MedeX 3.0 – software pago para gestão de clínicas, consultórios odontológios,
fisioteraputas e pacientes. Gratis para teste em 7 dias, tem o seu repositório de dados
na núvem por isto so funciona conectado a internet. Disponivel no endereço (fonte:
www.baixaaki.com.br/download/medex acessado aos 19/08/2018).
Adm Médico 4.32 – software médico para gerir consultório, agendas, e
pacientes. Pago, por uma licença que expira anualmente. Disponivel em:
(www.superdownloads.com.br/download/173/adm-medico-sistema/.acessado aos 19/08/2018)
Sistema Gerencial Hospitalar - SIGELAR 1.0. Projecto de software de gestão
hospitalar, e acompanhamento de tratamentos. Software livre, mas não é uma versão
completa, disponivel no github.com/emersoncantalice/SIGELAR?files=1
19/08/2018 (ver
acessado
aos
anexos D e E).
Pesquizas locais
Atraves de alguma pesquiza feita em alguns centros de saúde, e clínicas
privadas situadas no município de Benguela, com o propósito de saber como é
realizada a gestão do Historial Clínico dos seus paciente e se usam algum sistema
eletrónico. O autor constatou que são poucas as organizações que tem um sistema
de gestão eletrónico, um dos factos que motivou o desenvolvimento.
21
Aplicações Desktop versus Aplicações Web
Uma aplicação desktop (também chamada de escritório) é aquela que está
instalada no computador do usuário, e é executada directamente pelo sistema
operativo, que pode ser Microsoft Windows, Mac OS X, Linux ou Solaris, e cujo
rendimento depende de diversas configurações de hardware como memória RAM,
disco duro, memória de vídeo, entre outros periféricos do computador (O'reilly, 2007).
Vantagens
Normalmente a sua execução não requere comunicação com o exterior,
porque é realizada de forma local.
Podem ser mais robustas e estáveis que as aplicações Web.
Rendimento: o tempo de resposta é muito rápido.
Segurança: podem ser muito seguras (dependendo do programador).
Desvantagens
 Acesso limitado do computador onde estiverem instaladas.
São dependentes do sistema operativo que estiver instalado no
computador, e suas capacidades (vídeo, memoria, entre outros periféricos).
 Requerem actualização personalizada.
Aplicação Web
Uma aplicação web é toda ferramenta que se encontre dentro de um servidor
web que um usuário pode aceder mediante um navegador web com ou sem conexão
a Internet (O'reilly, 2007).
Cliente / Servidor (Client / Server)
A expressão “Cliente / Servidor” (comumente chamado de “Client / Server”)
descreve o desenvolvimento físico de modelos onde o computador cliente faz um
pedido para o computador servidor, e o computador servidor responde a esse pedido.
Pedido
C
Resposta
S
Este servidor
também pode
ser um cliente.
22
Ela esta estruturada em três partes:
Primeira parte: está constituída por um navegador web.
Segunda parte: a parte intermedia que é composta por um motor que permite
ler uma tecnologia web de tipo dinâmico.
Terceira parte: esta última parte se integra por uma base de dados sólida.
Vantagens
Tem muitas vantagens trabalhar com uma aplicação que está centralizada.
Desta maneira a distribuição e actualização é más fácil e rápida, visto que a aplicação
não está instalada nas máquinas dos clientes. Mas está centralizada em um servidor
que responde a solicitações de usuários remotos.
Actualizações automáticas: na hora de fazer uso de uma aplicação web a
mesma estará em total dependência de um desenvolvedor, que será o encarregado
das actualizações.
Não é necessário instalar-se: basta estar conectado à rede local ou conectado
à Internet e um navegador web como mediador, e acessar o servidor o que não
ocupará espaço em nosso disco duro.
Compatibilidade: só necessitamos de ter um navegador actualizado para que
sejam compatíveis, independentemente do sistema operativo que se tenha.
Desvantagens
 A disponibilidade da aplicação não será possível ao cliente, sempre que não
houver ligação entre o cliente e o servidor, seja local ou através da internet.
 O desempenho em uma aplicação web pode ser más lento porque cada vez
que se realiza uma solicitação de um documento HTML, se enviam ao mesmo tempo,
pela mesma via os dados a serem mostrados e o desenho da tela da aplicação, e o
mesmo pode ser afetado pela capacidade que tenha o servidor de aceitar um grupo
grande de conexões.
23
Após ter feito uma comparação das duas formas de programar, optou-se por
trabalhar em Web sendo que oferece maior praticidade e vantagens com relação a
uma aplicação desktop, permitindo a conexão simultânea de vários usuários
separados geograficamente a mesma aplicação. E o problema do tempo de espera
de um usuário ao acessar o servidor pode ser reduzido através da tecnologia AJAX
(Asynchronous Javascript and XML), que é uma técnica de programação web para
criar aplicações interativas que se executam no navegador, através de uma
comunicação assíncrona com o servidor em segundo plano. Proporcionando a troca
entre as páginas sem a necessidade de recarrega-las, facilitando a navegação, e
diminuição do tempo de espera do usuário.
Porque Aplicação Web?
As aplicações desktop padecem de algumas limitações como:
 Requerem instalação.
 São difícil de actualizar tendo em conta trocas de configurações que podem
ser necessárias em um dado momento.
 Ao inserir novas funcionalidades no software ou actualizar para melhorar as
que ja existem é necessário instalar novamente.
 Para garantir a comunição e acesso aos dados dos pacientes em diferentes
departamentos adjacentes ao centro. Se deseja uma proposta que seja:
Versátil: Pode-se necessitar que os usuários se conectem desde
compartimentos e equipamentos diferentes (PC, Mac, telemovel, entre otros…).
Flexivel: Deve ser fácil personalizar o contexto de uma entidade em particular.
Escalablidade: As necesidades da instituição podem mudar a qualquer
momento por isso deve ser fácil fazer actualizações que vai de acordo as novas
funcionalidades da aplicação.
Para dar resposta a estes elementos, na implementação de um sistema de
gestão das informações que diz respeito aos pacientes do centro médico MEDP. O
sistema sera desenvolvido usando a tecnologia web, fazendo recurso ao padrão MVC.
24
Dai algumas das vantajens de usar a tecnología web no desenvolvimento da referida
aplicação web.
 Não requerem instalação, e facilmente podem ser actualizadas.
 Pode-se aceder de qualquer lugar com a internet, ou conexão com o servidor
web através de uma conecção local por meio de wifi ou cabo.
 Os dados são guardados de forma remota.
 Compatiblidade através de plataformas diferentes.
 São convenientes em computadores com baixo nivel de procesamento e
necessitam de pouco espaço em disco.
 Fácil integração com os serviços web.
Padrão de Projectos Usando Modelo Vista Controlador
Uma aplicação JavaEE usa o modelo três camadas: apresentação, negócio
e persistência. Na camada de apresentação estão as páginas JSP, a camada de negócio contém a modelagem do domínio do problema e a camada de persistência contém as classes com conhecimento sobre a persistência de objetos no banco de dados.
O Model-View-Controller (MVC) é um padrão de arquitetura que divide a aplicação em controladores que tratam as entradas dos usuários, no modelo que prove
as funcionalidades principais e nas visões que apresentam as informações para os
usuários (SOUZA, 2008). Em aplicações complexas, que enviam uma série de dados
para o usuário, o desenvolvidor frequentemente necessita separar os dados (model)
da interface (view). Utilizando MVC, alterações feitas na interface não afetarão a manipulação dos dados e estes poderão ser reorganizados sem alterar a interface do
usuário. O MVC resolve esse problema por meio da separação das tarefas de acesso
aos dados e a lógica do negócio da apresentação e da interação com o usuário
O objectivo básico do padrão de projecto MVC é separar dados ou lógica de
negócios (model) da interface do usuário (view) e do fluxo da aplicação (controller).
25
A Figura 2 apresenta um esquema da arquitetura MVC utilizando JSP para a camada
de interface.
Figura 2
- Esquema de representação da arquitetura MVC utilizando JSP
(fonte:www.google.com/search?q=esquema+do+modelo+vista+controlador&client
aces-
sado aos 02/3/2018)
Metodologia, Linguagens e Ferramentas utilizadas
Neste epígrafe se descrevem as principais ferramentas estudadas e
analizadas para o desenvolvimento do sistema. Desta forma se descreve a
metodologia, as linguagens e as ferramentas. E em cada caso se definem as
seleccionadas para o desenvolvimento do sistema.
Na selecção das ferramentas para o desenvolvimento do método proposto,
houve um grande investimento no tempo de pesquisa, de formas a serem encontradas
as ferramentas adequadas e com nível de robustez e fiabilidade elevado, para permitir
o desenvolvimento de um software credível, moderno, intuitivo, e o mais importante
um sistema funcional. Para que possa responder as exigências requeridas pelo centro
de saúde MEDP no que toca ao armazenamento e gestão do Historial Clínico dos
seus pacientes.
1.3.1 Metodologia de Desenvolvimento
A criação de um sistema automatizado geralmente é um processo longo e
complexo que requer um grande volume de trabalho por parte de especialistas de
diferentes áreas e também é determinado pela realização de tarefas complexas entre
as quais existe uma relação lógica.
26
Um dos focos ou princípios mais difundidos ao seguir uma metodologia de
desenvolvimento é de facilitar a realização, planejamento e controle de um projecto
de computador, que constitui uma organização do trabalho em fases. Partindo desde
princípio adotou-se pelo RUP como a metologia a seguir no desenvolver deste
projecto.
O Rational Unified Process (RUP) É um modelo constituído por fases que
identifica quatro fases discretas no processo de software. No entanto, ao contrário do
modelo em cascata, no qual as fases coincidem com as actividades do processo, as
fases do RUP estão relacionadas mais estritamente aos negócios do que a assuntos
técnicos. fases do RUP:
1. Concepção. O objectivo da fase de concepção é estabelecer um business
case para o sistema. Se identificam todas as entidades externas (pessoas
e sistemas), que irão interagir com o sistema, e definir essas interacções.
A seguir usamos essas interacções para avaliar a contribuição do sistema
com o negócio. Se a contribuição for de pouca importância, o projecto pode
ser cancelado depois dessa fase.
2. Elaboração. Os objectivos da fase de elaboração são desenvolver um
entendimento do domínio do problema, estabelecer um Framework de
arquitectura para o sistema, desenvolver o plano de projecto e identificar
os riscos principais do projecto. Ao concluir essa fase, deve-se ter um
modelo de requisitos para o sistema (os casos de uso da UML são
especificados), uma descrição
da arquitectura e um plano de
desenvolvimento para o software.
3. Construção. A fase de construção está essencialmente relacionada ao
projecto, programação e teste do sistema. As partes do sistema são
desenvolvidas paralelamente e integradas durante esta fase. Ao concluir
esta fase, deve-se ter um sistema de software em funcionamento e a
documentação associada pronta para ser liberada para os usuários.
4. Transição. A fase final do RUP está relacionada à transferência do
sistema da comunidade de desenvolvimento para a comunidade dos
27
usuários e com a entrada em funcionamento do sistema no ambiente real.
Ao concluir esta fase, tem que haver um sistema de software
documentado, funcionando correctamente em seu ambiente operacional.
O RUP foi projectado em conjunto com a UML – uma linguagem de
modelagem orientada a objectos e por isso, a descrição dos workflows é orientada em
termos dos modelos UML associados. Os principais workflows de engenharia e de
apoio são:
1. Modelagem de negócios - Os processos de negócio são modelados
usando casos de uso de negócios.
2. Requisitos - Os agentes que interagem com o sistema são identificados e
os casos de uso são desenvolvidos para modelar os requisitos do sistema.
3. Análise e desenho - Um modelo de projecto é criado e documentado
usando modelos de arquitectura, modelos de componente, modelos de
objecto e modelos de sequência.
4. Implementação - Os componentes de sistema são implementados e
estruturados em subsistemas de implementação. A geração automática de
código com base nos modelos de projecto ajuda a acelerar esse processo.
5. Teste - O teste é um processo interativo realizado em conjunto com a
implementação. O teste de sistema segue o término da implementação.
6. Implantação - Uma versão do produto é criada, distribuída aos usuários e
instalada no local de trabalho.
7. Gestão de configuração e mudanças - Este workflow de apoio gere as
actualizações ao sistema.
8. Gestão de projectos - Este workflow de apoio gere o desenvolvimento do
sistema.
9. Ambiente - Este workflow de apoio está relacionado à disponibilização de
ferramentas apropriadas de software para a equipa de desenvolvimento.
(Sommerville, 2007, p. 54-56).
28
Optou-se por escolher o RUP como metodologia de desenvolvimento pelo
facto dela ser completa e robusta. Não obstante a dificuldade no uso da mesma em
comparação com as metodologias Ágeis por serem menos extenças e mais viradas
para a aplicação em sí.
1.3.2 Linguagems de Programação
Java Para a implementação do sistema resultado deste trabalho, optou-se
pela linguagem Java pelas funcionalidades que a mesma oferece no desenvolvimento
de sistemas para web. Essas funcionalidades estão, também, relacionadas às tecnologias agregadas ao uso da linguagem. Dentre essas tecnologias estão os frameworks
e os padrões de projecto.
Os padrões de projecto, embora sejam conceituais, definem a forma de empregar tecnologias na resolução de determinados problemas. Esses padrões não estão relacionados à linguagem, mas fornecem uma maneira de resolver problemas recorrentes em programação, otimizando o uso dos recursos que as linguagens e as
tecnologias possuem.
A plataforma JavaEE, também conhecida como J2EE ou JEE, está voltada
para o desenvolvimento de aplicações multicamadas, baseadas em componentes que
são executados em um servidor de aplicações.
A plataforma JavaEE é considerada um padrão de desenvolvimento porque é
necessário seguir determinadas regras para que o produto de software gerado seja
compatível com JavaEE. O desenvolvimento de software para esse ambiente é realizado por meio da linguagem de programação Java e de um conjunto de ferramentas
de desenvolvimento e de tecnologias associadas.
XHTML É uma extenção do HTML que é a linguagem básica da www. A
maioria dos documentos na Internet encontra-se escrita em HTML, daí a sua
incontornável importância. Mas pelo facto de usar o JSF o código fonte das páginas
foram escritos em XHTML com sigla em inglês para Extensible HyperText Markup
Language (Linguagem Extensível para Marcação de Hipertexto) que é nada mais que
a transformação de um documento existente de HTML podendo desta forma obter
29
algumas vantagems como: Compatiblidade da linguagem com futuras aplicações,
garantindo establidade das mesmas, compatiblidade com os futuros navegadores que
podem deixar de ser compatíveis com elementos e atributos de linguagems antigas
(“deprecated”) como HTML segundo recomendações da W3C (Organização de
padronização da Wor).
XHTML é um código consistente que dispensa uso de “truques” e “hacks” para
superar os “bugs”, o tempo de carregamento de uma página XHTML é mais rápido
porque o navegador interpreta uma página limpa sem ter que decidir sobre a
renderização de erros de código.
Ao visitar um sít pode-se ver normalmente o código XHTML utilizado para o
construir. Basta selecionar nos menus do Internet Explorer: Ver →Código fonte (ou
View →Page Source, no Netscape, Mozilla e Firefox). (Alexandre & Carlos, 2013) .
1.3.3 Linguagem de Modelagem
UML Na área de Engenharia de Software, a Linguagem de Modelagem
Unificada (do inglês,
UML - Unified Modeling Language) é uma linguagem de
modelagem que permite representar um sistema de forma padronizada. A UML não é
uma metodologia de desenvolvimento, o que significa que ela não diz o que fazer
primeiro e em seguida ou como projectar o sistema, mas ela auxilia a visualizar o
desenho e a comunicação entre os objectos.
Basicamente, a UML permite que desenvolvedores visualizem os produtos de
seus trabalhos em diagramas padronizados. Junto com uma notação gráfica, usando
programas como Rational Rose, StarUML, Visual Paradigm entre outros.
1.3.4 Ferramentas Case
StarUML (STAR UML, 2016) é uma ferramenta CASE de código aberto
(opensource) e está sob licença GPL (General Public License). Ela dá suporte a
modelagem de sistemas utilizando os diagramas da UML2 e também à MDA, com
definições de transformações para algumas plataformas específicas. É permitida
também a importação/exportação de modelos utilizando o formato XMI.
30
Visual paradigm Visual Paradigm for UML (VISUAL PARADIGM, 2010) é
uma ferramenta CASE com várias opções de modelagem com os diagramas da UML2
e que também oferece suporte a diagramas de requisitos SysML e a diagramas ER.
A ferramenta possui um bom ambiente de trabalho, o que facilita a visualização e
manipulação do projecto de modelagem. É uma ferramenta comercial e também
oferece suporte a transformações específicas para códigos-fonte de algumas
linguagens de programação como, por exemplo, C++ e Java.
Para elaborar alguns do principais diagramas foi usado o Visual Paradigm
versão 12.1 - (Build 20150802).
1.3.5 Servidores
Servidor de BD MySQL - É um Sistema Gestor de Bases de Dados (SGBD)
desenhado para administrar eficazmente a proliferação de sistemas e dados nas
empresas, oferecendo além vastas garantias de segurança e fiabilidade. É uma
plataforma para o processamento de transações em línea (OLTP) de grande escala,
sendo útil também para soluções de Inteligência de Negócios (em inglês, Business
Intelligence), integração, análises e criação de relatórios de dados.
Entre suas principais características destacam-se a sua facilidade de uso,
disponibilidade,
escalabilidade,
segurança,
produtividade,
acesso
a
dados
melhorados, redução da complexidade da tecnologia de informação, recuperação
rápida, conexão de administrador dedicada, detecção automática obrigatória de
conflitos para nas transações de escritura, maior granularidade em termos de
especificação de permissões em vários âmbitos, garantias de autorização e
autenticação, compatibilidade ampla com outras linguagens.
Servidor Web Apache Tomcat - (TOMCAT, 2012) é um contêiner servlet, ou
seja, um servidor de aplicações utilizado para interpretar aplicações escritas em Java
para web. Ele não implementa um contêiner EJB, mas abrange parte da especificação
JEE com tecnologias como servlet e JSP e tecnologias de apoio relacionadas, como
segurança, JNDI Resources (API para acesso a diretórios) e JDBC DataSources.
31
O Tomcat atua também como servidor web, ou pode funcionar integrado a um
servidor web dedicado como o Apache ou o IIS (Internet Information Services). Como
servidor web, ele provê um servidor HTTP puramente em Java. O servidor inclui ferramentas para configuração e gerenciamento, o que também pode ser feito editandose manualmente arquivos de configuração formatados em XML.
1.3.6 Frameworks
Java Server Faces (JSF) - É um framework (marca de trabalho) web J2EE
da família de código fonte aberto, baseado em componentes de interfase de usuário,
que facilita e agiliza o desenvolvimento de aplicações web. JSF oculta ao programador
os detalhes do requerimento HTTP e a resposta HTTP, tornando um estilo de
programação similar à programação de aplicações de escritório, de estilo JAVA Swing,
Delphi ou Visual Basic.
É uma tecnologia que permite construir aplicações web, que suportam
diferentes dispositivos como clientes, por ex. telefones celulares, agendas, notbook´s
entre outros (Fuentes, 2015).
Framework para programar aplicação web para java, criado pela ORACLE.
Seu funcionamento se dá através de agrupamentos de COMPONENTES que podem
disparar EVENTOS.
 O JSF 1 utilizava JSP como padrão para seus templates
 O JSF 2 utiliza Facelets para isso
 O MVC do JSF tem a finalidade de isolar a lógica do negócio da camada de
apresentação
 No JSF utilizaremos arquivos. XHTML
 Nestes arquivos poderemos chamar as classes, seus métodos, suas variáveis.
PrimeFaces – Framework (para dar estilo as páginas Web) PrimeFaces é
uma suíte de componentes de código fonte aberto para Java Server Faces 2.0 com
um conjunto de mais de cem componentes JSF para o desenvolvimento de interfaces
ricas (PRIMEFACES, 2012). Dentre as características do PrimeFaces, destacam-se:
32
a) possui um conjunto de componentes de interface gráfica para implementação de Rich Internet Application (RIA), como, por exemplo, DataTable, AutoComplete,
HtmlEditor e Charts (gráficos).
b) não há necessidade de configuração XML extra e não há dependências
requeridas de outras tecnologias.
c) A construção de Ajax é baseada no padrão JSF 2.0 Ajax APIs (Application
Programming Interface).
d) possui um skinning Framework com mais de 25 temas.
O Hibernate - (HIBERNATE, 2012). É um framework para o mapeamento objeto relacional escrito na linguagem Java e é também disponibilizado em .Net com o
nome NHibernate. Esse framework facilita o mapeamento dos atributos entre uma
base de dados relacional e o modelo de objetos de uma aplicação por meio do uso de
arquivos XML.
O Hibernate visa minimizar a complexidade dos programas Java baseados no
modelo orientado a objeto que trabalham com banco de dados no modelo relacional.
O Hibernate transforma os dados tabulares de um banco de dados em um grafo de
objetos definido pelo desenvolvedor. Sua principal característica é a transformação
das classes Java para tabelas de dados e dos tipos de dados Java para tipos SQL
(Structured Query Language). O Hibernate gera as sentenças SQL, mantendo o programa portável para qualquer banco de dados padrão SQL.
1.3.7 Ambiente de Desenvolvimento
Eclipse ambiente escolhido no desenvolvimento do software versão Java
EE-mars, que suporta a linguagem de programação java e xhtml. Este ambiente foi
selecionado pelo facto de ter um domínio pessoal, e mais tempo de prática no mesmo,
com relação a outros IDE.
É um dos mais completo Ambiente de Desenvolvimento Integrado (IDE, siglas
em inglês) Java EE/J2EE para a plataforma de código aberto Eclipse. Tem como
principais características:
33

Código aberto: Eclipse integra hoje as tecnologias más
inovadoras de códigos abertos, para oferecer um ambiente de desenvolvimento
Web J2EE, XML, UML e bases de dados com uma variedade de conectores de
servidor para acelerar o desenvolvimento, implementação, testes e portabilidade.
1.3.8 Ferramentas Auxiliares
Adicionalmente se utilizaram algumas ferramentas auxiliares para o
desenvolvimento deste trabalho. Em este epígrafe se fala brevemente de cada uma
delas.
iReport é uma ferramenta visual escrita em Java para a elaboração e desenho
de relatórios da JasperReports. Brinda uma interface intuitiva e amigável para criar
relatórios complexos em menor tempo possível. Se baseia na sintaxe XML para a
geração de código (Furutani, 2005).
A seguir apresentam-se algumas de suas principais características.
 100% escrito em Java, código aberto e gratuito.
 Suporta internacionalização nativamente.
 Facilidade de instalação.
 Incluem assistentes.
 Variedade de fontes incluídas.
 Compilador e exportador integrado.
 Compatível com JDBC.
 Suporte para sub-relatorios.
 Permite guardar copias de segurança
 Suporte para planilhas.
Workbench for Databases (Workbench, 2012) é uma ferramenta para projecto de banco de dados que auxilia a criar e a manter bancos de dados. Essa ferramenta utiliza diagramas de entidade e relacionamentos para projetar e gerar bases de
dados graficamente e sentenças SQLs.
Os principais recursos da ferramenta Workbench for Databases são:
34
a) modelar visualmente bancos de dados – a modelagem é feita graficamente
por meio de diagramas de entidades e relacionamentos. O projecto pode ser apresentado em níveis de detalhes distintos.
b) gerar bancos de dados – gerar scripts DDL (Data Definition Language) completos para criar o banco de dados ou gerá-lo diretamente.
c) importar base de dados – derivar um modelo gráfico a partir de um banco
de dados existente. A engenharia reversa é feita diretamente a partir do banco de
dados ou importada de scripts SQL.
Resumo das técnologias selecionadas
A tabela 1 apresenta um resumo das tecnologias utilizadas para modelagem,
implementação e execução do sistema. Elas estão distribuídas nas camadas de interface, aplicação (lógica de negócio), servidor web e base de dados.
Tabela 1 – Tecnologias selecionadas para o desenvolvimento do sistema
Processo de engenharia de software usado para
orientar o desenvolvimento do software.
Ambiente Integrado usado no desenvolvimento
do projecto v: 2012
Linguagem de programação usada para
programar as classes java v:1.7.0
Linguagem de programação usada para programar as páginas web.
Usado para a documentação da modelagem
v:2010
Framework usado no mapeamento objeto relacional das classes v: 5.2.7 (2012)
35
Usado para o control entre as classes Java e os
JSPs. V: 2.0 (2012)
Framework usado no desenvolvimento das interfaces da aplicação. V: 6 (2012)
Usado como gestor do banco de dados
V: 5.7.17.0 (2012)
Workbench 2012 usado para modelagem do
banco de dados
Contêiner usado como servidor web.v: 8.5 (2012)
Conclusão do Capítulo
Neste primeiro capítulo analizou-se os principais elementos que fazem
referência aos fundamentos teóricos sobre o tema a ser desenvolvido no presente
trabalho, tendo em conta a situação problemática e o objecto de estudo, o autor
identificou os problemas na área da recepção do centro médico “MEDP”. Área
responsavel em gerir toda informação relativa aos seus pacientes, gerando desta
forma o arquivo do Historial Clínico dos pacientes. Foram analisados os processos a
automatizar, e fez-se um resumo das ferramentas a serem utilizadas na modelagem
de acordo com a tabela 1.
36
CAPÍTULO 2: DESENVOLVIMENTO DO SISTEMA
Este capítulo apresenta uma proposta a problemática, seguindo os fluxos de
trabalho do RUP na seguinte ordem: modelagem do negócio, requisitos funcionais e
requisitos não funcionais, análise e desenho do sistema, implementação, e teste.
Introdução
Neste capítulo é feita a descrição do modelo de negocio actual de forma
resumida, enumerando as regras do negocio existentes no desenvolver do próprio.
Define-se também os actores do negocio, e elabora-se o diagrama de casos de usos
do negocio, bem como os diagramas de actividades, para podermos descrever os
casos de uso do negocio. E atraves do diagrama do modelo de objetos estabelecer a
relação entre os trabalhadores e as entidades do negocio.
Alem se apresenta a arquitectura do sistema, os diagramas de classes
utilizados na elaboraçao. Se apresentam também o modelo lógico da base de dados,
e o diagrama de objectos aonde se faz a distribuição do sistema representado por
nodos.
Modelo do Negócio
O modelo de negócio é o primeiro fluxo que apresenta o RUP para desenvolver um software. O mesmo permite compreender a estrutura e a dinâmica da entidade
na qual se vai implementar o sistema. Se analisa a problemática existente, identificando os processos envolvidos no negócio a fim de compreende-los e propor potenciais melhorias. Para isto se identificam casos de uso, atores, trabalhadores e entidades associados. Por último se determinam os requerimentos do sistema que vão suportar a organização.
O fluxo de trabalho do negócio permite descrever o negócio actual e modelar
o negócio proposto, dá uma visão do que é necessário fazer para dar resposta a solicitação do usuário. A modelação do negócio brinda uma via natural para determinar
os requerimentos do sistema de informação.
37
2.2.1 Descrição do Negócio
O Centro Médico MEDP recebe diariamente pacientes em busca de
atendimento sanitário, por parte dos profissionais de saúde daquele centro. Dando
início desta forma ao processo de atendimento do paciente, que é feito por um
recepcionista da área da recepção que através da observação do estado do paciente
o avalia, classificando em dois níveis normal( paciente que não necessita de
intervenção médica imediata ) ou crítico (paciente que necessita com urgência de
uma intervenção médica ).
Se o estado do paciente for considerado normal, o recepcionista faz o registo
dos dados pessoais do paciente e os serviços que este necessitar, no processo de
registo obtem-se os seguintes dados do paciente (nome, sexo, idade, numero de
telefone, tipos de análises, tipos de consulta ou outros serviços(atendimento de
emergência, curativos, injecção, aplicação de soro) e passa um recibo ao paciente
descrevendo os serviços requisitados e o valor dos mesmos. logo em seguida o
paciente é encaminhado ao departamento a seguir para continuar o seu atendimento.
Se o estado do paciente for considerado crítico, o paciente é encaminhado
de imediato ao departamento de enfermagem aonde lhe é prestado os primeiros
socorros. Logo após a recuperação do paciente, ele volta a recepção onde faz o seu
registo dos dados pessoais e dos serviços que lhe foram prestados de emergência,
e\ou os serviços que o mesmo ainda necessita, e é encaminhado ao departamento a
seguir para continuar o seu atendimento.
Quando o paciênte ja esta registado, normalmente ele é direcionado ao
departamento de enfermagem onde o enfermeiro faz a triagem do paciente obtendo
outros dados do paciente como (peso, idade, altura, glicémia, pressão arterial) e
completa os seus dados. Caso seja necessário, ou o paciente tenha solicitado “na
recepção”, ter uma consulta com o Dr. o paciente é encaminhado ao consultório
médico, aonde é examinado e lhe é passado uma preescrição dos exames a fazer no
laboratório caso necessário. E se não for necessário o Dr. passa a receita e a
dosagem dos fármacos.
38
As Regras do Negócio definidas são:
 O centro funciona 24/24 horas de segunda a domingo
 O paciente pode fazer análise com consulta interna ou externa
 O paciente so faz consulta e análise se fizer o registo e o pagamento
2.2.2 Processos do Negócio
Em todo o processo realizam-se conjunto de actividadess essenciais para produzir um resultado entendido e medido para um cliente de um negócio. Essas actividadess também são conhecidas por processos do negócio.
1. Gerir Pacientes
2. Gerir Consultas
3. Gerir Análises
4. Gerir Outros Serviços
5. Consultar Serviços
6. Atender Serviços
7. Registar Pagamentos
8. Consultar Historial Clíinico
2.2.3 Actores do Negócio
Actor do negócio é toda entidade, uma pessoa ou um sistema que interage
com o negócio mas não faz parte do mesmo, como ilustra a tabela 2.
Tabela 2 - Actores do negócio
Nome do ator
Descrição
Paciente: É a pessoa que vai ao centro médico para receber
atendimento, solicitando aconpanhamento médico, consultas, análises ou
outro serviço de saúde prestado pelo centro.
Director: É a pessoa que solicita relatórios para avaliações
39
2.2.4 Casos de Uso do Negócio
A descrição dos casos de uso do negócio permite modelar uma sequência de
actividades, permitindo saber, área e a pessoa da entidade que é responsavel pela
execução de cada actividade e as entidades do negócio envolvidas no processo.
Como mostra o diagrama da figura 3 e as respectivas descrições correspondentes a
cada caso de uso do negócio, descritos a seguir.
1- Solicitar consulta
2- Solicitar análise
3- Solicitar outros serviços
4- Solicitar Relatórios
A figura 3 ilustra todos os casos de uso do negócio levados a cabo no centro
médico MEDP.
Figura 3 –Diagrama dos casos de uso do negócio
40
Descrição dos Casos de Uso do Negócio e seus Diagramas de
Actividades
Um diagrama de actividade descreve o comportamento de um processo ou
função pela especificação da sequência de operações (actividades e/ou acções e
decisões que permitem determinar quando e como elas são realizadas (Videira, 2005,
p. 222).
Caso de uso do negócio solicitar consulta
A seguir temos a tabela 3 que mostra a descrição de um dos caso de uso do
negócio solicitar consulta seguido do seu diagrama de actividade.
Tabela 3 - Descrição do caso de uso do negócio solicitar consulta
Nome do caso de uso
Actor
Propósito
Solicitar consulta
Paciente
Permitir a qualquer paciente que deseje, realizar
consultas.
Resumo: O caso de uso começa quando o paciente solicita uma consulta
de especialidade com o Dr. fornecendo os seus dados pessoais e o tipo de consulta
o recepcionista verifica os dados e se há disponivel algum doutor da especialidade
desejada pelo paciente, regista e cobra pela consulta. O caso de uso termina quando
o paciente é encaminhado ao Doutor.
Precondicões
Tem de estar disponivel um Dr. da especialidade
solicitada pelo paciente.
O paciente deve receber o comprovativo do
Poscondições
registo da consulta.
41
Acção do ator
1- Solicitar consulta de
especialidade
Resposta do negócio
1.1-
O recepcionista confirma se há médico da
especialidade e a sua disponibilidade CA1
CA1- Se não existir nenhum médico
Curso Alternativo
disponivel na especialidade desejada,
termina o caso de uso.
Diagrama de actividade solicitar consulta
A figura 4 mostra o diagrama de actividade do caso de uso solicitar consulta, que
faz referência da interação entre os atores do negócio, paciente e recepcionista, e as
suas acções levadas a cabo no caso de uso.
Figura 4- Diagrama de actividade solicitar consulta
42
Caso de uso do negócio solicitar análise
A seguir na tabela 4 temos a descrição do caso de uso do negócio solicitar
análise, seguido do seu respectivo diagrama de actividade.
Tabela 4 - Descrição do caso de uso do negócio solicitar análise
Nome do caso de uso
Actor
Propósito
Solicitar análise
Paciente
Permitir a qualquer paciente que deseje, realizar
análises de consultas internas ou externas.
Resumo: O caso de uso começa quando o paciente solicita a realização
de análise. fornecendo os seus dados pessoais e o tipo de análise a realizar, o
recepcionista verifica os dados e se o laboratório esta a realizar o tipo de análise,
regista e cobra pela análise. O caso de uso termina quando o paciente é encaminhado
ao laboratório.
Precondicões
O laboratório tem que estar disponivel a realizar o
tipo de análise desejada.
O paciente deve receber o comprovativo do
Poscondições
registo da análise.
Acção do ator
2- Solicitar um tipo de
análise
Resposta do negócio
1.2-
O recepcionista confirma se o laboratório
esta a realizar o tipo de análise CA1
CA1- Se o laboratório não estiver a realizar
Curso Alternativo
o tipo de análise desejado, o caso de uso
termina.
43
Diagrama de actividade solicitar análise
A figura 5 mostra o diagrama de actividade do caso de uso solicitar análise, que
faz referência da interação entre os atores do negócio, paciente e recepcionista, e as
suas acções levadas a cabo no caso de uso.
Figura 5 - Diagrama de actividade solicitar análise
44
Caso de uso do negócio solicitar outros serviços
A tabela 5 ilustra a descrição do caso de uso do negócio solicitar serviços
complementares prestados pelo centro MEDP, seguido de seu respectivo diagrama
de actividade.
Tabela 5 – Descrição do caso de uso do negócio solicitar outros serviços
Nome do caso de uso
Solicitar outros serviços
Actor
Propósito
Paciente
Permitir a qualquer paciente que deseje, qualquer
outro serviço auxiliar.
Resumo: O caso de uso começa quando o paciente solicita outro serviço
prestado pelo centro, por exemplo um serviço ambulatório. O recepcionista verifica
os serviços pretendidos, regista e cobra pelo serviço. O caso de uso termina quando
o paciente é encaminhado ao serviço pretendido.
Precondicões
O serviço pretendido tem que estar disponível no
centro.
O paciente deve receber o comprovativo do
Poscondições
registo do serviço a receber.
Acção do ator
3- Solicitar outros
serviços
Resposta do negócio
1.3-
O recepcionista confirma se o serviço é
prestado CA1
CA1- Se o serviço pretendido não estiver
Curso Alternativo
disponivel termina o caso de uso.
45
Diagrama de actividade solicitar outros serviços
A seguir a figura 6 mostra o diagrama de actividade do caso de uso solicitar outros
serviços, que faz referência da interação entre os atores do negócio, paciente e
recepcionista, e as suas acções levadas a cabo no caso de uso.
Figura 6 – Diagrama de actividade solicitar outros serviços
46
Caso de uso do negócio solicitar relatório
A tabela 6 ilustra a descrição do caso de uso do negócio solicitar relatório,
seguido de seu respectivo diagrama de actividade.
Tabela 6 – Descrição do caso de uso do negócio solicitar relatórios
Nome do caso de uso
Actor
Propósito
Solicitar relatório
Director
Permitir ao director do centro consultar e avaliar
todo processo levado a cabo no centro.
Resumo: O caso de uso começa quando o director solicita o livro de
relatórios contendo informações sobre os pacientes e os serviços prestados aos
mesmos. O recepcionista procura o livro através da data pretendida. O caso de uso
termina quando o director recebe o bloco.
Precondicões
Poscondições
O livro requisitado na data pretendida tem que ter
informação registada.
Após a consulta, o livro tem de ser devolvido.
Acção do ator
4- Solicitar relatório
Resposta do negócio
1.4-
O recepcionista confirma se o relatório esta
disponivel CA1
Curso Alternativo
CA1- Se o livro de relatório não estiver
disponivel termina o caso de uso.
Diagrama de actividade solicitar relatório
Figura 7 – Diagrama de actividade solicitar relatório
47
2.2.5 Trabalhadores do Negócio
Trabalhadores do negócio representa pessoas ou sistemas (software) dentro
do negócio, e são os que realizam as actividades que estão compreendidas dentro de
um caso de uso.
A tabela 7 ilustra todos os trabalhadores envolvidos no processo de atendimento aos pacientes do centro MEDP.
Tabela 7 – Trabalhadores do negócio
Nome do trabalhador
Recepcionista
Descrição
É a pessoa que recebe todo paciente, faz
o seu registo e o encaminha para os demais
departamentos.
É a pessoa encaregada de fazer a triagem
Enfermeiro
ao paciente e avaliar o seu estado de saúde.
É a pessoa encarregada de fazer a coleta
Analista
Doutor
e análise laboratorial das amostras do paciente.
É a pessoa encaregada de consultar o paciente,
pedir exames laboratoriais, diagnosticar o paciente
e preescrever receita.

48
2.2.6 Entidades do Negócio
Uma entidade em um negócio é normalmente um objecto físico e palpavel,
que os trabalhadores do negócio manipulam para registar diversas informações da
organização ex: factura, livro de registo etc.
1. Resultados de análises
2. Livro de registos
3. Facturas
4. Recibo de Receitas
5. Recibo de Dosagem
6. Tabela de preços
2.2.7 Modelo de Objectos
Modelo de objectos de negócio, é um modelo interno a um negócio. Descreve
como cada caso de uso do negócio é levado a cabo por parte de um conjunto de
trabalhadores que utilizam um conjunto de entidades do negócio e de entidades de
trabalho como mostra a figura 8.








Figura 8 – Modelo de objectos
49
2.2.8 Descrição do Objecto de Automatização
Automatizar o processo de gestão do Historial Clínico dos pacientes do centro
médico MEDP em Benguela. O sistema deve permitir:
•
Registar paciente, retendo o nome, idade, sexo, filiação, numero de telefone.
•
Registar funcionário, retendo o nome, categoria, especialidade.
•
Registar análises, retendo o tipo de análise, a área de especialidade e o valor
da análise.
•
Registar consultas, retendo tipo de consulta e o valor da consulta.
•
Registar o tipo de outros serviços(curativos, injecção, aplicação de soro), e o
seu respectivo valor.
•
Inserir dados da triagem do paciente retendo, peso, altura, glicémia, pressão
arterial, Frequência cardiaca, Frequência respiratória, classificação do estado de
gravidade do paciente.
•
Arquivar HCE, retendo todos os dados do paciente, e alem o nome do
funcionário que o atendeu, as consultas feitas, as análises realizadas, (se for
o caso), os dados de outros serviços que o foram prestados, a data que foi
atendido,o diagnóstico a receita passada, e o valor total pago pelo paciente,
bem como permitir actualizar posteriormente as mesmas informações.
•
Emitir fatura, para confirmar os serviços prestados aos pacientes ( ver anexo
D ).
•
Imprimir relatórios do HCE Historial Clínico Eletrónico dos pacientes.
Para arquivar ou actualizar qualquer informação, os funcionários, quer seja um
recepcionista, um enfermeiro ou um doutor devem identificar-se com o seu nome de
utilizador e uma contra-senha; o sistema também deverá permitir a consulta das
informações.
50
Requisitos do Sistema
Nesta etapa definiu-se os requisitos funcionais e não funcionais do sistema.
Se enumera e
descreve-se os actores que intervem no sistema propondo uma
solução atravez de diagramas de casos de usos.
2.3.1 Requisitos Funcionais
Os requisitos funcionais são as capacidades ou condicões que o sistema deve
cumprir: estas definem as funcionalidades que o sistema será capaz de realizar,
expressa a natureza do funcionamento do sistema, mostra como interage o sistema
com ambiente e qual vai ser seu estado de funcionamento. Estes requisitos são
geralmente melhor descritos no Modelo de Casos de Uso do sistema atravez dos
casos de uso (Fuentes, 2015).
O presente projecto deverá cumprir com uma série de requerimentos
funcionais tais como:
 RF1:Autenticar
 RF2:Gerir Usuários
 RF3:Gerir Serviços
 RF4:Atender Serviços
 RF5: Gerir Pacientes
 RF6:Salvar HCE
 RF7:Pesquizar Paciente
 RF8:Actualizar Triagem
 RF9:Gerir Funcionários
 RF10:Gerir Colaboradores
 RF11:Gerar Relatórios
 RF12:Sair do sistema
51
2.3.2 Requisitos não Funcionais
Os requisitos não funcionais especificam as propriedades do sistema, e as
restrições físicas sobre os requisitos funcionais (Fuentes, 2015). Os requerimentos
não funcionais do sistema proposto são:
Interface externa O sistema apresenta uma aparéncia armónica em termos
das cores utilizadas nas diferentes interfaces tornando-as, legivel e simples de usar.
Esta constituido por uma página principal com um menu que permite a navegabilidade
rápida em todas outra interfaces que conpõem o sistema. O sistema conta também
com informações extras para tornar a aparência mais agradavel como, o logotipo da
instituição, informação sobre o tempo e o funcionário logado no sistema.
Usabilidade: A aplicação esta dirigida para o pessoal do centro médico MEDP
com diferentes capacidades no uso de sistemas informáticos por isso, o sistema tem
um nível de flexibilidade ao ser utilizado sem que se tenha uma vasta experiencia no
uso de computadores. Contando com uma interface gráfica consistente e foram
eliminados os erros de cálculos por estes serem automáticos.
Rendimento: Este sistema a ser implementado vai trabalhar com um grande
volume de dados, por isto dever contar com uma velocidade de procesamento para
todos os requerimentos funcionais devido ao seu objectivo, dai
que todas suas
funções deverão ter tempos de resposta curtos, o que aumentará a operabilidade do
sistema. E para isto é necessário que se cumpram com os requisitos de hardware
definidos.
Suporte: O sistema deve receber manutenção pelo menos uma vez por ano,
alem disto, se deve continuar com um processo de melhora e aperfeiçoamento com o
propósito de adicionar novos serviços e ferramentas que ofereçam ao pessoal do
centro MEDP maior facilidade na gestão das informações relacionadas aos pacientes
e não so.
Portabilidade: A aplicação poderá ser usada em qualquer plataforma que
suporte XHTML, CSS, Javascript, MySQL, Apache (Linux, Windows, Mac, etc).
52
Software: tanto no lado do servidor, como no lado do cliente a aplicação
poderá ser usada em sistemas operativos como ‘windows 7, 8, 8.1 e 10. Linux, Mac e
rodar nos principais navegadores como Internet Explorer, Mozilla Firefox, Opera,
Google Chrome e Baidu nos computadores clientes.
Segurança: no que toca a segurança resaltam aspectos como:
Confidencialidade: A informação estará protegida contra acessos não
autorizados utilizando para isto todos os mecanismos de autenticação e encriptação
que podem garantir que uma pessoa não autorizada entre no sistema.
Integridade: A informação gerida pelo sistema será objecto de uma cuidadosa
protecção contra a corrupção e estados de inconsisténcias. Dados como contrasenha
seram encriptados por serem sensiveis, para garantir a confidencialidade dos
mesmos.
Confiabilidade: O sistema conta com uma baixa percentagem de falhas e em
caso de ocorrer uma, deverá ser previsto um plano como backup, para uma melhor
proteção e rápida recuperação do problema ocorrido.
Hardware: Do lado do cliente se requere no mínimo um computador com um
microprocesador Intel de 1.6 GHz ou superior, 1 Gb de RAM e 40 Gb de disco duro.
Uma placa de rede com transferência de 100 Mb/s ou equivalente.
Do lado do servidor web um microprocesador Intel de 2.40 GHz com 6 Gb
de RAM, um disco duro de 120 Gb e uma placa de Rede de 100Mb/s
Os requisitos do servidor da base de dados poder ser iguais as do servidor
web, mas deve contar com um disco duro adicional de no mínimo 320 Gb.
Análise e desenho do sistema
A análise e desenho do sistema permite apresentar e descrever o sistema ao
promenor, atraves dos diagramas associados ao mesmo.
53
2.4.1 Modelagem do sistema
O sistema esta baseado em um paradigma de programação orientada a
objetos. implicando uma troca substancial na forma em que se modela a aplicação.
Todos os elementos do sistema se representam atraves de classes.
Neste modelo se utilizam quatro tipos de classes fundamentais. As classes
que representam as interfaces de usuario. Alem, estão os serviços que tem as funções
de gerir a lógica do negócio. Por outro lado se encontram as entidades que
representam os objetos que irão persistir na base de dados os Value Objects (VO)
que actuam como objetos de intercambio entre os distinto níveis do sistema.
2.4.1.1 Actores do Sistema
um actor do sistema é todo elemento externo do sistema que interage com o
mesmo e faz uso das suas funcionalidades. Um actor pode ser uma pessoa ou outro
sistema, a tabela 8 ilustra todos atores do sistema.
Tabela 8 – Atores do sistema
Nome do actor
Descrição
Usuario
Actor genérico que representa todos os
usuarios que se autenticam no sistema.
É a pessoa encarregada de gerir os
Administrador
usuarios que acedem ao sistema, definir seus
níveis de acesso tendo em conta a sua função, é
a pessoa autorizada à alterar a contrasenha dos
mesmo.
54
É um actor encarregado de pesquizar e
Enfermeiro
Recepcionista
actualizar dados do paciente.
É um actor encarregado de registar,
apagar, ou actualizar toda informação referente
aos pacientes e os serviços que estes usufruirem.
Alem disto Cria e gere o HCE
Diagrama de representação dos atores do sistema
O diagrama da figura 9 mostra os actores do sistema e a hierarquia existente
entre eles.
Figura 9 – Diagrama dos atores do sistema
55
2.4.1.2 Casos de uso do sistema
Um caso de uso do sistema é uma sequência de acções que um ou mais
actores realizam. A seguir descreve-se todos casos de uso do sistema, e por serem
muitos, então faremos a demostração dos considerados mais importantes e
abrangentes.
 RF1:Autenticar
 RF2: Gerir Pacientes
 RF3:Gerir Colaboradores
 RF4:Gerir Serviços
 RF5:Actualizar Triagem
 RF6:Consultar HCE
 RF7:Atender Serviços
 RF8:Gerir Funcionários
 RF9:Gerir Usuários
 RF10:Consultar Relatórios
2.4.1.3 Diagrama dos casos de uso do sistema
A figura 10 mostra o diagrama de todos casos de uso definidos para o sistema.
Esse diagrama também mostra que todas as operações serão feitas após o usuário
estar logado no sistema.
Por meio desse diagrama é possível, também, verificar que o administrador
herda todas as funcionalidades de um usuário genérico, e além tem outras funcionalidades específicas que so podem ser realizadas por ele, devido ao seu nível de
acesso a todas as funcionalidades do sistema.
56
Figura 10– Diagrama dos casos de uso do sistema
57
2.4.1.4 Descrição dos casos de uso de sistema
A tabela 9 mostra a descrição do caso do sistema autenticar usuário, que faz parte do
pacote de segurança.
Tabela 9 – Caso de uso do sistema autenticar usuário
Nome do caso de uso
Autenticar usuário
Actor
Usuário
Resumo: O caso de uso começa quando o usuario deseja
aceder ao sistema. O mesmo introduz o nome de usuario e contrasenha,
dado o nível que tenha, tenta aceder as funcionalidades específicas que
foram atribuidas.
Precondicões
O usuario deve estar previamente cadastrado
na base de datos do sistema.
Poscondições
Fluxo Básico
Acções do actor
Resposta do sistema
1 O actor insere o seu nome de
1 O sistema verifica se o usuário
usuário e contrasenha.
existe e a contrasenha esta
correcta(FA1)
1.1 O sistema exibe a interface
principal.
Fluxo alternativo
FA1 – Se o usuário inserir dados errados ou não estar cadastrado
na base de dados, o sistema mostra uma mensagem notificando o erro.
58
A tabela 10 mostra a descrição do caso do sistema gerir usuário.
Tabela 10 – Caso de uso do sistema gerir usuário
Nome do caso de uso
Gerir usuario
Actor
Administrador
Resumo: O caso de uso começa quando o administrador tem
que gerir algúm usuario do sistema. O caso de uso permite adicionar, alterar e
eliminar um usuario do sistema. O caso de uso termina mostrando uma
mensagem notificando que o usuario foi inserido, alterado, ou eliminado com
éxito.
Precondicões
O usuario administrador deve estar autenticado no
sistema, com os devidos previlégios.
Poscondições O caso de uso termina com o armazenamento de
toda informação do usuário na base de dados.
Fluxo Básico
Acções do actor
Resposta do sistema
1 O actor clica em adicionar ou em
1.1 O sistema mostra um formulário
alterar usuário.
para escolher o funcionário á
adicionar como usuário.
2 O actor escolhe o funcionário a
adicionar como usuário define o seu
nível de acesso e a sua contrasenha.
2.1 O sistema verifica os dados(FA1)
2.2 O sistema guarda os dados do
novo usuário na base de dados.
Fluxo alternativo
FA1 Se os dados estiverem incorrectos, o sistema mostra uma
mensagem notificando o erro.
59
A tabela 11 mostra a descrição do caso do sistema gerir serviços, que faz parte do
pacote atendimento médico.
Tabela 11 – Caso de uso do sistema gerir serviços
Nome do caso de uso
Gerir Serviços
Actores
Recepcionista e Administrador
Resumo: O caso de uso começa quando o actor deseja Gerir os
serviços prestados no centro. O caso de uso permite inserir, alterar ou apagar
um serviço que pode ser um tipo de análise, tipo de consulta ou serviços
anbulatório. O caso de uso termina mostrando uma mensagem informando o
sucesso da operação realizada.
Precondições
O usuário deve estar autenticado no
sistema.
Poscondições
O caso de uso deve terminar com o
armazenamento na base de dados a informação
relativa ao novo serviço ou da alteração feita.
Fluxo Básico
Acções do actor
1 O actor clica na opção desejada
(novo, editar, apagar).
2 O actor insere novos dados ou
modifica.
Resposta do sistema
1.1 O sistema abre um formulário de
acordo a opção desejada.
2.1 O sistema verifica osdados(FA1).
2.2 O sistema guarda os dados na
base de dados.
Fluxo alternativo
FA1 Se os dados estiverem incorrectos, o sistema mostra uma mensagem
notificando o erro.
60
A tabela 12 mostra a descrição do caso do sistema gerir paciente, mais um dos
requisitos que faz parte do pacote de atendimento médico.
Tabela 12 – Caso de uso do sistema gerir paciente
Nome do caso de uso
Gerir paciente
Actor
Recepcionista
Resumo: O caso de uso começa quando o recepcionista deseja
gerir os dados de um paciente. O caso de uso permite inserir, alterar ou
eliminar os dados do paciente. O caso de uso termina mostrando uma
mensagem notificando que os dados do paciente foram inseridos, alterados
ou eliminados com éxito.
Precondições
O usuario deve estar autenticado no
sistema.
Poscondições
Deve terminar com o armazenamento na
base de dados a informação relativa ao paciente.
Fluxo básico
Acções do actor
Resposta do sistema
1 O actor clica na opção desejada 1.1 O sistema abre um formulário de
(novo, editar, eliminar).
acordo a opção desejada.
2 O actor insere novos dados ou
modifica.
2.1 O sistema verifica os dados(FA1).
2.2 O sistema guarda os dados na
base de dados
Fluxo alternativo
FA1 Se os dados estiverem incorrectos, o sistema mostra uma mensagem
notificando o erro.
61
A tabela 13 mostra a descrição do caso de uso do sistema consultar relatórios.
Tabela 13 – Caso de uso do sistema ver relatórios
Nome do caso de uso
Ver relatórios
Actor
Administrador
Resumo O caso de uso começa quando o Administrador do
centro deseja ver os relatórios estatísticos de um pacinte. O caso de uso
permite imprimir, actualizar ou apagar os mesmos, e termina com a
visualização de cada relatório.
Precondições
O usuario deve estar autenticado no sistema e ter
privilégio de administrador.
Poscondições
Fluxo básico
Acções do actor
Resposta do sistema
1 O actor marca uma data e clica em 1.1 O sistema procura na base de
pesquizar.
dados toda informação relativa a data
marcada(FA1).
1.2 O sistema mostra a informação
relativa a data desejada.
Fluxo alternativo
FA1 Se não existir na base de dados a informação que permita gerar o
relatório.o sistema mostra uma mensagem notificando que não existe
informação na data marcada.
62
2.4.2 Diagramas de Sequência
O sistema implementado realiza processos para chegar a resultados. Para
exemplificar as funções representadas por esses processos foram utilizados diagramas de sequência. As figuras a seguir apresentam os diagramas de sequência de
algums processos de autenticação ao sistema e no atendimento de pacientes.
O diagrama da figura 11 ilustra o processo para efetuar login no sistema. Se
o Usuário e a Contrasenha estiverem corretos, o sistema realiza o login e informa que
o mesmo foi efetuado.
Figura 11 – Diagrama de sequência logar no sistema
63
O diagrama da figura 12 está o processo de registro de um paciente. Nesse
processo, o paciente informa os seus dados ao funcionário que o cadastra no sistema.
O sistema faz a verificação se o paciente já está cadastrado, caso ele não esteja é
permitido o cadastro do mesmo.
Figura 12 – Diagrama de sequência registar novo paciente
64
O diagrama da figura 13 mostra o processo para cadastro de um tipo de de
serviço prestado, neste caso análise, que o centro oferece. O sistema recebe os dados
do tipo de análise, verifica se ela já existe, caso não exista permite o cadastro do
mesmo.
Figura 13 – Diagrama de sequência registar novo serviço
O diagrama da figura 14 representa o atendimento a um paciente. Nesse processo o paciente informa dado pessoal e os serviços pretendidos. Se o paciente não
estiver cadastrado, o sistema solicita seu cadastro e so após isso é que regista os
serviços requeridos pelo paciente.
Figura 14 – Diagrama de sequência atender paciente
65
2.4.3 Diagramas de Comunicação
Designado anteriormente como diagrama de Colaboração até a versão 1.5 da
UML, o diagrama de comunicação mostra, de uma maneira semelhante ao diagrama
de sequência a colaboração dinâmica entre os objetos, mas não se foca no decorrer
do tempo mais sim, no contexto do sistema.
Um
diagrama
de
comunicação
ilustra
uma
interação
organizada
espacialmente. De forma distinta dos diagramas de sequência, um diagrama de
colaboração mostra as relações entre objectos que desempenham diferentes papeis.
Por outro lado, um diagrama de comunicação não mostra o tempo como uma
dimensão separada pelo que a sequência de interações e de actividades concorrentes
é representada através de uma expressão de sequência, no início de cada
mensagem, para identificar a ordem da sua execução. (Silva e Videira, 2005, p. 200).
 Complementa o Diagrama de Sequência
 Não se preocupa com a temporalidade do processo, se concentrando
apenas nos relacionamentos entre os elementos e nas mensagens que
são trocadas
 Os objetos aqui não possuem linha de vida como no de Sequência
A figura 15 ilustra o processo para efetuar login no sistema. Se o Usuário e a
ContraSenha estiverem corretos, o sistema realiza o login e por meio de uma mensagem de sucesso informa que o mesmo foi efetuado.
Figura 15 – Diagrama de comunicação logar no sistema
66
A figura 16 ilustra o processo de registro de um paciente. Nesse processo, o
paciente informa os seus dados ao funcionário que o cadastra no sistema. O sistema
faz a verificação se o paciente já está cadastrado é exibida uma mensagem de alerta,
caso ele não esteja é permitido o cadastro do mesmo e exibido uma mensagem de
sucesso.
Figura 16 – Diagrama de comunicação registar novo paciente
A figura 17 ilustra o processo para cadastro de um tipo de de serviço a ser
prestado pelo centro. O sistema recebe os dados do tipo de serviço, verifica se ela já
existe, caso não exista permite o cadastro do mesmo, e mostra uma mensagem de
sucesso. Caso existe mostra uma mensagem de erro.
Figura 17 – Diagrama de comunicação registar novo paciente
67
A figura 18 ilustra o atendimento a um paciente. Nesse processo o paciente
informa os dados pessoais e os serviços pretendidos. Se o paciente não estiver cadastrado, o sistema solicita seu cadastro e so após isso é que regista os serviços
requeridos pelo paciente, cria o seu Historial Clínico e é adicionado para interface da
triagem, terminando com a impressão do comprovativo do paciente.
Figura 18 – Diagrama de comunicação atender paciente
2.4.4 Diagrama de Classes
Um diagrama de classes é uma vista estática da estructura de um sistema.
nele se mostram as classes definidas com as suas operações e atributos, bem como
as relações existentes entre elas.
A figura 19 contém o diagrama de classes do sistema. Por meio desse diagrama é possível verificar que a única maneira de acesso ao sistema é por login. O
acesso é realizado por meio da classe login. Por questão de segurança somente poderão fazer login os usuários que forem cadastrados e previamente autorizados pelo
administrador do Sistema.
68
Figura 19 – Diagrama de classes do sistema
69
Modelo Lógico da Base de Dados
Figura 20 – Figura do modelo lógico da base de dados
Implementação
Após a modelagem do sistema a ser implementado, foi criado um protótipo,
com as respectivas telas de funcionalidades do sistema no Eclipse para Web que foi
o ambiente de desenvolvimento da aplicação. Este protótipo foi criado com o intuito
de se ter uma ideia de como o sistema irá ser apresentado, e de conhecer suas principais funcionalidades de forma a validá-las, e dando assim aos utilizadores a garantia
de também terem uma visão global do sistema que irá ser implantado, detectando os
erros antes de se implantar a versão final do sistema. E corrigindo os que eventualmente surgirão na versão de teste.
70
Nesta fase foi especificada a forma como o ecrã irá ser apresentado, os menus
e submenus que o sistema suporta.
Interfaces de usuário
A qualidade da
interface de usuário pode ser um dos motivos que conduza a um
sistema ao éxito ou ao fracasso, por isto que um dos aspectos más relevantes da
usabilidade de um sistema é a consistência da sua interface de usuário (Fuentes,
2015). A seguir se apresenta nas figuras 21 e 22 exemplos das duas principais
interfaces nomeadamente a interface de Login e so através da mesma é possivel
acessar o sistema, e a interface principal aquela que permite o acesso a todas outras
interfaces do sistema. ver em detalhes os anexos (F, G, H, I, J, K, L, M).
Figura 21 – Interface de Login
71
Figura 22 – Interface de usuário principal
2.6.1 Tratamento dos erros
Dada a importância que tem os dados que se gerem na aplicação, para manter
um correcto funcionamento, estabilidade e evitar erros, se efectu-ou um trabalho
detalhado e exaustivo de testes para identificar os possiveis erros por parte dos
usuários durante a utilização do sistema, tanto do lado do cliente como do servidor.
 A actividade de teste é o processo de executar um programa com a
intenção de descobrir um erro.
 Um bom caso de teste é aquele que tem uma elevada probabilidade de
revelar um erro ainda não descoberto.
A seguir se mostram algums exemplos de mensagens de erros que são gerados pelo
sistema ilustrado nas figuras 23, 24.
72
Alertas de erros para campos obrigatórios

Mensagens de erros a informar quando faltam dados por introduzir em campos
obrigatórios ou tipo de dado inválido.
Figura 23 – Interface de Erro por não preencher os campos obrigatórios
Antes de guardar os dados o sistema verifica se os mesmos são válidos e so
foram introduzidos tipos de dados correctos.
Figura 24 – Interface mostrando erros dos campos obrigatórios
73
Implantação
A seguir a figura 25 mostra um diagrama do modelo de funcionamento do
sistema e os seus requisitos mínimos de hardware e software para cada nodo. Se
descreve também a distribuição física do sistema. O diagrama é uma representação
em que cada nodo aparece como um dispositivo de hardware interconectado a outros
dispositivos interagindo entre sí para o correcto funcionamento do sistema. A
arquitectura do sistema se encontra formada por nodos clientes que requerem a
existência de um navegador web, para conectar-se atravez do protocolo HTTP a um
servidor de aplicações. Por sua vez o nodo servidor de aplicações é responsavel de
receber solicitações HTTP e transferir ao nodo: Servidor de Base de Dados. Para a
comunicação do nodo servidor de aplicações com o nodo Servidor de Base de Dados
se emprega o protocolo TCP.
Figura 25 – Diagrama de Implantação da aplicação web
74
Cada um dos servidores podem estar fisicamente separados e independente
ou podem estar em uma única máquina física dependendo das possiblidades
financeiras da instituição, em adquirir dois servidores distintos. Permitindo os nodos
usuários acederer aos nodos servidores atraves do protocolo HTTP e atraves um ip
ao servidor da base de dados.
Conclusão do Capítulo
Neste capítulo fez-se a modelagem do negócio actual identificando os actores
e trabalhadores da entidade, e as regras do negócio. Podendo desta forma elaborar
os diagramas de casos de uso do negócio e os diagramas de actividades de cada
caso de uso correspondente. Definiu-se também a relação existente entre cada
trabalhador com as entidades, e um modelo de objecto. Permitindo assim identificar
os requisitos funcionais e não funcionais do sistema a desemvolver através dos seus
actores e casos de uso agrupados em diferentes pacotes funcionais. Realizou-se
também as descrições dos actores e dos casos de usos do sistema, e por último deuse atenção aos requisitos extruturais, físicos e lógicos de Hardware e Software
envolvidos no sistema para tornar possivel o pleno funcinamento do sistema no seu
todo.
Por fim retratou-se sobre os elementos relacionados ao desenho do sistema,
como os pacotes do desenho, os diagramas de classes envolvidos na solução
proposta, e também fez-se apresentação dos principios de desenho que são levados
em conta, bem como o tratamento dos erros da aplicação no que concerne a
introdução de dados errados no sistema.
75
CONCLUSÕES
Se realizou o trabalho cumprindo satisfactóriamente com os objectivos
propostos.
Tal facto so foi possivel com o estudo dos processos relacionados com
Historial Clínico do Centro Médico MEDP, o que permitiu determinar os elementos
fundamentais que caracterizam um HC de pacientes. E o estudo de ferramentas de
desenvolvimento de aplicações web, e de desenho da base de dados facilitaram o
desenvolivimento do sistema. Se desenvolveu a aplicação web que permite a gestão
do historial clínico electrónico que inclui informações relacionada com serviços
prestados e o percurso clínico feito pelos pacientes. Se testou a aplicação para
detectar e corrigir os erros de validação, e verificar a segurança no armazenamento
da informação e restringir o acesso de pessoas não autorizadas as mesmas.
Após termos seguido a risca as fases que nos orienta o RUP, e completado
as etapas de concepção, elaboração e construção do projecto chegamos ao final do
mesmo, tendo em mãos um sistema que permite gerir o historial clinico dos pacientes
do centro médico MEDP.
76
RECOMENDAÇÕES
Como trabalhos futuros se recomenda:
 Estender o projecto para gestão das demais áreas de serviço do centro
como: farmácia, finanças, laboratório e consultório, integra-los neste sistema, e
incrementar os benefícios.
 Incorporar novos requisitos que não foram considerados objectivos
neste projecto, tais como: agendar consulta, alerta automático por meio de sms
ou email ao paciente, gerir recursos humanos.
 Dar formação de capacitação ao pessoal que poderá trabalhar com o
sistema de maneiras que o trabalho seja realizado com maior qualidade.
 Elaborar um manual de ajuda para os usuários que façam o uso do
sistema.
77
REFERÊNCIAS BIBLIOGRÁFICAS
Andreto, D. E., & Amaral, A. M. (2006). Software engineering for the web.
Siniciato, E. C., & Magalhães, W. (s.d.). Arquitetura para desenvolvimento de software
web utilizando novas tecnologias. Paranavaí.
Alexandre , P., & Carlos, P. (2013). Linguagens Web. 5ª edição . Lisboa: Edições
Sílabo.
Cajal., S. R. (s.d.). El impacto de la historia clínica electrónica en la investigación y la
docencia.
Çivici,
Ç.
(s.d.).
Prime
Faces
Guia
do
Usuário
6.0.
Obtido
de
http://www.primefaces.org/downloads
Fernández, R. G. (s.d.). La historia clínica eletrónica.
Ferreira, M. A. (2015). Portal web da faculdade de economia da universidade
katyavala bwila. UKB-ISP.
Fuentes, Y. M. (2015). Sistema de Gestión de Información Hospitalar. Havana.
Furutani, R. J. (2005). Jasper iReport Ferramenta para desenvolvimento e geração de
relatórios utilizando Java.
Levy, D. G. (2011). Manual del Expediente Clínico Electrónico (Primera edición ed.).
Obtido de http://www.dgis.salud.gob.mx
Luna, D. (2012). Historia Clínica Electrónica, 2012.
Magri, J. A. (s.d.). Arquitetura Dirigida a Modelos (MDA). Utilizando Modelos no
Desenvolvimento de Sistemas.
Maria, L. E., & Andrade, M. M. (2003). Fundamentos da Metodologia científica. 5ª
edição. (E. A. S.A, Ed.) São Paulo.
( APA sexta edição) estilo usado na gestão das referências bibliográficas.
78
Noval, M. A. (2015). Geracção dinámica de interfaces de usuário para dispositivos
moveis. Havana.
O'reilly, T. (2007). What is Web 2.0: Design patterns and business models for the next
generation of software. Communications & strategies, Buyto, 2007. Design
patterns and business models for the next generation. Obtido em 2017 de 2017,
de
http://www.buyto.es/general-diseno-web/diferencias-entre-aplicaciones-
web-y-aplicaciones-desktop
Otero, D. P. (2011). Beneficios y riesgos relacionados con el uso de la historia clínica
electrónica. Departamento de Informática en Salud.
Sanchez. (2010). M. Infraestrutura de software para el almacenamieto y consulta de
la História Clínica Eletrónica del sistema a las HIS,. (U. d. informáticas, Ed.)
Serna, A. (2005). Ventajas y desvantajas de la historia Clinica Electronica. Obtido de
http://www.tel.uva.es/personales/jgompil/ctmiii/HCE.pdf
Sousa, M. (1997). Dicionário de Termos Informáticos - Inglês/Português. SporPress.
Videira, C. S. (2005). UML Metodologias E Ferramentas CASE. 2ª edição.
( APA sexta edição) estilo usado na gestão das referências bibliográficas.
79
ANEXOS
A – Organigrama extrutural do centro médico MEDP
Figura 26 – Organigrama estrutural do centro médico medp
80
A1 – Capa do bloco de relatório usado para o registo das prestações
Figura 27 – Capa do bloco de relatório usado no centro MEDP
A2 – Pagina do bloco de relatório com dados registados
Figura 28 – Página do bloco de relatório
81
B – Questionário utilizado na coleta de informações
Figura 29 – Questionário utilizado para coleta de informações
82
C – Fatura gerada ao salvar os serviços prestado ao paciente
Figura 30 – Fatura gerada ao salvar os serviços prestados
83
D – Anexo da interface de login do sistema SIGELAR
Desenvolvido por Émerson Cantalice e Doglas Lima. Esse projecto busca
informatizar a maior parte possível do funcionamento de um hospital, trazendo mais
organização, gestão de produtos, pessoal e dados dos pacientes. Auxiliando também
os funcionários nas suas tarefas cotidianas como ilustra a figura 31.
Figura 31 – Interface de login do sistema SIGELAR
84
E – Anexo da interface principal do sistema SIGELAR
Desenvolvido por Émerson Cantalice e Doglas Lima. Esse projecto busca
informatizar a maior parte possível do funcionamento de um hospital, trazendo mais
organização, gestão de produtos, pessoal e dados dos pacientes. Auxiliando também
os funcionários nas suas tarefas cotidianas como ilustra a figura 32.
Figura 32 – Interface pricipal do sistema SIGELAR
85
F – Interface de acesso ao sistema do centro MEDP
O acesso ao sistema de gestão do Historial Clínico dos pacientes no centro
médico medp, é restrito à usuários previamente cadastrados e autorizados, com um
nome e uma contrasenha criptografada, inseridos na interface da figura 33.
Figura 33 – Interface de acesso ao sistema
G – Interface principal do sistema do centro MEDP
Após o usuário ter feito a autenticação na interface de login e cumprir com os
pre-requisitos estabelecidos, é encaminhado a interface principal. Na interface
principal o usuário conta com um menu geral, aonde ira aparecer os link´s de outras
interfaces ablitadas de acordo o nível de acesso do usuário logado, como mostra a
figura 34.
Figura 34 – Interface Principal do sistema
86
H – Interfaces dos diferentes níveis de acesso
Por questão de segurança existem três níveis diferentes de acesso, para que
cada usuário so tenha acesso a determinadas funções do sistema que lhe são
previamente atribuidos. Estes níveis são:
 Login Administrador – Acesso a todos itens do menu e sub-menus.
Figura 35 – Interface principal com nível de acesso Administrador
 Login Recepcionista – Acesso restrito a algums itens dos sub-menus.
Figura 36 – Interface principal com nível de acesso Recepcionista
 Login Enfermeiro – Acesso restrito a algums itens do menu e sub-menus.
Figura 37 – Interface principal com nível de acesso Enfermeiro
87
I – Interface gerir paciente
Este software esta direcionado na gestão do Historial Clínico de pacientes,
fazendo deles os atores principais no sistema a figura 38 apresenta a interface que
permite a gestão dos mesmos, atraves da inserção, actualização ou eliminação de
acordo as nessecidades do usuário.
Figura 38 – Interface para gestão dos dados dos pacientes
J – Interface prestar serviço
Nesta interface é feita prestação de todos serviços disponíveis no centro,
solicitados pelo paciente. O paciente paga pelos serviços a prestação é salva e uma
factura é emitida automaticamente confirmando o processo. figura 39
Figura 39 – Interface prestar serviço
88
K – Interface fazer consultas sobre serviços prestados
O sistema desenvolvido brinda com a possiblidade do usuário fazer consultas
gerais ou específicas sobre os serviços que são prestados, a interface na figura 40
mostra a possiblidade do usuário fazer uma consulta atraves de uma data específica.
Para aceder esta interface baste que o usuário vá ao menu “consultas” e sub-menu
“Atendimento prestado dado um dia”.
Figura 40 – Interface consultar serviços prestados
L – Interface de control de acesso
Muitas das vezes os usuários entrão no sistema alteram dados e depois
ninguem se responsabliza. Este problema é prevenido atraves do control de acesso
dos usuários como mostra a figura 41.
Figura 41 – Interface de control de acesso
89
M – Interface Ver Historial Clínico
Esta interface é uma das principais do sistema, pois é ela que tem a
responsablidade de congregar e mostrar toda informação com relação aos pacientes
que ja foram atendidos pelo centro médico. A figura 42 mostra com detalhes o historial
de cada paciente.
 Vista de todos pacientes
 Vista em detalhe dos dados de um paciente
Figura 42 – Interface ver o Historial Clínico de um paciente
90