1. INTRODUCCIÓN Y ALCANCE DEL ECOSISTEMA ASISTENCIAL

Los sistemas de información asistenciales son el conjunto de aplicaciones, servicios, repositorios, catálogos y mecanismos de integración que sostienen la actividad clínica y la gestión directamente asociada a la atención sanitaria. Su finalidad no es simplemente sustituir el papel por pantallas: deben proporcionar información fiable en el punto de atención, preservar la continuidad entre niveles, evitar duplicidades, mejorar la seguridad del paciente y dejar trazabilidad suficiente para la gestión, la evaluación, la investigación y el ejercicio de derechos.

En el Servicio Andaluz de Salud, el elemento vertebrador es Diraya, utilizado como soporte de la historia clínica electrónica. La documentación oficial del SAS lo presenta como un sistema integrado que reúne la información de salud de las personas atendidas para que esté disponible cuando y donde sea necesaria, y que además sirve para la gestión del sistema sanitario. Esta formulación es importante: Diraya no equivale a una única aplicación monolítica, sino a un ecosistema de módulos clínicos, de gestión e integración que comparten información y se apoyan en servicios corporativos.

El tema debe estudiarse desde cuatro planos complementarios. El plano funcional analiza qué procesos cubre cada solución: identificación, citación, registro clínico, prescripción, cuidados, pruebas diagnósticas, urgencias, hospitalización, demanda quirúrgica o acceso ciudadano. El plano informacional se ocupa de la identidad del paciente, la estructura de los episodios, documentos, observaciones, terminologías y catálogos. El plano técnico aborda integración, mensajería, imagen médica, disponibilidad, auditoría y seguridad. Finalmente, el plano organizativo determina quién gobierna el dato, quién autoriza accesos, cómo se despliegan cambios y cómo se presta soporte a sistemas críticos.

La criticidad de estos sistemas deriva de que una indisponibilidad o un dato erróneo puede repercutir en decisiones asistenciales. Por eso deben diseñarse con principios de calidad del dato, identificación inequívoca, mínimo privilegio, registro de accesos, resiliencia, continuidad y recuperación. El técnico TFA-STI interviene en la administración funcional y técnica, la integración de sistemas, la gestión de identidades y perfiles, la monitorización, el análisis de incidencias, las pruebas de regresión, la explotación autorizada de datos y la coordinación con profesionales clínicos y unidades de gestión.

El ecosistema también se proyecta fuera del puesto profesional. ClicSalud+ y la App Salud Andalucía permiten a la ciudadanía consultar información y realizar trámites; la Historia Clínica Digital del Sistema Nacional de Salud facilita el acceso a informes clínicos relevantes entre comunidades autónomas; la receta electrónica interoperable permite la dispensación fuera del territorio de origen; y el sistema regional de imagen médica hace posible consultar estudios e informes desde distintos centros. La visión correcta es, por tanto, la de una plataforma sanitaria longitudinal, multicanal e interoperable, no la de una colección aislada de programas.

2. IDENTIFICACIÓN DE LA PERSONA: BDU, GADU Y NHUSA

2.1. Identidad clínica y administrativa

La continuidad asistencial exige identificar correctamente a la persona antes de asociarle una cita, un episodio, una prescripción, una imagen o un resultado analítico. La identidad administrativa actúa como raíz del resto de la información. Un error de identificación puede producir duplicidades de historia, mezcla de información entre personas o pérdida de continuidad. Por ello, la gestión de identidades incluye altas, modificaciones, fusiones controladas, tratamiento de duplicados y procedimientos de rectificación con evidencias y autorización.

En el entorno del SAS, BDU/GADU suministra a cada ciudadano un Número Único de Historia de Salud de Andalucía y mantiene información administrativa relevante, incluida la adscripción al profesional de atención primaria. El identificador único permite relacionar los datos distribuidos en diferentes aplicaciones. La Resolución 0068/18 de creación de la Base Poblacional de Salud establece expresamente que la conexión entre sistemas se realizará mediante el identificador único de la BDU.

2.2. NHUSA como clave de vinculación

El NHUSA no debe confundirse con el número de un episodio hospitalario, una cita o una tarjeta física. Es un identificador longitudinal de la persona en la historia de salud andaluza. Los episodios y actos asistenciales tienen sus propios identificadores y se asocian al ciudadano mediante relaciones controladas. Esta separación permite representar múltiples ingresos, consultas, pruebas o prescripciones sin perder la unidad de la historia.

En una integración, la regla de oro es no utilizar como clave clínica principal un dato mutable o no universal, como el teléfono, el domicilio o incluso un documento de identidad que puede no existir, cambiar o contener errores. Los motores de integración pueden transportar varios identificadores, pero el sistema receptor debe aplicar reglas de correspondencia y validación. La coincidencia únicamente por nombre y fecha de nacimiento no ofrece garantías suficientes para una asociación automática irreversible.

2.3. Calidad del dato maestro

La calidad de los datos maestros comprende exactitud, completitud, coherencia, unicidad, vigencia y trazabilidad. Un dato puede ser sintácticamente válido y, sin embargo, ser clínicamente inútil: por ejemplo, un domicilio antiguo puede impedir una comunicación; un profesional adscrito incorrectamente puede alterar la agenda; y una fecha de nacimiento errónea puede afectar a reglas de edad. Los controles deben combinar validaciones automáticas, fuentes autoritativas y procedimientos de revisión humana.

Desde el punto de vista técnico, conviene distinguir el dato maestro de sus copias operativas. Un módulo puede mantener una caché o réplica para rendimiento, pero la fuente responsable debe estar identificada. Cuando se modifica un dato maestro, las integraciones deben propagar el cambio de forma segura e idempotente, evitando que un mensaje repetido genere efectos duplicados. También deben existir mecanismos para detectar colas detenidas, errores de transformación y discrepancias entre sistemas.

3. DIRAYA Y LA HISTORIA CLÍNICA ELECTRÓNICA COMPARTIDA

3.1. Definición oficial y principios

Diraya es el sistema utilizado por el SAS como soporte de la historia clínica electrónica. Integra la información de salud de las personas atendidas para hacerla accesible en el lugar y momento necesarios y sirve también para la gestión del sistema sanitario. Esta definición contiene los tres principios que deben memorizarse: longitudinalidad, disponibilidad asistencial y gestión integrada.

La historia clínica electrónica no es una reproducción literal del expediente en papel. Estructura información en problemas de salud, antecedentes, alergias, contactos, episodios, órdenes, resultados, medicación, informes y planes de cuidados. Parte de la información es estructurada y susceptible de explotación; otra parte se conserva como narrativa clínica o documento. La combinación de ambos tipos es necesaria: la estructura permite alertas y análisis, mientras que la narrativa conserva matices clínicos difíciles de codificar.

3.2. Registro único y reutilización controlada

El principio de registrar una vez y reutilizar reduce errores y carga administrativa, pero no significa copiar indiscriminadamente. Un dato debe tener contexto, autor, fecha, estado y procedencia. Por ejemplo, un antecedente confirmado no es equivalente a una sospecha diagnóstica; una medicación prescrita no implica que haya sido dispensada o administrada; y un resultado preliminar no tiene la misma validez que uno verificado. Los módulos deben conservar esos estados y las transiciones que los producen.

La reutilización también exige gobernanza semántica. Si dos módulos usan códigos distintos para el mismo concepto, la integración puede transmitir datos pero no garantizar que se interpreten igual. Por eso son relevantes los catálogos corporativos, las terminologías clínicas y los perfiles de integración. La interoperabilidad técnica sin interoperabilidad semántica puede generar una apariencia engañosa de continuidad.

3.3. Episodios, documentos y observaciones

Un episodio agrupa actividad relacionada con un proceso asistencial en un ámbito y periodo determinados. Un documento clínico presenta información con autoría, contexto, integridad y vocación de persistencia, como un informe de alta. Una observación representa un dato clínico concreto, como una tensión arterial o un resultado de laboratorio. Esta distinción es esencial para diseñar interfaces y repositorios: no todo debe viajar como documento completo ni todo puede reducirse a un valor aislado.

Los sistemas deben permitir rectificación sin borrar indebidamente la trazabilidad. En documentación clínica, la corrección suele implementarse mediante versiones, anulaciones justificadas o adendas, preservando el contenido previo cuando sea necesario para acreditar qué información estuvo disponible en cada momento. El objetivo no es impedir la corrección, sino evitar modificaciones opacas.

3.4. Valor asistencial

El valor de Diraya se manifiesta cuando un profesional puede conocer alergias, antecedentes, medicación, informes y resultados producidos en otro punto del sistema. Esa disponibilidad reduce repetición de pruebas y mejora la coordinación, pero no elimina la responsabilidad profesional de verificar la actualidad y pertinencia de la información. Una historia extensa puede contener datos obsoletos, duplicados o pendientes de validación; el diseño debe ayudar a priorizar, filtrar y mostrar procedencia.

4. ESTACIONES Y MÓDULOS ASISTENCIALES DE DIRAYA

4.1. Historia de Salud en Atención Primaria

La Historia de Salud en Atención Primaria es la estación de trabajo de los profesionales de este nivel. La documentación de ayudaDIGITAL señala que integra los contactos asistenciales generados en atención primaria y los datos básicos que se comparten con el resto de estaciones. Permite visualizar y editar determinados datos administrativos, gestionar procesos asistenciales y registrar o consultar alergias, contraindicaciones, problemas de salud, antecedentes, datos sociales y contactos.

Desde HSAP se accede a aplicaciones necesarias para la actividad cotidiana, entre ellas citación, prescripciones, incapacidad temporal, pruebas analíticas e imagen. Esto ilustra un patrón de portal clínico: el profesional mantiene un contexto de paciente y accede a funciones especializadas sin tener que reconstruir manualmente la identidad y el episodio en cada aplicación.

4.2. Diraya Atención Hospitalaria

Diraya Atención Hospitalaria se organiza en módulos relacionados. La documentación corporativa enumera la Estación Clínica para la actividad médica, la Estación Clínica de Cuidados para registros de enfermería, la Estación de Gestión para tareas administrativas derivadas de procesos asistenciales, el módulo de urgencias hospitalarias y el Portal Diraya. La separación por estaciones responde a perfiles y procesos distintos, pero los módulos comparten datos para evitar registros redundantes.

La Estación Clínica organiza la información por paciente y episodio, permite crear documentos y enlaza con prescripciones, pruebas analíticas, diagnóstico por imagen, citación y demanda quirúrgica. La Estación Clínica de Cuidados soporta valoración, escalas, planificación de cuidados, constantes, actividades e informes de continuidad. La Estación de Gestión cubre circuitos de hospitalización, hospital de día, actividad quirúrgica, estructura organizativa, ubicaciones y gestión de usuarios.

4.3. Urgencias y continuidad

Urgencias requiere registrar triaje, motivo de consulta, actuaciones, pruebas, evolución y destino con tiempos muy exigentes. El sistema debe facilitar una visión rápida y segura, pero también integrar el episodio con la historia longitudinal. Un error habitual de diseño consiste en tratar urgencias como una isla; la continuidad exige que los informes y datos relevantes queden disponibles para atención primaria y hospitalaria, con el contexto adecuado.

4.4. Portal Diraya y cambio de centro

Portal Diraya actúa como plataforma de acceso a las estaciones de trabajo y permite cambiar de centro físico, evitando autenticaciones repetidas en cada aplicación. Técnicamente, este comportamiento exige gestionar sesión, contexto organizativo, perfiles y autorizaciones. El hecho de que el usuario se autentique una vez no significa que tenga acceso universal: cada aplicación debe comprobar las funciones permitidas, el ámbito y la relación asistencial.

5. PRESCRIPCIÓN, RECETA ELECTRÓNICA Y PRUEBAS ANALÍTICAS

5.1. Receta XXI y prescripción electrónica

Receta XXI es el sistema de receta electrónica integrado en Diraya. La documentación del SAS destaca que facilita la prescripción y el control de medicamentos, permite a los profesionales consultar medicaciones pasadas y actuales y ofrece a las oficinas de farmacia la información necesaria para dispensar y registrar la entrega. Debe distinguirse entre prescripción, dispensación y administración: son actos diferentes, realizados por actores distintos y con trazabilidad propia.

La prescripción incluye medicamento, pauta, duración, indicaciones y condiciones de financiación o visado cuando procedan. La dispensación registra qué producto se entrega, cuándo y por qué oficina de farmacia. La administración, propia de determinados entornos asistenciales, acredita que una dosis se ha administrado efectivamente. Confundir estos estados puede producir errores en conciliación y seguimiento.

5.2. Seguridad de la medicación

Los sistemas de prescripción pueden incorporar reglas sobre alergias, duplicidades, dosis, interacciones y contraindicaciones. Estas ayudas no sustituyen el juicio clínico y deben controlar la fatiga por alertas. Una alerta excesivamente frecuente o poco específica termina ignorándose; una alerta crítica mal configurada puede bloquear la asistencia. La gobernanza de reglas clínicas requiere revisión, versionado y participación de farmacia, medicina, enfermería y tecnología.

5.3. Interoperabilidad de la receta

La interoperabilidad permite que una receta emitida en un servicio de salud pueda dispensarse en otro territorio conectado. Para ello deben intercambiarse identificadores, datos de prescripción, estado de dispensación y evidencias de forma segura. No basta con enviar un documento: los sistemas deben entender el estado de cada tratamiento y evitar dobles dispensaciones. La Estrategia de Salud Digital de Andalucía contempla también el marco europeo de receta electrónica.

5.4. Módulo de Pruebas Analíticas

El Módulo de Pruebas Analíticas integra las pruebas de los laboratorios clínicos en la historia de salud digital y cubre el ciclo desde la solicitud hasta la recepción de resultados, incluyendo toma de muestras. El catálogo corporativo proporciona un lenguaje común entre el MPA y los sistemas de información de laboratorio, permitiendo que cada laboratorio conserve su organización local mientras intercambia información normalizada.

El flujo típico comprende orden clínica, identificación de muestras, procesamiento en el sistema de laboratorio, validación técnica o facultativa, transmisión de resultados y consulta desde la historia. Deben gestionarse estados como solicitado, extraído, recibido, en proceso, preliminar, validado, corregido o cancelado. El receptor no debe presentar como definitivo un resultado que el emisor marque como preliminar.

Desde la perspectiva de soporte, la incidencia “no llega el resultado” exige localizar el punto de ruptura: orden no generada, muestra no identificada, analizador sin conexión, resultado no validado, mensaje rechazado, correspondencia de códigos incorrecta o asociación errónea de paciente. La monitorización debe ofrecer correlación extremo a extremo, no limitarse a comprobar que cada servidor responde.

6. IMAGEN MÉDICA DIGITAL: RIS, PACS, ARCHIVO REGIONAL Y DICOM

6.1. Sistema regional de archivo de imagen médica

El SAS dispone de un sistema regional de archivo de imagen médica digital para almacenar, gestionar y poner a disposición de los profesionales las imágenes generadas en distintos centros. Su valor no reside solo en centralizar almacenamiento, sino en vincular cada estudio con la historia, facilitar la consulta intercentros y reducir la repetición innecesaria de exploraciones.

En un circuito de imagen intervienen habitualmente la aplicación clínica que solicita, el sistema de información de radiología, las modalidades diagnósticas, el archivo y el visor. El RIS organiza agenda, petición, lista de trabajo e informe; el PACS o archivo de imagen conserva y distribuye los objetos DICOM. En despliegues regionales pueden existir componentes locales y centrales, cachés y políticas de ciclo de vida, pero el usuario percibe una consulta integrada.

6.2. DICOM

DICOM define objetos de información y servicios de comunicación para imagen médica. Un objeto contiene píxeles y metadatos como paciente, estudio, serie, modalidad y parámetros de adquisición. Los servicios DIMSE clásicos incluyen C-ECHO para verificación, C-STORE para almacenar, C-FIND para consultar y C-MOVE o C-GET para recuperar. Debe recordarse que DICOM no es únicamente un formato de archivo.

La calidad de los metadatos es tan importante como la imagen. Una imagen correcta asociada al paciente equivocado constituye un incidente grave. Por eso se utilizan listas de trabajo y mensajes de integración para reducir la introducción manual. La reconciliación posterior de estudios debe estar restringida y auditada.

6.3. Informe e imagen

El informe radiológico y la imagen son recursos relacionados pero distintos. El informe puede intercambiarse mediante mensajería o documento clínico; las imágenes se distribuyen mediante DICOM u otros mecanismos compatibles. La historia debe enlazar ambos elementos y preservar la relación con la petición original. Un visor integrado no implica que la imagen se copie en cada módulo clínico; normalmente se accede mediante servicios del archivo.

6.4. Otras señales y documentos multimedia

La evolución del archivo regional puede incorporar endoscopias, oftalmología, electrocardiogramas u otros contenidos. Esto obliga a decidir si cada tipo se representa como objeto DICOM, documento, señal estructurada o enlace a un repositorio especializado. El criterio debe basarse en interoperabilidad, preservación, rendimiento, trazabilidad y capacidad de visualización clínica.

7. CITACIÓN, DEMANDA QUIRÚRGICA, URGENCIAS Y GESTIÓN ASISTENCIAL

7.1. Citación y agenda

La citación relaciona demanda, cartera de servicios, agendas, recursos, preparación y prioridad. En atención primaria, ClicSalud+ y la App Salud Andalucía permiten solicitar determinadas citas; otras actividades requieren indicación profesional o condiciones especiales. La agenda no es una simple tabla de huecos: incorpora tipos de acto, duración, profesional, sala, equipamiento, reglas de apertura, bloqueos y posibles sobrecargas autorizadas.

Un cambio de agenda debe preservar citas ya asignadas o aplicar un procedimiento explícito de reprogramación y comunicación. Los sistemas deben registrar quién modifica, qué regla aplica y qué pacientes resultan afectados. En integraciones, la cancelación y la reprogramación necesitan identificadores estables para evitar que una actualización se interprete como una nueva cita duplicada.

7.2. Gestión de la demanda quirúrgica

La Aplicación de Gestión de la Demanda permite mantener un Registro de Demanda Quirúrgica único y centralizado. La inscripción se relaciona con indicación, procedimiento, prioridad, fecha, garantía y estado. El circuito continúa con preparación, programación, suspensión, reprogramación y resolución. Los cambios deben conservar motivo y trazabilidad porque afectan a derechos y a indicadores públicos.

La terminología actual de ayudaDIGITAL utiliza AGD y Registro de Demanda Quirúrgica. Por rigor, no debe presentarse un acrónimo histórico como si fuera necesariamente la denominación vigente de la aplicación. En un examen, conviene atender al nombre exacto usado en la documentación corporativa del momento.

7.3. Urgencias, hospitalización y quirófano

Los sistemas de urgencias gestionan flujo de pacientes, clasificación, ubicaciones, pruebas, tratamientos y destino. Hospitalización añade camas, traslados, órdenes, evoluciones y alta. El bloque quirúrgico coordina programación, quirófanos, equipos, anestesia y documentación. Aunque existan módulos especializados, la información esencial debe regresar a la historia longitudinal.

7.4. Otros registros asistenciales

El ecosistema incluye aplicaciones y registros para procesos concretos: garantías, heridas, cribados, vacunación, cuidados, salud mental, incapacidad temporal, pruebas funcionales o movilidad. No todos forman parte del núcleo de Diraya de la misma manera. La relación puede ser de módulo integrado, aplicación enlazada, servicio corporativo o sistema externo que intercambia información.

8. BASE POBLACIONAL DE SALUD: INTEGRACIÓN Y EXPLOTACIÓN LONGITUDINAL

8.1. Creación y naturaleza

La Base Poblacional de Salud fue creada por la Resolución 0068/18 de la Dirección Gerencia del SAS. La Resolución la define como un sistema de información del SSPA que integra datos de cada persona distribuidos en distintos sistemas de la entidad. Esta definición normativa debe prevalecer sobre etiquetas tecnológicas no oficiales. Puede utilizar técnicas de integración y analítica, pero la Resolución no la define simplemente como “un data warehouse” ni como “un data lake”.

8.2. Finalidades

Sus finalidades comprenden identificar necesidades de atención de la población y subgrupos, apoyar la planificación sanitaria y la salud pública, apoyar la gestión y la distribución de recursos, compartir información entre niveles, configurar biografías sanitarias longitudinales, anticipar necesidades futuras y disponer de infraestructura de datos para investigación. Son finalidades amplias y diferenciadas; no todas autorizan el mismo acceso ni la misma granularidad.

La BPS permite pasar de la visión por episodio a la visión poblacional y longitudinal. Un sistema operativo responde qué ocurrió en una consulta concreta; un sistema poblacional puede analizar trayectorias, utilización, resultados y necesidades en grupos. Esa potencia requiere especial cuidado con sesgos, calidad, cobertura, cambios de codificación y comparabilidad temporal.

8.3. Conexión y fuentes

La Resolución establece que la conexión se realiza mediante el identificador único de la BDU. Inicialmente integra información demográfica, del estado de salud y de utilización de servicios, y prevé incorporar progresivamente otros datos, incluidos ámbitos sociosanitarios o estadísticos cuando proceda. La integración necesita procesos de extracción, transformación y carga o mecanismos equivalentes, reglas de calidad, metadatos y linaje.

El linaje permite conocer de qué sistema y campo procede un indicador, qué transformaciones se aplicaron y qué fecha de corte tiene. Sin linaje, dos cifras diferentes pueden parecer incompatibles cuando en realidad responden a definiciones, periodos o poblaciones distintas. Los indicadores deben acompañarse de ficha técnica y versión.

8.4. Gobierno y acceso

La Resolución constituye una Comisión de Dirección con funciones de estrategia, programa anual, recursos, integración de nuevas fuentes y determinación de personas autorizadas. El acceso se limita a personal autorizado, con identificación y autenticación segura desde la red corporativa, y cada profesional accede exclusivamente a los datos necesarios para sus funciones. Se enumeran finalidades asistenciales, de administración, gestión, evaluación, inspección, investigación y salud pública.

8.5. Explotación responsable

La explotación debe aplicar minimización, seudonimización o anonimización según el objetivo y el riesgo, control de exportaciones, entornos autorizados y revisión de resultados. La seudonimización reduce exposición, pero los datos siguen siendo personales si existe posibilidad razonable de reidentificación. La anonimización exige evaluar el riesgo de singularización, vinculación e inferencia.

9. CLICSALUD+, APP SALUD ANDALUCÍA E INTEROPERABILIDAD CIUDADANA

9.1. ClicSalud+

ClicSalud+ es el canal web de relación de la ciudadanía con información y servicios sanitarios. Incluye agenda sanitaria, consulta de información de salud, trámites y datos personales, con funciones que dependen de la cobertura y del nivel de identificación. La información puede incluir informes, medicación, resultados analíticos, pruebas de imagen y situación en el registro de demanda quirúrgica.

El portal no es una copia íntegra de todas las pantallas profesionales. Publica conjuntos de información seleccionados, con reglas de disponibilidad, presentación y protección. Puede existir demora entre la generación de un dato y su visualización ciudadana por motivos de validación, sincronización o publicación. Esa diferencia no implica necesariamente que el profesional carezca del dato.

9.2. App Salud Andalucía

La App Salud Andalucía es la aplicación móvil institucional de referencia. Permite llevar la tarjeta sanitaria virtual y acceder a trámites como cita o consulta de historia clínica electrónica. Técnicamente actúa como canal de acceso a servicios; no debe suponerse que almacena localmente toda la historia. El diseño móvil debe limitar datos persistentes, proteger sesión, evitar exposición en notificaciones y adaptarse a pérdida o cambio de dispositivo.

9.3. Representación

El acceso en representación de menores o personas dependientes exige verificar la relación de representación y delimitar su alcance. No basta con conocer datos personales del representado. El sistema debe registrar quién accede, en nombre de quién y con qué base. La revocación o cambio de representación debe propagarse con rapidez.

9.4. Historia Clínica Digital del SNS

La Historia Clínica Digital del Sistema Nacional de Salud tiene como finalidad poner a disposición de ciudadanía y profesionales los informes clínicos relevantes cuando la asistencia se produce fuera de la comunidad habitual. No centraliza necesariamente toda la historia operativa; intercambia conjuntos documentales acordados y respeta políticas de consentimiento, oposición y trazabilidad.

9.5. Salud Responde y multicanalidad

Los canales telefónicos y presenciales continúan siendo necesarios para evitar exclusión digital. La multicanalidad exige que una cita o trámite iniciado por un canal sea coherente con los demás. Para ello, todos deben operar sobre servicios comunes o sincronizados y usar identificadores de transacción que permitan auditar el recorrido.

10. INTEROPERABILIDAD CLÍNICA: HL7, FHIR, CDA, DICOM, IHE Y TERMINOLOGÍAS

10.1. HL7 v2

HL7 v2 es una familia de mensajería ampliamente utilizada para intercambiar eventos clínico-administrativos. Los mensajes se componen de segmentos y campos delimitados. MSH identifica cabecera y tipo de mensaje; PID contiene datos del paciente; PV1 información de visita; ORC y OBR órdenes; y OBX observaciones. La obligatoriedad exacta depende del tipo de mensaje y del perfil de implementación.

MSH|^~&|SISTEMA_A|CENTRO|SISTEMA_B|REGION|202608041200||ORU^R01|MSG0001|P|2.5
PID|||NHUSA12345^^^SAS^PI||APELLIDO^NOMBRE
OBR|1|ORD123|LAB456|PRUEBA^Descripción
OBX|1|NM|CODIGO^Magnitud||5.2|unidad|3.5-5.5|N|||F

El ejemplo es didáctico: una interfaz real debe seguir su guía de implementación, codificación, escape de caracteres, juegos de identificadores y reglas de confirmación. No basta con que el mensaje sea sintácticamente válido; debe respetar semántica, cardinalidad y vocabularios acordados.

10.2. CDA y FHIR

CDA representa documentos clínicos con cabecera y cuerpo, permitiendo narrativa legible y secciones estructuradas. FHIR organiza la información en recursos como Patient, Encounter, Observation, MedicationRequest o DiagnosticReport y define APIs y operaciones de interoperabilidad. FHIR puede representarse en JSON, XML y otros formatos previstos por la especificación; no debe confundirse con una base de datos o con una aplicación concreta.

10.3. DICOM e IHE

DICOM cubre imagen médica. IHE no sustituye a HL7 o DICOM, sino que publica perfiles de integración que especifican cómo usar estándares para resolver flujos reales. Un perfil identifica actores, transacciones y requisitos de prueba. Esta orientación reduce ambigüedad y facilita pruebas de interoperabilidad entre proveedores.

10.4. Terminologías y clasificaciones

La interoperabilidad semántica utiliza clasificaciones y terminologías. CIE permite clasificar enfermedades y procedimientos para fines asistenciales, estadísticos o de codificación; SNOMED CT ofrece conceptos clínicos y relaciones; LOINC identifica observaciones y documentos; ATC clasifica principios activos y medicamentos por grupos terapéuticos. Ninguna terminología resuelve todos los usos. Deben definirse versiones, subconjuntos, equivalencias y gobernanza.

10.5. API y seguridad

Las APIs modernas deben aplicar autenticación, autorización, limitación de alcance, registro, versionado y protección frente a abuso. Una API clínica no puede confiar solo en que el consumidor esté dentro de la red. Debe validar identidad, permisos, propósito y contexto. Las respuestas deben minimizar datos, manejar paginación y errores sin revelar información sensible.

11. SEGURIDAD, PROTECCIÓN DE DATOS, AUDITORÍA Y CONTINUIDAD

11.1. Marco de protección

Los datos de salud son una categoría especial de datos personales conforme al artículo 9 del RGPD. Su tratamiento asistencial puede basarse en las excepciones previstas para diagnóstico, asistencia o gestión de sistemas sanitarios, bajo responsabilidad profesional y garantías adecuadas. No debe afirmarse que toda atención requiere consentimiento explícito para tratar la historia: la base jurídica puede ser la prestación sanitaria y la normativa aplicable. El consentimiento informado clínico y el consentimiento como base de tratamiento de datos son conceptos distintos.

La Ley 41/2002 regula autonomía, información y documentación clínica; la LOPDGDD complementa el RGPD; y el Esquema Nacional de Seguridad establece principios y medidas para sistemas del sector público. La categoría ENS de un sistema se obtiene mediante categorización formal de las dimensiones de seguridad. No puede deducirse automáticamente que todo sistema con datos de salud sea de categoría alta en todas las dimensiones.

11.2. Control de acceso

El control de acceso combina identificación, autenticación y autorización. La autenticación prueba quién es el usuario; la autorización determina qué puede hacer. Los perfiles deben ajustarse a función, centro y ámbito. Los cambios de puesto, sustituciones, rotaciones y bajas requieren procesos ágiles de alta, modificación y revocación. Las cuentas compartidas impiden atribución y deben evitarse.

El principio de mínimo privilegio no equivale a impedir la asistencia. Deben existir mecanismos excepcionales controlados para urgencias, con justificación y auditoría cuando proceda, pero su existencia y diseño deben basarse en documentación real del sistema. No conviene memorizar nombres anglosajones o funcionalidades no confirmadas como si fueran oficiales del SAS.

11.3. Auditoría y derechos

Los registros de acceso deben permitir investigar quién consultó o modificó información, desde qué aplicación, cuándo y sobre qué paciente. Deben protegerse contra alteración y conservarse conforme a política. La ciudadanía puede solicitar información sobre accesos en los términos establecidos; el sistema debe generar evidencias comprensibles sin exponer datos de terceros indebidamente.

11.4. Disponibilidad, continuidad y contingencia

La continuidad asistencial exige análisis de impacto, dependencias, procedimientos degradados, copias, replicación, recuperación y pruebas periódicas. RTO y RPO deben derivarse del análisis de negocio y del diseño aprobado; no existe un valor universal aplicable a todo Diraya. Una copia no probada no constituye una garantía de recuperación. También deben contemplarse caída de red, identidad, integración, impresión, firma o servicios externos.

Los procedimientos de contingencia deben definir qué se registra durante la indisponibilidad, cómo se identifica al paciente, cómo se concilian después los datos y quién autoriza el retorno. Introducir masivamente datos al restablecer puede generar duplicidades si no se usan claves idempotentes y reglas de reconciliación.

11.5. Seguridad de integración

La mensajería clínica debe proteger confidencialidad e integridad, validar origen, controlar repetición, gestionar confirmaciones y limitar contenido. Los motores de integración son activos críticos porque concentran datos de múltiples sistemas. Sus colas y mensajes de error pueden contener información sanitaria, por lo que los logs deben minimizar y proteger datos.

12. OPERACIÓN, SOPORTE E IMPLANTACIÓN: FUNCIÓN DEL TFA-STI

12.1. Modelo de soporte

El soporte de sistemas asistenciales debe diferenciar incidencia, petición de servicio, problema y cambio. Una incidencia restaura el servicio; un problema busca la causa raíz; un cambio modifica un componente; una petición cubre una necesidad estándar. Mezclar categorías impide medir y priorizar. En un sistema clínico, la prioridad debe considerar impacto asistencial, alcance, existencia de alternativa y riesgo para el paciente, no solo número de llamadas.

12.2. Diagnóstico extremo a extremo

El diagnóstico debe reconstruir el flujo. Para una analítica: petición, toma de muestra, recepción, procesamiento, validación, mensaje, integración y visualización. Para una imagen: orden, agenda, modalidad, almacenamiento, informe y enlace. Para una receta: prescripción, publicación, consulta, dispensación y actualización. Cada paso necesita identificadores correlacionables y estados.

Las pruebas técnicas deben respetar confidencialidad. No se deben copiar historias reales a entornos de prueba sin base y medidas adecuadas. Los datos sintéticos deben cubrir casos límite: múltiples identificadores, caracteres especiales, episodios cancelados, resultados corregidos, pacientes sin documento, representación y cambios de centro.

12.3. Monitorización

La monitorización útil combina infraestructura, aplicación, integración y negocio. CPU o espacio libre no detectan por sí solos que las órdenes se acumulan. Son necesarios indicadores como mensajes pendientes, tasa de rechazo, latencia por interfaz, citas no sincronizadas, estudios huérfanos, resultados no vinculados o errores de autenticación. Los umbrales deben evitar ruido y distinguir degradación de fallo total.

12.4. Gestión de cambios e implantaciones

Un cambio en catálogo, interfaz o pantalla puede afectar a muchos centros. Debe existir análisis de impacto, plan de pruebas, piloto, comunicación, formación, ventana, retorno y verificación. Los cambios de terminología y catálogos requieren compatibilidad con datos históricos. Una actualización de código no debe reinterpretar retrospectivamente resultados sin una regla explícita.

La implantación necesita coordinar TIC, responsables funcionales, profesionales, proveedores, protección de datos y seguridad. El TFA-STI traduce necesidades asistenciales a requisitos verificables, mantiene trazabilidad y evita que una solución local rompa la arquitectura corporativa.

12.5. Calidad y gobierno

La calidad se mide con disponibilidad, rendimiento, errores, satisfacción, calidad del dato y resultados del proceso. Un sistema puede estar disponible y prestar mal servicio si presenta información incompleta o tarda en propagar resultados. Los acuerdos de nivel de servicio deben incluir métricas funcionales, no solo infraestructura.

12.6. Documentación

La documentación mínima comprende mapa de aplicaciones, propietarios, dependencias, interfaces, catálogos, perfiles, procedimientos de contingencia, manuales, matriz de escalado y registro de decisiones. Debe mantenerse viva. Un diagrama desactualizado puede empeorar una crisis al dirigir actuaciones sobre un componente que ya no interviene.

13. EVOLUCIÓN Y TENDENCIAS DE LOS SISTEMAS ASISTENCIALES

13.1. De sistemas por centro a servicios compartidos

La evolución tiende a reducir silos mediante repositorios regionales, catálogos comunes, identidad corporativa y servicios compartidos. Esto mejora continuidad y explotación, pero aumenta el impacto potencial de fallos comunes. La arquitectura debe combinar centralización lógica con redundancia, segmentación y capacidad de degradación controlada.

13.2. FHIR y espacio europeo de datos

FHIR facilita APIs granulares y perfiles modernos; el Espacio Europeo de Datos de Salud impulsa usos primarios y secundarios bajo reglas comunes. La adopción no consiste en exponer sin más toda la historia. Requiere modelos de consentimiento u oposición aplicables, identificación transfronteriza, terminologías, conjuntos de datos prioritarios, trazabilidad y controles de acceso.

13.3. Inteligencia artificial

La IA puede apoyar priorización, extracción de información, predicción o ayuda a la decisión. En salud, la calidad del dato, la representatividad, el sesgo, la explicabilidad, la supervisión humana y la vigilancia posterior son esenciales. Un modelo integrado en un flujo clínico debe versionarse y monitorizarse; no basta con validar su precisión en un conjunto inicial.

El Reglamento europeo de inteligencia artificial introduce obligaciones según el riesgo y puede afectar a sistemas médicos o de gestión cuando encajen en sus categorías. Además, continúan aplicándose protección de datos, producto sanitario cuando proceda, seguridad y responsabilidad profesional.

13.4. Movilidad y atención remota

La historia clínica en movilidad permite atender fuera del puesto fijo. El reto es mantener identidad, contexto, conectividad, privacidad visual, bloqueo y borrado seguro. La teleasistencia y monitorización domiciliaria generan datos continuos que deben filtrarse y contextualizarse para no saturar a profesionales.

13.5. Analítica en tiempo más próximo

La analítica evoluciona hacia datos más actualizados, pero la velocidad no elimina la necesidad de validación. Un cuadro de mando operativo puede usar datos casi en tiempo real; un indicador oficial puede requerir cierre, depuración y reglas estables. Debe mostrarse la fecha de actualización y evitar comparar series con definiciones diferentes.

14. CASOS PRÁCTICOS Y FLUJOS EXTREMO A EXTREMO

14.1. Flujo de una prueba analítica

1. Orden: el profesional selecciona la prueba y el sistema registra paciente, episodio, solicitante, prioridad y contexto.
2. Muestra: se genera identificación inequívoca y se registra extracción y transporte.
3. Laboratorio: el SIL recibe la orden, dirige analizadores y controla estados.
4. Validación: el resultado se valida con estado y autoría.
5. Integración: el mensaje se transforma, valida y correlaciona.
6. Historia: el resultado se presenta con unidades, rango, fecha, estado y procedencia.
7. Ciudadanía: se publica conforme a reglas y canales definidos.

Una prueba de extremo a extremo debe comprobar tanto el dato normal como correcciones, cancelaciones, resultados críticos, duplicados y reenvíos. El mensaje repetido no debe crear dos observaciones si representa la misma versión; una corrección debe sustituir o versionar la anterior preservando trazabilidad.

14.2. Flujo de demanda quirúrgica

1. Indicación e inscripción: procedimiento, prioridad, fecha y situación de garantía.
2. Preparación: pruebas preoperatorias y aptitud.
3. Programación: asignación de fecha, quirófano y recursos.
4. Comunicación: citación y cambios con evidencia.
5. Intervención o resolución: salida del registro con motivo.
6. Explotación: indicadores de demora y situación, con definiciones estables.

La lógica de estados es crítica. Una suspensión temporal no equivale a baja definitiva; una renuncia no equivale a intervención realizada; y un traslado requiere continuidad. Los informes deben reflejar correctamente la población incluida y las exclusiones.

14.3. Flujo de imagen

1. Petición clínica con pregunta diagnóstica y prioridad.
2. Agenda y worklist para reducir entrada manual en la modalidad.
3. Adquisición y almacenamiento DICOM.
4. Interpretación y firma o validación del informe.
5. Publicación del informe y enlace a las imágenes.
6. Acceso intercentros con autorización y auditoría.

14.4. Distinciones de repaso

15. GOBIERNO TÉCNICO DEL DATO E INTEGRACIÓN FIABLE

15.1. Responsabilidad y contrato de interfaz

El gobierno de integración comienza por asignar responsables claros. Cada interfaz debe tener un propietario funcional, que define el significado y uso del dato, y un responsable técnico, que mantiene transporte, transformación, monitorización y soporte. También debe identificarse la fuente autoritativa de cada elemento. Sin esa asignación, una incidencia puede circular entre equipos porque todos administran una parte, pero nadie responde del flujo completo. La ficha de interfaz debe recoger emisor, receptor, finalidad, datos intercambiados, frecuencia, criticidad, dependencias, contactos, horario de soporte y procedimiento de escalado.

La especificación no puede limitarse a un ejemplo de mensaje. Debe definir cardinalidad, obligatoriedad condicional, longitudes, juegos de caracteres, zonas horarias, precisión temporal, unidades, vocabularios, identificadores y reglas de negocio. Un campo vacío puede significar desconocido, no aplicable, no medido o eliminado; tratar todos esos estados como una cadena vacía destruye semántica. Del mismo modo, cero no equivale a ausencia de resultado y una fecha sin hora puede ser insuficiente para ordenar eventos clínicos. Las decisiones deben documentarse y versionarse para que emisor y receptor evolucionen de forma coordinada.

La idempotencia es esencial cuando existen reintentos. Si el emisor no recibe confirmación, puede repetir un mensaje que sí fue procesado. El receptor debe reconocer el identificador del evento y evitar duplicar una cita, una orden o un resultado. Sin embargo, no debe descartar una versión corregida por considerarla repetida: necesita comparar identificador, estado y versión. La estrategia puede combinar claves de negocio, identificador técnico y control de secuencia. Los registros de auditoría deben permitir reconstruir cada intento, confirmación, rechazo y reproceso sin almacenar más datos clínicos de los necesarios.

Las confirmaciones técnicas y funcionales no son equivalentes. Una aceptación de transporte demuestra que el mensaje llegó y pudo analizarse; no garantiza que se haya incorporado a la historia ni que supere las reglas clínicas. Un resultado puede ser sintácticamente válido y rechazarse porque no existe la orden, el paciente no coincide o el código de prueba no está mapeado. La monitorización debe distinguir recepción, validación, persistencia y publicación. Mostrar únicamente el número de mensajes enviados ofrece una imagen incompleta y puede ocultar pérdidas funcionales.

15.2. Semántica, estados e identidad

Los catálogos corporativos requieren ciclo de vida propio. Deben existir altas, modificaciones, inactivaciones, equivalencias y fechas de vigencia. Eliminar físicamente un código utilizado históricamente rompe informes y mensajes antiguos; normalmente se inactiva y se conserva para interpretación. Cuando dos centros usan códigos locales diferentes, la tabla de correspondencias debe indicar versión y contexto. Los cambios de unidades son especialmente delicados: un valor numérico idéntico puede significar otra magnitud si cambia la unidad, por lo que la transformación debe ser explícita y verificable.

La reconciliación de identidad debe tratarse como proceso clínico-técnico de alto riesgo. Los sistemas pueden detectar posibles duplicados mediante reglas deterministas o probabilísticas, pero la decisión de fusionar necesita evidencia suficiente. Antes de una fusión se revisan identificadores, episodios, documentos, imágenes, medicación y resultados; después se comprueba que las referencias se han actualizado. También debe existir desfusión controlada para corregir una unión errónea. Cada operación conserva autor, motivo, fecha y objetos afectados, evitando que la corrección oculte el incidente original.

La gestión de estados evita interpretaciones incorrectas. Una orden puede estar solicitada, programada, iniciada, completada, cancelada o suspendida; un resultado puede ser preliminar, final, corregido o anulado; una cita puede estar reservada, confirmada, atendida, no presentada o reprogramada. La interfaz debe acordar qué transiciones son válidas y qué ocurre si llegan fuera de orden. En sistemas distribuidos es posible recibir primero una corrección y después una copia retrasada del resultado original; el receptor debe usar versión y tiempo de evento, no solo tiempo de recepción.

El tratamiento de errores debe separar los recuperables de los que requieren intervención. Una caída temporal puede resolverse mediante reintento con espera progresiva; un código desconocido necesita corrección de catálogo; una identidad ambigua requiere revisión humana. Reintentar indefinidamente un error permanente congestiona colas y oculta nuevos eventos. Conviene usar colas de errores controladas, límites de reintento, alertas con contexto y herramientas de reproceso que mantengan la trazabilidad. El reproceso no debe permitir editar silenciosamente el contenido clínico original.

15.3. Pruebas, rendimiento y observabilidad

Las pruebas de integración deben cubrir contrato, componente, extremo a extremo, regresión, rendimiento, seguridad y contingencia. El conjunto de casos incluye valores normales y límites, caracteres especiales, ausencia de datos opcionales, duplicados, mensajes fuera de orden, cancelaciones, correcciones y pacientes con múltiples identificadores. Deben verificarse también los efectos observables: que el profesional ve el dato correcto, con estado, unidad, fecha y procedencia. Una prueba que solo confirma el envío del mensaje no acredita la utilidad asistencial del flujo.

El rendimiento debe analizarse con métricas de servicio. La latencia aceptable de una consulta interactiva no es la misma que la de una carga analítica. Hay que medir percentiles, volumen, tamaño de mensajes, picos, colas y tiempo de procesamiento por etapa. Aumentar indiscriminadamente el tiempo de espera puede ocultar saturación y empeorar la experiencia. Las pruebas de carga deben reproducir concurrencia y distribución realista sin utilizar datos personales innecesarios. Cuando se aplica caché, se documenta su vigencia y mecanismo de invalidación para evitar información obsoleta.

La observabilidad combina métricas, logs y trazas correlacionadas. Las métricas permiten detectar tendencia; los logs explican eventos; las trazas siguen una transacción entre componentes. En salud, estas evidencias pueden incluir identificadores sensibles, por lo que deben seudonimizarse, limitarse y protegerse. El identificador de correlación debe permitir investigar sin exponer el contenido completo. Los paneles operativos deben mostrar salud de dependencias, tasa de errores, antigüedad de la cola y flujos funcionales, no solo disponibilidad de máquinas.

Los despliegues deben ser reversibles y compatibles. Si emisor y receptor no se actualizan simultáneamente, la nueva versión debe coexistir durante una transición o negociarse mediante versionado. Los cambios incompatibles requieren plan coordinado, piloto y ventana. El retorno no consiste únicamente en reinstalar software: puede ser necesario revertir catálogos, migraciones o mensajes ya emitidos. La verificación posterior comprueba funciones clínicas representativas y no se limita a que la aplicación abra. También se comunica a soporte qué ha cambiado y qué síntomas pueden aparecer.

15.4. Despliegue, continuidad y gobierno

La continuidad de integración incluye procedimientos degradados. Si el canal de laboratorio se interrumpe, debe saberse cómo se conservan órdenes y resultados, cómo se priorizan los críticos y cómo se concilian al recuperar. El uso temporal de papel o llamadas puede ser necesario, pero genera datos que después deben incorporarse sin duplicar. El plan identifica dependencias comunes —identidad, red, certificados, DNS, reloj, colas— porque una caída transversal puede afectar a múltiples aplicaciones que aparentan fallos independientes.

La contratación y relación con proveedores debe preservar conocimiento y capacidad de control. Los pliegos deben exigir documentación de interfaces, estándares, pruebas, exportabilidad, registro, seguridad, continuidad y soporte. Una integración no debe depender de una persona o de una herramienta inaccesible para el SAS. Los cambios del proveedor se someten a gestión de configuración y no se aplican directamente en producción. Los acuerdos de nivel de servicio deben incluir tiempos de diagnóstico, recuperación y entrega de evidencias, además de disponibilidad nominal.

La gestión de certificados y secretos merece tratamiento específico. Las interfaces pueden depender de certificados TLS, credenciales de servicio, claves de firma o tokens. Deben almacenarse en mecanismos seguros, renovarse antes de caducar y rotarse sin interrupciones. Una caducidad no detectada puede detener simultáneamente varios flujos; por ello se monitorizan fechas, cadena de confianza y nombres de servicio. Los secretos nunca deben aparecer en código, manuales públicos o logs. Los accesos administrativos se separan de las identidades de servicio y quedan auditados.

La sincronización temporal es otra dependencia transversal. Fechas y horas se utilizan para ordenar episodios, calcular demoras, validar certificados y reconstruir auditorías. Los sistemas deben usar fuentes horarias fiables y representar correctamente zona horaria y cambios estacionales. Un desfase de minutos puede alterar la secuencia aparente de mensajes o provocar que un token se considere aún no válido o expirado. Cuando se intercambian datos entre sistemas, se distingue el instante del evento clínico del instante de registro, envío, recepción y validación.

La accesibilidad y la ergonomía también forman parte de la seguridad asistencial. Una interfaz que oculta estados, recorta unidades o obliga a navegar por múltiples pantallas aumenta el riesgo de error. Las pruebas con profesionales deben comprobar legibilidad, orden de información, uso por teclado, contraste y comportamiento en distintos dispositivos. Los mensajes de error deben orientar sin revelar datos sensibles. La formación se diseña por tareas y perfiles, y las ayudas se mantienen alineadas con la versión implantada para evitar que el usuario siga procedimientos obsoletos.

Finalmente, el gobierno del dato necesita revisión periódica. Los flujos que fueron correctos pueden degradarse por nuevos centros, cambios de catálogo, actualización normativa o evolución clínica. Se revisan accesos, fuentes, finalidades, indicadores de calidad y riesgos. Las interfaces sin uso se retiran de forma controlada; las activas se inventarían y prueban. Esta disciplina reduce deuda técnica y evita que un sistema asistencial dependa de conexiones desconocidas. La integración fiable es un servicio continuo, no un proyecto que termina el día de la puesta en producción.

16. CONCLUSIONES E IDEAS CLAVE PARA EL REPASO

Los sistemas asistenciales del SAS forman una arquitectura funcional integrada cuyo núcleo es Diraya y cuya continuidad depende de identidad, catálogos, interoperabilidad, seguridad y operación. El opositor debe evitar dos simplificaciones: considerar Diraya una sola aplicación y considerar toda integración equivalente. Las estaciones clínicas, módulos de gestión, repositorios regionales y canales ciudadanos cooperan mediante patrones distintos.

Los conceptos de mayor rendimiento para el examen son: Diraya como soporte de la historia clínica electrónica; HSAP para atención primaria; Estación Clínica, Cuidados y Gestión en atención hospitalaria; Receta XXI; MPA y su integración con los SIL; archivo regional de imagen y DICOM; BDU/GADU y NHUSA; AGD y registro de demanda quirúrgica; ClicSalud+ y App Salud Andalucía; BPS y Resolución 0068/18; HL7, FHIR, CDA, IHE y terminologías.

Desde el punto de vista técnico, la calidad de un sistema sanitario se mide por la capacidad de entregar el dato correcto, al profesional correcto, en el momento correcto y con contexto. La disponibilidad sin integridad no es suficiente; la integración sin semántica tampoco; y la seguridad sin usabilidad puede inducir atajos inseguros. El diseño debe equilibrar asistencia, protección y eficiencia.

La preparación del tema debe incluir no solo definiciones, sino también relaciones y trampas: identidad frente a episodio; sistema operacional frente a analítico; informe frente a imagen; prescripción frente a dispensación; autenticación frente a autorización; dato preliminar frente a validado; y sistema corporativo frente a aplicación local. Las preguntas suelen introducir un término correcto en un ámbito equivocado.

17. MAPA CONCEPTUAL