FONDO PARA HOSPITALES DE CARABINEROS DE CHILE
-------------------------------------------------

PROYECTO:

“SISTEMA DE GESTIÓN HOSPITALARIA”

BASES PARA LICITACIÓN

6 de Agosto de 2011

Tabla de Contenidos. SECCIÓN BASES ADMINISTRATIVAS 9 RESOLUCIÓN 10 REQUISITOS Y CONDICIONES DE LOS OFERENTES 13 PROCESO DE LICITACIÓN 14 DISPOSICIONES CONTRACTUALES 20 SECCIÓN BASES TÉCNICAS 28 1 INFORMACIÓN GENERAL 29 1.1 INTRODUCCIÓN 29 1.2 ANTECEDENTES. 29 1.3 el adquirente del sistema de gestión hospitalaria 30 1.4 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL. 30 1.5 EL PROYECTO DE Sistema de GESTIÓN Hospitalaria: 32 2 OBJETIVOS DEL PROYECTO 34 2.1 INFORMACIÓN GENERAL 34 2.1.1 Para el área Clínica: 34 2.1.2 Para el área Administrativa 34 2.1.3 Para la Gestión Hospitalaria 35 2.1.4 Para la Institución: 35 2.1.5 Para el beneficiario del Sistema de Salud de Carabineros: 36 2.2 OBJETIVOS DEL PROYECTO: 36 2.3 CARACTERÍSTICAS TÉCNICAS QUE DEBE TENER LA SOLUCIÓN BUSCADA. 38 2.3.1 Características de Arquitectura 39 2.3.2 Características funcionales: 40 2.3.3 Características de estándares: 41 2.3.4 Características de seguridad: 41 2.4 LA ARQUITECTURA DEL PROYECTO Y SU POSIBILIDAD DE EXPANSIÓN 42 2.4.1 LA RED DE SALUD: 43 2.4.2 EL REGISTRO CLÍNICO ELECTRÓNICO o FICHA CLÍNICA ELECTRÓNICA (FCE): 43 2.4.3 EL ERP (Enterprise resource Planning) 44 2.4.4 CAPA DE SEGURIDAD: 44 2.4.5 IDENTIFICACIÓN BIOMÉTRICA: 44 2.4.6 EL FUNCIONAMIENTO: 44 2.4.7 CAPACIDAD DE EXPANSIÓN POTENCIAL (EVENTUAL) 45 2.4.8 DATACENTER: 45 2.5 los OFERENTEs 46 3 plazo del proyecto 47 4 MATERIA LICITADA: 48 4.1 Un Registro Clínico Electrónico: 48 4.2 Un ERP(ENTERPRISE RESOURCE PLANNING) 48 4.2.1 Finanzas. 49 4.2.2 Recursos Humanos 49 4.2.3 Bienes y Activos 49 4.3 UNA HERRAMIENTA DE INTEGRACIÓN 50 4.4 Herramientas complementarias 50 4.5 SERVICIOS COMPLEMENTARIOS 51 4.6 Documentación del Sistema: 51 4.7 LICENCIAS 52 5 CARACTERÍSTICAS FUNCIONALES DE LA SOLUCIÓN DEL “SISTEMA DE GESTIÓN HOSPITALARIA” 53 5.1 MÓDULOS REQUERIDOS para el área clínica Y SUS FUNCIONALIDADES. 53 5.1.1 MÓDULO CLÍNICO (MÓDULO MÉDICO) 53 5.1.2 MÓDULO DE ATENCIÓN DE ENFERMERÍA 64 5.1.3 MÓDULO DE NUTRICIÓN 71 5.1.4 MÓDULO DE FORMULARIOS Y CERTIFICADOS 72 5.1.5 GESTIÓN DE ATENCIÓN DE URGENCIA: 75 5.1.6 GESTIÓN DE ATENCIÓN DE CAMAS CRÍTICAS: 77 5.1.7 MÓDULO DE GESTIÓN DE PABELLONES QUIRÚRGICOS. (quirófanos) 78 5.1.8 MÓDULO DE GESTIÓN DE ESTERILIZACIÓN 82 5.1.9 MÓDULO DE FARMACOLOGÍA 84 5.1.10 MÓDULO DE SERVICIOS DE APOYO 85 5.1.11 MÓDULO DE ATENCIÓN EN POLICLÍNICO 87 5.1.12 mÓDULO DE ANATOMÍA PATOLÓGICA 90 5.1.13 MÓDULO DE ODONTOLOGÍA 93 5.1.14 MÓDULO INFECCIONES INTRAHOSPITALARIAS 98 5.1.15 MÓDULO DE MANEJO DE FICHAS CLÍNICAS DE PAPEL 100 5.1.16 MÓDULO DE INFORMACIÓN DEL PACIENTE (KIOSCOS DE AUTOSERVICIO) 102 5.1.17 mÓDULO ARCHIVO MAESTRO DE PACIENTES 103 5.1.18 MÓDULO DE AGENDA MÉDICA 105 5.1.19 mÓDULO DE HOSPITALIZACIÓN (GESTiÓN DE CAMAS) 111 5.1.20 MÓDULO de GESTIÓN DE CENTROS DE SALUD FAMILIAR Y DE PROGRAMAS DE SALUD 113 5.1.21 mÓDULO DE CUENTA DE PACIENTES (Puede ser parte de lA FCE o del ERP) 114 5.1.22 módulo de aranceles (Puede ser parte de lA FCE o del ERP) 117 5.2 MÓDULOS opcionales de laboratorio y banco de sangre 119 5.2.1 MÓDULO DE LABORATORIO CLÍNICO 120 5.2.2 MÓDULO DE BANCO DE SANGRE 123 5.3 MÓDULOS REQUERIDOS para el área DEL ERP (AUXILIARES administrativOS Y SUS FUNCIONALIDADES) 126 5.3.1 Requerimientos Generales. 126 5.3.2 Requerimientos Específicos. 126 5.3.2.1 Área Financiera y Contable. 126 5.3.2.1.1 Contabilidad General 126 5.3.2.1.2 Presupuesto. 130 5.3.2.1.3 Tesorería, BANCOS COMERCIALES, Conciliación Bancaria Y Control De Documentos en Garantía 131 5.3.2.1.4 Costos. 134 5.3.2.1.5 Proveedores, Cuentas por Pagar y Administración de Contratos. 136 5.3.2.1.5.1 Proveedores 136 5.3.2.1.5.2 Gestión de Contratos 137 5.3.2.1.6 Ingresos, Facturación, Cuentas por Cobrar, Rendiciones y Caja 138 5.3.2.1.6.1 Ingresos 138 5.3.2.1.6.2 Manejo de Fondos y Anticipo de Proveedores 141 5.3.2.1.6.3 GESTIÓN DE Caja 141 5.3.2.1.6.4 Facturación 142 5.3.2.2 Abastecimiento – Bodegas – Existencia – Activos 143 5.3.2.2.1 Abastecimiento y Gestión de Compras 143 5.3.2.2.2 RECEPCIÓN DE PRODUCTOS EN BODEGAS 154 5.3.2.2.3 Existencias, Gestión de Catálogos, 157 5.3.2.2.3.1 Existencias 157 5.3.2.2.3.2 Bodega de Farmacia 159 5.3.2.2.3.3 Gestión de Catálogos 160 5.3.2.2.4 Control de Demanda 168 5.3.2.2.5 Activo Fijo. 170 5.3.2.2.6 Activos de Producción (Maquina, Equipos, Flotas) y Mantenimiento 172 5.3.2.2.6.1 ADMINISTRACIÓN DE EQUIPOS Y MAQUINARIAS 172 5.3.2.2.6.2 ADMINISTRACIÓN DE ÓRDENES DE TRABAJO (OT) 179 5.3.2.2.6.3 ADMINISTRACIÓN MANTENIMIENTO PREVENTIVO 180 5.3.2.2.6.4 MONITOREO POR CONDICIÓN 182 5.3.2.2.6.5 MATERIALES Y REPUESTOS 182 5.3.2.2.6.6 MODELO DE EQUIPOS/UBICACIONES FUNCIONALES 183 5.3.2.2.6.7 ADMINISTRACIÓN DE PERSONAL MANTENIMIENTO 184 5.3.2.2.6.8 GESTIÓN MANTENIMIENTO DE LOS ACTIVOS 184 5.3.2.2.6.9 COSTOS Y PRESUPUESTO DE REPUESTOS 185 5.3.2.3 Recursos Humanos 185 5.3.2.3.1 Remuneraciones 186 5.3.2.3.2 Viáticos. 191 5.3.2.3.3 Administración De Personal 191 5.3.2.3.4 Reclutamiento, Mantención y Desarrollo de RR.HH 193 5.3.2.3.5 Gestión de Alimentación del Personal del HOSCAR 194 5.3.2.4 Homologación/Traspasos. 195 5.4 ESPECIFICACIóN DE HERRAMIENTAS DE GESTIóN 195 5.4.1 BUSINESS INTELLIGENCE (BI) 195 5.4.2 Cuadro De Mando Integral Hospitalario (Balanced Score card) 197 5.4.3 DATAWAREHOUSE 197 5.4.4 IR-GRD 197 5.5 La plataforma de integración: 197 5.6 EL PROCESO DE IMPLANTACIÓN. 198 5.6.1 Metodología de implantación. 198 5.6.2 Cronograma general del proyecto 199 5.6.3 Comité ejecutivo del proyecto 199 5.6.4 Aportes del FONDO al proceso de implantación: 200 5.7 servicios conexOs con el proceso de implantación: 200 5.7.1 organización del equipo del proyecto 200 5.7.2 Levantamiento y reingeniería de Procesos: 201 5.7.3 GESTIÓN DEL CAMBIO 202 5.7.4 Plan de Capacitación 204 5.7.5 Integración de aplicativos. 205 5.7.5.1 Integración con aplicativos legados. 205 5.7.5.2 Integración con sistemas externos. 206 5.7.5.3 Intercambio de información Clínica con otras Fichas Clínicas Electrónicas (“Pseudo Integración”). 207 5.7.6 Migración de datos: 207 5.8 Dimensionamiento del sistema. 209 5.8.1 LICENCIAS DE ERP Y FCE 209 5.8.2 EL HARDWARE DEL / de los DATACENTER PRINCIPALes 210 5.8.3 LA IDENTIFICACIÓN BIOMÉTRICA 211 5.8.4 LA FIRMA ELECTRÓNICA PRIVADA 211 5.8.5 EL IR-GRD 211 5.8.6 EL DWH 212 5.8.7 LA HERRAMIENTA DE BI 212 5.8.8 las Comunicaciones. 212 5.8.9 las Estaciones de trabajo CLÍNICO. 212 5.9 Seguridad del sistema. 212 5.10 Prueba general de la solución previo a la puesta en marcha. 214 5.11 CERTIFICACIÓN DEL SISTEMA. 214 5.12 Marcha blanca. 215 5.13 Documentación y manuales de usuario y de servicio 215 5.13.1 Manuales de aplicativos: 215 5.13.2 Manual de ayuda. 215 5.13.3 Manuales de contingencia. 215 5.13.4 Documentación: 215 6 Garantía sobre los productos 217 7 OPERACIóN y soporte POST GARANTÍA del sistema 218 8 EVALUACIÓN DE LAs ofertas 221 8.1 INSTRUCTIVO PARA PRESENTACIÓN DE LAS OFERTAS 221 8.1.1 Listado de Chequeo de documentos a presentar 221 8.1.5 Instrucciones para EL completado de planillas de Autoevaluación 224 8.1.6 Recomendación 225 8.2 CARACTERÍSTICAS TÉCNICAS MÍNIMAS EXIGIDAS. CONDICIÓN PREVIA A LA EVALUACIÓN. 225 8.3 TABLA DE EVALUACIÓN GENERAL 229 8.4 EXPERIENCIA DE LA EMPRESA 229 8.5 PRECIO DEL PROYECTO LICITADO 232 8.6 CONTRATO DE SERVICIO SOPORTE Y MANTENCIÓN POST-GARANTÍA 233 8.7 EVALUACIÓN FUNCIONAL DE FCE Y ERP 235 8.8 PRUEBA DE CONCEPTO 239 8.8.1 LABORATORIO DE PRUEBA 239 8.9 LICENCIA CORPORATIVA 245 8.10 PLAN DE GESTIÓN DEL CAMBIO Y CAPACITACIÓN 245 8.11 APORTE DE MÓDULOS DE LABORATORIO Y BANCO DE SANGRE 247 9 CRONOGRAMA DEL PROCESO DE LICITACIÓN 249 10 hitos de pago 250 11 información y ESTADÍSTICAS de la red de salud 254 11.8 UBICACIÓN Y TIPO DE establecimientos que forman parte de la Red de Salud METROPOLITANA de CARABINEROS 255 11.9 UBICACIÓN geográfica Y TIPO DE establecimientos que forman parte de la Red de Salud REGIONAL de CARABINEROS 256 11.10 ANCHO de banda disponible en los enlaces de comunicaciones 257 11.11 ESQUEMA GENERAL DE COMUNICACIONES (Esquema Referencial Actual) 258 11.12 ESQUEMA GENERAL LAN ACTUAL DEL HOSCAR 259 11.13 APLICATIVOS informáticos actualmente en uso 260 11.14 HOSCAR: ATENCIONES AMBULATORIAS EFECTUADAS AÑO 2010 264 11.15 HOSCAR: CAMAS Y EGRESOS HOSPITALARIOS AÑO 2010 264 11.16 CANTIDAD DE profesionales del área CLÍNICa 265 11.17 CANTIDAD DE personal de apoyo del área CLÍNICa 265 11.18 PERSONAL profesional del área administrativa HOSCAR 266 11.19 PERSONAL técnico del área administrativa 266 11.20 PERSONAL auxiliar HOSCAR Año 2010 267 11.21 DOTACIÓN DE QUIRÓFANOS E INTERVENCIONES QUIRÚRGICAS 267 11.22 DETALLE DE SERVICIOS CLÍNICOS 268 11.23 ATENCIONES ODONTOLÓGICAS por especialidad Hoscar año 2010 269 11.24 Dotación de CLÍNICAS dentales hoscar 2010 269 11.25 GLOSARIO DE SIGLAS 270 12 formularios de presentaciÓn y evaluación 275 12.1 CARACTERÍSTICAS TÉCNICAS INDISPENSABLES 276 12.2 CARACTERÍSTICAS FUNCIONALES DE LA FCE: 280 12.2.1 MÓDULO CLÍNICO 280 12.2.2 MÓDULO DE ENFERMERÍA 292 12.2.3 MÓDULO DE NUTRICIÓN 298 12.2.4 MÓDULO DE FORMULARIOS Y SOLICITUDES 300 12.2.5 GESTIÓN DE ATENCIÓN DE URGENCIA 303 12.2.6 GESTIÓN DE ATENCIÓN DE CAMAS CRÍTICAS 305 12.2.7 GESTIÓN DE PABELLONES QUIRÚRGICOS (QUIRÓFANOS) 306 12.2.8 ESTERILIZACIÓN 310 12.2.9 FARMACOLOGÍA 312 12.2.10 SERVICIOS DE APOYO CLÍNICO (SERVICIOS INTERMEDIOS) 314 12.2.11 MÓDULO DE POLICLÍNICO 316 12.2.12 ANATOMÍA PATOLÓGICA 318 12.2.13 ODONTOLOGÍA (DENTAL) 322 12.2.14 MÓDULO DE IIH (INFECCIONES INTRA HOSPITALARIAS) 327 12.2.15 MÓDULO DE MANEJO DE FICHAS CLÍNICAS (DE PAPEL) 328 12.2.16 KIOSCOS (INFORMACIÓN DE AUTOSERVICIO) 330 12.2.17 ARCHIVO MAESTRO DE PACIENTES (CLIENTES) 332 12.2.18 AGENDA 334 12.2.19 GESTIÓN DE CAMAS 339 12.2.20 MÓDULO de GESTIÓN DE CENTROS DE SALUD FAMILIAR Y DE PROGRAMAS DE SALUD 343 12.2.21 CUENTA DE PACIENTES 344 12.2.22 ARANCELES 347 12.3 CARACTERÍSTICAS FUNCIONALES DE LOS MÓDULOS OPCIONALES. 349 12.3.1 BANCO DE SANGRE 350 12.3.2 LABORATORIO CLÍNICO 353 12.4 CARACTERÍSTICAS FUNCIONALES DEL ERP 356 12.4.1 CONTABILIDAD 356 12.4.2 ADMINISTRACIÓN DE PRESUPUESTOS 361 12.4.3 TESORERÍA 363 12.4.4 GESTIÓN DE COSTOS 368 12.4.5 GESTIÓN DE PROVEEDORES 370 12.4.6 Gestión de Contratos 373 12.4.7 INGRESOS: General 375 12.4.8 Ingresos: Manejo de Fondos y Anticipo de Proveedores 379 12.4.9 Ingresos: Gestión de Caja 381 12.4.10 FACTURACIÓN 383 12.4.11 ABASTECIMIENTO 384 12.4.12 GESTIÓN COMPRAS 388 12.4.13 RECEPCIÓN DE PRODUCTOS EN BODEGAS 400 12.4.14 BODEGA FARMACIA 404 12.4.15 EXISTENCIAS 406 12.4.16 GESTIÓN DE CATÁLOGOS 408 12.4.17 CONTROL DEMANDA 418 12.4.18 ACTIVOS FIJOS 419 12.4.19 Gestión de Mantención de Equipos y Maquinarias 422 12.4.20 PERSONAL - REMUNERACIONES 432 12.4.21 PERSONAL - VIÁTICOS 439 12.4.22 ADMINISTRACIÓN DE PERSONAL 440 12.4.23 RECLUTAMIENTO Y DESARROLLO RRHH 442 12.4.24 GESTIÓN ALIMENTACIÓN DE RRHH 444 13 CASOS DE USO PARA EVALUACIÓN 446 13.1 Caso de Evaluación Nº 1 446 13.2 Caso de Evaluación Nº 2 447 13.3 Caso de Evaluación Nº 3 448 13.4 CASO DE EVALUACIÓN Nº 4: INTEGRACIÓN SIGFE II 449 13.5 CASO DE EVALUACIÓN Nº 5: RECEPCIÓN DE PAGOS DE PRESTACIONES 450 13.6 CASO DE EVALUACIÓN Nº 6: PAGO DE PROVEEDORES 451 13.7 CASO DE EVALUACIÓN Nº 7: RECEPCIÓN DE BODEGA CON EAN-128 452 13.8 CASO DE EVALUACIÓN Nº 8: RECEPCIÓN BODEGA CON AUTOMATIZACIÓN 453 14 ANEXOS DE BASES ADMINISTRATIVAS 454 14.1 ANEXO Nº 1: DECLARACIÓN DE PROBIDAD Y CONFLICTO DE INTERESES 454 14.2 ANEXO Nº 2: IDENTIFICACIÓN DEL OFERENTE 455 14.3 ANEXO Nº 3: DECLARACIÓN DE CONFORMIDAD 456 14.4 ANEXO Nº 4: DECLARACIÓN JURADA ART. 8 Y 10 DE LA LEY Nº 20.393. 457

* SECCIÓN BASES ADMINISTRATIVAS

BASES ADMINISTRATIVAS

sistema DE GESTIÓN HOSPITALARIA

* RESOLUCIÓN
APRUEBA BASES ADMINISTRATIVAS Y ANEXOS Nº 1, Nº 2, Nº 3 Y Nº 4, Y LAS BASES TÉCNICAS PARA LA IMPLEMENTACIÓN E IMPLANTACIÓN DE UN SISTEMA DE GESTIÓN HOSPITALARIA.

RESOLUCIÓN Nº _____/ SANTIAGO,

VISTO:

a. Lo preceptuado en la Ley Nº 19.886, de Bases sobre Contratos Administrativos de Suministro y Prestación de Servicios, y en el Decreto Nº 250 de fecha 09 de marzo del 2004, del Ministerio de Hacienda, publicado en el Diario Oficial de fecha 24 de septiembre del 2004, sobre Contratos Administrativos y Suministros y Prestaciones de Servicios, que aprueba el reglamento de la referida ley de conformidad a lo señalado en Capítulo IV, y sus modificaciones pertinentes. b. El artículo 1º, del D.F.L. Nº 1, de 1981, del Ministerio de Defensa Nacional, que concede personalidad jurídica al Fondo Para Hospitales de Carabineros de Chile. c. La facultad contemplada en el decreto Nº 412 de 1991, que en su artículo 4º, otorga al Señor Director de Salud la representación legal del Fondo Para Hospitales de Carabineros de Chile. d. El artículo 4º del D.F.L. (I) Nº 2, de 1968, Estatuto del Personal de Carabineros de Chile. e. Los objetivos previstos en el artículo 2º, del Decreto con Fuerza de Ley Nº 1, de fecha 23 de diciembre de 1981, del Ministerio de Defensa Nacional, Subsecretaría de Carabineros, que crea el denominado Fondo para Hospitales de Carabineros de Chile. f. La administración del mismo FONDO, confiada al Sr. Director de Salud de Carabineros, según lo preceptuado en el artículo 4º, inciso final, del Decreto con Fuerza de Ley (I) Nº 2, de 1968, del Ministerio del Interior, modificado por el artículo 1º, número 4º, letra c) del Decreto con Fuerza de Ley Nº 1, de 1998, del Ministerio de Defensa Nacional, Subsecretaría de Carabineros. g. Lo establecido en la Resolución Nº 1600, de fecha 30 de octubre del 2008, de la Contraloría General de la República, que establece normas sobre exención del Trámite de Toma de Razón; y, que deroga lo preceptuado en la Resolución Nº 520, de fecha 15 de noviembre de 1996, que fijaba el texto refundido, coordinado y sistematizado de la Resolución Nº 55, de 1992. h. Las demás disposiciones legales y reglamentarias que rigen esta materia, y en uso de las facultades que me conceden la ley y los reglamentos vigentes.

CONSIDERANDO:

a. Que, dentro de los elementos a implementar para lograr el objetivo de contar con un Sistema de gestión Hospitalario integrado e integral, se incluyen un aplicativo destinado al Registro Clínico Electrónico (más conocido entre los usuarios clínicos como FCE = Ficha Clínica Electrónica), y un aplicativo Administrativo – Financiero conocido como ERP (Enterprise Resources Planning) b. Que, el sistema configurado con las herramientas informáticas ya mencionadas debe permitir la gestión tanto del Fondo Para Hospitales de Carabineros de Chile, Centros Médicos Dentales, Policlínicos, con que cuenta el Fondo, Dirección de Salud de Carabineros de Chile, Hospital de Carabineros, configurados como entidades contables independientes, algunas de las cuales deben poder consolidarse contablemente. c. Que, para la administración y su red de salud los ejecutivos cuentan en la actualidad con diversos sistemas informáticos, de desarrollo propietario realizado en diversos lenguajes de programación, orientados principalmente a la gestión administrativa, y que no se encuentran integrados entre sí, ni cuentan con estándares HL7. d. Que, el registro de las actividades y acciones clínicas en la actualidad se realiza en las “Fichas Clínicas” tradicionales, las que son manuscritas en papel, por los integrantes del equipo de salud, lo que conlleva a demora, errores de traducción al ser la mayoría de las veces ilegibles. e. Que, en la red de Salud trabajan aproximadamente 3.200 personas, entre las que se incluyen los profesionales, el personal paramédico y el personal administrativo, quienes tienen la responsabilidad de llevar a cabo tanto las labores asistenciales como las docentes y de investigación clínica. f. Que, la importante infraestructura con que cuenta la Red de Salud y su moderno equipamiento de alta tecnología, le han permitido posicionarse como prestadores de servicios médicos de alta complejidad, lo que es claramente valorado por sus beneficiarios legales y sus cargas familiares legalmente reconocidas. g. Que, la Red de Salud dentro de sus objetivos de mantenerse en la vanguardia tecnológica, ha decidido incorporar los más modernos Sistemas de Gestión Hospitalaria que representan el estado del arte y que están basados en potentes plataformas informáticas en las que se incorporan los más altos estándares internacionales. h. Que, aparece como una necesidad migrar de un registro manuscrito a un registro digital, con lo cual será posible tabular información, realizar análisis de los procesos clínicos, definir las mejores prácticas, disponer de trazabilidad de los procesos y evitar errores por mala interpretación de los manuscritos. i. Que, el sistema a adquirir no se encuentra disponible en el Catálogo de Convenio Marco, con las características y especificad y complejidad que se requiere. j. Que, se debe propender al mejor funcionamiento operacional del área de gestión en el Sistema Institucional de Salud. k. Las necesidades del Servicio. l. Las normas y principios que inspiran la Ley de Compras Públicas y su Reglamento.

RESUELVO:

1. APRUÉBANSE, las bases administrativas y Anexos Nº 1, 2, 3, y 4 así como las Bases Técnicas, para llamar a licitación pública la adquisición e implementación del “Sistema de Gestión Hospitalaria para la Dirección de Salud de Carabineros de Chile”, según se detalla: 1.1. BASES ADMINISTRATIVAS. ANTECEDENTES Y CONDICIONES GENERALES. El Administrador del Fondo Para Hospitales de Carabineros de Chile, tiene la facultad de hacer llamados a propuesta pública y/o privada, con la finalidad de adquirir especies o servicios, en la forma establecida en la Ley N° 19.886 y su respectivo reglamento, sobre “Bases sobre contratos administrativos de suministros y prestación de servicios”, para satisfacer necesidades de la red de salud de Carabineros de Chile. 1.2.1. Objetivo.El Fondo Para Hospitales de Carabineros de Chile, en adelante el “FONDO”, ha elaborado las presentes bases, las que contienen todos los requerimientos para materializar la adquisición e implantación del “Sistema de Gestión Hospitalaria para la Dirección de Salud de Carabineros de Chile, el cual se centra fundamentalmente en la adquisición de aplicativos destinados al registro de información clínica (EMR) que para los efectos de esta propuesta, se identifica como Ficha Clínica Electrónica (FCE) y en un ERP que provea el soporte administrativo. Ambos aplicativos deben operar en forma totalmente integrada entre sí mediante una plataforma de integración e integrarse con aplicativos legados comerciales y propietarios, a fin de constituir un sistema completo y armónico. En las Bases Técnicas, se establecen los fines, condiciones y requisitos que deberán ser observados y cumplidos por las personas naturales y/o jurídicas, nacionales o extranjeras que presenten sus ofertas. 1.2.2. De las bases (artículos 19º al 25º del Reglamento de la Ley de Compras). Las presentes bases contienen las disposiciones generales que regirán las relaciones entre el Fondo para Hospitales de Carabineros de Chile, en adelante, “FONDO” y los proveedores de los productos a que se refiere la presente licitación, en adelante, "Oferentes", “Proveedores” o “Proponentes”, durante el proceso y en todas las materias relacionadas con esta licitación. Para que una oferta o postulación se considere válida, ésta deberá cumplir con las disposiciones de las presentes bases administrativas, de las bases técnicas y de los anexos adjuntos. La presentación de una propuesta implica, para la persona natural o jurídica que haga una oferta, la aceptación de las presentes bases, a las cuales se somete desde ya. 1.2.3. Normas generales. Esta licitación y la realización de su objeto, se regirá por los siguientes documentos: a. Las bases administrativas y anexos Nº 1, 2, 3, y 4 así como sus eventuales modificaciones por acto formal, debidamente tramitado. b. Las bases técnicas, así como sus eventuales modificaciones por acto formal debidamente tramitado. c. Las eventuales preguntas, respuestas y las aclaraciones, derivadas del procedimiento estipulado en las bases administrativas. d. La oferta técnica y económica. Todos los documentos antes mencionados formarán un todo integrado y se complementan, recíprocamente, en forma tal que se considera parte del contrato cualquiera obligación que aparezca en uno u otro de los documentos señalados. En caso de contradicción, se interpretarán los puntos oscuros conforme a los principios de estricta sujeción de las bases, libre concurrencia e igualdad de los oferentes”. Se deja constancia que se considerará el principio de preeminencia de las bases, como marco básico. Los precedentes documentos son de carácter público, en atención a la naturaleza de esta licitación. 1.2.4. Cumplimiento de plazos. Los plazos que se establecen en estas bases, para las distintas etapas del proceso de la licitación son fatales; y, de días corridos, salvo que expresamente se diga que son hábiles y el no cumplimiento de los mismos por algún participante implicará su exclusión del proceso a partir de esa fecha, siempre y cuando no exista una causal de ampliación o prorroga, descrita en las presentes bases. 1.2.5. Precio. El o los oferentes indicarán los precios ofertados, según se indica en el Capítulo 8 de las Bases Técnicas, en los puntos 8.5 y 8.6. Los precios de los bienes corporales y servicios ofrecidos por el proponente serán fijos durante el contrato y no estarán sujetos a variaciones por ningún motivo. El presupuesto estimado para este proyecto asciende a la suma total de $ 1.500.000.000.- (mil quinientos millones de pesos) impuestos incluidos. 1.2.6. Modificación de las bases. El FONDO podrá modificar o complementar las bases administrativas, técnicas y respectivos anexos, incluyéndose plazos de la licitación, hasta tres (03) días hábiles antes del plazo establecido para la recepción de las ofertas y formarán parte integrante de las bases originales, desde la fecha de su total tramitación, informando aquello, a través de la plataforma de licitaciones de www.mercadopublico.cl.
En este caso, los proveedores deberán efectuar las modificaciones o complementaciones que sean necesarias en el plazo que resta hasta el cierre de la recepción de la oferta, sin perjuicio que la resolución modificatoria pueda contemplar un nuevo plazo para la presentación de las ofertas. Toda modificación que realice el FONDO será aprobada por acto formal debidamente tramitado otorgándose un plazo prudencial para adecuar sus ofertas y publicado a través del sistema de información a través de resolución fundada emanada del Administrador del Fondo para Hospitales de Carabineros de Chile. * REQUISITOS Y CONDICIONES DE LOS OFERENTES 1.2. REQUISITOS Y CONDICIONES DE LOS OFERENTES. 1.3.7. Requisitos. Los oferentes, al presentar la oferta, deberán acompañar un documento de garantía de seriedad de la oferta, según las condiciones estipuladas en el numeral 1.3.6.a, la que podrá hacerse efectiva en caso de desistimiento de la oferta, por parte del proponente, o cuando se cumpla alguna de las causales indicadas en los puntos 1.3.14.2, 1.3.15, 1.4.1, 1.4.2 y 1.4.8, de estas bases administrativas. Asimismo, el oferente adjudicado deberá acreditar estar inscrito en el Registro Electrónico Oficial de Proveedores del Estado, de la Dirección de Compras y Contratación Pública, al momento de la firma del contrato. 1.3.8. Condiciones. Los participantes deberán ceñirse a las siguientes condiciones generales de licitación: a. Designación de un Ejecutivo Coordinador. Para la coordinación, cumplimiento y soluciones de problemas, derivados de la contratación a que se refiere la presente licitación, el oferente deberá nominar a un coordinador, con poder de resolución suficiente, para que se haga responsable de la licitación, con indicación de teléfono, fax y correo electrónico de contacto directo. b. Fijación del domicilio y competencia de los Tribunales. El proponente que se adjudique la licitación, deberá constituir domicilio en la comuna de Santiago. Y, para todos los efectos legales y judiciales, derivados de la licitación y del contrato, desde ya aceptan, expresamente, la competencia de los Tribunales Ordinarios de Justicia radicados en esta comuna. c. Financiamiento de la preparación de la oferta. Los costos derivados de la formulación de la oferta, en que incurra el proponente, serán de su cargo, no dándose origen a reembolso ni indemnización alguna, en caso de rechazarse o no adjudicarse la oferta. * PROCESO DE LICITACIÓN 1.3. PROCESO DE LICITACIÓN. 1.4.9. Obtención de bases (artículo 28º, del Reglamento de la Ley de Compras).El llamado a licitación será informado a través de la plataforma de licitaciones; www.mercadopúblico.cl y, las bases sólo se obtendrán a través de dicho sitio Web. 1.4.10. Proponentes que pueden participar en esta licitación. Pueden participar en la presente licitación las personas naturales o jurídicas, nacionales o extranjeras que presenten sus ofertas, a través de la plataforma de licitaciones, conforme al artículo 30º y 62º, del Reglamento de la Ley Nº 19.886; con las siguientes excepciones: Los oferentes que tengan conflicto de intereses con el FONDO; o, bien, entendiéndose que existe tal conflicto de intereses en los casos estipulados en los incisos primero y sexto del artículo 4º de la Ley de Compras Públicas. 1.4.11. Recepción de consultas. Todas las preguntas, tanto las de carácter técnico como las de índole administrativa, que los oferentes deseen formular con relación a la materia de esta licitación, deberán ser realizadas a través de la plataforma de licitaciones, en el plazo y de acuerdo a lo especificado en el punto 1.3.16 de las presentes bases.

1.4.12. Entrega de respuestas. Se procederá a analizar y responder las consultas formuladas las que se pondrán a disposición de todos los proveedores interesados en la plataforma de licitaciones, por el ID de la licitación, sin indicar el autor de las consultas, en el plazo y de acuerdo a lo especificado en el punto 1.3.16 de las presentes bases.

1.4.13. Aclaración de las bases (artículo 27º del Reglamento de la Ley de Compras). El FONDO, deberá absolver todas las preguntas que hubieren surgido en la respectiva etapa de consultas, dentro del proceso de licitación. Tales aclaraciones, se informarán a través de la plataforma de licitaciones. Así para el caso que se modifique el contenido de las bases de licitación, se concederá a los proveedores un plazo prudencial previo a la época de cierre de presentación de las ofertas. Acorde a lo anterior, toda respuesta a consultas efectuadas por los proveedores interesados que signifique una modificación a las bases generales y técnicas, así como a sus respectivos anexos, deberá ser aprobada por acto formal, debidamente tramitado, sin perjuicio de su posterior publicación en la plataforma de licitaciones.

1.4.14. Forma de presentación de las propuestas. La propuesta deberá presentarse de la siguiente forma y en el plazo indicado en el punto 1.3.16 de las presentes bases:

a. Documentos: El anexo Nº 1, Declaración jurada de probidad y conflicto de intereses; el anexo N° 2: identificación del Oferente; el anexo Nº 3, Declaración de Conformidad; el anexo Nº 4, Declaración Jurada artículo 8 y 10 de la Ley Nº 20.393. y, copia del documento de garantía, deberán ser ingresados a través de la plataforma de licitaciones, como documentos adjuntos en archivos compatibles (extensiones doc, pdf o txt). En cuanto al documento físico de la garantía de seriedad de la oferta, éste deberá ser entregado, a más tardar, en la fecha de cierre de la presentación de las ofertas, en el Departamento de Contabilidad y Finanzas, de la Dirección de Salud, ubicado en Av. Simón Bolívar Nº 2200, 4º piso, ala Oriente, Edificio Corporativo de la DISALCAR (interior), de la comuna de Ñuñoa, de Lunes a Viernes, en horario de hábil de 8:30 a 13:00 y de 15:00 a 17:30 horas. El documento de garantía debe tener las siguientes condiciones:

1. A favor de: Fondo Para Hospitales de Carabineros de Chile. RUT. 60.514.000-9. 2. Glosa: Para garantizar la seriedad de la oferta en el presente proceso licitatorio. 3. Vigencia: Ciento Ochenta días corridos, a contar del día de apertura de la propuesta. 4. Requisitos: Boleta de garantía bancaria o vale vista bancario, pagadero a la vista; es decir, al momento en que es presentado a cobro y con carácter de irrevocable. 5. Devolución: Una vez firmado el contrato y recepcionada la boleta bancaria de garantía de fiel cumplimiento del contrato mismo. 6. Tomador: El oferente o proponente. 7. Emisor: Banco comercial, con sucursal en la ciudad de Santiago. 8. Monto: Setenta millones de pesos. b. Oferta técnica: deberá ser presentada a través de la plataforma de licitaciones, incluyendo toda aquella información que permita evaluar la propuesta, de acuerdo a lo especificado en las bases administrativas y técnicas, como documento adjunto, en archivo de formato compatible (extensiones doc, xls, pdf, jpg o txt). c. Aquellos antecedentes administrativos, legales o financieros que se encuentren acreditados y disponibles electrónicamente en el Registro Electrónico Oficial de Proveedores del Estado, no será necesario presentarlos.

Oferta económica: el oferente cotizará el producto, de acuerdo al Capítulo 8 de las Bases Técnicas, en los puntos 8.5 y 8.6, que deberá completar y adjuntar en el sitio web www.mercadopúblico.cl.

La oferta deberá presentarse en pesos chilenos, considerando valores netos y con una validez de ciento ochenta días, contados a partir del día de la apertura electrónica de las ofertas, teniendo presente que el presupuesto disponible para este proyecto incluye los impuestos.

El precio del sistema deberá ser fijo, es decir no deberá estar sujeto a ningún tipo de reajuste durante el período del contrato. A excepción de la oferta de Servicio de Operación y Soporte post Garantía del Sistema que debe ser expresada en Unidad de Fomento (UF), de acuerdo con lo establecido en el capítulo 7 de las bases técnicas.

El FONDO podrá solicitar rectificaciones o aclaraciones a las ofertas, conforme lo previene el artículo 40 del Reglamento de la Ley de Compras Públicas. 1.4.15. Custodia de documentos (artículo 36º del Reglamento de la Ley de Compras).Los documentos que sean de carácter mercantil, quedarán bajo la custodia del Departamento de Contabilidad y Finanzas de la DISALCAR, siendo responsable de ello su respectivo Jefe. 1.4.16. Condiciones de la recepción de antecedentes. a. No se recibirá ningún antecedente fuera de lugar, día y hora señalados en la ficha digital de la licitación. b. Se deja claramente establecido que no se aceptarán ofertas, económicas y técnicas, enviadas por otra vía que no sea la electrónica, salvo la excepción contemplada en el numeral 1.3.6 a. precedente. c. Se deja constancia que el FONDO es un usuario más de la plataforma de licitaciones, por lo que no se responsabiliza de los errores u omisiones que se produzcan al ingresar la información al portal y que no le sean imputables. 1.4.17. Apertura y revisión de antecedentes del oferente (artículo 33º del Reglamento de la Ley de Compras).Cerrado el plazo de recepción de ofertas electrónicas y antecedentes, se procederá a la apertura electrónica de ofertas en el portal, al día hábil siguiente del cierre del proceso a través de la plataforma de licitaciones, a las 10.00 horas levantándose el acta de apertura electrónica.

En este acto se revisarán los documentos señalados en el punto 1.3.6., de las presentes bases. Se podrá solicitar a los oferentes salven errores u omisiones formales, siempre y cuando no confieran a esos oferentes situaciones de privilegio respecto de los demás competidores.

Lo anterior en el sentido y alcance que señala el artículo 40 del Reglamento de la Ley de Compras Públicas. 1.4.18. Inadmisibilidad de las ofertas electrónicas. El FONDO declarará inadmisible por resolución fundada, las ofertas que no cumplan con las exigencias previstas en el artículo 4º de la Ley Nº 19.886, y en los siguientes casos: a. Las propuestas entregadas por los proponentes en que se compruebe una presentación incompleta o ambigua de los documentos o antecedentes solicitados en las bases. b. Las propuestas que no vengan acompañadas del documento de garantía de seriedad de la oferta o, si la presentada, es de un banco sin sucursal en Santiago. En el evento de existir errores formales; esto es, en su emisión u otro, el FONDO está facultado para requerir del oferente su cambio o reemplazo, dentro de un plazo máximo de 48 horas, contado desde el momento de la notificación vía correo electrónico. c. Si el oferente no realiza su oferta a través de la plataforma de licitaciones, o no entrega los documentos solicitados que se indican en el numeral 1.3.6, de estas bases, salvo la excepción que dicho numeral contempla.
Los proponentes afectados por el rechazo de sus ofertas no tendrán derecho a solicitar indemnización alguna por este hecho.

1.4.19. Declaración de inadmisibilidad de las propuestas o de licitación. El FONDO podrá declarar inadmisibles las ofertas cuando éstas no cumplieren los requisitos de la licitación establecidos en las bases o, bien, desiertas cuando éstas no resulten convenientes a los intereses institucionales. Lo anterior, de acuerdo a lo establecido en la normativa legal y reglamentaria aplicable, previa resolución fundada dictada al efecto y sin derecho a indemnización de ningún tipo. 1.4.20. Calificación de las ofertas y consultas. 1.4.21.1. Calificación de las ofertas. Las ofertas de los proponentes serán calificadas en una única instancia por el FONDO, quien será responsable de la evaluación, selección y adjudicación de la propuesta. La calificación se efectuará por medio de una Comisión Evaluadora de Propuestas, designada para estos efectos. Los integrantes de dicha Comisión serán nominados por el FONDO.

Será responsabilidad de los proponentes haber entregado toda la información que permita al FONDO efectuar la evaluación de sus ofertas, de acuerdo con lo requerido en listado de detalle en el punto 8.2 de las Bases Técnicas, sin perjuicio de la documentación exigible por la reglamentación propia del Mercado Público. 1.4.21.2. Consultas a los oferentes (artículo 39º del Reglamento de la Ley de Compras). De considerarlo necesario, el FONDO podrá requerir aclaraciones a algún proponente, sobre aspectos de su propuesta que no resulten suficientemente comprensibles. Las explicaciones que el FONDO solicite, no podrán referirse a elementos esenciales o que afecten el tratamiento igualitario de los oferentes o el principio de sujeción a las bases de licitación. Tanto las aclaraciones solicitadas como las respuestas, pasarán a formar parte integrante de los antecedentes del contrato y las bases, en caso de ser adjudicado. 1.4.21. Evaluación de las ofertas. Las propuestas serán evaluadas por una “Comisión Evaluadora” que se designará al efecto, conforme a los criterios de evaluación y adjudicación especificados en las bases técnicas y su respectivo Capítulo 8. También tendrá consideración lo estipulado en los incisos primero y sexto del artículo 4º de la Ley de Compras Públicas. El Comité de Evaluación estará compuesto de la siguiente forma:

COMISIÓN EVALUADORA | CALIDAD DE FUNCIONARIO PÚBLICO | Asesor Jurídico | SI | Coordinador Médico | SI | Experto en Procesos | | Ingeniero OTI(*) | SI | Experto en Gestión del Cambio | | Ingeniero Industrial o Financiero | SI | Enfermera Universitaria | SI | Usuario Líder ERP | SI | Usuario Líder FCE | SI | (*)OTI: Oficina de Tecnologías de Información del HOSCAR 1.4.22. Adjudicación de la licitación y notificación a los proponentes (artículo 41º del Reglamento de la Ley de Compras).La propuesta de adjudicación de la oferta, que presente la Comisión Evaluadora, será analizada y aprobada o rechazada por el Administrador del FONDO. La notificación al o los proveedores adjudicados, y a los no adjudicados, se efectuará de la forma que se expresa en el numeral siguiente. 1.4.23.3. Publicación del proponente adjudicado. El FONDO, a través de la plataforma de licitaciones, publicará e informará los antecedentes relativos a la adjudicación, una vez que se haya completado el proceso respectivo, generándose la orden de compra en pesos ($), previa suscripción del contrato y tramitación del acto administrativo que lo apruebe, cuando ello sea procedente. 1.4.23.4. Aceptación de la adjudicación. Si el oferente adjudicado no aceptan la adjudicación, deberán manifestarlo expresamente en el plazo señalado en normativa vigente de la plataforma de licitaciones, mediante carta dirigida al Jefe del Departamento de Abastecimiento de la DISALCAR. En este caso, se dejará sin efecto la adjudicación mediante resolución fundada y hará efectivo el documento de garantía de seriedad de la oferta. Lo anterior, también ocurrirá en el caso de no suscribirse el contrato en el plazo previsto en el numeral 1.4.2. siguiente y el Servicio opte por dejar sin efecto la adjudicación mediante resolución fundada al efecto. Ante el rechazo del proveedor adjudicado, el FONDO podrá dictar una nueva Resolución de adjudicación del oferente siguiente mejor evaluado, y así sucesivamente, o bien, declarar desierta la licitación, si las restantes ofertas no resultan convenientes al interés institucional. 1.4.23.5. Devolución del documento de garantía de seriedad de la Oferta. Las cauciones de seriedad de la oferta se devolverán una vez suscrito el contrato respectivo, dado que existe la posibilidad de re adjudicar al siguiente mejor evaluado, en caso de rechazo de la adjudicación o no suscripción del contrato dentro del plazo de 10 días contados desde la notificación que de cuenta de la inadmisibilidad, de la preselección o adjudicación. Así, los proponentes no adjudicados, a su sola solicitud y después de este acto podrán retirar previa coordinación telefónica (9278087), con el Contador Jefe del Departamento de Contabilidad y Finanzas de la DISALCAR, ubicado en el 4º piso del Edificio Corporativo de la DISALCAR, Av. Simón Bolívar Nº 2200 (interior), de la comuna de Ñuñoa. La garantía será devuelta sin reajustes ni intereses, ni costo alguno para el FONDO. 1.4.23. Revocación de la adjudicación. La adjudicación podrá ser revocada previa resolución fundada dictada al efecto: a. Si dentro del plazo establecido el oferente adjudicado no acompaña el documento de garantía de fiel y oportuno cumplimiento del contrato, se dejará sin efecto la adjudicación. b. Si el oferente adjudicado adquiere un conflicto de intereses, con posterioridad a la oferta, ello en concordancia con el artículo 4º de la ley de Compras Nº 19.886. c. Si el oferente adjudicado no acredita encontrarse inscrito en el Registro Electrónico Oficial de Proveedores del Estado, de la Dirección de Compras y Contratación Pública, previo a la suscripción del contrato. d. Si el oferente no adjunta la totalidad de la documentación exigida en los puntos 1.4.4; 1.4.5; 1.4.6; 1.4.7; y, 1.4.8, según corresponda. En todos estos casos, el FONDO hará efectivo el documento de garantía de seriedad de la oferta sin más trámite.

1.4.24. Matriz de cumplimientos de plazos. El proceso se sujetará a los siguientes plazos; Descripción de las Etapas | Descripción de número de días hábiles | Observaciones | Publicación | 0 | | Visita a terreno | 15 | | Consultas | 17 al 19 | | Respuestas y/o aclaraciones | 24 al 28 | | Cierre recepción ofertas | 50 | | Apertura de ofertas electrónicas | 51 | | Plazo para evaluar | 51-80 | | | | | Plazo para adjudicar | 81-90 | | Plazo celebración contrato | 91-120 | | Número total de días hábiles del Proceso | 120 | |

* DISPOSICIONES CONTRACTUALES 1.4. DISPOSICIONES CONTRACTUALES. 1.5.25. Documentación integrante del contrato (artículo 63º y ss. del Reglamento de la Ley de Compras).La Asesoría Jurídica de la Dirección de Salud redactará el correspondiente contrato, con el oferente adjudicado que cumpla con la entrega de lo establecido en los puntos 1.4.4; 1.4.5; 1.4.6; 1.4.7; y, 1.4.8, de estas bases. El contrato considerará, como partes integrantes del mismo, los documentos establecidos en el numeral 1.1.3, de estas bases. El oferente que no concurra a la firma del contrato pertinente será motivo suficiente, como se señaló en cláusulas precedentes, para hacer efectivo el documento de seriedad de la oferta sin más trámite; y, dejar sin efecto, por ende, la adjudicación, pudiendo el Servicio adjudicar al siguiente oferente mejor evaluado o declarar desierto el proceso por resolución fundada si ninguna de las ofertas fueren conveniente a sus intereses. Una vez firmado el contrato y si ello fuere procedente, se devolverán las cauciones de garantía de seriedad de la oferta a los proponentes que resulten no favorecidos de conformidad a lo señalado en el numeral 1.3.14.3, de las presentes Bases Administrativas. 1.5.26. Plazo de celebración del contrato. El contrato se celebrará con el oferente que resulte adjudicado, en un plazo no superior a treinta (30) días hábiles, contados a partir de la publicación de la resolución de adjudicación en el sistema de información. Si no se suscribieran dentro de este término, el FONDO entenderá que no se ha formado el consentimiento y, en consecuencia, el acto administrativo en virtud del cual se aceptó la propuesta formulada por el oferente que resultó adjudicado, quedará sin efecto mediante resolución fundada. En tal caso, se hará efectivo el documento de garantía de seriedad de la oferta, a favor del FONDO. Este plazo de formalización del contrato podrá ser ampliado unilateralmente por el FONDO, de acuerdo a sus necesidades, previa resolución fundada debidamente tramitada. 1.5.27. Plazo de duración del contrato. El plazo de duración del contrato será de 24 meses, a contar de la tramitación de la resolución que lo apruebe, y una vez emitida la correspondiente orden de compra, sin perjuicio de las causales de terminación anticipada, que se estipulen en el referido contrato. Los derechos y obligaciones nacidos del contrato respectivo, sólo serán exigibles a partir de la total tramitación del acto administrativo que lo aprueba. 1.5.28. Nacionalidad de los participantes. Podrán participar en esta licitación, personas naturales o jurídicas, empresas nacionales y/o extranjeras. Las empresas extranjeras que participen, deberán hacerlo a través de un representante oficial con domicilio en Chile y acompañar un documento certificado debidamente visado por el Cónsul de Chile, traducido y legalizado en el Ministerio de Relaciones Exteriores, que indique lo siguiente: a. Individualización de la empresa que tiene su representación oficial en Chile, antigüedad y vigencia de la misma. Además, indicará el nombre de la Empresa que representa, dirección de la Casa Matriz y su representante legal. b. Las empresas participantes deberán tener presente que, en el evento de ser adjudicadas, tendrán la obligación de entregar, antes de la firma del contrato, un mandato amplio otorgado por la empresa extranjera a favor de la empresa chilena que la represente, la que, a través de sus mandatarios, actuará con las más amplias facultades, incluidas las judiciales, contenidas en ambos incisos del artículo 7° del Código de Procedimiento Civil, incluyendo además, en forma expresa, la de ser emplazada en juicio y, la de contestar demandas. c. Las empresas extranjeras y sus representantes oficiales en Chile deberán asumir una responsabilidad solidaria por todas y cada una de las obligaciones que contraigan con motivo del contrato que se suscriba.

1.5.29. Antecedentes legales de las empresas nacionales al momento de contratar. El oferente, persona jurídica, deberá proporcionar copia legalizada u original de: a. RUT. b. Declaración jurada notarial, respecto a conflicto de intereses, según el texto del anexo N° 1 de estas bases. c. Escritura de constitución legal. d. Extracto de escritura de constitución, publicado en el Diario Oficial. e. Extracto de escritura de constitución, inscrito en el Registro de Comercio respectivo. f. Escritura de la última modificación de la Sociedad, si la hubiere, con su respectivo extracto publicado e inscrito. g. Certificado de vigencia de la Sociedad, extendido con no más de treinta (30) días de anticipación, a la fecha de la firma del contrato. h. Escritura en que conste la personería del representante legal del oferente, la cual debe contener los requisitos establecidos en el artículo 7, del Código de Procedimiento Civil. Se debe acreditar la vigencia de la personería del representante legal. i. Certificado oficial de antecedentes comerciales de la Cámara de Comercio (No Dicom). j. Documento de garantía de fiel cumplimiento del contrato. k. Certificados de alianzas estratégicas firmados con empresas nacionales o internacionales, donde se indique el plazo de las referidas alianzas. l. Certificado emitido por la Dirección del Trabajo, que acredite los antecedentes laborales del proveedor, con no más de sesenta (60) días anticipación a la firma del contrato.
Aquellos antecedentes legales que se encuentren acreditados y disponibles electrónicamente en el Registro Electrónico Oficial de Proveedores del Estado, no será necesario presentarlos.

1.5.30. Antecedentes legales del representante oficial de la empresa extranjera en Chile al momento de contratar. Las personas jurídicas, deberán acompañar la siguiente documentación: a. Escritura de constitución de la Sociedad y modificaciones, si las hubiere. b. Publicación del extracto social. c. Inscripción de la sociedad en el Registro de Comercio del Conservador de Bienes Raíces. d. Certificado de vigencia de la sociedad, extendido por el Registro de Comercio del Conservador de Bienes Raíces, con una antigüedad no superior a treinta (30) días. e. Certificado de vigencia del poder del representante legal de la empresa, inscrito en el Registro de Comercio del Conservador de Bienes Raíces. f. Declaración Jurada de conformidad con los incisos primero y sexto, del artículo 4º de la Ley de Compras Públicas. g. Certificado ante Notario que acredite nombre y firma del representante legal de la Empresa que suscribe la propuesta. h. Escritura en que conste la personería del representante legal del oferente, la cual debe contener los requisitos establecidos en el artículo 7, del Código de Procedimiento Civil. i. Certificado emitido por la Dirección del Trabajo, que acredite los antecedentes laborales de la Empresa, a nivel nacional. j. Si la empresa es representante oficial de una marca, es necesario que adjunte la documentación que acredite dicha representación y su vigencia. Aquellos antecedentes legales que se encuentren acreditados y disponibles electrónicamente en el Registro Electrónico Oficial de Proveedores del Estado, no será necesario presentarlos. 1.5.31. Antecedentes financieros de las empresas nacionales o del representante oficial de la empresa extranjera en Chile. La empresa adjudicada, antes de firmar el contrato, deberá cumplir con los requisitos que lo habiliten para contratar con la Administración del Estado, de conformidad al artículo 4º de la ley Nº 19.886.-

1.5.32. Documento de garantía de fiel y oportuno cumplimiento del contrato (artículo 68º y ss. del Reglamento de la Ley de Compras). El adjudicatario deberá entregar el documento de garantía de fiel y oportuno cumplimiento del contrato, al momento de su suscripción. Si la garantía de cumplimiento no fuere entregada dentro del plazo indicado, el FONDO hará efectiva la garantía de seriedad de la oferta y podrá adjudicar el contrato definitivo al oferente siguiente mejor evaluado. Una vez recibido el documento de garantía de cumplimiento de contrato, se devolverá la garantía de seriedad de oferta, sin más trámite. La referida Boleta de Garantía además de dar cumplimiento en forma oportuna al contrato servirá como medio de caución de las obligaciones laborales y sociales del adjudicatario. El documento de garantía, se sujetará a las siguientes condiciones: a. A favor de: Fondo para Hospitales de Carabineros de Chile b. Glosa: Para garantizar el fiel cumplimiento del contrato, firmado con el Fondo para Hospitales de Carabineros de Chile. c. Vigencia: Plazo del contrato más ciento veinte (120) días corridos. d. Requisitos: Boleta de garantía bancaria, pagadero a la vista; es decir, al momento en que es presentado a cobro y con carácter de irrevocable. e. Devolución: Sesenta (60) días corridos, después de la fecha definitiva del contrato. f. Tomador: El oferente o proponente. g. Emisor: Banco comercial, con sucursal en la ciudad de Santiago. h. Monto: Diez por ciento (10%) del valor total del contrato, IVA incluido. La garantía de fiel cumplimiento del contrato, tiene por objeto garantizar el cumplimiento del mismo en forma oportuna y eficaz, por tanto, se hará efectiva tal boleta sin necesidad de requerimiento judicial en el evento del no pago de multas impuestas al proveedor; incumplimiento imputable al proveedor, incumplimiento de obligaciones sociales y previsionales. Se entenderá por incumplimiento grave: El hecho cierto de actuar el proveedor en la prestación de los servicios con falta, imprudencia, inobservancia de las reglas de la licitación o infracción de las mismas, las que pasan a especificarse: i)Por la no solución del adjudicatario, dentro de los plazos convenidos, de los reparos que sean formulados por escrito por el FONDO. ii)Si se ha rechazado definitivamente alguno de los bienes o servicios por no cumplir con los requerimientos establecidos y el proveedor no los suministra o no está en condiciones de suministrarlo en el plazo u oportunidad previstos. iii)Si el proveedor por sí o a través de alguno de sus dependientes incurriere en violación al deber de reserva, confidencialidad o secreto convenido o dispuesto por ley. En el evento de que la garantía de haga efectiva durante la vigencia del contrato definitivo o bien se prorrogue su vigor, deberá ser renovada en los mismos términos acordados en las presentes bases de licitación.

Si eventualmente se produce un acuerdo entre las partes que extienda el plazo del contrato, el proveedor deberá reemplazar la boleta de garantía al segundo día hábil de producido el acuerdo, con una vigencia de 120 días adicionales al nuevo plazo pactado. Se hace presente que el cobro de la Boleta Bancaria de Garantía de Fiel y Oportuno Cumplimiento de Contrato, será sólo en el evento de incumplimiento grave, esto es, las causales señaladas en las letras b), e), g) i), k), del numeral 1.4.16 de las Bases Administrativas. 1.5.33. Orden de compra. Posterior a la suscripción del contrato y a la total tramitación del acto administrativo que lo apruebe, se emitirá la orden de compra respecto de la cual el adjudicado tendrá un plazo de tres días hábiles para aceptarla en forma electrónica, a través del Sistema de Información (www.mercadopublico.cl), sin perjuicio de lo establecido en el artículo 62 del reglamento de la Ley de Compras. 1.5.34. Forma de pago. El precio será pagado por estados de avances y contra entrega de factura, requisitos que se acordarán en el contrato a suscribir, y de acuerdo a las especificaciones del Capítulo 10 de las Bases Técnicas. Las facturas deberán extenderse a nombre de: FONDO PARA HOSPITALES DE CARABINEROS DE CHILE, R.U.T. 60.514.000-9, Calle Antonio Varas Nº 2470, comuna de Ñuñoa, Región Metropolitana, Santiago.
El FONDO contará con un plazo de hasta diez (10) días hábiles, contados desde la recepción del documento de cobro, para efectuar observaciones que correspondieren, lo que se estipulará en el contrato que se suscriba con el adjudicatario. Los documentos de cobro serán pagados dentro del plazo de treinta (30) días, a contar de la fecha de entrega y recepción conforme. 1.5.35. Certificación de Cotización de Pagos Cotizaciones Previsionales. Asimismo, la empresa adjudicada deberá certificar el pago de las cotizaciones previsionales al día de la totalidad de sus trabajadores dependientes, de acuerdo a lo establecido en el artículo cuarto de la ley de compras. 1.5.36. Multas. Si el proveedor incurriere en retardo, y por tanto, no entregare el producto en todo o en parte dentro de los plazos estipulados en el contrato, el FONDO, deberá aplicar una multa equivalente al 0.15% del valor total del contrato, por cada día corrido de retardo, hasta que la entrega tenga lugar, y se complete el máximo del 15% del precio del contrato.

Alcanzado ese máximo, podrá ponerse término o resolverse el contrato o bien exigir su cumplimiento forzado, en ambos casos con indemnización de perjuicios.

Los pagos de multa deberán efectuarse dentro de los diez (10) días siguientes de requerido su cobro por el FONDO; en caso de no efectuarse el pago, se faculta, de manera irrevocable al FONDO, para proceder a hacer efectiva la multa descontando su monto del estado de pago más próximo, lo que se comunicará por carta certificada dirigida a su domicilio, ello mediante resolución fundada y debidamente tramitada por el FONDO.

Sin perjuicio de lo señalado precedentemente, el FONDO podrá ejercer las acciones legales que correspondan para el debido resguardo de sus intereses y hacer efectivas las garantías para asegurar el pago de las multas por los conceptos indicados en este punto. En el evento de presentarse una multa, ésta deberá ser notificada al proveedor infractor mediante acto administrativo fundado y debidamente tramitado. Una vez ocurrido tal acto el infractor tendrá derecho a presentar reconsideración dentro del plazo de 5 días hábiles de notificado, la que será resuelta en única instancia por el Administrador del Fondo para Hospitales de Carabineros de Chile. Si la multa excede el 15% se procederá al cobro de la Boleta Bancaria de Fiel y Oportuno Cumplimiento de Contrato de conformidad a lo estipulado en las presentes bases. 1.5.37. Confidencialidad. Se establece que el oferente que adjudique la presente licitación se obligará a mantener en RESERVA los datos que dicen relación con EL FONDO, antes, durante y luego de su ejecución. Respecto de la información técnica involucrada en las operaciones que darán origen al Contrato u otra información clasificada, las partes deberán acordar en todo momento tratar como confidencial toda información concerniente a las operaciones, planes, conocimientos, secretos comerciales, transacciones de negocios y material clasificado. Dicha información deberá ser protegida de acuerdo a las disposiciones legales y reglamentarias pertinentes.

Atendido lo anterior, el proveedor se comprometerá a guardar la más absoluta y estricta reserva y confidencialidad respecto del conocimiento y manejo de toda la información que con ocasión del Contrato definitivo tomare conocimiento.

Lo anterior implica que tanto, durante la vigencia del Contrato, cuanto después de ésta, el proveedor y la entidad se obligan a no revelar, en cualquier forma, a ninguna persona natural o jurídica que no sea su personal directamente involucrado en la prestación de los servicios que en este acto se contratan por EL FONDO, ninguna información relacionada con las Partes o el FONDO sea que se refiera a instalaciones, operaciones, métodos, datos, bases de datos, datos personales relacionados con los beneficiarios, información clínica del cualquier tipo correspondiente a pacientes, información legal, financiera, contractual y contable y cualquier otra información de naturaleza confidencial relacionada con el Proyecto, que haya sido o que vaya a ser revelada durante la vigencia del Contrato, directamente por cualquiera de las partes y/o sus personas relacionadas.

Por ende, queda estrictamente prohibido transmitir, difundir o reproducir cualquier información a la cual hayan accedido por medio del Contrato, a toda persona natural o jurídica que no sea su personal.

El no cumplimiento dará derecho para poner inmediato término al Contrato y, en el caso del EL FONDO, hacer efectiva la garantía de fiel cumplimiento de contrato, sin perjuicio de ejercer las acciones legales pertinentes. 1.5.38. Coordinación. El proveedor adjudicado designará un Ejecutivo, que actuará como representante ante el FONDO, para los efectos de la administración del contrato respectivo y su designación deberá contar con la aprobación del FONDO, reservándose el derecho de solicitar su cambio en el caso de que éste, a su juicio, no sea competente. Cualquier cambio de la persona asignada a esta función deberá ser aceptada, expresamente, por el FONDO, mediante acto formal. Lo anterior, sin perjuicio de la participación de los representantes legales, cuando ello se requiera. 1.5.39. Vínculos de dependencia. Se deja constancia que el contrato que se suscribirá será de adquisición e implementación del Sistema de Gestión Hospitalaria para la Dirección de Salud de Carabineros de Chile y no un contrato de trabajo, sin que existan vínculos de subordinación o dependencia alguna entre el FONDO y el adjudicado. Por lo tanto, para todos los efectos legales, la empresa tendrá la responsabilidad total y exclusiva de su condición de empleador para con sus trabajadores. No obstante ello, la obligación del oferente del pago de las obligaciones laborales y previsionales de sus trabajadores, es sin perjuicio de la responsabilidad solidaria del FONDO. 1.5.40. Término anticipado del contrato (artículo 77º del Reglamento de la Ley de Compras). El FONDO, por resolución fundada, podrá poner término anticipado al contrato por alguna de las siguientes causales: a. Resciliación o mutuo acuerdo entre los contratantes. b. Incumplimiento grave de las obligaciones contraídas por el contratante. Se entenderá por incumplimiento grave : i. La no solución por el adjudicatario, dentro de los plazos convenidos, de los reparos que les sean formulados por escrito, por parte del FONDO. ii. Si se ha rechazado definitivamente alguno de los bienes o servicios, por no cumplir con los requerimientos establecidos y el proveedor no los suministra o no está en condiciones de suministrarlo en el plazo u oportunidad previstos para estos efectos. iii. Si el proveedor por sí o a través de alguno de sus dependientes incurre en violación al deber de reserva, confidencialidad o secreto convenido o dispuesto por la ley. c. Estado de notoria insolvencia del contratante, a menos que se mejoren las cauciones entregadas o las existentes sean suficientes para garantizar el cumplimiento del contrato. d. Por exigirlo el interés público o la seguridad nacional. e. Registrar saldos insolutos de remuneraciones o cotizaciones de seguridad social con sus actuales trabajadores o con trabajadores contratados los dos últimos años, a la mitad del período de ejecución del contrato, con un máximo de seis meses. f. Si la empresa se encontrare en cesación de pagos o en una situación patrimonial que por razones fundadas permita presumir que impedirá el cabal y oportuno cumplimiento de sus obligaciones contractuales. g. Si por motivo sobreviniente, el proveedor incurriere en una causal legal que lo inhabilite para contratar con el Estado. h. Por infracción a lo estipulado en el artículo 4º de la Ley Nº 19.886. El aviso de término anticipado se hará por carta certificada, despachada al domicilio registrado por éste, con diez (10) días de antelación a la fecha en que se desea terminar el contrato.
El término anticipado del contrato, no obsta a que el FONDO se reserva el derecho de iniciar las acciones legales correspondientes y a cobrar el documento de garantía de fiel cumplimiento del contrato, cuando la causal de término anticipado sea imputable al adjudicado.

1.5.41. Prórroga del contrato: El contrato podrá prorrogarse previo acuerdo entre las partes, mediante acto administrativo fundado. En este mismo sentido podrá aumentarse o disminuirse de acuerdo a las necesidades del servicio siempre que no supere el señalado 20% del monto total del contrato. 1.5.42. Fuerza mayor o caso fortuito (Artículo 45 del Código Civil). Ante la ocurrencia de casos de fuerza mayor o caso fortuito, debidamente acreditados y formulados por el proveedor adjudicado, “EL FONDO”, podrá, de común acuerdo y a partir de la notificación respectiva, acordar una prórroga en el plazo de entrega, cuando ello procediere. Se considerara que un hecho constituye fuerza mayor o caso fortuito, si éste reúne en forma copulativa los siguientes requisitos:
- Que se produzca independientemente de la voluntad del proveedor.
- Que sea imprevisto.
- Que sea insuperable.
- Que genere la imposibilidad de cumplir con la obligación contraída. 1.5.43. Indemnización pactada (artículo 78º del Reglamento de la Ley de Compras). En los casos en que el FONDO ponga término anticipado POR LAS CAUSALES QUE SEAN IMPUTABLES AL ADJUDICATARIO QUE SE ENCUENTRAN INDICADAS EN EL NUMERAL 1.4.16 precedente, el adjudicatario desahuciado pagará al FONDO, a título de indemnización, (que procederá cuando el término anticipado se deba a un hecho imputable al oferente, debidamente calificada por el Servicio, excluyendo las situaciones de resciliación, termino anticipado por interés público o por la concurrencia de fuerza mayor) en una suma ascendente al veinte por ciento (20%) del valor total del contrato, reconociendo desde ya su responsabilidad en el referido término anticipado. La indemnización que se pacta deberá pagarse dentro de los treinta (30) días siguientes a la data en que se notifique tal término, mediante vale vista extendido a nombre del FONDO. Sin perjuicio de ello, la suma indemnizatoria podrá, además, ser descontada por el FONDO, de cualquier pago que deba realizarse al adjudicatario desahuciado, o bien, se perseguirá su cobro a través del ejercicio de las acciones judiciales que correspondan. Todo evento deberá ser calificado previamente por el Servicio mediante acto fundado dictado al respecto. 1.5.44. Derechos e impuestos. Todos los gastos de certificaciones, copias autorizadas u otros similares, como también los impuestos que se generen o produzcan por causa o con ocasión del contrato, tales como los gastos notariales de celebración de contrato, y/o cualesquiera otros que se originen en el cumplimiento de obligaciones que, según el contrato o las bases, ha contraído el oferente adjudicado, serán de cargo exclusivo de éste. 1.5.45. Cesibilidad del contrato (artículo 74º del Reglamento de la Ley de Compras).El adjudicado no podrá ceder ni transferir en forma alguna, total ni parcialmente, los derechos y obligaciones que nacen del desarrollo de una licitación, y en especial los establecidos en el contrato definitivo, salvo que una norma legal especial permita expresamente la cesión de derechos y obligaciones. Lo anterior, es sin perjuicio que los documentos justificativos de los créditos que emanan de los contratos puedan transferirse de acuerdo a las normas de derecho común. El proveedor adjudicado no podrá subcontratar, salvo autorización expresa que conste por escrito del FONDO, la que será de carácter parcial. 1.5.46. Encargado del procedimiento de compra y medio de contacto. Será encargado del procedimiento de compra, el Jefe de la Oficina de Adquisiciones del Departamento de Abastecimiento DISALCAR, o quien lo subrogue o reemplace en el cargo. Teléfono de contacto: (56-2) 9278235. 1. APRUÉBASE, las bases técnicas para para materializar la adquisición e implementación del Sistema de Gestión Hospitalaria para la Dirección de Salud de Carabineros de Chile, según se detalla:

BASES TÉCNICAS.
INTRODUCCIÓN. El FONDO ha elaborado las presentes bases técnicas, las que contienen todos los requerimientos para llamar a licitación pública la adquisición e implementación de un SISTEMA DE GESTIÓN HOSPITALARIA PARA LA DIRECCIÓN DE SALUD DE CARABINEROS DE CHILE, según se detalla: * SECCIÓN BASES TÉCNICAS

BASES técnicas

sistema DE GESTIÓN HOSPITALARIA

1 INFORMACIÓN GENERAL 2.1 INTRODUCCIÓN Dentro de los elementos a implementar para lograr el objetivo de contar con un Sistema de Gestión Hospitalario Integrado e Integral, se incluye un aplicativo destinado al Registro Clínico Electrónico (más conocido entre los usuarios clínicos como FCE = Ficha Clínica Electrónica), y un aplicativo Administrativo – Financiero conocido como ERP (Enterprise Resources Planning).

El sistema configurado con las herramientas informáticas ya mencionadas, debe permitir la gestión de la Red de Salud del FONDO, incluyendo tanto al Hospital de Carabineros (HOSCAR) como a los Centros Médico Dentales, Consultorios, Policlínicos, Centro de Salud Familiar (CESFAM) y otras entidades vinculadas con la salud con que cuenta la Institución.

2.2 ANTECEDENTES. El Fondo Para Hospitales cuenta con una Red prestadora de servicios de Salud, constituida por el Hospital de Carabineros (HOSCAR), Centros Médico Dentales, Consultorios y Policlínicos de diversa envergadura distribuidos a lo largo del país. En la red de Salud prestan servicios aproximadamente 3.200 personas, entre las que se incluyen los profesionales, el personal paramédico y el personal administrativo, quienes tienen la responsabilidad de llevar a cabo las labores asistenciales, administrativas, docentes y de investigación clínica. La importante infraestructura con que cuenta el FONDO a través del HOSCAR y su moderno equipamiento de alta tecnología, le han permitido posicionarse como prestadores de servicios médicos de alta complejidad, lo que es claramente valorado por sus beneficiarios y sus cargas familiares legalmente reconocidas. Esta preferencia se ve reflejada en los aproximadamente 10.000 egresos hospitalarios ocurridos en el HOSCAR en el año 2010, y en las aproximadamente 330.000 atenciones ambulatorias, de las cuales 158.110 corresponden a atenciones de urgencia. Adicionalmente se realizaron 310.000 acciones vinculadas con prestaciones odontológicas.

El Fondo para Hospitales de Carabineros y el HOSCAR, dentro de sus objetivos de mantenerse en la vanguardia tecnológica, han decidido adquirir un moderno Sistemas de Gestión Hospitalaria que represente el estado del arte y que estén basados en potentes plataformas informáticas en las que se incorporan los más altos estándares internacionales. Esta decisión es de gran relevancia, por cuanto, dado su triple calidad asistencial, docente y de investigación, la modernización que se plantea tendrá fuerte impacto tanto en la calidad asistencial como en la estructura de costos operacionales y de administración.

2.3 el adquirente del sistema de gestión hospitalaria El adquirente del Sistema de Gestión Hospitalario es el FONDO PARA HOSPITALES DE CARABINEROS DE CHILE, en adelante “EL FONDO”. EL FONDO designará un COMITÉ DE DIRECCIÓN ESTRATÉGICO del proyecto que tendrá por misión: * Validación del Cumplimiento de HITOS ESTRATÉGICOS * Validación de Cumplimiento de HITOS DE PAGO * Aprobación de Cambios al Alcance y Cronograma del Proyecto * Coordinación y Solución de Conflictos Este comité estará conformado por: * FONDO: * General DISALCAR * Director HOSCAR * Director/Coordinador del Proyecto * Asesoría Jurídica * Proveedor: * Alto Ejecutivo firmante del Contrato * Gerente del Proyecto del Proveedor

2.4 DESCRIPCIÓN DE LA SITUACIÓN ACTUAL. Para la administración de la DISALCAR y su Red de Salud, los ejecutivos cuentan en la actualidad con diversos sistemas informáticos de desarrollo propietario realizados en diversos lenguajes de programación, que están orientados principalmente a la gestión administrativa, y que no se encuentran integrados entre sí ni cuentan con estándares HL7. También disponen de algunos aplicativos comerciales modernos orientados a apoyar temas clínicos específicos, los que están dotados de conectividad HL7, y que se encuentran parcialmente integrados a los sistemas propietarios. El registro de las actividades y acciones clínicas se efectúa en Fichas Clínicas tradicionales, las que son manuscritas en papel por los diversos integrantes del equipo de salud.

El FONDO y cada uno de los Establecimientos y que conforman la Red de Salud, utilizan sus propias fichas clínicas y tiene sus propios archivos, de modo que si un paciente cambia de establecimiento dentro de la misma red, tendrá una segunda ficha clínica completamente independiente de la primera, no existiendo intercambio de información entre ambas. El Data Center de la DISALCAR cuenta con servidores antiguos en los que corren los aplicativos propietarios y servidores modernos, virtualizados algunos, en los que corren los aplicativos comerciales adquiridos, los que no operan en condiciones de redundancia, por lo que se encuentran en una situación de vulnerabilidad ante eventuales fallas o desperfectos, con los consiguientes riesgos de interrupción transitoria de los servicios. En el área clínica en general no cuenta con aplicativos informáticos. Hace excepción a lo anterior el Servicio de Imagenología, el que cuenta con un moderno sistema de radiología digital (RIS y PACS) de marca FUJI, que les permite alcanzar elevados estándares de gestión y almacenar la totalidad de las imágenes que corresponde a los exámenes de diagnóstico que efectúa, las que pueden ser consultadas en línea por los médicos cada vez que la atención de sus pacientes lo requiere. Actualmente estos archivos son compartidos en línea con el hospital DIPRECA, y con algunos establecimientos de la Red de Salud como Viña del Mar y Punta Arenas. Los equipos computacionales que utiliza son de una muy elevada potencia y representan el estado del arte. Su actual capacidad de archivo es del orden de los 10 Tera Bytes.

El Servicio de Sanidad Dental, cuenta también con un sistema de Radiología Digital, que genera imágenes en formato JPEG, las que son distribuidas a las clínicas dentales locales a través de la red existente.

El Laboratorio Clínico y el Banco de Sangre operan con aplicativos comerciales en la modalidad contractual de “Compra de Servicios”.

También se cuenta con algunos dispositivos automáticos de dispensación de fármacos e insumos clínicos, que están integrados con el sistema propietario de bodega. El área administrativa, utiliza varios sistemas que no están integrados entre sí. La mayoría son de desarrollo propietario y utilizan diversos lenguajes de programación, cada uno con su base de datos independiente. El sistema contable y presupuestario en uso es el SIGFE (Sistema de Información de Gestión Financiera del Estado). Existe un aplicativo comercial nuevo para Activo Fijo, que aún no está en explotación. El detalle de estos aplicativos aparece en el capítulo 11 de las presentes Bases Técnicas.

2.5 EL PROYECTO DE Sistema de GESTIÓN Hospitalaria:

Existe conciencia que los cambios requeridos para lograr los propósitos implican profundos cambios culturales que afectan transversalmente a toda la organización, y muy especialmente al área clínica, la que deberá asumir un rol relevante en la gestión, por cuanto la razón de ser de un establecimiento de salud es precisamente la generación de prestaciones de Salud. La eficiencia en los procesos productivos, el logro de adecuadas relaciones calidad – costos, la productividad de los diversos factores que forman parte de estos procesos son objetivos alcanzables mediante procedimientos analíticos avanzados basados en información oportuna y confiable, destinados a detectar las mejores prácticas. Las acciones de salud, que constituyen los servicios médicos que recibe el paciente, son el fruto de procesos complejos que tradicionalmente se han registrado en forma manuscrita en la denominada Ficha Clínica. Estas fichas se conservan en voluminosos archivos y deben ser ubicadas y movilizadas cada vez que el paciente requiere una atención de salud. Dado su condición de documento manuscrito, la legibilidad de su contenido resulta laboriosa y en muchos casos imposible, con lo que difícilmente es posible utilizar esta información para uso analítico, investigación o docencia.

En virtud de lo expuesto, aparece como una necesidad migrar de un registro manuscrito a un registro digital, con lo cual será posible tabular información, realizar análisis de los procesos clínicos, definir las mejores prácticas, disponer de trazabilidad de los procesos y evitar errores por mala interpretación de los manuscritos. Este registro digital es la Ficha Clínica Electrónica (FCE). El proyecto actual, se centra fundamentalmente en la adquisición de aplicativos destinados al registro de información clínica (EMR= Electronic Medical Record) que para los efectos de esta propuesta, se identifica como Ficha Clínica Electrónica (FCE) y en un ERP (Enterprise Resource Planning) que provea el soporte administrativo. Ambos aplicativos deben operar en forma totalmente integrada entre sí mediante una plataforma de integración e integrarse con aplicativos legados comerciales y propietarios, a fin de constituir un sistema completo y armónico.

Adicionalmente se adquiere algunas herramientas de apoyo a la gestión, entre las cuales destacamos un Datawarehouse, una herramienta de Inteligencia de Negocio y una herramienta de IR-GRD. (Grupos Relacionados de Diagnósticos). El objetivo especifico del Proyecto “Sistema de Gestión Hospitalaria” es potenciar el registro y gestión de los procesos clínicos y administrativos, dotándolos con herramientas informáticas que permitan detectar e incorporar las mejores prácticas, agilizar los procesos de atención, evitar errores clínicos, incorporar el uso de guías clínicas y protocolos de atención que ayuden a los profesionales en la toma de decisiones diagnosticas y terapéuticas. Además, será posible incorporar alertas y alarmas vinculadas con hechos críticos predefinidos, proveer a los profesionales de herramientas que permitan generar reportes con fines académicos, de investigación, clínicos y administrativos. Asimismo, se potencia la información financiera y administrativa, lo que permitirá a las autoridades tomar decisiones oportunas en base a información fidedigna obtenida en tiempo real.

Otro de los impactos esperados deriva del hecho que será posible lograr que la información clínica de un paciente esté disponible en forma inmediata en el momento en que éste requiera de atención profesional, independientemente del lugar de la Red de Salud en que se encuentre.

2 OBJETIVOS DEL PROYECTO * 3.6 INFORMACIÓN GENERAL El proyecto “Sistema de Gestión Hospitalaria” tiene impacto fundamentalmente en cinco áreas: 3.7.1 Para el área Clínica: Proveer un conjunto de funcionalidades estrechamente ligadas a la labor del equipo de salud, destinadas a facilitar su trabajo, mejorar la oportunidad y la calidad de la información disponible para la toma de decisiones clínicas, a proporcionar ayuda en línea mediante el uso de protocolos y guías clínicas, a minimizar posibles causas de errores en los procesos y a generar reportes que faciliten tanto la gestión como la confección de trabajos de investigación. Estas funcionalidades deben lograrse mediante el uso de interfaces de usuario que reúnan las características de ser amigables, de fácil uso y adaptables a las necesidades de las diversas especialidades médicas. Dado que el objetivo primario de la solución esperada es proveer herramientas modernas para gestionar la producción de prestaciones y acciones de salud, se solicita que la solución cuente con una herramienta potente y versátil para producir reportes preestablecidos, que permita que el administrador del sistema genere nuevos reportes de acuerdo con las necesidades y que los ejecutivos puedan contar con un tablero de mando con indicadores en tiempo real (BSC = Balaced Score Card). Estos indicadores tendrán niveles de agregación crecientes, destinados a satisfacer las necesidades de los diversos niveles jerárquicos de la Organización.

3.7.2 Para el área Administrativa Proveer un sistema administrativo financiero integrado entre sí y con el sistema clínico que permita el registro en tiempo real de las transacciones, privilegiando la automatización de procesos como elemento distintivo.

Debe permitir la estructuración de la organización en base a Unidades Tácticas (Unidades Estratégicas de Negocio) y la generación de Estados de Resultados Operacionales en línea por unidad táctica. Estas unidades se deberán poder consolidar de acuerdo a un patrón que se definirá en el momento de realizar la Reingeniería de procesos y configuración del Plan de Cuentas.

Al momento de los cierres de periodo contable deberán agregarse los gastos de Administración y Ventas, para establecer el resultado efectivo de la Unidad.

3.7.3 Para la Gestión Hospitalaria La inclusión de diversas herramientas debe proveer a los diferentes niveles ejecutivos, de información en tiempo real expresada en tableros de mando con niveles de agregación de información acorde con los privilegios de usuario, que permitan la toma de decisiones oportuna e informada. Los niveles más altos dispondrán de funcionalidades de DRILL IN para llegar a la máxima granularidad de la información.

Asimismo las herramientas de explotación de datos permitirá la detección de las mejores prácticas y de información relevante para el costeo de las prestaciones de salud y eventualmente el empleo de modelos matemáticos y estadísticas predictivas derivadas de análisis de correlación multidimensional.

Las herramientas de apoyo a la Gestión a que se hace referencia son las siguientes:

a. Herramientas de generadora de reportes. b. Una herramienta para GRD c. Un datawarehouse (DWH). d. Una herramienta de inteligencia de negocio (BI). e. Una herramienta de minería de datos.

3.7.4 Para la Institución: Soportar con un único sistema integrado a la totalidad de las entidades que están vinculadas con el sistema asistencial de los funcionarios de Carabineros de Chile y sus cargas familiares legalmente reconocidas, utilizando la cualidad multiempresa y multicentro de la solución requerida, con opción de consolidación contable de aquellas que se requiera para los efectos de análisis y presentación de resultados.

La plena integración de los componentes del sistema entre sí y la opción de integración con otros aplicativos Institucionales y de reparticiones estatales, incrementarán el nivel de automatización del sistema y por lo tanto su eficiencia, eficacia, confiabilidad y oportunidad de cumplimiento de normas y reglamentos vigentes. 3.7.5 Para el beneficiario del Sistema de Salud de Carabineros:

Permitirá que la información clínica de cada funcionario de la Institución que se encuentre en actividad y de sus respectivas cargas familiares, lo acompañe en sus desplazamientos y destinaciones a lo largo del país y en el extranjero.

Con esto maximiza sus opciones de oportunidad y certidumbre de los diagnósticos, toda vez que el profesional que lo atienda podrá contar con información relevante y fidedigna, que le permita acotar su incertidumbre diagnostica y acortar los periodos de estudio y tratamiento, recuperando su condición de salud en el plazo más breve posible.

3.7 OBJETIVOS DEL PROYECTO: El objetivo del proyecto es proveer los elementos necesarios para lograr mejores capacidades de gestión de los procesos productivos de prestaciones de salud.

El proyecto tiene entre otros, los siguientes objetivos específicos:

a. Evitar el ingreso de datos demográficos, los que serán capturados únicamente desde el Archivo Maestro de Pacientes (Clientes). b. Facilitar el registro utilizando preferentemente combo boxes y el uso de selección de opciones pre establecidas susceptibles de ser marcadas con un clic, a fin de reducir a un mínimo la escritura en forma de texto libre. c. Definición configurable de campos de registro obligatorio, editables o de sólo lectura. d. Acceder fácilmente a la prescripción electrónica. No debe haber doble digitación. La anotación de indicaciones farmacológicas en la FCE (plan terapéutico), deberá generar automáticamente la prescripción (o viceversa, dependiendo de las condiciones de integración). e. Acceder fácilmente a los formularios de solicitudes de pabellón quirúrgico, exámenes o procedimientos. No debe haber doble digitación. Las solicitudes de exámenes o procedimientos), deberán generar automáticamente la anotación en la FCE (plan de estudio) (o viceversa, dependiendo de las condiciones de integración). f. Utilizar el sistema de codificación diagnostica CIE 10 e incorporar estándares internacionales. g. Automatizar la generación de resúmenes clínicos, epicrisis e indicaciones de alta. h. Automatizar la organización y registro del trabajo de enfermería i. El sistema deberá permitir identificar las enfermedades de declaración obligatoria, supervigilancia epidemiológica y situaciones médico legales que el administrador del sistema defina, emitiendo alertas y poniendo a disposición los formularios pertinentes. Estos casos deben llegar por algún medio a la autoridad del establecimiento que se defina, a fin de cursarlas a las entidades que corresponda. j. Poder visualizar remotamente resultados de exámenes, curvas de signos vitales y anotaciones de enfermería, en pacientes hospitalizados. Eventualmente debe poder enviar informaciones específicas vía mensajes SMS o correo electrónico a los médicos tratantes. k. Facilitar la detección de casos y tabulación de datos para fines de investigación clínica. l. Obtener ayuda en línea, utilizando sistemas de ayuda farmacológica, guías y protocolos clínicos. m. Debe utilizar terminología estandarizada SNOMED n. Evitar riesgos derivados de ilegibilidad de las indicaciones médicas y farmacológicas. o. Disponer de acceso instantáneo a la información clínica desde cualquier punto de la Red de Salud, generando la portabilidad de la información clínica (La información disponible está donde esté el paciente) p. Automatizar y racionalizar los procesos q. Mejorar la calidad y oportunidad de la información para toma de decisiones, reduciendo los tiempos de estudio y de incapacidad laboral. r. Lograr plena integración entre los procesos clínicos y los procesos administrativos, de modo que los registros en el sistema administrativo – financiero se realicen en forma automática y en el momento en que ocurren las acciones clínicas. s. Incorporar en los análisis el concepto de GRD (Grupos Relacionados de Diagnósticos). Esta aplicación permite discriminar los grados de complejidad de diversas prestaciones de una misma denominación, a fin de poder segmentar la estructura de costos de las prestaciones según el criterio de complejidad. t. Automatizar los procesos de Notificaciones de diversa naturaleza, destinados a satisfacer necesidades propias y de entidades Estatales u. Disponer de herramientas de análisis v. Disponer de herramientas generadoras de reportes w. Disponer de información estructurada x. Obtener indicadores de gestión en tiempo real. y. Evitar que se incremente el volumen de bodegaje de fichas z. Proveer información para la toma de decisiones gerenciales. {. Disponer de tableros gráficos de control. |. Automatizar la captura y monitorización de datos relacionados con la Unidad de Calidad. }. Tener contabilidades al día y alimentar el sistema SIGFE idealmente en forma automática. ~. Modernizar la gestión de toda la Red de Salud basado en unidades de negocio clínicas y administrativas, a fin de poder identificar los centros de beneficio y los centros de pérdida y posibilitar la focalización de las acciones de gestión. El encargado de cada una de estas unidades de negocio dispondrá de un Estado de Resultados Operacionales y de indicadores de gestión en tiempo real. . Propender a la descentralización de la toma de decisiones operacionales. . Disponer de un sistema que posibilite efectuar una gestión moderna que permita afrontar los nuevos desafíos tecnológicos y de costos. . Efectuar explotación de datos utilizando herramientas avanzadas de Datawarehouse (DWH), Inteligencia de Negocios y Minería de Datos, orientado a la detección de las mejores prácticas y al control de costos de producción de prestaciones de salud

3.8 CARACTERÍSTICAS TÉCNICAS QUE DEBE TENER LA SOLUCIÓN BUSCADA. La solución buscada considera la adquisición de un ERP y una Ficha Clínica Electrónica que deben operar completamente integradas e incluir algunas herramientas adicionales para facilitar su integración con otros aplicativos y para posibilitar la gestión clínica y la explotación de datos. Las características generales de la solución son las siguientes, sin perjuicio de otras cualidades o funcionalidades que se señalen en las especificaciones técnicas.

3.9.6 Características de Arquitectura

a. Operación WEB (Arquitectura de tres capas) b. Arquitectura centralizada. c. Operar Multiempresa. d. Operar Multicentro. e. Arquitectura modular (esto es constituido por subsistemas funcionales independientes, integrables entre sí), idealmente basados en Arquitectura SOA (Service Oriented Aplication) con interfaz a formato HL7 (Health Level 7). f. Ser escalable en cuanto a módulos en uso y en cantidad de usuarios nombrados y concurrentes. g. Parametrizable, de modo tal que el administrador del sistema pueda configurar las funcionalidades, sin que sea necesario programación y acceso a bajo nivel de datos. h. Capacidad para diseño asistido de reportes, formularios y pantallas auxiliares, con una herramienta grafica adosada al sistema. i. Capacidad de integrar aplicativos, mediante el uso una plataforma de integración. (Middleware). j. Utilizar navegador Internet Explorer 7.x y superior y deseablemente, también Mozilla Firefox. k. Debe tener capacidad para utilizar autenticación biométrica de usuarios (huella dactilar) o tarjetas inteligentes. l. Debe actualizar versiones en los terminales de usuario, desde los servidores en forma automática. m. Debe operar en ambiente virtualizado y soportar configuración en cluster con balanceo de carga. n. Debe operar en condiciones de alta disponibilidad (99.9), con redundancia de servidores y de dispositivos de almacenamiento de datos y archivos. 3.9.7 Características funcionales: a. Interfaces de usuario en idioma español (de uso en Chile).

b. Debe desplegar imágenes (Ej. De exámenes de Imagenología (DICOM 3), de monitores clínicos, imágenes JPEG, otras).

c. Debe poder escanear y guardar documentos a nivel de las estaciones de trabajo, los que deben formar parte de la FCE.

d. Debe poder adaptar las interfaces (pantallas) de usuario a las necesidades clínicas específicas, mediante un Framework susceptible de ser operado por el administrador del sistema.

e. Debe poderse modificar los nombres con que se identifican los campos en las interfaces de usuario (etiquetas o labels), a fin de incorporar terminología local. f. A fin de poder cumplir con las actividades docentes, el sistema debe permitir la creación de varias categorías de alumnos-usuarios, quienes podrán ingresar datos en la FCE utilizando caracteres de color a fin de ser identificado fácilmente, en calidad de “registro transitorio”, el que podrá ser borrado, modificado o validado por un profesional usuario normal, tras lo cual, el registro será inmodificable. Debe haber algún sistema que advierta al médico tratante (responsable del paciente) de la existencia de estos registros transitorios, que no han sido validados.

g. Debe tener un Log de registro de transacciones que permita efectuar auditorias.

h. Debe proveer, utilizar y administrar una firma electrónica privada (simple), acorde con la legislación chilena.

i. Debe cumplir con la reglamentación y legislación chilena vinculada con la privacidad de la información sensible, con la reglamentación pertinente emanada del Ministerio de Salud, DIPRECA (Dirección de Previsión de Carabineros), DISALCAR y Carabineros de Chile.

j. Debe poder incorporar fotografías digitales desde los módulos de uso clínico.

k. Trazabilidad de las acciones realizadas y de la información almacenada en el sistema FCE (cumpliendo todos los estándares de confidencialidad y protección de datos del paciente).

l. Estandarización de procesos transversales para toda la Organización, a partir de la reingeniería de procesos.

m. Estandarización de la información clínica y administrativa.

n. Debe permitir configurar y gestionar programas de salud ministeriales e institucionales, tanto en pacientes pediátricos como en adultos y medicina familiar.

o. Debe permitir la gestión del concepto de medicina familiar en los Centros de Salud Familiar (CESFAM), utilizando árboles de vinculación parental.

3.9.8 Características de estándares: a. Integrado entre sí e integrable con otros aplicativos mediante estándares HL 7. b. Utilizar de estándares HL7, CIE 10, DICOM 3, SNOMED. c. Debe utilizar código de barras EAN-13, EAN-128, DUN-14, Datamatrix, (impresión y lectura de etiquetas) desde terminales fijos y móviles (inalámbricos). Debe soportar los drivers de los dispositivos correspondientes. d. Debe proveer Manuales de usuario y Documentación en idioma Español de uso en Chile. e. Debe adecuarse en todo momento a la legislación y reglamentación chilena y reglamentación Institucional vigente. f. Debe utilizar el RUT con dígito verificador, (debe incorporar algoritmo de cálculo del digito verificador) como identificador principal. 3.9.9 Características de seguridad: a. Debe disponer de niveles de seguridad de acceso, configurables en cuanto a datos, a funcionalidades y a estructura organizacional. b. Autorización y autenticación de ingreso. c. Capacidad de generación y configuración de roles, reglas y privilegios por parte del administrador. d. Capacidad de encriptación en las comunicaciones. e. Registro de operaciones en Log y capacidad de auditoría de los mismos. Alertas predefinidas. f. Debe utilizar un sistema biométrico de huella dactilar como validador de la identificación. g. Ofrecer garantía que en los accesos a la FCE se cumpla con lo estatuido en la Ley Nº 19.628 sobre Protección de Vida Privada o datos de carácter personal.

3.9 LA ARQUITECTURA DEL PROYECTO Y SU POSIBILIDAD DE EXPANSIÓN

El sistema debe soportar los requerimientos de Gestión Hospitalaria de la Red de Salud de Carabineros distribuidos a lo largo del país, en condiciones de operación en línea y de alta disponibilidad, manteniendo la integridad y confidencialidad de la información clínica de los pacientes. Se entiende por sistema de Gestión Hospitalaria la operación integrada de un sistema de Registros Clínicos, (Ficha Clínica Electrónica) plenamente integrado con un sistema Administrativo Financiero (ERP) y con algunos subsistemas legados del área clínica, administrativa, Institucional y del Estado, utilizando una plataforma de integración robusta y versátil. Las comunicaciones a nivel Nacional se realizarán a través de la Intranet Institucional y enlaces dedicados. Algunos accesos ocurrirán desde Internet empleando configuraciones VPN (Virtual Private Network).

3.10.10 LA RED DE SALUD: La red está formada por varios Centros Medico Dentales, Centros Médicos, Policlínicos, Centro de Rehabilitación Infantil y Centro de Salud Familiar, que tienen diversos niveles de complejidad y que se encuentran distribuidos a lo largo del país. En Santiago se ubica el Hospital de Carabineros (HOSCAR), que cuenta con 250 camas. El detalle de estos establecimientos se encuentra en el Capitulo 11 de las presentes Bases Técnicas. 3.10.11 EL REGISTRO CLÍNICO ELECTRÓNICO o FICHA CLÍNICA ELECTRÓNICA (FCE):

La FCE estará centrada en el paciente, de modo que existirá una ficha clínica única nacional para cada funcionario y para cada una de sus cargas familiares. Los Establecimientos de Salud atienden pacientes de acuerdo con su nivel de complejidad. Para esto deben acceder a la FCE que es única para cada funcionario. El acceso a la FCE y el registro de acciones de salud, debe generar una transacción correspondiente a la prestación y a los eventuales fármacos e insumos utilizados que debe quedar registrada en el sistema administrativo financiero correspondiente, asentando un cargo en la cuenta de paciente, un ingreso para el establecimiento, y los correspondientes movimientos de stock en bodegas de farmacia, dispensadores automáticos o botiquines, según corresponda. El acceso ambulatorio de un paciente al establecimiento de salud se inicia con su ingreso a la AGENDA médica. El Módulo de agenda es común para todos los establecimientos de la Red. La vista de la agenda será por defecto las que correspondan al Centro. El operador podrá ingresar y agendar pacientes en el establecimiento que requiera. El punto de la red desde el cual se genera el acceso a la FCE o el dominio al que este pertenece, permitirá enrutar la transacción administrativa al Sistema Administrativo Contable (ERP) correspondiente al establecimiento. Del mismo modo la identidad de este punto de acceso, permitirá que la FCE utilice la parametrización que corresponde al establecimiento en cuestión, reconociendo sus dependencias, funcionarios, farmacia y servicios de apoyo. Cada uno de los Establecimientos de Salud debe poder GENERAR (crear por primera vez) la FCE única. El sistema debe poder reconocer el Establecimiento que dio “origen” a la FCE

3.10.12 EL ERP (Enterprise resource Planning)

El ERP está centrado en el Establecimiento de Salud y opera en forma independiente para cada uno de ellos, de acuerdo con los niveles jerárquicos de consolidación que se defina.

Debe permitir que cada una de las diferentes razones sociales vinculadas con la Red de Salud pueda llevar una contabilidad completamente independiente de las demás. Debido a esto el ERP debe discriminar a partir de la identificación del terminal (o del dominio) que genera la transacción en la FCE, cual es la contabilidad que corresponde. La FCE y el ERP deben estar integrados entre sí en forma nativa o utilizando una plataforma de integración provista por el oferente. Esta misma herramienta permitirá integrar los aplicativos legados tanto clínicos como administrativos y algunos aplicativos externos. 3.10.13 CAPA DE SEGURIDAD:

El sistema debe contar con una fuerte capa de seguridad informática empleando tanto elementos de hardware como de software para evitar intrusiones y virus. 3.10.14 IDENTIFICACIÓN BIOMÉTRICA:

Un sistema biométrico para la validación de la identidad de pacientes y autenticación de los funcionarios. Esta misma aplicación permitirá operar la firma electrónica privada.

En este caso la identificación biométrica prevista es la huella digital. El poblamiento del repositorio para los usuarios (funcionarios de la red) se hará en forma masiva en cada establecimiento. El poblamiento de los beneficiarios (pacientes) se hará en los puntos de atención, con la primera consulta que efectúe, cotejando el carné de identidad con el Archivo Maestro de Pacientes que existe.
Esta primera consulta generará también la FCE única nacional, quedando registrada en la FCE el establecimiento que la generó (sólo para referencia estadística) 3.10.15 EL FUNCIONAMIENTO: El proceso se inicia en un establecimiento de la Red, por ejemplo: Viña del Mar, con la asignación de un cupo en la agenda para ser atendido previa identificación del usuario y del paciente a través del dispositivo biométrico.

Al momento de la consulta el médico selecciona al paciente en la lista de trabajo, en ese momento el paciente ingresa su validación biométrica para que se abra la FCE, utilizando automáticamente la Parametrización que corresponde al establecimiento en que está siendo atendido el paciente.

El registro de información en la FCE permite que el Centro de Salud de Viña del Mar acredite en su ERP una venta de la prestación y a la vez registre el cargo en cuenta de paciente. Si se utilizan insumos de cargo de paciente, se registrarán los movimientos correspondientes en bodega, botiquín u otro y el cargo en cuenta de paciente o cargo de servicio (Unidad de negocio) según corresponda.

De igual forma operaran todos los establecimientos: ingresando a una aplicación de FCE común en cuanto a información clínica del paciente y registrando en las cuentas del ERP respectivas.

3.10.16 CAPACIDAD DE EXPANSIÓN POTENCIAL (EVENTUAL) Se espera extender este servicio incorporando nuevos centros médicos en Santiago y en Provincia, los que se encuentran en etapa de proyecto y también incorporar algunos servicios clínicos adicionales al hospital

Cada establecimiento deberá tener su propia cuenta de ERP, organizado de acuerdo con la jerarquía de consolidación que se defina.

La aplicación de FCE continuará siendo común para todos ellos. De igual modo serán de uso común (compartido), la capa de identificación biométrica, la firma electrónica, la capa de seguridad y la plataforma de integración.

La forma de crecimiento es simplemente agregar nuevos establecimientos e instancias al modelo ya indicado, realizando ajustes en las parametrizaciones. 3.10.17 DATACENTER:

El servicio de Datacenter y el hardware correspondiente, será proporcionado por el FONDO, procediendo a la compra de este material o la contratación de un servicio de HOSTING, sobre la base del dimensionamiento y requerimientos técnicos propuestos por el Oferente, según lo requerido en el punto 5.8.2 de las presentes Bases.

3.10 los OFERENTEs En su propuesta los oferentes deberán incluir la totalidad de los componentes y herramientas incorporadas al Sistema de Gestión Hospitalaria, deberá presentar su empresa y demostrar su experiencia en el mercado, indicando la lista de sus clientes en materia de FCE y de ERP con los que ha actuado en calidad de contratista principal, con específica indicación de la cantidad de camas de hospital que representa cada uno de sus clientes.

En caso que el Contratista Principal (Prime Contractor) actúe en consorcio con otra u otras empresas, debe presentar la información requerida correspondiente a estas empresas y acompañar el contrato de consorcio que haya establecido en el que se garantice el soporte y mantenimiento de los componentes del sistema por un lapso mínimo de 10 años. Adicionalmente deberá acreditar casos de éxito propios y de las empresas del consorcio, con certificados emitidos por el cliente, el que podría ser entrevistado por el FONDO.

CERTIFICACIONES CON QUE CUENTAN LOS PRODUCTOS Y LOS OFERENTES. El oferente deberá incluir en su oferta las certificaciones de cualquier tipo con que cuenta tanto el/los proveedores como sus respectivos productos (Ej. HL7, CMMi, ISO).

Entiéndase por productos los aplicativos de FCE, ERP, Herramienta de integración, DWH (Datawarehouse), BI (Bussiness Inteligente), IR-GRD.

3 plazo del proyecto

El plazo total del proyecto, esto es, desde la fecha de suscripción del contrato hasta el inicio del periodo de garantía, no podrá superar los 24 meses. No obstante lo anterior y atendido la extremada complejidad del Proyecto, este podrá ser extendido hasta en un 20%, si este plazo es aprobado por ambas partes contratantes y no implica cambios en el monto licitado por concepto alguno.

4 MATERIA LICITADA:

Los elementos de software y servicios complementarios que se licitan son los siguientes, sin perjuicio de los detalles técnicos específicos que se señala más adelante: 5.11 Un Registro Clínico Electrónico: (=Ficha Clínica Electrónica = FCE), también conocida en inglés como EMR (Electronic Medical Record) destinada a registrar los eventos clínicos de los pacientes, sustituyendo el documento en papel que actualmente cumple con esta función. Debe contener los siguientes módulos: a. Clínico (para ser utilizado por el médicos y los profesionales del equipo de salud) b. Enfermería c. Nutrición d. Farmacología (Recetario inteligente) e. Servicios intermedios (servicios de apoyo clínico) f. Atención de Policlínico g. Agenda médica h. Admisión (administración de camas) i. Servicio de urgencia j. Camas criticas k. Pabellones Quirúrgicos l. Esterilización m. Odontología n. Formularios, Certificados y notificaciones o. Infecciones intra hospitalarias (IIH) p. Gestión de Centros de Salud Familiar (CESFAM) y de Programas de Salud (vacunación en lactantes, detección precoz de canceres, diabetes, hipertensión, obesidad, enfermedad coronaria, otros) q. Autoservicio de información al paciente (Kioscos)

5.12 Un ERP(ENTERPRISE RESOURCE PLANNING) Destinado a gestionar la totalidad de los procesos administrativo contables y proporcionar un efectivo apoyo al área productiva.
Debe contener al menos los siguientes módulos: 5.13.18 Finanzas. a. Contabilidad. Dentro de sus funciones debe incorporar las siguientes que están directamente vinculadas con la gestión clínica y administrativa: i. Manejo de múltiples aranceles para las prestaciones que otorga el hospital, dependiendo de planes, convenios, organismo financiador, y/o otras condiciones. ii. Cuenta de pacientes. iii. Manejo de reglas de elegibilidad crediticia del cliente. iv. Contabilidad Financiera, que permita operar con al menos 5 niveles jerárquicos en el Plan de Cuentas a fin de estructurar la organización en base a Unidades Tácticas (Unidades Estratégicas de Negocio). v. Debe tener una salida que reagrupe las cuentas para satisfacer las necesidades de Contabilidad Gubernamental y alimentar en forma automática el sistema SIGFE II. b. Presupuesto.

De acuerdo con los requerimientos gubernamentales.
Debe estar vinculado con cuentas contables cuando corresponda.

5.13.19 Recursos Humanos a. Reclutamiento. b. Hoja de Vida de funcionarios. c. Remuneraciones. d. Manejo de situaciones previsionales (licencias médicas) e. Actividades de Capacitación.

5.13.20 Bienes y Activos a. Valorización de Existencias i. Administración de bodegas de farmacia e insumos. b. Registro de Activo Fijo ii. Historial de mantención. iii. Planificación de programas de mantención preventiva. iv. Depreciación de activos y valor residual. 5.13 UNA HERRAMIENTA DE INTEGRACIÓN Destinada a integrar los diferentes aplicativos de modo que operen funcionalmente como un sistema único. Es necesario que permita la incorporación de lógicas de negocios. 5.14 Herramientas complementarias

Estas herramientas pueden ser aplicativos independientes o estar embebidas en los aplicativos de FCE y/o ERP. a. Un aplicativo para clasificación de IR-GRD, que corresponda a la modalidad taxonomía y diseño dominante adoptado por el MINSAL (Ministerio De Salud). b. Una herramienta para generar a voluntad reportes rutinarios, tanto de FCE como de ERP. c. Una herramienta que permita que el administrador del sistema FCE pueda configurar interfaces de usuario, de acuerdo con la especialidad y requerimientos clínicos. Idealmente una herramienta del tipo “arrastrar y soltar”. d. Una herramienta para generar, mantener e invocar Guías y Protocolos Clínicos. e. Una herramienta para generar o configurar formularios y documentos “inteligentes” que permita incorporar campos estructurados simples y de selección múltiple que se auto llenen si existe dato en el campo y que permita que el usuario lo complete si el campo esta vacío. También debe permitir incorporar campos de texto libre. f. Un Datawarehouse (DWH). g. Un tablero gráfico de mando que opere en línea. h. Una herramienta de Inteligencia de Negocio (BI). i. Una herramienta de integración (propietaria o de uso comercial). j. Un sistema de firma electrónica privada (simple). k. Un sistema biométrico de validación de identificación para funcionarios y pacientes, que además permita operar la firma electrónica simple o privada.

5.15 SERVICIOS COMPLEMENTARIOS a. Levantamiento y reingeniería de procesos. b. Gestión del Cambio. Debe aportar la metodología, un monitor calificado y responsabilizarse de orientar acciones para obtener los resultados deseados. c. Capacitación de usuarios bajo la modalidad “entrenar a los entrenadores”, con responsabilidad del oferente por el logro de los resultados que permitan la explotación del Sistema.

5.16 Documentación del Sistema: Toda la documentación deberá ser presentada en formato PDF en versión final, acompañada de los documentos originarios en su formato base (MS Office, Visio, BizAgi u otros). La entrega y aceptación de esta documentación será condición necesaria para la aceptación del Término de la Marcha Blanca. a. Manuales de arquitectura del sistema. b. Manual de arquitectura y topología de los servidores. c. Manual de uso del Software de virtualización. d. Manual de Parametrización del sistema. e. Manual de Configuración del sistema. f. Manual de procesos diseñados e implementados. g. Manuales de operación de los diferentes módulos. h. Manual de uso de las herramientas incorporadas al Proyecto. i. Manual de Contingencias. j. Documentación del proceso de Capacitación y sus resultados. k. Documentación del proceso del Gestión del Cambio y sus resultados. l. Documentación del modelo de datos. m. Modelos de Datos de los Sistemas. n. Documentación de configuración del DWH y de la herramienta de BI. o. Documentación de la configuración del Tablero de Mando.

5.17 LICENCIAS Para esta solución se debe proveer licencias suficientes para los aplicativos de ERP y FCE de acuerdo con el detalle de la cantidad de funcionarios declarados en el Capítulo 11 (más un 10% como mínimo), en los numerales 11.9, 11.10, 11.11, 11.12 y 11.13; considerando un crecimiento de un 10%. Se hace presente que los profesionales de la Salud por lo general tienen jornadas parciales que no exceden las 22 horas semanales, siendo frecuente, sobre todo en provincias, que la jornada de trabajo pueda no exceder de 11 horas semanales. El personal auxiliar paramédico por lo general tiene jornada completa, al igual que el personal administrativo, usuario del ERP. También se hace presente que, dado la estructuración de las personas usuarias del sistema caracterizadas por roles, perfiles y privilegios, sólo una pequeña proporción tiene acceso a la totalidad de los módulos, siendo lo habitual que los diferentes estamentos tengan acceso sólo a un módulo. Adicionalmente se deberán proveer licencias para los aplicativos de terceros tales como BI, DWH, herramienta de Integración (si es de marca comercial) y de Bases de Datos. Los derechos de uso de las licencias de la totalidad de los software que se integran en el sistema, propias o de terceros, deberán ser transferidas en propiedad al “FONDO” (FONDO PARA HOSPITALES DE CARABINEROS DE CHILE).

5 CARACTERÍSTICAS FUNCIONALES DE LA SOLUCIÓN DEL “SISTEMA DE GESTIÓN HOSPITALARIA” La tradicional Ficha Clínica (manuscrita en papel), es un documento destinado a registrar y conservar la totalidad de los antecedentes y eventos clínicos de un paciente a lo largo de su vida.

En ella intervienen los diferentes miembros del equipo de salud, dejando constancia de sus participaciones. De igual modo se registran los exámenes y procedimientos diagnósticos y terapéuticos efectuados, intervenciones quirúrgicas, atenciones de enfermería y de servicios de apoyo. Se solicita que la FCE, cumpla con los objetivos señalados precedentemente y que provea al menos las funcionalidades específicas que para cada módulo se señala a continuación.

6.18 MÓDULOS REQUERIDOS para el área clínica Y SUS FUNCIONALIDADES. * La agrupación modular de funcionalidades que a continuación se indica ha sido realizada tomando en consideración las necesidades funcionales de los diversos tipo de profesionales que participa en las actividades clínicas y también las condiciones particulares de algunos tipos de atención especializada, tales como la atención de urgencia, la atención de pacientes en camas criticas y de cada una de las especialidades médicas y odontológicas

6.19.21 MÓDULO CLÍNICO (MÓDULO MÉDICO) Está destinado a apoyar la labor de los médicos constituyéndose en el medio en el cual podrán registrar la información del paciente y también consultar la información, correspondiente a eventos actuales o anteriores, a fin de respaldar sus decisiones diagnósticas y terapéuticas. Este Módulo debe privilegiar la utilización de campos de información estructurada empleando campos de selección múltiple y minimizar el uso de textos libres, lo que se reserva para argumentar y/o fundamentar análisis clínicos y/o diagnósticos. La interfaces de usuario deben ser las adecuadas para cada una de las especialidades y sub especialidades médicas y poder generarse con una herramienta del sistema que pueda ser utilizada por los administradores del sistema, con posterioridad a la parametrización y configuración de puesta en marcha.

Debe estar completamente integrado con los demás módulos tanto de la FCE como del ERP que en los puntos que corresponda de acuerdo a los respectivos procesos. Es importante destacar las funcionalidades que permitan gestionar programas de salud y de vacunación, realizar labores docentes y dar soporte al concepto de salud familiar. Nro | Concepto | Funcionalidad | 1 | Identificación del paciente | Captura de antecedentes demográficos desde archivo maestro de pacientes (clientes). | 2 | | Generación de episodios y eventos clínicos. Discriminación si episodio es nuevo o control de uno existente. | 3 | Motivo de Consulta | Anamnesis actual. Capacidad para registrar síntomas y registrar signos dominantes, en campos estructurados de selección. | 4 | | Capacidad de la aplicación para que el médico pueda generar y administrar listas cortas de síntomas y de signos de uso frecuente, vinculadas a la especialidad y con su login. | 5 | | Registro de alergias. Selección de alternativas predefinidas parametrizables. La información de alergias debe visualizarse en forma permanente a modo de advertencia. | 6 | | Registro de Hábitos. Selección de alternativas predefinidas parametrizables. | 7 | Enfermedades Previas (anamnesis remota) | Anamnesis remota. Posibilidad de acceso a episodios anteriores. | 8 | | Si no hubiere episodios anteriores en la FCE, capacidad para registrar estos antecedentes en campo texto | 9 | Examen Físico | Registro de Examen Físico. Estructurado, por segmentos y sistemas. | 10 | Diagnóstico | Hipótesis diagnóstica. Se debe poder ingresar la cantidad de diagnósticos que sea necesario. | 11 | | Debe considerarse que los diagnósticos sufren modificaciones durante el estudio, antes de llegar a los diagnósticos definitivos. | 12 | | Uso de nomenclatura CIE 10. | 13 | | El mantenedor del CIE 10 debe permitir agregar sinónimos de uso corriente asociada a la nomenclatura oficial, y acceder por cualquiera de estos sinónimos a la codificación. | 14 | | Capacidad para que el médico pueda generar y administrar listas cortas de diagnósticos frecuentes, vinculadas con su login. | 15 | Plan de Estudio | El médico registra en la FCE los exámenes requeridos. Vinculo con módulo de formularios. | 16 | | A partir de esta información debe generarse automáticamente las solicitudes de examen a los departamentos que corresponda. También puede ser a la inversa, que el médico solicite los exámenes en el formulario correspondiente, y a partir de esto se registre en la FCE los exámenes solicitados. (Evitar doble digitación) | 17 | | Los formularios deben estar integrados con Laboratorio, RIS-PACS, Banco de Sangre, Servicios de apoyo clínico (exámenes y procedimientos diagnósticos. Ej. Endoscopía) | 18 | Resultado de exámenes | Trazabilidad y visualización del estatus de las solicitudes. (Ej. pendiente, realizado, pendiente de informe, terminado) | 19 | | Recepción automática de resultados de exámenes de laboratorio y servicios de apoyo clínico. | 20 | | Capacidad para visualización de imágenes de exámenes de Imagenología en formato DICOM e imágenes de exámenes de servicios de apoyo en formato JPEG u otros. | 21 | Plan Terapéutico: Prescripción de Medicamentos | El médico registra diariamente en la FCE la medicación prescrita. (Producto, presentación, dosis, vía de aplicación, frecuencia y días de uso). Se requiere que el médico ingrese los medicamentos una sola vez, llenándose automáticamente el registro en la FCE y el recetario. (Evitar doble digitación). | 22 | | A partir de este registro, debe generarse automáticamente la receta electrónica. El proceso puede ocurrir a la inversa, que el médico ingrese la prescripción directamente en el formulario recetario, para aprovechar las ventajas e inteligencia del módulo de farmacia, y a partir de esto se registre en la FCE los medicamentos indicados. (Evitar doble digitación) | 23 | | Mediante integración, las indicaciones de terapia y estudio, se transferirán automáticamente al módulo de enfermería | 24 | | Visualización de alertas en alergias medicamentosas, contraindicaciones o interacciones con otros medicamentos prescritos. En estos casos debe impedir la indicación. | 25 | | El sistema debe cotejar la indicación que se está intentando ingresar, con los otros medicamentos ya indicados, a fin de verificar la existencia de interacción de medicamentos. Integración con módulo de farmacología. | 26 | | En caso de insistir en la indicación a pesar de las alertas, el médico deberá justificar sus razones, bajo su firma, en un campo que aparecerá para dicho efecto. | 27 | | El sistema no aceptará indicaciones de dosis de medicamentos que se encuentre fuera de los rangos de uso habitual. El módulo de farmacia considera dosis de infantes y lactantes calculadas sobre el peso del niño. | 28 | | En caso de insistir en la indicación de dosis inusuales, a pesar de las alertas, el médico deberá justificar sus razones, bajo su firma, en un campo que aparecerá para dicho efecto. | 29 | | Posibilidad de suspender o anular una prescripción que deba aplicarse a futuro (Ej. Necesidad de cambiar un tratamiento ya iniciado). Si se ha indicado una terapia medicamentosa para varios días, se podrán anular o suspender las dosis aun no aplicadas. | 30 | | La suspensión o anulación se reflejara en el módulo de enfermería. | 31 | | Posibilidad de repetir y/o modificar prescripciones anteriores, para generar una nueva prescripción. | 32 | | Las prescripciones ya firmadas (realizadas) no podrán ser modificadas. Para modificar en estos casos, debe SUSPENDER la indicación y volver a indicar. Las prescripciones NO FIRMADAS podrán ser modificadas. | 33 | | En general ninguna información, registro, solicitud, prescripción ni indicación podrá ser modificada desde el momento en qué esta es firmada (grabada). Hacen excepción los registros no validados realizados por alumnos e internos). | 34 | | Si se desea modificar una indicación debe suspenderse esa terapia e indicar otra nueva. | 35 | | Capacidad para proporcionar ayuda farmacológica. Vinculación con módulo Farmacia. Dosis máximas, mínimas, interacciones, antagonismos, alergias, alternativas de nombres comerciales, genéricos. | 36 | | Capacidad para que el médico pueda generar y administrar listas cortas de medicamentos frecuentes, vinculadas con su login. | 37 | | Alerta en caso de duplicidad de prescripción. | 38 | | Indicaciones de cuidados de enfermería. Integración con módulo de enfermería | 39 | | Indicación de reposo. Selección múltiple de opciones. Aparecerá señalado en pantalla de enfermería. | 40 | Nutrición | Indicación nutricional habitual (dieta). Integración con módulo de nutrición. | 41 | | Nutrición Enteral. Integración con módulo de farmacia. | 42 | | Nutrición Para enteral. Integración con módulo de farmacia. | 43 | Evolución del paciente | Registro de Evolución Clínica. Permite anotaciones correspondientes a los controles en visitas o consultas sucesivas en pacientes hospitalizados y ambulatorios. | 44 | | Permite registrar la participación de inter consultores, kinesiólogos, u otros profesionales que se defina, vinculados con las indicaciones o requerimientos del médico tratante. | 45 | | Diagnósticos Definitivos, utilizando Nomenclatura CIE 10. | 46 | | Se debe poder ingresar la cantidad de diagnósticos definitivos que sea necesario. | 47 | | Capacidad del sistema para generar y presentar en pantalla, resúmenes clínicos que permitan visualizar la situación del paciente. Estos resúmenes deberán contener información que se defina, de Síntomas principales, diagnostico de ingreso, evolución de los diagnósticos, plan de estudio, plan terapéutico, balance hídrico, signos vitales, protocolo operatorio. Capacidad de ser impresos. | 48 | | Visualización de eventos anteriores, ordenados por fecha, los que pueden ser visualizados. | 49 | Epicrisis | Confección automática de la Epicrisis. Debe contener un campo para agregar automáticamente la clasificación GRD, cuando ésta haya sido realizada. Debe ofrecer un formato pre llenado con datos relevantes que se defina los que serán capturados del sistema, incluyendo terapia ambulatorias e indicación de controles, el que podrá ser complementado por el médico, llenando campos adicionales o incorporando texto libre. | 50 | | La Epicrisis debe poder ser impresa. | 51 | | Vinculación con IR GRD. Debe integrarse en forma bidireccional con el módulo IR GRD. | 52 | Egreso del Paciente | Registro de causa de Egreso. Alta médica, traslado, fallecimiento (Opciones predefinidas seleccionables). | 53 | | Indicaciones de alta médica. Las indicaciones se anotan en forma idéntica a la condición de hospitalización. El sistema captura las indicaciones del último día, que se entienden como indicaciones para cumplir en su domicilio. | 54 | | A partir del alta médica se habilita impresión de indicaciones, recetas, terapia y carné de alta. Puede requerirse la impresión de una receta para ser despachada por farmacia externa. Posibilidad que el paciente obtenga la información que se defina desde los módulos de información de autoservicio (KIOSCOS) | 55 | Pediatría | Debe permitir el registro, gestión y control de programas sanitarios específicos. Puede ser un módulo adicional vinculado a la FCE. Ejemplo: Inmunización (vacunación), control de niño sano. Vinculación con Módulo de Gestión de Centros de Salud Familiar (CESFAM) y de Programas de Salud | 56 | | Debe permitir agregar nuevos programas. (La mayoría de los programas en Chile y su gestión y control están definidos por normas nacionales). | 57 | | Reportes de cumplimiento de programas. | 58 | | Calendario de vacunación configurable, para seguimiento e información del paciente. Puede ser obtenido en los KIOSCOS de autoservicio. | 59 | | Capacidad para el Registro antropométrico percentilado. | 60 | | Registro gráfico de maduración neurológica | 61 | | Capacidad para administrar e imprimir material instructivo para los padres. | 62 | | Capacidad para visualizar DESDE la FCE del neonato, la ficha clínica de la madre. Verificación de antecedentes del embarazo y del parto. | 63 | Programas de Salud | Debe permitir que el paciente pueda ser vinculado con programas de salud y acciones de medicina preventiva. Vinculación con el Módulo de Gestión de Centros de Salud Familiar (CESFAM) y de Programas de Salud. | 64 | Docencia | Debe permitir que los alumnos y becados registren información en la FCE en carácter de BORRADOR, la que tiene que ser validada por el médico a cargo del paciente con su firma electrónica para que tengan valor. Deben poder distinguirse fácilmente estos textos en borrador, por el color, tipo de escritura u otro elemento distintivo. | 65 | | Las indicaciones, solicitudes de examen, medicación y terapias realizadas por alumnos y becados, NO PODRÁN SER EJECUTADAS por el sistema, salvo que sean validadas por el médico tratante. Los alumnos y becados tendrán perfiles de usuario que les asocie la funcionalidad solicitada. | 66 | | El sistema debe advertir que existe un registro clínico en BORRADOR pendiente de validación. Se definirá a quien se debe informar en forma automática esta situación. | 67 | | El sistema debe advertir que un paciente no tiene indicaciones terapéuticas vigentes. (No fue visto por su médico tratante).- Se definirá a quien se debe informar en forma automática. | 68 | Otras Funcionalidades Requeridas | Visualización de información de Enfermería (Signos vitales, balance hídrico, cumplimiento de terapias e indicaciones y otras funcionalidades incorporadas en el módulo de enfermería). Integración con módulo de enfermería. | 69 | | Sub módulo para generar, mantener y desplegar Guías Clínicas. Las Guías Clínicas están destinadas a apoyar la toma de decisiones clínicas con protocolos de diagnóstico y tratamiento. | 70 | | Sub módulo para generar, mantener y desplegar protocolos clínicos. Los protocolos señalan procedimientos establecidos. Ej.: protocolos de patologías AUGE. | 71 | | Capacidad para funcionar en redes inalámbricas (WiFi). | 72 | | Capacidad para operar con notebook y/o Tablet PC, Ipad, Net books. | 73 | | (Compatibilidad con Pantallas Touch Screen de los KIOSCOS y pabellones quirúrgicos). | 74 | | Posibilidad de utilizar PDA y Pocket PC. Dispositivos con pantallas de formato pequeño. | 75 | | Parametrización de la interfaz de usuario de la FCE, para adecuarla a las necesidades de las diferentes especialidades médicas. | 76 | | La aplicación debe contar con herramientas que permitan al administrador del sistema, modificar las pantallas a requerimiento del usuario y vincularlas con el login o rol de usuario | 77 | | Capacidad de incorporar diagramas específicos por especialidad, para que el médico pueda dibujar marcas en determinada región anatómica (Ej. Fondo de ojos, nódulos en mamas, tiroides) | 78 | | Para obstetricia debe incorporar un PARTOGRAMA", que registra parámetros tales como: dilatación cervical, frecuencia de contracciones, frecuencia cardiaca fetal, plano de Hodge. | 79 | | Capacidad para incorporar documentos escaneados a la Ficha, vinculados con el evento. | 80 | | Capacidad para incorporar FOTOS DIGITALES en el momento de la consulta, por puerto USB. Ej.: Dermatología. | 81 | | Debe tener una herramienta que permita al médico configurar una alerta o alarma ante una situación determinada. | 82 | | Calculo automático del IMC (Índice de masa corporal). | 83 | | Alertas para patologías AUGE. Vinculación con CIE 10. Despliegue de formulario especifico. Notificación automática por correo u otro procedimiento a la persona u oficina encargada. | 84 | | Vinculación de las alertas con el protocolo pertinente (si existe). | 85 | | Vincular estas alertas con la lógica de proceso y gestión establecido para enfermedades AUGE. | 86 | | Alertas para enfermedades de notificación obligatoria (ENO). Vinculación con CIE 10. Despliegue de formulario especifico. Notificación automática por correo u otro procedimiento a la persona u oficina encargada. | 87 | | Alertas para enfermedades incorporadas en el programa de Vigilancia Epidemiológica. Vinculación con CIE 10. Despliegue de formulario especifico. Notificación automática por correo u otro procedimiento a la persona u oficina encargada. | 88 | | Alertas para señalar la disponibilidad en el sistema de Guías Clínicas o protocolos. Vinculación con CIE 10. | 89 | | Operación y Gestión de Firma Electrónica simple. La aplicación debe proveerse en condiciones que permitan su utilización asociada a TODOS los registros clínicos que sean ingresados. Capacidad de autenticación de registros existentes. | 90 | | Capacidad para gestionar firma electrónica avanzada | 91 | | Cargo en cuenta de paciente, de Visitas medicas efectuadas a pacientes hospitalizados. Cada vez que un profesional ingrese información en primeras visitas (anamnesis, etc.) o en visitas sucesivas (evolución) en la FCE, el sistema debe considerar que se ha efectuado una “visita a paciente hospitalizado”, cargando automáticamente en la cuenta corriente del paciente la prestación indicada. Esta prestación debe ser acreditada en la cuenta del médico y del servicio clínico o unidad de negocio pertinente (proveedor interno) | 92 | | Al igual que en el punto precedente, deben registrarse y cargarse en cuenta del paciente las INTER CONSULTAS, VISITAS DE EVALUACIÓN pre anestésica, JUNTAS MÉDICAS, con indicación de los integrantes presentes. Evaluación y sesiones de Kinesioterapia. | 93 | | Posibilidad de categorizar el estado de salud del paciente, para información de familiares e indicar si un paciente hospitalizado tiene autorización para recibir visitas. Indicar posible alta a 24 - 48 horas. Integración con Admisión o módulo de gestión de camas, oficina de atención al paciente. | 94 | | Posibilidad de invocar otra FCE. Situaciones en que el paciente es un recién nacido y se requiere información respecto del parto registrado en la FCE materna. | 95 | | En paciente ambulatorio el médico podrá asignar personalmente un cupo para control, accediendo a sus cupos futuros (destinados a pacientes en control) del módulo de agenda. El médico podrá invocar su agenda y asignar con un simple clic un cupo destinado a controles. El módulo de agenda capturará el nombre del paciente desde cuya ficha se hace la gestión. | 96 | | En pacientes ambulatorios el médico podrá marcar en un campo si para el siguiente control requiere o no de la ficha de papel. | 97 | | Herramienta que permita configurar la interfaz de usuario dependiendo de la especialidad y subespecialidad, vinculados con perfiles, roles y privilegios. | 98 | | Generación de formularios foliados de consentimiento informado, el que será impreso FOLIADO, con numeración única. Los formularios impresos y firmados serán escaneados en la FCE y el documento físico archivados en la Ficha de papel o en un Archivo especial, por correlativo de folio. | 99 | | Acceso a nomenclatura y terminología médica. Debe proveerse las tablas SNOMED. |

6.19.22 MÓDULO DE ATENCIÓN DE ENFERMERÍA Este módulo está destinado a apoyar fuertemente las actividades de enfermería, a fin de optimizar su gestión, facilitar su labor y reducir el volumen de trabajo administrativo, liberando tiempo que pueda ser dedicado a incrementar el nivel de calidad de servicio en la atención y cuidado del paciente. Cada estación de enfermería debe recibir las indicaciones médicas correspondiente a los pacientes que tiene a su cargo en forma automática, y facilitar el llenado de formularios. Debe privilegiarse el uso de formularios de selección de alternativas múltiples y de combo boxes, llevando al mínimo posible el uso de campos de texto libre. La FCE debe permitir a la enfermera gestionar con seguridad el tratamiento y cuidado de sus pacientes. Para la administración de medicamentos a los pacientes se solicita que se realice utilizando códigos de barra, marcando la identificación del paciente y luego la del medicamento, a fin de verificar la vigencia de la indicación y que el medicamento es el que corresponde y no se encuentra dentro del periodo de vigencia (no se encuentra caducado). Finalmente al autorizarse la acción, se identifica igualmente con código de barras el funcionario que administra el medicamento, con lo cual esta acción queda registrada como efectuada a la hora correspondiente. Debe tenerse presente que las/los auxiliares paramédicos también tendrán acceso a ésta vista, a fin de recoger la información de las tareas pendientes en su plan de trabajo y registrar las actividades para las cuales se encuentre autorizada, de acuerdo con la definición de roles, privilegios y reglas.

Nro | Concepto | Funcionalidad | 1 | | Definición de camas asignadas a cada estación de enfermería, para generar su mapa de camas. Vinculación con admisión (administración de camas). | 2 | Ingreso | Realización del ingreso de Enfermería del paciente. Deseable utilización de NANDA, NIC, NOC. | 3 | | Registro de Evolución de Enfermería | 4 | | Registro de signos vitales. Visualización gráfica. Debe permitir cambiar la escala a voluntad a fin de desplegar un día, una semana, un mes. | 5 | | La grafica de signos vitales debe poder ser configurable para cada estación de enfermería, definiendo cuales son los parámetros que registrará. Parametrización de opciones a registrar. | 6 | Cuidados de enfermería | Registro de acciones de confort. | 7 | | Evaluación y gestión de riesgo de caídas y eventos adversos. Formulario de consentimiento de inmovilización otorgado por familiares, el que debe ser impreso y firmado por los familiares, de modo similar al proceso del consentimiento informado. | 8 | | Registro de caídas y /o eventos adversos que el administrador configure en el sistema | 9 | | Posibilidad de notificación de eventos adversos por mail u otro mecanismo a la enfermera jefe o la persona responsable de calidad u otra que se defina. | 10 | | Prevención y Control de ulceras por presión (escaras). Capacidad de marcar áreas especificas en un diagrama, señalando el lugar de las lesiones. | 11 | | Acceso al protocolo de prevención de escaras y formularios pertinentes. Adicionalmente debe enviar automáticamente la notificación pertinente al comité de escaras. | 12 | | Prevención Enfermedad Trombo Embólica. Uso del protocolo pertinente | 13 | | Balance hídrico. Calculo automático a medida que se ingresan los datos. Cierre del cálculo a una hora diaria predefinida. Integración con administración de sueros, hemoderivados, otros fluidos. | 14 | | Registro de acciones de enfermería. Ej.: Curaciones, tratamientos específicos. | 15 | Medicación | Programación horaria automática de la medicación diaria prescrita a los pacientes en la estación de enfermería correspondiente al sector. Información de toda la unidad y por paciente, con indicación de nombre paciente, numero de cama, medicamento, dosis, vía de administración. Generación automática de lista de trabajo y actividades a partir de las indicaciones médicas y reglas que se defina. | 16 | | Capacidad para operar con lectores de código de barras para automatizar validación y registro de medicación. Comprobación de terapia vigente y registro automático de hora y funcionario que administra la medicación. (Triada medicamento- paciente – funcionario). Uso de códigos EAN-128 y Data Matrix, para identificación de pacientes, funcionarios, profesionales, fármacos unidosis y frascos de laboratorio para toma de muestras. | 17 | | En el caso precedente, el sistema tiene que hacer un matching entre el paciente y la medicación, verificando la vigencia de la indicación. También valida que el medicamento no ha excedido su fecha de caducidad. El registro del funcionario (tercera lectura de código de barra), permite continuar con la siguiente medicación en el mismo paciente o en otro. El sistema permitirá validar o registrar al profesional que ejecuta la toma de muestras al final de varias muestras. No requiere identificarse en cada muestra de una sesión de toma de muestras. | 18 | | En caso de discrepancia o no validación en la secuencia de registro de código de barras para la administración de un fármaco, la acción podrá ser abortada, quedando registrada esta situación y la razón. La medicación NO aparecerá como efectuada. | 19 | | Cuando la medicación indicada tiene carácter de inmediata y es administrada al paciente ANTES que el producto sea despachado de farmacia, se asume que se utilizó productos del botiquín o bodega local de la estación de enfermería. En este caso, el sistema valida el producto contra la indicación, de la manera normal. En la receta debe indicar que el producto en vez de colocarse en la caja con la identificación del paciente en la gaveta de fármacos, debe depositarlos en la caja botiquín o Bodega local, del mismo gavetero. Al ser recibido, la enfermera deposita el producto en la bodega o botiquín, recuperando su stock. | 20 | | Registro automático de la medicación suministrada | 21 | | Programación automática de actividades diarias (por hora), a partir de las indicaciones médicas y reglas que se defina. | 22 | | Capacidad para el ingreso de actividades adicionales, en forma manual. | 23 | | Herramienta para el cálculo de la velocidad de goteo en sueros y hemoderivados. | 24 | Exámenes | El sistema advertirá de los exámenes que hayan sido solicitados por el Médico tratante | 25 | | De acuerdo con los protocolos de laboratorio se advertirá de las condiciones exigidas a las muestras y/o tipo de frasco/tubo a utilizar. Integración con LIS. | 26 | | Capacidad para visualización de información del Vademécum de productos farmacológicos. Acceso informativo (sólo lectura) al módulo sistema de farmacia. | 27 | | Toma de muestras. Impresión de etiquetas para frascos o tubos, con inclusión de código de barras | 28 | | Verificación de toma de muestras a efectuarse con triple lectura de código de barras, de modo similar a la medicación. El sistema permitirá validar o registrar al profesional que ejecuta la toma de muestras al final de varias muestras. No requiere identificarse en cada muestra de una sesión de toma de muestras. | 29 | | Seguimiento de exámenes y procedimientos solicitados. Integración con RIS, LIS, y servicios de apoyo diagnostico. | 30 | Otras funcionalidades | Control de actividades pendientes. Configuración de Alertas de actividades no realizadas según lo programado. | 31 | | Anulación de órdenes y recetas pendientes al producirse un alta. Vinculación con Farmacia, Laboratorio, Imagenología. | 32 | | En caso de traslado del paciente a otra sala de hospitalización del hospital, la vista de las actividades de enfermería indicadas y programadas deben trasladarse a la estación de enfermería que corresponda a la nueva ubicación del paciente. Vinculación con ADT. | 33 | | En caso de traslado transitorio del paciente, por ejemplo a pabellón, Imagenología, procedimiento fuera del hospital esta ubicación debe reflejarse en el sistema ADT | 34 | | Vista del stock de insumos y fármacos en botiquín. Integración con bodega (periférica) de Farmacia. (ERP) | 35 | | Posibilidad de hacer devolución a farmacia de productos no utilizados por el paciente. Integración con Farmacia (reingreso de producto + nota de crédito en la cuenta del paciente). | 36 | | Impresión de carné de alta e indicaciones. Captura diagnostico, tratamiento indicado, fecha de control y otros datos que se defina. | 37 | | Capacidad de impresión de documentos de alta que se debe entregar al paciente. | 38 | | Censo y estado de Camas (bloqueada, en mantención, en aseo). Integración con módulo de gestión de camas (ADT) | 39 | | Capacidad de generación de un resumen configurable de actividades efectuadas y actividades pendientes, para los efectos de los cambios de turno. Este resumen debe quedar guardado en alguna parte | 40 | | Capacidad de generar hoja de Residencia de Enfermería. Este documento debe quedar guardado en alguna parte | 41 | | Visualización de FCE (vista del médico en condición Sólo Lectura) | 42 | | Posibilidad de vincular protocolos de atención o Guías de Enfermería | 43 | | Capacidad de generar nuevos Formularios | 44 | | Capacidad de generar reportes de gestión de enfermería. | 45 | | Capacidad para operar vía WiFi | 46 | | Capacidad para utilizar lectores de código de barra inalámbricos. | 47 | | Capacidad de incorporar diagramas específicos por especialidad, para que la enfermera pueda dibujar marcas en determinada región anatómica (Ej. Descripción de ulceras por presión. | 48 | | Capacidad para incorporar FOTOS DIGITALES por puerto USB, en el momento de la atención del paciente. Ej.: lesiones cutáneas, vías instaladas. | 49 | | Programa para registro, control y mantención de vías y sondas. Alarmas de fechas de recambio publicables en pantalla de actividades de enfermería. Información a IIH. | 50 | | Indispensable incluir campos de datos que alimenten indicadores de calidad. Al momento de reingeniería de procesos, considerar requerimientos de la Unidad de Calidad del Hospital. | 51 | | Incluir pautas de supervisión de calidad e IIH. | 52 | | Uso de firma electrónica simple para registros de enfermería |

6.19.23 MÓDULO DE NUTRICIÓN La/el nutricionista debe visualizar la indicación dietética efectuada por el médico a fin de adecuar el menú a los requerimientos y a las condiciones y preferencias del paciente. Para el caso de pacientes que se encuentran hospitalizados, y dado que en la actualidad no existe un módulo de cocina, la salida será un listado impreso agrupado por los sectores de distribución y carros de distribución que corresponda.

Nro. | Funcionalidad | 1 | Visualización de la indicación médica para cada paciente en particular. Integración con módulo clínico. | 2 | Generar menús y raciones con su correspondiente valor nutricional. | 3 | Selección de menú para pacientes hospitalizados. | 4 | Valor nutricional del menú seleccionado. | 5 | Registro de Exclusiones y preferencias alimentarias del paciente. | 6 | Alarma de alergias alimentarias. Vinculación con herramienta de alergias. | 7 | Listado de menú por paciente y por sector de distribución de alimentos (carros). | 8 | Registro de alimento efectivamente consumido por el paciente | 9 | Capacidad de generar reportes de actividades realizadas y de ingredientes implícitos en las dietas que fueron asignadas a los pacientes. | 10 | Alimentación enteral. Es provista por farmacia. | 11 | Alimentación para enteral. Es provista por farmacia. | 12 | Calculo de insumos para preparación de raciones por tipo de menú. Vinculación con bodega (economato) | 13 | Generación de dietas para pacientes ambulatorios. | 14 | Las indicaciones nutricionales y sugerencias de menú, podrán ser impresas en los KIOSCOS |

6.19.24 MÓDULO DE FORMULARIOS Y CERTIFICADOS Este es un módulo que administra todos los formularios tales como recetario, solicitud de pabellón quirúrgico, exámenes y procedimientos diagnósticos y terapéuticos. Debe permitir que cada usuario pueda formar un subgrupo de los elementos que utiliza con mayor frecuencia. Para aquellas funcionalidades que involucran procesos que no están disponibles para ser integrados, deberá considerarse la posibilidad de generar un formato que debe ser impreso. (Ej. Notificaciones, certificados, situaciones Médico legales, recetas para ser despachadas en farmacias privadas, exámenes para ser efectuados fuera de la Red de Salud de DISALCAR).

Este módulo deberá proveer una herramienta que permita la confección por parte del administrador del sistema, de los formularios que se estime conveniente. Estos formularios deben poder contener campos activos de auto llenado, cajas de opciones múltiples, campos activos tipo listado de chequeo, y espacio para incorporar texto libre. Nro | Concepto | Funcionalidad | 1 | Recetario. | El recetario debe informar de la no existencia de un producto requerido. Debe ofrecer dosificación y modo de uso por defecto. Aplica la inteligencia del Módulo de farmacia. Capacidad de impresión de recetas. Integración con módulo de farmacología. | 2 | | Formato especial de receta para drogas controladas y estupefacientes. | 3 | Solicitudes: | Toda solicitud debe ser foliada con número único. | 4 | | Transfusión o Hemoderivados. Integración con Banco de Sangre. | 5 | | Exámenes de Laboratorio. Integración con Laboratorio. | 6 | | Exámenes de Imagenología. Integración con RIS y PACS. | 7 | | Pabellón Quirúrgico. Integración con módulo de Pabellones. | 8 | | Kinesioterapia. Módulo pertinente de Servicios de apoyo clínico. Trazabilidad del proceso | 9 | | Solicitud de otros exámenes de diagnóstico. Módulo pertinente de Servicios de apoyo clínico. Trazabilidad del proceso | 10 | | Solicitud de procedimientos diagnósticos. Módulo pertinente de Servicios de apoyo clínico. Trazabilidad del proceso. | 11 | | Interconsultas a especialistas. Módulo pertinente de Servicios de apoyo clínico. Trazabilidad del proceso | 12 | | Traslado de paciente. Integración con Admisión y con movilización | 13 | Certificados. | Todo Certificado debe ser foliado, con numero único | 14 | | De parto. Registro en "libro de partos". Hay que crear el Libro de Registro de Partos, con el formato requerido. | 15 | | Licencia medica. Integración con sistema de licencias de Carabineros. Integración con sistema de licencias medicas de la Superintendencia de Salud, cuando esté disponible este servicio. | 16 | | Fallecimiento. | 17 | | Comprobante de atención. | 18 | Notificaciones. | Toda Notificación debe ser foliada, con numero único | 19 | | Las notificaciones DEBEN aparecer en la pantalla del encargado y ser impresas. | 20 | | Debe generarse un reporte con las notificaciones ocurridas. | 21 | | Toda Notificación debe poder ser impresa. | 22 | | De enfermedad de Notificación obligatoria (ENO). Debe permitir el uso de campos de selección múltiple. Vinculación con CIE 10. | 23 | | Notificación de mordedura de animales. Vinculación con CIE 10 | 24 | | De patología AUGE. Debe permitir el uso de campos de selección múltiple. | 25 | | Enfermedades bajo supervigilancia epidemiológica. Debe permitir el uso de campos de selección múltiple | 26 | | Accidentes de tránsito. Debe permitir el uso de campos de selección múltiple. | 27 | | Accidentes laborales de Carabineros activos. (En acto de Servicio). Debe permitir el uso de campos de selección múltiple. | 28 | | Accidentes laborales de empleados de DISALCAR afectos a una Mutual de Seguridad. | 29 | | Situaciones médico legales. Debe permitir el uso de campos de selección múltiple | 30 | | Lesiones, agresiones, violencia intrafamiliar. | 31 | Formularios | Todo formulario DEBE SER FOLIADO con número ÚNICO. | 32 | | De consentimiento informado. | 33 | | De consentimiento de contención de paciente. | 34 | | De traslado de cuerpos al Instituto Médico Legal. | 35 | | Hoja de anestesia (con capacidad de generar gráficos). Balance Hídrico. Anotación grafica de signos vitales, suministro de fluidos y medicamentos, incidentes, etc. | 36 | | Hoja de parto "PARTOGRAMA". (Con capacidad de generar gráficos). Balance Hídrico. Anotación gráfica de dilatación cervical, frecuencia de contracciones, frecuencia cardiaca fetal, plano de Hodge. |

6.19.25 GESTIÓN DE ATENCIÓN DE URGENCIA: En la atención de urgencia los principales factores críticos son: la categorización de niveles de urgencia para priorizar la atención, los tiempos de espera y la optimización en la aplicación de los recursos disponibles.
Este módulo tiene por objeto colaborar al logro de esos objetivos, al posibilitar el seguimiento del paciente a través de todo el proceso de atención y generar informes de gestión.

Nro | Funcionalidad | 1 | Ingreso del paciente a Urgencia | 2 | Captura de datos Demográficos. Integración con archivo maestro de pacientes. | 3 | Discriminación de paciente beneficiario, particular, convenio, urgencia vital, NN. | 4 | Triage. Categorización de urgencia, según criterios predefinidos. Clave de colores para identificación. | 5 | Discriminación de urgencia pediátrica , de adultos, gineco obstetricia, dental | 6 | Discriminación de accidente común, laboral, escolar, violencia callejera, violencia intrafamiliar. Presentación del formulario correspondiente, el que se direccionará automáticamente a quien corresponda. | 7 | Tiempo de espera de pacientes. El tiempo se contabiliza desde el ingreso del paciente en Admisión. | 8 | Visualización de los tiempos de espera, en el listado de trabajo (worklist) con señalización mediante indicador de colores tipo semáforo u otro del tiempo transcurrido, según criterios predefinidos. Ejemplo Verde: espera normal, Amarillo: espera prolongada, Rojo: espera excesiva. | 9 | Mapeo/Censo de camas, Boxes y camillas, con indicación NIVEL DE Triage, y de la fase del proceso en que se encuentra el paciente (Ej. En espera de ser atendido, en observación, en hidratación, en espera de exámenes, en espera de traslado. Integración con Admisión, laboratorio clínico, Imagenología. | 10 | | 11 | Registro de accidentes de transito, laboral, escolar, evento Médico legal. Despliegue de formularios y notificaciones especificas para cada caso. | 12 | Alcoholemia. Debe llevarse un registro correlativo de alcoholemias. Las muestras de sangre para alcoholemia, en Chile son procedas en el Instituto Médico Legal y no en el laboratorio del Hospital. Ajustarse a normas vigentes. Llenado automático de formularios destinados al "SERVICIO MÉDICO LEGAL", de acuerdo con SUS normas. | 13 | Mordedura de perros y otros animales. Debe generarse los formularios correspondientes, y notificarse de acuerdo a normas vigentes. Despliegue de formulario de notificación. | 14 | Vinculación con cuenta del paciente | 15 | Vinculación con módulo clínico. | 16 | Vinculación con Módulo de Enfermería | 17 | Vinculación con módulo de recetario, solicitudes, formularios y certificados (Ej. Solicitudes de exámenes, traslado y solicitud de pabellones quirúrgicos). Integración con Admisión, Farmacia, RIS, LIS, Pabellones Quirúrgicos (perfil de usuario). | 18 | Generación de reportes de gestión | 19 | Ej. Informes de producción, tiempos de espera, índice ocupacional, tiempos de permanencia y destino de los pacientes al alta desde urgencia. |

6.19.26 GESTIÓN DE ATENCIÓN DE CAMAS CRÍTICAS: * Este módulo en esencia provee una interfaz gráfica con el mapa de camas de la unidad crítica, con algunos datos relevantes, que permita que al seleccionar una de estas camas, se ingrese de inmediato a la FCE del paciente. Asimismo debe permitir la captura de registros de los equipos de monitoreo y el control de bombas de infusión.

Nro | Funcionalidad | 1 | Capacidad de conectividad con equipos clínicos de monitoreo, EKG, EEG y bombas de infusión. Dependiendo de la tecnología de los equipos, debería poder capturarse las imágenes estáticas o dinámicas de estos equipos en demanda, o en forma automática al ocurrir una alarma. | 2 | Funcionalidades especiales del módulo de enfermería. Dado que el registro de datos y actividades es más frecuente que en pacientes comunes, debe poder ajustarse las matrices de signos vitales y actividades para capturar información en periodos de tiempo variables (Ej. Cada 10, 15, 30 minutos). | 3 | El Módulo clínico, requiere adecuaciones en la interfase de usuario, a fin de destacar resultados de laboratorio, balance hídrico y signos vitales. | 4 | Disponer forma para visualizar los registros de monitoreo que se encuentren ingresados a la FCE. | 5 | Generación de reportes. Vinculación con el módulo de generación de reportes. | 6 | Visualización gráfica de las camas criticas, con la identificación del paciente, que permita ingresar a la FCE al seleccionar la cama pertinente en el gráfico. |

6.19.27 MÓDULO DE GESTIÓN DE PABELLONES QUIRÚRGICOS. (quirófanos) Este Módulo está destinado a facilitar la programación y operación de los Pabellones Quirúrgicos, a fin automatizar los procesos y mejorar su productividad. Asimismo mejora el nivel de seguridad en la atención del paciente, al hacer exigible los exámenes preoperatorios, la existencia del consentimiento informado y el registro de la información establecida en los procesos y protocolos. Los pabellones de acuerdo con su equipamiento, amplitud y condición, pueden ser destinados a determinados tipos de cirugías.

Nro | Funcionalidad | 1 | Destinación de quirófanos o pabellones para determinados tipos de cirugía, en consideración del equipamiento de que disponen. | 2 | Gestión de solicitudes de Quirófano. Integración con FCE (Módulo de solicitudes). | 3 | Gestión de solicitudes de pabellón en lista de espera. | 4 | Validación de paquetes predefinidos de exámenes preoperatorios y de la evaluación pre anestésica. Integración con módulo Clínico. | 5 | Validación del Consentimiento Informado | 6 | Agendamiento de Quirófanos. Generar alerta en el Módulo de enfermería en que se encuentra el paciente, con indicaciones pre operatorias. | 7 | Generar registro del agendamiento de pabellón en el módulo Clínico. | 8 | Capacidad para reprogramar quirófanos en casos de presentarse casos de urgencias. | 9 | Publicación de Tabla Quirúrgica. En página WEB de la Intranet. En pantallas gigantes en pabellón. | 10 | Registro de suspensión de cirugía, hora, responsable de la decisión y causa. | 11 | Censo de quirófanos, indicando su status (Ej. disponible, ocupado, en desinfección, bloqueado, en mantención). Display Grafico que se vea en la tabla quirúrgica. | 12 | Requerimiento de equipos adicionales que deban incorporarse al quirófano para determinada cirugía programada. | 13 | Este equipo adicional programado, debe aparecer publicado en la tabla quirúrgica. | 14 | Solicitud de cajas quirúrgicas. Integración con esterilización. Solicitud de instrumental estéril se activa al validar el agendamiento. | 15 | Solicitud de paquetes de ropa estéril (no desechable). Integración con esterilización. Solicitud se activa al validar el agendamiento. | 16 | Gestión de fármacos e insumos desechables. Integración con Farmacia y Bodega de insumos, para reposición de stocks. | 17 | Integración con cuenta corriente del paciente para incorporar los cargos de derechos de pabellón, honorarios profesionales, medicamentos e insumos | 18 | Registro del equipo de médicos y del personal de apoyo (cirujano, anestesiólogo, ayudantes, etc.) | 19 | Formulario de Hoja de Anestesia. Tipo de anestesia (selección múltiple). | 20 | Formulario de Hoja de Anestesia. Anotación de signos vitales, tiempo anestésico, tiempo quirúrgico, medicamentos aplicados, sueros, transfusiones, etc. Despliegue gráfico. | 21 | Formulario de Hoja de Anestesia. Idealmente uso de pantallas táctiles para el anestesiólogo | 22 | Capacidad para solicitar exámenes, hemoderivados, biopsia rápida, desde hoja de anestesia | 23 | Capacidad para envío de biopsias o piezas operatorias a Anatomía Patológica. Impresión de etiquetas con código de barras (en la modalidad requerida). | 24 | Registro de tiempos quirúrgicos tales como llegada del paciente, inicio de anestesia, inicio de cirugía, termino de cirugía, termino de anestesia, salida del paciente. La hora de llegada y salida del paciente a pabellón, se vincula con Módulo ADT para cambios de estado y trazabilidad del paciente. | 25 | Registro de hora de inicio y termino del aseo. Registro de situaciones especiales detectadas | 26 | Capacidad para capturar datos desde equipos de monitoreo. | 27 | Registro de fármacos, insumos, hemoderivados, prótesis, órtesis consumidos. Vinculación con cuenta de paciente. Si el paciente esta adscrito a una cirugía paquetizada PAD, el material en exceso se registra sin precio y éste se carga a otra cuenta que se definirá. | 28 | Visualización de la FCE. | 29 | Dictado de protocolos quirúrgicos utilizando archivos digitales de audio (WAV u otro). Aparecerá el protocolo quirúrgico en la FCE cuando se encuentre trascrito y validado por el cirujano. En caso contrario aparecerá como “PENDIENTE”. | 30 | En el protocolo debe registrarse las prestaciones efectuadas para fines de cobro. Estas prestaciones se seleccionarán desde el archivo de prestaciones. Deben poder agregarse tantas prestaciones como resulte necesario. | 31 | Funcionalidad para la trascripción de archivos digitales de audio (WAV.). La transcripcionista debe enviar su trabajo a revisión por parte del cirujano. | 32 | Validación de trascripción de protocolos quirúrgicos. El cirujano revisa y valida el texto, el que es firmado en forma digital. | 33 | Las indicaciones y terapias post quirúrgicas se anotaran en la FCE. Si el paciente es enviado a sala de recuperación, estas indicaciones quedaran registradas en la lista de trabajo de la estación de enfermería de recuperación. Si es enviado a sala de camas criticas o la habitación del paciente, se procederá de igual manera. | 34 | Clasificación de las cirugías según su potencial contaminante. Opciones predefinidas parametrizables. | 35 | Registro y notificación de cirugías sépticas o potencialmente sépticas. Mensaje al Comité de Infecciones intra hospitalarias. Envío de e mail automático en caso de no existir módulo especifico integrado. (Vinculación al Módulo de IIH). | 36 | Gestión de biopsias, muestras biológicas, y exámenes de laboratorio. Integración con módulo de solicitudes. Vinculación con Anatomía patológica y laboratorio clínico. | 37 | Capacidad de Etiquetado de muestras. | 38 | El ingreso y la salida del paciente de pabellón, se reflejará en el sistema ADT, el que debe indicar la nueva ubicación del paciente. Trazabilidad del paciente | 39 | Registro de nacimientos y emisión de certificados de parto. Vinculación con Admisión y módulo de formularios. | 40 | El registro de nacimiento único o múltiple, genera automáticamente un registro en el archivo maestro de pacientes, con una identidad transitoria asociada a la identidad de la madre. Esta acción debe generar la Ficha Clínica del Recién nacido. Integración con Archivo Maestro de Pacientes. Cuando el recién nacido tenga identidad propia, debe ingresarse al maestro de pacientes, acción que reemplazara la identidad transitoria en TODOS los documentos y registros que se haya generado. | 41 | Emisión de certificado de defunción. | 42 | Emisión de los reportes predefinidos de gestión. Vinculación con módulo de Generación de Reportes de Gestión. | 43 | Lista de chequeo que asegure que el quirófano se encuentra en condiciones de ingresar el paciente programado, por encontrarse presentes todos los elementos y condiciones necesarias (Ej. instrumental, ropa, insumos previstos). Check list completo cambia de estado el quirófano de "en aseo", "en preparación" a "habilitado" en la tabla quirúrgica. |

6.19.28 MÓDULO DE GESTIÓN DE ESTERILIZACIÓN Este módulo está destinado a gestionar el inventario de material estéril, asegurar su control de calidad y trazabilidad. Se encarga del control de los materiales esterilizados y de hacer el seguimiento de los mismos tanto para su uso en las intervenciones quirúrgicas como en los procedimientos de enfermería realizados en salas de hospitalización o en lugares de atención ambulatoria. Nro | Funcionalidad | 1 | Inventario de instrumental. Uso de códigos EAN-128 y Data Matrix, aplicable al instrumental que este marcado. | 2 | Generación de cajas quirúrgicas a partir del inventario. Uso de códigos EAN-128 y Data Matrix. | 3 | Inventario de ropa. Integración con ropería o lavandería, si es posible. Probablemente se trate como bodega del ERP. | 4 | Generación de paquetes de ropa a partir del inventario. | 5 | Etiquetado de paquetes y cajas, con indicación de fecha y lote de esterilización. Generación e impresión de etiquetas con código de barras. | 6 | Capacidad para lectura de código de barras grabados en instrumental quirúrgico. | 7 | Incluir listado de clientes internos y externos Ej. Pabellón Nº 1, Otro establecimiento de salud, Sala Pensionado 2. Selección automática de destino a partir de la solicitud de material. | 8 | Gestión de solicitudes de cajas, paquetes y material estéril. Integración con módulo de Pabellones y enfermería. | 9 | Gestión manual de solicitudes esporádicas de material estéril de servicios no habituales. Ej. Imagenología, Endoscopia, otros. | 10 | Gestión de bodega de material estéril, con sus fechas de vigencia. Alertas en las fechas de vencimiento. | 11 | Gestión del proceso de esterilización, con monitoreo de cargas y validadores (OK) | 12 | Despacho de material estéril. Vinculación de fecha de esterilización y carga de esterilización, con usuario (paciente). Movimiento de inventario. | 13 | Trazabilidad de instrumental estéril. Se debe poder seguir un material estéril, desde su esterilización (registro del paciente usuario) hasta su regreso a esterilización o fecha de caducidad si no ha sido utilizado. | 14 | Trazabilidad del material estéril. Se debe poder seguir un material estéril, desde su esterilización hasta el usuario final (paciente) o fecha de caducidad | 15 | Capacidad para identificar el destino o uso que se dio a un determinado lote de esterilización. Ej.: Situación de IIH. | 16 | Recepción de material sucio. Movimiento de inventario. | 17 | Generación de reportes. Vinculación con Módulo de reportes. | 18 | Listado de material estéril por vencer. |

6.19.29 MÓDULO DE FARMACOLOGÍA Este módulo está destinado a generar la “inteligencia” al recetario, proporcionando al médico ayuda farmacológica en diversos aspectos, tales como: dosis sugerida para adultos, niños y lactantes, información de efectos adversos, sinergias y antagonismos entre productos que se intenta suministrar al paciente. Asimismo impedirá que se recete un producto al cual el paciente es alérgico.

El mantenedor de esta ayuda farmacológica, la mantención del catálogo de productos farmacológicos, productos alternativos, nombres comerciales y genéricos de los productos, estará a cargo de los profesionales Químico Farmacéuticos, al igual que la generación de productos magistrales. Las recetas deben estar integradas con las máquinas dispensadoras Grifols y Unicel existentes, a fin de producir una dispensación automatizada.

Nro | Funcionalidad | 1 | Capacidad para ingresar productos magistrales generados a partir de otros productos en existencia. El producto magistral debe estar registrado en el catálogo y en el Módulo de arancel. | 2 | Posibilidad de vincular uso de medicamentos con patologías AUGE u otras según protocolos. | 3 | Información farmacológica, dosis máximas, dosis útil, interacciones con otros fármacos, sustitutos y riesgos de reacción alérgica. Integración con el módulo clínico. | 4 | Activación de alertas predefinidas. | 5 | Al momento de ser prescrito un producto en el recetario, el sistema debe ofrecer la dosis sugerida, vía de aplicación y frecuencia de uso (horario de administración), información que podrá ser modificado por el médico). Debe discriminar dosificación en caso de paciente adulto, pediátrico y neonato. | 6 | Alertas de alergias. Vinculación con Módulo clínico y de enfermería. | 7 | Alertas de contraindicación o interacción con otros fármacos en uso actual o pasado por parte del paciente. | 8 | Mantenedor de información farmacológica. | 9 | Vinculación con admisión para habilitación de cuenta de paciente para cargos y notas de crédito. |

6.19.30 MÓDULO DE SERVICIOS DE APOYO Este módulo está destinado a proveer soporte al flujo de los procesos de servicios de apoyo diagnostico y terapéutico, en las fases de agendamiento, recepción del paciente, realización del examen, el dictado, trascripción y validación de los informes y la entrega de estos. * Nro | Funcionalidad | 1 | Este módulo debe gestionar el Flujo de Trabajo de cada uno de los servicios de apoyo clínico que generan PROCEDIMIENTOS DIAGNÓSTICOS o TERAPÉUTICOS, y permitir el dictado de informes y captura de las imágenes que generan los equipos (Ej. Endoscopía, Microscopía, campimetría) y permitir su visualización por parte de los médicos clínicos. La unidad clínica que realiza servicios de apoyo clínico puede ser parte de un servicio clínico mayor. En este caso debe poder diferenciarse la función de apoyo que utilizará este módulo, del servicio clínico madre, el que utilizará la FCE normal. | 2 | Debe permitir que se incorpore documentos escaneados (solicitud u orden de trabajo generados en forma manual fuera de la FCE) que queden vinculados con la actividad a realizar. Debe poderse ver esta orden al momento de realizar el procedimiento y al generar el informe. Ej. Endoscopia Digestiva puede ser parte de gastroenterología. Ambas se diferenciarán como unidad de negocio y asociarán en el plan de cuentes del ERP, para efectos de consolidación. | 3 | Recepción de solicitudes electrónicas desde la FCE y capacidad para asignar cupos en la agenda especifica del Servicio de Apoyo. | 4 | Generar listas de trabajo para cada servicio o unidad, vinculadas con el módulo de agendamiento. | 5 | El paciente ya citado, se presenta en recepción para ser atendido. Se le ubica y marca en la agenda, cambiando el estado a "paciente llegado". | 6 | La condición de paciente llegado, gatilla el paso del nombre del paciente a la Lista de Trabajo de la secretaria o enfermería del sector correspondiente y la aparición en la Lista de Trabajo del profesional que lo atenderá. Se inicia un contador de "tiempo en espera de ser atendido". También se indicara el tiempo de espera desde la hora de citación, por lo que el tiempo puede ser positivo o negativo. (Ej. Paciente llega mucho antes que la hora de citación). | 7 | Al seleccionar un paciente, éste debe ser identificado en forma biométrica, para habilitar la apertura de la FCE | 8 | Al abrir la FCE del paciente el estado pasa de espera, al de "atención". El cierre de la FCE indica el término de la atención. Los cambios de estado y de paciente se reflejan en el Mapa grafico de Boxes (Salas de procedimiento Diagnostico o Terapéutico). | 9 | A cada cambio de estado, el sistema debe capturar la hora del sistema. Hay acciones del proceso que gatillarán los cambios de estado para trazabilidad de la solicitud. Parametrizar los estados posibles en este tipo de atención. | 10 | Los cambios de estado deben ser visibles en las listas de trabajo del profesional, secretaría y/o enfermería, para trazabilidad. | 11 | Capturar y archivar imágenes, integrando los equipos clínicos pertinentes. Dependiendo de la configuración y arquitectura, estas imágenes podrán estar en formato JPEG u otras. | 12 | Capacidad para dictar y transcribir y validar o revisar informes, utilizando archivos digitales en formato WAV o similar. Debe utilizar micrófono con puerta USB para el dictado. Pedalera USB y audífonos para secretaria transcripcionista. | 13 | Al informar debe permitir el uso de esquemas predefinidos modificables por el usuario (Ej. Esquemas normales). | 14 | El profesional deberá podrá revisar y validar una transcripción realizada, la que una vez validada, quedará disponible para ser integrada y vista en la Ficha Clínica y/o ser impresa. | 15 | Firma digital para los informes. | 16 | Capacidad para generar formatos de informe (lay out) específicos para cada servicio de apoyo. | 17 | Las imágenes capturadas deben quedar vinculadas con el informe correspondiente. | 18 | La imágenes y los informes deben poderse visualizar desde la Ficha Clínica. Incluir visualizador de imágenes en concordancia con los formatos de imágenes utilizados. | 19 | Generación de informes estadísticos y de gestión por cada servicio de apoyo. |

6.19.31 MÓDULO DE ATENCIÓN EN POLICLÍNICO Está destinado a registrar la recepción del paciente que tiene una hora de atención ya agendada en las unidades de policlínico, atención primaria y centros de salud familiar, y a generar la lista de trabajo del profesional que lo atenderá, con indicación del tiempo de espera acumulado desde el momento de su arribo .
Al seleccionar un paciente de la lista de trabajo se abrirá la FCE previa comprobación de la identificación biométrica del paciente. Nro | Funcionalidad | 1 | Este módulo debe gestionar el Flujo de Trabajo de cada uno de los servicios de apoyo clínico que generan PROCEDIMIENTOS DIAGNÓSTICOS o TERAPÉUTICOS, y permitir el dictado de informes y captura de las imágenes que generan los equipos (Ej. Endoscopía, Microscopía, campimetría) y permitir su visualización por parte de los médicos clínicos. La unidad clínica que realiza servicios de apoyo clínico puede ser parte de un servicio clínico mayor. En este caso debe poder diferenciarse la función de apoyo que utilizará este módulo, del servicio clínico madre, el que utilizará la FCE normal. | 2 | Debe permitir que se incorpore documentos escaneados (solicitud u orden de trabajo generados en forma manual fuera de la FCE) que queden vinculados con la actividad a realizar. Debe poderse ver esta orden al momento de realizar el procedimiento y al generar el informe. Ej. Endoscopia Digestiva puede ser parte de gastroenterología. Ambas se diferenciarán como unidad de negocio y asociarán en el plan de cuentes del ERP, para efectos de consolidación. | 3 | Recepción de solicitudes electrónicas desde la FCE | 4 | Generar listas de trabajo para cada servicio o unidad, vinculadas con el módulo de agendamiento. | 5 | El paciente ya citado, se presenta en recepción para ser atendido. Se le ubica y marca en la agenda, cambiando el estado a "paciente llegado". | 6 | La condición de paciente llegado, gatilla el paso del nombre del paciente a la Lista de Trabajo de la secretaria o enfermería del sector correspondiente y la aparición en la Lista de Trabajo del profesional que lo atenderá. Se inicia un contador de "tiempo en espera de ser atendido". También se indicara el tiempo de espera desde la hora de citación, por lo que el tiempo puede ser positivo o negativo. (Ej. Paciente llega mucho antes que la hora de citación). | 7 | Al seleccionar un paciente, éste debe ser identificado en forma biométrica, para habilitar la apertura de la FCE | 8 | Al abrir la FCE del paciente el estado pasa de espera, al de "atención". El cierre de la FCE indica el término de la atención. Los cambios de estado y de paciente se reflejan en el Mapa grafico de Boxes (Salas de procedimiento Diagnostico o Terapéutico). | 9 | A cada cambio de estado, el sistema debe capturar la hora del sistema. Hay acciones del proceso que gatillarán los cambios de estado para trazabilidad de la solicitud. Parametrizar los estados posibles en este tipo de atención. | 10 | Los cambios de estado deben ser visibles en las listas de trabajo del profesional, secretaría y/o enfermería, para trazabilidad. | 11 | Capturar y archivar imágenes, integrando los equipos clínicos pertinentes. Dependiendo de la configuración y arquitectura, estas imágenes podrán estar en formato JPEG u otras. | 12 | Capacidad para dictar y transcribir y validar o revisar informes, utilizando archivos digitales en formato WAV o similar. Debe utilizar micrófono con puerta USB para el dictado. Pedalera USB y audífonos para secretaria transcripcionista. | 13 | Al informar debe permitir el uso de esquemas predefinidos modificables por el usuario (Ej. Esquemas normales). | 14 | El profesional deberá podrá revisar y validar una transcripción realizada, la que una vez validada, quedará disponible para ser integrada y vista en la Ficha Clínica y/o ser impresa. | 15 | Firma digital para los informes. | 16 | Capacidad para generar formatos de informe (lay out) específicos para cada servicio de apoyo. | 17 | Las imágenes capturadas deben quedar vinculadas con el informe correspondiente. | 18 | La imágenes y los informes deben poderse visualizar desde la Ficha Clínica. Incluir visualizador de imágenes en concordancia con los formatos de imágenes utilizados. | 19 | Generación de informes estadísticos y de gestión por cada servicio de apoyo. |

6.19.32 mÓDULO DE ANATOMÍA PATOLÓGICA Este módulo está destinado a proveer soporte al flujo de los procesos del Servicios de Anatomía Patológica, incluyendo la recepción d muestras, su procesamiento y la emisión de los informes correspondientes.

Nro | Funcionalidad | 1 | Gestión del Flujo de trabajo dentro del servicio, a través de las diferentes secciones, incluyendo dictado de informes. | 2 | Catalogo de servicios y procesos de Anatomía Patológica. Incluye tinciones e inmuno histoquímica. | 3 | Capacidad para agrupar tinciones e inmuno histoquímica que debe aplicarse a determinados diagnósticos. | 4 | Registrar recepción de muestras de paciente con solicitudes generadas en la FCE. Asociar Nº de biopsia. | 5 | Registrar recepción de muestras de paciente externos. (Solicitudes no generadas en FCE). Escaneo de orden de examen en papel. | 6 | El registro de recepción de muestras incluye, un correlativo, órgano, cantidad de muestras, numero de inclusiones, numero de tinciones. Ubicación en bodega-archivo. | 7 | Numeración correlativa diferente para muestras, citología convencional y para Papanicolau. | 8 | Definición de tipos de muestras. Paramétrico. | 9 | Definición de tipos de estudios y procesos susceptible de ser realizados. Paramétrico. | 10 | Definición de proceso que debe aplicarse a la muestra, según tipo de muestra (Ej. Inmunofluorescencia, histoquímica, numero de cortes a practicar, Tinciones) | 11 | Identificar muestras, bloques y placas histológicas, asociadas al paciente. Imprimir etiquetas con código de barras. | 12 | Capacidad de asociar un paciente con la biopsia, muestra, bloques, placas e informe | 13 | Trazabilidad de la muestra a través de los diferentes procesos y sus etapas. (Definición de estados), desde la solicitud de la muestra hasta el informe terminado y entregado. Integración con Módulo clínico indicando etapa del proceso en que se encuentra la muestra. (Cambios de estado). | 14 | Cada cambio de estado debe capturar fecha, hora y persona responsable, Generar reporte de tiempos que la muestra esta en cada etapa del proceso. | 15 | Visualización de lista de trabajo en cada sección, donde se debe registrar el trabajo realizado e insumos utilizados. Interfaz de usuario configurable. | 16 | En los puntos del proceso en que hay informes, debe visualizarse la orden de biopsia, visualizar biopsias anteriores para comparación y poderse invocar la FCE (protocolo quirúrgico, etc.) | 17 | Dictado de informes a archivos digitales, transcripción por secretaría y revisión por el profesional antes de liberar resultado. Los informes e imágenes deben poder ser visualizadas desde el Módulo clínico. | 18 | Capacidad para acceder a la Ficha Clínica al momento de realizar en informe. | 19 | Uso de esquemas de informes predefinidos | 20 | En el momento del informe se pueden generar la solicitud de reprocesos adicionales de la muestra. El requerimiento marcado como reproceso debe aparecen en la pantalla de la sección pertinente en la Lista de Trabajo | 21 | Transcripción a formatos predefinidos | 22 | Posibilidad de realizar informes complementarios a los ya realizados para una muestra determinada | 23 | Capacidad para incorporar FOTOGRAFÍAS de piezas macroscópicas, Los informes e imágenes deben poder ser visualizadas desde el Módulo clínico. | 24 | Captura de imágenes desde MICROSCOPIOS en formato JPEG. Acopio de imágenes en repositorio JPEG. | 25 | Los informes e imágenes deben poder ser visualizadas desde la FCE | 26 | Registro de autopsias | 27 | Consentimiento de familiares para autopsias. Vinculación con formularios. | 28 | Nomenclatura CIE 10 o la del Colegio Americano de Patología, según se decida en la reingeniería de procesos. | 29 | Capacidad para asociar cada muestra, bloque y placa con su lugar de almacenamiento físico, que permita su ubicación a posteriori. | 30 | Seguimiento de estudios citológicos sospechosos. Ej. Papanicolau. Listados y alertas para citación a plazos predefinidos. | 31 | Capacidad para generar reportes de gestión que se defina | 32 | Recepción electrónica de solicitudes de biopsia intra operatoria en pabellón | 33 | Debe poder realizar informe de biopsias intra operatorias en pabellón. Módulo de formularios. | 34 | Capacidad para registrar uso de insumos y consumibles | 35 | Informar cambios de estado a la ficha clínica para trazabilidad | 36 | El informe debe ser visualizado desde el Módulo clínico. Incluye acceso a imágenes que este disponibles, asociadas al informe |

6.19.33 MÓDULO DE ODONTOLOGÍA Este módulo corresponde en realidad a la FICHA ODONTOLÓGICA única nacional de los funcionarios de Carabineros y de sus cargas familiares legalmente reconocidas. Está destinada al registro de los eventos de salud dental de la población beneficiaria y de sus respectivos exámenes y tratamientos.

Debe soportar el flujo de procesos desde el agendamiento, el diagnostico y el tratamiento de los pacientes, incluyendo interfaces de usuario adecuadas para cada una de las especialidades dentales. Asimismo debe proveer el soporte administrativo para el flujo de trabajo del servicio de radiología dental, e integrarse con el sistema de radiología dental digital existente y también proveer el soporte para el flujo de trabajo del laboratorio dental.

Este módulo tiene particular relevancia, por cuanto las instalaciones destinadas a prestar servicios odontológicos tanto en el HOSCAR como en la Red de Salud, son de gran magnitud y trabajan en ella gran cantidad de profesionales (ver capitulo 11). Nro | Concepto | Funcionalidad | 1 | Agenda | Catálogo de clínicas (Boxes) segmentadas por tipo y subespecialidad. | 2 | | Definición de especialidades o profesionales asignados a cada clínica. | 3 | | Definición de segmentos horarios por clínica, y tiempo por cupo. | 4 | | Funcionalidades similares a gestión de agenda, descritas en Agenda Medica. | 5 | | Solicitud automática de Ficha Dental a Archivo de Fichas Dentales, en primeras consultas de pacientes antiguos. (Nuevo evento clínico). Omitir requerimiento en caso de controles, cuando el profesional así lo indique. Ídem cuando se trata de Paciente Nuevo (sin ficha previa). | 6 | | Carga de listado de tratamientos o servicio posibles de ser realizados, con su correspondiente código. Vinculación con módulo de valorización de prestaciones. | 7 | | Habilitación del cupo si el paciente ha resuelto previamente su situación de pago. Uso de un campo lógico, vinculado con Tesorería o Caja. Esta opción no es aplicable a pacientes beneficiarios de Dipreca, portadores de CMC. | 8 | | Impresión de programa de citas dentales del paciente. | 9 | | Recuerdo automático de cita próxima por SMS. | 10 | | Categorización de cupos en campo lógico, que permita "reservar" cupos para ser asignado a pacientes en tratamiento que necesitan ser controlados en determinado plazo | 11 | Presupuesto | Listado de trabajo por clínica y por profesional | 12 | | Indicación en lista de trabajo de paciente "en sala de espera", con indicación del tiempo de espera. | 13 | | Al seleccionarse un paciente, este debe accionar la identificación biométrica para permitir la apertura de la Ficha. | 14 | | Apertura de Ficha Dental del paciente. El formato de la Ficha presentada (clínica o dental), depende del perfil de usuario. | 15 | | La apertura de la Ficha, cambia el estado de paciente en espera a "atención". El cierre de la Ficha cambia estado a "realizado". Cada cambio de estado captura la hora del sistema, para análisis de los tiempos de cada etapa. | 16 | | Los cambios de estado y de paciente se reflejan el Mapa de Clínicas. | 17 | | Registro de anamnesis (motivo de consulta). | 18 | | Examen físico, expresado sobre un Odontograma o Dentograma. | 19 | | Tabla de nomenclatura estandarizada de hallazgos de examen. (Diagnósticos odontológicos) (Ej. Pieza ausente, carie de x tipo o ubicación en la pieza, obturación de x tipo, otros). Representación grafica de los hallazgos en el Dentograma. Clave de colores o símbolos o combinación de ambos. | 20 | | Listado de lesiones encontradas y solución propuesta para cada pieza dental, en listado para valorización y documentación (medio de pago, cargo, otro). | 21 | Atención | Listado de lesiones presupuestadas y documentadas. Solo se podrá trabajar sobre las piezas indicadas y realizar el trabajo presupuestado. | 22 | | Apertura de un historial por pieza, con campos que indiquen trabajo realizado y estado de avance del tratamiento. Vinculación con código de prestaciones. Definición paramétrica de estado de avance de tratamiento por cada pieza. | 23 | | Campo "comentarios" anexo a cada pieza. | 24 | | Formulario de envío de moldes a laboratorio y solicitudes de trabajo, con espacio para insertar comentarios. Debe existir una lista de procedimientos o trabajos que realiza el laboratorio dental, con su correspondiente arancel. (módulo de aranceles) | 25 | | Administración del laboratorio dental utilizando el módulo de "servicios de apoyo" de la FCE, con las adecuaciones pertinentes | 26 | Estudio | Al igual que la Ficha Medica, tendrá acceso al módulo de solicitudes y formularios para solicitar exámenes e indicar terapia farmacológica o especifica de odontología. Trazabilidad de exámenes solicitados. | 27 | | Acceso a resultado de exámenes. Visualización de radiografías. Visualización de radiografías dentales y de Scanner (PACS). | 28 | Evolución | Durante el tratamiento se deberá ir llenando un segundo Dentograma diferente al de ingreso en el que se refleje el tratamiento efectuado y ya terminado. Este Dentograma tendrá fecha actualizada a la ultima atención, de modo que al alta se habrá completado el Dentograma de alta | 29 | | Actualización del estado de tratamiento para la pieza que esta siendo tratada | 30 | Cirugía | Solicitud de pabellón para cirugía máxilofacial. Vinculación con módulo de solicitudes y formularios. Vinculación con módulo de pabellón de FCE. | 31 | | Para cirugía máxilofacial se utilizará la FCE MEDICA con la adecuación que corresponda en la interfaz de usuario. | 32 | | Llenado automático de Epicrisis al alta, similar a FCE MEDICA. Generación de resumen e indicaciones de alta. | 33 | Mapa | Mapa grafico de clínicas dentales por tipo, con indicación de su estado de uso. Visible por personal de recepción y por cualquier profesional usuario. Ej.: en espera del Odontólogo, en espera del paciente, en tratamiento, turno terminado, en aseo, bloqueada, otros. | 34 | Reportes | Registro de insumos utilizados por cada profesional, a partir de consumo estándar por prestación realizada. | 35 | | Producción por profesional, tasa de ausentismo de pacientes, otros que se defina. | 36 | Firma | Firma electrónica en todas las acciones profesionales registradas. | 37 | Perfiles | Creación de roles, perfiles y privilegios que corresponda | 38 | Interfaz de usuario | Se generará interfases de usuario adecuadas para el desempeño de cada subespecialidad | 39 | | El profesional tendrá acceso a SU agenda futura, a fin de citar a su paciente a control. Eventualmente utilizará cupos reservados para este efecto. | 40 | | El profesional deberá indicar en un campo, si para el siguiente control requiere o no requiere de la presencia de la Ficha Dental de papel. Si es paciente nuevo, esta discriminación no aplica. | 41 | Rayos dental | Incluir formulario especial para solicitud de radiología dental. (servicio independiente de Imagenología) | 42 | | Generar una aplicación que permita soportar el flujo de trabajo de radiología Dental, de modo similar al módulo de servicios de apoyo, que permitan generar listas de trabajo, e informes con dictado digital y transcripción. Debe informar a la ficha los cambios de estado a fin de que el Profesional Odontólogo tenga trazabilidad del proceso. Podría utilizarse el módulo de servicios de apoyo. Radiología Dental es Digital Directo sólo para ORTHOPANTOMOGRAFÍA y algún porcentaje de radiografías localizadas. El resto en análoga. | 43 | | Visualización de imágenes de Radiología Dental (establecer link a URL). Formato de radiología Dental: JPEG. | 44 | | Visualización de imágenes de Scanner de Imagenología. Vinculación o invocación del PACS | 45 | Recetas y ordenes hacia el exterior | Las recetas y solicitud de exámenes que el paciente NO quiera realizarse en el Hospital podrán ser impresas en el mesón de secretaria. Identificación biométrica para habilitar impresiones. | 46 | | También el paciente podría auto imprimir en terminales de autoservicio habilitados (KIOSCOS). KIOSCOS= PC touch screen de autoservicio para información del paciente. Funcionan con RUT e identificación biométrica. | 47 | | Los KIOSCOS podrán generar justificativos en que indique fecha y hora de llegada y hora de término de su atención. | 48 | | Los KIOSCOS podrán generar un impreso con las fechas y horas de citación de controles. Eventualmente esta información podría estar disponible en Internet si tiene identificador biométrico. | 49 | Laboratorio Dental | Ingreso de solicitudes u ordenes de trabajo. Funcionalidad similar a las de Módulo de Servicios de Apoyo. | 50 | | Procesos asignados a mecánicos dentales. | 51 | | Entrega de trabajos | 52 | Archivo Ficha Dental | Gestión de Fichas dentales de papel | 53 | | Todo paciente nuevo requiere de verificar si existe ficha en papel | 54 | | El odontólogo indicará si para el siguiente control requiere o no de ficha en papel | 55 | | Las solicitudes de ficha en papel se hará de acuerdo a la planilla de citación de pacientes, por día, por hora, por clínica y por profesional |

6.19.34 MÓDULO INFECCIONES INTRAHOSPITALARIAS Si existe el módulo especifico, proveerlo.
En caso de no existir un módulo específico, generar con la herramienta de BI u otra, vistas de indicadores que provean información tendiente a detectar precozmente un brote de infección intra hospitalaria y analizar las posibles fuentes y su cadena de contactos. Nro | Funcionalidad | 1 | Crear un pantalla de control que recoja datos relevantes que se defina en diferentes áreas, tales como: Cirugías sépticas efectuadas, cepas de bacteria aisladas en laboratorio de microbiología, alertas en detección de determinados hongos y cepas de bacterias, | 2 | Historias de manejo de vías. Detección de fechas de reemplazo no realizadas. Cultivo de muestras de vías. (Vías = todo dispositivo invasivo a permanencia). | 3 | Consumo de antibióticos, fuera de ciertos rangos, con indicación de los pacientes que lo utilizan y su ubicación si es hospitalizado | 4 | Detalle de consumo de determinados antibióticos | 5 | Alerta de enfermedades de notificación obligatoria | 6 | Alerta de enfermedades en vigilancia epidemiológica | 7 | Alerta de presencia de infecciones en pacientes operados en un mismo quirófano | 8 | Trazabilidad del lote de esterilización de cajas quirúrgicas utilizadas en pacientes que resultan con infecciones postoperatorias. | 9 | Ubicación de pacientes con aislamiento | 10 | Ubicación de pacientes infectados con la misma bacteria u hongo | 11 | Resultado de controles bacterianos ambientales de quirófanos y otras dependencias. |

6.19.35 MÓDULO DE MANEJO DE FICHAS CLÍNICAS DE PAPEL * Existe en la actualidad un archivo que acumula unas 80.000 fichas clínicas de papel, las que por razones legales deberán mantenerse a pesar de existir una FCE. Los pacientes que actualmente tienen fichas de papel, tendrán dos fichas, una de papel y la otra electrónica, las que deberán quedar vinculadas. Se prevé que el movimiento de las fichas de papel decrezca en forma significativa con el correr del tiempo, en la medida en que se incremente progresivamente el número de fichas electrónicas.

Cuando un paciente antiguo consulte o se hospitalice, se le generará la FCE, no obstante lo cual al momento de la consulta o en su cama de hospitalización, el profesional dispondrá de la ficha de papel para recabar antecedentes. El mismo profesional indicará si para el siguiente control requerirá o no de la ficha de papel. El archivo de fichas recibe el requerimiento a través de los sistemas de agenda y de gestión de camas. Existe un recinto de archivo independiente para las fichas odontológicas.

Nº | Funcionalidad | 1 | Vincular las FCE con las fichas de papel en cuanto a su identificación con código de barras y su ubicación. | 2 | Capacidad para generar nuevas fichas con su correspondiente código de barras o de colores a partir del numero de RUT | 3 | Archivo maestro de Historias Clínicas o documentación existente; y su ubicación física. | 4 | Clasificación de fichas por triple digito terminal | 5 | Identificación de fichas por código de colores | 6 | Capacidad de impresión de etiquetas con código de barras | 7 | Gestión de solicitudes de fichas, registro de solicitante y punto de destino. Gestión de solicitudes con fines de investigación. Vinculación con Agenda y Admisión (gestión de camas), Módulos de Urgencia, Enfermería. | 8 | Preparación de las fichas de papel uno o dos días previos a la citación | 9 | El sistema debe emitir listados por médico, box y servicio, indicando fecha y hora de atención y su ubicación física, a fin de que el personal pueda retirar las fichas de sus estantes de almacenamiento. Considerar el uso de dispositivos manuales que capturen el listado, ordenado por número correlativo, contra el cual el funcionario va marcando las fichas que encuentra. | 10 | Validación del cumplimiento de los listados, con lectura del código de barras de las fichas, previo a su despacho. | 11 | En los servicios clínicos debería accederse a una pantalla que permita registrar la recepción de dichas fichas y validar el listado de salida de archivo con el nombre y firma electrónica de quien las recibe. | 12 | El servicio clínico debe acceder a una pantalla de devolución utilizando el código de barras, el que generará un listado que debería ser firmado en forma electrónica por quien retira las fichas. Este listado es validado en recepción del archivo, a su ingreso. | 13 | Calificación de prioridades en los despachos | 14 | Capacidad para recibir solicitudes de fichas que se producen en el momento (paciente no agendado previamente, sino recepcionado en el mismo momento. | 15 | Registro de entrada y salida de fichas. Uso de código de barras. | 16 | Gestionar la devolución de fichas. El sistema debe mantener una lista de fichas prestadas, ordenadas por días transcurridos desde la fecha de salida | 17 | Trazabilidad de las fichas de papel que se encuentran circulando. (¿Donde esta?) | 18 | Detección de fichas perdidas o con devolución demorada. El sistema debe mantener una lista de fichas prestadas, ordenadas por días transcurridos desde la fecha de salida | 19 | Capacidad de búsqueda de fichas por diferentes criterios | 20 | Registro de movimiento histórico de las fichas | 21 | Informe de fichas que han salido y no regresan. Verificar si esta hospitalizado. | 22 | Almacenamiento de otros documentos tales como los consentimientos informados originales, con firma autógrafa del paciente, ordenados por folio correlativo del formulario, asociado al número de RUT del paciente. |

6.19.36 MÓDULO DE INFORMACIÓN DEL PACIENTE (KIOSCOS DE AUTOSERVICIO) Se espera poder instalar varios puestos de información de autoservicio para clientes, distribuidos estratégicamente en el HOSCAR, los que en los textos de estas bases técnicas aparecen mencionados como KIOSCOS.

En la descripción de funcionalidades aparecen algunas funciones, a las que posteriormente se le irán agregando otras. Nro | Funcionalidad | 1 | Entrega información a paciente tras identificación con RUT y biometría | 2 | Información de su citación actual, con indicación de su lugar de atención. Mostrará plano de cómo llegar al lugar y eventualmente una explicación escrita | 3 | Informará de citaciones futuras ya comprometidas | 4 | Entregará información de resultado de exámenes | 5 | Imprimirá certificados de justificación de ausencia laboral | 6 | Imprimirá recetas y solicitudes de exámenes que se encuentren pendientes | 7 | Si el paciente ambulatorio tiene indicación de dieta, ésta le será impresa con recomendaciones de nutrición | 8 | Mostrará información breve explicando ciertas enfermedades y su tratamiento. Puede incluir audio. Eventual capacidad para imprimir un resumen predefinido. | 9 | Opera con identificación biométrica y pantallas Touch Screen |

6.19.37 mÓDULO ARCHIVO MAESTRO DE PACIENTES Destinado a registrar los datos demográficos, condición previsional y situaciones o condiciones especiales de los pacientes.

Sin estar registrado en este archivo, NADIE podrá ser atendido. (Excepción: paciente ingresado en Urgencia en condición extrema o inconsciente, ingresado como NN. En este caso el sistema generará un numero Rut ficticio, para habilitar la cuenta de paciente).

Estos datos no volverán a ser ingresados durante los procesos de atención, ya que serán capturados directamente desde este archivo maestro. Nro | Funcionalidad | 1 | RUT. Con algoritmo de cálculo de digito verificador. | 2 | Apellidos (dos en campos separados). Apellido compuesto ocupa un campo, separado por espacio (Ej.: Del Río) | 3 | Nombres (dos en campos separados).Nombre compuesto ocupa un campo, separado por espacio (Ej.: María_ Luisa ) | 4 | Fecha nacimiento. | 5 | Calculo automático de edad por diferencia con fecha de la atención | 6 | Discriminar a partir de la edad si se trata de paciente adulto, niño (pediatría) o lactante (neonatología) | 7 | Vincular edad del paciente con calculo de dosis sugerida en módulo de farmacología | 8 | Lugar de nacimiento: ciudad o localidad. Región (parametrizable) | 9 | Nacionalidad. Ofrecer "Chileno", por defecto. | 10 | Sexo. Opciones parametrizadas. | 11 | Estado civil. Opciones parametrizadas. | 12 | Domicilio: calle, número, departamento, comuna, ciudad, Región. (En campos separados). Posibilidad de ofrecer una ciudad predeterminada por defecto. (Ej. Santiago) | 13 | Teléfonos del domicilio, celular. Campos separados | 14 | Familiar o persona para contacto: nombre, parentesco o relación, domicilio completo, teléfonos. En campos separados | 15 | Lugar de trabajo (nombre, dirección, teléfono). En campos separados. Este dato debe poder ser actualizado por el operador de admisión y/o agenda. | 16 | Condiciones especiales del paciente Ej. Minusválido, sordo. Opciones parametrizadas. | 17 | Condición previsional del paciente, asegurador de salud, convenio al que esta adscrito. Opciones parametrizadas. | 18 | Registro de Nº CMC (Carnet de Medicina Curativa). Este número indica la repartición y el plan de salud de la persona, por lo que debe asociarse a la selección del arancel a cobrar. (proporción del arancel que es bonificado por el Dipreca, por el seguro complementario, y copago de cargo del paciente) | 19 | Una persona puede tener más de un CMC y sólo uno de ellos estará activo. El /los CMC asignados permanecen siempre asociados a la persona | 20 | Capacidad para anotar un nuevo domicilio y teléfonos del paciente, sin perder la información histórica. Ídem respecto de su lugar de trabajo. | 21 | Tarifas especiales a las que el paciente/cliente está afecto. Vinculación con aranceles. | 22 | Capacidad para generar un RUT ficticio único e irrepetible para pacientes inconcientes o que ingresen a urgencia en condición extrema. Este RUT ficticio quedará permanentemente vinculado con la identidad real del paciente, cuando esta situación sea definida. | 23 | Al momento de conocerse la identidad del paciente al que se le asignó un RUT ficticio, el sistema debe corregir la identidad en toda la documentación, incluyendo la identificación en la FCE, en los exámenes, recetas y procedimientos que le hayan sido indicados y realizado, conservando de todos modos y adicionalmente el RUT ficticio como REFERENCIA. | 24 | Para pacientes con grado militar, consignar grado militar unidad a la que pertenece, repartición. En campos separados, con opciones parametrizables. | 25 | Para pacientes con grado militar, Condición de activo, pensionado, montepiado. Opciones parametrizables. | 26 | Para pacientes que son cargas autorizadas de pacientes afiliados a Dipreca, registrar relación de parentesco con el titular. Opciones parametrizables. | 27 | Para pacientes beneficiarios de Dipreca, registrar si esta afiliado al seguro complementario SECOSA. Considerar esta situación para valorización de prestaciones en módulo de aranceles. (Tiene o no tiene seguro complementario). | 28 | Vinculación con el número de Ficha Clínica de papel. Integración con módulo de administración de fichas clínicas de papel. | 29 | Creación automática de un registro provisorio de recién nacido asociado a identidad de la madre, a fin de crear una FCE. Cuando el recién nacido tenga identidad propia, se reemplazará esta información en todos los documentos creados con la identidad transitoria. |

6.19.38 MÓDULO DE AGENDA MÉDICA Está destinado a gestionar la oferta de los recursos profesionales disponibles para pacientes ambulatorios.

Se considera un sistema de agendamiento único parametrizable para las necesidades de cada uno de los establecimientos de salud de la red, con vistas locales por defecto para cada uno de ellos, con la opción de ingresar a la agenda de otros establecimientos para agendar ínter consultas y derivaciones.

Nro | Funcionalidad | 1 | Creación y definición de Boxes de atención. | 2 | Asignación de Boxes por especialidades. | 3 | Asignación de Boxes a determinados profesionales. | 4 | Definición de bloques horarios de atención especialidad/profesional/box. | 5 | Estructurar un Mantenedor de agenda | 6 | Definición de cupos. Tiempo asignado por atención de paciente nuevo o en control. Tiempo parametrizable por tipo de cupo (Mantenedor). | 7 | Los cupos deben tener un campo que permita categorizar este cupo según su destino. Ej. Paciente nuevo, paciente en control, cupo para ser asignado por el medico tratante desde la FCE al momento de la consulta, derivación de servicio de urgencia, derivación de provincia, paciente minusválido, anciano. La asignación de algunos destinos de cupos debe estar ligada a privilegios. | 8 | Capacidad de generar sobre cupos cuando la agenda se encuentra completa, dependiendo del perfil de usuario. | 9 | Capacidad de bloqueo de cupos o de bloques horarios, con indicación parametrizada de las razones. Ej. Profesional de vacaciones, asistente a algún evento especial. | 10 | Capacidad de redistribuir cupos asignados en casos de inasistencia del profesional (reasignación de cupos). | 11 | Capacidad de visualizar si existe ficha clínica en papel para el paciente que se cita. Vinculación con módulo de gestión de Ficha Clínicas de papel. | 12 | Por defecto, en “primeras consultas” por evento nuevo se solicitará la ficha de papel. | 13 | Para controles, verificará si el medico solicitó o no la ficha para el este control. | 14 | Capacidad para solicitar automáticamente la Ficha clínica de papel (si corresponde). El medico debe marcar si para el siguiente control requiere o no la ficha antigua en papel. | 15 | Capacidad del sistema de proponer el cupo más próxima disponible para el medico o la especialidad según se trate. | 16 | Asignación de cupo a un paciente. Previamente se debe validar que el paciente ha realizado los tramites administrativos (pagos o validación de crédito por pertenencia a convenio). Vinculación con tesorería. Si el paciente es beneficiario de DIPRECA, debe cargarse automáticamente el importe de la prestación en la cuenta de paciente. | 17 | Registro de cupos asignados previamente, con paciente inasistente. Generación de alerta. | 18 | Capacidad para asignar cupos múltiples, evitando coincidencia de horas (en diferentes especialidades). | 19 | Alerta en caso de existir cupos asignados aun pendientes del mismo paciente. Evitar duplicación de citas. | 20 | El sistema debe registrar para cada asignación de cupos, cual es el agente, persona o terminal que registró la operación (Ej. Call Center, Operador Juan Pérez. Internet/Intranet, el paciente) | 21 | Capacidad de visualizar agenda y asignar cupos en otros centros u hospitales de la red de salud Institucional. Capacidad multicentro y multiempresa de la aplicación. | 22 | Alertas en caso de paciente minusválido. Parametrización de tipos de invalidez. | 23 | Habilitación automática de acceso a la Ficha Clínica Electrónica en el día de la cita, para el medico tratante y personal de apoyo. Vinculación con módulo de seguridad del sistema. | 24 | Generación de una lista de espera por especialidad o tipo de requerimiento. Deben poder ordenarse por diferentes criterios tales como: antigüedad en la lista, control/nuevo, nivel de urgencia o prioridad clínica ("tipo Triage"). Debe capturarse día y hora del ingreso a la lista de espera, a fin de medir el tiempo de espera | 25 | La prioridad de pacientes en lista de espera debe poder modificarse a fin de adecuarla a la evolución y circunstancia del paciente | 26 | Al asignarse un cupo a alguien que esta en lista de espera, debe incorporarse a la agenda sin tener que volver a digitar datos de paciente. | 27 | Categorización de listas de espera por condición clínica y antigüedad en la lista. | 28 | Priorización de citas para pacientes AUGE, según protocolo. | 29 | Priorización de pacientes de edad avanzada, que viven fuera de santiago y minusválidos | 30 | Capacidad para que el médico tratante pueda asignar en el momento de la consulta, un cupo para controlar a su paciente. Evita hacer trámite de solicitud de hora. Solo debe validar que en pacientes no beneficiarios de Dipreca, se ha realizado los tramites administrativos (pagos o validación de crédito por pertenencia a convenio) | 31 | El médico podrá ver su agenda para días futuros. | 32 | Búsqueda rápida de cupos asignados a un paciente determinado | 33 | Capacidad para medir tiempos de espera de los pacientes (desde hora asignada/ hasta ser llamados). Reporte por especialidad y por profesional. | 34 | Capacidad para medir atrasos de pacientes. Hora asignada/hora de llegada | 35 | Capacidad para medir atrasos y horas trabajadas en exceso por el profesional. Primera hora programada/primer paciente llamado. Ultima hora programada/hora del ultimo paciente atendido. | 36 | Capacidad de generar reportes de gestión predefinidos. Ejemplo: cupos máximos posibles, cupos programados, cupos programados no utilizados (ausencia del paciente o del profesional). | 37 | Reporte de cantidad y Causas de bloqueo de cupos, por especialidad. | 38 | Reporte de cantidad de pacientes nuevos y en control por médicos, por especialidad. | 39 | Reporte de tiempos promedio de atención por medico, por especialidad para pacientes nuevos y en control. | 40 | Capacidad para realizar reportes en forma grafica Ej. Cantidad de pacientes llegados vs. Hora del día, para identificar horarios punta. Oferta de cupos por hora del día, etc. | 41 | Capacidad de generación de reportes nuevos, por parte del administrador del sistema. | 42 | Capacidad de generación mensajes SMS a una hora determinada y días antes a la cita (parametrizable cuantos días antes), para confirmar o recordar a los pacientes su cita. Debe capturar en forma automática los datos de la cita. El número de celular lo tomará del Archivo Maestro de Pacientes. Si no tiene móvil, registrado enviará listado con números de teléfono al Call Center para recordación manual. | 43 | Los cupos de cita tendrán un campo para marcar si se le ha confirmado o recordado la cita al paciente. | 44 | Si la confirmación de cita es manual, vía telefonista, deberá haber un campo para registrar si el paciente asistirá o anula su hora. | 45 | Debe indicar causas de anulación. Debe registrarse nombre de persona que fue contactada. Debe registrar día, hora y operador que llamó. Debe capturar en forma automática los datos de la cita. El número de celular lo tomará del Archivo Maestro de Pacientes. Si no tiene móvil, registrado enviará listado con números de teléfono al Call Center para recordación manual. | 46 | Debe permitir que el médico agende un control desde la Ficha del paciente que está atendiendo | 47 | Reporte de disponibilidad de cupo más próximo por especialidad o servicio requerido. Reportes de listas de espera por especialidad y servicio requerido | 48 | Capacidad para imprimir la citación, agregando información estandarizada a definir. Capacidad para imprimir el cargo efectuado en la cuenta de paciente. |

6.19.39 mÓDULO DE HOSPITALIZACIÓN (GESTiÓN DE CAMAS) Debe permitir la completa gestión de los diferentes tipos de camas con que cuenta el hospital, y facilitar la entrega de información a los familiares, respecto de la ubicación y del estado de salud de los pacientes hospitalizados. Nro | Funcionalidad | 1 | Definición de tipos de cama (según complejidad) y su ubicación en el hospital. Ej. Cama normal, observación, recuperación, UCI, UTI, Urgencia, camillas de examen de urgencia. | 2 | Tipo de habitación en que se encuentra la cama. Habitación de una cama, dos camas, diálisis, quimioterapia, UCI, UTI, Recuperación, | 3 | Vinculación de camas por servicios clínicos determinados y por estaciones de enfermería. Ej. Camas de medicina, cirugía, neurología/neurocirugía, oncología, urgencia, otras especialidades. | 4 | Disponibilidad de las camas. Ej.: ocupada, disponible, en aseo, en mantención, bloqueada, ocupada con posible alta en las próximas 24/48 horas. | 5 | Debe tener vinculación con módulo de aseo y mantención o con enfermería. | 6 | Censo diario de camas. Vinculación con módulo de enfermería. | 7 | Gestión de solicitud de cama. Módulo de formularios: solicitud de camas desde la FCE. | 8 | Gestión de lista de espera de camas | 9 | Asignación de cama a un paciente. Vinculación con archivo maestro de pacientes. | 10 | Vinculación con cuenta del paciente | 11 | Vinculación con oficina comercial ERP (validación de derechos o crédito si corresponde) | 12 | Vinculación con Módulo de enfermería. | 13 | Alerta en estación de enfermería pertinente, en caso de ingreso de paciente. | 14 | Generación de una lista de espera de camas por tipo o servicio clínico | 15 | Generación de una lista de espera por especialidad o tipo de requerimiento. Deben poder ordenarse por diferentes criterios tales como: antigüedad en la lista, control/nuevo, nivel de urgencia o prioridad clínica ("tipo Triage"). Debe capturarse día y hora del ingreso a la lista de espera, a fin de medir el tiempo de espera. | 16 | La prioridad debe poder modificarse a fin de adecuarla a la evolución y circunstancia del paciente | 17 | Al asignarse una cama a alguien que esta en lista de espera, debe incorporarse sin tener que volver a digitar datos de paciente | 18 | Categorización de listas de espera por condición clínica y antigüedad en la lista. | 19 | Gestión de nacimientos. Generación de identificación, asignación de cuna, asignación de cuenta corriente independiente de la madre en caso de hospitalización del recién nacido. Considerar situación de partos múltiples. | 20 | Gestión de traslados. Vinculación con módulo de enfermería de sectores o salas involucradas en los traslados. | 21 | Modificación de cuenta del paciente, en caso de traslados. | 22 | Re direccionamiento en recetas, exámenes y procedimientos pendientes (actualización de ubicación), en casos de traslados. | 23 | Gestión de altas/fallecimientos. Vinculación con módulo de enfermería. | 24 | Cierre de cuenta de paciente, en caso de fallecimiento. | 25 | Anulación de recetas, exámenes y procedimientos pendientes, en caso de fallecimiento. | 26 | Visualización de existencia previa de Ficha Clínica en Papel. Vinculación con módulo de gestión de fichas Clínicas en papel. | 27 | Solicitud automática de Ficha Clínica Tradicional al ingreso de un paciente a hospitalización. (Cuando corresponda). Vinculación con módulo de gestión de fichas Clínicas en papel. | 28 | Reportes de gestión de camas. Ej. Índices de ocupación, tiempo medio de estada, índice de rotación, índice de camas operables en total y por servicio clínico. Ingresos/egresos diarios y mensuales. | 29 | Reportes de listas de espera por tipo de cama y especialidad requerida | 30 | Mapa gráfico de camas, con indicación del ocupante, estado de salud y autorización de recibir visitas. Utilizar colores para diferentes condiciones (en uso, disponible, el aseo, en reparación, bloqueada, alta próxima.). Uso de formas diferentes para distinguir tipo de camas. Adultos, pediatría, neonatología, maternidad, critica, recuperación. |

6.19.40 MÓDULO de GESTIÓN DE CENTROS DE SALUD FAMILIAR Y DE PROGRAMAS DE SALUD

Este módulo esta destinado a gestionar y operar programas de Salud, de medicina preventiva, de vacunación que se apliquen en la Red de Salud, independientemente de si el establecimiento corresponde a nivel primario, secundario o terciario.
Asimismo debe permitir gestionar los Centros de Salud Familiar (CESFAM), incorporando algunas funcionalidades que son propias de esta actividad y algún método que permita establecer las vinculaciones parentales, las que quedaran registradas en las FCE personales de cada integrante de la familia.

Nro | Concepto | Funcionalidad | 1 | Atención Primaria y salud familiar | Debe discriminar Atención Primaria de Atención de Salud Familiar (CESFAM) | 2 | Salud Familiar | Debe permitir registro de historia familiar y genética, vinculada con esquema gráfico de árbol de relación parental. | 3 | | La vinculación parental debe poder ser visualizada desde la FCE de cada uno de los integrantes de la familia que se ha definido. | 4 | | Si se realiza una sesión o actividad (evento o acción) que involucre a la familia, el registro de la actividad será copiada en la FCE de cada integrante del grupo familiar asistente. | 5 | | Las sesiones o actividades grupales de la familia podrán ser calificadas de confidenciales, y requerir un perfil definido para su visualización. | 6 | Programas de Salud | Capacidad de definir y gestionar programas de salud y de medicina preventiva, en diferentes temas Ej.: detección precoz de diabetes, hipertensión arterial, obesidad, cáncer mamario, otros canceres, programas de vacunación, etc. | 7 | | Debe poder vincular al paciente (y su FCE) con el respectivo programa o programas de salud al que se adscribe. | 8 | | Capacidad para controlar y hacer seguimiento de programas específicos de salud y de medicina preventiva, de alcance nacional (MINSAL) y/o Institucional de Carabineros. |

6.19.41 mÓDULO DE CUENTA DE PACIENTES (Puede ser parte de lA FCE o del ERP) Módulo destinado a registrar tanto los cargos que se le deban efectuar a un paciente por concepto de prestaciones, insumos, medicamentos y servicios, en el momento en que estos se devenguen, como los abonos que efectúe.

Esta cuenta corriente debe habilitarse automáticamente al momento de su ingreso a hospitalización o al servicio de urgencia, respetando las condicionantes que se definan en las reglas de negocio.

N° | Funcionalidades | 1 | Capturar desde el Archivo Maestro de Paciente los datos demográficos. | 2 | Capturar desde archivo maestro de pacientes la condición previsional del paciente y el arancel (tabla de precios) a aplicar. | 3 | Referencia a documentos en garantía, mediante vinculación con módulo de Tesorería. | 4 | Habilitación automática de cuenta de paciente por evento. Requiere integración con módulo de Gestión de Camas (hospitalización) y módulo de Servicio de Urgencia. Verificación previa de existencia de garantía en Tesorería. Los beneficiarios de DIPRECA portadores de CMC, tienen garantía constituida por defecto. | 5 | Registro de cargos a partir de información proveniente de módulos que generan transacciones en la FCE y ERP. Ejemplos: servicios de apoyo, pabellones, farmacia, insumos médicos. | 6 | El registro de cargos debe incluir los siguientes datos: 1) Fecha, servicio de origen, terminal o punto de red de origen. 2) Funcionario que genera la transacción. 3) Numero del documento que origina la transacción (Numero de la receta, solicitud de examen o procedimiento, intervención quirúrgica, otros). 4) Código de la prestación, fármaco o insumo. 5) Arancel aplicado, valorización (precio). | 7 | Realizar registro diario y automático de cargos por día/cama (la hora que gatilla el cobro se configura según la regla de negocios que se especifique). Vinculación con hospitalización (Admisión o Gestión de Camas). Vinculación con Aranceles. | 8 | Registro de cargo por concepto de Visita a Paciente Hospitalizado: 1) cada vez que un médico escriba un ingreso de paciente a hospitalización y la valide con su firma electrónica 2) registre una evolución en la FCE y la valide con su firma electrónica. Debe registrar el nombre del médico, fecha y hora de la visita, identificación del terminal utilizado. | 9 | Registro de abonos, que debe incluir al menos: 1) fecha 2) tipo de abono. 3) Referencia al documento de ingreso a Tesorería (folio del ingreso) | 10 | Mantención automática del saldo de la cuenta corriente. Este saldo debe ser capturable por contabilidad al cierre de mes para acreditar ingresos devengados. | 11 | Emisión impresa de listado foliado de cargos (prefactura) en el formato que se defina, separado por tipo de cargo (familia de prestaciones), con subtotales y total. Indicación de monto de copago si corresponde. Indicación del funcionario y terminal o punto de red que lo emite. | 12 | Registro de ventas por prestaciones ambulatorias, con anotación de los mismos detalles requeridos en caso de ingreso en cuenta de paciente. Para pacientes NO DIPRECA registrar el folio y fecha de ingreso en tesorería ya sea en pago de la prestación o valores en garantía. En los pacientes beneficiarios de DIPRECA, el cargo en cuenta de paciente no requiere de ingreso ni comprobante de tesorería, ya que se trata de una venta a crédito. | 13 | Alerta al ingresarse nuevos eventos en Agenda Médica, hospitalización y Servicio de Urgencia respecto del estado de deuda del paciente. | 14 | Registro de cargos y abonos anulados (razón de anulación, identificación del funcionario y terminal). Debe registrarse como asiento de reversa. | 15 | Registro y anulación automática de ordenes, recetas y solicitudes pendientes al momento de concretarse el alta del paciente. | 16 | Cierre de la cuenta corriente al concretarse el alta del paciente. (definición de cuantas horas posteriores al alta) | 17 | Las prestaciones realizadas por profesionales además del registro en la cuenta de paciente, deben registrarse y acreditarse en la cuenta del médico y del servicio clínico o unidad de negocio a la que éste pertenece (proveedor interno). Integración con ERP. | 18 | Permitir cargos de prestaciones realizadas en otros establecimientos por derivación transitoria durante la hospitalización. Vinculación con Emisión de Cartas de Resguardo por parte de Tesorería. | 19 | Permitir cargos por Procesamiento de Muestra Realizadas en Entidades externas, de acuerdo al Arancel Convenido |

6.19.42 módulo de aranceles (Puede ser parte de lA FCE o del ERP) El hospital debe poder trabajar con múltiples aranceles para la valorización de las prestaciones de salud que otorga y que se encuentran debidamente codificadas, a fin de poder adecuar los valores a los diferentes convenios que se suscriba.

Nro | Funcionalidad | 1 | Debe contener un listado codificado para cada una de las prestaciones, productos, fármacos e insumos que el Hospital ofrece. En prestaciones clínicas debe utilizar codificación FONASA, propias y su equivalencia en codificación CIE 9 MC. | 2 | Este listado debe estar segmentado por familias de productos. | 3 | Debe proveer las funciones de mantención de estos listados. (agregar, modificar prestaciones) | 4 | Permitir la creación de múltiples tablas de valores (aranceles o precios de venta) para las prestaciones y productos disponibles, a fin de poder aplicar diferentes aranceles según la previsión del paciente y convenios que se defina. | 5 | Debe permitir que para las prestaciones otorgadas a beneficiarios de Dipreca se pueda calcular el monto bonificado, cobertura de seguro y copago, de acuerdo a las diferentes coberturas que otorga el asegurador DIPRECA, según los derechos del asegurado, los que se distinguen por el código de CMC, que esta asociado al RUT en el archivo maestro de clientes. | 6 | Los valores deben poder ser ingresados en forma libre, o generados automáticamente aplicando una constante configurable sobre un valor base. (Ej. 10% sobre valor FONASA nivel 1.) | 7 | A cada listado de valores correspondiente a una modalidad de venta o convenio debe tener una fecha y hora de vigencia, es decir fecha desde la cual el arancel es aplicable, y fecha y hora de termino, lo que implica que dicho valor deja de aplicarse a contar de la fecha de término. Esto debería permitir valorizar prestaciones ocurridas en cualquier fecha pasada, con el valor vigente a dicha fecha. (Situaciones de recalculo de cuenta en virtud de acreditarse una determinada condición. Ej.: Lesión en acto de servicio) | 8 | Los listados de valores deben permanecer disponibles, aun cuando hayan dejado de estar vigentes. | 9 | Para los efectos de las hospitalizaciones transitorias (Ej. Cirugía ambulatoria, diálisis, quimioterapia), debe ser posible calcular fracciones del arancel base de un día cama (Ej. Horas cama). Parametrizable. | 10 | Debe proveer estos valores vinculados con la condición previsional, convenio o modalidad de atención que corresponda al paciente que estará registrada en el archivo maestro de pacientes. . (Ej. Paciente acogido a la modalidad AUGE) | 11 | Debe estar vinculado con el módulo de hospitalización a fin de cargar en la cuenta del paciente los días de permanencia según el tipo de habitación que tenga asignada cada día. | 12 | Debe estar vinculado con el Módulo de gestión de servicio de Urgencia | 13 | Debe permitir la creación de paquetes de prestaciones, con contenidos configurables, registrados bajo un código de prestación creado para el efecto. Las prestaciones contenidas en el paquete deben conservar su codificación nativa. | 14 | Debe permitir la confección detallada de presupuestos de atención o de programas médicos. Estos presupuestos deben ser guardados debidamente foliados y vinculados con el paciente. Debe poder ser impreso en formato pre establecido. | 15 | Debe permitir imprimir y grabar en CD en formato Excel, el o los aranceles pactados correspondientes a un determinado asegurador o financiador. | 16 | Debe permitir generar recargos parametrizables sobre un determinado arancel, vinculados con la hora o día hábil o inhábil en que se otorga una prestación. Definición parametrizable de horario hábil/inhábil. | 17 | Valorizaciones diferenciadas para una misma prestación, servicio, medicamento o insumo, dependiendo de la calidad de ambulatorio, hospitalizado o atención de urgencia. Recargo por horario inhábil. |

6.19 MÓDULOS opcionales de laboratorio y banco de sangre El sistema de FCE debe integrarse con los aplicativos de Laboratorio Clínico y Banco de Sangre, actualmente en uso en el Hospital. El hospital no es propietario de estoa aplicativos, sino que licita bianualmente los servicios de estos dos módulos, por lo que, en teoría los aplicativos podrían ser diferentes cada dos o tres años.

Comprendiendo que a los proveedores de FCE podría resultarles más conveniente proveer estos módulos en lugar de integrarse con ellos, se les otorga la posibilidad de proveerlos con las funcionalidades que más abajo se especifica.

Quienes opten por proveer estos módulos opcionales deberán autoevaluarse y cumplir al menos con los puntajes mínimos establecidos en el capitulo 8.6 de evaluación. En caso de cumplimiento, se adjudicarán el puntaje de establecido en la pauta de evaluación general. En caso de ejercerse esta opción, debe migrarse los datos existentes, si técnicamente fuera posible. El contrato del uso del Software actualmente en uso en el Laboratorio Clínico, tiene vigencia de 36 meses a contar del 11 de Octubre de 2010. El contrato de uso del software actualmente en uso en el Banco de Sangre, tiene una vigencia de 2 años a contar del 1 de Enero de 2011.

6.20.43 MÓDULO DE LABORATORIO CLÍNICO Debe vincular las muestras con los resultados de los exámenes requeridos a través de órdenes electrónicas y manuales, capturando los resultados de los equipos automatizados de laboratorio y los resultados de los procesos manuales, y generando los correspondientes informes que serán visualizados desde la FCE. Los equipos automatizados de laboratorio clínico se encuentran en comodato por la compra de insumos, de modo que estos equipos podrían variar en las sucesivas licitaciones. El módulo de laboratorio deberá integrarse con los equipos actualmente en uso y con todos los que se incorporen en el futuro. Esta obligación es parte de las exigencias del contrato de mantención anual post garantía.

Nº | Concepto | Funcionalidad | 1 | | Debe dar soporte al flujo de trabajo de cada una de las secciones del laboratorio | 2 | Toma de muestras | De acuerdo con los exámenes solicitados por el Médico, el sistema debe indicar el tipo de frasco y volumen de sangre a colectar. Asimismo debe generar una etiqueta con código de barras adecuado para ser leído por la maquina que procesará la muestra | 3 | | El código de barras debe indicar el examen requerido y la identificación del paciente y el lugar de la toma de muestra | 4 | | La captura de identidad del paciente se logra capturando el código de barra de la identificación del paciente. Con el mismo procedimiento se identifica la persona que tomó la muestra. Esta acción debe cambiar el estado de la solicitud de examen parea los efectos de trazabilidad y marcar como efectuada la acción de enfermería anotada en la lista de trabajo. Esta acción deja un registro en la hoja de enfermería, con indicación de la hora. | 5 | Recepción de muestras | Al recibirse la muestra en el laboratorio, se lee su código de barras, se asocia con la solicitud de examen, se cambia de estado en la trazabilidad de la solicitud en la FCE y se carga la lista de trabajo de las maquinas pertinentes o de la persona encargada del proceso. | 6 | | Al procesarse la muestra el equipo e laboratorio debe leer nuevamente el código de barras del frasco. Si la acción es manual, el operador debe efectuar este registro | 7 | Resultados | Debe existir integración entre el LIS y los diferentes equipos de laboratorio que entregan resultados en formato digital, a fin que estos datos sean guardados en el LIS | 8 | | Al estar listo el resultado, estos deben ser previamente revisados por el profesional responsable de realizar esta función. | 9 | | Efectuado el control de calidad el resultado es liberado para conocimiento del Médico tratante en la FCE. Se cambia de estado en el sistema de trazabilidad de la FCE. | 10 | | Los resultados fuera del rango normal, deben poder destacarse gráficamente en forma evidente. Debe poder gatillarse un evento critico, en las situaciones que se parametrice, generándose las alarmas y comunicaciones tipo email y SMS, que se defina | 11 | | Los procedimientos de laboratorio cuyo resultado se genera en forma manual, deben tener un soporte de flujo y de proceso proporcionado por el LIS, a fin de que el operador disponga de una "lista de trabajo" y pueda incorporar los resultados obtenidos | 12 | Display | Si el paciente tiene otros exámenes del mismo tipo, el sistema debe permitir que se despliegue una serie comparativa. El Médico debe poder recibir cuantos resultados se deben comparar. Debe permitir seleccionar uno o más criterios para desplegar un gráfico. Ejemplo: curvas de glicemias seriadas, hematocrito, otros. | 13 | Cargo en cuenta del paciente | Los exámenes realizados deben cargarse automáticamente en la cuenta del paciente, al ingresarse la muestra al laboratorio. | 14 | Microbiología | El análisis de las cepas bacterianas y de la sensibilidad antibiótica debe alimentar un reporte para los efectos del trabajo de la unidad de IIH. | 15 | | La detección de virus, hongos y bacterias vinculadas con enfermedades de notificación obligatoria, debe reportarse automáticamente a la unidad encargada de esta labor, sin perjuicio de reportar también a la unidad de IIH. | 16 | | La detección de virus y bacterias vinculadas situaciones que requieran de aislamiento del paciente, será notificado automáticamente a la estación de enfermería de origen, en calidad de evento crítico. | 17 | Calibración de equipos automáticos | El sistema debe llevar un registro de los resultados de las muestras de calibración de cada equipo. Debe permitir registrar valores medidos en contra muestras medidas en laboratorios de control | 18 | Administración | Reportes de producción predefinidos. Ejemplo: Estadística de producción por sección | 19 | | Alimentación de indicadores de calidad | 20 | | Solicitud de insumos. Integración con bodega de insumos (ERP) |

6.20.44 MÓDULO DE BANCO DE SANGRE Debe asegurar la trazabilidad de la sangre desde que es donada hasta que es utilizada en forma natural o como hemoderivados. Debe controlar la fecha de caducidad y su eventual eliminación.

Deberá integrarse con los equipos automatizados con que se efectúan las pruebas de laboratorio de la sangre donada. Los equipos se encuentran en comodato por la compra de insumos, lo que es licitado periódicamente. Este módulo deberá integrarse nuevamente cada vez que esto ocurra, siendo esta obligación parte de las exigencias del contrato de mantención anual post garantía. Nº | Concepto | Funcionalidad | 1 | Ingreso de donantes | Vinculación con archivo maestro de pacientes (MPI) | 2 | | Registro de donantes esporádicos y habituales | 3 | | Historial de donantes | 4 | | Sistema que permita recordar a donantes habituales que están en plazo de poder volver a donar | 5 | Recolección de sangre | Generación de etiquetas parea bolsa de sangre y frascos para muestras para exámenes de laboratorio | 6 | | Asociación de la bolsa y de las muestras con el donante | 7 | | Asociación del resultado de los exámenes de muestras y clasificación, con el historial del donante | 8 | | Alertas en resultados de exámenes que inhabiliten el uso del material donado. | 9 | | Alerta de donante inhabilitado por ser portador de….. | 10 | | Registro de notificación donante que es portador de ……, que lo inhabilita para ser donante | 11 | Generación de hemoderivados | Generación de etiquetas para identificación de bolsas de hemoderivados. Asociación de hemoderivados con la bolsa madre. Registro de fecha de elaboración y caducidad | 12 | Mantención | registro de stock por tipo de sangre y de hemoderivados ordenados por fecha de elaboración y fecha de caducidad | 13 | | Alertas de fecha de caducidad de material en stock, con "n" días de anticipación. | 14 | | Registro de desecho de sangre y hemoderivados con indicación de causal | 15 | Utilización | Recepción de solicitudes electrónicas de sangre y/o hemoderivados. Habilitación de algún tipo de alarma acústica de recepción de solicitudes de aplicación inmediata. | 16 | | Realización y registro de resultado de pruebas cruzadas de compatibilidad | 17 | | Instalación de la transfusión requerida, por personal del Banco. Debe asociar código de barras de la identificación del paciente, con la bolsa y finalmente con la identificación del funcionario que realiza la acción. Esta acción deja un registro en la hoja de enfermería, con indicación de la hora. | 18 | | La acción anterior debe generar en la hoja de enfermería un campo para registrar reacciones adversas, de acuerdo con una tabla de opciones predefinidas. Este registro debe transferirse al historial del banco de sangre para la bolsa utilizada. En caso de reacciones adversas, debe generar una alerta o alarma en el banco de sangre, a fin de que tomen acciones. Debe registrarse la hora de término de la administración en la hoja de enfermería de modo similar a la aplicación de un suero. | 19 | | El receptor del hemoderivado debe quedar vinculado en el historial del donante | 20 | Transferencias | Debe registrarse las transferencias que ocurran desde otros BANCOS COMERCIALES. Este registro debe incorporar la totalidad de la información del donante y las pruebas de laboratorio realizadas | 21 | | Debe registrarse las transferencias que ocurran hacia otros BANCOS COMERCIALES. Debe adjuntarse las pruebas de laboratorio y datos del donante | 22 | Cargos en cuenta de paciente | Al registrarse la administración de un hemoderivado a un paciente, se produce automáticamente el cargo en la cuenta del paciente y el movimiento de stock del banco. | 23 | | Este Módulo debe permitir la completa trazabilidad de la muestra desde su origen hasta su utilización y/o eliminación | 24 | Administración | Reportes predefinidos de producción y productividad | 25 | | Reportes diarios de stock | 26 | | Alertas de fecha de vencimiento de productos | 27 | | Solicitud de insumos | 28 | | Alimentación de indicadores de calidad |

6.20 MÓDULOS REQUERIDOS para el área DEL ERP (AUXILIARES administrativOS Y SUS FUNCIONALIDADES) 6.21.45 Requerimientos Generales. Entendiendo la complejidad de los procesos financiero-contables que deben incluirse en una Solución de Gestión Administrativa, además de proveer indicadores de gestión ligados con la realidad económica de los procesos a controlar, se ha definido como premisa inicial que el desglose y detalle de los requerimientos finales de esta solución sean definidos durante el proceso de adjudicación de la propuesta y con la asesoría del oferente mediante un proceso de consultoría y re-ingeniería que definirá el alcance final de implantación del sistema. En esta sección se presentan los requerimientos de carácter general que el oferente deberá considerar al generar una propuesta válida para la realidad de DISALCAR. Se entiende por Solución ERP un Sistema Integrado de gestión financiera-contable, administrativo y logístico, que cumple las normas, usos y costumbres contables y financieras de aceptación general, además de las normas presupuestarias legales que han sido estipuladas por la Contraloría General de la República y Ministerio de Hacienda para las entidades gubernamentales. 6.21.46 Requerimientos Específicos. * Multimoneda. * Multi centros de responsabilidad. * Herramientas que permitan al usuario definir y parametrizar “avisos”, “alertas” y condiciones en que el sistema debe proceder. Esto permite al usuario recibir un panel de alerta o un mensaje de correo electrónico cuando ocurra en el sistema la condición especificada en la parametrización (por Ej.: Vencimiento de una factura, demora en aprobación de una solicitud de compra, etc.). * Flujos de funciones de Recursos Humanos (RRHH) manejado por WorkFlow. Los requerimientos han sido clasificados utilizando una definición estándar de los módulos considerados dentro de una solución ERP, los cuales se presentan a continuación.

6.21.47.1 Área Financiera y Contable. 6.21.47.2.1 Contabilidad General Ejecuta todos los registros de la contabilidad en Pesos Chilenos y mantiene en los auxiliares aquellos registros en otras denominaciones monetarias en forma simultánea. CONTABILIDAD | N° | Funcionalidades | 1 | Debe tener capacidad multiempresa, es decir, llevar contabilidades independientes de varias instituciones (empresas) | 2 | Debe tener capacidad Multicentro, es decir, cada contabilidad debe poder registrar múltiples Unidades de Negocio (UN), cada una de las cuales tendrá un Estado de Resultados operacional en línea e incluirá los gastos o costos distribuidos al cierre del periodo. Las UN podrán agruparse en departamentos. | 3 | Debe generar un output para contabilidad gubernamental (Formato SIGFE II /XML) para satisfacer requerimientos obligatorios, con los contenidos y formatos exigidos. | 4 | El Plan de Cuentas debe permitir que las cuentas madre puedan anidar 5 o más niveles jerárquicos y a su vez, estos niveles deben poder abrirse en subniveles, a fin de garantizar la granularidad de la información ( Según Plan de Cuentas establecido por el Sistema de Contabilidad Gubernamental y Ministerio de Hacienda) | 5 | Las cuentas contables deben poder definirse por el Departamento de Contabilidad y Finanzas de DISALCAR como Presupuestarias en la parametrización del sistema. Se requiere Integración con módulo de Presupuesto. | 6 | Las cuentas que se definan deben poder incluir lógica de negocios que permitan su distribución a las unidades de negocio (UN), de acuerdo con los criterios que se establezca | 7 | La contabilidad se llevara en moneda nacional, aunque los auxiliares deben permitir el uso de otras monedas y de Unidades de Fomento, que se convertirán a pesos al centralizar, de acuerdo con tipos de cambio o valores que se ingresen en el periodo. | 8 | La imputación contable debe poder ser ejecutada a nivel de las Unidades de Negocio. La Imputación contable, debe afectar automáticamente a la ejecución presupuestaria. | 9 | La parametrización del sistema tributario debe adecuarse a la legislación y reglamentación tributaria vigente en Chile para el Sector Público | 10 | Debe permitir la generación de diferentes tipos de comprobantes contables, según se defina en la parametrización del sistema. | 11 | Asignar a las Cuentas de Gastos de Operación una lógica de distribución automática por Unidades de Negocio o Centros de Responsabilidad.
Ejemplo: Distribución del gasto de agua, combustible de calefacción, energía eléctrica por metro cuadrado asignado a cada unidad de negocios. Deducción previa de consumos de unidades que cuenten con remarcadores. | 12 | Debe estar integrado con los subsistemas de Remuneraciones, Presupuesto, Bienes y Activos y centralizar los asientos en forma automática, al cierre del periodo. | 13 | Centralización automática de auxiliares contables. Se requiere también capacidad de Importación desde Auxiliares Contables externos. | 14 | Debe permitir la creación de un registro de proveedores y clientes con sus correspondientes datos, contra el cual se ingresen los documentos de compra y de venta (sistema de control de documentos) | 15 | Debe permitir llevar cuentas “T” por RUT de clientes y de proveedores. | 16 | Debe generar los libros contables exigibles incorporando las formalidades legales y reglamentarias vigentes en Chile. | 17 | Emitir los balances, estados de resultado, estado de flujo efectivo, consolidados y desagregados en forma paramétrica. | 18 | Emisión de estado de resultados por unidad de negocio o Centro de Responsabilidad, en periodos no cerrados | 19 | Generar balances y estados de resultado con los formatos propios de la contabilidad gubernamental, y ejecución presupuestaria de Ingresos y Gastos. | 20 | Generar los set de datos que deben incorporarse al SIFGE II, mediante alguna solución viable de comunicación o de integración. | 21 | Emisión de listados de movimientos por Rut, saldos de cuenta, deudas vencidas, deudas por vencer, cobranzas vencidas, cobranzas por vencer y otras que puedan ser generadas por el usuario. Detalle de transacciones por tipo. A partir de Libro Clientes y Libro Proveedores | 22 | Una vez cerrado un periodo contable, los registros deben ser inmodificables. Las modificaciones deben asentarse como una reversa contable hecha en el período en que es reconocida, en otras palabras, asientos de regularización y ajustes. | 23 | El Plan de Cuentas debe ser definido por el usuario en código y glosas, en 5 ó más niveles jerárquicos de 1 a 3 dígitos por cada nivel, en base al Plan de Cuentas establecido por el Sistema de Contabilidad Gubernamental. | 24 | La contabilidad debe ser ejecutada en la moneda local y extranjera, al igual que sus libros auxiliares. La utilización de decimales es seleccionada por el usuario. | 25 | La imputación contable debe ser ejecutada a nivel de Unidad de Negocio o Centro de Responsabilidad y el nivel de imputación de las cuentas debe ser seleccionado por el usuario. | 26 | Se deben definir unidades independientes de registro, que en definitiva se transformarán en Movimientos Contable (Departamentos, Servicios, Unidades, etc.), que pueden imputar transacciones para cualquier Unidad de Negocio o Centro de Responsabilidad. | 27 | Cualquier cuenta del Plan de Cuentas debe poder definirse como presupuestaria, y el sistema deberá crear diferentes planos para el registro de la formulación y ejecución de presupuestos por cuenta. | 28 | El sistema debe poder acotar o limitar los registros contables por Centro de Responsabilidad y/o Departamentos, a uno o un conjunto definido de tipos de documentos. | 29 | El maestro (Catálogo) de impuestos debe poder ser definido por el usuario, teniendo la libertad de definir un código, su glosa, su porcentaje, su aplicación como retenido o agregado, su prioridad de aplicación en caso de impuestos múltiples y la forma en que ellos van representados en los libros legales | 30 | El usuario debe poder definir libremente los Tipos de Comprobantes que usarán la foliación legal, no sólo limitándose a aquellos de Ingreso-Egreso-Traspaso, sino que debe poder hacer una definición más precisa para la gestión y auditoría contable. | 31 | Se deben definir plantillas con estructuras de asientos fijos para su utilización rápida en transacciones repetitivas de igual característica. | 32 | El sistema debe permitir la deshabilitación de cuentas y también su segregación para permitir su utilización sólo a ciertos libros auxiliares. | 33 | Asignar a las Cuentas de Gastos de Operación una lógica de distribución automática por Centros de Responsabilidad. | 34 | Siendo los libros auxiliares multimoneda, en la contabilidad se deben definir todas las monedas que serán utilizadas en el ejercicio. Su código, nombre, su tasa de cambio respecto de la moneda local, el número de decimales con que se la representará y sus cuentas contables de ajuste y de corrección monetaria. | 35 | Permitir realizar un asiento de ajuste de asientos generados por algún auxiliar. | 36 | Permitir el ingreso, a través de una interfaz con campos definibles por el usuario, de asientos provenientes de sistemas externos de remuneraciones. | 37 | Permitir la carga masiva, a través de una interfaz de campos definibles, de registros contables provenientes de algún sistema o aplicación externa. | 38 | Emitir todos los balances y libros legales (diario, mayor, comprobación y saldos, de ocho columnas, compra y ventas, balance clasificado, estado de resultados, flujo de efectivo, entre otros) de uso general exigidos por organismos externos, más aquellos que indican la norma y técnica contable. | 39 | De un período cerrado no se puede modificar nada, excepto vía una reversa contable hecha en el período siguiente que esté abierto. | 40 | Incluir guía de apoyo explicativa del procedimiento de cierre de Períodos Contables. | 41 | Mantener tablas históricas de movimientos y saldos, emitir reportes y hacer consultas de períodos o lapsos de tiempo retroactivos según criterio del usuario. | 42 | Emitir libro de honorarios conforme al registro contable del libro diario. | 43 | Reporte de la siguiente información: | | • Detalle de facturas centralizadas en Contabilidad. | | • Detalle de traspasos de Abastecimiento. | | • Detalle de centralización de proveedores en Presupuestos. | | • Detalle de facturas de bienes centralizadas en Contabilidad. | | • Capacidad para configurar reportes adicionales. | 44 | La conciliación bancaria debe contar con la opción de importar desde formato Excel la correspondiente cartola bancaria. | 45 | El registro contable del cliente, debe ser discriminado por el RUN, para personas naturales, y RUT para razones sociales. | 46 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. | 6.21.47.2.2 Presupuesto.

ADMINISTRACIÓN DE PRESUPUESTOS | N° | Funcionalidades | 1 | El sistema de Presupuestos debe estar integrado a la Contabilidad, compartir las cuentas definidas como presupuestarias, e integrarse con los libros auxiliares financieros, de administración de bienes y de RRHH que generan transacciones que afectan al presupuesto de Ingresos y Gastos. | 2 | Permitir el ingreso de metas y objetivos del establecimiento de salud en Programas y Proyectos que comprometen y utilizan recursos asignados a ellos y que son registrados en las cuentas definidas como presupuestarias. | 3 | Permitir la creación de un árbol jerárquico de 5 ó más niveles para definir los Programas y Proyectos presupuestarios. | 4 | Permitir la definición de múltiples fuentes de Presupuesto, y que cada fuente pueda, a su vez, ser definida en diferente moneda y unidad de fomento | 5 | Para cada fuente de Presupuesto permitir la definición de Programas, Subprogramas, Actividades y Tareas que conforman los proyectos. | 6 | El sistema debe permitir el ingreso de proyectos, asignación de presupuesto, y relacionarlos con las cuentas que llevarán las imputaciones. Todo bajo un Centro de Responsabilidad. | 7 | El sistema de Presupuesto debe contar con un ciclo de aprobación y rectificación de proyectos. .. | 8 | Permitir modificar el presupuesto de un proyecto sólo a través del proceso de ajustes, registrando el cambio y solicitando la aprobación correspondiente sea esta interna o externa. | 9 | Asociar cada Proyecto con una o más cuentas presupuestarias. | 10 | Si el presupuesto está en ejecución, el sistema de Presupuesto debe controlar la ejecución por gastos, preobligaciones, obligaciones o compromisos, devengos y pagos. | 11 | Permitir la formulación y ejecución de presupuestos multianuales. | 12 | Permitir múltiples consultas y reportes de formulación y de ejecución. | 13 | Permitir tener múltiples vistas, como por ejemplo, actividad y por tipo de programas. | 14 | Permitir ingresar perfiles calificados, por ejemplo autorizar sobregiros de cuentas presupuestarias en forma temporal o con límite de montos. | 15 | Consultas de ejecución presupuestaria con filtros de jerarquía de proyecto. Por ejemplo: fuente, programa, subprograma, actividad o tareas, o cualquier nivel de la jerarquía de los Centros de Responsabilidad. | 16 | Toda transacción que se genere en el módulo de presupuesto, debe tener a lo menos dos niveles de autorización o estado: DIGITADO y APROBADO | 17 | El presupuesto de gastos debe interactuar con el ingreso de diferentes Ordenes de Compra, las cuales cumplirán la función de rebajar y comprometer el presupuesto (Según normativa y procedimientos de DIPRES) | 18 | El flujo a través de Mercado Público es continuado una vez emitida en el Portal la correspondiente Orden de Compra, la cual es ingresada al sistema de abastecimiento, automáticamente deberá aparecer en el modulo de Presupuesto (en estado digitado) para ser aprobada y efectuar la ejecución presupuestaría al Sub Título, Ítem y Asignación respectivo. | 19 | Permitir el ingreso de las obligaciones, clasificando por grado de afectación presupuestaria. Lo cual corresponde a las instancias previas al devengamiento en la ejecución del presupuesto: Preafectación, Afectación; Compromiso Cierto y Compromiso Implícito. |

6.21.47.2.3 Tesorería, BANCOS COMERCIALES, Conciliación Bancaria Y Control De Documentos en Garantía

TESORERÍA | N° | Funcionalidades | | CONCEPTO: BANCOS COMERCIALES | 1 | Permitir el ingreso de cuentas bancarias para el establecimiento de salud registrado, con el número de cuenta, cuenta contable de transacciones, moneda de operación de esa cuenta y los indicadores correlativos de folio de cheques al comienzo de la operación y sus saldos de apertura. | 2 | Permitir el ingreso de entidades financieras bancarias u otras con las cuales operará el sistema, indicando las sucursales y ejecutivo responsable. | 3 | Vinculación de cada cuenta corriente con correlativos de cheques en uso | 4 | Vinculación de la cuenta corriente con la cuenta contable y unidad de negocios correspondiente | 5 | Validación del acreedor y la deuda imputada en la emisión del cheque o transferencia.
Control de documentos, remuneraciones, otros | 6 | Capacidad para efectuar traspaso de fondos entre cuentas corrientes (en caso de existir más de una) | 7 | Confección de libro auxiliar de bancos | 8 | Cierre de periodos mensuales y anuales. Arrastre de saldo de apertura. | 9 | Emisión de Cartas de Resguardo vinculado con Cuenta de Paciente | | CONCEPTO: EGRESOS | 10 | Definición de documentos y tipos de egresos.
Ej.: cheque, transferencia electrónica, efectivo, letra, pagare, cheque manual, otros medios de pago. | 11 | Permitir, desde el módulo de Tesorería, seleccionar la vía de pago de compromisos autorizados por el Administrador a través del módulo de Cuentas por Pagar (facturas, boletas y boletas de honorarios contabilizadas) | 12 | Definición de tipo o razón de pago. Ej.: factura, boleta, anticipo, fondo a rendir, caja chica, viático. | 13 | Permitir el ingreso por parámetros de diversos tipos de documentos. | 14 | Debe impedir la emisión de pagos si este no cuenta con autorización de la persona responsable
Debe haber una funcionalidad que permita la autorización de pagos en forma unitaria o masiva como en el caso de las remuneraciones) | 15 | Generación de egresos a proveedores a partir del registro de la cuenta del proveedor, vinculando una o mas facturas con el monto del cheque.
Vinculación con Cuentas por Pagar | 16 | Impedir la emisión de pagos por valores superiores al monto facturado | 17 | Permitir la generación de pagos parciales a proveedores | 18 | Permitir la generación de pagos de anticipos a proveedores | 19 | Permitir la selección de la cuenta bancaria para el pago, mostrando el saldo y el disponible a medida que se autorizan las emisiones de cheques. | 20 | Emisión de comprobantes contables de EGRESOS | 21 | Comprobación de la disponibilidad de saldos y presupuesto previo a la emisión de cheques | 22 | Permitir la transferencia electrónica de fondos y además la emisión de cheques manuales con captura en línea del número del cheque, cheques en formulario continuo (mecanizados) y manuales. Habilitar manualmente en el sistema la emisión de cheques. | 23 | Emitir nómina de pago para su envío al banco y ser pagada (vía Transfer). Generación de Archivos con Detalles Correspondientes. | 24 | Centralización contable y presupuestaria de los egresos. Transacción a Transacción. | 25 | Parametrización de glosas de cobros y gastos bancarios, vinculándolos con la codificación propia de cada banco. | 26 | Capacidad de anular documentos de pago por errores en el momento de su confección (Ejemplo: descuadre en la impresión de cheques) | 27 | Capacidad de anular documentos de pagos que ya hayan sido contabilizados, generando los asientos de reversas en las cuentas contables y presupuestarias (anula asiento contable y ejecución presupuestaria) | 28 | Permitir dar por pagado facturas capturadas en línea o a través de archivo plano de forma individual o masiva. | 29 | Capacidad para registrar revalidación de cheques caducados. | 30 | Capacidad para generar Cajas Chicas y Fondos a rendir | 31 | Mostrar una vista con los movimientos de egreso del módulo Tesorería, por cuenta corriente, por cuenta contable, por períodos, por código del Centro de Costo, por proyecto presupuestario. | | CONCEPTO: INGRESOS | 32 | Definición de documentos y tipos de ingresos.
Ej.: cheque, efectivo, letra, pagare, tarjeta de crédito y de débito, transferencia de fondos recibida. | 33 | Definición del concepto del ingreso.
Ejemplo: Garantía, prestaciones, venta activo, cobranzas | 34 | Emisión de comprobante de ingreso | 35 | Imputación del ingreso a la cuenta contable y presupuestaria correspondiente
Vinculación con cuentas por cobrar | 36 | Permitir el ingreso de documentos en garantía, vinculándolo con la transacción causante.
Ejemplo: Cuenta de pacientes y de proveedores. | 37 | Registro por el módulo de Tesorería de todos aquellos ingresos percibidos directamente a través de depósitos directos en el banco y otra forma de pago. | 38 | Emisión de detalles de depósitos | 39 | Permitir la selección de la cuenta bancaria para el pago, mostrando el saldo y el disponible | 40 | Permitir ingresar todos los parámetros con que el banco hace cargos o abonos en las cuentas corrientes, con el objeto de efectuar la conciliación bancaria en línea. | 41 | Capacidad de anular comprobantes de ingreso por errores en el momento de su confección (sin perder el correlativo único) | 42 | Capacidad de Anular un Ingreso y modificar movimientos de pago que ya hayan sido contabilizados y traspasados a los libros, generando todas las reversas contables, presupuestarias e inserción en los libros de banco y otros documentos legales impresos. (mientras el periodo contable no este cerrado) | 43 | Permitir el ingreso de cheques emitidos sin fecha
Ejemplo: cheque en garantía sin fecha. | 44 | Permitir el ingreso de cheques a fecha.
Ejemplo: Pago en cuotas con cheques a fecha (posfechados) guardados en cartera. | 45 | Relacionar los documentos en garantía con todas las referencias y características para su contabilización y control. | 46 | Permitir el ingreso de pagos parciales de cuentas por cobrar
Vinculación con cuenta de paciente y cuentas por cobrar. | 47 | Advertir de documentos en garantía por caducar | 48 | Advertir de cheques emitidos y no retirados, por caducar y caducados. | 49 | Permitir el calculo e imputación de intereses por mora | 50 | Permitir el ingreso por concepto de multas devengadas | | Conciliación bancaria | 51 | Conciliación bancaria automática de cada una de las cuentas, a partir de planillas Excel y/o archivo plano, según sistema disponible en cada banco. | 52 | Realizar la conciliación bancaria por cuenta mostrando el detalle de los conceptos no conciliados para su análisis, ajustes y contabilización. | 53 | El libro de bancos debe ser manejado en línea por cuenta de banco, por cuenta contable, por moneda y entre períodos, con la opción de impresión | 54 | Permitir ingresar ajustes a las cuentas bancarias producto del proceso de conciliación bancaria. | 55 | Emitir nóminas para depósito de cheques y otros documentos. | 56 | Para aquellos ingresos percibidos a través del banco, debe generarse los comprobantes de ingreso correspondiente y mover las cuentas contables y presupuestarias correspondientes. | 57 | Emisión de informe de cheques cobrados, emitidos y no cobrados, cheque emitidos no cobrados y caducados. Indicación de saldo comprometido y disponible. | 58 | Emisión de informe de cheques depositados y devueltos (protestos) | 59 | Emisión de informe de cheques emitidos, no cobrados y caducados por fecha. | 60 | Permitir el cierre de período y apertura automática del período siguiente (el proceso de cierre y apertura debe ser uno sólo, partiendo desde el módulo de contabilidad) | | Reportes | 61 | Disponibilidad de una herramienta configurada para emitir los informes rutinarios que se defina.
Ejemplo: informes diarios de disponibilidad de saldos de las cuentas de bancos. | | Cajas | 62 | Capacidad para generar cajas auxiliares | 63 | Capacidad para efectuar arqueo de cajas en cualquier momento. | 6.21.47.2.4 Costos. Es esencial determinar el costo real de las prestaciones de salud con sus respectivas unidades generadoras de productos. Para lo cual el módulo debe estar integrado con los módulos que corresponda de la FCE y ERP, contemplando las siguientes funcionalidades. GESTIÓN DE COSTOS | N° | Funcionalidades | 1 | Permita establecer los costos de producción, de los diferentes productos y servicios. | 2 | Permitir la parametrización de costos según productos y servicios | 3 | Permitir definir metodología e implementar costeo variable | 4 | Permitir definir los costos estándar de las prestaciones de salud y sus respectivas unidades generadoras de productos. | 5 | Determinar la estructura de costos de las actividades y sus respectivas unidades que permita explicar el resultado de los centros no productivos. | 6 | Determinar la estructura de costos de las prestaciones de salud y sus respectivas unidades que derive en su estado de resultado.
Se debe identificar, centro de costo, tipo de profesional que ejecuta, el tiempo asociado a los procedimientos, debe tener implícito las remuneraciones. | 7 | Que permita identificar los costos de Producción de las diferentes prestaciones médicas, productos y servicios, por Método Absorbente integrado, es decir que incluya todos los costos de la función productiva independientemente de su comportamiento fijo o variable. (Materiales, Insumo, Mano de Obra y los Costos Indirectos) Ej. 1,- que los gastos generales sean prorrateados por servicio, que cada centro de costo considere su activo fijo y lo deprecie, además considere la mano de obra por hora y minuto. | 8 | Que la mano de obra se separe por fondos fiscales y fondos propios, por tipos de contratos, por horas contratadas, por centro de costo, por tipo de profesionales, por asociación de procedimientos. | 9 | Permitir la parametrización completa del proceso de producción por servicio | 10 | Permitir identificar el rendimiento por Área o Servicio. | 11 | Parametrización completa del proceso de venta de servicios | 12 | Identificar los gastos asociados a los centros de costos, separados por consumo de los diferentes centros de responsabilidad, los cuales incluyen gastos generados por el paciente, respecto a la prestación otorgada y procedimientos asociados. | 13 | Permitir ver el consumo del servicio el cual tenga una concordancia respecto a las prestaciones y procedimientos efectuados, con el propósito de llevar el control de los consumos y gastos de los servicios versus la producción y facturación | 14 | Que el sistema entregue los gastos generados por cuentas corrientes y detallados por centro de costo. | 15 | Que genere un informe consolidado de los gastos y costos totales de las Unidades de Negocio o centros de costos. | 16 | Que genere un informe que identifique la productividad versus horas contratadas por centro de costo, esto permitirá identificar el tiempo de ocio del servicio. | 17 | Que el sistema aporte todos los informes necesarios que permitan confeccionar Tablas dinámicas para visualizar el Margen de Contribución, como varía el costo de acuerdo al nivel de producción en forma mensual. | 18 | Emitir informe respecto de las unidades de medida de las totalidad de las adquisiciones efectuadas por el HOSCAR. (Ej.: Kg., Frasco, centímetro cúbico, Cm.) | 19 | Informe de Honorarios médicos por centros de costo y por profesional en que se ejecutó el reemplazo del pago. | 6.21.47.2.5 Proveedores, Cuentas por Pagar y Administración de Contratos. Control detallado de todas las obligaciones de DISALCAR con sus proveedores, manejo de cuentas corrientes, devengo de gastos, autorización de pagos a Tesorería, registro e historial de proveedores, registro y control contable y presupuestario de contratos con terceros 6.21.47.2.6.1 Proveedores GESTIÓN DE PROVEEDORES | N° | Funcionalidades | 1 | Permitir el registro de proveedores | 2 | Relacionar a los proveedores según su clasificación, por rubro o actividad. | 3 | Permitir la actualización del registro de proveedores, permitiendo el bloqueo o desbloqueo de éste. | 4 | Permitir, en las cuentas por pagar, el ingreso de todo tipo de documentos a utilizar, por ejemplo, notas de débito o crédito, facturas, cheques, boletas, anticipos y ajustes, entre otros. | 5 | Para cada uno de los documentos ingresados se podrá definir toda la lógica de su tratamiento, contable y presupuestario. | 6 | Incorporar los libros contables legales (compra). | 7 | Las Cuentas por Pagar deben operar en múltiples moneda. | 8 | Las Cuentas por Pagar, además de registrar el devengo contable, deben poder generar las instancias presupuestarias de deuda exigible en el proyecto y Centro de Responsabilidad (debe registrar la ejecución presupuestaria y la clasificación respectiva según el fin del gasto o inversión) | 9 | Mostrar en línea la distribución contable propuesta por los parámetros del documento, la que puede ser aceptada o cambiada. (Distribución presupuestaria - contable con pre-ingreso de Orden de Compra) | 10 | Ingreso de notas de crédito y otros, donde toda reversa contable debe generar una reversa en la ejecución presupuestaria. | 11 | Generar en forma automática la autorización de Pago por Proveedor. | 12 | Cada autorización de pago debe contar con las referencias de cuentas que deben ser imputadas, Centros de Responsabilidad y los proyectos que son afectados. | 13 | Generada la autorización de pagos, contar con la posibilidad de reversar la operación antes de que se concrete. | 14 | El cierre mensual debe recalcular los saldos y limpiar los débitos y créditos de cada proveedor, preparando el próximo período (En el analítico del proveedor, debe mantenerse el historial de los débitos y créditos) | 15 | Libro de compras en línea, con la opción de impresión. | 16 | Historia de cuenta corriente del proveedor en línea. | | MAESTRO DE PROVEEDORES | 17 | Debe permitir estructurar y mantener en línea los Maestros de Proveedores, Contratistas, los cuales incorporen los antecedentes generales del cada uno. Ejemplo: Nombre, Rut, dirección, fono, fax, casilla, etc. | 18 | Debe desplegar datos al ingresar el Rut o nombre, sin tener que digitarlos nuevamente cuando se estén registrando, por ejemplo en una Orden de trabajo. | 19 | Debe permitir la creación de proveedores, contratistas realizando validaciones con los existentes en el maestro correspondiente, para evitar duplicidades de información. |

6.21.47.2.6.2 Gestión de Contratos Gestión de Contratos | N° | Funcionalidades | 1 | Permitir el registro de contratos con proveedores externos. | 2 | El módulo de Contratos debe estar en línea con el presupuesto para ejecutar la pre obligación y compromiso de los montos en el presupuesto, además del módulo de Tesorería para el registro de la eventual boleta de garantía. También debe contar con el registro de devolución y generar alertas por vencimiento. | 3 | Para cada contrato actualizado se debe ingresar su calendario de pagos en el tiempo y las garantías si corresponde. | 4 | La solución deberá permitir manejar los contratos tales como hora hombre con precio unitario por especialidad, en horario normal y de emergencia por un periodo de un año, estas se imputaran día a día en las respectivas Órdenes de Trabajo (OT). | 5 | El sistema deberá entrega en línea el saldo del contrato por cada una de las especialidades además del monto total. | 6 | El sistema deberá incluir los contratos de servicio de distinto tipo con imputación de costos en la OT. | 7 | La solución deberá permitir administrar los contratos de servicio asociados distintas áreas de DISALCAR (Mantenimiento, Activo Fijo, Reparaciones, etc.) | 8 | Debe permitir generar y mantener un catastro o inventario de elementos (activos), el cual debe permitir relacionar con los contratos, para su posterior administración. Estas listas se deben actualizar automáticamente cuando se actualice el catalogo de operaciones. | 9 | Permitir extraer información en línea de otros sistemas, a través de parámetros de búsqueda (interoperabilidad). | 10 | La solución deberá permitir generar los estados de pago de los contratos de obras. | 11 | La solución deberá permitir generar modificaciones de trabajos en ejecución y el workflow de aprobaciones respectivo. | 12 | El sistema deberá entrega en línea el saldo del contrato por cada una de las especialidades además del monto total. | 13 | El sistema deberá incluir los contratos con la imputación de costos respectivos. | 14 | Permitir clasificar y agrupar las operaciones contratadas según categorías. | 15 | Permitir asociar fichas técnicas configurables a Activos y utilizar sus campos como criterios de búsqueda. | 16 | Permitir asociar cualquier documento al contrato. Ej. fotos, videos, documentos, planos, etc. | 17 | Facilidad para extraer información a través de reportes estándares o diseñados por el usuario. | 18 | La solución deberá permitir mantener un control de avance financiero y físico por cada contrato de obra en ejecución, que permita hacer una buena gestión de éstos. | 19 | Flujo administrativo (Workflow) de aprobaciones con respecto a los contratos podrán ser definidos por el usuario autorizado con herramientas estándar del sistema. | 20 | Se puede asignar la responsabilidad de aprobación a un rol en vez de a una persona. | 21 | Notificación por E-mail | 22 | Se puede asociar archivos de documentos almacenados en disco o red LAN considerando todos los aspectos de seguridad. | 23 | Se pueden asociar direcciones URL de Internet considerando todos los aspectos de seguridad. | 24 | El sistema con la información administrada debe ser capaz de generar cualquier indicador de gestión asociado que permita ir tomando medidas de gestión correctiva. | 25 | El sistema enviará reportes por e-mail | 26 | Capacidad de Entregar resultados de Reportes en Formato PDF (Adobe) | 27 | Capacidad de Exportar resultados a Excel | 28 | Reportes con capacidad gráfica | 29 | Capacidad para realizar búsqueda en los resultados de un reporte | 30 | Reportes con capacidad de hipervínculo con otros reportes de mayor detalle de análisis | 31 | Reportes programados (programado para ejecutarse en forma programada y recurrente). Resultados pueden ser enviados por E-mail a usuarios. |

6.21.47.2.6 Ingresos, Facturación, Cuentas por Cobrar, Rendiciones y Caja Cuentas por Cobrar tiene por función la generación y el registro de todos los ingresos que tenga DISALCAR y sus Centros de Responsabilidad, tanto de ingresos propios, aportes externos y/o deudores internos, lo cual incluye el registro de las instancias presupuestarias relacionadas con los ingresos, devengos y percepción. Caja pago directo de compromisos por caja y recaudar o percibir ingresos de deudores mediante diferentes documentos y monedas. Apertura, cierre y arqueo de caja para cajas múltiples.

6.21.47.2.7.3 Ingresos Ingresos : General | N° | Funcionalidades | 1 | Permitir la creación y habilitación del establecimiento de salud para operar en cuentas por cobrar (deuda exigible, módulo de descuentos, libro de ventas, documentos en cartera, cobranza judicial, prefacturas, cuentas corrientes por clientes (estadías), cheques protestados, otros ingresos, anticipos de terceros, C x C, Recuperación de Préstamos, Deudas años anteriores. | 2 | Ingresar el año y mes de inicio de operación y los diferentes tipos de comprobantes, los cuales serán entregados en su oportunidad por el establecimiento de salud. | 3 | Indicar las cuentas de Renegociación de Deudas, de otros depositantes en caso de recibir pagos por montos no generados, cuentas de resultado, de intereses y de ingresos varios para registro (por ejemplo: cheques a fecha del paciente o tercero). | 4 | Generar bitácora de deuda del paciente con la forma de pago y las cuotas pendientes de cobro, y su historial desde su ingreso hasta que cancela. | 5 | Ingresar una clasificación de Clientes-Deudores para control y gestión por tipo de deudor. | 6 | Permitir bloquear o desbloquear a un cliente-deudor de forma manual y/o automática. | 7 | Permitir definir usuarios de todos los tipos de documentos, por ejemplo: débito o crédito, facturas, prefacturas, guías de despacho, órdenes de atención, boletas exentas de impuesto, bonos, ajustes contables, cheques, cheques post fechados, remesas, fondos por rendir, otros ingresos, pagarés, aranceles, matrículas, fondos de terceros, tarjetas de crédito y otros. | 8 | Permitir realizar auditorías por emisión de documentos; indicar el motivo de la situación como medida de control. | 9 | Permitir Definir a cada documento toda la lógica de su tratamiento contable y presupuestario. Definiendo las cuentas de registro contable y presupuestario que son afectadas y los libros legales correspondientes. | 11 | Permitir definir el rango de foliación de comprobantes generados por el sistema de Cuentas por Cobrar, por tipo de documento, de tal forma de facilitar el posterior análisis de transacciones por folio. | 12 | Permitir la definición, clasificación, tipificación y tarifado de servicios que el establecimiento de salud, venda o provea a terceros y que originen registros de ingresos en el sistema de Cuentas por Cobrar. | 13 | Permitir retarificar y/u homologar por categoría o previsión las ventas a clientes, detallando código, número de orden, fecha, monto, cantidad, tarifa, centros de costo, identificación del cliente, tipo de grupo de cobro. | 14 | Generar solicitudes de notas de crédito, débito y refacturación a través de un registro anterior o archivos magnéticos, según estructuras definidas. | 15 | Permitir exportar los cargos de ventas ambulatorias como hospitalizados por parámetros según el proceso de cierre semanal, mensual, diario, por tipos de clientes, otros. | 16 | Permitir generar facturación electrónica (SII) masiva, individual y de otro tipo, con bonificaciones según categorías o convenios de clientes. | 17 | Generar informes de facturación por períodos, situación de prefacturas, estadías de pacientes hospitalizados y de alta. | 18 | Que permita asociar la facturación al ingreso del paciente y su estadía. | 19 | Que permita emitir documentos de despacho y su control, considerando, fecha de despacho y fecha de posible pago. | 20 | Que permita parametrizar tipos de ingresos, para generar reportes y cierres. | 21 | Que permita realizar búsqueda por código o descripción y listar códigos de prestaciones facturas y por parámetros. | 22 | Relación entre el servicio definido con el o los Centros de Responsabilidad y con los proyectos presupuestarios a los que correspondan, indicando también las cuentas de imputación, de tal forma que el registro de un ingreso asociado a un servicio genere en forma automática el asiento contable y la imputación presupuestaria que corresponda. | 23 | Ingreso y registro de movimientos que generan débitos o créditos en Cuentas por Cobrar. | 24 | El ingreso de movimientos de débito debe recuperar el Centro de Responsabilidad, el código del Cliente-Deudor, la fecha, moneda de la transacción, tipo de documento, impuestos relacionados, fechas de registro y de vencimiento, generando en línea la distribución contable. | 25 | Al grabar el documento se debe generar automáticamente el asiento que va a la contabilidad en estado pendiente para revisión y posterior contabilización. | 26 | Un documento en estado pendiente puede ser anulado o modificado. Si ha sido contabilizado se debe reversar. Por ejemplo, facturas, posfacturas y otros documentos que se indique. | 27 | La contabilización de un documento debe traspasar los registros contables a los balances y libros legales. | 28 | Cuando la moneda de origen no es la local el sistema debe generar en línea el monto de registro en moneda local. | 29 | Contar con el ingreso y registro de movimientos de crédito en Cuentas por Cobrar, con el fin de anular o reversar movimientos de débito. | 30 | Crear módulo de crédito que permita calcular: deuda capital, cantidad de cuotas, reajustes, intereses de mora, gastos de cobranza y amortización de deuda capital, saldos, otros. | 31 | Permitir el ingreso y aprobación de prórrogas de pago de documentos en cartera que estén vencidos. | 32 | Permitir la renegociación de deudas, solicitud de renegociación, aprobación, cancelación de la deuda anterior y generar una nueva deuda con las nuevas condiciones, generando en línea los movimientos contables y presupuestarios que afectan esta operación. | 33 | Simular los valores resultantes de una solicitud de renegociación. | 34 | Mantener en línea el historial completo del Cliente-Deudor, mostrando por cliente, sus montos deudores y los saldos por cada documento, forma de abono o pagos y los tipos de documentos de pago con que fueron registrados. | 35 | Administrar la cobranza devuelta, registrando las objeciones y/o reparos, generando la nota de crédito para limpiar la deuda exigible, dejando la cobranza en estado de análisis para refacturar si corresponde. | 36 | Emisión de reportes, exportables a planilla Excel de los descuentos formulados y efectuados por número de RUN. | 37 | Sistema de descuento que permita efectuar cargos de forma tanto individual como masiva. |

6.21.47.2.7.4 Manejo de Fondos y Anticipo de Proveedores Ingresos: Manejo de Fondos y Anticipo de Proveedores | N° | Funcionalidades | 1 | El sistema debe tener toda la funcionalidad para el manejo de fondos, ingreso de solicitudes de fondos (Fijos o Por Rendir), su aprobación y contabilización, y registro presupuestario en caso que corresponda. | 2 | El sistema debe ser capaz de capturar todos los datos del solicitante y del beneficiario de fondos, el tipo de documento que será utilizado, moneda, centro de responsabilidad, proyecto y otros. | 3 | El sistema debe manejar todos los fondos como una cuenta por cobrar por parte del girador o el beneficiario del fondo, y en ese contexto se deben generar las transacciones contables y presupuestarias que corresponda. | 4 | La rendición de un fondo debe mostrar el monto asignado y registrar el reintegro, dejando registrado, si existe, el saldo por rendir. | 5 | La rendición de un fondo debe registrar el Centro de Responsabilidad, Proyecto Presupuestario y, según el tipo de documentos, debe mostrar la distribución contable del asiento que se ejecuta con la rendición. Reintegro del fondo no ocupado en su totalidad. | 6 | Listado detallado del estado de las aprobaciones y rendiciones de fondos en el sistema en forma global o por beneficiario deudor del fondo. | 7 | El anticipo de proveedores debe tener la misma lógica de operación que la de los fondos. | 8 | El sistema debe permitir la aprobación de los anticipos y captura del Centro de Responsabilidad y Proyecto, en caso que eso corresponda. | | CONSULTAS | 9 | Permitir consultas en línea sobre movimientos de Cuentas por Cobrar que afectan a Clientes-Deudores. | 10 | Libro de Ventas en línea con la opción de imprimir por año, mes, día. | 11 | Mostrar en diferente columna los montos afectos y los exentos para poder definir y calcular, de ser necesario, la proporcionalidad de impuesto al valor agregado (IVA), dado que esta Institución esta exenta de IVA de Venta, el IVA de las Compras debe ser considerado como parte del costo. | 12 | Consulta en línea del historial del Cliente-Deudor. | 13 | Consulta en línea del historial de Rendiciones de Fondos. | 14 | Incluir múltiples reportes operacionales orientados a la gestión de cuentas corrientes de Clientes-Deudores | 15 | Incluir Reportes de ingresos devengados y referencias de operaciones de las Cuentas por Cobrar. | 16 | Generar en línea todos los asientos contables y presupuestarios asociados al movimiento y los documentos que están siendo ingresados. (Ejecución Presupuestaria) |

6.21.47.2.7.5 GESTIÓN DE Caja Ingresos: Gestión de Caja | N° | Funcionalidades | 1 | Permite ingresar todos los documentos que operarán en la función de caja. | 2 | Permite el ingreso de la definición de cajas, usuario responsable, tipo de asiento contable que realiza y moneda de operación. La caja de moneda extranjera sólo podrá mover documentos en esa moneda. | 3 | Facilitar la apertura de caja registrando el usuario y momento de la apertura y el cierre de la misma. | 4 | La recaudación por caja debe recoger todas las referencias de los documentos que se están pagando y también capturar los documentos y sus referencias con que se está recaudando. | 5 | Clasificar la “liquidez” del documento recibido (efectivo, por ejemplo, tiene la más alta liquidez, pudiendo luego ordenar el arqueo por liquidez de lo recaudado). | 6 | Cargar en línea intereses por mora en la recaudación de ingresos. Permitir definir el tipo de clientes asociados al cobro de reajustes y devengos. | 7 | Anular movimientos ejecutados por el sistema de cajas antes de su cierre y antes de que hayan afectado la cuenta corriente del deudor, con lo cual se reversan todos los movimientos que hubiesen sido generados, previa aprobación y autorización del Supervisor. | 8 | Reversar contablemente movimientos de caja después que esta haya sido cerrada y cuando ya hubiese afectado la cuenta corriente del deudor y los saldos en las cuentas de caja y banco. En este caso el sistema reversa todos los movimientos que afectan la caja, al cliente, el banco y los libros. (Debe llamarse al ID de contabilización inicial para efectuar reversa.) | 9 | Arqueo de Caja para todos y cada uno de los diferentes documentos con que se ha recaudado. Presentar un resumen del arqueo por tipo de documento en moneda local y moneda de origen, permitiendo identificar claramente el monto a la Apertura y el Saldo al Cierre de la Caja. | 10 | Cierre de Caja por usuario responsable una vez que se ha efectuado el arqueo. | 11 | Reportes de la actividad de la caja, por cliente o deudor, por tipo de movimiento, por tipo de documento, moneda y usuario, Por Tipo de Producción (Venta). | 12 | La caja genera automáticamente los asientos contables y los envía a la contabilidad con las referencias, y también ejecuta las instancias presupuestarias que correspondan según sea percepción de ingreso o pago de gasto. |

6.21.47.2.7.6 Facturación * FACTURACIÓN | N° | Funcionalidades | 1 | Capacidad de Facturar por Tipo de Prestación, Grupo de Paciente, y otros | 2 | Capacidad de Generar Archivo de Traspaso a DIPRECA, para carga manual WEB | 3 | Capacidad de Efectuar Abonos Parciales de Pacientes a la Cuenta Respectiva | 4 | Permitir la Consulta Online de Detalles por Facturar de Pacientes para Revisión. | 5 | Capacidad de Imprimir Facturas Tributarias asociadas al Cobro de Pacientes Particulares, Actos de Servicio de las Instituciones, y otros. | 6 | Capacidad de Calcular y Emitir Cobros en base a Cargo Imponente (Gendarmería e Investigaciones) | 7 | Habilidad para distinguir claramente las categorías de Paciente, Institución Aseguradora, Institución Pagadora (Dipreca) | 8 | Permitir la consulta e impresión en cualquier momento de un estado de cuenta (Prefactura), correspondiente a un paciente hospitalizado o de cualquier otro tipo de cliente. |

6.21.47.2 Abastecimiento – Bodegas – Existencia – Activos 6.21.47.3.7 Abastecimiento y Gestión de Compras Permite desarrollar en línea todo el ciclo de abastecimiento normalmente utilizado en la administración pública y grandes empresas privadas. ABASTECIMIENTO | N° | Funcionalidades | 1 | Permitir la operación simultánea de múltiples Unidades de Negocio y/o Centros de Costo | 2 | Proceso de compras en su mayoría centralizado | 3 | Excepcionalmente, para ciertos requerimientos (Ítem, artículos, o familias de productos), que no es posible o resulta ineficiente mantener stock, se deberá considerar el despacho periódico descentralizado de pedidos a unidades usuarias (Centros de Costo) por parte de los proveedores, previas aprobación y control de consumos y facturación por parte de Abastecimiento. Lo anterior facilitará la implementación de un sistema Just In Time que optimice la utilización de recursos. | 4 | Captura de datos de Proveedores en línea (por ejemplo, contratos, otros) y directamente desde el Sistema de Cuentas por Pagar (por ejemplo, deuda vencida, disponibilidad de crédito, etc.). | 5 | Solicitudes internas de compras, compras directas con o sin licitación, e ingreso de planes de compra, deben referenciar artículos que existan en el maestro general de artículos que utiliza el sistema de Abastecimiento (Catálogo). | 6 | Creación descentralizada de solicitudes internas de requerimientos de compras de Bienes y Servicios. | | Los Bienes pueden ser: | | • Bienes de Cambio: Activados a su ingreso a existencias y llevados a gasto al momento de su venta. | | • Bienes de Consumo: Activados a su ingreso a existencias y llevados a gasto por cada Unidad de Negocio y/o Centro de Costo a su consumo. | | • Bienes del Activo Fijo: Los Bienes de Uso se deprecian y revalorizan y los Bienes de Consumo no se deprecian ni revalorizan. | 7 | En línea con lo asignado en presupuesto; deberá afectar a cada Centro de Costo, por lo que el sistema debe exigir, para cada ingreso de requerimientos, el código del Centro de Costo, proyecto o programa (definir) presupuestario, a objeto de ser cargado el pedido. La verificación de la disponibilidad presupuestaria será en línea. | 8 | Disponibilidad presupuestaria aceptada, autorizar la solicitud por pantalla. | 9 | Para los requerimientos internos aprobados, el sistema debe emitir la(s) Solicitud(es) de Cotización, capturando los eventuales oferentes desde el sistema de Proveedores. Por ejemplo, eventos inusuales como solicitudes de artículos a pedidos, entre otros. | 10 | Emitir cotizaciones por código de proveedor (por ejemplo, razón social, RUT, dirección teléfono, etc.), considerando última cotización vigente (por ejemplo, rango de tiempo, fecha). (Por responsabilidad administrativa el sistema deberá guardar cotizaciones históricas hasta 5 años). | 11 | En compras de cualquier modalidad enviar las solicitudes de cotización a los proveedores vía fax, correo electrónico u otro medio disponible, además del servicio Mercado Público, con el traspaso del requerimiento al portal y guardar la referencia del requerimiento interno que fue pre obligado o pre aprobado. | 12 | El flujo a través de Mercado Público es continuado una vez emitida en el Portal la correspondiente Orden de Compra, la cual es ingresada al sistema, que la parea con la referencia dejando abierta la ejecución de la Obligación o Compromiso Presupuestario. | 13 | Si no están disponibles los servicios del portal Mercado Público, el sistema debe permitir el ingreso de las cotizaciones, actualizar los datos y precios de los proveedores y presentar un “Cuadro Comparativo” con hasta seis cotizaciones y una sugerencia de adjudicación por mejor precio y calidad que puede ser modificada por el usuario, según fundamento técnico. | 14 | El sistema debe permitir seleccionar la o las mejores ofertas de uno o más proveedores, adjudicar la compra previamente obligada o en línea, y emitir cuadros comparativos, Orden de Compra, y Actas de Adjudicación cuando sea requerido. | 15 | Permitir la generación de Órdenes de Compra sin efectuar el proceso de adjudicación (tal como compras de urgencia). | 16 | En la generación de Órdenes de Compra sin efectuar el proceso de adjudicación permitir la consulta al presupuesto, la autorización y el registro simultáneo de la pre obligación y el compromiso. | 17 | Permitir el ajuste a la Orden de Compra en forma posterior a su emisión, hasta un cierto monto, si este supera el monto mínimo autorizado solicitar una aprobación. | 18 | Permitir llevar el registro histórico y el estado de cada Orden de Compra emitida. | 19 | Permitir mantener la Orden de Compra abierta, ante una recepción parcial o no cumplida de mercaderías en bodega (dependerá de los estados que se configuren). | 20 | La valorización de los artículos se recibe del archivo maestro (catálogo), en donde se guarda los últimos valores pasados de compras de los artículos, mostrando el valor de la última recepción, cantidad y diferencia porcentual entre la última compra y la nueva. El sistema deberá permitir la valorización de las salidas y existencias finales de acuerdo los métodos FIFO (First Input – First Output), LIFO (Last Input – First Output), PPP (Precio Promedio Ponderado) u otro de acuerdo a políticas establecidas por la DISALCAR. | 21 | Ingreso de Órdenes de Compra masivas desde, por ejemplo, programas de compra anual, mensual o quincenal entre otros. | 22 | Parametrizar plazos de entrega, prioridades, compras a proveedores alternativos, etc., a objeto de permitir la evaluación administrativa de proveedores por estos conceptos (cumplimiento de contratos). | 23 | Emitir Solicitudes de Compra sin registro de presupuesto en situaciones de urgencias según demanda asistencial (los recursos que se utilizarán no son sujetos a control presupuestarios). | 24 | Consulta de Solicitudes y de Órdenes de Compra emitidas o en cualquier estado. | 25 | Anular solicitudes internas o requerimientos no procesados como Órdenes de Compra u otros. Cuando estas solicitudes hayan sido aprobadas y ejecutadas, se podrá reversar la transacción correspondiente a la pre obligación y al presupuesto. | 26 | Anular Órdenes de Compra emitidas pero no enviadas al Proveedor. Reversar la pre obligación y también el compromiso. | 27 | “Cerrar” una Orden de Compra de la cual se haya recibido sólo una parcialidad | 28 | Cierre de mes o año, de tal forma que se actualicen los períodos de operación, además de alertas mensuales indicando las Órdenes de Compra pendientes. | 29 | Al término del período contable las Órdenes de Compra pendientes de cumplimiento total o parcial automáticamente deben cerrarse y abrirse en el nuevo período. | 30 | Permitir el ingreso oportuno de elementos que no existan en el maestro de artículos, con el objeto de facilitar su dispensación, uso y cobro. Posteriormente, su ingreso al maestro será regularizado (codificado y clasificado). | 31 | El Sistema debe permitir el Ingreso Electrónico (vía importación o automática) de documentos EDI (estándar EDIFACT/96) y/o XML (versión 2007), tipo GUÍA DE DESPACHO (DESADV) o FACTURA (INVOIC). | 32 | Permitiendo recibir en BODEGA contra la información recibida en documento electrónicos de despacho. |

GESTIÓN COMPRAS | N° | Funcionalidades | | GENERALES | 1 | El módulo deberá permitir el control y monitoreo de todas las operaciones de compras de manera eficiente. Contribuirá en su diseño a dar soluciones que ayuden en los procesos de requisición de materiales, pedidos de cotización, órdenes de compra y acuerdos de compra, de forma rápida y eficiente reduciendo el flujo de documentos, costos administrativos y permitiendo asimismo a los compradores focalizar su tarea en actividades estratégicas tales como negociación de contratos, desarrollo y calificación de proveedores, y análisis de los costos. | 2 | La Aplicación deberá proveer herramientas de reportes y control que colaboren al monitoreo de los costos de aprovisionamiento, calidad y performance en la compra y entrega de productos. | 3 | Debe poder gestionar las compras de diversos ítems: | | -productos (insumos y medicamentos) | | -Repuestos. | | -productos e insumos catalogados y no catalogados. | | -Activo fijo (equipos)
-Servicios | 4 | Debe efectuar la contabilización automática en la recepción de productos e insumos, equipos y repuestos, recepción con certificación y actualización de inventarios. | 5 | Debe permitir la configuración de diversos circuitos de documentos y procesos: | | ·Compras sin requisición. | | ·Orden de Compras abiertas. | | ·Compras de importación. | | ·Compras menores. | | ·Compras en consignación. | 6 | Las compras sin requisición son solicitadas verbalmente y en sistema deberá quedar registrado todo el proceso de compra para el pago de factura. | 7 | Las compras abiertas son los contratos de productos generados en la unidad de abastecimiento, por un periodo de dos años, con precios acordado en la licitación y sus reajustes correspondientes, por lo cual los precios deben ser parametrizables para este tipo de compra. Los productos solicitados al proveedor son mediante orden de entrega. | 8 | Las compras de importación corresponden a los productos adquiridos en el extranjero, proceso que debe estar soportado completamente a través del Sistema. | 9 | Los productos en consignación serán administrados por el departamento de Abastecimiento. La definición de ítems para consignación se realizará por decisión de este departamento o por un requerimiento del usuario. Los ítems en consignación se deberán registrar en el catálogo de productos. | 10 | El registro de los productos para consignación en el catálogo de productos se realizará de la misma forma que un ítem de stock, asimismo el consumo de este material será cargado a una Unidad de Negocio y/o centro de costo. En esta modalidad de adquisición de productos contempla que el material debe permanecer en las bodegas y el pago es mensual de acuerdo a los consumos realizados durante el mes. | 11 | Los ítems de consignación deben ser factibles de administrarse en función del contrato con el proveedor. | 12 | Las compras menores corresponden a productos adquiridos en comercio local, estos productos pueden o no estar en el maestro de productos, el proceso deberá considerar la solicitud de compra menor generado por área responsable para su aprobación. | 13 | Debe poder calcular los tiempos de demora del proceso de compras, desde el requerimiento hasta la llegada de la mercadería, incluyendo todos los procesos parciales (ingreso Pedido de Material (PM), aprobaciones, cotizaciones, Orden de Compra) | 14 | Debe permitir modificar maestros de productos, medicamentos e insumos de acuerdo a definiciones de perfiles de usuario. | | ADMINISTRACIÓN DE PROVEEDORES | 15 | El Registro o Maestro de Proveedores deberá contener campos como: nombre, dirección, teléfono, fax, e-mail, persona contacto, líneas de productos que fabrica o comercializa, referencias bancarias, referencias comerciales, entre otros. | 16 | Debe poder inhabilitar a proveedores con mala calificación | 17 | Debe permitir la calificación de proveedores según distintos conceptos. | 18 | Debe permitir la categorización de proveedores por rubro. Clasificación de los proveedores que permita identificar si se trata de: proveedor de medicamentos, equipos, productos, repuestos, servicios u otros. | 19 | Debe otorgar información de tiempos de entrega por proveedor y pedido, desde el envío de la Orden de Compra (O.C) hasta la recepción de la mercadería. | 20 | Debe permitir la configuración libre de atributos de proveedores | 21 | Debe otorgar información para módulo de pagos y presupuestos | 22 | Debe permitir la homologación de proveedores de acuerdo a certificación ISO 9001. | 23 | Identificación de proveedores locales y nacionales, con o sin movimiento. | | REQUERIMIENTOS DE COMPRAS | 24 | Debe permitir el ingreso de requerimientos en línea para ítems catalogados y no catalogados: | | ·Emisión de requerimientos automáticos al alcanzar el punto de pedido | | ·Gestión de requerimientos provenientes de las diferentes áreas usuarias. | 25 | Administración de distintos estados por requerimiento de Compras: | | ·Pendiente de autorización. | | ·Aprobado. | | ·En proceso de compra. | | ·Emitida la Orden de Compra. | | ·Recepcionado parcial o total. | | ·Anulado. | 26 | Debe exigir el campo Unidad de Negocio y/o “centro de costo emisor” y destino en el requerimiento de compra, el que luego debe ser asignado automáticamente al momento de generarse la orden de compra. | 27 | Debe permitir la consulta del estado de los requerimientos, permitida tanto para el usuario responsable de la emisión, como para las áreas de compras y control. | 28 | Debe otorgar permisos de anulación de un requerimiento en forma manual por ítem y total. | 29 | Debe poder establecer niveles de prioridad por requerimiento (normal y urgente). | 30 | Debe brindar la posibilidad de realizar requerimientos recurrentes. | 31 | Debe brindar funciones de control de stock y presupuesto según configuración en cada caso. | 32 | Debe permitir de acuerdo a perfiles de usuarios la autorización de las requisiciones basado en el monto. | 33 | Debe permitir adjuntar planos, documentos en la solicitud de cotización. | 34 | Debe tener integración con la interfaz basada en estándar XcBL 4.0 de MERCADO PÚBLICO , permitiendo ingresar en forma electrónica la Órdenes Generadas y Aprobadas a la Plataforma MERCADO PÚBLICO S. | | GESTIÓN DE COMPRAS | 34 | Record histórico de compras, desde las requisiciones, cotizaciones, hasta las Órdenes de Compra (a quién se cotizó, todas las fechas, detalle de todos los movimientos efectuados con relación a una requisición, cuadro selección de proveedores, hoja entrada de material). Esta información debe poder ser filtrada por: proveedor, Orden de Compra (OC), requisición, ítem, comprador. | 35 | Debe consolidar los requerimientos de compra en forma manual y automática por rubro, ítem y prioridad. | 36 | Debe generar solicitudes de cotizaciones en forma automática cuando se llegue a un mínimo predefinido de ÍTEMS, en los ÍTEMS y RUBROS definidos previamente. | 37 | Debe otorgar la facilidad de gestionar las funciones de compra desde una única pantalla. | | SOLICITUD DE COTIZACIONES | 38 | Envío electrónico de solicitudes de cotización (RFQ) a proveedores. | 39 | Opción de impresión de la cotización en papel. | 40 | Formatos de requisiciones, cotizaciones y Órdenes de Compra, impresos desde el sistema. | 41 | Opción de transmitir electrónicamente al proveedor sólo determinada información de las cotizaciones. (Ejemplo: no enviar precios, consumos, entre otros), en formatos estandarizados XML o EDI (EDIFACT). | 42 | Proveedores deben vincularse a grupos y clases de productos (relación ítem-proveedor). | 43 | Formato predeterminado de solicitud de cotización (que incluya campos como: descripción del ítem, cantidad solicitada, precio, condiciones de entrega, condiciones de pago, ofertas alternativas). | 44 | Formatos predeterminados para uso en negociaciones: invitación, formato de petición de oferta, cuadro comparativo. | 45 | Ingreso de información por parte del proveedor a los formatos electrónicos (archivos planos) pre-determinados para solicitud de cotización de proveedores. Además, después de recibir estos archivos del proveedor el sistema deberá cargar dicha información. | 46 | El sistema debe permitir el manejo de productos alternativos sugeridos por el proveedor en la cotización. | 47 | Información pre-determinada de tarifas de fletes (marítimos, aéreos, terrestre, courrier). | | ADMINISTRACIÓN DE COTIZACIONES | 48 | Debe permitir la administración de cotizaciones en forma manual y automática. | 49 | Debe permitir la Administración de cotizaciones de varias requisiciones de un mismo rubro. | 50 | Debe gestionar las cotizaciones recibidas de los proveedores:
·Manejo de fecha de vencimiento de las cotizaciones.
·Sistema de ingreso de las respuestas de los proveedores a medida que se reciban.
·Debe realizar comparaciones a nivel de ítem y a nivel de totales. | 51 | Generar solicitudes y respuestas de cotizaciones vía Internet y por fax Server. | 52 | Permitir cotizaciones a proveedores que operen con un portal de comercio electrónico (market place, Mercado Público) y proveedores fuera del portal (market place), en el cuadro comparativo se deberá considerar ambos grupos de proveedores. | 53 | Generación automática del cuadro comparativo de ofertas a partir del ingreso de ofertas, ya sea por medio electrónico o manual (precios, términos de entrega, términos de pago, descuentos, sobrecostos). Considerar una escala de pesos específicos para evaluación de variables cualitativas y cuantitativas (precio, tiempo de entrega, calidad, garantía, entre otras). | 54 | Debe poder Identificar por la planilla comparativa la mejor oferta en cuanto a:
·Precio cotizado
·Plazo de entrega
·Comparar las cotizaciones en diferentes monedas
·El monto total deberá incluir embalaje y gastos de exportación | 55 | Debe permitir la realización de compras a proveedores en forma directa hasta la generación de la Orden de Compra, la cual deberá ser autorizada de acuerdo al perfil del usuario. | 56 | Debe permitir la adjudicación de todos los ítems a un proveedor o varios proveedores. Debe permitir la adjudicación de un ítem a más de un proveedor. | 57 | El requerimiento deberá indicar al usuario el estado en que se encuentra en las diferentes etapas del proceso de cotización. | | ÓRDENES DE COMPRA | 58 | La aplicación permitirá a los compradores crear las Órdenes de Compra de la manera más rápida y eficiente posible, esto implicará que su generación esté apoyada por información predeterminada, enlace con el convenio acordado y con la información del proveedor. | 59 | Después de la decisión de compra, basándose en el análisis del cuadro comparativo de ofertas, poder “marcar” la relación de correspondencia de ítem(s)/proveedor(es), para que se pueda generar automáticamente la(s) Orden(s) de Compra (O.C). | 60 | Inclusión de costos adicionales en Orden de Compra (flete interno, flete aéreo, flete marítimo, embalaje, seguros, etc.). | 61 | Debe asignar en forma automática un número correlativo a las Órdenes de Compra emitidas. | 62 | Aplicación de descuentos en la Orden de Compra. | 63 | Debe poder generar Órdenes de Compra con múltiples fechas de entrega y con más de un lugar de entrega. | 64 | Debe permitir asociar un requerimiento del usuario a más de una Orden de Compra y a la factura del proveedor. | 65 | Envío de Orden de Compra automatizada, según puntos de reorden, con referencia a acuerdos de compra con proveedores. | 66 | Debe brindar la posibilidad de definir distintos niveles de autorización de una Orden de Compra en función del monto involucrado. Debe permitir autorizar electrónicamente los requerimientos de compra. | 67 | Anulación de ítems o total de Orden de Compra de acuerdo a los perfiles de usuarios. | 68 | Debe permitir asociar una Orden de Compra a más de una factura del proveedor. | 69 | Debe valorizar la Orden de Compra en forma automática según cotización aceptada. | 70 | Debe permitir el manejo de vigencia y generación multimoneda de las Órdenes de Compra (En pesos, dólares, unidades de fomento, etc.) | 71 | Debe permitir convertir los montos de las Órdenes de Compra, ya sea en pesos, dólares u otra moneda y mantener un histórico con dicha información. | 72 | Administración de distintos estados de una Orden de Compra.:
·Pendiente de autorización
·Autorizada
·Pendiente de recepción
·Recibida sujeta a conformidad del sector que realiza el control de calidad
·Cumplida parcialmente
·Cumplida
·Recibido no satisfactoriamente
·Anulada (parcial/total)
·Vencida. | 73 | Debe permitir la generación de consultas y listados de Órdenes de Compra por estado. | 74 | Debe brindar la posibilidad de definir múltiples condiciones de pago para las Órdenes de Compra:
·Pago total o parcial a determinados días de la fecha de recepción de la factura y la mercadería.
·Pago en cuotas iguales y no iguales.
·Anticipos totales o parciales.
·Dejar facturas pendientes | 75 | Debe permitir la emisión de Órdenes de Compra para ítems de importación:
·Múltiples monedas
·Modalidad de compra (FOB, CIF, u otra modalidad)
·Múltiples instrumentos de pago, identificando el número de carta de crédito si la operación es financiada por una entidad financiera. | 76 | Debe tener la opción de anular y listar las Órdenes de Compra, no desapareciendo el registro. | 77 | Debe permitir actualizar en forma automática las Órdenes de Compra, rebajando de cada ítem los productos recibidos. | 78 | Debe permitir generar contabilizaciones automáticas, por centro de costos, de los siguientes eventos:
·Costo de ventas
·Proveedores
·Compras
·Devoluciones
·Reemplazos sin cargo al cliente
·Activo fijo
·Ajustes | | MANEJO DE MATERIALES EN TRANSITO | 79 | La aplicación deberá proveer las herramientas necesarias para el control y seguimiento de los productos en tránsito. Esta operación incluye el seguimiento de Órdenes de Compra locales y de importación. Para lograr un eficiente manejo de productos en tránsito, el sistema debe disponer de información proporcionada por operadores logísticos claves en el proceso: agencias de aduana, agente embarcador y almacén en tránsito. | 80 | A través del sistema se podrá solicitar todas las Órdenes de Compra (aprobadas) pendientes de entrega. | 81 | Se deberá separar las Órdenes de Compra según sean de importación o locales, para los seguimientos respectivos. | 82 | Se podrán agrupar las Órdenes de Compra de la siguiente manera:
·Las que se encuentren pendientes de atención con plazo de entrega no vencido,
·Las que se encuentren pendientes de atención con plazo de entrega vencido y,
·Las que se encuentren atendidas (material recibido en almacén destino). | 83 | Para las Órdenes de Compra atendidas, se indicará el día de ingreso a almacén del Transportista y la fecha de envío a bodega destino, así como el número de guía de remisión (o guía de transporte) correspondiente. | 84 | Se podrá acceder a un seguimiento total en el que se podrá escoger el visualizar:
·Órdenes de Compra pendientes de atención,
·Órdenes de Compra con entregas parciales y,
·Órdenes de Compra totalmente atendidas. | | SEGUIMIENTO DE ÓRDENES DE COMPRA LOCALES | 85 | El seguimiento de compras locales deberá poder ser ejecutado por el usuario. El reporte de seguimiento deberá ser filtrado por:
·Proveedor
·Orden de Compra
·Ítem
·fecha
·Guía de remisión. | 86 | La información básica con la que debe contar el seguimiento es:
·Fecha de emisión de la Orden de Compra.
·Fecha de recepción de Orden de Compra por proveedor.
·Fecha de entrega pactada.
·Lugar de entrega.
·Fecha de recepción en almacén en tránsito.
·Fecha de envío a bodega destino.
·Número de guía de remisión (guía de despacho).
·Fecha de ingreso a almacén final. | 87 | Dicho seguimiento deberá enviar un e-mail o fax al proveedor, días antes del vencimiento, recordándole la fecha de entrega (en un formato predeterminado). El sistema deberá ejecutar acciones de seguimiento parametrizadas por tiempo. | | SEGUIMIENTO DE IMPORTACIONES | 88 | Posibilidad de tener un seguimiento de importación en el que se determine por cada Orden de Compra y embarques de ésta, toda la información de la cadena logística:
·Datos de O/C (número, fecha de emisión, forma de pago, condiciones de entrega).
·Fecha de entrega a agentes logísticos.
·Fecha de ingreso de la mercadería al almacén del embarcador.
·Fecha de inspección.
·Fecha de embarque de la mercadería
·Fecha en que arriba a puerto/aeropuerto de destino. | 89 | En el seguimiento se incluirá además los datos de todos los documentos de embarque:
·Número de factura comercial.
·Número de certificado de inspección.
·Número de packing list.
·Número de certificado de origen, otros certificados. | | CONSULTAS E INFORMES | 102 | Debe permitir consultar el último precio de compra para un determinado artículo, en pesos y en dólares, asociado a un proveedor. | 103 | Debe permitir consultar la asociación de Orden de Compra a la factura del proveedor y al requerimiento de compra. | 104 | Debe ser capaz de listar las Órdenes de Compra por fecha de entrega por parte del proveedor. | 105 | Debe permitir consultar las Órdenes de Compra por:
·Usuario solicitante
·Unidad de Negocio y/o Centro de costo
·Costos por Proyectos | 106 | Debe permitir consultar las Órdenes de Compra de acuerdo a los estados definidos. Permitir el enlace con el presupuesto, costos de proyectos y su correspondiente calce con las facturas recibidas. | 107 | Debe permitir obtener reportes para controlar la distribución de los gastos de materiales en el costo de la obra, por cada Orden de Compra. | 108 | Debe permitir obtener un reporte con todas las existencias (Órdenes de Compra) pendientes de recepción física. | 109 | Debe permitir consultar las Órdenes de Compra recibidas y las pendientes de recepción. Poder abrirlas y ver el detalle de sus productos. | 110 | Debe permitir obtener reportes para soportar la cuadratura de balances de inventario físico con balances contables. | 111 | Debe emitir reportes de excepción cuando los precios de los productos se excedan de un cierto margen predefinido en relación con el precio anterior del producto. | 112 | Debe contemplar dentro del menú, stock por bodega y consolidado a una fecha determinada. | 113 | Debe otorgar reportes de desempeño del proveedor para las transacciones de recepción y rechazos, es decir, emitir un informe con la calificación del proveedor. | 114 | Debe proveer múltiples capacidades de clasificación para propósitos de reporte, como por ejemplo:
·Por código de ítem
·Por descripción,
·Fecha Vencimiento o días a fecha de vencimiento, |

6.21.47.3.8 RECEPCIÓN DE PRODUCTOS EN BODEGAS RECEPCIÓN DE PRODUCTOS EN BODEGAS | N° | Funcionalidades | 1 | La recepción se registrará en referencia a una Orden de Compra de la que se obtendrá el detalle del ítem (Código, Descripción, Proveedor, Cantidad, Unidad de Medida) o una guía del proveedor, Inspección técnica. | 2 | El Sistema debe ser capaz de recibir por Pallet, Caja o Unidad, desglosando en cada caso las Subunidades de Embalaje de acuerdo a la Maestra de Productos Vigente. | 3 | El Sistema debe ser capaz de Importar y/o Recibir un Mensaje EDI/XML estandarizado de GUIA DE DESPACHO o FACTURA Electrónica enviado previamente por el proveedor y efectuar la recepción contra este documento previamente recibido. En caso de no contar con el documento, se procede a recibir con el método tradicional. | 4 | El Sistema debe ser capaz de actualizar su maestra de productos desde la maestra estandarizada GS1, que publica y mantiene GS1 (Chile) en conjunto con el ISP (Estandar5.sql). Donde vienen todos los productos Farmacéuticos e Insumos Médicos vigentes, además de su jerarquía de códigos. | 5 | Al recibir el material se debe seleccionar, empleando el sistema, el número de etiquetas requeridas para los artículos que no estén codificados. | 6 | Deberá tener la capacidad de imprimir las etiquetas con código de barras requeridas. La información que debe incluir la etiqueta es:
·Código de ítem
·Descripción del ítem.
·Número de parte.
·Unidad de medida
·Número de Lote
·Fecha de Vencimiento
·Ubicación física en almacenes
·Número de la Orden de Compra. | 7 | Debe generar comprobante de recepción de mercadería (hoja de entrada). | 8 | Debe efectuar la recepción de mercadería total o parcial. | 9 | Debe poder realizar el pareo de las recepciones v/s las Órdenes de Compra, en el momento de entrada de la mercadería (cantidad recibida). Posibilidad de generar márgenes de tolerancia en cantidades. | 10 | Debe permitir definir a priori protocolos o procedimientos de recepción de mercadería y bienes, según el tipo respectivo. Permitiendo aplicar estos protocolos y controlar la trazabilidad de ejecución del procedimiento. | 11 | Debe otorgar actualización automática de stock, provisión en contabilidad y cuentas a pagar. | 12 | Las discrepancias se pueden presentar por cualquiera de las siguientes formas:
·La cantidad física no coincide con la reflejada en la guía.
·La pieza física no coincide con la detallada en la guía.
·La cantidad registrada en la guía no coincide con la Orden de Compra y no estaban autorizadas las entregas parciales.
·La descripción de la guía no coincide con la Orden de Compra.
·La caja de embalaje estaba rota o abierta.
·El material se encontraba dañado. | 13 | Las discrepancias serán registradas por el operador responsable de la recepción al momento de realizar el ingreso. Se debe tener un link de la pantalla de recepción con la de discrepancias. | 14 | Al registrar la discrepancia se debe tener la opción de detener el pago de la factura que pudiese haber presentado el proveedor. | 15 | Se debe visualizar la siguiente información en pantalla:
·Número de ítem en Orden de Compra.
·Código del ítem.
·Número de parte.
·Descripción del material.
·Cantidad de compra.
·Cantidad recibida.
·Unidad de medida (de compra y almacenamiento). | 16 | El reporte de discrepancias debe ser impreso automáticamente al ser completado. Su consulta se realizará mediante selección de alguno de los siguientes criterios:
·Fecha
·Orden de Compra
·Autor de la discrepancia
·Código de ítem
·Número de guía y sus combinaciones. | 17 | PERMITIR ANULAR ACTA DE RECEPCION. | 18 | Generar aviso al usuario respecto de artículos con vencimiento a una fecha determinada, cuando ingresa al sistema. | 19 | Permitir asignar saldo nulo a ítems de Orden de Compra | 20 | Permitir consultar por Ordenes de Salida en base a criterios de búsqueda. | 21 | PERMITIR INDICAR QUÉ PERSONA HARÁ UN DESPACHO A UN SERVICIO DETERMINADO. | 22 | PERMITIR MANTENER PREPARADOS DE FARMACIA. | 23 | Permitir modificar observaciones del acta de recepción. | 24 | PERMITIR MODIFICAR OBSERVACIONES DE UNA ORDEN DE SALIDA. | 25 | Permitir modificar observaciones de orden de compra nula. | 26 | Permitir generar pedidos de compra a adquisiciones desde bodega (excepto Economato) | 27 | Permitir generar pedidos de compra a adquisiciones desde bodega (sólo Economato) | 28 | Permitir REDUCIR LA 'DEUDA' O 'CONSUMO' DE UN ARTÍCULO PARA UN SERVICIO. | 29 | Permitir generar reporte de cargas de actas de recepción para un período de tiempo determinado. | 30 | Permitir generar listado de artículos bajo punto de reposición. | 31 | PERMITIR GENERAR REPORTE DE LISTA DE PRECIOS DE ARTÍCULOS PARA VENTA A PUBLICO. | 32 | Permitir generar reporte de artículos sin movimiento. | 33 | Permitir generar reporte de artículos con restricción de despacho a los servicios. | 34 | Permitir generar reporte de artículos por bodegas. | 35 | Permitir generar reporte de Artículo - Proveedor. | 36 | Permitir generar reporte de artículos con una fecha de vencimiento determinada. | 37 | Permitir generar reporte de artículos por servicio. | 38 | Permitir generar reporte de compras de artículos. | 39 | Permitir GENERAR REPORTE DE CAMBIOS DE PRECIOS MANUALES DE ARTÍCULOS. | 40 | Permitir generar reporte de consumos mensuales de artículos. | 41 | Permitir GENERAR REPORTES DE DESPACHOS DESDE ESTERILIZACIÓN. | 42 | Permitir GENERAR REPORTES DE ENTRADAS - SALIDAS. | 43 | PERMITIR GENERAR REPORTE DE EXIST. FI Y DEUDA FA | 44 | Permitir generar reporte de informe técnico de artículos. | 45 | Permitir generar reporte de movimientos de artículos (entradas-salidas) para una bodega o servicio. | 46 | Permitir GENERAR REPORTE DE PREPARADOS DE FARMACIA. | 47 | Permitir generar reporte de consumos (órdenes de compra) totalizados por proveedor. | 48 | Permitir generar reporte de artículos bajo stock crítico. | 49 | Permitir GENERAR REPORTE DE ARTÍCULOS QUE HAN SIDO ELIMINADOS DEL STOCK DE UN SERVICIO. |

6.21.47.3.9 Existencias, Gestión de Catálogos, * Control de existencias para la DISALCAR, administrando múltiples bodegas y varios tipos de inventarios por bodega. Administración de artículos que requieren controles de niveles de seguridad, fechas de vencimiento y número de serie. 6.21.47.3.10.7 Existencias N° | Funcionalidades | 1 | Capacidad para generar un catalogo de productos agrupados por familias, tipo, grupos y subgrupos, definiendo para cada uno de ellos la unidad de medida. | 2 | Capacidad para vincular los productos a una orden de compra y factura, con definición del precio unitario | 3 | Capacidad para asociar lotes de productos con fecha de caducidad | 4 | Capacidad para asociar a cada lote de compra una ubicación en la estantería | 5 | Capacidad para operar con lectores de código de barras, tanto al ingreso de productos como a despacho por venta o consumo. | 6 | Capacidad para generar e imprimir etiquetas con código de barras bajo el estándar GS1/EAN | 7 | Capacidad para generar procesos de búsqueda a partir de diferentes criterios | 8 | Capacidad para administrar múltiples bodegas y consolidar las existencias. | 9 | definición de stock critico y punto de reposición | 10 | Traspaso de productos entre bodegas | 11 | Capacidad para administrar productos en consignación | 12 | Impresión de listado de productos con indicación de su ubicación para efectos de inventario físico | 13 | Capacidad para efectuar ajustes por mermas, pérdidas y caducidad de productos. | 14 | Administración de productos en transito, en calidad de préstamo y en calidad de anticipo a cuenta de compras pendientes o en proceso. | 15 | Capacidad para generar códigos que representen un conjunto de productos que se venden o consumen en forma complementaria. Ejemplo: Kit de aseo de paciente. | 16 | Posibilidad de generar nuevos productos a partir de productos existentes. Ej. Preparaciones Magistrales en Farmacia, preparación de alimentación enteral o paraenteral. | 17 | Capacidad para generar un listado de precios de costo y mas de un valor de precio de venta, según tipo de cliente | 18 | Valorización de existencia por precio de compra, según criterio contable de valorización. (Ej.: precio de reposición. Precio promedio ponderado) | 19 | Valorización de ventas a precios convencionales, que incluyen costo de transacción y margen de utilidad. | 20 | Administrar pedidos pendientes de despacho por falta de stock o de despachos parciales | 21 | Capacidad para anular pedidos vinculados a pacientes, al momento de generarse el alta del paciente. | 22 | Administración de multiples bodegas | 23 | Traspaso de bienes entre bodegas o instituciones | 24 | Capacidad para Ejecutar automáticamente la consolidación de artículos del maestro (catálogo) cuando se detecten duplicidades. | 25 | Capacidad para Ingresos y cambios masivos a la información del maestro de artículos (catálogo). | 26 | Búsqueda en línea por múltiples conceptos, sin requerir necesariamente el código del artículo. | 6.21.47.3.10.8 Bodega de Farmacia Nro | Funcionalidades | 1 | Inventario valorizado de stock, con indicación de lotes y fechas de vencimiento. Indicación de ubicación física. Uso de códigos EAN-128 y Datamatrix | 2 | Registro de ingreso/ transferencia de productos entre dependencias propias y hacia/desde otras contabilidades de la Institución. Vinculación con Enfermería y Pabellón Quirúrgico. | 3 | Registro de devoluciones. Actualización de stock. Vinculación con admisión. Nota de crédito en cuenta corriente de paciente | 4 | Generación de UNIDOSIS. Requiere etiquetado con código de barras. Uso de códigos EAN-128 y Datamatrix | 5 | Capacidad para ingresar productos magistrales generados a partir de otros productos en existencia. El producto debe estar registrado en el catálogo | 6 | Capacidad de impresión de etiquetas de código de barras y uso de dispositivos lectores de código de barras. Uso de códigos EAN-128 y Datamatrix | 7 | Visualización de recetas pendientes de despacho. Vinculación con FCE, Enfermería, Pabellón Quirúrgico | 8 | Manejo de farmacias o bodegas periféricas (o botiquines). Vinculación con módulos de enfermería, pabellón Quirúrgico, Urgencia | 9 | Considerar bodegas periféricas a dispositivos Grifols y Omnicell Integración con Grifols y Onmicell | 10 | Capacidad para consolidar las existencias de todas las bodegas, incluyendo periféricas y botiquines, para efectos de los cierres de periodos contables. Centralización automática del asiento | 11 | Control de estupefacientes, psicotrópicos y drogas oncológicas. Vinculación de estas con el paciente, con el funcionario que despacha y con el médico que receta. Registro auditable. Cuadre de inventario diario | 12 | Posibilidad de vincular uso de medicamentos con patologías AUGE u otras según protocolos. | 13 | Catálogo o Listado de productos en stock, por nombre genérico y comercial. Vinculación con FCE. | 14 | El catálogo podrá contener productos QUE NO FORMAN parte del arsenal del Hospital. En estos casos, deberá indicarse esta condición en forma clara, advirtiendo que en caso de indicarse, el paciente deberá adquirirlo fuera del hospital. | 15 | Alerta de vencimiento de productos en stock. | 16 | Alerta por Stock mínimo y crítico. Punto de reposición. Generación automática de pedidos de reposición. Vinculación con Bodegas general o Abastecimientos, según corresponda. | 17 | Despacho a pacientes hospitalizados, por carro o gavetero. Con las gavetas debidamente identificadas con código de barras. Agrupación de recetas por servicio y por carro, para su despacho simultáneo. | 18 | Cargo automático de productos despachados, en cuenta del paciente. Integración con “Cuentas de pacientes” | 19 | Actualización automática de inventarios. | 20 | En la búsqueda o consulta por un producto debe indicar la existencia en cada una de las bodegas central y periféricas, con indicación de fecha de vencimiento | 21 | Generar reportes múltiples predefinidos, tales como detalle de consumo de psicotrópicos, drogas oncológicas y antimicrobianos. | 22 | Permitir la generación de reportes nuevos, utilizando la herramienta de reportes | 23 | Transferencia de productos entre bodegas | 24 | Transferencia de bienes entre instituciones. (Ej. Centro Médico Viña del Mar) Implica salida de activo (pseudoventa a valor contable) | 6.21.47.3.10.9 Gestión de Catálogos

N° | Funcionalidades | 1 | El HOSCAR requiere un catálogo de materiales depurado, el cual será la base del catálogo en la aplicación. La Aplicación debe ser versátil en sus consultas para permitir la identificación rápida de los materiales del catálogo a cualquier usuario con el nivel de entrenamiento mínimo para esa función. | 2 | En el catálogo de materiales se deben registrar todos aquellos materiales que tienen una política de stock definida y los activos fijos definidos por la Empresa. | 3 | Debe proveer múltiples capacidades de clasificación para propósitos de reporte, como por ejemplo:
· Por código de ítem
· Por descripción, etc. | 4 | Para catalogar un material se debe tener la opción de registrar la siguiente información:
· Código Interno
. Código EAN-13
. Lote de Fabricación
. Fecha de Vencimiento
· Grupo y Clase.
· Descripción corta, en español e inglés.
· Descripción extendida, en español e inglés
· Coloquiales.
· Unidad de medida.
· Peso y Volumen.
· Clasificaciones, tales como: Capital, Disponible, Inactivo, Administrado por Proveedor, Consignación, Sólo a Pedido.
· Tipo específico de material, tales como: Medicamento, Insumo, Consumible, Suministro y otros.
· Fabricante: más de uno, indicando el preferido.
· Fecha de catalogación/creación
· Información del ítem: Disponible, Inactivo, Reemplazado, homologado, etc.
· Fotos del ítem | 5 | Debe permitir el ingreso (importación) de un maestro de productos de acuerdo a definiciones claramente establecidas y delimitadas, eliminando la posibilidad de ingresos de un mismo artículo con distinto código y viceversa. Esta Maestra debe Incorporar la relación SSCC (código de PALLET) - DUN-14 (código de caja) - EAN-13 (código producto) - EAN-13 (Dosis Unitaria) | 6 | Permitir clasificación según normativa FONASA para artículos (fármacos e insumos), tal que éstos, dependiendo de su utilización, puedan se cobrados al paciente por venta directa o a través de la prestación | 7 | Permitir asignar varias localizaciones a un artículo en cada almacén en un código de 5 caracteres alfanumérico. Por ejemplo, XYZ KC, donde: • XYZ = Corresponde a la ubicación física en el almacén. Puede ser un código plano o inteligente, por ejemplo, pasillo-estante-altura. | | MÉTODO DE INGRESO EN EL CATÁLOGO | 8 | Manual: para la incorporación de nuevos ítems al catálogo y para las actualizaciones de cualquier registro anterior. | 9 | Electrónico (XML o EDIFACT): para ingresar información parcial que es proveída por el fabricante a través de catálogos electrónicos o mensajes, así como para transferir información de un formato en medio magnético al sistema. | 10 | Para registrar un ítem, el sistema deberá indicar si éste ya existe en el catálogo, mediante búsqueda automática por código EAN-13, fabricante o descripción. Esta acción deberá permitir el bloqueo o cancelación del ingreso de un nuevo ítem al catálogo. | 11 | Las consultas del Inventario se deben realizar de acuerdo al código EAN-13, descripción, código interno, coloquiales, fabricantes, grupo, clase y sus combinaciones. | 12 | Debe manejar códigos alternativos de reemplazo para cada artículo (el mismo artículo, pero de distinto proveedor, tiene código distinto). Así cuando se esté requiriendo un determinado artículo, el sistema debe ser capaz de desplegar en pantalla los códigos de artículos alternativos. | 13 | Debe permitir la asignación a cada ítem de: cuentas contables y subítem de gasto. | 14 | Debe permitir clasificar las existencias en importadas y nacionales. | 15 | Debe permitir la identificación de un ítem como sujeto a gestión de stock o crítico. | 16 | Debe permitir el ingreso y modificación de especificaciones físicas y técnicas de los ítems. | 17 | La reposición de material se realizará a través de una recomendación de compra suministrada por el sistema, basada en los siguientes parámetros:
· Stock disponible.
· Cantidad en tránsito.
· Historia de consumo.
· Algoritmos de reposición.
· Tiempo de Aprovisionamiento (Lead Time).
· Paquete Estándar.
· Precio unitario.
· Nivel de servicio.
· Criticidad.
· Punto de reorden.
· Cantidad de reorden.
· Costo de compra.
· Reservas realizadas. | 18 | Debe permitir el manejo de diferentes unidades de medida de los ítems (compra, venta, stock, almacenaje, etc.). | 19 | Debe facilitar el manejo de factores de conversión entre unidades. | 20 | Debe permitir la definición de múltiples estados del stock por ítem, ya sea real o virtual (almacenado, reservado, control de calidad, pedido, en tránsito, dañado, etc.). | 21 | Definir bodegas (o ubicaciones) que sólo sean visibles en el sistema para un grupo definido de usuarios. | 22 | Generar alertas, tales como:
• Alerta 1: Artículos próximos a fecha de vencimiento o expiración.
• Alerta 2: Artículos en su Punto de Pedido.
• Otras. | | TRANSACCIONES | 23 | Debe mantener el stock en tiempo real. | 24 | Registro de los funcionarios autorizados y responsables de la reposición de materiales por código de Centro de Costo, bodegas, artículo o grupos. | 25 | Simulación de REDISTRIBUCIÓN de artículos entre diferentes bodegas de forma de igualar los PUNTOS DE PEDIDO de artículos de un mismo proveedor (algoritmo a ser agregado a pedido). Por ejemplo: Control de existencia on line y capacidad de proyectar movimientos entre las bodegas. | 26 | Debe brindar la facilidad de llevar ubicaciones físicas. | 27 | Debe permitir la impresión automática de etiquetas de identificación de los productos. | 28 | Debe permitir la proyección de stock (planificación, compras, etc.), mediante listados de compras por períodos de tiempo, de tal manera de identificar cuándo y cuánto comprar. | 29 | Debe permitir el ingreso de los documentos de respaldo con los que se recepcionan los artículos, ya sea, Factura, Guía de Despacho, etc. | 30 | Por cada documento necesario, el sistema debe posibilitar la incorporación de los siguientes conceptos mínimos:
· N° Documento (factura, guía)
· Tipo
· Proveedor
· Código artículo
· Detalle (descripción, dimensiones, etc.)
· Valor por ítem
· Unidades por ítem
· Número de Orden de Compra | 31 | Debe mantener actualizado el saldo pendiente de cada documento. | 32 | Debe valorizar las recepciones en forma en línea (on line), en base a precios especificados en la Orden de Compra. | 33 | Debe permitir realizar correcciones a los ítems recibidos, cuando el conteo físico no coincida con lo informado en la factura del proveedor. Las correcciones sólo podrán ser efectuadas por un usuario con la atribución correspondiente (perfil). Esto implica que el usuario pueda ingresar la factura correspondiente al Sistema, a pesar del problema presentado, pero el Sistema debe ser capaz de registrar y notificar al usuario la exigencia al proveedor de la entrega de una Nota de Crédito por la diferencia. | 34 | Debe permitir la diferenciación en la recepción de productos sujetos a control de calidad. | 35 | Debe ser capaz de modificar, en forma automática, el estado de las Solicitudes a Bodega cuando se efectúe la recepción física de la mercadería, cambiándose de “mercadería en tránsito” a al estado posterior, por ejemplo: “recibido en bodega”. | 36 | Debe calcular el tiempo que demora la bodega en abastecer un determinado artículo al solicitante. | 37 | Debe permitir recepcionar en la misma transacción productos comprados en el exterior (importados) y en el mercado local (nacionales). | 38 | Debe permitir un fácil acceso a información de los costos al momento de solicitar los productos a bodega, es decir, cuando se crea una solicitud de Productos | 39 | Debe permitir incorporar y administrar el estado de productos reservados para centros de costos que los solicitan, quedando no disponible para los demás. | 40 | La salida de productos debe ser apoyada por un documento impreso que especifique el detalle de los productos y el centro de costo al que fue cargado. | 41 | La creación de un vale puede originar la creación automática de una requisición o ser incluido en las recomendaciones de compra, si la disponibilidad del material es menor a la cantidad requerida. | 42 | Se deben proveer los medios de control para que la autorización de despacho interno de determinados tipos de ítems se restrinja a usuarios autorizados. | 43 | La búsqueda del vale se debe realizar por cualquiera de las siguientes opciones:
· Número correlativo de vale
· Usuario.
· Código de ítem
· Centro de costo
· Autorizador | 44 | Se debe tener la opción de despachar un vale en forma completa o parcial en una transacción única. Asimismo, se debe tener la opción de despachar parcialmente la cantidad requerida de un ítem, si es que está autorizada por el usuario. | 45 | Despachado el vale, se deben actualizar automáticamente los stocks y valor de inventario, registrándose además de la información del ítem, personal (despachador) que realiza el despacho. | 46 | Se debe disponer la facilidad de modificación, cancelación o anulación de vales, en forma parcial o total. | 47 | El sistema debe incluir la posibilidad de integración de su funcionalidad de despacho de materiales con un sistema de código de barras. | 48 | Debe asignar números secuenciales automáticos a los documentos emitidos. | 49 | La fecha de emisión de la solicitud de materiales debe ser por defecto. No se debe permitir su modificación. | 50 | Debe permitir generar contabilizaciones por centro de costos, al momento de salir de bodega los materiales e insumos. | 51 | Debe permitir la generación de provisión, si corresponde, a ítems recibidos y no facturados. | 52 | El acceso a los centros de costos a ser imputados debe depender del usuario en cuestión, por lo que un usuario no debe poder acceder a centros de costos ajenos a su función. | 53 | Debe incluir un módulo de “custodia” de artículos, el cual permita ingresar artículos con valor comercial elevado o de acceso restringido. | 54 | El acceso al módulo de custodia debe estar restringido. | 55 | Debe impedir el registro de guías de despacho con número duplicado. | 56 | Debe restringir la modificación de los datos provenientes del módulo de compras. | 57 | Debe proveer la facilidad para recibir ítems devueltos por los Usuarios y/o Servicios, actualizando saldos de inventario e incorporación de razones de devolución e identificarlos con un código de transacción diferente. La transacción debe generar un Comprobante de Devolución. | 58 | Debe poder discriminar entre los diferentes requerimientos de manera de asignar el producto de acuerdo al grado de urgencia de la solicitud (esta urgencia se mide por criterio a definir). | 59 | Debe permitir registrar como pendientes aquellas partes que no pueden ser proveídas por el stock disponible, e ir almacenando los pedidos pendientes en un archivo especial. | 60 | Debe proveer la facilidad de registrar transferencias entre bodegas, actualizando saldo de inventarios tanto para la bodega que recibe como para la que envía. Es decir, rebajar automáticamente de la bodega que envía e incrementar los saldos de la bodega que recibe, una vez recibidos los productos en ésta. | 61 | Debe permitir identificar un dueño virtual, en caso que existiese. | 62 | Devolución a proveedor de material ingresado a stock. | 63 | El cálculo de la “rotación” que permita una mejor definición para calcular su nivel de existencia de seguridad. | 64 | Devolución a proveedor por material rechazado por la inspección técnica | | CONTROL DE EXISTENCIAS | 65 | Debe permitir la posibilidad de tomar el inventario a través de lectores de códigos de barra, o manualmente y que el sistema en forma automática efectúe el cotejo determinando diferencias. | 66 | Debe proveer la facilidad de generar ajustes por conteo físico, tanto en unidades como en los valores totales. | 67 | Debe permitir definir y controlar inventarios multi-bodegas. | 68 | El fundamento del inventario es reflejar la exactitud de los stocks físicos en relación con los stocks reflejados en el sistema. Para esto, el sistema debe permitir la realización de inventarios periódicos (cíclicos) y totales de los ítems del almacén, así como los ajustes que se deben efectuar por diferencias detectadas. | 69 | La aplicación debe permitir la posibilidad de efectuar ajustes por diferencia de precio. | | REPORTES | 70 | Las listas de ítems para inventariar deben considerar los siguientes campos: | | · Código ítem. | | · Descripción del ítem. | | · Número de parte. | | · Unidad de medida. | | · Ubicaciones físicas. | | · Stock. (Opcional). | | · Cantidad inventariada. | | · Fecha de emisión del reporte. | 71 | La relación de ítems con discrepancia final considerará, además de la información anterior, el costo total de los ajustes a realizar (tanto por discrepancia positiva como negativa). | 72 | Debe permitir consultar las solicitudes de materiales por: | | · Usuario solicitante | | · Centro de costo | 73 | Debe permitir consultar las solicitudes de materiales de acuerdo a los estados definidos: | | · Solicitud en tránsito. | | · Material entregado. | | · Material en tránsito. | 74 | Debe permitir emitir informes de excepción para: | | · Solicitudes no aprobadas. | | · Solicitudes en tránsito. | | · Entregas en tránsito. | 75 | Consulta on-line del maestro de proveedores, que a lo menos contenga la siguiente información: | | · RUT del proveedor. | | · Nombre del proveedor. | | · Dirección. | | · Persona de contacto. | | · Teléfono. | | · Fax. | | · Dirección Internet. | | · Rubro de productos. | | · Descuentos. | | · Fechas y días de pago. | | · Calificación del proveedor (entrega adecuada, entrega fuera de plazo, productos defectuosos). | 76 | Debe proveer múltiples capacidades de clasificación para propósitos de reporte, como por ejemplo: | | · Por código de ítem. | | · Por descripción. | | · Etc. | 77 | Debe manejar distintos criterios de búsqueda de la información a nivel de campos numéricos y alfabéticos, y de datos codificados y descriptivos | 78 | Permitir consultar las Órdenes de Compra recibidas y pendientes de recepción. Poder abrirlas y ver el detalle de sus productos. | 79 | Debe permitir conocer el estado actual de los productos almacenados en bodega, tanto en línea como consultas a través de reportes, con las siguientes magnitudes entre otras: | | · Cantidad disponible. | | · Cantidad comprometida. | 80 | Debe permitir obtener listados de los productos almacenados, por ubicación para efectuar la toma de inventario físico. Las que deben contener, a lo menos: | | · Ítem. | | · Ubicación. | | · Código de producto. | | · Lote. | | · Descripción. | | · Unidad de medida. | 81 | El sistema debe entregar facilidades para hacer inventarios, por ejemplo: | | · Emitir listados con cantidades y sin cantidades. | | · Ingresar criterios de inventarios para poder hacerlos selectivos. | | · Debe tener la opción de solicitar lo que se quiere inventariar, el sistema hace la búsqueda e imprime el listado de acuerdo a criterios pedidos y ordenados por localización. | 82 | Debe entregar listado de verificación con todos los ítems contenidos en la factura y un espacio en blanco para inventariar los productos recibidos. El listado de verificación debe estar ordenado por localización física y por artículo. | 83 | Debe permitir calcular en forma automática y reportar la rotación de inventario, de acuerdo a parámetros definidos por Usuarios | 84 | Debe permitir obtener reportes o consultas para identificar tipos especiales de inventario, tales como: stock negativo, con poco movimiento y otros que le interese definir. | 85 | Debe proveer reportes que identifican el uso promedio del ítem por mes, trimestre y periodo definido. | 86 | Debe permitir la impresión de un código de barras con datos significativos para el control de existencias. | 87 | Debe permitir la consulta diaria y en línea de las Solicitudes de pedido pendientes de despacho, diferenciadas por: | | · Pendientes de despacho con stock. | | · Pendientes de despacho sin stock. | 82 | Debe permitir la consulta a nivel de detalle de las solicitudes de pedido. | 83 | Debe permitir agrupar las solicitudes para un mismo usuario y/o centro de costo. | 84 | Debe permitir consultar los saldos de las solicitudes: | | · Número de Solicitud. | | · Cantidad solicitada. | | · Total despachado. | | · Fecha del despacho. | | · Unidades pendientes de despacho. | 85 | Debe brindar facilidades de consulta de los datos del maestro de productos. | 87 | Debe proveer múltiples capacidades de clasificación para propósitos de reporte, como por ejemplo: | | · Por número de partes | | · Por modelo | 88 | Cualquier modificación de los datos de los archivos debe quedar registrado, para efectos de auditoría, especialmente todo lo relacionado con entradas y salidas de bodega y modificaciones en la bases de datos. | 89 | Debe generar reportes por centros de costo señalando los costos involucrados en las solicitudes, para un determinado período. | 90 | Debe proveer la facilidad de informar al Jefe del centro de costo respectivo, el cargo efectuado. |

6.21.47.3.10 Control de Demanda El Control de Demanda es un conjunto de funciones que facilita el análisis, el control, la distribución y reaprovisionamiento de “artículos” deforma que se optimice el uso de los artículos en un conjunto de Centros de Costo, distribuidos en diferentes bodegas. Opera según las convenciones y definiciones que siguen: • Artículo: Es un elemento único, descrito e incorporado al Catálogo de Artículos de existencias, pudiendo estar o no disponible para su consumo. Esta denominación es utilizada en el sistema de Existencias en reemplazo de “ítem”. • Unidad de Existencia: Es aquella unidad en que se utiliza para contabilizar la cantidad de artículos de algún tipo y es sinónimo de “Unidad de Almacenamiento”. También corresponde a la “unidad de entrega” y ella es el componente básico sobre el cual se valoriza un artículo. • Nivel de Seguridad Crítico: Es una cantidad de artículos que el usuario de Control de Demanda deberá definir, tal como el nivel mínimo de existencia del artículo en cada bodega. Es un número entero y finito, y el sistema debe proveer la facilidad de ingresar de a uno o en forma masiva, por Grupo o por Grupo-Subgrupo. La cantidad considerada como Nivel de Seguridad dependerá del grado de consumo del artículo y del plazo de aprovisionamiento (Tiempo de Pedido). NOTA. El Nivel de Seguridad deberá ser por defecto CERO o podrá ser calculado por el sistema, de la forma que asegure el consumo mientras se recibe un próximo pedido. * Punto de Pedido: Es un número de días por delante en el tiempo en que se debe solicitar un reaprovisionamiento de un artículo-proveedor. El Punto de Pedido es el nivel de existencias de un artículo para el que se hace necesario reaprovisionar el almacén. Este nivel depende del grado de consumo, plazo de aprovisionamiento (Tiempo de Pedido) y Nivel de Seguridad del artículo. El sistema debe considerar, además, la información estadísticas en cantidad deartículos. Este momento es calculado por el sistema según se explica en detalle en el punto relacionado con la Rotación de Artículos. * Unidad de Medida de Tiempo: Es el “día calendario” o día corrido (sin considerar fines de semana ni feriados), y es utilizado para cálculos y otras variables. * Tiempo de Pedido: Es la cantidad de “días calendario” que un cierto proveedor se demora en dejar en la bodega de entrega un artículo determinado desde el momento que se le gira una Orden de Compra. Este se mide por el número de artículos que se consumirán durante el tiempo que tarda en llegar el pedido. El sistema debe considerar además la información estadísticas en cantidad de artículos. Este valor debe ser informado por el usuario de Control de Demanda al proveedor del artículo. El sistema debe proveer la facilidad de ingreso de este factor uno a uno, por artículo, por artículo proveedor en forma masiva o masivo a todos los artículos de todos los proveedores. * Rotación de Artículos: Es una cantidad calculada por el sistema para cada artículo, la cual indica el PROMEDIO DIARIO DE ENTREGA DE ARTÍCULOS, calculado sobre una base de tiempo que será un valor definido por el usuario de Control de Demanda como un parámetro en unidad “días”. Esta cantidad podrá ser modificada por el Control de Demanda o ajustada por el sistema de acuerdo a algún algoritmo que defina el usuario y se programe en el sistema. El valor por defecto es 30 días. La Rotación se recalcula y se actualiza constantemente con cada salida. La rotación de artículos mide la frecuencia de salida de los artículos almacenados y se calcula comparando el stock medio del artículo que permanece en el almacén con sus consumos (salidas y/o ventas). Indica el número de veces en el período que el inventario es vendido y/o consumido. Cuando la Rotación calculada por el sistema es CERO el sistema graba Nulo o Blanco en la tabla correspondiente. Nota. La rotación cero (0) evidencia un producto OBSOLETO O MUERTO, ya que no ha registrado movimiento en un periodo determinado de tiempo. Nro. | Funcionalidad | | Control de Demanda | 1 | Guardar las cantidades y fechas de todas las salidas de un artículo de existencia y mantener actualizado el parámetro “Rotación del Artículo”. | 2 | Utilizar algoritmos de cálculo para obtener la estimación de días que faltan para el Punto de Pedido. | 3 | Atributos agregados al ingreso de artículos | 4 | Cada Artículo debe tener asociada una categoría y una condición a saber.
Ejemplos de categorías:
A = DISPONIBLE
B = EN RESERVA
C = EN TRANSITO.
Ejemplos de condición (2° Nivel):
1 = NUEVO
2 = REPARADO
3 = DEFECTUOSO
4 = VENCIDO
5 = OBSOLETO. | 2 | La categoría y la condición de un artículo deben ser mostradas en las consultas de Artículos en Existencia por Bodega. Por ejemplo:
• Artículo XXX
• Total en Existencia 100
• Disponibles 90
• Reserva de solicitudes del área clínica y servicios 10
• De los 90 disponibles, nuevos 80, reparados 8, vencidos 1, obsoletos 1. | 3 | Una Orden de Compra no recibida marca la cantidad pedida como Categoría en Transito y cuando esa orden ingrese a existencias lo cambiará a Categoría Disponible. | 4 | El usuario Control de Demanda puede generar automáticamente las Orden es de Compra para reposición de Existencias, las cuales pueden fraccionarse por Proveedor y por artículos, dependiendo de la naturaleza del artículo (por ejemplo: medicamentos Psicotrópicos, Refrigerados y Otros). | 5 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. | NOTAS ACLARATORIAS: La información básica de un programa de gestión de stocks debe considerar: * La localización de los productos en almacenes, bodegas / centros de costos. En la información registrada referida a cada producto debe figurar su ubicación. * Niveles de inventarios. Información sobre movimiento de los artículos en número de unidades (entradas, salidas, saldos). * Criterios de Clasificación: ABC (Pareto), Índice de Rotación, o una combinación de ambos (ABC y Rotación). * Productos obsoletos o caducados: Su fecha de caducidad ha sido superada. * Rotura de stock: Envíe mensaje o aviso cuando la cantidad de un artículo se encuentre por debajo del stock de seguridad.

6.21.47.3.11 Activo Fijo. Permite la asociación a las cuentas contables respectivas que registren su valor histórico, revalorizaciones, depreciación y corrección monetaria. Es necesario incorporar todos los controles físicos de los activos según su ubicación y responsabilidad y soportar los programas de mantenimiento de los mismo activos, tanto reactivos como preventivos.

ACTIVOS FIJO | N° | Funcionalidades | 1 | Activo Fijo debe operar para cada centro de costos y centros de responsabilidad y/o servicios. | 2 | Ejecutar en forma automática los procesos de cálculo de depreciación y corrección monetaria de los activos registrados en el Auxiliar. | 3 | Permitir la definición del o los establecimiento de salud en la cual será utilizado el Activo Fijo, y registrar el año y mes de inicio, la periodicidad en que será calculada la depreciación (mensual o anual), y el tipo de comprobante contable que será generado con estos valores para ser enviados en línea a Contabilidad previa aprobación. | 4 | Permitir la definición, de las cuentas que serán utilizadas en Contabilidad para el registro de ganancia o pérdida por venta, utilidad por revalorización, corrección monetaria y depreciación acumulada. | 5 | La primera clasificación de los activos es por TIPO. Esta clasificación apunta a definir el tratamiento contable que se aplicará sobre ese activo. Según Normativa de la Contraloría Gral. De la República. Dejar asociado el tratamiento internacional (IFRS), para cambios de procedimiento en el mediano plazo. | 6 | Para cada tipo de activo se deben definir todas sus cuentas asociadas: de registro del bien, de registro de sus mejoras, de su depreciación y de su corrección monetaria. | 7 | Mantener una tabla con parámetros necesarios para efectuar el cálculo de la corrección monetaria según Normativa de la Contraloría Gral. De la República. | 8 | La carpeta de ingreso registra su clasificación Tipo-Grupo-Subgrupo, se asocia a un Centro de Costo, Centro de Responsabilidad y a un Proyecto Presupuestario. Se registran todos los datos de la Orden de Compra, proveedor, valores, fechas, factura y se define su vida útil para efectos de la depreciación. | 9 | La carpeta Ubicación registra la ubicación física en la jerarquía Unidad-Sección aparte de la dirección de la ubicación y el usuario que será el responsable de ese activo. | 10 | Permitir identificar/Administrar Activos Puntuales Ej.: Equipos, Motores, Ascensores, etc. | 11 | Permitir manejar las estructuras de los Activos en forma conjunta y/o individual acorde con una estructura lógica de agrupación. | 12 | Permitir mirar gráficamente la Jerarquía de los Activos y sus componentes. | 13 | Permitir llevar el historial técnico de los Activos y Componentes a través del tiempo. | 14 | Permitir la asignación de operaciones de mantenimiento a los Activos con el fin de poseer la totalidad de actividades factibles de realizar en el activo. Estas listas se deben actualizar automáticamente cuando se actualice el catalogo de operaciones. | 15 | Permitir clasificar y agrupar los Activos según clases y características definidas según Normativa de la Contraloría Gral. De la República. | 16 | Permitir asociar fichas técnicas configurables a Activos y utilizar sus campos como criterios de búsqueda. | 17 | Permitir asociar planos a Activos (como adjuntos) | 18 | Permitir la asignación de operaciones de mantenimiento a los Activos con el fin de poseer la totalidad de actividades factibles de realizar en el activo. Estas listas se deben actualizar automáticamente cuando se actualice el catalogo de operaciones. | 19 | Permitir relacionar el rol o código de activo al inventario de activos. | 20 | Permitir llevar el control de emergencias, puestas fuera de funcionamiento y puesta en funcionamiento de los Activos generando los datos de: tiempo de reparación, tiempo entre fallas, tiempo de operación, etc. | 21 | Permitir extraer información en línea de los Activos, a través de parámetros de búsqueda previamente elaborados. | 22 | Permitir que el activo se pueda dar de baja del inventario. | 23 | Permitir asociar cualquier documento al registro del Activo. Ej. fotos, videos documentos, planos, etc. | 22 | Permitir la definición de una estructura de componentes al Activo o al grupo de Activos. | 23 | Facilidad para extraer información a través de reportes estándares o diseñados por el usuario. | 24 | Permitir hacer traslados o movimientos de bienes desde una dependencia física, centro de costo o centro de responsabilidad. | 25 | Permitir una operación conjunta e integrada entre ubicaciones físicas, centros de responsabilidad y centros de costo. |

6.21.47.3.12 Activos de Producción (Maquina, Equipos, Flotas) y Mantenimiento Permite inventariar y gestionar la mantención asociada a la vida útil de cada uno de los activos de producción que EL FONDO quiera incorporar. Permite la asociación a las cuentas contables respectivas que registren su valor histórico, revalorizaciones, depreciación y corrección monetaria. Permite controlar los distintos aspectos de la vida útil de un activo de producción, además de otorgar visibilidad y control a su proceso de mantenimiento sea este reactivo o preventivo.

6.21.47.3.13.10 ADMINISTRACIÓN DE EQUIPOS Y MAQUINARIAS Gestión de Mantención de Equipos y Maquinarias | N° | Funcionalidades | | ADMINISTRACIÓN DE EQUIPOS Y MAQUINARIAS | 1 | Permitir identificar/Administrar Equipos y Maquinarias | 2 | Permitir manejar las estructuras de los Equipos en forma conjunta y/o individual acorde con una estructura lógica de agrupación. | 3 | Permitir mirar gráficamente la Jerarquía de los Equipos y sus componentes. | 4 | Permitir llevar el historial técnico de los Equipos y Componentes a través del tiempo. | 5 | Permitir clasificar y agrupar los Equipos según clases y características definidas por el usuario.En especial considerar la incorporación de la clasificación ECRI para equipamiento médico. | 6 | Permitir asociar fichas técnicas configurables a Equipos y utilizar sus campos como criterios de búsqueda. | 7 | Permitir la asignación de lista de materiales a equipos con el fin de poseer la lista detallada de repuestos de ese Equipo. Estas listas se deben actualizar automáticamente cuando se actualice el catalogo de Repuestos. | 8 | Permitir relacionar el código de activo fijo al Inventario de equipos. | 9 | Permitir llevar el control de paradas y puesta en funcionamiento de los Equipos generando los datos de: tiempo de reparación, tiempo entre fallas, tiempo de operación, etc. | 10 | Permitir extraer información en línea de los Equipos, a través de parámetros de búsqueda previamente elaborados. | 11 | Permitir hacer el seguimiento, cuando el equipo esta en garantía del Proveedor cuando se trate de un equipo nuevo o bien cuando se realice una reparación por parte de terceros. | 12 | Permitir que el equipo se pueda dar de baja del Inventario de Activo Fijo. | 13 | Permitir que se pueda cambiar de ubicación al equipo, en cualquier momento sin perder su historial y seguir con el seguimiento de costos. | 14 | Permitir asociar cualquier documento al registro del equipo. Ej. fotos, videos documentos, planos, etc. | 15 | Permitir la definición de una estructura de componentes al equipo o al grupo de equipos. | 16 | Permitir agrupar equipos por tipo de modelo, fabricante, etc. | 17 | Permitir Numerar Equipos y Componentes con números alternos y con números estructurados Ej.: Tag Number, Coloquiales, Activo Fijo, etc. | 18 | Permitir manejar y controlar el mantenimiento y la administración del equipo rodante tales como ambulancias, horquillas, de tal manera de llevar un seguimiento de costos de reparaciones, consumos de combustibles, lubricantes, repuestos, distancias recorridas, horómetro, etc. | 19 | Facilidad para extraer información a través de reportes estándares o diseñados por el usuario. | | ADMINISTRACIÓN DE ÓRDENES DE TRABAJO (OT) | 20 | Permitir la generación de Solicitudes de Mantenimiento como etapa previa a la creación de las Órdenes de Trabajo. | 21 | El sistema debe permitir Solicitar trabajos de la siguiente manera: | | Registro del originador, Código de fallas (ruido, fuga, vibración, temperatura, aflojamiento, desgaste normal, desgaste anormal, Mantenimiento Preventivo no realizado, etc.) Código y ubicación del equipo Fecha del evento, turno y hora. | 22 | Registrar la Codificación de falla, Reporte de análisis de fallas (repetitivas, por turno, no comunes, por componente, por supervisor) Tiempo promedio entre fallas (TPEF), Tiempo promedio por reparación (TPPR), Confiabilidad, Reporte de cierre de OT. | 23 | Permitir la creación de Órdenes de trabajo, a partir de la Solicitud de Mantenimiento. | 24 | Permitir consultar desde una “OT” todas las Solicitudes de Mantenimiento asociadas a ella. | 25 | Permitir la asignación de una o varias Solicitudes de Mantenimiento a una Orden de Trabajo. | 26 | Permitir la creación de “OTs” para sistemas, equipos, componentes. | 27 | El sistema debe otorgar permisos de anulación de una Órdenes de trabajo en forma manual. | 28 | El sistema debe poder registrar el motivo de la anulación. | 29 | Permitir la creación de OTs de acuerdo al tipo de presupuesto (presupuesto corriente, reparación mayor activable, y cuentas contables. | 30 | Para el registro de la descripción, el sistema debe poder debe disponer de un campo “comentarios” que permita al registrar los comentarios y observaciones relacionadas con la reparación/mantención que se está solicitando. Debe permitir el ingreso de información suficiente para entender la naturaleza de las actividades, complejidad, etc. | 31 | Permitir la creación de trabajos estándar los cuales contienen, la descomposición en tareas, los desfases entre ellas, cantidad de recursos de mantención, listas de materiales, grupos de trabajo, etc., así como la estimación de costos (en línea) para estos trabajos. | 32 | Permitir manejar diversos estados básicos de una Orden de Trabajo de Mantenimiento (Ej.: en ejecución, en planificación, en espera, terminada, etc.) y otros estados secundarios. | 33 | Debe mantener información histórica de las mantenciones y reparaciones realizada a máquinas, equipos, etc. inventariadas en el Activo Fijo y de sus piezas. Se debe incluir como mínimo la siguiente información. | | · Equipo | | · Descripción de la mantención y/o reparación | | · Procedimientos utilizados y el tipo de intervención realizada. | | · Contratista | | · Proveedor del repuesto | | · Costos de repuestos y materiales | | · Costo en hrs. hombre | | · Fecha Inicio | | · Fecha estimada de término | | · Fecha de término | | · Responsable asignado | 34 | Permitir agrupar Órdenes de Trabajo de tal forma que se pueda consultar en línea los datos de costos estimados y reales de todo el grupo de “OTs”. | 35 | Permitir direccionar la autorización de las “OTs” a diferentes personas o cargos, según criterios definidos por el usuario. | 36 | Permitir interface o integración con MS Project (no se debe incluir el MS Project), y poder realizar Carta Gantt con la información del Trabajo a realizar. | 37 | Permitir asignarle fechas de ejecución a las Órdenes de trabajo, y llevar un control del tiempo utilizado en la ejecución de las tareas. | 38 | Permitir actualizar la disponibilidad real de un equipo en un período, una vez este haya terminado, con el fin de determinar horas reales disponibles. | 39 | Permitir la reprogramación de actividades comprometidas o liberadas por los mismos mecanismos de la programación original. | 40 | Permitir reprogramar la Orden de Trabajo y optimizar los recursos (nivelación de fuerza laboral /horas disponibles vs. horas requeridas). | 41 | Permitir la comparación gráfica entre recursos disponibles y requeridos para un grupo o grupos de trabajo. | 42 | Permitir visualizar en forma Gráfica, los estimados y reales y la varianza. | 43 | Permitir que un mismo trabajo estándar sea valorizado en forma diferente, dependiendo de factores como grados de dificultad, distancias, etc. | 44 | Permitir consultar el detalle de costos planeados y reales por tareas. | 45 | Permitir la asociación de “OTs”, a proyectos creados en el mismo sistema, de tal forma que los costos reales y planeados hagan parte de la estructura de costos del proyecto. | 46 | Permitir obtener los costos de Órdenes de Trabajo, por jerarquía de equipos / grupos de equipos. | 47 | Permitir discriminar los costos de los trabajos de mantenimiento, teniendo en cuenta la Mano de Obra, repuestos, materiales, servicios de terceros, etc. | 48 | Permitir registrar y controlar el tiempo real por tarea realizada por empleado y/o cargo. | 49 | Permitir la obtención de informes personalizados por el usuario acorde a parámetros de solicitud, presentando sólo los datos deseados con la opción de impresión directa. | 50 | Permitir valorizar la OT con todos los costos asociados a ella y personal externo, materiales y repuestos, servicios de terceros, costo de equipos y grúas, compras, contratos etc. | | ADMINISTRACIÓN MANTENIMIENTO PREVENTIVO | 51 | Permitir la programación de tareas repetitivas de acuerdo a parámetros de control, como calendario, horómetro, costeo de las tareas en términos de HH (horas hombre) por especialidad. | 52 | Proveer facilidades internas para la construcción de programas de mantenimiento ya sean tareas repetitivas, Órdenes correctivas, etc. empleando criterios de período de trabajo, reprogramación automática de tareas no ejecutadas, etc. | 53 | Armado de rutas con equipos que pertenezcan al mismo padre en la jerarquía de equipos. | 54 | El sistema debe contener un análisis tendiente a obtener las causas de las fallas, la tendencia de fallas, pronósticos y probabilidades de las fallas. Para esto debe permitir configurar y utilizar jerarquías de falla, al menos de tres niveles (Problema – Causa – Solución) y vincularlas a los equipos en análisis. | 55 | Permitir la elaboración de listas de materiales involucrados en el mantenimiento preventivo. | 56 | Permitir suministrar informes de los pronósticos de recursos requeridos por período (mano de obra, materiales, equipos tipo herramientas, etc.). | 57 | Permitir visualizar la carga de los recursos para mantenimiento disponibles | 58 | Permitir algún tipo de vinculación o relación con MS Project que permita poder elaborar carta Gantt de planificación | 59 | La programación debe incluir: | | · Periodo cubierto, Planificador, Grupo de trabajo, recurso disponible y planeado. | | · Prioridad del Equipo, Numero Orden de trabajo, Descripción de la rutina, Duración, Fecha Inicial y Fecha Final, | | · Carta Gantt del trabajo Planeado como salida. | 60 | Control de paradas de Equipos de Proceso | | · Identificación de requerimientos de Trabajos y necesidades de recursos. | | · Definir niveles de autoridad para el control de perdidas de Producción | | · Facilidad para cambiar fechas de programación en paradas mayores. | 61 | Generación automática de Órdenes de Trabajo basados en las rutinas de Mantenimiento preventivo y las estadísticas Operacionales de cada Equipo. | 62 | Control del personal y recursos dentro de los Grupos de Trabajo. | 63 | Acceso a Lista de Repuestos de Equipos. | 64 | Ajuste de la programación en forma manual (planeado y programado). | 65 | Identificación de requerimientos de recursos (mano obra, herramientas y equipos). | 66 | Reprogramación de tareas mediante el arrastre a un periodo no comprometido. | 67 | Distribuir automáticamente los recursos acorde con los desfases de las tareas de los trabajos estándares. | 68 | Múltiples unidades de intervalo de programación para Mantenimientos Preventivos. | | · Días | | · Semanas | | · Meses/Años | 69 | Mantenimiento Preventivo basado en Medidores (al menos 2 medidores en un mismo equipo), ejemplos: | | · Horómetros | | · Kilómetros | 70 | Mantenimiento Basado en Condiciones (Sintomático). Ejemplo: Vibraciones, Análisis de Aceite, etc. | 71 | Mantenimiento Preventivo –mantenimientos preventivos multinivel (jerarquía) | 72 | Procedimientos de Trabajo Seguro – los peligros y precauciones pueden combinarse en planes de seguridad predefinidos y unidos una vez a los activos o ubicaciones para usarse en los trabajos. | 73 | Procedimientos de Trabajo Seguro – procedimientos de desconexión y reconexión y tarjetas de bloqueo. | 74 | Presupuestos – Comparativo de Presupuestos otorgados por centro de costo versus costos incurridos por centro de costo. | | MONITOREO POR CONDICIÓN | 75 | Permitir la definición de rutinas, frecuencias e identificación de puntos de muestreo para colección de datos. | 76 | Permitir integrar este módulo con el módulo de programación, estándares de trabajo, Órdenes de Trabajo, estadísticas operacionales. | 77 | Permitir la facilidad para definir niveles de precaución y de peligro, y que estos niveles disparen alarmas para realizar el monitoreo. | 78 | Capacidad de obtener las tendencias en forma gráfica de acuerdo a las muestras tomadas. | 79 | Que el sistema permita la entrada manual de los resultados de las muestras. | 80 | Que el sistema permita la entrada automática de los resultados de muestras. | 81 | Permitir mantener el registro histórico de los datos digitados. | | MATERIALES Y REPUESTOS | 82 | Se requiere que todo listado de partes tenga la cantidad requerida de repuestos para su reparación y la cantidad instalada en el equipo. | 83 | Se requiere tener la facilidad de crear un listado de partes requeridas para efectuar un trabajo específico de mantenimiento, incluyendo materiales incluidos en el inventario y repuestos susceptibles de compra directa. | 84 | Se requiere asignarle al listado de partes un responsable para su control y actualización. | 85 | Se requiere de un número de identificación para hacerle seguimiento a los componentes. | 86 | Se requiere que al crear un listado de partes se pueda registrar la siguiente información: | | · Materiales | | · Fabricante | | · Nº de parte, | | · Código de almacén | | · Grupo identificador a cual pertenece Grupo Clase | | · Cantidad instalada | | · Cantidad requerida | | · Descripción del listado de partes | | · Costos unitarios | | · Unidades de medida | | . | 87 | El sistema debe permitir, agrupar listas de partes, definir stocks mínimos, definir tiempos de reposición, definir frecuencia de uso, asignar responsables, catalogar ítems nuevos. | 88 | Permita registrar la información de componentes del mismo modo que se registra un Equipo: Fabricante, Número de Parte, Número de Ítem Catalogado. Tipo de Posición (Instalado), Estado, etc. | 89 | Efectuar la búsqueda de repuestos y materiales por proveedor | 90 | Permitir la actualización de la vida del componente, desde el momento en que se le registra la estadística de Operación al Equipo. | 91 | Realizar seguimiento a componentes enviados a reparar a terceros, Actividades a realizar, Transacción de seguimiento, Ingreso al almacén, Retiro del almacén, dado de baja, etc. | 92 | Facilidad para cargar automáticamente desde Excel al software, la información de registro de Equipos y Componentes. | 93 | Facilidad para generar reportes e informes de gestión. | | MODELO DE EQUIPOS/UBICACIONES FUNCIONALES | 94 | Manejo separado del concepto de Ubicación Funcional (Posición, TAG) del concepto de Equipo Físico (Número de Golpe). | 95 | Se deben definir los equipos con los siguientes atributos como mínimo: código, descripción, tipo o sub-tipo, N° de serie, fabricante, fecha instalación, etc. | 96 | Manejo Jerárquico multi-nivel ilimitado (no necesariamente de la misma profundidad) tanto para ubicaciones funcionales como para equipos (relación equipo – equipo componente / subequipo). | 97 | Se requiere llevar el historial de mantenimiento y costos al nivel de detalle que se requiera (cualquier nivel de la jerarquía definida). | 98 | Especificaciones Técnicas de equipos en jerarquía de clasificación de al menos 2 niveles (clase, subclase). | 99 | Generación automática de descripciones de equipos desde los datos de especificación. | 100 | Equipos – lista de materiales/partes (despiece de equipos). | 101 | Equipos – generación automática de lista de materiales/repuestos a medida que se cierran las Órdenes de trabajo en base al consumo de bodega asociados a la OT. | | ADMINISTRACIÓN DE PERSONAL MANTENIMIENTO | 102 | Permitir registrar y controlar la disponibilidad de mano de obra, para poder utilizarlo al momento de la planificación, así mismo se debe actualizar automáticamente en línea y en tiempo real en la medida de la utilización de esa mano de obra. | 103 | Mecanismo de Costeo de Labor para distribuir los costos de la mano de obra basado en la cantidad de horas hombre (h/h) trabajadas en cada Orden de Trabajo y en el costo estándar estimado por hora de cada empleado, grupo de trabajo, especialidad, centro de costo, taller u organización. | 104 | Permitir obtener la discriminación de las horas trabajadas sobre equipos, plantas, etc. | 105 | Permitir registrar y controlar las horas reales trabajadas por persona / cargo, de acuerdo a las tareas realizadas. | 106 | Permitir registrar y controlar los tiempos de trabajo y tiempos no laborales (vacaciones, permisos, licencia médica, descanso, etc.) de modo que automáticamente tenga en cuenta estos tiempos al momento de la planificación, dando alerta de dicha situación y/o tomando medidas al respecto. | | GESTIÓN MANTENIMIENTO DE LOS ACTIVOS | 107 | Permitir asignar a equipos y materiales documentos según lo defina el usuario. Estos documentos pueden ser: Imágenes, textos, planillas de cálculo, planos, etc. Además asocia la aplicación para edición de esos documentos. | 108 | Permitir el análisis de los costos de mantenimiento. Debe ser versátil facilitando el análisis de distintos parámetros según lo solicite el usuario. (Ej. Real v/s. planeado, costos mensuales, costos de repuestos por equipo/ tiempo, etc.). | 109 | Permitir discriminar costos reales v/s planificados de acuerdo con las necesidades del usuario tanto en las “OTs”, como en los informes de costo (ejemplo horas de mano de obra, costos de la mano de obra, costo de los materiales y costos indirectos). | 110 | Permitir realizar análisis de fallas de acuerdo con los indicadores definidos por el usuario, además de indicadores estándar (tiempos medio de fallas, tiempo efectivo de funcionamiento, etc.). | 111 | Permitir realizar análisis integrados de la gestión de mantenimiento de acuerdo a parámetros estándar y definidos por el usuario. | 112 | Permitir visualizar en pantalla el gasto realizado en la OT por subítem de gasto. | | COSTOS Y PRESUPUESTO DE REPUESTOS | 113 | La solución deberá permitir mantener un control de costos y presupuestos al nivel de procesos y actividades, que le permita a la Gerencia hacer una buena gestión de éstos; a su vez poder controlar los costos individuales al nivel de cada uno de los equipos, flotas y unidades productivas. Ésta solución deberá permitir hacer gestión de costos a través de equipos y órdenes de trabajo, donde permita la visualización de costos de mantenimiento relacionados con Materiales, Labor y Otros tipos de costos. | 114 | La solución deberá permitir imputar un gasto a un centro de costo cuya naturaleza pueda ser de tipo Corriente, Reparación Mayor Activable o Capital de Inversión, además de mantener éstos tres tipos de presupuestos en el sistema. | 6.21.47.3.13.11 ADMINISTRACIÓN DE ÓRDENES DE TRABAJO (OT) Nro. | Funcionalidad | 1 | Permitir la generación de Solicitudes de Mantenimiento como etapa previa a la creación de las Órdenes de Trabajo. | 2 | El sistema debe permitir Solicitar trabajos de la siguiente manera: | | Registro del originador, Código de fallas (ruido, fuga, vibración, temperatura, aflojamiento, desgaste normal, desgaste anormal, Mantenimiento Preventivo no realizado, etc.) Código y ubicación del equipo Fecha del evento, turno y hora. | 3 | Registrar la Codificación de falla, Reporte de análisis de fallas (repetitivas, por turno, no comunes, por componente, por supervisor) Tiempo promedio entre fallas TPEF, Tiempo promedio por reparación TPPR, Confiabilidad, Reporte de cierre de OT. | 4 | Permitir la creación de Órdenes de trabajo, a partir de la Solicitud de Mantenimiento. | 5 | Permitir consultar desde una “OT” todas las Solicitudes de Mantenimiento asociadas a ella. | 6 | Permitir la asignación de una o varias Solicitudes de Mantenimiento a una Orden de Trabajo. | 7 | Permitir la creación de “OT” (ordenes de trabajo) para sistemas, equipos, componentes. | 8 | El sistema debe otorgar permisos de anulación de una Órdenes de trabajo en forma manual. | 9 | El sistema debe poder registrar el motivo de la anulación. | 10 | Permitir la creación de OTs de acuerdo al tipo de presupuesto (presupuesto corriente, reparación mayor activable, y cuentas contables. | 11 | Para el registro de la descripción, el sistema debe poder debe disponer de un campo “comentarios” que permita al registrar los comentarios y observaciones relacionadas con la reparación/mantención que se está solicitando. Debe permitir el ingreso de información suficiente para entender la naturaleza de las actividades, complejidad, etc. | 12 | Permitir la creación de trabajos estándar los cuales contienen, la descomposición en tareas, los desfases entre ellas, cantidad de recursos de mantención, listas de materiales, grupos de trabajo, etc., así como la estimación de costos (en línea) para estos trabajos. | 13 | Permitir manejar diversos estados básicos de una Orden de Trabajo de Mantenimiento (Ej.: en ejecución, en planificación, en espera, terminada, etc.) y otros estados secundarios. | 14 | Debe mantener información histórica de las mantenciones y reparaciones realizada a máquinas, equipos, etc. inventariadas en el Activo Fijo y de sus piezas. Se debe incluir como mínimo la siguiente información. | | · Equipo | | · Descripción de la mantención y/o reparación | | · Procedimientos utilizados y el tipo de intervención realizada. | | · Contratista | | · Proveedor del repuesto | | · Costos de repuestos y materiales | | · Costo en hrs. hombre | | · Fecha Inicio | | · Fecha estimada de término | | · Fecha de término | | · Responsable asignado | 15 | Permitir agrupar Órdenes de Trabajo de tal forma que se pueda consultar en línea los datos de costos estimados y reales de todo el grupo de “OTs”. | 16 | Permitir direccionar la autorización de las “OTs” a diferentes personas o cargos, según criterios definidos por el usuario. | 17 | Permitir interface o integración con MS Project (no se debe incluir el MS Project), y poder realizar Carta Gantt con la información del Trabajo a realizar. | 18 | Permitir asignarle fechas de ejecución a las Órdenes de trabajo, y llevar un control del tiempo utilizado en la ejecución de las tareas. | 19 | Permitir actualizar la disponibilidad real de un equipo en un período, una vez este haya terminado, con el fin de determinar horas reales disponibles. | 20 | Permitir la reprogramación de actividades comprometidas o liberadas por los mismos mecanismos de la programación original. | 21 | Permitir reprogramar la Orden de Trabajo y optimizar los recursos (nivelación de fuerza laboral /horas disponibles vs. horas requeridas). | 22 | Permitir la comparación gráfica entre recursos disponibles y requeridos para un grupo o grupos de trabajo. | 23 | Permitir visualizar en forma Gráfica, los estimados y reales y la varianza. | 24 | Permitir que un mismo trabajo estándar sea valorizado en forma diferente, dependiendo de factores como grados de dificultad, distancias, etc. | 25 | Permitir consultar el detalle de costos planeados y reales por tareas. | 26 | Permitir la asociación de “OTs” a proyectos creados en el mismo sistema, de tal forma que los costos reales y planeados hagan parte de la estructura de costos del proyecto. | 27 | Permitir obtener los costos de Órdenes de Trabajo, por jerarquía de equipos / grupos de equipos. | 28 | Permitir discriminar los costos de los trabajos de mantenimiento, teniendo en cuenta la Mano de Obra, repuestos, materiales, servicios de terceros, etc. | 29 | Permitir registrar y controlar el tiempo real por tarea realizada por empleado y/o cargo. | 30 | Permitir la obtención de informes personalizados por el usuario acorde a parámetros de solicitud, presentando sólo los datos deseados con la opción de impresión directa. | 31 | Permitir valorizar la OT con todos los costos asociados a ella y personal externo, materiales y repuestos, servicios de terceros, costo de equipos y grúas, compras, contratos etc. |

6.21.47.3.13.12 ADMINISTRACIÓN MANTENIMIENTO PREVENTIVO

Nro. | Funcionalidad | 1 | Permitir la programación de tareas repetitivas de acuerdo a parámetros de control, como calendario, horómetro, costeo de las tareas en términos de HH (HORAS HOMBRE) por especialidad. | 2 | Proveer facilidades internas para la construcción de programas de mantenimiento ya sean tareas repetitivas, Órdenes correctivas, etc. empleando criterios de período de trabajo, reprogramación automática de tareas no ejecutadas, etc. | 3 | Armado de rutas con equipos que pertenezcan al mismo padre en la jerarquía de equipos. | 4 | El sistema debe contener un análisis tendiente a obtener las causas de las fallas, la tendencia de fallas, pronósticos y probabilidades de las fallas. Para esto debe permitir configurar y utilizar jerarquías de falla, al menos de tres niveles (Problema – Causa – Solución) y vincularlas a los equipos en análisis. | 5 | Permitir la elaboración de listas de materiales involucrados en el mantenimiento preventivo. | 6 | Permitir suministrar informes de los pronósticos de recursos requeridos por período (mano de obra, materiales, equipos tipo herramientas, etc.). | 7 | Permitir el balanceo de recursos en forma gráfica. | 8 | Permitir interface con MsProject y poder elaborar carta Gantt. | 9 | La programación debe incluir: | | · Periodo cubierto, Planificador, Grupo de trabajo, recurso disponible y planeado. | | · Prioridad del Equipo, Numero Orden de trabajo, Descripción de la rutina, Duración, Fecha Inicial y Fecha Final, | | · Carta Gantt del trabajo Planeado como salida. | 10 | Control de paradas de Equipos de Proceso | | · Identificación de requerimientos de Trabajos y necesidades de recursos. | | · Definir niveles de autoridad para el control de pérdidas de Producción | | · Facilidad para cambiar fechas de programación en paradas mayores. | 11 | Generación automática de Órdenes de Trabajo basados en las rutinas de Mantenimiento preventivo y las estadísticas Operacionales de cada Equipo. | 12 | Control del personal y recursos dentro de los Grupos de Trabajo. | 13 | Acceso a Lista de Repuestos de Equipos. | 14 | Ajuste de la programación en forma manual (planeado y programado). | 15 | Identificación de requerimientos de recursos (mano obra, herramientas y equipos). | 16 | Reprogramación de tareas mediante el arrastre a un periodo no comprometido. | 17 | Distribuir automáticamente los recursos acorde con los desfases de las tareas de los trabajos estándares. | 18 | Múltiples unidades de intervalo de programación para Mantenimientos Preventivos. | | · Días | | · Semanas | | · Meses/Años | 19 | Mantenimiento Preventivo basado en Medidores (al menos 2 medidores en un mismo equipo), ejemplos: | | · Horómetros | | · Kilómetros | 20 | Mantenimiento Sintomático/Predictivo – Mantenimiento Basado en Condiciones (Sintomático). Ejemplo: Vibraciones, Análisis de Aceite, etc. | 21 | Mantenimiento Preventivo –mantenimientos preventivos multinivel (jerarquía) | 22 | Procedimientos de Trabajo Seguro – los peligros y precauciones pueden combinarse en planes de seguridad predefinidos y unidos una vez a los activos o ubicaciones para usarse en los trabajos. | 23 | Procedimientos de Trabajo Seguro – procedimientos de desconexión y reconexión y tarjetas de bloqueo. | 24 | Presupuestos – Comparativo de Presupuestos otorgados por centro de costo versus costos incurridos por centro de costo. | 6.21.47.3.13.13 MONITOREO POR CONDICIÓN Nro. | Funcionalidad | 1 | Permitir la definición de rutinas, frecuencias e identificación de puntos de muestreo para colección de datos. | 2 | Permitir integrar este módulo con el módulo de programación, estándares de trabajo, Órdenes de Trabajo, estadísticas operacionales. | 3 | Permitir la facilidad para definir niveles de precaución y de peligro, y que estos niveles disparen alarmas para realizar el monitoreo. | 4 | Capacidad de obtener las tendencias en forma gráfica de acuerdo a las muestras tomadas. | 5 | Que el sistema permita la entrada manual de los resultados de las muestras. | 6 | Que el sistema permita la entrada automática de los resultados de muestras. | 7 | Permitir mantener el registro histórico de los datos digitados. |

6.21.47.3.13.14 MATERIALES Y REPUESTOS Nro. | Funcionalidad | 1 | Se requiere que todo listado de partes tenga la cantidad requerida de repuestos para su reparación y la cantidad instalada en el equipo. | 2 | Se requiere tener la facilidad de crear un listado de partes requeridas para efectuar un trabajo específico de mantenimiento, incluyendo materiales incluidos en el inventario y repuestos susceptibles de compra directa. | 3 | Se requiere asignarle al listado de partes un responsable para su control y actualización. | 4 | Se requiere de un número de identificación para hacerle seguimiento a los componentes. | 5 | Se requiere que al crear un listado de partes se pueda registrar la siguiente información: | | · Materiales | | · Fabricante | | · Nº de parte, | | · Código de almacén | | · Grupo identificador a cual pertenece: Grupo - Clase | | · Cantidad instalada | | · Cantidad requerida | | · Descripción del listado de partes | | · Costos unitarios | | · Unidades de medida | | . | 6 | El sistema debe permitir, agrupar listas de partes, definir stocks mínimos, definir tiempos de reposición, definir frecuencia de uso, asignar responsables, catalogar ítems nuevos. | 7 | Permita registrar la información de componentes del mismo modo que se registra un Equipo: Fabricante, Número de Parte, Número de Ítem Catalogado. Tipo de Posición (Instalado), Estado, etc. | 8 | Efectuar la búsqueda de repuestos y materiales por proveedor | 9 | Permitir la actualización de la vida del componente, desde el momento en que se le registra la estadística de Operación al Equipo. | 10 | Realizar seguimiento a componentes enviados a reparar a terceros, Actividades a realizar, Transacción de seguimiento, Ingreso al almacén, Retiro del almacén, dado de baja, etc. | 11 | Facilidad para cargar automáticamente desde Excel al software, la información de registro de Equipos y Componentes. | 12 | Facilidad para generar reportes e informes de gestión. |

6.21.47.3.13.15 MODELO DE EQUIPOS/UBICACIONES FUNCIONALES Nro. | Funcionalidad | 1 | Manejo separado del concepto de Ubicación Funcional (Posición, TAG) del concepto de Equipo Físico (Número de Golpe). | 2 | Se deben definir los equipos con los siguientes atributos como mínimo: código, descripción, tipo o sub-tipo, N° de serie, fabricante, fecha instalación, etc. | 3 | Manejo Jerárquico multi-nivel ilimitado (no necesariamente de la misma profundidad) tanto para ubicaciones funcionales como para equipos (relación equipo – equipo componente / subequipo). | 4 | Se requiere llevar el historial de mantenimiento y costos al nivel de detalle que se requiera (cualquier nivel de la jerarquía definida). | 5 | Especificaciones Técnicas de equipos en jerarquía de clasificación de al menos 2 niveles (clase, subclase). | 6 | Generación automática de descripciones de equipos desde los datos de especificación. | 7 | Equipos – lista de materiales/partes (despiece de equipos). | 8 | Equipos – generación automática de lista de materiales/repuestos a medida que se cierran las Órdenes de trabajo en base al consumo de bodega asociados a la OT. |

6.21.47.3.13.16 ADMINISTRACIÓN DE PERSONAL MANTENIMIENTO Nro. | Funcionalidad | 1 | Permitir registrar y controlar la disponibilidad de mano de obra, para poder utilizarlo al momento de la planificación, así mismo se debe actualizar automáticamente en línea y en tiempo real en la medida de la utilización de esa mano de obra. | 2 | Mecanismo de Costeo de HH utilizada para distribuir los costos de la mano de obra basado en la cantidad de horas hombre (h/h) trabajadas en cada Orden de Trabajo y en el costo estándar estimado por hora de cada empleado, grupo de trabajo, especialidad, centro de costo, taller u organización. | 3 | Permitir obtener la discriminación de las horas trabajadas sobre equipos, plantas, etc. | 4 | Permitir registrar y controlar las horas reales trabajadas por persona / cargo, de acuerdo a las tareas realizadas. | 5 | Permitir registrar y controlar los tiempos de trabajo y tiempos no laborales (vacaciones, permisos, licencia médica, descanso, etc.) de modo que automáticamente tenga en cuenta estos tiempos al momento de la planificación, dando alerta de dicha situación y/o tomando medidas al respecto. |

6.21.47.3.13.17 GESTIÓN MANTENIMIENTO DE LOS ACTIVOS Nro. | Funcionalidad | 1 | Permitir asignar a equipos y materiales documentos según lo defina el usuario. Estos documentos pueden ser: Imágenes, textos, planillas de cálculo, planos, etc. Además asocia la aplicación para edición de esos documentos. | 2 | Permitir el análisis de los costos de mantenimiento. Debe ser versátil facilitando el análisis de distintos parámetros según lo solicite el usuario. (Ej. Real v/s. planeado, costos mensuales, costos de repuestos por equipo/ tiempo, etc.). | 3 | Permitir discriminar costos reales v/s planificados de acuerdo con las necesidades del usuario tanto en las “OTs”, como en los informes de costo (ejemplo horas de mano de obra, costos de la mano de obra, costo de los materiales y costos indirectos). | 4 | Permitir realizar análisis de fallas de acuerdo con los indicadores definidos por el usuario, además de indicadores estándar (tiempos medio de fallas, tiempo efectivo de funcionamiento, etc.). | 5 | Permitir realizar análisis integrados de la gestión de mantenimiento de acuerdo a parámetros estándar y definidos por el usuario. | 6 | Permitir visualizar en pantalla el gasto realizado en la OT por sub ítem de gasto. |

6.21.47.3.13.18 COSTOS Y PRESUPUESTO DE REPUESTOS Nro. | Funcionalidad | 1 | La solución deberá permitir mantener un control de costos y presupuestos al nivel de procesos y actividades, que le permita a la Gerencia hacer una buena gestión de éstos; a su vez poder controlar los costos individuales al nivel de cada uno de los equipos, flotas y unidades productivas. Ésta solución deberá permitir hacer gestión de costos a través de equipos y órdenes de trabajo, donde permita la visualización de costos de mantenimiento relacionados con Materiales, Labor y Otros tipos de costos. | 2 | La solución deberá permitir imputar un gasto a un centro de costo cuya naturaleza pueda ser de tipo Corriente, Reparación Mayor Activable o Capital de Inversión, además de mantener éstos tres tipos de presupuestos en el sistema. |

6.21.47.3 Recursos Humanos Se requiere de un sistema de Gestión de los Recursos Humanos de DISALCAR, que incluya distintos roles con características de tratamiento, cálculo de remuneraciones y control distintas. TIPOS DE ROLES | CARGOS REMUNERACIONES | DFL1 Empleados bajo el Código del Trabajo | DISALCAR | PNS Personal de Nombramiento Supremo, Médicos cuando son asimilados a Escala Jerárquica Institucional, también lleva las calificaciones respectivas, una vez por año. | CARABINEROS DE CHILE | PNI Personal de Nombramiento Institucional, también lleva las calificaciones respectivas una vez por año | CARABINEROS DE CHILE | CPR Personal Contratado por Resolución (a Contrata), también lleva las calificaciones respectivas una vez por año. | CARABINEROS DE CHILE | HONORARIOS | FONDO HOSPITAL | Esto permite distinguir entre Personal Civil y Personal Uniformado cuya información deberá ser privada. 6.21.47.4.13 Remuneraciones Se requiere que el proceso de cálculo de remuneraciones permita incorporar los haberes y descuentos que son propios de las diferentes modalidades contractuales vigentes. PERSONAL - REMUNERACIONES | N° | Funcionalidades | 1 | Manejar los regímenes de previsión privados y públicos, AFP, ISAPRES, CAJAS y otros. | 2 | En la presente situación, debe importarse las remuneraciones de todo el personal dependiente de CARABINEROS DE CHILE que presta sus servicios en el HOSCAR, es decir, el soporte correspondiente debe contener el "Costos Empresa" de haberes por funcionario y categoría, a fin de ser imputado a las correspondientes unidades de negocio. | 3 | Parametrización del cálculo de haberes conforme al Código del Trabajo, leyes especiales y propias de la administración pública, por ejemplo:
• Haberes imponibles.
• Haberes no imponibles.
• Haberes tributables.
• Haberes fijos.
• Haberes variables.
• Cálculo de excedentes.
• Devolución por días de licencias médicas.
• Generación de aguinaldos de fiestas patrias y navidad, imponibles y no imponibles.
• Bonos de carácter imponible y no imponible.
• Gestión de reajustes a las remuneraciones en forma anual y ocasional.
• Los cálculos deben ser generados en forma automática y parametrizable.
• Manejo de niveles y sub-niveles de sueldos y bandas salariales.
• Otros haberes.
• Cálculo de pago de turnos, refuerzos, horas extras y otros conforme al sistema de control de asistencia vigente en el establecimiento respectivo de DISALCAR.
• Considerar las Glosas asociadas a las Distintas Modalidades Contractuales Existentes, incluyendo Ley 15.076. | 4 | Parametrización de descuentos externos e internos de carácter previsional, legal y mantención de éstos. Por ejemplo:
• Manejo de descuentos previsionales y legales que afectan la remuneración del trabajador.
• Proceso de rebaja de licencias médicas y permiso sin goce de sueldo.
• Manejo de descuentos legales sobre aportes patronales: Mutual de Seguridad, Seguro de Cesantía, de Salud y otros.
• Debe contener estadísticas mensuales de cargas familiares por tramos y reajuste anual de éstas.
• Debe administrar el cálculo de la Retención Judicial del trabajador conforme a valores expresados en $ - U.F. - %.
• Manejar y administrar descuentos internos de Comisiones Administrativas.
• Descuentos Originados en Organismos Externos al Hospital y Retenciones Judiciales
• Mantención sobre prioridad de los descuentos en general.
• Descentralización del ingreso de descuentos de las diferentes Comisiones Internas del Hospital.
• Debe generar la liquidación del impuesto a la renta por cada funcionario o sociedad de profesionales, pudiendo permitir su modificación en cualquier período.
• Mantención y actualización de la tabla de impuesto a la renta.
• Mantención, ingreso y modificación de descuentos previsionales y otros.
• Cálculo automático de remuneraciones variables en la liquidación de remuneración de cada trabajador. | 5 | Manejar en forma automática los haberes y descuentos, lo que permite informar en forma masiva, para toda una planilla o un rango de empleados de ella, un haber o descuento. Por ejemplo, asignar a una planilla un bono especial o descontar un monto especifico por concepto de entrega de algún beneficio. | 6 | Ingresar por parámetros los niveles de renta y grados de la Escala Única, haberes y descuentos legales, haberes y descuentos informados, grupos de haberes y grupos de descuentos como base de cálculo de beneficios, tramos de impuestos, tipos de contratos, tipos de cargas familiares, etc. | 7 | Proceso de generación de liquidación de remuneraciones: Generación de liquidación de sueldo en cualquier momento y necesidad.
• Detección del alcance líquido.
• Debe considerar la confección de diferentes tipos de formularios de liquidación de sueldos (código del trabajo y honorarios). | 8 | Informar, modificar o eliminar haberes y descuentos en forma puntual para cada empleado. Por ejemplo, informar horas extraordinarias, pago de bonos, becas, o descontar anticipos, cuotas extraordinarias, etc. | 9 | El proceso de cálculo de descuentos debe completar el ciclo agregando los descuentos legales de salud, previsión e impuesto a la renta. Además, debe considerar los descuentos por concepto de anticipos, mutuales, cuotas de préstamos (cuando corresponda), los cuales deben considerar la interfaz a las instituciones que correspondan, por ejemplo DIPRECA, SIGFE II, entre otros. | 10 | El Sistema debe ser capaz de Generar el OUTPUT para el Pago Masivo en PREVIRED, de acuerdo a los formatos que corresponda | 11 | Incorporar el proceso de cierre mensual, generar el libro de remuneraciones y generar el Asiento Contable que será trasladado al Sistema de Contabilidad y al SIGFE II. Se hace presente que la unidad de remuneraciones es única pero maneja tres entidades diferentes. Esto implica la emisión de los tres Libros de Remuneraciones: Hoscar DFL 1, Hoscar Dipreca y Fondo Hospital. Odontológico. | 12 | Permitir relacionar todos los diferentes haberes y descuentos con cuentas contables y presupuestarias, y generar de manera automática la distribución contable de la preobligación, obligación, devengo y pago en el Presupuesto. | 13 | Manejar información histórica de los pagos realizados. Esto permite realizar en forma automática los procesos de reliquidación de haberes e impuestos que puedan requerirse, así como la emisión de certificados de renta. Calcular en forma automática el monto de la asignación familiar a percibir por los empleados, de acuerdo al imponible promedio de los últimos seis meses. En este caso, se necesita que los registros históricos de cualquier naturaleza del personal Ley N° 18.476 (Código del Trabajo) se mantengan con un intervalo en on-line de dos (2) años y una accesibilidad off-line de 5 (cinco) años consecutivos. | 14 | Registrar los movimientos de personal; por ejemplo, permisos sin goce de sueldo y licencias. | 15 | Registrar las cargas familiares incorporando la fecha de término del beneficio de la asignación. Contemplar, además, el trato de empleados que pertenezcan al régimen de previsión antiguo (Cajas de Previsión) con distintos tipos de cotización, y el personal recontratado, que tiene como previsión a DIPRECA. | 16 | Permitir el reajuste automático del nivel de renta (sueldo base), ya sea en un monto especifico o en un porcentaje | 17 | Permitir el pago de anticipos con la correspondiente emisión de listados para cuadratura y pago. Estos ‘pagos anticipados’ pasan en forma automática a descuento con el cálculo de la liquidación mensual. | 18 | Reportes estructurados. Por ejemplo:
• Informes previsionales: AFP, ISAPRES, FONASA, DIPRECA, INP y otros.
• Informes de aportes patronales.
• Ajuste de sueldos mensual.
• Resúmenes de haberes mensuales.
• Liquidación de descuentos mensual.
• Elaboración de estadísticas e informes a organismos externos al HOSCAR (INE, y otros).
• Informes de cuadratura de remuneraciones mensual.
• Informes contables.
• Centralización contable.
• Libro de remuneraciones y asientos contables.
• Reporte de presupuesto de gastos en personal, histórico y ocasional.
• Administración de trabajos estadísticos-históricos.
• Reportes de remuneraciones según necesidad.
• Resumen e indicadores de gastos en remuneración por categoría y Centro de Costo.
• Diferencia de las remuneraciones entre meses.
• Importación de remuneraciones del Personal Uniformado de Carabineros.
• Tabla de Escala Única de Sueldos / Estructura de Sueldos.
• Listado de grupos y subgrupos.
• Resumen de Planilla. Debe considerar todas las variables que intervienen en el pago de la remuneración de cada funcionario y categoría dentro del HOSCAR.
• Liquidaciones con cheque y sin cheque.
• Distintas formas de pago, incluyendo pago por nómina a través de bancos.
• Maestro alfabético de empleados.
• Resumen de haberes y descuentos por Código.
• Haberes y descuentos por empleado.
• Planilla de Honorarios a Suma Alzada.
• Asociación Chilena de Seguridad.
• Planillas de AFP.
• Planillas de ISAPRES.
• Planillas de INP. | 19 | Preparación y emisión de archivos exportables para cualquier entidad externa al Hospital, por ejemplo:
• PREVIRED.
• Depósitos a bancos.
• Mutual de Carabineros.
• Consorcios.
• Compañías de Seguros.
• Caja de Compensación.
• Crear archivo, para subirlo al portal del Bancoestado. Pago de Sueldos por transferencia electrónica. | 20 | Confección de planilla de pago mensual sujeta a la emisión de cheques y conciliación bancaria. | 21 | Integración con el sistema de control de asistencia vigente, sobre cálculo de todos los turnos, horas extras, ausencias del personal y otros. | 22 | Declaración operación renta anual de los diferentes impuestos a través de Internet. | 23 | Gestión y proyección parametrizada de cálculo de finiquitos e indemnizaciones por funcionario y Centro de Costo. | 24 | La ficha personal por funcionario debe tener un código asignado el cual debe ser irremplazable, así sea traslado a otra dependencia. | 25 | Calcular finiquito del personal. | 26 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. | 27 | Gestión abierta de periodos de devengo y distintos procesos de cálculo: nóminas, finiquitos, pagas extras, atrasos, etc. | 28 | Imputación de incidencias económicas a procesos actuales y futuros. | 29 | Incidencias económicas por unidades e importes, fijas y temporales. | 30 | Cálculos de devengos mensuales, por días naturales, por días laborables, por horas. | 31 | Gestión de anticipos: cálculo de cuotas, seguimiento del amortizado y saldo pendiente. | 32 | Asignación de importes a nivel general (categorías) y a nivel particular (empleados). | 33 | Diversos métodos de cálculo: proporcional, fijo, dependiente, por incidencias, por fórmulas. | 34 | Situaciones laborales especiales: jornada reducida, pluriempleo, alta sin cotización, ausencias. Asociadas a las distintas Modalidades Contractuales. | 35 | Gestión Asociada a Condiciones Especiales como: Accidentes laborales, Maternidad. | 36 | Distribución de los Costos de Remuneraciones a las Unidades de Negocio (Centros de Costo o Centros de Responsabilidad), en la cual el funcionario presta sus servicios. Si trabaja en más de una unidad de negocio, distribuir el costo en forma proporcional según tiempo aplicado. | 37 | Capacidad de Programar Transferencias Bancarias y/o Configurar la Generación Archivos de OUTPUT según requerimientos bancarios específicos. | 38 | Capacidad de Importar Sueldo Bruto (costo hospital) calculado por otra fuente, para un perfil de contrato y Rut específico en forma masiva. Capacidad para Distribución de los Costos de Remuneraciones a las Unidades de Negocio (Centros de Costo o Centros de Responsabilidad), en la cual el funcionario presta sus servicios. Si trabaja en más de una unidad de negocio, distribuir el costo en forma proporcional según tiempo aplicado. | 39 | El Sistema debe permitir calcular las remuneraciones correspondientes a las diferentes modalidades contractuales | 40 | Manejar Tablas De Indicadores Porcentuales Y Económicos Para El Calculo De Cotizaciones Previsionales Y Para El Impuesto Único, Según Su Variación (UF y UTM). | 41 | Informe Declaraciones Juradas Para El Proceso De Impuesto A La Renta. | 42 | Generar Archivos Mensuales De Respaldo Para Seguridad De La Información |

6.21.47.4.14 Viáticos. Registro y cálculo de anticipos y rendiciones de viáticos siguiendo la normativa, para cometidos funcionarios en el país o en el extranjero. Nro. | Funcionalidad | 1 | Permitir el ingreso de la “Resolución de Comisión y Anticipo de Viáticos”, es decir, documento que puede incluir el anticipo de viáticos de uno o varios funcionarios. Ingresar en forma automática desde una tabla el funcionario y todos aquellos parámetros necesarios para el cálculo del anticipo y su imputación presupuestaria de acuerdo a la normativa vigente. | 2 | La rendición de viáticos se debe realizar a través del ingreso del “Informe de cumplimiento de comisión y liquidación de viáticos”, y separar aquellas rendiciones que igualan el anticipo, de aquellas que necesitan reintegro o suplemento y ejecutar en ambos casos los ajustes generando la actualización en las cuentas respectivas. | 3 | Registrar en línea los montos de los viáticos en el Sistema de Presupuesto con la Pre obligación, Obligación, Devengo y Pago. | 4 | Manejar el historial por cada funcionario que haya sido registrado en el Sistema de Viáticos. Consultar los viáticos recibidos por funcionario en montos y días otorgados al mes y año a los diferentes porcentajes que exige la norma de gobierno. | 5 | Generar automáticamente el asiento a contabilidad por cada viático asignado. | 6 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. |

6.21.47.4.15 Administración De Personal Proceso de evaluación de desempeño, bienestar social, control de acciones de personal e información de los empleados y/o funcionarios durante su vida en la DISALCAR. ADMINISTRACIÓN DE PERSONAL | N° | Funcionalidades | 1 | Se requiere llevar Hoja de Vida del Personal con todos sus movimientos y una carpeta con información histórica, que permita registrar y controlar toda la información de la vida del funcionario durante su paso por la DISALCAR, entregando a Encargados de la Administración de Personal el apoyo para la toma de decisiones. | 2 | Se requiere Integración con Reloj Control | 3 | Capacidad de gestionar información privada o confidencial asociada a tipos de contratos del personal. | 4 | Capacidad de Administrar Distintos Tipos de Modalidades de Contratos (CPR, DFL1 AFP, DFL1 Dipreca, PNI, PNS y HONORARIOS) | 5 | Capacidad para permitir que una misma persona (empleado de las modalidades indicadas en 4), pueda tener dos contratos vigentes completamente diferentes, pero aplicados a horarios diferentes y excluyentes. Generando nominas, vacaciones y egresos independientes. | 6 | El sistema debe ser paramétrico, permitiendo definir flexiblemente el tipo de información que requiere manejarse según las necesidades del HOSCAR. Parametrizar: Corresponde a todos los procesos necesarios para determinar la información básica del sistema, tales como la definición de la estructura Organizacional, tipos de contratos, grupos, conceptos y descripciones. | 7 | Posibilidad de Agrupar el Personal por Tipo de Contrato y Asignar Privilegios o Roles para ser gestionados por determinados funcionarios o oficinas. | 8 | Capacidad de Gestionar Casos (Carpetas) de información variada de personas, incluidas fuentes externas digitalizadas) | 9 | Capacidad de Registro de Diario de Horas Extra | 10 | Capacidad de Generar Informes Acumulados y Cálculos Mensuales de Horas Extra a ser Incluidos en el cálculo de remuneraciones. | 11 | Capacidad de Administrar Procesos de Reclutamiento, en base a manejar Carpeta de Información del postulante (CV, Pruebas, Exámenes, etc.) | 12 | Capacidad de Proveer una Base de Datos de CV NO FUNCIONARIOS, que permita Registro y Mantención de Postulantes segmentados por especialidad. | 13 | Capacidad de Gestionar una Oficina de Partes de RRHH, digitalizando la información recibida, registrando el origen y destino y enviando la información a su destino. | 14 | Capacidad de registrar todas aquellas acciones que realizan los funcionarios durante su permanencia en la DISALCAR, tales como registro de Becas Estudiantiles, empleados sin solicitud de acumulación de feriados, cálculo de feriados, ayuda y préstamos de Bienestar Social y el ingreso de información (esto comprende a un conjunto de datos relacionados a Feriado Legal, Permisos Institucionales, Salidas al Exterior, Trayectoria Laboral, Hoja de Vida, Beneficios Legales, Viáticos, Licencias, Control de Asistencia). | 15 | Capacidad de Gestionar Sumarios (Caso tipo Sumario) en base a Carpetas de Casos, con responsables y seguimiento vía workflow (flujo de trabajo) del mismo y la inclusión de resoluciones en Hoja de Vida. | 16 | Capacidad de Gestionar un Registro Especial de "lista de revistas" (Tipo Oficina de Partes), con fecha de recepción, origen, detalle resumido de tema tratado. | 17 | Capacidad de dar Soporte para el Registro de Personal, mediante una funcionalidad integrada de Toma de Foto, Registro de Huella Digital Biométrica, Datos Varios, y que permita generar (imprimir) la Tarjeta de Identificación y Tarjeta de Estacionamiento, para los nuevos ingresados. Obs: Dependiendo de factibilidad técnica de incorporar drivers de equipos. | 18 | Capacidad de Registrar en la Hoja del Personal PERMISOS, TRASLADOS, y otros relacionados con el movimiento de personal | 19 | Capacidad de Gestionar Recursos Salas de Capacitación disponibles vía INTRANET asociadas a Cursos Dictados Internamente para la Inscripción del personal. | 20 | Workflow que permita aprobar la inscripción en los distintos cursos, por el encargado/responsable de cada curso. | 21 | Capacidad de Gestionar un Calendario de Cursos, con Fecha, Descripción, otros detalle y Documentos Anexos Descriptivos | 22 | Capacidad de Asociar Cursos y Recursos de Salas Disponibles. | 23 | Capacidad de Gestionar una Base de Cargos Disponibles con sus respectivas descripciones y perfiles buscados, indicando responsable y fechas relevantes. | 24 | Capacidad de Gestionar las Calificaciones de los Empleados, tales como la documentación de un determinado logro (Notas de Merito, Felicitaciones, Notas de Demerito y Reclamos) durante el período de evaluación de desempeño, donde se puedan añadir y eliminar en un entorno amigable a través de un sistema de archivos adjuntos. | 25 | Capacidad de derivar PMG de la Institución y Convenios de Desempeño a objetivos de personal de manera que los fines de los empleados dentro de la organización, se encuentren integrados a las necesidades de la entidad y de ésta forma puedan realizarse más concisas evaluaciones y valoraciones (Desarrollo de Personal) y la transferencia de resultados a Gestión de la Compensación | 26 | Capacidad de Integración con KIOSCOS de Autoservicio, en que el Funcionario pueda recabar información que el compete mediante su identificación biométrica. |

6.21.47.4.16 Reclutamiento, Mantención y Desarrollo de RR.HH Reclutamiento y selección, contratos, capacitación, desarrollo organizacional, control de asistencia Nro. | Funcionalidad | | Reclutamiento y Selección | 1 | Emisión de respuestas automáticas a las postulaciones realizadas a través del correo electrónico de selección o página de Web del HOSCAR. | 2 | Creación de plantillas electrónicas de requerimientos de personal generados por las distintas áreas del HOSCAR, ya sea por Aumento de Dotación, Cargo Vacante y Reemplazo, Evaluación Técnica u otras necesidades especiales. | 3 | Parametrización de:
• Currículums Vitae ingresados, ya sea por la página Web del Hospital, correo de Selección y los currículums físicos remitidos a RRHH.
• Entrevistas realizadas especificando los postulantes aceptados y rechazados.
• Registro de Concursos Internos realizados.
• Publicaciones realizadas en Diarios y el costo de éstas.
• Otros reportes y datos estadísticos de Selección, que la organización requiera. | | Desarrollo Organizacional | 4 | Incorporación del Sistema de Evaluación del Desempeño diseñado, aprobado y actualmente en uso en el HOSCAR, el cual debe considerar la creación y acceso a los siguientes sistemas de información de la organización:
• Sistema de Control de Asistencia.
• Distribución de Horas Médicas.
• Atención de Usuarios.
• Datos de contratos y otros antecedentes necesarios para el proceso de evaluación de desempeño. | 5 | Creación de herramienta que permita reportar la Trayectoria Laboral del personal, es decir, que contemple información tales como, cursos realizados, capacitación y otros. | 6 | Creación de un sistema de Gestión de Cargos, el cual permita registrar los Perfiles de Cargo del Personal del HOSCAR, y llevar a cabo la Evaluación de Cargos (ordenación de los distintos cargos, con respecto a ciertos factores, de acuerdo a la importancia relativa del cargo). | 7 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. |

6.21.47.4.17 Gestión de Alimentación del Personal del HOSCAR El Módulo de Alimentación gestiona las áreas de pacientes y de personal del HOSCAR en el sentido de generar los diferentes menúes y definir su aporte calórico y nutricional. La producción y distribución de la alimentación a pacientes y personal es responsabilidad de una empresa externa concesionaria del servicio. El módulo de Alimentación de Personal tiene como objetivo el control de acceso a la alimentación de los funcionarios del Hospital, además del registro de la información para desarrollar el proceso de descuento y gestionar información de estadísticas de las raciones que han sido proporcionadas al personal separados por servicio, centros de costo, unidad de negocios y por períodos de tiempo. Se debe mencionar que este módulo está directamente relacionado con el de Alimentación Clínica, ya que la administración de la alimentación en el Hospital se encuentra centralizada. Nro. | Funcionalidad | 1 | Integración del módulo de Alimentación con el módulo de Recursos Humanos. Identificación del funcionario y tipo de contrato asociado. Según el tipo de contrato, se valida si corresponde la emisión del vale de alimentación. | 2 | Integración del módulo de Alimentación con el módulo de Remuneraciones. Se realiza descuentos por planilla de sueldo de los consumos mensuales, según normativa del HOSCAR. | 3 | El módulo de integrarse o ser capaz de capturar las transacciones generadas por el sistema de administración de los vales de almuerzo. | 4 | Generación del vale de alimentación utilizando la tarjeta de identificación del funcionario.
• Las tarjetas de identificación del personal del HOSCAR son del tipo lectura por proximidad y también código de barra, pudiendo utilizar ambas tecnologías.
• La validación de personas se realizará sobre un dispositivo biométrico utilizando tecnología de verificación; es decir, se debe considerar que el código asociado a la tarjeta debe ser validado por medio de la huella digital. Los dispositivos lectores serán proporcionados por EL FONDO.
• La emisión del vale de alimentación debe estar validada contra la asistencia del funcionario al Hospital.
• Si el funcionario no porta su tarjeta de identificación, deberá permitirse la digitación del código asociado a ella, el cual se validará con la huella digital. | 5 | La inscripción periódica de los funcionarios para realizar consumos de alimentación se debe realizar por medio de la tarjeta de identificación. La inscripción se realiza automáticamente. El funcionario debe borrarse en caso de no asistencia. | 6 | Se debe permitir la generación de vales de alimentación para personas externas no registradas en el Hospital | 7 | Se requiere la capacidad de generación de diversas consultas y emisión de informes, según variados criterios establecidos a partir de información asociada a los módulos de Recursos Humanos y Remuneraciones.
Por ejemplo:
• Informes de Consumos versus Tramos de Descuentos según salario de los funcionarios.
• Informes de Consumos del Personal por evento (desayuno, almuerzo, cena y colaciones) y período.
• Informe de Cuadre de Vales Entregados versus Raciones/Menúes entregados. | 8 | Se requiere la capacidad de generación de informes de trazabilidad y auditoría de los eventos registrados. | 9 | Se requiere la capacidad de programación de menúes de eventos y su aporte nutricional. | 10 | Presentar otras funcionalidades no descritas anteriormente |

6.21.47.4 Homologación/Traspasos. 1 | Centros de Costo * Fármacos e insumos clínicos * Maestro (Catálogo) de Proveedores y Financiadores * Unidades de medida. * Servicios y Aranceles. | 2 | Presentar otras Homologaciones no descritas anteriormente * Compras-Existencias desde LEGADOS a ERP * Consumos de Fármacos e Insumos desde LEGADOS a ERP * Cargos/Pre facturas desde LEGADOS a ERP * Con equipamiento asociado a Farmacia y Almacén de Insumos Clínicos, como KÁRDEX (cantidad 2), y dispensadores automatizados ubicados en unidades críticas (UCI, UTI, Pabellón, Urgencias y otros). |

6.21 ESPECIFICACIóN DE HERRAMIENTAS DE GESTIóN 6.22.47 BUSINESS INTELLIGENCE (BI) Básicamente, Business Intelligence trata de una técnica que apunta a generar soluciones de información para la toma de decisiones dentro de una organización. El concepto de Business Intelligence resume una técnica de generación y organización de la información de una empresa para que sea útil al momento de la toma de decisiones por parte de los Directivos y Jefes de Áreas. Business Intelligence es un proceso donde se requiere: • Transformar DATOS en INFORMACIÓN. Consiste en recopilar datos repartidos en distintos sistemas, internos o externos a la organización, correlacionarlos y presentarlos de manera amigable y entendible para un analista. • Convertir INFORMACIÓN en CONOCIMIENTO. La información en manos de un analista, le permite comprender el comportamiento de la organización; puede descubrir la historia que hay detrás de las cifras. • Traducir el CONOCIMIENTO en DECISIONES. Al entender el comportamiento de la organización es posible tomar medidas que permitan mejorar el rendimiento y corregir anomalías. Por lo anterior, la herramienta de Business Intelligence a implementar deberá: * • Proporcionar acceso oportuno a información orientada al análisis. * • Permitir anticipar situaciones promoviendo una gestión y una toma de decisiones pro-activa. * • Sobre los Resultados del Hospital, permitir el acceso a toda la información del Hospital donde sea que esté el usuario. * • Permitir un ambiente único de acceso a toda la información de la institución, tal como indicadores de resultados, procesos e informaciones, planillas y gráficos de los datos. * • Proporcionar diversos modelos de plantillas para análisis gerencial, formateado de acuerdo con las mejores prácticas del mercado. * Realizar integraciones dinámicas con información. Las plantillas de análisis deben permitir que el usuario logre ver en detalle los datos originales de una información consolidada. * • Facilitar el acceso rápido a resultados diarios del Hospital, tales como facturación, informes financieros y estadísticas del servicio. * • Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente.

6.22.48 Cuadro De Mando Integral Hospitalario (Balanced Score card) Esta aplicación debe proveer una representación gráfica de los indicadores que se defina, con vistas que permitan que las diversas categorías de personas que accedan a esta información, tengan acceso al nivel de consolidación de la información que le corresponde según su perfil, a partir de la cual debe poder desagregar la información utilizando herramientas del tipo drill-in. El tiempo de refresco de la información se definirá en forma paramétrica. 6.22.49 DATAWAREHOUSE Esta aplicación debe poder formar Cubos y Datamart, incorporando datos que se que encuentren en diferentes bases de datos. Debe permitir la exportación de datos en formato SQL, EXCEL, MS-ACCESS y otros. 6.22.50 IR-GRD Esta aplicación debe capturar información desde la FCE y ERP a fin de generar la ponderación GRD a partir de los diagnósticos (CIE-10), código de prestaciones (CIE 9 MC) y cuenta de paciente. El resultado volverá a la FCE, mostrándose en el campo pertinente de la EPICRISIS.

6.22 La plataforma de integración: La solución debe incluir un software de integración que facilite los procesos de integración de la solución de FCE con el ERP y con los aplicativos legados, institucionales y externos. Adicionalmente debe permitir incorporar lógica de negocios. Se desea que el motor de integración: 5.5.1. Sea capaz de gestionar e interpretar diferentes conectores de acuerdo a la tecnología y plataforma de cada aplicación a integrar.

5.5.2. Permita el uso del Protocolo HL7 como mensajería estándar de datos relacionados con la atención del paciente, y funciones tales como: * Es deseables tener una Interfaz orientada a usuarios sin conocimientos de lenguajes de programación. * Envío de Alertas garantizado. * Control de errores y acciones compensatorias entre servicios. * Servicios de persistencia y trazado configurables. * Esquema extensible de puntos de comunicación basado en estándares (Web Services, FTP, TCP, Remoting). * Conectividad entre diferentes plataformas tecnológicas * Generación y Procesamiento de reglas complejas de negocios y transformaciones de datos. * Soporte a procesos de negocio. * Exponer interfaz común para la comunicación de aplicaciones * Permitir integrarse a nivel funcional o a nivel de datos. * Debe incorporar tecnología basada en estándares, como: * HL7 Versión 3.x. * Internet-HTTP, HTTPS. * XML-XPath, XSLT, * Web Services - WSDL, UDDI, SOAP. * Seguridad-SSL, * Conectores XML

6.23 EL PROCESO DE IMPLANTACIÓN. * 6.24.51 Metodología de implantación. La implantación en la Red de Salud de Carabineros, se iniciará en el HOSCAR. Se solicita que el oferente entregue una completa información de la metodología, secuencia y cronograma del proceso de implantación (carta Gantt referencial), individualizando los RRHH que aplicará con su correspondiente perfil, el tiempo que dedicará al proyecto cada uno de ellos y su correspondiente Currículo. Se valorará la experiencia previa en procesos de implantación de gran envergadura, que tengan las personas asignadas al proyecto.

El proceso de implantación deberá contener hitos que permitan medir los logros y avances. Estos hitos deben definir las condiciones de aceptabilidad y las responsabilidades atribuibles al proveedor y al FONDO. El cumplimiento de estos hitos deberá ser ratificado por el Comité Ejecutivo del Proyecto. Los Hitos de Pago no necesariamente corresponden a los hitos de avance a que se refiere el párrafo precedente. El cronograma propuesto podrá sufrir algunos ajustes, de acuerdo con las necesidades operacionales de la Red de Salud, lo que se concordará al inicio del proceso.

6.24.52 Cronograma general del proyecto Se solicita que el proveedor presente un cronograma tentativo que señale las actividades que se desarrollarán desde la fecha de la firma del contrato de adjudicación hasta la recepción definitiva del proyecto, con la solución operando en régimen. El cronograma solicitado deberá destacar y definir los hitos del proyecto, identificar los entregables, establecer la cronología de los informes de avance y definir el plazo máximo considerado. Se estima que la totalidad del proceso debe encuadrarse en un plazo máximo de veinticuatro meses. 6.24.53 Comité ejecutivo del proyecto Se constituirá un comité ejecutivo del Proyecto, formado por ejecutivos y mentores representantes tanto del oferente como del FONDO. Ésta será la instancia formal de comunicación entre ambos y su objetivo será la coordinación general del proyecto, la validación de las diversas etapas del proceso, la aprobación de ajustes puntuales en el alcance del proyecto, el cumplimiento de hitos, velar por el cumplimiento de los cronogramas propuestos, verificar y recibir los entregables previstos en el proyecto, supervisar los procesos de cambio y capacitación, como así también sus respectivas evaluaciones. Este Comité sesionará periódicamente, de acuerdo con el cronograma propuesto en la oferta, sin perjuicio de realizar reuniones extraordinarias si la situación así lo amerita. En su oferta, el oferente deberá señalar quien será su representante en este Comité y a la vez, el Jefe del Proyecto del Equipo del Proveedor. Esta persona debe tener un Titulo Profesional de un Área Vinculada con la naturaleza del proyecto y acreditar experiencia por haber participado en niveles ejecutivos en un mínimo de dos proyectos hospitalarios de similar o superior envergadura. El FONDO se reserva el derecho de aceptar al Jefe de Proyecto Propuesto por el Oferente u objetarlo durante la ejecución del proyecto, si a su juicio no reúne las competencias y experiencia necesaria. Dada la complejidad de este proyecto, se entiende que el Jefe del Proyecto propuesto por el oferente estará secundado por Coordinadores de Área, expertos en las aplicaciones de FCE y ERP, respectivamente, sin perjuicio que el Jefe de Proyecto propuesto pueda cumplir adicionalmente uno de estos roles (no ambos). 6.24.54 Aportes del FONDO al proceso de implantación: Sin perjuicio de los ajustes que resulte necesario efectuar de acuerdo con la metodología de trabajo propuesto por la empresa adjudicada, el FONDO otorgará las siguientes facilidades: a. Para los efectos del levantamiento y reingeniería de procesos, pondrá a disposición un equipo de profesionales de dedicación exclusiva, al que se adicionará los profesionales y funcionarios más representativos de cada uno de los procesos que se analizará. b. Colaborará activamente para hacer posible las integraciones con los sistemas legados propietarios y con los aplicativos comerciales en uso. c. Dará facilidades para la instalación de los aplicativos en los servidores que se adquirirá, o en el hosting que eventualmente se contrate, los que deberán quedar configurados en condición de alta disponibilidad. d. Pondrá a disposición un grupo de funcionarios que participaran en calidad de monitores para apoyar el proceso de capacitación del personal y puesta en marcha del sistema. e. Para apoyar el proceso de Gestión del Cambio, pondrá a disposición un sicólogo laboral con dedicación parcial al proyecto en el momento que resulte oportuno según el cronograma de trabajo. f. Una oficina o dependencia para ser usada por el proveedor (Jefe del proyecto y su equipo).

6.24 servicios conexOs con el proceso de implantación: 6.25.55 organización del equipo del proyecto Se entiende que un proyecto de la envergadura del presente requiere de la formación de equipos de trabajo constituidos por representantes de ambas partes, tanto en la gestión del proyecto como en el proceso de implantación. Al efecto, y con el objeto que el FONDO pueda dimensionar la calidad y cantidad de los RRHH que debe destinar a conformar estos equipos, se solicita al proveedor: * Definir cuales serían estos equipos de trabajo, su rol especifico y el tiempo de su funcionamiento, tomando como tiempo cero, la fecha de la firma del contrato de adjudicación. * Definir la composición de estos equipos, (incluir tanto los Recursos Humanos del oferente como los que deberá aportar el FONDO) indicando los perfiles, jornada de trabajo y horas estimadas aplicadas en la totalidad del proyecto. En el caso de los Recursos Humanos que deberá aportar el FONDO, las definiciones previas se entenderán como una sugerencia orientada a obtener un mejor resultado en tiempo, calidad y costo del proyecto.

Los representantes del oferente, se entenderán como una proposición, por lo que deberán identificarse claramente con su experiencia y formación. Además se deberá comprometer una permanencia mínima de un 80% del plazo para los componentes críticos del equipo del oferente.

* El oferente deberá entregar también una estimación temporal (mensual) del uso de los recursos humanos y una matriz donde estén claramente identificadas las responsabilidades asociadas al rol de cada uno de los integrantes de los equipos de trabajo. 6.25.56 Levantamiento y reingeniería de Procesos: El oferente deberá exponer en su oferta la metodología que empleará para realizar el levantamiento y reingeniería de procesos y presentar el Currículo y perfil de al menos dos profesionales que destinará a esta labor, los cuales deben tener experiencia comprobable en el tema. El FONDO se reserva el derecho de solicitar cambio de las personas propuestas por la empresa que resulte adjudicada, si a su juicio no reúne las competencias que le dé garantías de un resultado óptimo El rediseño de procesos deberá ser concordado con el equipo de trabajo del FONDO, y debe tender a privilegiar la adopción de los procesos incorporados al sistema adjudicado (tal como viene, asumiendo que esto representa mejores prácticas), en la medida que se cumpla con las funcionalidades requeridas en el capitulo 5 de las presentes Bases Técnicas. Los procesos deben estar alineados con el cumplimiento de disposiciones legales y reglamentarias vigentes en Chile país y en la Institución, necesidad que predominará sobre cualquier otra consideración. Los procesos que se concuerden deberán quedar debidamente documentados en formatos de archivos de libre acceso (por ningún motivo imágenes o PDF), a fin de incorporarlos en el alcance del proyecto. Aunque no es una restricción, se propone al oferente utilizar la notación Business Process Modeling Notation (BPMN) 1.0 o superior, e idealmente herramientas como “BizAgi Process Modeler”. Al menos dos licencias de uso de la herramienta utilizada deberá ser transferida en propiedad al FONDO. Para estos efectos deberá estimarse un cronograma de actividades, e indicar la cantidad de horas/persona que dedicará al efecto, la identidad y un CV resumido de estas personas. Debe aprovecharse la oportunidad de la actividad de rediseño de procesos, para lograr una actividad participativa de los funcionarios que el FONDO designe como contraparte, a fin de que esta actividad se articule con el proceso de gestión de cambio.

6.25.57 GESTIÓN DEL CAMBIO Por el fuerte impacto que tendrá en la personas la implantación del Proyecto “Sistema de Gestión Hospitalaria”, se otorga gran importancia a la Gestión del Cambio, por estimarse que es un FACTOR CRÍTICO DE ÉXITO, del cual dependerá en gran medida la suerte del proyecto. La Gestión del Cambio debe tener como factores integrantes * Un buen diagnóstico del perfil cultural y técnico actual que permita diseñar las acciones necesarias tendientes a asegurar la adopción del nuevo sistema por parte de los integrantes de la organización. * Desarrollo de una estrategia de comunicaciones destinada a lograr la aceptación y adopción del nuevo sistema por parte de los usuarios. * Desarrollo de un programa de capacitación a usuarios líderes y a usuarios generales que desarrolle las habilidades necesarias en el personal que operará el sistema mediante un acompañamiento continuo en el proceso. El oferente debe detallar la metodología de trabajo que propone y presentar a las personas que designará para gestionar el cambio, las que deben tener experiencia previa comprobable en implantaciones de esta magnitud. Idealmente una de estas personas debería ser de profesión psicólogo o profesión afín, con fuerte experiencia en procesos de gestión del cambio asociados a cambios de procesos e implantación de tecnología. Asimismo debe definir tanto los instrumentos y metodología de medición que se utilizarán para evaluar el impacto de las actividades realizadas durante las diversas etapas del proceso, como así también definir los rangos de aceptación que tendrá dicha evaluación. Se debe considerar un plan de contingencia para aplicar en el evento de lograrse evaluaciones insatisfactorias. En este aspecto del proyecto se debe explicitar la estrategia referencial que se empleará para lograr éxito en aspectos de motivación y participación de las personas, y contener una detallada descripción del Plan de Comunicación y Difusión y sus respectivos contenidos genéricos, los que deberán ajustarse a la realidad cultural de la Institución, con posterioridad a la adjudicación. Se espera que en virtud de la experiencia de la empresa, la oferta deberá incluir una enumeración de los riesgos que habitualmente se presentan en este tipo de proyectos, identificando los factores tanto internos como externos que puedan afectarlos e indicando su posible impacto y medidas de mitigación. Esta enumeración deberá ajustarse durante las primeras fases de la ejecución del proyecto tomando en cuenta la realidad y particularidades del HOSCAR. Se entiende que el proceso de capacitación forma parte importante de la gestión del cambio, por lo que además de la capacitación técnica, se espera una importante acción de coaching (acompañamiento) particularmente durante la marcha blanca, y un fuerte soporte de mesa de ayuda. Los antecedentes mínimos que se espera que el oferente proponga para esta etapa son los siguientes, sin perjuicio de las adecuaciones que deba ser necesario realizar en virtud de la experiencia adquirida por el adjudicado respecto de la cultura de la organización, durante el proceso de levantamiento y reingeniería de procesos: i. Metodología de Trabajo Marco. ii. Plan General de Dirección para la Gestión del Cambio. iii. Matriz del Equipo de personas que liderarán esta subproyecto y su experiencia. iv. Material Didáctico y Herramientas a utilizar. v. Plan de Comunicaciones y Difusión. vi. Matriz de Riesgos (a priori) del proceso y estrategias estimadas de mitigación propuestas. La Plan Definitivo de la Gestión del Cambio deberá ser emitido por el ADJUDICADO una vez terminado el proceso de reingeniería y deberá ser aceptado y validado por el Equipo del Proyecto del FONDO. 6.25.58 Plan de Capacitación Los usuarios de la FCE y ERP se estiman en unas 2.000 personas El oferente deberá proporcionar un equipo de capacitación compuesto por a lo menos dos personas, que cuenten con más de tres años de experiencia en actividades similares. Debe adjuntar los respectivos currículos. La capacitación se hará sobre la base de entrenar al entrenador, siendo de responsabilidad del adjudicado el logro de un nivel de conocimiento y destreza suficiente y adecuada para operar el sistema con fluidez.

Para estos efectos el oferente deberá presentar lo siguiente: a. Un plan de capacitación, incluyendo detalle de la metodología que se empleará y tiempo en horas de capacitación estimada para cada tipo de profesional (médico, enfermera, personal TI, personal administrativo usuario del ERP, otros profesionales) o para cada módulo. b. Criterios y metodología que se aplicará para evaluar los resultados de la capacitación, como mínimo se espera medir: a. Cantidad de personal por curso respecto del nominado por la institución b. Porcentaje de asistencia a sesiones (mínimo 85%) c. Satisfacción de los participantes según las encuestas de satisfacción entregadas al finalizar los encuentros c. Establecer un plan de contingencia para el caso que la evaluación de la capacitación resulte insatisfactoria. d. Proponer los medios audiovisuales que sean necesarios para llevar a cabo el proceso de capacitación. Es deseable apoyo de un aplicativo de e-learning proporcionado por el adjudicado, que pueda ser utilizado en la Intranet del HOSCAR e. Considerar reforzamiento de la capacitación de acuerdo con las brechas que eventualmente se perciban durante la marcha blanca f. Las actividades de capacitación y el material empleado debe estar en idioma español. El nivel de capacitación alcanzado por los usuarios debe medirse objetivamente mediante una metodología planteada por el oferente, la cual puede ser diferente para cada tipo de usuario, de acuerdo con la complejidad o intensidad de uso que deba hacer de los aplicativos adquiridos (profesionales, auxiliares paramédicos, administrativos). Debe garantizar la aprobación de la capacitación al menos para el 80% de los usuarios, siendo de su responsabilidad alcanzar esta meta, efectuando los reforzamientos y capacitaciones adicionales que sea necesario. Se debe recordar que como consecuencia de la integración y modificación de procesos, automatización de procesos e incorporación de validadotes automáticos, se modificará significativamente la forma de trabajo de los actuales funcionarios del área clínica y administrativa. Debe haber un plan especial de capacitación, para las personas que actuarán como ADMINISTRADORES DE FCE Y DE ERP y de las personas que operarán las diferentes herramientas del sistema (incluyendo aplicativos como BI, DWH, IR-GRD, y por ejemplo las herramientas de integración, generación de interfases de usuarios clínicos, generación de reportes, administrador de roles perfiles y privilegios,) y adecuarán las parametrizaciones del sistema y las tablas maestras. Se espera como mínimo el siguiente contenido: • Funcionalidades del sistema • Arquitectura funcional • Arquitectura técnica • Mantención de las Bases de Datos • Parametrización y Configuración del sistema • Uso de Herramientas del Sistema y Adicionales Utilizadas

6.25.59 Integración de aplicativos. 6.25.60.5 Integración con aplicativos legados. El HOSCAR cuenta con algunos sistemas de información que deben ser integrados, cuyo detalle se señala más adelante. El proveedor debe estar en condiciones de asegurar la interoperabilidad de los módulos/funcionalidades a ser integradas con la solución de FCE + ERP ofrecida, mediante la utilización de la plataforma de integración. La integración deberá estar basada en eventos que sean publicados en arquitectura SOA, que a su vez deben estar relacionados a reacciones que contienen la lógica de transformación y traspaso de datos. La integración con los aplicativos legados debe hacerse en conjunto con un grupo de profesionales y técnicos del FONDO, y proveedores del Hoscar, utilizando el software de Integración provisto por el oferente y cuya licencia quedará en propiedad del FONDO. Los trabajos de integración deberán quedar debidamente documentados en cuanto a formato, flujo, contenido y modo de comunicación. Todo esto deberá ser entregado en un Diccionario de Datos que contenga esta información y configuraciones en forma estructurada y ordenada lógicamente. Debe detallarse a modo ilustrativo un esquema de la arquitectura y metodología de la integración propuesta a priori y las características de la/las herramientas utilizadas. El desarrollo técnico que se aplique por parte del adjudicado, dependerá de las condiciones y características de los aplicativos a ser integrados. Los aplicativos o funcionalidades legados a ser integradas, son las siguientes: a. RIS – PACS (Productos FUJI. Cumple con estándares HL7) b. Aplicativo de radiología digital odontológica SIDEXIS XG c. LIS (INFOLAB – INFOCERO, con contrato de servicio vigente hasta el 11 de Octubre de 2013) d. Banco de Sangre (HEMATOS, del Grupo BIOS con contrato de servicio vigente hasta el 31 de Diciembre de 2013) e. Dispensadores Grifols y Omnicell f. Sistema Control Horario (Biométrico de Mano) g. Sistema de Licencias Medicas de Carabineros h. Sistema de facturación de la DIPRECA, que debe recibir archivos planos con los detalles de las cuentas de pacientes. i. SNACK (Sistema de Control de Vales de Alimentación) NOTA: En caso que el oferente opte por proveer el o los módulos de Laboratorio Clínico y Banco de Sangre, no será necesario considerar las integraciones correspondientes arriba indicadas. En su lugar debe integrar los equipos automatizados de laboratorio y migrar los datos históricos si técnicamente es posible. 6.25.60.6 Integración con sistemas externos. Entendemos que las integraciones con algunos sistemas estatales no serán factibles por razones técnicas de la contraparte. En estos casos dichas integraciones quedaran pendientes para ser realizadas cuando técnicamente sea factible, dentro del contrato de Operación, soporte y mantención post garantía. a. Sistema de Licencias Medicas de la Superintendencia de Salud (Cuando Técnicamente esté Disponible) b. Sistema de Licencias Médica de Carabineros en Chile (Batch) c. SIGFE II. (On-Line/ Batch) d. IMED. (On-Line) e. Mercado Público bajo estándar XBRL 4.0 o recomendación vigente de la Plataforma. (On-Line) f. SIGES (IFL o Batch) g. SICAR (IFL o Batch) h. FONASA (Consulta On-Line, si es técnicamente factible). i. DIPRECA (Batch) 6.25.60.7 Intercambio de información Clínica con otras Fichas Clínicas Electrónicas (“Pseudo Integración”).
Dado que los funcionarios de Carabineros pueden ser atendidos en hospitales o establecimientos de salud de otras Instituciones de Fuerzas Armadas, y miembros de las Fuerzas Armadas pueden ser atendidos en dependencias de Carabineros, surge la necesidad de intercambiar información clínica de los pacientes, a fin de facilitar los diagnósticos y tratamientos.
Como cada Institución tiene o puede llegar a tener diferentes productos de FCE, las integraciones formales entre ellas podrían resultar complejas y onerosas. Por esta razón se ha estado desarrollando en el país el concepto de “portabilidad de la información clínica”.
Esta portabilidad cuyos estándares aún no han sido definidos, consistiría en un mensaje HL7 complejo, conteniendo una serie de datos demográficos, y clínicos, dando cuenta de enfermedades crónicas, cirugías, alergias, uso de prótesis o trasplantes, tratamientos crónicos con medicamentos o tratamientos en curso.
El concepto al que hacemos referencia funcionaria del siguiente modo: El establecimiento que recibe un paciente que tiene FCE en otra Institución, solicita antecedentes del paciente a la Institución de origen, cuya sistema de FCE generaría este mensaje complejo, el que sería transmitido por vía electrónica en formato encriptado. La FCE receptora debería interpretar e incorporar este mensaje bajo el rubro “antecedentes previos”. Cuando concluya la atención del paciente, el aplicativo de FCE proveedora del servicio generaría a su vez un mensaje de características similares, conteniendo la información relevante del episodio clínico motivo de la atención prestada. Este mensaje sería recibido por la FCE de la Institución de origen del paciente y agregado como un episodio clínico ocurrido en establecimiento externo.
Si bien es cierto este tema esta en fase muy inicial para llegar a un acuerdo nacional respecto del método y de la estructura de la mensajería estandarizada, se plantea a los oferentes un desafío interesante, a fin de habilitar de alguna manera puertas de salida y entrada de estos mensajes para ser utilizadas en algún futuro próximo, dentro del contrato de mantención anual, con los contenidos que se acuerde.

6.25.60 Migración de datos: Deberá ser migrado:

a. El Archivo Maestro de Pacientes. b. Cuentas de Pacientes Vigentes a la Fecha (*) Abiertas c. Los datos de Anatomía Patológica que están en File Maker. d. Datos de Laboratorio y Banco de Sangre si el oferente opta por proveer estos módulos opcionales. e. Maestro de Productos, Insumos y Repuestos. f. Inventario actualizado a la fecha. g. Cuentas por Pagar y toda su información relacionada. h. Cuentas por Cobrar y toda su información relacionada. i. Maestro de Proveedores. j. Solicitudes de Adquisiciones en Proceso o No Aprobadas. k. Órdenes de Compra Aprobadas y en proceso de Abastecimiento. l. Base de Datos del Personal con todos sus datos. m. Saldos de Cuentas Corrientes en BANCOS COMERCIALES. n. Auxiliares de Cuentas Contables a la Fecha (*). o. Presupuesto de DISALCAR y del HOSCAR. p. Todos los Listados de Parámetros generales necesarios para la Operación. q. Configuración de Contratos Vigentes y toda su información relacionada. r. Facturas electrónicas Generadas, según normativa SII vigente s. Maestro de Máquinas y Equipos. t. Maestro de Activo Fijo. Nota (*): El concepto de “a la fecha”, se entiende como FECHA DE PUESTA EN PRODUCCIÓN.

6.25 Dimensionamiento del sistema. 6.26.61 LICENCIAS DE ERP Y FCE Para esta solución se debe proveer cómo mínimo, licencias suficientes para los aplicativos de ERP y FCE de acuerdo con el detalle de la cantidad de funcionarios de cada estamento declarados en el Capitulo 11, el que se incrementará considerando un crecimiento de un 10%. Se hace presente que los profesionales médicos y odontólogos por lo general tienen jornadas parciales que no exceden las 22 horas semanales, siendo frecuente, sobre todo en provincias la jornada puede no exceder de 11 horas semanales. El estamento de enfermería, por lo general tiene jornadas de 30 horas semanales. El personal auxiliar paramédico por lo general tiene jornada completa, al igual que el personal administrativo, usuario del ERP. También se hace presente que dado la estructuración de las personas usuarias del sistema caracterizadas por roles, perfiles y privilegios, sólo una pequeña proporción tiene acceso a la totalidad de los módulos, siendo lo habitual que los diferentes estamentos tengan acceso sólo a un módulo. Los volúmenes de producción en términos de atenciones ambulatorias y egresos hospitalarios se encuentran detallados en anexos. Los recursos humanos de las áreas clínicas y administrativas están señalados en el Capitulo 11 de las presentes Bases. En la TABLA DE EVALUACIÓN GENERAL, se plantea una puntuación especial para aquel oferente que otorgue uso de licencias para un número sin restricción de usuarios de FCE y ERP (denominado en estas bases como Licencia Corporativa). Para los efectos de las Licencias Corporativas que se menciona, se entiende que afectan a los aplicativos de ERP y FCE, quedando expresamente excluido en este concepto el licenciamiento del Motor de Datos, si es provisto por un tercero. Si el oferente opta por NO OFRECER licencias corporativas, el oferente deberá explicar, cuál será el Modelo de Licenciamiento ofrecido para el eventual crecimiento futuro del Proyecto y sus valores asociados, expresados en UF o Dólares Americanos. El FONDO entenderá que el Oferente MANTENDRÁ esta oferta de licencias de FCE y ERP, por el plazo de 5 años, a fin de que la Institución pueda proyectar eventuales crecimientos en la red de prestadores de establecimientos de salud que atiende a sus funcionarios y beneficiarios legales, utilizando la misma arquitectura tecnológica. Esta información es referencial y no forma parte de la oferta económica. 6.26.62 EL HARDWARE DEL / de los DATACENTER PRINCIPALes El oferente deberá definir el dimensionamiento técnico de los recursos de hardware necesarios para el correcto funcionamiento del Sistema, en condiciones de alta disponibilidad para garantizar un uptime de 99.7%., con balanceo de carga y redundancia en espejo de arreglos de discos que contienen bases de datos y archivos. Sin perjuicio que el oferente defina los requerimientos, a continuación se expresa algunas sugerencias que están vinculadas con la definición de la arquitectura del sistema a. Servidores:
Considerar mínimo dos maquinas físicas virtualizadas dispuestas en dos Racks normalizados independientes (los que podrían estar ubicados en diferentes centros de cómputos o Datacenter).
Máquinas para los motores de Bases de Datos (ver tipo de redundancia dependiendo de su eventual capacidad de operar en servidores virtuales)
Considerar servidores de dominio para los Establecimientos de la Red de Salud, servidores para generar reportes (reporting), para el DWH y para la herramienta de BI. Asimismo servidores para la capa de seguridad del sistema, para el antivirus, la firma electrónica, el IR-GRD, y para la herramienta de integración (middleware). Eventualmente también para los aplicativos de Laboratorio Clínico (LIS) y Banco de Sangre.
Considerar repositorio para imágenes JPEG, provenientes de equipos médicos, cámaras fotográficas y del escaneado de documentos.
Incluir necesidades de Switch de Core y otros dispositivos necesarios para la configuración del sistema en alta disponibilidad.

b. Software de virtualización. Considerar Software de Virtualización, el que sería adquirido OEM con el Hardware o contratado en un servicio de HOSTING.
La máquinas virtuales deben poder soportar los siguientes sistemas operativos: MS Windows 2003 (Estándar y Enterprise), Linux, Windows 2000 Server, Windows XP SP” y SCO Unix. c. Arreglos de discos externos:
Arquitectura SAN (Storage Area Network) con capacidad de 10 Tera Bytes reales en configuración RAID 5. Redundancia en espejo.

d. Respaldo de la data
Librería con dos drives LT04. o unidades de cinta virtuales en discos duros.

e. UPS
Establecer requerimiento de UPS. NOTA IMPORTANTE:
Todos estos recursos serán adquiridos por el FONDO o contratados como servicio de HOSTING, los que deberían estar disponibles al momento de la puesta en producción del sistema.
Se deberá configurar un ambiente de prueba transitorio para los trabajos de configuración y pruebas preliminares, utilizando temporalmente servidores y/o recursos alternativos, de propiedad del proveedor. * 6.26.63 LA IDENTIFICACIÓN BIOMÉTRICA La totalidad de los 250.000 beneficiarios y la totalidad de los profesionales y funcionarios del área clínica y administrativa, utilizaran este aplicativo para ingresar el sistema y/o validar acciones. También se utilizará para validar la firma electrónica privada. El proveedor deberá proveer las soluciones de biometría por huella dactilar que mejor se adapten y operen con su solución, orientado a minimizar el riesgo de implantación y puesta en producción. El hardware de captura de huellas dactilares será provisto por el FONDO. * 6.26.64 LA FIRMA ELECTRÓNICA PRIVADA Será utilizada por los profesionales del área clínica para certificar la totalidad de los documentos de acuerdo con las exigencias sanitarias y del Minsal y para evitar que los registros clínicos ingresados a la FCE puedan ser modificados a posteriori. 6.26.65 EL IR-GRD Se estima que un máximo de 5 personas trabajaran con este aplicativo. 6.26.66 EL DWH Se estima que un máximo de 3 personas trabajarán con este aplicativo. 6.26.67 LA HERRAMIENTA DE BI Los administradores u operadores de esta aplicación serán un máximo de 4. No obstante la visualización (vistas) de los tableros de mando serán utilizados por numerosas personas (clientes), quienes tendrán acceso a los niveles de agregación de la información de acuerdo a sus cargos. Todos deberán poder utilizar las herramientas de drill in, a sus respectivos niveles. 6.26.68 las Comunicaciones. La descripción y detalles de la topología de red local y de la Intranet Institucional de cobertura nacional, será entregada a la empresa adjudicada.

Se espera poder contar con una VLAN dinámica en la Intranet para garantizar un mínimo de ancho de banda para uso Clínico. * 6.26.69 las Estaciones de trabajo CLÍNICO. Los equipos PC actualmente existentes utilizan sistema operativo Windows XP y navegador Internet Explorer 8.x. Los equipos PC que se adquiera utilizaran sistema operativo Windows 7 e Internet Explorer 8.x y superior. Los aplicativos WEB a que se refiere la presente Base Técnica, debe correr en ambos sistemas operativos y versiones de Internet Explorer.

Se solicita información y recomendaciones de requerimientos técnicos para los equipos PC, dispositivos móviles de diversa naturaleza que permitan el trabajo junto al paciente, y otros dispositivos tecnológicos y periféricos que en la experiencia del oferente, agreguen facilidades, valor y movilidad al trabajo de los profesionales del área clínica. * 6.26 Seguridad del sistema. La oferta debe incluir la proposición de un modelo de arquitectura de seguridad, que considere un modelo de capas, un sistema centralizado de administración de usuarios para toda la Red de Salud, la utilización de identificación biométrica, la utilización de firma electrónica simple y con capacidad para gestionar firma avanzada (inicialmente sólo se utilizará firma simple), encriptación de datos transmitidos a través de redes públicas, procedimientos de respaldo de la información, procedimientos de recuperación de datos y sistema de auditoría de ingreso de usuarios y de fallas de la aplicación. Este módulo debe efectuar el control de acceso a la información disponible en la aplicación y bases de datos. Debe establece el nivel de seguridad de acceso del usuario a los diferentes módulos y funciones, dando acceso a un conjunto predefinido de acciones y funciones de determinados módulos. La configuración de roles con perfiles debe realizarse de manera de restringir o acotar acceso a datos, funcionalidad y estructura organizacional (1 servicio de 1 centro (centro = Establecimiento de la Red de Salud), n servicios de 1 centro, 1 servicio de n centros y n servicios de n centros) de forma independiente. Para asegurar la trazabilidad, cada acción de un usuario debe quedar registrada a nivel de servidores, en tablas (o archivos) de auditoría para su posterior control. Asimismo debe conservarse un registro auditable de la mensajería desde y hacia terceros. En caso de eventuales acciones de borrado de información, es deseable que éste borrado sea lógico y no implique borrado físico. El objetivo, en definitiva, es implementar medidas de seguridad en los diferentes componentes del sistema, a fin de garantizar en todo momento la privacidad, confidencialidad e integridad de la información clínica. a. Extremo cliente:
Definición de roles, reglas y perfiles. Autorización y autenticación de usuarios. Capacidad para identificación de usuarios empleando huella digital. b. Comunicaciones.
Las comunicaciones que se realicen, deben ser encriptadas (htpps con SSL). c. Servidores de aplicación.
Log de registro de transacciones que permitan efectuar auditorias
Log de registro de fallas percibidas y ocultas. d. Web Services.
Debe proveer servicio de autenticación. Debe llevarse un registro de transacciones. e. Servidor de Base de Datos.
Seguridad de la información.
Debe poder prevenir la corrupción de datos. f. Capacidad para definir tiempos máximos por sesión (Time Out). 6.27 Prueba general de la solución previo a la puesta en marcha. El proveedor presentará un Plan de Pruebas que empleará para el test general de la aplicación y sus integraciones antes de la puesta en marcha. En estas pruebas se verificará que el sistema realice los procesos definidos en la reingeniería y que se encuentren presenten las características funcionales y herramientas adquiridas en la licitación. El Plan de Pruebas debe ser técnicamente muy riguroso por tratarse de un hito trascendente del proyecto. Las funcionalidades y flujos deben ser aprobados por EL FONDO. Las observaciones que surjan deben resolverse en forma previa a la puesta en marcha del sistema. Se completará el test del software con las siguientes actividades que deben estar contenidas dentro del Plan de Pruebas (a aprobar por el FONDO) y quedar debidamente documentadas: a. Certificación de las Funcionalidades. b. Certificación de los procesos y flujos. c. Certificación de las herramientas propias de los aplicativos que han sido solicitadas. d. Pruebas del Sistema en ciclos normales con y sin sobrecarga. e. Pruebas de Borde (excepciones), con y sin sobrecarga. f. Situaciones de contingencia. Situación de componentes inoperantes. (Ej. inoperancia de la plataforma de integración o de aplicativos legados, fallas de equipamiento tales como: de maquinas físicas, de maquinas virtuales, arreglo de discos, red, desconexión de red eléctrica, UPS, desconexión de cables, falla de tarjeta de comunicaciones, falla del switch principal. Con posterioridad a la puesta en marcha en el HOSCAR, se deberá hacer las pruebas con los establecimientos de la Red de Salud ubicados en provincias. 6.28 CERTIFICACIÓN DEL SISTEMA. Con posterioridad a la aprobación de las pruebas de funcionamiento a que ha sido sometida la solución de FCE + ERP, el proveedor del o de los software deberá certificar el/los producto, incluyendo su configuración, normas de seguridad, parametrización, integraciones, interfaces y funcionalidades, certificando además, los estándares internacionales con que cumple. 6.29 Marcha blanca. La marcha blanca debe ser acompañada por el proveedor durante todo el proceso y será la oportunidad para hacer ajustes y optimizaciones. La correcta operación de todas las funcionalidades será una de las condiciones necesarias para la aceptación del producto.

6.30 Documentación y manuales de usuario y de servicio El proveedor de la solución integrada de FCE deberá proporcionar documentación y manuales en formato papel y digital escritos en idioma español de: 6.31.70 Manuales de aplicativos: De los diversos aplicativos que instalará, incluyendo los manuales técnicos de los software de FCE, ERP, DWH, de la plataforma de integración, de la herramienta generadora de reportes, de la herramienta de BIntelligence y demás aplicativos. 6.31.71 Manual de ayuda. Este manual digital está destinado a apoyar a la mesa de ayuda al usuario, para lo cual deberá describir en detalle todas las funcionalidades incorporadas en los diversos módulos del Sistema de gestión Hospitalaria. 6.31.72 Manuales de contingencia. Las situaciones de contingencia a que se refiere el punto 5.13.4.f y en particular las medidas de mitigación y reparación a ser aplicadas, deben ser adecuadamente documentadas en la forma de un manual. 6.31.73 Documentación: Deben quedar documentados los siguientes aspectos: a. La configuración de los servidores. (arquitectura, topología, direcciones IP, etc.). b. Las integraciones con aplicativos legados e Institucionales. (tanto para los mensajes de entrada como de salida, describir flujo de mensajes, formato y contenido. Formato de comunicaciones. c. La documentación de integraciones con sistemas externos, Describir flujo de mensajes, formato y contenido. Formato de comunicaciones. d. La documentación generada durante el proceso de implantación. e. La documentación de la configuración y parametrización del sistema para cada Establecimiento de Salud. f. La documentación de los planes de contingencia. g. Los procesos y flujo de procesos que se hayan implantado (reingeniería de procesos). h. Las parametrizaciones del sistema completo. i. Los reportes predefinidos incorporados a la solución. j. Los manuales de uso de las herramientas incorporadas al sistema. Deben permitir que los administradores expertos capacitados por el adjudicado, puedan hacer uso de dichas herramientas en forma autónoma. k. Modelo de Datos del Sistema. l. Librerías Utilizadas. m. Diccionario de Datos. n. Documentación de la capa de seguridad del sistema. o. Documentación del sistema de Identificación Biométrica. p. Documentación del aplicativo de firma electrónica privada. q. Documentación de la configuración de los tableros de mando. r. Documentación de la configuración del IR-GRD.

6 Garantía sobre los productos El oferente garantizará la integridad y correcto funcionamiento de la totalidad de los componentes de la solución ofrecida, incluyendo entre otros, los aplicativos y Software incorporados en la solución, durante al menos doce meses contados a partir de la fecha de recepción definitiva de la solución funcionando en régimen, la que se documentará mediante un acta suscrita por ambas partes, en el marco del Comité Ejecutivo. Debe definirse un protocolo para delimitar las responsabilidades por fallas que no correspondan al software ni a la configuración y/o a la arquitectura del sistema. Se entiende que todos los trabajos y servicios que se deban realizar dentro del periodo de garantía (operación, adecuaciones, soporte y mantención, integración de nuevos equipos clínicos), serán de cargo y costo exclusivo del oferente. Para los efectos de los trabajos de mantención reparativa durante el periodo de garantía, el oferente deberá indicar los tiempos de respuesta y de resolución de fallas, tanto para las fallas críticas como para las no críticas, entendiendo que se trata de un servicio crítico que debe operar en condiciones de alta disponibilidad. (Disponibilidad de uso del Sistema durante el 99.7% del tiempo). Previo al término de la garantía, el oferente adjudicado debe hacer entrega de la totalidad de la documentación del proyecto, como condición necesaria para la aceptación del producto. Se entiende que existen documentos que pueden ser entregados antes y que son necesarios para la capacitación de los administradores de las herramientas del sistema, y que hay otros que sufrirán modificaciones propias de los ajustes que serán necesarios realizar durante el periodo de marcha blanca y eventualmente de garantía.

7 servicio de OPERACIóN, soporte y mantención POST GARANTÍA del sistema Se solicita incluir en la oferta una propuesta y cotización de servicios anuales de Operación, Soporte y Mantención preventiva, reparativa y evolutiva, post garantía, y mejoramiento continuo, teniendo presente un horizonte de diez años. Esta cotización de servicio anual, deberá estar expresada en Unidades de Fomento, la que para los efectos de la evaluación económica será convertida a pesos chilenos al valor de la UF del día de apertura de las ofertas.

El servicio de Operación, Soporte y Mantención, debe contener los siguientes aspectos:

* Servicio de soporte de nivel secundario 24 x 7 * Supervisar y controlar la operación de la Mesa de Ayuda de Nivel Primario, que será provista por el proveedor de Hosting, el que será seleccionado en licitación pública independiente. El adjudicado tendrá derecho de opinión técnica en la redacción de las Bases de Licitación del Servicio de Hosting, teniendo presente que ejercer este derecho lo inhabilita para participar como oferente en la licitación del servicio de Hosting. El FONDO delegará la administración del contrato Hosting hacia el Adjudicado del Sistema de Gestión Hospitalaria, para lograr la máxima eficiencia y eficacia en la resolución de problemas, que permita obtener la disponibilidad requerida del sistema (el uptime) de un 99.7% del tiempo. * Para los efectos de operación y soporte remoto, el Contrato de HOSTING o el FONDO proveerá de una VPN de acceso a los servidores respectivos. * Proponer un plan de tiempos de resolución de problemas de acuerdo con la criticidad de la falla (definir listado de fallas críticas), acorde con la necesidad de mantener la operación del sistema en condiciones de alta disponibilidad con el uptime esperado de 99.7% del tiempo. El Servicio de Mantención debe contener los siguientes aspectos: * Instalación de updates y up grades de los software incorporados en el sistema ofertado. Ejemplo: FCE, ERP, IR-GRD, BI. * Renovación y/o actualización de las licencias de aplicativos provistos por terceros e incorporados en el Sistema Ofrecido. Ejemplo: IR- GRD. * Adecuación permanente del Software por cuenta del adjudicado, a los eventuales cambios en la legislación chilena y a la reglamentación del , Superintendencia de Salud, Servicio de Impuestos Internos, Dirección de Presupuestos (DIPRES) y Ministerio del Trabajo. * Integrar los nuevos equipos clínicos que el hospital adquiera. Ej. endoscopios, microscopios, monitores, bombas de infusión. * Ajustar las integraciones con los software legados que se renueve. Ej.: laboratorio clínico, banco de sangre. * Realizar las integraciones con los organismos estatales indicados en la lista de integraciones, que no hubiere sido técnicamente posible realizar durante la implantación, al momento que dichos organismos dispongan de las condiciones técnicas para su realización. Mejoramiento continuo: Debe incluirse dentro del concepto de Mejoramiento Continuo, la posibilidad de hacer cambios planificados en la estructura de la parametrización del sistema, nuevos desarrollos funcionales o de interfaces para incorporar nuevos equipos médicos diferentes de los existentes al momento de la implantación. Incluir al menos 400 horas/diseñador-programador/año con experiencia y conocimiento de las aplicaciones en uso, con el fin de incorporar validadores, nuevas funcionalidades, nuevas integraciones no previstas en esta licitación u otras adecuaciones. Estas 400 horas no necesariamente deberán ser ejecutadas dentro del mismo año, y podrán acumularse hasta completar un tope móvil de 3 años o 1.200 HH (horas-hombre) disponibles. Existirá una Planificación Conjunta de la Utilización de estos recursos (Carta Gantt Valorizada en Horas). No se considera para estos efectos las adecuaciones que deba hacerse para incorporar cambios legales y reglamentarios a Nivel Nacional e Institucional, debido a que estos deberán estar incluidos sin costo para el FONDO, en los conceptos de up grades, Updates o Parches. Que están considerados en el Contrato Anual de Soporte y Mantención post Garantía. Adicionalmente se deberá cotizar el valor referencial de la Hora - Hombre adicional, para la ampliación eventual de esta capacidad de 400 HH, para un profesional tipo DISEÑADOR-PROGRAMADOR. Para estos efectos la coordinación estará a cargo del Jefe de Proyecto del FONDO. Las comunicaciones vinculadas con los servicios de Operación, Soporte y Mantención, se entiende que deberán ser realizadas en el idioma español. Se entiende y se acepta que el monto cotizado para los Servicios anuales de Operación, Soporte, Mantención pueda ser desglosado en los siguientes rubros involucrados en este concepto: i. Mantención de Licenciamiento ii. Mesa de Soporte Segundo Nivel, Soporte up grades, Up dates, parches y Mejoramiento Continuo

Con posterioridad al periodo de Garantía, el FONDO suscribirá con la empresa adjudicada, un contrato anual de servicio de operación, soporte y mantención, el que se renovará automáticamente por períodos anuales, salvo que el FONDO comunique al adjudicado por carta certificada su intención de no renovar el contrato al vencimiento de la anualidad que se encontrare vigente. El precio del contrato anual se calculará convirtiendo el valor expresado en Unidades de Fomento IVA incluido a pesos chilenos al valor de la UF que corresponda a treinta días anteriores a la fecha de la iniciación del contrato o de sus renovaciones automáticas sucesivas. El proveedor entregará una boleta de garantía por fiel cumplimiento del contrato anual de servicio de operación, soporte y mantención, equivalente al 10% del precio del contrato anual con vigencia de 13 meses a contar de la fecha de inicio del contrato o sus renovaciones sucesivas. Esta boleta de garantía debe ser renovada anualmente ajustando su monto al nuevo valor anual calculado, procediendo el FONDO a hacer devolución de la boleta de garantía anterior, o del saldo remanente si se hiciera efectivo parte o todo el monto garantizado.

8 EVALUACIÓN DE LAs ofertas 9.31 INSTRUCTIVO PARA PRESENTACIÓN DE LAS OFERTAS * Adicionalmente a la entrega la oferta a través del sistema de información de mercado público por los procedimientos normales, deberá presentar TRES COPIAS impresas de la oferta técnica y cuatro ejemplares en CD, las que deberían ser entregadas en SIMON BOLÍVAR 2200, Piso 4, Ala Oriente, del Edificio Corporativo de DISALCAR (Interior), Departamento de Contabilidad y Finanzas de la Dirección de Salud, a más tardar en la fecha de cierre de la presentación de las ofertas (de Lunes a Viernes, en Horario Hábil, de 8:30 a 13:00 hrs., y de 15:00 a 17:30 hrs.). 9.32.74 Listado de Chequeo de documentos a presentar Documentos Legales Requeridos en Bases Administrativas | Referencia a Bases Técnicas | Instrucciones | 8.1.1.1 | | Constitución de Sociedad Oferente y Detalle de Socios | | Debe presentar los documentos de la Constitución de Sociedad y Vigencia del Oferente, Detalle de Composición del Directorio y Poderes del Representante Legal debidamente actualizados. | 8.1.1.2 | | Poderes Otorgados por las Empresas Representadas por el Oferente en esta oferta, en Calidad de "Representante", "Asociado Comercial (Partner)", "Consorcio" u otra figura legal | | Deberá presentar los poderes de la Representación de las Empresas Representadas por el Oferente Vigentes y Legalizados en Chile. | 8.1.1.3 | | Estados Financieros últimos 3 años (del Oferente y de la o las empresas matrices representadas en esta oferta) | | Deberán presentar el Detalle Resumido de Estados Financieros del Oferente y de las Empresas Representadas. | 8.1.1.4 | | Carta de Compromiso (Commitment) | | En el caso de Fabricantes Internacionales, se deberá presentar una "carta de compromiso" en que el fabricante de los productos de FCE y ERP incorporados al proyecto, se compromete a responsabilizarse por el funcionamiento de sus productos y a proveer las actualizaciones futuras de su tecnología, independientemente de quien sea su representante en Chile. Este documento deberá estar debidamente firmado por el mismo firmante de los poderes de su representante en Chile o su sucesor legal. | 8.1.1.5 | | Identificación de otros Proveedores de Herramientas de Software involucrados en el proyecto de esta oferta (todos) | | Deberá presentar la identificación (fabricante, distribuidor a quien se ha adquirido, dirección, teléfonos, contactos) de los fabricantes y proveedores de todas las herramientas de software involucradas en su solución ofertada | | | | | | Documentos Obligatorios Requeridos en Bases Técnicas | | | 8.1.2 | OFERTA TÉCNICA | | | | 8.1.2.1 | Descripción Sistema Ofertado | | La descripción deberá contener como mínimo los siguientes acápites:
(1) Entendimiento del Concepto del Proyecto y sus Objetivos.
(2) Descripción del Funcionamiento General y Arquitectura de Software del Sistema Ofertado y su Plataforma.
(3) Detalle de Módulos Funcionales de FCE y ERP.
(4) Detalle de Herramientas de Integración Incorporadas y Funcionalidades.
(5) Detalle de Identificación y Funcionalidad de Aplicaciones Complementarias tales como: Firma Electrónica Simple o Privada, IR-GRD, Solución de BI, Solución de Datawarehouse, Validación Biométrica de Identificación.
(6) Descripción de Metodología propuesta para llevar a cabo el Proyecto.
(7) Describir y Explicar la Metodología de Soporte Secundario (técnico) ofrecido, el Roadmap de Releases Planificados, la estrategia ofrecida para soportar el mejoramiento continuo en este proyecto.
(8) Descripción de la Estrategia, Herramientas y Enfoque de Aseguramiento de calidad para el proceso de Migración de datos.
(9) Diseño y Enfoque de Plan de Pruebas para Puesta en Marcha del Sistema. | | 8.2.2.2 | Plan Maestro del Proyecto (Gantt Preliminar), acotado al plazo máximo de 24 meses del Proyecto (puede ser menos tiempo si el oferente lo estima). | | Se requiere que el Oferente presente un Plan Maestro Integral Preliminar (en MS PROJECT 2007) para todo el proyecto a desarrollar, con las actividades debidamente identificadas, sus dependencias, recursos involucrados, plazos, HITOS claramente indicados (hitos Funcionales y también aquellos vinculados con los hitos de pago indicados en las Bases Técnicas-Capítulo 10). | | 8.1.2.3 | Organización Propuesta para el proyecto | | Deberá indicar cual será la organización que el oferente plantea para la ejecución del proyecto, mencionando los recursos humanos que aportará el oferente, sus roles y responsabilidades.
Además se solicita que el Oferente sugiera los requerimientos de Recursos Humanos que espera sean puestos a disposición por parte del FONDO para asegurar un proyecto exitoso. | | 8.1.2.4 | Detalle Curricular, Funciones y Jornada de Trabajo Asignada a cada uno de los integrantes del equipo | | El oferente debe aportar la información de las personas propuestas para desempeñar los roles y responsabilidades descritos en la organización. | | 8.1.2.5 | Plan de Gestión del Cambio y Capacitación Propuesto | 8.10 | Deberá efectuar una descripción del marco metodológico que utiliza el oferente para los procesos de gestión de cambio y capacitación en proyectos de esta naturaleza y envergadura. El oferente deberá señalar al menos tres (3) casos de aplicación exitosos y sus indicadores de resultados, en cada uno de los dos (FCE y ERP) rubros. | | 8.1.2.6 | Modelo de Licenciamiento para Crecimiento futuro de los productos ofrecidos (Licencias Adicionales), para FCE y/o ERP. | 5.8.1 | Si el oferente no opta por ofrecer licencias corporativas en los términos expresados en el punto 8.1.2.7 que sigue, el oferente deberá explicar, cual será el Modelo de Licenciamiento ofrecido para el eventual crecimiento futuro del Proyecto y sus valores asociados, expresados en UF o Dólares Americanos. | | 8.1.2.7 | Pronunciamiento sobre Eventual Oferta de Licencias Corporativas de FCE y/o ERP | 8.9 | El Oferente deberá manifestar, si opta o no opta, por ofrecer licencias corporativas para los productos FCE y/o ERP, a fin de determinar la modalidad de puntuación que se aplicará a este rubro en la matriz general de evaluación. | | 8.1.2.8 | Pronunciamiento sobre Eventual Inclusión de Módulos de Laboratorio y Banco de Sangre | 8.11 | El Oferente deberá manifestar si opta o no opta por incluir en su oferta los Módulos de Laboratorio y Banco de Sangre, a fin de determinar la modalidad de puntuación que se aplicará a este rubro en la matriz general de evaluación. | | 8.1.2.9 | Propuesta de Mantención Licencias, Soporte 2do Nivel Post-Garantía y Mejoramiento Continuo | 8.6 | El Oferente deberá completar la Tabla de Evaluación Técnica, indicada en el punto 8.6 de las Bases Técnicas. | | 8.1.2.10 | Tabla de Cumplimiento de Requisitos Obligatorios | 8.2 | El Oferente deberá completar la Tabla de Cumplimiento de Requisitos Obligatorios. | | 8.1.2.11 | Dimensionamiento y Arquitectura de Hardware Recomendada por el Oferente para el Funcionamiento Óptimo de su Solución en condición de Alta Disponibilidad | | El Oferente deberá realizar una propuesta de dimensionamiento de hardware para el funcionamiento en alta disponibilidad de su solución, incluyendo ambientes de prueba, producción y desarrollo, en arquitectura virtualizada. Se deberá detallar las capacidades y datos técnicos genéricos de los distintos componentes, a fin de que el FONDO proceda a Adquirirlos o ha requerirlos en Servicio de Hosting. | 8.1.3 | PLANILLAS DE AUTOEVALUACIÓN | | | | 8.1.3.1 | Autoevaluación de Experiencia de la Empresa y Documentación de Respaldo | 8.4 | El Oferente deberá completar la Tabla de autoevaluación de experiencia de la empresa y presentar la documentación de respaldo. | | 8.1.3.2 | Autoevaluación de Funcionalidades FCE | 8.7 y 12 | La deberá presentar, de acuerdo a los formatos señalados. | | 8.1.3.3 | Autoevaluación de Funcionalidades ERP | 8.7 y 12 | La deberá presentar, de acuerdo a los formatos señalados. | | 8.1.3.4 | Diseño de Prueba de concepto y Detalle de Funcionalidades a aprobar (Tabla de auto llenado) | 8.8 | El oferente deberá completar la tabla de auto llenado. | | | | | | 8.1.4. Oferta Económica | | | | | 8.1.4.1 | Oferta Sistema Gestión Hospitalaria | 8.5 | El Oferente deberá presentar la oferta económica. | | 8.1.4.2 | Oferta de Mantención Anual de Licencias y Soporte de segundo nivel y mejoramiento continuo. | 8.6 | El Oferente deberá presentar la oferta correspondiente. | | | |

8.1.5 Instrucciones para EL completado de planillas de Autoevaluación
Se proporciona planilla Excel formato MS-Office 2003 denominada “PLANILLA DE AUTOEVALUACIÓN DE FUNCIONALIDADES.XLS” para ser completada por los oferentes en los siguientes rubros: a. Características Técnicas Mínimas Exigidas. b. Evaluación de las funcionalidades de los módulos de la FCE. c. Evaluación de las funcionalidades de los módulos de la ERP. d. Definición de ítems evaluables para la Prueba de Concepto.

8.1.6 Recomendación
Es importante que en general los temas desarrollados en las ofertas técnicas sigan el mismo orden que el presentado en estas Bases Técnicas en los Capítulos 4 y 5 y en particular que el Oferente, aporte en forma ordenada y sistemática la información que facilitará a la Comisión Evaluadora, formarse una opinión para los efectos del llenado de las tablas de evaluación que se publican a continuación. 8.1 CARACTERÍSTICAS TÉCNICAS MÍNIMAS EXIGIDAS. CONDICIÓN PREVIA A LA EVALUACIÓN. El Oferente, deberá indicar si su producto cumple o no cumple con cada uno de los requisitos mínimos exigibles expresados en la siguiente Tabla. Para cada característica técnica (cada fila), el oferente DEBE LLENAR la columna “TRAZABILIDAD”, indicando claramente el documento, página y párrafo de la oferta técnica, en que se encuentra el respaldo de dicha aseveración. NOTA IMPORTANTE: Para continuar participando EN LA EVALUACIÓN, el oferente DEBE CUMPLIR con la totalidad de las características mínimas exigidas, de acuerdo con la siguiente tabla: CARACTERÍSTICAS TÉCNICAS MÍNIMAS EXIGIDAS TIPO DE CARACTERÍSTICA MINIMA EXIGIDA | CARACTERÍSTICA | CUMPLE | NO CUMPLE | TRAZABILIDAD. Documento y página de la oferta en que se encuentra la información | ARQUITECTURA Ref.: 2.3.1. | | | | | A | Operación WEB | | | | B | Arquitectura centralizada. | | | | C | Operar Multiempresa. | | | | D | Operar Multicentro. | | | | E | Arquitectura modular del Sistema (esto es, constituido por subsistemas funcionales independientes, integrables entre si), idealmente basados en Arquitectura SOA con interfaz en formato HL7. | | | | F | Ser escalable en cuanto a módulos en uso y en cantidad de usuarios nombrados y/o concurrentes. | | | | G | Parametrizable, de modo tal que el administrador del sistema pueda configurar las funcionalidades, sin que sea necesario programación y acceso a bajo nivel de datos. | | | | H | Capacidad para diseño asistido de reportes, formularios y pantallas auxiliares, con herramientas gráficas adosadas al Sistema. | | | | I | Capacidad de integrar aplicativos, mediante el uso una plataforma de integración. (Midleware). | | | | J | Utilizar navegador Internet Explorer 7.x y superior y deseablemente, también Mozilla Firefox. | | | | K | Debe tener capacidad para utilizar autenticación biométrica de usuarios pacientes y funcionarios (huella dactilar) | | | | L | Debe operar en ambiente virtualizado y soportar configuración en cluster con balanceo de carga. | | | | M | Debe operar en condiciones de alta disponibilidad (99.7), con redundancia de servidores y de dispositivos de almacenamiento de datos y archivos. | | | | FUNCIONAL Ref.: 2.3.2. | | | | | A | Interfaces de usuario en idioma español (de uso en Chile). | | | | B | Debe desplegar imágenes (Ej. De exámenes de Imagenología (DICOM 3), de monitores clínicos, imágenes JPEG, otras). | | | | C | Debe poder escanear y guardar documentos capturados a nivel de las estaciones de trabajo, los que deben formar parte de la FCE. | | | | D | Debe poder adaptar las interfaces (pantallas) de usuario a las necesidades clínicas específicas de cada especialidad o subespecialidad, mediante un Framework susceptible de ser operado por el administrador del sistema. | | | | E | Se debe poder modificar los nombres con que se identifican los campos en las interfases de usuario (etiquetas o labels), a fin de incorporar terminología local. | | | | F | A fin de poder cumplir con las actividades docentes, el sistema debe permitir la creación de varias categorías de alumnos-usuarios, quienes podrán ingresar datos en la FCE utilizando caracteres de color a fin de ser identificado fácilmente, en calidad de “registro transitorio”, el que podrá ser borrado, modificado o validado por un profesional usuario normal, tras lo cual, el registro será inmodificable. Debe haber algún sistema que advierta al médico tratante (responsable del paciente) de la existencia de estos registros transitorios, que no han sido validados. | | | | G | Debe tener un Log de registro de transacciones que permita efectuar auditorias (que, quien y cuando hizo). | | | | H | Debe proveer, utilizar y administrar una firma electrónica privada (simple), acorde con la legislación chilena. | | | | I | Debe cumplir con la reglamentación y legislación Chilena vinculada con la privacidad de la información sensible. | | | | J | Debe poder incorporar fotografías digitales desde los módulos de uso clínico. | | | | K | Trazabilidad de las acciones realizadas y de la información almacenada en el sistema FCE (cumpliendo todos los estándares de confidencialidad y protección de datos del paciente). | | | | L | Estandarización de procesos transversales para toda la Organización, a partir de la reingeniería de procesos. | | | | M | Estandarización de la información clínica y administrativa. | | | | N | Debe permitir configurar y gestionar programas de salud ministeriales e institucionales, tanto en pacientes pediátricos como en adultos y medicina familiar. | | | | O | Debe permitir la gestión del concepto de medicina familiar en los CESFAM (Centros de Salud Familiar), utilizando diagramas de vinculación parental. | | | | ESTÁNDARES Ref.: 2.3.3. | | | | | A | Aplicativos y módulos integrados entre sí e integrable con otros aplicativos mediante estándares HL7. | | | | B | Utilización de estándares HL7, CIE 10, DICOM 3, SNOMED. | | | | C | Debe utilizar código de barras EAN-13, EAN-128, DUN-14, Datamatrix, (impresión y lectura de etiquetas) desde terminales fijos y móviles (inalámbricos). Debe soportar los drivers de los dispositivos correspondientes. | | | | D | Debe proveer Manuales de usuario y Documentación en Español | | | | E | * Debe utilizar el RUT con dígito verificador, (debe incorporar algoritmo de cálculo del dígito verificador) como identificador principal. | | | | SEGURIDAD Ref.: 2.3.4. | | | | | A | Debe disponer de niveles de seguridad de acceso, configurables en cuanto a datos, a funcionalidades y a estructura organizacional. | | | | B | El sistema deberá ser capaz de ejecutar la Autorización y Autenticación de Ingreso. | | | | C | Capacidad de generación y configuración de roles, reglas y privilegios por parte del administrador. | | | | D | Capacidad de encriptación de datos en las comunicaciones. | | | | E | Capacidad de generar alertas ante incidentes de seguridad predefinidos. | | | | F | Debe utilizar un sistema biométrico de huella dactilar como validador de la identificación. | | | | G | Ofrecer garantía que los accesos a la FCE cumplan con la Ley 19.628 de Protección de Vida Privada o datos de carácter personal. | | | | | | | | | | | | | |

TIPO DE CARACTERÍSTICA | CARACTERÍSTICA | CUMPLE | NO CUMPLE | TRAZABILIDAD. Documento y página de la oferta en que se encuentra la información | POLÍTICA DE MANTENCIÓN DE SOFTWARE Ref.: 2.3.5 | LA MANTENCIÓN DEBE NECESARIAMENTE INCLUIR | | | | A | Actualización (up dates y up grades) de los software incorporados en el sistema ofertado | | | | B | Instalación de Updates y Parches | | | | C | Instalación de Upgrades | | | | D | Integrar los nuevos equipos clínicos que el hospital adquiera. | | | | E | Ajustar las integraciones con los software legados que se renueve. | | | | F | Compromiso de realizar las integraciones con los organismos estatales indicados en la lista de integraciones, que no hubiere sido técnicamente posible realizar durante la implantación, al momento que dichos organismos dispongan de las condiciones técnicas para su realización. | | | | G | Mejoramiento continuo: proveer al menos 400 horas/programador/año acumulativas. | | | | | | | | | 8.2 TABLA DE EVALUACIÓN GENERAL El Fondo, designará a las personas que constituirán el Comité de Evaluación Técnica, el que tendrá por función la realización de la evaluación técnica de las ofertas, aplicando las siguientes pautas generales: | TABLA DE EVALUACIÓN GENERAL | PUNTOS | 1 | EXPERIENCIA DE LA EMPRESA | 5 | 2 | PRECIO | 10 | 3 | EVALUACIÓN FUNCIONAL CLÍNICA | 15 | 4 | EVALUACIÓN FUNCIONAL ERP | 15 | 5 | PRUEBA DE CONCEPTO | 10 | 6 | LICENCIA CORPORATIVA | 10 | 7 | PLAN DE GESTIÓN DEL CAMBIO Y CAPACITACIÓN | 15 | 8 | APORTE DE LOS MÓDULOS DE LABORATORIO Y BANCO DE SANGRE | 5 | 9 | PRECIO DEL CONTRATO ANUAL DE SERVICIO, SOPORTE Y MANTENCIÓN POST GARANTÍA | 15 | | TOTAL PUNTOS: | 100 | Resultará adjudicada la oferta que obtenga el mayor puntaje en la Tabla de Evaluación General precedente. En caso de empate, se adjudicará la oferta cuyo precio del contrato anual de servicio, soporte y mantención post garantía sea el más bajo. 8.3 EXPERIENCIA DE LA EMPRESA Respecto de los proyectos mundiales en que ha utilizado los software propuestos para FCE y ERP incorporados en la presente oferta, el oferente deberá proporcionar información suficiente que permita entender la magnitud de los proyectos realizados y la identificación inequívoca de sus clientes y responsables de los proyectos (datos de contacto: nombre, teléfono, email) que permitan a la comisión evaluadora comprobar parte o toda dicha información, si lo estima pertinente, a fin de asignar los puntajes respectivos en la tabla. Respecto al Jefe de Proyecto propuesto, se deberá entregar una relación de los proyectos realizados por él, indicando detalles de la magnitud de dichos proyectos, del tiempo de implantación y del tiempo que le correspondió participar. La información proporcionada que por algún motivo no pueda ser comprobada, no será considerada en la evaluación. El oferente deberá consignar en las columnas (2), (3), (4) y (5), el número de proyectos e instalaciones, de las características requeridas en que ha participado, según corresponda, eligiendo el rango pertinente. Tabla Experiencia de la Empresa | EXPERIENCIA DE LA EMPRESA (1) | | (2) | (3) | (4) | (5) | Puntaje Obtenido (6) | Puntos máximo Posible (7) | | | | | | | | | | | EL PROVEEDOR ACREDITA QUE HA EFECTUADO: | En 0 a 19 Instituciones | En 20 a 40 Instituciones | En 41-70 Instituciones | En 71 a 100 Instituciones | En 101 y más Instituciones | | | | | Menos 10 Puntos | 0,2 Puntos | 0,5 Puntos | 0,70 Puntos | 1,2 Puntos | | | 1 | Instalaciones de FCE en hospitales de 200 camas y más. | | | | | | 0 | 1,2 | | | Menos 10 Puntos | 0,2 Puntos | 0,4 Puntos | 0,60 Puntos | 0.8 Puntos | | | 2 | Instalaciones de ERP en empresas de 500 empleados y más. | | | | | | 0 | 0,8 | | | | | | | | | | | MODALIDAD DE PROPIEDAD DE LOS SOFTWARE DE FCE Y ERP | | Consorcio entre proveedor FCE y ERP | Partnership o Representación acreditable documentalmente | Propiedad de FCE o ERP | Propiedad de ambos FCE y ERP | | | | | | 0 Puntos | 0,4 Puntos | 0,9 Puntos | 1,2 Puntos | | | 3 | Modalidad contractual del oferente respecto de los productos FCE y ERP | | | | | | 0 | 1,2 | | | | | | | | | | | EXPERIENCIA DE COORDINADORES DE ÁREA | | | | | | | | | El Coordinar Área FCE ha participado en: | 0 a 1 | 2 a 3 | 4 a 5 | 6 y más | | | | | | Menos 10 puntos | 0,30 | 0,70 | 1,2 | | | | 4 | Instalaciones de FCE en hospitales de 200 camas y más. | | | | | | 0 | 1,2 | | El Coordinar Área ERP ha participado en: | 0 a 1 | 2 a 4 | 5 a 7 | 8 y más | | | | | | Menos 10 puntos | 0,2 | 0,4 | 0,6 | | 0 | | 5 | Instalaciones de ERP en empresas de 500 empleados y más. | | | | | | | 0,6 | | TOTAL PUNTOS | | | | | | 0 | 5 | Cada uno de los tres rubros tiene asignado un puntaje. La suma de estos puntos corresponde al concepto de EXPERIENCIA DE LA EMPRESA, que aparece en la Tabla de Evaluación General. El oferente que obtenga el más alto puntaje en el concepto EXPERIENCIA DE LA EMPRESA, se hace acreedor al máximo puntaje de la TABLA DE EVALUACIÓN GENERAL, correspondiéndole a las demás ofertas, un puntaje proporcional decreciente. Se utilizará dos decimales

8.4 PRECIO DEL PROYECTO LICITADO El precio del Proyecto debe estar expresado en Pesos Chilenos. Se asignará el puntaje máximo a la oferta que cotice el más bajo precio total incluyendo impuestos, de los productos incluidos en la oferta y su implantación y puesta en marcha. A las demás ofertas se le asignará un puntaje proporcional decreciente. Se utilizará dos decimales. Para estos efectos se sumará los componentes de precio afectos a IVA (Impuesto al Valor Agregado = 19% en Chile), con el IVA incluido, y los componentes de precio EXENTOS de IVA, incluidos en la siguiente tabla:

TABLA DE PRESENTACIÓN DEL PRECIO DE LA OFERTA | Valor Neto EN PESOS Afecto a IVA | IVA de Ítems Afectos | Valor EN PESOS Exento de IVA | Total PESOS $ | Servicios y Bienes Afectos a IVA que se ofrecen. | | | N/A | | Servicios y Bienes Exentos de IVA que se Ofrecen. | N/A | N/A | | | Precio Total de la Oferta. | | | | $ | N/A: No Aplica el Concepto

Se hace presente que el proveedor deberá tener absoluto conocimiento y claridad de los aspectos tributarios vigentes en Chile, cuyo cumplimiento será de su responsabilidad. En caso de omitirse el costo de derechos o impuestos, o se generen deudas a favor del Fisco de Chile de cualquier naturaleza como consecuencia de la eventual adjudicación de la oferta, estas serán de cargo del proveedor.

8.5 CONTRATO anual DE SERVICIO SOPORTE Y MANTENCIÓN POST-GARANTÍA Precio El precio del Contrato Anual del Servicio de Soporte y Mantención Post Garantía, debe estar expresado en Unidades de Fomento (UF), INCLUYENDO el IVA (Impuesto al Valor Agregado). Para los efectos de la evaluación, este valor expresado en UF será convertido a Pesos Chilenos al valor de la UF del día de apertura de las ofertas. Se asignará el Puntaje Máximo de 11 de los 15 Puntos a que se refiere la Tabla de Evaluación General ubicada en el Punto 8.3 número 9, al oferente que presente el precio más bajo y al resto de las ofertas se les asignará un puntaje proporcional decreciente, utilizando dos decimales, según la fórmula:

Evaluación Técnica EVALUACIÓN SERVICIO DE SOPORTE POST-VENTA NIVEL 2 Y MANTENCIÓN (1) | (2) | (3) | Puntaje Asignado (4) | Puntaje Calculado (5) | | Tiempo de Respuesta mayor a 11 min.
0 puntos | Tiempo de Respuesta
10 min. o menor
3 puntos | | | Servicio de soporte de nivel secundario 24 x 7, ante falla crítica de aplicación y base de datos | | | 3 | | | Tiempo de Respuesta mayor a 91 min. 0 puntos | Tiempo de Respuesta
90 min. o menor 15 puntos | | | Resolución para Fallas Críticas aplicación y base de datos | | | 15 | | | Tiempo de Respuesta
Mayor a 8:01 horas 0 puntos | Tiempo de Respuesta
8 horas o menor 2 puntos | | | Tiempo de Resolución para Fallas No Críticas | | | 2 | | | | | | | PUNTAJE PARCIAL EVALUACIÓN TÉCNICA | | | 20 | | En las columnas (2) o (3), el oferente deberá indicar expresamente el tiempo en minutos comprometidos para cada rubro. La Comisión Evaluadora, calculará el puntaje correspondiente en la columna (5). El puntaje de evaluación técnica se obtiene multiplicando el puntaje parcial obtenido, por el FACTOR 0,2 (cero coma dos). ------------------------------------------------- Puntaje Oferta Técnica = Puntaje Técnico Obtenido * 0.2 En este rubro, los aspectos técnicos evaluados corresponden a un máximo de 20 puntos parciales, los que corresponden a su vez, a 4 puntos de los 15 expresados en la Tabla de Evaluación General indicada en el punto 8.3, número 9. Se asignará los 4 puntos a la oferta que tenga la más alta puntuación en la evaluación técnica, correspondiendo a las demás ofertas un puntaje proporcional decreciente utilizando dos decimales.

Puntaje Final El puntaje final se constituye sumando el Puntaje Final de Precio más el Puntaje Final de la Evaluación Técnica. ------------------------------------------------- Puntaje Final = Puntaje Precio + Puntaje Evaluación Técnica
-------------------------------------------------

------------------------------------------------- Puntaje Máximo Posible = 15 puntos

8.6 EVALUACIÓN FUNCIONAL DE FCE Y ERP La evaluación técnica de las ofertas, se hará sobre la base del cumplimiento de los requisitos solicitados, cuyo detalle se explicita en las presentes Bases Técnicas.

Se entregan planillas Excel para que el oferente realice una autoevaluación del cumplimiento de las funcionalidades requeridas para la totalidad de los módulos licitados y establezca el puntaje preliminar obtenido. El detalle de estas planillas se encuentra se encuentra en el Capítulo 12 de las presentes Bases Técnicas. El oferente entregará las tablas de autoevaluación debidamente llenadas, en dos formatos: en PDF y en formato Excel 2003.

Para cada fila de funcionalidades el oferente debe auto asignarse 2 puntos si su aplicación cumple con la funcionalidad, 1 punto si no cumple con la funcionalidad pero ésta será desarrollada dentro del proyecto, y 0 puntos si no cumple con la funcionalidad ni esta será desarrollada.

Para cada módulo se ha definido un puntaje mínimo de cumplimiento y una cantidad máxima de funcionalidades que el oferente podrá omitir. Para considerar cumplidas las bases de licitación, el puntaje obtenido en cada uno de los módulos solicitados debe ser igual o superior al mínimo exigido y las funcionalidades denominadas “no cumple ni será desarrollado”, deben ser iguales o menores que los máximos establecidos para cada módulo. Debe ser muy cuidadoso el llenado del campo “Trazabilidad” que se encuentra en cada una de las filas de las tablas, ya que esta información será la única que utilizará Comisión Evaluadora para comprobar en el texto y documentación de la oferta, la veracidad de la información contenida en la autoevaluación. La información de trazabilidad debe ser precisa, indicando en que documento, página y párrafo se encuentra la información pertinente. Ante la inexistencia o inexactitud de ésta información en el lugar indicado en el campo “Trazabilidad”, se entenderá que dicha fila será re evaluada con CERO PUNTOS, independientemente que la información correcta pueda encontrarse en otro documento diferente al citado. La Comisión Evaluadora no buscará la información; sólo la validará en las condiciones ya indicadas. La evaluación de las funcionalidades se realizará en dos bloques, correspondiendo uno a las funcionalidades de FCE y el otro a las funcionalidades del ERP. * 8.7.1 EVALUaCION DE LA FCE Los módulos de Aranceles y Cuenta de Pacientes han sido ubicados en el bloque de la FCE, y allí se debe realizar la autoevaluación, independientemente que el producto del proveedor tenga incorporados estos módulos dentro del ERP. Cada uno de los módulos tiene asignado un puntaje de Ponderación. El oferente que logre el máximo puntaje posible en un determinado módulo, se asignará el puntaje máximo de ponderación del módulo, en caso contrario, calculará una ponderación proporcional según la siguiente fórmula: Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. | Al oferente que logre la sumatoria máxima de ponderadores en el bloque de FCE , la Comisión Evaluadora le asignará el puntaje máximo de 15 puntos correspondiente a la Tabla de Evaluación General (Punto 8.3 número 3). Las demás oferentes tendrán un puntaje decreciente proporcional, calculado con dos decimales de la siguiente manera:

PUNTAJES MÁXIMO, MÍNIMO Y NÚMERO MÁXIMO DE ÍTEMS NO OFRECIDOS PARA CADA MÓDULO DE FICHA CLÍNICA ELECTRÓNICA. PONDERACIÓN POR MÓDULO PARA ESTRUCTURAR EL PUNTAJE DEL BLOQUE FCE. MÓDULO(1) | CANTIDAD DE ÍTEMS(2) | Puntaje Máximo(3) | Puntaje Mínimo(4) | Máximo número de Ítems en cero (5) | Ponderación Máxima Posible(6) | Ponderación Calculada(7) | CLÍNICO | 99 | 198 | 139 | 4 | 12 | | DENTAL | 55 | 110 | 77 | 2 | 8 | | ENFERMERÍA | 52 | 104 | 93 | 2 | 8 | | AGENDA | 48 | 96 | 67 | 2 | 7 | | FORMULARIOS | 36 | 72 | 50 | 1 | 4 | | PABELLONES | 43 | 86 | 60 | 2 | 7 | | ANATOMÍA PATOLÓGICA | 36 | 72 | 50 | 1 | 7 | | ADMISIÓN GESTIÓN DE CAMAS | 30 | 60 | 42 | 1 | 5 | | MAESTRO PACIENTES | 29 | 58 | 41 | 1 | 3 | | CUENTA PACIENTE | 19 | 38 | 27 | 1 | 5 | | ARCHIVO FICHAS | 22 | 44 | 31 | 1 | 4 | | ESTERILIZACIÓN | 18 | 36 | 25 | 1 | 4 | | SERVICIOS APOYO | 19 | 38 | 27 | 1 | 3 | | URGENCIA | 19 | 38 | 27 | 1 | 3 | | ARANCELES | 17 | 34 | 24 | 1 | 5 | | NUTRICIÓN | 14 | 28 | 20 | 1 | 2 | | ATENCIÓN EN POLICLÍNICO | 11 | 22 | 15 | 0 | 1 | | IIH | 11 | 22 | 15 | 0 | 2 | | FARMACOLOGÍA | 9 | 18 | 13 | 0 | 3 | | KIOSCOS | 9 | 18 | 13 | 0 | 1 | | CAMAS CRITICAS | 6 | 12 | 8 | 0 | 3 | | CESFAM y PROGRAMAS DE SALUD | 8 | 16 | 11 | 0 | 3 | | TOTAL | 610 | 1.220 | 854 | 24 | 100 | | El detalle de formularios a utilizar para la autoevaluación de cada uno de estos módulos se encuentra en el Capítulo 12 de estas Bases. * 8.7.2 EVALUCION DEL ERP *
PUNTAJES MÁXIMO, MÍNIMO Y NÚMERO MÁXIMO DE ÍTEMS NO OFRECIDOS PARA CADA MÓDULO DEL ERP. Para considerar cumplidas las bases de licitación, el puntaje obtenido en cada uno de los módulos solicitados debe ser igual o superior al mínimo exigido y las funcionalidades denominadas “no cumple ni será desarrollado”, deben ser iguales o menores que los máximos establecidos para cada módulo. Cada uno de los módulos tiene asignado un puntaje de Ponderación. El oferente que logre el máximo puntaje posible en un determinado módulo, se asignará el puntaje máximo de ponderación del módulo, en caso contrario, calculará una ponderación proporcional según la siguiente fórmula. Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

PONDERACIÓN POR MÓDULO PARA ESTRUCTURAR EL PUNTAJE DEL BLOQUE ERP. | MÓDULOS | ÍTEMS | Puntaje Máximo | Puntaje Mínimo | Máximo Número de ítems en Cero | PonderaciónMáxima | Ponderación Calculada | 1 | CONTABILIDAD | 46 | 92 | 64 | 2 | 10 | | 2 | PRESUPUESTO | 19 | 38 | 27 | 1 | 2 | | 3 | TESORERÍA | 63 | 126 | 88 | 3 | 4 | | 4 | GESTIÓN DE COSTOS | 19 | 38 | 27 | 1 | 3 | | 5 | GESTIÓN DE PROVEEDORES | 19 | 38 | 27 | 1 | 3 | | 6 | GESTIÓN DE CONTRATOS | 31 | 62 | 43 | 1 | 3 | | 7 | INGRESOS | 37 | 74 | 52 | 1 | 10 | | 8 | ING: MANEJO DE FONDOS Y ANTICIPO A PROVEEDORES | 16 | 32 | 22 | 1 | 3 | | 9 | ING: GESTIÓN DE CAJA | 12 | 24 | 17 | 0 | 3 | | 10 | FACTURACIÓN | 8 | 16 | 11 | 0 | 3 | | 11 | ABASTECIMIENTO | 32 | 64 | 45 | 1 | 4 | | 12 | COMPRAS | 114 | 228 | 160 | 5 | 10 | | 13 | RECEPCIÓN BODEGAS | 49 | 98 | 69 | 2 | 3 | | 14 | BODEGA FARMACIA | 24 | 48 | 34 | 1 | 3 | | 15 | EXISTENCIAS | 25 | 50 | 35 | 1 | 3 | | 16 | GESTIÓN DE CATÁLOGOS | 90 | 180 | 126 | 4 | 4 | | 17 | CONTROL DE DEMANDA | 6 | 12 | 8 | 0 | 3 | | 18 | ACTIVO FIJO | 25 | 50 | 35 | 1 | 6 | | 19 | MANTENIMIENTO EQUIPOS Y MAQUINARIA | 114 | 228 | 160 | 5 | 3 | | 20 | PERSONAL - REMUNERACIONES | 41 | 82 | 57 | 2 | 4 | | 21 | PERSONAL - VIÁTICOS | 5 | 10 | 7 | 0 | 2 | | 22 | PERSONAL - ADMINISTRACIÓN | 26 | 52 | 36 | 1 | 6 | | 23 | PERSONAL - RECLUTAMIENTO Y DESARROLLO | 7 | 14 | 10 | 0 | 3 | | 24 | PERSONAL - GESTIÓN ALIMENTACIÓN | 9 | 18 | 13 | 0 | 2 | | | | | 0 | - | 0 | | | | TOTALES | 837 | 1.674 | 1.172 | 35 | 100 | | Al oferente que logre la sumatoria máxima de ponderadores en el bloque de ERP, la Comisión Evaluadora le asignará el puntaje máximo de 15 puntos correspondientes a la Tabla de Evaluación General (Punto 8.3, número 4). Las demás oferentes tendrán un puntaje decreciente, proporcional, calculado con dos decimales de la siguiente manera:

El detalle de formularios a utilizar para autoevaluación de cada módulo se encuentra en el Capítulo 12 de estas Bases. 8.7 PRUEBA DE CONCEPTO La evaluación de una “Prueba de Concepto” será realizada por la Comisión Evaluadora designada por EL FONDO. La que tendrá por función verificar la existencia material de las herramientas y de las funcionalidades solicitadas.
El procedimiento y los detalles de la evaluación se detallan a continuación. 8.8.1 LABORATORIO DE PRUEBA La “Prueba de Concepto”, está concebida en los siguientes términos: 1. El objeto de esta demostración es verificar en ambiente de laboratorio, la existencia de las funcionalidades y herramientas que han sido requeridas y ofrecidas en la presente licitación. 2. Para la demostración se prepararon algunos casos de uso que serán idénticos para todos los oferentes (Detallados en “CASOS DE USO PARA EVALUACIÓN”, Capítulo 13). Será exigible la realización de la parte de los casos de uso que sea posible efectuar con los módulos y funcionalidades ofrecidas. No será exigible la demostración de las funcionalidades y herramientas que el oferente haya declarado que desarrollará o que no tiene ni desarrollará. 3. El contenido de guías clínicas y protocolos puede ser simulado con textos de prueba, sin valor clínico ni científico. Se pretende observar como a partir de un diagnóstico o síntoma relevante se anuncian automáticamente y se despliegan estos protocolos y guías clínicas. 4. Similar situación ocurrirá con las enfermedades de declaración obligatorias, enfermedades bajo supervigilancia epidemiológica y con las patologías AUGE. En estos casos, se desplegará el formulario simulado de declaración que corresponda. 5 Para el ingreso de datos en la FCE, se verificará el uso de cajas de selección múltiple (con opciones parametrizables), que permitan ingresar en forma estructurada los síntomas clínicos, hábitos, hipótesis diagnosticas, plan de estudios, plan terapéutico, dietas y cuidados de enfermería. 6. Asimismo, se deberá mostrar como a partir de las indicaciones del médico, se genera en forma automática la programación horaria de las actividades de enfermería. Se visualizará la forma como se ingresan los signos vitales.

7. Se deberá poblar un set de datos de prueba que incluya como mínimo: un PLAN DE CUENTAS CONTABLE DE 5 NIVELES, PROVEEDORES, CLIENTES (Maestro de Pacientes de Prueba), INVENTARIOS DE MEDICAMENTOS E INSUMOS, PERSONAL, ACTIVOS INMÓVILES Y MÓVILES. 8. Lo que se buscará mediante los CASOS DE USO PARA LA EVALUACIÓN, será demostrar la Seguridad del Sistema, el registro de los respectivos LOGs, la facilidad de interacción con el sistema, la capacidad de configuración y hacer cambios a pantallas pre-definidas, la capacidad de extraer reportes estándar y poder definir nuevos reportes. 9. Se deberá mostrar el funcionamiento de ROLES y PRIVILEGIOS del Sistema, permitiendo restringir el acceso a menúes y despliegue de información dependiendo del perfil del usuario de pruebas. 10. Se solicitará demostrar la emisión de facturas (obviamente no customizadas aún), cálculo de remuneración estándar y generación de reportes respectivos. 11. Se busca también verificar el movimiento de cuentas contables ante la ocurrencia de eventos de INGRESOS y EGRESOS del Sistema. 12. Interesa también demostrar las capacidades del módulo de recepción de Bodega en términos de lectura de códigos de barra EAN-128 y manejo del concepto de LOTE y FECHA DE VENCIMIENTO dentro del sistema, y como éste es trasladado hacia adelante en la cadena de trazabilidad, hasta la cama del paciente. 13. Se deberá también mostrar en el módulo de Bodega la capacidad de recibir con códigos de CAJA DUN-14 o PALLET SSCC, y efectuar el ingreso a Bodega de los productos a nivel de EAN-13 respectivos en forma automática. Idealmente, efectuar el proceso a partir de un documento electrónico XML o EDI tipo DESADV o INVOIC, enviado previamente por un proveedor ficticio. Para la realización de estas pruebas, los oferentes deberán preparar los elementos técnicos necesarios (Datashow, Lectores de Códigos de Barra) para posibilitar que su sistema pueda operar en una red local de un mínimo de 5 equipos PC y una impresora proporcionados por el FONDO, para desplegar simultáneamente diferentes módulos que permitan apreciar la interacción entre ellos y los registros correspondientes. Podrá utilizar bases de datos de prueba precargadas en su sistema a fin de facilitar la demostración de los flujos y las funcionalidades de las herramientas incorporadas al sistema. Es importante demostrar la operación integrada de los módulos ofrecidos. La integración con sistemas legados, con sistemas externos y entre la FCE y el ERP, no será requerida para los efectos de esta demostración. Sólo se comprobarán las funcionalidades ofrecidas, mediante el seguimiento de los casos de uso propuestos. No serán exigibles las funcionalidades que el oferente ha declarado que no tiene y que desarrollará y las que no estarán disponibles en la solución que ofrece. En especial se comprobará la existencia de los atributos y herramientas indicados en la tabla de evaluación, aplicando los siguientes criterios: El Oferente deberá marcar con un “SI”, en la Columna “Autoevaluación Funcionalidades Evaluables (SI / NO)”, aquellas herramientas o funciones que en la oferta declara como “CUMPLE”, y con un “NO”, aquellas herramientas y funcionalidades que en la oferta declara como “DESARROLLARÁ” o “NO CUMPLE NI DESARROLLARÁ”. Las funcionalidades marcadas por el oferente con “SI”, deben ser demostradas en forma práctica a fin de que la comisión evalúe de acuerdo con los siguientes criterios: si la funcionalidad a juicio de la Comisión Evaluadora no esta cumplida, asignará un puntaje negativo -10 (menos diez puntos), si estima que está cumplida parcialmente, asignará un punto, y si está cumplida completamente asignará dos puntos.

| MATRIZ DE EVALUACIÓN PRUEBA DE CONCEPTO | | Evaluación de la Comisión Evaluadora | | | | | | | | | | AREA FUNCIONAL | Autoevaluación Funcionalidades Evaluables
(SI / NO) | No Cumple -10 Puntos | Cumple Parcialmente 1 Punto | Cumple Plenamente 2 Puntos | Puntaje Parcial Obtenido | | FCE: | | | | | | 1 | a. La existencia de un motor para configurar alertas. | | | | | | 2 | b. La existencia de un sistema de ayuda farmacológica incorporada en el formulario de recetas (recetario). | | | | | | 3 | c. La capacidad del sistema para identificar Enfermedades de Declaración Obligatoria, Patologías AUGE, Enfermedades bajo Vigilancia Epidemiológica. | | | | | | 4 | d. Verificar la existencia de la herramienta que permite la visualización de Guías Clínicas y protocolos. | | | | | | 5 | e. Verificar la existencia de la herramienta que permite generar una epicrisis y resúmenes clínicos en forma automática. | | | | | | 6 | f. Verificar que los datos ya ingresados no puedan ser modificados por el usuario. | | | | | | 7 | g. Verificar la existencia de la funcionalidad que permite generar automáticamente el programa de trabajo de enfermería a partir de las indicaciones realizadas por el médico en la FCE. | | | | | | | ERP: | | | | | | 8 | h. Verificación de Registros en el Modelo de Datos | | | | | | 9 | i. Verificación de Emisión de Vouchers Contables | | | | | | 10 | j. Verificar el funcionamiento del modelo de contabilidad de 5 niveles jerárquicos, multiempresa, multicentro. | | | | | | 11 | k. Se verificará la capacidad de soporte para un modelo de trazabilidad de medicamentos y control de su Lote y Fecha de Vencimiento hasta la Cama del Paciente | | | | | | 12 | l. Se verificará la funcionalidad y capacidades de automatización en la logística de la bodega, y la capacidad de gestionar distintas bodegas. | | | | | | | | | | | | | | GENERAL: | | | | | | 13 | m. Verificación de la existencia y funcionamiento de la herramienta que permite diseñar y generar reportes. | | | | | | 14 | n. Verificar la existencia de la herramienta de B. Intelligence, de acuerdo con los atributos ofrecidos (Se podrá utilizar además de los datos que se ingresen durante la Prueba de Concepto, una base de datos precargada. | | | | | | 15 | o. Verificación de la existencia de herramientas que permitan adecuar las pantallas del usuario a las necesidades de las diferentes especialidades clínicas. | | | | | | 16 | p. Verificación de la existencia del Log de acceso y navegación auditable. | | | | | | 17 | q. Verificación de la existencia de la herramienta que permite generar roles, reglas y perfiles de usuario y la asignación de privilegios. | | | | | | | | | | | | | | TOTAL DE ITEMS EVALUABLES | | | | | | | | | | | | | | PUNTAJE OBTENIDO | | | | | | ÍTEMS EVALUABLES: son aquellos que el oferente ha marcado con “SI”.

El PUNTAJE MÁXIMO POSIBLE para un oferente se determina multiplicando por el factor “2”, la suma total de ítems evaluables (Total Ítems evaluables x 2 = “n”) (Ejemplo: n = 17 x 2 =34 puntos) El puntaje obtenido por el oferente representa: “n”/34 de 7 de los 10 puntos asignados a la prueba de concepto en la Tabla de Evaluación General. Siendo “n” el puntaje máximo posible que el oferente ha declarado poder demostrar. El puntaje obtenido por los conceptos mencionados corresponde a: Puntaje del Área Funcional = “n” / 34 x 7 | Resultado con DOS DECIMALES. |

OPINIÓN EXPERTA COMISIÓN EVALUADORA | | | | | | | | Rango de Puntuación | | FUNCIONALIDAD A EVALUAR | Máx | 0.00 – 1.00 | Totales | Acabado Gráfico. | 1.00 | | | Nivel de Intuitividad de la Interfaz de Usuario. | 1.00 | | | Relación de Información Estructurada versus Texto Libre en campos de Ingreso de Información. | 1.00 | | | Coherencia de Resumenes Automatizados. | 1.00 | | | Presentación de Listas de Trabajo de Enfermería. | 1.00 | | | Presentación de Guías y Protocolos. | 1.00 | | | Facilidad de Acceso a las Tareas versus Cantidad de Clicks. | 1.00 | | | Usabilidad de los Formularios. | 1.00 | | | Facilidad de Apoyo de la Automatización en la bodega. | 1.00 | | | Facilidad de auto completación de datos. | 1.00 | | | Facilidad de Prellenado de Formularios. | 1.00 | | | Facilidad de Modificación y Configuración de Planes Contables. | 1.00 | | | Facilidad de Visualización de Trazabilidad. | 1.00 | | | TOTAL PUNTAJE POSIBLE | 13 | | | TOTAL PUNTAJE OBTENIDO | | | | PUNTOS: | | La evaluación experta de los miembros de la comisión se realizará sobre los criterios que aparecen expresados en la tabla “OPINIÓN EXPERTA COMISIÓN EVALUADORA”, valorando en un rango de 0.00 a 1.00. Esto corresponde a 3 puntos de los 10 puntos indicados en la Tabla de Evaluación General para la Prueba de Concepto. Puntaje de Evaluación Experta = (3/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

------------------------------------------------- PuntajeFinal = Puntaje de Área Funcional + Puntaje de Evaluación Experta

8.8 LICENCIA CORPORATIVA Las Empresas que ofrezcan licencias sin restricción del número de usuarios (nombrados y/o concurrentes) para FCE y ERP se harán acreedoras al puntaje establecido en la matriz de la evaluación, aplicando el siguiente criterio: TABLA EVALUACIÓN LICENCIAS CORPORATIVAS | Sólo FCE con Licencia Corporativa | Sólo ERP con Licencia Corporativa | FCE y ERP con Licencia Corporativa | Puntaje de la evaluación general | 6 | 4 | 10 | 8.9 PLAN DE GESTIÓN DEL CAMBIO Y CAPACITACIÓN EVALUACIÓN PLAN GESTIÓN DEL CAMBIO Para la evaluación de estos conceptos (i) al (v) se asignará un puntaje entre CERO y UNO a cada fila aplicando criterio de juicio experto. El valor asignado se multiplicará por el Puntaje Asignado, con lo que se obtendrá el Puntaje Calculado. Para el concepto (vi), se evaluará el Jefe del Proyecto de Gestión del Cambio propuesto, donde el Oferente deberá entregar los respaldos de información que permitan realizar las asignaciones de puntajes respectivos. El puntaje asignado será igual al puntaje obtenido para cada rubro. Ref | EVALUACIÓN GESTIÓN DEL CAMBIO | Rango de Puntuación Conceptos (i) al (v) | Puntaje Asignado | Puntaje Obtenido | | | 0.00 – 1.00 | | | i. | Metodología de Trabajo Marco | | 1 | | ii. | Plan General de Dirección para la Gestión del Cambio | | 2 | | iii. | Material Didáctico y Herramientas a utilizar | | 1 | | iv. | Plan de Comunicaciones y Difusión | | 2 | | v. | Matriz de Riesgos (a priori) del proceso y estrategias estimadas de mitigación propuestas | | 1 | | | | | | | vi. | Persona que liderará este subproyecto y su experiencia | | | | | | | | No Cumple
(0 puntos) | Cumple
(1 punto) | | | | vi.1 | Profesional es Sicólogo o Profesión Afín | | | | 1 | | | | 0 a 1 proyectos
0 puntos | 2 a 3 proyectos
1 punto | 4 y más proyectos
2 puntos | | | vi.2 | Proyectos en que ha participado | | | | 2 | | | SUB TOTAL OBTENIDO | | | | 10 | | EVALUACIÓN PLAN DE CAPACITACIÓN Para la evaluación de los conceptos (1) al (4) se asignará un puntaje entre CERO y UNO a cada fila aplicando criterio de juicio experto. El valor asignado se multiplicará por el Puntaje Asignado, con lo que se obtendrá el Puntaje Calculado. Nro | EVALUACIÓN PLAN CAPACITACIÓN | Rango de Puntuación Conceptos (1) al (4) | Puntaje Máximo Asignado | Puntaje Obtenido | | | 0.00 - 1.00 | | | 1 | Metodología que se empleará y tiempo en horas de capacitación estimada para cada tipo de profesional | | 2 | | 2 | Medios audiovisuales que sean necesarios para llevar a cabo el proceso de capacitación | | 1 | | 3 | Plan de contingencia para el caso que la evaluación de la capacitación resulte insatisfactoria | | 1 | | 4 | Criterios y metodología que se aplicará para evaluar los resultados de la capacitación | | 1 | | | | | | | | SUB TOTAL OBTENIDO | | 5 | | Para determinar el Puntaje Final de este concepto, se debe sumar los dos SUB TOTALES Obtenidos A la oferta con el mayor puntaje Final se le asignará los 15 puntos correspondientes al rubro en la Tabla de Evaluación General. A las restantes ofertas se le asignará un puntaje proporcional decreciente, calculado con dos decimales, de acuerdo con la aplicación de la siguiente fórmula: 8.10 APORTE DE MÓDULOS DE LABORATORIO Y BANCO DE SANGRE Los oferentes que prefieran aportar estos dos módulos calificados como opcionales, en lugar de integrar los aplicativos existentes, se harán acreedores al puntaje establecido en la Tabla de Evaluación General. Los dos siguientes módulos tienen el carácter de Oferta Opcional, por lo que no tienen carácter de obligatorio. Si se presenta estos módulos, deben atenerse a los criterios de evaluación expresados al pié de las tablas de que siguen, siendo obligatorio el cumplimiento de los puntajes mínimos para calificar. Al módulo de LABORATORIO le corresponderá un Puntaje Máximo de TRES Puntos y al módulo de BANCO DE SANGRE un Puntaje Máximo de DOS Puntos, correspondientes a la Tabla de Evaluación General que se presenta en el punto 8.3. Si ofrece sólo uno de los módulos, se evaluará sólo este módulo, asignándole CERO puntos al segundo módulo. Cada módulo se evalúa por separado y los puntajes calculados se sumarán obteniendo el puntaje final por este concepto, evaluable en la Tabla de Evaluación General.

------------------------------------------------- ------------------------------------------------- Puntaje Final = PuntajeFinalLaboratorio + PuntajeFinalBancoSangre
-------------------------------------------------

PUNTAJES MÁXIMO, MÍNIMO Y NÚMERO MÁXIMO DE ÍTEMS NO OFRECIDOS PARA LOS MÓDULOS DE BANCO DE SANGRE Y LABORATORIO.

MÓDULO | CANTIDAD DE ÍTEMS | Puntaje Máximo | Puntaje Mínimo | Máximo número de Ítems en cero | Puntaje Obtenido | LABORATORIO | 20 | 40 | 28 | 1 | | BANCO DE SANGRE | 28 | 56 | 39 | 1 | | Para considerar cumplidas las bases de licitación, el puntaje obtenido en cada uno de los módulos solicitados debe ser igual o superior al mínimo exigido y las funcionalidades denominadas “no cumple ni será desarrollado”, deben ser iguales o menores que los máximos establecidos para cada módulo. El detalle de formularios a utilizar para la autoevaluación de cada uno de estos módulos se encuentra en el Capitulo 12 de estas Bases.

8 CRONOGRAMA DEL PROCESO DE LICITACIÓN Concepto | Día (hábil) | Observaciones | Publicación de Especificaciones | 0 | | Visita a terreno | 15 | | Consultas | 17 al 19 | | Respuestas y/ o aclaraciones | 24 al 28 | | Cierre recepción ofertas | 50 | | Apertura de ofertas Electrónicas | 51 | | Plazo para evaluar | 51 - 80 | | Plazo para adjudicar | 81 - 90 | | Plazo celebración contrato | 91 – 120 | | Número total de días hábiles del proceso | 120 | | (1) Las empresas que califiquen para presentar la prueba de concepto, serán citadas formalmente a una reunión (mediante correo electrónico al correo señalado en los antecedentes adjuntos a la oferta) en que se procederá a sortear el orden de precedencia en que deberán realizar esta prueba. Se levantará un Acta del Sorteo la que será firmada por todos los oferentes representados en la reunión. Para la Prueba de Concepto se destinará un día completo de 8 horas hábiles por empresa. 9 hitos de pago N° | HITO | % | 1 | Aceptación del levantamiento funcional y rediseño de procesos incorporando las mejores prácticas. (referencia Bases Técnicas Numeral 5.7.2)
Entregables (1)
1. Informe de Levantamiento, Brechas y Propuestas de Re-Ingeniería
2. Informe de Diseño de los Procesos a ser Implementados y entrega de documentación asociada
3. Minutas de Reuniones de Trabajo
4. Documentos de Aceptación de Usuarios Líderes
5. Informe de Alcance Final del Proyecto
6. Programa de Trabajo Definitivo del Proyecto

| 10 | 2 | Configuración de los servidores e Instalación de las licencias.
Entregables (1)
1. Certificados de Propiedad de Licencias FCE
2. Certificados de Propiedad de Licencias ERP
3. Informe de Pruebas de Instalación de Licencias de estos Aplicativos no parametrizados, ni integrados | 5 | 3 | Aceptación de las pruebas funcionales de configuración y parametrización.
Entregables (1)
1. Informe de Configuración y Parametrización del Sistema y Documentación Asociada
2. Documentación de Planes de Prueba Diseñados y su Resultado Obtenido
3. Plan de Gestión del Cambio y Capacitación Revisado | 5 | 4 | Aceptación de pruebas de integración con Sistemas Legados técnicamente viables.
Entregables (1)
1. Informe de Sistemas Legados Integrados y su Resolución Técnica
2. Plan de Pruebas Diseñado y sus Resultados Técnicos

Aceptación de Metodología y Pruebas de Migraciones de datos.
Entregables (1)
1. Informe de Análisis de Calidad de Datos y Propuestas de Migración
2. Informe de Metodología a Seguir para la Migración
3. Informe de Diseño de Pruebas de Migración y Pruebas Preliminares | 10 | 5 | Aceptación de pruebas funcionales pruebas de carga, contingencias y seguridad.
Entregables (1)
1. Informe de Análisis de Seguridad del Sistema y Planes de Contingencia
2 Informe Diseño de Pruebas de Carga, Contingencia y Seguridad para el Sistema
3. Informe de Ejecución de Pruebas y Resultados obtenidos
4. Informe de Plan de Puesta en Marcha Blanca del ERP
5. Informes de Avance del Plan de Gestión del Cambio y Capacitación para el área ERP
6. Plan de Manejo de Información Biométrica, de Carga de Archivos Maestros y su Implementación
7. Plan de Manejo de Firma Electrónica Simple y su Implementación | 5 | 6 | Término Marcha Blanca ERP
Entregables (1)
1. Informe de Resultado de Migración de Datos para Explotación
2. Registro de Tablas de Datos y Actualización de Parametrización del ERP
3. Informe de Detalle de Áreas del HOSCAR y Usuarios en Funcionamiento en Marcha Blanca
4. Informe de Detalle de Roles, Perfiles y Privilegios Configurados en el Sistema
5. Plan de Paso de Producción del ERP
6. Informes de Avance del Plan de Gestión del Cambio y Capacitación para el área ERP
7. Informe de Parametrización y Configuración Tablas Maestras FCE
8. Plan de Gestión del Cambio y Capacitación Área Clínica
9. Informe de Diseño de Pruebas Funcionales para FCE
10. Informe de Diseño de Pruebas de Carga, Contingencias y Seguridad FCE
11. Informe de Diseño de Pruebas de Integración FCE y ERP
12. Informe de Diseño de Pruebas de Integración FCE con Legados Área Clínica | 10 | 7 | Aceptación de la puesta en marcha del Piloto de FCE (plan puesta en marcha).Entregables (1)
1. Informe de Realización de Pruebas Funcionales
2. Informe de Realización de Pruebas de Carga, Contingencias y Seguridad FCE
3. Informe de Pruebas de Integración FCE y ERP
4. Informe de Pruebas de Integración Legados Área Clínica con FCE
5.Informes de Avance del Plan de Gestión del Cambio y Capacitación para el área ERP y FCE6. Informe de Detalle de Áreas Clínicas del HOSCAR y Usuarios en Funcionamiento en Marcha Blanca
7. Informe de Detalle de Roles, Perfiles y Privilegios Configurados en el Sistema FCE
8. Plan de Paso de Producción de FCE Entregables (1)
9. Plan de Roll-Out del Sistema Integral (ERP + FCE) dentro del HOSCAR | 5 | 8 | Aceptación de Implantación en el HOSCAR.Entregables (1)
1. Informe de Pruebas de Funcionamiento Integral del Sistema FCE + ERP + Legados Integrados
2. Documentación de Aceptación del Sistema por Coordinadores de Área Clínica y Área Administrativa
3. Configuración y Parametrización de Centros Médicos Regionales
4. Plan de Gestión del Cambio y Capacitación para Centros Médicos Regionales
5.Informes de Avance del Plan de Gestión del Cambio y Capacitación para el área ERP y FCE
6. Informe de Diseño de Pruebas de Funcionamiento de Centros Médicos Regionales Implantados por el Adjudicado e Implantados por el FONDO.
7. Plan de Implantación en Centros Médicos Regionales a cargo del Adjudicado y del Fondo
8. Registro de Asistencia a Capacitaciones en la Plataforma de Integración de Personal Técnico del HOSCAR. | 10 | 9 | Implantación centros médicos regionales (según alcance).Entregables (1)
1. Informes de Avance del Plan de Gestión del Cambio y Capacitación para el área ERP y FCE
2. Informe de Resultados de Pruebas de Centros Médicos Regionales
3. Documentación de Aceptación de Coordinadores Regionales | 5 | 10 | Término de la Marcha Blanca.Entregables (1)
1. Informe de Observaciones surgidas en el proceso de Marcha Blanca y su Resolución
2. Informes de Avance del Plan de Gestión del Cambio y Capacitación para el área ERP y FCE
3. Informe de Carga de Servidores y Pruebas Desempeño (tiempos de respuesta dentro del HOSCAR, Región Metropolitana y Centro Médicos Regionales, Uptime) y Proposición de Medidas de Ajuste y Corrección si procediese.
4. Entrega de Manuales de Usuario y de Servicio, a que se refiere el punto 5.13 de las Bases Técnicas | 20 | 11 | Customización de herramienta de DWH, BI e IR-GRD
Entregables (1)
1. Entrega de Documentación de Propiedad de Licencias de Uso para DWH, BI e IR-GRD
1. Informe de Modelamiento del DW (Cubos OLAP, Metodología de Actualización de Datos, etc)
2. Informe de Configuración BI de Indicadores del Tablero de Mando, definición de Niveles de Acceso de los Usuarios a los diferentes niveles de agregación de información
3. Pruebas de Acceso a Niveles de Agregación de Datos y de Capacidad de Desagregación de Datos (Drill-in) desde un determinado nivel hacia abajo
4. Entrega de Manuales de Uso de DW y BI
5. Informe de Capacitaciones de Herramientas DWH, BI e IR-GRD para usuarios expertos definidos por el FONDO
6. Informe de Capacitación de Usuarios de Vistas del Tablero de Mando | 5 | 12 | Término del Período de Garantía.
1. Informe de Observaciones y Contingencias surgidas durante el período y su resolución
2. Actualización de Manuales y Procedimiento que hubieren sufrido modificaciones y entrega de la Documentación Técnica que se encuentre Pendiente, descrita en el punto 5.13 de las Bases Técnicas
3. Informa Final de Cierre del proceso de Gestión del Cambio y Capacitación, referidos a la Red de Salud | 10 | | | | | TOTAL | 100 |
(1)El Detalle Final de Entregables asociado a cada Estado de Pago será Acordado con el Adjudicado una vez acordado el Alcance Final del Proyecto y debe completarse con la totalidad de la Documentación Requerida en el Punto 5.13 de las Bases Técnicas. El Monto en Pesos correspondiente a cada hito de pago, se calculará aplicando los porcentajes expresados en esta tabla sobre el MONTO TOTAL DE LA OFERTA ECONÓMICA ADJUDICADA (Impuestos Incluidos) de la presente Licitación.

Para la aprobación de cada HITO DE PAGO se requerirá de la respectiva ACTA DE ACEPTACIÓN emitida por quien el FONDO designe, hecho que dará lugar a la emisión de la FACTURA CORRESPONDIENTE por los montos establecidos en la tabla precedente, Impuesto IVA incluido, y al subsecuente pago.

10 información y ESTADÍSTICAS de la red de salud

ANTECEDENTES RELEVANTES DE LA RED DE SALUD DE DISALCAR

sistema de GESTIÓN HOSPITALARIA

11.11 UBICACIÓN Y TIPO DE establecimientos que forman parte de la Red de Salud METROPOLITANA de CARABINEROS

| Establecimiento | TIPO | Dirección | Comuna | Teléfono | 1 | HOSCAR | HOSPITAL GENERAL | Simón Bolívar 2600 | ÑUÑOA | 9278000 | 2 | CESFAM | CENTRO DE SALUD FAMILIAR | | MAIPÚ | | 3 | CRICAR | CENTRO DE REHABILITACIÓN INFANTIL | Caupolicán Nº 589 | ÑUÑOA | 9224944 | 4 | CLÍNICA DE PDI | CENTRO MÉDICO | Brown Norte | ÑUÑOA | | | | | | | |

11.12 UBICACIÓN geográfica Y TIPO DE establecimientos que forman parte de la Red de Salud REGIONAL de CARABINEROS

11.13 ANCHO de banda disponible en los enlaces de comunicaciones

| ORIGEN | DESTINO | ANCHO DE BANDA | 1 | HOSCAR | HOSDIP | 1 Gbps | 2 | HOSCAR | DIPRECA | 1 Gbps | 3 | HOSCAR | TIC | 1 Gbps | 4 | HOSDIP | TIC | 1 Gbps | 5 | HOSDIP | PDI | 10 mb | 6 | TIC | MEDICINA -PREVENTIVA | 2 Mb | 7 | TIC | ZONA | 100 Mb | 8 | TIC | PREF.SANTIAGO | 100 Mb | 9 | TIC | PREF. PROVINCIAS | 10 Mb | 10 | TIC | COM. SANTIAGO | 10 Mb | 11 | TIC | COM. PROVINCIAS | 2 Mb | 12 | TIC | UNIDADES MENORES | 512 Kb-1 Mb | 13 | TIC | CENTROS MÉDICOS | 512 Kb- 1 Mb |

11.14 ESQUEMA GENERAL DE COMUNICACIONES (Esquema Referencial Actual)

*

11.15 ESQUEMA GENERAL LAN ACTUAL DEL HOSCAR

11.16 APLICATIVOS informáticos actualmente en uso

11.17 HOSCAR: ATENCIONES AMBULATORIAS EFECTUADAS AÑO 2010

| Cantidad de Boxes de atención | Atenciones efectuadas año 2009 | Urgencia adultos | 23 | 106.051 | Urgencia Pediátrica | 20 | 44.003 | Policlínico | 68 | 182.603 | TOTAL | 111 | 332.657 |

11.18 HOSCAR: CAMAS Y EGRESOS HOSPITALARIOS AÑO 2010

| CANTIDAD CAMAS | EGRESOS | CAMAS NORMALES | 235 | 10.000 | CAMAS CRITICAS (UTI, NEONATOLOGÍA Y PEDIATRÍA) | 15 | | TOTAL | 250 | |

11.19 CANTIDAD DE profesionales del área CLÍNICa PROFESIONALES DEL ÁREA CLÍNICA | | | | | | HOSCAR | RED DE SALUD | | | | | | DESCRIPCIÓN | CANTIDAD | CANTIDAD | TOTAL | | | | | Médicos | 320 | 109 | 429 | Odontólogos | 137 | 110 | 247 | Enfermeras | 126 | 27 | 153 | Matronas | 40 | 38 | 78 | Tecnólogos Médicos | 59 | 1 | 60 | Nutricionistas | 21 | 8 | 29 | Psicólogos | 25 | 14 | 39 | Kinesiólogos | 14 | | 14 | Otros profesionales | 55 | 7 | 62 | | | | | TOTAL | 797 | 314 | 1.111 |

11.20 CANTIDAD DE personal de apoyo del área CLÍNICa PERSONAL DE APOYO DEL ÁREA CLÍNICA | | | | | | | | | HOSCAR | RED DE SALUD | | | | | | DESCRIPCIÓN | CANTIDAD | CANTIDAD | TOTAL | | | | | Técnicos | 33 | | 33 | Auxiliares Enfermería especializados | 112 | 83 | 195 | Auxiliares enfermería sin especialidad | 486 | 26 | 512 | Auxiliares dentales | | 53 | 53 | | | | | TOTAL | 631 | 162 | 793 | 11.21 PERSONAL profesional del área administrativa HOSCAR * PERSONAL PROFESIONAL DEL ÁREA ADMINISTRATIVA | | | | HOSCAR | | | DESCRIPCIÓN | CANTIDAD | Profesionales | 66 | Ingenieros | 19 | Educacional | 7 | Contadores | 6 | | | TOTAL | 98 | * 11.22 PERSONAL técnico del área administrativa * PERSONAL TÉCNICO DEL ÁREA ADMINISTRATIVA | | | | | | HOSCAR | RED DE SALUD | | | | | | DESCRIPCIÓN | CANTIDAD | CANTIDAD | TOTAL | | | | | Contable | 26 | | 26 | Computación | 17 | | 17 | Administrativo | 276 | 68 | 344 | Secretarias | 22 | | 22 | Digitadoras | 25 | | 25 | Telefonistas | 5 | | 5 | Parvularias | 3 | | 3 | | | | | TOTAL | 374 | 68 | 442 |

11.23 PERSONAL auxiliar HOSCAR Año 2010 PERSONAL AUXILIAR DE SERVICIOS MENORES | | | DESCRIPCIÓN | CANTIDAD | | | Servicios menores área clínica | 254 | Servicios menores área administrativa | 63 | | | TOTAL | 317 | | |

11.24 DOTACIÓN DE QUIRÓFANOS E INTERVENCIONES QUIRÚRGICAS

TOTAL QUIRÓFANOS | 12 | INTERVENCIONES QUIRÚRGICAS | AÑO 2009 | | | INTERVENCIONES QUIRÚRGICAS (*) | 11.266 | | | (*) Incluye: | | CIRUGÍA AMBULATORIA | 1.895 | PARTOS | 949 |

11.25 DETALLE DE SERVICIOS CLÍNICOS * BRONCO PULMONAR | * CARDIOLOGÍA – CARDIOLOGÍA INFANTIL | * CIRUGÍA | * CIRUGÍA INFANTIL | * CIRUGÍA MAXILO FACIAL | * DERMATOLOGÍA | * ENDOCRINOLOGÍA | * ENDOSCOPIA | * GASTROENTEROLOGÍA | * GINECOLOGÍA | * INTERMEDIO MÉDICO | * INTERMEDIO QUIRÚRGICO | * KINESITERAPIA | * MATERNIDAD | * MEDICINA COMPLEMENTARIA | * MEDICINA FÍSICA Y REHABILITACIÓN. | * MEDICINA INTERNA | * NEFROLOGÍA | * NEUROCIRUGÍA | * NEUROLOGÍA-NEUROFISIOLOGÍA | * NUTRICIÓN | * OFTALMOLOGÍA | * OTORRINOLARINGOLOGÍA | * PABELLÓN 3°, 4°, MAXILO FACIAL, OFTALMOLOGÍA | * PEDIATRÍA-CONTROL NIÑO SANO | * PENSIONADO (1°, 2°, 3°, 4°, 5° PISO) | * UNIDAD HOSPITALIZACIÓN TRANSITORIA (UCA) | * PSIQUIATRÍA- PSICOLOGÍA | * RECUPERACIÓN | * TRAUMATOLOGÍA | * UCI. ADULTO, PEDIÁTRICO, NEONATOLOGÍA | * URGENCIA ADULTO | * URGENCIA PEDIÁTRICA | * URGENCIA GINECOLOGÍA OBSTETRICIA | * URGENCIA TRAUMATOLOGÍA | * UNIDAD DEL DOLOR | * UROLOGÍA | * ANATOMÍA PATOLÓGICA, | * BANCO DE SANGRE, | * ESTERILIZACIÓN, | * IMAGENOLOGÍA, | * INFECCIONES INTRAHOSPITALARIAS, | * LABORATORIO, | * OFICINA CALIDAD | * VACUNATORIO |

OTROS SERVICIOS NO PROPIAMENTE CLÍNICOS:

* ALIMENTACIÓN (cocina) | * DOCENCIA, | * LAVANDERÍA, | * MOVILIZACIÓN (RADIO OPERADOR DE AMBULANCIAS), | |

11.26 ATENCIONES ODONTOLÓGICAS por especialidad Hoscar año 2010 ESPECIALIDAD | ACCIONES REALIZADAS | | | Odontopediatría | 44.740 | Ortodoncia | 44.747 | Prevención | 8.117 | Operatoria | 71.526 | Endodoncia | 46.550 | Radiología Dental | 27.848 | Prótesis Fija | 14.229 | Prótesis Removible | 6.515 | Implantología | 10.020 | Periodoncia | 32.502 | TOTAL | 306.794 |

11.27 Dotación de CLÍNICAS dentales hoscar 2010

Clínicas Dentales Hoscar | 53 | 11.28 GLOSARIO DE SIGLAS Nro | SIGLA | SIGNIFICADO | 1 | ADT | ADMITION, DIRCHARGE AND TRANSFER | 2 | AUGE | ACCESO UNIVERSAL CON GARANTÍAS EXPLICITAS | 3 | Autenticación: | Proceso en el que se valida la autenticidad de un sujeto o entidad. | 4 | BD | BASE DE DATOS | 5 | BOX | Sala de atención clínica en la que se establece la relación médico - paciente. | 6 | BSC | BALANCED SCORE CARD | 7 | Camas Críticas | Camas ubicadas en un lugar especializado dotadas de alto nivel de equipamiento de soporte vital. Incluye Unidad de cuidados Intensivos de adulto, pediatría y neonatal. También Unidad Coronaria y de Tratamiento Intensivo | 8 | Carné de alta | Documento breve que se entrega al paciente que indica periodo y servicio de hospitalización, diagnostico y terapia efectuada, tratamiento en casa y fecha de control. Medico responsable. | 9 | CDSS | CLINICAL (OR DIAGNOSTIC) DECISION SUPPORT SYSTEMS | 10 | CESFAM | Centro de Salud Familiar | 11 | CGR | CONTRALORÍA GENERAL DE LA REPUBLICA | 12 | CIE 10 | CLASIFICACIÓN ESTADÍSTICA INTERNACIONAL DE ENFERMEDADES | 13 | CIE 9 MC | Clasificación Internacional de Enfermedades Versión 9 Modificación Clínica. | 14 | CIS | CLINICAL INFORMATION SYSTEM | 15 | Clínica Dental | Sala especialmente acondicionada en la que se realiza un procedimiento Terapéutico Odontológico. | 16 | CMC | Carnet de Medicina Curativa | 17 | CMM: | Capability Maturity Model | 18 | Copago | Porción de la cuenta que debe ser pagada por el paciente, no cubierta por seguros u otros | 19 | CUPO | Lapso de tiempo de la Agenda Medica asignado a la realización de una atención Clínica | 20 | Data Center: | centro de procesamiento de datos | 21 | Dentograma | Diagrama estándar en que aparecen representadas las piezas dentarias de ambas arcadas | 22 | DESADV | Aviso de Despacho Electrónico (Dispatch Advice por sus Siglas en Inglés), bajo el Estándar EDIFACT de las Naciones Unidas | 23 | DICOM | DIGITAL IMAGING AND COMMUNICATIONS IN MEDICINE | 24 | DIPRES | DIRECCIÓN DE PRESUPUESTO | 25 | DISALCAR | Dirección de Salud de Carabineros | 26 | DISANCAR | Dirección de Sanidad de Carabineros | 27 | DWH | DATA WAREHOUSE | 28 | EAN | EUROPEAN ARTICLE NUMBER | 29 | ECRI | MEDICAL DEVICE DATA INTEGRATION FOR COMPUTERIZED MAINTENANCE MANAGEMENT AND ENTERPRISE ASSET MANAGEMENT SYSTEMS
ECRI Institute’s real-time interfaces allow you to standardize your data against our industry-standard device classification systems, Health Devices International Sourcebase and the Universal Medical Device Nomenclature System™ (UMDNS™), and also enable you to process hazard and recall notices directly from Alerts Tracker™, our comprehensive healthcare product safety alerts system. | 30 | EDI | Estándar para Intercambio Electrónico de Datos (Electronic Data Interchange), compuesto por un conjunto de documentos estandarizados desarrollados por las Naciones Unidas. Estándar EDIFACT. | 31 | EEG | Electroencefalograma | 32 | EKG | Electrocardiograma | 33 | EKG | ELECTROCARDIOGRAMA | 34 | ENO | ENFERMEDADES DE NOTIFICACIÓN OBLIGATORIA | 35 | Epicrisis | Resumen del evento al alta | 36 | Episodio clínico | | 37 | ERP | ENTERPRISE RESOURCE PLANNING | 38 | ETE | ENFERMEDAD TROMBOEMBÓLICA | 39 | Evento clínico | | 40 | FCE | Registro Clínico Electrónico. Los clínicos lo identifican mejor como Ficha Clínica Electrónica | 41 | Gavetero | Dispositivo portacajas o porta gavetas, destinada a transportar los fármacos de un paciente. Cada gaveta estará identificada con el nombre del paciente. Cada gavetero pertenece a una estación de enfermería | 42 | Gbps | GIGABYTES POR SEGUNDO | 43 | GRD | GRUPO RELACIONADOS DE DIAGNÓSTICO | 44 | HA | HIGH AVAILABITY | 45 | HD | HARD DISK | 46 | HEMATOS | SW de banco de sangre del grupo BIOS. | 47 | HH | HORAS HOMBRE | 48 | HIS | HOSPITAL INFORMATION SYSTEM | 49 | HL7 | HEALTH LEVEL SEVEN | 50 | HOSCAR | HOSPITAL DE CARABINEROS | 51 | HW | HARDWARE | 52 | IDS | INTRUSIÓN DETECTION SYSTEM | 53 | IFL: | Interfaz fuera de Línea | 54 | IFRS | | 55 | IIH | Infecciones Intra Hospitalarias | 56 | IMC | Índice de masa corporal | 57 | iMED | Servicios de Aprobación de Bonos de Atención de Isapres en base a Certificación de Huella Digital | 58 | INFOLAB | SW laboratorio Contacto: Sra. Nélida: 6516490 | 59 | INFORME REM | Registro Estadístico Mensual (MINSAL) | 60 | ISP | instituto de salud publica | 61 | ITIL: | Information Technology Infrastructure Library ('Biblioteca de infraestructura de Tecnologías de Información'), | 62 | JPEG | Joint Photographic Experts Group | 63 | LAN | LOCAL AREA NETWORK | 64 | LIS | LABORATORY INFORMATION SYSTEM | 65 | LOINC | LOGICAL OBSERVATIONS IDENTIFIERS, NAMES, CODES | 66 | Mbps | MEGABYTES POR SEGUNDO | 67 | MINSAL | Ministerio de Salud | 68 | MP | MANTENCIÓN PREVENTIVA | 69 | MPI | master partient index | 70 | NANDA | North America Nurse Diagnostic Asosiation | 71 | NAS | NETWORK ATTACHED STORAGE | 72 | NN | PACIENTE SIN IDENTIDAD CONOCIDA | 73 | Odontograma | Diagrama estándar en que aparecen representadas las piezas dentarias de ambas arcadas | 74 | OEM | Original Equipment Manufacturer | 75 | ORTHOPANTOMOGRAFÍA | Radiografía dental panorámica de toda la dentadura en una sola toma. | 76 | OT | orden de trabajo | 77 | PAD | Pago Asociado a Diagnóstico | 78 | PC | PERSONAL COMPUTER | 79 | PDA | PERSONAL DIGITAL ASSISTANT | 80 | PDI | POLICIA DE INVESTIGACIONES | 81 | PMG | Programa de Mejoras de Gestión Anual | 82 | PREVIRED | Empresa Receptora de Pago Previsionales | 83 | SIDEXIS XG | Sistema de archivo digital de Radiología Dental | 84 | RAID | REDUNDANT ARRAY OF INEXPENSIVE DISKS | 85 | RAM | RANDOM ACCESS MEMORY | 86 | RCE | Registro clínico electrónico | 87 | RFQ | REQUEST FOR QUOTATION | 88 | RIS | Radiologycal Information System | 89 | RRHH | RECURSOS HUMANOS | 90 | RUN | Rol Único Nacional. NUMERO ÚNICO NACIONAL DE IDENTIFICACIÓN PERSONAL, utilizado en Chile. Tiene un digito verificador calculado con un algoritmo. En personas naturales es idéntico al RUT y se nombran en forma indistinta. | 91 | RUT | Rol Único Tributario. Es el número de identificación de personas Jurídicas en Chile (empresas). En personas naturales el RUT y el RUN coinciden. Tiene un digito verificador calculado con un algoritmo. | 92 | Sala de Procedimiento | Sala en la que se realiza un procedimiento Diagnóstico o Terapéutico. | 93 | Sala de Recuperación | Sala destinada al control inmediato y de recuperación anestésica de un paciente post operado. En esta unidad el paciente NO ESTA HOSPITALIZADO, sino de paso por algunas horas. | 94 | SAN | STORAGE AREA NETWORK | 95 | SECOSA | Seguro Complementario de Salud | 96 | SICARS | SISTEMA DE INDICADORES DE CALIDAD DE ATENCIÓN Y RESULTADOS SANITARIOS | 97 | SIGGES MINSAL | Sistema de Información de Gestión de Garantías en Salud | 98 | SIGFE | SISTEMA GUBERNAMENTAL DE FINANZAS DEL ESTADO | 99 | SIGGES | SISTEMA DE INFORMACIÓN DE GESTIÓN DE GARANTÍAS EXPLÍCITAS EN SALUD | 100 | SII | SERVICIO DE IMPUESTOS INTERNOS | 101 | SIVEP MINSAL | Sistema Vigilancia Epidemiológica | 102 | SLA | SERVICE LEVEL AGREEMENT | 103 | SMS | Sistema de Short Message System (Mensajes Cortos) para equipos Móviles | 104 | SNOMED | SYSTEMATIZED NOMENCLATURE OF MEDICINE | 105 | SOA: | La Arquitectura Orientada a Servicios (en ingles Service-Oriented Architecture o SOA), | 106 | SW | SOFTWARE | 107 | Synapse | Marca Registrada de PACS de FUJI | 108 | Tabla Quirúrgica | Programa horario por quirófano | 109 | TDR | TÉRMINOS DE REFERENCIA | 110 | TI | TECNOLOGÍA DE INFORMACIÓN | 111 | Tótem | PC Touch Screen de acceso publico para autoservicio de información del paciente e impresión de ciertos documentos | 112 | Triage | MODALIDAD DE CLASIFICACIÓN DE GRAVEDAD | 113 | UF | Unidades de Fomento | 114 | UN | UNIDAD DE NEGOCIO | 115 | UPS | UNINTERRUPTIBLE POWER SUPLY | 116 | VIA | Dispositivo invasivo a permanencia. | 117 | VPN | VIRTUAL PRIVATE NETWORK | 118 | WiFi | WIRELESS FIDELITY | 119 | XcBL | xCBL is the pre-eminent XML component library for business-to-business e-commerce. This standard is created, maintained, and supported for use - free of charge - by anyone needing document definitions for their e-commerce applications. xCBL is a set of XML business documents and their components, distributed freely here on xCBL.org. In addition to using the business documents provided, you can also use the component library to build your own documents. Either way, using xCBL promotes interoperability between applications. | 120 | XML | EXTENSIBLE MARKUP LANGUAGE |

11 formularios de presentaciÓn y evaluación

FORMULARIOS DE AUTOEVALUACIÓN A SER LLENADOS POR LOS OFERENTES

sistema de gestiÓn hospitalaria

CARACTERÍSTICAS TÉCNICAS INDISPENSABLES Se solicita que el oferente, independientemente de su oferta técnica, complete los cuadros que a continuación se indica, anotando junto a cada línea que describe una funcionalidad, si su producto cumple o no cumple con el requerimiento, contestando “SI” (= SI CUMPLE) o “NO”(=NO CUMPLE). Necesariamente debe llenar el campo “Trazabilidad” con información que permita encontrar fácilmente la referencia en el texto de la documentación de la oferta.

TIPO DE CARACTERÍSTICA | CARACTERÍSTICA | CUMPLE | NO CUMPLE | TRAZABILIDAD. Documento y página de la oferta en que se encuentra la información | 2.3.1. ARQUITECTURA | | | | | A | Operación WEB | | | | B | Arquitectura centralizada. | | | | C | Operar Multiempresa. | | | | D | Operar Multicentro. | | | | E | Arquitectura modular (esto es constituido por subsistemas funcionales independientes, integrables entre si), idealmente basados en Arquitectura SOA con interfaz a formato HL7. | | | | F | Ser escalable en cuanto a módulos en uso y en cantidad de usuarios nombrados y concurrentes. | | | | G | Parametrizable, de modo tal que el administrador del sistema pueda configurar las funcionalidades, sin que sea necesario programación y acceso a bajo nivel de datos. | | | | H | Capacidad para diseño asistido de reportes, formularios y pantallas auxiliares, con una herramienta grafica adosada al sistema. | | | | I | Capacidad de integrar aplicativos, mediante el uso una plataforma de integración. (Midleware). | | | | J | Utilizar navegador Internet Explorer 7.x y superior y deseablemente, también Mozilla Firefox. | | | | K | Debe tener capacidad para utilizar autenticación biométrica de usuarios (huella dactilar) | | | | L | Debe actualizar versiones en los terminales de usuario, desde los servidores en forma automática. | | | | M | Debe operar en ambiente virtualizado y soportar configuración en cluster con balanceo de carga. | | | | N | Debe operar en condiciones de alta disponibilidad (99.9), con redundancia de servidores y de dispositivos de almacenamiento de datos y archivos. | | | | 2.3.2. FUNCIONAL | | | | | A | Interfaces de usuario en idioma español (de uso en Chile). | | | | B | Debe desplegar imágenes (Ej. De exámenes de Imagenología (DICOM 3), de monitores clínicos, imágenes JPEG, otras). | | | | C | Debe poder escanear y guardar documentos a nivel de las estaciones de trabajo, los que deben formar parte de la FCE. | | | | D | Debe poder adaptar las interfaces (pantallas) de usuario a las necesidades clínicas específicas, mediante un Framework susceptible de ser operado por el administrador del sistema. | | | | E | Debe poderse modificar los nombres con que se identifican los campos en las interfases de usuario (etiquetas o labels), a fin de incorporar terminología local. | | | | F | A fin de poder cumplir con las actividades docentes, el sistema debe permitir la creación de varias categorías de alumnos-usuarios, quienes podrán ingresar datos en la FCE utilizando caracteres de color a fin de ser identificado fácilmente, en calidad de “registro transitorio”, el que podrá ser borrado, modificado o validado por un profesional usuario normal, tras lo cual, el registro será inmodificable. Debe haber algún sistema que advierta al médico tratante (responsable del paciente) de la existencia de estos registros transitorios, que no han sido validados. | | | | G | Debe tener un Log de registro de transacciones que permita efectuar auditorias.(que, quien y cuando hizo) | | | | H | Debe proveer, utilizar y administrar una firma electrónica privada (simple), acorde con la legislación chilena. | | | | i | Debe cumplir con la legislación chilena vinculada con la privacidad de la información crítica, con la legislación relacionada con Salud y con la reglamentación del Ministerio de Salud, DIPRECA y DISALCAR. | | | | j | Debe poder incorporar fotografías digitales desde los módulos de uso clínico. | | | | k | Trazabilidad de las acciones realizadas y de la información almacenada en el sistema FCE (cumpliendo todos los estándares de confidencialidad y protección de datos del paciente). | | | | l | Estandarización de procesos transversales para toda la Organización, a partir de la reingeniería de procesos. | | | | m | Estandarización de la información clínica y administrativa. | | | | n | Debe permitir configurar y gestionar programas de salud ministeriales e institucionales, tanto en pacientes pediátricos como en adultos y medicina familiar. | | | | o | Debe permitir la gestión del concepto de medicina familiar en los CESFAM (Centros de Salud Familiar), utilizando árboles de vinculación parental. | | | | 2.3.3. ESTÁNDARES | | | | | a | Integrado entre si e integrable con otros aplicativos mediante estándares HL 7. | | | | b | Utilización de estándares HL7, CIE 10, DICOM 3, SNOMED. | | | | c | Debe utilizar código de barras EAN-13, EAN-128, DUN-14, Data Matrix, (impresión y lectura de etiquetas) desde terminales fijos y móviles (inalámbricos). Debe soportar los drivers de los dispositivos correspondientes. | | | | d | Debe proveer Manuales de usuario y Documentación en Español | | | | e | Debe adecuarse en todo momento a la legislación y reglamentación chilena y reglamentación Institucional vigente. | | | | f | Debe utilizar el RUT con dígito verificador, (debe incorporar algoritmo de calculo del digito verificador) como identificador principal. | | | | 2.3.4. SEGURIDAD | | | | | a | Debe disponer de niveles de seguridad de acceso, configurables en cuanto a datos, a funcionalidades y a estructura organizacional. | | | | b | Autorización y autenticación de ingreso. | | | | c | Capacidad de generación y configuración de roles, reglas y privilegios por parte del administrador. | | | | d | Capacidad de encriptación en las comunicaciones. | | | | e | Capacidad de generar alertas ante incidentes de seguridad predefinidos. | | | | f | Debe utilizar un sistema biométrico de huella dactilar como validador de la identificación. | | | | g | Ofrecer garantía en los accesos a la FCE cumpliendo la Ley 19628 de Protección de vida privada o datos de carácter personal, tanto para pacientes como prestadores. | | | |

CARACTERÍSTICAS FUNCIONALES DE LA FCE: Se solicita que para cada una de las filas de los diferentes módulos que aparecen a continuación, el oferente se autocalifique en el sentido de * Asignarse dos puntos si su aplicación cuenta con la funcionalidad. * Asignarse un punto si compromete el desarrollo de la funcionalidad para este proyecto y * Cero puntos cuando el producto no cuenta con la funcionalidad y ésta no será desarrollada. Necesariamente debe llenar el campo “Trazabilidad” con información que permita encontrar fácilmente la referencia en el texto de la documentación de la oferta. Si la información resulta inexacta, se corregirá la evaluación a cero puntos.

MÓDULO CLÍNICO

Nro | Concepto | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Identificación del paciente | Captura de antecedentes demográficos desde archivo maestro de pacientes (clientes) | | | | 0 | | 2 | | Generación de episodios y eventos clínicos. Discriminación si episodio es nuevo o control de uno existente | | | | 0 | | 3 | Motivo de Consulta | Anamnesis actual. Capacidad para registrar síntomas y registrar signos dominantes, en campos estructurados de selección | | | | 0 | | 4 | | Capacidad de la aplicación para que el médico pueda generar y administrar listas cortas de síntomas y de signos de uso frecuente, vinculadas a la especialidad y con su login. | | | | 0 | | 5 | | Registro de alergias. Selección de alternativas predefinidas parametrizables. La información de alergias debe visualizarse en forma permanente a modo de advertencia. | | | | 0 | | 6 | | Registro de Hábitos. Selección de alternativas predefinidas parametrizables. | | | | 0 | | 7 | Enfermedades Previas (anamnesis remota) | Anamnesis remota. Posibilidad de acceso a episodios anteriores. | | | | 0 | | 8 | | Si no hubiere episodios anteriores en la FCE, capacidad para registrar estos antecedentes en campo texto | | | | 0 | | 9 | Examen Físico | Registro de Examen Físico. Estructurado, por segmentos y sistemas. | | | | 0 | | 10 | Diagnóstico | Hipótesis diagnóstica. Se debe poder ingresar la cantidad de diagnósticos que sea necesario. | | | | 0 | | 11 | | Debe considerarse que los diagnósticos sufren modificaciones durante el estudio, antes de llegar a los diagnósticos definitivos. | | | | 0 | | 12 | | Uso de nomenclatura CIE 10. | | | | 0 | | 13 | | El mantenedor del CIE 10 debe permitir agregar sinónimos de uso corriente asociada a la nomenclatura oficial, y acceder por cualquiera de estos sinónimos a la codificación. | | | | 0 | | 14 | | Capacidad para que el médico pueda generar y administrar listas cortas de diagnósticos frecuentes, vinculadas con su login. | | | | 0 | | 15 | Plan de Estudio | El médico registra en la FCE los exámenes requeridos. Vinculo con módulo de formularios. | | | | 0 | | 16 | | A partir de esta información debe generarse automáticamente las solicitudes de examen a los departamentos que corresponda. También puede ser a la inversa, que el médico solicite los exámenes en el formulario correspondiente, y a partir de esto se registre en la FCE los exámenes solicitados. (Evitar doble digitación) | | | | 0 | | 17 | | Los formularios deben estar integrados con Laboratorio, RIS-PACS, Banco de Sangre, Servicios de apoyo clínico (exámenes y procedimientos diagnósticos. Ej. Endoscopía) | | | | 0 | | 18 | Resultado de exámenes | Trazabilidad y visualización del estatus de las solicitudes. (Ej. pendiente, realizado, pendiente de informe, terminado) | | | | 0 | | 19 | | Recepción automática de resultados de exámenes de laboratorio y servicios de apoyo clínico. | | | | 0 | | 20 | | Capacidad para visualización de imágenes de exámenes de Imagenología en formato DICOM e imágenes de exámenes de servicios de apoyo en formato JPEG u otros. | | | | 0 | | 21 | Plan Terapéutico: Prescripción de Medicamentos | El médico registra diariamente en la FCE la medicación prescrita. (Producto, presentación, dosis, vía de aplicación, frecuencia y días de uso). Se requiere que el médico ingrese los medicamentos una sola vez, llenándose automáticamente el registro en la FCE y el recetario. (Evitar doble digitación). | | | | 0 | | 22 | | A partir de este registro, debe generarse automáticamente la receta electrónica. El proceso puede ocurrir a la inversa, que el médico ingrese la prescripción directamente en el formulario recetario, para aprovechar las ventajas e inteligencia del módulo de farmacia, y a partir de esto se registre en la FCE los medicamentos indicados. (Evitar doble digitación). | | | | 0 | | 23 | | Mediante integración, las indicaciones de terapia y estudio, se transferirán automáticamente al módulo de enfermería | | | | 0 | | 24 | | Visualización de alertas en alergias medicamentosas, contraindicaciones o interacciones con otros medicamentos prescritos. En estos casos debe impedir la indicación. | | | | 0 | | 25 | | El sistema debe cotejar la indicación que se está intentando ingresar, con los otros medicamentos ya indicados, a fin de verificar la existencia de interacción de medicamentos. Integración con módulo de farmacología. | | | | 0 | | 26 | | En caso de insistir en la indicación a pesar de las alertas, el médico deberá justificar sus razones, bajo su firma, en un campo que aparecerá para dicho efecto. | | | | 0 | | 27 | | El sistema no aceptará indicaciones de dosis de medicamentos que se encuentre fuera de los rangos de uso habitual. El módulo de farmacia considera dosis de infantes y lactantes calculadas sobre el peso del niño. | | | | 0 | | 28 | | En caso de insistir en la indicación de dosis inusuales, a pesar de las alertas, el médico deberá justificar sus razones, bajo su firma, en un campo que aparecerá para dicho efecto. | | | | 0 | | 29 | | Posibilidad de suspender o anular una prescripción que deba aplicarse a futuro (Ej. Necesidad de cambiar un tratamiento ya iniciado). Si se ha indicado una terapia medicamentosa para varios días, se podrán anular o suspender las dosis aun no aplicadas. | | | | 0 | | 30 | | La suspensión o anulación se reflejara en el módulo de enfermería. | | | | 0 | | 31 | | Posibilidad de repetir y/o modificar prescripciones anteriores, para generar una nueva prescripción. | | | | 0 | | 32 | | Las prescripciones ya firmadas (realizadas) no podrán ser modificadas. Para modificar en estos casos, debe SUSPENDER la indicación y volver a indicar. Las prescripciones NO FIRMADAS podrán ser modificadas. | | | | 0 | | 33 | | En general ninguna información, registro, solicitud, prescripción ni indicación podrá ser modificada desde el momento en qué esta es firmada (grabada). Hacen excepción los registros no validados realizados por alumnos e internos). | | | | 0 | | 34 | | Si se desea modificar una indicación debe suspenderse esa terapia e indicar otra nueva. | | | | 0 | | 35 | | Capacidad para proporcionar ayuda farmacológica. Vinculación con módulo Farmacia. Dosis máximas, mínimas, interacciones, antagonismos, alergias, alternativas de nombres comerciales, genéricos. | | | | 0 | | 36 | | Capacidad para que el médico pueda generar y administrar listas cortas de medicamentos frecuentes, vinculadas con su login. | | | | 0 | | 37 | | Alerta en caso de duplicidad de prescripción. | | | | 0 | | 38 | | Indicaciones de cuidados de enfermería. Integración con módulo de enfermería | | | | 0 | | 39 | | Indicación de reposo. Selección múltiple de opciones. Aparecerá señalado en pantalla de enfermería. | | | | 0 | | 40 | Nutrición | Indicación nutricional habitual (dieta). Integración con módulo de nutrición. | | | | 0 | | 41 | | Nutrición Enteral. Integración con módulo de farmacia. | | | | 0 | | 42 | | Nutrición Para enteral. Integración con módulo de farmacia. | | | | 0 | | 43 | Evolución del paciente | Registro de Evolución Clínica. Permite anotaciones correspondientes a los controles en visitas o consultas sucesivas en pacientes hospitalizados y ambulatorios. | | | | 0 | | 44 | | Permite registrar la participación de inter consultores, kinesiólogos, u otros profesionales que se defina, vinculados con las indicaciones o requerimientos del médico tratante. | | | | 0 | | 45 | | Diagnósticos Definitivos, utilizando Nomenclatura CIE 10. | | | | 0 | | 46 | | Se debe poder ingresar la cantidad de diagnósticos definitivos que sea necesario. | | | | 0 | | 47 | | Capacidad del sistema para generar y presentar en pantalla, resúmenes clínicos que permitan visualizar la situación del paciente. Estos resúmenes deberán contener información que se defina, de Síntomas principales, diagnostico de ingreso, evolución de los diagnósticos, plan de estudio, plan terapéutico, balance hídrico, signos vitales, protocolo operatorio. Capacidad de ser impresos. | | | | 0 | | 48 | | Visualización de eventos anteriores, ordenados por fecha, los que pueden ser visualizados. | | | | 0 | | 49 | Epicrisis | Confección automática de la Epicrisis. Debe contener un campo para agregar automáticamente la clasificación GRD, cuando ésta haya sido realizada. Debe ofrecer un formato pre llenado con datos relevantes que se defina los que serán capturados del sistema, incluyendo terapia ambulatorias e indicación de controles, el que podrá ser complementado por el médico, llenando campos adicionales o incorporando texto libre. | | | | 0 | | 50 | | La Epicrisis debe poder ser impresa. | | | | 0 | | 51 | | Vinculación con IR GRD. Debe integrarse en forma bidireccional con el módulo IR GRD | | | | 0 | | 52 | Egreso del Paciente | Registro de causa de Egreso. Alta médica, traslado, fallecimiento (Opciones predefinidas seleccionables). | | | | 0 | | 53 | | Indicaciones de alta médica. Las indicaciones se anotan en forma idéntica a la condición de hospitalización. El sistema captura las indicaciones del último día, que se entienden como indicaciones para cumplir en su domicilio. | | | | 0 | | 54 | | A partir del alta médica se habilita impresión de indicaciones, recetas, terapia y carné de alta. Puede requerirse la impresión de una receta para ser despachada por farmacia externa. Posibilidad que el paciente obtenga la información que se defina desde los módulos de información de autoservicio (KIOSCOS) | | | | 0 | | 55 | Pediatría | Debe permitir el registro, gestión y control de programas sanitarios específicos. Puede ser un módulo adicional vinculado a la FCE. Ejemplo: Inmunización (vacunación), control de niño sano. Vinculación con Módulo de Gestión de Centros de Salud Familiar (CESFAM) y de Programas de Salud | | | | 0 | | 56 | | Debe permitir agregar nuevos programas. (La mayoría de los programas en Chile y su gestión y control están definidos por normas nacionales). | | | | 0 | | 57 | | Reportes de cumplimiento de programas. | | | | 0 | | 58 | | Calendario de vacunación configurable, para seguimiento e información del paciente. Puede ser obtenido en los KIOSCOS de autoservicio. | | | | 0 | | 59 | | Capacidad para el Registro antropométrico percentilado. | | | | 0 | | 60 | | Registro gráfico de maduración neurológica | | | | 0 | | 61 | | Capacidad para administrar e imprimir material instructivo para los padres. | | | | 0 | | 62 | | Capacidad para visualizar DESDE la FCE del neonato, la ficha clínica de la madre. Verificación de antecedentes del embarazo y del parto. | | | | 0 | | 63 | Programas de Salud | Debe permitir que el paciente pueda ser vinculado con programas de salud y acciones de medicina preventiva. Vinculación con el Módulo de Gestión de Centros de Salud Familiar (CESFAM) y de Programas de Salud. | | | | | | 64 | Docencia | Debe permitir que los alumnos y becados registren información en la FCE en carácter de BORRADOR, la que tiene que ser validada por el médico a cargo del paciente con su firma electrónica para que tengan valor. Deben poder distinguirse fácilmente estos textos en borrador, por el color, tipo de escritura u otro elemento distintivo. | | | | 0 | | 65 | | Las indicaciones, solicitudes de examen, medicación y terapias realizadas por alumnos y becados, NO PODRÁN SER EJECUTADAS por el sistema, salvo que sean validadas por el médico tratante. Los alumnos y becados tendrán perfiles de usuario que les asocie la funcionalidad solicitada. | | | | 0 | | 66 | | El sistema debe advertir que existe un registro clínico en BORRADOR pendiente de validación. Se definirá a quien se debe informar en forma automática esta situación. | | | | 0 | | 67 | | El sistema debe advertir que un paciente no tiene indicaciones terapéuticas vigentes. (No fue visto por su médico tratante).- Se definirá a quien se debe informar en forma automática. | | | | 0 | | 68 | Otras Funcionalidades Requeridas | Visualización de información de Enfermería (Signos vitales, balance hídrico, cumplimiento de terapias e indicaciones y otras funcionalidades incorporadas en el módulo de enfermería). Integración con módulo de enfermería. | | | | 0 | | 69 | | Sub módulo para generar, mantener y desplegar Guías Clínicas. Las Guías Clínicas están destinadas a apoyar la toma de decisiones clínicas con protocolos de diagnóstico y tratamiento. | | | | 0 | | 70 | | Sub módulo para generar, mantener y desplegar protocolos clínicos. Los protocolos señalan procedimientos establecidos. Ej.: protocolos de patologías AUGE. | | | | 0 | | 71 | | Capacidad para funcionar en redes inalámbricas (WiFi). | | | | 0 | | 72 | | Capacidad para operar con notebook y/o Tablet PC, Ipad, Net books. | | | | 0 | | 73 | | (Compatibilidad con Pantallas Touch Screen de los KIOSCOS y pabellones quirúrgicos). | | | | 0 | | 74 | | Posibilidad de utilizar PDA y Pocket PC. Dispositivos con pantallas de formato pequeño. | | | | 0 | | 75 | | Parametrización de la interfaz de usuario de la FCE, para adecuarla a las necesidades de las diferentes especialidades médicas. | | | | 0 | | 76 | | La aplicación debe contar con herramientas que permitan al administrador del sistema, modificar las pantallas a requerimiento del usuario y vincularlas con el login o rol de usuario | | | | 0 | | 77 | | Capacidad de incorporar diagramas específicos por especialidad, para que el médico pueda dibujar marcas en determinada región anatómica (Ej. Fondo de ojos, nódulos en mamas, tiroides) | | | | 0 | | 78 | | Para obstetricia debe incorporar un PARTOGRAMA", que registra parámetros tales como: dilatación cervical, frecuencia de contracciones, frecuencia cardiaca fetal, plano de Hodge. | | | | 0 | | 79 | | Capacidad para incorporar documentos escaneados a la Ficha, vinculados con el evento. | | | | 0 | | 80 | | Capacidad para incorporar FOTOS DIGITALES en el momento de la consulta, por puerto USB. Ej.: Dermatología. | | | | 0 | | 81 | | Debe tener una herramienta que permita al médico configurar una alerta o alarma ante una situación determinada. | | | | 0 | | 82 | | Calculo automático del IMC (Índice de masa corporal). | | | | 0 | | 83 | | Alertas para patologías AUGE. Vinculación con CIE 10. Despliegue de formulario especifico. Notificación automática por correo u otro procedimiento a la persona u oficina encargada. | | | | 0 | | 84 | | Vinculación de las alertas con el protocolo pertinente (si existe). | | | | 0 | | 85 | | Vincular estas alertas con la lógica de proceso y gestión establecido para enfermedades AUGE. | | | | 0 | | 86 | | Alertas para enfermedades de notificación obligatoria (ENO). Vinculación con CIE 10. Despliegue de formulario especifico. Notificación automática por correo u otro procedimiento a la persona u oficina encargada. | | | | 0 | | 87 | | Alertas para enfermedades incorporadas en el programa de Vigilancia Epidemiológica. Vinculación con CIE 10. Despliegue de formulario especifico. Notificación automática por correo u otro procedimiento a la persona u oficina encargada. | | | | 0 | | 88 | | Alertas para señalar la disponibilidad en el sistema de Guías Clínicas o protocolos. Vinculación con CIE 10. | | | | 0 | | 89 | | Operación y Gestión de Firma Electrónica simple. La aplicación debe proveerse en condiciones que permitan su utilización asociada a TODOS los registros clínicos que sean ingresados. Capacidad de autenticación de registros existentes. | | | | 0 | | 90 | | Capacidad para gestionar firma electrónica avanzada | | | | 0 | | 91 | | Cargo en cuenta de paciente, de Visitas medicas efectuadas a pacientes hospitalizados. Cada vez que un profesional ingrese información en primeras visitas (anamnesis, etc.) o en visitas sucesivas (evolución) en la FCE, el sistema debe considerar que se ha efectuado una “visita a paciente hospitalizado”, cargando automáticamente en la cuenta corriente del paciente la prestación indicada. Esta prestación debe ser acreditada en la cuenta del médico y del servicio clínico o unidad de negocio pertinente (proveedor interno) | | | | 0 | | 92 | | Al igual que en el punto precedente, deben registrarse y cargarse en cuenta del paciente las INTER CONSULTAS, VISITAS DE EVALUACIÓN pre anestésica, JUNTAS MÉDICAS, con indicación de los integrantes presentes. Evaluación y sesiones de Kinesioterapia. | | | | 0 | | 93 | | Posibilidad de categorizar el estado de salud del paciente, para información de familiares e indicar si un paciente hospitalizado tiene autorización para recibir visitas. Indicar posible alta a 24 - 48 horas. Integración con Admisión o módulo de gestión de camas, oficina de atención al paciente. | | | | 0 | | 94 | | Posibilidad de invocar otra FCE. Situaciones en que el paciente es un recién nacido y se requiere información respecto del parto registrado en la FCE materna. | | | | 0 | | 95 | | En paciente ambulatorio el médico podrá asignar personalmente un cupo para control, accediendo a sus cupos futuros (destinados a pacientes en control) del módulo de agenda. El médico podrá invocar su agenda y asignar con un simple clic un cupo destinado a controles. El módulo de agenda capturará el nombre del paciente desde cuya ficha se hace la gestión. | | | | 0 | | 96 | | En pacientes ambulatorios el médico podrá marcar en un campo si para el siguiente control requiere o no de la ficha de papel. | | | | 0 | | 97 | | Herramienta que permita configurar la interfaz de usuario dependiendo de la especialidad y subespecialidad, vinculados con perfiles, roles y privilegios. | | | | 0 | | 98 | | Generación de formularios foliados de consentimiento informado, el que será impreso FOLIADO, con numeración única. Los formularios impresos y firmados serán escaneados en la FCE y el documento físico archivados en la Ficha de papel o en un Archivo especial, por correlativo de folio. | | | | 0 | | 99 | | Acceso a nomenclatura y terminología médica. Debe proveerse las tablas SNOMED. | | | | 0 | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | |

Puntaje máximo posible | 198 | Puntaje mínimo exigido | 139 | Máximo ítem "No Cumple ni será desarrollado" | 4 | Ponderación del módulo | 12 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

MÓDULO DE ENFERMERÍA

Nro | Concepto | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | | Definición de camas asignadas a cada estación de enfermería, para generar su mapa de camas. Vinculación con admisión (administración de camas). | | | | 0 | | 2 | Ingreso | Realización del ingreso de Enfermería del paciente. Deseable utilización de NANDA, NIC, NOC. | | | | 0 | | 3 | | Registro de Evolución de Enfermería | | | | 0 | | 4 | | Registro de signos vitales. Visualización gráfica. Debe permitir cambiar la escala a voluntad a fin de desplegar un día, una semana, un mes. | | | | 0 | | 5 | | La grafica de signos vitales debe poder ser configurable para cada estación de enfermería, definiendo cuales son los parámetros que registrará. Parametrización de opciones a registrar. | | | | 0 | | 6 | Cuidados de enfermería | Registro de acciones de confort. | | | | 0 | | 7 | | Evaluación y gestión de riesgo de caídas y eventos adversos. Formulario de consentimiento de inmovilización otorgado por familiares, el que debe ser impreso y firmado por los familiares, de modo similar al proceso del consentimiento informado. | | | | 0 | | 8 | | Registro de caídas y /o eventos adversos que el administrador configure en el sistema | | | | 0 | | 9 | | Posibilidad de notificación de eventos adversos por mail u otro mecanismo a la enfermera jefe o la persona responsable de calidad u otra que se defina. | | | | 0 | | 10 | | Prevención y Control de ulceras por presión (escaras). Capacidad de marcar áreas especificas en un diagrama, señalando el lugar de las lesiones. | | | | 0 | | 11 | | Acceso al protocolo de prevención de escaras y formularios pertinentes. Adicionalmente debe enviar automáticamente la notificación pertinente al comité de escaras. | | | | 0 | | 12 | | Prevención Enfermedad Trombo Embólica. Uso del protocolo pertinente | | | | 0 | | 13 | | Balance hídrico. Calculo automático a medida que se ingresan los datos. Cierre del cálculo a una hora diaria predefinida. Integración con administración de sueros, hemoderivados, otros fluidos. | | | | 0 | | 14 | | Registro de acciones de enfermería. Ej.: Curaciones, tratamientos específicos. | | | | 0 | | 15 | Medicación | Programación horaria automática de la medicación diaria prescrita a los pacientes en la estación de enfermería correspondiente al sector. Información de toda la unidad y por paciente, con indicación de nombre paciente, numero de cama, medicamento, dosis, vía de administración. Generación automática de lista de trabajo y actividades a partir de las indicaciones médicas y reglas que se defina. | | | | 0 | | 16 | | Capacidad para operar con lectores de código de barras para automatizar validación y registro de medicación. Comprobación de terapia vigente y registro automático de hora y funcionario que administra la medicación. (Triada medicamento- paciente – funcionario). Uso de códigos EAN-128 y Data Matrix, para identificación de pacientes, funcionarios, profesionales, fármacos unidosis y frascos de laboratorio para toma de muestras. | | | | 0 | | 17 | | En el caso precedente, el sistema tiene que hacer un matching entre el paciente y la medicación, verificando la vigencia de la indicación. También valida que el medicamento no ha excedido su fecha de caducidad. El registro del funcionario (tercera lectura de código de barra), permite continuar con la siguiente medicación en el mismo paciente o en otro. El sistema permitirá validar o registrar al profesional que ejecuta la toma de muestras al final de varias muestras. No requiere identificarse en cada muestra de una sesión de toma de muestras. | | | | 0 | | 18 | | En caso de discrepancia o no validación en la secuencia de registro de código de barras para la administración de un fármaco, la acción podrá ser abortada, quedando registrada esta situación y la razón. La medicación NO aparecerá como efectuada. | | | | 0 | | 19 | | Cuando la medicación indicada tiene carácter de inmediata y es administrada al paciente ANTES que el producto sea despachado de farmacia, se asume que se utilizó productos del botiquín o bodega local de la estación de enfermería. En este caso, el sistema valida el producto contra la indicación, de la manera normal. En la receta debe indicar que el producto en vez de colocarse en la caja con la identificación del paciente en la gaveta de fármacos, debe depositarlos en la caja botiquín o Bodega local, del mismo gavetero. Al ser recibido, la enfermera deposita el producto en la bodega o botiquín, recuperando su stock. | | | | 0 | | 20 | | Registro automático de la medicación suministrada | | | | 0 | | 21 | | Programación automática de actividades diarias (por hora), a partir de las indicaciones médicas y reglas que se defina. | | | | 0 | | 22 | | Capacidad para el ingreso de actividades adicionales, en forma manual. | | | | 0 | | 23 | | Herramienta para el cálculo de la velocidad de goteo en sueros y hemoderivados. | | | | 0 | | 24 | Exámenes | El sistema advertirá de los exámenes que hayan sido solicitados por el Médico tratante | | | | 0 | | 25 | | De acuerdo con los protocolos de laboratorio se advertirá de las condiciones exigidas a las muestras y/o tipo de frasco/tubo a utilizar. Integración con LIS. | | | | 0 | | 26 | | Capacidad para visualización de información del Vademécum de productos farmacológicos. Acceso informativo (sólo lectura) al módulo sistema de farmacia. | | | | 0 | | 27 | | Toma de muestras. Impresión de etiquetas para frascos o tubos, con inclusión de código de barras | | | | 0 | | 28 | | Verificación de toma de muestras a efectuarse con triple lectura de código de barras, de modo similar a la medicación. El sistema permitirá validar o registrar al profesional que ejecuta la toma de muestras al final de varias muestras. No requiere identificarse en cada muestra de una sesión de toma de muestras. | | | | 0 | | 29 | | Seguimiento de exámenes y procedimientos solicitados. Integración con RIS, LIS, y servicios de apoyo diagnostico. | | | | 0 | | 30 | Otras funcionalidades | Control de actividades pendientes. Configuración de Alertas de actividades no realizadas según lo programado. | | | | 0 | | 31 | | Anulación de órdenes y recetas pendientes al producirse un alta. Vinculación con Farmacia, Laboratorio, Imagenología. | | | | 0 | | 32 | | En caso de traslado del paciente a otra sala de hospitalización del hospital, la vista de las actividades de enfermería indicadas y programadas deben trasladarse a la estación de enfermería que corresponda a la nueva ubicación del paciente. Vinculación con ADT. | | | | 0 | | 33 | | En caso de traslado transitorio del paciente, por ejemplo a pabellón, Imagenología, procedimiento fuera del hospital esta ubicación debe reflejarse en el sistema ADT | | | | 0 | | 34 | | Vista del stock de insumos y fármacos en botiquín. Integración con bodega (periférica) de Farmacia. (ERP) | | | | 0 | | 35 | | Posibilidad de hacer devolución a farmacia de productos no utilizados por el paciente. Integración con Farmacia (reingreso de producto + nota de crédito en la cuenta del paciente). | | | | 0 | | 36 | | Impresión de carné de alta e indicaciones. Captura diagnostico, tratamiento indicado, fecha de control y otros datos que se defina. | | | | 0 | | 37 | | Capacidad de impresión de documentos de alta que se debe entregar al paciente. | | | | 0 | | 38 | | Censo y estado de Camas (bloqueada, en mantención, en aseo). Integración con módulo de gestión de camas (ADT) | | | | 0 | | 39 | | Capacidad de generación de un resumen configurable de actividades efectuadas y actividades pendientes, para los efectos de los cambios de turno. Este resumen debe quedar guardado en alguna parte | | | | 0 | | 40 | | Capacidad de generar hoja de Residencia de Enfermería. Este documento debe quedar guardado en alguna parte | | | | 0 | | 41 | | Visualización de FCE (vista del médico en condición Sólo Lectura) | | | | 0 | | 42 | | Posibilidad de vincular protocolos de atención o Guías de Enfermería | | | | 0 | | 43 | | Capacidad de generar nuevos Formularios | | | | 0 | | 44 | | Capacidad de generar reportes de gestión de enfermería. | | | | 0 | | 45 | | Capacidad para operar vía WiFi | | | | 0 | | 46 | | Capacidad para utilizar lectores de código de barra inalámbricos. | | | | 0 | | 47 | | Capacidad de incorporar diagramas específicos por especialidad, para que la enfermera pueda dibujar marcas en determinada región anatómica (Ej. Descripción de ulceras por presión. | | | | 0 | | 48 | | Capacidad para incorporar FOTOS DIGITALES por puerto USB, en el momento de la atención del paciente. Ej.: lesiones cutáneas, vías instaladas. | | | | 0 | | 49 | | Programa para registro, control y mantención de vías y sondas. Alarmas de fechas de recambio publicables en pantalla de actividades de enfermería. Información a IIH. | | | | 0 | | 50 | | Indispensable incluir campos de datos que alimenten indicadores de calidad. Al momento de reingeniería de procesos, considerar requerimientos de la Unidad de Calidad del Hospital. | | | | 0 | | 51 | | Incluir pautas de supervisión de calidad e IIH. | | | | 0 | | 52 | | Uso de firma electrónica simple para registros de enfermería | | | | 0 | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | |

Puntaje máximo posible | 104 | Puntaje mínimo exigido | 73 | Máximo ítem "No Cumple ni será desarrollado" | 2 | Ponderación del módulo | 8 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |
MÓDULO DE NUTRICIÓN

Nro. | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Visualización de la indicación médica para cada paciente en particular. Integración con módulo clínico. | | | | 0 | | 2 | Generar menús y raciones con su correspondiente valor nutricional. | | | | 0 | | 3 | Selección de menú para pacientes hospitalizados. | | | | 0 | | 4 | Valor nutricional del menú seleccionado. | | | | 0 | | 5 | Registro de Exclusiones y preferencias alimentarias del paciente. | | | | 0 | | 6 | Alarma de alergias alimentarias. Vinculación con herramienta de alergias. | | | | 0 | | 7 | Listado de menú por paciente y por sector de distribución de alimentos (carros). | | | | 0 | | 8 | Registro de alimento efectivamente consumido por el paciente | | | | 0 | | 9 | Capacidad de generar reportes de actividades realizadas y de ingredientes implícitos en las dietas que fueron asignadas a los pacientes. | | | | 0 | | 10 | Alimentación enteral. Es provista por farmacia. | | | | 0 | | 11 | Alimentación para enteral. Es provista por farmacia. | | | | 0 | | 12 | Calculo de insumos para preparación de raciones por tipo de menú. Vinculación con bodega (economato) | | | | 0 | | 13 | Generación de dietas para pacientes ambulatorios. | | | | 0 | | 14 | Las indicaciones nutricionales y sugerencias de menú, podrán ser impresas en los KIOSCOS | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | |

Puntaje máximo posible | 28 | Puntaje mínimo exigido | 20 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 2 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

MÓDULO DE FORMULARIOS Y SOLICITUDES

Nro | Concepto | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Recetario. | El recetario debe informar de la no existencia de un producto requerido. Debe ofrecer dosificación y modo de uso por defecto. Aplica la inteligencia del Módulo de farmacia. Capacidad de impresión de recetas. Integración con módulo de farmacología. | | | | 0 | | 2 | | Formato especial de receta para drogas controladas y estupefacientes. | | | | 0 | | 3 | Solicitudes: | Toda solicitud debe ser foliada con número único. | | | | 0 | | 4 | | Transfusión o Hemoderivados. Integración con Banco de Sangre. | | | | 0 | | 5 | | Exámenes de Laboratorio. Integración con Laboratorio. | | | | 0 | | 6 | | Exámenes de Imagenología. Integración con RIS y PACS. | | | | 0 | | 7 | | Pabellón Quirúrgico. Integración con módulo de Pabellones. | | | | 0 | | 8 | | Kinesioterapia. Módulo pertinente de Servicios de apoyo clínico. Trazabilidad del proceso | | | | 0 | | 9 | | Solicitud de otros exámenes de diagnóstico. Módulo pertinente de Servicios de apoyo clínico. Trazabilidad del proceso | | | | 0 | | 10 | | Solicitud de procedimientos diagnósticos. Módulo pertinente de Servicios de apoyo clínico. Trazabilidad del proceso. | | | | 0 | | 11 | | Interconsultas a especialistas. Módulo pertinente de Servicios de apoyo clínico. Trazabilidad del proceso | | | | 0 | | 12 | | Traslado de paciente. Integración con Admisión y con movilización | | | | 0 | | 13 | Certificados. | Todo Certificado debe ser foliado, con numero único | | | | 0 | | 14 | | De parto. Registro en "libro de partos". Hay que crear el Libro de Registro de Partos, con el formato requerido. | | | | 0 | | 15 | | Licencia medica. Integración con sistema de licencias de Carabineros. Integración con sistema de licencias medicas de la Superintendencia de Salud, cuando esté disponible este servicio. | | | | 0 | | 16 | | Fallecimiento. | | | | 0 | | 17 | | Comprobante de atención. | | | | 0 | | 18 | Notificaciones. | Toda Notificación debe ser foliada, con numero único | | | | 0 | | 19 | | Las notificaciones DEBEN aparecer en la pantalla del encargado y ser impresas. | | | | 0 | | 20 | | Debe generarse un reporte con las notificaciones ocurridas. | | | | 0 | | 21 | | Toda Notificación debe poder ser impresa. | | | | 0 | | 22 | | De enfermedad de Notificación obligatoria (ENO). Debe permitir el uso de campos de selección múltiple. Vinculación con CIE 10. | | | | 0 | | 23 | | Notificación de mordedura de animales. Vinculación con CIE 10 | | | | 0 | | 24 | | De patología AUGE. Debe permitir el uso de campos de selección múltiple. | | | | 0 | | 25 | | Enfermedades bajo supervigilancia epidemiológica. Debe permitir el uso de campos de selección múltiple | | | | 0 | | 26 | | Accidentes de tránsito. Debe permitir el uso de campos de selección múltiple. | | | | 0 | | 27 | | Accidentes laborales de Carabineros activos. (En acto de Servicio). Debe permitir el uso de campos de selección múltiple. | | | | 0 | | 28 | | Accidentes laborales de empleados del HOSCAR afectos a mutual de seguridad. | | | | 0 | | 29 | | Situaciones médico legales. Debe permitir el uso de campos de selección múltiple | | | | 0 | | 30 | | Lesiones, agresiones, violencia intrafamiliar. | | | | 0 | | 31 | Formularios | Todo formulario DEBE SER FOLIADO con número ÚNICO. | | | | 0 | | 32 | | De consentimiento informado. | | | | 0 | | 33 | | De consentimiento de contención de paciente. | | | | 0 | | 34 | | De traslado de cuerpos al Instituto Médico Legal. | | | | 0 | | 35 | | Hoja de anestesia (con capacidad de generar gráficos). Balance Hídrico. Anotación grafica de signos vitales, suministro de fluidos y medicamentos, incidentes, etc. | | | | 0 | | 36 | | Hoja de parto "Partograma". (Con capacidad de generar gráficos). Balance Hídrico. Anotación gráfica de dilatación cervical, frecuencia de contracciones, frecuencia cardiaca fetal, plano de Hodge. | | | | 0 | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | Puntaje máximo posible | 72 | Puntaje mínimo exigido | 50 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 4 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

GESTIÓN DE ATENCIÓN DE URGENCIA

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Ingreso del paciente a Urgencia | | | | 0 | | 2 | Captura de datos Demográficos. Integración con archivo maestro de pacientes. | | | | 0 | | 3 | Discriminación de paciente beneficiario, particular, convenio, urgencia vital, NN. | | | | 0 | | 4 | Triage. Categorización de urgencia, según criterios predefinidos. Clave de colores para identificación. | | | | 0 | | 5 | Discriminación de urgencia pediátrica , de adultos, gineco obstetricia, dental | | | | 0 | | 6 | Discriminación de accidente común, laboral, escolar, violencia callejera, violencia intrafamiliar. Presentación del formulario correspondiente, el que se direccionará automáticamente a quien corresponda. | | | | 0 | | 7 | Tiempo de espera de pacientes. El tiempo se contabiliza desde el ingreso del paciente en Admisión. | | | | 0 | | 8 | Visualización de los tiempos de espera, en el listado de trabajo (worklist) con señalización mediante indicador de colores tipo semáforo u otro del tiempo transcurrido, según criterios predefinidos. Ejemplo Verde: espera normal, Amarillo: espera prolongada, Rojo: espera excesiva. | | | | 0 | | 9 | Mapeo/Censo de camas, Boxes y camillas, con indicación NIVEL DE Triage, y de la fase del proceso en que se encuentra el paciente (Ej. En espera de ser atendido, en observación, en hidratación, en espera de exámenes, en espera de traslado. Integración con Admisión, laboratorio clínico, Imagenología. | | | | 0 | | 10 | | | | | 0 | | 11 | Registro de accidentes de transito, laboral, escolar, evento Médico legal. Despliegue de formularios y notificaciones especificas para cada caso. | | | | 0 | | 12 | Alcoholemia. Debe llevarse un registro correlativo de alcoholemias. Las muestras de sangre para alcoholemia, en Chile son procedas en el Instituto Médico Legal y no en el laboratorio del Hospital. Ajustarse a normas vigentes. Llenado automático de formularios destinados al "SERVICIO MÉDICO LEGAL", de acuerdo con SUS normas. | | | | 0 | | 13 | Mordedura de perros y otros animales. Debe generarse los formularios correspondientes, y notificarse de acuerdo a normas vigentes. Despliegue de formulario de notificación. | | | | 0 | | 14 | Vinculación con cuenta del paciente | | | | 0 | | 15 | Vinculación con módulo clínico. | | | | 0 | | 16 | Vinculación con Módulo de Enfermería | | | | 0 | | 17 | Vinculación con módulo de recetario, solicitudes, formularios y certificados (Ej. Solicitudes de exámenes, traslado y solicitud de pabellones quirúrgicos). Integración con Admisión, Farmacia, RIS, LIS, Pabellones Quirúrgicos (perfil de usuario). | | | | 0 | | 18 | Generación de reportes de gestión | | | | 0 | | 19 | Ej. Informes de producción, tiempos de espera, índice ocupacional, tiempos de permanencia y destino de los pacientes al alta desde urgencia. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | | Puntaje máximo posible | 38 | | Puntaje mínimo exigido | 27 | | Máximo ítem "No Cumple ni será desarrollado" | 1 | | Ponderación del módulo | 3 | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

GESTIÓN DE ATENCIÓN DE CAMAS CRÍTICAS

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Capacidad de conectividad con equipos clínicos de monitoreo, EKG, EEG y bombas de infusión. Dependiendo de la tecnología de los equipos, debería poder capturarse las imágenes estáticas o dinámicas de estos equipos en demanda, o en forma automática al ocurrir una alarma. | | | | 0 | | 2 | Funcionalidades especiales del módulo de enfermería. Dado que el registro de datos y actividades es más frecuente que en pacientes comunes, debe poder ajustarse las matrices de signos vitales y actividades para capturar información en periodos de tiempo variables (Ej. Cada 10, 15, 30 minutos). | | | | 0 | | 3 | El Módulo clínico, requiere adecuaciones en la interfase de usuario, a fin de destacar resultados de laboratorio, balance hídrico y signos vitales. | | | | 0 | | 4 | Disponer forma para visualizar los registros de monitoreo que se encuentren ingresados a la FCE. | | | | 0 | | 5 | Generación de reportes. Vinculación con el módulo de generación de reportes. | | | | 0 | | 6 | Visualización gráfica de las camas criticas, con la identificación del paciente, que permita ingresar a la FCE al seleccionar la cama pertinente en el gráfico. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | | Puntaje máximo posible | 12 | Puntaje mínimo exigido | 8 | Máximo ítem "No Cumple ni será desarrollado" | 0 | Ponderación del módulo | 3 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

GESTIÓN DE PABELLONES QUIRÚRGICOS (QUIRÓFANOS)

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Destinación de quirófanos o pabellones para determinados tipos de cirugía, en consideración del equipamiento de que disponen. | | | | 0 | | 2 | Gestión de solicitudes de Quirófano. Integración con FCE (Módulo de solicitudes). | | | | 0 | | 3 | Gestión de solicitudes de pabellón en lista de espera. | | | | 0 | | 4 | Validación de paquetes predefinidos de exámenes preoperatorios y de la evaluación pre anestésica. Integración con módulo Clínico. | | | | 0 | | 5 | Validación del Consentimiento Informado | | | | 0 | | 6 | Agendamiento de Quirófanos. Generar alerta en el Módulo de enfermería en que se encuentra el paciente, con indicaciones pre operatorias. | | | | 0 | | 7 | Generar registro del agendamiento de pabellón en el módulo Clínico. | | | | 0 | | 8 | Capacidad para reprogramar quirófanos en casos de presentarse casos de urgencias. | | | | 0 | | 9 | Publicación de Tabla Quirúrgica. En página WEB de la Intranet. En pantallas gigantes en pabellón. | | | | 0 | | 10 | Registro de suspensión de cirugía, hora, responsable de la decisión y causa. | | | | 0 | | 11 | Censo de quirófanos, indicando su status (Ej. disponible, ocupado, en desinfección, bloqueado, en mantención). Display Grafico que se vea en la tabla quirúrgica. | | | | 0 | | 12 | Requerimiento de equipos adicionales que deban incorporarse al quirófano para determinada cirugía programada. | | | | 0 | | 13 | Este equipo adicional programado, debe aparecer publicado en la tabla quirúrgica. | | | | 0 | | 14 | Solicitud de cajas quirúrgicas. Integración con esterilización. Solicitud de instrumental estéril se activa al validar el agendamiento. | | | | 0 | | 15 | Solicitud de paquetes de ropa estéril (no desechable). Integración con esterilización. Solicitud se activa al validar el agendamiento. | | | | 0 | | 16 | Gestión de fármacos e insumos desechables. Integración con Farmacia y Bodega de insumos, para reposición de stocks. | | | | 0 | | 17 | Integración con cuenta corriente del paciente para incorporar los cargos de derechos de pabellón, honorarios profesionales, medicamentos e insumos | | | | 0 | | 18 | Registro del equipo de médicos y del personal de apoyo (cirujano, anestesiólogo, ayudantes, etc.) | | | | 0 | | 19 | Formulario de Hoja de Anestesia. Tipo de anestesia (selección múltiple). | | | | 0 | | 20 | Formulario de Hoja de Anestesia. Anotación de signos vitales, tiempo anestésico, tiempo quirúrgico, medicamentos aplicados, sueros, transfusiones, etc. Despliegue gráfico. | | | | 0 | | 21 | Formulario de Hoja de Anestesia. Idealmente uso de pantallas táctiles para el anestesiólogo | | | | 0 | | 22 | Capacidad para solicitar exámenes, hemoderivados, biopsia rápida, desde hoja de anestesia | | | | 0 | | 23 | Capacidad para envío de biopsias o piezas operatorias a Anatomía Patológica. Impresión de etiquetas con código de barras (en la modalidad requerida). | | | | 0 | | 24 | Registro de tiempos quirúrgicos tales como llegada del paciente, inicio de anestesia, inicio de cirugía, termino de cirugía, termino de anestesia, salida del paciente. La hora de llegada y salida del paciente a pabellón, se vincula con Módulo ADT para cambios de estado y trazabilidad del paciente. | | | | 0 | | 25 | Registro de hora de inicio y termino del aseo. Registro de situaciones especiales detectadas | | | | 0 | | 26 | Capacidad para capturar datos desde equipos de monitoreo. | | | | 0 | | 27 | Registro de fármacos, insumos, hemoderivados, prótesis, órtesis consumidos. Vinculación con cuenta de paciente. Si el paciente esta adscrito a una cirugía paquetizada PAD, el material en exceso se registra sin precio y éste se carga a otra cuenta que se definirá. | | | | 0 | | 28 | Visualización de la FCE. | | | | 0 | | 29 | Dictado de protocolos quirúrgicos utilizando archivos digitales de audio (WAV u otro). Aparecerá el protocolo quirúrgico en la FCE cuando se encuentre trascrito y validado por el cirujano. En caso contrario aparecerá como “PENDIENTE”. | | | | 0 | | 30 | En el protocolo debe registrarse las prestaciones efectuadas para fines de cobro. Estas prestaciones se seleccionarán desde el archivo de prestaciones. Deben poder agregarse tantas prestaciones como resulte necesario. | | | | 0 | | 31 | Funcionalidad para la trascripción de archivos digitales de audio (WAV.). La transcripcionista debe enviar su trabajo a revisión por parte del cirujano. | | | | 0 | | 32 | Validación de trascripción de protocolos quirúrgicos. El cirujano revisa y valida el texto, el que es firmado en forma digital. | | | | 0 | | 33 | Las indicaciones y terapias post quirúrgicas se anotaran en la FCE. Si el paciente es enviado a sala de recuperación, estas indicaciones quedaran registradas en la lista de trabajo de la estación de enfermería de recuperación. Si es enviado a sala de camas criticas o la habitación del paciente, se procederá de igual manera. | | | | 0 | | 34 | Clasificación de las cirugías según su potencial contaminante. Opciones predefinidas parametrizables. | | | | 0 | | 35 | Registro y notificación de cirugías sépticas o potencialmente sépticas. Mensaje al Comité de Infecciones intra hospitalarias. Envío de e mail automático en caso de no existir módulo especifico integrado. (Vinculación al Módulo de IIH). | | | | 0 | | 36 | Gestión de biopsias, muestras biológicas, y exámenes de laboratorio. Integración con módulo de solicitudes. Vinculación con Anatomía patológica y laboratorio clínico. | | | | 0 | | 37 | Capacidad de Etiquetado de muestras. | | | | 0 | | 38 | El ingreso y la salida del paciente de pabellón, se reflejará en el sistema ADT, el que debe indicar la nueva ubicación del paciente. Trazabilidad del paciente | | | | 0 | | 39 | Registro de nacimientos y emisión de certificados de parto. Vinculación con Admisión y módulo de formularios. | | | | 0 | | 40 | El registro de nacimiento único o múltiple, genera automáticamente un registro en el archivo maestro de pacientes, con una identidad transitoria asociada a la identidad de la madre. Esta acción debe generar la Ficha Clínica del Recién nacido. Integración con Archivo Maestro de Pacientes. Cuando el recién nacido tenga identidad propia, debe ingresarse al maestro de pacientes, acción que reemplazara la identidad transitoria en TODOS los documentos y registros que se haya generado. | | | | 0 | | 41 | Emisión de certificado de defunción. | | | | 0 | | 42 | Emisión de los reportes predefinidos de gestión. Vinculación con módulo de Generación de Reportes de Gestión. | | | | 0 | | 43 | Lista de chequeo que asegure que el quirófano se encuentra en condiciones de ingresar el paciente programado, por encontrarse presentes todos los elementos y condiciones necesarias (Ej. instrumental, ropa, insumos previstos). Check list completo cambia de estado el quirófano de "en aseo", "en preparación" a "habilitado" en la tabla quirúrgica. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | 86 | Puntaje mínimo exigido | 60 | Máximo ítem "No Cumple ni será desarrollado" | 2 | Ponderación del módulo | 7 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

ESTERILIZACIÓN

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Inventario de instrumental. Uso de códigos EAN-128 y Data Matrix, aplicable al instrumental que este marcado. | | | | 0 | | 2 | Generación de cajas quirúrgicas a partir del inventario. Uso de códigos EAN-128 y Data Matrix. | | | | 0 | | 3 | Inventario de ropa. Integración con ropería o lavandería, si es posible. Probablemente se trate como bodega del ERP. | | | | 0 | | 4 | Generación de paquetes de ropa a partir del inventario. | | | | 0 | | 5 | Etiquetado de paquetes y cajas, con indicación de fecha y lote de esterilización. Generación e impresión de etiquetas con código de barras. | | | | 0 | | 6 | Capacidad para lectura de código de barras grabados en instrumental quirúrgico. | | | | 0 | | 7 | Incluir listado de clientes internos y externos Ej. Pabellón Nº 1, Otro establecimiento de salud, Sala Pensionado 2. Selección automática de destino a partir de la solicitud de material. | | | | 0 | | 8 | Gestión de solicitudes de cajas, paquetes y material estéril. Integración con módulo de Pabellones y enfermería. | | | | 0 | | 9 | Gestión manual de solicitudes esporádicas de material estéril de servicios no habituales. Ej. Imagenología, Endoscopia, otros. | | | | 0 | | 10 | Gestión de bodega de material estéril, con sus fechas de vigencia. Alertas en las fechas de vencimiento. | | | | 0 | | 11 | Gestión del proceso de esterilización, con monitoreo de cargas y validadores (OK) | | | | 0 | | 12 | Despacho de material estéril. Vinculación de fecha de esterilización y carga de esterilización, con usuario (paciente). Movimiento de inventario. | | | | 0 | | 13 | Trazabilidad de instrumental estéril. Se debe poder seguir un material estéril, desde su esterilización (registro del paciente usuario) hasta su regreso a esterilización o fecha de caducidad si no ha sido utilizado. | | | | 0 | | 14 | Trazabilidad del material estéril. Se debe poder seguir un material estéril, desde su esterilización hasta el usuario final (paciente) o fecha de caducidad | | | | 0 | | 15 | Capacidad para identificar el destino o uso que se dio a un determinado lote de esterilización. Ej.: Situación de IIH. | | | | 0 | | 16 | Recepción de material sucio. Movimiento de inventario. | | | | 0 | | 17 | Generación de reportes. Vinculación con Módulo de reportes. | | | | 0 | | 18 | Listado de material estéril por vencer. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | | Puntaje máximo posible | 36 | Puntaje mínimo exigido | 25 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 4 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

FARMACOLOGÍA

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Capacidad para ingresar productos magistrales generados a partir de otros productos en existencia. El producto magistral debe estar registrado en el catálogo y en el Módulo de arancel. | | | | 0 | | 2 | Posibilidad de vincular uso de medicamentos con patologías AUGE u otras según protocolos. | | | | 0 | | 3 | Información farmacológica, dosis máximas, dosis útil, interacciones con otros fármacos, sustitutos y riesgos de reacción alérgica. Integración con el módulo clínico. | | | | 0 | | 4 | Activación de alertas predefinidas. | | | | 0 | | 5 | Al momento de ser prescrito un producto en el recetario, el sistema debe ofrecer la dosis sugerida, vía de aplicación y frecuencia de uso (horario de administración), información que podrá ser modificado por el médico). Debe discriminar dosificación en caso de paciente adulto, pediátrico y neonato. | | | | 0 | | 6 | Alertas de alergias. Vinculación con Módulo clínico y de enfermería. | | | | 0 | | 7 | Alertas de contraindicación o interacción con otros fármacos en uso actual o pasado por parte del paciente. | | | | 0 | | 8 | Mantenedor de información farmacológica. | | | | 0 | | 9 | Vinculación con admisión para habilitación de cuenta de paciente para cargos y notas de crédito. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | 18 | Puntaje mínimo exigido | 13 | Máximo ítem "No Cumple ni será desarrollado" | 0 | Ponderación del módulo | 3 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

SERVICIOS DE APOYO CLÍNICO (SERVICIOS INTERMEDIOS)

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Este módulo debe gestionar el Flujo de Trabajo de cada uno de los servicios de apoyo clínico que generan PROCEDIMIENTOS DIAGNÓSTICOS o TERAPÉUTICOS, y permitir el dictado de informes y captura de las imágenes que generan los equipos (Ej. Endoscopía, Microscopía, campimetría) y permitir su visualización por parte de los médicos clínicos. La unidad clínica que realiza servicios de apoyo clínico puede ser parte de un servicio clínico mayor. En este caso debe poder diferenciarse la función de apoyo que utilizará este módulo, del servicio clínico madre, el que utilizará la FCE normal. | | | | 0 | | 2 | Debe permitir que se incorpore documentos escaneados (solicitud u orden de trabajo generados en forma manual fuera de la FCE) que queden vinculados con la actividad a realizar. Debe poderse ver esta orden al momento de realizar el procedimiento y al generar el informe. Ej. Endoscopia Digestiva puede ser parte de gastroenterología. Ambas se diferenciarán como unidad de negocio y asociarán en el plan de cuentes del ERP, para efectos de consolidación. | | | | 0 | | 3 | Recepción de solicitudes electrónicas desde la FCE y capacidad para asignar cupos en la agenda especifica del Servicio de Apoyo | | | | 0 | | 4 | Generar listas de trabajo para cada servicio o unidad, vinculadas con el módulo de agendamiento. | | | | 0 | | 5 | El paciente ya citado, se presenta en recepción para ser atendido. Se le ubica y marca en la agenda, cambiando el estado a "paciente llegado". | | | | 0 | | 6 | La condición de paciente llegado, gatilla el paso del nombre del paciente a la Lista de Trabajo de la secretaria o enfermería del sector correspondiente y la aparición en la Lista de Trabajo del profesional que lo atenderá. Se inicia un contador de "tiempo en espera de ser atendido". También se indicara el tiempo de espera desde la hora de citación, por lo que el tiempo puede ser positivo o negativo. (Ej. Paciente llega mucho antes que la hora de citación). | | | | 0 | | 7 | Al seleccionar un paciente, éste debe ser identificado en forma biométrica, para habilitar la apertura de la FCE | | | | 0 | | 8 | Al abrir la FCE del paciente el estado pasa de espera, al de "atención". El cierre de la FCE indica el término de la atención. Los cambios de estado y de paciente se reflejan en el Mapa grafico de Boxes (Salas de procedimiento Diagnostico o Terapéutico). | | | | 0 | | 9 | A cada cambio de estado, el sistema debe capturar la hora del sistema. Hay acciones del proceso que gatillarán los cambios de estado para trazabilidad de la solicitud. Parametrizar los estados posibles en este tipo de atención. | | | | 0 | | 10 | Los cambios de estado deben ser visibles en las listas de trabajo del profesional, secretaría y/o enfermería, para trazabilidad. | | | | 0 | | 11 | Capturar y archivar imágenes, integrando los equipos clínicos pertinentes. Dependiendo de la configuración y arquitectura, estas imágenes podrán estar en formato JPEG u otras. | | | | 0 | | 12 | Capacidad para dictar y transcribir y validar o revisar informes, utilizando archivos digitales en formato WAV o similar. Debe utilizar micrófono con puerta USB para el dictado. Pedalera USB y audífonos para secretaria transcripcionista. | | | | 0 | | 13 | Al informar debe permitir el uso de esquemas predefinidos modificables por el usuario (Ej. Esquemas normales). | | | | 0 | | 14 | El profesional deberá podrá revisar y validar una transcripción realizada, la que una vez validada, quedará disponible para ser integrada y vista en la Ficha Clínica y/o ser impresa. | | | | 0 | | 15 | Firma digital para los informes. | | | | 0 | | 16 | Capacidad para generar formatos de informe (lay out) específicos para cada servicio de apoyo. | | | | 0 | | 17 | Las imágenes capturadas deben quedar vinculadas con el informe correspondiente. | | | | 0 | | 18 | La imágenes y los informes deben poderse visualizar desde la Ficha Clínica. Incluir visualizador de imágenes en concordancia con los formatos de imágenes utilizados. | | | | 0 | | 19 | Generación de informes estadísticos y de gestión por cada servicio de apoyo. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | 38 | Puntaje mínimo exigido | 37 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 3 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

MÓDULO DE POLICLÍNICO Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | El paciente ya citado, se presenta en recepción para ser atendido. Se le ubica en la agenda y se cambia de estado a "paciente llegado". | | | | 0 | | 2 | Esta acción gatilla el paso a la Lista de Trabajo de la secretaria o enfermería del sector correspondiente y la aparición en la lista de trabajo del profesional. Se inicia un contador de tiempo de espera para ser atendido. También se indicara el tiempo de espera desde la hora de citación, por lo que el tempo puede ser positivo o negativo. | | | | 0 | | 3 | Al seleccionar un paciente, éste debe ser identificado en forma biométrica, para habilitar la apertura de la FCE | | | | 0 | | 4 | Al abrir la FCE del paciente el estado pasa de espera al de atención. El cierre de la FCE indica el término de la atención. Los cambios de estado y de paciente se reflejan en el Mapa grafico de Boxes (Sala de consulta médica). | | | | 0 | | 5 | A cada cambio de estado, el sistema debe capturar la hora del sistema. | | | | 0 | | 6 | El profesional utiliza el Módulo Clínico de la FCE, con interfaz de usuario adecuado a su especialidad. Acceso a recetario, solicitud de exámenes, indicación nutricional, etc. | | | | 0 | | 7 | El profesional tendrá acceso a SU agenda futura, a fin de citar a su paciente a control. Eventualmente utilizará cupos reservados para este efecto. | | | | 0 | | 8 | El profesional deberá indicar en un campo, si para el siguiente control requiere o no requiere de la presencia de la Ficha de papel. Si es paciente nuevo, esta discriminación no aplica. | | | | 0 | | 9 | Las recetas y solicitud de exámenes que el paciente NO quiera realizarse en el Hospital, podrán ser impresas en el mesón de secretaria, enfermería del sector y/o terminales de autoservicio. (KIOSCOS). Identificación biométrica para habilitar impresiones. | | | | 0 | | 10 | Las indicaciones nutricionales (dieta recomendada) se podrán imprimir en los KIOSCOS, con sugerencias de menú. KIOSCOS= PC touch screen para información del paciente. Funcionan con RUT e identificación biométrica. | | | | 0 | | 11 | Los KIOSCOS podrán generar justificativos en que indique fecha y hora de llegada y hora de término de su atención | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | | 22 | Puntaje mínimo exigido | | 15 | Máximo ítem "No Cumple ni será desarrollado" | | 0 | Ponderación del módulo | | 1 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

ANATOMÍA PATOLÓGICA

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Gestión del Flujo de trabajo dentro del servicio, a través de las diferentes secciones, incluyendo dictado de informes. | | | | 0 | | 2 | Catalogo de servicios y procesos de Anatomía Patológica. Incluye tinciones e inmuno histoquímica. | | | | 0 | | 3 | Capacidad para agrupar tinciones e inmuno histoquímica que debe aplicarse a determinados diagnósticos. | | | | 0 | | 4 | Registrar recepción de muestras de paciente con solicitudes generadas en la FCE. Asociar Nº de biopsia. | | | | 0 | | 5 | Registrar recepción de muestras de paciente externos. (Solicitudes no generadas en FCE). Escaneo de orden de examen en papel. | | | | 0 | | 6 | El registro de recepción de muestras incluye, un correlativo, órgano, cantidad de muestras, numero de inclusiones, numero de tinciones. Ubicación en bodega-archivo. | | | | 0 | | 7 | Numeración correlativa diferente para muestras, citología convencional y para Papanicolau. | | | | 0 | | 8 | Definición de tipos de muestras. Paramétrico. | | | | 0 | | 9 | Definición de tipos de estudios y procesos susceptible de ser realizados. Paramétrico. | | | | 0 | | 10 | Definición de proceso que debe aplicarse a la muestra, según tipo de muestra (Ej. Inmunofluorescencia, histoquímica, numero de cortes a practicar, Tinciones) | | | | 0 | | 11 | Identificar muestras, bloques y placas histológicas, asociadas al paciente. Imprimir etiquetas con código de barras. | | | | 0 | | 12 | Capacidad de asociar un paciente con la biopsia, muestra, bloques, placas e informe | | | | 0 | | 13 | Trazabilidad de la muestra a través de los diferentes procesos y sus etapas. (Definición de estados), desde la solicitud de la muestra hasta el informe terminado y entregado. Integración con Módulo clínico indicando etapa del proceso en que se encuentra la muestra. (Cambios de estado). | | | | 0 | | 14 | Cada cambio de estado debe capturar fecha, hora y persona responsable, Generar reporte de tiempos que la muestra esta en cada etapa del proceso. | | | | 0 | | 15 | Visualización de lista de trabajo en cada sección, donde se debe registrar el trabajo realizado e insumos utilizados. Interfaz de usuario configurable. | | | | 0 | | 16 | En los puntos del proceso en que hay informes, debe visualizarse la orden de biopsia, visualizar biopsias anteriores para comparación y poderse invocar la FCE (protocolo quirúrgico, etc.) | | | | 0 | | 17 | Dictado de informes a archivos digitales, transcripción por secretaría y revisión por el profesional antes de liberar resultado. Los informes e imágenes deben poder ser visualizadas desde el Módulo clínico. | | | | 0 | | 18 | Capacidad para acceder a la Ficha Clínica al momento de realizar en informe. | | | | 0 | | 19 | Uso de esquemas de informes predefinidos | | | | 0 | | 20 | En el momento del informe se pueden generar la solicitud de reprocesos adicionales de la muestra. El requerimiento marcado como reproceso debe aparecen en la pantalla de la sección pertinente en la Lista de Trabajo | | | | 0 | | 21 | Transcripción a formatos predefinidos | | | | 0 | | 22 | Posibilidad de realizar informes complementarios a los ya realizados para una muestra determinada | | | | 0 | | 23 | Capacidad para incorporar FOTOGRAFÍAS de piezas macroscópicas, Los informes e imágenes deben poder ser visualizadas desde el Módulo clínico. | | | | 0 | | 24 | Captura de imágenes desde MICROSCOPIOS en formato JPEG. Acopio de imágenes en repositorio JPEG. | | | | 0 | | 25 | Los informes e imágenes deben poder ser visualizadas desde la FCE | | | | 0 | | 26 | Registro de autopsias | | | | 0 | | 27 | Consentimiento de familiares para autopsias. Vinculación con formularios. | | | | 0 | | 28 | Nomenclatura CIE10 o la del Colegio Americano de Patología, según se decida en la reingeniería de procesos. | | | | 0 | | 29 | Capacidad para asociar cada muestra, bloque y placa con su lugar de almacenamiento físico, que permita su ubicación a posteriori. | | | | 0 | | 30 | Seguimiento de estudios citológicos sospechosos. Ej. Papanicolau. Listados y alertas para citación a plazos predefinidos. | | | | 0 | | 31 | Capacidad para generar reportes de gestión que se defina | | | | 0 | | 32 | Recepción electrónica de solicitudes de biopsia intra operatoria en pabellón | | | | 0 | | 33 | Debe poder realizar informe de biopsias intra operatorias en pabellón. Módulo de formularios. | | | | 0 | | 34 | Capacidad para registrar uso de insumos y consumibles | | | | 0 | | 35 | Informar cambios de estado a la ficha clínica para trazabilidad | | | | 0 | | 36 | El informe debe ser visualizado desde el Módulo clínico. Incluye acceso a imágenes que este disponibles, asociadas al informe | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | 72 | Puntaje mínimo exigido | 50 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 7 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

ODONTOLOGÍA (DENTAL)

Nro | Concepto | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Agenda | Catálogo de clínicas (Boxes) segmentadas por tipo y subespecialidad. | | | | 0 | | 2 | | Definición de especialidades o profesionales asignados a cada clínica. | | | | 0 | | 3 | | Definición de segmentos horarios por clínica, y tiempo por cupo. | | | | 0 | | 4 | | Funcionalidades similares a gestión de agenda, descrito en Agenda Medica. | | | | 0 | | 5 | | Solicitud automática de Ficha Dental a Archivo de Fichas Dentales, en primeras consultas de pacientes antiguos. (Nuevo evento clínico). Omitir requerimiento en caso de controles, cuando el profesional así lo indique. Ídem cuando se trata de Paciente Nuevo (sin ficha previa). | | | | 0 | | 6 | | Carga de listado de tratamientos o servicio posibles de ser realizados, con su correspondiente código. Vinculación con módulo de valorización de prestaciones. | | | | 0 | | 7 | | Habilitación del cupo si el paciente ha resuelto previamente su situación de pago. Uso de un campo lógico, vinculado con Tesorería o Caja. Esta opción no es aplicable a pacientes beneficiarios de Dipreca, portadores de CMC. | | | | 0 | | 8 | | Impresión de programa de citas dentales del paciente. | | | | 0 | | 9 | | Recuerdo automático de cita próxima por SMS. | | | | 0 | | 10 | | Categorización de cupos en campo lógico, que permita "reservar" cupos para ser asignado a pacientes en tratamiento que necesitan ser controlados en determinado plazo | | | | 0 | | 11 | Presupuesto | Listado de trabajo por clínica y por profesional | | | | 0 | | 12 | | Indicación en lista de trabajo de paciente "en sala de espera", con indicación del tiempo de espera. | | | | 0 | | 13 | | Al seleccionarse un paciente, este debe accionar la identificación biométrica para permitir la apertura de la Ficha. | | | | 0 | | 14 | | Apertura de Ficha Dental del paciente. El formato de la Ficha presentada (clínica o dental), depende del perfil de usuario. | | | | 0 | | 15 | | La apertura de la Ficha, cambia el estado de paciente en espera a "atención". El cierre de la Ficha cambia estado a "realizado". Cada cambio de estado captura la hora del sistema, para análisis de los tiempos de cada etapa. | | | | 0 | | 16 | | Los cambios de estado y de paciente se reflejan el Mapa de Clínicas. | | | | 0 | | 17 | | Registro de anamnesis (motivo de consulta). | | | | 0 | | 18 | | Examen físico, expresado sobre un Odontograma o Dentograma. | | | | 0 | | 19 | | Tabla de nomenclatura estandarizada de hallazgos de examen. (Diagnósticos odontológicos) (Ej. Pieza ausente, carie de x tipo o ubicación en la pieza, obturación de x tipo, otros). Representación grafica de los hallazgos en el Dentograma. Clave de colores o símbolos o combinación de ambos. | | | | 0 | | 20 | | Listado de lesiones encontradas y solución propuesta para cada pieza dental, en listado para valorización y documentación (medio de pago, cargo, otro). | | | | 0 | | 21 | Atención | Listado de lesiones presupuestadas y documentadas. Solo se podrá trabajar sobre las piezas indicadas y realizar el trabajo presupuestado. | | | | 0 | | 22 | | Apertura de un historial por pieza, con campos que indiquen trabajo realizado y estado de avance del tratamiento. Vinculación con código de prestaciones. Definición paramétrica de estado de avance de tratamiento por cada pieza. | | | | 0 | | 23 | | Campo "comentarios" anexo a cada pieza. | | | | 0 | | 24 | | Formulario de envío de moldes a laboratorio y solicitudes de trabajo, con espacio para insertar comentarios. Debe existir una lista de procedimientos o trabajos que realiza el laboratorio dental, con su correspondiente arancel. (módulo de aranceles) | | | | 0 | | 25 | | Administración del laboratorio dental utilizando el módulo de "servicios de apoyo" de la FCE, con las adecuaciones pertinentes | | | | 0 | | 26 | Estudio | Al igual que la Ficha Medica, tendrá acceso al módulo de solicitudes y formularios para solicitar exámenes e indicar terapia farmacológica o especifica de odontología. Trazabilidad de exámenes solicitados. | | | | 0 | | 27 | | Acceso a resultado de exámenes. Visualización de radiografías. Visualización de radiografías dentales y de Scanner (PACS). | | | | 0 | | 28 | Evolución | Durante el tratamiento se deberá ir llenando un segundo Dentograma diferente al de ingreso en el que se refleje el tratamiento efectuado y ya terminado. Este Dentograma tendrá fecha actualizada a la ultima atención, de modo que al alta se habrá completado el Dentograma de alta | | | | 0 | | 29 | | Actualización del estado de tratamiento para la pieza que esta siendo tratada | | | | 0 | | 30 | Cirugía | Solicitud de pabellón para cirugía máxilofacial. Vinculación con módulo de solicitudes y formularios. Vinculación con módulo de pabellón de FCE. | | | | 0 | | 31 | | Para cirugía máxilofacial se utilizará la FCE MEDICA con la adecuación que corresponda en la interfaz de usuario. | | | | 0 | | 32 | | Llenado automático de Epicrisis al alta, similar a FCE MEDICA. Generación de resumen e indicaciones de alta. | | | | 0 | | 33 | Mapa | Mapa grafico de clínicas dentales por tipo, con indicación de su estado de uso. Visible por personal de recepción y por cualquier profesional usuario. Ej.: en espera del Odontólogo, en espera del paciente, en tratamiento, turno terminado, en aseo, bloqueada, otros. | | | | 0 | | 34 | Reportes | Registro de insumos utilizados por cada profesional, a partir de consumo estándar por prestación realizada. | | | | 0 | | 35 | | Producción por profesional, tasa de ausentismo de pacientes, otros que se defina. | | | | 0 | | 36 | Firma | Firma electrónica en todas las acciones profesionales registradas. | | | | 0 | | 37 | Perfiles | Creación de roles, perfiles y privilegios que corresponda | | | | 0 | | 38 | Interfaz de usuario | Se generará interfases de usuario adecuadas para el desempeño de cada subespecialidad | | | | 0 | | 39 | | El profesional tendrá acceso a SU agenda futura, a fin de citar a su paciente a control. Eventualmente utilizará cupos reservados para este efecto. | | | | 0 | | 40 | | El profesional deberá indicar en un campo, si para el siguiente control requiere o no requiere de la presencia de la Ficha Dental de papel. Si es paciente nuevo, esta discriminación no aplica. | | | | 0 | | 41 | Rayos dental | Incluir formulario especial para solicitud de radiología dental. (servicio independiente de Imagenología) | | | | 0 | | 42 | | Generar una aplicación que permita soportar el flujo de trabajo de radiología Dental, de modo similar al módulo de servicios de apoyo, que permitan generar listas de trabajo, e informes con dictado digital y transcripción. Debe informar a la ficha los cambios de estado a fin de que el Profesional Odontólogo tenga trazabilidad del proceso. Podría utilizarse el módulo de servicios de apoyo. Radiología Dental es Digital Directo sólo para ORTHOPANTOMOGRAFÍA y algún porcentaje de radiografías localizadas. El resto en análoga. | | | | 0 | | 43 | | Visualización de imágenes de Radiología Dental (establecer link a URL). Formato de radiología Dental: JPEG. | | | | 0 | | 44 | | Visualización de imágenes de Scanner de Imagenología. Vinculación o invocación del PACS | | | | 0 | | 45 | Recetas y ordenes hacia el exterior | Las recetas y solicitud de exámenes que el paciente NO quiera realizarse en el Hospital podrán ser impresas en el mesón de secretaria. Identificación biométrica para habilitar impresiones. | | | | 0 | | 46 | | También el paciente podría auto imprimir en terminales de autoservicio habilitados (KIOSCOS). KIOSCOS= PC touch screen de autoservicio para información del paciente. Funcionan con RUT e identificación biométrica. | | | | 0 | | 47 | | Los KIOSCOS podrán generar justificativos en que indique fecha y hora de llegada y hora de término de su atención. | | | | 0 | | 48 | | Los KIOSCOS podrán generar un impreso con las fechas y horas de citación de controles. Eventualmente esta información podría estar disponible en Internet si tiene identificador biométrico. | | | | 0 | | 49 | Laboratorio Dental | Ingreso de solicitudes u ordenes de trabajo. Funcionalidad similar a las de Módulo de Servicios de Apoyo. | | | | 0 | | 50 | | Procesos asignados a mecánicos dentales. | | | | 0 | | 51 | | Entrega de trabajos | | | | 0 | | 52 | Archivo Ficha Dental | Gestión de Fichas dentales de papel | | | | 0 | | 53 | | Todo paciente nuevo requiere de verificar si existe ficha en papel | | | | 0 | | 54 | | El odontólogo indicará si para el siguiente control requiere o no de ficha en papel | | | | 0 | | 55 | | Las solicitudes de ficha en papel se hará de acuerdo a la planilla de citación de pacientes, por día, por hora, por clínica y por profesional | | | | 0 | |

TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | Puntaje máximo posible | 110 | Puntaje mínimo exigido | 77 | Máximo ítem "No Cumple ni será desarrollado" | | 2 | Ponderación del módulo | 8 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

MÓDULO DE IIH (INFECCIONES INTRA HOSPITALARIAS)

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Crear un pantalla de control que recoja datos relevantes que se defina en diferentes áreas, tales como: Cirugías sépticas efectuadas, cepas de bacteria aisladas en laboratorio de microbiología, alertas en detección de determinados hongos y cepas de bacterias, | | | | 0 | | 2 | Historias de manejo de vías. Detección de fechas de reemplazo no realizadas. Cultivo de muestras de vías. (Vías = todo dispositivo invasivo a permanencia). | | | | 0 | | 3 | Consumo de antibióticos, fuera de ciertos rangos, con indicación de los pacientes que lo utilizan y su ubicación si es hospitalizado | | | | 0 | | 4 | Detalle de consumo de determinados antibióticos | | | | 0 | | 5 | Alerta de enfermedades de notificación obligatoria | | | | 0 | | 6 | Alerta de enfermedades en vigilancia epidemiológica | | | | 0 | | 7 | Alerta de presencia de infecciones en pacientes operados en un mismo quirófano | | | | 0 | | 8 | Trazabilidad del lote de esterilización de cajas quirúrgicas utilizadas en pacientes que resultan con infecciones postoperatorias. | | | | 0 | | 9 | Ubicación de pacientes con aislamiento | | | | 0 | | 10 | Ubicación de pacientes infectados con la misma bacteria u hongo | | | | 0 | | 11 | Resultado de controles bacterianos ambientales de quirófanos y otras dependencias. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | 22 | Puntaje mínimo exigido | 15 | Máximo ítem "No Cumple ni será desarrollado" | 0 | Ponderación del módulo | 2 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

MÓDULO DE MANEJO DE FICHAS CLÍNICAS (DE PAPEL) Nº | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Vincular las FCE con las fichas de papel en cuanto a su identificación con código de barras y su ubicación. | | | | 0 | | 2 | Capacidad para generar nuevas fichas con su correspondiente código de barras o de colores a partir del numero de RUT | | | | 0 | | 3 | Archivo maestro de Historias Clínicas o documentación existente; y su ubicación física. | | | | 0 | | 4 | Clasificación de fichas por triple digito terminal | | | | 0 | | 5 | Identificación de fichas por código de colores | | | | 0 | | 6 | Capacidad de impresión de etiquetas con código de barras | | | | 0 | | 7 | Gestión de solicitudes de fichas, registro de solicitante y punto de destino. Gestión de solicitudes con fines de investigación. Vinculación con Agenda y Admisión (gestión de camas), Módulos de Urgencia, Enfermería. | | | | 0 | | 8 | Preparación de las fichas de papel uno o dos días previos a la citación | | | | 0 | | 9 | El sistema debe emitir listados por médico, box y servicio, indicando fecha y hora de atención y su ubicación física, a fin de que el personal pueda retirar las fichas de sus estantes de almacenamiento. Considerar el uso de dispositivos manuales que capturen el listado, ordenado por número correlativo, contra el cual el funcionario va marcando las fichas que encuentra. | | | | 0 | | 10 | Validación del cumplimiento de los listados, con lectura del código de barras de las fichas, previo a su despacho. | | | | 0 | | 11 | En los servicios clínicos debería accederse a una pantalla que permita registrar la recepción de dichas fichas y validar el listado de salida de archivo con el nombre y firma electrónica de quien las recibe. | | | | 0 | | 12 | El servicio clínico debe acceder a una pantalla de devolución utilizando el código de barras, el que generará un listado que debería ser firmado en forma electrónica por quien retira las fichas. Este listado es validado en recepción del archivo, a su ingreso. | | | | 0 | | 13 | Calificación de prioridades en los despachos | | | | 0 | | 14 | Capacidad para recibir solicitudes de fichas que se producen en el momento (paciente no agendado previamente, sino recepcionado en el mismo momento. | | | | 0 | | 15 | Registro de entrada y salida de fichas. Uso de código de barras. | | | | 0 | | 16 | Gestionar la devolución de fichas. El sistema debe mantener una lista de fichas prestadas, ordenadas por días transcurridos desde la fecha de salida | | | | 0 | | 17 | Trazabilidad de las fichas de papel que se encuentran circulando. (¿Donde esta?) | | | | 0 | | 18 | Detección de fichas perdidas o con devolución demorada. El sistema debe mantener una lista de fichas prestadas, ordenadas por días transcurridos desde la fecha de salida | | | | 0 | | 19 | Capacidad de búsqueda de fichas por diferentes criterios | | | | 0 | | 20 | Registro de movimiento histórico de las fichas | | | | 0 | | 21 | Informe de fichas que han salido y no regresan. Verificar si esta hospitalizado. | | | | 0 | | 22 | Almacenamiento de otros documentos tales como los consentimientos informados originales, con firma autógrafa del paciente, ordenados por folio correlativo del formulario, asociado al número de RUT del paciente. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | 44 | Puntaje mínimo exigido | 31 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 4 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

KIOSCOS (INFORMACIÓN DE AUTOSERVICIO)

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Entrega información a paciente tras identificación con RUT y biometría | | | | 0 | | 2 | Información de su citación actual, con indicación de su lugar de atención. Mostrará plano de cómo llegar al lugar y eventualmente una explicación escrita | | | | 0 | | 3 | Informará de citaciones futuras ya comprometidas | | | | 0 | | 4 | Entregará información de resultado de exámenes | | | | 0 | | 5 | Imprimirá certificados de justificación de ausencia laboral | | | | 0 | | 6 | Imprimirá recetas y solicitudes de exámenes que se encuentren pendientes | | | | 0 | | 7 | Si el paciente ambulatorio tiene indicación de dieta, ésta le será impresa con recomendaciones de nutrición | | | | 0 | | 8 | Mostrará información breve explicando ciertas enfermedades y su tratamiento. Puede incluir audio. Eventual capacidad para imprimir un resumen predefinido. | | | | 0 | | 9 | Opera con identificación biométrica y pantallas Touch Screen | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | 18 | Puntaje mínimo exigido | 13 | Máximo ítem "No Cumple ni será desarrollado" | 0 | Ponderación del módulo | 1 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

ARCHIVO MAESTRO DE PACIENTES (CLIENTES)

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | RUT. Con algoritmo de cálculo de digito verificador. | | | | 0 | | 2 | Apellidos (dos en campos separados). Apellido compuesto ocupa un campo, separado por espacio (Ej.: Del Río) | | | | 0 | | 3 | Nombres (dos en campos separados).Nombre compuesto ocupa un campo, separado por espacio (Ej.: María_ Luisa ) | | | | 0 | | 4 | Fecha nacimiento. | | | | 0 | | 5 | Calculo automático de edad por diferencia con fecha de la atención | | | | 0 | | 6 | Discriminar a partir de la edad si se trata de paciente adulto, niño (pediatría) o lactante (neonatología) | | | | 0 | | 7 | Vincular edad del paciente con calculo de dosis sugerida en módulo de farmacología | | | | | | 8 | Lugar de nacimiento: ciudad o localidad. Región (parametrizable) | | | | 0 | | 9 | Nacionalidad. Ofrecer "Chileno", por defecto. | | | | 0 | | 10 | Sexo. Opciones parametrizadas. | | | | 0 | | 11 | Estado civil. Opciones parametrizadas. | | | | 0 | | 12 | Domicilio: calle, número, departamento, comuna, ciudad, Región. (En campos separados). Posibilidad de ofrecer una ciudad predeterminada por defecto. (Ej. Santiago) | | | | 0 | | 13 | Teléfonos del domicilio, celular. Campos separados | | | | 0 | | 14 | Familiar o persona para contacto: nombre, parentesco o relación, domicilio completo, teléfonos. En campos separados | | | | 0 | | 15 | Lugar de trabajo (nombre, dirección, teléfono). En campos separados. Este dato debe poder ser actualizado por el operador de admisión y/o agenda. | | | | 0 | | 16 | Condiciones especiales del paciente Ej. Minusválido, sordo. Opciones parametrizadas. | | | | 0 | | 17 | Condición previsional del paciente, asegurador de salud, convenio al que esta adscrito. Opciones parametrizadas. | | | | 0 | | 18 | Registro de Nº CMC (Carnet de Medicina Curativa). Este número indica la repartición y el plan de salud de la persona, por lo que debe asociarse a la selección del arancel a cobrar. (proporción del arancel que es bonificado por el Dipreca, por el seguro complementario, y copago de cargo del paciente) | | | | 0 | | 19 | Una persona puede tener más de un CMC y sólo uno de ellos estará activo. El /los CMC asignados permanecen siempre asociados a la persona | | | | 0 | | 20 | Capacidad para anotar un nuevo domicilio y teléfonos del paciente, sin perder la información histórica. Ídem respecto de su lugar de trabajo. | | | | 0 | | 21 | Tarifas especiales a las que el paciente/cliente está afecto. Vinculación con aranceles. | | | | 0 | | 22 | Capacidad para generar un RUT ficticio único e irrepetible para pacientes inconcientes o que ingresen a urgencia en condición extrema. Este RUT ficticio quedará permanentemente vinculado con la identidad real del paciente, cuando esta situación sea definida. | | | | 0 | | 23 | Al momento de conocerse la identidad del paciente al que se le asignó un RUT ficticio, el sistema debe corregir la identidad en toda la documentación, incluyendo la identificación en la FCE, en los exámenes, recetas y procedimientos que le hayan sido indicados y realizado, conservando de todos modos y adicionalmente el RUT ficticio como REFERENCIA. | | | | 0 | | 24 | Para pacientes con grado militar, consignar grado militar unidad a la que pertenece, repartición. En campos separados, con opciones parametrizables. | | | | 0 | | 25 | Para pacientes con grado militar, Condición de activo, pensionado, montepiado. Opciones parametrizables. | | | | 0 | | 26 | Para pacientes que son cargas autorizadas de pacientes afiliados a Dipreca, registrar relación de parentesco con el titular. Opciones parametrizables. | | | | 0 | | 27 | Para pacientes beneficiarios de Dipreca, registrar si esta afiliado al seguro complementario SECOSA. Considerar esta situación para valorización de prestaciones en módulo de aranceles. (Tiene o no tiene seguro complementario). | | | | 0 | | 28 | Vinculación con el número de Ficha Clínica de papel. Integración con módulo de administración de fichas clínicas de papel. | | | | 0 | | 29 | Creación automática de un registro provisorio de recién nacido asociado a identidad de la madre, a fin de crear una FCE. Cuando el recién nacido tenga identidad propia, se reemplazará esta información en todos los documentos creados con la identidad transitoria. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | Puntaje máximo posible | 58 | Puntaje mínimo exigido | 41 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 3 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

AGENDA Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Creación y definición de Boxes de atención. | | | | 0 | | 2 | Asignación de Boxes por especialidades. | | | | 0 | | 3 | Asignación de Boxes a determinados profesionales. | | | | 0 | | 4 | Definición de bloques horarios de atención especialidad/profesional/box. | | | | 0 | | 5 | Estructurar un Mantenedor de agenda | | | | 0 | | 6 | Definición de cupos. Tiempo asignado por atención de paciente nuevo o en control. Tiempo parametrizable por tipo de cupo (Mantenedor). | | | | 0 | | 7 | Los cupos deben tener un campo que permita categorizar este cupo según su destino. Ej. Paciente nuevo, paciente en control, cupo para ser asignado por el medico tratante desde la FCE al momento de la consulta, derivación de servicio de urgencia, derivación de provincia, paciente minusválido, anciano. La asignación de algunos destinos de cupos debe estar ligada a privilegios. | | | | 0 | | 8 | Capacidad de generar sobre cupos cuando la agenda se encuentra completa, dependiendo del perfil de usuario. | | | | 0 | | 9 | Capacidad de bloqueo de cupos o de bloques horarios, con indicación parametrizada de las razones. Ej. Profesional de vacaciones, asistente a algún evento especial. | | | | 0 | | 10 | Capacidad de redistribuir cupos asignados en casos de inasistencia del profesional (reasignación de cupos). | | | | 0 | | 11 | Capacidad de visualizar si existe ficha clínica en papel para el paciente que se cita. Vinculación con módulo de gestión de Ficha Clínicas de papel. | | | | 0 | | 12 | Por defecto, en “primeras consultas” por evento nuevo se solicitará la ficha de papel. | | | | 0 | | 13 | Para controles, verificará si el medico solicitó o no la ficha para el este control. | | | | 0 | | 14 | Capacidad para solicitar automáticamente la Ficha clínica de papel (si corresponde). El medico debe marcar si para el siguiente control requiere o no la ficha antigua en papel. | | | | 0 | | 15 | Capacidad del sistema de proponer el cupo más próxima disponible para el medico o la especialidad según se trate. | | | | 0 | | 16 | Asignación de cupo a un paciente. Previamente se debe validar que el paciente ha realizado los tramites administrativos (pagos o validación de crédito por pertenencia a convenio). Vinculación con tesorería. Si el paciente es beneficiario de DIPRECA, debe cargarse automáticamente el importe de la prestación en la cuenta de paciente. | | | | 0 | | 17 | Registro de cupos asignados previamente, con paciente inasistente. Generación de alerta. | | | | 0 | | 18 | Capacidad para asignar cupos múltiples, evitando coincidencia de horas (en diferentes especialidades). | | | | 0 | | 19 | Alerta en caso de existir cupos asignados aun pendientes del mismo paciente. Evitar duplicación de citas. | | | | 0 | | 20 | El sistema debe registrar para cada asignación de cupos, cual es el agente, persona o terminal que registró la operación (Ej. Call Center, Operador Juan Pérez. Internet/Intranet, el paciente) | | | | 0 | | 21 | Capacidad de visualizar agenda y asignar cupos en otros centros u hospitales de la red de salud Institucional. Capacidad multicentro y multiempresa de la aplicación. | | | | 0 | | 22 | Alertas en caso de paciente minusválido. Parametrización de tipos de invalidez. | | | | 0 | | 23 | Habilitación automática de acceso a la Ficha Clínica Electrónica en el día de la cita, para el medico tratante y personal de apoyo. Vinculación con módulo de seguridad del sistema. | | | | 0 | | 24 | Generación de una lista de espera por especialidad o tipo de requerimiento. Deben poder ordenarse por diferentes criterios tales como: antigüedad en la lista, control/nuevo, nivel de urgencia o prioridad clínica ("tipo Triage"). Debe capturarse día y hora del ingreso a la lista de espera, a fin de medir el tiempo de espera | | | | 0 | | 25 | La prioridad de pacientes en lista de espera debe poder modificarse a fin de adecuarla a la evolución y circunstancia del paciente | | | | 0 | | 26 | Al asignarse un cupo a alguien que esta en lista de espera, debe incorporarse a la agenda sin tener que volver a digitar datos de paciente. | | | | 0 | | 27 | Categorización de listas de espera por condición clínica y antigüedad en la lista. | | | | 0 | | 28 | Priorización de citas para pacientes AUGE, según protocolo. | | | | 0 | | 29 | Priorización de pacientes de edad avanzada, que viven fuera de santiago y minusválidos | | | | 0 | | 30 | Capacidad para que el médico tratante pueda asignar en el momento de la consulta, un cupo para controlar a su paciente. Evita hacer trámite de solicitud de hora. Solo debe validar que en pacientes no beneficiarios de Dipreca, se ha realizado los tramites administrativos (pagos o validación de crédito por pertenencia a convenio) | | | | 0 | | 31 | El médico podrá ver su agenda para días futuros. | | | | 0 | | 32 | Búsqueda rápida de cupos asignados a un paciente determinado | | | | 0 | | 33 | Capacidad para medir tiempos de espera de los pacientes (desde hora asignada/ hasta ser llamados). Reporte por especialidad y por profesional. | | | | 0 | | 34 | Capacidad para medir atrasos de pacientes. Hora asignada/hora de llegada | | | | 0 | | 35 | Capacidad para medir atrasos y horas trabajadas en exceso por el profesional. Primera hora programada/primer paciente llamado. Ultima hora programada/hora del ultimo paciente atendido. | | | | 0 | | 36 | Capacidad de generar reportes de gestión predefinidos. Ejemplo: cupos máximos posibles, cupos programados, cupos programados no utilizados (ausencia del paciente o del profesional). | | | | 0 | | 37 | Reporte de cantidad y Causas de bloqueo de cupos, por especialidad. | | | | 0 | | 38 | Reporte de cantidad de pacientes nuevos y en control por médicos, por especialidad. | | | | 0 | | 39 | Reporte de tiempos promedio de atención por medico, por especialidad para pacientes nuevos y en control. | | | | 0 | | 40 | Capacidad para realizar reportes en forma grafica Ej. Cantidad de pacientes llegados vs. Hora del día, para identificar horarios punta. Oferta de cupos por hora del día, etc. | | | | 0 | | 41 | Capacidad de generación de reportes nuevos, por parte del administrador del sistema. | | | | 0 | | 42 | Capacidad de generación mensajes SMS a una hora determinada y días antes a la cita (parametrizable cuantos días antes), para confirmar o recordar a los pacientes su cita. Debe capturar en forma automática los datos de la cita. El número de celular lo tomará del Archivo Maestro de Pacientes. Si no tiene móvil, registrado enviará listado con números de teléfono al Call Center para recordación manual. | | | | 0 | | 43 | Los cupos de cita tendrán un campo para marcar si se le ha confirmado o recordado la cita al paciente. | | | | 0 | | 44 | Si la confirmación de cita es manual, vía telefonista, deberá haber un campo para registrar si el paciente asistirá o anula su hora. | | | | 0 | | 45 | Debe indicar causas de anulación. Debe registrarse nombre de persona que fue contactada. Debe registrar día, hora y operador que llamó. Debe capturar en forma automática los datos de la cita. El número de celular lo tomará del Archivo Maestro de Pacientes. Si no tiene móvil, registrado enviará listado con números de teléfono al Call Center para recordación manual. | | | | 0 | | 46 | Debe permitir que el médico agende un control desde la Ficha del paciente que está atendiendo | | | | 0 | | 47 | Reporte de disponibilidad de cupo más próximo por especialidad o servicio requerido. Reportes de listas de espera por especialidad y servicio requerido | | | | 0 | | 48 | Capacidad para imprimir la citación, agregando información estandarizada a definir. Capacidad para imprimir el cargo efectuado en la cuenta de paciente. | | | | 0 | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | |

Puntaje máximo posible | 96 | Puntaje mínimo exigido | 67 | Máximo ítem "No Cumple ni será desarrollado" | 2 | Ponderación del módulo | 7 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

GESTIÓN DE CAMAS

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Definición de tipos de cama (según complejidad) y su ubicación en el hospital. Ej. Cama normal, observación, recuperación, UCI, UTI, Urgencia, camillas de examen de urgencia. | | | | 0 | | 2 | Tipo de habitación en que se encuentra la cama. Habitación de una cama, dos camas, diálisis, quimioterapia, UCI, UTI, Recuperación, | | | | 0 | | 3 | Vinculación de camas por servicios clínicos determinados y por estaciones de enfermería. Ej. Camas de medicina, cirugía, neurología/neurocirugía, oncología, urgencia, otras especialidades. | | | | 0 | | 4 | Disponibilidad de las camas. Ej.: ocupada, disponible, en aseo, en mantención, bloqueada, ocupada con posible alta en las próximas 24/48 horas. | | | | 0 | | 5 | Debe tener vinculación con módulo de aseo y mantención o con enfermería. | | | | 0 | | 6 | Censo diario de camas. Vinculación con módulo de enfermería. | | | | 0 | | 7 | Gestión de solicitud de cama. Módulo de formularios: solicitud de camas desde la FCE. | | | | 0 | | 8 | Gestión de lista de espera de camas | | | | 0 | | 9 | Asignación de cama a un paciente. Vinculación con archivo maestro de pacientes. | | | | 0 | | 10 | Vinculación con cuenta del paciente | | | | 0 | | 11 | Vinculación con oficina comercial ERP (validación de derechos o crédito si corresponde) | | | | 0 | | 12 | Vinculación con Módulo de enfermería. | | | | 0 | | 13 | Alerta en estación de enfermería pertinente, en caso de ingreso de paciente. | | | | 0 | | 14 | Generación de una lista de espera de camas por tipo o servicio clínico | | | | 0 | | 15 | Generación de una lista de espera por especialidad o tipo de requerimiento. Deben poder ordenarse por diferentes criterios tales como: antigüedad en la lista, control/nuevo, nivel de urgencia o prioridad clínica ("tipo Triage"). Debe capturarse día y hora del ingreso a la lista de espera, a fin de medir el tiempo de espera. | | | | 0 | | 16 | La prioridad debe poder modificarse a fin de adecuarla a la evolución y circunstancia del paciente | | | | 0 | | 17 | Al asignarse una cama a alguien que esta en lista de espera, debe incorporarse sin tener que volver a digitar datos de paciente | | | | 0 | | 18 | Categorización de listas de espera por condición clínica y antigüedad en la lista. | | | | 0 | | 19 | Gestión de nacimientos. Generación de identificación, asignación de cuna, asignación de cuenta corriente independiente de la madre en caso de hospitalización del recién nacido. Considerar situación de partos múltiples. | | | | 0 | | 20 | Gestión de traslados. Vinculación con módulo de enfermería de sectores o salas involucradas en los traslados. | | | | 0 | | 21 | Modificación de cuenta del paciente, en caso de traslados. | | | | 0 | | 22 | Re direccionamiento en recetas, exámenes y procedimientos pendientes (actualización de ubicación), en casos de traslados. | | | | 0 | | 23 | Gestión de altas/fallecimientos. Vinculación con módulo de enfermería. | | | | 0 | | 24 | Cierre de cuenta de paciente, en caso de fallecimiento. | | | | 0 | | 25 | Anulación de recetas, exámenes y procedimientos pendientes, en caso de fallecimiento. | | | | 0 | | 26 | Visualización de existencia previa de Ficha Clínica en Papel. Vinculación con módulo de gestión de fichas Clínicas en papel. | | | | 0 | | 27 | Solicitud automática de Ficha Clínica Tradicional al ingreso de un paciente a hospitalización. (Cuando corresponda). Vinculación con módulo de gestión de fichas Clínicas en papel. | | | | 0 | | 28 | Reportes de gestión de camas. Ej. Índices de ocupación, tiempo medio de estada, índice de rotación, índice de camas operables en total y por servicio clínico. Ingresos/egresos diarios y mensuales. | | | | 0 | | 29 | Reportes de listas de espera por tipo de cama y especialidad requerida | | | | 0 | | 30 | Mapa gráfico de camas, con indicación del ocupante, estado de salud y autorización de recibir visitas. Utilizar colores para diferentes condiciones (en uso, disponible, el aseo, en reparación, bloqueada, alta próxima.). Uso de formas diferentes para distinguir tipo de camas. Adultos, pediatría, neonatología, maternidad, critica, recuperación. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | 60 | Puntaje mínimo exigido | 42 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 5 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

MÓDULO de GESTIÓN DE CENTROS DE SALUD FAMILIAR Y DE PROGRAMAS DE SALUD Nro | Concepto | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Atención Primaria y salud familiar | Debe discriminar Atención Primaria de Atención de Salud Familiar (CESFAM) | | | | 0 | | 2 | Salud Familiar | Debe permitir registro de historia familiar y genética, vinculada con esquema gráfico de árbol de relación parental. | | | | 0 | | 3 | | La vinculación parental debe poder ser visualizada desde la FCE de cada uno de los integrantes de la familia que se ha definido. | | | | 0 | | 4 | | Si se realiza una sesión o actividad (evento o acción) que involucre a la familia, el registro de la actividad será copiada en la FCE de cada integrante del grupo familiar asistente. | | | | 0 | | 5 | | Las sesiones o actividades grupales de la familia podrán ser calificadas de confidenciales, y requerir un perfil definido para su visualización. | | | | 0 | | 6 | Programas de Salud | Capacidad de definir y gestionar programas de salud y de medicina preventiva, en diferentes temas Ej.: detección precoz de diabetes, hipertensión arterial, obesidad, cáncer mamario, otros canceres, programas de vacunación, etc. | | | | 0 | | 7 | | Debe poder vincular al paciente (y su FCE) con el respectivo programa o programas de salud al que se adscribe. | | | | 0 | | 8 | | Capacidad para controlar y hacer seguimiento de programas específicos de salud y de medicina preventiva, de alcance nacional (MINSAL) y/o Institucional de Carabineros. | | | | 0 | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | | |

Puntaje máximo posible | 16 | Puntaje mínimo exigido | 11 | Máximo ítem "No Cumple ni será desarrollado" | 0 | Ponderación del módulo | 3 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

CUENTA DE PACIENTES

N° | Funcionalidades | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Capturar desde el Archivo Maestro de Paciente los datos demográficos. | | | | 0 | | 2 | Capturar desde archivo maestro de pacientes la condición previsional del paciente y el arancel (tabla de precios) a aplicar. | | | | 0 | | 3 | Referencia a documentos en garantía, mediante vinculación con módulo de Tesorería. | | | | 0 | | 4 | Habilitación automática de cuenta de paciente por evento. Requiere integración con módulo de Gestión de Camas (hospitalización) y módulo de Servicio de Urgencia. Verificación previa de existencia de garantía en Tesorería. Los beneficiarios de DIPRECA portadores de CMC, tienen garantía constituida por defecto. | | | | 0 | | 5 | Registro de cargos a partir de información proveniente de módulos que generan transacciones en la FCE y ERP. Ejemplos: servicios de apoyo, pabellones, farmacia, insumos médicos. | | | | 0 | | 6 | El registro de cargos debe incluir los siguientes datos: 1) Fecha, servicio de origen, terminal o punto de red de origen. 2) Funcionario que genera la transacción. 3) Numero del documento que origina la transacción (Numero de la receta, solicitud de examen o procedimiento, intervención quirúrgica, otros). 4) Código de la prestación, fármaco o insumo. 5) Arancel aplicado, valorización (precio). | | | | | | 7 | Realizar registro diario y automático de cargos por día/cama (la hora que gatilla el cobro se configura según la regla de negocios que se especifique). Vinculación con hospitalización (Admisión o Gestión de Camas). Vinculación con Aranceles. | | | | 0 | | 8 | Registro de cargo por concepto de Visita a Paciente Hospitalizado: 1) cada vez que un médico escriba un ingreso de paciente a hospitalización y la valide con su firma electrónica 2) registre una evolución en la FCE y la valide con su firma electrónica. Debe registrar el nombre del médico, fecha y hora de la visita, identificación del terminal utilizado. | | | | 0 | | 9 | Registro de abonos, que debe incluir al menos: 1) fecha 2) tipo de abono. 3) Referencia al documento de ingreso a Tesorería (folio del ingreso) | | | | 0 | | 10 | Mantención automática del saldo de la cuenta corriente. Este saldo debe ser capturable por contabilidad al cierre de mes para acreditar ingresos devengados. | | | | 0 | | 11 | Emisión impresa de listado foliada de cargos (prefactura) en el formato que se defina, separados por tipo de cargo (familia de prestaciones), con subtotales y total. Indicación de monto de copago si corresponde. Indicación del funcionario y terminal o punto de red que lo emite. | | | | 0 | | 12 | Registro de ventas por prestaciones ambulatorias, con anotación de los mismos detalles requeridos en caso de ingreso en cuenta de paciente. Para pacientes NO DIPRECA registrar el folio y fecha de ingreso en tesorería ya sea en pago de la prestación o valores en garantía. En los pacientes beneficiarios de DIPRECA, el cargo en cuenta de paciente no requiere de ingreso ni comprobante de tesorería, ya que se trata de una venta a crédito. | | | | 0 | | 13 | Alerta al ingresarse nuevos eventos en Agenda Médica, hospitalización y Servicio de Urgencia respecto del estado de deuda del paciente. | | | | 0 | | 14 | Registro de cargos y abonos anulados (razón de anulación, identificación del funcionario y terminal). Debe registrarse como asiento de reversa. | | | | 0 | | 15 | Registro y anulación automática de ordenes, recetas y solicitudes pendientes al momento de concretarse el alta del paciente. | | | | 0 | | 16 | Cierre de la cuenta corriente al concretarse el alta del paciente. (definición de cuantas horas posteriores al alta) | | | | 0 | | 17 | Las prestaciones realizadas por profesionales además del registro en la cuenta de paciente, deben registrarse y acreditarse en la cuenta del médico y del servicio clínico o unidad de negocio a la que éste pertenece (proveedor interno). Integración con ERP. | | | | | | 18 | Permitir cargos de prestaciones realizadas en otros establecimientos por derivación transitoria durante la hospitalización. Vinculación con Emisión de Cartas de Resguardo por parte de Tesorería. | | | | 0 | | 19 | Permitir cargos por Procesamiento de Muestra Realizadas en Entidades externas, de acuerdo al Arancel Convenido | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | |

Puntaje máximo posible | 38 | Puntaje mínimo exigido | 27 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 5 |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

ARANCELES

Nro | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Debe contener un listado codificado para cada una de las prestaciones, productos, fármacos e insumos que el Hospital ofrece. En prestaciones clínicas debe utilizar codificación FONASA, propias y su equivalencia en codificación CIE 9 MC. | | | | 0 | | 2 | Este listado debe estar segmentado por familias de productos. | | | | 0 | | 3 | Debe proveer las funciones de mantención de estos listados. (agregar, modificar prestaciones) | | | | 0 | | 4 | Permitir la creación de múltiples tablas de valores (aranceles o precios de venta) para las prestaciones y productos disponibles, a fin de poder aplicar diferentes aranceles según la previsión del paciente y convenios que se defina. | | | | 0 | | 5 | Debe permitir que para las prestaciones otorgadas a beneficiarios de Dipreca se pueda calcular el monto bonificado, cobertura de seguro y copago, de acuerdo a las diferentes coberturas que otorga el asegurador DIPRECA, según los derechos del asegurado, los que se distinguen por el código de CMC, que esta asociado al RUT en el archivo maestro de clientes. | | | | 0 | | 6 | Los valores deben poder ser ingresados en forma libre, o generados automáticamente aplicando una constante configurable sobre un valor base. (Ej. 10% sobre valor FONASA nivel 1.) | | | | 0 | | 7 | A cada listado de valores correspondiente a una modalidad de venta o convenio debe tener una fecha y hora de vigencia, es decir fecha desde la cual el arancel es aplicable, y fecha y hora de termino, lo que implica que dicho valor deja de aplicarse a contar de la fecha de término. Esto debería permitir valorizar prestaciones ocurridas en cualquier fecha pasada, con el valor vigente a dicha fecha. (Situaciones de recalculo de cuenta en virtud de acreditarse una determinada condición. Ej.: Lesión en acto de servicio) | | | | 0 | | 8 | Los listados de valores deben permanecer disponibles, aun cuando hayan dejado de estar vigentes. | | | | 0 | | 9 | Para los efectos de las hospitalizaciones transitorias (Ej. Cirugía ambulatoria, diálisis, quimioterapia), debe ser posible calcular fracciones del arancel base de un día cama (Ej. Horas cama). Parametrizable. | | | | 0 | | 10 | Debe proveer estos valores vinculados con la condición previsional, convenio o modalidad de atención que corresponda al paciente que estará registrada en el archivo maestro de pacientes. . (Ej. Paciente acogido a la modalidad AUGE) | | | | 0 | | 11 | Debe estar vinculado con el módulo de hospitalización a fin de cargar en la cuenta del paciente los días de permanencia según el tipo de habitación que tenga asignada cada día. | | | | 0 | | 12 | Debe estar vinculado con el Módulo de gestión de servicio de Urgencia | | | | 0 | | 13 | Debe permitir la creación de paquetes de prestaciones, con contenidos configurables, registrados bajo un código de prestación creado para el efecto. Las prestaciones contenidas en el paquete deben conservar su codificación nativa. | | | | 0 | | 14 | Debe permitir la confección detallada de presupuestos de atención o de programas médicos. Estos presupuestos deben ser guardados debidamente foliados y vinculados con el paciente. Debe poder ser impreso en formato pre establecido. | | | | 0 | | 15 | Debe permitir imprimir y grabar en CD en formato Excel, el o los aranceles pactados correspondientes a un determinado asegurador o financiador. | | | | 0 | | 16 | Debe permitir generar recargos parametrizables sobre un determinado arancel, vinculados con la hora o día hábil o inhábil en que se otorga una prestación. Definición parametrizable de horario hábil/inhábil. | | | | 0 | | 17 | Valorizaciones diferenciadas para una misma prestación, servicio, medicamento o insumo, dependiendo de la calidad de ambulatorio, hospitalizado o atención de urgencia. Recargo por horario inhábil. | | | | 0 | | | | | | | | | | TOTAL PUNTOS OBTENIDOS | 0 | 0 | | 0 | | | | | | | | | | PONDERACIÓN PROPORCIONAL DEL MÓDULO | | | | Puntaje máximo posible | 34 | Puntaje mínimo exigido | 24 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación del módulo | 5 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

CARACTERÍSTICAS FUNCIONALES DE LOS MÓDULOS OPCIONALES. Los dos siguientes módulos tienen el carácter de Oferta Opcional, por lo que no es obligatoria. Si se presenta debe atenerse a los criterios de evaluación expresados al pié de las tablas de que siguen, siendo obligatorio el cumplimiento de los puntajes de mínimos para calificar. Al módulo de LABORATORIO le corresponderá un ponderador de 60 y al módulo de BANCO DE SANGRE un ponderador de 40. Si ofrece sólo uno de los módulos, se evaluará sólo este módulo, asignándole CERO puntos de ponderación al segundo módulo. Cada módulo se evalúa por separado y los ponderadores calculados se sumarán, correspondiente al oferente con sumatoria máxima en este rubro, el máximo puntaje asignado en la TABLA DE EVALUACIÓN GENERAL, y a los demás se les asignará el puntaje proporcional decreciente que corresponda.

BANCO DE SANGRE Nº | Concepto | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Ingreso de donantes | Vinculación con archivo maestro de pacientes (MPI) | | | | 0 | | 2 | | Registro de donantes esporádicos y habituales | | | | 0 | | 3 | | Historial de donantes | | | | 0 | | 4 | | Sistema que permita recordar a donantes habituales que están en plazo de poder volver a donar | | | | 0 | | 5 | Recolección de sangre | Generación de etiquetas parea bolsa de sangre y frascos para muestras para exámenes de laboratorio | | | | 0 | | 6 | | Asociación de la bolsa y de las muestras con el donante | | | | 0 | | 7 | | Asociación del resultado de los exámenes de muestras y clasificación, con el historial del donante | | | | 0 | | 8 | | Alertas en resultados de exámenes que inhabiliten el uso del material donado. | | | | 0 | | 9 | | Alerta de donante inhabilitado por ser portador de….. | | | | 0 | | 10 | | Registro de notificación donante que es portador de ……, que lo inhabilita para ser donante | | | | 0 | | 11 | Generación de hemoderivados | Generación de etiquetas para identificación de bolsas de hemoderivados. Asociación de hemoderivados con la bolsa madre. Registro de fecha de elaboración y caducidad | | | | 0 | | 12 | Mantención | registro de stock por tipo de sangre y de hemoderivados ordenados por fecha de elaboración y fecha de caducidad | | | | 0 | | 13 | | Alertas de fecha de caducidad de material en stock, con "n" días de anticipación. | | | | 0 | | 14 | | Registro de desecho de sangre y hemoderivados con indicación de causal | | | | 0 | | 15 | Utilización | Recepción de solicitudes electrónicas de sangre y/o hemoderivados. Habilitación de algún tipo de alarma acústica de recepción de solicitudes de aplicación inmediata. | | | | 0 | | 16 | | Realización y registro de resultado de pruebas cruzadas de compatibilidad | | | | 0 | | 17 | | Instalación de la transfusión requerida, por personal del Banco. Debe asociar código de barras de la identificación del paciente, con la bolsa y finalmente con la identificación del funcionario que realiza la acción. Esta acción deja un registro en la hoja de enfermería, con indicación de la hora. | | | | 0 | | 18 | | La acción anterior debe generar en la hoja de enfermería un campo para registrar reacciones adversas, de acuerdo con una tabla de opciones predefinidas. Este registro debe transferirse al historial del banco de sangre para la bolsa utilizada. En caso de reacciones adversas, debe generar una alerta o alarma en el banco de sangre, a fin de que tomen acciones. Debe registrarse la hora de término de la administración en la hoja de enfermería de modo similar a la aplicación de un suero. | | | | 0 | | 19 | | El receptor del hemoderivado debe quedar vinculado en el historial del donante | | | | 0 | | 20 | Transferencias | Debe registrarse las transferencias que ocurran desde otros BANCOS COMERCIALES. Este registro debe incorporar la totalidad de la información del donante y las pruebas de laboratorio realizadas | | | | 0 | | 21 | | Debe registrarse las transferencias que ocurran hacia otros bancos. Debe adjuntarse las pruebas de laboratorio y datos del donante | | | | 0 | | 22 | Cargos en cuenta de paciente | Al registrarse la administración de un hemoderivado a un paciente, se produce automáticamente el cargo en la cuenta del paciente y el movimiento de stock del banco. | | | | 0 | | 23 | | Este Módulo debe permitir la completa trazabilidad de la muestra desde su origen hasta su utilización y/o eliminación | | | | 0 | | 24 | Administración | Reportes predefinidos de producción y productividad | | | | 0 | | 25 | | Reportes diarios de stock | | | | 0 | | 26 | | Alertas de fecha de vencimiento de productos | | | | 0 | | 27 | | Solicitud de insumos | | | | 0 | | 28 | | Alimentación de indicadores de calidad | | | | 0 | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | | Puntaje máximo posible | 56 | Puntaje mínimo exigido | 39 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación | 40 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

LABORATORIO CLÍNICO

Nº | Concepto | Funcionalidad | Cumple | Será desarrollado | No cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | | Debe dar soporte al flujo de trabajo de cada una de las secciones del laboratorio | | | | 0 | | 2 | Toma de muestras | De acuerdo con los exámenes solicitados por el Médico, el sistema debe indicar el tipo de frasco y volumen de sangre a colectar. Asimismo debe generar una etiqueta con código de barras adecuado para ser leído por la maquina que procesará la muestra | | | | 0 | | 3 | | El código de barras debe indicar el examen requerido y la identificación del paciente y el lugar de la toma de muestra | | | | 0 | | 4 | | La captura de identidad del paciente se logra capturando el código de barra de la identificación del paciente. Con el mismo procedimiento se identifica la persona que tomó la muestra. Esta acción debe cambiar el estado de la solicitud de examen parea los efectos de trazabilidad y marcar como efectuada la acción de enfermería anotada en la lista de trabajo. Esta acción deja un registro en la hoja de enfermería, con indicación de la hora. | | | | 0 | | 5 | Recepción de muestras | Al recibirse la muestra en el laboratorio, se lee su código de barras, se asocia con la solicitud de examen, se cambia de estado en la trazabilidad de la solicitud en la FCE y se carga la lista de trabajo de las maquinas pertinentes o de la persona encargada del proceso. | | | | 0 | | 6 | | Al procesarse la muestra el equipo e laboratorio debe leer nuevamente el código de barras del frasco. Si la acción es manual, el operador debe efectuar este registro | | | | 0 | | 7 | Resultados | Debe existir integración entre el LIS y los diferentes equipos de laboratorio que entregan resultados en formato digital, a fin que estos datos sean guardados en el LIS | | | | 0 | | 8 | | Al estar listo el resultado, estos deben ser previamente revisados por el profesional responsable de realizar esta función. | | | | 0 | | 9 | | Efectuado el control de calidad el resultado es liberado para conocimiento del Médico tratante en la FCE. Se cambia de estado en el sistema de trazabilidad de la FCE. | | | | 0 | | 10 | | Los resultados fuera del rango normal, deben poder destacarse gráficamente en forma evidente. Debe poder gatillarse un evento critico, en las situaciones que se parametrice, generándose las alarmas y comunicaciones tipo email y SMS, que se defina | | | | 0 | | 11 | | Los procedimientos de laboratorio cuyo resultado se genera en forma manual, deben tener un soporte de flujo y de proceso proporcionado por el LIS, a fin de que el operador disponga de una "lista de trabajo" y pueda incorporar los resultados obtenidos | | | | 0 | | 12 | Display | Si el paciente tiene otros exámenes del mismo tipo, el sistema debe permitir que se despliegue una serie comparativa. El Médico debe poder recibir cuantos resultados se deben comparar. Debe permitir seleccionar uno o más criterios para desplegar un gráfico. Ejemplo: curvas de glicemias seriadas, hematocrito, otros. | | | | 0 | | 13 | Cargo en cuenta del paciente | Los exámenes realizados deben cargarse automáticamente en la cuenta del paciente, al ingresarse la muestra al laboratorio. | | | | 0 | | 14 | Microbiología | El análisis de las cepas bacterianas y de la sensibilidad antibiótica debe alimentar un reporte para los efectos del trabajo de la unidad de IIH. | | | | 0 | | 15 | | La detección de virus, hongos y bacterias vinculadas con enfermedades de notificación obligatoria, debe reportarse automáticamente a la unidad encargada de esta labor, sin perjuicio de reportar también a la unidad de IIH. | | | | 0 | | 16 | | La detección de virus y bacterias vinculadas situaciones que requieran de aislamiento del paciente, será notificado automáticamente a la estación de enfermería de origen, en calidad de evento crítico. | | | | 0 | | 17 | Calibración de equipos automáticos | El sistema debe llevar un registro de los resultados de las muestras de calibración de cada equipo. Debe permitir registrar valores medidos en contra muestras medidas en laboratorios de control | | | | 0 | | 18 | Administración | Reportes de producción predefinidos. Ejemplo: Estadística de producción por sección | | | | 0 | | 19 | | Alimentación de indicadores de calidad | | | | 0 | | 20 | | Solicitud de insumos. Integración con bodega de insumos (ERP) | | | | 0 | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | | 0 | |

Puntaje máximo posible | 40 | Puntaje mínimo exigido | 28 | Máximo ítem "No Cumple ni será desarrollado" | 1 | Ponderación | 60 | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

CARACTERÍSTICAS FUNCIONALES DEL ERP Se solicita que para cada una de las filas de los diferentes módulos que aparecen a continuación, el oferente se autocalifique en el sentido de * Asignarse dos puntos si su aplicación cuenta con la funcionalidad * Asignarse un punto si compromete el desarrollo de la funcionalidad para este proyecto y * Cero puntos cuando el producto no cuenta con la funcionalidad y ésta no será desarrollada. Necesariamente debe llenar el campo “Trazabilidad” con información que permita encontrar fácilmente la referencia en el texto de la documentación de la oferta. Si la información resulta inexacta, se corregirá la evaluación a cero puntos.

CONTABILIDAD CONTABILIDAD | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Debe tener capacidad multiempresa, es decir, llevar contabilidades independientes de varias instituciones (empresas) | | | | 0 | | 2 | Debe tener capacidad Multicentro, es decir, cada contabilidad debe poder registrar múltiples Unidades de Negocio (UN), cada una de las cuales tendrá un Estado de Resultados operacional en línea e incluirá los gastos o costos distribuidos al cierre del período. Las UN podrán agruparse en departamentos. | | | | 0 | | 3 | Debe generar un output para contabilidad gubernamental (Formato SIGFE II /XML) para satisfacer requerimientos obligatorios, con los contenidos y formatos exigidos. | | | | 0 | | 4 | El Plan de Cuentas debe permitir que las cuentas madre puedan anidar 5 o más niveles jerárquicos y a su vez, estos niveles deben poder abrirse en subniveles, a fin de garantizar la granularidad de la información ( Según Plan de Cuentas establecido por el Sistema de Contabilidad Gubernamental y Ministerio de Hacienda) | | | | 0 | | 5 | Las cuentas contables deben poder definirse por el Departamento de Contabilidad y Finanzas (Disalcar) como Presupuestarias en la parametrización del sistema. Se requiere Integración con módulo de Presupuesto. | | | | 0 | | 6 | Las cuentas que se definan deben poder incluir lógica de negocios que permitan su distribución a las unidades de negocio, de acuerdo con los criterios que se establezca | | | | 0 | | 7 | La contabilidad se llevara en moneda nacional, aunque los auxiliares deben permitir el uso de otras monedas y de Unidades de Fomento, que se convertirán a pesos al centralizar, de acuerdo con tipos de cambio o valores que se ingresen en el periodo. | | | | 0 | | 8 | La imputación contable debe poder ser ejecutada a nivel de las Unidades de Negocio. La Imputación contable, debe afectar automáticamente a la ejecución presupuestaria. | | | | 0 | | 9 | La parametrización del sistema tributario debe adecuarse a la legislación y reglamentación tributaria vigente en Chile para el Sector Público | | | | 0 | | 10 | Debe permitir la generación de diferentes tipos de comprobantes contables, según se defina en la parametrización del sistema. | | | | 0 | | 11 | Asignar a las Cuentas de Gastos de Operación una lógica de distribución automática por Unidades de Negocio o Centros de Responsabilidad.
Ejemplo: Distribución del gasto de agua, combustible de calefacción, energía eléctrica por metro cuadrado asignado a cada unidad de negocios. Deducción previa de consumos de unidades que cuenten con remarcadores. | | | | 0 | | 12 | Debe estar integrado con los subsistemas de Remuneraciones, Presupuesto, Bienes y Activos y centralizar los asientos en forma automática, al cierre del periodo. | | | | 0 | | 13 | Centralización automática de auxiliares contables. Se requiere también capacidad de Importación desde Auxiliares Contables externos. | | | | 0 | | 14 | Debe permitir la creación de un registro de proveedores y clientes con sus correspondientes datos, contra el cual se ingresen los documentos de compra y de venta (sistema de control de documentos) | | | | 0 | | 15 | Debe permitir llevar cuentas T por Rut de clientes y de proveedores. | | | | 0 | | 16 | Debe generar los libros contables exigibles incorporando las formalidades legales y reglamentarias vigentes en Chile. | | | | 0 | | 17 | Emitir los balances, estados de resultado, estado de flujo efectivo, consolidados y desagregados en forma paramétrica. | | | | 0 | | 18 | Emisión de estado de resultados por unidad de negocio o Centro de Responsabilidad, en periodos no cerrados | | | | 0 | | 19 | Generar balances y estados de resultado con los formatos propios de la contabilidad gubernamental, y ejecución presupuestaria de Ingresos y Gastos. | | | | 0 | | 20 | Generar los set de datos que deben incorporarse al SIFGE II, mediante alguna solución viable de comunicación o de integración. | | | | 0 | | 21 | Emisión de listados de movimientos por Rut, saldos de cuenta, deudas vencidas, deudas por vencer, cobranzas vencidas, cobranzas por vencer y otras que puedan ser generadas por el usuario. Detalle de transacciones por tipo. A partir de Libro Clientes y libro Proveedores | | | | 0 | | 22 | Una vez cerrado un periodo contable, los registros deben ser inmodificables. Las modificaciones deben asentarse como una reversa contable hecha en el período en que es reconocida, en otras palabras asientos de regularización y ajustes. | | | | 0 | | 23 | El Plan de Cuentas debe ser definido por el usuario en código y glosas, en 5 ó más niveles jerárquicos de 1 a 3 dígitos por cada nivel, en base al Plan de Cuentas establecido por el Sistema de Contabilidad Gubernamental. | | | | 0 | | 24 | La contabilidad debe ser ejecutada en la moneda local y extranjera, al igual que sus libros auxiliares. La utilización de decimales es seleccionada por el usuario. | | | | 0 | | 25 | La imputación contable debe ser ejecutada a nivel de Unidad de Negocio o Centro de Responsabilidad y el nivel de imputación de las cuentas debe ser seleccionado por el usuario. | | | | 0 | | 26 | Se deben definir unidades independientes de registro, que en definitiva se transformarán en Movimientos Contable (Departamentos, Servicios, Unidades, etc.), que pueden imputar transacciones para cualquier Unidad de Negocio o Centro de Responsabilidad. | | | | 0 | | 27 | Cualquier cuenta del Plan de Cuentas debe poder definirse como presupuestaria, y el sistema deberá crear diferentes planos para el registro de la formulación y ejecución de presupuestos por cuenta. | | | | 0 | | 28 | El sistema debe poder acotar o limitar los registros contables por Centro de Responsabilidad y/o Departamentos, a uno o un conjunto definido de tipos de documentos. | | | | 0 | | 29 | El maestro (Catálogo) de impuestos debe poder ser definido por el usuario, teniendo la libertad de definir un código, su glosa, su porcentaje, su aplicación como retenido o agregado, su prioridad de aplicación en caso de impuestos múltiples y la forma en que ellos van representados en los libros legales | | | | 0 | | 30 | El usuario debe poder definir libremente los Tipos de Comprobantes que usarán la foliación legal, no sólo limitándose a aquellos de Ingreso-Egreso-Traspaso, sino que debe poder hacer una definición más precisa para la gestión y auditoría contable. | | | | 0 | | 31 | Se deben definir plantillas con estructuras de asientos fijos para su utilización rápida en transacciones repetitivas de igual característica. | | | | 0 | | 32 | El sistema debe permitir la deshabilitación de cuentas y también su segregación para permitir su utilización sólo a ciertos libros auxiliares. | | | | 0 | | 33 | Asignar a las Cuentas de Gastos de Operación una lógica de distribución automática por Centros de Responsabilidad. | | | | 0 | | 34 | Siendo los libros auxiliares multimoneda, en la contabilidad se deben definir todas las monedas que serán utilizadas en el ejercicio. Su código, nombre, su tasa de cambio respecto de la moneda local, el número de decimales con que se la representará y sus cuentas contables de ajuste y de corrección monetaria. | | | | 0 | | 35 | Permitir realizar un asiento de ajuste de asientos generados por algún auxiliar. | | | | 0 | | 36 | Permitir el ingreso, a través de una interfaz con campos definibles por el usuario, de asientos provenientes de sistemas externos de remuneraciones. | | | | 0 | | 37 | Permitir la carga masiva, a través de una interfaz de campos definibles, de registros contables provenientes de algún sistema o aplicación externa. | | | | 0 | | 38 | Emitir todos los balances y libros legales (diario, mayor, comprobación y saldos, de ocho columnas, compra y ventas, balance clasificado, estado de resultados, flujo de efectivo, entre otros) de uso general exigidos por organismos externos, más aquellos que indican la norma y técnica contable. | | | | 0 | | 39 | De un período cerrado no se puede modificar nada, excepto vía una reversa contable hecha en el período siguiente que esté abierto. | | | | 0 | | 40 | Incluir guía de apoyo explicativa del procedimiento de cierre de Períodos Contables. | | | | 0 | | 41 | Mantener tablas históricas de movimientos y saldos, emitir reportes y hacer consultas de períodos o lapsos de tiempo retroactivos según criterio del usuario. | | | | 0 | | 42 | Emitir libro de honorarios conforme al registro contable del libro diario. | | | | 0 | | 43 | Reporte de la siguiente información: | | | | 0 | | | • Detalle de facturas centralizadas en Contabilidad. | | | | | | | • Detalle de traspasos de Abastecimiento. | | | | | | | • Detalle de centralización de proveedores en Presupuestos. | | | | | | | • Detalle de facturas de bienes centralizadas en Contabilidad. | | | | | | | • Capacidad para configurar reportes adicionales. | | | | | | 44 | La conciliación bancaria debe contar con la opción de importar desde formato Excel la correspondiente cartola bancaria. | | | | 0 | | 45 | El registro contable del cliente, debe ser discriminado por el RUN, para personas naturales, y RUT para razones sociales. | | | | 0 | | 46 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 92 | | | | Puntaje Mínimo Exigido | | | 64 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 2 | | | | Ponderación del Módulo | | | 10 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

ADMINISTRACIÓN DE PRESUPUESTOS ADMINISTRACIÓN DE PRESUPUESTOS | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | El sistema de Presupuestos debe estar integrado a la Contabilidad, compartir las cuentas definidas como presupuestarias, e integrarse con los libros auxiliares financieros, de administración de bienes y de RRHH que generan transacciones que afectan al presupuesto de Ingresos y Gastos. | | | | 0 | | 2 | Permitir el ingreso de metas y objetivos del establecimiento de salud en Programas y Proyectos que comprometen y utilizan recursos asignados a ellos y que son registrados en las cuentas definidas como presupuestarias. | | | | 0 | | 3 | Permitir la creación de un árbol jerárquico de 5 ó más niveles para definir los Programas y Proyectos presupuestarios. | | | | 0 | | 4 | Permitir la definición de múltiples fuentes de Presupuesto, y que cada fuente pueda, a su vez, ser definida en diferente moneda y unidad de fomento | | | | 0 | | 5 | Para cada fuente de Presupuesto permitir la definición de Programas, Subprogramas, Actividades y Tareas que conforman los proyectos. | | | | 0 | | 6 | El sistema debe permitir el ingreso de proyectos, asignación de presupuesto, y relacionarlos con las cuentas que llevarán las imputaciones. Todo bajo un Centro de Responsabilidad. | | | | 0 | | 7 | El sistema de Presupuesto debe contar con un ciclo de aprobación y rectificación de proyectos. | | | | 0 | | 8 | Permitir modificar el presupuesto de un proyecto sólo a través del proceso de ajustes, registrando el cambio y solicitando la aprobación correspondiente sea esta interna o externa. | | | | 0 | | 9 | Asociar cada Proyecto con una o más cuentas presupuestarias. | | | | 0 | | 10 | Si el presupuesto está en ejecución, el sistema de Presupuesto debe controlar la ejecución por gastos, pre obligaciones, obligaciones o compromisos, devengos y pagos. | | | | 0 | | 11 | Permitir la formulación y ejecución de presupuestos multianuales. | | | | 0 | | 12 | Permitir múltiples consultas y reportes de formulación y de ejecución. | | | | 0 | | 13 | Permitir tener múltiples vistas, como por ejemplo, por actividad y por tipo de programas. | | | | 0 | | 14 | Permitir ingresar perfiles calificados, por ejemplo autorizar sobregiros de cuentas presupuestarias en forma temporal o con límite de montos. | | | | 0 | | 15 | Consultas de ejecución presupuestaria con filtros de jerarquía de proyecto. Por ejemplo: fuente, programa, subprograma, actividad o tareas, o cualquier nivel de la jerarquía de los Centros de Responsabilidad. | | | | 0 | | 16 | Toda transacción que se genere en el módulo de presupuesto, debe tener a lo menos dos niveles de autorización o estado: DIGITADO y APROBADO | | | | | | 17 | El presupuesto de gastos debe interactuar con el ingreso de diferentes Ordenes de Compra, las cuales cumplirán la función de rebajar y comprometer el presupuesto (Según normativa y procedimientos de DIPRES) | | | | 0 | | 18 | El flujo a través de Mercado Público es continuado una vez emitida en el Portal la correspondiente Orden de Compra, la cual es ingresada al sistema de abastecimiento, automáticamente deberá aparecer en el modulo de Presupuesto (en estado digitado) para ser aprobada y efectuar la ejecución presupuestaría al Sub Título, Ítem y Asignación respectivo. | | | | 0 | | 19 | Permitir el ingreso de las obligaciones, clasificando por grado de afectación presupuestaria. Lo cual corresponde a las instancias previas al devengamiento en la ejecución del presupuesto: Preafectación, Afectación; Compromiso Cierto y Compromiso Implícito. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 38 | | | | Puntaje Mínimo Exigido | | | 27 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 1 | | | | Ponderación del Módulo | | | 2 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

TESORERÍA TESORERÍA | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | | CONCEPTO: BANCOS COMERCIALES | | | | | | 1 | Permitir el ingreso de cuentas bancarias para el establecimiento de salud registrado, con el número de cuenta, cuenta contable de transacciones, moneda de operación de esa cuenta y los indicadores correlativos de folio de cheques al comienzo de la operación y sus saldos de apertura. | | | | 0 | | 2 | Permitir el ingreso de entidades financieras bancarias u otras con las cuales operará el sistema, indicando las sucursales y ejecutivo responsable. | | | | 0 | | 3 | Vinculación de cada cuenta corriente con correlativos de cheques en uso | | | | 0 | | 4 | Vinculación de la cuenta corriente con la cuenta contable y unidad de negocios correspondiente | | | | 0 | | 5 | Validación del acreedor y la deuda imputada en la emisión del cheque o transferencia.
Control de documentos, remuneraciones, otros | | | | 0 | | 6 | Capacidad para efectuar traspaso de fondos entre cuentas corrientes (en caso de existir más de una) | | | | 0 | | 7 | Confección de libro auxiliar de bancos | | | | 0 | | 8 | Cierre de periodos mensuales y anuales. Arrastre de saldo de apertura. | | | | 0 | | 9 | Emisión de Cartas de Resguardo vinculado con Cuenta de Paciente | | | | 0 | | | CONCEPTO: EGRESOS | | | | | | 10 | Definición de documentos y tipos de egresos.
Ej.: cheque, transferencia electrónica, efectivo, letra, pagare, cheque manual, otros medios de pago. | | | | 0 | | 11 | Permitir, desde el módulo de Tesorería, seleccionar la vía de pago de compromisos autorizados por el Administrador a través del módulo de Cuentas por Pagar (facturas, boletas y boletas de honorarios contabilizadas) | | | | 0 | | 12 | Definición de tipo o razón de pago. Ej.: factura, boleta, anticipo, fondo a rendir, caja chica, viático. | | | | 0 | | 13 | Permitir el ingreso por parámetros de diversos tipos de documentos. | | | | 0 | | 14 | Debe impedir la emisión de pagos si este no cuenta con autorización de la persona responsable
Debe haber una funcionalidad que permita la autorización de pagos en forma unitaria o masiva como en el caso de las remuneraciones) | | | | 0 | | 15 | Generación de egresos a proveedores a partir del registro de la cuenta del proveedor, vinculando una o mas facturas con el monto del cheque.
Vinculación con Cuentas por Pagar | | | | 0 | | 16 | Impedir la emisión de pagos por valores superiores al monto facturado | | | | 0 | | 17 | Permitir la generación de pagos parciales a proveedores | | | | 0 | | 18 | Permitir la generación de pagos de anticipos a proveedores | | | | 0 | | 19 | Permitir la selección de la cuenta bancaria para el pago, mostrando el saldo y el disponible a medida que se autorizan las emisiones de cheques. | | | | 0 | | 20 | Emisión de comprobantes contables de EGRESOS | | | | 0 | | 21 | Comprobación de la disponibilidad de saldos y presupuesto previo a la emisión de cheques | | | | 0 | | 22 | Permitir la transferencia electrónica de fondos y además la emisión de cheques manuales con captura en línea del número del cheque, cheques en formulario continuo (mecanizados) y manuales. Habilitar manualmente en el sistema, la emisión de cheques. | | | | 0 | | 23 | Emitir nómina de pago para su envío al banco y ser pagada (vía Transfer). Generación de Archivos con Detalles Correspondientes. | | | | 0 | | 24 | Centralización contable y presupuestaria de los egresos. Transacción a Transacción. | | | | 0 | | 25 | Parametrización de glosas de cobros y gastos bancarios, vinculándolos con la codificación propia de cada banco. | | | | 0 | | 26 | Capacidad de anular documentos de pago por errores en el momento de su confección (Ejemplo: descuadre en la impresión de cheques) | | | | 0 | | 27 | Capacidad de anular documentos de pagos que ya hayan sido contabilizados, generando los asientos de reversas en las cuentas contables y presupuestarias (anula asiento contable y ejecución presupuestaria) | | | | 0 | | 28 | Permitir dar por pagado facturas capturadas en línea o a través de archivo plano de forma individual o masiva. | | | | 0 | | 29 | Capacidad para registrar revalidación de cheques caducados. | | | | 0 | | 30 | Capacidad para generar Cajas Chicas y Fondos a rendir | | | | 0 | | 31 | Mostrar una vista con los movimientos de egreso del módulo Tesorería, por cuenta corriente, por cuenta contable, por períodos, por código del Centro de Costo, por proyecto presupuestario. | | | | 0 | | | CONCEPTO: INGRESOS | | | | | | 32 | Definición de documentos y tipos de ingresos.
Ej.: cheque, efectivo, letra, pagare, tarjeta de crédito y de débito, transferencia de fondos recibida. | | | | 0 | | 33 | Definición del concepto del ingreso.
Ejemplo: Garantía, prestaciones, venta activo, cobranzas | | | | 0 | | 34 | Emisión de comprobante de ingreso | | | | 0 | | 35 | Imputación del ingreso a la cuenta contable y presupuestaria correspondiente
Vinculación con cuentas por cobrar | | | | 0 | | 36 | Permitir el ingreso de documentos en garantía, vinculándolo con la transacción causante.
Ejemplo: Cuenta de pacientes y de proveedores. | | | | 0 | | 37 | Registro por el módulo de Tesorería de todos aquellos ingresos percibidos directamente a través de depósitos directos en el banco y otra forma de pago. | | | | 0 | | 38 | Emisión de detalles de depósitos | | | | 0 | | 39 | Permitir la selección de la cuenta bancaria para el pago, mostrando el saldo y el disponible | | | | 0 | | 40 | Permitir ingresar todos los parámetros con que el banco hace cargos o abonos en las cuentas corrientes, con el objeto de efectuar la conciliación bancaria en línea. | | | | 0 | | 41 | Capacidad de anular comprobantes de ingreso por errores en el momento de su confección (sin perder el correlativo único) | | | | 0 | | 42 | Capacidad de Anular un Ingreso y modificar movimientos de pago que ya hayan sido contabilizados y traspasados a los libros, generando todas las reversas contables, presupuestarias e inserción en los libros de banco y otros documentos legales impresos. (mientras el periodo contable no este cerrado) | | | | 0 | | 43 | Permitir el ingreso de cheques emitidos sin fecha
Ejemplo: cheque en garantía sin fecha. | | | | 0 | | 44 | Permitir el ingreso de cheques a fecha.
Ejemplo: Pago en cuotas con cheques a fecha (posfechados) guardados en cartera. | | | | 0 | | 45 | Relacionar los documentos en garantía con todas las referencias y características para su contabilización y control. | | | | 0 | | 46 | Permitir el ingreso de pagos parciales de cuentas por cobrar
Vinculación con cuenta de paciente y cuentas por cobrar. | | | | 0 | | 47 | Advertir de documentos en garantía por caducar | | | | 0 | | 48 | Advertir de cheques emitidos y no retirados, por caducar y caducados. | | | | 0 | | 49 | Permitir el calculo e imputación de intereses por mora | | | | 0 | | 50 | Permitir el ingreso por concepto de multas devengadas | | | | 0 | | | Conciliación bancaria | | | | | | 51 | Conciliación bancaria automática de cada una de las cuentas, a partir de planillas Excel y/o archivo plano, según sistema disponible en cada banco. | | | | 0 | | 52 | Realizar la conciliación bancaria por cuenta mostrando el detalle de los conceptos no conciliados para su análisis, ajustes y contabilización. | | | | 0 | | 53 | El libro de bancos debe ser manejado en línea por cuenta de banco, por cuenta contable, por moneda y entre períodos, con la opción de impresión | | | | 0 | | 54 | Permitir ingresar ajustes a las cuentas bancarias producto del proceso de conciliación bancaria. | | | | 0 | | 55 | Emitir nóminas para depósito de cheques y otros documentos. | | | | 0 | | 56 | Para aquellos ingresos percibidos a través del banco, debe generarse los comprobantes de ingreso correspondiente y mover las cuentas contables y presupuestarias correspondientes. | | | | 0 | | 57 | Emisión de informe de cheques cobrados, emitidos y no cobrados, cheque emitidos no cobrados y caducados. Indicación de saldo comprometido y disponible. | | | | 0 | | 58 | Emisión de informe de cheques depositados y devueltos (protestos) | | | | 0 | | 59 | Emisión de informe de cheques emitidos, no cobrados y caducados por fecha. | | | | 0 | | 60 | Permitir el cierre de período y apertura automática del período siguiente (el proceso de cierre y apertura debe ser uno sólo, partiendo desde el módulo de contabilidad) | | | | 0 | | | Reportes | | | | | | 61 | Disponibilidad de una herramienta configurada para emitir los informes rutinarios que se defina.
Ejemplo: informes diarios de disponibilidad de saldos de las cuentas de bancos. | | | | 0 | | | Cajas | | | | 0 | | 62 | Capacidad para generar cajas auxiliares | | | | 0 | | 63 | Capacidad para efectuar arqueo de cajas en cualquier momento. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 126 | | | | Puntaje Mínimo Exigido | | | 88 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 3 | | | | Ponderación del Módulo | | | 4 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

GESTIÓN DE COSTOS GESTIÓN DE COSTOS | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Permita establecer los costos de producción, de los diferentes productos y servicios. | | | | 0 | | 2 | Permitir la parametrización de costos según productos y servicios | | | | 0 | | 3 | Permitir definir metodología e implementar costeo variable | | | | 0 | | 4 | Permitir definir los costos estándar de las prestaciones de salud y sus respectivas unidades generadoras de productos. | | | | 0 | | 5 | Determinar la estructura de costos de las actividades y sus respectivas unidades que permita explicar el resultado de los centros no productivos. | | | | 0 | | 6 | Determinar la estructura de costos de las prestaciones de salud y sus respectivas unidades que derive en su estado de resultado.
Se debe identificar, centro de costo, tipo de profesional que ejecuta, el tiempo asociado a los procedimientos, debe tener implícito las remuneraciones. | | | | 0 | | 7 | Que permita identificar los costos de Producción de las diferentes prestaciones médicas, productos y servicios, por Método Absorbente integrado, es decir que incluya todos los costos de la función productiva independientemente de su comportamiento fijo o variable. (Materiales, Insumo, Mano de Obra y los Costos Indirectos) Ej. 1,- que los gastos generales sean prorrateados por servicio, que cada centro de costo considere su activo fijo y lo deprecie, además considere la mano de obra por hora y minuto. | | | | | | 8 | Que la mano de obra se separe por fondos fiscales y fondos propios, por tipos de contratos, por horas contratadas, por centro de costo, por tipo de profesionales, por asociación de procedimientos. | | | | | | 9 | Permitir la parametrización completa del proceso de producción por servicio | | | | | | 10 | Permitir identificar el rendimiento por Área o Servicio. | | | | | | 11 | Parametrización completa del proceso de venta de servicios | | | | | | 12 | Identificar los gastos asociados a los centros de costos, separados por consumo de los diferentes centros de responsabilidad, los cuales incluyen gastos generados por el paciente, respecto a la prestación otorgada y procedimientos asociados. | | | | | | 13 | Permitir ver el consumo del servicio el cual tenga una concordancia respecto a las prestaciones y procedimientos efectuados, con el propósito de llevar el control de los consumos y gastos de los servicios versus la producción y facturación. | | | | | | 14 | Que el sistema entregue los gastos generados por cuentas corrientes y detallados por centro de costo. | | | | | | 15 | Que genere un informe consolidado de los gastos y costos totales de las Unidades de Negocio o centros de costos. | | | | | | 16 | Que genere un informe que identifique la productividad versus horas contratadas por centro de costo, esto permitirá identificar el tiempo de ocio del servicio. | | | | | | 17 | Que el sistema aporte todos los informes necesarios que permitan confeccionar Tablas dinámicas para visualizar el Margen de Contribución, como varía el costo de acuerdo al nivel de producción en forma mensual. | | | | | | 18 | Emitir informe respecto de las unidades de medida de los Ingresos/Despachos de Bodega. (Ej.: Kg., Frasco, centímetro cúbico, Cm.) | | | | | | 19 | Informe de Honorarios médicos por centros de costo y por profesional en que se ejecutó el reemplazo del pago. | | | | | | | | | | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 38 | | | | Puntaje Mínimo Exigido | | | 27 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 1 | | | | Ponderación del Módulo | | | 3 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

GESTIÓN DE PROVEEDORES GESTIÓN DE PROVEEDORES | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Permitir el registro de proveedores | | | | 0 | | 2 | Relacionar a los proveedores según su clasificación, por rubro o actividad. | | | | 0 | | 3 | Permitir la actualización del registro de proveedores, permitiendo el bloqueo o desbloqueo de éste. | | | | 0 | | 4 | Permitir, en las cuentas por pagar, el ingreso de todo tipo de documentos a utilizar, por ejemplo, notas de débito o crédito, facturas, cheques, boletas, anticipos y ajustes, entre otros. | | | | 0 | | 5 | Para cada uno de los documentos ingresados se podrá definir toda la lógica de su tratamiento, contable y presupuestario. | | | | 0 | | 6 | Incorporar los libros contables legales (compra). | | | | 0 | | 7 | Las Cuentas por Pagar deben operar en múltiples moneda. | | | | 0 | | 8 | Las Cuentas por Pagar, además de registrar el devengo contable, deben poder generar las instancias presupuestarias de deuda exigible en el proyecto y Centro de Responsabilidad (debe registrar la ejecución presupuestaria y la clasificación respectiva según el fin del gasto o inversión) | | | | 0 | | 9 | Mostrar en línea la distribución contable propuesta por los parámetros del documento, la que puede ser aceptada o cambiada. (Distribución presupuestaria - contable con pre-ingreso de Orden de Compra) | | | | 0 | | 10 | Ingreso de notas de crédito y otros, donde toda reversa contable debe generar una reversa en la ejecución presupuestaria. | | | | 0 | | 11 | Generar en forma automática la autorización de Pago por Proveedor. | | | | 0 | | 12 | Cada autorización de pago debe contar con las referencias de cuentas que deben ser imputadas, Centros de Responsabilidad y los proyectos que son afectados. | | | | 0 | | 13 | Generada la autorización de pagos, contar con la posibilidad de reversar la operación antes de que se concrete. | | | | 0 | | 14 | El cierre mensual debe recalcular los saldos y limpiar los débitos y créditos de cada proveedor, preparando el próximo período (En el analítico del proveedor, debe mantenerse el historial de los débitos y créditos) | | | | 0 | | 15 | Libro de compras en línea, con la opción de impresión. | | | | 0 | | 16 | Historia de cuenta corriente del proveedor en línea. | | | | 0 | | | MAESTRO DE PROVEEDORES | | | | | | 17 | Debe permitir estructurar y mantener en línea los Maestros de Proveedores, Contratistas, los cuales incorporen los antecedentes generales del cada uno. Ejemplo: Nombre, Rut, dirección, fono, fax, casilla, etc. | | | | 0 | | 18 | Debe desplegar datos al ingresar el Rut o nombre, sin tener que digitarlos nuevamente cuando se estén registrando, por ejemplo en una Orden de trabajo. | | | | 0 | | 19 | Debe permitir la creación de proveedores, contratistas realizando validaciones con los existentes en el maestro correspondiente, para evitar duplicidades de información. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 38 | | | | Puntaje Mínimo Exigido | | | 27 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 1 | | | | Ponderación del Módulo | | | 3 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

Gestión de Contratos Gestión de Contratos | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Permitir el registro de contratos con proveedores externos. | | | | 0 | | 2 | El módulo de Contratos debe estar en línea con el presupuesto para ejecutar la pre obligación y compromiso de los montos en el presupuesto, además del módulo de Tesorería para el registro de la eventual boleta de garantía. También debe contar con el registro de devolución y generar alertas por vencimiento. | | | | 0 | | 3 | Para cada contrato actualizado se debe ingresar su calendario de pagos en el tiempo y las garantías si corresponde. | | | | 0 | | 4 | La solución deberá permitir manejar los contratos tales como hora hombre con precio unitario por especialidad, en horario normal y de emergencia por un periodo de un año, estas se imputaran día a día en las respectivas Órdenes de Trabajo (OT). | | | | 0 | | 5 | El sistema deberá entrega en línea el saldo del contrato por cada una de las especialidades además del monto total. | | | | 0 | | 6 | El sistema deberá incluir los contratos de servicio de distinto tipo con imputación de costos en la OT. | | | | 0 | | 7 | La solución deberá permitir administrar los contratos de servicio asociados distintas áreas del HOSCAR (Mantenimiento, Activo Fijo, Reparaciones, etc.) | | | | 0 | | 8 | Debe permitir generar y mantener un catastro o inventario de elementos (activos), el cual debe permitir relacionar con los contratos, para su posterior administración. Estas listas se deben actualizar automáticamente cuando se actualice el catalogo de operaciones. | | | | 0 | | 9 | Permitir extraer información en línea de otros sistemas, a través de parámetros de búsqueda (interoperabilidad). | | | | 0 | | 10 | La solución deberá permitir generar los estados de pago de los contratos de obras. | | | | 0 | | 11 | La solución deberá permitir generar modificaciones de trabajos en ejecución y el workflow de aprobaciones respectivo. | | | | 0 | | 12 | El sistema deberá entrega en línea el saldo del contrato por cada una de las especialidades además del monto total. | | | | 0 | | 13 | El sistema deberá incluir los contratos con la imputación de costos respectivas. | | | | 0 | | 14 | Permitir clasificar y agrupar las operaciones contratadas según categorías. | | | | 0 | | 15 | Permitir asociar fichas técnicas configurables a Activos y utilizar sus campos como criterios de búsqueda. | | | | 0 | | 16 | Permitir asociar cualquier documento al contrato. Ej. fotos, videos, documentos, planos, etc. | | | | 0 | | 17 | Facilidad para extraer información a través de reportes estándares o diseñados por el usuario. | | | | 0 | | 18 | La solución deberá permitir mantener un control de avance financiero y físico por cada contrato de obra en ejecución, que permita hacer una buena gestión de éstos. | | | | 0 | | 19 | Flujo administrativo (Workflow) de aprobaciones con respecto a los contratos podrán ser definidos por el usuario autorizado con herramientas estándar del sistema. | | | | 0 | | 20 | Se puede asignar la responsabilidad de aprobación a un rol en vez de a una persona. | | | | 0 | | 21 | Notificación por E-mail | | | | 0 | | 22 | Se puede asociar archivos de documentos almacenados en disco o red LAN considerando todos los aspectos de seguridad. | | | | 0 | | 23 | Se pueden asociar direcciones URL de Internet considerando todos los aspectos de seguridad. | | | | 0 | | 24 | El sistema con la información administrada debe ser capaz de generar cualquier indicador de gestión asociado que permita ir tomando medidas de gestión correctiva. | | | | 0 | | 25 | El sistema enviará reportes por e-mail | | | | 0 | | 26 | Capacidad de Entregar resultados de Reportes en Formato PDF (Adobe) | | | | 0 | | 27 | Capacidad de Exportar resultados a Excel | | | | 0 | | 28 | Reportes con capacidad gráfica | | | | 0 | | 29 | Capacidad para realizar búsqueda en los resultados de un reporte | | | | 0 | | 30 | Reportes con capacidad de hipervínculo con otros reportes de mayor detalle de análisis | | | | 0 | | 31 | Reportes programados (programado para ejecutarse en forma programada y recurrente). Resultados pueden ser enviados por E-mail a usuarios. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 62 | | | | Puntaje Mínimo Exigido | | | 43 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 1 | | | | Ponderación del Módulo | | | 3 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

INGRESOS: General Ingresos : General | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Permitir la creación y habilitación del establecimiento de salud para operar en cuentas por cobrar (deuda exigible, módulo de descuentos, libro de ventas, documentos en cartera, cobranza judicial, prefacturas, cuentas corrientes por clientes (estadías), cheques protestados, otros ingresos, anticipos de terceros, C x C, Recuperación de Préstamos, Deudas años anteriores. | | | | 0 | | 2 | Ingresar el año y mes de inicio de operación y los diferentes tipos de comprobantes, los cuales serán entregados en su oportunidad por el establecimiento de salud. | | | | 0 | | 3 | Indicar las cuentas de Renegociación de Deudas, de otros depositantes en caso de recibir pagos por montos no generados, cuentas de resultado, de intereses y de ingresos varios para registro (por ejemplo: cheques a fecha del paciente o tercero). | | | | 0 | | 4 | Generar bitácora de deuda del paciente con la forma de pago y las cuotas pendientes de cobro, y su historial desde su ingreso hasta que cancela. | | | | 0 | | 5 | Ingresar una clasificación de Clientes-Deudores para control y gestión por tipo de deudor. | | | | 0 | | 6 | Permitir bloquear o desbloquear a un cliente-deudor de forma manual y/o automática. | | | | 0 | | 7 | Permitir definir usuarios de todos los tipos de documentos, por ejemplo: débito o crédito, facturas, prefacturas, guías de despacho, órdenes de atención, boletas exentas de impuesto, bonos, ajustes contables, cheques, cheques post fechados, remesas, fondos por rendir, otros ingresos, pagarés, aranceles, matrículas, fondos de terceros, tarjetas de crédito y otros. | | | | 0 | | 8 | Permitir realizar auditorías por emisión de documentos; indicar el motivo de la situación como medida de control. | | | | 0 | | 9 | Permitir Definir a cada documento toda la lógica de su tratamiento contable y presupuestario. Definiendo las cuentas de registro contable y presupuestario que son afectadas y los libros legales correspondientes. | | | | 0 | | 11 | Permitir definir el rango de foliación de comprobantes generados por el sistema de Cuentas por Cobrar, por tipo de documento, de tal forma de facilitar el posterior análisis de transacciones por folio. | | | | 0 | | 12 | Permitir la definición, clasificación, tipificación y tarifado de servicios que el establecimiento de salud, venda o provea a terceros y que originen registros de ingresos en el sistema de Cuentas por Cobrar. | | | | 0 | | 13 | Permitir retarificar y/u homologar por categoría o previsión las ventas a clientes, detallando código, número de orden, fecha, monto, cantidad, tarifa, centros de costo, identificación del cliente, tipo de grupo de cobro. | | | | 0 | | 14 | Generar solicitudes de notas de crédito, débito y refacturación a través de un registro anterior o archivos magnéticos, según estructuras definidas. | | | | 0 | | 15 | Permitir exportar los cargos de ventas ambulatorias como hospitalizados por parámetros según el proceso de cierre semanal, mensual, diario, por tipos de clientes, otros. | | | | 0 | | 16 | Permitir generar facturación electrónica (SII) masiva, individual y de otro tipo, con bonificaciones según categorías o convenios de clientes. | | | | 0 | | 17 | Generar informes de facturación por períodos, situación de prefacturas, estadías de pacientes hospitalizados y de alta. | | | | 0 | | 18 | Que permita asociar la facturación al ingreso del paciente y su estadía. | | | | 0 | | 19 | Que permita emitir documentos de despacho y su control, considerando, fecha de despacho y fecha de posible pago. | | | | 0 | | 20 | Que permita parametrizar tipos de ingresos, para generar reportes y cierres. | | | | 0 | | 21 | Que permita realizar búsqueda por código o descripción y listar códigos de prestaciones facturas y por parámetros. | | | | 0 | | 22 | Relación entre el servicio definido con el o los Centros de Responsabilidad y con los proyectos presupuestarios a los que correspondan, indicando también las cuentas de imputación, de tal forma que el registro de un ingreso asociado a un servicio genere en forma automática el asiento contable y la imputación presupuestaria que corresponda. | | | | 0 | | 23 | Ingreso y registro de movimientos que generan débitos o créditos en Cuentas por Cobrar. | | | | 0 | | 24 | El ingreso de movimientos de débito debe recuperar el Centro de Responsabilidad, el código del Cliente-Deudor, la fecha, moneda de la transacción, tipo de documento, impuestos relacionados, fechas de registro y de vencimiento, generando en línea la distribución contable. | | | | 0 | | 25 | Al grabar el documento se debe generar automáticamente el asiento que va a la contabilidad en estado pendiente para revisión y posterior contabilización. | | | | 0 | | 26 | Un documento en estado pendiente puede ser anulado o modificado. Si ha sido contabilizado se debe reversar. Por ejemplo, facturas, posfacturas y otros documentos que se indique. | | | | 0 | | 27 | La contabilización de un documento debe traspasar los registros contables a los balances y libros legales. | | | | 0 | | 28 | Cuando la moneda de origen no es la local, el sistema debe generar en línea el monto de registro en moneda local. | | | | 0 | | 29 | Contar con el ingreso y registro de movimientos de crédito en Cuentas por Cobrar, con el fin de anular o reversar movimientos de débito. | | | | 0 | | 30 | Crear módulo de crédito que permita calcular: deuda capital, cantidad de cuotas, reajustes, intereses de mora, gastos de cobranza y amortización de deuda capital, saldos, otros. | | | | 0 | | 31 | Permitir el ingreso y aprobación de prórrogas de pago de documentos en cartera que estén vencidos. | | | | 0 | | 32 | Permitir la renegociación de deudas, solicitud de renegociación, aprobación, cancelación de la deuda anterior y generar una nueva deuda con las nuevas condiciones, generando en línea los movimientos contables y presupuestarios que afectan esta operación. | | | | 0 | | 33 | Simular los valores resultantes de una solicitud de renegociación. | | | | 0 | | 34 | Mantener en línea el historial completo del Cliente-Deudor, mostrando por cliente, sus montos deudores y los saldos por cada documento, forma de abono o pagos y los tipos de documentos de pago con que fueron registrados. | | | | 0 | | 35 | Administrar la cobranza devuelta, registrando las objeciones y/o reparos, generando la nota de crédito para limpiar la deuda exigible, dejando la cobranza en estado de análisis para refacturar si corresponde. | | | | 0 | | 36 | Emisión de reportes, exportables a planilla Excel de los descuentos formulados y efectuados por número de RUN. | | | | 0 | | 37 | Sistema de descuento que permita efectuar tanto cargos de forma individual como masiva. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 74 | | | | Puntaje Mínimo Exigido | | | 52 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 1 | | | | Ponderación del Módulo | | | 10 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

Ingresos: Manejo de Fondos y Anticipo de Proveedores Ingresos: Manejo de Fondos y Anticipo de Proveedores | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | | 1 | El sistema debe tener toda la funcionalidad para el manejo de fondos, ingreso de solicitudes de fondos (Fijos o Por Rendir), su aprobación y contabilización, y registro presupuestario en caso que corresponda. | | | | 0 | | | 2 | El sistema debe ser capaz de capturar todos los datos del solicitante y del beneficiario de fondos, el tipo de documento que será utilizado, moneda, centro de responsabilidad, proyecto y otros. | | | | 0 | | | 3 | El sistema debe manejar todos los fondos como una cuenta por cobrar por parte del girador o el beneficiario del fondo, y en ese contexto se deben generar las transacciones contables y presupuestarias que corresponda. | | | | 0 | | | 4 | La rendición de un fondo debe mostrar el monto asignado y registrar el reintegro, dejando registrado, si existe, el saldo por rendir. | | | | 0 | | | 5 | La rendición de un fondo debe registrar el Centro de Responsabilidad, Proyecto Presupuestario y, según el tipo de documentos, debe mostrar la distribución contable del asiento que se ejecuta con la rendición. Reintegro del fondo no ocupado en su totalidad. | | | | 0 | | | 6 | Listado detallado del estado de las aprobaciones y rendiciones de fondos en el sistema en forma global o por beneficiario deudor del fondo. | | | | 0 | | | 7 | El anticipo de proveedores debe tener la misma lógica de operación que la de los fondos. | | | | 0 | | | 8 | El sistema debe permitir la aprobación de los anticipos y captura del Centro de Responsabilidad y Proyecto, en caso que eso corresponda. | | | | 0 | | | | CONSULTAS | | | | | | | 9 | Permitir consultas en línea sobre movimientos de Cuentas por Cobrar que afectan a Clientes-Deudores. | | | | 0 | | | 10 | Libro de Ventas en línea con la opción de imprimir por año, mes, día. | | | | 0 | | | 11 | Mostrar en diferente columna los montos afectos y los exentos para poder definir y calcular, de ser necesario, la proporcionalidad de impuesto al valor agregado (IVA), dado que esta Institución esta exenta de IVA de Venta, el IVA de las Compras debe ser considerado como parte del costo. | | | | 0 | | | 12 | Consulta en línea del historial del Cliente-Deudor. | | | | 0 | | | 13 | Consulta en línea del historial de Rendiciones de Fondos. | | | | 0 | | | 14 | Incluir múltiples reportes operacionales orientados a la gestión de cuentas corrientes de Clientes-Deudores, ingresos devengados y referencias de operaciones de las Cuentas por Cobrar. | | | | 0 | | | 15 | Incluir Reportes de ingresos devengados y referencias de operaciones de las Cuentas por Cobrar. | | | | 0 | | | 16 | Generar en línea todos los asientos contables y presupuestarios asociados al movimiento y los documentos que están siendo ingresados. (Ejecución Presupuestaria) | | | | 0 | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | | | Puntaje Máximo Posible | | | 32 | | | | | Puntaje Mínimo Exigido | | | 22 | | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 1 | | | | | Ponderación del Módulo | | | 3 | | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

Ingresos: Gestión de Caja Ingresos: Gestión de Caja | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Permite ingresar todos los documentos que operarán en la función de caja. | | | | 0 | | 2 | Permite el ingreso de la definición de cajas, usuario responsable, tipo de asiento contable que realiza y moneda de operación. La caja de moneda extranjera sólo podrá mover documentos en esa moneda. | | | | 0 | | 3 | Facilitar la apertura de caja registrando el usuario y momento de la apertura y el cierre de la misma. | | | | 0 | | 4 | La recaudación por caja debe recoger todas las referencias de los documentos que se están pagando y también capturar los documentos y sus referencias con que se está recaudando. | | | | 0 | | 5 | Clasificar la “liquidez” del documento recibido (efectivo, por ejemplo, tiene la más alta liquidez, pudiendo luego ordenar el arqueo por liquidez de lo recaudado). | | | | 0 | | 6 | Cargar en línea intereses por mora en la recaudación de ingresos. Permitir definir el tipo de clientes asociados al cobro de reajustes y devengos. | | | | 0 | | 7 | Anular movimientos ejecutados por el sistema de cajas antes de su cierre y antes de que hayan afectado la cuenta corriente del deudor, con lo cual se reversan todos los movimientos que hubiesen sido generados, previa aprobación y autorización del Supervisor. | | | | 0 | | 8 | Reversar contablemente movimientos de caja después que esta haya sido cerrada y cuando ya hubiese afectado la cuenta corriente del deudor y los saldos en las cuentas de caja y banco. En este caso el sistema reversa todos los movimientos que afectan la caja, al cliente, el banco y los libros. (Debe llamarse al ID de contabilización inicial para efectuar reversa.) | | | | 0 | | 9 | Arqueo de Caja para todos y cada uno de los diferentes documentos con que se ha recaudado. Presentar un resumen del arqueo por tipo de documento en moneda local y moneda de origen, permitiendo identificar claramente el monto a la Apertura y el Saldo al Cierre de la Caja. | | | | 0 | | 10 | Cierre de Caja por usuario responsable una vez que se ha efectuado el arqueo. | | | | 0 | | 11 | Reportes de la actividad de la caja, por cliente o deudor, por tipo de movimiento, por tipo de documento, moneda y usuario, Por Tipo de Producción (Venta). | | | | 0 | | 12 | La caja genera automáticamente los asientos contables y los envía a la contabilidad con las referencias, y también ejecuta las instancias presupuestarias que correspondan según sea percepción de ingreso o pago de gasto. | | | | 0 | | | | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 24 | | | | Puntaje Mínimo Exigido | | | 17 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 0 | | | | Ponderación del Módulo | | | 3 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

FACTURACIÓN FACTURACIÓN | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Capacidad de Facturar por Tipo de Prestación, Grupo de Paciente, y otros | | | | 0 | | 2 | Capacidad de Generar Archivo de Traspaso a DIPRECA, para carga manual WEB | | | | 0 | | 3 | Capacidad de Efectuar Abonos Parciales de Pacientes a la Cuenta Respectiva | | | | 0 | | 4 | Permitir la Consulta Online de Detalles por Facturar de Pacientes para Revisión. | | | | 0 | | 5 | Capacidad de Imprimir Facturas Tributarias asociadas al Cobro de Pacientes Particulares, Actos de Servicio de las Instituciones, y otros. | | | | 0 | | 6 | Capacidad de Calcular y Emitir Cobros en base a Cargo Imponente (Gendarmería e Investigaciones) | | | | 0 | | 7 | Habilidad para distinguir claramente las categorías de Paciente, Institución Aseguradora, Institución Pagadora (Dipreca) | | | | 0 | | 8 | Permitir la consulta e impresión en cualquier momento de un estado de cuenta (Prefactura), correspondiente a un paciente hospitalizado o de cualquier otro tipo de cliente. | | | | | | | | | | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 16 | | | | Puntaje Mínimo Exigido | | | 11 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 0 | | | | Ponderación del Módulo | | | 3 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

ABASTECIMIENTO ABASTECIMIENTO | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Permitir la operación simultánea de múltiples Unidades de Negocio y/o Centros de Costo | | | | 0 | | 2 | Proceso de compras en su mayoría centralizado | | | | 0 | | 3 | Excepcionalmente, para ciertos requerimientos (Ítem, artículos, o familias de productos), que no es posible o resulta ineficiente mantener stock, se deberá considerar el despacho periódico descentralizado de pedidos a unidades usuarias (Centros de Costo) por parte de los proveedores, previas aprobación y control de consumos y facturación por parte de Abastecimiento. Lo anterior facilitará la implementación de un sistema Just In Time que optimice la utilización de recursos. | | | | 0 | | 4 | Captura de datos de Proveedores en línea (por ejemplo, contratos, otros) y directamente desde el Sistema de Cuentas por Pagar (por ejemplo, deuda vencida, disponibilidad de crédito, etc.). | | | | 0 | | 5 | Solicitudes internas de compras, compras directas con o sin licitación, e ingreso de planes de compra, deben referenciar artículos que existan en el maestro general de artículos que utiliza el sistema de Abastecimiento (Catálogo). | | | | 0 | | 6 | Creación descentralizada de solicitudes internas de requerimientos de compras de Bienes y Servicios. | | | | 0 | | | Los Bienes pueden ser: | | | | 0 | | | • Bienes de Cambio: Activados a su ingreso a existencias y llevados a gasto al momento de su venta. | | | | 0 | | | • Bienes de Consumo: Activados a su ingreso a existencias y llevados a gasto por cada Unidad de Negocio y/o Centro de Costo a su consumo. | | | | 0 | | | • Bienes del Activo Fijo: Los Bienes de Uso se deprecian y revalorizan y los Bienes de Consumo no se deprecian ni revalorizan. | | | | 0 | | 7 | En línea con lo asignado en presupuesto; deberá afectar a cada Centro de Costo, por lo que el sistema debe exigir, para cada ingreso de requerimientos, el código del Centro de Costo, proyecto o programa (definir) presupuestario, a objeto de ser cargado el pedido. La verificación de la disponibilidad presupuestaria será en línea. | | | | 0 | | 8 | Disponibilidad presupuestaria aceptada, autorizar la solicitud por pantalla. | | | | 0 | | 9 | Para los requerimientos internos aprobados, el sistema debe emitir la(s) Solicitud(es) de Cotización, capturando los eventuales oferentes desde el sistema de Proveedores. Por ejemplo, eventos inusuales como solicitudes de artículos a pedidos, entre otros. | | | | 0 | | 10 | Emitir cotizaciones por código de proveedor (por ejemplo, razón social, RUT, dirección teléfono, etc.), considerando última cotización vigente (por ejemplo, rango de tiempo, fecha). (Por responsabilidad administrativa el sistema deberá guardar cotizaciones históricas hasta 5 años). | | | | 0 | | 11 | En compras de cualquier modalidad enviar las solicitudes de cotización a los proveedores vía fax, correo electrónico u otro medio disponible, además del servicio Mercado Público , con el traspaso del requerimiento al portal y guardar la referencia del requerimiento interno que fue preobligado o pre aprobado. | | | | 0 | | 12 | El flujo a través de Mercado Público es continuado una vez emitida en el Portal la correspondiente Orden de Compra, la cual es ingresada al sistema, que la parea con la referencia dejando abierta la ejecución de la Obligación o Compromiso Presupuestario. | | | | 0 | | 13 | Si no están disponibles los servicios del portal Mercado Público, el sistema debe permitir el ingreso de las cotizaciones, actualizar los datos y precios de los proveedores y presentar un “Cuadro Comparativo” con hasta seis cotizaciones y una sugerencia de adjudicación por mejor precio y calidad que puede ser modificada por el usuario, según fundamento técnico. | | | | 0 | | 14 | El sistema debe permitir seleccionar la o las mejores ofertas de uno o más proveedores, adjudicar la compra previamente obligada o en línea, y emitir cuadros comparativos, Orden de Compra, y Actas de Adjudicación cuando sea requerido. | | | | 0 | | 15 | Permitir la generación de Órdenes de Compra sin efectuar el proceso de adjudicación (tal como compras de urgencia). | | | | 0 | | 16 | En la generación de Órdenes de Compra sin efectuar el proceso de adjudicación permitir la consulta al presupuesto, la autorización y el registro simultáneo de la preobligación y el compromiso. | | | | 0 | | 17 | Permitir el ajuste a la Orden de Compra en forma posterior a su emisión, hasta un cierto monto, si este supera el monto mínimo autorizado solicitar una aprobación. | | | | 0 | | 18 | Permitir llevar el registro histórico y el estado de cada Orden de Compra emitida. | | | | 0 | | 19 | Permitir mantener la Orden de Compra abierta, ante una recepción parcial o no cumplida de mercaderías en bodega (dependerá de los estados que se configuren). | | | | 0 | | 20 | La valorización de los artículos se recibe del maestro (catálogo), en donde se guarda los últimos valores pasados de compras de los artículos, mostrando el valor de la última recepción, cantidad y diferencia porcentual entre la última compra y la nueva. El sistema deberá permitir la valorización de las salidas y existencias finales de acuerdo los métodos FIFO (First Input – First Output), LIFO (Last Input – First Output), PPP (Precio Promedio Ponderado) u otro de acuerdo a políticas establecidas por la Dirección General del HOSCAR. | | | | 0 | | 21 | Ingreso de Órdenes de Compra masivas desde, por ejemplo, programas de compra anual, mensual o quincenal entre otros. | | | | 0 | | 22 | Parametrizar plazos de entrega, prioridades, compras a proveedores alternativos, etc., a objeto de permitir la evaluación administrativa de proveedores por estos conceptos (cumplimiento de contratos). | | | | 0 | | 23 | Emitir Solicitudes de Compra sin registro de presupuesto en situaciones de urgencias según demanda asistencial (los recursos que se utilizarán no son sujetos a control presupuestarios). | | | | 0 | | 24 | Consulta de Solicitudes y de Órdenes de Compra emitidas o en cualquier estado. | | | | 0 | | 25 | Anular solicitudes internas o requerimientos no procesados como Órdenes de Compra u otros. Cuando estas solicitudes hayan sido aprobadas y ejecutadas, se podrá reversar la transacción correspondiente a la pre obligación y al presupuesto. | | | | 0 | | 26 | Anular Órdenes de Compra emitidas pero no enviadas al Proveedor. Reversar la pre obligación y también el compromiso. | | | | 0 | | 27 | “Cerrar” una Orden de Compra de la cual se haya recibido sólo una parcialidad | | | | 0 | | 28 | Cierre de mes o año, de tal forma que se actualicen los períodos de operación, además de alertas mensuales indicando las Órdenes de Compra pendientes. | | | | 0 | | 29 | Al término del período contable las Órdenes de Compra pendientes de cumplimiento total o parcial automáticamente deben cerrarse y abrirse en el nuevo período. | | | | 0 | | 30 | Permitir el ingreso oportuno de elementos que no existan en el maestro de artículos, con el objeto de facilitar su dispensación, uso y cobro. Posteriormente, su ingreso al maestro será regularizado (codificado y clasificado). | | | | 0 | | 31 | El Sistema debe permitir el Ingreso Electrónico (vía importación o automática) de documentos EDI (estándar EDIFACT/96) y/o XML (versión 2007), tipo GUÍA DE DESPACHO (DESADV) o FACTURA (INVOIC). | | | | 0 | | 32 | Permitiendo recibir en BODEGA contra la información recibida en documento electrónicos de despacho. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 64 | | | | Puntaje Mínimo Exigido | | | 45 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 1 | | | | Ponderación del Módulo | | | 4 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

GESTIÓN COMPRAS GESTIÓN COMPRAS | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | | GENERALES | | | | | | 1 | El módulo deberá permitir el control y monitoreo de todas las operaciones de compras de manera eficiente. Contribuirá en su diseño a dar soluciones que ayuden en los procesos de requisición de materiales, pedidos de cotización, órdenes de compra y acuerdos de compra, de forma rápida y eficiente reduciendo el flujo de documentos, costos administrativos y permitiendo asimismo a los compradores focalizar su tarea en actividades estratégicas tales como negociación de contratos, desarrollo y calificación de proveedores, y análisis de los costos. | | | | 0 | | 2 | La Aplicación deberá proveer herramientas de reportes y control que colaboren al monitoreo de los costos de aprovisionamiento, calidad y performance en la compra y entrega de productos. | | | | 0 | | 3 | Debe poder gestionar las compras de diversos ítems: | | | | 0 | | | -productos (insumos y medicamentos) | | | | | | | -Repuestos. | | | | | | | -productos e insumos catalogados y no catalogados. | | | | | | | -Activo fijo (equipos)
-Servicios | | | | | | 4 | Debe efectuar la contabilización automática en la recepción de productos e insumos, equipos y repuestos, recepción con certificación y actualización de inventarios. | | | | 0 | | 5 | Debe permitir la configuración de diversos circuitos de documentos y procesos: | | | | 0 | | | ·Compras sin requisición. | | | | | | | ·Orden de Compras abiertas. | | | | | | | ·Compras de importación. | | | | | | | ·Compras menores. | | | | | | | ·Compras en consignación. | | | | | | 6 | Las compras sin requisición son solicitadas verbalmente y en sistema deberá quedar registrado todo el proceso de compra para el pago de factura. | | | | 0 | | 7 | Las compras abiertas son los contratos de productos generados en la unidad de abastecimiento, por un periodo de dos años, con precios acordado en la licitación y sus reajustes correspondientes, por lo cual los precios deben ser parametrizables para este tipo de compra. Los productos solicitados al proveedor son mediante orden de entrega. | | | | 0 | | 8 | Las compras de importación corresponden a los productos adquiridos en el extranjero, proceso que debe estar soportado completamente a través del Sistema. | | | | 0 | | 9 | Los productos en consignación serán administrados por el departamento de Abastecimiento. La definición de ítems para consignación se realizará por decisión de este departamento o por un requerimiento del usuario. Los ítems en consignación se deberán registrar en el catálogo de productos. | | | | 0 | | 10 | El registro de los productos para consignación en el catálogo de productos se realizará de la misma forma que un ítem de stock, asimismo el consumo de este material será cargado a una Unidad de Negocio y/o centro de costo. En esta modalidad de adquisición de productos contempla que el material debe permanecer en las bodegas y el pago es mensual de acuerdo a los consumos realizados durante el mes. | | | | 0 | | 11 | Los ítems de consignación deben ser factibles de administrarse en función del contrato con el proveedor. | | | | 0 | | 12 | Las compras menores corresponden a productos adquiridos en comercio local, estos productos pueden o no estar en el maestro de productos, el proceso deberá considerar la solicitud de compra menor generado por área responsable para su aprobación. | | | | 0 | | 13 | Debe poder calcular los tiempos de demora del proceso de compras, desde el requerimiento hasta la llegada de la mercadería, incluyendo todos los procesos parciales (ingreso Pedido de Material (PM), aprobaciones, cotizaciones, Orden de Compra) | | | | 0 | | 14 | Debe permitir modificar maestros de productos, medicamentos e insumos de acuerdo a definiciones de perfiles de usuario. | | | | 0 | | | ADMINISTRACIÓN DE PROVEEDORES | | | | | | 15 | El Registro o Maestro de Proveedores deberá contener campos como: nombre, dirección, teléfono, fax, e-mail, persona contacto, líneas de productos que fabrica o comercializa, referencias bancarias, referencias comerciales, entre otros. | | | | 0 | | 16 | Debe poder inhabilitar a proveedores con mala calificación | | | | 0 | | 17 | Debe permitir la calificación de proveedores según distintos conceptos. | | | | 0 | | 18 | Debe permitir la categorización de proveedores por rubro. Clasificación de los proveedores que permita identificar si se trata de: proveedor de medicamentos, equipos, productos, repuestos, servicios u otros. | | | | 0 | | 19 | Debe otorgar información de tiempos de entrega por proveedor y pedido, desde el envío de la Orden de Compra (O.C) hasta la recepción de la mercadería. | | | | 0 | | 20 | Debe permitir la configuración libre de atributos de proveedores | | | | 0 | | 21 | Debe otorgar información para módulo de pagos y presupuestos | | | | 0 | | 22 | Debe permitir la homologación de proveedores de acuerdo a certificación ISO 9001. | | | | 0 | | 23 | Identificación de proveedores locales y nacionales, con o sin movimiento. | | | | 0 | | | REQUERIMIENTOS DE COMPRAS | | | | | | 24 | Debe permitir el ingreso de requerimientos en línea para ítems catalogados y no catalogados: | | | | 0 | | | ·Emisión de requerimientos automáticos al alcanzar el punto de pedido | | | | | | | ·Gestión de requerimientos provenientes de las diferentes áreas usuarias. | | | | | | 25 | Administración de distintos estados por requerimiento de Compras: | | | | 0 | | | ·Pendiente de autorización. | | | | | | | ·Aprobado. | | | | | | | ·En proceso de compra. | | | | | | | ·Emitida la Orden de Compra. | | | | | | | ·Recepcionado parcial o total. | | | | | | | ·Anulado. | | | | | | 26 | Debe exigir el campo Unidad de Negocio y/o “centro de costo emisor” y destino en el requerimiento de compra, el que luego debe ser asignado automáticamente al momento de generarse la orden de compra. | | | | 0 | | 27 | Debe permitir la consulta del estado de los requerimientos, permitida tanto para el usuario responsable de la emisión, como para las áreas de compras y control. | | | | 0 | | 28 | Debe otorgar permisos de anulación de un requerimiento en forma manual por ítem y total. | | | | 0 | | 29 | Debe poder establecer niveles de prioridad por requerimiento (normal y urgente). | | | | 0 | | 30 | Debe brindar la posibilidad de realizar requerimientos recurrentes. | | | | 0 | | 31 | Debe brindar funciones de control de stock y presupuesto según configuración en cada caso. | | | | 0 | | 32 | Debe permitir de acuerdo a perfiles de usuarios la autorización de las requisiciones basado en el monto. | | | | 0 | | 33 | Debe permitir adjuntar planos, documentos en la solicitud de cotización. | | | | 0 | | 34 | Debe tener integración con la interfaz basada en estándar XcBL 4.0 de MERCADO PÚBLICO , permitiendo ingresar en forma electrónica la Órdenes Generadas y Aprobadas a la Plataforma MERCADO PÚBLICO S. | | | | 0 | | | GESTIÓN DE COMPRAS | | | | | | 34 | Record histórico de compras, desde las requisiciones, cotizaciones, hasta las Órdenes de Compra (a quién se cotizó, todas las fechas, detalle de todos los movimientos efectuados con relación a una requisición, cuadro selección de proveedores, hoja entrada de material). Esta información debe poder ser filtrada por: proveedor, Orden de Compra (OC), requisición, ítem, comprador. | | | | 0 | | 35 | Debe consolidar los requerimientos de compra en forma manual y automática por rubro, ítem y prioridad. | | | | 0 | | 36 | Debe generar solicitudes de cotizaciones en forma automática cuando se llegue a un mínimo predefinido de ÍTEMS, en los ÍTEMS y RUBROS definidos previamente. | | | | 0 | | 37 | Debe otorgar la facilidad de gestionar las funciones de compra desde una única pantalla. | | | | 0 | | | SOLICITUD DE COTIZACIONES | | | | | | 38 | Envío electrónico de solicitudes de cotización (RFQ) a proveedores. | | | | 0 | | 39 | Opción de impresión de la cotización en papel. | | | | 0 | | 40 | Formatos de requisiciones, cotizaciones y Órdenes de Compra, impresos desde el sistema. | | | | 0 | | 41 | Opción de transmitir electrónicamente al proveedor sólo determinada información de las cotizaciones. (Ejemplo: no enviar precios, consumos, entre otros), en formatos estandarizados XML o EDI (EDIFACT). | | | | 0 | | 42 | Proveedores deben vincularse a grupos y clases de productos (relación ítem-proveedor). | | | | 0 | | 43 | Formato predeterminado de solicitud de cotización (que incluya campos como: descripción del ítem, cantidad solicitada, precio, condiciones de entrega, condiciones de pago, ofertas alternativas). | | | | 0 | | 44 | Formatos predeterminados para uso en negociaciones: invitación, formato de petición de oferta, cuadro comparativo. | | | | 0 | | 45 | Ingreso de información por parte del proveedor a los formatos electrónicos (archivos planos) pre-determinados para solicitud de cotización de proveedores. Además, después de recibir estos archivos del proveedor el sistema deberá cargar dicha información. | | | | 0 | | 46 | El sistema debe permitir el manejo de productos alternativos sugeridos por el proveedor en la cotización. | | | | 0 | | 47 | Información pre-determinada de tarifas de fletes (marítimos, aéreos, terrestre, courrier). | | | | 0 | | | ADMINISTRACIÓN DE COTIZACIONES | | | | | | 48 | Debe permitir la administración de cotizaciones en forma manual y automática. | | | | 0 | | 49 | Debe permitir la Administración de cotizaciones de varias requisiciones de un mismo rubro. | | | | 0 | | 50 | Debe gestionar las cotizaciones recibidas de los proveedores:
·Manejo de fecha de vencimiento de las cotizaciones.
·Sistema de ingreso de las respuestas de los proveedores a medida que se reciban.
·Debe realizar comparaciones a nivel de ítem y a nivel de totales. | | | | 0 | | 51 | Generar solicitudes y respuestas de cotizaciones vía Internet y por fax Server. | | | | 0 | | 52 | Permitir cotizaciones a proveedores que operen con un portal de comercio electrónico (market place, Mercado Público) y proveedores fuera del portal (market place), en el cuadro comparativo se deberá considerar ambos grupos de proveedores. | | | | 0 | | 53 | Generación automática del cuadro comparativo de ofertas a partir del ingreso de ofertas, ya sea por medio electrónico o manual (precios, términos de entrega, términos de pago, descuentos, sobrecostos). Considerar una escala de pesos específicos para evaluación de variables cualitativas y cuantitativas (precio, tiempo de entrega, calidad, garantía, entre otras). | | | | 0 | | 54 | Debe poder Identificar por la planilla comparativa la mejor oferta en cuanto a:
·Precio cotizado
·Plazo de entrega
·Comparar las cotizaciones en diferentes monedas
·El monto total deberá incluir embalaje y gastos de exportación | | | | 0 | | 55 | Debe permitir la realización de compras a proveedores en forma directa hasta la generación de la Orden de Compra, la cual deberá ser autorizada de acuerdo al perfil del usuario. | | | | 0 | | 56 | Debe permitir la adjudicación de todos los ítems a un proveedor o varios proveedores. Debe permitir la adjudicación de un ítem a más de un proveedor. | | | | 0 | | 57 | El requerimiento deberá indicar al usuario el estado en que se encuentra en las diferentes etapas del proceso de cotización. | | | | 0 | | | ÓRDENES DE COMPRA | | | | | | 58 | La aplicación permitirá a los compradores crear las Órdenes de Compra de la manera más rápida y eficiente posible, esto implicará que su generación esté apoyada por información predeterminada, enlace con el convenio acordado y con la información del proveedor. | | | | 0 | | 59 | Después de la decisión de compra, basándose en el análisis del cuadro comparativo de ofertas, poder “marcar” la relación de correspondencia de ítem(s)/proveedor(es), para que se pueda generar automáticamente la(s) Orden(s) de Compra (O.C). | | | | 0 | | 60 | Inclusión de costos adicionales en Orden de Compra (flete interno, flete aéreo, flete marítimo, embalaje, seguros, etc.). | | | | 0 | | 61 | Debe asignar en forma automática un número correlativo a las Órdenes de Compra emitidas. | | | | 0 | | 62 | Aplicación de descuentos en la Orden de Compra. | | | | 0 | | 63 | Debe poder generar Órdenes de Compra con múltiples fechas de entrega y con más de un lugar de entrega. | | | | 0 | | 64 | Debe permitir asociar un requerimiento del usuario a más de una Orden de Compra y a la factura del proveedor. | | | | 0 | | 65 | Envío de Orden de Compra automatizada, según puntos de reorden, con referencia a acuerdos de compra con proveedores. | | | | 0 | | 66 | Debe brindar la posibilidad de definir distintos niveles de autorización de una Orden de Compra en función del monto involucrado. Debe permitir autorizar electrónicamente los requerimientos de compra. | | | | 0 | | 67 | Anulación de ítems o total de Orden de Compra de acuerdo a los perfiles de usuarios. | | | | 0 | | 68 | Debe permitir asociar una Orden de Compra a más de una factura del proveedor. | | | | 0 | | 69 | Debe valorizar la Orden de Compra en forma automática según cotización aceptada. | | | | 0 | | 70 | Debe permitir el manejo de vigencia y generación multimoneda de las Órdenes de Compra (En pesos, dólares, unidades de fomento, etc.) | | | | 0 | | 71 | Debe permitir convertir los montos de las Órdenes de Compra, ya sea en pesos, dólares u otra moneda y mantener un histórico con dicha información. | | | | 0 | | 72 | Administración de distintos estados de una Orden de Compra.:
·Pendiente de autorización
·Autorizada
·Pendiente de recepción
·Recibida sujeta a conformidad del sector que realiza el control de calidad
·Cumplida parcialmente
·Cumplida
·Recibido no satisfactoriamente
·Anulada (parcial/total)
·Vencida. | | | | 0 | | 73 | Debe permitir la generación de consultas y listados de Órdenes de Compra por estado. | | | | 0 | | 74 | Debe brindar la posibilidad de definir múltiples condiciones de pago para las Órdenes de Compra:
·Pago total o parcial a determinados días de la fecha de recepción de la factura y la mercadería.
·Pago en cuotas iguales y no iguales.
·Anticipos totales o parciales.
·Dejar facturas pendientes | | | | 0 | | 75 | Debe permitir la emisión de Órdenes de Compra para ítems de importación:
·Múltiples monedas
·Modalidad de compra (FOB, CIF, u otra modalidad)
·Múltiples instrumentos de pago, identificando el número de carta de crédito si la operación es financiada por una entidad financiera. | | | | 0 | | 76 | Debe tener la opción de anular y listar las Órdenes de Compra, no desapareciendo el registro. | | | | 0 | | 77 | Debe permitir actualizar en forma automática las Órdenes de Compra, rebajando de cada ítem los productos recibidos. | | | | 0 | | 78 | Debe permitir generar contabilizaciones automáticas, por centro de costos, de los siguientes eventos:
·Costo de ventas
·Proveedores
·Compras
·Devoluciones
·Reemplazos sin cargo al cliente
·Activo fijo
·Ajustes | | | | 0 | | | MANEJO DE MATERIALES EN TRANSITO | | | | | | 79 | La aplicación deberá proveer las herramientas necesarias para el control y seguimiento de los productos en tránsito. Esta operación incluye el seguimiento de Órdenes de Compra locales y de importación. Para lograr un eficiente manejo de productos en tránsito, el sistema debe disponer de información proporcionada por operadores logísticos claves en el proceso: agencias de aduana, agente embarcador y almacén en tránsito. | | | | 0 | | 80 | A través del sistema se podrá solicitar todas las Órdenes de Compra (aprobadas) pendientes de entrega. | | | | 0 | | 81 | Se deberá separar las Órdenes de Compra según sean de importación o locales, para los seguimientos respectivos. | | | | 0 | | 82 | Se podrán agrupar las Órdenes de Compra de la siguiente manera:
·Las que se encuentren pendientes de atención con plazo de entrega no vencido,
·Las que se encuentren pendientes de atención con plazo de entrega vencido y,
·Las que se encuentren atendidas (material recibido en almacén destino). | | | | 0 | | 83 | Para las Órdenes de Compra atendidas, se indicará el día de ingreso a almacén del Transportista y la fecha de envío a bodega destino, así como el número de guía de remisión (o guía de transporte) correspondiente. | | | | 0 | | 84 | Se podrá acceder a un seguimiento total en el que se podrá escoger el visualizar:
·Órdenes de Compra pendientes de atención,
·Órdenes de Compra con entregas parciales y,
·Órdenes de Compra totalmente atendidas. | | | | 0 | | | SEGUIMIENTO DE ÓRDENES DE COMPRA LOCALES | | | | | | 85 | El seguimiento de compras locales deberá poder ser ejecutado por el usuario. El reporte de seguimiento deberá ser filtrado por:
·Proveedor
·Orden de Compra
·Ítem
·fecha
·Guía de remisión. | | | | 0 | | 86 | La información básica con la que debe contar el seguimiento es:
·Fecha de emisión de la Orden de Compra.
·Fecha de recepción de Orden de Compra por proveedor.
·Fecha de entrega pactada.
·Lugar de entrega.
·Fecha de recepción en almacén en tránsito.
·Fecha de envío a bodega destino.
·Número de guía de remisión (guía de despacho).
·Fecha de ingreso a almacén final. | | | | 0 | | 87 | Dicho seguimiento deberá enviar un e-mail o fax al proveedor, días antes del vencimiento, recordándole la fecha de entrega (en un formato predeterminado). El sistema deberá ejecutar acciones de seguimiento parametrizadas por tiempo. | | | | 0 | | | SEGUIMIENTO DE IMPORTACIONES | | | | | | 88 | Posibilidad de tener un seguimiento de importación en el que se determine por cada Orden de Compra y embarques de ésta, toda la información de la cadena logística:
·Datos de O/C (número, fecha de emisión, forma de pago, condiciones de entrega).
·Fecha de entrega a agentes logísticos.
·Fecha de ingreso de la mercadería al almacén del embarcador.
·Fecha de inspección.
·Fecha de embarque de la mercadería
·Fecha en que arriba a puerto/aeropuerto de destino. | | | | 0 | | 89 | En el seguimiento se incluirá además los datos de todos los documentos de embarque:
·Número de factura comercial.
·Número de certificado de inspección.
·Número de packing list.
·Número de certificado de origen, otros certificados. | | | | 0 | | | CONSULTAS E INFORMES | | | | | | 102 | Debe permitir consultar el último precio de compra para un determinado artículo, en pesos y en dólares, asociado a un proveedor. | | | | 0 | | 103 | Debe permitir consultar la asociación de Orden de Compra a la factura del proveedor y al requerimiento de compra. | | | | 0 | | 104 | Debe ser capaz de listar las Órdenes de Compra por fecha de entrega por parte del proveedor. | | | | 0 | | 105 | Debe permitir consultar las Órdenes de Compra por:
·Usuario solicitante
· Unidad de Negocio y/o Centro de costo
·Costos por Proyectos | | | | 0 | | 106 | Debe permitir consultar las Órdenes de Compra de acuerdo a los estados definidos. Permitir el enlace con el presupuesto, costos de proyectos y su correspondiente calce con las facturas recibidas. | | | | 0 | | 107 | Debe permitir obtener reportes para controlar la distribución de los gastos de materiales en el costo de la obra, por cada Orden de Compra. | | | | 0 | | 108 | Debe permitir obtener un reporte con todas las existencias (Órdenes de Compra) pendientes de recepción física. | | | | 0 | | 109 | Debe permitir consultar las Órdenes de Compra recibidas y las pendientes de recepción. Poder abrirlas y ver el detalle de sus productos. | | | | 0 | | 110 | Debe permitir obtener reportes para soportar la cuadratura de balances de inventario físico con balances contables. | | | | 0 | | 111 | Debe emitir reportes de excepción cuando los precios de los productos se excedan de un cierto margen predefinido en relación con el precio anterior del producto. | | | | 0 | | 112 | Debe contemplar dentro del menú, stock por bodega y consolidado a una fecha determinada. | | | | 0 | | 113 | Debe otorgar reportes de desempeño del proveedor para las transacciones de recepción y rechazos, es decir, emitir un informe con la calificación del proveedor. | | | | 0 | | 114 | Debe proveer múltiples capacidades de clasificación para propósitos de reporte, como por ejemplo:
·Por código de ítem
·Por descripción,
·Fecha Vencimiento o días a fecha de vencimiento, | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 228 | | | | Puntaje Mínimo Exigido | | | 160 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 5 | | | | Ponderación del Módulo | | | 10 | | |

Ponderación proporcional en el módulo= (ponderación del módulo/puntaje máximo posible)*puntaje obtenido. | Resultado con DOS DECIMALES. |

RECEPCIÓN DE PRODUCTOS EN BODEGAS RECEPCIÓN DE PRODUCTOS EN BODEGAS | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | La recepción se registrará en referencia a una Orden de Compra de la que se obtendrá el detalle del ítem (Código, Descripción, Proveedor, Cantidad, Unidad de Medida) o una guía del proveedor, Inspección técnica. | | | | 0 | | 2 | El Sistema debe ser capaz de recibir por Pallet, Caja o Unidad, desglosando en cada caso las Subunidades de Embalaje de acuerdo a la Maestra de Productos Vigente. | | | | 0 | | 3 | El Sistema debe ser capaz de Importar y/o Recibir un Mensaje EDI/XML estandarizado de GUIA DE DESPACHO o FACTURA Electrónica enviado previamente por el proveedor y efectuar la recepción contra este documento previamente recibido. En caso de no contar con el documento, se procede a recibir con el método tradicional. | | | | 0 | | 4 | El Sistema debe ser capaz de actualizar su maestra de productos desde la maestra estandarizada GS1, que publica y mantiene GS1 (Chile) en conjunto con el ISP (Estandar5.sql). Donde vienen todos los productos Farmacéuticos e Insumos Médicos vigentes, además de su jerarquía de códigos. | | | | 0 | | 5 | Al recibir el material se debe seleccionar, empleando el sistema, el número de etiquetas requeridas para los artículos que no estén codificados. | | | | 0 | | 6 | Deberá tener la capacidad de imprimir las etiquetas con código de barras requeridas. La información que debe incluir la etiqueta es:
·Código de ítem
·Descripción del ítem.
·Número de parte.
·Unidad de medida
·Número de Lote
·Fecha de Vencimiento
·Ubicación física en almacenes
·Número de la Orden de Compra. | | | | 0 | | 7 | Debe generar comprobante de recepción de mercadería (hoja de entrada). | | | | 0 | | 8 | Debe efectuar la recepción de mercadería total o parcial. | | | | 0 | | 9 | Debe poder realizar el pareo de las recepciones v/s las Órdenes de Compra, en el momento de entrada de la mercadería (cantidad recibida). Posibilidad de generar márgenes de tolerancia en cantidades. | | | | 0 | | 10 | Debe permitir definir a priori protocolos o procedimientos de recepción de mercadería y bienes, según el tipo respectivo. Permitiendo aplicar estos protocolos y controlar la trazabilidad de ejecución del procedimiento. | | | | 0 | | 11 | Debe otorgar actualización automática de stock, provisión en contabilidad y cuentas a pagar. | | | | 0 | | 12 | Las discrepancias se pueden presentar por cualquiera de las siguientes formas:
·La cantidad física no coincide con la reflejada en la guía.
·La pieza física no coincide con la detallada en la guía.
·La cantidad registrada en la guía no coincide con la Orden de Compra y no estaban autorizadas las entregas parciales.
·La descripción de la guía no coincide con la Orden de Compra.
·La caja de embalaje estaba rota o abierta.
·El material se encontraba dañado. | | | | 0 | | 13 | Las discrepancias serán registradas por el operador responsable de la recepción al momento de realizar el ingreso. Se debe tener un link de la pantalla de recepción con la de discrepancias. | | | | 0 | | 14 | Al registrar la discrepancia se debe tener la opción de detener el pago de la factura que pudiese haber presentado el proveedor. | | | | 0 | | 15 | Se debe visualizar la siguiente información en pantalla:
·Número de ítem en Orden de Compra.
·Código del ítem.
·Número de parte.
·Descripción del material.
·Cantidad de compra.
·Cantidad recibida.
·Unidad de medida (de compra y almacenamiento). | | | | 0 | | 16 | El reporte de discrepancias debe ser impreso automáticamente al ser completado. Su consulta se realizará mediante selección de alguno de los siguientes criterios:
·Fecha
·Orden de Compra
·Autor de la discrepancia
·Código de ítem
·Número de guía y sus combinaciones. | | | | 0 | | 17 | PERMITIR ANULAR ACTA DE RECEPCIÓN. | | | | | | 18 | Generar aviso al usuario respecto de artículos con vencimiento a una fecha determinada, cuando ingresa al sistema. | | | | | | 19 | Permitir asignar saldo nulo a ítems de Orden de Compra | | | | | | 20 | Permitir consultar por Órdenes de Salida en base a criterios de búsqueda. | | | | | | 21 | PERMITIR INDICAR QUÉ PERSONA HARÁ UN DESPACHO A UN SERVICIO DETERMINADO. | | | | | | 22 | PERMITIR MANTENER PREPARADOS DE FARMACIA. | | | | | | 23 | Permitir modificar observaciones del acta de recepción. | | | | | | 24 | PERMITIR MODIFICAR OBSERVACIONES DE UNA ORDEN DE SALIDA. | | | | | | 25 | Permitir modificar observaciones de orden de compra nula. | | | | | | 26 | Permitir generar pedidos de compra a adquisiciones desde bodega (excepto Economato) | | | | | | 27 | Permitir generar pedidos de compra a adquisiciones desde bodega (sólo Economato) | | | | | | 28 | Permitir REDUCIR LA 'DEUDA' O 'CONSUMO' DE UN ARTÍCULO PARA UN SERVICIO. | | | | | | 29 | Permitir generar reporte de cargas de actas de recepción para un período de tiempo determinado. | | | | | | 30 | Permitir generar listado de artículos bajo punto de reposición. | | | | | | 31 | PERMITIR GENERAR REPORTE DE LISTA DE PRECIOS DE ARTÍCULOS PARA VENTA A PUBLICO. | | | | | | 32 | Permitir generar reporte de artículos sin movimiento. | | | | | | 33 | Permitir generar reporte de artículos con restricción de despacho a los servicios. | | | | | | 34 | Permitir generar reporte de artículos por bodegas. | | | | | | 35 | Permitir generar reporte de Artículo - Proveedor. | | | | | | 36 | Permitir generar reporte de artículos con una fecha de vencimiento determinada. | | | | | | 37 | Permitir generar reporte de artículos por servicio. | | | | | | 38 | Permitir generar reporte de compras de artículos. | | | | | | 39 | Permitir GENERAR REPORTE DE CAMBIOS DE PRECIOS MANUALES DE ARTÍCULOS. | | | | | | 40 | Permitir generar reporte de consumos mensuales de artículos. | | | | | | 41 | Permitir GENERAR REPORTES DE DESPACHOS DESDE ESTERILIZACIÓN. | | | | | | 42 | Permitir GENERAR REPORTES DE ENTRADAS - SALIDAS. | | | | | | 43 | PERMITIR GENERAR REPORTE DE EXIST. FI Y DEUDA FA | | | | | | 44 | Permitir generar reporte de informe técnico de artículos. | | | | | | 45 | Permitir generar reporte de movimientos de artículos (entradas-salidas) para una bodega o servicio. | | | | | | 46 | Permitir GENERAR REPORTE DE PREPARADOS DE FARMACIA. | | | | | | 47 | Permitir generar reporte de consumos (órdenes de compra) totalizados por proveedor. | | | | | | 48 | Permitir generar reporte de artículos bajo stock crítico. | | | | | | 49 | Permitir GENERAR REPORTE DE ARTÍCULOS QUE HAN SIDO ELIMINADOS DEL STOCK DE UN SERVICIO. | | | | | | | | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 98 | | | | Puntaje Mínimo Exigido | | | 69 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 2 | | | | Ponderación del Módulo | | | 3 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

BODEGA FARMACIA | | | | | | | N° | Funcionalidades | | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Inventario valorizado de stock, con indicación de lotes y fechas de vencimiento. Indicación de ubicación física. Uso de códigos EAN-128 y Datamatrix | | | | | 0 | | 2 | Registro de ingreso/ transferencia de productos entre dependencias propias y hacia/desde otras contabilidades de la Institución. Vinculación con Enfermería y Pabellón Quirúrgico | . | | | | 0 | | 3 | Registro de devoluciones. Actualización de stock.
Vinculación con admisión. Nota de crédito en cuenta corriente de paciente | | | | | 0 | | 4 | Generación de UNIDOSIS. Requiere etiquetado con código de barras. Uso de códigos EAN-128 y Datamatrix | | | | | 0 | | 5 | Capacidad para ingresar productos magistrales generados a partir de otros productos en existencia El producto debe estar registrado en el catálogo | . | | | | 0 | | 6 | Capacidad de impresión de etiquetas de código de barras y uso de dispositivos lectores de código de barras. Uso de códigos EAN-128 y Datamatrix | | | | | 0 | | 7 | Visualización de recetas pendientes de despacho. Vinculación con FCE, Enfermería, Pabellón Quirúrgico | | | | | 0 | | 8 | Manejo de farmacias o bodegas periféricas (o botiquines). Vinculación con módulos de enfermería, pabellón Quirúrgico, Urgencia | | | | | 0 | | 9 | Considerar bodegas periféricas a dispositivos Griffols y Omnicell Integración con Griffols y Onmicell | | | | | 0 | | 10 | Capacidad para consolidar las existencias de todas las bodegas, incluyendo periféricas y botiquines, para efectos de los cierres de periodos contables. Centralización automática del asiento | | | | | 0 | | 11 | Control de estupefacientes, psicotrópicos y drogas oncológicas. Vinculación de estas con el paciente, con el funcionario que despacha y con el médico que receta.
Registro auditable.
Cuadre de inventario diario. | | | | | 0 | | 12 | Posibilidad de vincular uso de medicamentos con patologías AUGE u otras según protocolos. | | | | | 0 | | 13 | Catálogo o Listado de productos en stock, por nombre genérico y comercial Vinculación con FCE.. | | | | | 0 | | 14 | El catálogo podrá contener productos QUE NO FORMAN parte del arsenal del Hospital. En estos casos, deberá indicarse esta condición en forma clara, advirtiendo que en caso de indicarse, el paciente deberá adquirirlo fuera del hospital. | | | | | 0 | | 15 | Alerta de vencimiento de productos en stock. | | | | | 0 | | 16 | Alerta por Stock mínimo y crítico. Punto de reposición. Generación automática de pedidos de reposición. Vinculación con Bodegas general o Abastecimientos, según corresponda. | | | | | 0 | | 17 | Despacho a pacientes hospitalizados, por carro o gavetero. Con las gavetas debidamente identificadas con código de barras. Agrupación de recetas por servicio y por carro, para su despacho simultáneo | . | | | | 0 | | 18 | Cargo automático de productos despachados, en cuenta del paciente Integración con “Cuentas de pacientes” | | | | | 0 | | 19 | Actualización automática de inventarios. | | | | | 0 | | 20 | En la búsqueda o consulta por un producto debe indicar la existencia en cada una de las bodegas central y periféricas, con indicación de fecha de vencimiento | | | | | 0 | | 21 | Generar reportes múltiples predefinidos, tales como detalle de consumo de psicotrópicos, drogas oncológicas y antimicrobianas. | | | | | 0 | | 22 | Permitir la generación de reportes nuevos, utilizando la herramienta de reportes | | | | | 0 | | 23 | Trasferencia de productos entre bodegas | | | | | 0 | | 24 | Transferencia de bienes entre instituciones. (Ej. Centro Médico Viña del Mar) Implica salida de activo (pseudo venta a valor contable) | | | | | | | | | | | | | | | | TOTAL PUNTOS | | 0 | 0 | 0 | | | | | | | | | | | | | | | | | | | | Puntaje Máximo Posible | | 48 | | | | Puntaje Minimo Exigido | | 34 | | | | Máximo ítem "No Cumple ni será desarrollado" | | 1 | | | | Ponderación del Módulo | | 3 | | | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

EXISTENCIAS | | | | | | | N° | Funcionalidades | | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Capacidad para generar un catalogo de productos agrupados por familias, tipo, grupos y subgrupos, definiendo para cada uno de ellos la unidad de medida. | | | | | 0 | | 2 | Capacidad para vincular los productos a una orden de compra y factura, con definición del precio unitario | | | | | 0 | | 3 | Capacidad para asociar lotes de productos con fecha de caducidad | | | | | 0 | | 4 | Capacidad para asociar a cada lote de compra una ubicación en la estantería | | | | | 0 | | 5 | Capacidad para operar con lectores de código de barras, tanto al ingreso de productos como a despacho por venta o consumo. | | | | | 0 | | 6 | Capacidad para generar e imprimir etiquetas con código de barras bajo el estándar GS1/EAN | | | | | 0 | | 7 | Capacidad para generar procesos de búsqueda a partir de diferentes criterios | | | | | 0 | | 8 | Capacidad para administrar múltiples bodegas y consolidar las existencias. | | | | | 0 | | 9 | definición de stock critico y punto de reposición | | | | | 0 | | 10 | Traspaso de productos entre bodegas | | | | | 0 | | 11 | Capacidad para administrar productos en consignación | | | | | 0 | | 12 | Impresión de listado de productos con indicación de su ubicación para efectos de inventario físico | | | | | 0 | | 13 | Capacidad para efectuar ajustes por mermas, pérdidas y caducidad de productos. | | | | | 0 | | 14 | Administración de productos en transito, en calidad de préstamo y en calidad de anticipo a cuenta de compras pendientes o en proceso. | | | | | 0 | | 15 | Capacidad para generar códigos que representen un conjunto de productos que se venden o consumen en forma complementaria. Ejemplo: Kit de aseo de paciente. | | | | | 0 | | 16 | Posibilidad de generar nuevos productos a partir de productos existentes. Ej. Preparaciones Magistrales en Farmacia, preparación de alimentación enteral o parenteral. | | | | | 0 | | 17 | Capacidad para generar un listado de precios de costo y mas de un valor de precio de venta, según tipo de cliente | | | | | 0 | | 18 | Valorización de existencia por precio de compra, según criterio contable de valorización. (Ej.: precio de reposición. Precio promedio ponderado) | | | | | 0 | | 19 | Valorización de ventas a precios convencionales, que incluyen costo de transacción y margen de utilidad. | | | | | 0 | | 20 | Administrar pedidos pendientes de despacho por falta de stock o de despachos parciales | | | | | 0 | | 21 | Capacidad para anular pedidos vinculados a pacientes, al momento de generarse el alta del paciente. | | | | | 0 | | 22 | Administracion de multiples bodegas | | | | | 0 | | 23 | Traspaso de bienes entre bodegas o instituciones | | | | | 0 | | 24 | Capacidad para Ejecutar automáticamente la consolidación de artículos del maestro (catálogo) cuando se detecten duplicidades. | | | | | 0 | | 25 | Capacidad para Ingresos y cambios masivos a la información del maestro de artículos (catálogo). | | | | | 0 | | 26 | Búsqueda en línea por múltiples conceptos, sin requerir necesariamente el código del artículo. | | | | | 0 | | | | | | | | | | | TOTAL PUNTOS | | 0 | 0 | 0 | | | | | | | | | | | | | | | | | | | | | | | | | | | | Puntaje Máximo Posible | | 52 | | | | Puntaje Mínimo Exigido | | 35 | | | | Máximo ítem "No Cumple ni será desarrollado" | | 1 | | | | Ponderación del Módulo | | | 3 | | | | | | | | | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

GESTIÓN DE CATÁLOGOS | GESTION DE CATALOGOS | | | | | | | N° | Funcionalidades | | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | El HOSCAR requiere un catálogo de materiales depurado, el cual será la base del catálogo en la aplicación. La Aplicación debe ser versátil en sus consultas para permitir la identificación rápida de los materiales del catálogo a cualquier usuario con el nivel de entrenamiento mínimo para esa función. | | | | | 0 | | 2 | En el catálogo de materiales se deben registrar todos aquellos materiales que tienen una política de stock definida y los activos fijos definidos por la Empresa. | | | | | 0 | | 3 | Debe proveer múltiples capacidades de clasificación para propósitos de reporte, como por ejemplo:
· Por código de ítem
· Por descripción, etc. | | | | | 0 | | 4 | Para catalogar un material se debe tener la opción de registrar la siguiente información:
· Código Interno
. Código EAN-13
. Lote de Fabricación
. Fecha de Vencimiento
· Grupo y Clase.
· Descripción corta, en español e inglés.
· Descripción extendida, en español e inglés
· Coloquiales.
· Unidad de medida.
· Peso y Volumen.
· Clasificaciones, tales como: Capital, Disponible, Inactivo, Administrado por Proveedor, Consignación, Sólo a Pedido.
· Tipo específico de material, tales como: Medicamento, Insumo, Consumible, Suministro y otros.
· Fabricante: más de uno, indicando el preferido.
· Fecha de catalogación/creación
· Información del ítem: Disponible, Inactivo, Reemplazado, homologado, etc.
· Fotos del ítem | | | | | 0 | | 5 | Debe permitir el ingreso (importación) de un maestro de productos de acuerdo a definiciones claramente establecidas y delimitadas, eliminando la posibilidad de ingresos de un mismo artículo con distinto código y viceversa. Esta Maestra debe Incorporar la relación SSCC (código de PALLET) - DUN-14 (código de caja) - EAN-13 (código producto) - EAN-13 (Dosis Unitaria) | | | | | 0 | | 6 | Permitir clasificación según normativa FONASA para artículos (fármacos e insumos), tal que éstos, dependiendo de su utilización, puedan se cobrados al paciente por venta directa o a través de la prestación | | | | | 0 | | 7 | Permitir asignar varias localizaciones a un artículo en cada almacén en un código de 5 caracteres alfanumérico. Por ejemplo, XYZ KC, donde:
• XYZ = Corresponde a la ubicación física en el almacén.
Puede ser un código plano o inteligente, por ejemplo, pasillo-estante-altura. | | | | | 0 | | | MÉTODO DE INGRESO EN EL CATÁLOGO | | | | | | | 8 | Manual: para la incorporación de nuevos ítems al catálogo y para las actualizaciones de cualquier registro anterior. | | | | | 0 | | 9 | Electrónico (XML o EDIFACT): para ingresar información parcial que es proveída por el fabricante a través de catálogos electrónicos o mensajes, así como para transferir información de un formato en medio magnético al sistema. | | | | | 0 | | 10 | Para registrar un ítem, el sistema deberá indicar si éste ya existe en el catálogo, mediante búsqueda automática por código EAN-13, fabricante o descripción. Esta acción deberá permitir el bloqueo o cancelación del ingreso de un nuevo ítem al catálogo. | | | | | 0 | | 11 | Las consultas del Inventario se deben realizar de acuerdo al código EAN-13, descripción, código interno, coloquiales, fabricantes, grupo, clase y sus combinaciones. | | | | | 0 | | 12 | Debe manejar códigos alternativos de reemplazo para cada artículo (el mismo artículo, pero de distinto proveedor, tiene código distinto). Así cuando se esté requiriendo un determinado artículo, el sistema debe ser capaz de desplegar en pantalla los códigos de artículos alternativos. | | | | | 0 | | 13 | Debe permitir la asignación a cada ítem de: cuentas contables y subítem de gasto. | | | | | 0 | | 14 | Debe permitir clasificar las existencias en importadas y nacionales. | | | | | 0 | | 15 | Debe permitir la identificación de un ítem como sujeto a gestión de stock o crítico. | | | | | 0 | | 16 | Debe permitir el ingreso y modificación de especificaciones físicas y técnicas de los ítems. | | | | | 0 | | 17 | La reposición de material se realizará a través de una recomendación de compra suministrada por el sistema, basada en los siguientes parámetros:
· Stock disponible.
· Cantidad en tránsito.
· Historia de consumo.
· Algoritmos de reposición.
· Tiempo de Aprovisionamiento (Lead Time).
· Paquete Estándar.
· Precio unitario.
· Nivel de servicio.
· Criticidad.
· Punto de reorden.
· Cantidad de reorden.
· Costo de compra.
· Reservas realizadas. | | | | | 0 | | 18 | Debe permitir el manejo de diferentes unidades de medida de los ítems (compra, venta, stock, almacenaje, etc.). | | | | | 0 | | 19 | Debe facilitar el manejo de factores de conversión entre unidades. | | | | | 0 | | 20 | Debe permitir la definición de múltiples estados del stock por ítem, ya sea real o virtual (almacenado, reservado, control de calidad, pedido, en tránsito, dañado, etc.). | | | | | 0 | | 21 | Definir bodegas (o ubicaciones) que sólo sean visibles en el sistema para un grupo definido de usuarios. | | | | | 0 | | 22 | Generar alertas, tales como:
• Alerta 1: Artículos próximos a fecha de vencimiento o expiración.
• Alerta 2: Artículos en su Punto de Pedido.
• Otras. | | | | | 0 | | | | | | | | | | | | | | | | | | | TRANSACCIONES | | | | | | | 23 | Debe mantener el stock en tiempo real. | | | | | 0 | | 24 | Registro de los funcionarios autorizados y responsables de la reposición de materiales por código de Centro de Costo, bodegas, artículo o grupos. | | | | | 0 | | 25 | Simulación de REDISTRIBUCIÓN de artículos entre diferentes bodegas de forma de igualar los PUNTOS DE PEDIDO de artículos de un mismo proveedor (algoritmo a ser agregado a pedido). Por ejemplo: Control de existencia on line y capacidad de proyectar movimientos entre las bodegas. | | | | | 0 | | 26 | Debe brindar la facilidad de llevar ubicaciones físicas. | | | | | 0 | | 27 | Debe permitir la impresión automática de etiquetas de identificación de los productos. | | | | | 0 | | 28 | Debe permitir la proyección de stock (planificación, compras, etc.), mediante listados de compras por períodos de tiempo, de tal manera de identificar cuándo y cuánto comprar. | | | | | 0 | | 29 | Debe permitir el ingreso de los documentos de respaldo con los que se recepciona los artículos, ya sea, Factura, Guía de Despacho, etc. | | | | | 0 | | 30 | Por cada documento necesario, el sistema debe posibilitar la incorporación de los siguientes conceptos mínimos:
· N° Documento (factura, guía)
· Tipo
· Proveedor
· Código artículo
· Detalle (descripción, dimensiones, etc.)
· Valor por ítem
· Unidades por ítem
· Número de Orden de Compra | | | | | 0 | | 31 | Debe mantener actualizado el saldo pendiente de cada documento. | | | | | 0 | | 32 | Debe valorizar las recepciones en forma en línea (on line), en base a precios especificados en la Orden de Compra. | | | | | 0 | | 33 | Debe permitir realizar correcciones a los ítems recibidos, cuando el conteo físico no coincida con lo informado en la factura del proveedor. Las correcciones sólo podrán ser efectuadas por un usuario con la atribución correspondiente (perfil). Esto implica que el usuario pueda ingresar la factura correspondiente al Sistema, a pesar del problema presentado, pero el Sistema debe ser capaz de registrar y notificar al usuario la exigencia al proveedor de la entrega de una Nota de Crédito por la diferencia. | | | | | 0 | | 34 | Debe permitir la diferenciación en la recepción de productos sujetos a control de calidad. | | | | | 0 | | 35 | Debe ser capaz de modificar, en forma automática, el estado de las Solicitudes a Bodega cuando se efectúe la recepción física de la mercadería, cambiándose de “mercadería en tránsito” a al estado posterior, por ejemplo: “recibido en bodega”. | | | | | 0 | | 36 | Debe calcular el tiempo que demora la bodega en abastecer un determinado artículo al solicitante. | | | | | 0 | | 37 | Debe permitir recepcionar en la misma transacción productos comprados en el exterior (importados) y en el mercado local (nacionales). | | | | | 0 | | 38 | Debe permitir un fácil acceso a información de los costos al momento de solicitar los productos a bodega, es decir, cuando se crea una solicitud de Productos | | | | | 0 | | 39 | Debe permitir incorporar y administrar el estado de productos reservados para centros de costos que los solicitan, quedando no disponible para los demás. | | | | | 0 | | 40 | La salida de productos debe ser apoyada por un documento impreso que especifique el detalle de los productos y el centro de costo al que fue cargado. | | | | | 0 | | 41 | La creación de un vale puede originar la creación automática de una requisición o ser incluido en las recomendaciones de compra, si la disponibilidad del material es menor a la cantidad requerida. | | | | | 0 | | 42 | Se deben proveer los medios de control para que la autorización de despacho interno de determinados tipos de ítems se restrinja a usuarios autorizados. | | | | | 0 | | 43 | La búsqueda del vale se debe realizar por cualquiera de las siguientes opciones:
· Número correlativo de vale
· Usuario.
· Código de ítem
· Centro de costo
· Autorizador | | | | | 0 | | 44 | Se debe tener la opción de despachar un vale en forma completa o parcial en una transacción única. Asimismo, se debe tener la opción de despachar parcialmente la cantidad requerida de un ítem, si es que está autorizada por el usuario. | | | | | 0 | | 45 | Despachado el vale, se deben actualizar automáticamente los stocks y valor de inventario, registrándose además de la información del ítem, personal (despachador) que realiza el despacho. | | | | | 0 | | 46 | Se debe disponer la facilidad de modificación, cancelación o anulación de vales, en forma parcial o total. | | | | | 0 | | 47 | El sistema debe incluir la posibilidad de integración de su funcionalidad de despacho de materiales con un sistema de código de barras. | | | | | 0 | | 48 | Debe asignar números secuenciales automáticos a los documentos emitidos. | | | | | 0 | | 49 | La fecha de emisión de la solicitud de materiales debe ser por defecto. No se debe permitir su modificación. | | | | | 0 | | 50 | Debe permitir generar contabilizaciones por centro de costos, al momento de salir de bodega los materiales e insumos. | | | | | 0 | | 51 | Debe permitir la generación de provisión, si corresponde, a ítems recibidos y no facturados. | | | | | 0 | | 52 | El acceso a los centros de costos a ser imputados debe depender del usuario en cuestión, por lo que un usuario no debe poder acceder a centros de costos ajenos a su función. | | | | | 0 | | 53 | Debe incluir un módulo de “custodia” de artículos, el cual permita ingresar artículos con valor comercial elevado o de acceso restringido. | | | | | 0 | | 54 | El acceso al módulo de custodia debe estar restringido. | | | | | 0 | | 55 | Debe impedir el registro de guías de despacho con número duplicado. | | | | | 0 | | 56 | Debe restringir la modificación de los datos provenientes del módulo de compras. | | | | | 0 | | 57 | Debe proveer la facilidad para recibir ítems devueltos por los Usuarios y/o Servicios, actualizando saldos de inventario e incorporación de razones de devolución e identificarlos con un código de transacción diferente. La transacción debe generar un Comprobante de Devolución. | | | | | 0 | | 58 | Debe poder discriminar entre los diferentes requerimientos de manera de asignar el producto de acuerdo al grado de urgencia de la solicitud (esta urgencia se mide por criterio a definir). | | | | | 0 | | 59 | Debe permitir registrar como pendientes aquellas partes que no pueden ser proveídas por el stock disponible, e ir almacenando los pedidos pendientes en un archivo especial. | | | | | 0 | | 60 | Debe proveer la facilidad de registrar transferencias entre bodegas, actualizando saldo de inventarios tanto para la bodega que recibe como para la que envía. Es decir, rebajar automáticamente de la bodega que envía e incrementar los saldos de la bodega que recibe, una vez recibidos los productos en ésta. | | | | | 0 | | 61 | Debe permitir identificar un dueño virtual, en caso que existiese. | | | | | 0 | | 62 | Devolución a proveedor de material ingresado a stock. | | | | | 0 | | 63 | El cálculo de la “rotación” que permita una mejor definición para calcular su nivel de existencia de seguridad. | | | | | 0 | | 64 | Devolución a proveedor por material rechazado por la inspección técnica | | | | | 0 | | | CONTROL DE EXISTENCIAS | | | | | | | 65 | Debe permitir la posibilidad de tomar el inventario a través de lectores de códigos de barra, o manualmente y que el sistema en forma automática efectúe el cotejo determinando diferencias. | | | | | 0 | | 66 | Debe proveer la facilidad de generar ajustes por conteo físico, tanto en unidades como en los valores totales. | | | | | 0 | | 67 | Debe permitir definir y controlar inventarios multi-bodegas. | | | | | 0 | | 68 | El fundamento del inventario es reflejar la exactitud de los stocks físicos en relación con los stocks reflejados en el sistema. Para esto, el sistema debe permitir la realización de inventarios periódicos (cíclicos) y totales de los ítems del almacén, así como los ajustes que se deben efectuar por diferencias detectadas. | | | | | 0 | | 69 | La aplicación debe permitir la posibilidad de efectuar ajustes por diferencia de precio. | | | | | 0 | | | REPORTES | | | | | | | 70 | Las listas de ítems para inventariar deben considerar los siguientes campos: | | | | | 0 | | | · Código ítem. | | | | | | | | · Descripción del ítem. | | | | | | | | · Número de parte. | | | | | | | | · Unidad de medida. | | | | | | | | · Ubicaciones físicas. | | | | | | | | · Stock. (opcional). | | | | | | | | · Cantidad inventariada. | | | | | | | | · Fecha de emisión del reporte. | | | | | | | 71 | La relación de ítems con discrepancia final considerará, además de la información anterior, el costo total de los ajustes a realizar (tanto por discrepancia positiva como negativa). | | | | | 0 | | 72 | Debe permitir consultar las solicitudes de materiales por: | | | | | 0 | | | · Usuario solicitante | | | | | | | | · Centro de costo | | | | | | | 73 | Debe permitir consultar las solicitudes de materiales de acuerdo a los estados definidos: | | | | | 0 | | | · Solicitud en tránsito. | | | | | | | | · Material entregado. | | | | | | | | · Material en tránsito. | | | | | | | 74 | Debe permitir emitir informes de excepción para: | | | | | 0 | | | · Solicitudes no aprobadas. | | | | | | | | · Solicitudes en tránsito. | | | | | | | | · Entregas en tránsito. | | | | | | | 75 | Consulta on-line del maestro de proveedores, que a lo menos contenga la siguiente información: | | | | | 0 | | | · RUT del proveedor. | | | | | | | | · Nombre del proveedor. | | | | | | | | · Dirección. | | | | | | | | · Persona de contacto. | | | | | | | | · Teléfono. | | | | | | | | · Fax. | | | | | | | | · Dirección Internet. | | | | | | | | · Rubro de productos. | | | | | | | | · Descuentos. | | | | | | | | · Fechas y días de pago. | | | | | | | | · Calificación del proveedor (entrega adecuada, entrega fuera de plazo, productos defectuosos). | | | | | | | 76 | Debe proveer múltiples capacidades de clasificación para propósitos de reporte, como por ejemplo: | | | | | 0 | | | · Por código de ítem. | | | | | | | | · Por descripción. | | | | | | | | · Etc. | | | | | | | 77 | Debe manejar distintos criterios de búsqueda de la información a nivel de campos numéricos y alfabéticos, y de datos codificados y descriptivos | | | | | 0 | | 78 | Permitir consultar las Órdenes de Compra recibidas y pendientes de recepción. Poder abrirlas y ver el detalle de sus productos. | | | | | 0 | | 79 | Debe permitir conocer el estado actual de los productos almacenados en bodega, tanto en línea como consultas a través de reportes, con las siguientes magnitudes entre otras: | | | | | 0 | | | · Cantidad disponible. | | | | | | | | · Cantidad comprometida. | | | | | | | 80 | Debe permitir obtener listados de los productos almacenados, por ubicación para efectuar la toma de inventario físico. Las que deben contener, a lo menos: | | | | | 0 | | | · Ítem. | | | | | | | | · Ubicación. | | | | | | | | · Código de producto. | | | | | | | | · Lote. | | | | | | | | · Descripción. | | | | | | | | · Unidad de medida. | | | | | | | 81 | El sistema debe entregar facilidades para hacer inventarios, por ejemplo: | | | | | 0 | | | · Emitir listados con cantidades y sin cantidades. | | | | | | | | · Ingresar criterios de inventarios para poder hacerlos selectivos. | | | | | | | | · Debe tener la opción de solicitar lo que se quiere inventariar, el sistema hace la búsqueda e imprime el listado de acuerdo a criterios pedidos y ordenados por localización. | | | | | | | 82 | Debe entregar listado de verificación con todos los ítems contenidos en la factura y un espacio en blanco para inventariar los productos recibidos. El listado de verificación debe estar ordenado por localización física y por artículo. | | | | | 0 | | 83 | Debe permitir calcular en forma automática y reportar la rotación de inventario, de acuerdo a parámetros definidos por Usuarios | | | | | 0 | | 84 | Debe permitir obtener reportes o consultas para identificar tipos especiales de inventario, tales como: stock negativo, con poco movimiento y otros que le interese definir. | | | | | 0 | | 85 | Debe proveer reportes que identifican el uso promedio del ítem por mes, trimestre y periodo definido. | | | | | 0 | | 86 | Debe permitir la impresión de un código de barras con datos significativos para el control de existencias. | | | | | 0 | | 87 | Debe permitir la consulta diaria y en línea de las Solicitudes de pedido pendientes de despacho, diferenciadas por: | | | | | | | | · Pendientes de despacho con stock. | | | | | | | | · Pendientes de despacho sin stock. | | | | | | | 82 | Debe permitir la consulta a nivel de detalle de las solicitudes de pedido. | | | | | 0 | | 83 | Debe permitir agrupar las solicitudes para un mismo usuario y/o centro de costo. | | | | | 0 | | 84 | Debe permitir consultar los saldos de las solicitudes: | | | | | 0 | | | · Número de Solicitud. | | | | | | | | · Cantidad solicitada. | | | | | | | | · Total despachado. | | | | | | | | · Fecha del despacho. | | | | | | | | · Unidades pendientes de despacho. | | | | | | | 85 | Debe brindar facilidades de consulta de los datos del maestro de productos. | | | | | | | 87 | Debe proveer múltiples capacidades de clasificación para propósitos de reporte, como por ejemplo: | | | | | 0 | | | · Por número de partes | | | | | | | | · Por modelo | | | | | | | 88 | Cualquier modificación de los datos de los archivos debe quedar registrado, para efectos de auditoria, especialmente todo lo relacionado con entradas y salidas de bodega y modificaciones en la bases de datos. | | | | | 0 | | 89 | Debe generar reportes por centros de costo señalando los costos involucrados en las solicitudes, para un determinado período. | | | | | 0 | | 90 | Debe proveer la facilidad de informar al Jefe del centro de costo respectivo, el cargo efectuado. | | | | | 0 | | | | | | | | | | | TOTAL PUNTOS | | 0 | 0 | 0 | | | | | | | | | | | | Puntaje Máximo Posible | | 180 | | | | Puntaje Minimo Exigido | | 126 | | | | Máximo ítem "No Cumple ni será desarrollado" | | 4 | | | | Ponderación del Módulo | | 4 | | | | | | | | | | | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. | CONTROL DEMANDA | CONTROL DEMANDA | | | | | | | N° | Funcionalidades | | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Guardar las cantidades y fechas de todas las salidas de un artículo de existencia y mantener actualizado el parámetro “Rotación del Artículo”. | | | | | 0 | | 2 | Utilizar algoritmos de cálculo para obtener la estimación de días que faltan para el Punto de Pedido. | | | | | 0 | | 3 | Cada Artículo debe tener asociada una categoría y una condición a saber. | | | | | 0 | | | Ejemplos de categorías: | | | | | | | | A = DISPONIBLE | | | | | | | | B = EN RESERVA | | | | | | | | C = EN TRANSITO. | | | | | | | | Ejemplos de condición (2° Nivel): | | | | | | | | 1 = NUEVO | | | | | | | | 2 = REPARADO | | | | | | | | 3 = DEFECTUOSO | | | | | | | | 4 = VENCIDO | | | | | | | | 5 = OBSOLETO. | | | | | | | 4 | La categoría y la condición de un artículo deben ser mostradas en las consultas de Artículos en Existencia por Bodega. Por ejemplo: | | | | | 0 | | | • Artículo XXX | | | | | | | | • Total en Existencia 100 | | | | | | | | • Disponibles 90 | | | | | | | | • Reserva de solicitudes del área clínica y servicios 10 | | | | | | | | • De los 90 disponibles, nuevos 80, reparados 8, vencidos 1, obsoletos 1. | | | | | | | 5 | Una Orden de Compra no recibida marca la cantidad pedida como Categoría en Transito y cuando esa orden ingrese a existencias lo cambiará a Categoría Disponible. | | | | | 0 | | 6 | El usuario Control de Demanda puede generar automáticamente las Orden es de Compra para reposición de Existencias, las cuales pueden fraccionarse por Proveedor y por artículos, dependiendo de la naturaleza del artículo (por ejemplo: medicamentos Psicotrópicos, Refrigerados y Otros). | | | | | 0 | | 7 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. | | | | | 0 | | | | | | | | | | | TOTAL PUNTOS | | 0 | 0 | 0 | | | | | | | | | | | | Puntaje Máximo Posible | | 14 | | | | Puntaje Minimo Exigido | | 8 | | | | Máximo ítem "No Cumple ni será desarrollado" | | 0 | | | | Ponderación del Módulo | | 3 | | | | | | | | | | | Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. | ACTIVOS FIJOS ACTIVOS FIJO | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Activo Fijo debe operar para cada centro de costos y centros de responsabilidad y/o servicios. | | | | 0 | | 2 | Ejecutar en forma automática los procesos de cálculo de depreciación y corrección monetaria de los activos registrados en el Auxiliar. | | | | 0 | | 3 | Permitir la definición del o los establecimiento de salud en la cual será utilizado el Activo Fijo, y registrar el año y mes de inicio, la periodicidad en que será calculada la depreciación (mensual o anual), y el tipo de comprobante contable que será generado con estos valores para ser enviados en línea a Contabilidad previa aprobación. | | | | 0 | | 4 | Permitir la definición, de las cuentas que serán utilizadas en Contabilidad para el registro de ganancia o pérdida por venta, utilidad por revalorización, corrección monetaria y depreciación acumulada. | | | | 0 | | 5 | La primera clasificación de los activos es por TIPO. Esta clasificación apunta a definir el tratamiento contable que se aplicará sobre ese activo. Según Normativa de la Contraloría Gral. De la República. Dejar asociado el tratamiento internacional (IFRS), para cambios de procedimiento en el mediano plazo. | | | | 0 | | 6 | Para cada tipo de activo se deben definir todas sus cuentas asociadas: de registro del bien, de registro de sus mejoras, de su depreciación y de su corrección monetaria. | | | | 0 | | 7 | Mantener una tabla con parámetros necesarios para efectuar el cálculo de la corrección monetaria según Normativa de la Contraloría Gral. De la República. | | | | 0 | | 8 | La carpeta de ingreso registra su clasificación Tipo-Grupo-Subgrupo, se asocia a un Centro de Costo, Centro de Responsabilidad y a un Proyecto Presupuestario. Se registran todos los datos de la Orden de Compra, proveedor, valores, fechas, factura y se define su vida útil para efectos de la depreciación. | | | | 0 | | 9 | La carpeta Ubicación registra la ubicación física en la jerarquía Unidad-Sección aparte de la dirección de la ubicación y el usuario que será el responsable de ese activo. | | | | 0 | | 10 | Permitir identificar/Administrar Activos Puntuales Ej.: Equipos, Motores, Ascensores, etc. | | | | 0 | | 11 | Permitir manejar las estructuras de los Activos en forma conjunta y/o individual acorde con una estructura lógica de agrupación. | | | | 0 | | 12 | Permitir mirar gráficamente la Jerarquía de los Activos y sus componentes. | | | | 0 | | 13 | Permitir llevar el historial técnico de los Activos y Componentes a través del tiempo. | | | | 0 | | 14 | Permitir la asignación de operaciones de mantenimiento a los Activos con el fin de poseer la totalidad de actividades factibles de realizar en el activo. Estas listas se deben actualizar automáticamente cuando se actualice el catalogo de operaciones. | | | | 0 | | 15 | Permitir clasificar y agrupar los Activos según clases y características definidas según Normativa de la Contraloría Gral. De la República. | | | | 0 | | 16 | Permitir asociar fichas técnicas configurables a Activos y utilizar sus campos como criterios de búsqueda. | | | | 0 | | 17 | Permitir asociar planos a Activos (como adjuntos) | | | | 0 | | 18 | Permitir la asignación de operaciones de mantenimiento a los Activos con el fin de poseer la totalidad de actividades factibles de realizar en el activo. Estas listas se deben actualizar automáticamente cuando se actualice el catalogo de operaciones. | | | | 0 | | 19 | Permitir relacionar el rol o código de activo al inventario de activos. | | | | 0 | | 20 | Permitir llevar el control de emergencias, puestas fuera de funcionamiento y puesta en funcionamiento de los Activos generando los datos de: tiempo de reparación, tiempo entre fallas, tiempo de operación, etc. | | | | 0 | | 21 | Permitir extraer información en línea de los Activos, a través de parámetros de búsqueda previamente elaborados. | | | | 0 | | 22 | Permitir que el activo se pueda dar de baja del inventario. | | | | 0 | | 23 | Permitir asociar cualquier documento al registro del Activo. Ej. fotos, videos documentos, planos, etc. | | | | 0 | | 22 | Permitir la definición de una estructura de componentes al Activo o al grupo de Activos. | | | | | | 23 | Facilidad para extraer información a través de reportes estándares o diseñados por el usuario. | | | | | | 24 | Permitir hacer traslados o movimientos de bienes desde una dependencia física, centro de costo o centro de responsabilidad. | | | | 0 | | 25 | Permitir una operación conjunta e integrada entre ubicaciones físicas, centros de responsabilidad y centros de costo. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | | | | | | | | Puntaje Máximo Posible | | | 50 | 50.0 | | | Puntaje Mínimo Exigido | | | 35 | 20.0 | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 1 | 1.0 | | | Ponderación del Módulo | | | 6 | 6.0 | | *

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

Gestión de Mantención de Equipos y Maquinarias Gestión de Mantención de Equipos y Maquinaria. | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | | ADMINISTRACIÓN DE EQUIPOS Y MAQUINARIAS | | | | | | 1 | Permitir identificar/Administrar Equipos y Maquinarias | | | | 0 | | 2 | Permitir manejar las estructuras de los Equipos en forma conjunta y/o individual acorde con una estructura lógica de agrupación. | | | | 0 | | 3 | Permitir mirar gráficamente la Jerarquía de los Equipos y sus componentes. | | | | 0 | | 4 | Permitir llevar el historial técnico de los Equipos y Componentes a través del tiempo. | | | | 0 | | 5 | Permitir clasificar y agrupar los Equipos según clases y características definidas por el usuario.En especial considerar la incorporación de la clasificación ECRI para equipamiento médico. | | | | 0 | | 6 | Permitir asociar fichas técnicas configurables a Equipos y utilizar sus campos como criterios de búsqueda. | | | | 0 | | 7 | Permitir la asignación de lista de materiales a equipos con el fin de poseer la lista detallada de repuestos de ese Equipo. Estas listas se deben actualizar automáticamente cuando se actualice el catalogo de Repuestos. | | | | 0 | | 8 | Permitir relacionar el código de activo fijo al Inventario de equipos. | | | | 0 | | 9 | Permitir llevar el control de paradas y puesta en funcionamiento de los Equipos generando los datos de: tiempo de reparación, tiempo entre fallas, tiempo de operación, etc. | | | | 0 | | 10 | Permitir extraer información en línea de los Equipos, a través de parámetros de búsqueda previamente elaborados. | | | | 0 | | 11 | Permitir hacer el seguimiento, cuando el equipo esta en garantía del Proveedor cuando se trate de un equipo nuevo o bien cuando se realice una reparación por parte de terceros. | | | | 0 | | 12 | Permitir que el equipo se pueda dar de baja del Inventario de Activo Fijo. | | | | 0 | | 13 | Permitir que se pueda cambiar de ubicación al equipo, en cualquier momento sin perder su historial y seguir con el seguimiento de costos. | | | | 0 | | 14 | Permitir asociar cualquier documento al registro del equipo. Ej. fotos, videos documentos, planos, etc. | | | | 0 | | 15 | Permitir la definición de una estructura de componentes al equipo o al grupo de equipos. | | | | 0 | | 16 | Permitir agrupar equipos por tipo de modelo, fabricante, etc. | | | | 0 | | 17 | Permitir Numerar Equipos y Componentes con números alternos y con números estructurados Ej.: Tag Number, Coloquiales, Activo Fijo, etc. | | | | 0 | | 18 | Permitir manejar y controlar el mantenimiento y la administración del equipo rodante tales como ambulancias, horquillas, de tal manera de llevar un seguimiento de costos de reparaciones, consumos de combustibles, lubricantes, repuestos, distancias recorridas, horómetro, etc. | | | | 0 | | 19 | Facilidad para extraer información a través de reportes estándares o diseñados por el usuario. | | | | 0 | | | ADMINISTRACIÓN DE ÓRDENES DE TRABAJO (OT) | | | | | | 20 | Permitir la generación de Solicitudes de Mantenimiento como etapa previa a la creación de las Órdenes de Trabajo. | | | | 0 | | 21 | El sistema debe permitir Solicitar trabajos de la siguiente manera: | | | | | | | Registro del originador, Código de fallas (ruido, fuga, vibración, temperatura, aflojamiento, desgaste normal, desgaste anormal, Mantenimiento Preventivo no realizado, etc.) Código y ubicación del equipo Fecha del evento, turno y hora. | | | | 0 | | 22 | Registrar la Codificación de falla, Reporte de análisis de fallas (repetitivas, por turno, no comunes, por componente, por supervisor) Tiempo promedio entre fallas TPEF, Tiempo promedio por reparación TPPR, Confiabilidad, Reporte de cierre de OT. | | | | 0 | | 23 | Permitir la creación de Órdenes de trabajo, a partir de la Solicitud de Mantenimiento. | | | | 0 | | 24 | Permitir consultar desde una “OT” todas las Solicitudes de Mantenimiento asociadas a ella. | | | | 0 | | 25 | Permitir la asignación de una o varias Solicitudes de Mantenimiento a una Orden de Trabajo. | | | | 0 | | 26 | Permitir la creación de “OTs” para sistemas, equipos, componentes. | | | | 0 | | 27 | El sistema debe otorgar permisos de anulación de una Órdenes de trabajo en forma manual. | | | | 0 | | 28 | El sistema debe poder registrar el motivo de la anulación. | | | | 0 | | 29 | Permitir la creación de OTs de acuerdo al tipo de presupuesto (presupuesto corriente, reparación mayor activable, y cuentas contables. | | | | 0 | | 30 | Para el registro de la descripción, el sistema debe poder debe disponer de un campo “comentarios” que permita al registrar los comentarios y observaciones relacionadas con la reparación/mantención que se está solicitando. Debe permitir el ingreso de información suficiente para entender la naturaleza de las actividades, complejidad, etc. | | | | 0 | | 31 | Permitir la creación de trabajos estándar los cuales contienen, la descomposición en tareas, los desfases entre ellas, cantidad de recursos de mantención, listas de materiales, grupos de trabajo, etc., así como la estimación de costos (en línea) para estos trabajos. | | | | 0 | | 32 | Permitir manejar diversos estados básicos de una Orden de Trabajo de Mantenimiento (Ej.: en ejecución, en planificación, en espera, terminada, etc.) y otros estados secundarios. | | | | 0 | | 33 | Debe mantener información histórica de las mantenciones y reparaciones realizada a máquinas, equipos, etc. inventariadas en el Activo Fijo y de sus piezas. Se debe incluir como mínimo la siguiente información. | | | | 0 | | | · Equipo | | | | | | | · Descripción de la mantención y/o reparación | | | | | | | · Procedimientos utilizados y el tipo de intervención realizada. | | | | | | | · Contratista | | | | | | | · Proveedor del repuesto | | | | | | | · Costos de repuestos y materiales | | | | | | | · Costo en hrs. hombre | | | | | | | · Fecha Inicio | | | | | | | · Fecha estimada de término | | | | | | | · Fecha de término | | | | | | | · Responsable asignado | | | | | | 34 | Permitir agrupar Órdenes de Trabajo de tal forma que se pueda consultar en línea los datos de costos estimados y reales de todo el grupo de “OTs”. | | | | 0 | | 35 | Permitir direccionar la autorización de las “OTs” a diferentes personas o cargos, según criterios definidos por el usuario. | | | | 0 | | 36 | Permitir interface o integración con MS Project (no se debe incluir el MS Project), y poder realizar Carta Gantt con la información del Trabajo a realizar. | | | | 0 | | 37 | Permitir asignarle fechas de ejecución a las Órdenes de trabajo, y llevar un control del tiempo utilizado en la ejecución de las tareas. | | | | 0 | | 38 | Permitir actualizar la disponibilidad real de un equipo en un período, una vez este haya terminado, con el fin de determinar horas reales disponibles. | | | | 0 | | 39 | Permitir la reprogramación de actividades comprometidas o liberadas por los mismos mecanismos de la programación original. | | | | 0 | | 40 | Permitir reprogramar la Orden de Trabajo y optimizar los recursos (nivelación de fuerza laboral /horas disponibles vs. horas requeridas). | | | | 0 | | 41 | Permitir la comparación gráfica entre recursos disponibles y requeridos para un grupo o grupos de trabajo. | | | | 0 | | 42 | Permitir visualizar en forma Gráfica, los estimados y reales y la varianza. | | | | 0 | | 43 | Permitir que un mismo trabajo estándar sea valorizado en forma diferente, dependiendo de factores como grados de dificultad, distancias, etc. | | | | 0 | | 44 | Permitir consultar el detalle de costos planeados y reales por tareas. | | | | 0 | | 45 | Permitir la asociación de “OTs” a proyectos creados en el mismo sistema, de tal forma que los costos reales y planeados hagan parte de la estructura de costos del proyecto. | | | | 0 | | 46 | Permitir obtener los costos de Órdenes de Trabajo, por jerarquía de equipos / grupos de equipos. | | | | 0 | | 47 | Permitir discriminar los costos de los trabajos de mantenimiento, teniendo en cuenta la Mano de Obra, repuestos, materiales, servicios de terceros, etc. | | | | 0 | | 48 | Permitir registrar y controlar el tiempo real por tarea realizada por empleado y/o cargo. | | | | 0 | | 49 | Permitir la obtención de informes personalizados por el usuario acorde a parámetros de solicitud, presentando sólo los datos deseados con la opción de impresión directa. | | | | 0 | | 50 | Permitir valorizar la OT con todos los costos asociados a ella y personal externo, materiales y repuestos, servicios de terceros, costo de equipos y grúas, compras, contratos etc. | | | | 0 | | | ADMINISTRACIÓN MANTENIMIENTO PREVENTIVO | | | | | | 51 | Permitir la programación de tareas repetitivas de acuerdo a parámetros de control, como calendario, horómetro, costeo de las tareas en términos de HH (HORAS HOMBRE) por especialidad. | | | | 0 | | 52 | Proveer facilidades internas para la construcción de programas de mantenimiento ya sean tareas repetitivas, Órdenes correctivas, etc. empleando criterios de período de trabajo, reprogramación automática de tareas no ejecutadas, etc. | | | | 0 | | 53 | Armado de rutas con equipos que pertenezcan al mismo padre en la jerarquía de equipos. | | | | 0 | | 54 | El sistema debe contener un análisis tendiente a obtener las causas de las fallas, la tendencia de fallas, pronósticos y probabilidades de las fallas. Para esto debe permitir configurar y utilizar jerarquías de falla, al menos de tres niveles (Problema – Causa – Solución) y vincularlas a los equipos en análisis. | | | | 0 | | 55 | Permitir la elaboración de listas de materiales involucrados en el mantenimiento preventivo. | | | | 0 | | 56 | Permitir suministrar informes de los pronósticos de recursos requeridos por período (mano de obra, materiales, equipos tipo herramientas, etc.). | | | | 0 | | 57 | Permitir visualizar la carga de los recursos para mantenimiento disponibles | | | | 0 | | 58 | Permitir algún tipo de vinculación o relación con MS Project que permita poder elaborar carta Gantt de planificación | | | | 0 | | 59 | La programación debe incluir: | | | | | | | · Periodo cubierto, Planificador, Grupo de trabajo, recurso disponible y planeado. | | | | 0 | | | · Prioridad del Equipo, Numero Orden de trabajo, Descripción de la rutina, Duración, Fecha Inicial y Fecha Final, | | | | | | | · Carta Gantt del trabajo Planeado como salida. | | | | | | 60 | Control de paradas de Equipos de Proceso | | | | 0 | | | · Identificación de requerimientos de Trabajos y necesidades de recursos. | | | | | | | · Definir niveles de autoridad para el control de perdidas de Producción | | | | | | | · Facilidad para cambiar fechas de programación en paradas mayores. | | | | | | 61 | Generación automática de Órdenes de Trabajo basados en las rutinas de Mantenimiento preventivo y las estadísticas Operacionales de cada Equipo. | | | | 0 | | 62 | Control del personal y recursos dentro de los Grupos de Trabajo. | | | | 0 | | 63 | Acceso a Lista de Repuestos de Equipos. | | | | 0 | | 64 | Ajuste de la programación en forma manual (planeado y programado). | | | | 0 | | 65 | Identificación de requerimientos de recursos (mano obra, herramientas y equipos). | | | | 0 | | 66 | Reprogramación de tareas mediante el arrastre a un periodo no comprometido. | | | | 0 | | 67 | Distribuir automáticamente los recursos acorde con los desfases de las tareas de los trabajos estándares. | | | | 0 | | 68 | Múltiples unidades de intervalo de programación para Mantenimientos Preventivos. | | | | 0 | | | · Días | | | | | | | · Semanas | | | | | | | · Meses/Años | | | | | | 69 | Mantenimiento Preventivo basado en Medidores (al menos 2 medidores en un mismo equipo), ejemplos: | | | | 0 | | | · Horómetros | | | | | | | · Kilómetros | | | | | | 70 | Mantenimiento Basado en Condiciones (Sintomático). Ejemplo: Vibraciones, Análisis de Aceite, etc. | | | | 0 | | 71 | Mantenimiento Preventivo –mantenimientos preventivos multinivel (jerarquía) | | | | 0 | | 72 | Procedimientos de Trabajo Seguro – los peligros y precauciones pueden combinarse en planes de seguridad predefinidos y unidos una vez a los activos o ubicaciones para usarse en los trabajos. | | | | 0 | | 73 | Procedimientos de Trabajo Seguro – procedimientos de desconexión y reconexión y tarjetas de bloqueo. | | | | 0 | | 74 | Presupuestos – Comparativo de Presupuestos otorgados por centro de costo versus costos incurridos por centro de costo. | | | | 0 | | | MONITOREO POR CONDICIÓN | | | | | | 75 | Permitir la definición de rutinas, frecuencias e identificación de puntos de muestreo para colección de datos. | | | | 0 | | 76 | Permitir integrar este módulo con el módulo de programación, estándares de trabajo, Órdenes de Trabajo, estadísticas operacionales. | | | | 0 | | 77 | Permitir la facilidad para definir niveles de precaución y de peligro, y que estos niveles disparen alarmas para realizar el monitoreo. | | | | 0 | | 78 | Capacidad de obtener las tendencias en forma gráfica de acuerdo a las muestras tomadas. | | | | 0 | | 79 | Que el sistema permita la entrada manual de los resultados de las muestras. | | | | 0 | | 80 | Que el sistema permita la entrada automática de los resultados de muestras. | | | | 0 | | 81 | Permitir mantener el registro histórico de los datos digitados. | | | | 0 | | | MATERIALES Y REPUESTOS | | | | | | 82 | Se requiere que todo listado de partes tenga la cantidad requerida de repuestos para su reparación y la cantidad instalada en el equipo. | | | | 0 | | 83 | Se requiere tener la facilidad de crear un listado de partes requeridas para efectuar un trabajo específico de mantenimiento, incluyendo materiales incluidos en el inventario y repuestos susceptibles de compra directa. | | | | 0 | | 84 | Se requiere asignarle al listado de partes un responsable para su control y actualización. | | | | 0 | | 85 | Se requiere de un número de identificación para hacerle seguimiento a los componentes. | | | | 0 | | 86 | Se requiere que al crear un listado de partes se pueda registrar la siguiente información: | | | | 0 | | | · Materiales | | | | | | | · Fabricante | | | | | | | · Nº de parte, | | | | | | | · Código de almacén | | | | | | | · Grupo identificador a cual pertenece Grupo Clase | | | | | | | · Cantidad instalada | | | | | | | · Cantidad requerida | | | | | | | · Descripción del listado de partes | | | | | | | · Costos unitarios | | | | | | | · Unidades de medida | | | | | | | . | | | | | | 87 | El sistema debe permitir, agrupar listas de partes, definir stocks mínimos, definir tiempos de reposición, definir frecuencia de uso, asignar responsables, catalogar ítems nuevos. | | | | 0 | | 88 | Permita registrar la información de componentes del mismo modo que se registra un Equipo: Fabricante, Número de Parte, Número de Ítem Catalogado. Tipo de Posición (Instalado), Estado, etc. | | | | 0 | | 89 | Efectuar la búsqueda de repuestos y materiales por proveedor | | | | 0 | | 90 | Permitir la actualización de la vida del componente, desde el momento en que se le registra la estadística de Operación al Equipo. | | | | 0 | | 91 | Realizar seguimiento a componentes enviados a reparar a terceros, Actividades a realizar, Transacción de seguimiento, Ingreso al almacén, Retiro del almacén, dado de baja, etc. | | | | 0 | | 92 | Facilidad para cargar automáticamente desde Excel al software, la información de registro de Equipos y Componentes. | | | | 0 | | 93 | Facilidad para generar reportes e informes de gestión. | | | | 0 | | | MODELO DE EQUIPOS/UBICACIONES FUNCIONALES | | | | | | 94 | Manejo separado del concepto de Ubicación Funcional (Posición, TAG) del concepto de Equipo Físico (Número de Golpe). | | | | 0 | | 95 | Se deben definir los equipos con los siguientes atributos como mínimo: código, descripción, tipo o sub-tipo, N° de serie, fabricante, fecha instalación, etc. | | | | 0 | | 96 | Manejo Jerárquico multi-nivel ilimitado (no necesariamente de la misma profundidad) tanto para ubicaciones funcionales como para equipos (relación equipo – equipo componente / subequipo). | | | | 0 | | 97 | Se requiere llevar el historial de mantenimiento y costos al nivel de detalle que se requiera (cualquier nivel de la jerarquía definida). | | | | 0 | | 98 | Especificaciones Técnicas de equipos en jerarquía de clasificación de al menos 2 niveles (clase, subclase). | | | | 0 | | 99 | Generación automática de descripciones de equipos desde los datos de especificación. | | | | 0 | | 100 | Equipos – lista de materiales/partes (despiece de equipos). | | | | 0 | | 101 | Equipos – generación automática de lista de materiales/repuestos a medida que se cierran las Órdenes de trabajo en base al consumo de bodega asociados a la OT. | | | | 0 | | | ADMINISTRACIÓN DE PERSONAL MANTENIMIENTO | | | | | | 102 | Permitir registrar y controlar la disponibilidad de mano de obra, para poder utilizarlo al momento de la planificación, así mismo se debe actualizar automáticamente en línea y en tiempo real en la medida de la utilización de esa mano de obra. | | | | 0 | | 103 | Mecanismo de Costeo de Labor para distribuir los costos de la mano de obra basado en la cantidad de horas hombre (h/h) trabajadas en cada Orden de Trabajo y en el costo estándar estimado por hora de cada empleado, grupo de trabajo, especialidad, centro de costo, taller u organización. | | | | 0 | | 104 | Permitir obtener la discriminación de las horas trabajadas sobre equipos, plantas, etc. | | | | 0 | | 105 | Permitir registrar y controlar las horas reales trabajadas por persona / cargo, de acuerdo a las tareas realizadas. | | | | 0 | | 106 | Permitir registrar y controlar los tiempos de trabajo y tiempos no laborales (vacaciones, permisos, licencia médica, descanso, etc.) de modo que automáticamente tenga en cuenta estos tiempos al momento de la planificación, dando alerta de dicha situación y/o tomando medidas al respecto. | | | | 0 | | | GESTIÓN MANTENIMIENTO DE LOS ACTIVOS | | | | | | 107 | Permitir asignar a equipos y materiales documentos según lo defina el usuario. Estos documentos pueden ser: Imágenes, textos, planillas de cálculo, planos, etc. Además asocia la aplicación para edición de esos documentos. | | | | 0 | | 108 | Permitir el análisis de los costos de mantenimiento. Debe ser versátil facilitando el análisis de distintos parámetros según lo solicite el usuario. (Ej. Real v/s. planeado, costos mensuales, costos de repuestos por equipo/ tiempo, etc.). | | | | 0 | | 109 | Permitir discriminar costos reales v/s planificados de acuerdo con las necesidades del usuario tanto en las “OTs”, como en los informes de costo (ejemplo horas de mano de obra, costos de la mano de obra, costo de los materiales y costos indirectos). | | | | 0 | | 110 | Permitir realizar análisis de fallas de acuerdo con los indicadores definidos por el usuario, además de indicadores estándar (tiempos medio de fallas, tiempo efectivo de funcionamiento, etc.). | | | | 0 | | 111 | Permitir realizar análisis integrados de la gestión de mantenimiento de acuerdo a parámetros estándar y definidos por el usuario. | | | | 0 | | 112 | Permitir visualizar en pantalla el gasto realizado en la OT por subítem de gasto. | | | | 0 | | | COSTOS Y PRESUPUESTO DE REPUESTOS | | | | | | 113 | La solución deberá permitir mantener un control de costos y presupuestos al nivel de procesos y actividades, que le permita a la Gerencia hacer una buena gestión de éstos; a su vez poder controlar los costos individuales al nivel de cada uno de los equipos, flotas y unidades productivas. Ésta solución deberá permitir hacer gestión de costos a través de equipos y órdenes de trabajo, donde permita la visualización de costos de mantenimiento relacionados con Materiales, Labor y Otros tipos de costos. | | | | 0 | | 114 | La solución deberá permitir imputar un gasto a un centro de costo cuya naturaleza pueda ser de tipo Corriente, Reparación Mayor Activable o Capital de Inversión, además de mantener éstos tres tipos de presupuestos en el sistema. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 228 | | | | Puntaje Mínimo Exigido | | | 160 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 5 | | | | Ponderación del Módulo | | | 3 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

PERSONAL - REMUNERACIONES PERSONAL - REMUNERACIONES | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Manejar los regímenes de previsión privados y públicos, AFP, ISAPRES, CAJAS y otros. | | | | 0 | | 2 | En la presente situación, debe importarse las remuneraciones de todo el personal dependiente de CARABINEROS DE CHILE que presta sus servicios en el HOSCAR, es decir, el soporte correspondiente debe contener el "Costos Empresa" de haberes por funcionario y categoría, a fin de ser imputado a las correspondientes unidades de negocio. | | | | 0 | | 3 | Parametrización del cálculo de haberes conforme al Código del Trabajo, leyes especiales y propias de la administración pública, por ejemplo:
• Haberes imponibles.
• Haberes no imponibles.
• Haberes tributables.
• Haberes fijos.
• Haberes variables.
• Cálculo de excedentes.
• Devolución por días de licencias médicas.
• Generación de aguinaldos de fiestas patrias y navidad, imponibles y no imponibles.
• Bonos de carácter imponible y no imponible.
• Gestión de reajustes a las remuneraciones en forma anual y ocasional.
• Los cálculos deben ser generados en forma automática y parametrizable.
• Manejo de niveles y sub-niveles de sueldos y bandas salariales.
• Otros haberes.
• Cálculo de pago de turnos, refuerzos, horas extras y otros conforme al sistema de control de asistencia vigente en el establecimiento respectivo de DISALCAR.
• Considerar las Glosas asociadas a las Distintas Modalidades Contractuales Existentes, incluyendo Ley 15.076. | | | | 0 | | 4 | Parametrización de descuentos externos e internos de carácter previsional, legal y mantención de éstos. Por ejemplo:
• Manejo de descuentos previsionales y legales que afectan la remuneración del trabajador.
• Proceso de rebaja de licencias médicas y permiso sin goce de sueldo.
• Manejo de descuentos legales sobre aportes patronales: Mutual de Seguridad, Seguro de Cesantía, de Salud y otros.
• Debe contener estadísticas mensuales de cargas familiares por tramos y reajuste anual de éstas.
• Debe administrar el cálculo de la Retención Judicial del trabajador conforme a valores expresados en $ - U.F. - %.
• Manejar y administrar descuentos internos de Comisiones Administrativas.
• Descuentos Originados en Organismos Externos al Hospital y Retenciones Judiciales
• Mantención sobre prioridad de los descuentos en general.
• Descentralización del ingreso de descuentos de las diferentes Comisiones Internas del Hospital.
• Debe generar la liquidación del impuesto a la renta por cada funcionario o sociedad de profesionales, pudiendo permitir su modificación en cualquier período.
• Mantención y actualización de la tabla de impuesto a la renta.
• Mantención, ingreso y modificación de descuentos previsionales y otros.
• Cálculo automático de remuneraciones variables en la liquidación de remuneración de cada trabajador. | | | | 0 | | 5 | Manejar en forma automática los haberes y descuentos, lo que permite informar en forma masiva, para toda una planilla o un rango de empleados de ella, un haber o descuento. Por ejemplo, asignar a una planilla un bono especial o descontar un monto especifico por concepto de entrega de algún beneficio. | | | | 0 | | 6 | Ingresar por parámetros los niveles de renta y grados de la Escala Única, haberes y descuentos legales, haberes y descuentos informados, grupos de haberes y grupos de descuentos como base de cálculo de beneficios, tramos de impuestos, tipos de contratos, tipos de cargas familiares, etc. | | | | 0 | | 7 | Proceso de generación de liquidación de remuneraciones: Generación de liquidación de sueldo en cualquier momento y necesidad.
• Detección del alcance líquido.
• Debe considerar la confección de diferentes tipos de formularios de liquidación de sueldos (código del trabajo y honorarios). | | | | 0 | | 8 | Informar, modificar o eliminar haberes y descuentos en forma puntual para cada empleado. Por ejemplo, informar horas extraordinarias, pago de bonos, becas, o descontar anticipos, cuotas extraordinarias, etc. | | | | 0 | | 9 | El proceso de cálculo de descuentos debe completar el ciclo agregando los descuentos legales de salud, previsión e impuesto a la renta. Además, debe considerar los descuentos por concepto de anticipos, mutuales, cuotas de préstamos (cuando corresponda), los cuales deben considerar la interfaz a las instituciones que correspondan, por ejemplo DIPRECA, SIGFE II, entre otros. | | | | 0 | | 10 | El Sistema debe ser capaz de Generar el OUTPUT para el Pago Masivo en PREVIRED, de acuerdo a los formatos que corresponda | | | | | | 11 | Incorporar el proceso de cierre mensual, generar el libro de remuneraciones y generar el Asiento Contable que será trasladado al Sistema de Contabilidad y al SIGFE II. Se hace presente que la unidad de remuneraciones es única pero maneja tres entidades diferentes. Esto implica la emisión de los tres Libros de Remuneraciones: Hoscar DFL 1, Hoscar Dipreca y Fondo Hospital. Odontológico. | | | | 0 | | 12 | Permitir relacionar todos los diferentes haberes y descuentos con cuentas contables y presupuestarias, y generar de manera automática la distribución contable de la preobligación, obligación, devengo y pago en el Presupuesto. | | | | 0 | | 13 | Manejar información histórica de los pagos realizados. Esto permite realizar en forma automática los procesos de reliquidación de haberes e impuestos que puedan requerirse, así como la emisión de certificados de renta. Calcular en forma automática el monto de la asignación familiar a percibir por los empleados, de acuerdo al imponible promedio de los últimos seis meses. En este caso, se necesita que los registros históricos de cualquier naturaleza del personal Ley N° 18.476 (Código del Trabajo) se mantengan con un intervalo en on-line de dos (2) años y una accesibilidad off-line de 5 (cinco) años consecutivos. | | | | 0 | | 14 | Registrar los movimientos de personal; por ejemplo, permisos sin goce de sueldo y licencias. | | | | 0 | | 15 | Registrar las cargas familiares incorporando la fecha de término del beneficio de la asignación. Contemplar, además, el trato de empleados que pertenezcan al régimen de previsión antiguo (Cajas de Previsión) con distintos tipos de cotización, y el personal recontratado, que tiene como previsión a DIPRECA. | | | | 0 | | 16 | Permitir el reajuste automático del nivel de renta (sueldo base), ya sea en un monto especifico o en un porcentaje | | | | 0 | | 17 | Permitir el pago de anticipos con la correspondiente emisión de listados para cuadratura y pago. Estos ‘pagos anticipados’ pasan en forma automática a descuento con el cálculo de la liquidación mensual. | | | | 0 | | 18 | Reportes estructurados. Por ejemplo:
• Informes previsionales: AFP, ISAPRES, FONASA, DIPRECA, INP y otros.
• Informes de aportes patronales.
• Ajuste de sueldos mensual.
• Resúmenes de haberes mensuales.
• Liquidación de descuentos mensual.
• Elaboración de estadísticas e informes a organismos externos al HOSCAR (INE, y otros).
• Informes de cuadratura de remuneraciones mensual.
• Informes contables.
• Centralización contable.
• Libro de remuneraciones y asientos contables.
• Reporte de presupuesto de gastos en personal, histórico y ocasional.
• Administración de trabajos estadísticos-históricos.
• Reportes de remuneraciones según necesidad.
• Resumen e indicadores de gastos en remuneración por categoría y Centro de Costo.
• Diferencia de las remuneraciones entre meses.
• Importación de remuneraciones del Personal Uniformado de Carabineros.
• Tabla de Escala Única de Sueldos / Estructura de Sueldos.
• Listado de grupos y subgrupos.
• Resumen de Planilla. Debe considerar todas las variables que intervienen en el pago de la remuneración de cada funcionario y categoría dentro del HOSCAR.
• Liquidaciones con cheque y sin cheque.
• Distintas formas de pago, incluyendo pago por nómina a través de bancos.
• Maestro alfabético de empleados.
• Resumen de haberes y descuentos por Código.
• Haberes y descuentos por empleado.
• Planilla de Honorarios a Suma Alzada.
• Asociación Chilena de Seguridad.
• Planillas de AFP.
• Planillas de ISAPRES.
• Planillas de INP. | | | | 0 | | 19 | Preparación y emisión de archivos exportables para cualquier entidad externa al Hospital, por ejemplo:
• PREVIRED.
• Depósitos a bancos.
• Mutual de Carabineros.
• Consorcios.
• Compañías de Seguros.
• Caja de Compensación.
• Crear archivo, para subirlo al portal del Bancoestado. Pago de Sueldos por transferencia electrónica. | | | | | | 20 | Confección de planilla de pago mensual sujeta a la emisión de cheques y conciliación bancaria. | | | | 0 | | 21 | Integración con el sistema de control de asistencia vigente, sobre cálculo de todos los turnos, horas extras, ausencias del personal y otros. | | | | 0 | | 22 | Declaración operación renta anual de los diferentes impuestos a través de Internet. | | | | 0 | | 23 | Gestión y proyección parametrizada de cálculo de finiquitos e indemnizaciones por funcionario y Centro de Costo. | | | | 0 | | 24 | La ficha personal por funcionario debe tener un código asignado el cual debe ser irremplazable, así sea traslado a otra dependencia. | | | | 0 | | 25 | Calcular finiquito del personal. | | | | 0 | | 26 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. | | | | 0 | | 27 | Gestión abierta de periodos de devengo y distintos procesos de cálculo: nóminas, finiquitos, pagas extras, atrasos, etc. | | | | 0 | | 28 | Imputación de incidencias económicas a procesos actuales y futuros. | | | | 0 | | 29 | Incidencias económicas por unidades e importes, fijas y temporales. | | | | 0 | | 30 | Cálculos de devengos mensuales, por días naturales, por días laborables, por horas. | | | | 0 | | 31 | Gestión de anticipos: cálculo de cuotas, seguimiento del amortizado y saldo pendiente. | | | | 0 | | 32 | Asignación de importes a nivel general (categorías) y a nivel particular (empleados). | | | | 0 | | 33 | Diversos métodos de cálculo: proporcional, fijo, dependiente, por incidencias, por fórmulas. | | | | 0 | | 34 | Situaciones laborales especiales: jornada reducida, pluriempleo, alta sin cotización, ausencias. Asociadas a las distintas Modalidades Contractuales. | | | | 0 | | 35 | Gestión Asociada a Condiciones Especiales como: Accidentes laborales, Maternidad. | | | | 0 | | 36 | Distribución de los Costos de Remuneraciones a las Unidades de Negocio (Centros de Costo o Centros de Responsabilidad), en la cual el funcionario presta sus servicios. Si trabaja en más de una unidad de negocio, distribuir el costo en forma proporcional según tiempo aplicado. | | | | 0 | | 37 | Capacidad de Programar Transferencias Bancarias y/o Configurar la Generación Archivos de OUTPUT según requerimientos bancarios específicos. | | | | 0 | | 38 | Capacidad de Importar Sueldo Bruto (costo hospital) calculado por otra fuente, para un perfil de contrato y Rut específico en forma masiva. Capacidad para Distribución de los Costos de Remuneraciones a las Unidades de Negocio (Centros de Costo o Centros de Responsabilidad), en la cual el funcionario presta sus servicios. Si trabaja en más de una unidad de negocio, distribuir el costo en forma proporcional según tiempo aplicado. | | | | 0 | | 39 | El Sistema debe permitir calcular las remuneraciones correspondientes a las diferentes modalidades contractuales | | | | 0 | | 40 | Manejar Tablas De Indicadores Porcentuales Y Económicos Para El Calculo De Cotizaciones Previsionales Y Para El Impuesto Único, Según Su Variación (UF y UTM). | | | | | | 41 | Informe Declaraciones Juradas Para El Proceso De Impuesto A La Renta. | | | | | | | | | | | | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 82 | | | | Puntaje Mínimo Exigido | | | 57 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 2 | | | | Ponderación del Módulo | | | 4 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

PERSONAL - VIÁTICOS | | | | | | | N° | Funcionalidades | | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Permitir el ingreso de la “Resolución de Comisión y Anticipo de Viáticos”, es decir, documento que puede incluir el anticipo de viáticos de uno o varios funcionarios. Ingresar en forma automática desde una tabla el funcionario y todos aquellos parámetros necesarios para el cálculo del anticipo y su imputación presupuestaria de acuerdo a la normativa vigente. | | | | | 0 | | 2 | La rendición de viáticos se debe realizar a través del ingreso del “Informe de cumplimiento de comisión y liquidación de viáticos”, y separar aquellas rendiciones que igualan el anticipo, de aquellas que necesitan reintegro o suplemento y ejecutar en ambos casos los ajustes generando la actualización en las cuentas respectivas. | | | | | 0 | | 3 | Registrar en línea los montos de los viáticos en el Sistema de Presupuesto con la Preobligación, Obligación, Devengo y Pago. | | | | | 0 | | 4 | Manejar el historial por cada funcionario que haya sido registrado en el Sistema de Viáticos. Consultar los viáticos recibidos por funcionario en montos y días otorgados al mes y año a los diferentes porcentajes que exige la norma de gobierno. | | | | | 0 | | 5 | Generar automáticamente el asiento a contabilidad por cada viático asignado. | | | | | 0 | | 6 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. | | | | | 0 | | | | | | | | | | | TOTAL PUNTOS | | 0 | 0 | 0 | | | | | | | | | | | | Puntaje Máximo Posible | | 12 | | | | Puntaje Minimo Exigido | | 7 | | | | Máximo ítem "No Cumple ni será desarrollado" | | 0 | | | | Ponderación del Módulo | | 2 | | | | | | | | | | | | | | | | | | | * Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

ADMINISTRACIÓN DE PERSONAL ADMINISTRACIÓN DE PERSONAL | | | | | | N° | Funcionalidades | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Se requiere llevar Hoja de Vida del Personal con todos sus movimientos y una carpeta con información histórica, que permita registrar y controlar toda la información de la vida del funcionario durante su paso por el HOSCAR, entregando a Encargados de la Administración de Personal el apoyo para la toma de decisiones. | | | | 0 | | 2 | Se requiere Integración con Reloj Control | | | | 0 | | 3 | Capacidad de gestionar información privada o confidencial asociada a tipos de contratos del personal. | | | | 0 | | 4 | Capacidad de Administrar Distintos Tipos de Modalidades de Contratos (CPR, DFL1 AFP, DFL1 Dipreca, PNI, PNS y HONORARIOS) | | | | 0 | | 5 | Capacidad para permitir que una misma persona (empleado de las modalidades indicadas en 4), pueda tener dos contratos vigentes completamente diferentes, pero aplicados a horarios diferentes y excluyentes. Generando nominas, vacaciones y egresos independientes. | | | | 0 | | 6 | El sistema debe ser paramétrico, permitiendo definir flexiblemente el tipo de información que requiere manejarse según las necesidades del HOSCAR. Parametrizar: Corresponde a todos los procesos necesarios para determinar la información básica del sistema, tales como la definición de la estructura Organizacional, tipos de contratos, grupos, conceptos y descripciones. | | | | 0 | | 7 | Posibilidad de Agrupar el Personal por Tipo de Contrato y Asignar Privilegios o Roles para ser gestionados por determinados funcionarios o oficinas. | | | | 0 | | 8 | Capacidad de Gestionar Casos (Carpetas) de información variada de personas, incluidas fuentes externas digitalizadas) | | | | 0 | | 9 | Capacidad de Registro de Diario de Horas Extra | | | | 0 | | 10 | Capacidad de Generar Informes Acumulados y Cálculos Mensuales de Horas Extra a ser Incluidos en el cálculo de remuneraciones. | | | | 0 | | 11 | Capacidad de Administrar Procesos de Reclutamiento, en base a manejar Carpeta de Información del postulante (CV, Pruebas, Exámenes, etc.) | | | | 0 | | 12 | Capacidad de Proveer una Base de Datos de CV NO FUNCIONARIOS, que permita Registro y Mantención de Postulantes segmentados por especialidad. | | | | 0 | | 13 | Capacidad de Gestionar una Oficina de Partes de RRHH, digitalizando la información recibida, registrando el origen y destino y enviando la información a su destino. | | | | 0 | | 14 | Capacidad de registrar todas aquellas acciones que realizan los funcionarios durante su permanencia en el HOSCAR, tales como registro de Becas Estudiantiles, empleados sin solicitud de acumulación de feriados, cálculo de feriados, ayuda y préstamos de Bienestar Social y el ingreso de información (esto comprende a un conjunto de datos relacionados a Feriado Legal, Permisos Institucionales, Salidas al Exterior, Trayectoria Laboral, Hoja de Vida, Beneficios Legales, Viáticos, Licencias, Control de Asistencia). | | | | 0 | | 15 | Capacidad de Gestionar Sumarios (Caso tipo Sumario) en base a Carpetas de Casos, con responsables y seguimiento vía workflow (flujo de trabajo) del mismo y la inclusión de resoluciones en Hoja de Vida. | | | | 0 | | 16 | Capacidad de Gestionar un Registro Especial de "lista de revistas" (Tipo Oficina de Partes), con fecha de recepción, origen, detalle resumido de tema tratado. | | | | 0 | | 17 | Capacidad de dar Soporte para el Registro de Personal, mediante una funcionalidad integrada de Toma de Foto, Registro de Huella Digital Biométrica, Datos Varios, y que permita generar (imprimir) la Tarjeta de Identificación y Tarjeta de Estacionamiento, para los nuevos ingresados. Obs: Dependiendo de factibilidad técnica de incorporar drivers de equipos. | | | | 0 | | 18 | Capacidad de Registrar en la Hoja del Personal PERMISOS, TRASLADOS, y otros relacionados con el movimiento de personal | | | | 0 | | 19 | Capacidad de Gestionar Recursos Salas de Capacitación disponibles vía INTRANET asociadas a Cursos Dictados Internamente para la Inscripción del personal. | | | | 0 | | 20 | Workflow que permita aprobar la inscripción en los distintos cursos, por el encargado/responsable de cada curso. | | | | 0 | | 21 | Capacidad de Gestionar un Calendario de Cursos, con Fecha, Descripción, otros detalle y Documentos Anexos Descriptivos | | | | 0 | | 22 | Capacidad de Asociar Cursos y Recursos de Salas Disponibles. | | | | 0 | | 23 | Capacidad de Gestionar una Base de Cargos Disponibles con sus respectivas descripciones y perfiles buscados, indicando responsable y fechas relevantes. | | | | 0 | | 24 | Capacidad de Gestionar las Calificaciones de los Empleados, tales como la documentación de un determinado logro (Notas de Merito, Felicitaciones, Notas de Demerito y Reclamos) durante el período de evaluación de desempeño, donde se puedan añadir y eliminar en un entorno amigable a través de un sistema de archivos adjuntos. | | | | 0 | | 25 | Capacidad de derivar PMG de la Institución y Convenios de Desempeño a objetivos de personal de manera que los fines de los empleados dentro de la organización, se encuentren integrados a las necesidades de la entidad y de ésta forma puedan realizarse más concisas evaluaciones y valoraciones (Desarrollo de Personal) y la transferencia de resultados a Gestión de la Compensación | | | | 0 | | 26 | Capacidad de Integración con KIOSCOS de Autoservicio, en que el Funcionario pueda recabar información que el compete mediante su identificación biométrica. | | | | 0 | | | | | | | | | | TOTAL PUNTOS | 0 | 0 | 0 | | | | | | | | | | | Puntaje Máximo Posible | | | 52 | | | | Puntaje Mínimo Exigido | | | 36 | | | | Máximo Ítem "No Cumple ni será desarrollado" | | | 1 | | | | Ponderación del Módulo | | | 6 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

RECLUTAMIENTO Y DESARROLLO RRHH N° | Funcionalidades | | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | | Reclutamiento y Selección | | | | | | | 1 | Emisión de respuestas automáticas a las postulaciones realizadas a través del correo electrónico de selección o página de Web del HOSCAR. | | | | | 0 | | 2 | Creación de plantillas electrónicas de requerimientos de personal generados por las distintas áreas del HOSCAR, ya sea por Aumento de Dotación, Cargo Vacante y Reemplazo, Evaluación Técnica u otras necesidades especiales. | | | | | 0 | | 3 | Parametrización de: | | | | | 0 | | | • Currículums Vitaes ingresados, ya sea por la página Web del Hospital, correo de Selección y los currículums físicos remitidos a RRHH. | | | | | | | | • Entrevistas realizadas especificando los postulantes aceptados y rechazados. | | | | | | | | • Registro de Concursos Internos realizados. | | | | | | | | • Publicaciones realizadas en Diarios y el costo de éstas. | | | | | | | | • Otros reportes y datos estadísticos de Selección, que la organización requiera. | | | | | | | | Desarrollo Organizacional | | | | | | 4 | Incorporación del Sistema de Evaluación del Desempeño diseñado, aprobado y actualmente en uso en el HOSCAR, el cual debe considerar la creación y acceso a los siguientes sistemas de información de la organización: | | | | | 0 | | | • Sistema de Control de Asistencia. | | | | | | | | • Distribución de Horas Médicas. | | | | | | | | • Atención de Usuarios. | | | | | | | | • Datos de contratos y otros antecedentes necesarios para el proceso de evaluación de desempeño. | | | | | | | 5 | Creación de herramienta que permita reportar la Trayectoria Laboral del personal, es decir, que contemple información tales como, cursos realizados, capacitación y otros. | | | | | 0 | | 6 | Creación de un sistema de Gestión de Cargos, el cual permita registrar los Perfiles de Cargo del Personal del HOSCAR, y llevar a cabo la Evaluación de Cargos (ordenación de los distintos cargos, con respecto a ciertos factores, de acuerdo a la importancia relativa del cargo). | | | | | 0 | | 7 | Presentar otras funcionalidades no descritas anteriormente que lleven a la modernización del modelo vigente. | | | | | 0 | | | | | | | | | | | TOTAL PUNTOS | | 0 | 0 | 0 | | | | | | | | | | | | | | | | | | | | Puntaje Máximo Posible | | | | 14 | | | | Puntaje Minimo Exigido | | | | 10 | | | | Máximo ítem "No Cumple ni será desarrollado" | 0 | | | | Ponderación del Módulo | | | | 3 | | | | | | | | | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

GESTIÓN ALIMENTACIÓN DE RRHH N° | Funcionalidades | | Cumple | Será Desarrollado | No Cumple ni será desarrollado | Total | Trazabilidad. Documento y Pagina de la oferta | 1 | Integración del módulo de Alimentación con el módulo de Recursos Humanos. Identificación del funcionario y tipo de contrato asociado. Según el tipo de contrato, se valida si corresponde la emisión del vale de alimentación. | | | | | 0 | | 2 | Integración del módulo de Alimentación con el módulo de Remuneraciones. Se realiza descuentos por planilla de sueldo de los consumos mensuales, según normativa del HOSCAR. | | | | | 0 | | 3 | El módulo de integrarse o ser capaz de capturar las transacciones generadas por el sistema de administración de los vales de almuerzo. | | | | | 0 | | 4 | Generación del vale de alimentación utilizando la tarjeta de identificación del funcionario. | | | | | 0 | | | • Las tarjetas de identificación del personal del HOSCAR son del tipo lectura por proximidad y también código de barra, pudiendo utilizar ambas tecnologías. | | | | | | | | • La validación de personas se realizará sobre un dispositivo biométrico utilizando tecnología de verificación; es decir, se debe considerar que el código asociado a la tarjeta debe ser validado por medio de la huella digital. Los dispositivos lectores serán proporcionados por el HOSCAR. | | | | | | | | • La emisión del vale de alimentación debe estar validada contra la asistencia del funcionario al Hospital. | | | | | | | | • Si el funcionario no porta su tarjeta de identificación, deberá permitirse la digitación del código asociado a ella, el cual se validará con la huella digital. | | | | | | | 5 | La inscripción periódica de los funcionarios para realizar consumos de alimentación se debe realizar por medio de la tarjeta de identificación. La inscripción se realiza automáticamente. El funcionario debe borrarse en caso de no asistencia. | | | | | 0 | | 6 | Se debe permitir la generación de vales de alimentación para personas externas no registradas en el Hospital | | | | | 0 | | 7 | Se requiere la capacidad de generación de diversas consultas y emisión de informes, según variados criterios establecidos a partir de información asociada a los módulos de Recursos Humanos y Remuneraciones. | | | | | 0 | | | Por ejemplo: | | | | | | | | • Informes de Consumos versus Tramos de Descuentos según salario de los funcionarios. | | | | | | | | • Informes de Consumos del Personal por evento (desayuno, almuerzo, cena y colaciones) y período. | | | | | | | | • Informe de Cuadre de Vales Entregados versus Raciones/Menúes entregados. | | | | | | | 8 | Se requiere la capacidad de generación de informes de trazabilidad y auditoría de los eventos registrados. | | | | | 0 | | 9 | Se requiere la capacidad de programación de menúes de eventos y su aporte nutricional. | | | | | 0 | | 10 | Presentar otras funcionalidades no descritas anteriormente | | | | | 0 | | | | | | | | | | | TOTAL PUNTOS | | 0 | 0 | 0 | | | | | | | | | | | | Puntaje Máximo Posible | | 20 | | | | Puntaje Minimo Exigido | | 13 | | | | Máximo ítem "No Cumple ni será desarrollado" | | 0 | | | | Ponderación del Módulo | | 2 | | |

Ponderación proporcional en el módulo=(ponderación del módulo/puntaje máximo posible)*puntaje obtenido | Resultado con DOS DECIMALES. |

CASOS DE USO PARA EVALUACIÓN * *
Caso de Evaluación Nº 1

Caso de Evaluación Nº 2

Caso de Evaluación Nº 3

CASO DE EVALUACIÓN Nº 4: INTEGRACIÓN SIGFE II

SIGFE II
Contabilidad
Finanzas
Maestro Cuentas SIGFE II
(Vacio)
Importación/Configuración Cuentas “Espejo”
Creación Plan de Cuentas Interno Multi-Nivel
Realización de Carga de Datos Financiero/Contables
Generación de
Reportes de Cuentas Consolidadas y Detalladas
Base de Prueba
Reporte
Maestro Cuentas SIGFE II
(DATOS)
Espejamiento
Cuentas SIGFE con Datos
SIGFE II
Contabilidad
Finanzas
Maestro Cuentas SIGFE II
(Vacio)
Importación/Configuración Cuentas “Espejo”
Creación Plan de Cuentas Interno Multi-Nivel
Realización de Carga de Datos Financiero/Contables
Generación de
Reportes de Cuentas Consolidadas y Detalladas
Base de Prueba
Reporte
Maestro Cuentas SIGFE II
(DATOS)
Espejamiento
Cuentas SIGFE con Datos

CASO DE EVALUACIÓN Nº 5: RECEPCIÓN DE PAGOS DE PRESTACIONES Contabilidad
Finanzas
Caja
Maestro Cuentas HOSCAR
Contabilización
Cuentas Mayores
Control Documentos a Fecha y Depósito
Recepción Pago Prestación
Rebaja Cuenta Cliente
Auxiliar de Pago Prestaciones
Cliente
Documentación Respaldo
Documento de Pago

Maestro
Pacientes
Auxiliar de Ingresos
Auxiliar Documentos
De Pago
Contabilidad
Finanzas
Caja
Maestro Cuentas HOSCAR
Contabilización
Cuentas Mayores
Control Documentos a Fecha y Depósito
Recepción Pago Prestación
Rebaja Cuenta Cliente
Auxiliar de Pago Prestaciones
Cliente
Documentación Respaldo
Documento de Pago

Maestro
Pacientes
Auxiliar de Ingresos
Auxiliar Documentos
De Pago

CASO DE EVALUACIÓN Nº 6: PAGO DE PROVEEDORES Contabilidad
Finanzas
Caja
Maestro Cuentas HOSCAR
Contabilización
Cuentas Mayores
Entrega Documento de Pago
Rebaja Cuenta Corriente Proveedor y Emisión Documentos
Proveedor
Factura

Maestro
Proveedores
Auxiliar de Pagos a Proveedores
Auxiliar Documentos por Pagar
Recepción
Facturas y
Otros
Cheque o Vale Vista
Proceso de Pago a Proveedores
Auxiliar
Pagos Aprobados
Actualización Cuenta Corriente Proveedores
Aprobación Facturas
Banco
Provisión Fondos
Contabilidad
Finanzas
Caja
Maestro Cuentas HOSCAR
Contabilización
Cuentas Mayores
Entrega Documento de Pago
Rebaja Cuenta Corriente Proveedor y Emisión Documentos
Proveedor
Factura

Maestro
Proveedores
Auxiliar de Pagos a Proveedores
Auxiliar Documentos por Pagar
Recepción
Facturas y
Otros
Cheque o Vale Vista
Proceso de Pago a Proveedores
Auxiliar
Pagos Aprobados
Actualización Cuenta Corriente Proveedores
Aprobación Facturas
Banco
Provisión Fondos

CASO DE EVALUACIÓN Nº 7: RECEPCIÓN DE BODEGA CON EAN-128 .
Bodega
Proveedor
Lectura Códigos de Barra de Caja EAN-128
Proveedor Entrega en Bodega Caja con EAN-128
(Lote y Fecha Vencimiento
Maestro de
Bodega de
Productos
Maestro Desglose Caja-Unidad
GS1
Registro Unidades Recibidas con Lote y Fecha Vencimiento
.
Bodega
Proveedor
Lectura Códigos de Barra de Caja EAN-128
Proveedor Entrega en Bodega Caja con EAN-128
(Lote y Fecha Vencimiento
Maestro de
Bodega de
Productos
Maestro Desglose Caja-Unidad
GS1
Registro Unidades Recibidas con Lote y Fecha Vencimiento

CASO DE EVALUACIÓN Nº 8: RECEPCIÓN BODEGA CON AUTOMATIZACIÓN GS1 - ISP
Bodega
Proveedor
Lectura Códigos de Barra SSCC de Pallet
Proveedor Entrega en Bodega Pallet con SSCC
(Lote y Fecha Vencimiento)
Maestro de
Bodega de
Productos
Maestro Desglose Caja-Unidad
GS1
Registro Unidades Recibidas con Lote y Fecha Vencimiento
Desglose SSCC – Caja - Unidad
GS1 - ISP
Bodega
Proveedor
Lectura Códigos de Barra SSCC de Pallet
Proveedor Entrega en Bodega Pallet con SSCC
(Lote y Fecha Vencimiento)
Maestro de
Bodega de
Productos
Maestro Desglose Caja-Unidad
GS1
Registro Unidades Recibidas con Lote y Fecha Vencimiento
Desglose SSCC – Caja - Unidad

ANEXOS DE BASES ADMINISTRATIVAS

ANEXO Nº 1: DECLARACIÓN DE PROBIDAD Y CONFLICTO DE INTERESES (de conformidad con los incisos 1 y 6, del artículo cuarto de la Ley de Compras.

En _____________ a ______ días del mes de ____________ de 2011, comparece _______________, de nacionalidad _______________, profesión _______________, RUT Nº ____________, con domicilio en _________________, por sí o en representación de ___________, quien bajo juramento expone:

Que a la empresa que representa, en la presente licitación no le afectan las inhabilidades, incompatibilidades y prohibiciones para celebrar contratos con los Órganos del Estado, especialmente las indicadas en el Artículo 4º de la Ley Nº 19.886.

NOMBRE Y FIRMA
OFERENTE

FECHA………………………

ANEXO Nº 2: IDENTIFICACIÓN DEL OFERENTE

1.- Nombre :

2.- RUT :

3.- Giro Social (Si lo tuviere) :

4.- Dirección :

5.- Comuna :

6.- Teléfono :

7.- Fax :

8.- E-mail :

9.- Representante Legal (si lo tuviere) :

10.- RUT Representante Legal si lo tuviere :

11.- Personería del Representante Legal si lo tuviere

Copia Fotostática de la Escritura Pública si lo tuviere :

12.- Nombre de Encargado de la Propuesta: Teléfono:

E- Mail:

Nota: Este Anexo debe presentarse en este formato.

ANEXO Nº 3: DECLARACIÓN DE CONFORMIDAD

En _____________ a ______ días del mes de ____________ de 2011, comparece _______________, de nacionalidad _______________, profesión _______________, RUT Nº ____________, con domicilio en _________________, por sí o en representación de ___________, quien bajo juramento expone:

Haber estudiado y tomado conocimiento de las Bases de la presente y sus Anexos, de las aclaraciones y respuestas a las consultas, y encontrarse conforme con todos sus términos y condiciones.

NOMBRE Y FIRMA OFERENTE
FECHA………………………

ANEXO Nº 4: DECLARACIÓN JURADA ART. 8 Y 10 DE LA LEY Nº 20.393. En _____________ a ______ días del mes de ____________ de 2011, comparece _______________, de nacionalidad _______________, profesión _______________, RUT Nº ____________, con domicilio en _________________, (por sí) (en su calidad de representante de ___________), quien bajo juramento expone: Que personalmente y/o la empresa que representa, en la presente Licitación ID N° 4642-XX-LP11 no le afectan ninguna de las prohibiciones para contratar que señala los Arts. 8 y 10 de la Ley Nº 20.393, que Establece la Responsabilidad Penal de las Personas Jurídicas en los Delitos de Lavado de Activos, Financiamiento del Terrorismo y Delitos de Cohecho que la Ley indica.

NOMBRE Y FIRMA
REPRESENTANTE LEGAL OFERENTE

FECHA………………………

5.-IMPÚTESE al Subtitulo 31 INICIATIVAS DE INVERSIÓN, ítem 02, Proyectos Asignación 006, Equipos Centro de Costo 02074, Hospital de
Carabineros.

6.-REMÍTASE la totalidad de los antecedentes a la Contraloría General de la República, a objeto de realizar el trámite de TOMA DE RAZÓN, conforme lo establece la Resolución Nº 1600, de 2008, del ente contralor. 7.-PUBLÍQUESE e INFÓRMESE el presente llamado a licitación pública en el Sistema de Información del Portal Mercado Público, de acuerdo a lo dispuesto en el Artículo 20º de las Ley Nº 19.886.

ANÓTESE, TÓMESE RAZÓN, REGÍSTRESE Y COMUNÍQUESE.

CARLOS GUSTAVO CARRASCO HELLWIG General de Carabineros DIRECTOR DE SALUD ADMINISTRADOR FONDO HOSPITALES

DISTRIBUCION:
1.- CGR .
2.- Fondo Salud
3.- Depto. Cont. y Finanzas.
4.- Depto. Abastecimiento.
5.- Asesoría Jurídica.
6.- Archivo.