Los sistemas que dan soporte al Procedimiento Administrativo Común (PAC)

¿QUÉ SISTEMAS HAY QUE INCLUIR SI EL EJERCICIO ES UN PAC?

La actuación de la Administración en muchos casos se regula a través del Procedimiento Administrativo Común, o PAC, y si la propuesta del caso práctico se apoya en parte o totalmente en este, se muestran a continuación los servicios y sistemas que puede ser necesario utilizar.

Comenzaremos repasando el uso de los medios declarados compartidos, que pueden dar soporte al PAC y que, según la normativa, “será obligatorio y sustitutivo para los medios y servicios particulares de las distintas unidades” (RD 806/2014 art 10.3). Con lo cual, siempre que tengan encaje en el ejercicio, deberían de ser utilizados.

Luego revisaremos los distintos sistemas puestos a disposición que podremos utilizar, con una aproximación más profunda que la que podamos emplear en el ejercicio, pero con el fin que logremos una idea muy clara de para qué vale cada uno de ellos, en qué casos los usaremos y con qué fin.

1. Los servicios declarados como compartidos.

Los servicios que están declarados como compartidos, que son más susceptibles de ser referenciados en nuestro ejercicio por dar soporte al procedimiento administrativo son los siguientes, y tienen el siguiente encaje en nuestro ejercicio.

1.1. Servicio unificado de telecomunicaciones:

Siempre que necesitamos incluir líneas de comunicaciones, telefonía fija o móvil o conectividad entre sedes, acudiremos al Contrato Unificado de Telecomunicaciones, con diferentes lotes y adjudicatarios dependiendo del lote:

• Lote 1 Red corporativa multiservicio y servicio de telefonía fija: para las redes de comunicaciones en nuestras sedes y la telefonía por IP, que actualmente se sirve mediante una centralita virtual (basada en Comunicaciones Unificadas de CISCO).

• Lote 2 Comunicaciones móviles: tanto los terminales como los contratos de voz y datos para las comunicaciones móviles.

• Lote 3 Conectividad a Internet desde las sedes: proporcionado por el proveedor adjudicatario de los lotes, incluye la gestión del tráfico, enrutamiento y cortafuegos hasta el punto de acceso a Internet.

• Lote 4 Red Internacional: proporciona las comunicaciones seguras entre sedes que se encuentran en el extranjero.

Este servicio es opcional y poco probable que aparezca en nuestro ejercicio, pudiendo no acudir a él si indicamos explícitamente que entendemos que el organismo ya dispone de toda la infraestructura necesaria y la capacidad sobrante para alojar nuestro sistema, y que utilizaremos todos los sistemas e infraestructura existente.

Por ejemplo, esta frase sirve para el apartado 1.1, 1.2,1.3 y 1.4 con algunas variaciones: “Asumo que el organismo ya dispone de toda la infraestructura y capacidad de comunicaciones [cómputo, almacenamiento, etc.] necesaria, por ejemplo a través del Contrato Unificado de Comunicaciones y de acuerdo a la normativa que regula la conexión a la red SARA.”

1.2. Servicio de seguridad gestionada:

Actualmente en desarrollo, cubre los aspectos de seguridad perimetral, unificación de logs y correlación de eventos (SIEM), centro de operaciones de seguridad (COR) y como mecanismo de coordinación entre organismos. Si aparece en algún ejercicio el diseño de un sistema de gestión de la seguridad, deberemos hacer mención a la conectividad federada con este servicio, aunque habrá partes de la gestión de seguridad que resida en nuestro tejado como la definición y seguimiento de la Política de Seguridad, elaboración e implantación de procedimientos y herramientas de seguridad, desarrollo de auditorías, clasificación e implantación de las medidas del ENS, etc.

Este servicio es opcional que aparezca en nuestro ejercicio, pudiendo no acudir a él si indicamos explícitamente que entendemos que el organismo ya dispone de toda la infraestructura necesaria y la capacidad sobrante para alojar nuestro sistema, y que utilizaremos todos los sistemas e infraestructura existente.

Hablar del COCS (centro de operaciones de ciberseguridad de la AGE)

El Centro de Operaciones de Ciberseguridad de la Administración General del Estado y sus Organismos Públicos (COCS), previsto en la Medida 9 del Plan de Digitalización de las Administraciones Públicas 2021 – 2025, es un servicio compartido y de prestación centralizada, dirigido a proporcionar protección a la Administración General del Estado y sus organismos públicos, con el fin de aumentar la capacidad de vigilancia y detección de amenazas en la operación diaria de sus sistemas de información y comunicaciones, así como de mejorar su capacidad de respuesta ante eventuales ataques.

Descripción

El COCS reforzará, a través de servicios horizontales de ciberseguridad, las capacidades de prevención, protección, detección y respuesta ante incidentes de ciberseguridad, de forma que gracias a la optimización y las economías de escala se obtenga una mejor eficacia y eficiencia y sirva de referente para otros centros.

La División de Planificación y Coordinación de Ciberseguridad, dependiente de la Secretaría General de Administración Digital (SGAD), será responsable de la dirección técnica y estratégica del servicio. El CCN-CERT pone a disposición su capacidad de operación de ciberseguridad, herramientas y soluciones de ciberseguridad.

Se encuentran en el alcance del COCS la totalidad de las entidades usuarias del Servicio Unificado de Comunicaciones de la Administración General del Estado, más otras entidades que cuentan con conexión directa a un nodo de interconexión de Red SARA.

El COCS prestará servicios de prevención, protección, detección y respuesta ante incidentes de ciberseguridad:

1.3. Servicio de alojamiento de infraestructuras TIC:

Actualmente en desarrollo, permite el alojamiento de servidores en centros de procesos de datos declarados de Tier III. Deberemos mencionar esta posibilidad siempre y cuando se necesite el alojamiento de servidores en propiedad de la Unidad TIC en algún lugar, antes de ejecutar un contrato para este propósito, siempre que sea posible.

1.4. Servicio de nube híbrida (Nube SARA):

Relacionado con lo anterior en cierta medida, se trata de un servicio aún en desarrollo que permite el alojamiento de servidores virtuales en modo nube para las unidades que requieran capacidad de cómputo, almacenamiento y comunicaciones. Será la opción preferente en la solución de nuestro ejercicio para la arquitectura física, siempre que esté disponible, a menos que aplique alguna otra consideración que no la haga viable.

Este servicio es opcional que aparezca en nuestro ejercicio, pudiendo no acudir a él si indicamos explícitamente que entendemos que el organismo ya dispone de toda la infraestructura necesaria y la capacidad sobrante para alojar nuestro sistema. Esto puede ser justificado en un sistema de soporte a PAC, que probablemente requiera poca capacidad de cálculo, almacenamiento y comunicaciones.

1.5. Servicio de correo electrónico unificado:

Si se requiere de dotar de cuentas de correo electrónico, este será el servicio al que deberemos suscribirnos. La administración de las cuentas de correo recaerá en nuestra unidad.

Este servicio es opcional que aparezca en nuestro ejercicio, pudiendo no acudir a él si indicamos explícitamente que entendemos que el organismo ya dispone de toda la infraestructura necesaria y la capacidad sobrante para alojar nuestro sistema.

1.6. Servicio multicanal de atención al ciudadano:

Se trata del servicio de soporte a la atención telefónica (060) y multicanal, para la resolución de dudas e incidencias de los ciudadanos con respecto a algún servicio telemático. En nuestro ejercicio, si se trata de un sistema que da soporte a PAC, podremos incorporar un servicio de atención al ciudadano, a través del servicio compartido.

Hay que tener en cuenta que este servicio no proporciona los agentes para la atención, si no que entrega las herramientas para la gestión de la demanda ciudadana:

• Clasificador automático de llamadas y cuestionarios.
• Teléfonos “softphone”.
• Sistemas de gestión y encolado de llamadas.
• Sistemas de grabación de llamadas.
• Etc.

Este servicio es opcional que aparezca en nuestro ejercicio, y debe justificarse en términos de importancia del servicio, complejidad del procedimiento y en último lugar coste de implementación del servicio. A menos, desde luego, que lo requiera el enunciado.

1.7. Servicio de gestión del registro electrónico

El registro de entrada y salida es un sistema de apuntes que deja constancia de todas las comunicaciones desde fuera de la Administración a la misma (registro de entrada) y desde la Administración al exterior (registro de salida).

Este servicio compartido cubre todos los aspectos de la gestión de registro:

• Gestión de apuntes de entrada y salida en Registro Electrónico.
• Gestión de registro presencial (Oficinas de asistencia en materia de registro).
• Intercambio de registros internos y externos (SIR).

A efectos prácticos, en nuestra solución podemos optar por:

a) Desarrollar un sistema de registro propio, que deberá umplir con la norma SICRES e integrarse con la plataforma SIR, de forma obligatoria, conforme a lo dispuesto en la Ley 39/2015: “Ley 39/2015 del Procedimiento Administrativo Común de las Administraciones Públicas, modificada por la disposición final 9 de la Ley 10/2021, de 9 de julio, las Administraciones de su ámbito deben estar integradas en SIR a partir del 2 de abril de 2021”.

b) Utilizar el REC directamente, mediante la adopción del servicio en nube de GEISER. Nuestra aplicación se integrará con REC a través de la API que dispone a través de servicios web.

¿Para qué realizará la aplicación acceso a GEISER?. Básicamente dos casos, uno sencillo y otro más complejo, que pueden ser :

Caso de uso 1 (integración débil): Realización de apuntes en registro. La aplicación de forma obligatoria deberá realizar apuntes de registro:

• De entrada cuando la aplicación realiza aportes al expediente de documentos u operaciones iniciadas por el ciudadano, que por norma general irán firmadas electrónicamente, en los supuestos que se indica en la Ley 39.
• De salida cuando produce notificaciones al ciudadano, como pueden ser la solicitud de subsanación, remisión de resoluciones, requerimientos, etc.

Caso de uso 2 (integración fuerte): Integración de la bandeja de entrada de tramitación en la aplicación. En este caso, cuando se produzca una solicitud genérica con destino a la unidad tramitadora, para el procedimiento especificado, la aplicación consultará la bandeja específica e incorporará los apuntes de registro y documentos especificados al expediente.

Si utilizamos el caso 1, hay que tener en cuenta que la tramitación presencial del procedimiento se realizará de la siguiente manera, como forma general:

a) Un ciudadano presenta un formulario físico en la oficina de asistencia en materia de registros.

b) El funcionario digitaliza el documento, realiza el apunte en registro y lo introduce mediante GEISER en registro indicando el procedimiento y la unidad tramitadora destino. Se entrega un recibo al ciudadano.

c) En la unidad, un funcionario a través de GEISER ve esa entrada en registro en la bandeja de entrada.

d) Manualmente, crea un expediente en la aplicación al ciudadano e incorpora la documentación anexa en GEISER.

e) La aplicación puede consultar al registro para obtener el documento de recibo en cualquier momento, e incorporarlo al expediente, o disponer en línea de el solo cuando sea necesario.

En el caso 2, la aplicación realiza el punto c) y el d) automáticamente.

El servicio de integración de aplicaciones en REC tiene teóricamente un coste de servicio, no para los apuntes en sí, si no para los apuntes que incorporan documentos. Recientemente se han dado instrucciones para que las aplicaciones no almacenen documentos en el registro, ya que no está diseñado para este propósito. Para evitar esto, puede indicarse en los apuntes de registro las referencias a los documentos y el HASH de cada uno de ellos, con un enlace al documento en cuestión (o CSV del sistema de archivo).

1.8. Servicio de gestión de notificaciones

Este servicio proporciona medios de comunicación y notificación a los interesados en el procedimiento (ciudadanos). La comunicación no tiene efectos jurídicos, no requiere firma en recepción y no produce acuse de recibo, al contrario que la notificación.

Mediante la suscripción a este servicio, que requiere la firma de un convenio en el caso de notificaciones postales, se dispone de los siguientes medios de notificación:

a. Comparecencia en sede (gratuita), a través de Carpeta Ciudadana en Punto de Acceso General.

b. Notificación a través de Dirección Electrónica Habilitada (DEH), también gratuito, especialmente indicado para personas jurídicas (empresas y organismos).

c. A través de notificación postal (no gratuito), a través de los servicios de impresión y ensobrado y los operadores de los servicios postales.

Nota

Cuando el servicio es postal, también se produce la recepción del acuse de recibo, que será de forma electrónica a través de un servicio web que pondremos a disposición a través de Red SARA, para recibir los acuses de recibo de las notificaciones (datado), bien por confirmación de entrega, bien por plazo.

INFO

Hay otro procedimiento de notificación, que es el de comparecencia en sede, válido para los sujetos obligados y en el caso que toda la tramitación se produzca a través de la aplicación que reside en nuestra sede electrónica, tal es el caso por ejemplo de ACCEDA.

Este servicio, en el caso de un PAC, es necesario que aparezca en nuestro ejercicio ya que es un requisito legal.

1.9 Servicio común de generación y validación de firmas electrónicas

Este servicio consiste en la suite de validación de identidad y firma electrónica. Se trata de una actividad que va ligada a la tramitación electrónica del expediente. Dispone de dos modalidades que deberemos elegir:

a) Modo de consumo en la nube, generalmente a través de el acceso a “@firma” a través de la red SARA.

b) Modo federado, en el cual podemos realizar una instalación en local para los casos en que tengamos uno o los dos casos siguientes:

• i) Gran volumen de procesamiento de firma electrónica y validación de certificados.

• ii) Necesidades especiales de latencia, disponibilidad o confidencialidad, que vengan especificadas en el enunciado.

En estos sistemas podemos incluir a Fire, “@firma”, “Clave” y “Clave firma” que indicaremos después.

Este servicio, en el caso de un PAC, es necesario que aparezca en nuestro ejercicio ya que es un requisito legal, salvo que podamos justificar una solución de firma electrónica alternativa (difícilmente a menos que lo indique el enunciado).

1.10. Servicio de gestión de expediente y documento electrónico

Este servicio permite la gestión de expedientes y documentos electrónicos, de acuerdo a lo dispuesto en el ENI y las NTI de Interoperabilidad, cuyo plazo de adopción ya se ha extinguido.

Tiene dos modalidades en las que podemos implantar la interoperabilidad:

a) Utilizar el formato ENI como formato nativo para el almacenaje y la gestión de los documentos y expedientes electrónicos. Utilizaremos esta aproximación para sistemas que crearemos desde cero y que tengan el objetivo de alcanzar la máxima interoperabilidad. También si queremos un almacenamiento en la nube de nuestros expedientes en INSIDE/ARCHIVE.

b) Utilizar un formato nativo y realizar la conversión a formato interoperable cuando sea necesario (intercambio o remisión de expedientes). Para esto generamos un interfaz mediante G-INSIDE, que permite generar formatos interoperables “al vuelo”.

Este servicio, en el caso de un PAC, es necesario que aparezca en nuestro ejercicio ya que es un requisito legal, salvo que podamos justificar una solución de interoperabilidad alternativa (difícilmente a menos que lo indique el enunciado).

QUE ES INSIDE

InSide es un sistema para la gestión de documentos y expedientes electrónicos que cumple los requisitos para que ambos puedan almacenarse y/o obtenerse según el ENI, esquema que establece las normas básicas para el intercambio y almacenamiento de documentos y expedientes electrónicos. Supone la gestión documental íntegramente electrónica de los documentos de la gestión viva del expediente, como paso previo al archivado definitivo de la documentación en un formato interoperable y duradero.

Además, integra servicios de Interconexión con la Administración de Justicia y en general, con otras administraciones.

Como complemento a InSide se añaden funcionalidades relacionadas con la gestión de documentos electrónicos con CSV, como la generación, consulta o el almacenamiento de documentos, teniendo en cuenta los aspectos de interoperabilidad de las Administraciones Públicas.

G-Inside (Generador de Inside)

Es la puesta a disposición de una batería de servicios Web en la nube SARA para validar y generar documentos y expedientes en base al ENI, generación de documentos PDF de visualización del documento y expediente electrónicos. G-Inside no almacena nada, sólo se puede usar como modo de conversión a documentos y expedientes electrónicos para su almacenamiento en otro sistema. Permite el uso de los servicios para la validación sintáctica de los documentos y expedientes electrónicos.

1.11. Servicio de gestión de archivo electrónico

Muy similar al anterior, ofrece un almacenamiento definitivo a largo plazo de expedientes finalizados, que cumple los requisitos de interoperabilidad y unifica formatos de cara al mantenimiento de un sistema unificado a largo plazo, de acuerdo a las Políticas de Gestión Documental.

Este servicio, en el caso de un PAC, es necesario que aparezca en nuestro ejercicio ya que es un requisito legal, salvo que podamos justificar una solución de interoperabilidad alternativa (difícilmente a menos que lo indique el enunciado).

2. Identificación, autenticación y autorización

2.1. Introducción

La identificación se refiere a la capacidad de distinguir de forma única entre los usuarios de un sistema. Simplemente identifica (distingue) a unos usuarios de otros. La información que se almacena de un usuario puede variar, desde una sencilla cuenta de correo hasta un perfil completo de datos dentro del sistema.

La autenticación es el proceso que permite asegurar que un usuario es quien declara ser, es decir, que sus datos son correctos.

La firma electrónica permite asegurar la autenticidad del origen del documento, así como la integridad de la información firmada.

Algunos o todos de estos elementos se encontrarán casi seguro en un sistema de soporte al procedimiento administrativo.

La Ley 39/2015 de Procedimiento Administrativo Común, en el Capítulo II, de identificación y firma de los interesados en el procedimiento administrativo, utiliza el término identificación para referirse a identificación y autenticación, ya que indica que “las Administraciones Públicas están obligadas a verificar la identidad de los interesados en el procedimiento administrativo …”.

Para ello, de forma obligatoria, deberán admitir:

• Sistemas basados en certificados cualificados de firma electrónica expedidos por los prestadores de servicios de confianza incluidos en la “Lista de confianza de prestadores de servicios de certificación”.

• Sistemas basados en certificados cualificados de sello electrónico expedidos por los prestadores de servicios de confianza incluidos en la “Lista de confianza de prestadores de servicios de certificación”.

• Sistemas de clave concertada y cualquier otro que se considere válido, siempre que:

  • Cuenten con un registro previo que permita verificar la identidad.

  • Cuenten con autorización previa de la SGAD.

¿Qué es esto a efectos prácticos?

• El sistema de identificación debe identificar y autenticar la identidad de la persona física o jurídica (es decir, asociarla a un DNI, NIF o NIE u otras maneras de identificación, como nombre y apellidos, razón social, etc. ).

• Deben admitirse necesariamente los medios de identificación basados en certificados X509 (de firma para personas físicas y de sello para las personas jurídicas), de cualquiera de los proveedores contemplados en eIDAS.

• Pueden admitirse otros mecanismos previa autorización.

¿Por qué los certificados tienen un papel tan relevante?

• Porque se basan en una cadena de confianza que permite asegurar que la identidad del titular ha sido comprobada, y que los mecanismos técnicos en que se basa esta confianza se mantienen de acuerdo a una serie de requisitos establecidos.

2.2. Sistemas para validar la identidad y representación del ciudadano o entidad:

Cl@ve identificación es un hub de mecanismos de autenticación diversos que permite a las aplicaciones realizar la identificación de manera normalizada.

Dispone de los siguientes mecanismos de identificación:

• DNI electrónico o certificado.

• Cl@ve permanente (claves concertadas con registro previo).

• Cl@ve PIN 24h (claves concertadas con registro previo).

• Identificación de ciudadanos de la UE (proyecto STORK).

¿Cómo funciona?.

• Es necesario previamente solicitar el alta al organismo en el servicio Cl@ve, informando del certificado que se utilizará para firmar las solicitudes y autenticar.

• Una vez dado de alta, se genera por parte de la aplicación un token SAML2 firmado con el certificado indicando:

• La solicitud de identificación.

• Los mecanismos admitidos.

• El nivel de seguridad (QAA) requerido.

• La aplicación genera este token y lo envía al navegador del usuario, junto con la redirección del mismo a través de HTTP a la pasarela de Cl@ve. No es necesario que los servidores se vean entre sí, ya que la comunicación se realiza a través de redirecciones a través del navegador del usuario.

• Cl@ve autentica al usuario mediante el proveedor de identidad escogido, y devuelve la respuesta firmada mediante un parámetro para que el servidor de la aplicación la decodifique, y proporcionando la información de:

  • Nombre y apellidos del usuario (currentGivenName, currentFamilyName). Obligatorio.

  • Identificador de la persona (personIdentifier). Obligatorio. En caso de certificados nacionales, el NIF.

  • Proveedor de identidad utilizado. Obligatorio. Actualmente, certificado electrónico, credencial europea, clave permanente o cl@ve PIN24h.

@firma

Es posible que en ocasiones debamos validar de forma autónoma los certificados o las firmas de los documentos enviados a la aplicación. En este caso, utilizaremos los servicios proporcionados por @firma para:

• Comprobar la validez de los documentos firmados.
• Comprobar la validez de los certificados.

¿Como funciona?

Previo al uso del servicio en la nube deberemos realizar una solicitud de uso del servicio, indicando las direcciones IP visibles desde red SARA de los servidores que accederán al mismo, así como el certificado utilizado para validar a los servidores.

Una vez con acceso al servicio, los servidores realizarán peticiones SOAP, firmadas con WS-Security, al servicio web de @firma, para algunos de los siguientes usos:

• Validación de firmas.
• Validación de certificados.
• Obtención de los datos de las firmas y certificados.

¿Cómo representar el uso de @firma en nuestro ejercicio?

Mediante un acceso a través de RED SARA al servicio, o bien, mediante el modo federado, solo recomendado para casos de alto volumen.

En general, la conectividad a @firma será necesaria en algunos casos específicos, como cuando se hagan aportes de documentación firmados, y sea necesario comprobar la firma de los interesados.

REPRESENTA

¿Para qué sirve?

“Representa” es un aplicativo que permite comprobar la pertenencia y estado en activo de una persona a un colectivo o colegio profesional que tenga algún convenio firmado con las Administraciones Públicas que les habilite a realizar la tramitación de procedimientos administrativos en nombre de los ciudadanos, o bien si una persona determina está apoderada o habilitada para representar en un determinado procedimiento administrativo.

Se usa en los casos en los que, para el procedimiento administrativo en cuestión, existen colectivos (por ejemplo, abogados o procuradores), que están adheridos a un convenio que les permite ejercer la representación por el mero hecho de pertenecer a ese colectivo y encontrarse en activo.

Los colectivos que reconoce actualmente Representa son:

• Las personas inscritas en el Registro Electrónico de Apoderamientos.
• Los funcionarios habilitados inscritos en el registro de funcionarios habilitados.
• Gestores Administrativos.
• Graduados Sociales.
• Notarios.

¿Cómo se utiliza?

Se trata de un servicio web accesible a través de la red SARA, que permite comprobar si la identidad de una persona determinada dispone de la capacidad de representación sobre un interesado, para un determinado procedimiento (debe disponer de código en SIA para ello).

Tiene dos servicios principales, uno para determinar la pertenencia a un colectivo y otro para determinar la capacidad de representación sobre un procedimiento determinado.

Los representantes también pueden ser personas jurídicas.

El servicio requiere del acceso a los servicios web a través de red SARA.

¿Cuándo haremos uso del servicio?

Siempre que haya un procedimiento administrativo, podemos incluir Representa, puesto que es un derecho de los interesados recogido en la Ley 39/2015, a menos que el reglamento del procedimiento indique explícitamente lo contrario.

Como alternativas, podemos utilizar Habilita y Apodera, de forma individual, aunque no parece demasiado útil.

NOTA

Podemos añadir un valor añadido al ejercicio si proponemos como medida organizativa en nuestro ejercicio la firma de convenios con colectivos de representación para la gestión de trámites complejos o que necesiten de ayuda adicional para el ciudadano, así como la utilización de representa.

APODERA

Apodera permite la inscripción y registro de poderes de representación presenciales o telemáticos.

¿Cómo se utiliza?

Apodera tiene dos vertientes:

• Para el ciudadano, dispone de un portal de acceso web, situado en el Punto de Acceso General, en Carpeta Ciudadana, y en la url https://apodera.redsara.es.

• Para las Administraciones, en el portal https://apodera.redsara.es/funcionario. En este caso, se accede a través de AutenticA, donde a su vez se mantiene la gestión de los roles y permisos.

Para el tratamiento automatizado, se dispone del servicio web de consulta de apoderamientos, accesible a través de red SARA mediante un registro previo del organismo, que se comprueba mediante el intercambio de certificados.

¿Cuándo haremos uso del servicio?

Si no hacemos uso del servicio de Representa, deberemos utilizar este para comprobar el registro de Apoderamientos, cuando nuestro sistema de soporte a un procedimiento administrativo que permita los apoderamientos.

HABILITA

Habilita es el registro de funcionarios habilitados, que se trata de un mecanismo de identificación de ciudadanos, solo que en este caso lo hará un funcionario por ellos, según los dispuesto en la Ley 39/2015.

La aplicación tiene una interfaz de administración a través de un portal web, para el alta y registro de habilitados, así como un acceso de servicios web para el consumo del servicio. El WSDL de servicios permite un único servicio, que es consultar si el usuario dispone de habilitación para el procedimiento correspondiente, identificado por su código SIA.

2.3 Sistemas para validar la identidad y autorización de los empleados públicos.

Para identificar y autorizar a los empleados públicos en nuestro sistema disponemos de varios métodos, como una integración (Single Sign On) de la aplicación en el sistema de autenticación de red del Organismo (usualmente Directorio Activo, pero también puede ser Radius u otros mecanismos de autenticación).

Estos métodos tienen el problema de que sólo son válidos para usuarios de red local, pero está bien que si esta opción existe, pueda ofrecerse.

También se encuentra la opción de AutenticA, una aplicación de Single Sign On proporcionada como servicio que no requiere que los usuarios se encuentren en la misma red local.

AUTENTICA

Autentica se alimenta de fuentes primarias de usuarios gestionadas por responsables de los organismos. Permite incorporar usuarios empleados públicos y relacionados (altos cargos, asesores, personal temporal, etc.) que se encuentren asociados con la estructura organizativa mantenida por DIR3.

Está integrado con Cl@ve para la identificación (admite certificados y claves concertadas), y devuelve datos de la Unidad, puesto, teléfono y correo electrónico del usuario autenticado.

Además, permite la gestión de permisos y roles por aplicación.

NOTA

El sistema de autorización es suficientemente flexible para la mayoría de las aplicaciones: permite especificar por cada aplicación y cada usuario las combinaciones que se requieran de ámbito, perfil y rol, logrando de esta manera una granularidad fina que puede utilizar la aplicación para gestionar el acceso a la información y a las operaciones.

¿Cómo funciona?

• En primer lugar, habremos de registrar la aplicación contra el servicio de Autentica mediante la correspondiente solicitud. Esto registra la aplicación en Autentica y le proporciona un identificador, y además se indica una serie de parámetros a Autentica, como son la URL de retorno de la autenticación.

• En la aplicación, redirigiremos el navegador del usuario proporcionando como parámetro el identificador de aplicación. Después de la autenticación, Autentica redirigirá el navegador del usuario a la URL de retorno para esa aplicación, e incluirá una respuesta SAML con los datos del usuario.

NOTA

como en el caso de Clave, no es necesaria la conectividad a través de RED SARA para el uso de este servicio, ya que los servicios basados en SAML se ejecutan a través del intercambio de tokens a través del equipo del usuario.

También está la funcionalidad de Autenticación, que permite asignar a cada usuario, para cada aplicación, una combinación de Ámbito - Perfil - Rol. Son elementos destinados a que cada aplicación construya un árbol de autorizaciones con hasta 3 niveles de profundidad para identificar todos los permisos posibles.

3.Servicios de asistencia a la firma electrónica

La firma electrónica es un elemento clave y esencial de la administración electrónica, y en general para el intercambio de documentos con garantía de autoría e integridad.

La política de firma electrónica y certificados de la AGE y sus OOPP recoge los aspectos legales y técnicos con respecto a la utilización de estos medios en los procedimientos de la Administración.

Los sistemas de firma electrónica, de cara a las aplicaciones, se basan en la premisa de que el usuario firmante dispone de un certificado X509 en un equipo bajo su control, o en un dispositivo de firma seguro en la nube, con el que realizará la firma electrónica o el sello electrónico (recuerda, las personas firmas y las entidades sellan). Como para firmar es necesario que la aplicación que firma (por ejemplo, Adobe Acrobat o Autofirma o cualquier otra) acceda a la clave privada del usuario, esta operación se realiza por norma general, en el equipo del usuario, o servidor en el caso de sellos para la actuación administrativa automatizada, excepto: a) Que utilicemos un dispositivo hardware para la firma segura. b) Que utilicemos la firma en la nube.

Aunque la aplicación en principio que desarrollemos no realizará la parte de firma para los interesados, sí que podemos proporcionar mecanismos para la validación de las firmas.

Escenarios típicos de gestión de firma electrónica en las aplicaciones de soporte a PAC:

• Asistir en el proceso de firma en el equipo del usuario para los interesados de los documentos que requieran de firma para la presentación de solicitudes, renuncias o desestimientos, comunicaciones, declaraciones responsables o recursos (art.11.2 Ley 39/2015).

• Acreditar la representación, apoderamiento o habilitación.

• Realizar la firma de documentos aportados al expediente por parte de los tramitadores.

• Ejecutar la firma de disposiciones, resoluciones o notificaciones.

• Realización de actuaciones administrativas automatizadas mediante sellado.

Según el reglamento de eIDAS, las personas físicas firman y las personas jurídicas sellan, siendo ambos mecanismos técnicamente muy similares, exceptuando que los certificados de firma identifican a una persona y los de sello a una entidad.

Aplicaciones y servicios que dan soporte a este proceso:

1. Autofirma

Autofirma es una aplicación de cliente instalable en los dispositivos de usuario final, está disponible para Windows, MacOS y Linux.

Permite la firma electrónica o sellado de cualquier tipo de documento, incluyendo PDF, en distintos formatos (Xades, Pades). Toma un documento de entrada y produce un documento de salida firmado con el certificado que se encuentra en el equipo del usuario.

Esta aplicación no se integra con nuestro sistema pero la podemos proponer si preguntan.

2. ClaveFirma

   ClaveFirma es una solución de firma en la nube, mediante la puesta a disposición de los ciudadanos de un certificado de firma alojado en un dispositivo seguro de firma (HSM) custodiado por la Policía Nacional, y servido a través de una serie de servicios web.

Clave Firma no se ofrece como un servicio directamente al ciudadano si no que se ofrece como solución integrable a través de otros proveedores de servicios. Para la utilización o la integración de esta opción en nuestro sistema, puede utilizarse el componente de Fire.

3. FIRe

FIRE es un componente de integración que simplifica el uso de las firmas electrónicas haciendo de “hub” para los procesos de firma en la nube y firma local. La firma local se realiza invocando a “autofirma” y la firma en la nube invocando a Clave Firma.

Fire proporciona dos flujos distintos de firma, uno para un único documento y otro para lotes de documentos. Requiere conectividad a través de Red SARA

4. PortaFirmas

Portafirmas es la aplicación para gestionar flujos de firma para la Administración. Puede utilizarse como aplicación web en solitario o integrarse en el workflow de las aplicaciones. También dispone de una aplicación para móvil (iOS y Android).

Portafirmas permite:

• Firmas en paralelo o cascada.

• Realizar el “visto bueno” de documentos.

• Definición de flujos de firma pre-establecidos.

• Organización de las solicitudes en bandejas de entrada, enviados, pendientes, terminados.

• Consulta de CSV de documentos firmados en portafirmas.

¿Cómo se utiliza?

• Como aplicación disponible para usuario final en red, simplemente deberemos designar los firmantes a la hora de enviar un documento a firma.

• Integrada en los flujos de workflow de nuestra aplicación a través de un interfaz de servicios web, disponibles a través de red SARA.

o NOTA

Podemos utilizar portafirma integrada con nuestro sistema simplemente invocando los servicios web de portafirmas a través de SOAP a través de red SARA. Si tenemos un gestor de flujos de trabajos en nuestro sistema, éste comunicará con Portafirmas AGE quién tiene qué firmar qué, y el documento a firmar aparecerá en la bandeja de firma del susodicho, pero ¡ojo! solo para los empleados públicos generalmente. El sistema tendrá que almacenar quién debe firmar qué en cada uno de los trámites y cómo es el procedimiento de firma. También tendrá que consultar con regularidad si ya se ha producido la firma. Las personas firmantes deberán estar ya dadas de alta en Portafirmas AGE.

3.1 Firma electrónica y sellado por parte de la Administración.

Las Administraciones Públicas deberán identificarse según lo dispuesto en la Ley 40/2015, y contar con mecanismos de firma y sello electrónicos para el desarrollo de su actividad.

En el caso del PAC, la Administración podrá utilizar los siguientes mecanismos de firma electrónica:

a) Firma electrónica por los titulares del procedimiento firmados personalmente con su certificado personal o de empleado público, así como el DNI-e.

b) Firma electrónica mediante certificado de sello.

3.2 Código Seguro de Verificación

Regulados en el art 27 de la Ley 39/2015, no se trata propiamente de un sistema de “firma electrónica” (aunque el texto legal debería decir sello) como de una modalidad de verificación que permite:

• El cotejo de copias en papel con el original en electrónico (recordemos que salvo excepciones los documentos administrativos son de carácter electrónico).

• Ofrecer una referencia al documento en sí, alojado por la Administración, ofreciendo unas garantías de autenticidad, preservación y seguridad.

¿En qué consiste?

Generalmente asociados al sistema de gestión documental (como podría ser INSIDE y otro), permite asociar de forma unívoca a un documento un código que permita su recuperación a través de un mecanismo en sede electrónica (podría ser Carpeta Ciudadana o el PaG) utilizando dicho código.

Generalmente se incluye un membrete o una banda al documento en PDF donde se incluye:

• El código seguro de verificación, como una cadena de caracteres arbitraria o predecible.
• La dirección de la sede electrónica donde puede producirse el cotejo o la validación del documento.

¿Como se utiliza?

• Es necesario previamente una Orden Ministerial para el uso de los mecanismos de CSV (artículo 42 de la Ley 40/2015 y el art. 20 del RD 1671/2007). En dicha Orden debe especificarse al menos:

  a) Actuaciones automatizadas a las que es de aplicación el sistema.

  b) Órganos responsables de la aplicación del sistema.

  c) Disposiciones que resultan de aplicación a la actuación.

  d) Indicación de los mecanismos utilizados para la generación del código.

  e) Sede electrónica a la que pueden acceder los interesados para la verificación del contenido de la actuación o documento.

  f) Plazo de disponibilidad del sistema de verificación respecto a los documentos autorizados mediante este sistema.

• Después es necesario que dispongamos de un sistema que genere, asigne y gestione el código, lo incluya en las copias impresas de los documentos electrónicos que guardemos (recordemos el deber de custodia) y además gestione la visualización de los documentos a partir del código desde la sede correspondiente.

• CSV broker y PaG. Podemos incluir un enlace mediante una solicitud al punto de verificación de CSV del PaG, para lo cual:

  • Deberemos dirigir una solicitud como organismo previamente.

  • Deberemos seguir un formato determinado para la generación del CSV.

  • Deberemos proporcionar accesibilidad a un servicio web que se ajuste al protocolo de consulta de documentos

NOTA

Otros lugares donde pueden producirse y validarse CSV son mediante el Portafirmas AGE, que produce códigos CSV durante la firma, y mediante la “suite” INSIDE, que dispone de un sistema para la generación de CSV.

4. REGISTRO ELECTRONICO

El registro electrónico es, por decirlo así, el repositorio de las constancias electrónicas de las comunicaciones electrónicas entre interesados y administraciones. No es más que una base de datos (sea cual sea su forma) que almacena entradas de datos para cada comunicación recibida o enviada por una Administración.

La referencia legal, además de las Leyes 39 y 40/2015, es el BOE.es - BOE-A-2021-5032 Real Decreto 203/2021, de 30 de marzo, por el que se aprueba el Reglamento de actuación y funcionamiento del sector público por medios electrónicos.

¿En qué consiste?

Para la AGE, debe existir un único Registro Electrónico Común, o REC. En el caso de un procedimiento administrativo, integraremos el registro electrónico generalmente para estas funcionalidades:

• Registrar la entrada de solicitudes, desestimientos, recursos y reclamaciones o comunicados de los ciudadanos, generalmente a través de un documento con un formato determinado (formulario) firmado electrónicamente.

• Recuperar un recibo del propio registro con la confirmación del asiento y un localizador, para entregar al ciudadano.

• Registrar las notificaciones, resoluciones, peticiones de subsanación y cualquier comunicación con efectos jurídicos a los interesados.

Como norma general, utilizaremos la aplicación de GEISER tanto para integrar una aplicación con el REC como para integrar las partes del procedimiento que puedan ocurrir de forma presencial en las OAMR.

GEISER

Integraremos nuestra aplicación con el registro electrónico a través de un interfaz de servicios web a través de RED SARA, generalmente con los servicios web proporcionados por GEISER, previamente identificados y autorizados por los gestores del servicio a través de certificados electrónicos.

Para la utilización de GEISER será necesario firmar previamente un convenio, y solicitar dar de alta nuestra aplicación para la tramitación de asientos de registro.

Como norma general añadiremos un asiento de registro, en una oficina (virtual) de registro que debe existir previamente en DIR3, para un determinado identificador de procedimiento administrativo existente en SIA, y dentro de este, sobre un determinado asunto.

De esta manera, nuestra aplicación simula la operación correspondiente que realizaría un funcionario de la Oficina de Asistencia en Materia de Registro (OAMR) manualmente a través del interfaz web de GEISER.

NOTA

La interfaz de servicios web para aplicaciones de GEISER se llama REGECO.

¿Qué relación hay entre SIR, ORVE, GEISER y REC?

Actualmente, existen muchos sistemas o bases de datos de Registro Electrónico. Aunque la normativa indica que es necesario unificar y disponer un solo Registro por Administración, lo cierto es que aún está muy fragmentado. El Registro Electrónico Común de la AGE es la visión unificada de este conjunto de bases de datos de registro, mediante un interfaz común para toda la AGE.

SIR es la plataforma tecnológica que realiza esta visión común, digamos es la capa de integración de los diferentes registros, el sistema de envío de uno a otro y la capa que le da una visión común a todos ellos desde fuera.

Para su acceso y gestión disponemos de dos aplicaciones de usuario final, como son ORVE (con un interfaz muy simplificado cuando las necesidades son pequeñas como una oficina de registro muy pequeña) y GEISER (que permite gestionar de forma completa una OAMR completa así como el acceso a las Unidades Tramitadoras).

¿Qué relación tiene con SIA y DIR3?

En el caso de GEISER, se apoya en SIA (como referencia de los Procedimientos Administrativos) para asociar a qué procedimiento corresponde un asiento, y en DIR3 como directorio de Unidades y Oficinas, para identificar quién es el responsable de ese asiento y a qué Unidad dentro de la Administración debe dirigirlo.

5. Noficaciones electrónicas

Las notificaciones electrónicas son una parte esencial del PAC, normativamente, ya que de no notificar correctamente a los interesados durante el transcurso del procedimiento, podría quedar invalidado o ser objeto de recurso por producirse indefensión.

Las notificaciones antes de la era electrónica en la Administración se producían en papel, mediante un envío postal que se firmaba en la entrega (“datado”) donde quedaba constancia del envío a la dirección correspondiente, así como certificación o no de la entrega y recepción.

En la era electrónica, el procedimiento es similar, aunque para los sujetos no obligados a la actuación electrónica, existe la opción de solicitar notificaciones postales.

Afortunadamente, el servicio común de notificación (Notifica) permite abstraerse de estos detalles.

NOTIFICA

¿En qué consiste? Notifica es una solución que puede accederse directamente como solución en la nube o como servicio integrable en nuestra aplicación.

Como solución en la nube, simplemente deberemos de dar de alta a los usuarios de las Unidades correspondientes en la aplicación, y podrán a través de un interfaz web proceder a la realización de notificaciones electrónicas. Hay varios métodos de notificación:

• Mediante comparecencia en sede electrónica, propia o la del PAG.

• Mediante Dirección Electrónica Habilitada (DEH) o Direción Electrónica Habilitada Única (DEHú).

• O mediante notificaciones en formato papel (que tienen coste y requieren la firma de un convenio).

Notifica permite gestionar COMUNICACIONES (no asociadas a un procedimiento administrativo), NOTIFICACIONES (asociadas a un procedimiento administrativo dado de alta en SIA) o ambas.

También dispone de servicios web para que nuestra aplicación pueda realizar envíos mediante alguno de los métodos anteriores, y reciba las respuestas de la notificación (datado).

¿Cómo se utiliza?

Si optamos por la solución Integrada, a través de un conjunto de servicios web con los que nos integraremos a través de red SARA.

6. Pasarelas de pagos

Las pasarelas de pago serán necesarias únicamente cuando se mencionen en el enunciado algún tipo de tasas, o se trate de un sistema de pago de penalizaciones o impuestos.

¿En qué consiste?

La pasarela de pagos de la AEAT permite el pago de tasas para trámites de la AGE.

Permite la identificación del ciudadano mediante Cl@ve, realizar los pagos a través de la pasarela, y a la Administración, realizar las consultas de los pagos realizados, comprobar las referencias de los pagos realizados y consultar los datos de los pagos producidos en un periodo de tiempo.

¿Cómo se utiliza?

Es necesario darse de alta en el servicio, y cumplimentar la parte administrativa para dar de alta las entidades bancarias, etc.

Dispone de una interfaz web administrativa por red SARA y luego los servicios web para acceder a la información de la pasarela de pagos.

7. Gestión de documento y expediente electrónico

El documento y expediente electrónicos forma parte de la normativa de interoperabilidad (ENI), por un lado, y por otro, da plena validez jurídica a los mismos en cuanto a normativa.

Será extraordinariamente raro el sistema de la Administración que no incluya algún tipo de gestión documental, así que estos sistemas formarán parte casi obligatoria de cualquier sistema que podamos concebir.

Cuando hablamos de la normativa de interoperabilidad, de los formatos admitidos, etc, tenemos que tener en cuenta que la normativa no está hablando de un formato específico en el cual estos documentos estarán almacenados en ningún sistema concreto, si no de los formatos de intercambio y presentación que debemos emplear para que el sistema sea interoperable con otros y accesible a los ciudadanos.

Esto significa que internamente podremos, en nuestro sistema, almacenar los expedientes y documentos como nos apetezca, pero que deberemos implementar una interfaz para que se entreguen en los formatos interoperables que corresponda.

Por ejemplo:

• Podemos hacer un formulario web que recoja la información de una solicitud, guardarla de forma temporal en una o varias tablas de un servidor de SGBDR, con los campos desglosados, luego convertirlos a XML que el solicitante firmará con Autofirma para confeccionar un documento XSIG que almacenaremos en un sistema de ficheros.

• Este documento se incorporará a una carpeta de expediente y luego otro proceso descompondrá y validará el documento XML, generando metadatos en una base de datos, añadiendo información adicional de gestión y lo serializará a un interfaz REST de un gestor documental en JSON.

• En este caso, deberemos tener un módulo que permita al ciudadano visualizar los datos de su expediente y los documentos que pueda visualizar, lo que proporcionaremos por un interfaz web en HTML5, además de otro interfaz para que puedan ser consultados por carpeta ciudadana.

• Además, tendremos otro interfaz de interoperabilidad que permita exportar los datos de documento y expediente electrónico a formato INSIDE a través de G-INSIDE, para su consumo por parte de otra Administración o para remisión a Justicia en caso de recurso administrativo.

• Además, tendremos otros procesos internos que permitan convertir los formatos internos a PDF para su consulta más cómoda y descarga, con un código CSV.

Por tanto, la interoperabilidad es una capa transversal a la aplicación ya que afecta:

• Al modelo de datos, ya que no podremos presentar la información que no tenemos.

• A la capa de negocio, que tendrá que proporcionar las conversiones y los mecanismos necesarios para la interpretación de la información en cada momento del expediente.

• A la capa de presentación, que tendrá que mostrar los datos en formatos reconocidos e interoperables de acuerdo al ENI en los casos necesarios.

La normativa exige por tanto, proporcionar unos formatos determinados. ¿Qué normativa?:

La norma técnica de Expediente Electrónico y documento electrónico recogidas por el Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica.

Hay que hacer notar que la normativa de interoperabilidad obliga a unos formatos para el intercambio de información, por lo que es indistinto el formato interno que utilicemos.

Generalmente, el formato de intercambio para los ficheros será en XML, conforme a un XSD (interoperabilidad semántica), que contiene:

• Datos cualesquiera en un formato intercambiable (base64).

• Descripción de los datos intercambiados (metadatos).

• Firma electrónica (y/o CSV).

En cuanto al expediente electrónico, se trata de un contenedor para los documentos, agrupados, cuya estructura corresponde con:

• Descripción de la estructura y contenido del expediente.

• Metadatos del expediente.

• Índice del expediente.

• Índice del contenido del expediente.

• Firma electrónica del expediente.

Los expedientes pueden anidarse, y enlazar a otros expedientes.

INSIDE

¿En qué consiste?

Se trata de una “suite” de productos presentados en forma de aplicación instalable, servicios web integrables en una aplicación desarrollada por nosotros, o como un servicio en Nube. La suite cumple todos los formatos especificados en el ENI, además dispone también de algunas funcionalidades como generación y visualización de códigos CSV, generación de firmas y sellado electrónico, búsquedas de expedientes, almacenamiento de datos, remisión a Justicia y a otras Administraciones, etc.

En general, utilizaremos INSIDE en un ejercicio en el que tengamos necesidad de gestionar información de expedientes, preferentemente en la nube (para evitar buscar soluciones adicionales o desarrollar lo que ya está desarrollado) a menos que necesitemos funcionalidades específicas que no dispongamos.

¿Qué relación hay entre INSIDE y un gestor documental?

Hay que tener en cuenta que INSIDE se pronuncia sobre el formato, no sobre el contenido. Es decir, no nos permite tratar el contenido de los documentos (que trata como información binaria en base64). Por tanto, si necesitamos analizar documentos de diversa índole, como PDF, word, excel, etc. o bien realizar una gestión documental completa, con flujos de aprobación, indexación, clasificación en temáticas, taxonomía, conversión de documentos, gestión de la visibilidad, publicación, edición, etc, necesitaremos incluir un gestor documental completo para esta funcionalidad.

Podremos integrar el gestor documental con INSIDE, mediante una funcionalidad que incorpore y recupere los documentos al expediente, utilizando los servicios web de INSIDE.

INSIDE NO ES UN GESTOR DOCUMENTAL. Ofrece la capa de interoperabilidad, algo de seguridad, firma y gestión de expedientes.

Se integrará además con el gestor de flujos de trabajo (workflow) para las operaciones que se realizan en el documento electrónico y expediente:

Si no deseamos almacenar nuestros expedientes en la nube, o en el formato de INSIDE por algún motivo, disponemos de librerías como G-INSIDE que nos permiten hacer la conversión al vuelo de nuestro formato interno al formato ENI.

8.Inventario de procedimientos administrativos: SIA.

SIA se trata de un catálogo centralizado de procedimientos administrativos. Permite proporcionar información acerca de los procedimientos administrativos que dispone un organismo y de esta manera, mantener esta información en el Punto de Acceso General.

Generalmente no nos integraremos con este servicio, simplemente actualizaremos los datos para que el catálogo esté correctamente actualizado.

Actualmente, la información de SIA se utiliza en los apuntes de registro electrónico (para indicar un documento a que procedimiento corresponde, aunque es opcional) y también es utilizado por ACCEDA, que proporciona el enlace del formulario de entrada y la descripción del procedimiento al catálogo central.

9.Inventario de unidades y organismos: DIR3.

DIR3 es similar en cuanto a que es un catálogo central que mantiene la estructura organizativa de las Administraciones públicas, cuestión necesaria para varios aspectos, como la identificación de unidades y oficinas, remisión de documentos a unidades, a través de REC, autenticación y autorización, etc.

Generalmente lo utilizaremos para consultar la estructura organizativa en cuanto a que tengamos que integrarnos con personal de otros organismos de la Administración Pública, o remitir documentos a través de registro.

10. Consulta de expedientes: PAG y Carpeta ciudadana.

La carpeta ciudadana se encuentra en el Punto de Acceso General, y permite, para todos los organismos suscritos, que el sistema de Carpeta Ciudadana consulte al endpoint de servicios que hayamos especificado al suscribirnos al servicio, tanto de los expedientes, notificaciones y documentos que tengamos asociados a un identificador (NIF/NIE).

Nos suscribimos al servicio indicando una dirección URL de consulta mediante servicios web para que el sistema, que nos habrá validado previamente con Cl@ve y tendrá lógicamente nuestro NIF/NIE, realice una serie de consultas en nuestro nombre, a todos los organismos suscritos al servicio (no tienen porqué ser todos, la suscripción es voluntaria).

Por ejemplo, una vez que entramos en el servicio, en paralelo, se realizan consultas contra los “endpoints” de los organismos suscritos:

Para habilitar nuestro sistema para que muestre esta información en Carpeta Ciudadana, simplemente tendremos que implementar el “endpoint” de servicios en nuestra infraestructura o aplicación: NOTAS sobre arquitecturas:

● Si tenemos un sistema centralizado de expedientes, implementaremos un servicio web que consulte este servicio, que supondremos que ya existirá, y nuestro sistema se integrará a su vez con este sistema para incluir los expedientes necesarios.

● Si nuestro sistema a construir se encargara de la gestión de sus propios expedientes, implementaremos un “endpoint” de servicios con el sistema intermedio o con Carpeta Ciudadana.

● Si utilizamos INSIDE como gestor de expedientes, generalmente la implementación cambiará, pero tendremos que derivar de todas maneras la consulta a INSIDE para los expedientes que allí se almacenen, con lo que no cambia sustancialmente la arquitectura.

● Si utilizamos ACCEDA para la gestión global de procedimientos administrativos, ya dispone de una opción para integrarse con Carpeta Ciudadana.

En este caso, seremos accedidos por este servicio a través de la Red SARA.

12. Intercambio de certificaciones y verificación de datos: PID-SVD.

Denominaremos certificaciones en vez de certificados para no llamar a error con los certificados electrónicos destinados a la identificación y firma.

Utilizaremos esta plataforma, la de intermediación de datos/verificación de datos, para obtener y proporcionar tanto certificaciones de las que tengamos potestad de otorgar como para la consulta y verificación de datos de los que tengamos consentimiento para hacerlo.

Esta plataforma nos permite evitar requerir aportes documentales por un lado, como la verificación de la identidad por ejemplo (evitando la típica copia del DNI), estar al corriente de pagos con a AEAT, Seguridad Social, etc.

Existen varios servicios a los que podemos suscribirnos. Los más habituales son:

• Verificación de datos de Identidad (como los que incluye el DNI): DGP

• Verificación de datos de residencia: en base a los datos del Padrón. (INE)

• Prestación de desempleo (SPEE-INEM)

• Títulos oficiales (Ministerio de Educación)

• Estar al corriente de pagos y de alta en la Seguridad Social (TGSS)

• Al corriente de pagos con la AEAT.

• Datos catastrales (Catastro)

• Nivel y grado de dependencia (IMSERSO)

• Prestaciones públicas actuales (INSS)

• Nacimiento, matrimonio, defunción, antecedentes penales (Ministerio de Justicia)

Estos servicios serán accesibles a través de la RED SARA, y requieren lógicamente un instrumento jurídico para su consumo (firma de convenio).

Para su utilización, debemos integrarnos con ellos desarrollando un “endpoint” de servicios para su consumo. Adicionalmente, si se menciona en el enunciado que podremos emitir algún tipo de “certificado”, podremos ofrecerlo a través de la PID.

13. Gestión de procedimientos electrónicos y sede electrónica: ACCEDA.

Acceda es una solución tanto en la nube como para la instalación en local de sede electrónica, tramitación, etc.

Será una opción a considerar si entendemos que no tenemos sede electrónica desarrollada y deberemos disponer de una.

También podremos reutilizar alguna parte de acceda con precauciones, tiene las dos opciones: utilizar como servicio en nube, o instalable a través del código fuente en nuestros servidores.

La parte menos desarrollada de ACCEDA es quizá el CMS, pero por otro lado, presenta un gestor de flujos de trabajos muy adaptado al procedimiento administrativo, y presenta de salida una fuerte integración con los servicios comunes como INSIDE, GEISER, NOTIFICA, FIRE, CLAVE, etc, lo que permite a un organismo un alto grado de cumplimiento en materia de administración electrónica a un coste relativamente bajo.

Si queremos realizar alguna adaptación más allá del “estándar” de acceda, la única opción es la reutilización del código, que se puede descargar de Forja CTT.