Grupo-Consiti/clinical_laboratory
4
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

Se adiciona to be desing

Browse Source
This commit is contained in:
Luis Ernesto Portillo Zaldivar 2025-07-12 15:23:44 -06:00
parent fc558bcd0f
commit 8c6799b9df
1 changed files with 175 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

175
documents/requirements/ToBeDesing.md Normal file
View File

@ -0,0 +1,175 @@
# Diseño Técnico del Módulo LIMS para Odoo 18
El **Laboratory Information Management System (LIMS)** para **Odoo 18** gestionará de forma integral el flujo de trabajo de un laboratorio clínico, desde la recepción de pacientes y muestras hasta la emisión de resultados en PDF. Se priorizará la reutilización de componentes estándar de Odoo (Contactos, Ventas, Inventario, etc.) siempre que sea posible, extendiendo su funcionalidad con nuevos modelos prefijados como **`lims.`** para agrupar las entidades propias del módulo. A continuación se detallan los **componentes core** del LIMS, las **integraciones obligatorias** con otros módulos Odoo, y las **extensiones opcionales** que enriquecen la solución, indicando explícitamente cuáles forman parte del núcleo y cuáles son adicionales. Se incluyen además un **diagrama ERD** del modelo de datos propuesto y un **diagrama de flujo** del proceso, para orientar el desarrollo técnico con precisión.
## Componentes Core del Módulo LIMS (Esenciales)
Los componentes core conforman la funcionalidad mínima requerida del LIMS. Incluyen la gestión de pacientes y órdenes de laboratorio, el manejo de muestras, el registro y validación de resultados clínicos, y la generación de informes finales. Cada componente core se detalla a continuación:
### Recepción de Pacientes y Registro de Órdenes de Laboratorio (Core)
**Descripción:** Cuando un paciente llega al laboratorio (o se recibe una orden externa), el **recepcionista** registra una nueva **orden de laboratorio** asociada al paciente y a uno o varios análisis clínicos solicitados. Si el paciente ya existe en la base de datos, se selecciona su ficha de **Contacto**; si no, se crea un nuevo `res.partner` marcado como paciente. En la orden se eligen los análisis requeridos de un **catálogo de pruebas** predefinido (por ejemplo: _Hemograma_, _Perfil lipídico_, _Glucosa_, etc.), cada uno con su precio y configuración técnica cargada en el sistema. Al confirmar la orden, el sistema asigna un identificador único y genera automáticamente las **etiquetas** para las muestras necesarias, cada una con un código de barras o QR que incluye el código de orden, datos del paciente y tipo de muestra. Estas etiquetas se imprimen en la impresora de etiquetas del laboratorio para adherirlas a los tubos/recipientes correspondientes. La orden queda registrada en estado inicial (por ejemplo, _Pendiente de toma de muestra_) y visible para los técnicos de laboratorio.
**Detalles técnicos y reutilización:** El paciente se gestiona reutilizando el modelo `res.partner` con campos adicionales (como número de historia clínica) y banderas para distinguir tipos de contacto (e.g. `is_patient`, `is_doctor`). La orden de laboratorio se implementará aprovechando el modelo de **Ventas**: es decir, una **cotización/orden de venta (`sale.order`)** donde cada análisis solicitado corresponde a una línea de producto de tipo Servicio. Esta decisión se toma porque la integración con facturación es obligatoria, por lo que conviene usar el flujo estándar de _Presupuesto -> Orden de Venta -> Factura_ de Odoo en lugar de inventar un modelo aislado. Alternativamente se consideró un modelo personalizado `lims.request` (Lab Request), pero se optará por `sale.order` para reducir desarrollo redundante. Al confirmar la orden, se puede desencadenar vía código la creación de las etiquetas de muestra (ejecutando reportes QWeb de etiquetas) y notificar al laboratorio (por ejemplo, mediante el _chatter_ de Odoo o una actividad programada). La orden de venta generada estará ligada al paciente (campo `partner_id`) y permitirá luego la facturación integrada (ver _Integraciones_ más abajo).
### Gestión de Muestras y Toma de Muestras (Core)
**Descripción:** Este componente abarca el **ciclo de vida de las muestras clínicas** desde su recolección hasta su disposición final, garantizando trazabilidad completa. Tras registrar una orden, el **técnico de laboratorio** prepara el material necesario según los análisis solicitados y procede a la **toma de muestra** del paciente (por ejemplo, extracción de sangre, recolección de orina, hisopo, etc.). Cada vez que se toma una muestra, el técnico **escanea el código de barras/QR** de la etiqueta adherida al tubo, de modo que el sistema identifica la muestra y la marca inmediatamente como _Recogida_. El sistema registra la fecha/hora de recolección, así como el usuario que realizó la toma, para fines de auditoría. Si una orden requiere múltiples muestras (p. ej. distintos tubos para diferentes pruebas), el técnico repetirá el proceso para cada código de muestra; el sistema soportará **múltiples muestras vinculadas a una misma orden** cuando aplique.
Cada muestra pasará por varios **estados predefinidos** a medida que avanza en el flujo: _Pendiente_, _Recogida_, _En análisis_, _Resultado listo_, _Validado_, _Desechada_, etc.. Estos estados reflejan dónde se encuentra la muestra en el proceso (esperando toma, en proceso de análisis, con resultado pendiente de validación, finalizada, o eliminada). Los usuarios de laboratorio podrán actualizar manualmente el estado según corresponda (por ejemplo, marcar _En análisis_ al iniciar el procesamiento en equipo, _Resultado listo_ al obtener un valor, _Validado_ tras la revisión final). Cada cambio de estado quedará registrado con sello de tiempo y usuario responsable usando el **chatter** de Odoo para mantener una trazabilidad automática. Adicionalmente, se podrá filtrar y buscar muestras por estado, paciente, código o tipo de prueba, facilitando el seguimiento de los trabajos en curso.
**Detalles técnicos y reutilización:** Para representar las muestras de paciente sin mezclarlas con los productos de inventario regulares (reactivos, bienes), se optará por **extender el modelo de lotes/series de inventario** (`stock.production.lot`, referido aquí como _stock.lot_) para que funcione como **registro de muestra**. Cada muestra física (p. ej. cada tubo) estará representada por un lote/serial único asociado a un **producto genérico de tipo "Muestra"**, diferenciado por tipo de muestra (sangre, orina, etc.). En el momento de la toma, el sistema creará un nuevo `stock.lot` para la muestra con un código único (que puede ser el mismo código de barras impreso) y le asignará el **propietario** (`owner_id`) correspondiente al paciente. Gracias a esto, Odoo tratará esa unidad en inventario como **propiedad del paciente y no de la compañía**, logrando que **no afecte las valoraciones ni aparezca en reportes financieros de stock**. Adicionalmente, se agregarán campos personalizados en el lote de muestra (mediante herencia del modelo) para almacenar información propia: estado de la muestra, fecha/hora de recolección, referencias a la orden y a los análisis asociados, etc.. Todas las muestras se ubicarán en **ubicaciones internas dedicadas** al laboratorio (por ejemplo un almacén "LAB/Muestras" con sub-ubicaciones para refrigeradores, estantes, etc.) separadas de las ubicaciones de reactivos, para evitar confusiones en los listados de inventario. Mediante reglas de acceso y filtros, estas ubicaciones y productos de tipo muestra se ocultarán de los menús generales de inventario para los usuarios comunes, quedando visibles solo en el contexto del módulo LIMS.
Internamente, la relación entre muestras y órdenes/pruebas quedará plasmada mediante enlaces de **uno a muchos**: una orden de laboratorio puede tener varias muestras asociadas, y cada muestra a su vez puede vincularse a uno o varios análisis (por ejemplo, un mismo tubo de sangre usado para química y hematología). Esto se gestionará asignando cada registro de análisis (ver sección siguiente) a la muestra correspondiente mediante un campo de relación `many2one` (`lims.test.sample_id`). Adicionalmente, el módulo aprovechará las funcionalidades nativas de códigos de barras de Odoo (módulo _Inventory_) para el escaneo rápido de muestras, y posiblemente las **etapas Kanban** para visualizar el flujo de estados de las muestras de forma gráfica (similar al uso de etapas en CRM), mejorando la experiencia de seguimiento.
### Gestión de Análisis y Resultados Clínicos (Core)
**Descripción:** Constituye el núcleo funcional del LIMS la capacidad de **ingresar, almacenar y validar los resultados** de las pruebas de laboratorio realizadas. Por cada análisis solicitado en una orden, el sistema debe permitir capturar uno o múltiples valores resultantes, comparar con rangos de referencia y marcar una vez que hayan sido revisados. El **técnico de laboratorio** será el encargado de ingresar los resultados obtenidos en los equipos o manualmente, mientras que un **Administrador (ej. patólogo)** deberá validar aquellos resultados antes de liberarlos en el informe final.
**Detalles operativos:** El módulo gestionará un **Catálogo maestro de pruebas de laboratorio**, donde se define cada tipo de análisis junto con los **parámetros medibles** que lo componen, sus unidades y rangos normales esperados. Por ejemplo, una prueba _Hemograma completo_ incluirá parámetros como Hemoglobina (g/dL), Hematocrito (%), Leucocitos (10^3/µL), etc., con sus intervalos de referencia por sexo/edad configurados. Esto permitirá que al registrar un resultado, el sistema despliegue automáticamente los campos requeridos para cada parámetro y pueda resaltar valores fuera de rango en la interfaz (p. ej. mostrando en rojo si un valor excede el normal).
El ingreso de resultados se hará desde una vista que liste las pruebas pendientes de resultados (por orden o por muestra). Al seleccionar una prueba, se presentarán campos de entrada para cada parámetro definido, aceptando valores numéricos, texto (ej. _Positivo/Negativo_) e incluso archivos adjuntos si aplica (por ejemplo una imagen de microscopía). Al guardar, la prueba pasará a estado _Resultado Ingresado_ (pendiente de validación). Si algún valor está fuera de los rangos normales configurados, el sistema puede generar **alertas visuales** al técnico e incluso comentarios automáticos sugeridos (e.g. "Valor fuera de rango, repetir prueba") para apoyo, aunque las interpretaciones médicas quedarán a criterio del especialista.
Antes de emitir el informe final, un **Administrador del laboratorio** deberá **verificar y validar** los resultados. Ciertas pruebas críticas podrán requerir obligatoriamente la doble validación por un usuario de rol supervisor antes de marcarse como _Validado_. Al validar, se registra quién y cuándo realizó la aprobación final, y la orden completa pasa a estado _Completada/Listo para Reportar_. Una vez validados todos los resultados de la orden, esta queda lista para generar el informe en PDF.
**Detalles técnicos y modelo de datos:** Para implementar esta gestión se introducirán nuevos modelos de datos con prefijo `lims.` que complementan la reutilización de productos de Odoo. Cada tipo de análisis en el catálogo será representado por un **producto de tipo Servicio** en Odoo (`product.template`/`product.product`), lo que permite aprovechar la definición de precio, impuestos y facturación. A estos productos se les añadirá un indicador (por ejemplo `is_lab_test=True` o categoría _Análisis Clínicos_) para distinguirlos de otros servicios, y se les asociará una lista de **parámetros** técnicos. Los parámetros de cada prueba se definirán en un modelo **`lims.test.parameter`**, que contendrá campos como nombre del parámetro, unidad de medida (`uom_id` reutilizando el módulo de Unidades de Odoo), valores de referencia mínimos/máximos (y posiblemente fórmulas o tablas por edad/sexo). Este modelo estará vinculado al producto de análisis mediante un campo `many2one` (un producto puede tener múltiples parámetros definidos).
Cuando se confirma una orden de laboratorio (ya sea como `sale.order` estándar), por cada línea de producto de análisis se creará internamente un registro en el modelo **`lims.test`** que representa la **prueba en proceso** asociada a esa orden y a ese paciente. El modelo `lims.test` incluirá campos `many2one` apuntando a la orden (o directamente a la línea de orden), al paciente, al tipo de prueba (producto) y a la muestra correspondiente (si la prueba requiere una muestra específica). También manejará su propio estado (_pendiente_, _en proceso_, _resultado ingresado_, _validado_, etc.) independiente del estado de la orden global.
Además, `lims.test` tendrá una relación One2many hacia un modelo de **Resultados por parámetro**, por ejemplo **`lims.result`**, en el que cada registro representa el valor obtenido para **un parámetro específico de esa prueba**. Cada `lims.result` enlazará al parámetro definido (`lims.test.parameter`) y contendrá el valor numérico o textual ingresado, un campo de observaciones y posiblemente una referencia a un archivo adjunto si se subió alguno (usando el módulo de Documentos de Odoo para guardar, por ejemplo, una imagen). De esta forma, una prueba con N parámetros tendrá N registros hijo en `lims.result`, facilitando la estructuración de los datos. En pruebas muy simples (p.ej. _Glucosa_ que solo tiene un valor) igual se manejará como una lista de un solo resultado para mantener un modelo consistente. La validación se puede implementar añadiendo un campo booleano `is_validated` en `lims.test` (marcado por el admin), o mediante estados adicionales, y controlando permisos para que solo el grupo de Administradores pueda cambiar ese flag/estado. Esto puede apoyarse en el flujo de aprobación nativo de Odoo (por ejemplo, con checks en vistas o transiciones condicionadas a grupo).
### Emisión de Reportes de Resultados en PDF (Core)
**Descripción:** Una vez validados los resultados, el sistema genera el **Informe de Laboratorio en PDF** listo para entregar al paciente y/o médico remitente. Este informe consolidado incluirá los datos del paciente, datos de la orden (fecha, código, médico solicitante si aplica), y una tabla con cada análisis realizado, sus resultados numéricos/textuales y los rangos de referencia correspondientes. También mostrará observaciones o comentarios añadidos, la fecha de validación, y los datos del laboratorio (nombre, logo y firma/autorización del responsable). El PDF será el **documento oficial** que recibe el paciente; en la primera fase no se prevé mostrar resultados en pantalla fuera de este PDF formateado.
**Detalles técnicos y reutilización:** Se utilizará el motor estándar de **reportes QWeb PDF** de Odoo para diseñar la plantilla del informe. Se partirá de un formato base que pueda personalizarse con el logo y colores de la empresa. La generación del informe se habilitará desde la orden de laboratorio (por ejemplo un botón "Imprimir Resultados" similar a "Imprimir Cotización/Factura"), y el sistema ensamblará los datos de paciente, orden, pruebas y resultados validados para renderizar el PDF. Cada informe generado se adjuntará al registro correspondiente (posiblemente al modelo `sale.order` o a un modelo `lims.request` si se usara) utilizando la funcionalidad de **adjuntos (ir.attachment)** de Odoo. Esto permite que, si más adelante se habilita un portal web, el paciente pueda descargar su resultado en PDF desde allí con los permisos adecuados. El historial de informes quedará así almacenado para futura consulta o reimpresión. Cabe mencionar que Odoo soporta múltiples plantillas, así que se podrían tener diferentes formatos según el tipo de prueba o cliente, aunque inicialmente se entregará un único diseño estándar. Finalmente, a través del sistema de email de Odoo, se podrá enviar automáticamente el informe PDF al paciente o al médico cuando esté listo, adjuntándolo en un correo con una plantilla de notificación (ej. "Sus resultados están disponibles"). Esto aprovecha las **herramientas de notificación** ya integradas en la plataforma en lugar de desarrollos ad-hoc.
## Integraciones Obligatorias con Módulos Odoo
Para funcionar plenamente dentro del ecosistema Odoo, el módulo LIMS debe integrarse con ciertos módulos base de forma **indispensable**. Estas integraciones son consideradas parte del _core_ pues sin ellas no se cumplirían requerimientos primarios (como la facturación). Las principales integraciones obligatorias son:
- **Contactos (`res.partner`) como Pacientes y Médicos:** En lugar de crear un modelo aislado de pacientes, se reutiliza el modelo de contactos de Odoo para representar a **pacientes** y **médicos remitentes**. Se añadirán flags booleanos (`is_patient`, `is_doctor`) y campos médicos (fecha de nacimiento, sexo, código de historia clínica, etc.) al modelo existente para adaptarlo al contexto clínico. Esto permite que pacientes y médicos estén disponibles en la libreta de direcciones general, y facilita integraciones con otros módulos (por ejemplo un paciente es también cliente para facturación, o un médico remitente puede ser un usuario portal). El control de acceso garantizará que solo personal autorizado vea los datos sensibles.
- **Ventas y Facturación (`sale` / `account`):** La **integración con el módulo de Ventas/Facturación de Odoo es obligatoria** para manejar el cobro de los servicios de laboratorio. Como se describió, cada orden de laboratorio será una orden de venta con líneas de producto (análisis) y usará el flujo estándar para generar una **factura** por dichos servicios. El módulo LIMS asegurará que al confirmar la orden se apliquen las reglas de facturación definidas: se podrá configurar si se factura por adelantado (factura inmediata) o al entregar resultados. En cualquier caso, la factura (`account.move`) quedará relacionada con la orden/paciente para trazabilidad. Se aprovechará toda la funcionalidad nativa de contabilidad: registro de pagos (efectivo, tarjeta, seguros), impuestos aplicables (ej. IVA), gestión de facturas pendientes, etc.. También se podrán generar **informes contables específicos** para el laboratorio (por ejemplo ingresos por tipo de prueba, cuentas por cobrar de convenios, etc.) apoyándose en las facturas y filtros/reportes de Odoo. La emisión de la factura al paciente podrá coordinarse con la entrega de resultados (incluso enviarse juntos por email en un mismo mensaje) para mejorar la experiencia del cliente. En síntesis, no se desarrollará un sistema de facturación paralelo sino que se **usarán los modelos y procesos estándar de Odoo**, integrando el LIMS de forma transparente con la contabilidad.
- **Usuarios y Seguridad:** El módulo integrará la gestión de **usuarios** de Odoo asignándolos a **grupos de seguridad específicos** del laboratorio (Recepción, Técnico, Administrador de Lab) con permisos definidos sobre los nuevos modelos. Se crearán **reglas de registro** para restringir, por ejemplo, que técnicos solo vean sus órdenes o que solo administradores puedan ver resultados validados, aprovechando el sistema de seguridad de Odoo. Esto extiende el módulo _Auth_ base de Odoo y asegura que la confidencialidad y segregación de funciones se mantenga consistente con otros módulos.
## Extensiones e Integraciones Opcionales
Además de las integraciones esenciales arriba mencionadas, el diseño propone varias **extensiones opcionales** que pueden activarse según las necesidades del laboratorio. Estas funcionalidades no son requeridas para un mínimo producto viable, pero añaden valor en escenarios más complejos o avanzados. Se listan a continuación, identificadas claramente como _opcionales_ para priorización en el desarrollo:
- **Integración con Inventario (Reactivos e Insumos) – _Opcional_:** Permite gestionar los **reactivos de laboratorio, materiales y suministros** mediante el módulo de **Inventario** de Odoo. Los reactivos (por ejemplo reagentes químicos, tiras de prueba) se dan de alta como productos almacenables normales, organizados en categorías (Reactivos Químicos, Material de Muestreo, etc.), habilitando control de stock, lotes y fechas de caducidad. Al activar esta extensión, cada tipo de análisis podrá llevar asociada una “receta” de insumos necesarios (similar a una lista de materiales o **BOM**) indicando qué productos y en qué cantidad consume cada prueba. De este modo, cuando se registra un resultado o se completa una prueba, el sistema puede **descontar automáticamente del inventario** los reactivos utilizados, ya sea creando movimientos internos de consumo o mediante órdenes de fabricación simbólicas que consumen materiales sin producir un artículo tangible. Esto brinda **trazabilidad** de qué lote de reactivo se usó en cada muestra (útil ante controles de calidad o retiros) y permite calcular **costos por prueba** en base a los insumos gastados. También habilita funcionalidades de Odoo como puntos de reorden para stock mínimo y órdenes de compra automáticas al proveedor cuando un reactivo esté por agotarse. Por último, al gestionar los reactivos en Odoo, se puede aprovechar el módulo de **Calidad** para, por ejemplo, bloquear el uso de lotes vencidos (vía campos de caducidad y estados de bloqueo) y programar alertas de vencimiento de lotes (usando el _scheduler_ estándar de productos caducos). En resumen, esta integración opcional convierte el LIMS en un sistema completo no solo de información de laboratorio sino también de administración de insumos, aunque se deja configurable para laboratorios que prefieran llevar el inventario fuera del sistema.
- **Programación de Citas (_Calendar_) – _Opcional_:** Integración con el calendario de Odoo para manejar **citas de pacientes** para toma de muestras o entrega de resultados. El laboratorio podría definir franjas disponibles y agendar citas para evitar aglomeraciones y mejorar la planificación. Incluso se podría exponer un portal de reservas en línea para pacientes (aprovechando el sitio web de Odoo) o simplemente usar el calendario internamente para que el recepcionista cite a cada paciente y el sistema envíe recordatorios por email/SMS. Esta funcionalidad es útil en entornos de alta demanda (p.ej. campañas, pandemias) para gestionar el flujo de pacientes.
- **Portal Web para Pacientes y Médicos – _Opcional_:** Mediante el portal de Odoo, se puede permitir que los pacientes (o médicos remitentes) accedan con credenciales a una sección donde visualizar y descargar sus **informes de resultados en PDF** una vez disponibles. Asimismo, médicos u otras clínicas podrían **enviar órdenes al laboratorio** electrónicamente a través del portal o vía integración API, las cuales caerían directamente en el LIMS para ser procesadas. Esto mejora la comodidad y reduce tiempos, emulando portales que existen en LIMS comerciales. Su implementación requiere exponer adecuadamente modelos como `sale.order` (u órdenes de laboratorio) en el portal, filtrados por usuario y con medidas de seguridad estrictas.
- **Integración con Sistemas Clínicos/Hospitalarios – _Opcional_:** Si la organización cuenta con otros módulos de salud (ej. un módulo de **Historia Clínica** o de **Gestión Hospitalaria**), el LIMS debería poder integrarse para **recibir solicitudes externas** y **enviar de vuelta resultados** automáticamente. Esto podría lograrse reutilizando la base de datos de pacientes compartida (`res.partner`) y mediante mecanismos como la API REST de Odoo o señales dentro de la base de datos. Por ejemplo, un médico desde el módulo de consultas podría generar una solicitud de laboratorio que cree una orden de venta con los productos de análisis correspondientes, visible al laboratorio inmediatamente. Al validarse los resultados, el sistema LIMS podría adjuntar el PDF en la historia clínica del paciente o notificar al médico remitente. Esta integración asegura un flujo de información sin fisuras en entornos donde el laboratorio es parte de un sistema de salud más amplio.
- **Mantenimiento de Equipos de Laboratorio – _Opcional_:** Integración con el módulo de **Mantenimiento** de Odoo para llevar registro de **calibraciones, mantenimiento preventivo y correctivo** de los equipos de laboratorio (ej. auto-analizadores, centrífugas). Se podrían programar órdenes de mantenimiento periódicas, registrar calibraciones realizadas (fecha, resultado, próximo vencimiento) y asociar cada equipo a sus pruebas. Incluso, el LIMS podría condicionar la validez de resultados según el estado del equipo (p.ej. advertir o bloquear si un equipo está vencido en calibración). Esto es importante en laboratorios certificados con normas de calidad (ISO 15189, etc.), pero se considera una extensión avanzada.
- **Compras y Proveedores – _Opcional_:** Extensión del uso del módulo **Compras** para gestionar la adquisición de reactivos e insumos. Combinado con el inventario opcional, se pueden generar automáticamente **Órdenes de Compra** o solicitudes de cotización al llegar a mínimos de stock, manejar múltiples proveedores por reactivo, registrar los costos y lotes desde la recepción de mercadería, e incluso adjuntar documentos como fichas de seguridad químicas en cada producto. Esta integración garantiza el abastecimiento oportuno de insumos y cierra el ciclo de stock desde la compra hasta el consumo en análisis.
- **Recursos Humanos – _Opcional_:** Si se desea, se puede relacionar el módulo LIMS con **Empleados (HR)** de Odoo para registrar el personal de laboratorio, sus roles, turnos y competencias. Por ejemplo, se podrían restringir ciertas acciones a técnicos con certificaciones específicas (definidas en el perfil del empleado), o llevar el calendario de turnos para asegurar cobertura. Aunque no es imprescindible para el funcionamiento básico, aprovechar HR permitiría, por ejemplo, saber qué técnico realizó cada prueba (ligando la muestra al empleado usuario, lo cual ya se hace parcialmente con usuarios) y extraer reportes de productividad por empleado, entre otros.
- **Soporte Multi-sucursal/Compañía – _Opcional_:** Diseño preparado para soportar múltiples **sucursales de laboratorio** o esquema multi-compañía de Odoo. Esto implica que las órdenes, muestras y facturas estén asociadas a la compañía correspondiente, permitiendo que varios laboratorios (empresas) operen en la misma base de datos de Odoo aisladamente. También se podría utilizar para manejar **centros de toma de muestra** distintos a la sede principal, con las muestras identificadas por su origen. Gracias a que Odoo ya soporta multi-compañía, el módulo LIMS respetará dichas reglas (por ejemplo, separando secuencias de folios por compañía, o filtrando datos por compañía del usuario) para que sea escalable a organizaciones con presencia en varios sitios.
Cada integración opcional se desarrollará de manera **modular y configurable**. Es decir, el módulo LIMS base funcionará sin necesidad de activarlas, pero detectará si los correspondientes módulos están instalados para habilitar sus características. Por ejemplo, si no se instala Inventario, simplemente no se registrarán consumos de reactivos; si no se instala Portal, no aparecerán opciones de publicación web de resultados, etc.. Esto asegura que el desarrollo sea flexible y que cada laboratorio active solo las partes que necesita, priorizando primero el **núcleo mínimo funcional** y luego incorporando extensiones según requerimientos específicos.
## Modelo de Datos Propuesto
Los principales modelos de datos y sus relaciones se ilustran en el siguiente diagrama ERD. Se han resaltado los nuevos modelos introducidos (prefijo **`lims.`**) y cómo se vinculan con los modelos estándar de Odoo:
 _Figura: Diagrama ERD del modelo de datos del LIMS. En color azul se muestran los nuevos modelos (lims._) agregados por el módulo, mientras que los blancos representan modelos estándar de Odoo reutilizados. Las flechas indican relaciones principales: por ejemplo, la Orden de Laboratorio (`sale.order`) referencia un Paciente (`res.partner`), y cada Prueba de Laboratorio (`lims.test`) pertenece a una Orden, está asociada a un tipo de Análisis (producto) y opcionalmente a una Muestra física (`stock.lot`). Cada Prueba tiene múltiples Resultados (`lims.result`), uno por parámetro definido (`lims.test.parameter`).\*
Como se muestra, la **orden de laboratorio** se modela sobre `sale.order` con su campo `partner_id` apuntando al paciente (contacto). Cada análisis solicitado en la orden es un producto de servicio (`product.template`) que define un **Análisis** del catálogo. A nivel de datos, por cada análisis de la orden se genera un registro en `lims.test` (Prueba de Laboratorio) que representa la ejecución de ese análisis para el paciente y muestra dados. El modelo `lims.test` está vinculado a la orden (many2one a `sale.order`), al paciente (redundante vía la orden, pero posible campo directo para facilidad), al **producto** del análisis (many2one a `product.product`) y a la **muestra** correspondiente (many2one a `stock.lot` de tipo muestra) si aplica.
El **modelo de Muestra** en sí no se define como uno nuevo, sino que se implementa extendiendo `stock.production.lot` (serie de producto) con campos adicionales, manteniendo así la integración con inventario. Cada lote de muestra está ligado a un **producto tipo "Muestra"** genérico según su tipo (sangre, orina, etc.), y marcado con el `owner_id` del paciente. Esto permite rastrear su ubicación en inventario sin contaminar los reportes contables (gracias a owner_id, Odoo los excluye de stock de la compañía). En la práctica, podría definirse un modelo `lims.sample` que herede de `stock.lot` para exponerlo en las vistas del LIMS, pero la base de datos aprovechará las tablas existentes de stock para no duplicar información.
El **Catálogo de análisis** se maneja principalmente con el modelo `product.template`: cada análisis es un producto con precio, y se distingue por una categoría o flag especial. Para los aspectos técnicos, se introduce el modelo `lims.test.parameter` que almacena los parámetros detallados de cada análisis (relación many2one con el producto de análisis). A su vez, cuando se registran resultados, se crean instancias de `lims.result` ligadas tanto a la prueba (`lims.test`) como al parámetro definido (`lims.test.parameter`), conteniendo el valor obtenido. Esto garantiza la normalización: la definición de cada parámetro (unidad, valores normales) está centralizada, mientras que los resultados particulares referencian esa definición.
En cuanto a **facturación**, al usar `sale.order` y sus líneas para las órdenes de laboratorio, la relación con las facturas se maneja por Odoo estándar: la confirmación de la orden genera un `account.move` (factura) relacionado, con líneas correspondientes a cada análisis (producto). En el diagrama se omite la representación de la factura por ser un modelo estándar, pero debe entenderse que `sale.order` tiene su campo `invoice_ids` y sigue el flujo normal.
Por último, la relación entre **orden, muestras y pruebas** merece resaltarse: una orden puede tener múltiples muestras (ej. distintos tipos de muestra para distintos análisis), y una muestra puede usarse para varios análisis. En el esquema propuesto, cada `lims.test` lleva un campo `sample_id` apuntando a la muestra que utilizó; de esta manera, múltiples pruebas pueden referenciar el mismo `stock.lot` cuando provinieron del mismo tubo. Adicionalmente, el `stock.lot` de muestra apunta al paciente (vía owner) y al producto tipo muestra, cerrando el lazo de información.
### Consumo de reactivos al ejecutar una prueba (Extensión Inventario)
A continuación se detalla cómo se realizará el **descuento de reactivos** cuando se ejecute una prueba de laboratorio, ampliando la sección de Inventario opcional:
| Escenario | Mecanismo | Pasos técnicos |
| ------------------------------------------ | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Inventario activo – consumo automático** | **Lista de materiales (BOM) + movimiento interno** | 1. Cada análisis (`product.product`) mantiene una **BOM** de tipo _consumo_ con sus reactivos.<br>2. Al cambiar `lims.test.state` de `draft` → `in_process`, el método `_create_reagents_move()` genera un `stock.move` _Internal_ restando la cantidad y lote FEFO.<br>3. El `stock.move` se confirma automáticamente.<br>4. Campo `stock_move_id` en `lims.test` enlaza la auditoría. |
| **Inventario activo – revisión manual** | **Wizard “Confirmar consumo”** | Igual que el caso anterior, pero el movimiento se crea en **borrador** y se abre un wizard editable antes de validar. |
| **Inventario inactivo** | **Consumo teórico** | Sólo se calcula `lims.test.theoretical_cost` a partir de la BOM. No se crean movimientos de stock reales. |
> ```python
> def action_start_analysis(self):
> self.write({'state': 'in_process', 'analysis_start': fields.Datetime.now()})
> if self.env['ir.config_parameter'].sudo().get_param('lims.use_inventory'):
> self._create_reagents_move()
> ```
### Pacientes menores de edad y facturación
Se amplía la sección de _Recepción de Pacientes_ para contemplar menores de edad:
1. **Estructura de contactos**
- El menor se registra como un `res.partner` con `is_patient = True` y `parent_id` apuntando a su tutor (madre, padre, etc.).
2. **Campos de la orden**
- `patient_id` (m2o→res.partner) = menor.
- `invoice_partner_id` = tutor por defecto (o aseguradora).
3. **Flujo de creación de orden**
- Al escoger al bebé, un _onchange_ rellena `invoice_partner_id` con el padre/madre.
- La factura (`account.move`) se emite al tutor, mientras el expediente clínico (`lims.test`, muestras, resultados) sigue apuntando al menor.
4. **Informe PDF**
- Se imprimen ambos bloques:
```
Paciente: Juan Carlos Pérez (3 meses)
Responsable de pago: María Pérez
```
5. **Ventajas**
- Reutiliza `parent_id` ya soportado por Odoo.
- Mantiene datos fiscales del responsable sin duplicar.
- Permite varios tutores si se usa un campo many2many (`guardian_ids`).
## Flujos de Proceso Principales
Para entender la secuencia de actividades entre los distintos roles (Recepcionista, Técnico de Laboratorio, Administrador, etc.) y el sistema, se presenta a continuación un **diagrama de flujo** simplificado del proceso desde la recepción de una orden hasta la entrega de resultados. Este flujo asume un caso típico con pago por adelantado; variaciones (como facturación al final o inclusión de módulos opcionales) no se muestran para mantener la claridad general:
&#x20;_Figura: Diagrama de flujo del proceso LIMS principal. Se ilustran las etapas core: el **Recepcionista** registra la orden y prepara las etiquetas; el **Técnico de Lab** recoge la muestra y actualiza su estado, luego realiza los análisis y carga los resultados; el **Administrador** verifica y valida los resultados; finalmente el **Sistema** genera el informe PDF y se procede a la entrega al paciente/médico. Los pasos de facturación pueden ocurrir al registrar la orden o al final según configuración, integrados mediante Odoo._
Como muestra el diagrama, el proceso inicia con la **recepción** de la solicitud: el recepcionista ingresa la orden en el sistema seleccionando al paciente (o creando uno nuevo) y las pruebas requeridas, tras lo cual imprime las etiquetas de código de barras. En ese momento también puede realizar el cobro según la política (pago inmediato con factura o a crédito). Luego el caso pasa al área de laboratorio: un técnico toma la muestra del paciente, escanea la etiqueta y marca la muestra como _Recogida_ en el sistema. El técnico procede a realizar los análisis indicados; conforme obtiene resultados, los introduce en la interfaz correspondiente del LIMS. Cuando todos los resultados están ingresados, un administrador/supervisor los revisa uno a uno y marca la prueba (o la orden completa) como _Validada_, indicando conformidad. Acto seguido, el sistema compila toda la información validada y genera el **informe PDF** oficial. El recepcionista puede entonces **entregar** el informe al paciente impreso o enviarle un correo con el PDF adjunto; adicionalmente, si el portal web está habilitado, el paciente podría descargar el resultado en línea. En paralelo, la factura por los servicios prestados habrá sido ya confirmada y entregada (o queda lista para su emisión si se factura al final). Todo el proceso queda registrado en Odoo para consultas futuras, trazabilidad de cada paso (mediante historiales en chatter, movimientos de stock para muestras, etc.) y generación de métricas operativas.
## Conclusiones y Consideraciones Finales
El diseño propuesto se enfoca en **no reinventar la rueda**, integrando la solución de laboratorio de forma nativa con Odoo 18. Se identificaron los **componentes núcleo** que deben desarrollarse (órdenes, muestras, resultados, informes) y se definieron claramente las **integraciones obligatorias** (Contactos, Ventas/Facturación, Seguridad) frente a las **extensiones opcionales** (Inventario, Portal, Citas, Mantenimiento, etc.). Esto permite planificar el proyecto en fases, priorizando primero el core para lograr un producto funcional mínimo, y luego incorporando las características opcionales según las necesidades prioritarias del laboratorio. La utilización de un prefijo común (`lims.`) en los nuevos modelos facilita su identificación en el código y en la base de datos, aislando la lógica específica de laboratorio.
En términos de **precisión técnica**, se detalló la estructura de datos con nuevos modelos y campos, las relaciones clave (ej. vincular muestras con propietario para no alterar stock financiero) y el aprovechamiento de capacidades existentes de Odoo (como lotes, BOM, reportes QWeb, portal, etc.). Esto asegura que el desarrollo se alinee con las mejores prácticas de la plataforma, maximizando la mantenibilidad y minimizando desarrollos ad-hoc. En resumen, el módulo LIMS integrará la gestión de laboratorio clínico al ecosistema Odoo de manera cohesionada, permitiendo eficiencia operativa y trazabilidad total de muestras y resultados, al mismo tiempo que permanece extensible para futuras necesidades o integraciones adicionales. Todas las decisiones de diseño tomadas buscan un balance entre **funcionalidad** (cumplir con los requerimientos clínicos específicos) y **reutilización** (apoyarse en la sólida base de Odoo para lo común), asegurando una implementación robusta y escalable.
## ERD (formato marmaid)
erDiagram
RES_PARTNER ||--o{ SALE_ORDER : "patient_id"
RES_PARTNER ||--o{ SALE_ORDER : "invoice_partner_id"
RES_PARTNER ||--o{ RES_PARTNER : "parent_id / guardian"
SALE_ORDER ||--|{ SALE_ORDER_LINE : contains
SALE_ORDER_LINE }o--|| PRODUCT_PRODUCT : "analysis product"
SALE_ORDER_LINE ||--|{ LIMS_TEST : generates
LIMS_TEST ||--|| SALE_ORDER_LINE : "source line"
LIMS_TEST }o--|| STOCK_PRODUCTION_LOT : "sample_id"
LIMS_TEST }o--|| PRODUCT_PRODUCT : "analysis type"
LIMS_TEST ||--o{ LIMS_RESULT : has
LIMS_TEST_PARAMETER ||--o{ LIMS_RESULT : "parameter_id"
PRODUCT_PRODUCT ||--o{ LIMS_TEST_PARAMETER : defines
LIMS_TEST }o--|| STOCK_MOVE : "stock_move_id"
STOCK_MOVE }o--|| STOCK_PRODUCTION_LOT : "consumes lot"