dTool - Levantamento de requisitos
Stakeholders: Ana Paula (http://lattes.cnpq.br/2142304563601810, eng. produção) e ? (?, eng. elétrica)
Análise econômica na área da saúde

**Problemática:**
- Estudos de custos, coleta de dados para alimentar modelos de custos
- Descobrir e avaliar o custo do tratamento de cada paciente (não se sabe o custo do tratamento de uma gripe, por exemplo)
- O que fazem: entender tudo o que acontece com o paciente quando chega ao hospital
- Observação do consumo dos recursos da instituição por um paciente
- Quanto tempo um profissional leva para realizar uma atividade
- Quanto do salário de um profissional está sendo alocado para um paciente específico
    - consumo de estruturas, materiais, insumos
    - tempo do profissional

Dados de visita têm no prontuário eletrônico (exames, consultas, cuidados da enfermagem (banho, medicamentos))
O que não tem no prontuário: dados de tempo
Materiais: atualmente não usado, um dado que já pode ser obtido de outras formas com o hospital
Antes: alunos bolsistas marcando tempo (do lado, com um cronômetro)
Estado atual: custeio do tratamento de AVC? (?)
- Tem protótipos e aplicativo iniciado
- Android e iOS, Ionic (desenvolvido por um dos stakeholders)
- Usado por 9 instituições

**Objetivo:**
- Uso pelos próprios profissionais de saúde
- Simplificar o máximo possível para que os profissionais usem
- Nem sempre no dispositivo pessoal do profissional, nem sempre com internet

**Passos:**
1. Mapeamento de todos os passos
    1. Ex.: AVC (curativo, sonda, …)

**Requisitos funcionais:**
- Múltiplas instituições
- Coletar tempos por atividades e custo por profissional, emissão de relatórios
- Mapeamento prévio das atividades
- Coleta de vários pacientes e profissionais ao mesmo tempo
- Uso pelo profissional e bolsista
- Visualização dos resultados pelos profissionais (para gerar engajamento no uso do aplicativo)
- Relatórios acessados pelos gestores
- Relatórios "rápidos" (gráficos) -> informações relevantes (tempos da enfermagem para os enfermeiros)
- Sem identificação do profissional
- Processos com passos diferentes dependendo do profissional
- SONHO DE CONSUMO: único fluxo de cadastro de processos
- Cada instituição tem variação nas atividades
- Fluxos variam mesmo entre diferentes equipes na mesma instituição
- Fluxos podem ramificar (mas podem ficar zerados)
- Matriz (fluxo) sempre é apresentada da mesma forma durante a tomada de tempos
- Processos cadastrados pelos gestores (ou quem está interessado nas informações)
- Paciente muda de hospital: "quebra" (dados financeiros diferentes) -> trabalhar da entrada a saída da mesma instituição
- Sem levantamento de materiais (já tem como obter com o hospital)
- Quem atende quem, fazendo o quê, início e término
- Saída: mediana do tempo levado para fazer uma atividade
- Tablet beira-leito, paciente único, múltiplos profissionais
- Profissional pode realizar múltiplas atividades ao mesmo tempo
- Deixar cancelar a medida de tempos (ligar o cronômetro e cancelar), zerar cronômetro
- Não é problema deixar um enfermeiro ver atividades de outras áreas, mas os relatórios tem que ser restritos
- Sabem a fonte dos dados (o device), mas não sabe o profissional em si
- Exportar para CSV ou algo do tipo (bem importante)
- Seleção inicial de instituição (código do projeto, pelo app atual) e categoria (enfermeiro, …)
- Segurança (SUPER IMPORTANTE)
- Não precisa ver o cronômetro, mas sim que ele está rodando para uma atividade específica
- Não deixar fazer a mesma atividade duas vezes no mesmo uso (inicia, finaliza, envia, limpa o quadro e inicia novamente)
- Infos do paciente: prontuário, iniciais e sexo
- Infos do profissional: apenas o código do projeto/instituição e categoria (enfermeiro, …)
- Forma simples de inserir matriz profissionais x processos/atividades
- Import de dados pelo celular? (acho que não)

**Usuários:**
- Stakeholders (gestor admin) -> criar instituições (talvez?), criar processos, ver relatórios de todas as instituições
- Gestor da instituição -> criar processos, ver relatórios de todas as áreas
- Profissionais -> entrada de dados de múltiplos pacientes
- Bolsistas -> entrada de dados de múltiplos pacientes e de múltiplos profissionais

**Requisitos não-funcionais:**
- Funcionar online e offline
- Desempenho (ambiente de hospital, correria, agilidade)
- Grande entrada de dados

- Definição de fluxo-base do app (diagrama)
- Definição da comunicação com os AGES II
- Considerar usar Firebase como banco de dados e “backend” (Cloud Functions) para evitar o desenvolvimento de uma API com NodeJS

### Sobre a plataforma web:
- Primeiro focamos no desenvolvimento do app e API (se aplicável) se avaliarmos que o app está “encaminhado” e teremos tempo, podemos começar a desenvolver uma plataforma web simples, para uso dos stakeholders e gestores das instituições; 
- Para acelerar o desenvolvimento da plataforma web, usaríamos templates de dashboards administrativos, já prontos, e daríamos pouca possibilidade de modificação aos stakeholders;
- Se o app demandar um esforço maior do que o previsto, focaremos em completá-lo e adicionaremos as funcionalidades requeridas de gestão (CRUD instituições, importação de processos e exportação de relatórios) no app, com uma UI/UX simplificada;

### Configuração
- Pesquisar possibilidade de usar Docker para facilitar a configuração de ambiente de desenvolvimento

### Dúvidas aos stakeholders:
- Que ações o usuário pode tomar enquanto está cronometrandro o tempo de uma atividade? Pensamos em três ações:
Iniciar contagem: uma atividade sempre inicia pausada. O usuário deve selecionar uma opção “Iniciar contagem” para ativar o cronômetro da atividade;
- Finalizar contagem: uma vez que o cronômetro de uma atividade está ativo, o usuário tem uma opção “Finalizar contagem” para parar o cronômetro da atividade atual e passar para a próxima atividade (sem iniciar o cronômetro da próxima atividade);
- Pular: em qualquer momento, o usuário pode selecionar uma opção “Pular” para passar para a próxima atividade, descartando o tempo decorrido na atividade atual.
- Pensamos nessas ações, com a semântica definida acima. Vocês pensam em alguma ação adicional? Ou em não exibir alguma das ações acima? Ou até mesmo mudar a definição de alguma ação?
- Vocês comentaram que os dados que vocês possuem dos pacientes são: nro. de prontuário, iniciais do nome e sexo. 
- Vocês precisam destes dados no relatório completo dos tempos? Vocês necessitam que as medidas de tempos de procedimentos estejam atreladas a um paciente?

### Próximos passos:
- Bianca: criação do projeto inicial do app com React Native.
- Igor: repassar definições sobre fluxo-base aos AGES II, para início dos mockups; auxiliar com Docker (após contato com AGES II).
- Rafael: pesquisar sobre Docker para facilitar a configuração do ambiente; redirecionar dúvidas aos AGES IV.

[Link para Download](Arquivos/retro-Dtool-0.pdf)