Download Criterios de aceptación del código fuente

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