---
# System prepended metadata

title: SmartScreening (SS) - Jornada do Paciente
tags: [SmartScreening]

---

---
title: SmartScreening (SS) - Jornada do Paciente
description: Visão macro da jornada do paciente para o alinhamento de expectativas com a Unimed
tags: SmartScreening
---

# Visão macro da jornada do Paciente
![](https://i.imgur.com/DzPyt4Y.png)





# Entrega de valor e alinhamento de expectativas

## Preâmbulo com considerações e alinhamentos
1. Com base no que foi desenvolvido ou verificado até o momento é possível fazer algumas constatações e alinhamentos sobre o que acreditamos ser possível entregar como produto conforme levantamento inicial feito no plano de projeto;
2. Consideramos não ser viável ou possível executar o protocolo de Manchester (ou qualquer outro sistema de classificação de riscos) de forma automática dentro do aplicativo do terminal SS pelas seguintes justificativas:
    2.1 No Manchester existem vários fatores e discriminadores que são baseados na observação do médico ou enfermeiro quando está sendo feita a classificação. Tentar fazer isso de forma automática não é possível, pois não existe método validado para que o paciente faça a autoclassificação;
    2.2 A auditoria do Manchester certamente não vai autorizar uma classificação que não seja feita pelo profissional habilitado operando os fluxos exatamente como está estabelecido pelo padrão Manchester.
    2.3. Como já existe um módulo do MV Soul que já faz a classificação Manchester, a solução agregará mais valor para a Unimed se existir uma integração entre o SS e o aplicativo da MV no sentido de agilizar ou automatizar parte do processo (de coleta de alguns sinais vitais) de classificação. Além disso, na classificação será possível fazer a correção ou ajuste de algum dado que o paciente preencheu errado no SS. Por exemplo, quando for perguntada a religião a pessoa pode escolher errado e isso é um aspecto importante que a Unimed precisa saber;
* Para automatizar os processos burocráticos será preciso fazer algumas perguntas adicionais no SS. No momento da classificação será importante e possível fazer ajustes de forma rápida e objetiva, evitando problemas ou transtornos caso o paciente tenha escolhido uma opção errada no SS.
* Todo o processo ou proposta de valor inserida pelo projeto do SS deve ser adicional e opcional, pois caso o terminal SS não funcione em algum momento a rotina do PS deve seguir normalmente sem afetar o fluxo normal. A substituição definitiva de componentes ou elementos da jornada do paciente será tratada em um momento pós projeto.
4. As integrações irrestritas e sem bloqueios entre o SS e as APIs da MV e NucleOS são pontos chaves para as entregas de valor do projeto. O que será possível fazer a mais ou a menos está diretamente ligado à disponibilidade das APIs e boa vontade da MV e NucleOS.
5. Vamos nos preparar para que não haja problemas em relação à ordem da jornada do paciente definida pela Unimed. Por exemplo, se após o SS o paciente vai direto para a classificação ou para a Burocracia deve ser um aspecto dinâmico e flexível, para não alterar ou impactar em possíveis mudanças que a Unimed possa fazer no fluxo de atendimento.

# proposta de valor e benefícios inseridos/afetados pelo projeto

## 01 Ticket no terminal da MV
* No futuro (pós projeto) esse terminal pode ser totalmente substituído pelo SS, mas por medidas de segurança o terminal da MV deve continuar disponível durante todo o projeto como um plano B em caso de qualquer problema, pois tudo deve continuar funcionando normalmente em caso de parada do SS;
* O Ticket inicia o processo de filas de atendimento no MV e guia toda a jornada do paciente. Portanto, precisa existir esse processo como já é feito hoje para permitir o incremento gradual da proposta de valor do projeto.

## 02 Terminal SmartScreening
* Será feita a coleta dos sinais vitais conforme previsto no plano de projeto, mas haverá um incremento gradativo dos sinais medidos. O refinamento das acurácias dos dispositivos (sensores) requer o hardware adequado para isso.  
* O atraso no recebimento do hardware solicitado impacta diretamente nos resultados, pois os dispositivos usados pela Multicast não possuem as acurácias adequadas para os resultados desejados. Estamos trabalhando e buscando alternativas para minimizar os impactos dos atrasos no recebimento do hardware solicitado, mas os resultados esperados dependem do hardware adequado que estamos aguardando.
* O design físico do terminal está sendo feito pelo Instituto Senai (ISTEO) conforme definido no termo de cooperação técnica.
* Foi desenvolvida pela Multicast uma versão inicial do aplicativo/interface que vai ser executada no terminal (Totem do SS). O ISTEO vai dar continuidade ao desenvolvimento dessa aplicativo conforme definido no plano de projeto.

## 03 Classificação de risco
* Agilizar o processo da classificação de risco;
* Aproveitar esse momento para validar alguns dados importantes com o apoio do profissional da Classificação. Ou seja, aproveitar esse momento para um double check de alguns dados e corrigir se for o caso.
* Quebrar paradigmas sobre a conferência integral de dados que já estão no sistema da Unimed. A validação deve existir apenas para dados vitais ou estratégicos no momento da classificação. Exemplo, confirmar a queixa do paciente relacionada à opção escolhida no terminal da MV ou SS (a proposta é que o SS tenha as mesmas opções do MV). Confirmar o número de telefone, religião, escolha de especialidade e se o paciente escolheu corretamente retorno ao pronto socorro. 
* Durante um determinado tempo e conforme a solução vai evoluindo será necessário ter um aplicativo web para que o Classificador (enfermeiro ou médico) faça: (i) a digitação dos dados aferidos pelos equipamentos de medição dos sinais vitais; (ii)digitar o número do ticket (senha); (iii) confirmar ou corrigir dados. Por exemplo, se o paciente selecionou errado a religião o classificador poderia corrigir esse dado.
* Futuramente, a proposta é que esse aplicativo não exista mais, pois essas opções podem ser feitas no próprio módulo de classificação do MV soul.
* A proposta é manter essa funcionalidade durante todo o projeto, pois precisamos validar e ajustar as acurácias das medições feitas no SS.

## 04 Burocracia
* A proposta é que (em um determinado momento) a burocracia exista apenas quando necessário ou quando for uma situação específica. Por exemplo, quando não tem a carteirinha da Unimed ou é um atendimento particular.
* A partir do momento que tivermos uma comunicação efetiva com o NucleOS e o MV pode ser possível criar a  da ficha de atendimento do paciente, incluindo a autorização da consulta.


## 05 Atendimento médico
* Se a integração com a MV estiver funcionando bem e tivermos o apoio ou interesse da MV sistemas poderemos agregar ainda mais valor com o envio de todos os dados coletados para a ficha do paciente que o médico consulta.
* Com isso o médico terá acesso a tudo que foi medido ou avaliado previamente, evitando que ele tenha que aferir novamente algum dado ou sinal vital.

