La transformación digital de la Administración Pública no consiste, como a veces se simplifica, en sustituir el papel por el PDF, sino en repensar de raíz el modo en que un procedimiento administrativo nace, se tramita y se conserva. El expediente electrónico es la unidad sobre la que se asienta toda esa transformación: es el conjunto ordenado de documentos y actuaciones que sirven de antecedente y fundamento a la resolución administrativa, así como las diligencias encaminadas a ejecutarla, y su gestión íntegramente electrónica exige la concurrencia de tres elementos que, aunque suelen estudiarse por separado, en la práctica de un Ayuntamiento funcionan siempre entrelazados. El primero es el marco normativo y técnico que define qué es un documento electrónico, qué es un expediente electrónico y cómo deben estructurarse para ser válidos, interoperables y conservables a largo plazo, marco que en España se concreta fundamentalmente en el Esquema Nacional de Interoperabilidad. El segundo es la herramienta que materializa ese marco en el día a día de cualquier oficina pública: los sistemas de gestión documental y los motores de flujos de trabajo o BPM, que son los que efectivamente capturan, clasifican, enrutan y archivan los documentos conforme avanza la tramitación. Y el tercero, sin el cual los dos anteriores quedarían confinados dentro de las fronteras de un único organismo, es la arquitectura de servicios web que permite que ese expediente, o partes de él, viajen de forma normalizada entre sistemas heterogéneos de distintas administraciones, haciendo posible en la práctica el principio de que el ciudadano no tenga que volver a aportar un documento que ya obra en poder de cualquier Administración.
A lo largo de este tema se recorrerá el ciclo de vida completo de un expediente electrónico, desde su entrada por el registro hasta su archivo definitivo, deteniéndonos en cada una de las piezas normativas y tecnológicas que lo hacen posible, para terminar mostrando cómo la interoperabilidad técnica basada en servicios web es, en última instancia, la infraestructura que convierte en realidad operativa un principio que de otro modo quedaría reducido a una declaración de buenas intenciones en la ley.
El punto de partida obligado es entender qué exige la normativa para que un documento y un expediente sean considerados electrónicos en sentido pleno, no como una mera digitalización superficial de un trámite que sigue siendo en esencia analógico. El Esquema Nacional de Interoperabilidad, aprobado mediante Real Decreto y desarrollado a través de sucesivas Normas Técnicas de Interoperabilidad, establece el conjunto de criterios y recomendaciones de seguridad, conservación y normalización que deben seguir las Administraciones Públicas españolas para garantizar el ejercicio de derechos y el cumplimiento de deberes a través del acceso electrónico a los servicios públicos. Su razón de ser es precisamente combatir la fragmentación: sin un esquema común, cada Administración podría definir sus propios formatos, sus propias estructuras de metadatos y sus propios criterios de firma, de modo que un expediente perfectamente válido para un Ayuntamiento resultaría ilegible o inválido para una Comunidad Autónoma o para la Administración General del Estado.
Un documento electrónico, conforme a este marco, no es simplemente un archivo digital, sino que se compone de tres elementos indisociables: el contenido propiamente dicho, expresado normalmente en un formato normalizado y duradero como el PDF en su variante de archivo; la firma electrónica que garantiza su autenticidad e integridad, vinculando el documento a su autor de forma que cualquier alteración posterior sea detectable; y los metadatos, esto es, la información estructurada que describe el propio documento, como su fecha, su órgano emisor, su tipología documental o el procedimiento al que pertenece, y que resulta imprescindible para poder clasificarlo, buscarlo y, más adelante, conservarlo o eliminarlo conforme a las políticas de archivo correspondientes. El expediente electrónico, a su vez, no es un mero contenedor de documentos sueltos, sino que requiere un índice electrónico firmado que relacione de forma ordenada todos los documentos que lo componen, garantizando su integridad y permitiendo, en caso de que el expediente deba remitirse a otro órgano u Administración, verificar que se ha recibido completo y sin alteraciones. Esta exigencia de foliado e indexado electrónico es, en realidad, la traducción digital de lo que tradicionalmente se hacía con el expediente en papel cuando se numeraban sus folios; lo que cambia es que ahora esa garantía de completitud e integridad la proporciona la firma electrónica sobre el propio índice, no la imposibilidad física de extraer una hoja sin que se note.
A todo ello se añade la obligación de conservación a largo plazo, que en el ámbito electrónico plantea un reto específico que no existía con el papel: la obsolescencia tecnológica de los formatos y de los soportes de almacenamiento. Un documento en papel conservado en un archivo histórico sigue siendo legible siglos después sin más que conservar el propio papel, pero un fichero en un formato propietario corre el riesgo de quedar inaccesible si dentro de veinte años ya no existe software capaz de interpretarlo. De ahí que el Esquema Nacional de Interoperabilidad incorpore una Norma Técnica específica sobre Política de Gestión de Documentos Electrónicos, que obliga a las Administraciones a definir estrategias de preservación digital, recomendando formatos abiertos y estandarizados precisamente por su mayor garantía de durabilidad frente a formatos propietarios sujetos a los vaivenes comerciales de un fabricante concreto.
Todo este marco normativo sería pura teoría si no existiera una herramienta capaz de aplicarlo de forma sistemática a cada uno de los miles de expedientes que un Ayuntamiento tramita diariamente, y esa herramienta es el sistema de gestión documental, frecuentemente denominado gestor de contenidos empresarial o, en terminología más amplia, documática. Un sistema de gestión documental es, en esencia, el repositorio centralizado donde se almacenan, clasifican y custodian todos los documentos electrónicos de la organización, proporcionando funcionalidades que van mucho más allá de lo que ofrecería un simple sistema de ficheros: control de versiones, que permite recuperar estados anteriores de un documento y conocer quién modificó qué y cuándo; control de acceso granular, que determina qué usuarios o qué unidades administrativas pueden ver, editar o firmar cada documento en función de su rol; y, de forma muy especialmente relevante para el sector público, la aplicación de cuadros de clasificación y calendarios de conservación que determinan durante cuánto tiempo debe conservarse cada tipología documental antes de poder proceder a su eliminación o a su transferencia al archivo histórico.
Sobre ese repositorio documental se construyen los motores de flujos de trabajo o BPM, acrónimo de Business Process Management, que son los que efectivamente modelan y automatizan el recorrido que sigue un expediente a través de las distintas unidades administrativas que intervienen en su tramitación. Un motor BPM permite definir, normalmente mediante una notación gráfica estandarizada como BPMN, las distintas tareas, decisiones y bifurcaciones de un procedimiento administrativo: qué unidad debe informar primero, en qué condiciones el expediente debe derivarse a un informe jurídico, qué plazos máximos tiene cada tarea antes de generar una alerta de retraso, y quién debe firmar la resolución final. La gran ventaja de modelar los procedimientos de esta manera, frente al tradicional reparto manual de expedientes en papel entre mesas y dependencias, es que el propio sistema garantiza que ningún expediente quede olvidado en un cajón, que los plazos administrativos se controlen de forma automática, y que en todo momento pueda saberse con precisión en qué fase de la tramitación se encuentra cualquier expediente, lo cual resulta además imprescindible para satisfacer el derecho del ciudadano a conocer el estado de tramitación de los procedimientos en los que es interesado.
El ciclo de vida completo de un expediente puede ahora describirse con precisión apoyándose en estas dos piezas. Todo comienza en el registro electrónico, donde una solicitud presentada por un ciudadano, ya sea a través de la sede electrónica del Ayuntamiento o de forma presencial con posterior digitalización, genera un asiento registral con su correspondiente sello de fecha y hora y su justificante de presentación. A partir de ese momento, el sistema de gestión documental crea el expediente electrónico, le asigna sus metadatos iniciales conforme al cuadro de clasificación corporativo, y el motor de flujos de trabajo lo inserta en el procedimiento correspondiente, derivándolo automáticamente a la primera unidad responsable de su tramitación. A lo largo de la instrucción, cada nueva actuación administrativa, ya sea un informe técnico, un requerimiento de subsanación o una notificación al interesado, se incorpora al expediente como un nuevo documento que pasa a formar parte del índice electrónico firmado, sin que en ningún momento se rompa la trazabilidad ni la integridad del conjunto. Cuando finalmente se dicta la resolución, esta se firma electrónicamente y se incorpora al expediente, que pasa entonces a un estado de finalización, tras el cual, transcurridos los plazos administrativos pertinentes, el expediente es archivado conforme a la política de conservación que le corresponda según su tipología, pudiendo terminar, según los casos, en una eliminación controlada una vez superado su plazo de conservación, o en una transferencia al archivo histórico si se le reconoce valor documental permanente. Este recorrido íntegro, desde el registro hasta el archivo, es exactamente lo que tanto el Esquema Nacional de Interoperabilidad como los sistemas de documática y BPM están diseñados para sostener de forma coherente y trazable.
Todo lo descrito hasta ahora funciona razonablemente bien mientras el expediente permanece dentro de las fronteras de un único sistema y de una única Administración. El problema surge, y es un problema que un Ayuntamiento afronta de forma constante, cuando ese expediente necesita relacionarse con sistemas externos: consultar si un ciudadano está al corriente de sus obligaciones con la Agencia Tributaria, verificar un dato de empadronamiento que ya consta en otro organismo, o remitir un expediente completo a un órgano de otra Administración que deba resolver sobre él. Es precisamente en este punto donde la arquitectura de servicios web deja de ser una cuestión meramente técnica de programadores y se convierte en la pieza que permite cumplir, en la práctica, uno de los principios más reivindicados por la ciudadanía: el derecho a no aportar documentos que ya obran en poder de cualquier Administración Pública.
Un servicio web, en términos generales, es un mecanismo de comunicación entre aplicaciones distintas a través de la red, diseñado para que sistemas heterogéneos, construidos con tecnologías y lenguajes de programación diferentes, puedan intercambiar información de forma normalizada sin necesidad de conocer los detalles internos de implementación del otro extremo. Históricamente, el primer gran estándar para construir estos servicios fue SOAP, acrónimo de Simple Object Access Protocol, un protocolo basado íntegramente en XML que define con un detalle muy estricto la estructura del mensaje intercambiado, organizado siempre en un sobre o envelope que contiene una cabecera opcional con metainformación y un cuerpo con la operación y los datos propiamente dichos. SOAP se apoya habitualmente en un documento de descripción denominado WSDL, siglas de Web Services Description Language, también en formato XML, que actúa como un contrato formal: especifica de manera exhaustiva qué operaciones ofrece el servicio, qué parámetros espera cada una de ellas, qué tipos de datos utiliza y qué estructura tendrá la respuesta, permitiendo generar de forma automática el código cliente necesario para invocar el servicio. Esta rigidez del contrato es, a la vez, la mayor virtud y la mayor limitación de SOAP: por un lado ofrece una enorme robustez y predictibilidad, así como extensiones estandarizadas para seguridad avanzada como WS-Security, lo cual explica por qué sigue siendo el estándar elegido en determinadas plataformas de interoperabilidad del sector público español que requieren garantías formales muy estrictas, como ocurre en algunos servicios de la Plataforma de Intermediación de Datos. Por otro lado, esa misma rigidez conlleva mensajes más pesados, un mayor consumo de ancho de banda y de procesamiento, y una curva de aprendizaje y un acoplamiento entre cliente y servidor sensiblemente mayores que los de su alternativa más moderna.
Esa alternativa es REST, acrónimo de Representational State Transfer, que no es en rigor un protocolo cerrado como SOAP, sino un estilo arquitectónico que aprovecha directamente las capacidades ya existentes del propio protocolo HTTP en lugar de definir una capa adicional sobre él. En una arquitectura REST, cada recurso de información, por ejemplo un expediente, un ciudadano o un documento concreto, se identifica mediante una URI propia, y las operaciones sobre ese recurso se expresan utilizando los verbos HTTP estándar con una semántica clara y consistente: GET para consultar o recuperar un recurso sin producir ningún efecto colateral en el servidor, POST para crear un nuevo recurso, PUT para actualizar por completo un recurso existente, PATCH para modificarlo parcialmente, y DELETE para eliminarlo. Esta correspondencia tan directa entre la operación deseada y el verbo HTTP empleado simplifica enormemente tanto el diseño como la comprensión del servicio por parte de cualquier desarrollador externo, sin necesidad de consultar un contrato WSDL previo tan detallado. A esto se suma que las respuestas de un servicio REST incorporan los códigos de estado HTTP estandarizados, que informan de manera inmediata sobre el resultado de la operación sin necesidad de inspeccionar el cuerpo completo de la respuesta: un código 200 indica que la operación se completó correctamente, un 201 que se ha creado un nuevo recurso, un 400 que la solicitud del cliente contenía algún error, un 401 o un 403 que existe un problema de autenticación o de autorización, un 404 que el recurso solicitado no existe, y un 500 que se ha producido un error interno en el servidor. En cuanto al formato de los datos intercambiados, mientras que SOAP exige siempre XML, REST admite en principio cualquier formato, aunque en la práctica casi totalidad de los servicios REST actuales emplean JSON, JavaScript Object Notation, por tratarse de una notación mucho más ligera, más legible y de procesamiento sensiblemente más rápido que el XML, lo cual contribuye decisivamente a la menor sobrecarga característica de las arquitecturas REST frente a SOAP. Otra característica esencial del estilo REST es la ausencia de estado, lo que en terminología técnica se denomina statelessness: cada petición debe contener toda la información necesaria para ser procesada de forma independiente, sin que el servidor conserve memoria del estado de interacciones anteriores con ese mismo cliente, lo cual simplifica enormemente el escalado horizontal del servicio, ya que cualquier instancia del servidor puede atender cualquier petición entrante sin necesidad de compartir sesión con las demás.
Esta infraestructura de servicios web, sea bajo el paradigma SOAP o bajo el paradigma REST, es precisamente lo que permite materializar de forma efectiva el principio de interoperabilidad que defendía el Esquema Nacional de Interoperabilidad como mero marco normativo. Cuando un ciudadano presenta una solicitud en la sede electrónica de un Ayuntamiento y autoriza la consulta de sus datos, el sistema municipal no exige al ciudadano que aporte un certificado de empadronamiento o un certificado de estar al corriente de obligaciones tributarias en papel, sino que invoca, a través de un servicio web, a la Plataforma de Intermediación de Datos, que actúa como nodo central de interoperabilidad entre las distintas Administraciones españolas, permitiendo que el sistema municipal obtenga esa información directamente del organismo que la custodia de origen, sin intervención manual del ciudadano ni del propio funcionario. Esta consulta se ejecuta normalmente mediante una petición HTTP a un servicio expuesto por dicha plataforma, identificando con precisión qué dato se solicita y bajo qué consentimiento o habilitación legal, recibiendo como respuesta una estructura de datos normalizada, ya sea en XML bajo SOAP o en JSON bajo REST según el servicio concreto de que se trate, que el sistema municipal incorpora automáticamente al expediente electrónico que se está tramitando. De este modo se cierra el círculo: el marco normativo del Esquema Nacional de Interoperabilidad define el qué y el porqué de la interoperabilidad, los sistemas de gestión documental y los motores de flujos de trabajo organizan el expediente al que esos datos deben incorporarse, y la arquitectura de servicios web proporciona el cómo, el mecanismo técnico concreto que hace posible que esa promesa legal de no pedir al ciudadano papeles que la Administración ya tiene se traduzca en una consulta automatizada que se ejecuta en fracciones de segundo.
El recorrido realizado a lo largo de este tema demuestra que la gestión moderna del expediente electrónico en un Ayuntamiento no puede entenderse como la suma de tres compartimentos estancos, sino como un continuo en el que cada pieza resulta indispensable para que las otras dos cumplan su función. El Esquema Nacional de Interoperabilidad proporciona el lenguaje común y las garantías jurídicas de autenticidad, integridad y conservación que un documento y un expediente electrónico deben satisfacer para tener pleno valor administrativo; los sistemas de gestión documental y los motores de flujos de trabajo trasladan ese marco normativo a la operativa diaria, automatizando la captura, la clasificación, el enrutamiento entre unidades y el archivo final de cada expediente conforme avanza su tramitación; y la arquitectura de servicios web, ya sea bajo el paradigma más formal y robusto de SOAP o bajo el paradigma más ligero y flexible de REST, constituye la infraestructura técnica concreta que permite que toda esa información viaje de forma normalizada entre sistemas heterogéneos de distintas Administraciones.
Es esta última pieza, en definitiva, la que transforma un principio legal en una realidad tangible para el ciudadano: cuando este presenta una solicitud sin tener que acompañarla de certificados que otra Administración ya posee, lo que está ocurriendo detrás de esa aparente sencillez es una petición HTTP perfectamente estructurada que recupera un dato en tiempo real desde el sistema que lo custodia. Comprender esta cadena completa, desde el fundamento normativo hasta el detalle del protocolo de comunicación, es lo que permite a un técnico de Administración Local no solo operar estos sistemas, sino participar con criterio en su diseño, su mantenimiento y su mejora continua, al servicio de una Administración cada vez más ágil, más interoperable y más respetuosa con el tiempo y los derechos de la ciudadanía.