‍Para sectores muy regulados, como el sanitario, adentrarse en los dominios del no-código para crear aplicaciones puede ser una perspectiva un tanto intimidante. La fundadora de una agencia de desarrollo sin código nos cuenta lo que ha aprendido ayudando a una organización en este ámbito. *Se puede hacer.

Veronica Picciafuoco dirige Eldur Studio: una agencia de desarrollo sin código que ayuda a las organizaciones a implantar herramientas sin código y de bajo código, y muestra lo que se puede hacer sin desarrolladores. En un proyecto reciente, se le encargó un reto un poco delicado. Una empresa del sector de la telesalud quería crear un portal para pacientes con fines de integración, pero no quería ralentizar el desarrollo de su producto principal, la aplicación móvil. Querían crear un portal de pacientes que sus empleados (en este caso, los miembros del equipo asistencial) pudieran utilizar y modificar ellos mismos, sin que su equipo de desarrolladores tuviera que crear esas aplicaciones desde cero. 

La empresa no puede ser nombrada por razones de cumplimiento. Si se lo dijéramos, tendríamos que matarle a usted y probablemente a nosotros mismos". Esto da una idea del tipo de industria en la que operan, donde las normas sobre cumplimiento y privacidad son comprensiblemente estrictas. El resultado es que para muchos que crean aplicaciones que manejan información sanitaria, adentrarse en los dominios del no-código puede ser una perspectiva ligeramente desalentadora.  

Pues no tiene por qué. Este es el mensaje de Veronica, que ha conseguido crear una solución sin código que combina Twilio, Retool, Make y Google Sheets. El resultado es un portal de pacientes que ayuda a un solo miembro del equipo asistencial a atender a cientos de pacientes, en lugar de a un puñado. Veronica nos cuenta sus principales conclusiones. 

El resultado es que para muchas personas que crean aplicaciones que manejan información sanitaria, adentrarse en los dominios del no-código puede ser una perspectiva un tanto desalentadora".  

‍

1. Audite sus procesos antes de tomar decisiones arquitectónicas

No es necesario que todas las partes de su aplicación cumplan la HIPAA. Solo tienes que asegurarte de que las partes de la arquitectura de tu aplicación que manejan PHI (información sanitaria protegida) cumplen la normativa HIPAA. Por ejemplo, queríamos crear una automatización que enviara un mensaje de texto a los pacientes que no hubieran hecho una determinada cosa. Así que nos conectamos a la base de datos relacional para obtener la lista de pacientes que cumplían esa condición. A continuación, esa lista se copiaba automáticamente en una hoja de Google, que *no* cumple la HIPAA. No importaba, porque los datos de los pacientes eran anónimos. Lo único relevante para esta automatización eran los números de teléfono. Utilizamos Make (herramienta de automatización) para conectar esos datos con Twillio, donde creamos un chatbot sin código al que se podía enviar un mensaje de texto y que enviaba respuestas".

No es necesario que todas las partes de su aplicación cumplan la HIPAA. Solo tienes que asegurarte de que las partes de la arquitectura de tu aplicación que manejan PHI (información sanitaria protegida) cumplen la normativa HIPAA".

2. Si puede, elija una herramienta que ofrezca el cumplimiento de la HIPAA desde el primer momento.

Aunque este ejemplo es una solución a las restricciones de la HIPAA, hay muchas herramientas sin código que afirman cumplir la HIPAA. Esto significa un montón de cosas, pero la principal es que la plataforma sin código es capaz de firmar un BAA(Business Associate Agreement) con usted. JotForm, Caspio, KnackHQ, Formstack, Retool y AppSheet son algunas de las que pueden hacerlo. El uso de una herramienta compatible es crucial cuando se trata de cosas como formularios de admisión, donde casi siempre se pasa PHI. ¿Significa esto que no puede utilizar formularios Webflow? Sí. Pero puede crear su sitio web en Webflow, incrustar en él un formulario conforme a la HIPAA y tener lo mejor de ambos mundos: una gran página de aterrizaje y un sitio web excelente, y estar en paz con la ley".

‍

‍

3. No se deje asustar por los requisitos de cumplimiento, pero desconfíe de los permisos

Aunque no muchas herramientas sin código son capaces de firmar un BAA (o querrán que se actualice a un plan Enterprise para hacerlo), la mayor parte de lo que se necesita para proteger los datos de los pacientes ya es estándar en la industria sin código. Como el cifrado, el registro de cambios y los permisos. Por ejemplo, los datos encriptados y seguros son en gran medida el estándar y los cambios de registro están disponibles en los planes pro de la mayoría de las herramientas sin código que existen. Resulta tentador utilizar una herramienta interna popular en lugar de una base de datos para organizar proyectos y permitir que personas sin conocimientos técnicos realicen cambios en los datos, pero recuerda que con los datos sanitarios, los permisos a nivel de fila también son imprescindibles. Este es el principal motivo por el que Google Sheets no es una buena idea para albergar datos de pacientes (ni tampoco Notion o Airtable)".

4. No olvide documentar y formar a su equipo

Una parte importante de la conformidad no consiste únicamente en marcar las casillas con las herramientas tecnológicas que se utilizan, sino en disponer de los procesos adecuados para comprobar que todo funciona. Es imprescindible documentar adecuadamente la arquitectura y formar periódicamente al personal al respecto. He utilizado la herramienta de colaboración visual Whimsical incrustada en una página de Notion, pero en realidad sirve cualquier herramienta de diagramación para flujos de UX, como Miro o Figma o incluso Google Slides. Una cosa buena de no-código es que es fácil de entender, por lo que su equipo puede saber realmente cómo se procesan los datos. Se acabó eso de "el sistema no me deja hacerlo". Hay una razón por la que una enfermera no puede acceder a determinados datos".