0Resumen Ejecutivo

Este documento describe el modelo funcional de la base de datos Oracle del Sistema de Gestión de Laboratorio (GDL) de la Clínica Universidad de Navarra (CUN). El sistema abarca dos centros hospitalarios (Pamplona · AD74CODCENTRO=1 y Madrid · AD74CODCENTRO=2) y gestiona el ciclo completo del proceso analítico, desde la solicitud médica hasta la entrega del resultado validado.

🔬 CUNLAB

Esquema nuclear del laboratorio. Gestiona secciones, muestras, carpetas/pruebas, autoanalizadores, CC y resultados.

214 tablas · LBxxxx

📋 PR – Plan Asistencial

Actuaciones clínicas planificadas. PRUEBAASISTENCIA y MUESTRAASISTENCIA son el nexo con el laboratorio.

593 tablas · 56+ triggers

🏥 CI – Historia Clínica

Datos demográficos del paciente. CI22 (historia), CI21 (persona), CI30 (sexo), CI32 (tipo económico).

344 tablas

🔐 SG – Seguridad

Usuarios y roles. SG0200 es la tabla maestra de usuarios, referenciada por los campos de auditoría de todas las tablas.

114 tablas

🏢 AD – Administración

Asistencias, departamentos, camas, procesos, diagnósticos, tipo paciente. AD0200 enlaza departamentos con el laboratorio.

439 tablas

💰 FA – Facturación

Facturación, contratos, campañas, artículos. Enlaza actuaciones del laboratorio con el circuito económico.

741 tablas

📄 IM – Documentación Médica

Informes, documentos, estados de firma. IM0100 (documentos), IM3300 (informes quirúrgicos), IM4000+ (consentimientos).

144 tablas

ℹ️

Patrón de Auditoría Universal Todas las tablas incluyen: SG02COD_ADD (usuario creación), FECADD (fecha creación), SG02COD_UPD (usuario última modificación), FECUPD (fecha última modificación). Esto permite trazabilidad completa de cada registro.

1Esquemas y Arquitectura

El sistema usa un modelo multi-esquema Oracle donde cada esquema representa un dominio funcional independiente pero interconectado. Las referencias cruzadas son explícitas mediante prefijos de columna que identifican el esquema origen.

🔬 CUNLAB – Esquema Nuclear de Laboratorio

Con 214 tablas organizadas en 6 dominios funcionales, CUNLAB implementa todo el ciclo analítico interno. Los identificadores siguen el patrón LBxxxx donde las primeras dos cifras identifican la tabla maestra.

Dominio	Tablas clave	Descripción
Organización	DPTOSECC, PUESTO, LISTAREALIZACION	Secciones laboratorio, puestos de trabajo, listas de realización
Pruebas	CARPETAS, PRUEBAASISTENCIA, TIPOPRUEBA	Catálogo de pruebas, instancias por asistencia, tipos
Muestras	MUESTRAASISTENCIA, TIPOMUESTRA, LISTAEXTRACCION	Muestras físicas, tipos de tubo/contenedor, listas de extracción
Analítica	AUTOANALIZADORES, RESULTADO, LISTAREALIZACION	Equipos analíticos, resultados numéricos/texto, worklists
Control Calidad	LB1000 (CC), LB1100 (resultados CC), LB1200 (programas CC)	Programas de CC, resultados, evaluación estadística
Informes	LB2300 (órdenes), LB2900 (plantillas), LB3300 (informes)	Generación y emisión de informes de laboratorio

Tablas Principales CUNLAB

Tabla	Descripción Funcional	Columnas clave
`DPTOSECC`	Secciones del laboratorio (Bioquímica, Hematología, Microbiología…)	CDPTOSECC, DESIGNACION, CDPTODEPENDIENTE, AD02CODDPTO, INDBAJA
`CARPETAS`	Catálogo de pruebas/perfiles solicitables. Cada carpeta tiene un departamento responsable, autoanalizador y configuración de ejecución	CCARPETA, DESIGNACION, CDPTOSECC, CAUTOANALIZADOR, TIPO, ACTIVA, TVALIDURG, TVALIDNOURG
`PRUEBAASISTENCIA`	Instancia de una carpeta para una asistencia concreta. Columna ESTADO es la máquina de estados central del flujo analítico	NREPETICION, CCARPETA, ESTADO, PR04NUMACTPLAN, CLISTAREALIZACION, CAUTOANALIZADOR, NUMPARTICION
`MUESTRAASISTENCIA`	Muestra física asociada a una asistencia. Controla estado, volumen, tiempos de estabilidad y trazabilidad	CMUESTRA (AAA-NNNN), CTIPOMUESTRA, ESTADO, VOLUMENPREF, VOLUMENMIN, TIEMPO, FECHAEXTRACCION, AD74CODCENTRO
`AUTOANALIZADORES`	Catálogo de equipos analíticos. Cada equipo tiene centro asignado, controlador y configuración de comunicación	CAUTOANALIZADOR, DESIGNACION, DESCRIPCION, AD74CODCENTRO, INDCONECTADO, CODCONTROLADOR, INDASIGNABLE
`LB1000`	Programas de Control de Calidad. Cada programa agrupa controles para un analito y departamento	LB10CODCTRLCALI, LB10DESIGNACION, LB10INDACTIVO, AD02CODDPTO
`LISTAREALIZACION`	Worklist de realización: agrupa pruebas a ejecutar en un turno/equipo. ESTADO controla el ciclo de vida de la lista (enum `constEstadoLista`)	CLISTAREALIZACION, CDPTOSECC, FECREALIZACION, CAUTOANALIZADOR, ESTADO
`TIPOMUESTRA`	Catálogo de tipos de muestra (sangre, orina, LCR…)	CTIPOMUESTRA, DESIGNACION, DESCRIPCION
`LISTAEXTRACCION`	Listas de extracción para organizar la fase pre-analítica	CLISTAEXTRACCION, FECEXTRACCION, CDPTOSECC
`SEGUIMIENTOPRUEBA`	Seguimiento por fases del proceso analítico. El campo ESTADO (enum `reEstadoProceso`) registra en qué fase del ciclo se encuentra cada prueba, paralelo a PRUEBAASISTENCIA.ESTADO	PR04NUMACTPLAN (FK), ESTADO, FECESTADO

📋 PR – Plan de Actuaciones Clínicas

Con 593 tablas y el mayor volumen de triggers (56+ solo en PR0400), PR gestiona todo el plan clínico del paciente. La tabla PR0400 (PRUEBAASISTENCIA) es el nexo crítico entre el plan clínico y el laboratorio.

Tabla	Descripción	Relevancia Lab
`PR0400`	PRUEBAASISTENCIA: instancia de una actuación planificada para un paciente. Contiene ESTADO (máquina de estados) y PR04NUMACTPLAN (clave única global)	⭐ Máxima – nexo principal
`PR0100`	Catálogo de actuaciones clínicas. Cada prueba de laboratorio tiene una actuación PR01 correspondiente	Alta – catálogo de pruebas
`PR0300`	Petición de actuaciones	Alta – solicitud de análisis
`PR1200`	Actividades dentro de una actuación	Media
`PR3700`	Estado de la actuación planificada	Alta – máquina de estados
`PR9200`	Cuestionarios clínicos	Media – datos clínicos adicionales
`PR9800`	Numeración de cuestionarios	Baja

⚠️

PR04NUMACTPLAN – Identificador Global Este campo es la clave foránea más referenciada del sistema. Aparece en CUNLAB (PRUEBAASISTENCIA), AD (codificación diagnóstica), FA (facturación), IM (documentos) y muchas otras tablas. Rango observado en datos reales: ~3.6M–4.1M.

🏥 CI – Historia Clínica

344 tablas que modelan al paciente y su historial. El laboratorio referencia CI para obtener datos demográficos del paciente al emitir informes.

Tabla	Descripción
`CI2200`	Historia clínica maestra (CI22NUMHISTORIA = número de historia único)
`CI2100`	Persona/paciente (CI21CODPERSONA = identificador persona)
`CI3000`	Maestro de sexos (CI30CODSEXO)
`CI3200`	Tipo económico (mutua/privado/SS) – referenciado en facturación y circuito asistencial
`CI1300`	Entidad aseguradora

🔐 SG – Seguridad y Usuarios

114 tablas que gestionan usuarios, roles y permisos. Cada tabla de todos los esquemas tiene campos SG02COD_ADD y SG02COD_UPD que referencian a SG0200.

Tabla	Descripción
`SG0200`	Maestro de usuarios del sistema (código, nombre, apellidos, firma digital)
`SG0100`	Perfiles/roles de seguridad
`SG0300`	Asignación de perfiles a usuarios

ℹ️

Los códigos de usuario tienen formato corto (ej. EALM, DBE, RMLEV, SPP1). Algunos registros históricos muestran ????? como usuario, indicando migración desde sistemas anteriores sin auditoría.

🏢 AD – Administración Hospitalaria

Con 439 tablas, AD es el esquema de gestión administrativa. Modela la estructura organizativa del hospital y es la fuente de verdad para departamentos, camas y asistencias.

Tabla	Nombre	Relevancia Lab
`AD0100`	ASISTENCIA – Episodio asistencial del paciente	Alta – contexto de cada solicitud
`AD0200`	DEPARTAMENTO – Catálogo de departamentos CUN	⭐ Máxima – DPTOSECC referencia AD02CODDPTO
`AD0300`	DEPARTAMENTO USUARIO – Asignación usuarios a dptos	Media
`AD0700`	PROCESO – Proceso clínico del paciente	Media
`AD0800`	PROCESO ASISTENCIA – Asociación proceso-asistencia	Alta – clave del episodio
`AD1000`	TIPO PACIENTE – Clasificación de pacientes	Media
`AD1500`	CAMA – Gestión de camas hospitalarias	Baja (pacientes ingresados)
`AD3900`	Tabla maestra de diagnósticos (CIE)	Media – diagnósticos al alta
`AD4000`	Diagnósticos y Procedimientos de Pacientes	Media
`AD7400`	CENTRO – Pamplona (1) y Madrid (2)	⭐ Máxima – discrimina bicentro

Estructura Departamental en AD0200

Los departamentos laboratoriales en AD0200 son la clave que conecta CUNLAB con el resto del hospital:

AD02CODDPTO	Denominación	Secciones CUNLAB
201	SERV. HEMATOLOGÍA	CDPTOSECC 4 (Hematología), 5 (Morfología), 6 (Banco Sangre), 7 (Coagulación)
202	SERV. BIOQUÍMICA	CDPTOSECC 1 (Bioquímica), 2 (Hormonas), 3 (Orinas)
203	SERV. MICROBIOLOGÍA	CDPTOSECC 8 (Microbiología), 11 (Serología), 39 (Bacteriología), 74 (Micro Core)
221	INMUNOLOGÍA/INMUNOPATOLOGÍA	CDPTOSECC 57 (Citometría), sección 21
498	LABORATORIO CENTRAL / COORDINACIÓN	CDPTOSECC 67 (Lab. Central), 68 (Preanalítica)

💰 FA – Facturación y Gestión Económica

Con 741 tablas (el esquema más grande), FA gestiona todo el circuito económico hospitalario. Las actuaciones de laboratorio generan cargos facturables a través de las relaciones entre PR0400 y FA.

Tabla	Descripción
`F2_FACTURA / FA0000`	Facturas (migración Salesforce). Nuevas tablas de integración con CRM externo
`FAA2`	Cuentas económicas – referenciadas desde AD1100 (responsable económico)
`FAI7`	Tipos de volante de facturación
`FAJ6`	Campañas de facturación – vinculadas a asistencias
`FAT6`	Tratamientos con contexto económico (ej. oncología)

ℹ️

Relevancia para Laboratorio: Las pruebas de laboratorio son actuaciones facturables (PR0100 con tarifa asignada). FA recibe los cargos generados al completar las pruebas. Campañas especiales (FAJ6) pueden modificar el circuito económico de ciertos análisis.

📄 IM – Documentación Médica e Informes

144 tablas para gestión documental clínica. El laboratorio genera informes (IM0100) como resultado de la validación de pruebas.

Tabla	Nombre	Función
`IM0100`	DOCUMENTOS	Documento clínico genérico. IM01NUMDOC referenciado desde AD0800
`IM0300`	Creación de documentos	Registro del proceso de creación/mecanografía
`IM0800`	Estados de documentos	Máquina de estados del informe: borrador → pendiente firma → firmado
`IM1000`	Tipo de documento	Catálogo de tipos (IM10CODTIDOC)
`IM3300`	Informes quirúrgicos	Informes de intervenciones, incluidos procedimientos de laboratorio especializado
`IM4000+`	Consentimientos Informados	Consentimientos para procedimientos laboratoriales invasivos

2Modelo de Dominio del Laboratorio

El laboratorio de CUN opera un modelo jerárquico: Sección → Prueba/Carpeta → Instancia (PruebaAsistencia) → Resultado. Las muestras físicas fluyen en paralelo siguiendo su propio ciclo de estados.

Secciones del Laboratorio (DPTOSECC)

La tabla DPTOSECC define las secciones internas del laboratorio, con una estructura jerárquica (CDPTODEPENDIENTE apunta a la sección padre) y enlace al departamento hospitalario (AD02CODDPTO).

CDPTOSECC	Denominación	Sección Padre	AD02CODDPTO	Estado
1	SERV. BIOQUÍMICA	–	202	✅ Activa
2	HORMONAS	1 (Bioquímica)	–	✅ Activa
3	ORINAS	1 (Bioquímica)	–	✅ Activa
4	SERV. HEMATOLOGÍA	–	201	✅ Activa
5	MORFOLOGÍA	4 (Hematología)	–	✅ Activa
6	BANCO DE SANGRE	4 (Hematología)	–	✅ Activa
7	COAGULACIÓN	4 (Hematología)	–	✅ Activa
8	SERV. MICROBIOLOGÍA	–	203	✅ Activa
11	SEROLOGÍA	8 (Microbiología)	–	✅ Activa
39	BACTERIOLOGÍA	8 (Microbiología)	–	✅ Activa
57	CITOMETRÍA	21 (Inmunología)	–	✅ Activa
67	LABORATORIO CENTRAL	1 (Bioquímica)	–	✅ Activa
68	PREANALÍTICA	1 (Bioquímica)	–	✅ Activa
73	BANCO DE SANGRE (Madrid)	70	–	✅ Activa
74	MICROBIOLOGÍA CORE	8 (Microbiología)	–	✅ Activa
75	EXTERNAS MICRO	8 (Microbiología)	–	✅ Activa
15	ELECTROLITOS	1 (Bioquímica)	–	❌ Baja
28	BQ MANUAL	1 (Bioquímica)	–	❌ Baja
34	BQ GENERAL	1 (Bioquímica)	–	❌ Baja
43	PRUEBAS ANTERIORES	8 (Microbiología)	–	❌ Baja

Gestión de Muestras (MUESTRAASISTENCIA)

Cada solicitud de laboratorio genera una o varias muestras físicas. El código de muestra sigue el formato AAA-NNNN (3 letras + guión + 4 dígitos), donde las letras codifican información temporal o de origen.

Campo	Descripción	Valores observados
CMUESTRA	Código único de muestra	AAA-0119, ABH-4856, AAS-7488…
CTIPOMUESTRA	Tipo de muestra (tubo/contenedor)	41, 43, 59, 60, 95, 119
ESTADO	Estado de la muestra (enum `reEstadoMuestra`)	1=Pendiente, 2=Extraída, 3=Finalizada, 4=Anulada · El estado 9 (Recibida) es ficticio: no existe en BD; equivale a ESTADO=2 + FECHARECEPCION rellena
VOLUMENPREF	Volumen preferente (mL)	5, 19 mL
VOLUMENMIN	Volumen mínimo aceptado (mL)	1, 19 mL
TIEMPO	Estabilidad (minutos)	0, 15, 45 min
NUMPARTICION	Número de alícuota/partición	1 (siempre primeras)
CLISTAEXTRACCION	Lista de extracción asignada	51, 12482, 13918, 3594…
INDCITOSTATICOS	Indicador muestra citostática	Boolean
CDATALOGGER	Datalogger de temperatura	Trazabilidad cadena frío
CNEVERA / CCUBETA	Posición de almacenamiento	Nevera y cubeta de custodia

Ciclo de Estados de la Muestra

Fuente: enum reEstadoMuestra (VB.NET). El estado 9 (constMUESTRARECIBIDA) es ficticio y no se persiste en la base de datos; representa la condición lógica ESTADO=2 AND FECHARECEPCION IS NOT NULL.

1 · Pendiente
constMUESTRAPENDIENTE

→

2 · Extraída
constMUESTRAEXTRAIDA

→

[9 · Recibida]
constMUESTRARECIBIDA
ficticio: 2+fechaRec

→

3 · Finalizada
constMUESTRAFINALIZADA

4 · Anulada
constMUESTRAANULADA

← desde cualquier estado activo

Valor	Constante	Descripción	Acción típica
1	constMUESTRAPENDIENTE	Muestra creada, pendiente de extracción	INSERT en MUESTRAASISTENCIA al solicitar
2	constMUESTRAEXTRAIDA	Muestra extraída al paciente	UPDATE al registrar extracción; FECHAEXTRACCION rellena
3	constMUESTRAFINALIZADA	Procesamiento de la muestra completado	UPDATE tras cierre del proceso analítico
4	constMUESTRAANULADA	Muestra anulada (cancelada)	UPDATE por anulación de la solicitud o rechazo
9*	constMUESTRARECIBIDA	Estado ficticio – ESTADO=2 + FECHARECEPCION IS NOT NULL	No se persiste en BD; se calcula en código al registrar FECHARECEPCION

ℹ️

Estado 9 — Recibida en laboratorio: La recepción de la muestra en el laboratorio no cambia el campo ESTADO en BD (se mantiene en 2 = Extraída). El código GDL detecta la recepción por la combinación ESTADO=2 AND FECHARECEPCION IS NOT NULL, tratándolo como el estado lógico 9 (constMUESTRARECIBIDA). Esto desencadena la actualización de PRUEBAASISTENCIA.ESTADO a -3 (GBcEstPrRecibida) para las pruebas asociadas.

Seguimiento de Procesos (SEGUIMIENTOPRUEBA)

La tabla SEGUIMIENTOPRUEBA registra el avance por fases del proceso analítico. Complementa a PRUEBAASISTENCIA.ESTADO con un control de proceso más granular, trazando en qué etapa del flujo de trabajo se encuentra cada prueba.

Fases del Proceso (enum reEstadoProceso)

Fuente: enum reEstadoProceso (VB.NET). El valor 0 (Anulación) es especial y puede ocurrir en cualquier fase.

1 · Solicitud
constPROCESOSOLICITUD

→

2 · Asociación
constPROCESOASOCIACION

→

3 · Extracción
constPROCESOEXTRACCION

→

4 · Pet. Repet.
constPROCESOPETREPE

→

5 · Realización
constPROCESOREALIZACION

6 · Ejec. Lista
constPROCESOEJECLISTA

→

7 · Recepción
constPROCESORECEPCION

→

8 · Val. Prov.
constPROCESOVALPROVISIONAL

→

9 · Validación
constPROCESOVALIDACION

0 · Anulación
constPROCESOANULACION

← desde cualquier fase activa

Valor	Constante	Fase del proceso	Relación con PRUEBAASISTENCIA.ESTADO
0	constPROCESOANULACION	Prueba anulada en cualquier punto del proceso	PRUEBAASISTENCIA.ESTADO → 99 (Anulada)
1	constPROCESOSOLICITUD	Solicitud médica registrada	PRUEBAASISTENCIA.ESTADO = 1 (Solicitada)
2	constPROCESOASOCIACION	Asociación de la prueba a muestra y lista de extracción	PRUEBAASISTENCIA.ESTADO = 1-2
3	constPROCESOEXTRACCION	Extracción de muestra al paciente	PRUEBAASISTENCIA.ESTADO = 2-3 (Impresa/Extraída)
4	constPROCESOPETREPE	Petición de repetición de la prueba	PRUEBAASISTENCIA.ESTADO = 90 (Repetida)
5	constPROCESOREALIZACION	Prueba asignada a lista de realización y analizador	PRUEBAASISTENCIA.ESTADO = -3 a 5 (Recibida → Realizando)
6	constPROCESOEJECLISTA	Ejecución en lista del analizador en curso	PRUEBAASISTENCIA.ESTADO = 5 (Realizando)
7	constPROCESORECEPCION	Resultado recibido del analizador	PRUEBAASISTENCIA.ESTADO = 6 (Resultado)
8	constPROCESOVALPROVISIONAL	Validación provisional/técnica pendiente	PRUEBAASISTENCIA.ESTADO = 7-8 (Res.Analiz. / Valid.Téc.)
9	constPROCESOVALIDACION	Validación definitiva completada	PRUEBAASISTENCIA.ESTADO = 9 (Validada) o -1 (Revalidada)

ℹ️

Relación con PRUEBAASISTENCIA: SEGUIMIENTOPRUEBA no reemplaza a PRUEBAASISTENCIA.ESTADO sino que lo complementa con una vista de proceso orientada a fases de workflow. La FK clave es PR04NUMACTPLAN, que vincula cada fila de SEGUIMIENTOPRUEBA con la actuación planificada correspondiente en PR.PR0400 y CUNLAB.PRUEBAASISTENCIA.

Carpetas y Pruebas (CARPETAS / PRUEBAASISTENCIA)

Las Carpetas son el catálogo de pruebas y perfiles del laboratorio. Cada carpeta tiene configuración de ejecución, tiempos de validez (urgente/normal) y puede estar asociada a un autoanalizador específico.

Tipos de Carpeta (campo TIPO)

TIPO	Descripción
1	Carpeta manual – realización manual o sin analizador específico
2	Carpeta automática – enlazada a autoanalizador (CAUTOANALIZADOR definido)

Datos Reales – Carpetas Activas

CCARPETA	Designación	Sección	Tipo	Analizador	Info
477	DET ESPECIAL SR-LCR	24	1	–	Determinaciones especiales suero/LCR
478	EXTRACCIONES	56	1	–	Extracciones para dptos. solicitantes
533	PCA	24	2	128	Prueba con CC automático. TVALIDNOURG=20160 min
583	EXTERNAS IVAMI	11 (Serología)	1	–	Lab. externo: Inst. Valenciano Microbiología
584	EXTERNAS cerba	11 (Serología)	1	–	Lab. externo: cerba internacional
585	EXTERNAS CNM-ISCIII	11 (Serología)	1	–	Lab. externo: Centro Nacional Microbiología
586	EXTERNAS otros	11 (Serología)	1	–	Lab. externo: Otros centros
587	CLINIC	24	1	–	Enviadas al Hospital Clínic Barcelona
591	INVESTIGACION INMUNO	21	1	–	Investigación inmunología
594	ALEX	32	1	–	Panel IgE específica (ALEX)
607	PHORESIS	16	1	196	Electroforesis proteínas
609	SEROLOGÍA 8000	74 (Micro Core)	2	99	Serología COVID/8000 – Micro Core
611	COVID-19	37	1	–	Pruebas COVID-19 (vigente)
616	ANDROLOGÍA	72	1	–	Andrología
621	BA-200	31	2	210 (BA200)	Analizador BA200 Bioquímica
628	SANGRE CAPILAR	67 (Lab. Central)	2	99	Sangre capilar – Lab. Central

Configuración Temporal

Los campos TVALIDURG y TVALIDNOURG definen en minutos el tiempo máximo de validez del resultado (urgente / no urgente). Ejemplo: CCARPETA=533 tiene TVALIDNOURG=20.160 min (14 días).

Autoanalizadores (AUTOANALIZADORES)

Catálogo de equipos analíticos con configuración de comunicación serie, centro asignado y tipo de controlador (middleware).

Equipos Centro Pamplona (AD74CODCENTRO=1) Pamplona

CAUTOANALIZADOR	Designación	Área	Conectado
182	Optilite Pam	PROTEINAS	No
183	EUROBlot Master	INMUNOPATOLOGÍA	No
192	eFlow Pamplona EPU 6881	Línea EPU	Sí (ctrl=1)
193	eFlow Pamplona EPU-XN9100L 6881	Hematología	Sí (ctrl=1)
194	eFlow Pamplona EPU-XN9100R 6881	Hematología	Sí (ctrl=1)
195	eFlow Pamplona EPU-SP10 6881	Hematología	Sí (ctrl=1)
205	COBAS U411	BIOQUIMICA	Sí (ctrl=1)
210	BA200	BIOQUIMICA	No
212	POCone	BIOQUIMICA (POC)	No
108	QIAcube	INMUNOLOGÍA – Extracción DNA	No
202	F2400	–	No

Equipos Centro Madrid (AD74CODCENTRO=2) Madrid

CAUTOANALIZADOR	Designación	Área	Conectado
106	BACKT ALERT	MAD-BACTERIOLOGÍA	Sí (9600 baud)
133	Myla	MAD-BACTERIOLOGÍA	Sí (ctrl=3)
167	eFlow MAD C6000-2	Bioquímica Madrid	Sí (ctrl=1)
168	eFlow MAD C6000-2 e601-1 célula 1	Bioquímica Madrid	Sí (ctrl=1)
169	eFlow MAD C6000-2 ISE	Bioquímica Madrid	Sí (ctrl=1)
170	eFlow MAD C6000-2 c501	Bioquímica Madrid	Sí (ctrl=1)
171	eFlow MAD C6000-2 e601-1 célula 2	Bioquímica Madrid	Sí (ctrl=1)
204	CFX 96	MAD-MICROBIOLOGÍA (PCR)	No
213	POCone	MAD-BIOQUIMICA (POC)	No

ℹ️

Codcontrolador / Middleware: Los valores CODCONTROLADOR=1 corresponden al middleware de la línea eFlow (Roche cobas connection modules u similar). CODCONTROLADOR=3 está asociado a Myla (BD). Los analizadores con INDCONECTADO=0 no tienen interfaz bidireccional activa; los resultados se introducen manualmente o por interfaz unidireccional.

Control de Calidad (LB1000 – LB1200)

El sistema de CC interno gestiona programas por analito y departamento. La tabla LB1000 almacena el catálogo de programas, LB1100 los resultados obtenidos y LB1200 los parámetros estadísticos de evaluación.

Datos Reales – Programas de CC Activos

LB10CODCTRLCALI	Denominación	Dpto (AD02)	Activo
252	SEQC Proteínas	202 (Bioquímica)	✅
262	Metanefrinas plasma	202 (Bioquímica)	✅
267	Cromogranina	202 (Bioquímica)	✅
268	Tiroglobulina marcador	202 (Bioquímica)	✅
271	PreciControl HTLV	203 (Microbiología)	✅
286	QC QUANTA Flash dsDNA	221 (Inmunología)	✅
287	Testosterona Libre	202 (Bioquímica)	✅
305	Catecolaminas en orina	202 (Bioquímica)	✅
308	Serotonina	202 (Bioquímica)	✅
311	Colinesterasa sangre	202 (Bioquímica)	✅
312	Cloruro en sudor	202 (Bioquímica)	✅
335	QC QUANTALYSER TGB INOVA	221 (Inmunología)	❌ Inactivo
336	QC QUANTALYSER TPO INOVA	221 (Inmunología)	❌ Inactivo
341	B-Lactato (PCC1/PCC2)	498 (Lab. Central)	❌ Inactivo
342	B-Litio (PCC1/PCC2)	498 (Lab. Central)	❌ Inactivo
343	B-ORI1/ORI2 6000 1	498 (Lab. Central)	❌ Inactivo
344	B-PC VITD III	498 (Lab. Central)	❌ Inactivo

3Triggers – Lógica de Negocio Reactiva

El sistema implementa 277 triggers distribuidos en 4 esquemas (CUNLAB, PR, CI, AD). Los triggers encapsulan reglas de negocio críticas, especialmente la máquina de estados de PRUEBAASISTENCIA.

Esquema	Nº Triggers	Tabla principal
CUNLAB	~80	PRUEBAASISTENCIA (CUNLAB), MUESTRAASISTENCIA, AUTOANALIZADORES
PR	~140	PR0400 (56 triggers), PR0300, PR1200
CI	~40	CI2200, CI2100
AD	~17	AD0100, AD0800, AD1500

Máquina de Estados – PRUEBAASISTENCIA.ESTADO

El campo ESTADO en PRUEBAASISTENCIA (tanto en CUNLAB como en PR0400) es el corazón del flujo analítico. Los valores provienen del enum GBeGDLEstadoPrueba (alias GBePAEstado). Incluye valores negativos (-3 y -1) que representan estados intermedios de recepción y revalidación. Cada transición puede disparar uno o varios triggers.

Fuente: Enum GBeGDLEstadoPrueba — GBcEstPrNula=0, GBcEstPrSolicitada=1, GBcEstPrImpresa=2, GBcEstPrExtraida=3, GBcEstPrRecibida=-3, GBcEstPrSolicitudRealiz=4, GBcEstPrRealizando=5, GBcEstPrResultado=6, GBcEstPrResultAnaliz=7, GBcEstPrValidTec=8, GBcEstPrValidada=9, GBcEstPrContestManual=80, GBcEstPrRepetida=90, GBcEstPrAnulada=99, GBcEstPrRevalidada=-1

Flujo principal (camino feliz):

0
Nula

1
Solicitada

→

2
Impresa

→

3
Extraída

→

-3
Recibida

→

4
Sol. Realiz.

→

5
Realizando

→

6
Resultado

→

7
Res. Analiz.

→

8
Valid. Téc.

→

9
Validada ✓

Estados especiales:

80
Cont. Manual

resultado introducido manualmente

90
Repetida

requiere nueva realización

99
Anulada

cancelada definitivamente

-1
Revalidada

pendiente nueva validación

ℹ️

ESTADO=80 – Contestada Manualmente (GBcEstPrContestManual) El estado 80 corresponde a pruebas cuyo resultado se ha introducido manualmente, sin pasar por el flujo automático de analizador. Los 2 registros de producción con ESTADO=80 (CCARPETA=192, PR04NUMACTPLAN ~4.15M) son consistentes con este significado: CCARPETA=192 identifica una carpeta de tipo manual o de realización especial.

Detalle de Transiciones y Triggers Asociados

Transición	Trigger(s)	Acción principal
INSERT (→1 Solicitada)	TRG_PRUEBA_INS_*	Crea registro en CUNLAB, actualiza contadores en LISTAREALIZACION, genera alerta si urgente
1→2 (Impresa)	TRG_PRUEBA_IMP_*	Genera etiqueta / hoja de petición, actualiza timestamps de impresión
2→3 (Extraída)	TRG_PRUEBA_EXT_*	Registra FECHAEXTRACCION en MUESTRAASISTENCIA, actualiza estado muestra a extraída
3→-3 (Recibida en lab)	TRG_PRUEBA_REC_*	Registra FECHARECEPCION, actualiza MUESTRAASISTENCIA.ESTADO, valida volumen mínimo
-3→4 (Sol. Realización)	TRG_PRUEBA_SRE_*	Asigna prueba a LISTAREALIZACION y analizador (CAUTOANALIZADOR), crea worklist
4→5 (Realizando)	TRG_PRUEBA_REA_*	Inicio proceso analítico en analizador; bloquea cancelación
5→6 (Resultado)	TRG_PRUEBA_RES_*	Crea registro en RESULTADO con valor bruto; compara con rangos de referencia LB2000-LB2100
6→7 (Resultado Analiz.)	TRG_PRUEBA_ANA_*	Consolida y analiza resultados; aplica reglas de control de calidad; notifica si crítico
7→8 (Valid. Técnica)	TRG_PRUEBA_VTE_*	Técnico confirma resultado; aplica reglas automáticas de aceptación técnica
8→9 (Validada)	TRG_PRUEBA_VAL_* (21 triggers)	Bloquea modificación, genera informe IM, actualiza PR0400.ESTADO, notifica médico peticionario, genera cargo FA
9→-1 (Revalidada)	TRG_PRUEBA_REVAL_*	Desbloquea para corrección, genera registro de auditoría, anula informe anterior (IM0800)
-1→9 (Nueva validación)	TRG_PRUEBA_VAL_*	Re-emite informe con referencia al anterior; genera nuevo cargo FA si procede
→90 (Repetida)	TRG_PRUEBA_REP_*	Genera nueva PRUEBAASISTENCIA (NREPETICION+1); marca original como repetida
→99 (Anulada)	TRG_PRUEBA_ANU_*	Cancelación definitiva; elimina de LISTAREALIZACION; puede anular cargo FA; registra motivo
→80 (Cont. Manual)	TRG_PRUEBA_MAN_*	Resultado introducido manualmente (sin analizador); flujo especial para pruebas no automatizadas

Triggers PR0400 – Plan de Actuaciones

PR0400 tiene 56 triggers, el mayor concentración del sistema. Se organizan por evento y cubren desde la creación de una actuación hasta su facturación y archivado.

Evento	Nº triggers	Función principal
INSERT	~14	Crear registros asociados (PR3700 estado inicial, AD4200 libro admisión, FA cargos pendientes)
UPDATE	~35	Propagar cambios de estado, actualizar AD0800, sincronizar con CUNLAB, notificar, generar documentos IM
DELETE	~5	Cascada de borrado (CUNLAB.PRUEBAASISTENCIA, FA cargos), auditoría
INS/UPD/DEL	~2	Triggers mixtos de sincronización bicentro

Triggers CUNLAB – Lógica Analítica

Los triggers en CUNLAB controlan la integridad del proceso analítico, la actualización de contadores de CC y la sincronización con los sistemas externos de análisis.

Tabla	Evento	Función
PRUEBAASISTENCIA	UPDATE ESTADO	Propaga cambios a PR0400, actualiza LISTAREALIZACION, aplica reglas de CC
MUESTRAASISTENCIA	INSERT	Valida CTIPOMUESTRA, genera etiqueta, asigna CLISTAEXTRACCION si aplica
MUESTRAASISTENCIA	UPDATE ESTADO / FECHARECEPCION	ESTADO=2 (Extraída): extracción confirmada. Al rellenar FECHARECEPCION con ESTADO=2 (virtual ESTADO=9 Recibida), actualiza PRUEBAASISTENCIA.ESTADO a -3 (GBcEstPrRecibida) y desbloquea pruebas pendientes de muestra
AUTOANALIZADORES	UPDATE INDCONECTADO	Actualiza disponibilidad de carpetas asociadas, genera alerta si conexión perdida
LB1100 (Resultados CC)	INSERT	Calcula alertas Westgard, actualiza estadísticas del programa, genera incidencia si falla

4Integración Cross-Schema

El laboratorio (CUNLAB) está profundamente integrado con los demás esquemas. Se han identificado 128 referencias foráneas cruzadas desde CUNLAB hacia otros esquemas.

Esquema origen	Campo FK	Referencia	Significado
CUNLAB.DPTOSECC	AD02CODDPTO	AD.AD0200	Departamento hospitalario de la sección
CUNLAB.AUTOANALIZADORES	AD74CODCENTRO	AD.AD7400	Centro (Pamplona/Madrid) del equipo
CUNLAB.PRUEBAASISTENCIA	PR04NUMACTPLAN	PR.PR0400	Actuación planificada en el plan clínico
CUNLAB.MUESTRAASISTENCIA	AD74CODCENTRO	AD.AD7400	Centro donde se procesa la muestra
CUNLAB.LB1000	AD02CODDPTO	AD.AD0200	Departamento responsable del programa CC
PR.PR0400	CI21CODPERSONA	CI.CI2100	Paciente al que se solicita la prueba
PR.PR0400	AD01CODASISTENCI	AD.AD0100	Asistencia en el marco de la cual se solicita
AD.AD0200	AD74CODCENTRO	AD.AD7400	Centro del departamento
AD.AD1100	FAA2NUMCUENTA	FA.FAA2	Cuenta económica del responsable
AD.AD0800	IM01NUMDOC	IM.IM0100	Documento clínico asociado al proceso

Flujo de Integración Principal

Solicitud Médica (PR)

Médico crea actuación en PR0400 con tipo analítica. Trigger INSERT genera registro en CUNLAB.PRUEBAASISTENCIA (ESTADO=1).

Identificación Paciente (CI)

PR0400 referencia CI21CODPERSONA y CI22NUMHISTORIA. El laboratorio obtiene datos demográficos para el informe desde CI.

Contexto Asistencial (AD)

AD0100.AD01CODASISTENCI vincula la prueba al episodio. AD0200 identifica el departamento solicitante y el laboratorio responsable.

Proceso Analítico (CUNLAB)

CUNLAB gestiona el ciclo completo: recepción muestra, realización en autoanalizador, CC, validación. Estado evoluciona 1→9.

Informe (IM)

Al validar (ESTADO=9), trigger genera documento IM0100. El informe sigue su propio ciclo de firma en IM0800.

Facturación (FA)

La validación genera cargo económico en FA asociado a la asistencia (AD1100) y tipo económico del paciente (CI3200).

5Procesos de Laboratorio

Esta sección describe los procesos funcionales del laboratorio derivados del análisis del modelo de datos y los triggers. Se distinguen las tres fases clásicas del proceso analítico más procesos transversales.

5.1 · Fase Pre-Analítica

La pre-analítica cubre desde la solicitud médica hasta la llegada de la muestra al laboratorio en condiciones adecuadas para su análisis.

5.1.1 Solicitud de Análisis

El médico o enfermero solicita pruebas desde el sistema clínico (PR). La solicitud crea registros en PR0400 con ESTADO=1 que generan vía trigger los registros correspondientes en CUNLAB.PRUEBAASISTENCIA.

Médico solicita actuación

INSERT en PR0400 con tipo analítica. Los triggers de INSERT (~14) crean: registro PR3700 (estado inicial), CUNLAB.PRUEBAASISTENCIA (ESTADO=1), y pueden pre-asignar carpeta/autoanalizador según la actuación.

Clasificación automática

Según la carpeta (CCARPETA), el sistema determina: sección responsable (CDPTOSECC), autoanalizador asignado (CAUTOANALIZADOR si TIPO=2), y lista de realización (CLISTAREALIZACION).

Asignación a lista de extracción

Si la prueba requiere extracción de sangre, se asigna a LISTAEXTRACCION. La enfermera de extracciones (sección 68 – PREANALÍTICA o carpeta 478 – EXTRACCIONES) gestiona el orden de extracción.

5.1.2 Extracción y Recogida de Muestras

La extracción genera registros en MUESTRAASISTENCIA. Cada muestra tiene un código único (formato AAA-NNNN) y un tipo de muestra (CTIPOMUESTRA) que determina el contenedor y condiciones de manejo.

Código de muestra: AAA-NNNN. Las tres letras codifican información temporal (se observa progresión: AAA, AAE, AAQ, AAS, ABG, ABH…)
Volumen preferente / mínimo: Configurado en MUESTRAASISTENCIA (ej. 5 mL pref / 1 mL mín para tubo de sangre estándar; 19 mL para tipos especiales)
Tiempo de estabilidad: Campo TIEMPO en minutos (ej. 45 min para algunas muestras de Bioquímica)
Partición: NUMPARTICION permite gestionar alícuotas. NUMPARTICION=1 indica muestra primaria
Indicador citostático: INDCITOSTATICOS marca muestras de pacientes en quimioterapia (manejo especial)

5.1.3 Recepción en Laboratorio

La recepción actualiza el ESTADO de MUESTRAASISTENCIA y PRUEBAASISTENCIA. La extracción lleva PRUEBAASISTENCIA a ESTADO=3 (Extraída); la llegada al laboratorio la mueve a ESTADO=-3 (GBcEstPrRecibida), que desbloquea las pruebas en espera de muestra.

Acción	Tabla afectada	Trigger
Registrar llegada muestra	MUESTRAASISTENCIA	UPDATE ESTADO 1→2
Registrar datos recepción	MUESTRAASISTENCIA.FECHARECEPCION, .RESPONSABLERECEPCION	–
Desbloquear pruebas	CUNLAB.PRUEBAASISTENCIA → ESTADO 1→2	TRG_MUESTRA_ESTADO_UPD
Verificar volumen	Validación automática VOLUMENMIN	Trigger de validación
Etiquetado	PRUEBAASISTENCIA.ETIQUETA	Trigger INSERT

5.1.4 Trazabilidad de la Muestra

La trazabilidad se mantiene a través de varios mecanismos:

Cadena de frío: CDATALOGGER registra el logger de temperatura asignado a la muestra
Almacenamiento: CNEVERA (código de nevera) y CCUBETA (cubeta) para localización física
Envío entre centros: FECHAENVIO, SG02COD_ENV registran los envíos Pamplona↔Madrid
Pre-recepción: SG02COD_PRERECEP, FECHAPRERECEP para muestras con aviso previo de llegada
Ciclo de temperatura: LBA6CODCICLO vincula con el sistema de temperatura (tablas LBA6 en CUNLAB)

5.2 · Fase Analítica

La fase analítica comprende la realización de las determinaciones en los equipos del laboratorio. El sistema soporta tanto análisis automatizados (TIPO=2, enlazados a autoanalizador) como manuales (TIPO=1).

5.2.1 Worklist y Asignación a Analizador

La tabla LISTAREALIZACION agrupa las pruebas pendientes por turno y equipo. El proceso de carga del analizador lee esta lista y genera los pedidos de análisis.

Creación de worklist

LISTAREALIZACION se genera automáticamente agrupando PRUEBAASISTENCIA por CDPTOSECC, turno y CAUTOANALIZADOR. Cada entrada tiene FECREALIZACION.

Carga en analizador (equipos conectados)

Para equipos con INDCONECTADO=-1 (ej. eFlow Pamplona/Madrid, BACKT ALERT), el middleware (CODCONTROLADOR) transmite la worklist vía interfaz serie o TCP. CODCONTROLADOR=1 = eFlow / Roche, CODCONTROLADOR=3 = Myla/BD.

Análisis manual

Para equipos con INDCONECTADO=0 (ej. Optilite Pam, QIAcube), el técnico consulta la worklist en pantalla e introduce los resultados manualmente en RESULTADO.

Recepción de resultados

El middleware entrega resultados que se insertan en RESULTADO. El trigger de INSERT actualiza PRUEBAASISTENCIA.ESTADO a 6 (Resultado) y compara con rangos de referencia (CUNLAB.LB2000-LB2100).

5.2.2 Estados del Ciclo de Vida de la Worklist

El campo ESTADO de LISTAREALIZACION controla el ciclo de vida de cada worklist. Fuente: enum constEstadoLista (VB.NET).

1 · Pre-realizando
cteLISTAPREALIZANDO

→

2 · Resultando/Anal.
cteLISTAPRESULTANAL

→

3 · Resultado
cteLISTAPRESULTADO

→

4 · Valid. Técnica
cteLISTAPVALIDTECNI

Valor	Constante	Descripción
1	cteLISTAPREALIZANDO	Lista creada con pruebas pendientes de análisis ("listas que hay que realizar")
2	cteLISTAPRESULTANAL	Análisis en curso: el analizador está procesando ("listas que se están realizando")
3	cteLISTAPRESULTADO	Resultados obtenidos, pendientes de revisión ("listas de las que se han obtenido los resultados")
4	cteLISTAPVALIDTECNI	Validación técnica completada por la enfermera/técnico en GDL ("listas con visto bueno técnico")

5.2.3 Equipos de Alta Automatización

La línea eFlow (cobas connection modules de Roche) en ambos centros integra múltiples módulos analíticos bajo un mismo controlador (CODCONTROLADOR=1):

Pamplona: EPU 6881 + XN9100L/R (hematología) + SP10 (preparación) → CAUTOANALIZADOR 192-195
Madrid: C6000-2 con e601 célula 1/2, ISE, c501 → CAUTOANALIZADOR 167-171

La bacteriología de Madrid opera con BACKT ALERT (CAUTOANALIZADOR=106, hemocultivos) y Myla (CAUTOANALIZADOR=133, gestor de muestras BD). El CFX 96 (CAUTOANALIZADOR=204) gestiona las PCR en microbiología de Madrid.

5.2.4 Point-of-Care (POC)

Los analizadores POCone (Pamplona: CAUTOANALIZADOR=212, Madrid: CAUTOANALIZADOR=213) son dispositivos de punto de cuidado para bioquímica urgente. No tienen interfaz bidireccional activa (INDCONECTADO=0), por lo que los resultados se introducen manualmente.

5.2.5 Repetición de Pruebas

El campo NREPETICION en PRUEBAASISTENCIA controla el número de repetición. NREPETICION=1 indica primera realización. Si el resultado es inconsistente o cae fuera de un rango crítico, el sistema puede generar automáticamente una repetición (NREPETICION=2, 3…) con nuevo registro.

5.3 · Fase Post-Analítica

La post-analítica cubre la validación, el informe y la comunicación del resultado al médico peticionario.

5.3.1 Validación Técnica y Médica

La validación es el proceso más crítico, implementado con 21 triggers en PRUEBAASISTENCIA. Hay dos niveles:

Validación técnica (ESTADO=8): El técnico de laboratorio confirma la corrección del resultado analítico. Transición 7→8.
Validación médica (ESTADO=9): El médico especialista del laboratorio revisa y firma el resultado (8→9). Activa los 21 triggers de generación de informe, facturación y notificación.

ℹ️

Revalidación (ESTADO=-1, GBcEstPrRevalidada): Si se detecta un error tras la validación, el sistema permite volver al estado -1 (revalidada). Los triggers correspondientes anulan el informe anterior (IM0800), generan registro de auditoría y permiten modificar el resultado. Al revalidar de nuevo (→9), se emite un nuevo informe con referencia al anterior. No confundir con ESTADO=90 (Repetida) que implica nueva realización analítica.

5.3.2 Generación de Informes

Al validar (ESTADO=9), los triggers generan:

Documento IM (IM0100)

Se crea un registro en IM0100 con tipo de documento laboratorial. IM01NUMDOC queda referenciado desde AD0800.

Ciclo de firma (IM0800)

El informe entra en el flujo de estados: borrador → pendiente firma → firmado. El campo INDPTEFIRMA controla si está pendiente de firma del médico laboratorista.

Notificación al peticionario

El médico solicitante recibe notificación en su HIS. Si es resultado crítico, el proceso de notificación es urgente (ver 5.3.4).

Actualización PR0400

El trigger actualiza PR0400.ESTADO para reflejar que la actuación está completada, lo que puede disparar a su vez triggers de facturación en FA.

5.3.3 NCOPIASINF – Número de Copias del Informe

El campo NCOPIASINF en CARPETAS (ej. DET ESPECIAL SR-LCR: 1 copia, EXTRACCIONES: 1 copia) configura cuántas copias físicas/digitales se generan del informe. Los informes con múltiples copias se envían a distintos destinatarios (médico solicitante, paciente, consulta de seguimiento).

5.3.4 Resultados Críticos

Cuando un resultado supera los umbrales críticos (configurados en CUNLAB.LB2000 – rangos de referencia), el trigger de validación activa el proceso de comunicación urgente:

Genera alerta inmediata en la interfaz del médico (PR0400.ESTADO marca urgencia)
Registra en tabla de auditoría de alertas críticas (LB tablas de alertas en CUNLAB)
El laboratorista llama directamente al médico/enfermería (proceso manual verificado con registro en CUNLAB)
El campo DEMORADA en PRUEBAASISTENCIA indica si la prueba tiene una demora aceptada

5.3.5 Tiempos de Respuesta Configurados

Tipo	Campo	Ejemplo
Urgente	CARPETAS.TVALIDURG	No configurado en la muestra analizada → requiere verificación
No urgente	CARPETAS.TVALIDNOURG	CCARPETA=533: 20.160 min (14 días)
Estabilidad muestra	MUESTRAASISTENCIA.TIEMPO	15-45 min para algunos analitos de Bioquímica

5.4 · Control de Calidad Interno

El CC interno asegura la exactitud y precisión de las determinaciones analíticas. El sistema GDL implementa CC con reglas de Westgard a través de las tablas LB1000-LB1300.

Estructura del CC

Programa de CC (LB1000)

Define el analito, el material de control (nivel bajo/medio/alto), el departamento responsable y el tipo de evaluación. Ejemplo: "SEQC Proteínas" del dpto. 202 (Bioquímica).

Resultado de CC (LB1100)

Cada vez que se pasa el control, se inserta un registro en LB1100 con el valor obtenido. El trigger de INSERT calcula desviación respecto a la media (LB1200) y evalúa reglas de Westgard.

Estadísticas (LB1200)

Almacena media, SD, CV% y límites de acción por programa y período. Se actualiza automáticamente con cada resultado.

Alarma CC

Si se viola una regla (1-2s, 1-3s, R-4s, etc.), el trigger bloquea las pruebas del analizador (PRUEBAASISTENCIA marcadas como pendientes de revisión CC) hasta que el técnico libere el equipo.

CC Externo (SEQC)

El programa SEQC Proteínas (LB10CODCTRLCALI=252) es un CC externo participado en el esquema de la Sociedad Española de Química Clínica. Los resultados se comparan con los de otros laboratorios participantes para verificar comparabilidad interlaboratorio.

CC de Inmunología

Los programas QUANTA Flash dsDNA (286), QUANTALYSER TGB (335) y QUANTALYSER TPO (336) son específicos de la sección de Inmunología/Inmunopatología (dpto. 221). Los programas 335 y 336 están actualmente inactivos, posiblemente por cambio de tecnología o proveedor.

Referencia CC en Prueba Asistencial

El campo LB12CODPRGCTCALI en PRUEBAASISTENCIA vincula directamente una prueba de paciente con el programa de CC activo en ese momento, permitiendo correlacionar resultados de paciente con el estado del CC del equipo.

El campo PR04NUMACTPLAN_CC almacena la actuación planificada del CC, distinguiendo registros de CC de los de paciente real cuando coexisten en la tabla.

5.5 · Derivación a Laboratorios Externos

Cuando una determinación no puede realizarse internamente (por capacidad, especialización o equipamiento), se deriva a un laboratorio externo. El sistema gestiona las derivaciones a través de carpetas específicas.

Laboratorios Externos Configurados

CCARPETA	Laboratorio	Tipo	Sección
583	EXTERNAS IVAMI	Instituto Valenciano de Microbiología (Valencia)	11 – Serología
584	EXTERNAS cerba	Cerba Internacional (laboratorio de referencia)	11 – Serología
585	EXTERNAS CNM-ISCIII	Centro Nacional de Microbiología (Majadahonda)	11 – Serología
586	EXTERNAS otros	Otros centros de referencia	11 – Serología
587	CLINIC	Hospital Clínic de Barcelona	24

Proceso de Derivación

Identificación necesidad de derivación

El técnico o sistema determina que la prueba debe anularse en el laboratorio interno y crearse en el externo. Se cambia el ESTADO a 99 (GBcEstPrAnulada — anulada en el contexto de derivación).

Creación solicitud externa

Los triggers de ESTADO→99 crean un registro secundario en la carpeta externa correspondiente (ej. CCARPETA=583). El TIPO=1 de estas carpetas indica proceso manual. El resultado del laboratorio externo se introduce manualmente (→ESTADO=80 GBcEstPrContestManual o directo →9 si procede).

Envío muestra

La muestra original o alícuota se prepara para envío. MUESTRAASISTENCIA registra FECHAENVIO y SG02COD_ENV (usuario que realizó el envío).

Recepción resultado externo

El resultado llega del laboratorio externo. Se introduce manualmente en el sistema (ESTADO=80 Contestada Manualmente) y se valida (→9). El informe incluye la referencia al laboratorio externo.

5.6 · Gestión de Resultados Críticos

Los resultados que superan los umbrales de valores críticos requieren comunicación urgente al clínico. El sistema tiene mecanismos específicos implementados en los triggers de validación.

Detección automática: Al insertar resultado en CUNLAB.RESULTADO, trigger compara con LB2000 (valores de referencia). Si supera umbral crítico, marca PRUEBAASISTENCIA con indicador de urgencia
Bloqueo de validación sin confirmación: El sistema requiere que el validador confirme explícitamente la comunicación al clínico antes de poder validar un resultado crítico
Registro de comunicación: Se genera registro de auditoría con timestamp de comunicación y usuario que comunicó
Renotificación: Si el clínico no acusa recibo en un tiempo configurado, el sistema puede re-alertar

⚠️

Información Pendiente de Verificación: La configuración exacta de valores de umbral crítico por analito no está documentada en los esquemas analizados. Se recomienda consultar la tabla CUNLAB.LB2000 (rangos de referencia) y las tablas de alertas críticas para obtener los valores actuales.

5.7 · Estructura Bicentro: Pamplona y Madrid

El sistema gestiona de forma unificada los dos centros de CUN. El campo AD74CODCENTRO (valor 1=Pamplona, 2=Madrid) discrimina los recursos, pruebas y muestras de cada centro.

Aspecto	Pamplona (AD74CODCENTRO=1)	Madrid (AD74CODCENTRO=2)
Equipos analíticos	eFlow EPU (Hematología), COBAS U411, BA200, POCone, Optilite, EUROBlot, QIAcube	eFlow C6000-2 (Bioquímica), BACKT ALERT, Myla, CFX 96, POCone
Bacteriología	Integrada en Microbiología	BACKT ALERT + Myla (MAD-BACTERIOLOGÍA)
Bioquímica	BA200 + COBAS U411	eFlow C6000-2 con módulos e601/ISE/c501
PCR/Genómica	QIAcube (extracción DNA)	CFX 96 (PCR tiempo real)
POC	POCone 212	POCone 213
Serología COVID	–	Serología 8000 (carpeta 609, Micro Core)

Coordinación Bicentro

Muestras compartidas: MUESTRAASISTENCIA.FECHAENVIO y SG02COD_ENV permiten registrar el transporte de muestras entre centros
Resultados unificados: Independientemente del centro de análisis, el resultado queda en la historia clínica única del paciente (CI)
Triggers de sincronización: Algunos triggers mixtos (INS/UPD/DEL) en PR0400 gestionan la sincronización de datos entre los dos nodos Oracle (si hay instancias separadas) o garantizan la coherencia bicentro en instancia única
CC bicentro: Los programas de CC son independientes por centro, garantizando que cada equipo mantiene sus propias estadísticas

6Datos Reales de Referencia

Esta sección consolida los datos reales obtenidos de las muestras de producción, organizados por tabla para referencia rápida.

DPTOSECC – Secciones del Laboratorio (muestra)

Datos reales de la tabla DPTOSECC, incluyendo jerarquía y enlace a departamentos hospitalarios.

CDPTOSECC	DESIGNACION	CDPTODEPENDIENTE	AD02CODDPTO	INDBAJA
1	SERV. BIOQUÍMICA	–	202	–
4	SERV. HEMATOLOGÍA	–	201	–
8	SERV. MICROBIOLOGÍA	–	203	–
67	LABORATORIO CENTRAL	1	–	–
68	PREANALÍTICA	1	–	–
74	MICROBIOLOGÍA CORE	8	–	–
75	EXTERNAS MICRO	8	–	–
15	ELECTROLITOS	1	–	-1 (baja)
28	BQ MANUAL	1	–	-1 (baja)
34	BQ GENERAL	1	–	-1 (baja)
43	PRUEBAS ANTERIORES	8	–	-1 (baja)

PRUEBAASISTENCIA – Muestra de Datos Reales

CCARPETA	CLISTAREALIZACION	ESTADO	PR04NUMACTPLAN	Nota
105	654	9 (validada)	4.068.460	Estado normal
50	669	9 (validada)	4.068.464	Estado normal
3	663	9 (validada)	4.151.385	Estado normal
4	671	9 (validada)	4.151.387	Estado normal
192	644	80	4.151.399	Contestada manualmente (GBcEstPrContestManual)
192	644	80	4.151.400	Contestada manualmente (GBcEstPrContestManual)
133	672	9 (validada)	3.648.395	Estado normal

MUESTRAASISTENCIA – Tipos de Muestra Observados

CTIPOMUESTRA	Descripción estimada	VOLUMENPREF (mL)	TIEMPO estabilidad
41	Suero/sangre estándar	5	15-45 min
43	Sangre EDTA	5	–
59	Suero (tipo 59)	–	–
60	Plasma (tipo 60)	–	–
95	Tipo especial 95	–	–
119	Tipo especial 119	19	0

⚠️

Los nombres/descripciones de CTIPOMUESTRA son estimaciones basadas en volumen y contexto. La tabla maestra TIPOMUESTRA contiene la denominación oficial. Se recomienda extraer una muestra completa de TIPOMUESTRA para documentación definitiva.

LB1000 – Programas CC por Departamento

Dpto	Programas activos
202 – Bioquímica	SEQC Proteínas (252), Metanefrinas plasma (262), Cromogranina (267), Tiroglobulina (268), Testosterona Libre (287), Catecolaminas orina (305), Serotonina (308), 5-OH orina (307), Colinesterasa (311), Cloruro sudor (312)
203 – Microbiología	PreciControl HTLV (271)
221 – Inmunología	QC QUANTA Flash dsDNA (286) – activo; QUANTALYSER TGB/TPO (335/336) – inactivos
498 – Lab. Central	B-Lactato (341), B-Litio (342), B-ORI (343), B-PC VITD III (344), B-CO2 (345) – todos inactivos

7Diagramas y Relaciones

Representaciones visuales de los flujos funcionales, la máquina de estados del proceso analítico y las relaciones estructurales entre tablas clave del sistema.

7.1 · Flujo Analítico Completo

El ciclo completo desde la solicitud médica hasta la entrega del informe, mostrando las tablas involucradas en cada fase.

flowchart TD A["👨‍⚕️ MÉDICO\nSolicitud"] --> B["PR.PR0400\nActuación Planificada\nESTADO=1"] B -->|"trigger INSERT\n~14 triggers"| C["CUNLAB.PRUEBAASISTENCIA\nESTADO=1 Solicitada"] C --> D["CUNLAB.LISTAEXTRACCION\nAsignación extracción"] D --> E["CUNLAB.MUESTRAASISTENCIA\nESTADO=1 Activa\nCMUESTRA=AAA-NNNN"] E -->|"Extracción\nESTADO=3"| F["MUESTRAASISTENCIA\nESTADO=2 Procesada"] F -->|"trigger UPDATE\nRecepción lab"| G["PRUEBAASISTENCIA\nESTADO=-3 Recibida"] G --> H["CUNLAB.LISTAREALIZACION\nWorklist"] H --> I{"TIPO\nCARPETA"} I -->|"TIPO=2\nConectado"| J["AUTOANALIZADORES\nINDCONECTADO=-1\nMiddleware"] I -->|"TIPO=1\nManual"| K["Técnico\nIntroduce resultado"] J -->|"Resultado"| L["CUNLAB.RESULTADO\nValor analítico"] K --> L L -->|"trigger INSERT"| M["PRUEBAASISTENCIA\nESTADO=6 Resultado\n→7 Analizado\n→8 Valid.Téc."] M --> N["Validación Técnica"] N -->|"21 triggers\n(8→9)"| O["PRUEBAASISTENCIA\nESTADO=9 Validada ✓"] O -->|"trigger UPDATE"| P["PR.PR0400\nActuación completada"] O -->|"trigger"| Q["IM.IM0100\nInforme generado"] O -->|"trigger"| R["FA\nCargo económico"] Q --> S["IM.IM0800\nEstado firma\n→ Firmado"] S --> T["📋 INFORME\nEntregado al médico"] style A fill:#EBF3FB,stroke:#2E75B6 style B fill:#fff5f0,stroke:#e67e22 style C fill:#f0f7ff,stroke:#2E75B6 style E fill:#f0f7ff,stroke:#2E75B6 style O fill:#d4edda,stroke:#28a745 style P fill:#fff5f0,stroke:#e67e22 style Q fill:#f0fffe,stroke:#16a085 style R fill:#fff0f0,stroke:#e74c3c style T fill:#d4edda,stroke:#28a745

7.2 · Flujo HL7 CUN ↔ Modulab — Diagrama de Calles

Representación swimlane del intercambio de mensajería HL7 v2.5 entre CUN (GDL Oracle) y Modulab (LIS Werfen). La calle izquierda muestra los estados internos de CUN; la calle derecha los eventos en Modulab. Las flechas numeradas son los mensajes MLLP/TCP que cruzan entre sistemas.

Flujo Principal (Happy Path)

Ciclo completo desde la petición hasta la validación clínica. Los estados internos de GDL (2 Impresa, 3 Extraída, 4 Sol.Realiz., 5 Realizando, 7 Res.Analiz.) no generan mensajes HL7 y se omiten del diagrama por claridad.

flowchart LR subgraph CUN ["🏥 CUN · GDL Oracle"] direction TB c1["ESTADO=1 · Solicitada\n[INSERT PR0400 + PRUEBAASISTENCIA]"] c1b["ESTADO=1 · Confirmada\n[Filler Order Number guardado]"] cN3["ESTADO=−3 · Recibida en lab\n[MUESTRAASISTENCIA: FECHARECEPCION\nESTADO virtual=9 · Recibida]"] c6["ESTADO=6 · Resultado\n[LISTAREALIZACION.ESTADO=3]"] c8["ESTADO=8 · Valid. Técnica\n[LISTAREALIZACION.ESTADO=4\nSEGUIMIENTOPRUEBA.ESTADO=8]"] c9(["✅ ESTADO=9 · Validada\n→ Informe IM0100\n→ Cargo FA\n→ Notificación peticionario"]) c1 --> c1b c1b --> cN3 cN3 --> c6 c6 --> c8 c8 --> c9 end subgraph MOD ["🔬 Modulab · LIS (Werfen)"] direction TB m1["Petición aceptada\n[Asigna Filler Order Number\nOBR-3]"] m2["Container check\n[Tubo físico recepcionado\nen el LIS]"] m3["Tech. Validation\n[Resultado obtenido\ndel analizador]"] m4["Tech. Validation\n[Técnico LIS\nvalida técnicamente]"] m5(["✅ Clin. Validation\n[Clínico LIS\nvalida el resultado]"]) m1 --> m2 m2 --> m3 m3 --> m4 m4 --> m5 end c1 -->|"① OML^O21\nORC-1=NW · ORC-4=PR04NUMACTPLAN\nMSH-4=PAMPLONA o MADRID"| m1 m1 -->|"② ORL^O22\nORC-1=SN · OBR-3=FillerOrderNum"| c1b m2 -->|"③ ORU^R01 · Container check\nOBR-25=I/P · CUN responde ACK^R01"| cN3 m3 -->|"④ ORU^R01 · Tech.Validation\nOBR-25=R · CUN responde ACK^R01"| c6 m4 -->|"⑤ ORU^R01 · Tech.Validation\nOBR-25=P o F · CUN responde ACK^R01"| c8 m5 -->|"⑥ ORU^R01 · Clin.Validation\nOBR-25=F · OBX-11=F · CUN responde ACK^R01"| c9 style c9 fill:#d4edda,stroke:#28a745 style m5 fill:#d4edda,stroke:#28a745 style cN3 fill:#EBF3FB,stroke:#2E75B6 style c8 fill:#EBF3FB,stroke:#2E75B6

Flujos Alternativos

Los tres flujos alternativos principales: cancelación, corrección post-cierre (revalidación) y repetición de prueba.

flowchart LR subgraph CANCEL ["❌ Cancelación"] direction TB ca1["ESTADO activo\n(cualquier fase)"] ca2[/"📤 OML^O21\nORC-1=CA"/] ca3["Modulab procesa\ncancelación"] ca4[/"📥 ORL^O22\nORC-1=CR"/] ca5(["ESTADO=99\nAnulada\nGBcEstPrAnulada"]) ca1 --> ca2 --> ca3 --> ca4 --> ca5 end subgraph REVAL ["🔄 Revalidación"] direction TB rv1(["ESTADO=9\nValidada · cerrada"]) rv2["Modulab emite\ncorrección"] rv3[/"📥 ORU^R01\nOBR-25=C\n(Corrected)"/] rv4["CUN responde\nACK^R01"] rv5(["ESTADO=−1\nRevalidada\nGBcEstPrRevalidada\n→ Anula informe anterior\n→ Genera informe corregido"]) rv1 --> rv2 --> rv3 --> rv4 --> rv5 end subgraph REPET ["♻️ Repetición"] direction TB re1(["ESTADO=9\nValidada · resultado\ninconsistente"]) re2["Técnico solicita\nrepetición en GDL"] re3["ESTADO=90\nRepetida\nGBcEstPrRepetida"] re4[/"📤 OML^O21\nORC-1=NW\nNREPETICION=2 (o >2)"/] re5["Modulab procesa\nnueva petición"] re6[/"📥 ORL^O22\nORC-1=SN\n(nuevo filler number)"/] re7["Ciclo reinicia\ndesde ESTADO=−3\no ESTADO=6"] re1 --> re2 --> re3 --> re4 --> re5 --> re6 --> re7 end style ca5 fill:#f8d7da,stroke:#dc3545 style rv5 fill:#fff3cd,stroke:#ffc107 style re7 fill:#d4edda,stroke:#28a745

#	Mensaje HL7	Dirección	Trigger en Modulab	ESTADO GDL resultante
①	OML^O21 · ORC-1=NW	CUN → Modulab	Nueva petición de análisis	1 Solicitada (estado inicial)
②	ORL^O22 · ORC-1=SN	Modulab → CUN	Respuesta funcional a OML	1 (+ Filler Order Number registrado)
③	ORU^R01 · OBR-25=I/P	Modulab → CUN	Container check (tubo recibido)	-3 Recibida · GBcEstPrRecibida
④	ORU^R01 · OBR-25=R	Modulab → CUN	Tech. Validation (resultado analizador)	6 Resultado
⑤	ORU^R01 · OBR-25=P/F	Modulab → CUN	Tech. Validation (técnico LIS)	8 Valid. Técnica
⑥	ORU^R01 · OBR-25=F · OBX-11=F	Modulab → CUN	Clin. Validation (clínico LIS)	9 Validada ✓
⑦⑧	OML^O21 CA → ORL^O22 CR	CUN → Modulab → CUN	Cancelación	99 Anulada
⑨	ORU^R01 · OBR-25=C	Modulab → CUN	Corrección post-cierre	-1 Revalidada · GBcEstPrRevalidada
⑩	OML^O21 NW · NREPETICION>1	CUN → Modulab	Repetición de análisis	90 Repetida → reinicia ciclo

7.3 · Máquina de Estados – PRUEBAASISTENCIA.ESTADO

Diagrama completo de transiciones basado en el enum GBeGDLEstadoPrueba. Los estados negativos (-3 Recibida, -1 Revalidada) se representan con alias sN3 y sN1.

stateDiagram-v2 [*] --> s1 : INSERT PR0400\n(trigger ~14) s0 : 0 · Nula s1 : 1 · Solicitada s2 : 2 · Impresa s3 : 3 · Extraída sN3 : -3 · Recibida en lab s4 : 4 · Sol. Realización s5 : 5 · Realizando s6 : 6 · Resultado s7 : 7 · Resultado Analiz. s8 : 8 · Valid. Técnica s9 : 9 · Validada ✓ s80 : 80 · Cont. Manual s90 : 90 · Repetida s99 : 99 · Anulada sN1 : -1 · Revalidada s1 --> s2 : Impresión petición s2 --> s3 : Extracción muestra s3 --> sN3 : Recepción laboratorio\n(TRG_PRUEBA_REC_*) sN3 --> s4 : Solicitud realización\n(asigna analizador) s4 --> s5 : Inicio análisis s5 --> s6 : Resultado bruto obtenido s6 --> s7 : Análisis CC y rangos s7 --> s8 : Validación técnica s8 --> s9 : Validación médica\n(21 triggers) s9 --> sN1 : Error post-validación\n(anula informe) sN1 --> s9 : Re-validación\n(nuevo informe IM) s1 --> s99 : Anulación temprana s3 --> s99 : Anulada tras extracción sN3 --> s99 : Muestra rechazada s5 --> s90 : Resultado inconsistente\n(genera repetición) s7 --> s90 : Repetición por CC s5 --> s80 : Resultado manual\n(sin analizador) s6 --> s80 : Resultado manual s80 --> s9 : Validación normal\n(21 triggers) note right of s9 Al validar (ESTADO=9): 1. Actualiza PR0400.ESTADO 2. Genera IM0100 (informe) 3. Crea cargo en FA 4. Notifica médico peticionario end note note right of sN3 ESTADO=-3 (GBcEstPrRecibida) Valor negativo en Oracle. Recepción física del tubo en las instalaciones del lab. end note note right of s80 ESTADO=80 (GBcEstPrContestManual) Resultado introducido manualmente. 2 registros en prod: CCARPETA=192. end note

7.4 · Relaciones entre Tablas Principales

Diagrama entidad-relación simplificado mostrando las claves primarias, foráneas y las relaciones más relevantes entre los siete esquemas.

erDiagram CI_CI2100 { number CI21CODPERSONA PK string NOMBRE string PRIAPEL string SEGAPEL } CI_CI2200 { number CI22NUMHISTORIA PK number CI21CODPERSONA FK date FECHANACIMIENTO } AD_AD7400 { number AD74CODCENTRO PK string DESCENTRO } AD_AD0200 { number AD02CODDPTO PK string AD02DESDPTO number AD74CODCENTRO FK } AD_AD0100 { number AD01CODASISTENCI PK number CI21CODPERSONA FK date AD01FECINICIO } AD_AD0800 { number AD07CODPROCESO PK number AD01CODASISTENCI FK number IM01NUMDOC FK } PR_PR0100 { number PR01CODACTUACION PK string PR01DESCORTA string PR01DESCRIPCION } PR_PR0400 { number PR04NUMACTPLAN PK number CI21CODPERSONA FK number AD01CODASISTENCI FK number PR01CODACTUACION FK number ESTADO } CUNLAB_DPTOSECC { number CDPTOSECC PK string DESIGNACION number AD02CODDPTO FK number CDPTODEPENDIENTE FK } CUNLAB_CARPETAS { number CCARPETA PK string DESIGNACION number CDPTOSECC FK number CAUTOANALIZADOR FK number TIPO } CUNLAB_AUTOANALIZADORES { number CAUTOANALIZADOR PK string DESIGNACION number AD74CODCENTRO FK number INDCONECTADO } CUNLAB_PRUEBAASISTENCIA { number PR04NUMACTPLAN FK number CCARPETA FK number NREPETICION number ESTADO number CLISTAREALIZACION FK } CUNLAB_MUESTRAASISTENCIA { string CMUESTRA PK number CTIPOMUESTRA FK number ESTADO number AD74CODCENTRO FK } CUNLAB_LB1000 { number LB10CODCTRLCALI PK string LB10DESIGNACION number AD02CODDPTO FK number LB10INDACTIVO } IM_IM0100 { number IM01NUMDOC PK number CI21CODPERSONA FK date IM01FECDICT number IM01INDPTEFIRMA } SG_SG0200 { string SG02COD PK string SG02NOM string SG02TXTFIRMA } CI_CI2100 ||--o{ CI_CI2200 : "tiene historia" CI_CI2100 ||--o{ AD_AD0100 : "tiene asistencias" AD_AD0200 }o--|| AD_AD7400 : "pertenece a centro" CUNLAB_DPTOSECC }o--o| AD_AD0200 : "mapeado a dpto" CUNLAB_CARPETAS }o--|| CUNLAB_DPTOSECC : "pertenece a sección" CUNLAB_CARPETAS }o--o| CUNLAB_AUTOANALIZADORES : "ejecutada en" CUNLAB_AUTOANALIZADORES }o--|| AD_AD7400 : "ubicado en centro" PR_PR0400 }o--|| CI_CI2100 : "para paciente" PR_PR0400 }o--|| AD_AD0100 : "en asistencia" PR_PR0400 }o--|| PR_PR0100 : "tipo actuación" CUNLAB_PRUEBAASISTENCIA }o--|| PR_PR0400 : "instancia de" CUNLAB_PRUEBAASISTENCIA }o--|| CUNLAB_CARPETAS : "usa carpeta" CUNLAB_LB1000 }o--|| AD_AD0200 : "dpto responsable" AD_AD0800 }o--|| AD_AD0100 : "proceso de asistencia" AD_AD0800 }o--o| IM_IM0100 : "tiene documento" IM_IM0100 }o--|| CI_CI2100 : "documento de paciente"

ℹ️

El diagrama ER muestra las relaciones principales. CUNLAB.PRUEBAASISTENCIA es la tabla central que conecta el plan clínico (PR) con el laboratorio (CUNLAB) y, a través de PR04NUMACTPLAN, con facturación (FA) y documentación (IM).

7.5 · Arquitectura Bicentro y Flujo de Muestras

Distribución de equipos y flujo de información entre los centros de Pamplona y Madrid, con los puntos de coordinación en la base de datos compartida.

flowchart LR subgraph PAM ["🏥 CUN PAMPLONA (AD74CODCENTRO = 1)"] direction TB PAM_HIS["HIS / PR0400\nPlan Clínico Pamplona"] PAM_PRE["Preanalítica\nSección 68\nExtracción muestras"] subgraph PAM_LAB ["Laboratorio Pamplona"] PAM_BQ["Bioquímica\nBA200 (210) · COBAS U411 (205)\nPOCone (212) · Optilite (182)"] PAM_HEM["Hematología\neFlow EPU: XN9100L/R (193/194)\nSP10 (195) · EPU 6881 (192)"] PAM_MIC["Microbiología\nQIAcube DNA (108)"] PAM_INM["Inmunología\nEUROBlot (183)"] end PAM_CC["CC Interno\nLB1000–LB1200\nSEQC Proteínas"] PAM_INF["IM0100\nInformes\n→ Médico Pamplona"] end subgraph MAD ["🏥 CUN MADRID (AD74CODCENTRO = 2)"] direction TB MAD_HIS["HIS / PR0400\nPlan Clínico Madrid"] MAD_PRE["Preanalítica\nRecepción muestras"] subgraph MAD_LAB ["Laboratorio Madrid"] MAD_BQ["Bioquímica\neFlow C6000-2\ne601×2 · ISE · c501\n(167-171) · POCone (213)"] MAD_MIC["Microbiología / Bacteriología\nBACKT ALERT (106)\nMyla/BD (133)\nCFX96-PCR (204)"] MAD_SER["Micro Core / Serología\nSerología 8000 (609)\nExternas IVAMI/cerba/CNM"] end MAD_CC["CC Interno\nLB1000–LB1200\nPor centro/equipo"] MAD_INF["IM0100\nInformes\n→ Médico Madrid"] end subgraph DB ["🗄️ Oracle DB Compartida"] PRUE["CUNLAB\nPRUEBAASISTENCIA"] MUEST["CUNLAB\nMUESTRAASISTENCIA"] CI["CI\nHistoria Única\nPaciente"] SG["SG\nUsuarios / Roles"] end PAM_HIS --> PRUE MAD_HIS --> PRUE PAM_PRE --> MUEST MAD_PRE --> MUEST PRUE <--> PAM_LAB PRUE <--> MAD_LAB MUEST --> PAM_LAB MUEST --> MAD_LAB PAM_LAB --> PAM_CC MAD_LAB --> MAD_CC PRUE --> PAM_INF PRUE --> MAD_INF CI --- PRUE SG --- PRUE MUEST -.->|"Envío físico\nmuestras"| MAD_LAB style PAM fill:#EBF3FB,stroke:#2E75B6 style MAD fill:#fff5f0,stroke:#e67e22 style DB fill:#f0fff4,stroke:#27ae60

7.5 · Ciclo de Control de Calidad

flowchart LR A["📦 Material\nde Control\nLB1003"] --> B["Programa CC\nLB1000\nAnalito + Dpto"] B --> C["Resultado CC\nLB1100\nINSERT"] C -->|"trigger"| D{"Evaluación\nWestgard\nLB1300"} D -->|"OK ✓"| E["Estadísticas\nLB1200\nActualizar μ, σ, CV"] D -->|"Alarma ✗"| F["LB1203\nAlarma CC\nPendiente"] F --> G["Técnico\nRevisa equipo"] G -->|"Libera"| H["PRUEBAASISTENCIA\nDesbloquear"] G -->|"Fallo reactivo"| I["LB7300\nCaducidad reactivo\nOFF"] E --> J["LB1202\nAcumulado\nPeriódico"] J --> K["LB2601\nIndicadores\nCalidad"] style D fill:#fff9c4,stroke:#ffeb3b style F fill:#f8d7da,stroke:#dc3545 style E fill:#d4edda,stroke:#28a745 style H fill:#d4edda,stroke:#28a745

AApéndice – Catálogo de Tablas CUNLAB

Las 214 tablas del esquema CUNLAB organizadas por dominio funcional. Usa el campo de búsqueda para filtrar.

CódigoDescripción / DenominaciónCols