NEFROLOGÍA. Vol. XXIV. Número 6. 2004 ARTÍCULO ESPECIAL Creación del Registro de enfermos renales de Castilla y León C. Estébanez*, M. Lara*, J. M. Rubio** y P. Martín Pérez*** *Coordinación Autonómica de Trasplantes de Castilla y León. **Servicio de Informática (Desarrollo Corporativo) de la Consejería de Sanidad de la Junta de Castilla y León. ***Servicio de Estadística de la Consejería de Sanidad de la Junta de Castilla y León. INTRODUCCIÓN La primera vez que se recogieron datos de enfermos españoles en tratamiento renal sustitutivo fue en 1975 por la Sociedad Española de Nefrología (SEN). Los datos fueron facilitados por los diferentes Servicios de Nefrología y Centros de diálisis, por tanto, la idea de estudiar los casos de enfermos renales crónicos terminales y su evoluación a través del tiempo ya surgió hace casi 30 años 1-2. La SEN, considerando que los Registros de Enfermos Renales constituyen un instrumento de trabajo con aplicaciones clínicas y administrativas importantes, se planteó la posibilidad de promover una organización interterritorial que facilitara la recopilación de información global de todos los pacientes que estuvieran en diálisis o trasplante en el territorio español. Para ello, en Mayo de 1997, convoca una reunión a la que asisten todos los Registros Autonómicos entonces funcionantes: Andaluz, Catalán, Valenciano, Canario y Vasco, y el resultado de esta reunión fue el acuerdo generalizado de intentar agrupar la información de todos los pacientes renales de España. Para lograr este objetivo se formó el Grupo de Registros de Enfermos Renales (GRER), cuyo principal objetivo sería facilitar la colaboración entre los Registros Regionales ya creados y a su vez favorecer el desarrollo de otros. La formación de GRER en 1998 y la aprobación en 1999 de la propuesta de formación de Registros Autonómicos, por parte del Consejo Interterritorial del Ministerio de Sanidad y Consumo, son hechos importantes que han contribuido al desarrollo de los Registros Autonómicos de Enfermos Renales en España3-4. En el territorio español existen diversos registros autonómicos de enfermos renales con un recorrido histórico similar aunque con peculiaridades en cuanto a intereses y objetivos. Los Registros de Andalucía y Cataluña son los más antiguos y datan de 1984. Actualmente están en funcionamiento y forman parte del GRER además de estos dos, los registros del País Vasco, Comunidad Valenciana, Ca536 narias, Asturias, Baleares, Castilla y León, Navarra y Extremadura. Desde 1992, en la Comunidad Autónoma de Castilla y León, a través de la SCAL-N (Sociedad Castellano-Astur-Leonesa de Nefrología) se venían recogiendo datos de los pacientes en tratamiento sustitutivo renal de forma globalizada. Coincidiendo con los hechos reseñados anteriormente y a través de la Coordinación Autonómica de trasplantes, la Consejería de Sanidad de la Junta de Castilla y León, creó en el año 2001, el Registro Autonómico de Enfermos Renales Crónicos (REDIT), para disponer de mecanismos de información que permitieran conocer los recursos disponibles, las necesidades de la población y lograr desarrollar una adecuada planificación y gestión sanitaria5. En este sentido la insuficiencia renal es, por sus propias características, una de las patologías más susceptibles de utilizar un registro de recogida, análisis y tratamiento de los datos de forma que permita la realización de estudios clínícos, epidemiológicos y la valoración de la calidad de la asistencia nefrológica en Castilla y León. DISEÑO DEL REGISTRO DE ENFERMOS RENALES DE CASTILLA Y LEÓN (REDIT) Los datos que proporciona un registro deben ser lo más exactos posible. Un diseño correcto evitará errores y disminuirá costes en un futuro, además de ser condición indispensable para asegurar la validez de un registro de casos como son los registros de enfermos renales6-7. En el momento del diseño del registro es clave establecer adecuadamente los objetivos a alcanzar y en función de ellos determinar las variables que serán de interés y el grado de calidad que se exigirá a la información. La historia del REDIT comienza en el año 2000. Los Servicios de Nefrología ya habían propuesto la idea de recoger y almacenar datos relativos a los pacientes con enfermedad renal crónica de la Comunidad de Castilla y León, y desde el año 1992 ve- REGISTRO RENAL CASTILLA-LEÓN nían recogiendo datos de los enfermos renales de forma globalizada, es decir, no existían datos individualizados ni evolutivos de los pacientes, y tampoco existían mecanismos para comprobar la veracidad y exhaustividad de la información suministrada, y fue en el año 2000, a instancias de la Coordinación Autonómica de Trasplantes (CAT), cuando se decide la creación de un Registro con datos individualizados, para mejorar la información sobre esta patología, En febrero del año 2000 se organizó la primera Reunión del REDIT, convocada por la CAT, a la que acudieron cuatro representantes de los Servicios de Nefrología de la Comunidad y un representante del Servicio de Estadística de la Consejería de Sanidad y Bienestar Social de la Junta de Castilla y León. Aquí se estableció la importancia de conocer las necesidades de Diálisis de la Comunidad de Castilla y León, en base al conocimiento epidemiológico de los pacientes subsidiarios de este tipo de tratamiento a través de la elaboración de un registro y se establecieron las variables que serían recogidas de cada paciente, de forma que el registro fuera lo más compatible posible con los registros ya existentes8. Se definieron los objetivos del registro: 1. Crear una base de datos con todos los pacientes con Insuficiencia renal crónica terminal residentes en Castilla y León. 2. Determinar las características demográficas de la población afectada. 3. Proporcionar los datos epidemiológicos y asistenciales precisos para una planificación eficaz de la atención de la insuficiencia renal crónica. 4. Obtención de indicadores estadísticos de interés para el estudio de los pacientes con esta patología renal. 5. Evaluar y elaborar propuestas sobre la eficacia de la red asistencial en relación con la Insuficiencia renal crónica, en sus aspectos sanitario, económico y de gestión. 6. Servir de base para elaborar estudios clínicos y epidemiológicos, incluidos los relativos al trasplante renal. 7. Gestión de la lista de espera de trasplante renal. 8. Realización de publicaciones periódicas y trabajos de investigación. 9. Coordinarse con otros registros de índole similar ubicados fuera del ámbito territorial de Castilla y León. 10. Otras actividades, relacionadas con los sistemas de análisis de la información de los enfermos renales, que fueran determinadas por indicación de los especialistas en Nefrología y/o por la Administración sanitaria. A través de la experiencia de los registros autonómicos ya existentes y de criterios propios se establecieron las características que debía de reunir nuestro registro, éste debía de ser: Factible, se recogerían todos los datos y en todos los casos, Ampliable, se podría realizar una ampliación de las variables recogidas para poder realizar estudios a lo largo del tiempo, Transportable, tanto los datos como los resultados de salida generados en el registro serán exportables a otras aplicaciones informáticas para ser estudiados, almacenados o analizados estadísticamente, Público, el acceso a los datos globales se podría llevar a cabo desde cualquier Hospital o Centro de diálisis, alcance regional se registrarán todos los pacientes que tengan su residencia en la comunidad de Castilla y León. De esa primera reunión surgió la definición de caso o entidad registrable y se esbozaron las variables de interés para los nefrólogos y para la Administración. La definición de caso tiene una gran influencia sobre la calidad de la información, una definición incorrecta de caso o su inexistencia, conllevará múltiples problemas pudiendo llegar a cuestionar la validez misma del registro. Es necesario considerar aspectos relativos a la persona, al lugar, al tiempo, al método diagnóstico y a la epidemiología de la enfermedad9 , 1 0 . El REDIT incluye, como casos, a los pacientes con Insuficiencia Renal Crónica Terminal en diálisis o con injerto renal funcionante, con residencia en la Comunidad de Castilla y León y cuyo tratamiento y/o seguimiento se realiza en esta Comunidad o fuera de ella. La definición de variables requiere la utilización de criterios de estandarización, siendo recomendable normalizar la información de acuerdo con pautas homologadas internacionalmente y utilizar clasificaciones de enfermedades renales primarias, como las de la EDTA (European Dialysis and Transplant Association) o las clasificaciones de causas de fallecimiento, como la CIE-9 (Clasificación Internacional de Enfermedades), compatibles con las utilizadas por otros registros. La información recogida en nuestro registro a través de las variables, se basa en el intento de recoger información de calidad más que cantidad, ya que está publicada la experiencia del fracaso de muchos registros por el intento de recoger demasiados datos de cada caso. Las variables recogidas en nuestro registro son las siguientes: 1. Datos de identificación: Nombre y apellidos, DNI, teléfono, Número de registro: Cada paciente tendrá asociado un número que servirá para identificarlo. Este número lo asigna la aplicación informática de forma automática. El CIP: Código Identi537 C. ESTÉBANEZ y cols. ficativo del paciente, reúne las siguientes características: es unívoco, impide la posibilidad de que existan duplicados y es fácil de obtener. Corresponde al número de la Tarjeta sanitaria del paciente; es un número no secuencial, su ventaja es que es un número «sanitario» y que está incluido en la banda magnética de la tarjeta sanitaria, con lo que puede ser fácilmente capturado por los lectores de bandas magnéticas. Es nuestro código de seguridad para evitar duplicidades, condición indispensable para que un registro sea eficaz. Fecha de nacimiento: Es preferible recoger la fecha de nacimiento en vez de la edad, ya que permite actualizaciones automáticas y aproximaciones para el cálculo de supervivencia. Lugar de residencia y sexo: Son datos útiles para realizar comparaciones estadísticas en los cálculos. 2. Datos propios del registro: Centro de referencia, motivo de notificación: casos nuevos, traslados, modificaciones de datos y nuevas reentradas en diálisis. Motivo de salida del registro y fecha de salida, 3. Datos de la enfermedad renal primaria: Enfermedad renal primaria, codificada según EDTA, fecha del diagnóstico, Centro de diálisis, fecha de inicio en diálisis, tipo de tratamiento y fecha de cambio de tratamiento. 4. Datos de la lista de espera: Datos de los incluidos en la lista de espera: Fecha de entrada en la lista, centro de trasplante, fecha de trasplante, trasplantes previos, causa de fracaso de/ injerto y tratamiento postrasplante. Datos de los excluidos de la lista de espera: Causa de la exclusión. 5. Datos de inmunología: Tipaje, anticuerpos, urgencia, grupo sanguíneo y serología vírus hepatitis 8, C y VIH. Algunos datos solicitados en otros registros no se incluyeron de principio para facilitar la recogida, aunque no se excluyó la posibilidad de incluirlos en etapas posteriores cuando el registro ya se encontrara en funcionamiento. Una vez definidas las variables se establecieron los Indicadores que se iban a utilizar para su cuantificación: incidencia, prevalencia, análisis de supervivencia, tasas de morbilidad y mortalidad, tasa de trasplantes y tiempo de espera en lista. Cada uno de estos indicadores se presenta de forma global, por sexo, por grupos de edad, enfermedad renal primaria y tipo de tratamiento. La segunda Reunión tuvo lugar en abril, incorporándose al grupo una Analista programadora del Servicio Informático de la Consejería de Sanidad y Bienestar Social. En esta reunión se diseñó el formato de recogida de datos en soporte papel y autocopiable, El diseño debía de cumplir las siguientes condiciones: claridad, concisión y comodidad. Mejor 538 preguntas con respuesta cerrada que abierta, mejor respuesta única que respuesta múltiple, prever todas las opciones de respuesta posibles (considerar siempre la opción «otros»), incluir las definiciones en el propio formato y dejar siempre una copia para quien recoge los datos9-11. Es importante validar el formato antes de su utilización para detectar errores e inconsistencias así como dificultades de interpretación, además es muy útil la elaboración de un manual de procedimientos. Se elaboraron las normas de funcionamiento del registro: los datos serían enviados al registro con una periodicidad de 3-4 meses. Se realizarían estudios de interés para la Comunidad (Propuesta y aprobación previa por la comisión del registro) y se emitirían informes: EDTA, etc., y habría una Representación del REDIT en las Reuniones Regionales y Nacionales. La Consejería se ocuparía de la realización de las hojas de recogida de datos y de recabar los datos relativos al código de identificación del paciente (CIP). Para llevar a cabo todo este proyecto era necesario la creación de una aplicación informática, a través del Servicio de Informática de la Consejería de Sanidad y Bienestar social. Los principales objetivos de esta aplicación informática serían la facilidad de uso y agilidad de operación, Inicialmente la viabilidad del proyecto se vio comprometida debido a la infraestructura telemática que existía en la Junta de Castilla y León. En consecuencia, durante el período previo a la realización de las Trasferencias Sanitarias, se optó por desarrollar una base de datos centralizada en la Consejería de Sanidad y que fuera mantenida por la CAT, la cual se encargaría de solicitar, recibir los formularios de diálisis y trasplantes, y posteriormente proceder a su registro informático. Teniendo en cuenta los objetivos planteados y la falta de integración con otros sistemas de información, se propuso realizar el desarrollo completo en Microsoft Access 2000. Aplicación Access: Esta aplicación se compone de dos bases de datos en Access 2000: · RediDAT.mdb contiene las tablas en las que se registran los datos personales de los pacientes, los datos de la entrada en el registro y los diferentes tratamientos a los que se someten. También se almacenan datos auxiliares, como son causas de fallecimiento, tipos de tratamientos, motivos de salida del registro, etc. · RediPRG.mdb está formada por todos los objetos necesarios para explotar los datos anteriores, consultas, formularios, informes, módulos y tablas vinculadas a las existentes en la BD RediDAT.mdb. REGISTRO RENAL CASTILLA-LEÓN Para acceder a la aplicación se debe tener un acceso directo sobre el fichero RediPRG.mde, que es la versión compilada de la BD RediPRG.mdb. La creación de un fichero de datos informatizado requiere, según la legislación vigente, la declaración del mismo a la Agencia de Protección de datos y establecimiento de un plan de seguridad para preservar la confidencialidad de los datos9, 12, 13. Según lo recogido en el Decreto 994/1999, de 11 de Junio sobre el Reglamento de Medidas de Seguridad de los Ficheros Automatizados que contengan Datos de Carácter Personal, y la Ley Orgánica 15/1999, de 13 de Diciembre sobre la Protección de Datos de Carácter Personal, se establece que la información personal referente a datos de salud integre medidas de seguridad de nivel alto. Por todo ello, se desarrolló la BID de datos Access «Codificada», con identificación, autenticación de usuarios y control de acceso a los datos, generando un informe de seguridad RediDat.snp. Se fuerza la identificación y autenticación de los usuarios y se implementa una política de control de acceso a datos, de forma que un usuario sólo disponga en un momento dado, de aquellos recursos para los que este autorizado. Listados y Estadísticas: Para explotar los datos que contiene el registro, se han desarrollado una serie de listados de pacientes y estadísticas. Los diferentes listados de los que dispone la aplicación se dividen en: Listados para Hospitales de Referencia y Centros de Diálisis y listados para Centros de Trasplante. En junio de ese año se reunieron la CAT y los Servicios de Informática y Estadística para chequear la aplicación informática del REDIT. Se diseña el método de recogida de los datos: habitualmente los registros reciben datos de manera pasiva, es decir el personal del centro donde se atiende al enfermo envía los datos al registro; sólo en circunstancias especiales los datos son recogidos de manera activa, es decir por personal vinculado al registro y formado para ello. En el primer caso se reducen los costes pero es más difícil mantener la calidad. En nuestro registro se establece que los datos se deberán enviar en los primeros 3 meses del año y los nefrólogos representantes del registro quedan encargados de recoger los primeros datos de los distintos centros y remitirlos a la Consejería. Se elabora una sectorización de los Hospitales para la recogida de la información. Se establecieron además los usos autorizados y accesos permitidos al REDIT. La introducción de los datos en el registro se haría desde la Consejería, por un administrativo grabador de datos, Finalmente, por Orden de 30 de marzo de 2001 de la Consejería de Sanidad y Bienestar Social, se crea el Registro de enfermos Renales de Castilla y León5. Una vez creado el Registro y la aplicación informática (REDIT), se comenzó con la fase de Recogida de datos, y para ello, desde la Consejería de Sanidad y Bienestar Social, se solicitaron los datos personales de los pacientes, entre ellos el CIP, a los Gerentes de los Hospitales del INSALUD, organismo por aquel entonces independiente de la Junta de Castilla y León, motivo por el cual estuvo dificultada la obtención de dichos datos. Los nefrólogos pertenecientes a la Comisión del Registro empezaron a recoger y enviar los datos clínicos de los pacientes correspondientes a los Hospitales que se les habían asignado por sectorización, y aquí empezaron a surgir los primeros problemas: pacientes con datos incompletos, fallos en la introducción del número CIP y al principio una importante falta de respuesta de algunos hospitales. El siguiente paso fue la Introducción de los datos, en la Consejería de Sanidad. Era importante establecer un sistema de control de calidad, porque la pérdida de la calidad de los datos se produce fundamentalmente por dos motivos: falta de recogida de datos o recogida incorrecta o incompleta de los mismos. En el primer caso se producen valores perdidos, lo que conlleva una pérdida de exhaustividad, y en el segundo caso la recogida incorrecta del dato puede ser por errores de trascripción, de codificación, de grabación, etc. Ambos problemas ya habían surgido con anterioridad, por eso, aunque en un principio se decidió que la recogida de datos se hiciera de manera pasiva y se mandaran los datos desde los Centros al registro, dado que muchos centros no enviaron los cuestionarios, la situación del Registro no resultó operativa y la información de la base de datos no fue útil como registro poblacional de los pacientes en tratamiento sustitutivo renal en la Comunidad de Castilla y León, lo que obligó a considerar desde la Administración y concretamente desde la CAT la contratación de una persona formada, especialista en Nefrología, que recogiera los datos de una manera activa, desplazándose a los hospitales y centros que no habían enviado la información previamente, solucionando el principal problema que era la pérdida de exhaustividad. Está demostrado que la mejor medida a este respecto es un adecuado funcionamiento del registro y la implantación de ciertas medidas de tipo organizativo, como la obligatoriedad administrativa de notificación (en nuestra Comunidad de momento no existe esta obligatoriedad). Otra medida para incrementar la exhaustividad es la consulta o contraste de los pacientes declarados por un centro con los existentes en la base de datos del registro. Para ello se realizó el envío sis539 C. ESTÉBANEZ y cols. temático de las listas de pacientes declarados al REDIT a sus notificadores para su comprobación9 , 1 4 , 1 5 . En el segundo año de funcionamiento del registro y gracias al feed-back de información entre los nefrólogos y la CAT, la respuesta tanto de Centros como de Hospitales fue buena y se lograron recoger todos los datos de forma pasiva. El Servicio de Informática ha establecido mecanismos de control de calidad en la base de datos, capaces de detectar la existencia de valores manifiestamente erróneos; el problema es la detección de valores erróneos pero que pueden ser posibles. Hay criterios de depuración o validación incorporados a la aplicación informática y mecanismos de control de duplicados a través de un código identificador único e inmutable: CIP. Durante el primer año de funcionamiento hubo que eliminar la obligatoriedad de cumplimiento de algunos datos ya que los notificadores no los rellenaban y necesitábamos comenzar a introducir las fichas de los pacientes en la base de datos para que el REDIT empezara a funcionar. Así, en un principio se permitió enviar las fichas de los pacientes sin notificar el CIP y debido a problemas de tipo administrativo con el INSALUD, la CAT tuvo dificultades para conseguir los CIP; ésta fue la causa de que algunos pacientes se grabaran en la base de datos sin CIP. Tras realizarse las trasferencias sanitarias en nuestra CCAA, este problema se solucionó gracias a la obtención de un acceso directo a la base de datos del CIP desde la CAT, pero los pacientes que fueron grabados sin este código crearon muchos problemas posteriores, ya que dieron lugar a un porcentaje de pacientes repetidos y para poder detectar estas duplicidades, hubo que realizar una búsqueda manual de posibles variantes fonéticas, acentos y cambios en algunas letras. Tras dos años de funcionamiento el REDIT fue admitido en el GRER durante el Congreso de la SEN celebrado en Bilbao en Octubre del año 2002. Las condiciones de incorporación a este grupo fueron las siguientes: el registro solicitante debía gestionar información individualizada y evolutiva de los pacientes en diálisis y trasplante y acreditar su funcionamiento durante los dos últimos años, el ámbito territorial del Registro solicitante debía incluir todos los centros de diálisis y trasplante de al menos una comunidad española y por último era necesaria la aprobación de la solicitud por el GRER. Para mantener la motivación de los profesionales y mejorar la calidad de los datos, son importantes los mecanismos de retorno de la información, que deben de establecerse de tal forma que los resultados se distribuyan a todos los usuarios, especialmente, a los que proporcionan los datos. El periodo 540 de retorno de los datos puede ser variable pero en cualquier caso nunca debe ser superior al año. La forma más común y la que se decidió utilizar en nuestro registro es la publicación de informes anuales9, 16, 17, decidiéndose que la primera vez saldrían publicados de forma casi simultánea los informes estadísticos correspondientes a los años 2001 y 2002. Para la elaboración del informe anual había que realizar un procesamiento y análisis de los datos existentes y de ello se ocupó el Servicio de Estadística de la Consejería de Sanidad en Coordinación con el Servicio de Informática, lo que llevó bastante más tiempo del que se había previsto, debido a la existencia de datos erróneos, repetidos o inexistentes; esto obligó a «limpiar la base de datos manualmente y recopilar información importante que no estaba registrada. Posteriormente se estableció un plan de análisis de la información, de lo cual se encargaron fundamentalmente el Servicio de Estadística y la CAT, quedando prevista la publicación de estos dos primeros informes estadísticos para principios del año 2004. Cuando el Servicio de Estadística tuvo que comenzar la explotación de la base de datos del REDIT también se encontró con algunos problemas. En primer lugar, la estructura de la base de datos que proporciona REDIT causa problemas a la hora de la explotación estadística. Esta base está formada por dos tablas. Una de ellas contiene información de los pacientes, con datos sociodemográficos, de diagnóstico, de causa de muerte..., y por tanto existe un paciente por registro. La segunda base guarda los datos relativos a los tratamientos como: fecha de inicio, datos relativos a la lista de espera según el tratamiento, trasplantes..., de forma que existe un tratamiento por registro. Por tanto, a la hora de realizar el análisis estadístico conjunto de ambas tablas, se complica la explotación cuando tratamos de estudiar la información de los tratamientos por paciente. Una segunda dificultad en el estudio de los datos de este registro, es la necesidad de separar la información en múltiples tablas: prevalencia, incidencia, tratamientos, salidas del registro..., para proceder a su explotación individualizada. Esta división, lógicamente, incrementa el trabajo debido a la necesidad de repetir análisis pero el principal problema es la dificultad para crear las tablas individuales a partir de la base de datos original. Concretamente la base más difícil de preparar es la de prevalencia, ya que hay que fijar los datos a una fecha exacta, a 31 de diciembre, lo que implica deshacer cambios que ya tenemos registrados en la base, como muertes, salidas, nuevos tratamientos..., etc., eliminar los casos que se han perdido antes de fin de año, incluir casos que entran durante el año REGISTRO RENAL CASTILLA-LEÓN y permanecen a día 31 de diciembre... Hay que tener en cuenta que esta depuración se hace además más compleja por el problema que comentábamos anteriormente de multiplicidad de los tratamientos por paciente. Por último indicar que, debido a que es la primera explotación estadística del Registro, ha habido numerosos errores de codificación y muchos de ellos se fueron descubriendo según se iba realizando la explotación. Esto ha ido retrasando considerablemente todo el análisis, ya que cada cambio implica rehacer la separación de bases de datos y comenzar el análisis estadístico de nuevo. Por tanto destacar que el principal tipo de problemas con los que se ha encontrado el Servicio de Estadística a la hora de analizar los datos del registro, han sido de depuración y limpieza de la base. Es muy importante el conocimiento de la base, la experiencia de casos anteriores y la introducción en todos los casos del CIP, para evitar estos problemas de duplicidades, por eso en los próximos años suponemos que los problemas de limpieza desaparecerán y la depuración se llevara a cabo de una forma eficaz y rápida. Aplicación Web: Una vez que la infraestructura telemática de la Junta de Castilla y León ha mejorado, y el REDIT ha comenzado a funcionar de forma correcta, se ha decidido realizar una aplicación Web para proporcionar una forma sencilla, flexible y eficaz de gestionar el REDIT a través de Internet. El desarrollo ha partido de la visión que se tenía del registro con la aplicación Access, añadiendo nuevas funcionalidades y registrando nuevos datos que se han demostrado que eran necesarios para disponer de un registro mas completo. Las características de esta nueva aplicación se explican con profundidad en los siguientes apartados. Requisitos: En primer lugar se debe acceder al sitio Web en el que se ubica el REDIT, para ello se arranca el navegador Web, en concreto Internet Explorer 5.0 o superior o Netscape y se accede al portal de la aplicación REDIT, escribiendo la ruta correspondiente. La aplicación web del REDIT está desplegada en un servidor de aplicaciones Oracle, cuyo acceso está restringido al personal conectado a la red de la Junta de Castilla y León. Los Hospitales que deben acceder al Registro pertenecen al Sacyl y por tanto están en su red. Para permitir su acceso a la URL de¡ REDIT, se ha abierto un firewall para las determinadas IP desde donde se va a acceder al registro en cada uno de estos Hospitales. Una vez que los requisitos anteriores son cumplidos, se necesita una cuenta de usuario (nombre de usuario y su clave (password» para poder acceder a las diferentes operaciones que proporciona el Registro. Esta cuenta de usuario deberá ser proporcionada por el personal que administra la seguridad de las aplicaciones J2EE dentro de la Junta de Castilla y León. El número de operaciones que se pueden utilizar depende de los permisos con que cuente el usuario que se conecte, variando en función del grupo (rol) al que pertenece. Tecnología: Como todas las aplicaciones J2EE que se están desarrollando en la Junta de Castilla y León, la capa de acceso interactivo de esta aplicación se ha desarrollado siguiendo el patrón de diseño MVC (Modelo/Vista/Controlador) Modelo 2, estableciéndose como estándar Struts, como implementación de dicho patrón de diseño. La capa de persistencia se implementa adoptando el patrón de diseño Data Access Object y para el intercambio entre capas de la arquitectura se ha utilizado el patrón Value Object. El patrón Value Listiterator se ha adoptado para el acceso y la navegación entre las consultas con un número elevado de registros, de forma que se puede realizar una paginación para ver todos los resultados de una consulta de una forma más clara. Para realizar los desarrollados de las diferentes capas que componen la aplicación se ha optado por utilizar un entorno de trabajo que soporta generación de aplicaciones J2EE, como es la herramienta de Oracle Jdeveloper 9i (9.0.3.1). Una vez desarrollada la aplicación, ésta debe ser desplegada en un servidor de aplicaciones para que pueda ser accedida por los usuarios. En este caso se ha elegido como servidor de este tipo de aplicaciones «Oracle Application Server 9i». Análisis: El servicio de Informática ha realizado un estudio de los requisitos que la CAT necesitaba plasmar en la aplicación. Una vez realizado dicho estudio, se pasó a definir los diferentes esquemas de clases, diagramas de secuencia, esquema de datos, etc., para posteriormente comenzar con el desarrollo de la aplicación, que conlleva el desarrollo de la base de datos y la aplicación que explote dichos datos. Para realizar las tareas de análisis, en las que se definen y realizan los diferentes diagramas y esquemas, se optó en la Junta de Castilla y León por utilizar una herramienta denominada EA (Enterprise Architect) 3.10 de Sparx Systems. Listados y Estadísticas: Los diferentes listados son los mismos que existían en la aplicación Access pero se dividen en función del usuario conectado. Las estadísticas por su parte se dividen en «estadísticas por hospital de referencia» o «generales» pudiendo ser estas últimas vistas sin poseer una cuenta de usuario para acceder a la aplicación, utilizando la zona pública de la misma. Cada vez que se solicita uno 541 C. ESTÉBANEZ y cols. de estos reports, desde la aplicación se realiza una llamada al servidor de reports, siendo mostrados en formato PDF. Para el desarrollo de los listados y las estadísticas se ha utilizado una herramienta de Oracle denominada «Reports Builder 9i» (9.0.2.0.3). Seguridad: Como aplicación J2EE perteneciente a la Junta de Castilla y León cumple una serie de requisitos en cuanto a Seguridad de Acceso se refiere. El manejo de datos de alto nivel de seguridad, obliga a la utilización de sistemas que protegen la integridad de los mismos. Para conseguir esta protección, se ha optado por la utilización de un protocolo HTTP seguro, que proporciona una encriptación de los datos que se manejan entre los puntos de acceso al registro y el servidor que mantiene dichos datos. De esta forma se consigue un canal de comunicación seguro, para que los datos con los que se trabaja no puedan ser accedidos ni modificados por personas ajenas a la aplicación. Este sistema de Seguridad controla tanto el acceso a la aplicación, como a las diferentes opciones que ofrece. Autenticación: Como se ha mencionado anteriormente el acceso a la aplicación está controlado y restringido únicamente para aquellas personas que posean una cuenta de usuario. La aplicación internamente conecta con un módulo, denominado Autenticación, el cual realiza la validación de la cuenta de usuario introducida, permitiendo o no el acceso a la aplicación. Además proporciona al usuario la posibilidad de modificar la clave de su cuenta, una vez haya sido validada. Este modulo es un componente Java, en concreto un EJ13 (Enterprise Java Bean), que corre en una instancia de un servidor de aplicaciones (9iAS). Autorización: Otro módulo del Sistema de Seguridad que utiliza la aplicación del Registro de Diálisis es el denominado «Autorización». Como se ha mencionado anteriormente, según los privilegios con los que cuente el usuario conectado, este podrá acceder a un número determinado de operaciones que proporciona la aplicación. El que controla las opciones que se deben presentar a un usuario determinado es el módulo de Autorización, el cual genera de forma dinámica el menú superior de la aplicación con todas las opciones permitidas para el usuario actual y las opciones de pantalla (enlaces, botones, etc.) a las que el usuario puede acceder. Para tener un control más exhaustivo de los accesos a cada una de las operaciones de la aplicación, se comprueba en todo momento que la operación solicitada por el usuario se encuentra en el conjunto de funciones permitidas para el mismo, no pudiendo acceder a otras. De la misma forma que el módulo definido anteriormente, este módulo es otro componente Java (EJB), que corre en una instancia de un servidor de aplicaciones. 542 Auditorías: Por ser una aplicación que trabaja con datos personales referentes a la salud, la LOPID (Ley de Protección de Datos) obliga a mantener una serie de auditorías, de forma que en todo momento se tenga constancia de quién maneja esos datos y qué operaciones se realizan sobre ellos. Incorpora un módulo de Auditorías, el cual almacena (registra) todos los accesos que se realizan sobre la Base de Datos, a través de la aplicación. Estos accesos pueden ser: inserción de nuevos pacientes, modificación, borrado y visualización de los datos que contiene el registro de diálisis y trasplantes. Únicamente se registran las operaciones que manejan datos de nivel 3 de seguridad, como son los referentes a la salud de los pacientes. Los listados solicitados son auditados, puesto que en ellos se muestran datos personales, mientras que en el caso de las estadísticas no se audita, ya que lo único que presentan son cifras de pacientes, en ningún caso datos particulares. Datos registrados: Todos los datos que se introducen en el registro son almacenados en tablas de una Base de Datos. La versión de la misma es Oracle 8i (8.1.7). Esta aplicación web entrará en funcionamiento durante el año 2004. Los principales problemas que nos hemos encontrado al poner en funcionamiento la aplicación web, han sido derivados del volcado de la base de datos en Acces a la base de datos en Oracle; en esta nueva base de datos es imprescindible la introducción del código identificador CIP del paciente para comenzar a rellenar el resto de los datos, por eso todos los pacientes existentes en la antigua base de datos que no poseían el CIP no podían ser incluidos en esta base. Este problema principalmente lo encontramos en los listados de pacientes trasplantados que se habían solicitado a los Hospitales y de los que únicamente disponíamos de datos básicos como nombre, apellidos, fecha de nacimiento, fecha de trasplante y Hospital de trasplante. De todos estos pacientes hubo que buscar el resto de datos identificativos y el CIP en la base de datos correspondiente, y de éstos un pequeño porcentaje no lo pudimos localizar y hubo que asignar un número identificativo seriado que habrá que corregir posteriormente cuando consigamos los datos a través de los Hospitales. Otro problema que encontramos, a pesar del limpiado previo de la base de datos, es que aún nos encontramos con varios pacientes repetidos que no habíamos localizado anteriormente y algunos datos erróneos como fechas de diagnóstico o fechas de tratamiento. Por otro lado al haber perfeccionado la nueva base de datos introduciendo algunos campos nuevos y algunas modificaciones, hubo que ajustar estos campos para REGISTRO RENAL CASTILLA-LEÓN poder hacer el volcado; y aún así, algunos campos no se pudieron ajustar, como por ejemplo la inmunología, que ha cambiado totalmente el formato y precisará volver a introducir los datos en su totalidad. Actualmente poseemos un registro que funciona correctamente y en el cual están registrados la totalidad de los pacientes que reciben tratamiento sustitutivo renal en la Comunidad de Castilla y León. Para mantenerlo en funcionamiento se ha optado por gestionarlo de forma interna, de tal forma que trabajan en él 4 personas pertenecientes a la Consejería de Sanidad: 1 administrativo grabador de datos, 1 informático, 1 estadístico y 1 técnico de la coordinación de trasplantes. Resumiendo, podemos decir que en los inicios de la creación del registro la calidad de los datos recogidos era bastante deficiente, ya que sólo se recogían algunos datos de los pacientes y además había muchos pacientes que no eran notificados al registro, por lo cual la pérdida de exhaustividad en la recogida de datos era importante. Actualmente, y gracias a la colaboración de los nefrólogos, creemos que hemos logrado detectar todos los casos y el grado de calidad de los datos es muy aceptable. Uno de los temas que nos preocupaba en un principio era la elección del formato de recogida de datos, apoyándonos en la experiencia de otros registros y en criterios propios, decidimos elegir el formato papel, que es el formato más extendido actualmente, aunque creemos que el formato electrónico será el que se vaya imponiendo en un futuro próximo. En la definición de las variables utilizamos clasificaciones de enfermedades renales primarias como son las de la EDTA y de causas de fallecimiento como la CIE9, que son clasificaciones que tienen una gran difusión de uso; de esta manera se intentó que nuestro registro fuera lo más compatible posible con el resto de los registros autonómicos, lo que nos ha permitido el envío de datos anuales al GRER. Una vez que el registro comenzó a funcionar y pudimos realizar una explotación estadística de los datos, establecimos mecanismos de retorno de información de tal manera que los resultados obtenidos se difundieron inicialmente en las reuniones de la SCAL-N a todos los profesionales relacionados con el tema y posteriormente hemos elaborado los informes estadísticos de los años 2001 y 2002, que serán enviados en el primer semestre de este año. Esta difusión de resultados nos parece importante porque la información obtenida puede ser de utilidad en la práctica clínica y además este feed-back contribuye a la mejora del retorno de los datos. Otro paso importante en la creación de nuestro Registro fue el desarrollo de la base de datos, que en principio se hizo en Access 2000 y en este tipo de base se grabaron los datos de los pacientes durante los primeros años de funcionamiento del registro. Posteriormente, según fue mejorando la infraestructura telemática de la Junta de Castilla y León, nos planteamos la realización de una aplicación web, de forma que se pudiera acceder a los datos a través de Internet. El principal problema para desarrollar este proyecto era lograr el cumplimiento de todas las medidas de seguridad establecidas según la Legislación vigente para preservar la confidencialidad de los datos, ya que el manejo de datos relacionados con la salud pertenece a los ficheros que deben de cumplir medidas de seguridad de nivel alto; esto obliga a encriptar los datos para evitar el acceso y la modificación de éstos por personas ajenas a la aplicación. Una vez subsanado este problema, las ventajas de un Registro-web son evidentes, permite un acceso simultáneo de todos los usuarios que se conectan al registro, acceden a una única base de datos y por tanto están accediendo a los mismos datos, y los ven de forma simultánea desde cualquiera de los puntos de acceso al registro. Esto permite no tener que realizar fusiones o uniones de las diferentes BD que pudieran existir en cada uno de los Hospitales o centros donde se trabaje con el registro. Otra ventaja al trabajar con este tipo de plataforma es que cada uno de los Hospitales y Centros de diálisis pueden introducir y modificar los datos de sus pacientes, evitando así la recepción y posterior introducción de los datos por parte del personal de la Coordinación de Trasplantes. Nuestro registro-web comenzará a funcionar durante el primer semestre del año 2004. CONCLUSIONES Como conclusiones más importantes derivadas de nuestra experiencia podemos reseñar las siguientes: Uno de los pilares fundamentales para que un registro funcione correctamente es un buen diseño previo de la base de datos; ésta debe tener mecanismos de control de calidad de los datos y un código identificativo único e inmutable para cada paciente (en nuestro registro este código es el CIP), imprescindible para evitar duplicidades de pacientes. Creemos que es un error permitir la introducción de pacientes en el registro sin este código identificativo, aunque nosotros realizamos esta concesión para que el REDIT comenzara a funcionar, esta decisión habría que haberla valorado más ampliamente ya que nos creó muchos problemas posteriores, obligando a la depuración manual de la base de datos para detectar los pacientes duplicados. En nuestra CCAA se decidió que la gestión del REDIT 543 C. ESTÉBANEZ y cols. Anexo I. Hoja de recogida de datos. se llevara a cabo de forma interna, de tal forma que su mantenimiento estuviera a cargo de personal perteneciente a la Consejería de Sanidad de la Junta de Castilla y León. Otro de los pilares del buen funcionamiento del registro es el feed-back de información que debe existir de forma periódica entre los Servicios de Nefrología que aportan los datos al 544 registro y la Administración. Por último reseñar que decidimos realizar una aplicación web del REDIT para facilitar el acceso a los datos a través de Internet y que esto nos permitiera mantener un registro actualizado que sirviera de referencia tanto a los profesionales sanitarios relacionados con el tema como a la Coordinación de Trasplantes. REGISTRO RENAL CASTILLA-LEÓN BIBLIOGRAFíA 1. Magaz A y cols.: Organización de los registros autonómicos de enfermos renales en tratamiento sustitutivo en España. Nefrología 20 (Supl. 5): 17, 2000. 2. Combined reported on regular Dialisis and Transplantation in Europe, XIX, 1998. Nephrol Díal Transplant 4 (Supl. 4), 1989. 3. Magaz A y cols.: Organización de los registros autonómicos de enfermos renales en tratamiento sustitutivo en España. Nefrología 20 (Supl. 5): 22, 2000. 4. Amenábar JJ: Registros de enfermos renales. Historia del comité de registro de la Sociedad Española de Nefrología. Nefrología 20 (Supl. 5): 1-5, 2000. 5. Orden de 30 de marzo de 2001, de la Consejería de Sanidad y Bienestar social de la Junta de Castilla y León. Publicación BOCY1- n.º 76 (18 de abril de 2001). 6. Zurriaga 0: Aspectos metodológicos de los registros de enfermos renales en tratamiento sustitutivo. Nefrología 20 (Supl. 5) 23, 2000. 7. Gómez Rodríguez P: Problemas en la producción de la información epidemiológica. En: Centro Nacional de epidemiología (ed.). Estadísticas demográfico-sanitarias, ponencias presentadas en el 1 encuentro Marcelino Pascua. Madrid: Ministerio de Sanidad y Consumo, Instituto de Salud Carlos III, Centro Nacional de Epidemiologia, 1992. 8. Amenábar JJ: Registros de diálisis y trasplantes, una asignatura pendiente en España. Nefrología 19: 200-202, 1999. 9. Zurriaga O: Aspectos metodológicos de los registros de enfermos renales en tratamiento sustitutivo. Nefrología 20 (Supl. 5): 23-31, 2000. 10. Teutsch S: Consideratios in planning a surveillance system. En: Teustch, Churchil RE (eds.). Principies and practice of public health surveillance. New York: Oxford University press, 1994. 11. Gervil M, Uirich V, Olesen J, Rusell MB: screening for migraine in the general population: validation of a simple questionnaire. Cephalalgia 18: 342-348, 1998. 12. Desarrollo de la Ley Orgánica 511992 de 29 de octubre sobre tratamiento automatizado de datos de carácter personal (LORTAD): Real Decreto 1332/1994. Madrid: Boletín Oficial del Estado, 20 de Junio de 1994. 13. Real Decreto 994/1999 de 11 de Junio por el que se aprueba el Reglamento de medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal. 14. Peiró S, Librero J, Ordiñana R: lmplicaciones para la gestión hospitalaria de la calidad de anotación y codificación del diagnóstico en el conjunto mínimo de datos. Var Pract Med 9: 1-3, 1996. 15. Sullivan KM, Gibsss NP, Knowles CM: Management of surveillance system and quality control of data. En: Teustch S, Churchill RE (ed). Principies and practice of public health surveillance. New York: Oxzford University Press, 1994. 16. Generalitat Valenciana. Conselleria de Sanitat: Registro de enfermos renales de la Comunidad Valenciana. Informes 19901996. Serie informes de salud núm. 3, 4, 17, 30, 34 y 37. Valencia, 1994-1998. 17. Generalitat de Catalunya. Departament de Sanitat i Seguretat Social. Servei Catalá de la Salut. Registre de malalts renals de Catalunya. Informes estadístics 1984-1997. Barcelona, 1985-1999. 545