Exportar un diario miccional a Epic, Cerner y otros sistemas EMR

Bladder Diaries exporta el diario del paciente como dos archivos estándar: un FHIR R4 Bundle (.fhir.json) para los EMR modernos que ingieren FHIR, y un HL7 C-CDA R2.1 CCD (.ccd.xml) para sistemas heredados y mensajería Direct Secure Messaging. Ambos archivos se construyen en el navegador, se descargan localmente y luego se adjuntan a la historia clínica a través de la entrada estándar del EMR receptor. Ningún dato del paciente transita por los servidores de bladderdiaries.com; la herramienta de chart-matching del receptor sustituye el placeholder de Patient sintético en la ingesta.

Acaba de completar un diario de 3 días con un paciente. La calculadora devolvió un MVV (volumen miccional máximo) de 320 mL, un AVV (volumen miccional medio) de 145 mL, un NPi (índice de poliuria nocturna) del 32%, un 24hVV (volumen miccional de 24 horas) de 2.1 L y un FVC (frequency-volume chart) de frecuencia de 9 micciones cada 24 horas. La pregunta restante es mecánica: ¿cómo llegan estos números a la historia clínica en una forma que su codificador, su enfermería y la próxima visita puedan leer? Este recorrido cubre los dos formatos de archivo, dónde aterriza cada uno en Epic, Cerner / Oracle Health, Athena Health, Prompt Health (vía Kno2) y el EMR heredado, y cómo se ve el contrato de chart-matching del lado del receptor.

Los dos formatos de archivo: FHIR R4 Bundle frente a HL7 C-CDA R2.1 CCD

Los dos estándares del catálogo de importación a la historia clínica son FHIR (Fast Healthcare Interoperability Resources) y C-CDA (Consolidated Clinical Document Architecture). Ambos son estándares HL7; ambos transportan los mismos datos del diario en formas de cable distintas. Bladder Diaries emite los dos porque el ecosistema EMR es bilingüe: las instalaciones modernas ingieren FHIR de forma nativa, las instalaciones ambulatorias heredadas ingieren C-CDA, y los mandatos federales estadounidenses (21st Century Cures Act, ONC Cures Act Final Rule) exigen desde 2023 que las tecnologías EHR certificadas soporten FHIR R4, con C-CDA R2.1 como rampa de entrada para lo heredado.

FHIR R4 Bundle: la vía moderna

FHIR R4 (publicado en octubre de 2019) es el estándar JSON orientado a recursos que ingiere la cohorte EMR moderna. La exportación se entrega como un Bundle de type: "collection" que contiene:

• 1 recurso Patient placeholder que porta el centinela REPLACE_WITH_MRN en Patient.identifier. El receptor completa el MRN real en la ingesta.
• N recursos Observation a nivel de evento: uno por micción, uno por ingesta hídrica, uno por puntuación de urgencia (cuando esté presente), uno por episodio de fuga. El receptor ve la cronología en bruto.
• 5 recursos Observation de métricas calculadas para MVV, AVV, NPi, 24hVV y FVC, cada uno con codificación híbrida LOINC más codificación del CodeSystem personalizado de Bladder Diaries (según Phase 8 D-12). El receptor obtiene una codificación estándar y una codificación precisa.
• 1 recurso DiagnosticReport que resume las métricas, con el PDF codificado en base64 dentro de presentedForm[0].data. Un artefacto legible para humanos acompaña siempre a los datos estructurados.

El Bundle valida contra el esquema HL7 R4 y contra el perfil US Core 6.1.0 Implementation Guide. Los receptores que perfilan contra US Core (Epic, Cerner / Oracle Health, Athena, Allscripts / Veradigm) encuentran los campos esperados: Patient.identifier, Observation.code, Observation.value[x], Observation.effectiveDateTime, DiagnosticReport. Los receptores que no perfilan contra US Core siguen obteniendo la forma R4 base, suficiente para la ingesta.

HL7 C-CDA R2.1 CCD: la rampa de entrada heredada

C-CDA R2.1 (publicado en julio de 2015) es el estándar documental basado en XML que ingieren la cohorte EMR ambulatoria heredada y el transporte Direct Secure Messaging. La exportación se entrega como un ClinicalDocument con:

• El US Realm Header (CONF:1198-*) que cubre el placeholder de Patient, la organización custodian, el autor del documento y la estructura CDA estándar.
• Un body que contiene las seis secciones obligatorias del CCD (Alergias, Medicación, Problemas, Procedimientos, Resultados, Historia social), con nullFlavor="NI" en las secciones que el diario no rellena.
• Un organizer Results que transporta las mismas cinco métricas calculadas, cada <observation> doblemente declarada con el templateId Result Observation V3 (2.16.840.1.113883.10.20.22.4.2, extensión 2015-08-01).
• Un elemento observationMedia que transporta el informe PDF codificado en base64 inline; no hace falta un adjunto separado.

El CDA valida contra el schematron HL7 SDWG C-CDA R2.1 (cerrado en la Phase 11 Plan 11-01). La vía C-CDA es la elección adecuada cuando el EMR receptor es anterior al ciclo de conformidad 21st Century Cures Act, cuando el flujo de trabajo está mediado por Direct Secure Messaging, o cuando el equipo IT del receptor ha desactivado la entrada FHIR.

¿Cuál elijo?

| EMR receptor | Formato | Superficie de entrada | | ------------------------ | ---------- | --------------------------------------------------------------------------- | | Epic | FHIR R4 | App SMART on FHIR, FHIR Inbox, adjunto a la historia en una consulta | | Cerner / Oracle Health | FHIR R4 | Entrada FHIR R4, Bridges, Code App Gallery | | Athena Health | FHIR R4 | Entrada More Disruption Please (MDP); repliega a CCD si MDP está desactivado | | Prompt Health | Cualquiera | Partenariado Kno2: el normalizador del lado del receptor admite ambos | | Allscripts / Veradigm | FHIR R4 | Ingesta dbMotion / TouchWorks | | NextGen | C-CDA | Entrada CCD; la hoja de ruta FHIR aún no se ha entregado en todas las ediciones | | eClinicalWorks | C-CDA | Entrada CCD | | Greenway / Intergy | C-CDA | Entrada CCD | | Cola larga heredada | C-CDA | Direct Secure Messaging (DSM), entrega HIE al buzón |

La regla de decisión: envíe FHIR R4 si sabe que el receptor admite FHIR; envíe C-CDA si lo desconoce, o si el receptor está explícitamente en la rampa de entrada heredada. Bladder Diaries emite ambos archivos desde la misma salida de la calculadora; usted puede mantener los dos a mano y usar el que el receptor acepte realmente.

Paso a paso: de /entry a la historia clínica

El flujo de trabajo de extremo a extremo tiene cuatro pasos. Los tres primeros viven en su navegador, en bladderdiaries.com. El cuarto vive en el EMR receptor.

Paso 1: Introducir el diario en /entry

Abra la Calculadora en bladderdiaries.com. Introduzca el diario del paciente como micciones, ingestas hídricas, marcadores de acostarse y, cuando se documenten, episodios de fuga y puntuaciones de urgencia. El formulario de pantalla única requiere unos 90 segundos para un diario típico de 3 días. La edad del paciente y la marca de enuresis pilotan el umbral del NPi por banda etaria y la clasificación de la continencia.

Paso 2: Leer las métricas en /results

La calculadora enruta a /results tras enviar. La página renderiza MVV, AVV, NPi, 24hVV, FVC y la clasificación IPC (Integrated Pelvic Care) 4Is (Fluid Imbalance, Storage Impairment, Voiding Impairment, Incontinence). El marco de cuatro compartimentos retroalimenta luego el lenguaje de la nota de encuentro; consulte el pilar de interpretación del diario miccional para la disciplina clínica que empareja los números con el diagnóstico diferencial.

Paso 3: Pulsar el botón de exportación

La barra de exportación en la parte superior de /results lleva tres botones: PDF, FHIR Bundle y C-CDA CCD. Pulse el formato que acepta el EMR receptor. El archivo se construye en el navegador (FHIR Bundle en JSON, CCD en XML) y aterriza en su carpeta local de descargas con un nombre de archivo determinista: bladder-diary-YYYY-MM-DD.fhir.json o bladder-diary-YYYY-MM-DD.ccd.xml. No se produce ningún upload HTTPS a bladderdiaries.com; el toast confirma "descargado. Nota: el archivo se guarda en su dispositivo, fuera de esta calculadora".

Paso 4: Adjuntar a la historia clínica en el EMR receptor

Epic vía SMART on FHIR: si su organización ha desarrollado una app SMART on FHIR orientada al paciente, el paciente carga el FHIR Bundle a través de MyChart. Si su equipo IT ha habilitado la FHIR Inbox, deposite ahí el archivo. Si no hay ninguna de estas vías disponibles, adjunte el FHIR Bundle como adjunto a la historia en una consulta de rutina; el archivo vive en la historia como un binario, y los datos estructurados pueden reanalizarse más adelante.

Cerner / Oracle Health: la entrada FHIR R4 acepta el archivo a través de la operación R4/$import cuando el equipo IT la ha habilitado. Muchas instituciones lo enrutan a través de Bridges (la capa de interoperabilidad de Oracle Health). Code App Gallery es una tercera vía: una superficie SMART on FHIR donde el archivo se carga como recurso adjunto al paciente.

Athena Health: la entrada More Disruption Please (MDP) es la vía FHIR R4. Deposite el FHIR Bundle por el endpoint MDP. Si su instancia Athena solo dispone de la entrada CCD heredada, envíe el C-CDA CCD en su lugar.

Prompt Health: el partenariado Kno2 admite ambos formatos de archivo. Kno2 actúa como un normalizador del lado del receptor que convierte FHIR o CCD al formato que el EMR aguas abajo espera. La misma vía funciona para cualquier EMR de la red Kno2.

EMR heredado vía Direct Secure Messaging (DSM): el C-CDA CCD viaja por DSM como adjunto XML. El Health Information Service Provider (HISP) del receptor lo entrega en el buzón del receptor. La vía DSM es la elección adecuada para consultas ambulatorias que todavía no han adoptado FHIR.

La opción de correo electrónico simple no se recomienda. Privilegie la entrada estándar del EMR receptor; la vía email es un flujo manual de último recurso.

El contrato de privacidad: cliente puro, sin tránsito de PHI

La propiedad más importante del pipeline de exportación es que nunca transmite datos del paciente. Ambos archivos se construyen íntegramente en su navegador a partir de los datos del diario que el clínico introdujo en /entry. El diario vive únicamente en el localStorage del navegador: ninguna base de datos en el servidor, ningún upload HTTPS a bladderdiaries.com, ninguna analítica de terceros sobre la carga útil del diario.

El EMR receptor es la autoridad de chart-matching. El placeholder de Patient lleva precisamente REPLACE_WITH_MRN en Patient.identifier para que el receptor pueda ejecutar su propio matching contra el espacio de nombres MRN local. La política IT del receptor determina si el matching es automático (R4/$import del lado del sistema con una regla de enlace a historia) o manual (el personal de recepción empareja el archivo entrante con la historia). Bladder Diaries no ve, almacena ni transmite ninguna información de matching.

La postura HIPAA / RGPD se desprende de este diseño. Bladder Diaries se mantiene fuera del perímetro HIPAA Covered Entity y fuera del perímetro RGPD data-controller porque jamás retiene datos del paciente en sus servidores. El navegador local del clínico retiene el diario; el sistema de archivos del clínico retiene la exportación; el EMR receptor retiene la historia. Cada eslabón es una superficie de cumplimiento conocida para el equipo IT local y para el Business Associate Agreement local (cuando proceda); el eslabón bladderdiaries.com está vacío por diseño.

Esto se documenta en la Política de privacidad. El invariante de cliente puro es el cerrojo arquitectónico que mantiene a Bladder Diaries fuera del perímetro regulatorio; el catálogo de formatos de archivo es la rampa operativa que, aun así, entrega los datos estructurados a la historia.

¿Qué es el OID CodeSystem 2.25.* en mi registro de auditoría?

Los receptores que auditen el documento entrante por CodeSystem verán un Object Identifier (OID) propio de Bladder Diaries en el registro de auditoría, con la forma 2.25.<uuid-decimal>. Es intencional y merece una breve explicación, porque los equipos IT clínicos a veces marcan los OID desconocidos como una incidencia de seguridad.

Un OID es un identificador jerárquico registrado contra un árbol global (el arco OID ISO/IEC 9834). Los estándares HL7 usan OID para identificar sistemas de codificación de forma inequívoca: LOINC es 2.16.840.1.113883.6.1, SNOMED CT es 2.16.840.1.113883.6.96. Cada OID corresponde a una autoridad registrada que mantiene los códigos.

Las cinco métricas calculadas de Bladder Diaries (MVV, AVV, NPi, 24hVV, FVC) todavía no están totalmente cubiertas por el LOINC canónico. LOINC dispone de códigos para los volúmenes subyacentes (por ejemplo 28604-5 Voided volume, 28649-0 Urine output 24 hour), pero no para las métricas calculadas específicas del diario miccional en la forma precisa que requiere el marco IPC. La codificación híbrida emite tanto un código LOINC (cuando existe) como un código personalizado de Bladder Diaries (siempre), de modo que el receptor obtiene una codificación estándar para anclar una búsqueda y una codificación precisa para anclar un cálculo.

El CodeSystem personalizado necesita un OID. En lugar de solicitar un arco registrado a través de HL7 (un proceso de varios meses), Bladder Diaries usa el arco 2.25.* según RFC 4122 §4.5, que permite a cualquier parte derivar un OID globalmente único a partir de un UUID tratando el UUID como un entero decimal. El OID resultante es único sin registro, trazable y conforme con el estándar HL7 para identificadores de CodeSystem. El equipo IT clínico puede documentar el OID como emitido por Bladder Diaries (una aprobación única en la lista de permitidos de OID), y el registro de auditoría sigue fluyendo con normalidad.

Qué preguntar a su departamento de IT antes de la primera exportación

Cinco preguntas alinean las expectativas antes de la primera exportación de paciente. Las respuestas determinan qué formato de archivo y qué superficie de entrada usar:

1. ¿Soportamos la ingesta de FHIR R4? La mayoría de instalaciones EMR en 2026 soportan FHIR R4 en algún grado; la variabilidad está en la superficie de entrada (app SMART on FHIR, FHIR Inbox, R4/$import, vía específica del proveedor).
2. ¿Soportamos la ingesta de C-CDA R2.1? Los receptores C-CDA R2.0 normalmente parsean documentos R2.1 (el esquema es retrocompatible), pero las advertencias de schematron pueden diferir.
3. ¿Cuál es nuestra superficie de app SMART on FHIR? Epic y Cerner / Oracle Health: esto responde si el FHIR Bundle se carga por una app orientada al paciente (MyChart) o solo por la FHIR Inbox de back-office.
4. ¿Es localizable nuestra dirección de Direct Secure Messaging? EMR ambulatorios heredados: la dirección DSM es el destino del C-CDA CCD. Su HISP puede confirmar que la dirección está publicada en el registro DirectTrust.
5. ¿Tenemos un partenariado con Kno2? Prompt Health y otros EMR conectados a Kno2: la entrada Kno2 es un único endpoint que enruta a múltiples EMR aguas abajo.

Bonus: ¿cuáles son las reglas de chart-matching para un archivo entrante con MRN placeholder? Algunos receptores hacen matching automático por demografía (nombre más fecha de nacimiento más sexo más dirección); otros exigen un Patient.identifier totalmente poblado. Conocer la política del receptor le indica si el archivo enruta automáticamente o si el personal del receptor lo emparejará manualmente.

Preguntas frecuentes

¿Qué formato de archivo debo enviar a Epic? FHIR R4 Bundle (.fhir.json). Epic ingiere FHIR R4 a través de su superficie de app SMART on FHIR, de la FHIR Inbox si su equipo IT la ha habilitado, o como adjunto a la historia en una consulta de rutina. Valida contra US Core 6.1.0.

¿Qué formato de archivo debo enviar a Cerner u Oracle Health? FHIR R4 Bundle (.fhir.json). Cerner / Oracle Health ingiere FHIR R4 por el mismo estándar. Algunas instituciones enrutan a través de Bridges o Code App Gallery; la entrada FHIR de back-office es la vía estándar.

¿Qué formato de archivo debo enviar a Athena Health? FHIR R4 Bundle (.fhir.json) por la entrada More Disruption Please (MDP). Si su instancia Athena solo dispone de la entrada CCD heredada, envíe el C-CDA CCD (.ccd.xml) en su lugar.

¿Qué formato de archivo debo enviar a Prompt Health? Cualquiera de los dos. Prompt Health admite ambos formatos a través de su partenariado Kno2; el normalizador del lado del receptor de Kno2 convierte al formato que espera el EMR aguas abajo.

¿Sube Bladder Diaries mis datos de paciente a algún lugar? No. Ambos formatos de archivo se generan íntegramente en su navegador. El archivo aterriza en su carpeta de descargas local; ningún upload HTTPS a bladderdiaries.com ni a ningún tercero. La Política de privacidad lo describe en detalle.

¿Qué es el placeholder REPLACE_WITH_MRN? Un valor centinela deliberado en el recurso Patient sintético. La herramienta de chart-matching de su EMR lo sustituye por el número de historia clínica real en la ingesta. Este patrón permite que el archivo se envíe sin datos de identificación del paciente y deja que el receptor aplique su propia política de chart-matching.

¿Por qué mi registro de auditoría EMR muestra un OID CodeSystem 2.25. que no reconozco?* Es el CodeSystem personalizado de Bladder Diaries, autoasignado bajo el arco OID RFC 4122 §4.5. Se usa para las cinco métricas calculadas (MVV, AVV, NPi, 24hVV, FVC) que el LOINC canónico todavía no cubre. Cada métrica también lleva un código LOINC híbrido cuando existe.

¿Puedo enviar el mismo archivo a varios EMR? Sí. Ambos formatos de archivo son agnósticos al receptor. El mismo FHIR Bundle o C-CDA CCD puede enrutarse a varios EMR en paralelo (por ejemplo atención primaria más derivación a especialidad). El chart-matching en cada destino es independiente.

Cierre: pruébelo con el próximo diario

El próximo diario de 3 días que complete con un paciente en Bladder Diaries es el caso de prueba. Abra la Calculadora, introduzca el diario, lea las métricas en /results y pulse el botón de exportación que corresponda al EMR receptor. El archivo aterriza en su carpeta de descargas; adjúntelo a través de la entrada estándar del EMR receptor. El clínico dispone entonces, en la historia clínica, de los mismos números estructurados que la calculadora devolvió en pantalla; los servidores de bladderdiaries.com permanecen vacíos; y el archivo basado en estándares aterriza donde corresponde: en la historia, junto al resto del registro del paciente.

Autor: Dr. Di Wu, MD, PT (miembro fundador de IPC). El hito v5.0 de Bladder Diaries entrega interoperabilidad EMR basada en estándares. Estándares referenciados: HL7 FHIR R4, HL7 C-CDA R2.1, US Core 6.1.0 Implementation Guide, LOINC y RFC 4122 §4.5 (arco OID derivado de UUID). Foto: Vitaly Gariev en Unsplash.