UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOSFACULTAD DE INGENIERÍA DE SISTEMAS E INFORMÁTICA
UNIDAD DE POST GRADOMAESTRIA: Ingeniería de Sistemas e Informática
PROYECTO DE INVESTIGACION
Titulo Tentativo
APLICACIÓN DE UN SISTEMA DE INFORMACIÓN PARA EL MONITOREO Y
TOMA DE DECISIONES EN EL SISTEMA DE AUDITORIA DE SEGUROS DE
ESSALUD
Autor : Weiss Najarro Carlos Profesor: Dr. Armando Zárate
Curso : Tesis 2
LIMA – PERU
2006
RESUMEN
1) TITULOAplicación de un Sistema de Información Variable Independiente causa PARAVariable intermedia (direcciona tesis)
monitoreo y toma de decisiones en el Sistema de Auditoria de Seguros de EsSaludVariable dependiente efecto
2) PROBLEMÁTICA
P: No se realiza una monitorización en el Sistema de Auditoría de Seguros.
Problemas Específicosa) No existe un sistema apropiado de registro de actividades de
Auditoría de Seguros.b) Existen sólo registros físicos que dificultan la consolidación de la
información.c) No se puede realizar un análisis adecuado porque la información
está desorganizada y es de difícil acceso.d) Inadecuada monitorización del sistema de auditoría de seguros en
todas las sedes asistenciales de EsSalud.e) Inadecuada toma de decisiones por falta de un sistema que
consolide y analice la información del sistema de Auditoría de Seguros.
3) OBJETIVOS
a) Que exista un sistema apropiado de registro de actividades de Auditoría de Seguros.
b) Que los registros no sean sólo físicos sino sobretodo magnéticos para facilitar la consolidación de la información.
c) Que se puede realizar rápidamente un análisis adecuado tomando como base la información organizada y es de fácil acceso, por el sistema de información.
d) Mejorar la monitorización del sistema de auditoría de seguros en todas las sedes asistenciales de EsSalud.
e) Mejorar la toma de decisiones por la utilización adecuada del sistema de información que consolidará toda la información y facilitará su análisis.
4) HIPÓTESIS ESPECÍFICAS
a) Se registrarán todas las actividades de Auditoría de seguros en un sistema de información con acceso amigable.
b) Se registrarán todas las observaciones obtenidas durante el proceso de Auditoría de Seguros en cada una de las sedes asistenciales.
c) SE desarrollarán automáticamente indicadores, que faciliten el análisis de la información obtenida y del proceso de auditoría realizado.
d) Se optimizará la toma de decisiones en base a un análisis integral, adecuado y eficiente, gracias al uso de indicadores desarrollados.
5) VARIABLES:
VI : Aplicaciones de S.I.V.Inter : Diseño de una AplicacionesV. D : Monitoreo y toma de decisiones en el sistema de Auditoria de
Seguros de EsSalud
6) MODELO DE INVESTIGACIÓN:
Modelo Investigación = Variable Interdependiente.Modelo Investigación = Diseño de una Aplicaciones de S.I.
7) DISCUSIÓN (RESULTADO):
Con el Diseño de una Aplicaciones de un Sistema de Información se monitoreara y se tomara decisiones en el sistema de Auditoria de seguros de EsSalud.
2. ESTRUCTURA REFERECIAL
2.1. MARCO HISTORICO2.1.1 HISTORIA DE LOS SISTEMAS DE INFORMACIÓN
2.1.2. HISTORIA SEGURO SOCIAL DE SALUD
2.1.2.1 Servicios de salud
2.1.2.2 Los Sistemas de Información y su impacto en los Servicios de
Salud
2.1.2.3 Las Tecnologias de Información
2.1.3 DESARROLLO DE LAS TI EN SALUD.
2.1.3.1 El valor de la información en salud
2.1.3.2 Situación de las TI en salud.
2.1.4 AVANCES DE LOS SISTEMAS DE INFORMACIÓN PARA LA TOMA DE DECISIONES EN EL CAMPO DE LA SALUD.
2.2. MARCO TEORICO2.2.1 DEFINICIÓN DE SISTEMA DE INFORMACIÓN
2.2.2 CARACTERÍSTICAS DE UN SISTEMAS DE INFORMACIÓN
2.2.3 AUDITORIA DE SEGUROS DE ESSALUD
2.2.4.DEFINICIÓN DE ANALISIS Y DISEÑO DE UN SISTEMA DE
INFORMACIÓN
2.2.4.1 Rational Unified Process.
2.2.5 DEFINICIÓN DE TOMA DE DECISIONES
2.2.6. CLASIFICACIÓN DE LOS SISTEMAS DE INFORMACIÓN PARA LA TOMA
DE DECISIONES
2.2.6.1. Decision Support Systems (DSS)
2.2.6.2. Executive Information Systems (EIS)
2.2.6.3.- Group Decision Support Systems (GDSS)
2.2.6.4. Sistemas Expertos de Soporte para la Toma de Decisiones
(EDSS)
2.2.7.- SISTEMAS DE DATAWAREHOUSING
2.2.7.1 Análisis multidimensional OLAP
2.2.7.2.- Herramientas datamining
2.3 MARCO CONCEPTUAL
2.4 MARCO TECNOLOGICO
2.4.1 Objetivos del Sistema de Auditoria de Seguros.2.4.2 Rational Rose
2.5 MARCO FILOSÓFICO
2.5.1 Concepto de Holismo.
2.6 MARCO LEGAL
APLICACIÓN DE UN SISTEMA DE INFORMACIÓN PARA EL MONITOREO Y
TOMA DE DECISIONES EN EL SISTEMA DE AUDITORIA DE SEGUROS DE
ESSALUD
2. ESTRUCTURA REFERECIAL
2.1. MARCO HISTORICO
2.1.1 HISTORIA DE LOS SISTEMAS DE INFORMACIÓN
El concepto de sistema surgió de la idea de que las ciencias tenga una relación entre todas las ciencias como era la de economía, filosofía. Para ello Bertalanffy dio la idea de que tenga una relación Bertalanffy “Es el estudio de las relaciones entre las partes de un ente integrado (abstracto o concreto) y de su comportamiento como un todo respecto a su entorno”.
luego surgen nuevos conceptos como sistemas abiertos, sistemas cerrados con el cual no existía ninguna interconexión con el entorno. y es así surgió el pensamiento sistémico.
Luego apareció una nueva ideología que era la equifinidad según el investigador o científico dice:
Bertalanffy “permite explicar como bajo diversas condiciones iniciales es posible llegar al mismo estado final”.A partir del trabajo de bertalanffy surge un conjunto de estudios y contribuciones de sus discípulos como Anato Rapoport en matemática y kenneth boulding en economía.Luego surgieron teorías interdisciplinarias que iban mas allá de las ciencias clásicas, la idea central era la posibilidad de que las diversas disciplinas compartan conocimientos entre si, en la búsqueda de una sola ciencia expresada a través de la teoría general de sistemas (TGS).
El cual contenía Idealismo, Dualismo, Materialismo, Estructuralismo, Existencialismo o fenomelogía, Luego la teoría no se presenta en contra de los grandes sistemas de pensamiento como:
Es perspectiva el hipotético mundo real vivo desde diversos ángulos, muestra aspectos diversos que se explican por la hipótesis y los instrumentos utilizados por el investigador.
Es integradora puesto que comprende como complementarios aspectos que tradicionalmente se han considerado como opuesto. (dicotomía quiere decir si es verdadero o falso).Es crítica dispuesta a la rectificación o modificación de los principios que utilice, siempre que nuevos conocimientos científicos induzcan a ello.
Favorece la libertad del investigador y del docente, al utilizar que estos pueden utilizar sin prejuicios cualquier ciencia o metodología, en cualquier combinación, siempre que los principios obedezcan a una lógica coherente y los resultados sean adecuados. A la que se denominaron Abierto y antidogmático.
A la Visión simétrica, concebir los objetos y los seres como todo. Es un contexto de propiedades y relaciones integradas. Es preciso diferenciar: todos, agregados se le llamo Totalidad.
A el conjunto de elementos organizados e interactivos. Aparecen cualidades emergentes que no poseían las partes no estaban implícitas en estas. Cuando el todo se construye mediante la interrelación de sus elementos, las partes disociadas se transforman en componente.
Los elementos o partes del todo no participan en el conjunto por sus cualidades perceptibles (peso, tamaño, etc), sino por su lugar, conexiones y funciones en el espacio – tiempo. se le llamo el todo
A el “todo” natural supone un sistema cuyos elementos se hallan en reciproca relación física. En los subsistemas de los organismos de los animales (Sistemas nervioso, etc) carecen de sentido tanto en la practica como en la teoría así sus partes se consideran independientes de las demás. Se le dio el nombre de Totalidad y sus partes.
A todo ello surgió una idea un conjunto de elementos que se interesan y cumplen un objetivo es un sistema.
El termino proviene de las matemáticas “Significa similitud formal de las ecuaciones, estructuras geométricas o cualquier clase de elementos”. (analiza sus partes para conocerlas mejor). Se le llamo Isomorfismo Bertalanffy “Extiende a estructuras, algoritmos, relaciones, funciones y procesos cuya semejanza permite transferirlos de una clase de sistemas a otra u otras”.(economía, filosofía). Operan en una variedad de campos.
Hay principios universales (gravitación universal, relación totalidad / parte, organización, comunicación-información) que puede aplicarse a campos muy distintos.
La ley de Malthus que cree que todo sistema que crece con mayor rapidez que los recursos disponibles. (exponencial simétrico, recursos asociado).
Los fenómenos de centralización – descentralización (tiene ventajas y desventajas)o aparición de jerarquías.
Los isomorfismos pueden ser generales o limitarse a uno o varios aspectos de los sistemas que comparan, ya sean naturales, conceptuales, artificiales.No confundir isomorfismo con analogía.
En todo sistema cerrado el estado final de los sistemas cerrados esta determinado de manera inequívoca por las condiciones iniciales, de acuerdo con la física clásica. (busca salida o producción) Bertalanffy “En los sistemas abiertos, el estado final puede alcanzarse de distintas maneras a partir de las condiciones iniciales diferentes”. Se le llamo Equifinalidad.
Fenómeno en el cual el ensamblaje de las partes es mayor que la suma de los efectos propios de cada sistema ejercidos en forma independiente. (participan políticas y se unen). Toda actividad colectiva que produce resultados cualitativos positivos es una actividad sinergia, ya que no podría obtenerse igual resultado mediante la suma de los esfuerzos aislados.(antiergia). Se le llamo Sinergia.
El grado de desorden es mensurable, la única forma de vencer a la entropía emergente en un sistema cerrado es mediante el concepto de sistemas abierto, que permite el ingreso de la entropía negativa para establecer un equilibrio en la estructura de sistema. se le llamo Entropía
Nos hace a percibirnos de la diferencia entre nuestros conceptos y unos sistemas postulados cuya estructura y relaciones pueden definirse de muy diversas formas, opuestas o complementarias. Se refiere al Enfoque sistémico.
Desde el punto analista se examina la composición interna como las funciones que desempeña y sus relaciones con el entorno global y con los entornos específicos que interactúa. Para los sistemas concretos se debe delimitar que es lo que entendemos del propio sistema (jerarquía que se encuentra los demás sistemas con las que se relaciona, el ambiente o el entorno) luego se sitúan en el espacio-tiempo. se llamo Organización de los sistemas complejos.
Cualquier sistema en el cual se proyecta la atención del investigador, depende de los objetivo de la actividad o de los intereses del usuario. Puede ser individual o colectivo. Y esta compuesto de n subsistemas. Se le llamo Sistema de referencia.
Al que engloba a el sistema de referencia, el cual el sistema referencial depende mucho de el. Se le denomino Suprasistema. Depende jerárquicamente del sistema de referencia no es lo mismo que un subsistema porque los sistemas pueden estar en un mismo nivel jerárquico no como un subsistema. Se le denomino Infrasistema. Al sistema jerárquica y estructura análoga al sistema de referencia. Son sistemas que se asemejan estructuras, normas o comportamientos análogos a los sistema de referencia. Se le llamo Isosistemas.
Al sistema de nivel análogo del sistema de referencia pero pertenecen a otro conjunto o clase se le denomino Heterosistema.Conjuntos funcionales sistémicos susceptibles de ser aislados conceptualmente se le llamo Componentes.
la subdivisión de los componentes, los componentes dependen de los subsistemas. Se le llamo Subsistemas.
la subdivisión de los subsistemas, los subsistema dependen de los elementos. Son los subsistemas más simple. Se le denomino Elementos.
El sistema de referencia funciona con la interacción de los componentes, subsistemas y elementos. Un análisis profundo podría concebir categorías intermedias como conjunto de componentes.
Otra perspectiva era La perspectiva jerárquica universal alcanza el limite absoluto del universo algo que engloba a un sistema. Visto exteriormente es parte de un todo mas amplio. Visto interiormente es un todo compuesto por partes. Sistemas creados poseen estados estables, mediante circuitos cibernéticos de retroalimentación, retroacción y retroinformacion (feed-back), y mecanismos adaptativos (adecuados para el cambio). Crecen cuantitativamente y se desarrollan cualitativamente, tendiendo hacia niveles superiores de organización dotados de mayor diferenciación y complejidad. Pueden lograr sus objetivos con insumos diversos y por diferentes procedimientos. Están sometidos a riesgos de degeneración y desaparición.
La Síntesis de las relaciones que traiga consigo la Línea jerárquica vertical refiriéndose un sistema de referencia se encuentra en con un suprasistema. La Línea analógica vertical refiriéndose a un sistema de referencia se encuentra con un isosistema. El sistema de referencia se encuentra dentro de una esfera de relaciones , algunos de los cuales aparecen como relaciones verticales, relaciones horizontales con un entorno próximo.
Los Sistemas cerrados y abiertos se le denominaron un sistema cerrado esta aislado de su entorno, no tiene relación con ningún objeto exterior. un sistema abierto interactúa con su entorno, si se relaciona con un sistema de estructura análoga o jerárquica, se mantiene en intercambio de información. un sistema cerrado- abierto es cuando su comportamiento puede ser un tiempo abierto y luego se puede permutar a cerrado en función de sus factores del entorno.
Los Limites de la organización son Todo sistema tiene una zona limite o interfase que lo separa del entorno o de otros sistemas. Los limites pueden considerarse estáticos cuando se definen sin tener en cuenta sus cambios temporales. Así suelen aparecer a la observación directa o a su construcción teórica.Los limites pueden considerarse como dinámicos o dialectos cuando los concebimos en función del tiempo y son estáticos si no hacen ninguna funcionalidad.
2.1.2. HISTORIA SEGURO SOCIAL DE SALUD
2.1.2.1 Servicios de salud1
Mediante Ley 27056 “Ley de creación del Seguro Social de Salud” se crea el Seguro Social de Salud, el cual establece un organismo público con autonomía técnica, administrativa, económica, financiera, presupuestaria y contable, encargado de administrar los programas de la seguridad social en salud del país.
La Ley 26790 “Ley de Modernización de la Seguridad Social en Salud“, determinó cambios importantes en la seguridad social. Dicha norma crea las Entidades Prestadoras de Servicios de Salud (EPS). Las EPS, de acuerdo a ley son consideradas complementarias a EsSalud, aunque en la práctica actúan más en calidad de gestoras de un esquema selectivo dirigido a aquellas empresas cuyo trabajadores eligen por mayoría recibir la parte de la “capa simple” de las prestaciones integrales de salud mediante EPS en vez de recibirlas por medio de EsSalud; inclusive han generado un aporte “voluntario” por medio del cual, las EPS, brindan también servicios de la denominada “capa compleja” que sólo debería cubrirlas EsSalud. Asimismo el Seguro Complementario de Trabajo de Riesgo (SCTR) que brinda cobertura por accidente de trabajo y enfermedad profesional a los trabajadores que desarrollan actividades calificadas como de “alto riesgo”.
El Seguro Regular, es un seguro obligatorio, que constituye la modalidad de aseguramiento con mayor número de afiliados. Los tipos de trabajadores se encuentran subdivididos en siete modalidades, seis de carácter obligatorio, y una de carácter complementario, pero para asegurados obligatorios. Las seis de carácter obligatorio corresponden a las de: a) Empleado, b) Obrero, c)Pescador y Procesador Artesanal Independiente, d) Trabajador del Hogar (TH), e)Construcción civil y f) Pensionistas. La modalidad de carácter complementario, corresponde al aseguramiento mediante las Entidades Prestadoras de Servicios de Salud (EPS). Las EPS brindan prestaciones de servicios de salud a nivel de “Capa Simple”, mientras que el Seguro Regular de EsSalud comprende la atención integral, en otras palabras “Capa simple” y “Capa Compleja”. Debido a ello, las personas que por votación en sus empresas, deciden afiliarse a una EPS, reciben atención de capa compleja únicamente por medio de EsSalud. De ahí se consideraría el carácter complementario de este seguro, pero en la práctica, utilizando el argumento de la continuidad de la atención, las EPS, han determinado un aporte “voluntario”, por el cual tienen también derecho a atenciones de “capa compleja” a través de estas entidades. Por lo tanto, dentro del sistema de seguridad social, son dos los tipos de entidades gestoras las que comparten el mercado: EsSalud (de carácter público) y las EPS (de carácter privado). Las prestaciones de salud son de: prevención y promoción de la salud, recuperación de la salud, bienestar y promoción social y rehabilitación de la salud. Comprende al asegurado titular y a su derechohabientes (cónyuge o concubino
1 Manual de Procedimiento de Auditoria.
(a), hijos (as) menores, hijos(as) mayores de edad incapacitados y madres gestantes de hijos extramatrimoniales).
Los Seguros potestativos están dirigidos fundamentalmente a la afiliación de los trabajadores independientes y sectores menos favorecidos de la población económicamente activa. Existen actualmente los seguros potestativos: a) EsSalud Independiente, b) EsSalud Personal y Familiar, y c) Seguro Potestativo Único. Comprende al asegurado titular (sin limite de edad para EsSalud Independiente, hasta 65 años para EsSalud Familiar y Personal), y sus derechohabientes (cónyuges o concubino (a), hijos (as) menores de edad, e hijos(as) mayores de edad incapacitados); pero ya no hay afiliación, estos asegurados irán migrando al Plan Protección Vital del nuevo Seguro Potestativo. Junto con este plan, se ha creado también el Plan Protección total.
El Seguro Complementario de Trabajo de Riesgo (SCTR), creado mediante la citada Ley 26790 ( de 1997) “Ley de Modernización de la Seguridad Social en Salud”, brinda cobertura por accidente de trabajo y enfermedad profesional, y además, pensión por invalidez y sepelio, a los afiliados regulares del Seguro Social de Salud, que laboran en ocupaciones tipificadas como de alto riesgo. La cobertura de prestaciones de salud, se puede obtener tanto a través de EsSalud, como por medio de las EPS, y el financiamiento es de tipo privado a través de aportes a EsSalud o a una Compañía de Seguros o una EPS. La cobertura por accidente laboral abarca toda lesión orgánica o perturbación funcional causada en el centro laboral por motivo de trabajo, por acción imprevista, fortuita, u ocasional de una fuerza externa, repentina y violenta que obra súbitamente sobre el trabajador o debido al esfuerzo del mismo. La cobertura por enfermedad profesional, considera todo estado patológico permanente o temporal, que sobreviene al trabajo como consecuencia directa de la clase de trabajo que desempeña o del medio en que se ha visto obligado a trabajar. Las prestaciones de salud que se brindan por medio del SCTR, procuran el cuidado integral de los trabajadores que desarrollan actividades de riesgo, y presta asistencia preventiva o promocional en salud ocupacional tanto al trabajador, como al empleador. Este seguro comprende sólo al titular.
El Seguro de Salud Agrario, constituye la segunda modalidad de aseguramiento en cuanto a importancia en número de afiliación comparado con el Seguro Regular. Tiene dos modalidades, una de carácter obligatorio para los trabajadores agrarios dependientes y la otra no obligatoria para los trabajadores agrarios independientes. En los dos casos, solo considera a los trabajadores que desarrollan actividades de cultivo, de crianza, de agroindustria, de avicultura y acuícola, y comprende al asegurado titular y a sus derechohabientes (cónyuge o concubino (a), hijos (as) menores, hijos(as) mayores de edad incapacitados y madres gestantes de hijos extramatrimonial). Para el caso del seguro dependiente, los trabajadores deben cumplir una jornada mínima de 4 horas diarias, y no se encuentra comprendido el personal administrativo que labore en la provincia de Lima y en la provincia Constitucional del Callao. Las prestaciones de salud son de:
prevención y promoción de la salud, recuperación de la salud, bienestar y promoción social y rehabilitación de la salud.
Los Regímenes Especiales, se han trasladado al Seguro Potestativo.
2.1.2.2. Los Sistemas de Información y su impacto en los Servicios de Salud
La evaluación de tecnologías para la salud (ETS) puede definirse como la investigación integral de las consecuencias clínicas, económicas y sociales del empleo de las tecnologías en salud y sus efectos directos e indirectos, deseados y no deseados, sobre las personas y la sociedad. Esta evaluación consiste en la apreciación objetiva del valor médico, social, económico y ético que posee una tecnología específica en un lugar y momento determinado.2
Durante los últimos quince años el interés por las ETS ha ido aumentando en los países desarrollados por el efecto de una o varias de las siguientes razones:
Un conocimiento cada vez más preciso de la variabilidad de la práctica clínica, causada por diversas razones (diversidad clínico-epidemiológica, incertidumbre, aceptabilidad, accesibilidad, diferencias en el entrenamiento y/o en los incentivos, etc.) que pueden inducir pautas de conducta poco uniformes y posiblemente inapropiadas en ciertos casos, por parte de los profesionales ( por ejemplo la tasa de uso de un procedimiento quirúrgico o farmacológico en dos provincias de un mismo país la cual oscila entre 28 y 163 por 100,000 habitantes, siendo idénticos el modelo de organización de los servicios y la formación de los profesionales) La constatación de los elevados niveles de incertidumbre sobre el efecto real de muchas de las intervenciones diagnósticas y terapéuticas La rapidez de la introducción de nuevas tecnologías y la presión de los intereses tan fuerte de su incorporación.
El carácter poco sustantivo y a menudo complementario de muchas tecnologíasnuevas respecto a las antiguas.3
Las ETS consideran básicamente: seguridad, eficacia, efectividad, utilidad, impacto económico, consecuencias organizativas, implicaciones éticas e impacto social. El método más generalmente empleado para evaluar una tecnología es la consolidación de la mejor evidencia disponible. Para ello se precisa, recolectar, analizar y sintetizar información de la mejor calidad, la información puede ser tanto primaria como secundaria.
2La promoción, la evaluación y la gestión de la tecnología para la salud. Hacia un enfoque virtual e integral, UTESA, Excelencia en tecnología para la salud, Funsalud, 2002.
3 El desarrollo de la evaluación de las tecnologías en salud en América Latina y el Caribe, Programa de organizacióny gestión de sistemas y servicios de salud, Organización Panamericana de la Salud, 2000.
Entre la información primaria destaca la proporcionada por las estadísticas demográficas y epidemiológicas, los sistemas de vigilancia y alerta, los registros de las altas hospitalarias y de ciertas enfermedades o condiciones clínicas. Entre
la información secundaria destaca la proporcionada por estudios observacionales de tipo descriptivo o analítico, así como la proporcionada por estudios experimentales particularmente los ensayos clínicos controlados.3
Una tecnología médica puede ser evaluada en cualquier fase de su ciclo de vida:
Experimental.- priman los estudios referidos a seguridad y eficacia en un sentido estricto. Sus resultados son condición necesaria para pasar a las fases posteriores.
De implantación inicial.- importa conocer la efectividad, la utilidad clínica y los impactos económicos y organizativo previsibles, es un ámbito no experimental sino de ensayo clínico, deben de estar rigurosamente establecidas las condiciones desde los puntos de vista científico, ético, legal y administrativo.
De generalización.- proporciona información sobre cuanto tiempo ha de seguir siendo utilizada dicha tecnología.
Declive.- Se trata de evaluar si ha llegado ya el momento en que la tecnología encuestión es sustituible con ventaja por una o varias tecnologías nuevas.En el campo de la salud los criterios más utilizados para las ETS son:
1. - Seguridad de la tecnología médica.- Valoración del daño inevitable inducido por la aplicación de una tecnología médica. El efecto positivo por el uso de la tecnología debe superar de manera evidente el riesgo potencial de su aplicación.
2. - Eficacia de la tecnología médica.- Este criterio se refiere a la probabilidad de que un individuo se beneficie por el uso de una tecnología en la resolución de un problema de salud, bajo condiciones ideales de aplicación.
3. - Efectividad de una tecnología médica.- Es la probabilidad de que un individuo obtenga un beneficio como consecuencia de la aplicación de la tecnología médica.
De esta manera la evaluación de tecnología se convierte en una herramienta para los tomadores de decisiones y nos ayuda a aprovechar la tecnología médica de una mejor manera, obteniendo beneficios económicos y sociales.
Una vez conociendo la situación actual del sistema de salud, los avances Tecnológicos en materia de salud y la importancia del uso de las ETS,
podemos comprender la importancia que juega la información en los sistemas de salud y con ella las tecnologías de información.
2.1.2.3 Las Tecnologias de Información
La información es el activo más importante de las organizaciones puesto que representa todo el conocimiento que tiene de su mercado. Las características que debe cumplir la información son:
Exactitud: información precisa y libre de errores.
Completitud: La información debe tener todos aquellos hechos que pudieran ser importantes.
Economicidad: el coste en que se debe incurrir para obtener la información debe sermenor que el beneficio proporcionado por ésta a la organización.
Confianza: Garantizar tanto la calida de los datos utilizados como las fuentes deinformación.
Relevancia: La información debe ser útil para la toma de decisiones.
Nivel de detalle: la información debe cumplir con el nivel de detalle indicado a la decisión que se destina y ser presentada de manera adecuada para su fácil manipulación.
Oportunidad: Se debe entregar a la persona indicada y en el tiempo indicado.
Verificabilidad: la información deberá ser contrastada y comprobado en todomomento.
A su vez para que la información sea útil debe tener:
Vigencia: En función al tiempo del tema de nuestro interés, asignar un periodo
Relevancia: Identificar quienes proporcionan la información y de que fuente se obtiene
Pertinencia: Mayor enfoque a nuestro contextoVisibilidad: Identificar si la fuente corresponde al tema tratado
Impacto: Observar el efecto que se tiene sobre el tema La evolución que han tenido las TI en salud durante varios años demuestran la importancia de la información para este campo.
2.1.3 DESARROLLO DE LAS TI EN SALUD.
2.1.3.1 El valor de la información en salud
Actualmente los sistemas de salud dependen altamente de los sistemas de información para una gran variedad de decisiones administrativas y clínicas. Los objetivo que persiguen los sistemas de información en salud están basados en enriquecer las metas y expectativas del sistema de salud.
Los sistemas de información en salud han evolucionado a través de los años, la siguiente figura representa esta evolución.
Figura 1. - Evolución de las tecnologías de información en Salud4
4 Information technology in the Health Sector of Latin America and the Caribbean. Challenges and opportunities forthe international technical cooperation, Pan American Health Organization, Pan American Sanitary Bureau, RegionalOffice of the World Health Organization. Division of Health Systems and Services Development, October 2001.
2.1.3.2 Situación de las TI en salud.
Todo proyecto de tecnología de información y comunicación de la salud debe procurar la obtención de mejoras de la calidad en los procesos de atención sanitaria, una mayor eficacia y eficiencia de las operaciones y la atención individual y certeza de rendimiento de la inversión.5
En la actualidad las tecnologías de información en salud, se han enfocado al desarrollo de sistemas de gestión que permiten a los establecimientos de atención médica controlar los recursos de su unidad, así como el control de sus pacientes, en este tipo de sistema principalmente podemos encontrar información relacionada con los siguientes temas:
Tabla 1. Información más común en los sistemas de salud6
5 Tarjetas de Datos Sanitarios con circuito Integrado (tarjetas inteligentes) Manual para los profesionales de la Salud, Área de tecnología y prestación de servicios de salud, Organización Panamericana de la Salud, 20036 Setting Up Healthcare Services Information Systems. A Guide for Requirement Analysis, Application Specification,and Procurement, Essential Drugs and Technology Program. Division of Health Systems and Services Development, PanAmerican Health Organization. World Health Organization, July 1999
Actualmente existe un gran desarrollo de modelos utilizados en los sistemas de información hospitalaria que permiten una comunicación entre los diferentes servicios hospitalarios. Este tipo de desarrollos utilizan información que puede ser de diferente tipo, clasificándose como:
Tabla 2. Clasificación de datos en los sistemas de información en salud 6
Una reciente inspección de la infraestructura de información en salud reveló la existencia de un gran número de problemas relacionados con la colección de datos, utilización de la información, diseminación de la información, capacitación y recurso humano. Todo esto lleva a que los sistemas de información en salud no sean una herramienta útil a los tomadores de decisiones.
2.1.4 AVANCES DE LOS SISTEMAS DE INFORMACIÓN PARA TOMA DE DECISIONES EN EL CAMPO DE LA SALUD.
El gran desarrollo de las tecnologías de información a impactado en las organizaciones, lo cual ha sido aprovechado por diferentes empresas que se han dedicado al desarrollo de software y hardware para modelos de toma de decisiones, actualmente en el mercado de los sistemas computacionales, podemos encontrar diferentes compañías que ofrecen desarrollos para evaluaciones costo – efectividad a través de la tecnología de software. Este tipo de empresas están enfocadas al desarrollo de sistemas con especificaciones muy particulares de sus clientes, el personal de estas empresas está conformado principalmente por ingenieros en sistemas y afines, quienes tienen todas las bases de conocimiento para el desarrollo de los sistemas computacionales, pero no conocen a fondo la problemática de los sistemas de salud, así como de otros campos de aplicación, por lo anterior este trabajo representa una innovación, ya
que actualmente en el mercado no se cuenta con un sistema de control de auditoria.
Durante el proceso de búsqueda de información, encontré, diversos desarrollos de modelos para sistemas de toma de decisiones entre los que se pueden mencionar, los sistemas de soporte expertos para la creación de nuevos productos, el desarrollo de sistemas para la formulación y planeación estratégica, sistemas que emplean técnicas de razonamiento causal, análisis y desarrollo para modelos económicos, propuestas tecnológicas para administrar el desempeño de los sistemas de decisión, sistemas para toma de decisiones en la administración de desastres y la creación de modelos que incorporan diferentes herramientas para el manejo de variables con comportamiento no uniforme y con accesos a diferentes bases de datos.
Dentro del campo de la salud, actualmente existen sistemas con modelos de toma de decisiones enfocados a evaluar el uso de los medicamentos en los pacientes, estos sistemas utilizan información de los efectos causados en los pacientes, sobre la base de las características de los medicamentos, tipos de dosis, característica del paciente y método utilizado, con ello obtienen la evaluación de los efectos sobre los pacientes para un determinado medicamento. También hay sistemas que proporcionan información de los procesos clínicos para asistir a un paciente, generan alertas, información para cuidados externos en determinados procedimientos, recomendaciones y generacion de opiniones.
Estos sistemas son herramientas para los médicos quienes son los tomadores de decisiones, ya que los asisten en sus decisiones médicas, también encontré sistemas de soporte de decisiones para administradores de marketing de los servicios de salud . En el campo de la medicina, no solo se utiliza los sistemas de información, para mejorar sus procesos en toma de decisiones, si no que los sistemas de información utilizan a la medicina para generar modelos de toma de decisiones, un ejemplo de ello es la utilización del proceso que lleva a cabo el sistema nervioso central para cumplir su función, ya que existen sistemas desarrollados bajo este modelo, principalmente en aplicaciones de decisiones demercado, modelado de decisiones, estimaciones de mercado, modelos econométricos y simulaciónes.
Otros avances, son los modelos de toma de decisiones tales como el del Dr. Bijan Fazlollahi, quien es profesor del departamento de sistemas computacionales y negocios internacionales, en el Colegio de negocios Robinson en la Universidad del estado de Georgia, Atlanta, USA y Rustam Vahidov, quien es profesor de administración de sistemas de información en el departamento de ciencias de decisión en la Universidad de Montreal, Canada, ellos crearon un método para
generación de alternativas utilizando sistemas de toma de decisiones. Este trabajo utiliza un algoritmo genético que se basa en la relación problema – solución/toma de decisión, que considera la separación de la generación de alternativas desde la evaluación y la diseminación del conocimiento, este método reduce el tiempo que el investigador tarda en encontrar las diferentes alternativas a un problema determinado y provee un alto grado de colaboración hombre-maquina.Otro elemento importante en los sistemas de toma de decisiones son los accesos a la información, actualmente existen en on-line una gran variedad de bases de datos, las cuales pueden ser utilizadas en las organizaciones principalmente con enfoque administrativo con propósito de aplicar estrategias de administración en las organizaciones, lo que genera inteligencia competitiva entre ellas.En conclusión los avances sobre este tema se enfocan no solo a la generación de modelos, si no al tipo de herramientas y opciones de aplicación de los modelos ya existentes, así como a los accesos a información, evaluación de los modelos ya creados e incorporación de datos.
Actualmente está presenta la necesidad de desarrollos enfocados al enriquecimiento del análisis de los modelos. Y sin duda en los siguientes años se producirán nuevos avances sobre este tema, muestra de ello, son el gran número de espacios científicos en los cuales se dan a conocer los adelantos en esta materia, en todo el mundo, tal es el caso de la Conferencia Internacional de la Ciencia de los Sistemas, Congreso MedInfo, Congreso Informédica, entre muchos otros eventos.
2.2. MARCO TEORICO
2.2.1 DEFINICIÓN DE SISTEMA DE INFORMACIÓN7
“Un sistema de información puede definirse técnicamente como un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones, el control, el análisis y visión en una empresa. Además para apoyar a la toma de decisiones, la coordinación y el control, los sistemas de información pueden también ayudar a los administradores y al personal a analizar problemas, y visualizar cuestiones complejas y crear nuevos productos.
Los Sistemas de Información pueden contener datos acerca de personas, lugares, y cosas importantes dentro de la institución y el entorno que lo rodea.
Tres Actividades de un sistema de información producen la información que la empresa requiere para la toma de decisiones, para el control de las operaciones, el análisis de los problemas y la creación de nuevos productos y servicios. Estas actividades son las de Alimentación, Procesamiento y producto. La Alimentación o entrada captura la recolección de datos primarios dentro de la organización o del entorno que lo rodea para procesarlos en un sistema de información. El Procesamiento transforma estos datos primos a algo que tenga mas sentido; es decir, viene a ser la conversión del insumo de forma que sea mas comprensible para las persona. El Producto o la salida transfiere o disminuye la información procesada a las personas o actividades donde deben ser empleado. Los Sistemas de Información también requieren la retroalimentación que es el producto regresado a personas indicadas de la empresa para ayudarles a evaluar que el insumo sea el correcto o corregir la etapa de alimentación”.
La teoría planteada se basa en el sistema estructurado ya que habla de ingreso de datos, un proceso, una salida y un feedback, en cambio en una orientación a objetos un sistema de información sería el ingreso de datos asignados hacia un objeto el cual interactúa con otros objetos y logran los objetivos de la empresa y el feedback sería en iteraciones de las fases del RUP.
7 Moncada Ochoa, “sistema de información gerencial”, 2001, pagina 8
Figura 2. – Sistema de Información en la metodología R.U.P8.
2.2.2 CARACTERÍSTICAS DE UN SISTEMAS DE INFORMACIÓN9
“Sus principales características son:
Suelen lograrse ahorros significativos de mano de obra.
Los sistemas de información son los primeros en implantarse en las organizaciones.
Son intensivos en entradas y salidas de información; sus cálculos y procesos suelen ser simples y poco sofisticados, requieren mucho manejo de datos para poder realizar sus operaciones y como resultado generan también grandes volúmenes de información.
Tiene la propiedad de ser recolectores de información.
8 Copyright IBM Corp. 1987-2004 Rational Unified Process® Version 2003.06.139 www.wanadoo.com
Son adaptables de aplicación que se encuentran en el mercado.
Ejemplos: facturación, nóminas, cuentas por cobrar, cuentas por pagar, contabilidad general.”
Para complementar las características de los sistemas de información se deben también tener en cuenta que un sistema de información también brinda información a las organización de forma eficiente y rápida para la toma de decisiones también minimiza recursos económicos, humanos, etc.
2.2.3 AUDITORIA DE SEGUROS DE ESSALUD
Siendo Essalud una institución prestadora de servicios de salud, existen dos aspectos fundamentales que tienen que ver con su Sistema de Gestión en lo que se refiere a la parte de prestaciones asistenciales: uno, el relacionado con la prestación misma, en el sentido de brindar a sus asegurados una atención médica eficiente, eficaz, oportuna y de calidad; el otro, en salvaguarda de los derechos de sus asegurados, es la sostenibilidad del sistema.
Para lograr la sostenibilidad del sistema existen tres elementos importantes:
Que los aportes de los asegurados sean suficientes para cubrir la siniestralidad que ellos generen.
Que el número de aportantes sea cada vez mayor con el fin de diluir por distribución, el riesgo.
Que exista un sistema de control tal que evite que estos fondos sean utilizados inadecuadamente.
El tercer punto, que tiene que ver con la presente trabajo, es el elemento primordial para asegurar que todos los esfuerzos que se realicen, vayan encaminados al cumplimiento de los objetivos institucionales.
En un Sistema de Control, existen también dos áreas importantes relacionadas con el mismo: la primera, la adecuada administración de los recursos con los que se cuenta, para lo cual la Alta Dirección determina los parámetros a seguir para el cumplimiento de este objetivo; la segunda se centraliza en limitar las prestaciones a quienes por ley tienen el derecho de recibirlas; por lo tanto esta parte del Sistema de Control es la encargada de evitar que se brinden prestaciones a quienes no cuentan con tal derecho.Esto, en relación a lo que decíamos al inicio, significa en otras palabras que debemos tener un Sistema de Gestión de la Calidad de Atención, administrado por las áreas prestacionales y un Sistema de Gestión de la Calidad en Seguros administrada por las áreas aseguradoras o de seguros. Si el primer sistema no funciona bien, generaremos la insatisfacción del usuario y su alejamiento de EsSalud. Si el segundo sistema no funciona bien, agotaremos los recursos y
generaremos déficit. He ahí la importancia de contar con un Sistema eficiente de control a nivel de seguros.
El Sistema de Gestión de la Calidad en Seguros, deberá encargarse, de la implementación operativa integrada, estandarizada y coordinada en todas las Unidades de Seguros, de las políticas emitidas por la Alta Dirección y la División de Aseguramiento, de las normas y procedimientos emitidos por la Gerencia Central de Seguros a través de la Gerencia Técnica y de la Gerencia de Servicios al Asegurado, y del control cuantitativo y cualitativo de la función de seguros. Por otra parte, debe de ir desarrollando una automatización progresiva de la Auditoria de Seguros, en base a indicadores, que permitan la detección precoz y la investigación focalizada, y la generación de normas correctivas también precoces. Paralelamente, la implementación de una Auditoria Muestral de Seguros, garantizaría, junto a todo lo anterior un excelente sistema de control para EsSalud.
2.2.4. DEFINICIÓN DE ANALISIS Y DISEÑO DE UN SISTEMA DE
INFORMACIÓN
2.2.4.1 Rational Unified Process. R.U.P.“La Figura 3 ilustra la historia de RUP. El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory).
Figura 3: Historia de RUP
Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de
Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarrolló e incorporó diversos elementos para expandir ROP, destacándose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process.
Características esenciales
Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y es iterativo e incremental.
Proceso dirigido por Casos de UsoSegún Kruchten, P10, los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que seria bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del trabajo como se muestra en la Figura 4.
Figura 4: Los Casos de Uso integran el trabajo
10 Kruchten, P., The Rational Unified Process: An Introduction, 2000 Addison Wesley
Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.
Como se muestra en la Figura 5, basándose en los Casos de Uso se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de Uso.
Figura 5: Trazabilidad a partir de los Casos de Uso
Proceso centrado en la arquitecturaLa arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo10.
La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Además la definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema.
En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.
Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la
arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software.
En la Figura 6 se ilustra la evolución de la arquitectura durante las fases de RUP. Se tiene una arquitectura más robusta en las fases finales del proyecto. En las fases iniciales lo que se hace es ir consolidando la arquitectura por medio de baselines y se va modificando dependiendo de las necesidades del proyecto.
Architecture
Inception Elaboration Construction Transition
tiempo
ArchitectureArchitecture
Inception Elaboration Construction Transition
tiempo
Figura 6: Evolución de la arquitectura del sistema
Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura11, el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso y de despliegue, más la de Casos de Uso que es la que da cohesión a todas.
11 Kruchten, P. Architectural Blueprints—The “4+1” View Model of Software Architecture. IEEE
Figura 7: Los modelos se completan, la arquitectura no cambia drásticamente
Al final de la fase de elaboración se obtiene una baseline de la arquitectura donde fueron seleccionados una serie de Casos de Uso arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los más importantes para el usuario y aquellos que cubran las funcionalidades significativas)
Como se observa en la Figura 7, durante la construcción los diversos modelos van desarrollándose hasta completarse (según se muestra con las formas rellenas en la esquina superior derecha). La descripción de la arquitectura sin embargo, no debería cambiar significativamente (abajo a la derecha) debido a que la mayor parte de la arquitectura se decidió durante la elaboración. Se incorporan pocos cambios a la arquitectura (indicados con mayor densidad de puntos en la figura inferior derecha)12.
Proceso iterativo e incremental
Según Jacaboson, I., Booch, G., Rumbaugh J. el equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. 12 Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley
Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto.
Una iteración puede realizarse por medio de una cascada como se muestra en la Figura 8. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.
Figura 8: Una iteración RUP
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual del producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. En la Figura 9 se muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.
Figura 9: Esfuerzo en actividades según fase del proyecto
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline de la arquitectura.
Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.
Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
Otras prácticas
RUP identifica 6 best practices con las que define una forma efectiva de trabajar
para los equipos de desarrollo de software.
Gestión de requisitos
RUP brinda una guía para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y restricciones. Utiliza una notación de Caso de Uso y escenarios para representar los requisitos.
Desarrollo de software iterativo Desarrollo del producto mediante iteraciones con hitos bien definidos, en las
cuales se repiten las actividades pero con distinto énfasis, según la fase del proyecto.
Desarrollo basado en componentes
La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema. Esta característica en un proceso de desarrollo permite que el sistema se vaya creando a medida que se obtienen o se desarrollan sus componentes.
Modelado visual (usando UML)
UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema software. Es un estándar de la OMG (http://www.omg.org). Utilizar herramientas de modelado visual facilita la gestión de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado visual también ayuda a mantener la consistencia entre los artefactos del sistema: requisitos, diseños e implementaciones. En resumen, el modelado visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software.
Verificación continua de la calidad
Es importante que la calidad de todos los artefactos se evalúe en varios puntos durante el proceso de desarrollo, especialmente al final de cada iteración. En esta verificación las pruebas juegan un papel fundamental y se integran a lo largo de todo el proceso. Para todos los artefactos no ejecutables las revisiones e inspecciones también deben ser continuas.
Gestión de los cambiosEl cambio es un factor de riesgo crítico en los proyectos de software. Los artefactos software cambian no sólo debido a acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo, especialmente importantes por su posible impacto son los cambios en los requisitos. Por otra parte, otro gran desafío que debe abordarse es la construcción de software con la participación de múltiples desarrolladores, posiblemente distribuidos geográficamente, trabajando a la vez en una release, y quizás en distintas plataformas. La ausencia de disciplina rápidamente conduciría al caos. La Gestión de Cambios y de Configuración es la disciplina de RUP encargada de este aspecto
Estructura del proceso
El proceso puede ser descrito en dos dimensiones o ejes13:Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinámicos del proceso. Indica las características del ciclo de vida del proceso expresado en términos de fases, iteraciones e hitos. Se puede observar en la Figura 10 que RUP consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Como se mencionó anteriormente cada fase se subdivide a la vez en iteraciones.
Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles.
Figura 10: Estructura de RUP
13 Rational Software Corporation, Rational Unified Process. Best Practices for Software Development Teams, 1998
Estructura Dinámica del proceso. Fases e iteracionesRUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo concluye con una generación del producto para los clientes. Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada fase es variable.
ciclo de desarrollo ciclo de evolución
generación(release final de un ciclo de desarrollo)
release(producto al final de
una iteración)
base line(release asociadaa un hito)
ciclo de desarrollo ciclo de evolución
generación(release final de un ciclo de desarrollo)
release(producto al final de
una iteración)
base line(release asociadaa un hito)
Figura 11: Ciclos, releases, baseline
Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores que podrían ser los criterios aplicables a cada iteración. Los hitos para cada una de las fases son: Inicio - Lifecycle Objectives, Elaboración - Lifecycle Architecture, Construcción - Initial Operational Capability, Transición - Product Release. Las fases y sus respectivos hitos se ilustran en la Figura 12.
tiempo
Objetivos(Vision)
Arquitectura CapacidadOperacional
Inicial
Releasedel Producto
Inception Elaboration Construction Transition
tiempo
Objetivos(Vision)
Arquitectura CapacidadOperacional
Inicial
Releasedel Producto
Inception Elaboration Construction Transition
Figura 12: Fases e hitos en RUP
La duración y esfuerzo dedicado en cada fase es variable dependiendo de las características del proyecto. Sin embargo, la Figura 13 ilustra porcentajes frecuentes al respecto. Consecuente con el esfuerzo señalado, la Figura 14 ilustra una distribución típica de recursos humanos necesarios a lo largo del proyecto.
Inicio Elaboración Construcción Transición
Esfuerzo 5 % 20 % 65 % 10%
Tiempo Dedicado 10 % 30 % 50 % 10%
Figura 13: Distribución típicas de esfuerzo y tiempo
Figura 14: Distribución típica de recursos humanos
InicioDurante la fase de inicio se define el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso más esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un plan de negocio para determinar que recursos deben ser asignados al proyecto.
Los objetivos de esta fase son10:
Establecer el ámbito del proyecto y sus límites. Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que
definen la funcionalidad.
Mostrar al menos una arquitectura candidata para los escenarios principales.
Estimar el coste en recursos y tiempo de todo el proyecto. Estimar los riesgos, las fuentes de incertidumbre.
Los resultados de la fase de inicio deben ser14:
Un documento de visión: Una visión general de los requerimientos del proyecto, características clave y restricciones principales.
Modelo inicial de Casos de Uso (10-20% completado). Un glosario inicial: Terminología clave del dominio. El caso de negocio. Lista de riesgos y plan de contingencia. Plan del proyecto, mostrando fases e iteraciones. Modelo de negocio, si es necesario Prototipos exploratorios para probar conceptos o la arquitectura candidata.
Al terminar la fase de inicio se deben comprobar los criterios de evaluación para continuar:
Todos los interesados en el proyecto coinciden en la definición del ámbito del sistema y las estimaciones de agenda.
Entendimiento de los requisitos, como evidencia de la fidelidad de los Casos de Uso principales.
Las estimaciones de tiempo, coste y riesgo son creíbles. Comprensión total de cualquier prototipo de la arquitectura desarrollado. Los gastos hasta el momento se asemejan a los planeados.
Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o repensarlo profundamente.
ElaboraciónEl propósito de la fase de elaboración es analizar el dominio del problema, establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los Casos de Uso críticos identificados en la fase de inicio. También debe demostrarse que se han evitado los riesgos más graves.
Los objetivos de esta fase son10: 14 Rational Software Corporation, Rational Unified Process. Best Practices for Software Development Teams, 1998
Definir, validar y cimentar la arquitectura. Completar la visión. Crear un plan fiable para la fase de construcción. Este plan puede
evolucionar en sucesivas iteraciones. Debe incluir los costes si procede. Demostrar que la arquitectura propuesta soportará la visión con un coste
razonable y en un tiempo razonable.
Al terminar deben obtenerse los siguientes resultados14:
Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos y actores identificados, la mayoría de los casos desarrollados.
Requisitos adicionales que capturan los requisitos no funcionales y cualquier requisito no asociado con un Caso de Uso específico.
Descripción de la arquitectura software. Un prototipo ejecutable de la arquitectura. Lista de riesgos y caso de negocio revisados. Plan de desarrollo para el proyecto. Un caso de desarrollo actualizado que especifica el proceso a seguir. Un manual de usuario preliminar (opcional).
En esta fase se debe tratar de abarcar todo el proyecto con la profundidad mínima. Sólo se profundiza en los puntos críticos de la arquitectura o riesgos importantes.
En la fase de elaboración se actualizan todos los productos de la fase de inicio.
Los criterios de evaluación de esta fase son los siguientes:
La visión del producto es estable. La arquitectura es estable. Se ha demostrado mediante la ejecución del prototipo que los principales
elementos de riesgo han sido abordados y resueltos. El plan para la fase de construcción es detallado y preciso. Las
estimaciones son creíbles. Todos los interesados coinciden en que la visión actual será alcanzada si
se siguen los planes actuales en el contexto de la arquitectura actual. Los gastos hasta ahora son aceptables, comparados con los previstos.
Si no se superan los criterios de evaluación quizá sea necesario abandonar el proyecto o replanteárselo considerablemente.
Construcción
La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a través de las sucesivas iteraciones. Durante esta fase todos los componentes, características y requisitos deben ser implementados, integrados y probados en su totalidad, obteniendo una versión aceptable del producto.
Los objetivos concretos según Kruchten, P. incluyen:
Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.
Conseguir una calidad adecuada tan rápido como sea práctico. Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba)
tan rápido como sea práctico.
Los resultados de la fase de construcción deben ser14: Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e
Implementación) Arquitectura íntegra (mantenida y mínimamente actualizada) Riesgos Presentados Mitigados Plan del Proyecto para la fase de Transición. Manual Inicial de Usuario (con suficiente detalle) Prototipo Operacional – beta Caso del Negocio Actualizado
Los criterios de evaluación de esta fase son los siguientes: El producto es estable y maduro como para ser entregado a la comunidad
de usuario para ser probado. Todos los usuarios expertos están listos para la transición en la comunidad
de usuarios. Son aceptables los gastos actuales versus los gastos planeados.
TransiciónLa finalidad de la fase de transición es poner el producto en manos de los usuarios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la documentación, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, configuración, instalación y facilidad de uso del producto.
Kruchten, P se citan algunas de las cosas que puede incluir esta fase:
Prueba de la versión Beta para validar el nuevo sistema frente a las expectativas de los usuarios
Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por nuestro proyecto.
Conversión de las bases de datos operacionales. Entrenamiento de los usuarios y técnicos de mantenimiento. Traspaso del producto a los equipos de marketing, distribución y venta.
Los principales objetivos de esta fase son: Conseguir que el usuario se valga por si mismo. Un producto final que cumpla los requisitos esperados, que funcione y
satisfaga suficientemente al usuario.
Los resultados de la fase de transición son13
Prototipo Operacional Documentos Legales Caso del Negocio Completo Línea de Base del Producto completa y corregida que incluye todos los
modelos del sistema Descripción de la Arquitectura completa y corregida Las iteraciones de esta fase irán dirigidas normalmente a conseguir una
nueva versión.
Los criterios de evaluación de esta fase son los siguientes:
El usuario se encuentra satisfecho. Son aceptables los gastos actuales versus los gastos planificados.
Estructura Estática del proceso. Roles, actividades, artefactos y flujos de trabajo Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. RUP define cuatro elementos los roles, que responden a la pregunta ¿Quién?, las actividades que responden a la pregunta ¿Cómo?, los productos, que responden a la pregunta ¿Qué? y los flujos de trabajo de las disciplinas que responde a la pregunta ¿Cuándo? (ver Figura 15 y 16)13
Figura 15: Relación entre roles, actividades, artefactos
ActividadesRoles Artefactos
ActividadesActividadesRolesRoles ArtefactosArtefactos
Figura 16: Detalle de un workflow mediante roles, actividades y artefactos
Roles
Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas.
Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el dueño de un conjunto de artefactos.
RUP define grupos de roles, agrupados por participación en actividades relacionadas. Estos grupos son15:
Analistas:
15 Rational Software Corporation, Product: Rational Software Corporation, 2002
Analista de procesos de negocio. Diseñador del negocio. Analista de sistema. Especificador de requisitos.
Desarrolladores: Arquitecto de software. Diseñador Diseñador de interfaz de usuario Diseñador de cápsulas. Diseñador de base de datos. Implementador. Integrador.
Gestores: Jefe de proyecto Jefe de control de cambios. Jefe de configuración. Jefe de pruebas Jefe de despliegue Ingeniero de procesos Revisor de gestión del proyecto Gestor de pruebas.
Apoyo: Documentador técnico Administrador de sistema Especialista en herramientas Desarrollador de cursos Artista gráfico
Especialista en pruebas: Especialista en Pruebas (tester) Analista de pruebas Diseñador de pruebas
Otros roles: Stakeholders. Revisor Coordinación de revisiones Revisor técnico Cualquier rol
Actividades
Una actividad en concreto es una unidad de trabajo que una persona que desempeñe un rol puede
ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.
Artefactos
Un producto o artefacto es un trozo de información que es producido, modificado o usado durante el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final.
Un artefacto puede ser cualquiera de los siguientes15
Un documento, como el documento de la arquitectura del software. Un modelo, como el modelo de Casos de Uso o el modelo de diseño. Un elemento del modelo, un elemento que pertenece a un modelo como una
clase, un Caso de Uso o un subsistema.
Flujos de trabajo
Con la enumeración de roles, actividades y artefactos no se define un proceso, necesitamos contar con una secuencia de actividades realizadas por los diferentes roles, así como la relación entre los mismos. Un flujo de trabajo es una relación de actividades que nos producen unos resultados observables. A continuación se dará una explicación de cada flujo de trabajo.
Modelado del negocioCon este flujo de trabajo pretendemos llegar a un mejor entendimiento de la organización donde se va a implantar el producto.
Los objetivos del modelado de negocio son15
Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado (organización objetivo).
Entender el problema actual en la organización objetivo e identificar potenciales mejoras.
Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.
Derivar los requisitos del sistema necesarios para apoyar a la organización objetivo.
Para lograr estos objetivos, el modelo de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización por medio de un modelo de Casos de Uso
del negocio y un Modelo de Objetos del Negocio. Complementario a estos modelos, se desarrollan otras especificaciones tales como un Glosario.
RequisitosEste es uno de los flujos de trabajo más importantes, porque en él se establece qué tiene que hacer exactamente el sistema que construyamos. En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.
Los objetivos del flujo de datos Requisitos es15
Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podría hacer.
Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.
Definir el ámbito del sistema. Proveer una base para la planeación de los contenidos técnicos de las
iteraciones. Proveer una base para estimar costos y tiempo de desarrollo del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades
y metas del usuario.
Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso. Los requisitos no funcionales representan aquellos atributos que debe exhibir el sistema, pero que no son una funcionalidad específica. Por ejemplo requisitos de facilidad de uso, fiabilidad, eficiencia, portabilidad, etc.
Para capturar los requisitos es preciso entrevistar a todos los interesados en el proyecto, no sólo a los usuarios finales, y anotar todas sus peticiones. A partir de ellas hay que descubrir lo que necesitan y expresarlo en forma de requisitos.
En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se diseña la interfaz gráfica de usuario. Para ello habitualmente se construyen prototipos de la interfaz gráfica de usuario que se contrastan con el usuario final.
Análisis y DiseñoEl objetivo de este flujo de trabajo es traducir los requisitos a una especificación que describe cómo implementar el sistema.
Los objetivos del análisis y diseño son
Transformar los requisitos al diseño del futuro sistema. Desarrollar una arquitectura para el sistema. Adaptar el diseño para que sea consistente con el entorno de
implementación, diseñando para el rendimiento.
El análisis consiste en obtener una visión del sistema que se preocupa de ver qué hace, de modo que sólo se interesa por los requisitos funcionales. Por otro lado el diseño es un refinamiento del análisis que tiene en cuenta los requisitos no funcionales, en definitiva cómo cumple el sistema sus objetivos.
Al principio de la fase de elaboración hay que definir una arquitectura candidata: crear un esquema inicial de la arquitectura del sistema, identificar clases de análisis y actualizar las realizaciones de los Casos de Uso con las interacciones de las clases de análisis. Durante la fase de elaboración se va refinando esta arquitectura hasta llegar a su forma definitiva. En cada iteración hay que analizar el comportamiento para diseñar componentes. Además si el sistema usará una base de datos, habrá que diseñarla también, obteniendo un modelo de datos.
El resultado final más importante de este flujo de trabajo será el modelo de diseño. Consiste en colaboraciones de clases, que pueden ser agregadas en paquetes y subsistemas.
Otro producto importante de este flujo es la documentación de la arquitectura de software, que captura varias vistas arquitectónicas del sistema.
ImplementaciónEn este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. Además se deben hacer las pruebas de unidad: cada implementador es responsable de probar las unidades que produzca. El resultado final de este flujo de trabajo es un sistema ejecutable.
En cada iteración habrá que hacer lo siguiente: Planificar qué subsistemas deben ser implementados y en que orden deben
ser integrados, formando el Plan de Integración. Cada implementador decide en que orden implementa los elementos del
subsistema. Si encuentra errores de diseño, los notifica. Se prueban los subsistemas individualmente. Se integra el sistema siguiendo el plan.
La estructura de todos los elementos implementados forma el modelo de implementación. La integración debe ser incremental, es decir, en cada momento sólo se añade un elemento. De este modo es más fácil localizar fallos y los componentes se prueban más a fondo. En fases tempranas del proceso se pueden implementar prototipos para reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable desde el principio, probar tecnologías o diseñar la
interfaz de usuario. Los prototipos pueden ser exploratorios (desechables) o evolutivos. Estos últimos llegan a transformarse en el sistema final.
PruebasEste flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son15
Encontrar y documentar defectos en la calidad del software. Generalmente asesora sobre la calidad del software percibida. Provee la validación de los supuestos realizados en el diseño y
especificación de requisitos por medio de demostraciones concretas. Verificar las funciones del producto de software según lo diseñado. Verificar que los requisitos tengan su apropiada implementación.
Las actividades de este flujo comienzan pronto en el proyecto con el plan de prueba (el cual contiene información sobre los objetivos generales y específicos de las prueba en el proyecto, así como las estrategias y recursos con que se dotará a esta tarea), o incluso antes con alguna evaluación durante la fase de inicio, y continuará durante todo el proyecto.
El desarrollo del flujo de trabajo consistirá en planificar que es lo que hay que probar, diseñar cómo se va a hacer, implementar lo necesario para llevarlos a cabo, ejecutarlos en los niveles necesarios y obtener los resultados, de forma que la información obtenida nos sirva para ir refinando el producto a desarrollar.
DespliegueEl objetivo de este flujo de trabajo es producir con éxito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:
Probar el producto en su entorno de ejecución final. Empaquetar el software para su distribución. Distribuir el software. Instalar el software. Proveer asistencia y ayuda a los usuarios. Formar a los usuarios y al cuerpo de ventas. Migrar el software existente o convertir bases de datos.
Este flujo de trabajo se desarrolla con mayor intensidad en la fase de transición, ya que el propósito del flujo es asegurar una aceptación y adaptación sin complicaciones del software por parte de los usuarios. Su ejecución inicia en fases
anteriores, para preparar el camino, sobre todo con actividades de planificación, en la elaboración del manual de usuario y tutoriales.
Gestión del proyectoLa Gestión del proyecto es el arte de lograr un balance al gestionar objetivos, riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios.
Los objetivos de este flujo de trabajo son: Proveer un marco de trabajo para la gestión de proyectos de software
intensivos. Proveer guías prácticas realizar planeación, contratar personal, ejecutar y
monitorear el proyecto. Proveer un marco de trabajo para gestionar riesgos.
La planeación de un proyecto posee dos niveles de abstracción: un plan para las fases y un plan para cada iteración.
Configuración y control de cambiosLa finalidad de este flujo de trabajo es mantener la integridad de todos los artefactos que se crean en el proceso, así como de mantener información del proceso evolutivo que han seguido.
EntornoLa finalidad de este flujo de trabajo es dar soporte al proyecto con las adecuadas herramientas, procesos y métodos. Brinda una especificación de las herramientas que se van a necesitar en cada momento, así como definir la instancia concreta del proceso que se va a seguir.
En concreto las responsabilidades de este flujo de trabajo incluyen:
Selección y adquisición de herramientas Establecer y configurar las herramientas para que se ajusten a la
organización. Configuración del proceso. Mejora del proceso. Servicios técnicos.
El principal artefacto que se usa en este flujo de trabajo es el caso de desarrollo que especifica para el proyecto actual en concreto, como se aplicará el proceso, que productos se van a utilizar y como van a ser utilizados. Además se tendrán que definir las guías para los distintos aspectos del proceso, como pueden ser el modelado del negocio y los Casos de Uso, para la interfaz de usuario, el diseño, la programación, el manual de usuario”.
El Proceso Unificado Rational trata de desarrollar en una forma corta cualquier proyecto de investigación orientado a cualquier campo de una ciencia, sea en un proyecto de software, arquitectura, construcción, medicina, etc.. por que al final lo que se logra es delegar las funcionalidades de todos los objetos que intervienen en dichos objetivos o proyectos usando conocimiento de cada objeto para que interactúen entre si y lograr los objetivos del proyecto. Esta metodología usa diferentes tipos de diagramas como el de CASO USO que nos permite delegar conjunto de funciones hacia un objetivo en común o también capturar todos los requerimientos posibles para realizar el CASO DE USO. El DIAGRAMA DE COLABORACIÓN nos permite visualizar como los objetos van a interactuar entre ellos logrando un objetivo común que podría ser los indicadores. Los DIAGRAMAS DE CLASES es la representación conceptual de los objetos de acuerdo a sus estados y mensajes que ellos necesiten. Para hacer que los objetos de una clase cumplan funcionalidades complejas el diseñador tiene que investigar bien que las funcionalidades de un objeto cumpla con l objetivo del diseñadorRUP es una forma muy sencilla de disminuir la complejidad y permite el desarrollo del sistema tratando de cumplir los objetivos.
2.2.5 DEFINICIÓN DE TOMA DE DECISIONES
Tomar decisiones es un nuevo término para designar una actividad antigua que consiste en reaccionar ante situaciones más o menos inesperadas, esta actividad tiene relación con los actos reflejos que abundan en nuestro devenir cotidiano y de los que regularmente no tenemos conciencia ni recuerdo. El tomar una decisión depende de un gran número de factores conscientes o inconscientes, razonables o irrazonables y cuyo peso en la decisión poco tiene que ver con la calidad de la información contenida en ellos. La decisión que se toma de esta manera es un asunto personal y no existe ningún sistema computacional que se atreva a cambiarla. Sin embargo existen ciertas decisiones que son sometidas a un análisis científico en donde dada la repercusión de sus resultados pueden caer en los intereses de los demás; este tipo de decisiones pertenecen a aquellas que se elaboran a nivel profesional y existe una corriente de opiniones que favorece que entre ellas se incluyan las decisiones relacionadas con el área médica. De acuerdo a esta visión podemos describir una tipología de las decisiones de la siguiente manera:
Decisiones que se pueden asumir sin necesidad de modelos sofisticados (matemáticos o estadísticos). Son las decisiones diarias basadas en la experienciadel tomador de decisiones y suelen tener repercusiones e influencias en los objetivos, especialmente en el corto plazo.
Decisiones cuya racionalización requiere de una cierta información procesable estadísticamente, pero dentro de unos límites relativamente simples. Utilizan modelos empresariales sencillos.
Decisiones complejas, reservadas generalmente para grandes empresas o instituciones públicas y para las cuales es necesario acudir a modelos matemáticos de decisión para combinar las distintas opciones y encontrar la más adecuada. Ahora bien, también las decisiones se clasifican de acuerdo al tipo de participantes que se involucran en la toma de decisiones, en este caso de acuerdo a O.R. Holsti16, existen tres modelos para la toma de decisiones,
El primero de ellos es la “Política burocrática” de donde se generan decisiones como resultado de una negociación entre organizaciones burocráticas, en este modelo los valores de la organización están imperfectamente relacionados y el comportamiento de la organización es político.
El segundo modelo es “Dinámica de grupos” en donde surgen decisiones como producto de la interacción grupal, en este modelo la mayoría de las decisiones son tomadas en grupos elite pequeños, el grupo es diferente a la suma de sus miembros y la dinámica de grupo afecta la calidad y sustancia de las decisiones y
16 Tres modelos de toma de decisión (O.R. Holsti), Internet
El tercer modelo es “Proceso individual de toma de decisión” en donde la decisión es producto de una decisión individual, en este modelo se da mayor importancia a la evaluación individual y del proceso cognitivo, el cual puede conllevar a límites cognitivos a la racionalidad y a desvíos sistemáticos y motivados. Dependerá de cada proceso de la organización, la aplicación de cada modelo”.
2.2.6. CLASIFICACIÓN DE LOS SISTEMAS DE INFORMACIÓN PARA LA
TOMA DE DECISIONES
2.2.6.1. Decision Support Systems (DSS)17
Las características que deben de tener este tipo de sistemas son:
Interactividad.- sistemas computacionales que puedan interactuar en forma amigable y con respuestas en tiempo real.
Variabilidad en el tipo de decisiones.- apoyo al proceso de decisiones estructuradas y no estructuradas.
Frecuencia de uso.- Utilización frecuente.
Variedad de usuarios.- puede ser usado por diferentes usuarios de diversas áreas.
Flexibilidad.- permite adaptarse a una variedad determinada de estilos administrativos.
Posibilidad de desarrollo.- Permite que el usuario desarrolle de manera directa modelos de decisión sin la participación operativa de profesionales en informática.
Interacción ambiental.- Permite interactuar con información externa
Comunicación inter-organizacional.- Facilita la comunicación de información relevante de los niveles altos hacia los operativos y viceversa.
Acceso a base de datos.- Tiene capacidad de almacenar información de las bases de datos corporativas.
Simplicidad.- Debe ser simple de manejar y fácil de aprender por el usuario final.
17- Sistemas de información para los negocios. Un enfoque de toma de decisiones, Daniel Cohen, Enrique Asín, McGraw Hill, 2000
Para la implantación de un DSS técnicamente existen varias alternativas las cuales son:
Implantación aislada en microcomputadoras.- esta opción se recomienda para tomadores de decisiones independientes, que no requieren de interactuar con otros sistemas o personas.
Implantación en microcomputadoras interconectadas constituyendo una red local.- utilizada para la toma de decisiones secuenciales o simultáneas, las cuales involucran la participación de diferentes personas.
Microcomputadoras conectadas a minicomputadoras o a mainframes.- utilizado para toma de decisiones secuenciales compartiendo un mismo DSS, el cual está centrado en el mainframe.
Podemos encontrar en el mercado modelos desarrollados bajo los DSS, en ellos el usuario puede utilizar modelos clásicos, entre ellos están los modelos de inventarios, control de proyectos, programación lineal, simulación, colas, análisis estadístico y planeación financiera.
Los DSS tienen la posibilidad de manejar y almacenar información haciendo uso del acceso a bases de datos corporativas, generación de información privada en bases de datos locales y manipulación de información a través de técnicas de manejo de información. También permiten al usuario desarrollar sus propios modelos de decisión, estos sistemas deben ser de fácil accesos para la explotación de la información a través de gráficas de alta calidad y reportes que se diseñan y obtienen en intervalos cortos de tiempo.
Los DSS pueden utilizar bases de datos corporativas, locales y archivos propietarios así como, bases de datos públicas y de Internet. Las tendencias futuras de los DSS están en el apoyo a decisiones simultáneas, uso de DSS desarrollados en diversas localidades remotas, mayor apoyo gráfico, mayor desarrollo para computadoras personales, uso del reconocimiento de voz, descentralización del proceso de toma de decisiones, mayor desarrollo de software haciendo mayor uso de data warehouse y de data mining, incremento en la generación de modelos para ser utilizados en el Internet17
2.2.6.2. Executive Information Systems (EIS) Se define como un sistema computacional que provee al ejecutivo acceso fácil a lainformación interna y externa al negocio con el fin de dar seguimiento a los factores críticos del negocio. Con esta definición se puede decir que los EIS se basan en la información presente dejando a un lado los escenarios futuros. Sus principales características son:
Diseñados para cubrir las necesidades específicas de la alta administración.
Extraen, filtran, comprimen y dan seguimiento a la información crítica del negocio.
Los ejecutivos interactúan de forma directa con el sistema sin intermediarios.
Sistema caracterizado por manejo de gráficos de alta calidad, información tabular y en forma de texto.
Acceso de información que se encuentra en línea. El sistema está soportado por elementos especializados de hardware tales
como monitores o videos de alta resolución y sensibles al tacto, ratón e impresora con tecnología avanzada.
Para que un EIS tenga éxito deberá estar orientado hacia el uso gráfico de pantallas, deben ser rápidos, la información debe estar disponible y actualizada y los datos incorporados deben ser críticos para el éxito de una empresa.
El funcionamiento de los EIS se logra con el apoyo de paquetes como Excel o lotus, sin embargo existen herramientas especializadas tales como, el Commander EIS, Command Center, Executive Decisions y Executive Edge, la disponibilidad de software comercial a contribuido al crecimiento de este tipo de sistemas, cuyo precio oscila entre 100,000 a 200,000 dólares para uso en mainframes.
Las tendencias futuras de los EIS son, mejor integración con otras aplicaciones, desarrollo de mejor software comercial, mejores interfaces sistema – ejecutivo17
2.2.6.3.- Group Decision Support Systems (GDSS) Es un sistema interactivo basado en computadora, que facilita la solución de problemas no estructurados por un conjunto de tomadores de decisiones que trabajan en equipo. Estos sistemas deben de estar integrados por un líder o facilitador, un solicitante y los participantes. Sus características son:
Sistemas diseñados para apoyar decisiones en grupos. Accesibles para usuarios con diferente nivel de conocimiento computacional
y desoporte a la decisión.
Los GDSS pueden ser específicos o generales. Deben contener mecanismos para evitar el desarrollo de conductas
negativas en elgrupo.
Deben motivar a los miembros del grupo a participar de manera activa.
Este tipo de sistemas requieren de una sala de decisión la cual debe contener una red local de decisión y un sistema de teleconferencia.
Actualmente se cuentan con varios paquetes desarrollados para el GDSS entre ellos están:PLEXSYS, Colab, Shell GDSS, SAMM, DECAID, LADN, SMU Decision Lab, APL,DELAWARE y GROUPSYSTEMS.
La tendencia futura en este tipo de sistemas está en el mejoramiento de la tecnología con la que actualmente se están llevando a cabo las juntas, mayor apoyo en el Internet y utilización de inteligencia artificial.
2.2.6.4. Sistemas Expertos de Soporte para la Toma de Decisiones (EDSS)Un sistema experto se puede definir como un sistema computacional interactivo que permite la creación de bases de conocimiento, los cuales una vez cargadas responden a preguntas, despegan y sugieren cursos de acción emulando el proceso de razonamiento de un experto para resolver problemas en un área específica del conocimiento humano.
Este tipo de sistemas se ha logrado desarrollar gracias al uso de la inteligencia artificial, la cual podemos definir como la ciencia que estudia de manera sistemática el comportamiento inteligente, con el fin de imitar o simular las habilidades humanas mediante la creación y utilización de computadoras. Dentro de la inteligencia artificial existe una variedad de áreas las cuales son:
La robótica.- que estudia la imitación del movimiento humano a través de robots, estos robots son programados para desempeñar casi cualquier tarea en las empresas.
La simulación de la capacidad sensorial humana.- es un área que a partir de las computadoras pretende imitar las capacidades o habilidades sensoriales humanas tales como vista, oído, habla y tacto.
El lenguaje natural.- que se enfoca en el diseño y desarrollo de software capaz de aceptar, interpretar y ejecutar instrucciones dadas por los usuarios en su lenguaje nativo, sin embargo a esta rama aún le falta mayor desarrollo.
Los sistemas expertos.- los cuales permiten cargar bases de conocimientos obtenidos a través de la experiencia de un especialista o experto.
La complejidad de los sistemas expertos genera limitaciones en el manejo de la información, para eliminar estas limitaciones se han desarrollado redes neuronales, que son software diseñados para imitar los procesos del pensar del ser humano, su nombre proviene de la similitud con la forma de operar del cerebro en donde las neuronas forman enlaces en base a pulsos electrónicos.
En el caso de los problemas que tienen datos imprecisos o problemas que tienen más de una solución pueden encontrar respuesta a través del uso de la lógica difusa que es una técnica matemática.
También existe el concepto de “agente inteligente”, el cual es un programa diseñado con conocimientos para realizar ciertas tareas específicas, normalmente repetitivas. El propósito principal es poder asignar tareas al agente inteligente, las cuales se harán más rápido, más frecuentemente y con mayor eficiencia que si fueran desarrolladas por el ser humano.
Para utilizar un sistema experto es conveniente primero observar si se cumplen las siguientes características:
Utilización de varios expertos dentro del trabajo rutinario Las decisiones que se toman son complejas y siguen una secuencia lógica. La lógica de la toma de decisiones y la solución al problema se pueden
traducir en un árbol de decisión que muestre todos los cambios posibles y las acciones que se deben de realizar en cada caso.
El conocimiento está bien definido y es profundo. El problema no tiene solución analítica. Las reglas del juego no cambian con demasiada frecuencia. Existen pocos expertos en otras áreas de la organización.
Para el desarrollo de sistemas expertos es necesario utilizar las herramientas necesarias, estas pueden ser lenguajes de programación los cuales son llamados shells.
Existe una tendencia a denominar a los lenguajes relacionados con la inteligencia artificial y los sistemas expertos como lenguajes de quinta generación, los más conocidos son: LISP y PROLOG, dentro de esta categoría se encuentran C, Pascal, ADA y SMALLTALK. Aunque actualmente se tienen lenguajes orientados a objetos con aplicaciones en web los cuales están siendo muy utilizados para el desarrollo de este tipo de sistemas. En el mercado podemos encontrar paquetes de sistemas expertos como VP-EXPERT, EXSYS, LEVEL 5 e INTELLIGENT DEVELOPER, entre otros.
La tendencia futura de este sistema es una mayor utilización de los mismos en las
organizaciones, a futuro, las interfases serán en lenguaje natural, mayor uso de herramientas inteligentes para explotar la información, integración con otras tecnologías y el comercio electrónico en Internet se verá fuertemente beneficiado. 17 los sistemas de información requieren de manejo de información y para ello requieren de sistemas de almacenaje de datos, en la siguiente sección se describen estos sistemas.
2.2.7.- SISTEMAS DE DATAWAREHOUSING Estos Sistemas constan de tres elementos principales:
1. Levantamiento y gestión de grandes volúmenes de datos.2. Análisis de datos, tecnología OLAP y herramientas de datamining.3. Software de consulta amigable e intuitivo.
Figura 17. – Evolución de los sistemas Datawarehousing/Datamining.
Un Datawarehouse es un gran almacén de datos, en el que se integran datos procedentes de varias fuentes, ya sea internos o externos a la empresa. Y debe cumplir el principio arquitectural fundamental: la separación de los sistemas transaccionales de los informacionales en dos entornos tecnológicos diferentes, para que el análisis de los datos acumulados del negocio no interfiera con el procesamiento y registro de nuevas transacciones.
Los datawarehouse se encuentran organizados por temas y no por funciones, en estos sistemas también se utiliza del concepto Data Mart para referirse a un almacén de datos de menor tamaño, restringido generalmente a un área temática o a un departamento de la empresa.
Las etapas para la construcción de un Datawarehouse son:
Captura de datos.- utilizando herramientas para la extracción que soportan múltiples formatos de almacenamiento (bases de datos, tablas de textos, hojas de cálculo, etc.).
Tratamiento, conversión y transformación de los datos.- teniendo que homologar, mezclar o enriquecer los datos, podemos resaltar los siguientes: detección y corrección de errores como la eliminación de registros duplicados, anulación de valores sin sentido, homologación en la denominación de las variables, uso de diferentes unidades de medida, uso de diferentes formatos para fechas o cantidades, incorporación de valores que por defecto no estén incluidos, eliminación de campos que no aportarán nada al análisis y obtención de más información sobre las entidades objeto de análisis.
Existen tres tipos de sistemas de gestión de datos en los datawarehouse.
Base de datos relacional tradicional.- Las bases de datos convencionales son Access, SQL Server, Oracle Sybase, DB2, basado en un proceso de normalización.
Base de datos relacional, con un diseño en estrella y una desnormalización de tablas.- consiste en utilizar estructuras de datos no normalizadas que incorporan redundancias que permiten agilizar las consultas.
Bases de datos multidimensional.- Se almacenan los datos en cubos multidimensionales, especialmente diseñados para acelerar las consultas y el análisis multidimensional de la información.
Las herramientas de exploración del Datawarehouse facilitan el análisis de los datos acumulados para generar informes y gráficos útiles para la toma de decisiones, de donde podemos distinguir tres grandes grupos de herramientas disponibles para la exploración:
Herramientas queries and reporting.- permite generar informes predefinidos a partir de los campos calculados, así como preparar consultas ad hoc de forma gráfica, técnica QBE, Quero By Example o mediante el lenguaje SQL (Structure Query Language).
Análisis multidimensional (OLAP: ON LINE ANALYTICAL PROCESSING).- Son herramientas que facilitan el análisis de los datos a través de dimensiones y de jerarquías, utilizando consultas rápidas predefinidas y subtotales previamente calculados.
Herramientas de datamining.- Son técnica avanzadas que permiten detectar y modelizar relaciones entre los datos y obtener información no evidente17
2.2.7.1.- Análisis multidimensional OLAP Este tipo de técnica emplea un modelo multidimensional constituido por tres componentes:
Dimensiones.- grupos conceptuales que permiten analizar o consolidar los datos.
Medidas o indicadores.- valores numéricos que se guardan en la base de datos.
Jerarquías de dimensiones.- distintos niveles de agregación dentro de una dimensión.
Las operaciones básicas de análisis multidimensional permiten navegar por los datos almacenados en el Datawarehouse teniendo operaciones como: cambio de dimensión de análisis (drill across), permutar dos dimensiones de análisis (swap), subir (up) o descender (down) en el nivel de agregación, profundizar para alcanzar datos de un nivel inferior (drill down), expansión de un nivel de información (expand) y anulación de la expansión de un nivel de información (collapse). Hyperion es una de las empresas líderes en el mercado mundial de herramientas OLAP, a través de su plataforma Business Intelligence Essbase XTD.
2.2.7.2.- Herramientas datamining
Constituyen métodos avanzados para explorar y modelizar relaciones en grandes volúmenes de datos y obtener información que se encuentra implícita. Podemos clasificar en tres grupos los diferentes tipos de herramientas utilizados en la minería de datos:
Herramientas estadísticas
Calculo de parámetros estadísticos (medias, varianzas, correlaciones, etc.) Técnicas bayesianas Tests de hipótesis Técnicas de regresión lineal Análisis multivariante Análisis cluster (agrupación de datos para poder llevar a cabo la
segmentación)
Herramientas simbólicas
Árboles de decisión Reglas
Herramientas de inteligencia artificial
Redes neuronales Algoritmos genéticos
La metodología de datamining consta de las siguientes etapas:
Muestreo.- selección de una muestra de datos
Exploración.- Determinación de las tendencias principales, rango de las variables clave, frecuencia de los valores, correlación entre variables, etc.
Modificación.- Transformación y filtrado de variables.
Modelización de comportamiento.- empleando redes neuronales, árboles de decisión, análisis de regresión ó análisis estadístico multivariante.
Evaluación.- comprobación de la validez del modelo
Presentación.- presentación gráfica de los resultados18.
Una vez definidas las herramientas para el desarrollo de modelos y sistemas de toma de decisiones, es necesario visualizar la aplicación de estas herramientas en el proceso de toma de decisiones para la asignación de recursos en los establecimientos de atención médica.
2.3 MARCO CONCEPTUAL
Desarrollo de conceptos relacionados con el tema:
18 Sistemas de información. Herramientas prácticas para la gestión empresarial, Álvaro Gómez Vieites, Carlos SuárezRey, Alfa omega, 2004
Análisis.
Es el proceso mediante el cual se definen los problemas existentes en la unidad bajo estudio, con el fin de proponer alternativas de solución.
Análisis de Sistemas.
Es el proceso mediante el cual se estudian e interpretan los hechos del sistema actual, con el fin de especificar los requerimientos y especificaciones funcionales del sistema a desarrollar.
Arquitectura de información.
Referido al diseño y/o construcción de modelos (procesos, datos) desde un punto de vista de información.
Catalogo de requisitos.
Lista de requisitos, que comprenden los requisitos funcionales que el sistema debe satisfacer.
Dato.
Son hechos o material original de información; es decir son los elementos usados como base de decisión, calculo o medida en un proceso.
Desarrollo de sistemas.
Es un proceso formado por fases: plan de sistemas de información, análisis, diseño, construcción e implantación de sistemas, comienza cuando la administración o algunos consultores detectan las mejoras de los sistemas de información desde un punto de vista de soporte a las gestiones técnicas y/o administrativas.
Diagrama de contexto
Es aquel gráfico que proporciona el ámbito de estudio (declaración formal del dominio de la información). En el aparece todo aquello que necesite o envíe‚ datos de o hacia el real en estudio, representándose estos por unos objetos (productoras y receptoras de información) que se llaman entidades externas. Los objetos pueden ser instituciones públicas y privadas, Ministerios, entre otros.
Diagrama de Flujo de Datos.
Proporciona una representación del sistema a nivel lógico y conceptual, describiendo el movimiento de los datos en el sistema, ya sea manual o automático, incluyendo procesos, lugares para almacenar datos.
Diseño de sistemas. Es el proceso de planificar, reemplazar o completar un sistema organizacional existente, en dichos procesos se detallan un conjunto de especificaciones físicas que constituir n el punto de partida en la construcción del nuevo sistema.
Entidad.
Es cualquier objeto sobre el cual un sistema guarda información, las entidades están caracterizadas por sus atributos. Los atributos son las características o descripciones de una entidad.
Especificación funcional.
Son descripciones detalladas de las necesidades de información y los requerimientos del sistema a desarrollar desde un punto de vista funcional. Información. Es un conjunto de datos arreglados y ordenados en forma sutil, producido como resultado del procesamiento de datos.
Modelo. Son representaciones cuantitativas o cualitativas de un sistema. Estas representaciones deben mostrar las relaciones entre los diversos factores que son de interés para el análisis.
Modelo conceptual. Son gráficos, resultados del proceso de análisis y diseño como proceso de abstracción del sistema.
Modelo de datos. El modelo de datos es una representación gráfica y verbal de la información que fluye en cualquier sistema del mundo real y cuya validez puede ser verificada. Dicho modelo esta conformado por las entidades y sus relaciones.
Modulo.
- Es la representación de un programa, subprograma o rutina, dependiendo del lenguaje que se vaya a utilizar.
- Grupo de actividades y tareas que se realizan para producir un conjunto específico de productos finales.
Problemas. Los problemas son identificados en el ámbito del estudio mediante un conjunto de entrevistas, y son los que dificultan el buen desenvolvimiento de las actividades de la Institución o Dirección.
Procesos. Son actividades definidas cuya ejecución pueden ser identificadas por la transformación de flujos de datos (son susceptibles de tener entradas y salidas de datos).
Sistemas. Es un conjunto de elementos interdependientes organizados de modo que constituyan una entidad integral, que tienen el propósito común de lograr algún o algunos objetivos.
Accidente:
Es toda lesión corporal producida por acción imprevista, fortuita u ocasional, de una fuerza externa, repentina y violenta que obra súbitamente sobre la persona, independientemente de su voluntad y que puede ser determinada por los médicos de una manera cierta.
Adscripción:
Es el proceso por el cual EsSalud determina, el Centro Asistencial, al cual el paciente debe acudir para recibir servicios de salud. Esta asignación la realiza, de acuerdo a la distribución geográfica de la población, la dirección o ubicación del asegurado y la distribución de los Centros Asistenciales de EsSalud. Los servicios de salud a los que nos referimos son los de primer nivel de complejidad.
Afiliado:
Es el asegurado titular beneficiario de una póliza, o plan de seguros, o plan de salud.
Atención Ambulatoria:
Es la atención médica que recibe el asegurado, y luego regresa a su domicilio.
Atención Hospitalaria:
Es el internamiento por indicación médica, de un asegurado, en un centro asistencial, por lo menos durante un día, para recibir atención médica o quirúrgica.
Auditoría:
Es una herramienta del sistema de gestión, que revisa y evalúa, el adecuado cumplimiento de los procedimientos establecidos, con el fin de detectar irregularidades o vulnerabilidad de los sistemas de control vigentes.
Auditoría Concurrente:
Es el conjunto de procedimientos de auditoria de seguros, para el control de las atenciones hospitalarias, realizadas en un centro asistencial. Es una evaluación concurrente, porque se da durante el internamiento, con el fin de verificar, la correcta aplicación de los sistemas de control.
Auditoría de Casos Específicos:
Es el conjunto de procedimientos de auditoría de seguros, para la investigación de casos sospechosos detectados por otras áreas. Es una evaluación de casos derivados de las áreas administrativas o de las áreas de prestaciones, con el fin de verificar los derechos de los beneficiarios y los mecanismos para vulnerar los sistemas de control.
Auditoría de Planta:
Es el conjunto de procedimientos de auditoría, que se realizan con el fin de evaluar retrospectivamente las atenciones ambulatorias y de emergencia, realizadas en un Centro Asistencial.
Auditoría de Seguros:
Es una herramienta de gestión desarrollada e implementada por el área de seguros, con la finalidad de controlar los seguros que genera y administra la aseguradora.
Auditoría de Seguros en EsSalud:
Es el sistema de control (revisión y evaluación) de la aplicación, de los procedimientos establecidos, para la afiliación, registro y otorgamiento de prestaciones (en nuestro caso asistenciales), a los usuarios de los Centros Asistenciales propios de las Redes de EsSalud y tercerizados, así como para la protección del sistema, contra vulneración del mismo, con el fin de obtener beneficios a los que por ley no se tiene derecho.
Auditoría para el otorgamiento de Beneficios Especiales:
Es el conjunto de procedimientos de auditoría de seguros, para el control de las autorizaciones de procedimientos especiales, medicamentos fuera del petitorio y tratamientos en el extranjero. Es una evaluación previa, se da antes del otorgamiento del servicio, con el fin de verificar los derechos de los beneficiarios a estos servicios y la correcta aplicación de los sistemas de control.
Capa Simple:
Es el conjunto de atenciones médicas de mayor frecuencia y de menor complejidad detalladas en el Anexo 1 del Reglamento de la Ley Nº 26790.
Capa Compleja:
Es el conjunto de atenciones médicas de mayor complejidad y menor frecuencia. Por exclusión son aquellas enfermedades, no indicadas en la relación de Capa Simple.
Caso auditado:
Se considera caso auditado a aquel en el que se ha completado todo el procedimiento de auditoría de seguros, al margen de que se hayan detectado una o más irregularidades en cualquier parte del procedimiento.
Cobertura:
Beneficio que ampara al asegurado.
Continuidad:
El concepto de continuidad, se utiliza en este manual, cuando un asegurado estando acreditado en un tipo de seguro de EsSalud, migra hacia otro tipo de seguro, convirtiéndose en una excepción al Periodo de Carencia, de acuerdo a las normas del contrato del nuevo seguro. También hablamos de continuidad, cuando un asegurado regular en Periodo de Latencia, contrata un Seguro Potestativo, este caso también es una excepción al Periodo de Carencia. Sólo se remite a Seguros Potestativos.
Cónyuge:
Es el asegurado cónyuge, mujer o varón, casado con el afiliado o titular. Es un derechohabiente del titular.
Deducible:
Es el monto que debe pagar el titular o derechohabiente, para poder recibir una atención ambulatoria u hospitalaria, cuando así esté estipulado en su póliza o plan de seguros.
Derechohabiente:
Es el asegurado no titular, que cuenta con los derechos de cobertura de un plan de salud, por ser dependiente del titular. Puede ser cónyuge o concubino(a), hijo menor de edad, o hijo mayor de edad incapacitado, de acuerdo a las condiciones estipuladas en el plan de salud.
Enfermedad Crónica:
Es aquella enfermedad que tiene un tiempo de evolución prolongada o permanente, y que requiere de un tratamiento o control continúo. En todos los casos, EsSalud determinará esta característica, para sus asegurados.
Emergencia:
Es toda alteración o compromiso del estado de salud de una persona, de aparición súbita, y que pone en peligro su vida o el funcionamiento de órganos y sistemas vitales. Las situaciones de emergencia son identificadas y calificadas como tales, exclusivamente por el profesional de la salud.
Exclusiones:
Son todas aquellas intervenciones de salud, que no están cubiertas por una póliza, o plan de seguros o plan de salud.
Paciente Referido:
Es el asegurado, que por razones de su enfermedad, es transferido por su médico tratante a un centro asistencial de mayor nivel de complejidad, para la solución específica de dicha afección. Luego de la solución del motivo de referencia, el paciente deberá ser transferido a su centro asistencial de origen.
Periodo de Carencia:
Es el periodo durante el cual el titular y sus derechohabientes, no gozan de las coberturas contenidas en su Plan de Salud.
Periodo de Espera:
Es el periodo donde se postergan algunas prestaciones, para el titular y sus derechohabientes. Para tener derecho a alguna de estas prestaciones, deberá transcurrir el plazo establecido en las condiciones generales del Plan de Salud.
Periodo de Latencia:
Es el periodo durante el cual, un asegurado y sus derechohabientes, gozan del derecho de recibir atenciones de salud, en caso de desempleo o suspensión perfecta de labores, de acuerdo a lo estipulado en su plan de salud. Solo se remite a seguros regulares.
Plan de Salud:
Es la cobertura brindada por el asegurador, al titular y derechohabientes.
Plan Mínimo de Atención:
Es el conjunto de intervenciones de salud, que como mínimo deben otorgarse al asegurado titular o derechohabiente, y que constan en el Anexo 2 del Reglamento de la Ley Nº 26790, aprobado mediante Decreto Supremo Nº 009-97-SA.
Preexistencia:
Es cualquier condición de alteración del estado de salud, diagnosticada por un profesional médico colegiado, conocida por el asegurado y no resuelta en el momento previo a llenar y suscribir la Declaración Jurada de Salud, contenida en el formulario de afiliación.
Proceso de Contrarreferencia:
Es el procedimiento asistencial-administrativo, mediante el cual el medico tratante del Centro Asistencial de Destino, retorna la responsabilidad del manejo médico del paciente o el resultado del elemento diagnóstico, a su Centro Asistencial de Origen.
Proceso de Referencia:
Es el procedimiento asistencial-administrativo, mediante el cual el médico tratante traslada la responsabilidad del cuidado de la salud y/o ayuda al diagnóstico del paciente a un profesional de la salud de un Centro Asistencial de mayor nivel de Complejidad.
2.4 MARCO TECNOLOGICO
2.4.1 Objetivos del Sistema de Auditoria de Seguros.
Diseñar, un Sistema de Información para el monitoreo y toma de decisiones en el Sistema de Auditoria de Seguros de EsSalud, que integre y analice la data obtenida con la aplicación del Manual de Procedimientos de Auditoria de Seguros para los seguros: regular y potestativos de EsSalud, que permita aplicar las acciones respectivas orientadas a la supervisión, control y evaluación de las prestaciones de salud que se otorguen a los asegurados en los centros asistenciales, así como para el proceso de afiliación de dichos seguros. Asimismo, el desarrollo del sistema de información servirá para a través de una adecuada toma de decisiones, garantizar el correcto uso del sistema de aseguramiento de EsSalud y evitar pérdidas en los recursos de la institución.
Los seguros regulares y potestativos, relacionados al presente proyecto, se clasifican en:
Seguro Reqular
Seguro Regular: Trabajadores Dependientes, Pensionistas y Pescadores y Procesadores Pesqueros Artesanales Independientes.
Seguro de Salud Agrario
Seguro de Salud Agrario - Trabajadores Dependientes. Seguro de Salud Agrario - Trabajadores Independientes.
Sequros Potestativos
Seguro EsSalud Independiente. Seguro Essalud Personal y Familiar. Seguro Potestativo Único. Seguro Potestativo Plan Protección Total y Plan Protección Vital.
2.4.2 Rational Rose19
Rational Rose es una herramienta para “modelado visual”, que forma parte de un conjunto más amplio de herramientas que juntas cubren todo el ciclo de vida del desarrollo de software.
Rational Rose permite completar una gran parte de las disciplinas (flujos fundamentales) del proceso unificado de Rational (RUP), en concreto:
• Modelado del negocio• Captura de requisitos (parcial)• Análisis y diseño (completo)• Implementación (como ayuda)• Control de cambios y gestión de configuración (parte)
La ventana principal
La primera pantalla que aparece es un selector de “Framework” (esqueleto). Este cuadro de diálogo permite elegir modelos que contienen elementos predefinidos para distintos tipos de proyectos. Existen esqueletos para Java,Visual C++, RUP, ...
Al cancelar este cuadro de diálogo aparece la ventana principal de Rose.
19 http://ls.fi.upm.es/mdp/si/rose-int-req-an.pdf
Esta ventana tiene los siguientes componentes:
• “Browser”: muestra de forma jerárquica todos los elementos de los modelosde un proyecto.
• Documentación: muestra texto asociado al elemento seleccionado. Permitetambién modificar ese texto.
• “Log”: muestra mensajes sobre errores, progreso de tareas, etc.
• Diagramas: cada diagrama se muestra con una ventana diferente. Las ventanas de diagrama cuentan con un botón “overview”, que permite desplazarse rápidamente por el contenido de diagramas grandes.
• Barra de botones: es independiente del diagrama activo. Contiene los botones típicos de cualquier aplicación Windows (nuevo, abrir, guardar, copiar, cortar, pegar, imprimir, ayuda contextual) y botones propios de Rose:
o Ver / ocultar documentacióno Ir a diagramas de clase, de interacción, de componentes, de estado, de despliegue, de caso de uso. Al activar estos botones se muestra una lista con los diagramas del tipo correspondiente, para seleccionar cuál se quiere visualizar.o Ir al diagrama padreo Ir al diagrama anterioro Aumentar zoom, disminuir zoomo Ajustar a ventana, deshacer ajustaro Ayuda general
Los botones “ir a diagramas de caso de uso” y “ayuda general” no aparecen la primera vez que se arranca Rose, pero pueden activarse editando esa barra de botones.
• Barra de herramientas: dependerá del diagrama que se encuentre seleccionado. Contiene:
o Icono para seleccionar elementoso Conjunto de iconos propios del tipo de diagramao Icono de bloqueo. Si está bloqueado, cualquier icono de la barra permanece activo hasta que no se elija otro icono o el diagrama pierda el foco. Esto facilita insertar rápidamente elementos del mismo tipo en un diagrama. Este icono no se muestra generalmente, pero puede añadirse a la barra. Se puede conseguir el mismo resultado pulsando MAYS al insertar elementos en el diagrama.
• Especificación: permite completar la especificación de un elemento. La especificación puede abrirse de tres formas:
o Pulsando con el botón derecho del ratón en un elemento y eligiendo la opción “Open specification”.
o Seleccionado el elemento y activando la opción “Specification”, delmenú “Browse”.
o Haciendo doble clic en el elemento. Esto funciona así sólo en algunostipos de elementos.
El “Browser”
Esta ventana proporciona:
• Una vista jerárquica de los elementos de un proyecto.• Capacidades de “arrastrar y soltar” para editar el modelo.• Actualización automática del modelo ante cambios en el árbol.
Esta ventana aparece por defecto en la parte izquierda de la ventana principal. Puede ocultarse si se desea y también puede cambiarse su posición (fija o flotante).
Uso del browser para navegación:
• Al hacer doble clic sobre un diagrama, se muestra la ventana de ese diagrama.• Al hacer doble clic sobre un elemento de otro tipo (una clase, por ejemplo), se muestra la especificación de ese elemento.• En un diagrama, al hacer clic con el botón derecho en un elemento y elegir laopción “select in browser”, se selecciona ese elemento en el árbol.
Uso de arrastrar y soltar (introducción):
• De browser a browser: en general se mueven elementos de una parte a otra.• De browser a diagrama: se insertan elementos en el diagrama. Si el elemento pertenece a un paquete distinto que el del diagrama se muestra un texto “from...” para indicar dónde está definido ese elemento. La funcionalidad de “arrastrar y soltar” del browser es más compleja. En el manual de usuario está totalmente descrita (páginas 27, 28 y 29) y se irán viendo ejemplos según se profundice en las siguientes sesiones.
Creación de elementos. Hay varias opciones:• Desde un diagrama, mediante el icono correspondiente de la barra de herramientas.• Desde el browser, pulsando con el botón derecho en el paquete correspondiente, y eligiendo la opción “new” + el tipo de elemento que se desea crear. Esta opción no inserta el elemento en el diagrama. • Desde el menú principal, seleccionando “tools / create / <<tipo de elemento>” y luego pinchando en el diagrama correspondiente.
Borrado: si se borra con [SUPR] un elemento de un diagrama no se está borrando ese elemento del modelo, sólo se está quitándolo del diagrama. Para borrar un elemento definitivamente hay que hacerlo:
• Eligiendo la opción “delete” del menú de contexto en el browser.• Eligiendo la opción “edit / delete from model” ([CTRL+D]) del menú de contexto en el diagrama.
Introducción a los diagramas
Los diagramas son vistas gráficas del modelo. Rose mantiene automáticamente la consistencia entre los diagramas y las especificaciones correspondientes: si se modifica el diagrama se cambia la especificación, y viceversa.
Tipos de diagramas soportados por Rose:
• de Clases• de Casos de uso• de Colaboración• de Secuencia• de Componentes• de Estados• de Actividad• de Despliegue
En el árbol de todo modelo aparecen cuatro vistas, cada una de las cuales
admite determinados tipos de diagramas:
• Caso de uso: esta vista define la interacción entre actores y casos de uso. Diagramas principales: casos de uso, colaboración, secuencia, actividad.
• Lógica: esta vista define fundamentalmente las clases del sistema y sus relaciones. Diagramas principales: clases, estados.
• Componentes: esta vista contiene información sobre ficheros, ejecutables y librerías del sistema. Diagrama de componentes.• Despliegue: esta vista muestra la asignación de procesos al hardware. Diagrama de despligue.Creación de diagramas:
• Desde el browser, mediante el menú de contexto de un paquete, opción “new / <tipo de diagrama>”.• Desde la barra de botones, mediante los botones “ir a <tipo de diagrama>”, seleccionando “new” en el cuadro de diálogo posterior.• Desde el menú principal, mediante la opción “browse / <tipo de diagrama>” y seleccionando “new” en el cuadro de diálogo.
Enlazado de diagramas. Se pueden enlazar diagramas mediante notas. Forma de hacerlo:
• En el diagrama origen del enlace, insertar una nota.• Arrastrar el diagrama destino desde el browser hasta esa nota.• Haciendo doble clic en la nota se irá al diagrama destino.
Borrado de diagramas:
• Desde el browser, mediante el menú de contexto del diagrama, opción “delete”.• Desde la barra de botones, mediante los botones “ir a <tipo de diagrama>”, seleccionando el diagrama y luego pulsando el botón “delete” en el cuadro de diálogo posterior.• Desde el menú principal, mediante la opción “browse / <tipo de diagrama>”, seleccionando el diagrama y luego pulsando el botón “delete” en el cuadro de diálogo posterior.
Creación de elementos (ya visto):
• Desde el browser.• Desde el diagrama (barra de herramientas).• Desde el menú principal.
Nombrado de elementos:
• Elementos que pueden tener nombre repetido (si están en paquetes distintos): actores, casos de uso, clases, componentes y paquetes. En caso de producirse un nombre repetido, saldrá un mensaje avisándolo.• Si el nombre se define desde el diagrama, no existe la posibilidad de repetir nombres: se cogerá el elemento cuyo nombre se ha escrito. Si se quieren repetir nombres, habrá que poner el nombre en el browser o en la especificación.
Edición de diagramas:
• Funciona como cualquier editor gráfico.• Lo elementos se pueden mover, cambiar el tamaño, copiar, pegar, ... con el ratón.
Borrado de elementos (ya visto):
• Borrado “superficial” (sólo se borra del diagrama).• Borrado “profundo” (se borra del modelo).
Relaciones:
• Se crean eligiendo el tipo de relación y arrastrando desde el origen hasta el destino.• Se pueden definir “codos” en la línea que representa la relación (al crearlos o posteriormente).
Organización automática: Rose puede reorganizar de forma automática un diagrama. Para ello se usa la opción “Format / Layout diagrama” del menú principal.
Workspaces: define un entorno de trabajo, representando qué ventanas de un modelo están abiertas. Pueden grabarse y cargarse y pueden existir varios workspaces asociados a un mismo modelo.
Requisitos y Análisis con Rose
1. Captura de Requisitos
• Estructura recomendada en la fase de captura de requisitos para un proyecto de la complejidad del que se pide:
Use Case View
Paquete “Casos de uso”• Casos de uso y actores directamente, sin paquetes intermedios.• Dentro de cada caso de uso irá su modelo de estados, con su correspondiente diagrama de transición de estados.• Diagrama de casos de uso “Main”: mostrará el modelo de casos de uso.
Paquete “Interfaz de usuario” para el prototipo de IU• Diagrama “Main” (diagrama de clases) mostrará la navegación entre ventanas.• Las pantallas (y resúmenes de datos) se representarán como clases. Diagrama “Main”: mostrará los dos paquetes.
1.1 Encontrar actores y casos de uso
• En la barra de herramientas de caso de uso incorporar el botón “Creates an association relation”, que permite crear asociaciones sin dirección.
1.1.1 Identificación de actores• Los actores se pueden crear directamente en el diagrama.• Descripción de cada actor: en el campo “documentation” de su ventana deespecificación.
1.1.2 Identificación y breve descripción de casos de uso
• Los casos de uso se pueden crear directamente en el diagrama.• Descripción breve de cada caso de uso: en el campo “documentation” de su ventana de especificación.
1.1.3 Descripción del Modelo de casos de uso
• El resultado se va reflejando en el diagrama “Main” del paquete “Casos de uso”.
1.2 Detallar los casos de uso
• Aquí van diagramas de estados y especificación de los casos.
1.2.1 Diseñar un diagrama de estado para cada caso
• Diagrama de estados de cada caso de uso: se crea dentro del caso de uso.• Para “pintar” el camino básico sólo se pueden usar colores diferentes.
1.2.2 Descripción textual del caso de uso
• Lo mejor es hacerla en documentos aparte (Word, workpad, HTML, ...) y enlazarla al caso de uso en la pestaña “files” de su especificación.
1.3 Diseñar un prototipo de la interfaz de usuario
• Como Rose no permite pintar flechas entre notas, se utilizarán clases pararepresentar las pantallas.
o Las pantallas llevarán el estereotipo “pantalla”o La navegación se reflejará mediante asociaciones con dirección.
o Los datos que aparecen en pantalla se reflejarán como atributos públicos de la clase, con los estereotipos “entrada” o “salida” para reflejar su función.o Las acciones que puede elegir el usuario se reflejarán como operaciones públicas de la clase, con el estereotipo “acción”.o Los estereotipos se pueden escribir en el momento, o se pueden crear de forma completa, modificando ficheros de configuración de Rose. Esta segunda opción permite reutilizar estereotipos entre proyectos, así como asignarles representaciones gráficas.
2. Análisis
• Estructura recomendada en la fase de análisis para un proyecto de la complejidad del que se pide:
o Logical View Paquete “Modelo de Análisis”• Un paquete “Clases de análisis” que contendrá las clases de análisis (así se podrán utilizar en varios casos de uso).o Este paquete tendrá las clases de análisiso Habrá un diagrama de clases de análisis (“Main”).
• Un paquete para la realización de cada caso de uso, con nombre “<caso de uso> Análisis”.
o Un diagrama de clases de análisis (“Clases”) con aquellas clases que participan en el caso de uso (incluyendo su relación con los actores).
o Un elemento de tipo “Realización de caso de uso” (caso de uso con estereotipo “use-case realization”) con el mismo nombre que el paquete (“<caso de uso> - Análisis”). Dentro de cada realización de caso de uso se define un diagrama de colaboración
• Un diagrama de casos de uso (“Realizaciones – Análisis”) donde se muestran las relaciones de realización entre los casos de uso de captura de requisitos y los casos de uso de análisis. Paquete “Modelo de Diseño” (su contenido se verá cuando se trate el tema de diseño, implementación, etc.). Diagrama “Main”: mostrará los dos paquetes de la vista lógica.
2.1 Analizar los casos de uso
• Para mayor comodidad, poner los botones de los tres tipos de clases de análisis en la barra de herramientas de diagrama de clase.
• En los diagramas de clases de análisis se usarán asociaciones sin dirección.Poner el botón correspondiente en la barra de herramientas de clases deanálisis.
2.1.1 Identificar las clases de análisis
• Las clases de análisis se crearán directamente en el diagrama “Main” del paquete “Clases de Análisis”. Luego se arrastrarán desde el browser a los diagramas de clases de la realización de cada caso de uso.
• Los actores se arrastran desde el browser.• Las relaciones se definen en el diagrama de clases global. Luego, para los diagramas parciales basta con arrastrar las clases y actores y se dibujan automáticamente las relaciones.
2.1.2 Describir interacciones entre objetos de análisis
• Relaciones de realización:
o Para cada realización de caso de uso se reflejará la relación entre un caso de uso y su realización como una asociación dirigida (de realización a caso de uso) con estereotipo “realize" (En el diagrama “Realizaciones - Análisis”).
• Diagramas de colaboración:
o En los diagramas de colaboración los objetos (de clases de análisis o de actores) se crean arrastrando las clases sobre el diagrama. o Hay que dibujar los enlaces entre objetos (no se “heredan” de las relaciones entre clases).
o Conviene recordar el sentido en el que se pintaron los enlaces, ya que afecta a la inserción de mensajes.
o Los mensajes se numeran de forma automática. No se pueden insertar mensajes “en medio” de la secuencia actual, por lo que conviene preparar un borrador en papel antes de meter el diagrama de colaboración en Rose. Ojo: Se puede cambiar el orden de los mensajes mediante el “Diagrama de secuencia asociado” (F5). En ese diagrama se puede pintar la dependencia entre mensajes (para numeración jerárquica) y se puede cambiar el orden.
o Recordar que para borrar realmente un mensaje hay que eliminarlo del modelo (CTRL+D).
o Para añadir más mensajes en el mismo sentido, lo mejor es editar el enlace (pestaña “Messages”).
o Los nombres de los mensajes se van a definir como operaciones (sin argumentos) de las clases de análisis (facilita la consistencia y reutilización). Ojo:
hay que seleccionar el texto del mensaje y no la flecha. Ojo: hay que hacerlo sobre la marcha, ya que es más complicado cuando hay varios mensajes en la misma flecha.
o Esto hará que las operaciones aparezcan en los diagramas de clases. Se puede evitar que aparezcan (en los diagramas parciales) editando las propiedades de cada clase en los diagramas.
• Descripción textual de las colaboraciones
o Se pueden poner como una nota en el diagrama de colaboración.
o Otra opción sería ponerlo como descripción de la realización del caso de uso (menos recomendable porque es difícil hacer referencia a los mensajes del diagrama).
2.2 Analizar cada clase de análisis
• Los resultados de esta etapa se verán reflejados en el diagrama “Main” del paquete “Clases de análisis”.
• En este diagrama se puede cambiar la forma de representar los estereotipos para que se vean mejor las responsabilidades y atributos (opción “decoration”).
2.2.1 Identificar las responsabilidades
• Son las operaciones identificadas según se van completando los diagramas de colaboración de cada caso de uso.
2.2.2 Identificar los atributos
• Se definen en cada clase sin asignarles tipo.• Esto hará que los atributos aparezcan en los diagramas de clases. Se puede evitar que aparezcan en los diagramas parciales editando las propiedades de cada clase en los diagramas.
2.2.3 Identificar asociaciones, agregaciones y generalizaciones
• Se definen en el diagrama de clases principal de todo el análisis (Diagrama “Main” del paquete “Clases de Análisis”).• Para definir agregación, se modifica el extremo de la asociación que corresponda, diciendo que es agregado.• Para definir agregación fuerte, se modifica el tipo de “containment” del extremo opuesto a la agregación.• Para definir las cardinalidades, se modifica el extremo que corresponda.
2.5 MARCOS FILOSOFICO
2.5.1 Concepto de Holismo20.
“El Holismo (del griego holos que significa todo, entero, total) es la idea de que todas las propiedades de un sistema (biológico, químico, social, económico, mental, lingüístico, etc) no pueden ser determinadas o explicadas como la suma de sus componentes. El sistema completo se comporta de un modo distinto que la suma de sus partes.”
“El holismo enfatiza la importancia del TODO, que es más grande que la suma de las partes y da importancia a la interdependencia de las partes, de ahí el significado de decir: "Tengo una visión holista de la realidad o tengo una visión INTEGRAL de la realidad”. Este concepto tiene gran importancia en psicología, filosofía, pedagogía, historia, etc.”
2.6 MARCO LEGAL
Ley 26790 – Ley de Modernización de la Seguridad Social en Salud y normas modificatorias
D.S. N° 009-97-SA Reglamento de la Ley 26790. Ley 27056 – Ley de Creación del Seguro Social de Salud – EsSalud y normas
modificatorias. D.S. 002-99-TR Reglamento de la Ley 27056 Ley 27360 – Ley que aprueba las Normas de Promoción del Sector Agrario, su
Reglamento y normas modificatorias. D.S. 049-2002-AG Reglamento de la Ley 27360 Decreto Supremo Nº 013 – 2002 – TR, Texto Único de Procedimientos
Administrativos del Seguro Social de Salud – EsSalud. Resolución de Presidencia Ejecutiva Nº 261 – PE – ESSALUD – 2004, deja sin
efecto el procedimiento de acreditación contingente para la atención de asegurados y derechohabientes.
Directiva Nº 001 – GG – IPSS – 97, procedimiento para la inscripción y acreditación de gestantes de hijo(s) extramatrimonial(es).
Resolución Nº 08 – GDA – ESSALUD – 2004, establece pautas complementarias y faculta a la Gerencia Central de Seguros a dictar las normas necesarias para la adecuación progresiva de la Resolución Nº 261 – PE – ESSALUD – 2004.
Resolución de Gerencia Central de Seguros Nº 021-GCSEG-GDA-ESSALUD-2004. Aprueba el Procedimiento de Verificación de presuntas Afiliaciones Indebidas.
20 http://es.wikipedia.org/wiki/holismo...
Resolución Nº 040 – GCSEG – GDA – ESSALUD – 2004, aprueba el procedimiento de verificación del derecho de cobertura de los asegurados del Seguro Regular, Seguro Agrario Dependiente y Regímenes Especiales.
Resolución de Presidencia Ejecutiva Nº 201 – PE – ESSALUD – 2004, que autoriza la creación de Redes Asistenciales en EsSalud.
Ley 26790 – Ley de Modernización de la Seguridad Social en Salud y normas modificatorias.
D.S. N° 009-97-SA Reglamento de la Ley 26790. Ley 27056 – Ley de Creación del Seguro Social de Salud – EsSalud y normas
modificatorias. D.S. 002-99-TR Reglamento de la Ley 27056 Decreto Supremo Nº 013 – 2002 – TR, Texto Único de Procedimientos
Administrativos del Seguro Social de Salud – EsSalud. Acuerdo del Consejo Directivo Nº 216 – 39 – ESSALUD – 2004, que aprueba
el Seguro Potestativo Único. Resolución Nº 04 – GDA – ESSALUD – 2004, mediante la cual se faculta a la
Gerencia Central de Seguros a dictar Normas Complementarias para la Implementación del Seguro Potestativo Único.
Resolución Nº 08 – GDA – ESSALUD – 2004, establece pautas complementarias y faculta a la Gerencia Central de Seguros a dictar las normas necesarias para la adecuación progresiva de la Resolución Nº 261 – PE – ESSALUD – 2004.
Resolución de Gerencia Central de Seguros Nº 021-GCSEG-GDA-ESSALUD-2004. Aprueba el Procedimiento de Verificación de presuntas Afiliaciones Indebidas.
Resolución Nº 037 – GCSEG – GDA – ESSALUD – 2004, mediante la cual se aprueba en vía de regularización las cláusulas del Contrato del Seguro Potestativo Único.
Resolución Nº 054-GCSEG-GDA-ESSALUD-2004, aprueba el Procedimiento de Evaluación de información de la Declaración Jurada de Salud del Seguro Potestativo Único, el Procedimiento de evaluación de cobertura por diagnóstico, y el Procedimiento de Atención de reclamos por la acreditación o cobertura por diagnóstico.
Resolución Nº 56-GCSEG-GDA-ESSALUD-2004, aprueba el Procedimiento de control de ingresos por concepto de Deducibles y Copagos (Ambulatorio y Hospitalario) de los Seguros EsSalud Independiente y Potestativo Único.
Resolución Nº 62-GCSEG-GDA-ESSALUD-2004, aprueba denominaciones, cláusulas contractuales y formularios de los Planes Protección Total, Protección Vital y Emergencias Accidentales.
Resolución de Presidencia Ejecutiva Nº 201 – PE – ESSALUD – 2004, que autoriza la creación de Redes Asistenciales en EsSalud.
Contratos de los Seguros Potestativos que administra EsSalud.
Resolución de Presidencia Ejecutiva Nº 201 – PE – ESSALUD – 2004, que autoriza la creación de Redes Asistenciales en EsSalud.
Manual de Procedimientos de Seguros.
REFERENCIA BIBLIOGRAFICA
REFERENCIAS:
A. BIBLIOGRAFICAS
7 Moncada Ochoa, “sistema de información gerencial”, 2001, pagina 8
8 Copyright IBM Corp. 1987-2004 Rational Unified Process® Version 2003.06.13
10 Kruchten, P., The Rational Unified Process: An Introduction, 2000 Addison Wesley
11 Kruchten, P. Architectural Blueprints—The “4+1” View Model of Software Architecture. IEEE
12 Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley
13 Rational Software Corporation, Rational Unified Process. Best Practices for Software Development Teams, 1998
14 Rational Software Corporation, Rational Unified Process. Best Practices for Software Development Teams, 1998
15 Rational Software Corporation, Product: Rational Software Corporation, 2002
17- Sistemas de información para los negocios. Un enfoque de toma de decisiones, Daniel Cohen, Enrique Asín, Mc Graw Hill, 2000
18 Sistemas de información. Herramientas prácticas para la gestión empresarial, Álvaro Gómez Vieites, Carlos Suárez Rey, Alfa omega, 2004
B. ARTICULOS
Manual de Procedimientos de Auditoria.
2La promoción, la evaluación y la gestión de la tecnología para la salud. Hacia un enfoque virtual e integral, UTESA, Excelencia en tecnología para la salud, Funsalud, 2002.
3 El desarrollo de la evaluación de las tecnologías en salud en América Latina y el Caribe, Programa de organización y gestión de sistemas y servicios de salud, Organización Panamericana de la Salud, 2000.
4 Information technology in the Health Sector of Latin America and the Caribbean. Challenges and opportunities for the international technical cooperation, Pan American Health Organization, Pan American Sanitary Bureau, Regional Office of the World Health Organization. Division of Health Systems and Services Development, October 2001.
5 Tarjetas de Datos Sanitarios con circuito Integrado (tarjetas inteligentes) Manual para los profesionales de la Salud, Área de tecnología y prestación de servicios de salud, Organización Panamericana de la Salud, 2003
6 Setting Up Healthcare Services Information Systems. A Guide for Requirement Analysis, Application Specification, and Procurement, Essential Drugs and Technology Program. Division of Health Systems and Services Development, Pan American Health Organization. World Health Organization, July 1999
C. REVISTAS
D. ENLACES DE INTERNET
9 www.wanadoo.com
16 Tres modelos de toma de decisión (O.R. Holsti), Internet
19 http://ls.fi.upm.es/mdp/si/rose-int-req-an.pdf20 http://es.wikipedia.org/wiki/holismo...
