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: [email protected] 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