El Blog de NessyImagina que se te ocurre crear un producto para el área de salud. Que gastas horas y horas y luego te das cuenta que la tecnología con la que construiste el producto no cumple con leyes o regulación…
Por qué salud es distinto a otras industrias
A veces fantaseo con crear es un software parecido a Mailchimp (email Marketing), pero centrado en la privacidad de los suscriptores. Si quisiera hacerlo, desde el punto de vista tecnológico, podría comenzar a programar un Producto Mínimo Viable (MVP) solo pensando en lo que quiero construir.
Pero para productos en salud, es otro el cuento. Cuando creas software en salud, la dignidad humana va primero (qué mal tener que ser explícito en esto…), y esto te hará cuestionar muchas cosas a la hora de construirlo. Sí, lo siento, aquí no tiene entrada el “move fast and break things” clásico del mundo start-up 🤭
En consecuencia, en esta área hay muchas aristas de las que hay que preocuparse y tenemos que ser muy conscientes del stack tecnológico que elegimos. O al menos más si lo comparamos con otros rubros como educación, empleabilidad o productividad (lo digo porque tengo experiencia en ellos).
Dicho esto, ¿cómo saber si mi elección de tecnología está bien para salud? Y en particular, ¿Es razonable usar Firebase para crear este tipo de productos?
A modo resumen: Firebase es una muy buena opción, pero hay que tener ojo 👀 por eso partiré con un breve resumen el Marco regulatorio en que nos movemos, y luego hablaré sobre Firebase en sí.
Nota: Firebase es un conjunto de herramientas que te simplifica la creación de aplicaciones web o móviles. Está destinada a programadores que quieren iterar sus productos más rápido.
El marco regulatorio ⚖️
Aviso: No soy experto en temas regulatorios. De profesión soy Ingeniero Civil en Computación y algo manejo por formación (Diplomado de Emprendimiento e Innovación en Salud Digital) y por investigación propia. Así que puede ser que lo que te diga aquí no sea 100% preciso, y ante dudas es mejor consultar con una abogada.
Las leyes más bakanes que buscan proteger a los usuarios o pacientes y su información son el GDPR (Europa) e HIPAA (Estados Unidos):
- GDPR es una regulación de la UE implementada para proteger la información de identificación personal (PII) del usuario y hacer que las empresas cumplan con un estándar más alto en lo que respecta a cómo recopilan, almacenan y usan estos datos.
- HIPAA es una ley creada para proteger la información confidencial de la salud del paciente (PHI) para que no se divulgue sin el consentimiento o conocimiento del paciente.
Lamentablemente en Chile no llegamos a esos niveles. Sin embargo, sí hay una regulación que cumplir:
¿Cuándo hay que cumplir con GDPR o HIPAA?
Tengo entendido que si tu software va a funcionar para pacientes de USA (ejemplo, colocas que tu APP esté disponible para descarga en ese país), entonces tienes que cumplir HIPAA. Mientras que si tu software tiene usuarios residentes en Europa, tendrás que cumplir con GDPR.
Así que una regla general es que tienes que preocuparte de la regulación del país donde quieres implementar tu solución. Por ejemplo, si es solo en Chile 🇨🇱, no tienes que cumplir GDPR ni HIPAA. Solo estás obligado a cumplir con la regulación local, donde está la ley 19.628 y la 20.584
Sin embargo, es una buena práctica crear software pensando en cumplir regulaciones más estrictas, ya que estas fueron creadas para proteger a los pacientes (HIPAA) y es una forma de ser proactivo, sobre todo cuando nuestra regulación no lo hace.
Algunos aspectos importantes de la regulación Chilena 🇨🇱
En mi emprendimiento previo, “TeeshMe”, un estudiante podía subir una foto de un ejercicio de logaritmos y un profesor le iba a decir paso a paso cómo resolverlo. Con el tiempo, podríamos haber creado algoritmos (con inteligencia artificial) que entregaran la solución automáticamente.
Esto está perfectamente bien. Pero, ¿qué pasa si quiero automatizar el diagnóstico de cáncer uterino con un algoritmo?
Antes de darte la respuesta, algunos datos que son de vital interés al momento de crear software en salud en Chile:
- Ficha clínica: es un documento donde se registran antecedentes relacionados con la salud de las personas (sí, puede ser digital).
- Tratamiento de datos: básicamente cualquier operación (automatizada o no) sobre datos.
Sobre la ficha clínica:
- Toda información que surja de la Ficha clínica se considera como información sensible.
- Los únicos que tienen acceso a la ficha clínica son prestadores relacionados directamente con la atención (además del titular o su representante legal). Es decir, un administrador de sistema o un programador no debería poder acceder a dicha información.
Sobre tratamiento de datos:
- Solo puedes hacer tratamiento de datos sensibles (ej.: Ficha clínica) cuando la ley lo autorice, exista consentimiento del titular o sean datos para determinar beneficios de salud a sus titulares.
En consecuencia:
- ¿Quieres utilizar datos para una investigación científica? I’m sorry, pero tienes que informar a las personas involucradas y estas tienen derecho a elegir su incorporación.
- ¿Quieres mostrar una imagen de una radiografía de un paciente en tu página web? Tienes que tener su autorización escrita.
- ¿Quieres crear un algoritmo predictivo en base la información de los pacientes en tu sistema? De seguro esa información es parte de la ficha clínica, por ende pasa a ser un dato sensible y en consecuencia estás haciendo “tratamiento de datos”, lo cual requiere que el titular lo consienta expresamente (da igual si lo tienes anónimo o no 😉).
Como puedes ver, automatizar la respuesta a una pregunta matemática (TeeshMe) es posible, ya que una imagen de ese estilo no es información sensible ni tampoco dato personal. Pero en el caso de automatizar un diagnóstico, este utiliza información sensible y personal, por tanto, es obligación contar con el consentimiento escrito del paciente.
Ahí radica la diferencia con otro tipo de aplicaciones. En salud, es muy fácil que información que recolectas sea considerado un dato sensible, y por ende, para hacer “tratamiento” (básicamente cualquier algoritmo que los use) necesitarás tener consentimiento escrito 😱
Sí, si puedes alojar la información en servidores extranjeros 🙊
Hay un mito persistente que dice que no puedes alojar información de pacientes en servidores externos. La verdad es que sí puedes, así que no hay problemas con que uses algún proveedor Cloud como Firebase, Heroku, AWS o Digital Ocean. Ale Mauro escribió sobre esto en ForoSaludDigital.
Puse una sección con esta información porque de verdad es un concepto erróneo que incluso informáticos que trabajan en salud lo han hecho perdurar (lo he escuchado en distintos cursos que he ido como estudiante).
Ahora sí… El caso de Firebase 🔥
Para crear Apposito, elegimos un stack tecnológico (conjunto de tecnologías) que se ajustara a mi experiencia y a la de Eliana. Esto nos llevó a elegir Firebase, ya que ambos teníamos conocimientos y experiencia en esta tecnología (en este post hay más información de la decisión).
Ya sabíamos las funcionalidades que íbamos a programar y que eran posible de implementar con Firebase. La pregunta que quedaba era: ¿es razonable usar esta tecnología en salud? ¿Existe alguna razón para no usarla?
Firebase y regulación ⚖️
La respuesta corta es: la mayoría de servicios de Firebase cumplen con HIPAA (puedes ver el listado completo aquí). Y al cumplir con HIPAA, creo ya cumples con todo lo que te exige la ley en Chile 🎉 y a la vez de GDPR (o al menos, gran parte).
En nuestro caso, usamos Firestore (base de datos), Firebase Cloud Functions (operaciones en la nube), Cloud Storage (para guardar imágenes) y Cloud Identity (para inicio de sesión), todos cubiertos por HIPAA.
Algunos servicios relevantes que no cumplen la regulación son Crashlytics (para reporte de errores en aplicaciones móviles) y Firebase Authentication (para manejar inicios de sesión). Ambos pueden ser muy importantes a la hora de crear APPs en salud, ¿qué hacer entonces?
- En el caso de Crashlytics, puedes usar una alternativa que cumpla HIPAA, aunque la mayoría son de pago. O simplementar utilizar el diagnóstico por defecto de Android e iPhone. Quizás hay información extra que no tendrás, pero al menos no estarás ciego.
- En el caso de Firebase Authentication, puedes usar Cloud Identity (que fue lo que usamos nosotros).
Nota importante: si haces aplicaciones para profesionales de salud (ejemplo, para enfermeras), quizás no es tan importante con que todo lo que uses cumpla HIPAA. Mi razonamiento es que la información de la persona que usará la APP no es PHI (información protegida de salud). Sin embargo, la información que ingresen de terceros si es PHI, y es ahí donde hay que tener cuidado.
Firebase y casos de uso que querrías implementar en salud 💉
A grandes rasgos, hay muchos casos de uso que son posibles de realizar con Firebase. A continuación van 4 ejemplos de casos de uso y qué tecnología de Firebase usar para implementarlo (será un poco más técnica esta parte 👨💻👩💻)
Ficha clínica, Información de pacientes, Información de profesionales, etc.
Puedes utilizar Firestore, ya que es una base de datos.
Para cumplir con regulación (por ejemplo, hacer que una enfermera pueda ver información solo de sus pacientes), tendrás que implementar cierto manejo de permisos, para lo cual tienes que usar Firestore Security Rules.
Imágenes de pacientes (lunares, heridas, etc.), archivos con información de exámenes, etc.
Puedes usar Cloud Storage, ya que te permite almacenar distintos tipos de archivos (PDF, imágenes, etc.).
Si quieres manejar permisos de lectura sobre estos archivos, tendrás que utilizar Cloud Storage Security Rules.
Sin embargo, para permisos más elaborados, tendrás que dejar todos los archivos privados y permitir que usuarios accedan a ellos a través de Cloud Function (donde puedes manejar la lógica de acceso de forma muy personalizada).
Historial de cambios y de acceso
Es una muy buena práctica saber quién hizo qué respecto a la información de los pacientes, de manera de tener un historial de cambios.
Firestore tiene utilidades que te ayudan. Por ejemplo, con Cloud Firestore Triggers puedes crear fácilmente historiales de la ficha de un paciente. Sin embargo, la gran dificultad es que no puedes saber quién hizo los cambios, lo cual es muy relevante en salud.
Tampoco hay una manera fácil de saber qué usuario está leyendo cierta información (ej.: ¿quién leyó los datos personales de un paciente particular?).
Interoperabilidad
Puedes hacer que tu solución sea interoperable (que se pueda comunicar con otros sistemas) implementando una capa de HL7 FHIR con Cloud Functions. No es una tarea fácil, pero es posible.
⚠️ No por usar un servicio que cumple con la regulación estás cumpliendo con la regulación
Para construir una aplicación, de seguro que vas a usar servicios en la nube o código de terceros.
Podríamos decir que todos estos servicios externos que uso son legos con los cuales construyo mi aplicación.
Si mis piezas cumplen con cierto estándar, al armar mi figurita también tengo que preocuparme de seguir cumpliendo el estándar. Así que no es suficiente con que las partes pequeñas cumplan, la figura final también debe hacerlo.
Ejemplo un poco más técnico: usar Firestore para guardar datos de ficha clínica donde toda la información está pública. Firestore cumple HIPAA, pero como no me preocupé de dejar la información privada, cualquier persona puede ver la información y por tanto, rompo HIPAA.
Conclusión
Cuando creamos software en salud, debemos ser muy cuidadosos con los servicios que usamos y con las librerías que instalamos. Por un lado está la parte regulatoria, y por otro el aspecto ético: tenemos la obligación ética de crear aplicaciones que respeten la dignidad humana.
En este sentido, Firebase es una excelente herramienta que te permite prototipar rápido y cumple con regulaciones como HIPAA y GDPR ❤️ además tiene distintas funcionalidades que te permitirán lograr que la aplicación que crees también cumpla con la ley.
Sin embargo, mientras desarrollábamos Apposito, nos encontramos con que algunos casos de uso como historial de cambios o historial de acceso no son tan fáciles de implementar debido a limitaciones en Firestore.