Antes de comprar un componente hay que saber dónde vive, quién responde por él y qué cruza cada frontera. Definimos arquitecturas de salud digital que se pueden operar, auditar y conectar a una red nacional sin rehacerlas.
Casi ninguna institución arranca de cero. Tiene un expediente, un laboratorio, un PACS, un portal y una lista de proyectos pendientes. El problema aparece cuando hay que incorporar piezas nuevas —un índice maestro de pacientes, un catálogo de productos, la validación de profesionales y establecimientos— y nadie puede decir con precisión dónde deben vivir, quién las mantiene, qué exponen hacia afuera ni cómo se conectan a la plataforma nacional de intercambio. Nuestro trabajo es cerrar esas decisiones y dejarlas escritas, con el detalle suficiente para contratar, construir y auditar.
Cuatro planos, y ninguno se resuelve en el siguiente. Cuando una organización salta directo al plano tecnológico, termina con componentes correctos que nadie sabe operar y por los que nadie responde.
¿Quién decide, quién aprueba y cómo se cambia lo decidido?
Qué se decide aquí¿Qué significa cada dato y cuál es su fuente de verdad?
Qué se decide aquí¿Qué componentes existen y qué contrato cumple cada uno?
Qué se decide aquí¿Dónde corre, cómo se protege y cómo se sostiene?
Qué se decide aquíNo es una lista de compras. Cada componente resuelve un problema concreto y arrastra una decisión que suele quedarse sin dueño hasta que un proyecto la cierra por su cuenta.
Resuelve si dos registros de dos sistemas distintos son la misma persona, y mantiene el vínculo entre sus identificadores.
Si la coincidencia es determinística sobre el identificador nacional, probabilística, o ambas con una cola de revisión humana; y qué sistema queda como dueño del identificador maestro.
Da un identificador estable a cada medicamento, insumo o dispositivo, para que la prescripción, el despacho y el inventario hablen del mismo producto.
Si se adopta el catálogo nacional, uno internacional o el propio, y cómo se mapea lo ya cargado en los sistemas sin perder el histórico.
Confirma que quien firma un acto clínico está habilitado para hacerlo, en el momento en que lo hace.
Si la validación se consulta en línea contra la fuente autoritativa —el colegio profesional o el registro nacional— o se replica localmente, y qué ocurre cuando la fuente no responde.
Identifica de forma única cada sede, servicio y unidad, que es lo que permite enrutar, reportar y auditar por lugar.
Qué codificación se usa —la habilitación sanitaria nacional u otra— y quién actualiza el registro cuando una sede abre, cambia de servicio o cierra.
Publica y valida los CodeSystem, ValueSet y ConceptMap que usan los sistemas, en vez de dejar cada tabla de códigos incrustada en cada aplicación.
Si se opera un servidor terminológico propio o se consume el nacional, y cómo se versiona un ValueSet sin invalidar los datos ya capturados.
Conserva lo que hay que conservar —recursos FHIR, documentos, imágenes— con una política de retención y un modo probado de recuperarlo. Es la fuente de verdad, y por eso no se expone nunca de forma directa.
Qué contenido es fuente de verdad aquí y qué es copia de otro sistema, porque de eso depende quién puede escribir en él y qué se pierde si se cae.
Registra quién accedió a qué, cuándo y con qué justificación. El punto de exposición emite el evento, pero el registro se guarda aquí y en modo solo-anexar: quien llegue a la frontera no debe poder reescribir la evidencia de su propio acceso.
Si la auditoría vive en cada sistema o se centraliza, y cuánto tiempo se conserva un registro que puede llegar a ser evidencia.
Determina quién pide, en nombre de quién pide y a qué tiene derecho a acceder — tanto para personas como para sistemas.
Qué se resuelve con identidad de sistema y qué exige identidad de la persona usuaria, y dónde queda registrado el consentimiento cuando el dato sale de la institución.
La copia conforme al perfil que responde las consultas externas: solo lo ya publicado, materializado a partir de la fuente de verdad y reconstruible en cualquier momento.
Qué se materializa, con qué frescura, y cómo se reconstruye desde la fuente cuando cambia el perfil. Si esta copia se vuelve la única, dejó de ser una copia.
Es la única puerta por la que la institución publica y consume información hacia afuera: gateway de API, capa FHIR, nodo de la red nacional.
Qué se expone, con qué perfil y a quién; y si esa puerta almacena datos o solamente los deja pasar.
La pregunta que más se pospone es dónde vive cada componente. Y no es una pregunta de infraestructura: define qué se puede exponer, qué hay que replicar y qué controles son obligatorios en cada punto.
El espacio donde su institución es un miembro más entre otros: prestadores, registros del Estado y la plataforma nacional de intercambio. Usted no lo administra, pero sí decide cómo se presenta ante él.
Nada se publica aquí sin un contrato explícito: perfil, terminología, identidad del solicitante y registro de la transacción.
La única zona alcanzable desde afuera. Aquí viven los componentes que hablan con el exterior, y solo esos. Todo lo que pasa por aquí se autentica, se autoriza y se registra.
Nada de lo que vive aquí es fuente de verdad. La DMZ traduce, enruta y publica copias reconstruibles de lo ya autorizado, sin acceso directo a las bases internas.
El expediente, los repositorios, el índice maestro, la terminología y la auditoría. Nada de esto se expone directamente; se alcanza únicamente a través de la DMZ.
Ningún sistema externo llega hasta aquí, y ningún componente interno sale a Internet por su cuenta.
Una frontera no se define por dónde está el cortafuegos, sino por lo que se permite atravesarla y bajo qué prueba.
Consultas y respuestas de los componentes internos que atienden una solicitud externa, ya reducidas a lo que esa solicitud necesita.
Conexiones iniciadas desde adentro, cuentas de servicio con permiso mínimo, credenciales distintas por ambiente y resultado registrado.
Recursos que cumplen un perfil publicado, con su terminología ligada, y solo hacia solicitantes identificados y autorizados.
Autenticación mutua entre sistemas, autorización por caso de uso y no por sistema completo, firma y sellado cuando el dato tiene valor probatorio, y bitácora de cada mensaje.
En Costa Rica, la plataforma nacional de intercambio es X-Road. Encajarla en la arquitectura cambia menos de lo que se teme y más de lo que se planifica.
La institución instala su propio security server. Es el único componente que habla con la red nacional; el resto de sus sistemas nunca lo hace directamente.
Cada organización y cada subsistema se registra y recibe certificados. La red sabe quién pregunta antes de que la pregunta llegue a usted.
La plataforma firma y sella lo que la atraviesa. Eso resuelve el no repudio, pero también obliga a decidir qué se envía: lo que cruza queda registrado.
No hay una base nacional que lo guarde todo. Cada institución sigue siendo dueña de su información y responde consultas puntuales.
Meddyg realiza pruebas de concepto junto a la Agencia Nacional de Gobierno Digital para validar transacciones de recursos FHIR sobre X-Road, dentro de la demostración funcional de interoperabilidad de Costa Rica. En otros países cambia el nombre de la plataforma; las decisiones de arquitectura que hay que cerrar —dónde va el nodo, qué se expone, quién autoriza y qué se registra— son las mismas.
Trabajamos sobre marcos que ya están probados en otros países y ecosistemas. Para su institución eso son tres cosas concretas: menos meses discutiendo lo que ya está resuelto, una arquitectura que el resto del ecosistema reconoce, y requisitos que puede poner en un cartel y exigir.
Construir por dentro lo que el país ya va a ofrecer, y terminar pagándolo dos veces.
Le decimos qué conviene reutilizar y qué construir, y le dejamos escritos los requisitos de estándares abiertos y portabilidad que debe exigir en cada contratación. Es lo que evita descubrir tres años después que no puede cambiar de proveedor.
Medio año discutiendo cómo se llama cada componente y quién responde por él.
Su arquitectura queda nombrada con el mismo vocabulario que usan los demás actores del ecosistema. Cuando le toque integrarse, la conversación arranca en el punto correcto y no en el glosario.
Descubrir durante la implementación que el componente que ya compró no puede cumplir el perfil nacional.
Convertimos el perfil que exige la guía nacional en un requisito de arquitectura verificable, antes de la compra. Si un producto no lo cumple, usted se entera cuando todavía puede cambiar de producto.
Que cada equipo interprete la norma clínica a su manera y usted termine con cinco versiones del mismo proceso.
Bajamos la norma hasta el sistema por una ruta ya probada: del documento a los procesos y los datos, de ahí al perfil FHIR, y de ahí a algo que se puede probar antes de producción. Si su dominio ya tiene un DAK publicado, se ahorra la etapa más lenta del proyecto.
El riesgo no aparece cuando se adoptan estándares; aparece cuando se expone un sistema que fue diseñado para vivir dentro de una red cerrada. Estas son las barandas que definimos junto con la arquitectura, no después.
Se publica una API sobre el expediente completo porque era más rápido que definir el intercambio.
Se expone un caso de uso a la vez, con su perfil y su alcance. Lo que no está en un contrato publicado, no se puede pedir.
Cualquier sistema que ya está dentro puede consultar cualquier cosa, porque la red se considera segura.
Autenticación de sistema y de persona usuaria en cada llamada, permisos por caso de uso y credenciales distintas por ambiente.
Cuando hay que responder quién accedió a un expediente, la información está repartida en registros que ya rotaron.
El registro de acceso se diseña como componente, con retención definida y consulta propia, desde el primer intercambio.
Se devuelve el recurso entero porque el consumidor «después filtra», y esa copia queda fuera de control.
Minimización desde el diseño: cada intercambio define su conjunto mínimo y la respuesta se recorta en el punto de exposición.
Un documento clínico intercambiado no puede demostrar quién lo emitió ni que no fue alterado.
Firma y sellado en los intercambios que lo requieren. Meddyg brindó asistencia técnica al Banco Central de Costa Rica para habilitar el firmado JAdES de recursos FHIR.
Se prueba contra producción porque el ambiente de pruebas no tiene datos parecidos a los reales.
Ambientes separados con datos sintéticos o anonimizados, promoción controlada y secretos distintos en cada uno.
Cada fase cierra una pregunta y deja un artefacto. Una arquitectura sin artefactos no se puede contratar, construir ni auditar.
¿Qué hay hoy, quién lo opera y qué se intercambia realmente?
Inventariamos sistemas, integraciones vivas, flujos clínicos y contratos vigentes. No lo que dice el diagrama: lo que está corriendo.
¿Qué tiene que poder hacer la organización que hoy no puede?
Priorizamos los intercambios por valor clínico y factibilidad, y los escribimos como requisitos funcionales y no funcionales. Cuando existe un DAK de la OMS para el dominio, lo tomamos como punto de partida.
¿Qué componentes existen en el estado deseado y qué contrato cumple cada uno?
Definimos el catálogo de componentes, sus responsabilidades y sus límites, con los perfiles y las terminologías que cada uno debe cumplir.
¿Dónde vive cada componente y qué cruza cada frontera?
Colocamos cada componente en su zona, definimos los controles de cada frontera y el punto único de exposición hacia la red nacional.
¿Quién responde por cada componente y cómo se cambia lo decidido?
Asignamos dueños, definimos el registro de decisiones de arquitectura y la ruta para aprobar una excepción sin que la excepción se vuelva la norma.
¿En qué orden se construye y qué puede entrar en producción primero?
Ordenamos el trabajo en incrementos que se pueden liberar y medir, empezando por el que resuelve un intercambio real y no por el que es más grande.
¿Se está construyendo lo que se definió?
Revisamos los entregables del proveedor contra los contratos definidos y ajustamos la arquitectura cuando la realidad obliga, con la decisión registrada.
Documentos que sirven para contratar, construir y auditar — no para presentar una vez y archivar.
El estado actual, la arquitectura objetivo, los componentes y sus contratos, con el nivel de detalle que exige un cartel de licitación.
Qué vive en cada zona, qué cruza cada frontera y bajo qué control, y cómo se conecta la organización a la plataforma nacional.
Cada componente con su responsabilidad, su dueño, su contrato y la decisión de comprar, construir o reutilizar.
Cada decisión con su contexto, las alternativas evaluadas y la consecuencia asumida. Es lo que evita rediscutir lo mismo cada año.
Controles por frontera, matriz de acceso, requisitos de auditoría y de firma, redactados para poder exigirlos contractualmente.
Incrementos liberables, dependencias, riesgos y el orden en que conviene construir para que algo entre en producción pronto.
La arquitectura no es el diagrama que se entrega: es lo que sigue funcionando tres años después. Estos son proyectos en los que Meddyg definió o construyó la arquitectura que quedó en operación.
Pruebas de concepto junto a la Agencia Nacional de Gobierno Digital para validar transacciones de recursos FHIR sobre la plataforma nacional, dentro de la demostración funcional de interoperabilidad de Costa Rica: intercambio seguro entre sistemas distintos, sin centralizar los datos.
Diseño, despliegue a producción y operación del primer servidor FHIR que recibe las notificaciones de enfermedades de notificación obligatoria, vacunas y resultados de laboratorio del EDUS/CCSS, y posteriormente de otros establecimientos de salud.
Asistencia técnica al Banco Central de Costa Rica para integrar el formato JAdES dentro de GAUDI, su plataforma de firma digital y sellado, y habilitar así el firmado de recursos FHIR.
Implementación de arquitecturas de PACS y estaciones de trabajo de diagnóstico para el intercambio de imágenes médicas bajo el estándar DICOM, en hospitales públicos del Servicio Nacional de Salud de República Dominicana.
Los marcos que nombramos en esta página son el método con el que trabajamos, no clientes. Cuando un caso corresponde a un cliente, lo decimos con su nombre — como los cuatro de arriba.
El servicio sirve tanto a quien tiene que definir la arquitectura por primera vez como a quien ya la tiene escrita y necesita conectarla al ecosistema.
Cajas, ministerios y hospitales que deben incorporar componentes nacionales y conectarse a la plataforma de intercambio del país.
Hospitales, clínicas y laboratorios que necesitan participar del ecosistema sin rehacer sus sistemas ni abrir su red.
Equipos que ya tienen el mandato de definir la arquitectura y necesitan cerrar decisiones y dejarlas defendibles.
Responsables que deben habilitar el intercambio sin ampliar la superficie de exposición de la institución.
Fabricantes que deben cumplir un perfil nacional y demostrar cómo su producto encaja en la arquitectura del cliente.
Iniciativas que necesitan una arquitectura de referencia común para que cada institución no resuelva a su manera.
Si reconoce tres o más, el problema no es tecnológico: son decisiones abiertas que cada proyecto está cerrando por su cuenta, de forma distinta.
Definimos la arquitectura que su organización necesita para operar hoy y conectarse mañana, con las decisiones escritas, los componentes ubicados y las barandas de seguridad puestas desde el diseño.