# Listado de Tareas de Desarrollo para Módulo LIMS en Odoo 18

A continuación se presenta un listado detallado y granular de las tareas de desarrollo necesarias para implementar el módulo de Gestión de Laboratorio Clínico (LIMS) sobre Odoo 18, basado en los documentos de requerimientos y diseño técnico.

---

## Funcionalidades Core

### [Core] Configuración y Modelos Base del Módulo
**Detalle:**
- Crear el módulo Odoo `lims_management` con su estructura de directorios (`models`, `views`, `security`, `report`, `data`).
- Definir los grupos de seguridad principales en `security/lims_security.xml`: Recepcionista (`group_lims_receptionist`), Técnico de Laboratorio (`group_lims_technician`), y Administrador de Laboratorio (`group_lims_admin`).
- Asignar jerarquías a los grupos (ej. Administrador hereda permisos de Técnico y Recepcionista).
- Crear el menú principal del módulo "Laboratorio" y los submenús iniciales (Órdenes, Pacientes, Catálogo de Pruebas, etc.).

### [Core] Gestión de Pacientes y Médicos (Extensión de Contactos)
**Detalle:**
- Extender el modelo `res.partner` para añadir los campos necesarios:
    - `is_patient` (Booleano) para identificar pacientes.
    - `is_doctor` (Booleano) para identificar médicos remitentes.
    - `patient_history_id` (Char) para el número de historia clínica.
    - `birthdate_date` (Fecha) y `gender` (Selección) para cálculos de rangos de referencia.
    - `parent_id` (Many2one a `res.partner`) para asociar pacientes menores de edad con su tutor legal.
- Modificar la vista de formulario de Contactos para mostrar estos campos en una nueva pestaña "Información Clínica".
- Aplicar reglas de registro para que la información clínica sensible solo sea visible para roles autorizados del laboratorio.

### [Core] Catálogo de Análisis Clínicos (Extensión de Productos)
**Detalle:**
- Extender el modelo `product.template` para añadir un campo `is_lab_test` (Booleano) que identifique los productos que son análisis de laboratorio.
- Crear el modelo `lims.test.parameter` con los campos:
    - `name` (Nombre del parámetro, ej. "Hemoglobina").
    - `product_id` (Many2one a `product.template`, el análisis al que pertenece).
    - `uom_id` (Many2one a `uom.uom`, unidad de medida).
    - `reference_min`, `reference_max` (Float, para rangos numéricos).
    - `reference_text` (Char, para valores cualitativos como "Negativo").
    - `gender`, `age_min`, `age_max` para definir rangos contextuales.
- Crear la vista de producto para que en la pestaña "Laboratorio" se puedan gestionar los parámetros (`One2many` a `lims.test.parameter`).

### [Core] Gestión de Órdenes de Laboratorio (Sobre `sale.order`)
**Detalle:**
- Personalizar la vista de formulario de `sale.order` para que funcione como "Orden de Laboratorio". Cambiar etiquetas y ocultar campos no relevantes para el flujo LIMS.
- Añadir un campo `patient_id` (Many2one a `res.partner`, dominio `[('is_patient', '=', True)]`) a `sale.order`.
- Implementar un `onchange` para que al seleccionar un paciente menor de edad, el campo de dirección de factura (`partner_invoice_id`) se popule automáticamente con el tutor (`parent_id`).
- Sobrescribir el método `action_confirm` de `sale.order` para que, además de confirmar la venta, dispare la creación de los registros `lims.test` y las muestras (`stock.lot`) correspondientes.

### [Core] Gestión de Muestras (Sobre `stock.lot`)
**Detalle:**
- Crear un producto genérico "Muestra de Laboratorio" (`product.template`) de tipo almacenable, no vendible/comprable, y con seguimiento por Lote/Nº de Serie.
- Extender el modelo `stock.lot` para añadir campos específicos de la muestra:
    - `sample_state` (Selección: `pending`, `collected`, `in_analysis`, `result_ready`, `validated`, `disposed`).
    - `collection_datetime` (Datetime, fecha y hora de toma).
    - `collected_by_id` (Many2one a `res.users`, técnico que tomó la muestra).
    - `disposal_date` (Date, fecha de descarte).
    - `sale_order_id` (Many2one a `sale.order`).
- Crear ubicaciones de inventario específicas para el laboratorio (ej. "LAB/Muestras/Recepción", "LAB/Muestras/Almacenamiento Frío") separadas del stock general.
- Al confirmar una orden, generar un `stock.lot` por cada muestra requerida, asignando al paciente como propietario (`owner_id`) para que no afecte la valoración de inventario.
- Desarrollar una vista Kanban para `stock.lot` que muestre las muestras agrupadas por su estado (`sample_state`).

### [Core] Gestión de Pruebas y Resultados
**Detalle:**
- Crear el modelo `lims.test` para representar la ejecución de un análisis:
    - `sale_order_line_id` (Many2one a `sale.order.line`).
    - `patient_id` y `product_id` (relacionados desde la línea de pedido).
    - `sample_id` (Many2one a `stock.lot`).
    - `state` (Selección: `draft`, `in_process`, `result_entered`, `validated`, `cancelled`).
    - `validator_id` (Many2one a `res.users`), `validation_date` (Datetime).
- Crear el modelo `lims.result` para almacenar cada valor de resultado:
    - `test_id` (Many2one a `lims.test`).
    - `parameter_id` (Many2one a `lims.test.parameter`).
    - `value_numeric` (Float), `value_text` (Char), `value_selection` (Selección).
    - `is_out_of_range` (Booleano, calculado).
    - `notes` (Texto para comentarios del técnico).
- Desarrollar la interfaz de ingreso de resultados: una vista de formulario para `lims.test` con una lista editable (`One2many`) de sus `lims.result`, donde los campos de parámetro se cargan dinámicamente.
- Implementar la lógica visual para resaltar en rojo los resultados (`lims.result`) que estén fuera de su rango de referencia.

### [Core] Flujo de Validación y Seguridad
**Detalle:**
- Implementar la máquina de estados en el modelo `lims.test` para controlar las transiciones (ej. no se puede validar si no hay resultados ingresados).
- Crear reglas de registro (`ir.rule`) para asegurar que:
    - Los recepcionistas solo puedan crear y ver órdenes, pero no ingresar ni validar resultados.
    - Los técnicos puedan ver órdenes asignadas, registrar la toma de muestra e ingresar resultados, pero no validar.
    - Los administradores sean los únicos que puedan mover una prueba al estado `validated`.
- Registrar en el chatter de `lims.test` y `stock.lot` cada cambio de estado, validación o acción relevante para auditoría.

---

## Tareas de Reportes

### [Reporte] Etiquetas de Muestras con Código de Barras
**Detalle:**
- Crear una plantilla de reporte QWeb para generar etiquetas de muestra.
- La etiqueta debe incluir: Nombre del paciente, ID de la orden, tipo de muestra y un código de barras/QR único (basado en el `name` del `stock.lot`).
- Añadir un botón "Imprimir Etiquetas" en la orden de laboratorio (`sale.order`) que ejecute este reporte para todas las muestras asociadas.

### [Reporte] Informe Final de Resultados en PDF
**Detalle:**
- Crear una plantilla de reporte QWeb compleja y profesional para el informe de resultados.
- El reporte debe tener un encabezado con datos del laboratorio (logo, dirección) y del paciente.
- La sección de resultados debe agrupar los análisis y listar los parámetros en una tabla con columnas: `Parámetro`, `Resultado`, `Unidad`, `Valor de Referencia`.
- Implementar la lógica para resaltar visualmente (ej. con color o un símbolo) los valores fuera de rango.
- Incluir una sección para comentarios/observaciones y los datos del profesional que validó el informe.
- Añadir un botón "Imprimir Informe de Resultados" en la orden, que solo se active cuando todas las pruebas estén en estado `validated`.
- El PDF generado debe guardarse automáticamente como adjunto en la orden de laboratorio.

---

## Tareas de Integración (Obligatorias)

### [Integración] Flujo de Facturación y Cobro
**Detalle:**
- Configurar las políticas de facturación en los productos de análisis (ej. `service_policy` en Odoo).
- Asegurar que la creación de la factura desde la `sale.order` funcione correctamente según la política definida (al confirmar la orden o al finalizar el servicio).
- Personalizar la vista de la factura (`account.move`) si es necesario para incluir referencias a la orden de laboratorio.
- Garantizar que los pagos se puedan registrar usando los métodos estándar de Odoo (diarios de caja, banco, etc.).

---

## Tareas de Extensiones Opcionales

### [Extensión Opcional] Gestión de Inventario de Reactivos
**Detalle:**
- Configurar los reactivos como productos almacenables con seguimiento por Lote y reglas de caducidad (FEFO).
- Permitir asociar una Lista de Materiales (BOM) a cada producto de análisis para definir los reactivos que consume.
- Desarrollar la lógica para que al iniciar un `lims.test` (`state` = `in_process`), se genere y valide automáticamente un movimiento de stock (`stock.move`) para descontar los reactivos de la BOM del inventario.
- Crear alertas o notificaciones para lotes de reactivos próximos a caducar o con bajo stock (utilizando los schedulers y reglas de reorden de Odoo).

### [Extensión Opcional] Portal Web para Pacientes/Médicos
**Detalle:**
- Extender los controladores del portal de Odoo para mostrar las órdenes de laboratorio (`sale.order`) al usuario logueado.
- Crear una vista en el portal para que el paciente/médico pueda ver el estado de su orden y descargar el informe PDF de resultados cuando esté disponible.
- (Avanzado) Crear un formulario en el portal para que médicos remitentes puedan crear nuevas órdenes de laboratorio de forma remota.

### [Extensión Opcional] Integración con Calendario para Citas
**Detalle:**
- Integrar con el módulo `calendar` de Odoo.
- Añadir un botón en la orden de laboratorio para "Agendar Cita" de toma de muestra, creando un `calendar.event`.
- El evento del calendario debe estar vinculado al paciente y a la orden de laboratorio.
- Configurar recordatorios automáticos por email para las citas agendadas.
