274

274

Documento relacionado	Descripción
M01 - Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
M01 - Especificación del caso de uso: Armar Cartilla	Especificación del caso de uso Armar Cartilla
M05 – Especificación de la Cartilla Médica	Especificación del archivo cartilla médica a ser enviado al Departamento de Servicios al Cliente
Documento relacionado	Descripción
Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
Caso de Uso: Atender Consultas Afiliado	Especificación del CU que maneja las consultas a responder a un afiliado
Diagrama de secuencia Atender Consultas Afiliado	Diagrama de secuencia para el escenario: consulta cap al que pertenece
Diagrama de secuencia Atender Consultas Afiliado	Diagrama de secuencia para el escenario: consulta ingreso al plan
Diagrama de secuencia Atender Consultas Afiliado	Diagrama de secuencia para el escenario: consulta tipo de autorización de una prestación
Diagrama de secuencia Atender Consultas Afiliado	Diagrama de secuencia para el escenario: consulta prestaciones del plan
Documento relacionado	Descripción
Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
Diagrama de secuencia: Autorización Automática	Especifica evaluarAutorizacionAutomatica
Caso de Uso: Pedir autorización automática, Pedir autorización manual y Actualizar Autorización manual	Casos de uso que usan esta clase.
Diagrama de Paquetes controladores	Da una visión global de las clases que contiene este paquete.
Diagrama de estados: Autorización Automática	Muestra los estados posibles de una autorización automática, y como estarán en cada caso sus respectivos atributos
Diagrama de estados: Autorización Manual	Muestra los estados posibles de una autorización manual, y como estarán en cada caso sus respectivos atributos
Especificación de clase: Autorizacion	Pertenece al paquete dominio.
Especificación de clase: Afiliado	Pertenece al paquete dominio.
Documento relacionado	Descripción
M01 - Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
M01 - Especificación del caso de uso: Enviar información carnets	Especificación del caso de uso Armar Cartilla
M05 - Especificación del listado de datos de carnets	Especificación del listado a ser enviado al Departamento de Servicios al Cliente
Documento relacionado	Descripción
Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y en especial las de control).
Especificación de Interfaz online con el Prestador	Define como serán los retornos de todos los métodos presentados en este documento, explicando además el significado de cada uno.
Especificación de clase: AutorizaciónController	Se utiliza métodos de esta clase, y se instancia.
Diagrama de Paquetes controladores	Da una idea global del paquete al que pertenece esta clase.
Especificación de clase: Afiliado	Pertenece al paquete dominio.
Documento relacionado	Descripción
Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
Diagrama de secuencia: Mantener Planes	Esquematiza el proceso de alta de un nuevo plan, utiliza asiduamente la clase PlanesController.
Caso de Uso: Mantener Planes	ABM de planes, utiliza extensivamente esta clase.
Diagrama de Paquetes controladores	
Documento relacionado	Descripción
Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
Diagrama de secuencia: Autorización Automática	Especifica evaluarAutorizacionAutomatica
Caso de Uso: Pedir autorización automática, Pedir autorización manual y Actualizar Autorización manual	Casos de uso que usan esta clase.
Diagrama de Paquetes controladores	Da una visión global de las clases que contiene este paquete.
Diagrama de estados: Autorización Automática	Muestra los estados posibles de una autorización automática, y como estarán en cada caso sus respectivos atributos
Diagrama de estados: Autorización Manual	Muestra los estados posibles de una autorización manual, y como estarán en cada caso sus respectivos atributos
Especificación de clase: Autorizacion	Pertenece al paquete dominio.
Especificación de clase: Afiliado	Pertenece al paquete dominio.

274

Documento relacionado	Descripción
Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
Caso de Uso: Emitir hoja de Ruta	Especificación del CU Emitir hoja de ruta.
Diagrama de Paquetes controladores	

75.10 TECNICAS DE DISEÑO

TRABAJO PRACTICO

MIKLOLIFE

GRUPO	2

AYUDANTE	Daniel Tomaszevski

CUATRIMESTRE	2005 - 1

INTEGRANTES

Apellido	Nombre	E-mail	Padrón
Castagnino	Florencia	florcastagnino@gmail.com	79504
Dimov	Nicolás	nicodimov@yahoo.com	77624
Lavena	Sebastián	sjlavena@gmail.com	78767
Lucarella	Leandro	luca-7510@llucax.hn.org	77891
Marcet	Diego	dmarcet@fi.uba.ar	78862
Markiewicz	Ricardo	rmarkie@fi.uba.ar	78226
Mazzitelli	Lautaro	lmazzitelli@gmail.com	77020
Pérez	María Florencia	maryflowerp@yahoo.com.ar	79357
Rugilo	Guillermo	guillerugilo@yahoo.com.ar	78439
Sosa	Julián	jsosa@certant.com	81135

Índice de contenido

1. Modelo de clases	1

1.1. Identificación de actores	1

1.1.1. Operador	1

1.1.2. Promotor	1

1.1.3. Enrutador	1

1.1.4. Prestador	1

1.1.5. Cobranzas	1

1.1.6. Pagos	2

1.1.7. Auditor Médico	2

1.1.8. Director	2

1.1.9. Ministerio	2

1.1.10. Administrador	2

1.1.11. Dpto. Servicios Al Cliente	2

1.2. Identificación de casos de uso	2

1.2.1. Funcionalidades	2

1.2.1.1. Paquete Administración	2

1.2.1.2. Paquete Autorizaciones	3

1.2.1.3. Paquete Reportes	3

1.2.1.4. Paquete interacción con promotor	3

1.2.1.5. Paquete interacción con cobranzas	3

1.2.1.6. Paquete interacción con prestadores	3

1.2.1.7. Paquete interacción con clientes	3

1.3. Especificación de casos de uso	4

1.3.1. Actualizar morosos	4

1.3.1.1. Diagrama de secuencia	5

1.3.2. Armar cartilla	6

1.3.3. Ingresar solicitud	6

1.3.4. Agregar Afiliado	7

1.3.5. Mantener promotores	8

1.3.6. Pedir autorización manual	9

1.3.7. Registrar visitas	10

1.3.8. Emitir hoja de ruta	12

1.3.8.1. Diagrama de secuencia	13

1.3.9. Mantener prestadores	14

1.3.10. Recibir y cotejar consumos y prestaciones	15

1.3.10.1. Diagrama de secuencia (parte 1)	20

1.3.10.2. Diagrama de secuencia (parte 2)	21

1.3.11. Pedir autorización automática	22

1.3.11.1. Diagrama de secuencia	24

1.3.12. Atender consulta afiliado	25

1.3.12.1. Diagrama de secuencia (CAP)	27

1.3.12.2. Diagrama de secuencia (fechaIngrsoPlan)	29

1.3.12.3. Diagrama de secuencia (prestacionesPlan)	31

1.3.12.4. Diagrama de secuencia (tipoAutorizacion)	32

1.3.13. Mantener CAPs	34

1.3.14. Actualizar autorización manual	35

1.3.15. Generar reporte autorizaciones rechazadas	36

1.3.16. Generar reporte prestaciones con deuda	37

1.3.17. Generar reporte porcentaje rechazos	37

1.3.18. Mantener planes	38

1.3.18.1. Diagrama de secuencia (parte 1)	41

1.3.18.2. Diagrama de secuencia (parte 2)	42

1.3.19. Mantener prestaciones	43

1.3.19.1. Diagrama de secuencia (alta)	45

1.3.19.2. Diagrama de secuencia (baja)	46

1.3.19.3. Diagrama de secuencia (modificación)	47

1.3.20. Mantener afiliados	48

1.3.21. Eliminar afiliado	48

1.3.22. Modificar afiliado	49

1.3.23. Consultar autorizaciones	50

1.3.24. Enviar información carnets	51

1.3.25. Consultar cobertura online	52

1.3.26. Solicitar autorización automática online	53

1.3.27. Mantener zonas	53

1.4. Especificación de clases	54

1.4.1. Especificación de clases de dominio	54

1.4.1.1. Promotor	54

1.4.1.2. Persona	54

1.4.1.3. Afiliado	55

Método verificarCobertura(codPrestacion: integer):	55

Método obtenerCantidadDePrestacionesRealizadas(codPrestacion: ): int	56

Método consultarPrestacion(codPrestacion: int, cantPrestacionesRealizadas: int): float	57

Método verificarCarencia(codPrestacion: int): float	57

1.4.1.4. Prestacion	58

1.4.1.5. Plan	58

Método borrar(): bool	58

Método obtenerCobertura(codPrestacion: ): Cobertura	58

Método agregarCobertura(cobertura: Cobertura): bool	58

Método obtenerCoberturas(): Cobertura[]	59

1.4.1.6. Prestador	59

1.4.1.7. Cap	59

1.4.1.8. Autorizacion	59

Método getEstado(): enum(Pendiente, Aprobada, Rechazada, Realizada, Vencida)	59

Método getEstado(fechaRecepcion: fecha): enum(Pendiente, Aprobada, Rechazada, Realizada, Vencida)	60

Método setResolucion(fundamentosResolucion: string, porcentajeCobertura: float):	60

Método Autorizacion(fechaSolicitud: fecha):	60

Método obtenerPlazoDeVencimiento(): int	60

1.4.1.9. Zona	60

1.4.1.10. Solicitante	60

1.4.1.11. AutorizacionManual	61

Método AutorizacionManual(fechaSolicitud: fecha):	61

Método getEstado(fechaRecepcion: fecha): enum(Pendiente, Aprobada, Rechazada, Realizada, Vencida)	61

1.4.1.12. AutorizacionAutomatica	61

Método AutorizacionAutomatica(fechaSolicitud: fecha):	61

Método getEstado(fechaRecepcion: fecha): enum(Pendiente, Aprobada, Rechazada, Realizada, Vencida)	61

1.4.1.13. Cobertura	61

1.4.1.14. Categoria	62

1.4.1.15. HistoriaPlan	62

1.4.1.16. Direccion	62

1.4.2. Especificación de clases de control	62

1.4.2.1. AfiliadosSolicitanteController	62

1.4.2.2. AfiliadosMorososController	71

1.4.2.3. ArmarCartillaController	73

1.4.2.4. AtenderConsultasController	75

1.4.2.5. AutorizacionController	78

1.4.2.6. CapsController	83

1.4.2.7. CarnetController	87

1.4.2.8. InterfazPrestadorController	88

1.4.2.9. PlanesController	89

1.4.2.10. PrestacionesController	96

1.4.2.11. PrestadoresController	99

1.4.2.12. PromotoresController	102

1.4.2.13. RecibirPrestacionesController	106

1.4.2.14. RegistrarVisitasController	107

1.4.2.15. ReporteAutorizacionesController	110

1.4.2.16. RutasController	114

1.4.2.17. ZonasController	115

1.4.3. Especificación de clases de reporte	116

1.4.3.1. InfoPrestacionesAdmin	116

1.4.3.2. InfoPrestacionesReport	119

1.4.3.3. LineaInfoPrestacionesReport	120

1.4.3.4. NotificacionesAdmin	120

1.5. Diagrama de casos de uso	123

1.6. Diagramas paquetes	124

1.6.1. Diagrama de arquitectura general del sistema	124

1.6.2. Diagrama de paquete de dominio	125

1.6.3. Diagrama de paquete de control	126

1.6.4. Diagrama de paquete de reportes	127

1.7. Diagramas de clases	128

1.7.1. Diagrama de clases de dominio	128

1.7.2. Diagrama de relación de clases de dominio	129

1.7.3. Diagrama de clases de control	130

1.7.4. Diagrama de clases de persistencia	131

1.7.5. Diagrama de clases de reporte	132

1.8. Diagramas de estado	133

1.8.1. Diagrama de estado de autorización manual	133

1.8.2. Diagrama de estados de autorización automática	134

1.8.3. Diagrama de estado de Solicitante	135

2. Diseño de la base de datos	136

2.1. Diagrama de tablas	136

2.2. Diccionario de datos	137

2.2.1. Composición física de las tablas	137

2.2.2. Diccionario de datos de las tablas	140

2.2.3. Diccionario de datos de los atributos	142

Descripción	142

2.3. Mapeo de clases de entidad	145

Clase.atributo	145

2.4. Reglas de integridad referencial	148

2.5. Análisis del volumen de datos	157

2.5.1. Espacio estimado	158

2.6. Criterios de depuración	159

3. Alcance del Software	162

3.1. Diagrama de alcance	163

4. Funciones complementarias al Software	164

4.1. Importación inicial de datos	164

4.2. Cruzar el reporte de consumo contra el reporte de aprobación/rechazo de prestaciones realizadas	164

4.3. Revisar archivos rechazados del Prestador por formato incorrecto	164

4.4. Armado de hoja de ruta	164

4.5. Entrega al promotor de planes a ofrecer a solicitantes	165

4.6. Entrega de formularios de carga de solicitantes	165

4.7. Confección y reparto de carnets de afiliados	165

4.8. Impresión y reparto de Cartilla médica	165

4.9. Pagos de los afiliados	165

4.10. Verificacion por parte del prestador, de una autorización manual	166

5. Diseño de interfaces	167

5.1. Interfaces con el usuario	167

5.1.1. Introducción	168

5.1.2. Aspectos Generales	168

5.1.3. Alertas	168

5.1.3.1. Objetivos	168

5.1.3.2. Especificacion	168

5.1.3.3. Funcionamiento	169

5.1.3.4. Ejemplos	169

5.1.4. Ventana Principal	170

5.1.4.1. Objetivos	170

5.1.4.2. Especificacion	170

5.1.4.3. Funcionamiento	170

5.1.5. Ventanas de Consulta	170

5.1.5.1. Objetivo	170

5.1.5.2. Especificacion	170

5.1.5.3. Funcionamiento	170

5.1.5.4. Ejemplo	171

5.1.5.5. Diagrama de Transicion de Estados	172

5.1.6. Ventanas ABM	172

5.1.6.1. ABM Básico	172

Objetivo	172

Especificacion	172

Funcionamiento	172

5.1.6.2. ABM Complejos	173

Objetivos	173

Especificacion	173

Funcionamiento	173

Ejemplo 1	174

5.1.6.3. ABM de Relaciones	174

Objetivo	174

Especificacion	174

Funcionamiento	174

Ejemplo	175

5.1.7. Pedido de Autorización Manual	175

5.1.7.1. Objetivos	175

5.1.7.2. Especificacion	175

5.1.7.3. Funcionamiento	175

5.1.7.4. Ejemplo	175

5.1.8. Pantallas de Búsqueda	176

5.1.8.1. Objetivo	176

5.1.8.2. Especificacion	176

5.1.8.3. Funcionamiento	176

5.1.8.4. Ejemplo	176

5.1.9. Mantener Planes	177

5.1.9.1. Objetivos	177

5.1.9.2. Especificacion	177

5.1.9.3. Funcionamiento	177

5.1.10. Actualizar Autorizacion Manual	179

5.1.10.1. Objetivos	179

5.1.10.2. Especificacion	179

5.1.10.3. Funcionamiento	179

5.1.11. Consultar Autorización	181

5.1.11.1. Objetivos	181

5.1.11.2. Especificacion	181

5.1.11.3. Funcionamiento	181

5.1.12. Anexo – HIG Gnome	182

5.1.13. Diseño de listados	184

5.1.13.1. Reporte de autorizaciones rechazadas	184

5.1.13.2. Porcentaje de rechazos	185

5.1.13.3. Hoja de ruta	186

5.1.13.4. Formulario de carga de solicitantes	188

5.1.13.5. Cartilla médica	189

5.1.13.6. Información de carnets	193

5.1.13.7. Actualización de prestaciones	196

5.2. Interfaces con otros sistemas	197

5.2.1. Cobranzas	197

5.2.2. Pagos	200

5.2.3. Prestador	208

5.3. Interfaces con otros sistemas interactivos	213

5.3.1. Prestador	213

6. Modelo de procesamiento	217

6.1. Ciclo del procesamiento	217

6.1.1. Línea de tiempo diaria	217

6.1.2. Línea de tiempo mensual	218

6.1.3. Línea de tiempo anual	218

6.2. Esquema del procesamiento	219

6.2.1. Casa Central	219

6.2.1.1. Área de atención telefónica a afiliados	219

6.2.1.2. Área administrativa	220

6.2.1.3. Área de sistemas	222

6.2.1.4. Área de atención personalizada a afiliados	224

6.2.2. CAP	225

6.2.2.1. Área administrativa	225

6.2.2.2. Área de atención personalizada a afiliados	226

7. Especificación de lanzamiento de tareas	227

8. Diseño y lanzamiento de tareas batch	230

8.1. Tareas	230

8.1.1. Emisión de reporte de autorizaciones rechazadas	230

8.1.1.1. Composición	230

8.1.1.2. Ejecución	230

8.1.1.3. Condiciones previas	230

8.1.1.4. Puntos de control	230

8.1.1.5. Contingencias	230

8.1.2. Emisión de reporte de prestaciones con deuda	231

8.1.2.1. Composición	231

8.1.2.2. Ejecución	231

8.1.2.3. Condiciones previas	231

8.1.2.4. Puntos de control	231

8.1.2.5. Contingencias	232

8.1.3. Emisión de reporte de porcentaje de rechazo de solicitudes	232

8.1.3.1. Composición	232

8.1.3.2. Ejecución	232

8.1.3.3. Condiciones previas	232

8.1.3.4. Puntos de control	233

8.1.3.5. Contingencias	233

8.1.4. Procesar consumos y prestaciones	233

8.1.4.1. Composición	233

8.1.4.2. Ejecución	233

8.1.4.3. Condiciones previas	234

8.1.4.4. Puntos de control	234

8.1.4.5. Contingencias	234

8.1.5. Actualizar estado de morosidad de afiliados	234

8.1.5.1. Composición	234

8.1.5.2. Ejecución	234

8.1.5.3. Condiciones previas	235

8.1.5.4. Puntos de control	235

8.1.5.5. Contingencias	235

8.1.6. Enviar información carnets	235

8.1.6.1. Composición	235

8.1.6.2. Ejecución	235

8.1.6.3. Condiciones previas	235

8.1.6.4. Puntos de control	236

8.1.6.5. Contingencias	236

8.1.7. Depuración	236

8.1.7.1. Composición	236

8.1.7.2. Ejecución	236

8.1.7.3. Condiciones previas	236

8.1.7.4. Puntos de control	236

8.1.7.5. Contingencias	236

8.1.8. Backup de Base de Datos	236

8.1.8.1. Composición	236

8.1.8.2. Ejecución	237

8.1.8.3. Condiciones previas	237

8.1.8.4. Puntos de control	237

8.1.8.5. Contingencias	237

8.2. Nota sobre el control de contingencias de tareas	237

8.2.1. Especificación de archivos auxiliares:	238

8.2.1.1. Archivos XML:	238

8.2.1.2. Archivo INI:	239

8.2.1.3. Archivos de log:	239

9. Diseño de la arquitectura de procesamiento	240

9.1. Arquitectura física	240

9.2. Modalidad de procesamiento	240

9.3. Diseño funcional	240

10. Especificación de tecnología	241

10.1. Hardware Requerido	241

10.2. Software Requerido	242

10.3. Estaciones de Trabajo	242

10.4. Servidores	242

10.4.1. Servidor stand-alone primario	243

10.4.2. Servidor stand-alone secundario	243

10.4.3. Cluster DB	243

10.4.4. Cluster Directorio	243

11. Modelo de instalación de componentes	244

11.1. Mapa de instalación	244

11.2. Configuración de entorno	244

11.2.1. Estación de trabajo consultas	244

11.2.2. Estación de trabajo recepción	244

11.2.3. Estación de trabajo administración	244

11.2.4. Estación de trabajo director	244

11.2.5. Estación de trabajo técnico	244

11.3. Webserver	244

11.4. Dataserver	244

11.5. Servidor de red	244

12. Diseño conceptual del menú	245

12.1. Estructura elegida	245

12.2. Forma de agrupamiento	245

12.3. Opciones del menú	245

13. Diseño conceptual de seguridad	246

13.1. Introducción – Conceptos Básicos	246

13.2. Infraestructura Física	246

13.3. Infraestructura Lógica	247

13.3.1. Infraestructura de usuarios, y grupos y perfil en base a roles	247

13.3.2. Vínculo hacia la aplicación – Propagación de perfiles según roles	249

13.3.3. Ambiente interno	250

13.3.4. Ambiente externo	251

13.3.5. Conclusión	251

13.4. Enlace	251

13.6. Seguridad frente a accesos externos e internos	252

13.7. Backups	253

13.8. Auditoría	254

13.8.1. Servers y software de base	254

13.8.2. Aplicación	254

13.9. Seguridad dentro de la aplicación	254

13.10. Detección de intrusiones	254

13.11. Glosario de términos para los estandares utilzados	255

13.12. Anexo - Detalle de la terminología LDAP	257

14. Diseño de la implementación del menú y seguridad de acceso	259

15. Anexos	260

15.1. Estándares de diseño de interfaces	260

15.2. Informe de evolución del diseño	260

15.3. Planificación de la exposición	260

Modelo de clases

Identificación de actores

Tomando como herramienta de especificación a los “casos de uso”, comenzamos la confección de dicho modelo por la identificación de los actores y sus objetivos frente al sistema. Para el caso de nuestro sistema, los actores son:

Operador

Es el intermediario entre los afiliados y el sistema.

Se encarga de:

atender consultas por parte de los afiliados respecto a la obra social;

ingresar en el sistema datos de solicitantes que quieran afiliarse;

recibir solicitudes personales de autorizaciones manuales y darlas de alta en el sistema;

atender consultas por parte de los afiliados respecto a las prestaciones que realizaron y autorizaciones emitidas a los mismos;

dar de alta afiliados al sistema a partir de los datos de los solicitantes y la interacción con el caso de uso correspondiente;

Promotor

Es el encargado de entrevistar a posibles afiliados de la obra social. Recibe una hoja de ruta con los solicitantes a visitar, un listado que permite la carga de los datos de los afiliados (ref. modelo 5: listado de carga de solicitantes). Registra en el sistema las visitas que pudo o no realizar y los solicitantes que serán afiliados al sistema por parte del operador así como también los datos de los familiares a afiliar.

Enrutador

Es el encargado de confeccionar una hoja de ruta con solicitantes que debe visitar un Promotor en base a los datos brindados por el sistema.

Prestador

Es el actor al cual la obra social debe retribuirle monetariamente por las prestaciones realizadas a los afiliados de la obra social. Puede ser una organización o un profesional particular. Envía un listado con las prestaciones realizadas a los afiliados del sistema.También puede solicitar una autorización automática online y/o consultar coberturas de los afiliados de la misma forma.

Cobranzas

Este actor informa a la obra social que afiliados son morosos y cuantos meses adeudan.

Pagos

Es el área de la Obra Social encargada de pagarle el porcentaje de la prestación cubierto del afiliado al prestador. Recibe un reporte detallado de lo que tiene que abonar.

Auditor Médico

Es un profesional (médico) que se encarga de evaluar la autorización de las autorizaciones manuales que son pedidas a la obra social por parte de los prestadores y/o afiliados.

Director

Drector de la obra social. Se le envían reportes periódicamente.

Ministerio

Ministerio de Salud. Se le envían reportes periódicamente.

Administrador

Es el encargado de:

mantener planes, prestadores, caps, promotores, prestaciones y afiliados. Con mantener nos referimos a alta, baja y modificación de los mismos, excepto en el caso de los afiliados donde solo puede modificar los datos del mismo o darlo de baja en el sistema.

Realizar el armado de la cartilla de un plan del sistema a partir del caso de uso correspondiente

Dpto. Servicios Al Cliente

Departamento encargado de la impresión y el envío tanto de carnets como de cartillas médicas a los afiliados.

Identificación de casos de uso

Funcionalidades

Paquete Administración

Mantener Afiliados: maneja el ABM de los afiliados en el sistema;

Modificar Afiliado: maneja la modificación de datos de un afiliado en el sistema;

Eliminar Afiliado: maneja la baja de un afiliado en el sistema;

Mantener Planes: maneja el ABM de los planes del sistema;

Mantener Prestaciones: maneja el ABM de las prestaciones en el sistema;

Mantener Promotores: maneja el ABM de los promotores en el sistema;

Mantener CAPS: maneja el ABM de los caps en el sistema;

Mantener Prestadores: maneja el ABM de los prestadores en el sistema;

Armar cartilla: de acuerdo al plan ingresado se arma un listado con la descripción del mismo y la cobertura correspondiente a cada prestación que abarca;

Mantener Zonas: maneja el ABM de zonas en el sistema;

Paquete Autorizaciones

Actualizar autorización manual: se actualiza el estado de la autorización manual estableciendo su aprobación o rechazo;

Solicitar Autorización automática online: se carga en el sistema una autorización automática de manera online (webservice);

Pedir Autorización automática: se carga en el sistema una autorización automática de forma manual (a través de un operador);

Pedir Autorización manual: se carga en el sistema una autorización manual;

Consultar autorizaciones: permite consultar la cantidad y tipo de autorizaciones que tiene un cierto afiliado;

Consultar cobertura online: verifica que un afiliado tenga una cobertura determinada y obtiene sus características (tipo, porcentaje, etc);

Paquete Reportes

Generar Reporte Autorizaciones Rechazadas: se genera un reporte con el detalle de las autorizaciones rechazadas en el período;

Generar Reporte Porcentaje Rechazos: se genera un reporte con el porcentaje y detalle de autorizaciones rechazadas en el período;

Generar Reporte Prestaciones con Deuda: se genera un reporte de afiliados que tomaron prestaciones estando morosos;

Paquete interacción con promotor

Emitir hoja de ruta: a través de los solicitantes pendientes de visita se confecciona el listado para el promotor

Registrar visitas: se cargan en el sistema los afiliados a incorporar, los solicitantes no visitados y/o se eliminan los solicitantes que no serán afiliados;

Paquete interacción con cobranzas

Actualizar morosos: se actualiza en el sistema el estado de los afiliados, si el afiliado tiene una deuda quedará registrado;

Paquete interacción con prestadores

Recibir y cotejar consumos y prestaciones: se recibe de un prestador el listado de las prestaciones que los afiliados se realizaron, se genera un reporte que se envía a pagos según las prestaciones recibidas aprobadas y/o rechazadas por el sistema, también se genera un reporte señalando el consumo de los afiliados;

Paquete interacción con clientes

Atender consultas afiliado: se atienden consultas realizadas por los afiliados/solicitantes a través del operador;

Ingresar solicitud: se ingresan en el sistema los datos de los clientes que desean afiliarse a la obra social;

Agregar afiliado: da de alta un nuevo afiliado en el sistema (a partir de un solicitante).

Especificación de casos de uso

Actualizar morosos

Documento relacionado	Descripción
M01 - Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
M05 - Especificación de Interfaces con el sector Cobranzas	Especificación de la interfaz con el sector Cobranzas
M01 -Especificación de clase: AfiliadosMorososController	Especificación de la clase AfiliadosMorososController y sus métodos.
M01 - Diagrama de Secuencia Actualizar Morosos	Diagrama de secuencia del escenario principal del CU

Caso de uso: Actualizar Morosos	
Actores: Cobranzas
Descripción: registra en el sistema las modificaciones recibidas desde cobranzas
Precondiciones: Cobranzas tiene acceso y permisos suficientes para subir archivos al sitio FTP publicado por la Obra Social, a fines de establecer la comunicación entre los sistemas. Asimismo, el Sistema tiene acceso a éste sitio y a los archivos que contiene.
Postcondiciones: Quedan actualizados los estados de cuenta de los afiliados.
Flujo Principal: Cobranzas envía información de morosidad de los afiliados (deposita un archivo en un directorio del sitio FTP destinado). El Sistema, periódicamente obtiene dicha información, moviéndola temporalmente a un “directorio de procesamiento” (local a la máquina en que se ejecuta el Sistema), en el que se mantiene hasta que finalice el proceso Se ejecuta AfiliadosMorososController.cargarDatos(), si devuelve false (E1). Fin del caso de uso.
SubFlujos: No hay
Flujos de Excepción: E1 - El archivo no es correcto. Fin de caso de uso.

Diagrama de secuencia

Armar cartilla

Documento relacionado	Descripción
M01 - Especificación de clase: ArmarCartillaController	Especificación de la clase ArmarCartillaController y sus métodos.
M01 - Diagramas de Clases	Diagramas de clases de dominio, de control y de persistencia.
M05 - Especificación de la Cartilla Médica	Especificación del archivo cartilla médica a ser enviado al Departamento de Servicios al Cliente

Caso de uso: ArmarCartilla	
Actores: Administrador
Actores secundarios: Dpto. Servicios al Cliente
Descripción: este CU es el encargado de confeccionar la cartilla médica correspondiente a un plan.
Precondiciones: ninguna
Postcondiciones: la cartilla fue confeccionada.
Flujo Principal: El sistema despliega una lista de los planes vigentes obtenida mediante la llamada a ArmarCartillaController.obtenerPlanesVigentes() El administrador selecciona el plan del cual desea confeccionar la cartilla. Mediante ArmarCartillaController.cargarCartillaPlan(codPlan) queda confeccionada la cartilla médica para el plan seleccionado y es enviada por eMail al Dpto. Servicios al Cliente.
Flujos Alternativos: No hay
Flujos de Excepción: No hay

Ingresar solicitud

Documento relacionado	Descripción
Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
Diagrama Entidad Relación	Esquema de relaciones en la base de datos.
Especificación de clase: AfiliadoSolicitanteController	Especificación de la clase AfiliadoSolicitanteController y sus métodos.

Caso de uso: Ingresar Solicitud	
Actores:Operador
Precondiciones:No tiene
Descripción:El operador obtiene datos de un solicitante (por teléfono, fax, internet, etc.) necesarios para que un promotor le sea asignado para una futura visita.
Postcondiciones: Queda cargado el solicitante en el sistema
Flujo Principal: El operador obtiene los datos mínimos indispensables de un solicitante para su posterior carga, de las planillas generadas manualmente con la recopilación de las llamadas telefónicas, formularios web, fax, etc. Para la planilla seleccionada se obtiene el tipo y número de documento y se verifica que en usuario no esté actualmente cargado como solicitante, esto se realiza invocando al método AfiliadoSolicitanteController.existeSolicitante(tipoDoc, nroDoc) Si era solicitante -> E1 Se ingresan los datos del solicitante para que quede pendiente su visita por algún promotor. Se invoca al método AfiliadoSolicitanteController.agregarSolicitante(tipoDoc,nroDoc,nombre,apellido,eMail,fechaNacimiento,calle,numero,piso,departamento,codigoPostal,provincia,idZona,telefono, sexo,disponibilidad, cantidadfamiliares, observaciones), siendo idZona el identificador de la zona en la que reside el solicitante, elegida por el operador de una lista de zonas cargadas previamente en el sistema (previa llamada a AfiliadoSolicitanteController.obtenerZonas()). Fin flujo principal.
Flujos de Excepción: E1 El solicitante ya estaba en la lista de solicitantes. No se carga nuevamente.
Nota: Los datos requeridos del solicitante son los siguientes: Tipo de documento ( obligatorio ) Número de documento ( obligatorio ) Nombre (obligatorio) Apellido (obligatorio) Dirección ( obligatorio ) Email Sexo Fecha de Nacimiento Teléfono Código Postal Provincia

Agregar Afiliado

Documento relacionado	Descripción
M01 - Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación de clase: AfiliadoSolicitanteController	Especificación de la clase AfiliadoSolicitanteController y sus métodos.

Caso de uso: Agregar Afiliado	
Actores: Operador
Precondiciones: Se ejecutó el caso de uso Registrar Visitas.
Descripción: El operador obtiene la lista de los solicitantes que han sido visitados por un promotor y están en condiciones de afiliarse a la obra social, luego realiza la afiliacion mediante el sistema, registrando los datos correspondientes y asociando el plan elegido en caso de que sea titular o asignando un titular en caso de que no lo sea.
Postcondiciones: El solicitante queda ingresado en el sistema como Afiliado y tiene un plan asociado.
Flujo Principal: El operador selecciona un solicitante de la lista de solicitantes que están en condiciones de afiliarse. AfiliadoSolicitanteController.obtenerSolicitantesAfiliar(); Con el tipo y número de documento (tipoDoc, nroDoc) del solicitante, se verifica que la persona no sea actualmente un afiliado AfiliadoSolicitanteController.existeAfiliado(tipoDoc, nroDoc). Si devuelve true -> S1, si ya existía -> E1 Se despliega una lista con el grupo familiar del solicitante, disponible para afiliar. AfiliadoSolicitanteController.obtenerFamiliares(tipoDoc, nroDoc). Por cada familiar del solicitante se ejecuta AfiliadoSolicitanteController.afiliarFamiliar(tipoDoc, nroDoc). Fin de caso de uso.
Flujos Alternativos: S1: Se despliega una lista de los planes disponibles y se selecciona uno para asociarle al nuevo afiliado. Se ejecuta AfiliadoSolicitanteController.afiliarTitular( tipoDoc, nroDoc, codPlan) Continúa el flujo principal.
Flujos de excepción: E1: Si el solicitante existía en la base y no puede ser afiliado nuevamente se lo elimina como solicitante en el sistema mediante la llamada a AfiliadoSolicitanteController.eliminarSolicitante( tipoDoc,nroDoc). Si el solicitante existía en la base y puede ser reactivado se llama a AfiliadoSolicitanteController.reactivarAfiliado(tipoDoc,nroDoc) Finaliza el caso de uso.

Mantener promotores

Documento relacionado	Descripción
M01 - Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación de clase: PromotoresController	Especificación de la clase PromotoresController y sus métodos.

Caso de uso: Mantener_Promotores	
Descripción: Administra el alta, modificación y/o baja de los promotores del sistema.
Actores: Administrador
Precondiciones: El administrador se encuentra logueado al sistema.
Postcondiciones: Quedará actualizada la información de los promotores.
Flujo Principal: El sistema muestra al administrador el menú correspondiente a la opción Mantener promotores. El administrador selecciona una de las siguientes opciones: Alta promotor -> S1 Modificación promotor -> S2 Eliminación promotor -> S3 Salir -> Fin de caso de uso
Flujos Alternativos: S1. Alta de promotor El sistema solicita al administrador el ingreso de los datos del promotor tipoDoc y nroDoc. El sistema verifica la existencia previa del promotor mediante la llamada a PromotoresController.existePromotor(tipoDoc,nroDoc), si devuelve true -> (E1) El sistema solicita al administrador el ingreso de los siguientes datos como campos de texto: nombre, apellido, fechaNacimiento, eMail, calle, numero, piso, departamento, codigoPostal, provincia, telefono, sexo y un listado de zonas para que seleccione cual le pertenece obtenido mediante la llamada a PromotoresController.obtenerZonas(). Cuando el administrador confirma el ingreso de los datos se llama a PromotoresController.agregarPromotor(tipoDoc,nroDoc,nombre,apellido, fechaNacimiento,eMail,calle,numero,piso,departamento,codigoPostal,provincia, telefono, sexo, idZona). Vuelve a 2 del flujo principal. S2. Modificación de promotor El sistema solicita al administrador el ingreso de los datos del promotor tipoDoc y nroDoc. El sistema verifica la existencia previa del promotor mediante la llamada a PromotoresController.existePromotor(tipoDoc,nroDoc), si devuelve false -> (E2) Mediante la llamada a PromotoresController.obtener(tipoDoc,nroDoc) se obtienen y muestran en pantalla los datos del promotor. Se permite la modificación de eMail, calle, numero, piso, departamento, codigoPostal, provincia, telefono y la zona Cuando el administrador confirma el ingreso de los datos se llama a PromotoresController.modificarPromotor(tipoDoc,nroDoc, eMail, calle, numero, piso, departamento, codigoPostal, provincia, telefono, idZona). Vuelve a 2 del flujo principal. S3. Eliminación de promotor El sistema solicita al administrador el ingreso de los datos del promotor tipoDoc y nroDoc. El sistema verifica la existencia previa del promotor mediante la llamada a PromotoresController.existePromotor(tipoDoc,nroDoc), si devuelve false -> (E2) El sistema pide confirmación. Una vez confirmada la eliminación se llama a PromotoresController.eliminarPromotor(tipoDoc,nroDoc). Vuelve a 2 del flujo principal.
Flujos de Excepción: E1 El promotor ya existe en el sistema. Vuelve a 2 del flujo principal. E2 El promotor no existe en el sistema. Vuelve a 2 del flujo principal.

Pedir autorización manual

Documento relacionado	Descripción
Diagramas de clases de todos los paquetes.	En especial, del paquete Controladores, y Dominio.
Diagrama de estados: Autorización Manual	Diagrama de los estados, transiciones y eventos relevantes relacionados con una autorización manual.
Especificación de clase: AutorizacionController	Especificación de la clase AutorizacionController y sus métodos.

Caso de uso: Pedir autorización manual	Orden:06
Actores: Operador
Precondiciones: El operador se encuentra logueado al sistema.
Postcondiciones: La autorización queda registrada en el sistema con estado pendiente.
Flujo Principal: El operador solicita ingresar una autorización manual, eligiendo la opción correspondiente en el sistema. El sistema presenta una pantalla pidiendo código de afiliado, de prestación y el CUIT de prestador y observaciones; El operador completa todos los datos. Se muestra una pantalla informando si el afiliado es moroso, y si su plan tiene cobertura para la prestación que solicita, como así también si supera el límite de prestaciones anuales en esta prestación, o no cumple con alguna carencia. AutorizacionController.consultarAfiliado(codAdiliado,codPrestacion) Si no existe algún código-> E1 El operador confirma la operación. Si no acepta se termina el caso de uso. El sistema almacena los datos registrando la autorización manual a partir del código de afiliado, de prestación, de prestador y observaciones AutorizacionController.GuardarAutotorizacionManual(codPrestación,cuitPrestador, codAfiliado,observaciones) Fin del caso de uso.
Flujos Alternativos: No hay
Flujos de Excepción: E1El sistema muestra error y vuelve a 2;
Notas: El pedido solo puede ser por operador. Si un prestador desea elevar un pedido deberá hacerlo por medio de un operador. Si el código solicitado corresponde a una prestación que corresponde autorización automática o bién no esta cubierta, el operador decidirá que hacer (se permite esta operatoria para contemplar casos excepcionales. Ej: Legislación que pueda afectar,ordenes judiciales, cualquier otro que se considere pertinente a tal efecto).

Registrar visitas

Documento relacionado	Descripción
Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
Diagrama Entidad Relación	Esquema de relaciones en la base de datos.
Especificación de clase: RegistrarVisitasController	Especificación de la clase RegistrarVisitasController y sus métodos.

Caso de Uso:Registrar Visitas	
Actores: Promotor
Descripción: El promotor regresa de visitar a los solicitantes, según la hoja de ruta que le fue asignada, y realiza la carga de los datos de cada uno en el sistema, para que éstos estén disponibles para afiliar o descartar según corresponda.
Precondiciones: Se ejecutó el caso de uso Emitir hoja de Ruta, el promotor se encuentra logueado en el sistema
Postcondiciones: Los solicitantes quedan ingresados en el sistema para que la afiliación sea posible, vuelven a ser marcados para visitar o son descartados.
Flujo principal: Se muestra en pantalla una lista con los solicitantes asignados al promotor mediante la llamada a RegistrarVisitasController.obtenerSolicitantesAsignados(tipoDoc,nroDoc) El promotor selecciona un solicitante y se muestran las siguientes opciones: Establecer como pendiente -> S1 Afiliar -> S2 Eliminar solicitante -> S3 Salir -> Fin de caso de uso
Flujos alternativos S1 : Se establece como pendiente el afiliado mediante la llamada a RegistrarVisitasController.establecerPendiente(tipoDocSolicitante, nroDocSolicitante) Vuelve al punto 1 del flujo principal. S2 : Se marca al solicitante como visitado RegistrarVisitasController.visitado(tipoDocSolicitante, nroDocSolicitante) Se verifica si el nuevo afiliado pertenece a un grupo familiar mediante la llamada a RegistrarVisitasController.obtenerCantidadFamiliares(tipoDocSolicitante,nroDocSolicitante) Si la cantidad de familiares es cero, va al punto 6. Se muestra una pantalla con los datos necesarios para registrar al familiar del titular en el sistema, el promotor completa los datos y se almacenan mediante la llamada a RegistrarVisitasController.cargarFamiliar(tipoDocTitular,nroDocTitular,tipoDocFamiliar,nroDocFamiliar,nombreFamiliar,ApellidoFamiliar,eMailFamiliar,fechaNacimientoFamiliar,sexoFamiliar,calleFamiliar,numeroFamiliar,pisoFamiliar,dptoFamiliar,codigoPostalFamiliar,provinciaFamiliar, telefonoFamiliar) Mientras haya familiares del titular vuelve a mostrarse la pantalla de carga de los mismos. Vuelve al punto 1 del flujo principal. S3 : Se elimina el solicitante a través de la llamada a RegistrarVisitasController.eliminarSolicitante( tipoDocSolicitante, nroDocSolicitante ) Vuelve al punto 1 del flujo principal.

Emitir hoja de ruta

Documento relacionado	Descripción
Especificación de clase: RutasController	Especificación de la clase RutasController y sus métodos.
Diagramas de Clases	Diagramas de clases de dominio, de control y de persistencia.
Diagrama de Secuencia de Emitir Hoja de Ruta	Diagrama de secuencia que representa el escenario principal del CU
Modelo 5 : Listado Hoja de Ruta	Especificación del Listado Hoja de Ruta
Modelo 5 : Listado Carga Familiares	Especificación del Listado Carga Familiares

Caso de uso: Emitir Hoja de Ruta	
Descripción: caso de uso a partir del cual el enrutador obtiene toda la información para asignar promotores a solicitantes pendientes de visita, y para entregar a los promotores un listado con los planes a ofrecer a cada solicitante.
Actores: Enrutador
Precondiciones: Ninguna.
Postcondiciones: El Enrutador confecciona la hoja de ruta y envía una copia al Promotor.
Flujo Principal: El sistema recupera el listado de los promotores a partir de la llamada a RutasController.obtenerPromotores() y lo muestra al Enrutador; El enrutador selecciona el promotor para el cual confeccionará la hoja de ruta; El sistema recupera las solicitudes pendientes de proceso a través de la llamada a RutasController.obtenerSolicitantesPendientes() y se muestran al Enrutador; El Enrutador asocia al promotor un solicitante de acuerdo a las ubicaciones relativas y agrega el solicitante a la Hoja de Ruta del promotor. Al confirmar la asociación entre el promotor y el solicitante se llama a RutasController.asociarPromotor(solicitante.tipoDoc,solicitante.nroDoc,promotor.codigo). El sistema envía por mail la hoja de ruta confeccionada al promotor.
Flujos de Excepción: No hay.

Diagrama de secuencia

Mantener prestadores

Documento relacionado	Descripción
M01 - Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación de clase: PrestadoresController	Especificación de la clase PrestadoresController y sus métodos.

Caso de uso: Mantener_Prestadores	
Descripción: Administra el alta, modificación y/o baja de los prestadores del sistema.
Actores: Administrador
Precondiciones: El administrador se encuentra logueado al sistema.
Postcondiciones: Quedará actualizada la información de los prestadores.
Flujo Principal: El sistema muestra al administrador el menú correspondiente a la opción Mantener prestadores. El administrador selecciona una de las siguientes opciones: Alta prestador -> S1 Modificación prestador -> S2 Eliminación prestador -> S3 Salir -> Fin de caso de uso
Flujos Alternativos: S1. Alta de prestador El sistema solicita al administrador el ingreso del CUIT del prestador. El sistema verifica la existencia previa del prestador mediante la llamada a PrestadoresController.existePrestador(CUIT), si devuelve true -> (E1) El sistema solicita al administrador el ingreso de los siguientes datos como campos de texto: nombre, eMail, calle, numero, piso, departamento, codigoPostal, provincia, telefono y un listado de zonas para que seleccione cual le pertenece obtenido mediante la llamada a PrestadoresController.obtenerZonas(). Cuando el administrador confirma el ingreso de los datos se llama a PrestadoresController.agregarPrestador(CUIT,nombre, eMail, calle, numero, piso, departamento, codigoPostal, provincia, telefono, idZona). Vuelve a 2 del flujo principal. S2. Modificación de prestador El sistema solicita al administrador el ingreso del CUIT del prestador CUIT. El sistema verifica la existencia previa del prestador mediante la llamada a PrestadoresController.existePrestador(CUIT), si devuelve false -> (E2) Mediante la llamada a PrestadoresController.obtener(CUIT) se obtienen y muestran en pantalla los datos del prestador. Se permite la modificación de eMail, calle, numero, piso, departamento, codigoPostal, provincia, telefono y la zona Cuando el administrador confirma el ingreso de los datos se llama a PrestadoresController.modificarPrestador(CUIT, eMail, calle, numero, piso, departamento, codigoPostal, provincia, telefono, idZona). Vuelve a 2 del flujo principal. S3. Eliminación de prestador El sistema solicita al administrador el ingreso del CUIT del prestador. El sistema verifica la existencia previa del prestador mediante la llamada a PrestadoresController.existePrestador(CUIT), si devuelve false -> (E2) El sistema pide confirmación. Una vez confirmada la eliminación se llama a PrestadoresController.eliminarPrestador(CUIT). Vuelve a 2 del flujo principal.
Flujos de Excepción: E1 El prestador ya existe en el sistema. Vuelve a 2 del flujo principal. E2 El prestador no existe en el sistema. Vuelve a 2 del flujo principal.

Recibir y cotejar consumos y prestaciones

Ref	Documento relacionado	Descripción
R1	Especificación de Interfaces con el Prestador	Describe la interfaz a través de la cual se comunica el Sistema con el Prestador.
R2	Especificación de Interfaces con el sector Pagos	Describe la interfaz a través de la cual se comunica el Sistema con el sector de Pagos de la Obra Social.
R3	Diagrama de secuencia: Recibir y Cotejar Consumos y Prestaciones – Parte 1	Diagrama de secuencia del escenario principal del CU.
R4	Diagrama de secuencia: Recibir y Cotejar Consumos y Prestaciones – Parte 2	Diagrama de secuencia de las validaciones aplicadas a la información recibida desde el Prestador.
R5	Diagrama de estados: Autorización Manual	Diagrama de los estados, transiciones y eventos relevantes relacionados con una autorización manual.
R6	Diagrama de estados: Autorización Automática	Diagrama de los estados, transiciones y eventos relevantes relacionados con una autorización automática.
R7	Especificación de clase: RecibirPrestacionesController	Especificación de la clase RecibirPrestacionesController y sus métodos.

Caso de uso: Recibir y Cotejar Consumos y Prestaciones	
Descripción: Representa la interacción entre el Prestador y el Sistema, al momento que el Prestador envía la informacion de prestaciones realizadas, el Sistema las procesa y emite los reportes de Consumo y de Aprobaciones/Rechazos de Prestaciones Realizadas.
Actores: Prestador, Pagos.
Precondiciones: El Prestador tiene acceso y permisos suficientes para subir archivos al sitio FTP publicado por la Obra Social, a fines de establecer la comunicación entre los sistemas. Asimismo, el Sistema tiene acceso a éste sitio y a los archivos que contiene. (Ver R1 para detalles acerca del formato de los archivos recibidos.) El Sistema posee acceso y permisos suficientes para subir archivos al sitio FTP publicado por Pagos. (ver R2)
Poscondiciones: Autorizaciones efectuadas por los afiliados afectados actualizada. Área de Pagos notificada acerca de las aprobaciones/rechazos de la info enviada por el prestador acerca de prestaciones realizadas. Área de Pagos dispone de los reportes de consumo de los afiliados. Prestadores informados acerca del resultado del procesamiento de la informción enviada.
Flujo Principal: Los Prestadores envían información de prestaciones e intervenciones de los afiliados (depositan, cada uno, un archivo en un directorio del sitio FTP destinado). Ver R1. El Sistema, periódicamente (ver R1), obtiene dicha información, recorriendo todos los directorios destinados a los Prestadores del sitio FTP. (S1) [ RecibirPrestacionesController.procesarInfoRecibida() ] Por cada archivo encontrado, se lo mueve temporalmente a un “directorio de procesamiento” (local a la máquina en que se ejecuta el Sistema), en el que se mantiene hasta que finalice el proceso. Por cada archivo de Prestador recibido: El Sistema verifica el formato de la información recibida, aplicando el esquema predeterminado mediante librerías externas al Sistema (ver R1). Si el formato NO es válido à E1 El Sistema valida cada línea de la información recibida. Validaciones sobre la info. recibida: A nivel global del archivo se verifica: El Prestador existe en el Sistema. Si no existe à E1 Por cada línea de la info. recibida se verifica: El Prestador NO está dado de baja en la fecha de realización recibida. El afiliado existe en el Sistema. El afiliado NO está dado de baja en la fecha de realización recibida. La prestación existe en el Sistema y NO está dada de baja en la fecha de realización enviada por el Prestador. La autorización existe en el Sistema. La autorización está relacionada con el Prestador, en los datos del Sistema. La autorización está relacionada con la prestación descripta por el Prestador, en los datos del Sistema La autorización está relacionada con el afiliado en los datos del Sistema La autorización no está realizada (en los datos del Sistema) al momento del proceso de la línea. La autorización está aprobada en la fecha de realización de la información de prestaciones e intervenciones enviada por el Prestador. Esto implica que en dicha fecha no estaba ni vencida ni en ningún otro estado. (Ver R5 y R6: diagramas de estado de las autorizaciones) El tipo de autorización coincide, para el código de autorización recibido, con el tipo de autorización en los datos del Sistema. Porcentaje de cobertura es igual al que se aplicaba al momento de la aprobación de la autorización. Si la línea pasa la validación, se registra en el sistema la prestación realizada por el afiliado. Sino, la línea se pasa a una lista de “líneas rechazadas” (no se registra nada en el Sistema) El Sistema, en base a los datos del archivo y el resultado de la validación, agrega los datos correspondientes referidos al procesamiento de éste archivo al informe de aprobaciones/rechazos de prestaciones realizadas. El Sistema, en base a los datos del archivo e información disponible en el propio Sistema, agrega los datos correspondientes relacionados al procesamiento de éste archivo al reporte de consumo de los afiliados (se incluyen sólo las prestaciones realizadas que hayan sido aprobadas). El Sistema mueve el archivo del directorio temporal de procesamiento y lo ubica en un directorio de “documentos aceptados” (del sitio FTP publicado por la Obra Social) del Prestador en cuestión. El Sistema envía la confirmación del proceso exitoso del archivo al Prestador, mediante una notificación vía email, especificando el nombre del archivo. Se sigue con el procesamiento del siguiente archivo en 4, hasta que no haya más archivos en el FTP para procesar. El Sistema envía el informe de aprobaciones/rechazos de prestaciones realizadas al sector Pagos. (ver R2) El Sistema envía el reporte de consumo de los afiliados al sector Pagos. (ver R2) Finaliza el caso de uso.
Flujos Alternativos: S1: Alguno de los directorios está vacío (el Prestador no envió ningún archivo ese día) El Sistema envía una notificación vía email al Prestador, indicando que en esa fecha no se recibió nada. (Ver R1) El Sistema envía una notificación vía email al sector Pagos de la Obra Social, indicando que para dicho Prestador en la fecha de proceso no se recibieron archivos (Ver R2) Se prosigue recorriendo los directorios en 3
Flujos de Excepción: E1 Se mueve el archivo a un directorio (del sitio FTP publicado por la Obra Social) de documentos rechazados. Se envía un mail al Prestador avisando que hay archivos rechazados en el FTP, informando el directorio y nombre del archivo para que pueda revisarlo. El Sistema envía una notificación vía email al sector Pagos de la Obra Social, indicando que hay un nuevo archivo rechazado en el directorio FTP de rechazados(Ver R2) Se prosigue con el siguiente archivo en 4. De no haber más archivos, se sigue en 5
Notas: - La comunicación Prestador-Sistema es “asincrónica”: el Prestador deja un archivo en un sitio FTP y luego el sistema lo procesa con un método que se ejecuta periódicamente: RecibirPrestacionesController.procesarInfoRecibida(). Ver el documento “Especificación de Interfaces con el Prestador”(R1) para detalles de formato, medio y periodicidad de la comunicación.

Especificación de Datos:

Información de prestaciones e intervenciones

Cabecera:

Número de CUIT del Prestador.

Fecha en que el Prestador envía ésta información.

Detalle (cada línea):

Código de autorización relacionada a la prestación.

Tipo de autorización (Manual/Automatica) relacionada a la prestación.

Código de prestación.

Fecha de Realización de la prestación

Porcentaje de cobertura a cubrir por la Obra Social.

Código de afiliado.

Informe de aprobaciones/rechazos de prestaciones realizadas

Cabecera:

Fecha de generación de éste informe

Detalle (cada línea):

Número de CUIT del Prestador

Nombre del Prestador

Código de autorización relacionada a la prestación, enviado por el Prestador.

Tipo de autorización (Manual/Automática)

Código de prestación enviado por el Prestador.

Código de afiliado enviado por el Prestador

% cobertura reclamado por el prestador

% cobertura correspondiente al momento de aprobar la autorización (si la autorización existe en el sistema)

Fecha de aprobación de la autorización (si la autorización existe en el Sistema)

Fecha de vencimiento de la autorización (si la autorización existe en el Sistema)

Fecha de realización de la autorización, enviada por el Prestador.

Fecha de recepción de la Información de prestaciones e intervenciones enviada por el prestador, en la cual venía la autorización especificada en c).

Identificador de línea Aprobada/Rechazada.

Motivo del rechazo de la línea (ej: “Autorización recibida inexistente”, “Autorización Vencida”, “% cobertura recibido inválido”, “Autorización recibida no relacionada con el afiliado”, “Autorización recibida no relacionada con la prestación”)

Reporte de consumo de los afiliados

Cabecera:

Fecha de generación de éste reporte

Detalle (cada línea):

Código de afiliado

Nombre y apellido del afiliado

Código del plan del afiliado

Por cada afiliado:

Número de CUIT del Prestador donde se realizó la prestación

Nombre Prestador donde se realizó la prestación

Código de autorización asociado a la prestación realizada.

Código de prestación REALIZADA

Nombre de la prestación realizada

Fecha de Realización de la prestación

% Cobertura

Diagrama de secuencia (parte 1)

Diagrama de secuencia (parte 2)

Pedir autorización automática

Documento relacionado	Descripción
Diagrama de secuencia: Pedir autorización automática	Diagrama de secuencia del escenario principal del CU.
Diagrama de estados: Autorización Automática	Diagrama de los estados, transiciones y eventos relevantes relacionados con una autorización automática.
Especificación de clase: AutorizacionController	Especificación de la clase AutorizacionController y sus métodos.

Caso de uso: Pedir autorización automática	
Actores: Solicitador de autorizaciones
Precondiciones: El cliente se encuentra afiliado.
Postcondiciones: El pedido de autorización queda registrado.
Flujo Principal: El solicitador solicita registrar una autorización automática. El sistema pide el código de afiliado, el código de prestación que se desea autorizar, y el CUIT del prestador. El solicitador completa los datos. El sistema verifica si la prestación puede ser aprobada (teniendo en cuenta el estado de cuenta, antigüedad, plan, cobertura, carencias y el límite de la respectiva prestación anual) Y se registra los datos proporcionados con el pedido de autorización automática con el estado correspondiente (aprobada ò rechazada + motivos), junto con la fecha y hora de la operación y se establece la fecha de vencimiento como n(*) días a partir de la fecha actual. Si hay error en los códigos pasados à E1 AutorizacionController.evaluarAutorizacionAutomatica(cuitPrestador, codPrestacion, codAfiliado); Se muestra resultado de la operación, de ser aprobada se informa porcentaje de cobertura y el código de autorización. AutorizacionController.CurrentAutorizacion.Codigo AutorizacionController.CurrentAutorizacion.Porcentaje Fin de caso de uso.
Flujos Alternativos: No hay
Flujos de Excepción: E1 Si el numero de afiliado ó el código de prestación no existe, se pide que lo reingrese volviendo a 2.
Notas: (*) n será en principio 60 (días). Pero es variable, se obtendrá de Dominio.Autorizacion.obtenerPlazoDeVencimiento()

Diagrama de secuencia

Atender consulta afiliado

Documento relacionado	Descripción
Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
Especificación de clase: AtenderConsultasController	Especificación de la clase AtenderConsultasController y sus métodos.
Diagrama de secuencia Atender Consultas Afiliado	Diagrama de secuencia para el escenario: consulta fecha de ingreso al plan
Diagrama de secuencia Atender Consultas Afiliado	Diagrama de secuencia para el escenario: consulta cap al que pertenece
Diagrama de secuencia Atender Consultas Afiliado	Diagrama de secuencia para el escenario: consulta tipo de autorización de una prestación
Diagrama de secuencia Atender Consultas Afiliado	Diagrama de secuencia para el escenario: consulta prestaciones del plan

Caso de uso: Atender Consultas Afiliado	
Descripción: Administra la atención de consultas por parte de un afiliado
Actores: Operador
Precondiciones: El operador se encuentra logueado al sistema.
Postcondiciones: Ninguna
Flujo Principal: El sistema muestra al administrador el menú correspondiente a las consultas que puede realizar sobre un afiliado, para lo cual pide el ingreso de tipo y número de documento del afiliado; El operador ingresa el tipo y número de documento del afiliado; El sistema verifica la existencia del afiliado en el sistema mediante la llamada a AtenderConsultasController.existeAfiliado(tipoDoc,nroDoc), si devuelve false -> (E1) El administrador selecciona una de las siguientes opciones: Morosidad del afiliado -> S1 Permanencia en el plan -> S2 CAP al que pertenece -> S3 Prestadores por zona para una prestación-> S4 Tipo de autorización de prestación -> S5 Porcentaje de cobertura de una prestación -> S6 Prestaciones del plan -> S7 Salir -> Fin de caso de uso
Flujos Alternativos: S1. Morosidad del afiliado Mediante la llamada a AtenderConsultasController.cuotasAdeudadas(tipoDoc,nroDoc) se devuelve al operador la cantidad de cuotas que adeuda el afiliado. Vuelve a 1 del flujo principal. S2. Permanencia en el plan Mediante la llamada a AtenderConsultasController.permanenciaEnPlan(tipoDoc,nroDoc) se devuelve al operador la fecha de alta del afiliado en el plan vigente. Vuelve a 1 del flujo principal S3. CAP al que pertenece Mediante la llamada a AtenderConsultasController.obtenerCAPAfiliado(tipoDoc,nroDoc) se devuelve al operador la información correspondiente al CAP al cual pertenece el afiliado Vuelve a 1 del flujo principal S4. Prestadores por zona para una prestación Se muestra al operador las prestaciones correspondientes al plan del afiliado mediante la llamada a AtenderConsultasController.obtenerPrestacionesPlan(tipoDoc,nroDoc) El operador selecciona la prestación para la cual quiere saber el/los prestadores por zona Mediante la llamada a AtenderConsultasController.obtenerPrestadoresZona(tipoDoc,nroDoc,codigoPrestacion) se devuelve al operador la información de los prestadores correspondientes a la zona a la cual pertenece el afiliado Vuelve a 1 del flujo S5. Tipo de autorización de una prestación Se muestra al operador las prestaciones correspondientes al plan del afiliado mediante la llamada a AtenderConsultasController.obtenerPrestacionesPlan(tipoDoc,nroDoc) El operador selecciona la prestación para la cual quiere saber el tipo de autorización requerida El sistema devuelve el tipo de autorización mediante la llamada a AtenderConsultasController.obtenerTipoAutorizacion(tipoDoc,nroDoc,codigoPrestacion) Vuelve a 1 del flujo S6. Porcentaje de cobertura de una prestación Se muestra al operador las prestaciones correspondientes al plan del afiliado mediante la llamada a AtenderConsultasController.obtenerPrestacionesPlan(tipoDoc,nroDoc) El operador selecciona la prestación para la cual quiere saber el porcentaje de cobertura requerido El sistema devuelve el tipo de autorización mediante la llamada a AtenderConsultasController.obtenerPorcentajeCobertura(tipoDoc,nroDoc,codigoPrestacion) Vuelve a 1 del flujo S7. Prestaciones del plan Se muestra al operador las prestaciones correspondientes al plan del afiliado mediante la llamada a AtenderConsultasController.obtenerPrestacionesPlan(tipoDoc,nroDoc) Vuelve a 1 del flujo
Flujos de Excepción: E1 El sistema informa al operador que el afiliado no existe en el sistema. Vuelve a 1 del flujo principal.

Diagrama de secuencia (CAP)

Diagrama de secuencia (fechaIngrsoPlan)

Diagrama de secuencia (prestacionesPlan)

Diagrama de secuencia (tipoAutorizacion)

Mantener CAPs

Documento relacionado	Descripción
M01 - Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación de clase: CAPSController	Especificación de la clase CAPSController y sus métodos.

Caso de uso: Mantener_CAPS	
Descripción: Administra el alta, modificación y/o baja de los caps del sistema.
Actores: Administrador
Precondiciones: El administrador se encuentra logueado al sistema.
Postcondiciones: Quedará actualizada la información de los caps.
Flujo Principal: El sistema muestra al administrador el menú correspondiente a la opción Mantener caps. El administrador selecciona una de las siguientes opciones: Alta cap -> S1 Modificación cap -> S2 Eliminación cap -> S3 Salir -> Fin de caso de uso
Flujos Alternativos: S1. Alta de cap El sistema solicita al administrador el ingreso de los datos del cap tipoDoc y nroDoc. El sistema verifica la existencia previa del cap mediante la llamada a CAPSController.existeCAP(codigo), si devuelve true -> (E1) El sistema solicita al administrador el ingreso de los siguientes datos como campos de texto: codigo, horario, calle, numero, piso, departamento, codigoPostal, provincia, telefono y un listado de zonas para que seleccione cual le pertenece obtenido mediante la llamada a CAPSController.obtenerZonas(). Cuando el administrador confirma el ingreso de los datos se llama a CAPSController.agregarCAP(codigo,horario, calle, numero, piso, departamento, codigoPostal, provincia, telefono, idZona). El sistema muestra un listado de zonas mediante la llamada a CAPSController.obtenerZonas() dando la posibilidad al administrador de seleccionar las zonas a asociar con el cap. Una vez seleccionadas las zonas se llama a CAPSController.asociarCAPconZona(idCap,idZona[]) para realizar la asociación. Vuelve a 2 del flujo principal. S2. Modificación de cap El sistema solicita al administrador el ingreso del código de CAP. El sistema verifica la existencia previa del cap mediante la llamada a CAPSController.existeCAP(codigo), si devuelve false -> (E2) Mediante la llamada a CAPSController.obtener(codigo) se obtienen y muestran en pantalla los datos del cap. Se permite la modificación de horario, calle, numero, piso, departamento, codigoPostal, provincia, telefono y zona Cuando el administrador confirma el ingreso de los datos se llama a CAPSController.modificarCAP(codigo,horario, calle, numero, piso, departamento, codigoPostal, provincia, telefono, idZona). El sistema muestra un listado de zonas mediante la llamada a CAPSController.obtenerZonas() dando la posibilidad al administrador de seleccionar las zonas que a asociar con el cap, marca las ya asociadas al CAP mediante la llamada a CAPSController.obtenerZonasAsociadas(idCAP) Una vez seleccionadas las zonas se llama a CAPSController.asociarCAPconZona(idCap,idZona[]) para realizar la asociación. Vuelve a 2 del flujo principal. S3. Eliminación de cap El sistema solicita al administrador el ingreso del código de CAP. El sistema verifica la existencia previa del cap mediante la llamada a CAPSController.existeCAP(codigo), si devuelve false -> (E2) El sistema pide confirmación. Una vez confirmada la eliminación se llama a CAPSController.eliminarCAP(codigo). Vuelve a 2 del flujo principal.
Flujos de Excepción: E1 El cap ya existe en el sistema. Vuelve a 2 del flujo principal. E2 El cap no existe en el sistema. Vuelve a 2 del flujo principal.

Actualizar autorización manual

Documento relacionado	Descripción
Diagrama de estados: Autorización Manual	Diagrama de los estados, transiciones y eventos relevantes relacionados con una autorización automática.
Especificación de clase: Autorizacion	Especificación de la clase Autorizacion y sus métodos, de paquete Dominio.
Especificación de clase: AutorizacionController	Especificación de la clase AutorizacionController y sus métodos, de paquete Controlador.

Caso de uso: Actualizar autorización manual	
Actores: Auditor médico
Precondiciones: El auditor médico se encuentra logeado al sistema.
Poscondiciones: Se registra la decisión de aceptar ó se rechazar la autorización
Flujo Principal: El sistema muestra un listado de autorizaciones manuales pendientes ordenado según la antigüedad del pedido. AutorizacionController.ObtenerAutorizacionesPendientes() El auditor médico elige una autorización manual revisar. Se muestra una pantalla informando si el afiliado es moroso, y si su plan tiene cobertura para la prestación que solicita, como así también si supera el límite de prestaciones anuales en esta prestación y si cumple con las carencias pactadas. AutorizacionController.consultarAfiliado(codAdiliado,codPrestacion) El auditor médico aprueba/rechaza el pedido (S1) Se registra la decisión del auditor médico, y la fecha actual, la fecha de vencimiento como n* días a partir de la fecha actual y el número de legajo del auditor que se encuentra logeado. AutorizaciónController.SetResolucionAutorizacionManual(Autorizacion, motivo, aprobada [true/false]) Fin del caso de uso.
Flujos Alternativos: S1 Si el auditor médico opta por no decidir, se termina el cuso.
Flujos de Excepción:
Diccionario de Datos: autorización manual: Autorización.Código, fechaResolución, fechaVencimiento, Afiliado.código, fundamentosResolucion, prestación solicitada
Notas: *n será en principio 60 (días). Pero es definido en un archivo de configuracion (ver especificacion de clase: Autorizacion) , se obtendrá de Dominio.Autorizacion.obtenerPlazoDeVencimiento()

Generar reporte autorizaciones rechazadas

Documento relacionado	Descripción
Especificación de la Clase “ReporteAutorizacionesController”	Descripción detallada de la clase ReporteAutorizacionesController
M05 – Especificación Reporte autorizaciones rechazadas	Especificación del reporte
M08- Lanzamiento de tareas batch	Tiempos y formas de lanzamiento de tareas batch

Caso de uso: Generar Reporte Autorizaciones Rechazadas	
Actores: Tiempo (Diariamente)
Actores secundarios: Director
Precondiciones:
Descripción: Se genera y envía el reporte de las autorizaciones rechazadas para enviar al Director de la OS
Postcondiciones: El reporte queda guardado y es enviado al Director.
Flujo Principal: Se genera el reporte mediante la llamada al método: ReporteAutorizacionesController.generarReporteAutorizacionesRechazadas() Finaliza el caso de uso.
SubFlujos: No hay

Generar reporte prestaciones con deuda

Documento relacionado	Descripción
Especificación de la Clase “ReporteAutorizacionesController”	Descripción detallada de la clase ReporteAutorizacionesController
M05 – Especificación Reporte autorizaciones rechazadas	Especificación del reporte
M08- Lanzamiento de tareas batch	Tiempos y formas de lanzamiento de tareas batch

Caso de uso: Generar Reporte Prestaciones con Deuda	
Actores: Tiempo (mensualmente)
Actores secundarios: director
Precondiciones:
Descripción: Se genera un reporte de todas las personas que han tomado prestaciones estando inhabilitados para hacerlo.
Postcondiciones: El reporte es almacenado y enviado al Director.
Flujo Principal: Se genera el reporte con la llamada al método: ReporteAutorizacionesController.generarPrestacionesConDeuda( ) Finaliza el caso de uso.

Generar reporte porcentaje rechazos

Documento relacionado	Descripción
Especificación de la Clase “ReporteAutorizacionesController”	Descripción detallada de la clase ReporteAutorizacionesController

Caso de uso: Generar Reporte Porcentaje Rechazos	
Actores: Tiempo (anualmente)
Actores secundarios: Ministerio
Precondiciones:
Descripción: Se genera el reporte anual de los porcentajes de rechazo de las solicitudes (manuales o automáticas) de sus afiliados discriminados por tipo de prestación y motivo de rechazo.
Postcondiciones: El reporte es almacenado y enviado al Ministerio.
Flujo Principal: Se genera el reporte con la llamada al método: ReporteAutorizacionesController.generarPorcentajeRechazos( ) Finaliza el caso de uso.

Mantener planes

Documento relacionado	Descripción
Diagrama de secuencia: Mantener Planes	Diagrama de secuencia del escenario principal del CU.
Especificación de clase: PlanesController	Especificación de la clase PlanesController y sus métodos.
Diagramas de Clases	Diagramas de clases de dominio, de control y de persistencia.

Caso de uso: Mantener Planes	
Descripción: Suministra al administrador las funciones requeridas para la Alta, Baja y/o Modificación de los planes.
Actores: Administrador.
Precondiciones: Ninguna.
Postcondiciones: Quedará actualizada la información del plan.
Flujo Principal: Se crea una nueva instancia de PlanesController que se utilizará todo a lo largo del C.U. El sistema muestra al administrador el menú correspondiente a la opción Mantener Planes. El administrador selecciona una de las siguientes opciones: Alta de Plan Baja de Plan Modificación de Plan Salir Si la opción seleccionada es Alta de Plan (S1). Si se selecciona Baja de Plan (S2). Si la opción seleccionada es Modificación de Plan (S3). Si elige Salir, fin de Caso de Uso.
Flujos Alternativos: S1. Alta de Plan S1.1 El sistema solicita que el administrador ingrese Plan.descripción, Plan.categoría y Plan.permanenciaMínima del nuevo plan. S1.2 El administrador ingresa los datos solicitados por el sistema. S1.3 Se invoca a Plan.crearPlan(Plan.descripción, Plan.categoría, Plan.permanenciaMínima). Si hay algún error en el proceso, se toma la excepción (excPlan) y de acuerdo a ella se ejecuta E1: excCatInval, E2: excPermMinInval o E3: excCatExiste. Caso contrario, se almacena en memoria el codPlan (resultado del método) del nuevo plan. S1.4 El sistema pide a la clase controladora, que tome como current al nuevo plan (PlanesController.makeCurrent(codPlan)) S1.4 El sistema obtiene la lista de planes existentes (tanto activos como inactivos): mediante los métodos PlanesController.obtenerPlanesVigentes() y PlanesController.obtenerPlanesInactivos(), con estos Planes despliega la lista en pantalla brindando la posibilidad de seleccionar los planes desde los cuales se desea importar coberturas de forma de facilitar su carga. S1.5 El administrador selecciona el/los plan/es a importar. S1.6 Se invoca al método PlanesController.importarCoberturas(Plan.codigo) para cada plan seleccionado por el administrador, si se atrapa una excepción de tipo excImpCob (E4). S1.7 Se despliega en pantalla las Prestaciones existentes mediante el método PrestacionesController.obtenerPrestaciones() con la posibilidad de filtrarlas por categoría y de hacer búsquedas por nombre. Al seleccionar una prestación, esta se agregará a la lista (también desplegada en pantalla) en la que cada ítem tendrá los siguientes campos: Prestación.codigo y Prestación.nombre. carencia. porcentaje. limiteAnual. tipoAutorización. Eliminar la cobertura de la prestación del plan. S1.8 El administrador selecciona las prestaciones que desea incluir cargando los campos antes especificados. S1.9 Se invoca a PlanesController.agregarCobertura(Prestacion.codigo, carencia, porcentaje, limiteAnual, tipoAutorización). Si hay algún error en el proceso, se toma la excepción (excCob) y se la procesa de acuerdo al siguiente esquema: Si excCarencInval: E5. Si excPorcentInval: E6. Si excLimAnInval: E7. Si excCobExist: E8. S1.10 Vuelve a 1. S2. Baja de Plan S2.1 El sistema despliega los Planes vigentes mediante PlanesController.obtenerPlanesVigentes(). S2.2 El administrador selecciona que plan desea dar de baja. S2.3 Se hace current el plan seleccionado: PlanesController.makeCurrent(codPlan). S2.4 Se registra la baja invocando PlanesController.desactivarPlan() y vuelve a 1. S3. Modificación de Plan S3.1 El sistema despliega los planes vigentes mediante PlanesController.obtenerPlanesVigentes(). S3.2 El administrador selecciona el plan que desea modificar (Plan). S3.3 Se hace current el plan seleccionado (PlanesController.makeCurrent(Plan.codigo)) y se muestran sus datos permitiendo su edición y la importación de coberturas desde otros planes ya existentes: se utiliza la misma pantalla que en S1.4 solo que al estar en modo edición se deben además obtener los datos existentes para el plan, esto se realiza mediante PlanesController.obtenerCoberturas(). S3.4 El administrador edita los datos del Plan y las Coberturas, y acepta las modificaciones. S3.5 El sistema registra las modificaciones ejecutando PlanesController.importarCoberturas(Plan.codigo) para cada plan seleccionado por el administrador, si se atrapa una excepción de tipo excImpCob (E4); PlanesController.actualizarCobertura(Prestacion.codigo, carencia, porcentaje, limiteAnual, tipoAutorización) para las Coberturas existentes que hayan sido modificadas y PlanesController.agregarCobertura(Prestacion.codigo, carencia, porcentaje, limiteAnual, tipoAutorización) para las coberturas nuevas, y en caso de haberse modificado alguno de los datos del plan, se registra mediante PlanesController.actualizarPlan(descripción,categoría,permanenciaMinima). En caso de error, se toma la excepción (excPlan, excCob y excCobExist) y se la procesa de la forma siguiente: Si excCatInval: E1. Si excPermMinInval: E2. Si excCatExiste: E3. Si excCarencInval: E5. Si excPorcentInval: E6. Si excLimAnInval: E7. Si excCobExist: E8. S3.6 Vuelve a 1.
Flujos de Excepción: E1 El sistema informa que Plan.categoría debe ser un número decimal mayor o igual que cero, vuelve a S1.2 o S3.5 según corresponda. E2 El sistema informa que Plan.permanenciaMínima debe ser un número decimal mayor o igual a cero meses, vuelve a S1.2 o S3.5 según corresponda. E3 El sistema informa que ya existe un plan con Plan.categoría igual a la ingresada, vuelve a S1.2 o S3.5 según corresponda. E4 El sistema informa que existen dos o más coberturas para la misma prestación desplegando la información de cada una iterando sobre excImpCob.codPlan[],haciendo current el plan (PlanController.makeCurrent(excImpCob.codPlan[i]) y luego PlanesController.obtenerCobertura(codPrestacion) y permitiendo la selección de a lo sumo una de ellas. Esto brinda la posibilidad al administrador de elegir que cobertura utilizar para la prestación. Si selecciona Aceptar, vuelve a S1.6, si Cancelar S1.5 E5 El sistema informa que la carencia es un número entero mayor o igual a cero. Vuelve manteniendo los datos válidos ya cargados a S1.4 o S3.5 según corresponda. E6 Se informa que el porcentaje debe ser un número decimal entre 0 y 100. Vuelve manteniendo los datos válidos ya cargados a S1.4 o S3.5 según corresponda. E7 Se informa que el límiteAnual debe ser un número entero mayor o igual a cero. Vuelve manteniendo los datos válidos ya cargados a S1.4 o S3.5 según corresponda. E8 El sistema informa que ya existe una cobertura para la prestación dentro del plan. Vuelve a S1.4 o S3.5 según corresponda.
Diccionario de datos: plan_codigo: valor perteneciente a la colección devuelta por PlanesController.obtenerPlanesVigentes() o PlanesController.obtenerPlanesInactivos() excPlan: enum {excCatExiste, excCatInval, excPermMinInval} excCob: enum {excCarencInval, excPorcentInval, excLimAnInval} excCobExist: codPrestacion. excImpCob: codPlan[] + codPrestacion. codPlan: entero que representa el código del plan. codPrestacion: entero que representa el código de la prestación. Planes: colección de instancias de Plan. Plan: instancia de Plan. Prestaciones: instancia de Prestacion. Coberturas: instancia de Cobertura. carencia: float que representa la carencia de la cobertura (al crearse la instancia de Cobertura es Cobertura.carencia). porcentaje: float que representa el porcentaje de cobertura sobre la prestación (al crearse la instancia de Cobertura es Cobertura.porcentaje). limiteAnual: entero que representa el límite anual de prestaciones que tienen cobertura (al crearse la instancia de Cobertura es Cobertura.limiteAnual). tipoAutorización: enumerado {manual,auto} (al crearse la instancia de Cobertura es Cobertura.tipoAutorizacion). datos del plan: Plan.descripcion, Plan.categoria, Plan.permanenciaMinima.

Diagrama de secuencia (parte 1)

Diagrama de secuencia (parte 2)

Mantener prestaciones

Documento relacionado	Descripción
M01 - Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación de clase: PrestacionesController	Especificación de la clase RecibirPrestacionesController y sus métodos.
M05 – Especificación del archivo de prestaciones	Especificación del archivo

Caso de uso: Mantener_Prestaciones	
Descripción: Administra el alta, modificación y/o baja de las prestaciones del sistema.
Actores: Administrador
Precondiciones: El administrador se encuentra logueado al sistema.
Postcondiciones: Quedará actualizada la información de las prestaciones.
Flujo Principal: El sistema muestra al administrador el menú correspondiente a la opción Mantener prestaciones. El administrador selecciona una de las siguientes opciones: Actualización prestaciones Salir Si la opción seleccionada es Actualización (S1). Si elige Salir, fin del caso de uso.
Flujos Alternativos: S1. Actualización de Prestaciones 1. El sistema solicita al administrador el path del archivo recibido que contiene las prestaciones actualizadas. 2. El administrador ingresa los datos solicitados por el sistema. 3. Con el path ingresado, se ejecuta PrestacionesController.cargarDatosArchivo(path_archivo), si devuelve false (E1). 4. Vuelve a 1.
Flujos de Excepción: E1 El sistema informa que el path ingresado no es válido o bien que el nomenclador no tiene la estructura requerida y vuelve a 1.

Diagrama de secuencia (alta)

Diagrama de secuencia (baja)

Diagrama de secuencia (modificación)

Mantener afiliados

Documento relacionado	Descripción
Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.

Caso de uso: Mantener_Afiliados	
Actores: Operador, Administrador
Descripción: se encarga de la modificación y/o eliminación de afiliados en el sistema.
Precondiciones: El operador o el administrador se encuentran logueados en el sistema
Postcondiciones: Quedará actualizada la información del afiliado
Flujo Principal: El sistema muestra al operador el menú correspondiente a la opción Mantener afiliados. El operador selecciona una de las siguientes opciones: 2. Baja de afiliado 3. Modificación de afiliado 4. Salir Si la opción seleccionada es 2, el sistema muestra al actor el menú correspondiente a la opción baja de afiliado, en donde el operador tendrá que ingresar el tipo y número de documento del afiliado a dar de baja. Se ejecuta el caso de uso Eliminar_Afiliado. Si la opción seleccionada es 3, el sistema muestra al actor el menú correspondiente a la opción modificación de datos, en donde el operador tendrá que ingresar el tipo y número de documento del afiliado cuyos datos se quieren modificar. Se ejecuta el caso de uso Modificar_afiliado. Si la opción seleccionada es 4 -> fin de caso de uso.
Flujos Alternativos: No hay
Flujos de Excepción: No hay

Eliminar afiliado

Documento relacionado	Descripción
Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
Especificación de clase: AfiliadoSolicitanteController	Especificación de la clase AfiliadoSolicitanteController y sus métodos.

Caso de uso: Eliminar_Afiliado	
Descripción: maneja la baja lógica de un afiliado en el sistema (marca de borrado)
Precondiciones: El afiliado está dado de alta en el sistema
Postcondiciones: el afiliado es dado de baja del sistema.
Flujo Principal: El sistema verifica que el número de afiliado existe mediante la llamada AfiliadoSolicitanteController.existeAfiliado(tipoDoc, nroDoc) si no existe el afiliado (el método retorna false) -> (E1) Se verifica si el afiliado es titular de grupo familar. Se ejecuta AfiliadoSolicitanteController.esTitular(tipoDoc, nroDoc). Si el afiliado a eliminar no tiene grupo familiar asociado(en la llamada anterior se obtuvo false), ir a 6. En caso de que el afiliado a eliminar sea titular de un grupo familiar, el sistema despliega en pantalla una lista con los datos (código de afiliado, nombre, apellido, tipo y número de documento) de los integrantes de dicho grupo. Permite además seleccionar al nuevo titular (utilizando un checkbox para marcar a lo sumo un integrante de la lista). Para ello se ejecuta AfiliadoSolicitanteController.obtenerFamiliaresAfiliados(tipoDoc,nroDoc) Si se seleccionó un nuevo titular, con su tipo y número de documento se ejecuta AfiliadoSolicitanteController.modificarTitular(tipoDoc, nroDoc, tipoDocNuevo, nroDocNuevo). En caso contrario (no se selecciona nuevo titular, sino que se elimina al grupo familiar) se ejecuta AfiliadoSolicitanteController.eliminarGrupoFamiliar(tipoDoc, nroDoc) Se ejecuta AfiliadoSolicitanteController.eliminarAfiliado(tipoDoc,nroDoc). Si alguno de estos métodos devuelve false -> (E2) Fin de caso de uso.
Flujos de Excepción: E1 – El afiliado no existe en el sistema. Se vuelve al punto 1. E2 – Error cuando se intentó eliminar al afiliado. Se vuelve a 1.

Modificar afiliado

Documento relacionado	Descripción
Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
Especificación de clase: AfiliadoSolicitanteController	Especificación de la clase AfiliadoSolicitanteController y sus métodos.

Caso de uso: Modificar Afiliado	
Descripción: maneja la modificación de los datos de un afiliado en el sistema
Precondiciones: El afiliado está dado de alta en el sistema
Postcondiciones: los datos del afiliado fueron modificados
Flujo Principal: Se valida la existencia del afiliado en la obra social mediante la llamada a AfiliadoSolicitanteController.existeAfiliado(tipoDoc,nroDoc) si devuelve false -> (E1) Se obtienen los datos del afiliado mediante la llamada a AfiliadoSolicitanteController.obtenerDetalleAfiliado(tipoDoc,nroDoc) y se muestran en pantalla con todos los datos bloqueados, y las tres opciones siguientes: modificar datos, agregar beneficiario (familiar o demás dentro de la cobertura) salir. Si la opción seleccionada es salir, ir al punto 8. Si la opción es agregar beneficiario se llama a Agregar Afiliado y luego ir al punto 9. Si selecciona la opción modificación de datos, se habilitan todos los campos que pueden ser modificados (telefono, dirección, codigo_postal, provincia, zona, e-mail, plan) y la opción para guardar las modificaciones. En caso de modificarse la zona, ésta será elegida de una lista de zonas ingresadas previamente al sistema (obtenida mediante la llamada a AfiliadoSolicitanteController.obtenerZonas()). El operador modifica los campos, y pide al sistema que procese los mismos. Se llama a AfiliadoSolicitanteController.modificarAfiliado(tipoDoc,nroDoc,telefono,calle, numero,piso,departamento,codigoPostal, provincia, idZona, eMail,codPlan) Fin de caso de uso.
Flujos Alternativos: No hay
Flujos de Excepción: E1 – El numero de afiliado ingresado no corresponde a un afiliado dentro de la obra social. Se vuelve al punto 1.

Consultar autorizaciones

Documento relacionado	Descripción
Diagramas de clases de todos los paquetes.	En especial, del paquete Controladores, y Dominio.
Diagrama de estados: Autorización Automática	Diagrama de los estados, transiciones y eventos relevantes relacionados con una autorización automática.
Diagrama de estados: Autorización Manual	Diagrama de los estados, transiciones y eventos relevantes relacionados con una autorización manual.
Especificación de clase: AutorizacionController	Especificación de la clase AutorizacionController y sus métodos.

Caso de uso: Consultar autorizaciones	
Actores: Operador
Precondiciones: El operador se encuentra logueado al sistema.
Postcondiciones: Ninguna
Flujo Principal: El sistema muestra una pantalla solicitando un criterio para listar autorizaciones, podrá ser por: código de afiliado, número de legajo del auditor que aprobo/rechazo las autorizaciones (listará solo manuales), código de autorización, ó fechas de solicitud. Campos que se mostrarán: código de autorización, código de afiliado, si es manual o automática, estado de la autorización, fecha de solicitud, fecha de resolución (de haber), fecha de vencimiento, fecha de resolución (si es manual), los fundamentos de la resolución, y de existir observaciones en caso de una manual, también. La ventana mostrará el primer elemento, permitiendo desplazarse a otros registros mediante una barra de navegación. Si el operador elige el criterio de código de afiliado -> S1 AutorizacionController.obtenerAutorizacionesPorAfiliado(codAfiliado) Si el operador elige el criterio del nro de legajo del auditor -> S2 AutorizacionController.obtenerAutorizacionesPorAuditor(nroLegajo) Si el operador elige el criterio del intervalo de fechas -> S3 AutorizacionController.obtenerAutorizacionesPorFechas(fechaInicio,fechaFin) Si el operador elige el criterio del código de autorización > S4 AutorizacionController.obtenerAutorizacion(codAutorizacion) Fin del caso de uso.
Flujos Alternativos: S1. Se muestra una lista de todos las autorizaciones que se le hicieron al afiliado solicitado. Si el código no existe -> E1 Si existe, S5 S2. Se muestra una lista de todos las autorizaciones que resolvió el auditor solicitado. Si el código no existe -> E1 Si existe, S5 S3. Se muestra una lista de todos las autorizaciones que se solicitaron en ese período. Si el código no existe -> E1 Si existe, S5 S4. 1. Se muestra los datos de la autorización solicitada. Si el código no existe -> E1, si existe -> S5.2 S5. 1. El operador puede elegir ordenar por alguno de los campos mencionados en 1. 2. El operador puede elegir hacer otra búsqueda (vuelve a 1), o bien cerrar la consulta. 3. Fin del caso de uso
Flujos de Excepción: E1. El sistema muestra error y vuelve a 1;

Enviar información carnets

Documento relacionado	Descripción
M01 - Especificación de clase: CarnetsController	Especificación de la clase CarnetsController y sus métodos.
M01 - Diagramas de Clases	Diagramas de clases de dominio, de control y de persistencia.
M05 - Especificación del listado de datos de carnets	Especificación del listado a ser enviado al Departamento de Servicios al Cliente

Caso de uso: EnviarInformaciónCarnets	
Actores: Tiempo(diariamente)
Actores secundarios: Dpto. Servicios al Cliente
Descripción: este CU es el encargado de confeccionar el listado con los datos de los afiliados para confeccionar y enviar los carnets.
Precondiciones: ninguna
Postcondiciones: el listado fue confeccionado y enviado.
Flujo Principal: Se obtiene la fecha actual desde el sistema. Se llama al método CarnetsController.cargarDatosAfiliados(fechaActual) Se envía por eMail el listado al Dpto. Servicios al Cliente.
Flujos Alternativos: No hay
Flujos de Excepción: No hay

Consultar cobertura online

Ref.	Documento relacionado	Descripción
R1	Especificación de interfaz: Interfaz prestador online	Muestra los métodos que puede llamar el prestador, y especifica con detalle los valores de retorno..
R2	Especificación de clase: InterfazPrestadorController	Especificación de la clase InterfazPrestadorControllerController y sus métodos.

Caso de uso: Consultar cobertura online	
Actores: Prestador
Precondiciones: El prestador se encuentra logeado
Postcondiciones: El pedido de autorización queda registrado.
Flujo Principal: El prestador consulta si un afiliado tiene cobertura para determinada prestación de acuerdo a su plan. InterfazPrestadorController.consultarCobertura(codAfiliado,codPrestacion) El sistema evalúa si el afiliado tiene cubierta en su plan la prestación solicitada, e informa el porcentaje de cobertura, y si debe hacerlo mediante una autorización automática ó manual. No se realizan validaciones adicionales, la consulta es de carácter informativo, para saber las características del plan del afiliado respecto a la prestación solicitada. (Ver R1, y R2) El sistema envía la respuesta al prestador, usando ConsultaCoberturaResponse (ver R1) Fin del caso de uso
Notas: Ver referencias para obtener una visión completa sobre la operación.

Solicitar autorización automática online

Ref.	Documento relacionado	Descripción
R1	Diagrama de secuencia: Pedir autorización automática	Diagrama de secuencia del escenario principal del CU.
R2	Especificación de interfaz: Interfaz prestador online	Muestra los métodos que puede llamar el prestador, y especifica con detalle los valores de retorno..
R3	Especificación de clase: InterfazPrestadorController	Especificación de la clase InterfazPrestadorControllerController y sus métodos.

Caso de uso: Solicitar autorización automática online	Orden: 24
Actores: Prestador
Precondiciones: El prestador se encuentra logeado
Postcondiciones: El pedido de autorización queda registrado.
Flujo Principal: El prestador solicita registrar una autorización automática envíando el código de afiliado y el código de prestación. InterfazPrestadorController.evaluarAutorizacionAutomatica(codAfiliado,codPrestacion) El sistema evalúa si el pedido puede ser concedido (ver R3), y devuelve si se aprueba ó se rechaza, conteniendo el código de autorización, el porcentaje de cobertura, ó si hubiera un error, o si se rechaza, un mensaje conteniendo el motivo (ver R2). El sistema registra el pedido de autorización automática, si se aprobó ó rechazo el pedido (no se registra si hay errores en los parámetros. Fin del caso de uso
Notas: Ver referencias para obtener una visión completa sobre la operación.

Mantener zonas

Documento relacionado	Descripción
M01 - Diagrama de clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación de clase: ZonasController	Especificación de la clase ZonasController y sus métodos.

Caso de uso: Mantener_Zonas	
Descripción: Administra el alta, modificación y/o baja de las zonas del sistema.
Actores: Administrador
Precondiciones: El administrador se encuentra logueado al sistema.
Postcondiciones: Quedará actualizada la información de las zonas.
Flujo Principal: El sistema muestra al administrador el menú correspondiente a la opción Mantener zonas. El administrador selecciona una de las siguientes opciones: Alta zona -> S1 Modificación zona -> S2 Salir -> Fin de caso de uso
Flujos Alternativos: S1. Alta de zona El sistema solicita al administrador el ingreso del nombre de la zona. El sistema verifica la existencia previa del zona mediante la llamada a ZonasController.existeZona(nombre), si devuelve true -> (E1) El sistema solicita al administrador el ingreso de la descripción. Cuando el administrador confirma el ingreso de los datos se llama a ZonasController.agregarZona(nombre,descripcion). Vuelve a 2 del flujo principal. S2. Modificación de zona El sistema solicita al administrador el ingreso del nombre de la zona El sistema verifica la existencia previa del zona mediante la llamada a ZonasController.existeZona(nombre), si devuelve false -> (E2) Mediante la llamada a ZonasController.obtener(nombre) se obtienen y muestran en pantalla los datos de la zona. Se permite la modificación de la descripción Cuando el administrador confirma el ingreso de los datos se llama a ZonasController.modificarZona(nombre,descripcion). Vuelve a 2 del flujo principal.
Flujos de Excepción: E1 La zona ya existe en el sistema. Vuelve a 2 del flujo principal. E2 La zona no existe en el sistema. Vuelve a 2 del flujo principal.

Especificación de clases

Especificación de clases de dominio

Promotor

Persona encargada de atender a los Solicitantes que quieren afiliarse.

Atributo	Tipo	Descripción
fechaBaja	fecha	Fecha en la que fue dado de baja el promotor (si no está activo)

Persona

Clase abstracta para representar los datos y acciones comunes de una persona.

Atributo	Tipo	Descripción
tipoDocumento	enum(DNI,LC,LE,CI)	Tipo de documento.
nroDocumento	int	Número de documento
nombre	string	Primer y segundo nombre (en ese orden).
apellido	string	Apellido completo.
eMail	string	Dirección de correo electrónico de la persona.
fechaNacimiento	Fecha	Fecha de nacimiento
sexo	enum(M,F)	Género de la persona

Afiliado

Persona afiliada a la obra social.

Atributo	Tipo	Descripción
codigo	int	Identificador único de afiliado.
fechaAfiliacion	fecha	Fecha en la que se lo dio de alta en el sistema.
fechaBaja	fecha	Fecha en la que el afiliado solicita la baja
moroso	int	Indica cuantos meses adeuda.

Método verificarCobertura(codPrestacion: integer):

Verifica si el Afiliado posee cobertura para un codigo de prestacion (codPrestacion).

Devuelve verdadero o falso.

Se verificará si el afiliado tiene o no cobertura, de acuerdo a:

Que el Afiliado tenga cobertura de acuerdo al plan pactado.

Que no se haya excedido en la cantidad de prestaciones por período.(*)

Que el afiliado no sea un moroso con 3 ó más cuotas adeudadas (ver atributo “moroso”).

Que las carencias que estipula su plan sean respetadas. (**)

Que en la cobertura de la prestación solicitada este estipulado que sea resoluble mediante una autorización automática.

Que el afiliado no se haya dado de baja, es decir se debe verificar que: afiliado.FechaBaja==null

Ver diagrama de relaciones entre clases.

Ver diagrama de secuencia de autorización automática.

Para lograr verificar los requisitos antes descriptos:

Cada afiliado tiene un plan asociado (Afiliado.Plan), donde puede obtener si lo cubre o no (Afiliado.Plan.ObtenerCobertura(codPrestacion)!=null) y revisar el tema de carencias (**) (afiliado.verificarCarencia==0), y de si es resoluble por autorización automática (cobertura.TipoAutorizacion==auto).

(*) Para controlar el límite de prestaciones, se hará: (afiliado.obtenerCantidadDePrestacionesRealizadas() < cobertura.limiteAnual() )

En caso de que se apruebe la autorización, se devuelve un número que representa el porcentaje de cobertura.

Si se rechaza la autorización, se lanza una excepción que se llamara “AutorizacionRechazoException” conteniendo el mensaje de rechazo qué se obtendrá accediendo a la property message.

Si hay un error de cualquier tipo, se lanza una excepción llamada verificarCoberturaException conteniendo un mensaje que informa el error producido.

Parámetro	Tipo	Descripción
codPrestacion	integer	Código de una prestación.

Método obtenerCantidadDePrestacionesRealizadas(codPrestacion: ): int

Retorna la cantidad de veces que el afiliado realizo una prestacion determinada (codPrestacion).

Se recorre la lista de autorizaciones del afiliado (afiliado.Autorizaciones[]), verificando cuantas autorizaciones se encuentren en estado “APROBADO” ó “REALIZADA” (autorización.getEstado())* de aquellas que la prestación sea la pasada por parámetro, en el año actual. Para determinar el año actual, se usará la fecha de afiliación tomando el día y mes de afiliación para determinar en el corriente año (de acuerdo a la última vez que se cumplió ese mismo día y mes), cuales son las prestaciones realizadas.

Ver diagrama de estados de Autorización Manual.

Ver diagrama de estados de Autorización Automática.

Parámetro	Tipo	Descripción
codPrestacion	int	Código de una prestación.

Método consultarPrestacion(codPrestacion: int, cantPrestacionesRealizadas: int): float

Retorna la cantidad de prestaciones realizadas.

Se invoca Plan.obtenerCobertura(codPrestacion) para ver si tiene cubierto (!=null).

Se invoca this.obtenerCantidadDePrestacionesRealizadas(codPrestacion) para saber cuantas veces se realizó esta prestación. Se devuelve el porcentaje de cobertura (cobertura.Porcentaje), será cero si NO esta cubierto (si cobertura = null), también se devuelve la cantidad de autorizaciones con estado aprobado ó realizado (ver diag de Estados).

Parámetro	Tipo	Descripción
codPrestacion	int	Código de una prestación.
cantPrestacionesRealizadas	int	Cantidad de Prestaciones Realizadas por el Afiliado.

Método verificarCarencia(codPrestacion: int): float

Retorna la cantidad de tiempo (en meses) que el Afiliado debe esperar para tomar una prestacion determinada (codPrestacion).

Primero se procederá a calcular la cantidad de días que el afiliado lleva contratando la prestación actual:

Se accede a afiliado.HistoriaPlan[], si la lista de HistoriaPlan (ver diagrama de clases y/o relaciones) tiene un solo elemento significa.que el afiliado esta con el mismo plan desde que se entró a la OS , entonces accediendo a este elemento (afiliado.HistoriaPlan[].first().fechaIngreso), podremos calcular en base a la fecha actual, la cantidad de días que hace que el afiliado contrató el plan.

Si la mencionada lista, tiene más de un elemento implicará que el afiliado se cambio de plan, en estos casos se irá recorriendo uno a uno los planes del afiliado, por orden cronológico comenzando por el plan actual hasta encontrar ó un plan que NO cubra con la prestación pasada por parámetro (historiaPlan.Plan.obtenerCobertura(codPrestacion)==null), ó bien sea el 1er plan del afiliado (fin de la lista), y con cada uno de estos se irá sumando la cantidad de días que aporta (historiaPlan.FechaEgreso-historiaPlan.FechaIngreso). Es decir, se obtendrá el total acumulado de días en que el afiliado tuvo cubierta la prestación pasada por parámetro de manera ininterrumpida.

Una vez que se tiene la cantidad de días, se calcula la cantidad de meses que representan, considerando para este cálculo que un mes tiene 30 días.

Entonces si lo días calculados son n, la cantidad de meses serán meses=n/30.

Con cobertura=Afiliado.Plan.ObtenerCobertura(codPrestacion), obtenemos la cobertura.

El valor de retorno, será:

“0” si meses > cobertura.Carencia

“meses-cobertura.Carencia” si meses< cobertura.Carencia

Parámetro	Tipo	Descripción
codPrestacion	int	Código de una prestación.

Prestacion

Tipo de prestación que puede realizarse un afiliado.

Atributo	Tipo	Descripción
codigo	string	Código de la prestación según el codificador
nombre	string	Nombre de la prestación (descripción breve).
fechaBaja	fecha	Fecha en la que fue dado de baja (o NULL si está activo)

Plan

Plan para los Afiliados de la obra social

Atributo	Tipo	Descripción
codigo	int	Código de plan.
categoría	float	Categoría del plan. Cuanto más grande es la categoría, mejor es el plan
descripcion	string	Una breve descripción del plan.
permanenciaMinima	float	Permanencia mínima (en meses) que debe cumplir en el plan antes de pasarse a otro.
fechaBaja	fecha	Fecha en la que el afiliado solicita la baja

Método borrar(): bool

Cambia fechaBaja a la fecha actual del sistema

Método obtenerCobertura(codPrestacion: ): Cobertura

Retorna un tipo de Cobertura para una prestacion particular (codPrestacion).

Se recorre la lista de coberturas del plan actual (plan.Coberturas[] ), y se devuelve aquella (cobertura.Prestacion.Codigo) que se corresponda con el código de prestación pasado por parámetro. Si no hay coincidencias, se devuelve null.

Parámetro	Tipo	Descripción
codPrestacion	int	Código de una prestación.

Método agregarCobertura(cobertura: Cobertura): bool

Agregua una cobertura a un plan determinado. Retorna verdadero (correcto) o falso (error).

Se recorre la lista de coberturas del plan, en caso de hallar una con el mismo código de prestación (cobertura.idPrestacion) se arroja una excepción de tipo excCobExist con excCobExist.codPlan = id y excCobExist.codPrest = idPrestacion.

De lo contrario, se agrega una referencia a la cobertura en la colección que es atributo del objeto y se devuelve una referencia a dicha colección.

Parámetro	Tipo	Descripción
cobertura	Cobertura	Una Cobertura.

Método obtenerCoberturas(): Cobertura[]

Devuelve un arreglo de las Coberturas que cubre el Plan.

Prestador

Entidad prestadora de servicios para la obra social. Podría ser tanto una Clínica, como un centro de radiología o un médico particular.

Atributo	Tipo	Descripción
cuit	string	Número de CUIT.
nombre	string	Nombre legal de la entidad.
fechaBaja	fecha	Fecha en la que fue dado de baja (o NULL si está activo)
email	string	Mail del Presador, utilizado para informarle errores en sus archivos enviados
password	string	Password que utilizará el prestador para logearse al sistema y pedir autorizaciones automaticas, consultas, y verificaciones de autorizacion manual.

Cap

Centro de Atención Personalizada, es un punto de atención al cliente que cubre una o más Zonas y tiene uno o más Promotores.

Atributo	Tipo	Descripción
codigo	string	Código único para identificar al Cap (se usa para referirse al Cap en listados, etc)
horario	string	Horario de atención (texto libre)
fechaBaja	fecha	Fecha de baja del CAP

Autorizacion

Cada vez que un Afiliado va a realizarse una Prestación, debe pedir una Autorización (sea Manual o Automática.

Atributo	Tipo	Descripción
codigo	int	Identificador único.
porcentajeCobertura	float	Porcentaje de la prestacion cubierto por la Autorizacion
fechaSolicitud	fecha	Fecha en que fue solicitada la autorización.
fechaRealizacion	fecha	Fecha en que efectivizada la autorización. Es decir el dia en que se rechazo o el dia en que el afiliado la utilizo.
fechaVencimiento	fecha	Fecha en que vence la autorización.
aprobada	bool	Indica si la autorizacion fue aprobada o no.
fundamentosResolucion	string	Una descripcion coloquial del por qué se aprueba o rechaza la autorización

Método getEstado(): enum(Pendiente, Aprobada, Rechazada, Realizada, Vencida)

Retorna el estado de la corriente Autorizacon Manual. Puede ser Pendiente, Aprobada, Rechazada, Realizada o Vencida.

Dependiendo si es automática ó manual, se devolverá el correspondiente estado claramente identificado en el diagrama de estados para “autorización automática” y “autorización manual”, para la fecha actual. Ver diagramas.

Método getEstado(fechaRecepcion: fecha): enum(Pendiente, Aprobada, Rechazada, Realizada, Vencida)

De acuerdo a sí es manual, o automática, se devolverá el correspondiente estado estipulado en los diagramas de estado: Diagrama de Estados: Autorización Manual según fecha y Diagrama de Estados: Autorización Automática según fecha respectivamente. Ver diagramas.

Parámetro	Tipo	Descripción
fechaRecepcion	fecha	Fecha en que se recibe la Autorización.

Método setResolucion(fundamentosResolucion: string, porcentajeCobertura: float):

Asigna un porqué a la autorizacion (FundamentoResolucion) y un porcentaje de cobertura (porcentajeCobertura).

Parámetro	Tipo	Descripción
fundamentosResolucion	string	Una descripción coloquial justificando la Resolución.
porcentajeCobertura	float	Cuanto cubre una Cobertura determinada.

Método Autorizacion(fechaSolicitud: fecha):

Constructor de la Clase.

Parámetro	Tipo	Descripción
fechaSolicitud	fecha	Fecha en que se ingresa la solicitud.

Método obtenerPlazoDeVencimiento(): int

Devuelve la cantidad de tiempo en días que debe pasar una autorizacion sin realizarse, para que se venza. (En gral 60 = 2 meses).

Habrá un archivo “config.ini” en el directorio principal del sistema. Este tendrá una variable llamada “plazoDeVencimientoDeAutorizaciones” que valdrá 60.

Formato: Será un archivo de texto, y tendrá variables separadas por un ‘\n’.

Ej:

Var1=algo

Var2=otracosa

plazoDeVencimientoDeAutorizaciones=60

El valor de retorno deberá leerse en días.

Zona

Región geográfica que cubre un Cap y a la que pertenecen los Prestadores

Atributo	Tipo	Descripción
nombre	string	Nombre de la Zona
descripcion	string	Descripción de la Zona

Solicitante

Persona esperando ser Afiliado a la obra social por un Promotor.

Atributo	Tipo	Descripción
disponibilidad	string	Horario en el cual puede ser visitado (como texto libre)
familiares	int	Cantidad de integrantes del grupo familiar a afiliar.
observaciones	string	Observaciones que puedan ser de utilidad para el Promotor.
pendiente	bool	Indica si el solicitante fue visitado o no.

AutorizacionManual

Autorización que debe ser aprobada manualmente, a través de un auditor médico.

Atributo	Tipo	Descripción
observaciones	string	Una descripcion coloquial del por qué se solicita la autorización
fechaResolucion	fecha	Fecha en la que se aprobo/rechazo la autorizacion.
nroLegajo	int	Se graba el nro de legajo de quien estaba logeado al momento de autorizar/rechazar

Método AutorizacionManual(fechaSolicitud: fecha):

Constructor de la Clase.

Parámetro	Tipo	Descripción
fechaSolicitud	fecha	Fecha en que se ingresa la solicitud.

Método getEstado(fechaRecepcion: fecha): enum(Pendiente, Aprobada, Rechazada, Realizada, Vencida)

Retorna el estado de la corriente Autorizacon Manual. Puede ser Pendiente, Aprobada, Rechazada, Realizada o Vencida.

Parámetro	Tipo	Descripción
fechaRecepcion	fecha	Fecha en que se recibe la Autorización.

AutorizacionAutomatica

Autorización aprobada o rechazada automáticamente por el sistema

Método AutorizacionAutomatica(fechaSolicitud: fecha):

Constructor de la Clase.

Parámetro	Tipo	Descripción
fechaSolicitud	fecha	Fecha en que se ingresa la solicitud.

Método getEstado(fechaRecepcion: fecha): enum(Pendiente, Aprobada, Rechazada, Realizada, Vencida)

Retorna el estado de la corriente Autorizacon Automatica. Puede ser Pendiente, Aprobada, Rechazada, Realizada o Vencida.

Parámetro	Tipo	Descripción
fechaRecepcion	fecha	Fecha en que se recibe la solicitud.

Cobertura

Limitaciones de cobertura para un Plan y una Prestación determinada.

Atributo	Tipo	Descripción
carencia	float	Antigüedad (en meses) que debe tener el afiliado en el plan para ser cubierto.
porcentaje	float	Porcentaje de la prestación cubierto.
limiteAnual	int	Cantidad de prestaciones que se puede realizar por año (cero indica que no hay límite).
tipoAutorizacion	enum(manual,auto)	Indica el tipo de autorización que necesita para realizarse la prestación.

Categoria

Clasificación de las Prestaciones

Atributo	Tipo	Descripción
codigo	int	Código de la categoría según el codificador
nombre	string	Nombre de la categoría.
fechaBaja	fecha	Fecha en la que fue dado de baja (o NULL si está activo)

HistoriaPlan

Representa el período de tiempo que un afiliado estuvo en un plan.

Atributo	Tipo	Descripción
fechaIngreso	fecha	Fecha en que se dio de alta el plan
fechaEgreso	fecha	Fecha en la que el plan no rige mas para el afiliado (si es el plan actual es NULL)

Direccion

Dirección y datos de un domicilio

Atributo	Tipo	Descripción
calle	string	Calle del domicilio
numero	int	Número del domicilio
piso	int	Piso del domicilio
departamento	string	Departamento del domicilio
codigoPostal	string(8)	Código postal del domicilio
provincia	enum([provincias])	Provincia donde se encuentra el domicilio
telefono	string	Teléfono del domicilio

Especificación de clases de control

AfiliadosSolicitanteController

Documento relacionado	Descripción
Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
Especificación del caso de uso: Ingresar Solicitud	Especificación del caso de uso Ingresar Solicitud
Especificación del caso de uso: Agregar afiliado	Especificación del caso de uso Agregar afiliado
Especificación del caso de uso: Modificar Afiliado	Especificación del caso de uso Modificar Afiliado
Especificación del caso de uso: Eliminar Afiliado	Especificación del caso de uso Eliminar Afiliado

Paquete: Controlador

Responsabilidades: provee la funcionalidad para manejar el ABM de solicitantes y el ABM de afiliados, así como también distintos tipos de consulta sobre los mismos en el sistema.

Métodos:

afiliarFamiliar

Firma y valor de retorno:

afiliarFamiliar(tipoDoc,nroDoc)

Descripción general:

Afilia un familiar del titular

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del familiar
nroDoc	Int	Número de documento del familiar

d. Descripción detallada:

Se recuperan los datos del familiar a incorporar:

familiar = SolicitanteDataService.obtener(tipoDoc, nroDoc)

titular = AfiliadoDataService.obtener(familiar.idTitular)

Se completan los datos del familiar con los valores que se indican a continuación:

familiar.FechaAfiliacion = fecha actual

familiar.FechaBaja = Null

familiar.Moroso = 0 (cero)

familiar.IdPlan = titular.IdPlan

Se agregar el plan al historial:

HistoriaPlanDataService.agregar( familiar.Codigo, familiar.idPlan)

Se asigna un código de afiliado (familiar.Codigo): se trata de un autoincrement obtenido de la capa de persistencia.

Luego se almacena en la tabla Afiliado los datos contenidos en el objeto instanciadoutilizando el método: AfiliadoDataService.Agregar(afiliado).

Si algún paso fallara, el método devuelve FALSE, caso contrario devuelve TRUE.

afiliarTitular

a. Firma y valor de retorno:

afiliarTitular( tipoDocumento, nroDocumento, codPlan ): bool

b. Descripción general:

Un solicitante pasa a ser un afiliado en el sistema.

c. Parámetros:

Nombre	Tipo	Descripción
TipoDoc	string	Tipo de documento del solicitante
NroDoc	Int	Número de documento del solicitante
CodPlan	Int	Código de plan a asignar al afiliado

d. Descripción detallada:

Se recuperan los datos del solicitante a afiliar mediante la llamada a

SolicitanteDataService.obtener(tipoDoc, nroDoc) y se almacena en una instancia auxiliar llamada solicitante.

Se instancia una variable de la clase Afiliado llamada dato.

Se asigna el plan al afiliado:

dato.IdPlan = codPlan

Se completan los datos del afiliado con los valores que se indican a continuación:

dato.FechaAfiliacion = fecha actual

dato.FechaBaja = null

dato.Moroso: 0 (cero)

Se agregar el plan al historial del afiliado mediante la llamada a

HistoriaPlanDataService.agregar(dato.codigo,dato.idPlan)

Se asigna un código de afiliado (dato.Codigo): se trata de un autoincrement obtenido de la capa de persistencia.

Luego se almacenan los datos en el sistema mediante la llamada a

AfiliadoDataService.agregar(Dato).

3.3 agregarSolicitante

a. Firma y valor de retorno:

agregarSolicitante(tipoDoc,nroDoc,nombre,apellido,eMail,fechaNacimiento,calle,numero,

piso,departamento,codigoPostal,provincia,idZona,telefono,sexo,disponibilidad, cantidadfamiliares, observaciones): void

b. Descripción general:

Carga un solicitante en el sistema.

c. Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del solicitante
nroDoc	Int	Número de documento del solicitante
Nombre	String	Nombre
Apellido	String	Apellido
email	String	Email
fechaNacimiento	Fecha	Fecha de nacimiento
Calle	String	Calle del solicitante
Numero	Int	Número de calle
Piso	Int	Piso
Departamento	String	Dpto
codigoPostal	String(8)	Código postal
Provincia	String	Provincia
idZona	int	Identificador único de la zona en la que habita el solicitante
Telefono	String	Teléfono
Sexo	Enum	Sexo
Disponibilidad	String	Disponibilidad para visita del promotor
cantidadFamiliares	Int	Cantidad de familiares del solicitante
observaciones	String	Comentarios sobre el solicitante

d. Descripción detallada:

Se instancia una variable de la clase Solicitante llamada Dato. Se cargan los datos pasados por parámetro:

Dato.TipoDocumento = tipoDoc

Dato.NroDocumento = nroDoc

Dato.Nombre = nombre

Dato.Apellido = apellido

Dato.Sexo = sexo

Dato.FechaNacimiento = fechaNacimiento

Dato.EMail = eMail

Dato.Disponibilidad = disponibilidad

Dato.Familiares = cantidadFamiliares

Se instancia una variable de la clase Zona llamada datosZona y se obtienen todos sus datos mediante la llamada a ZonaDataService.obtener(idZona).

Se instancia una variable de la clase Direccion llamada Dir y se carga:

Dir.Calle = calle

Dir.Numero = numero

Dir.Piso = piso

Dir.Departamento = departamento

Dir.CodigoPostal = codigoPostal

Dir.Provincia = provincia

Dir.Zona = datosZona

Y se carga la dirección del solicitante:

Dato.direccion = Dir

Finalmente se almacenan los datos en la BD mediante la llamada a SolicitanteDataService.guardar(Dato).

3.4 eliminarAfiliado

a. Firma y valor de retorno:

eliminarAfiliado(tipoDoc,nroDoc) : bool

b. Descripción general:

Éste método es el encargado de eliminar a un afiliado del sistema, marcándolo como inactivo.

c. Parámetros:

Nombre	Tipo	Descripción
TipoDoc	string	Tipo de documento con el que se registró al afiliado en el sistema.
NroDoc	Int	Número de documento con el que se registró al afiliado en el sistema.

Descripción detallada:

Se recuperan los datos del afiliado mediante la llamada a

AfiliadoDataService.obtener(tipoDoc,nroDoc) y carga los datos en una instancia auxiliar de Afiliado llamada dato.

Se carga la fecha actual a partir del motor de la BD.

Modifica dato.fechaBaja = fechaActual;

Se guardan las modificaciones mediante la llamada a AfiliadoDataService.guardar(dato).

3.5 eliminarGrupoFamiliar

a. Firma y valor de retorno:

eliminarGrupoFamiliar(tipoDoc, nroDoc ) : bool

Descripción general:

Éste método elimina el grupo familiar asociado al afiliado (titular) que fue dado de alta en el sistema con los datos que el método recibe como parámetros.

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento con el que se registró al titular del grupo familiar en el sistema.
NroDoc	Int	Número de documento con el que se registró al titular del grupo familiar en el sistema.

Descripción detallada:

Este método llama a AfiliadoDataService.obtenerFamiliares(tipoDoc,nroDoc) para obtener los registros que posean un titular definido por los parámetros que toma el método. Con estos datos se crea una lista de instancias de la clase Afiliado llamada afiliados. Luego, se recorre la lista, tomando el tipo y número de documento de cada instancia para ejecutar el método eliminarAfiliado(afiliados[i].tipoDoc, afiliado[i].nroDoc)

Si alguno de los métodos devuelve false se retorna, caso contrario se retorna true.

3.6 eliminarSolicitante

a. Firma y valor de retorno:

eliminarSolicitante(tipoDoc,nroDoc) : bool

Descripción general:

Éste método es el encargado de eliminar a un solicitante del sistema.

c. Parámetros:

Nombre	Tipo	Descripción
TipoDoc	string	Tipo de documento con el que se registró al solicitante en el sistema.
NroDoc	Int	Número de documento con el que se registró al solicitante en el sistema.

d. Descripción detallada:

Se elimina al solicitante mediante la llamada a SolicitanteDataService.eliminar(tipoDoc,nroDoc)

esTitular

Firma y valor de retorno:

esTitular(tipoDoc, nroDoc): bool

Descripción general:

Este método indica si el afiliado registrado en el sistema mediante los datos recibidos como parámetros es titular de un grupo familiar.

Parámetros:

Nombre	Tipo	Descripción
TipoDoc	string	Tipo de documento con el que se registró al afiliado en el sistema.
NroDoc	Int	Número de documento con el que se registró al afilido en el sistema.

d. Descripción detallada:

Se llama a AfiliadoDataService.esTitular(tipoDoc,nroDoc) para obtener la cantidad de integrantes del supuesto grupo familiar del que el afiliado en cuestión podría ser titular. Si el valor obtenido es 0, se devuelve false, en caso contrario true.

existeAfiliado

Firma y valor de retorno:

existeAfiliado(tipoDoc,nroDoc) : bool

Descripción general:

Devuelve si un afiliado existe en el sistema.

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del solicitante
nroDoc	int	Número de documento del solicitante

d. Descripción detallada:

Mediante la llamada a AfiliadoDataService.existe(tipoDoc,nroDoc) verifica si el afiliado está dado de alta en el sistema. Si devuelve false el método retorna false.

3.9 puedeReactivarAfiliado

a. Firma y valor de retorno:

puedeReactivarAfiliado(tipoDoc,nroDoc) : bool

Descripción general:

Verifica si un afiliado puede ser reactivado o no puede volver a ser afiliado.

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del solicitante
nroDoc	int	Número de documento del solicitante

Descripción detallada:

Se obtienen los datos del afiliado mediante la llamada a

AfiliadoDataService.obtener(tipoDoc,nroDoc) y se almacenan en una instancia auxiliar de la clase Afiliado llamada dato.

Si dato.fechaBaja es null (el afiliado está activo) se impide volver a afiliarlo, el método devuelve false.

Si dato.fechaBaja distinto null (el afiliado está dado de baja) y dato.Moroso tiene un valor mayor a 3 entonces el afiliado está dado de baja en el sistema pero con deuda que impide volver a afiliarlo, el método devuelve false.

Si dato.Fechabaja distinto null (el afiliado está dado de baja) y dato.moroso tiene un valor menor a 3 entonces el afiliado está dado de baja en el sistema pero puede volver a afiliarse, el método devuelve true.

3.10 existeSolicitante

a. Firma y valor de retorno:

existeSolicitante(tipoDoc,nroDoc) : bool

Descripción general:

Verifica la existencia de un solicitante en el sistema

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del solicitante
nroDoc	Int	Número de documento del solicitante

d. Descripción detallada:

Se devuelve SolicitanteDataService.existe(tipoDoc,nroDoc) , true si existe en el sistema y false si no existe.

3.11 modificarAfiliado

a. Firma y valor de retorno:

modificarAfiliado(tipoDoc,nroDoc,telefono,calle,numero,piso,departamento,codigoPostal,

provincia,idZona,eMail,codPlan) : bool

Descripción general:

Modifica los datos de un afiliado en el sistema

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del afiliado
nroDoc	Int	Número de documento del afiliado
Telefono	String	Teléfono del afiliado
Calle	String	Calle del afiliado
Numero	Int	Número de calle del afiliado
Piso	Int	Piso
Departamento	String	Dpto
codigoPostal	String(8)	Código postal
Provincia	String	Provincia
IdZona	Int	Identificador único de la zona en la que habita el afiliado
Email	String	Email
codPlan	Int	Código del plan del afiliado

d. Descripción detallada:

Se recuperan los datos del afiliado mediante la llamada a

AfiliadoDataService.obtener(tipoDoc,nroDoc) y se almacena en una instancia auxiliar de la clase Afiliado llamada dato.

Se modifican los datos según lo pasado por parámetro. Si se detecta un cambio de plan se modifica el historial del afiliado mediante la llamada a

HistoriaPlanDataService.agregar( dato.Codigo, codPlan )

En caso de detectarse un cambio de dirección y de zona, se instancia un objeto de la clase Zona (nuevaZona) mediante la llamada a ZonaDataService.obtener(idZona). Luego se instancia una variable de la clase Direccion llamada Dir y se carga:

Dir.Calle = calle

Dir.Numero = numero

Dir.Piso = piso

Dir.Departamento = departamento

Dir.CodigoPostal = codigoPostal

Dir.Provincia = provincia

Dir.Zona = nuevaZona

Y se carga la dirección del afiliado:

dato.direccion = Dir

Una vez modificados los datos se almacenan mediante la llamada a

AfiliadoDataService.guardar(dato)

modificarTitular

Firma y valor de retorno:

modificarTitular(tipoDocAnterior, nroDocAnterior, tipoDocNuevo,

nroDocNuevo ) : bool

Descripción general:

Éste método reasigna el titular de un grupo familiar.

Parámetros:

Nombre	Tipo	Descripción
tipoDocAnterior	string	Tipo de documento con el que se registró al titular original del grupo familiar en el sistema.
NroDocAnterior	Int	Número de documento con el que se registró al titular original del grupo familiar en el sistema.
TipoDocNuevo	string	Tipo de documento con el que se registró al nuevo titular del grupo familiar en el sistema.
NroDocNuevo	Int	Número de documento con el que se registró al nuevo titular del grupo familiar en el sistema.

d. Descripción detallada:

Se obtienen los datos del afiliado tomado como nuevo titular, creando una instancia de la clase Afiliado llamada nuevoTitular mediante la llamada al método: AfiliadoDataService.obtener(tipoDocNuevo,nroDocNuevo).

Luego se modifica dicha instancia, poniendo el atributo “titular” en null (eliminando los datos del titular anterior).

Se ejecuta el método

AfiliadoDataService.obtenerFamiliaresAfiliados(tipoDocAnterior,nroDocAnterior) para obtener los registros que posean un titular definido por tipoDocAnterior y nroDocAnterior (titular original), guardando estos datos en una lista auxiliar de instancias de la clase Afiliado.

Para cada elemento de esta lista, se reasigna el titular, eliminando los datos del titular anterior y asignando al campo “titular” la instancia nuevoTitular.

Se almacenan los datos ejecutando para cada elemento de la lista de familiares y para la instancia nuevoTitular el método AfiliadoDataService.guardar(afiliado.codigo)

Si alguno de los métodos devuelve false se retorna, caso contrario se retorna true.

3.13 obtenerFamiliares

a. Firma y valor de retorno:

obtenerFamiliares(tipoDoc,nroDoc) : Solicitante[]

b. Descripción general:

Devuelve los familiares del solicitante para que sean cargados en el sistema

c. Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del solicitante
nroDoc	String	Número de documento del solicitante

Descripción detallada:

Se obtienen los datos de los familiares del solicitante mediante la llamada a SolicitanteDataService.obtenerFamiliares(tipoDoc,nroDoc)

3.14 obtenerFamiliaresAfiliados

a. Firma y valor de retorno:

obtenerFamiliares(tipoDoc, nroDoc) : Afiliado[]

Descripción general:

Éste método devuelve una lista con todos los afiliados pertenecientes al grupo familiar del que es titular la persona que fue ingresada al sistema con los datos que el método recibe como parámetros.

c. Parámetros:

Nombre	Tipo	Descripción
TipoDoc	string	Tipo de documento con el que se registró al titular del grupo familiar en el sistema.
NroDoc	Int	Número de documento con el que se registró al titular del grupo familiar en el sistema.

d. Descripción detallada:

Este método llama a AfiliadoDataService.obtenerFamiliares(tipoDoc,nroDoc) para obtener los registros que posean un titular definido por los parámetros que toma el método. Con estos datos se crea la lista de instancias de la clase Afiliado devuelta por el método. Esta lista estará vacía si no se obtienen registros (la persona ingresada no es titular de grupo).

3.15 obtenerSolicitantesAfiliar

a. Firma y valor de retorno:

obtenerSolicitantesAfiliar() : Solicitante[]

Descripción general:

Obtiene los solicitantes pendientes de afiliación.

c. Descripción detallada:

Se recuperan los datos de los solicitantes pendientes de afiliación mediante la llamada a SolicitanteDataService.obtenerPendientesAfiliacion().

3.16 obtenerDetalleAfiliado

a. Firma y valor de retorno:

obtenerDetalleAfiliado(tipoDoc,nroDoc) : Afiliado

Descripción general:

Obtiene los datos de un afiliado

Parámetros:

Nombre	Tipo	Descripción
TipoDoc	string	Tipo de documento del afiliado
NroDoc	Int	Número de documento del afiliado

d. Descripción detallada:

Se recuperan los datos del afiliado mediante la llamada a

AfiliadoController.obtener(tipoDoc,nroDoc) y se devuelven.

3.17 reactivarAfiliado

a. Firma y valor de retorno:

reactivarAfiliado(tipoDoc,nroDoc) : bool

Descripción general:

Vuelve a habilitar un afiliado en el sistema modificando los datos descriptivos del mismo.

Parámetros:

Nombre	Tipo	Descripción
TipoDoc	string	Tipo de documento del afiliado
NroDoc	Int	Número de documento del afiliado

d. Descripción detallada:

Se recuperan los datos del afiliado mediante la llamada a

SolicitanteDataService.obtener(tipoDoc,nroDoc) y carga los datos en una instancia auxiliar de Solicitante llamada solicitante.

Se recuperan los datos del afiliado mediante la llamada a

AfiliadoDataService.obtener(tipoDoc,nroDoc) y carga los datos en una instancia auxiliar de Afiliado llamada Dato.

Dato.Calle = solicitante.Calle

Dato.Numero = solicitante.Numero

Dato.Piso = solicitante.Piso

Dato.Departamento = solicitante.Departamento

Dato.Telefono = solicitante.Telefono

Dato.Email = solicitante.Email

Dato.FechaBaja = null

Se almacenan las modificaciones mediante la llamada a AfiliadoDataService.guardar(Dato).

8 obtenerZonas

Firma y valor de retorno:

ObtenerZonas() : Zona[]

Descripción detallada:

Se obtienen los datos de las zonas almacenadas en el sistema mediante la llamada a ZonaDataService.obtenerTodas() y se devuelven en un vector.

AfiliadosMorososController

Paquete: Controlador

Responsabilidades:

Esta clase es la encargada de la actualización de las deudas de los afiliados en el sistema.

Métodos:

cargarDatos

Firma y valor de retorno:

cargarDatos () : bool

Descripción general:

Éste método es el que se llama al dispararse el evento para procesar los archivos recibidos. Chequea y procesa los archivos que estén disponibles en el sitio FTP.

Descripción detallada:

Verifica que el formato de nombre del archivo sea válido.

(AAAA-MM-DD_estado_Afiliados.txt)

Para cada registro del archivo realiza todas las validaciones referidas al archivo que contiene los datos de las prestaciones llamando a

verificarRegistro(stringRegistro), si devuelve true se llama a

actualizarDeuda(tipoDoc,nroDoc,cantidadCuotas). Si devuelve false se ignora el registro.

Si algún paso falla devolverá false, caso contrario devolverá true.

actualizarDeuda

Firma y valor de retorno:

actualizarDeuda(tipoDoc,nroDoc, cantidadCuotas): bool

Descripción general:

Modifica la cantidad de cuotas que adeuda un afiliado.

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del afiliado a modificar
nroDoc	Int	Nro de documento del afiliado a modificar
cantidadCuotas	Int	Cantidad de cuotas que adeuda

Descripción detallada:

Se obtienen los datos del afiliado mediante la llamada a AfiliadoDataService.obtener(tipoDoc,nroDoc), si el método retornó un valor distinto de nulo se almacena en una instancia auxiliar de la clase Afiliado llamada Dato.

Se modifica dato.moroso = cantidadCuotas y se almacenan los datos mediante la llamada a AfiliadoDataService.guardar(dato)

Si alguno de los métodos devuelve false se retorna, caso contrario se retorna true

verificarRegistro

Firma y valor de retorno:

verificarRegistro(stringRegistro): bool

Descripción general:

Verifica el formato del registro obtenido

Parámetros:

Nombre	Tipo	Descripción
stringRegistro	String	Registro del archivo de deudas

Descripción detallada:

Controla la estructura del registro, que debe poseer los campos:

Tipo documento: string

Nro de documento: número de tipo entero

CantidadCuotas: número de tipo entero

Si falla la verificación el método devuelve false, caso contrario devuelve true.

ArmarCartillaController

Paquete: Controlador

Responsabilidades: provee la funcionalidad para el armado de la cartilla médica

Métodos:

3.1 obtenerPlanesVigentes

Firma y valor de retorno:

obtenerPlanesVigentes(): Plan[]

Descripción general:

Retorna una colección de instancias de Plan de los planes vigentes en el sistema (aquellos cuya fecha de baja es NULL).

Parámetros:

No tiene.

Descripción detallada:

Obtiene una colección de todos los planes del sistema (planes[]) mediante PlanDataService.obtenerPlanesVigentes() y la devuelve.

3.2 obtenerDetallePlan

Firma y valor de retorno:

obtenerDetallePlan(codigoPlan): Plan

Descripción general:

Devuelve los datos de un plan

Parámetros:

Nombre	Tipo	Descripción
codigoPlan	Int	Código del plan del cual se quieren obtener los detalles

Descripción detallada:

Obtiene los datos de un plan mediante la llamada a PlanDataService.obtener (codigoPlan) y los devuelve.

3.3 obtenerCoberturasPlan

Firma y valor de retorno:

obtenerCoberturas(codPlan): Cobertura []

Descripción general:

Devuelve una colección de Cobertura representando las coberturas que tiene el plan actual.

Parámetros:

Nombre	Tipo	Descripción
codigoPlan	Int	Código del plan del cual se quieren obtener las coberturas

Descripción detallada:

Mediante la llamada a CoberturaDataService.obtenerCoberturasPlan(codigoPlan) devuelve un vector de coberturas.

3.4 obtenerCAPS

Firma y valor de retorno:

obtenerCAPS() : CAP[]

Parámetros:

Nombre	Tipo	Descripción
codigoPrestacion	Int	Código de la prestación de la cual se quieren los detalles

Descripción detallada:

Se obtiene la colección de CAPS del sistema mediante la llamada a CAPDataService.obtenerTodos() y se devuelve.

3.5 cargarCartillaPlan

Firma y valor de retorno:

cargarCartillaPlan(codPlan): CartillaMedica

Descripción general:

Arma la cartilla médica de acuerdo al código de plan pasado por parámetro.

Parámetros:

Nombre	Tipo	Descripción
codPlan	Int	Código del plan sobre el que se quiere confeccionar la cartilla médica

Descripción detallada:

Se obtienen los datos principales del plan mediante la llamada a obtenerDetallePlan(codPlan) y se agregan a la cartilla: plan.Codigo,plan.Categoría, plan.Descripción, plan.PermanenciaMinima.

Se agregan a la cartilla los datos de los CAPS mediante la llamada a obtenerCAPS(). Para cada elemento del vector devuelto se agrega a la cartilla CAP.Codigo, CAP.Horario, CAP.Direccion.Calle, CAP.Direccion.Numero, CAP.Direccion.Piso, CAP.Direccion.Departamento, CAP.Direccion.CodigoPostal, CAP.Direccion.Provincia, CAP.Direccion.Telefono.

Se obtienen las coberturas del plan mediante la llamada a obtenerCoberturasPlan(plan.codigo).

Para cada cobertura obtenida:

Se cargan los datos en la cartilla: cobertura.Porcentaje, cobertura.TipoAutorizacion, cobertura.Carencia, cobertura.LimiteAnual

Mediante la llamada a PrestacionDataService.obtenerPrestadoresPorId (cobertura.IdPrestacion) obtengo los prestadores de la cobertura para el plan.

El vector obtenido se ordena por el campo Prestador.Direccion.idZona

Para cada identificador de zona obtenido se obtiene el nombre mediante la llamada a ZonaDataService.obtenerNombre(Prestador.Direccion.idZona) y se carga en la cartilla.

Para cada elemento del vector correspondiente a ese identificador de zona se carga en la cartilla prestador.CUIT, prestador.Nombre,prestador.Direccion.Calle, prestador.Direccion.numero, prestador.Direccion.Piso, prestador.Direccion.Departamento, prestador.Direccion.CodigoPostal, prestador.Direccion.Provincia, prestador.Direccion.Telefono, prestador.EMail.

Se vuelve al punto 4 hasta que se terminen los elementos del vector.

AtenderConsultasController

Paquete: Controlador

Responsabilidades:

Esta clase es la encargada de administrar las respuestas a las consultas que puede realizar un afiliado al sistema.

Métodos:

existeAfiliado

Firma y valor de retorno:

existeAfiliado(tipoDoc,nroDoc) : bool

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del afiliado
nroDoc	int	Número de documento del afiliado

Descripción detallada:

Mediante la consulta a AfiliadoDataService.existe(tipoDoc,nroDoc) se devuelve true en caso que exista el afiliado y false si no existe en el sistema.

cuotasAdeudadas

Firma y valor de retorno:

cuotasAdeudadas(tipoDoc,nroDoc) : int

Descripción general:

Obtiene la cantidad de cuotas que adeuda un afiliado

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del afiliado
nroDoc	int	Número de documento del afiliado

Descripción detallada:

Mediante la llamada a AfiliadoDataService.obtener(tipoDoc,nroDoc) se obtiene una instancia de afiliado almacenada en una variable auxiliar llamada dato.

Se devuelve dato.moroso

permanencia en Plan

Firma y valor de retorno:

permanenciaEnPlan(tipoDoc,nroDoc) : Fecha

Descripción general:

Obtiene la fecha de alta del afiliado en el plan vigente

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del afiliado
nroDoc	int	Número de documento del afiliado

Descripción detallada:

Mediante la llamada a AfiliadoDataService.obtener(tipoDoc,nroDoc) se obtiene una instancia de afiliado almacenada en una variable auxiliar llamada dato.

Mediante la llamada a HistoriaPlanDataService.obtenerUltimaFechaIngreso(dato.codigo) se devuelve la última fecha de ingreso a un plan registrada para el afiliado.

obtenerCAPAfiliado

Firma y valor de retorno:

obtenerCAPAfiliado(tipoDoc,nroDoc) : CAP

Descripción general:

Obtiene los datos del CAP asociado al afiliado

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del afiliado
nroDoc	int	Número de documento del afiliado

Descripción detallada:

Mediante la llamada a AfiliadoDataService.obtener(tipoDoc,nroDoc) se obtiene una instancia de afiliado almacenada en una variable auxiliar llamada dato.

Con el identificador de zona del afiliado obtengo el identificador de CAP correspondiente a la misma mediante la llamada a ZonaDataService.obtenerIdCAP(afiliado.Direccion.IdZona)y almaceno el identificador en la variable idCAP.

Con el identificador del CAP obtengo todos sus datos mediante la llamada a CAPDataService.obtener(idCAP) y devuelvo los datos.

obtenerPrestacionesPlan

Firma y valor de retorno:

obtenerPrestacionesPlan(tipoDoc,nroDoc) : Prestacion[]

Descripción general:

Obtiene los datos de las prestaciones correspondientes al plan del afiliado

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del afiliado
nroDoc	int	Número de documento del afiliado

Descripción detallada:

Mediante la llamada a AfiliadoDataService.obtener(tipoDoc,nroDoc) se obtiene una instancia de afiliado almacenada en una variable auxiliar llamada dato.

Mediante la llamada a CoberturaDataService.obtenerCoberturasPlan(dato.idPlan) se obtienen las coberturas correspondientes al plan en un vector llamado auxCoberturas.

Para todos los elementos del vector (variable auxiliar i) se obtienen los datos de la prestación mediante la llamada a PrestacionDataService.obtener(auxCoberturas.elemento[i].idPrestacion)

Este método devuelve una instancia de prestación que se almacena en un vector auxiliar llamado auxPrestaciones.

Se devuelve auxPrestaciones.

obtenerPrestadoresZona

Firma y valor de retorno:

obtenerPrestadoresZona(tipoDoc,nroDoc,codigoPrestacion) : Prestador[]

Descripción general:

Obtiene los datos de los prestadores de la zona del afiliado

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del afiliado
nroDoc	int	Número de documento del afiliado

Descripción detallada:

Mediante la llamada a AfiliadoDataService.obtener(tipoDoc,nroDoc) se obtiene una instancia de afiliado almacenada en una variable auxiliar llamada dato.

Mediante la llamada a

PlanDataService.obtenerPrestadores(afiliado.idPlan) obtengo los prestadores de un plan, filtro los prestadores que tienen prestador.direccion.IdZona = dato.direccion.idZona y los devuelvo.

obtenerTipoAutorizacion

Firma y valor de retorno:

obtenerTipoAutorizacion(tipoDoc,nroDoc,codigoPrestacion):enum(manual,auto)

Descripción general:

Obtiene el tipo de autorización requerido para que el afiliado pueda realizar la prestación.

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del afiliado
nroDoc	int	Número de documento del afiliado
codigoPrestacion	Int	Código de la prestación del cual se quiere averiguar el tipo de autorización requerida

Descripción detallada:

Mediante la llamada a AfiliadoDataService.obtener(tipoDoc,nroDoc) se obtiene una instancia de afiliado almacenada en una variable auxiliar llamada dato.

Mediante la llamada a CoberturaDataService.obtener(dato.idPlan,codigoPrestacion) se obtienen los datos correspondientes a la cobertura y se devuelve el valor de cobertura.tipoAutorizacion.

obtenerPorcentajeCobertura

Firma y valor de retorno:

obtenerPorcentajeCobertura(tipoDoc,nroDoc,codigoPrestacion):float

Descripción general:

Obtiene el tipo de autorización requerido para que el afiliado pueda realizar la prestación.

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del afiliado
nroDoc	int	Número de documento del afiliado
codigoPrestacion	Int	Código de la prestación del cual se quiere averiguar el tipo de autorización requerida

Descripción detallada:

Mediante la llamada a AfiliadoDataService.obtener(tipoDoc,nroDoc) se obtiene una instancia de afiliado almacenada en una variable auxiliar llamada dato.

Mediante la llamada a CoberturaDataService.obtener(dato.idPlan,codigoPrestacion) se obtienen los datos correspondientes a la cobertura y se devuelve el valor de cobertura.porcentaje.

AutorizacionController

Paquete: Controlador

Responsabilidades: Da la funcionalidad necesaria de más alto nivel para el manejo de autorizaciones, ver descripción de métodos. Conoce a: Autorización, AutorizacionManual, AutorizacionAutomatica, AutorizacionDataService, Afiliado, PrestadorDataService, PrestacionDataService

Métodos:

3.1 guardarAutorizacionManual

Firma y valor de retorno:

bool GuardarAutorizacionManual(int codPrestacion, String cuitPrestador, int codAfiliado, observaciones)

Descripción general:

Guarda una autorización Manual.

Parámetros:

Nombre	Tipo	Descripción
codPrestacion	Int	Código de prestación.
cuitPrestador	String	Cuit del prestador.
codAfiliado	Int	Código de afiliado.
observaciones	String	Observaciones sobre la autorización cuando es solicitada. Ej: Por que es necesario que se apruebe según el médico del afiliado.

Descripción detallada: Se registra un nuevo pedido de Autorización Manual con los datos pasados por parámetro. Es responsabilidad de este método intentar guardarla sin verificar más que los códigos existan, para eso:

PrestacionDataService.obtener(codPrestacion)!=null

PrestadorDataService.obtener(cuitPrestacion)!=null

AfiliadoDataService.obtener(codAfiliado)!=null

Además:

Se setea “fechaSolicitud” como la fecha del sistema en el instante solicitado.

“fechaRealización” en NULL

“fechaVencimiento” comó a n días de la fechaSolicitud. n=Autorización.obtenerPlazoDeVencimiento()

fechaResolución en NULL

fundamentosResolucion en NULL.

Nota: No se setea el atributo “aprobada”, pues mientras fechaResulución sea null, este valor no tiene sentido. Ver diagramas de estados para más detalles.

Para todo esto se instancia una AutorizacionManual con los datos mencionados y se guarda utilizando AutorizacionDataService.Guardar(autorizacion);

Si algún código es inexistente ó ocurre algún error de cualquier tipo se devuelve false, de lo contrario true.

3.2 evaluarAutorizacionAutomatica

Firma y valor de retorno:

float evaluarAutorizacionAutomatica(String cuitPrestador, int codPrestacion, int codAfiliado)

Descripción general:

Evalúa si una autorización debe ser rechazada o aprobada, lo registra.

Parámetros:

Nombre	Tipo	Descripción
cuitPrestador	String	CUIT del prestador.
codPrestacion	int	Código de prestación.
codAfiliado	int	Código de afiliado.

Descripción detallada:

Nota: Ver diagrama de secuencia de ”Autorización Automática” para detalles sobre este método.

A grandes rasgos:

Se evalúa la viabilidad del pedido y se guarda la autorización aprobada ó rechazada según corresponda de acuerdo a:

Que el Afiliado tenga cobertura de acuerdo al plan pactado.

Que no se haya excedido en la cantidad de prestaciones por período.

Que el afiliado no sea un moroso con más de 3 cuotas adeudadas (ver atributo “moroso”).

Que las carencias que estipula su plan sean respetadas.

Que en la cobertura de la prestación solicitada este estipulado que sea resoluble mediante una autorización automática.

(Estas validaciones se realizan en afiliado.VerificarCobertura(), ver especificacion de Afiliado)

En caso de que haya una falencia en cualquiera de los ítems mencionados, la Autorización se registrará como rechazada. Caso contrario, se registra como aprobada.

En caso de que se apruebe la autorización, se devuelve un número que representa el porcentaje de cobertura. Si se rechaza, dicho número será 0 (cero).

Si hay un error de cualquier tipo, se lanza una excepción conteniendo un mensaje que informa el error producido.

Se genera automáticamente los fundamentos de la resolución en caso de rechazo, y se registra junto con fechaResolucion = fechaDelSistema.

Para guardar siempre se hace uso de AutorizacionDataService.Guardar(Autorización).

Por último, se hace currentAutorizacion= autorizacionCreada.

3.3 SetResolucionAutorizacionManual

Firma y valor de retorno:

bool setResolucionAutorizacionManual(int codAutorizacion, String fundamentosResolucion, float porcentaje)

Descripción general:

Registra como aprobada o rechazada una autorización manual previamente guardada, junto con los fundamentos de la resolución, además graba quien la aprobó/rechazo.

Parámetros:

Nombre	Tipo	Descripción
codAutorizacion	Int	Código de la autorización a aprobar/rechazar.
fundamentosResolucion	String	Motivo por el que se aprueba/rechaza la autorización.
Porcentaje	Flota	Porcentaje de cobertura. 0 indíca rechazo.

Descripción detallada: Se invoca a AutorizacionDataService.obtener(codAutorizacion) para obtener la autorización en cuestión, se setea la fechaResulucion, los fundamentos de la resolución, el porcentaje de cobertura, y si se aprobó o rechazó la autorización (0 en porcentaje indica rechazo).

Además, se graba en nroLegajo del auditor que esta logeado. Para obtener el nroDeLegajo, primero se obtiene el nombre del usuario actual mediante userName=System.Environment.UserName, y después se le pasa a System.Security.Ldap.obtenerAtrubuto(userName,’workforceID’) que obtiene el número de legajo.

Luego se llama a AutorizacionDataService.actualizar (autorización) para actualizar los datos en la BD.

3.4 obtenerAutorizacionesPendientes

Firma y valor de retorno:

Autorizaciones[] obtenerAutorizacionesPendientes()

Descripción general:

Devuelve una lista de autorizaciones pendientes

Parámetros

Nombre	Tipo	Descripción
codAutorizacion	Int	Código de la autorización a aprobar/rechazar.
fundamentosResolucion	String	Motivo por el que se aprueba/rechaza la autorización.
Porcentaje	Flota	Porcentaje de cobertura. 0 indíca rechazo.

Descripción detallada:

Se llama simplemente a AutorizacionDataService.obtenerPendientes() quien hará un select de los campos donde fechaResolucion sea NULL.

3.5 consultarAfiliado

Firma y valor de retorno:

VistaSituacionAfiliado consultarAfiliado(codAdiliado,codPrestacion)

Descripción general:

Devuelve una instancia de VistaSituacionAfiliado conteniendo la situación actual del afiliado: Cuanto hace que es moroso, si su plan cubre la prestación solicitada, si cumple con las carencias.

Parámetros:

Nombre	Tipo	Descripción
codPrestacion	int	Código de prestación.
codAfiliado	int	Código de afiliado.

El valor de retorno, es “vistaSituacionAfiliado”, que es una clase con la siguiente estructura:

VistaSituacionAfiliado
Atributos
Nombre	Tipo	Visibilidad	Descripción
afiliado	Afiliado	Público	Será null si el código pasado por parámetro no existe. Desde la vista se podrá acceder a afiliado.Moroso para dar esta información, y se podrá acceder a afiliado.
limiteAnual	int	Público	Contendrá el limite que estipula la cobertura del afiliado, en cuanto a la cantidad de prestaciones que puede realizarse.
prestacionesRealizadas	Int	Público	Contendrá la cantidad de prestaciones realizadas, y también las aprobadas sin vencer a realizar.
porcentajeDeCobertura	Float	Público	El porcentaje de cobertura de la prestación solicitada.
carencia	Float	Público	Tiene la cantidad de meses que falta para que el afiliado pueda acceder a la prestacion solicitada. Será 0 si puede hacerlo ya.
Métodos
Ninguno

Descripción detallada:

Se revisan si los códigos existen mediante

AfiliadoDataService.existe(codAfiliado),

PrestacionDataService.existe(codPrestacion).

Si el código de prestación no existe, se lanza excepción con el mensaje de error.

Luego mediante AfiliadoDataService.Obtener(codAfiliado) y se asigna a vistaSituacionAfiliado.afiliado.

Después, se obtiene el limite anual haciendo cobertura=afiliado.Plan.obtenerCobertura(codPrestacion) y leyendo cobertura.LimiteAnual

Se obtiene el porcentaje de cobertura, y la cantidad de prestaciones realizadas con afiliado.consultarPrestacion(codPrestacion, cantidadDePrestaciones) (donde cantidadDePrestaciones es una variable de salida). Luego, se accede a afiliado.verificarCarencia(codPrestacion) y se asigna este valor a vistaSituacionAfiliado.carencia.

Ver especificación de clase de Afiliado para más detalles sobre los métodos de afiliado.

3.6 obtenerAutorizacionesPorAfiliado

Firma y valor de retorno:

Autorizacion[] obtenerAutorizacionPorAfiliado(int codAdiliado)

Descripción general:

Devuelve una lista de autorizaciones del afiliado solicitado por parámetro.

Parámetros:

Nombre	Tipo	Descripción
codAfiliado	int	Código de afiliado.

Descripción detallada:

Se revisan si el código existe mediante AfiliadoDataService.existe(codAfiliado),

Si no existe, se devuelve null.

Luego, usando AutorizacionDataService.obtenerPorAfiliado(codAfiliado) se obtiene la lista de autorizaciones a devolver. Este método hará internamente un select en autorizaciones, donde coincida el código de afiliado, con el pasado por parámetro.

Se devuelve la lista obtenida.

3.7 obtenerAutorizacionesPorAuditor

Firma y valor de retorno:

Autorizacion[] obtenerAutorizacionPorAuditor(int nroLegajo)

Descripción general:

Devuelve una lista de autorizaciones de aquellas que el auditor pasado por parámetro, haya resuelto.

Parámetros:

Nombre	Tipo	Descripción
nroLegajo	int	Número de legajo del auditor que aprobó/rechazo la autorización.

Descripción detallada:

Usando AutorizacionDataService.obtenerPorAuditor(codAuditor) se obtiene la lista de autorizaciones a devolver. Este método hará internamente un select en autorizaciones, donde coincida el número de legajo, con el pasado por parámetro.

Se devuelve la lista obtenida.

3.7 obtenerAutorizacionesPorFecha

Firma y valor de retorno:

Autorizacion[] obtenerAutorizacionPorFecha(Fecha fechaInicio, Fecha fechaFin)

Descripción general:

Devuelve una lista de autorizaciones de aquellas que se hayan solicitado entre las fechas pasadas por parámetro.

Parámetros:

Nombre	Tipo	Descripción
nroLegajo	int	Número de legajo del auditor que aprobó/rechazo la autorización.

Descripción detallada:

Usando AutorizacionDataService.obtenerPorFechaDeSolicitud(fechaInicio,fechaFin) se obtiene la lista de autorizaciones a devolver. Este método hará internamente un select en autorizaciones, donde el resultado debe ser aquellas autorizaciones con una fechaSolicitud mayor a fechaInicio, y menor a fechaFin.

Se devuelve la lista obtenida.

3.7 obtenerAutorizacion

Firma y valor de retorno:

Autorizacion obtenerAutorizacion(int codAutorizacion)

Descripción general:

Devuelve una lista de autorizaciones de aquellas que se hayan solicitado entre las fechas pasadas por parámetro.

Parámetros:

Nombre	Tipo	Descripción
codAutorizacion	int	Código de una autorización.

Descripción detallada:

Usando AutorizacionDataService.obtener (codAutorizacion) la autorización a devolver. Este método hará internamente un select en autorizaciones, a fin de obtener la autorización que se pasa por parámetro.

Se devuelve la autorización obtenida. Si el código no existe, AutorizacionDataService devolverá null, y este método también.

CapsController

Documento relacionado	Descripción
M01 - Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
M01 - Caso de Uso: Mantener CAPS	ABM de caps, utiliza extensivamente esta clase.

Paquete: Controlador

Responsabilidades:

Esta clase es la encargada de administrar las funciones relacionadas con los caps, brindando acceso a operaciones de ABM y de consulta.

Métodos:

existeCAP

Firma y valor de retorno:

existeCAP(codigo) : bool

Descripción general:

Verifica la existencia de un cap en la BD

Parámetros:

Nombre	Tipo	Descripción
Codigo	String	Código identificador del CAP

Descripción detallada:

Devuelve el resultado de la llamada a CAPDataService.existeCAP(codigo).

agregarCAP

Firma y valor de retorno:

agregarCAP(codigo,horario,calle,numero,piso,departamento,codigoPostal,provincia,telefono, idZona)

Descripción general:

Agrega un CAP al sistema

Parámetros:

Nombre	Tipo	Descripción
codigo	String	Código identificador del CAP
horario	String	Horario de atención del CAP
Calle	String	Calle domicilio
Numero	Int	Numero
Piso	Int	piso
Departamento	String	Dpto
codigoPostal	String(8)	Código postal
Provincia	String	Provincia
telefono	String	Teléfono
idZona	Int	Identificador de zona correspondiente a la dirección

Descripción detallada:

Se instancia una variable de la clase CAP llamada Dato. Se almacenan los datos pasados por parámetro:

Dato.Codigo= codigo

Dato.Horario = horario

Se instancia una variable de la clase Direccion llamada Dir y se carga:

Dir.Calle = calle

Dir.Numero = numero

Dir.Piso = piso

Dir.Departamento = departamento

Dir.CodigoPostal = codigoPostal

Dir.Provincia = provincia

Dir.IdZona = idZona

Y se carga la dirección del cap

Dato.direccion = Dir

Mediante la llamada a CAPDataService.agregar(Dato) se almacenan los datos en la BD.

modificarCAP

Firma y valor de retorno:

modificarCAP(codigo,horario, calle, numero, piso, departamento, codigoPostal, provincia, telefono, idZona)

Descripción general:

Modifica los datos del cap en la BD

Parámetros:

Nombre	Tipo	Descripción
Codigo	String	Código identificador del CAP
horario	String	Horario de atención del CAP
Calle	String	Calle domicilio
Numero	Int	Numero
Piso	Int	piso
Departamento	String	Dpto
codigoPostal	String(8)	Código postal
Provincia	String	Provincia
telefono	String	Teléfono
idZona	Int	Identificador de zona correspondiente a la dirección

Descripción detallada:

Se obtienen los datos del cap mediante la llamada a

CAPDataService.obtener(codigo) y se almacenan en una variable de la clase CAP llamada Dato. Se almacenan los datos pasados por parámetro:

Dato.Horario = horario

Se instancia una variable de la clase Direccion llamada Dir y se carga:

Dir.Calle = calle

Dir.Numero = numero

Dir.Piso = piso

Dir.Departamento = departamento

Dir.CodigoPostal = codigoPostal

Dir.Provincia = provincia

Dir.IdZona = idZona

Y se carga la dirección del cap

Dato.direccion = Dir

Mediante la llamada a CAPDataService.guardar(Dato) se almacenan los datos en la BD.

eliminarCAP

Firma y valor de retorno:

eliminarCAP(codigo) : bool

Descripción general:

Elimina un cap de la BD

Parámetros:

Nombre	Tipo	Descripción
Codigo	String	Código identificador del CAP

Descripción detallada:

Mediante la llamada a CAPDataService.obtener(codigo) se obtienen los datos del cap y se almacenan en una variable llamada Dato.

Se modifica la fecha de baja:

Dato.FechaBaja = fechaActual

Se almacenan los cambios mediante la llamada a CAPDataService.guardar(Dato).

obtenerCAP

Firma y valor de retorno:

obtenerCAP(codigo) : CAP

Parámetros:

Nombre	Tipo	Descripción
Codigo	String	Código identificador del CAP

Descripción detallada:

Se obtienen los datos del cap mediante la llamada a

CAPDataService.obtener(codigo) y se devuelven.

obtenerZonas

Firma y valor de retorno:

ObtenerZonas() : Zona[]

Descripción detallada:

Se obtienen los datos de las zonas almacenadas en el sistema mediante la llamada a ZonaDataService.obtenerTodas() y se devuelven en un vector.

asociarCAPconZona

Firma y valor de retorno:

asociarCAPconZona(idCAP,idZona[])

Descripción general:

Este método se encarga de asociar un identificador de cap a cada zona pasada por parámetro en el vector.

Parámetros:

Nombre	Tipo	Descripción
idCAP	Int	Identificador del CAP a asociar a la zona
idZona[]	vector de int	Identificadores de las zonas a asociar

Descripción detallada:

Para cada elemento del vector idZona:

Se obtienen los datos de la zona mediante la llamada a

ZonaDataService.obtener(idZona) y se almacenan en una variable llamada auxZona de tipo Zona.

Se modifica auxZona.idCAP = idCAP

Se guarda la modificación mediante la llamada a ZonaDataService.guardar(acusona)

obtenerZonasAsociadas

Firma y valor de retorno:

obtenerZonasAsociadas(idCAP) : Zona[]

Descripción general:

Este método se encarga de asociar un identificador de cap a cada zona pasada por parámetro en el vector.

Parámetros:

Nombre	Tipo	Descripción
idCAP	Int	Identificador del CAP a asociar a la zona

Descripción detallada:

Se obtienen las zonas asociadas a un CAP mediante la llamada a

ZonaDataService.obtenerZonasCAP(idCAP) y se devuelve el vector obtenido.

CarnetController

Paquete: Controlador

Responsabilidades: provee la funcionalidad para el armado del listado a enviar

Métodos:

3.1 cargarDatosAfiliados

Firma y valor de retorno:

cargarDatosAfiliados (fechaActual)

Descripción general:

Arma el listado con los datos de los afiliados cargados en el sistema en el día actual.

Parámetros:

Nombre	Tipo	Descripción
Fecha Actual	Fecha	Fecha actual

Descripción detallada:

Obtiene una colección de todos los afiliados ingresados en el día al sistema mediante la llamada a AfiliadoDataService.obtenerAfiliadosHoy() y la almacena en un vector auxiliar llamado aux.

Se carga el nodo principal (AFILIADOS) del archivo XML.

Para cada elemento del vector:

Se almacena el elemento en una variable llamada Dato de tipo Afiliado;

Se obtiene el código del plan mediante la llamada a PlanDataService.obtenerCodigo(Dato.idPlan) y se almacena en una variable llamada codigoPlan de tipo entero.

Se agrega al listado el siguiente nodo AFILIADO utilizando los siguientes datos:

Dato.CodigoAfiliado

Dato.Nombre

Dato.Apellido

codigoPlan

Dato.FechaAfiliacion

Dato.Direccion.Calle

Dato.Direccion.Numero

Dato.Direccion.Piso

Dato.Direccion.Departamento

Dato.Direccion.CodigoPostal

Dato.Direccion.Provincia

Dato.Direccion.Telefono

<AFILIADO>

<codigo>afiliado.Codigo</codigo>

<nombre>afiliado.nombre </nombre>

<apellido>afiliado.apellido</apellido>

<codigoPlan>codigoPlan</codigoPlan>

<fechaAfiliacion>Dato.fechaAfiliacion</fechaAfiliacion>

<direccion>

<calle>Afiliado.Direccion.Calle</calle>

<numero> Afiliado.Direccion.Numero</numero>

<piso> Afiliado.Direccion.Piso</piso>

<dpto> Afiliado.Direccion.Departamento</dpto>

<codPostal> Afiliado.Direccion.codigoPostal</codPostal>

<provincia> Afiliado.Direccion.Provincia</provincia>

<telefono> Afiliado.Direccion.Telefono</telefono>

</direccion>

</AFILIADO>

Una vez finalizada la carga de los elementos se cierra el archivo. Queda listo para ser enviado.

InterfazPrestadorController

Paquete: Controlador

Responsabilidades: Contiene los métodos que se exportarán mediante SOAP. Podrán ser llamados de manera remota. Conoce a: AutorizacionController,

Precondición para todos los métodos:

Primero se debe setear prestadorLogeado. Desde el modelo de seguridad, se asignará al instanciar esta clase, no podrá instanciarse si no se hace.

Métodos:

3.1 Logear

Firma y valor de retorno:

bool logear(String cuit, String password)

Descripción general:

Logea a un prestador para acceder a los servicios que presta la interfaz online.

Parámetros:

Nombre	Tipo	Descripción
cuit	String	CUIT del prestador. Formato: “11-11111111-1”
password	String	Password del prestador.

Descripción detallada:

Los password estarán grabados en el servidor de seguridad LDAP, asociado con el cuit que se usará como el típico nombre de usuario.

Para validar la password, se validará contra el servidor LDap, llamando a System.Security.Ldap.compararPasswordDePrestador(cuit,password)

Si el servidor nos constesta que no es un password y/o cuit valido, entonces se devuelve false.

Si esta todo ok, entonces primero se instancia a un prestador haciendo: PrestadorDataService.obtener(cuit); y esta instancia se asigna a prestadorLogeado, y luego se devuelve true.

3.1 evaluarAutorizacionAutomatica

Firma y valor de retorno:

AutorizacionAutomaticaResponse evaluarAutorizacionAutomaticaOnline(int codPrestacion, int codAfiliado)

Descripción general:

Recibe un pedido online de autorización automática, lo procesa y lo contesta.

Parámetros:

Nombre	Tipo	Descripción
codPrestacion	Int	Código de prestación.
codAfiliado	Int	Código de afiliado.

Descripción detallada:

-Se instancia AutorizacionController y se ejecuta autorizacionController.evaluarAutorizacionAutomatica(prestadorLoegeado.CuitPrestador, codPrestacion, codAfiliado):float

De acuerdo a lo que devuelva este método(*), se arma el valor de retorno de acuerdo al documento “Interfaz de autorizaciones con el prestador”

(*) Ver especificación de clase “AutorizaciónController”.

3.2 consultarAfiliado

Firma y valor de retorno:

AutorizacionManualResponse verificarAutorizacionManual(int codAfiliado, int codPrestacion)

Descripción general:

Consulta si una prestación debe ser automática o manual para un afiliado, o si este directamente no la tiene cubierta. No se hacen mayores validaciones, solo se consulta el plan. La verifiación de carencias, límites de prestaciones, morosidad, etc se harán al momento de autorizar. Aquí es solo a título “informativo”.

Parámetros:

Nombre	Tipo	Descripción
codPrestacion	Int	Código de prestación.
codAfiliado	Int	Código de afiliado.

Descripción detallada:

Se llama a AfiliadoDataService.obtener(código)

Una vez que se tiene la instancia de Afiliado, se hace afiliado.obtenerCobertura(codPrestacion), para obtener la cobertura de este afiliado con respecto a esa prestación. Si se obtiene null, será que no tiene cobertura para esta prestación, si se obtiene una prestación distinta de null, entonces se irá leyendo los atributos de esta instancia de “Cobertura”, a fin de armar el valor de retorno de acuerdo al documento de: “Especificación de Interfaz online con el Prestador”, una vez hecho esto, se devuelve.

PlanesController

Paquete: Controlador

Responsabilidades:

Esta clase es la encargada de administrar las funciones relacionadas con los planes, brindando acceso a operaciones de ABM y de consulta.

Métodos:

crearPlan

Firma y valor de retorno:

crearPlan(descripción,categoría,permanenciaMinima): int

Descripción general:

Crea el nuevo plan realizando validaciones sobre los parámetros recibidos.

Parámetros:

Nombre	Tipo	Descripción
descripcion	string	Descripcion del nuevo plan.
categoria	float	Número identificatorio de la categoría
permanenciaMinima	float	Permanencia Mínima del nuevo plan en meses.

Descripción detallada:

Se validan los parámetros:

La categoría no debe existir, para eso se hace una llamada recursiva a existeCategoria, si esta retorna true se arroja excCatExiste . Además se valida que la categoría sea un número mayor o igual a cero, si no cumple, se arroja excCatInval..

permanenciaMinima debe ser mayor o igual a cero, si no cumple, se arroja excPermMinInval..

Si alguno de los parámetros resulta inválido, se arroja una excepción de acuerdo a la validación que haya fallado. Dicha excepción es un valor enumerado de acuerdo al siguiente tipo: excPlan = enum {excCatExiste, excCatInval, excPermMinInval}

Si los datos son válidos, se invoca a nuevoPlan con los mismos parámetros y devuelve el resultado de dicho método (que es el código del nuevo plan).

existeCategoria

Firma y valor de retorno:

existeCategoria(categoría): bool

Descripción general:

Busca en los planes existentes en el sistema si existe la categoría recibida por parámetro.

Parámetros:

Nombre	Tipo	Descripción
categoria	float	Número identificatorio de la categoría

Descripción detallada:

Obtiene todos los planes vigentes del sistema mediante la llamada a PlanesController.obtenerPlanesVigentes().

Compara las categorías de los planes con la que se recibe por parámetro, si existe coincidencia con alguna devuelve true y en caso contrario devuelve false.

nuevoPlan

Firma y valor de retorno:

nuevoPlan(descripción,categoría,permanenciaMinima): int

Descripción general:

Crea un nuevo plan con los datos recibidos por parámetro y lo almacena en la BD. Devuelve el código asignado al nuevo plan.

Parámetros:

Nombre	Tipo	Descripción
descripcion	string	Descripcion del nuevo plan.
categoria	float	Categoría del nuevo plan.
permanenciaMinima	float	Permanencia Mínima del nuevo plan en meses.

Descripción detallada:

Crea una nueva instancia de Plan.

Asigna a los atributos del plan los valores recibidos por parámetro, cero a fechaBaja y a código.

Almacena el nuevo plan invocando a PlanDataService.agregar(plan).

Si se almaceno correctamente el objeto plan se modifica en su atributo código con el valor que le asigno la clase de persistencia (que lo maneja como un autoincremental). Devuelve dicho valor como resultado o 0 en caso de que haya fallado el almacenamiento en la BD.

desactivarPlan

Firma y valor de retorno:

desactivarPlan(): bool

Descripción general:

Efectua la baja lógica del plan referenciado por currentPlan. Esto implica que no se tomaran mas afiliados para dicho plan pero aquellos que aun pertenezcan al mismo seguirán con las misma condiciones.

Parámetros:

Ninguno.

Descripción detallada:

Si currentPlan == NULL, retorna false.

Borra el plan actual mediante currentPlan.desactivar()

Almacena el plan borrado PlanDataService.guardar(currentPlan)

Setea currentPlan = NULL y devueltre true.

actualizarPlan

Firma y valor de retorno:

actualizarPlan(descripción,categoría,permanenciaMinima): bool

Descripción general:

Actualiza los datos del plan actual con los valores recibidos por parámetro

Parámetros:

Nombre	Tipo	Descripción
descripción	string	Descripción del plan.
categoría	float	Categoría del plan.
permanenciaMinima	float	Permanencia mínima del plan en meses.

Descripción detallada:

Si currentPlan == NULL, retorna false.

Se validan los parámetros:

La categoría no debe existir, para eso se hace una llamada recursiva a existeCategoria, si esta retorna true se arroja excCatExiste . Además se valida que la categoría sea un número mayor o igual a cero, si no cumple, se arroja excCatInval.

permanenciaMinima debe ser mayor o igual a cero, si no cumple, se arroja excPermMinInval.

Modifica los atributos del plan con los valores recibidos por parámetro:

currentPlan.descripcion = descripción

currentPlan.categoria = categoría

currentPlan.permanenciaMinima = permanenciaMinima

Almacena el plan modificado PlanDataService.guardar(currentPlan)

makeCurrent

Firma y valor de retorno:

makeCurrent(codPlan): bool

Descripción general:

Setea como plan actual (currentPlan) el plan con código codPlan.

Parámetros:

Nombre	Tipo	Descripción
codPlan	int	Código del plan que se quiere hacer actual.

Descripción detallada:

currentPlan = PlanDataService.obtener(codPlan)

Si currentPlan != NULL devuelve true, caso contrario devuelve false.

obtenerPlanesVigentes

Firma y valor de retorno:

obtenerPlanesVigentes(): Plan[]

Descripción general:

Retorna una colección de instancias de Plan de los planes vigentes en el sistema (aquellos cuya fecha de baja es NULL).

Parámetros:

No tiene.

Descripción detallada:

Obtiene una colección de todos los planes del sistema (planes[]) mediante PlanDataService.obtenerTodos()

Devuelve la referencia de aquellos planes en los que fechaBaja sea NULL.

obtenerPlanesInactivos

Firma y valor de retorno:

obtenerPlanesInactivos(): Plan []

Descripción general:

Retorna una colección de instancias de Plan de los planes inactivos en el sistema (aquellos cuya fecha de baja es distinta de NULL)

Parámetros:

No tiene.

Descripción detallada:

Obtiene una colección de todos los planes del sistema (planes[]) mediante PlanDataService.obtenerTodos()

Devuelve la referencia de aquellos planes en los que fechaBaja sea distinta de NULL.

importarCoberturas

Firma y valor de retorno:

importarCoberturas(codPlanOrig): bool

Descripción general:

Importa las coberturas del plan con código codPlanOrig al plan actual.

Parámetros:

Nombre	Tipo	Descripción
codPlanOrig	int	Código del plan desde el que se desea importar.

Descripción detallada:

Si currentPlan == NULL retorna false.

Crea la instancia del Plan original:

planO = PlanDataService.obtener(codPlanOrig)

Itera sobre la colección de coberturas del planO, creando nuevas coberturas con los mismos valores que los del plan original

coberturaN = new Cobertura(planO.obtenerCoberturas()[i])

e intenta agregarlas al plan actual:

currentPlan.agregarCobertura(coberturaN).

En caso de fallar la inserción porque ya existe una cobertura para la prestación dentro del plan, se arroja una excepción (excImpCob) que contiene codPlan[] con los planes que poseen una cobertura sobre la prestación y codPrestacion.

Si se realizaron con éxito las importaciones, se guarda en la BD

PlanDataService.guardar(currentPlan) y retorna true.

agregarCobertura

Firma y valor de retorno:

agregarCobertura(codPrestacion, carencia, porcentaje, limiteAnual, tipoAutorización): bool

Descripción general:

Crea una nueva cobertura sobre la prestación con código codPrestacion para el plan actual.

Parámetros:

Nombre	Tipo	Descripción
codPrestacion	Int	Código de la prestación.
carencia	float	Tiempo de carencia en meses.
porcentaje	float	Porcentaje de cobertura sobre la prestación.
limiteAnual	int	Cantidad máxima de prestaciones cubiertas por año.
tipoAutorizacion	enum{manual,auto}	Tipo de autorización.

Descripción detallada:

Si currentPlan == NULL retorna false.

Valida los parámetros arrojando una excepción de tipo: excCob = enum {excCarencInval, excPorcentInval, excLimAnInval}, en caso de que falle alguna de las validaciones:

Si carencia es menor o igual a cero arroja excCarencInval .

Si porcentaje es menor o igual a cero arroja excPorcentInval.

Si limiteAnual es menor o igual a cero arroja excLimAnInval.

Crea una nueva instancia de Cobertura:

cobertura = new Cobertura(codPlan,codPrestacion, carencia,porcentaje,limiteAnual,tipoAutorizacion)

con sus atributos seteados con los valores recibidos por parámetro.

Intenta agregarla la cobertura al plan actual:

currentPlan.agregarCobertura(cobertura)

En caso de fallar la inserción porque ya existe una cobertura para la prestación dentro del plan, se arroja una excepción que contiene el codPrestacion (excCobExist).

Si se realizaron con éxito las importaciones, se guarda en la BD

PlanDataService.guardar(currentPlan) y retorna true.

actualizarCobertura

Firma y valor de retorno:

actualizarCobertura(codPrestacion, carencia, porcentaje, limiteAnual, tipoAutorización): bool

Descripción general:

Actualiza la cobertura sobre una prestación que tiene el plan actual. La cobertura debe existir en el plan.

Parámetros:

Nombre	Tipo	Descripción
codPrestacion	int	Código de la prestación.
carencia	float	Tiempo de carencia en meses.
porcentaje	float	Porcentaje de cobertura sobre la prestación.
limiteAnual	int	Cantidad máxima de prestaciones cubiertas por año.
tipoAutorizacion	enum{manual,auto}	Tipo de autorización.

Descripción detallada:

Si currentPlan == NULL retorna false.

Se validan los parámetros:

Si carencia es menor o igual a cero arroja excCarencInval .

Si porcentaje es menor o igual a cero arroja excPorcentInval.

Si limiteAnual es menor o igual a cero arroja excLimAnInval.

Obtiene la cobertura mediante currentPlan.ObtenerCobertura(codPrestacion).

En caso de encontrar la cobertura modifica los atributos con los valores recibidos por parámetro, persiste los cambios invocando PlanDataService.guardar(currentPlan) y devuelve true.

De no encontrar la cobertura porque no esta asociada con el plan, devuelve false.

obtenerCoberturas

Firma y valor de retorno:

obtenerCoberturas(): Cobertura []

Descripción general:

Devuelve una colección de Cobertura representando las coberturas que tiene el plan actual.

Parámetros:

Ninguno.

Descripción detallada:

Si currentPlan == NULL devuelve NULL.

Devueve el resultado del método currentPlan.ObtenerCoberturas()

obtenerCobertura

Firma y valor de retorno:

obtenerCobertura (codPrestacion) : Cobertura

Descripción general:

Devuelve la cobertura asociada al plan actual y a la prestación con código codPrestacion

Parámetros:

Nombre	Tipo	Descripción
codPrestacion	Int	Código de la prestación.

Descripción detallada:

Si currentPlan == NULL devuelve NULL

Itera sobre las coberturas del currentPlan hasta encontrar aquella con código igual a codPrestación. Si la encuentra, devuelve una referencia a la misma.

Si no la encuentra, devuelve NULL.

PrestacionesController

Documento relacionado	Descripción
M01 - Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
M01 - Caso de Uso: Mantener Prestaciones	ABM de prestaciones, utiliza extensivamente esta clase.
M01 - Diagrama de Paquetes controladores	
M05 – Especificación Archivo de prestaciones	Especificación del archivo

1.	Paquete: Controlador

2.	Responsabilidades:

Esta clase es la encargada de administrar las funciones relacionadas con las prestaciones, brindando acceso a operaciones de ABM y de consulta.

3.	Métodos:

3.1	actualizarPrestacion

a.	Firma y valor de retorno:

actualizarPrestacion( codigoPrestacion, nombrePrestacion, codigoCategoria, nombreCategoria

modificador) : bool

b.	Descripción general:

Realiza el ABM de una prestación según el modificador pasado por parámetro

c.	Parámetros:

Nombre	Tipo	Descripción
codigoPrestacion	Int	Código de la prestación
nombrePrestacion	String	Nombre de la prestación
codigoCategoria	Int	Código de la categoría a la que pertenece la prestación.
nombreCategoria	String	Nombre de la categoría.
modificador	Char	Modificador (A-B-M)

d.	Descripción detallada:

Si modificador = ‘A’

·	Se verifica la existencia en el sistema de la categoría mediante la llamada a CategoriaDataService.existe(nombre).

Si devuelve false:

se instancia una Categoria y se cargan los datos:

categoria.nombre = nombreCategoria

categoria.codigo = codigoCategoria

El atributo categoria.fechaBaja se deja en null.

se agrega la categoria al sistema mediante la llamada a CategoriaDataService.agregar(categoria).

· Se instancia una Prestación y se cargan los datos:

prestacion.nombre = nombrePrestacion

prestacion.codigo = codigoPrestacion

El atributo prestacion.fechaBaja se deja en null.

Se obtiene el identificador de categoria mediante la llamada a CategoriaDataService.obtener(codigoCategoria), la categoría existía previamente o fue dada de alta recién en el sistema.

prestacion.idCategoria = categoria.id

·	Luego se almacena en la tabla Prestación lo datos mediante la llamada aPrestacionDataService.agregar(prestacion).

Si modificador = ‘B’

·	Se llama al método PrestacionDataService.eliminar(codigoPrestacion), que se encarga de marcar la fecha de baja de la prestación (utilizando para eso la fecha actual) y idCategoria = null. También se llama al método CategoriaDataService.eliminar(codigoCategoria), que se encarga de hacer lo mismo con la categoría de la prestación, siempre y cuando no exista otra prestación asociada a ella.

Si modificador =’M’

· Se verifica la existencia en el sistema de la categoría mediante la llamada a CategoriaDataService.existe(nombre).

Si devuelve false:

se instancia una Categoria y se cargan los datos:

categoria.nombre = nombreCategoria

categoria.codigo = codigoCategoria

El atributo categoria.fechaBaja se deja en null.

se agrega la categoria al sistema mediante la llamada a CategoriaDataService.agregar(categoria).

· Se obtienen los datos de la categoría mediante la llamada a CategoriaDataService.obtener(codigoCategoria) y se almacenan en una variable Categoria de tipo Categoria.

·	Se recuperan los datos de la prestación llamando a

PrestacionDataService.obtener (codigoPrestacion) y se almacenan en una instancia de la clase

Prestacion llamada Prestacion.

·	Se modifica:

Prestacion.nombre = nombrePrestacion

Prestacion.idCategoria = Categoria.id

Se llama al método PrestacionDataService.guardar (prestacion)

·	Si categoria.nombre es distinto a nombreCategoria se modifica el nombre de la misma y se llama a CategoriaDataService.guardar(categoria)

Si algún paso falla devolverá false, caso contrario devolverá true.

3.2	obtenerPrestaciones

a.	Firma y valor de retorno:

obtenerPrestaciones() : Prestacion []

b.	Descripción general:

Obtiene una colección de los datos de las prestaciones almacenadas en el sistema

c.	Descripción detallada:

Obtiene una colección de los datos de las prestaciones almacenadas en el sistema:

·	Mediante la llamada a PrestacionesDataService.obtenerTodas() obtiene una colección de todas las instancias de Prestacion

·	Por cada instancia de Prestacion, llama a PrestacionesController.obtenerDetalles(prestacion.codigo) y agrega el resultado a la colección de retorno.

3.3	cargarDatosArchivo

a.	Firma y valor de retorno:

cargarDatosArchivo (path_archivo) : bool

b.	Descripción general:

Realiza todas las validaciones referidas al archivo que contiene los datos de las prestaciones

c.	Parámetros:

Nombre	Tipo	Descripción
Path_archivo	String	Ubicación del archivo a cargar en el sistema

d.	Descripción detallada:

Realiza todas las validaciones referidas al archivo que contiene los datos de las prestaciones:

·	Verifica que el path recibido cumple con el nombre que debe tener el archivo.

·	Para cada registro del archivo realiza todas las validaciones referidas al archivo que contiene los datos de las prestaciones llamando a verificarRegistro(stringRegistro), si devuelve true se verifica el siguiente registro hasta llegar al fin, caso contrario el método devuelve false

·	Una vez verificados todos los registros para cada uno de ellos se llama a actualizarPrestacion ( codigoPrestacion, nombrePrestacion, codigoCategoria, nombreCategoria, modificador)

Si algún paso falla devolverá false, caso contrario devolverá true.

3.4	obtenerDetalles

a.	Firma y valor de retorno:

obtenerDetalles(codPrestacion) : Prestacion

b.	Descripción general:

Realiza todas las validaciones referidas al archivo que contiene los datos de las prestaciones

c.	Parámetros:

Nombre	Tipo	Descripción
codigoPrestacion	Int	Código de la prestación de la cual se quieren los detalles

d.	Descripción detallada:

Se crea una nueva instancia de Prestacion

prestacion = new Prestacion(PrestacionDataService.obtener(codPrestacion))

Se devuelve la instancia de la prestacion

3.5	obtenerPrestadores

a.	Firma y valor de retorno:

obtenerPrestadores(codPrestacion) : Prestador[]

b.	Descripción general:

Consulta en el sistema todos los prestadores que brindan la prestación con el código recibido por parámetro, y devuelve una instancia de Prestador por cada uno de ellos.

c.	Parámetros:

Nombre	Tipo	Descripción
codigoPrestacion	Int	Código de la prestación de la cual se quieren los detalles

d.	Descripción detallada:

Se obtiene la coleccíon de Prestadores que brindan la prestación a través del método PrestacionDataService.obtenerPrestadores(codPrestacion).

Se devuelve la colección de retorno de Prestador.

3.6	verificarRegistro

a.	Firma y valor de retorno:

verificarRegistro(stringRegistro): bool

b.	Descripción general:

Verifica el formato del registro obtenido

c.	Parámetros:

Nombre	Tipo	Descripción
stringRegistro	String	Registro del archivo de prestaciones

d.	Descripción detallada:

·	Controla la estructura del registro, que debe poseer los campos:

·	codigoPrestacion: alfanumérico de hasta 7 caracteres

·	nombrePrestacion: cadena de hasta 200 caracteres.

·	codigoCategoria: alfanumérico de hasta 7 caracteres

·	nombreCategoria: cadena de hasta 200 caracteres.

·	modificador: char A-B-M

·	Si falla la verificación el método devuelve false, caso contrario devuelve true.

PrestadoresController

Documento relacionado	Descripción
M01 - Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
M01 - Caso de Uso: Mantener Prestadores	ABM de prestadores, utiliza extensivamente esta clase.

Paquete: Controlador

Responsabilidades:

Esta clase es la encargada de administrar las funciones relacionadas con los prestadores, brindando acceso a operaciones de ABM y de consulta.

Métodos:

existePrestador

Firma y valor de retorno:

existePrestador(CUIT) : bool

Descripción general:

Verifica la existencia de un prestador en la BD

Parámetros:

Nombre	Tipo	Descripción
CUIT	String	CUIT del prestador

Descripción detallada:

Devuelve el resultado de la llamada a PrestadorDataService.existePrestador(CUIT).

agregarPrestador

Firma y valor de retorno:

agregarPrestador(CUIT,nombre,eMail,calle,numero,piso,departamento,codigoPostal,provincia,telefono,idZona)

Descripción general:

Agrega un prestador al sistema

Parámetros:

Nombre	Tipo	Descripción
CUIT	String	CUIT del prestador
Nombre	string	Nombre
eMail	String	Email
Calle	String	Calle domicilio
Numero	Int	Numero
Piso	Int	piso
Departamento	String	Dpto
codigoPostal	String(8)	Código postal
Provincia	String	Provincia
telefono	String	Teléfono
idZona	Int	Identificador de zona correspondiente a la dirección

Descripción detallada:

Se instancia una variable de la clase Prestador llamada Dato. Se almacenan los datos pasados por parámetro:

Dato.CUIT = CUIT

Dato.nombre = nombre

Dato.EMail = eMail

Se instancia una variable de la clase Direccion llamada Dir y se carga:

Dir.Calle = calle

Dir.Numero = numero

Dir.Piso = piso

Dir.Departamento = departamento

Dir.CodigoPostal = codigoPostal

Dir.Provincia = provincia

Dir.IdZona = idZona

Y se carga la dirección del prestador

Dato.direccion = Dir

Mediante la llamada a PrestadorDataService.agregar(Dato) se almacenan los datos en la BD.

modificarPrestador

Firma y valor de retorno:

modificarPrestador(CUIT,eMail,calle,numero,piso,departamento,codigoPostal,provincia,telefono,idZona)

Descripción general:

Modifica los datos del prestador en la BD

Parámetros:

Nombre	Tipo	Descripción
CUIT	String	CUIT del prestador
eMail	String	Email
Calle	String	Calle domicilio
Numero	Int	Numero
Piso	Int	piso
Departamento	String	Dpto
codigoPostal	String(8)	Código postal
Provincia	String	Provincia
telefono	String	Teléfono
idZona	int	Identificador de zona correspondiente a la dirección

Descripción detallada:

Se obtienen los datos del prestador mediante la llamada a

PrestadorDataService.obtener(CUIT) y se almacenan en una variable de la clase Prestador llamada Dato. Se almacenan los datos pasados por parámetro:

Dato.EMail = eMail

Se instancia una variable de la clase Direccion llamada Dir y se carga:

Dir.Calle = calle

Dir.Numero = numero

Dir.Piso = piso

Dir.Departamento = departamento

Dir.CodigoPostal = codigoPostal

Dir.Provincia = provincia

Dir.IdZona = idZona

Y se carga la dirección del prestador

Dato.direccion = Dir

Mediante la llamada a PrestadorDataService.guardar(Dato) se almacenan los datos en la BD.

eliminarPrestador

Firma y valor de retorno:

eliminarPrestador(CUIT) : bool

Descripción general:

Elimina un prestador de la BD

Parámetros:

Nombre	Tipo	Descripción
CUIT	String	CUIT del prestador

Descripción detallada:

Mediante la llamada a PrestadorDataService.obtener(CUIT) se obtienen los datos del prestador y se almacenan en una variable llamada Dato.

Se modifica la fecha de baja:

Dato.FechaBaja = fechaActual

Se almacenan los cambios mediante la llamada a PrestadorDataService.guardar(Dato).

obtenerPrestador

Firma y valor de retorno:

obtenerPrestador(CUIT) : Prestador

Parámetros:

Nombre	Tipo	Descripción
CUIT	String	CUIT del prestador

Descripción detallada:

Se obtienen los datos del prestador mediante la llamada a

PrestadorDataService.obtener(CUIT) y se devuelven.

obtenerZonas

Firma y valor de retorno:

ObtenerZonas() : Zona[]

Descripción detallada:

Se obtienen los datos de las zonas almacenadas en el sistema mediante la llamada a ZonaDataService.obtenerTodas() y se devuelven en un vector.

PromotoresController

Documento relacionado	Descripción
M01 - Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
M01 - Caso de Uso: Mantener Promotores	ABM de promotores, utiliza extensivamente esta clase.

Paquete: Controlador

Responsabilidades:

Esta clase es la encargada de administrar las funciones relacionadas con los promotores, brindando acceso a operaciones de ABM y de consulta.

Métodos:

existePromotor

Firma y valor de retorno:

existePromotor(tipoDoc,nroDoc) : bool

Descripción general:

Verifica la existencia de un promotor en la BD

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del promotor
nroDoc	int	Número de documento del promotor

Descripción detallada:

Devuelve el resultado de la llamada a PromotorDataService.existePromotor(tipoDoc,nroDoc).

agregarPromotor

Firma y valor de retorno:

agregarPromotor(tipoDoc,nroDoc,nombre,apellido,fechaNacimiento,eMail,calle,numero,piso,departamento,codigoPostal,provincia,telefono,sexo,idZona)

Descripción general:

Agrega un promotor al sistema.

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del promotor
nroDoc	int	Número de documento del promotor
Nombre	string	Nombre
Apellido	String	Apellido
fechaNacimiento	Fecha	Fecha de nacimiento
eMail	String	Email
Calle	String	Calle domicilio
Numero	Int	Numero
Piso	Int	piso
Departamento	String	Dpto
codigoPostal	String(8)	Código postal
Provincia	String	Provincia
telefono	String	Teléfono
sexo	Enum(F,M)	Sexo
idZona	Int	Identificador de zona correspondiente a la dirección

Descripción detallada:

Se instancia una variable de la clase Promotor llamada Dato. Se almacenan los datos pasados por parámetro:

Dato.TipoDocumento = tipoDoc

Dato.NroDocumento = nroDoc

Dato.nombre = nombre

Dato.apellido = apellido

Dato.Sexo = sexo

Dato.FechaNacimiento = fechaNacimiento

Dato.EMail = eMail

Se instancia una variable de la clase Direccion llamada Dir y se carga:

Dir.Calle = calle

Dir.Numero = numero

Dir.Piso = piso

Dir.Departamento = departamento

Dir.CodigoPostal = codigoPostal

Dir.Provincia = provincia

Dir.IdZona = idZona

Y se carga la dirección del promotor

Dato.direccion = Dir

Mediante la llamada a PromotorDataService.agregar(Dato) se almacenan los datos en la BD.

modificarPromotor

Firma y valor de retorno:

modificarPromotor(tipoDoc,nroDoc, eMail,calle,numero,piso,departamento,codigoPostal,provincia,telefono,idZona)

Descripción general:

Modifica los datos del promotor en la BD

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del promotor
nroDoc	int	Número de documento del promotor
eMail	String	Email
Calle	String	Calle domicilio
Numero	Int	Numero
Piso	Int	piso
Departamento	String	Dpto
codigoPostal	String(8)	Código postal
Provincia	String	Provincia
telefono	String	Teléfono
idZona	int	Identificador de zona correspondiente a la dirección

Descripción detallada:

Se obtienen los datos del promotor mediante la llamada a

PromotorDataService.obtener(tipoDoc,nroDoc) y se almacenan en una variable de la clase Promotor llamada Dato. Se almacenan los datos pasados por parámetro:

Dato.EMail = eMail

Se instancia una variable de la clase Direccion llamada Dir y se carga:

Dir.Calle = calle

Dir.Numero = numero

Dir.Piso = piso

Dir.Departamento = departamento

Dir.CodigoPostal = codigoPostal

Dir.Provincia = provincia

Dir.IdZona = idZona

Y se carga la dirección del promotor

Dato.direccion = Dir

Mediante la llamada a PromotorDataService.guardar(Dato) se almacenan los datos en la BD.

eliminarPromotor

Firma y valor de retorno:

eliminarPromotor(tipoDoc,nroDoc) : bool

Descripción general:

Elimina un promotor de la BD

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del promotor
nroDoc	int	Número de documento del promotor

Descripción detallada:

Mediante la llamada a PromotorDataService.obtener (tipoDoc,nroDoc) se obtienen los datos del promotor y se almacenan en una variable llamada Dato.

Se modifica la fecha de baja:

Dato.FechaBaja = fechaActual

Se almacenan los cambios mediante la llamada a PromotorDataService.guardar(Dato).

obtenerPromotor

Firma y valor de retorno:

obtenerPromotor(tipoDoc,nroDoc) : Promotor

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo de documento del promotor
nroDoc	int	Número de documento del promotor

Descripción detallada:

Se obtienen los datos del promotor mediante la llamada a

PromotorDataService.obtener(tipoDoc,nroDoc) y se devuelven.

obtenerZonas

Firma y valor de retorno:

ObtenerZonas() : Zona[]

Descripción detallada:

Se obtienen los datos de las zonas almacenadas en el sistema mediante la llamada a ZonaDataService.obtenerTodas() y se devuelven en un vector.

RecibirPrestacionesController

Ref.	Documento relacionado	Descripción
R1	Todos los Diagramas de clases: controladores, dominio, persistencia, reportes.	Diagramas de clases, con los atributos y la firma de los métodos.
R2	Especificaciones de clases: InfoPrestacionesAdmin, NotificacionesAdmin	Especificación de clase, administradoras de reportes y de notificaciones
R3	Especificaciones de clases: InfoPrestacionesReport, LineaInfoPrestacionesReport, ConsumoAfiliadosReport, PrestacionesRealizadasReport	Especificación de clases que representan reportes
R4	Especificación de clase: Autorizacion	Especificación de clase
R5	Diagrama de estados: Autorización Manual Diagrama de estados: Autorización Automática	Diagrama de los estados, transiciones y eventos relevantes relacionados con una autorización.
R6	Especificación de CU: Recibir y Cotejar Consumos y Prestaciones	Caso de uso controlado por ésta clase
R7	Especificación de Interfaces con el Prestador	Interfaz con el Prestador, describiendo comunicación, formato, medio, periodicidad.
R8	Especificación de Interfaces con sector Pagos	Interfaz con Pagos, describiendo comunicación, formato, medio, periodicidad.

Paquete: Controlador

Responsabilidades:

Ésta clase es la encargada de llevar a cabo el caso de uso “Recibir y Cotejar Consumos y Prestaciones”, ofreciendo la funcionalidad de chequear la información enviada por el prestador y manipularla.

Hace uso de la clase InfoPrestacionesAdmin para crear una representación de la información enviada por el prestador (clase InfoPrestacionesReport) y para generar los reportes a enviar a Pagos.

Cada instancia de ésta clase mantiene una instancia de un reporte de consumo (ConsumoAfiliadosReport) y de un informe de aprobaciones/rechazos de prestaciones realizadas (PrestacionesRealizadasReport).

Usa las clases InfoPrestacionesReport y LineaInfoPrestacionesReport para averiguar la validez de los datos en el informe recibido.

Utiliza la clase AutorizacionDataService para actualizar el estado de una autorización realizada en el Sistema.

Métodos:

procesarInfoRecibida()

Firma y valor de retorno:

void procesarInfoRecibida()

Descripción general:

Éste método es el que se llama al dispararse el evento periódico (ver R7) para procesar los archivos recibidos. Chequea y procesa los archivos que estén disponibles en el sitio FTP.

Parámetros: No tiene

Descripción detallada:

Obtiene todos los prestadores registrados en el Sistema, por medio del método PrestadorDataService.obtenerTodos()

Por cada prestador, obtiene todos los archivos que estén pendientes de procesar para cada prestador, usando InfoPrestacionesAdmin.getInfoPendiente( prestador )

Si no hay informes pendientes de procesar para ese prestador, se le envía una notificación al Prestador y también al sector Pagos indicando que en el último día no se recibieron archivos del prestador en cuestión. Lo hace mediante NotificacionesAdmin.notificarPrestador( “NoRecibido” ) y NotificacionesAdmin.notificarPagos( prestador, “NoRecibido” ).

Por cada archivo obtenido en ii , representado mediante un objeto de la clase InfoPrestacionesReport:

Valida el formato, aplicándolo contra el XML Schema, llamando al método InfoPrestacionesReport.validarFormato()

Si el formato no es el correcto, ó si el CUIT del prestador contenido en el archivo recibido no coincide con el CUIT del prestador en proceso, mueve el archivo a un directorio de rechazados con InfoPrestacionesAdmin.moverArchivoRechazado( infoPresReport ) ; y además notifica al Prestador y a Pagos acerca del error (con métodos de InfoPrestacionesAdmin )

Si el formato y el CUIT son correctos, se validan y marcan como aprobadas/rechazadas todas las líneas del informe en proceso, mediante InfoPrestacionesReport.validarLineas(). Luego se procesan las líneas validadas:

Para línea Aprobada registra en el sistema, para la autorización asociada a la línea, la fecha de realización de la prestación, con AutorizacionDataService.guardar( aut ) ; y además se la agrega al reporte de Consumo.

La info de todas las líneas se agrega en el reporte de aprobaciones/rechazos de prestaciones realizadas

Se mueve el archivo a un directorio de documentos aceptados, usando InfoPrestacionesAdmin.moverArchivoAceptado( infoPrestacionesReport ).

Se notifica al Prestador el éxito del proceso (que no hubo errores graves) llamando a NotificacionesAdmin.notificarPrestador( “Ok”, nombreArchivo )

Se envían los reportes de Consumo y de Aprobaciones/Rechazos al sector Pagos, usando los métodos InfoPrestacionesAdmin.EnviarReporte( reporteConsumo) y InfoPrestacionesAdmin.EnviarReporte( reporteAprobaciones)

RegistrarVisitasController

Documento relacionado	Descripción
Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
Caso de Uso: Registrar Visitas	Especificación del CU

Paquete: Controlador

Responsabilidades:

Esta clase es la encargada de proveer los métodos necesarios para que se ejecute el CU Registrar Visitas.

Métodos:

obtenerSolicitantesAsignados

Firma y valor de retorno:

obtenerSolicitantesAsignados(tipoDoc, nroDoc): Solicitante[]

Descripción general:

Obtiene los solicitantes que el promotor debía visitar.

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del promotor
nroDoc	int	Número de documento del promotor

Descripción detallada:

Con el tipo y número de documento se obtiene el código del promotor mediante la llamada a PromotorDataService.obtenerCodigo(tipoDoc,nroDoc). Este código se almacena en la variable auxiliar codigoPromotor.

Mediante la llamada a SolicitanteDataService.obtenerSolicitantesAsignados(codigoPromotor) se obtiene una lista con instancias de la clase Solicitante y se devuelve

establecerPendiente

Firma y valor de retorno:

establecerPendiente(tipoDoc, nroDoc) : bool

Descripción general:

Registra en el sistema que el solicitante no fue visitado

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del solicitante.
nroDoc	int	Número de documento del solicitante

Descripción detallada:

Se obtienen los datos del solicitante mediante la llamada a SolicitanteDataService.obtener(tipoDoc,nroDoc) y se almacenan en una instancia auxiliar de la clase Solicitante llamada dato.

Se modifica el atributo pendiente y idPromotor: dato.pendiente = true y dato.idPromotor = null. Se almacenan los cambios mediante la llamada a SolicitanteDataService.guardar(dato)

Si algún paso fallara, el método devuelve FALSE, caso contrario devuelve TRUE

visitado

Firma y valor de retorno:

visitado(tipoDocSolicitante, nroDocSolicitante)

Descripción general:

Establece al solicitante como visitado

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del solicitante
nroDoc	int	Número de documento del solicitante

Descripción detallada:

Se obtienen los datos del solicitante mediante la llamada a SolicitanteDataService.obtener(tipoDoc,nroDoc) y se almacenan en una instancia auxiliar de la clase Solicitante llamada dato.

Se modifica el atributo pendiente: dato.pendiente = false. Se almacenan los cambios mediante la llamada a SolicitanteDataService.guardar(dato)

obtenerCantidadFamiliares

Firma y valor de retorno:

obtenerCantidadFamiliares(tipoDocSolicitante, nroDocSolicitante): int

Descripción general:

Obtiene la cantidad de familiares asignada a un solicitante

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del solicitante
nroDoc	int	Número de documento del solicitante

Descripción detallada:

Se obtienen los datos del solicitante mediante la llamada a SolicitanteDataService.obtener(tipoDoc,nroDoc) y se almacenan en una instancia auxiliar de la clase Solicitante llamada dato. Se devuelve el atributo dato.familiares.

eliminarSolicitante

Firma y valor de retorno:

eliminarSolicitante(tipoDocSolicitante, nroDocSolicitante): bool

Descripción general:

Se elimina al solicitante del sistema

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	string	Tipo de documento del solicitante
nroDoc	int	Número de documento del solicitante

Descripción detallada:

Mediante la llamada a SolicitanteDataService.eliminar(tipoDoc,nroDoc) se elimina al solicitante del sistema.

Si algún paso fallara, el método devuelve FALSE, caso contrario devuelve TRUE

cargarFamiliar

Firma y valor de retorno:

cargarFamiliar(tipoDocTitular,nroDocTitular,tipoDocFamiliar,nroDocFamiliar,nombre,Apellido,eMail,fechaNacimiento,sexo,calle,numero,piso,dpto,codigoPostal,

provincia, telefono) : bool

Descripción general:

Carga un familiar de un titular en el sistema

Parámetros:

Nombre	Tipo	Descripción
tipoDocTitular	string	Tipo de documento del titular asociado al solicitante
nroDocTitular	int	Número de documento del titular asociado al solicitante
tipoDocFamilliar	string	Tipo de documento del familiar
nroDocFamiliar	int	Número de documento del familiar
nombre	string	Nombre del familiar
apellido	string	Apellido del familiar
email	string	Email del familiar
fechaNacimiento	Fecha	Fecha de nacimiento del familiar
sexo	enum(M,F)	Sexo del familiar
calle	string	Calle del familiar
numero	int	Número del familiar
piso	int	Piso del familiar
departamento	string	Departamento del familiar
codigoPostal	string(8)	Código postal del familiar
provincia	enum(provincias)	Provincia del familiar
telefono	string	Teléfono del familiar

Descripción detallada:

Se obtienen los datos del titular mediante la llamada a SolicitanteDataService.obtener(tipoDocTitular,nroDocTitular) y se almacenan en una instancia de la clase solicitante llamada aux.

Se crea una instancia de solicitante llamada dato.

Se almacenan los atributos:

dato.tipoDocumento = tipoDocFamilliar

dato.nroDocumento = nroDocFamiliar

dato.nombre = nombre

dato.apellido = apellido

dato.eMail = email

dato.fechaNacimiento = fechaNacimiento

dato.sexo = sexo

dato.direccion = direccion

dato.idTitular = aux.idPersona

dato.pendiente = false

Mediante la llamada a SolicitanteDataService.agregar(dato) se carga al solicitante del sistema.

Si algún paso fallara, el método devuelve FALSE, caso contrario devuelve TRUE

ReporteAutorizacionesController

Documento relacionado	Descripción
M05 – Especificación del listado de autorizaciones rechazadas	Especificación del listado
Reporte autorizaciones (Interfaces/Rerportes/prestaciones_con_deuda.csv)	Ejemplos de los formatos de los reportes generados por el sistema.
M08 -- Diseño y lanzamiento de tareas batch	Tiempos y forma de lanzamiento de tareas batch

Paquete: Controlador.

Responsabilidades: Clase encargada de generar los reportes de las autorizaciones que fueron rechazadas o aceptadas por el personal médico de la OS.

Métodos:

obtenerAutorizacionesRechazadas

Firma y valor de retorno:

obtenerAutorizacionesRechazadas(): Autorizacion[]

Descripcion General:

Devuelve un vector de todas las autorizaciones que fueron rechazadas el mes anterior al actual. Dicho arreglo esta ordenado por el atributo Autorización.fechaSolicitud.

Descripcion detallada:

Mediante la llamada a AutorizacionDataService.obtenerManualesRechazadasMesAnterior() se obtiene en un vector todas las autorizaciones donde el mes de la fecha de resolución es el mes pasado. Las autorizaciones manuales rechazadas contienen el atributo aprobada = false y fecha de resolución distinta de null.

Al vector anterior se le agrega lo devuelto por la llamada a AutorizacionDataService.obtenerAutomaticasRechazadasMesAnterior(), se obtienen las autorizaciones donde el mes de la fecha de solicitud es el mes pasado. Las autorizaciones automáticas rechazadas contienen el atributo aprobada = false.

obtenerAutorizaciones

Firma y valor de retorno:

obtenerAutorizaciones ( fechaHasta ): Autorizacion[]

Descripcion General:

Devuelve un arreglo de todas las autorizaciones que fueron emitidas el mes anterior al actual. Dicho arreglo esta ordenado por el atributo Autorización.fechaResolución.

Parámetros:

Nombre	Tipo	Descripción
fechaHasta	FECHA	Fecha hasta la cual se contemplarán autorizaciones.

Descripcion detallada:

Mediante una llamada al método AutorizacionDataService.obtenerPorFechaRes(fechaDesde,fechaHasta)

generarReporteAutorizacionesRechazadas

Firma y valor de retorno:

generarReporteAutorizacionesRechazadas(): void

Descripción General:

Se genera el reporte de las autorizaciones rechadazas.

Descripción Detallada:

Se recuperan las autorizaciones rechazadas en el mes anterior con el método obtenerAutorizacionesRechazadas().

Para cada autorización obtenida se ejecutan los siguientes pasos:

Se obtiene el afiliado asociado a la autorización actual mediante la llamada a AfiliadoDataService.obtener(autorizacion.idAfiliado) y se almacena en una variable llamada afiliado de tipo Afiliado.

Se obtiene el plan asociado al afiliado mediante la llamada a PlanDataService.obtener(afiliado.idPlan) y se almacena en una variable Plan de tipo Plan.

Se obtiene la prestación asociada a la autorización mediante la llamada a PrestacionDataService.obtener (autorizacion.idPrestacion) y se almacena en una variable Prestacion de tipo Prestacion

Se arma el registro separado por comas (,):

Afiliado.Codigo

Afiliado.Nombre

Afiliado.Apellido

Afiliado.TipoDocumento

Afiliado.NroDocumento

Afiliado.Moroso

Plan.Codigo

Plan.Descripcion

Prestacion.Codigo

Prestacion.Nombre

Autorizacion.Codigo

Autorizacion.Tipo

Autorizacion.FechaSolicitud

Autorizacion.FundamentosResolucion

Si la autorización es de tipo manual se carga:

Autorizacion.Observaciones

Autorizacion.FechaResolucion

Autorizacion.NroLegajo

Si es automática estos campos quedan en blanco.

Se carga el registro en el archivo y se pasa a la siguiente autorización obtenida de existir una.

Se envía por e-mail al director el listado de Autorizaciones Rechazadas (AA_MM_AUT_RECHAZADAS.csv). El archivo queda guardado en el directorio $INI_PATH/Reportes/Autorizaciones/Rechazadas (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado, ver modelo 8).

generarPorcentajeRechazos

Firma y valor de retorno:

generarPorcentajeRechazos( ): void

Descripción General:

Se genera un reporte con el porcentaje de autorizaciones rechazadas en el mes anterior.

Parámetros:

Nombre	Tipo	Descripción
fechaHasta	FECHA	Fecha hasta la cual se contemplarán autorizaciones.

Descripcion General:

Se obtiene en una lista todas las autorizaciones que se han emitido el mes anterior al actual con obtenerAutorizaciones ( ) y se almacenan en un arreglo.

Por cada elmento del arreglo:

Si el estado es APROBADA, se incrementa el total de autorizaciones aprobadas, se va al punto 10, si el estado es RECHAZADA se va al punto 5, si el estado es otro diferente de los dos anteriormente mencionados, se pasa al punto 4.

El estado es distinto de APROBADA o RECHAZADA, la autorización no es tenida en cuenta y se va directamente al punto 9.

Se obtiene de la Autorización su descripción (autorizacion.fundamentosResolución, autorizacion.observaciones) , el valor del atributo tipo (autorizacion.tipo, manual o automática), el valor del atributo autorizacion.fechaResolución.

Se obtiene una instancia de la prestación asociada para recuperar los datos necesarios prestacion = PrestacionDataService.obtener ( autorizacion.idPrestacion )

con la prestación se obtiene prestacion.nombre y se incrementa en una unidad el total de autorizaciones rechazadas para la prestación <prestacion.nombre>

Se agregan todos los datos obtenidos al listado de Porcentaje de Rechazos.

Se incrementa el total de autorizaciones rechazadas.

Se obtiene el siguiente elemento de la lista de Autorizaciones y se vuelve al punto 3, sino no hay más elementos en la lista se va al punto 11.

Para calcular el porcentaje de autorizaciones rechazadas, se suman total de autorizaciones rechazadas y total de autorizaciones aprobadas, luego se divide total de autorizaciones rechazadas por el número que dio anteriormente y se lo multiplica por cien.

Para calcular el porcentaje individual de autorizaciones rechazadas por prestación, para cada prestación se divide el total de autorizaciones rechazadas para la prestación <nombre de la prestación> por el total de autorizaciones rechazadas y a este resultado se lo multiplica por cien.

Se obtiene el listado uniendo el porcentaje individual de autorizaciones rechazadas (por prestación) obtenido en el punto 11, con el atributo prestacion.nombre de la clase Prestación y autorizacion.fundamentosResolución, y prestacion.observaciones de la clase Autorización, luego se ordena la lista según el porcentaje de autorizaciones rechazadas por prestación, en forma decreciente.

En primer lugar se almacenan los totales en el archivo total de autorizaciones aprobadas, total de autorizaciones rechazadas y luego se recorre la lista y por cada elemento se almacena un registro en el archivo binario. (Modelo 5, porcentaje_rechazos_dat.rtf)

Se guarda el archivo Porcentaje de Autorizaciones Rechazadas bajo el nombre DD_MM_AAAA.txt donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/Reportes/Autorizaciones/ProcentajeRechazadas (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado, ver modelo 8).

Se verifica si se han generado los archivos correspondientes a todo el año y de ser asi se realiza la unión de todos los archivos recalculando todos los valores de forma tal que se reflejen las magnitudes anuales y los porcentajes correctos de rechazos por prestación. El nuevo archivo se almacena con el nombre AAAA.dat (mismo formato que porcentaje_rechazos.dat) en el directorio antes mencionado. Con los valores obtenidos del cálculo se genera un nuevo archivo con formato csv para enviar via e-mail al Ministerio de Salud. (Modelo 5, porcentaje_rechazos.csv).

generarPrestacionesConDeuda

Firma y valor de retorno

generarPrestacionesConDeuda ( ) : void

Descripción general

Se genera el reporte de las personas que han tomado prestaciones y no estaban en condiciones de hacerlo en el mes anterior al actual.

Parametros

Nombre	Tipo	Descripción
fechaHasta	FECHA	Fecha hasta la cual se contemplarán autorizaciones.

Descripción detallada

Se obtiene en una lista todas las autorizaciones donde el valor fechaRealización pertenece al mes anterior con la llamada a obtenerAutorizaciones()

Se obtiene el primer elemento de la lista de autorizaciones.

Se obtiene una instancia de afiliado utiliazando el atributo autorizacion. idAfiliado y el método AfiliadoDataService.obtener( idAfiliado ). Del objeto afiliado se obtiene el atributo código y el atributo moroso, si moroso es >= 0, se pasa al punto (4), si no, se pasa al punto (6).

Se obtienen del objeto afiliado los atributos tipoDocumento, nroDocumento, nombre, apellido.

Para completar el registro se instancia también un objeto de la clase prestacion con PrestacionDataService.obtener( autorizacion.idPrestacion ), para obtener e insertar información relevante de la misma en el reporte y se guardan todos los datos en una lista temporal.

Se obtiene la próxima autorización, y se pasa a (3), si no hay más autorizaciones se pasa al punto (7).

Se ordena la lista obtenida según el atributo fechaRealizaciónde la autorización. y se vuelca secuencialmente el contenido de cada nodo de la lista en un registro del archivo donde los campos estarán separados por comas. (Los campos utilizados se detallan en el archivo “prestaciones_con_deuda.csv”).

Se guarda el archivo Prestaciones Con Deuda bajo el nombre DD_MM_AAAA.txt donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/Reportes/PrestacionesConDeuda (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado, ver modelo 8).

RutasController

Paquete: Controlador

Responsabilidades:

Esta clase es la encargada del manejo de la información relacionada con el armado de la hoja de ruta a ser entregada a un promotor.

Métodos:

obtenerPromotores

Firma y valor de retorno:

obtenerPromotores() : Promotor []

Descripción general:

Obtiene una colección de promotores almacenados en el sistema

Descripción detallada:

Mediante la llamada a PromotorDataService.obtenerTodos() obtiene una colección de instancias de Promotor del sistema

obtenerSolicitantesPendientes

Firma y valor de retorno:

obtenerSolicitantesPendientes() : Solicitante[]

Descripción general:

Obtiene los solicitantes pendientes de visita

Descripción detallada:

Mediante la llamada a SolicitanteDataService.obtenerPendientes() obtiene una colección de instancias de Solicitante

asociarPromotor

Firma y valor de retorno:

asociarPromotor(tipoDocSolicitante,nroDocSolicitante, codigoPromotor): bool

Descripción general:

Asocia un solicitante a un promotor.

Parámetros:

Nombre	Tipo	Descripción
tipoDoc	String	Tipo documento del solicitante
nroDoc	int	Número de documento del solicitante
codigoPromotor	int	Código de identificación del promotor

Descripción detallada:

Obtiene los datos del solicitante a partir de SolicitanteDataService.obtener(tipoDoc,nroDoc) y los almacena en una instancia de solicitante llamada dato.

Modifica dato.pendiente = false y dato.idPromotor = codigoPromotor

Almacena los cambios mediante la llamada a SolicitanteDataService.guardar(dato)

Si algún paso falla devolverá false, caso contrario devolverá true.

ZonasController

Documento relacionado	Descripción
M01 - Todos los Diagrama de clases	Diagramas de clases, con los atributos y la firma de los métodos (clases tanto de dominio como de persistencia y control).
M01 - Caso de Uso: Mantener Zonas	ABM de zonas, utiliza extensivamente esta clase.

Paquete: Controlador

Responsabilidades:

Esta clase es la encargada de administrar las funciones relacionadas con las zonas, brindando acceso a operaciones de ABM y de consulta.

Métodos:

existeZona

Firma y valor de retorno:

existeZona(nombre) : bool

Descripción general:

Verifica la existencia de un zona en la BD

Parámetros:

Nombre	Tipo	Descripción
Nombre	String	Nombre de la zona

Descripción detallada:

Devuelve el resultado de la llamada a ZonaDataService.existeZona(nombre).

agregarZona

Firma y valor de retorno:

agregarZona(nombre,descripcion)

Descripción general:

Obtiene una colección de los datos de las prestaciones almacenadas en el sistema

Parámetros:

Nombre	Tipo	Descripción
Nombre	string	Nombre
Descripción	String	Descripción de la zona

Descripción detallada:

Se instancia una variable de la clase Zona llamada Dato. Se almacenan los datos pasados por parámetro:

Dato.Nombre = nombre

Dato.Descripcion = descripcion

Mediante la llamada a ZonaDataService.agregar(Dato) se almacenan los datos en la BD.

modificarZona

Firma y valor de retorno:

modificarZona(nombre,descripcion)

Descripción general:

Modifica los datos de la zona en la BD

Parámetros:

Nombre	Tipo	Descripción
Nombre	string	Nombre
Descripción	String	Descripción de la zona

Descripción detallada:

Se obtienen los datos del zona mediante la llamada a

ZonaDataService.obtener(nombre) y se almacenan en una variable de la clase Zona llamada Dato. Se almacenan la descripción:

Dato.Descripcion = descripcion

Mediante la llamada a ZonaDataService.guardar(Dato) se almacenan los datos en la BD.

Especificación de clases de reporte

InfoPrestacionesAdmin

Documento relacionado	Descripción
Especificaciones de clases: InfoPrestacionesReport, ConsumoAfiliadosReport, PrestacionesRealizadasReport	Especificación de clases de reportes
Especificación del Caso de Uso “Recibir y Cotejar…”	Especificación del Caso de Uso en que se utiliza ésta clase
Especificación de Interfaces con el Prestador	Interfaz con el Prestador, describiendo comunicación, formato, medio, periodicidad.
Especificación de Interfaces con sector Pagos	Interfaz con Pagos, describiendo comunicación, formato, medio, periodicidad.

Paquete: Reportes

Responsabilidades: Contiene la funcionalidad necesaria para poder levantar información recibida del Prestador, y generar y enviar reportes.

Métodos:

3.1 obtenerInfoPendiente

Firma y valor de retorno:

InfoPrestacionesReport[] obtenerInfoPendiente( Prestador prestador )

Descripción general:

Obtiene, del directorio FTP asociado al prestador p, todos los archivos que haya al momento,los parsea y encapsula cada uno dentro de un objeto InfoPrestacionesReport. Devuelve la lista de informes enviados por el prestador.

Parámetros:

Nombre	Tipo	Descripción
prestador	Prestador	Prestador del cual se obtendrán todas los informes pendientes de procesar

Descripción detallada:

Dentro del sitio FTP publicado por la Obra Social (cuya dirección se obtiene del archivo de configuración de la aplicación) , se identifica al directorio del prestador en base a su número de CUIT (el nombre de su directorio asociado es su número de CUIT, en la forma xx-xxxxxxxx-x)

Mediante librerías del framework base, se cargan todos los archivos de ése directorio, y cada uno se lo parsea y en base a él se crean y completan los objetos a devolver.

3.2 moverArchivoAceptado

Firma y valor de retorno:

void moverArchivoAceptado( InfoPrestacionesReport ip )

Descripción general:

En base al objeto informe que se pasa por parámetro, se mueve su archivo asociado correspondiente al directorio de archivos aceptados.

Parámetros:

Nombre	Tipo	Descripción
ip	InfoPrestacionesReport	Informe de prestaciones que corresponde al archivo que se debe mover

Descripción detallada:

Se obtiene el nombre del archivo a partir de la información contenida en el objeto ip (atributo nombreArchivo)

Se mueve, mediante librerías del fwk base, el archivo al directorio FTP de aceptados, cuya ubicación se obtiene del archivo de configuración de la aplicación.

3.3 moverArchivoRechazado

Firma y valor de retorno:

void moverArchivoRechazado( InfoPrestacionesReport ip )

Descripción general:

En base al objeto informe que se pasa por parámetro, se mueve su archivo asociado correspondiente al directorio de archivos rechazados.

Parámetros:

Nombre	Tipo	Descripción
Ip	InfoPrestacionesReport	Informe de prestaciones que corresponde al archivo que se debe mover

Descripción detallada:

Se obtiene el nombre del archivo a partir de la información contenida en el objeto ip (atributo nombreArchivo)

Se mueve, mediante librerías del fwk base, el archivo al directorio FTP de rechazados, cuya ubicación se obtiene del archivo de configuración de la aplicación.

3.4 enviarReporteConsumo( ConsumoAfiliadosReport reporteConsumo )

Firma y valor de retorno:

void enviarReporteConsumo( ConsumoAfiliadosReport reporteConsumo )

Descripción general:

En base al objeto reporte que se pasa por parámetro, se lo envía en formato archivo, depositándolo en un sitio FTP, al sector de Pagos de la Obra Social.

Parámetros:

Nombre	Tipo	Descripción
reporteConsumo	ConsumoAfiliadosReport	Reporte de consumo de los afiliados a enviar al sector Pagos

Descripción detallada:

Se genera un archivo XML basándose en el schema definido en el documento “Especificación de Interfaces con sector Pagos”

Se obtiene la dirección del directorio FTP publicado por Pagos donde se deben dejar los reportes, desde el archivo de configuración del Sistema.

Se envía vía FTP, y usando librerías del fwk base, el archivo XML generado, al directorio FTP correspondiente

3.5 enviarReporteAprobaciones( PrestacionesRealizadasReport informeAprobaciones )

Firma y valor de retorno:

void enviarReporteAprobaciones( PrestacionesRealizadasReport informeAprobaciones )

Descripción general:

En base al objeto reporte que se pasa por parámetro, se lo envía en formato archivo, depositándolo en un sitio FTP, al sector de Pagos de la Obra Social.

Parámetros:

Nombre	Tipo	Descripción
informeAprobaciones	PrestacionesRealizadasReport	Informe de aprobacioes/rechazos de prestaciones realizadas a enviar al sector Pagos

Descripción detallada:

Se genera un archivo XML basándose en el schema definido en el documento “Especificación de Interfaces con sector Pagos”, para el informe de aprobaciones/rechazos de autorizaciones.

Se obtiene la dirección del directorio FTP publicado por Pagos donde se deben dejar los reportes, desde el archivo de configuración del Sistema.

Se envía vía FTP, y usando librerías del fwk base, el archivo XML generado al directorio FTP correspondiente

InfoPrestacionesReport

Documento relacionado	Descripción
Especificación de Interfaces con el Prestador	Interfaz con el Prestador, describiendo comunicación, formato, medio, periodicidad.
CU “Recibir y Cotejar Consumos y Prestaciones”	Caso de uso en el cual se utiliza indirectamente la clase.

Paquete: Reportes

Responsabilidades: Representa un reporte enviado por el Prestador, conteniendo la información de las prestaciones realizadas por los afiliados de la Obra Social en el último período de tiempo fijado (ver “Especificación de Interfaces con el Prestador”)

Métodos:

3.1 validarFormato

Firma y valor de retorno:

bool validarFormato()

Descripción general:

Valida el formato del archivo asociado a éste objeto informe contra el esquema descripto en el documento “Especificación de Interfaces con el Prestador”.

Devuelve true en caso de que el archivo sea válido, y false en caso contrario.

Descripción detallada:

A partir del atributo nombreArchivo, se levanta el archivo asociado de disco y se lo carga en una clase del fwk base que representa un documento XML.

Se valida, utilizando librerías del fwk base, éste documento XML contra el XML Schema, cuya ubicación y nombre está descripta en el archivo de configuración del Sistema.

Se devuelve true si la validación resultó correcta, sino, false.

3.2 validarLineas

Firma y valor de retorno:

void ValidarLineas( Prestador prestador )

Nombre	Tipo	Descripción
prestador	Prestador	Prestador al cual están asociadas las lineas a validar

Descripción general:

Valida cada linea del informe según las validaciones explicadas en el CU “Recibir y Cotejar Consumos y Prestaciones”, marcando cada linea como aprobada ó rechazada.

Descripción detallada:

Éste método simplemente llama a LineaInfoPrestacionesReport.Validar( prestador) para cada linea que pertenezca al reporte.

LineaInfoPrestacionesReport

Documento relacionado	Descripción
Especificación de Interfaces con el Prestador	Interfaz con el Prestador, describiendo comunicación, formato, medio, periodicidad.
CU “Recibir y Cotejar Consumos y Prestaciones”	Caso de uso en el cual se utiliza indirectamente la clase.
Diagrama de secuencia “Recibir y Cotejar Consumos y Prestaciones Parte 2”	

Paquete: Reportes

Responsabilidades: Representa una línea del reporte enviado por el Prestador, conteniendo la información acerca de una prestación realizada(íntimamente ligada con la autorización) por los afiliados de la Obra Social.

Métodos:

3.1 validar

Firma y valor de retorno:

bool validar( Prestador prestador )

Nombre	Tipo	Descripción
prestador	Prestador	Prestador al cual está asociada la linea a validar

Descripción general:

Valida, según reglas de negocio (ver CU “Recibir y Cotejar..” ), si la línea es aprobada para ser pagada a la Clínica, ó si es rechazada.Además, marca el atributo Aprobada en true ó false según el resultado de la validación. Éste mismo resultado es el que devuelve el método.

Descripción detallada:

Se realizan todas las validaciones para una linea explicadas en detalle en el documento “Especificación del Caso de Uso Recibir y Cotejar Consumos y Prestaciones” à ver el diagrama de secuencia “Recibir y Cotejar Consumos y Prestaciones Parte 2”

Se devuelve true sólo si todas las validaciones fueron superadas

NotificacionesAdmin

Documento relacionado	Descripción
Especificaciones de clases: InfoPrestacionesReport, ConsumoAfiliadosReport, PrestacionesRealizadasReport	Especificación de clases de reportes
Especificación del Caso de Uso “Recibir y Cotejar…”	Especificación del Caso de Uso en que se utiliza ésta clase
Especificación de Interfaces con el Prestador	Interfaz con el Prestador, describiendo comunicación, formato, medio, periodicidad.
Especificación de Interfaces con sector Pagos	Interfaz con Pagos, describiendo comunicación, formato, medio, periodicidad.

Paquete: Reportes

Responsabilidades: Clase que contiene la funcionalidad para generar y enviar notificaciones en formato e-mail.

Métodos:

3.1 notificarPrestador

Firma y valor de retorno:

void notificarPrestador( Prestador p, enum[Ok,Error,NoRecibido] tipoNotificacion, string nombreArchivo )

Descripción general:

Envía un mail al prestador p, cuyo contenido depende del tipo de notificación (ver “Especificación de Interfaces con el Prestador”)

Parámetros:

Nombre	Tipo	Descripción
p	Prestador	Prestador al cual se le enviará el e-mail de notificación
tipoNotificacion	Enum[Ok, Error, NoRecibido]	Tipo de notificación a enviar: Proceso exitoso (Ok), Error grave (Error) ó que no se recibieron archivos en las últimas 24hs. (NoRecibido)
nombreArchivo	String	Nombre del archivo relacionado con la notificación. En caso de que tipoNotificación sea “NoRecibido”, éste parámetro no se tendrá en cuenta dentro del método

Descripción detallada:

Se genera un objeto de tipo Mail (provisto por el fwk base) con los datos acordes según el documento “Especificación de Interfaces con el Prestador”

Se obtiene el e-mail del Prestador, con el atributo email del objeto p.

Se envía el objeto Mail a través de librerías provistas por el fwk base a la dirección del prestador p.

3.2 notificarPagos

Firma y valor de retorno:

void notificarPagos( Prestador p, enum[Error,NoRecibido] tipoNotificacion, string nombreArchivo )

Descripción general:

Envía un mail al sector de Pagos de la Obra Social indicando algún tipo de anomalía en el proceso de los archivos enviados por el prestador p. El contenido de la notificación depende de su tipo (ver “Especificación de Interfaces con Pagos”)

Parámetros:

Nombre	Tipo	Descripción
P	Prestador	Prestador con acerca del cual se envía la notificación
tipoNotificacion	Enum[Error, NoRecibido]	Tipo de notificación a enviar: Error grave (Error) ó que no se recibieron archivos en las últimas 24hs. (NoRecibido)
nombreArchivo	String	Nombre del archivo relacionado con la notificación. En caso de que tipoNotificación sea “NoRecibido”, éste parámetro no se tendrá en cuenta dentro del método

Descripción detallada:

Se genera un objeto de tipo Mail (provisto por el fwk base) con los datos acordes según el documento “Especificación de Interfaces con el Prestador”

Se obtiene el e-mail del Prestador, con el atributo email del objeto p.

Se envía el objeto Mail a través de librerías provistas por el fwk base a la dirección del sector Pagos, obtenida desde el archivo de configuración del sistema..

Diagrama de casos de uso

Diagramas paquetes

Diagrama de arquitectura general del sistema

Diagrama de paquete de dominio

Diagrama de paquete de control

Diagrama de paquete de reportes

Diagramas de clases

Diagrama de clases de dominio

Diagrama de relación de clases de dominio

Diagrama de clases de control

Diagrama de clases de persistencia

Diagrama de clases de reporte

Diagramas de estado

Diagrama de estado de autorización manual

Diagrama de estados de autorización automática

Diagrama de estado de Solicitante

Diseño de la base de datos

Diagrama de tablas

Diccionario de datos

Composición física de las tablas

Tabla	Campo	Tipo	T.Prom	Nulo	PK	FK	Referencia
Afiliados	idAfiliado	Integer	4	No	Si	No	
	Codigo	Integer	4	No	No	No	
	FechaAfiliacion	Date	7	No	No	No	
	FechaBaja	Date	7	Si	No	No	
	Moroso	Integer	4	No	No	No	
	idPlan	Integer	4	No	No	Si	Planes
	idTitular	Integer	4	No	No	Si	Afiliados
Autorizaciones	idAutorizacion	Integer	4	No	Si	No	
	Codigo	Integer	4	No	No	No	
	porcentajeCobertura	Integer	4	No	No	No	
	fechaSolicitud	Date	7	No	No	No	
	fechaRealizacion	Date	7	Si	No	No	
	fechaVencimiento	Date	7	No	No	No	
	Aprobada	Smallint	2	No	No	No	
	fundamentosResolucion	Varchar(255)	50	Si	No	No	
	Tipo	Enum(Manual,Auto)	5	No	No	No	
	idAfiliado	Integer	4	No	No	Si	Afiliados
	idPrestador	Integer	4	No	No	Si	Prestadores
	idPrestacion	Integer	4	No	No	Si	Prestaciones
AutorizacionesManuales	idAutorizacion	Integer	4	No	Si	No	
	fechaResolucion	Date	7	Si	No	No	
	Observaciones	Varchar(255)	100	No	No	No	
	Nrolegajo	Integer	4	No	No	No	
CAPs	idCAP	Integer	4	No	Si	No	
	Codigo	Varchar(255)	10	No	No	No	
	Horario	Varchar(255)	11	No	No	No	
	idDireccion	Integer	4	No	No	Si	Direcciones
Categorías	idCategoria	Integer	4	No	Si	No	
	Codigo	Integer	4	No	No	No	
	Nombre	Varchar(255)	25	No	No	No	
	fechaBaja	Date	7	Si	No	No	
Coberturas	idPrestacion	Integer	4	No	Si	Si	Prestaciones
	idPlan	Integer	4	No	Si	Si	Planes
	Carencia	Float	4	No	No	No	
	Porcentaje	Integer	4	No	No	No	
	LimiteAnual	Integer	4	No	No	No	
	tipoAutoriazacion	Enum(Manual,Auto)	5	No	No	No	
Direcciones	idDireccion	Integer	4	No	Si	No	
	Calle	Varchar(255)	25	No	No	No	
	Numero	Integer	4	No	No	No	
	Piso	Integer	4	Si	No	No	
	Departamento	Varchar(255)	1	Si	No	No	
	CodigoPostal	Varchar(8)	6	No	No	No	
	Provincia	Enum([Provincias])	7	No	No	No	
	Telefono	Varchar(20)	10	No	No	No	
	idZona	Integer	4	No	No	Si	Zonas
HistoriasPlanes	idAfiliado	Integer	4	No	Si	Si	Afiliados
	idPlan	Integer	4	No	Si	Si	Planes
	fechaIngreso	Date	7	No	No	No	
	fechaEgreso	Date	7	No	No	No	
Personas	idPersona	Integer	4	No	Si	No	
	tipoDocumento	Enum(DNI,LC,LE,CI)	2	No	No	No	
	nroDocumento	Integer	4	No	No	No	
	Nombre	Varchar(255)	12	No	No	No	
	Apellido	Varchar(255)	10	No	No	No	
	Email	Varchar(255)	25	Si	No	No	
	fechaNacimiento	Date	7	No	No	No	
	Sexo	Enum(M,F)	1	No	No	No	
	idDireccion	Integer	4	No	No	Si	Direcciones
Planes	idPlan	Integer	4	No	Si	No	
	Codigo	Integer	4	No	No	No	
	Categoría	Float	4	No	No	No	
	Descripción	Varchar(255)	40	No	No	No	
	permanenciaMinima	Float	4	No	No	No	
	fechaBaja	Date	7	Si	No	No	
Prestaciones	idPrestacion	Integer	4	No	Si	No	
	Codigo	Varchar(8)	8	No	No	No	
	Nombre	Varchar(255)	25	No	No	No	
	FechaBaja	Date	7	Si	No	No	
	idCategoria	Integer	4	No	No	Si	Categorías
Prestadores	idPrestador	Integer	4	No	Si	No	
	Cuit	Varchar(11)	11	No	No	No	
	Nombre	Varchar(255)	25	No	No	No	
	FechaBaja	Date	7	Si	No	No	
	Email	Varchar(255)	10	No	No	No	
	idDireccion	Integer	4	No	No	Si	Direcciones
PrestadoresPrestaciones	idPrestador	Integer	4	No	Si	Si	Prestadores
	idPrestacion	Integer	4	No	Si	Si	Prestaciones
Promotores	idPersona	Integer	4	No	Si	Si	Personas
	fechaBaja	Date	7	No	No	No	
Solicitantes	idPersona	Integer	4	No	No	Si	Personas
	Disponibilidad	Varchar(255)	11	No	No	No	
	Familiares	Integer	4	No	No	No	
	Observaciones	Varchar(255)	70	No	No	No	
	Pendiente	Smallint	2	No	No	No	
	idPromotor	Integer	4	No	No	Si	Promotores
	Idtitular	Integer	4	No	No	Si	Titulares
Zonas	IdZona	Integer	4	No	Si	No	
	Nombre	Varchar(255)	10	No	No	No	
	Descripción	Varchar(255)	50	No	No	No	
	IdCAP	Integer	4	No	No	Si	Zonas

Diccionario de datos de las tablas

Tabla	Descripción
Afiliados	Esta tabla almacena los Afiliados de la Obra Social. Están vinculados con un Plan (mediante idPlan) y con otro Afiliado en caso de no ser titular de la cuenta.
Autorizaciones	En esta table se almacenan Autorizaciones que son Automáticas. Cada una de ellas se relacionan con un Afiliado (idAfiliado), con un Prestador (idPrestador) y una Prestación (idPrestacion).
AutorizacionesManuales	Esta tabla representa una entidad débil, que depende de Autorizaciones. Tiene por lo tanto las mismas relaciones que tienen las Autorizaciones. Almacena las Autorizaciones Manuales que llegan a la Obra Social.
CAPs	Esta tabla almacena los CAPs que posee la Obra Social.
Categorías	Almacena las categorías a las que pertenecen las distintas prestaciones. Se basa en el nomenclador.
Coberturas	Almacena la relación que existe entre un plan (idPlan) y las diversas prestaciones (idPrestaciones) que cubre. A su vez indica si para tomar la prestación es necesario una autorización manual o automática.
Direcciones	Almacena las direcciones que eventualmente se involucren en el sistema: tanto las de los Afiliados, Promotores, Solicitantes y CAPs
HistoriasPlanes	Almacena los planes (idPlanes) a los que estuvo asociado un afiliado (idAfiliado) alguna vez dentro de la Obra Social con su respectiva fecha de alta y en caso de haberlo dejado, su fecha de baja.
Personas	Representa la entidad abstracta persona. Está relacionada con un CAP (idCap) y una Dirección (idDireccion).
Planes	Almacena los planes que posee la obra social con sus características.
Prestaciones	Almacena las prestaciones enunciadas en el nomenclador sus características. La principa es el código (codigo) y la vinculación con una categoría (idCategoria).
Prestadores	Almacena tanto médicos particulares como clínicas que pueden realizar prestaciones a los afiliados de la obra social. Los prestadores pertenecen a una zona (idZona) y poseen una dirección física (idDireccion).
PrestadoresPrestaciones	Tabla que relaciona a un prestador (idPrestador) con las distintas prestaciones (idPrestacion) que puede brindar a los afiliados.
Promotores	Almacena los datos de los promotores que posee la Obra Social.
Solicitantes	Esta tabla contiene los datos personales y de contacto de los distintos solicitantes que quizás en un futuro sean afiliados de la Obra Social. Se relaciona con un Promotor (idPromotor) y puede también relacionarse con un titular en caso de poder tener un familiar directo ya asociado en la Obra Social.
Zonas	Almacena las distintas Zonas geográficas en donde hay CAPs.

Diccionario de datos de los atributos

Tabla	Campo	Descripción
Afiliados	idAfiliado	Identificador de un Afiliado en el sistema.
	Codigo	Identificador único de afiliado. Número de carnet.
	FechaAfiliacion	Fecha en la que el solicitante paso a ser un afiliado de la obra social.
	FechaBaja	Fecha en la que el afiliado solicita la baja en el sistema.
	Moroso	Indica cuantos meses adeuda el afiliado.
	IdPlan	Identificador del plan al que pertenece el afiliado.
	IdTitular	Identificador del titular del afiliado actual.
Autorizaciones	idAutorizacion	Identificador de la autorización en el sistema.
	Codigo	Identificador único de la autorización. Número de formulario.
	porcentajeCobertura	Porcentaje de la prestación cubierto por la autorización.
	fechaSolicitud	Fecha en la que fue solicitada la autorización.
	fechaRealizacion	Fecha en la que fue efectivizada la autorización. Es decir el día en que se rechazó o el día en que el afiliado la utilizó.
	fechaVencimiento	Fecha en que vence la autorización.
	Aprobada	Indica si la autorización fue aprobada o no.
	fundamentosResolucion	Una descripción coloquial del por qué se aprueba o rechaza la autorización.
	Tipo	Indica si la autorización es manual o automática.
	idAfiliado	Identificador del afiliado que solicitó la autorización.
	idPrestador	Identificador del prestador que solicitó la autorización.
	idPrestacion	Identificador de la prestación a llevar a cabo.
AutorizacionesManuales	IdAutorizacion	Identificador en el sistema de la autorización a la que pertenece, ya que AutorizacionManual es una entidad débil.
	fechaResolucion	Fecha en la que se aprobo/rechazó la autorización manual.
	Observaciones	Una descripción coloquial del por qué se solicita la autorización.
	nroLegajo	El legajo del profesional que evaluó la autorización.
CAPs	IdCAP	Identrificador del CAP en el sistema.
	Codigo	Identificador único del CAP en el sistema. Código de uso público, se utiliza en listados, etc.
	Horario	Horario de atención (texto libre).
	IdDireccion	Identificador que relaciona a un CAP con una dirección.
Categorías	idCategoria	Identificador de la categoría en el sistema.
	Codigo	Código de la categoría según en nomenclador.
	Nombre	Nombre de la categoría.
	fechaBaja	Fecha en la que fue dada de baja la categoría (NULL si esta activa).
Coberturas	idPrestacion	Identificador de una Prestación en el sistema.
	IdPlan	Identificador de un Plan en el sistema.
	Carencia	Antigüedad (en meses) que debe tener el afiliado en el plan para ser cubierto.
	Porcentaje	Antigüedad (en meses) que debe tener el afiliado en el plan para ser cubierto.
	LimiteAnual	Cantidad de prestaciones que se puede realizar por año (cero indica que no hay límite).
	tipoAutoriazacion	Indica el tipo de autorización que necesita para realizarse la prestación (automática o manual).
Direcciones	idDireccion	Identificador de una dirección en el sistema.
	Calle	Nombre de la calle del domicilio.
	Numero	Número de vivienda del domicilio.
	Piso	Piso del domicilio (NULL si no es aplicable).
	Departamento	Departamento del domicilio (NULL si no es aplicable).
	CodigoPostal	Código postal del domicilio.
	Provincia	Provincia donde se encuentra el domicilio.
	Telefono	Teléfono del domicilio.
	idZona	Identificador de la zona a la que pertenece la dirección.
HistoriasPlanes	idAfiliado	Identificador en el sistema de un afiliado.
	IdPlan	Identificador en el sistema de un plan.
	fechaIngreso	Fecha en que se dio de alta un afiliado en el plan.
	fechaEgreso	Fecha en que se dio de baja un afiliado en el plan (NULL si no se aplica).
Personas	idPersona	Identificador único de una persona en el sistema.
	tipoDocumento	Tipo de documento de la persona.
	nroDocumento	Número de documento de la persona.
	Nombre	Primer y segundo nombre de la persona (en ese orden).
	Apellido	Apellido completo de la persona.
	Mail	Dirección de correo electrónico de la persona.
	fechaNacimiento	Fecha de nacimiento de la persona.
	Sexo	Género de la persona.
	idDireccion	Identificador en el sistema de la dirección de la persona.
Planes	idPlan	Identificador del plan en el sistema.
	Codigo	Identificador único del Plan en el sistema. Se utiliza para listados, etc.
	Categoría	Categoría del plan. Cuanto más grande es la categoría, mejor es el plan
	Descripción	Una breve descripción del plan.
	permanenciaMinima	Permanencia mínima (en meses) que debe cumplir en el plan antes de pasarse a otro.
	fechaBaja	Fecha en la que el afiliado solicita la baja.
Prestaciones	idPrestacion	Identificador de la prestación en el sistema.
	Codigo	Identificador único de la prestación en el sistema.
	Nombre	Nombre del plan
	FechaBaja	Fecha de cuando se dio de baja la prestación.
	idCategoria	Identificador en el sistema de la categoría a la que pertenece la prestación.
Prestadores	idPrestador	Identificador del prestador en el sistema.
	Cuit	Número de CUIT del prestador.
	Nombre	Nombre del prestador.
	FechaBaja	Fecha en que fue dado de baja el prestador (NULL si no se aplica).
	Email	Dirección de correo electrónico del prestador.
	idDireccion	Identificador de la dirección a la que pertenece el prestador.
PrestadoresPrestaciones	idPrestador	Identificador en el sistema de un prestador.
	idPrestacion	Identificador en el sistema de una prestación.
Promotores	IdPersona	Identificador en el sistema de una persona (entidad abstracta).
	fechaBaja	Fecha en que fue dado de baja un promotor (NULL si no se aplica)
Solicitantes	IdPersona	Identificador en el sistema de una persona (entidad abstracta).
	Disponibilidad	Horario en el cual puede ser visitado (texto libre).
	Familiares	Cantidad de integrantes del grupo familiar a afiliar.
	Observaciones	Observaciones que puedan ser de utilidad para el Promotor.
	Pendiente	Indica si el solicitante fue visitado o no.
	IdPromotor	Identificador en el sistema del promotor que atendió al solicitante.
	Idtitular	Identificador en el sistema del titular de la cuenta (cero si no es aplicable).
Zona	IdZona	Identificador único en el sistema de una zona.
	Nombre	Nombre de la zona.
	Descripción	Breve descripción de la zona.
	IdCAP	Identificador que relaciona a una Zona con un CAP.

Mapeo de clases de entidad

Tabla	Campo	Clase.atributo
Afiliados		
	Codigo	Afiliado.codigo
	FechaAfiliacion	Afiliado.FechaAfiliacion
	FechaBaja	Afiliado.FechaBaja
	Moroso	Afiliado.Moroso
	IdPlan	Afiliado.Plan
	IdTitular	Afiliado.Titular
Autorizaciones		
	Codigo	Autorización.codigo
	porcentajeCobertura	Autorización.porcentajeCobertura
	fechaSolicitud	Autorización.fechaSolicitud
	fechaRealizacion	Autorización.fechaRealizacion
	fechaVencimiento	Autorización.fechaVencimiento
	Aprobada	Autorización.aprobada
	fundamentosResolucion	Autorización.fundamentosResolucion
	Tipo	Autorización.tipo
	IdAfiliado	Autorización.Afiliado
	IdPrestador	Autorización.Prestador
	IdPrestacion	Autorización.Prestacion
AutorizacionesManuales		
	fechaResolucion	AutorizacionManual.fechaResolucion
	Observaciones	AutorizacionManual.observaciones
	nroLegajo	AutorizacionManual.nroLegajo
CAPs		
	Codigo	CAP.codigo
	Horario	CAP.horario
	IdDireccion	CAP.Direccion
Categorías		
	Codigo	Categoría.codigo
	Nombre	Categoría.nombre
	fechaBaja	Categoría.fechaBaja
Coberturas		
	Carencia	Cobertura.carencia
	Porcentaje	Cobertura.porcentaje
	LimiteAnual	Cobertura.limiteAnual
	tipoAutoriazacion	Cobertura.tipoAutorizacion
Direcciones		
	Calle	Dirección.calle
	Numero	Dirección.numero
	Piso	Dirección.piso
	Departamento	Dirección.departamento
	CodigoPostal	Dirección.codigoPostal
	Provincia	Dirección.provincia
	Telefono	Dirección.telefono
HistoriasPlanes		
	fechaIngreso	HistoriaPlan.fechaIngreso
	fechaEgreso	HistoriaPlan.fechaEgreso
Personas		
	tipoDocumento	Persona.tipoDocumento
	nroDocumento	Persona.nroDocumento
	Nombre	Persona.nombre
	Apellido	Persona.apellido
	Mail	Persona.mail
	fechaNacimiento	Persona.fechaNacimiento
	Sexo	Persona.sexo
	idDireccion	Persona.Direccion
Planes		
	Codigo	Plan.codigo
	Categoría	Plan.categoría
	Descripción	Plan.descripción
	permanenciaMinima	Plan.permanenciaMinima
	fechaBaja	Plan.fechaBaja
Prestaciones		
	Codigo	Prestación.codigo
	Nombre	Prestación.nombre
	FechaBaja	Prestación.fechaBaja
	idCategoria	Prestación.Categoria
Prestadores		
	Email	Prestador.email
	Cuit	Prestador.cuit
	Nombre	Prestador.nombre
	FechaBaja	Prestador.fechaBaja
	idDireccion	Prestador.idDireccion
Promotores		
	FechaBaja	Promotor.fechaBaja
Solicitantes		
	Disponibilidad	Solicitante.disponibilidad
	Familiares	Solicitante.familiares
	Observaciones	Solicitante.observaciones
	Pendiente	Solicitante.pendiente
	idPromotor	Solicitante.Promotor
	idTitular	Solicitante.Titular
Zona		
	Nombre	Zona.nombre
	Descripción	Zona.descripción
	IdCAP	Zona.CAP

Reglas de integridad referencial

Afiliado
Persona afiliada a la obra social. Se da de baja lógica normalmente. Solo se puede dar de baja física si ningún Afiliado lo tiene como titular. Al darse de baja hay que borrar en cascada la tabla HistoriaPlan, Autorización, Persona y Solicitante (que lo tenga como titular). Solo puede darse de alta física si existen las referencias correspondientes a Persona, Plan y Titular (en caso que corresponda).
Atributo	Tipo	Descripción
idPersona	INT	Clave primaria interna de la base de datos
codigo	INT	Identificador único de afiliado
fechaAfiliacion	DATE	Fecha en la que se lo dio de alta en el sistema.
fechaBaja	DATE	Fecha en la que el afiliado solicita la baja. NULL si está activo
moroso	INT	Indica cuantos meses adeuda.
idPlan	INT	No puede ser NULL
idTitular	INT	NULL si es titular, si pertenece a un grupo familiar, se guarda el id del titular del grupo.

Autorización
Autorización para realizarse una Prestación. No tiene bajas a menos que se depure la base de datos, en cuyo caso se debe borrar en cascada la tabla AutorizacionManual. Solo puede darse de alta física si existen las referencias correspondientes al Prestador, Prestación y Afiliado.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	INT	Identificador único.
porcentajeCobertura	DECIMAL(3,2)	Porcentaje de la prestacion cubierto por la Autorizacion
fechaSolicitud	DATE	Fecha en que fue solicitada la autorización.
fechaRealizacion	DATE	Fecha en que efectivizada la autorización. Es decir el dia en que se rechazo o el dia en que el afiliado la utilizo. NULL si todavía no fue realizada
fechaVencimiento	DATE	Fecha en que vence la autorización.
aprobada	BOOL	Indica si la autorizacion fue aprobada o no.
fundamentosResolucion	VARCHAR(255)	Una descripcion coloquial del por qué se aprueba o rechaza la autorización
tipo	ENUMmanual,auto)	Tipo de autorización
idPrestador	INT	No puede ser NULL
idPrestacion	INT	No puede ser NULL
idAfiliado	INT	No puede ser NULL

AutorizacionManual
Autorización que debe ser aprobada manualmente, a través de un auditor médico. Solo puede darse de alta física si existe la referencia correspondiente a la Autorización.
Atributo	Tipo	Descripción
idAutorizacion	INT	Clave primaria interna de la base de datos
observaciones	VARCHAR(255)	Una descripción coloquial del por qué se solicita la autorización
fechaResolucion	DATE	Fecha en la que se aprobó/rechazo la autorización. NULL si todavía no hay una resolución tomada.
nroLegajo	INT	Número de legajo del profesional que evaluó la autorización.

Cap
Centro de Atención Personalizada, es un punto de atención al cliente que cubre una o más Zonas y tiene uno o más Promotores. Se puede dar de baja sólo si no tiene asociado Personas ni Zonas. Si se da de baja, hay que dar de baja en cascada la tabla Dirección. Solo puede darse de alta física si existen la referencia correspondiente a Dirección.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	VARCHAR(255)	Código único de identificación del Cap.
horario	VARCHAR(255)	Horario de atención como un texto libre.
idDireccion	INT	No puede ser NULL

Categoria
Clasificación de las Prestaciones. Sólo puede ser dado de baja si no tiene Prestaciones asociadas.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	INT	Código de la categoría según el codificador
nombre	VARCHAR(255)	Nombre de la categoría
fechaBaja	DATE	Si no es NULL, la Categoria fue dada de baja en la fecha indicada por este campo.

Cobertura
Limitaciones de cobertura para un Plan y una Prestación determinada. Es dado de baja cuando se da de baja el Plan al que pertenece. Solo puede darse de alta física si existen las referencias correspondientes a Prestación y Plan.
Atributo	Tipo	Descripción
idPrestacion	INT	Clave primaria interna de la base de datos
idPlan	INT	Clave primaria interna de la base de datos
carencia	FLOAT	Antigüedad que debe tener el afiliado en el plan para ser cubierto. Si es NULL no tiene tiempo de carencia
porcentaje	INT(3)	Porcentaje de la prestación cubierto.
limiteAnual	INT	Cantidad de prestaciones que se puede realizar por año. Si es NULL no hay límite
tipoAutorizacion	ENUM(manual,auto)	Indica el tipo de autorización que necesita para realizarse la prestación.

Direccion
Direccion de un domicilio. No se puede dar de baja directamente, se da de baja indirectamente al eliminar un Prestador, un Cap o una Persona. Solo puede darse de alta física si existen la referencia correspondiente a Zona.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
calle	VARCHAR(255)	Calle del domicilio
numero	INT	Número del domicilio
piso	INT	Piso del domicilio. NULL si no aplica
departamento	VARCHAR(255)	Departamento del domicilio. NULL si no aplica
codigoPostal	VARCHAR(8)	Código postal del domicilio
provincia	ENUM([provincias])	Provincia donde se encuentra el domicilio
telefono	VARCHAR(30)	Teléfono del domicilio. NULL si no aplica
idZona	INT	No puede ser NULL

HistoriaPlan
Representa el período de tiempo que un afiliado estuvo en un plan. Se da de baja sólo al dar de baja un Afiliado. Solo puede darse de alta física si existen las referencias correspondientes a Plan y Afiliado.
Atributo	Tipo	Descripción
idAfiliado	INT	Clave primaria interna de la base de datos
idPlan	INT	Clave primaria interna de la base de datos
fechaIngreso	DATE	Fecha en que se dio de alta el plan
fechaEgreso	DATE	Fecha en la que el plan no rige mas para el afiliado. Si es el plan actual es NULL

Persona
Clase abstracta para representar los datos y acciones comunes de una persona. No se puede dar de baja de forma directa, se da de baja al dar de baja un Afiliado, Solicitante o Promotor. Solo puede darse de alta física si existen la referencia correspondiente Dirección.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
tipoDocumento	ENUM(DNI,LC,LE,CI)	Tipo de documento.
nroDocumento	INT	Número de documento
nombre	VARCHAR(255)	Primer y segundo nombre (en ese orden).
apellido	VARCHAR(255)	Apellido completo.
eMail	VARCHAR(255)	Dirección de correo electrónico de la persona.
fechaNacimiento	DATE	Fecha de nacimiento
sexo	ENUM(M,F)	Género de la persona
idDireccion	INT	No puede ser NULL

Plan
Plan de la obra social. Normalmente tiene baja lógica, pero puede darse de baja física si no tiene Afiliados asociados (y por lo tanto tampoco tiene asociados HistoriaPlan). Si se da de baja, hay que borrar en cascada la tabla Cobertura.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	INT	Codigo de plan (nomenclador).
categoria	FLOAT	Categoría a la que pertenece (nomenclador).
descripcion	VARCHAR(255)	Una breve descripción del plan.
permanenciaMinima	FLOAT	Permanencia mínima (en meses) que debe cumplir en el plan antes de pasarse a otro. NULL si no tiene
fechaBaja	DATE	Fecha en la que el plan se dio de baja. Si está activo es NULL.

Prestacion
Tipo de prestación que puede realizarse un afiliado. Tiene sólo baja lógica (excepto que se depure la base de datos, en cuyo caso hay que borrar, sólo si no tiene Autorizaciones y Coberturas asociadas, en cascada la tabla PrestadorPrestacion). Solo puede darse de alta física si existe la referencia correspondiente a Categoria.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
codigo	VARCHAR(8)	Código de prestación según el codificador
nombre	VARCHAR(255)	Nombre de la prestación.
fechaBaja	DATE	Si no es NULL, la Prestacion fue dada de baja en la fecha indicada por este campo.
idCategoria	INT	No puede ser NULL

Prestador
Entidad prestadora de servicios para la obra social. Podría ser tanto una Clínica, como un centro de radiología o un médico particular. Tiene sólo baja lógica (excepto que se depure la base de datos, en cuyo caso hay que borrar, sólo si no tiene Autorizaciones asociadas, en cascada las tablas Direccion y PrestadorPrestacion). Solo puede darse de alta física si existe la referencia correspondiente a Direccion.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
cuit	VARCHAR(11)	Número de CUIT
nombre	VARCHAR(255)	Nombre legal de la entidad (no puede ser NULL)
fechaBaja	DATE	Si no es NULL, el Prestador fue dado de baja en la fecha indicada por este campo.
Email	VARCHAR(255)	La dirección de correo electrónico del prestador.
idDireccion	INT	No puede ser NULL

PrestadorPrestacion
Relación N a M entre Prestadores y Prestaciones. Se da de baja sólo cuando se da de baja un Prestador o una Prestación. Solo puede darse de alta física si existen las referencias correspondientes a Prestador y Prestacion.
Atributo	Tipo	Descripción
idPrestador	INT	Clave primaria interna de la base de datos
idPrestacion	INT	Clave primaria interna de la base de datos

Promotor
Persona encargada de atender a los Solicitantes que quieren afiliarse. No se puede dar de baja si tiene Solicitantes asociados. Si se da de baja, hay que dar de baja en cascada a la tabla Persona. Solo puede darse de alta física si existe la referencia correspondiente a Persona.
Atributo	Tipo	Descripción
idPersona	INT	Clave primaria interna de la base de datos

Solicitante
Persona esperando ser Afiliado a la obra social por un Promotor. Si se da de baja, hay que dar de baja en cascada la tabla Persona. Solo puede darse de alta física si existen las referencias correspondientes a Promotor (en caso que corresponda) y Titular (en caso que corresponda).
Atributo	Tipo	Descripción
idPersona	INT	Clave primaria interna de la base de datos
disponibilidad	VARCHAR(255)	Horario en el cual puede ser visitado expresado con texto libre
familiares	INT	Cantidad de integrantes del grupo familiar a afiliar.
observaciones	VARCHAR(255)	Observaciones que puedan ser de utilidad para el Promotor.
pendiente	BOOL	Indica si el solicitante fue visitado o no.
idPromotor	INT	NULL si no está asignado a ningún Promotor
idTitular	INT	NULL si no se va a agregar a un grupo familiar de un Titular existente

Zona
Región geográfica, cuya mínima unidad es un barrio. Solo se puede dar de baja si no tiene un Prestador asociado. Solo puede darse de alta física si existe la referencia correspondiente a CAP.
Atributo	Tipo	Descripción
id	INT	Clave primaria interna de la base de datos
nombre	VARCHAR(255)	Nombre de la Zona
descripcion	VARCHAR(255)	Descripción de la Zona
idCap	INT	No puede ser NULL

Análisis del volumen de datos

Realizamos una proyección estimando las instancias iniciales y el pico máximo de registro utlizando la columna T.Prom del inciso Composición física de las tablas, la cual indica el tamaño promedio en bytes de cada campo, teniendo en cuenta el tipo de dato físico y que es lo que se va a almacenar. A su vez se estimo un posible estado inicial de los datos contenidos en la obra social y que serán importados o cargados en el sistema a desarrollar.

Para confeccionar la siguiente tabla, sugerimos una tasa de crecimiento de datos, basados en entrevistas y/o estadísticas con el personal de la obra social.

Tabla	Tamaño promedio de una tupla [bytes]	Instancias Iniciales [tuplas]	Pico Máximo de Instancias [tuplas]	Tasa de crecimiento [tuplas/mes]
Afiliados	34	400.500	1.001.250	3.500,00
Autorizaciones	97	1.000.000	2.500.000	8.739,08
AutorizacionesManuales	115	100.000	250.000	873,91
CAPs	29	15	38	0,20
Categorías	40	50	125	0,10
Coberturas	24	15.075	37.688	0,10
Direcciones	58	981.185	2.452.963	8.802,20
HistoriasPlanes	22	520.650	1.301.625	3.850,00
Personas	66	901.170	2.252.925	8.752,00
Planes	71	5	13	0,05
Prestaciones	48	2.010	5.025	3,00
Prestadores	76	80.000	200.000	50,00
PrestadoresPrestaciones	8	80.400.000	201.000.000	50.325,00
Promotores	11	45	113	2,00
Solicitantes	99	500.625	1.251.563	5.250,00
Zonas	68	588.711	1.471.778	3.520,88

Espacio estimado

Tabla	Tamaño inicial estimado por mes [bytes]	Tamaño de pico máximo [bytes]	Proyección a 2 años [bytes]
Afiliados	13.617.000	34.042.500	99.297.000
Autorizaciones	97.000.000	242.500.000	707.337.079
AutorizacionesManuales	11.500.000	28.750.000	83.859.551
CAPs	435	1.088	4.611
Categorías	2.000	5.000	2.000
Coberturas	361.800	904.500	363.528
Direcciones	56.908.730	142.271.825	56.908.730
HistoriasPlanes	11.454.300	28.635.750	72.438.300
Personas	59.477.220	148.693.050	59.477.220
Planes	355	888	2.911
Prestaciones	96.480	241.200	96.480
Prestadores	6.080.000	15.200.000	8.816.000
PrestadoresPrestaciones	643.200.000	1.608.000.000	643.200.000
Promotores	495	1.238	16.335
Solicitantes	49.561.875	123.904.688	49.561.875
Zonas	40.032.348	100.080.870	212.414.633
TOTALES	989.293.038	2.473.232.595	1.993.796.252

Criterios de depuración

Conociendo los criterios de depuración se puede estimar el tamaño de los objetos de la base de datos, con lo cual esta sección esta ligada directamente con el análisis del volumen de datos. Estos procesos se almacenarán en las Tareas (Jobs) del motor de la base de datos (ver modelo 8) y se ejecutarán como instrucciones SQL.

Estos procesos se ejecutan luego del backup de la base de datos (Para que el backup este completo antes de la depuración).

Tabla	Frecuencia	Criterio
Afiliados	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior a 10 años respecto de la fecha actual. Se borra en cascada de la tabla HistoriaPlan los registros que hacen referencia a ellos y también en la tabla Persona los registros referenciados. Esto ocurre solo si los registros no están referenciados en esta tabla como titulares (idTitular).
Autorizaciones	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaRealizacion es anterior a 10 años respecto de la fecha actual. Se borran de la tabla todos lo registros en donde el campo FechaVencimiento es anterior a 10 años respecto de la fecha actual. Se borra en cascada los registros de AutorizacionesManuales.
AutorizacionesManuales	-	-
CAPs	-	-
Categorías	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior a 10 años respecto de la fecha actual y si no tiene prestaciones a que hagan referencia a ellas.
Coberturas	-	-
Direcciones	-	-
HistoriasPlanes	mensualmente	Se conserva el historial de los últimos 5 planes a los que perteneció el afiliado.
Personas	-	-
Planes	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior a 10 años respecto de la fecha actual. Se borran en cascada las Coberturas. Esto solo si no existen Afiliados e Historia de planes (HistoriaPlan) que hagan referencia a este Plan
Prestaciones	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior al año respecto de la fecha actual. Se borra en cascada las entradas en PrestadorPrestacion que contengan a estas Prestaciones. Esto solo si no existen Autorizaciones o Coberturas que hagan referencias a estas Prestaciones.
Prestadores	mensualmente	Se borran de la tabla todos lo registros en donde el campo FechaBaja es anterior a 10 años respecto de la fecha actual siempre y cuando no existan autorizaciones que hagan referencia a estos Prestadores. Se borra en cascada la Direccion y PrestadorPrestacion.
PrestadoresPrestaciones	-	-
Promotores	-	-
Solicitantes	-	-
Zonas	-	-

Alcance del Software

Se implementaron los casos de uso que responden a necesidades funcionales, y que hacen referencia a la actividad principal de la obra social. Las acciones secundarias o que pueden ser analizadas e implementadas en futuras versiones del presente trabajo (o software), son debidamente detalladas en el modelo número cuatro, Funciones complementarias al software.

A continuación, se puede ver en el el siguiente diagrama de casos de usos, los casos que son especificados en este trabajo. Estos son los encerrados por una linea punteada.

Diagrama de alcance

Funciones complementarias al Software

Importación inicial de datos

Una vez finalizada la instalación del sistema, será necesario realizar la importación de ciertos datos que son requisito fundamental para el funcionamiento del mismo y para los que no se diseñó una ventana que permita su ingreso o manipulación (debido a que son datos que se modifican muy raramente). Esta tarea será entonces llevada a cabo por la persona encargada de instalar el sistema. Los datos a importar son los referidos a las zonas (para ubicar CAP´s o bien para determinar el domicilio de los afiliados y relacionarlos así con el CAP más cercano). Los campos a cargar son nombre y descripción de cada zona.

Cruzar el reporte de consumo contra el reporte de aprobación/rechazo de prestaciones realizadas

Consideramos que el manejo de prestaciones que llegaron declaradas por un prestador y qué hacer si los datos enviados por el mismo no se corresponden con los asentados en el sistema, es tarea del sector de Pagos, ya que con criterios propios, ajenos a nuestro sistema (historial de relaciones con el prestador, deudas del afiliado, cantidad de rechazos anteriores, etc.), determinará qué acción tomar respecto a datos que no se correspondan. Son los encargados de ponerse en contacto con el sector correspondiente del Prestador para revisar y llegar a un acuerdo en cuanto a la acción a tomar frente a datos erróneos.

Ésta funcionalidad no está incluida en el sistema por no tener la información necesaria en el mismo como para tomar una decisión al respecto.

Revisar archivos rechazados del Prestador por formato incorrecto

Durante el proceso de la información (de prestaciones realizadas) que los Prestadores envían al Sistema, el Sistema determina si el archivo enviado cumple con el formato pactado y predefinido. Si no es así, ó si el CUIT de Prestador informado en el archivo no es correcto, dicho archivo se mueve a un directorio de “documentos rechazados” en el sitio FTP, y el Sistema envía un mail al Prestador para que éste determine las fallas en su documento, la corrección y volverlo a enviar como si fuera otro archivo distinto. Asimismo, el Sistema envía un mail al sector Pagos informando el nombre de archivo rechazado, el prestador asociado y la fecha de proceso del archivo, para que Pagos esté al tanto de los documentos rechazados y pueda actuar en consecuencia.

Armado de hoja de ruta

La inteligencia respecto al armado de la hoja de ruta que utilizará un promotor para visitar a una serie de solicitantes a los que intentará afiliar no se corresponde con una funcionalidad esencial que nuestro sistema deba contemplar, por lo tanto la confección de la misma queda relegada al actor Enrutador. Éste, a través de consultas al sistema (zonas cargadas inicialmente, datos de los promotores y de los solicitantes pendientes de visita) confecciona la hoja de ruta tendiendo en cuenta las ubicaciones relativas (es decir, la zona en la que habita el solicitante respecto a la zona en la que se encuentra el CAP en el que trabaja el promotor, buscando que sean lo más cercanas posible) y la disponibilidad horaria de los solicitantes en cuestión. Este listado es enviado por email. Los datos que figuran en este formulario son: tipo y número de documento, nombre y apellido del promotor; tipo y número de documento, nombre completo, dirección, disponibilidad horaria y cantidad de familiares del solicitante. (ref. modelo 5: especificación del listado Hoja de Ruta).

Entrega al promotor de planes a ofrecer a solicitantes

Cuando un promotor visita a un solicitante lleva consigo folletería para ofrecerle distintos planes. El diseño, impresión y encuadernado de los folletos es realizado fuera del sistema a través de una imprenta, ya que no se considera algo esencial para su funcionalidad y sería una inversión extra en materiales (impresoras, papel, tinta, diseñadora, etc.). Una vez impresa la folletería se entrega una cantidad determinada a cada promotor para que él distribuya entre los solicitantes como lo considere conveniente.

Entrega de formularios de carga de solicitantes

Cuando un promotor visita a un solicitante toma nota de los datos personales del mismo y de los familiares que desea afiliar en caso que lo desee. El listado de carga de solicitantes utilizado para completar los datos es documentación impresa fuera del sistema. Se distribuyen varias copias para cada promotor, de modo que siempre pueda disponer de la cantidad suficiente para utilizar en las visitas. Los datos que deben figurar en estos formularios son: tipo y número de documento del titular, tipo y número de documento del familiar (sólo en caso de que el solicitante forme parte de un grupo familiar del que no es titular), dirección, teléfono, código postal, provincia, sexo, e-mail, plan elegido para afiliación y fecha de nacimiento del solicitante. Para control interno deben figurar los siguientes datos del promotor: tipo, número de documento y nombre y apellido (ref. modelo 5: listado de carga de solicitantes)

Confección y reparto de carnets de afiliados

La confección y la distribución (por correo o personal) de los carnets que se confeccionan al momento de afiliar a un solicitante o grupo familiar, queda excluida del alcance del sistema debido a que no constituye una funcionalidad esencial y requiere una inversión extra para obtener hardware específico para la confección de los carnets (debido a la impresión en plástico, hologramas, bandas magnéticas, etc.), por lo tanto es tercerizado al Departamento de Servicios al Cliente, que recibe los datos necesarios para imprimir el carnet y luego enviarlo al afiliado..

Impresión y reparto de Cartilla médica

Decidimos dejar afuera del sistema la impresión de la cartilla, por no considerar necesaria la inversión requerida para su diseño, impresión y envío a los afiliados, ya que esta es una funcionalidad auxiliar del sistema. Los datos requeridos para confeccionar una cartilla de un plan son enviados al Departamento de Servicios al Cliente, que se encargará de la impresión y entrega de la misma a los afiliados.

Pagos de los afiliados

El manejo de pagos por parte de los afiliados a la obra social, queda excluido del alcance de nuestro sistema, debido a que solo es necesario saber si un afiliado no está al día con sus pagos (moroso). No consideramos entonces esta característica a la hora de la implementación.

Verificacion por parte del prestador, de una autorización manual

Los prestadores verificaran las autorizaciones manuales por telefono, comunicandose con uno de nuestros operadores, quien le confirmará si los datos que poseen acerca de la autorización manual son correctos.

Diseño de interfaces

Interfaces con el usuario

Introducción

El presente documento deberá ser interpretado como el estándar a nivel de diseño de interfaces de usuario en el momento de construir la aplicación, de modo tal que las interfaces con el usuario sean homogéneas.

El diseño de las interfaces estará basado en la utilización del Toolkit Gtk+ (http://www.gtk.org/) y todas las ventanas deberán cumplir con las Human Interface Guidelines (versión 2.0) del proyecto Gnome.

Un resumen de estas especificaciones se puede encontrar al final de este documento.

La especificación esta pensada para utilizar el toolkit Gtk . Dos de las características mas importantes de este toolkit es que soporta nativamente i18n y l10n, y por otro lado soporta temas. Es por eso, que a lo largo del documento es posible que vea textos de botones en inglés, iconos distintos para el mismo botón y cambios que, a primera vista, parecen cosas diferentes, cuando en realidad es el mismo ejemplo solo corriendo en entornos diferentes.

Esto se ha considerado hacerlo de esta forma, para mostrar distintas variantes a fin de familiarizar al desarrollador con la herramienta elegida.

Aspectos Generales

Si bien existirán diversas pantallas en toda la aplicación para los distintos circuitos de la misma, el formato de la interfaz debe ser homogéneo para toda la aplicación. El propósito de esta sección del documento es de definir y especificar esa homogeneidad.

Todas las ventanas deberán ajustar su diseño a una ventana de 800x600 pixels (Considerar 720x600 descartando posibles paneles o barras del sistema operativo). Cualquier cambio en el tamaño de la pantalla deberá replicarse relativo al mismo y reformular esta documentación.

Alertas

Objetivos

Informar al usuario posibles consecuencias de una acción o finalización de procesos.

Especificacion

Las alertas deberán ser usadas en aquellos lugares donde los CUSO o el SISTEMA requieran informar algo al usuario. Por ejemplo : Perdida de conexión con la base de datos; Confirmación antes de eliminar; Notificación de proceso éxito en Pedido de Autorización Manual

Funcionamiento

Los mensajes de alerta se mostrarán utilizando un dialogo de mensaje modal, con un icono descriptivo al tipo de error y un texto indicando el problema. Con esto lo que se intenta expresar, es que debe tener significancia instantánea ante los ojos del usuario, con lo cual se deben ubicar cerca de donde se produjo una anomalía. A modo de ejemplo, un formato erróneo introducido en una caja de texto podría llevar a un error cuando se realice luego una transacción de datos, con lo cual el mensaje de alerta debe ir por debajo de la caja de texto.

Ejemplos

La alerta de tipo Error sera emitida cuando se de una condición irrecuperable, como se la perdida de conexión con la base de datos. Contara solamente con un botón Cerrar y deberá abortar la aplicación en caso de ser necesario.

Este dialogo informa de una operación terminada exitosamente. Por ejemplo, al cargar un nuevo registro en un ABM, con un mensaje que diga “La operación fue realizada correctamente”.

Las preguntas deberán ser usadas en casos donde el usuario pueda cometer errores, pero sin afectar el funcionamiento normal de la aplicación. Por ejemplo, un dialogo que al cancelar una acción le pregunte si esta seguro de querer cancelar un ABM.

Este dialogo es parecido al anterior, solo de que debe ser usado cuando el resultado de la operación sea critico o no reversible. Por ejemplo, antes de eliminar un registro o dar de baja un afiliado, debería aparecer un dialogo de confirmación de Advertencia. Se deberá informar las posibles consecuencias de la acción.

Ventana Principal

Objetivos

Centralizar el acceso a las distintas funcionalidades del sistema y proveer de la interfaz de login del sistema.

Especificacion

No corresponde

Funcionamiento

La ventana principal tendrá una barra de menú en la parte superior y una barra de estado en la parte inferior. En el centro se encontrará el nombre de a aplicación justo con los datos de la filial de la obra social, su número de cuit, dirección y todos los datos con los que se identifica el usuario.

Ventanas de Consulta

Objetivo

Permitir al usuario consulta de datos, ya sea para informar a terceros como para consulta interna.

Especificacion

Todos los casos de uso Consultar , como ser Consultar Afiliado, Consultar Planes, etc

Funcionamiento

Todas la ventanas que impliquen consultas estarán organizadas como se especifica a continuación.

En la parte superior izquierda se mostrarán los criterios de búsqueda posibles, alineados en un contenedor de tipo tabla. El botón de buscar será definido por un StockButton de tipo "Buscar", ubicado en la última fila alineado a la derecha.

Los criterios de búsqueda deberán ser tomados siguiendo las siguientes pautas :

Deberán figurar al menos los campos claves únicos de los objetos (como ser Tipo y Numero de Documento para Afiliados)

Deberán estar los campos triviales al momento de requerir información, como ser Apellido y Nombre para el mismo caso de Afiliado. Dirección es un claro ejemplo de un filtro que no es útil y no debería encontrarse

Claves foráneas. Los datos principales de aquellas relaciones de herencia o composición que la clase de dominio tenga con alguna otra.

Debajo de este se encontrará una lista (representada por un control TreeView con modelo ListStore) donde se muestran los registros que cumplan con los criterios de la búsqueda. En la parte inferior se encontrará un botón con el texto "Ver" sin icono.

Las columnas a agregar en la lista deberán ser :

Todos los datos relacionados con los criterios de búsqueda

Aquellos datos de mayor importancia del dominio

Si la búsqueda retorna mas de N elementos (siendo N un valor configurable por el administrador del sistema) se deberá avisar al usuario que su búsqueda a arrojado demasiados elementos y si desea mostrarlos todos o acotar la búsqueda introduciendo nuevos criterios. Esto es a fin de maximizar la performance y minimizar el consumo de ancho de banda.

En la parte derecha del layout se encontrarán los datos a mostrar, según corresponda. Si la ventana lo requiere, pueden existir botones en la parte inferior de esta área para acceder a datos extra o secundarios.

La ventana donde se muestran estos datos deberá ser un diálogo modal, con un botón de cerrar (StockButton CLOSE) en la parte inferior derecha del mismo.

Ejemplo

Diagrama de Transicion de Estados

Ventanas ABM

Estas ventanas serán para carga de datos. Existen diferentes variantes que iremos especificando a lo largo de la sección.

ABM Básico

Objetivo

Permitir ingreso de datos para clases simples del dominio.

Especificacion

Algunas clases del dominio que encajan en esta categoría:

Categorías

Cap

Prestación

Funcionamiento

Presentan típicamente solo campos de caja de entrada, listas de selecciona, radio buttons y checkboxes. Los campos a mostrar serán aquellas propiedades del objeto del dominio que sean modificables por el usuario y no requieran de un proceso a parte (como las fechas de baja de algunos elementos).

El diálogo de carga será modal, con botones de Aceptar y Cargar ubicados como se ilustra. Dentro del mismo se deberá encontrar una tabla, con separación de columnas y filas seteada en 8 pixels, en 2 columnas. La columna de la izquierda contendrá etiquetas identificadores del campo a modificar, con el texto alineado a la izquierda. En la columna de la derecha se deberá poner el objeto para el ingreso del dato.

Para el caso de Modificación, si algún campo no puede ser modificado, deberá desactivarse dicho campo para modificación solamente, pero deberá ser mostrado su valor actual.

ABM Complejos

Objetivos

Existen diversos casos donde la ventana de carga de datos debe ser mas elaborada, permitiendo cargar incluso relaciones entre distintas clases del dominio. Veremos a continuación algunos aspectos a tener en cuenta para la creación de las pantallas.

Especificacion

Otras ventanas que encajan en esta categoría

ABM Promotor

ABM Afiliado

Funcionamiento

Como ejemplo usaremos la clase Solicitante. Si observamos el diagrama de clases, el solicitante es una persona (hay una herencia) y su vez tiene una composición con una Dirección. Para crear la ventana, se deberá utilizar un frame por cada relación (herencia o composición), debidamente identificada con un nombre representativo de la composición.

En este ejemplo, la ventana tendrá 3 frames:

Datos Personales

Dirección

Solicitud

Dentro de cada frame, deberá existir una matriz cuyos elementos sigan las reglas especificadas en el punto ABM Básico, especificado anteriormente.

Siguiendo este esquema, la ventana de Alta de Afiliado sera igual a la mostrada en el Ejemplo 1, pero en lugar de contener la sección Solicitud, tendrá una sección Plan, donde se detalle el plan actual. Así mismo, tendrá otra sección con botones “Consultar Historial de Planes” y “Consultar Autorizaciones” donde se podrá observar los planes a los que ha pertenecido (o pertenece) y las autorizaciones aprobadas o rechazadas del Afiliado.

La ventana de AMB de Promotor sera igual a la del Ejemplo 1, salvo que no contendrá la sección Solicitud. Los Solicitantes asociados no se muestran aquí ya que para eso existe la vista Emitir Hoja de Ruta.

Las ventanas de ABM de planes se ejemplifica en el Ejemplo 2 con su Diagrama de Transición de Estados correspondiente.

Ejemplo 1

ABM de Relaciones

Objetivo

Asociar datos entre dos entidades del dominio

Especificacion

Funcionamiento

Este tipo de ventanas esta pensado para, por ejemplo, relacionar un Promotor con un Solicitante, en Emitir Hoja de Ruta.

Luego de seleccionar de una lista de Promotores un elemento, se obtienen los Solicitantes libre y los asignados a dicho promotor. Los libres deben ser cargados en una lista de tipo TreeView y los asignados en una lista a la derecha. Entre ambas listas deberán encontrarse 2 stock button : Agregar y Borrar, como se ve en el ejemplo.

El botón Agregar deberá pasar un elemento de la lista izquierda a la de la derecha y el Borrar en sentido opuesto. Los cambios deberán ser registrado solo cuando el botón Aceptar sea presionado

Ejemplo

Pedido de Autorización Manual

Objetivos

Registrar un pedido de Autorización Manual

Especificacion

Caso de Uso : Pedido de Autorización Manual

Funcionamiento

Los botones marcados como "..." son de búsqueda. En el caso de que el operador no recuerde los códigos, dispondrá de la ventana de búsqueda para encontrar el código por varios criterios (Ver la sección más adelante sobre Ventanas de Búsqueda).

La ventana además presenta 2 posibles alertas, que pueden o no ser tomadas en cuenta por el Operador que cargue la Autorización. Una es acerca del estado de cuenta y otra sobre el límite de prestaciones anual del afiliado.

Ejemplo

Pantallas de Búsqueda

Objetivo

Ayudar al usuario a encontrar códigos referidos en distintos casos de uso

Especificacion

No corresponden a ninguna caso de uso particular.

Funcionamiento

Estas pantallas son auxiliares y no pertenecen a un caso de uso. La idea es utilizar estas pantallas de manera reutilizable en donde sean necesarias búsquedas para ayudar al usuario a encontrar códigos necesarios para otras pantallas.

El botón "Seleccionar" tendrá como acción cerrar el diálogo y completar el campo correspondiente de la ventana que lo llamó.

Los criterios de búsqueda se seleccionarán en cada caso, atendiendo a los campos más representativos del registro.

Ejemplo

Mantener Planes

Este caso será utilizado para utilizado para ejemplificar como se realizan las vistas de todos los casos “Mantener”.

Objetivos

Agregar, Modificar o Eliminar datos en tablas.

Especificacion

Caso de Uso : Mantener Planes, Mantener Caps, Mantener Afiliados, Mantener Prestaciones, etc.

Funcionamiento

Cada caso de uso comienza mostrando una ventana como la siguiente :

La ventana presenta una lista (TreeView) con un modelo ListStore y 3 botones : Agregar , Propiedades y Borrar.

En la lista deberán aparecer los datos principales de la clase del dominio.

Opcionalmente, puede incluirse antes de la lista un sección de búsqueda, para los casos donde la cantidad de elementos pueda llegar a ser grande. En recomendable utilizar este ítem en Mantener Planes, por ejemplo.

Los 3 botones ejecutarán como acción la ventana de “Alta”. Para el caso de Agregar, todos sus campos estarán vacíos. En el caso de modificación, solo deberán estar sensibles aquellos que puedan ser modificados desee este caso de uso.

Para el caso de borrar solo se mostrarán los campos sin sensibilidad (es decir, no modificables) para información del usuario antes de realizar la operación.

Para el casos complejos como Mantener Afiliados o Mantener Planes, la venta tendrá a su vez operaciones de ABM sobre los campos que lo requieran, para el manejo de las colecciones nacidas en base a composiciones con otras clases del dominio. Como se ejemplifica en la ventana de más arriba.

Las ventanas de ABM de las relaciones son todas ABM Básicos como ya se habló en los puntos anteriores.

Un ejemplo para el caso de Mantener Planes, es la alta de una Cobertura :

Actualizar Autorizacion Manual

Esta ventana es tal vez una de las más complejas e importantes, es por eso que haremos un alto para mostrar y definir como debe funcionar.

Objetivos

Aprobar o Rechazar las autorizaciones manuales

Especificacion

Caso de Uso : Actualizar Autorización Manual.

Funcionamiento

Al auditor médico se le presenta la siguiente pantalla :

Lo que se muestra en la imagen es solo el esqueleto. La lista presentará por cada fila todas las autorizaciones pendientes de aprobación o rechazo, con las siguientes columnas :

Código de autorización

Fecha Solicitud

Tipo y número de documento

Apellido del Afiliado

Observaciones de la Solicitud

Las filas deberán estar ordenadas inicialmente por Fecha de Solicitud, pero clickeando sobre los títulos de las columnas el Auditor Médico podrá cambiar este orden.

Al seleccionar una autorización y presionar el botón “Revisar” se despliega la siguiente ventana :

La ventana está dividida en 3 secciones diferentes, cada una brindando información acerca de diferentes aspecto que el auditor utilizará para evaluar la resolución final.

Las secciones son bastante claras y no necesitan mucha explicación, solo haremos algunas aclaraciones de alguna de ellas.

Estado de cuenta : El auditor médico solo requiere saber si el afiliado es o no moroso, por eso solo muestra el mensaje simple. El valor entre corchetes rectos indica que esa palabra puede o no aparecer.

Plan : Inicialmente el usuario recibe un mensaje indicando si la prestación está o no cubierta en el plan actual del cliente. Se puede ejecutar una acción de consulta sobre el Plan presionando el botón “Consultar Plan” (ver la sección de ventanas Auxiliares detallada más arriba para el formato de esta ventana).

Consumo de esta Prestación : Se informa cuantas prestaciones se ha realizado en este año el Afiliado (para la prestación pedida) y el límite anual indicado en la Cobertura del Plan vigente. El auditor puede Consultar todos los consumos de esta prestación presionando “Consultar Consumos” (solo se verán los consumos relacionados con la prestación en cuestión, no todos los consumos).

Consultar Autorización

Objetivos

Ver los datos principales de una autorización en caso de necesidad interna o consulta externa por parte de Afiliados o Prestadores.

Especificacion

Caso de Uso : Consultar Autorización

Funcionamiento

Esta ventana es de especial importancia explicar su funcionamiento ya que rompe con los esquemas mencionados anteriormente.

El principal motivo de esto es la gran cantidad de información que maneja, tanto a nivel relaciones como en volumen de datos.

No sería óptimo ni funcional utilizar listas como en ejemplos anteriores ya que solo harían inusable la aplicación desde todo punto de vista.

La ventana estará organizada de la siguiente manera :

El funcionamiento básico está definido en el caso de uso correspondiente.

Por si el programador no está familiarizado con la notación de expresiones regulares, aclararemos que las etiquetas que contiene valores como “[Elemento1|Elemento2]” significa que esa etiqueta deberá tomar uno de esos posibles valores como texto.

Los botones de búsqueda disparan diálogos modales con ventanas de consulta (ver sección correspondiente más arriba) en el caso de búsqueda por Afiliado y Auditor médico, y diálogos de entrada de datos en el caso de búsquedas por código o fecha.

Los 4 botones ubicados abajo de la ventana son la barra de navegación. Ellos permiten desplazarse entre los diferentes registros que concuerdan con el criterios de búsqueda.

Por último, el botón “Cerrar”, cierra el diálogo.

Anexo – HIG Gnome

Las Human Interface Guidelines del proyecto Gnome son el lineamiento básico que cualquier aplicación debe seguir si pretende integrarse con el desktop Gnome en GNU/Linux.

Fueron seleccionadas como el estándar a seguir ya que el target de la aplicación fue un desktop Gnome corriendo en cajas con GNU/Linux, creando una solución Open Source en su totalidad.

El documento completo consta de unas 160 páginas, y fue realizado tras varios estudios de usabilidad realizados por los laboratorios de Sun Microsystem en el año 2000 y es continuamente actualizado. La versión en que nos basaremos será la 2.0.

Este estándar define varios puntos a tener en cuenta :

Principios de usabilidad

Integración con el Desktop

Ventanas

Menús

Toolbars

Controles (entrada de texto, listas, etc)

Feedback

Diseño visual

Íconos

Como puntos más destacados. Como nos hemos limitado a utilizar la mayoría de los controles e iconos estándar, varias de las secciones anteriores no nos son de importancia, por lo que solo resumiremos algunos conceptos importantes para entender el armado de las ventanas.

Nos centraremos en la parte de diseño visual, ya que es la más importante en nuestro caso.

Como primer punto, veamos la diferencia entre las siguientes imágenes :

Como puede observarse en el caso de la derecha, la separación en secciones utilizando un indentado proporciona una mayor claridad de los datos agrupados.

Las separaciones de los distintos componentes, bordes y alienaciones se pueden resumir en el siguiente ejemplo :

Diseño de listados

Reporte de autorizaciones rechazadas

Documento relacionado	Descripción
M01 - Diagramas de Clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación del Caso de Uso Generar Reporte Autorizaciones Rechazadas	Especificación del CU
M01 – Reporte Autorizaciones Controller	Especificación del controlador

Especificación del listado

Cada registro del listado carga los siguientes datos:

Afiliado.Codigo

Afiliado.Nombre

Afiliado.Apellido

Afiliado.TipoDocumento

Afiliado.NroDocumento

Afiliado.Moroso

Plan.Codigo

Plan.Descripcion

Prestacion.Codigo

Prestacion.Nombre

Autorizacion.Codigo

Autorizacion.Tipo

Autorizacion.FechaSolicitud

Autorizacion.FundamentosResolucion

Si la autorización es de tipo manual se carga:

Autorizacion.Observaciones

Autorizacion.FechaResolucion

Autorizacion.NroLegajo

Si es automática estos campos quedan en blanco.

Estructura del archivo

Nombre del archivo: AA_MM _AUT_RECHAZADAS.txt

AA: 2 dígitos del año al cual correponde el archivo

MM: 2 dígitos del mes al cual corresponde el archivo.

AUT_RECHAZADAS: constante para que se identifique el archivo.

Formato de un registro del archivo:

Cada registro es CSV y contiene los campos detallados en el punto 1.

Ejemplo:

1,José,Pérez,DNI,28806868,0,210,Plan 210,10101, tratamiento quirúrgico del encefalomeningocele, 10, manual, 20050601, rechazada por carencia, intervención quirúrgica urgente, 20050603, 1230

2560, Florencia, Gómez, LC, 5456210, 1, 110, Plan 110, 220101, colposcopía, 120, automatica, 20050620, , , ,

125, Juan, López, LE, 8654123,4, 210, Plan 210, 300202, Paquimetría computarizada, 260, automatica, 20050623, afiliado inactivo, , ,

Porcentaje de rechazos

Formato del Archivo “porcentaje_rechazos.dat”

Este es un archivo binario donde los primeros 4 bytes corresponden al total de autorizaciones aprobadas, los segundos 32 bytes son el total de autorizaciones rechazadas, y luego apareceran una serie de boques de longitud fija donde los primeros 8 bytes serán el código de prestación, luego 100 bytes para el nombre de la prestación y por último 4 bytes para el porcentaje de rechazos.

Ejemplo:

[total_aprobadas]

[total_rechazadas]

[codigo_prestacion][nombre_prestacion][porcentaje_rechazos]

[codigo_prestacion][nombre_prestacion][porcentaje_rechazos]

[codigo_prestacion][nombre_prestacion][porcentaje_rechazos]

[codigo_prestacion][nombre_prestacion][porcentaje_rechazos]

[codigo_prestacion][nombre_prestacion][porcentaje_rechazos]

[codigo_prestacion][nombre_prestacion][porcentaje_rechazos]

...

[codigo_prestacion][nombre_prestacion][porcentaje_rechazos]

Hoja de ruta

Documento relacionado	Descripción
M01 - Diagramas de Clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación del Caso de Uso Emitir Hoja de Ruta	Especificación del CU

Especificaciones del listado:

La hoja de ruta está formada por un encabezado que contiene los datos del promotor para el cual fue realizada. El contenido del listado es una tabla con los datos necesarios del solicitante para que pueda ser visitado por el promotor.

Datos necesarios para llenar el listado:

Datos del Encabezado:

promotor.TipoDocumento

promotor.NroDocumento

promotor.Nombre

promotor.Apellido

Datos requeridos para confeccionar el listado:

solicitante.TipoDocumento

solicitante.NroDocumento

solicitante.Nombre

solicitante.Apellido

solicitante.Direccion

solicitante.Disponibilidad

solicitante.Observaciones

solicitante.Familiares

Esquema del documento:

HOJA DE RUTA
TIPO DOCUMENTO	NUMERO DOCUMENTO	NOMBRE Y APELLIDO
Tipo y NroDoc	Nombre	Dirección	Disponibilidad	Familiares

Formulario de carga de solicitantes

Especificaciones del listado:

El listado de carga de solicitantes es entregado al promotor vacío para que en las sucesivas visitas que debe realizar complete los datos tanto del solicitante como de los familiares del mismo si es que desea afiliarlos también.

En el caso de carga de los datos de un solicitante que será afiliado titular no se cargan los campos tipoDoc y nroDoc familiar. El promotor completa el encabezado del formulario cuando lo utilice. Inicialmente es una hoja sin datos cargados por el sistema.

Esquema del documento:

CARGA SOLICITANTES
TIPO DOCUMENTO PROMOTOR	NUMERO DOCUMENTO PROMOTOR	NOMBRE Y APELLIDO PROMOTOR
Tipo y NroDoc titular	Tipo y NroDoc familiar	Nombre y Apellido	Dirección	Email	Teléfono	CP	Provincia	Sexo	Plan	Fecha Nacimiento

Cartilla médica

Documento relacionado	Descripción
M01 - Diagramas de Clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación del Caso de Uso Armar Cartilla	Especificación del CU
M01 – Armar Cartilla Controller	Especificación del controlador

Especificación de la cartilla

La cartilla médica contiene:

datos identificatorios de la obra social;

datos identificatorios del plan;

datos de las coberturas del plan se detallan, para cada una, los datos descriptivos de la cobertura (tiempo mínimo de permanencia en el plan para acceder a la cobertura, porcentaje de cobertura, tipo de autorización requerida y cantidad máxima permitida por año)

A continuación se cargan los prestadores que brindan esa cobertura separados por zona.

Formato del archivo a enviar al Dpto. Servicios al Cliente

Nombre del archivo: AAAA-MM-DD_COD-PLAN.xml

AAAA: 4 dígitos del año en que se confeccionó el archivo

MM: 2 dígitos del mes en que se confeccionó el archivo.

DD: 2 dígitos del día en se confeccionó el archivo.

COD_PLAN: código del plan sobre el cual se generó la cartilla médica.

Formato del archivo:

El formato de cada archivo es XML 1.0.

El archivo XML tiene un nodo principal (PLAN) y a continuación distintos nodos secundarios (detalle del plan, detalle CAPS, detalle coberturas). A continuación se muestra un ejemplo.

No se utiliza un schema para la construcción dado que no se necesitan validaciones. Solo se utiliza este formato porque es más claro visualmente para cuando el Dpto. Servicios al Cliente obtenga la información para armar la cartilla.

Ejemplo formato:

<?xml version="1.0" encoding="UTF-8"?>

<PLAN>

<detallePlan>

<codigo>plan.Codigo</codigo>

<categoria>plan.Categoria</categoria>

<descripcion>plan.Descripcion</descripcion>

<permanenciaMinima>plan.PermanenciaMinima</permanenciaMinima>

</detallePlan>

<CAPS>

<CAP>

<codigo>CAP.Codigo</codigo>

<horario>CAP.Horario</horario>

<direccion>

<calle>CAP.Direccion.Calle</calle>

<numero>CAP.Direccion.Numero</numero>

<piso>CAP.Direccion.Piso</piso>

<dpto>CAP.Direccion.Departamento</dpto>

<codPostal>CAP.Direccion.codigoPostal</codPostal>

<provincia>CAP.Direccion.Provincia</provincia>

<telefono>CAP.Direccion.Telefono</telefono>

</direccion>

</CAP>

<CAP>

<codigo>CAP2.Codigo</codigo>

<horario>CAP2.Horario</horario>

<direccion>

<calle>CAP2.Direccion.Calle</calle>

<numero>CAP2.Direccion.Numero</numero>

<piso>CAP2.Direccion.Piso</piso>

<dpto>CAP2.Direccion.Departamento</dpto>

<codPostal>CAP2.Direccion.codigoPostal</codPostal>

<provincia>CAP2.Direccion.Provincia</provincia>

<telefono>CAP2.Direccion.Telefono</telefono>

</direccion>

</CAP>

</CAPS>

<COBERTURAS>

<cobertura>

<porcentaje>cobertura.Porcentaje</porcentaje>

<tipoAutorizacion>cobertura.TipoAutorizacion</tipoAutorizacion>

<carencia>cobertura.Carencia</carencia>

<limiteAnual>cobertura.LimiteAnual</limiteAnual>

<ZONA>

<nombre>zona.nombre</nombre>

<PRESTADORES>

<prestador>

<CUIT>prestador.CUIT</CUIT>

<nombre>prestador.Nombre</nombre>

<email>prestador.EMail</email>

<direccion>

<calle>prestador.Direccion.Calle</calle>

<numero>prestador.Direccion.Numero</numero>

<piso>prestador.Direccion.Piso</piso>

<dpto>prestador.Direccion.Departamento</dpto>

<codPostal>prestador.Direccion.codigoPostal</codPostal>

<provincia>prestador.Direccion.Provincia</provincia>

<telefono>prestador.Direccion.Telefono</telefono>

</direccion>

</prestador>

<prestador>

<CUIT>prestador2.CUIT</CUIT>

<nombre>prestador2.Nombre</nombre>

<email>prestador2.EMail</email>

<direccion>

<calle>prestador2.Direccion.Calle</calle>

<numero>prestador2.Direccion.Numero</numero>

<piso>prestador2.Direccion.Piso</piso>

<dpto>prestador2.Direccion.Departamento</dpto>

<codPostal>prestador2.Direccion.codigoPosta</codPostal>

<provincia>prestador2.Direccion.Provincia</provincia>

<telefono>prestador2.Direccion.Telefono</telefono>

</direccion>

</prestador>

</PRESTADORES>

</ZONA>

<ZONA>

<nombre>zona2.nombre</nombre>

<PRESTADORES>

<prestador>

<CUIT>prestador.CUIT</CUIT>

<nombre>prestador.Nombre</nombre>

<email>prestador.EMail</email>

<direccion>

<calle>prestador.Direccion.Calle</calle>

<numero>prestador.Direccion.Numero</numero>

<piso>prestador.Direccion.Piso</piso>

<dpto>prestador.Direccion.Departamento</dpto>

<codPostal>prestador.Direccion.codigoPostal</codPostal>

<provincia>prestador.Direccion.Provincia</provincia>

<telefono>prestador.Direccion.Telefono</telefono>

</direccion>

</prestador>

<prestador>

<CUIT>prestador2.CUIT</CUIT>

<nombre>prestador2.Nombre</nombre>

<email>prestador2.EMail</email>

<direccion>

<calle>prestador2.Direccion.Calle</calle>

<numero>prestador2.Direccion.Numero</numero>

<piso>prestador2.Direccion.Piso</piso>

<dpto>prestador2.Direccion.Departamento</dpto>

<codPostal>prestador2.Direccion.codigoPosta</codPostal>

<provincia>prestador2.Direccion.Provincia</provincia>

<telefono>prestador2.Direccion.Telefono</telefono>

</direccion>

</prestador>

</PRESTADORES>

</ZONA>

</cobertura>

</COBERTURAS>

</PLAN>

Información de carnets

Documento relacionado	Descripción
M01 - Diagramas de Clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación del Caso de Uso Enviar Información Carnets	Especificación del CU
M01 – Carnets Controller	Especificación del controlador

Especificación del listado

El listado contiene los datos de los afiliados necesarios para confeccionar y enviar los carnets.

Código del afiliado

Nombre del afiliado

Apellido del afiliado

Código del plan del afiliado

Fecha de afiliación del afiliado

Dirección del afiliado (calle, número, piso, departamento, código postal, provincia, teléfono)

Formato del archivo a enviar al Dpto. Servicios al Cliente

Nombre del archivo: AAAA-MM-DD_DATOS_CARNETS.xml

AAAA: 4 dígitos del año en que se confeccionó el archivo

MM: 2 dígitos del mes en que se confeccionó el archivo.

DD: 2 dígitos del día en se confeccionó el archivo.

DATOS_CARNETS: dato constante para que el departamento identifique el archivo recibido.

Formato del archivo:

El formato de cada archivo es XML 1.0.

El archivo XML tiene un nodo principal (AFILIADOS) y a continuación nodos secundarios (AFILIADO) con los datos de los afiliados mencionados en el punto 1. A continuación se muestra un ejemplo.

No se utiliza un schema para la construcción dado que no se necesitan validaciones. Solo se utiliza este formato porque es más claro visualmente para cuando el Dpto. Servicios al Cliente obtenga la información para confeccionar y enviar los carnets.

Ejemplo formato:

<?xml version="1.0" encoding="UTF-8"?>

<AFILIADOS>

<AFILIADO>

<codigo>afiliado.Codigo</codigo>

<nombre>afiliado.Nombre </nombre>

<apellido>afiliado.Apellido</apellido>

<codigoPlan>codigoPlan</codigoPlan>

<fechaAfiliacion>afiliado.FechaAfiliacion</fechaAfiliacion>

<direccion>

<calle>Afiliado.Direccion.Calle</calle>

<numero> Afiliado.Direccion.Numero</numero>

<piso> Afiliado.Direccion.Piso</piso>

<dpto> Afiliado.Direccion.Departamento</dpto>

<codPostal> Afiliado.Direccion.codigoPostal</codPostal>

<provincia> Afiliado.Direccion.Provincia</provincia>

<telefono> Afiliado.Direccion.Telefono</telefono>

</direccion>

</AFILIADO>

<AFILIADO>

<codigo>afiliado2.Codigo</codigo>

<nombre>afiliado2.Nombre </nombre>

<apellido>afiliado2.Apellido</apellido>

<codigoPlan>codigoPlan2</codigoPlan>

<fechaAfiliacion>afiliado.FechaAfiliacion</fechaAfiliacion>

<direccion>

<calle>Afiliado2.Direccion.Calle</calle>

<numero> Afiliado2.Direccion.Numero</numero>

<piso> Afiliado2.Direccion.Piso</piso>

<dpto> Afiliado2.Direccion.Departamento</dpto>

<codPostal> Afiliado2.Direccion.codigoPostal</codPostal>

<provincia> Afiliado2.Direccion.Provincia</provincia>

<telefono> Afiliado2.Direccion.Telefono</telefono>

</direccion>

</AFILIADO>

</AFILIADOS>

Actualización de prestaciones

Documento relacionado	Descripción
M01 - Diagramas de Clases	Diagramas de clases de dominio, de control y de persistencia.
M01 - Especificación del Caso de Uso Mantener Prestaciones	Especificación del CU
M01 – Prestaciones Controller	Especificación del controlador

1.	Especificación del listado

Es responsabilidad de quien envía el path del archivo que tenga tanto el nombre como el formato correcto, caso contrario no se realizarán las modificaciones.

El codigo y nombre de la prestación son los que serán modificados a partir del modificador del registro (A-B-M).

El codigo y nombre de categoria son las asociadas a la prestación, si la categoría no existe en el sistema y debe ser asociada a la prestación es dada de alta;

Si se modifican los datos de la prestación se verifica que el nombre de la categoría contenido en el registro sea el mismo sino se modifica.

Si se elimina la prestación (modificador B) se desasocia la categoria a la prestación, si la categoria no tiene prestaciones asociadas también se da de baja en el sistema asociando fecha de baja como la actual.

2.	Formato del archivo para mantener prestaciones

·	Nombre del archivo: AAAA-MM-DD_PRESTACIONES.csv

1.	AAAA: 4 dígitos del año en que se confeccionó el archivo

2.	MM: 2 dígitos del mes en que se confeccionó el archivo.

3.	DD: 2 dígitos del día en se confeccionó el archivo.

4.	PRESTACIONES: constante para identificar el tipo de archivo.

·	Formato del archivo:

El archivo es csv.

Controla la estructura del archivo, que debe poseer los campos:

·	codigoPrestacion: alfanumérico de hasta 7 caracteres

·	nombrePrestacion: cadena de hasta 200 caracteres.

·	codigoCategoria: alfanumérico de hasta 7 caracteres

·	nombreCategoria: cadena de hasta 200 caracteres.

·	modificador: char A-B-M

3.	Ejemplo archivo:

101, tratamiento quirúrgico del encefalomeningocele, 10, operaciones en el sistema nervioso, A

102, tratamiento quirúrgico craneostenosis, 10, operaciones en el sistema nervioso, B

605, tratamiento del aneurisma o de las fístulas arteriovenosas, 70, Operaciones en el Sistema Cardiovascular,M

519, proctopexia prolapso de recto vía abdominal, 80, Operaciones en el Aparato Digestivo y Abdomen, A

521, operación plástica colostomía, 80, Operaciones en el Aparato Digestivo y Abdomen, M

706, biopsia de encía sutura de encía, 30, Operaciones Otorrinolaringológicas, A

101, metabolismo basal, 190, Endocrinología y nutrición, B

02A, analgésicos opioides, Sistema nervioso, A

Interfaces con otros sistemas

Cobranzas

Interacción: Recepción del Archivo de Información de Deudas enviado por Cobranzas.

Descripción:	Éste archivo es enviado diariamente por Cobranzas, conteniendo la información acerca del estado de morosidad de los afiliados.

Periodicidad:	El archivo se recibe diariamente. El Sistema, mediante un proceso scheduleado, toma éstos archivos a una hora fija: se define que será 4:00 AM. Puede que Cobranzas no envíe ningún archivo un día en particular.

Medio:	Se pone a disposición de Cobranzas un directorio en un único sitio FTP. El sector tiene acceso a ese directorio, para escritura, a través de un nombre de usuario y un password. La administración de todas éstas credenciales queda fuera del alcance del Sistema, y son manejadas por el servidor FTP.

El Sistema también posee una credencial de acceso al sitio FTP, con permisos de lectura/escritura sobre el directorio asignado al sector Cobranzas. El Sistema almacena ésta credencial en un archivo de configuración.

Formato:

Nombre de archivo: AAAA-MM-DD_estado_Afiliados.txt

AAAA: 4 dígitos del año en que se depositó el archivo

MM: 2 dígitos del mes en que se depositó el archivo.

DD: 2 dígitos del día en se depositó el archivo.

Es responsabilidad de Cobranzas nombrar el archivo correctamente, tanto la fecha como su extensión. El archivo debe ser depositado en el sitio FTP nombrado según el formato explicado.

Formato del archivo:

tipo de documento del Afiliado: tipo de documento del afiliado sobre el cual se quiere modificar información. Dato de tipo string.

número de documento del Afiliado: número de documento del afiliado sobre el cual se quiere modificar información. Dato de tipo entero.

cantidadCuotas: cantidad de cuotas que adeuda el afiliado. Dato de tipo entero.

El formato del archivo es CSV. Cada registro está compuesto por campos enumerados anteriormente.

Ejemplo formato:

tipoDoc1,nroDoc1,cantidadCuotas

tipoDoc2,nroDoc2,cantidadCuotas

tipoDoc3,nroDoc3,cantidadCuotas

tipoDoc4,nroDoc4,cantidadCuotas

tipoDoc5,nroDoc5,cantidadCuotas

Ejemplo archivo:

DNI,28803868,1

LE,8340845,2

LC,5957078,0

DNI,25112156,1

LE,7598456,3

DNI,26789423,1

Documento relacionado	Descripción
M01 - Especificación del Caso de Uso “Actualizar Morosos”	Caso de uso que describe la interacción entre el sector Cobranzas y el Sistema para registrar el estado de morosidad de los afiliados.

Pagos

Interacción: Envío del Archivo de Aprobaciones/Rechazos de Prestaciones Realizadas enviado al sector Pagos.

Descripción: Éste archivo es enviado por el Sistema al sector Pagos, conteniendo un informe acerca de las prestaciones realizadas que enviaron los Prestadores, y si cada una de dichas realizaciones fueron aprobadas ó rechazadas por el Sistema.

Periodicidad: El archivo es generado y enviado por el Sistema hacia Pagos, 1 vez por día, una vez que se terminó de procesar toda la información enviada por todos los Prestadores (diariamente a las 3AM, se toman todos los archivos que estén hasta esa hora). Podría ser que el Sistema no envíe ningún archivo un día en particular: esto depende de que ese día no haya habido nada de movimiento, ó bien que hubo problemas en la transmisión de datos PrestadorSistema; en todos éstos casos Pagos es notificado por el sistema vía e-mail. (ver punto 3)

Medio: El sector Pagos debe poner a disposición del Sistema, un directorio en un sitio FTP, así como suministrarle las credenciales necesarias con permisos de escritura en el directorio, para que el sistema pueda depositar allí el archivo con la información. El Sistema almacena las credenciales en un archivo de configuración.

Formato:

Nombre de archivo: rp_AAAA-MM-DD_SS.xml

rp: Prefijo de “Reporte de Prestaciones”

AAAA: 4 dígitos del año en que se depositó el archivo

MM: 2 dígitos del mes en que se depositó el archivo.

DD: 2 dígitos del día en se depositó el archivo.

SS: 2 dígitos de número de secuencia dentro de un día. Será “00” el primer archivo depositado en la fecha AAAA-MM-DD, “01” el segundo y así sucesivamente para el mismo día.

Formato del archivo: El formato de cada archivo es XML 1.0 , conforme a los estándares de la W3C. Se pone a disposición del sector de Pagos el XML Schema con el que cumplen todos los documentos XML que el Sistema deposita en directorio asignado del sitio FTP. A grandes rasgos, el esquema determina que el XML debe tener la información discriminada en líneas, de cada autorización aprobada ó rechazada.

El esquema se presenta a continuación:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="informeAprRechazos" type="informeAprRechazosType"/>

<xs:complexType name="informeAprRechazosType">

<xs:sequence>

<xs:element name="lineas" type="LineasType"/>

</xs:sequence>

<xs:attribute name="fechaGeneracion" type="xs:date"/>

</xs:complexType>

<xs:complexType name="LineasType">

<xs:sequence>

<xs:element name="linea" type="LineaType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="LineaType">

<xs:sequence>

<xs:element name="tipoAutorizacion" type="TipoAutorizacionType" minOccurs="0"/>

<xs:element name="prestador" type="PrestadorType"/>

<xs:element name="codigoPrestacion" type="CodigoPrestacionType"/>

<xs:element name="codigoAfiliado" type="xs:positiveInteger" minOccurs="0"

maxOccurs="unbounded"/>

<xs:element name="porcentajeCoberturaReclamado" type="PorcentajeCoberturaType"/>

<xs:element name="porcentajeCoberturaReal" type="PorcentajeCoberturaType"

minOccurs="0"/>

<xs:element name="fechaAprobacion" type="xs:date" minOccurs="0"/>

<xs:element name="fechaVencimiento" type="xs:date" minOccurs="0"/>

<xs:element name="fechaRealizacion" type="xs:date"/>

<xs:element name="fechaRecepcionInfo" type="xs:date"/>

<xs:element name="motivoRechazo" type="xs:string" minOccurs="0"/>

</xs:sequence>

<xs:attribute name="codigoAutorizacion" type="xs:positiveInteger"/>

<xs:attribute name="aprobada" type="xs:boolean"/>

</xs:complexType>

<xs:complexType name="PrestadorType">

<xs:sequence>

<xs:element name="CUIT" type="CUITType"/>

<xs:element name="nombre" type="xs:string"/>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="CUITType">

<xs:restriction base="xs:string">

<xs:pattern value="\d{2}-\d{8}-\d{1}"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="TipoAutorizacionType">

<xs:restriction base="xs:normalizedString">

<xs:enumeration value="Manual"/>

<xs:enumeration value="Automatica"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="CodigoPrestacionType">

<xs:restriction base="xs:normalizedString">

<xs:minLength value="1"/>

<xs:maxLength value="8"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="PorcentajeCoberturaType">

<xs:restriction base="xs:decimal">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="100"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Ejemplo:

<?xml version="1.0" encoding="UTF-8"?>

<informeAprRechazos fechaGeneracion="2005-05-29">

<lineas>

<linea codigoAutorizacion="123" aprobada="true">

<tipoAutorizacion>Manual</tipoAutorizacion>

<prestador>

<CUIT>30-12345678-1</CUIT>

<nombre>Clinica San Camilo</nombre>

</prestador>

<codigoPrestacion>B01AC06</codigoPrestacion>

<codigoAfiliado>987</codigoAfiliado>

<porcentajeCoberturaReclamado>12.5</porcentajeCoberturaReclamado>

<porcentajeCoberturaReal>12.5</porcentajeCoberturaReal>

<fechaAprobacion>2005-05-12</fechaAprobacion>

<fechaVencimiento>2005-07-12</fechaVencimiento>

<fechaRealizacion>2005-05-27</fechaRealizacion>

<fechaRecepcionInfo>2005-05-28</fechaRecepcionInfo>

</linea>

<linea codigoAutorizacion="8888" aprobada="false">

<tipoAutorizacion>Manual</tipoAutorizacion>

<prestador>

<CUIT>30-11112222-1</CUIT>

<nombre>Clinica Fiorito</nombre>

</prestador>

<codigoPrestacion>B01AC06</codigoPrestacion>

<codigoAfiliado>1155</codigoAfiliado>

<porcentajeCoberturaReclamado>12.5</porcentajeCoberturaReclamado>

<porcentajeCoberturaReal>10</porcentajeCoberturaReal>

<fechaAprobacion>2005-05-10</fechaAprobacion>

<fechaVencimiento>2005-07-10</fechaVencimiento>

<fechaRealizacion>2005-05-27</fechaRealizacion>

<fechaRecepcionInfo>2005-05-28</fechaRecepcionInfo>

<motivoRechazo>Porcentaje de cobertura recibido

invalido</motivoRechazo>

</linea>

<linea codigoAutorizacion="112" aprobada="false">

<prestador>

<CUIT>30-11112222-1</CUIT>

<nombre>Clinica Fiorito</nombre>

</prestador>

<codigoPrestacion>0123456</codigoPrestacion>

<codigoAfiliado>6688</codigoAfiliado>

<porcentajeCoberturaReclamado>40</porcentajeCoberturaReclamado>

<fechaRealizacion>2005-05-27</fechaRealizacion>

<fechaRecepcionInfo>2005-05-28</fechaRecepcionInfo>

<motivoRechazo>Autorizacion Recibida

inexistente</motivoRechazo>

</linea>

</lineas>

</informeAprRechazos>

Interacción: Envío del Archivo del Reporte de Consumo de los Afiliados enviado al sector Pagos.

Descripción: Éste archivo es enviado por el Sistema al sector Pagos, conteniendo un informe acerca del consumo por afiliado de prestaciones, basándose en los últimos datos enviados por los prestadores.

Periodicidad: El archivo es generado y enviado por el Sistema hacia Pagos, 1 vez por día, una vez que se terminó de procesar toda la información enviada por todos los Prestadores (diariamente a las 3AM, se toman todos los archivos que estén hasta esa hora). Podría ser que el Sistema no envíe ningún archivo un día en particular: esto depende de que ese día no haya habido nada de movimiento, ó bien que hubo problemas en la transmisión de datos PrestadorSistema; en todos éstos casos Pagos es notificado por el sistema vía e-mail.

Medio: El sector Pagos debe poner a disposición del Sistema, un directorio en un sitio FTP, así como suministrarle las credenciales necesarias con permisos de escritura en el directorio, para que el sistema pueda depositar allí el archivo con la información. El Sistema almacena las credenciales en un archivo de configuración.

Formato:

Nombre de archivo: rc_AAAA-MM-DD_SS.xml

rc: prefijo de “Reporte de Consumo”

AAAA: 4 dígitos del año en que se depositó el archivo

MM: 2 dígitos del mes en que se depositó el archivo.

DD: 2 dígitos del día en se depositó el archivo.

SS: 2 dígitos de número de secuencia dentro de un día. Será “00” el primer archivo depositado en la fecha AAAA-MM-DD, “01” el segundo y así sucesivamente para el mismo día.

Formato del archivo: El formato de cada archivo es XML 1.0 , conforme a los estándares de la W3C. Se pone a disposición del sector de Pagos el XML Schema con el que cumplen todos los documentos XML que el Sistema deposita en directorio asignado del sitio FTP. A grandes rasgos, el esquema determina que el XML debe tener la información discriminada en líneas, de cada autorización aprobada ó rechazada.

El esquema se presenta a continuación:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="reporteConsumo" type="reporteConsumoType"/>

<xs:complexType name="reporteConsumoType">

<xs:sequence>

<xs:element name="lineas" type="LineasType"/>

</xs:sequence>

<xs:attribute name="fechaGeneracion" type="xs:date"/>

</xs:complexType>

<xs:complexType name="LineasType">

<xs:sequence>

<xs:element name="linea" type="LineaType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="LineaType">

<xs:sequence>

<xs:element name="nombreAfiliado" type="xs:string"/>

<xs:element name="apellidoAfiliado" type="xs:string"/>

<xs:element name="codigoPlanAfiliado" type="xs:integer"/>

<xs:element name="autorizacionRealizada" type="AutorizacionRealizadaType"

minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="codigoAfiliado" type="xs:positiveInteger"/>

</xs:complexType>

<xs:complexType name="AutorizacionRealizadaType">

<xs:sequence>

<xs:element name="prestador" type="PrestadorType"/>

<xs:element name="codigoPrestacion" type="CodigoPrestacionType"/>

<xs:element name="nombrePrestacion" type="xs:string"/>

<xs:element name="fechaRealizacion" type="xs:date"/>

<xs:element name="porcentajeCobertura" type="PorcentajeCoberturaType"/>

</xs:sequence>

<xs:attribute name="codigo" type="xs:positiveInteger"/>

</xs:complexType>

<xs:complexType name="PrestadorType">

<xs:sequence>

<xs:element name="CUIT" type="CUITType"/>

<xs:element name="nombre" type="xs:string"/>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="CUITType">

<xs:restriction base="xs:string">

<xs:pattern value="\d{2}-\d{8}-\d{1}"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="CodigoPrestacionType">

<xs:restriction base="xs:normalizedString">

<xs:minLength value="1"/>

<xs:maxLength value="8"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="PorcentajeCoberturaType">

<xs:restriction base="xs:decimal">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="100"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Ejemplo:

<?xml version="1.0" encoding="UTF-8"?>

<reporteConsumo fechaGeneracion="2005-05-29">

<lineas>

<linea codigoAfiliado="1568">

<nombreAfiliado>Jorge</nombreAfiliado>

<apellidoAfiliado>Drexler</apellidoAfiliado>

<codigoPlanAfiliado>2</codigoPlanAfiliado>

<autorizacionRealizada codigo="554">

<prestador>

<CUIT>30-12345678-1</CUIT>

<nombre>Clinica San Camilo</nombre>

</prestador>

<codigoPrestacion>30510</codigoPrestacion>

<nombrePrestacion>antrotomía maxilar radical

sinusotomía maxilar radical</nombrePrestacion>

<fechaRealizacion>2005-05-27</fechaRealizacion>

<porcentajeCobertura>12.5</porcentajeCobertura>

</autorizacionRealizada>

<autorizacionRealizada codigo="554">

<prestador>

<CUIT>30-99999999-1</CUIT>

<nombre>Clinica Loca Loca</nombre>

</prestador>

<codigoPrestacion>30519</codigoPrestacion>

<nombrePrestacion>cirugía de la fosa pterigomaxilar

con videofibroscopía</nombrePrestacion>

<fechaRealizacion>2005-05-27</fechaRealizacion>

<porcentajeCobertura>40</porcentajeCobertura>

</autorizacionRealizada>

</linea>

<linea codigoAfiliado="666">

<nombreAfiliado>Satanás</nombreAfiliado>

<apellidoAfiliado>Belcebú</apellidoAfiliado>

<codigoPlanAfiliado>1</codigoPlanAfiliado>

<autorizacionRealizada codigo="666">

<prestador>

<CUIT>30-66666666-6</CUIT>

<nombre>Clinica El Diablito</nombre>

</prestador>

<codigoPrestacion>30205</codigoPrestacion>

<nombrePrestacion>movilización del

estribo</nombrePrestacion>

<fechaRealizacion>2005-05-27</fechaRealizacion>

<porcentajeCobertura>12.5</porcentajeCobertura>

</autorizacionRealizada>

</linea>

</lineas>

</reporteConsumo>

Notificaciones enviadas al sector Pagos

Éstas son notificaciones que se le envían al sector Pagos, siempre vía e-mail, según distintas situaciones que pueden ocurrir al procesar (ó intentar procesar) cada archivo enviado por el Prestador.

Error grave

Descripción: Implica que las líneas de un archivo enviado por el Prestador NO pudieron ser procesadas (ninguna de ellas)

Condiciones: (UNA ó más de las siguientes)

Formato del nombre de archivo incorrecto. Es decir, no cumple lo especificado en el documento “Especificación de Interfaces con el Prestador”.

Formato del archivo incorrecto: NO cumple lo especificado en el documento “Especificación de Interfaces con el Prestador”

El número de CUIT enviado en el contenido del archivo no existe en el Sistema, y/ó no corresponde al Prestador que tiene asociado el directorio de donde se levantó el archivo.

Subject del e-mail:

ERROR[espacio][CUIT Prestador][espacio][nombre_archivo]

Donde [CUIT Prestador] es el número de CUIT del Prestador correspondiente al directorio donde se sacó el archivo

Body del e-mail: Vacío.

No se recibieron archivos

Descripción: Implica que no se recibió ningún archivo de un Prestador en particular, desde el último proceso de los archivos, hasta el comienzo del actual. Es decir, el Prestador en cuestión no envió ningún archivo en las últimas 24hs.

Condiciones: (UNA ó más de las siguientes)

No hay archivos en el directorio FTP asociado al Prestador, al momento de comenzar el proceso de los archivos.

Subject del e-mail:

NORECIBIDO[espacio][CUITPrestador][espacio][fecha_inicio_proceso_actual]

Donde [CUIT Prestador] es el número de CUIT del Prestador correspondiente al directorio donde se sacó el archivo

Body del e-mail: Vacío.

Documento relacionado	Descripción
Especificación del Caso de Uso “Recibir y Cotejar Consumos y Prestaciones”	Caso de uso que describe la interacción entre el Sistema y el sector Pagos para la transmisión de los reportes de consumo y de aprobaciones/rechazos de prestaciones realizadas.

Prestador

Interacción: Recepción del Archivo de Información de Prestaciones e Intervenciones enviado por el Prestador.

Descripción:	Éste archivo es enviado periódicamente por el Prestador, conteniendo la información acerca de las prestaciones y/ó intervenciones que se realizaron los afiliados de la Obra Social, en el Prestador en cuestión; con el objetivo de informarle a la Obra Social el porcentaje que tiene que cubrir de dichas prestaciones realizadas al Prestador.

Periodicidad:	El archivo se recibe diariamente. El Sistema, mediante un proceso scheduleado, toma éstos archivos diariamente a una hora fija: se define que será 3:00 AM.

Se espera que siempre haya al menos 1 archivo por día, por cada Prestador: si no tiene consumos para informar, debe enviar un documento sin lineas de consumo (ver g. Ejemplo de documento vacío).

Por circunstancias extraordinarias, puede que el Prestador necesite depositar más de 1 archivo un día en particular.

Medio:	Se pone a disposición de cada Prestador un directorio en un único sitio FTP. Cada Prestador tiene acceso a su directorio, para escritura, a través de un nombre de usuario y un password.	Además de éste directorio, a cada prestador se le pondrá a disposición otro directorio “documentos rechazados” (ver punto d3: “Archivos con formato inválido” ) con permisos de sólo lectura (hay 1 directorio de documentos rechazados para cada Prestador).	La administración de todas éstas credenciales queda fuera del alcance del Sistema, y son manejadas por el servidor FTP.

El Sistema también posee una credencial de acceso al sitio FTP, con permisos de lectura/escritura sobre todos los directorios asignados a los prestadores. El Sistema almacena ésta credencial en un archivo de configuración de la aplicación.

Formato:

d1)	Nombre de archivo: AAAA-MM-DD_SS.xml

AAAA: 4 dígitos del año en que se depositó el archivo

MM: 2 dígitos del mes en que se depositó el archivo.

DD: 2 dígitos del día en se depositó el archivo.

SS: 2 dígitos de número de secuencia dentro de un día. Será “00” el primer archivo depositado en la fecha AAAA-MM-DD, “01” el segundo y así sucesivamente para el mismo día.

Es responsabilidad del Prestador nombrar el archivo correctamente, tanto la fecha como el número de secuencia y su extensión. El archivo debe ser depositado en el sitio FTP nombrado según el formato explicado.

d2)	Formato del archivo:	El formato de cada archivo es XML 1.0 , conforme a los estándares de la W3C. Se pone a disposición de todos los Prestadores el XML Schema con el que deben cumplir todos los documentos XML que se depositen en cada directorio del sitio FTP.	A grandes rasgos, el esquema determina que el XML debe tener un nodo que identifique al Prestador (mediante su CUIT), y a continuación la información, discriminada en líneas, de cada prestación realizada.

d3)	Archivos con formato inválido:	Cada vez que el sistema intente procesar un archivo que no cumple con el esquema acordado, se mueve el archivo del directorio FTP del Prestador hacia el directorio FTP de “documentos rechazados” que le corresponde.	A su vez, se le envía un mail al Prestador (que debe haber proporcionado una dirección e-mail para tales propósitos) informándole el directorio y nombre de archivo que no ha superado la validación, con el objeto de que pueda revisarlo.

La misma lógica se sigue si el número de CUIT especificado en el XML no corresponde al Prestador ó no existe en el Sistema.

El esquema se presenta a continuación:

Esquema que define el formato

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="infoPrestaciones" type="InfoPrestacionesType"/>

<xs:complexType name="InfoPrestacionesType">

<xs:sequence>

<xs:element name="prestador" type="PrestadorType"/>

<xs:element name="lineas" type="LineasType"/>

</xs:sequence>

<xs:attribute name="fechaEnvio" type="xs:date"/>

</xs:complexType>

<xs:complexType name="PrestadorType">

<xs:sequence>

<xs:element name="CUIT" type="CUITType"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="LineasType">

<xs:sequence>

<xs:element name="linea" type="LineaType" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="LineaType">

<xs:sequence>

<xs:element name="tipoAutorizacion" type="TipoAutorizacionType"/>

<xs:element name="codigoAfiliado" type="xs:positiveInteger"/>

<xs:element name="codigoPrestacion" type="CodigoPrestacionType"/>

<xs:element name="fechaRealizacion" type="xs:date"/>

<xs:element name="porcentajeCobertura" type="PorcentajeCoberturaType"/>

</xs:sequence>

<xs:attribute name="codigoAutorizacion" type="xs:positiveInteger"/>

</xs:complexType>

<xs:simpleType name="CUITType">

<xs:restriction base="xs:string">

<xs:pattern value="\d{2}-\d{8}-\d{1}"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="TipoAutorizacionType">

<xs:restriction base="xs:normalizedString">

<xs:enumeration value="Manual"/>

<xs:enumeration value="Automatica"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="CodigoPrestacionType">

<xs:restriction base="xs:normalizedString">

<xs:minLength value="1"/>

<xs:maxLength value="8"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="PorcentajeCoberturaType">

<xs:restriction base="xs:decimal">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="100"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Ejemplo:

<?xml version="1.0" encoding="UTF-8"?>

<infoPrestaciones fechaEnvio="2005-05-28">

<prestador>

<CUIT>30-12345678-1</CUIT>

</prestador>

<lineas>

<linea codigoAutorizacion="123">

<tipoAutorizacion>Automatica</tipoAutorizacion>

<codigoAfiliado>987</codigoAfiliado>

<codigoPrestacion>B01AC06</codigoPrestacion>

<fechaRealizacion>2005-05-27</fechaRealizacion>

<porcentajeCobertura>12.5</porcentajeCobertura>

</linea>

<linea codigoAutorizacion="225">

<tipoAutorizacion>Manual</tipoAutorizacion>

<codigoAfiliado>3305</codigoAfiliado>

<codigoPrestacion>10101</codigoPrestacion>

<fechaRealizacion>2005-05-27</fechaRealizacion>

<porcentajeCobertura>20</porcentajeCobertura>

</linea>

<linea codigoAutorizacion="112">

<tipoAutorizacion>Manual</tipoAutorizacion>

<codigoAfiliado>123</codigoAfiliado>

<codigoPrestacion>661095</codigoPrestacion>

<fechaRealizacion>2005-05-27</fechaRealizacion>

<porcentajeCobertura>10</porcentajeCobertura>

</linea>

</lineas>

</infoPrestaciones>

Ejemplo de documento vacío:

<?xml version="1.0" encoding="UTF-8"?>

<infoPrestaciones fechaEnvio="2001-01-01">

<prestador>

<CUIT>30-12345678-1</CUIT>

</prestador>

<lineas></lineas>

</infoPrestaciones>

Notificaciones enviadas al Prestador

Éstas son notificaciones que se le envían al Prestador, siempre vía e-mail, según distintas situaciones que pueden ocurrir al procesar (ó intentar procesar) cada archivo enviado por el Prestador.

Proceso exitoso

Descripción: Implica que el archivo superó las condiciones y que se pudo procesar (parsear) completo. NO implica de ninguna forma que todas las líneas de consumo hayan sido aceptadas; no tiene relación con la aprobación/rechazo de las líneas.

Condiciones: (deben cumplirse TODAS las siguientes)

Formato del nombre de archivo correcto, según lo especificado en éste documento (punto d1).

Formato del archivo correcto, según lo especificado en el punto e.

El número de CUIT enviado en el contenido del archivo debe existir en el Sistema, y corresponder al Prestador que tiene asociado el directorio de donde se levantó el archivo.

Subject del e-mail: OK[espacio][nombre_archivo]

Body del e-mail: Vacío.

Error grave

Descripción: Implica que las líneas del archivo NO pudieron ser procesadas (ninguna de ellas)

Condiciones: (UNA ó más de las siguientes)

Formato del nombre de archivo incorrecto. Es decir, no cumple lo especificado en éste documento (punto d1).

Formato del archivo incorrecto: NO cumple lo especificado en el punto e.

El número de CUIT enviado en el contenido del archivo no existe en el Sistema, y/ó no corresponde al Prestador que tiene asociado el directorio de donde se levantó el archivo.

Subject del e-mail: ERROR[espacio][nombre_archivo]

Body del e-mail: Vacío.

No se recibieron archivos

Descripción: Implica que no se recibió ningún archivo desde el último proceso de los archivos, hasta el comienzo del actual. Es decir, el Prestador no envió ningún archivo en las últimas 24hs.

Condiciones: (UNA ó más de las siguientes)

No hay archivos en el directorio FTP asociado al Prestador, al momento de comenzar el proceso de los archivos.

Subject del e-mail: NORECIBIDO[espacio][fecha_inicio_proceso_actual]

Body del e-mail: Vacío.

Documento relacionado	Descripción
Especificación del Caso de Uso “Recibir y Cotejar Consumos y Prestaciones”	Caso de uso que describe la interacción entre el Prestador y el Sistema para la transmisión de la info de prestaciones realizadas por los afiliados.

Interfaces con otros sistemas interactivos

Prestador

Nombre del Documento:

Especificación de Interfaz online con el Prestador

Documento relacionado	Descripción
Especificación de clase “InterfazPrestadorController”	Clase en la que se describen los métodos que se exportan al prestador..

Interacción: Petición de autorizacion automática online, ó petición de verificación de que una autorización manual este aprobada., ó una consulta de cobertura.

Descripción:	En este documento, se describe como será la interacción con el prestador, cuando este pida una autorización automática online ó una verificación de que una autorización manual este aprobada.

Periodicidad:	Esta interacción será asincrónica, por lo que no se indica periodicidad. Funcionará “On demmand”, es decir, cada vez que el prestador (la clínica) necesite efectuar la interacción.

Medio:

Se utilizará internet para las comunicaciónes. Será por http, en puerto 80, y se registrará un dns para tal fín: www.miklolife-webservices.com.ar

Autenticación

Importante: Antes de utilizar cualquiera de los métodos que abajo se describen, la clinica deberá llamar a “logear(String cuit, String password):bool”. Esté la validará. El cuit debe ser pasado en String con el siguiente formato: “11-11111111-1”, por ej.

Devolverá si esta ok, o no. En caso de error se deberán contactar telefonicamente. La password la obtendrán también telefonicamente, o personalmente.

Una vez que se llame la clínica se encontrará logeada, no es necesario que esta se vuelva a logear para llamar a otro método, hasta el próximo inicio de sesión claro.

Formato:

Todas las interacciónes usarán SOAP para llevarse a cabo, se definen métodos exportados en la clase “InterfazPrestadorController”, a fin hacer efectivas las interacciones.

Los métodos exportados són:

AutorizacionAutomaticaResponse evaluarAutorizacionAutomaticaOnline(int codPrestacion, int codAfiliado)

Descripción:

Este método procesará una autorización automática online, y devolverá si se aprobo ó rechazo, indicando los motivos.

El valor de retorno será un objeto con la siguiente estructura:

AutorizacionAutomaticaResponse
Atributos
Nombre	Tipo	Visibilidad	Descripción
codAfiliado	int	Público	Será 0 si el código pasado por parametro es inexistente.(*)
codPrestacion	int	Público	Será 0 si el código pasado por parametro es inexistente.(*)
codAutorizacion	int	Público	Contendrá el código de autorización que se generó al procesar esta autorización (aprobada 1 ó 2). Se generá tanto para rechazo, como para aprobación. No se generá si hay códigos inexistentes, ó un error de nuestro lado (aprobada en 3 ó -1), en estos casos contendrá 0
aprobada	int	Público	Será 1 si está aprobada, 2 si es rechazada, 3 si hay un error con los datos pasados por parametros y -1 si hay un error de nuestro sistema (**) (ej: Saturación, servidor de datos caído, etc).
Mensaje	String	Público	Contendrá un mensaje explicando el motivo de rechazo (en caso de rechazo), o de descripción de un error, si se produce. Si sale todo ok, será null.
porcentajeCobertura	float	Público	Contendrá el porcentaje de cobertura en caso de aprobarse la autorización.
Métodos
Ninguno

(*) Si no hay error, se devuelve el mismo valor con que se llamo a este “método web”.

(**) En estos casos deberán reintentar la operación más tarde.

ConsultaCoberturaResponse consultarCobertura(int codAfiliado,int codPrestacion)

Nota: La consulta es solo para consultar acerca de una prestación del afiliado, apunta para que el prestador pueda saber si una prestación debe ser automatica o manual, y si el afiliado lo tiene cubierto. Pero las validaciones para autorizarlo, solo se hacen cuando se pide una autorización: No se validan carencias, limites anuales, ni nada. Que la consulta diga: “Es automatica”, será que su plan así lo contempla, pero no implica que esté en condiciones de hacerlo.

El valor de retorno será un objeto con la siguiente estructura:

ConsultaCoberturaResponse
Atributos
Nombre	Tipo	Visibilidad	Descripción
codAfiliado	int	Público	Será 0 si el código pasado por parametro es inexistente.(*)
codPrestacion	int	Público	Será 0 si el código pasado por parametro es inexistente.(*)
TipoDeAutorizacion	int	Público	Será 1 si es automática, 2 sí es manual, 3 si no está cubierta y 4 si el afiliado esta inactivo (Ej: Dadod de baja). -1(**) si hay un error de nuestro lado que impide realizar la consulta.
Mensaje	String	Público	Contendrá un mensaje explicando el error, de producirse.
porcentajeCobertura	float	Público	Contendrá el porcentaje de cobertura para la consulta solicitada.
Métodos
Ninguno

(*) Si no hay error, se devuelve el mismo valor con que se llamo a este “método web”.

(**) En estos casos deberán reintentar la operación más tarde.

Modelo de procesamiento

Ciclo del procesamiento

Línea de tiempo diaria

Evento	Duración	00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23
Consulta de afiliados en Casa Central y CAPs	10 hs																								
Consulta de afiliados vía Web	24 hs																								
Ingreso de solicitudes de afiliación	10 hs																								
Alta de afiliados	10 hs																								
Confección y Asignación de hoja de ruta	2 hs																								
Registro de visitas realizadas	2 hs																								
Confección de cartilla	4 hs																								
Ingreso de solicitud de autorización manual	10 hs																								
Solicitar autorización automática vía telefónica	10 hs																								
Resolver solicitud de autorización manual	10 hs																								
Solicitar autorización automática online	24 hs																								
Consultar cobertura online	24 hs																								
Consultar autorizaciones	10 hs																								
Procesar consumos y prestaciones	2 hs																								
Actualizar estado de morosidad de afiliados	1 hs																								
Mantenimiento de planes	2 hs																								
Mantenimiento de prestaciones	2 hs																								
Mantenimiento de promotores	2 hs																								
Mantenimiento de CAPs	2 hs																								
Mantenimiento de zonas	2 hs																								
Mantenimiento de prestadores	2 hs																								
Baja y modificación de afiliados	10 hs																								
Emisión de reporte de autorizaciones rechazadas	2 hs																								
Enviar información carnets	1 hs																								

El esquema anterior es el utilizado en días hábiles (Lunes a Viernes no feriados). Para los Sábados se mantendrá el mismo esquema salvo para las operaciones realizadas por el personal administrativo y de atención al público, en cuyo caso los horarios de 8 a 18 hs. deben ser reemplazados por el de 8 a 12 hs.

Línea de tiempo mensual

Evento	Duración	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	…	26	27	28	29	30	31
Backup	4 hs																						
Depuración de Base de Datos	4 hs																						
Emisión de reporte de prestaciones con deuda	2 hs																						

Línea de tiempo anual

Evento	Duración	01	02	03	04	05	06	07	08	09	10	11	12
Emisión de reporte de porcentaje de rechazo de solicitudes	6 hs												

Esquema del procesamiento

Casa Central

Área de atención telefónica a afiliados

En esta área funciona el call center 0800 de atención telefónica de afiliados. Además los operadores se encargan de cargar las solicitudes ingresadas desde la página Web.

Los puestos tanto de los operadores como del supervisor, deben tener acceso a los casos de uso:

Atender consulta afiliado

Ingresar solicitud

Agregar afiliado

Mantener afiliado

Pedir autorización manual

Pedir autorización automática

Consultar autorizaciones

Área administrativa

En esta área funciona la administración central de la obra social.

Se puede subdividir en cuatro sectores:

Auditoria medica

En este sector trabajan los auditores médicos encargados de resolver las autorizaciones manuales. Estos puestos deben contar con acceso al caso de uso

Actualizar autorización manual

Promoción

En este sector trabajan los promotores de la obra social, quienes desde las 8 hasta las 16 hs realizan visitas a posibles afiliados, y desde las 16 hasta las 18 hs vuelcan el resultado de sus visitas en el sistema. Es por ello que no es necesario contar con la misma cantidad de puestos que de promotores que trabajen en la casa central. Por supuesto los promotores podrían terminar antes de ese horario las visitas marcadas en la hoja de ruta y volver a la oficina para registrar los resultados obtenidos, pero esto no será de normal acontecimiento (en estos casos el supervisor de promotores podría adelantar la hoja de ruta del día siguiente al promotor). Estos puestos deben contar con acceso al caso de uso

Registrar visitas

Además los promotores deben tener acceso a sus cuentas de e-mail para poder bajar e imprimir la hoja de ruta diariamente (si prefieren hacerlo desde las oficinas de la obra social).

El caso del supervisor de promoción es especial ya que la persona que desempeñe este cargo trabajará de 8 a 18 hs en la oficina. Este puesto debe contar con acceso a los casos de uso

Registrar visitas

Emitir Hoja de Ruta

Mantener promotores

Administración

En este sector se realiza el mantenimiento de la información de la obra social (prestadores, CAPs, zonas, etc.). Este puesto debe contar con acceso a los casos de uso

Mantener planes

Mantener prestaciones

Mantener prestadores

Mantener CAPs

Armar cartilla

Dirección

A este puesto llegarán los reportes mensuales (vía e-mail). Debe tener acceso completo a las consultas a través del caso de uso

Atender consulta afiliado

Consultar autorizaciones

Área de sistemas

Esta área debe ubicarse en una zona central del edificio de la casa central por la topología física de red en estrella. Si la Casa Central es un edificio debe establecerse en el piso cuyo número es la mitad de los pisos totales del mismo según las normas de la EIA/TIA (Electronic Industries Alliance / Telecomunication Industry Association) 568 A y B sobre cableado estructurado. De la misma se desprenden los enlaces hacia el resto de los pisos tanto de datos como telefónicos, saliendo de switches desde el rack central hacia hubs dentro de cada piso, y de ellos se realiza la distribución hacia el resto de las terminales. Esta sala deberá respetar las condiciones establecidas en el modelo 13, conceptos en seguridad.

El puesto en la sala de servidores se utilizará únicamente para diagnóstico y corrección de problemas en los servidores. El personal que trabaje full time dentro del rack como aquellos externos no deberán tener acceso a la aplicación. El acceso a los servers deberá ser full por el personal interino y full time dedicado al mantenimiento de los equipos, para el resto dependerá del trabajo a realizar y será acordado con la empresa, analizando el impacto al dejar entrar a terceros. El administrador de seguridad será el responsable frente a tales accesos y deberá responder ante cualquier incidente que impacte sobre el negocio de la empresa. Todos los procesos Batch referentes a datos de la organización (backups, depuraciones, generación de reportes, etc.) se ejecutarán en esta sala de forma de evitar inconvenientes en la ejecución por problemas de comunicación, malfuncionamiento del equipo, apagado inintencional del equipo, etc.

El administrador de seguridad no debe tener acceso a la aplicación, inclusive no debe por qué conocer sus interfaces. Pero será el encargado y responsable de todas las credenciales de acceso a las máquinas y servicios dentro del NOC (Network Operation Center). Deberá tener todas las cuentas administrativas para equipos y servicios y será el responsable de la mantención y delegación de las tareas de mantenimiento.

El puesto de help desk no requiere acceso a la aplicación. El mismo debe ser capaz de ver los datos pero debe estar supervisado para alterarlos por el administrador de seguridad en caso de ser necesario. No se deberían hacer modificaciones manuales a los datos salvo en caso de contingencia, y en este caso se debe dejar documentado el incidente y las medidas tomadas para su solución.

Para más detalles sobre la infraestructura del NOC, remitirse al modelo 13, conceptos de seguridad.

Área de atención personalizada a afiliados

En esta área se brinda la atención personalizada a los afiliados y a los solicitantes.

Los puestos de consulta Web solo requieren acceso a la página de la obra social.

Los puestos de atención deben contar con acceso a los casos de uso:

Atender consulta afiliado

Ingresar solicitud

Mantener afiliado

Consultar autorizaciones

CAP

Área administrativa

El sector de promoción (puestos de Promotor y Supervisión de promotor) son idénticos a los ya descriptos en el sector de mismo nombre en el área de Administración de la Casa Central.

El responsable del CAP debe tener acceso al caso de uso:

Atender consulta afiliado

Consultar autorizaciones

Área de atención personalizada a afiliados

En esta área se brinda la atención personalizada a los afiliados y a los solicitantes.

Los puestos de atención deben contar con acceso a los casos de uso

Atender consulta afiliado

Ingresar solicitud

Mantener afiliado

Consultar autorizaciones

Especificación de lanzamiento de tareas

Tarea	Tipo	Justificación
Casa Central
Atención telefónica de afiliados. Puestos de operadores y supervisor
Atender consulta de afiliado	ON-LINE	Se requiere acceso inmediato a los datos del afiliado para poder responder su consulta.
Ingresar solicitud	ON-LINE	Requiere interacción con el operador. Maneja transacciones de un único registro. Se requiere acceso inmediato para confirmar al solicitante el correcto ingreso en el sistema de su solicitud.
Agregar afiliado	ON-LINE	Requiere interacción con el operador. Maneja transacciones de unos pocos registros.
Mantener afiliado	ON-LINE	Requiere interacción con el operador. Se requiere acceso inmediato para confirmar al afiliado la correcta modificación de sus datos.
Pedir autorización manual	ON-LINE	Maneja transacciones de un único registro. Demanda una carga normal de CPU. Se requiere acceso inmediato para confirmar al prestador el correcto ingreso en el sistema de su solicitud de autorización manual.
Pedir autorización automática vía telefónica	ON-LINE	Maneja transacciones de un único registro. Demanda una carga normal de CPU. Se requiere acceso inmediato para confirmar al prestador el correcto ingreso en el sistema de su solicitud de autorización y del resultado de la misma.
Consultar autorizaciones	ON-LINE	Requiere interacción con el operador que debe brindar una respuesta inmediata a la consulta que le realizan.
Auditoria médica
Actualizar autorización manual	ON-LINE	Requiere interacción con el auditor. Maneja transacciones de un único registro. No necesita una alta carga de procesamiento para resolverse.
Atender consulta sobre afiliado	ON-LINE	Se requiere acceso inmediato a los datos del afiliado para poder resolver la autorización manual.
Promoción. Puestos de promotores
Registrar visitas	ON-LINE	Requiere interacción con el promotor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Promoción. Puesto de supervisor
Registrar visitas	ON-LINE	Ídem anterior.
Emitir Hoja de Ruta	ON-LINE	Ya que el sistema solo se encarga de emitir el reporte y registrar las solicitudes como atendidas, la mayor parte de la tarea es realizada en forma manual y por ende no requiere una alta carga de procesamiento.
Mantener promotores	ON-LINE	Requiere interacción con el supervisor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Administración
Mantener planes	ON-LINE	Necesita interacción con el administrador.
Mantener prestaciones	ON-LINE	Necesita interacción con el administrador. La cantidad de datos a los que accede no es importante y no demanda una alta carga de procesamiento.
Mantener prestadores	ON-LINE	Ídem anterior.
Mantener CAPs	ON-LINE	Ídem anterior.
Mantener zonas	ON-LINE	Ídem anterior.
Armar cartilla	ON-LINE	Ídem anterior.
Dirección
Atender consulta sobre afiliado	ON-LINE	El director de la O.S. puede acceder a los datos de los afiliados en cualquier momento y necesita respuesta inmediata.
Consultar autorizaciones	ON-LINE	Necesita interacción con el director, quien consulta los datos y espera una respuesta inmediata.
Sistemas. Data Server
Depuración	BATCH	Se efectúa fuera del horario laboral. No requiere interacción con el usuario. Procesa gran cantidad de información. Los criterios de depuración son automáticos (ver modelo 2).
Backup de la Base de Datos	BATCH	Se efectúa fuera del horario laboral. No requiere interacción con el usuario. Procesa gran cantidad de información.
Sistemas. Web Server
Consulta de afiliados vía Web	ON-LINE	Los usuarios pueden realizar consultas Web las 24 hs del día y esperan recibir la información al momento de la consulta.
Pedir autorización automática vía Web	ON-LINE	Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU. Se requiere acceso inmediato para confirmar al prestador el correcto ingreso en el sistema de su solicitud de autorización y del resultado de la misma.
Consultar cobertura online	ON-LINE	Se requiere disponibilidad las 24 horas.
Sistemas. Puesto en sala de servidores
Emisión de reporte de autorizaciones rechazadas	BATCH	Maneja un volumen importante de información. No requiere interacción con el usuario. Se ejecuta fuera del horario laboral. El reporte resultante no se requiere en el momento.
Emisión de reporte de prestaciones con deuda	BATCH	Ídem anterior.
Procesar consumos y prestaciones	BATCH	Maneja un volumen importante de información. No requiere interacción. Se ejecuta fuera del horario laboral. Es una tarea programada para ejecutarse diariamente en un horario acordado con los Prestadores ya que estos deben enviar antes de la ejecución de la tarea, vía FTP, los archivos conteniendo la información de prestaciones e intervenciones.
Actualizar estado de morosidad de afiliados	BATCH	Maneja un volumen importante de información. No requiere interacción. Se ejecuta fuera del horario laboral. Es una tarea programada para ejecutarse diariamente en un horario acordado con el sector de Cobranzas ya que este debe enviar antes de la ejecución de la tarea, vía FTP, el listado de afiliados cuyo estado de cuenta ha sido modificado.
Emisión de reporte de porcentaje de rechazo de solicitudes	BATCH	Por tratarse de un reporte anual, maneja una gran cantidad de información. No requiere interacción. Se ejecuta fuera del horario laboral.
Enviar información carnets	BATCH	No requiere interacción. Se ejecuta fuera del horario laboral. Maneja un volumen importante de información.
Atención personalizada de afiliados. Puestos de atención (ídem para CAPs)
Atender consulta de afiliado	ON-LINE	Se requiere acceso inmediato a los datos del afiliado para poder responder su consulta.
Ingresar solicitud	ON-LINE	Requiere interacción con el usuario final. Maneja principalmente transacciones de un único registro. Se requiere acceso inmediato para confirmar al solicitante el correcto ingreso en el sistema de su solicitud.
Mantener afiliado	ON-LINE	Requiere interacción con el usuario final. Se requiere acceso inmediato para confirmar al afiliado la correcta modificación de sus datos.
Consultar autorizaciones	ON-LINE	Requiere interacción con el operador que debe brindar una respuesta inmediata a la consulta que le realizan.
CAP
Promoción. Puestos de promotores
Registrar visitas	ON-LINE	Requiere interacción con el promotor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Promoción. Puesto de supervisor
Registrar visitas	ON-LINE	Requiere interacción con el supervisor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Emitir Hoja de Ruta	ON-LINE	Se requiere acceso inmediato debido a que los promotores solo pueden comenzar su trabajo diario luego de que se les ha asignado una hoja de ruta.
Mantener promotores	ON-LINE	Requiere interacción con el supervisor. Maneja principalmente transacciones de un único registro. Demanda una carga normal de CPU.
Responsable del CAP
Consultar autorizaciones	ON-LINE	Necesita interacción con el usuario, quien consulta los datos y espera una respuesta inmediata.
Atender consulta afiliado	ON-LINE	El responsable del CAP puede acceder a los datos de los afiliados en cualquier momento y necesita respuesta inmediata.

Diseño y lanzamiento de tareas batch

Tareas

Emisión de reporte de autorizaciones rechazadas

Composición

Emite un reporte de las autorizaciones rechazadas con rango de un mes desde la fecha actual hacia atrás. Una vez generado, el reporte se almacena y se envía una copia por e-mail al director de la Obra Social. El archivo de salida, tal como se especifica en ReporteAutorizacionesController (modelo 1), queda guardado bajo el nombre DD_MM_AAAA.txt donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/Reportes/Autorizaciones/Rechazadas (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado).

En caso de no finalizar la tarea en forma correcta en un ciclo anterior, al lanzarse el proceso se continuará la ejecución desde el registro siguiente al último almacenado en el archivo de log, gracias a la forma en que se nombran los archivos es posible generar el reporte que falló en un primer momento con el mismo rango de fechas que tenía inicialmente. Ya que el orden en que se procesan las autorizaciones rechazadas esta dado por la fecha de resolución, no existe la posibilidad de que, ante un fallo en el proceso, se dejen registros sin procesar.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará diariamente a partir de las 5 a.m. de forma que no entorpezca la ejecución de otras tareas.

Condiciones previas

Para la configuración del generador de reportes, se tendrá un XML almacenado localmente. Dicho XML debe definir la/s dirección/es de e-mail adonde se debe enviar una copia del mismo y la dirección de e-mal del help desk para comunicarle cualquier error que exista en la ejecución de la tarea.

Puntos de control

En el directorio de salida del reporte se llevará un archivo de log en el que se guardará en formato binario los números de autorización ya procesados, dicho archivo se nombrará igual que el archivo de salida pero su extensión será .log y un archivo temporal en el que se irá guardando el progreso del reporte. El nombre de estos archivos será el mismo que el de salida del reporte, aunque su extensión será .log y .tmp respectivamente.

Al terminar exitosamente el proceso de generación del reporte el archivo de log será eliminado y el archivo temporal será renombrado según se especifico anteriormente.

Contingencias

Al ocurrir una falla, se enviará un e-mail al help desk para notificarlo del problema.

Además, si fuera necesario, puede ejecutarse la tarea manualmente ya que se trata de una aplicación de consola que puede ser invocada por el usuario directamente desde el símbolo del sistema. Dicha ejecución debe ser realizada por una persona del área de sistemas una vez que se haya detectado y solucionado la causa del error. Cabe aclarar que el sistema no tiene las funcionalidades de diagnosticar ni corregir dicho fallo y por ende no realizará ningún tipo de chequeo previo a la ejecución para verificar que el mismo haya sido corregido.

Emisión de reporte de prestaciones con deuda

Composición

Emite un reporte de las prestaciones tomadas por afiliados con deuda en el último mes. Una vez generado, el reporte se almacena y se envía una copia por e-mail al director de la Obra Social. El archivo de salida, tal como se especifica en ReporteAutorizacionesController (modelo 1), queda guardado bajo el nombre DD_MM_AAAA.txt donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/Reportes/PrestacionesConDeuda (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado).

En caso de no finalizar la tarea en forma correcta en un ciclo anterior, al lanzarse el proceso se continuará la ejecución desde el registro siguiente al último almacenado en el archivo de log, gracias a la forma en que se nombran los archivos es posible generar el reporte que falló en un primer momento con el mismo rango de fechas que tenía inicialmente. Ya que el orden en que se procesan las autorizaciones de prestaciones efectuadas esta dado por la fecha de resolución, no existe la posibilidad de que, ante un fallo en el proceso, se dejen registros sin procesar.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará mensualmente a partir de las 5 a.m. del día 3 de forma que no entorpezca la ejecución de otras tareas.

Condiciones previas

Para la configuración del generador de reportes, se tendrá un XML almacenado localmente. Dicho XML debe definir la/s dirección/es de e-mail adonde se debe enviar una copia del mismo y la dirección de e-mal del help desk para comunicarle cualquier error que exista en la ejecución de la tarea.

Puntos de control

En el directorio de salida del reporte se llevará un archivo de log en el que se guardará en formato binario los números de autorización ya procesados, dicho archivo se nombrará igual que el archivo de salida pero su extensión será .log y un archivo temporal en el que se irá guardando el progreso del reporte. El nombre de estos archivos será el mismo que el de salida del reporte, aunque su extensión será .log y .tmp respectivamente.

Al terminar exitosamente el proceso de generación del reporte el archivo de log será eliminado y el archivo temporal será renombrado según se especifico anteriormente.

Contingencias

Al ocurrir una falla, se enviará un e-mail al help desk para notificarlo del problema.

Además, si fuera necesario, puede ejecutarse la tarea manualmente ya que se trata de una aplicación de consola que puede ser invocada por el usuario directamente desde el símbolo del sistema. Dicha ejecución debe ser realizada por una persona del área de sistemas una vez que se haya detectado y solucionado la causa del error. Cabe aclarar que el sistema no tiene las funcionalidades de diagnosticar ni corregir dicho fallo y por ende no realizará ningún tipo de chequeo previo a la ejecución para verificar que el mismo haya sido corregido.

Emisión de reporte de porcentaje de rechazo de solicitudes

Composición

Emite un reporte del porcentaje de rechazado de solicitudes en el último mes. Una vez generado, el reporte se almacena y se envía una copia por e-mail al Ministerio de Salud. El archivo de salida queda guardado bajo el nombre DD_MM_AAAA.txt donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/Reportes/Autorizaciones/ProcentajeRechadas (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado).

En caso de no finalizar la tarea en forma correcta en un ciclo anterior, al lanzarse el proceso se continuará la ejecución desde el registro siguiente al último almacenado en el archivo de log, gracias a la forma en que se nombran los archivos es posible generar el reporte que falló en un primer momento con el mismo rango de fechas que tenía inicialmente. Ya que el orden en que se procesan las autorizaciones rechazadas esta dado por la fecha de resolución, no existe la posibilidad de que, ante un fallo en el proceso, se dejen registros sin procesar.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará anualmente a partir de las 0 a.m. del primero de enero de forma que no entorpezca la ejecución de otras tareas.

Por tratarse de un proceso que se ejecuta una vez al mes, en caso de una falla en la ejecución, no es posible esperar al próximo ciclo para finalizar el reporte. Es por ello que antes de comenzar con la tarea se reprograma el scheduler para que se ejecute al día siguiente en el mismo horario al original. Al finalizar la correcta ejecución se restaurará el valor al mismo día del mes siguiente. De esta forma, en caso de ocurrir un fallo el sistema volverá a intentar ejecutar la tarea al día siguiente, mas allá de si se corrigió el error o no.

Condiciones previas

Para la configuración del generador de reportes, se tendrá un XML almacenado localmente. Dicho XML debe definir la/s dirección/es de e-mail adonde se debe enviar una copia del mismo y la dirección de e-mail del help desk para comunicarle cualquier error que exista en la ejecución de la tarea.

Puntos de control

En el directorio de salida del reporte se llevará un archivo de log en el que se guardará en formato binario los números de autorización ya procesados, dicho archivo se nombrará igual que el archivo de salida pero su extensión será .log y un archivo temporal en el que se irá guardando el progreso del reporte. El nombre de estos archivos será el mismo que el de salida del reporte, aunque su extensión será .log y .tmp respectivamente.

Al terminar exitosamente el proceso de generación del reporte el archivo de log será eliminado y el archivo temporal será renombrado según se especifico anteriormente.

Contingencias

Además al ocurrir una falla, se enviará un e-mail al help desk para notificarlo del problema.

Por último, si fuera necesario, puede ejecutarse la tarea manualmente ya que se trata de una aplicación de consola que puede ser invocada por el usuario directamente desde el símbolo del sistema. Dicha ejecución debe ser realizada por una persona del área de sistemas una vez que se haya detectado y solucionado la causa del error. Cabe aclarar que el sistema no cuenta con funciones de diagnóstico y corrección de errores, y por ende no realizará ningún tipo de chequeo previo a la ejecución para verificar que el mismo haya sido corregido.

Procesar consumos y prestaciones

Composición

Procesa los archivos de información de prestaciones e intervenciones de los afiliadosenviados por los prestadores y alojados en el sitio FTP destinado para tal caso (ref: Modelo 5 - Especificación de Interfaces con el Prestador). Una vez procesados todos los archivos de prestadores, genera el informe de aprobaciones/rechazos de prestaciones realizadas y el reporte de consumo de los afiliados y sube ambos documentos al directorio de pagos del sitio FTP (ref: Modelo 5 – Especificación de Interfaces con el sector Pagos).

Ante una falla del proceso en un ciclo anterior, y para evitar procesar varias veces el mismo registro de prestación tomada, se verificará al inicio de la ejecución que no existan los archivos temporales de los reportes informe de aprobaciones/rechazos de prestaciones realizadas y reporte de consumo de los afiliados. En caso de que así fuera, al procesar cada archivo de información de prestaciones e intervenciones de los afiliados se deberá verificar registro por registro, que no exista en los dos primeros archivos y si así fuera a manera de control deberá verificar que los registros coincidentes sean idénticos.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará diariamente a partir de las 3 a.m. por ser el horario acordado con los prestadores como limite diario para el envío de los archivos y de forma que no entorpezca la ejecución de otras tareas.

Condiciones previas

El sitio FTP debe estar online y la aplicación debe tener acceso de lectura/escritura a los directorios de los Prestadores y al directorio de Pagos. Para el acceso al sitio FTP, se tendrá un XML almacenado localmente en la maquina que ejecute la tarea. Dicho XML debe definir la dirección y puerto del sitio FTP, los directorios de los prestadores y el directorio donde se guardarán los reportes generados de forma que sean accesibles al sector de Pagos, además del e-mail del responsable en el área de sistemas al que deba comunicársele cualquier error en el proceso. El Schema de validación del XML debe estar disponible al proceso para que este pueda realizar la validación de los archivos recibidos.

Puntos de control

Al finalizar el procesamiento de cada archivo de información de prestaciones e intervenciones de los afiliados, se mueve dicho archivo al subdirectorio documentos aceptados del directorio del prestador en el sitio FTP; si ocurre un error de validación el archivo se moverá al subdirectorio documentos rechazados perteneciente al directorio antes citado. Por ende, todos los archivos que no hayan sido procesados en su totalidad permanecerán en el directorio de entrada del Prestador y serán reprocesados en caso de que el proceso no finalice correctamente.

Contingencias

Al igual que los otros procesos, ante una falla en la ejecución de la tarea se enviará un e-mail al área de sistemas para notificarla del problema. Por tratarse de un proceso extremadamente sensible al negocio de la organización, será responsabilidad del personal de sistemas resolver en forma inmediata cualquier problema reportado y volver a ejecutar el proceso invocándolo desde la línea de comandos.

Actualizar estado de morosidad de afiliados

Composición

Procesa los archivos recibidos en el sitio FTP en el directorio acordado con el sector Cobranzas (ref: Modelo 5 - Especificación de Interfaces con el sector Cobranzas) y actualiza los estados de morosidad de los afiliados. Los archivos encontrados en el FTP se mueven temporalmente a un directorio de procesamiento que al finalizar el correcto procesamiento de los mismos, se eliminan.

Los archivos se tomarán en orden de acuerdo al nombre que es indicativo de la fecha de emisión.

En caso de que al iniciar la ejecución de la tarea se detecten archivos en el directorio de procesamiento lo que indicaría que la tarea fallo en un ciclo anterior, se comenzará procesando estos antes de los que se encuentren en el FTP.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará diariamente a partir de las 4 a.m. por ser el horario acordado con el sector Cobranzas como limite diario para el envío de los archivos y de forma que no entorpezca la ejecución de otras tareas.

Condiciones previas

El sitio FTP debe estar online y la aplicación debe tener acceso de lectura/escritura al directorio de Cobranzas. Para la configuración del path en el FTP debe existir un XML en el mismo directorio que el del ejecutable que defina la dirección y puerto del sitio y el path al directorio de Cobranzas, dicho documento además contendrá la dirección de e-mail del área de sistemas a la que debe enviarse un correo en caso de ocurrir un error en el proceso.

Puntos de control

A medida que se procesan registros de afiliados estos se eliminan del archivo CSV.

Contingencias

Si se encontrara un error en uno de los CSV no se seguirá ejecutando la tarea y se enviará un e-mail al área de sistemas para informar el problema. Por tratarse de un proceso extremadamente sensible al negocio de la organización, será responsabilidad del personal de sistemas resolver en forma inmediata cualquier problema reportado y volver a ejecutar el proceso invocándolo desde la línea de comandos.

Enviar información carnets

Composición

Para llevar el control de contingencias ocurridas en ciclos anteriores, lo primero que se verifica al comenzar la ejecución de la tarea es el archivo INI para chequear la última fecha en la que se completó en forma exitosa.

Consulta los afiliados ingresados entre la fecha siguiente al del INI y la fecha actual y a partir de sus datos genera un XML con el formato definido en la especificación de la clase CarnetsController (modelo 1). Una vez generado el archivo de salida se envía al departamento de servicios al cliente. El archivo XML de salida queda guardado bajo el nombre DD_MM_AAAA.xml donde DD es el día, MM es el mes, y AAAA el año en que se ejecuto el proceso, en el directorio $INI_PATH/NuevosAfiliados (donde $INI_PATH es la variable que indica la ruta donde el sistema fue instalado). Si la tarea concluye exitosamente se seteará en el INI la fecha actual.

Ejecución

Se utiliza el scheduler de Windows 2000 Professional (sistema operativo que tiene instalado el puesto en la sala de servidores) para programar la ejecución de la aplicación de consola que llevará adelante la tarea. La misma se realizará diariamente a partir de las 23 hs de forma que no entorpezca la ejecución de otras tareas y para que al día siguiente el Depto. de Servicios al Cliente tenga la información necesaria para emitir los carnets.

Condiciones previas

Para la configuración, se tendrá un XML almacenado. Dicho XML debe definir la/s dirección/es de e-mail del departamento de Servicios al Cliente adonde se debe enviar una copia del archivo XML de nuevos afiliados y la dirección de e-mal del help desk para comunicarle cualquier error que exista en la ejecución de la tarea. Además, en el mismo directorio debe existir un archivo INI que contenga la fecha en la que se completó por última vez en forma exitosa la tarea.

Puntos de control

Ya que la cantidad diaria de nuevos afiliados no será excesiva y por lo tanto la carga de trabajo por reprocesar los nuevos afiliados de un día dado no es importante, no se implementan puntos de control sobre el proceso diario. Para llevar control sobre el último día que se terminó correctamente la ejecución de la tarea se utiliza el archivo INI mencionado anteriormente.

Contingencias

Ante un error en la ejecución de la tarea se envía automáticamente un e-mail al help desk. Además del control de contingencias mencionado en la Composición de la tarea, se puede ejecutar el proceso en forma manual si así se requiriese.

Depuración

Composición

Realiza la depuración según lo explicado en el modelo 2.

Ejecución

El proceso de depuración se almacena en las tablas de tareas (jobs) del motor de base de datos y será este el encargado de lanzarlo a las 23 hs de los días 2 de cada mes.

Condiciones previas

El motor de base de datos debe estar corriendo y el backup de la base de datos debe haberse ejecutado el día anterior (ver próxima tarea batch).

Puntos de control

La tarea como se explicó en el modelo 2, esta definida por sentencias SQL que serán ejecutadas por el DBMS, dichas sentencias deben estar atomizadas en transacciones de forma que sea el motor el que realice el proceso con puntos de control en cada commit y debe estar configurado para que lleve un log de lo acontecido (tanto transacciones exitosas como erroneas).

Contingencias

Se debe configurar el DBMS para que ante cualquier error en el proceso se envíe un e-mail al administrador de seguridad (que además cumple tareas de administración de la base de datos). Esta persona podrá diagnosticar el error a partir del archivo de log confeccionado por el motor durante la ejecución de la tarea, y una vez solucionado, deberá ejecutar la tarea reconfigurando el job para que se ejecute ese mismo día fuera del horario de trabajo a partir del último registro exitoso del log.

Backup de Base de Datos

Composición

Se realiza el backup completo de la base de datos: todas las tablas del sistema especificadas en el modelo 2 y en el modelo 14 (tablas referidas a la seguridad). Los archivos resultantes de dicho backup se almacenan en cinta.

Ejecución

El proceso de backup se almacena en las tablas de tareas (jobs) del motor de base de datos y será este el encargado de lanzarlo a las 23 hs de los días 1 de cada mes.

Condiciones previas

El motor de base de datos debe estar corriendo y el equipo de grabación de cinta debe estar conectado y cargado con una cinta de suficiente capacidad para contener la información del backup.

Puntos de control

Ídem a tarea de depuración.

Contingencias

Ídem a tarea de depuración. En caso de error será el administrador de la base de datos el responsable de cancelar la depuración al día siguiente ya que esta sólo debe correrse luego de que el proceso de backup se haya completado correctamente.

Nota sobre el control de contingencias de tareas

Para realizar el control de contingencias de los procesos ejecutados en el puesto de la sala de servidores (Emisión de reporte de autorizaciones rechazadas, Emisión de reporte de prestaciones con deuda, Emisión de reporte de porcentaje de rechazo de solicitudes, Procesar consumos y prestaciones y Actualizar estado de morosidad de afiliados) se correrá un servicio que cada 30 minutos verificará que no haya habido ningún fallo que haya hecho que la tarea haya terminado abruptamente. Para ello se implementa el siguiente mecanismo:

Al comenzar la ejecución de la tarea lanzada por el scheduler, se seteará un valor en la registry propio de cada tarea que indicará que se comenzó la ejecución de la misma. Dicho valor será igual al valor actual mas uno.

Al finalizar correctamente la ejecución de la tarea dicho flag se setearará con valor igual a cero.

Cada 30 minutos el programa corriendo como servicio chequeará los valores de la registry de cada proceso, si encontrase alguno con valor distinto de cero verificará que exista una instancia de la aplicación corriendo en ese momento, de no ser así asumirá que dicha tarea finalizó incorrectamente de forma abrupta y buscará en el directorio de la misma el XML que contiene la dirección de e-mail a la que debe comunicársele la falla y a continuación enviará un correo a dicha casilla.

Las claves y valores en la registry para cada tarea son las siguientes:

Emisión de reporte de autorizaciones rechazadas

Clave: HKEY_LOCAL_MACHINE\SOFTWARE\MIKLOLIFE\RepAutRech

Valor DWORD: Ejecución

Valor String: Path de la tarea

Emisión de reporte de prestaciones con deuda

Clave: HKEY_LOCAL_MACHINE\SOFTWARE\MIKLOLIFE\RepPrestDeuda

Valor DWORD: Ejecución

Valor String: Path de la tarea

Emisión de reporte de porcentaje de rechazo de solicitudes

Clave: HKEY_LOCAL_MACHINE\SOFTWARE\MIKLOLIFE\RepPorcRech

Valor DWORD: Ejecución

Valor String: Path de la tarea

Procesar consumos y prestaciones

Clave: HKEY_LOCAL_MACHINE\SOFTWARE\MIKLOLIFE\ConsyPrest

Valor DWORD: Ejecución

Valor String: Path de la tarea

Actualizar estado de morosidad de afiliados

Clave: HKEY_LOCAL_MACHINE\SOFTWARE\MIKLOLIFE\Morosidad

Valor DWORD: Ejecución

Valor String: Path de la tarea

Enviar información carnets

Clave: HKEY_LOCAL_MACHINE\SOFTWARE\MIKLOLIFE\Carnets

Valor DWORD: Ejecución

Valor String: Path de la tarea

Especificación de archivos auxiliares:

Archivos XML:

Como se mencionó anteriormente, muchas de las tareas batch requieren la existencia de un archivo XML de configuración, el mismo tendrá el siguiente formato:

<?xml version="1.0" encoding="UTF-8"?>

<config TAREA_X>

<email resultado> direccion de e-mail adonde enviar archivo </email resultado>

...

<email resultado> direccion de e-mail adonde enviar archivo </email resultado>

<email error> direccion de e-mail adonde comunicar error </email error>

...

<email error> direccion de e-mail adonde comunicar error </email error>

<FTP prestadores>

<url> </url>

<puerto> número de puerto </puerto>

<directorio prestador>

<path> path al directorio del prestador </path>

<dir aceptados> nombre del subdir de docs. aceptados </dir aceptados>

<dir rechazados> nombre del subdir de docs. rechazados </dir rechazados>

</directorio prestador>

<directorio prestador>

...

</directorio prestador>

</FTP prestadores>

<FTP pagos>

<url>> </url>

<puerto> número de puerto </puerto>

<path reportes> path donde se guardan los reportes generados </path reportes>

</FTP pagos>

<FTP cobranzas>

<url>> </url>

<puerto> número de puerto </puerto>

<path archivos>

path donde cobranzas guarda los archivos de actualización de morosidad

</path reportes>

</FTP pagos>

</config TAREA_X>

No todos los archivos de configuración necesitan tener todas las secciones, sino que solo se setearán las que sean necesarias para el proceso.

TAREA_X es un string predefinido que sirve para validar que el XML en el directorio de una tarea determinada sea el que define la configuración del mismo. Los valores preestablecidos son los siguientes:

TAREA	VALOR DEL STRING
Emisión de reporte de autorizaciones rechazadas	RepAutRech
Emisión de reporte de prestaciones con deuda	RepPrestDeuda
Emisión de reporte de porcentaje de rechazos de solicitudes	RepPorcRech
Procesar consumos y prestaciones	ConsyPrest
Actualizar estado de morosidad de afiliados	Morosidad
Enviar información carnets	Carnets

Archivo INI:

Para la tarea “Enviar información carnets” se requiere un archivo adicional .ini que tendrá el siguiente formato:

[Fecha OK]

Fecha= valor fecha

Donde valor fecha es un número entero con formato AAAAMMDD donde AAAA representa el año, MM representa el mes y DD el día.

Archivos de log:

Para las tareas

Emisión de reporte de autorizaciones rechazadas:

Emisión de reporte de prestaciones con deuda:

Emisión de reporte de porcentaje de rechazo de solicitudes:

Se utilizan archivos binarios con los números de autorización (IDs) guardados uno a continuación del otro.

Para los procesos de Depuración y Backup, se utiliza los archivos provistos por el motor de base de datos.

Diseño de la arquitectura de procesamiento

Diseño de la arquitectura de procesamiento

Arquitectura física

El servidor central, los servidores de dominio y las estaciones de trabajo estan conectadas mediante un switch a una red Ethernet, mientras que las estaciones de trabajo de los CAPs estarán vinculadas al mismo servidor central a través de internet.

Modalidad de procesamiento

El sistema consta de varias capas de abstracción para permitir un desarrollo prolijo, veloz y fácilmente escalable.

Framework de desarrollo: Servicios técnicos de base sobre los que reside el sistema. Todas las capas de aplicación conocen esta capa base.

Dominio: Clases básicas con todas las entidades de negocio que representan la funcionaliad del sistema.

Persistencia: Clases encargadas de manejar la persistencia de la información.

Controlador: Cada instancia mantiene el estado de una sesión de un caso de uso del sistema.

Presentacion: Implementan la interfaz gráfica ofreciendo comunicación con los controladores.

Seguridad: Ofrece la funcionalidad para poder validad usuarios, y evaluar si un usuario/rol tiene los permisos suficientes para ejecutar determinadas tareas.

Diseño funcional

Las especificaciones del software y hardware de cada servidor o estación de trabajo, se especifica en el Modelo 10.

Especificación de tecnología

El presente documento detalla la especificación de la tecnología a utilizar, en cuanto a hardware requerido y software de base mínimo para el correcto desempeño del negocio, en particular tomando como base los modelos 13 y 14 que se describirán posteriormente.

Para dar estructura a este modelo, en primer lugar se hará una revisión del hardware mínimo requerido para implementar la solución, y luego el software base para lograr la correcta funcionalidad y disponibilidad del negocio.

Hardware Requerido

El hardware es muy variado de acuerdo a la función que implemente, dentro de la infraestructura de la organización. Como se detalla luego en el modelo 13 acerca de la formación de infraestructura, básicamente se cuenta con terminales de trabajo que es el grueso de los equipos, y luego con aquellas máquinas que hacen a los procesos y al networking de la corporación.

Comenzaremos por el equipamiento potente, el que se encargará de llevar a cabo los procesos de alto consumo de CPU y memoria y que deberán garantizar la eficiencia de la aplicación, así como la disponibilidad de la misma. En este apartado mencionaremos los servidores que deberán ubicarse en la sala de cómputos. En la misma, en la Casa Central además se deberá contar con el equipamiento de networking necesario para garantizar y mantener el enlace entre este edificio y cada uno de los CAPs (ver el detalle en el modelo 13, conceptos de seguridad). Todo este último equipamiento, como ser routers, switches y racks no estarán detallados en este documento, ya que corresponde a un trabajo conjunto entre los Ingenieros especialistas en infraestructura y el proveedor de internet y enlaces físicos y lógicos.

En primer lugar, necesitaremos 2 clusters, uno para albergar el servidor de base de datos relacional y otro para contener el servidor LDAP con la base jerárquica de directorio (ver luego la implementación en el modelo 14).

Estos clusters serán DELL PowerEdge 2850. Por cada cluster serán necesarios por lo menos dos nodos para garantizar la disponibilidad de la información (esto está sujeto a análisis financiero por parte de la empresa). Como bien lo dice su especificación, estas poderosas máquinas son rackeables, incluyen fuentes de alimentación redundantes y unidades de disco conectables en caliente y soporta discos RAID para la redundancia de datos. Las mismas deberán contar con dos procesadores Intel Xeon de 3.6GHz, bus frontal de 800MHz, 1MB de caché L2, 4GB de memoria y unidades de disco de 73GB (por cada nodo). En la imagen podemos apreciar uno de estos nodos. Recordemos que por lo menos necesitaremos dos nodos por cluster. Es importante destacar que esta máquina viene equipada con posibilidad de backup en cinta, requisito que se verá luego en el modelo 13, conceptos de seguridad. La forma de la máquina para el rack es de 2U.

Otro componente importante son los servidores del dominio que actuarán como PDC (Controlador de Dominio Primario) y BDC (Controlador de Dominio Secundario), que adicionalmente contendrán los servicios de DNS y WINS (implementado en Samba). Para ello hemos seleccionado dos servidores HP Proliant DL585. El mismo contará con procesadores AMD Opteron de 2.4GHz (con dos procesadores por cada máquina ya que se espera una alta carga para administrar todos los requerimientos de red), y 32 GB de memoria DDR. Tendrán rígidos de 80 GB. Su forma en el rack es de 4U. En esta maquinaria tendremos además del servidor SMB para controlar contendrán aquellos servicios de infraestructura tales como DHCP y DNS.

Como se puede apreciar, estos equipos son rackeables y sería conveniente que estuviesen en un solo rack dentro de la Casa Central de manera de mantener centralizado físicamente el núcleo de negocio de la corporación, de manera de poder hacer un monitoreo rápido en caso de incontingencia.

Ahora nos referiremos a las estaciones de trabajo. Las mismas tendrán una baja potencia ya que como se mencionó anteriormente, la carga pesada recae en los servidores. Las mismas tendrán un procesador Intel Pentium III a 500Mhz, con 256MB de RAM, rígido de 20GB y placa ethernet de 10MB (además, claro está, de monitor, teclado y mouse).

Software Requerido

El software base requerido será distinto obviamente para los servidores que para las estaciones de trabajo. Empezaremos en este caso al revés ya que es el caso más simple la revisión de una terminal de trabajo y luego pasaremos al software necesario para revestir los servidores.

Estaciones de Trabajo

Las estaciones de trabajo se instalarán en primer lugar con un Sistema Operativo Windows 2000 Professional y serán puestas en el dominio por el administrador del mismo. Además de contar con el Sistema Operativo instalado con aquellos componentes necesarios para acceder a internet y un cliente de correo electrónico como el Outlook Express, las estaciones de trabajo deberán contar con el siguiente software:

* Novell - Mono Framework 2.0

* Gtk# 2.0

La aplicación es multiplataforma con lo cual con estos componentes preinstalados se puede pasar a instalar la aplicación en sí y otros componentes.

Servidores

Para los servidores será necesario un sistema operativo más robusto y con buen soporte técnico, por lo cual la elección es que sean instalados con un Suse 9 de Novell, versión Enterprise (tanto en los clusterizados para el motor de base de datos y el directorio, como en el server stand-alone), instalando los servicios básicos de networking.

Servidor stand-alone primario

En el Server stand-alone se instalará también un demonio DHCP que entregará direcciones IP dentro de un rango acotado según la red que disponga el proveedor del enlace, y un server DNS. Además debe instalarse en el un servicio SAMBA 3. Todos estos paquetes vienen incluídos en la última versión de la distribución. Este servidor hará de PDC (Controlador Primario del Dominio).

Servidor stand-alone secundario

Este server contará con las mismas facilidades del anterior salvo que no tendrá los servicios de DHCP y DNS instalados. Sí tendrá un SAMBA 3 configurado como BDC (Controlador Secundario de Dominio). Para más detalle sobre estos servicios consultar el modelo 13, conceptos de seguridad.

Cluster DB

En este servidor será instalado un Novell Suse 9 versión Enterprise. Adicionalmente deberá instalarse un motor PostgreSQL 8 clusterizada con la base almacenada en un compartido por los nodos del cluster.

Cluster Directorio

En este cluster deberá instalarse nuevamente el Sistema Operativo Novell Suse 9 versión Enterprise y sobre él el directorio Novell eDirectory 8.7.3, junto a su administrador vía web Novell iManager 2. La base del directorio (dib) deberá estar compartida por los clusters de modo que los servicios vía LDAP estén disponibles el 100% del tiempo independientemente del estado del enlace.

El resto del software y el detalle de instalación del mismo será discutida en el modelo siguiente, instalación de componentes.

Modelo de instalación de componentes

Configuración de Entorno

Todas las estaciones de trabajo deberan contar con los siguientes elementos basicos para hacer funcionar el sistema :

Mono .NET Framework 1.2

Gtk# Runtime

Glade # Runtime

Mozilla Firefox 1.0

Estación de Trabajo de Promotores

El sistema operativo se instalara en su versión en español con la configuración regional y de teclado de Argentina. Existirá un icono en el escritorio para acceder directamente a la página de consultas de familiares del sistema.

El Mozilla Firefox 1.0 se utilizara con la configuración por defecto que tienen al instalarse

También tendrán configuradas las impresoras de recepción que se encuentran detrás de los puestos de trabajo para poder imprimir.

Estación de Trabajo Supervisores

El sistema operativo se instalara en su versión en español con la configuración regional y de teclado de Argentina. Existirá un icono en el escritorio para acceder directamente al sistema, donde el usuario deberá loguearse para utilizar el mismo.

El Mozilla Firefox 1.0 se utilizara con la configuración por defecto que tienen al instalarse

Estación de Atencion Personalizada

El sistema operativo se instalara en su versión en español con la configuración regional y de teclado de Argentina. Existirá un icono en el escritorio para acceder directamente al sistema, donde el usuario deberá loguearse para utilizar el mismo.

También tendrán configuradas las impresoras de administración que se encuentran detrás de los puestos de trabajo para poder imprimir. El Mozilla Firefox 1.0 se utilizara con la configuración por defecto que tienen al instalarse

Estación de Trabajo Director

El sistema operativo se instalara en su versión en español con la configuración regional y de teclado de Argentina. Existirá un icono en el escritorio para acceder directamente a la página de login del sistema, donde el usuario deberá loguearse para utilizar el mismo.

También tendrán configuradas las impresoras de administración para poder imprimir. El Mozilla Firefox se utilizara con la configuración por defecto que tienen al instalarse.

Estación de Help Desk

El sistema operativo se instalara en su versión en español con la configuración regional y de teclado de Argentina. Existirá un icono en el escritorio para acceder directamente al sistema, donde el usuario deberá loguearse para utilizar el mismo.

El Mozilla Firefox se utilizara con la configuración por defecto que tienen al instalarse.

WebServer

Se instalara GNU/Linux SUSE Exterprice Server incluyendo Apache, mod_mono y Mono .NET Frameork 1.2. Se configurara que el servicio de Apache HTTP Server se iniciara automáticamente con el inicio y de esta manera asegurarse de que siempre este corriendo.

También se configurara el SMTP Server Postfix con SpamAssesin y ClamAV Antivirus para proteccion de los equipos contra virus y spam.

DataServer

Se instalasa PostgreSQL Server 8.0. Será necesario configurar la seguridad del servidor para que el sistema y el WebServices tenga acceso a la base de datos. Además también será necesario que este habilitada la opción de conexión remota para que el técnico pueda administrar la base desde su computadora en caso de necesitarlo.

Servidor de RED1

Contara con un sistema operativo Linux Debian, cualquier versión estable y con un paquete de DHCP Server (Ej. udhcpd, dhcp).

Se instalara un paquete de firewall (Ej. firewall-easy, shorewall) que poseerá la siguiente configuración:

Permite acceso desde la RED1 a la RED2 a través de los puertos 80(HTTP), 443(SSL)

Permite acceso desde la RED2 a la RED1, en conexiones establecidas, a través de los puertos superiores a 1023.

También se instalara un paquete de ruteo (Ej. radvd) con la siguiente configuración:

La tabla de ruteo hacia la RED2, solo contiene la información necesaria para acceder al Web Server y no al servidor de RED2.

Servidor de RED2

Contara con un sistema operativo Linux Debian, cualquier versión estable.

Se instalara un paquete de firewall (Ej. firewall-easy, shorewall) que poseerá la siguiente configuración:

Permite acceso en ambos sentidos a través de los puertos 80(HTTP), 443(SSL) y puertos superiores a 1023 en conexiones establecidas.

Permite el acceso desde la RED2 hacia Internet a través del puerto 25(SMTP).

También se instalara un paquete de ruteo (Ej. radvd) con la siguiente configuración:

La tabla de ruteo hacia la RED2, solo contiene la información necesaria para acceder al Web Server y no al servidor de RED1

Hacia el otro lado permite ruteo a cualquier sitio de Internet

Diseño conceptual del menú

Diseño conceptual de seguridad

El presente documento estipula a modo conceptual los requisitos necesarios para cumplir con el negocio y asegurar el correcto tratamiento de la información. El objetivo primario es garantizar la continuidad comercial, y defender la información ante una amplia gama de amenazas, minimizando el daño a la misma y maximizando el retorno sobre inversiones y oportunidades.

El esquema presentado es un lineamiento acotado del esquema 1 de la normativa ISO 17799:2002 el cual es el estándar internacional sobre seguridad en tecnología de la información, adecuando el mismo al dominio de la presente aplicación y extendiendo a la infraestructura de la corporación Obra Social Asistencia Médica Miklolife. Adicionalmente se utilizarán otros estándares, muchos de ellos obtenidos de RFCs de la IETF, los cuales, en el momento de ser utilizados, se hará referencia al número de los mismos.

Introducción – Conceptos Básicos

El término de seguridad en este contexto se referirá a la preservación de las siguientes tres características fundamentales:

A-Confidencialidad: la información deberá ser accesible sólo a aquellas personas autorizadas a tener acceso a la misma.

B-Integridad: se debe mantener la exactitud y totalidad de la información y los métodos de procesamiento.

C-Disponibilidad: los usuarios autorizados al acceso a la información y sus recursos relacionados deben poder acceder a ellos en todo momento en que sea requerido.

En cuanto a la operativa diara de los usuarios frente a sus tareas, se manejarán dos términos clave:

A-Autenticación: se refiere a la fase en que se valida la identidad del usuario.

B-Autorización: se refiere a las actividades permitidas para el usuario, una vez autenticado.

La presente documentación es un delineamiento de cómo será implementada la infraestructura y la aplicación de gestión para respetar estos conceptos y asegurarse de que sean cumplimentados de la manera acordada.

Infraestructura Física

Bajo este tópico se describirá como deberá establecerse la infraestructura física de la corporación debido a la arquitectura remitida en el análisis de la aplicación, haciéndola extensiva para el futuro anexo de nuevas aplicaciones complementarias a la gestión de Afiliados, Coberturas, Planes, Autorizaciones, Prestadores y Prestaciones.

La empresa cuenta con una sede central y numerosos CAP distribuídos en todo el país. Para implementar un esquema de infraestructura física, el núcleo de procesamiento deberá incorporarse en la sede central de la obra social manteniendo la carga pesada del procesamiento de la información, restándole a los CAP la infraestructura mínima para mantener contínuo el enlace hacia la sede central, y a su vez protegido contra intentos de intrusión y violación de la información.

En sede central deberá implementarse un NOC donde serán ubicadas todos los servidores y dispositivos de networking necesarios para distribuir la aplicación a través de los CAPs, y en cada uno de éstos últimos se deberán incorporar racks con el equipamiento necesario para la accesibilidad al enlace y la protección del mismo ante amenazas a la seguridad.

Para el primer caso, se dispondrá de una sala propia. La misma deberá mantener los equipos debidamente instalados sobre racks. Deberá tener techo, piso y paredes falsas por los que deberá pasar el cableado debidamente canalizado. Adicionalmente deberá mantenerse la temperatura de la misma entre 10 y 15 grados Celsius con el objeto de mantener la temperatura de las máquinas. Las paredes, techo y piso reales deben estar preparadas para desastres físicos como fuego o inundación. El acceso debe estar bloqueado con cerraduras electrónicas, y activadas mediante un código numérico o una placa magnética, y toda persona ajena debe ser escoltado al mismo (recordar que es el centro neurálgico del negocio).

En el caso de cada CAP, deberá contar con un rack con los dispositivos de networking y servers necesarios para mantener el enlace, debidamente custodiados bajo llave, de donde saldrán las bocas hacia todos los puestos de trabajo.

Como en breve será descripto, se necesitará un servicio de directorio LDAP para el control de autenticación y autorización de los usuarios, y el motor de base de datos para el uso propio de la aplicación y futuras aplicaciones que fuesen de necesidad. Para garantizar la continuidad de la operativa diaria, se dispondrá de dos cluster separados, uno para guardar la base del directorio y otro para guardar la base relacional. Ambos clusters deben permanecer en el NOC de la sede central de modo de mantener centralizado el control de los mismos. Al estar clusterizados los dos servicios principales, se dispondrá de continuidad ya que ante la caída de uno de los nodos, otro de ellos tomará el servicio.

Infraestructura Lógica

En esta sección se describirá la infraestructura lógica a implementarse en la organización y particularmente en la aplicación. Para comenzar, se tratará la manera de organizar y estructurar a todos los usuarios desde el punto de vista de empleados de la firma, y como vincularlos hacia la aplicación.

Infraestructura de usuarios, y grupos y perfil en base a roles

Los usuarios de la organización serán almacenados en una base de datos jerárquica del tipo ISO X.500, con un servicio LDAP, en su versión 3 del protocolo, full compliant con las RFC 3377, 2251, 2252, 2253, 2254, 2256, 2829-2830 (las dos últimas para la autenticación). El servicio debe estar clusterizado como anteriormente se mencionó, y la conexión al mismo debe ser vía SSL. No deberá permanecer abierto el puerto TCP estándar 389 para comunicaciones por texto plano. El puerto abierto será el estándar para comunicación LDAP sobre SSL que es el 636 y toda comunicación se utilizará mediante querys LDAP. La base del directorio deberá bajarse a un archivo plano LDIF semanalmente e ir almacenando las copias de resguardo en cinta en modo progresivo con el motivo de poder hacer una restauración ante una situación de desastre.

En el siguiente modelo se describirá en exactitud la implementación del directorio y cómo almacenar a los usuarios y grupos. A modo de adelanto, los usuarios serán entries de la clase inetOrgPerson descrita en la RFC 2798 y para los grupos, entries del tipo groupOfUniqueNames, descrita en el estándar X.500.

El árbol tendrá una estructura jerárquica, comenzando por una raíz representando a la organización con clase organization, y luego contenedores de la clase organizationalUnit, cada uno representando un CAP, y debajo de cada uno de ellos los usuarios de ese CAP. Lo mismo para la Sede Central. Luego deberá haber un contenedor especial para los grupos. Los mismos definiran los roles que tendrán los usuarios en la aplicación.

El objetivo de usar un árbol LDAP es que es un servicio distribuído ideal para mantener la información de infraestructura, incluyendo usuarios, grupos, servidores y todo tipo de datos de tal índole. El usuario tendrá almacenados sus datos personales, sus credenciales y podrá ser vinculado a diversos grupos, pudiendo las aplicaciones utilizar estos agrupamientos para poder perfilar a los usuarios. El directorio además permite almacenar un password de diversos modos, inclusive extender la clase propuesta para poder almacenar credenciales del tipo biométrica, como el iris de ojos o las huellas digitales de los usuarios. Este último es muy recomendado debido a su gran avance en cuanto a tecnología se refiere. Adicionalmente, el directorio cuenta con la ventaja de separar la aplicación y la administración de empleados de la organización y sus roles dentro de la misma, manteniendo el usuario una sola identidad dentro de la empresa y conservando sus credenciales para entrar a las diversas aplicaciones con que cuente la corporación.

En el mismo podemos ver varios usuarios en distintos contenedores de acuerdo a su ubicación física de trabajo, y por cada una de ellas un contenedor organizationalUnit de modo de mantener reflejada la jerarquía de la organización. Vemos también el contenedor ou=Grupos_Gestion debajo del cual estarán ubicados aquellos grupos que perfilan los usuarios de nuestra aplicación de acuerdo a sus roles. Por último, el administrador general del directorio, colgando directamente de la raíz organizativa.

A modo conceptual, este esquema recién descrito se representa en la siguiente figura:

Vínculo hacia la aplicación – Propagación de perfiles según roles

En cuanto a la seguridad netamente de la aplicación, la misma estará montada en el mismo schema dentro del motor de base de datos (también clusterizado), pero no tendrá relación con los datos propios de la aplicación. Habrá una tabla con usuarios (donde se guardarán sus usernames, coincidentes con los RDN de sus entries LDAP), con el objeto de integrar un usuario a la aplicación. Adicionalmente esta tabla puede llegar a contener datos exclusivos del usuario dentro de la aplicación de ser necesario, pero es recomendable que se extienda la clase usuario si estos datos son más de infraestructura que de la aplicación en sí. Luego deberá existir una tabla que mapee los grupos con las funcionalidades existentes en la aplicación, y más en detalle, otra tabla que relacione las funcionalidades con ítems de menú (que se describirá en el modelo acerca del concepto e implementación de menues).

A modo conceptual, para aplicar este esquema, la aplicación debe en primer lugar realizar la autenticación del usuario, vía LDAP. Este procedimiento será descrito luego en la implementación. Luego, una vez autenticado se obtendrá su membreía trayendo vía LDAP los grupos a los cuales el usuario está enlazado y una vez con estros grupos y armado el perfil del usuario, se mostrarán aquellas funcionalidades a las que el usuario está autorizado a acceder.

Lo anterior se puede visualizar en el siguiente esquema gráfico:

Como se puede ver, el manejo de la seguridad es sencillo y recae en el poder del directorio con servicio LDAP.

NOTA: En el siguiente modelo, modelo 14 – implementación de seguridadse detallarán todos los pasos desde la autenticación hasta llegar a las acciones propias del usuario, y se presentará el DER en la base de datos relacional y reglas de integridad referencial para implementar este esquema. Este modelo es solamente a nivel descriptivo.

Ambiente interno

Internamente, se utilizará un dominio w2k, pero emulado a través de un SAMBA 3 utilizando el mismo directorio LDAP en reemplazo del Microsoft Active Directory, ya que este último posee escasas prestaciones a nivel de directorio, aunque debemos destacar que cumple con todas las especificaciones de las RFC (el tema de la exclusión de AD es poder tener un dominio windows bajo la administración poderosa de Samba, utilizando adicionalmente un directorio que permita mantener un árbol corporativo).

En las estaciones de trabajo de los usuarios se contará con clientes Windows 2000 Professional debidamente licenciados. Toda la administración del dominio deberá implementarse bajo Novell Suse Linux 9, mediante un PDC Samba 3 como recién se nombró, y adicionalmente manteniendo un servicio BDC Samba 3 a modo de resguardo, y para restaurar el dominio en caso de una caída del PDC.

Antes de proseguir, cabe destacar que deberá extenderse el schema del directorio con las clases auxiliares posixAccount, shadowAccountn y posixGroup, descritas en su totalidad en la RFC 2307 junto con las clases que vienen incorporadas en la instalación de Samba (sambaSamAccount para las cuentas de usuarios de dominio Windows).

La siguiente figura esquematiza el dominio logrado y su vínculo al directorio:

De esta manera, los usuarios se podrán loguear a sus terminales de trabajo y a la aplicación utilizando las mismas credenciales. Se recomienda analizar de incluir un logon script o una herramienta más poderosa de control remoto de terminales para acotar las actividades del usuario dentro de su estación de trabajo.

Ambiente externo

Hay dos tipos de accesos internos con los que se deben llevar cuentas. Uno de ellos es el grueso y son los afiliados. Otro son los prestadores. Ambos estarán dentro de un contenedor único llamado externos al nivel siguiente de la organización en el árbol de directorio, y la funcionalidad de los mismos se otorgará bajo el mismo esquema que a los usuarios internos de la aplicación. Esto se explicará en detalle en el modelo 14, implementación de la seguridad.

Conclusión

Bajo este esquema de infraestructura lógica, el usuario contará con el beneficio de mantener una única identidad dentro de la organización, pudiendo tener un set de credenciales único para todos los entornos operativos en donde se movilice y extendiendo este esquema a futuras implementaciones Single Sign On.

Enlace

Se deberá contratar un ISP para proveer un enlace dedicado que interconecte la Sede Central de la Obra Social con todos sus CAPs. Toda la organización dispondrá de una única red privada, y será en la Sede Central el único punto con salida a Internet, a través de otro enlace provisto por el ISP, centralizando de esta manera todos los controles de seguridad frente a amenazas externas. Los usuarios rasos no tendrán salida a intenet, utilizando mensajería interna para comunicarse. El servidor SMTP para los mails deberá permanecer en el NOC central para controlar el flujo hacia la red exterior.

A nivel conceptual, se refleja en el siguiente diagrama:

Seguridad frente a accesos externos e internos

Las transacciones que se realicen por las aplicaciones deben realizarse a través de un canal SSL, debiendo implementarse internamente un CA que emita certificados, los cuales deberán ser incorporados por todas las instancias clientes de la aplicación para poder establecer comunicaciones con las respectivas fuentes de datos. Bajo ningún punto de vista se permitirá información viajando vía texto plano.

En relación a esto, también se deberán establecer canales SSL para las comunicaciones provenientes desde el exterior. Todos los archivos recibidos por los prestadores deberán viajar bajo SSL. En este caso se deberá comprar certificados de un CA correspondiente disponible en Internet para garantizar la identidad de los participantes de la transacción. Los mismos deberán ser enviados por SFTP o SCP.

En el caso de los archivos subidos desde los prestadores y la clínica, el formato de los documentos dependerán de la operativa necesitada por la aplicación. En esta fase inicial los documentos transaccionados son emitidos vía un web service utilizando el estándar XML y vía FTP, según las interfaces ya pactadas por ambas partes.

En relación al último párrafo, es importante tener en cuenta que estas transacciones implican un alto impacto entre las partes negociantes, con lo cual se recomienda que en el futuro, se reconsidere que el documento trasmitido sea concatenado con la firma digital del origen de manera que garantice el no repudiation de la información enviada, y adicionalmente, todo este paquete deberá finalizarse con el hash MD5 del conjunto, certificando así que la información recibida es la que fue enviada desde el origen. Esto es sólo una recomendación a futuro y deberá ser evaluada por ambas partes como un proyecto aparte.

Para cada CAP deberá implementarse un firewall de modo que sólo estén abiertos los puertos que se utilicen para la aplicación, mail y mensajería. Visto y considerando el desempeño y papel que tienen los CAPs, deberán bloquearse todos los paquetes ICMP ya que no tienen sentido a nivel interno. Deberán estár disponibles a la altura del GateWay para que el administrador local de infraestructura pueda hacer debuggings y correcciones en casos de contingencia.

También debe estár debidamente configurado un firewall desde la Sede Central hacia la salida al exterior, permitiendo el paso único de puertos sobre de nivel aplicativo. Se deberá habilitar exclusivamente la salida a Inteneret para servicios como SMTP y aquellos que necesariamente requieran de la red externa. Asimismo se negociará con la parte gerencial, ya que por lo general son los que demandan tener conectividad con Internet, y servicios de mensajería externos.

Los WebServers deben estar detrás del firewall dentro del NOC de la Sede Central. El mismo estará habilitado hacia el exterior para cumplimentar con las transacciones online del cliente. En casos futuros de pasar a un Application Server se deberá respetar las mismas reglas, reconfigurando el FireWall para que habilitar la entrada y salida hacia el mismo.

Backups

Dado a que se prevée un alto volumen de tráfico diario con la base de datos, se establecerá un backupeo de la base de datos, diariamente y en forma progresiva, los cuales serán pasados a cinta y almacenados en lugares debidamente custodiados, preferentemente bajo llave electrónica o mediante autenticación biométrica.

Para el servicio de directorio se bajará a un LDIF semanalmente, debido a que el mismo no sufrirá cambios en el corto plazo.

NOTA: estos backups son a nivel servidores y no lo referente a la información que por lo general maneja la base de datos, contemplado en el modelo 06, Modelo de Procesamiento. Estos backups se hacen en forma progresiva y se almacenan en cinta y es el respaldo ante incontingencias y desastre. Solamente en el caso del directorio adicionalmente se guardará el LDIF como se nombró recientemente.

Auditoría

Servers y software de base

Se deben activar todos los logs de los servers y software de base utilizado, con un grado moderado de información además del timestamp de cada evento detectado, e incluyendo de ser posible un owner que haya disparado el evento. Los mismos deberán ser backupeados regularmente a intervalos diarios y bajados a cinta, para auditar a futuro en caso de contingencias. Es fundamental e indispensable que entre los servicios que logueen se encuentren la base de datos de la aplicación (para detectar eventos a nivel transacción) y el directorio, para detectar intentos de intrusión.

Aplicación

La aplicación deberá emitir un archivo de log por cada evento ocurrido. Principalmente deberá auditarse la pantalla de login y el logout del usuario, para detectar quien entró a la aplicación, quien salió y a que hora, así como intentos de intrusión o adivinación de passwords.

Dentro de la aplicación se deberá loguear cada transacción crítica con la base (como inserts o updates, no es necesario autidar selects a este nivel, para ello estára el log de la base de dato propia). También deberán auditarse aquellas operaciones a nivel de negocio, como por ejemplo la anexión de un Afiliado y por quien fue realizada, con su respectivo timestamp.

Seguridad dentro de la aplicación

Desde el momento del desarrollo se deberán tener las precauciones necesarias para evitar ataques comunes. Es obligatorio que en ningún momento valores introducidos por el usuario sean llevados directamente a la base de datos. Las transacciones con la misma deben estar en una capa superior evitando ataques indirectos a la base de datos, como sql injection. En el caso de ser absolutamente necesario llevar el contenido de una entrada del usuario a una sentencia sql, la misma deberá obligatoriamente parsearse con expresiones regulares a fin de detectar que venga sql embebido en la misma, el cual pudiera ocasionar inclusive hasta el borrado de las tablas si se tuvieran los permisos necesarios.

Referido a esto último, se deberá prearmar un usuario para el acceso a la base de datos, el cual deba tener restringido el acceso a la misma para hacer operaciones sobre el esquema de la misma. El usuario en el cual se impersonificará la apliación deberá tener permiso de lectura sobre las tablas y escritura y update de las mismas, de ningún modo podrá hacer alteraciones al esquema físico que compone la base de datos de la aplicación.

Detección de intrusiones

Para respaldar la seguridad de los usuarios, se establece como máximo un número de 3 intentos seguidos de login. Si el cuarto intento es fallido, la aplicación debe lockear la cuenta del usuario vía LDAP e inhabilitar al mismo. Sólo el administrador LDAP deberá ser capaz de rehabilitar y poner online al usuario, y en caso de pérdida de password, el administrador LDAP deberá pisar el password y se requerirá al usuario que cambie el password en el dominio al reingresar a la estación de trabajo. Todo esto se hará desde la clase inetOrgPerson explicada en el modelo 14 – implementación de seguridad.

NOTA: el administrador pisará el password del usuario y habilitará los flags necesarios para que el dominio exija un ingreso de password para entrar por parte del usuario. Este paso es instantáneo y debe ser instruído el empleado a realizarlo automáticamente al confirmarle el administrador que su password está listo para ser llenado. De la misma manera al ingresar un nuevo usuario se procederá de la misma manera. El acceso a una terminal física por agentes externos se debería contemplar en una documentación aparte acerca de seguridad a nivel organizacional, pero de todas formas debe estar garantizado que un extraño realice un acceso a una terminal propia de la empresa justo en el momento en que su password está vulnerable.

Glosario de términos para los estandares utilzados

Si bien todo lo usado en este documento son estándares internacionales altamente utilizados a nivel mundial, esta última sección provee un mini glosario con aquellos términos que puedan resultar de difícil comprensión para el lector.

ISO (Internacional Organization for Standarization):organización mundial cuyo objetivo es la normalización de un gran número de actividades y procedimientos a nivel corporativo, científico o de procedimiento.

IETF (Internet Engineer Task Force):organización mundial dedicada a la estandarización de protocolos de red disponibles públicamente en internet en RFCs.

RFC (Request for Comments):cada RFC es la definición de un protocolo de la IETF donde se incluyen todos los detalles e interfaces de los mismos, los cuales deben ser respetados estrictamente para mantener compatibilidad en las comunicaciones.

ISO 17799:2002 esquema-1: estándar a nivel internacional desarrollado por ISO para tratar la seguridad en tecnología de la información. Este estandar es requerido a nivel megacorporativo y normaliza todo el desenvolvimiento relacionado a la información tanto electrónica como no electrónica. Este documento es una versión acotada de los pasos a seguir propuestos por este esquema.

Directorio X.500:se cita la definición provista por la Universidad de Murcia, Españaacerca de este estándar “ X.500 como normativa nace como un intento de impulsar la construcción de un servicio de Directorio a nivel mundial, totalmente distribuido para proporcionar servicio tanto a personas como a máquinas. La normativa ha sido desarrollada conjuntamente por ISO y el CCITT, dando lugar en 1988 a la primera serie de recomendaciones”. En resumen, es una base de datos jerárquica con interfaces de acceso bien definidas y estrictas.

DAP (Directory Access Protocol): es parte del estándar X.500 y define una de las interfaces con el directorio.

LDAP (Lightway Directory Access Protocol):es el estándar usado hoy en día para el acceso a directorios X.500. En un primer momento se utilizaba DAP pero se realizó un acotamiento del mismo protocolo restándole complejidad poco o nunca utilizada, resultando este protocolo que se define en las RFC de la IETF citadas al comienzo del documento.

LDAP URI: protocolo de acceso a directorio vía una URL, descrita en una RFC de la IETF.

LDIF:estándar de serialización de los objetos del directorio, tambipen descrito en una RFC de la IETF. Mediante este protocolo se pueden tener objetos serializados. Adicionalmente, establece una interfaz con el directorio tanto para exportar como para importar archivos de este tipo, facilitando backups de la base, y generación de multiples objetos.

TCP:protocolo de transporte. Es parte de la pila TCP/IP y se ubica en la capa de transporte. Su objetivo es garantizar la transmisión de la información y garantizar que la misma llegue a las capas superiores en el orden en que fue mandada.

Puerto TCP:es el punto de acceso al servicio (SAP) de las capas superiores (aplicación, presentación y sesión). Las aplicaciones que se comunican a través de la red deberán establecer un número llamado puerto tanto de origen como destino, de modo de que el protocolo TCP pueda trabajar para múltiples aplicaciones simultáneamente.

SSL (Secure Socket Layer):protocolo para trasmisión de informción en modo seguro a través de una red, desarrollado por Netscape. El mismo descansa sobre TCP, y utiliza certificados clave pública/privada para realizar una transmisión encriptada sobre un canal.

SFTP (Secure File Transfer Protocol):protocolo utilizado principalmente para hacer subida y bajada de archivos entre máquinas remotas. Es FTP resposando sobre una capa SSL.

SSH (Secure Shell):protocolo reemplazante del RLogin el cual reposa sobre una transmisión encriptada mediante certificados correspondientes.

SCP (Secure Copy):protocolo que reposa sobre SSH para realizar subida y bajada de archivos entre terminales remotas, encriptando la información que viaja por la red.

NOC (Networt Operation Center):lugar físico donde residen servidores y dispositivos de networking de capa 1 a la 3, enfocados primordialmente en mantener la infraestructura de red de una o varias organizaciones, y en menor grado el funcionamiento de servicios. Si priman servers de información sobre los dispositivos de networking suele llamarse DataCenter.

RACK: proveniente del inglés, dícese del armario donde residen diversos dispositivos de networking como servers, switches, hubs y routers. Los mismos vienen construídos para tales fines y los dispositivos proveen soportes estandarizados para poder ser apilados en los mismos.

SMB/CIFS: protocolo utilizado para el compartimiento de recursos para grupos de trabajo, proveyendo reglas como autenticación y autorización a recursos.

SAMBA: servicio OpenSource que implementa un servidor SMB. Uno de sus usos es emular un Controlador de Dominio Windows, haciendo que las terminales Windows no noten que no es Windows quien está del otro lado.

PDC: siglas de Primary Domain Controler. Es el server que se encarga de realizar la autenticación y autenticación en un dominio SMB.

BDC: realiza el mismo trabajo que el server PDC, pero a nivel secundario, es decir, retoma su actividad en caso de detectar que sa crasheado el PDC.

Encriptación LanManager: se toma el password del usuario y se lo trunca a 14 bytes (o se lo rellena si no llega a esta cantidad). Con estos 14 bytes se encripta 3 veces un string predefinido de 8 bytes utilizando el algoritmo DES.

Encriptación NT:se toma el password del usuario, se lo convierte a unicode y se le aplica un hash MD4. Muy fácil de romper.

ISP (Internet Service Provider): compañía proveedora de enlaces corporativos y/o hogareños para conectividad a internet o propia.

SMTP (Simple Mail Transfer Protocol): protocolo para el envío de mensajería (llamado típicamente ‘e-mail’) a través de una red. Es RFC en la IETF.

No repudiation: metodología a nivel electrónico que garantiza que una actividad o documento ejecutada por una entidad (individuo, corporación, etc), no puede ser refutada por la misma.

SQL (Structured Query Language): desarrollado originalmente por IBM, es un estándar para comunicación con una base de datos relacional. Hoy en día existe un ANSI base del que parten todos los motores, y customizado según el motor en particular, lo que lo hace un lenguaje débil y poco portable, a diferencia de LDAP.

Application Server:Servidor de aplicaciones Java tales como JSP o Servlets (o los más recientes Portlets). Proveen servicios a nivel portal para aplicaciones tanto de intranet como extranet.

JAVA: lenguaje originalmente llamado OAK desarrollado por Sun Microsystems, totalmente orientado a objetos. El mismo es interpretado por una JVM (máquina virtual), la cual posee la desvirtud de consumir muchos recursos de la máquina, y a su vez no permite realizar tareas de bajo nivel, sin utilizar la interfaz de lenguaje nativo.

Anexo - Detalle de la terminología LDAP

Este pretende ser un mini resumen acerca de las funcionalidades previstas por el protocolo y algunas definiciones.

En primer lugar, un directorio es un conjunto de objetos, llamados entries. Cada uno de ellos posee atributos, algunos de ellos mandatorios y otros optativos. Los primeros son necesarios prellenarlos para crear el objeto, los otros puden ser cargados luegos.

Un atributo puede ser monovaluado (es decir, tener un solo valor) o multivaluado (poseer mucho, primera diferencia con una instancia en una base relacional).

Cada entry pertenece a una o más clases. Una clase es un conjunto predefinido de atributos, donde se definen además si van a ser mandatorios ú opcionales. Una clase puede ser estructural o auxiliar. Una clase auxiliar puede ser utilizada por cualquier objeto para incorporar sus atributos. Una clase estructural define al objeto en si.

Los objetos están relacionados jerárquicamente entre ellos, y se los accede según su jerarquía en el árbol. Hay muchas formas de definirlos, la más comun es desde el objeto hacia la raíz. Cada objeto se encuentra dentro de un contexto, y un objeto dentro del contexto es determinado por un nombre único dentro del mismo, llamado RDN (Relative Distinguished Name). El RDN junto al contexto del objeto, forman el DN (Distinguished Name), el cual es el nombre distintivo del objeto, no hay manera de que hayan dos objetos con DN iguales (los RDN pueden estar repetidos en contextos diferentes).

Las operaciones comunes en un directorio, vía LDAP son las siguientes:

Conexión / Desconexión: se abre y cierra una conexión contra el directorio en el puerto donde el mismo esté escuchando.

Bind: se toma la conexión impersonificado en uno de los objetos usuario del directorio, presentándole al directorio el DN del mismo y el password. A partir de ese momento, las operaciones que se realicen en el directorio estarán bajo responsabilidad del usuario que ha hecho el bind y por lo tanto bajo los permisos otorgados para dicho usuario.

Search: búsqueda de objetos. Para la misma se debe definir un objeto base (puede ser una hoja o un nodo dentro del árbol), un scope de búsqueda (el protocolo establece tres tipos posibles; base –en el mismo objeto-, un nivel –el nivel inmediatamente inferior- y subárbol –el subárbol completo a partir del objeto base-). Finalmente, se permite especificar criterios de búsqueda, en notación prefija, y los atributos que se desea recuperar de los objetos resultantes. La búsqueda puede estar acotada desde el lado del server o del cliente. Si está acotada en ambos, prevalecerá el número seteado en el server.

Add: se refiere a la creación de un nuevo objeto.

Modify: se refiere a la modificación de atributos dentro de un objeto.

Rename: se refiere al cambio de RDN del objeto.

Delete: se refiere al borrado del objeto.

Compare: se refiere a la comparación de un atributo contra un valor específico.

Diseño de la implementación del menú y seguridad de acceso

El presente documento detalla la implementación de seguridad sólo a nivel de la aplicación, en base a los conceptos partidos de los anteriores modelos de seguridad y menú, así como la especificación del DER propio dentro de la base de datos para tratar estos tópicos, vinculados a los servicios de la base de directorio. Aunque esta documentación estipula específicamente las especificaciones sobre la aplicación, inevitablemente debemos hacer referencia al manejo de usuarios del dominio Windows implementado en Samba ya que los usuarios en el directorio son los autoritativos. Por ello comenzaremos por este lado y luego seguiremos con la implementación propia referente a la aplicación.

ABM de usuarios en el dominio, datos propios de los usuarios internos

Los usuarios internos son todo el personal de la Obra Social. En el momento de la incorporación de un empleado (cualquiera sea su cargo), el administrador del dominio deberá darlo de alta como tal bajo el contenedor correspondiente (en Casa Central o en alguno de los CAP). Esto lo debe hacer a través de alguna de las herramientas administrativas que provee Samba como WEBMIN o SWAT, que son aplicaciones WEB de uso libre, o con las propias herramientas de samba por línea de comando, como el smbpasswd.

La estructura corporativa del árbol será como se muestra a continuación:

donde Sede Central es el contenedor que representa la Casa Matriz de la Obra Social y CAPn es el contenedor que representa a cada CAP. A la altura de los contenedores deberá crearse el usuario administrador general de todo el directorio, con derechos de supervisor sobre roto el árbol (desde o=Miklolife hacia abajo en el subárbol, heredando los permisos hacia abajo).

Los usuarios entrantes deberán incorporarse debajo del contenedor donde estén trabajando físicamente, posibilitando el movimiento a otro contenedor en caso de viaje o cambio de lugar físico de trabajo. Adicionalmente se genera un contenedor ou=Grupo_Gestion exclusivo para la nuestra aplicación, debajo del cual estarán los grupos representativos de roles dentro de la aplicación, tema que se tratará en breve y con sumo detalle. El contenedor ou=Desafectados es para uso exclusivos de usuarios desafectados de la empresa. Finalmente, en el contenedor ou=Extranet deberán ubicarse los afiliados, que no son usuarios internos, sólo a los efectos de autenticación. Este tópico también será discutido en breve.

El administrador deberá setear un password default que el usuario deberá cambiar la primera vez que se loguée al dominio desde una de las terminales (es importante destacar que el administrador del dominio debe incorporar los trustees correspondientes para todas las máquinas dentro de la organización). Este procedimiento fue descrito en el modelo 13, conceptos de seguridad, en donde se detalla las precauciones a tomar en el intermedio en que se pise un password de usuario o se cree uno por primera vez.

Las políticas de password establecidas son de 6 caracteres mínimo, incluyendo por lo menos un carácter numérico. Se establecerá adicionalmente una política de caducidad de contraseña de 60 días, impidiendo establecer la contraseña actual como próxima en el momento de cambio.

Para la desafectación de usuarios se tomará la siguiente política: cuando un empleado es despedido o se desvincula por otro medio de la empresa, se lockea su cuenta vía LDAP y se mueve el mismo al contenedor ou=desafectados. A los 30 días el usuario es borrado definitivamente del directorio.

ABM de usuarios externos, usuario administrativo para la aplicación

La aplicación deberá contar con un usuario administrativo para realizar las tareas de autenticación, autorización y creación de usuarios externos. Este usuario estará dentro del contenedor de la Casa Central y se su DN (Distinguished Name) será cn=admin_gestion,ou=Sede_Central,o=Miklolife. El mismo deberá tener los siguientes permisos:

Sobre los contenedores de usuarios (todos estos permisos heredados al subárbol):

Búsqueda

Comparación de atributos

Lectura de objetos y sus atributos

Sobre el contenedor ou=Grupo_Gestion,o=Miklolife deberá tener (todos estos permisos heredados al subárbol):

Búsqueda

Comparación de atributos

Lectura de objetos y sus atributos

Creación

Modificación de atributos

Renombrado

Eliminación

A su vez, y como se ve en la figura esquemática del directorio, habrá un contenedor externos. Dentro del mismo se alojarán los usuarios que no son empleados de la corporación, es decir aquellos que realicen tareas desde los prestadores y los pacientes mismos. El Distinguished Name del contenedor será ou=Externos,o=Miklolife y tendrá los siguientes permisos (todos heredados al subárbol):

Búsqueda

Comparación de atributos

Lectura de objetos y sus atributos

Creación

Modificación de atributos

Renombrado

Eliminación

Estos usuarios tendrán pocos atributos habilitados como se verá luego, y servirán para loguearse remotamente hacia la aplicación, pero usando el mismo repositorio de identidades que el resto de los usuarios de la aplicación. Los mismos basarán su comportamiento bajo el mismo esquema que el resto, por asignación a grupos dentro del contenedor de grupos, que será quien defina el o los perfiles de los usuarios.

Datos propios de los usuarios, contenedores y grupos

Como se especificó anteriormente, se emplearán las RFC 3377, 2251, 2252, 2253, 2254, 2256, 2829-2830, y particularmente para los usuarios, la RFC 2798 que define la clase estructural inetOrgPerson y la RFC 2307 que define las clases posixAccount, posixGroup, shadowAccount auxiliares utilizadas por Samba, así como también las clases propias de Samba como sambaSamAccount. También se utilizarán las clases estructurales organization y organizationalUnit para los respectivos contenedores que jerarquizan al árbol, y la clase estructural groupOfUniqueNames para los grupos.

A continuación se detallan los atributos que tendrán las entries de cada clase, exceptuando a los usuarios que se tratarán luego con más detalle:

Organización:es la raíz del subárbol que representa la corporación, serán instancias de la clase organization. Solamente contendrá su DN, el atributo O con el RDN del objeto, y una descripción, en la misma se presentará la razón social de la empresa.

Contenedores:serán de la clase organizationalUnit. Dividen jerárquicamente al árbol para no hacerlo plano si no corporativo, conteniendo a los distintos usuarios y grupos de manera separada según ubicaciones físicas y roles. Serán cargados su DN, el atributo ou que forma su RDN y como descripción deberán contener el motivo por el cual se realizó dicha subdivisión lógica.

Grupos:serán de la clase groupOfUniqueNames definida en X.500, y adicionalmente tendrán la clase auxiliar posixGroup para el tratamiento Samba, en el cual no ahondaremos. Estos objetos tendrán cargado su DN, el CN como RDN del mismo, y los atributos optativos description, donde estará el papel que juega el grupo en la corporación o a nivel de aplicación, y uniqueMember, que contendrá el DN de los usuarios que pertenezcan a este grupo. Los atributos cargados por Samba no serán descriptos en este documento, y están disponibles online en www.samba.org, lo mismo para los usuarios.

Usuarios Internos

Este tipo de objeto será tratado especialmente y se mostrarán los datos necesarios para los usuarios empleados de la organización. A continuación se muestra una tabla con los atributos de la clase inetOrgPerson que serán utilizados (no serán utilizados todos), y un mapeo al mundo humano de que representa cada atributo. Los atributos están definidos en esta clase y en las clases de la que hereda (organizationalPerson, person, Top) según la RFC 2798:

Nombre del atributo	Nombre descriptivo
uid	Apodo del usuario
cn	Apodo del usuario
sn	Apellido
givenName	Primer Nombre
fullName	Nombre Completo
departmentNumber	Numero de CAP / Sede Central
employeeNumber	Número de legajo
employeeType	Tipo de empleado (efectivo, pasante, contratista)
homePhone	Teléfono Particular
homePostalAddress	Dirección Particular
mail	Mail corporativo
photo	URI a la foto del empleado
userPassword	Password del usuario, encriptado según el directorio elegido (este atributo no se puede leer como parte del esquema, sólo admite un compare, esto es a nivel estándar X.500)
description	Observaciones Generales
title	Cargo del Empleado
ou	Area
L	Zona de trabajo

Usuarios Externos

A continuación se presenta la misma tabla con los atributos necesarios (y únicos) para los usuarios externos como prestadores y afiliados:

Nombre del atributo	Nombre descriptivo
uid	Apodo del usuario
cn	Apodo del usuario
sn	Apellido
givenName	PrimerNombre
fullName	NombreCompleto
homePhone	Teléfono Particular
homePostalAddress	Dirección Particular
mail	Mail corporativo
userPassword	Password del usuario, encriptado según el directorio elegido (este atributo no se puede leer como parte del esquema, sólo admite un compare, esto es a nivel estándar X.500)

Programas a utilizar

Ya hemos establecido que el dominio será windows pero administrado desde un SAMBA, aplicación de uso gratuito disponible en internet. Para soporte de ésta aplicación distribuida, se utilizará un sistema operativo Novell Suse Enterprise 9 (no Netware) que correrá bajo las especificaciones planteadas en el modelo 13, conceptos de seguridad. El mismo sistema operativo será utilizado para soportar al directorio. Para la base del directorio hay una amplia gama de opciones, como por ejemplo:

eDirectory, de Novell

Active Directory, de Microsoft

Oracle Internet Directory, de Oracle

OpenLDAP, del grupo OpenLDAP y de distribución gratuita

AD y OID de Microsoft y Oracle respectivamente los descartamos de inmediato por sus bajas prestaciones y difícil administración. La elección se inclina hacia Novell eDirectory, producto de muchos años de antigüedad y totalmente robusto. El mismo utiliza MD5 para proteger internamente sus datos haciéndolo difícil de vulnerar. OpenLDAP se descartó a pesar de ser una opción OpenSource, ya que es pésimo a nivel de directorio, si bien cumple con todos los estándares, posee muchas limitaciones y características que el mismo grupo OpenLDAP piensa no desarrollar en el futuro.

Para las estaciones de trabajo, se instalará un windows 2000 professional, y la aplicación de gestión. Se limitará la manejabilidad del sistema operativo por parte del usuario común, y se activará un protector de pantalla con contraseña a los 5 minutos de desuso, de modo tal que la estación permanezca lockeada en caso de que el usuario deje su puesto de trabajo momentáneamente.

En cuanto al motor de base de datos a utilizar existen varias alternativas también:

SQL Server 200X de MS

Oracle 10

Mysql

PostgreSQL

La inclinación surge hacia PostgreSQL debido al alto contenido de prestaciones y características embebidas y a que es de uso gratuito, compitiendo con Oracle, cuyo motor es muy potente y sus prestaciones son altas, como también la de SQL Server. MySQL todavía está carente de ciertas características que facilitan el desarrollo, razón por la cual queda en último lugar entre los motores posibles.

Base de Datos Relacional, diseño y características

Como se explicó en el modelo 13, conceptos de seguridad, para manejarla a nivel aplicación se combina la potencia del directorio con tablas paramétricas de la base de datos propia de la aplicación. A nivel esquemático, se mostrará nuevamente la figura del modelo anterior:

Los grupos del directorio (clase groupOfUniqueNames) serán quienes llevarán la tarea de mantener el perfil del usuario. Un usuario puede pertenecer a todos los grupos que desee, de manera que se pueden combinar haciendo perfiles más complejos. Para ver los perfiles por defecto que deberán estar inicialmente, ver la sección 6.

Recaerá luego en la base de datos relacional el parametrizar cada grupo contra una funcionalidad propia de la aplicación. A continuación se detalla el DER de esta porción de la base de datos de la aplicación, completamente aislada e independiente del resto de las tablas y relaciones:

Explicaremos a continuación el significado y uso de cada una de las tablas.

Diccionario de datos

Tablas

Tabla	Descripción
Perfil_Funcionalidad	Su objetivo es mapear un grupo del directorio contra una funcionalidad propia de la aplicación.
Funcionalidad	Tabla paramétrica que contiene todas las funcionalidades posibles dentro de la aplicación.
Funcionalidad_Menu	Desglosa cada funcionalidad en subactividades, y serán las que utiliza la aplicación para mostrar en pantalla.

Diccionario de composición de los campos

Tabla	Campo	Tipo	Nulo	PK	FK	Referencia
Perfil_Funcionalidad	Id	Integer	NO	SI	NO	
	Nombre_grupo	Varchar	NO	NO	NO	
	Fid_funcionalidad	Integer	NO	NO	SI	Funcionalidad
Funcionalidad	Id	Integer	NO	SI	NO	
	Nombre_funcionalidad	Varchar	NO	NO	NO	
	Descripcion	Varchar	SI	NO	NO	
Funcionalidad_Menu	Id	Integer	NO	SI	NO	
	Fid_funcionalidad	Integer	NO	NO	SI	Funcionalidad
	Nombre_Menu	Varchar	NO	NO	NO	
	Descripcion_menu	Varchar	SI	NO	NO	

Especificación descriptiva de los atributos

En primer lugar, tenemos la tabla Perfil_Funcionalidad. Dentro de ésta tabla tenemos un id interno a la tabla de modo de poder identificar como único a cada registro. Luego tenemos nombre_grupo, que es el nombre textual de uno de los grupos mantenidos en el contenedor de grupos del directorio (debe coincidir con el atributo CN del mismo). Finalmente, tenemos fid_funcionalidad que es la clave foránea hacia una funcionalidad, dentro de la entidad Funcionalidad que será descrita en el próximo paso.

En la tabla Funcionalidad, tenemos un id identificador único de cada registro y clave primaria de la tabla. Luego vemos el campo nombre_funcionalidad, que deberá ser un nombre corto distinsor de una de las funcionalidades de la aplicación. Finalmente, el atributo descripción, que explayará brevemente el uso de tal funcionalidad. Esta es una tabla netamente paramétrica.

Por último, contamos con la tabla Funcionalidad_Menu, cuya función es el desglose de cada funcionalidad en diferentes subactividades. Cada una de éstas será un ítem de menú, tal como se explicó en el modelo 12, diseño conceptual de menú. Como siempre, el campo id identifica lógicamente a cada registro. Luego, fid_funcionalidad será un foráneo hacia una funcionalidad de la tabla del párrafo anterior. Luego vemos a nombre_menu que es un descriptivo corto de la actividad que proporcionará el item en cuestión y es lo que se mostrará en pantalla, y descripcion_menu es una breve descripción acerca de que realiza esta subactividad desprendida de cierta funcionalidad.

Reglas de Integridad Referencial

Tabla Funcionalidad

Al borrarse un registro de esta tabla, deben borrarse en cascada aquellos que le hacían referencia desde las tablas Perfil_Funcionalidad y Funcionalidad_Menu. Esta operación es muy crítica, ya que se está sacando una funcionalidad completa a la aplicación.

Cuando se da de alta, no es necesario en principio que Se generen registros en las otras dos tablas. Si no contiene registros referenciados en Funcionalidad_Menu, simplemente se toma como que dicha funcionalidad no posee subactividades.

Tabla Perfil_Funcionalidad

Tanto al crear o borrar un registro, el mismo no tiene impacto en el resto de las tablas. Simplemente se le está agregando o sacando respectivamente, una funcionalidad al rol elegido.

Tabla Funcionalidad_Menu

En este caso la creación y el borrado son irrestrictos como en el caso anterior. Crear o borrar un registro implica agregar o eliminar una subactividad a una funcionalidad.

Perfiles y funcionalidades por defecto

En el momento inicial la aplicación contará con ciertos perfiles ya creados por defecto. Los mismos estarán contenidos dentro del contenedor ou=Grupo_Gestion,o=Miklolife y serán los siguientes grupos:

RDN (Relative Distinguished Name)	Objetivo
Cn=autenticados	Representa a todos los usuarios que tienen acceso a la aplicación. Solamente los usuarios que se encuentren dentro de este grupo podrán intentar autenticarse contra la aplicación, de lo contrario serán rechazados automáticamente.
Cn=Administradores	Representa a los usuarios cuyo rol es Administrativo (ver el actor Administrador en el caso de usos).
Cn=Prestadores	Representa a los usuarios que son empleados de las prestadoras, los mismos estarán en el contenedor ou=Extranet,o=Miklolife y tendrán todas aquellas funcionalidades habilitadas para usuarios empleados de las distintas prestadoras de la Obra Social.
Cn=Afiliados	Representa a los usuraos afiliados a la obra social, que accederan por medio de la extranet para realizar tareas sobre sus cuentas y a nivel general acerca de su Plan. Estos usuarios estarán contenidos dentro de ou=Extranet,o=Miklolife.
Cn=Operadores	Representa a todos los usuarios cuyo rol es Operador (ver el actor del mismo nombre en el caso de uso).

Así mismo, y relacionadas con los grupos anteriores, se deberán presentar las siguientes funcionalidades por default:

Grupo (perfil)	Funcionalidad
Cn=Administradores	Mantener Planes Mantener Prestaciones Mantener Prestadores Mantener CAPs Armar Cartilla
Cn=Prestadores	Recibir y Cotejar consumos y Prestaciones
Cn=Operadores	Mantener Afiliado Ingresar Solicitud Agregar Afiliado
Cn=Consultor	Atender Consulta Afiliado Consultar Autorizaciones
Cn=SolicitanteAutoriz	Pedir Autorización Manual Pedir Autorización Automática
Cn=Auditor	Resolver Autorizaciones
Cn=Promotor	Registrar Visitas
Cn=Enrutador	Emitir Hoja de Ruta

El mantenimiento de estas tablas lo realizará el administrador de seguridad, perteneciente al área de sistemas. Para ello utilizará directamente el sistema de consultas provisto por el motor de base de datos.

Operatoria diaria – Integración del directorio y la base de datos

En esta sección se mostrarán las actividades relacionadas a seguridad por parte de la aplicación y se delineará con detalle cómo se debe proceder para implementar tales actividades.

Login en el Dominio

Este tópico no hace a la aplicación y se describirá brevemente el sistema de login de un dominio windows, aunque no se graficará ni entrará en detalles con respecto al mismo.

El usuario introduce su usuario y password así como también especifica el dominio al que se quiere loguear. En ese momento, la máquina envía al PDC una petición de login, junto con el modo de encriptación utilizado (NT o LanManager, ver el glosario del modelo 13). El PDC contesta (si la máquina está registrada) con un string de 8 bytes random, llamado challenge. El mismo llega a la máquina. Allí se encripta NT o LanManager el password introducido por el usuario, y con él encripta el challenge y se envía el resultado al PDC. Del otro lado, el PDC hace lo mismo con el password que tenía almacenado para el usuario (lo busca del objeto usuario del directorio) y finalmente compara estos dos strings, autenticando la veracidad del usuario si el resultado de la comparación es positivo, o denegando su acceso al dominio si es negativo.

Login a la aplicación

Este proceso se relatará en detalle ya que se considera crucial en cuanto al tema de seguridad. Una vez adentro de la aplicación, el usuario podrá hacer todo lo que su rol le permita con lo cual una vulneración en esta parte puede llegar a romper el negocio.

La pantalla de login es simple y consta de dos cajas de texto, una para ingresar un username y luego un password, éste último mostrando como echo caracteres asterisco.

La autenticación constará de los siguientes pasos:

El usuario ingresa su username y su password. El usuario uid=admin_gestion,ou=Sede_Central,o=Miklolife en el cual se impersonifica la aplicación, realiza una conexión contra el server LDAP, y un bind con sus credenciales propias, hardcodeadas en la aplicación (bind es el término por el cual se toma las riendas de las operaciones del directorio bajo cierto usuario, seteándose automáticamente los permisos correspondientes). El siguiente paso es hacer un searh LDAP, a partir de o=Miklolife, con scope subtree (ver la RFC 2254 para los detalles de la búsqueda y los filtros LDAP). Se usará el siguiente filtro (&(objectclass=inetOrgPerson)(uid=XXXXX)). Este filtro, para el público sql, es un análogo a la porción where en un select sql. El mismo está en notación prefija, y lo que queremos precisar acá es que el server devuelva aquellos objetos (debería ser uno sólo o ninguno) con clase inetOrgPerson (es un usuario) y cuyo uid es XXXXX (donde esto último es el username introducido por el usuario). Si el mismo no existe en el directorio (código LDAP 32 – No Such Entry), la autenticación falla y se deniega el acceso al usuario. Si el usuario existe, se pasa al punto 2 (código LDAP 0, success). Si hubiere más de un resultado, se deniega el acceso, pero este es un error administrativo, ya que no deberían haber dos usuarios iguales ya que esto está restringido por el dominio.

En este punto obtenemos el DN del usuario resultante de la búsqueda del punto 1. Ahora, se realiza un bind LDAP con este mismo usuario (con su DN y su password), esta acción se traduce como un rebind. Si la misma falla (código LDAP 49, Invalid Credentials), el password ingresado por el usuario es incorrecto y se deniega el acceso. Si el código es 0 – Success el usuario está casi adentro de la aplicación y se pasa al punto 3.

El siguiente paso es buscar si el usuario está en el grupo cn=autenticados,ou=Grupo_Gestion,o=Miklolife. Si no se encuentra dentro del mismo (atributo uniqueMember) se deniega el acceso al mismo (el usuario es parte del dominio pero no de la aplicación). Si el DN del usuario se encuentra entre los miembros del grupo, entonces el usuario pertenece a la aplicación y está adentro de la misma.

Es importante destacar que en cada punto se posibilita una denegación de ingreso al usuario por alguna causa. Bajo ningún concepto hay que darle al usuario información del por qué de la falla de la autenticación ya que estas son pistas que pueden ayudar a piratas informáticos. Ante cualquier error, se devolverá el mensaje “Su usuario o password son incorrectos”. Es el único mensaje que se arrojará ante un login erróneo.

El paso siguiente es realizar la autorización del usuario. Para ello, se buscan aquellos grupos en cuyo atributo uniqueMember figure el DN del usuario logueado. Luego, con la lista de estos grupos, se entra en la base de datos en la tabla Perfil_Funcionalidad, y se buscan todas las entradas de la tabla que tengan los grupos resultantes de esta última búsqueda. Una vez detectadas estos registros, se tendrán las funcionalidades asociadas al rol del usuario dentro de la tabla Funcionalidad y junto con ellas, los ítems de menú cuando correspondan, si es que hay asociados registros en la tabla Funcionalidad_Menu.

El siguiente esquema representa el usuario en la autenticación y búsqueda de perfiles para mantener una mejor idea conceptual de lo que se pretende lograr.

ABM de usuarios internos

Para estos procesos se deberá utilizar un usuario perteneciente al grupo cn=Administradores,ou=Grupos_Gestion,o=Miklolife.

Alta

Para dar de alta un usuario, se ingresará el username del mismo, y con éste se hará una búsqueda en todo el árbol, a partir de o=Miklolife. Si el usuario no existe, se informa del hecho y se deniega el alta del mismo (un usuario debe pertenecer a la corporación).

En caso de existir el usuario, simplemente se lo agrega (controlando que no estuviera previamente incluido) al grupo cn=autenticados,ou=Grupo_Gestion,o=Miklolife.

El siguiente paso es asignarlo a los perfiles correspondientes, con lo cual el paso siguiente es traer todos los grupos (menos cn=autenticados) debajo del contenedor ou=Grupo_Gestion,o=Miklolife. Se mostrará una lista de los mismos (solamente el valor del atributo CN). El usuario administrador podrá asignarlo a múltiples perfiles, desde un combo multiseleccionable desplegable. Finalmente, se asignará el usuario a cada uno de los grupos elegidos vía LDAP. Un usuario puede ser ingresado sin membresías previas, simplemente no se le presentará ninguna actividad al loguearse a la aplicación. Luego podrán agregarse membresías en la instancia de modificación.

Modificación

Para los usuarios internos a la corporación, no se permitirán modificar datos inherentes al mismo dentro de esta aplicación, debe realizarse desde alguna de las herramientas administradoras del dominio. En esta instancia para estos usuarios, se permitirá cambiar las membresías a los grupos que harán el perfil del usuario. Para ello se presentará un combo como en el proceso de alta, con los grupos actuales a los que el usuario está vinculado preseleccionados. Se elegirán los que se desee para el usuario en cuestión, y se guardarán sus membresías vía LDAP.

Baja

La baja de un usuario simplemente consiste en desvincularlo de todos los grupos dentro del contenedor ou=Grupos_Gestion,o=Miklolife. En realidad basta con sacarlo del grupo cn=autenticados pero se le sacará la membresía a todos los grupos de modo de no dejar basura.

ABM de usuarios externos

Para estos procesos se necesitará un usuario que sea miembro del grupo cn=Administradores,ou=Grupos_Gestion,o=Miklolife. Todos los usuarios tratados estarán únicamente en el contenedor ou=Extranet,o=Miklolife.

Alta

El alta de usuarios externos es similar a la de los internos pero se le permitirá además llenar los campos Username (uid y cn) ,Apellido (sn), Primer Nombre (givenName), Nombre Completo (fullName), Teléfono (homePhone), Dirección (homePostalAddress), mail (mail) y password (userPassword), con retipeo de este último, y ocultando los caracteres presentando asteriscos en la pantalla (entre paréntesis se muestran los atributos que se guardarán a nivel LDAP). Sólo el campo Apellido será obligatorio, ya que con él se guarda el campo sn del objeto usuario y en la clase estructural inetOrgPerson este atributo es mandatario. Se deberán parsear los campos ingresados para evitar errores o intentos malintencionados de guardar información (igualmente cada atributo del directorio tiene su propia sintaxis y no admitirá valores que se alejen de la misma). En cuanto a los passwords, el directorio propio controlará según las políticas establecidas.

Adicionalmente se presentará un grupo de radio buttons con las leyendas Prestador y Afiliado, cada uno con un radio asociado.

Antes de guardar el nuevo objeto usuario, se mostrará una pantalla preview con los datos ingresados (menos el password) y se pedirá confirmación o modificación de los datos, volviendo al paso anterior. Los campos en caso de modificación deberán ser prellenados con los valores entrados en el paso anterior.

Una vez con todos los datos del usuario, se procede a crear un objeto usuario, impersonificándose en el usuario cn=admin_gestion,ou=Sede_Central,o=Miklolife. El usuario se creará en el contenedor ou=Externos,o=Miklolife, y se asignará al grupo cn=Prestadores,ou=Grupo_Gestion,o=Miklolife, o a cn=Afiliados,ou=Grupo_Gestion,o=Miklolife según se corresponda a un usuario de las prestadoras o a un afiliado de la Obra Social. Adicionalmente se deberá agregar a cn=autenticados,ou=Grupo_Gestion,o=Miklolife, que como es de saber, corresponde a los usuarios de esta aplicación.

Si la respuesta es 0 – Success se dará por finalizada la alta. Si la respuesta es distinta, como un 68 - entry already exists, 65 – object class violation, etc, se deberá volver al paso anterior y modificar los datos. No puede haber usuarios con el mismo username dentro de un mismo contenedor.

Modificación

En esta etapa, se selecciona un usuario ya existente, y se permitirá modificar todos los campos (menos el password) del usuario. Este esquema es exactamente idéntico al alta, con la salvedad de que los campos serán prellenados. El cambio de password será tratado aparte.

En el caso de estos usuarios, por ser externos, la modificación no contemplará cambios en las membresías ya que las funcionalidades serán las del grupo al que pertenecen.

Como en el alta, antes de guardar las modificaciones se presentará una pantalla a modo de preview con los datos ingresados, y un botón para confirmar junto a otro para volver atrás.

Luego, se procede a hacer un ldap modify y como siempre, chequear que la respuesta del server sea exitosa, o en caso contrario volver a la pantalla inicial.

Baja

Simplemente se los saca del grupo cn=autenticados,ou=Grupo_Gestion,o=Miklolife, y del grupo correspondiente si bien es un usuario de un prestador o un usuario afiliado de la Obra Social.

Cambios de Password

Usuarios Internos

No se les permitirá el cambio de password. Todos los usuarios que no pertenezcan a los grupos cn=Prestadores,ou=Grupo_Gestion,o=Miklolife o cn=Afiliados,ou=Grupo_Gestion,o=Miklolife deberán modificar sus password por medio de la terminal utilizando las técnicas conocidas de windows (ctrl+alt+del y luego Change Password). Esto cambiará el password del dominio, modificando también los passords LanManager / NT, con lo cual el usuario tendrá su nueva credencial para loguearse a todas las aplicaciones que utilicen al directorio como repositorio central de identidades.

Usuarios Externos

A los usuarios prestadores y afiliados se les permitirá cambiar su password en un módulo aparte. Todos los usuarios pertenecientes a estos grupos deben tener una funcionalidad de cambio de password y lo podrán hacer por las suyas. El mismo es cambiado a nivel LDAP y el atributo modificado es userPassword. El directorio tendrá una política establecida de modo que no se pueda volver a poner el password anterior como vigente.

En este módulo simplemente se mostraran dos cajas de texto, y el usuario deberá rellenarlas con lo nuevos passwords, por duplicado para corroborar que no haya habido errores de tipeo. Paso seguido se impersonifica en el usuario propio, y se modifica su password vía LDAP, controlando que el server LDAP retorne siempre un 0 – Success y de lo contrario volver al paso anterior.

Salida de la aplicación

Este evento no tiene ninguna actividad a nivel de directorio. Simplemente la aplicación vuelve a la pantalla de login pidiendo nuevas credenciales para tener acceso a la aplicación. De esta manera, el usuario no tiene acceso a ningún módulo si no se loguea a la aplicación (se vuelve al punto 7.2).

Ver usuarios

En este módulo, se presentará una lista seleccionable simple con todos los usuarios debajo de o=Miklolife que pertenezcan al grupo cn=autenticados,ou=Grupo_Gestion,o=Miklolife. Una vez elegido el usuario, se mostrarán todos los atributos relevantes del mismo (sólo los que tiene cargados en el entry del directorio), y las membresías a las cuales pertenece (en el caso de externos, se mostrará si es prestador o afiliado).

ABM de perfiles

En este apartado, se trata el agregado de nuevos perfiles a la aplicación. En este caso se debe acceder a la base relacional además del directorio jerárquico. Para estas operaciones la aplicación se debe impersonificar en el usuario cn=admin_gestion,ou=Sede_Central,o=Miklolife.

Alta

En el alta, se pedirá el nombre del nuevo perfil y se mostrará una lista de las funcionalidades existentes. El usuario administrador deberá seleccionar del combo múltiple aquellas funcionalidades que desea tenga el nuevo perfil. Previo a una pantalla de previsualización, se procederá a los siguientes dos pasos:

Crear un nuevo grupo, dentro del contenedor ou=Grupo_Gestion,o=Miklolife con cn=XXXX donde XXXX es el nombre del nuevo perfil.

En la tabla Perfil_Funcionalidad, se agrega por cada funcionalidad elegida, un nuevo par nombre_grupo / fid_funcionalidad (Ver DER anterior).

Modificación

Se presentará una pantalla similar al alta pero con aquellas funcionalidades elegidas preseleccionadas. El usuario deberá elegir las funcionalidades que quedarán para ese perfil, y acto seguido se procederá a modificar la tabla Perfil_Funcionalidad modificando, eliminando y agregando registros de pares nombre_grupo / fid_funcionalidad según se hayan seleccionado en el caso anterior.

Baja

Se presentarán una lista de perfiles (exceptuando los perfiles por default que se describieron secciones atrás). El usuario seleccionará un perfil y se le advertirá que se está por eliminar el mismo. Una vez realizado esto, y confirmado por el usuario, se procederá a hacer un ldap delete del grupo elegido, y se eliminará de la tabla Perfil_Funcionalidad todos los registros donde nombre_grupo sea igual al cn del grupo que se ha eliminado.

http://developer.gnome.org/projects/gup/hig/

http://www.gtk.org

14.7.6. Salida de la aplicación

Página 274

Técnicas de Diseño (75.10)

CCLXXIV

1.3.19.3. Diagrama de secuencia (modificación)

2005-06-25T17:35:35