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

Integraciones de salud

Patrones de integración soportados hoy: informes de laboratorio en una llamada, clínicas que escriben en nombre de una organización, dispositivos, apps de terceros consentidas, webhooks y SDKs — y lo que no está disponible.

Una integración sanitaria conecta un sistema que produce o necesita datos de salud — un laboratorio, una clínica, un dispositivo, otra aplicación — al registro del paciente. Con Anpheros, cada integración pasa por la misma API y las mismas reglas: los datos se escriben como HL7 FHIR R4, se atribuyen a su origen, son visibles para el paciente y se comparten con otras partes solo bajo el consentimiento del paciente. Esta página describe los patrones de integración que la plataforma soporta hoy.

Explore el directorio de integraciones de Anpheros para ver cada integración con su estado verificado (disponible, beta o guía para desarrolladores), los datos y recursos FHIR que intercambia, su dirección, autenticación y documentación.

Laboratorios: informes completos en una sola llamada

Un laboratorio, o cualquier sistema que contenga informes de laboratorio, envía un informe completo y la plataforma convierte cada resultado en un laboratorio Observation:

curl -X POST https://platform.anpheros.com/v1/patients/$PID/labs/import \
     -H "Authorization: Bearer $KEY" -H "Content-Type: text/csv" \
     -H "X-Anpheros-Source-System: labx" -H "Idempotency-Key: report-2026-0917-77" \
     --data-binary @report.csv

• Formatos: CSV (encabezados en rumano o inglés, se acepta coma decimal), HL7 v2 ORU^R01 y JSON.
• Los marcadores se mapean a LOINC cuando el informe proporciona un código o el nombre coincide con la terminología de la plataforma; otros conservan el código propio del laboratorio y se listan como unmapped.
• Cada fila recibe un identificador estable, por lo que reenviar el mismo informe omite lo que ya se importó.
• Hasta 500 filas por solicitud; cada resultado lleva la procedencia nombrando el sistema de origen y el informe.

Detalles: Conector de laboratorio.

Clínicas: escribiendo en nombre de una organización

Las clínicas y las personas que trabajan en ellas son recursos de directorio (Organization, Practitioner, PractitionerRole). El sistema de una clínica puede entonces indicar quién está detrás de cada solicitud:

• X-Anpheros-Acting-As: PractitionerRole/<id> — el profesional que trabaja a través de su aplicación; escrito en el registro de acceso y mostrado al paciente por nombre;
• X-Anpheros-On-Behalf-Of: Organization/<id> — la organización para la que se realiza una escritura;
• X-Anpheros-Author-Ref: Practitioner/<id> — el autor registrado en Provenance.

Con el consentimiento del paciente, la clínica lee el registro completo, incluyendo lo que otras organizaciones escribieron, y cambia solo lo que escribió ella misma. Varios recursos pueden ser escritos atómicamente con un paquete transaction de FHIR (POST /fhir/R4).

Un ejemplo práctico, desde el directorio hasta una visita escrita como una sola transacción: Cómo integrar sistemas de clínicas con un backend FHIR.

El flujo consentimiento → laboratorio Observation escrito por un proyecto de clínica → notificación en la aplicación del paciente se ha ejercido de extremo a extremo con un proyecto de clínica de prueba.

Dispositivos y wearables

Las mediciones de los dispositivos son Observations con author_type: "device" y un código LOINC: frecuencia cardíaca, presión arterial, SpO₂, peso, glucosa, pasos, duración del sueño y otros (FHIR code systems). Anpheros Daily escribe los resúmenes diarios que lee de Apple Health y Health Connect como Observations de la misma manera. Anpheros no se conecta directamente a las nubes de los proveedores de dispositivos; tu aplicación o backend lee el dispositivo y escribe el resultado. Cómo leer Apple Health, Health Connect y Samsung Health y mapear cada métrica a LOINC: Wearable data in FHIR.

Aplicaciones de terceros: acceso consentido

Una aplicación que desea datos que una persona ya tiene en Anpheros se registra una vez y solicita consentimiento a través de OAuth 2.1 con PKCE (lanzamiento independiente de SMART on FHIR):

1. GET /oauth/authorize?...&scope=patient/Observation.rs?category=laboratory offline_access — la página de consentimiento alojada;
2. la persona elige el registro y la duración (30, 90, 180 o 365 días);
3. POST /oauth/token intercambia el código por un token de acceso (30 minutos) y un token de actualización rotatorio (30 días);
4. la aplicación solo ve a ese paciente, solo dentro de sus ámbitos, bajo su propio ID de emparejamiento.

Autenticación y OAuth

Eventos: reaccionando a cambios

En lugar de consultar, registre un webhook. Las entregas se firman con HMAC-SHA256, se reintentan con backoff hasta por 24 horas y llevan IDs, nunca contenido clínico. Cuando otro proyecto escribe en un registro al que tiene acceso, el evento lo indica (data.external: true, con la fuente). Webhooks

SDKs

Los SDKs de TypeScript (@anpheros/sdk) y Dart / Flutter (anpheros_sdk) implementan todo lo anterior: importación de laboratorio (labs.importCsv, labs.importHl7, labs.importItems), OAuth con PKCE, gestión de webhooks y verificación de firmas. SDKs

Lo que no está disponible

• Conectores prefabricados a sistemas EHR (Electronic Health Record) o sistemas de información de laboratorio específicos; las integraciones se construyen contra la API.
• Lanzamiento SMART EHR (lanzamiento dentro de un EHR); solo se admite el lanzamiento independiente.
• Integraciones directas con proveedores de dispositivos.

Relacionado

• Cómo integrar sistemas de clínicas con un backend FHIR: tutorial paso a paso para EMRs de clínicas
• Cómo normalizar datos médicos: códigos, unidades, fechas, duplicados, validación
• Cómo importar resultados de laboratorio a un registro FHIR: tutorial paso a paso con CSV y HL7 v2
• Interoperabilidad de datos de salud
• API de salud
• Arquitectura
• Casos de uso

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