Requisitos de CC - SR1

1) Aquisição e análise inicial dos dados.

Identificar Problema:

"Como trabalhar com grandes volumes de dados de forma centralizada visando apresentar informações úteis para melhorar as estratégias da empresa"

Levantamento e definição da base de dados:

O dataset retrata atestados médicos que a SafeCare é encarregada de fazer a intermediação entre o colaborador/paciente e a empresa do colaborador. A base de dados foi gerada por código por meio da dependência Faker da linguagem Python. As colunas bem como o formato dos seus valores foram baseados nos dados verdadeiros que a SafeCare possui. Essas são as colunas do dataset gerado: 

1. Nome: nome do colaborador

2. CPF: CPF do colaborador

3. Data: data em que o atestado foi emitido

4. Unidade Atendimento: Nome do Hospital, clínica ou outro departamento médico,

5. Nome Prescrito: nome do médico que prescreveu o atestado,

6. CRM: CRM do prescritor,

7. Tempo: tempo em dias de afastamento do colaborador,

8. Hora de Entrada: hora da entrada do paciente,

9. Hora de Saída:hora da saída do paciente,

10. CID: Classificação Estatística Internacional de Doenças e Problemas Relacionados com a Saúde,

11. Aceito: se a empresa aceitou o atestado ou não,

12. Observação: observação,

13. Origem: SUS, Hospital Particular, clinica, etc

14. Recepção: recepção,

15. Especialidade: especialidade médica.

Foi criada uma lógica para que uma probabilidade do atestado ser aceito ou não fosse calculado durante a geração das linhas. Sendo assim, essa probabilidade foi usada para definir o valor da coluna ‘Aceito’.

Infelizmente, para o SR1 não foi possível a utilização de uma base de dados do cliente, devido a limitações de comunicação com o cliente que geraram falta de tempo para que o processo de obtenção dos dados fosse realizado. Para o uso da própria base de dados da SafeCare seria necessário um processo contratual que se tornou inviável para o contexto do SR1. Porém é visado o uso da base de dados da SafeCare para o SR2.

Hipóteses:

1. Podem existir CIDS (especialidades médicas) que devido a sua gravidade e impacto podem gerar mais atestados aprovados. Exemplos: atestados de cardiologia podem ser considerados mais graves que atestados dermatológicos.

2. Um tempo de afastamento muito grande provavelmente terá mais chance de ser reprovado

Análise descritiva e diagnóstica:

Essa análise vai mudar quando o grupo tiver acesso aos dados do cliente 

A correlação foi fraca porque os dados foram gerados aleatoriamente, eles não tiveram relação, a única exceção foi CID e Aceito pois definimos a partir da gravidade do CID a probabilidade de uma pessoa ser aceita ou não. 

Definir métricas de desempenho:

 Foi utilizado as métricas de classificação mais populares em todos os modelos, a Acurácia, Precisão, Recall e F1-Score

Resultado das métricas no KNN:

O resultado foi o esperado, valores baixos por causa do problema da geração dos dados, que faz com que a correlação entre as colunas tendam a 0.

2) Aplicação de Machine Learning.

Aplicação de um técnica básica de ML: 

Aplicar um modelo K-NN para descobrir se o atestado é aceito ou não.

Documentação das análises:

Resultado do KNN

(o link para o colab esta na seção de links do relatório)

3) Proximas etapas

1. Passar pelo processo contratual e adquirir a base de dados da SafeCare.

2. Começar o processo de centralização dos dados.

3. Refazer as análises e hipóteses com a base de dados verdadeira.

4. Possivelmente remodelar o nosso modelo ML.