REQUISITOS Y DEMÁS CONDICIONES QUE DEBEN TOMAR EN … · la contratación de lo requerido y...

Instituto Guatemalteco de Seguridad Social

Manifestación de Interés a Ofertar DA No. 219-IGSS-2014 Departamento de Abastecimientos

1

7ª. Avenida 22-72, zona 1, Centro Cívico Guatemala, C. A PBX: 2412-1224, ext. 1239

REQUISITOS Y DEMÁS CONDICIONES QUE DEBEN TOMAR EN CUENTA LOS INTERESADO S EN LA MANIFESTACIÓN DE INTERÉS A OFERTAR DA No. 219-IGSS-2014. LOS INTERESADOS EN OFERTAR DEBEN CUMPLIR DE FORMA PUNTUAL Y EXACTA CON LO SIGUIENTE:

1. ADJUNTAR LA DOCUMENTACIÓN SIGUIENTE:

a. Documento que contenga:

a.1. Razón social y nombre comercial de la empresa, dirección para recibir notificaciones,

números telefónicos, dirección de correo electrónico y nombre del propietario, representante legal, o mandatario, según sea el caso.

a.2. Precio total expresado en quetzales, en números, con dos (2) decimales y expresado en letras. En el precio total en letras, los decimales podrán ser consignados en números. De acuerdo a lo que establece el Artículo 10 del Decreto 27-92 del Congreso de la República de Guatemala, Ley del Impuesto al Valor Agregado y sus reformas, el precio ofertado debe incluir el Impuesto al Valor Agregado -IVA-; asimismo, deberá considerar en el precio ofertado, todos los costos en que incurra el objeto del presente proceso e indicar el tiempo de implementación del mismo, el cual no deberá exceder de 24 meses.

b. Declaración Jurada, contenida en acta notarial en donde haga constar:

b.1. Que no es deudor moroso del Estado, ni de las entidades a las que se refiere el Artículo 1 y

que no está comprendido en ninguna de las prohibiciones que establece el Artículo 80,

ambos de la Ley de Contrataciones del Estado.

b.2. Que leyó, estudió, aceptó y se somete expresamente a cada una de las condiciones,

requisitos y demás estipulaciones establecidas y exigidas en la presente Manifestación de

Interés a Ofertar DA No. 219-IGSS-2014, aclaraciones y modificaciones.

b.3. Que no existe conflicto de interés entre __________ (nombre del INTERESADO ) y el Banco

________ que acredite la titularidad de sus cuentas bancarias (el nombre del banco debe

coincidir con la entidad bancaria que emita la certificación solicitada), en la literal h) del

numeral 1. de la presente Manifestación de Interés a Ofertar.

b.4. Que el INTERESADO tiene la capacidad de ejecutar el objeto y que asume las

responsabilidades administrativas, civiles y penales que se deriven del mismo.

b.5. Que la presentación de la Manifestación de Interés a Ofertar, no implica derecho alguno para

la contratación de lo requerido y garantiza la veracidad y exactitud de toda la información

proporcionada. En caso de ser contratado se compromete a cumplir con el objeto del

proceso de Manifestación de Interés a Ofertar DA No. 219-IGSS-2014 y acepta que el

―INSTITUTO” está en su derecho de no realizar la contratación de no convenir a sus

intereses.

b.6. Que toda la información y documentos anexos proporcionados por el INTERESADO al

Registro de Proveedores adscrito al Ministerio de Finanzas Públicas están actualizados y es

de fácil acceso.



2


b.7. Que en caso de firmar contrato garantice las actualizaciones de los productos ofertados de

software mientras dure la implementación y hasta la recepción del proyecto sin costo alguno

para en el Instituto.

b.8. Las actualizaciones posteriores podrán ser negociadas y de convenir a los intereses

institucionales podrán ser adquiridas en adendas o ampliaciones del contrato que resulte de

la presente negociación, siempre que por la naturaleza de los desarrollos o los programas se

determine que los mismos únicamente puedan ser adquiridas al desarrollador original.

Dichas ampliaciones deben contar con la aprobación de la Junta Directiva del Instituto.

b.9. Que se compromete, en caso de firmar contrato, al finalizar el Proyecto, a entregar o poner a

disposición del ―INSTITUTO” los códigos fuente, de las interfaces para realizar futuras

modificaciones acorde a las necesidades de la Institución.

b.10. Que se compromete en caso de firmar contrato a brindar un Plan de Capacitación, el cual

deberá incluir la nómina de los cursos, el programa sintético de cada uno y la duración, en

horas o la cantidad de horas recomendada por el fabricante, capacitando a doce

profesionales que se designarán por el ―INSTITUTO”.

b.11. Que se compromete en caso de firmar contrato, a cumplir con el plazo para la

implementación del Proyecto, el cual no debe exceder de veinticuatro (24) meses contados a

partir de la fecha de notificación de la aprobación del contrato.

b.12. Que se compromete a brindar una garantía de 3 años en sitio para el Hardware ofertado en

todos sus componentes con atención de 7 x 24 con 4 horas de tiempo de respuesta.

c. Fotocopia legalizada u original (según corresponda) de los siguientes documentos:

c.1. Si es persona individual: I. Patente de Comercio de la empresa, que indique el giro comercial afín a lo requerido. II. Documento Personal de Identificación (DPI) del propietario o mandatario, si fuera el caso,

con el documento que lo acredite debidamente inscrito en los registros correspondientes, si fuera el caso.

c.2. Si es persona jurídica: I. Testimonio de la escritura pública de constitución de la sociedad y sus modificaciones si

las hubiere, debidamente inscritas en el Registro Mercantil. II. Documento que acredite el nombramiento del representante legal o mandatario

debidamente inscrito en los registros correspondientes. III. Documento Personal de Identificación (DPI) del representante legal o mandatario. IV. Patente de comercio de sociedad. V. Patente de comercio de empresa, que indique el giro comercial afín a lo requerido.

En caso de los extranjeros adjuntar fotocopia legalizada del pasaporte completo vigente.

c.3. En caso de tratarse de entidades constituidas en el extranjero, las mismas deben cumplir con los requisitos establecidos en el Código de Comercio y contar con la debida autorización para operar en Guatemala.

c.4. Autorización expresa otorgada por la empresa fabricante o subsidiara facultada para tal

extremo, para comercializar los productos ofertados al ―INSTITUTO”.

c.5. Experiencia: Al menos un contrato, carta o finiquito que demuestre la implementación satisfactoria de una solución integral de sistemas informáticos que incluya la instalación,



3


migración de datos, puesta en operación, garantía, soporte y actualizaciones de un sistema de gestión administrativa de los recursos gubernamentales (GRP) y un sistema de gestión médica; para instituciones del Estado, entidades centralizadas, descentralizadas, autónomas, nacionales o extranjeras, pertenecientes al sector de salud pública o seguridad social.

c.6. Listado que contenga el Staff de implementación de la solución integral requerida, con un

mínimo de diez personas certificadas por la empresa fabricante.

d. Original de la Constancia de Inscripción en el Registro de Proveedores de Guatecompras, tal y como la genera el sistema, debidamente firmada, en la cual indique que el INTERESADO se encuentra habilitado.

e. Fotocopia simple de la inscripción actualizada al registro tributario unificado (RTU) extendida por la Superintendencia de Administración Tributaria (SAT).

f. Original de la solvencia de pagos de contribuciones patronales y de trabajadores, extendida por

el ―INSTITUTO” a nombre del INTERESADO al 30 de abril de 2014, la cual debe ser solicitada por escrito, por el propietario, representante legal o mandatario para el evento que participa, al Departamento de Recaudación, en la ventanilla ubicada en el Centro de Atención al Afiliado –CATAFI-, 1er. nivel de las Oficinas Centrales del ―INSTITUTO”.

g. Original o fotocopia legalizada de la constancia otorgada por el Departamento de Recaudación, para el caso que el INTERESADO no esté afecto al Seguro Social.

Para obtener dicho documento, deberá presentar solicitud por escrito al Departamento de Recaudación, firmada por el propietario, representante legal o mandatario, indicando nombre del patrono (nombre del propietario de la empresa o denominación social), número de la Manifestación de Interés a Ofertar en la que va a participar, fecha del proceso y la dirección exacta.

En todos los casos, cuando se trate de documentos provenientes del extranjero debe cumplirse con lo que establecen los Artículos 37 y 38 de la Ley del Organismo Judicial.

h. Certificación Bancaria que acredite la titularidad de las cuentas y operaciones bancarias que

posee. Para el efecto deberá contener la información siguiente:

h.1. Identificación del cuentahabiente. h.2. Tipo de cuentas que posee en la entidad bancaria. h.3. Promedio de cifras antes del punto decimal de los saldos que posee. h.4. Tiempo de manejo de la cuenta. h.5. Clase de cuentahabientes. h.6. Determinación si posee créditos. h.7. Saldo del deudor h.8. Clasificación o categoría del deudor de conformidad con la normativa correspondiente.

El Ministerio de Finanzas Públicas a través de la Dirección Normativa de Contrataciones y Adquisiciones del Estado emitirá el formato respectivo que contenga la información detallada.

i. El INTERESADO deberá proponer y presentar en su propuesta técnica, un enfoque de

administración y control del proyecto, el cual debe incluir la estrategia, el plan de trabajo, la

metodología de implantación, el personal asignado al proyecto, las etapas del proyecto,

cronogramas de actividades, períodos de informes de estatus, estrategia de pruebas y migración

de datos, de acuerdo a lo establecido en el subnumeral 9.5.



4


2. SUSCRIPCIÓN Y APROBACIÓN DEL CONTRATO

El contrato detallará todas las condiciones que regirán el objeto de la presente negociación y se elaborará con base a la Ley de Contrataciones del Estado y su Reglamento, a la oferta presentada y documentos presentados en la presente Manifestación de Interés a Ofertar. La suscripción y aprobación del mismo se realizará dentro del plazo y formalidades establecidos en la Ley de Contrataciones del Estado (Artículos 47 y 48 de la Ley y 26 de su Reglamento). El contrato debe incluir la cláusula especial siguiente: ―CLÁUSULA RELATIVA AL COHECHO: Yo el Contratista , manifiesto que conozco las penas relativas al delito de cohecho así como las disposiciones contenidas en el Capítulo III del Título XIII del Decreto 17-73 del Congreso de la República, Código Penal. Adicionalmente, conozco las normas jurídicas que facultan a la Autoridad Superior de la entidad afectada para aplicar las sanciones administrativas que pudieren corresponderme, incluyendo la inhabilitación en el Sistema GUATECOMPRAS.‖ (Artículo 3 del Acuerdo Ministerial No. 24-2010 del Ministerio de Finanzas Públicas, Normas de Transparencia en los Procedimientos de Compra o Contratación Pública).

3. GARANTÍAS

3.1. SEGURO DE CAUCIÓN DE SOSTENIMIENTO DE OFERTA

Se formalizará mediante póliza, extendida por una institución aseguradora debidamente autorizada para operar en la República de Guatemala (Artículo 64 y 69 de la LEY; 36 del REGLAMENTO; 3 literal b), 106 y 109 del Decreto número 25-2010 del Congreso de la República de Guatemala, Ley de la Actividad Aseguradora).

Deben tomarse en cuenta las consideraciones siguientes:

a) Extendida a favor del INSTITUTO.

b) Debe garantizar a:

Si es persona individual a nombre del propietario de la empresa. Si es persona jurídica a nombre de la razón o denominación social.

c) Con vigencia de ciento veinte (120) días a partir de la fecha de recepción y apertura de

PLICAS, sin embargo con el adjudicatario, puede convenirse su prórroga. d) Constituida por un porcentaje no menor del uno por ciento (1%) ni mayor del cinco por ciento

(5%) del valor total de la OFERTA.

e) Se hará efectiva en cualquiera de los casos siguientes:

Si el adjudicatario no sostiene su OFERTA.

Si no concurre a suscribir el CONTRATO respectivo dentro del plazo legal correspondiente o si habiéndolo hecho no presenta el seguro de caución de cumplimiento dentro del plazo de 15 días siguientes a la firma del CONTRATO.

(Artículos 47 de la LEY y 36 del REGLAMENTO)

Dicha póliza será requerida al INTERESADO por el INSTITUTO, previo a someter a consideración de la Autoridad Superior del Instituto la autorización de la presente negociación.

3.2. SEGURO DE CAUCIÓN DE CUMPLIMIENTO

Dentro de los quince (15) días siguientes a la suscripción del contrato, el Contratista deberá presentar seguro de caución de cumplimiento de contrato (Artículos 65 y 69 de la Ley de Contrataciones del Estado; 36, 38 y 39 de su Reglamento; 3 literal b), 106 y 109 del Decreto número 25-2010 del Congreso de la República de Guatemala, Ley de la Actividad Aseguradora).



5


Este seguro de caución tendrá las características siguientes:

a) Formalizado mediante póliza extendida a favor del Instituto Guatemalteco de Seguridad Social, por una institución aseguradora debidamente autorizada para operar en la República de Guatemala.

b) Constituido por una suma equivalente al diez por ciento (10%) del monto del Contrato. c) El Contratista se compromete a mantener vigente el seguro de caución de cumplimiento

hasta que el Instituto Guatemalteco de Seguridad Social, extienda la constancia de haber recibido a su satisfacción la totalidad de lo contratado en la presente negociación.

El seguro de caución de cumplimiento se hará efectivo si el Contratista incumple con alguna de las condiciones establecidas en el contrato, o si el producto entregado no fuese el solicitado.

3.3. SEGURO DE CAUCIÓN DE CALIDAD Y/O FUNCIONAMIENTO

El Contratista , deberá otorgar seguro de caución de calidad y/o funcionamiento, por el equivalente al quince por ciento (15%) del valor original del contrato, como requisito previo para la entrega del software, la cual tendrá una vigencia de dieciocho (18) meses, contados a partir de la fecha extienda la constancia de haber recibido a su satisfacción la totalidad de lo contratado en la presente negociación. (Artículos 67 y 69 de la Ley de Contrataciones del Estado).

4. PLAZO CONTRACTUAL

El plazo contractual será de veinticuatro (24) meses, contado a partir del día siguiente de recibida la orden de compra (Artículo 78 del Reglamento).

5. VIGENCIA DEL CONTRATO

La vigencia del contrato será a partir del día siguiente de la notificación de la aprobación del contrato, hasta que el Instituto Guatemalteco de Seguridad Social extienda la constancia de haber recibido a su satisfacción la totalidad de lo contratado en la presente negociación (Artículo 78 del Reglamento).

6. LUGAR DE ENTREGA E IMPLEMENTACIÓN

Se deberá entregar e implementar lo solicitado en las oficinas centrales del ―INSTITUTO‖ ubicadas en 7ª. Avenida 22-72 zona 1, 6to. Nivel, Oficinas Centrales del Instituto Guatemalteco de Seguridad Social, y en las distintas unidades médico-administrativas que sean designadas por la Autoridad Administrativa Superior del ―INSTITUTO‖.

7. FORMA DE PAGO El ―INSTITUTO” realizará los pagos parciales de acuerdo a la entrega e implementación satisfactoria de los productos recibidos dentro de los treinta (30) días hábiles siguientes a la fecha de la presentación de la factura correspondiente y demás documentación que se le requiera, por medio de depósito en cuenta monetaria del Banco de Desarrollo Rural, Sociedad Anónima, -BANRURAL-, que el Contratista haya registrado. El trámite de dicho pago estará a cargo de la Subgerencia Administrativa, quien procederá de conformidad con la normativa del ―INSTITUTO”. En caso que el objeto no sea pagado en el ejercicio fiscal vigente, se afectará la partida presupuestaria autorizada para el ejercicio fiscal siguiente, por el Órgano Director del INSTITUTO y que corresponda a la Subgerencia Administrativa. El INSTITUTO pagará los productos recibidos conforme a los siguientes componentes:



6


Componente Descripción Porcentaje de

Pago

Responsable de Aceptación por

parte del INSTITUTO

Entrega de hardware e instalación de software

en el centro de cómputo del Departamento de Informática

del INSTITUTO

Acta de aceptación de la

instalación 50%

Comisión Técnica designada por la

Autoridad Administrativa

Superior.

Entrega de prototipo de los procesos administrativos y

financieros estándar Instalado en los ambientes de

desarrollo del INSTITUTO.


entrega 10%



Superior.

Entrega de prototipo de los procesos médicos estándar en los ambientes de desarrollo del

INSTITUTO.


entrega 10%



Superior.

Ejecución de las pruebas integrales de la funcionalidad final de la solución propuesta

Acta de aceptación de las

pruebas 10%



Superior.

Puesta en marcha de la solución propuesta en las unidades que designe el

“INSTITUTO”

Acta de aceptación de la solución y cierre

de proyecto

10%



Superior.

Finalización del programa de capacitación y entrega de manuales de capacitación

Acta de aceptación de

Documentos en formato

electrónico

10%



Superior.

8. ESPECIFICACIONES GENERALES

El INSTITUTO, desea adquirir con base al pedido No. 7/2014, emitido por el Departamento de Informática de la Subgerencia Administrativa una SOLUCIÓN INTEGRAL DE SISTEMAS INFORMÁTICOS SAP O SU EQUIVALENTE QUE INCLUYA: LA INSTALACIÓN, MIGRACIÓN DE DATOS, PUESTA EN OPERACIÓN, GARANTÍA, SOPORTE Y ACTUALIZACIONES DE UN SISTEMA DE GESTIÓN ADMINISTRATIVA DE LOS RECURSOS GUBERNAMENTALES (GRP) Y UN SISTEMA DE GESTIÓN MÉDICA PARA EL INSTITUTO GUATEMALTECO DE SEGURIDAD SOCIAL, de acuerdo a las especificaciones técnicas que se describen a continuación:



7


9. ESPECIFICACIONES TÉCNICAS

9.1 Implementación del Software

9.1.1 Alcance

La propuesta de solución del INTERESADO deberá estar enfocada a soportar las operaciones adjetivas y sustantivas del “INSTITUTO”, incluyendo las interfaces que considere necesarias con las diferentes aplicaciones sustantivas y otros sistemas que no sean cubiertos por la solución del software propuesto, tomando en cuenta los aspectos siguientes:

a. Calidad en la Atención. Las unidades asistenciales deberán otorgar atención oportuna a los

afiliados y derechohabientes, conforme los conocimientos médicos y principios éticos vigentes, con satisfacción de las necesidades de salud y de las expectativas del paciente y de la institución.

b. Procesos Estandarizados de Atención. Para conseguir la exitosa implementación de este proyecto, las unidades del “INSTITUTO”; deberán operar mediante procesos de atención, guías de actuación y coberturas de salud estandarizadas para los servicios de atención clínica, hospitalaria y auxiliares de diagnóstico y tratamiento que se encuentren normalizados y validados por la institución.

c. Integración de la Información Clínico-Asistencial en el Expediente Clínico Electrónico. Para proporcionarles una herramienta eficaz a los profesionales del área médica es esencial tener acceso a toda la información generada por un afiliado o derechohabiente dentro del ciclo de atención médica (historia clínica, hoja de anamnesis, cursos clínicos, antecedentes, alergias, tratamientos farmacológicos, diagnóstico por imagen); de esta manera, los profesionales del “INSTITUTO”, contarán con información amplia y suficiente para apoyarse en la toma de decisiones que deriven en un diagnóstico y tratamiento de los afiliados o derechohabientes para brindar una Atención de Calidad. Como resultado, el afiliado o derechohabiente deberá contar con un expediente Clínico Electrónico que contenga toda la información clínico asistencial que genere durante su atención.

d. Explotación de la Información. Uno de los objetivos del “INSTITUTO” es la optimización de sus recursos humanos, económicos y materiales. Para lo cual deberá tener la capacidad de explotar la información gerencial, directiva y estadística que generen los pacientes a su paso por la red de servicios de salud.

e. Necesidad a ser cubierta en el corto y mediano plazo. El “INSTITUTO” ha logrado consolidar un proceso de cambio y modernización de muchas de sus principales áreas de trabajo, esto ha permitido obtener logros importantes, que están impactando en la imagen y credibilidad hacia la institución, principalmente por la mejora en la calidad de los servicios a sus afiliados y beneficiarios; sin embargo, este proceso necesita seguir fortaleciéndose para que sea sostenible a través del tiempo.

En este sentido, para consolidar la extensión de cobertura de los programas institucionales, es necesario continuar desarrollando capacidades del personal, apropiación de la normativa institucional, sistematización y automatización de los procesos de trabajo y ampliación de la capacidad instalada, esta ultima mediante la inversión en infraestructura y equipamiento, que permitan:

I. Esclarecer las cifras financieras y optimizar la utilización de los recursos públicos. II. Reforzar los controles internos e incrementar la visibilidad en la ejecución de los procesos. III. Entregar servicios eficientes y de calidad que dignifiquen a los trabajadores y

derechohabientes. IV. Mejorar el bienestar laboral de todas las personas que pertenecen al instituto.



8


V. Aumentar el número de afiliados en pro de la recaudación.

Para lograr lo anterior el ―INSTITUTO‖ requiere llevar a cabo una modernización tecnológica que le permita en el corto y mediano plazo, lo siguiente:

I. Transparencia, visibilidad y control de los proceso de la información. II. Eficiencia en los procesos internos. III. Mejora en la atención de los afiliados y beneficiarios.

A continuación se presentan de manera general los componentes que el ―INSTITUTO” considera necesarios para el proyecto de implementación del Sistema de Gestión Administrativa de los Recursos Gubernamentales (GRP) y de Gestión Médica del “INSTITUTO”.

a. Gestión Administrativa de los Recursos Gubernamentales (GRP) o su equivalente.- El

“INSTITUTO” requiere habilitar las herramientas tecnológicas que le permitan desarrollar y mantener altos estándares de eficiencia, lograr que los sistemas se encuentren comunicados entre sí, compartiendo información y siguiendo el flujo natural de trabajo, eliminando la recaptura de información, asegurando así una mayor coordinación entre procesos y procedimientos del del “INSTITUTO”.

b. Gestión Médica.- El “INSTITUTO” requiere contar con la información de la actividad asistencial del paciente (control del tráfico de pacientes, gestión del Expediente Clínico, servicios auxiliares de diagnóstico y tratamiento, servicios administrativos y otros).

c. Plataforma Tecnológica. El INTERESADO debe considerar que deberá instalar, configurar y poner a punto del servidor el Hardware y el Software propuesto, instalándolo de manera central, esto permitirá a los usuarios interactuar con el Sistema de Gestión Administrativa de los Recursos Gubernamentales y de Gestión Médica del “INSTITUTO”.

9.2 DEFINICIÓN DEL PROYECTO

Implementación Gestión Administrativa de los Recursos Gubernamentales y de Gestión Médica del “INSTITUTO” De acuerdo a las metodologías de implementación, el proceso de implementación del software debe presentar al menos las siguientes etapas o su equivalente:

Preparación inicial

Análisis y Diseño

Ejecución o Construcción

Preparación final

Liberación

9.3 Equipos y Suministros de parte del Contratista

El Contratista deberá otorgar al ―INSTITUTO”, los derechos de uso del software propuesto, mediante el modelo de licenciamiento, mismo que tendrá que entregarse al inicio del proyecto y que deberá de detallar en el anexo técnico.



9


El software entregado deberá cubrir el siguiente número de licencias

Gestión Administrativa de los Recursos Gubernamentales y Gestión Médica

Cantidad

Usuarios GRP 2,500

Licenciamiento para procesar registros para cálculo de nómina de empleados y Pensionados

175,000

Usuarios de Planeación y presupuestarios 100

Sesiones concurrentes de reporteria para atender un universo de 200 usuarios.

25

Usuarios Médicos y de Enfermería 2,700

El Contratista se obliga a proporcionar el software requerido por los consultores asignados durante la implementación del proyecto, haciéndose responsable de su originalidad y licenciamiento. El Contratista se asegurará de proveer a todo su personal el equipo de cómputo necesario para el desempeño de sus funciones dentro de las instalaciones del “INSTITUTO” mientras dure la implementación del proyecto. El “INSTITUTO” no se hará responsable por el equipo suministrado por el Contratista para el desarrollo de sus trabajos.

9.4 Facilidades de acceso por parte del “INSTITUTO”

“EL INSTITUTO” proporcionara lo siguiente:

a. Facilidades de acceso para el personal asignado por el Contratista , a las instalaciones donde

se realizarán las actividades de este proyecto. b. El apoyo necesario para que el Contratista complemente cualquier información adicional que

requiera para dar cumplimiento con lo aquí solicitado. c. El personal clave con dominio en los procesos a implementar, así como el personal técnico

que estará involucrado en la configuración y administración de la solución.

9.5 Requerimientos de Ejecución del Proyecto

9.5.1 Estrategia de Implementación del Proyecto

El INTERESADO deberá proponer y presentar en su propuesta técnica, un enfoque de administración y control del proyecto, el cual debe incluir la estrategia, el plan de trabajo, la metodología de implantación, el personal asignado al proyecto, las etapas del proyecto, cronogramas de actividades, períodos de informes de estatus, estrategia de pruebas y migración de datos.



10


El enfoque deberá cumplir lo siguiente:

9.5.1.1 ADMINISTRACIÓN DE PROYECTOS

a. Alineación de las metodologías de trabajo de cada uno de los grupos que participan en el proyecto para agilizar la comunicación interna y externa del proyecto.

b. Integración del plan general de proyecto que describe las actividades a realizar por cada uno de los grupos que participan en el proyecto.

c. El CONTRATISTA es responsable de cumplir con las expectativas de calidad acordadas con “EL INSTITUTO”.

d. El CONTRATISTA es el responsable de asegurar el cumplimiento de acuerdo a la definición de entregables de cada una de las tareas del proyecto.

e. El CONTRATISTA es responsable de proveer un reporte de avance del proyecto con período máximo semanal.

f. El CONTRATISTA deberá integrar su programa de trabajo y cronograma de proyecto en MS/Project 2007 o superior.

9.5.1.2 ADMINISTRACIÓN DEL ALCANCE

a. Control y documentación del alcance acordado con cada una de las áreas usuarias.

b. Verificación y control del cumplimiento del alcance definido al inicio del proyecto. c. Control y documentación de los cambios de alcance requeridos por el

“INSTITUTO”.

9.5.1.3 ADMINISTRACIÓN DEL TIEMPO

a. Administración y control del tiempo estimado de duración del proyecto de acuerdo al alcance de los servicios y el costo estimado para el proyecto.

b. Asignación de los recursos humanos y materiales necesarios para cumplir con las expectativas de tiempo marcadas al inicio del proyecto.

c. Estimación del esfuerzo requerido por cada uno de los participantes para que de forma integral el proyecto cumpla con las expectativas de tiempo marcadas al inicio del proyecto.

9.5.1.4 ADMINISTRACIÓN DE LA COMUNICACIÓN

a. Definición de los procesos de los planes y políticas oficiales de comunicación del proyecto mediante los cuales se hará la comunicación con el comité directivo del proyecto, con los integrantes en la implementación y los usuarios en general.

b. Definición del tipo y formatos de comunicados dentro del proyecto (minutas, reporte de eventos, histórico de eventos y otros.)

c. Reuniones de estado del avance del proyecto. d. Documentación de los acuerdos hechos durante las reuniones de trabajo. e. Distribución de los comunicados de acuerdo a hechos durante las reuniones de

trabajo. f. Definición del proceso oficial para hacer una solicitud de cambio de alcance o un

requerimiento adicional al proyecto. g. Definición del proceso oficial de escalamiento para atender cualquier evento que

pudiera afectar el tiempo, costo, alcance o calidad del proyecto.

9.5.1.5 ADMINISTRACIÓN DE RIESGOS

a. Identificación y documentación de riesgos y su impacto. b. Riesgos internos al proyecto. c. Riesgos externos al proyecto.



11


d. Definición y documentación de las estrategias para eliminar o minimizar riesgos. e. Identificación de los recursos humanos y materiales requeridos para mitigar

riesgos. f. Definición del plan de contingencia. g. Análisis de impacto de los riesgos para cada uno de los servicios que conforman el

proyecto. h. Análisis de impacto en costo, tiempo alcance y calidad del proyecto. i. Definición del Cronograma de atención.

9.5.1.6 ADMINISTRACIÓN DE RECURSOS

a. Control y planeación de la asignación de recursos humanos que deben participar en el proyecto.

b. Seguimiento para que el personal asignado al proyecto cuente con la experiencia requerida.

c. El INTERESADO en ofertar entregará en su propuesta un documento de organización del proyecto que, describa de manera general los participantes de parte del INTERESADO y del “INSTITUTO”, se deberá describir los roles de los participantes dentro del proyecto así como sus perfiles.

9.5.2 Metodología de generación de Entregables de Proyecto

La metodología de entrega de proyectos que utilice el Contratista deberá considerar: a. Incorporación de las mejores prácticas en la materia y estar en constante revisión y

actualización. b. Detalle específico en la fase de planeación principalmente. c. Inclusión de herramientas para la planeación e implementación del proyecto.

9.5.2.1 Diseño de Procesos

Los procesos del “INSTITUTO”, deberán ser redefinidos y/o corregidos tomando en cuenta:

a. El diseño de procesos a que se hace referencia el presente documento, y que son parte de la materia de los productos requeridos, se limitan únicamente a las modificaciones derivadas de la implementación de la solución.

b. La normatividad, métodos y procedimientos vigentes aplicables a “EL INSTITUTO”.

c. Las mejores prácticas de operación contenidas en la aplicación seleccionada alineadas al modelo operativo gubernamental.

d. Diseño y documentación de todos los procesos (actuales y futuros, soportados en la aplicación tecnológica y de aquellos que sean impactados de forma indirecta).

En toda decisión sobre cambios a los procesos, procedimientos, políticas y necesidades de información, “EL INSTITUTO”, participará de forma activa considerando los niveles comprendidos dentro del alcance del proyecto. Asimismo, todo proceso y procedimiento modificado y aceptado, será debidamente documentado por parte del Contratista en manuales electrónicos. La documentación mínima requerida, una vez concluido el rediseño del proceso y alineado a la solución, adicional a la documentación propia del proceso, deberá comprender lo siguiente:

a. Definición de procesos clave

b. Especificaciones de los requisitos funcionales del proceso mejorado.

c. Manuales de normas y procedimientos de operación de la herramienta.

d. Mapa de procesos y flujos documentales, mediante diagramas secuenciales de

actividades y tareas del proceso.



12


e. Diseño de la impresión de los documentos cuyo formato en papel no se pueden

eliminar (facturas, recibos entre otros).

f. Detección de las necesidades básicas para la implementación de la herramienta.

g. Capacitación del personal asignado a los procesos.

h. Matriz de evaluación de procesos implementados y una guía de posibles mejoras.

i. Elaboración de los casos de negocio, (establecer en términos de negocios la

necesidad, la justificación y la propuesta de alternativas a la solución de

problemas de negocios u objetivos estratégicos).

j. Programas de acción en lo relacionado a nuevos recursos para desarrollar

(tecnologías); humano (cambios de personal, capacitación y otros) y políticas o

estrategias a implantar y su relación con el resto de los procesos

k. Diccionario de datos que utilizará cada uno de los miembros de los procesos.

9.5.3 Metodología de Implementación

Con la finalidad de asegurar el cumplimiento de los objetivos del proyecto en tiempo y forma, el Contratista deberá seguir la metodología de implementación del software ofertado , misma que deberá contener al menos las siguientes características:

a. Documentación de la situación futura del “INSTITUTO” basándose en las mejores

prácticas contenidas en la aplicación y de los procesos ya rediseñados alineados al modelo operativo gubernamental.

b. Parametrización de la aplicación documentando la configuración en herramientas estándar.

c. Plan de pruebas unitarias de acuerdo al diseño. d. Plan de pruebas integrales, incluyendo integración con los sistemas sustantivos. e. Estrategia de migración de datos y pruebas de volumen. f. Plan de entrenamiento y capacitación. g. Plan detallado de arranque. h. Plan de carga de información inicial. i. Soporte presencial el primer mes de operación. j. Control de cambios y aceptación de entregables por etapa.

Como parte de esta metodología se deberán documentar los productos generados en el proyecto, dichos documentos formarán parte de la entrega de productos ―entregables‖, hasta la totalidad del proyecto. Los aspectos que al menos se deben documentar son:

a. Memoria técnica de las configuraciones del software, hardware. b. Manuales de usuario final. c. Métodos y procedimientos modificados por la solución propuesta. d. Aceptación de los entregables del proyecto. e. Avance del proyecto. f. Rutinas y subrutinas. g. Listados de código desarrollado.

La documentación producto de los trabajos efectuados deberá ser entregada en forma impresa y/o en dispositivo de almacenamiento.



13


9.5.4 Administración del Cambio

Enfoque de la Administración del Cambio para el “INSTITUTO” Con el propósito de facilitar el proceso de asimilación de la herramienta y al mismo tiempo sensibilizar al personal del “INSTITUTO” sobre la importancia de este proyecto, se considera pertinente contar con una estrategia de Administración del Cambio la cual realice las actividades necesarias para alcanzar los objetivos planteados. Se deberá contar con un enfoque integral basado en la detección y mitigación de riesgos tanto humanos como tecnológicos. Así mismo será necesario planear, diseñar y ejecutar una estrategia de comunicación masiva para informar a todas las unidades ejecutaras dentro de cada una de las provincias. La Administración del Cambio se deberá enfocar en lograr:

a. Facilitar la adopción de las herramientas informáticas por el personal de las unidades ejecutoras.

b. Detectar las dinámicas organizacionales que pueden acelerar u obstaculizar el proyecto.

c. Elaborar y ejecutar la estrategia para el cambio. d. Elaborar estrategia de comunicación que motive la participación del personal en los

cursos e. Elaborar estrategia de comunicación que logre el apoyo de mandos medios y

directivos a que personal a cargo participe en los cursos f. Alinear a la organización a través del diseño y ejecución de la estrategia de

comunicación masiva.

Se deberá contar con una metodología sustentada en una serie de herramientas las cuales deberán ser utilizadas a lo largo del proyecto para alcanzar la meta propuesta. Es de suma importancia para el “INSTITUTO”, monitorear el proceso de cambio, por ello, será necesario contar con un reporte de la ejecución de la capacitación, que contenga resultados de las evaluaciones, relación de asistencias y ausentismos, y que permita la medición del avance a la fecha comparado contra el objeto deseado.

El eje de las acciones de Administración del Cambio es una estrategia efectiva que, bien ejecutada, reduce el riesgo del proyecto y acelera la obtención de beneficios por medio de:

a. Construir una plataforma de trabajo en donde el equipo de capacitadores se

comunique en el mismo lenguaje dando prioridad en todo momento al cumplimiento de los objetivos planteados.

b. Detectar las dinámicas organizacionales que pueden acelerar u obstaculizar el proyecto.

c. Elaborar y ejecutar la estrategia para el cambio. d. Potenciar las habilidades del capacitador para el manejo de las relaciones con

todos los niveles de la organización. e. Facilita el diálogo para la solución creativa de los conflictos naturales. f. Alinea a la organización a través del diseño y ejecución de la estrategia de

comunicación masiva. g. Habilita los grupos de trabajo para enfrentar los retos inherentes de las nuevas

responsabilidades para que puedan más fácilmente cumplir con los entregables comprometidos en tiempo y forma.

Las herramientas básicas de Administración del Cambio que se deben considerar son:



14


a. Diagnóstico I. Situacional

II. Riesgos III. Patrocinadores IV. Evaluación de los facilitadores

b. Comunicación

I. Elaborar la Estrategia de Comunicación para informar y sensibilizar al personal.

c. Integración y formación de equipos de trabajo

d. Transferencia de habilidades y conocimientos I. Se refiere a la coordinación efectiva de la capacitación y a la adecuada

formación de los capacitadores.

9.5.5 Capacitación

El INTERESADO deberá presentar un plan de capacitación, para el equipo de proyecto, dirigido tanto a personal técnico como funcional. La capacitación de la solución propuesta deberá ser impartida en las instalaciones propias del ―INSTITUTO‖. El INTERESADO deberá privilegiar en su propuesta los planes de capacitación basados en cursos estándar presenciales alineados con los planes y modelos de capacitación del fabricante o fabricantes de la solución propuesta. Cada curso debe estar estructurado según el tipo de personal al que va dirigido: administradores del sistema, analistas, programadores, usuarios y otros colaboradores del INSTITUTO. La capacitación a personal técnico, del software de aplicación, deberá estar enfocada a proporcionar los conocimientos sobre la funcionalidad específica y detallada de los procesos a implementar, que permita la conducción de proyectos subsecuentes en el corto plazo y la autonomía a través de expertos propios. El INTERESADO podrá proponer dentro de su propuesta una solución o herramienta que le facilite la generación de la documentación o manuales propios de la capacitación a otorgar.

9.5.6 Estrategia de Pruebas y Migración de Datos

9.5.6.1 ESTRATEGIA DE PRUEBAS

El Contratista deberá proponer las especificaciones del plan de pruebas del sistema propuesto a implementar y someterlas a aprobación del “INSTITUTO” para cada uno de los niveles de prueba establecidos:

a. Pruebas unitarias (de funcionalidad de cada módulo) b. Pruebas de integración (del conjunto de módulos) c. Pruebas del sistema (del comportamiento) d. Pruebas de volumen de información (migración y prueba de agotamiento ―stress‖) e. Pruebas de seguridad f. Pruebas de integridad

9.5.6.2 Estrategia de Migración de Datos

La información a migrar en el nuevo sistema será conformada tanto por aquellos datos requeridos para iniciar la operación del nuevo sistema en base a saldos iníciales, catálogos base de operación y operaciones abiertas.



15


El Contratista deberá elaborar la definición de la estrategia en conjunto con el “INSTITUTO” para la migración de datos. Es responsabilidad del Contratista la definición de los formatos utilizados para la migración de datos.

La definición de la estrategia de la migración de datos deberá de contener al menos los siguientes elementos:

a. Actividades de preparación, calidad y formato de datos a migrar en la aplicación. b. Actividades de depuración y preparación de información. c. Asesoría del Contratista para la preparación y prueba de datos a migrar.

El “INSTITUTO” proveerá la información de acuerdo a los formatos electrónicos definidos en un conjunto con el Contratista , y solo podrá entregar la información que se almacene en los sistemas departamentales actuales. El “INSTITUTO” depurará la información en los plazos establecidos de acuerdo al cronograma acordado.

9.5.7 Estrategia de Cierre y Liberación

El Contratista proporcionará los criterios de aceptación de productos y entregables conforme a los requerimientos funcionales y de desempeño esperados en la implementación del software, dichos criterios de aceptación se realizarán en conjunto con el “INSTITUTO”.

La aceptación de conformidad de los productos, entregables y servicios se llevará a cabo por parte de las áreas usuarias y del departamento de informática, enfocando los siguientes objetivos:

a. Componentes del plan de trabajo y áreas clave para la administración del proyecto,

entre otros. b. Planos de Negocio considerando: factibilidad técnica de la solución, factibilidad

funcional de la solución, cobertura funcional de la solución, factibilidad de implementación y despliegue, entre otros.

c. Componentes implementados considerando: pruebas de unidad, pruebas de integración, volumen, agotamiento, concurrencia y conexiones remotas e interfaces con otros sistemas, entre otros.

9.6 Requerimientos Funcionales

La solución propuesta deberá estar en el idioma Español con opción multi-idioma y utilizar moneda nacional con opción multi-moneda. La Solución Integral de Gestión Administrativa de Recursos Gubernamentales (GRP) y Gestión Médica propuesta por el INTERESADO deberá ser parametrizable y no una herramienta a desarrollarse ni un desarrollo a la medida. La Solución propuesta deberá ser una solución integral y modular, la cual deberá permitir la interacción natural de todos y cada uno de los módulos y submódulos de la gestión clínica-médica y administrativa de los pacientes y centros. El Contratista deberá presentar un diagrama funcional que sea una referencia documental de la Solución Integral de Gestión Administrativa de Recursos Gubernamentales (GRP) y Gestión Médica que describa y presente la integración de los módulos solicitados por el ―INSTITUTO” y sus posibilidades de crecimiento.

A continuación se presenta la funcionalidad que al menos debe quedar implementada en el software del “INSTITUTO”, la cual se encuentra agrupada por proceso funcional.



16


El INTERESADO deberá calificar cada rubro mencionado, especificando claramente si cumple o no cumple con lo solicitado, según el subnumeral 9.6.1.1.

Uno de los criterios de evaluación de las propuestas se basará en establecer si se cumple o no con cada uno de los requerimientos funcionales especificados en el presente anexo, para lo cual los INTERESADOS deberán indicar si cumple o no con cada requerimiento.

9.6.1.1 REQUERIMIENTOS DE FUNCIONALIDAD DE RECURSOS FINANCIEROS

No. Funcionalidad Requerida Cumple: Si o No

Contabilidad

1 Alta, baja y modificación de plan de cuentas contables y virtuales

2 Manejo de multimoneda con conversión automática a moneda nacional.

3 Creación de cuentas contables, validando que la información se encuentre balanceada

4 Contabilización en línea de los diferentes módulos a implementar.

5 Obtención de saldos de cuentas de manera automática que sirva para los procesos diarios, así como para los cierres mensuales, cuatrimestrales y anuales.

6 Generaciones de operaciones en diversos periodos contables abiertos.

7 Seguimiento de información por medio de reportes estándar que permitan visualizar la información en línea.

8 Ejecución de procesos de arrastre de saldos.

9 Obtención de Estados Financieros (Estado de Resultados, Balance General, Balanza de Comprobación, Flujo de Efectivo).

Presupuesto

1 Alta, baja y modificación de unidades ejecutoras del gasto

2 Asignación, modificación y administración de la vigencia de partidas presupuestales que en conjunto con las unidades ejecutoras del gasto determinarán el presupuesto asignado.

3 Manejo de los diversos momentos presupuestarios que el INSTITUTO utilice (precompromiso, comprometido, devengado y pagado)

4 Control del presupuesto por medio de los diversos módulos a implementar, el mismo que será asignado de forma restrictiva

5 Posibilidad de realizar modificaciones al presupuesto por medio de ampliaciones o disminuciones (adecuaciones presupuestarias)

6 Definir partidas presupuestarias que sean asignables a programas institucionales



17


7 Obtención de reportes que puedan determinar el momento presupuestario en el cual se encuentra el presupuesto por unidad ejecutora del gasto.

Contraloría

1 Alta, baja y modificación de unidades ejecutoras

2 Control de gastos por áreas (unidades ejecutoras) y cuentas

3 Generación de procesos de distribución de gastos.

4 Obtención de reportes por diferentes conceptos: periodo, ejercicio, unidades ejecutoras y cuentas.

Cuentas por Pagar

1 Alta, baja y modificación de proveedores.

2 Alta, baja y modificación de cuentas de banco de proveedores.

3 Asignación de las condiciones de pago a cada uno de los proveedores

4 Registro de las facturas entregadas por los proveedores

5 Obtener el saldo y partidas individuales de proveedores

6 Seguimiento de los saldos y partidas pendientes de pago por proveedor.

7 Determinación de flujos de salida por fechas para definir el proceso de fondos necesario para tesorería.

Cuentas por Cobrar

1 Alta, baja y modificación de deudores.

2 Asignación de condiciones de pago de los deudores.

3 Emisión de recibos autorizados a los deudores.

4 Obtener saldo y partidas individuales de deudores.

5 Seguimiento de saldos y partidas pendientes de cobro por deudor.

6 Determinación de flujos de ingreso para transferencia para cubrir las cuentas por pagar del INSTITUTO.

Tesorería

1 Alta, baja y modificación de bancos y cuentas bancarias del INSTITUTO.

2 Pago de pasivos a proveedores en base a los datos de cuentas bancarias asignadas.

3 Dispersión de pagos entre cuentas del INSTITUTO a cuentas de proveedores.

4 Emisión de cheques para pagos.

5 Cambio de fecha de pago en base a los flujos de efectivo que se posean o acuerdos adicionales con proveedores.

6 Manejo de traspasos entre cuentas determinando la necesidad de flujo para los pagos correspondientes

7 Proceso para conciliación automática de pagos e ingresos que el INSTITUTO recibe diariamente para que se pueda tener al día los saldos de las cuentas bancarias.

Inventario de Activos Fijos



18


1 Alta, baja, traslados y modificación de activos fijos.

2 Determinación de vida útil por clase de activo fijo.

3 Determinación automática de depreciación de activo fijo en base a su vida útil para su contabilización.

Inventario de Activos Fijos (Flotilla)

1 Administrar todos los vehículos tales como automóviles, equipo pesado móvil, camiones, ambulancias, entre otros, para la Administración de Activos, Administración de Inventario y Administración de Trabajos.

2 Debe permitir registrar toda la información de atributos de los vehículos y equipo rodante.

3 Debe administrar reemplazos de piezas del vehículo

4 Debe Rastrear — desde la compra, hasta que se dé de baja —por número de serie y número de equipo, asignación, historial de mantenimiento y costo.

5 Debe permitir el registro de múltiples reparaciones para cada componente

6 Debe tener la capacidad de integrar múltiples lecturas provenientes de sistemas externos de administración de consumos.

7 Debe ser capaz de registrar historial de medidores y permitir la corrección de lecturas anteriores.

8 Debe tener la capacidad de rastrear un número ilimitado de lectura de medidores con historial.

9 Debe poder rastrear datos de vehículos con información clave tal como ubicación de reparación, entrada de medidor por orden de trabajo, tipo de combustible, entre otros aspectos.

10 Debe poder rastrear las llantas por número de serie o número único de parte.

11 Debe incluir rastreo de inventario y funcionalidad de compra como parte de una sola aplicación.

Mantenimiento Preventivo

1 El sistema debe manejar Pautas de trabajo en una biblioteca para poder ser utilizadas en las órdenes de trabajo o en el mantenimiento preventivo. La Pauta de Trabajo debe incluir operaciones/actividades, mano de obra, materiales, servicios estándares y herramientas (planificados y reales)

2 Dentro de una pauta de trabajo se debe poder hacer referencia a otra pauta de trabajo, generando posteriormente órdenes de trabajo jerárquicas

3 Debe poder definirse programa de mantenimiento preventivo utilizando frecuencias de tiempo y/o medidores.

4 Debe manejar múltiples disparadores: intervalo temporal (días, semanas, meses, años), medidores (pudiendo tener un número ilimitado de medidores en un mismo equipo, ejemplos Horómetros, Kilómetros, condiciones, y eventos).



19


5 Debe Generar órdenes de trabajo de mantenimiento preventivo, automáticamente cuando se cumplan los requisitos.

6 Debe permitir generar planes de mantenimiento preventivo estacional, especificando un determinado periodo de tiempo (estacionalidad)

7 Se debe poder definir a nivel de cada mantenimiento preventivo, los días de la semana para los que ese mantenimiento puede generarse, evitando por ejemplo que un preventivo se ejecute el fin de semana.

8 Debe permitir clasificar planes de trabajos múltiples en un mantenimiento preventivo único, donde se determina el siguiente a aplicarse de acuerdo a la secuencia de preventivos ya aplicados

9 Debe poder consultar las próximas órdenes de trabajo de mantenimiento preventivo en un equipo y/o ubicación, para sacar ventaja de paradas no planeadas de un equipo.

10 Debe dar un pronóstico de la futura fecha de mantenimiento preventivo para la planificación de recursos.

11 Automáticamente debe poder generar órdenes de mantenimiento preventivo de trabajo basadas en tolerancia, fechas de vencimiento o lecturas de medidor.

12 Automáticamente generar mantenimientos preventivos basándose en los resultados monitoreados de inspección de datos.

13 Debe generar mantenimientos preventivos a demanda, en lote o automáticamente, asociados por algunos campos (e.g. equipo, tipo de trabajo, taller, tripulación y otros que se requieran)

14 Debe permitir pasar por alto mantenimientos preventivos programados para generar ordenes de trabajo de mantenimiento preventivo a demanda.

15 Debe soportar múltiples criterios para generar órdenes de trabajo Mantenimiento Preventivo, activadores con múltiples medidores en el mismo activo, preaprobados definidos por el usuario para activo individual, y a través de Mantenimiento Preventivo basado en condición que sea generada cuando existan condiciones de operación predefinidas.

16 Debe permitir extensiones de Mantenimiento Preventivo y llevar registro para reprogramar ordenes de Mantenimiento Preventivo pendientes y mantenerse al tanto del progreso y realización del trabajo.

17 Debe soportar las estructuras de jerarquía de



20


Mantenimiento Preventivo, o Mantenimiento Preventivo anidados, a ser agrupados para ser activados de una sola vez.

18 Debe soportar programas de administración de trabajo predictivo a través de la generación automática de actividad de trabajo específico cuando se cumplan los parámetros específicos de las condiciones de operación.

19 El sistema debe permitir consolidar semanalmente, mensualmente, trimestralmente, planes de trabajo en un solo Maestro de Mantenimiento Preventivo.

20 Debe soportar el establecimiento de rutas de Mantenimiento preventivo con múltiples activos y/o ubicaciones designadas.

21 Debe tener indicaciones automatizadas para alertar al usuario que se vence una fecha de inspección de Mantenimiento Preventivo.

22 Debe permitir la asignación de prioridad a un Mantenimiento Preventivo cuando se desee.

23 Debe tener indicaciones automáticos para alertar al usuario que llegó una fecha de inspección de un Mantenimiento Preventivo.

9.6.1.2 REQUERIMIENTOS DE FUNCIONALIDAD DE RECURSOS MATERIALES


Abastecimientos

1 Validación automática de la disponibilidad presupuestal al inicio del proceso de Solicitud de Pedidos y Pedidos de Compra que sean realizados

2 Creación de Solicitudes de Pedidos por parte de los usuarios que requieren insumos, servicios y/o activos fijos, validando que los datos maestros existan.

3 Búsqueda de proveedores para asignación en los pedidos de compra.

4 Creación de Pedido de Compra por parte de compradores, con 2 o 3 niveles de autorización para su procesamiento de compra, validando que los datos maestros existan.

5 Manejo de pedidos de compra por contrato abierto y autorizaciones para compra fuera de contrato abierto por el INSTITUTO.

6 Formato de Pedido de Compra para confirmación a proveedores de la compra a realizar.

7 Integración automática entre el módulo de abastecimientos y contabilidad para generar



21



Abastecimientos

documentos contables de forma transparente.

8 Reportes para visualizar la información histórica de las compras realizadas, por proveedor, material y/o servicio

Almacenes

1 Alta, baja y modificación de materiales y servicios

2 Manejo de inventarios, entradas, salidas y traspasos de materiales

3 Asignación de estatus de materiales recibidos determinando

4 Integración automática con el área de cuentas por pagar validando la recepción del bien y/o servicio para iniciar con el trámite de pago al proveedor

5 Asignación de Centros Logísticos y almacenes para el control de inventarios

6 Posibilidad de realizar inventarios físicos y ajustes de los mismos en el sistema.

7 Reportes para visualizar el inventario existente por centro logístico y almacén así como el estatus del mismo

9.6.1.3 REQUERIMIENTOS DE FUNCIONALIDAD DE RECURSOS HUMANOS


Administración de Personal

1 Alta, baja y modificación de datos de empleados, así como asignación de unidad organizacional y nivel dentro de la organización.

2 Manejo de información personal de empleado así como información familiar.

3 Asignación de categoría al empleado para determinar el pago de la nómina

4 Obtención de recibos de nómina

Nómina

1 Mantenimiento de tabulador para el pago de la nómina de las diversas categorías existentes

2 Definición de nóminas ordinarias y extraordinarias.

3 Cálculo de obligaciones fiscales (pago de impuestos, cálculo anual, declaraciones informativas, entre otros)

4 Administración de préstamos.

5 Administración de pensión alimenticia

6 Control de descuentos.

7 Finiquitos de ley



22



Administración de Personal

9 Integración de salario para indemnizaciones.

10 Resumen de periodo de nómina con detalle de empleado y acumulado.

11 Generación de finiquitos masivos.

12 Seguimiento y manejo de licencias solicitadas por el empleado.

13 Realizar el cálculo de retroactivos en los casos que aplique (aumento de sueldo)

14 Seguimiento de transferencias de empleados a otras áreas y/o ubicaciones.

15 Captura de incidencias que afecten el cálculo de la nómina.

16 Opción de reproceso de la nómina.

17 Integración con el sistema contable, Guatenóminas u otros sistemas de manera satisfactoria.

Administración Pecuniarias

1 Integrar las solicitudes recibidas para el trámite de pago de pensiones aprobadas por el sistema de nómina electrónica y/o otros sistema

2 Administrar la relación de pensionados aprobados para procesamiento de pagos por concepto de nómina pecuniaria

3 Calculo del monto a pagar de las pensiones recibidas y aprobadas para la generación de pagos por concepto de nómina pecuniaria de pensionados

4 Resumen de periodo de nómina pecuniaria con detalle de pensionado y acumulado.

5 Administración de la nómina pecuniaria de pensionados

6 Integración con el sistema contable de manera transparente

9.6.1.4 REQUERIMIENTOS GENERALES GESTIÓN ADMINISTRATIVA


Generales

1 Se requiere que todos los componentes de software a implantar hayan sido desarrollados de origen por el mismo fabricante de la solución marca SAP o su equivalente.

2 Interfaz de usuario totalmente en idioma



23



Generales

español, y en su caso permitir configurar a otro idioma.

3 La instalación de los componentes de software de la solución en ambiente de producción deberá ser en forma gradual.

4 Deberá contar con una independencia funcional de componentes.

5 Los módulos incluidos en la solución, motivo de esta manifestación deben contar con la capacidad de operar en forma natural y 100% adecuada bajo una plataforma tecnológica de alta disponibilidad.

6 Deberá contar con su propia herramienta de ayuda, esta deberá estar en línea, en idioma español y deberá proveer dicha ayuda en varios niveles, es decir a nivel general, de módulo, de pantalla y de campo. Esta ayuda deberá poder ser modificable para complementar o ajustar los textos de ayuda.

7 Deberá operar de forma integral y en línea, es decir que los registros de las operaciones sustantivas de los diversos procesos / módulos afecten de manera integral toda su cadena de valor en tiempo real.

8 Interacción con hojas de cálculo (al menos Microsoft Excel) tanto para importar como para exportar información, para preparar informes con características especiales.

9 Deberá poder generar archivos en diversos formatos (TXT, XLS, ASCII, XML, HTML)

10 Deberá permitir realizar operaciones en distintas monedas en todos los tipos de transacciones, con conversión automática y en tiempo real a quetzales.

11 Deberá contener un calendario configurable para días hábiles y no hábiles nacionales.

12 Deberá lograr comunicarse con otros sistemas utilizando interfaces de entrada y salida.

13 Deberá permitir la integración de tecnología Internet para manejo de transacciones con alta seguridad.

14 Deberá mantener una base de datos histórica de información procesada.

15 Deberá generar registros de auditoría parametrizables por el usuario.

16 Deberá contar con una herramienta de control de cambios a los registros para control y auditoría.

17 Deberá incluir indicadores de desempeño generales y a su vez permitir la creación de



24



Generales

nuevos indicadores de desempeño de acuerdo a las necesidades de los usuarios.

18 Deberá contar con un control automático consecutivo para la asignación de números a los diferentes tipos de documentos que se generen dentro de los procesos del sistema, así como la parametrización y configuración de los mismos de acuerdo a las necesidades del usuario y proceso.

19 Deberá permitir la automatización de flujos de trabajo, relacionando operaciones y transacciones de negocio, de forma que en el propio sistema se puedan identificar, validar, aprobar, turnar, cancelar o modificar operaciones relacionadas con los flujos de trabajo.

20 Deberá incluir un Workflow configurable a ―n‖ pasos, secuenciales, condicionales, y paralelos con posibilidad de soportar el envío de documentos para gestión en los diferentes componentes de la solución integral.

21 Deberá permitir definición y diseño grafico de flujos de trabajo que integre: asignación de funciones, definición y mantenimiento de reglas de negocio, delegar tareas, escalar tareas, semaforización y alertas programables.

22 Deberá incluir manejo de Firma electrónica de documentos (Autorizaciones de usuario)

23 Deberá permitir adjuntar información no estructurada a los registros y transacciones de la solución, como pueden ser hojas de cálculo, documentos electrónicos, digitalizados e imágenes.

24 Deberá ser fácilmente adaptable a los cambios en procesos, normas y reglamentos sin necesidad de realizar modificaciones de alto impacto en su configuración.

25 Deberá contar con la suficiente flexibilidad para soportar cambios estructurales durante el ejercicio fiscal sin afectar su operación. Por ejemplo la división o creación de nuevas unidades de negocio o proyectos.

26 Deberá permitir al usuario realizar y parametrizar sus propias consultas y reportes de información.

27 Deberá contar con una herramienta que permita al usuario generar reportes personalizados según su necesidad, incluyendo en sus casos gráficos.

28 Deberá asegurar que las consultas y reportes



25



Generales

en línea permitan derivar a diversos niveles de detalle.

29 Deberá incluir una serie de reportes predefinidos que sean parametrizables por el usuario.

30 Deberá ser flexible en la creación de campos adicionales definidos y requeridos por el usuario en las diversas pantallas y tablas de la base de datos.

31 Deberá permitir que el usuario final pueda utilizar "shortcuts", combinación de teclas de acceso rápido, nombre de la operación o transacción para navegar por la aplicación.

32 Deberá contar con documentos, oficios, memoranda , circulares en formatos estandarizados

33 Deberá generar etiquetas para identificación e expedientes.

Seguridad

34 La solución deberá mantener una clave y una contraseña única y personal para los usuarios, que le permita el acceso a los módulos (no al Sistema Operativo ni a la Base de Datos aún cuando el usuario contará con las herramientas necesarias para hacerlo).

35 Deberá mantener estándares y políticas para generación de claves de usuario y contraseñas.

36 Deberá permitir la definición de perfiles de seguridad para facilitar la asignación y exclusión de permisos a grupos de usuarios.

37 Deberá permitir la encripción de contraseñas y archivos así como la capacidad de integrar de manera natural o mediante interfaz, soluciones de identificación Biométrica al procedo de reconocimiento del derechohabiente.

38 Deberá asegurar que las contraseñas no sean editables aún para el nivel máximo de administrador del sistema.

39 Deberá permitir controlar el estado de los usuarios como: activo, baja, suspendido, vencido.

40 Deberá restringir el acceso mediante la utilización de perfiles de seguridad para los usuarios de acuerdo a la estructura organizacional, funciones, niveles de operación, tipo de personal o estado.

41 Deberá permitir la administración de usuarios



26



Generales

respecto a accesos de lectura y escritura a nivel de aplicación, módulo, menú, opción del menú y a nivel de campo.

42 Deberá contener un módulo de seguridad de cuentas de usuario que maneje caducidades parametrizadas y el histórico de contraseñas.

43 Deberá permitir incluir al sistema de seguridad datos adicionales y en forma automática (ejemplo: el número de empleado, nivel de estructura)

44 Deberá permitir el acceso a la aplicación mediante una combinación de los niveles de autorización siguientes: • Nivel de módulo • Nivel de menús • Nivel de transacción • Nivel de campo

45 Deberá permitir mecanismos de seguridad (supervisores, doble autorización) para el acceso a operaciones especiales (ejemplo: manejo de transferencias a bancos, eliminar transacciones, corregir registros)

46 Deberá permitir definir el número máximo de intentos de acceso no exitosos en la autentificación inicial al sistema.

47 Deberá bloquear las claves de usuarios, que intenten accesos no autorizados.

48 Deberá permitir controlar la desconexión automática de usuarios por inactividad de la sesión de trabajo a nivel de aplicación.

Técnicos

49 Deberá identificar y controlar procesos monitoreando las cargas de trabajo que generen y los recursos que se consuman.

50 Deberá desempeñarse en ambiente de tiempo real considerando misión crítica en todos los módulos.

51 Deberá vigilar su propio funcionamiento, identificar y notificar los errores que ocurran.

52 Deberá garantizar la integridad y seguridad de la base de datos.

53 Deberá incluir herramientas de respaldo automático, independientes de las que tenga la base de datos y el sistema operativo.

54 Deberá contar con las facilidades para su integración con aplicaciones satelitales.

55 Deberá tener compatibilidad con los estándares internacionales (EDI) de exportación electrónica de archivos.

56 Deberá contar con la capacidad de control de la integridad de su información, incluyendo



27



Generales

los mecanismos de recuperación automática en casos de interrupción de transacciones y contar con pistas de auditoría.

Reportes

1

Deberá contar con herramientas propias para la generación de reportes en pantalla o impresos.

2 Deberá permitir la generación de gráficos en diversos formatos de 2 y 3 dimensiones.

3 Deberá permitir la clasificación de información de renglones y columnas en orden ascendente o descendente con múltiples niveles agrupados.

4 Deberá permitir especificar subtotales y totales en renglones y columnas de acuerdo al cumplimiento de criterios en los datos del mismo reporte.

5 Deberá permitir la generación de fórmulas, algoritmos y filtros.

6 Deberá permitir que los importes en los reportes se presenten en unidades, en miles, en millones.

7 Deberá permitir en todos sus componentes, la asignación de valores por omisión en los registros.

8 Deberá contar con asistencia guiada para la construcción de las consultas o reportes.

9 Deberá permitir utilizar comodines (wildcards), y operadores relacionales ( > , < , >= ) así como usar operadores lógicos (and, or, not) en la especificación de criterios de búsqueda.

10 Deberá permitir el análisis a niveles detallados (de profundidad) dentro del mismo reporteador (drill-down).

11 Deberá permitir generar reportes en formatos de Microsoft Office, texto, xml, PDF y HTML y exportarlos hacia aplicaciones analíticas.

12 Deberá permitir especificar la fecha y hora de ejecución del reporte en forma automática.

13 Deberá permitir obtener una relación de todos los reportes disponibles del sistema, total, por módulo, por usuario.

14 Deberá permitir la impresión de reportes tanto en línea como por lotes (batch).

15 Deberá permitir restringir el número de tablas que un usuario puede incluir en un reporte y facilitar la construcción de las consultas.

16 Deberá permitir de dar de alta los reportes en el menú del sistema.



28


9.6.1.5 REQUERIMIENTOS DE FUNCIONALIDAD DE GESTIÓN MÉDICA


Generales de Gestión Medica

1 La solución propuesta debe tener la capacidad de soportar diversos sistemas operativos, entre ellos Windows, UNIX o Linux.

2 La solución propuesta debe tener la capacidad de soportar diversas bases de datos relacionales que estén basadas en el estándar ANSI como Oracle, MS SQL, SyBase o DB2.

3 El sistema propuesto debe permitir el uso de un cliente liviano ó "Thin Client".

4 El sistema debe manejar un identificador único para cada asegurado y beneficiario.

5 Debe de manejar los datos de afiliación, personales, familiares, historial médico.

6 Adicional al identificador interno, debe manejar otros identificadores externos como cédula, pasaporte, y otros documentos de identificación.

7 El sistema debe manejar el estándar HL7 para el intercambio, integración, compartir y recuperar información de otros sistemas ejemplo PACS y RIS.

8 El sistema debe cubrir los niveles asistenciales de consulta externa y atención especializada de hospitalización, con una única historia clínica electrónica unificada que disponga de una base de datos poblacional para la identificación del paciente en todo el sistema de salud.

9 El sistema debe mantener una historia clínica por paciente que debe estar disponible a nivel de todo el ―INSTITUTO”.

10 El sistema debe tener la capacidad de definir una estructura de servicios que están conformado por uno o más profesionales que manejan una especialidad.

11 El sistema debe manejar catálogos de actividades y eventos definidos para todo el



29


―INSTITUTO”.

12 Deben tener la capacidad de poder definir ‗n‘ cantidad de catálogos como sean necesarios..

13 El sistema debe tener la capacidad de solicitar actividades en formas distintas.

14 El sistema debe tener la capacidad de manejar en estructura todos los centros asistenciales incluidos en el alcance del proyecto y capacidad de incorporar el resto de unidades asistenciales que compone el ―INSTITUTO”.

15 El sistema debe manejar la ubicación (consultorio, cama), así como la localización (Radiología, Quirófano, entre otros) .

16 El sistema debe tener la capacidad de definir la estructura física de los Centros

17 El sistema debe tener la capacidad de definir la estructura funcional de cada centro basado en las actividades que desarrollan cada unidad funcional

18 El sistema debe tener la capacidad de definir episodios asistenciales

19 El sistema debe tener como centro al paciente en todo momento, los flujos de trabajo que se definan deben apuntar siempre a la satisfacción del paciente y agilizar las tareas del personal del ―INSTITUTO”.

20 El sistema debe manejar un catalogo y estados de procesos común para todo el ―INSTITUTO”.

21 El sistema debe manejar alertas que pueden ser generadas automáticamente por el sistema o por un operador del sistema

22 El sistema debe tener la capacidad de manejar transferencias de documentos

23 Además de las pantallas gráficas de operadores normales, el sistema debe contar de pantallas táctiles para el registro rápido y facilidad de operación del mismo, como en urgencia, hospitalización, quirófano, entre otros

24 El sistema debe manejar la definición de los usuarios a utilizar y administrar el sistema

25 Debe poder definir roles por usuario o por grupo



30


26 El sistema debe permitir el balanceo de cargas entre servidores, tanto para usuarios al autentificarse, como para procesos

27 El sistema debe permitir la administración y re-ejecución de procesos y tareas interrumpidas (síncronas y asíncronas).

28 El sistema debe permitir el monitoreo de la utilización y desempeño de las aplicaciones que están corriendo o en espera: Base de datos, Sistema operativo

29 El sistema debe contar con una herramienta que permita realizar desarrollos utilizando la tecnología orientada a objetos

30 El sistema debe poseer un registro de las versiones que determina en cual fueron creados todos los objetos del sistema

31 El sistema debe poseer mecanismos o planes de contingencia que permiten regresar a versiones anteriores en caso de fallas en el registro de nuevas versiones

32 El sistema debe permitir la personalización de los menús por usuario, por grupos de usuarios o por tipo de usuario

33 Las contraseñas no deberán ser editables aún para el nivel máximo de administrador del sistema

34 Debe llevar un registro histórico de modificaciones a los catálogos. Donde guarde el usuario, la fecha y la hora de las modificaciones.

35 Debe producir código compatible con el estándar de desarrollo XML, HTML para ambientes de Internet

36 La solución debe ser capaz de establecer comunicación a través de multi-protocolos TCP/IP, HTTP, HTTPS, ATM, Frame Relay en redes como: LAN, WAN, Internet, intranet, extranet

37 La codificación usada para representación de datos clínicos en las visitas debe ser configurable y adaptable a cada una de las necesidades de los profesionales (CIE-X, CPT, Codificación NANDA, entre otras)

38 La solución debe operar sobre una plataforma tecnológica que soporte los estándares de integración definidos por el consorcio WS-I, tales como SOAP, WSDL y UDDI para la construcción y ejecución de SERVICIOS Web



31


(Web Services) que permitan la integración de la Solución propuesta de forma directa con otras aplicaciones o a través de herramientas de EAI o Integration Brokers que utilicen estos estándares

39 El sistema debe mantener el registro de todas las transacciones con fecha, hora y usuario que realizó la operación

Seguridad del Sistema de Gestión Medica

1 El sistema debe permitir la creación de roles asignando privilegios de uso por aplicación, menús y pantallas

2 Se debe permitir asignar un usuario a uno o más roles. De esta forma sus privilegios serán la combinación de los privilegios de los roles asignados

3 El sistema debe tener un módulo para la administración de los privilegios totales que tiene una persona

4 Debe permitir definir si un rol tiene autorización para generar transacciones en diferentes centros de atención

5 Debe permitir definir qué campos de información asociados a una aplicación son visibles para los miembros de un grupo de usuarios

6 Debe ser posible definir algunas características asociadas a la generación de contraseñas, tales como, largo de contraseña y el tipo de carácter que puede contener

7 Debe contar con la posibilidad de indicar el tiempo de duración de la contraseña, y permitir notificar a los usuarios con anticipación de su expiración

8 Debe poseer la funcionalidad para auto registro que será utilizada por aquellos usuarios que ingresarán al sistema para someter solicitudes de servicios (Ejemplo Citas)

Registro de Pacientes

1 Deberá usar el identificador único para cada paciente del Registro Único de Afiliados y Pacientes para todas las Líneas de Servicio, y también para el número de expediente clínico

2 Registro único de pacientes, esto es, que el sistema permita que una vez registrado un paciente en una Línea de Servicio, en caso de ingresar a otra línea en alguna otra



32


ocasión, se hace uso de este mismo registro en la segunda Línea de Servicio

3 El sistema debe manejar eventos por pacientes, esto es, actualiza el mismo registro cada vez que el paciente regresa a ser tratado en cualquier Línea de Servicio

4 El sistema debe mantener un índice para todos los encuentros por paciente

5 Debe poderse configurar los tipos de visita por área de especialidad

6 sistema debe permitir ligar varios médicos a un solo paciente e incluso a modificar el médico tratante registrado en caso de ser necesario

7 Los pacientes podrán ser localizados por match parcial o completo de nombre

8 Los pacientes podrán ser localizados por el número RUAP

9 Los pacientes podrán ser localizados por número de visita o episodio

10 Los pacientes podrán ser localizados por búsqueda específica predefinida por el usuario

11 Los pacientes podrán ser localizados por fecha de nacimiento

12 Los pacientes podrán ser localizados por médico(s) tratante(s)

13 Los pacientes podrán ser localizados por fecha de admisión anterior

14 Los pacientes podrán ser localizados por fecha de egreso anterior

15 Los pacientes podrán ser localizados por diagnóstico

16 El sistema debe permitir fusionar registros de pacientes integrando toda la información generada en todos sus eventos o episodios identificados con casos de eventos de urgencia con pacientes no identificados, una vez que se conozca la identidad del paciente

17 Los datos generales de los pacientes deberán verse y podrán editarse (modificar) en línea

18 El registro debe incluir un campo de: Nombre completo del paciente

19 El registro debe incluir un campo de: Sexo, Edad, Estado Civil, Domicilio, Teléfono



33


Particular, Teléfono Celular y/o Dirección de Correo Electrónico y Religión

20 El registro debe incluir, en caso de ser menor de edad o incapacitado, un campo de: Nombre completo del padre y/o tutor

21 El registro debe incluir, en caso de ser menor de edad o incapacitado, un campo de: Domicilio del padre o tutor

22 El registro debe incluir, en caso de ser menor de edad o incapacitado, un campo de: Teléfono del padre o tutor

23 El registro debe incluir, en caso de ser menor de edad o incapacitado, un campo de: Teléfono celular y/o correo electrónico del padre o tutor

Registro de Datos del Médico

1 Para el registro de un paciente debe existir un campo para: Médico externo de referencia en base a catálogo de médicos

2 Para el registro de un paciente debe existir un campo para: Médico tratante del centro

3 Para el registro de un paciente debe existir un campo para: Médico inter consultante del centro

4 Para el registro de un paciente debe existir un campo para: Médico que realiza estudio y/o del Servicio

Gestión de Quirófanos, Pacientes y Procedimientos Quirúrgicos

1 El sistema debe manejar la inclusión de pacientes al listado de demanda quirúrgica

2 El sistema debe poder registrar pacientes desde diferentes orígenes; consultorios, urgencias, de hospitalizados en otros centros, entre otros

3 El sistema debe manejar las pruebas y consultas preoperatorias del paciente, así como la consulta de pre anestesia

4 El sistema debe de manejar la planificación y programación de quirófanos

5 El sistema debe poder manejar salidas del listado de demanda quirúrgica por diferentes motivos

6 El sistema debe permitir la gestión de los listados de pacientes en demanda quirúrgica sea por centro, red asistencial o organización



34


7 El sistema debe de manejar diferentes estados del paciente en la lista de espera

8 El sistema debe poder manejar cuantos cambios de estado sean necesarios, indicando fechas y motivos de los mismos

9 Permitir al personal autorizado tener acceso a la ficha de intervención de cualquiera de las cirugías programadas

10 Proporcionar los datos recogidos en la programación como: Fecha/hora de inicio y finalización de la programación, Intervención, Ocupación de sala, entre otros.

11 El sistema debe manejar definición de quirófanos dentro de cada Unidad asistencial

12 El sistema debe de llevar tipos de intervenciones

13 Los quirófanos deben poder estar organizados en sesiones y turnos

14 El sistema debe poder manejar agendas o turnos especiales de quirófanos

15 El sistema debe manejar la inclusión de paciente en la agenda del quirófano, se debe poder consultar el estado de programación por diferentes criterios

16 El sistema debe de manejar información del paciente para poder realizar la reserva del quirófano

17 El sistema debe de contar con la capacidad de reprogramación de reservas

18 El sistema debe poder manejar cirugía de urgencias y no programadas

19 Debe presentar la historia de acuerdo con la estructura definida para el ámbito y con las preferencias del profesional

20 Permitir el registro de constantes, consulta del histórico de constantes de forma numérica y gráfica

21 Permitir la generación e histórico de Informes clínicos

22 Gestión de peticiones: Farmacológicas, peticiones de pruebas diagnósticas, Petición de Interconsulta, entre otros

23 Registro de la Actividad Quirúrgica, hitos de entrada, comienzo de intervención, salida, medicación, constantes, entre otras



35


24 Permitir la elaboración de notas médicas (pre-operatoria, post-operatoria, pre-anestésica) y solicitudes de estudio

25 Poder consultar expedientes desde este módulo

26 Permitir diferenciar entre el diagnóstico y prestación de entrada y salida

27 Registrar la sala en la que se realizará y cama de recuperación asignada

28 Registrar al equipo interviniente, registrando cada miembro del personal, su función y tiempo de participación

29 Poder registrar el material planificado, el utilizado y su consiguiente repercusión en los inventarios

30 Permitir registrar los hemocomponentes utilizados durante una cirugía

31 Poder registrar en el módulo el tipo de anestesia empleada

32 Permitir el ingreso de informes asociados a la intervención por cada miembro del equipo interviniente participante

33 Permitir en el caso de partos, el registro de cada nacimiento

34 Poder registrar en el sistema los datos referentes a semanas y días de gestación, tipo de parto, puerperio, condiciones del embarazo, parto prematuro o en tiempo

35 Poder registrar los datos del personal que dé atención al parto

36 Registrar por cada recién nacido, información referente a la fecha y hora de expulsión, sexo, peso, talla, grupo sanguíneo, PH, las tres pruebas de Apgar, el estado del recién nacido, destino, tipo de reanimación, datos de identificación y complicaciones

37 Registrar si el recién nacido fallece, el lugar del deceso (Hospitalización, reanimación, en la exploración, entre otros)

38 Registro de comprobaciones necesarias después de intervención

39 Capacidad de pantalla táctil para el registro rápido de los datos

Gestión de Hospitalización de Pacientes

1 El sistema debe poder manejar pre-



36


hospitalización de pacientes.

2 El sistema debe poder registrar y gestionar pre ingresos de pacientes

3 El sistema debe tener la capacidad de gestionar la notificación de pre ingreso de pacientes.

4 El sistema debe poder gestionar la admisión de pacientes ya sea desde urgencia, consulta externa, lista de espera quirúrgica, hospitalización.

5 Debe permitir anular el ingreso, siempre y cuando no se haya realizado actividad alguna al paciente.

6 El sistema debe validar los datos del paciente al momento de asignar una cama, por ejemplo aislamiento, sexo, edad.

7 El sistema debe gestionar a los pacientes hospitalizados.

8 Desde el sistema se debe gestionar los servicios y médicos asignados.

9 En el sistema se debe llevar un registro de todas las ubicaciones donde se ha encontrado el paciente hospitalizado.

10 El sistema debe gestionar las Altas de los pacientes hospitalizados, mediante este proceso se dará el alta administrativa del paciente y se registrarán los datos requeridos para el alta, y el destino del paciente como por ejemplo domicilio, exitus, consultas externas, hospitalización, otros hospitales, entre otros

11 El sistema debe tener la capacidad de anular Altas.

12 El sistema debe de gestionar las camas del hospital.

13 El sistema debe permitir la generación de plantas de enfermería y gestión de camas para pacientes ambulatorios (hospital de día).

14 El sistema debe manejar diferentes estados para las camas entre ellas libre, ocupada, entre otras.

15 Permitir conocer en todo momento el estado de ocupación de cada cama de la planta o Unidad de Enfermería.

16 Permitir también la libre asignación de cama al paciente de conformidad con necesidades



37


especiales de atención.

17 Permitir el registro del cambio de cama de un paciente dentro del mismo piso o servicio o hacia distinto piso o servicio, debiendo contener un historial de transferencias por episodio.

18 Debe manejar partes judiciales.

19 Debe permitir el registro y notificación de accidentes y agresiones.

20 Debe permitir ver informes clínicos del paciente.

21 Permitir imprimir los reportes de ocupación hospitalaria por cada unidad médica.

22 Permitir imprimir los reportes de censo de camas de la unidad médica.

23 Emitir el informe correspondiente en caso de egreso por defunción

Gestión de Imagenología

1 Estar preparado para trabajar en unidades de

radiología independientes o integradas al cien

por ciento con el sistema hospitalario.

2 Permitir administrar toda la información

relativa a pacientes y a estudios realizados

por paciente

3 Permitir consultar la lista de pacientes

programados por día

4 Permitir conocer en todo momento la

ubicación física del paciente en el servicio de

Imagenología, diferenciando si se encuentra

en la sala de espera, sala de cuidados o

alguna sala de exploraciones

5 Permitir diferenciar el estado de los pacientes

que se encuentran en el servicio, los que se

encuentran en estudio, los que han finalizado

el estudio, o bien los pacientes que aún

estando citados, no han llegado al servicio

6 Permitir registrar la hora de llegada del

paciente a la cita, y si éste está o no

preparado para que se le realice el estudio

7 Permitir notificar a la sala de exploración

cuando el paciente en sala de espera esté

listo para ingresar.

8 Permitir asignar citas urgentes, de forma

directa, indicando las pruebas que se requiera

se le realicen a dicho paciente.

9 Permitir modificar el número de estudios o

pruebas programados para los pacientes



38


citados si fuere necesario

10 En caso de que un paciente se presente sin la

preparación necesaria para la realización de

una prueba, el sistema permitirá el registro

del rechazo desde la recepción, registrando la

razón y acción realizada

11 Poder generar estadísticas que permitan

explotar rápidamente la información generada

12 Integrar archivos planos de RX

13 Permitir integrar procesos de RIS – PACS

14 Posibilidad de incluir imágenes en el expediente e incluso el informado de las mismas, se tendrían controladas de manera semi automática

15 Capacidad de adjuntar manualmente archivos externos, multimedia, o imágenes en formato JPG y catalogarlo para su futura accesibilidad por cualquier profesional autorizado a acceder al expediente del paciente.

Gestión de Agendas y Citas

1 El sistema debe gestionar las citas de consulta externa de pacientes.

2 El sistema debe permitir crear y modificar agendas de los servicios de salud por unidades, especialidades y profesionales.

3 El sistema debe poder realizar búsquedas de agendas por Unidad Ejecutora, Servicio, Profesional.

4 El sistema debe permitir bloquear y desbloquear agendas.

5 La configuración de las agendas debe permitir la programación de las mismas por rangos de fechas, por días, entre otras.

6 El sistema debe de poder realizar búsqueda de pacientes por diferentes campos cédula, nombre, pasaporte, seguro social, entre otros para asignarle una cita.

7 El sistema debe permitir agendar múltiples citas para un paciente.

8 El sistema debe permitir generar citas para planificar programas de Médicos de cabecera.

9 El sistema debe permitir gestionar citas pendientes por asignar fechas por paciente o por lote.

10 El sistema debe permitir gestionar lista de notificaciones ya sea por teléfono, SMS, email, entre otras.

11 El Sistema debe permitir reprogramaciones



39


de citas simples o en lotes.

12 El sistema debe permitir generar citas extras.

13 El sistema debe permitir ver las citas anteriores del paciente al momento de asignar citas para validar.

14 Se debe poder consultar citas por paciente, especialidad, profesional.

15 Debe permitir la anulación de citas

Gestión de Urgencias

1 El módulo de urgencia debe poderse manejar a través de pantallas táctiles.

2 Debe poderse manejar sin el uso de ratón.

3 Debe poder manejar escala de colores para el manejo de listado de pacientes, triage, entre otros.

4 El módulo de urgencia debe manejar la identificación del paciente en cualquier ubicación y condición que se encuentre.

5 El sistema debe permitir registrar todos los actos realizados sobre el paciente en su período de instancia en urgencia.

6 El sistema debe manejar todos los estados en el servicio de Urgencia de un Paciente, registro, en espera de triaje, en triaje, consulta, observación, entre otros.

7 El sistema debe manejar la agenda de consulta médica basado en los diferentes servicios que se ofrece en urgencia.

8 El sistema debe poder manejar la admisión de pacientes no asegurados o beneficiarios en urgencias.

9 El sistema debe manejar triage para la evaluación de los pacientes en urgencia.

10 Los profesionales médicos y de enfermería deben tener acceso al módulo del expediente del paciente para gestionar la consulta.

11 El sistema debe poder manejar alta de urgencia.

12 Debe manejar la actualización de los datos en tiempo real y de forma automática.

13 El módulo de urgencia debe manejar la evolución del paciente.

14 El sistema debe poder manejar ordenes de servicios como radiología, laboratorio, farmacia, entre otros.



40


15 Se debe poder derivar a los pacientes de urgencias a otras unidades como quirófanos, o a otras unidades de atención.

16 Presentar la historia clínica electrónica de acuerdo con la estructura definida para el ámbito y con las preferencias del profesional de la salud.

17 Permitir el registro de constantes, consulta del histórico de constantes de forma numérica y gráfica.

18 Permitir la declaración de enfermedades de declaración obligatoria.

19 Permitir el uso de cuestionarios de exploración.

20 Presentar alertas de superación del tiempo de atención en función del triage.

21 Permitir las derivaciones a consulta externa, peticiones de pruebas diagnósticas, Petición de Interconsulta, Órdenes para enfermería, Petición de derivación a otro centro.

22 Permitir la generación e histórico de Informes clínicos.

23 Posibilidad de Re-triage y modificación de triage antes de que se inicie la atención.

24 Permitir el registro de la atención clínica recibida con todos los datos relativos a la misma: Motivo de consulta, anamnesis, exploración, juicio clínico, entre otros.

25 Permitir la prescripción farmacológica por el facultativo.

26 Registrar la aplicación de fármacos y procedimientos médicos por los enfermeros con alertas del no cumplimiento de las pautas prescritas.

27 Gestionar los planes de Cuidados en Urgencias; Balance Hídrico, Curas y Vendajes, entre otros.

28 Permitir generar el alta de urgencias por las distintas causas: ingreso en planta, curación, fallecimiento.

29 Permitir la consulta clínica de la lista de pacientes con herramientas de filtrado por ubicación, prioridad, médico responsable, entre otros

30 Permitir generar el Informe de Alta Médico.

31 Permitir generar el Informe de Alta de



41


Enfermería

Gestión de Historias Clínicas

1 El sistema debe gestionar el expediente de todos los pacientes, independientemente de la Unidad ejecutora donde sea atendido.

2 El sistema debe poder general la historia del paciente a partir de las diferentes actos y servicios de salud que se gestionan dentro del sistema de un paciente.

3 Los diferentes operadores solamente podrán acceder el expediente de un paciente dentro del sistema si tienen algún acto o actividad a desarrollar con el paciente, adicionalmente solo podrán acceder la parte del expediente a la que por su actividad tiene que acceder.

4 El sistema debe poder generar la historia del paciente a partir de las diferentes actos y servicios de salud que se gestionan dentro de la actividad asistencial de un paciente.

5 El expediente del paciente debe poderse conformar tantos por datos personales, como historial clínico, familiar, entre otros.

6 Permitir la gestión de la Base de Datos de Pacientes Única.

7 Permitir la visualización de información distribuida del paciente, independientemente del centro en el que se presta la asistencia.

8 Permitir la gestión de traslados entre centros.

9 Continuidad asistencial. Permitir la gestión de procesos entre centros de consulta externa y hospitalización.

10 Contar con vistas, interfaz, formularios e informes parametrizable por centro / servicio.

11 Permitir el acceso de consulta a todos los episodios clínicos de los diferentes ámbitos (cuidados primarios, consultas externas, urgencias, hospitalización, hospital día, quirófanos).

Estación de Consulta Externa

1 El sistema deberá presentar la historia clínica electrónica de acuerdo con la estructura definida para el ámbito y con las preferencias del profesional.

2 Deberá permitir el registro de constantes, consulta del histórico de constantes de forma numérica y gráfica.

3 Deberá permitir el registro y notificación de



42


enfermedades de declaración obligatoria.

4 Deberá permitir el registro de cuestionarios de Exploración.

5 Deberá permitir la generación e histórico de Informes clínicos.

6 Deberá permitir el registro de la hoja de valoración integral que permite en la primera visita del episodio registrar toda la información relevante para el mismo.

7 Permitir el registro de visitas de revisiones.

8 Deberá permitir la generación de peticiones de pruebas diagnósticas, Petición de Interconsulta, órdenes para enfermería, Petición de derivaciones, entre otras.

9 Deberá permitir la gestión de cuidados de enfermería. Planes de cuidados, curas y vendajes. Valoraciones por patrones funcionales.

10 Deberá permitir la generación de la hoja de Incapacidad temporal y adjuntar a la historia clínica la misma, incluyendo el motivo y su duración.

11 El sistema debe permitir al médico tratante o demás médicos, según sea el caso, registrar, consultar, verificar, ampliar o complementar mediante formatos o formularios específicos donde se presenten detalladamente los campos de información tanto opcionales como obligatorios, incluso imprimir la información (según privilegios).

12 El sistema debe permitir el uso de escalas, estándares internacionales, tanto a nivel cuantitativo, cualitativo o gráfico, según sea el caso y por especialidad.

13 Permite dar seguimiento a las referencias y contra referencias.

14 Permite al médico registrar la solicitud de receta médica así como hacer consulta de interacciones medicamentosas.

15 Debe permitir incorporar documentos originados por otras aplicaciones al expediente clínico electrónico.

16 Permite agregar protocolos clínicos y guías de actuación

Registro de Diagnósticos y/o Procedimientos

1 Para el registro de un paciente debe existir un



43


campo para: Diagnóstico principal y/o Procedimiento.

2 Para el registro de un paciente debe existir un campo para: Diagnóstico de ingreso.

3 Para el registro de un paciente debe existir un campo para: Diagnóstico de egreso.

4 Para el registro de un paciente deben existir al menos 8 campos para: diagnósticos secundarios

Gestión de Farmacia

1 El sistema debe permitir definir, modificar o eliminar medicamentos usando para ello la ficha de medicamento.

2 El sistema debe poder manejar los principios activos del medicamento.

3 El sistema debe poder manejar los Grupos terapéuticos

4 El sistema debe gestionar las Interacciones con otros medicamentos.

5 El sistema debe gestionar las Incompatibilidades entre medicamentos.

6 Debe poder gestionar las Formas farmacéuticas.

7 Debe poder gestionar los Protocolos de medicación.

8 Debe permitir la recepción y validación de prescripciones médicas.

9 Debe permitir el registro de información farmacológica adicional de los productos.

10 Debe permitir la generación de carros de dispensación.

11 Debe permitir la generación de itinerarios.

12 Debe permitir el registro de Salida y entrada de carros.

13 Debe permitir la gestión de devolución de medicamentos.

14 Debe permitir la gestión Grupos de medicamentos y tipos de alergias.

15 Deberá ser multi-almacén y estar completamente integrado con la administración de pacientes.

16 Emitir un reporte de consumo de medicamentos, (Recetas surtidas, Recetas parcialmente surtidas, Recetas Pendientes



44


por surtir).

17 Permitir definir ejercicios fiscales y todos los movimientos será imputado a un ejercicio fiscal siempre.

18 Definir una estructura jerárquica para clasificar los fármacos de, al menos, tres niveles.

19 Ser posible trabajar tanto con genéricos como con marcas comerciales

20 Utilizar códigos de barras.

21 Permitir el registro de los laboratorios que fabrican los fármacos.

22 El sistema deberá contemplar los campos básicos que están determinados en los Catálogos y Cuadros Básicos Oficiales de medicamentos y material de curación.

23 Deberá contener en la ficha de los fármacos, al menos, la siguiente información:

1. Si es marca comercial

2. El genérico al que equivale

3. Principios activos que contiene

4. Grupo Terapéutico al que pertenece

5. Forma de presentación (gotas, cápsulas, pomada, entre otras)

6. Vía de administración preferente

7. Si es un mórfico o psicotrópico

8. Partida presupuestaria a la que pertenece

9. Si se va a utilizar control de lotes y caducidad

10. La forma de almacenamiento que requiere (normal, en cámara frigorífica, entre otras)

11. Almacenes donde se ubica con expresión de sus valores de stock mínimo, máximo y punto de pedido en dicho almacén

24 Permitir registrar todas las entradas de fármacos a los almacenes.

25 Permitir el registro de salida de fármacos.

26 Ser posible registrar traspasos de fármacos entre diferentes almacenes.

27 Permitir el registro y gestión de préstamos



45


entre diferentes centros.

28 Para todos los movimientos de fármacos, tanto de entrada como de salida, el sistema permitirá emitir contra recibos y órdenes de trabajo con rutas optimizadas para colocar o recoger los fármacos de su ubicación.

29 Debe constar de las funcionalidades necesarias para registrar las órdenes médicas de prescripción de medicación a pacientes. Estas órdenes médicas podrán provenir de los módulos clínicos de la solución propuesta o puede ser registrado desde el mismo módulo de Farmacia.

30 Calcular a partir de las órdenes médicas, las dosis necesarias para cada paciente en función de las pautas de tratamiento (Unidosis y Multidosis).

31 Ser posible generar las hojas de medicación por central de enfermera como documento soporte para la administración de la medicación.

32 Deberá estar perfectamente interconectado con la gestión de pacientes para evitar el enviar medicación a un paciente egresado.

33 Existir reportes suficientes para explotar la información de Farmacia con posibilidad de aplicar diferentes filtros y condiciones de consulta.

34 Debe de disponer de un reporte de existencias por almacenes.

35 Debe de disponer de un reporte de necesidades o bajo mínimos.

36 Debe de disponer de un reporte de consumos.

37 Debe de disponer de un reporte Kardex de entradas y salidas por medicamento y rango de fechas.

38 Debe de disponer de un reporte de escaso y nulo movimiento.

39 Debe de disponer de un reporte de próximos a caducar, según el parámetro de número de meses a caducar.

40 Debe disponer de un reporte de existencias y consumos por programa (prioritarios, VIH, entre otras).

41 Gestionar de diferentes tipos de inventarios, incluyendo inventarios valorados por precio



46


de compra o precio medio, con posibilidad de actualizar existencias.

42 Llevar el control de ajustes de inventario.

43 Administrar medicamentos por lote y fecha de caducidad.

44 Configurar puntos de reorden por medicamento.

45 Alertar cuando un medicamento ya esté por terminarse de acuerdo a una previa configuración de inventarios mínimos y puntos de reorden.

46 Configurar la semaforización de caducidad de los insumos, de acuerdo a un rango de fechas

Solicitudes de Materiales, Medicamentos y Servicios

1 Solicitar a los diferentes servicios materiales, medicamentos y estudios al ingreso y durante su estancia del paciente.

2 Realizar devoluciones o cancelaciones de los materiales, medicamentos y suministros que no se utilizaron en la cuenta del paciente.

3 Reportar todas las solicitudes que estén pendientes de confirmar configurable de todos los servicios a la cuenta del paciente por piso y general.

4 Las solicitudes de materiales, medicamentos y servicios clínicos se confirman para su seguimiento dentro del sistema una vez realizadas.

5 No permitir facturar a un paciente si está pendiente una solicitud de surtido.

6 Posibilidad de realizar modificaciones, devoluciones o cancelaciones de los materiales, medicamentos y suministros que no utilizaron, directamente por la enfermera de piso, personal de Suministros y/o médico que la originó, o con autorización por el propio servicio clínico que la recibió.

7 Posibilidad de cambiar un paquete asignado, generando sólo las solicitudes faltantes al servicio correspondiente y/o cancelando automáticamente las solicitudes generadas y generando nuevas solicitudes .

8 Permitir que el usuario registre los distintos tipos de prescripciones que serán: Dieta, Nutrición enteral, Nutrición parenteral, Fármacos, Sueros, Sondas o drenajes,



47


Aerosol, Cuidados, Constantes.

9 Distinguir entre la persona que ordena la prescripción (prescriptor) y la persona que registra la prescripción, controladas dichas actuaciones a través de permisos.

10 Permitir la validación diaria de prescripciones con el objeto de asegurar la continuidad de las mismas y la confirmación del facultativo. Permitir la configuración de esta funcionalidad para que la validación sea manual o automática.

11 Permitir la estructuración de perfiles de prescripciones, de tal manera que varias prescripciones se puedan agrupar dentro de un perfil concreto a modo de protocolo. De esta forma se podrá prescribir el perfil entero agilizando el proceso.

12 Permitir la modificación y eliminación de prescripciones es decir los cambios en las prescripciones previamente realizadas e interrupciones, tanto temporales como totales.

13 Contar con la funcionalidad de control de alergias medicamentosas.

14 Permitir acceder al módulo de prescripciones desde la asistencia médica, central de enfermeras, historia clínica y área quirúrgica, para crear una nueva prescripción o consultar las prescripciones existentes.

15 Contar con la funcionalidad de prescripción de dietas de cocina para efectuar la selección y los campos para establecer el comienzo y fin de la prescripción.

16 Permitir registrar datos clínicos justificativos de su petición, composición de la dieta, opciones de nutrición parenteral y pauta de administración.

17 Permitir la búsqueda de medicamentos por principio activo, nombres genéricos o marcas comerciales y determinar dosis, unidades y tipo de pauta.

18 Permitir seleccionar la fecha de inicio y finalización de la prescripción, para el caso en emergencias y hospitalización.

19 Permitir la selección de una sonda o drenaje para prescripción del paciente.

20 Permitir la dosificación del oxigeno expresado en porcentaje o en litros por minuto. Indicando los días exactos en que



48


empieza y termina la prescripción.

21 Permitir detallar los cuidados específicos que deben ser aplicados al paciente especificando el comienzo y fin, en fechas concretas o plazos determinados.

22 Contar con prescripciones de constantes clínicas y perfiles estandarizados.

23 Para el caso de Consulta Externa, se deberá emitir la receta médica.

24 Mostrar en pantalla las indicaciones médicas, contraindicaciones, efectos adversos, entre otras, de los medicamentos prescritos y que estos sean impresos en la receta médica.

25 Permitir determinar a qué servicio va destinada la petición de servicio: Laboratorio, Microbiología, Diagnóstico por imágenes, Anatomía Patológica, Inter consultas, Técnicas especiales.

26 Solicitudes a laboratorio: Contar con un seleccionador de pruebas cuya estructura sea en forma de árbol (Catálogo de pruebas) el cual deberá contar con dos grupos de elementos: perfiles de pruebas y pruebas.

27 Al solicitar pruebas de anatomía patológica, el sistema deberá registrar los siguientes datos: Servicio, Profesional, Prioridad, Fecha de toma, Datos clínicos, Muestras seleccionadas, Datos del paciente, Nombre, Ámbito (hospitalización, consulta externa, emergencias), Episodio.

28 Permitir realizar la petición mediante los siguientes criterios: Prioridad (normal, preferente, urgente e inmediata), Fecha de cita propuesta, Servicio solicitante, Localización del paciente, Profesional, Datos clínicos, Diagnóstico de presunción, Comentarios, Pruebas solicitadas.

29 Permitir que un profesional realice una consulta especial de forma interna a otro facultativo.

30 Permitir realizar una petición a laboratorio general o microbiología a varios pacientes de forma simultánea y en cualquiera de los servicios (consulta externa, hospitalización, emergencias o pacientes ambulatorios).

31 Permitir consultar los resultados de las peticiones de servicios de un paciente en concreto en un determinado servicio.



49


32 Permitir conocer el estado de una petición de servicio bajo los siguientes criterios: Pendiente, Resultado sin lectura, Resultado con lectura.

33 Contar con una pantalla de detalles que permita consultar los resultados de estudios de una petición de forma más precisa.

34 Contar con una funcionalidad de estadísticas de laboratorio.

35 El sistema debe de disponer de la posibilidad de definir perfiles de estudios que engloben a varias tipologías de estudios.

36 El sistema debe de disponer de una herramienta que permita controlar los pacientes que están pendientes de obtención de muestra.

37 El sistema debe de ser capaz de emitir etiquetas para las muestras de los pacientes para su correcta identificación y envío a los servicios de apoyo

Gestión de Nutrición

1 El sistema debe registrar y gestionar todos los aspectos relativos a las dietas asignadas.

2 Debe manejar la evaluación y prescripción de dietas.

3 Permitir la definición de dietas y platos.

4 El sistema debe tener una herramienta para definir los ingredientes, platos y menús, de tal manera que puedan ser combinado s o reutilizados dependiendo de su aporte calórico o por los ingredientes que los compone.

5 Se debe poder tener una tabla de definición de ingredientes.

6 Se debe tener un módulo de definición de platos.

7 Se debe tener un módulo de definición de menús con las diferentes configuraciones mensuales para todos los días, indicando las alternativas de platos a combinar.

8 Se debe poder definir el número y descripción de comidas al día, como su horario de entrega.

9 El sistema debe de permitir asignar las dietas a los pacientes.

10 El sistema debe proporcionar un mecanismo



50


de selección de menús dependiendo del tipo de paciente y dieta asignada.

11 El sistema debe permitir la prescripción de dietas condicionadas.

12 El sistema debe permitir generar las ordenes de trabajo en la cocina, a partir de todos los platos prescritos a los pacientes y el horario del día.

13 Se debe poder registrar los platos despachados que se sube por paciente

Gestión de Cuidados de Enfermería

1 Permitir la utilización de protocolos normalizados de enfermería NANDA para los diagnósticos de Enfermería.

2 Permitir la utilización de protocolos normalizados de enfermería NIC para las intervenciones de Enfermería.

3 Permitir la utilización de protocolos normalizados de enfermería NOC para la clasificación de resultados de Enfermería.

4 Gestión de los planes de cuidados:

1. El sistema deberá aportar una herramienta que identifique las 5 diferentes fases en el proceso de cuidados enfermeros como sigue: Valoración, Planificación de Cuidados, Ejecución del Plan de Cuidados, Evaluación e Informe de Continuidad de Cuidados.

2. Deberá permitir aplicar los procesos e información de cuidados enfermeros a los episodios de Hospitalización, Emergencias, Consulta Externas y Atención Primaria.

3. Deberá manejar el flujo de los procesos de Cuidados Enfermeros considerando primero la Valoración del paciente, seguida de la Planificación de Planes de Cuidados y su posterior Evaluación.

4. Una vez realizada la Evaluación: Deberá permitir volver a la Planificación para modificar alguno de los Diagnósticos o Actividades que forman el Plan de Cuidados.

5. Una vez que el paciente está preparado para el alta: Deberá permitir la emisión del Informe de



51


Continuidad de Cuidados si el enfermero lo estima conveniente o porque alguno de los problemas no hayan finalizado.

6. Una vez dado de alta el paciente: Deberá permitir bloquear el conjunto de datos recogido a lo largo de todo el proceso (expediente de enfermería (sábana de enfermería)) y deberá almacenarlos para su consulta junto con el episodio del paciente.

7. Deberá permitir la asociación de cada paso del Proceso de Cuidados Enfermeros a un sistema de codificación determinado con el fin de facilitar al máximo las tareas de creación de planes de cuidados, modificación, consulta, automatización de tareas, entre otras.

Para la Hoja de Valoración:

1. Permitir la recogida de los datos de valoración resultados de la entrevista al paciente, la exploración física y fuentes indirectas (familiar o profesional responsable en atención primaria).

2. Contar con un formulario específico donde se recoja la información de valoración del paciente basado en las necesidades humanas básicas de Virginia Henderson, en los patrones funcionales de salud de Marjory Gordon y/o el que el INSTITUTO determine.

3. Permitir la creación y/o modificación de nuevos formularios de valoración del paciente de acuerdo a las necesidades del INSTITUTO.

5 Plan de Cuidados Estándar (PCE):

1. Permitir la configuración de problemas estándar que puedan presentar los pacientes con un determinado problema de salud.

2. Permitir la planificación de las actividades cuidadoras destinadas a resolver un determinado problema de salud.

3. Permitir la realización completa o parcial del plan de cuidados al



52


paciente.

4. Permitir la configuración de un conjunto de diagnósticos o problemas enfermeros y actividades de colaboración.

5. Permitir la configuración de la duración de cada actividad con URV (Unidad Relativa de Valor).

6. Permitir la configuración de las Intervenciones y las actividades de acuerdo a la clasificación internacional NIC.

7. Permitir la configuración de la URV del plan completo mediante la sumatoria de las URV de las actividades que lo componen

Plan de Cuidados Individual (PCI):

1. Permitir la configuración de problemas concretos a un determinado paciente seleccionado.

2. Permitir la planificación de actividades concretas a un determinado paciente seleccionado.

3. Permitir la asignación manual del Plan de Cuidados personalizado para un paciente en concreto.

4. Permitir la asignación automática del plan de cuidados personalizado si no se asigna ningún PCE.

5. Permitir a la enfermera cargar un PCE cuando el paciente presente una serie de problemas que puedan ser mejorados o solucionados con alguno de los Planes de Cuidados Estándar definidos. Por ejemplo, si el paciente tiene un ACV (Accidente Cerebro – Vascular), el enfermero/a cargará el PCE de ACV para ese paciente.

6. Permitir a la enfermera cargar un Plan de Cuidados Estándar, desde una lista de PCE creados.

7. Permitir a la enfermara seleccionar todos los problemas y actividades del PCE o solamente los que presente el paciente actual.

8. Permitir almacenar el PCE o PCI asignado a los pacientes.



53


9. Permitir la consulta del PCE o PCI asignado a los pacientes.

10. Permitir la consulta del número de pacientes con PCE o PCI asignados.

11. Permitir la consulta del número de pacientes con un PCE o PCI determinado

6 Gestión de Agenda de Tareas

1. Deberá permitir la consulta de las tareas pendientes (de distinta naturaleza) organizadas según distintos patrones.

2. Deberá mostrar directamente la agenda de tareas planificadas para el turno actual.

3. Deberá mostrar la agenda de tareas planificadas por algún intervalo de tiempo (día completo, días previos, días posteriores, entre otras) indicando la hora de comienzo y finalización.

4. Deberá permitir la consulta de las agendas de tareas por usuario que realiza la conexión como de todos los usuarios implicados.

5. Deberá mostrar de forma adicional la información relativa a la ejecución de las tareas (tarea realizada, pospuesta, cancelada, entre otras).

6. Deberá mostrar la fecha y hora exacta de cuándo fue realizada y la persona que la realizó la tarea consultada

Manejo de Archivo

1 El sistema debe permitir la consulta de los movimientos realizados en la historia clínica física de los pacientes.

2 Debe permitir la fusión de la historia clínica física y electrónica de los pacientes.

3 Debe permitir el registro de historias asociadas a su correspondiente carpeta.

4 Debe permitir la gestión de solicitudes recibidas de la historias clínica física de los pacientes.

5 Debe permitir la gestión de préstamos y devoluciones de la historia clínica física.

6 Debe permitir la generación de listados



54


(Historias clínicas no devueltas, tiempo de devolución, exitus, entre otras).

7 Debe permitir la gestión de cambios de archivo.

8 Debe permitir la gestión de traspasos de episodios.

9 Debe permitir la Impresión de etiquetas identificadoras

Gestión de Costos y Facturación de la Actividad Asistencial

1 El sistema debe tener la capacidad de definir centro de costos por servicio.

2 El sistema debe manejar autorizaciones por servicio.

3 El sistema debe poder manejar convenios de servicios con terceros .

4 El sistema de poder manejar diferentes tipos de tarifas por convenio.

5 El sistema debe manejar niveles de cobertura por convenio.

6 El sistema debe poder manejar costos por paquetes.

7 El sistema debe poder generar facturas por paciente, para Instituciones de Salud.

8 El sistema debe tener la capacidad de gestionar los pagos a servicios y profesionales contratados.

9 El sistema debe tener la capacidad de integrarse a Sistemas de ERP con sus módulos de contabilidad, Inventario, Cuentas por Cobrar, mediante emisión de pólizas contables

Inteligencia de Negocios Gestión Médica

1 El sistema de deberá permitir la explotación de información asistencial y administrativa a partir de los datos registrados en todos y cada uno de los módulos, sub módulos o subsistemas que conformen el Sistema; así como la capacidad de extraer de otros sistemas informáticos del INSTITUTO.

2 Permitir acceso interactivo y en tiempo real a la información almacenada en las bases de datos.

3 Permitir la agrupación, transformación y presentación de la información almacenada en la base de datos.



55


4 Proporcionar una única arquitectura para el análisis de los datos y generar informes.

5 Deberá contar con funcionalidades de análisis in situ, de análisis de indicadores, de métricas de cuadro de mando y de explotación analítica.

6 Permitir la impresión de informes.

7 Permitir guardar archivos en formatos electrónicos y medios digitales.

8 El sistema debe tener la capacidad de explotar información del paciente en visita de primera vez o si es visita de seguimiento.

9 Permitir la emisión de informes de estancia hospitalaria por servicios y días de estancia por servicio, así como transferencias.

10 Al generar los reportes en Bioestadística, separa los pacientes internos de los externos.

11 Al generar los reportes en Bioestadística, separa los pacientes generados por estación específica, rango de fechas, nombre del médico.

12 Debe permitir la generación de reportes de actividad por Diagnósticos.

13 Debe permitir la generación de reportes de defunciones por Servicio y Diagnóstico.

14 Deberá permitir la generación de reportes de consultas por tiempo.

15 Deberá permitir la generación de reportes de consultas por Profesional Médico.

16 Deberá permitir la generación de reportes de consultas por servicio.

17 Deberá permitir la generación de reportes de consultas de pacientes por centro.

18 Deberá permitir añadir información adicional a los informes establecidos.

19 Deberá permitir añadir nuevos informes al catálogo de informes.

20 Deberá de contener informe de Hospitalización: Pacientes por años, meses y días.

21 Deberá de contener informe de Hospitalización: Pacientes por turnos.

22 Deberá de contener informe de Hospitalización: Pacientes por profesionales.



56


23 Deberá de contener informe de Hospitalización: Pacientes por especialidades.

24 Deberá de contener informe de Hospitalización: Ingresos derivados a cirugía.

25 Deberá de contener informe de Hospitalización: Altas por Edad y Sexo.

26 Deberá de contener informe de Hospitalización: Altas por Procedencia geográfica.

27 Deberá de contener informe de Hospitalización: Procedencias de los ingresos.

28 Deberá de contener informe de Hospitalización: Destino de las altas.

29 Deberá de contener informe de Hospitalización: Número de éxitus.

30 Deberá de contener informe de Hospitalización: Estancias de pacientes por profesional y especialidad.

31 Deberá de contener informes de Quirófano: Intervenciones por Quirófano.

32 Deberá de contener informes de Quirófano: Intervenciones por Especialidad.

33 Deberá de contener informes de Quirófano: Intervenciones por Profesional.

34 Deberá de contener informes de Quirófano: Intervenciones por diagnóstico CIE.

35 Deberá de contener informes de Quirófano: Intervenciones por año, meses, días y turnos.

36 Deberá de contener informes de Quirófano: Gráficas entre quirófanos.

37 Deberá contar con el informe de Consultas Externas: Consultas por Especialidad.

38 Deberá contar con el informe de Consultas Externas: Consultas por Profesional médico.

39 Deberá contar con el informe de Consultas Externas: Consultas por Edad, Sexo.

40 Deberá contar con el informe de Consultas Externas: Consulta por procedencia geográfica.

41 Deberá contar con el informe de Consultas Externas: Consultas por años, meses, días y turnos.



57


42 Deberá contar con el informe de Consultas Externas: Origen de citas y solicitante.

43 Deberá contar con el informe de Consultas Externas: Pacientes no presentados.

44 Deberá contar con el informe de Consultas Externas: Pacientes atendidos y no atendidos.

45 Deberá contar con el informe de Consultas Externas: Tiempos de atención y espera.

46 Deberá contar con el informe de Consultas Externas: Evolución de las listas de espera.

47 Deberá contar con el informe de Consultas Externas: Porcentaje de ocupación de agendas.

48 Deberá contar con los siguientes informes Administrativos:

49 Deberá contar con el informe administrativo: Facturación por servicio.

50 Deberá contar con el informe administrativo: Facturación por Profesional médico.

51 Deberá contar con el informe administrativo: Facturación por centro de costo.

52 Deberá contar con el informe administrativo: Facturaciones pendientes de cobro por pagador.

53 Deberá contar con el informe administrativo: Registros de cobros y retrasos.

54 Deberá contar con el informe de los Servicios Auxiliares de diagnóstico: Tipos de pruebas realizadas, pruebas más frecuentes, entre otras.

55 Deberá contar con el informes de los Servicios Auxiliares de diagnóstico: Influencia de cada una de las pruebas de cada profesional, cantidades y porcentajes.

56 Deberá contar con el informes de los Servicios Auxiliares de diagnóstico: Procedencia de las peticiones: qué profesionales / servicios generan las peticiones de laboratorio



58


9.7 REQUERIMIENTOS DE HARDWARE QUE CUBRA ADQUISICIÓN, INSTALACIÓN Y PUESTA A

PUNTO DE LA INFRAESTRUCTURA, EQUIPO DE CÓMPUTO Y DE COMUNICACIONES

HARDWARE

DESCRIPCIÓN CANTIDAD

UNIDAD DE

MEDIDA

Cumple: Si o No

1 SERVIDOR DE RACK PARA BASE DE DATOS CARACTERÍSTICAS: - Chasis para Rack con capacidad de alojar hasta 16

discos duros de 2.5‖ y procesadores Intel o su equivalente.

- 1 Procesador Intel® Xeon® E5-2670 2.60GHz, 20M Cache, 8.0GT/s QPI, Turbo, 8C o su equivalente.

- Chipset Intel C602 o su equivalente. - Memoria mínima de 128 GB en módulos de 16x8GB

1866 Mhz expandible como mínimo hasta 768 GB de memoria sin sustitución.

- Dual Ranked RDIMMs para 1 procesador - Bios actualizable (flash) vía dispositivo externo, CD

ROM y red remota, de la misma marca del servidor ofertado.

- Tarjeta Controladora de RAID que soporte al menos los siguientes niveles de RAID (1) y con al menos 512 Mb de caché de escritura.

- Los discos deberán venir configurados en RAID 1. - 1X16 Backplane, para Discos Duros SAS de 2.5‖ - 2 discos duros de 300 GB de capacidad cada uno,

velocidad de 15k rpm, Serial-Attach SCSI 6Gbps de 2.5‖, con tecnología hot-plug o hot-swap.

- Unidad DVD-ROM SATA booteable interno. - 1 Tarjeta de 2 puertos 10 GbE - Puertos de comunicación como mínimo: 4 puertos USB

2.0 o superior, 1 puerto de video, todos integrados a la tarjeta madre, sin tarjetas adicionales, sin conectores de extensión. Al menos 2 puertos USB 2.0 o superior y 1 puerto de video al frente del equipo para acceso inmediato.

- Capacidad de gestión y administración remota del servidor mediante software y hardware desarrollado y soportado por el mismo fabricante del servidor ofertado, instalado o integrado en la tarjeta madre que permita el acceso a red con puerto dedicado exclusivo a 1 Gb o serie y compatible con IPMI 2.0

- Administración remota de los servidores que admita la redirección de la consola gráfica, de serie y de medios virtuales con la posibilidad de realizar operaciones como la actualización del BIOS, el firmware, los controladores de dispositivo del sistema y la instalación de aplicaciones desde una ubicación remota como si el

2 EQUIPO



59


usuario se encontrara delante del sistema. Asimismo, admita una pantalla de vídeo continuo incluso durante el reinicio con capacidad de reproducir video de eventos de arranque (boot) o en caso de falla; y la integración con Active Directory

- La herramienta de administración deberá tener la capacidad de integrarse a Microsoft System Center, VMware Center o su equivalente con el objeto de estandarizar la plataforma de administración

- Ranuras de expansión seis totales antes de configurar: al menos 4 ranuras x8 PCI-Express o superiores, 1 ranuras x16 PCI-Express o superiores.

- Bahías internas de discos antes de configurar para soportar 16 discos duros SAS hot-plug.

- Bahía óptica ocupada por el dispositivo óptico. - Tarjeta de red Quad port 10/100/1000 ethernet

interconstruida, con conector RJ45. - Ventiladores hot plug o hot swap redundantes. - Fuentes de poder redundantes de 750 W eficiencia

Titanium o equivalente que mínimo soporten la configuración del servidor, incluir 2 cables nema 5-15p.

- Manuales técnicos y de usuario originales impresos o en CD.

- Soporte a sistemas operativos: Windows Server DataCenter 2012

- Software de administración, desarrollado y soportado por el mismo fabricante del servidor ofertado, que permita monitorear y diagnosticar el sistema desde una consola, con notificación de alertas mediante texto.

- Chasis de altura máxima de 2U, listo para montaje en Rack de 19‖, incluir Rieles para Rack.

-

2 SERVIDOR DE RACK PARA GRANJA DE SERVIDORES CARACTERÍSTICAS: - Chasis para Rack con capacidad de alojar hasta 16



- Chipset Intel C602 o su equivalente. - Memoria mínima de 32 GB en módulos de 16x2GB 1866

Mhz expandible como mínimo hasta 768 GB de memoria sin sustitución.





10 EQUIPO



60






- Administración remota de los servidores que admita la redirección de la consola gráfica, de serie y de medios virtuales con la posibilidad de realizar operaciones como la actualización del BIOS, el firmware, los controladores de dispositivo del sistema y la instalación de aplicaciones desde una ubicación remota como si el usuario se encontrara delante del sistema. Asimismo, admita una pantalla de vídeo continuo incluso durante el reinicio con capacidad de reproducir video de eventos de arranque (boot) o en caso de falla; y la integración con Active Directory






Titanium o equivalente que mínimo soporten la configuración del servidor, incluir 2 cables nema 5-15p.

- Manuales técnicos y de usuario originales impresos o en CD.






61


3 SERVIDOR DE RACK PARA INTEGRACIÓN CARACTERÍSTICAS: - Chasis para Rack con capacidad de alojar hasta 16
















2 EQUIPO



62





Titanium o equivalente que mínimo soporten la configuración del servidor, incluir 2 cables nema 5-15p Manuales técnicos y de usuario originales impresos o en CD.




4 SERVIDOR DE RACK PARA BI CARACTERÍSTICAS: - Chasis para Rack con capacidad de alojar hasta 16



- Chipset Intel C602 y/o superior o su equivalente. - Memoria mínima de 8 GB en módulos de 8x1GB 1600









- Capacidad de gestión y administración remota del servidor mediante software y hardware desarrollado y soportado por el mismo fabricante del servidor ofertado, instalado o integrado en la tarjeta madre que permita el

1 EQUIPO



63


acceso a red con puerto dedicado exclusivo a 1 Gb o serie y compatible con IPMI 2.0











5 SERVIDOR DE RACK PARA APLICACIONES CARACTERÍSTICAS: - Chasis para Rack con capacidad de alojar hasta 16







2 EQUIPO



64















- Soporte a sistemas operativos: Windows Server DataCenter 2012 o su equivalente.

- Software de administración, desarrollado y soportado por el mismo fabricante del servidor ofertado, que



65


permita monitorear y diagnosticar el sistema desde una consola, con notificación de alertas mediante texto.


6 SERVIDOR DE RACK PARA ENTORNO PREPODUCCIÓN Y CAPACITACIÓN CARACTERÍSTICAS: - Chasis para Rack con capacidad de alojar hasta 16














- La herramienta de administración deberá tener la

2 EQUIPO



66


capacidad de integrarse a Microsoft System Center, VMware Center o su equivalente con el objeto de estandarizar la plataforma de administración




















2.0 o superior, 1 puerto de video, todos integrados a la tarjeta madre, sin tarjetas adicionales, sin conectores de

4 EQUIPO



67


extensión. Al menos 2 puertos USB 2.0 o superior y 1 puerto de video al frente del equipo para acceso inmediato.














- 1 Procesador Intel® Xeon® E5-2670 2.60GHz, 20M

2 EQUIPO



68


Cache, 8.0GT/s QPI, Turbo, 8C o su equivalente. - Chipset Intel C602 o su equivalente. - Memoria mínima de 32 GB en módulos de 16x2GB 1866















interconstruida, con conector RJ45. - Ventiladores hot plug o hot swap redundantes.



69


- Fuentes de poder redundantes de 750 W eficiencia Titanium o equivalente que mínimo soporten la configuración del servidor, incluir 2 cables nema 5-15p Manuales técnicos y de usuario originales impresos o en CD.




9 GABINETE PARA RACK DE 42 UNIDADES. Características: - Capacidad de carga de hasta 2500 lbs. - Altura: 78.7‖ (1998 mm) - Ancho: 23.8‖ (605 mm) - Profundidad:42.1 (1070 mm) - Incluir todos sus accesorios.

2 PIEZA

10 El almacenamiento deberá soportar en su arquitectura los siguientes tipos de discos: - SATA de 7,200 RPM. - NL-SAS de 7,200 RPM. - FC de 10 KRPM y 15 KRPM. - SAS de 10 KRPM y 15 KRPM. - SSD – Sata Solid Disk -Deberá de incluir 2 controladoras redundantes. -64 GB de memoria caché por controladora. - Deberá contar con 101 TB usables distribuidos de la siguiente manera: - 2 TB en discos de SSD - 29 TB en discos de SAS de 1.2 TB @ 10 KRPM - 70 TB en discos de NL-SAS de 4 TB @ 7.2 KRPM -La memoria cache debe contar con un mecanismo de protección de los datos en caso de Falla en la alimentación eléctrica y deberá estar basado en tecnología flash. - El sistema de almacenamiento propuesto deberá tener la capacidad de escalabilidad al menos de 960 discos de almacenamiento dentro de la misma familia. -Medida de optimización de espacio como solución del centro de datos, el almacenamiento deberá soportar 12 y 24 discos por enclosure.. -Deberá soportar interfaces FC, FCoE, 1 Gbe y 10 GbE . -Deberá de soportar protocolos FC, iSCSI y NAS. -Puertos RJ45 para la administración. -Deberá ser instalado un rack de 42 U. -El almacenamiento debe tener la capacidad de mover dinámica e inteligentemente los datos entre diferentes tecnologías de discos, basándose en frecuencia de acceso, es decir aquellos datos que ya no son utilizados en un periodo de tiempo (configurable) se han movidos hacía otro disco de menor desempeño, dejando la capacidad de los

1 EQUIPO



70


discos de alto desempeño para los datos que son generados y utilizados día a día. -Deberá soportar como mínimo los siguientes sistemas operativos Windows , Solaris, HP-UX, Linux, IBM AIX,Novell NetWare y VMware. -Incluir el licenciamiento necesario para poder realizar copias internas PIT (Point in time), aprovisionamiento dinámico. -Incluir el software y licenciamiento para Load Balancing and Fai!-over sobre las conexiones de los servidores requeridos en estas bases y futuras adiciones de servidores a la SAN. -La administración deberá ser a través de una interface de tipo WEB y un software propietario que podrá ser instalado en cualquier equipo que la convocante indique. -Se deberá de incluir el software para administración y monitoreo que permita realizar reportes del consumo del almacenamiento, optimizar la capacidad a través de reportes de tendencias y alertas sobre el uso del I / 0, monitoreo en la replicación asíncrona y síncrona, utilización en el ancho de banda y creación de copias PIT. -El software y licenciamiento será propiedad de la dependencia y deberá ser re-utilizado cuando se realice la actualización a los controladores, operando en un esquema de licenciamiento perpetuo. -El licenciamiento para todo el software del almacenamiento deberá ser para toda la capacidad requerida en estas bases y los crecimientos futuros. -El almacenamiento deberá de tener integración con software para ambientes virtuales. -Se deberá incluir todo el equipo de comunicación necesario de acuerdo a las interfaces que la solución de almacenamiento contenga en arreglo, garantizando una alta disponibilidad y redundancia. -Instalación física de los equipos, configuración y puesta a punto. -Garantía de 3 años en sitio en todos sus componentes con atención de 7 x 24 con 4 horas de tiempo de respuesta.

11 Switch para conexión equipos -Conmutador ToR de 1 U, alta densidad -48 Puertos 1/10 Gb Base T -4 puertos 10/40 QSFP+ -Flujo de aire reversible de la parte frontal a la parte trasera y viceversa -Conmutación Ethernet L2 y L3 escalable con QoS -Grupos de agregado de 128 enlaces hasta con 8 miembros por grupo, que usan hash avanzado -Deberá incluir todo lo necesario para montaje en Rack de 19‖, incluir Rieles para Rack.

4 EQUIPO

12 Enclosure para rack que incluye: -Deberá incluir los módulos de conector de 10 GbE necesarios para el requerimiento del proyecto. -Puertos de Administración -9 Módulos de ventiladores redundantes de conexión en

1 EQUIPO



71


marcha -4 Fuentes de Poder -1 Licenciamiento para administración y control -Deberá incluir panel de control frontal con LCD gráfica interactiva.

13 Equipos Blade Server para la implementación de SAP que incluye: -4 Procesadores Intel Intel Xeon E5-4650 2.70 GHz, 20M Cache, 8.0GT/s QPI, Turbo, 8 Core, 130W o su equivalente. -Chipset Intel C600 o su equivalente. - Memoria mínima de 1024 GB en módulos de 32x32GB 1600 Mhz expandible como mínimo hasta 3 TB de memoria sin sustitución. - Adaptador Ethernet 10 Gb de dos puertos - 4 Discos de 300 GB 15 KRPM configurados en RAID 10 Incluye instalación, configuración y puesta a punto.

8 EQUIPO

14 UPS PARA RACK. Características: - NIVEL DE POTENCIA: 12 kW /15 kVA - RESPALDO: A media Carga 5 minutos, Carga

Completa 15 minutos. - Aplicación de administración compatible con Windows. - Deberá incluir panel de control multifunción LCD

- Puertos de control y administración DB-9 RS-232, RJ-45

10/100 Base-T, Smart-Slot

- Listo para montaje en Rack de 19‖, incluir Rieles para

Rack.

- Incluye instalación física del equipo, configuración y

puesta a punto.

4 EQUIPO

10. DISPOSICIONES ESPECIALES

10.1 El INTERESADO deberá describir en su propuesta el uso de mejores prácticas internacionales relacionadas con los siguientes aspectos:

a. Mejores Prácticas del Expediente Clínico b. Mejores Prácticas en materia de información en salud c. Mejores Prácticas de Expediente Clínico Electrónico.

10.2 El INTERESADO deberá describir en su propuesta el uso de estándares, códigos y protocolos

internacionales relacionados con los siguientes aspectos:

a. Estándares internacionales de comunicación y manejo de información de salud Health Level Seven (HL7).

b. Estandar Internacional para el intercambio de imágenes Médicas. Digital Imaging and Communication in Medicine (DICOM).



72


c. Codificación Internacional de Procedimientos CIE-9. d. Codificación Internacional de Enfermedades CIE-10. e. Codificación Internacional de Diagnósticos de Enfermería

10.3 Entregables

El INTERESADO deberá presentar una relación de entregables de la Gestión Administrativa de los Recursos Gubernamentales (GRP) o su equivalente, así como la de la Gestión Médica según el requerimiento funcional descrito en el punto anterior.

10.4 Consideraciones Especiales

10.4.1 Lugar de Trabajo

El desarrollo del proyecto se llevará a cabo en las oficinas del “INSTITUTO” en la Ciudad Capital de Guatemala, o en algún lugar alterno pero ubicado también dentro de la Ciudad Capital de Guatemala. EL “INSTITUTO” proporcionará un área de trabajo para el desarrollo de este proyecto.

10.4.2 Gastos de Viaje

De acuerdo a la premisa anterior la propuesta del INTERESADO deberá incluir los viáticos para

el personal que este designe.

10.4.3 Infraestructura y equipamiento necesario

EL “INSTITUTO” será responsable de brindar, instalar, administrar y operar todos los componentes de software, hardware y comunicaciones necesarios para el correcto funcionamiento de los componentes ofertados en esta manifestación de interés a ofertar, de manera enunciativa más no limitativa deberá considerar: licencias del Sistema Operativo, Base de Datos, antivirus, servicios de internet, cableado, servicios de comunicación, redes, fuentes de poder, requeridos para la operación y buen funcionamiento de la propuesta del INTERESADO. EL “INSTITUTO” será el responsable de proveer toda la infraestructura y componentes necesarios para tener alta disponibilidad y sitios alternos de recuperación de desastres.

EL “INSTITUTO” será responsable de brindar, instalar, administrar y operar todo el hardware e infraestructura tecnológica de todos los centros de trabajo descritos en el alcance de la propuesta del INTERESADO.

10.5 Las especificaciones técnicas del bien ofertado deberán ser iguales o superiores a las requeridas

en este documento.

10.6 El INTERESADO deberá incluir en su propuesta, el plan de capacitación, el cual incluirá la nómina de los cursos, el programa sintético de cada uno y la duración, en horas o la cantidad de horas recomendada por el fabricante.

10.7 Los cursos serán impartidos en el centro de capacitación propuesto por el ―INSTITUTO”, por instructores certificados y los mismos estarán relacionados directamente con los bienes ofertados, debiendo contener un balance entre teoría y ejercicios prácticos, que proporcionen el conocimiento adecuado para configurar, administrar, monitorear y mantener en operación los bienes adquiridos.



73


10.8 El INTERESADO deberá manifestar el periodo de garantía y descripción de la misma, que ofrecerá sobre los productos entregados, el cual no podrá ser menor a 18 meses.

10.9 El INTERESADO deberá indicar en su propuesta que entregará las actualizaciones de los productos ofertados durante la implementación de la solución.

10.10 Se requiere del INTERESADO que entregue y/o ponga a disposición del ―INSTITUTO” los códigos fuente, para realizar futuras modificaciones acorde a las necesidades de la institución. Estos deberán ser entregados el finalizar el Proyecto.

10.11 El Contratista deberá presentar al momento de la implementación del proyecto, y bajo una metodología de implementación de proyectos avalada por el fabricante que deberá contener al menos lo siguiente:

a. Preparación inicial b. Análisis y Diseño c. Ejecución o Construcción d. Preparación final e. Liberación

10.12 Los productos ofertados deberán ser entregados bajo la modalidad ―Llave en Mano‖, es decir,

que todos los elementos necesarios para que los bienes ofertados funcionen correctamente y para que provean los servicios requeridos.

10.13 En las especificaciones técnicas, las palabras ―capacidad‖, ―contar‖ y/o similares, significa que el INTERESADO deberá contemplar la provisión, inclusión y/o disponibilidad, de las características a las que se hace alusión, a efecto de cumplir con las Especificaciones Técnicas mínimas requeridas.

10.14 La Institución pondrá a disposición del Contratista los medios físicos (hardware), a efecto de que se efectué con viabilidad la implementación, instalación, e implementación de los productos requeridos, con excepción de los equipos que sean requeridos en el apartado de Equipos y Suministros por parte del INTERESADO, mismos que deberán ser proveídos por el Contratista .

GLOSARIO DE TÉRMINOS

a. INSTITUTO GUATEMALTECO DE SEGURIDAD SOCIAL: Institución que en lo sucesivo será denominada “INSTITUTO”.

b. INTERESADO : Persona individual o jurídica que manifiesta su interés en participar en el presente proceso.

c. Instalación de software.- La instalación de programas computacionales (software) es el proceso

por el cuales sean los nuevos programas son transferidos a un computador con el fin de ser configurados, y preparados para ser ejecutados en el sistema informático, para cumplir la función para la cual fueron desarrollados.

d. Implementación.- Una implementación es la configuración de una aplicación informática,

realización o la ejecución de un plan, idea, modelo científico, diseño, especificación, estándar, algoritmo o política.



74


e. Hardware.- Se refiere a todas las partes tangibles de un sistema informático; sus componentes son: eléctricos, electrónicos, electromecánicos y mecánicos. Son cables, gabinetes o cajas, periféricos de todo tipo y cualquier otro elemento físico involucrado.

f. Software.- Equipamiento lógico o soporte lógico de un sistema informático, que comprende el

conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas.

g. Licenciamiento.- Es un contrato entre el licenciante (autor/titular de los derechos de

explotación/distribuidor) y el licenciatario del programa informático (usuario consumidor /usuario profesional o empresa), para utilizar el software cumpliendo una serie de términos y condiciones establecidas dentro de sus cláusulas.

h. Prototipo.- Es un modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos, Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas.

ACRÓNIMOS AIX ―Advanced Interactive Executive‖ (Sistema operativo tipo UNIX propietario de IBM) API ―Application Programming Interface‖ (Interfaz de Programación de Aplicaciones ) ASM ―Automatic Storage Management‖ (Gestión automática de espacio) BCP ―Business Continuity Planning‖ (Plan de continuidad de negocio) Base-T ―Configuración base T‖ Estándar habitualmente adoptado para los conectores RJ45 BI ―Business Inteligence‖ (Inteligencia de negocio) CIE-X ―Clasificación Internacional de Enfermedades‖ (Es el acrónimo de la Clasificación

internacional de enfermedades, versión ‖X‖ y determina la clasificación y codificación de las enfermedades y una amplia variedad de signos, síntomas, hallazgos anormales, denuncias, circunstancias sociales y causas externas de daños y/o enfermedad).

CORE ―Procesador‖ Unidades física de procesamiento de datos CPT ―Current Procedural Terminology‖ (Se utiliza para comunicar los datos y las prácticas médicas,

incluyendo la información del paciente como los síntomas, diagnósticos, enfermedades, lesiones,

tratamientos y procedimientos médicos.) CPU ―Central Processing Unit‖ (Unidad Central de Proceso) DAS ―Direct Attached Storage‖ (Almacenamiento directo ligado) DDNS ―Dynamic Domain Naming Service‖ (Servicio de Dominio de Nombres Dinámico) DDR ―Double Data Rate‖ (Doble tasa de transferencia de datos) DICOM ―Digital Imaging and Communication in Medicine‖ (Es el estándar reconocido mundialmente

para el intercambio de pruebas médicas, pensado para su manejo, visualización, almacenamiento, impresión y transmisión.) DHCP ―Dynamic Host Configuration Prtocol‖ (Protocolo de Configuración Dinámica de Host) DIMM ―Double In-Line Memory Module‖ (Módulo de Memoria En Línea Apareado) DNS ―Domain Naming Service‖ (Servicio de Dominio de Nombres) DRP ―Disaster Recovery Plan‖ (Plan de Contingencia o de Recuperación ante Desastres) DRS ―Dynamic Resource Scheduling‖ (Programación Dinámica de Recursos) DSA ―Directory Service Agent‖ (Agente de Servicios de Directorios) DVD ―Digital Video Disk / Digital Versatile Disk‖ (Disco Versátil Digital / Disco de Video Digital) EAI ―Enterprise Application Integration‖ (Es el uso de software y principios de arquitectura de sistemas para integrar un conjunto de aplicaciones, dentro de cualquier empresa). E/S ―Input/Output‖ Entrada/Salida ECC ―Error-Correcting Code‖ (Corrección de Errores de Código) EPIC ―Electronic Privacy Information Center‖ (Centro de información electrónico privado) ETL ―Extraction Transformation Load‖ (Extracción transformación carga) FC ―Fibre Channel‖ (Canal de Fibra)

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Aplicaci%C3%B3n_inform%C3%A1tica



75


FCoE ―Fibre Channer over Ethernet‖ Canal de Fibra sobre Ethernet FTP ―File Transfer Protocol‖ (Protocolo de Transferencia de Archivos) GB ―Gigabyte‖ (Gigabyte) Gb ―Gigabit‖ (Gigabit) Gbps ―GigaBits Per Second‖ (Gigabits Por Segundo) Ghz ―Gigahertz‖ (Giga hertzio) GUI ―Graphic User Interface‖ (Interfaz gráfica de usuario) HA ―High Avaibility‖ (Alta disponibilidad) HL7 ―Health Level Seven‖ (Salud Nivel 7, por su nombre en inglés, es la Organización

internacional generadora de estándares de interoperabilidad para informática médica. Es una organización desarrolladora de estándares certificada por ANSI (American National Standards Institute)).

HSM ―Hardware Security Module‖ (Módulo de seguridad de hardware) HTML ―HyperText Markup Language‖ Lenguaje de Marcado para Hipertextos HTTP ―HyperText Transfer Protocol‖ (Protocolo para transferencia de hipertexto) HTTPS ―Hyper Text Transfer Protocol Secure‖ (Protocolo seguro de transferencia de hipertexto ) HW ―Hardware‖ (Hardware) Hz ―Hertz‖ (Hertzio) I/O ―Input/Output‖ (Entrada/Salida) IMAP ―Internet Message Access Protocol‖ (Protocolo de acceso a mensajes internet) IO ―Input/Output‖ (Entrada/Salida) IOPS ―Input/Output Processors‖ (Procesadores de Entrada/Salida) iSCSI ―Small Computers System Interface‖ (Interfaz de sistema para pequeñas computadoras) KVM ―Kernel-based Virtual Machine‖ Máquina virtual basada en el núcleo LAN ―Local Area Network‖ (Red de área local) LDAP ―Lightweight Directory Access Protocol‖ (Protocolo de acceso a directorios livianos) LIS ―Laboratory Information System‖ (Es un software modular, basado en laboratorio. Gestiona la

información y ofrece un conjunto de características clave que apoyan un moderno laboratorio). Mbps ―Megabits per second‖ (Megabits por segundo) Mhz ―Megahertz‖ (Mega hertzio) NANDA ―North American Nursing Diagnosis Association‖ (Es el estándar de codificación para el

diagnóstico de enfermería, su objetivo es desarrollar, mejorar y promover la terminología que refleje con precisión el juicio clínico emitido en enfermería para mejorar todos los aspectos de la

práctica de la misma.) NAS ―Network Attached Storage‖ Almacenamiento de Red NFS ―Network File System‖ (Sistema de archivos de red) NIC ―Network Interface Card‖ (Tarjeta de interfaz de red) NIC ―Nursing Interventions Classification‖ (Es una lengua comprensiva, estandarizada que describe

los tratamientos que las enfermeras realizan en todas las especialidades) NIS ―Network Infomation Service‖ (Servicio de información de red ) NL-SAS ―Near Line SAS‖ Interface Adjunta Serial SCSI NOC ―Nursing Outcomes Classification‖ (Esta clasificación es resultado de una investigación

desarrollada en la University of Iowa College of Nursing desde 1991 y que sigue actualmente desarrollándose. Ordena y clasifica los Resultados sensibles a las intervenciones de la enfermera, permitiendo evaluar la calidad de los cuidados proporcionados y medir los resultados obtenidos en los pacientes influenciados por los cuidados enfermeros)

NTP ―Network Time Protocol‖ (Protocolo de tiempo de red) OEM ―Original Equipment Manufacturer‖ (Fabricante de equipamiento original) OS ―Operating System‖ (Sistema operativo) PACS ―Picture Archiving and Communication System‖ (Sistema de archivo y transmisión de imágenes

médicas que maneja y administra imágenes, dentro del cual están la distribución y diagnóstico de estudios radiológicos)

PCIe ―Personal Computer Interface‖ (Interfaz para computadora personal) PDU ―Protocol Data Unit / Power Distributions Units‖ (Unidad de datos de protocolo)/ (Unidades de

distribución de energía)

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3DLaboratory%2BInformation%2BSystem%2B%28LIS%29%26noj%3D1%26biw%3D939%26bih%3D609&rurl=translate.google.com.mx&sl=en&u=http://en.wikipedia.org/wiki/Software&usg=ALkJrhiqF_EMCjaz1RY3suUr2q6oQRZy8A

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3DLaboratory%2BInformation%2BSystem%2B%28LIS%29%26noj%3D1%26biw%3D939%26bih%3D609&rurl=translate.google.com.mx&sl=en&u=http://en.wikipedia.org/wiki/Laboratory&usg=ALkJrhjc0lttfdYxFgHj-gQ484815gTCzg



76


QA ―Quality Assurance‖ Aseguramiento de calidad RAID ―Redundant Array of Independent Disks‖ (Matriz redundante de discos independientes) RAM ―Random Access Memory‖ (Memoria de acceso aleatorio) RIS ―Radiological Information System El Sistema de Información Radiológica que va asociado a

PACS es un sistema de gestión de información, enfocado completamente a la administración del flujo de trabajo que mejora la productividad, eficiencia y el manejo de información en ambientes de radiología e imagen‖

ROM ―Read Only Memory‖ (Memoria sólo de lectura) RPM ―Revolutions per minute‖ (Revoluciones por minuto) SAN ―Storage Area Network‖ (Red de área de almacenamiento) SAS ―Serial Attached SCSI‖ (Interface Adjunta Serial SCSI) SATA ―Serial ATA‖ (Serial ATA) SCSI ―Small Computer System Interface‖ (Interfaz de sistema para pequeñas computadoras) SE ―Standard Edition‖ (Edición estándar) SOAP ―Simple Object Access Protocol‖ (Es un protocolo estándar que define cómo dos objetos en

diferentes procesos pueden comunicarse por medio de intercambio de datos XML.) SSD ―Solid-State Drive‖ (Unidad de estado sólido) SW ―Software‖ (Software) TB ―Terabyte‖ (Terabyte) TI ―Information Technologys‖ (Tecnologías de la información) TIER ―nivel de fiabilidad‖ nivel de fiabilidad Triage ―Triaje (del francés triage‖ (Es un método de la medicina de emergencias y desastres para la

selección y clasificación de los pacientes basándose en las prioridades de atención, privilegiando la posibilidad de supervivencia, de acuerdo a las necesidades terapéuticas y los recursos disponibles)

U ―U de Rack‖ Medida estándar de rack UDDI ―Universal Description, Discovery and Integration‖ (Es una iniciativa industrial abierta entroncada

en el contexto de los servicios Web). UPS ―Uninterruptible Power Supply‖ (Fuente de poder ininterrumpida) USB ―Universal Serial Bus‖ (Bus serial universal) WAN ―Wide Area Network‖ Red de Área Amplia WSDL ―Web Services Description Language‖ (Es un formato XML que se utiliza para describir

servicios Web.) WS-I ―Web Services Interoperability Organization‖ (Fomenta y promover la Interoperabilidad de

Servicios Web sobre cualquier plataforma, sobre aplicaciones y sobre lenguajes de programación.)

http://es.wikipedia.org/wiki/Protocolo_(inform%C3%A1tica)

http://es.wikipedia.org/wiki/Norma_(tecnolog%C3%ADa)

http://es.wikipedia.org/wiki/XML

http://es.wikipedia.org/wiki/Idioma_franc%C3%A9s

http://es.wikipedia.org/wiki/Medicina_de_emergencias_y_desastres

http://es.wikipedia.org/wiki/Servicios_Web

http://es.wikipedia.org/wiki/XML

http://es.wikipedia.org/wiki/Servicios_Web

REQUISITOS Y DEMÁS CONDICIONES QUE DEBEN TOMAR EN … · la contratación de lo requerido y...

Documents

Transcript of REQUISITOS Y DEMÁS CONDICIONES QUE DEBEN TOMAR EN … · la contratación de lo requerido y...