Análise Exploratória de Dados de Saúde com Python: 10 passos

Até agora, em minhas postagens, nos restringimos a temas de alta carga teórica, que nos exigiram discussões mais aprofundadas. De fato, não conseguiremos e nem queremos fugir dessas digressões, sob o risco de sermos rasos, afinal, "sem teoria, a ciência de dados é apenas sobre memes de gatos".

Por outro lado, uma das principais intenções da criação do blog é também exercitar um pouco de código, mostrando para vocês o dia a dia de um médico que também "coda", na ideia de que esse exemplo também motive, de algum modo, todos aqueles que já estão na interface saúde-dados e precisam apenas de um "empurrãozinho" para evoluírem nessa jornada.

Pois bem, a postagem de hoje vai nesse sentido: Análise Exploratória de dados ou, do inglês, Exploratory Data Analysis (EDA).

EDA: O que é?

Termo, ao que parece, cunhado pelo proeminente matemático americano, John Tukey, a Análise Exploratória de Dados se refere a um conjunto de abordagens técnicas para melhor compreender os dados que se têm em mãos, a fim de, por exemplo:

• Definir o significado das variáveis (Features);
• Identificar o tipo dos dados (String, Integer, Float, etc);
• Concluir sobre a quantidade de valores únicos de cada feature;
• Quantificar o total de entradas;
• Conhecer a proporção de entradas não nulas e de entradas nulas (missing);
• Descrever estatisticamente as features (Média, Mediana, Moda, etc);
• Sublinhar os valores considerados discrepantes (Outliers);
• Realizar a análise univariada, bivariada e multivariada

‘Exploratory data analysis’ is an attitude, a state of flexibility, a willingness to look for those things that we believe are not there, as well as those we believe to be there.” Jonh Tukey

EDA: Por quê?

Muitas vezes subestimada, a análise exploratória é justamente a primeira coisa que você deve fazer ao se deparar com qualquer conjunto de dados. Pular esse estágio, ou fazê-lo de forma displicente (como pode acontecer se você utilizar recursos como a biblioteca profiling sem muita atenção), pode levá-lo a incorrer, de forma ingênua, em conclusões erradas. Por isso, nunca negligencie essa etapa!

EDA: Onde se situa?

Antes de iniciar uma nova análise exploratória de dados, é importante termos uma visão panorâmica do ciclo de vida de projetos de ciência de dados, a fim de localizar onde se situa a EDA. Para tanto, tomemos o modelo CRISP-DM (CRoss Industry Standard Process for Data Mining), que tradicionalmente define seis etapas:

Pela imagem, podemos depreender alguns conceitos:

1.Tudo gira em torno de dados: Por mais óbvio que seja, o insumo para ciência de dados são dados! No entanto, às vezes, simplesmente não temos os dados at all, o que demandará esforços de gerá-los, antes de qualquer coisa. A importância de sistemas de input estão aqui (em outras oportunidades comentaremos sobre o papel de sistemas como prontuários para o contexto da saúde nesse quesito).

2. Iteração: A ciclagem repetitiva do processo agrega conhecimentos não existentes nas primeiras passagens. Dessa forma, a próxima repetição pode ser muito mais bem informada pelos aprendizados adquiridos.

3. Compreensão do negócio: Repare que essa é uma das primeiras etapas, que serve de fio-condutor para as demais. Por isso, sem formular claramente o problema de negócio e o objetivo-alvo, todo o projeto pode se perder sem um rumo. Ora, ninguém melhor para compreender o negócio do que aquele que o vive, na pele. É aqui que o médico cientista de dados se sobressai, como falamos em nossa primeira postagem.

4. Compreensão dos dados: É justamente aqui que se situa a EDA. Lembre-se que os dados são nossa matéria-prima, e, se vamos extrair dela nosso produto final, precisamos conhecê-la a fundo.

5. Preparação dos dados (Data Wrangling ou Data Mongering): para a tristeza dos cientistas de dados, nem todo dataset na vida real é limpo e organizado como aqueles das competições do Kaggle, que por conveniência utilizaremos hoje em exemplo de EDA. Pelo contrário, a maioria dos dados, sobretudo no contexto da saúde, tem vários problemas de qualidade e nos obrigarão a passar a maior parte do tempo os limpando e preparando para uma correta análise.

EDA: Como?

Para ilustrarmos na prática como empreender uma EDA, utilizaremos o seguinte conjunto de dados: Medical Appointment No Shows. Para nos acompanhar, você também pode baixar o dataset e seguir o passo a passo:

Passo 1. Defina o significado dos dados:

Idealmente, o conjunto de dados fornecido deveria vir sempre acompanhado de um dicionário, que o explique minimamente (Data Request Document, os famosos DRD, são especialmente úteis para isso). No entanto, sabemos que esse ideal nem sempre é o que acontece, pois a maturidade em dados das empresas é um processo longo e gradual.

‍

Em todo o caso, ter contato com um Subject-Matter Expert (SME) que elabore uma explicação dos dados pode ser valioso (e aqui mais um ponto para o médico cientista de dados, já que, na prática, você mesmo será o SME).

No nosso caso, o próprio Kaggle nos fornece essa informação:

• PatientID: identificador exclusivo de um paciente
• AppointmentID: um identificador exclusivo de um agendamento
• Gender: identifica o sexo do paciente
• ScheduledDay: dia em que o paciente solicitou um agendamento
• AppointmentDay: dia em que a consulta foi marcada
• Age: identifica a idade do paciente.
• Neighbourhood: pelo que entendi, trata-se do endereço do local de atendimento
• Scholarship: identifica se o paciente é estudante com bolsa de estudos
• Hipertension: identifica se o paciente tem histórico de hipertensão
• Diabetes: identifica se o paciente tem histórico de diabetes
• Alcoholism: identifica se o paciente tem histórico de alcoolismo
• Handicap: identifica se o paciente é portador de alguma deficiência
• SMS_received: identifica se o paciente recebeu um lembrete por SMS
• No-show: é o nosso target ou variável-alvo, identificando se ocorreu ou não falta do paciente à consulta

Passo 2. Defina seus objetivos:

Agora, tendo em mente o significado das variáveis, o próximo passo é se perguntar: O que é possível encontrar nesse dataset? Nesse sentido, como costuma dizer nosso CEO, da 3778, Guilherme Salgado: faça perguntas inteligentes para os dados, procure levantar hipóteses plausíveis que fazem sentido investigar em sua exploração.

Para o nosso exemplo, seriam perguntas interessantes de se fazer:

• Quantos faltas ocorreram ao todo?
• Qual é a proporção de atendimentos com no-show frente ao total?
• Quantos pacientes geraram no-show? São poucos ou muitos?
• A idade ou o sexo do paciente influencia na sua disposição para cometer um no-show?
• Será que o dia da consulta é o que mais influencia? Por exemplo, sendo sexta-feira um dia de maior falta?
• Ou será que a data do agendamento tem alguma influência na ocorrência do no-show? Por exemplo, o fato de agendar muito antes da consulta pode contribuir?
• Se existe um aviso com SMS, a ocorrência do no-show diminui? Vale a pena gastar o dinheiro do SMS para diminuir o no-show?
• E se os pacientes têm alguma doença, eles se mostram mais comprometidos a não faltar na consulta? Ou seria o contrário?

A lista aqui não foi exaustiva e, por isso, não está completa. Procure você mesmo, com criatividade, ampliá-la com perguntas adicionais.

Passo 3. Prepare seu ambiente de trabalho

Agora, mãos à obra! Para tanto, ligue o seu ambiente de desenvolvimento preferido. No meu caso, trabalhando com a stack da Google, gosto muito do Google Colab para a intenção de análises Ad hoc. A grande vantagem do colab é que, de pronto, já temos praticamente tudo pré-instalado na máquina virtual, de modo que não é necessário você realizar muitas instalações manuais.

Para o nosso propósito, as principais instalações seriam as seguintes:

Particularmente, eu prefiro deixar todas as importações em apenas uma cédula de código, no início do notebook, para minha organização. Embora isso pareça um toque, facilitará muito em projetos mais extensos ou quando você precisa dialogar com outros membros da equipe.

Passo 4. Importe os dados

Os dados do Kaggle foram disponibilizados no site em formato CSV. Baixe o conjunto de dados e importe-os diretamente no seu notebook ou hospede dentro do seu Google Drive, que se liga facilmente ao Google Colab, como ilustra o vídeo abaixo:

‍

Passo 5. Descreva o perfil dos dados

Lembre-se dos objetivos gerais de uma EDA: identificar o tipo dos dados; concluir sobre a quantidade de valores únicos de cada feature; quantificar o total de entradas; conhecer a proporção de entradas não-nulas e de entradas nulas; e descrever estatisticamente as features. Felizmente, isso pode ser feito com poucas e simples linhas de código, veja só:

Assim, de cara, já sabemos o tamanho do nosso dataset (110527 linhas e 13 colunas), o número de nulos por coluna (felizmente 0 nulos) e o tipo de dado em cada coluna. Para conferir, dê uma espiada no dataset:

Passo 6. Preparando os dados

No entanto, nessa pequena espiada já percebemos algumas questões que tem de ser resolvidas. O id paciente e o id atendimento estão sendo entendidos como valores numéricos, o que é um problema clássico. Além disso, as datas de agendamento e consulta estão sendo entendidas como texto, o que impede que façamos alguma inteligência de tempo sobre elas.

Para resolver esse problema, podemos simplesmente converter os valores:

A fim de deixar o código mais rápido, você também pode converter várias colunas de uma vez, veja só:

Outra alternativa (tenha em mente que, no mundo da programação, não existe exatamente certo e errado, existem caminhos que você opta por seguir, baseado no tempo disponível, na experiência, nas diretrizes do local de trabalho e, sobretudo, no conhecimento que você vai adquirindo sobre boas práticas e atalhos) é já fazer conversões logo ao importar o dataset, com parâmetros passados para o método read_csv (sempre recorra à documentação, está tudo lá!) :

Mas temos mais coisas a arrumar. Será que, mesmo em um dataset do Kaggle, teremos algum input ilógico de dados? Não deixe de investigar ativamente, supondo que não. Por exemplo, uma data de consulta antes da data de agendamento seria algo estranho, não é mesmo?

‍

Por fim, uma transformação que considero interessante é ajeitar o nome das features (a nomenclaturização de variáveis deve ser bem pensada e acordada em convenção, para manter a consistência do projeto e assim torná-lo facilmente inteligível) :

Passo 7. Engenharia de features

Passemos agora para a engenharia de features (Feature engineering), que, de forma resumida, consiste em aproveitar os dados existentes para criar novas variáveis que não estão originalmente no conjunto de dados. Particularmente, essa é uma das partes que mais gosto.

Novamente, aqui conhecimento panorâmico da área de saúde, conferido por uma formação em medicina, mas sobretudo por uma formação em Medicina de Família e Comunidade, permite que derivemos várias features, veja como:

Novamente, a lista aqui não foi exaustiva e, por isso, não está completa. Procure você mesmo, com criatividade, ampliá-la com features adicionais.

Passos 8. Lidando com valores ausentes

Já tínhamos visto que, felizmente, o conjunto de dados não possui nenhum valor nulo. Isso nos economizará essa etapa. No entanto, em próximas oportunidades, nos dedicaremos exclusivamente a ela, dada sua importância.

Passos 9. Lidando com valores outliers

Essa passo também é um capítulo a parte. Também reservaremos uma postagem inteiramente dedicada e ela, dada sua importância.

Passos 10. Análise descritiva

Feitas todas essas etapas, pronto: estamos aptos a começar a explorar nossas hipóteses levantadas.

• Qual é a proporção de atendimentos com no-show frente ao total?

‍

Ora, será que é isso muito ou pouco? Que tal darmos uma olhada no que nos diz a literatura para termos uma parâmetro de comparação.

• Quantos pacientes geraram no-show? São poucos ou muitos?

Pelo histograma, já vemos que temos alguns pacientes que se destacam. Quando formos fazer oportunamente nossa análise de outliers, iremos nos debruçar sobre eles. Mas, de antemão, será que vale pensar em alguma abordagem específica para esses pacientes ou será que devemos ignorar essas exceções e nos concentrar no "grosso" dos pacientes?

Desde a análise exploratória, lembre-se que não estamos fazendo isso tudo por fazer: a ideia é sempre tomar alguma ação data-driven.

• Será que o dia da consulta é o que mais influencia? Por exemplo, sendo sexta-feira um dia de maior falta?

• Ou será que a data do agendamento tem alguma influência na ocorrência do no-show? Por exemplo, o fato de agendar muito antes da consulta pode contribuir?

‍

Ora, a saúde é uma das áreas mais complexas que existe! São vários fatores interagindo de forma não facilmente perceptível para os raciocínios incautos da mente humana, muitas vezes acostumados a simplificações e atalhos sujeitos a muitos vieses cognitivos. Dessa forma, assim como no consultório é difícil observar sinais patognomônicos, também nos dados em saúde será difícil encontrar variáveis explicativas absolutas. Nesse sentido, será que vale tentarmos modelar as variáveis para, em conjunto, tentar melhor explicar ou, quem sabe, predizer a probabilidade de falta de um paciente?

EDA: Resumindo

Fizemos uma pequena exploração de dados de agendamento de consultas, apenas a título de ilustração de uma EDA com python. Naturalmente, muitas outras visualizações exploratórias seriam possíveis. Que tal você mesmo executá-las?

‍
O código, para você complementar, eu deixo para você aqui no meu perfil do GitHub:
‍
https://github.com/gregrodrigues22/python_eda/blob/main/EDA_Blog.ipynb