Seudonimización HIPAA Safe Harbor en Aidbox: De FHIR a análisis sin exponer datos de pacientes

El problema con el análisis de datos sanitarios

Las organizaciones sanitarias disponen de datos valiosos, pero compartirlos es un campo minado. Un hospital quiere estudiar las tasas de lesión renal aguda en su población de UCI. Un equipo de investigación externo tiene la experiencia estadística necesaria. Los datos existen — cientos de miles de observaciones de laboratorio almacenadas como recursos FHIR en Aidbox. Pero entregar registros de pacientes sin procesar viola HIPAA.

La solución habitual es un pipeline ETL a medida: exportar datos, ejecutar un script para eliminar los identificadores, confiar en que nada se escape, y cargar los datos depurados en otro lugar. Esto es lento, propenso a errores y difícil de auditar. Cada nueva pregunta de investigación implica otro pipeline.

¿Y si la seudonimización ocurriera dentro de la base de datos, declarada junto a la vista que da forma a los datos?

La seudonimización como característica de ViewDefinition

Aidbox ahora admite la seudonimización por columna en ViewDefinitions. Se anotan las columnas con una extensión FHIR que especifica qué transformación aplicar. El compilador SQL envuelve cada expresión de columna con una función de PostgreSQL — los datos sensibles se transforman antes de llegar a la salida.

{
  "resourceType": "ViewDefinition",
  "name": "deident_observations",
  "status": "active",
  "resource": "Observation",
  "select": [{
    "column": [
      {
        "name": "patient_id",
        "path": "subject.getReferenceKey(Patient)",
        "extension": [{
          "url": "http://health-samurai.io/fhir/core/StructureDefinition/de-identification",
          "extension": [
            {"url": "method", "valueCode": "cryptoHash"},
            {"url": "cryptoHashKey", "valueString": "my-secret-key"}
          ]
        }]
      },
      {
        "name": "status",
        "path": "status"
      }
    ]
  }]
}

La columna patient_id lleva una extensión de seudonimización. Generará un hash HMAC-SHA256 en lugar de la referencia real del paciente — determinista (el mismo paciente siempre obtiene el mismo hash) e irreversible (no es posible recuperar el valor original a partir del hash). La columna status no tiene extensión y se transfiere sin cambios.

El constructor de ViewDefinition en la interfaz de Aidbox hace esto visual — haga clic en el icono de escudo en cualquier columna para elegir un método y configurar los parámetros:

Métodos disponibles

Dos métodos son especialmente relevantes para el patrón que vamos a explorar:

cryptoHash produce la misma salida para la misma entrada — lo que significa que puede usarlo para unir tablas. Aplique el hash al ID del paciente en dos ViewDefinitions distintas con la misma clave, y los hashes coincidirán. Esta es la base para la reidentificación.

dateshift desplaza todas las fechas dentro del mismo recurso con el mismo desplazamiento, preservando las relaciones temporales. Una diferencia de 3 días entre dos eventos sigue siendo de 3 días. El desplazamiento se deriva de HMAC(dateShiftKey, resource.id), por lo que es determinista por recurso pero impredecible sin la clave.

Ejemplo práctico: subcontratar la investigación de lesión renal aguda

Recorramos un escenario realista usando datos MIMIC-IV cargados en Aidbox — 100 pacientes de UCI, más de 800.000 observaciones.

El objetivo: Un hospital quiere que un equipo de investigación externo analice las tasas de lesión renal aguda (AKI) en su población de UCI. Los investigadores necesitan resultados de creatinina en laboratorio, pero no deben ver los identificadores reales de los pacientes ni las fechas exactas.

El enfoque: Crear dos tablas materializadas — un conjunto de datos seudonimizado para los investigadores, y una tabla de mapeo interna que conecta los IDs hasheados con los pacientes reales.

Diseño de la vista seudonimizada

Comenzamos con una ViewDefinition sobre el recurso Observation, filtrada a resultados de laboratorio de creatinina. Cuatro columnas, cada una con una estrategia de seudonimización diferente:

ID del paciente — la columna que más protección necesita. Aplicamos cryptoHash para convertir el UUID real en una cadena hexadecimal HMAC-SHA256 irreversible:

// ---8<--- snip
{
  "name": "patient_id",
  "path": "subject.getReferenceKey(Patient)",
  "extension": [{
    "url": "..de-identification",
    "extension": [
      {"url": "method", "valueCode": "cryptoHash"},
      {"url": "cryptoHashKey", "valueString": "aki-study-2026"}
    ]
  }]
}
// ---8<--- snap

Valor de creatinina y unidad — los datos clínicos que el investigador realmente necesita. Sin seudonimización — los valores de laboratorio no son identificadores:

// ---8<--- snip
{
  "name": "creatinine",
  "path": "value.ofType(Quantity).value",
  "type": "decimal"
},
{
  "name": "unit",
  "path": "value.ofType(Quantity).unit"
}
// ---8<--- snap

Fecha efectiva — desplazada por un desplazamiento determinista por recurso usando dateshift. Una diferencia de 3 días entre dos análisis sigue siendo de 3 días, pero la fecha real del calendario queda oculta:

// ---8<--- snip
{
  "name": "effective_date",
  "path": "effective.ofType(dateTime)",
  "extension": [{
    "url": "..de-identification",
    "extension": [
      {"url": "method", "valueCode": "dateshift"},
      {"url": "dateShiftKey", "valueString": "aki-study-2026"}
    ]
  }]
}
// ---8<--- snap

La tabla de mapeo

La segunda ViewDefinition es para la reidentificación — permanece de uso interno. Dos columnas sobre el recurso Patient, ambas apuntando a id: una en texto plano y otra hasheada con la misma clave que la anterior. Como cryptoHash es determinista, los IDs hasheados coincidirán entre ambas tablas.

Construcción en la interfaz

El constructor de ViewDefinition hace esto visual. Haga clic en el icono de escudo en cualquier columna para elegir un método de seudonimización y configurar sus parámetros:

Una vez guardado, materialice como tabla:

Lo que ve el investigador

El investigador consulta la tabla seudonimizada. Sin IDs de paciente reales, sin fechas reales:

SELECT * FROM sof.deident_creatinine LIMIT 5;

El patient_id es una cadena hexadecimal — el investigador puede agrupar por ella, contar pacientes distintos y seguir tendencias a lo largo del tiempo. Pero no puede revertirla para encontrar al paciente real.

Cálculo de la métrica

La lesión renal aguda se identifica habitualmente por la elevación de creatinina. Un criterio de cribado simplificado: creatinina superior a 1,5 mg/dL indica posible daño renal. El investigador ejecuta:

SELECT
  CASE
    WHEN creatinine <= 1.1 THEN 'Normal (≤1.1)'
    WHEN creatinine <= 1.5 THEN 'Elevated (1.1–1.5)'
    WHEN creatinine <= 3.0 THEN 'High (1.5–3.0)'
    ELSE 'Critical (>3.0)'
  END AS risk_category,
  count(*) AS observation_count,
  count(DISTINCT patient_id) AS patient_count,
  round(avg(creatinine)::numeric, 2) AS avg_creatinine
FROM sof.deident_creatinine
GROUP BY 1
ORDER BY 1;

19 pacientes tuvieron lecturas de creatinina superiores a 3,0 mg/dL — un umbral crítico que sugiere lesión renal grave. El investigador identifica a estos pacientes por sus IDs hasheados y envía los resultados al hospital.

Reidentificación para seguimiento clínico

El hospital une los resultados de la investigación con la tabla de mapeo interna — haciendo coincidir los IDs hasheados con los UUIDs reales de los pacientes:

SELECT
  m.real_id,
  max(o.creatinine) AS peak_creatinine,
  count(*) AS high_readings
FROM sof.deident_creatinine o
JOIN sof.patient_id_map m ON o.patient_id = m.hashed_id
WHERE o.creatinine > 3.0
GROUP BY m.real_id
ORDER BY peak_creatinine DESC
LIMIT 20;

Ahora el hospital sabe exactamente qué pacientes necesitan atención clínica — sin haber expuesto nunca sus identidades al equipo de investigación.

El panorama completo

La idea clave: la misma cryptoHashKey lo une todo. El investigador trabaja exclusivamente con identificadores hasheados. El hospital guarda la tabla de mapeo y la clave. La reidentificación ocurre solo de forma interna y solo cuando es necesario.

ViewDefinitions Safe Harbor predefinidas

Escribir reglas de seudonimización para cada tipo de recurso es tedioso. Proporcionamos io.health-samurai.de-identification.r4 — un paquete FHIR disponible a través del registro de artefactos de Aidbox con ViewDefinitions predefinidas para 17 tipos de recursos R4 habituales: Patient, Encounter, Observation, Condition, Claim, ExplanationOfBenefit, AllergyIntolerance, DiagnosticReport, MedicationRequest, MedicationDispense, MedicationAdministration, Immunization, Procedure, Specimen, DocumentReference, Practitioner y Location.

Cada ViewDefinition aplica las reglas Safe Harbor:

• cryptoHash en identificadores y referencias — coherente entre tablas para uniones
• dateshift en fechas clínicas — preserva las relaciones temporales
• birthDateSafeHarbor en Patient.birthDate — desplazamiento de fecha más redacción automática cuando el paciente tiene más de 89 años, según lo exigido por 45 CFR 164.514(b)(2)(i)(C)
• redact en nombres, direcciones y otros identificadores directos

Todos los parámetros de clave criptográfica están en blanco por defecto — configure sus propias claves antes de materializar. Instale el paquete mediante FAR, configure las claves, materialice como tablas y comience a consultar.

Primeros pasos

1. Active el modo fhir-schema — configure fhir.validation.fhir-schema-validation=true (obligatorio desde Aidbox 2604)
2. Instale io.health-samurai.de-identification.r4 mediante FAR, o escriba sus propias ViewDefinitions
3. Configure las claves criptográficas en cada ViewDefinition — las claves en blanco serán rechazadas
4. Materialice como tablas — $materialize con type=table o mediante el constructor de ViewDefinition
5. Consulte con SQL desde la consola SQL de Aidbox, Grafana o cualquier herramienta de BI

Para la referencia completa de métodos y detalles de parámetros, consulte la documentación de seudonimización. Para probar el escenario completo de esta entrada con un único docker compose up, consulte el ejemplo de seudonimización.