Módulo Registro de Cáncer - Guía de diseño del sistema¶
Introducción¶
El kit de herramientas DHIS2 para el Registro de Cáncer se basa en normas y principios reconocidos internacionalmente para el registro de cáncer de base poblacional, tal como los define la Agencia Internacional de Investigación sobre el Cáncer (IARC) en Cancer Registration: Principles and Methods (Publicaciones Científicas de la IARC n.o 160, 2021) y operacionalizados a través del software CanReg5 desarrollado por la IARC. Este kit de herramientas incluye un programa Tracker de DHIS2 alineado con los estándares de datos de CanReg5 para el registro individual de casos de cáncer, apoyando el monitoreo de base poblacional a nivel de registro, así como una aplicación personalizada de DHIS2 para exportar los datos del programa Tracker al formato CanReg5.
El kit de herramientas del Registro de Cáncer está diseñado para apoyar a los registros de cáncer de base poblacional en el fortalecimiento de sus procesos rutinarios de gestión de datos y en la mejora de la calidad, la exhaustividad y la oportunidad del registro de casos de cáncer. El Tracker DHIS2 del Registro de Cáncer no está diseñado para proporcionar soporte a la decisión clínica, sino que sirve como una herramienta operativa para la captura individual de casos y como fuente de datos para la vigilancia del cáncer y el análisis epidemiológico. Está alineado con los estándares de datos de CanReg5 para el registro individual de casos de cáncer, apoyando el monitoreo de base poblacional a nivel de registro.
Este documento de diseño del sistema explica la configuración de referencia en DHIS2 para el caso de uso del registro de cáncer, incluyendo una descripción detallada de la configuración del Tracker DHIS2 y de los mecanismos de control de calidad de datos. Este documento no aborda los recursos y la infraestructura necesarios para implementar dicho sistema (tales como servidores, energía eléctrica, conectividad a internet, respaldos, capacitación y soporte a usuarios), que se cubren en la Guía de Implementación del Tracker DHIS2.
Los metadatos de referencia de este kit de herramientas están disponibles aquí: dhis2.org/metadata-downloads.
Agradecimientos¶
El kit de herramientas DHIS2 para el Registro de Cáncer ha sido desarrollado con el apoyo financiero de Vital Strategies y la orientación técnica de la Agencia Internacional de Investigación sobre el Cáncer (IARC). Agradecemos a la IARC por proporcionar experiencia técnica en estándares de registro de cáncer y el modelo de datos CanReg5 a lo largo del diseño y desarrollo de estas herramientas. También deseamos agradecer a los Grupos HISP que participaron en las consultas y contribuyeron con su experiencia de implementación al desarrollo de este kit de herramientas.
Descripción general del diseño del sistema¶
Contexto¶
El cáncer representa una de las principales causas de morbilidad y mortalidad a nivel mundial, con la carga global cada vez más concentrada en los países de ingresos bajos y medianos (PIBM), donde los sistemas de salud a menudo están menos equipados para responder. Los datos fiables y de alta calidad sobre la incidencia del cáncer, las características de los casos y los resultados son esenciales para informar la planificación nacional de control del cáncer, asignar recursos, monitorear tendencias a lo largo del tiempo y evaluar el impacto de los programas de prevención y tratamiento. Los registros de cáncer de base poblacional son el instrumento principal para generar esta evidencia, y su fortalecimiento sistemático es una prioridad para el control global del cáncer.
El registro individual de casos de cáncer ofrece ventajas significativas sobre la notificación agregada. Un enfoque basado en casos permite la desagregación flexible por sitio tumoral, morfología, edad, sexo, origen geográfico y otras variables clínica y epidemiológicamente relevantes. También permite el seguimiento longitudinal de los casos registrados, facilita la deduplicación de registros provenientes de múltiples fuentes de notificación y permite la aplicación de controles sistemáticos de calidad de datos para identificar y corregir las entradas incompletas o inconsistentes. Estas capacidades son críticas en el contexto del registro de cáncer, donde los casos generalmente se notifican desde múltiples fuentes — hospitales, laboratorios de anatomía patológica, certificados de defunción — y deben consolidarse en un único registro verificado.
A pesar de su importancia, los registros de cáncer de base poblacional en muchos PIBM enfrentan desafíos persistentes en materia de exhaustividad, oportunidad y sostenibilidad de los datos. Las operaciones de los registros a menudo dependen de sistemas basados en papel fragmentados o herramientas de software independientes que son difíciles de mantener, se integran deficientemente con los sistemas nacionales de información sanitaria y requieren una capacidad técnica significativa para funcionar. CanReg5, desarrollado por la IARC, se ha convertido en el software estándar reconocido internacionalmente para el registro de cáncer de base poblacional y proporciona un modelo de datos bien establecido y un conjunto de procedimientos de control de calidad de datos. Sin embargo, su integración en la infraestructura nacional de salud digital más amplia — incluidos los sistemas de información sanitaria de rutina gestionados por los Ministerios de Salud — sigue siendo limitada en muchos contextos.
El Tracker DHIS2 del Registro de Cáncer está diseñado para abordar estos desafíos aprovechando la plataforma DHIS2 — ya ampliamente desplegada en los sistemas nacionales de información sanitaria de los PIBM — para apoyar el registro individual de casos de cáncer alineado con los estándares de datos de CanReg5. Al implementar el registro de cáncer dentro de DHIS2, este kit de herramientas busca facilitar la integración de los datos de vigilancia del cáncer en la infraestructura nacional de información sanitaria, reducir la duplicación de esfuerzos de gestión de datos y apoyar el control sistemático de la calidad de datos en el punto de registro.
Caso de uso¶
El kit de herramientas DHIS2 del Registro de Cáncer está diseñado para apoyar el registro individual rutinario de casos de cáncer que alimentan los registros de cáncer de base poblacional. El sistema se basa en el modelo de datos Tracker de DHIS2, alineado con los estándares de datos y los flujos de trabajo de CanReg5, el software reconocido internacionalmente para el registro de cáncer de base poblacional desarrollado por la IARC.
El componente de captura de datos basado en web del diseño del sistema permite al personal del registro registrar y gestionar casos individuales de cáncer provenientes de múltiples fuentes de notificación — incluyendo registros hospitalarios, informes de laboratorios de anatomía patológica y citología, y certificados de defunción — y consolidarlos en un único registro de registro verificado. El programa Tracker soporta la captura de los elementos de datos esenciales requeridos para el registro de cáncer de base poblacional, incluyendo los datos demográficos del paciente, las características del tumor, la base del diagnóstico y la fuente de notificación.
Una característica clave del diseño del sistema es la implementación de controles sistemáticos de calidad de datos integrados en el programa Tracker. Estos controles están diseñados para identificar las entradas incompletas, inconsistentes o inverosímiles en el momento de la captura de datos o durante las operaciones rutinarias del registro, ayudando a los registros a mantener los estándares de calidad de datos requeridos para un análisis epidemiológico válido y la comparabilidad internacional.
Aunque el Tracker DHIS2 del Registro de Cáncer no está diseñado para apoyar la gestión clínica de casos ni el soporte a la decisión, sirve como una herramienta de registro electrónico que permite el registro estructurado y estandarizado de casos de cáncer dentro de la infraestructura nacional de información sanitaria DHIS2.
Advertencia
El kit de herramientas está concebido como una configuración de referencia, completamente alineada con los estándares de CanReg5 para una transferencia simplificada de datos hacia CanReg5. Los administradores del sistema pueden necesitar localizar el programa agregando nuevos elementos de datos o atributos, pero la modificación de la configuración de referencia está fuertemente desaconsejada, ya que probablemente rompería la alineación con CanReg5 y la lógica de las reglas de programa de los controles de calidad de datos.
Usuarios previstos¶
El diseño del sistema del Registro de Cáncer DHIS2 está destinado a satisfacer las necesidades de los usuarios en todos los niveles del sistema de registro de cáncer. Estos usuarios pueden incluir:
- Responsables y personal del registro de cáncer (nacional y subnacional): usuarios de datos responsables de supervisar la exhaustividad y calidad del registro de casos de cáncer, monitorear las operaciones del registro y utilizar los datos del registro para apoyar la planificación y la notificación del control del cáncer
- Personal de captura de datos del registro: usuarios responsables de la captura y gestión diaria de los casos individuales de cáncer en el programa Tracker, incluyendo el registro de las notificaciones de casos recibidas de hospitales, laboratorios y otras fuentes de notificación, y la aplicación de los procedimientos de control de calidad de datos para garantizar la exactitud y exhaustividad de los registros
- Gestores de datos del programa de cáncer: usuarios responsables de supervisar los flujos de recolección de datos, el aseguramiento de la calidad de datos y las funciones de notificación para el programa nacional de registro de cáncer
- Administradores del sistema / Puntos focales del SIS: personal del Ministerio de Salud y/o equipo central de DHIS2 responsable del mantenimiento del sistema DHIS2, del apoyo a la adaptación local de la configuración del registro de cáncer y de la asistencia técnica a los usuarios finales
- Socios de implementación y proveedores de asistencia técnica: organizaciones que proporcionan soporte técnico a los registros nacionales de cáncer, incluyendo la IARC, los Grupos HISP y otros socios involucrados en la implementación del sistema, la capacitación y el fortalecimiento de capacidades
Tracker¶
Estructura del programa Tracker¶
La estructura del programa Tracker es la siguiente:
| Etapa | Descripción |
|---|---|
| Inscripción | La etapa de inscripción recopila los datos demográficos básicos de una persona, incluyendo los identificadores únicos, como Atributos de Entidad Rastreada (TEA). Varios de estos TEA esenciales, como el Apellido y el Nombre, son compartidos entre los programas Tracker de DHIS2. El Tipo de Entidad Rastreada para el programa del Registro de Cáncer es «Persona». |
| Tumor | Esta etapa contiene la información esencial relacionada con el tumor. La etapa es repetible |
| Fuentes | Esta etapa contiene la información esencial relacionada con las fuentes asociadas a cada tumor. La etapa es repetible |
| Seguimiento | Esta etapa contiene la información de seguimiento del paciente y no está asociada ni al tumor ni a las fuentes. La etapa es repetible |
Tipo de entidad rastreada¶
El programa Tracker del Registro de Cáncer DHIS2 permite la inscripción de un tipo de entidad rastreada (TET) «persona» en el programa de registro de cáncer. Cada persona inscrita representa un paciente con cáncer registrado en el registro de cáncer de base poblacional. El TET está configurado a nivel del sistema y puede ser compartido con otros programas Tracker DHIS2 desplegados dentro de la misma instancia nacional, conforme a las prácticas estándar de implementación de DHIS2.
Inscripción¶
La etapa de inscripción captura la información demográfica esencial del paciente requerida para inscribir a un individuo en el programa de registro de cáncer. Como buena práctica, el personal del registro debe primero buscar un registro existente antes de crear una nueva inscripción, para evitar inscripciones duplicadas del mismo paciente.
Los atributos recopilados en la inscripción representan el conjunto mínimo de datos necesario para el registro de cáncer de base poblacional y han sido mapeados a los requisitos estándar de datos de la IARC. Se recopilan cinco atributos clave de entidad rastreada en esta etapa. Estos atributos están configurados a nivel del tipo de entidad rastreada y, por lo tanto, pueden ser compartidos entre otros programas Tracker dentro de la misma instancia DHIS2. Sin embargo, se debe tener especial cuidado al compartir el atributo Sexo, ya que el conjunto de opciones asignado a este atributo utiliza códigos numéricos que se referencian en múltiples controles de calidad de datos a lo largo del programa. Cualquier modificación de estos códigos — o sustitución por un conjunto de opciones codificado de manera diferente — rompería la lógica de dichos controles. El conjunto de opciones Sexo ha sido mapeado con el diccionario CanReg5 correspondiente.
Un atributo, el Identificador del paciente, es generado automáticamente por el sistema en el momento de la inscripción. El patrón sigue la misma convención utilizada en CanReg5: el identificador tiene 8 caracteres de longitud, compuesto por el año actual en formato de cuatro dígitos seguido de un número secuencial de cuatro dígitos, en la forma CURRENT_DATE(yyyy)+SEQUENTIAL(####).
Tumor¶
La etapa Tumor es el componente central del programa Tracker del Registro de Cáncer. Captura toda la información clínica y epidemiológica clave relacionada con un caso individual de cáncer, y es donde se aplica el conjunto completo de controles de calidad de datos en el punto de registro. Para una descripción detallada de los controles de calidad, consulte la sección dedicada de este documento.
La etapa está estructurada en múltiples secciones, varias de las cuales están ocultas de la interfaz de captura de datos. Estas secciones ocultas sirven propósitos funcionales específicos dentro del diseño del sistema: soportan la lógica de cálculo subyacente a los controles de calidad, controlan el flujo de captura de datos mediante reglas de programa, alimentan las salidas analíticas del programa y permiten la extracción de datos a través de la aplicación personalizada DHIS2 del Registro de Cáncer.
| Secciones | Visibilidad | Descripción |
|---|---|---|
| Paciente | Visible | Información del paciente |
| Tumor | Visible | Información del tumor |
| Estado de los controles | Visible | Ejecución de controles múltiples |
| Controles | No visible | Información almacenada de cada control individual |
| Control morfología topografía | No visible | Control morfología topografía en múltiples pasos |
| Prueba de tumores primarios múltiples | No visible | Prueba de tumores primarios múltiples en múltiples pasos |
| Estado raro | Visible | Visible solo para los usuarios que pueden confirmar el estado raro |
| Identificador del tumor | No visible | Almacenamiento de información necesaria para la exportación a CanReg5 |
Elementos obligatorios¶
El único elemento de datos formalmente obligatorio en la etapa Tumor es el Número de tumor, que sirve como referencia vinculando cada registro de tumor con sus fuentes correspondientes y es esencial para el proceso de extracción de datos a través de la aplicación personalizada del Registro de Cáncer.
Sin embargo, en la práctica, todos los elementos de datos de las secciones paciente y tumor deben estar completados para que los controles de calidad de datos se ejecuten correctamente. La única excepción es el campo Grado, que no se requiere cuando el código de comportamiento indica un valor distinto a maligno. Este requisito se aplica mediante la regla de programa CR - Imposible ejecutar los controles si todos los elementos obligatorios no tienen valores, que impide la ejecución de los controles cuando falta alguno de los campos requeridos.
Paciente¶
La sección paciente recopila la información demográfica y geográfica asociada al caso de cáncer. El campo de fecha central en esta sección es la Fecha de incidencia, que es la fecha de referencia utilizada para todas las salidas analíticas en CanReg5. La Fecha de evento — la fecha del sistema DHIS2 registrada en el momento de la captura de datos — es un campo separado cuyo valor está determinado por las decisiones de implementación local: puede establecerse como la fecha de captura de datos, alinearse con la fecha de incidencia o reflejar otra fecha localmente relevante. La decisión de mantener la fecha de incidencia como un elemento de datos dedicado en lugar de utilizar la fecha de evento para este propósito está motivada por los requisitos de la aplicación personalizada de extracción del Registro de Cáncer, que referencia directamente el elemento de datos.
El campo Edad debe ingresarse manualmente. Se utiliza en los controles de calidad de datos, y una regla de programa verifica la consistencia entre la edad ingresada, la fecha de nacimiento y la fecha de incidencia, devolviendo una advertencia si se detecta una discrepancia. Se proporcionan más detalles en la sección de controles de calidad de este documento.
El campo Dirección utiliza un conjunto de opciones que contiene valores de marcador de posición y debe personalizarse antes de la implementación para reflejar la geografía administrativa del país o la región. En lugar de utilizar un elemento de datos de tipo Unidad organizativa para la codificación geográfica, el enfoque recomendado es utilizar elementos de datos de tipo texto combinados con listas desplegables dependientes, implementadas mediante reglas de programa utilizando la acción Mostrar grupo de opciones. Esto permite la configuración de menús de selección en cascada — por ejemplo, un primer elemento que lista las regiones administrativas, seguido de un segundo elemento que muestra solo los distritos pertenecientes a la región seleccionada. Este enfoque se alinea con la convención de CanReg5 para la codificación de direcciones, donde la variable de dirección tiene dos caracteres de longitud y típicamente codifica una combinación de dos niveles administrativos.
Tumor¶
La sección tumor es el componente principal de recopilación de datos de la etapa Tumor. Captura las variables clave que deben registrarse para cada caso de cáncer, alineadas y mapeadas a los requisitos estándar de datos de la IARC, con la adición del Número de tumor, que sirve como referencia local vinculando un registro de tumor específico con sus fuentes correspondientes.
El Número de tumor está concebido como un identificador único para el tumor dentro del registro. Puede ser un número secuencial o cualquier otro valor definido localmente, y tiene un conjunto de opciones de tipo texto con valores numéricos asignados. Combinado con el Identificador del paciente recopilado en la inscripción, el Número de tumor constituye el Identificador del tumor — el identificador compuesto que identifica de manera única un registro de tumor dentro del sistema.
Para evitar que el mismo Número de tumor sea asignado a más de un tumor perteneciente al mismo paciente, se ha implementado un mecanismo dedicado utilizando un conjunto de reglas de programa que operan sobre una sección oculta Identificador del tumor.
Un elemento de datos Número de tumor anterior, de tipo MULTI_TEXT, comparte el mismo conjunto de opciones que el elemento Número de tumor. Cuando se abre un nuevo evento de tumor, las reglas de programa inspeccionan los valores registrados en el evento de tumor anterior. Si se registró un Número de tumor en el evento anterior, ese valor se asigna al elemento Número de tumor anterior. Si tanto un Número de tumor como un Número de tumor anterior estaban presentes en el evento anterior, los dos valores se concatenan y almacenan como dos valores separados dentro del campo MULTI_TEXT. Una vez completado el Número de tumor anterior, una regla de programa adicional verifica si el valor actualmente ingresado en el campo Número de tumor del evento activo ya existe entre los valores almacenados en el Número de tumor anterior. Si se encuentra una coincidencia, se muestra un mensaje de error informando al usuario que el Número de tumor seleccionado ya ha sido asignado a este paciente y que se debe elegir un valor diferente.
Los elementos de datos restantes en la sección tumor están alineados y mapeados a los estándares de datos de CanReg5 y se utilizan como entradas para los controles de calidad de datos descritos en la sección dedicada de este documento. Con la excepción del campo topografía, todos los elementos son entradas de selección libre. El campo Topografía está implementado como una lista desplegable dependiente: los códigos de topografía disponibles se filtran según el sitio seleccionado por el usuario, de modo que solo los valores de topografía válidos para el sitio elegido se presentan para la selección.
Para simplificar la captura de datos, cada opción incluye el código correspondiente en su nombre, permitiendo al personal del registro buscar directamente por código al seleccionar un valor.
Los conjuntos de opciones están mapeados con la versión ICDO3.2 de CanReg5:
Nota
Los conjuntos de opciones utilizados en esta sección, y los códigos asociados a cada opción, están directamente mapeados a los estándares de CanReg5. Es esencial que estos códigos no se modifiquen durante la implementación local o el mantenimiento del sistema. Cualquier alteración de los códigos de opciones rompería la lógica de los controles de calidad de datos, que dependen de estos valores para sus cálculos
Estado de los controles¶
Esta sección permite al personal del registro activar la ejecución de los controles de calidad de datos. Cuando el usuario selecciona la opción Ejecutar los controles, se muestra un mensaje de advertencia para cada control que no se ha superado, permitiendo al usuario revisar y corregir las entradas correspondientes.
Como se indica en la sección de elementos obligatorios, todos los elementos de datos de las secciones paciente y tumor deben tener un valor antes de que los controles puedan ejecutarse. La única excepción es el campo Grado, que es obligatorio solo cuando el código de comportamiento es maligno (3).
Cuando se selecciona «Ejecutar los controles», la captura de datos para la sección tumor se bloquea. Si el usuario necesita modificar un valor después de ejecutar los controles, debe desmarcar el elemento para reactivar la captura de datos. Este comportamiento se aplica mediante dos reglas de programa:
- CR - Bloquear la captura de datos si los controles han sido ejecutados
- CR - Bloquear la captura de datos si los controles han sido ejecutados - Grado
Una vez seleccionado Ejecutar los controles, dos opciones de control adicionales se hacen visibles: Ejecutar el control Topografía Morfología y Ejecutar la prueba de tumores primarios múltiples. Estos se han implementado como pasos separados porque requieren verificación en múltiples pasos y la intervención de reglas de programa adicionales que no pueden ejecutarse en una sola pasada. Se proporcionan más detalles en la sección Controles de este documento. Cuando se selecciona la opción principal Ejecutar los controles, estos dos controles posteriores son obligatorios para garantizar que se ejecute el conjunto completo de controles de calidad.
Sección de controles¶
| Elementos de datos | Tipo de valor |
|---|---|
| CR - Controles: Edad Morfología rara | Booleano |
| CR - Controles: Edad Topografía rara | Booleano |
| CR - Controles: Edad Topografía Morfología rara | Booleano |
| CR - Controles: Base rara | Booleano |
| CR - Controles: Grado inválido | Booleano |
| CR - Controles: Sexo Morfología rara | Booleano |
| CR - Controles: Sexo Topografía inválida | Booleano |
| CR - Controles: Topografía Comportamiento raro | Booleano |
| CR - Controles: Topografía Morfología rara | Booleano |
| CR - Controles: Resultado de la prueba de tumores primarios múltiples | Conjunto de opciones |
| CR - Raro | Booleano |
| CR - Inválido | Booleano |
Esta sección siempre está oculta de la interfaz de captura de datos. Contiene todos los controles de calidad de datos, cada uno implementado como un elemento de datos separado. Por defecto, todos los controles reciben un valor falso mediante la regla de programa CR - Reiniciar todos los controles, que restablece cualquier control que haya devuelto previamente un resultado verdadero cada vez que el elemento Ejecutar los controles se desmarca.
El único control con un tipo de valor diferente es el Resultado de la prueba de tumores primarios múltiples, cuya salida no es un booleano sino uno de tres valores posibles: Tumor primario duplicado, Tumor primario múltiple o Topografía desconocida. La lógica completa de cada control se describe en la sección Controles de este documento.
Además de los controles individuales, esta sección contiene dos elementos de clasificación resumida: Raro e Inválido. Al igual que los demás elementos de control, ambos se restablecen a falso cada vez que el elemento Ejecutar los controles se desmarca. Sus valores verdaderos se asignan entonces cuando se ejecutan los controles: el elemento Raro se establece como verdadero si algún control con resultado raro devuelve un resultado verdadero; el elemento Inválido se establece como verdadero si algún control con resultado inválido devuelve un resultado verdadero.
Estos dos elementos sirven un doble propósito. Pueden utilizarse en las salidas analíticas para restringir los conteos a los tumores que han superado todos los controles de calidad, y pueden aplicarse como filtros en las listas de trabajo y las listas de líneas para identificar y revisar los casos marcados como raros o inválidos.
Un tumor se clasifica como Raro cuando la combinación de valores ingresados — tales como morfología, topografía, edad y otras variables — representa una combinación que rara vez puede ocurrir, y un supervisor debe confirmar que los datos ingresados son correctos. Se proporcionan más detalles en la sección Estado raro de este documento.
Un tumor se clasifica como Inválido cuando los datos ingresados describen una combinación anatómica y clínicamente imposible para un tumor (por ejemplo, un hombre con topografía ovárica).
Siguiendo la misma lógica que CanReg5, el sistema permite a los usuarios ingresar y guardar cualquier combinación de valores, incluyendo aquellas que producen un resultado inválido. Esto es intencional: los registros inválidos pueden identificarse retrospectivamente y corregirse, y pueden excluirse de las salidas analíticas. Para garantizar la integridad analítica, es esencial que las siguientes tres condiciones se apliquen siempre como filtros al generar cualquier salida analítica:
- Ejecutar los controles = verdadero
- Raro = falso O Raro = verdadero Y Confirmar el estado raro = verdadero (ver la sección Estado raro)
- Inválido = falso
Control morfología topografía¶
| Elementos de datos | Tipo de valor |
|---|---|
| CR - Familia morfológica | Conjunto de opciones |
| CR - Clave Topografía Morfología | Conjunto de opciones |
| CR - Presente en la lista DEBE | Booleano |
| CR - Presente en la lista NO-DEBE | Booleano |
Esta sección siempre está oculta de la interfaz de captura de datos. Contiene los elementos de datos utilizados en el cálculo del control Topografía Morfología rara. La lógica completa de este control se describe en la sección Controles de este documento.
Prueba de tumores primarios múltiples¶
| Elementos de datos | Tipo de valor |
|---|---|
| CR - Grupo de morfología | Conjunto de opciones |
| CR - Grupo de morfología anterior | Conjunto de opciones |
| CR - Grupo de morfología anterior (múltiple) | Conjunto de opciones - Multitexto |
| CR - Grupo de topografía | Conjunto de opciones |
| CR - Grupo de topografía anterior | Conjunto de opciones |
| CR - Grupo de topografía anterior (múltiple) | Conjunto de opciones - Multitexto |
| CR - Resultado de morfología | Conjunto de opciones |
Esta sección siempre está oculta de la interfaz de captura de datos. Contiene los elementos de datos utilizados en el cálculo de la prueba de tumores primarios múltiples. La lógica completa de este control se describe en la sección Controles de este documento.
Estado raro¶
Esta sección solo es visible cuando el tumor ha sido clasificado como raro (es decir, cuando el elemento Raro se establece como verdadero) y es accesible exclusivamente para los usuarios que tienen el rol específico autorizado para confirmar el estado raro. Permite a un supervisor designado revisar el caso marcado y confirmar que los datos ingresados son correctos a pesar de la combinación inusual de valores.
La lógica que rige la clasificación rara y el flujo de confirmación se describen en detalle en la sección Controles de este documento.
Identificador del tumor¶
| Elementos de datos | Tipo de valor |
|---|---|
| CR - Número de tumor anterior | Conjunto de opciones - Multitexto |
| CR - Identificador del paciente | Texto |
| CR - TUMOURID | Texto |
Esta sección siempre está oculta de la interfaz de captura de datos. Contiene los elementos de datos clave utilizados en la extracción de datos del registro de cáncer desde DHIS2 y su importación posterior en CanReg5 a través de la aplicación personalizada del Registro de Cáncer.
El elemento Número de tumor anterior se completa con los valores de número de tumor recopilados de los eventos de tumor anteriores del mismo paciente. Este mecanismo evita que el mismo número de tumor se asigne a más de un tumor perteneciente al mismo paciente. La lógica completa se describe en la sección Tumor de este documento.
El elemento Identificador del paciente se completa automáticamente con el Identificador del paciente recopilado durante la fase de inscripción mediante la regla de programa CR - Asignar valor al identificador de paciente del tumor - Tumor. Este valor se utiliza entonces para completar el elemento TUMOURID, que sirve como identificador único para el registro del tumor y se utiliza para vincular uno o más registros de fuente a un tumor específico durante el proceso de extracción e importación. El TUMOURID se compone concatenando el Identificador del paciente, el valor 01 y el Número de tumor, tal como lo asigna la regla de programa CR - Asignar valor al TUMOURID.
Fuente¶
La etapa Fuente se utiliza para registrar las fuentes de documentación a partir de las cuales el caso de cáncer ha sido notificado al registro. Cada fuente representa un documento — como un registro hospitalario, un informe de anatomía patológica o un certificado de defunción — que respalda el registro de un tumor específico. La etapa está compuesta por dos secciones:
| Secciones | Visibilidad | Descripción |
|---|---|---|
| Fuente | Visible | Información de la fuente |
| TUMOURIDSOURCETABLE | No visible | Almacenamiento de información necesaria para la exportación a CanReg5 |
Sección Fuente¶
Esta sección recopila la información relacionada con el registro de fuente individual. Un aspecto clave de la etapa Fuente es la capacidad de vincular cada fuente a un tumor específico perteneciente al mismo paciente inscrito. Como se describe en la sección Estructura del programa Tracker, un solo tumor puede tener múltiples fuentes de información asociadas. Para ello, el usuario debe especificar el Número de tumor al que se vincula la fuente en el momento de la captura de datos.
Si el número de tumor seleccionado en el registro de fuente no ha sido previamente asignado en ningún evento de tumor para el mismo paciente, se muestra un mensaje de error guiando al usuario a seleccionar un número de tumor existente válido. Esta validación se aplica mediante la regla de programa CR - Mostrar error si el número de tumor no ha sido asignado a ningún tumor.
El campo Tipo de fuente utiliza valores de marcador de posición en la configuración de referencia y debe personalizarse antes de la implementación para reflejar los tipos de fuente relevantes para el contexto local del registro.
TUMOURIDSOURCETABLE¶
| Elementos de datos | Tipo de valor |
|---|---|
| CR - Identificador del paciente | Texto |
| CR - TUMOURIDSOURCETABLE | Texto |
Esta sección siempre está oculta de la interfaz de captura de datos. Contiene los elementos de datos clave utilizados en la extracción de datos del registro de cáncer desde DHIS2 y su importación posterior en CanReg5 a través de la aplicación personalizada del Registro de Cáncer.
El elemento Identificador del paciente se completa automáticamente con el Identificador del paciente recopilado durante la fase de inscripción mediante la regla de programa CR - Asignar valor al identificador de paciente del tumor - Fuente. Este valor se combina con el Número de tumor seleccionado en la sección fuente para completar el elemento TUMOURIDSOURCETABLE, siguiendo la misma lógica de concatenación utilizada para el TUMOURID en la etapa Tumor — Identificador del paciente + 01 + Número de tumor — asignada por la regla de programa CR - Asignar valor al TUMOURIDSOURCETABLE.
El elemento TUMOURIDSOURCETABLE es la referencia clave utilizada durante el proceso de exportación para vincular cada registro de fuente con su tumor correspondiente, permitiendo la reconstrucción correcta de la relación tumor-fuente cuando los datos se importan en CanReg5.
Seguimiento¶
La etapa de Seguimiento se utiliza para registrar el estado de seguimiento del paciente registrado a lo largo del tiempo. Captura la fecha del último contacto con o información sobre el paciente, el estado de seguimiento y — en los casos en que el estado registrado es fallecimiento — la fecha de defunción.
Controles¶
Una de las características centrales del kit de herramientas DHIS2 del Registro de Cáncer es la implementación de los controles de calidad de datos utilizados en CanReg5 para evaluar la exhaustividad y exactitud de los casos de cáncer registrados. Estos controles representan un componente esencial de la práctica de registro de cáncer de base poblacional, garantizando que los datos recopilados cumplan con los estándares requeridos para un análisis epidemiológico válido y la comparabilidad internacional.
Como se describe en las secciones de la etapa Tumor anteriores, la implementación de estos controles en DHIS2 requiere la configuración de múltiples reglas de programa y varios elementos de datos calculados que funcionan en combinación. Las secciones siguientes describen cada control en detalle, incluyendo las variables involucradas, las condiciones evaluadas y los resultados esperados.
Los controles de CanReg5 utilizados como referencia están disponibles aquí: https://github.com/IARC-CSU/CanReg5/tree/release/R45/src/canreg/common/qualitycontrol
Consideraciones transversales¶
Varias consideraciones se aplican a la mayoría o a todos los controles descritos en esta sección y se presentan aquí para evitar repeticiones.
Tipos de valores para elementos de datos y conjuntos de opciones¶
Un aspecto clave de la correcta implementación de los controles es la configuración apropiada de los tipos de valores de los elementos de datos y los conjuntos de opciones. En CanReg5, la mayoría de los controles evalúan valores específicos contra un rango de valores numéricos, utilizando los códigos numéricos asignados a cada opción. Por lo tanto, es esencial que en DHIS2 tanto los elementos de datos como sus conjuntos de opciones asociados estén configurados con un tipo de valor Número, y que las variables de reglas de programa que referencian valores de conjuntos de opciones utilicen el código en lugar del nombre para mostrar. Los nombres de opciones pueden permanecer como texto descriptivo, pero los códigos deben ser numéricos.
Esta configuración permite traducir directamente las condiciones de rango de CanReg5 en expresiones de reglas de programa DHIS2 sin modificación. Por ejemplo, una condición de CanReg5 como morphologyNumber >= 8270 && morphologyNumber <= 8281 puede implementarse en DHIS2 utilizando la misma expresión, sin necesidad de enumerar cada valor individual dentro del rango. Esto reduce significativamente la complejidad y longitud de las expresiones de reglas de programa.
Lógica de códigos agrupados¶
Algunos controles de CanReg5 utilizan un enfoque de agrupación para optimizar la evaluación de los códigos de topografía, dividiendo el código por 10 para agrupar un rango de valores. Por ejemplo, una función puede definir topographyGroup = topographyNumber / 10 y luego evaluar topographyGroup == 53 para cubrir todos los códigos de topografía en el rango 530–539. Dado que esta operación de división no es nativamente soportada en las reglas de programa DHIS2, la lógica equivalente debe expresarse explícitamente como una condición de rango. El ejemplo anterior se traduciría en DHIS2 como topography >= 530 && topography <= 539.
Edad — Fecha de incidencia — Fecha de nacimiento¶
El objetivo de este control es verificar que la edad ingresada en la etapa Tumor sea consistente con la fecha de incidencia y la fecha de nacimiento registradas para el paciente. La edad esperada se calcula como la diferencia entre la fecha de incidencia y la fecha de nacimiento, y se activa una advertencia si la edad ingresada no coincide con el valor calculado. El mensaje de advertencia devuelve la edad esperada para guiar al personal del registro en la corrección de la entrada si es necesario.
En DHIS2, este control se implementa mediante la regla de programa CR - Verificar la edad, la fecha de incidencia y la fecha de nacimiento.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckAgeIncidenceDateBirthDate.java
Edad — Morfología¶
El objetivo de este control es identificar las combinaciones raras de edad y morfología. El control evalúa los primeros cuatro dígitos del código de morfología contra el valor de la edad y devuelve un resultado raro si se cumple alguna de las siguientes condiciones:
- Edad ≤ 25 y morfología entre: 9730, 9823, 9890
- Edad ≥ 15 y morfología entre: 8910, 8960, 8961, 8962, 8970, 8981, 8991, 9072, 9470, 9490, 9500, 9687
- Edad < 15 y morfología entre: 9724, 9732, 9823
Las variables involucradas en este control son Edad y Morfología.
En DHIS2, este control se implementa mediante la regla de programa CR - Edad Morfología rara, que asigna un valor verdadero al elemento de datos CR - Controles: Edad Morfología rara cuando el elemento Ejecutar los controles está seleccionado y se cumple alguna de las condiciones anteriores. La lógica sigue directamente la implementación de CanReg5, ya que la configuración de tipo de valor numérico descrita en la sección Consideraciones transversales permite expresar las condiciones como comparaciones de rango e igualdad equivalentes en la expresión de la regla de programa.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckAgeMorphology.java
Edad — Topografía¶
El objetivo de este control es identificar las combinaciones raras de edad y topografía. El control evalúa el código de topografía contra el valor de la edad y devuelve un resultado raro si se cumple alguna de las siguientes condiciones:
- Edad < 5 y topografía en el rango 530–539 o 610–619
- Edad < 20 y topografía en alguno de los siguientes rangos o valores: 150–159, 190–199, 200–209, 210–219, 230–239, 240–249, 384, 500–509, 530–539, 540–549, 550–559
Las variables involucradas en este control son Edad y Topografía.
Como se describe en la sección Consideraciones transversales, la implementación de CanReg5 utiliza un enfoque de agrupación donde el código de topografía se divide por 10 para crear un valor agrupado que luego se evalúa contra un conjunto de números de grupo. Dado que esta operación de división no es nativamente soportada en las reglas de programa DHIS2, cada condición de grupo se traduce en una expresión de rango explícita. Por ejemplo, la condición de CanReg5 topographyGroup == 53 se expresa en DHIS2 como topography >= 530 && topography <= 539.
En DHIS2, este control se implementa mediante la regla de programa CR - Edad Topografía rara, que asigna un valor verdadero al elemento de datos CR - Controles: Edad Topografía rara cuando el elemento Ejecutar los controles está seleccionado y se cumple alguna de las condiciones anteriores.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckAgeTopography.java
Edad — Topografía — Morfología¶
El objetivo de este control es identificar las combinaciones raras que involucran edad, topografía y morfología conjuntamente. El control evalúa las tres variables en combinación y devuelve un resultado raro si se cumple alguna de las siguientes condiciones:
- Edad < 40 y topografía en el rango 610–619 y morfología en el rango 8140–8149
- Edad < 20 y topografía en el rango 170–179 y morfología < 9590
- Edad < 20 y topografía en el rango 330–339, 340–349, o 180–189 y morfología no está en el rango 8240–8249
- Edad > 5 y morfología es 9510 o 9512 y topografía en el rango 690–699
- Edad < 15 o edad > 45 y topografía en el rango 580–589 y morfología es 9100
Las variables involucradas en este control son Edad, Topografía y Morfología. Al igual que con el control Edad — Topografía, la lógica de agrupación de CanReg5 aplicada a los códigos de topografía y morfología se traduce en DHIS2 en expresiones de rango explícitas, como se describe en la sección Consideraciones transversales.
En DHIS2, este control se implementa mediante la regla de programa CR - Edad Topografía Morfología rara, que asigna un valor verdadero al elemento de datos CR - Controles: Edad Topografía Morfología rara cuando el elemento Ejecutar los controles está seleccionado y se cumple alguna de las condiciones anteriores.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckAgeTopographyMorphology.java
Base del diagnóstico¶
El objetivo de este control es verificar que la base del diagnóstico sea consistente con la morfología y la topografía registradas para el tumor. El control clasifica los códigos de base del diagnóstico en tres categorías:
- No confirmado microscópicamente: códigos 0–4
- Confirmado microscópicamente: códigos 5–8
- Desconocido: código 9
Un conjunto de códigos de morfología — y dos condiciones específicas de topografía — se aceptan independientemente de la base del diagnóstico y siempre devuelven un resultado OK. Estos son: 8000, 8150–8154, 8170, 8270–8281, 8800, 8720 cuando la topografía está en el rango 690–699 o 440–449, 8960, 9050, 9100, 9140, 9350, 9380, 9384, 9500, 9510, 9530–9539, 9590, 9732, 9761 y 9800.
Para todos los demás códigos de morfología, si la base del diagnóstico no está confirmada microscópicamente (es decir, el código de base no está en el rango 5–8), el control devuelve un resultado Raro. Aunque la implementación original de CanReg5 devuelve un resultado «Query» para esta condición, la implementación DHIS2 trata esto como una combinación rara, consistente con el enfoque aplicado a los demás controles del kit de herramientas.
Las variables involucradas en este control son Base del diagnóstico, Morfología y Topografía.
En DHIS2, este control se implementa mediante la regla de programa CR - Base rara, que asigna un valor verdadero al elemento de datos de control correspondiente cuando el elemento Ejecutar los controles está seleccionado y se cumplen las condiciones anteriores.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckBasis.java
Grado¶
El objetivo de este control es verificar que el valor de grado ingresado sea consistente con el comportamiento y la morfología del tumor. Las variables involucradas en este control son Comportamiento, Morfología y Grado.
El control aplica la siguiente lógica:
- Casos no malignos (comportamiento ≠ 3): el campo grado debe estar vacío o codificado como 9. Si cualquier otro valor de grado está presente, el control devuelve un resultado Inválido. Casos malignos (comportamiento = 3): el campo grado es obligatorio. Si está
- vacío, el control devuelve un resultado Faltante. Si el código de grado está fuera del rango válido 1–9, el control devuelve un resultado Inválido. Cuando un código de grado válido está presente (y no es igual a 9, que se omite), las siguientes reglas de consistencia morfología-grado se evalúan, cada una devolviendo un resultado Inválido si no se cumple:
Morfología 8331, 9187 o 9511 debe tener grado = 1 (bien diferenciado)
- Morfología 8249, 8332, 9083, 9243 o 9372 debe tener grado = 2 (moderadamente
- diferenciado) Morfología 8631 o 8634 debe tener grado = 3 (poco diferenciado)
- Morfología 8020, 8021, 8805, 9062, 9082, 9392, 9401, 9451, 9505 o 9512
- debe tener grado = 4 (indiferenciado/anaplásico) Los códigos de grado 5–8 solo son válidos para linfomas y leucemias (morfología ≥
- 9590); si morfología < 9590 y grado está en el rango 5–8, el resultado es Inválido Morfología 9702, 9705, 9708, 9709, 9716, 9717, 9718, 9719, 9724, 9726,
- 9729, 9827, 9834 o 9837 (linfomas de células T) deben tener grado = 5 Morfología 9714 (linfoma de células T y células nulas, anaplásico) debe tener grado
- = 4, 5 o 7 Morfología en el rango 9700–9719 (linfomas de células T y células asesinas) deben
- tener grado = 5 u 8 Morfología 9670–9699, 9712, 9728, 9737, 9738, 9811–9818, 9823, 9833 o
- 9836 (linfomas de células B) deben tener grado = 6 Morfología 9948 (célula asesina) debe tener grado = 8
- En DHIS2, este control se implementa mediante la regla de programa CR - Verificación del Grado, que asigna un valor verdadero al elemento de datos Grado inválido cuando el elemento Ejecutar los controles está seleccionado y se cumple alguna de las condiciones anteriores.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckGrade.java
Morfología { #morphology }
El objetivo de este control es verificar que el código de morfología ingresado sea un código CIE-O-3 válido, verificando los primeros cuatro dígitos del valor de morfología contra un archivo de referencia de familias morfológicas reconocidas.¶
En DHIS2, este control no requiere una implementación dedicada mediante regla de programa. Dado que el campo morfología está configurado como un conjunto de opciones cerrado, los usuarios están restringidos a seleccionar únicamente códigos de morfología válidos de la lista predefinida. La validez del valor ingresado está por tanto garantizada por la propia interfaz de captura de datos, haciendo redundante un control programático.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckMorphology.java
Sexo — Morfología { #sex-morphology }
El objetivo de este control es identificar las combinaciones raras de sexo y morfología. El control evalúa el código de morfología contra el sexo del paciente utilizando un archivo de búsqueda que asigna cada código de morfología a una familia morfológica, y devuelve un resultado raro si se cumple alguna de las siguientes condiciones:¶
Sexo = masculino y morfología pertenece a una de las siguientes familias:
- Vulva/Vagina (22), Útero (23), Ovario (24), Órganos genitales femeninos y otros tejidos (25), o Placenta (26) Sexo = masculino y morfología = 9084 con comportamiento = 3 (maligno solo en ovario)
- Sexo = femenino y morfología pertenece a una de las siguientes familias:
- Pene (27), o Próstata/Testículo (28) Las variables involucradas en este control son Sexo, Morfología y Comportamiento.
En CanReg5, la agrupación de los códigos de morfología en familias se gestiona mediante el archivo de búsqueda MorphFam.txt. En DHIS2, esta agrupación se implementa mediante una serie de reglas de programa con el prefijo CR - Familia morfológica: [nombre de la familia morfológica], cada una asignando el valor de familia correspondiente al elemento de datos CR - Familia morfológica, ubicado en la sección oculta Control Morfología Topografía. El control sexo-morfología evalúa entonces el valor de este elemento de datos en lugar del código de morfología directamente.
En DHIS2, este control se implementa mediante la regla de programa CR - Sexo Morfología rara, que asigna un valor verdadero al elemento de datos de control correspondiente cuando el elemento Ejecutar los controles está seleccionado y se cumple alguna de las condiciones anteriores.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckSexMorphology.java
Sexo — Topografía { #sex-topography }
El objetivo de este control es identificar las combinaciones inválidas de sexo y topografía — específicamente, los casos donde un sitio topográfico anatómicamente exclusivo de un sexo se registra para un paciente del sexo opuesto. A diferencia de los controles descritos anteriormente, este control devuelve un resultado Inválido en lugar de Raro, ya que las combinaciones que identifica son anatómicamente imposibles.¶
El control devuelve un resultado Inválido si se cumple alguna de las siguientes condiciones:
Sexo = masculino y topografía en el rango 510–589 (órganos genitales femeninos)
- Sexo = femenino y topografía en el rango 600–639 (órganos genitales masculinos)
- Al igual que con el control Edad — Topografía, la lógica de agrupación de CanReg5 aplicada a los códigos de topografía se traduce en DHIS2 en expresiones de rango explícitas, como se describe en la sección Consideraciones transversales.
Las variables involucradas en este control son Sexo y Topografía.
En DHIS2, este control se implementa mediante la regla de programa CR - Sexo Topografía inválida, que asigna un valor verdadero al elemento de datos de control correspondiente cuando el elemento Ejecutar los controles está seleccionado y se cumple alguna de las condiciones anteriores.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckSexTopography.java
Topografía { #topography }
El objetivo de este control es verificar que el código de topografía ingresado sea un código CIE-O-3 válido, verificando el valor de topografía de tres dígitos contra el archivo de búsqueda de referencia O3_10T.txt utilizado en CanReg5 para la conversión CIE-O-3 a CIE-10.¶
Al igual que con el control Morfología, en DHIS2 este control no requiere una implementación dedicada mediante regla de programa. Dado que el campo topografía está configurado como un conjunto de opciones cerrado, los usuarios están restringidos a seleccionar únicamente códigos de topografía válidos de la lista predefinida. La validez del valor ingresado está por tanto garantizada por la propia interfaz de captura de datos, haciendo redundante un control programático.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckTopography.java
Topografía — Comportamiento { #topography-behaviour }
El objetivo de este control es identificar las combinaciones raras de topografía y comportamiento. Específicamente, señala los casos donde un código de comportamiento in situ (2) se registra para sitios topográficos donde los tumores in situ se consideran raros. El control devuelve un resultado Raro si se cumple la siguiente condición:¶
Comportamiento = 2 (in situ) y topografía en alguno de los siguientes rangos:
- 400–409 (huesos), 410–419 (cráneo), 420–429 (sangre, médula ósea, bazo), 470–479 (sistema nervioso periférico), 490–499 (tejidos blandos), o 700–729 (meninges, cerebro, nervios) Al igual que con los otros controles basados en topografía, la lógica de agrupación de CanReg5 se traduce en DHIS2 en expresiones de rango explícitas, como se describe en la sección Consideraciones transversales.
Las variables involucradas en este control son Topografía y Comportamiento.
En DHIS2, este control se implementa mediante la regla de programa CR - Topografía Comportamiento raro, que asigna un valor verdadero al elemento de datos de control correspondiente cuando el elemento Ejecutar los controles está seleccionado y se cumple la condición anterior.
El control de calidad de CanReg5 correspondiente está disponible aquí: CheckTopographyBehaviour.java
Topografía — Morfología { #topography-morphology }
El objetivo de este control es identificar las combinaciones raras de topografía y morfología evaluando la familia morfológica del código de morfología ingresado contra la topografía utilizando dos tablas de búsqueda de referencia: una lista DEBE, que contiene las combinaciones donde una familia morfológica específica debe estar asociada con sitios topográficos específicos, y una lista NO-DEBE, que contiene las combinaciones donde una familia morfológica específica no debe estar asociada con sitios topográficos específicos.¶
Cada código de morfología pertenece a una familia morfológica, y a cada familia se le asigna una de tres claves posibles que determina qué tabla de búsqueda aplicar y cómo interpretar el resultado:
NA (*): la familia morfológica se acepta con cualquier topografía. El
- control se supera independientemente de la topografía ingresada. Más (+): la familia morfológica tiene un conjunto restringido de sitios
- topográficos con los que se espera que ocurra. La combinación de familia y topografía se busca en la lista DEBE. Si la combinación se encuentra, el control se supera. Si no se encuentra, la combinación se considera rara. Menos (−): la familia morfológica tiene un conjunto restringido de sitios
- topográficos con los que no debe ocurrir. La combinación de familia y topografía se busca en la lista NO-DEBE. Si la combinación se encuentra, la combinación se considera rara. Si no se encuentra, el control se supera. Las variables involucradas en este control son Topografía y Morfología.
Dada la complejidad de esta lógica y la dependencia de tablas de búsqueda que no pueden ser replicadas nativamente en las reglas de programa DHIS2, la implementación requiere que varios elementos de datos intermedios calculados se completen antes de que el resultado final del control pueda ser asignado. Los siguientes elementos, ubicados en la sección oculta Control Morfología Topografía, se completan secuencialmente mediante reglas de programa dedicadas:
Familia morfológica: asignada en función del código de morfología ingresado, utilizando la serie de reglas de programa con el prefijo
- CR - Familia morfológica: [nombre de la familia morfológica], como se describe en la sección del control Sexo — Morfología. 2. Clave Topografía Morfología: derivada de la búsqueda de la familia morfológica, este elemento identifica si la clave de la familia es asterisco, más o menos. 3. Presente en la lista DEBE: cuando la clave es más, un conjunto de reglas de programa evalúa si la combinación de familia morfológica y topografía está presente en la tabla de búsqueda DEBE. Debido a la longitud de la expresión requerida para cubrir todas las combinaciones familia-topografía, esta evaluación se ha dividido en 9 reglas de programa distintas, cada una cubriendo un rango distinto de familias morfológicas. Estas reglas siguen el prefijo de nomenclatura CR - Topografía Morfología: DEBE - Familia morfológica [rango]. Si la combinación se encuentra en alguna de estas reglas, el elemento Presente en la lista DEBE recibe el valor verdadero; de lo contrario recibe el valor falso. 4. Presente en la lista NO-DEBE: cuando la clave es menos, una regla de programa evalúa si la combinación de familia morfológica y topografía está presente en la tabla de búsqueda NO-DEBE. Si la combinación se encuentra, este elemento recibe el valor verdadero; de lo contrario recibe el valor falso. El resultado final asignado al elemento de datos de control CR - Controles: Topografía Morfología rara se determina entonces de la siguiente manera: Si la clave es NA: el control se supera y se asigna falso a
CR - Controles: Topografía Morfología rara.
- Si la clave es más y Presente en la lista DEBE es verdadero: el control se supera y se asigna falso.
- Si la clave es más y Presente en la lista DEBE es falso: la combinación es rara y se asigna verdadero.
- Si la clave es menos y Presente en la lista NO-DEBE es verdadero: la combinación es rara y se asigna verdadero.
- Si la clave es menos y Presente en la lista NO-DEBE es falso: el control se supera y se asigna falso.
- Este control es uno de los más complejos del kit de herramientas debido a su dependencia de la lógica de tablas de búsqueda que debe aproximarse en DHIS2 mediante una secuencia de reglas de programa intermedias y elementos de datos calculados. Como se indica en la sección Estado de los controles, este control requiere un disparador separado — Ejecutar el control Topografía Morfología — debido a la naturaleza de múltiples pasos de su ejecución. El control de calidad de CanReg5 correspondiente está disponible aquí: CheckTopographyMorphology.java
Prueba de tumores primarios múltiples { #multiple-primary-tester }
El objetivo de este control es determinar si dos o más tumores registrados para el mismo paciente representan registros duplicados del mismo tumor o tumores primarios múltiples distintos. A diferencia de todos los demás controles, este control opera entre eventos de tumor en lugar de dentro de un solo evento, y su resultado no es un booleano sino uno de tres valores posibles: Tumor primario duplicado, Tumor primario múltiple o Topografía desconocida.
El control se basa en dos variables de agrupación intermedias — Grupo de morfología y Grupo de topografía — que se derivan de los códigos de morfología y topografía ingresados respectivamente, utilizando la lógica de mapeo definida en la clase CanReg5 DefaultMultiplePrimaryTester. Estos valores se asignan a elementos de datos dedicados mediante una serie de reglas de programa antes de la ejecución del control.¶
Para permitir la comparación entre eventos de tumor, los valores del Grupo de morfología y del Grupo de topografía de los eventos de tumor anteriores se asignan a los elementos de datos correspondientes Grupo de morfología anterior y Grupo de topografía anterior. Para evitar una marcación incorrecta de duplicados, la lógica de concatenación utilizada para el Número de tumor (descrita en la sección Tumor) no se aplica aquí: si el mismo valor de grupo de morfología o topografía ya está presente de un evento anterior, no se concatena nuevamente.
El control evalúa entonces los valores actuales y anteriores según la siguiente lógica:
Evaluación de la morfología:
Si alguno de los grupos de morfología es inválido (0), el resultado es Topografía desconocida
Si alguno de los grupos de morfología es no especificado (17), el resultado de la morfología es
- indeciso y se realiza la evaluación de la topografía
- Si ambos grupos son carcinomas y uno es carcinoma no especificado (grupo 5), el resultado de la morfología es indeciso y se realiza la evaluación de la topografía
- Si un grupo es hematopoyético/linfoide (8–13) y el otro es hematopoyético no especificado (14), el resultado es Tumor primario duplicado
- Si ambos grupos de morfología son iguales y sistémicos (grupos 7–15), el resultado es Tumor primario duplicado
- Si ambos grupos de morfología son iguales pero no sistémicos, el resultado de la morfología es indeciso y se realiza la evaluación de la topografía
- Si los dos grupos de morfología son diferentes, el resultado es Tumor primario múltiple Evaluación de la topografía (realizada solo cuando el resultado de la morfología es indeciso):
- Si ambos grupos de topografía son no especificados (80), el resultado es
Tumor primario duplicado
- Si un grupo de topografía es no especificado (80), el resultado es Topografía desconocida
- Si ambos grupos de topografía son iguales, el resultado es Tumor primario duplicado Si los dos grupos de topografía son diferentes, el resultado es Tumor primario múltiple
- Como se indica en la sección Estado de los controles, este control requiere un disparador separado — Ejecutar la prueba de tumores primarios múltiples — debido a la naturaleza de múltiples pasos de su ejecución que involucra la población secuencial de elementos de datos intermedios antes de que el resultado final pueda ser evaluado.
- La implementación correspondiente de CanReg5 está disponible aquí: DefaultMultiplePrimaryTester.java
Aplicación personalizada del Registro de Cáncer { #cancer-registry-custom-application }
Se ha desarrollado una aplicación DHIS2 personalizada para apoyar la extracción de datos del registro de cáncer desde el programa Tracker DHIS2 en un formato compatible con CanReg5. La necesidad de una aplicación de extracción dedicada surge de las diferencias estructurales entre el modelo de datos DHIS2 y el formato de datos esperado por CanReg5 para la importación. Mientras que DHIS2 almacena los datos de casos individuales en múltiples etapas de programa — inscripción, tumor y fuente — CanReg5 espera una estructura plana basada en registros donde la información del paciente, del tumor y de la fuente se consolida en un único archivo importable. La aplicación personalizada cierra esta brecha consultando los elementos de datos relevantes a través de todas las etapas, aplicando las transformaciones necesarias y produciendo un archivo de salida que CanReg5 puede ingerir directamente.
Cancer Registry Export Custom application¶
A custom DHIS2 application has been developed to support the extraction of cancer registry data from the DHIS2 tracker program in a format compatible with CanReg5. The need for a dedicated extraction application arises from the structural differences between the DHIS2 data model and the data format expected by CanReg5 for import. While DHIS2 stores individual case data across multiple program stages — enrollment, tumor, and source — CanReg5 expects a flat, record-based structure where patient, tumor, and source information are consolidated into a single importable file. The custom application bridges this gap by querying the relevant data elements across all stages, applying the necessary transformations, and producing an output file that CanReg5 can ingest directly.
Se dispone de más detalles técnicos sobre la aplicación, incluyendo instrucciones de instalación, requisitos de configuración y orientación de uso, aquí
Grupos de usuarios { #user-groups }
Grupo de usuarios
Metadatos¶
| Datos | CR - Administrador | Puede editar y visualizar |
|---|---|---|
| Sin acceso | CR - Acceso | Solo puede visualizar |
| Solo puede visualizar | CR - Captura de datos | Solo puede visualizar |
| Captura y visualización | Referencias { #references } | Bray, F., Colombet, M., Mery, L., Piñeros, M., Znaor, A., Zanetti, R. y Ferlay, J. (eds.) (2017). Cancer Incidence in Five Continents, Vol. XI. Publicación Científica de la IARC n.o 166. Lyon: Agencia Internacional de Investigación sobre el Cáncer. Disponible en: https://ci5.iarc.who.int |
DHIS2. Guía de Implementación del Tracker DHIS2. Oslo: Universidad de Oslo. Disponible en: https://docs.dhis2.org¶
DHIS2. Metadatos de referencia para el kit de herramientas DHIS2 del Registro de Cáncer. Disponible en: https://dhis2.org/metadata-downloads
Ervik, M., Cooke, A. y la Unidad de Vigilancia del Cáncer de la IARC. CanReg5: Software para Registros de Cáncer. Lyon: Agencia Internacional de Investigación sobre el Cáncer. Disponible en: http://www.iacr.com.fr/index.php?option=com_content&view=article&id=9:canreg5&catid=68&Itemid=445
Unidad de Vigilancia del Cáncer de la IARC. Repositorio de código fuente de CanReg5, versión R45. GitHub. Disponible en: https://github.com/IARC-CSU/CanReg5/tree/release/R45
Piñeros, M., Mery, L., Soerjomataram, I., Bray, F. y Steliarova-Foucher, E. (eds.) (2021). Cancer Registration: Principles and Methods. Publicaciones Científicas de la IARC n.o 160. Lyon: Agencia Internacional de Investigación sobre el Cáncer. Disponible en: https://publications.iarc.who.int/Book-And-Report-Series/Iarc-Scientific-Publications/Cancer-Registration-Principles-And-Methods-2021
IARC Cancer Surveillance Unit. CanReg5 source code repository, release R45. GitHub. Available at: https://github.com/IARC-CSU/CanReg5/tree/release/R45
Piñeros, M., Mery, L., Soerjomataram, I., Bray, F. and Steliarova-Foucher, E. (eds.) (2021). Cancer Registration: Principles and Methods. IARC Scientific Publications No. 160. Lyon: International Agency for Research on Cancer. Available at: https://publications.iarc.who.int/Book-And-Report-Series/Iarc-Scientific-Publications/Cancer-Registration-Principles-And-Methods-2021