|
El Hospital Guillermo Grant Benavente necesita contar con un Sistema para Anatomía Patológica con el que se debe generar el registro de la trazabilidad y procesamiento de muestras, sistema web y que pueda ser integrable con las diversas plataformas en uso en el hospital, este sistema debe cubrir las etapas de pre y post analítica.
El Sistema debe contar con lo siguiente:
ESPECIFICACIONES TÉCNICAS DE INFRAESTRUCTURA,
1. Arquitectura General de la Solución
La institución requiere disponer de un sistema web que permita gestionar de manera eficiente, segura y oportuna los servicios brindados. Para ello, el proveedor deberá ofertar una solución web integral, que no requiera instalación en equipos locales y que cumpla con los estándares técnicos y de seguridad definidos por el hospital.
El oferente deberá proveer, implementar y mantener una solución integral de infraestructura tecnológica en modalidad on-premise, virtualizada y en alta disponibilidad (HA), destinada a soportar la operación continua del SISTEMA e INTEGRACIONES durante toda la vigencia del contrato.
La solución deberá diseñarse bajo principios de alta disponibilidad, resiliencia, seguridad por diseño y continuidad operacional, garantizando la eliminación de puntos únicos de falla y la disponibilidad permanente de los servicios.
Será responsabilidad exclusiva del oferente el correcto dimensionamiento de la infraestructura, considerando la demanda actual y su crecimiento proyectado, asegurando el uso óptimo del sistema e integraciones y el acceso completo a todas sus funcionalidades.
Todos los componentes deberán ser suministrados, instalados, configurados, puestos en marcha, administrados, monitoreados y mantenidos por el oferente, sin costo adicional para el HGGB.
Adicionalmente, el oferente podrá proponer una arquitectura basada en infraestructura convergente o hiperconvergente, en la cual los componentes de cómputo, almacenamiento y red se encuentren integrados en una plataforma unificada, siempre que dicha solución cumpla con los requisitos de alta disponibilidad, seguridad, escalabilidad y continuidad operacional establecidos en las presentes bases.
En caso de optar por este tipo de arquitectura, el oferente deberá garantizar la gestión centralizada de los recursos, la expansión modular sin interrupción del servicio y la eliminación de puntos únicos de falla, asegurando niveles de servicio equivalentes o superiores a los definidos para arquitecturas tradicionales.
Asimismo, el oferente deberá describir detalladamente la arquitectura propuesta, incluyendo la forma en que se integran los componentes de cómputo, almacenamiento y red, así como los mecanismos de alta disponibilidad y tolerancia a fallas implementados.
2. Requisitos Previos a la Entrada en Producción
Previo a la puesta en operación de cualquier componente de la solución, el oferente deberá dar cumplimiento a los lineamientos de gobernanza, seguridad de la información y ciberseguridad definidos por el HGGB.
El oferente deberá acreditar la aplicación de configuraciones seguras (hardening), la actualización de parches de seguridad y la ejecución de escaneos de vulnerabilidades, debiendo remediar los hallazgos detectados conforme a su nivel de criticidad antes de su conexión a la red institucional.
Asimismo, todos los activos asociados a la solución deberán encontrarse debidamente registrados y actualizados en el inventario institucional del Hospital.
La entrada en producción estará sujeta a la aprobación formal del Encargado de Ciberseguridad del HGGB o de la instancia que éste designe, pudiendo el Hospital rechazar la puesta en operación en caso de incumplimiento, sin que ello genere derecho a compensación para el oferente.
3. Plataforma de Servidores
El oferente deberá implementar una plataforma de servidores en dependencias del HGGB, compuesta por equipos montables en rack y configurada bajo un esquema de virtualización en alta disponibilidad.
La arquitectura deberá contemplar clúster de servidores con capacidad de conmutación automática ante fallas, asegurando continuidad operativa sin intervención manual. Asimismo, deberá incorporar mecanismos de replicación de datos en tiempo real o casi real, tales como servidores espejo o soluciones equivalentes.
La solución deberá considerar almacenamiento con tolerancia a fallas, incluyendo controladoras redundantes y capacidad de expansión en línea, permitiendo el crecimiento de la demanda durante toda la vigencia del contrato.
Los servidores deberán incorporar mecanismos de seguridad adecuados, tales como soluciones antimalware, EDR y configuraciones de hardening, debidamente gestionadas y actualizadas.
El oferente deberá garantizar que la plataforma soporte la totalidad de las funcionalidades del sistema, manteniendo niveles de disponibilidad acordes a la criticidad del servicio.
4. Sistema de Respaldo y Recuperación
El oferente deberá implementar una solución de respaldo que garantice la protección, disponibilidad e integridad de la información del sistema.
Los respaldos deberán ejecutarse de forma automática, con periodicidad diaria y sin afectar la operación del sistema, considerando aplicaciones, bases de datos y configuraciones. Se deberá mantener una retención mínima de treinta días.
Asimismo, los respaldos deberán almacenarse en un sitio remoto, físicamente independiente del sitio principal, en cumplimiento de lo establecido en el Decreto N°83, en infraestructura con certificación TIER III o superior, o equivalente.
La solución deberá permitir la recuperación íntegra y oportuna de la información ante incidentes.
Adicionalmente, el oferente deberá definir objetivos de recuperación, estableciendo un Tiempo Objetivo de Recuperación (RTO) y un Punto Objetivo de Recuperación (RPO), los cuales deberán ser acordes a la criticidad del sistema y validados por el HGGB.
El oferente deberá realizar pruebas de restauración de respaldos con una periodicidad mínima trimestral (cada 3 meses), debiendo acreditar la correcta recuperación de la información y el cumplimiento de los tiempos definidos de RTO y RPO. Asimismo, deberá entregar al HGGB un informe formal de cada prueba realizada, incluyendo resultados, tiempos de recuperación, observaciones y eventuales acciones correctivas.
5. Infraestructura de Red y Seguridad
El oferente deberá considerar dentro de su solución la provisión, implementación y mantenimiento de la infraestructura de red necesaria para la correcta operación del sistema, incluyendo equipos tales como switches, firewalls y demás dispositivos de comunicación requeridos. En este contexto, el firewall será considerado un componente crítico de la solución, debiendo desempeñar un rol central en la protección, control y monitoreo del tráfico de red.
Dichos equipos deberán ser suministrados, instalados, configurados, administrados y mantenidos durante toda la vigencia del convenio, sin costo adicional para el HGGB, debiendo contar con capacidades de administración, montaje en rack y segmentación de red, que permitan un funcionamiento eficiente y acorde a la demanda de la solución.
Deberán considerarse todos los elementos y accesorios asociados, tales como patch cords de cobre, organizadores y demás componentes requeridos. Asimismo, el oferente deberá contemplar la conexión de la solución a la red institucional, siendo todos estos elementos y trabajos de su exclusiva responsabilidad y costo.
La arquitectura de red deberá diseñarse bajo un esquema que garantice la alta disponibilidad, redundancia y escalabilidad, evitando la existencia de puntos únicos de falla y asegurando la continuidad operativa ante contingencias.
Toda la infraestructura de red, incluyendo switches, firewalls y demás componentes críticos, deberá implementarse en esquemas de alta disponibilidad (HA), tales como configuraciones activo-activo o activo-pasivo, según corresponda, garantizando la continuidad del servicio ante la falla de al menos un componente sin interrupción de la operación.
Asimismo, los equipos, en particular el firewall, deberán incorporar funcionalidades de seguridad alineadas con las buenas prácticas, tales como control de acceso, filtrado de tráfico, inspección y monitoreo, que permitan proteger la información, resguardar el tráfico de red y asegurar el acceso continuo y seguro a los sistemas.
El oferente deberá asegurar que la infraestructura de red cuente con la capacidad suficiente para soportar la operación del sistema y su crecimiento proyectado durante toda la vigencia del contrato.
6. Continuidad Eléctrica
El oferente deberá garantizar la continuidad del suministro eléctrico mediante la implementación de sistemas de alimentación ininterrumpida (UPS), con una autonomía mínima de treinta minutos, que permitan mantener la operación de los componentes críticos ante interrupciones del suministro.
La solución deberá considerar la protección de servidores, equipos de red y demás elementos necesarios para la operación del sistema, mediante mecanismos de respaldo eléctrico y protección ante fallas de energía. Asimismo, se deberá contemplar la implementación de sistemas de monitoreo y alerta ante interrupciones del suministro eléctrico, con el fin de informar oportunamente al personal responsable.
El oferente deberá considerar la provisión e instalación de todos los elementos necesarios para la correcta conexión a la red eléctrica, incluyendo cables de alimentación, enchufes, adaptadores y demás accesorios requeridos para la puesta en marcha de la solución.
El dimensionamiento de estos sistemas deberá ser consistente con la infraestructura implementada y considerar el crecimiento proyectado.
7. Licenciamiento de Software
Todo el software utilizado como parte de la solución deberá estar debidamente licenciado por el oferente, asegurando el cumplimiento de la normativa vigente en materia de propiedad intelectual.
El modelo de licenciamiento deberá garantizar el acceso completo a todas las funcionalidades del sistema, permitiendo el uso simultáneo por parte de todos los usuarios definidos por el HGGB, sin restricciones ni costos adicionales por instalación en estaciones de trabajo institucionales.
El oferente será responsable de mantener la vigencia, actualización y cumplimiento de las licencias durante toda la duración del contrato, considerando el crecimiento proyectado.
El HGGB podrá solicitar en cualquier momento la acreditación del licenciamiento, debiendo el oferente proporcionar la documentación correspondiente que respalde su cumplimiento.
8. Soporte, Monitoreo y Mantención
El oferente deberá proporcionar un servicio integral de soporte, monitoreo y mantención que garantice la continuidad operativa del sistema y de toda la infraestructura asociada durante toda la vigencia del contrato.
El servicio deberá operar en modalidad continua, 24 horas al día, 7 días a la semana (24x7), contemplando monitoreo permanente y proactivo de todos los componentes de la solución, incluyendo servidores, red, almacenamiento, servicios y aplicaciones, permitiendo la detección temprana de incidentes, degradaciones de rendimiento y eventos de seguridad.
El oferente deberá disponer de canales formales de atención, los cuales deberán estar claramente definidos y operativos, permitiendo la gestión estructurada de incidentes, asegurando su registro, categorización, seguimiento y trazabilidad completa.
La atención de incidentes deberá realizarse de forma remota o presencial según la criticidad, debiendo el oferente garantizar la disponibilidad permanente de personal técnico calificado.
El soporte presencial deberá ser proporcionado cuando el HGGB lo requiera, sin costo adicional. Esto incluye reuniones y/o coordinaciones para planificaciones de todo tipo de soportes.
El oferente deberá gestionar el ciclo completo de los incidentes, desde su identificación hasta su resolución y cierre, incluyendo la aplicación de medidas correctivas y preventivas que eviten su recurrencia.
Asimismo, el oferente deberá implementar y mantener procedimientos formales de gestión de cambios, asegurando que toda modificación a la infraestructura o al sistema sea planificada, evaluada, aprobada y ejecutada de manera controlada, sin afectar la continuidad operativa.
El incumplimiento de cualquiera de las condiciones establecidas en la presente sección será considerado para efectos de la aplicación de las sanciones y multas definidas en el contrato.
9. Niveles de Servicio (SLA) y Reportabilidad
El oferente deberá cumplir estrictamente los acuerdos de nivel de servicio (SLA) establecidos en las presentes bases, los cuales serán de carácter obligatorio y vinculante durante toda la vigencia del contrato.
Para efectos de la medición del servicio, se considerarán incidentes todos aquellos eventos que afecten la operación del sistema, incluyendo caídas de aplicaciones, indisponibilidad de la infraestructura, lentitud en la operación o fallas en componentes críticos.
La medición del nivel de servicio se realizará en función del tiempo de indisponibilidad del sistema y/o integraciones, el cual será contabilizado desde la generación del ticket por parte del Hospital, el que podrá ser registrado por cualquier funcionario autorizado.
Los eventos de indisponibilidad se clasificarán conforme a los siguientes rangos:
- Entre 4 y 10 minutos: afectación leve
- Entre 11 y 30 minutos: afectación moderada
- Superior a 31 minutos: afectación grave
Estos rangos serán utilizados como base para la aplicación de las sanciones y multas definidas en el contrato.
El oferente deberá garantizar una disponibilidad mínima mensual del sistema de 99,9%, medida sobre la totalidad de los servicios provistos. Para efectos de este cálculo, se excluirán únicamente las ventanas de mantención programadas previamente autorizadas por el HGGB.
El oferente deberá garantizar la disponibilidad continua de la infraestructura, la correcta operación de los servicios, la ejecución oportuna de respaldos y el adecuado funcionamiento de todos los componentes que forman parte de la solución.
Asimismo, el oferente deberá proporcionar reportes periódicos al HGGB, los cuales deberán incluir, a lo menos, indicadores de disponibilidad del sistema, incidentes registrados, tiempos de indisponibilidad, estado de respaldos y desempeño general de la infraestructura. Este reporte periódico deberá ser mensual.
El incumplimiento de los niveles de servicio comprometidos dará lugar a la aplicación de las sanciones y multas establecidas en el contrato.
10. Procedimientos de Contingencia en caso de Falla del Sistema
Con el fin de lograr la continuidad operacional de los procesos, el proveedor deberá diseñar solución, documentos, y en consecuencia proponer un plan de contingencia que, al menos:
a) Asegure el normal desarrollo de la producción.
b) Asegure generar solicitudes de exámenes y su procesamiento.
c) El manual de procedimiento contingencia debe ser validado por el hospital.
d) Considere la existencia de aplicaciones computacionales especiales que respalden el trabajo frente a la ausencia del sistema y permitan que los datos almacenados, sean masivamente cargados una vez que éste se haya recuperado de su mal funcionamiento o interrupción.
11. Interoperabilidad
El sistema ofertado debe ser capaz de integrarse obligatoriamente y sin costo alguno con los sistemas utilizados por el HGGB en cualquier parte del proceso (Pre Analítica, Analítica y Post Analítica), sean estos de desarrollo local como de proveedores externos. Es necesario que interopere con la Ficha Electrónica SIRYC, SinetSur y/o como también aquellos que la institución determine durante el periodo de licitación.
Es responsabilidad del proveedor ajustar su sistema a petición del hospital para llevar a cabo las integraciones que se soliciten. Las integraciones deberán realizarse mediante servicios web o APIs, siguiendo estándares internacionales de intercambio de información en salud como HL7 FHIR o en su defecto como el hospital lo requiera. Deben manejar códigos de mensajería estándares en cada request. Ejemplo:
200 OK: La solicitud se ha realizado correctamente.
201 Created: La solicitud se ha completado y se ha creado un nuevo recurso.
400 Bad Request: La solicitud no se pudo entender debido a un error de sintaxis.
401 Unauthorized: La solicitud requiere autenticación.
403 Forbidden: La solicitud no tiene permisos para acceder al recurso.
404 Not Found: El recurso solicitado no existe.
500 Internal Server Error: Ha ocurrido un error inesperado en el servidor.
12. Ambientes de trabajo
El sistema de anatomía patológica deberá contar con, al menos, los siguientes ambientes separados:
- Producción: para el funcionamiento normal con información real.
- Testing/QA: para pruebas de integración y validación de cambios.
- Desarrollo: para pruebas técnicas y configuraciones previas.
Estos ambientes deberán estar disponibles para la institución al momento de realizar integraciones, pruebas y capacitaciones.
13. Flexibilidad y escalabilidad
El sistema deberá permitir ampliar los procesos de integración y/o solución completa según lo defina la institución en etapas posteriores.
La integración deberá realizarse de manera que no condicione ni limite la evolución tecnológica de la FCE institucional y/o de procesos que se deseen implementar.
De igual manera el hospital podría solicitar desarrollos de nuevas funcionalidades para dar respuesta a nuevos procesos o procesos ya existentes, las cuales deben ser sin costo.
El oferente deberá garantizar la disponibilidad de interfaces de integración y la colaboración técnica necesaria para llevar a cabo las integraciones que la institución solicite.
Los costos de la adecuación del software para cumplir con nuevos requerimientos estarán incluidos en la oferta.
14. Documentos del Sistema Informático
Deberá suministrarse la siguiente documentación del Sistema informático, la cual deberá estar en idioma español:
a) Layout de las pantallas con descripciones
b) Flujograma del sistema
c) Manual del usuario
d) Manual de administrador
e) Manual de operaciones
f) Manual de instalación del sistema
g) Manual de seguridad, incluyendo el sistema de recuperación en caso de desastres.
h) Modelo de datos del sistema
i) Diccionario de datos del sistema
16. Implementación y Puesta en Marcha: Plan de Trabajo
Los oferentes deberán presentar un Plan de Trabajo que considere un completo plan de implementación y puesta en marcha del SISTEMA, el cual, consigne todas y cada una de las actividades propias de la ingeniería de software para la implementación de sistemas de este tipo. En un plano no mayo a 180 dias
Este plan deberá considerar los plazos necesarios para cada etapa de implementación, los responsables y los requerimientos a cumplir por parte tanto del proveedor como del cliente. Este plan debe ser aprobado y firmado por el director técnico del Hospital y el referente del área Informática del HGGB.
Se solicita que el plan de implementación considere al menos las siguientes fases o que presente un plan acorde o similar al siguiente:
a) Inicio
Deberá contemplar todas las actividades para el inicio del Proyecto, incluyendo presentación de los equipos de trabajo del cliente y del proveedor, modelo de trabajo, cronograma, definir perfiles y responsabilidades. Reuniones para analizar en detalle propuesta de integración, ambientes de prueba, desarrollo y otras actividades propias del inicio del proyecto. Es requisito la disponibilidad del personal involucrado en fechas acordadas en cronograma.
b) Instalación de Hardware y Software
Deberá contemplar la instalación de Hardware y componentes del software central para funcionamiento.
- Servidor de Aplicación/Base de datos (Mirror)
- Servidor de Aplicaciones
- Equipamiento
- Aplicaciones en cliente usuario Clínico y/o administrativo, ETC.
Este plan debe incluir la definición del equipamiento necesario para operar el sistema adecuadamente. Para lo cual, el proveedor debe realizar un levantamiento de requerimientos tecnológicos, tanto para trabajar dentro del HGGB como fuera de él si el hospital lo requiere.
17. Capacitaciones:
El proveedor deberá ejecutar la totalidad de las capacitaciones definidas en las Especificaciones Técnicas, incluyendo capacitación de usuarios y de administradores, conforme al alcance total del sistema.
Estas capacitaciones deberán realizarse obligatoriamente de manera previa a la puesta en marcha del sistema, como requisito para su implementación.
Asimismo, el proveedor deberá realizar capacitaciones posteriores a la puesta en marcha, cada vez que el hospital lo requiera, sin limitación de tiempo, con el objetivo de reforzar conocimientos, capacitar nuevos usuarios o abordar cambios en la operación del sistema.
La definición de fechas, cantidad de sesiones, perfiles de usuarios y alcance de las capacitaciones será determinada por el hospital, conforme a sus necesidades operativas.
El incumplimiento de estas obligaciones dará lugar a la aplicación de las multas establecidas.
18. Soporte en terreno durante la puesta en marcha:
Una vez iniciada la puesta en marcha del sistema, el proveedor deberá disponer de soporte en terreno mediante la presencia de personal especializado, por un período de 30 días hábiles consecutivos, con dedicación acorde a la operación del establecimiento.
Este soporte deberá considerar acompañamiento directo a los usuarios en su operación diaria, resolución de dudas, apoyo en la ejecución de procesos, gestión de incidencias y monitoreo del correcto funcionamiento del sistema en ambiente productivo.
El hospital podrá definir la distribución horaria, cobertura, y solicitar la extensión de este período en función de las necesidades operativas y el nivel de adopción del sistema en caso que se requiera.
19. Configuración data existente
El proveedor adjudicatario deberá considerar el traspaso o conexión en línea de toda la información histórica disponible en los sistemas actuales del Hospital. Esto implica la migración completa de los datos gestionados por el proveedor saliente hacia la base de datos del nuevo sistema, dejándolos disponibles y operativos mediante integraciones u otros mecanismos que el Hospital defina.
La migración deberá garantizar la integridad, consistencia y trazabilidad de la información traspasada. El proceso de migración previa es un requisito obligatorio y condición indispensable para la puesta en marcha del sistema, por lo que no se autorizará el inicio de operaciones sin su cumplimiento total y verificado.
20. Migración de Datos
El Adjudicatario deberá asesorar y acompañar activamente al HGGB durante la transición hacia un nuevo proveedor, elaborando y entregando un Plan de Migración que abarque la totalidad de las plataformas instaladas.
Dicho plan deberá contemplar, a lo menos, lo siguiente:
- Entrega del 100% de los datos y documentación ingresados al sistema, conforme a los plazos y condiciones definidos en Implementación y Puesta en Marcha: Plan de Trabajo
- Modelos de datos actualizados y documentación técnica completa que permita la migración hacia otra plataforma tecnológica sin pérdida de información.
El incumplimiento de cualquiera de estas obligaciones será considerado falta grave en los términos del contrato.
El formato de salida de la data existente la definirá el hggb.
21. Monitoreo del Departamento TIC
El proveedor deberá garantizar al Departamento de Tecnologías de la Información y Comunicaciones (TIC) del HGGB el acceso irrestricto, en cualquier momento que este lo requiera, a los servidores, bases de datos y demás componentes de infraestructura asociados al sistema contratado.
El alcance de los permisos, roles y privilegios de acceso será definido unilateralmente por el HGGB, reservándose la institución el derecho de ampliarlos o modificarlos según las necesidades operacionales y de seguridad que se presenten. El proveedor no podrá restringir, condicionar ni limitar dicho acceso bajo ninguna circunstancia.
|
Especificaciones Técnicas Sistema Anatomía Patológica
|
|
|
|
|
Nombre de la empresa oferente
|
|
|
|
Marca del equipo ofertado
|
|
|
|
Modelo del equipo ofertado
|
|
|
|
Garantía ofrecida (meses)
|
|
|
|
Plazo entrega (meses)
|
|
|
|
|
|
|
|
|
Item
|
Requerimiento
|
Obligatoriedad
|
Cumplimiento [Si/No]
|
|
|
|
Integración
|
|
|
|
|
1
|
Con el sistema HIS y Ficha Electrónica del Hospital, utilizando protocolos de interoperabilidad entre sistemas como webservices, apis o como el hggb lo defina, y a los sistemas que el hospital defina, que puede ser ficha clínica u otros.
|
|
|
|
|
|
Características Generales
|
|
|
|
|
2
|
Se debe disponer para usuarios externos a la UAP de una clave única por funcionario para visualización de exámenes dentro de la red del servicio de salud (Hospital y establecimientos externos asociados al Hospital)
|
|
|
|
|
3
|
Se debe disponer para usuarios internos a la UAP de clave única por funcionario, con diferenciación jerárquica de acceso y visualización, de todo el proceso de trabajo de la Unidad.
|
|
|
|
|
4
|
Considerar listado de equipos médicos de la UAP total para su integración.
|
|
|
|
|
5
|
Sistema debe permitir dar vincular (ingreso) y desvincular (dar de baja) a usuarios.
|
|
|
|
|
6
|
El sistema debe registrar los tiempos asociados a todo el proceso de laboratorio desde la solicitud y hasta la entrega de los resultados.
|
|
|
|
|
7
|
Registro de todos los profesionales de la salud que participan en el proceso.
|
|
|
|
|
8
|
Debe permitir cotejo de muestras e hito de control a través de chequeo de control por Pistolas lector de código de barra, datamatrix 1 o 2 D o QR o sistema equivalente técnico.
|
|
|
|
|
9
|
Toda la información generada en el sistema APA debe estar disponible en los servidores ubicados en el datacenter del Hospital.
|
|
|
|
|
|
Función Solicitud y Toma de muestras
|
|
|
|
|
10
|
Identificar al paciente según su Rut o pasaporte, Numero de ficha. En el caso de recién nacidos considerar el Rut de la madre, Rut provisorio del NN o correlativo que permita identificar al individuo de manera única. Debe permitir el ingreso de pacientes no identificables como NN. Además, debe poseer algoritmo de comprobación de RUT incorporado.
|
|
|
|
|
11
|
Al identificar por Rut al paciente, el sistema APA permite obtener la información demográfica de los pacientes (nacionalidad: extranjero/chilena), fecha de nacimiento, edad (años, meses), nombres, apellidos, sexo), desde el sistema HIS del Hospital e importarla a través de una integración con el sistema APA. Esta información debe ser mantenida en el tiempo en el sistema APA. Asimismo, esta información demográfica debe ser adjuntada al resultado del examen en cada evento, asociados a la ficha clínica. En el caso de no existir integración con sistema HIS, el sistema APA debe permitir incorporar la información requerida en el servicio donde se genera la muestra.,
|
|
|
|
|
12
|
Al identificar por Rut al paciente, el sistema APA permite obtener la información clínica de los pacientes (N° de ficha Clínica, GES, Previsión, Tipo Paciente, Servicio clínico de origen del paciente, antecedentes clínicos, diagnóstico clínico previo), desde el sistema HIS del Hospital e importarla a través de una integración con el sistema APA. Esta información debe ser mantenida en el tiempo en el sistema APA. Asimismo, esta información demográfica debe ser adjuntada al resultado del examen en cada evento, asociados a la ficha clínica. En el caso de no existir integración con sistema HIS, el sistema APA debe permitir incorporar la información requerida en el servicio donde se genera la muestra., y las integraciones que el hospital defina.
|
|
|
|
|
13
|
Permitir solicitar múltiples exámenes a la muestra (Citología miscelánea, Biopsia y Necropsia). El sistema APA debe desplegar las opciones requeridas.
|
|
|
|
|
14
|
El sistema debe permitir incorporar la información relacionada a :
- Tipo Examen (Biopsia / Estudio células neoplásicas)
- Tipo Biopsia (Institucional/pensionado/otro)
- Antecedentes clínicos Relevantes
- Biopsias previas (diagnostico/ n° caso)
- Órgano o tejido
- Cantidad de Órganos o tejidos
- Nombre del médico
- Servicio clínico de toma de muestra
Además en el caso de citología, se debe incorporar:
- Identificación del portaobjeto
- Nombre completo persona que rotula la citología.
|
|
|
|
|
15
|
En el caso de que la muestra sea tomada en horario no hábil de entrega de la UAP, el sistema debe permitir categorizarla en modo custodia y desplegar los elementos de dicho modulo.
|
|
|
|
|
16
|
Permite imprimir etiqueta con la información necesaria de identificación de la muestra.
|
|
|
|
|
17
|
Permitir registrar al profesional de la salud con su orden en el sistema APA.
|
|
|
|
|
18
|
Permite la impresión de la emisión de la solicitud de toma de muestras de biopsia con hora y fecha.
|
|
|
|
|
19
|
Permite programación de funcionarios por turnos asociados a la producción de la Unidad.
|
|
|
|
|
20
|
Permite vincular ubicaciones con fines de trazabilidad de la muestra
|
|
|
|
|
21
|
Todo el proceso debe estar debidamente registrado y disponible por concepto de auditorías
|
|
|
|
|
22
|
Los campos a rellenar en el módulo de solicitud son obligatorios. El sistema debe ser capaz de alertar al usuario cuando existen campos vacíos. Dicho procedimiento debe ser trazable y el usuario autenticable.
|
|
|
|
|
23
|
Una vez que el usuario envía la solicitud, el sistema debe imprimir un comprobante. El sistema no debe permitir enmiendas posteriores al envío de la solicitud.
|
|
|
|
|
|
Módulo Admisión/ Recepción UAP (Preanalítica)
|
|
|
|
|
24
|
Sistema debe desplegarse en áreas de secretaría y recepción de muestras.
|
|
|
|
|
25
|
Debe permitir cotejo de muestras e hito de control a través de chequeo de control por Pistolas lector de código de barra, datamatrix 1 o 2 D o QR o sistema equivalente técnico.
|
|
|
|
|
26
|
Al realizar la lectura de la etiqueta de la muestra, el sistema debe desplegar en el módulo la información respectiva
|
|
|
|
|
27
|
Permite la unificación de RUT en el caso de equivocaciones, duplicaciones y pacientes no identificables
|
|
|
|
|
28
|
Permitir que cada solicitud de examen posea un código correlativo interno inequívoco para evitar problemas con la ejecución de estos o para efectos de auditoría interna.
|
|
|
|
|
29
|
Debe permitir el rechazo de muestras.
|
|
|
|
|
30
|
Al seleccionar rechazo de la muestra, el sistema APA debe permitir incorporar el motivo del rechazo de la muestra en un cuadro de observaciones.
|
|
|
|
|
31
|
Permite el registro de las ubicaciones de origen de las muestras (servicios, laboratorios etc.)
|
|
|
|
|
32
|
Permite la definición de roles asociados a la recepción de muestras (secretaria, TPM, entre otros.)
|
|
|
|
|
33
|
Permitir recepción de muestras de biopsias rápidas (intraoperatoria)
|
|
|
|
|
34
|
En caso de falla en la conectividad del sistema con el HIS, el sistema deberá poder registrar su origen manualmente para su ingreso y además generar una etiqueta con códigos. Se debe considerar el registro e identificación del paciente individualizado (admisión) y también permitir adjuntar la orden de exámenes manual.
|
|
|
|
|
35
|
Permite el registro de datos de la persona que recibe, fecha, hora, funcionario y servicio clínico de origen.
|
|
|
|
|
36
|
Permitir la emisión de reportes de rechazo de muestras y/o especímenes con su respectivo código de rechazo y solicitante, durante un período de tiempo específico.
|
|
|
|
|
37
|
Permite obtener la información demográfica de los pacientes (fecha de nacimiento, edad, RUT, nombres, apellidos, sexo), desde el sistema HIS del Hospital e importarla a través de una integración con el sistema APA. Esta información debe ser mantenida en el tiempo en el sistema APA. Asimismo, esta información demográfica debe ser adjuntada al resultado del examen en cada evento, asociados a la ficha clínica. En el caso de no existir integración con sistema HIS, el sistema APA debe desplegar esta información en el módulo de recepción UAP.
|
|
|
|
|
38
|
Desplegar en pantalla la información del paciente referida al paciente según su Rut o pasaporte. En el caso de recién nacidos considerar el Rut de la madre o correlativo que permita identificar al individuo de manera única. Debe permitir el ingreso de pacientes no identificables como NN. Además, debe poseer algoritmo de comprobación de RUT incorporado.
|
|
|
|
|
39
|
Permite obtener la información clínica de los pacientes (GES, Previsión, Tipo Paciente, Servicio clínico, antecedentes clínicos, diagnóstico clínico previo), desde el sistema HIS del Hospital e importarla a través de una integración con el sistema APA. Esta información debe ser mantenida en el tiempo en el sistema APA. Asimismo, esta información demográfica debe ser adjuntada al resultado del examen en cada evento, asociados a la ficha clínica. En el caso de no existir integración con sistema HIS, el sistema APA debe desplegar la información requerida para ser visualizada en la UAP.
|
|
|
|
|
40
|
Permitir que cada solicitud de examen posea un código correlativo interno inequívoco para evitar problemas con la ejecución de estos o para efectos de auditoría interna.
|
|
|
|
|
41
|
Sistema genera con la información incorporada en las etapas previas un pre-informe de biopsia.
|
|
|
|
|
42
|
Permitir la creación de códigos de seguimiento para cada caso que identifiquen la solicitud y contenedor recepcionado, sus casetes y laminas, según el estándar del Hospital.
|
|
|
|
|
43
|
Permite imprimir etiqueta con la información necesaria de identificación de la muestra en la impresora de etiquetas de sala de recepción.
|
|
|
|
|
|
Módulo Macroscopía
|
|
|
|
|
44
|
Debe permitir cotejo de muestras e hito de control a través de chequeo de control por Pistolas lector de código de barra, datamatrix 1 o 2 D o QR o sistema equivalente técnico.
|
|
|
|
|
45
|
Al realizar la lectura de la etiqueta de la muestra, el sistema debe desplegar en el módulo la información respectiva.
|
|
|
|
|
46
|
Permite incorporar en el registro inicial el código Fonasa asignado a cada uno de los exámenes a solicitar.
|
|
|
|
|
47
|
Sistema debe permitir a través de dictáfono con reconocimiento de voz, el incorporar en el sistema APA las características de la muestra recibida.
|
|
|
|
|
48
|
El sistema debe permitir conectarse con la impresora de casetes para realizar las impresiones con los códigos correspondientes. Debe permitir autenticar al TPM responsable del proceso.
|
|
|
|
|
49
|
El sistema APA debe registrar:
- El patólogo de turno que realiza la macroscopía
- Fecha de la macroscopía
- Numero de la muestra
- Órgano
- Número de cortes
- Número de casetes
- Técnicas histoquímicas solicitadas
|
|
|
|
|
50
|
El sistema debe permitir imprimir el dictado realizado en el sistema por el AP del proceso de macroscopía para ser adjuntado a la solicitud de biopsia en papel y las láminas histológicas que saldrán del laboratorio en los procesos siguientes
|
|
|
|
|
|
Módulo Laboratorio
|
|
|
|
|
51
|
Permitir acceso a la lista de trabajo en cada módulo de corte.
|
|
|
|
|
52
|
Permitir registrar cada paso realizado.
|
|
|
|
|
53
|
Permitir reutilizar un mismo número de identificación por si se deben realizar nuevas prestaciones o tinciones.
|
|
|
|
|
54
|
Permitir generación y configuración de estadísticas de laboratorio (tiempos, resultados etc.)
|
|
|
|
|
55
|
El sistema debe permitir el cotejo de cantidad y numero de casetes y laminas histológicas coincidan con los datos registrados desde el proceso de inclusión, cortes, tinción y montaje y salida de laboratorio.
|
|
|
|
|
56
|
El sistema debe permitir imprimir el numero de biopsia a incorporar al portaobjeto, ya sea en impresora de láminas portaobjeto y en impresora de etiquetas para lámina portaobjeto (dependiendo la zona en la que se encuentre). Debe permitir autenticar al TM responsable del proceso.
|
|
|
|
|
57
|
Permite cotejar luego de la etapa de tinción y montaje, que las láminas histológicas coincidan con el numero y cantidad de los datos registrados.
|
|
|
|
|
58
|
Debe permitir cotejo de muestras e hito de control a través de chequeo de control por Pistolas lector de código de barra, datamatrix 1 o 2 D o QR o sistema equivalente técnico.
|
|
|
|
|
59
|
Permitir cotejar y dejar constancia de las muestras chequeadas en el sistema. Debe permitir autenticar al TM responsable del proceso.
|
|
|
|
|
|
Módulo Análisis Microscopía
|
|
|
|
|
60
|
Permite incorporar en el registro inicial el código Fonasa asignado a cada uno de los exámenes a solicitar.
|
|
|
|
|
61
|
Permite consultar: paciente, medico solicitante, exámenes solicitados e información de la trazabilidad de la muestra.
|
|
|
|
|
62
|
El sistema debe permitir incorporar el cotejo de coincidencia de orden de biopsia, numero de biopsia, datos del paciente, borrador de macroscopía con el numero y cantidad de láminas histológicas
|
|
|
|
|
63
|
En el caso de que la lámina entregada al AP requiera de una nueva técnica, se debe considerar dentro del sistema el registro de entrega de la lámina a laboratorio para la realización de dicha solicitud. Este requerimiento debe ser trazable y tanto el AP como el TM deben ser autenticables. Debe registrar fecha y hora del proceso de solicitud, fecha y hora de entrega de la lámina con la nueva técnica realizada.
|
|
|
|
|
64
|
El sistema debe permitir ingresar el diagnostico Anatomo patológico en pre-informe de macroscopía, consignando fecha de diagnóstico.
|
|
|
|
|
65
|
El sistema de reconocimiento de voz y el sistema APA deben permitir incorporar el diagnóstico anatomo patológico al pre-informe de macroscopía que se encuentra dentro del sistema APA.
|
|
|
|
|
66
|
Permitir impresión del informe.
|
|
|
|
|
67
|
En el caso de que el AP tenga laminas pendientes a revisar, el sistema no debe generar el informe anatomo patológico, se debe generar alarma de aviso en estos casos.
|
|
|
|
|
68
|
El sistema permite incorporar información adicional o complementaria que no se encontraba en la información previa entregada.
|
|
|
|
|
69
|
Para prestaciones que se realizan en el extrasistema (Unidad de Anatomía Patológica externa al establecimiento), el sistema debe permitir el ingreso de estos informes al sistema APA.
|
|
|
|
|
70
|
Para biopsias de resultado crítico, el sistema debe permitir realizar la notificación al servicio clínico que realizo la solicitud inicial del examen. Este requerimiento debe ser trazable.
|
|
|
|
|
71
|
Debe incluir Codificación Cod. Cie-O y Codificación TNM
|
|
|
|
|
72
|
El sistema debe entregar un listado de las biopsias a despachar, incorporando:
- Fecha de control del paciente
- Unidad o servicio donde va dirigido el examen
|
|
|
|
|
73
|
El sistema debe unificar la información de todos los hitos del proceso (pre-informe de macroscopía / datos clínicos / datos demográficos / técnicas realizadas / conclusión diagnóstica, entre otros) en un único informe de entrega de resultado. Esta información debe estar desplegada en pantalla en el formato de informe establecido por la UAP.
|
|
|
|
|
|
Función Diagnóstico Resultado/ Despacho
|
|
|
|
|
74
|
Permitir impresión en PDF de los informes resultados desde el sistema APA a las impresoras conectadas
|
|
|
|
|
75
|
Permitir transmitir reportes de exámenes con su N.º de folio (identificador único de examen) correspondiente y Rut de paciente.
|
|
|
|
|
76
|
Para biopsias de resultado crítico, el sistema debe permitir realizar la notificación al servicio clínico que realizo la solicitud inicial del examen. Este requerimiento debe ser trazable.
|
|
|
|
|
|
Función Recepción informe diagnóstico
|
|
|
|
|
77
|
El sistema en las unidades o servicios clínicos donde recepcionan dichos exámenes deben consignar como recibido el diagnostico entregado. Esta información debe ser trazable, y se debe autenticar el profesional de la unidad o servicio clínico que recepción dichos documentos.
|
|
|
|
|
|
Modulo Informe
|
|
|
|
|
78
|
Permite la generación de diversos tipos de informes (informes mensuales), con formatos a definir por el usuario al momento de la adjudicación, con la siguiente información como mínimo:
|
|
|
|
|
79
|
Resultado crítico
|
|
|
|
|
80
|
Informes de estadísticas
|
|
|
|
|
81
|
Informes anatomo patológicos
|
|
|
|
|
82
|
Informes de trazabilidad de informes despachados
|
|
|
|
|
83
|
Informe Indicador biopsias
|
|
|
|
|
84
|
Evento Adverso
|
|
|
|
|
85
|
Evento centinela
|
|
|
|
|
86
|
Permitir la consulta de resultados asociados al profesional tratante.
|
|
|
|
|
|
Modulo Fallecidos
|
|
|
|
|
87
|
Para el área de Fallecidos, el sistema debe permitir ingresar la solicitud de despacho desde el servicio donde ocurrió el deceso y luego el ingreso a la UAP.
|
|
|
|
|
88
|
En el caso de personas fallecidas sin identificación, el sistema debe permitir incorporar para el ingreso a la UAP:
|
|
|
|
|
89
|
• Nombre y apellido que permita utilizar las siglas NN
|
|
|
|
|
90
|
• Sexo
|
|
|
|
|
91
|
• Estado de ingreso a la UAP
|
|
|
|
|
92
|
• Fecha de ingreso a la UAP
|
|
|
|
|
93
|
• Hora de ingreso a la UAP
|
|
|
|
|
94
|
• Encargado del ingreso
|
|
|
|
|
95
|
Para el retiro:
|
|
|
|
|
96
|
• Encargado de la entrega del cadáver perteneciente a la UAP.
|
|
|
|
|
97
|
• Fecha de retiro del cadáver desde la UAP.
|
|
|
|
|
98
|
• Hora de retiro del cadáver desde la UAP.
|
|
|
|
|
99
|
• Encargado de retiro del cadáver desde la UAP.
|
|
|
|
|
100
|
• Atributo de encargado de retiro del cadáver (familiar, funeraria, SML, otro)
|
|
|
|
|
|
Modulo Casos Críticos
|
|
|
|
|
101
|
El sistema debe registrar y almacenar todos los casos incorporados a biopsias con resultado crítico.
|
|
|
|
|
102
|
El sistema debe generar alarmas en caso de que dichas biopsias no hayan sido notificadas o entregadas.
|
|
|
|
|
103
|
Al designar una biopsia como caso crítico, el sistema debe consultar si efectivamente dicha biopsia tendrá esta categoría, en el caso de ser favorable, la biopsia no puede modificar su categorización.
|
|
|
|
|
|
Modulo Custodias
|
|
|
|
|
104
|
En caso de que la muestra no pueda ser entregada el día de la extracción en el horario hábil de recepción de la UAP, el sistema debe permitir registrar la trazabilidad de la muestra a través del módulo de biopsias.
|
|
|
|
|
105
|
Para las biopsias que se extraen en horario que no permite realizar entrega a la UAP, el sistema debe permitir realizar ingreso de la muestra para biopsia en el sistema - modulo custodia, como mínimo con los siguientes parámetros:
- Fecha inicio custodia
- Hora inicio custodia
- Etiqueta (datos del paciente (nombre completo, Rut), tipo biopsia, órgano o tejido, entre otros)
- Nombre Funcionario
- Fecha termino custodia
- Hora termino custodia
|
|
|
|
|
106
|
La información contenida en el módulo custodias, debe ser trazable y el usuario autenticable.
|
|
|
|
|
|
Modulo Gestión
|
|
|
|
|
107
|
permitir generación y configuración de estadísticas de laboratorio (tiempos, resultados etc.)
|
|
|
|
|
108
|
Indicadores de calidad configurables para:
|
|
|
|
|
109
|
Preanalítica.
|
|
|
|
|
110
|
Laboratorio.
|
|
|
|
|
111
|
Rechazo de Biopsias.
|
|
|
|
|
112
|
Situaciones de Riesgo (notificación de resultados críticos)
|
|
|
|
|
113
|
Trazabilidad de biopsias despachadas.
|
|
|
|
|
114
|
Tiempo de informes de biopsias diferidas.
|
|
|
|
|
115
|
Permite acceder al historial de las solicitudes, tomas de muestra, prestaciones realizadas y exámenes por paciente.
|
|
|
|
|
116
|
Permitir la emisión de reportes de exámenes efectuados por solicitante durante períodos configurables.
|
|
|
|
|
|
Archivo y Reserva de Muestras
|
|
|
|
|
117
|
Control de archivo de material procesado (Casetes y Portaobjetos), registro de préstamos/salidas de material, solicitante y fechas.
|
|
|
|
|
118
|
Control de Reserva de muestra, considerando eliminación por vencimiento y reutilización para nuevos análisis.
|
|
|
|
|
119
|
Sistema permite generar estadística en base a tipos de patología, información demográfica, entre otros.
|
|
|
|
|
|
Modulo Gestión - Estadísticas
|
|
|
|
|
120
|
Permitir realizar estadística, obtener reportes de exámenes ejecutados por unidad de trabajo en un cierto periodo de tiempo.
|
|
|
|
|
121
|
Permitir generar informes y reportes personalizados según las necesidades del Hospital durante la vigencia del contrato.
|
|
|
|
|
122
|
Sistema permite generar estadística en base a tipos de patología, información demográfica, entre otros.
|
|
|
|
|
123
|
análisis estadístico en relación a informes, tiempos de resolución, AP correspondiente, productividad.
|
|
|
|
|
124
|
Mantiene histórico de prestaciones realizadas
|
|
|
|
|
|
Trazabilidad de la muestra y procesos
|
|
|
|
|
125
|
Permite capturar archivos análogos para ser incorporados al sistema de manera digital.
|
|
|
|
|
126
|
Permite carga de imágenes a la base de datos, tanto de macroscopía como microscopía. Debe permitir autenticar al profesional que realizo la carga del archivo al sistema.
|
|
|
|
|
127
|
El sistema de permitir realizar trazabilidad de las láminas e inclusiones, debe registrar el ingreso y préstamo de estas. El sistema debe ser configurable, en el caso de las láminas como mínimo debe incluir: fechas de ingreso a la bodega, TPM responsable de dicha labor, n° caso, cantidad de láminas ingresadas a bodega, fecha de préstamo, fecha de devolución, AP solicitante, cantidad de láminas a solicitar. En el caso de las inclusiones como mínimo debe incluir: fechas de ingreso a la bodega, TM responsable de dicha labor, n° caso, cantidad de inclusiones ingresadas a bodega, fecha de préstamo, fecha de devolución, AP solicitante, cantidad de inclusiones a solicitar, causal de solicitud, destino provisorio.
|
|
|
|
|
|
Sistema de reconocimiento de voz
|
|
|
|
|
128
|
Integrable con Software de Reconocimiento de voz Dragon
|
|
|
|
|
129
|
Debe permitir el reconocimiento de voz en tiempo real
|
|
|
|
|
130
|
Incorpore entrenamiento inicial breve (máximo 30 minutos) con la aplicación del equipo de reconocimiento.
|
|
|
|
|
131
|
Alta precisión en el reconocimiento de la voz e interpretación inteligente del habla.
|
|
|
|
|
|
Módulo Seguridad
|
|
|
|
|
132
|
Mantenedor con perfiles y roles definidos por usuario y perfiles de acceso
|
|
|
|
|
133
|
Considerar perfil de administrador del servidor para el Hospital
|
|
|
|
|
134
|
Permitir seleccionar campos mandatorios por llenar antes de salir de la pantalla actual, en todos aquellos módulos que la UAP así lo necesite.
|
|
|
|
|
135
|
Registro de todas las operaciones realizadas por cada usuario del sistema con posibilidad de auditorías en pantalla
|
|
|
|
|
136
|
Permite realizar auditorías de trazabilidad sobre las muestras ingresadas
|
|
|
|
|
|
Soporte y Garantía
|
|
|
|
|
137
|
Garantía por un periodo de 36 meses
|
|
|
|
|
138
|
Actualización del software por 36 meses sin costo para el Hospital (Hardware y Software)
|
|
|
|
|
|
Condiciones Generales
|
|
|
|
|
139
|
Demostrar aplicaciones en unidades de Anatomía Patológica en al menos 3 establecimientos de salud chilenos.
|
|
|
|
|
140
|
La Licencia de software debe ser multiusuario, sin costo adicional por estación de trabajo.
|
|
|
|
|
141
|
Posibilidad de adaptarse a forma de trabajo del Laboratorio
|
|
|
|
|
142
|
Permitir migración de informes históricos en formato PDF
|
|
|
|
|
Especificaciones Técnicas Sistema Laboratorio Patología Molecular
|
|
|
|
|
Nombre de la empresa oferente
|
|
|
|
|
Marca del equipo ofertado
|
|
|
|
|
Modelo del equipo ofertado
|
|
|
|
|
Garantía ofrecida (meses)
|
|
|
|
|
Plazo entrega (meses)
|
|
|
|
|
|
|
|
|
|
|
Item
|
Requerimiento
|
Obligatoriedad
|
Cumplimiento [Si/No]
|
|
|
|
|
1.- Gestión Integral del Flujo de Trabajo y Trazabilidad
|
|
|
|
|
|
1
|
Gestión de solicitudes de examen: Debe permitir el ingreso, validación y trazabilidad de solicitudes clínicas, vinculando directamente los tipos de análisis solicitados con el tipo de muestra y protocolos moleculares aplicables
|
|
|
|
|
|
2
|
Definición y seguimiento de flujos de trabajo personalizados: El sistema debe permitir configurar y adaptar flujos de trabajo distintos según protocolos de extracción y técnica molecular (ej. PCR, secuenciación Sanger, NGS, RT-PCR, hibridación, MLPA, entre otras técnicas moleculares). Con posibilidad de monitorear el flujo completo de trabajo, desde la recepción de muestras hasta la emisión del informe a través de un panel de seguimiento visual (workflow chart).
|
|
|
|
|
|
3
|
Asignación de tareas y responsables por etapa: Debe permitir trazabilidad preanalítica, analítica y postanalítica a través del registro de quién realiza cada paso del flujo (extracción, PCR, carga en equipo, validación, informe, etc.), con timestamp y clave (firma digital).
|
|
|
|
|
|
4
|
Identificación de muestras asociadas (por familia, biopsias múltiples, estudios combinados): Permite agrupar muestras que comparten relación clínica o biológica (ej. biopsia primaria vs metástasis, madre-hijo, múltiples tejidos del mismo paciente).
|
|
|
|
|
|
5
|
Definición de plazos críticos y alertas: Debe permitir la asignación de tiempos máximos permitidos por fase (ej. 24 hrs desde recepción a extracción, 72 hrs hasta el informe) con alertas automáticas si se exceden.
|
|
|
|
|
|
6
|
Repeticiones y reanálisis gestionados desde el sistema: Debe permitir el registro de repeticiones técnicas, con motivo, fecha y responsable. Debe permitir diferenciar entre reanálisis por falla técnica o por solicitud médica. Debe generar un registro con el número de veces que se ha procesado una muestra.
|
|
|
|
|
|
7
|
Registro de no conformidades en el flujo de trabajo: Debe permitir registrar eventos como muestras insuficientes, contaminaciones, fallos de controles, incidentes técnicos.
|
|
|
|
|
|
8
|
Gestión de insumos críticos: Debe permitir el registro de consumo de kits, sondas, enzimas, placas, etc., por muestra o batch, asociando lote, caducidad y responsable de uso.
|
|
|
|
|
|
9
|
Seguimiento por código de barras: Debe integrar un sistema de tracking de muestras mediante código de barras o QR, desde la recepción hasta el almacenamiento
|
|
|
|
|
|
10
|
Esperable que permita trazabilidad de controles y estándares por muestra o batch: Debe permitir el registro del uso de controles positivos, negativos, blancos y estándares internos por cada corrida. Debe permitir rastrear fallos por control (ej. control negativo amplificado = falla).
|
|
|
|
|
|
|
2.- Administración de Datos Clínicos y del Paciente
|
|
|
|
|
|
11
|
Ingreso centralizado de información: Debe permitir ingresar los datos una sola vez, desde una interfaz principal y validada. Cada dato clínico debe quedar vinculado desde el inicio con todo el flujo analítico posterior. El ingreso centralizado debe recibir datos automáticamente desde otros sistemas clínicos o administrativos
|
|
|
|
|
|
12
|
Autocompletado inteligente: que reconozca el Rut ingresado previamente, y complete automáticamente los datos demográficos del paciente.
|
|
|
|
|
|
13
|
Adjunto de documentos clínicos: Posibilidad de anexar consentimientos informados, informes anteriores, y otros archivos relevantes al ingreso del paciente.
|
|
|
|
|
|
14
|
Registro estructurado de antecedentes personales y familiares: Debe contar con Campos específicos para historia familiar de cáncer/enfermedades hereditarias, historia personal de enfermedades previas, terapias génicas, trasplantes, entre otros
|
|
|
|
|
|
15
|
Asociación automática a ficha clínica: Integración o vinculación a bases de datos de pacientes institucionales. Visualización de antecedentes moleculares previos, con acceso a detalles técnicos y resultados, para análisis longitudinal del paciente.
|
|
|
|
|
|
|
3.- Gestión Técnica Analítica y Control de Calidad
|
|
|
|
|
|
16
|
Hojas de trabajo dinámicas: Generación automatizada de control de calidad para cada proceso (extracción DNA, extracción RNA, PCR convencional, PCR en tiempo real, secuenciación, entre otros procesos noleculares). Que pueden ser adaptadas al tipo de muestra, análisis o protocolo. Con capacidad para editar, personalizar y actualizar en tiempo real
|
|
|
|
|
|
17
|
Registro de reactivos y controles: Base de datos de reactivos y controles internos/externos con trazabilidad por lote y fecha de vencimiento, con alertas de stock y caducidad.
|
|
|
|
|
|
18
|
Calibración y control de equipos: Módulo para registrar controles de equipos (termocicladores, secuenciadores, espectrofotómetros y otros equipos para trabajo molecular), con seguimiento de fechas y usuarios responsables.
|
|
|
|
|
|
19
|
Validación Analítica: Registro y documentación de la validación analítica de cada protocolo implementado, con posibilidad de adjuntar imágenes de curvas, parámetros y protocolos
|
|
|
|
|
|
20
|
Planificación y registro de mantenimiento preventivo: Debe permitir programar un calendario automatizado de mantenimientos de equipos (ej. calibración termociclador), revisión de protocolos, renovación de validaciones
|
|
|
|
|
|
|
4.- Integración e interoperabilidad del sistema
|
|
|
|
|
|
21
|
Integración con plataformas analíticas: Debe permitir la conectividad con equipos como termocicladores (Applied Biosystems, Bio-Rad), secuenciadores (MiSeq™, SeqStudio, entre otros), sistemas de extracción (QIAcube, Taiwan Advance Nanotech) y análisis bioinformático.
|
|
|
|
|
|
22
|
Importación de Resultados: Capacidad para importar resultados desde archivos.ab1, fasta, .vcf, .csv o generados por software de análisis (ej. Variant Reporter, BaseSpace, entre otros).
|
|
|
|
|
|
23
|
Compatibilidad con Sistemas Clínicos (HIS/LIS): Permite interoperabilidad HL7 para integrar con historias clínicas electrónicas y sistemas de gestión hospitalaria, y las que el hospital defina.
|
|
|
|
|
|
24
|
Exportación de Datos: Funcionalidad para exportar información a formatos estructurados (Excel, CSV, JSON, XML) para análisis externo o respaldo por personal del laboratorio.
|
|
|
|
|
|
|
5.- Generación de Informes
|
|
|
|
|
|
25
|
Plantillas de informes personalizables: Sistema que permita editar y guardar plantillas de informe según tipo análisis (microorganismos o genes analizados).
|
|
|
|
|
|
78
|
Permite la generación de diversos tipos de informes estadísticos (informes mensuales), con formatos a definir por el usuario al momento de la adjudicación
|
|
|
|
|
|
26
|
Integración de elementos gráficos y textuales: Posibilidad de incluir secuencias, gráficos, imágenes de electroferogramas, mutaciones detectadas, entre otros.
|
|
|
|
|
|
27
|
Verificación y Firma Digital: Sistema que permita revisión, validación y firma electrónica del informe por parte del profesional responsable.
|
|
|
|
|
|
28
|
Control de calidad automático previo a la generación del informe: El sistema debe incluir una etapa de verificación automática de criterios mínimos de calidad, antes de permitir generar el informe (ej. Concentración DNA/RNA, Control interno de amplificabilidad, Presencia de amplificación en control positivo, ausencia de amplificabilidad de control negativo, %Q30, profundidad mínima de cobertura, entre otros). Posibilidad de incluir una sección automática de “Evaluación de Calidad Técnica” dentro del informe
|
|
|
|
|
|
29
|
Interpretación automatizada o asistida por reglas: El sistema debe permitir definir reglas automatizadas de interpretación basadas en el tipo de gen analizado, mutación detectada, tipo de variante (benigna, patogénica, VUS), Guías clínicas (ej. ACMG para variantes germinales). Estas reglas pueden autocompletar parte del informe o sugerir texto que luego es validado por el profesional.
|
|
|
|
|
|
30
|
Biblioteca de interpretaciones clínicas: Repositorio editable de interpretaciones previas (por gen, variante, patología), que permite reutilizar comentarios clínicos validados, mantener consistencia en informes similares, acelerar la redacción de informes
|
|
|
|
|
|
31
|
Asociación a guías clínicas y enlaces externos: El informe puede incluir enlaces o citas automáticas a guías clínicas vigentes (ej. NCCN, ESMO, ACMG), bases de datos (ClinVar, COSMIC, LOVD, OncoKB), documentación complementaria relevante para el médico
|
|
|
|
|
|
32
|
Secciones condicionales y dinámicas: El sistema debe permitir activar o desactivar secciones del informe según el tipo de análisis (ej. “Interpretación germinal”, “Recomendaciones terapéuticas”, “Resultados bioinformáticos”, etc.). Soporte para informes simples (ej. mutación puntual) y informes estructurados complejos (con múltiples genes, múltiples variantes, gráficos de cobertura, entre otros)
|
|
|
|
|
|
33
|
Gestión de informes preliminares vs. definitivos: Posibilidad de generar informes preliminares, con marcado de estado (“pendiente de validación”, “informe parcial”) que no pueden ser enviados oficialmente. Mecanismo para marcar como versión final firmada, con bloqueo de edición posterior.
|
|
|
|
|
|
34
|
Generación de informes comparativos o longitudinales (Seguimiento de enfermedad mínima residual): El sistema permite generar informes que comparen resultados actuales con anteriores del mismo paciente, destacando nuevas variantes o cambios clínicos.
|
|
|
|
|
|
|
6.- Distribución de informes:
|
|
|
|
|
|
35
|
Control de versiones y bloqueo de informe: Permite asegurar que solo la versión final y validada del informe pueda ser distribuida. Mecanismo de bloqueo del informe una vez firmado digitalmente para evitar cambios posteriores. Historial de versiones accesible solo para usuarios autorizados.
|
|
|
|
|
|
36
|
Módulo de revisión automática previa al envío con chequeo de: Datos obligatorios (RUT, nombre del médico, diagnóstico completo, firma). Coherencia entre muestra y técnica. Existencia de firma digital válida
|
|
|
|
|
|
38
|
Firma electrónica avanzada: Soporte para firmas electrónicas simples y/o avanzadas con validación criptográfica (según normativa chilena). Registro de usuario firmante, fecha, IP o dispositivo de firma.
|
|
|
|
|
|
39
|
Envío automatizado por canal definido: Permite configurar canales preferidos, como: correo electrónico, portal web, HIS, FTP seguro, impresora local.
|
|
|
|
|
|
40
|
Notificación automática al médico tratante: Envío automático de alerta o confirmación al médico tratante cuando el informe está disponible (por email, mensaje interno, app o sistema HIS).
|
|
|
|
|
|
41
|
Portal web para profesionales tratantes: Acceso seguro para médicos a través de un portal con credenciales, donde puedan consultar, descargar o revisar los informes actuales y pasados. Permite controlar quién ha accedido, descargado o leído un informe
|
|
|
|
|
|
42
|
Trazabilidad del envío: Registro detallado de fecha y hora de generación del informe, fecha y hora de firma, fecha y hora de envío, usuario que envió, método de envío, confirmación de recepción de informe (descarga o apertura)
|
|
|
|
|
|
43
|
Personalización del formato de salida: Posibilidad de exportar informe en distintos formatos: PDF, HL7 CDA, XML, JSON, etc., según requerimientos del sistema receptor
|
|
|
|
|
|
44
|
Gestión de reenvíos y errores: Reintento automático en caso de falla de entrega (por caída de red, error en servidor, entre otros). Registro de informes no entregados y opción de reenviar manualmente.
|
|
|
|
|
|
45
|
Acceso para pacientes ó profesional externo (opcional): Portal de pacientes (seguro y autenticado) con acceso restringido a sus informes. Con opción para descarga, impresión o compartir informe con profesionales externos. Configurable por institución (si se desea habilitar o no).
|
|
|
|
|
|
|
7.- Seguridad, cumplimiento Normativo y Auditoría
|
|
|
|
|
|
46
|
Audit Trail Completo: Registro detallado y cronológico de toda acción realizada dentro del sistema, desde ingreso de datos hasta modificaciones o eliminaciones.
|
|
|
|
|
|
47
|
Gestión de Usuarios y Permisos: Asignación de roles y accesos por usuario, garantizando protección de datos sensibles y cumplimiento de la ley de datos personales.
|
|
|
|
|
|
48
|
Cumplimiento de Normativas: Diseñado para facilitar el cumplimiento de estándares como ISO 15189, CAP, CLIA, y protocolos de bioseguridad nacional
|
|
|
|
|
|
49
|
Cifrado y Respaldo: Seguridad robusta con cifrado de base de datos y respaldos automáticos programables, en servidores locales o nube.
|
|
|
|
|
|
50
|
Módulo de Reportes y Estadísticas: Herramientas para generar métricas de productividad, tiempos de respuesta, control de calidad y uso de recursos.
|
|
|
|
|
|
|
8.- Escalabilidad, mantenimiento y soporte:
|
|
|
|
|
|
51
|
El sistema debe permitir crecer en volumen de muestras sin pérdida de performance.
|
|
|
|
|
|
52
|
Soporte técnico local/regional, disponibilidad de actualizaciones, capacitación del personal entre otros.
|
|
|
|
|
|
53
|
Documentación técnica, manual de usuario, manual de administración, guías de validación.
|
|
|
|
|
|
|
9.- Analíticas y dashboards
|
|
|
|
|
|
54
|
Paneles de gestión (dashboards) para indicadores clave: tiempos de respuesta, rendimiento del laboratorio, eficiencia, tasa de rechazo de muestras, tiempos de demora por fase (preanalítica, analítica, post‑analítica), tipo de examen realizado, tipo de muestras procesada
|
|
|
|
|
|
55
|
Alertas tempranas si algún paso demora más de lo esperado o si hay cuellos de botella en el proceso de trabajo de cada muestra.
|
|
|
|
|
|
56
|
Reportes de uso de reactivos, costos, productividad por usuario o por turno, entre otras aplicaciones.
|
|
|
|
|
|
57
|
Posibilidad de descargas los datos en formato Excel.
|
|
|
|
|
|
|
10.- Estadísticas
|
|
|
|
|
|
58
|
Permitir realizar estadística, obtener reportes de exámenes ejecutados por unidad de trabajo en un cierto periodo de tiempo.
|
|
|
|
|
|
59
|
Permitir generar informes y reportes personalizados según las necesidades del Hospital durante la vigencia del contrato.
|
|
|
|
|
|
60
|
Sistema permite generar estadística en base a tipos de patología, información demográfica, entre otros.
|
|
|
|
|
|
61
|
Análisis estadístico en relación a informes, tiempos de resolución, AP correspondiente, productividad.
|
|
|
|
|
|
62
|
Mantiene histórico de prestaciones realizadas
|
|
|
|
|
|
|
11.- Trazabilidad de la muestra y procesos
|
|
|
|
|
|
63
|
Permite capturar archivos análogos para ser incorporados al sistema de manera digital.
|
|
|
|
|
|
|
12.- Sistema de reconocimiento de voz
|
|
|
|
|
|
64
|
Integrable con Software de Reconocimiento de voz Dragon
|
|
|
|
|
|
65
|
Debe permitir el reconocimiento de voz en tiempo real
|
|
|
|
|
|
66
|
Incorpore entrenamiento inicial breve (máximo 30 minutos) con la aplicación del equipo de reconocimiento.
|
|
|
|
|
|
67
|
Alta precisión en el reconocimiento de la voz e interpretación inteligente del habla.
|
|
|
|
|
|
|
13.- Seguridad
|
|
|
|
|
|
68
|
Mantenedor con perfiles y roles definidos por usuario y perfiles de acceso
|
|
|
|
|
|
69
|
Considerar perfil de administrador del servidor para el Hospital
|
|
|
|
|
|
70
|
Permitir seleccionar campos mandatorios por llenar antes de salir de la pantalla actual, en todos aquellos módulos que la UAP así lo necesite.
|
|
|
|
|
|
71
|
Registro de todas las operaciones realizadas por cada usuario del sistema con posibilidad de auditorías en pantalla
|
|
|
|
|
|
72
|
Permite realizar auditorías de trazabilidad sobre las muestras ingresadas
|
|
|
|
|
|
|
14.- Soporte y Garantía
|
|
|
|
|
|
73
|
Garantía por un periodo de 36 meses
|
|
|
|
|
|
74
|
Actualización del software por 36 meses sin costo para el Hospital (Software y Hardware)
|
|
|
|
|
|
|
15.- Condiciones Generales
|
|
|
|
|
|
75
|
Demostrar aplicaciones en Laboratorios de Biología Molecular
|
|
|
|
|
|
76
|
La Licencia de software debe ser multiusuario, sin costo adicional por estación de trabajo.
|
|
|
|
|
|
77
|
Posibilidad de adaptarse a forma de trabajo del Laboratorio
|
|
|
|
|
|
78
|
Permitir migración de informes históricos en formato PDF
|
|
|
|
|
|
Especificaciones Técnicas Sistema Laboratorio Citometría de Flujo
|
|
|
|
|
Nombre de la empresa oferente
|
|
|
|
|
Marca del equipo ofertado
|
|
|
|
|
Modelo del equipo ofertado
|
|
|
|
|
Garantía ofrecida (meses)
|
|
|
|
|
Plazo entrega (meses)
|
|
|
|
|
|
|
|
|
|
|
Item
|
Requerimiento
|
Obligatoriedad
|
Cumplimiento [Si/No]
|
|
|
|
|
1.- Gestión Integral del Flujo de Trabajo y Trazabilidad
|
|
|
|
|
|
1
|
Gestión de Flujos de Trabajo: Permite definir, automatizar y monitorizar los procesos del laboratorio desde la solicitud hasta el informe final, optimizando la eficiencia y reduciendo los tiempos de respuesta.
|
|
|
|
|
|
2
|
Gestión de Pedidos de Laboratorio: Administra el ciclo de vida completo de las solicitudes de análisis, desde su ingreso hasta su finalización.
|
|
|
|
|
|
3
|
Trazabilidad Completa de la Fase Preanalítica: Garantiza un seguimiento exhaustivo y documentado de cada muestra desde su recepción, incluyendo el registro de mielogramas.
|
|
|
|
|
|
4
|
Seguimiento por Código de Barras (Tracking): Implementa el uso de códigos de barras en muestras, solicitudes y hojas de trabajo para un rastreo preciso y la eliminación de errores manuales.
|
|
|
|
|
|
5
|
Gestión de Insumos: Mantiene un registro detallado de la entrega de tubos TransFix, citrato y otros materiales asociados a las muestras.
|
|
|
|
|
|
|
2.- Administración de Datos Clínicos y del Paciente
|
|
|
|
|
|
6
|
Ingreso Centralizado de Datos: Permite el registro completo de datos demográficos del paciente, información de la muestra (calidad y cantidad) y datos del examen físico, siguiendo protocolos estandarizados (ej. QMT).
|
|
|
|
|
|
7
|
Autocompletado Inteligente de Solicitudes: Agiliza el ingreso de datos rellenando automáticamente las solicitudes con la información existente del paciente.
|
|
|
|
|
|
8
|
Historial Clínico Unificado: Muestra de forma automática el historial de muestras anteriores del paciente, vinculando instantáneamente todos sus datos, informes previos, esquemas de anticuerpos y estudios relacionados (mielogramas, ADN, tinciones).
|
|
|
|
|
|
9
|
Digitalización de Documentos: Permite escanear y adjuntar solicitudes y otros documentos, vinculándolos directamente al registro del paciente y su número de ingreso.
|
|
|
|
|
|
|
3.- Procesamiento Analítico y Control de Calidad
|
|
|
|
|
|
10
|
Generación de Hojas de Trabajo Dinámicas: Facilita la creación de hojas de trabajo para marcación con más de 2000 paneles de anticuerpos distintos, ajustando automáticamente las dosis para técnicas de alta sensibilidad.
|
|
|
|
|
|
11
|
Base de Datos de Reactivos: Incluye un registro completo de anticuerpos que genera alertas automáticas sobre fechas de caducidad y niveles de stock para una gestión proactiva del inventario.
|
|
|
|
|
|
12
|
Gestión de Calibración: Administra y registra las calibraciones de los instrumentos para asegurar la precisión y fiabilidad de los resultados
|
|
|
|
|
|
13
|
Registro de Paneles y Análisis: Vincula cada panel de anticuerpos utilizado directamente con el paciente y el análisis correspondiente para una trazabilidad analítica total.
|
|
|
|
|
|
|
4.- Integración e interoperabilidad del sistema
|
|
|
|
|
|
14
|
Integración con Instrumentos de Laboratorio: Se conecta directamente con citómetros como BD FACSCanto II™ y BD FACSymphony™ A1 (FACS Lyric), permitiendo la captura automatizada de datos
|
|
|
|
|
|
15
|
Integración con Historia Clínica Electrónica (HCE/HIS): Se comunica con los sistemas de información hospitalaria para un intercambio fluido de datos de pacientes y resultados, asegurando la consistencia de la información
|
|
|
|
|
|
16
|
Compatibilidad con Archivos Estándar: Permite la importación de archivos `. FCS` y el rescate de sus metadatos, integrando la información cruda del análisis directamente en el sistema
|
|
|
|
|
|
17
|
Importación y Exportación de Datos: Ofrece herramientas flexibles para importar datos masivos y exportar información en diversos formatos para análisis externos, informes o migraciones
|
|
|
|
|
|
|
5.- Generación y Distribución de Informes
|
|
|
|
|
|
18
|
Motor de Búsqueda Avanzada: Permite localizar pacientes y estudios utilizando cualquier criterio de búsqueda: datos demográficos, fechas, patología, tipo de muestra, informe utilizado, palabra utilizada en informe o anticuerpo específico.
|
|
|
|
|
|
19
|
Amplia Biblioteca de Plantillas: Dispone de 43 plantillas de informe especializadas para diagnóstico, seguimiento y otros fines, listas para ser utilizadas
|
|
|
|
|
|
20
|
Informes Personalizables y Multicontenido: Permite integrar en los informes texto libre, valores de referencia, gráficos e imágenes para una comunicación de resultados clara y completa.
|
|
|
|
|
|
21
|
Distribución Segura y Auditable: Gestiona el envío de informes por correo electrónico y plataformas seguras, dejando un registro de la fecha, hora y usuario que realiza el envío.
|
|
|
|
|
|
22
|
Mecanismos de Verificación: Incorpora validaciones de RUT, códigos internos y enlaces antes del envío para garantizar la integridad y correcta entrega de los informes.
|
|
|
|
|
|
23
|
Firma electrónica avanzada: Soporte para firmas electrónicas simples y/o avanzadas con validación criptográfica (según normativa chilena). Registro de usuario firmante, fecha, IP o dispositivo de firma.
|
|
|
|
|
|
24
|
Envío automatizado por canal definido: Permite configurar canales preferidos, como: correo electrónico, portal web, HIS, FTP seguro, impresora local.
|
|
|
|
|
|
25
|
Trazabilidad del envío: Registro detallado de fecha y hora de generación del informe, fecha y hora de firma, fecha y hora de envío, usuario que envió, método de envío, confirmación de recepción de informe (descarga o apertura)
|
|
|
|
|
|
26
|
Personalización del formato de salida: Posibilidad de exportar informe en distintos formatos: PDF, HL7 CDA, XML, JSON, etc., según requerimientos del sistema receptor
|
|
|
|
|
|
27
|
Gestión de reenvíos y errores: Reintento automático en caso de falla de entrega (por caída de red, error en servidor, entre otros). Registro de informes no entregados y opción de reenviar manualmente.
|
|
|
|
|
|
|
6.- Seguridad, Conformidad y Análisis de datos.
|
|
|
|
|
|
28
|
Módulo de Gestión de Auditorías (Audit Trail): Registra todas las acciones y modificaciones realizadas en el sistema, facilitando las auditorías internas y externas y asegurando la integridad de los datos.
|
|
|
|
|
|
29
|
Gestión de la Conformidad: Diseñado para ayudar a cumplir con las normativas y estándares de calidad del laboratorio (ej. ISO 15189).
|
|
|
|
|
|
30
|
Seguridad y Almacenamiento Robusto de Datos
|
|
|
|
|
|
31
|
Almacenamiento Seguro: Protege la base de datos contra accesos no autorizados.
|
|
|
|
|
|
32
|
Cifrado de Datos: Aplica cifrado tanto a los documentos generados como a la transmisión de información (métodos POST) para garantizar la confidencialidad
|
|
|
|
|
|
33
|
Gestión de Privilegios de Usuario: Controla el acceso a la información sensible mediante perfiles de usuario y permisos detallados
|
|
|
|
|
|
34
|
Explotación de Datos para Análisis Estadístico: Facilita la interpretación de informes y la creación de un diagnóstico resumido y estructurado, ideal para realizar búsquedas avanzadas y análisis estadísticos de cohortes
|
|
|
|
|
|
35
|
Exportación de datos en formato Excel de acuerdo a búsquedas específicas
|
|
|
|
|
|
|
7.- Escalabilidad, mantenimiento y soporte:
|
|
|
|
|
|
36
|
El sistema debe permitir crecer en volumen de muestras sin pérdida de performance.
|
|
|
|
|
|
37
|
Soporte técnico local/regional, disponibilidad de actualizaciones, capacitación del personal entre otros.
|
|
|
|
|
|
38
|
Documentación técnica, manual de usuario, manual de administración, guías de validación.
|
|
|
|
|
|
|
8.- Analíticas y dashboards
|
|
|
|
|
|
39
|
Paneles de gestión (dashboards) para indicadores clave: tiempos de respuesta, rendimiento del laboratorio, eficiencia, tasa de rechazo de muestras, tiempos de demora por fase (preanalítica, analítica, post‑analítica), tipo de examen realizado, tipo de muestras procesada
|
|
|
|
|
|
40
|
Alertas tempranas si algún paso demora más de lo esperado o si hay cuellos de botella en el proceso de trabajo de cada muestra.
|
|
|
|
|
|
41
|
Reportes de uso de reactivos, costos, productividad por usuario o por turno, entre otras aplicaciones.
|
|
|
|
|
|
42
|
Posibilidad de descargas los datos en formato Excel.
|
|
|
|
|
|
|
9.- Estadísticas
|
|
|
|
|
|
43
|
Permitir realizar estadística, obtener reportes de exámenes ejecutados por unidad de trabajo en un cierto periodo de tiempo.
|
|
|
|
|
|
44
|
Permitir generar informes y reportes personalizados según las necesidades del Hospital durante la vigencia del contrato.
|
|
|
|
|
|
45
|
Sistema permite generar estadística en base a tipos de patología, información demográfica, entre otros.
|
|
|
|
|
|
46
|
Análisis estadístico en relación a informes, tiempos de resolución, AP correspondiente, productividad.
|
|
|
|
|
|
47
|
Mantiene histórico de prestaciones realizadas
|
|
|
|
|
|
|
10.- Trazabilidad de la muestra y procesos
|
|
|
|
|
|
48
|
Permite capturar archivos análogos para ser incorporados al sistema de manera digital.
|
|
|
|
|
|
|
11.- Sistema de reconocimiento de voz
|
|
|
|
|
|
49
|
Integrable con Software de Reconocimiento de voz Dragon
|
|
|
|
|
|
50
|
Debe permitir el reconocimiento de voz en tiempo real
|
|
|
|
|
|
51
|
Incorpore entrenamiento inicial breve (máximo 30 minutos) con la aplicación del equipo de reconocimiento.
|
|
|
|
|
|
52
|
Alta precisión en el reconocimiento de la voz e interpretación inteligente del habla.
|
|
|
|
|
|
|
12.- Seguridad
|
|
|
|
|
|
53
|
Mantenedor con perfiles y roles definidos por usuario y perfiles de acceso
|
|
|
|
|
|
54
|
Considerar perfil de administrador del servidor para el Hospital
|
|
|
|
|
|
55
|
Permitir seleccionar campos mandatorios por llenar antes de salir de la pantalla actual.
|
|
|
|
|
|
56
|
Registro de todas las operaciones realizadas por cada usuario del sistema con posibilidad de auditorías en pantalla
|
|
|
|
|
|
57
|
Permite realizar auditorías de trazabilidad sobre las muestras ingresadas
|
|
|
|
|
|
|
13.- Soporte y Garantía
|
|
|
|
|
|
58
|
Garantía por un periodo de 36 meses
|
|
|
|
|
|
59
|
Actualización del software por 36 meses sin costo para el Hospital (Actualización de Software, Hardware)
|
|
|
|
|
|
|
14.- Condiciones Generales
|
|
|
|
|
|
60
|
Demostrar aplicaciones en Laboratorios de Citometría de Fujo
|
|
|
|
|
|
61
|
La Licencia de software debe ser multiusuario, sin costo adicional por estación de trabajo.
|
|
|
|
|
|
62
|
Posibilidad de adaptarse a forma de trabajo del Laboratorio
|
|
|
|
|
|
63
|
Permitir migración de informes históricos en formato PDF
|
|
|
|
|
|