DocumentaciónSoporteCosta Rica · Contacto
ESENPT
Hablemos
Infraestructura

Repositorios Cloud

Los proyectos clínicos rara vez se detienen por falta de ideas. Se detienen esperando dónde guardar los datos. Le entregamos el repositorio operando —FHIR, imágenes médicas o documental firmado— con la autenticación, la autorización, la auditoría y la conformidad ya resueltas.

Solicitar una propuesta→Ver qué incluye
El punto de partida

Montar el repositorio no es el proyecto. Es el peaje para poder empezarlo.

Ninguna organización de salud quiere estar en el negocio de operar servidores. Quiere publicar resultados de laboratorio, compartir un estudio con otro centro, conservar un consentimiento que sirva como prueba. Pero antes de eso hay que resolver un servidor FHIR, un servidor de autorización, la validación contra el perfil nacional, el cifrado, la residencia de los datos, el respaldo, la auditoría y alguien que conteste a las tres de la mañana. Ese peaje se paga en meses y con un equipo que la mayoría de las instituciones no tiene ni quiere contratar. Nosotros ya lo pagamos: usted recibe el repositorio andando.

Qué desplegamos

Tres repositorios, una sola plataforma debajo

Usted elige qué necesita custodiar. Lo que sostiene el repositorio —identidad, autorización, auditoría, cifrado, respaldo y operación— no se cotiza aparte: es la misma base para los tres y viene incluida.

R4 / R5

Repositorio FHIR

Datos clínicos estructurados

Cuándo lo necesita

Cuando necesita almacenar y exponer información clínica —personas, resultados, vacunas, condiciones, medicación— de forma que otro sistema la entienda sin un integrador a la medida por cada conexión.

  • API FHIR RESTful

    Búsqueda, lectura, escritura, transacciones y operaciones estándar sobre R4 o R5, con paginación y control de concurrencia.

  • Perfilado y validación

    Cada recurso se valida contra la guía nacional o institucional en el momento de escribirlo, no en una auditoría posterior.

  • Terminología resuelta

    SNOMED CT, LOINC y los ValueSets nacionales disponibles para validar, expandir y traducir códigos sin montar un servidor aparte.

  • Extracción masiva

    Bulk Data y operaciones de exportación para analítica, reportes y tableros, sin golpear la API que atiende la operación clínica.

  • Versionado e historia

    Cada cambio conserva la versión anterior: se puede reconstruir qué decía el dato en una fecha determinada.

PACS / VNA

Repositorio de imágenes

Estudios e informes por imágenes

Cuándo lo necesita

Cuando los estudios viven encerrados en el PACS del fabricante, sacarlos tiene costo cada vez, y compartir un caso con otro centro todavía significa quemar un disco.

  • Archivo DICOM y VNA

    Almacenamiento neutral de fabricante: los estudios dejan de depender del equipo o del proveedor que los generó.

  • DICOMweb

    WADO-RS, QIDO-RS y STOW-RS para que visores y sistemas clínicos consuman los estudios por web, sin instalar nada en la estación.

  • Visor integrado

    Visualización diagnóstica y de referencia dentro del expediente, con el acceso controlado por el mismo servidor de autorización.

  • Ingesta y enrutado

    Recepción desde modalidades y PACS existentes, con reglas de enrutado, conciliación de estudios y anonimización para docencia e investigación.

  • Informe estructurado

    El informe del estudio se publica también como recurso FHIR, para que el expediente lo lea sin tener que abrir el visor.

Firmado digitalmente

Repositorio documental

Documentos con valor probatorio

Cuándo lo necesita

Cuando un consentimiento, una epicrisis o una incapacidad tiene que poder atribuirse a quien la emitió y probarse que nadie la alteró — y hoy es un PDF suelto en una carpeta compartida.

  • Firma y sellado

    Firma digital en formatos de larga duración y sellado de tiempo, para que el documento siga siendo verificable años después de emitido.

  • Verificación en el ingreso

    Todo documento que entra se verifica: firma válida, certificado vigente y cadena de confianza completa, antes de quedar archivado.

  • Índice y recuperación

    Registro y repositorio con metadatos consultables, para encontrar el documento correcto sin tener que abrirlos todos.

  • Retención y preservación

    Políticas de retención por tipo documental y preservación de la validez de la firma a lo largo del tiempo.

  • Publicación estándar

    Exposición mediante perfiles de intercambio documental, para que otro establecimiento recupere el documento sin desarrollar una integración propia.

Base común — incluida siempre

Lo que normalmente se subestima en la cotización y termina siendo la mitad del proyecto.

Identidad y autorización

Servidor de autorización propio con SMART on FHIR e IHE IUA, registro de aplicaciones cliente y permisos por rol y por caso de uso.

Auditoría y trazabilidad

Cada acceso queda registrado con quién, qué, cuándo y desde dónde, en formato consultable y con la retención que su normativa exija.

Cifrado y residencia

Cifrado en tránsito y en reposo, con la ubicación de los datos definida y declarada por escrito desde el primer día.

Respaldo y recuperación

Respaldos con restauración probada de forma periódica. Un respaldo que nadie ha intentado devolver todavía no es un respaldo.

Monitoreo y soporte

Observabilidad, alertas y un canal con tiempos de respuesta comprometidos. Cuando algo falla, no lo descubre el personal clínico.

Salida sin secuestro

Sus datos son suyos y salen completos, en formato estándar, el día que usted lo pida. Sin rescate ni conversiones a la medida.

Lo que no tiene que contratar aparte
  • Servidor de autorización
  • Certificados y su rotación
  • Auditoría y retención
  • Respaldo con restauración probada
  • Monitoreo y alertas
  • Ambiente de pruebas
  • Actualización de versiones
  • Soporte con respuesta comprometida
Acceso

El repositorio no es el riesgo. Quién puede leer qué, sí.

Un repositorio clínico sin arquitectura de acceso es un incidente con fecha pendiente. Desplegamos el circuito completo de autenticación y autorización, no una lista de usuarios con contraseña.

  1. 01

    La aplicación se identifica

    Cada sistema que consulta el repositorio está registrado como cliente, con su propia credencial y su propio alcance. No hay una cuenta compartida que medio equipo conoce.

    • OAuth 2.0
    • Registro de clientes
  2. 02

    La persona se autentica

    El profesional entra con la identidad que su organización ya usa —incluida la firma digital nacional cuando corresponde— y no con un usuario creado solo para este sistema.

    • OpenID Connect
    • IHE IUA
  3. 03

    Se emite un permiso acotado

    El token que se entrega dice exactamente qué se puede hacer y sobre qué: esta persona, estos recursos, solo lectura, por este tiempo. Un permiso amplio es una brecha esperando.

    • Scopes SMART
    • patient/ · user/ · system/
  4. 04

    El repositorio decide y recorta

    El repositorio no confía en que el cliente se porte bien: valida el permiso en cada llamada, aplica el consentimiento y devuelve únicamente lo que el permiso alcanza.

    • Autorización por recurso
    • Consentimiento
  5. 05

    Queda el rastro

    Cada acceso —el concedido y el rechazado— queda registrado de forma consultable. Cuando alguien pregunte quién vio ese expediente, hay respuesta y no una investigación.

    • ATNA
    • AuditEvent

SMART on FHIR e IHE IUA no son un capricho técnico. Son la razón por la que una aplicación clínica de terceros puede conectarse a su repositorio sin que usted le abra la base de datos, y por la que su repositorio puede aceptar la identidad de otra institución sin tener que crearle usuarios. Un esquema propio funciona bien hasta el día en que hay que integrarse con alguien más.

Conformidad

Guardar el dato no basta: tiene que cumplir el perfil

Un repositorio que acepta cualquier cosa le traslada el problema a quien consume. Validamos contra la guía de implementación en el momento de escribir, cuando corregir todavía es barato.

Cuando hay guía nacional

La situación

Costa Rica ya publicó sus guías de implementación HL7© FHIR© R5: Core, terminológica, resultados de laboratorio e informes de imágenes médicas. Lo que se publique tiene que cumplirlas.

Cómo lo resolvemos

El repositorio se configura contra esos perfiles: cada recurso que entra se valida y lo que no cumple se rechaza o se aparta con el motivo explícito, en lugar de contaminar el repositorio. Meddyg participó en el diseño, perfilamiento y publicación de esas guías.

Cuando todavía no hay

La situación

En muchos dominios —y en muchos países— aún no existe un perfil nacional publicado, y esperar a que exista no es una opción para un proyecto que ya tiene fecha.

Cómo lo resolvemos

Definimos un perfil institucional mínimo sobre el estándar base, tomando de los modelos de referencia internacionales lo que sabemos que la guía nacional va a terminar pidiendo. El dato se guarda desde el primer día en una forma que migra a la guía nacional sin reescribir lo ya cargado.

Qué revisa realmente la validación

Estructura y cardinalidad

Que el recurso traiga los elementos que el perfil exige y ninguno de los que el perfil prohíbe.

Terminología

Que los códigos pertenezcan al ValueSet que el perfil obliga, y no a una lista interna parecida que nadie más entiende.

Referencias

Que lo que el recurso apunta exista y sea del tipo correcto, para que el expediente no termine lleno de enlaces rotos.

Reglas del perfil

Las invariantes que la guía declara y que ninguna revisión estructural detecta por sí sola.

Evidencia entregable

Un reporte de conformidad que se puede presentar a quien lo pida, con el detalle de qué se validó y con qué resultado.

Operación

Qué significa exactamente «llave en mano»

Es fácil de decir y difícil de cumplir. Estos son los compromisos concretos que quedan por escrito, y la forma en que se verifica cada uno.

Disponibilidad

El compromiso

Un nivel de servicio acordado por escrito, con ventanas de mantenimiento anunciadas y tiempos de respuesta diferenciados por severidad.

Cómo se verifica

Reporte periódico de disponibilidad e incidentes, con el detalle de cada evento, su causa y lo que se cambió para que no se repita.

Respaldo y recuperación

El compromiso

Frecuencia y retención definidas, y objetivos de recuperación acordados antes de firmar en lugar de descubiertos durante el incidente.

Cómo se verifica

Pruebas de restauración periódicas y documentadas sobre un ambiente real, no sobre un procedimiento escrito.

Cifrado y residencia

El compromiso

Cifrado en tránsito y en reposo, y la ubicación física de los datos definida y declarada desde el inicio del contrato.

Cómo se verifica

Documento de arquitectura y configuración, revisable por su oficial de seguridad o de protección de datos personales.

Versiones y actualizaciones

El compromiso

Actualización del motor, de los paquetes de perfiles y de las terminologías, incluida la convivencia entre R4 y R5 mientras el ecosistema termina de decidirse.

Cómo se verifica

Ambiente de pruebas con la versión nueva antes de tocar producción, y un plan de reversa escrito para cada cambio mayor.

Observabilidad

El compromiso

Monitoreo del repositorio y de sus integraciones, con alertas que llegan a nuestro equipo antes de que el problema llegue a un consultorio.

Cómo se verifica

Tableros de uso, latencia y errores accesibles para su equipo, no solamente para el nuestro.

Salida sin secuestro

El compromiso

Sus datos son suyos. El día que decida llevárselos, salen completos y en formato estándar, con las imágenes en DICOM y los recursos en FHIR.

Cómo se verifica

Un plan de salida escrito desde el contrato: qué se exporta, en qué formato y en cuánto tiempo se entrega.

Método

De la decisión al repositorio en producción

Seis etapas. La segunda es la que evita la mayoría de los incidentes, y es la que casi siempre se salta cuando el repositorio se compra por catálogo.

  1. 01

    Alcance y dimensionamiento

    Definimos qué va a custodiar el repositorio, quién lo consulta, con qué volumen y a qué ritmo crece. De aquí sale un tamaño real y un costo de operación creíble, no una cotización de catálogo.

    Lo que queda
    • Casos de uso y volúmenes
    • Datos y documentos a alojar
    • Dimensionamiento y costo de operación
  2. 02

    Diseño del acceso

    Definimos quiénes son los clientes, qué puede pedir cada uno, cómo se autentica la persona y qué papel juega el consentimiento. Es la etapa más barata para descubrir que alguien iba a poder leer de más.

    Lo que queda
    • Matriz de clientes y permisos
    • Diseño SMART on FHIR / IUA
    • Política de auditoría y retención
  3. 03

    Despliegue y aseguramiento

    Levantamos los ambientes, aplicamos el endurecimiento, el cifrado y la residencia acordada, y dejamos el respaldo probado antes de que entre el primer dato real.

    Lo que queda
    • Ambientes de pruebas y producción
    • Configuración de seguridad documentada
    • Respaldo con restauración verificada
  4. 04

    Carga y conformidad

    Ingresamos los datos o los estudios existentes validando contra el perfil, y separamos desde el inicio lo que no cumple en lugar de dejarlo entrar y descubrirlo cuando alguien lo consulte.

    Lo que queda
    • Migración o ingesta inicial
    • Reporte de conformidad
    • Tratamiento acordado de excepciones
  5. 05

    Integración

    Conectamos el repositorio con sus sistemas clínicos, con los visores, con las modalidades y con el ecosistema al que deba responder.

    Lo que queda
    • Integraciones en operación
    • Pruebas de extremo a extremo
    • Documentación técnica de interfaces
  6. 06

    Operación y transferencia

    Operamos el repositorio con los compromisos acordados y dejamos a su equipo capaz de entender qué ocurre adentro, aunque no tenga que operarlo.

    Lo que queda
    • Runbook de operación
    • Tableros y alertas
    • Capacitación del equipo interno
Entregables

Lo que queda en manos de la organización

No un servidor y una contraseña: el repositorio operando y todo lo que hace falta para auditarlo, explicarlo y, si algún día quiere, llevárselo.

El repositorio operando

Ambientes de pruebas y producción desplegados, asegurados y monitoreados, con los accesos entregados a su organización.

Arquitectura de acceso documentada

Clientes registrados, alcances por rol y caso de uso, y el procedimiento para dar de alta o revocar un consumidor sin depender de nosotros.

Reporte de conformidad

Qué perfiles valida el repositorio, con qué resultado sobre los datos cargados y qué excepciones quedaron abiertas y por qué.

Runbook de operación

Respaldo, restauración, escalamiento y los procedimientos para los fallos que ya sabemos que van a ocurrir alguna vez.

Auditoría consultable

El registro de accesos con la retención definida y la forma concreta de responder quién vio qué, sin abrir un ticket con el proveedor.

Plan de salida

Qué se exporta, en qué formato estándar y en cuánto tiempo. Escrito desde el inicio, no negociado el día que se quiere migrar.

Experiencia

Repositorios que ya operan

Los tres tipos de repositorio de esta página corresponden a trabajo que Meddyg ya ejecutó, no a una línea de catálogo.

RepositorioFHIR en producción

Primer servidor FHIR nacional para el EDUS/CCSS

Meddyg implementó y desplegó a producción el primer servidor FHIR que recibiría las notificaciones de enfermedades de notificación obligatoria, vacunas y resultados de laboratorio del EDUS de la Caja Costarricense de Seguro Social, y posteriormente de otros establecimientos de salud.

RepositorioImágenes médicas

Arquitecturas PACS en hospitales públicos de República Dominicana

Meddyg implementó 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 (SNS).

RepositorioDocumental firmado

Firma digital de recursos FHIR con el Banco Central de Costa Rica

El BCCR invitó a Meddyg a colaborar en la integración del formato JAdES dentro de GAUDI, su plataforma de firma digital y sellado. Meddyg brindó la asistencia técnica para que los equipos del BCCR habilitaran el firmado de recursos FHIR.

RepositorioConformidad

Las guías contra las que validamos, ayudamos a escribirlas

Meddyg participó en el diseño, perfilamiento y publicación de las guías de implementación HL7© FHIR© R5 de Costa Rica: Core, terminológica, resultados de laboratorio e informes de imágenes médicas. La validación del repositorio no se configura desde afuera del estándar.

Los casos anteriores corresponden a trabajo documentado de Meddyg. DICOM, HL7© FHIR©, IHE y SMART on FHIR son estándares y modelos de referencia que aplicamos, no clientes ni certificaciones.

Para quién

Quién termina necesitando un repositorio administrado

Casi siempre no es un área de tecnología buscando servidores, sino un proyecto clínico que necesita avanzar.

Hospitales y clínicas privadas

Que necesitan una base clínica estándar sin montar —ni sostener— un área de infraestructura para operarla.

Centros de imágenes y laboratorios

Que quieren dejar de depender del PACS del fabricante y entregar sus resultados donde el clínico ya trabaja.

Instituciones públicas de salud

Que deben cumplir la guía nacional y demostrar trazabilidad de cada acceso a la información de una persona.

Empresas de software clínico

Que necesitan un backend FHIR conforme para su producto, sin desviar a su equipo a construir y operar uno propio.

Aseguradoras y administradoras

Que reciben información clínica de terceros y deben custodiarla con control de acceso, retención y valor probatorio.

Programas nacionales y regionales

Que necesitan un punto de recepción confiable para notificaciones, registros o reportes de muchos establecimientos a la vez.

Autodiagnóstico

Señales de que le hace falta uno

Tiene un proyecto clínico detenido esperando dónde guardar los datos.
Necesita un servidor FHIR en producción y nadie en su equipo ha operado uno antes.
Sacar los estudios del PACS actual tiene costo cada vez que lo intenta.
Le exigieron cumplir la guía nacional y no tiene con qué validar lo que publica.
No puede responder hoy quién consultó el expediente de una persona el mes pasado.
Guarda documentos que deberían tener valor probatorio y hoy son archivos sin firma.

Si reconoce dos o más, el problema no es de presupuesto de infraestructura: es de tiempo. Un repositorio administrado entra en operación en semanas, no en el próximo ciclo presupuestario.

¿Cuánto lleva su proyecto esperando infraestructura?

Cuéntenos qué necesita custodiar y quién debe consultarlo. Le decimos qué repositorio le corresponde, qué incluye, en cuánto tiempo entra en operación y cuánto cuesta mantenerlo andando.

Solicitar una propuesta→Hablar con un especialista
Continuidad

Antes y después del repositorio

El repositorio resuelve dónde viven los datos. Alrededor hay decisiones que conviene tomar antes y trabajo que continúa después.

Evaluación de interoperabilidadCuando todavía no hay claridad de qué sistemas producen la información que el repositorio va a recibir.Definición de arquitecturasCuando el repositorio es una pieza de una arquitectura mayor que aún no está definida.Guías de ImplementaciónCuando el perfil contra el que debe validar el repositorio todavía no está escrito ni publicado.Modelado de datosCuando lo que se va a cargar significa cosas distintas según el sistema del que viene.Capa FHIRCuando los sistemas que alimentan el repositorio no hablan FHIR y no van a ser reemplazados.Integración con HIECuando el repositorio debe además responder a un ecosistema nacional de intercambio.
Ver todos los servicios→