API Vidamos — cumplimiento RDA e RIPS

POST /rips/validar

Validar un RIPS sin transmitir (dry-run)

Ejecuta la puerta local de validación (reglas del Documento Técnico 1 v003 + catálogos oficiales) SIN tocar el MUV ni persistir nada. Ideal para integrar en el flujo del cliente ANTES de radicar: se corrige hasta que valid sea true.

Cuerpo de la petición application/json

{
  "rips": {}
}

Respuestas

GET /rips

Listar radicaciones de la entidad

Últimas 100 radicaciones (cada intento es una fila — evidencia append-only).

Respuestas

POST /rips

Radicar un RIPS ante el MUV (obtiene el CUV)

Valida localmente, transmite al Mecanismo Único de Validación con las credenciales SISPRO de la entidad y persiste la evidencia del intento. La operación del MUV se elige sola según rips.tipoNota: factura (null), NC, ND, NA (nota de ajuste, sin adjunto) o RS (RIPS sin factura, sin adjunto).

La puerta local revisa dos cosas antes de gastar el viaje al MUV: el RIPS contra el Documento Técnico 1 y el XML de la factura contra el Documento Técnico 2 (contenedor AttachedDocument con factura y ApplicationResponse embebidos, apartados obligatorios, extensión del sector salud, pagos anticipados, periodo de facturación y el cruce PFP001: el número de la factura del XML debe ser idéntico a rips.numFactura). Los rechazos salen como rechazado-local con los mismos códigos del MUV (FED*, VFE*, PFE*, PFP001, RVG018…) y su comoCorregir; las notificaciones del DocTec2 las emite el propio MUV al radicar.

Cuerpo de la petición application/json

{
  "rips": {},
  "xmlFevFile": ""
}

Respuestas

GET /rips/{id}

Detalle de una radicación con sus errores accionables

Parámetros

Respuestas

GET /rips/{id}/cuv

Verificar el CUV de una radicación ante el MUV (lo que consulta el pagador)

Consulta ConsultarCUV del Mecanismo Único de Validación (manual API-Docker v4.3 §8.14) con el obligado y el número de documento de la radicación, y compara el CUV que devuelve el Ministerio con el que Vidamos guardó. verificado es true solo si el MUV conoce el documento y el CUV coincide. La operación no requiere credenciales SISPRO: es la misma consulta que hace la entidad responsable de pago.

Parámetros

Respuestas

GET /rda/{id}/ihce

Recuperar el RDA propio tal como quedó registrado en IHCE

Consulta GET /Composition/{id}/$document del gateway (manual de operaciones v1.4 §5.5 op. 10) con el id de Composition que IHCE devolvió al aceptar el RDA, y reenvía el Bundle completo al tenant que lo transmitió. Vidamos no persiste ni registra el contenido clínico; la consulta queda en la auditoría del envío. Solo aplica a RDA aceptado.

Parámetros

Respuestas

POST /rda/consultas

Listar los RDA de un paciente registrados en IHCE (consulta del profesional autorizado)

Consulta $consultar-rda-paciente (RDA de paciente) o $consultar-rda-encuentros-clinicos (urgencias, hospitalización, consulta externa) del gateway, manual de operaciones v1.4 §5.5 op. 7 y 8. El Ministerio exige y audita quién consulta (§5.4 n.º 9): humanuser es la identificación de la persona, normalmente el profesional de la salud, y es obligatoria. Vidamos la deja en su propia auditoría como actor y no persiste el número del paciente. La respuesta se reduce a metadatos (id de Composition, VIDA, fecha, tipo); el documento completo se pide con GET /rda/{id}/ihce cuando es propio. Paginación token-based: si siguiente no es null, repita la llamada con ese valor en cursor; un cursor vencido responde 410.

Cuerpo de la petición application/json

{
  "alcance": "paciente",
  "paciente": {
    "tipo": "CC",
    "numero": "000000099"
  },
  "humanuser": {
    "tipo": "CC",
    "numero": "111111199"
  },
  "cursor": ""
}

Respuestas

POST /rda/validar

Validar un Bundle RDA sin transmitir (linter estructural)

Cuerpo de la petición application/json

{
  "bundle": {}
}

Respuestas

POST /rda/validar-oficial

Validar un Bundle contra el validador oficial HL7 (conformidad de perfiles)

Dry-run contra el validador oficial del estándar con los paquetes minsalud.fhir.co.rda y FHIR Core CO — la vara de conformidad del Ministerio, más estricta que el linter de /rda/validar. Es pesado (arranca una JVM): pensado para diagnóstico y certificación, no para cada transmisión. Responde 503 si el ambiente no tiene validador configurado.

Cuerpo de la petición application/json

{
  "bundle": {}
}

Respuestas

POST /rda/desde-datos

Transmitir un RDA desde datos planos (sin saber FHIR)

La promesa del producto: el cliente envía el modelo intermedio en español (paciente, autor, prestador, atención, diagnósticos…) y la plataforma construye el Bundle conforme a los perfiles oficiales, lo valida y lo transmite a IHCE. Si faltan datos que el perfil oficial exige, responde 400 con la lista campo por campo en español.

Cuerpo de la petición application/json

{
  "tipo": "paciente",
  "datos": {}
}

Respuestas

GET /rda

Listar transmisiones RDA

Parámetros

Respuestas

POST /rda

Transmitir un Bundle RDA ya construido

Cuerpo de la petición application/json

{
  "tipo": "paciente",
  "bundle": {}
}

Respuestas

GET /rda/{id}

Detalle de una transmisión RDA (errores accionables incluidos)

Parámetros

Respuestas

GET /rda/{id}/eventos

Trazabilidad completa de una transmisión (auditoría)

Parámetros

Respuestas

GET /resumen

Resumen de cumplimiento (conteos por estado y tipo)

Respuestas

GET /sesion

Con qué entidad, papel, módulos y permisos entra la credencial

Devuelve el tenant (slug, nombre, tipoEntidad, módulos contratados), la identidad (api-key, o usuario con su rol) y los permisos efectivos: los del rol cuyo módulo está contratado. El panel construye la navegación desde esta respuesta. Un módulo no contratado responde 403 con codigo/modulo en cualquiera de sus rutas.

Respuestas

GET /health

Liveness

Respuestas

GET /ready

Readiness (estado real de cada dependencia)

Respuestas

ErrorAccionable

Un hallazgo explicado para humanos: DÓNDE está el problema en términos de negocio, QUÉ está mal y CÓMO corregirlo. Diseñado para que el personal operativo resuelva sin escalar a soporte.

RipsIssue

Radicacion