Upload
dangngoc
View
223
Download
3
Embed Size (px)
Citation preview
FACULDADE DE TECNOLOGIA DE ITAPIRA
“OGARI DE CASTRO PACHECO”
ALLEN CORRADI DE BRITO
CARLOS LUÍS CAVENAGHI
ESTUDO DE DESENVOLVIMENTO DE SISTEMA ELETRÔNICO
PARA GERENCIAR O HISTÓRICO CLÍNICO DE PACIENTE EM
PRONTO-SOCORRO
ITAPIRA/SP 2017
FACULDADE DE TECNOLOGIA DE ITAPIRA
“OGARI DE CASTRO PACHECO”
ALLEN CORRADI DE BRITO
CARLOS LUÍS CAVENAGHI
ESTUDO DE DESENVOLVIMENTO DE SISTEMA ELETRÔNICO
PARA GERENCIAR O HISTÓRICO CLÍNICO DE PACIENTE EM
PRONTO-SOCORRO
Trabalho de Graduação apresentado ao
Curso de Tecnologia em Gestão da
Tecnologia da Informação da Faculdade de
Tecnologia de Itapira como pré-requisito para
a obtenção do Título de Tecnólogo em
Gestão da Tecnologia da Informação.
Orientador: Prof. Esp. Nilton Cesar Sacco
ITAPIRA/SP 2017
Ficha catalográfica elaborada pela Biblioteca da Faculdade de Tecnologia de Itapira – Ogari de Castro Pacheco
BRITO, Allen Corradi de. CAVENAGHI, Carlos Luís. Estudo de Desenvolvimento de Sistema Eletrônico para Gerenciar o Histórico Clínico de Paciente em Pronto-Socorro / Carlos Luís Cavenaghi; Allen Corradi de Brito. 2017. 75p. Orientador: Nilton Cesar Sacco Monografia (Graduação) – Curso Tecnologia da Gestão da Tecnologia da Informação da Faculdade de Tecnologia de Itapira, 2017.
1. Tecnologia da Informação. 2 Software. 3 Medicina. 4 Paciente. 5 Histórico I. BRITO, Allen Corradi de; CAVENAGHI, Carlos Luís. II Monografia (Graduação) – Faculdade de Tecnologia de Itapira. III. Título
B777e CDD 004.6
FACULDADE DE TECNOLOGIA DE ITAPIRA
“OGARI DE CASTRO PACHECO”
ALLEN CORRADI DE BRITO
CARLOS LUIS CAVENAGHI
ESTUDO DE DESENVOLVIMENTO DE SISTEMA ELETRÔNICO
PARA GERENCIAR O HISTÓRICO CLÍNICO DE PACIENTE EM
PRONTO-SOCORRO
Trabalho de Graduação apresentado ao Curso de Tecnologia em Gestão da
Tecnologia da Informação da Faculdade de Tecnologia de Itapira como pré-requisito
para a obtenção do Título de Tecnólogo em Gestão da Tecnologia da Informação.
STATUS: ____________________ CONCEITO: ___________________
BANCA EXAMINADORA
Prof. Dr. Joaquim M. F. Antunes Neto: _____________________________________
Profa. Dra. Simone Cardoso Leon:________________________________________
Prof. Me. Mateus Guilherme Fuini: ________________________________________
Prof. Esp. Nilton Cesar Sacco (orientador): __________________________________
ITAPIRA, 29 de Junho de 2017
RESUMO
O trabalho abordou como a tecnologia pode ajudar a área de saúde, mais
especificamente nos prontos-socorros, com o estudo de desenvolvimento de um
software que abastece um banco de dados e permite a consulta de informações sobre
os pacientes, assim como toda a sequência de seu atendimento. Através de uma
interface simples e de utilização rápida e ágil para os profissionais de saúde, é
possível melhorar o atendimento e o serviço à saúde da população. O principal
objetivo do estudo de desenvolvido de software é o auxílio aos profissionais de saúde,
agilizando assim o atendimento do paciente e gerando economia de tempo sem perda
da qualidade. Foi realizado o método científico de pesquisa através de entrevista
direta com o profissional da área de saúde para buscar compreender as necessidades
da área e utilizado apenas as informações pertinentes para o estudo de
desenvolvimento do software, após esta etapa foram elaboradas as tabelas de cada
entidade e suas respectivas relações para com as outras tabelas, foi utilizado para o
desenvolvimento do banco de dados os scripts em SQL Server e foi desenvolvido os
diagramas de caso de uso, das atividades, de classe e do banco de dados relacional.
Por fim, houve o desenvolvimento das telas do sistema, feitos partir das tabelas das
entidades. A partir desse estudo se dá passagem para os futuros desenvolvimentos,
tendo apenas a programação em alguma linguagem especifica, talvez em Java ou C,
linguagens essas, fortemente orientadas a objetos, que dá ainda mais suporte ao seu
desenvolvimento.
Palavras-chave: software, medicina, protótipo, paciente, histórico
ABSTRACT
The study discussed how technology can help the health area, more specifically in the
emergency room, with the study of software development that supplies a database and
allows the consultation of patient information, as well as the entire sequence of your
service. Through a simple interface and quick and agile use for health professionals, it
is possible to improve the service and the health service of the population. The main
objective of the software development study is to help health professionals, thus
speeding patient care and saving time without loss of quality. The scientific method of
research was conducted through a direct interview with the health professional to seek
to understand the needs of the area and used only the pertinent information for the
study of software development. After this stage, the tables of each entity and their
respective relationships with the other tables were elaborated. For the development of
the database scripts in SQL Server and has developed the use case, activity, class
and relational database diagrams. Finally, there was the development of the screens
of the system, made from the entity of tables. From this study, we give way to future
developments, having only the programming in some specific language, perhaps in
Java or C, these languages, strongly oriented to objects that gives even more support
to its development.
Keywords: software, medicine, prototype, patient, historical
Lista de ilustrações
Quadro 1 - Exame de anamnese. ............................................................................. 10
Quadro 2 - Método Scrum de Gestão de Projeto ...................................................... 16
Quadro 3 - Framework Kanban ................................................................................. 17
Quadro 4 - Javadoc online ........................................................................................ 20
Quadro 5 - Estrutura de Levantamento de Requisitos .............................................. 23
Quadro 6 - Comparativo Modelos de Implantação SaaS e On-Premise ................... 27
Quadro 7 - Tela Cadastro Administrador ................................................................... 43
Quadro 8 - Tela login Administrador .......................................................................... 44
Quadro 9 - Tela Painel Administrativo usuário Administrador ................................... 45
Quadro 10 - Tela Geração de Relatório .................................................................... 46
Quadro 11 - Tela login Usuários nos Terminais de Acesso ...................................... 47
Quadro 12 - Tela Formulário Cadastro de Paciente .................................................. 48
Quadro 13 - Tela Usuário Enfermeiro ....................................................................... 49
Quadro 14 - Tela Usuário Médico ............................................................................. 50
Quadro 15 - Tela Monitor de Chamados ................................................................... 51
Quadro 16 - Diagrama de Caso de Uso Cadastro de Paciente ................................. 63
Quadro 17 - Diagrama de Caso de Uso Pré-Atendimento ........................................ 64
Quadro 18 - Diagrama de Caso de Uso Pré-Atendimento com Registros ................ 65
Quadro 19 - Diagrama de Caso de Uso Atendimento Médico................................... 66
Quadro 20 - Diagrama das Classes .......................................................................... 67
Quadro 21 - Diagrama de Sequência Pré-Atendimento ............................................ 68
Quadro 22 - Diagrama de Sequência Consulta Médica ............................................ 69
Quadro 23 - Diagrama de Atividade Cadastro de Paciente ....................................... 70
Quadro 24 - Diagrama de Atividade Triagem ............................................................ 71
Quadro 25 - Diagrama de Atividade Triagem ............................................................ 72
Quadro 26 - Diagrama de Entidade Relacionamento DER ....................................... 73
Quadro 27 - Modelo Físico ........................................................................................ 74
Quadro 28 - Fluxograma das Atividades ................................................................... 75
LISTA DE ABREVIATURAS E SIGLAS
C - linguagem de programação desenvolvida por Dennis Ritchier
C++ - linguagem de programação desenvolvida por Bejarne Stroustrup
CPU - (Central Processing Unit - Unidade Central de Processamento)
JAVA - linguagem de programação desenvolvida por uma equipe de programadores
chefiada por James Gosling
JVM - (Java Virtual Machine - Máquina virtual Java) necessária para executar os
programas desenvolvidos na linguagem de programação Java
WEB - (World Wide Web) - sistema hipertexto que opera através da rede mundial de
computadores
API - (Application Programming Interface – Interface de Programa Aplicativo)
JAVAONE - conferência anual sobre as tecnologias para Java realizada pela Oracle
DESKTOP - termo internacionalmente usado para se referir aos computadores de
mesa
CSS - (Cascading Style Sheets) - mecanismo para adicionar estilo (cores, fontes,
espaçamento, etc.) a um documento web
OPENCV - (Open Source Computer Vision Library) – biblioteca para processamento
de imagem
SaaS – (Software as a Service) – modelo de implantação de serviços de software em
nuvem
On-premise – modelo de implantação de serviços de software localmente
HOST - qualquer computador ou máquina conectado a uma rede
BPMN - (Businnes Process Model and Notation) - é uma notação da metodologia de
gerenciamento de processos de negócio e trata-se de uma série de ícones padrões
para o desenho de processos
SUMÁRIO
1 INTRODUÇÃO ......................................................................................................... 9
2 METODOLOGIA ..................................................................................................... 14
3 LINGUAGEM DE PROGRAMAÇÃO JAVA E O BYTECODE ................................. 18
3.1 BIBLIOTECAS DE CLASSE JAVA ...................................................................... 19
3.2 JAVAFX ............................................................................................................... 19
3.3 JAVADOC ........................................................................................................... 19
4 BANCO DE DADOS MSSQL SERVER .................................................................. 21
5 LEVANTAMENTO DE REQUISITOS ..................................................................... 23
5.1 SEGURANÇA ...................................................................................................... 24
6 PROCESSOS DE ATENDIMENTO A PACIENTE ................................................. 26
6.1 ESTRUTURA DE IMPLANTAÇÃO DO SISTEMA ............................................... 27
7 CONCLUSÃO ......................................................................................................... 28
REFERÊNCIAS ......................................................................................................... 30
9
1 INTRODUÇÃO
Coletar, identificar, filtrar, organizar, armazenar, disseminar e controlar o
histórico clínico de paciente no ambiente hospitalar de prontos-socorros que tenha a
atribuição de “atendimentos de urgência/emergência [...] assistência rápida a
pacientes que se encontram em situações de risco confirmado ou potencial
(STENZEL; PARANHOS; FERREIRA, 2012)”, não sendo uma atividade simples e
fácil. Além disso, dado ao caráter descentralizado deste ambiente e o modo obsoleto
de comunicação, que ainda é realizado por meio da ficha de atendimento em formato
de papel, pode-se conter graves erros no processo de acolhimento ao paciente.
A proposta deste trabalho é realizar o estudo, apontar as atividades
necessárias ao desenvolvimento, da estrutura ao sistema eletrônico para gerenciar os
processos de atendimento ao paciente com o auxílio da engenharia de software, criar
protótipos de tela, e demostrar os passos necessários à codificação. Ou seja, o atual
trabalho não contempla a implementação (codificação) em linguagem de programação
e suas derivadas atividades, salvo as atividades ligadas à elaboração dos scripts para
banco de dados, pois estão correlacionadas à elaboração do estudo, já que o
gerenciamento dos dados é o artefato que o estudo pretende abordar com maior
ênfase.
Aliás, devido ao caráter diverso dos dados e a falta de organização deles dentro
dos centros médicos, o estudo de desenvolvimento do sistema para gerenciar o
histórico clínico de paciente em pronto-socorro, ao qual foi dado o nome PS-System,
tem como premissa criar as seguintes características indispensáveis: primeiro, a
funcionalidade para se eliminar informação redundante; segundo, o registro correto
delas; terceiro, a velocidade em se localizar o histórico clínico; quarto, um meio seguro
e permanente de armazenamento; quinto, rápida comunicação entre os profissionais
que estão realizando o acolhimento do paciente, sexto, interfaces funcionais,
agradáveis de se utilizar e sejam de fácil entendimento.
“[...] gerenciar a informação que os profissionais de saúde precisam para desempenhar as atividades com efetividade e eficiência, facilitar a comunicação, integrar a informação e coordenar as ações entre os múltiplos membros da equipe profissional de atendimento [...]” (MARIN, 2010)
10
Em muitas ocasiões dentro dos prontos-socorros, é rotina médica chegar a uma
análise elementar sobre o quadro hospitalar de um paciente por meio de informações
provenientes de fontes impressas. Por exemplo, a leitura acerca de um exame de
hemograma. Todavia, estes mesmos quadros clínicos podem ser avaliados por meio
de apoio da informação arquivada em meio eletrônico. Sobretudo, quando se fala
sobre solução de problemas que a medicina clínica atual pontua: o diagnóstico, o
planejamento terapêutico e o prognóstico. (SABBATINI, 1993)
Para a construção deste estudo de desenvolvimento é fundamental entender
que a avaliação médica compreende levantar dados de um problema (dor) e a partir
daí indicar uma solução para ele. Tão importante é poder recuperar algum conjunto
de dados anteriores a fim de se identificar um padrão para o problema e possíveis
mudanças clínicas do paciente. Para Neto e Issy (2009, p. 355), “a avaliação médica
do paciente [...] envolve o diagnóstico correto que permita o desenvolvimento de
estratégias terapêuticas ótimas. ”
Desta forma, o primeiro passo é o estabelecimento do diagnóstico da doença.
Segundo Lewis e colaboradores (2013), na avaliação inicial o médico busca reunir
dados para identificar o risco de doença e detectar uma condição médica. Uma
maneira é ele utilizar o método clínico de anamnese, onde as informações são
coletadas por meio da história médica. Nesta abordagem, os dados são classificados
como subjetivos - também chamados de sintomas. Esta forma é a descrição e
narração vivenciadas pelo paciente sobre si mesmo. O quadro 1 apresenta os pontos
determinantes para se chegar ao diagnóstico por anamnese:
Quadro 1 - Exame de anamnese.
Fonte: (Lewis e colaboradores, 2013, p. 38)
Não obstante, outra técnica que auxilia a elaboração do quadro clínico para se
atingir o diagnóstico é o chamado exame físico. Ele é classificado como dado objetivo,
pois compreende a inspeção, palpação, percussão e ausculta (sons produzidos pelo
11
corpo). No decorrer do atendimento, o médico especula o paciente, ou seja, analisa a
fisionomia, a feição, o físico, o jeito, etc. Desta forma, tem-se a descrição um pouco
mais detalhada sobre a condição dele. Para ver o quadro sobre como é realizado o
roteiro do exame físico, conforme anexo A.
O diagnóstico por imagem compreende um vasto espectro e quando
empregado corretamente pode ser muito útil ao médico. Além disso, o propósito do
estudo é abordar a parte técnica do desenvolvimento, contudo, não deixar de
apresentar benefícios que exames como este podem ajudar a “determinar ou excluir
doença em um indivíduo sintomático (NICOLL, 2013)”. E dentro de um sistema
eletrônico em que a recuperação para análise permite flexibilidade, os benefícios são
desde a identificação de riscos inicias para prevenção de ocorrências de uma doença,
até a detecção precoce de uma doença oculta.
Dentro deste repertório ainda encerra o exame laboratorial. Aquele que é
realizado para:
“Os exames na medicina laboratorial podem ser direcionados para (1) confirmar uma suspeita clínica (que poderia incluir fazer o diagnóstico), (2) excluir um diagnóstico, (3) auxiliar na seleção, otimização e monitoramento do tratamento, (4) fornecer um prognóstico ou (5) fazer a triagem para doença na ausência de sinais ou sintomas clínicos. O exame também é usado para estabelecer e monitorar a gravidade de um distúrbio fisiológico. ” (Burtis e colaboradores, 2011, p. 30)
Desse modo, Santos (2012, p. 66) revela a prática de padronizar os exames
laboratoriais rotineiros utilizados pelos profissionais médicos. Dessa maneira, cria
uma espécie de ligação entre o exame e o laboratório que o gerou. Em virtude disso,
o registro em meio eletrônico torna possível conceber o perfil dos laboratórios e
reconhecer padrões de qualidade. No anexo B há uma descrição dos exames
realizados pelos laboratórios que permitem ao médico ter mais uma peça de apoio ao
diagnóstico.
Uma decisão baseada em dados subjetivos, objetivos, por imagem e
laboratorial assegura uma avaliação médica imparcial e contribui para esclarecer e
vislumbrar possibilidades de cura e tratamento. (Lewis e colaboradores, 2013). Não
menos importante, é registrar estes dados em um banco de dados por meio de um
software, onde o armazenamento, a organização e a recuperação são características
inerentes dos sistemas eletrônicos. É uma ferramenta importante à medida que a
prática clínica busca incorporar tecnologias da informação como forma de estratégia
12
na melhora da qualidade do atendimento e gestão hospitalar. (LOPES DIAS, 2008).
Por isso, a quantificação e qualificação de tais dados, ao serem sistematizadas por
estratégias de tecnologia da informação, vislumbram o surgimento de ferramentas de
grande utilidade para o setor hospitalar.
Para Figueiredo e colaboradores (2007), o sistema atual de histórico clínico,
mantém os dados em papel sulfite organizado em fichários que são armazenados em
armários de ferro de forma casual. Com o tempo a legibilidade dos papeis é afetada
devido ao acumulo de ferrugem e os dados vão sumindo. Podendo até mesmo apagar-
se por completo. Além disso, a manipulação dos fichários é caótica; e qualquer tipo
de consulta leva a uma busca demorada.
Aliás, devido ao caráter diverso dos dados e a falta de organização deles dentro
dos centros médicos, o estudo visa dar ao software histórico clínico de paciente a
condição para ele eliminar a redundância de informação e permitir o registro correto
delas. Além disso, pretende dar agilidade na localização do histórico clínico de
pacientes e um meio seguro e permanente de armazenamento.
A dedicação para o estudo de desenvolvimento do sistema, não é só introduzir
os aspectos descritos, mas também expandir-se para apoiar o diagnóstico,
prognóstico e o planejamento terapêutico. Neste contexto, por meio da estruturação
dos dados por estratégias de tecnologia da informação, abre-se o caminho para o
médico chegar a uma solução terapêutica eficiente e eficaz por meio da informação
recuperada através da interface do software, quando da consulta em pronto-socorro.
(FIGUEIREDO, 2007)
Outro elemento a ser ponderado é o relativo à comunicação. Para Marin (2010,
p. 22) “Estima-se que os médicos usam cerca de 38% e os enfermeiros 50% do seu
tempo escrevendo. ” De fato, o estudo quer apontar a relevância do PS-System na
transmissão de dados entre os profissionais, porque é inerente o caráter de agilidade
na obtenção da informação. Já que cada profissional tem acesso ao terminal gráfico
interligado ao servidor, assim, qualquer alteração realizada no histórico do paciente
por outro terminal vai ser percebida em tempo real pelos demais.
Em virtude de o profissional atendente realizar a primeira coleta de dados,
contudo, são dados estáticos que buscam identificar quem é o paciente e a sua região
de moradia. O sistema permite a inserção deles e não a sua exclusão. A seguir, o
13
enfermeiro é o responsável pela coleta de dados dinâmicos que são uma espécie de
espelho, onde irá refletir para o médico o grau de risco do paciente. Assim, o estudo
de desenvolvimento do sistema precisa considerar que a lógica é criar acesso restrito
de inclusão, ponderando o nível de cada dado. Algo que o histórico clínico de paciente
atual em formato de papel não permite separar.
Ou seja, o estudo leva em consideração que os dados têm um caráter
heterogêneo, isto é, que sua descrição é uma forma útil que dá ao profissional médico,
ao enfermeiro e ao atendente uma percepção sobre cada parte a ser considerada no
momento do acolhimento. Isto é, para qual conjunto de informação cada dado faz
parte. Desta forma, este estudo pretende ponderar sobre a pertinência do registro de
alguns dados que relatórios e pesquisas dizem produzir melhor resultado. Mas não
vai investigar como uma eventual leitura deles pelo médico pode persuadi-lo a
formular um diagnóstico. Tal estudo e análise ficam para uma conjectura futura em
uma linha diferente da atual.
Portanto, o objetivo do estudo corrente é descrever tecnicamente o
desenvolvimento de um sistema eletrônico para gerenciar o histórico clínico de
paciente atendido em pronto-socorro, que acessa uma base de dados estruturada e
coerente, e assim, apontar a relevância que dados objetivos, subjetivos, por imagem
e laboratorial ora registrados em meio eletrônico e de fácil recuperação, podem dar
apoio aos profissionais de saúde no momento do acolhimento do paciente em pronto-
socorro.
14
2 METODOLOGIA
Inicialmente, foi utilizado o método de entrevista quantitativa de forma informal,
para observar os processos interpostos na atividade desenvolvida da área de prontos-
socorros, ainda para reunir os principais tópicos e identificar possíveis pontos em que
é necessário dedicar maior atenção.
“A entrevista é considerada uma modalidade de interação entre duas ou mais pessoas. Trata-se de uma conversação dirigida a um propósito definido que não é a satisfação da conversação em si, pois esta última é mantida pelo próprio prazer de estabelecer contato sem ter o objetivo final de trocar informações, ou seja, diminuir as incertezas acerca do que o interlocutor. ” (FRASER, 2004)
Após, foram utilizados técnicas de engenharia de software tal como o
levantamento de requisitos, onde se identifica os principais aspectos que o sistema
terá em sua execução, estudo de caso, onde se identificou a viabilidade da construção
deste estudo a partir de modelos que o mercado oferece como o Prontuário Eletrônico
do Paciente do Sistema Único de Saúde, que deveria ser utilizado em todas as
unidades de saúde pública, porém ainda é pouco difundido e utilizado, e o sistema
privados de prontuários eletrônicos, como é o caso do ClinicWeb, que é um sistema
para clinicas e consultórios particulares, ambos com o mesmo propósito, que é o
gerenciamento dos processos em centros de saúde.
Foram feitas as construções de diagramas, para se ter uma visão das
atividades do sistema de forma a melhorar o entendimento de seus processos e a
elaboração de scripts para um banco de dados relacional, num esforço para delinear
e aprimorar o caminho do estudo.
“Um processo de software (ou metodologia de desenvolvimento de software) é um conjunto de atividades e resultados associados que auxiliam na produção de software. Dentre as várias atividades associadas, existem por exemplo a análise de requisitos e a codificação. O resultado do processo é um produto que reflete a forma como o processo foi conduzido. “ (DOS SANTOS SOARES, 2004)
Há duas formas de metodologias de desenvolvimento de software que são
empregadas até os dias de hoje, a metodologia tradicional ou clássica e a metodologia
ágil ou manifesto ágil, ambas metodologias devem ser empregadas de acordo com a
15
necessidade de cada projeto, obedecendo também aos resultados a serem
alcançados e os custos para se chegar ao resultado final.
As metodologias clássicas foram dominantes até o final do século 90, pois eram
as únicas a serem utilizadas nos desenvolvimentos de softwares, porém pode-se
utilizar até os dias de hoje, desde que os requisitos do sistema sejam estáveis e os
requisitos futuros sejam previsíveis, mas ainda assim o processo será engessado e
haverá barreiras para o desenvolvimento do software, como a pesada documentação
exigida nesta metodologia.
As metodologias clássicas são divididas entre Modelo Cascata, onde deve ser
usado apenas em projetos onde os requisitos estão bem definidos e estáveis.
Modelos Espirais e de prototipagem trabalham com um método incremental
mais rápido que o convencional, e pode ser adotado em todos os níveis da engenharia
de software, desde o desenvolvimento de conceitos até a manutenção do sistema no
longo prazo.
Como exemplos de modelos ágeis temos o Feature Driven Development, que
significa desenvolvimento guiado por funcionalidades, que é divido em cinco processo,
desenvolver um modelo abrangente, construir uma lista de funcionalidades, planejar
por funcionalidades, detalhar por funcionalidades e construir por funcionalidades. Este
método começa com a visão global do negócio, já que esse método considera a soma
de tudo mais importante do que cada uma das partes separadamente. Passa-se,
então, para o detalhamento do produto com a subdivisão por áreas a serem
modeladas, culminando na descrição de cada funcionalidade.
O modelo ágil eXtreme Programming, que significa programação extrema, é
uma metodologia de desenvolvimento ágil que adota a estratégia de constante
acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento
de software, utilizado na construção de softwares com requisitos vagos e em
constante mudança.
O modelo ágil Scrum, é um modelo de desenvolvimento voltado para o
gerenciamento de projetos e totalmente adaptativo a outros modelos, tem como base
o desenvolvimento iterativo e incremental, feitos em fases e sempre acompanhado de
melhorias constantes.
16
Destacamos ainda a utilização de metodologia de desenvolvimento ágil para o
desenvolvimento do projeto, que Silva explica sobre essas metodologias.
“Estas metodologias incluem quatro valores principais: interações e indivíduos são mais importantes que processos e ferramentas; o software funcionando é mais relevante que a documentação compreensiva; o cliente deve estar sempre presente durante o projeto e a metodologia deve prover agilidade na resposta a mudanças. “ (Silva,2009)
Foi escolhido como modelo ágil de desenvolvimento o método Scrum, que é o
framework de gestão para acompanhamento das atividades de desenvolvimento de
projetos, consiste basicamente na priorização das atividades, na estimativa de tempo
para execução das atividades, na revisão dessas atividades e inclusão no tempo
esperado para entrega do produto final, todo este processo acompanhado de reuniões
e do responsável do projeto, o staff e o time de desenvolvimento.
O método Scrum pode ser implantado em parceria com o Kanban, que é uma
ferramenta de acompanhamento de projetos, feito com papéis ou software que
disponibilize essa funcionalidade, serve para melhor visualização das etapas
concluídas, das que estão sendo executadas e das que ainda irão começar, ainda
produz uma revisão sobre todo o projeto de forma visual e revisão das etapas.
Quadro 2 - Método Scrum de Gestão de Projeto
Fonte: site http://www.mindmaster.com.br/scrum/
18
3 LINGUAGEM DE PROGRAMAÇÃO JAVA E O BYTECODE
Para a elaboração do estudo de desenvolvimento de sistema eletrônico para
armazenamento de histórico clínico do paciente foi elencado algumas tecnologias de
desenvolvimento para construção do sistema, como Java e suas bibliotecas para
construção da linhas de código, o JavaFx para construção gráfica, o Javadoc para
construção do documento de apoio a linguagem, elaborado a partir da atualidade do
mercado de desenvolvimento de software, dando margem a outras linguagens,
ficando a cargo do desenvolvedor a tecnologia que melhor se adapta.
“A linguagem Java não nasce do impulso de criar uma linguagem de programação voltada à internet, mas da inspiração de construir uma linguagem que é capaz de se adaptar a diversos dispositivos eletrônicos domésticos, tais como geladeiras, controles remotos, fornos de micro-ondas. ” (SCHILD, 2015, p. 03)
No início da década de 90, a ideia para a criação de Java vem das linguagens
de programação C e C++ onde os programadores James Gosling, Patrick Naughton,
Cris Warth, Ed Frank e Mile Sheridan, nos laboratórios da Sun Microsystems,
idealizam uma solução única para diversos tipos de CPU, apesar de cada uma possuir
um diferente controlador.
A portabilidade e a segurança de Java são possíveis devido à saída do
compilador não produzir código executável. Ou seja, o bytecode é um agrupamento
otimizado de instruções que é interpretado pela Máquina Virtual Java (JVM, Java
Virtual Machine). Por isso, Java também é extremamente compatível com programas
baseados na WEB, não obstante, para a segurança deles já que ela impede
‘execuções fora do sistema’, além de incluir alta compatibilidade com outros sistemas.
(SHILD, 2015, p. 06)
19
3.1 Bibliotecas de classe Java
Segundo Deitel (2003) Java é uma linguagem de programação em que os
programas escritos são constituídos por pedaços de código que recebem o nome de
classes. Elas são conhecidas por Java APIs (Applications Programming Interfaces -
Interface de Programas Aplicativos). Não obstante, Java admite que o programador
também crie suas próprias classes, assim como ele pode utilizar as classes nativas
da linguagem e as classes criadas por outros programadores.
Estas bibliotecas estão disponíveis como código-fonte abertos. Ou seja, é
possível ver e analisar todas as classes, além de modifica-las e utiliza-las para fins
pessoais. Contudo, se deseja utilizar as classes para fins comerciais, então é preciso
pagar por suas licenças para um pequeno número delas disponíveis hoje.
Por sinal, um grande número de bibliotecas é gratuito e um dos motivos de Java
ser uma linguagem de programação tão difundida entre os profissionais da área de
desenvolvimento. Seu ecossistema é conhecido como código aberto (open source).
3.2 JavaFx
É uma tecnologia que fornece recurso avançado para desenvolvimento de
interfaces gráficas, o qual prove grande facilidade de elaboração das telas de modo
que o usuário é capaz de interagir intuitivamente. Incumbência, que a princípio se
demostra árdua, porém, prontamente resolvida por Chris Oliver, o desenvolvedor que
apresenta a Sun Microsystems um projeto inovador.
A primeira versão é lançada em 2007 na conferência JavaOne, que é
organizada pela Oracle.
De modo resumido, é possível criar interfaces de qualidade para desktop
utilizando conceitos de CSS. Isto permite aos desenvolvedores utilizarem modelos de
programação comuns enquanto desenvolvem.
3.3 Javadoc
Um aspecto importante de analisar quando da elaboração de um estudo sobre
desenvolvimento de sistema, é reconhecer a importância que a criação de
documentação oferecida por uma linguagem de programação tem no momento de sua
construção. Desta forma, outra caraterística inerente de Java é ser capaz de
20
documentar desde o próprio código, passando por exceções e detalhes importantes
de seu uso, até a disponibilidade de ampla fundamentação online. No site da Oracle
é possível encontrar vasta documentação sobre Java.
Quadro 4 - Javadoc online
Fonte: (Disponível em: https://docs.oracle.com/javase/7/docs/api/)
21
4 BANCO DE DADOS MSSQL SERVER
O Microsoft SQL Server é um sistema gerenciador de Banco de dados
relacional (SGBD) desenvolvido pela Microsoft. Como um banco de dados, é um
produto de software cuja principal função é a de armazenar e recuperar dados
solicitados por outras aplicações de software, seja aqueles no mesmo computador ou
aqueles em execução em outro computador através de uma rede.
Para construção do banco de dados do sistema foi utilizado a linguagem SQL
Server, onde foram escritos os scripts e construído o modelo relacional do banco.
Conhecido pela abreviatura SQL Server, o Microsoft Query Language Server,
é um banco de dados relacional. Sua origem precede a década de 90. Em que é
desenvolvido para a plataforma OS2, contudo na metade desta mesma década é
lançada uma versão para a plataforma NT, porém de modo encapsulado.
Segundo Jobstraibizer (2009), a partir do ano 2000 o SQL Server ganha
popularidade e segurança, mas somente após a versão de 2008 ele é aprimorado e
obtém uma profusão de características tais como:
▪ Informações representadas de forma única, ou seja, como em uma tabela;
▪ Todo dado é acessível usando nome da tabela, valor da chave primária e nome
da coluna;
▪ Valores nulos existem para representar um campo vazio independentemente
do tipo de dado declarado.
Sua arquitetura é distribuída, ou seja, “[...] as informações em fase de
processamento são distribuídas para vários computadores, em vez de ficarem
confinadas a uma única máquina (VERAS apud SOMMERVILLE, 2003). ” Portanto, o
sistema pode ser executado por um conjunto de processadores interligados por rede.
Algumas características dele são:
▪ SQL-DEMO: biblioteca de ActiveX que implementa interface para
gerenciamento do SQL Server;
▪ SQL Enterprise Manager: ferramenta gráfica para administração de ambiente
de múltiplos servidores;
▪ Serviços SQL Server Agent e MS SQL Server: o serviço SQL Server Agent
permite agendar backups e definir alguma mensagem de aviso quando da
ocorrência de erro. Já o serviço MS SQL Server roda em background no
22
sistema operacional. É ele que permite inserir, atualizar e consultar dados
armazenados no banco de dados.
Portanto, a revolução dos processos industriais e as mudanças impostas até
na cultura de uma sociedade fazem da informação um bem valioso. Portanto, uma
forma segura, acessível e organizada de guardar estes dados é fundamental.
23
5 LEVANTAMENTO DE REQUISITOS
Para Wazlawick (2011, p. 21) “O levantamento e análise de requisitos
compõem uma parte significativa da fase de concepção [...] e, para cada fonte,
identificar quais as funções necessárias que o sistema deverá disponibilizar. ”
Em resumo, de um lado há a fase de levantamento de requisitos que traz dado
acerca das funcionalidades do sistema e as suas restrições. De outro lado, há a fase
de análise dos requisitos que permite detalhar e estruturar estes dados.
Todavia, são os requisitos funcionais, que compõem o conjunto de funções a
qual o sistema vai realizar; ele é o responsável por reunir todas as informações de
entrada e de saída.
Portanto, no primeiro estágio é necessário defini-los. E para tanto, nós vamos utilizar, segundo Wazlawick (2011), a estrutura do quadro 2 que segue.
Quadro 5 - Estrutura de Levantamento de Requisitos
Fonte: (Adaptado de Wazlawick, 2011, p. 28)
Já os requisitos não funcionais, segundo Vazquez e Simões (2016, p. 105), são
aqueles que apontam para aspectos gerais do software. Além do mais, eles formam,
junto aos requisitos funcionais, um conjunto de funcionalidades que determina como
o sistema vai realizar as instruções, as quais o usuário aciona.
Devido ao fato da frequente ocorrência de semelhantes requisitos não
funcionais em um projeto de software, é comum não mudar muito quando a empresa
realiza diferentes trabalhos.
Em virtude disso, com o firme propósito de concretizar uma estrutura comum,
são identificados padrões que se tornam regras para produção solida e coesa de
software. Nos anexos C e D são descritos dois padrões mais utilizados hoje em dia.
Sendo que o padrão do anexo D é nossa escolha, porque compreende um melhor
conjunto estruturado, ajustando-se ao propósito do nosso projeto.
24
Os requisitos funcionais e não funcionas foram elaborados com as perspectivas
e processos levantados conforme apêndice C e D. Dando assim as principais
conotações sobre as funcionalidades do sistema e a que o sistema se propõe em seus
requisitos não funcionais.
5.1 Segurança
Para adicionar o elemento de segurança da informação no estudo é preciso
considerar as propriedades de confidencialidade, integridade, disponibilidade e
autenticidade.
“Confidencialidade [...] informação só pode ser acessada por quem detém um determinado nível de privilégio ou autorização. Integridade [...] informação só pode ser modificada por quem tem a devida autorização para fazê-lo [...]. Disponibilidade [...] informação que deve estar disponível sempre que uma parte autorizada necessitar consulta-la. Autenticidade visa a garantir que as partes envolvidas sejam realmente quem elas dizem ser [...]. (ROCHOL; CARISSIMI; GRANVILLE, 2009) ”
Logo, a técnica mais utilizada que proporciona as propriedades de
confidencialidade, integridade e autenticidade para a segurança da informação é a
criptografia. Contudo, ela não é infalível. Toda criptografia pode ser quebrada, seja
por analise de frequência, seja por diversas outras formas.
A criptografia é antiga e para alguns historiadores há indícios do uso dela no
sistema de escrita hieroglífica dos egípcios. É desta época o primeiro exemplo
documentado do uso da criptografia. Em 1900 a.C, quando o escriba de Khnumhotep
II tem a ideia de substituir algumas palavras ou trechos de texto. Se o documento é
roubado, o ladrão não consegue encontrar o caminho até o tesouro. Assim, ele morre
de fome perdido nas catacumbas da pirâmide. No entanto, também há evidências do
usa dela nas comunicações de Júlio Cesar (50 a.C).
Basicamente os principais tipos de cifras que são utilizados é a de transposição,
a qual realiza a mistura dos caracteres originais. E as cifras de substituição, a qual é
a troca ou substituição de um caractere ou caracteres da informação com base em
uma tabela. Com o advento dos computadores as cifras passam a ser processadas
ou por blocos, ou por fluxo.
25
A propriedade de disponibilidade é fornecida por meio da segurança dos
recursos que mantém as informações tais quais cópias de segurança (backup),
servidores e rotas redundantes, firewall, proxies, etc.
26
6 PROCESSOS DE ATENDIMENTO A PACIENTE
Para Ferreira (2015) “processos de negócio são sistemas com clientes”.
Considerando este aspecto, é possível admitir os clientes como sendo os pacientes
e, os fornecedores, como sendo as instituições hospitalares e todos seus
colaboradores tais como médicos, enfermeiros, atendentes, etc. Desta forma, traçar
uma linha de comparação entre o universo da indústria de manufatura e o universo da
indústria hospitalar, é trivial já que a demanda de pessoas buscando saúde é suprida
por profissionais especialistas numa simbiose entre duas forças de trabalho muito
idênticas. De um lado há uma indústria voltada para suprir o consumo de bens
tangíveis e do outro lado há uma indústria voltada para suprir, em sua essência, o
consumo de bens intangíveis, de serviços à saúde.
Falando um pouco mais sobre a importância de se delinear o processo. “Um
processo é um grupo de atividades realizadas numa sequência lógica com o objetivo
de produzir um bem ou um serviço que tem valor para um grupo específico de clientes
(NOGUEIRA apud HAMMER E CHAMPY, 2017)", ou seja, é uma sucessão de
estágios que tem fim e objetiva montar um conjunto de atividades em que há uma
entrada, não obstante, há uma transformação dessa entrada em uma saída.
Ainda que voltado para a área médica e, com a finalidade de dispor em padrão
atual as atividades inerentes ao fluxo de atendimento dentro do pronto-socorro, é
adotada a notação da OMG (Object Management Group) que é a criadora do padrão
de modelagem e notação de processo o BPMN (Businnes Process Model and
Notation).
Além disso, o BPMN disponibiliza em formato portável as definições do
processo. Desta forma, é possível utilizar, no início, a ferramenta de um determinado
fornecedor e à medida que o projeto avança pode-se reaproveitar o mesmo arquivo
em ferramentas de outros fornecedores já que é totalmente compatível.
Portanto, é importante desenhar as atividades já que uma das vantagens de se
empregar esta tecnologia é sua capacidade de melhorar os processos. Ou seja,
controla e coordena as atividades de maneira eficaz. Além disso, permite identificar
melhorias mais facilmente.
27
6.1 Estrutura de Implantação do Sistema
Há dois modelos estudados na implantação do sistema e na infraestrutura dos
equipamentos. O primeiro modelo é o local ou também chamado de on-premise. Ele
requer uma estrutura de software e hardware, também de certificados e mão-de-obra
mais especifica, pois, os custos desse modelo ficam todos a cargo na implantação,
porém assegura a integridade e a confidencialidade dos dados desde que instituídas
medidas de segurança. Além disso, torna-os sempre disponíveis. O segundo modelo
é o SaaS, que significa software como serviço e é definida como um serviço disponível
para execução sem muita implantação de infraestrutura, ou mesmo de mão-de-obra,
pois o software é distribuído via internet, até mesmo o acesso pode ser via internet.
O processo de troca de informação entre os hosts clientes e o host servidor é
gerado de forma continua, onde os hosts clientes, no caso atendentes, enfermeiros e
médicos vão acessar o servidor local, também chamado de on-premise.
Porém após a maturidade do sistema implantado ser atingida, outro modelo
que poderá ser estudado e implantado é o modelo Saas, onde a instituição teria parte
dos custos com infraestrutura, ou mesmo a redução dos custos, visto a virtualização
dos serviços conforme segue tabela com o comparativo.
Quadro 6 - Comparativo Modelos de Implantação SaaS e On-Premise
Fonte: (Próprio autor)
28
7 CONCLUSÃO
O principal objetivo do estudo proposto é a elaboração da engenharia de
software do sistema de histórico clínico de pacientes em prontos-socorros, elaborado
através de ferramentas e técnicas que o exige. As principais são, levantamento de
todos os requisitos através de pesquisa com profissionais da área sobre qual a
importância do modelo proposto e quais informações podem ser relevantes. Após esta
etapa, são elaborados os requisitos funcionais do software, que corresponde as suas
funcionalidades assim como os requisitos não funcionais que são os requisitos para
as funcionalidades do sistema trabalhar em tempo de execução. Em seguida, é
produzido o modelo descritivo, onde consta toda descrição das rotinas exercidas pelos
usuários, e também o modelo de relacionamento, evidenciando as principais tabelas
e dados que são colhidos pelo software. A partir disso são elaborados os scripts do
banco de dados com as normalizações pertinentes, desenhado os diagramas e as
telas do sistema, com auxílio de ferramentas próprias.
Com total relevância, o tema traz à tona a importância da elaboração de
estratégias para o desenvolvimento de projetos que vêm impactar não apenas à área
de saúde, que é um dos grandes problemas atuais, mas também nos temas que
necessitam de grande atenção como a educação, o desenvolvimento humano e
social, a igualdade, a plenitude dos idosos e tantos outros que podem ser ramificados.
A elaboração deste trabalho busca não apenas melhorar a qualidade da
prestação de serviços de saúde, mas também auxiliar na melhoria dos processos
destas instituições, não obstante, avaliar até que ponto é possível aprimorar a
qualidade de trabalho dos profissionais de saúde quanto à execução de suas tarefas
e funcionalidades.
Desta forma, o estudo levanta os principais pontos das rotinas operacionais de
um pronto-socorro e desenha o projeto para o desenvolvimento de sistema
informatizado.
A proposta inicial do trabalho foi elaborar a engenharia de software e o
desenvolvimento do sistema em código de execução, porém, com o tempo disponível
muito curto para tais tarefas, optou-se apenas pela engenharia de software,
postergando sua implementação a uma data futura.
29
Para evolução do projeto é proposto o desenvolvimento do software e a
integração com outras áreas do setor de saúde para ele tornar-se um sistema único
para todo o sistema da instituição, podendo ter diversas funcionalidades tais como o
agendamento com especialista após consulta com o médico; a reserva de
medicamentos prescritos pelo médico; o acompanhamento pelos profissionais de
saúde sobre pacientes; o acesso remoto ao sistema.
Este trabalho é muito importante para o desenvolvimento de uma linha de
pensamento, mostrando a princípio, que a área de saúde está desatualizada por falta
de capacitação e anseia por tratar os pacientes de uma maneira revolucionária,
descontruindo um hiato de atividades obsoletas, despontando como ferramenta
imprescindível no pronto atendimento clínico de pacientes.
30
REFERÊNCIAS
BAGGIO, D.L. OpenCV 3.0 Computer Vision with Java. Birmingham: Packt Publishing, 2015. Disponível em: <https://books.google.com.br/books?id=LFtICgA AQBAJ> Acesso em: 13 mai. 2017. BRASIL. Agência Nacional de Saúde Suplementar. Tempo de espera na Urgência e Emergência. Rio de Janeiro: Ministério da Saúde, 2012. p. 6. Disponível em:<http: //www.ans.gov.br/images/stories/Plano_de_saude_e_Operadoras/Areado_prestador /20130118_fichas_tecnicas.zip>. Acesso em: 21 dez. 2016. BURTIS, Carl A.; ASWOOD, Edward R.; BRUNS, David E. Tietz fundamentos de química clínica. ISBN: 8535246002, 9788535246001. São Paulo: Elsevier Brasil, 2011. p. 984. Disponível em:< https://books.google.com.br/books?id=F-WdPgAACAAJ> Acesso em: 04 out. 2016. DEITEL, H. M. Java, como programar. Porto Alegre: Bookman, 2003. DOS SANTOS SOARES, Michel. Comparação entre metodologias Ágeis e tradicionais para o desenvolvimento de software. INFOCOMP Journal of Computer Science, v. 3, n. 2, p. 8-13, 2004. FARIAS, Josivania Silva et al. Adoção de prontuário eletrônico do paciente em hospitais universitários de Brasil e Espanha: a percepção de profissionais de saúde. Revista de Administração Pública, Rio de Janeiro, v. 45, n. 5, out. 2011. p. 1303-326. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0034-76122011000500004&lng=pt&nrm=iso>. Acesso em: 20 set. 2016. FERREIRA, A.S.R. Modelagem Organizacional por Processos. Editora: Mauad, 2015. Disponível em:<https://books.google.com.br/books?id=4zPvBwAAQBAJ> Acesso em: 20 mai. 2017 FIGUEIREDO, LT et al. Prontuário Eletrônico Do Paciente — A Funcionalidade Do Registro Informatizado. Revista enfermagem, UFPE online. 2007 out./dez.; 1(2):254-61 FRASER, Márcia Tourinho Dantas; GONDIM, Sônia Maria Guedes. Da fala do outro ao texto negociado: discussões sobre a entrevista na pesquisa qualitativa. 2004. Acesso em: 20 mai. 2017 HAMMER, Michael; CHAMPY, James; KORYTOWSKI, Ivo. Reengenharia: revolucionando a empresa em função dos clientes, da concorrência e das grandes mudanças da gerência. Rio de Janeiro: Campus, 1994. Acesso em: 15 mai. 2014 JOBSTRAIBIZER, F. Guia profissional Microsoft SQL Server 2008. São Paulo: Digerati Books, 2009. Disponível em: < https://books.google.com.br/books?id=oRm ZrDph5WMC> Acesso em: 14 mai. 2017
31
LEWIS, Sharon L; DIRKSEN, Shannon Ruff; HEITKEMPER, Margaret Maclean. Tratado de enfermagem médico-cirúrgica: avaliação e assistência dos problemas clínicos. Rio de Janeiro: Elsevier, 2013. p.1802. Tradução: Maysa Ritmony Ide. Disponível em:< https://books.google.com.br/books?id=6cEEAQAAQ BAJ> Acesso em: 08 out. 2016. LOPES, Juliana Dias. A utilização do prontuário eletrônico do paciente pelos hospitais de belo horizonte. Revista, Textos de la CiberSociedad, 16. Monográfico: Internet, sistemas interativos e saúde. 2008. Disponível em:<http://www.cibersocied ad.net> MARIN, Heimar de Fátima. Sistemas de informação em saúde: considerações gerais. Health information system: general considerations. 2010. NETO, Onofre Alves; ISSY, Adriana Machado. Dor: princípios e práticas. Porto Alegre: Artmed, 2009. Disponível em:< https://books.google.com.br/books?id= QgCJ_f_-htkC> Acesso em: 09 nov. 2016. NICOLL, D. et al. Manual de Exames Diagnósticos - 6ed. São Paulo: AMGH, 2013. Disponível em: <https://books.google.com.br/books?id=Kxk7AgAAQBAJ> Acesso em: 07 mai. 2017. ROCHOL, J. CARISSIMI, A. S. GRANVILLE, L.Z. Redes de Computadores: Volume 20 da Série Livros didáticos informática UFRGS. Porto Alegre: Bookman, 2009. Disponível em: < https://books.google.com.br/books?id=kjy99_UHK5EC> Acesso em: 15 mai. 2014 SABBATINI, Renato M.E. Uso do Computador no Apoio ao Diagnóstico Médico. Revista Informédica, Núcleo de Informática Biomédica da Universidade Estadual de Campinas. 05 de nov. 1993. Disponível em:<http://www.informaticamedica. org.br/informed/decisao.htm> Acesso em: 25 nov. 2016 SANTOS, José Sebastião dos. Protocolos clínicos e de regulação: acesso à rede de saúde. Rio de janeiro: Elsevier, 2012. Disponível em: < https://books.google.com. br/books?id=azlQU357jTUC> Acesso em: 07 ago. 2016. SCHILDT, Herbert. Java para Iniciantes - 6ed: crie, compile e execute programas Java rapidamente. Rio de Janeiro: Bookman, 2015. 706p. Disponível em: < https://books.google.com.br/books?id=s73xBwAAQBAJ > Acesso em: 16 fev. 2017. SILVEIRA, Felipe Miralha da. Navegação georreferenciada de uma base de dados de árvores genealógicas. 2013. SILVA, F. G.; HOENTSCH, Sandra CP; SILVA, Leila. Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS. BR. Scientia Plena, v. 5, n. 12, 2009. SOMMERVILLE, I. Engenharia de software. 6. ed. Tradução Maurício de Andrade. São Paulo: Addison Wesley, 2003. Acesso em: 15 mai. 2014
32
STENZEL, Gabriela Quadros de Lima; PARANHOS, Mariana Esteves; FERREIRA, Vinícius Renato Thomé. A psicologia no cenário hospitalar: encontros possíveis. Porto Alegre: Edipucrs, 2012. 348 p. Disponível em:< https://books.google.com. br/books?id=xNs--TubIAQC> Acesso em: 26 mar. 2017 VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de Requisitos: software orientado ao negócio. Rio de Janeiro: Brasport, 2016. Disponível em: < https://books.google.com.br/books?id=gA7kDAAAQBAJ > Acesso em: 19 fev. 2017 VERAS, Manoel. Arquitetura de sistemas distribuídos. 2015. Disponível em: < http://manoelveras.com.br/blog/?p=195> Acesso em: 14 mai. 2017 WAZLAWICK, Raul. Análise e Projeto de Sistemas de Informação Orientados. Rio de Janeiro: Elsevier, 2011. 352p. Disponível em: < https://books.google.com.br/books?id=Cf6t E2 zISf0C > Acesso em: 25 fev. 2017
33
ANEXO
ANEXO A – ROTEIRO DO EXAME FÍSICO POR SISTEMAS
ANEXO B - ROTEIRO EXAME ANAMNESE
ANEXO C - DESCRIÇÃO DOS EXAMES
ANEXO D - NORMA PARA ELABORAÇÃO REQUISITOS NÃO FUNCIONAIS
ANEXO E - NORMA ISO/IEC 25010
34
ANEXO A – ROTEIRO DO EXAME FÍSICO POR SISTEMAS
SISTEMA COMPONENTES FUNÇÕES
TEGUMENTO COMUM
Pele;
Estrutura associada;
Pelos;
Unhas;
Glândulas;
Sudoríferas;
Sebáceas
Regula temperatura corporal;
Protege o corpo;
Elimina alguns resíduos;
Ajuda produzir vitamina D;
Detecta sensações;
ESQUELÉTICO
Ossos;
Articulação do corpo;
Cartilagens associadas
Sustenta e protege o corpo;
Fixação muscular;
Auxilia movimentação;
Armazena células que produzem
células sanguíneas;
Armazenam minerais e lipídios
MUSCULAR Tecido muscular esquelético;
Fixados a ossos
Participa produção de movimento
como caminhada e postura;
Produz calor
NERVOSO
Encéfalo;
Medula espinhal;
Nervos;
Órgãos
Regula atividades corporais;
Detecta mudanças;
Interpreta e responde;
Secreções glandulares
ENDÓCRINO Glândula e tecido;
Produz substâncias químicas; Regula atividades do corpo
CIRCULATÓRIO
Sangue;
Coração;
Vaso sanguíneo
Coração bombeia sangue por meio
dos vasos sanguíneos
LINFÁTICO E IMUNIDADE
Líquido linfático;
Vasos linfáticos;
Baço;
Timo;
Linfonodos;
Tonsilas;
Células T e B
Retorna proteína;
Transporta lipídeos;
Trato gastrintestinal;
Proliferação de células;
Protege contra micróbios patogênicos
RESPIRATÓRIO
Pulmão;
Via respiratória;
Faringe;
Laringe;
Traqueia;
Brônquios;
Bronquíolos;
Transfere o ar inalado para o sangue;
Regula acidez líquidos corporais;
DIGESTÓRIO
Órgão do trato intestinal;
Auxílio sistema digestivo;
Glândulas salivares;
Fígado;
Vesícula biliar e pâncreas;
Realiza a decomposição física e
química dos alimentos;
Absorve nutrientes;
Elimina resíduos sólidos
URINÁRIO
Rins;
Ureteres;
Bexiga urinária;
Uretra
Produz, armazena e elimina urina;
Elimina resíduos;
Regula volume e composição sangue;
Mantem equilíbrio corporal;
GENITAL
Gônadas;
Órgãos associados;
Tubas uterinas;
Útero e vagina;
Etc
Produção gameta;
Reprodução;
Glândulas mamárias;
etc
35
ANEXO B - ROTEIRO EXAME ANAMNESE
REGISTRO MARCADORES TIPO EXAME
ESTADO GERAL
1. Aparência corporal; 2. Estado de consciência e excitação; 3. Discurso/fala; 4. Movimento corpo e modo andar; 5. Estado nutricional; 6. Estatura.
Inspeção Palpação
Percussão Ausculta
SINAIS VITAIS
7. Pressão arterial (os dois braços para comparar); 8. Pulso (apical/radial); 9. Respiração; 10. Temperatura; 11. Registro da altura e peso (IMC).
Inspeção Palpação
Percussão Ausculta
TEGUMENTAR -PALPAR PELE
12. Cor; 13. Fissura, laceração, lesão; 14. Cicatriz, tatuagem, piercing; 15. Hematoma, erupção; 16. Edema; 17. Hidratação; 18. Textura; 19. Turgor (inchaço do corpo ou de um de seus órgãos); 20. Vascularização.
Inspeção Palpação
Percussão Ausculta
CABEÇA E PESCOÇO
21. Crânio; 22. Pescoço; 23. Olhos; 24. Nariz; 25. Boca; 26. Orelha.
Inspeção Palpação
Percussão Ausculta
EXTREMIDADES
27. Braços; 28. Dedos; 29. Punhos; 30. Cotovelos; 31. Ombro.
Inspeção Palpação
Percussão Ausculta
TÓRAX POSTERIOR 32. Desenvolvimento muscular; 33. Movimento respiratório; 34. Diâmetro anteroposterior.
Inspeção Palpação
Percussão Ausculta
TÓRAX ANTERIOR 35. Mamas; 36. etc.
Inspeção Palpação
Percussão Ausculta
ABDOME
37. Cicatriz; 38. Simetria; 39. Peristaltismo; 40. Sopro
Inspeção Palpação
Percussão Ausculta
CONCLUSÃO DO EXAME DAS EXTREMIDADES
41. Amplitude do movimento dos quadris; 42. Creptação; 43. Etc.
Inspeção Palpação
Percussão Ausculta
NEUROLÓGICO 44. Marcha; 45. Hálux ao andar; 46. Calcanhar ao andar
Inspeção Palpação
Percussão Ausculta
GENITAIS 47. Genitália masculina; 48. Genitália Feminina.
Inspeção Palpação
Percussão Ausculta
36
ANEXO C - DESCRIÇÃO DOS EXAMES
BIOQUIMICO LABORATÓRIO UROANÁLISE LABORATÓRIO
Ácido úrico (Sangue) B01 Urina rotina U01
Ácido úrico (Urina) B02 Espermograma U02
Alfa 1- glicoproteína ácida
(mucoproteína) B03 Microalbumina na urina U03
Amilase B04
Pesquisa de
espermatozoide (após
vasectomia)
U04
Bilirrubina total e frações B05
Cálcio ionizável B06
Cálcio urinário B07
Capacidade latente de lig.
De ferro (CTLF/TIBC +
ferro)
B08
Clearence de creatinina B09
Cloro B10
Colesterol total B11
Creatinina B12
Creatinofosfoquinase (CK
ou CPK) B13
Desidrogenase lática B14
Eletroforese de proteína B15
Ferritina B16
Fosfatase alcalina (ALP) B17
Fósforo B18
Gama GT B19
Glicemia de jejum B20
Glicemia pós-prandial
(GPP) B21
37
GTT – curva glicêmica 75g
(2 dosagens) B22
GTT – curva glicêmica 75g
(3 dosagens) B23
HDL colesterol B24
Cultura (secreção ocular) B25
Cultura (outras secreções) B26
HORMÔNIO LABORATÓRIO HEMATOLOGIA LABORATÓRIO
FSH H01 Contagem de reticulócitos HE01
Insulina H02 Eritograma HE02
LH H03 Hemograma completo HE03
Progesterona H04 Determinação direta e
reversa do grupo ABO HE04
Prolactina H05
Eletroforese de
hemoglobina – teste de
falsificação
HE05
Testosterona H06 Retração do coágulo (RC) HE06
Tiroxina (T4 total) (quando
TSH alterado) H07 Coombs indireto – TIA HE07
T3 (quando TSH alterado) H08 Tempo de coagulação HE08
T4 livre (quando TSH
alterado) H09
Tempo e atividade
protrombina (TAP) HE09
TSH H10 Tempo de sangramento
(TS) HE10
Tempo de tromboplastina
(TTPA) HE11
Fator RH inclui variante
DU HE12
Velocidade de
homossedimentação
(VHS)
HE13
38
PARASITOLOGIA LABORATÓRIO CARDIOLOGIA LABORATÓRIO
Exame parasitológico de
fezes (EPF) P01
Anticorpo
antitireoglobulina C01
Pesquisa de sangue oculto P02 Dosagem alfa-1 –
antitripsina C02
Fosfatase ácido total e
frações C03
Gasometria venosa C04
PNEUMOLOGIA LABORATÓRIO DERMATOLOGIA LABORATÓRIO
Gasometria arterial P01 Exame micológico a fresco
(direto) D01
Dosagem alfa-1-
antitripsina P02
Cultura para identificação
de fungos D02
ENDOCRINOLOGIA LABORATÓRIO GASTROENTEROLOGIA LABORATÓRIO
17 – ALFA –
HIFROXIPROGESTERON
A
E01 Antimitocôndria G01
Anticorpo antitireoglobulina E02 Antimusculo liso G02
Androstenediona E03 Dosagem alfa-1
antitripsina G03
Corticol E04
Estradiol E05
GH E06
IGF 1 (somatomedina C) E07
LH E08
Paratormônio (PTH) E09
SDHEA (Sulfato de
hidroepiandrosterona) E10
T3 E11
Teste de intolerância a
insulina E12
Tireoglobulina E13
39
NEFROLOGIA LABORATÓRIO SAÚDE DO
TRABALHADOR LABORATÓRIO
Anti-HBE – pesquisa de
anticorpos contra antígeno
E do vírus da hepatite E
N01 Feno S01
aAnti HBC – Igm – contra
antígeno central do vírus
da hepatite B
N02 Ácido hipúrico S02
Atividade plasmática
renina N03 Àcido metil-hipúrico S03
Ácido úrico – 2 amostras N04 Mercúrio S04
Ceruloplasmina N05 Meta-homoglobina S05
Cobre urinário N06 Zinco S06
Cobre sérico N07
Complemento C3 N08
Complemento C4 N09
Cálcio N10
Calciúria (2 amostras) N11
CAPD mensal N12
CAPD trimestral N13
Dosagem alfa- 1 –
antitripsina N14
Dosagem de aldosterona N15
Dosagem de citrato – 2
amostras N16
Dosagem de alumínio N17
Dosagem de alumínio pós-
fesferal N18
Dosagem de ciclosporina N19
Exames qualitativos de
cálculos urinários N20
Hemo mensal N21
40
Hemo trimestral N22
Ferro sérico N23
Fosfatase ácido total
frações N24
ANEXO D - NORMA PARA ELABORAÇÃO REQUISITOS NÃO FUNCIONAIS
Functionaty
(Funcionalidade)
Enfoca os requisitos
funcionais
Functionaty (Funcionalidade) Enfoca os requisitos funcionais
Usability
(Usabilidade)
Trata da facilidade de uso do software e incluí fatores humanos,
estética, consistência na interface do usuário, ajuda online e contextual,
assistentes, documentação e matérias de treinamento.
Reliability
(Confiabilidade)
Trata de integridade, conformidade e interoperabilidade do software.
Incluí aspectos de frequência e gravidade de falhas, previsibilidade,
exatidão e tempo médio entre falhas.
Performance
(Desempenho)
Trata de velocidade, eficiência, taxa de transferência, tempo de resposta
e uso de recurso.
Supportability
(Suportabilidade)
Trata da extensibilidade, adaptabilidade, manutenibilidade,
compatibilidade, configurabilidade, escalabilidade, instabilidade,
localizabilidade (ex.: internacionalização) e testabilidade.
+
Restrições de
designer
(projeto)
Restrições de designer (projeto) Restringe algo sobre o projeto da
arquitetura de software.
Restrições de
implementação
Restrições de implementação restringem algo sobre a construção do
projeto.
Restrição de
interface
Restrição de interface Restrições de formatos, tempos ou outros fatores
usado por tal interação.
Restrições
físicas
Restrições físicas Limitações quanto ao hardware que dever ser
suportado.
41
ANEXO E - NORMA ISO/IEC 25010
Adequação
funcional
Grau no qual um produto fornece funcionalidades que atendem às
necessidades específicas e implícitas quando utilizado em determinadas
condições.
Eficiência no desempenho
Desempenho relativo à quantidade de recursos usados em determinadas
condições.
Compatibilidade
Grau no qual um produto, sistema ou equipamento pode trocar informações
com outros produtos, sistemas ou componentes; e também, ou
alternativamente, executar as funções necessárias enquanto compartilha o
mesmo ambiente de hardware e software.
Usabilidade
Grau no qual um produto ou sistema pode ser usado por determinados
usuários para alcançar determinados objetivos de maneira efetiva, eficiente e
satisfatória em determinado contexto.
Confiabilidade Grau no qual um sistema, produto ou componente executa determinadas
funções em determinadas condições por um determinado período de tempo.
Capacidade de manutenção
Grau de efetividade e eficiência com o qual um produto ou sistema pode ser
modificado por aqueles com essa intenção.
Segurança
Grau no qual um produto ou sistema protege informações e dados de tal
forma que as pessoas ou sistemas tenham o grau de acesso apropriado a
seus perfis e níveis de autorização.
Portabilidade
Grau de efetividade e eficiência com o qual um sistema, produto ou
componente pode ser transferido de um equipamento, software ou de um
ambiente operacional para outro.
42
APÊNDICE
APÊNDICE A - TELAS DO SISTEMA
APÊNDICE B – REQUISITOS FUNCIONAIS
APÊNDICE C – REQUISITOS NÃO FUNCIONAIS
APÊNDICE D – DIAGRAMAS DE CASO DE USO
APÊNDICE E – DIAGRAMA DE CASO DE CLASSE
APÊNDICE F – DIAGRAMAS DE SEQUENCIA
APÊNDICE G – DIAGRAMAS DE ATIVIDADE
APÊNDICE H – DIAGRAMA DE ENTIDADE RELACIONAMENTO DER
APÊNDICE I – MODELO FÍSICO
APÊNDICE J – FLUXOGRAMA DAS ATIVIDADES
43
APÊNDICE A - TELAS DO SISTEMA
Quadro 7 - Tela Cadastro Administrador
Fonte: (Próprio autor)
Cadastro do Administrador ou Cliente, por padrão o sistema gera uma senha e
login de administrador, que após podem ser alterados, o módulo cliente instala as
funcionalidades do sistema nos terminais, onde após sua instalação o Administrador
pode cadastrar login e senha para este cliente.
44
Quadro 8 - Tela login Administrador
Fonte: (Próprio autor)
Tela de login do Administrador, exibindo os campos de login e senha.
45
Quadro 9 - Tela Painel Administrativo usuário Administrador
Fonte: (Próprio autor)
Na tela do Administrador, temos o painel administrativo, na aba Cadastrar
Perfil, onde se pode cadastrar um novo usuário como Médico, Enfermeiro ou
Atendente, preenchendo todos os campos de cada formulário, na aba Configurar
Módulo, onde se pode instalar as funcionalidades do terminal ou de servidor de banco,
e temos a aba Senha Administrador, onde o Administrador pode alterar sua senha.
46
Quadro 10 - Tela Geração de Relatório
Fonte: (Próprio autor)
No menu Relatório, há a opção de Gerar Relatório, onde se dão as opções de
geração de relatório por nome ou por CPF.
47
Quadro 11 - Tela login Usuários nos Terminais de Acesso
Fonte: (Próprio autor)
A tela de login do sistema é aberta quando se abre o menu Arquivo, Logar, na
tela que é aberta pode-se logar com os usuários cadastrados como Atendente, Médico
ou Enfermeiro, imputando as informações de login e senha cadastrados.
48
Quadro 12 - Tela Formulário Cadastro de Paciente
Fonte: (Próprio autor)
A tela acima mostra a tela do Atendente quanto ao cadastro de um paciente,
onde mostra todo o formulário para ser preenchido, incluindo a foto do mesmo.
49
Quadro 13 - Tela Usuário Enfermeiro
Fonte: (Próprio autor)
A tela de trabalho do usuário Enfermeiro, composta pelas abas Salas, que
indica onde o paciente se localiza, a aba de Classificação de grau de risco, onde é
informado se o paciente precisa de atendimento imediato, a aba Histórico clinico, onde
o enfermeiro pode observar os últimos atendimentos do mesmo.
50
Quadro 14 - Tela Usuário Médico
Fonte: (Próprio autor)
A tela administrativa do usuário Médico, onde há as mesmas funcionalidades
do Enfermeiro, porém este usuário é quem faz o preenchimento dos campos quanto
a consulta, exames, diagnóstico e prescrição, para que estas informações estejam
diretamente no banco de dados do histórico clínico do paciente.
51
Quadro 15 - Tela Monitor de Chamados
Fonte: (Próprio autor)
Tanto as telas dos usuários Enfermeiro e Médico tem uma tela de chamada dos
pacientes, que podem ser visualizadas previamente para chamada, dessa chamada
é gerada diretamente na sala de espera, onde o paciente pode visualizar seu número
e as senhas que já foram chamadas anteriormente.
52
APÊNDICE B – REQUISITOS FUNCIONAIS
Notificação de não instalação do Módulo Administrador
[RF01] O sistema precisa executar uma rotina de notificação de modo que ao
examinar a não existência da instalação do módulo administrador, exiba uma
mensagem;
Ator: sistema;
Informação de entrada: rastreamento da instalação do módulo administrador;
Informação de saída: mensagem de aviso;
Restrições lógicas: o sistema não deve permitir um tempo longo de rastreamento da
instalação do módulo;
Restrições tecnológicas: não há.
Criação de apenas um Administrador
[RF02] O sistema só pode permitir a criação de um usuário do tipo administrador;
Descrição: o sistema dever permitir somente a criação de um usuário do tipo
administrador;
Ator: sistema;
Informações de entrada: inserção de nome, senha e foto pelo administrador;
Informações de saída: o sistema constrói um gerenciador de perfil que permite ao
usuário do tipo administrador criar e excluir os perfis das categorias médico,
enfermeiro e atendente;
Restrições lógicas: não têm campos nulos no cadastro do usuário do tipo
administrador;
Restrições tecnológicas: não há.
53
Associação de mesmo usuário para o mesmo perfil
[RF03] O sistema não pode permitir a associação de mais que um perfil para um
mesmo usuário;
Descrição: o sistema não pode permitir a associação de mais que um perfil para um
mesmo usuário, por exemplo, um usuário do tipo médico não pode estar associado a
outros usuários do tipo enfermeiro ou atendente e vice-versa;
Ator: sistema;
Informação de entrada: não há;
Informação de saída: não há;
Restrições lógicas: não pode ter associação entre os tipos de usuários;
Restrições tecnológicas: não há.
Alterações perfil Administrador
[RF04] O sistema precisa registrar as alterações realizadas pelo administrador nos
perfis por ele administrado
Descrição: o sistema registra as inclusões, exclusões, alterações e atualizações
realizadas nos perfis dos tipos de usuários em uma espécie de arquivo de registro de
evento das ações do administrador;
Ator: sistema;
Informação de entrada: inclusão, inativação, alteração e atualização nos campos do
formulário de um tipo de usuário;
Informação de saída: uma lista ordenada para somente leitura com os dados: data,
hora, qual o campo alterado, o dado alterado, nome do administrador e IdEvento;
Restrições lógicas: arquivo de registro de eventos das ações do administrador é
somente leitura;
Restrições tecnológicas: não há.
54
Geração de Senha
[RF05] O sistema precisa gerar uma senha após o atendente abrir pedido de
atendimento
Descrição: o sistema gera uma senha toda vez que a função abrir pedido de
atendimento for acionado pelo atendente;
Ator: sistema;
Informação de entrada: se o paciente tem histórico clínico cadastrado é só conferir os
dados e executar a função abrir pedido de atendimento para gerar uma senha; se o
paciente não tem histórico clínico cadastrado é só proceder ao cadastro, logo em
seguida, abrir pedido de atendimento para gerar a senha;
Informação de saída: uma senha alfanumérica que é impressa;
Restrições lógicas: não há;
Restrições tecnológicas: uma impressora conectada e configurada.
Registro de Inclusões ou Alterações
[RF06] O sistema precisa registrar as inclusões ou atualizações realizadas no
histórico clínico do paciente;
Descrição: toda vez que o médico ou enfermeiro realiza uma inclusão ou atualização
no histórico clínico do paciente o arquivo de registro de evento deste atualiza criando
uma nova entrada;
Ator: sistema;
Informação de entrada: o tipo de usuário médico ou enfermeiro realiza uma inclusão
ou atualização de dados do histórico clínico do paciente;
Informação de saída: o sistema faz uma chamada ao arquivo de registro de evento
do histórico clínico do paciente que é somente leitura e o atualiza, criando novas
entradas por meio dos dados: data, hora, qual o campo alterado, o dado alterado,
nome do profissional e IdEvento;
Restrições lógicas: arquivo de registro de eventos do histórico clínico de paciente é
somente leitura;
Restrições tecnológicas: não há.
55
Chamada de Pacientes
[RF07] A interface gráfica dos usuários do tipo médico e enfermeiro precisam permitir
a chamada de paciente por sua senha no monitor de chamada;
Descrição: o sistema exibe a senha no monitor;
Ator: sistema;
Informação de entrada: médico e enfermeiro fazem a chamada de atendimento por
meio da senha;
Informação de saída: se é o médico quem faz a chamada, então, o sistema exibe a
senha no quadro vermelho do monitor; se é o enfermeiro quem faz a chamada, então,
o sistema exibe a senha no quadro azul do monitor;
Restrições lógicas: o médico e o enfermeiro não podem chamar a mesma senha no
mesmo momento;
Restrições tecnológicas: não há.
Inclusão e Alteração de Dados do Paciente
[RF08] O sistema deve permitir aos usuários do tipo médico e enfermeiro inclusão e
atualização de dados no histórico clínico de paciente
Descrição: o sistema inclui e atualiza dados do histórico clínico de paciente;
Ator: sistema;
Informação de entrada: campos para preenchimento;
Informação de saída: lista com os dados;
Restrições lógicas: não há;
Restrições tecnológicas: não há.
56
Configurações Cliente/Servidor pelo Administrador
[RF09] O usuário do tipo administrador, por meio de uma área privada, precisará ter
acesso para alterar as configurações do módulo cliente e o servidor (dependência);
Descrição: o módulo cliente e servidor (dependência) precisam possuir uma janela
de acesso privado que permite alterar parâmetros, por exemplo, comunicação em
rede entre eles;
Ator: administrador;
Informação de entrada: o administrador, por meio de uma área de acesso privado,
pode alterar parâmetros de funcionamento dos módulos, por exemplo, conexão de
rede;
Informação de saída: não há;
Restrições lógicas: função que retorna as configurações padrões dos módulos;
Restrições tecnológicas: não há.
Inclusão ou Inativação de Usuários
[RF10] O usuário do tipo administrador, por meio de uma área privada, precisa ter
acesso para inclusões e inativação de um ou mais usuários do tipo médico, enfermeiro
e atendente;
Descrição: o usuário do tipo administrador pode incluir ou excluir os perfis de um
usuário do tipo médico, enfermeiro ou atendente;
Ator: administrador;
Informação de entrada: em uma área privada há as opções de inclusão ou inativação
de um usuário do tipo médico, enfermeiro ou atendente;
Informação de saída: uma lista com os usuários adicionados e o tipo;
Restrições lógicas: não há;
Restrições tecnológicas: Os parâmetros de configuração dos módulos precisam estar em uma lista ordenada de forma alfabética.
57
Criação de Base de Dados para Novo Paciente
[RF11] O sistema criará uma nova base de dados no banco de dados
permanente para um paciente não pré-cadastrado;
Descrição: o sistema precisa criar uma base de dados permanente no sistema de
gerenciamento de banco de dados (SGBD) para um paciente não pré-cadastrado;
Ator: sistema;
Informação de entrada: em uma janela, o atendente preenche o formulário contendo
os seguintes dados: IdHcp autopreenchimento, nome, sexo, data de nascimento,
filiação (mãe, pai), RG, CPF, cartão SUS, endereço, se possui ou não convênio
médico e qual;
Informação de saída: o formulário com o campo IdHcp é associado à base de dados
histórico clínico de paciente;
Restrições lógicas: o formulário de um paciente deve estar sempre associado a seu
histórico clínico, ainda que este não possua qualquer dado;
Restrições tecnológicas: não há.
Cadastro de Paciente
[RF12] Um usuário do tipo atendente pode apenas incluir dados de um novo paciente
ou apenas atualizar o endereço, o telefone e o e-mail do histórico clínico de um
paciente pré-cadastrado no SGBD;
Descrição: Um usuário do tipo atendente tem permissão para apenas incluir os dados
de um novo paciente ou apenas atualizar os dados de endereço, telefone e e-mail de
um paciente com pré-cadastro no SGBD;
Ator: atendente;
Informação de entrada: o atendente insere os dados nos campos ou atualiza apenas
endereço e telefone se o paciente já for cadastrado, depois atualiza o histórico clínico
do paciente;
Informação de saída: os relativos campos no SGBD são atualizados e as alterações
são registradas no arquivo de registro de eventos do histórico clínico do paciente;
Restrições lógicas: não há;
58
Restrições tecnológicas: não há.
Atualização de Dados Paciente pelo Enfermeiro
[RF13] Um usuário do tipo enfermeiro pode atualizar informações do exame pré-
atendimento, como pressão cardíaca e grau de risco para triagem do atendimento
Descrição: o usuário enfermeiro fara pré atendimento colhendo informações sobre
pressão arterial e identificação do grau de risco do paciente entre baixo, médio e alto
para que a senha gerada no atendimento, possa ter o fluxo correto no atendimento;
Ator: enfermeiro;
Informação de entrada: usuário colherá informação de pressão cardíaca de forma
manual com estetoscópio ou com aparelho totalmente automática, insere-se a
informação no histórico do paciente e a partir dessa informação e destacado o grau
de risco do paciente entre grau baixo, grau médio ou grau alto, tornando assim a
sequência de chamada de acordo com esse grau de risco, considerando
preferencialmente o grau alto de risco como de 1ª chamada, o grau médio de risco
como de 2ª chamada e o grau baixo como o de 3ª chamada;
Informação de entrada: usuário enfermeiro insere informação de pressão arterial e
define o grau de risco;
Informação de saída: a partir das informações fornecidas pelo usuário enfermeiro o
sistema refaz a lista de chamada dando prioriza ao grau de risco alto, logo após o
médio e por fim o grau de risco baixo;
Restrições lógicas: o sistema deve conter sempre o histórico de pressão arterial e
do grau de risco definido pelo usuário enfermeiro;
Restrições tecnológicas: não há.
Chamada de Paciente pelo Médico
[RF14] Usuário médico terá acesso apenas para a funcionalidade fila, para efetuar o
chamado sequencial do sistema;
Descrição: usuário médico poderá apenas chamar a sequência da fila pré
estabelecida pelo sistema, quando este feito no pré atendimento pelo usuário
enfermeiro;
Ator: médico;
59
Informação de entrada: ao acessar o sistema médico, o usuário médico entrara em
uma tela especifica para efetuar o chamado de cada paciente para consulta, porém
terá acesso apenas ao botão Chamar Próximo ou Retornar ao Chamado Anterior;
Informação de entrada: apenas abertura de tele de fila de atendimento e clique nos
botões específicos de chamado;
Informação de saída: o sistema irá gerar a senha em tela para os pacientes
visualizarem e comparecer ao consultório médico para atendimento;
Restrições lógicas: o sistema deve manter a sequência lógica das senhas no IdHcp,
para que posteriores consultas, auditorias e melhorias no funcionamento possam
ocorrer;
Restrições tecnológicas: Dashboard para visualização da senha pelos pacientes;
Atendimento Médico
[RF15] Usuário médico pode atualizar sobre o atendimento médico do paciente, como
exame subjetivo, objetivo, por imagem, diagnóstico, e o tratamento;
Descrição: o usuário médico irá atualizar e ou inserir informações de sintomas, irá
solicitar exame por imagem, exame objetivo, assim poderá formular um diagnóstico e
prescrever o tratamento.
Ator: médico;
Informações de entrada: o usuário médico irá alimentar o SGBD com os dados de
sintomas e exame objetivo, com isso poderá formular diagnóstico ou ainda pedir
exame por imagem para dar base ao diagnóstico, quando este definido irá inserir o
diagnóstico e informar o tratamento, podendo ser tratamento através de medicação
ou tratamento especifico, como exemplo, tratamento através de fisioterapia;
Informação de saída: não há;
Restrições lógicas: as informações deverão ser alimentadas no IdHcp no paciente.
Restrições tecnológicas: não há.
60
Encaminhamento do Paciente pelo Médico
[RF16] O usuário médico poderá fazer encaminhamento de paciente a especialista
Descrição: Quando do não diagnóstico do paciente, o usuário médico tem a opção
de encaminhamento, abrindo-se assim uma nova tela para escolha da especialidade,
o agendamento final será feito no atendimento;
Ator: médico;
Informações de entrada: médico irá inserir dados da especialidade no sistema e
encaminhar paciente ao atendimento, o usuário atendente irá agendar no sistema a
hora e o dia para atendimento do paciente.
Informações de saída: o sistema irá confirmar o agendamento e o sistema irá gerar
uma guia para que o paciente não esqueça de ir;
Restrições lógicas: o sistema deverá guardar as informações no SGBD do IdHcp do
paciente;
Restrições tecnológicas: impressora conectada ao sistema para impressão da guia de atendimento do especialista.
Geração de Senha Automática para Usuários
[RF17] O sistema deve gerar uma senha para autenticação do primeiro acesso ao
módulo cliente pelos profissionais cadastrados;
Descrição: após o cadastro dos profissionais, o sistema gera uma senha para
autenticação do primeiro acesso deles ao módulo cliente;
Ator: sistema;
Informações de entrada: campos não podem ser nulos;
Informações de saída: senha para autenticação do primeiro acesso;
Restrições lógicas: não há;
Restrições tecnológicas: não há.
61
Pré Atendimento
[RF18] O usuário enfermeiro poderá incluir o grau de risco vermelho, ocasionando
assim o atendimento prioritário do médico, estando ele em atendimento ou não,
direcionando o médico a sala correspondente para atender o paciente;
Descrição: quando houver pacientes em grau de risco vermelho, ou seja, que corre
risco de morte, o enfermeiro irá incluir no sistema o grau de risco vermelho e irá
selecionar a sala a encaminhar o paciente, ao clicar no botão encaminhar, o médico
receberá um sinal visual e sonoro identificando a sala onde o paciente está para que
este possa interromper o atendimento, se estiver atendendo, e atender o paciente, o
enfermeiro não tem a necessidade de incluir os dados do paciente, somente depois
do atendimento ou se houver algum documento ou acompanhante com o paciente,
ainda assim será de responsabilidade do atendente a entrada desses dados;
Ator: enfermeiro;
Informações de entrada: selecionar o grau de risco vermelho, selecionar a sala e
clicar no botão encaminhar;
Informações de saída: o médico recebe em seu monitor sinal visual e sonoro,
identificando o grau vermelho e a sala que o paciente será ou foi encaminhado;
Restrições lógicas: não há;
Restrições tecnológicas: não há.
62
APÊNDICE C – REQUISITOS NÃO FUNCIONAIS
[RNF01] ADEQUAÇÃO FUNCIONAL: Adaptar as telas dos profissionais à linguagem
própria da profissão: não utilizar palavras genéricas para caracterizar os menus, as
abas, os campos de dados ou os botões de ação. Desta forma, tem-se o uso por
intuição.
[RNF02] EFICIÊNCIA NO DESEMPENHO: O sistema deve oferecer aos usuários um
desempenho rápido e preciso, já que os dados contidos no mesmo são de extrema
importância, pois tratam de dados humanos, então a otimização do sistema para
melhoramento do desempenho sobre este é de extrema importância.
[RNF03] COMPATIBILIDADE: O sistema será compatível a princípio com sistema
Windows e posteriormente compatibilidade com outros sistema e plataformas, como
plataforma web, para que possa ser acessado via remota pelo médico ou o
administrador do sistema, para análise e correção das informações ou dos dados.
[RNF04] USABILIDADE: Por ter uma interface de trabalho simples e bem definida, a
usabilidade do sistema é de rápida assimilação e de simples compreensão, sendo sua
utilização fácil e simples, cabendo aos usuários apenas a inclusão de dados, edição
ou inativação.
[RNF05] CONFIABILIDADE: Por ser uma plataforma local de trabalho, suas
informações e dados não correm risco inerente a áreas externas, há também o
trabalho de não haver redundância dos dados, pois as inclusões de dados são feitas
com chaves especificas.
[RNF06] CAPACIDADE DE MANUTENÇÃO: Por se tratar de um servidor e clientes
locais, a manutenção é de simples acessos e fácil execução, garantindo a integridade
e usabilidade do sistema.
[RNF07] SEGURANÇA: Para se ter acesso ao sistema é necessário um cadastro feito
diretamente pelo administrador, garantindo a segurança do sistema, o usuário
paciente não tem acesso às informações, e os usuários que acessam o sistema tem
acesso apenas a sua área de atuação.
[RNF08] PORTABILIDADE: Como seu desenvolvimento poderá ocorrer em
linguagem Java, o sistema poderá ser compatível com as diversas plataformas,
dependendo apenas de sua implantação no cliente.
63
APÊNDICE D – DIAGRAMAS DE CASO DE USO
Quadro 16 - Diagrama de Caso de Uso Cadastro de Paciente
Fonte: (Próprio autor)
Diagrama de caso de uso é descrito como será feito o cadastro do paciente no
sistema, se este já não estiver cadastrado no mesmo, e após o envio ao enfermeiro
para o pré-atendimento.
64
Quadro 17 - Diagrama de Caso de Uso Pré-Atendimento
Fonte: (Próprio autor)
Diagrama descreve como o pré-atendimento do paciente, onde o ator
enfermeiro acessa seu terminal e chamará o paciente no monitor da sala de espera,
após entrar na sala de atendimento o enfermeiro irá ouvir os sintomas e fazer alguns
exames de pressão arterial, onde terá base para conceituar a triagem do paciente no
sistema.
65
Quadro 18 - Diagrama de Caso de Uso Pré-Atendimento com Registros
Fonte: (Próprio autor)
Ainda sobre o pré-atendimento, o diagrama mostra os exames que o ator
enfermeiro pode realizar no paciente e registrar no sistema antes de encaminhar ao
terminar do médico que terá a triagem completa para chamada dos pacientes.
66
Quadro 19 - Diagrama de Caso de Uso Atendimento Médico
Fonte: (Próprio autor)
Em seu terminal, o médico acessa sua lista de chamada e acessa a listagem
em ordem de triagem para fazer a chamada dos pacientes. Quando o paciente é
atendido, este relato os sintomas ao médico, que por sua vez irá fazer alguns exames
de auscultação e físicos, e irá determinar o diagnóstico ou encaminhará ao
encaminhará a um especialista, após a consulta, o médico irá receitar ao paciente
algum medicamento ou tratamento físico e encerrará o atendimento.
68
APÊNDICE F – DIAGRAMAS DE SEQUENCIA
Quadro 21 - Diagrama de Sequência Pré-Atendimento
Fonte: (Próprio autor)
Diagrama de sequência dos processos de atendimento, cadastramento do
paciente e chamada pelo enfermeiro.
69
Quadro 22 - Diagrama de Sequência Consulta Médica
Fonte: (Próprio autor)
No diagrama foram evidenciadas as sequencias dos processos de chamada do
paciente pelo médico, atendimento, diagnostico e prescrição médica.
70
APÊNDICE G – DIAGRAMAS DE ATIVIDADE
Quadro 23 - Diagrama de Atividade Cadastro de Paciente
Fonte: (Próprio autor)
Diagrama de atividade de cadastro de um paciente, tendo as raias Paciente e
Atendente como atores responsáveis pelo processo, descrevendo suas atividades
para a conclusão do processo.
71
Quadro 24 - Diagrama de Atividade Triagem
Fonte: (Próprio autor)
O diagrama de triagem realizado pelas raias Paciente e Enfermeiro, que são os
principais atores para execução do processo, onde o Paciente tem pouca ação sobre
o fluxo de atividade, porém é peça chave para execução dele.
72
Quadro 25 - Diagrama de Atividade Triagem
Fonte: (Próprio autor)
O diagrama de atividade da consulta médica, onde temos as raias Paciente e
Médico como atores principais para execução das atividades para execução do
processo.
73
APÊNDICE H – DIAGRAMA DE ENTIDADE RELACIONAMENTO DER
Quadro 26 - Diagrama de Entidade Relacionamento DER
Fonte: (Próprio autor)