Posts Tagged ‘Módulos del SIGEM’

h1

SIGEM – 4ª Parte (para acabar el Registro)

noviembre 12, 2008

Para ir terminando sobre el funcionamiento del Registro en el SIGEM, echamos un vistazo a la posibilidad de dar de alta a los interesados.

Para empezar, existe la posibilidad de extraer una lista de personas desde un dominio de valores. Si no he entendido mal el lenguaje técnico, esto significa que puedo extraer, por ejemplo, la base de datos del Padrón Municipal de Habitantes (PMH) de mi Ayuntamiento y ponerlo en el listado de interesados. De esta forma, me evitaré tener que rellenar, de uno en uno, todos los valores de los datos personales de los interesados.

¿Y qué dice la Protección de Datos sobre todo esto? Quiero decir, ¿puedo sacar los datos del Padrón Municipal para completar el listado de interesados en los procedimientos administrativos? Además, ya puesto, podría volcar en el Registro los datos de los vecinos del pueblo de al lado ya que, cada vez más, estos «foráneos» realizan trámites en el municipio donde yo trabajo.

En teoría, también podría extraer el listado de interesados de la base de datos de entidades sujetas al I.A.E., siempre por el mismo motivo, economizar esfuerzos y usar los datos que ya han sido recopilados.

Estas alternativas de «extracción de datos» presentan algunos inconvenientes que paso a analizar someramente, ya que la Agencia Española de Protección de Datos viene destripando el asunto ya desde hace algunos años.

Para empezar: ¿puedo pedir a la oficina del Padrón Municipal que «ceda» al Registro los datos de los vecinos del mismo Ayuntamiento?

Veamos que dice la Ley sobre la Cesión. Según el art. 3.i) LOPD, por cesión o comunicación de datos se entiende toda revelación de datos realizadas a una persona distinta del interesado. Pero, ¿la comunicación del PMH al Registro es cesión o no? ¿No pertenecen las dos secciones al mismo ayuntamiento, es decir, a la misma persona jurídica? Si así fuera, no habría cesión y los datos podrían extraerse desde el PMH y pasarlos al Registro sin el menor problema jurídico de respeto a la LOPD.

De esta interpretación queda fuera la posibilidad de ceder los datos del PMH del Ayuntamiento A, al Registro del Ayuntamiento B. Esa sí que sería una cesión y tendría que ir a través de los cauces fijados por la AEPD.

En todo caso, incluso si admitimos que no hay cesión y que, dentro del mismo Ayuntamiento, trasvasamos los datos del PMH a la base de datos de los interesados, dentro de la aplicación del Registro, también tendríamos un problema de carácter práctico.

Ejemplo: los datos del PMH pueden no ser útiles para el Registro ya que el interesado quiere ser notificado, por el motivo que sea, en una dirección distinta a la que figura en el Padrón.

Además, deberíamos estar comprobando cada cierto tiempo que las bases de datos del Registro y las del PMH sean idénticas, porque, por ejemplo, yo puedo estar empadronado en la Calle Mayor en enero, y solicitar en febrero la licencia de vado para mi vivienda que acabo de adquirir en la Calle Menor, donde viviré a partir de marzo. Eso obliga a que las dos bases de datos se comparen con una cierta frecuencia para poner al día los datos.

La puesta al día de los datos, recordémoslo, es otra de las obligaciones legales impuestas por la LOPD (art. 4.3). Además, ¿cuándo es «cada cierto tiempo»? y ¿por qué las dos bases de datos deben ser iguales?

Todos estos interrogantes, de difícil solución (yo, por lo menos, no la tengo), me hacen plantear la solución más sencilla: que el Registro no coja los datos personales de ningún «dominio de valores» y que se introduzcan a mano (o escaneados desde las instancias/solicitudes).

Una última cosa: en el procedimiento de alta de nuevos interesados, espero sólo que no sea necesario rellenar el campo del segundo apellido. Si no, los extranjeros tendremos el mismo problema que tengo yo con el Carrefour: para todo el mundo, soy Amedeo Maturo, menos para esta cadena de supermercados, para la cual soy Amedeo Maturo «Segundo Apellido inventado».

h1

SIGEM – 2º Parte (algo sobre el Registro)

septiembre 15, 2008

Lo prometido es deuda, así que sigo destripando la documentación de este gestor documental, para ver qué se puede adelantar, sobre todo en lo que se refiere a sus funciones y utilidades.

Según la documentación disponible, el SIGEM consta de 5 módulos, que son:

  • Registro
  • Tramitación Técnica
  • Expedientes
  • Archivo
  • Pasarela

Empezaré por el Registro, reportando la configuración general del sistema, junto con algunas observaciones sobre aspectos que se podrían mejorar.

El esquema general del Registro es el indicado por este dibujito, siendo la parte en rojo, la actividad propia de este módulo.

El Registro está pensado para recibir documentos en el soporte tradicional del papel y en soporte electrónico. En el segundo caso, la tramitación (mejor dicho, el paso a la fase de distribución) es más sencilla ya que tenemos, desde el principio, el llamado expediente electrónico.

En el caso de presentación «tradicional» de una instancia-solicitud en soporte papel, el Registro, a parte de proporcionar los asientos registrales informatizados, podrá también digitalizar los documentos anexos en soporte papel. De esta forma, la instancia-solicitud del ciudadano, presentada en papel, proseguirá su iter administrativo sólo en formato electrónico. Si sólo la administración electrónica se quedara en esto, sería un gran adelanto, con toneladas de papel ahorrado (en copias) a lo largo del tiempo.

Pero, las funciones del e-Registro son también otras. A partir de este momento, la documentación ya está en mano de la Administración y ésta la distribuye entre sus propias unidades administrativas. Por comodidad de ejemplos, imaginemos que la instancia-solicitud de un ciudadano a su Ayuntamiento lleva un código en su margen superior derecho con las siglas URB-08-09-12-E0001.

El SIGEM debería poder enviar, a través del canal de distribución, de forma automática, la solicitud número 1, del día 12 de septiembre de 2008, a la Concejalía de Urbanismo, donde, el Jefe de Sección (¿a mano? ¿automáticamente?), repartirá el expediente en función de las cargas de trabajo, ausencias, competencias, etc. entre sus funcionarios.

Tanto la parametrización de los códigos de los expedientes, así como la distribución de los expedientes se podrá gestionar desde el apartado de Administración del Registro. Es aquí donde tendremos que tener cuidado con los parámetros que podrán ser admitidos por el Registro. Recordemos que, según el art. 24.2.b), Ley 11/2007, se podrán admitir no sólo los documentos normalizados (los que llevan el mencionado código URB-08-09-12-E0001 del ejemplo), si no también «cualquier solicitud, escrito o comunicación distinta de los mencionados en el apartado anterior dirigido a cualquier órgano o entidad del ámbito de la administración titular del registro«.

Aquí creo que empezamos a tener un problema. En el antiguo mundo de la Administración en papel, si quería presentar una instancia al Ayuntamiento de Melilla y me encontraba de vacaciones en Coruña, me daba un paseo por el pórtico de la zona de la Ciudad de Cristal, me iba a la Subdelegación del Gobierno y presentaba el escrito. Ya se encargaría la Administración de hacer llegar mi instancia al órgano competente.

Pues, con el texto del art. 24.2.b en la mano, ya no tengo tan claro que esta práctica, muy beneficiosa para el ciudadano, se pueda trasladar al Registro electrónico. Es decir, éste admitirá cualquier tipo de escrito (independientemente del soporte utilizado) dirigido a esa administración, pero no admitirá un escrito dirigido a cualquier otra administración.

Para que estos tipos de escritos se puedan recibir, será necesaria un previo convenio de colaboración, entre las Administraciones que quieran intercambiar las funcionalidades de sus registros electrónicos.

Eso quiere decir que la Administración Municipal de, por ejemplo, Miravete de la Sierra ya puede ir firmando un convenio con, pongamos, la Diputación de Teruel, para habilitar los registros electrónicos de ambos.

Se entrevé ya la creación de una jungla de convenios de reconocimientos mutuos, donde la interoperabilidad será el gran debate. Ayuntamientos de Extremadura, con el Open Office y con servidores Unix y Linux, deberán tener una plataforma de registro común con cualquier otra administración de signo Windows.

Por cierto, y si el alcalde de mi ciudad no quiere firmar un convenio de colaboración con nadie ¿eso quiere decir que no podré usar nunca este e-registro para comunicarme con otras administraciones? ¿Quedará todo a espensas de la voluntad de las partes?

Me temo que el instrumento del convenio, en este caso, no es más apropiado.

Todavía queda mucho rato y estamos sólo en el módulo de Registro.