Solicitud de información RFI para Servicios Tecnológicos y de Información para Hospitales

SOLICITUD DE INFORMACIÓN (RFI)

Servicios Tecnológicos y de Información para Hospitales

COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN

Agosto de 2018

Página 1 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

TABLA DE CONTENIDO

INTRODUCCIÓN. ................................................................................................... 8 1.

CRONOGRAMA. .............................................................................................. 9 1.1. Plan de Trabajo. ......................................................................................... 9 1.2. Forma de Presentación. ........................................................................... 10

2.

OBJETO. ........................................................................................................ 10

3.

CONDICIONES TÉCNICAS. .......................................................................... 10 3.1. Especificaciones técnicas de la solución...................................................11 3.2. Condiciones de Entrega del servicio. ........................................................11 3.3. Garantía Técnica ...................................................................................... 12 3.4. Soporte Técnico. ...................................................................................... 12 3.4.1. Plan de Contingencia y continuidad del servicio. ............................... 13

4.

RIESGOS. ...................................................................................................... 14 4.1. Metodología. ............................................................................................ 14 4.2. Riesgos preliminares. ............................................................................... 15

ANEXOS. .............................................................................................................. 19 Anexo 1. Carta de Presentación. ...................................................................... 19 Anexo 2. Formato de experiencia previa. .......................................................... 21 Anexo 3. Requerimientos Técnicos. .................................................................. 22 A3.1. Funcionalidad Generales de la Solución ............................................... 22 A3.2. Funcionalidad Requerida Módulos Administrativos y Financieros ........ 22 A3.2.1. Contabilidad. .................................................................................. 23 A3.2.2. Tesorería. ....................................................................................... 24 A3.2.3. Cuentas por Pagar. ........................................................................ 27 A3.2.4. Cartera. .......................................................................................... 29 A3.2.5. Glosas. ........................................................................................... 31 A3.2.6. Anticipos y Abonos. ........................................................................ 32 A3.2.7. Presupuesto Contable. ................................................................... 33 A3.2.8. Terceros.......................................................................................... 35 A3.2.9. Activos Fijos. .................................................................................. 37 Página 2 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

A3.2.10. Facturación................................................................................... 39 A3.2.11. Agendas Médico-Asistenciales. .................................................... 43 A3.2.12. Admisiones. .................................................................................. 44 A3.2.13. Suministros................................................................................... 48 A3.2.14. Nómina. ........................................................................................ 55 A3.2.15. Costos. ......................................................................................... 58 A3.2.16. Funcionalidad Adicional Opcional: Recursos Humanos y Contratación Servicios. ............................................................................... 60 A3.3. Funcionalidad Requerida Módulos Clínico Asistenciales HIS ............... 62 A3.3.1. Admisión del paciente. ................................................................... 62 A3.3.2. Agenda Médica............................................................................... 63 A3.3.3. Historia Clínica Médica. .................................................................. 65 A3.3.4. Urgencias. ...................................................................................... 69 A3.3.5. Historia Clínica Enfermería............................................................. 71 A3.3.6. Gestión de unidades quirúrgicas. ................................................... 73 A3.3.7. Resultados de Laboratorio ............................................................. 74 A3.3.8. Imágenes diagnósticas ................................................................... 75 A3.3.9. Órdenes médicas ........................................................................... 76 A3.3.10. Gestión de relación médico-paciente ........................................... 77 A3.3.11. Seguimiento de Pacientes ............................................................ 77 A3.3.12. Pacientes y gestión de camas, Referencia y contra–referencia ... 78 A3.3.13. Instrucciones de alta .................................................................... 80 A3.3.14. Registro de alergias y reacciones adversas ................................. 80 A3.3.15. Gestión de Medicamentos ............................................................ 81 A3.3.16. Odontología .................................................................................. 83 A3.3.17. Nutrición y Dietas ......................................................................... 85 A3.3.18. Promoción y Prevención .............................................................. 86 A3.3.19. Epidemiología............................................................................... 87 A3.3.20. Gestión de información de Territorios ........................................... 87 A3.3.21. Gestión de seguridad del paciente ............................................... 88 A3.3.22. Auditoría ....................................................................................... 88 A3.3.23. Generación Plantillas ................................................................... 89 A3.3.24. Gestión documental ..................................................................... 89 Página 3 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

A3.3.25. Sistemas Auxiliares LIS, RIS, PHIS .............................................. 90 A3.4. Funcionalidades Requeridas para la Operación General del Sistema .. 90 A3.4.1. Control de Acceso .......................................................................... 90 A3.4.2. Seguridad de acceso ...................................................................... 91 A3.4.3. Usabilidad y Movilidad .................................................................... 92 A3.4.4. Presentación .................................................................................. 92 A3.4.5. Búsqueda ....................................................................................... 93 A3.4.6. Base de Datos ................................................................................ 93 A3.4.7. Respaldo de Datos ......................................................................... 94 A3.4.8. Conexión a la Base de Datos ......................................................... 94 A3.4.9. Integración - Estándares ................................................................ 95 A3.4.10. Integración – Arquitectura de Integración ..................................... 95 A3.4.11. Comunicación, interacción de servicios de integración ................ 96 A3.4.12. Procesamiento de mensajes ........................................................ 97 A3.4.13. Calidad de servicio ....................................................................... 97 A3.4.14. Seguridad y administración en interoperabilidad .......................... 98 A3.4.15. Gobernabilidad ............................................................................. 99 A3.4.16. Seguridad de la Información......................................................... 99 A3.4.17. Confidencialidad, integridad y disponibilidad .............................. 100 A3.4.18. Autenticación .............................................................................. 101 A3.4.19. Autorización ................................................................................ 101 A3.4.20. Auditoría general del Sistema..................................................... 102 A3.4.21. Firma electrónica ........................................................................ 103 A3.5. Requerimientos Generarles de Implementación y operación del Sistema ..................................................................................................................... 103 A3.5.1. Del Datacenter ............................................................................. 103 A3.5.2. De Conectividad ........................................................................... 104 A3.5.3. De Mesa de Ayuda ....................................................................... 105 A3.5.4. Para la Implementación y puesta en servicio ............................... 106 A3.5.4. Para la Operación del Sistema ..................................................... 107 A3.6. Funcionalidad requerida interoperabilidad HIS - HCEU ...................... 108 FUNCIONALIDAD REQUERIDA INTEROPERABILIDAD HIS – HCEU .............. 109 CDA Epicrisis Urgencias .................................................................................. 109 Página 4 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

Sección 1: Datos IPS...................................................................................110 Sección 2: Tipo de servicio y documento ......................................................110 Fecha y hora de generación de epicrisis: ......................................................110 Sección 5: Diagnósticos ................................................................................ 111 Sección 6: Motivo de consulta de Urgencias ................................................. 111 Sección 7: Revisión por Sistemas ................................................................. 111 Sección 8: Antecedentes ............................................................................... 111 Sección 9: Examen Físico ............................................................................. 111 Piel y anexos: ................................................................................................112 Sección 10: Evolución Clínica del paciente ...................................................112 Sección 11: Ayudas diagnósticas (Paraclínicos e imágenes) ........................112 Sección 12: Plan tratamiento urgencias (Farmacológico, quirúrgico, terapia respiratoria, terapia física o cualquier otra indicación Médica) ......................112 Listado de los tratamientos farmacológicos, quirúrgicos, terapéutico o indicaciones Médicas realizadas en el Servicio de Urgencias que debe contener código único de medicamentos vigentes CUMS con dosis, frecuencia y duración del tratamiento, Códigos CUPS de los procedimientos realizados indicando la cantidad y duración de los mismos, descripción de las indicaciones Médicas ordenadas durante la Hospitalización. .......................112 Sección 13: Plan tratamiento egreso, Ordenes Médicas. (Farmacológico, quirúrgico, terapia respiratoria, terapia física o cualquier otra indicación Médica) .........................................................................................................112 Sección 14: Condición egreso .......................................................................112 Sección 15: Medico que elaboró la Epicrisis .................................................112 CDA Epicrisis Hospitalización ...........................................................................113 Sección 3: Datos de identificación básica (Directiva 022 de 2011 y Decreto 062 de 2014) .................................................................................................113 Sección 6: Motivo de consulta de Urgencias .................................................114 Sección 7: Revisión por Sistemas .................................................................114 Ginecológicos: formula obstétrica, Menarquía, Fecha ultima menstruación, Planificación (si o no), Método de planificación, Vida sexual activa (si o no), ultima citología fecha, resultados ultima citología, Menopausia. ...................114 Sección 9: Examen Físico .............................................................................114 Sección 10: Evolución Clínica del paciente ...................................................115 Sección 11: Ayudas diagnósticas (Paraclínicos e imágenes) ........................115 Página 5 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

Sección 12: Plan tratamiento Hospitalización (Farmacológico, quirúrgico, terapia respiratoria, terapia física o cualquier otra indicación Médica) ..........115 Sección 13: Plan tratamiento egreso, Ordenes Médicas. (Farmacológico, quirúrgico, terapia respiratoria, terapia física o cualquier otra indicación Médica) .........................................................................................................115 Sección 14: Condición egreso .......................................................................115 Sección 15: Medico que elaboró la Epicrisis .................................................115 CDA Consulta Externa ......................................................................................116 Sección 1: Datos IPS ....................................................................................116 Sección 2: Datos de la atención y documento ..............................................116 Sección 3: Datos Médico...............................................................................116 Sección 4: Datos de identificación básica (Decreto 062 de 2014) ................116 EPS: ..............................................................................................................116 Sección 6: Motivo de Consulta ......................................................................117 Sección 7: Revisión por Sistemas .................................................................117 Sección 8: Antecedentes ...............................................................................117 Ginecológicos: formula obstétrica, Menarquía, Fecha ultima menstruación, Planificación (si o no), Método de planificación, Vida sexual activa (si o no), ultima citología fecha, resultados ultima citología, Menopausia. ..................117 Sección 9: Examen Físico .............................................................................117 Sección 10: Diagnósticos ..............................................................................118 Sección 11: Análisis.......................................................................................118 Sección 12: Plan o tratamiento .....................................................................118 Sección 13: Ordenes Médicas ......................................................................118 Otros: ............................................................................................................118 CDA SIVIGILA Nacional ....................................................................................118 CDA SIVIGILA ................................................................................................. 120 Sección 1: Información General ................................................................... 120 Sección 2: Identificación del Paciente .......................................................... 120 Sección 3: Notificación ................................................................................. 120 CDA HCMP Historia Clínica Materna Perinatal ................................................ 121 Sección 1: Datos IPS ................................................................................... 121 Sección 2: Datos de la atención y documento ............................................. 121 Sección 3: Datos Médico.............................................................................. 121 Página 6 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

Sección 4: Identificación gestante ................................................................ 121 Parentesco: .................................................................................................. 122 Sección 5: Motivo de Consulta ..................................................................... 122 Sección 6: Revisión por sistemas ................................................................ 122 Sección 7: Antecedentes .............................................................................. 122 Sección 8: Examen Físico ............................................................................ 124 Sección 9: Resultados Laboratorio .............................................................. 124 Sección 10: Imagenología ............................................................................ 124 Resultados de ecografías y demás ayudas diagnosticas de imágenes. ...... 124 Sección 11: Análisis...................................................................................... 124 Análisis del caso de la gestante. .................................................................. 124 Sección 12: Impresión diagnóstica ............................................................... 124 Sección 13: Plan o tratamiento .................................................................... 124 Sección 14: Ordenes Médicas ..................................................................... 124

Página 7 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

INTRODUCCIÓN. En general, las Empresas Sociales del Estado del país, enfrentan grandes retos que se originan en el modelo planteado por la Ley 100 de 1993, que migró de subsidios (los hospitales recibían dinero del Estado para prestar sus servicios) a la oferta de sus servicios (la demanda de servicios requerida por las Empresas Prestadoras de Servicios (EPS), principalmente del régimen subsidiado). Así las cosas, las Empresas Sociales del Estado, se vieron abocados a competir con los prestadores de servicios privados de salud, ocasionando que aquellas de más baja complejidad sean las más afectadas en este nuevo escenario.

Adicional a la competencia con el sector privado, las bajas en la productividad de las empresas sociales del estado, tienen impacto directo en las finanzas de estas organizaciones.

En cuanto a las tecnologías, temas como la tecnología biomédica propia de los procesos asistenciales o las tecnologías de información y comunicación (TIC), que cada vez tiene mayor participación en los procesos productivos del sector salud, no están siendo utilizados por las empresas sociales del estado debido a la escasez de recursos que puedan invertir en tecnología e innovación. Al respecto, se dispone de poca información de carácter formal con relación a la implementación de las TIC en las Instituciones Prestadoras de Salud (IPS) de Colombia, especialmente en lo referido a los sistemas de gestión hospitalaria (HIS en inglés) y sistemas de gestión de recursos empresariales (ERP en inglés).

Finalmente, los cambios en los esquemas de atención impulsados por el Ministerio de Salud y Protección Social en los años recientes, a través del Modelo Integral de Atención en Salud (MIAS), obligan a las Empresas Sociales del Estado, y demás instituciones de servicios prestadoras de salud, a pertenecer a las Redes Integrales de Prestación de Servicios de Salud (RIPSS) organizadas por las Empresas Prestadoras del Estado (EPS). En consecuencia, es un requisito esencial para conformar y pertenecer a una RIPSS el disponer de información confiable, oportuna y que se pueda compartir vía estándares de interoperabilidad.

Todo lo anterior implica para Empresas Sociales del Estado, y demás instituciones de servicios prestadoras de salud, modernizar sus sistemas HIS y ERP para tenerlos a tono con las nuevas condiciones del entorno. Esta situación se constituye en una oportunidad para La Cooperativa de Hospitales de Antioquia - COHAN, de construir una oferta de valor a partir de servicios tecnológicos, de información y de gestión para las Empresas Sociales del Estado, y demás instituciones de servicios prestadoras de salud de Antioquia y de otras regiones, para lo que se hace necesario realizar una investigación de mercado que permita recolectar información sobre las condiciones actuales de la oferta de servicios y productos de Página 8 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

potenciales proveedores de sistemas HIS y de ERP que existen en el mercado.

El presente documento de solicitud de información (Request for Information, RFI por sus siglas en inglés) forma parte de la investigación de mercado que viene adelantando LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN, acerca de los potenciales proveedores de soluciones HIS y ERP existentes en el mercado que podrían atender las necesidades de las Empresas Sociales del Estado, y demás instituciones de servicios prestadoras de salud.

Este RFI está dirigido a los proveedores que han tenido experiencia en el suministro de software, capacitación, implantación, evolución y soporte de herramientas informáticas para soluciones que apoyen los procesos de gestión hospitalaria y sistemas de gestión de recursos empresariales en las Empresas Sociales del Estado, y demás instituciones de servicios prestadoras de salud a nivel nacional.

1. OBJETO DEL RFI. Solicitar información necesaria para la investigación de mercado que viene adelantando La Cooperativa de Hospitales de Antioquia - COHAN acerca de los potenciales proveedores de soluciones existentes en el mercado que podrían atender las necesidades de las Empresas Sociales del Estado, y demás instituciones de servicios prestadoras de salud, especialmente en lo referido a los sistemas de gestión hospitalaria (HIS en inglés) y sistemas de gestión de recursos empresariales (ERP en inglés).

El resultado de este proceso podrá generar un proceso de contratación, por parte de la Cooperativa de Hospitales de Antioquia - Cohan, de servicios tecnológicos de información y gestión que pueda ser utilizado por las Empresas Sociales del Estado, y demás instituciones de servicios prestadoras de salud.

2. CRONOGRAMA. 2.1.

Plan de Trabajo.

A continuación, se describen las actividades y fechas en las que se debe realizar el proceso de RFI. Actividad

Fechas Inicio Fin 13/08/2018 03/09/2018 13/08/2018 27/08/2018

Publicación de RFI Fecha máxima para realizar preguntas Reunión socialización de 27/08/2018 respuestas/solución a inquietudes Página 9 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

27/08/2018

Actividad

Fechas

Inicio Fecha y hora límite para el envío de 03/09/2018 respuestas al RFI 10:00 a.m.

Fin 03/09/2018 4:00 p.m.

La dirección electrónica para el envío de las solicitudes de aclaración y la respuesta a cada uno de los puntos contenidos en este documento (respuesta a los RFI) es: petic@cohan.org.co, y el correo electrónico debe ser enviado bajo el asunto RFI Servicios Tecnológicos - nombre de la empresa que envía.

2.2.

Forma de Presentación.

Los interesados deben responder al requerimiento de información de acuerdo con la siguiente estructura: 1. Índice.

2. Carta de presentación del interesado (Anexo 1).

3. Descripción de la solución que puede presentar (arquitectura, tecnologías y servicios involucrados) 4. Respuesta a cada uno de los Requerimientos de Información del capítulo 4 del documento del RFI. 5. Estimación de los costos y gastos en que debe incurrir la Cooperativa.

6. Estimación de los tiempos requeridos para la implementación y puesta en funcionamiento de la plataforma, incluyendo las restricciones que deban tenerse en cuenta (Capítulo 4 en el documento del RFI).

7. Descripción de riesgos adicionales a los establecidos en el documento del RFI (Capítulo 4 en el documento del RFI).

8. Experiencia en contratos similares para lo cual debe utilizar el formato contenido en el Anexo 2.

La respuesta del interesado debe estar contenida en un archivo electrónico compatible con las siguientes aplicaciones: Microsoft Word, Excel, PowerPoint, WinZip y Acrobat Reader. Si el archivo está en formato PDF no debe tener restricción de impresión ni de extracción de contenido para facilitar el análisis de la información recibida.

3. OBJETO DE LA EVENTUAL CONTRATACIÓN. Contratar servicios en la nube que permitan prestar servicios tecnológicos de información y de gestión (HIS/ERP) de las Empresas Sociales del Estado, y demás instituciones de servicios prestadoras de salud, de tal manera que se disponga de información confiable, oportuna que se pueda compartir vía estándares de interoperabilidad, como requisito esencial para conformar y pertenecer a las RIPSS Página 10 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

(Redes Integrales de Prestadores de Servicios de Salud).

4. CONDICIONES TÉCNICAS DE LA EVENTUAL CONTRATACIÓN. La solución que se plantee, para la prestación de los servicios solicitados, deberá cumplir con cada uno de los aspectos descritos en este capítulo; para ello deberá describir, en forma clara y concisa, la manera como los resuelve.

4.1.

Especificaciones técnicas de la solución.

El Anexo 3, Requerimientos Técnicos, incluye cada una de las condiciones funcionales/no funcionales que debe cubrir la solución que se oferte; el interesado deberá diligenciar el formato en cuestión indicando si cada criterio funcional está cubierto por su solución y describiendo, en forma clara y concisa, la manera como lo hará.

En el análisis de las respuestas entregadas sólo se tendrán en cuenta aquellas que se entreguen en los formatos establecidos en el Anexo 3; cualquier información entregada en un esquema diferente no será objeto de revisión.

4.2.

Condiciones de Entrega del servicio.

El interesado debe indicar el tiempo que se tomará la implementación total de la solución en días calendario, contados a partir de la suscripción del correspondiente contrato1; así mismo, deberá indicar el tiempo que se tomaría la implementación de la solución en las Empresas Sociales del Estado y demás instituciones de servicios prestadoras de salud que hagan uso de la misma de acuerdo con la siguiente tabla:

Nro. Equipos de cómputo Hasta 10 11-30 31-50 > 50

Condiciones de la Institución Nro. Usuarios Nro. Usuarios en simultáneos por la la Institución Institución Hasta 10 10 Hasta 60 30 Hasta 100 50 Hasta 200 Hasta 100

Tiempo Implementación

En la eventual contratación que surja, el interesado deberá tener en cuenta al momento de la entrega final, para cada Empresa Social del Estado y/o institución de prestador de servicios de salud que hagan uso de la solución, y al momento en 1 Hace referencia al contrato que pudiera suscribirse entre una Institución Prestadora de Salud que quiera hacer uso del software con-

tratado por la Cooperativa de Hospitales de Antioquia – COHAN. Página 11 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

que entre a operar con la solución deberá estar acompañada del correspondiente informe en el que se incluya la descripción de la solución entregada y los documentos soporte.

Así mismo, en la implementación de cada servicio deberá ejecutarse o coordinarse la realización de protocolos de prueba que permitan garantizar su operación apropiada en las condiciones propias de la institución. Estas pruebas deberán contar con el acompañamiento del personal del interesado, no tendrán costo adicional para LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN y deberán arrojar como resultado el funcionamiento óptimo de los servicios contratados de acuerdo con los protocolos que se definan por las partes.

4.3.

Garantía Técnica

En la eventual contratación que surja, el interesado deberá tener en cuenta para la Garantía Técnica lo siguiente: Dada la modalidad de uso del software como servicio, el interesado seleccionado se compromete a que éste opere correctamente en las premisas propias del cliente durante el período que éste haga uso de aquél.

Para delimitar las responsabilidades de la garantía en cuestión, se deberá levantar un acta al momento de entrar en operación (una vez finalice la implementación del servicio en cada institución) en la que se indiquen las condiciones propias en que el servicio estará operando, describiendo los componentes que serán responsabilidad de cada una de las partes. Para garantizar la prestación del servicio el interesado deberá considerar: 1) En caso de no poder atender cualquier requerimiento por medios virtuales, deberá hacer presencia en sitio sin que este desplazamiento represente costos adicionales para LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN o el cliente que requiera de su presencia.

2) El software que se suministre deberá mantenerse actualizado en el cumplimento de los requisitos/exigencias de Ley o cualquier normatividad emitida por entes regulatorios del Sector Salud o aquél que le aplique.

4.4.

Soporte Técnico.

En la eventual contratación que surja, el interesado deberá tener en cuenta para el Soporte Técnico lo siguiente: •

El interesado debe incluir en la oferta un soporte técnico 7x24 durante el tiempo que cada institución haga uso del software como servicio;

Página 12 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

adicionalmente, deberá especificar los procedimientos y el esquema de atención (incluyendo esquemas de escalamiento) que utilizará para atender en los tiempos establecidos en los niveles de servicio, las fallas, peticiones, quejas y reclamos que se presenten con relación a los servicios prestados y demás requerimientos presentados por los clientes y/o LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN. •

El soporte técnico deberá prestarse de manera telefónica o en línea, con niveles de escalamiento, datos de contacto y correos electrónicos. Además, debe incluir una herramienta de gestión de las incidencias para el seguimiento de los casos reportados.

•

El interesado debe indicar si, como parte de las herramientas de gestión de las incidencias, incluye soporte a través de la Web, donde se pueda: consultar manuales, actualizaciones, novedades, fallas, soporte, entre otros; así mismo, deberá asignar a LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN las cuentas de acceso acorde con su rol de supervisión y dueño del servicio.

•

El interesado deberá considerar la entrega de un informe mensual de los requerimientos atendidos en el mes inmediatamente anterior (con corte el último día de cada mes); este informe deberá entregarse en los primeros 5 días hábiles del mes y deberá incluir: 1) Un indicador de cumplimiento en la atención de los requerimientos reportados y solucionados durante el mes (total y por tipo de servicio). 2) Un indicador de los requerimientos reportados en meses anteriores y solucionados en el mes en cuestión (total y por tipo de servicio). 3) Un reporte consolidado discriminados por tipo de caso y antigüedad en la solución del requerimiento (Hasta 1 día; Hasta 5 días; Hasta 10 días; Hasta 30 días; Hasta 2 meses).

4.4.1. Plan de Contingencia y continuidad del servicio.

En la eventual contratación que surja, el interesado deberá tener en cuenta para la entrega de la solución lo siguiente: •

El interesado deberá acompañar la solución con un plan de contingencia y continuidad del servicio que será activado ante la ocurrencia de una emergencia que afecte la prestación del servicio o cuando se superen los tiempos establecidos para la atención de los Acuerdos de Niveles de Servicio descritos en este aparte.

•

Las Empresas Sociales del Estado, y demás instituciones de servicios prestadoras de salud, que hacen uso del servicio y a voluntad, podrán

Página 13 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

ejecutar las acciones del plan de continuidad ante la ocurrencia de un evento que afecte la prestación del servicio mientras el interesado atiende y encuentra la solución.

•

En el plan deberá contemplar la manera como se actualiza la información una vez el sistema entre de nuevo en servicio.

5. RIESGOS. 5.1.

Metodología.

Se trabajó con una metodología para identificar y clasificar los riesgos de acuerdo con la probabilidad de ocurrencia y el impacto del evento2. A continuación, se identifican y describen los riesgos según el tipo y la etapa de un eventual proceso de contratación en la que ocurre; posteriormente se evalúan los riesgos teniendo en cuenta su impacto y su probabilidad de ocurrencia; y finalmente, se establece un orden de prioridad teniendo en cuenta los controles propuestos y el contexto de estos.

Tabla X Matriz de riesgos IMPACTO

Numérica

PROB ABILI DAD

Insignif icante

Meno r

Moderad o

Mayor

Catastrófi co

1

2

3

4

5

Histórica

1 en 10,000 – 100,000

Puede ocurrir, pero sólo en circunstancias excepcionales

Raro

1

2

3

4

5

6

1 en 1,000 – 10,000

Podría ocurrir, pero dudoso

Improb able

2

3

4

5

6

7

1 en 100 – 1,000

Podría ocurrir en cualquier momento futuro

Posible

3

4

5

6

7

8

1 en 10 – 100

Probablemente ocurrirá

Probabl e

4

5

6

7

8

9

>1 en 10

Se espera que ocurra en la mayoría de las circunstancias

Casi Cierto

5

6

7

8

9

10

2 Tomando como base el estándar australiano para la administración de riesgos (AS/NZS 4360:1999) Página 14 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

El orden de prioridades fue establecido asignando un puntaje de acuerdo con la probabilidad de ocurrencia (raro; improbable; posible; probable; casi cierto) y de su impacto (insignificante; menor; moderado; mayor; catastrófico). Los riesgos fueron clasificados teniendo cuenta su calificación de acuerdo con Tabla x.

Tabla x Prioridad de tratamiento y control del riesgo N°

Factor de escogencia y calificación

Riesgo > 7

Riesgo Extremo: Se requiere un plan de acción detallado

6 <= Riesgo <= 7

Riesgo Alto: Se necesita una atención mayor de la administración

Riesgo = 5

Riesgo Medio: Especificar responsabilidad de la administración

Riesgo < 5

Riesgo Bajo: Administrar por procedimientos de rutina

Área: (i) internos, riesgos internos a LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN y (ii) externos, riesgos externos a LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN. Etapa: es el momento en que se puede materializar el riesgo.

Tipo: los riesgos se pueden clasificar según los siguientes tipos: (i) Financieros/Económicos: están relacionados con los cambios en los precios de las acciones y de los commodities, tasas de cambio, tasas de interés, inflación. Igualmente, está involucrado el riesgo de crédito o riesgo en la calidad de crédito de los Oferentes y el riesgo de liquidez. (ii) Operacional: está relacionado con las pérdidas potenciales que resultan de sistemas inadecuados, fallas en la administración, controles defectuosos, fraude y errores humanos. (iii) Legales/Regulatorios: están relacionados con los cambios en la legislación de salud o cuando la contraparte no tiene la autoridad legal para hacer transacciones. (iv) Negocios: están relacionados con los eventos en el mundo de la salud, tales como la incertidumbre en la demanda de servicios, el cambio en el precio de los productos, costo de producir y entregar. (v) Reputacional: está relacionado con la credibilidad del negocio.

5.2.

Riesgos preliminares.

A continuación, se describen los riesgos que LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN ha identificado, de manera preliminar, para la ejecución Página 15 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

Operacion al Operacional

Deficiencias en la calidad del trabajo realizado (v.gr. defectos en los requerimientos implementados, desvíos sobre estándares de calidad del proyecto), reprocesos y retrasos en ruta crítica.

Reprocesos, deficiencias en calidad y retrasos en ruta crítica.

Retrasos en ruta crítica en fase de implementación.

Suspensión del proyecto o retrasos en ruta crítica y sobrecostos.

Bajo desempeño del recurso humano de EL CONTRATISTA

Fallas en la infraestructura de TI de EL CONTRATISTA que impactan la disponibilidad de los recursos o la seguridad de la información.

LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN no cuente con la capacidad y disponibilidad de la infraestructura de TI (recursos técnicos y humanos) suficientes para la Implementación y operación de la Plataforma.

Operacion al

Operacional

Retrasos en el cronograma y deficiencias en la calidad del trabajo realizado por desconocimiento de las labores desarrolladas por el recurso saliente; además de posibles deficiencias en la definición y aplicación de estándares de proyecto.

Operacion al

Cambios en el equipo de trabajo de EL CONTRATISTA que no son solicitados por LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA COHAN.

Operacional

Ausencia de funcionalidades requeridas para habilitar el adecuado funcionamiento del sistema de gestión hospitalaria.

Ejecución

Identificación de nuevos Requerimientos Funcionales de la Plataforma durante las etapas de implementación y operación, que además no están cubiertas por los servicios de Actualización, Mantenimiento y Soporte.

Operacional

Funcionam iento Ejecución

Consecuencia de la ocurrencia del evento

No se cuente con mecanismos que garanticen el manejo de la información histórica de acuerdo con la legislación aplicable.

Ejecución

Ejecución

Descripción (Qué puede pasar y, si es posible, cómo puede pasar)

Ejecución

Interno Externo Externo Externo

Tipo

Ejecución

7

Etapa

Interno

Específico Específico

6

Específico

5

Específico

4

Específico

3

Áre a

Interno

2

Especifico

1

Clas e

Específico

N°

Externo

de un eventual contrato.

Identificar, en la etapa de implementación y o en la operación, que se requiere de software y/o hardware adicional.

Página 16 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

Operacional Operacional Legal

14

Ejecución

Externo

Especifico

Ejecución

13

11

Externo

Los clientes que harán uso de la plataforma no cuentan con los recursos técnicos y humanos necesarios para hacer un uso óptimo de ella

10

Especifico

12

Operacional

Suspensión temporal o definitiva de la prestación del servicio soportado por la Plataforma.

Demandas por violación de derechos de propiedad intelectual de la plataforma (software, hardware y/o licencias utilizadas en su funcionamiento)

Operacional

Deficiencias en la prestación del servicio soportado por la plataforma que pueden afectar la calidad de asistencia hospitalaria.

Ausencia y/o falta de capacitación en la ejecución de los planes de continuidad y contingencia de la Plataforma (durante la etapa de implementación y la de funcionamiento)

Funcionam iento

Retraso en ruta crítica e incumplimiento de los ANS establecidos entre LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN y los usuarios de la Plataforma.

Funcionam iento

Deficiencias en la calidad de los servicios prestados por EL CONTRATISTA que no satisfacen las necesidades de LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA COHAN; incumplimiento de las condiciones pactadas en el contrato.

Funcionam iento

Fallas o inestabilidad en la Plataforma una vez implementada (es decir, cuando esté en funcionamiento)

Incumplimiento de los ANS pactados entre LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA COHAN y EL CONTRATISTA de la Plataforma.

Incremento en los costos de operación de la Plataforma.

Afectación de los servicios prestados a las instituciones de salud a través de la Plataforma.

Externo

Consecuencia de la ocurrencia del evento

Externo

Descripción (Qué puede pasar y, si es posible, cómo puede pasar)

Externo

Operacional

Operacional

Tipo

Específico

Ejecución

Ejecución

Etapa

Específico

Externo

Externo

Áre a

Específico

9

Especifico

8

Clas e

Especifico

N°

Gestión del cambio y comunicación en los hospitales.

Pérdida o fallas en la custodia de la historia clínica y/o la información que tenga normatividad especifica

Página 17 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

Operacional

Tipo

Operacional

Funcionami ento Funcionam iento

Etapa

Externo

Áre a

Externo

16

Específico

15

Clas e

Específico

N°

Descripción (Qué puede pasar y, si es posible, cómo puede pasar) Dejar de atender los cambios generados por la regulación para los servicios soportados por la plataforma, quedando ésta desactualizada con relación a las necesidades del mercado Obsolescencia de la tecnología utilizada para desarrollar, operar y soportar los servicios ofertados en ella.

Página 18 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

Consecuencia de la ocurrencia del evento

ANEXOS. Anexo 1. Carta de Presentación. ___________[Lugar y Fecha] Señores LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN. XXXXXXXXXXXXXXX Gerente General Cra. 48 #24-104 Medellín, Antioquia Asunto: Solicitud de Información (RFI: Request For Information) para los Servicios Tecnológicos y de Información para Hospitales.

El suscrito, actuando en mi condición de _________________ y, por lo tanto, Representante Legal de la sociedad ___________________________, legalmente constituida tal como consta en el certificado de existencia y representación vigente expedido por la ______________________, se permite manifestar que: 1. En el caso en que LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA COHAN realice un proceso de contratación para “Contratar servicios en la nube que permitan prestar servicios tecnológicos de información y de gestión de hospitales, de tal manera que se disponga de información confiable, oportuna que se pueda compartir vía estándares de interoperabilidad, como requisito esencial para conformar y pertenecer a las RIPSS (Redes Integrales de Prestadores de Servicios de Salud)”, estaría interesado en participar de dicho proceso.

2. El representante legal, los socios (o Junta Directiva), y la sociedad proponente, no están incursos en causales de inhabilidad e incompatibilidad para la prestación de servicios a la Cooperativa de Hospitales de Antioquia – LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN y declaran que tienen procedencia lícita de activos y de carencia de antecedentes o riesgo de investigación por actividades ilícitas.

Página 19 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

3. La información que entrega, como parte de este proceso de Solicitud de Información, es veraz y puede ser utilizada en los estudios que adelanta LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN para la contratación de servicios tecnológicos y de información para los Hospitales.

4. El Proponente, hará uso responsable de los datos a que tengan acceso únicamente con relación a los servicios objeto de la presente solicitud, garantizando la confidencialidad y debida diligencia en su conservación de conformidad con lo dispuesto en la Ley estatutaria 1581 de 2012 y el Decreto 1377 de 2013 y demás normas complementarias.

5. Cuenta con las condiciones técnicas, operativas y el recurso humano capacitado y suficiente para atender este tipo de proyectos, según se relaciona en la experiencia aportada como parte de este proceso.

Atentamente,

Firma de la(s) persona(s) autorizada(s) Nombre completo Dirección Comercial

_________________________________ _________________________________

Página 20 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

Anexo 2. Formato de experiencia previa.

Relación de Experiencia Entida d

NIT

Direcc ión y teléfo no

Nro. Contrat o

Objeto

Inicio

Página 21 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

Fin

Valor

Estad o

Anexo 3. Requerimientos Técnicos.

Este anexo incluye cada una de las condiciones funcionales/no funcionales que debe cubrir la solución que se oferte; el interesado deberá diligenciar este formato indicando si el punto es cubierto por su solución y describiendo, en forma clara y concisa, la manera como lo hará.

A3.1. Funcionalidad Generales de la Solución

NO.

CRITERIOS FUNCIONALES

1

Manejo de información multisede - multinit: La solución deberá permitir la generación de informes y reportes consolidados por Institución, agrupando en ella las sedes que tenga y/o las otras instituciones en las que tenga participación accionaria.

2

El sistema deberá permitir la generación/construcción de informes consolidados (en la modalidad multisede – multinit) de producción por servicio facturado, por dependencias (o procesos) y por aseguradora, informes de usuarios atendidos por servicios, causas de consulta por grupos de edad, genero, servicio y aseguradora, listados de usuarios atendidos con datos de identificación y contacto. reportes con datos de historias

3

Intercambio y/o compartir Información: La solución deberá permitir intercambiar y/o compartir información entre las Instituciones que hagan uso de ella.

4

Interfaz para el envío/recibo de información: Deberá contar con mecanismo que faciliten la generación y/o entrega de información a Entes de control y/o el cargue de información proveniente de otras entidades y en el cumplimiento de la normatividad vigente, las que la modifiquen o actualicen (ej. El Sistema Obligatorio de Garantía de Calidad y sus componentes Sistema Único de Habilitación; Sistema Único de Acreditación; el PAMEC y el SIS).

CUMPLE

NO CUMPLE

A3.2. Funcionalidad Requerida Módulos Administrativos y Financieros Página 22 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.2.1. Contabilidad.

NO.

CRITERIOS FUNCIONALES

1

Generación de medio magnético de anexos tributarios: Permitir generar un archivo con la Información de Anexos Tributarios que debe ser reportada a la administración de impuestos, teniendo en cuenta la información que se requiera de otros módulos para su generación.

2

Parametrización: Permitir definir datos de la Institución que contrate el servicio, plan de cuentas con sus niveles, centros de costos con sus niveles, terceros con quienes se realizan transacciones, conceptos de impuestos y sus reglas, fuentes contables y sus consecutivos, etc.

3

Información a diferentes niveles de detalle: Permitir tener detalles a nivel de centro de costo y/o tercero, según parametrización que se haga de las cuentas. Permitir que los saldos se puedan manejar a nivel de libros mayores o de auxiliares.

4

Captura De Información De Movimientos Contables: Generar los comprobantes contables periódicos a la aplicación de contabilidad de acuerdo a la parametrización definida y a las necesidades de la Institución. Estos movimientos deben ser consultados y /o modificados (de acuerdo a parámetros establecidos por la Institución). Adicionalmente debe grabar movimientos contables adicionales.

5

Comprobantes Predefinidos: Deberá contar con opciones que a través de las cuales sea posible grabar unos comprobantes predefinidos que se requieren en todos los períodos contables, de tal manera que se facilite y agilice la grabación de los mismos cada mes modificando solo los elementos que varían en ese mes.

6

Impuestos: Contar con el manejo de IVA, ICA, retención en la fuente, IVA retenido, IVA retenido régimen simplificado, impuesto de timbre y demás que apliquen. Con sus correspondientes bases y generando los certificados correspondientes para ser entregados a los terceros para efectos tributarios, permitir adicionar impuestos que se creen ya sea por la Nación o cualquier Ente Territorial que tenga jurisdicción en la Institución que hace uso del servicio.

CUMPLE

Página 23 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

7

Consulta de Información Contable: Por diferentes niveles: cuenta, NIT, centro de costo, entre otros, a nivel de movimiento o a nivel de libro mayor y/o saldos. Consultas que permiten impresión y se convierten en una gran variedad de reportes de acuerdo a los parámetros de consulta utilizados, incluyendo rangos de tiempo

8

Control de comprobantes generados por otros módulos: Contar con una ayuda que permite controlar los comprobantes generados por los módulos de tal manera que se pueda saber qué comprobantes han sido generados, cuáles no, quién los generó, fecha y hora, entre otros.

9

Diferidos: Permitir grabación de los diferentes diferidos y sus variaciones para emitir las amortizaciones mensuales correspondientes de acuerdo a la parametrización de los mismos.

10

Libros Oficiales: Genera reportes oficiales exigidos: libro mayor, libro diario, auxiliar, etc.

11

Cierre Automático de Cuentas Temporales: Contar con una utilidad para generar de manera automática los movimientos contables para el cierre de cuentas temporales.

12

Reportes y estadísticas varias: Contar con todos los reportes necesarios de acuerdo con la normatividad vigente y proveer la facilidad para que se puedan obtener reportes de obligatoriedad posterior.

13

Generación de Ajustes por Diferencia en Cambio: Contar con una funcionalidad que permite ajustar las cuentas contables no solo por inflación sino por factor de cambio para aquellas Instituciones que manejan conversiones de moneda en algunas cuentas contables.

14

Cumplimiento de Normas NIIF: La solución debe cumplir con las Normas Internacionales de Información Financiera y permitir la generación de informes de acuerdo con lo establecido en ellas.

CUMPLE

A3.2.2. Tesorería.

Página 24 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

1

Parametrización: Permitir que la Institución defina de acuerdo a sus necesidades los datos de: Bancos, Conceptos Bancarios, Conceptos Bancarios con Bancos, Formas de Recibo, Conceptos para Movimiento Contable, Fuentes, Formatos para Impresión de Cheques, Poblaciones, Cajas, Rubros de Flujo de Caja, entre otros.

2

Recibos de caja por cartera: Permitir registrar dineros recibidos por concepto de recaudos de cartera. Afecta en una sola transacción el saldo en la caja y/o bancos y el saldo de cuentas por cobrar.

3

Recibos de caja por otros conceptos: Poder registrar información de ingresos por conceptos diferentes a los de cartera.

4

Órdenes de pago por cuentas causadas: Permitir registrar las órdenes de cancelación o abono de documentos que se tengan pendientes de pago con los proveedores. Así mismo, imprimir el cheque o generar la transferencia correspondiente y generar información relacionada con el banco del cual se gira el cheque.

5

Órdenes de pago por otros conceptos: Para elaborar pagos por cuentas no causadas

6

Anticipos de cuentas por pagar: Para generar cheques que corresponden a anticipos de compras a Proveedores

7

Cambio de composición de la caja: Para registrar cambios de composición del dinero en la caja. Ejemplo: Cuando se va a realizar el cambio de un cheque por efectivo

8

Notas Bancarias: Para registrar las notas débito y crédito enviadas por el Banco

9

Consignación: Deberá permitir elaborar las consignaciones del dinero que se tiene registrado en la caja y que está pendiente por consignar tanto en bancos locales como en bancos de otras plazas. Deberá administrar información de cheques posfechados para que estos sean sugeridos en la consignación sólo cuando se ha cumplido la fecha

CUMPLE

Página 25 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

10

Documentos Posfechados: Permitir el registro de documentos posfechados que se reciben en la caja, generando un documento de recibo provisional; posteriormente cuando se cumpla la fecha de vencimiento del posfechado permitir la elaboración de un recibo real de ingreso y establecer la relación con el recibo provisional

11

Extracto Bancario: Permitir el almacenamiento de la información de los extractos bancarios de cada uno de los bancos donde se tenga cuenta, con el objetivo de poder realizar la conciliación bancaria

12

Entrega de cajas: Cuando el cajero termine el turno de trabajo, el sistema deberá permitir registrar el dinero que está entregando, generando un reporte en el que se reflejen los faltantes y/o sobrantes como resultado de comparar lo especificado por el cajero y el movimiento real registrado en la aplicación durante el turno.

13

Traslado de cajas: Permitir el traslado de documentos y/o efectivo pendientes de ser consignados de una caja a otra.

14

Saldos de conciliación: Controlar los saldos de conciliación bancaria, es decir, identificar los documentos que no cruzaron en la conciliación, diferenciando los que se originan del extracto de los que provienen del movimiento de la aplicación.

15

Saldos: Mantener al día (actualizada) la saldos

CUMPLE

información de los

16

Comprobantes Contables: Permitir la generación de comprobantes contables de todos los movimientos realizados: recibos de caja, cheques, notas, entre otros

17

Presupuesto de flujo de caja: Permitir el registro del presupuesto de flujo de caja del año, detallando el valor por cada rubro de flujo de caja.

Con esta información cada mes deberá generar un comparativo de este presupuesto con el movimiento real durante el período, de tal manera que se pueda contar con una herramienta de control y proyección del flujo de caja

Página 26 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

18

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

Entrega de cheques: Contar con mecanismos de control de los cheques girados, identificando cuáles de estos se han entregado realmente al beneficiario del cheque.

Para realizar este control, un cheque puede tener los siguientes estados: girado, autorizado, pagado, entre otros. En cualquier momento se podrá consultar: Cuáles cheques están pendientes de autorizar o entregar, Cuáles cheques están autorizados y no entregados, Cuáles cheques están entregados y no pagados, Cuáles cheques fueron devueltos por insuficiencia de fondos.

A3.2.3. Cuentas por Pagar.

NO.

CRITERIOS FUNCIONALES

1

Parametrización: Permitir parámetros tales como: Consecutivos, Tablas de ICA, IVA, IVA retenido, retención en la fuente, timbre e información de proveedores (únicos en todo el sistema) que además tengan uno o varios conceptos de actividad.

2

Registro de facturas de compra: Permitir el registro de las facturas de las diferentes compras de bienes o servicios realizados por la Institución.

El sistema deberá registrar información que permite causar la retención en la fuente de acuerdo a los parámetros establecidos en las tablas de parametrización y según el tipo de proveedor, igualmente el registro de todos los impuestos a que haya lugar.

3

Recibo automático desde suministros: Se deberán generar de manera automática las facturas en Cuentas por pagar de las compras de insumos y materiales que se reciben en el inventario.

4

Programación y administración de autorizaciones de pagos: Y Deberá ser posible elaborar la programación de los pagos a los diferentes proveedores y su posterior

CUMPLE

Página 27 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

gestión.

5

Elaboración de órdenes de pago: Elaboración de órdenes de pago, para gestión de pago a los proveedores

6

Generación de pagos en lote: Deberá permitir la generación automática de los pagos o transferencias, de acuerdo a lo definido en las autorizaciones, evitándose el trabajo manual de elaboración de cheques de forma individual.

7

Pagos por transferencia electrónica: Permitir el pago a proveedores por medio de transferencia electrónica entre entidades bancarias, entregando un archivo en medio magnético con la estructura de la (s) entidad (es) bancaria (s) definida por la Institución.

8

Registro de notas a las facturas: Permitir el registro de notas que deban generarse a las facturas existentes en el saldo.

9

Generación de anticipos a proveedores: Generar pagos por concepto de un anticipo a un proveedor

10

Aplicación de anticipos: Permitir la aplicación de los anticipos realizados en las correspondientes facturas de compra, manteniendo el control de la información real del saldo de los anticipos entregados a los proveedores.

11

Genera notas bancarias por pagos por transferencia al módulo de caja: Permitir la generación de las notas correspondientes al impuesto de transacciones financieras y que están asociadas a los pagos por transferencias realizados.

12

Vencimientos detallados y resumidos por proveedorfactura: Generar reportes que permitan hacer seguimiento a los vencimientos de las cuentas por pagar que se tienen con los diferentes proveedores, discriminado por edades de dichas cuentas.

13

Estados de cuentas por pagar: El sistema deberá manejar información de estado de cuenta con cada proveedor y sus diferentes movimientos

14

Información de la historia de una factura y todos sus

Página 28 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

movimientos: Permitir la generación de facturas con el correspondiente detalle y su seguimiento su radicación hasta el pago total de las mismas.

15

Generación de notas en lote para cancelación de saldos: Poder automatizar la cancelación de saldos a través de notas

16

Cálculo automático de IVA, ICA, IVA retenido, timbre, retención, con sus bases: Con la parametrización del Proveedor y de los Conceptos utilizados para la radicación de las facturas el sistema deberá calcular en forma automática los impuestos reglamentados en la ley que deben ser aplicados a las facturas recibidas para pago.

17

Generación de comprobantes a la contabilidad: Deberá generar de manera automática los comprobantes a contabilidad teniendo en cuenta la parametrización y la información capturada asociados a facturas, notas, órdenes de pago, anticipos y aplicación de anticipos

18

Generación de información de movimientos bancarios para la aplicación de tesorería: El sistema deberá permitir la generación de reportes asociados a los movimientos bancarios y de los cheques emitidos desde el módulo de Tesorería

19

Integración con los módulos de caja y bancos y presupuesto público: Permitir el control del tope de los contratos de un proveedor, relacionando el contrato en el momento de la causación de la factura. De igual manera, a través del proceso de órdenes de pago causadas, se deberá afectar el giro presupuestal en el módulo de Presupuesto.

20

Generación de cheques: En el momento cancelar una cuenta por pagar el sistema deberá generar el cheque de acuerdo al formato establecido por cada entidad bancaria

A3.2.4. Cartera.

Página 29 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

1

Manejo de la información de recibos de cuentas por cobrar: El sistema debe permitir abonar o cancelar el saldo de una cuenta de cobro (factura) y a la vez realizar el recaudo por los diferentes medios de pago, actualizando directamente la información de Tesorería. Adicionalmente, contar con un reporte resumido y detallado de recibos aplicados a facturas de terceros.

2

Manejo de la información de notas débito de cuentas por cobrar: Permitir la generación de las notas débito por la falta de registro de la totalidad de los cargos que deben cobrarse al responsable del paciente; lo anterior para actualizar la operación de cobranzas y aumentar el saldo de dicha factura sin alterar las operaciones previamente realizadas

3

Manejo de la información de notas crédito de cuentas por cobrar: Permitir la generación de las notas crédito para disminuir el saldo de una factura, por un mayor valor facturado a un paciente; lo anterior para actualizar la operación de cobranzas y disminuir el saldo de dicha factura sin alterar las operaciones previamente realizadas.

Desde el movimiento de glosas, en la aceptación de una glosa las notas crédito se deben generar en forma automática

4

Manejo de relación de envío/ radicación/ devolución/ de documentos: El sistema deberá contar con un mecanismo de manejo de documentos a través de la relación de envío/ radicación/ devolución/ anulación/ a nivel de Institución, por períodos de tiempo y para diferentes tipos de servicios

5

Manejo de radicación / devolución en lote: El sistema deberá permitir la agilización del proceso de radicación/devolución de facturas a través del manejo de lotes de éstas, que además puedan pertenecer a diferentes relaciones de envío e incluso de diferentes responsables.

Esta funcionalidad deberá suplir procesos manuales de clasificación de facturas por número de envío, haciendo más eficiente el proceso de registro de devoluciones al emplear el orden de llegada de las facturas.

6

Generación de consultas: El Sistema deberá permitir realizar consultas interactivas sobre el movimiento de las Instituciones, de las cuentas por cobrar, sobre saldos y sobre el movimiento de facturas, Cartera por edades, y los informes que se requieran por Ley

7

Manejo de la liquidación para el pago a terceros:

CUMPLE

Página 30 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

El sistema debe permitir la generación de un reporte para la liquidación de pago a terceros, el cual debe tener como base la relación de cargos por prestación de servicios hospitalarios que hayan sido efectivamente pagados por parte del paciente o de la persona/empresa responsable del mismo.

Además debe permitir consolidar la información de Facturación y de Cuentas por Cobrar: cargos, facturas, recibos de pago, notas crédito o notas débito que afecten el saldo de cada factura.

8

Manejo de cartera para empresas – multicompañía: El software debe permitir consolidar las cuentas por cobrar de diferentes Instituciones, generando diferentes reportes que permitan realizar diferentes análisis.

9

Manejo de cartera para empresas –multiempresa multisede: El software debe permitir consolidar las cuentas por cobrar de diferentes sedes de una Institución o diferentes nit, generando diferentes reportes que permitan realizar diferentes análisis.

A3.2.5. Glosas.

NO.

CRITERIOS FUNCIONALES

1

El sistema debe contar con un mecanismo que permita realizar la administración de las glosas recibidas desde las empresas-contratos, facilitando la respuesta oportuna a éstas.

2

El sistema debe permitir que se relacionen las glosas formuladas por cada empresa para cada uno de los conceptos glosados; así mismo, hacer la remisión de las glosas hacia los responsables de realizar la auditoría y emitir las correspondientes respuestas.

3

El sistema debe permitir el registro de las respuestas generadas para las glosas recibidas; discriminando por cada concepto: la justificación y los movimientos de cartera requeridos que fueron generados.

CUMPLE

Página 31 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.2.6. Anticipos y Abonos.

NO.

1

2

3

4

5

CRITERIOS FUNCIONALES

CUMPLE

Recibos de caja de anticipos y abonos: Permitir el registro de los recaudos por concepto de Abonos y/o anticipos, hechos por empresas o/a particulares. Deberá ser posible registrar anticipos que tienen una destinación para un paciente específico o un grupo de pacientes.

Cuando el abono o anticipo es de destinación específica deberá permitir que se detallen los pacientes beneficiarios y el valor asignado a cada uno, así como realizar el control por paciente.

Abonos: El sistema debe permitir el registro de abonos; estos pueden llegar sin destinación específica o estar asociados a un responsable y/o beneficiario determinado; para realizar un abono es necesario que exista saldo de las facturas.

Otros datos que se registran en el momento de grabar la recepción de anticipos o abonos deben ser: Detalle de conceptos contables, rubro de ingreso, detalle de formas de pago; así como asociar documentos posfechados recibidos anteriormente como forma de pago Aplicación de anticipos y abonos a facturas: El sistema deberá permitir la amortización parcial o total de los abonos/anticipos recibidos en la facturación generada para la empresa o particular.

Esta funcionalidad deberá contar con las siguientes características: - Realizar el control sobre la amortización de los anticipos/abonos para que se haga sobre los pacientes a los cuales se destinó el dinero, si estos son de destinación específica.

- Incluir observaciones que puedan acompañar la aplicación de los anticipos y/o abonos.

- Identificar cuando la aplicación se realice a un particular.

- Incluir porcentajes que pueden aplicarse sobre los saldos de las facturas que se envíen de manera automática.

Reclasificación de responsables en recibos de anticipos y abonos: Permitir la reclasificación del valor total del anticipo, o la parte que esté pendiente de aplicar, a otra empresa, cuando el procedimiento así lo amerita; por ejemplo concesiones, fusiones de EPS, errores de digitación o cambio de responsable. Esta actividad solo puede realizarse en recibos de abonos o anticipos sin aplicación.

Reclasificación de los responsables de un recibo de abono o anticipo de destinación específica: Permitir la realización del traslado, a otro responsable, del saldo parcial o total de los anticipos o abonos recibidos, en caso que el dinero se vaya a destinar para la atención de otros pacientes. Solo puede realizarse en recibos de anticipos con destinación específica, por el saldo que esté sin aplicar

Página 32 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

6

7

8

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

Disminuir el saldo de un anticipo o de abono registrando una devolución al responsable: Permitir la realización del reintegro parcial o total del anticipo a la empresa que lo generó, afectando el saldo en cartera, realizando o no el reintegro en dinero y definiendo la causa por la cual se realiza.

El reintegro de dinero a la empresa o particular se puede hacer mediante orden de pago o cambio de composición de caja Consultas: El sistema debe contar con consultas rápidas y en línea de los movimientos que ha tenido un anticipo o abono y los saldos actuales del mismo.

Comprobantes contables: El sistema debe permitir la generación de la información contable de los movimientos que se efectúan en la aplicación de los abonos/anticipos, como son: - Anticipos y abonos recibidos - Amortización de los abonos y anticipos - Traslado de Responsable de los anticipos y/o abonos - Devolución de los Anticipos y/o abonos

A3.2.7. Presupuesto Contable.

NO.

CRITERIOS FUNCIONALES

1

Manejo de la información del presupuesto: El sistema debe permitir el registro de información de los valores de presupuesto mensual a nivel de cuenta y centro de costo.

2

Control del presupuesto: El sistema debe permitir el control del presupuesto mediante el uso de los reportes de ejecución de lo presupuestado versus lo ejecutado, para tomar acciones correctivas en caso de una variación muy significativa.

Con el análisis de los reportes se puede llegar a determinar si un presupuesto quedó sobrevalorado o subvalorado y realizar el ajuste respectivo

3

Funcionalidad generación automática del presupuesto: El sistema deberá permitir la generación automática del presupuesto contable de un año, para lo cual tendrá como base la información del presupuesto registrado en el año

CUMPLE

Página 33 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

previo y la definición de un porcentaje de variación que debe aplicar entre los dos años.

Este proceso se puede generar para toda la información, para una cuenta o para un centro de costos 4

Manejo de la información sobre recaudos: Permitir el registro de recaudos efectuados para cada rubro que afecten el presupuesto de ingresos.

5

Manejo de las variaciones de ingresos y de egresos: Permitir el registro de las adiciones por aportes, recursos propios, recursos de capital, transferencia de Fondos Financieros, reducciones y traslados efectuados para cada rubro presupuestal que afectan el presupuesto de ingresos y el de egresos

6

Manejo de suspensiones y aplazamientos: Teniendo presente que el aplicativo será utilizado por instituciones del sector público, éste deberá contar con una funcionalidad que permita la suspensión y el levantamiento de apropiaciones y control en la generación de disponibilidades sobre los rubros que sean suspendidos.

7

Manejo de disponibilidades: Permitir la generación de certificados de disponibilidad de los rubros presupuestales de egresos, mediante los cuales se garantiza la existencia de apropiación disponible y suficiente para respaldar los actos administrativos de la Institución, cuando en esta se aplique este concepto.

8

Manejo de compromisos: Permitir la generación de los certificados de Compromisos adquiridos, es decir permitir el perfeccionamiento y afectación en forma definitiva de la apropiación presupuestal

9

Manejo de obligaciones: Generar un reporte con la relación de las facturas expedidas por los proveedores de los bienes o servicios y que se utilice para generar los giros que amparan los Compromisos en que haya incurrido la Institución.

10

Manejo de los giros reservados y directos: Permitir el ingreso de todos los giros que se efectúen y que afectan el presupuesto de egresos, validando que correspondan a un compromiso o a una disponibilidad de acuerdo con el tipo de giro que se efectúe

11

Administración del PAC: Controlar y administrar el programa anual de Caja (PAC) tanto de ingresos como de egresos. Para lograrlo deberá facilitar el registro de un PAC inicial que sirve de punto de control de las inversiones y los gastos que se van ejecutando durante el año; opcionalmente se podrá administrar el PAC de ingresos

12

Generación de información estadística: Obtener reportes con información requerida por los organismos de control y por la Institución que faciliten la toma de decisiones en cualquier nivel decisorio con relación

Página 34 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

a los rubros administrados en ella.

13

Informes: El sistema deberá contar como mínimo con los siguientes informes: Movimientos por ingresos, egresos, ejecución presupuestal de ingresos, ejecución presupuestal de egresos, disponibilidades pendientes, registros presupuestales pendientes, compromisos pendientes de pago, saldos por rubro, libro de ingresos y egresos, bitácora de operación de ingresos y egresos

14

Reprogramación del PAC de ingresos y egresos: El PAC de ingresos y egresos debe ser reprogramado dependiendo de los parámetros definidos para tal fin en los rubros presupuestales. La reprogramación puede ser automática para disminuir el margen de error, o manual.

15

Administración de contratos: Permitir el registro y seguimiento de cada contrato que realiza la Institución con mínimo los siguientes datos: la disponibilidad, registro, compromiso y giro presupuestal de cada uno, saldo actualizado por contrato y el detalle de los diferentes pagos que se le efectuaron durante la ejecución del mismo

A3.2.8. Terceros.

NO.

CRITERIOS FUNCIONALES

1

Consulta en línea de cada uno de los cargos prestados por los terceros y originados desde los programas de cargos

2

Facilidad para grabar y asociar el número de la factura del tercero al cargo

3

Posibilidad de ingresar otros cargos asociados al tercero desde un movimiento propio

4

Al consultar un cargo de un tercero, se podrán visualizar todos los movimientos que lo han afectado, mediante un detalle que contiene las Facturas, los Abonos, las Notas Débito, las Notas Crédito, los Recibos y las Autorizaciones de los pagos

5

Posibilidad de realizar el desglose del valor de un recibo o de un abono a los conceptos de cada factura por una prioridad previamente definida en un maestro. Esto es: Verificar cuáles conceptos de una factura existen en el maestro de Prioridades y se obtiene su orden de prioridad. El valor del documento (recibo o abono) se va distribuyendo a cada

CUMPLE

Página 35 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

concepto, aplicándolo primero a los de mayor orden (1 tiene mayor prioridad que 10), hasta que el valor a desglosar se agote. Si aún queda valor pendiente de desglosar, éste se aplica a los conceptos que no existen en el maestro de Prioridades en forma proporcional. Si quedan cargos pendientes, su valor desglosado es cero (0)

6

Posibilidad de realizar el desglose del valor de un recibo o de un abono a los conceptos de cada factura de manera proporcional, esto es: Calcular el porcentaje de proporcionalidad, que es igual al valor total del documento menos el valor desglosado y éste resultado se divide por el valor de los conceptos que no tienen prioridad. El valor porcentual encontrado se aplica al valor de cada concepto de la factura que no tiene definido orden de prioridad hasta que el valor a desglosar se agote. Si quedan cargos pendientes, su valor desglosado es cero (0)

7

Generar autorizaciones a pagos: Las autorizaciones de pagos consisten en autorizar el pago a los terceros basados en los recaudos de dinero. Para esto, se deben obtener los saldos y el movimiento de terceros. Como cada tercero tiene una modalidad de pago, se debe tener en cuenta esta variable para saber si se le paga según lo facturado o según lo recaudado

8

Permitir parametrizar el movimiento de autorizaciones de la aplicación para que ésta no permita cancelar valores de los cuales no se ha recibido factura de parte del tercero; este funcionamiento aplica también para el reporte de autorizaciones pendientes

9

Permitir el registro de un movimiento de novedades en el cual se detallen los conceptos contables que afectan automáticamente el valor de las autorizaciones (novedades).

Este movimiento deberá manejar parámetros a partir de los cuales el usuario podrá definir la forma como necesita que sea liquidada la novedad en el período

10

Permitir la realización de pagos a terceros, esto consiste en pagar al Tercero el valor que ya fue previamente autorizado por el programa de Autorizaciones. Para cada tercero se debe poder definir su forma de pago.

11

Permitir la generación de cheques para el pago de los cargos a los Terceros; esto podrá realizarse en lote o individual y dependiendo de la forma de pago que se tenga establecida para el tercero.

12

Permitir la generación del extracto de terceros, este es un informe que permite conocer el ciclo de vida de cada uno de

Página 36 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

los servicios prestados por un tercero: desde el origen de los servicios (cargos), pasando por facturación, cuentas por cobrar (recibos, notas débito y crédito), hasta llegar a las autorizaciones de pago que se producen en el proceso de Terceros con el fin de presentarlo a cada uno de los médicos o terceros 13

Generar saldos de Terceros para cada período contable, dejando registro de ejecución del proceso para auditoria del mismo

14

Permitir la reasignación de los valores desglosados a un tercero después de haber hecho una asignación previa; esta nueva asignación se hace porque la primera resultó afectada por una nota crédito. Además debe permitir que se asocie un centro de costos y NIT a cada concepto contable ingresado; de esta manera, podrá distribuir la información a los centros de costo y NIT que se requiera

15

Permitir que en las autorizaciones se realice asociación de centros de costos para cada concepto contable relacionado en el detalle, de tal forma que en el momento de contabilizar los pagos efectuados a los terceros, la cuenta y el concepto asociado sean contabilizados en el centro de costos correspondiente.

16

Contar con una funcionalidad que permita la modificación de autorizaciones en la parte de Conceptos Contables sin que se tenga que modificar el detalle de cargos a autorizar.

17

Permitir la parametrización del comprobante contable de retención en la fuente para que su causación dependa del registro previo de la factura del tercero, este mismo manejo lo tiene el programa de notas y su respectivo comprobante contable

18

Permitir el pago de varios documentos autorizados a un tercero por medio de la generación de un solo cheque en el que se reúna el valor total de los conceptos agrupados.

A3.2.9. Activos Fijos.

Página 37 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

1

Manejo de la información sobre los activos fijos: Permitir el registro de la información completa de cada activo, tal como: placa, descripción de las características principales del activo, tipo de activo (muebles, vehículos, maquinaria, entre otros), marca, modelo, fecha de adquisición, valor de adquisición, datos relacionados para generar la depreciación acumulada, ubicación, responsables del activo y detalle de los componentes del activo, útil en el caso de activos que están compuestos por varias partes, manejo de activos intangibles y su correspondiente amortización.

2

Manejo de movimientos sobre los activos fijos: Administrar la información de los Activos Fijos en el registro de los movimientos realizados sobre los mismos, tales como: Adquisición, Mejoras, Venta, Retiro y Traslados

3

Manejo de los activos y sus componentes: Administrar los activos y las partes que componen un activo con el fin de llevar un control de los componentes físicos que lo conforman.

4

Manejo de formas de adquisición de activos: Permitir la definición de diferentes formas de la manera como se pueden adquirir los activos, tales como compra, donación, leasing, reposición por garantía, entre otros

5

Control de ubicación y responsables: Permitir el registro y seguimiento (histórico) de la ubicación física de cada uno de los activos y la persona o grupo de personas responsables de ellos al interior de la Institución.

Cada ubicación debe tener relación con su centro de costos para la generación de los informes de ubicaciones por centro de costos.

6

Control de activos no propios de la Institución: Administrar la información de los Activos Fijos que no son de propiedad de la Institución; permitiendo si se realiza el cálculo de depreciación que afecte el modulo Contable o el módulo de Costos

7

Cálculo de depreciación Generar los valores de depreciación en cada mes, mostrando los saldos para cada uno de los activos fijos vigentes en la aplicación. Así mismo, debe permitir la distribución de los valores de depreciación en diferentes centros de costos, de acuerdo a un porcentaje determinado por el usuario.

8

Cálculo de valorización: Generar los valores de valorización o desvalorización de acuerdo a un avalúo técnico de los activos fijos

CUMPLE

Página 38 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

.

NO.

CRITERIOS FUNCIONALES

9

Comprobantes contables automáticos: Generación automática de los asientos contables del periodo, correspondientes a las depreciaciones, los movimientos de adquisición, mejoras, venta, retiro y valorizaciones anuales

10

Integración con otros módulos: Generar movimiento de adquisición de Activos fijos, proveniente del módulo de Suministros, envío de las depreciaciones de los activos fijos no propios de la Institución al módulo de Costos y recepción de información de los diferentes movimientos originados mediante el módulo de Contabilidad

CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

.

A3.2.10. Facturación.

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir diferentes métodos de facturación como Medicina Prepagada, o seguros, con base en su cubrimiento y detalle de topes; adicionalmente, debe permitir la liquidación de la franquicia y valores excedentes de acuerdo con la parametrización de topes, cuotas moderadoras y de recuperación.

2

Permitir la generación de facturas combinando los métodos parametrizados, cubriendo los responsables en forma gradual.

3

Contar con una funcionalidad para parametrizar cualquier tipo de contratación de la (s) Red (es) a la que pertenezca la Institución y las tarifas que deben aplicarse a los usuarios particulares.

4

Permitir la atención de Pacientes Hospitalizados y/o Ambulatorios

5

Contar con la opción de facturación por paciente o facturación por servicio.

6

Contar con una funcionalidad que permita el manejo de diferentes métodos de liquidación de los procedimientos: por Procedimiento, por grupo quirúrgico, por tiempos de cirugía,

CUMPLE

Página 39 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

por unidad y diferentes métodos de liquidación de exámenes (manejo de la liquidación de exámenes por valor total del examen) 7

Permitir la liquidación automática de la estancia hospitalaria (pensión)

8

Permitir la generación de cargos relacionados con la utilización de las habitaciones en la Institución; liquidar de manera automática los días y el valor de la estancia del paciente, de acuerdo con el tipo de habitación, el tipo de servicio y la tarifa que le fue asignada en el momento de la admisión. Para la liquidación de la estancia, se requiere el registro de los traslados de los pacientes a las habitaciones, donde se debe especificar la fecha y hora de ingreso del paciente a la habitación.

9

Permitir el registro y la liquidación de cargos de otros servicios, tales como: exámenes de laboratorio, procesos diagnósticos, cirugías, alimentación o productos no hospitalarios. Estos cargos deben ser realizados a pacientes activos, inactivos o mediante la utilización de paquetes de servicio; además, pueden ser grabados con valores o ser liquidados de manera automática según la parametrización de los procedimientos, los contratos y los cubrimientos

10

Permitir la liquidación de cargos de insumos, materiales, farmacia, material médico quirúrgico, productos químicofarmacéuticos y artículos o productos de cualquier tipo, afectando tanto el inventario como la cuenta del paciente.

También debe manejar las devoluciones con su correspondiente efecto en el inventario y en la cuenta correspondiente.

11

Permitir la generación de cargos a partir de la atención médica en la Historia Clínica de acuerdo con las órdenes registradas por el médico y la actividad clínica; todo esto se lleva a cargos en facturación de acuerdo con la parametrización definida previamente.

12

El sistema debe contar con la opción de generación e impresión de facturas de los cargos a los pacientes en cualquier momento, durante su estancia en la Institución y en especial al momento de su egreso. La generación de facturas debe realizarse tanto para el paciente como para él (los) responsables de la cuenta de prestación de servicios y podrán emitirse hasta tres (3) facturas dependiendo del número de responsables, incluyendo todos los cargos y valores que se hayan generado.

13

El sistema debe permitir la generación de facturas manuales

Página 40 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

facilitando el registro de este tipo de documentos por servicios diferentes a los inherentes a la actividad de la institución o para grabar saldos iniciales de cartera sin detalle de cargos por factura.

14

El sistema debe permitir la generación del estado de cuenta por los diferentes servicios prestados al paciente: exámenes de laboratorio, rayos X, ecografías, procedimientos médico quirúrgicos, materiales médico quirúrgicos, cargos de pensión/habitación, etc. Debe permitir la consulta en forma separada de los cargos facturados y los no facturados, los cargos de los pacientes activos y de los inactivos; así mismo debe permitir la generación de un informe impreso para el total de cargos consultados.

15

El sistema debe permitir la generación de las cuotas de recuperación, pago de particulares y otros movimientos que contengan el recaudo de efectivo y/o títulos valores deben afectar el saldo de la caja en forma automática

16

El sistema debe permitir la generación de Comprobantes contables de Facturación

17

El sistema debe permitir el registro de la factura en el módulo de Cuentas Por Cobrar

18

El sistema debe permitir el manejo de diferentes secuencias para el manejo de los números de facturas, en diferentes puntos de venta del servicio (facturación distribuida)

19

El sistema debe permitir hacer cambios, modificaciones, adiciones y/o anulaciones de cargos de servicios ya grabados a un paciente con el fin de realizar una nueva liquidación (reliquidación de cargos)

20

El sistema debe permitir la realización de cambios de tarifas sin alterar su normal funcionamiento (Tarifas/precios anteriores y actuales de los productos/servicios que se comporten de acuerdo con la fecha de vigencia de la tarifa)

21

El sistema debe estar orientado al manejo de los valores reconocidos, es decir, a determinar qué valores deberá pagar la empresa responsable de la cuenta del paciente, basándose en los conceptos de cubrimientos, los cuales a su vez, abarcan uno o varios conceptos de facturación

22

El sistema debe tener la opción de no reconocidos de artículos y conceptos El sistema desde la grabación del cargo deberá poder determinar si el artículo o el concepto no es reconocido por la empresa y colocarlo como excedente (100% a cargo del

Página 41 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

.

NO.

CRITERIOS FUNCIONALES

CUMPLE

paciente) o como no facturable (no puede ser incluido en la cuenta del paciente).

Nota: La información de los no reconocidos de artículos y conceptos, también puede utilizarse para aquellos artículos o conceptos que para una empresa y plan específico se encuentran incluidos dentro del valor de otros conceptos, es decir, no se facturan ni a la empresa ni al paciente, pero sin embargo, para la institución es importante discriminarlos. Es el caso de los equipos de cirugía, los cuales a menudo se incluyen dentro del valor de los derechos de sala, pero es necesario cuantificar su utilización, por lo tanto se graba el cargo como no facturable

23

El sistema debe permitir a la institución que defina las tarifas básicas, tales como la tarifa para Particulares y la tarifa base; así mismo, las demás tarifas que se definan con base en éstas y/o con porcentajes de recargo o de descuento (tarifas compuestas), con el fin de facilitar su administración (ej. al cambiar una tarifa base se afectan todas aquellas tarifas con las que esté relacionada).

24

El sistema debe permitir la contratación de servicios mediante “Paquetes”, lo que implica una facturación integral que pueda incluir el registro detallado de los cargos y su posterior comparación para determinar la rentabilidad o pérdida del paquete.

25

El sistema debe tener la opción de Refacturación por uno o varios métodos por causas imputables a las empresas (no reciben las facturas por diferentes causas) y ante la imposibilidad de anular la factura original para liberar los cargos y volver a facturarlos.

26

El sistema debe poder controlar la facturación a través del valor “consumido” del contrato teniendo en cuenta, para el control, aspectos como la fecha de vencimiento y la duración del contrato.

27

El sistema debe permitir el cálculo automático del valor del IVA en las facturas que se emitan manuales. Dicho IVA será incluido en la factura como otro cargo más en el detalle de conceptos

28

El sistema debe generar de manera automática a contabilidad los comprobantes contables según la parametrización definida

29

El sistema debe tener la opción para generar la información para la aplicación de costos ABC

30

El sistema debe permitir diferentes métodos de facturación

Página 42 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

tales como: - Pacientes particulares - Accidentes de Tránsito, controlando los diferentes topes de acuerdo al responsable: Aseguradora, Fisalud o Entidad Promotora de Salud (Aseguradora) - Régimen contributivo de acuerdo al cubrimiento, liquidando el copago con control de tope, la cuota moderadora y los períodos de carencia.

- Régimen subsidiado de acuerdo al cubrimiento, liquidando el copago con control de tope compartido entre las EPS’s (Entidades Prestadoras de Salud del Régimen Subsidiado) y la seccional o entidad reguladora de salud correspondiente.

31

Debe tener la opción de generación de la Información requerida por las ESE´s a nivel intra-institucional y para los organismos reguladores del sistema de salud; así mismo, la generación de informes propios para la toma de decisiones en cualquier nivel decisorio de la institución

Nota: El sistema de facturación debe cumplir con la normatividad vigente para el tema, emitida por los Entes de los diferentes niveles (DIAN, Ministerios, Departamentos y /o municipios).

A3.2.11. Agendas Médico-Asistenciales.

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir la programación de la Agenda de los profesionales de la salud y de los consultorios de la institución (Horarios de atención a pacientes).

2

El sistema debe permitir el manejo de citas simultáneas de recursos y de personal médico o paramédico (Agenda compartida)

3

El sistema debe permitir la definición de Tipos de programación (Múltiples duraciones de citas)

4

El sistema debe permitir hacer reservas de citas. Esta funcionalidad deberá poderse ejecutar vía web por los usuarios de los servicios de salud.

5

El sistema debe permitir la generación de citas periódicas para terapias y tratamientos

CUMPLE

Página 43 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

6

El sistema debe permitir la centralización del manejo de la Agenda en el proceso de "Agenda Diaria"

7

El sistema debe permitir la verificación de ausentismos y sus causas.

8

El sistema debe permitir la generación de Novedades en las agendas

9

El sistema debe permitir la cancelación de citas, esta actividad deberá poderse ejecutar vía web por los usuarios de los servicios de salud

10

El sistema debe permitir la reasignación o traslado de citas

11

El sistema debe permitir el registro de la hora en que el paciente llegó a cumplir su cita

12

El sistema deberá permitir el envío de mensajes para recordar las citas que tiene programado cada paciente en cada institución.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.2.12. Admisiones.

NO.

CRITERIOS FUNCIONALES

1

El sistema debe contar con un mecanismo para agilizar el proceso de la admisión de los pacientes a la institución cuando se conoce con anticipación la fecha futura de la hospitalización, la realización del procedimiento quirúrgico ambulatorio o cualquier servicio hospitalario que requiera la apertura de la historia clínica (Preadmisión de pacientes)

2

Admisión de Pacientes El sistema debe contar con un mecanismo para realizar, en forma automática, la verificación de los derechos de atención a un paciente, realizando el cruce contra la información de afiliados, cuando ésta exista.

Así mismo debe permitir la admisión de pacientes que ingresan al servicio de urgencias, generando de forma automática los RIPS de Identificación y de Urgencias. Una vez se completa este proceso, el paciente adquiere el carácter de

CUMPLE

Página 44 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

Activo dentro del sistema. Durante este proceso de admisión, deberá ser posible realizar una admisión con los datos mínimos del paciente (Ingreso corto) para que éste quede activo; una vez se haya estabilizado el paciente y se tenga posibilidad de interactuar con él, se debe completar la información del ingreso.

Admisión de pacientes que ingresan por un evento de accidente de tránsito, capturando para ellos la información requerida para elaborar en forma automática el formulario único de reclamación, el formato para verificación de pólizas, el certificado de atención médica. De igual manera a partir de la información de ingreso se podrá hacer la liquidación para los responsables del accidente con los respectivos controles de topes y saldos.

3

El sistema debe permitir la admisión de pacientes que ingresan al servicio de hospitalización alimentando de forma automática los RIPS de Identificación y de Hospitalización; una vez se completa este proceso, el paciente adquiere el carácter de Activo dentro del sistema

4

El sistema debe permitir el control de las camas de la institución en forma ágil y completará

5

El sistema debe realizar los procesos de ingreso, traslado, egreso de habitaciones, reservas de habitaciones y manejo de lista de espera para los pacientes; así mismo permitir el acceso a la información por parte de las áreas involucradas en de la atención del paciente, según criterios de la institución.

6

Poder realizar el ingreso, traslado y egreso de los pacientes a las habitaciones, grabando para cada caso la fecha y la hora del evento; conservando y controlando la consistencia de la información referente al tipo de habitación, tarifa y servicio asociados para su cobro adecuado

7

El sistema debe contar con el control automático de las novedades que afectan el movimiento de las habitaciones mediante manejo de estados (disponibles, ocupados, reservados, fuera de servicio)

8

El sistema debe permitir la generación de reportes tales como censo de pacientes, utilización de camas por servicio, pacientes hospitalizados con n días de estancia, entre otros

9

El sistema debe permitir la generación de reportes estadísticos tales como Egresos y estancias, disponibilidad y utilización, días de estancia, días cama ocupada

10

Movimiento de Autorizaciones

Página 45 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

El sistema debe facilitar el manejo de la información propia del detalle de las autorizaciones que la EPS entrega para un paciente con el fin de respaldar la atención que se le presta a éste; así mismo, permitir la actualización de esta información para pacientes activos, inactivos o externos (ayudas diagnósticas) de manera independiente del proceso de ingreso del paciente.

11

Movimiento De Responsables El sistema debe permitir el registro de los responsables de la cuenta del paciente y el período en que está a cargo (fecha y hora de inicio, fecha y hora final); otros datos que debe gestionar son: tarifa, plan de beneficios, contrato, descripción, dirección y teléfono del responsable, observación/justificación del cambio de responsable y la facilidad para identificar el responsable actual a cargo del paciente.

12

Movimiento Diario de Partos El sistema debe permitir la gestión de la información relacionada con la gestación (e parto, el puerperio y los recién nacidos), actualizando de manera automática el RIP del recién nacido y su aprobación automática en el caso en que los dos sobrevivan.

13

El sistema debe permitir la generación de estadísticas diarias de partos y nacimientos.

14

Movimiento de Egreso de Pacientes El sistema debe permitir el reporte de egreso del paciente, especificando los diagnósticos, los procedimientos y las especialidades médicas que intervinieron en su proceso de atención, así mismo un resumen de la atención médica asistencial prestada. Al momento del egreso se deberá actualizar de manera automática los RIPS de Urgencia, Hospitalización y Procedimientos con la información de estado a la salida y diagnósticos.

15

El sistema debe disponer de información para la generación de reportes tales como: Pacientes egresados por servicio, por médico, entre otros.

16

El sistema debe permitir la generación de estadísticas relacionadas con la información de los diagnósticos de egreso, especialidades, servicios, municipios y mortalidad entre otras

17

Cambio de Historia Clínica.

El sistema debe permitir la realización del cambio de Historia Clínica para un paciente en los casos en que se detecte la asignación de dos números diferentes de Historia en un mismo Paciente (Homologación de pacientes)

Página 46 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

18

Cambio de Identificación: El sistema debe permitir la actualización de la identificación de un Paciente (modificación o cambio) cuando se comprueba un error en la información almacenada en el sistema. Además debe contar con la posibilidad de almacenar diferentes tipos de identidad para un paciente, pero en este caso sólo una debe ser la primaria.

19

Calendario epidemiológico semanal: El sistema deberá permitir la generación de estadísticas de las enfermedades transmisibles que sean de notificación obligatoria a la Secretaría de Salud

20

Cambio de Nombre: El sistema debe permitir la actualización de la información básica del paciente (nombres, apellidos, contacto, identificación), conservando el historial y la trazabilidad de los cambios realizados.

21

Estadísticas El Sistema deberá generar tanto las estadísticas solicitadas por los organismos gubernamentales, como las propias de la Institución para la toma de decisiones en cualquier nivel decisorio. Entre los principales informes estadísticos que debe producir la aplicación se encuentran: morbilidad, mortalidad y utilización de recursos, generado por lugar de procedencia, residencia habitual, especialidad o servicio de atención.

Deberá generar además indicadores institucionales como: índices de ingresos, índices de egresos, índices de ocupación de camas, índices de morbilidad específica, índices de mortalidad, índices de estancias, etc.

22

A nivel operativo, el Sistema deberá generar todos los informes de uso permanente para realizar o llevar a cabo los procesos de gestión en cada uno de los servicios institucionales, así: a) Clasificación de los pacientes activos (actualmente tienen ingresos abiertos en la institución) ordenados alfabéticamente, por servicio, por empresa, por médico responsable. b) Clasificación de los pacientes egresados por servicio, médico, empresa Estado y disponibilidad del recurso de cama hospitalaria.

23

A nivel gerencial, generar todos los informes que permiten realizar los controles básicos en la producción de servicios, así: Informes estadísticos discriminados por diagnósticos, especialidad, servicios, municipios, procedimientos o intervenciones y estancia hospitalaria

24

El sistema debe permitir la admisión de pacientes que ingresan por un evento catastrófico; en este caso se debe capturar la información del evento y los pacientes asociados

CUMPLE

Página 47 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

al mismo, o el ingreso de un paciente que debe asociarse a un evento previamente registrado en el sistema con el fin de poder cuantificar y clasificar los ingresos de pacientes asociados a uno o varios eventos catastróficos (generación de estadísticas). Además, todos los datos del evento deben tenerse en cuenta al momento de imprimir los formatos requeridos por el Fondo de Solidaridad y Garantía.

25

El sistema debe permitir la generación automática de “cartas de notificación” que deban emitirse al momento del ingreso del paciente al servicio de urgencias y que vayan dirigidas a entidades y/o personas naturales o jurídicas que fueron registradas como “notificables” en el sistema.

26

El sistema debe permitir la generación de informes requeridos por los organismos reguladores del Sistema de Salud.

A3.2.13. Suministros.

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir el registro de la información de los proveedores con los cuales se realizan las compras de bienes, indicando entre otros datos: Dirección, teléfono y ciudad, persona de contacto, plazo en días que otorga, descuentos financieros que generalmente otorga, información de autorretención, régimen de IVA, autorretención de ICA, impuesto de timbre, actividad económica, forma de pago (cheque o transferencia electrónica), entidad bancaria y número de cuenta para la transferencia bancaria, entre otras.

2

El sistema debe permitir el registro de la lista de precios, descuentos y condiciones de pago otorgados por los proveedores para los artículos requeridos en una cotización (el proceso se debe poder realizar de forma manual y/o por medio de una utilidad de cargue masivo).

3

Gestión de solicitudes a compras El sistema debe permitir la identificación de las necesidades de artículos que deben comprarse haciendo uso de alguna de una de las siguientes opciones: a) Por comparación de la cantidad ideal de stock contra el saldo actual del artículo; b)

CUMPLE

Página 48 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

Por los pendientes de entrega que se generen del despacho de las requisiciones internas (pedidos de los diferentes servicios al Almacén Principal); c) Por la programación de las compras basados en los puntos de reorden definidos en días; d) Por necesidades específicas determinadas por el Almacén Principal de cada institución.

Así mismo deberá permitir la identificación de cuáles de las necesidades están tramitadas a través de una solicitud de cotización o de una orden de compra.

4

Registro de órdenes de compra definitivas El sistema debe permitir la elección del proveedor al que se le realizará cada compra, las cotizaciones, solicitud de compras y/o listas de precios desde la que se obtendrá el elemento (para identificar precios, descuentos, impuestos, condiciones de pago y bonificaciones, entre otros).

Las órdenes de compra definitivas, se deben poder generar de manera electrónica en formato EDI para ser enviadas al proveedor de manera automática.

5

Registro de recepciones por compra y causación El sistema debe permitir el registro de los bienes adquiridos y de su recepción en la institución, especificando proveedor (para visualizar sus atributos fiscales), orden de compra (para llevar control de pendientes), número de remisión, número de guía del transportador y número de factura, los artículos recibidos (identificados según el catálogo de artículos definidos en las institución en cumplimiento de los código EAN que pueden ser leído utilizando un lector de códigos de barras) La recepción de los elementos incluidos en una orden de compra no podrá permitir la modificación de datos básicos de ésta ni la recepción de elementos que no estén incluidos en ella o cantidades que no han sido solicitadas. Así mismo, la recepción podrá realizarse en entregas parciales y el sistema deberá tener en cuenta los controles antes descritos.

Una vez finalice el proceso de recepción (parcial o total), el sistema deberá efectuar la causación de la compra en el módulo de cuentas por pagar o en el módulo de contabilidad (según corresponda).

6

El sistema debe permitir asociar cada medicamento, registrado en el catálogo, al medicamento genérico correspondiente de acuerdo a la resolución del Ministerio de Salud (Resolución 1830 de 1999).

7

Información de productos y servicios con todos sus datos incluyendo códigos de barras El sistema debe permitir el registro de la información de los bienes a controlar a través del inventario, indicando entre otros datos: Código, nombre comercial y nombre genérico (si aplica), unidad y fracción de manejo; factor de conversión de

Página 49 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

fracciones a unidades, grupo de artículos al que pertenece, registro INVIMA (o del ente gubernamental que certifica medicamentos, donde aplique), tipo de IVA (gravado, exento, excluido y porcentaje aplicable), costo y fecha de la última compra, códigos EAN con los cuales se pueda identificar el artículo y factor de conversión del código EAN a la fracción del artículo, ubicaciones del artículo en cada uno de los servicios donde se maneja, precios de venta y porcentajes de utilidad esperados para cada una de las tarifas con las cuales se vende a pacientes.

Así mismo, el sistema debe permitir la generación de la relación de los proveedores que suministran el artículo, indicando la cantidad de empaque del proveedor para el artículo, el tiempo de reposición, y la prioridad del proveedor con relación a los demás proveedores que suministran el mismo artículo; calificación de los proveedores.

8

Control de múltiples almacenes y sub-almacenes El sistema debe permitir la realización de control de saldos de inventario para todos los almacenes, subalmacenes y áreas administrativas de cada institución (servicios) que sean definidas por el usuario según necesidades

9

Control de stock por servicio El sistema debe permitir, donde se determine, para cada servicio (almacén, sub-almacén, área administrativa) gestionar el conjunto de artículos que les es permitido manejar, las cantidades ideales de stock a almacenar y los días máximos y mínimos de inventario.

El conjunto de artículos debe poderse definir en términos de comerciales y de genéricos, que permita descargar por los subalmacenes (o a nivel global) el costo, según el servicio.

10

Gestión de requisiciones internas El sistema debe permitir la generación de pedidos de los diferentes servicios al Almacén Principal utilizando cualquiera de las siguientes opciones: a) Para artículos a los cuales se les controla el saldo, por comparación de la cantidad ideal de stock contra el saldo actual del artículo en el servicio que solicita; b) Para artículos de consumo a los cuales no se les controla el saldo, por comparación de la cantidad ordenada en el periodo (mes o semana) contra la cantidad máxima a pedir en ese mismo periodo. c) Por necesidades específicas determinadas por el servicio que hace la solicitud. En esta opción debe permitir solicitar artículos no registrados en el catálogo de la institución.

Adicionalmente, debe permitir la identificación de los pendientes que se tengan para despachar desde el Almacén Principal, ya sea por grupo de artículos o por servicio que solicita.

Para los servicios definidos como sub-almacenes, el sistema

Página 50 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

debe permitir que el Almacén Principal, encargado de atender sus necesidades, genere automáticamente y por día las requisiciones internas que dese allí se requieran, basadas en la comparación de la cantidad ideal de stock contra el saldo actual del artículo en el sub-almacén; así mismo debe generar alertas de vencimiento para cada uno de los artículos.

11

Movimientos de inventario El sistema debe permitir la realización de movimientos (entrada, salida o traslado entre servicios) que sean parametrizables en cuanto a: a) Costeo del tipo de movimiento, obteniendo la información de la cantidad, descuentos e IVA aplicables. b) El destino del servicio (traslados y consumos). c) El efecto contable que genera y/o si aplica el uso de interfaz con Cuentas por Pagar. d) Si es un préstamo y si corresponde al inicio o a la terminación de dicho préstamo. e) Si está asociado a una orden de compra, una requisición o con otro movimiento de inventario y si el movimiento requiere de la información de un proveedor.

Además, el sistema debe permitir que a cada tipo de movimiento le sea habilitado el control para la autorización a los usuarios y servicios que pueden utilizarlo.

Los artículos que intervienen en cada tipo de movimiento deben poder identificarse con el código asignado internamente desde el catálogo de artículos o con el código EAN que se le haya asociado previamente; éste último podrá ser leído utilizando un lector de códigos de barras.

En el caso de los tipos de movimientos que están relacionados con préstamos, el sistema debe permitir la realización de control del saldo del préstamo por institución relacionados como terceros, documento de préstamo y artículos prestados.

12

Generación de información a facturación correspondiente a los cargos de materiales y medicamentos.

El sistema debe permitir el registro de la (s) salida (s) de artículos o medicamentos aplicados al paciente, realizando el descargo automático del saldo de inventario del servicio que despacha, y aumentando la cuenta del paciente con el precio de venta de acuerdo a la tarifa pactada para el responsable de la cuenta.

Así mismo, debe permitir el registro de las devoluciones de medicamentos de pacientes, disminuyendo la cuenta del mismo de acuerdo a la tarifa del responsable e incrementando el saldo de inventario del almacén que suministró el medicamento.

Nota: El precio de venta del artículo dependerá de quién sea el responsable de la cuenta del paciente y el costo de la mercancía vendida dependerá del costo promedio del artículo

13

Manejo de mercancía en consignación El sistema debe permitir la identificación y control de la

Página 51 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

mercancía en consignación a través de la definición de almacenes (servicios) de mercancía en consignación ya sea generales o por proveedor.

Así mismo, debe permitir la legalización de la mercancía cuando es utilizada (ya sea en pacientes o internamente), a través de movimientos de inventario.

Nota: Los bienes que se encuentren en consignación no harán parte de los procesos de consolidación del inventario de la institución, ya que no se consideran como propios; sin embargo se debe conocer y controlar su saldo en cada servicio de consignación

14

Realización de inventario físico y generación de ajustes El sistema debe permitir la implementación de un proceso para la realización y ajuste de los inventarios físicos, ya sean generales o rotativos.

Para la realización del conteo se debe poder utilizar terminales portátiles donde es posible identificar el artículo ya sea con su código interno o con cualquiera de los códigos EAN asociados a él.

Una vez realizado el conteo, el archivo almacenado en la terminal portátil, se debe poder importar al sistema de Suministros y Farmacia para continuar con el proceso.

Previo a la realización del ajuste se debe generar un reporte de comparación entre el inventario físico y el inventario del sistema con el fin de cuantificar, analizar y explicar las diferencias.

Se debe contar con un proceso que genere automáticamente los movimientos, ya sea de entrada por faltante o de salida por sobrante, tanto en cantidad como en valor, que permitan que el saldo actual de los artículos en el sistema sea idéntico al inventario físico registrado.

El sistema debe permitir la realización del inventario físico con uno o dos conteos.

15

Trazabilidad de lotes El sistema debe permitir la captura del (los) lote (s) de inventarios recibidos con su respectiva fecha de vencimiento cada vez que se realice una entrada del inventario (por compra, préstamo, donación, bonificación, etc). Lo anterior debe permitir la realización de revisiones periódicas de las existencias próximas a vencerse con el fin de evitar pérdidas de inventarios y/o la consulta de fechas de recibidos, medicamentos que hacen parte del lote y/o proveedor que lo suministró, entre otros.

16

Gestión de mezclas El sistema debe permitir el ingreso en el catálogo los artículos que corresponden a mezclas, con el fin de realizar el control de su fabricación, utilizando un paquete de elementos que determina los materiales y las cantidades necesarias para su

Página 52 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

fabricación. En este paquete se deben identificar el medicamento principal y el diluyente de la mezcla.

Para el control de fabricación de las mezclas, se debe poder determinar los materiales y cantidades requeridos para la mezcla, indicando el lote de fabricación y la fecha vencimiento con el fin de tener la trazabilidad de los lotes En la venta de los artículos tipo mezcla, el precio de venta se debe obtener a partir de la tarifa de los elementos que componen la mezcla

17

Integración con el sistema de órdenes médicas El sistema debe generar información de medicamentos y materiales ordenados al paciente, a través del módulo de órdenes médicas, para ser cargados a la cuenta del paciente y descargados automáticamente del inventario.

18

Generación de comprobantes contables El sistema debe generar la información requerida por contabilidad para cada uno de los conceptos de movimiento, de acuerdo con la definición contable establecida para cada grupo de artículos y concepto de movimiento. Así mismo, generar información de entradas por compra como facturas o cuentas por pagar de acuerdo a la definición contable establecida para cada grupo de artículos; adicionalmente, generar reportes de acuerdo a los grupos, asignaciones o distribuciones del inventario.

19

Presupuesto anual de consumos El sistema debe permitir la estimación del presupuesto anual de consumos con base en los movimientos de inventario del año en curso; así mismo, la comparación de la ejecución (consumo real) con el presupuesto realizado para el período actual y para cada servicio al interior de las instituciones.

20

21

Solicitud de cotizaciones El sistema debe facilitar la gestión de compras permitiendo almacenar la solicitud de cotización de artículos de la institución y a qué proveedores se envía la solicitud, para ser referenciada una vez se reciba la correspondiente cotización de parte del proveedor. La gestión debe contemplar, entre otras, la siguiente información: Fechas de solicitud y vencimiento, proveedores a los cuales se les hace la solicitud, solicitudes a compras que se atenderán con la cotización, artículos a cotizar con unidad, tipo de artículo, precio y cantidad.

Registro de cotización El sistema debe permitir la administración de la información asociada a las cotizaciones recibidas: Identificación del proveedor, lista de precios, fecha de la cotización, vigencia, descuentos financieros, descuentos comerciales generales

Página 53 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

para todo el documento y/o específicos por artículo, información de bonificaciones (ya sea por valores comprados o por cantidades compradas), indicando si se liquidan por cada compra o por las compras acumuladas.

22

23

24

Generación de órdenes de compra de prueba El sistema debe permitir la generación automática de órdenes de compra de prueba en las que asigne los artículos y cantidades que deben ser adquiridas a un proveedor en particular de acuerdo a unos criterios de selección.

La selección de los artículos a comprarle a un proveedor puede realizarse por: Información de las solicitudes a compras que no se han tramitado, verificación de saldos actuales contra los días mínimos de inventario y los tiempos de reposición.

La selección del proveedor para la orden de compra de prueba debe tener las siguientes opciones: a) Por el menor precio del artículo a comprar, considerando todas las listas de precios vigentes o las listas de precios de un conjunto específico de proveedores. b) Por una priorización asignada con anticipación por el responsable de las negociaciones, la cual debe permitir designar con anticipación el proveedor para cada artículo.

En el análisis de las cotizaciones recibidas, el sistema debe facilitar la elección del proveedor que ofrece las mejores condiciones de precio, descuento y tiempo de entrega (permitir la comparación de estos conceptos para la toma de decisiones).

Una vez la orden de compra de prueba se genere y se revise, debe poderse actualizar como una orden de compra definitiva que debe informarse al proveedor o como una orden de compra cancelada.

Manejo de históricos de compras El sistema debe permitir el análisis de históricos de compras: a) Por proveedor, verificando los artículos comprados en un rango de fechas; b) Por artículo, verificando los proveedores a quienes se le ha comprado en un rango de fechas.

Manejo de mercancía en préstamo El sistema debe permitir la identificación y control de la mercancía que la institución da o recibe en calidad de préstamo a través de la definición de conceptos de entrada y salida de mercancía prestada a/por otras instituciones; una vez se haga uso de la mercancía (en pacientes o internamente) deben registrarse los movimientos de inventario correspondientes.

Nota: Los bienes que se encuentren en calidad de préstamo no harán parte de los procesos de consolidación del inventario de la institución, ya que no se consideran como propios; sin embargo debe ser posible conocer y controlar su saldo y

Página 54 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

legalizar su ingreso Control de demanda insatisfecha El sistema deberá permitir, en el proceso de atención de las requisiciones internas por parte del Almacén Principal y por cada artículo que no sea entregado en la cantidad solicitada, la captura de la causa de no despacho y posteriormente permitirá analizar las razones por las cuales no se cumple con las necesidades de los diferentes servicios

25

26

Paquetes dinámicos El sistema debe permitir la definición de paquetes de artículos, asignándole un código de artículo en el catálogo y estableciendo las cantidades de cada uno de los artículos que intervienen en la configuración del paquete y el comportamiento que tendrá a nivel de facturación. Así mismo, realizará las actualizaciones (carga/descarga) en los saldos del inventario de los artículos que componen el paquete cuando éste sea utilizado en un paciente, en este caso, el precio de venta se obtendrá a partir de la tarifa de los elementos que lo componen y el tipo de comportamiento dependiendo si es facturable o no.

A3.2.14. Nómina.

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir la administración y generación de cualquier tipo de nómina como: Nómina de oficiales, manejo de pensionados, manejo de múltiples sindicatos, convenciones colectivas, nóminas temporales, manejo de destajos, diversas periodicidades de pago (mensual y quincenal) y múltiples contratos de trabajo por empleado.

2

El sistema debe permitir que se parametricen datos para la nómina como: salario mínimo, auxilio de alimentación, subsidio de transporte, porcentajes de retención en la fuente, seguridad social e incapacidades, diversos tipos de nómina, motivos de retiro, períodos de liquidación, calendarios de nómina, conceptos de nómina, bases de liquidación, rangos de indemnizaciones, entidades y cuentas de los empleados

CUMPLE

Página 55 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

3

El sistema debe permitir la administración de las hojas de vida de los empleados.

4

El sistema debe permitir la generación del reporte de aportes a entidades externas (Seguridad Social y Parafiscales).

5

El sistema debe permitir la liquidación de prestaciones sociales, mínimo: vacaciones, prima de vacaciones, prima de servicios, prima técnica, bonificación de servicios prestados, prima de navidad, cesantías, cesantías parciales, intereses sobre cesantías, cesantías anuales a fondos de cesantías, quinquenios, liquidación definitiva, bonificación por recreación, permitir crear conceptos nuevos.

6

El sistema debe permitir el manejo de consolidaciones y provisiones

7

El sistema debe contar con una interfaz contable que permita el registro contable de la nómina en el módulo de contabilidad.

8

El sistema debe contar con facilidades para realizar simulaciones de nómina y prestaciones sociales

9

El sistema debe permitir la realización de las siguientes transacciones: novedades de nómina vía (archivo plano, mail o internet), novedades por beneficiario, liquidación de compensatorios, manejo de ausentismos y días no trabajados, conciliación de incapacidades, control de descuentos de diversos tipos de embargos (civil, alimentos, ejecutivo), generación de medios magnéticos, pago de embargos, control de sanciones y demandas, liquidación de impuestos a empleados (retenciones), definición de turnos, generación de novedades y rotaciones automáticas, interface con sistemas de control de tiempos, manejo de encargos (funciones y salario), control y descuento de UPC, definición y liquidación de destajos

10

El sistema debe permitir la liquidación de nómina normal y adicional (extra-nómina), teniendo en cuenta conceptos como (horas extras, recargos, incapacidades, prima de antigüedad, prima de riesgos, quinquenio, auxilios, préstamos, libranzas, fondos de empleados, cooperativas, embargos (en valor o porcentaje autorizado por el juez), liquidación de expatriados, manejo de bonificaciones, generación de medios magnéticos para pago por gerencia electrónica, generación de cheques y pago en efectivo.

Así mismo la administración de pensionados (gestión de todos los conceptos relacionados con el manejo de la nómina de pensionados y jubilados, tales como generación de cuotas partes, liquidaciones de mesadas, sustituciones y beneficiarios por pensión)

CUMPLE

Página 56 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

11

El sistema debe permitir la liquidación de aportes de seguridad social teniendo en cuenta todas las novedades o incidencias que se generan en el proceso de nómina (incapacidades, traslados, vacaciones, ingresos, retiros, descuentos de UPC, variaciones de salarios, etc.); así mismo, la generación de reportes y medios magnéticos para las diferentes entidades (EPS, ARP, AFP), y de planillas unificadas para su pago.

12

El sistema debe permitir la realización del proceso de liquidación definitiva de prestaciones sociales de manera automática y teniendo en cuenta toda la información del sistema, la acumulación de nómina y los demás factores y variables que se deban tener en cuenta para este proceso (renuncia, insubsistencia, suspensión del empleo, jubilación, invalidez, retiro forzoso por edad, suspensión); así mismo deberá validar (durante el proceso) información como: vacaciones, cesantías, indemnizaciones, embargos, préstamos, primas y prendas devolutivas que estén pendientes por pagar.

13

El sistema debe permitir el incremento de sueldos teniendo en cuenta diversas variables y definiendo los grupos a los cuales se les debe aplicar; de igual manera debe permitir la ejecución de simulaciones y/o comparaciones con el mercado y de proyecciones de nómina. Adicionalmente, deberá permitir la generación de los retroactivos correspondientes a los periodos que se dejaron de cancelar con el respectivo aumento.

14

El sistema debe permitir la generación de todos los procesos de liquidación de cesantías de acuerdo al tipo de solicitud (parcial, definitiva o fin de año) y la información que pueda generar variaciones en este proceso (ausentismos, licencias, incidencias etc.); así mismo debe mantener el histórico de los procesos de liquidación que se le han realizado a los trabajadores, permitiendo la generación de medios magnéticos y reportes con destino a los Fondos de Cesantías.

15

El sistema debe permitir la generación del proceso de vacaciones en tiempo o en dinero de acuerdo con la solicitud del empleado o la programación de la compañía; de igual manera debe considerar el aplazamiento o la reversión de las vacaciones con la generación de los correspondientes comprobantes de pago, reportes de cumplimiento de vacaciones, reliquidación de vacaciones y conservando un histórico de todos los períodos disfrutados por cada empleado. En la liquidación de las vacaciones deberá tenerse en cuenta las primas legales o extralegales según las políticas que tenga la Institución, pagos por nómina y la conservación de la información histórica.

CUMPLE

Página 57 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

16

El sistema deberá permitir la parametrización (asignación, liquidación y conservación del histórico) de cualquier tipo de acuerdo laboral en la forma de compensación salarial que tenga un empleado ya sea el arreglo en pesos o porcentaje, finalizando el periodo con un ajuste de cuentas entre el colaborador y el patrono.

17

El sistema debe permitir la liquidación definitiva automática de prestaciones sociales teniendo en cuenta toda la información del sistema, acumulación de nómina, liquidación y mantenimiento de aportes parafiscales y provisiones, generación de certificados de ingresos y retenciones, manejo de reingresos a nómina, presupuesto de nómina, manejo de sustituciones patronales entre Instituciones, generación de medios magnéticos a entidades de control, cambio de identificación, etc.

18

El sistema debe permitir la generación de reportes de: - pre nómina - por centro de costo - por nivel - ordenados alfabéticamente - comparativos de novedades grabadas vs liquidadas - consolidados mensuales - estado de endeudamiento - empleados sin cuenta - empleados no liquidados - comparativos por meses, etc.

Nota: En caso de requerir reportes adicionales el usuario puede generar nuevos a través de la funcionalidad de reportes dinámicos

19

El sistema debe permitir la generación de los reportes de pagos para ser enviados por el correo interno a todos los funcionarios de cada institución.

20

El sistema debe permitir la generación de los reportes para el certificado de Ingresos y Retenciones y los demás informes solicitados por los entes de control.

CUMPLE

A3.2.15. Costos.

Página 58 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir la generación automática del Plan de Costos para un período determinado, incluyendo la información de los costos unitarios asociados a las actividades ejecutadas en los diferentes procedimientos CUPS, distribuidos por centros de costos operativos y centros de costos de apoyo homogéneos.

Nota: La información del Plan de Costos debe ser ágil, coherente, razonable y completa con relación a los CUPS que se ofertan en la red pública, de tal manera que permita comparar sus costos con los valores facturados.

2

El sistema deberá permitir la obtención del Plan de Costos en una de las siguientes formas (seleccionada por cada Institución): Mediante un proceso que calcula el costo unitario de cada procedimiento y lo lleva al Plan de Costos del período tomando como base la información generada por la distribución de los centros de costos operativos y la producción reportada en ellos. En el caso de los centros de costos de apoyo homogéneos toma el costo unitario de la unidad producida por cada uno de los centros de costo involucrados.

Mediante un movimiento de distribución por unidades equivalentes, o por peso equivalente, se asignan los costos a los diferentes procedimientos CUPS, teniendo en cuenta su participación dentro del grupo de cada centro de costos.

Para los demás CUPS se asignan criterios que por su casuística, frecuencia y cuantías no sean representativos dentro de la red pública.

3

Manejo de información de referencia: El sistema debe permitir la configuración o parametrización de acuerdo a las necesidades propias de la Institución, como son: unidades de producción, centros de costos, criterios de distribución, estándares de procedimientos con sus componentes (CUPS), aplicativos para la asignación y distribución de recursos en centros de costos y entre centros de costos, al igual que para la asignación de recursos a los CUPS.

4

Grabación de movimientos de costos: El sistema debe permitir el registro de información que se ingrese periódicamente y de manera manual, tales como movimientos que se derivan fundamentalmente del gasto (mano de obra, materiales, costos generales y estimaciones contables) que consume la Institución para funcionar adecuadamente y de acuerdo al volumen de producción que logra en cada período.

5

Distribución de costos: El sistema debe permitir la distribución de los costos y gastos

CUMPLE

Página 59 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

entre los diferentes centros de costos (de apoyo u operativos) de la Institución, para obtener el costo de los procedimientos producidos en cada uno de ellos. Así mismo, manejar estimados por procedimientos que permiten realizar las distribuciones y los comparativos entre costos estimados versus real.

Adicionalmente debe contemplar la utilización de los RIPS como instrumento de apoyo para la distribución de los diferentes recursos en los procedimientos CUPS.

6

Generación de movimientos automáticos: El sistema debe permitir el traslado al módulo de Costos, generando los movimientos de manera automática, de la información existente en otros módulos como: Cirugía, Contabilidad, Suministros, Nómina, Facturación y Activos.

7

Generación de acumulados: El sistema debe permitir el almacenamiento de la información obtenida en las distribuciones realizadas, agrupada por procedimientos, centros de costos, conceptos, elementos del costo, tipo de costos (fijo/variable) y clase de centros de costos

8

Cierre de período: El sistema debe permitir el control de los usuarios en el ingreso de información de un periodo (para que no puedan realizar modificaciones en los datos ingresados)

9

Generación de reportes: El sistema debe permitir la obtención de reportes de las transacciones de costos, costos de procedimientos, reportes de análisis, comparación entre los diferentes centros de costos, unidades de negocio, procedimientos CUPS y relación ingreso – costo de los diferentes servicios ofertados en CUPS. Así mismo, los reportes de la facturación discriminada por centro de costos.

A3.2.16. Funcionalidad Adicional Opcional: Recursos Humanos y Contratación Servicios.

Página 60 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir el manejo de la hoja de vida de cada uno de los empleados de cada Institución.

2

El sistema debe permitir al proceso de selección y contratación de empleados mediante el almacenamiento y control de toda la información relacionada con los aspirantes, tales como resultados de pruebas de conocimiento, pruebas psicotécnicas, etc.

Nota: El proceso puede realizarse o no, bajo el modelo de competencias, caso en el cual deberá permitir el almacenamiento y posterior consulta de los registros históricos de la evaluación de cada empleado.

3

El sistema debe permitir la planeación de tareas, actividades y responsabilidades, definiendo cronogramas de trabajo e identificando la disponibilidad de los empleados.

4

El sistema debe permitir la gestión (planeación, administración y evaluación) de los eventos y beneficios para los empleados.

5

El sistema debe permitir el registro y actualización de la información relacionada con la educación formal y no formal de los empleados.

6

El sistema debe permitir la generación de la nómina de prestación de servicios

7

El sistema debe permitir el control de la documentación requerida para la firma de los contratos de los empleados.

8

El sistema debe permitir la generación de contratos impresos, controlando la numeración, vigencia, número de disponibilidad y el registro presupuestal.

9

El sistema debe permitir el control de las bases para aportes de seguridad social, así como el cálculo de impuestos (Retención en la Fuente, Rete-ICA) en los contratos de prestación de servicios.

10

El sistema debe permitir la realización del control de descuentos de cooperativas y/o libranzas autorizadas previamente por el contratista.

11

El sistema debe permitir la generación de novedades asociados a cada contrato de prestación de servicios.

12

El sistema debe permitir la generación de hojas de vida de los contratos.

13

El sistema debe permitir el manejo y control de capacitaciones

CUMPLE

Página 61 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

realizadas a los empleados.

A3.3. Funcionalidad Requerida Módulos Clínico Asistenciales HIS A3.3.1. Admisión del paciente.

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir el almacenamiento de los datos que ayuden individualizar al paciente en la red (datos de aseguramiento y socio-demográficos); así mismo la gestión del proceso de admisión del paciente, en áreas de consulta externa, hospitalización o urgencia, incluyendo todos los pacientes de TRIAGE.

2

El sistema debe asignar automáticamente un número de historia clínica único para el paciente, éste debe ser la identificación del paciente o el NUIT. Así mismo, debe permitir la apertura del registro clínico administrativo en pacientes sin identificación y la admisión del recién nacido, considerando el vínculo madre-hijo.

3

El sistema debe estar dotado de diferentes criterios de búsqueda de pacientes (exacta y/o por aproximación), al menos por nombres, apellidos, identificación y número de historia clínica. Adicionalmente, debe permitir la edición de los datos obtenidos de las búsquedas.

4

El sistema debe permitir la asignación del estado de preadmisión (estado "en espera" para hospitalización) de pacientes.

5

El sistema debe permitir la gestión de Admisión del Usuario/Paciente, tanto en las áreas de Consulta de Especialidades, Hospitalización y Urgencias, como admisión en observación

6

El sistema debe identificar y gestionar prestaciones y atenciones asociadas a seguros (seguro escolar, seguros de accidentes de tránsito y otros), permitiendo la acreditación del

CUMPLE

Página 62 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

derecho de atención, tipo de seguro, cobertura y restricciones, según las reglas de negocio establecidas por la institución.

7

La plataforma deberá proporcionar la capacidad de interoperar de manera segura con otras plataformas regionales y nacionales de comprobación de derechos a través de servicios web.

8

El sistema debe contar con la opción de búsqueda de pacientes, localizar en forma on-line, ubicando el área donde se encuentra (urgencia, hospitalización y atención ambulatoria)

A3.3.2. Agenda Médica.

NO.

CRITERIOS FUNCIONALES

1.

El sistema debe permitir la definición de agendas por especialidad, subespecialidad, servicio, recurso humano, horario y frecuencia o intervalos; teniendo en cuenta el proceso de agenda para consulta prioritaria desde el servicio de urgencias

2

El sistema debe permitir la apertura de agenda por periodos variables.

3

El sistema debe permitir la definición y parametrización de los tipos de atenciones: ingreso, control, sobrecupos, consultas abreviadas, consultas derivadas y procedimientos.

4

El sistema debe permitir la redistribución de cupos de agenda, modificación de rendimientos y/o la reasignación de pacientes de un profesional a otro.

CUMPLE

El sistema debe permitir la gestión de citas, incluyendo: Citación de las agendas para el mismo día o días futuros.

Citaciones periódicas, por ejemplo para especialidades como rehabilitación y dental.

- Citar un paciente para diferentes especialidades Nota: La gestión debe buscar que se concentren, en lo posible, las fechas de las citaciones de un paciente, evitando que se presenten conflictos de citas para un paciente a la misma hora

5

Página 63 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

y día con diferentes especialidades.

6

El sistema debe permitir la selección vía web de hora, día, lugar y especialidad para una cita que requiera (autoasignación), y gestionar la integración (interfaz web) con línea de asignación/gestión de citas de que disponga cada Institución.

7

El sistema debe permitir la búsqueda automática de cupos disponibles para citas.

8

El sistema debe permitir la configuración de alertas para casos especiales definidos por la institución, ejemplo diagnósticos específicos.

9

El sistema debe permitir que se agende una nueva cita o procedimiento desde el momento de la consulta con el profesional.

10

El sistema debe contar con funciones de bloqueo y/o anulación de citas (motivos parametrizables por la Institución) y la reorganización de las citas mediante reprogramación automática y/o manual.

11

El sistema debe permitir que el usuario clínico pueda visualizar su agendamiento.

12

El sistema debe permitir la visualización gráfica de las agendas en cualquiera de las siguientes opciones: profesionales por ubicación, especialidad, agenda personal, pacientes en espera de atención médica, tipo de atención, atenciones cumplidas.

13

El sistema debe permitir que se incorporen notas para los profesionales.

14

El sistema debe permitir la consulta de todas las citas del paciente (reporte histórico) en un periodo determinado, mostrando: fecha-hora-especialidad-profesional, asistencias e inasistencias y motivos de baja, para habilitar al personal de la Institución con diversos indicadores (predictores y tendencias).

15

El sistema debe permitir la contabilización de los tiempos de atención del paciente: Recepción, espera, inicio-fin de la atención clínica o procedimiento, tiempos medios de atención, tiempos muertos y otros indicadores que la Institución estimara pertinentes.

16

El sistema debe permitir el uso de estados parametrizables de la agenda establecidos por la Institución.

Página 64 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

17

El sistema debe permitir la visualización de la lista de citas por especialidad, profesional u otros parámetros.

18

El sistema debe contar con la posibilidad de visualizar las horas asignadas a sus pacientes en los consultorios de atención primaria, así mismo realizar el agendamiento de las mismas y generar alertas sobre anulación de citas y/o reposición de las mismas

19

El sistema debe permitir el acceso, por parte del personal médico, a la agenda de atención ambulatoria para realizar consultas y citas. Así mismo, permitir el agendamiento de pacientes extra.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.3.3. Historia Clínica Médica.

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá permitir el registro de información clínica de un paciente; éste debe ser válido desde el punto de vista clínico y legal y recoger información de tipo asistencial, preventiva y social.

2

El sistema debe permitir el registro y consulta de Anamnesis: Datos surgidos de la entrevista clínica, incluido el motivo de consulta, la enfermedad actual y otra información demográfica relevante.

3

El sistema debe permitir el registro y consulta de Antecedentes: Información de antecedentes clínicos del paciente según sexo, por especialidad y con codificación de enfermedades basada en CIE-10

4

El sistema debe permitir el registro de antecedentes de uso de medicamentos (incorporar vacunas y notas del paciente).

5

El sistema debe permitir el registro y consulta de revisión por sistemas.

6

El sistema debe permitir el registro y consulta de Exploración física: conjunto de datos objetivos o signos que estén relacionados con los síntomas que refiere el paciente,

CUMPLE

Página 65 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

registrando como mínimo y según escalas y unidades parametrizadas: la temperatura, índice de masa corporal, talla, peso, escala de Glasgow, presión arterial con cálculo para la presión arterial media, frecuencia cardiaca, frecuencia respiratoria y pulso (signos vitales), saturación de oxígeno en toda la red.

7

El sistema debe generar alarmas para control de signos vitales por fuera de los rangos establecidos, creando las notificaciones correspondientes.

8

El sistema debe permitir que se establezcan rangos de seguridad y alertas para cada parámetro de signos vitales, considerando las variables de edad, y sexo del paciente, entre otras subdivisiones.

9

El sistema debe permitir la visualización gráfica de los datos de signos vitales del paciente; otorgar una visualización centralizada de todas las constantes registradas al paciente, además de visualizaciones de la evolutiva de constantes seleccionadas.

10

El sistema debe contemplar el uso de filtros (fecha y hora) para la visualización de constantes, ya sea por paciente y/o por Unidad Clínica.

11

El sistema debe permitir la exploración física por regiones: Permitiendo registrar y describir el estado del paciente tras de examen físico por aparato o sistema del cuerpo humano, determinando si fue o no evaluada la región y el estado de ésta, donde las regiones principales se describen a continuación: ● Examen cardiaco y vascular ● Examen del aparato digestivo ● Examen del aparato urinario ● Examen del sistema linfático ● Examen dermatológico ● Examen ginecológico ● Examen neurológico ● Examen osteoarticular ● Examen otorrinolaringológico ● Examen pulmonar o respiratorio ● Examen psiquiátrico y psicológico ● Examen urológico

12

El sistema debe permitir el registro y consulta de datos de exploración complementaria: Registro de pruebas y exámenes complementarios, relacionando órdenes de laboratorio, diagnóstico por imágenes y pruebas especiales realizados en el paciente.

Página 66 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

13

El sistema debe permitir el registro y consulta de diagnóstico: Registro de diagnóstico asociado al paciente, con codificación CIE-10.

14

El sistema debe permitir el ingreso y visualización, en forma centralizada, de todos los diagnósticos del paciente, utilizando codificaciones clínicas estandarizadas, tales como: CIE-10

15

El sistema debe disponer de listados de diagnósticos más frecuentes por usuario y/o especialidad.

16

El sistema debe permitir la agregación de atributos o propiedades al diagnóstico, tales como: Diagnóstico Principal, diagnóstico secundario.

17

El sistema debe permitir la identificación de estados o fases del diagnóstico, ej.: Observación, estudio, definitivo, vigente, etc.

18

El sistema debe contar con ayuda para la búsqueda de diagnóstico, sea por código o por descripción.

19

El sistema debe permitir que se resalten o marquen diagnósticos específicos, tales como: Enfermedades de notificación obligatoria y otros definidos por la institución, incluyendo notificación de eventos adversos

20

El sistema debe permitir la consignación de diagnósticos a los antecedentes del paciente.

21

El sistema debe permitir la generación de listados de diagnóstico por paciente y conjunto de pacientes y búsqueda de diagnóstico usando clasificación CIE-10.

22

El sistema debe permitir que se asocie una descripción detallada con narrativa al diagnóstico codificado de un paciente.

23

El sistema debe permitir que se realicen parametrizaciones de los datos como obligatorios para su diligenciamiento, así como gestionar (crear, actualizar, borrar y restringir por usuario) otros elementos de información clínica necesaria para el registro de salud del paciente.

24

El sistema debe permitir el registro de la Evolución Médica: Registro de tipo de evolución, gestión (registro, consulta y lectura según permisos) de diagnósticos por evolución, y datos generales de evolución.

25

El sistema debe permitir el registro y seguimiento de

CUMPLE

Página 67 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

procedimientos realizados, codificados con CUPS y CUM, registro de nuevos hallazgos y nuevos diagnósticos según procedimientos.

26

El sistema debe permitir la gestión de egreso de los pacientes: tipos de egreso, justificación, condiciones de salida, plan de manejo y visualización de órdenes generadas y realizadas.

27

El sistema debe permitir el manejo de epicrisis: Resumen completo de la atención clínica del paciente.

28

El sistema debe permitir la gestión de consentimiento informado y gestión de salida voluntaria para los pacientes de cada Institución.

29

El sistema debe permitir la gestión del CLAP (RED PERINATAL).

30

El sistema debe permitir la consulta de cada una de los componentes de la historia por especialidad, problemas y cronología.

31

El sistema debe permitir la asignación de roles y privilegios para el control de acceso a la historia, donde solamente el personal que presta la atención al paciente logre acceder a la historia.

32

El sistema debe permitir la gestión de datos e información ambulatoria.

33

El sistema debe permitir la gestión de datos e información quirúrgica

34

El sistema debe permitir la gestión de datos e información hospitalaria

35

El sistema debe permitir la impresión de brazalete para recién nacido, con identificación del bebé y de la madre.

36

El sistema debe permitir la gestión de los Registros Clínicos centrados en el paciente, permitiendo la concurrencia de varios especialistas de manera simultánea, identificando aquellos que participan en la atención del paciente.

37

El sistema debe permitir la generación de informes de la Historia Clínica en formatos variables que permita seleccionar, mediante filtros adecuados, eventos, episodios, exámenes y otros, por rango de fecha, tipo de patología, grupos de pacientes, entre otros definidos a la medida.

38

El sistema debe permitir la impresión de informes clínicos en Página 68 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

formatos flexibles y exportables a documentos de texto, planillas de cálculo y PDF. 39

El sistema debe permitir la incorporar de documentos escaneados en la Historia Clínica del paciente.

40

El sistema debe permitir la gestión integral de los datos del embarazo u otros, sean estos: atenciones ambulatorias, atenciones de urgencia, hospitalizaciones por cualquier causa, trabajo de parto.

41

El sistema debe permitir el registro de los otros profesionales de la salud y de la actividad docente-universitaria.

42

El sistema debe permitir la realización y emisión de informes estadísticos, con base a parámetros seleccionados por el usuario.

43

El sistema debe permitir el registro de la causa de la muerte con diagnóstico codificado.

44

El sistema debe permitir la generación del historial del paciente (médico, social y familiar); contando con la posibilidad de elegir diagnósticos que formen parte del historial médico.

45

El sistema deberá permitir la parametrización de la historia clínica de acuerdo a las necesidades de cada Institución, cumpliendo la normatividad.

46

El sistema deberá permitir la visualización de las Guías Prácticas Clínicas (GPC) de acuerdo con la patología de los pacientes.

A3.3.4. Urgencias.

NO.

1

CRITERIOS FUNCIONALES

CUMPLE

Clasificación de los pacientes con base en su grado de urgencia.

El Sistemas deberá permitir el registro ágil de un paciente y la información clínica de éste, con el objetivo de determinar la

Página 69 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

prioridad para su atención en el servicio de urgencias según la gravedad de su estado clínico.

2

El sistema debe permitir que al ingreso de cada paciente a la unidad de urgencias que lo atenderá, se registre toda la información contenida en los Formularios de Atención de Urgencia dispuesta por la Institución; así mismo dar acceso a la Historia Clínica Digital de cada paciente, incluyendo la atención del TRIAGE

3

El sistema deberá permitir el uso de listas de espera independientes para cada área: Pediátricas, Adulto, Obstetricia.

4

El sistema deberá permitir el registro de emergencia vital, especificando solicitud rápida de exámenes y prescripciones para cada paciente.

5

El sistema debe garantizar la no duplicación de pacientes en listas de espera de urgencias y en hospitalización.

6

El sistema deberá permitir el registro de datos de pacientes sin identificación, generando una notificación para regularizar posteriormente la situación de cada uno de ellos; para lograrlo, deberá asignar un código temporal de identificación al paciente que se atiende e indicar si existió una condición de identificación previa, y el código de la misma.

7

El sistema deberá contar con un esquema de priorización o categorización del paciente (TRIAGE) para la atención de urgencia.

8

El sistema deberá apropiar los siguientes niveles de clasificación: ● Rojo: Atención inmediata ● Amarillo: Situación de Urgencia con riesgo vital (Espera hasta 1 hora para su atención) ● Verde: No compromete la vida del paciente (Espera hasta 6 horas para su atención). Pacientes que presentan un problema de salud que no compromete su integridad; no es una urgencia. Incluye condiciones de riesgo que ameritan atención médica prioritaria, según lineamientos de la red a la que pertenece la Institución.

9

El sistema deberá indicar el tiempo máximo de espera para ser atendido luego de que se le haya realizado el TRIAGE.

10

El sistema debe destacar pacientes con períodos críticos de espera (tiempo definido de espera) según TRIAGE de priorización que se les haya aplicado.

Página 70 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

11

El sistema deberá contemplar diferentes áreas de atención de urgencia: Espera, unidad de atención, unidad de reanimación y salas de observación para las diferentes urgencias y procedimientos.

12

El sistema debe permitir la realización de traspasos entre diferentes atenciones (por ejemplo: Urgencia – hospital, observación – hospitalización, etc.), facilitando el registro de diagnósticos no médicos (enfermería y salud mental).

13

El sistema debe contabilizar (calcular y entregar) los tiempos (totales, parciales, medias y tendencias) de las atenciones de pacientes en urgencia: sala de espera, unidad de atención, unidad de reanimación y sala de observación.

14

El sistema debe permitir la integración con el módulo de Gestión de Camas y Pabellón del hospital.

15

El sistema debe permitir la generación en línea de solicitudes de medicamentos, procedimientos, vacunas, exámenes e indicaciones médicas; así como el acceso a protocolos de atención y diagnóstico.

16

El sistema debe generar registros de las atenciones por accidentes de tránsito, escolar, de trabajo u otros, entregando adicionalmente una estadística de los mismos.

17

El sistema debe permitir el ingreso de datos clínicos por parte de diferentes profesionales, debidamente registrados y autorizados.

18

El sistema debe mantener información del estado en que se encuentran las peticiones solicitadas al paciente en urgencias.

19

El sistema debe permitir la generación de formularios de Consentimiento Informado.

CUMPLE

A3.3.5. Historia Clínica Enfermería.

Página 71 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir la gestión de la historia clínica de enfermería, facilitando el registro de la atención y cuidado del paciente por parte del personal de Enfermería.

2

El sistema debe garantizar la integración natural de la información de historia clínica de enfermería con otros módulos y/o procesos tales como la generación de órdenes médicas, garantizando la disminución de errores por interpretación y mejor oportunidad en el cuidado de Enfermería según el tratamiento médico.

3

El sistema debe suministrar información gráfica de datos de monitoreo que facilite la interpretación del estado clínico del paciente en el tiempo y la conducta a tomar por parte del equipo médico.

4

El sistema debe garantizar la búsqueda ágil, oportuna y en línea de registros de Enfermería en la historia clínica.

5

El sistema debe contar con perfiles de seguridad y permisos de acceso de acuerdo con la necesidad de cada persona que requiera el ingreso a la historia.

6

El sistema debe contar con un esquema de control sobre órdenes médicas pendientes y cumplidas por cada paciente.

7

El sistema debe permitir la parametrización de horas de administración de medicamentos según los horarios definidos por la Institución.

8

El sistema debe permitir la visualización de históricos por turnos de enfermería según horarios que se manejen en la Institución

9

El sistema debe permitir la visualización de la Historia Clínica de diferentes maneras, por ejemplo: por paciente, grupos de pacientes, servicio clínico, episodios, y otros definidos por la institución.

10

El sistema debe permitir la visualización y gestión de diferentes listas de trabajo a través de diferentes filtros tales como: cuidados programados, exámenes, procedimientos, administración de medicamentos y dietas etc., sean estas indicadas por médicos y/o enfermeras.

11

El sistema debe permitir la gestión de solicitudes desde enfermería, mostrando el estado en que se encuentran las diferentes solicitudes de los pacientes a su cargo, por ejemplo: Laboratorio, anatomía patológica, imágenes, interconsultas, movilización, centros de sangre y otras.

CUMPLE

Página 72 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

12

El sistema debe permitir la visualización del reporte de camas ocupadas y disponibles, facilitando la gestión de camas según las necesidades del usuario.

13

El sistema debe permitir el registro de valoración por enfermería.

14

El sistema deberá permitir la parametrización de las pautas que debe tener en cuenta en la categorización de pacientes, según escalas de riesgo y otros estándares definidos por la Institución.

15

El sistema debe permitir la gestión de planes de cuidados propios; flexibles, definidos por el usuario y/o unidad clínica, coherente al modelo de cuidado de la Institución.

16

El sistema debe permitir la visualización de planes de cuidado haciendo uso de diferentes filtros.

17

El sistema debe permitir el ingreso de datos en formularios (definidos por la institución) que apunten a la seguridad del paciente, tales como consentimiento informado, registro de incidencias y otros.

18

El sistema debe permitir la gestión de tratamientos (crear y evolucionar tratamiento, realizar seguimiento, sesiones programadas/sesiones realizadas, inasistencias y postergaciones).

19

El sistema deberá permitir la visualización de los protocolos de enfermería de acuerdo con la patología de cada uno de los pacientes.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.3.6. Gestión de unidades quirúrgicas.

NO.

1

CRITERIOS FUNCIONALES

CUMPLE

El sistema debe permitir la gestión de la lista de espera quirúrgica (centralizada y gestionada de acuerdo a grupos y perfiles de usuarios definidos por el hospital o la red; ej: para sala de partos)

Página 73 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

2

El sistema debe contemplar en la solicitud de quirófano la identificación obligatoria: el profesional solicitante, la fecha de ingreso de la solicitud, fecha probable de intervención, identificación del paciente, diagnósticos, instrumental, equipamiento, equipos clínicos, tipo de quirófano, uso de filtros, entre otros.

3

El sistema debe permitir la actualización en línea de la lista de espera quirúrgica según intervenciones realizadas, considerando como mínimo, los motivos de salida o estados.

4

El sistema debe permitir la planificación de quirófanos, salas de parto y salas de parto integral por fecha, hora, tipo y especialidad.

5

El sistema debe permitir la planificación de tabla quirúrgica diaria, con acceso de acuerdo con el grupo de especialidades y perfil del usuario.

6

El sistema debe permitir el registro del personal que participó en el acto quirúrgico.

7

El sistema debe disponer de un gestor de solicitudes a esterilización, instrumental e insumos, registro de paquetes quirúrgicos de ropa y número de cajas del instrumental

8

El sistema debe proveer una solución al ingreso de datos del recién nacido, considerando partos múltiples, vínculo madrerecién nacido con flujo bidireccional de información para el manejo clínico y estadístico.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.3.7. Resultados de Laboratorio

NO.

CRITERIOS FUNCIONALES

1

El sistema debe proporcionar capacidad para recibir, almacenar y desplegar, en el registro clínico del paciente, valores discretos de resultados de laboratorio

2

El sistema deberá proporcionar la capacidad de mostrar resultados de diagnóstico complementarios de laboratorio.

CUMPLE

Página 74 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

3

El sistema deberá proporcionar la capacidad de mostrar resultados normales y anormales de diagnósticos complementarios.

4

El sistema deberá proporcionar la capacidad de, electrónicamente, recibir resultados de laboratorio clínico en un formato estructurado, y desplegar tales resultados en un formato legible.

5

El sistema deberá permitir el registro automático de los resultados de laboratorio clínico en la historia clínica del paciente.

6

El sistema deberá permitir la visualización de los resultados de laboratorio directamente a los pacientes vía web.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.3.8. Imágenes diagnósticas

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá proporcionar la capacidad de mostrar resultados de diagnóstico por imagen, permitiendo el acceso y visualización de imágenes biomédicas por paciente.

2

El sistema debe permitir la interoperabilidad con PACS (Picture Archiving System), la visualización de imágenes DICOM (Digital Imaging and Communication in Medicine) y conectividad total con el sistema RIS PACS, administrando los recursos disponibles (médicos, profesionales no médicos, equipos, insumos, unidad de atención, horarios de atención en diferentes formatos y listas de espera).

3

El sistema deberá permitir asignar en la historia clínica electrónica las imágenes biomédicas de un paciente.

4

El sistema deberá permitir la generación de listados cronológicos de las imágenes diagnósticas de un paciente y buscar por criterios específicos.

5

El sistema deberá permitir el registro de los resultados de la lectura de un estudio de imágenes o una imagen particular de un paciente, como parte de la historia clínica electrónica.

CUMPLE

Página 75 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

A3.3.9. Órdenes médicas

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá proporcionar la funcionalidad para gestionar órdenes a procedimientos o medicamentos con información suficiente para su consecución según el departamento asociado a la orden.

2

El sistema deberá proporcionar la funcionalidad para chequear potenciales interacciones entre medicamentos a ser ordenados y medicación actual, así como alertar al usuario al momento de generar la orden si existen potenciales interacciones.

3

El sistema deberá proporcionar la funcionalidad para registrar en la historia del paciente cada orden generada así mismo permitir la firma electrónica por el médico tratante para cada orden generada al paciente.

4

El sistema deberá proporcionar la funcionalidad para codificar las órdenes de procedimientos según la Clasificación Única de Procedimientos en Salud (CUPS).

5

El sistema deberá generar una lista de órdenes del paciente con acceso controlado para que tanto el personal médicoasistencial, relacionado con la atención, como los servicios que intervienen en la atención del paciente (radiología y laboratorio clínico) accedan a la lista de órdenes del paciente en tiempo real, especificando la información sobre las actividades pendientes de realizar.

6

El sistema deberá permitir realizar consultas, seguimiento y control de la orden u órdenes generadas a un paciente.

7

El sistema deberá proporcionar la funcionalidad para asignar estados y prioridades a las órdenes de los pacientes.

8

El sistema deberá permitir cancelar órdenes creadas, registrando su respectiva justificación, con fecha, hora, lugar y firma electrónica de quien ordena la cancelación; para esto, el usuario ejecutor deberá poseer un perfil especial que permita dicho procedimiento.

9

El sistema deberá proporcionar la funcionalidad para que las órdenes sean generadas por el médico tratante asignado u otro tipo de personal médico-asistencial asignado al paciente.

10

El sistema deberá permitir el registro de la fecha y hora de cada orden generada.

CUMPLE

Página 76 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

El sistema debe permitir el seguimiento de procedimiento (s) solicitado (s), ya sea de procesamiento interno o externo (a terceros) con "manejo de estados" y resultados.

11

A3.3.10. Gestión de relación médico-paciente

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá proporcionar la funcionalidad para mostrar y gestionar (asignar, actualizar y eliminar) las asignaciones de personal de atención o médico al paciente.

2

El sistema deberá proporcionar la funcionalidad para organizar y mostrar equipos de médicos o de atención y miembros individuales asignados al paciente.

3

El sistema deberá proporcionar la funcionalidad para que el personal médico-asistencial asignado al paciente pueda gestionar datos clínicos y ver información de los pacientes que le son asignados.

4

El sistema deberá proporcionar la funcionalidad para capturar y manejar, como elementos de datos discretos, la identificación de todos y cada uno de los integrantes del equipo médico-asistencial asignado al paciente.

CUMPLE

A3.3.11. Seguimiento de Pacientes

NO.

1

CRITERIOS FUNCIONALES

CUMPLE

El sistema deberá proporcionar una funcionalidad para gestionar y mostrar el estado de cuidado del paciente (esperando por médico, admitido, en espera, esperando enfermera, esperando consulta, en camino a departamento,

Página 77 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

etc.).

2

El sistema deberá proporcionar una funcionalidad para presentar una alerta cuando el estado del paciente ha excedido el marco de tiempo definido en el sistema para dicho estado.

3

El sistema deberá proporcionar una funcionalidad para identificar la ubicación física de los pacientes o un paciente específico en urgencias, incluyendo la fecha y hora de acceso del paciente a esa ubicación 4

El sistema deberá proporcionar una funcionalidad para gestionar la reubicación de pacientes en urgencias y desplegar las correcciones de ubicación del paciente.

5

El sistema deberá proporcionar una funcionalidad para gestionar y mostrar múltiples pacientes que están siendo atendidos simultáneamente en una habitación o espacio identificado.

6

El sistema deberá proporcionar una funcionalidad para gestionar camas ad-hoc y la gestión de pacientes en estas camas temporales.

7

Opciones de búsqueda rápida a través de distintos parámetros que identifiquen al paciente: número de identificación nacional, nombre, apellido, número de historia clínica.

A3.3.12. Pacientes y gestión de camas, Referencia y contra–referencia

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá proporcionar una funcionalidad para mostrar todos los pacientes actuales así como las habitaciones o espacios de atención vacíos.

2

El sistema deberá proporcionar una funcionalidad para mostrar los pacientes pendientes o en espera de TRIAGE, asignación a hospitalización o pendientes de reubicación.

CUMPLE

Página 78 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

3

El sistema deberá proporcionar una funcionalidad para mostrar pacientes que estén esperando a ser registrados.

4

El sistema deberá proporcionar una funcionalidad para mostrar los tiempos de espera de pacientes aún no han sido llevados al área de tratamiento.

5

El sistema deberá proporcionar una funcionalidad para mostrar los pacientes que han sido admitidos a hospitalización pero aún permanecen en urgencias.

6

El sistema deberá proporcionar una funcionalidad para mostrar información disponible de los pacientes que llegarán, que han sido remitidos desde otras instituciones.

7

El sistema deberá permitir gestionar toda la información necesaria para el proceso de referencia y contrareferencia entre hospitales.

8

El sistema deberá proporcionar información de la disponibilidad de camas y especialización para el proceso de referencia y contrareferencia.

9

El sistema debe contar con acceso fácil y rápido a listas de camas ocupadas y disponibles.

10

El sistema debe tener interfaz gráfica o un mapa de camas, libres y ocupadas, por sectores y por toda la institución.

11

El sistema debe contar con acceso y búsqueda eficiente y directa, desde el mapa de camas, a la historia clínica del paciente, según perfiles de acceso.

12

El sistema debe permitir la generación del listado de camas ocupadas, considerando: Nombre del paciente y diagnóstico, N° de cama y sector (definidos por la institución) y tiempo estimado de liberación, integrando la Categorización Riesgo/Dependencia.

13

El sistema debe permitir el seguimiento a los movimientos realizado al paciente (trazabilidad).

14

El sistema debe permitir diferentes "estados" o atributos de las camas, ejemplo: Libre, en reserva, en reparación, bloqueada, pre alta, etc.

15

El sistema debe disponer de una lista de pacientes con indicación de hospitalización y de espera de camas.

16

El sistema debe permitir la generación de listados de camas utilizando diferentes filtros, ej.: rango de fechas, por sectores,

CUMPLE

Página 79 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

por estados o atributos de las camas.

A3.3.13. Instrucciones de alta

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá permitir el registro de las indicaciones o plan de alta para cada paciente teniendo en cuenta las diferentes especialidades tratantes.

2

El sistema deberá permitir la captura de las indicaciones de alta dadas al paciente o referenciar documentos que contienen dichas indicaciones.

3

El sistema deberá incluir en los instructivos de alta detalles de cuidado adicional tales como seguimiento, visitas y tiempo apropiado de cuidado adicional.

4

El sistema deberá permitir la edición de instrucciones de alta para un paciente en particular; esta actividad la deberá realizar el profesional tratante.

CUMPLE

A3.3.14. Registro de alergias y reacciones adversas

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá capturar, mantener, modificar y mostrar como datos discretos, el listado de medicamentos y otros agentes con los cuales el paciente ha tenido eventos alérgicos u otras reacciones adversas.

2

El sistema deberá que se especifique el tipo de reacción alérgica o adversa en un campo discreto.

CUMPLE

Página 80 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

3

El sistema deberá permitir que se indique explícitamente, en un campo discreto, que un paciente no ha sufrido o no conoce que haya sufrido reacciones adversas o alergias a medicamentos.

4

El sistema deberá capturar y mantener, como dato discreto, la razón por la cual se inactiva, modifica o remueve un elemento de la lista de alergias y reacciones adversas.

5

El sistema deberá capturar y mantener, como dato discreto, la identidad del usuario que agregó, modificó, inactivó o removió elementos de la lista de alergias y reacciones adversas de un paciente, incluyendo los atributos del elemento cambiado; en este sentido deberá conservar el id del usuario, la fecha y hora de la gestión que efectuó.

6

El sistema deberá registrar los usuarios que explícitamente indicaron que la lista de alergias fue revisada, conservando la fecha y hora en que se hizo uso de la opción de revisado de alergias.

7

El sistema deberá proporcionar un mecanismo para registrar la fuente de la información de la alergia.

8

El sistema deberá mostrar la lista de alergias (por paciente o grupo de ellos), incluyendo fecha y tiempo de registro.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.3.15. Gestión de Medicamentos

NO.

1

CRITERIOS FUNCIONALES

CUMPLE

El sistema debe contar con un esquema de alertas en la administración de medicamentos.

2

El sistema debe permitir la verificación, en el Kardex electrónico (programación de medicamentos) de enfermería, de los medicamentos vigentes (no cancelados ni terminados) que tiene formulado un paciente.

3

El sistema debe permitir la lectura e identificación del medicamento que tenga que administrarse a cada paciente.

Página 81 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

4

El sistema debe permitir la verificación de que el medicamento registrado se encuentre en la programación de medicamentos del paciente.

5

El sistema debe permitir la confirmación de la administración del medicamento en el módulo de Enfermería.

6

El sistema debe permitir la generación de una alarma cuando el medicamento leído no esté en la programación de ese paciente; además, debe guardar un registro de esta alerta con el objetivo de tener información de intentos de administración equivocada.

7

El sistema debe permitir la visualización de la existencia de inventario farmacéutico de la Institución. La búsqueda de medicamento debe poder realizarse por: principio activo, nombre comercial, grupo terapéutico, forma farmacéutica o por prescripciones favoritas o frecuentes asociadas a perfil y/o usuario.

8

El sistema debe permitir la integración con Farmacia, facilitando la reposición de medicamentos e insumos para su facturación y costeo, incluyendo un sistema móvil de dispensación.

9

El sistema debe permitir la generación de alertas al clínico ante la falta de stock de medicamentos.

10

El sistema debe permitir la gestión de prescripciones de medicamentos que requieran de autorizaciones especiales según haya sido definido por parte de la Institución.

11

El sistema debe permitir el manejo de distintos tipos de prescripciones: simples, infusiones o soluciones, micro dosis, estupefacientes, restringidos, por protocolos, etc.

12

El sistema debe generar propuestas de horarios, frecuencias y periodos de administración de medicamentos.

13

El sistema debe permitir el manejo de diferentes vías de administración e informar precauciones de administración (modo, velocidad, diluyentes recomendados e incompatibles).

14

El sistema debe permitir la suspensión, término y/o modificación de la prescripción de acuerdo con indicaciones del médico tratante.

15

El sistema debe permitir la prescripción automática de un plan de tratamiento fármaco-terapéutico por un periodo de tiempo definido en pacientes crónicos (recetas de pacientes

CUMPLE

Página 82 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

crónicos)

16

El sistema debe contar con esquema móvil de captación electrónica de datos para la administración con código de barras (y opcionalmente con tecnología RFID) que considere la identificación del medicamento, del paciente y del administrador, asegurando la trazabilidad del proceso.

17

El sistema debe permitir realizar ajustes, por parte de enfermería, de horarios de adecuación de prescripción.

18

El sistema debe permitir que en el registro de administraciones se contemple: paciente, medicamento, dosis, vía, lugar anatómico de administración, fecha, hora y quién lo administró.

19

El sistema debe permitir el acceso al perfil farmacológico del paciente.

A3.3.16. Odontología

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá proporcionar una funcionalidad para gestionar los registros de odontología asociados a un paciente (registro odontológico electrónico completo), permitiendo generar notas clínicas de su evolución.

2

El sistema deberá proporcionar una funcionalidad para incorporar modelos específicos de historia clínica odontológica de los pacientes.

3

El sistema debe permitir el registro de hallazgos en cada una de las piezas dentales, parcial o totalmente, y en toda la boca.

Esta información se debe visualizar, en forma gráfica a través del odontograma, así como en forma de listado descriptivo con las convenciones institucionales

4

El sistema debe permitir que una vez realizado el examen dental o diagnóstico odontológico, se lleve a cabo el registro de trabajos en cada una de las piezas dentales, parcial o totalmente, y el de trabajos realizados en toda la boca. Esta

CUMPLE

Página 83 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

información se debe visualizar, en forma gráfica a través del odontograma, así como en forma de listado descriptivo.

5

El sistema debe generar de manera automática los RIPS de los servicios realizados.

6

El sistema debe permitir registrar cada una de las actividades del tratamiento dental, obtener las tarifas vigentes y elaborar el presupuesto para ser acordado con el paciente.

7

El sistema debe permitir que se actualice el presupuesto ejecutado y la cuenta del paciente, a medida que se van registrando las actividades odontológicas ejecutadas, las consultas y tratamientos realizados.

8

El sistema debe permitir modificaciones al examen dental y al tratamiento inicialmente acordado, manteniendo registro de las adiciones, anulaciones, repeticiones y solicitando justificación al profesional clínico cada vez que ejecute una de estas actividades.

9

El sistema debe permitir la realización de consultas de cada una de las notas odontológicas y cada uno de los registros de examen dental y evolución del tratamiento dental de un paciente, en forma cronológica; la consulta debe contar con filtros por rangos de fechas y tipos de notas.

10

El sistema debe permitir la realización de consultas de odontogramas y notas asistenciales, de tratamientos ya cerrados o suspendidos.

11

El sistema debe permitir la captura y presentación de la información a través de diagramas gráficos: odontogramas, periodontogramas, diagramas de prótesis, diagramas de higiene y ortogramas. Estos diagramas darán cuenta de atenciones programadas, realizadas y pendientes, con control de las diferentes etapas de tratamiento (Presupuesto - En tratamiento - Finalizado y/o Alta); totalmente configurable por el usuario (Estados, colores, características).

12

El sistema debe permitir la integración del módulo de odontología con el módulo de facturación.

13

El sistema debe permitir la prescripción y administración de medicamentos.

14

El sistema debe permitir la visualización de imágenes precargadas. Cuando sea necesario, deberá poder interactuar con el RIS-PACS integrando los equipos de rayos intraoral y ortopantomógrafo y todas sus funciones asociadas.

Página 84 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

El sistema debe permitir la referencia de pacientes intra y extra-institucionalmente así como anotar la contrareferencia.

15

A3.3.17. Nutrición y Dietas

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá proporcionar una funcionalidad para generar dietas específicas por paciente, así como ejercer un control sobre cada una de ellas durante la estancia del paciente en la Institución, determinando periodos y estados a dichas dietas; así mismo generar los resúmenes de dietas por paciente.

2

El sistema debe permitir la prescripción de dietas habituales y/o personalizadas para pacientes especiales o que requieran de suplementos, medicamentos, texturas especiales teniendo presente las alertas de seguridad con relación a antecedentes alérgicos.

3

El sistema debe permitir la gestión de nutriciones parenterales y lácteas complejas.

4

El sistema debe permitir que se prescriban dietas distintas dentro de las 24 horas, por ejemplo: realimentación post operatoria.

5

El sistema debe permitir que se prescriban dietas lácteas; considerando el manejo de diferentes tipos de fórmulas lácteas, cambios frecuentes de indicaciones, diferentes volúmenes, incorporación de nutrientes o medicamentos adicionales a la formula.

6

El sistema debe permitir la realización de validaciones y/o modificaciones a la prescripción según perfiles, por ejemplo ajuste de la dieta realizada por Nutricionista.

7

El sistema debe permitir la gestión de dietas: Consultar acerca de las dietas prescritas por paciente y por Unidad.

8

El sistema debe permitir el registro del control de ingesta: registrar el consumo de la alimentación, reacciones alérgicas

CUMPLE

Página 85 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

y otras observaciones generales, así como, el seguimiento nutricional del paciente.

9

El sistema debe permitir el registro del consumo de alimentación mediante balance hídrico nutricional

10

El sistema debe permitir seguimiento nutricional del paciente: oral, parenteral, enteral y lactantes.

11

El sistema debe permitir la generación de solicitudes de insumos a bodega con base a preparaciones por turno, días, semanas.

A3.3.18. Promoción y Prevención

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá proporcionar una funcionalidad para crear, administrar y hacer seguimiento a programas de promoción y prevención de cada Institución registrada en el sistema.

2

El sistema deberá permitir la creación de actividades de Protección específica y Detección temprana (PyD) a realizar en periodos específicos, definiendo los diferentes ciclos para su ejecución y teniendo en cuenta lo siguiente: - Generar todos los formatos de Historia Clínica de P y P con las variables exigidas en las normas técnicas contenidas en la resolución 412 de 2000 o aquellas que la complementen y/o modifiquen, - Consulta de detección para alteraciones del crecimiento y desarrollo, - Consulta de detección temprana de alteraciones en menores de 10 años, - Consulta de detección de alteraciones en jóvenes de 10 a 26 años para el FFD y de 10 a 29 años para ARS, - Consulta de detección de alteraciones en el adulto de 27 a 44 años para el FFD, - Consulta de detección para la detección de alteraciones del adulto mayor de 45 años, - Consulta de primera vez y control de planificación familiar, - Toma y entrega de citología Cervico vaginal,

CUMPLE

Página 86 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

- Actividades educativas y asesorías, - Generar el conjunto mínimo básico tanto de laboratorios

-

como de consulta a otras actividades en P y P (Inducción de la demanda) según los grupos etéreos, que permita mediante validación visualizar cuando se haya realizado una actividad de P y P y la fecha de acuerdo a las frecuencias de uso contempladas en las matrices de programación de P y P por pagador, Igualmente permitiendo la gestión de gráficos de referencia.

3

El sistema deberá incorporar los modelos de PyP según normatividad y de acuerdo con los portafolios manejados por la Institución para este fin.

4

El sistema deberá permitir la generación de reportes y gráficos de las diferentes variables relacionadas con la norma, contando con las tablas de evaluación de desarrollo o las que sirvan de referencia para la mejor interpretación y análisis de los resultados.

A3.3.19. Epidemiología

NO.

CRITERIOS FUNCIONALES

CUMPLE

El sistema deberá proporcionar una funcionalidad para gestionar la información requerida por los sistemas de vigilancia de salud pública según se establezca en la reglamentación (ej. decreto 3518 de 2006).

1

A3.3.20. Gestión de información de Territorios

NO.

1

CRITERIOS FUNCIONALES

CUMPLE

El sistema deberá proporcionar una funcionalidad para Página 87 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

acceder desde dispositivos móviles, teniendo en cuenta los permisos, para consulta y registro de información clínica y de atención básica en territorios por parte de los ERI (Equipos de Respuesta Inicial: Médicos, Enfermeras, Promotores) y ERC (Equipo de Respuesta Complementaria: Nutricionista, Odontólogos, fisioterapeutas, psicólogos, salud ocupacional, higienista oral), según modelo regional de salud en los territorios.

A3.3.21. Gestión de seguridad del paciente

NO.

CRITERIOS FUNCIONALES

CUMPLE

El sistema deberá incorporar mecanismos automáticos que garanticen la seguridad del paciente en el proceso asistencial, cumpliendo con las normas legales y políticas de seguridad del paciente aplicables en la República de Colombia.

1

A3.3.22. Auditoría

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá proporcionar una funcionalidad para controlar y monitorear los registros clínicos, demográficos y el proceso transaccional con el fin de registrar errores, excepciones y hacer seguimiento que ayuden a generar soluciones específicas.

2

El sistema deberá permitir al administrador definir la inclusión o exclusión de eventos auditables, basado en las políticas de la Institución y de operación.

CUMPLE

Página 88 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

3

El sistema deberá permitir registrar para cada uno de los registros de auditoría la fecha y hora del evento, el componente del sistema donde ocurrió el evento, tipo de evento incluido la descripción del dato y el identificador del paciente de ser relevante, identidad del usuario que generó el evento y el resultado del evento especificando si falló o fue exitoso.

4

El sistema deberá permitir la lectura de las bitácoras de registros auditados y generar reportes por criterios específicos según lo registrado, incluyendo rangos de fechas, así como exportar dichos reportes para su análisis.

5

El sistema debe contar con un historial de modificaciones que permita la auditoria de los registros clínicos.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.3.23. Generación Plantillas

NO.

CRITERIOS FUNCIONALES

CUMPLE

El sistema deberá permitir que se creen plantillas de contenido estructurado a la medida, en cualquiera de sus componentes; facilitando, además, la creación de formularios parametrizables para las especialidades médicas, odontológicas y de otros profesionales, que pueden contener escalas o cálculos matemáticos, con validaciones y mensajes de alerta que estén a disposición del usuario.

1

A3.3.24. Gestión documental

NO.

1

CRITERIOS FUNCIONALES

CUMPLE

El sistema deberá permitir la gestión de documentos, anexos Página 89 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

clínicos, relacionados con el paciente.

A3.3.25. Sistemas Auxiliares LIS, RIS, PHIS

NO.

CRITERIOS FUNCIONALES

CUMPLE

El Sistema deberá proporcionar una funcionalidad para interoperar o incorporar sistemas auxiliares tales como: Laboratorio (LIS), Radiología (RIS), Farmacia (PHIS), Enfermedades de notificación obligatoria y otros.

1

A3.4. Funcionalidades Requeridas para la Operación General del Sistema A3.4.1. Control de Acceso

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá proporcionar una funcionalidad para gestionar (crear, recuperar, actualizar y eliminar) usuarios del sistema.

2

El sistema deberá proporcionar una funcionalidad para gestionar roles y privilegios a los roles.

3

El sistema deberá tener métodos de autenticación y autorización que determinen el nivel acceso a funcionalidades específicas asignadas a los roles.

4

El sistema deberá permitir la asignación de restricciones o privilegios a usuarios, grupos de usuarios o roles.

5

El sistema deberá proporcionar una funcionalidad para

CUMPLE

Página 90 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

asociar permisos del tipo: ● Basado-en-usuario: donde los permisos de acceso se asignan a cada usuario ● Basado-en-rol: Usuarios agrupados bajo un rol específico y los permisos asignados a dichos grupo. ● Basado-en-contexto: extensión de control de acceso basado-en-rol con permisos adicionales basado en el contexto de la transacción tal como tiempo del día, ubicación de estación de trabajo, modo de emergencia, entre otros definidos por el administrador. ● El sistema deberá permitir remover usuarios (borrando sus privilegios) sin eliminar la información histórica relacionada con ese usuario en el sistema.

6

El sistema debe permitir el acceso diferenciado a los diferentes módulos, de acuerdo a la calificación del usuario.

7

El sistema debe contar con niveles de seguridad diferenciados que resguarden la confidencialidad de los datos del paciente, cumplan con las normas y leyes sobre confidencialidad de datos sensibles, protección de datos personales y firma electrónica.

8

El sistema debe contar con esquemas de encriptación en el envío y recepción de los datos.

A3.4.2. Seguridad de acceso

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá contar con mecanismos de autenticación de los usuarios al momento en que estos quieran acceder al mismo.

2

El sistema deberá contar con mecanismos para crear reglas que deben tenerse en cuenta en la generación de contraseñas fuertes, ej. incluir caracteres alfanuméricos, caracteres especiales, con un número mínimo de dígitos parametrizable

3

El sistema deberá contar con mecanismos que realicen el control de sesiones de trabajo y el cierre de éstas en el

CUMPLE

Página 91 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

momento en que se superen los periodos de inactividad previamente definidos y parametrizados por el administrador.

4

El sistema deberá configurar un número límite de intentos de autenticación por un usuario, y prevenir diversos intentos maliciosos a través de mecanismos de inactivación de usuario u otros algoritmos de periodos de inactividad.

5

El sistema deberá proporcionar un mecanismo de regeneración de contraseñas a los usuarios, no recuperando la contraseña creada, sino generando una nueva y cifrándola para su almacenamiento en el sistema.

6

El administrador tendrá la posibilidad de regenerar contraseñas de usuario; éstas deberán usar estándares de inscripción no reversible para su almacenamiento en el sistema.

A3.4.3. Usabilidad y Movilidad

NO.

CRITERIOS FUNCIONALES

1

El sistema deberá contar con una interfaz gráfica de usuario acorde a tamaños y tipos de pantalla que hagan uso de él.

2

El sistema deberá contemplar el acceso desde dispositivos móviles inalámbricos (Tablet PC, teléfonos móviles) para operar con las diversas funcionalidades clínico-asistenciales.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.4.4. Presentación

NO.

1

CRITERIOS FUNCIONALES

CUMPLE

El sistema debe operar en una plataforma en la nube (web) y en consecuencia los usuarios deben poder acceder a ella desde los navegadores que tengan en sus equipos sin

Página 92 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

necesidad de un software instalado localmente.

2

El sistema debe operar en los navegadores con mayor difusión comercial (ej. Internet Explorer, Edge, Chrome, Safari y Firefox, etc.)

3

El sistema deberá permitir el acceso desde dispositivos móviles.

4

El sistema debe permitir la visualización de la lista de tareas pendientes que tiene el usuario que se conectó y luego de que éste ingrese las credenciales de acceso.

5

El sistema debe permitir el acceso desde la página de inicio a los procesos de contratación activos, alertas, búsqueda avanzada, panel de ayuda y menú de configuración para cada tipo de usuario.

6

El sistema debe permitir administrar las tablas maestras y listas de valores por parte del administrador en cada institución (modalidades de contratación, Clasificador de Bienes y Servicios, etc.).

A3.4.5. Búsqueda

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir ordenar los resultados de las búsquedas por diferentes criterios y utilizar filtros en los resultados.

2

El sistema debe permitir la generación de búsquedas a los usuarios de acuerdo con el perfil que tengan asignados.

3

El sistema debe permitir búsquedas que hagan uso de jerarquías, navegando a través de éstas.

CUMPLE

A3.4.6. Base de Datos

Página 93 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir la implementación de controles que impidan a los usuarios con privilegios modificar la información almacenada en la base de datos.

2

El sistema debe restringir el acceso de los administradores de bases de datos (DBA) a la información clasificada almacenado en él.

3

El sistema debe permitir limitar el acceso a las bases de datos desde las herramientas y usuarios autorizados y en horarios específicos.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.4.7. Respaldo de Datos

NO.

CRITERIOS FUNCIONALES

1

El sistema debe contar con mecanismos de respaldo de todos los datos almacenados por los usuarios (teniendo en cuenta todos los niveles de la arquitectura que lo conforman).

2

El sistema debe permitir a los usuarios recuperar su información ante una pérdida de datos.

3

El sistema debe ofrecer mecanismos para evitar la eliminación o borrado de información en la base de datos, garantizando que los datos nunca sean eliminados físicamente, sino marcados como inactivos.

4

El sistema debe permitir configurar periódicamente tareas de eliminación de datos inactivos en la base de datos.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.4.8. Conexión a la Base de Datos

NO.

1

CRITERIOS FUNCIONALES

CUMPLE

El sistema debe permitir la conexión de herramientas de

Página 94 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

inteligencia de negocio de otros fabricantes.

2

El sistema debe permitir el acceso a la base de datos para realizar la extracción, transformación y carga de datos.

3

El sistema debe permitir que se realicen procesos de importación/exportación de datos de forma masiva.

A3.4.9. Integración - Estándares

NO.

CRITERIOS FUNCIONALES

1

El sistema debe estar basado en una arquitectura abierta, segura y orientada a servicios (Service Oriented Architecture –SOA).

2

El sistema debe permitir el uso de los estándares XML, ebXML, SOAP, REST, ROSETANET para el intercambio de información estructurada con otros sistemas de información.

3

El sistema debe soportar los estándares de interoperabilidad WS-Reliable Messaging, WSPolicy, WS-Trust y WS-Metadata Exchange.

CUMPLE

A3.4.10. Integración – Arquitectura de Integración

NO.

CRITERIOS FUNCIONALES

1

El sistema debe incorporar funcionalidades que permitan coordinar los servicios de la capa de integración.

2

El sistema debe contar con un diseño que debe estar basado en capas, para facilitar la separación del portal de visualización de la capa de servicios de integración.

3

El sistema debe incluir un catálogo con información de cada contrato de servicio web (web service contract) y la

CUMPLE

Página 95 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

descripción de cada componente funcional.

4

El sistema debe proporcionar un mecanismo de colas que garantice transacciones completas de tipo ACID (Atómicas, Consistentes, Aisladas y Durables).

5

El sistema debe permitir la utilización protocolos de comunicación SOAP-HTPP y SOAPMessage Queues.

6

El sistema debe permitir la integración con otros sistemas de información utilizando diferentes tipos de fuentes de datos.

7

El sistema debe ofrecer un esquema de monitoreo para el uso de los servicios de integración expuestos.

A3.4.11. Comunicación, interacción de servicios de integración

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir la orquestación de procesos de negocio utilizando el lenguaje BPEL.

2

El sistema debe permitir la configuración de servicios de integración con sus respectivos mensajes de petición y respuesta.

3

El sistema debe soportar la comunicación utilizando los protocolos JDBC, JMS, FTP, SMTP, POP3, IMAP4, HTTP, SOAP.

4

El sistema debe soportar estilos de mensajería de un solo sentido, de solicitud-respuesta y pubsub.

5

El sistema debe tener un enrutador de los mensajes al proveedor de servicio de integración correspondiente.

6

El sistema debe permitir la transformación entre formatos de protocolo como SOAP/HTTP, SOAP/Message Queue o SOAP/JMS.

7

El sistema debe tener la capacidad de almacenar y reenviar mensajes en una cola.

8

El sistema debe soportar los estándares de servicios web WS-

CUMPLE

Página 96 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

BPEL, WS-Coordination, WSBusinessActivity, WS-CDL, WSNotification, y WS-RF.

A3.4.12. Procesamiento de mensajes

NO.

CRITERIOS FUNCIONALES

1

El sistema debe incluir un componente o motor de reglas de negocio para orquestar los servicios de integración.

2

El sistema debe permitir la transformación entre formatos de datos propietarios y formatos de datos canónicos.

3

El sistema debe permitir la transformación de formatos de datos a partir de mapeo semántico o mapeo de posición de datos.

4

El sistema debe permitir la validación los mensajes recibidos.

5

El sistema debe proporcionar un mecanismo de estructuración semántica de datos basado en estándares abiertos.

6

El sistema debe soportar la capacidad de agregar diferentes servicios y proveedores de servicios de integración en un único formato canónico (mensajes y datos).

7

El sistema debe tener la capacidad de difundir los eventos desde los productores hasta los consumidores de servicios de integración (event broker).

CUMPLE

A3.4.13. Calidad de servicio

NO.

1

CRITERIOS FUNCIONALES

CUMPLE

El sistema debe permitir la validación de la ejecución de Página 97 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

transacciones del servicio de integración.

El sistema debe controlar las excepciones planteadas en el proceso de consumo del servicio de integración y el paso de mensajes.

2

A3.4.14. Seguridad y administración en interoperabilidad

NO.

CRITERIOS FUNCIONALES

1

El sistema debe soportar diferentes niveles de servicio en la respuesta de los servicios de integración.

2

El sistema debe soportar el protocolo WS-Security para la firma y cifrado de mensajes SOAP.

3

El sistema debe permitir autenticar y autorizar el consumo de servicios de integración (service invocation).

4

El sistema debe permitir la captura y el registro de enrutamiento de mensajes y llevar un registro histórico del consumo de servicios de integración con estampa de tiempo.

5

El sistema debe permitir el seguimiento y monitoreo del enrutamiento de mensajes y actividades de consumo de servicios de integración desde una consola única de monitoreo.

6

El sistema debe tener un sistema de monitoreo del desempeño del procesamiento de los mensajes.

7

El sistema debe permitir la trazabilidad del contenido de los mensajes intercambiados y la búsqueda por parte de los usuarios.

8

El sistema debe permitir la búsqueda de mensajes a partir de palabras clave del contenido (payload).

9

El sistema debe permitir la configuración de alertas.

10

El sistema debe permitir el monitoreo proactivo de las actividades de intercambio de mensajes.

CUMPLE

Página 98 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

11

El sistema debe permitir la conexión vía VPN con otros sistemas de información utilizando diferentes sistemas operativos (Linux, UNIX based, Windows) y cifrado SSL.

12

El sistema debe permitir la conexión con otros sistemas de información a través de autenticación de firewall utilizando múltiples puertos (80, 443, etc).

13

El sistema debe permitir el consumo de servicios web de plataformas externas utilizando certificados digitales y transmisión de tokens.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.4.15. Gobernabilidad

NO.

CRITERIOS FUNCIONALES

1

El sistema debe incorporar mecanismos de gobernabilidad que permitan validar la calidad de los datos de integración y el intercambio de datos.

2

El sistema debe ofrecer un proceso de registro de servicios de integración en un repositorio.

3

El sistema debe permitir el descubrimiento de servicios de integración del repositorio utilizando un mecanismo estándar.

4

El sistema debe permitir la configuración de reglas de negocio sobre el proceso de consumo de servicios de integración.

5

El sistema debe permitir el monitoreo de indicadores definidos sobre la capa de integración en una consola única de monitoreo.

CUMPLE

A3.4.16. Seguridad de la Información

NO.

CRITERIOS FUNCIONALES

CUMPLE

Página 99 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

1

El sistema debe estar protegido de acuerdo con la versión vigente del estándar ISO 27001 de seguridad de la información.

2

El sistema debe incluir los elementos de seguridad que permitan garantizar su confiabilidad a los usuarios.

3

El sistema debe incluir mecanismos y herramientas de protección frente a ataques electrónicos como hacking, denegación del servicio o introducción de software malicioso.

4

El sistema debe permitir la búsqueda de virus en todos los documentos que intenten al momento de ser cargados y rechazar documentos que contengan virus.

5

El sistema debe cumplir con el principio de protección de datos personales de la Ley Estatutaria 1581 de 2012 del Estado colombiano y su reglamentación.

A3.4.17. Confidencialidad, integridad y disponibilidad

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir el intercambio de datos únicamente entre usuarios autorizados.

2

El sistema debe garantizar que el intercambio de datos con y entre los usuarios utilice protocolos seguros como HTTPS.

3

El sistema debe garantizar que el intercambio de datos con otros sistemas de información utilice protocolos de encripción de datos.

4

El sistema debe garantizar que los datos intercambiados entre los usuarios no puedan ser alterados o modificados por usuarios no autorizados.

5

El sistema debe garantizar que el 100% de las cargas y transferencias de datos se realizan bajo el control de la capa de aplicación, con la apropiada lógica y restricciones del sistema.

6

El sistema debe incluir mecanismos para garantizar la integridad de la información y realizar la recuperación en caso de presentarse algún incidente.

7

El sistema debe incluir mecanismos para evitar ataques de negación de servicio, detección de intrusos y continuidad del servicio.

CUMPLE

Página 100 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.4.18. Autenticación

NO.

CRITERIOS FUNCIONALES

1

El sistema debe incluir una consola que permita la administración centralizada de políticas de acceso para todos los usuarios.

2

El sistema debe permitir el almacenamiento de las contraseñas utilizando algoritmos de encripción estándar de la industria como DES, 3DES, entre otros.

3

El sistema debe permitir la configuración de políticas restrictivas de contraseñas, como histórico de contraseña, validez, longitud, intentos antes de bloqueo y caracteres.

4

El sistema debe asignar una contraseña aleatoria a los nuevos usuarios y exigir su cambio al iniciar sesión por primera vez o permitir a los usuarios definir la contraseña en el registro inicial.

5

El sistema debe permitir la configuración del número máximo de conexiones activas por usuario, la duración máxima de la sesión y el bloqueo por inactividad.

6

El sistema debe permitir la configuración del número de intentos de ingreso fallidos a partir del cual se bloquea el acceso a un usuario.

7

El sistema debe llevar un registro histórico de la hora inicial y final de cada sesión de usuario.

8

El sistema debe ofrecer a los usuarios un sistema de autoservicio que permita recuperar o restablecer las contraseñas de manera segura.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.4.19. Autorización

NO.

CRITERIOS FUNCIONALES

1

El sistema debe garantizar que solamente el personal autorizado puede obtener acceso a las herramientas, datos o información.

2

El sistema debe permitir configurar en cada Módulo diferentes

CUMPLE

Página 101 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

CRITERIOS FUNCIONALES

niveles de autorización (acceso, lectura, modificación, administración, auditoría).

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

escritura,

3

El sistema debe permitir configurar niveles de autorización por usuario, grupo o perfil.

4

El sistema debe soportar los estándares de autorización XACML y SAML.

5

El sistema debe restringir a los administradores la posibilidad de deshabilitar los controles de autorización y acceso definidos para su tipo de usuario.

A3.4.20. Auditoría general del Sistema

NO.

CRITERIOS FUNCIONALES

1

El sistema debe mantener una bitácora que permita generar trazas de auditoría consultables desde una consola central.

2

El sistema debe permitir el control detallado de las actividades y transacciones que se realizan por parte de los usuarios, incluyendo administradores.

3

El sistema debe permitir el acceso a los datos dentro del repositorio de auditoría solamente a los usuarios autorizados.

4

El sistema debe garantizar que el acceso y la modificación de los datos y las trazas de auditoria están a cargo de los usuarios de auditoría, no debe permitirse a los usuarios administradores o usuarios privilegiados acceso a esta información.

5

El sistema debe registrar los usuarios no autorizados que intenten acceder a él.

6

El sistema debe permitir que se configure el registro de trazas de acceso a la información.

7

El sistema debe incluir mecanismos de estampado de tiempo (time-stamping) para las actividades y transacciones que lo requieran.

CUMPLE

Página 102 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

CRITERIOS FUNCIONALES

8

El sistema debe notificar al usuario la ejecución exitosa o fallida de todas las transacciones que realice.

9

El sistema debe ofrecer resúmenes gráficos de las actividades que generen alertas.

10

El sistema debe permitir la identificación de la dirección IP del dispositivo desde el cual se realicen las transacciones.

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.4.21. Firma electrónica

NO.

CRITERIOS FUNCIONALES

1

El sistema debe permitir el uso de firmas digitales y electrónicas, certificados de autenticación para identificar al usuario firmante de los documentos enviados o diligenciados.

2

El sistema debe permitir el uso de firmas electrónicas y certificados digitales que soporten infraestructura de clave pública (PKI) que incluyan esquemas de verificación, autenticación y autorización.

3

El sistema debe permitir la generación de un código hash en cada documento cargado, para asegurar la integridad, el no repudio y la autenticidad del origen del documento.

CUMPLE

A3.5. Requerimientos Generarles de Implementación y operación del Sistema A3.5.1. Del Datacenter

Página 103 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

REQUERIMIENTOS FUNCIONALES

1

El sistema opera en la nube desde un datacenter

2

El datacenter utilizado para la prestación del servicio cumple con las mejores prácticas TIER IV de la Norma TIA 942, con relación a seguridad lógica y física, control de acceso, redundancia, disponibilidad y fiabilidad de los servicios de provisión y control de la infraestructura de servidores y networking

3

El datacenter cuenta con niveles de respaldo apropiados y planes de contingencia y continuidad que operan de manera que se garantice la continuidad del servicio.

4

El sistema cuenta con configuraciones de copia de seguridad de los datos que permiten su despliegue en centros de datos físicamente separados, soportando conexiones seguras por VPN y cifrado de datos

5

Los planea de respaldo/recuperación de información con los que cuenta el datacenter están alineados con los requerimientos (cumplen con ellos) definidos para la custodia de datos confidenciales (habeas data)-.

6

El sistema, que funciona en la nube, cuenta con una configuración de tolerancia a fallas y escalabilidad hardware bajo demanda, para asegurar una alta disponibilidad del servicio en términos de ancho de banda, hardware y software

7

El datacenter cuenta con los niveles de disponibilidad acordes y que garantizan la operación 7x24 del sistema que soporta

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.5.2. De Conectividad

NO.

REQUERIMIENTOS FUNCIONALES

1

El sistema está diseñado y opera de tal manera que se

CUMPLE

Página 104 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

optimiza el uso del ancho de banda y puede operar en condiciones mínimas y suficientes para operar los servicios que sean contratados por cada institución, debido a que algunas de ellas operarán desde sitios remotos en los que no será posible asegurar un ancho de banda mínimo.

2

El proveedor del sistema cuenta con los procesos de gestión del ciclo de vida de los elementos de infraestructura y de las herramientas de TI que conforman y soportan los servicios que presta.

3

La conectividad cuenta con los niveles de disponibilidad acordes y que garantizan la operación 7x24 del sistema que soporta

En la siguiente sección, para efectos de estandarización de la operación, el proveedor tipificará las condiciones mínimas requeridas en la conectividad (ancho de banda) que debe cumplir una institución de acuerdo con el número de equipos y usuarios que pueda llegar a tener en operación (calculados para un usuario) Nro. Equipos de cómputo

Nro. Usuarios

Nro. Usuarios simultáneos

Ancho de banda requerido(*)

Equipo de comunicación requerido o sugerido (marca/ referencia) (**)

Hasta 10 Hasta 10 10 11-30 Hasta 60 30 31-50 Hasta 100 50 > 50 Hasta 200 Hasta 100 (*) Este deberá ser el que utilice cada institución para conectarse hasta el datacenter en el que opere el servicio; la conexión podrá realizarse por medio físico o inalámbrico (redes 3G en adelante). (**) Deberá indicar la totalidad de equipos requeridos para garantizar la conectividad de las Instituciones; además deberá incluir los dispositivos móviles en los que opera la plataforma con alta confiabilidad.

A3.5.3. De Mesa de Ayuda

Página 105 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

1

REQUERIMIENTOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

Quien operará el sistema cuenta con una mesa de ayuda que funciona 7x24 y permite prestar los servicios de administración hospitalaria a LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN La mesa de ayuda cuenta con los protocolos estandarizados que apoyen la operación del sistema y garanticen su óptimo uso por parte de las Instituciones.

2

A3.5.4. Para la Implementación y puesta en servicio

NO.

1

REQUERIMIENTOS FUNCIONALES

CUMPLE

Se indicará la metodología (de amplia aceptación y reconocimiento) que será utilizada para la gestión y gerencia del proyecto.

2

Construir una matriz de riesgo para el proceso de implementación del servicio, de acuerdo con la metodología de proyectos que utilice.

3

Se realizarán un proceso de capacitación con personal de LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN (máximo 10) teniendo presente los siguientes puntos: - Debe ser certificada - Incluir una porción teórica y una porción práctica - Involucrar la totalidad de las funcionalidades básicas que permitan garantizar la operación de una institución.

- Involucrar los procesos que apoyará el sistema en los hospitales.

- Incluir la arquitectura de la solución, los equipos que la componen y los protocolos que deben operar desde la mesa de ayuda.

- Garantice la transferencia del conocimiento a los participantes - Esté acompañada de medios audiovisuales (presentaciones, videos, audios, etc) que sirvan de soporte y/o apoyen el proceso de implementación y operación del sistema.

- Se realice como punto de partida del proyecto y antes de

Página 106 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

que entre en operación la primera de las instituciones.

Contar con los manuales, guías y demás documentos (electrónicos) que sirvan de soporte para la operación del sistema Nota: El proveedor del sistema autorizará a COHA para que todo el material entregado como parte de la capacitación sea utilizado dentro de los programas académicos que ofrece el Politécnico de LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN.

-

4

El proceso de implementación en cada Institución deberá contemplar la realización de procesos de capacitación que garanticen la transferencia del conocimiento y el uso apropiado por parte del personal que hará uso del sistema.

5

Se llevarán a cabo comités de seguimiento periódicos (mínimo 1 a la semana) durante el proceso de implementación de la solución en las Instituciones que hagan uso de ella, en el que se evalúe el plan de trabajo y los riesgos identificados para cada Institución.

En la siguiente sección, para efectos de planeación del proyecto, el proveedor tipificará las condiciones mínimas requeridas para la implementación del sistema, de manera óptima, en las Instituciones Nro. Equipos de cómputo Hasta 10 11-30 31-50 > 50

Nro. Usuarios en la Institución Hasta 10 Hasta 60 Hasta 100 Hasta 200

Nro. Usuarios simultáneos por la Institución 10 30 50 Hasta 100

Tiempo Implementación

A3.5.4. Para la Operación del Sistema

NO.

REQUERIMIENTOS FUNCIONALES

1

Quien opere el sistema deberá realizar pruebas periódicas de simulación de situación de desastre a partir de protocolos

CUMPLE

Página 107 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

entregados por parte de él mismo y que estén alineados con los planes de contingencia y continuidad del negocio, aportados como parte de la solución.

2

Quien opere el sistema deberá entregar informes mensuales de operación y cubrimiento del sistema, estos deberán estar disponibles en línea por parte de LA COOPERATIVA DE HOSPITALES DE ANTIOQUIA - COHAN o cada Institución (en este último caso sólo podrán ver lo que le compete a cada una de ellas).

3

Se llevarán a cabo comités de seguimiento a la operación, como mínimo una vez al mes, en los que se revisen los informes del punto anterior, los informes de disponibilidad y mesa de servicio. Para lograrlo se deberá construir y presentar un cuadro de mando integral que garantice el seguimiento a la operación del sistema.

A3.6. Funcionalidad requerida interoperabilidad HIS - HCEU

NO.

1

REQUERIMIENTOS FUNCIONALES

CUMPLE

El HIS debe estar en condiciones de generar documentos HL7 V3 CDA r2 que sean especificados dentro del marco de las definiciones de la Historia Clínica Electrónica Unificada (CDA: Clinical Document Architecture). Los CDAs a desarrollar son: CDA Epicrisis Urgencias, CDA Epicrisis Hospitalización, CDA Gestante y CDA Consulta Externa.

2

El HIS debe desarrollar los servicios necesarios para enviar los documentos HL7 CDA generados dentro de su aplicación, a la Historia Clínica Electrónica Unificada. Los servicios para enviar documentos CDA son: Obtener identificación de paciente.

Almacenar CDA en el repositorio.

Registrar el CDA en locator o registro.

3

El HIS debe desarrollar los servicios necesarios para consultar los documentos HL7 CDA del repositorio de la Historia Clínica Electrónica Unificada para que sean desplegados dentro de

Página 108 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

su aplicación en un visor. Los servicios para consultar CDA son: Obtener lista de documentos de paciente.

Desplegar documento CDA del paciente.

4

El HIS debe generar la mensajería demográfica de pacientes estandarizada, basada en mensajería HL7, con el propósito de actualizar y consultar el Maestro Índice de Pacientes que se implemente para la Historia Clínica Electrónica Unificada

5

El HIS debe realizar los procesos de interoperabilidad necesarios con los sistemas de información de la Secretaría de la Seccional de Salud respectiva; en el sistema de Vigilancia en Salud Pública Nacional

6

SIVIGILA NACIONAL: Permite la generación de alertas cuando se identifica un evento de interés en Salud Pública.

El HIS debe generar y enviar un CDA de la primera página (Datos básicos) de la Ficha de Notificación del evento a la Secretaria Seccional de Salud, de acuerdo con el Decreto 3518 de 2006 y la legislación que lo modifique o complemente.

7

SIVIGILA (Sistema de Vigilancia en Salud Pública): Permite la generación de alertas cuando se identifica un evento de interés en salud pública. El HIS debe generar y enviar un CDA de la primera página (Datos básicos) de la Ficha de Notificación del evento a la Secretaria Seccional de Salud.

8

RIPS (Registro Individual de Prestación de Servicios de Salud): El HIS debe generar los archivos planos de acuerdo a las atenciones en las Instituciones Prestadoras de Servicios de Salud, según la Resolución 3374 de 2000.

9

Todas estas especificaciones estarán acordes con las normas vigentes, o las que las modifiquen, adicionen o sustituyan.

A3.7. FUNCIONALIDAD REQUERIDA INTEROPERABILIDAD HIS – HCEU

A3.7.1. CDA Epicrisis Urgencias

Página 109 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

1

REQUERIMIENTOS FUNCIONALES

CUMPLE

Sección 1: Datos IPS Código IPS Nombre IPS Código punto de atención Nombre punto de atención

2

Sección 2: Tipo de servicio y documento Tipo de documento: acorde con clasificación de documentos de LOINC Servicio: Especialidad: Fecha y hora de ingreso: Fecha y hora de egreso: Fecha y hora de generación de epicrisis:

3

Sección 3: Datos de identificación básica (Directiva 022 de 2011 y Decreto 062 de 2014) Primer Nombre: Segundo Nombre: Primer Apellido: Segundo Apellido: Tipo de documento: Número de documento: Municipio de nacimiento: Municipio de procedencia: País nacimiento: Código estado civil: Códigos estado civil.

Nivel educativo: Códigos nivel educativo Religión: Sexo: Fecha de nacimiento: Grupo sanguíneo: Factor Rh: EPS

4

Sección 4: Datos de ubicación Localidad: Dirección: Barrio: Codificación de Barrios por localidad.

Teléfono fijo: Teléfono celular: Correo electrónico: Nombre completo del Contacto: Parentesco: Dirección contacto: Teléfono fijo del Contacto: Teléfono celular del Contacto: Correo electrónico del Contacto:

Página 110 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

5

Sección 5: Diagnósticos Diagnóstico ingreso Urgencias CIE 10 Diagnóstico egreso Urgencias CIE 10

6

Sección 6: Motivo de consulta de Urgencias Motivo de Consulta de Ingreso a Urgencias: Enfermedad actual de Ingreso a Urgencias:

7

Sección 7: Revisión por Sistemas Piel y anexos: Otorrinolaringológico: Cardiovascular: Pulmonar: Gastrointestinal: Genitourinario: Musculo esquelético: Neurológico:

8

Sección 8: Antecedentes Patológicos: Quirúrgicos: Farmacológicos: Familiares: Traumatológicos: Toxicológicos: (Hábitos, fumador, consumo de licor, consumo de sustancias psicoactivas) Alérgicos: Inmunológicos: (Vacunas) Transfusionales: Hospitalizaciones: Ginecológicos: formula obstétrica, Menarquía, Fecha ultima menstruación, Planificación (si o no), Método de planificación, Vida sexual activa (si o no), ultima citología fecha, resultados ultima citología, Menopausia.

9

Sección 9: Examen Físico Condición general (aspecto general): Signos vitales: Tensión Arterial, Frecuencia Cardiaca, Frecuencia Respiratoria, Temperatura.

Datos antropométricos: Peso, Talla, IMC, Perímetro cefálico, Perímetro Abdominal.

Cabeza: (descripción cráneo, cara, ojos, oídos nariz, boca, orofaringe) Cuello: Cardio pulmonar: Abdomen: Genitourinario: Extremidades: Osteomuscular: Sistema Nervioso Central:

CUMPLE

Página 111 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

Piel y anexos: 10

Sección 10: Evolución Clínica del paciente Se describe el resumen de la evolución del paciente durante la hospitalización en el servicio de urgencias.

11

Sección 11: Ayudas diagnósticas (Paraclínicos e imágenes) Código CUPS del procedimiento realizado y paraclínico o imagen realizada y lectura de imágenes.

12

Sección 12: Plan tratamiento urgencias (Farmacológico, quirúrgico, terapia respiratoria, terapia física o cualquier otra indicación Médica) Listado de los tratamientos farmacológicos, quirúrgicos, terapéutico o indicaciones Médicas realizadas en el Servicio de Urgencias que debe contener código único de medicamentos vigentes CUMS con dosis, frecuencia y duración del tratamiento, Códigos CUPS de los procedimientos realizados indicando la cantidad y duración de los mismos, descripción de las indicaciones Médicas ordenadas durante la Hospitalización.

13

Sección 13: Plan tratamiento egreso, Ordenes Médicas.

(Farmacológico, quirúrgico, terapia respiratoria, terapia física o cualquier otra indicación Médica) Listado de los tratamientos farmacológicos, quirúrgicos, terapéutico o indicaciones Médicas ordenas para al egreso de Urgencia que debe contener código único de medicamentos vigentes CUMS con dosis, frecuencia y duración del tratamiento, Códigos CUPS de los procedimientos a realizar indicando la cantidad y duración de los mismos, descripción de las indicaciones Médicas ordenadas al egreso.

14

Sección 14: Condición egreso Condición final al egreso: Vivo, Muerto.

Motivo egreso: Domicilio, Remisión a otro Centro Hospitalario, Traslado a otro Servicio, Alta Voluntaria, Fallecimiento.

15

Sección 15: Medico que elaboró la Epicrisis Primer Nombre: Segundo Nombre: Primer Apellido: Segundo Apellido: Tipo de documento: Número de documento: Especialidad

Página 112 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.7.2. CDA Epicrisis Hospitalización

NO.

1

REQUERIMIENTOS FUNCIONALES

CUMPLE

Sección 1: Datos IPS Código IPS: Nombre IPS: Código punto de atención: Nombre punto de atención:

2

Sección 2: Tipo de servicio y documento Tipo de documento: acorde con clasificación de documentos de LOINC Servicio: Especialidad: Fecha y hora de ingreso: Fecha y hora de egreso: Fecha y hora de generación de epicrisis:

3

Sección 3: Datos de identificación básica (Directiva 022 de 2011 y Decreto 062 de 2014) Primer Nombre: Segundo Nombre: Primer Apellido: Segundo Apellido: Tipo de documento: Número de documento: Municipio de nacimiento: Municipio de procedencia: País nacimiento: Código estado civil: Códigos estado civil.

Nivel educativo: Códigos nivel educativo Religión: Sexo: Fecha de nacimiento: Grupo sanguíneo: Factor Rh: EPS

4

Sección 4: Datos de ubicación Localidad: Dirección: Barrio: Codificación de Barrios por localidad.

Teléfono fijo: Teléfono celular: Correo electrónico: Nombre completo del Contacto: Parentesco: Dirección contacto: Teléfono fijo del Contacto: Teléfono celular del Contacto: Correo electrónico del Contacto:

Página 113 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

5

Sección 5: Diagnósticos Diagnóstico ingreso Hospitalización CIE 10 Diagnóstico egreso Hospitalización CIE 10

6

Sección 6: Motivo de consulta de Urgencias Motivo de Consulta de Ingreso Hospitalización: Enfermedad actual de Ingreso Hospitalización:

7

Sección 7: Revisión por Sistemas Piel y anexos: Otorrinolaringológico: Cardiovascular: Pulmonar: Gastrointestinal: Genitourinario: Musculo esquelético: Neurológico:

8

Sección 8: Antecedentes Patológicos: Quirúrgicos: Farmacológicos: Familiares: Traumatológicos: Toxicológicos: (Hábitos, fumador, consumo de licor, consumo de sustancias psicoactivas) Alérgicos: Inmunológicos: (Vacunas) Transfusionales: Hospitalizaciones: Ginecológicos: formula obstétrica, Menarquía, Fecha ultima menstruación, Planificación (si o no), Método de planificación, Vida sexual activa (si o no), ultima citología fecha, resultados ultima citología, Menopausia.

9

Sección 9: Examen Físico Condición general (aspecto general): Signos vitales: Tensión Arterial, Frecuencia Cardiaca, Frecuencia Respiratoria, Temperatura.

Datos antropométricos: Peso, Talla, IMC, Perímetro cefálico, Perímetro Abdominal.

Cabeza: (descripción cráneo, cara, ojos, oídos nariz, boca, orofaringe) Cuello: Cardio pulmonar: Abdomen: Genitourinario: Extremidades: Osteomuscular: Sistema Nervioso Central:

CUMPLE

Página 114 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

Piel y anexos: 10

Sección 10: Evolución Clínica del paciente Se describe el resumen de la evolución del paciente durante la hospitalización.

11

Sección 11: Ayudas diagnósticas (Paraclínicos e imágenes) Código CUPS del procedimiento realizado y paraclínico o imagen realizada y lectura de imágenes.

12

Sección 12: Plan tratamiento Hospitalización (Farmacológico, quirúrgico, terapia respiratoria, terapia física o cualquier otra indicación Médica) Listado de los tratamientos farmacológicos, quirúrgicos, terapéutico o indicaciones Médicas realizadas durante la Hospitalización que debe contener código único de medicamentos vigentes CUMS con dosis, frecuencia y duración del tratamiento, Códigos CUPS de los procedimientos realizados indicando la cantidad y duración de los mismos, descripción de las indicaciones Médicas ordenadas durante la Hospitalización.

13

Sección 13: Plan tratamiento egreso, Ordenes Médicas.

(Farmacológico, quirúrgico, terapia respiratoria, terapia física o cualquier otra indicación Médica) Listado de los tratamientos farmacológicos, quirúrgicos, terapéutico o indicaciones Médicas ordenas para el egreso de Hospitalización que debe contener código único de medicamentos vigentes CUMS con dosis, frecuencia y duración del tratamiento, Códigos CUPS de los procedimientos a realizar indicando la cantidad y duración de los mismos, descripción de las indicaciones Médicas ordenadas al egreso.

14

Sección 14: Condición egreso Condición final al egreso: Vivo, Muerto.

Motivo egreso: Domicilio, Remisión a otro Centro Hospitalario, Traslado a otro Servicio, Alta Voluntaria, Fallecimiento.

15

Sección 15: Medico que elaboró la Epicrisis Primer Nombre: Segundo Nombre: Primer Apellido: Segundo Apellido: Tipo de documento: Número de documento: Especialidad:

Página 115 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.7.3. CDA Consulta Externa

NO.

1

REQUERIMIENTOS FUNCIONALES

CUMPLE

Sección 1: Datos IPS Código IPS: Nombre IPS: Código punto de atención: Nombre punto de atención:

2

Sección 2: Datos de la atención y documento Tipo de documento: Fecha de la consulta: Hora de la consulta: Servicio: Tipo de consulta: Tipo de Especialidad:

3

Sección 3: Datos Médico Primer Nombre: Segundo Nombre: Primer Apellido: Segundo Apellido: Tipo de documento: Número de documento: Especialidad:

4

Sección 4: Datos de identificación básica (Decreto 062 de 2014) Primer Nombre: Segundo Nombre: Primer Apellido: Segundo Apellido: Tipo de documento: Número de documento: Municipio de nacimiento: Municipio de procedencia: Código estado civil: Códigos estado civil.

Nivel educativo: Códigos nivel educativo Religión: Sexo: Fecha de nacimiento: Grupo sanguíneo: Factor Rh: EPS:

5

Sección 5: Datos de ubicación Localidad: Dirección: Barrio: Codificación de Barrios por localidad.

Teléfono fijo:

Página 116 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

Teléfono celular: Correo electrónico: Nombre completo del Contacto: Parentesco: Dirección contacto: Teléfono fijo del Contacto: Teléfono celular del Contacto: Correo electrónico del Contacto: 6

Sección 6: Motivo de Consulta Motivo de Consulta: Enfermedad actual:

7

Sección 7: Revisión por Sistemas Piel y anexos: Otorrinolaringológico: Cardiovascular: Pulmonar: Gastrointestinal: Genitourinario: Musculo esquelético: Neurológico:

8

Sección 8: Antecedentes Patológicos: Quirúrgicos: Farmacológicos: Familiares: Traumatológicos: Toxicológicos: (Hábitos, fumador, consumo de licor, consumo de sustancias psicoactivas) Alérgicos: Inmunológicos: (Vacunas) Transfusionales: Hospitalizaciones: Ginecológicos: formula obstétrica, Menarquía, Fecha ultima menstruación, Planificación (si o no), Método de planificación, Vida sexual activa (si o no), ultima citología fecha, resultados ultima citología, Menopausia.

9

Sección 9: Examen Físico Condición general (aspecto general): Signos vitales: Tensión Arterial, Frecuencia Cardiaca, Frecuencia Respiratoria, Temperatura.

Datos antropométricos: Peso, Talla, IMC, Perímetro cefálico, Perímetro Abdominal.

Cabeza: (descripción cráneo, cara, ojos, oídos nariz, boca, orofaringe) Cuello: Cardio pulmonar:

Página 117 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

Abdomen: Genitourinario: Extremidades: Osteomuscular: Sistema Nervioso Central: Piel y anexos: 10

Sección 10: Diagnósticos Diagnóstico Consulta Externa CIE 10

11

Sección 11: Análisis Resumen del caso y atención en Consulta Externa.

12

Sección 12: Plan o tratamiento Farmacológico: códigos CUMS y nombre del medicamento dosis, frecuencia y duración Quirúrgico: códigos CUPS y nombre Terapéutico: códigos CUPS cantidad y frecuencia Indicaciones Médicas: recomendaciones.

13

Sección 13: Ordenes Médicas Laboratorio: código CUPS y nombre Imagenología: código CUPS y nombre Interconsultas: Otros:

A3.7.4. CDA SIVIGILA Nacional

NO.

1

2

REQUERIMIENTOS FUNCIONALES

CUMPLE

Sección 1: Información General Tipo de documento: Código UPGD: Razón social de la unidad primaria generadora del dato: Nombre del evento: Código del evento: Fecha de la notificación: Sección 2: Identificación del Paciente Tipo de documento:

Página 118 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

Número de identificación: Nombres y apellidos del paciente: Teléfono: Fecha de nacimiento: Edad: Unidad de medida de la edad: Sexo: País de ocurrencia del caso nombre: Código del país: Nombre del Departamento: Código del departamento: Nombre del municipio de procedencia / ocurrencia: Código del municipio: Área de ocurrencia del caso: Localidad de ocurrencia del caso: Barrio de ocurrencia del caso: Cabecera municipal / centro poblado / rural disperso: Vereda / zona: Ocupación del paciente: Código ocupación del paciente: Tipo de régimen de salud: Nombre de la administradora de salud: Código administradora de salud: Pertenencia étnica: Seleccione los grupos poblacionales a los que pertenece el paciente:

3

Sección 3: Notificación Código del municipio: Nombre del Departamento y municipio de residencia del paciente: Dirección de residencia: Fecha de consulta: dd/mm/aaaa Fecha de inicio de síntomas: dd/mm/aaaa Clasificación inicial del caso: Hospitalizado: si o no Fecha de hospitalización: dd/mm/aaaa Condición final: Fecha de defunción: dd/mm/aaaa Número certificado de defunción Causa básica de muerte: Código causa básica de muerte: Nombre del profesional que diligencia la ficha: Teléfono

4

Sección 4: Espacio Exclusivo para Uso de los Entes Territoriales Seguimiento y clasificación final del caso: Fecha de ajuste: dd/mm/aaaa

Página 119 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

A3.7.5. CDA SIVIGILA

NO.

1

REQUERIMIENTOS FUNCIONALES

CUMPLE

Sección 1: Información General Tipo de documento: Fecha de Notificación a SDS: Semana: Año: Nombre del evento: Código del evento: Nombre de UPGD (Unidad Primaria Generadora del Dato): Código UPGD:

2

Sección 2: Identificación del Paciente Tipo Identificación: Número de Identificación: Fecha de Nacimiento: Edad: Unidad de medida de la edad: Hijo / Hija de: Primer Nombre: Segundo Nombre: Primer Apellido: Segundo Apellido: Teléfono: Sexo: Departamento de residencia del paciente: Municipio de residencia del paciente: El paciente reside en zona rural: Dirección de residencia: Localidad de residencia del o la paciente: Barrio de residencia del o la paciente: Cuál Barrio: Pertenencia étnica: Grupo poblacional: Código Ocupación: Nombre Ocupación: Tipo de aseguramiento: Entidad Administradora: Estado Civil: Nivel Educativo:

3

Sección 3: Notificación País de procedencia del caso: Departamento de procedencia del caso: Municipio de procedencia del caso: Área de procedencia del caso: Clasificación inicial del caso:

Página 120 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

Fecha de Consulta: Hospitalizado: Fecha Hospitalización: Condición Final: Fecha de defunción: No. Certificado de defunción: Causa básica de muerte: Persona que digita el documento: Nombre del Profesional: Teléfono del Profesional:

A3.7.6. CDA HCMP Historia Clínica Materna Perinatal

NO.

1

2

REQUERIMIENTOS FUNCIONALES

CUMPLE

Sección 1: Datos IPS Código IPS: Nombre IPS: Código punto de atención: Nombre punto de atención: Sección 2: Datos de la atención y documento Tipo de documento: Fecha de la consulta: Hora de la consulta: Servicio: Tipo de consulta: Tipo de Especialidad:

3

Sección 3: Datos Médico Primer Nombre: Segundo Nombre: Primer Apellido: Segundo Apellido: Tipo de documento: Número de documento: Especialidad:

4

Sección 4: Identificación gestante Nombres:

Página 121 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

Apellidos: Dirección: Localidad: Teléfono: Población especial: Ocupación: Fecha de nacimiento: Edad: Etnia: Alfabeta: Estudios: Estado civil: Vive sola: Lugar de control prenatal: Lugar del parto/aborto Tipo de documento: Número identificación: Régimen: Nombre EPS/ARS: Nombre acudiente: Teléfono acudiente: Parentesco: 5

Sección 5: Motivo de Consulta Motivo de Consulta: Enfermedad actual:

6

Sección 6: Revisión por sistemas Movimientos fetales: SI / NO Sangrado vaginal: SI / NO Amniorrea: SI / NO Cefalea: SI / NO Tinnitus: SI / NO Fosfenos: SI / NO Epigastralgia: SI / NO Flujo: SI / NO Factores de riesgo para coagulopatías: SI / NO

7

Sección 7: Antecedentes Patológicos: Quirúrgicos: Farmacológicos: Antecedente Familiares TBC: SI / NO Diabetes: SI / NO Hipertensión: SI / NO Pre eclampsia: SI / NO Eclampsia: SI / NO Otra condición Médica grave: SI / NO Antecedentes Personales

Página 122 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

CUMPLE

TBC: SI / NO Diabetes: SI / NO Tipo de Diabetes: I, II, Gestacional Hipertensión: SI / NO Pre eclampsia: SI / NO Eclampsia: SI / NO Otra condición Médica grave: SI / NO Cirugía genito-urinaria: SI / NO Infertilidad: SI / NO Cardiopatía: SI / NO Nefropatía: SI / NO Violencia: SI / NO VIH +: SI / NO Traumatológicos: Toxicológicos: Fuma SI / NO, Medicamentos SI / NO, Alcohol SI / NO, Violencia SI / NO. Alérgicos: Inmunológicos: Antirubeola, Antitetanica, Tos ferina.

Transfusionales: Hospitalizaciones: Antecedentes Obstétricos: Hemorragia posparto: SI / NO Número de gestas: Número de embarazos ectópicos: Número de abortos: 3 abortos espontáneos consecutivos: SI / NO Número de partos: Ultimo Parto selección entre: N/C ; Normal ; < 2500 gr ; 4000 gr.

Antecedentes de partos gemelares: SI / NO Número de partos vaginales: Número de cesareas: Número de nacidos vivos: Número de nacidos que viven: Numero de nacidos que mueren en la primera semana: Número de nacidos que mueren después de la primera semana: Número de nacidos muertos: Menarquía: edad en años Fecha ultima menstruación: dd/mm/aaaa Fecha probable de parto: dd/mm/aaaa Planificación: SI / NO Método de planificación: Ciclos menstruales regulares: SI / NO Vida sexual activa: SI / NO Fecha ultima citología: dd/mm/aaaa Resultados ultima citología: Menopausia: edad

Página 123 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)

NO.

REQUERIMIENTOS FUNCIONALES

8

Sección 8: Examen Físico Condición general (aspecto general): Signos vitales: Tensión Arterial, Frecuencia Cardiaca, Frecuencia Respiratoria, Temperatura.

Datos antropométricos: Peso previo embarazo, Peso actual, Ganancia de peso, Talla, IMC Cabeza: (descripción cráneo, cara, ojos, oídos nariz, boca, orofaringe) Cuello: Cardio pulmonar: Abdomen: Altura uterina en cms: Fetocardia: Genitourinario: Especuloscopia: Tacto vaginal: Extremidades: Osteomuscular: Sistema Nervioso Central: Piel y anexos:

9

Sección 9: Resultados Laboratorio Resultados de laboratorio de Toxoplasma, Cuadro Hemático, VIH, Uroanalisis, glicemia, Serología, urocultivo, Hemoclasificación, Hepatitis B.

10

Sección 10: Imagenología Resultados de ecografías y demás ayudas diagnosticas de imágenes.

11

Sección 11: Análisis Análisis del caso de la gestante.

12

Sección 12: Impresión diagnóstica Diagnostico CIE 10

13

Sección 13: Plan o tratamiento Farmacológico: códigos CUMS y nombre medicamento dosis, frecuencia y duración Quirúrgico: códigos CUPS y nombre Terapéutico: códigos CUPS cantidad y frecuencia Indicaciones Médicas: recomendaciones.

14

Sección 14: Ordenes Médicas Laboratorio: código CUPS y nombre Imagenología: código CUPS y nombre Interconsultas: Otros:

CUMPLE

Página 124 de 124 (RFI – Servicios de Tecnología e Información para los Hospitales)

NO CUMPLE

DESCRIPCIÓN/ OBSERVACIONES (INDICAR EN QUÉ TIEMPO LO TIENE IMPLEMENTADO, SI HOY NO ESTÁ OPERATIVO)