Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Interoperabilidad de datos de salud

Los niveles técnico, sintáctico, semántico y organizativo de interoperabilidad, los estándares que utiliza Anpheros (FHIR R4, IPS, SMART on FHIR, HL7 v2) y por qué la procedencia hace que los datos intercambiados sean confiables.

La interoperabilidad de datos de salud es la capacidad de diferentes sistemas —aplicaciones, clínicas, laboratorios, hospitales, servicios de IA— para intercambiar datos de salud y utilizarlos sin tener que reinterpretarlo manualmente. Anpheros la aborda almacenando cada registro en los formatos que otros sistemas ya entienden (HL7 FHIR R4 con sistemas de códigos estándar), intercambiándolo a través de protocolos estándar (FHIR REST, SMART on FHIR, el Resumen Internacional del Paciente, mensajes de laboratorio HL7 v2) y manteniendo el contexto que hace que los datos intercambiados sean confiables: quién lo escribió, cuándo y con el consentimiento de quién.

Cuatro niveles de interoperabilidad

La mayoría de los proyectos de integración fallan a nivel semántico y organizacional, no técnico. La codificación en el momento de la escritura y el registro de la procedencia de cada valor son lo que hacen que los datos de una fuente sean utilizables en otra.

Estándares que Anpheros utiliza

• HL7 FHIR R4. Cada registro está compuesto por recursos FHIR — 26 tipos — buscables y versionados, con una CapabilityStatement en /fhir/R4/metadata. Plataforma FHIR
• International Patient Summary (IPS). Patient/{id}/$summary devuelve un paquete de documento IPS, validado con el validador oficial de HL7 contra hl7.fhir.uv.ips#1.1.0 con 0 errores. El IPS es el formato de resumen destinado a la atención transfronteriza en Europa.
• Reglas de informes de laboratorio de HL7 Europe. Los resultados de laboratorio se verifican al escribir; las brechas se informan en la cabecera de respuesta Anpheros-Conformance (asesoramiento hoy). Observation/$validate?profile=eu-lab ejecuta la verificación bajo demanda.
• SMART on FHIR. Las aplicaciones de terceros acceden a un registro a través de OAuth 2.1 con PKCE y ámbitos de paciente SMART v2; descubrimiento en /fhir/R4/.well-known/smart-configuration. El grupo de pruebas de lanzamiento independiente de la suite Inferno SMART App Launch STU2 se supera; el lanzamiento de EHR no es compatible todavía.
• HL7 v2. Los resultados de laboratorio llegan como mensajes ORU^R01, así como en formato CSV o JSON, y se convierten en Observaciones FHIR. Conector de laboratorio
• Espacio Europeo de Datos Sanitarios. FHIR R4 y el IPS son los formatos en los que se basa el EHDS para resúmenes de pacientes y resultados de laboratorio; Anpheros los sigue. Esto es una alineación con los formatos, no una certificación.

Patrones de intercambio

1. Acceso de aplicación consentido — una aplicación solicita al paciente los ámbitos (scopes), lee y escribe en el registro a través de FHIR o REST, y pierde el acceso cuando el paciente lo revoca.
2. Intercambio de documentos — el registro, o su resumen, sale como un paquete FHIR ($everything, $summary).
3. Resultados entrantes — los laboratorios y clínicas escriben en el registro en nombre de su organización; el paciente ve quién escribió qué.
4. Eventos — se informa a los suscriptores de que algo ha cambiado (solo IDs, nunca contenido clínico) y leen lo que tienen permitido.

Procedencia: interoperabilidad en la que puede confiar

Los datos que viajan entre sistemas pierden su contexto a menos que el contexto viaje con ellos. En Anpheros, cada versión de cada recurso registra:

• el tipo de autor — paciente, profesional, dispositivo, importación o IA;
• la organización en cuyo nombre se escribió y, cuando se nombra, el profesional;
• el sistema de origen y su ID de registro allí (X-Anpheros-Source-System, X-Anpheros-Origin-Id).

Los valores producidos por IA se etiquetan como tales y se mantienen separados de los hechos clínicos cuando se construye un contexto para un modelo.

Identidad entre aplicaciones

Cada aplicación ve su propio identificador para la misma persona (IDs de pares), por lo que los registros no pueden correlacionarse entre aplicaciones a espaldas del paciente. Las referencias a personas fuera del ámbito de una aplicación se enmascaran. La interoperabilidad ocurre a través del consentimiento, no a través de identificadores compartidos.

Relacionado

• Cómo normalizar datos médicos: códigos, unidades, fechas, duplicados, validación
• Procedencia de datos médicos explicada: quién escribió qué y cómo registrarlo
• Cómo integrar sistemas de clínica con un backend FHIR: tutorial paso a paso para EMRs de clínica
• Cómo importar resultados de laboratorio a un registro FHIR: tutorial paso a paso con CSV y HL7 v2
• Plataforma FHIR
• Integraciones de salud
• Sistemas de códigos FHIR
• API de salud
• Infraestructura de datos médicos
• DICOM vs FHIR: datos de imagen y datos clínicos, y cómo se conectan
• API de resultados de laboratorio: HL7 v2 y FHIR para resultados de laboratorio
• FHIR vs HL7 v2: mensajes y recursos comparados
• El Espacio Europeo de Datos Sanitarios (EHDS) para desarrolladores

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card