La modifique porque tenia un pequeño error y ademas para que quede mas parecido el formato a las que hice con mazzi

Renombre de archivo... me habia salteado la "u"

Se adjunta al pie un comentario de cada evento, explicando el CU y el actor que hace efectiva la transición de estados.

Versión inicial del diagrama de estados de una autorización manual.
La idea es que quien tenga dudas de como es la vida de una autorizacion manual, simplemente abra este diagrama.
Cada estado tiene asociado un comentario con las condiciones (una por renglón) para que se pueda decir que la autorización está en ese estado específico. No debería haber ambigüedad de estados.

especificación actualizada. Falta refinar los datos a pedirle a la Clínica, pero la base está. :)

No habiamos eliminado al solicitante

Se cambio nombre de atributo.

Si, sigo cambiando. Cada tanto me acuerdo de algo...

El tema de fecha de vencimientos: Ahora es 2 meses a partir de cuando se aprueba la autorización y no de cuando se emite.

Nombre mas copado de "Analizar Consumos y Prestaciones"

Faltaba el tema de grabar el prestador para donde se realizará la prestación.

1) Reordenacón de atributos de Autorización
2) Saqué los underscores de todos los nombres de atributos para unificar notación. Esto después nos va a facilitar la lectura de clases->tablas y el mapeo.

fecha de vencimiento estaba 2 veces...

Se rehizo. Quiero aclarar que todo lo que comitie hoy lo hizo mazzi.

Bueno teniamos un problema... En ningun lado se guardaba si se aprobaba o no la autorizacion!

Nuevo atributo:

Aprobada: bool

Solo tendrá sentido si fecha_resolucion != null

Se corrige detalle menor.

Se agrega 'Consultar solicitante'. Falta especificar

Cambie el nombre de 2 atributos:
Clase: Autorizaciones

FechaAprobacion por FechaResolucion
descripcion_rechazo por fundamentos_resolucion

Para que ambos atributos sirvan en caso de aprobación/rechazo y no en un solo caso.

* Hay que ponerle titular (que es un afiliado) al solicitante en caso de que
  quiera depender de uno. Representarlo en el diagrama de clases.
* Si el solicitente existe como inactivo y se quiere volver a afiliar, hace
  falta llamar a "consultar estado de cuenta"? o podemos verificar el atributo
  "Afiliado::moroso" directamente?
* Si un ex afiliado, conserva la antigüedad si quiere reafiliarse? (nosotros
  pensamos que no, que es un nuevo afiliado) Esto es por las PK en las tablas.

Saque lo de requisitos minimos (Leasé moroso, etc, etc.) Ahora siempre lo verá un auditor.

Se actualiza con lo hablado en la reunión del 24/04. También se pule bastante
para que deje de ser una mezcla entre DER y DC y empiece a ser un DC de verdad
=) El principal cambio es que se sacan atributos pertenecientes a relaciones.

Actualizado a la reunion dominguera del 24 de abril.

Modifiqué el CU dejando de lado las autorizaciones pendientes y agregué un archivito de decisiones tomadas

- Arregle las especificaciones de acuerdo a lo que me acordaba que dijo el ayudante
- Agregue la clase Hoja de Ruta y atributos al solicitante

Agregué perolata

Paso el diccionario de datos adentro del diagrama. Saque un par de atributos que estaban mal (en general de relaciones entre clases que estaban al revés). Igual falta MUCHO por hacer, puse muchas preguntas...

Bueno, aca esta el hermano del anterior... Este actualiza la autorizacion manual. En realidad es la nueva version del "Revisar autorizaciones manuales", al rtf anterior le di "delete", pero no estoy seguro si lo borro localmente o tambien en el servidor. Asi que si el otro todavia existe, no sirve mas, borrenlo al carajo.

Actualice el cuso agregando el diccionario de datos y le saque la parte de “criterios minimos de aceptación”. Antes funcionaba de manera que si un afiliado no tenia cobertura o era moroso se rechazaba automáticamente antes que lo vea un auditor. Por todo lo que hablamos hasta ahora, asumo que esa decisión le corresponde al grone con corbata.

Peor es nada.

no me gusta mucho como quedo, pero no se me ocurre una manera mejor de escribir lo que quiero decir, espero que se me ocurra y cuando eso suceda lo cambio

Agrego los cu de adrian

Mando los dos reportes q especifiqué y al de clases le agregué el atributo tipo a la prestación (aparentemente hay tipos porque así lo pide el reporte) y al de clases le saqué dos errores de ortografía :P

Desglosé el CU de reportes al director en 2 CU diferentes

Agrego script para generar, a partir del diagrama UML, la especificación de las
clases. Lo que hace es tomar todos los datos de la clase, incluído los
comentarios, así sólo hay que mantener actualizado el diagrama y a partir de
ahí podemos generar la especificación en texto.

actualización del diccio de datos de éste CU

Diagrama actualizado con cardinalidades y relaciones. Saco estado_cuenta de Afiliado porque supongo que vamos a necesitar muchos mas datos que ese para mostrar al Auditor Médico en las autorizaciones manuales.

- Agregue los flujos de datos para emitir_hoja_de_ruta e ingresar_solicitud

Se incluye un borrador de la especificación de los datos involucrados en éste CU. Falta refinarlo.

Voy subiendo lo que tengo porque no doy mas y no se me ocurre nada...
en realidad tengo un par de dudas..
por ahi meti una opcion de "Consulta de prestador" porque alguien lo menciono
en la reunion, y yo como buen esclavo lo anote, pero no se que carajo es una
consulta de prestador.. si alguien sabe que aclare..
tampoco se muy bien como manejar o dividir las consultas, si por cliente, por
solicitante, por planes, por prestaciones.. o como ¿?¿?¿
espero obtener alguna ayuda, si no intentare hacer lo que me parezca mejor.
demasiado comentario para un solo commit!!!

Es cualquiera. Como no definimos bien que mierda hace 'Consultar Estado de Cuenta' (hay que preguntar si puede ser online), quedan varias cosas en el aire

Se agregan los atributos estado (bool) y estado_cuenta(int) en afiliado. Representa si un Afiliado se encuentra activo o no en el sistema (estado) y en caso de adeudar meses, cuantos son (estado_cuenta).

Se agrega la definicion del atributo Afiliado::estado_cuenta

Se agrega la definicion del atributo Afiliado::estado.

 Actualizo el diagrama a lo acordado el lunes

Caso de Uso Actualizar Morosos. No hecho todavia.

- Agregue casos de uso Recuperar Historial y Emitir Hoja de Ruta
- Agregue actor CAP
- Agregue especificaciones de Ingresar Solicitud, Recuperar Historial y Emitir Hoja de Ruta

Se renombra para que sea más fácil de completar con tab XD

Se ponen los diagramas para que entren en una página.

Modificacion mia (dmarcet) de los casos de uso.
Archivo temporal: incorporar las modificaciones a casos_de_uso.dia o no, y eliminarlo.

Se agregan notas del ayudantes nuevas y se cambia el nombre de las viejas que estaba mal la fecha.

 * Saco que se genere el pedido de auth manual como habiamos hablado.

 * Caso de Uso : Pedir Autorizacion automatica

Diccionario de datos del diagrama de clases.

- Se relaciona prestador con zona.
- Se desgloso el domicilio de la persona en calle, numero, dto.
- En cobertura se puso tiempo_de_permanencia en vez de tiempo_de_conveniencia

cambie los nombres de los archivos y les agregue _

subo los casos de uso que estaban en el grupo

Caso de uso Atender Consultas

Sincronizado con el grupo Yahoo.