Mi primer experimento reproducible con ARIUTH

Mi primer experimento reproducible con ARIUTH

Llevo semanas dándole vueltas a un problema que me toca de cerca como investigador y como ingeniero: en salud, la historia clínica de un mismo paciente suele estar fraccionada entre distintas instituciones, en formatos distintos, y cualquier sistema de inteligencia artificial que intente intervenir sobre esos datos carga con un riesgo enorme si actúa sin control. De ahí nació ARIUTH — Adaptive Resilient Interoperability Unit for Health —
https://github.com/jaiderreyes/airuh-health/blob/main/README.md,Es un proyecto que vengo construyendo como parte de mi trabajo Investigativo con una premisa simple de enunciar y difícil de sostener: ninguna acción clínica debería llegar a ejecutarse sin pasar antes por un control de gobernanza explícito.

No «sin ser auditada después». Sin pasar antes.

Esta semana, después de bastante diseño en papel — revisión de estado del arte, una matriz de vacíos frente a los sistemas existentes, y una arquitectura completa documentada , decidí que ya era hora de dejar de diseñar y empezar a construir. Y hoy puedo contar, en primera persona, el primer resultado real: ARIUTH ya ejecutó, de punta a punta, su primer experimento reproducible.

Lo que construí primero

En vez de intentar levantar toda la arquitectura completa de una sola vez que además de ser poco manejable como despliegue, no me habría dejado ningún punto de medición claro como investigador , decidí construir por versiones. La primera, v0.1, tenía un objetivo deliberadamente pequeño: demostrar que existe un flujo real de autorización, aunque todavía no hubiera interoperabilidad entre formatos ni agentes de IA orquestando nada.

El núcleo mínimo quedó así: una identidad autenticada, un motor de políticas que decide si una acción se permite o no, y un estado clínico persistido en el estándar internacional FHIR R4.

La política que decide si una acción se autoriza o no vive fuera del código de la aplicación, como una regla declarativa independiente. En su versión más simple, para esta primera etapa, se lee casi como una frase:

package ariuth.v0_1
default decision := "DENY"
decision := "ALLOW" if {
    input.token.valid == true
    input.token.role == "clinician"
}

Nada se autoriza por omisión. Si no se cumple explícitamente la condición, la respuesta es negar.

El experimento

Generé una identidad clínica de prueba, autenticada correctamente. Esa identidad intentó registrar una observación clínica un resultado de hemoglobina, codificado con terminología LOINC, asociado a un paciente de prueba. En términos del estándar FHIR, algo así:

{
  "resourceType": "Observation",
  "status": "final",
  "code": {
    "coding": [
      { "system": "http://loinc.org", "code": "718-7", "display": "Hemoglobin [Mass/volume] in Blood" }
    ]
  },
  "valueQuantity": { "value": 13.5, "unit": "g/dL" }
}

Antes de que esa observación tocara siquiera el sistema de historia clínica, pasó por el motor de políticas. Con el rol correcto, la política autorizó la acción, y solo entonces el dato quedó persistido como un recurso FHIR verificable, con su propio identificador dentro del servidor clínico.

Después hice la prueba que en realidad más me importaba: repetí exactamente el mismo intento, pero con una identidad sin el rol autorizado. El resultado fue el que tenía que ser — la acción se bloqueó antes de tocar el dato clínico. No hubo escritura, no hubo excepción silenciosa, no hubo «primero guardamos y después revisamos». El sistema se comportó exactamente como está diseñado para comportarse: deny-by-default.

Por qué me importa tanto este resultado

Porque es la primera vez que el principio central de ARIUTH deja de ser una frase en un documento de arquitectura y se convierte en comportamiento verificado. Llevaba semanas escribiendo, en distintos documentos del proyecto, que «ninguna acción clínica llega al estado sin pasar por gobernanza». Hoy dejé de escribirlo y lo vi ejecutarse.

Como investigador, esto también me da algo que no tenía antes: un punto de medición real. A partir de aquí, cada versión del roadmap (v0.2 con auditoría y trazabilidad, v0.3 con la primera fuente de datos heterogénea real, v0.4 con resiliencia ante conectividad intermitente, hasta llegar a v1.0) va a tener su propio experimento documentado, no solo una lista de funcionalidades agregadas.

Lo que viene

El siguiente paso es incorporar un mecanismo de auditoría y trazabilidad completo que cada decisión de la política y cada escritura en el estado clínico quede registrada de forma verificable, no solo en un log de consola. Y después de eso, la primera fuente de datos real más allá del caso de prueba con el que arranqué hoy.

Voy a seguir documentando cada hito así, como bitácora de investigación aplicada. Si trabajas en interoperabilidad clínica, gobernanza de IA en salud, o simplemente te interesa ver cómo se construye un sistema de este tipo desde cero, este es apenas el primer capítulo.