UNIVERSIDADE PAULISTA – UNIP EaD

PIM - Projeto Integrado Multidisciplinar

Curso Superior de Tecnologia em

Análise e Desenvolvimento de Sistemas

NOME DO ALUNO
RA

CONSTRUÇÃO DE SISTEMA PARA TELE ATENDIMENTO MÉDICO

São Paulo
2022
 RESUMO
A presente pesquisa propõe uma solução digital que objetiva o
desenvolvimento de uma codificação em C# do mecanismo de acesso a um trecho
de banco de dados, assim como os protótipos de interface gráfica com o usuário em
ASP.Internet e android. Acompanhando o prognóstico do desenvolvimento, tendo
em vista a tarefa de melhorar algum aspecto do sistema já em desenvolvimento, a
equipe foi encarregada de desenvolver uma estrutura para possibilitar o acesso às
informações da base de dados (banco de informações). Um banco de dados
prototipando uma interface gráfica do usuário em ASP.NET permitindo que o
usuário interaja com os dados modelados, e levando em consideração o
desenvolvimento de outra interface gráfica do usuário no Android.
Para o desenvolvimento do projeto foram aplicados os conceitos,
conhecimentos e práticas adquiridos ao longo do curso com o complemento da
investigação de forma a permitir a aplicação e implementação da tecnologia back-
end. Porém, para o desenvolvimento do projeto foi necessário analisar, desenvolver
diagramas de funcionamento, instalação e estruturação do banco de dados e
desenvolvimento das interfaces solicitadas, permitindo a realização do primeiro
versionamento do sistema de acesso ao banco de dados.
Palavras chave: Desenvolvimento de Sistemas; Teleatendimento; ASP.Net
 ABSTRACT
The present research proposes a digital solution that aims to develop a coding in C#
of the access mechanism to a database segment, as well as the prototypes of a
graphical user interface in ASP.Internet and android. Following the development
prognosis, in view of the task of improving some aspect of the system already under
development, the team was in charge of developing a structure to enable access to
the information in the database (information bank). A database prototyping a
graphical user interface in ASP.NET allowing the user to interact with the modeled
data, and taking into account the development of another graphical user interface in
Android.
For the development of the project, the concepts, knowledge and practices acquired
during the course were applied with the complement of the investigation in order to
allow the application and implementation of the back-end technology. However, for
the development of the project it was necessary to analyze, develop diagrams of
operation, installation and structuring of the database and development of the
requested interfaces, allowing the realization of the first versioning of the database
access system.
Keywords: Systems Development; Call center; ASP.Net
SUMÁRIO
1. INTRODUÇÃO 5
1.1 MODELO DE NEGÓCIO 5
1.2 SEGMENTAÇÃO DO NEGÓCIO 5

2. DESENVOLVIMENTO 6
2.1 REQUISITOS FUNCIONAIS (RF) 6
2.2 Requisitos Funcionais do sistema 6
2.3 REQUISITOS NÃO FUNCIONAIS 7
2.4 REQUISITOS NÃO FUNCIONAIS DO SISTEMA (RNF) 7
2.5 PROJETO DO SISTEMA E DIAGRAMA DE CASO 8
2.6 PROJETO DO SISTEMA 8
2.7 OBJETOS 8
2.8 DIAGRAMA DE CASO DE USO 9
2.9 PROGRAMAÇÃO DO SISTEMA 10
2.10 DESENVOLVIMENTO DA APLICAÇÃO 10

3. CONCLUSÃO 11

BIBLIOGRAFIA 13
 1. INTRODUÇÃO

1.1 MODELO DE NEGÓCIO

Do ponto de vista da aplicação, prova ser uma ferramenta de interação e integração,
onde há transferência de dados relativos à saúde a telemedicina surge como um
importante instrumento para facilitar o acesso à saúde e na interação entre os
profissionais da área, seja entre si ou com seus pacientes.. Em relação ao aplicativo
desenvolvido, deve-se entender que existem dois tipos de telemedicina: a síncrona
(online), cujo os médicos e pacientes se ligam simultaneamente e interagem em
tempo real; e assíncrono, em que pacientes ou médicos remetem ou obtêm
informações, inscrições, documentos ou vídeos em instantes diferentes. O software
concebido abrange ambas as formas de telemedicina. Isso permite consulta online e
armazenagem de arquivos. Isso permite baixá-los para o dispositivo em que são
usados para que possam ser encaminhados no momento certo.

1.2 SEGMENTAÇÃO DO NEGÓCIO

Desde municípios, organizações e empresários individuais do setor de saúde

que prestam serviços e atendem as classes A, B e C, e que necessitam estabelecer
uma relação de atendimento remoto entre si e seus pacientes (teleatendimento).
Prioridades: agilidade no atendimento; Segurança; Data atualizada. Canal:
site próprio; consultor no local. Relacionamento com o cliente redes sociais e
WhatsApp; próprio site, telefone; Endereço de email.
- Fonte de financiamento: Venda de licenças do sistema.
- Características principais: sistema no formato de aplicativo web (App) para
conexão da estrutura de atendimento médico-hospitalar (desde instuições,
até profissionais da saúde) com o usuário e paciente final.
- Principais Atividades: Administração de sistemas; pesquisa e
desenvolvimento; local na rede Internet. Principais Parcerias:
administradores de planos de Saúde; seguradora; hospital especializado
Clínica Médica Privada do SUS - Ministério da saúde Pública. Estrutura de
 custos: Aquisição de licenças; manutenção de software Marketing e vendas
digitais.
2. DESENVOLVIMENTO

2.1 REQUISITOS FUNCIONAIS (RF)

Diz respeito a todas as especificações voltadas para as funções e recursos do

sistema que está sendo desenvolvido. Esses parâmetros correspondem aos
requisitos básicos para que o software consiga operar, que atuam em camadas no
sistema. Esses requisitos são definidos em coordenação com os interesses e
objetivos que os analistas de planejamento e negócios elaboraram, visando atender
às demandas e necessidades esboçadas antes do software entrar em operação.

2.2 REQUISITOS FUNCIONAIS DO SISTEMA

● RF1. O sistema deve registrar as consultas, sinalizando o paciente e o

fisioterapeuta, bem como data, horário, valor da consulta e plano de saúde do
paciente.
● RF2. O sistema deve permitir que um fisioterapeuta insere informações no
prontuário do paciente, e essa ação deve ser registrada com a data e a hora
da entrada.
● RF3. O sistema deve permitir que os pacientes cancelarão suas consultas
com até 24 horas de antecedência sem ônus, porém, quando esse período
for perdido ou o paciente não comparecer à consulta, o sistema deverá gerar
uma factura no valor de meia consulta e bloqueia a agenda desse paciente
até que ele pague sua dívida.
● RF4. Os fisioterapeutas devem ter acesso aos registros das consultas
agendadas, bem como ao número de consultas realizadas em um
determinado período.
● RF5 O sistema deve permitir que os fisioterapeutas ofereçam descontos e
parcelamentos de acordo com a política da clínica de fisioterapia.
● RF6. O sistema deve permitir que um funcionário registra o pagamento de
consultas, agende e desmarque consultas, cadastre pacientes,
fisioterapeutas, medicamentos, profissões e planos de saúde.
 ● RF 7. Somente fisioterapeutas podem desbloquear consultas para pacientes
que não podem marcar consultas.
● RF8 O sistema deve ser capaz de visualizar a agenda de fisioterapeutas e
planos de saúde conveniados. Essas consultas podem ser feitas provendo
uma ou mais informações, como nome do fisioterapeuta, plano de saúde e
datas.
● RF 9. Não é possível excluir pacientes examinados, pois o sistema deve
manter um histórico de atendimentos.
● RF 10. O sistema deve permitir habilitação e desabilitação de pacientes e
fisioterapeutas. Eles também tiveram que criar IDs exclusivos para cada
paciente e fisioterapeuta.

2.3 REQUISITOS NÃO FUNCIONAIS

Enquanto os requisitos de desempenho definem o comportamento básico do

sistema. Os requisitos não funcionais definem como o sistema executa essa função.
Vamos voltar ao exemplo de notificação por e-mail. O fato de o sistema enviar
automaticamente uma notificação por e-mail é um requisito funcional. Os requisitos
não funcionais ditarão quando. Isso é diferente dos requisitos funcionais. Os
requisitos não funcionais não são fundamentais para o sistema. Isso significa que o
sistema continuará a funcionar mesmo se a não conformidade for atendida. No
entanto, não devemos reduzir o papel dos pré-requisitos não funcionais.

2.4 REQUISITOS NÃO FUNCIONAIS DO SISTEMA (RNF)

● RNF1. O sistema deve ser confiável, neste sentido, deve atender
satisfatoriamente às suas especificações.
● RNF2 A probabilidade de o sistema funcionar dentro do prazo deve ser alta.
● RNF2. O software deve ser portátil. Isso significa que ele deve ser usado em
qualquer plataforma de hardware e software.
● RNF3. Os sistemas devem lidar com acessos não autorizados, portanto, um
alto grau de segurança deve ser garantido, e o acesso às funções deve ser
controlado por administradores e grupos de usuários em geral.
 ● RNF4. A interface do software deve ser amigável, ou seja, o usuário deve se
sentir confortável ao utilizar o sistema para que sua experiência seja fácil.
● RNF5. Deve ser possível consultar a agenda via Internet utilizando os
principais navegadores disponíveis no mercado.
● RNF6. A retenção de informações deve ser implementada em um sistema de
gerenciamento de banco de dados relacional gratuito (RDBMS) .

2.5 PROJETO DO SISTEMA E DIAGRAMA DE CASO

A partir do levantamento e da análise de necessidades realizadas, chegou-se

ao diagrama de casos, que, segundo GUEDES (2011), apresenta uma visão externa
geral das funcionalidades que o sistema deve oferecer aos usuários,
independentemente de sua forma de atuação, esses recursos irão se desenvolver.
Os pacientes podem fazer login e solicitar. A secretária além de poder
realizar exames, pacientes, profissionais da saúde de todos os níveis, planos de
saúde e contas, pode agendar consultas, também, como ator que é descendente do
paciente, herda todos os seus casos de uso.

2.6 PROJETO DO SISTEMA

A programação orientada a objetos é um padrão de programação

fundamental utilizado por quase todos os programadores em algum momento.Trata
- se de um paradigma de programação mais popular e é ensinado à maioria dos
programadores em sua carreira educacional como uma forma padrão de
programação. Ele é usado para organizar um programa de software em partes
reutilizáveis simples de projetos de codificação (usualmente chamados de classes),
que são empregados para criar instâncias únicas de objetos. Existem muitas
linguagens de programação orientadas a objetos, incluindo o C++.

2.7 OBJETOS

Objetos são elementos computacionais que figuram no domínio da solução

entidade parcial (abstrata ou concreta) do domínio de interesse para o problema que
está sendo analisado. Esses objetos são agrupados em classes. No paradigma
orientado a objetos, tudo pode potencialmente ser figurado como um objeto. De uma
perspectiva de programação, um objeto não é muito diferente de uma variável no
paradigma de programação convencional. Por exemplo, ao definir uma variável do
tipo elemento C ou Java, esta variável possui: · Um espaço na memória para
armazenar seu estado atual (um valor); · Um conjunto de operações associadas que
podem ser aplicadas a ele, através dos operadores definidos na linguagem aplicável
a valores inteiros (adição, subtração, inversão de sinais, multiplicação, divisão de
inteiros, resto de divisão de inteiros, incremento, decremento).Da mesma forma,
quando um objeto é criado, esse objeto adquire espaço na memória para armazenar
seu estado (os valores de seu conjunto de atributos, definido pela classe e um
conjunto de operações que podem ser aplicadas ao objeto o conjunto de métodos
definidos pela classe.

2.8 DIAGRAMA DE CASO DE USO

FIGURA 1: INTERFACE USUÁRIO

Fonte: autor (2022)

FIGURA 2: INTERFACE ADMINISTRADOR

Fonte: autor (2022)

2.9 TELAS DE PROGRAMAÇÃO DO SISTEMA

Tela 1: Editar usuário

Fonte: autor (2022)

Tela 2: Lista usuários

Fonte: autor (2022)

Tela 3: Emulador de tela 1

Fonte: autor (2022)

Tela 4: Emulador de tela 2

Fonte: autor (2022)

Tela 5: Design de tela 1

Fonte: autor (2022)

Tela 6: Design de tela 2

Fonte: autor (2022)

2.10 DESENVOLVIMENTO DA APLICAÇÃO

O desenvolvimento de interfaces seguiu as boas práticas de design e

princípios de usabilidade, segundo as quais, segundo Vilariño (2018), da qual é
necessário construir uma interface amigável para a interação humano-computador,
através de um canal de comunicação em que existam interações para alcançar um
objetivo comum.
Figura 3: reconhecimento do fluxo de navegação e das telas

Fonte: autor (2022)

 3. CONCLUSÃO

Está ficando cada vez mais claro o quanto a telemedicina pode auxiliar tanto
os profissionais de saúde quanto os pacientes que precisam interagir com eles. A
interação entre os dois personagens do uso da presente pesquisa se faz ainda mais
necessária considerando o contexto da sociedade atual que vive reflexo de uma
pandemia de SARS-CoV2 (coronavírus). Com isso, a tecnologia trará inovação e
ajudará a minimizar as barreiras existentes entre médicos e pacientes.
Este projeto dá-nos condições para interpretar de forma mais assertiva os
interesses do cliente e transformá-los em realidade de forma ordenada, com mais
eficiência, com custo nas previsões e de forma eficiente, não só cumprindo as
expectativas, mas também os prazos definidos pelos clientes, atores do processo.
No âmbito deste projeto conseguimos definir um modelo de negócio e um
plano estrutural para implementação do sistema, da qual está totalmente voltado
para o teleatendimento. Oferecemos especificações funcionais e não funcionais e
regras de protocolo para desenvolvimento do sistema, além de planejamento e
aplicação em interface web, que são pressupostos essenciais para demonstração
do protótipo e difusão do aplicativo.
BIBLIOGRAFIA

BEZERRA, Eduardo. Princípios de Análise e Projetos de Sistemas com UML.

Rio de Janeiro: Elsevier, 2007.
Cunha Pereira França Magalhães, Carolina da: Guia prático para atendimentos
por telemedicina em tempos de covid-19, 2020. https://onlinedoctor.com.br/
cartilha-telemedicina.pdf, acesso em 20/04/2022.
HIDOCTOR, Software Médico Para Consultório. Disponível em:
<http://www.hidoctor.com.br>. Acessado em: 15 out. 2022.
PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional.
Porto Alegre: AMGH, 2011.