Blockchain en salud: aplicaciones, privacidad y límites

La atención sanitaria y el suministro de medicamentos implican a organizaciones que necesitan intercambiar información de forma fiable. Un hospital puede necesitar comprobar de dónde procede un registro, mientras que un distribuidor debe seguir el recorrido de un producto. Blockchain ofrece una forma de compartir evidencias sobre esos procesos.

Su aplicación en salud exige decidir qué información se registra y quién puede consultarla. Esa distinción permite estudiar la trazabilidad sin asumir que los datos clínicos deban publicarse en una cadena. La confidencialidad del paciente y las responsabilidades de cada entidad forman parte del diseño desde el inicio.

Qué problema puede resolver

Un sistema sanitario puede necesitar compartir evidencia de autorizaciones, procedencia o versiones entre organizaciones. Un registro distribuido es una arquitectura posible cuando esas partes necesitan verificar un historial común. No mejora por sí solo la calidad clínica de los datos ni hace seguros todos los accesos.

La pregunta inicial no es qué red usar, sino qué participantes escriben, qué comprueban los demás y qué responsabilidad conserva cada organización. Una base de datos con controles de acceso y auditoría puede resolver el mismo problema con menos complejidad.

Datos clínicos y privacidad

No conviene publicar historias clínicas, diagnósticos o identificadores de pacientes en una red pública. Los hashes tampoco son automáticamente anónimos: pueden permitir vincular información cuando existen datos auxiliares. Cifrar información no garantiza que deje de ser dato personal.

Las directrices del EDPB sobre blockchain y datos personales sirven para evaluar responsabilidades, conservación y derechos. Antes de diseñar el registro hay que definir base jurídica, acceso, rectificación, supresión y análisis de riesgos. La arquitectura debe permitir cumplir las obligaciones aplicables durante toda su vida útil.

Aplicaciones que merece la pena evaluar

Evidencia de versiones y autorizaciones

Un registro puede conservar referencias a versiones y eventos de autorización mientras los documentos viven en sistemas clínicos controlados. La prueba demuestra qué se registró, no que el diagnóstico fuera correcto. Las revocaciones y correcciones deben seguir siendo operativas fuera de la cadena.

Trazabilidad de medicamentos

Compartir eventos firmados entre fabricantes, distribuidores y dispensadores puede facilitar comprobaciones de procedencia. Sigue haciendo falta vincular el identificador al producto físico y detectar registros falsos. La FDA explica sus requisitos de trazabilidad de medicamentos; usar blockchain no demuestra por sí solo su cumplimiento.

Investigación y documentación

Sellar referencias a protocolos o versiones de un estudio puede ayudar a detectar cambios posteriores. No valida los resultados, el consentimiento de participantes ni la calidad del ensayo. Debe conservarse el documento original y su contexto.

Ejemplo de diseño: compartir la versión de un protocolo

Supongamos que varias organizaciones participan en un estudio y necesitan comprobar qué versión de un protocolo estaba vigente. Una arquitectura posible conserva los documentos en repositorios controlados y registra referencias a las versiones aprobadas. No necesita publicar historias clínicas para cubrir esa finalidad.

El recorrido debe identificar quién aprueba una versión, quién puede consultarla y cómo se señala que ha sido sustituida. Si se detecta un error, conservar el historial no significa seguir presentando como vigente el documento incorrecto. La aplicación necesita mostrar la relación entre versión anterior y corrección, con permisos y responsabilidades definidos.

Este es un ejemplo de arquitectura, no una validación clínica ni un caso de cumplimiento ya resuelto. Antes de implantarlo hay que estudiar si sus referencias permiten identificar personas y cómo atender los derechos aplicables. La prueba técnica puede usar documentación sintética para evaluar el recorrido sin incorporar datos de pacientes.

La aceptación del piloto debería comprobar que cada organización recupera la versión correcta, que un actor sin permiso no puede declararla vigente y que una caída del registro no impide acceder a la documentación necesaria. Medir esas propiedades aporta más información que contar cuántas transacciones se han escrito.

Cómo evaluar un piloto

Define una hipótesis medible: tiempo de conciliación, errores de identificación o disponibilidad de evidencia. Prueba revocación de acceso, pérdida de claves, caída de participantes y recuperación. Compara con una solución convencional y publica los resultados como piloto hasta disponer de evidencia de operación real.

El valor se demuestra con un proceso mejor y responsabilidades claras, no con promesas de datos imposibles de manipular o privacidad garantizada.