Brasília inteligente e o problema da saúde pública

Por: Marcelo, Heron, Danilo e Hugo

Toda cidade busca sempre proporcionar uma boa qualidade de vida às pessoas que nela residem e na capital do Brasil esse fato não é diferente. De acordo com a empresa americana de consultoria empresarial, Mercer, Brasília é a cidade brasileira onde as pessoas têm as melhores condições para viver. Contudo, essa cidade ainda possui bastantes problemas nas áreas administradas pelo governo local como na área de segurança, transporte e saúde. Tomando como foco o problema no setor da saúde pública, acreditamos que tornar Brasília uma cidade inteligente (smart city) será o melhor caminho para sanar problemas nessa área, que ainda afeta de modo negativo muitos usuários do Sistema Único de Saúde (SUS).

O Distrito Federal ainda possui muitos problemas relacionados ao sistema de saúde pública, como superlotação de pronto-socorros, falta de recursos humanos, atendimento insuficiente e precário, entre outros, como relata o Relatório de Fiscalização de Hospitais Públicos do DF do Ministério Público do Distrito Federal e Territórios (MPFT). Com isso em mente, fomos às ruas fazer uma pesquisa sobre quais eram os pontos negativos de se utilizar o SUS na região. Após recolhermos os dados necessários e após uma análise detalhada das adversidades do sistema de saúde de Brasília, constatamos que o problema das filas de espera nos hospitais ainda é muito comum e acaba afetando de modo negativo a vida dos paciente que esperam por um atendimento decente nesses estabelecimentos. Com isso, decidimos por criar um sistema que irá auxiliar na organização dessas filas de maneira a torná-las mais ágeis e mais organizadas para que, assim, o atendimento aos pacientes ocorra de maneira conveniente, diminuindo um dos maiores problemas no setor da saúde pública de Brasília. Além disso, esse sistema visa integrar diferentes sistemas de informação e automatizar o processamento de dados com o intuito de tornar a cidade mais inteligente, e assim, aumentar a qualidade de vida dos cidadãos.

Smart Cities

O conceito de smart cities, ou cidades inteligentes, se define pelo uso da tecnologia para melhorar a infraestrutura urbana e tornar os centros urbanos mais eficientes e melhores de se viver. As cidades inteligentes fazem o uso intensivo de tecnologias de informação e comunicação focando em três área principais: Internet of Things (IoT), que consiste em conectar os dispositivos eletrônicos utilizados no dia a dia à internet de maneira que tudo possa ser controlado remotamente por um usuário; Big Data, processamento e análise de grandes quantidades de informações; e Governança Algorítmica, gestão e planejamento com base em ações construídas por algoritmos aplicados à vida urbana. Utilizando esses fluxos de interação as smart cities procuram melhorar a qualidade de vida dos cidadãos facilitando a interação das pessoas com os recursos oferecidos pela cidade.

Design Thinking

O Design Thinking é um processo de pensamento crítico e criativo que ajuda na imersão e no entendimento de parâmetros e padrões essenciais para criar projetos de melhor qualidade com boas decisões e melhor organização de informações e ideias. Design Thinking não se trata de uma metodologia mas de uma abordagem. Ele busca solucionar problemas com uma visão ampla e coletiva, envolvendo a perspectiva de todos os stakholders (interessados), todos os envolvidos são colocados no meio do desenvolvimento do produto e não apenas o consumidor final do produto.

O processo também busca mapear as experiências de vivência, cultura e hábitos dos envolvidos de forma que se obtenha uma perspectiva mais completa sobre a situação, partindo de uma abordagem humanizada, antropocêntrica.

O Design Thinking é divido em etapas, caracterizando bem o processo. As etapas que executamos foram:

Imersão: A primeira fase do processo é quando a equipe do projeto identificou os aspectos e contexto do problema em hospitais da rede pública brasiliense. Pode-se perceber vários outros problemas correlacionados por meio da imersão, entrevistas, interações com os pacientes e funcionários do hospital analisando tanto do ponto de vista do usuário final quanto dos outros stakholders envolvidos. A partir desta imersão preliminar, criando o entendimento inicial de quais seriam nossos desafios, houve um aprofundamento em um dos problemas específicos, de forma a identificar necessidades e oportunidades que guiaram a geração de soluções na fase seguinte do projeto.

Organização das ideias levantadas 1

Organização das ideias levantadas 2

Ideação: Com os tópicos de imersão já devidamente documentados, utilizamos técnicas de visualização e organização destas ideias, buscando gerar ideias inovadoras ao tema do projeto, realizando discussões de forma cooperativa na equipe. Foram utilizadas ferramentas de síntese de ideias, estimulando a criatividade por meio da organização de cartões contendo os tópicos absorvidos durante a imersão. Buscamos assim construir soluções criativas de acordo com o contexto que estávamos analisando. Utilizamos das diferentes perspectivas da nossa equipe multidisciplinar (dois membros do curso de Engenharia de Computação, um da Ciência da Computação e outro da Administração) além da expertise de nossa professora mentora e de validações vindas dos contatos que temos com profissionais da área.

Ideacão com dados obtidos

Ideacão com dados obtidos

Ideacão com dados obtidos

Prototipação: Com a ideação já definida, buscou-se realizar várias prototipações, desde a protótipos em papel de baixa fidelidade até protótipos com telas mais complexas e interface semelhante a um sistema web. Nesta fase pôde-se analisar ideias geradas que puderam ser validadas e verificadas. O protótipo ajudou a tornar toda a ideia teórica em um produto mais tangível, do abstrato para o físico por meio de uma representação mais realista. A Prototipação ocorreu de forma iterativa, sempre sendo refeita ao longo do projeto de forma que chegássemos a ideias mais próximas da realidade dos usuários da rede pública e com usabilidade mais apropriada ao contexto em que o produto se encontraria.

Protótipo de Baixa Fidelidade

Protótipo de Alta Fidelidade

Implementação: Foram realizadas diversas validações e testes com os protótipos de baixa e alta fidelidade, modelando de forma que um produto final pudesse se adequar à realidade do problemas que estamos tratando e às necessidades dos usuários. Esta é a fase final em que o projeto se encontra, onde os detalhes e características do produto assim como sua usabilidade são constantemente aperfeiçoados para serem implementados.

Metodologia Utilizada

Mecanismos de organização

Para organização de conteúdo e discussões, assim como divisão de tarefas e definição de metas, o grupo utilizou o Trello, site no qual é possível definir as etapas do projeto, responsáveis por cada uma destas e anexo de informações. O grupo também utilizou de alguns conceitos dos métodos ágeis para auxiliar na organização do tempo e dos objetivos. Um conceito utilizado foi o de "stand up meetings" que consistem de reuniões de curta duração (cerca de 15 a 20 minutos) com todo o grupo realizadas em pé. A reunião tem como objetivos: discutir o que foi realizado até o momento, as dificuldades encontradas por cada membro e definir o que cada um irá realizar até a próxima reunião. No caso do Scrum, essa reunião é chamada de Daily Scrum Meeting e define que essas reuniões devem ser realizadas diariamente, mas devido a conflitos de horários e disponibilidade de tempo, essas reuniões foram realizadas ao final de cada aula. Como meio de comunicação entre os integrantes do grupo como avisos e debates mais céleres, foi utilizado um grupo privado no aplicativo Whatsapp. Nos finais de semana, uma outra reunião era realizada para discutir o que foi realizado durante a semana e definir os objetivos da semana seguinte.

Imagem do trello do grupo no início do projeto

Levantamento de ideias e decisão de tema

A partir do conceito de Smart Cities e das discussões levantadas pelo grupo, começamos o processo para definição da principal abordagem do projeto.Através de um brainstorm, os participantes do grupo compartilharam entre si os problemas do Distrito Federal mais perceptíveis a eles e os colocaram em cards para facilitar a organização. Após breve apresentação de cada problema, os cards foram organizados em clusters para que áreas conexas fossem agrupadas e pudéssemos identificar que área de atuação eram identificadas pelo grupo como mais necessitadas de soluções inteligentes. Logo, com um total de 3 cards, foi decidido por abordar o tema saúde pública, devido também à facilidade de acesso aos profissionais de usuários deste ramo.

Pesquisas sobre o tema

Com o tema definido, iniciou-se o levantamento de dados e informações sobre a área da saúde no Distrito Federal. Nesta fase, foram feitas pesquisas sobre como esta funciona, assim como entrevistas com profissionais e usuários dos serviços públicos de saúde. No total foram 13 entrevistas sendo 8(oito) delas com pacientes de diversos centros de atendimento do DF, 3(três) com funcionários, 1(uma) com um médico e 1(uma) com o gestor de uma Unidade de Pronto-Atendimento(UPA). Com estes resultados, foi possível realizar o levantamento das necessidades das pessoas que estão diretamente ligadas à saúde pública do DF e dos problemas por elas percebidos.

Points of View e Hipótese de Solução

Em posse dos dados levantados nas entrevistas e pesquisas, começamos a elaborar pontos de vista (PoV) para filtrar o conteúdo adquirido realizando um alta definição de cada problema evidenciando os quem é atingido por ele, do que esta pessoa ou grupo precisa e por que há essa necessidade. Partindo deste princípio e ao analisar as entrevistas, foi possível perceber que os problemas percebidos são direta ou indiretamente relacionados ao atraso no atendimento, longo tempo de espera e à falta de médicos. Os PoV elaborados foram:

• Ponto de vista:
  1. As a: Pessoa adoentada
  2. I Want: Ser atendido em um tempo digno
  3. So That: Meu problema seja resolvido logo.
• Ponto de vista:
  1. As a: Pessoa adoentada
  2. I want: Obter um diagnóstico ou tratamento preciso
  3. So That: Diagnósticos incorretos não causem sequelas, problemas futuros e maiores gastos e retornos repetitivos aos hospitais.
• Ponto de vista:
  1. As a: Médico
  2. I Want: Obter um diagnóstico ou tratamento preciso
  3. So That: otimize tempo de trabalho e evite retornos repetitivos desnecessários.
• Ponto de vista:
  1. As a: Pessoa adoentada
  2. I Want: Encontrar o hospital que melhor atende meu problema
  3. So That: haja os equipamentos, especialidades ou medicamentos necessários para o tratamento no local em que eu for atendido.

O PoV elaborado pelo grupo e utilizado como hipótese de solução por ser mais compatível com a realidade vivenciada pelos entrevistados foi o de "Como uma pessoas enferma eu quero um atendimento médico onde eu sei que existe a especialidade que preciso e que há a menor fila de espera, para que não precise perder tempo me dirigindo para locais desnecessários e assim aumentar a rapidez do atendimento". Esta definição se baseou no grande número de pessoas que percebem as longas filas em determinadas unidades, a falta de médicos ou especialidades médicas e a falta de informação sobre o atendimento em cada unidade como os principais problemas enfrentados hoje por usuários e profissionais da saúde pública.

Protótipos e propostas de solução

Com o problema definido, em seguida o grupo reuniu-se mais uma vez para formular ideias e sugestões de soluções. Cada membro teve cerca um tempo limitado (aproximadamente 20 minutos) para propor 4 soluções diferentes. As soluções foram escritas e/ou desenhadas em pequenas folhas de papel. Ao final do tempo, o grupo dividiu-se em duplas, onde um indivíduo da dupla compartilhava as suas propostas com o outro e recebia seu feedback. Depois que cada um da dupla havia compartilhado todas as suas soluções e coletado todo o feedback, as melhores ideias foram compartilhadas com os demais membros do grupo. Esse procedimento permite rapidamente selecionar as melhores ideias e eficientemente reduz o tempo de discussão. Assim, com uma mostra menor das melhores propostas, o grupo analisou coletivamente a melhor solução.

Principais soluções propostas

As imagens a seguir apresentam as principais propostas de soluções selecionadas pelo grupo:

Proposta de solução 1: Realocar paciente para outros hospitais baseado na disponibilidade de médicos.

Proposta de solução 2: Fila de espera virtual com sugestão de locais alternativos para atendimento.

Proposta de solução 3: Um aplicativo que apresenta o hospital mais próximo com menor fila para a especialidade requerida.

O grupo decidiu combinar as três melhores soluções em uma só da seguinte forma: desenvolver um sistema consistindo em um aplicativo que funcionaria como uma espécie de fila de espera virtual. Assim, o usuário que desejasse atendimento médico utilizaria o aplicativo para descobrir quais os locais de atendimento (hospital, UPA, posto de saúde), que possui a especialidade médica requerida, mais próximo e o tempo médio de espero em cada lugar.

Um problema que o grupo encontrou nessa solução foi como garantir que um médico daquela especialidade encontra-se naquele local de atendimento em um dado momento. Outro problema apresentado foi como garantir que o usuário seria atendido utilizando o aplicativo. A solução para ambas veio na forma de integração de sistemas e automatização. Para o primeiro problema, o grupo analisou que seria necessário um sistema de controle de presença dos médicos e funcionários. Segundo o artigo de número 6 da Portaria Nº 163, de 24 de junho de 2013, os servidores residentes da Secretária de Estado de Saúde do DF (SES/DF) obrigatoriamente utilizam um sistema de controle eletrônico de ponto. Assim, a solução proposta seria integrar o sistema sendo desenvolvido com o sistema de ponto eletrônico médico. Essa integração de sistemas permitiria determinar quais locais de atendimento possuem médicos de uma dada especialidade em tempo real. Essa informação é essencial, pois como foi observado nas entrevistas realizadas para investigar o problema, uma das maiores reclamações foi ir até um local de atendimento e descobrir que não havia médico da especialidade desejada.

Já para a resolução do segundo problema encontrado, o grupo verificou que o sistema de saúde pública brasileiro já possui um sistema de informação que reúne informações diversas, inclusive a quantidade de pacientes aguardando atendimento, a prioridade de um paciente no atendimento e em qual estágio do atendimento um indivíduo se encontra, chamado de Prontuário Eletrônico do Cidadão (PEC). O PEC requer o cadastro de cada paciente o que permite manter o histórico do paciente e a coleta de dados para a geração de relatórios de saúde dinâmicos. O cadastro geralmente é feito com a utilização com um documento de identificação, mas também pode utilizar o Cartão Nacional de Saúde (CNS) que tem como objetivo criar uma base nacional de informações de saúde, com identificação dos indivíduos, independentemente de sua cobertura suplementar. O sistema a ser desenvolvido será integrado ao PEC de forma que os seus usuários realizaram um cadastro da mesma forma que é realizada atualmente, como algum documento de identificação ou, caso o usuário possui, com o CNS. Assim, uma vez que o usuário desejar um atendimento, ele será automaticamente inserido na fila de espera de atendimento do PEC, como se tivesse no local de atendimento.

Modelo simplificado do sistema proposto como solução.

Reunindo as informações sobre os médicos presentes em uma dado local de atendimento e da fila de espera de atendimento, o sistema a ser desenvolvido também será capaz de estimar o tempo médio de espera para ser atendido. Além disso, o sistema poderá utilizar a localização do usuário para determinar o local de atendimento mais próximo e com a menor fila de espera. Esse aplicativo, portanto, resolve os principais problemas encontrados: determinar se em um determinado local de atendimento existe algum médico da especialidade requerida e diminuir o tempo na fila de espera para o atendimento.

Protótipos de baixa fidelidade

Protótipos são extremamente úteis, pois permitem a discussão e a avaliação de ideias com os clientes e/ou usuários (stakeholders) e tem como foco o design do sistema. Protótipos de baixa fidelidade são protótipos geralmente desenhados ou confeccionados utilizando materiais comuns de baixo custo o que permitem ser rapidamente elaborados e posteriormente descartados. É importante destacar que a qualidade do desenho não é importante desde que permite ilustrar bem o design do sistema. Esse tipo de protótipo é bastante utilizado, pois permite rapidamente obter feedback do usuário e modificá-lo no mesmo instante. As imagens a seguir mostram as telas que o grupo elaborou que representam um protótipo de baixa fidelidade do sistema:

Tela de acesso ao sistema.

Tela de cadastro.

Tela inicial do sistema. O sistema pede que o usuário selecione a especialidade da qual deseja atendimento.

Uma lista de especialidades é apresentada.

Em seguida o sistema pede para o usuário selecionar o local de atendimento desejado. Informações sobre distância e tempo média de espera também são apresentadas.

Uma vez selecionado o local o usuário é apresentado a opção de entrar na fila.

Ao entrar na fila, a senha do usuário é mostrada, assim como a senha atual sendo atendida, o tempo médio de espera e um mapa exibindo o local de atendimento e a posição atual do usuário.

Quando for a vez do usuário, essa tela apresenta o local exato de atendimento e o tempo de espera total. O usuário também pode optar por entrar em outra fila ou visualizar o exato local de atendimento.

Tela apresenta detalhes mais precisos do local exato de atendimento assim como um mapa com a posição aproximada do local de atendimento.

O protótipo foi apresentado a 15 stakeholders nas proximidades do HRAN. Antes da apresentação do protótipo, explicou-se brevemente a finalidade do sistema e que o propósito da interação com as telas era para avaliar o sistema em si e não a pessoa. Pediu-se que a pessoa comunica-se as suas ações para deixar claro os motivos daquela interação. Para simular uma interação de inicio a fim, foi dado o seguinte objetivo ao usuário: você precisa de um atendimento com um gastroenterologista no hospital mais próximo.

Todos os usuários conseguiram chegar ao objetivo final, mas houve dois pontos em que houve rupturas comunicativas. Essas rupturas consistem em falhas na comunicação entre preposto do sistema e o usuário. Vários usuários optaram pela apresentação de mais lugares de atendimento, uma tela que não foi prototipada no naquele momento. Essa interação permitiu realizar algumas análises do design. Primeiro, não ficou claro que a primeira opção de local apresentada é sempre do local mais próximo do usuário. Uma possível alteração a ser realizada é adicionar um filtro que deixa explicito que os locais estão sendo filtrados pelo local mais próximo. Essa melhoria também pode permitir que o usuário realize diferentes tipos de filtros como, por exemplo, ordenar pelo hospital com menor tempo médio de espera. Uma outra possível alteração pode ser adicionar uma espécie de tag dizendo "Mais próximo!" para deixar claro que aquele local é o que está a menor distância do usuário. A segunda ruptura foi que muitos usuários não selecionaram a opção de visualizar o local com informações mais precisas. O motivo desta ruptura pode ser que o não ficou a necessidade de seu uso com o objetivo dado ou possivelmente não ficou evidente que o ícone era um botão e o qual era o seu objetivo. Uma forma possível alteração é tornar o próprio local dado , nesse caso "Triagem", no botão que oferece informações mais precisas. Essa solução foi apresentada para os usuários os quais concordaram e disseram ser mais intuitivo.

Testando o protótipo de baixa fidelidade no HRAN

Feedback

Ao concluir a apresentação do protótipo, foi pedido a opinião do usuário sobre o sistema. Todos afirmaram que o sistema era bastante intuitivo e fácil de utilizar. Muitos afirmaram que o sistema seria muito útil e que realmente ajudaria reduzir não só tamanho das filas, mas o tempo gasto nelas. Alguns usuários inclusive comentaram que o sistema proposto teria ajudado eles naquele momento, pois haviam gasto tempo indo até um local de atendimento em que não havia o médico disponível para a especialidade procurada. Estes usuários também pediram para disponibilizar rapidamente o aplicativo para que pudessem utilizá-lo.

Considerações Finais

Todo o processo de desenvolvimento do projeto pôde trazer diversos aprendizados à equipe envolvida sobre as temáticas de Design Thinking, Saúde Pública, Prototipação, Cidades Inteligentes entre várias outras atividades elaboradas. Algumas hipóteses criadas durante as primeiras projeções do trabalho foram totalmente refutadas e em geral partiam de opiniões pessoais e suposições. A visão de universitários difere em alguns pontos das necessidades reais de quem utiliza o sistema público de saúde com frequência.

Após a aplicação de metodologias, processos de imersão e de criatividade com validações de stakeholders e tutoria da professora, pôde-se obter hipóteses mais precisas e que pudessem agradar os envolvidos no problema analisado. Assim foi construído o protótipo que foi testado e revisado diversas vezes até que atingisse a forma atual do produto (sempre aberto a melhorias).

O projeto desenvolvido visa resolver o problema de filas que é presente e constante na realidade dos serviços de saúde públicos e se enquadra como sistema de informação que realiza o armazenamento e integração de dados, oferece uma possibilidade de acesso e transparência ao usuário final e economiza recursos dos diversos envolvidos - hospitais podem economizar em processos, alocações e atendimentos iniciais e pacientes podem economizar tempo e gastos com deslocamentos. O sistema proposto também faz sua conexão com cidades inteligentes já que utiliza da integração de informações do setor de saúde e interações com hospitais públicos espalhados pela cidade, podendo agregar outros recursos futuros e módulos já que é apresentado como um sistema integrado e conectado a uma rede comum. Também propõe-se seguir todos os padrões multi-plataforma possibilitando sua utilização de forma genérica em qualquer dispositivo móvel além do acesso web.

A implementação do projeto pode trazer melhorias ao sistema público de saúde desobstruindo salas de espera de hospitais, evitando deslocamentos desnecessários e também atendimentos incorretos. Os dados gerados pelo sistema também poderão integrar um Big Data para futura análise de comportamento, Business Intelligence, aprimoramento do sistema e outras melhorias.

É de grande importância que problemas na área de saúde pública e cidades inteligentes sejam abordados em universidades públicas e gratuitas. Desta forma, universitários capacitados podem ter contato, imergir nesta realidade e possivelmente dar continuidade a projetos que envolvam este tipo de solução, dando assim retorno à sociedade e buscando construir uma cidade mais inteligente e justa.

Todo o material produzido durante a realização deste projeto (dados coletados, protótipos, relatórios) foi disponibilizado em formato aberto para uso livre por qualquer contribuinte. As ideias desenvolvidas neste trabalho também têm a finalidade de serem propagadas, aprimoradas e continuadas.

Entrega Final

Resumo

Toda cidade busca sempre proporcionar uma boa qualidade de vida às pessoas que nela residem e na capital do Brasil esse fato não é diferente. De acordo com a empresa americana de consultoria empresarial, Mercer, Brasília é a cidade brasileira onde as pessoas têm as melhores condições para viver. Contudo, essa cidade ainda possui bastantes problemas nas áreas administradas pelo governo local como na área de segurança, transporte e saúde. Tomando como foco o problema no setor da saúde pública, acreditamos que tornar Brasília uma cidade inteligente (smart city) será o melhor caminho para sanar problemas nessa área, que ainda afeta de modo negativo muitos usuários do Sistema Único de Saúde (SUS).

O Distrito Federal ainda possui muitos problemas relacionados ao sistema de saúde pública, como superlotação de pronto-socorros, falta de recursos humanos, atendimento insuficiente e precário, entre outros, como relata o Relatório de Fiscalização de Hospitais Públicos do DF do Ministério Público do Distrito Federal e Territórios (MPFT). Com isso em mente, fomos às ruas fazer uma pesquisa sobre quais eram os pontos negativos de se utilizar o SUS na região. Após recolhermos os dados necessários e após uma análise detalhada das adversidades do sistema de saúde de Brasília, constatamos que o problema das filas de espera nos hospitais ainda é muito comum e acaba afetando de modo negativo a vida dos paciente que esperam por um atendimento decente nesses estabelecimentos. Com isso, decidimos por criar um sistema que irá auxiliar na organização dessas filas de maneira a torná-las mais ágeis e mais organizadas para que, assim, o atendimento aos pacientes ocorra de maneira conveniente, diminuindo um dos maiores problemas no setor da saúde pública de Brasília. Além disso, esse sistema visa integrar diferentes sistemas de informação e automatizar o processamento de dados com o intuito de tornar a cidade mais inteligente, e assim, aumentar a qualidade de vida dos cidadãos.

Smart Cities

O conceito de smart cities, ou cidades inteligentes, se define pelo uso da tecnologia para melhorar a infraestrutura urbana e tornar os centros urbanos mais eficientes e melhores de se viver. As cidades inteligentes fazem o uso intensivo de tecnologias de informação e comunicação focando em três área principais: Internet of Things (IoT), que consiste em conectar os dispositivos eletrônicos utilizados no dia a dia à internet de maneira que tudo possa ser controlado remotamente por um usuário; Big Data, processamento e análise de grandes quantidades de informações; e Governança Algorítmica, gestão e planejamento com base em ações construídas por algoritmos aplicados à vida urbana. Utilizando esses fluxos de interação as smart cities procuram melhorar a qualidade de vida dos cidadãos facilitando a interação das pessoas com os recursos oferecidos pela cidade.

Design Thinking

O Design Thinking é um processo de pensamento crítico e criativo que ajuda na imersão e no entendimento de parâmetros e padrões essenciais para criar projetos de melhor qualidade com boas decisões e melhor organização de informações e ideias. Design Thinking não se trata de uma metodologia mas de uma abordagem. Ele busca solucionar problemas com uma visão ampla e coletiva, envolvendo a perspectiva de todos os stakholders (interessados), todos os envolvidos são colocados no meio do desenvolvimento do produto e não apenas o consumidor final do produto.

O processo também busca mapear as experiências de vivência, cultura e hábitos dos envolvidos de forma que se obtenha uma perspectiva mais completa sobre a situação, partindo de uma abordagem humanizada, antropocêntrica.

O Design Thinking é divido em etapas, caracterizando bem o processo. As etapas que executamos foram:

Imersão: A primeira fase do processo é quando a equipe do projeto identificou os aspectos e contexto do problema em hospitais da rede pública brasiliense. Pode-se perceber vários outros problemas correlacionados por meio da imersão, entrevistas, interações com os pacientes e funcionários do hospital analisando tanto do ponto de vista do usuário final quanto dos outros stakholders envolvidos. A partir desta imersão preliminar, criando o entendimento inicial de quais seriam nossos desafios, houve um aprofundamento em um dos problemas específicos, de forma a identificar necessidades e oportunidades que guiaram a geração de soluções na fase seguinte do projeto.

Organização das ideias levantadas 1

Organização das ideias levantadas 2

Ideação: Com os tópicos de imersão já devidamente documentados, utilizamos técnicas de visualização e organização destas ideias, buscando gerar ideias inovadoras ao tema do projeto, realizando discussões de forma cooperativa na equipe. Foram utilizadas ferramentas de síntese de ideias, estimulando a criatividade por meio da organização de cartões contendo os tópicos absorvidos durante a imersão. Buscamos assim construir soluções criativas de acordo com o contexto que estávamos analisando. Utilizamos das diferentes perspectivas da nossa equipe multidisciplinar (dois membros do curso de Engenharia de Computação, um da Ciência da Computação e outro da Administração) além da expertise de nossa professora mentora e de validações vindas dos contatos que temos com profissionais da área.

Ideacão com dados obtidos

Ideacão com dados obtidos

Ideacão com dados obtidos

Prototipação: Com a ideação já definida, buscou-se realizar várias prototipações, desde a protótipos em papel de baixa fidelidade até protótipos com telas mais complexas e interface semelhante a um sistema web. Nesta fase pôde-se analisar ideias geradas que puderam ser validadas e verificadas. O protótipo ajudou a tornar toda a ideia teórica em um produto mais tangível, do abstrato para o físico por meio de uma representação mais realista. A Prototipação ocorreu de forma iterativa, sempre sendo refeita ao longo do projeto de forma que chegássemos a ideias mais próximas da realidade dos usuários da rede pública e com usabilidade mais apropriada ao contexto em que o produto se encontraria.

Protótipo de Baixa Fidelidade

Protótipo de Alta Fidelidade

Implementação: Foram realizadas diversas validações e testes com os protótipos de baixa e alta fidelidade, modelando de forma que um produto final pudesse se adequar à realidade do problemas que estamos tratando e às necessidades dos usuários. Esta é a fase final em que o projeto se encontra, onde os detalhes e características do produto assim como sua usabilidade são constantemente aperfeiçoados para serem implementados.

Metodologia Utilizada

Mecanismos de organização

Para organização de conteúdo e discussões, assim como divisão de tarefas e definição de metas, o grupo utilizou o Trello, site no qual é possível definir as etapas do projeto, responsáveis por cada uma destas e anexo de informações. O grupo também utilizou de alguns conceitos dos métodos ágeis para auxiliar na organização do tempo e dos objetivos. Um conceito utilizado foi o de "stand up meetings" que consistem de reuniões de curta duração (cerca de 15 a 20 minutos) com todo o grupo realizadas em pé. A reunião tem como objetivos: discutir o que foi realizado até o momento, as dificuldades encontradas por cada membro e definir o que cada um irá realizar até a próxima reunião. No caso do Scrum, essa reunião é chamada de Daily Scrum Meeting e define que essas reuniões devem ser realizadas diariamente, mas devido a conflitos de horários e disponibilidade de tempo, essas reuniões foram realizadas ao final de cada aula. Como meio de comunicação entre os integrantes do grupo como avisos e debates mais céleres, foi utilizado um grupo privado no aplicativo Whatsapp. Nos finais de semana, uma outra reunião era realizada para discutir o que foi realizado durante a semana e definir os objetivos da semana seguinte.

Imagem do trello do grupo no início do projeto

Levantamento de ideias e decisão de tema

A partir do conceito de Smart Cities e das discussões levantadas pelo grupo, começamos o processo para definição da principal abordagem do projeto.Através de um brainstorm, os participantes do grupo compartilharam entre si os problemas do Distrito Federal mais perceptíveis a eles e os colocaram em cards para facilitar a organização. Após breve apresentação de cada problema, os cards foram organizados em clusters para que áreas conexas fossem agrupadas e pudéssemos identificar que área de atuação eram identificadas pelo grupo como mais necessitadas de soluções inteligentes. Logo, com um total de 3 cards, foi decidido por abordar o tema saúde pública, devido também à facilidade de acesso aos profissionais de usuários deste ramo.

Pesquisas sobre o tema

Com o tema definido, iniciou-se o levantamento de dados e informações sobre a área da saúde no Distrito Federal. Nesta fase, foram feitas pesquisas sobre como esta funciona, assim como entrevistas com profissionais e usuários dos serviços públicos de saúde. No total foram 13 entrevistas sendo 8(oito) delas com pacientes de diversos centros de atendimento do DF, 3(três) com funcionários, 1(uma) com um médico e 1(uma) com o gestor de uma Unidade de Pronto-Atendimento(UPA). Com estes resultados, foi possível realizar o levantamento das necessidades das pessoas que estão diretamente ligadas à saúde pública do DF e dos problemas por elas percebidos.

Points of View e Hipótese de Solução

Em posse dos dados levantados nas entrevistas e pesquisas, começamos a elaborar pontos de vista (PoV) para filtrar o conteúdo adquirido realizando um alta definição de cada problema evidenciando os quem é atingido por ele, do que esta pessoa ou grupo precisa e por que há essa necessidade. Partindo deste princípio e ao analisar as entrevistas, foi possível perceber que os problemas percebidos são direta ou indiretamente relacionados ao atraso no atendimento, longo tempo de espera e à falta de médicos. Os PoV elaborados foram:

• Ponto de vista:
  1. As a: Pessoa adoentada
  2. I Want: Ser atendido em um tempo digno
  3. So That: Meu problema seja resolvido logo.
• Ponto de vista:
  1. As a: Pessoa adoentada
  2. I want: Obter um diagnóstico ou tratamento preciso
  3. So That: Diagnósticos incorretos não causem sequelas, problemas futuros e maiores gastos e retornos repetitivos aos hospitais.
• Ponto de vista:
  1. As a: Médico
  2. I Want: Obter um diagnóstico ou tratamento preciso
  3. So That: otimize tempo de trabalho e evite retornos repetitivos desnecessários.
• Ponto de vista:
  1. As a: Pessoa adoentada
  2. I Want: Encontrar o hospital que melhor atende meu problema
  3. So That: haja os equipamentos, especialidades ou medicamentos necessários para o tratamento no local em que eu for atendido.

O PoV elaborado pelo grupo e utilizado como hipótese de solução por ser mais compatível com a realidade vivenciada pelos entrevistados foi o de "Como uma pessoas enferma eu quero um atendimento médico onde eu sei que existe a especialidade que preciso e que há a menor fila de espera, para que não precise perder tempo me dirigindo para locais desnecessários e assim aumentar a rapidez do atendimento". Esta definição se baseou no grande número de pessoas que percebem as longas filas em determinadas unidades, a falta de médicos ou especialidades médicas e a falta de informação sobre o atendimento em cada unidade como os principais problemas enfrentados hoje por usuários e profissionais da saúde pública.

Protótipos e propostas de solução

Com o problema definido, em seguida o grupo reuniu-se mais uma vez para formular ideias e sugestões de soluções. Cada membro teve cerca um tempo limitado (aproximadamente 20 minutos) para propor 4 soluções diferentes. As soluções foram escritas e/ou desenhadas em pequenas folhas de papel. Ao final do tempo, o grupo dividiu-se em duplas, onde um indivíduo da dupla compartilhava as suas propostas com o outro e recebia seu feedback. Depois que cada um da dupla havia compartilhado todas as suas soluções e coletado todo o feedback, as melhores ideias foram compartilhadas com os demais membros do grupo. Esse procedimento permite rapidamente selecionar as melhores ideias e eficientemente reduz o tempo de discussão. Assim, com uma mostra menor das melhores propostas, o grupo analisou coletivamente a melhor solução.

Principais soluções propostas

As imagens a seguir apresentam as principais propostas de soluções selecionadas pelo grupo:

Proposta de solução 1: Realocar paciente para outros hospitais baseado na disponibilidade de médicos.

Proposta de solução 2: Fila de espera virtual com sugestão de locais alternativos para atendimento.

Proposta de solução 3: Um aplicativo que apresenta o hospital mais próximo com menor fila para a especialidade requerida.

O grupo decidiu combinar as três melhores soluções em uma só da seguinte forma: desenvolver um sistema consistindo em um aplicativo que funcionaria como uma espécie de fila de espera virtual. Assim, o usuário que desejasse atendimento médico utilizaria o aplicativo para descobrir quais os locais de atendimento (hospital, UPA, posto de saúde), que possui a especialidade médica requerida, mais próximo e o tempo médio de espero em cada lugar.

Um problema que o grupo encontrou nessa solução foi como garantir que um médico daquela especialidade encontra-se naquele local de atendimento em um dado momento. Outro problema apresentado foi como garantir que o usuário seria atendido utilizando o aplicativo. A solução para ambas veio na forma de integração de sistemas e automatização. Para o primeiro problema, o grupo analisou que seria necessário um sistema de controle de presença dos médicos e funcionários. Segundo o artigo de número 6 da Portaria Nº 163, de 24 de junho de 2013, os servidores residentes da Secretária de Estado de Saúde do DF (SES/DF) obrigatoriamente utilizam um sistema de controle eletrônico de ponto. Assim, a solução proposta seria integrar o sistema sendo desenvolvido com o sistema de ponto eletrônico médico. Essa integração de sistemas permitiria determinar quais locais de atendimento possuem médicos de uma dada especialidade em tempo real. Essa informação é essencial, pois como foi observado nas entrevistas realizadas para investigar o problema, uma das maiores reclamações foi ir até um local de atendimento e descobrir que não havia médico da especialidade desejada. Segundo a Lei LEI Nº 12.527, DE 18 DE NOVEMBRO DE 2011 que trata do acesso a informações governamentais, é possível utilizar dados pessoais, como podem ser caracterizados os pontos dos servidores, conforme sua utilização para fins de atendimento médico, conforme consta na seção V da referida lei:

Seção V

Das Informações Pessoais 

Art. 31.  O tratamento das informações pessoais deve ser feito de forma transparente e com respeito à intimidade, vida privada, honra e imagem das pessoas, bem como às liberdades e garantias individuais. 

§ 1^o  As informações pessoais, a que se refere este artigo, relativas à intimidade, vida privada, honra e imagem: 

I - terão seu acesso restrito, independentemente de classificação de sigilo e pelo prazo máximo de 100 (cem) anos a contar da sua data de produção, a agentes públicos legalmente autorizados e à pessoa a que elas se referirem; e 

II - poderão ter autorizada sua divulgação ou acesso por terceiros diante de previsão legal ou consentimento expresso da pessoa a que elas se referirem. 

§ 2^o  Aquele que obtiver acesso às informações de que trata este artigo será responsabilizado por seu uso indevido. 

§ 3^o  O consentimento referido no inciso II do § 1^o não será exigido quando as informações forem necessárias: 

I - à prevenção e diagnóstico médico, quando a pessoa estiver física ou legalmente incapaz, e para utilização única e exclusivamente para o tratamento médico; 

II - à realização de estatísticas e pesquisas científicas de evidente interesse público ou geral, previstos em lei, sendo vedada a identificação da pessoa a que as informações se referirem; 

III - ao cumprimento de ordem judicial; 

IV - à defesa de direitos humanos; ou 

V - à proteção do interesse público e geral preponderante. 

§ 4^o  A restrição de acesso à informação relativa à vida privada, honra e imagem de pessoa não poderá ser invocada com o intuito de prejudicar processo de apuração de irregularidades em que o titular das informações estiver envolvido, bem como em ações voltadas para a recuperação de fatos históricos de maior relevância. 

§ 5^o  Regulamento disporá sobre os procedimentos para tratamento de informação pessoal. 

Escala Médica obtida no Portal da Transparência

Considerando os itens I e II do parágrafo 3 da referida lei, optamos por disponibilizar em tempo real as informações do ponto eletrônico através do nosso sistema mas indicando apenas a especialidade médica do servidor, ocultando informações como nome ou matrícula. Vale ressaltar que o Governo do Distrito Federal já disponibiliza a escala de todos os profissionais da saúde do Distrito Federal através do Portal da Transparência na seção Servidores/Escala dos profissionais da Saúde, divulgando inclusive o nome completo dos profissionais e o horário em que teriam que estar nas unidades de saúde.

Outra opção encontrada por nós foi obter a informação sobre a presença do médico no centro de saúde através da confirmação do login deste no sistema de prontuários do SUS, confirmando sua presença na unidade e a execução do atendimento. Preferimos manter a proposta da utilização do ponto biométrico uma vez que nem sempre os médicos estariam utilizando um computador para o atendimento, visto que o atendimento em unidades como UTI e Pronto-Socorro requerem uma atenção integral ao paciente, não garantindo a utilização login em determinados momentos.

Já para a resolução do segundo problema encontrado, o grupo verificou que o sistema de saúde pública brasileiro já possui um sistema de informação que reúne informações diversas, inclusive a quantidade de pacientes aguardando atendimento, a prioridade de um paciente no atendimento e em qual estágio do atendimento um indivíduo se encontra, chamado de Prontuário Eletrônico do Cidadão (PEC). O PEC requer o cadastro de cada paciente o que permite manter o histórico do paciente e a coleta de dados para a geração de relatórios de saúde dinâmicos. O cadastro geralmente é feito com a utilização com um documento de identificação, mas também pode utilizar o Cartão Nacional de Saúde (CNS) que tem como objetivo criar uma base nacional de informações de saúde, com identificação dos indivíduos, independentemente de sua cobertura suplementar. O sistema a ser desenvolvido será integrado ao PEC de forma que os seus usuários realizaram um cadastro da mesma forma que é realizada atualmente, como algum documento de identificação ou, caso o usuário possui, com o CNS. Assim, uma vez que o usuário desejar um atendimento, ele será automaticamente inserido na fila de espera de atendimento do PEC, como se tivesse no local de atendimento.

Modelo simplificado do sistema proposto como solução.

Reunindo as informações sobre os médicos presentes em uma dado local de atendimento e da fila de espera de atendimento, o sistema a ser desenvolvido também será capaz de estimar o tempo médio de espera para ser atendido. Além disso, o sistema poderá utilizar a localização do usuário para determinar o local de atendimento mais próximo e com a menor fila de espera. Esse aplicativo, portanto, resolve os principais problemas encontrados: determinar se em um determinado local de atendimento existe algum médico da especialidade requerida e diminuir o tempo na fila de espera para o atendimento.

Protótipos de baixa fidelidade

Protótipos são extremamente úteis, pois permitem a discussão e a avaliação de ideias com os clientes e/ou usuários (stakeholders) e tem como foco o design do sistema. Protótipos de baixa fidelidade são protótipos geralmente desenhados ou confeccionados utilizando materiais comuns de baixo custo o que permitem ser rapidamente elaborados e posteriormente descartados. É importante destacar que a qualidade do desenho não é importante desde que permite ilustrar bem o design do sistema. Esse tipo de protótipo é bastante utilizado, pois permite rapidamente obter feedback do usuário e modificá-lo no mesmo instante. As imagens a seguir mostram as telas que o grupo elaborou que representam um protótipo de baixa fidelidade do sistema:

Tela de acesso ao sistema.

Tela de cadastro.

Tela inicial do sistema. O sistema pede que o usuário selecione a especialidade da qual deseja atendimento.

Uma lista de especialidades é apresentada.

Em seguida o sistema pede para o usuário selecionar o local de atendimento desejado. Informações sobre distância e tempo média de espera também são apresentadas.

Uma vez selecionado o local o usuário é apresentado a opção de entrar na fila.

Ao entrar na fila, a senha do usuário é mostrada, assim como a senha atual sendo atendida, o tempo médio de espera e um mapa exibindo o local de atendimento e a posição atual do usuário.

Quando for a vez do usuário, essa tela apresenta o local exato de atendimento e o tempo de espera total. O usuário também pode optar por entrar em outra fila ou visualizar o exato local de atendimento.

Tela apresenta detalhes mais precisos do local exato de atendimento assim como um mapa com a posição aproximada do local de atendimento.

O protótipo foi apresentado a 15 stakeholders nas proximidades do HRAN. Antes da apresentação do protótipo, explicou-se brevemente a finalidade do sistema e que o propósito da interação com as telas era para avaliar o sistema em si e não a pessoa. Pediu-se que a pessoa comunica-se as suas ações para deixar claro os motivos daquela interação. Para simular uma interação de inicio a fim, foi dado o seguinte objetivo ao usuário: você precisa de um atendimento com um gastroenterologista no hospital mais próximo.

Todos os usuários conseguiram chegar ao objetivo final, mas houve dois pontos em que houve rupturas comunicativas. Essas rupturas consistem em falhas na comunicação entre preposto do sistema e o usuário. Vários usuários optaram pela apresentação de mais lugares de atendimento, uma tela que não foi prototipada no naquele momento. Essa interação permitiu realizar algumas análises do design. Primeiro, não ficou claro que a primeira opção de local apresentada é sempre do local mais próximo do usuário. Uma possível alteração a ser realizada é adicionar um filtro que deixa explicito que os locais estão sendo filtrados pelo local mais próximo. Essa melhoria também pode permitir que o usuário realize diferentes tipos de filtros como, por exemplo, ordenar pelo hospital com menor tempo médio de espera. Uma outra possível alteração pode ser adicionar uma espécie de tag dizendo "Mais próximo!" para deixar claro que aquele local é o que está a menor distância do usuário. A segunda ruptura foi que muitos usuários não selecionaram a opção de visualizar o local com informações mais precisas. O motivo desta ruptura pode ser que o não ficou a necessidade de seu uso com o objetivo dado ou possivelmente não ficou evidente que o ícone era um botão e o qual era o seu objetivo. Uma forma possível alteração é tornar o próprio local dado , nesse caso "Triagem", no botão que oferece informações mais precisas. Essa solução foi apresentada para os usuários os quais concordaram e disseram ser mais intuitivo.

Testando o protótipo de baixa fidelidade no HRAN

Feedback

Ao concluir a apresentação do protótipo, foi pedido a opinião do usuário sobre o sistema. Todos afirmaram que o sistema era bastante intuitivo e fácil de utilizar. Muitos afirmaram que o sistema seria muito útil e que realmente ajudaria reduzir não só tamanho das filas, mas o tempo gasto nelas. Alguns usuários inclusive comentaram que o sistema proposto teria ajudado eles naquele momento, pois haviam gasto tempo indo até um local de atendimento em que não havia o médico disponível para a especialidade procurada. Estes usuários também pediram para disponibilizar rapidamente o aplicativo para que pudessem utilizá-lo.

Considerações Finais

Todo o processo de desenvolvimento do projeto pôde trazer diversos aprendizados à equipe envolvida sobre as temáticas de Design Thinking, Saúde Pública, Prototipação, Cidades Inteligentes entre várias outras atividades elaboradas. Algumas hipóteses criadas durante as primeiras projeções do trabalho foram totalmente refutadas e em geral partiam de opiniões pessoais e suposições. A visão de universitários difere em alguns pontos das necessidades reais de quem utiliza o sistema público de saúde com frequência.

Após a aplicação de metodologias, processos de imersão e de criatividade com validações de stakeholders e tutoria da professora, pôde-se obter hipóteses mais precisas e que pudessem agradar os envolvidos no problema analisado. Assim foi construído o protótipo que foi testado e revisado diversas vezes até que atingisse a forma atual do produto (sempre aberto a melhorias).

O projeto desenvolvido visa resolver o problema de filas que é presente e constante na realidade dos serviços de saúde públicos e se enquadra como sistema de informação que realiza o armazenamento e integração de dados, oferece uma possibilidade de acesso e transparência ao usuário final e economiza recursos dos diversos envolvidos - hospitais podem economizar em processos, alocações e atendimentos iniciais e pacientes podem economizar tempo e gastos com deslocamentos. O sistema proposto também faz sua conexão com cidades inteligentes já que utiliza da integração de informações do setor de saúde e interações com hospitais públicos espalhados pela cidade, podendo agregar outros recursos futuros e módulos já que é apresentado como um sistema integrado e conectado a uma rede comum. Também propõe-se seguir todos os padrões multi-plataforma possibilitando sua utilização de forma genérica em qualquer dispositivo móvel além do acesso web.

A implementação do projeto pode trazer melhorias ao sistema público de saúde desobstruindo salas de espera de hospitais, evitando deslocamentos desnecessários e também atendimentos incorretos. Os dados gerados pelo sistema também poderão integrar um Big Data para futura análise de comportamento, Business Intelligence, aprimoramento do sistema e outras melhorias.

É de grande importância que problemas na área de saúde pública e cidades inteligentes sejam abordados em universidades públicas e gratuitas. Desta forma, universitários capacitados podem ter contato, imergir nesta realidade e possivelmente dar continuidade a projetos que envolvam este tipo de solução, dando assim retorno à sociedade e buscando construir uma cidade mais inteligente e justa.

Todo o material produzido durante a realização deste projeto (dados coletados, protótipos, relatórios) foi disponibilizado em formato aberto para uso livre por qualquer contribuinte. As ideias desenvolvidas neste trabalho também têm a finalidade de serem propagadas, aprimoradas e continuadas.

Protótipo de Baixa Fidelidade v.2.0

Fluxo Principal

Assim como foi realizado nos protótipos em papel, explicou-se aos stakeholders que o objetivo daquela interação era avaliar o quão intuitivo o sistema é e não a sua habilidade em si. Também foi dado um objetivo específico para guiar o fluxo de execução das atividades no sistema. Para simular uma interação de inicio a fim, foi dado o seguinte objetivo ao usuário: "você precisa de um atendimento com um cardiologista no hospital mais próximo". Pediu-se também que o usuário explica-se em voz alta o seu raciocínio por trás de cada tomada de decisão apresentada na interação com a interface. Toda ruptura comunicativa foi anotada e depois, ao final do teste, perguntou-se ao usuário o que levou aquela ruptura. Oito usuários foram utilizados para realizar esses testes sendo seis destes pais de crianças, com idade em torno de 30 e 50 anos e dois usuários mais idosos, de idade acima de 60 anos.

A primeira tela apresenta a tela de acesso ao sistema. Nessa tela, o usuário deve informar os seus dados de login, que são compostos por CPF ou CNS e senha. Depois de inserir os seus dados, o usuário pode optar por entrar no sistema. Caso o usuário não possui um cadastro no sistema, ele pode optar por realizar um cadastro. A imagem a seguir ilustra a tela de acesso:

Protótipo v2 - Tela de acesso

Caso o usuário não possui cadastro, uma nova tela é apresentada como um formulário de preenchimento de dados. Dados essenciais são marcados com asterisco para indicar preenchimento obrigatório. Os dados do usuário pedidos são: CPF, CNS (Cartão Nacional de Saúde), senha, confirmação de senha e e-mail.

Feedback/Validação - Tela de Cadastro

Um dos usuários perguntou o que significava a sigla CNS. Depois de explicar o seu significado perguntou-se ao usuário se possuía um. O usuário respondeu que não e perguntou com fazia para obter um. Esse feedback deixa claro que o campo CNS tem que ser acompanhado de algum informação adicional explicando não somente o seu significado, mas como obtê-lo. Pode-se classificar esse ruptura comunicativa como o erro, pois pode cessar a conversa com o sistema. Neste caso, é necessário uma forma de recuperação de erro, no qual o sistema oferece um caminho alternativo, externo à interface, pelo qual o usuário pode retomar a conversa . Uma forma de oferecer esse recurso seria por meio da inclusão de um botão com o formato de um ponto de interrogação. Esse botão é comumente conhecido por fornecer dados adicionais que auxiliam no entendimento do recurso específico, nesse caso o campo a ser preenchido. Ao selecionar o botão, o sistema poderia fornecer uma breve explicação sobre o que é o CNS e um link para uma página externa que permite a solicitação deste.

Protótipo v2 - Tela de cadastro de dados.

A tela a seguir representa a tela principal do sistema, onde o usuário pode selecionar a opção de entrar em uma fila, alterar os seus dados, sair e trocar de usuário atual, ou excluir o seu cadastro.

Protótipo v2 - Tela principal de opções apresentada para o usuário cadastrado.

Caso o usuário selecione a opção "Serviço Médico" a seguinte tela é apresentada. A tela apresenta ao usuário a opção de selecionar uma especialidade médica de qual deseja-se receber atendimento.

Protótipo v2 - Tela apresentando a opção de selecionar uma especialidade.

Tela apresentando as opções de especialidades médicas que o usuário pode selecionar. No caso dos testes executados com os stakeholders, solicitou-se selecionar a opção "Cardiologista".

Protótipo v2 - Tela de seleção de especialidades médicas.

Uma vez selecionada a especialidade médica, a opção de selecionar um local de atendimento é apresentado para o usuário.

Feedback/Validação - Tela de Seleção de Local de Atendimento

Muitos dos usuários optaram novamente por selecionar a opção "Mais opções" o qual nessa versão 2.0 foi desenvolvida. Também nessa versão de protótipo foi adicionado um recurso para explicitar qual local encontra-se mais próximo ao usuário. Um usuário questionou o motivo pelo qual esse recurso encontra-se apenas quando deseja-se verificar mais opções. Devido a esse questionamento, uma nova versão do protótipo terá que apresentar essa funcionalidade em primeiro lugar, o que deixa evidente a sua importância.

Protótipo v2 - Tela apresentando as opções de local de atendimento para a especialidade selecionada.

Uma vez que o usuário tem informado a especialidade desejada e o local de atendimento a opção de entrar na fila torna-se disponível como mostra a tela a seguir:

Protótipo v2 - Tela apresentando a opção de entrar na fila após a inserção dos dados.

O sistema insere o usuário na fila de espera de atendimento informando também ao sistema de Prontuário Eletrônico do Cidadão (PEC) do local os dados do usuário. O PEC administra a fila de pacientes aguardando o atendimento e organiza-os de acordo com sua prioridade. O nosso sistema irá inserir o paciente no último lugar na fila de espera, não associando nenhuma prioridade ao usuário, deixando que os atendentes realizem essa avaliação quando for a sua vez. O nosso sistema gera uma senha que simboliza a posição do usuário na fila de espera que é alterado em tempo real de acordo com andamento da fila. A tela também apresenta a geolocalização do local de atendimento de acordo com a posição do usuário para ajudá-lo com sua localização. O sistema também informa ao usuário o tempo médio aproximado até o seu atendimento.

Feedback/Validação - Tela de Indicando Senha de Atendimento

Alguns stakeholders questionaram como o sistema realiza o cálculo do tempo médio de espera. Explicou-se que o sistema realiza um cálculo, levando em conta diferentes fatores como o tempo médio de consulta, o número de médicos disponíveis, a quantidade de pacientes preferências, entre outros para informar ao usuário o tempo médio aproximado até o seu atendimento.

Protótipo v2 - Tela indicando a senha de atendimento do usuário e o tempo média de espera até o atendimento.

A tela a seguir apresenta quando é a vez do usuário de ser atendido. Ela também apresenta quanto tempo o usuário esperou na fila e a opção de entrar em outra fila, caso desejar.

Feedback/Validação - Tela de Indicando a Chegada de Sua Vez

No primeira versão do protótipo, observou-se que os usuários tiveram dificuldade em discernir o propósito do ícone de localização, mas já na segunda versão, observou-se que não houve nenhuma dificuldade. Os usuários clicavam no ícone por curiosidade sem mesmo ter que explicar o seu funcionamento, mostrando que a sua visualização está bem melhor representado na sua segunda versão.

Protótipo v2 - Tela indicando que é a vez do usuário e o local onde deve-se dirigir.

Protótipo v2 - Tela detalhando o local de atendimento.

Fluxos Alternativos

Os fluxos de execução são apresentados como alternativas ao fluxo de execução principal. Em ambos os caso uma mensagem é apresentada para que o usuário tome uma decisão informada sobre o que será executado, caracterizando-se uma forma de prevenção de ruptura apoiada .

Protótipo v2 - Tela de prevenção apoiada de exclusão de cadastro.

Protótipo v2 - Tela indicando que a exclusão de cadastro foi realizada com sucesso.

Protótipo v2 - Tela de prevenção apoiada para o caso em que o usuário deseja desistir de esperar na fila.

Protótipo v2 - Tela indicando que a desistência foi realizada com sucesso.

Modelagem de Processos

Para a modelagem de processos do sistema, utilizamos o modelo conhecido como Service Blueprint. Esse tipo de modelagem ilustra os serviços oferecidos pelo sistema em três planos diferentes: Customer Actions, o qual representa as ações do usuário, Front Stage, o qual representa as interações visíveis do usuário com o sistema e Back Stage, o qual representa as ações internas do sistema não visíveis para o usuário. Além da divisão em planos em termos de camadas de ações e visibilidade, a modelagem também oferece uma divisão temporal. Cada um dos três planos são divididos em quatro etapas temporais: Aware, a qual representa o momento em que o usuário ainda não teve o primeiro contato com o sistema, Join, a qual representa o momento de adesão ao sistema e as primeiras impressões do usuário, Use, a qual representa o período em que o usuário já está familiarizado com o sistema e está em pleno uso e Leave, a qual indica o momento em que o usuário finaliza o uso dos serviços prestados pelo sistema.

Aware

Modelagem de Processos (Aware)

Join

Modelagem de Processos (Join)

Use

Modelagem de Processos (Use)

Leave

Modelagem de Processos (Leave)

Visão Geral do Blueprint

Visão geral do blueprint de serviços do aplicativo.

Validação da Modelagem de Processos

Para a validação da Modelagem de Processos, entrou-se em contato com a Subsecretaria de Parceria Público-Privada, órgão responsável pela parceria entre empresas privadas e órgão públicos em empreendimentos públicos. Explicou-se para a representante do órgão que desejava-se obter maiores informações sobre o processo envolvido para criar essa parceria e que o objetivo do grupo era, junto com essa parceria, instaurar um sistema de fila espera virtual para auxiliar no atendimento de pacientes da rede de saúde pública. Também foi explicitado que seria necessário a integração com os sistemas e bancos de dados de atendimento dos hospitais públicos como o PEC, CNS e ponto eletrônico dos médicos. A representante explicou que seria necessário enviar um e-mail para a Subsecretaria pedindo os esclarecimentos necessários junto com todas as informações relacionadas ao empreendimento. A representante também acrescentou que essas parcerias geralmente envolve um processo licitatório que avalia diferentes empresas, tecnologias e os custos associados. Por fim, a representante mencionou que seria interessante entrar em contato com algum representante do Ministério da Saúde para obter informações específicas dos sistemas presentes nos hospitais públicos.

Conclusões

Observou-se que para continuar com a evolução do projeto é necessário obter mais informações e realizar mais validações junto com a Subsecretaria de Parceria Público-Privada. Essas informações serão essenciais para analisar a viabilidade do projeto em si. Também será necessário uma análise mais profunda dos sistemas presentes na rede pública de saúde, especialmente no que se refere a dados e troca de informação. Após o levantamento dessa informação, será possível verificar qual será o custo associado a execução do projeto e a sua viabilidade. Mesmo com essas dúvidas relacionadas com o back stage do projeto, observou-se uma avaliação positiva e grande interesse por parte dos stakeholders referente ao protótipo apresentado.

Apresentação de Slides

Link para os slides.