Se ponen + a los PK y - a los FK.

Cambio Prestacion.codigo a int como en el nomenclador.

Se agregan las claves primarias 'naturales' con un # adelante.

Saco Cobertura.id.

- Se pone la relación entre Autorizacion y Prestacion que faltaba.
- Se corrije Persona.idDireccion como FK.

Cambios en clases y der
- Se elimino Afiliado.activo ya que se puede chequear por fechaBaja == NULL
- Se puso fechaBaja en planes para poder realizar mantenimiento a largo plazo.
  Tambien ¿soluciona? problema de cambio de plan compulsivo
- Cobertura.tiempPermanencia se renombra a Cobertura.carencia.
- Se borra la relacion entre Autorizacion y Cobertura. Estaba por el porcentaje
  de Cobertura pero ahora lo almacenamos.

Bueno, para tener coherencia con la especificación que vamos a presentar hoy, tube que modificar el diagrama.

Verificar cobertura no lo incluye nadie (se hará con un metodo mas adelante en los cuso que corresponda).

A raiz de esto, quedaba colgado en el diagrama, asi que lo saque.
Cualquier cosa lo hablamos despues...

Tambien cambie la relacion de include en Actualizar autorizacion manual... porque consultar afiliado NO existe. Mas adelante vemos como resolvemos esto, pero ahora cierra un poco mejor asi.

Se incluye caso de uso atender consulta.

Se embebe el Telefono en Direccion y se pone la Direccion como una composición.

Elimino este CU que Guillermo incluyó en el CU de los consumos

 pequeño fix

 * actualizo con algunas consultas
   - Consultar Afiliad y se ajustan flechitas (mirar y consultar antes de tocar!!!!!!)
 - Consultar Planes (aca no me gusta como quedan los CUSO que se incluyen)
 - Consultar Promotores (por si alguien llama para verificar si quien esta en
 la puerta es realmente un promotor)

DER preliminar.

- Saco Autorizacion::tipo, para eso tenemos 2 clases distintas.
- Cambio Autorizacion::get_estado() por Autorizacion::getEstado().
- Saco agregación (o sea, se pasa a asociación común) a Prestador-Autorización,
  Cobertura-Autorización, Afiliado-Autorización y Cobertura-Prestación.
- Se cambia "Historia de planes" por HistoriaPlan (estaba mal, porque no
  representaba al conjunto de planes sino a las fechas de alta y baja de un
  plan, el historial de planes sería la colección que tiene el afiliado). Se
  corrijen las cardinalidades que también estaban mal.
- Se corrije cardinalidad de Plan-Afiliado que estaba mal.

Agregue comentarios respecto los atributos "fundamentosResolucion" y observaciones.

La clase "Automatica" Ahora es "AutorizacionAutomatica" para mantener coherencia con la nomenclatura.

Cambie comentarios de atributo fundamentosResolucion y obvesercaciones de Autorizacion y AutorizacionManual resp.

Se le saca el tipo binario para que se puedan hacer merges.

Se convierte a RTF porque se había subido con formato de Word.

Eliminé el CU "Generar Reporte de Consumo" e incluí su funcionalidad en "Recibir y Cotejar Consumos y Prestaciones".
Los motivos son varios:
1) Ningún otro CU lo incluía
2) No representaba un diálogo completo entre actor-sistema, sino que dependía de la finalización de un paso detallado en el CU "Recibir y cotejar..."
3) Molestaba y agregaba mugre en el diagrama de CU sin sentido

Eliminé el CU "Generar Reporte de Consumo" e incluí su funcionalidad en "Recibir y Cotejar Consumos y Prestaciones"

Agregué, en cada uno,una nota explicando cómo interpretar los diagramas

Se modificó un párrafo que decía incorrectamente el momento a partir del cual se establece la fecha de vencimiento de una Autorización.

de todo un poco
un cuso nuevo

en afiliar cliente cambie la precondicion por otra que calza mejor e incluye a la que estaba... en el otro no hice nada, lo hago mañana..

ooootra vez corregi la bosta del estado
ahora digo solamente que se obtiene el estado, no de donde lo saca ni como

- Agregue el campo activo a la clase Plan y actualice en base a eso el CU Mantener planes y el archivo de decisiones

Se completaron las descrpciones faltantes de los atributos de cada clase.

Observaciones solo tiene sentido en Autorizacion Manual, se elimina del padre "Autorizacion". Para motivos de rechazo sigue estando fundamentosResolucion

Se actualizaron las decisiones en cuanto a las Autorizaciones

Saqué un comentario que estaba de más

Actor nuevo: "Solicitador de autorizaciones"

Cambie el actor protagonico.

Saque el tema de observaciones. Para que dejar que alguien ponga motivos de la autorizacion si los va a aprobar una maquina y nadie lo va a leer?

Si fuera necesario poner motivos, deberia pedir una autorizacion manual.

Especifiqué las validaciones que se hacen sobre la info que envía el Prestador

Saco la transición entre "Pendiente" y "Vencida"... Sólo pueden vencer las autorizaciones aprobadas, porque la fecha de vencimiento se setea cuando se aprueba/rechaza una autorización.

adapte todo al diagrama de clases actualizado hace un rato, arregle algunas cosas y detalle otras

hice mas detalles, modifique como sacar el estado de la autorizacion utilizando el metodo de la clase, etc

Detalle en diccionario de datos... faltaba lo de prestador y prestacion

Cambie la fechaResolucion de lugar.
Ahora esta en Autorizacion Manual (hijo de autorizacion) y no esta mas en el padre. Pues en las autorizaciones automaticas esta fecha es identica a fechaSolicitud.

cambie el actor Tiempo por Tiempo (diariamente) al mejor estilo rivadulla

Diagrama de estados de una autorización automática. Al igual que con la manual, con éste diagrama la idea es que queden perfectamente claros los estados, transiciones y eventos que disparan las transiciones de una autorización manual.
También se colocan las notas que explican como se define cada estado a nivel clase.

Se aplican cambios mencionados en el RFC 1 =)
- Afiliado.nroAfiliado pasa a ser Afiliado.codigo
- Zona.codigo pasa a ser Zona.nombre
- Se borra Prestador.codigo
- Se borra Prestacion.codigo
(faltaría actualizar los CU para que usen los nuevos nombres)

- a pedido de Flor(C)

New! Éste CU existía en el diagrama pero aún no estaba especificado.

- Faltaba cambiar el nombre dentro del CU.
- Se pasó la especificación de datos del reporte de consumo al CU "Generar Reporte de Consumo"

actualizada con los campos segun el diagrama de clases vigente, detalle algunas cosas (mientras veo la profesia 3)

- Agregue la especificacion mantener planes
- Agregue tipo de atributo a clase plan
- Saque atributo precio del plan (asumo q igual q para las prestaciones, nosotros no tocamos costos de planes) y agregue categoría

- Elimine el caso de uso Consultar Solicitante porque estaba 2 veces

arreglo palabras mal escritas y pongo un par de acentos

Se agrega relación entre Afiliado y Solicitante, porque el Solicitante podría
decir a la hora de pedir una solicitud que se quiere agregar al Plan familiar
del Afiliado titular X.

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