# Destrabar el flujo de pacientes en el sistema

Para destrabar el flujo de pacientes generalmente realizamos dos cosas.
- Si es un error de negocio, realizamos cambios de features / código.
- Si es un error de pacientes en particular, realizamos nuestras muy mencionadas "Migraciones de Multis"

## Errores de Negocios

### Razones
Estos errores se deben a tener mal implementada alguna lógica del negocio en nuestro sistema.

**Por ejemplo:** Tenemos el caso de los pacientes con tratamientos de braquiterapias. Anteriormente (antes de la salida a PROD). Para poder darles un turno de equipo, realizabamos los mismos chequeos que con cualquier otro tratamiento, verificabamos si tienen placa verificadora, si tienen simulación y demás. Pero en la realidad todo estos chequeos no eran necesarios, bastaba con ser una braquiterapia y que no esté archivado el tratamiento para tenderlo.

### Como solucionarlo
Averiguar la lógica de negocios correcta y realizar los respectivos cambios en el código

## Errores en el flujo de los pacientes debido al sistema

### Razones
Estos errores generalmente se deben a bugs que tenemos en el sistema que aún no pudimos identificar o falta de lógica en algunas partes. El problema más grande de estos es que si el bug se da en lugares cruciales del sistema (El seguimiento de una historia clínica) los pacientes no pueden avanzar en el flujo de su tratamiento.

**Por ejemplo:** Uno de los bugs que se nos está escapando, es el de la tomosimulación, por alguna razón al momento de atender los turnos de tomosimulación (cuando atendemos NO ES LO MISMO QUE dar el presente) no se actualiza el estado de la definición de conducta, por lo tanto, no se actualiza el seguimiento y el flujo de los pacientes termina estancado.

### Como solucionarlo

Para resolver estos errores particulares, lo que hacemos es un método que llamamos "Migraciones de Multis". Estas migraciones una vez revisas y mergeadas, se ejecutan primero en **BACK-UP** para ver si destraba al / los paciente/s y luego se ejecuta en **PROD**. Además de eso, absolutamente TODAS estas migraciones deben ser registradas en algún lugar como que fueron ejecutadas, esto lo hacemos mediante el esquema `Mevaterapia.Migrations.MigrationFixRegister` donde guardamos el **nombre** de la migración y **cuando** se ejecutó. De esa forma nos aseguramos de no poder ejecutar la misma migración más de una vez y también podemos ver las que ejecutamos previamente.

#### Pasos a seguir para crear el Multi

##### **1. Investigar al paciente**
Tenemos que revisar el estado en el que ESTÁ y en CUAL DEBE ESTAR. Puede que el paciente haya asistido a turnos de placas verificadoras y el follow up nunca se actualizó. Pero esto puede ser por otra razón, como que el follow up se estancó en un estado anterior.

Hay que ser meticulosos en esta parte, porque lo que hacemos generalmente es buscar los IDs mediante la URL o queries. Los problemas más comunes son:
- Tomar IDs incorrectos
- Revisar Testing en vez de BackUp o Prod (Está desfasado generalmente)
- Confundir IDs de tablas (Esto pasa si estamos buscando la IDs mediante queries)

##### **2. Realizar la migración**
Antes de seguir, dejo algunos PRs relacionados para poder guiarse mientras se lee.
- [Fixes for field end_at in agreements](https://github.com/lambdaclass/mevaterapia/pull/1758) (Una migración con queries, arregla un error de datos mal migrados, refiriéndome a migrar los datos de su DB a la nuestra)
- [Fix Tomograph & Ingress statuses](https://github.com/lambdaclass/mevaterapia/pull/1699/files) (Una migración con mapas, casos puntuales)
- [Cu 865bbw9xt restore invoice items](https://github.com/lambdaclass/mevaterapia/pull/1878)

Al crear el código de la migración, siempre consta de N partes esenciales
1. Creamos un `Ecto.Multi` y le creamos un nombre UNICO a la migracion para identificarla luego en el schema migration_fixer
2. La primer operación que se agrega a ese Multi, es verificar que la migración no se haya ejecutado antes para esto usamos el nombre unico que definimos en el paso 1, en caso de que no, pasamos al paso 3.
3. En este paso se realiza la actualización de los datos actuales a los deseados. Que se puede realizar de dos formas distintas:
- Mediante mapas, es decir, crear un mapa que tenga la siguiente estructura

%{
      # Nombre de lo que vamos a modificar - Qué vamos a modificar
      "ID-DE-LO-QUE-MODIFICAMOS" => %{campo: nuevo_valor}
}

Por ejemplo, queremos actualizar el micro status del tratamiento de un paciente:

%{
    # Faure, Estela Noemi - Tridimensional Conformado - lecho de histerectomia+areas ganglionares
    "2dfd77d9-cc64-495d-a0d7-b0e895dcc9dd" => %{micro_status: :ingress}
}

En este caso, la ID que estamos utlizando es la ID del tratamiento Tridimensional Conformado - lecho de histerectomia+areas ganglionares que realiza la paciente Faura, Estela Noemi
Fuente: [Fix Tomograph & Ingress statuses](https://github.com/lambdaclass/mevaterapia/pull/1699/files)

- En otros casos, puede que tengamos que realizar queries de un schema entero y actualizar sus valores, para esto les dejo como referencia el siguiente [PR](https://github.com/lambdaclass/mevaterapia/pull/1758).

##### **3. Review de la migración**
En este paso, los reviewers deben de ejecutar la migración en el dump más actual de PROD. Pasos a seguir
1. Ejecutar la migración
2. Ejecutar nuevamente la migración para ver que no se pueda ejecutar dos veces
3. Revisar que la migración haya actualizado correctamente los datos que DEBÍA actualizar, absolutamente todo (Si son muchos casos particulares, bueno, inducción (?)) y en revisar si el multi bastó para destrabar el flujo del paciente por ejemplo un error común es: los pacientes no se puedan seguir creando aplicaciones porque no tienen registrada la fecha del ok medico en el status, la forma de revisar esto es :
1. ejecutar el multi
2. Revisar que la fecha haya sido cargada correctamente
3. Intentar crear una nueva aplicacion para el paciente con exito

Una vez mergeado el PR se pasa al siguiente punto

###### **4. Ejecutarlo en PROD**

Este paso es el más sencillo (?).
1. Ejecutamos primero la migración en BACKUP, es básicamente realizar el Punto 3 (Sin la parte de la review). Si todo está OK seguimos con el siguiente punto
2. Ejecutarlo en PROD, verificar y avisar al cliente (Esto lo hace Nico generalmente)

### Extra: Consideraciones al crear las migraciones
Estos son cositas que fuimos aprendiendo mientras hacíamos las migraciones.
- Si hace falta documentar cosas, se documentan, ya sea de donde sacaron las IDS, como las sacaron, si hubo información extra del cliente, etc.
- Relacionado al punto anterior, si hay que usar datos que ya están en la DB, es mejor no utilizar dejar datos arbitrarios en la migración, realizar un **get** de la db y listo.
- Revisar al menos 2 veces lo que se está cambiando, si hace falta preguntar al cliente, se pregunta
- Siempre se agrega una mini descripcion del objetico del multi como docmodule en la migración, describiendo el problema a solucionar
- Es muy importante revisar bien las ids de los schemas que se busca cambiar, los cambios no siempre son visibles en la ui