Documento de Visão
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 22/08 | 1.0.0 | Adição dos artefatos do documento de visão | Felipe Borges, Hiroshi |
| 22/08 | 1.1.0 | Construção escopo da Descrição da Parte Interessada | Guilherme |
| 22/08 | 1.2.0 | Construção escopo da Introdução | Hiroshi |
| 22/08 | 1.3.0 | Adição Visão geral do Produto | Felipe Borges |
| 22/08 | 1.4.0 | Adição dos Recursos do Produto | Natália Rodrigues |
| 22/08 | 1.5.0 | Adição do Posicionamento do Produto | Mateus Nóbrega |
| 24/08 | 1.5.1 | Atualização dos Recursos do Produto | Natália Rodrigues |
| 24/08 | 1.5.2 | Correção Introdução | Hiroshi |
| 24/08 | 1.5.3 | Definição de precedência e prioridade | Michel M. Camargo |
| 24/08 | 1.5.4 | Atualizando Descrição da Parte Interessada | Guilherme |
| 24/08 | 1.6.0 | Adição das restrições do produto | Lucas Kishima |
| 25/08 | 1.6.1 | Reescrevendo tópico 4 em 4.1 e 4.2 | Felipe Borges |
| 25/08 | 1.7.0 | Adição de alguns pontos no tópico 5 | Natália Rodrigues |
| 26/08 | 1.7.1 | Revisão do Documento de Visão | Guilherme, Felipe Borges, Hiroshi |
| 26/08 | 1.7.2 | Adição das Restrições de Segurança | Lucas Kishima |
| 26/08 | 1.7.3 | Revisão do Posicionamento | Mateus Nóbrega |
| 26/08 | 2.0.0 | Revisão do Documento de Visão e passagem para Wiki | Guilherme, Felipe Borges, Natália, Mateus, Hiroshi, Lucas Kishima |
| 27/08 | 2.0.1 | Revisão das restrições | Lucas Kishima |
| 27/08 | 2.0.2 | Alteração do Tópico 3.1 do Tópico 3.2 | Guilherme |
| 28/08 | 2.0.3 | Alteração nos Tópicos 1.3 e 1.5 | Guilherme |
| 28/08 | 2.0.4 | Ajuste no Tópico 5 | Natália Rodrigues |
| 28/08 | 2.0.5 | Ajuste do Tópico 1, Tópico 3.2 | Guilherme, Felipe Borges, Mateus |
| 28/08 | 2.0.6 | Ajustes no Tópico 6 e adição do tópico 6.4 | Lucas Kishima |
| 31/08 | 2.0.7 | Ajuste no Tópico 1.2, 1.3, 3, 3.3.1, 3.3.2 | Guilherme |
| 07/12 | 2.0.8 | Adicionando vantagem do médico na utilização do sistema |
- 1.1 Propósito
- 1.2 Escopo
- 1.3 Definições, acrônimos e abreviações
- 1.4 Referências
- 1.5 Visão Geral
- 3.1 Resumo dos Usuários
- 3.2 Ambiente do Usuário
- 3.3 Perfis dos Envolvidos
- 3.4 Perfis dos Usuários
- 3.5 Principais Necessidades dos Usuários ou dos Envolvidos
- 3.6 Alternativas e Concorrência
- 6.1 Restrições de Design
- 6.2 Restrições de Implementação
- 6.3 Restrições de Segurança
- 6.4 Restrições de Uso
1. Introdução
1.1 Propósito
O documento presente tem a finalidade de apresentar e estabelecer uma visão ampla sobre o webapp Receituário Médico de modo a deixar claro sua proposta, características e utilidade.
1.2 Escopo
Este projeto tem como finalidade suprir a necessidade de controle, gerenciamento de receitas médicas e de contato pós-consulta de forma rápida e eficiente.
- FGA - Faculdade do Gama (UnB)
- UnB - Universidade de Brasília
- MDS - Métodos de Desenvolvimento de Software
- GPP - Gestão de Portfólios e Projetos de Software
- Profissionais de saúde - A quem compete prescrever medicamentos, exames e recomendações de saúde
- Prescrição - Lista de medicamentos indicados e recomendações de saúde para um paciente
1.4 Referências:
IBM Knowledge Center - Documento de Visão: A estrutura de tópicos do documento de visão. Disponível em: https://www.ibm.com/support/knowledgecenter/pt-br/SSWMEQ_3.0.1/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.htm. Acesso em: 22 ago. 2017;
FREIRE, Thiago; OLIVEIRA, Rodrigo; MORENO, Augusto; NASCIMENTO, Josué; AUGUSTO, Marcelo. Projeto WikiLegis: Documento de Visão. Disponível em: https://github.com/fga-gpp-mds/2016.2-WikiLegis/wiki. Acesso em 22 ago. 2017;
SILVA, Ana; DINIZ, Arthur; OLIVEIRA, Bruna; SILVA, Guilherme; LACERDA, GuilhermE. Projeto Trezentos: Documento de Visão. Disponível em: https://github.com/fga-gpp-mds/2017.1-Trezentos/wiki. Acesso em 22 ago. 2017;
BATISTA, Matheus; ARAÚJO, Igor; WILLER, Guilherme; OLIVEIRA, Vinícius; BARCELOS, Filipe; SOUSA, André. Projeto Escola X: Documento de Visão. Disponível em: https://github.com/fga-gpp-mds/2017.1-Escola-X/wiki. Acesso em 22 ago. 2017;
1.5 Visão geral
Este documento é dividido em 7 tópicos descrevendo os detalhes das características do software proposto. Sendo dividido em:
- Introdução: no qual é introduzido os detalhes gerais sobre a visão do projeto;
- Posicionamento: descrevendo o problema e a oportunidade de negócio;
- Descrições dos Envolvidos e dos Usuários: esta seção descreve o perfil das partes interessadas no projeto;
- Visão Geral do Produto: Esta seção fornece uma visualização de alto nível das capacidades do produto, interfaces para outros aplicativos e configurações dos sistemas;
- Recursos do Produto: breve descrição dos recursos do produto;
- Restrições: as restrições de design, restrições externas, como requisitos operacionais ou regulamentares;
Atualmente, um profissional de saúde usa uma quantia considerável de tempo em uma consulta escrevendo uma prescrição. O paciente também pode acumular muitas receitas e gerenciá-las pode se tornar trabalhoso.
Nosso projeto oferecerá uma automatização da geração de prescrições e possibilitará que o paciente entre em contato com o profissional de saúde numa eventual necessidade de acompanhamento ou esclarecimento de dúvidas.
Para o profissional de saúde a aplicação oferecerá uma gama de ferramentas para criar, organizar e gerir prescrições, pacientes e medicações utilizadas.
| O problema de | redigir receitas manualmente |
|---|---|
| afeta | o tempo da consulta e o controle do histórico do paciente |
| cujo impacto é | o prolongamento do tempo de consulta |
| uma boa solução seria | um sistema que auxilia na criação e controle das prescrições. |
| Para | profissionais de saúde e pacientes |
|---|---|
| Que | necessitam de uma ferramenta que auxilie no gerenciamento de prescrições de profissionais de saúde |
| O Receituário Médico | é um sistema |
| Que | faz o gerenciamento de prescrições e fornece uma interface de contato entre o profissional de saúde e o paciente |
| Diferente de | prescrições manuais e aplicações como Euprescrevo e Docsnote |
| Nosso produto | é uma solução que une as funções de prescrever e manter o contato com o paciente. |
| Nome | Descrição | Responsabilidade |
|---|---|---|
| Equipe de Desenvolvimento | Estudantes da disciplina Métodos de Desenvolvimento de Software da FGA. | Desenvolvimento, Testes, Documentação e Implementação do Software. |
| Equipe de Gestão de Processo | Estudantes da disciplina Gestão de Portfólios e Projetos de Software da FGA. | Gerir o desenvolvimento do produto identificando problemas e apontando caminhos e soluções. |
| Cliente | Médico pediatra formado pela UnB, Especialista em Medicina do Adolescente pela UnB, Especialista em Medicina Esportiva pela Universidade Federal de São Paulo. | Esclarecer os requisitos e validar o software. |
| Coachs | Estudantes da UnB, monitores da matéria de GPP e MDS. | Auxiliar as equipes de GPP e MDS durante o desenvolvimento do projeto. |
| Professora | Professora na Universidade de Brasília, no campus FGA, atual professora das disciplinas MDS e GPP. | Avaliar e Auxiliar os estudantes das matérias de GPP e MDS. |
| Nome | Descrição |
|---|---|
| Paciente | Pessoas que buscam atendimento médico. |
| Médicos | Todos os profissionais de saúde que utilizam a plataforma. |
O sistema será utilizado nos browsers Google Chrome, Safari, Internet Explorer, Firefox, Opera e Edge.
| Representante | Felipe Borges de Souza Chaves, Guilherme Marques Moreira da Silva, Lucas Hiroshi Horinouchi, Lucas Kishima dos Santos, Mateus Nascimento Nóbrega, Michel Martins de Camargo, Natália Maria Rodrigues Queiroz. |
|---|---|
| Descrição | Desenvolvedores. |
| Tipo | Estudantes da FGA da disciplina MDS. |
| Responsabilidade | Desenvolvimento, Testes, Documentação e Implementação do software. |
| Critérios de Sucesso | Finalizar o desenvolvimento e realizar entrega do software em tempo estipulado. |
| Envolvimento | Alto. |
| Problemas/Comentários | A equipe é inexperiente na linguagem de programação utilizada no desenvolvimento, no padrão arquitetural e nas metodologias de desenvolvimento. |
| Representante | João Paulo Nunes Soares, Marcelo Augusto Araújo dos Reis, Ronyell Henrique dos Santos, Thiago Nogueira Freire. |
|---|---|
| Descrição | Gerenciamento de projeto. |
| Tipo | Estudantes da matéria GPP da FGA. |
| Responsabilidade | Gerir o desenvolvimento do produto identificando problemas e apontando caminhos e soluções. |
| Critérios de Sucesso | Manter a equipe focada no projeto, gerência dos riscos associados ao projeto e finalizar o desenvolvimento do projeto. |
| Envolvimento | Alto. |
| Problemas/Comentários | Eles podem não serem familiarizados com a utilizaçao de plataformas o nosso projeto deve levar em conta isso. |
| Representante | Getúlio Bernardo Morato Filho |
|---|---|
| Descrição | Médico formado pela UnB, Especialista em Medicina do Adolescente pela UnB, Especialista em Medicina Esportiva pela Universidade Federal de São Paulo. |
| Tipo | Cliente idealizador do projeto com grande interesse no seu desenvolvimento. |
| Responsabilidade | Estabelecer os requisitos e validar o software. |
| Critérios de Sucesso | Conseguir passar de maneira clara os requisitos. |
| Envolvimento | Alto. |
| Problemas/Comentários | - |
| Representante | Pacientes. |
|---|---|
| Descrição | Pessoa que busca atendimento médico. |
| Tipo | Usuário que tem interesse em obter melhor atendimento. |
| Responsabilidade | - |
| Critérios de Sucesso | Acesso aos receituários médicos e comunicação constante com o médico. |
| Envolvimento | Alto. |
| Problemas/Comentários | Possuem faixas etárias diferentes. Eles podem não serem familiarizados com a utilizaçao de plataformas. |
| Representante | Médico |
|---|---|
| Descrição | Formados em Medicina, usuários do software. |
| Tipo | Formados em medicina. |
| Responsabilidade | - |
| Critérios de Sucesso | Gerenciar receituários, exames dos pacientes de maneira eficiente e fazer feedback mais eficiente. |
| Envolvimento | Alto. |
| Problemas/Comentários | A utilização não deve ser complexa e eles podem não estarem familiarizados com a utilizaçao de plataformas online. |
| Necessidade | Interesse | Solução Atual | Solução Proposta |
|---|---|---|---|
| Gerenciar receituários. | Mesclar funcionalidades de sistemas já existentes como DocsNote e Memed para otimizar o gerenciamento. | Ferramentas que possibilitam gerenciar o receituário, passar receitas. | Integrar funcionalidades de gerenciamento de receituários e de comunicação com paciente. |
| Comunicar com o médico. | Sistema de mensagens para facilitar a comunicação com o médico. | DocsNote, ferramenta que permite a comunicação entre cliente e médico. | Integrar funcionalidades de gerenciamento de receituários e de comunicação. |
O EUPRESCREVO é um sistema website gratuito que tem como objetivo a prescrição segura, legível e integrada com todos os sistemas de gestão de saúde e de farmácias.
O projeto Memed é um sistema web, android e ios gratuito para prescrição de receitas que tem como objetivo garantir que sejam receitados remédios com a maior perfeição para o paciente. A plataforma preza pela gratuidade do serviço e pela infraestrutura de entre médico, paciente e farmácia.
O DocsNote é um webapp para facilitar a comunicação entre pacientes e médicos que simplifica consultas médicas e diagnosticos de doenças.
O sistema irá oferecer uma plataforma de interação entre profissional de saúde e pacientes através de uma sistema web. O usuário profissional da saúde contará com ferramentas que irá auxiliá-lo a criar receitas, analisar como é usualmente tratado doenças por outros profissionais de saúde e se comunicar com seus pacientes, enquanto o usuário paciente terá acesso a suas receitas e contato com seu médico de forma rápida.
O sistema oferece as seguintes funcionalidades aos usuários:
-
Gerenciar e manter usuários: tanto os profissionais da saúde quanto pacientes poderão ser cadastrados no sistema, de forma que consigam adicionar, remover e alterar informações dos seus perfis;
-
Facilitar, para o profissional de saúde, a prescrição de medicamentos e exames, e a realização de orientações quanto ao que foi prescrito a seus pacientes, utilizando de sugestões de texto inteligentes;
-
Otimizar o tempo gasto pelo usuário profissional da saúde ao fazer todas as orientações aos pacientes, em cada receita;
-
Disponibilizar ao profissional da saúde as informações referentes a cada paciente cadastrado;
-
Possibilitar ao profissional da saúde a criação de um padrão personalizado de receita, fazendo com que as prescrições e orientações mais utilizadas possam ser sugeridas ao profissional no momento da geração de novos receituários;
-
Permitir a realização de pesquisas sobre medicamentos, exames e receitas prescritas por outros profissionais, viabilizando que os receituários tenham alcance em regiões distintas do país e facilitando, assim, a integração dos responsáveis por gerar os receituários;
-
Dar ao profissional de saúde a possibilidade de marcar como favoritas receitas já prescritas;
-
Permitir que o profissional de saúde convide pacientes para ter acesso à plataforma e participe do círculo de comunicação;
-
Oferecer suporte aos pacientes, com possibilidade de gerar feedbacks sobre atendimentos, medicações e comunicação direta entre os profissionais de saúde e paciente;
-
Garantir o acompanhamento de todas as receitas por parte dos pacientes;
-
Permitir que o paciente envie exames ao profissionais de saúde, de acordo com o que se fizer necessário.
6. Restrições
O design será elegante e simples, pensado ao pormenor, onde apenas o essencial tem lugar à vista.
O sistema será desenvolvido utilizando a linguagem Python e o framework Django. Além disso, o sistema será desenvolvido com base no modelo de arquitetura conhecido como MTV que é considerada uma variação do MVC.
O sigilo entre médico-paciente é um dos mais tradicionais preceitos morais da assistência em saúde, baseado nisso o sistema deve assegurar ao paciente a não exposição de circunstâncias de sua vida pessoal. O sigilo, nesse contexto, funciona como mecanismo de proteção ao paciente, logo, as informações do paciente como exames, diagnósticos e receitas só estarão disponíveis para seu médico.
Para o uso do sistema é necessário que o usuário tenha acesso a um dispositivo conectado à internet e que possua um navegador web compatível com o sistema. Caso o usuário do sistema não possua acesso à internet, o sistema deve mostrar uma página de erro.
