Download Criterios de aceptación del código fuente
Document related concepts
no text concepts found
Transcript
Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud ADQUISICIÓN DE: SOFTWARE APLICATIVO DE ATENCION PRIMARIA DE LA SALUD PRESUPUESTO OFICIAL: $ 120.000 VALOR DEL PLIEGO: $ 324 APERTURA: _________________________________ (LUGAR: ______________________________________- ROSARIO.-) INDICE CONDICIONES PARTICULARES ........................................................................................................................ 2 1.OBJETO ............................................................................................................................................................................................... 2 2.DESCRIPCIÓN GENERAL DEL PROCESO LICITATORIO ........................................................................................................... 2 3.GARANTÍA DE ADJUDICACION ..................................................................................................................................................... 4 4.IGUALDAD DE PRECIOS ................................................................................................................................................................. 4 5.FORMA DE COTIZAR ....................................................................................................................................................................... 4 6.ORDENANZA 7602/03 Y DECRETO 1962/04 .................................................................................................................................. 4 7.IMPUGNACIONES ORDENANZA 2650/80: .................................................................................................................................... 4 8.OBLIGACIONES DEL ADJUDICATARIO ....................................................................................................................................... 5 9.PENALIDADES .................................................................................................................................................................................. 5 10.TRANSCRIPCIÓN DE DECRETOS Y ORDENANZAS PERTINENTES ...................................................................................... 5 11.ACTIVIDADES A REALIZAR ......................................................................................................................................................... 5 Producto 1: Planificación y Diseño .............................................................................................................. 5 Producto 2: Módulos de Historias Clínicas y Atenciones y Turnos .............................................................. 6 Producto 3: Módulo de Farmacia ................................................................................................................. 6 Producto 4: Módulo de Estadística ............................................................................................................... 6 Producto 5: Cierre ......................................................................................................................................... 7 12.DEMOSTRACIÓN Y/O PRUEBA DE LA OFERTA ...................................................................................................................... 7 13.PLAZO Y FORMA DE ENTREGA .................................................................................................................................................. 7 14.FORMAS DE PAGO ......................................................................................................................................................................... 7 15.CRITERIOS DE ADJUDICACION ................................................................................................................................................... 8 16.ANTECEDENTES DEL OFERENTE ............................................................................................................................................... 8 17.INFORMACIÓN A PRESENTAR PARA LA EVALUACIÓN TÉCNICA (EN SOBRE NRO. 2) .................................................. 8 18.INFORMACIÓN A PRESENTAR PARA LA EVALUACIÓN ECONÓMICA (EN SOBRE NRO. 3) ........................................... 9 19.GARANTÍA ....................................................................................................................................................................................... 9 20.RIESGOS ........................................................................................................................................................................................... 9 21.MODO Y LUGAR DE EJECUCIÓN DE LOS TRABAJOS ............................................................................................................. 9 22.CAUSALES DE RESCISIÓN DE LA ADJUDICACIÓN IMPUTABLES AL ADJUDICATARIO .............................................. 10 23.PEDIDO DE ACLARACIONES Y CONSULTAS ......................................................................................................................... 10 24.ADICIONALES ............................................................................................................................................................................... 10 25.ITEMS A COTIZAR ........................................................................................................................................................................ 11 ANEXO 1: SISTEMA APLICATIVO .................................................................................................................... 12 1.1.AREAS INVOLUCRADAS ........................................................................................................................................................... 12 1.2.REQUERIMIENTOS FUNCIONALES DEL SISTEMA A OFERTAR ........................................................................................ 12 LISTADO DE REQUERIMIENTOS .............................................................................................................................................. 12 ABSTRACT..................................................................................................................................................................................... 13 CASOS DE USO ............................................................................................................................................................................. 21 INTERFACES CON OTROS SISTEMAS ...................................................................................................................................... 24 1.3.REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA A OFERTAR .................................................................................. 24 1.4.FUNCIONALIDADES A PROTOTIPAR ...................................................................................................................................... 24 1.5.AREA DEL PROYECTO PILOTO ................................................................................................................................................ 25 1.6.GLOSARIO DE TERMINOS ......................................................................................................................................................... 25 Página 1 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud ANEXO 2: FORMULARIO PARA EL C.V. DEL PERSONAL PROPUESTO ..................................................... 27 ANEXO 3: MANTENIMIENTO............................................................................................................................ 28 3.1.ALCANCES DEL SERVICIO DE MANTENIMIENTO ............................................................................................................... 28 3.2.MODIFICACIONES SOBRE LOS SERVICIOS INCLUIDOS EN EL CONTRATO................................................................... 28 3.3.FORMA DE COMUNICACIÓN DE LOS RECLAMOS ............................................................................................................... 28 3.4.TIEMPOS DE RESPUESTA ANTE RECLAMOS ........................................................................................................................ 28 3.5.VIGENCIA DEL CONTRATO....................................................................................................................................................... 28 3.6.CAUSALES DE RESCISIÓN......................................................................................................................................................... 28 3.7.HORARIOS DE PRESTACION DE LOS SERVICIOS ................................................................................................................. 28 ANEXO 4: CRITERIOS DE ACEPTACIÓN ........................................................................................................ 28 ANEXO 5: TECNOLOGÍAS DE DESARROLLO ................................................................................................. 32 ANEXO 6: ANTECENDENTES DEL OFERENTE ............................................................................................. 35 ANEXO 7: PLAN DE RIESGO............................................................................................................................ 36 CONDICIONES PARTICULARES OBJETO La Municipalidad de Rosario llama a Licitación Pública para la Adquisición de un Software Aplicativo de Atención Primaria de la Salud, basándose en los requerimientos y servicios conexos detallados en Anexo 1. Se deberá utilizar la tecnología y herramientas de desarrollo e implementación detalladas en Anexo 5, y los estándares de documentación y desarrollo que serán entregados al Adjudicatario. Opcionalmente Municipalidad podrá contratar el servicio de mantenimiento según características en Anexo 3. DESCRIPCIÓN GENERAL DEL PROCESO LICITATORIO CONSULTA Y RETIRO DEL PLIEGO: El pliego de bases y condiciones generales se encuentra a disposición de los interesados para su consulta y adquisición en el Despacho de la Secretaría General (Buenos Aires 711 – Segundo Piso). También podrá ser consultado en Internet al sitio www.rosario.gov.ar. Los interesados en su compra, lo harán en la antedicha repartición, previo pago de un sellado municipal de $324 (pesos trescientos veinticuatro) emitido por las Cajas del Banco Municipal de Rosario destinadas para tal fin. 2.1 APERTURA DE LA LICITACIÓN: La apertura del presente llamado a licitación pública se llevará a cabo el día ……………………. del año 2005 a las …….horas o el primer día hábil siguiente, a la misma hora, si este resultare inhábil, en el Salón Belgrano de la Municipalidad de Rosario, Buenos Aires 711, 1er.piso. 2.2 ACLARACIONES AL PLIEGO DE BASES Y CONDICIONES: Los adquirentes del presente pliego de bases y condiciones podrán solicitar las aclaraciones técnicas que consideren necesarias, formalmente por escrito, y respecto de los ítems requeridos en el llamado a licitación, a la Dirección General de Informática de la Municipalidad de Rosario, ubicada en calle Santa Fe 656 - 1er.Piso, Rosario, Teléfonos: 03414802251/5/6. Serán aceptadas las consultas y/o aclaraciones técnicas recibidas hasta 5 (cinco) días corridos antes de la fecha y hora fijados para la apertura de la licitación, y las respuestas serán comunicadas a todos los adquirentes del presente pliego, como máximo, hasta 48 horas corridas antes de la fecha y hora fijados para la apertura de la licitación. 2.3 OFERTA. MODO Y PLAZO DE PRESENTACIÓN. REQUISITOS: La presentación de la propuesta se hará en 3 (tres) sobres cerrados, identificados cada uno de ellos en su exterior y en letra imprenta, con el nombre completo del oferente y las siguientes leyendas: SOBRE Nº 1: “Documentación de la empresa”, SOBRE Nº 2 : “Oferta Técnica” y SOBRE Nº 3 : “Oferta Económica”. Los sobres deberán presentarse en original y una copia. Los tres sobres serán colocados dentro de un sobre cerrado y lacrado, el cual no contendrá ninguna identificación del oferente y llevará por única leyenda el número de expediente administrativo por el cual se tramita el presente llamado a licitación. La propuesta será presentada por los interesados, en el Despacho de la Secretaría General, el cual entregará recibo de su recepción. Las ofertas estarán escritas a máquina, mecanografiadas o mediante uso de PC indistintamente, y cada una de sus hojas estará foliada y contendrá la firma y sello del oferente. Las salvaturas (enmiendas, raspaduras, agregados, entre líneas, testados) serán consignadas al pie de los respectivos escritos y antes de la firma y sello del oferente. Serán aceptadas las propuestas ingresadas hasta el día y hora fijados para la apertura de la presente licitación. 2.4 GARANTÍA DE LA OFERTA: Los oferentes deberán avalar sus ofertas mediante la constitución de garantía por la suma de Pesos mil doscientos ($1.200 ), bajo cualquiera de las siguientes formas: Depósito en dinero en efectivo, en Pesos, a la Orden de Municipalidad de Rosario a efectuarse en la Caja del Banco Municipal ubicada en el Hall central del edificio Ex Aduana, Av. Belgrano 328 – Planta Baja). Seguro de caución, con póliza emitida por Compañía de Seguros autorizada por la Superintendencia de Seguros de la Nación. La compañía deberá constituir domicilio legal en la ciudad de Rosario y someterse a la jurisdicción de los Tribunales Ordinarios de Rosario, Provincia de Santa Fe. Fianza otorgada por institución bancaria o entidad financiera de primera línea, sujeta a control del Banco Central de la República Argentina y a satisfacción del Departamento Ejecutivo. La institución bancaria/financiera se constituirá en lisa, llana y principal pagadora con renuncia al beneficio de división y excusión; en los términos del Artículo Nro. 2013 del Código Civil y a la exigencia de la interpelación judicial previa determinada por el Artículo Nro. 480 del Código de Comercio, pagadera incondicionalmente al primer requerimiento de Municipalidad de Rosario. La entidad deberá Página 2 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud constituir domicilio legal en la ciudad de Rosario y someterse a la jurisdicción de los Tribunales Ordinarios de Rosario, Provincia de Santa Fe. 2.5 MANTENIMIENTO DE LA OFERTA: Los oferentes están obligados a mantener las ofertas presentadas durante un plazo mínimo de 90 (noventa) días corridos contados a partir de la fecha de apertura. 2.6 PÉRDIDA DE LA GARANTÍA DE LA OFERTA: Si las ofertas presentadas fueran retiradas por el oferente dentro del plazo de mantenimiento de la oferta indicado en el artículo anterior, el oferente perderá el depósito en garantía constituido oportunamente. 2.7 DEVOLUCIÓN DE LA GARANTÍA DE OFERTA: Una vez resuelto el presente llamado a licitación, mediante el dictado del respectivo acto administrativo, Municipalidad de Rosario dispondrá la devolución de las garantías a aquellos oferentes cuyas propuestas no hubieran sido aceptadas, sin derecho a reclamo alguno por la no adjudicación, (Artículo 81 de la Ordenanza de Contabilidad). Dichos depósitos podrán ser retirados, previa solicitud por ante la Dirección General de Contabilidad y Liquidaciones - Dirección de Liquidación, dentro del plazo máximo de 3 (tres) meses contados desde la resolución de la adjudicación; transcurrido dicho término, caducará administrativamente todo derecho, procediéndose a la apropiación de fondos, según la forma de constitución del depósito. 2.8 ACEPTACIÓN DE LAS OFERTAS: Municipalidad de Rosario se reserva el derecho de aceptar la oferta que considere más conveniente a sus intereses o rechazarlas a todas, acto que no dará lugar a indemnización alguna (Art. 74 Ordenanza de Contabilidad). 2.9 ACTO DE APERTURA DE LAS OFERTAS: El día y hora fijados en el presente pliego y en presencia de los interesados que concurran, se procederá a la apertura de las ofertas en el Salón Belgrano, según el siguiente procedimiento: 1) Se verificará que estén reunidas las ofertas recibidas en tiempo y forma. 2) Se abrirán los SOBRES Nº 1, 2 y 3 y se verificará, para cada uno de ellos, su contenido y constancia de pago del sellado de adquisición del pliego. Las ofertas cuyo sobre no contuviere en su interior los SOBRES Nº 1, 2 y 3 serán rechazadas in limine. Dichas presentaciones serán apartadas, no procediéndose a la apertura de sobres y la documentación quedará bajo custodia de Municipalidad de Rosario, hasta su posterior devolución al interesado, que deberá retirarla en forma personal en el Despacho de la Secretaría General. 3) Se labrará un Acta donde se consignará lo acaecido. 2.10 DOCUMENTACIÓN A CUMPLIMENTAR CON LAS OFERTAS: Los sobres deberán estar correctamente rotulados indicando el nro. de sobre, y la licitación a la cual hace referencia. El oferente deberá seguir rigurosamente el orden temático del presente pliego y especificaciones técnicas, debiendo dar respuesta a todas y cada una de las exigencias para la presentación de sus propuestas. 1) Contenido del SOBRE Nº 1: En original y duplicado: Datos personales o societarios: Nombre completo de la persona física o jurídica que formula la propuesta, Nº de CUIT, CUIL o CDI, número de teléfono, número de fax, dirección de correo electrónico. En el caso de personas jurídicas, copia certificada de estatutos de la institución o Contrato Social, nómina completa de sus integrantes y miembros de Comisión Directiva o Directorio, copia certificada de inscripción en el Registro Público de Comercio y constancia de su subsistencia. Nota de declaración de domicilio real del oferente y constitución de domicilio legal en la ciudad de Rosario y Nota de declaración jurada por la cual el oferente declara que ante cualquier controversia o cuestión litigiosa que se suscite con motivo de la presente licitación se somete a la jurisdicción de los tribunales competentes de la ciudad de Rosario, Provincia de Santa Fe, con renuncia a todo otro fuero que pudiere corresponder, incluso el Federal. Firma y aclaración de firma de la persona que rubrica la propuesta, sea el propio oferente o apoderado de éste, con agregación, en este último caso, de copia certificada de poder mediante el cual se le asignan facultades de representación en el llamado a licitación. Sellado Municipal de la adquisición del pliego, emitido por pesos trescientos veinticuatro($324). Pliego de Bases y Condiciones y sus anexos, firmado y sellado por el oferente o apoderado, en cada una de sus hojas. Constancia de constitución de garantía de la oferta conforme al Art. 2.4. Constancia de inscripción en el Padrón de Proveedores de la Municipalidad de Rosario (Decreto Nro. 439/1998): Los oferentes que se hallen inscriptos en el Padrón de Proveedores de la Municipalidad de Rosario deberán presentar dicha constancia. Aquellos oferentes que no se hallen asentados en el Padrón de Proveedores, o bien deban modificar los datos oportunamente declarados en el mismo, presentarán el formulario de empadronamiento / modificación de datos que se adjunta al presente, completado en todos sus rubros. Declaración jurada por la cual el oferente declare que no se encuentra comprendido en cualesquiera de las siguientes circunstancias: Haber sido declarado en concurso liquidativo o quiebra o haberse solicitado su concurso preventivo dentro de los dos años anteriores al presente llamado a licitación. No pertenecer, en caso de sociedades, ninguno de los socios, a la planta de personal municipal, tanto permanente como contratado, incluso dentro de los 2 (dos) años después de haber cesado en sus funciones. No estar inhibido, ni ser deudor del Estado. No estar condenado por delito contra la fe pública. En caso que los oferentes optaren por presentarse bajo empresas consorciadas en Unión Transitora de Empresas, deberán, además de la documentación citada anteriormente, dar cumplimiento a los requisitos dispuestos por la Ley 22.903, adjuntando copia del Acta de asamblea donde conste la decisión de cada sociedad de participar en la U.T.E, contrato constitutivo de U.T.E. en el que se Página 3 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud encuentre pactada la solidaridad entre las empresas frente al comitente debiendo cumplir individualmente con los requisitos establecidos (con excepción de la garantía de oferta, que deberá ser presentada a nombre de la U.T.E.). El contrato constitutivo podrá inscribirse con posterioridad a la fecha de apertura y antes del acto que disponga la adjudicación. Fotocopias autenticadas de los siguientes comprobantes otorgados por esta Municipalidad: Constancia de pagos registrados que demuestre que no haya deuda de Derecho de Registro e Inspección hasta el mes de junio del 2005 inclusive Constancia de pagos al día de Tasa General de Inmuebles y de Contribución de Mejoras de las propiedades que posea el proponente en la ciudad de Rosario hasta el mes de junio del 2005 inclusive. 2) Contenido del SOBRE Nro. 2: En original y duplicado: Antecedentes: los oferentes deberán presentar toda la documentación que crean necesaria para acreditar sus antecedentes. Adjuntar información de Organismos Públicos y/o privados de quienes hayan sido o sean proveedores de productos similares. Indicar teléfono, dirección y persona a contactar a la que se podrán solicitar referencias. (Detalles en Art. 16 ) Propuesta técnica y toda especificación técnica aclaratoria de lo ofertado (Detalles en Art. 17) 3) Contenido del SOBRE Nro. 3: En original y duplicado, Propuesta económica (Detalles en Art.18). Los duplicados de los Sobres 2 y 3 serán remitidos, luego del acto de apertura, a la Dir. Gral. de Informática a los fines de adelantar la lectura de las propuestas. 1. GARANTÍA DE ADJUDICACION El oferente que resultare Adjudicatario de la presente licitación, deberá incrementar el monto del depósito en garantía de oferta indicado en el Art 2.4 hasta la suma equivalente al 5 % (cinco por ciento) del monto total adjudicado, a fin de avalar el cumplimiento de las obligaciones emergentes del contrato, debiendo acreditar tal circunstancia dentro de los 10 (diez) días hábiles contados a partir de que fuere notificado fehacientemente del acto administrativo de adjudicación. 2. IGUALDAD DE PRECIOS Cuando después de abiertas las propuestas se verifique una coincidencia de precios y condiciones ofrecidas, se llamará exclusivamente a esos proponentes a fin de mejorar sus precios, en forma escrita, señalando día y hora dentro de un término que no exceda de 5 (cinco) días hábiles. Cuando la coincidencia entre las propuestas más convenientes no quede resuelta dentro del plazo señalado en el párrafo anterior, la adjudicación se hará por concurso de antecedentes entre los proponentes o por sorteo entre ellos (Art. 74 de la Ordenanza de Contabilidad). FORMA DE COTIZAR Las ofertas deben incluir en el precio el Impuesto al Valor Agregado, por ser Municipalidad de Rosario No responsable en el citado impuesto, en tanto y en cuanto se halle gravado el servicio o bien que se contrata. Se aceptarán únicamente ofertas en Pesos. No se aceptarán costos adicionales que no hayan sido incluidos en la oferta. El precio a cotizar deberá incluir: todos los gastos que se generen por traslados, viáticos, etc. la totalidad de los gastos emanados del cumplimiento de las obligaciones laborales y previsionales correspondientes los derivados de los seguros los que surjan de las normas impositivas o del presente llamado todo aquello que sea parte del objeto de la presente licitación El Item 2 – Opcional deberá cotizarse indefectiblemente, bajo pena de desestimación de la propuesta completa. 3. ORDENANZA 7602/03 Y DECRETO 1962/04 Constituyen parte de esta licitación y se adjuntan al pliego licitatorio. Para gozar de dichos beneficios, los proveedores deberán presentar la declaración jurada establecida en el Anexo I del decreto citado. 4. IMPUGNACIONES ORDENANZA 2650/80: Los oferentes tendrán derecho a tomar vista de lo actuado en los actos licitatorios en que hubieren formulado propuesta durante el día siguiente hábil al de la apertura de la licitación, concurriendo para tal fin a la dependencia municipal donde se hubiere realizado el acto. Podrán formular impugnaciones dentro de los 2 (dos) días hábiles siguientes al vencimiento del término anterior, las cuales serán admitidas si cumplieren con los requisitos de presentación que se detallan: Las impugnaciones serán presentadas por escrito, en papel con sellado municipal por un valor de $2000( dos mil Pesos) exponiendo las razones de hecho y de derecho en que se funden. Los escritos serán presentados ante la Dirección de Mesa General de Entradas de Municipalidad, con mención del expediente por el cual se tramitó el llamado a licitación. Las impugnaciones a las propuestas de terceros o a los actos licitatorios no fundadas o carentes de importancia que, a juicio del Departamento Ejecutivo hayan tenido el propósito de entorpecer el trámite de la adjudicación, harán pasible a quien las haya formulado de sanción de pérdida del depósito en garantía de su oferta, sin perjuicio de disponerse su suspensión por hasta doce meses en el Padrón de Proveedores y Registro de Sancionados. Página 4 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud 5. OBLIGACIONES DEL ADJUDICATARIO Sin perjuicio de las penalidades mencionadas en el Art.9, los postulantes/Adjudicatarios serán pasibles de la aplicación del régimen sancionatorio previsto en el Decreto Nº 439 de fecha 25 de marzo de 1998 (Padrón de Proveedores y Registro de Sancionados). PENALIDADES En caso de que el Adjudicatario incurriera en las situaciones detalladas a continuación, Municipalidad se reserva el derecho de aplicar las siguientes multas: Por cada incumplimiento en los plazos y/o los criterios de aceptación de cada producto/subproducto se prevé un descuento del 1% del valor de cada producto. Estos descuentos podrán ser acumulativos y se harán efectivos al momento del pago de la factura que deberá realizar Municipalidad. Por cada incumplimiento del contrato de mantenimiento se prevé una multa del 1% del monto total del mantenimiento, que se hará efectiva al momento del pago de la factura del contrato de mantenimiento que deberá realizar Municipalidad. En caso de incumplimiento de la garantía el Adjudicatario será pasible de las sanciones correspondientes conforme al decreto 439/98 del Reglamento de Compras. TRANSCRIPCIÓN DE DECRETOS Y ORDENANZAS PERTINENTES TRANSCRIPCIÓN DEL ART. 18º DE LA LEY ORGÁNICA DE LAS MUNICIPALIDADES Nro. 2756: “Cuando la Municipalidad fuere condenada al pago de una deuda cualquiera, la corporación arbitrará dentro de los 6 (seis) meses siguientes a la notificación de la sentencia respectiva, la forma de verificar el pago. Esta prescripción formará parte integrante, bajo pena de nulidad de todo acto o contrato que las autoridades comunales celebren en representación del municipio y deberá ser transcripto en toda escritura publica o contrato que se celebre con particulares”. TRANSCRIPCIÓN DEL ART.55 DE LA ORDENANZA DE CONTABILIDAD: “No obstante lo dispuesto en el artículo anterior en casos excepcionales podrán contraerse obligaciones susceptibles de traducirse en compromisos sobre presupuestos a dictarse para años financieros futuros, en los casos siguientes: Inc.C) Locaciones de inmuebles y de Servicios y contratos de suministros y otros gastos de operación, cuando procuren ventajas económicas, aseguren la continuidad de los servicios, permitan lograr colaboraciones intelectuales o técnicas o lo indiquen las costumbres administrativas. El Departamento Ejecutivo cuidará de incluir en el proyecto de presupuesto para cada año financiero, las previsiones necesarias para imputar los gastos comprometidos en virtud de lo autorizado por el presente artículo e incluirá en los contratos pertinentes la cláusula rescisoria a favor de la Municipalidad, sin indemnización, si no se votan en los períodos siguientes los créditos que permitan atender las erogaciones”. TRANSCRIPCIÓN DE DECRETO Nro. 0624/96: “Quien resultare Adjudicatario de la presente licitación Pública, deberá abrir en el Banco Municipal de Rosario, una Cuenta Corriente o Caja de Ahorro, según corresponda, a fines de que Tesorería General haga efectivos los pagos correspondientes. La constancia de apertura de la referida Cuenta Corriente o Caja de Ahorro, deberá acompañarse conjuntamente con la factura respectiva”. TRANSCRIPCIÓN DEL ART. 5 DEL DECRETO Nro. 0736/01: “En los citados actos licitatorios todos los oferentes deberán incluir en sus propuestas declaración sobre su conocimiento a las disposiciones del presente decreto” ACTIVIDADES A REALIZAR El desarrollo del sistema deberá incluir la entrega de los productos intermedios que se describen a continuación: Producto 1: Planificación y Diseño Este producto se subdivide en: Subproducto 1: Documentación de Planificación, incluyendo como mínimo: Cronograma detallado de trabajo para todas las actividades, productos/subproductos a entregar con asignación de los recursos involucrados en las mismas Revisión y ampliación del material entregado por Municipalidad en Anexo 1, incluyendo: Especificación de casos de uso del módulo de estadística. Diagrama de estados y actividad. Versión actualizada incluyendo las modificaciones realizadas sobre la documentación entregada, y los nuevos casos de uso que pudiesen surgir. Subproducto 2: Documentación de todo el diseño a los fines de permitir el seguimiento del desarrollo y su posterior mantenimiento, incluyendo como mínimo: Diagrama de componentes Diseño de Interfaces de Usuario Diagrama de Clases. Modelo de Datos. Mapeo del Diagrama de Clases al Modelo de Datos. Diagrama de secuencias: cuando la complejidad lo justifique. Especificaciones de Casos de Uso de Diseño. Especificaciones de Operaciones: cuando la complejidad lo justifique. Página 5 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Prototipación de las funcionalidades indicadas en el punto 1.4 del Anexo 1 Producto 2: Módulos de Historias Clínicas y Atenciones y Turnos Subproducto 1: Programación y testing de los módulos de Historias Clínicas, Atenciones y Turnos y ABMs de las tablas involucradas Programación de los módulos Historias Clínicas, Atenciones y Turnos y ABMs de las tablas involucradas. Documentación y ejecución de todos los casos de prueba funcionales y no funcionales, de integración, de stress y de performance con sus correspondientes resultados. Ultima versión actualizada de la documentación entregada en etapas anteriores. Subproducto 2: Implementación provisoria de los módulos de Historias Clínicas, Atenciones y Turnos y ABMs de las tablas involucradas Capacitación de usuarios pertenecientes al área del proyecto piloto indicada en punto 1.5 Anexo 1 para la implementación provisoria. La implementación de los módulos para la prueba usuaria y la realización de un paralelo. La transferencia tecnológica del desarrollo al personal técnico municipal. Capítulo del Manual de Usuario del Sistema correspondiente a los módulos implementados. Ultima versión actualizada de la documentación entregada en etapas anteriores. Subproducto 3: Implementación definitiva de los módulos de Historias Clínicas, Atenciones y Turnos y ABMs de las tablas involucradas La implementación definitiva de los módulos. La entrega del código fuente y objeto de lo desarrollado para asegurar la migración e implementación de los módulos en los otros Centros de Salud Municipales. Manual de Configuración e Instalación del Sistema. Ultima versión actualizada de la documentación entregada en etapas anteriores. Producto 3: Módulo de Farmacia Subproducto 1: Programación y testing del módulo de Farmacia y ABMs de las tablas involucradas Programación del módulo de Farmacia y ABMs de las tablas involucradas. Documentación y ejecución de todos los casos de prueba funcionales y no funcionales, de integración, de stress y de performance con sus correspondientes resultados. Ultima versión actualizada de la documentación entregada en etapas anteriores. Subproducto 2: Implementación provisoria del módulo de Farmacia y ABMs de las tablas involucradas Capacitación de usuarios pertenecientes al área del proyecto piloto indicada en punto 1.5 Anexo 1 para la implementación provisoria. La implementación de los módulos para la prueba usuaria y la realización de un paralelo. La transferencia tecnológica del desarrollo al personal técnico municipal. Capítulo del Manual de Usuario del Sistema correspondiente a los módulos implementados. Ultima versión actualizada de la documentación entregada en etapas anteriores. Subproducto 3: Implementación definitiva del módulo de Farmacia y ABMs de las tablas involucradas La implementación definitiva de los módulos. La entrega del código fuente y objeto de lo desarrollado para asegurar la migración e implementación de los módulos en los otros Centros de Salud Municipales. Ultima versión actualizada de la documentación entregada en etapas anteriores. Producto 4: Módulo de Estadística Subproducto 1: Programación y testing del módulo de Estadísticas y ABMs de las tablas involucradas Programación del módulo de Estadísticas y ABMs de las tablas involucradas. Documentación y ejecución de todos los casos de prueba funcionales y no funcionales, de integración, de stress y de performance con sus correspondientes resultados. Ultima versión actualizada de la documentación entregada en etapas anteriores. Subproducto 2: Implementación provisoria del módulo de Estadísticas y ABMs de las tablas involucradas Capacitación de usuarios pertenecientes al área del proyecto piloto indicada en punto 1.5 Anexo 1 para la implementación provisoria. La implementación de los módulos para la prueba usuaria y la realización de un paralelo. La transferencia tecnológica del desarrollo al personal técnico municipal. Capítulo del Manual de Usuario del Sistema correspondiente a los módulos implementados. Ultima versión actualizada de la documentación entregada en etapas anteriores. Subproducto 3: Implementación definitiva del módulo de Estadísticas y ABMs de las tablas involucradas La implementación definitiva de los módulos. La entrega del código fuente y objeto de lo desarrollado para asegurar la migración e implementación de los módulos en los otros Centros de Salud Municipales. Ultima versión actualizada de la documentación entregada en etapas anteriores. Página 6 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Producto 5: Cierre Este producto incluye: La entrega de las actualizaciones al código fuente (si las hubiese) de todo lo desarrollado, para asegurar el correcto funcionamiento y posterior mantenimiento del sistema. Manual de Usuario del Sistema completo Ultima versión actualizada de la documentación entregada en etapas anteriores. DEMOSTRACIÓN Y/O PRUEBA DE LA OFERTA La Municipalidad de Rosario, antes de la adjudicación, podrá solicitar información adicional o explicativa, o efectuar cualquier consulta sobre el material o configuraciones propuestas, y/o pedir una demostración o prueba a todas las firmas o a alguna en particular, acerca de la solución técnica ofertada, sin modificar la propuesta inicial. Las consultas y/o pruebas serán solicitadas con 5 días corridos de anticipación como mínimo. Si un oferente se niega o no cumple con la fecha y hora prevista para dar respuesta a las consultas y/o demostración y/o prueba será desestimado. Todos los gastos en que se incurra para llevar adelante la demostración o prueba estarán totalmente a cargo de los oferentes (incluyendo viáticos). PLAZO Y FORMA DE ENTREGA El plazo máximo para la ejecución de la totalidad de los trabajos es de diez (10) meses calendario. El plazo de entrega propuesto correspondiente a los distintos productos se detalla en la siguiente tabla. Sistema para APS Plazo de aceptación propuesto a partir del inicio del contrato Producto 1: Planificación y Diseño Subproducto 1 1 mes Subproducto 2 3 meses Producto 2: Módulos de Historia Clínicas y 5 meses Atenciones y Turnos Producto 3: Módulo de Farmacia 8 meses Producto 4: Módulo de Estadísticas 9 meses Producto 5: Cierre 10 meses Los plazos de aceptación son sugeridos dado que los mismos pueden redistribuirse sin que esto afecte la duración total del proyecto, respetando el orden de implementación de los módulos establecido en la Tabla anterior, y cumplimentando los criterios de aceptación fijados en el Anexo 4, (en el plazo máximo ofertado para cada producto/subproducto). Cualquier modificación a estos plazos solo podrá realizarse de común acuerdo entre las partes. El incumplimiento de los plazos y/o los criterios de aceptación antes referidos implicará la aplicación del sistema de penalidades establecidas en el Art. 9. PENALIDADES. FORMAS DE PAGO El Adjudicatario deberá presentar facturación por el Item 1) en 4 etapas: Etapas de Pago Porcentaje de Pago sobre el valor total adjudicado Producto 1: Planificación y Diseño Subproducto 1 Subproducto 2 Producto 2: Módulos de Historia Clínicas y Atenciones y Turnos Producto 3: Módulo de Farmacia Producto 4 y 5: Módulo de Estadísticas y Cierre 10% 15% 25% 30% 20% La fecha de factura no podrá ser anterior a la fecha de aprobación por escrito de Municipalidad para cada etapa/producto/subproducto. El mantenimiento, en caso de contratarse, será abonado mensualmente, previa conformidad dada por Municipalidad. El pago se realizará a los treinta (30) días corridos de la fecha de factura. Si las facturas no se encontraran en forma o no se adecuaran a las condiciones estipuladas, serán devueltas al Adjudicatario, quién deberá subsanar los errores o deficiencias y presentarlas nuevamente para su conformación. Los efectos de las dilaciones que se originen en estas circunstancias serán asumidos en forma exclusiva por el Adjudicatario, no dando derecho al cobro de Página 7 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud intereses o cualquier otro tipo de indemnización. Municipalidad descontará de cada factura las multas que se hubieren aplicado en cada período. La Tesorería General, previo al pago de cada factura deberá cumplimentar las previsiones establecidas en el decreto nro. 0736/01. CRITERIOS DE ADJUDICACION La adjudicación de la presente licitación se realizará a aquel oferente que habiendo cumplido con los requisitos de documentación solicitada, presente una propuesta que cumpla o supere satisfactoriamente la evaluación de las características técnicas, antecedentes presentados y pruebas (si hubiera) y tenga la mejor relación costo-calidad. Municipalidad podrá rechazar todas las ofertas, sin que esto dé derecho a reclamo alguno por parte de las firmas oferentes. En la evaluación de las ofertas se adoptarán las siguientes pautas: 1) Aspectos formales: sólo se evaluarán aquellas ofertas que cumplan cabalmente con los requisitos formales detallados en el presente pliego 2) Evaluación de calidad de las ofertas (sólo para las que cumplan con los requisitos señalados en el punto anterior): se realizará conforme a los parámetros y / o criterios que a continuación se exponen, asignándole a cada firma el puntaje correspondiente. RUBROS DE EVALUACIÓN ASPECTOS A EVALUAR ANTECEDENTES DE LA FIRMA PLAN, METODOLOGÍA, MODALIDAD Y CRONOGRAMA DE TRABAJO PROPUESTOS EQUIPO DE TRABAJO PROPUESTO PUNTAJE MAXIMO ( sobre 100) Antecedentes de los oferentes en la tecnología de desarrollo propuesta en Anexo 5. Antecedentes de los oferentes en desarrollo de sistemas con características similares o superiores en cuanto a temática, esfuerzo en hs/hombre, duración, etc. Presentación de certificaciones de calidad de sus procesos de desarrollo de software y/o productos o los planes del oferente para certificar calidad de sus procesos de desarrollo y/o productos. Soporte técnico local. Infraestructura interna de la firma. 20 Coherencia del cronograma de trabajo en función de tiempos, recursos y roles asignados. Menores plazos de ejecución de los distintos productos. Otras características propuestas que, de acuerdo a los evaluadores, superen las condiciones mínimas solicitadas en el presente pliego. Capacidad para identificar aspectos críticos del proyecto (detallados en el Plan de Riesgos del Anexo 7). 50 Antecedentes del personal en los roles asignados. Cantidad de personal afectado en función del plan de trabajo y cronograma propuesto. 30 Se considerarán de igual calidad las ofertas que alcancen una diferencia máxima de hasta 5 puntos respecto a la de mayor calidad NOTA: Para el caso de oferentes que presenten más de una alternativa, el análisis se hará para cada alternativa por separado. ANTECEDENTES DEL OFERENTE Mencionar los antecedentes del oferente respecto a desarrollos web transaccionales y/o respecto a desarrollos de sistemas en general en los últimos 5 años. Para cada antecedente que presente el oferente debe completarse la información requerida en Anexo 6. INFORMACIÓN A PRESENTAR PARA LA EVALUACIÓN TÉCNICA (EN SOBRE NRO. 2) Para obtener una correcta valorización será imprescindible que la oferta incluya características, especificaciones técnicas y todo otro detalle considerado de relevancia. En cuanto a la ejecución de los trabajos Se debe especificar lo siguiente: Cronograma propuesto de trabajo respetando los productos y tiempos de entrega solicitados en el pliego. Página 8 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Personal y roles asignados para dar cumplimiento al cronograma de trabajo. Datos específicos del personal asignado según información requerida en Anexo 2. Plan de Calidad y Plan de Testing a aplicar para el proyecto. Plan de riesgos según información requerida en Anexo 7. Todo aquello que el oferente considere necesario para demostrar su solvencia en todas las etapas que deberá desarrollar para cumplimentar los requerimientos del pliego. En cuanto al sistema aplicativo Se debe especificar lo siguiente: Detalle completo del entorno de desarrollo y software de base, teniendo en cuenta los requisitos del Anexo 5. Especificación de Arquitectura propuesta. En cuanto a capacitación Se debe especificar lo siguiente: Temario. Cantidad de horas que incluye. Material de apoyo a proveer a los asistentes. Nómina y antecedentes del personal de la empresa que esté a cargo de la misma. En cuanto a garantía y mantenimiento Se debe especificar lo siguiente: Tiempo de duración y características de las garantías ofrecidas, no debiendo ser ésta de menor alcance al solicitado en el Art. 19. GARANTÍA. Propuesta de mantenimiento durante la garantía y cuando finalice la misma contemplando como mínimo lo especificado en el Anexo 3. Datos específicos del personal asignado según información requerida en Anexo 2. Lista de teléfonos de soporte técnico. 6. INFORMACIÓN A PRESENTAR PARA LA EVALUACIÓN ECONÓMICA (EN SOBRE NRO. 3) Los oferentes deberán completar una planilla con el siguiente formato para cada Sistema Aplicativo propuesto (en caso de proponer más de uno): Costo total del Item 1 Costo del Item 2 detallando: Costo por hora de mantenimiento durante la vigencia de la garantía. Costo por hora de mantenimiento una vez vencida la garantía o fuera de las condiciones que cubre la misma o fuera del mantenimiento. Abono mensual de mantenimiento durante la vigencia de la garantía. Abono mensual de mantenimiento una vez vencida la garantía. Valor/hora para el desarrollo de nuevos requerimientos, dando los parámetros para poder estimar el tiempo necesario para el desarrollo de éstos. NOTA: Si el oferente desea cotizar software de base y/o módulos alternativos, deberá realizarlo separadamente de las cotizaciones solicitadas. GARANTÍA Los oferentes expresarán en sus ofertas los alcances de la garantía, debiendo asegurar el normal funcionamiento del sistema por el término de un año como mínimo, a partir de la aceptación de la implementación definitiva, del último producto entregado, por parte de Municipalidad. Durante ese lapso el proveedor adjudicado estará obligado a solucionar cualquier falla detectada en un módulo, sin costo alguno para Municipalidad, suministrando además toda la documentación referida a la misma. Si surgen errores tras la implementación definitiva de algún módulo, y mientras no se finalice la implementación de todo el sistema las correcciones quedarán a cargo del proveedor, debiendo las mismas cumplimentar lo detallado en Anexo 3. El Adjudicatario deberá resolver la falla en forma “definitiva” dentro de los 2 días hábiles de notificada la misma, caso contrario, se hará pasible de una sanción de acuerdo a lo establecido en el Art. 9. PENALIDADES. En todos los casos, el Adjudicatario correrá con el costo de horas del personal afectado, viáticos del mismo y cualquier gasto que se origine cuando la modificación no pueda hacerse en el domicilio de Municipalidad. RIESGOS “Municipalidad de Rosario sólo será responsable por los hechos o riesgos que la misma asuma expresamente. El Adjudicatario celebrará el contrato a su riesgo y ventura y responde por todos los hechos u obligaciones relativos a la prestación del servicio”. MODO Y LUGAR DE EJECUCIÓN DE LOS TRABAJOS a) Seguimiento del Cronograma de trabajo y programación de actividades. Página 9 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud El seguimiento de las tareas que conforman el Cronograma de trabajo; la programación de reuniones/entrevistas entre personal de Municipalidad y el adjudicatario y el monitoreo de los productos generados en cada etapa, estará a cargo de una Comisión de Seguimiento del Proyecto, integrada por: Personal de la Dirección General de Informática y de la Secretaria de Salud Pública. Dentro de los 10 días de firmado el contrato, la Comisión de Seguimiento aprobará un Cronograma de Trabajo Definitivo, al cual deberán ajustarse todas las actividades que se realicen en el marco del Contrato. Dicho cronograma deberá respetar los lineamientos generales contenidos en la Propuesta Técnica del Adjudicatario, incorporando aquellas adecuaciones consensuadas entre las partes para facilitar el desarrollo del Proyecto. b) Lugar y horarios de ejecución de los trabajos A los fines del desarrollo de las actividades previstas en el contrato, el oferente deberá contar con una oficina permanente en la ciudad de Rosario, durante todo el tiempo de su ejecución. En general, las tareas que el Adjudicatario desarrolle en el ámbito municipal deberán realizarse en el rango de 7 a 13 hs en días hábiles. Sin perjuicio de ello, las partes podrán acordar reuniones de trabajo / entrevistas por la tarde. En todos los casos, deberá garantizarse la coordinación previa de fecha, horario y lugar de las reuniones. Específicamente para las tareas del Producto 1/ Subproducto 1: Revisión y ampliación del material entregado por Municipalidad en Anexo 1, en caso de requerir consultas con los usuarios finales, éstas se canalizarán a través del personal de la Dir. Gral. de Informática asignado al proyecto. c) Remoción y/o sustitución del Personal Salvo que Municipalidad acuerde lo contrario, el adjudicatario no efectuará cambios en la composición del Personal asignado. Si fuese necesario sustituir a algún integrante, por cualquier motivo que escape al razonable control del Adjudicatario, éste lo reemplazará de inmediato por otra persona con calificaciones iguales o superiores a las de la persona reemplazada, previa aprobación de Municipalidad. En caso de realizarse una sustitución no acordada entre las partes, la misma dará lugar a Penalidades citadas en el Art. 9. PENALIDADES. Si Municipalidad tiene motivos razonables para estar insatisfecha con el desempeño de cualquier integrante del Personal, el Adjudicatario lo reemplazará por otra persona cuya idoneidad y experiencia sean aceptables para la misma. El Adjudicatario no podrá reclamar el reembolso de ningún gasto adicional resultante de la remoción y/o sustitución de algún integrante del Personal, o inherente a ésta. CAUSALES DE RESCISIÓN DE LA ADJUDICACIÓN IMPUTABLES AL ADJUDICATARIO Son causales de rescisión las siguientes: Aplicación reiterada de penalidades establecidas en Art. 9. PENALIDADES. Incumplimiento del Art. 13. PLAZO Y FORMA DE ENTREGA. Reiterada incapacidad profesional de los técnicos responsables del contrato de mantenimiento. Reiterada desatención a consultas del personal técnico y/o usuarios de Municipalidad. Falta de respuesta en los plazos citados en el Anexo 3-Inc.3.4. PEDIDO DE ACLARACIONES Y CONSULTAS Toda aclaración técnica con respecto a productos y servicios solicitados deberán ser requeridos a la Dirección de Informática de la Municipalidad de Rosario, TE.: 0341-4802251/5/6. Además se podrá consultar previo acuerdo 48 horas antes, la siguiente documentación preliminar: Diagrama de casos de uso Especificación de casos de uso de análisis Modelo de Datos Diseño de Interfaces de Usuario ADICIONALES En caso que durante el desarrollo del Producto 1 surjan nuevos casos de uso, que impliquen una mayor funcionalidad de los módulos licitados, se podrá acordar una ampliación del contrato, la cual no podrá exceder el 10% del monto de adjudicación total. Para ello el Adjudicatario deberá presentar formalmente los esfuerzos, tiempos y recursos involucrados que demande dicha ampliación y Municipalidad podrá aceptarla o recharzarla. A los fines del cálculo de los adicionales, se tomará como base el valor/hora cotizado en la respectiva Propuesta Económica, tomando como tope los señalados en el primer párrafo. Bajo ningún aspecto se aceptará como ampliación aquellos cambios que sugiera Municipalidad para introducir mejoras al diseño o calidad de la solución propuesta por el Adjudicatario, ni todo aquello que puede contribuir a superar los criterios de calidad exigidos. Página 10 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud ITEMS A COTIZAR 1) ITEM 1 - Sistema Aplicativo de Atención Primaria de la Salud que cumpla con los requerimientos detallados en Anexo 1 y Anexo 5. 2) ITEM 2 – OPCIONAL: Servicio de mantenimiento según características que se detallan en Anexo 3. Página 11 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud ANEXO 1: SISTEMA APLICATIVO 1.1 AREAS INVOLUCRADAS Areas Secretaría de Salud Pública Atención Primaria de la Salud (A.P.S) Farmacia Central Dirección de Salud Bucal Programa de Inmunizaciones Centros de Salud (CS) Dirección General de Informática Centro Informático Local de la Secretaría de Salud Pública Hospitales Municipales 1.2 REQUERIMIENTOS FUNCIONALES DEL SISTEMA A OFERTAR El oferente deberá ofertar un sistema que permita la registración y el seguimiento de todos los movimientos de cada paciente en la red de salud municipal: turnos, entregas de medicamentos, internaciones, urgencias, prácticas, programas, tratamientos prolongados e interconsultas. LISTADO DE REQUERIMIENTOS Nº 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. Descripción Módulo: Historias Clínicas Registrar pacientes con y sin Historias Clínicas Individuales (HCIs). Unificar HCIs. La HC debe ser única para todo el sistema de la Red Municipal (hospitalaria y APS). Agrupar pacientes en HC´s familiares (HCFs) y mantener la historia de cambios de integrantes a nivel individual. Emitir carnets de HCIs. Detectar pacientes con Obra Social. Registrar adscripción de pacientes. Controlar distribución de pacientes entre los distintos Equipos de Referencia del CS. Depurar periódicamente las HCIs (por inactividad o duplicidad). Módulo: Atenciones y Turnos Registrar personal de cada CS. Mantener Equipos de Referencia. Administrar agendas de profesionales. Administrar turnos en los CS. Posibilitar la reserva on-line desde los CS de turnos en otros efectores de salud (hospitales, CEMAR u otros CS). Emitir planilla diaria de atenciones. Registrar atenciones de todos los servicios de los CS a pacientes con y sin HCIs. Registrar resultados de algunas prácticas (ej: PAPs). Registrar internaciones de pacientes tramitadas desde los CS. Controlar asistencia de pacientes. Controlar funcionamiento de los Equipos de Referencia y productividad de los profesionales. Controlar cumplimiento del calendario de vacunación. Módulo: Farmacia Utilizar la clasificación internacional ATC (Anatómica, Terapéutica y Química) para identificar los medicamentos y vacunas. Administrar pedidos de los CS a los Centros de Distribución (Farmacia Central, Dirección de Salud Bucal, Programa de Inmunizaciones). Administrar pedidos de los Centros de Distribución a sus proveedores (Compras, Convenios con Laboratorios/Provincia, etc.). Registrar ingreso de insumos a nivel central para su posterior distribución a los CS. Registrar ingreso de insumos a los CS. Administrar stock de medicamentos y descartables en los CS. Registrar entregas de medicamentos a pacientes (del CS, con y sin HCIs o externos al CS). Administrar tratamientos prolongados (Protocolos de medicamentos especiales y Programas: Procreación Responsable, Materno Infantil, etc.). Registrar distribución de insumos en sectores del CS. Registrar salidas de insumos por excepción, préstamo o consumo directo (Odontología). Controlar consumo de medicamentos por diagnóstico y tipo de medicamento. Controlar cumplimiento y abandono de tratamientos prolongados. Controlar demanda insatisfecha. Generar informes de consumo de medicamentos por programa. Módulo: Estadística Página 12 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud 35. 36. 37. 38. 39. 40. 41. Obtener informes detallados o resumidos (indicadores) de rendimiento según los criterios ingresados. Obtener informes detallados o resumidos (indicadores) de producción según los criterios ingresados. Obtener informes detallados o resumidos (indicadores) de cobertura según los criterios ingresados. Obtener informes detallados o resumidos (indicadores) de recursos según los criterios ingresados. Obtener informes detallados o resumidos (indicadores) de costos según los criterios ingresados. Permitir la portabilidad de los informes estadísticos, en los distintos niveles de desagregación solicitados. Archivos para ser manejados por Planilla de Calculo, Procesador de Texto, pdf, además de las salidas por pantalla e impresoras. Permitir configurar tableros de control de indicadores para los distintos niveles ejecutivos. Generales 42. 43. 44. 45. 46. 47. 48. 49. Permitir realizar Altas, Bajas, Modificaciones y Consultas de las tablas maestras que surjan por cada módulo. Centralizar la carga de determinadas tablas maestras que precisan consenso general (Medicamentos, Profesionales, Diagnósticos, Prácticas, Tratamientos, etc.). Manejar diferentes niveles de acceso a la información (CS, distrito o total) para los distintos actores del sistema. Utilizar bajas lógicas en los casos que así se requieran Alta seguridad en el manejo de la información de los individuos y sus intervenciones. Se maneja información confidencial. Las interfaces de usuario deberán estar diseñadas considerando las diferentes habilidades de los mismos y ser fácilmente operables para agilizar la atención al público. Soportar concurrencia (90 PC’s aproximadamente) dado que la información va a ser utilizada por todos los Centros de Salud y dependencias de la Secretaría de Salud Pública. Los tiempos de respuesta deben ser razonables considerando que se trabaja con Atención al Público. ABSTRACT MÓDULO: HISTORIAS CLÍNICAS El sistema registrará pacientes que pueden o no tener HCIs. Las HCIs deberán ser únicas en toda la red municipal de salud (APS y hospitales). Para esto, deberán incluirse todos los controles posibles a fin de minimizar la duplicidad de HCIs. Por cada paciente se registrarán los datos personales (apellido, nombre, apellido materno, fecha de nacimiento o edad a la fecha de la consulta (para calcular una fecha de nacimiento aproximada), sexo y tipo y nro de documento), obra social (si no la declara el paciente o está ya cargada en el sistema hospitalario, se podrá capturar este dato del padrón de Obras Sociales), fecha de apertura de HCI, equipo de referencia, médico de cabecera y fecha de primera consulta. Los pacientes pueden o no estar adscriptos. Sobre los no adscriptos se llevará un control para intentar reducir su cantidad, fomentando el proceso de adscripción. Los pacientes se irán agrupando en Historias Clínicas Familiares (HCFs). Las HCFs se identificarán con el Centro de Salud (CS) y un número secuencial propio (el mismo se inicializará con el último número de HCF correspondiente al archivo físico al momento de implementar el sistema en cada CS). Además deberá registrarse la historia de los cambios del grupo familiar a nivel de integrantes: por ejemplo, un integrante forma una nueva familia y por lo tanto deja de pertenecer al grupo familiar asignado originalmente, o fallece, etc. A nivel de HCF se registrarán datos generales, como ser: CS, microárea, domicilio y/o referencia geográfica, teléfono, fecha de apertura. De cada HCF será posible determinar la seccional policial y el distrito municipal al que pertenece, a partir de su domicilio mediante las rutinas de georeferenciación. A cada paciente con HCI del CS se le emitirá un carnet personal en el que constará su nro. de HC Familiar e Individual, Centro de Salud, Equipo de Referencia, nombre y apellido, fecha de nacimiento y fecha de apertura. Existirán procesos de depuración de HCIs: Uno periódico que pasará a una categoría de “Inactivas” a las HCIs que no hayan tenido movimientos en los últimos 5 años, y dará de baja las que hayan estado en esta situación en los pasados 10 años (guardándolas como información histórica). Esta depuración del sistema deberá ir acompañada obviamente por la correspondiente reorganización y depuración de los archivos físicos. Otro cuyo objetivo será la unificación de HCIs al detectarse duplicaciones. De cada paciente se registrarán en el resto de los módulos de APS (Farmacia, Atenciones y Turnos) y en el sistema hospitalario y del CEMAR todos los movimientos dentro de la red de salud municipal (turnos, entregas de medicamentos, urgencias, internaciones, prácticas, programas, tratamientos prolongados, interconsultas). Página 13 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud MÓDULO: ATENCIONES Y TURNOS El sistema permitirá: Mantener los “Equipos de Referencia” (ER): Los ER son equipos de profesionales formados por médicos y enfermeros que tienen a su cargo una determinada cantidad de pacientes. Se deberá intentar mantener equilibrada la distribución de pacientes entre los distintos equipos de referencia de cada CS. De cada ER se tendrá registro de su formación y cambios, por lo que se prevé llevar un histórico de la composición de los E.R. en el transcurso del tiempo. Si un profesional deja de trabajar en el CS o abandona el ER, existen 2 opciones respecto a sus pacientes adscriptos: todos sus pacientes quedan sin médico de cabecera y posteriormente cada uno de ellos elige uno nuevo del mismo ER o cambia de ER; o el paquete completo de pacientes adscriptos a ese profesional es trasladado a un nuevo profesional que tome el lugar del anterior dentro del ER. Generar agenda de turnos por servicio y por profesional: El sistema generará diariamente la agenda de los profesionales que trabajen con turnos programados según un horizonte de tiempo definido por efector y especialidad. Cada profesional podrá determinar el tiempo que dedicará a su consulta (10, 15, 20 minutos, etc), siendo este un tiempo promedio de la duración de sus atenciones. Si en algunos casos se extienden o en otros son más cortas, se irán compensando unas con otras. En resumen, las duraciones de los turnos se definirán según efector, profesional, servicio y especialidad. Aclaración: una persona puede trabajar en distintos efectores, teniendo agendas distintas por cada efector. El sistema deberá controlar que no haya superposición horaria entre las agendas. Registrar las excepciones horarias del personal: Para poder visualizar en la agenda las distintas actividades y el tiempo que le dedican los profesionales a otras tareas, estas se registrarán como excepciones en las agendas, pudiendo así determinar: Profesional, fecha, hora desde, hora hasta, Tipo de Excepción, Observación. Los tipos de excepciones puede ser por Ej.: Licencia Anual Ordinaria, Congreso, Trabajo en Terreno, Reunión, Trabajo con Equipo, Visita a escuela, Práctica Grupal, etc. Este manejo de excepciones puede ser extensible a cualquier personal del CS (médicos, psicólogos, odontólogos, enfermeros, asistentes sociales, administrativos, etc.). Asignar turnos de profesionales del CS: Se priorizará siempre que el profesional que atienda al paciente sea de su ER. Al dar un turno se consultará el padrón de Obras Sociales para que en caso de detectar que el paciente tiene Obra Social, quede registrado este dato en el sistema y sea accesible desde cualquier consulta (planilla diaria de atenciones, al dar un nuevo turno, etc.). Se emitirá un comprobante del turno otorgado. Se van a hacer controles de los pacientes que no concurren a las consultas reiteradas veces para que el ER pueda considerar otras formas de trabajo con estos pacientes. Manejo de “sobreturnos”: Ante estas consultas no programadas, puede ocurrir que el paciente pase primero por administración o vaya directamente al consultorio del profesional. Por esto es que no se registrarán los “sobreturnos” como turnos programados y simplemente se registrará la atención que el profesional agregó al final de su planilla diaria de atenciones. Anular un turno del CS: Este turno queda libre para ser tomado por otro paciente. Consultar, asignar y cancelar turnos en otros efectores (hospitales, CEMAR u otros CS): Desde cada efector que utilice el sistema se podrán asignar turnos para prácticas, consultas con especialistas o con el equipo de referencia del paciente en otros efectores de la red. Existe un cupo de turnos por especialidad asignado a cada efector en un período de tiempo determinado. Cada efector puede reservar on-line los turnos que tiene asignados con una determinada cantidad de días de anticipación (ej.: 2 días). Pasado este plazo el turno queda a disposición pudiendo ser tomado para otro paciente por el efector de origen. La anulación de estos turnos sólo podrá ser realizada por personal del efector que hizo la asignación o alguien autorizado. Ejs: Los hospitales o el CEMAR podrán asignar desde sus PC turnos para los ER de los centros de salud. Los CS podrán reservar turnos para prácticas en el CEMAR. Los CS podrán reservar turnos para especialistas de otro CS. Registrar atenciones de pacientes: Diariamente el administrativo registrará en el sistema las planillas de atenciones que los profesionales completan durante las consultas (turnos médicos, odontológicos, psicológicos, prácticas de enfermería, atenciones en guardia y cualquier otro tipo de atenciones). De cada atención se registrará: Página 14 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud turno asociado, en caso de tratarse de un turno programado paciente, fecha, hora y profesional para los demás tipos de atenciones. diagnóstico principal y otros diagnósticos los cuales serán códigos del CIE10. Los profesionales escribirán directamente el código en la planilla manual (en general no son más de 30 los que se utilizan por lo tanto los profesionales están familiarizados con los mismos). prácticas (admitirán únicamente códigos) y nros de muestra en los casos que corresponda (Ej.: tomas de muestras para análisis). tratamientos (admitirán únicamente códigos). fecha de próxima consulta (tentativa, el turno real depende de la solicitud del paciente). derivación: en caso que se derive al paciente a otro efector o profesional, se registrará el efector y el servicio, especialidad y/o el profesional al que se deriva. Odontología utilizará la misma planilla de atenciones, registrando además junto al diagnóstico (que en este caso se denomina “prestación”), el nro. de pieza dentaria sobre la que se realizó la atención, en los casos que correspondan. La aplicación de vacunas en enfermería se va a registrar en una planilla diferente, en la que se va a indicar paciente, vacuna y dosis colocada. El sistema estará preparado para que este ingreso se haga on-line al momento de realizar la atención, para que por Ej., en la guardia puedan registrarlo directamente los médicos, y en un futuro, si fuera posible contar con puestos de trabajo en cada consultorio, lo pudiera hacer el profesional durante la atención. Registrar internaciones de pacientes tramitadas desde el CS: Los pedidos de internación de pacientes desde los CS se manejan con el Sistema Integral de Emergencia Sanitaria (SIES), quedando la información del traslado y la internación registrada en el sistema del SIES, pero habrá opción de registrar en el sistema de APS determinados datos como ser: fecha y hora de la solicitud, efectores a los que se solicitó la internación y no la aceptaron, razón del rechazo y datos de la persona con quien se tramitó y efector donde finalmente se internó al paciente. Registrar resultados de algunas prácticas: Algunas prácticas pueden llevar un seguimiento posterior (Ej.: la toma de muestras para PAPs, de la que interesa conocer su resultado). Esta información podrá obtenerse del informe que el paciente traiga en su próxima consulta o de un informe que se reciba desde el efector que la realice. Se contemplará la posibilidad de que a futuro se puedan obtener los resultados de análisis hechos en el laboratorio del CEMAR. Se podrá acceder a estos resultados mediante el nro. de muestra que se registra asociado a la práctica y que es impreso en la etiqueta de la muestra que se envía desde el centro. Controles que posibilitará el sistema: A partir de toda la información registrada en el sistema, podrán obtenerse informes que permitan controlar, entre otras cosas: Asistencia de los pacientes a su “primera consulta” en caso que haya sido acordada. Asistencia a consultas programadas. Asistencia a “próximas consultas” según registro de cada atención. Cumplimiento del calendario de vacunación. Pacientes que se atienden por fuera de su ER. Productividad de profesionales. MÓDULO: FARMACIA Codificación de medicamentos: Se adoptará la clasificación internacional ATC (Clasificación Anatómica, Terapéutica y Química) de la OMS, como codificación única de medicamentos para el sistema. En esta clasificación, las drogas son divididas dentro de diferentes grupos de acuerdo al órgano o sistema sobre el que ellas actúan y sus propiedades químicas, farmacológicas y terapéuticas. Se clasifican en 5 diferentes niveles, los cuales se dividen dentro de 14 grupos principales (1º nivel), y dentro de cada uno de ellos, en dos grupos terapéuticos / farmacológicos (niveles 2º y 3º). El 4º nivel es un subgrupo farmacológico / terapéutico / químico y el 5º nivel corresponde a la sustancia química. La clasificación ATC aplica hasta 7 caracteres, permitiendo identificar la monodroga. A esta clasificación hay que agregarle un código secuencial asociado a la forma farmacéutica (Ej. comprimidos, suspensión, ampollas de 100 ml, de 400 Mg., etc.) La clasificación ATC comprende en el grupo J las vacunas. La dosis (mono o multidosis) se define en el código de forma farmacológica. Para las búsquedas de medicamentos en el sistema se deberá permitir tanto el ingreso del código completo y la búsqueda por descripción, como la búsqueda del mismo por los distintos niveles de la clasificación hasta llegar al 5to nivel en el que quedará definido el código e identificada la monodroga. Ej.: Página 15 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Clasificación completa del Ibuprofeno (ilustra la estructura del código ATC): Nivel 1º Nivel (Grupo anatómico principal) 2º Nivel (Grupo terapéutico principal) 3º Nivel (Subgrupo terapéutico/ farmacológico) 4º Nivel (Subgrupo terapéutico/farmacológico/químico) 5º Nivel (sustancia química) Tipo de Da- Código to Letra M Número de 2 cifras Letra Letra Número de 2 cifras Descripción Sistema músculo-esquelético M01 Antiinflamatorios y antirreumáticos M01A Antiinflamatorios y antirreumáticos no esteroides M01AE Derivados del ácido propiónico M01AE0 Ibuprofeno 1 Respecto a la forma farmacéutica: Monodroga IBUPROFENO Código de Monodroga M01AE01 Código Descripción 1 2 3 400 Mg. Ampolla 400 Mg. Comprimido 20 Mg. / Ml Suspensión El sistema permitirá: Emitir pedidos de insumos: Desde los CS a Farmacia Central, Dirección de Salud Bucal o Programa de Inmunizaciones: Según el tipo de pedido (Medicamentos Generales, Especiales, Vacunas o Insumos de Odontología) se calcula la cantidad a pedir insumo en base a la existencia actual, el consumo del último mes y en los casos que corresponda (medicamentos especiales y vacunas) la proyección de necesidades futuras. Se controlará que esta cantidad no sea inferior al punto mínimo de reposición asociado al efector por insumo. Observaciones: el servicio de Odontología de cada CS deberá declarar mensualmente el consumo de insumos (dado que los mismos no tienen otro tipo de registro de salida), con lo que se descontará esa cantidad del stock y así podrá generarse el pedido. Desde Farmacia Central o Dirección de Salud Bucal a Compras: Estos pedidos se arman sumando las cantidades por insumo de los pedidos realizados por los CS, y ajustando las cantidades que consideren necesarias. Desde Farmacia Central al LEM: Carga del convenio periódico con el LEM detallando insumos y cantidades convenidas. Este convenio existirá en el sistema como un pedido al proveedor LEM. Desde Programa de Inmunizaciones a la Provincia: De acuerdo al stock actual, consumo del último mes y la proyección de necesidades futuras de cada CS efectúan el pedido general de vacunas. Gestionar compras y recepciones de insumos en los Centros de Distribución: Mediante circuito de compras: Ante los pedidos recibidos, Compras efectúa las licitaciones, que una vez adjudicadas dan origen a las órdenes de compra que se registrarán en el sistema con los siguientes datos: proveedor (Laboratorio o Droguería), nombre comercial, insumo, cantidad y precio unitario. Al llegar la mercadería (pedido completo o entrega parcial) a Farmacia Central o a la Dirección de Salud Bucal junto a los correspondientes remitos, se ingresan estos al sistema completando la información con lote y vencimiento de cada insumo y confirmando la cantidad recibida. Compras directas: Son compras del día, de hasta $300, que no generan pedidos, ni Ordenes de Compra. En estos casos hay que cargar el remito o factura con todos los datos necesarios (proveedor, insumo, nombre comercial, lote, vencimiento, cantidad y precio unitario). Otros ingresos generales: Ej.: Recepciones de medicamentos provenientes del LEM, Vacunas y Leche con Hierro desde la Provincia, etc). Se registrará origen, insumo, nombre comercial, lote, vencimiento y cantidad. Página 16 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Control de pedidos pendientes: Al cargar todo el circuito de compras, los pedidos de Farmacia Central y de la Dirección de Salud Bucal quedarán asociados a las Órdenes de Compra y estas a su vez, a los Remitos de los Proveedores, con lo cual se podrán conocer las entregas de insumos aún no completadas para un mejor seguimiento de las mismas. En el caso de los Programas, también se podrán conocer los pedidos pendientes, comparando el convenio periódico con las cantidades entregadas. Registrar ingreso de insumos a los Centros de Salud: Tanto los que vengan de un Centro de Distribución con el remito como otro tipo de ingresos (donaciones, devoluciones, Programa REMEDIAR, etc) serán registrados en el sistema y en ese momento se va a actualizar el stock de cada insumo, discriminando los lotes con distintas fechas de vencimiento. En el caso de los remitos de Farmacia Central, Odontología o Inmunizaciones, ingresando los datos de identificación del remito, va a capturarse directamente el detalle del envío para no hacer doble ingreso de información (ya se tiene identificado: origen, insumo, lote, vencimiento, nombre comercial y precio unitario). Observación: En estos envíos de insumos entre efectores, se debe manejar el concepto de “stock en tránsito”. Esto permite descontar del stock del efector que entrega insumos y no sumarlos al stock que debiera recibirlos hasta tanto este último no confirme y apruebe la recepción de los mismos, permitiéndole efectuar las observaciones pertinentes. En los otros tipos de ingresos que llegan directamente al CS debe contemplarse la posibilidad de que no se carguen todos los datos del medicamento (nombre comercial, laboratorio, lote, vencimiento, etc.). Registrar entregas de medicamentos a pacientes: Las entregas pueden hacerse: Ante la presentación de un paciente con carnet de tratamiento prolongado (con Protocolo de medicamentos especiales o no), se deberán controlar los datos y registrar la cantidad entregada y la fecha. La primera vez que se presenta el paciente con el carnet confeccionado por el médico, se hace la carga inicial del plan de entregas (si existe mercadería en stock se la entrega), y comienza a formar parte del circuito de crónicos hasta que se cumpla la fecha de próxima consulta. Observaciones: Para poder hacer entrega de un medicamento especial, tiene que estar autorizado el protocolo correspondiente. Esta verificación la hace el farmacéutico antes de proceder a la entrega del medicamento. Por presentación de un paciente (con o sin HCI) con una receta de un médico del CS. Para estos casos se van a poder registrar todas las recetas según las cuales se hacen las entregas, registrando paciente, profesional, medicamento, posología, cantidad recetada y cantidad entregada. Una 3era situación en que se entregan medicamentos es a pacientes externos al CS (de CS provinciales u otros efectores) que traen recetas. En estos casos se registra la entrega a la persona (sin generarle HCI, aunque de todos modos se busca si tiene HCI en la red municipal de salud), y dejando asentado de que efector es la receta. Observaciones: En cada entrega, el sistema deberá determinar en forma automática los datos del insumo entregado (origen (proveedor o programa), lote, vencimiento) basándose siempre en el criterio de entregar primero lo que tiene vencimiento más próximo y tras esa clasificación, manejar prioridades según los orígenes de los insumos (ej: prioridad de medicamentos recibidos de programa REMEDIAR). Opciones de implementación: Esto puede llegar a hacerse on-line, al momento de estar haciendo las entregas, en las farmacias que vayan a disponer de una PC y donde los recursos humanos sean suficientes para afrontar esta tarea. Una segunda opción sería que se llenara una planilla diaria de entregas en farmacia y al final del día un administrativo fuera el encargado de hacer la carga. Registrar entregas de insumos (principalmente descartables) a distintos sectores del CS: Se registrará fecha, sector, insumo y cantidad entregada. En ese momento se descuenta la cantidad entregada del stock del CS ya que una vez en el sector destino, el consumo de estos insumos no se registra a nivel individual. Registrar préstamos de medicamentos a otros CS: En los casos en que se envían medicamentos a otros CS se registra este movimiento descontando la cantidad enviada del stock del CS. El CS que recibe el préstamo lo registra como un ingreso por préstamo. Registrar salidas de insumos por motivos excepcionales: Página 17 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud En casos de deshecho de insumos en general por pérdida de cadena de frío, vencimiento, robo, roturas en tránsito, etc. Deberá registrarse fecha, motivo, insumo y cantidad a descontar del stock. Registrar y controlar la autorización de protocolos de medicamentos especiales: Los tratamientos que requieren autorización (protocolos de medicamentos especiales), se cargan en el CS detallando HCI, profesional, diagnóstico/s, medicamento prescripto, posología, cantidad y duración del tratamiento. En el CEMAR (Auditoría de Farmacia o Comisión de Medicamentos) se analiza cada protocolo y se autoriza o no. Sólo los autorizados podrán proseguir el trámite de entrega al paciente. Se podrán consultar los protocolos autorizados o no. Controles que posibilitará el sistema: Al registrar las entregas de medicamentos a nivel de paciente, serán posibles los siguientes controles: Consultar entregas de medicamentos a pacientes en distintos efectores de la red municipal para controlar posibles retiros duplicados. Cumplimiento y abandono de tratamientos prolongados. Demanda insatisfecha. Consumo de medicamentos por programa, por diagnóstico, según clasificación ATC. etc. MÓDULO: ESTADISTICA Los indicadores que se proponen en el presente módulo tienen como finalidad esencial conformar un componente de monitoreo y evaluación acerca de los procesos de atención en los efectores de salud y de los resultados/impacto logrados en la población bajo responsabilidad del sistema. Deben cumplir con la condición de ser útiles para la toma de decisiones. La veracidad y utilidad de estos indicadores dependerá en forma directa de la calidad de la información que se ingrese al sistema en el resto de los módulos. Se requiere que puedan ser valorados en distintos niveles de agregación, es decir tanto a nivel de un efector particular como tomando como unidad de análisis varios efectores de salud, por ejemplo los ubicados en un mismo distrito del municipio o a nivel global involucrando a todos los efectores pertenecientes al sistema en cuestión. El modelo de análisis que se requiere es el diseño de indicadores que den cuenta de la producción, el rendimiento, la cobertura, cumplimiento de metas, los recursos y el costo. Se podrán pedir informes detallados o resumidos (totales, porcentajes y/o razones) que contengan los indicadores en valores absolutos o relativos según diversos criterios y desagregaciones (expuestos en la tabla de la siguiente página) y las respectivas definiciones de cada uno de ellos. Los criterios y desagregaciones que se ponen en juego para el cálculo de los indicadores pueden ser solicitados en forma exclusiva o en diferentes y variadas combinaciones. Además a partir de la construcción de estos indicadores que denominamos “básicos” se pretende que el usuario pueda libremente construir sus propios indicadores a partir de relacionar en cocientes (porcentajes o razones) los indicadores básicos. Es importante destacar que en el futuro se prevé integrar al cálculo de los indicadores, información obtenida de otros sistemas que integran la red de salud del municipio (hospitales, laboratorio, etc.). Por lo tanto es necesario que el diseño de este módulo sea lo suficientemente flexible para posibilitar esta integración futura. Página 18 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. Nivel de agregación Período (Rango de fechas) Servicio Especialidad Profesional Edad y sexo Adscriptos o no adscriptos Diagnósticos según codificación CIE 10 Diagnósticos agrupados en capítulos de CIE 10 Diagnósticos agrupados en subcapítulos de CIE 10 Consulta nueva o repetida (asociado al año calendario) Resultado de consulta: derivación ambulatoria, derivación a internación o resuelto. Práctica Tipo de tratamiento Cobertura de atención médica de los beneficiarios Procedencia de los beneficiarios (Domicilio, Microárea, Efector, Seccional Policial, Distrito, General) Beneficiarios nuevos o existentes (referido al alta del paciente) Edad a la fecha de captación Insumos (monodroga con forma farmacéutica o <> niveles ATC) Programa Tipo de tratamiento prolongado Por receta / Por tratamiento Vacuna Dosis Calendario de vacunación cumplido o no cumplido Efector Unidad de tiempo Servicio Especialidad Profesional edad y sexo Adscriptos o no adscriptos Diagnósticos según codificación CIE 10 Diagnósticos agrupados en capítulos de CIE 10 Diagnósticos agrupados en subcapítulos de CIE 10 Primera vez o ulterior (asociado al diagnóstico) Tipo de diagnóstico (Principal, Secundario, etc...) Consulta nueva o repetida (asociado al año calendario) Resultado de consulta: derivación ambulatoria, derivación a internación o resuelto. Práctica Tipo de tratamiento Cobertura de atención médica de los beneficiarios Procedencia de los beneficiarios (Domicilio, Microárea, Efector, Seccional Policial, Distrito, General) Beneficiarios nuevos o existentes (referido al alta del paciente) Edad a la fecha de captación Insumos (monodroga con forma farmacéutica o <> niveles ATC) Programa Tipo de tratamiento prolongado Por receta / Por tratamiento Vacuna Dosis Calendario de vacunación cumplido o no cumplido Página 19 de 36 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x Recursos / Costos Horas de RRHH Insumos de farmacia x x x x x x x x x x x x x Familias x x x x x x x x x x x x x Cobertura / cumplimiento de metas Beneficiarios Beneficiarios activos Prácticas 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Desagregaciones Consultas Criterios Aplicación de vacunas Producción y Rendimiento x x x x x x x x x x x x x x x x x x x x x x Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Aclaraciones: Todos los porcentajes y razones deben referir a un período determinado, tanto en el numerador como en el denominador. Los informes en cuyo criterio de búsqueda se solicite la edad, deben permitir ingresar un rango específico o basarse en la clasificación de edad provista por el Censo de Población. A continuación se citan algunos ejemplos de los indicadores a calcular: Producción y rendimiento Consultas Total de consultas asociado a un diagnóstico (primera vez o ulterior). Discriminar frecuencia según diagnóstico y tipo de diagnóstico (Principal, secundario, etc) Porcentajes de consultas según edad y sexo (Total de consultas por edad o rango de edad y sexo / total de consultas X 100) Total de consultas por tipo de cobertura según categoría de institución Prácticas Total de prácticas. Mostrar el tipo de prestación/prácticas con la frecuencia Total de prácticas para cierto diagnóstico. Discriminar frecuencia por diagnóstico según se trate de diagnóstico principal, secundario, etc. Razón de prácticas por tipo de cobertura e institución (Total de prácticas / total prácticas por tipo de cobertura e institución) Aplicaciones de vacunas Total de vacunas aplicadas según dosis y grupo etáreo Cobertura de vacunación (Total de beneficiarios con calendario vacunación cumplido / Total de beneficiarios adscriptos/ no adscriptos) Cobertura y cumplimiento de metas Beneficiarios (activos o todos) Total de beneficiarios activos por cierto diagnóstico. Discriminar frecuencia según diagnóstico y tipo de diagnóstico (Principal, secundario, terciario, etc) Total de beneficiarios por tipo de consultas nuevas y repetidas Desagregar por edad y sexo Prevalencia diagnóstica de la población adscripta ( Total de beneficiarios según tipo de diagnóstico / Total de adscriptos) Total de beneficiarios derivados a internación según tipo de diagnóstico Familias Total de familias por efector Total de familias por seccional policial. Recursos / Costos Horas de RRHH Total de horas contratadas por servicio, especialidad, profesional. Promedio de consultas por hora por servicio, especialidad, profesional (Total de consultas por servicio, especialidad, profesional / Total de horas por servicio, especialidad, profesional) Promedio de prácticas por hora por profesional (Total de prácticas por profesional / Total de horas por profesional) Insumos de farmacia Total de insumos entregados a beneficiarios (adscriptos/ no adscriptos) por receta Total de insumos entregados a beneficiarios adscriptos por programa Total de insumos entregados a beneficiarios adscriptos por tipo de tratamiento Total de insumos entregados por efector. A partir de la valorización de los recursos (de farmacia o las horas de RRHH) podrán obtenerse los costos totales asociados a los indicadores referentes a Recursos. Ejemplos: Valor total de horas contratadas por servicio, especialidad, profesional. Valor promedio de la consulta por servicio, especialidad, profesional Valor promedio de cada práctica Valor total de insumos entregados a beneficiarios (adscriptos/ no adscriptos) por receta Valor total de insumos entregados a beneficiarios adscriptos por programa Página 20 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Valor total de insumos entregados a beneficiarios adscriptos por tipo de tratamiento Indicadores que surgen como combinación de los denominados “básicos” Ejemplos: Razón de consultas según captación de beneficiarios (Total de consultas repetidas / Total de consultas nuevas) Promedio de consultas por beneficiario (Total de consultas / Total de beneficiarios) Razón de prácticas realizadas a beneficiarios según tengan o no cobertura (Total de prácticas a beneficiarios sin cobertura / Total de prácticas con cobertura) Prácticas por consultas (Total de consultas realizadas (Primera vez / Ulterior) / Total de prácticas) Razón de beneficiarios (Total de beneficiarios adscriptos / Total de beneficiarios no adscriptos) Porcentaje de beneficiarios captados en el año (total de beneficiario captados en el año / Total de beneficiarios adscriptos) Concentración de consultas por beneficiario por diagnóstico (Total de consultas por diagnóstico / Total de beneficiarios captados con tal diagnóstico) Captación de recién nacidos antes del primer mes de vida (Total de recién nacidos captados antes del primer mes de vida/ Total de menores de 1 año captados) Total de beneficiarios de prácticas por diagnóstico (Total de prácticas según diagnóstico/ total de beneficiarios). Desagregar por edad, sexo, profesional derivante, servicio, efector, procedencia) Porcentaje de beneficiarios activos ( Total de consultas / total de beneficiarios activos X 100) Índice de resolutividad (Total de consultas realizadas / Total de consultas resueltas en el efector) CASOS DE USO Lista de Actores Preliminar Nombre Actor Descripción Administrativo CS Personal administrativo de cada CS. Tiene acceso limitado a la información del CS en que trabaja. Jefe CS Cada CS tiene un jefe. El acceso es también limitado a su propio CS. Coordinador de Distrito Cada uno de los distritos descentralizados cuenta con un coordinador que está a cargo de todos los CS de la zona. Dirección de APS Tiene acceso a todo el sistema. Administrador Es una figura que será encargada de administrar los datos en forma centralizada. Estará encargado de mantener las tablas maestras y de depurar las HCIs. Farmacia Central Farmacia Central de APS que distribuye insumos a los CS. Dirección de Salud Bucal Distribuye insumos de Odontología a los CS. Programa de Distribuye insumos de vacunación a los CS. Inmunizaciones Lista de Casos de Uso Preliminar N° Nombre del CU Consultar/modificar paciente 1. 2. 3. 4. 5. Seleccionar paciente Consultar/modificar HCF Seleccionar HCF Generar HCF Seleccionar ER 6. 7. 8. Consultar Obra Social Emitir carnet de HC personal Controlar distribución de pacientes entre <> ER Informe de pacientes no 10. adscriptos Informe de pacientes no 11. asignados a ninguna HCF 9. Descripción Módulo: Historias Clínicas Consulta general de un paciente, desde la que se puede acceder a todo lo que tenga que ver con la HCI (en caso que la tenga) o al paciente sin HCI. También desde este CU se dan de alta los nuevos pacientes (con o sin HCs). Permite buscar pacientes (con y sin HCIs de APS y de DTT) con <> criterios de búsqueda. Consulta los datos generales de una HCF y permite consultar, eliminar o agregar integrantes. Permite buscar HCFs y familias sin HCF con <> criterios de búsqueda. Desde este CU puede accederse al alta de una nueva HCF. Alta de una HCF. Permite seleccionar un ER y dentro del mismo, un médico de cabecera, de los existentes en el CS. Junto a cada ER se muestra el % de pacientes adscriptos que tiene, para que en base a este dato el operador tienda a equilibrar la distribución de pacientes entre los <> ERs. Consulta el padrón de Obras sociales con los datos de una persona para detectar si tiene alguna Obra Social. Imprime un carnet de identificación personal similar al que hoy se entrega en los hospitales. Calcula el % de pacientes adscriptos a cada ER de un CS. Para fomentar el proceso de adscripción, se podrá sacar un informe en el que figurarán todos los pacientes que no están adscriptos a ningún ER. Idem anterior, pero respecto al agrupamiento de pacientes en HCFs. Página 21 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud 12. Depurar HCs Coordina los CU de depuración. Depurar HCs por duplicaciones Proceso que permitirá unificar bajo un nro de HCI varias HCIs que hayan 13. sido creadas para una misma persona. Depurar HCs por inactividad Proceso que pasará a un estado de “inactivas” las HCIs que no registren 14. movimientos en los últimos 5 años y dará de baja las que tengan 10 años de inactividad. Módulo: Atenciones y Turnos Consultar turnos de un paciente Consulta los turnos que fueron otorgados al paciente tanto en el CS como en el resto de efectores, ordenados por fecha en forma decreciente. 1. Seleccionando un turno de APS puede registrarse el resultado de la atención, en base a lo que el profesional completó en la planilla de atenciones o bien anularse el turno. Alta de turnos Permite asignar turnos a pacientes, ya sea dentro del CS, en otros CS o en 2. efectores de 2do. Nivel. Anular turno Siempre que la fecha y hora del turno no haya pasado, puede anularse, 3. quedando libre y disponible para cualquier otro paciente. 4. Seleccionar profesional Permite buscar profesionales según <> criterios de búsqueda. 5. Emitir comprobante de turno Imprime un comprobante del turno otorgado. Seleccionar efector y Permite seleccionar efector y especialidad entre los que dispone el CS para 6. especialidad tomar turnos en otros efectores de APS o de 2do Nivel. Consultar atenciones realizadas Lista las atenciones registradas a un paciente, agrupadas por servicio. a un paciente Pueden así consultarse por ej, todas las atenciones realizadas por el 7. profesional de referencia, las dosis de vacunas aplicadas a un paciente, las prestaciones odontológicas, etc. Registrar atenciones de Mediante este CU se registrarán en el sistema las planillas de atenciones pacientes que los profesionales completan con las atenciones que realizan, tanto de 8. turnos programados como no programados, atenciones de enfermería, vacunación, etc. Registrar atención Registra el resultado de una atención en particular (diagnósticos, 9. tratamientos, prácticas realizadas, etc). Registrar internación Permite registrar que un paciente fue internado. Registra datos generales 10. del proceso de búsqueda de cama en hospitales. 11. Registrar vacunación Registra los datos particulares de una atención de “vacunación”. Registrar resultados de Mediante este CU se registran resultados de prácticas que llevan 12. prácticas seguimiento (ej: PAPs) según informes recibidos desde efectores que las realizan. 13. Administrar personal del CS Permite registrar altas y modificaciones del personal de un CS. Agregar personal del CS Mediante este CU se puede seleccionar una persona que ya sea “personal 14. de APS” o no, para luego asociarla al CS donde va a desempeñarse. Mantener Equipos de 15. Se pueden generar nuevos ERs o registrar modificaciones en los existentes. Referencia Consultar agenda Consulta la agenda de un trabajador del CS (profesional o no profesional). 16. Esta agenda puede estar formada por turnos programados (para los profesionales que trabajan por turnos) y excepciones. Emitir planilla diaria de Seleccionando una fecha de la agenda de un profesional se imprime la atenciones planilla con los turnos asignados y renglones en blanco para que el profesional registre las atenciones que realiza sin turnos. En determinados 17. casos (ej: enfermería), las planillas sólo tendrán los datos del profesional, la fecha, y todos los renglones en blanco, ya que las atenciones se realizan sin turnos. También en este CU se imprime la planilla de vacunación (sólo para enfermeros). Generar agenda de turnos Proceso automático y temporal que genera para cada profesional que trabaje con turnos programados su agenda de turnos de una determinada 18. duración para un horizonte a futuro de tiempo variable según la especialidad. Registrar excepciones Se registran las actividades que no corresponden a atenciones por turnos 19. de los trabajadores de los CS. Cuando un profesional deja de trabajar en el CS o deja de conformar un cribir pacientes ER, o un ER completo deja de existir, todos los pacientes que tenía 20. adscriptos quedan sin ER o médico de cabecera, según el caso, o en el último caso, pueden pasar a tener un nuevo médico de cabecera que reemplaza al anterior. Informe de proyección de Permite conocer las dosis de vacunas que según el calendario actual vacunación deberán ser aplicadas durante un período de tiempo futuro (por defecto el 21. mes sgte). Cada CS podrá valerse de esta información para hacer el pedido de vacunas al Programa de Inmunizaciones. Página 22 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud 22. 23. 24. 25. 26. 27. 28. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Informe de pacientes que se atienden por fuera de su ER Informe de pacientes que registran atenciones con profesionales que no son los de su ER, pero que forman otros ERs. Es decir, no se consideran las atenciones realizadas por especialistas que no forman ERs (ej: ginecólogos, odontólogos, etc) Informe de control de asistencia Mediante este informe se controla la asistencia de los pacientes a las de pacientes distintas consultas. Refleja la inasistencia a turnos reservados y la falta de concertación de “próximas consultas”. Seleccionar HCIs que no Recupera las HCIs a las que al haber sido adscriptos se le dio una “fecha asistieron a su 1era consulta de 1era consulta”, a la que no asistieron. Seleccionar pacientes que no Recupera pacientes que no asistieron a turnos que tenían asignados. asistieron a turnos programados Seleccionar pacientes que no Recupera pacientes que no concertaron una “próxima consulta” según la asistieron a “consultas fecha registrada por el profesional en su última consulta. posteriores” Informe de productividad de Este informe calcula varios índices de productividad de los profesionales profesionales del CS. Informe de cumplimiento del Este informe recupera los pacientes que no están cumpliendo con las dosis calendario de vacunación de vacunas que les corresponderían (Hay que ver sobre qué pacientes hacer este control, porque de las HCIs que existan previamente a la implementación del sistema no se tendrá registro de sus carnets de vacunación, por lo que este control no reflejaría la realidad). Módulo: Farmacia Administrar Pedidos Permite consultar pedidos realizados y recibidos (por los CD), generar pedidos nuevos, modificar los existentes mientras no existan Ordenes de Compra o Remitos asociados al mismo y reimprimirlos. Generar pedido de Insumos Permite generar los distintos tipos de pedidos (generales, especiales, de vacunas y de odontología) en función de los consumos y el punto mínimo de reposición en el caso de los CS y cuando los pedidos son generados por los CD se sumarizan los pedidos recibidos los distintos CS. Las cantidades finales del pedido son factibles de ser ajustadas a criterio del operador. Administrar Ordenes de Permite reimprimir una Orden de Compra o modificar sus datos mientras Compra no esté en curso (no debe existir un Remito asociado a la Orden de Compra). Generar Orden de Compra De los pedidos efectuados por Farmacia Central o Dirección de Salud Bucal, se generan las distintas Ordenes de Compra definiendo el proveedor (droguería o laboratorio), nombre comercial, cantidad pedida y precio unitario. Registrar Remitos de Se actualiza el stock de Farmacia Central o de la Dirección de Salud Proveedores Bucal, con las cantidades que los proveedores entreguen, además de registrar el lote y fecha de vencimiento de cada insumo recibido. Se asocia el remito a la Orden de Compra que le dio origen. Aprobar Remito Recibida en el CS la medicación de los CD, y previo control físico del envío, se registrará la aprobación de la recepción con las observaciones correspondientes. Registrar ingreso de insumos Ingreso de insumos a CS o CD que no provienen de ordenes de compra ni pedidos formales (donaciones, préstamos, etc). Se ingresan todos los datos de los insumos. Actualizar stock Cada ingreso o retiro de insumos (cualquiera sea el origen o el destino), desencadena la actualización del stock de las farmacias de los CS o de los CD identificando el lote del insumo que se incrementa o decrementa. Registrar distribución de Registra la entrega periódica de insumos que los CD realizan a los CS. insumos a los Centros de Salud Consultar stock Ante cada entrega de medicamentos, se debe controlar previamente que la cantidad que se desea entregar esté disponible y validar el vencimiento de los mismos. Registrar entrega de Permite registrar la entrega de medicamentos a pacientes por Medicamentos a pacientes presentación de recetas o carnets de tratamientos prolongados, previa consulta de las entregas de medicamentos registradas al paciente en todos los efectores de la red municipal en el último tiempo. Registrar receta Registra datos de una receta indicando profesional, fecha, diagnósticos, medicación, posología, cantidad prescripta y cantidad entregada. Pueden registrarse también entregas parciales por receta. Registrar Tratamiento Permite registrar un nuevo carnet de tratamiento prolongado (programas Prolongado o protocolos especiales), modificar uno existente siempre que no tenga entregas registradas y su estado sea PENDIENTE o darlo de baja. Cuando el tratamiento está AUTORIZADO (en los casos que así lo requiera) pueden registrarse las entregas de medicamentos según la prescripción. Página 23 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud 14. 15. 16. 17. Registrar autorización de Tratamientos Registrar Abandonos de Tratamientos Registrar salida insumos del stock Consultar medicamentos entregados por paciente Controlar Pedidos Pendientes 18. 19. 20. 21. 1. 2. Informe de demanda insatisfecha Informe de control de cumplimiento de tratamientos Informe de consumo de insumos Ingresar criterios generales y determinar nivel de análisis Ingresar/modificar persona Permite registrar la autorización de Tratamientos que así lo requieren (Incidentales, Prolongados, Vía de Excepción Incidentales, Vía de Excepción Prolongados) y ajustar datos del tratamiento (cantidad prescripta, posología, fecha de próxima consulta). Permite indicar como INACTIVOS aquellos tratamientos que en un período de tiempo indicado no han retirado medicación. Permite descontar insumos del stock de un CS o CD por distintos motivos (Pérdida, Vencimiento, Rotura, Robo, Préstamo, Entregas a pacientes sin identificar, Entregas a sectores del CS, Consumo periódico, etc). Permite consultar los medicamentos entregados a un paciente en toda la red de APS. En función de los pedidos efectuados (Farmacia Central a los proveedores o al LEM, Programa de Inmunizaciones a la Provincia, Dirección de Salud Bucal a los proveedores, CS a Farmacia Central , Programa de Inmunizaciones o Dirección de Salud Bucal), controla el cumplimiento de los mismos, comparando las cantidades pedidas con las que figuran en los remitos. Consulta o listado de medicamentos cuya demanda por parte de pacientes no pudo cumplirse total o parcialmente en un período determinado, en uno o varios CS. Consulta o listado de pacientes con tratamientos prolongados que cumplen o no cumplen con el mismo. Consulta o listado de insumos consumidos según distintos criterios (por diagnósticos, por programa, por proveedor, según distintos niveles de clasificación de insumos (ATC), por motivos de salida, etc). General En este CU se agrupará el ingreso de todos los criterios que sean utilizados en todos los informes que emita el sistema y además, se limitará el acceso a distintos niveles de información según el rol del usuario (si tiene acceso a todo el sistema, a los CS de un distrito, a un único CS, etc). Alta y modificación de personas. Se mantendrán todas las personas (sean pacientes, profesionales, etc) en un mismo repositorio. INTERFACES CON OTROS SISTEMAS El sistema de APS deberá coexistir con el sistema actualmente implementado en los hospitales municipales, por lo que deberán incluirse ciertas interfaces a nivel de datos. Esto significa que ambos sistemas compartirán determinados datos. Para todo lo que es consultas (de HCs existentes en ese sistema, de atenciones de pacientes en la red hospitalaria, de turnos disponibles en hospitales, etc), el sistema de APS deberá utilizar la base de datos del sistema de hospitales, para obtener la información. Dado que el sistema de hospitales maneja una codificación de datos (ej: tipos de documentos, localidades, efectores etc), diferente a la utilizada en por todos los sistemas desarrollados y mantenidos por Municipalidad, se deberán mantener las relaciones entre estas codificaciones. Ejemplo de diferencias en la codificación “Caso Localidades”: En el sistema de hospitales la localidad “Rosario” está codificada con código 1, mientras que en el sistema de APS deberá ser código 2000, subpostal 8 tal como se codifica en el resto de los sistemas municipales. Cuando se deba actualizar/agregar información en el sistema de hospitales (Alta de HCIs, Reserva / Anulación de turnos en hospitales), las transacciones deberán hacerse directamente la base de datos del sistemas de hospitales, contemplando ciertas restricciones particulares impuestas por este sistema. Las especificaciones detalladas serán entregadas al Adjudicatario. 1.3 REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA A OFERTAR El aplicativo debe cumplir con los requerimientos no funcionales detallados en el Anexo 4-Criterios de aceptación de requerimientos no funcionales 1.4 FUNCIONALIDADES A PROTOTIPAR Módulo: HC CU Principal CU Secundarios 01- Consultar/Modificar Paciente 03- Consultar/Modificar HCF 02– Seleccionar Paciente 06- Seleccionar ER 08- Emitir Carnet de HC personal Módulo: Atenciones y Turnos CU Principal CU Secundarios 02- Alta de Turnos 06-Seleccionar efector y especialidad Página 24 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud 08-Registrar atenciones de pacientes 11-Registrar vacunación 09-Registrar atención Módulo: Farmacia CU Principal CU Secundarios 01-Administrar Pedidos 02- Generar pedidos de insumos 07-Registrar ingreso de insumos 11-Registrar Entrega de Medicamentos 12-Registrar receta a pacientes 1.5 AREA DEL PROYECTO PILOTO Se realizará la implementación de cada módulo en dos Centros de Salud. La cantidad de usuarios promedio entre los dos Centros de Salud es 20. Además hay alrededor de 10 personas vinculas a la obtención de información estadística y de gestión. 1.6 GLOSARIO DE TERMINOS Término Adscripción Descripción Procedimiento por el cual un profesional se hace responsable de una persona en APS Atención primaria de la Salud (APS) Dirección de la Secretaria de Salud Pública que dirige los CS y Vecinales Centro de Distribución (CD) Centro de Distribución de Insumos: Odontología , Programa de Inmunizaciones, y Farmacia central , distribuye insumos a Centros de Salud y Servicios Centro de Salud (CS) En Rosario existen Centros de Salud distribuidos en distintas zonas con el objetivo de brindar atención directa y seguimiento de las patologías de la población de dichas zonas CIE10 Clasificación Internacional de Enfermedades de la OMS. Es la codificación de diagnósticos que se utilizará en el sistema. Clasificación Anatómica, Terapéutica Nomenclador usado para identificar las monodrogas. y Química (ATC) Equipo de Referencia (ER) Equipo de profesionales (médicos y enfermeros) que tienen a cargo un grupo de pacientes Historia Clínica Familiar (HCF) Número que identifica el agrupamiento de pacientes que pueden o no estar adscriptos. Este número es secuencial por Centro de Salud Historia Clínica Individual (HCI) Número que identifica unívocamente a un paciente dentro de la red municipal de salud Insumos La clasificación insumos incluye: medicamentos, descartables, vacunas y otros LEM Laboratorio de Especialidades Medicinales, funciona como un proveedor de medicamentos. Las entregas de Medicamentos son por convenio de tiempo determinado (Ej. 3 meses) provee de medicamentos a la farmacia central de APS Medicamentos Generales Son aquellos medicamentos esenciales cuya distribución es desde el nivel central y es a granel. Medicamentos Especiales Son aquellos medicamentos normatizados para su Indicación. Es decir, existen normas a cumplir para la entrega de dichos medicamentos. Paciente adscripto Persona a la que se le asigno un equipo de referencia (ER) Paciente No adscripto Persona que está ingresada en el sistema de APS pero no está adscripta. Puede o no tener HCI Prescripción Cantidad de Medicamento asignada a un paciente en una receta o protocolo Programa La nación y la provincia proveen de insumos a la Municipalidad, teniendo ésta que informarle periódicamente del destino (pacientes por diagnostico) de los mismos Protocolo Autorización a la que se somete la adquisición de un medicamento especial, por paciente y por un determinado período de tiempo . Entran en esta categoría los tratamientos prolongados, por vía de excepción, recetas del CEMAR. Programa REMEDIAR Es un programa Nacional que cubre medicamentos esenciales y es complemento en la entrega de medicamentos generales. Beneficiario Toda persona que ha recibido atenciones en algún efector de la red municipal de salud Beneficiario activo Todo beneficiario que ha concurrido por lo menos una vez en el período de referencia Morbilidad Problemas de salud codificados según la Clasificación Internacional de Enfermedades (CIE 10) provista por la Organización Mundial de la Salud (OMS) Página 25 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Consultas nuevas Consultas repetidas Consultas de primera vez o ulterior Clasificación de edad provista por el Censo de Población Refiere a la captación en el efector del beneficiario en el año calendario. Corresponde a aquellos beneficiarios ya captados en el efector en el año calendario. Están asociadas al diagnóstico y lo define el profesional. Intervalos cerrados de a 4 años. Ej: [0, 4] – [5, 9] – [10, 14]... Página 26 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud ANEXO 2: FORMULARIO PARA EL C.V. DEL PERSONAL PROPUESTO [Completar la Tabla 1 con los datos personales y laborales.] Tabla 1 Datos personales Nombre y Apellido Fecha de nacimiento Nacionalidad Datos laborales Nombre de la firma/entidad Antigüedad en la firma/entidad Relación Laboral con la firma/entidad Lugar donde actualmente desarrolla sus tareas Cargos/Roles propuestos Dedicación (hs/hombre) Calificaciones principales para el cargo/componentes propuestos: [Indicar en aproximadamente media página la experiencia y la capacitación recibida que sea más pertinente para las tareas del trabajo. Describir el nivel de responsabilidad en trabajos anteriores pertinentes, indicando fechas y lugares.] Educación: [Completar las Tablas 2.1 y 2.2 con la formación superior y otros estudios especializados del profesional, indicando los nombres de las instituciones de enseñanza, y los títulos obtenidos o en curso.] Tabla 2.1: Títulos Obtenidos Título Institución de Enseñanza Año de Obtención Tabla 2.2: Títulos en Curso Título Institución de Enseñanza Fecha de Inicio Materias Restantes /Total de Materias Experiencia laboral: [Completar la Tabla 3, detallando sólo los puestos ocupados que avalen la experiencia del profesional para el cargo propuesto. Empezando con el puesto actual, enumerar en orden inverso los cargos desempeñados.] Tabla 3 Organización Empleadora Inicio Fin Cargo Proyectos en los que participó Nombre Descripción Fecha de inicio Duración (meses) Cargos/Roles Duración del desempeñados cargo durante el Proyecto (meses) Organización Empleadora Inicio Fin Cargo Proyectos en los que participó Nombre Descripción Fecha de inicio Duración (meses) Cargos/Roles Duración del desempeñados cargo durante el Proyecto (meses) Firma del Profesional: Página 27 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud ANEXO 3: MANTENIMIENTO 3.1. ALCANCES DEL SERVICIO DE MANTENIMIENTO El mantenimiento del software aplicativo debe incluir como mínimo: Entrega sin costo para Municipalidad de las actualizaciones periódicas para la versión adquirida o actualización de la última versión existente en el mercado para el mismo ambiente de trabajo, compatibilizando las modificaciones que se le puedan haber hecho al software aplicativo para resolver problemáticas puntuales de esta Municipalidad, suministrando además toda la documentación referida a la misma. Municipalidad podrá implementarlas o no de acuerdo a la evaluación que realice sobre los impactos que producirán las mismas. Consultoría telefónica para la resolución de cuestiones pertinentes al uso del software, en caso de falla. Resolución telefónica de problemas, en caso de falla. Soporte local, en las oficinas de Municipalidad, cuando se determine que ello es necesario. Envío de las correcciones del software a través de conexión remota o medio magnético. Guía al usuario en la implementación de correcciones y/o actualizaciones a través de una combinación de medios magnéticos y/o documentación impresa y/o conexión remota, o con intervención directa de personal del Adjudicatario en caso de ser necesario. Consultoría referente a las alternativas para resolver aplicaciones que no estén contempladas en el sistema. 3.2. MODIFICACIONES SOBRE LOS SERVICIOS INCLUIDOS EN EL CONTRATO Durante la vigencia del contrato, Municipalidad podrá aumentar o disminuir los servicios que se solicitan siempre que dichas modificaciones no alteren en un 20% en más o en menos el importe total del contrato; sin que ello dé motivo a rescisión o reclamo alguno por los beneficios que hubiere dejado de percibir por la parte suprimida, reducida o modificada. 3.3. FORMA DE COMUNICACIÓN DE LOS RECLAMOS Municipalidad realizará los reclamos en forma telefónica, fax, correo electrónico o notificación. Para tal fin indicará quienes son las personas autorizadas a realizar los mismos. El Adjudicatario deberá indicar (en el momento en que se le contrate el servicio) quiénes son las personas autorizadas para resolver los pedidos. 3.4. TIEMPOS DE RESPUESTA ANTE RECLAMOS Municipalidad según su criterio clasificará los reclamos en “Urgentes” o “Normales” debiendo el Adjudicatario asegurar que: Ante un reclamo clasificado como de “Urgente” tomará las medidas necesarias para la resolución del mismo dentro de las 8 horas corridas de efectuado. Ante un reclamo de mantenimiento “Normal” deberá resolverse dentro del siguiente día hábil de efectuado el mismo y ofrecer alternativas para poder realizar procesos críticos. El Adjudicatario en todos los casos deberá resolver el problema en forma “definitiva” dentro de un día hábil de efectuado, caso contrario deberá justificar con informe a Municipalidad el motivo de su retraso, de no ser así se hará pasible de una multa de acuerdo a lo establecido en el Art. 9. PENALIDADES. 3.5. VIGENCIA DEL CONTRATO Esta Municipalidad decidirá al momento de la adjudicación del software, la contratación o no del mantenimiento por uno o dos años a partir de la fecha de aceptación de la implementación definitiva de lo solicitado en esta licitación, o cuando finalice la garantía según considere la Municipalidad. 3.6. CAUSALES DE RESCISIÓN Son causales de rescisión del contrato las enumeradas en el ART. 22 CAUSALES DE RESCISIÓN DE LA ADJUDICACIÓN IMPUTABLES AL ADJUDICATARIO. 3.7. HORARIOS DE PRESTACION DE LOS SERVICIOS Lunes a Sábado de 6 a 18 hs. ANEXO 4: CRITERIOS DE ACEPTACIÓN El control de calidad es el conjunto de tareas de evaluación de las actividades y resultados entregados por el Adjudicatario, tendientes a lograr el cumplimiento de los trabajos previstos y alcanzar los resultados esperados. Las tareas de control de calidad y criterios de aceptación de los productos entregados estarán enfocados sobre los aspectos de completitud, calidad y forma de entrega. Criterios de aceptación aplicables a todos los productos y subproductos De existir modificaciones, correcciones y/o agregados en cualquiera de los productos y/o subproductos, deben estar incluidos en un plan de ajuste acordado entre las partes, y actualizada toda la documentación generada. Todo producto y/o subproducto debe respetar la norma de nomenclatura estándar de la Municipalidad. Página 28 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud En el caso de ser considerado necesario por parte de Municipalidad, deberán presentarse informes en el ámbito de talleres de trabajo, a los fines de facilitar las tareas de coordinación, intercambio de ideas, detección temprana y resolución de problemas. Todos los productos y/o subproductos deben ser consistentes entre si. Debe haber buena disponibilidad de comunicación y respuesta de cada uno de los integrantes del personal del Adjudicatario para satisfacer todas las consultas y solicitudes de carácter técnico, respecto de la ejecución y avance de las actividades para las cuales el Adjudicatario los ha propuesto y han sido aceptados. La información de avance debe ser consistente para que sea aceptada una etapa y/o producto intermedio o final. Criterios de aceptación del cronograma El cronograma debe ajustarse a los tiempos de entrega establecidos en el presente pliego. Todas las tareas deben tener tiempos y recursos asignados. El cronograma debe contener hitos significativos acordados entre las partes. En la elaboración del cronograma deben contemplarse para cada producto/subproducto los tiempos de revisión insumidos por Municipalidad y los tiempos de corrección insumidos por el adjudicatario. Estos tiempos serán acordados entre las partes. Los tiempos de revisión insumidos por Municipalidad representarán un 10 % del tiempo destinado a la realización del producto/subproducto. La estructuración del cronograma debe corresponderse con los productos y/o subproductos a entregar. Una vez iniciado el servicio del Adjudicatario, se debe plasmar el plan de trabajo en la herramienta de planificación indicada en Anexo 5. Criterios de aceptación de revisión y ampliación del material entregado por Municipalidad Deben estar presentes todas las funciones del sistema acordadas con Municipalidad y los nuevos requerimientos que podrían surgir de la actividad de Revisión y ampliación del material (Producto 1 – Subproducto1). Criterios de aceptación del diseño Los modelos/diagramas presentados deben ser consistentes entre si y con los requerimientos. Los diagramas deben describir correctamente los principales servicios y componentes La especificación de diseño detallado debe ser lo suficientemente clara y parametrizada para facilitar la Mantenibilidad del código, detallando cada script y las principales líneas de código. Deben estar diseñados todos los casos de uso de análisis. El diseño del aplicativo debe adherir como mínimo a las siguientes reglas básicas: 1. No incrustar código java directamente en las jsp. 2. Garantizar la validación del lado del servidor en la entrada de datos. 3. Minimizar el uso de javascript del lado del cliente. 4. Garantizar que el código javascript utilizado sea soportado por todos los navegadores mencionados en Anexo 5. 5. No implementar la lógica de negocios en los ActionForm, que sean simples Beans. Diseño de Interfaces Deben estar diseñadas las interfaces necesarias para cubrir todas las funcionalidades Todos los caso de uso deben tener acciones de aceptación y de cancelación de operaciones. Todas las acciones que se ejecuten deben poseer la misma identificación en todos los casos de uso. Buscar siempre la coherencia. El diseño debe ser coherente en todas las interfaces (logos, estándar de distribución de elementos). Permitirle a los usuarios frecuentes el uso de teclas rápidas (shortcuts) y el ingreso directo de códigos sin necesidad de acceder a las consultas. Dar realimentación de información. Los usuarios necesitan ver las consecuencias de sus acciones. Si un usuario ingresa un comando pero el sistema no muestra información respecto a que lo está o no procesando, esto puede dejar al usuario confundido o desorientado. Diseñar diálogos que tengan un fin. Cada tarea debe tener un inicio, un desarrollo y un fin. Es importante que el usuario sepa cuándo una tarea está finalizada. El usuario necesita tener la sensación de que la tarea ha alcanzado su término. Permitir manejos simples de los errores. Los errores del usuario deben estar diseñados dentro del sistema. No debe haber ninguna acción por parte del usuario que sea considerada como un error que está más allá de la capacidad del sistema para manejarlo. Si el usuario comete un error, debe recibir información útil, clara y concisa sobre la naturaleza de tal error. Respaldar que el centro del control esté en el usuario. La satisfacción del usuario es alta cuando el usuario tiene la sensación de que es él quien tiene el control, y la satisfacción del usuario es baja cuando el usuario siente que la computadora tiene el control. Reducir la carga de la memoria inmediata del usuario. Hacer todo lo posible para liberar la carga en la memoria del usuario. Por ejemplo, en lugar de pedirle al usuario que tipee el Página 29 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud nombre de un archivo para abrirlo, presentar al usuario una lista de archivos disponibles en ese momento. Deben ser traceables con los casos de uso y requerimientos. Todas y cada una de las operaciones, disposición de objetos en páginas y presentación de la información de cada uno de los casos de uso debe estar validada por Municipalidad. Diagrama de Estados y Actividad Deben esquematizarse las actividades, procesos y estados principales del producto. Debe ser consistente con el resto de los modelos y especificaciones. Modelo de datos Debe incluir todas las clases persistentes Mapeo del diagrama de clases al modelo de datos Debe mapearse todos los atributos de las clases persistentes. Todas las tablas deben tener su correspondiente clase persistente asociada. Matriz de Trazabilidad Debe mostrar la relación de los requerimiento con los casos de uso, casos de prueba y código. Prototipo El prototipo debe ser consistente con la especificación de interfaces relacionada y los requerimientos funcionales que se intentan prototipar. Criterios de aceptación de los Casos de Prueba Debe existir el plan de testing para cada subsistema/interface. Debe existir un conjunto de casos de prueba funcionales definidos y entregados para cada caso de uso, en correspondencia al plan de testing planteado. Debe existir un conjunto de casos de prueba de sistema que testee el comportamiento de los casos de uso una vez integrados. Todos los casos de prueba deben contar con una descripción detallada. Los resultados de testing deben estar documentados de manera clara y formal, para cada caso de prueba ejecutado. Los casos de prueba funcionales definidos y entregados para cada caso de uso deben comprender el testeo de una cantidad significativa de funcionamiento correcto y erróneo de las funciones. Dicho de otra manera, de existir errores, debe existir una buena probabilidad de encontrarlos. Debe existir una base de datos con los datos de prueba empleados para la ejecución de los casos de prueba que permita volver a probar los mismos. No deben aparecer errores relacionados con aspectos de navegabilidad dentro de la aplicación. Una vez integrados y entregados todos los casos de uso, a partir de su funcionamiento, no deben detectarse errores de integridad de la base de datos de prueba causados por los mismos. Los resultados de los casos de prueba deben reflejar el correcto funcionamiento del sistema. Criterios de aceptación del código fuente Las definiciones de componentes realizadas en el diseño deben corresponderse con la estructura del software entregado. El código debe condecir con la especificación de diseño detallado. Todos y cada uno de los componentes de código deben poseer una especificación de diseño detallado No deben existir errores que impidan la correcta ejecución del sistema de acuerdo a los criterios de aceptación de los casos de prueba. Todos los productos pactados (fuentes, objetos, bases de datos de prueba con datos cargados) deben estar instalados en el ambiente de la Municipalidad. Deberá entregarse actualizada a la ultima versión aprobada e instalada del producto para ser mantenida con las herramientas indicadas en Anexo 5. Los productos finales que hubiesen sido prototipados deberán responder al prototipo realizado. Deberán estar codificados todos los casos de uso de diseño. Criterios de aceptación de la Base de Datos La totalidad de la base de datos deberá encontrarse instalada en el ambiente de producción de la Municipalidad. Deberá existir correspondencia entre la totalidad de los componentes gráficos y descriptivos. El modelo de datos empleado debe condecir con la base de datos instalada. La base de datos debe estar correctamente configurada para adecuarse a las características de seguridad e integridad definidas. De existir problemas en las bases de datos, la corrección debe ser derivada sin que esto ocasione problemas en las pruebas y en la ejecución del sistema. Página 30 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Criterios de aceptación de la Implementación Provisoria La instalación del software necesario en el servidor y en todos los puestos de trabajo del área del proyecto piloto indicada en punto 1.5 Anexo 1, bajo la supervisión de personal municipal. Operatoria en paralelo con la forma de trabajo actual durante 15 días corridos, a los fines de verificar los resultados obtenidos. La operatoria del sistema durante este período estará a cargo de personal de esta Municipalidad. Durante este plazo se deben realizar todos los ajustes al sistema que fueran necesarios. Todo el personal que corresponda debe haber recibido las capacitaciones adjudicadas en esta licitación. Que los resultados de todos los procesos asociados al sistema que utiliza actualmente la Municipalidad (sean manuales o automáticos) coincidan con los resultados del sistema adjudicado. Que se cumplan los requerimientos mínimos planteados en este pliego. Que cumpla con la funcionalidad ofrecida por el oferente. Que el software de base y el aplicativo estén estabilizados: sin puestas fuera de servicio o lentitud aleatorias o sin causa determinada. El sistema no debe estar fuera de servicio por un período de tiempo superior a 4 horas, ni deberán registrarse más de 5 fallas en un período de 15 días corridos, debido a problemas relacionados a aspectos funcionales o no funcionales derivados de la programación desarrollada en el sistema. La capacitación de los usuarios del área del proyecto piloto indicada en punto 1.5 Anexo 1, debe realizarse en el rango horario de 7 a 13 hs en días hábiles. Criterios de aceptación del Diagrama de Despliegue Los nodos y demás elementos deben corresponderse con los equipos reales y existentes. Criterios de aceptación de la Transferencia Tecnológica El Adjudicatario deberá proveer el entrenamiento necesario para asegurar la administración y mantenimiento del aplicativo. La capacitación debe realizarse en forma coordinada con el calendario de implementación provisoria de los módulos y en la ciudad de Rosario en horarios y lugar que la Municipalidad disponga. La capacitación debe apoyarse a través de la participación del personal técnico municipal en las reuniones de revisión técnica del producto. Durante el período de implantación el personal técnico municipal deberá participar en la configuración del ambiente operativo y en la puesta en marcha de los sistemas. La Municipalidad de Rosario evaluará al finalizar la transferencia tecnológica si la misma alcanzó los objetivos esperados. En el caso de no haberse cumplido en forma completa, se podrá pedir una ampliación de la misma, sin costo para Municipalidad. Criterios de aceptación de la Implementación Definitiva La instalación de la ultima versión del software en el servidor y en todos los puestos de trabajo del área piloto indicada en punto 1.5 Anexo 1, bajo la supervisión de personal municipal. El módulo se considerará implementado definitivamente cuando se compruebe que ha funcionado correctamente (según todos los criterios de aceptación) durante 2 semanas a partir de la aceptación de la implementación provisoria, sin fallas y sin necesidad de realizar ajustes al mismo. Criterios de aceptación del Manual de Usuario del sistema Todos los casos de uso deben estar descriptos en el manual del usuario. Los manuales del usuario deben estar de acuerdo al código en lo que hace a interfaces, mensajes, navegación y funcionalidad. Los manuales deben describir la operatoria de cada uno de los perfiles que pueden acceder a cada caso de uso. Los manuales deben ser entendibles por el usuario final, de manera que a partir de ellos, y con una capacitación adecuada (la prevista dentro del cronograma del proyecto), puede operar sin inconvenientes la/las funciones sobre las que posee permiso de acceso. El vocabulario de términos específicos debe ser consistente a lo largo de todo el manual y para todos los perfiles de usuarios. Deberá entregarse en medio magnético y ser editable por las herramientas establecidas en Anexo 5 para asegurar su posterior mantenimiento. Criterios de aceptación del Manual de Configuración e Instalación De ser factible deben entregarse instaladores que permiten instalar todos los módulos desarrollados. En el caso de requerirse instalación en los puestos clientes, la misma deberá quedar totalmente automatizada (para que la misma no se realice por cada cliente en forma manual) y proveerse esta solución al Contratante Página 31 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud La especificación del procedimiento de instalación debe ser lo suficientemente clara como para que un personal informático especializado pueda replicar el proceso sin cometer errores. Los resultados de todos los casos de prueba ejecutados sobre los instaladores deberán ser exitosos (script y especificación de procedimientos). CRITERIOS DE ACEPTACION DE REQUERIMIENTOS NO FUNCIONALES En el caso de surgir algún problema en los casos de prueba no funcionales, las correcciones/agregados deben estar incluidas en un plan de ajuste acordado entre las partes. Criterios de aceptación de Seguridad de acceso a las funciones y opciones del sistema Los usuarios que ingresen al sistema deben ser identificados y autenticados, y las funciones del sistema deben habilitarse según su sector y perfil en cada una de las funciones que así lo requieran. Los usuarios que realizaron operatorias sobre el sistema deben poder ser identificados posteriormente. Deben quedar registradas todas las excepciones al tratamiento normal de las operaciones que provee el sistema (transigencia de controles). Debe permitir realizar definiciones por grupos y asignar los usuarios a los mismos. Deberá disponer de un administrador de tareas de seguridad de aquellas funcionalidades que no están cubiertas por la librería Seguridad Web incluida en Anexo 5. Poseer un nivel de seguridad sobre grupos de datos que impida su alteración por parte de usuarios no autorizados. Debe realizar el cierre automático de una sesión de trabajo por inactividad en un lapso de tiempo configurable. Criterios de aceptación de Usabilidad El sistema debe cumplir con los estándares de interface web de la Municipalidad de Rosario, salvo casos previamente acordados entre las partes. Debe disponerse de ayuda en línea sensible al contexto. El sistema deberá estar íntegramente en español, tanto los literales de las pantallas/ventanas y reportes como los mensajes específicos y ayudas en línea. Las interfaces de usuario deben ajustarse a criterios de aceptación del diseño de interfaces. El usuario debe poder recordar como operar el sistema entre usos del mismo. El sistema debe anticipar y prevenir los errores de usuario mas comunes. El sistema debe ayudar al usuario a recuperarse ante los errores, y sugerir posibles acciones a seguir. El usuario debe percibir que el sistema le facilita su trabajo. Criterios de aceptación de Performance Deben aprobarse todos y cada uno de los casos de prueba no funcionales de performance. Durante la interacción en la carga de datos y consultas simples el tiempo máximo de respuesta del sistema no deberá superar los 10 segundos. El sistema deberá asegurar una performance estable, sin variaciones aleatorias o sin causa imputable al hardware o al sistema operativo. Criterios de aceptación de Mantenibilidad Los cambios potenciales al sistema deben involucrar una cantidad mínima de componentes distintos. Deberá estar modularizado y diseñado teniendo en cuenta la reusabilidad de componentes. ANEXO 5: TECNOLOGÍAS DE DESARROLLO Todas las herramientas/componentes detalladas a continuación serán de utilización obligatoria para garantizar el mantenimiento, salvo las indicadas con (*). La Municipalidad de Rosario se reserva el derecho de implementar nuevas versiones de los componentes indicados en su entorno de desarrollo y de exigir al Adjudicatario, su implementación en el aplicativo antes de la aprobación del subproducto 1 de los productos 2,3 y 4. Entorno de desarrollo Sistema Operativo: Estación de trabajo: Windows (NT, 2000, XP), Linux. Servidor: Linux (Debian Woody). Lenguajes: Java (J2SE 1.4.2), Javascript (acorde a lo que soportan las aplicaciones de navegación de los Servidores de Cliente Fino), HTML 4.01 Strict y CSS2 (compatibilidad con el standard W3C). Tecnologías: JSP, XML. DataBase: Informix versión 7.31 .UD7. Servidor Web: Apache 1.3.26-0woody6. Servidor de Aplicaciones: Tomcat 4.1.30. Source Control (Repositorio): CVS. Página 32 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud Herramientas de Modelado: Visio 2000, Erwin 3.0. Herramienta de Planificación: MS Project 98 o 2000. Herramientas de Documentación: Plantillas estándares de Ingeniería de Software de la Municipalidad. Frameworks Struts (Framework MVC . Modeling View Controller) Versión 1.1 Release Hibernate (Framework de persistencia) 2.1.8 Castor 0.9.5.2 Axis Librerías Externas Itext 1.1 Versión 1.2.4 Log4j Jakarta commons 1.2.8 --- Librerías Propias Seguridad Web Versión Servicios Web de otras Aplicaciones Propias Servicio de Georeferenciación Versión Descripción Plataforma de trabajo para desarrollos de aplicaciones web. Permite dividir el desarrollo en varias capas (presentación, modelo y controlador), es decir separar la capa de presentación de la lógica de negocio, haciendo los proyectos mantenibles y escalables Motor de persistencia para Java, que nos permite hacer persistentes los objetos de nuestras aplicaciones contra base de datos relacionales. Motor de persistencia JDO (Java Data Object).Solo se utiliza para persistencia a archivos XML. Motor de SOAP. Descripción Librería para la creación y manejo de documentos en pdf desde Java. Librería para el manejo de Loggers desde Java. Conjunto de librerías que agrupan código reutilizable del proyecto jakarta. Estas librerías incluyen código para el manejo de emails, expresions, beans, loggers, etc. Descripción Librería que brinda funcionalidad para la autenticación, cambio de contraseña, control de acceso a páginas por grupos. Un usuario puede pertenecer a más de un grupo. Descripción Herramientas para Desarrollo (Opcionales) Eclipse SDK(*) Versión Este servicio permite a partir de una dirección (calle y altura) obtener las coordenadas a fin de identificar puntos en un mapa. Descripción Hibern8ide(*) 1.2.x Release Build 3.1 Entorno de desarrollo que permite integrar distintas tecnologías y herramientas como ser J2SE (Java), Ant, Junit, CVS. Permite incorporar a través de plugs-in funcionalidades adicionales como ser administración de tomcat, base de datos, logging, uml, etc. Herramienta para realizar consultas en HQL (Hibernate Query Language) Software Base de los Servidores de Cliente Fino Sistema Operativo Administrador de Escritorio Gestor de Archivos Aplicaciones de Oficina Aplicaciones de Navegación Aplicaciones correo Mensajería instantánea Visor de PDF Editor de Imágenes Administrador de impresión Debian GNU/Linux, Sarge KDE 3.3.2 Konqueror OpenOffice 1.1.3 Mozilla-Firefox 1.0.2 IExplorer 5.5/6.0 Netscape 7.0 Kmail en Linux Outlook Express Gaim Xpdf y Kpdf GIMP y Kolourpaint CUPS Puestos de Trabajo El software aplicativo debe correr en los puestos de trabajo con las siguientes características mínimas: Tipo Procesador Disco Memoria Sistema Operativo Página 33 de 36 Aplicaciones de Navegación Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud PC Pentium 166MHz 2 GB PC Celeron 3 GB Cliente Fino N/A 32 MB Windows (95 o superior) 40 GB 256 MB Linux Debian 3.1 o superior N/A N/A N/A Página 34 de 36 1. Mozilla-Firefox 1.0.2 o superior 2. IExplorer 5.5/6.0 3. Netscape 7.0 Mozilla-Firefox 1.0.2 N/A Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud ANEXO 6: ANTECENDENTES DEL OFERENTE Nombre del Proyecto Organización donde brindó los servicios Tipo de organización donde brindo los servicios (Pública/Privada) Area/s de la organización que abarcó el servicio Fecha de inicio del proyecto Estado actual (En curso/Finalizado) Duración del proyecto (en meses) Esfuerzo en hs. hombre Descripción de las funcionalidades más importantes Plataforma y arquitectura Características y cantidad de puestos clientes: Software de base en servidor y clientes (Sistema operativo, base de datos, drivers, etc.): Lenguajes de desarrollo: Referentes(**) Nombre: Cargo: Teléfono: e-mail: Herramientas con las que trabajó Personal de la empresa involucrado en el proyecto Nombre: Rol: Dedicación: (Total/Parcial) (**)Deben facilitarse todos los datos para que la Municipalidad pueda realizar contacto con el personal que esté vinculado al proyecto en los lugares donde se haya citado. Página 35 de 36 Municipalidad de Rosario Licitación Pública – Software Aplicativo de Atención Primaria de la Salud ANEXO 7: PLAN DE RIESGO Identificación <Completar y mantener actualizada la siguiente tabla con los riesgos del proyecto , indicar probabilidad de ocurrencia (nivel) del riesgo, impacto y acciones a tomar (preventivas, mitigaciones o de contingencia según corresponda)> Riesgo Probabilidad de ocurrencia Impacto Administración Una vez identificados los riesgos: analizarlos identificar la probabilidad de ocurrencia el impacto que pueden producir los riesgos en el proyecto prever las acciones a tomar en caso de que se efectivicen los riesgos Seguimiento <Establecer como se realizará el seguimiento de los riesgos > Página 36 de 36 Acciones a tomar