pliego

L.P. 07/16
DIRECCION RECURSOS MATERIALES
DPTO. DE ADQUISICIONES
Avda. L.A. DE Herrera 3326, 3do. Piso. Of. 321
TEL. 2486-50-08 int 2071/fax int. 2072
E-mail: licitaciones@asse.com.uy
Horario de atención: 9.15 a 15hs.
CONTRATACION DE UNA EMPRESA PARA
DESARROLLO E IMPLEMENTACION
DE
SISTEMA DE HISTORIA CLINICA ELECTRONICA
CONSULTA AMBULATORIA NO URGENTE
A.S.S.E.
CONTRATO Nº 07/16 (Licitación Pública)
APERTURA: 24/06/2016
HORA: 11.00
PRIMER LLAMADO – PLAZA
EL
UN
DE
EN
LA ADMINISTRACION DE SERVICIOS DE SALUD DEL ESTADO LLAMA A LICITACION
PÚBLICA POR LA CONTRATACION DE REFERENCIA, SEGÚN EL SIGUIENTE DETALLE Y
LAS CONDICIONES QUE FIGURAN BAJO EL TITULO “CONDICIONES GENERALES“.
OBJETO:
Contratación de empresa para el desarrollo e implementación de un Sistema de Historia Clínica
Electrónica (HCE) de consulta ambulatoria no urgente en A.S.S.E. (Ver características y
condiciones en “ANEXO I” que forma parte del pliego)
Se deberán cotizar los siguientes ítem como parte de la propuesta:
1) Desarrollo e implementación de Sistema de Historia Clínica Electrónica (HCE).
Licenciamiento.
2) Mantenimiento anual finalizado el proyecto.
3) Valor hora para futuras modificaciones o solicitud de servicios adicionales.
NO SE ACEPTAN COTIZACIONES ALTERNATIVAS, NI VARIANTES
En caso de presentarlas, sólo se considerará la oferta indicada como básica o en su defecto, la ubicada
en el primer orden de la cotización.
TERMINOS DE REFERENCIA PARA:
DESARROLLO E IMPLEMENTACION DE UNA HCE DE CONSULTA AMBULATORIA NO
URGENTE EN A.S.S.E.
1.
Resumen Ejecutivo
1.1.
Términos generales
•
Licitación por un Sistema de HCE Ambulatoria (HCE-A) a desarrollar e implementar
en un plazo máximo de 24 meses.
•
El software desarrollado debe contar con licencia de uso, modificación, y
redistribución a favor del ASSE sin restricciones.
1
L.P. 07/16
•
Fuerte presencia de tareas de Gestión del cambio cultural en el cronograma de
implantación.
•
Desarrollo alineado a lo sugerido por Salud.uy en cuanto a la Interoperabilidad,
para lograr en 2018 estar integrados a la HCEN.
•
La metodología para la Gestión del proyecto debe realizarse en base a estándares
internacionales reconocidos (por ejemplo PMI, ISO 21500: 2012, ISO/IEC/IEEE
16326-2009, HERMES method o PRINCE2).
•
Debe tener en cuenta las pautas de desarrollo de sistemas de Software definidas
por la Dirección Informática de ASSE, que se adjuntan como ANEXO 1 al presente
pliego.
1.2.
Alcance del Sistema
•
Registro de todas las consultas ambulatorias no urgentes de ASSE a nivel nacional
desde cualquiera de sus Unidades Asistenciales o desde el domicilio del paciente.
•
Contar con un módulo de registro remoto OffLine para cubrir también el registro de
consultas ambulatorias donde no se cuente con acceso a Intranet y garantizar el
acceso y mantenimiento de la información en conexiones de bajo ancho de banda.
•
Se debe contar además con un módulo para obtener datos estadísticos requeridos
por ASSE y por MSP, a modo de ejemplo, cumplimiento de Metas Asistenciales,
SINADI, entre otros.
1.3.
•
Trabajo
La oferta debe incluir análisis, desarrollo, capacitación y mantenimiento de un
sistema de HCE ambulatorio capaz de integrarse a la HCEN, con el alcance
especificado en 1.2.
•
Debe incluirse la capacitación a capacitadores para realizar la implantación.
•
Debe contemplar las pruebas de estrés realizadas por un tercero, que garanticen la
buena performance del Sistema.
•
Definición e implantación de la arquitectura necesaria para la Interoperabildad.
•
Planificación y ejecución de la Gestión del Cambio para la implantación del sistema
de HCE-A.
•
Definir, planificar y ejecutar la migración de los datos clínicos registrados en el EC, al
nuevo sistema HCE-A.
•
Transferencia de conocimiento de la solución y los conocimientos necesarios para su
evolución por parte de ASSE o por terceros que se designen a estos efectos, a partir
de la aceptación de la fase Piloto.
1.4.
Contenido de la Propuesta Técnica:
a) Descripción del trabajo a realizar, en cada una de las fases.
b) Metodología a aplicar en cada fase y tarea.
c) Conformación del equipo de trabajo, detallando el número de integrantes por perfil,
formación y experiencia.
d) Carga horaria presencial de cada integrante del equipo propuesto para cada fase del
proyecto.
2
L.P. 07/16
e) Recursos que deberá poner a disposición ASSE en lo atinente a infraestructura.
f)
Recursos humanos que deberá poner a disposición ASSE con estimación de Horas
Hombre de ASSE por perfil, en cada fase.
g) Descripción de los entregables a generar como resultado de los servicios ofrecidos
en las diferentes fases.
h) Plan de Trabajo con cronograma que incluya el ítem d).
i)
ASSE podrá solicitar a los oferentes la realización de una presentación verbal de la
propuesta técnica.
1.5. Experiencia
• Las empresas oferentes y el personal adjudicado a las tareas del proyecto deben
contar con experiencia acreditada en implantación y desarrollo de HCE, experiencia
en desarrollo de Interoperabilidad (HL7, CDA-R2, XDS), uso de estándares
recomendados por IHE.
•
2.
Profesionales con formación en Informática, Medicina, Informática Médica y
Gerenciamiento de proyectos.
Introducción
2.1.
Antecedentes
ASSE es el principal prestador estatal de atención integral de salud. Brinda asistencia a
más de 1.300.000 uruguayos y cuenta con 28.000 funcionarios
Posee una red asistencial con más de 800 Unidades Asistenciales distribuidas en todo el
territorio nacional, de diferentes niveles de complejidad: 833 Consultorios, Policlínicas,
Centros de Salud, y Centros Auxiliares y 43 Hospitales.
Se realiza consulta ambulatoria de policlínica en todos los centros, con una producción
anual de más de 8 millones de consultas.
Actualmente se cuenta con un sistema denominado Escritorio Clínico (EC), en el que se
registra aproximadamente un 11% del total de consultas ambulatorias realizadas por los
médicos de todo el país.
2.2. Fundamentación
Las tecnologías de la Información y Comunicación ofrecen una nueva perspectiva de la
Continuidad Asistencial con la aparición del concepto de Historia Clínica Electrónica como
un sistema integrado de información para el área clínica de los Servicios de Salud.
En el marco de la Historia Clínica Electrónica y dentro de ella el registro de la consulta
ambulatoria no urgente, que a la fecha, se registra en el Sistema de Escritorio Clínico,
surge la necesidad de re-diseñar dicha herramienta, para dar mejora al registro en la
misma y lograr una integración a la HCE de ASSE y la HCE Nacional.
2.3.
Objetivos
•
Contar con una HCE que permita disponibilizar la información clínica de cada
usuario de ASSE, para que todo el personal de salud pueda accederlo y de esta
manera mejorar la continuidad Asistencial y la coordinación de los cuidados dentro
y fuera de la institución.
•
Sistema que permite el registro de la consulta ambulatoria no urgente centralizada
y descentralizada. Debe permitir registrar y almacenar el conjunto de datos clínicos
y paraclínicos (incluso los no digitales) que hacen referencia a los episodios de
3
L.P. 07/16
•
3.
salud y enfermedad de los usuarios de ASSE y a la actividad sanitaria que se
genera con motivo de esos episodios en el ámbito ambulatorio no urgente. Incluye
profesionales médicos y no médicos.
Esta HCE Ambulatoria debe seguir los lineamientos sugeridos por IHE y aceptados
por Salud.uy (AGESIC) para garantizar que el sistema cuente con
Interoperabilidad, integrandose a la HCEN (HCE Nacional).
Requerimientos
3.1.
Requerimientos funcionales
•
Información clínica compartida.
Acceso a toda la información necesaria para la atención del usuario (incluída la de
otras instituciones de Salud).
•
HCE única para cada usuario.
El PNA (Primer Nivel de Atención) deberá tener acceso a los registros asistenciales
generados por servicios del segundo y tercer nivel de atención. Igualmente esto es
aplicable a la inversa.
•
Integración con Agenda.
Debe interoperar con los sistemas de agenda, pudiendo ser más de uno.
•
Autenticación de usuarios.
Los usuarios serán autenticados en un sistema LDAP que será o bien desarrollado
enteramente por el oferente o bien adaptado de una solución pre-existente, lo que
se definirá conjuntamente con ASSE. Dicho sistema será un módulo independiente
del Sistema de HCE-A y podrá tener una evolución independiente. Se prevé que
en él puedan realizar su autenticación otros sistemas de ASSE
3.2. Análisis de los requerimientos funcionales
Se espera contar con una pantalla con cinco áreas bien definidas:
• Área de Datos Patronímicos, que muestre C.I., Nombre, edad, sexo y
Médico de Referencia. Pero mediante un link puede visualizar rápidamente
el resto de los datos patronímicos del paciente. Ésta información será
provista por un Web service de ASSE disponible a esos efectos
• Área de datos del Profesional actuante (Fecha y hora de consulta,
Unidad Asistencial, Especialidad y Nombre del profesional que asiste)
• Área de alertas y Problemas activos, Patologías crónicas diagnosticadas
(Diabetes, HTA y/ o Sobrepeso/obesidad), Alergias, Vacunas vencidas,
Consulta de control vencida o Consulta Pendiente).
• Área de menú (se detalla más adelante)
• Área central de la pantalla. Es el único espacio de la pantalla que varía
según la acción que solicite el profesional. Por ejemplo es aquí donde se
mostrará la agenda de pacientes a ser atendido en la fecha y hora, por el
profesional.
3.3.
•
Nueva Consulta
Búsqueda de un paciente
• Todo el personal de salud de ASSE registrado como usuario de la HCE-A,
podrá acceder a los datos clínicos de un paciente, buscando directamente
por algún dato patronímico del mismo, generalmente por su documento de
identidad, pero puede ser algún otro dato que maneje el Padrón de ASSE
(por ej. teléfono, Apellido, fecha de nacimiento, etc.). En caso de existir más
4
L.P. 07/16
•
de un paciente con el mismo dato de búsqueda se muestra la lista resultado
para que el profesional decida cuál invocar.
Se generará una auditoría que resgitrará cada acceso a una historia clínica
e indicará fecha y hora, así como identificará
quien accedió a la
información.Por otra parte, ASSE cuenta con sistemas de Agenda (Gestión
de Consultas, SGA,etc) que interoperará con la HCE-A para visualizar los
pacientes agendados para el médico, ayudando a invocar la HC del
paciente a atender. A medida que el médico va registrando consultas se va
formando además, el parte diario, evitando al profesional tener que llenar
formularios de parte diario en papel.
•
Motivo de consulta (Ver Servidor de Terminología)
Formato Texto libre Obligatorio. Para codificar con Código CIAP-2
mediante el Servidor de terminología. (El motivo será único por
consulta).
•
Anamnesis
Campo en formato texto, obligatorio.
•
Consulta de Control (SI/NO)
Se debe indicar el tipo de Consulta, porque en función del tipo de Consulta
se mostrarán diferentes plantillas a completar. También se debe analizar
algún otro tipo de requerimiento a fin de dar cumplimiento con las metas
asistenciales.
•
•
(NO) Los datos a registrar difieren fundamentalmente en el Examen Físico,
que solo deberá contener PA, Peso, Talla y Texto libre.
•
(SI) Para Med. General, Pediatras, Med. Familia, Med. Rural, Geriatras,
Ginecólogos y Parteras. El Examen físico y contenido del control registra los
datos requeridos en el control según pautas vigentes del MSP y se muestra
precargado con los datos de Control de enfermería.
Registro de Consulta de Control etario
• Mostrar y registrar los datos protocolizados para el control de cada rango
etario y mostrar las consultas anteriores para poder comparar valores,
incluso graficarlas para ver la evolución de datos clínicos como peso, talla,
IMC, PA, Triglicéridos, etc.
•
Una presentación intuitiva de los datos registrados en cada consulta puede
resolverse usando uno de los recursos de usabilidad conocido como
sistema de “Acordeón”, donde se muestran líneas con los principales
renglones o items de una consulta, expandiéndose al hacer clic sobre el
item a registrar o consultar (por ejemplo si se hace click sobre Exámen
Físico se abre el espacio suficiente para registrar los datos definidos para el
rango etario del paciente). Este recurso se puede “anidar” o sea, también se
podría presentar la información a registrar agrupada en formato de
acordeón.
•
Debe ser posible poder visualizar los datos de consultas anteriores
(parámetros predefinidos) para ver la evolución del paciente. (Ej. peso,
talla, IMC)
•
Los controles serán por sexo y edad, según pautas del MSP.
•
Dependiendo de si se completó o no la Consulta de Control, el sistema
sugiere la próxima fecha de control para que el médico la corrobore. Estos
5
L.P. 07/16
valores generarán alertas cuando se atienda nuevamente al paciente,
indicando si tiene Control Vencido.
•
Enfermería puede registrar datos de Control, Exámen Físico (PA y
mediciones antropométricas), además de Procedimientos (que sería
deseable que fueran codificados con un estandar) y actos de enfermería en
texto libre.
•
Reportes varios para enfermería y para el médico (ej. pacientes atendidos
con Consultas de Control vencidas, Pacientes atendidos con determinada
patología crónica, Procedimientos de enfermería realizados, por paciente o
por enfermero en un determinado período de tiempo...).
3.3.1 Conducta, Indicaciones
•
Básicamente se mostrará en la pantalla un cuadro de texto libre para la descripción
de las Indicaciones, que además de formar parte del CDA de la consulta, podrá ser
impreso para entregarle al paciente. junto con la prescripción medicamentosa.
•
Prescripción de fármacos, se debe disponer de la funcionalidad de seleccionar el
medicamento, la dosis, período, forma de administración y otras indicaciones.
Debe tener alertas de interacciones medicamentosas y de contraindicaciones por
alergias etc. además de contar con acceso a la información del medicamento
partiendo de la droga.
Se debe Interoperar con el sistema de Farmacia (WebFarma, etc) que se encarga
de mantener el stock de medicamentos desde la Compra hasta el despacho en
farmacia (controlando incluso el lote). Se enviaría mediante HL7 la prescripción
recibiendo información sobre la existencia o no de cada medicamento. Una vez
confirmada la prescripción, Farmacia lo registra como solicitud a atender, de forma
que cuando el paciente se presente con su Documento de Identidad ya tenga la
medicación para retirar. Concretado el retiro de la medicación el sistema de
Farmacia devolverá información de medicamentos retirados, (fecha, cantidad, etc.)
que se podrá mostrar mediante el botón MEDICAMENTOS.
•
•
Botón Medicamentos mostrará los medicamentos indicados en las
consultas previas, mostrando además de las dosis, etc. la fecha en que se
retiró de farmacia. También se podrán ver prescripciones realizadas por
otros profesionales (Ej. HCEO)
Desde aquí se podrán señalar los medicamentos de uso prolongado, no
solo para facilitar la prescripción y controlar la interacción medicamentosa
sino además para realizar las prescripciones de medicamentos para
enfermedades crónicas, previsto en el sistema de Farmacia.
Ordenes de servicio de paraclínica
• Para Imagenología, se debe contar con una pantalla de selección de tipo
de estudio, área a estudiar, motivo del estudio, etc. para la conformación de
una Orden de servicio (generada en formato CDA, teniendo la posibilidad de
imprimirla) que permite transferir esa información mediante estándares de
interoperabilidad al Sistema RIDI.
• Esta Orden de servicio habilitará al paciente a coordinar día y hora en la
Recepción del Sistema RIDI, solamente dando su identificación (CI, porque
el resto de la información ya fue enviada con la Orden de servicio generada
por el médico del ambulatorio)
• El CDA que genera el RIDI con el informe, será la forma de interoperar para
que la HCEA disponga de esa información para que el médico del
ambulatorio pueda verlo en el Botón Paraclínica y Procedimientos, que
6
L.P. 07/16
•
•
•
•
•
mostrará las ordenes de servicio (y su estado), los informes y las imágenes
mediante los CDA generados por el RIDI.
Para Laboratorio, se espera una lógica de interoperabilidad similar a la
descripta para Imagenología. O sea, una ventana donde se indique el tipo
de estudio, el motivo, etc. y se debe analizar una estructura que permita la
selección de estudios completos, o parciales, indicando el análisis
específico (ver estándar LOINC). También se conformará un documento
CDA (que permita imprimir la orden) y la IO con las Agendas de los
Laboratorios que habiliten al paciente a coordinar día y hora sin necesidad
de otros datos que su CI. Por último la interoperabilidad con Laboratorios
para la recepción de los resultados y la visualización de las Ordenes (su
estado) y los resultados en el Botón Paraclínica y Procedimientos.
Interconsulta o Pase
• Armar documento para imprimir pase a especialista, con motivo de la
interconsulta, etc., interoperando con los Sistemas de Agenda (Gestión de
Consultas, SGA, etc).
•
IO vía HL7 con las Agendas, de forma que cuando el usuario va a pedir
Fecha y hora ya esté el Pase habilitante.
•
Prever un Módulo de generación de Orden de Consulta o Pase vía CDA-R2
que luego pueda ser visualizado por el especialista como "documento pase"
(Hoy intrainstitución y a futuro disponible interinstitucionalmente).
•
Las Agendas devolverán la fecha y hora agendada para luego poder
consultarla en el Botón de Paraclínica y Procedimientos.
Procedimientos de enfermería
•
Texto libre con indicaciones de procedimientos para realizar al paciente
(curación, toma periódica de PA, etc.)
•
Estas indicaciones serán visualizadas por Enfermería al ingresar a la HCE
del paciente (en el Botón de Procedimientos de ENFERMERÍA) y el
personal de enfermería debe poder cambiar el estado del procedimiento de
“Pendiente” a “Realizado”, indicando la fecha y comentarios en texto libre.
•
También se generará un documento imprimible para entregarle al paciente
en caso de ser necesario.
Indicaciones para el Paciente
•
Texto libre con indicaciones particulares para el paciente (complementarias
de los folletos específicos para cada patología)
•
También se generará un documento imprimible para entregarle al paciente
en caso de ser necesario
Antecedentes
Los antecedentes estarán subdivididos y formulados según rango de edad, según
normativa MSP.
◦ Antecedentes del niño
◦ Antecedentes del adolescente
◦ Antecedentes del adulto.
◦ Antecedentes del adulto mayor
◦ Antecedentes del embarazo
7
L.P. 07/16
3.3.2
•
Servidor de
Diagnósticos)
Terminología
(Para
Problemas,
Motivos
de
consulta
y
Armar la pantalla que recoja el texto libre y en función de la devolución del Servidor
de terminología guíe al médico en la selección correcta del texto para lograr una
descripción homogénea de diagnósticos, motivos de consultas y eventualmente de
problemas, para lograr una sencilla y rápida codificación en CIAP-2 o CIE10 (a
definir, dependiendo del caso). Independientemente de la selección del texto
seleccionado en el Tesauro del Servidor de Terminología, se guardará el texto libre
original digitado por el profesional.
3.3.3. Registro de Vacunas
Registrar y mostrar para actualizar el esquema de vacunación en un formato similar
a la pag. 5 del carné de control del niño, usando checkbox. Además de las vacunas
de adultos obligatorias.
Parametrizar y mantener una lista de vacunas con su tiempo de vigencia, para el
registro y control de las vacunas obligatorias para adultos (como el caso de la
Antitetánica).
Se registrarán fechas de vacunación para poder mostrar alertas de vacunas
vencidas (solo para los casos en que el usuario ya tenga algún registro de vacunas,
para evitar alertas molestas al inicio de una HCE).
3.3.4. Uso del INUS.
•
Poder conocer los registros previos del paciente en otras Instituciones de Salud, de
los cuales se debería tener acceso a sus datos clínicos o consultas. (Ver
requerimientos no funcionales)
3.3.5 Lista de Problemas del paciente.
•
•
Pantalla de visualización y mantenimiento de Problemas.
Parametrización de Problemas y Diagnósticos que sugieran la creación de un
nuevo problema asociado al paciente o la asociación de la consulta a un problema
ya registrado para el paciente.
3.3.6. Consultas e Internaciones previas. (HCE)
•
•
•
•
•
Consultas previas realizadas en ASSE u otras instituciones mostrando los CDA del
XDS (por ej. Ambulatorio del HCEO)
Internación (IO con Geosalud)
Emergencia (IO con Historia de Emergencia y Egresos Hospitalarios GeoSalud,
etc)
Intervenciones Quirúrgicas (IO con Sistema de Descripción Operatoria)
Consultas del ambulatorio Oncológico (IO con HCE-O)
3.3.7. Botón de Embarazo (solo para sexo femenino)
•
•
Visualización de los datos registrados en el SIP (Sistema Informático Perinatal).
Enviar o recibir datos registrados en SIP.
3.3.8. Botones de Información
•
Información para el paciente. Link al sitio donde se guardará toda la folletería
informativa para las diferentes patologías y preparaciones para estudios
paraclínicos, etc. Se podrá sugerir el documento específico en función del
8
L.P. 07/16
•
•
diagnóstico y Orden de servicio, aunque el médico puede acceder al resto de los
documentos informativos o folletos para imprimir.
Documentos Médico Legales. Link al sitio donde se guardarán todos los
documentos médico legales que se deben imprimir para que firme el paciente.
Estos documentos firmados luego se adjuntarán a la HCE a través de su escaneo
para visualizarlo en el Botón de Documentos externos.
Documentos Externos. Permitirá visualizar todos los documentos digitalizados
que no son generados por el sistema, pero que fueron adjuntados a la HCE del
paciente a criterio del Médico (es el caso de estudios o imágenes digitalizadas o
impresas que el paciente tiene en su poder, también consentimientos legales,
informes de terceros sin IO, Anatomías Patológicas, etc.).
3.3.9. Reportes y estadísticas
•
•
•
Análisis de requerimientos de información estadística orientado a un módulo de
inteligencia de negocios . Diseño de las consultas y/o reportes esperados,
definición de data marts sencillos.
Coordinar conjuntamente con la contraparte técnica el tipo de datos necesarios
para implementar un Data Warehouse con las variables y dimensiones
necesarias de modo que resulte un aporte a la inteligencia del negocio
facilitando el análisis de la información orientado a la toma de decisiones.
Considerar la consolidación de la información proveniente tanto del nuevo
sistema como de otros sistemas ya existentes en ASSE.
En particular, tener en tiempo real el estado del cumplimiento de las Metas
establecidas por el MSP, parametrizado de tal forma que se puedan establecer
nuevas metas y modificar las actuales.
3.3.10. Usuarios del Sistema
•
•
•
Se identifican al menos estos perfiles de usuarios:
•
Médicos , Profesionales no médicos.
•
•
•
Enfermería.
Gestión
Administración del sistema
Mantenimiento y control de permisos (auditoría)
Autenticación de usuarios
Los usuarios serán autenticados en un sistema LDAP que será o bien desarrollado enteramente
por el oferente o bien adaptado de una solución pre-existente, lo que se definirá conjuntamente
con ASSE. Dicho sistema será un módulo independiente del Sistema de HCE-A y podrá tener
una evolución independiente. Se prevé que en él puedan realizar su autenticación otros sistemas
de ASSE.
Será un sistema web que debe incluir al menos las siguientes características:
•
•
•
Alta, baja, modificación y eliminación de usuarios y grupos (ABM)
Autogestión de contraseñas por los usuarios mediante pregunta secreta y/o
envió a cuenta de correo alternativa o SMS a teléfono móvil
posibilidad de gestionar separadamente los usuarios de sistemas en
diferentes regiones del país (por ejemplo un nivel de administración
nacional, otro regional, otro departamental)
9
L.P. 07/16
•
3.4.
Preveer Firma Digital de los médicos con la nueva C.I. Electrónica, que incluye un
chip de contacto para poder colocar la rubrica en documentos electrónicos y que se
estima la puedan tener todos los médicos antes del 2017. Para sumar las ventajas
de esta funcionalidad, es importante investigar y elegir un dispositivo de lectura que
no atente contra la usabilidad del sistema. (Sería bueno poder contar por ejemplo,
con alguna aplicación para usar los celulares como dispositivos de lectura del chip).
Requerimientos no funcionales
El Sistema de HCE del ambulatorio de ASSE debe ser desarrollado siguiendo las
recomendaciones de uso de estándares existentes, especificadas por IHE, que
también son adoptadas y recomendadas por Salud.uy (AGESIC) esto incluye el
uso de la arquitectua definida para el Sistema HCE-O pensando en la futura HCEN.
Auditoría
Se desarrollará un sistema de auditoría que permita dar seguimiento a la actividad realizada por
los administradores de sistema y muy especialmente al acceso que se realice a historias clínicas
de pacientes.
3.4.1. HCE Única y Nacional
El sistema debe alinearse a los estándares, arquitectura y procedimientos
sugeridos por Salud.uy (AGESIC) para lograr que la información clínica de un
paciente sea completa y esté disponible mediante la Plataforma de
Interoperabilidad para todos los Prestadores de Salud públicos y privados. (HCEN)
• Identificación única de usuarios (INUS)
• Registro XDS
• Seguridad y confidencialidad
CDA
Firma digital
• Uso de estándares recomendados (IHE consensuados por Salud.uy)
3.4.2. Interoperabilidad interinstitucional, a nivel nacional y regional
•
•
•
•
•
•
•
•
Trabajar con los equipos de desarrollo interno de ASSE para Interoperar
mediante HL7 entre los sistemas de ASSE involucrados (ver 4.4).
Trabajar con Agesic / Salud.uy (INUS, PDI, ESB en el marco del programa
de adopción para formar parte de la HCEN)
Definir Clasificaciones y Estándares necesarios para la implementación de
la Interoperabilidad pensando en la HCEN.
Trabajar con Salud.uy por el uso del servidor de terminología.
Utilizar tablas maestras ya definidas (Unidades Ejecutoras, Unidades
Asistenciales, Departamentos y Localidades)
Usar mensajería HL7 vía Bus de servicios Web.
Usar repositorio XDS con CDA-R2 para documentos con nivel 2 de
codificación (Consultas, Informes, Descripción operatoria, Recetas,
Resultados paraclínicos, etc.).
Usar los procedimientos de Interoperabilidad que Salud.uy disponga para
mantener Interoperabilidad con los datos Clínicos a destacar de cada
paciente (Alergias, Enfermedades crónicas, vacunas, medicación de uso
prolongado, etc.)
10
L.P. 07/16
3.4.3. Gestión de Cambio Organizacional
•
•
Soporte a la Gestión del Cambio, incluyendo servicio de capacitación, mejora de
procesos, generación, ejecución y seguimiento de planes de comunicación internos
y acciones tendientes a favorecer el buen uso del Sistema.
Diseñar, gestionar y ejecutar el Plan de Capacitación para la Implantación del
HCEA, dirigido a los usuarios de distintos perfiles (referentes, super-usuarios,
usuarios finales con perfil operativo, administrador y Mesa de Ayuda).
• El manual de usuario deberá permitir una comprensión del uso del sistema
en forma completa. Deberá asegurarse la generación de contenidos
digitales que permitan realizar una capacitación a distancia. Deberá
realizarse una instancia de capacitación para capacitadores.
Diseñar, gestionar y ejecutar el Plan de Comunicación.
3.4.4. Sistema Escalable
•
•
•
•
•
•
•
•
La aplicación debe ser independiente de las plataformas.
El sistema se realizará bajo el paradigma de tecnología WEB
Diseñar estructura de datos para interoperar con Sistemas propios y externos,
existentes y futuros. (CDA – XDS)
El sistema deberá ser Multitenant.
Multiplataforma a nivel de SO, BD y Servidor de Aplicaciones.
Debe poder funcionar en esquemas de alta disponibilidad y funciones de balanceo
de carga.
Debe poder permitir configuraciones escalables.
La solución debe garantizar la integridad y consistencia de datos.
3.4.5. Base de datos y Lenguaje de programación
•
•
Para el desarrollo se solicitará la utilización de Java. Se podrán usar
generadores que produzcan módulos en dicho lenguaje. El licenciamiento
requerido para el generador será de cargo del oferente. En caso de utilizar
generadores de alto nivel, se deberá entregar a ASSE la base de
conocimiento generada adicionalmente al código fuente.
Base de datos pautada por ASSE:
• MariaDB (MySQL)
3.4.6. Conectividad
•
•
•
Para el alcance Nacional, se deben buscar estrategias para poder continuar la
consulta teniendo mala conectividad a la red de ASSE.
• Para los puestos remotos 3G, tener una función sensora del ancho de
banda o tiempo de respuesta, para sugerir pasar automáticamente a una
versión de menor carga o tráfico. (Solo lo básico y con pantallas muy
simples, sin imágenes)
• Considerar también para esta funcionalidad, la posibilidad de contar con una
estructura que permita guardar la información de las transacciones de forma
que frente a la falta de comunicación con el remoto, se garantice poder
restaurar la sesión sin perdida del registro clínico, quedando el corte de
conexión transparente para el usuario.
Diseñar un módulo de registro Offline
Desarrollar una versión del sistema “Móvil” para celular o tablet que pueda
funcionar Offline, de manera que le permita al médico cargar la HCE de los
pacientes agendados o a visitar (en el caso del médico Rural) y de esa manera
11
L.P. 07/16
•
poder realizar las consultas sin necesidad de estar conectado a Internet. Se
definirá un mínimo de datos clínicos a registrar en este tipo de consulta Offline, que
no contará obviamente con las funcionalidades que requieran interoperabilidad. Los
datos registrados serán exportados al sistema HCE-A en formato CDA y se
registrarán los datos básicos de las consultas en la base de datos clínica.
En el proceso de Importación se usará el Servidor de terminología para "codificar"
el motivo de consulta y el diagnóstico, conservando siempre el texto original.
3.4.7. Seguridad
El sistema deberá contar con las herramientas de seguridad para garantizar la
confidencialidad, integridad y autenticidad de los datos.
• Auditoría de todas las transacciones llevadas a cabo por el sistema.
• Identificación unívoca del usuario que realiza las transacciones en los logs
de auditoría.
• Registro de los cambios realizados en el proceso de parametrización.
• El sistema deberá contar con los mecanismos para firmar electrónicamente
las transacciones llevadas a cabo por el usuario utilizando firma electrónica
avanzada (CDA)
• Estudio de factibilidad para el uso de la Cédula de Identidad Inteligente para
la firma digital de la consulta al generar el CDA.
• Pruebas de estrés del sistema previas a la implantación y al año de
implantado, realizadas por un tercero que certifique el tiempo de respuesta
del Sistema.
•
Especificar las tareas de mantenimiento correctivo, adaptativo, perfectible
y/o evolutivo sobre las funcionalidades desarrolladas.
3.4.8. Usabilidad
Para que el aplicativo resulte fácil e intuitivo para el usuario, debe conservar las
características intuitivas de navegabilidad de los principales aplicativos WEB.
Se requiere del desarrollo de un Prototipo del sistema, que permita validar el
diseño de la interfaz hombre/máquina, en particular, aspectos de look and feel y
usabilidad, que incluya las funcionalidades acordadas, antes de terminar el
desarrollo del sistema piloto.
Se debe mantener el mismo criterio de visualización utilizado para los distintos
sistemas asistenciales en ASSE.
3.5. Interoperabilidad con los sistemas:
Para las comunicaciones entre todos los componentes y la solución HCE-A, se
utilizarán estándares de la salud, como ser HL7, DICOM, etc., basados en los
perfiles IHE cuando aplique.
•
Sistema de Afiliaciones (Padrón de usuarios)
•
Consultas (SGC, SGA , etc)
•
Sistema de Médico de referencia
•
Farmacia (WebFarma)
•
Repositorio de datos clíncos
12
L.P. 07/16
4.
Equipos del Proyecto sugeridos
•
Equipo técnico permanente del proyecto de HCE del ambulatorio no urgente.
• Por el Oferente:
• Por parte del oferente se espera la conformación de un equipo de trabajo
interdisciplinario que sea capaz de atender profesionalmente los diferentes
requerimientos planteados.
• La dedicación debe ser acorde a la función y a la etapa del proyecto en que
interviene. A este equipo se sumarán los funcionarios de ASSE dedicados a
la contraparte.
• Estos técnicos integrarán a su vez equipos multidisciplinarios de trabajo con
médicos y técnicos referentes, designados por las direcciones de ASSE.
• Se trabajará interinstitucionalmente y con organismos y empresas
vinculadas para planificar y resolver la Interoperabilidad del Sistema.
• Documentar detalle del equipo de proyecto y sus funciones, previo al
cambio de cualquier integrante deberá ser aprobado por la Dirección de
ASSE.
5.
Cronograma
El Oferente debe presentar el cronograma detallando las fases y los hitos del proyecto.
6.
Estructura propuesta por ASSE para colaborar con la implantación.
Los usuarios del sistema son profesionales médicos y no médicos que realizan consultas
ambulatorias no urgentes y que integran el equipo de salud de las Unidades Asistenciales
con nivel variable de conocimiento y uso de herramientas informáticas.
La Mesa de ayuda será proporcionada por ASSE y capacitada por el Oferente.
7.
Servicios solicitados al Oferente que se coordinarán al inicio del Proyecto.
La siguiente lista no restringe al proveedor para entregar otra documentación o elementos
de apoyo que considere útiles para alcanzar el completo y correcto cumplimiento de lo
solicitado.
Soporte técnico
◦ Corrección de errores y análisis de fallas
◦ Transferencia de conocimiento
◦ Documentación y asesoramiento técnico
◦ Actualización tecnológica
◦ Definir niveles de Soporte en función de criticidad.
Soporte funcional
Administración y operación
◦ Migración
◦ Respaldos
◦ Monitoreo
◦ Auditoría
◦ Registro de incidentes.
Fases, entregables y tiempos del Cronograma
Análisis detallado con entregables documentados.
Testing
◦ Incluir los casos de prueba elaborados y los procedimientos de
documentación de realización de las pruebas. Para los Test
unitarios, integrales y de seguridad.
13
L.P. 07/16
◦ Debe ser confeccionado de tal manera que pueda ser reproducido y
verificado toda vez que se lo desee. Esto implica la automatización del
procedimiento del testing.
Mantenimiento
Implantación
8.
Restricciones
•
•
•
•
•
•
•
•
El Sistema debe poder correr en cualquier Navegador WEB.
Debe tener una buena performance trabajando con modem 3G que es como se conectan
muchos médicos, usando las Netbook entregadas por ASSE.
Se deben respetar las sugerencias de IHE aceptadas por AGESIC, tanto en la definición
de estándares usados para la sintaxis como para la semántica de la Interoperabilidad
según cada caso de uso (HL7, LOINC, SNOMED, OIDs).
Se debe usar la arquitectura de Interoperabilidad sugerida por Salud.UY para la HCEN.
Se deberá proveer mantenimiento correctivo, adaptativo, perfectible y/o evolutivo sobre
las funcionalidades desarrolladas por el tiempo que se defina en la contratación de los
servicios. Se debe pensar en el mantenimiento durante el peródo de ejecución del
proyecto y cotizar por separado el mantenimiento para el año siguiente a la finalización del
proyecto.
Debe existir una efectiva transferencia de conocimiento al personal de ASSE
dependiente de la Dirección de Informática de ASSE, para poder hacer mantenimiento y
mejoras independientemente de que la empresa que desarrolle el Sistema de HCE-A
preste además un servicio de soporte y mantenimiento post-implantación.
Deberá diseñarse un plan para la transferencia tecnológica, especificando las
actividades a realizar, los documentos que serán provistos, sus contenidos, y las
instancias de transferencia.
•
Incluye documentos de especificación de requerimientos, de arquitectura y diseño,
como así otras consideraciones técnicas de implementación. También incluye los
documentos en versión digital, actualizados, del Modelo de datos de las bases de
datos, el Diccionario de datos de las bases de datos y los Casos de Uso.
•
Adicionalmente en la ejecución del proyecto deberán entregarse manuales de
usuario, operación, instalación, herramientas de desarrollo, administración,
respaldos, monitoreo de servicios y toda documentación que permita una adecuada
transferencia de conocimientos.
•
Así mismo deberá detallar la metodología del proceso de diseño y desarrollo de la
solución.
•
Debe contar como mínimo con ambientes de desarrollo, test, capacitación,
preproducción y producción, independientes.
•
Se debe disponibilizar la base de conocimientos y su código fuente para poder
realizar las modificaciones que se consideren oportunas.
•
Resulta un requerimiento que todo software desarrollado y entregado a ASSE que
haya sido solicitado en el marco de ésta licitación cuente con una licencia de uso,
modificación, y redistribución a favor del ASSE sin restricciones. Para esto es
imprescindible que ASSE pueda regenerar cualquiera de las aplicaciones
solicitadas, en el marco de la presente licitación, a partir de los códigos fuentes,
que deberán ser entregados en tiempo y forma sin necesidad de adquirir
herramientas y/o librerías externas en cualquier momento
La metodología de dirección de proyectos deberá ser compatibles con estándares
internacionales.
14
L.P. 07/16
El plan Director del proyecto debe contener como mínimo documentos que reflejen:
• Identificación de interesados
• Cronograma
• Plan de recursos humanos CV del equipo del oferente, roles y responsabilidades
• Plan de capacitación
• Plan de comunicaciones
• Plan de transferencia tecnológica
• Riesgos
•
La conformidad es el resultado de la validación de los entregables, de acuerdo a una serie
de criterios acordados al inicio del proyecto, cuando se determinen los entregables y sus
atributos cuantificables y calificables.
•
El oferente deberá proporcionar la infraestructura con los equipos necesarios (servidores,
notebook, tablet, etc) y adecuados a las tareas que el equipo realizará en el transcurso del
proyecto.
• El equipo de trabajo se ubicará físicamente en las instalaciones de ASSE,
contemplando las necesidades operativas de cada etapa, donde parte de ellos
podrán trabajar físicamente en las instalaciones del oferente.
En la eventualidad de que algún integrante del equipo de proyecto del oferente deba
desplazarse para cumplir los encargos/requerimientos, los costos que este desplazamiento
implique (traslados, alojamiento, viáticos) serán exclusivamente del adjudicatario.
• CONFIDENCIALIDAD Los datos recabados y procesados durante el desarrollo y posterior
implantación del software son de uso exclusivo de ASSE.
9.
Anexos
9.1 Anexo I - Pautas para el Desarrollo de Sistemas Informáticos de ASSE
9.2:Anexo 2 – Evaluación de las propuestas.
15
L.P. 07/16
CONDICIONES GENERALES
(Licitaciones Públicas de contrataciones en modalidad Plaza)
1) PRESENTACIÓN DE LA OFERTA:
Las ofertas podrán ser presentadas exclusivamente el día fijado para el Acto de Apertura:
a) Personalmente, en la Recepción de la Dirección Recursos Materiales (of.326) por escrito en
original y dos copias, firmadas por el representante de la Empresa oferente con aclaración de
firma o sello, foliadas (enumeradas sus hojas), en sobre cerrado en cuyo exterior se
establecerá el nombre de la firma oferente y el número y objeto de la Licitación.b) Por fax - *Dentro de las cuarenta y ocho horas del envío del fax deberá presentarse el original
de la oferta firmada y sellada, acompañada de la documentación que bajo el título “Presentación
de la oferta” se indica que debe presentarse en original. (Será de cargo del oferente verificar la
recepción efectiva del fax enviado y que el mismo fue recepcionado en forma legible).
Se sugiere que la presentación de ofertas se efectúe hasta treinta minutos antes de la hora
indicada para el acto de apertura para su mejor diligenciamiento por parte de la Administración.
El acto de apertura de ofertas se llevará a cabo cualquiera sea el número de ofertas
presentadas.
Documentación a presentar conjuntamente con la oferta:
Las ofertas deberán presentarse con dos copias, acompañadas de la siguiente documentación:
a) Formulario de cotización (Anexo III)
b) Antecedentes del oferente y experiencia documentada en la realización de servicios similares y
toda la información que a su juicio sea necesario para evaluar sus antecedentes.
c)Constitución del Equipo de Trabajo que tendrá a su cargo el desarrollo de las tareas
encomendadas, adjuntando currículum vitae de sus integrantes.
d)Información que acredite la antigüedad en el ramo
e) Para el caso de que la oferta en su alternativa mayor supere el límite máximo de las
Licitaciones Abreviadas ($7.585.000) deberá presentarse con carácter obligatorio depósito de
garantía de mantenimiento de oferta por la suma de $75.850*.
f) Lista de Verificación (Anexo IV)
INFORMACION QUE DEBE CONTENER LA OFERTA:
En la oferta se deberá indicar:
a) Declaración de la firma que incluya: plazo para el inicio de los trabajos (a partir de la emisión y
envío al adjudicatario de la correspondiente Orden de Compra)
b) Cronograma detallando fases e hitos del proyecto
IMPORTANTE:
La documentación y la información solicitada, según detalle que antecede, deberán ser presentados
en el orden establecido según Anexo III.
2) FORMA DE COTIZAR:
La forma de cotizar será, de acuerdo a los ítems solicitados, la siguiente:
1) Desarrollo e implementación de Sistema de Historia Clínica Electrónica (HCE). Licenciamiento.
Precio total del desarrollo y precio de licenciamiento por separado, en moneda nacional o dólares.
Los precios deberán establecerse sin impuestos indicando por separado los mismos. En caso
contrario se considerarán inlcuídos en el precio ofertado.
2) Mantenimiento anual finalizado el proyecto. Precio mensual del servicio de mantenimiento y
precio total para el período, en moneda nacional. Los precios deberán establecerse sin
impuestos indicando por separado los mismos. En caso contrario se considerarán inlcuídos en el
precio ofertado.
16
L.P. 07/16
3) Valor hora para futuras modificaciones o solicitud de servicios adicionales, en moneda
nacional. Los precios deberán establecerse sin impuestos indicando por separado los
mismos. En caso contrario se considerarán inlcuídos en el precio ofertado.
NO SE ACEPTARAN OFERTAS QUE ESTABLEZCAN INTERES POR MORA.
3) SISTEMA DE PAGO:
Crédito, a través del SIIF, dentro del plazo estimado de noventa días contados a partir del último
día del mes al que pertenece la factura.
Facturación:
La facturación para el ítem 1 Desarrollo del Software, será por avance y cumplimineto de hitos,
debiendo contar con informe técnico por parte de ASSE que avale el cumplimiento.
El licenciamiento se facturará una vez entregado.
La facturación del servicio de mantenimiento luego de culminado el proyecto se realizará
mensualment, a mes vencido.
Las cantidad de horas por servicios adicionales serán avaladas por la administración para su
posterior facturación.
Las facturas deberán presentarse en la moneda solicitada en la forma de cotización, según el
íítem, debidamente conformadas, en la Dirección Recursos Materiales.
No se aceptarán facturas en que se establezcan intereses por mora o ajustes por pago
fuera de fecha. Si la factura contuviera impresa alguna referencia a esos extremos, por el solo
hecho de presentar oferta, se entiende que las firmas aceptan que la Administración anule dicha
referencia mediante sello u otro medio similar en forma previa a su tramitación.
NO SE ABONARAN EN NINGUN CASO INTERESES O AJUSTES POR MORA
4) MANTENIMIENTO DE OFERTA: 180 días. Vencido dicho plazo la vigencia de las ofertas se
considerará automáticamente prorrogada por 90 días más, salvo manifestación expresa en
contrario por parte de los oferentes.
5) ACTUALIZACION DE PRECIOS:
Se aplicará cláusula de actualización de precios para los ítems 2 y 3.
La actualización del monto del mantenimiento y valor hora será: 20% por IPC en forma semestral
(1 de enero y 1 de julio de cada año) y 80% de acuerdo a la variación de los salarios en los
momentos y porcentajes que se acuerden para el grupo de actividad que corresponda.
P 1= PO * [(0.2 * (A1 / A0) + 0.8 * (B1+1)]
P0= precio cotizado en la propuesta
P1= precio actualizado de la propuesta
A0 = Índice de Precios al Consumo (IPC) al mes anterior a la fecha de la apertura de ofertas
(para el primer ajuste)
A1 = Índice de Precios al Consumo (IPC) del cierre de mes anterior al ajuste.
Para el cálculo de la variación del IPC en el caso del primer ajuste, se considerará el período
transcurrido entre el último día del mes anterior al de la apertura y el 31 de diciembre o 30 de
junio según sea el caso. Para los siguientes ajustes en caso de corresponder, se aplicará la
formula sobre los precios actualizados por los indices acumulados en el semestre anterior.
B1 = % de aumento según consejo de salarios de la actividad respectiva.
17
L.P. 07/16
6) DE LA EVALUACION DE LAS OFERTAS Y ADJUDICACION:
I. CRITERIOS /PONDERACIONES
La comparación de las Ofertas para su posterior adjudicación, se efectuará ajustándose en un
todo a las Condiciones del Pliego, y Ponderando el Análisis de las mismas con los Criterios
definidos por la Administración, de acuerdo a los porcentajes que se describen en Anexo II
(Numeral 9.2.1 Evaluación de las propuestas).
II. Referente a empresas oferentes que deseen acogerse a los beneficios o márgenes de
preferencia para bienes/servicios nacionales.
Se aplicará el margen de preferencia de acuerdo a lo establecido en el Numeral 10.5.1 del Pliego
Único de Bases y Condiciones General para los Contratos de Suministros y Servicios No
Personales, la empresa deberá presentar el ANEXO I del mencionado Pliego.
Referente a las empresas oferentes que deseen acogerse a los beneficios o márgenes de
preferencia para bienes/servicios nacionales de MIPYMES.
Se aplicará el margen de preferencia de acuerdo a lo establecido en el Numeral 10.5.2. del Pliego
Único de Bases y Condiciones General para los Contratos de Suministros y Servicios No
Personales.
III. UNA VEZ PROPUESTA LA ADJUDICACION POR PARTE DE LA COMISION ASESORA Y
ANTES QUE SE EXTIENDA LA RESOLUCION CORRESPONDIENTE, LA ADMINISTRACION
CONTROLARÁ QUE EL PROVEEDOR ESTE ACTIVO EN RUPE.
“De acuerdo al Art. 14 del Dcto. 155/013 es responsabilidad del proveedor mantener
actualizada su ficha tanto en datos como en documentos.”
IV. LA ADMINISTRACIÓN DE SERVICIOS DE SALUD DEL ESTADO SE RESERVA EL
DERECHO DE:
1) Adjudicar total o parcialmente el llamado o dejar sin efecto el mismo en cualquier etapa del
procedimiento según se estime conveniente a los intereses de esta Administración.
2) aumentar las cantidades a adjudicar en hasta un cien por ciento si durante el curso del
procedimiento licitatorio y en forma previa a la resolución de Adjudicación surgieran nuevas
necesidades, para lo cual se requerirá el consentimiento del proveedor seleccionado como futuro
adjudicatario y en caso de considerarlo pertinente podrá solicitar una mejora de precios.
7) OFERTAS SIMILARES/NEGOCIACIONES
En caso de que se presentaran ofertas similares A.S.S.E. se reserva el derecho de entablar
negociaciones con aquellos oferentes que precalifiquen a tal efecto, a fin de obtener mejores
condiciones técnicas, de calidad o de precio.
Asimismo la Administración podrá realizar negociaciones tendientes a la mejora de oferta en los
casos de precios manifiestamente inconvenientes. Para el caso de recibirse ofertas en diferentes
monedas se utilizará como criterio para la comparación el dólar interbancario vendedor del Banco
Central del día anterior a la fecha de apertura.
8) INCUMPLIMIENTOS
A.S.S.E. se reserva el derecho de rescindir unilateral y administrativamente el contrato por su sola
voluntad en caso de incumplimientos por parte de la Empresa adjudicataria de cierta gravedad o
entidad o por mediar reiteración de incumplimientos leves respecto de las obligaciones
estipuladas en los Pliegos, sin derecho a reclamo alguno contra la Administración quedando está
18
L.P. 07/16
habilitada a disponer la pérdida del depósito de garantía, suspender la firma del Registro de
Proveedores de la Institución y realizar la comunicación respectiva al RUPE.
9) GARANTIAS
Para el caso que el monto total de la oferta supere el monto límite de las licitaciones abreviadas
$7.585.000 (considerando impuestos incluidos), los oferentes deberán presentar con carácter
obligatorio depósito de mantenimiento de oferta por el 1% del monto mínimo que rige para las
licitaciones públicas ($ 7.585.001). En tal caso, los mismos deberán presentarse y efectuarse en
avales bancarios, póliza del Banco de Seguros del Estado, a favor de A.S.S.E., certificación
bancaria de que en la Institución existen fondos depositados en moneda nacional o en dólares
americanos, a la orden de la Administración o depósito en efectivo en pesos o dólares en la
cuenta Fondo de terceros de A.S.S.E., del BROU (solicitar número de cuenta).
Los documentos expedidos por bancos privados deberán venir con firmas certificadas por
escribano público.En los casos que los documentos de depósito establezcan fecha de vencimiento de la misma no
deberá ser inferior a un año a partir de la fecha de apertura. Los documentos de depósito deben
ser únicos y particulares para el presente llamado.Para el caso que el monto de la adjudicación supere la suma de $ 3.034.000 el adjudicatario
deberá presentar dentro de los cinco días hábiles de recibida la notificación de la adjudicación,
depósito de garantía de fiel cumplimiento de contrato por el 5% del monto total de la adjudicación
en las mismas condiciones previstas para los depósitos de garantía de mantenimiento de oferta.
El depósito tiene carácter obligatorio. Éstos serán devueltos una vez finalizada la relación
contractual, contra la presentación del correspondiente recibo de depósito, conformado
por el responsable de controlar el buen cumplimiento del servicio.
10) ACLARACIONES Y PRORROGA
Los oferentes podrán solicitar por escrito y presentado directamente ante el Departamento de
Adquisiciones de A.S.S.E aclaración respecto al mismo hasta siete días hábiles antes de la
fecha de apertura, teniendo la Administración un plazo de setenta y dos horas para evacuar las
mismas.
Para solicitar prórroga de la fecha de apertura, los adquirientes de pliego deberán presentar la
solicitud por escrito en el referido Departamento, con una antelación mínima de siete días
hábiles a la fecha fijada para la apertura, acompañada de un depósito a favor de A.S.S.E.
equivalente a 20 Unidades Reajustables. La prórroga será resuelta por la Administración según
su exclusivo criterio.Todas aquellas modificaciones al pliego, aclaraciones y respuestas a consultas que
puedan surgir de parte de las firmas y/o de la Administración serán publicadas en la pág.
web de compras estatales siendo responsabilidad de las empresas interesadas el
consultar periódicamente dicho medio a fin de tomar conocimiento y notificarse de las
mismas.
RIGEN PARA ESTE LLAMADO LO DISPUESTO EN: EL PRESENTE PLIEGO Y EN EL PLIEGO
UNICO
DE
BASES
Y
CONDICIONES
GENERALES
(ver
en
sitio
web
www.comprasestatales.gub.uy) Y EN EL TOCAF - DCTO. 150/12 – (ver en sitio web
www.cgn.gub.uy).
VALOR DEL PLIEGO: SIN COSTO
Montevideo, 30 de mayo de 2016.- (SV/cg)
IMPORTANTE: La entrega de pliegos se efectuará en el horario de 9.15 a 13.45hs., debiendo
retirarse los mismos en la Of. 326 (3º piso).
√ PLAZO ÚLTIMO PARA EL RETIRO DEL PRESENTE PLIEGO: JUEVES 23 DE JUNIO DE 2016
HASTA 13.45hs.
19
L.P. 07/16
9.1 - Anexo I
Pautas para el Desarrollo de Sistemas
Informáticos de A.S.S.E.
Indice de contenido
1. INTRODUCCIÓN............................................................................ 22
2. Ambientes en ASSE........................................................................ 22
3. Ambientes de desarrollo:................................................................ 22
4. Ambientes de Prueba:.................................................................... 22
5. Ambiente de capacitación:.............................................................. 23
6. Ambiente de Producción:................................................................ 23
7. Plataforma.................................................................................... 23
8. Sistemas de Apoyo al Desarrollo y Testing......................................... 23
9. PAUTAS GENERALES...................................................................... 24
10. PAUTAS A CONSIDERAR POR LOS DESARROLLADORES.......................24
11. Contraseñas.................................................................................. 24
12. Sistemas Web............................................................................... 25
13. Ingreso al Sistema/Autenticación..................................................... 25
14. Sobre el Ingreso y la autenticación de los Sistemas ............................25
15. Documentación............................................................................. 25
16. Modelo de Datos............................................................................ 26
17. Apariencia/Interfaz/Navegación....................................................... 26
18. Ingreso de Datos / Formularios........................................................ 26
19. Validación de Datos........................................................................ 28
20. Despliegue de Información/ Presentación de Datos............................. 28
21. Reportes/Exportación..................................................................... 29
22. Manejo de Errores/Control de Excepciones. .......................................29
23. Manejo de comunicaciones por e-mail............................................... 29
24. Consideraciones de seguridad.......................................................... 30
25. Otros........................................................................................... 30
26. APROBACIÓN................................................................................ 31
20
L.P. 07/16
INTRODUCCIÓN
Se describen en esta sección algunas características básicas que son de interés para
desarrolladores de sistemas de software para ASSE.
Confidencialidad de la información
La información registrada en los sistemas de ASSE es confidencial y la contraparte
(desarrolladores internos o las empresas proveedoras de sistemas) no tendrán acceso a la
misma.
En caso que fuese necesario para la contraparte el acceso a la información éste será
debidamente autorizado por la Dirección de Informática de ASSE.
Si por causa fortuita se accediera a dicha información, la contraparte se obliga a guardar estricto
secreto y absoluta reserva sobre la que llegue a su conocimiento.
Ambientes en ASSE
ASSE dispone de diferentes ambientes para los sistemas informáticos.
Ambientes de desarrollo:
Solo para los equipos desarrolladores de Dirección Informática de ASSE.
Ambientes de Prueba:
Se cuenta con dos ambientes de prueba donde el Área de Testing ejecuta las pruebas al Sistema,
el volumen de datos es reducido y los datos se desea que sean sintéticos. En este ambiente solo
pueden haber versiones candidatas a llegar a producción.
Testing funcional:
T1lib: Ambiente de Prueba.
T2lib: Ambiente de Prueba (alternativo).
Testing no-funcional:
Pre-Producción: Es un ambiente similar a producción en cuanto a arquitectura de componentes,
tamaño de hardware, y volumen de datos. Su objeto son pruebas no funcionales de aplicaciones,
scripts y procesos.
21
L.P. 07/16
Ambiente de capacitación:
Ambiente destinado para Capacitar a los Usuarios finales de un nuevo Sistema o módulo. Se
deberá suministrar conjuntos de datos/scripts para la fabricación de información sintética que
permita la capacitación. Se dispone de los mismos sistemas que en producción.
Ambiente de Producción:
Este ambiente corresponde al que acceden los usuarios finales del sistema.
Toda manipulación en los ambientes referidos (exceptuando los de desarrollo), se realiza por
parte del equipo de operaciones de Dirección Informática de ASSE, utilizando instrucciones y
scripts suministrados por proveedores (internos o externos).
El requisito general es que las aplicaciones pasen por los diferentes ambientes y sean sometidas
a diferentes pruebas de acuerdo a las características del sistema y cada ambiente. La ejecución
de scripts y despliegue se realizan de acuerdo a las instrucciones de los proveedores, teniendo
que ejecutarse la totalidad de las tareas de forma correcta. Ante la ocurrencia de errores, los
mismos no se corrigen, sino que se devuelven al desarrollador o proveedor para su corrección, y
volver a iniciar el proceso.
Plataforma
Estructura de los despliegues en la infraestructura:
1. un balanceador (Apache HTTP server + mod_jk) activo y uno pasivo (LinuxHA);
2. cada aplicación será desplegada en dos servidores virtuales, sobre hardware físico
diferente;
3. Los componentes de despliegue (balanceador, contenedores y RDBMS) corren sobre
sistema operativo GNU/Linux.
4. las bases de datos tienen esquemas de replicación automatizados (réplica de logs binarios,
master-slave, etc.), según el motor.
Sistemas de Apoyo al Desarrollo y Testing
Se cuenta con Subversion como herramienta de versionado.
Se cuenta con Redmine como la plataforma de documentación del desarrollo de los sistemas, sus
especificaciones técnicas y el registro de incidentes que se presenten en cualquiera de las etapas.
Wiki interna de Dirección de Informática para la documentación técnica (http://wiki.edlibertad.asse/wiki/)
InfoASSE Portal de Información Interna para publicar información relacionada a los sistemas.
(http://info.asse.com.uy/)
22
L.P. 07/16
PAUTAS GENERALES
1. Todos los sistemas asistenciales consultarán los datos patronímicos del beneficiario (paciente)
mediante un WS publicado el cual consumirá los datos del Padrón de Usuarios de ASSE.
2. El desarrollo de los sistemas será realizado preferentemente en lenguaje JAVA o Genexus
generando en JAVA, quedando sujetos a análisis y aprobación de la Dirección de Informática los
desarrollos en lenguajes diferentes.
3. El motor de base de datos será MariaDB o PostgreSQL en sus versiones vigentes quedando
sujeto a análisis y aprobación de la Dirección de Informática la utulización de otras DB diferentes.
4. Los sistemas asistenciales desarrollados, propios y externos, deberán soportar para el
intercambio de información clínica el conjunto de estándares HL7. Ver http://www.sueiidiss.org/
PAUTAS A CONSIDERAR POR LOS DESARROLLADORES
Se listan a continuación una serie de aspectos que deberán ser tenidos en cuenta a efectos del
desarrollo de aplicaciones.
En caso de no cumplir con alguna de las indicaciones deberá
fundamentarse el motivo y acordar con la contraparte interna de ASSE cuál es el mecanismo de
resolución. Las pautas establecidas están numeradas a efectos de poder hacer un seguimiento de
las mismas en el correspondiente Formulario de verificación de cumplimiento.
Contraseñas
1. Las contraseñas no se almacenarán ni serán transmitidas en texto plano en ningún sistema o
medio.
Sistemas Web
1. Para los sistemas o aplicativos con interfaz web el desarrollo deberá contemplar los elementos
necesarios para un comportamiento correcto, específicamente en el navegador Mozilla Firefox
2. Utilizar variables de sesión y no las URL para transmitir valores entre transición de páginas.
3. Controlar/Inhibir que el usuario utilice el botón “Atrás” del navegador. Particularmente para las
transiciones que implican el re-envío de datos, por ejemplo tras una página de confirmación de
ingresos.
Ingreso al Sistema/Autenticación
Sobre el Ingreso y la autenticación de los Sistemas
23
L.P. 07/16
4. El usuario y contraseña del Sistema se validara contra un servidor openLDAP existente en
ASSE (éste será el control de acceso).
5. Cuando se pierda la sesión, avisar al usuario y direccionarlo o desplegar un enlace al login del
sistema.
Documentación
6. Todos los sistemas o aplicativos deberán contar con su correspondiente documento de
especificación de requerimientos funcionales y la documentación técnica.
7. Elaborar la documentación de usuario con la mayor sencillez posible y con un capítulo de
Preguntas Frecuentes que se irá actualizando a medida que se utiliza el Sistema.
8. Para la puesta en producción del Sistema la documentación de usuario deberá estar disponible
y actualizada en el Portal de Información Interna de ASSE, actualmente (http://info.asse.com.uy/)
9. Documentación completa de lógica de negocios y su API que permita la interacción con otras
aplicaciones por fuera de la interfaz provista.
Modelo de Datos
10. Documentación completa del modelo de datos.
11. Para el diseño de las bases de datos se seguirán los principios de la guía de la cartilla
BD:Principios_de_Diseño.pdf adjuntando un documento de diseño arquitectónico.
Apariencia/Interfaz/Navegación
Sobre la apariencia, los menús y la navegación de los sistemas. Se debe incluir:
12. El logo de ASSE en la esquina superior izquierda.
13. El nombre del Sistema (sin abreviaturas) seguido por la versión en el centro superior. La
versión en un tamaño inferior al nombre del Sistema.
14. El usuario conectado (eventualmente el perfil y la Unidad Asistencial donde esta posicionado)
más la fecha y hora del sistema en la
esquina superior derecha junto con un link para
desloguearse del sistema.
24
L.P. 07/16
15. En la parte inferior de la pantalla se visualizará la dirección de correo de soporte, otros datos
de contacto que deberán estar visibles sin necesidad de estar autenticado.
16. El enlace a la documentación del usuario (ubicado en el portal de información interna).
17. Elementos que permitan identificar si se está en un ambiente de prueba o en producción (por
ejemplo: poder ajustar desde un usuario administrador una imagen con la palabra “PRUEBA”
arriba a la derecha muy visible)
18. El look-n-feel deberá gestionarse desde css (Cascading Stile Sheets), pudiendo
personalizarse por usuario y ajustarse globalmente por parte de ASSE.
19. Los Pop-up deberán estar restringidos a la pestaña actual del navegador.
Ingreso de Datos / Formularios
Sobre la entrada de datos a los sistemas por parte de los usuarios.
20. Controlar el ingreso de los campos obligatorios y marcarlos con un asterisco (*) en la etiqueta
del formulario (por ejemplo: “Nombre*”).
21. Todos los controles deben ser multinivel, tanto a nivel de la presentación, lógica y base de
datos.
22. Alertar en la confirmación de la lista de campos obligatorios no completados.
23. Para minimizar el error de “TIPEO” se tomara en cuenta la utilización de tablas maestras con
valores codificados normalizados y estándares.
24. Usar descripciones emergentes sensibles al contexto, para ayudar al ingreso de los datos.
(Tooltip, overlay)
25. Para los campos críticos del negocio (como ser los de atención de salud) distinguir los datos
no declarados explícitamente por el usuario de los valores nulos o por defectos. Motivo: Se dan
situaciones en las que se está seleccionado un valor válido por defecto (por ejemplo Altura 0 cm),
cuando el usuario no declaro tal valor (se debería guardar vacío o sin/datos) (estudiar el
contexto).
25
L.P. 07/16
26. Si el valor seleccionado en controles de tipo Radio Button, Combos desplegables o Checklists
alteran la necesidad de ingresar otros datos (por ejemplo: un Textbox de comentario, otro combo
desplegable) habilitar o inhibir de acuerdo a los valores de los primeros.
27. Cuando se ingresa una cédula de identidad, controlar que sea válida (validar el dígito
verificador). El almacenamiento a nivel de persistencia de la CI será definido por ASSE.
28. La confirmación del Ingreso/Modificación de Formularios extensos, complicados o sensibles
debe hacerse con una vista distinta a la de ingreso, donde solo se muestren los datos
Ingresados/Modificados por el usuario. Esto esta motivado por la necesidad de que un Usuario
pueda realmente prestarle atención a los datos que esta confirmando.
Validación de Datos
Controles a ejecutar sobre los datos que se ingresan.
29. Controlar que los campos numéricos solo acepten números de acuerdo al contexto (por
ejemplo: Edad en años solo debería admitir enteros positivos no mayores que 200). Los campos
de fecha se deben controlar que reciban valores válidos (fechas válidas y contexto, que la fecha
de inicio no sea posterior a al fecha de fin).
30. Los campos de texto, deben controlar que no se ingresen más caracteres de los que
soportan, ni caracteres especiales no soportados por la codificación de la plataforma (por
ejemplo: ś).
31. Validar los campos con características propias como ser; los campos de texto que son correos
electrónicos, los de número de RUT.
32. Los mensajes de alertas deben incluir la información que utiliza en la evaluación. Por ejemplo:
“El Monto en $ debe ser mayor a 0”, “La fecha de alta debe ser mayor o igual a la de ingreso
(01/03/2010)”). Esto facilita al usuario corregir los datos que esta ingresando, sin tener que volver
a pasos anteriores del proceso.
Despliegue de Información/ Presentación de Datos
Sobre la forma de mostrar la información
33. La descripción de los errores debe informar al usuario cuales son los campos incorrectos (al
menos el primero según el orden de ingreso en la pantalla de haberse producidos más de uno), y
además informar que tipo de dato es el válido para el mismo (por ejemplo: “Edad no válida, la
26
L.P. 07/16
edad debe ser un numero entero mayor o igual a cero”, “Fecha de alta no válida, la fecha debe
ser posterior a la fecha de alta (20/01/2011)”, “Observaciones los campos marcados con * no
pueden ser nulos/vacíos”).
34. Las operaciones sensibles al sistema (como ser borrado de un registro) deberán tener un
diálogo de confirmación y que este contenga los datos de la acción y datos relevantes (por
ejemplo: “Desea eliminar la reserva de hora para Odontólogo de JUAN CARLOS PEREZ PEREZ
(CI: 1.123.456-7)
Reportes/Exportación
Exportar información/Reportes
35. Para cualquier reporte/exportación a documentos pdf, de texto o planillas de cálculo, controlar
los permisos de sesión.
36. Los reportes a imprimir deben generarse en planilla de cálculo (opendocument) ó pdf y el
usuario elegirá la opción más conveniente.
Manejo de Errores/Control de Excepciones.
Sobre el manejo de errores y el control de excepciones, logs
37. Las excepciones del Sistema deberán ser capturadas y registradas en un archivo de log.
38. Los logs podrán configurarse para definir el nivel de registro en tiempo de ejecución.
39. Se deberán utilizar los mecanismos de log de la plataforma, en caso de JEE, se prefiere e
Log4J
Manejo de comunicaciones por e-mail
40. Toda aplicación que envíe e-mails debe hacerlo usando como origen y/o destino direcciones
de correo validas y alcanzables desde Internet, además en el caso de la dirección de origen, la
misma debe existir y se debe asignar a una persona que chequee dicha casilla de correo
periódicamente.
41. Si la aplicación pretende emplear la infraestructura de correo electrónico de ASSE , deberá
autenticarse mediante el mecanismo dispuesto para dicho fin ( SMTP-AUTH por ejemplo ) y el
usuario que utilice para dicho fin debe coincidir con el nombre de usuario de la dirección de
correo.
27
L.P. 07/16
42. La aplicación deberá garantizar que cuenta con controles de cantidad de e-mails generados ,
de modo de no saturar al servidor ni a los destinatarios bajo ninguna circunstancia.
Consideraciones de seguridad
43. Las aplicaciones que utilicen mecanismos de autenticación y/o autorización, deberán registrar
los accesos incluyendo fecha,usuario,origen(por ejemplo dirección IP cuando corresponda ) y el
resultado de la validación (éxito o fracaso), así mismo deberá registrar información relacionada al
mecanismo de autorización .
44. Se deberá informar al usuario cuando fue su último acceso a la aplicación y desde donde
(indicando la dirección ip en caso que corresponda).
45. Se deberá implementar que las aplicaciones estén atentas a la cantidad de intentos fallidos de
acceso y que generen mensajes de alerta en caso de detectarse comportamientos anómalos.
46. Se deberán implementar los mecanismos que des estimulen ataques por fuerza bruta (por
ejemplo el uso de captcha o tarpitting).
Otros
47. El acceso a Base de datos para actividades recurrentes se realizará solo a través del sistema.
48. La aplicación solamente utilizará conexiones a BD definidas en pooles de conexiones
gestionados por el contenedor. La aplicación debe desconocer las credenciales de acceso a la
BD.
49. Se definirán pooles de conexiones diferentes para modificaciones de datos y para consultas.
La aplicación solamente hará modificaciones en el pool de conexiones r/w y canalizará todas las
consultas al pool de conexiones r/o. ASSE podrá definir réplicas master-slave o multimaster para
soportar este requerimiento de acuerdo a su conveniencia.
50. Separar datos de parametrización de sistema de los datos asistenciales o de proceso en
sistemas de gran porte. Dicha separación se realizará a nivel de BD diferentes.
51. Migración de sesiones
desde el balanceador para instalación de nuevas versiones.
(considerar balanceador de carga y sistemas corriendo en dos servidores en paralelo)
28
L.P. 07/16
52. En caso de ser un sistema que requiera mucha parametrización, poder hacer una copia de la
configuración en el ambiente de Pre-producción al de producción (considerar si hay que hacer un
upgrade de Pre-producción desde producción antes).
53. Se deberá capacitar a los usuarios finales del Sistema (o ante una nueva versión) antes de
ser puesto en producción.
29
L.P. 07/16
9.2. - Anexo 2
Evaluación de las propuestas
ASSE evaluará las propuestas en base a lo indicado en el artículo siguiente y al cumplimiento de
lo estipulado en los Términos de Referencia (TDR).
9.2.1. REQUISITOS EXIGIDOS A LAS EMPRESAS OFERENTES.
Los oferentes deben contar con experiencia documentada en la realización de servicios
similares a la que es objeto de este llamado.
• Incluir contratos ejecutados en organizaciones estatales.
• Experiencia en la implantación de metodologías o modelos utilizados para
los servicios requeridos.
• Experiencia en el sector salud y en organismos públicos.
Se valorará especialmente que el equipo consultor presentado por la empresa
contenga los siguientes perfiles:
α) Ingenieros en Sistemas con conocimiento documentado (experiencia) en
Sistemas de Gestión Hospitalaria e Interoperabilidad.
β) Doctores (al menos un doctor) en Medicina con formación en informática
aplicada a la medicina.
9.2.2. COTIZACIÓN
La cotización debe incluir configuración y parametrización del software, capacitación a
capacitadores y capacitación a 200 usuarios finales.
Opcionalmente se deberá cotizar instancias de capacitación a usuarios finales en grupos de no
más de 20 personas. Pueden cotizarse otras modalidades de capacitación por ej. A distancia.
Se debe cotizar el mantenimiento a futuro en forma separada
Se deberá cotizar el valor hora para futuras modificaciones o solicitud de servicios adicionales.
La política a seguir será la siguiente:
ASSE especificará los requerimientos. El Proveedor definirá la cantidad de horas que le
demanda el requerimiento.
ASSE autorizará ó rechazará dichas horas a la puesta en producción del nuevo requerimiento,
el proveedor deberá dar las mismas garantías.
9.2.3. Evaluación de las propuestas
Para la evaluación de las propuestas se considerará un máximo del 60% para la
propuesta técnica y 40% para la propuesta económica.
Propuesta técnica se tomarán en cuenta los siguientes factores:
•
Plan de trabajo
•
Metodología de Gestión de Proyectos a utilizar.
•
Metodología sugerida para el proceso de gestión del cambio.
30
L.P. 07/16
•
Experiencia en proyectos en el área salud en Uruguay.
•
Tiempo propuesto para la ejecución del proyecto.
Criterios de Evaluación Técnica
Criterio
Puntare Máximo
Plan de trabajo
20
Currículum del equipo de trabajo: se valorará cada currículum en
función de su formación, experiencia en áreas relacionadas, tiempo a
dedicar con respecto al tiempo total del proyecto
15
Experiencia de la empresa en proyectos relacionadas a la informática
de la salud
10
Metodología de gestión de proyectos
5
Metodología propuesta de gestión del cambio
5
Tiempo propuesto para la ejecución del proyecto
TOTAL
5
60
Criterios de Evaluación Económica
La fórmula para determinar los puntajes de precio es la siguiente:
40×Pb
Pi
Puntaje Económico =
, donde Pb es el precio más bajo entre las ofertas que califican, y
Pi el precio de la propuesta en consideración
En caso de que el resultado de T y/o P tenga decimales, se aplica el siguiente criterio: si el valor
del primer decimal es 5 o más, aumenta el valor de las unidades en uno (redondeo, no truncado).
31
L.P. 07/16
ANEXO III
FORMULARIO DE COTIZACION
Ítem
Descripción
Moneda
1
Desarrollo e implementación
de Sistema de HCE
$
Ítem
Descripción
Moneda
2
Servicio de mantenimiento
finalizado el proyecto
$
Total
items
Descripción
Moneda
Precio
s/impuestos
Impuestos
Precio Total
imp. Incl.
Precio
mensual
s/impuestos
Impuestos
Total anual
imp. incl.
Sub - total
s/impuestos
Impuestos
Monto total
ofertado
Desarrollo e implementación
de Sistema de HCE
1y2
Servicio de mantenimiento
anual finalizado el proyecto
(12 meses)
$
Monto total
item 1 y 2
Ítem
Descripción
3
Valor hora para futuras
modificaciones o solicitud
de servicios adicionales
Precio hora
Moneda
s/impuestos
Impuestos
Precio total
hora
imp. incl.
$
Por empresa: ...............................................................................
Firma: .........................................................................................
Aclaración de firma: ......................................................................
C.I.:.............................................................................................
32
L.P. 07/16
ANEXO IV
LISTA DE VERIFICACION
Control de documentación y requisitos del pliego
Campos a completar por la empresa
Descripción
Formulario de cotización (Anexo III)
Plazo de entrega y tiempo de respuesta a los llamados
Mantenimiento de oferta
Documentación que acredite la antigüedad en el ramo
Solicitado en
pliego
Ofertado por la
empresa
(Nombre de la
empresa)
Nº foja de la oferta en la que
se especifica
Control
Administración
Cumple SI/NO
si
Especificar
180 días
Mínimo 2 años
Referencias documentadas de los últimos lugares donde haya
prestado servicios
Mínimo 2
referencias
"Quienes se amparen a las normas de protección a la
Industria Nacional deberán presentar Declaración Jurada Anexo I
del Pliego Único de Bases de Condiciones Generales"
si
Depósito de garantía de mantenimiento de oferta en caso de
superar el límite de L.A. $ 7.585.000.
si
Lista de verificación (Anexo IV)
si
Firma:..............................................................................
Aclaración de firma:.....................................................
C.I.:............................................................................
33
L.P. 07/16
ANEXO IV
LISTA DE VERIFICACION
Control de documentación y requisitos del pliego
Campos a completar por la empresa
Descripción
Formulario de cotización (Anexo II)
Plazo de entrega y tiempo de respuesta a los llamados
Mantenimiento de oferta
Documentación que acredite la antigüedad en el ramo
Solicitado en
pliego
Ofertado por la
empresa
(Nombre de la
empresa)
Nº foja de la oferta en la que
se especifica
Control
Administración
Cumple SI/NO
si
Especificar
180 días
Mínimo 2 años
Referencias documentadas de los últimos lugares donde haya
prestado servicios
Mínimo 2
referencias
"Quienes se amparen a las normas de protección a la
Industria Nacional deberán presentar Declaración Jurada Anexo I
del Pliego Único de Bases de Condiciones Generales"
si
Depósito de garantía de mantenimiento de oferta en caso de
superar el límite de L.A. $ 7.585.000.
si
Lista de verificación (Anexo IV)
si
Firma:..............................................................................
Aclaración de firma:.....................................................
C.I.:............................................................................
34