Guía sobre la estructura de los datos a reportar en los RIPS en formato JSON

Publicado: 27 de febrero de 2024

---

El pasado mes de diciembre, el Ministerio de Salud y Protección Social emitió la Resolución 2275 de 2023 por medio de la cual “… se expide la resolución única reglamentaria del Registro Individual de Prestación de Servicios de Salud -RIPS, soporte de la Factura Electrónica de Venta -FEV en salud y se dictan otras disposiciones”.

El objeto de dicha resolución es unificar y actualizar las disposiciones relativas al proceso de generación del RIPS como soporte de la FEV en salud, permitiendo la integración de los campos de datos del RIPS con los campos de datos adicionales del sector salud que se deberán contemplar en la generación de la factura electrónica de venta, los cuales serán validados por el Ministerio de Salud y Protección Social, estableciendo el conjunto de información administrativa, financiera y asistencial, las reglas de validación aplicables a su estructura, contenido y relación, y la transmisión de archivos ante el mecanismo único de validación, como condiciones para adelantar el reconocimiento y pago de la prestación o provisión de servicios y tecnologías de salud en el territorio nacional.

Con el fin de lograr este objeto, se establece que los Registros Individuales de Prestación de Servicios de Salud (RIPS) deberán ser presentados en formato JSON y serán soporte de la Factura Electrónica de Venta (FEV). De esta manera, el Ministerio establece unas reglas de validación que corresponden a las condiciones de carácter técnico aplicables a la estructura, contenido y relación de los campos de datos del RIPS como soporte de la factura electrónica de venta en salud, para garantizar la consistencia y razonabilidad de la información.

Ahora bien, con respecto a la estructura del archivo en formato JSON, ésta se encuentra especificada en el Anexo Técnico 1 de la resolución 2275 de 2023. Este anexo contiene la estructura del archivo, es decir, los objetos que lo conforman, tales como: transacción, usuarios, servicios, consultas, medicamentos, procedimientos, urgencias, hospitalizacion, recienNacidos y otrosServicios. De igual manera, el anexo contiene, para cada objeto, el nombre del campo, el tipo, tamaño y observaciones a tener en cuenta para una correcta generación del archivo.

1. Nombre de los campos (propiedades)

Con respecto al nombre del campo es obligatorio que corresponda al establecido en la resolución, por ejemplo: en el objeto “usuarios” existe un campo llamado “numDocumentoldObligado” y así debe ser reportado, no se acepta “numeroDocIdObligado” ni “numdocumentoidobligado” u otros posibles variaciones.

Estos campos (los nombres) se conocen como “propiedades” y tienen una validación de estructura ya que los “Nombres de propiedades (son sensibles a minúsculas y mayúsculas)”, así lo establece el numeral 1.2 del anexo técnico.La causal de rechazo RVG01 establece que “Solo se podrá validar los RIPS si cumplen con la estructura establecida”.

2. Tipo de dato

Los tipos de datos se ajustan según los tipos de datos permitidos en JSON y sobre los cuales aplicarán validaciones de contenido. La resolución contempla 2 tipos de dato:

- Cadena (C) que corresponde a una cadena de texto (puede ser alfanumérica) y su contenido va dentro de comillas dobles. Acepta caracteres UNICODE permitidos en JSON sin tener en cuenta caracteres especiales, y;

- Numérico (N) compuesto por números enteros positivos, es importante recordar que no se deben informar el separador de miles. Aunque sea redundante, se aclara que por permitirse solamente números enteros implica por definición que no se aceptan decimales . De igual manera la resolución prohibe valores negativos. Si se reportan valores o cantidades negativas se informa la generación de la regla de rechazo RVG01.

Si se reporta un tipo de dato errado se generará la regla de rechazo “RVG04 El dato informado debe corresponder al tipo de dato requerido”. Por ejemplo, en el objeto urgencias existe una propiedad (campo) de nombre “causaMotivoAtencion” que es de tipo Cadena, si se reporta 22, se toma como un número y no como una cadena, se genera el rechazo. Para evitarlo, debe ser reportado como “22” porque el tipo de dato Cadena siempre debe ir dentro de comillas dobles.

3. Tamaño del dato

3.1. Tamaño Fijo sin nulos

Explica la resolución que “Existen datos con tamaño fijo y datos con tamaño variable. Los datos de tamaño fijo no admiten información con otro número de posición diferente a la que se establece, es decir, la información en este tipo de configuración siempre tiene exactamente el mismo tamaño".

Un ejemplo de tamaño de dato fijo, en el objeto “usuarios”, es el campo código “U01” y propiedad “tipoDocumentoIdentificacion” cuyo tamaño permitido es 2. Por lo que se espera que sea diligenciado “CC” para informar Cédula de Ciudadanía, no permitiendo “C” o “Cédula de Ciudadanía”, ya que el primero tiene un tamaño de 1 y el segundo un tamaño de 20. Al ser de tamaño fijo, tampoco se puede dejar de reportar, es decir no tolera el valor null o 0. Si no se cumple con el tamaño se genera la regla de validación general RVG05 que corresponde a un Rechazo ya que El dato informado debe corresponder al tamaño de dato requerido.

3.2. Tamaño Fijo con nulos

Existe en la Resolución, datos de tamaño fijo que toleran nulos, es decir, se reporta el dato con el tamaño establecido o nulo (null). Por ejemplo, en el objeto “usuarios”, el campo de código “U07”, propiedad “codMunicipioResidencia” debe ser una Cadena con tamaño “0, 5”, es decir, para Bogotá se debe reportar “11001” y si no se conoce el código de municipio se reporta null (sin comillas).

3.3. Tamaño Variable sin nulos

También existen “Los datos de tamaño variable [que] admiten un rango de número de posiciones que varía de un mínimo hasta un máximo. En caso de que la información no utilice el número máximo de posiciones, no se deben incluir caracteres para rellenar el espacio, tales como ceros, blancos o espacios.”

Por ejemplo, en el objeto “usuarios” el campo de código “U02” y propiedad “numDocumentoIdentificacion” tipo Cadena tiene un tamaño de “4-20”, es decir mínimo 4 a máximo 20 caracteres. Se puede reportar “123456” y cumple. No se puede reportar “123” por ser menor a límite inferior (4 caracteres) ni “ABCDEFGHIJK0123456789” por ser superior al limite superior (20 caracteres) ya que contiene 21 caracteres. Tampoco se puede reportar null porque el mínimo a reportar son 4 caracteres. Para el ejemplo, “123456” tampoco se deben rellenar con ceros o espacios para llegar al límite máximo, esto quiere decir que no se debe reportar “00000000000000123456”.

3.4. Tamaño Variable con nulos

Se observa que existen datos de tamaño variable que toleran valor nulo. Por ejemplo, en el objeto “procedimientos”, el campo de código “P04” y propiedad “numAutorizacion” tipo Cadena tiene un tamaño “0-30”, es decir acepta null y hasta 30 caracteres, por ejemplo: se puede reportar: “1”, “ABC15”, “123456789” sin que se sobrepasen los 30 caracteres o null (sin comillas dobles).

Otra variación de este tamaño es el que acepta nulo y un rango de caracteres. Por ejemplo: en el objeto “consultas” de código “C11” y propiedad “codDiagnosticoRelacionado1” tipo Cadena tiene un tamaño “0, 4-25”, es decir tolera reportar null, pero si se reporta debe ser de mínimo 4 a 25 caracteres. Por ejemplo, no es posible reportar “123” por ser de 3 caracteres ni ningún valor que sobrepase los 25. Si no se tiene la información se debe reportar null (Sin comillas dobles).

El no cumplimiento de los tamaños establecidos en la resolución genera la regla de validación general RVG05 que es de Rechazo y es porque El dato informado debe corresponder al tamaño de dato requerido.

4. Tabla de referencia

A continuación se presenta una tabla de referencia que consideramos de utilidad para comprender mejor la estructura de los datos a reportar en los RIPS en formato JSON:

---

Si tienes dudas, comentarios, sugerencias con respecto a este artículo u otro tema, no dudes en ponerte en contacto con nosotros, dando clic aquí.

---