Lizandro GuarnizoandClaude Sonnet 4.6
0ec4ae3e66
- numero: usar NUM_FACTURA en lugar de cadena vacía
- codFormaPago: CLIP (particular) / INST (EPS) según TNS real
- tipousuario: fallback desde TIPOUSU cuando TIPOUSUSISPRO es NULL
- fechaHoraEgreso: última FECHA_REPORTADO en lugar de FECHA_RECEPCION
- _fmt_datetime: eliminar espacios en tiempo ("06: 08: 29" → "06:08:29")
- especialidad: limpiar valores basura (., -, 0, 00)
- telefono: fallback "0000000" cuando vacío (campo requerido TNS)
- profesional: COALESCE(USUARIO, MEDICO.CODIGO) en queries SQL
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
5.5 KiB
Análisis de Campos RIPS vs Normas vigentes
Fecha: 2026-06-25
Proyecto: rips_manager (TNS API v2)
1. ¿Qué normas hay en esta carpeta?
| Sobre qué trata | ¿Es RIPS? | |
|---|---|---|
| Res. 866 de 2021 | Datos clínicos relevantes para interoperabilidad de Historia Clínica (IHCE) | ❌ No es RIPS |
| Res. 1888 de 2025 | Adopta el RDA (Resumen Digital de Atención) — historia clínica interoperable | ❌ No es RIPS |
| Res. 1995 de 1999 | Normas de manejo y custodia de historia clínica | ❌ No es RIPS |
| Anexo Técnico Res. 866 | Estructura técnica del conjunto de datos clínicos RDA/IHCE | ❌ No es RIPS |
Importante: RIPS está regido por Res. 2275 de 2023 (vigente desde 1-abr-2024), actualizada por Res. 558/2024 y Res. 1884/2024. Esa resolución NO está en esta carpeta.
2. RIPS vigente: ¿qué campos exige Res. 2275/2023?
Los campos del archivo FVLH03404/ripsjson_FVLH03404.json corresponden exactamente al formato Res. 2275:
A nivel de USUARIO (paciente):
| Campo | ¿Nuestro sistema lo envía? | Dónde |
|---|---|---|
| tipoDocumentoIdentificacion | ✅ | tipoDocumento en Tercero/Crear |
| numDocumentoIdentificacion | ✅ | nit en Tercero/Crear |
| fechaNacimiento | ✅ | fechaNacimiento en Tercero/Crear |
| codSexo | ✅ | sexo en Tercero/Crear |
| tipoUsuario | ✅ | tipousuario en RdaPaciente |
| codMunicipioResidencia | ✅ | codigoCiudad en Tercero/Crear |
| codZonaTerritorialResidencia | ✅ | zona en Tercero/Crear |
| codPaisResidencia | ❌ No enviamos | TNS lo gestiona con "170" por defecto |
| codPaisOrigen | ❌ No enviamos | TNS lo gestiona con "170" por defecto |
| incapacidad | ❌ No enviamos | TNS lo gestiona internamente |
A nivel de PROCEDIMIENTO (por examen):
| Campo | ¿Nuestro sistema lo envía? | Dónde |
|---|---|---|
| codProcedimiento | ✅ | codigoMaterial en detallePedido |
| fechaInicioAtencion | ✅ | fechaHoraRealizacion en detallePedido |
| codDiagnosticoPrincipal | ✅ | diagnosticoprincipal en detallePedido |
| vrServicio | ✅ | valor en detallePedido |
| finalidadTecnologiaSalud | ❌ No enviamos | TNS lo gestiona — campo RIPS interno |
| viaIngresoServicioSalud | ⚠️ Parcial | viaIngreso: "01" fijo en cabecera RDA |
| modalidadGrupoServicioTecSal | ❌ No enviamos | TNS lo gestiona internamente |
| grupoServicios | ❌ No enviamos | TNS lo gestiona internamente |
| codServicio | ❌ No enviamos | TNS lo gestiona internamente |
| valorPagoModerador | ❌ No enviamos | TNS pone 0 para particulares |
| conceptoRecaudo | ❌ No enviamos | TNS lo gestiona internamente |
| numAutorizacion | ✅ | numeroAutorizacion en RdaPaciente |
| idMIPRES | ❌ No enviamos | Opcional — solo si aplica MIPRES |
| tipoDoc/numDoc profesional | ⚠️ Parcial | Solo enviamos username (profesional) |
3. ¿Los campos que no enviamos son un problema?
NO, porque TNS API es un intermediario habilitado por MinSalud que:
- Recibe nuestros datos en su formato simplificado (RdaPaciente/Insertar)
- Completa internamente los campos RIPS (finalidad, grupoServicios, codServicio, conceptoRecaudo, etc.) basándose en la configuración del prestador (sucursal 81080)
- Genera y transmite el RIPS completo en formato Res. 2275 al MinSalud
Los campos que sí debemos revisar:
| Campo | Riesgo | Acción |
|---|---|---|
finalidadTecnologiaSalud |
Medio — varía por examen (23 vs 15 en el JSON antiguo) | TNS puede manejarlo por tipo de procedimiento |
viaIngresoServicioSalud |
Bajo — laboratorio siempre es "02" (Extramural) | Confirmar con TNS si aceptan fijo |
| Doc. del profesional (CC) | Bajo — TNS usa username del sistema | Si TNS lo requiere, agregar campo |
4. Campos del RDA (Res. 1888/2025) que SÍ cubrimos
La Res. 1888 define el "Resumen Digital de Atención" para IHCE (interoperabilidad). Estos campos coinciden con lo que ya enviamos a TNS:
| Campo RDA | Nuestro campo TNS |
|---|---|
| Municipio de residencia habitual | codigoCiudad |
| Zona territorial de residencia | zona |
| Fecha y hora de inicio de la atención | fechaHoraIngreso / fechaHoraRealizacion |
| Fecha y hora de fin de la atención | fechaHoraEgreso |
| Diagnóstico principal (CIE-10) | diagnosticoprincipal |
| Tipo de usuario | tipousuario |
| Profesional que realizó la atención | profesional |
| Grupo de servicios | modalidadAtencion: "01" (parcial) |
5. Resoluciones RIPS vigentes (imagen historial CNT)
Según el historial de resoluciones RIPS:
- Res. 2275/2023 → vigente desde 1-abr-2024 (formato xml + json)
- Res. 558/2024 → vigente desde 1-oct-2024 (actualización)
- Res. 1884/2024 → vigente desde 1-oct-2024 (actualización)
Estas son las normas que rigen el RIPS actual. Ninguna está en la carpeta norma — solo hay normas de RDA/IHCE.
6. Conclusión
✅ Lo que hacemos está bien para el flujo TNS API v2:
- Enviamos todos los campos que TNS requiere en su documentación
- TNS completa los campos RIPS internos (finalidad, grupoServicios, etc.)
⚠️ Recomendación: Agregar a la carpeta norma/ la Res. 2275 de 2023 y la Res. 558 de 2024 para tener la norma RIPS vigente de referencia.
⚠️ Pendiente confirmar con TNS: Si finalidadTecnologiaSalud (campo que varía entre exámenes de laboratorio) debe venir de la BD del laboratorio y enviarse en el detallePedido.