El problema real.
Conocer nombres de estándares no demuestra que un mensaje sobreviva un flujo distribuido. La interoperabilidad requiere acordar la semántica, confirmar durabilidad, manejar reintentos y observar el recorrido de los datos.
La decisión de arquitectura.
Resolver un mismo recorrido con servicios idiomáticos: ingestión HL7 v2 en Java, mapeo FHIR en Kotlin, gateway gRPC en Go, reclamaciones EDI en C# y consola Angular. El contrato entre servicios es tan importante como cada implementación.
- 01HL7 v2 / Java
- 02Kafka → FHIR / Kotlin
- 03gRPC / Go
- 04EDI X12 / C#
Los controles que lo sostienen.
- Confirmación del mensaje después de la publicación durable del evento.
- Fechas parciales conservadas como tales, sin inventar datos clínicos.
- Deduplicación de reclamaciones y límites explícitos de recursos.
- Observabilidad con OpenTelemetry y controles de privacidad en los atributos de las trazas.
Evidencia con contexto.
El repositorio sirve como evidencia técnica del enfoque: contratos, implementación, infraestructura y controles ejecutables. El CV describe 34,226 líneas de código y seis flujos de integración continua; aquí no se presentan como estado de CI en tiempo real.
Fuente de cifras y alcance: CV 2026 proporcionado por el autor. No es telemetría en tiempo real.
Los límites también importan.
Los datos de ejemplo son sintéticos. Los controles expresados como código no sustituyen un informe SOC 2, una certificación ni la validación de un despliegue hospitalario. Un laboratorio público no equivale a una instalación clínica en producción.