faculdade de tecnologia de itapira - … · allen corradi de; cavenaghi, carlos luís. ii...

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




CARLOS LUÍS CAVENAGHI



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




CARLOS LUIS CAVENAGHI



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/

http://www.mindmaster.com.br/scrum/

17

Quadro 3 - Framework Kanban

Fonte: site https://br.atlassian.com/agile/kanban

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).


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.


Percussão Ausculta

CABEÇA E PESCOÇO

21. Crânio; 22. Pescoço; 23. Olhos; 24. Nariz; 25. Boca; 26. Orelha.


Percussão Ausculta

EXTREMIDADES

27. Braços; 28. Dedos; 29. Punhos; 30. Cotovelos; 31. Ombro.


Percussão Ausculta

TÓRAX POSTERIOR 32. Desenvolvimento muscular; 33. Movimento respiratório; 34. Diâmetro anteroposterior.


Percussão Ausculta

TÓRAX ANTERIOR 35. Mamas; 36. etc.


Percussão Ausculta

ABDOME

37. Cicatriz; 38. Simetria; 39. Peristaltismo; 40. Sopro


Percussão Ausculta

CONCLUSÃO DO EXAME DAS EXTREMIDADES

41. Amplitude do movimento dos quadris; 42. Creptação; 43. Etc.


Percussão Ausculta

NEUROLÓGICO 44. Marcha; 45. Hálux ao andar; 46. Calcanhar ao andar


Percussão Ausculta

GENITAIS 47. Genitália masculina; 48. Genitália Feminina.


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


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


Tela de login do Administrador, exibindo os campos de login e senha.

45

Quadro 9 - Tela Painel Administrativo usuário Administrador


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


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


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


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


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


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


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;


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;


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;


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;


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;


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;



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;


Restrições lógicas: função que retorna as configurações padrões dos módulos;


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


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;


58


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;


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;


Restrições lógicas: as informações deverão ser alimentadas no IdHcp no paciente.


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;



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;



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


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


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


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


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.

67

APÊNDICE E – DIAGRAMA DE CASO DE CLASSE

Quadro 20 - Diagrama das Classes


68

APÊNDICE F – DIAGRAMAS DE SEQUENCIA

Quadro 21 - Diagrama de Sequência Pré-Atendimento


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


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


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


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


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


74

APÊNDICE I – MODELO FÍSICO

Quadro 27 - Modelo Físico


75

APÊNDICE J – FLUXOGRAMA DAS ATIVIDADES

Quadro 28 - Fluxograma das Atividades


faculdade de tecnologia de itapira - … · allen corradi de; cavenaghi, carlos luís. ii...

Documents