{ "info": { "name": "API Vidamos — cumplimiento RDA e RIPS", "description": "**Disponibilidad:** cualquier ruta puede responder `503` con cuerpo\n`{ \"error\", \"codigo\": \"bd-arrancando\", \"reintentarEnSegundos\" }` y cabecera `Retry-After`\nmientras la base de datos despierta tras un periodo de inactividad (±20 s). Reintente\npasado ese tiempo; ninguna operación se ejecutó.\n\nAPI REST del motor de cumplimiento de Vidamos para prestadores y software de salud\nen Colombia:\n\n- **RDA** (Resolución 1888/2025, mod. 1799/2026): generación, validación y transmisión\n del Resumen Digital de Atención a la plataforma IHCE del Ministerio de Salud, con\n número VIDA y trazabilidad completa.\n- **RIPS** (Resolución 948/2026): validación y radicación del RIPS como soporte de la\n FEV contra el Mecanismo Único de Validación (MUV), con CUV y trazabilidad.\n\n**Integración 100% headless**: toda la operación se realiza desde el código del\nsistema del cliente. Los errores llegan **accionables y en español** (dónde está el\nproblema en términos de negocio, qué está mal y cómo corregirlo) — ver el esquema\n`ErrorAccionable`.\n\nLa autenticación es por API key de la entidad (header `X-Api-Key`), emitida durante\nel onboarding. Las credenciales ante el Ministerio (Entra ID para IHCE, SISPRO para\nel MUV) son de cada entidad y se configuran una sola vez.\n\n\nGenerada desde el contrato OpenAPI publicado en https://vidamos.co/docs/api/", "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json" }, "auth": { "type": "apikey", "apikey": [ { "key": "key", "value": "X-Api-Key", "type": "string" }, { "key": "value", "value": "{{apiKey}}", "type": "string" }, { "key": "in", "value": "header", "type": "string" } ] }, "variable": [ { "key": "baseUrl", "value": "https://api.vidamos.co", "type": "string" }, { "key": "apiKey", "value": "", "type": "secret" } ], "item": [ { "name": "RIPS", "description": "Validación y radicación RIPS→MUV (Res. 948/2026)", "item": [ { "name": "Validar un RIPS sin transmitir (dry-run)", "request": { "method": "POST", "header": [ { "key": "Content-Type", "value": "application/json" } ], "url": { "raw": "{{baseUrl}}/rips/validar", "host": [ "{{baseUrl}}" ], "path": [ "rips", "validar" ] }, "description": "Validar un RIPS sin transmitir (dry-run)\n\nEjecuta la puerta local de validación (reglas del Documento Técnico 1 v003 +\ncatálogos oficiales) SIN tocar el MUV ni persistir nada. Ideal para integrar en\nel flujo del cliente ANTES de radicar: se corrige hasta que `valid` sea `true`.\n", "body": { "mode": "raw", "raw": "{\n \"rips\": {}\n}", "options": { "raw": { "language": "json" } } } }, "response": [] }, { "name": "Listar radicaciones de la entidad", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/rips", "host": [ "{{baseUrl}}" ], "path": [ "rips" ] }, "description": "Listar radicaciones de la entidad\n\nÚltimas 100 radicaciones (cada intento es una fila — evidencia append-only)." }, "response": [] }, { "name": "Radicar un RIPS ante el MUV (obtiene el CUV)", "request": { "method": "POST", "header": [ { "key": "Content-Type", "value": "application/json" } ], "url": { "raw": "{{baseUrl}}/rips", "host": [ "{{baseUrl}}" ], "path": [ "rips" ] }, "description": "Radicar un RIPS ante el MUV (obtiene el CUV)\n\nValida localmente, transmite al Mecanismo Único de Validación con las credenciales\nSISPRO de la entidad y persiste la evidencia del intento. La operación del MUV se\nelige sola según `rips.tipoNota`: factura (`null`), NC, ND, NA (nota de ajuste,\nsin adjunto) o RS (RIPS sin factura, sin adjunto).\n\nLa puerta local revisa dos cosas antes de gastar el viaje al MUV: el RIPS contra el\nDocumento Técnico 1 y el XML de la factura contra el Documento Técnico 2 (contenedor\nAttachedDocument con factura y ApplicationResponse embebidos, apartados obligatorios,\nextensión del sector salud, pagos anticipados, periodo de facturación y el cruce\nPFP001: el número de la factura del XML debe ser idéntico a `rips.numFactura`). Los\nrechazos salen como `rechazado-local` con los mismos códigos del MUV (FED*, VFE*,\nPFE*, PFP001, RVG018…) y su `comoCorregir`; las notificaciones del DocTec2 las emite\nel propio MUV al radicar.\n", "body": { "mode": "raw", "raw": "{\n \"rips\": {},\n \"xmlFevFile\": \"\"\n}", "options": { "raw": { "language": "json" } } } }, "response": [] }, { "name": "Detalle de una radicación con sus errores accionables", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/rips/:id", "host": [ "{{baseUrl}}" ], "path": [ "rips", ":id" ], "variable": [ { "key": "id", "value": "" } ] }, "description": "Detalle de una radicación con sus errores accionables" }, "response": [] }, { "name": "Verificar el CUV de una radicación ante el MUV (lo que consulta el pagador)", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/rips/:id/cuv", "host": [ "{{baseUrl}}" ], "path": [ "rips", ":id", "cuv" ], "variable": [ { "key": "id", "value": "" } ] }, "description": "Verificar el CUV de una radicación ante el MUV (lo que consulta el pagador)\n\nConsulta `ConsultarCUV` del Mecanismo Único de Validación (manual API-Docker v4.3\n§8.14) con el obligado y el número de documento de la radicación, y compara el CUV\nque devuelve el Ministerio con el que Vidamos guardó. `verificado` es `true` solo si\nel MUV conoce el documento y el CUV coincide. La operación no requiere credenciales\nSISPRO: es la misma consulta que hace la entidad responsable de pago.\n" }, "response": [] } ] }, { "name": "RDA", "description": "Generación, validación y transmisión RDA→IHCE (Res. 1888/2025)", "item": [ { "name": "Recuperar el RDA propio tal como quedó registrado en IHCE", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/rda/:id/ihce", "host": [ "{{baseUrl}}" ], "path": [ "rda", ":id", "ihce" ], "variable": [ { "key": "id", "value": "" } ] }, "description": "Recuperar el RDA propio tal como quedó registrado en IHCE\n\nConsulta `GET /Composition/{id}/$document` del gateway (manual de operaciones v1.4\n§5.5 op. 10) con el id de Composition que IHCE devolvió al aceptar el RDA, y reenvía\nel Bundle completo al tenant que lo transmitió. Vidamos no persiste ni registra el\ncontenido clínico; la consulta queda en la auditoría del envío. Solo aplica a RDA\n`aceptado`.\n" }, "response": [] }, { "name": "Listar los RDA de un paciente registrados en IHCE (consulta del profesional autorizado)", "request": { "method": "POST", "header": [ { "key": "Content-Type", "value": "application/json" } ], "url": { "raw": "{{baseUrl}}/rda/consultas", "host": [ "{{baseUrl}}" ], "path": [ "rda", "consultas" ] }, "description": "Listar los RDA de un paciente registrados en IHCE (consulta del profesional autorizado)\n\nConsulta `$consultar-rda-paciente` (RDA de paciente) o `$consultar-rda-encuentros-clinicos`\n(urgencias, hospitalización, consulta externa) del gateway, manual de operaciones v1.4\n§5.5 op. 7 y 8. El Ministerio exige y audita quién consulta (§5.4 n.º 9): `humanuser`\nes la identificación de la persona, normalmente el profesional de la salud, y es\nobligatoria. Vidamos la deja en su propia auditoría como actor y no persiste el número\ndel paciente. La respuesta se reduce a metadatos (id de Composition, VIDA, fecha, tipo);\nel documento completo se pide con `GET /rda/{id}/ihce` cuando es propio.\nPaginación token-based: si `siguiente` no es null, repita la llamada con ese valor en\n`cursor`; un cursor vencido responde 410.\n", "body": { "mode": "raw", "raw": "{\n \"alcance\": \"paciente\",\n \"paciente\": {\n \"tipo\": \"CC\",\n \"numero\": \"000000099\"\n },\n \"humanuser\": {\n \"tipo\": \"CC\",\n \"numero\": \"111111199\"\n },\n \"cursor\": \"\"\n}", "options": { "raw": { "language": "json" } } } }, "response": [] }, { "name": "Validar un Bundle RDA sin transmitir (linter estructural)", "request": { "method": "POST", "header": [ { "key": "Content-Type", "value": "application/json" } ], "url": { "raw": "{{baseUrl}}/rda/validar", "host": [ "{{baseUrl}}" ], "path": [ "rda", "validar" ] }, "description": "Validar un Bundle RDA sin transmitir (linter estructural)", "body": { "mode": "raw", "raw": "{\n \"bundle\": {}\n}", "options": { "raw": { "language": "json" } } } }, "response": [] }, { "name": "Validar un Bundle contra el validador oficial HL7 (conformidad de perfiles)", "request": { "method": "POST", "header": [ { "key": "Content-Type", "value": "application/json" } ], "url": { "raw": "{{baseUrl}}/rda/validar-oficial", "host": [ "{{baseUrl}}" ], "path": [ "rda", "validar-oficial" ] }, "description": "Validar un Bundle contra el validador oficial HL7 (conformidad de perfiles)\n\nDry-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.\n", "body": { "mode": "raw", "raw": "{\n \"bundle\": {}\n}", "options": { "raw": { "language": "json" } } } }, "response": [] }, { "name": "Transmitir un RDA desde datos planos (sin saber FHIR)", "request": { "method": "POST", "header": [ { "key": "Content-Type", "value": "application/json" } ], "url": { "raw": "{{baseUrl}}/rda/desde-datos", "host": [ "{{baseUrl}}" ], "path": [ "rda", "desde-datos" ] }, "description": "Transmitir un RDA desde datos planos (sin saber FHIR)\n\nLa promesa del producto: el cliente envía el modelo intermedio en español\n(paciente, autor, prestador, atención, diagnósticos…) y la plataforma construye\nel Bundle conforme a los perfiles oficiales, lo valida y lo transmite a IHCE.\nSi faltan datos que el perfil oficial exige, responde 400 con la lista campo por\ncampo en español.\n", "body": { "mode": "raw", "raw": "{\n \"tipo\": \"paciente\",\n \"datos\": {}\n}", "options": { "raw": { "language": "json" } } } }, "response": [] }, { "name": "Listar transmisiones RDA", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/rda", "host": [ "{{baseUrl}}" ], "path": [ "rda" ], "query": [ { "key": "estado", "value": "", "disabled": true, "description": "" } ] }, "description": "Listar transmisiones RDA" }, "response": [] }, { "name": "Transmitir un Bundle RDA ya construido", "request": { "method": "POST", "header": [ { "key": "Content-Type", "value": "application/json" } ], "url": { "raw": "{{baseUrl}}/rda", "host": [ "{{baseUrl}}" ], "path": [ "rda" ] }, "description": "Transmitir un Bundle RDA ya construido", "body": { "mode": "raw", "raw": "{\n \"tipo\": \"paciente\",\n \"bundle\": {}\n}", "options": { "raw": { "language": "json" } } } }, "response": [] }, { "name": "Detalle de una transmisión RDA (errores accionables incluidos)", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/rda/:id", "host": [ "{{baseUrl}}" ], "path": [ "rda", ":id" ], "variable": [ { "key": "id", "value": "" } ] }, "description": "Detalle de una transmisión RDA (errores accionables incluidos)" }, "response": [] }, { "name": "Trazabilidad completa de una transmisión (auditoría)", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/rda/:id/eventos", "host": [ "{{baseUrl}}" ], "path": [ "rda", ":id", "eventos" ], "variable": [ { "key": "id", "value": "" } ] }, "description": "Trazabilidad completa de una transmisión (auditoría)" }, "response": [] }, { "name": "Resumen de cumplimiento (conteos por estado y tipo)", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/resumen", "host": [ "{{baseUrl}}" ], "path": [ "resumen" ] }, "description": "Resumen de cumplimiento (conteos por estado y tipo)" }, "response": [] } ] }, { "name": "Estado", "description": "Salud del servicio", "item": [ { "name": "Con qué entidad, papel, módulos y permisos entra la credencial", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/sesion", "host": [ "{{baseUrl}}" ], "path": [ "sesion" ] }, "description": "Con qué entidad, papel, módulos y permisos entra la credencial\n\nDevuelve el tenant (slug, nombre, tipoEntidad, módulos contratados), la identidad\n(`api-key`, o `usuario` con su rol) y los permisos efectivos: los del rol cuyo módulo\nestá contratado. El panel construye la navegación desde esta respuesta. Un módulo no\ncontratado responde `403` con `codigo`/`modulo` en cualquiera de sus rutas.\n" }, "response": [] }, { "name": "Liveness", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/health", "host": [ "{{baseUrl}}" ], "path": [ "health" ] }, "description": "Liveness", "auth": { "type": "noauth" } }, "response": [] }, { "name": "Readiness (estado real de cada dependencia)", "request": { "method": "GET", "header": [], "url": { "raw": "{{baseUrl}}/ready", "host": [ "{{baseUrl}}" ], "path": [ "ready" ] }, "description": "Readiness (estado real de cada dependencia)", "auth": { "type": "noauth" } }, "response": [] } ] } ] }