Datos Clínicos para Uso Secundario e Investigación: Arquitectura para una Segunda Vida de los Datos

El uso secundario se refiere a la aplicación de datos clínicos recopilados durante la atención rutinaria a propósitos más allá del tratamiento inmediato del paciente. La definición clásica de AMIA lo enmarca como la aplicación de información de salud personal a usos fuera de la prestación directa de atención sanitaria — incluyendo análisis, investigación, medición de calidad y seguridad, salud pública y pago [1]; la lista actual se extiende naturalmente a la farmacovigilancia, la evaluación de tecnologías sanitarias y el entrenamiento de modelos de IA. El mundo regulatorio ha alcanzado a la pregunta arquitectónica: el Reglamento del Espacio Europeo de Datos de Salud de la UE (UE 2025/327), en vigor desde marzo de 2025, establece un marco legal dedicado para el uso secundario de datos de salud electrónicos — acceso basado en permisos a través de organismos de acceso a datos de salud, derechos de exclusión voluntaria de los pacientes, y entornos de procesamiento seguro obligatorios desde los que no se pueden descargar datos personales — con la mayoría de las normas de uso secundario aplicándose desde marzo de 2029 [3]. Para los arquitectos, el mensaje es directo: un CDR diseñado únicamente para el flujo de trabajo asistencial cumplirá los requisitos de uso secundario de la misma manera que la mayoría de los sistemas cumplen los requisitos para los que nunca fueron diseñados — tarde, con alto costo y de forma parcial. La completitud y representatividad, la gobernanza del consentimiento y la privacidad, la desidentificación y la construcción confiable de cohortes deben diseñarse desde el inicio.

Separar el Registro Primario del Entorno de Investigación

El principio de diseño fundamental — y la forma que marcos como el EHDS institucionalizan con sus entornos de procesamiento seguro [3] — es la separación arquitectónica entre el registro clínico primario y el entorno de uso secundario. El CDR permanece como el registro identificado, versionado y autoritativo que sirve a la atención; un entorno distinto — un almacén de datos, un mart de datos de investigación o un nodo de analítica federada — recibe un extracto gobernado: desidentificado, enriquecido con variables derivadas y organizado para patrones de consulta analítica en lugar de patrones de flujo de trabajo clínico. Los dos entornos difieren en casi todas las dimensiones arquitectónicas, que es precisamente por qué fusionarlos fracasa:

El pipeline de transformación entre ambos es un punto de integración de primera clase, no un proceso ETL secundario. En nuestra experiencia debe manejar tres responsabilidades como etapas explícitas y verificables: filtrado por consentimiento y exclusión voluntaria (qué registros pueden fluir, según el propósito); aplicación de reglas de desidentificación; y estandarización de vocabulario — mapeando códigos locales a SNOMED CT, CIE, LOINC y ATC según lo requiera el contexto de investigación, ya que las definiciones de cohortes son tan confiables como la codificación que las sustenta. Sobre la desidentificación específicamente, la Regla de Privacidad HIPAA de EE.UU. proporciona el marco de referencia canónico: dos métodos reconocidos — Determinación por Experto (un experto calificado determina formalmente que el riesgo de reidentificación es muy pequeño) y Puerto Seguro (eliminación de los identificadores enumerados) — con la importante advertencia oficial de que ambos, incluso aplicados correctamente, conservan algún riesgo residual de reidentificación [2]. Arquitectónicamente, eso significa que la desidentificación es un proceso de riesgo gestionado con reglas documentadas y revisión periódica, no una transformación de casilla de verificación.

Analítica Federada: Mover la Pregunta, No los Datos

Para la investigación multi-sitio, la analítica federada está ganando terreno como alternativa que preserva la privacidad frente a la centralización de datos: cada sitio participante ejecuta análisis aprobados contra sus datos locales y devuelve solo resultados agregados o con protección de privacidad al investigador coordinador. El patrón cuenta con ecosistemas maduros detrás. La plataforma i2b2, utilizada en más de 200 sitios en todo el mundo, adopta un enfoque ontológico para el descubrimiento de cohortes sobre un almacén en esquema estrella, mientras que el Modelo de Datos Común OMOP, administrado por la comunidad OHDSI, fue diseñado desde el principio como un modelo de analítica compartido para que el mismo código de análisis pueda ejecutarse de forma idéntica en cada sitio [4]. Un entorno nativo en openEHR aporta su propio instrumento: dado que las consultas AQL se escriben contra arquetipos en lugar de esquemas físicos, la misma consulta está diseñada para ser compartible entre sistemas conformantes y fronteras empresariales [5] — que es exactamente la propiedad que la ejecución federada requiere.

Los arquitectos que evalúan la federación deben valorar tres aspectos más allá de las herramientas: la estandarización de consultas entre implementaciones heterogéneas (una consulta que significa cosas sutilmente diferentes en distintos sitios produce resultados confiables pero incorrectos); las características operacionales como la latencia de red, la disponibilidad de los sitios y los límites de tamaño de los conjuntos de resultados; y — lo más difícil — el modelo de gobernanza para aprobar, ejecutar y auditar consultas remotas: quién revisa un análisis propuesto, qué umbrales de agregación protegen contra la reidentificación por recuentos pequeños, y cómo se registra cada ejecución remota. En nuestra experiencia, el diseño de la gobernanza, no la tecnología, determina si una red federada sobrevive a su primer incidente.

Consecuencias de Diseño para el CDR

Trabajando hacia atrás, un CDR destinado a alimentar bien el uso secundario necesita cuatro propiedades desde el primer día: captura de datos basada en estándares y vinculada a terminología, porque la limpieza retrospectiva de codificación es el trabajo de calidad de datos más costoso que existe; consentimiento y exclusión voluntaria representados como datos estructurados y consultables, no formularios escaneados, para que el pipeline de extracción pueda filtrar mecánicamente; registros versionados y temporalmente fieles, para que las cohortes puedan reconstruirse a la fecha de corte de un estudio y los estudios puedan reproducirse; y una separación limpia entre el sujeto identificado y el contenido clínico, para que la seudonimización sea un ejercicio de gestión de claves en lugar de una cirugía de datos. Ninguna de estas es exótica — las cuatro son propiedades naturales de un repositorio openEHR bien diseñado — pero en nuestra experiencia cada una es casi imposible de incorporar retroactivamente en un almacén que las combinó.

El Rol de CaboLabs

CaboLabs diseña plataformas de datos clínicos pensando en la segunda vida de los datos. Nuestro repositorio de datos clínicos nativo en openEHR, Atomik, proporciona las propiedades que este artículo defiende en la fuente: captura de datos validada por plantillas y vinculada a terminología, registros versionados con plena fidelidad temporal, separación arquitectónica de datos demográficos del contenido clínico, y consultas AQL basadas en arquetipos que hacen la lógica de cohortes portable entre sistemas conformantes. Alrededor del repositorio, nuestra práctica de consultoría cubre el diseño de pipelines de uso secundario — filtrado de consentimiento, flujos de trabajo de desidentificación, mapeo de vocabulario a SNOMED CT, LOINC y CIE — y arquitectura de datos de investigación en ecosistemas de openEHR, FHIR y HL7.

Si estás construyendo un entorno de datos de investigación sobre operaciones clínicas, preparándote para marcos como el EHDS, o quieres un CDR cuyos datos valga la pena reutilizar, habla con nosotros en cabolabs.com — los buenos datos de investigación no se extraen, se diseñan desde el origen.