‍Para setores altamente regulamentados, como o de saúde, mergulhar nos domínios do no-code para criar aplicativos pode ser uma perspectiva um pouco intimidadora. Aqui, a fundadora de uma agência de desenvolvimento sem código revela o que aprendeu ao ajudar uma organização nesse setor. *É possível fazer isso.

Veronica Picciafuoco dirige o Eldur Studio: uma agência de desenvolvimento sem código que ajuda as organizações a implementar ferramentas sem código e com pouco código e mostra o que pode ser feito sem desenvolvedores. Em um projeto recente, ela foi encarregada de um desafio um pouco delicado. Uma empresa do setor de telessaúde queria criar um aplicativo de portal do paciente para fins de integração, mas estava ansiosa para não atrasar o desenvolvimento de seu produto principal, o aplicativo móvel. Eles queriam criar um portal do paciente que seus funcionários (nesse caso, membros da equipe de atendimento) pudessem usar e ajustar por conta própria, sem que sua equipe de desenvolvedores criasse esses aplicativos do zero. 

A empresa não pode ser identificada por motivos de conformidade. Se disséssemos a você, teríamos que matá-lo e, provavelmente, a nós mesmos. Isso dá uma dica do tipo de setor em que eles estão operando, onde as regras de conformidade e privacidade são compreensivelmente rigorosas. O resultado é que, para muitos desenvolvedores de aplicativos que lidam com informações de saúde, mergulhar nos domínios do no-code pode ser uma perspectiva um pouco desanimadora.  

Bem, não precisa ser assim. Essa é a mensagem de Veronica, que conseguiu criar com sucesso uma solução sem código combinando Twilio, Retool, Make e Google Sheets. O resultado é um portal do paciente que ajuda um único membro da equipe de atendimento a dar suporte a centenas de pacientes, em vez de apenas alguns. Aqui, Veronica nos apresenta seus principais aprendizados. 

O resultado é que, para muitos desenvolvedores de aplicativos que lidam com informações de saúde, mergulhar nos domínios do no-code pode ser uma perspectiva um pouco desanimadora".  

‍

1. Audite seus processos antes de tomar qualquer decisão arquitetônica

'Nem todas as partes do seu aplicativo precisam estar em conformidade com a HIPAA. Você só precisa garantir que as partes da arquitetura do seu aplicativo que lidam com PHI (informações de saúde protegidas) estejam em conformidade com os regulamentos da HIPAA. Por exemplo, queríamos criar uma automação que enviasse mensagens de texto aos pacientes que não tivessem feito determinada coisa. Então, nos conectamos ao banco de dados relacional para obter a lista de pacientes que correspondiam a essa condição. Essa lista foi então copiada automaticamente para uma planilha do Google, que não está em conformidade com a HIPAA. Isso não importava, pois os dados dos pacientes eram anônimos. A única coisa relevante para essa automação eram os números de telefone. Usamos a Make (ferramenta de automação) para conectar esses dados com o Twillio, onde criamos um chatbot sem código que você poderia enviar mensagens de texto e que enviaria respostas".

'Nem todas as partes do seu aplicativo precisam estar em conformidade com a HIPAA. Você só precisa garantir que as partes da arquitetura do seu aplicativo que lidam com PHI (informações de saúde protegidas) estejam em conformidade com os regulamentos da HIPAA'

2. Se possível, escolha uma ferramenta que ofereça conformidade com a HIPAA pronta para uso

Embora esse exemplo seja uma solução alternativa para as restrições da HIPAA, há muitas ferramentas sem código que afirmam estar em conformidade com a HIPAA. Isso significa várias coisas, mas a principal delas é que a plataforma sem código pode assinar um BAA(Business Associate Agreement) com você. JotForm, Caspio, KnackHQ, Formstack, Retool e AppSheet são algumas das que podem fazer isso. O uso de uma ferramenta compatível é crucial quando se trata de coisas como formulários de admissão, em que você quase sempre estará passando PHI. Isso significa que você não pode usar formulários do Webflow? Sim. Mas você ainda pode criar seu site no Webflow, incorporar um formulário em conformidade com a HIPAA dentro dele e ter o melhor dos dois mundos: uma excelente página de destino e um site incrível, sem infringir a lei.

‍

‍

3. Não deixe que os requisitos de conformidade o assustem, mas tenha cuidado com as permissões

Embora poucas ferramentas sem código sejam capazes de assinar um BAA (ou queiram que você faça upgrade para um plano Enterprise para isso), a maior parte do que é necessário para proteger os dados dos pacientes já é padrão do setor para ferramentas sem código. Como criptografia, alterações de registro e permissões. Por exemplo, dados criptografados e seguros são, em grande parte, o padrão e as alterações de registro estão disponíveis nos planos profissionais da maioria das ferramentas sem código existentes. É tentador usar uma ferramenta interna popular em vez de um banco de dados para organizar projetos e permitir que pessoas não técnicas façam alterações nos dados, mas lembre-se de que, com dados de saúde, as permissões em nível de linha também são obrigatórias. Esse é o principal motivo pelo qual o Google Sheets não é uma boa ideia para armazenar dados de pacientes (nem o Notion ou o Airtable).

4. Não se esqueça de documentar e treinar sua equipe

'Uma grande parte da conformidade não é apenas verificar as caixas com as ferramentas tecnológicas que você usa, mas ter os processos certos para verificar se tudo funciona. É imprescindível documentar adequadamente a sua arquitetura e treinar regularmente a sua equipe sobre ela. Usei a ferramenta de colaboração visual Whimsical incorporada em uma página do Notion, mas, na verdade, qualquer ferramenta de diagramação para fluxos de UX funciona, como Miro, Figma ou até mesmo o Google Slides. Um aspecto positivo da ausência de código é que ela é simples de entender, de modo que sua equipe pode realmente saber como os dados são processados. Chega de "o sistema não me deixa fazer isso"! Há um motivo pelo qual um enfermeiro não pode acessar determinados dados.