Propuesta técnica del modelo de datos LIS para PostgreSQL 18+

Estado: propuesta de diseño

Motor objetivo: PostgreSQL 18 o posterior

Convención: nombres técnicos en español, minúsculas y snake_case

Alcance: modelo relacional para laboratorio clínico multisede, con trazabilidad clínica, calidad, inventario, facturación, microbiología, informes y auditoría.

Este documento evoluciona —no replica literalmente— LIS_datos_modelo_postgresql.sql. Conserva su cobertura y la de LIS_datos_ejemplo.sql, corrige riesgos de integridad/concurrencia y agrega componentes necesarios para una trazabilidad completa. No contiene una migración ejecutable ni sustituye la validación clínica, regulatoria o de seguridad.

Contenido

1. Objetivos y criterios
2. Decisiones PostgreSQL 18+
3. Arquitectura de datos
4. Modelo clínico central
5. Catálogo y configuración clínica
6. Muestras y ejecución analítica
7. Resultados, validación e informes
8. Equipos y calidad
9. Reactivos e inventario
10. Microbiología
11. Facturación y cobertura
12. Usuarios, seguridad y auditoría
13. Estados y reglas de integridad
14. Índices, vistas y funciones
15. Interoperabilidad
16. Operación, crecimiento y recuperación
17. Diferencias frente al SQL fuente
18. Matriz de migración
19. Pruebas de aceptación del modelo

1. Objetivos y criterios

El modelo debe permitir:

• reconstruir el recorrido completo desde paciente y orden hasta la versión exacta de un informe;
• operar varias sedes y distinguir registro, toma, procesamiento y entrega;
• configurar pruebas, perfiles, analitos, métodos, referencias y tarifas con vigencia;
• compartir o dividir muestras sin perder identidad ni cadena de custodia;
• conservar resultados originales, repeticiones, correcciones y validaciones;
• impedir la publicación cuando faltan controles o aprobaciones obligatorias;
• documentar valores críticos y su comunicación confirmada;
• relacionar resultados con equipos, ejecuciones y lotes realmente usados;
• soportar microbiología, facturación, pagos, cuentas por cobrar, alertas y auditoría;
• configurar como datos —no como código— las pruebas reflejas, el delta check y la autovalidación, con evidencia de cada aplicación;
• registrar los datos clínicos que intervienen en un cálculo o en la selección de una referencia;
• seguir una muestra derivada a un laboratorio de referencia sin perder la custodia;
• interoperar mediante mapeos explícitos sin acoplar el modelo físico a una sola versión de un estándar.

1.1 Alcance funcional

El núcleo cubre hematología, química, uroanálisis, microbiología, parasitología, inmunología/serología, hormonas y coagulación. Banco de sangre y patología/citología pueden usar las entidades comunes de orden, muestra, resultado e informe, pero requieren submodelos especializados antes de producción (donantes/componentes/compatibilidad y casos/bloques/láminas/diagnósticos, respectivamente).

1.2 Criterios de normalización

Se busca tercera forma normal para maestros y hechos, con duplicación intencional solo para instantáneas históricas: precio vendido, nombre/método reportado, unidad, intervalo de referencia mostrado y representación del informe. Una instantánea no es un dato maestro alternativo; es evidencia de lo vigente en el momento del hecho.

2. Decisiones PostgreSQL 18+

La fecha extraíble de un UUIDv7 no reemplaza creado_en: el instante clínico debe ser siempre una columna explícita.

2.1 Convenciones de columnas

• PK: id.
• FK: <entidad>_id.
• Identificador legible: codigo, numero_orden, numero_factura, numero_informe.
• Tiempos: verbos en participio o evento, por ejemplo recolectada_en, recibida_en, validada_en.
• Auditoría técnica mínima en maestros: creado_en, creado_por_id, actualizado_en, actualizado_por_id.
• Activación de maestros: activo; hechos usan estados, anulaciones o versiones, no borrado suave genérico.
• Todas las constraints e índices reciben nombres explícitos y estables.

2.2 Estrategia de claves primarias

No todas las tablas necesitan el mismo tipo de clave. Un uuid ocupa 16 bytes y se repite en cada fila hija y en cada índice que lo referencie; en un catálogo de decenas de filas ese coste no compra nada.

Dos consecuencias prácticas: una clave foránea hereda siempre el tipo de la clave a la que apunta, así que el tipo se decide una sola vez por tabla referenciada; y el identificador legible de negocio (codigo, numero_orden, numero_factura, numero_informe) es independiente de la clave técnica y mantiene su propia restricción de unicidad en cualquiera de los tres casos.

2.3 Características de PostgreSQL 18 aprovechadas

3. Arquitectura de datos

flowchart TD
    Personas[Personas y cobertura] --> Ordenes[Órdenes y atención]
    Catalogo[Catálogo clínico] --> Ordenes
    Ordenes --> Muestras[Muestras y alícuotas]
    Muestras --> Analitica[Ejecución analítica]
    Catalogo --> Analitica
    Calidad[Equipos y calidad] --> Analitica
    Inventario[Reactivos e inventario] --> Analitica
    Analitica --> Resultados[Resultados y validación]
    Catalogo --> Reglas[Reglas clínicas]
    Reglas --> Resultados
    Reglas --> Ordenes
    Resultados --> Informes[Informes y entrega]
    Ordenes --> Finanzas[Facturación y cartera]
    Resultados --> Alertas[Alertas y notificaciones]
    Personas --> Auditoria[Seguridad y auditoría]
    Informes --> Auditoria
    Finanzas --> Auditoria

    classDef maestro fill:#D0EBFF,stroke:#1971C2,stroke-width:2px,color:#0B2E4F
    classDef clinico fill:#D3F9D8,stroke:#2B8A3E,stroke-width:2px,color:#1B4332
    classDef soporte fill:#FFF3BF,stroke:#E67700,stroke-width:2px,color:#5F3C00
    classDef gobierno fill:#E5DBFF,stroke:#6741D9,stroke-width:2px,color:#2F1B69
    class Personas,Catalogo maestro
    class Ordenes,Muestras,Analitica,Resultados,Informes clinico
    class Calidad,Inventario,Finanzas,Alertas,Reglas soporte
    class Auditoria gobierno

3.1 Dominios

4. Modelo clínico central

erDiagram
    PACIENTE ||--o{ ORDEN_LABORATORIO : tiene
    MEDICO_SOLICITANTE ||--o{ ORDEN_LABORATORIO : solicita
    SEDE ||--o{ ORDEN_LABORATORIO : registra
    ORDEN_LABORATORIO ||--|{ PRUEBA_SOLICITADA : contiene
    PRUEBA ||--o{ PRUEBA_SOLICITADA : instancia
    ORDEN_LABORATORIO ||--o{ MUESTRA : origina
    MUESTRA ||--o{ ALICUOTA : divide
    PRUEBA_SOLICITADA }o--o{ ALICUOTA : utiliza
    PRUEBA_SOLICITADA ||--o{ EJECUCION_ANALITICA : procesa
    EJECUCION_ANALITICA ||--o{ RESULTADO_VERSION : produce
    PRUEBA_SOLICITADA ||--o{ RESULTADO : contiene
    RESULTADO ||--|{ RESULTADO_VERSION : versiona
    RESULTADO_VERSION ||--o{ VALIDACION_RESULTADO : valida
    ORDEN_LABORATORIO ||--o{ INFORME_RESULTADOS : emite

4.1 Personas y cobertura

sexo_biologico y identidad_genero son conceptos separados. La selección de referencias clínicas usa los criterios validados por el laboratorio y conserva cuál se aplicó; no debe inferirse de un campo ambiguo llamado genero.

4.2 Orden y prueba solicitada

Los totales en la orden son una proyección conciliada con las pruebas solicitadas. Los importes finales vendidos se conservan aunque la tarifa del catálogo cambie.

La orden y la prueba solicitada tienen ciclos distintos: la orden agrega, la prueba avanza. El estado de la orden se deriva del conjunto de sus pruebas, nunca al revés.

stateDiagram-v2
    [*] --> Pendiente
    Pendiente --> En_proceso: muestra aceptada y distribuida
    Pendiente --> Derivada: prueba no realizada internamente
    Pendiente --> Cancelada: cancelación o rechazo sin nueva toma
    Derivada --> En_proceso: resultado recibido del laboratorio de referencia
    En_proceso --> En_espera: repetición, dilución o incubación en curso
    En_espera --> En_proceso: nueva ejecución
    En_proceso --> Validada_tecnicamente: revisión técnica conforme
    Validada_tecnicamente --> En_espera: devuelta para repetir o aclarar
    Validada_tecnicamente --> Validada_profesionalmente: aprobación clínica
    Validada_profesionalmente --> Publicada: incluida en un informe emitido
    Publicada --> Publicada: corrección, nueva versión de resultado
    Publicada --> [*]
    Cancelada --> [*]

    classDef inicial fill:#E6E6FA,stroke:#5F3DC4,stroke-width:2px,color:#2F1B69
    classDef curso fill:#D0EBFF,stroke:#1971C2,stroke-width:2px,color:#0B2E4F
    classDef cierre fill:#D3F9D8,stroke:#2B8A3E,stroke-width:2px,color:#1B4332
    classDef excepcion fill:#FFE3E3,stroke:#C92A2A,stroke-width:2px,color:#5C0000
    class Pendiente inicial
    class En_proceso,En_espera,Derivada curso
    class Validada_tecnicamente,Validada_profesionalmente,Publicada cierre
    class Cancelada excepcion

5. Catálogo y configuración clínica

erDiagram
    SECCION_LABORATORIO ||--o{ PRUEBA : agrupa
    TIPO_MUESTRA ||--o{ REQUISITO_MUESTRA : clasifica
    TIPO_RECIPIENTE ||--o{ REQUISITO_MUESTRA : contiene
    PRUEBA ||--|{ REQUISITO_MUESTRA : requiere
    PERFIL ||--|{ PERFIL_PRUEBA : compone
    PRUEBA ||--o{ PERFIL_PRUEBA : integra
    PRUEBA ||--|{ ANALITO : reporta
    ANALITO ||--o{ OPCION_ANALITO : ofrece
    ANALITO ||--o{ INTERVALO_REFERENCIA : interpreta
    PRUEBA ||--o{ TARIFA_PRUEBA : tarifa
    ASEGURADORA ||--o{ TARIFA_PRUEBA : acuerda
    UNIDAD_MEDIDA ||--o{ ANALITO : expresa
    PRUEBA ||--o{ CODIGO_EXTERNO : mapea
    ANALITO ||--o{ CODIGO_EXTERNO : mapea
    PRUEBA ||--o{ REGLA_REFLEJA : desencadena
    ANALITO ||--o{ REGLA_DELTA : vigila
    PRUEBA ||--o{ REGLA_AUTOVALIDACION : libera

5.1 Reglas clínicas configurables

Tres comportamientos que el marco conceptual exige no son código: son configuración versionada, con vigencia y aprobación, y dejan evidencia cada vez que se aplican.

6. Muestras y ejecución analítica

Estado de muestra

stateDiagram-v2
    [*] --> Pendiente
    Pendiente --> Recolectada: toma y etiquetado
    Recolectada --> Recibida: recepción técnica
    Recibida --> Rechazada: no conformidad
    Recibida --> En_proceso: distribución
    En_proceso --> Procesada: ejecuciones finalizadas
    Procesada --> Almacenada: conservación
    Almacenada --> Descartada: fin de retención
    Rechazada --> Descartada
    Descartada --> [*]

El estado fuente no incluía almacenamiento y descarte; se agregan para completar la cadena de custodia. La nueva toma se representa como una nueva muestra relacionada, no reutilizando el código rechazado.

7. Resultados, validación e informes

7.1 Cálculo de criticidad

1. Seleccionar el intervalo vigente para analito, método, unidad y criterios del paciente en la fecha clínicamente relevante.
2. Si no existe o existen varios igualmente aplicables, marcar referencia no resuelta y enviar a revisión; nunca asumir normal.
3. Comparar límites críticos antes que límites de referencia.
4. Guardar intervalo_referencia_id, representación mostrada, bandera y criticidad en la versión.
5. Disparar alerta/notificación según política sin liberar automáticamente.

7.2 Corrección

Una corrección agrega resultado_version, nuevas validaciones y un informe que referencia/reemplaza al anterior. resultado_version e informe_resultado_detalle permiten reproducir cualquier informe histórico aunque cambien paciente, catálogo o referencia.

stateDiagram-v2
    [*] --> Capturada: ejecución analítica o interfaz
    Capturada --> Referencia_no_resuelta: sin intervalo aplicable único
    Referencia_no_resuelta --> Capturada: configuración corregida
    Capturada --> Revisada: coherencia, delta y criticidad evaluadas
    Revisada --> Reemplazada: repetición produce versión posterior
    Revisada --> Liberada: validaciones exigidas completas
    Liberada --> Publicada: incluida en un informe emitido
    Publicada --> Reemplazada: corrección publicada en versión posterior
    Reemplazada --> [*]
    Publicada --> [*]

    classDef curso fill:#D0EBFF,stroke:#1971C2,stroke-width:2px,color:#0B2E4F
    classDef cierre fill:#D3F9D8,stroke:#2B8A3E,stroke-width:2px,color:#1B4332
    classDef excepcion fill:#FFE3E3,stroke:#C92A2A,stroke-width:2px,color:#5C0000
    class Capturada,Revisada curso
    class Liberada,Publicada cierre
    class Referencia_no_resuelta,Reemplazada excepcion

Ninguna transición modifica una versión existente: Reemplazada significa que existe una versión posterior vigente, no que la anterior se haya alterado. Por eso el puntero de versión vigente vive en la cabecera resultado y las filas de resultado_version son inmutables una vez escritas.

8. Equipos y calidad

9. Reactivos e inventario

erDiagram
    SECCION_LABORATORIO ||--o{ REACTIVO : usa
    REACTIVO ||--o{ LOTE_REACTIVO : recibe
    PRUEBA ||--o{ PRUEBA_REACTIVO : requiere
    REACTIVO ||--o{ PRUEBA_REACTIVO : participa
    LOTE_REACTIVO ||--o{ MOVIMIENTO_INVENTARIO : mueve
    EJECUCION_ANALITICA ||--o{ CONSUMO_REACTIVO : consume
    LOTE_REACTIVO ||--o{ CONSUMO_REACTIVO : traza

El saldo actual puede materializarse para consulta, pero debe reconciliarse con la suma de movimientos. El stock a nivel de reactivo es una agregación de lotes utilizables, no una segunda fuente manual.

10. Microbiología

Este desglose mejora las tablas fuente cultivos y antibiogramas, que guardan un solo germen y mezclan cabecera con una fila de antimicrobiano.

11. Facturación y cobertura

paciente_id y aseguradora_id pueden conservarse en factura como instantáneas relacionales verificadas, aunque sean derivables de la orden, porque el documento financiero tiene identidad histórica propia.

12. Usuarios, seguridad y auditoría

12.1 Controles

• Revocar privilegios por defecto a PUBLIC en el esquema aplicativo.
• Separar roles PostgreSQL de migración, aplicación, solo lectura operacional y auditoría.
• La aplicación nunca se conecta como propietario ni superusuario.
• Conceder permisos mínimos por tablas/vistas o funciones; no GRANT ALL general.
• Considerar RLS solo si existe aislamiento real por organización y todas las rutas de acceso se prueban. Las sedes de una misma organización no son automáticamente tenants.
• Proteger copias de seguridad y exportaciones con los mismos controles que la base activa.
• Auditar accesos/entregas de información clínica según política, además de cambios.
• Cifrar transporte con TLS y mantener llaves, certificados y secretos fuera de tablas de negocio.

12.2 Dónde vive la auditoría

Conviene separar dos cosas que el SQL fuente mezclaba bajo la palabra «auditoría».

Trazabilidad que es parte del registro clínico o financiero. resultado_version, validacion_resultado, evento_muestra, notificacion_critica, historial_estado_orden, movimiento_inventario, entrega_informe. Se consultan desde la aplicación, se imprimen en informes, participan en reglas de integridad y deben ser transaccionalmente coherentes con el hecho que describen. Permanecen en PostgreSQL, con claves foráneas reales.

Bitácora técnica que no es dato de negocio. evento_auditoria (el antiguo audit_log) y mensaje_interfaz. Son un flujo append-only, de alto volumen, esquema laxo (jsonb de antes/después, contenido crudo de protocolo) y consulta poco frecuente y casi siempre por rango de fechas. Ese perfil no es el de una base relacional.

Nota de arquitectura. Se recomienda trasladar la bitácora técnica a un motor distinto, orientado a documentos JSON o a registros de eventos —OpenSearch/Elasticsearch, ClickHouse, Loki o un almacén de objetos con archivo por fecha—, dejando en PostgreSQL únicamente la trazabilidad que participa del negocio. Razones: el volumen de auditoría suele superar en un orden de magnitud al de los datos clínicos y distorsiona respaldos, autovacuum y tiempos de restauración; su retención legal es distinta y normalmente más larga que la operativa; y su patrón de consulta —búsqueda por texto y agregación temporal— se sirve mucho mejor fuera de un motor relacional. Si por simplicidad inicial se mantiene en PostgreSQL, debe ir en tablas particionadas por fecha, con política de archivado y purga explícita desde el primer día, no como una tabla que crece indefinidamente. Lo que no puede trasladarse fuera es la evidencia que un informe o una regla de integridad necesitan leer: esa es registro clínico, no bitácora.

13. Estados y reglas de integridad

13.1 Catálogos iniciales

13.2 Restricciones importantes

• fecha_nacimiento <= current_date; las reglas dependientes de la fecha actual se validan en servicio/trigger, no en un CHECK inmutable incorrecto.

• edad_min_dias <= edad_max_dias, valor_min <= valor_max y críticos coherentes cuando existan.

• Vigencia: vigente_hasta IS NULL OR vigente_hasta >= vigente_desde. Con dos columnas un periodo invertido sí es representable, así que este CHECK no es opcional: sin él, el constructor de rango de la restricción de no solapamiento fallaría en tiempo de ejecución en vez de rechazarse limpiamente al insertar.

• Importes, volúmenes, cantidades y tiempos no negativos; descuento dentro de la base.

• Un valor de resultado cumple una exclusión lógica entre numérico, texto y opción. Fórmulas almacenan el valor evaluado además de su procedencia.

• Un intervalo de referencia no puede solaparse con otro de igual analito, método, unidad y criterios. La vigencia se modela con el par clásico vigente_desde/vigente_hasta, y el no solapamiento se impone en la base con una restricción EXCLUDE sobre la expresión de rango. No hace falta convertir las columnas a daterange:

  create extension if not exists btree_gist;
  
  create table lis.intervalo_referencia (
      id            uuid primary key default uuidv7(),
      analito_id    uuid    not null references lis.analito (id),
      metodo_id     integer references lis.metodo (id),
      unidad_id     integer not null references lis.unidad_medida (id),
      sexo_id       integer references lis.sexo_biologico (id),   -- nulo = aplica a todos
      edad_min_dias integer not null default 0,
      edad_max_dias integer not null default 36500,
      valor_min     numeric,
      valor_max     numeric,
      vigente_desde date    not null,
      vigente_hasta date,                                          -- nulo = sin fin previsto
  
      constraint intervalo_referencia_vigencia_coherente
          check (vigente_hasta is null or vigente_hasta >= vigente_desde),
      constraint intervalo_referencia_edad_coherente
          check (edad_min_dias <= edad_max_dias),
  
      constraint intervalo_referencia_sin_solape
          exclude using gist (
              analito_id              with =,
              coalesce(metodo_id, -1) with =,
              unidad_id               with =,
              coalesce(sexo_id, -1)   with =,
              int4range(edad_min_dias, edad_max_dias, '[]')        with &&,
              daterange(vigente_desde, vigente_hasta, '[]')        with &&
          )
  );

  El mismo patrón aplica a tarifa_prueba, equipo_prueba, cobertura_paciente, prueba_reactivo y cuenta_rol. Dos detalles no son opcionales, y ambos se comprobaron contra PostgreSQL 18.4:

  1. coalesce(...) en todo criterio opcional. Una restricción EXCLUDE ignora las filas en las que el operador devuelve nulo. Con sexo_id with = a secas, dos filas con sexo_id nulo y vigencias solapadas se insertan sin error, porque null = null no es verdadero. Sustituir el nulo por un centinela cierra el hueco. La alternativa, más limpia si se puede, es hacer la columna not null y tener una fila «no aplica» en el catálogo.
  2. El tercer argumento '[]'. Por defecto daterange(a, b) es semiabierto y excluye b, de modo que una vigencia que termina el 30 de junio y otra que empieza el 30 de junio no se detectan como solapadas, aunque para el negocio ese día está cubierto dos veces. Como vigente_hasta se lee de forma inclusiva, el rango debe construirse inclusivo. Lo mismo vale para el rango de edades.

  Un vigente_hasta nulo produce un rango sin límite superior y se compara correctamente: dos vigencias abiertas sobre los mismos criterios se rechazan entre sí.

• Una FK por sí sola no valida relaciones transitivas (por ejemplo, paciente de muestra = paciente de orden); usar claves compuestas adicionales o trigger de restricción transaccional.

• Los estados solo cambian por transiciones autorizadas y se registra el historial.

• Publicar requiere versión validada, referencia resuelta o excepción documentada, y control de calidad apto cuando aplique.

• No usar ON DELETE CASCADE desde orden a resultados liberados. La cancelación conserva hechos.

14. Índices, vistas y funciones

14.1 Índices iniciales orientados a consultas

PostgreSQL no crea automáticamente índices en columnas FK del lado referenciante. Deben indexarse las FK usadas en uniones/borrado y diseñarse índices compuestos según las consultas.

No crear un índice adicional sobre una columna ya cubierta por PK o UNIQUE. Validar índices con consultas y EXPLAIN (ANALYZE, BUFFERS) en datos representativos.

El recorrido por saltos de PostgreSQL 18 permite que un índice compuesto atienda consultas que no restringen sus primeras columnas, siempre que esas primeras columnas tengan pocos valores distintos. Antes de añadir un índice que solo reordena las columnas de otro existente, conviene medir si el que ya está cubre el caso. Esto es especialmente aplicable a la lista de trabajo, donde sección, estado y prioridad tienen cardinalidad baja.

14.2 Vistas

El SQL fuente llama “vistas materializadas” a objetos creados con CREATE VIEW; la propuesta los clasifica correctamente. Solo materializar una vista si las mediciones justifican costo, latencia y política de refresco.

14.3 Funciones y triggers

• generar_numero_orden/factura/informe: usar secuencia o contador por organización/año bloqueado transaccionalmente. No usar MAX + 1, que produce colisiones bajo concurrencia.
• seleccionar_intervalo_referencia: determinista respecto a una fecha y criterios; si no hay una coincidencia única, devuelve condición de revisión.
• evaluar_criticidad: opera sobre el intervalo ya seleccionado y no clasifica “normal” cuando falta referencia.
• calcular_edad: calcula años, meses o días con respecto a la fecha clínica del informe; el texto de edad se genera para presentación y no se guarda como dato maestro ni se recalcula siempre contra current_date.
• registrar_transicion_estado: valida transición, actualiza la proyección e inserta historial en una transacción. Con RETURNING old.estado, new.estado de PostgreSQL 18 obtiene ambos valores de la propia sentencia de actualización, sin releer la fila ni arriesgar una lectura desfasada.
• actualizar_fecha_modificacion: permitido en maestros; no sustituye auditoría.
• Triggers de auditoría cubren las tablas definidas por política y reciben identidad/correlación desde la sesión de aplicación.
• Funciones SECURITY DEFINER, si existen, fijan search_path, validan permisos y tienen superficie mínima.

15. Interoperabilidad

Ese mapeo es la entidad codigo_externo de §5: sistema, codigo, version, display y vigencia, nunca una columna suelta loinc_code sin contexto. Las unidades se expresan con el catálogo unidad_medida referenciando UCUM, de modo que un Observation pueda emitirse con unidad codificada y no con una cadena escrita a mano. Las interfaces ASTM/HL7 v2 de equipos se adaptan a un modelo canónico y conservan correlación/mensaje original para soporte.

16. Operación, crecimiento y recuperación

• Usar un pool de conexiones; evitar una conexión por usuario final y sesiones inactivas prolongadas.
• Activar pg_stat_statements y monitorear latencia, bloqueos, conexiones, autovacuum, crecimiento y consultas de lista de trabajo/informe.
• Mantener transacciones cortas; operaciones humanas largas usan estados, no transacciones abiertas.
• Establecer respaldos completos y archivado continuo de WAL si el RPO exige recuperación a un punto en el tiempo.
• Probar restauraciones periódicamente; un respaldo no probado no demuestra recuperabilidad.
• Definir RPO, RTO, retención y archivo con el propietario del negocio antes de fijar frecuencias.
• Considerar partición temporal para evento_auditoria, evento_muestra, mensaje_interfaz, resultado_version o movimientos solo cuando volumen y mantenimiento lo justifiquen. PostgreSQL 18 no convierte la partición en un requisito por sí sola.
• Mantener migraciones versionadas, transaccionales cuando sea posible, con expansión/contracción para cambios incompatibles e índices concurrentes en producción cuando corresponda. Para añadir NOT NULL a una tabla grande sin bloquearla mientras se valida, usar NOT NULL NOT VALID y validar después; para reglas que aún no se pueden imponer sobre datos históricos, declararlas NOT ENFORCED y activarlas al sanear. PostgreSQL no admite ADD CONSTRAINT IF NOT EXISTS: la idempotencia se consigue comprobando pg_constraint en un bloque DO.

17. Diferencias frente al SQL fuente

18. Matriz de migración

Las 33 tablas del esquema original quedan cubiertas así:

18.1 Uso de los datos de ejemplo

El archivo de ejemplo sirve como escenario de migración y aceptación: configuración base de tres sedes y ocho roles; aseguradoras y médicos; secciones, pruebas, perfiles, analitos, referencias y tarifas; equipos, reactivos y controles; cinco pacientes con órdenes particulares/aseguradas y normal/urgente; facturación y pagos; toma/recepción; resultados normales y críticos; validaciones; alertas; informes; consumo de inventario; urocultivo y antibiograma posterior.

Antes de cargarlo se deben reemplazar contraseñas y datos personales ficticios por fixtures seguros, adaptar UUID a valores válidos para el motor, y ajustar los inserts a las nuevas entidades/versiones. Nunca usar esas credenciales de ejemplo en un entorno real.

18.2 Entidades sin equivalente en la fuente

Estas entidades no migran desde ninguna tabla del SQL original: cubren conceptos que las cuatro fuentes no modelaban. Se listan aparte para que la matriz anterior siga siendo una correspondencia uno a uno verificable.

19. Pruebas de aceptación del modelo

19.1 Integridad

1. Rechazar un paciente duplicado con el mismo identificador en la misma organización y permitir otro emisor/sistema válido.
2. Impedir asociar una muestra o alícuota de otro paciente a una prueba solicitada.
3. Expandir un perfil sin duplicar pruebas ya incluidas según la política elegida.
4. Impedir rangos o tarifas con vigencias incompatibles para la misma clave.
5. Impedir un resultado con valor numérico y textual principal simultáneos.
6. Impedir consumo negativo, sobreconsumo no autorizado o uso de lote vencido/bloqueado.
7. Impedir borrado físico de una orden con resultados o informes.
8. Impedir dos intervalos de referencia o dos tarifas con vigencias solapadas para los mismos criterios, comprobando que la rechaza la restricción EXCLUDE del motor y no una validación de la aplicación. Incluir el caso de dos filas con el mismo criterio opcional nulo y el de dos vigencias que comparten día frontera.
9. Impedir procesar o divulgar una prueba cuyo consentimiento obligatorio no esté vigente.
10. Impedir que un analito dependiente del volumen total se calcule cuando la muestra temporizada no tiene periodo ni volumen.

19.2 Flujo clínico

1. Ejecutar la jornada del archivo de ejemplo desde CC hasta entrega.
2. Rechazar una muestra y crear una nueva toma sin perder trazabilidad.
3. Compartir una alícuota entre varias pruebas y usar varias alícuotas en una prueba.
4. Recibir un resultado por interfaz, repetirlo y liberar la versión seleccionada.
5. Detectar un crítico, documentar comunicación y escalamiento.
6. Corregir un resultado ya informado y reproducir tanto el informe original como el corregido.
7. Mantener una orden parcial mientras un cultivo continúa 48–72 horas.
8. Registrar dos microorganismos y antibiogramas independientes en un cultivo polimicrobiano.
9. Disparar una prueba refleja desde un resultado positivo y comprobar que crea una prueba solicitada nueva, con su tarifa, su cobertura y su propia trazabilidad.
10. Autovalidar un resultado que cumple la regla vigente, comprobar que queda registrada la regla que lo liberó, y comprobar que un resultado crítico de la misma prueba no se autovalida.
11. Derivar una prueba a un laboratorio de referencia, recibir el resultado y reproducir el informe identificando qué laboratorio lo produjo y quién lo firmó.
12. Agregar una prueba a una orden ya registrada reutilizando una muestra vigente, y comprobar que se rechaza cuando el criterio de estabilidad ha expirado.

19.3 Concurrencia, seguridad y operación

1. Generar simultáneamente números de orden sin duplicados.
2. Verificar que roles no autorizados no lean ni modifiquen resultados, pagos o auditoría.
3. Confirmar que cada FK crítica tiene índice útil y que la lista de trabajo usa el índice previsto.
4. Verificar que los eventos auditables generan actor, fecha, correlación y antes/después.
5. Restaurar una copia en un entorno aislado y reconciliar conteos e informes con hashes.
6. Comprobar que la bitácora técnica puede archivarse, purgarse o trasladarse a su motor definitivo sin afectar la reproducción de informes históricos ni ninguna regla de integridad (§12.2).

Referencias técnicas

• PostgreSQL 18 — UUID Functions
• PostgreSQL 18 — Date/Time Types
• PostgreSQL 18 — Constraints
• PostgreSQL 18 — Row Security Policies
• HL7 FHIR — Diagnostics Module
• LOINC
• SNOMED CT
• ISO 15189:2022