Plataforma · Integraciones
Mira™ Integraciones.
Mira™ se lleva bien. Sincronización EMR, cámaras de compensación, SSO, telefonía, contabilidad — se conecta con lo que ya ejecuta.
Integraciones que su equipo de IT puede verificar y su equipo de cumplimiento puede auditar.
Las organizaciones de hospicio no existen de forma aislada. Los expedientes de pacientes se originan en EMRs. Los reclamos se enrutan a través de cámaras de compensación. El personal se autentica a través de proveedores de identidad empresarial. Los ingresos se registran en sistemas de contabilidad. Las familias y los equipos de cuidado se comunican por SMS y voz. Cada uno de estos puntos de contacto es una posible brecha de integración — un lugar donde los datos deben reingresarse, donde un retraso de sincronización produce un reclamo desactualizado, donde un fallo de SSO deja a un clínico fuera del expediente de una visita.
Mira™ trata las integraciones como infraestructura de primer orden, no como conectores adicionales. La sincronización EMR se basa en OAuth con renovación automática de tokens — los tokens de acceso expiran según el calendario del proveedor EMR; Mira™ los rota automáticamente sin intervención manual. Las conexiones de cámaras de compensación se configuran por pagador, no por organización — así Availity gestiona Medicare Parte A mientras Change Healthcare gestiona un pagador comercial específico, y el enrutamiento es invisible para el personal de facturación. El SSO es SAML 2.0 y OIDC, con MSAL B2C para organizaciones Microsoft/Azure AD. Los webhooks llevan firmas HMAC-SHA256 para que sus sistemas puedan verificar la autenticidad del payload sin depender de la seguridad de la red.
Cada evento de integración se registra en la misma infraestructura de auditoría que los eventos de acceso PHI. Cuando falla la renovación de un token, el evento se registra. Cuando se reintenta la entrega de un webhook, el contador de reintentos y el último código HTTP se registran. Cuando se rechaza una aserción SAML, el motivo del rechazo queda registrado. Estos registros son consultables por los oficiales de cumplimiento junto a los eventos de auditoría PHI — sin herramienta de monitoreo de integraciones separada.
Superficies de integración
- ✓ Sincronización EMR — Epic + Cerner vía OAuth; FHIR R4 Patient, Encounter, Observation; write-back bidireccional
- ✓ Cámara de compensación — Availity + Change Healthcare; enrutamiento por pagador; procesamiento EDI 277/835
- ✓ SSO — SAML 2.0, OIDC, MSAL B2C; Azure AD, Okta, Google Workspace probados
- ✓ Webhooks + REST API — eventos firmados con HMAC-SHA256; reintento de 24h con backoff exponencial
- ✓ Contabilidad + telefonía — asientos QuickBooks; SMS + voz saliente con Twilio
Lo que los equipos de IT y desarrollo preguntan
- → "¿Qué versión de FHIR usan?" — R4; tipos de recursos Patient, Encounter, Observation, Condition
- → "¿Cómo manejan la expiración de tokens?" — renovación automática; sin rotación manual; evento registrado en fallo
- → "¿Se pueden enrutar distintos pagadores por diferentes cámaras?" — sí; tabla de enrutamiento por pagador en admin
- → "¿Cuál es el esquema de firma de webhooks?" — HMAC-SHA256 sobre el cuerpo completo del payload; timestamp en encabezado
- → "¿Es compatible con PKCE para flujos OAuth?" — sí; todos los flujos OAuth 2.0 usan PKCE; sin implicit grant
- → "¿Pueden recibir estados de reclamo en tiempo real?" — sí; claim.submitted, claim.adjudicated, payment.posted
OAuth 2.0 con PKCE. FHIR R4 Patient, Encounter, Observation. Write-back bidireccional.
La sincronización EMR en Mira™ usa OAuth 2.0 con PKCE — sin secretos de cliente almacenados en archivos de configuración, sin credenciales de larga duración que requieran rotación programada. El flujo de autorización inicial se ejecuta una sola vez; Mira™ almacena el token de actualización en el gestor de secretos y rota el token de acceso automáticamente antes de cada llamada a la API. El tiempo de vida del token de acceso lo establece el proveedor EMR (típicamente 15–60 minutos); Mira™ lo renueva sin exponer la expiración al usuario ni al personal de facturación.
La sincronización entrante lee recursos FHIR R4: Patient (demografía, identificadores, cobertura del pagador), Encounter (tipo de visita, fechas de servicio, proveedor asistente), Observation (signos vitales, puntuaciones de estado funcional) y Condition (códigos de diagnóstico). La sincronización es incremental — Mira™ solicita recursos modificados desde la última marca de tiempo de sincronización exitosa, no una exportación completa en cada ejecución. Los fallos de sincronización se registran con el tipo de recurso, la URL de la operación FHIR y el código HTTP devuelto por el EMR.
El write-back bidireccional publica actualizaciones del estado de reclamos de vuelta al EMR como recursos FHIR ClaimResponse. Cuando un reclamo es adjudicado y un pago se registra en Mira™, el write-back se activa automáticamente — sin paso manual, sin ciclo de exportación-importación. Epic y Cerner exponen puntos de write-back bajo sus marcos SMART on FHIR; Mira™ usa la misma sesión OAuth para lecturas y escrituras.
- – OAuth 2.0 + PKCE; tokens de acceso renovados automáticamente; tokens de actualización en gestor de secretos
- – Recursos FHIR R4: Patient, Encounter, Observation, Condition; sincronización incremental desde última fecha modificada
- – Fallos de sincronización registrados con tipo de recurso, URL de operación FHIR, código HTTP; visibles en registro de eventos admin
- – Write-back bidireccional: ClaimResponse publicado en EMR al adjudicar; misma sesión OAuth que las lecturas
Capturas del producto Mira con anotaciones numeradas. 1 2 - 1 Conexión OAuth con Epic / Cerner. Los tokens se renuevan automáticamente.
- 2 Escritura bidireccional: estado de reclamaciones, vitales, notas.
Capturas del producto Mira con anotaciones numeradas. 1 - 1 Availity + Change Healthcare configurados por pagador.
Enrutamiento por pagador. Procesamiento EDI 277/835. Verificación de elegibilidad en tiempo real.
El enrutamiento de cámaras en Mira™ se configura a nivel de pagador, no a nivel de organización. Un reclamo de Medicare Parte A se enruta a través de Availity. Un pagador comercial específico se enruta a través de Change Healthcare. Un programa Medicaid estatal se enruta por un tercer gateway EDI. La tabla de enrutamiento se gestiona en el panel admin; el personal de facturación solo ve el estado de envío — la selección de cámara les es invisible y es consistente en cada envío.
El envío de reclamos genera transacciones ASC X12N 837P o 837I según el tipo de reclamo. El sondeo de estado usa el par de transacciones 276/277 — Mira™ envía una Solicitud de Estado de Reclamación 276 y procesa la Respuesta 277 para actualizar el expediente del reclamo. El procesamiento del ERA maneja el 835 Health Care Claim Payment/Advice para registrar ajustes por línea, concesiones contractuales y montos de responsabilidad del paciente. El procesamiento 835 se ejecuta contra el 837 original del reclamo para relacionar los códigos de motivo de ajuste con las líneas correspondientes.
La verificación de elegibilidad en tiempo real se ejecuta a través de Availity y Change Healthcare según el pagador. El par de transacciones 270/271 devuelve detalles de beneficios incluyendo deducible, copago, coseguro y máximo de bolsillo. El resultado de elegibilidad se adjunta al expediente del paciente y se muestra en el constructor de reclamos — el personal de facturación ve el resultado de verificación sin salir del reclamo.
- – Tabla de enrutamiento por pagador en admin; el personal de facturación solo ve el estado — el enrutamiento es transparente
- – Envío 837P / 837I; sondeo de estado 276/277; registro ERA 835 con conciliación por línea
- – Elegibilidad 270/271 en tiempo real: deducible, copago, coseguro, máximo de bolsillo
- – Availity + Change Healthcare activos; el pagador determina cuál se usa en el momento del envío
SAML 2.0, OIDC y MSAL B2C. Azure AD, Okta y Google Workspace probados.
La autenticación del personal en Mira™ usa la Biblioteca de Autenticación de Microsoft (MSAL) con Azure B2C como intermediario de identidad. B2C admite federación con cualquier proveedor de identidad compatible con SAML 2.0 u OIDC — incluyendo Azure AD (Entra ID), Okta, Google Workspace y cualquier despliegue ADFS local. Las organizaciones que ya tienen un IdP empresarial no necesitan provisionar credenciales Mira™ separadas para su personal; la autenticación fluye por el IdP existente y el token de sesión lo emite B2C.
La federación SAML 2.0 usa una URL de metadatos del proveedor de servicios publicada por el tenant B2C de Mira™; el administrador del IdP agrega Mira™ como parte de confianza usando estos metadatos. El mapeo de atributos relaciona el identificador de usuario del IdP, correo electrónico, nombre para mostrar y membresías de grupo con el perfil de usuario de Mira™. El mapeo de grupos a roles se configura en el panel admin de Mira™ — un grupo de seguridad de Azure AD se mapea a un rol clínico de Mira™; un grupo de Okta se mapea a un rol de facturación. El mapeo se evalúa en cada inicio de sesión; los cambios de rol en el IdP toman efecto en el próximo inicio de sesión del usuario.
La federación OIDC sigue el flujo de código de autorización con PKCE. El token de ID lleva los claims estándar (sub, email, name) más cualquier claim personalizado configurado en el registro de aplicación del IdP. La aplicación de las políticas MFA se maneja a nivel del IdP — Mira™ no evita los requisitos de MFA establecidos por la política del IdP de la organización.
- – MSAL B2C como intermediario; federa con cualquier IdP SAML 2.0 u OIDC; sin credenciales Mira separadas
- – SAML 2.0: URL de metadatos SP publicada; mapeo de atributos para identificador, correo, nombre, grupos
- – Mapeo grupo-rol en panel admin; evaluado en cada inicio de sesión; cambios en IdP toman efecto al siguiente inicio
- – OIDC: código de autorización + PKCE; MFA aplicado por el IdP; Mira no evita la política MFA del IdP
Capturas del producto Mira con anotaciones numeradas. 1 - 1 SAML 2.0, OIDC, MSAL B2C. Azure AD, Okta, Google Workspace.
Capturas del producto Mira con anotaciones numeradas. 1 2 - 1 Firme cargas con HMAC-SHA256. Protección contra replay vía timestamp.
- 2 ¿Entrega fallida? Reintentos por 24h con backoff exponencial.
Payloads firmados con HMAC-SHA256. Reintento de 24h con backoff exponencial. REST API completa documentada en /developers.
Los webhooks de Mira™ llevan un encabezado X-Mira-Signature con un resumen HMAC-SHA256 del cuerpo de la solicitud, firmado con un secreto compartido generado al registrar el webhook. El resumen se calcula sobre el cuerpo en bytes crudos antes del análisis JSON — por lo que la verificación de la firma no depende del orden de claves ni de la normalización de espacios en el consumidor. Un encabezado X-Mira-Timestamp lleva la marca de tiempo Unix del intento de entrega; los consumidores deben rechazar entregas donde la marca de tiempo tenga más de 300 segundos para prevenir ataques de replay.
Las entregas fallidas — cualquier respuesta HTTP fuera del rango 2xx, o un tiempo de espera de conexión — se reintentan con backoff exponencial: 30 segundos, 2 minutos, 8 minutos, 30 minutos, 2 horas, 8 horas, y luego cada hora hasta 24 horas después del intento de entrega inicial. Después de 24 horas sin entrega exitosa, el evento se marca como fallido permanentemente y aparece en la cola de mensajes sin entregar en el panel admin. Los eventos en la cola de mensajes sin entregar pueden reproducirse manualmente una vez resuelto el problema del endpoint.
La REST API sigue las convenciones JSON:API. Todos los recursos están versionados bajo /api/v2/. La autenticación usa tokens bearer obtenidos via el flujo OIDC de MSAL B2C — el mismo token que autentica la aplicación web autentica las llamadas a la API. Los límites de tasa son 1.000 solicitudes por minuto por organización por defecto; el límite aparece en los encabezados de respuesta X-RateLimit-*. La especificación OpenAPI 3.1 está publicada en el portal de desarrolladores.
- – Firma HMAC-SHA256 sobre cuerpo crudo de solicitud; encabezados X-Mira-Signature + X-Mira-Timestamp en cada entrega
- – Protección contra replay: rechazar entregas donde X-Mira-Timestamp tenga >300 segundos
- – Programa de reintentos: 30s → 2m → 8m → 30m → 2h → 8h → cada hora hasta 24h; cola de mensajes sin entregar en admin
- – REST API: JSON:API, /api/v2/, autenticación bearer; 1.000 solicitudes/min por defecto; OpenAPI 3.1 en /developers
QuickBooks Online para asientos de ingresos. Twilio para SMS y voz salientes. Ambos por evento webhook.
El registro de pagos en Mira™ dispara un evento webhook payment.posted. La integración con QuickBooks consume este evento y crea un recibo de venta o pago de factura en QuickBooks Online usando la API de Contabilidad de QuickBooks v3. El mapeo entre el expediente de pago de Mira™ y las cuentas de ingresos de QuickBooks se configura en el panel admin — cada pagador se mapea a una cuenta de ingresos de QuickBooks para que los ingresos se categoricen correctamente sin asientos manuales.
La autenticación con QuickBooks Online usa OAuth 2.0 con el servidor de autorización de QuickBooks. El tiempo de vida del token de actualización es de 100 días; Mira renueva los tokens de acceso automáticamente y alerta al panel admin cuando un token de actualización está a 14 días de expirar — dando tiempo a los administradores para volver a autorizar antes de que la conexión caduque. El ID de empresa de QuickBooks se almacena por organización Mira™; las configuraciones de contabilidad multi-entidad (múltiples empresas QuickBooks) son compatibles con una conexión QuickBooks por organización Mira™.
La integración con Twilio gestiona SMS y voz salientes para flujos de comunicación del equipo de cuidado: recordatorios de citas, avisos de medicamentos y mensajes de notificación familiar. Los SIDs del Servicio de Mensajería de Twilio se configuran por organización; la provisión de números de teléfono y los grupos de números se gestionan en la consola de Twilio. Los webhooks de estado de entrega de mensajes de Twilio son consumidos por Mira™ y registrados en el expediente de comunicación del paciente — los estados de entregado, no entregado y fallido son visibles para los coordinadores de cuidados.
- – API QuickBooks Online v3; evento payment.posted activa creación de recibo; mapeo pagador-cuenta en admin
- – OAuth 2.0 QuickBooks; tokens de actualización de 100 días; alerta admin a 14 días antes de expiración; multi-entidad compatible
- – SIDs de Servicio de Mensajería Twilio por organización; SMS + voz salientes para citas, medicamentos, notificaciones familiares
- – Webhooks de estado de entrega Twilio registrados en expediente de comunicación del paciente; entregado/no entregado/fallido visibles
Capturas del producto Mira con anotaciones numeradas. 1 - 1 QuickBooks para asientos de ingresos; Twilio para SMS + voz salientes.
Recorra el flujo de integraciones en 60 segundos.
Resumen → configuración OAuth de Epic → llega el registro → se arma el reclamo → webhook se dispara → estado regresa al EMR. Seis pasos.
Resumen de integraciones
Conecte Epic, Cerner, Availity, Change Healthcare, Azure AD, Okta, Twilio, QuickBooks.
Cómo encajan las integraciones en el panorama general.
Mira™ IA
Las funciones de IA que analizan reclamos, redactan resúmenes IDG y predicen denegaciones operan sobre datos que llegan a través de la sincronización EMR. Cuanto más rico sea el conjunto de recursos FHIR entrantes, más contexto tiene la IA. Las integraciones son la cadena de suministro de Mira™ IA.
Explorar IA →Mira™ Cumplimiento
Los eventos de integración — fallos en la renovación de tokens, fallos en la entrega de webhooks, rechazos de aserciones SAML — se registran en el mismo registro de auditoría inmutable que los eventos de acceso PHI. Los oficiales de cumplimiento pueden consultar eventos de integración junto a eventos de acceso clínico sin una herramienta de monitoreo separada.
Explorar Cumplimiento →Portal de desarrolladores
La REST API y el catálogo de eventos webhook están documentados en detalle en el portal de desarrolladores. Especificación OpenAPI 3.1, esquemas de eventos webhook, flujos de autenticación, encabezados de límite de tasa y credenciales de sandbox — todo disponible sin conversación de ventas.
Ir a la documentación →¿Listo para revisar la arquitectura de integraciones de Mira™ con su equipo de IT?
Apoyamos revisiones técnicas: alcances OAuth, mapeo de recursos FHIR, metadatos de federación SAML, verificación de firmas de webhooks. Traiga a su ingeniero de integración. 45 minutos, sin diapositivas, sin guion.