Sistemas de Información Hospitalaria

Pliego de condiciones particulares y
técnicas para la contratación de una

solución para los Sistemas de
Información Hospitalaria,
Historia Clínica Central y Portal
Personal de Salud.
#TecnoFE
1
Contenido
1 Objeto de la licitación
2 Marco Referencial
3 Alcance
4 Descripción de la solución
4.1 Resumen global
4.2 Detalle de los componentes
Renglón I: Solución HCEC, PSC, servicios de implementación para las
soluciones licitadas y de consultoría para adaptar los sistemas
provinciales
Renglón I.1: HCEC - Historia Clínica Electrónica Compartida
Renglón I.2: PSC - Portal de Salud del ciudadano
Renglón I.3: Servicios de implementación para las soluciones
HCEC y PSC
Renglón I.4: Servicios de consultoría para adaptar los HIS
provinciales a la nueva solución HCEC
Renglón II: Producto de software para el ámbito hospitalario, integrando
las siguientes soluciones (HIS, ERP, LIS, RIS, BI)
Renglón II.1: HIS (ERP, LIS, RIS, BI)
Renglón II.2: Servicios de Consultoría para la implementación
del HIS licitado
Renglón III: Producto de software y servicio de implementación de una
solución de Administración de Agendas y Turnos para la Red de
Salud de la provincia
Renglón III.1: Producto de software y servicio de
implementación, soporte y mantenimiento inicial
para una solución informática de Administración de
Agendas y Turnos para la Red de Salud de la
provincia
Renglón III.2: Servicios de consultoría para adaptar los
sistemas provinciales (HIS) para que interactúen
con el sistema de administración de agendas y
turnos licitado
Renglón IV: Servicios de consultoría para la construcción de una
solución de BI en el ámbito del Ministerio de Salud.
2
5 Consideraciones Generales
Arquitectura de la solución
Servicios Profesionales
Plan de contingencia, rescisión o término de contrato
Mantenimiento
6 Anexo I: Instrucciones para la preparación de la oferta técnica
7 Anexo II: Integración del HIS/ERP con Sistemas Externos
8 Anexo III: Evaluación de las ofertas
9 Anexo IV: Cronograma
3
Objeto de la licitación
El objeto de la presente licitación es la contratación de una solución
tecnológica integral para el ámbito de salud pública de la provincia, que
contemple la provisión, instalación y puesta en funcionamiento de los
siguientes productos:
- Un Sistema de Información Hospitalario (HIS), el cual deberá

complementarse con un sistema de Laboratorio (LIS), uno de Imágenes
(RIS), uno de Recursos Empresariales (ERP) debidamente integrados, de
manera que permita registrar los actos médicos y administrativos del efector
y de los pacientes en su proceso asistencial dentro del establecimiento de
Salud.
- Por otra parte, se requiere dotar a toda la red de atención sanitaria de la

provincia de un sistema de información para soporte de la Historia Clínica
Electrónica Compartida (HCEC), que integrado a otros sistemas Públicos o
privados, permita el registro, mantenimiento, y consulta de todos los datos
relativos a los pacientes y de las atenciones realizadas en cualquier
establecimiento de Salud de la Provincia. Esta historia clínica deberá poder
ser consultada por profesionales de la salud desde cualquier punto de la red
de atención, pero también estará accesible a cualquier ciudadano que quiera
consultar (vía aplicaciones WEB o móviles) su Historia personal.
- Una herramienta para la gestión de agendas y turnos para los servicios

prestados en toda la red de salud.
- Una solución de Business Intelligence (Inteligencia de Negocios) que integre

la información producida por todos los sistemas informáticos utilizados en la
red de salud de la provincia, y asista en el análisis y la presentación de los
datos, proporcionando a las áreas ejecutivas un profundo y completo
conocimiento de la situación en cada momento con información relevante y
oportuna para la toma de decisiones.
Paralelamente se incluye como objeto, la contratación de servicios de soporte y

mantenimiento preventivo, correctivo y evolutivo, que permita contemplar la
“estabilización” de las herramientas que integran la solución implementada, y
un período para el desarrollo e implementación de nuevos requerimientos
solicitados por el Ministerio de Salud como “mejora continua”, dentro del marco
de las solución informática integral solicitada en el punto anterior, y en el
marco del Plan Estratégico de Tecnología 2016 - 2018, llamado TecnoFE.
1 Antecedentes
El Plan Estratégico de Tecnología 2016-2018: TecnoFE
4
El 17 de mayo de 2016 el Gobierno de Santa Fe presentó el Plan Estratégico de
Tecnología 2016-2018, en adelante también llamado TecnoFE, el primer plan
estratégico para el desarrollo tecnológico de la provincia.
TecnoFE responde a un ejercicio de planificación, un ejercicio en el cual el

Gobierno ha definido sus objetivos a medio y largo plazo, estableciendo metas
y objetivos cuantitativos, desarrollando las estrategias necesarias para
conseguirlos e identificando los recursos necesarios para llevarlas a cabo.
Estrategia para el Eje de Salud Pública

El Gobierno de la Provincia de Santa Fe está convencido de la vital importancia
de la tecnología para mejorar el bienestar de los ciudadanos de la provincia. Es
por ello que uno de los objetivos de TecnoFE es responder a las crecientes
expectativas ciudadanas en el área de Salud, el Gobierno de Santa Fe
considera imprescindible informar y alinear su percepción con la realidad
actual. Asimismo, es de vital importancia dotar a los efectores de salud de la
provincia de nuevos y mejores recursos así como también mejorar la atención
que ofrecen a la población.
Programas que conforman el Plan de Salud Pública de TecnoFE

La estrategia para Salud se basa en el uso de un modelo conceptual para
estructurar los programas de proyectos y sus alcances, y en la priorización de
éstos en base a los objetivos establecidos. Dicho modelo organiza los proyectos
en ámbitos, políticas y niveles de equipamiento facilitando su análisis, nivel de
alineación con los objetivos estratégicos del Gobierno de Santa Fe y su
priorización.
5
Programas ámbitos y proyectos del Plan de Salud de TecnoFE
Alcance de esta gestión con respecto a TecnoFE

Tal cual se describió en el apartado anterior, los Programas que conforman el
Plan en Salud son los siguientes:
· PRG.SL.01. Estrategia en Salud

· PRG.SL.02. Historia Clínica Compartida
· PRG.SL.03. Gestión de Hospitales
· PRG.SL.04. Sistema Integral de Receta Electrónica
· PRG.SL.05. Tarjeta Sanitaria
Los programas y proyectos alcanzados por la solución que se licita en

este pliego son los siguientes:
- El Programa “Estrategia en Salud”contempla proyectos e iniciativas

relacionados con alinear la estrategia del Gobierno de Santa Fe con el
modelo TIC de Salud, para determinar así la configuración óptima de los
proyectos.
En ese sentido la implementación de una herramienta de “Inteligencia de

negocios” que proporcione de manera eficiente y oportuna toda la
información necesaria para contar con una visión completa e integral del
sistema de salud de la provincia en cada momento, constituye una
iniciativa estratégica para procurar dicho objetivo. El programa alcanzado
es:
· PRG.SL.01. Estrategia en Salud
- El Programa de “Historia Clínica Compartida” contiene aquellos proyectos e

iniciativas relacionados con disponer de los Sistemas de Información
necesarios para compartir y gestionar una única historia clínica para cada
paciente entre todos los sistemas de salud existentes. De este programa,
los proyectos alcanzados por este pliego son:
· SL.02 Selección e implantación de la solución de la Historia

Clínica Compartida (HCC)
· SL.03 Migración de los repositorios actuales a la Historia Clínica
Compartida (HCC)
6
- El Programa de “Gestión de Hospitales” Incluye aquellos proyectos e
iniciativas relacionados con disponer de un nuevo y único Sistema de
Información que mejor se ajuste a las necesidades de los hospitales en la
Provincia y se alinee con los objetivos del GSF. Así se obtendrá coherencia y
homogeneidad de la información.
En efecto todos y cada uno de los productos y servicios licitados en este

pliego, como una solución integral para el sistema de Salud provincial,
constituyen una iniciativa que contribuye al objetivo de este programa.
· PRG.SL.03. GESTIÓN DE HOSPITALES
Y en particular se encuentran alcanzados por este pliego los siguientes

proyectos:
· SL.04 Selección y provisión del nuevo ERP

· SL.05 Implantación ERP en Venado Tuerto y Ceres
· SL.06 Implantación ERP en H.Cullen y H.Provincial
· SL.07 Completar migración al resto de los hospitales
PRG.SL.03
Marco referencial
La red de salud de la provincia, cuenta con 702 efectores (581 provinciales y
221 municipales) de diferentes niveles de complejidad, organizados
territorialmente en cinco nodos. A través de ellos el ciudadano, según sus
necesidades de salud, transita por los distintos niveles de atención, en variadas
especialidades, carteras de servicios de diferente complejidad y atención en
servicios de urgencias.
Como se define en el plan estratégico provincial de tecnología, el proceso de

implementación de la solución informática en el ámbito hospitalario, está
previsto para todo nuevo hospital dentro de la provincia, comenzando en una
primera etapa por el hospital de la ciudades de Venado Tuerto y Ceres, a
inaugurarse a mediados del año 2017.
La solución informática buscada, debe permitir una adecuada integración y
coordinación de las unidades al interior del establecimiento, así como con el
resto de la red asistencial; facilitando la utilización de herramientas de gestión
clínica, gestión del conocimiento y la aplicación del enfoque de calidad,
certificando HIMSS nivel 5.
7
Se requiere que la herramienta informática aplicada en el ámbito del efector de
salud (Renglón II: HIS, LIS, RIS, ERP), se integre con la Historia Clínica
Electrónica Compartida (en adelante HCEC, renglón I), a través de canales de
interoperabilidad que deben enmarcarse en las especificaciones técnicas
recomendadas por IHE (Integrating the Healthcare Enterprise).
Del mismo modo, los sistemas existentes serán adecuados por la Provincia de
Santa Fe en colaboración con la adjudicataria, para interactuar con la HCEC,
dentro del mismo marco de interoperabilidad solicitado para la nueva solución
hospitalaria, licitada en el presente pliego.
Asimismo, los ciudadanos podrán acceder a su Historial Clínico, cuando lo
requieran, a través del portal personal de salud.
2 Alcance
El alcance del presente pliego, se describe en el siguiente cuadro:
8
Renglón
Solución Licitada Ámbito de implementación
N°
I 1. Producto de software
Todos los efectores que conforman la red de
para la Historia Clínica
salud pública de la provincia
Electrónica Compartida
2. Producto de software
Ciudadanos usuarios de la red de salud
para el Portal de Salud del
pública de la provincia
Ciudadano
3. Servicios de Toda la red de Salud de la
implementación, soporte y provincia
mantenimiento inicial de la
solución de la HCEC y el
PSC.
4. Servicios de consultoría Los HIS utilizados por la provincia
para adaptar los sistemas son:
provinciales (HIS) a la
nueva estructura de la Sicap - Sistema de información
HCEC para Centros de Atención
Primaria
Diagnose - Sistema de gestión
hospitalaria
1. Producto de software ● Licencias ilimitadas y de uso

II para el ámbito hospitalario, perpetuo para todos los
integrando las siguientes efectores de la Provincia de
soluciones (HIS, ERP, LIS, Santa Fe.
RIS)
2. Servicios de ● Implementación de todos los
implementación, soporte y módulos en nuevos hospitales:
mantenimiento inicial para ○ Hospital de Venado
el producto de software en Tuerto
el ámbito hospitalario. ○ Hospital de Ceres
● Implementación gradual en
efectores en funcionamiento:
○ Hospital Provincial de
Rosario
○ Hospital J. M Cullen
III 1. Producto de software y Todos los efectores de la red de
servicio de implementación, salud
soporte y mantenimiento
inicial de una solución
informática que permita
administrar las agendas y
turnos de los servicios de
salud de la red.
2. Servicios de consultoría Los HIS utilizados por la provincia
para adaptar los sistemas son:
provinciales (HIS) para que
interactúen con el Sicap - Sistema de información
sistema de administración para Centros de Atención
9
de agendas y turnos. Primaria
Diagnose - Sistema de gestión
hospitalaria
IV 1. Producto de Software de Ministerio de Salud, y toda la red

Inteligencia de Negocios. de Salud de la provincia.
2. Servicios profesionales La definición de información e
para la implementación y indicadores a visualizar estará a
soporte de la solución de cargo del Ministerio de Salud de la
BI. provincia de Santa Fe, y se apoyará
en propuestas elaboradas por la
adjudicataria en coordinación con el
equipo de proyecto del GSF, a partir
de una serie de relevamientos y
consultorías llevadas a cabo por la
empresa en todas las áreas del
Ministerio de Salud y la red de Salud
de la provincia, que se requieran.
A continuación se describe el ámbito donde se aplicará la solución solicitada,
para cada implementación:
Renglón I
I.1 - HCEC: La Historia Clínica Electrónica Compartida, deberá permitir
visualizar todas las intervenciones de los ciudadanos con la red de salud
pública de la provincia, que hoy cuenta con 702 efectores de diferentes niveles
de complejidad, con una infraestructura de 5427 camas públicas, el 10,7% son
camas municipales, distribuidas en 129 efectores con internación, con un total
anual de 151.067 egresos y 8.384.954 consultas ambulatorias.
Esta herramienta deberá definir el marco de interoperabilidad con el que se
interconectan todos los sistemas de información utilizados actualmente en los
efectores de salud y los nuevos sistemas del ámbito hospitalarios, licitado en el
renglón II del presente pliego, habilitando la posibilidad de incorporar con
posterioridad los efectores privados y municipales, fuera del ámbito de este
proyecto.
I.2 - PSC: El Portal de Salud del ciudadano, deberá permitir a los ciudadanos,
acceder cuando lo requiera, a su historial clínico personal.
Según último censo nacional 2010, la provincia de Santa Fe cuenta con
3.194.537 habitantes y en nuestras bases de datos, 3.600.000 personas están
registrados en la red de salud pública de la provincia.
I.3 - Servicios de implementación, soporte y mantenimiento inicial de
la solución de la HCEC y el PSC: La implementación de la historia clínica
electrónica compartida, contempla la puesta en marcha e implantación de los
canales de interoperabilidad clínica que garanticen la integración de la
información de los usuarios de la red de salud de la provincia, registrada en los
10
diferentes sistemas de información que utilizan los efectores de la provincia. Y
paralelamente se requiere el servicio de soporte y mantenimiento correctivo,
preventivo y evolutivo de esta solución, con el objetivo de alcanzar la
estabilización de la misma y acompañar los primeros pasos de la mejora
contínua, en todos los ámbitos en que se implemente.
I.4 - Servicios de consultoría para adaptar los HIS de la provincia

(Sicap y Diagnose): Los servicios de consultoría deberán facilitar la
modificación de los software utilizados en los efectores de la provincia (Sicap y
Diagnose), de manera que puedan adaptarse a la nueva estructura de la HCEC.
Los mencionados servicios deberán contemplar las siguientes tareas:

conducción, análisis y resolución del diseño de las interfaces que permitan
interoperar a los sistemas provinciales con la HCEC propuesta, quedando a
cargo de la Sectorial de Informática de Salud la codificación que demande
dicha solución. También será responsabilidad de la adjudicataria, llevar a cabo
de manera coordinada con el equipo de la mencionada Sectorial, la
planificación, diseño y ejecución de las pruebas de integración necesarias, y
brindar el soporte que se requiera durante la implementación y puesta en
funcionamiento en los distintos efectores, de los cambios desarrollados por la
Sectorial de Informática de Salud para lograr el objetivo propuesto.
Durante el período previsto para la cotización, el Ministerio de Salud publicará

una fecha donde se podrán realizar las consultas referidas a los sistemas
provinciales, a demanda de los oferentes.
Actualmente 559 efectores del primer nivel de atención utilizan Sicap como
sistema de información para registro de información clínica, y 59 efectores con
internación, utilizan al menos un módulo del sistema de gestión hospitalaria
Diagnose.
11
Renglón II
II.1 - Solución informática para el ámbito hospitalario: Esta solución

informática a implementar en el ámbito hospitalario, debe permitir registrar y
gestionar el proceso asistencial del paciente en el efector. Esta herramienta
deberá ofrecer una solución integrada (HIS, RIS, LIS, ERP) para las
implementaciones en nuevos hospitales (Nuevo Hospital de Venado Tuerto y
Nuevo Hospital de Ceres, en el marco de este proyecto). Asimismo, debe
integrarse e interoperar hacia adentro del hospital con los sistemas existentes
en los efectores que poseen sistemas de información (Hospital Provincial de
Rosario y Hospital J.M. Cullen).
II.2 - Servicios de implementación, soporte y mantenimiento inicial

para el producto de software en el ámbito hospitalario: Los servicios de
implementación de esta herramienta para el ámbito hospitalario (HIS), serán
efectivizados por prestadores regionales, para cada implementación, según lo
especificado a continuación:
● Hospital Venado Tuerto: El hospital de Venado Tuerto, es un hospital

nodal que referencia a 42 efectores de primer nivel de atención, y
cuenta con un promedio de 61 camas disponibles de diferentes niveles
de complejidad con 3.689 egresos y 149.236 atenciones ambulatorias
realizadas en el año 2015 (116.734 médicas y 32.502 no médicas), en el
cual trabajan 364 personas. Su inauguración e implementación de las
soluciones en el ámbito hospitalario están previstas para julio del año
2017. Su proyección es convertirse en un Hospital Nodal de Tercer Nivel
de Atención, con referencia a 57 efectores de primer y segundo nivel de
atención, con un crecimiento para 120 camas, nuevos servicios y la
incorporación de 300 nuevos puestos de trabajo.
● El nuevo hospital base referencial de Ceres , se encuentra en la

ciudad de Ceres, cubriendo una poblaciòn de 9.000 habitantes
atendidos en el año 2016. Es un hospital de mediana complejidad, con
21 camas 1.555 egresos y 40.116 consultas ambulatorias realizadas en
el año 2015, en el cual trabajan 88 personas. Su inauguración e
implementación de las soluciones en el ámbito hospitalario están
previstas en julio del año 2017.
En etapas posteriores, se proyectan nuevas implementaciones según el

siguiente cronograma:
● Hospital Provincial de Rosario, se encuentra en la ciudad de Rosario,

es un hospital de referencia, de tercer nivel de atención, de alta
complejidad, con 119 camas y 201.817 consultas ambulatorias
realizadas en el año 2015, en el cual trabajan 1.433 personas. La fecha
de implementación de la solución en el ámbito hospitalario está
12
planificada para mediados del año 2017.
● Hospital “José María Cullen”, se encuentra en la ciudad de Santa Fe,

es un hospital de referencia, de tercer nivel de atención, de alta
complejidad, y dispone de 353 camas y 105.729 consultas ambulatorias
realizadas en el año 2015, en el cual trabajan 1.693 personas. La fecha
de implementación de la solución en el ámbito hospitalario está
planificada para mediados del año 2017.
Posteriormente, se proyectan nuevas implementaciones según el siguiente

cronograma, sin contemplarse como objetos del presente pliego:
● CEMAFE, es el centro de especialidades médicas ambulatorias de la
ciudad de Santa Fe, donde se concentrará la atención ambulatoria de
especialidades referenciadas por el primer nivel de atención de la ciudad
de Santa Fe y el centro norte de la provincia. La fecha de inauguración
del mencionado centro está prevista para mediados del año 2017.
● El nuevo hospital “J. B. Iturraspe”, se encuentra en la ciudad de

Santa Fe, es un hospital de referencia, de tercer nivel de atención, de
alta complejidad, con 190 camas, 17.222 egresos y 232.829 consultas
ambulatorias realizadas en el año 2015, en el cual trabajan 1.438
personas. La inauguración del nuevo hospital “Iturraspe”, en etapa de
construcción, como la implementación de la solución en el ámbito
hospitalario está planificada para el año 2018.
Paralelamente a los servicios de implementación, se requiere el soporte y

mantenimiento correctivo, preventivo y evolutivo de la solución, con el objetivo
de alcanzar su estabilización y acompañar los primeros pasos de la mejora
contínua, en todos los ámbitos en que se implemente.
Renglón III
III.1 - Producto de software y servicio de implementación, soporte y

mantenimiento inicial de una solución informática que permita
administrar las agendas y turnos de los servicios de salud de la red: La
solución informática licitada, debe brindar un servicio de gestión de agendas y
turnos de los servicios prestados por toda la red de salud, tanto ambulatorios
como hospitalarios incluyendo servicios quirúrgicos y telemedicina, utilizando
mensajería estándar HL7 v.2. Esta información debe estar sincronizada con los
procesos de los HIS nuevos, licitados en el presente pliego, como así también
con los utilizados por los demás efectores de la provincia (Diagnose y Sicap,
cuya adaptación está contemplada en el inciso 2 del Renglón III del presente
pliego). Además, deberá permitir la articulación y coordinación necesaria entre
efectores, e interoperar en todo momento con la historia clínica electrónica
compartida.
13
Se requiere también un servicio de consultoría para la implementación y
puesta en marcha de esta solución, el soporte y mantenimiento correctivo,
preventivo y evolutivo de la misma, con el objetivo de alcanzar su
estabilización y acompañar los primeros pasos de la mejora contínua, en todos
los ámbitos en que se implemente.
III.2 - Servicios de consultoría para la adaptación de los HIS
provinciales (Sicap y Diagnose) para interoperar con el sistema de
administración de agendas y turnos, solicitado en el inciso 1 del presente
renglón.
Todo HIS deberá responsabilizarse por implementar en su sistema los flujos y

pantallas necesarios para disparar este proceso, incluyendo la integración a
través de mensajería estándar HL7v2 para obtener los cupos, confirmar
reserva y cancelar reserva.
Los servicios de consultoría mencionados, deberán contemplar las siguientes

tareas: conducción, análisis y resolución del diseño de las interfaces que
permitan interoperar a los sistemas provinciales con el Sistema de Agendas y
turnos propuesto, quedando a cargo de la Sectorial de Informática de Salud la
codificación que demande dicha solución. También será responsabilidad de la
adjudicataria, llevar a cabo de manera coordinada con el equipo de la
mencionada Sectorial, la planificación, diseño y ejecución de las pruebas de
integración necesarias, y brindar el soporte que se requiera durante la
implementación y puesta en funcionamiento en los distintos efectores, de los
cambios desarrollados por la Sectorial de Informática de Salud para lograr el
objetivo propuesto.

Renglón IV
IV.1 - Producto de Software de Inteligencia de Negocios (Business

Intelligence): el producto licitado deberá permitir la integración de las
diferentes fuentes de información o plataformas con las que trabaja el
Ministerio de Salud de la provincia de Santa Fe, y su explotación en las
áreas estratégicas que se determinen, dentro del ámbito de dicho Ministerio
y en la red de salud de la provincia.
IV.2 - Implementación, soporte y mantenimiento inicial para la

solución de BI: Se contratarán servicios de consultoría para el diseño e
implementación de una solución que permita integrar la información producida
y/o almacenada por los distintos sistemas utilizados en el ámbito del Ministerio
de salud de la provincia, y llevar a cabo su explotación a través de la
herramienta de BI licitada en el punto anterior. El equipo responsable de
brindar este servicio de consultoría, trabajará con los equipos de gestión que
14
designe el Ministerio de Salud para la definición de procesos, proyectos e
indicadores, en función de las necesidades de información de la gestión.

mantenimiento correctivo, preventivo y evolutivo de esta solución, con el
objetivo de alcanzar su estabilización y acompañar los primeros pasos de la
mejora contínua, en todos los ámbitos en que se implemente.
15
3 Descripción de la solución
3.1 Resumen global
En el siguiente gráfico, se esquematiza el requerimiento objeto del presente

pliego:
Gráfico 1
4.1.1 Descripción resumida de los componentes y sus

interacciones:
Renglón I
I.1 - HCEC: Historia Clínica Electrónica Compartida. Este sistema permitirá
consolidar, compartir y gestionar los datos necesarios para mantener una
Historia Clínica única para la red de salud de la provincia de Santa Fe.
Este Sistema debe proporcionar un modelo asistencial que permita el acceso y
la consulta de forma inmediata, segura y confidencial de la información
relevante del paciente, independientemente de su ubicación geográfica o lugar
de atención (hospital, centro de atención primaria, consultas privadas, etc.).
En esta solución se deben contemplar tres componentes necesarios para la

gestión de la Historia Clínica Electrónica Compartida (gráfico 1), consolidando
16
los documentos clínicos de las atenciones realizadas a la población y
registradas por los distintos software utilizados en los efectores de la red de
salud de la provincia (HIS), y estos documentos son consolidados dentro de un
repositorio único centralizado y un registro de eventos.
Esta solución está basada en una plataforma de interoperabilidad y consta al

menos de componentes como: un índice maestro de pacientes, un repositorio
de documentos, un registro de eventos, un canal de interoperabilidad y un
visor para usuario final.
La solución se debe implementar sobre un modelo de servicios que estarán

disponibles hacia oferentes y consumidores de información quienes interactúan
con un repositorio centralizado, el cual se encontrará alojado en la
infraestructura tecnológica de la Provincia.
Canal de Interoperabilidad Clínica: Tal como se visualiza en el gráfico 1 del

presente pliego, el canal de interoperabilidad clínica forma parte de la solución
de la HCEC, y tendrá a su cargo nutrir la misma, integrando la información
producida en los diferentes software utilizados por los efectores de la red de
Salud de la provincia, incluyendo el nuevo HIS a licitar y los sistemas existentes
Diagnose y Sicap.
Del mismo modo, deberá permitir el acceso al Registro compartido de la HCEC,

desde todos los sistemas de información que lo requieran.
Estas estrategias de acceso e integración se extenderá en etapas posteriores a

otras organizaciones Municipales y Privadas.
Respetando el marco técnico propuesto, estos canales deberán aportar las

siguientes funcionalidades:
● Envío de documentos al repositorio
● Registro del metadato de los documentos en el repositorio
● Consulta de documentos
● Despliegue de los documentos
● Actualización del identificador o índice único de pacientes
17
I.2 - PSC: Portal de Salud del Ciudadano: Este aplicativo brindará el acceso
individual de cada ciudadano a su Historia Clínica personal, desde donde podrá
acceder a todos sus eventos clínicos registrados en cualquier punto de la red
de servicios de salud de la Provincia. Este acceso se podrá efectuar de distintas
modalidades, aplicaciones web y móviles.
Asimismo, podrá gestionar y/o cancelar los turnos programados de las

prestaciones que la red habilite para sus usuarios.
Del mismo modo, permitirá al ciudadano acceder a contenido educacional o

material de prevención que el Ministerio de Salud determine oportuno.
I.3 - Servicios de implementación, soporte y mantenimiento inicial de

la solución HCEC y PSC: Se contratarán los servicios de consultoría y/o
desarrollos necesarios para poner en funcionamiento la solución de Historia
Clínica Electrónica Compartida y el acceso individual del Portal de Salud del
Ciudadano, así como también el soporte y mantenimiento preventivo,
correctivo y evolutivo con el objetivo de estabilizar la implementación de
ambas soluciones, y acompañar los primeros pasos en la mejora contínua.
Estos servicios deberán estar a cargo de proveedores nominalizados para la

implementación local.
I.4 - Servicios de consultoría para adaptar los sistemas provinciales

(Sicap y Diagnose): Para alcanzar el objetivo de la solución para la HCEC, es
necesario que los HIS utilizados por los efectores de la provincia (Sicap y
Diagnose), interactúen con la HCEC a través de los canales de interoperabilidad
clínica.
Por esta razón, se licitan servicios de consultoría necesarios para adaptar estos
sistemas para que a través de una arquitectura orientada a servicios, definidas
en el canal de interoperabilidad clínica, puedan generar documentos
estandarizados para ser enviados a la plataforma de la HCEC.

permitan interoperar a los sistemas provinciales con la HCEC propuesta,
quedando a cargo de la Sectorial de Informática de Salud la codificación que
demande dicha solución. También será responsabilidad de la adjudicataria,
llevar a cabo de manera coordinada con el equipo de la mencionada Sectorial,
la planificación, diseño y ejecución de las pruebas de integración necesarias,
y brindar el soporte que se requiera durante la implementación y puesta en

18
19
Renglón II
II. 1 Solución informática en el ámbito hospitalario
HIS: Sistema de Información Hospitalario. Este Sistema debe permitir registrar

y gestionar los actos médicos de cada ciudadano en su proceso asistencial.
Registros que deben constituirse en la fuente de la que se nutrirá la Historia
Clínica Electrónica Compartida y desde donde, debidamente integrado al
Sistema de gestión administrativa (ERP) se puedan consolidar estadísticas de
tipo clínicas, administrativas y financieras.
El HIS debe estar centrado en el paciente, su Historia Clínica y sus
necesidades, permitiendo con facilidad la gestión integral y coordinada de sus
datos individuales detallados, los cuales deben ser capturados directamente en
el sitio en que se generan y por quien lo realiza.
La solución informática en el ámbito hospitalario debe estar integrada hacia el
interior con los sistemas LIS y RIS/PACs, según puede visualizarse en el
esquema del gráfico 3.
20
- Gráfico 3 -
Además de interactuar con los sistemas internos del efector, el HIS deberá
interoperar con los siguientes sistemas (ver gráfico 3.1):
● la HCEC implementando los perfiles IHE necesarios para conformar la
misma, utilizando los protocolos estándares PIXv2/V3, hl7 v2 y XDS.b.
● el sistema de Administración de Agendas y turnos utilizando mensajería

HL7 v2 o superior.
● la herramienta de Inteligencia de Negocios utilizada por la Provincia.
Gráfico 3.1
LIS: Sistema de Información de Laboratorio. Esta herramienta deberá facilitar

la Gestión integral del Laboratorio de Análisis Clínicos, incluyendo funciones de
conexión y control de autoanalizadores y otros equipos del laboratorio, solicitud
de determinaciones, generación de listas de trabajo, validación e informe de
resultados y seguimiento de las muestras.
El HIS deberá integrarse e interoperar con el LIS mediante una interfaz con
éste. Las tareas que se realicen desde el HIS, como gestión de turnos, solicitud
de determinaciones, etc., deben ser replicadas en forma transparente al LIS y
este deberá entregar resultados parciales y totales en tiempo real a todos los
usuarios del HIS.
El servicio de mensajería a través del cual van a interoperar el LIS y el HIS,
deberá ajustarse al estándar HL7 v 2 o posterior, siendo deseable que la misma
implemente el marco técnico de IHE para el dominio de laboratorio.
RIS: Sistema Información Radiológico. Esta solución cubre la gestión integral

de un Servicio de Imágenes, controlando toda la actividad generada, tanto a
nivel administrativo desde la asignación de los turnos, hasta la redacción final
de los informes, interactuando con el PACS disponible en el efector.
21
El HIS debe mantener una integración total con el sistema RIS/PACS,
administrando sus recursos disponibles: médicos, profesionales no médicos,
equipos, insumos, agenda de turnos y listas de espera. Por otra parte, los
usuarios del HIS tendrán acceso transparente a la visualización de los
exámenes radiológicos e informes asociados, a través de los visualizadores
propios del PACS o de terceros. Tal como se muestra en el esquema del gráfico
3.
El servicio de mensajería a través del cual van a interoperar el RIS y el HIS,

deberá ajustarse al estàndar HL7 v 2 o posterior, siendo deseable que la
misma implemente el marco técnico de IHE para el dominio de
Radiología.
ERP: Sistema de Recursos Empresariales. Esta Herramienta permitirá gestionar

en forma integrada todos los procesos administrativos del establecimiento de
salud, integrando los procesos administrativos y logísticos básicos: dispensa de
medicamentos, gestión de insumos, gestión de recursos humanos y gestión
contable financiera.
Facilitará además el control en la gestión, auditorías y las rendiciones de
cuentas, para garantizar la calidad y transparencia de la Gestión.
El Sistema ERP debe estar totalmente integrado al HIS para disponer de un
registro clínico, estadístico y administrativo que de continuidad de información
para una mejor calidad de atención de los pacientes y sea un instrumento
productor de información para la gestión y la toma de decisiones.
Capa de Interacción con Otros Sistemas: El sistema informático del ámbito

hospitalario, deberá dialogar e integrarse con otras soluciones TICs utilizadas
en el ámbito del Ministerio de Salud. Se trata de sistemas propios del
Ministerio, sistemas transversales de la administración pública central y de
diferentes programas Nacionales. Para lograr esta integración deberá utilizar
los canales de interacción propuestos por dichos sistemas, que son detallados
en Anexo II del presente pliego.
II.2 - Como parte de este renglón, se contratarán servicios de consultoría para

la implementación de la herramienta informática para el ámbito hospitalario
(HIS), así como también el soporte y mantenimiento preventivo, correctivo y
evolutivo con el objetivo de estabilizar la implementación de ambas soluciones,
y acompañar los primeros pasos en la mejora contínua.
Cada implementación deberá realizarse a través de la integración con
Empresas de localización Provincial, siendo deseable que la ubicación real se
encuentre en la ciudad de implementación.
La/s Empresa/s u Organización/es oferentes deberán acreditar un vínculo
laboral para la implementación del renglón citado, con empresas radicadas en
la Provincia de Santa Fe.
22
La/s empresa/s con las cuales se establezca la relación, deberán constar en la
presentación de la oferta, con los siguientes datos:
● Nombre o Razón Social
● Domicilio Legal. Se considera el domicilio legal para acreditar la

localización en la Provincia.
● Tipo de empresa (indicar modalidad societaria o unipersonal)
● Antecedentes Fiscales y Contractuales: deberán acreditar los mismos

antecedentes fiscales y contractuales solicitados a la empresa oferente.
● Antecedentes laborales en el rubro solicitado o similares: acreditar al

menos 6 (seis) meses de servicios en la Provincia, anteriores a la
publicación del presente pliego.
Las condiciones en que se establezcan las vinculaciones laborales será de
estricta responsabilidad de las empresas.
Renglón III
III.1 - Producto de software y servicio de implementación, soporte y

mantenimiento inicial, para la administración de agendas y turnos:
Esta solución debe permitir administrar las agendas, asignando cupos a los
diferentes efectores de la red.
El sistema debe permitir conocer los turnos disponibles según su cupo,
reservarlo, confirmar y cancelar las reservas, tanto desde el Portal de Salud del
Ciudadano, como así también desde los HIS de los diferentes efectores.
Deberá incluir la funcionalidad de permitir gestionar listas de espera con
administración centralizada por especialidad, antigüedad en la lista, hipótesis
diagnóstica, grupos etarios y complicaciones por diagnóstico.
Una vez confirmada la asignación del turno a un paciente, se deberá informar
al HIS correspondiente dicha información.
Deberá incluir el servicio de notificar al paciente de sus citas por e-mail o SMS
y enviar recordatorios.
Por lo tanto, la solución solicitada deberá encargarse de la comunicación
bidireccional con los sistemas HIS de la Red de salud, donde un paciente o HIS,
podrá obtener un turno para la especialidad o procedimiento que requiera.
Se requieren además los servicios de consultoría necesarios para la

implementación y puesta en marcha de la solución, y requisitos de
comunicación e interoperabilidad solicitados, así como también el soporte y
23
III.2 - Servicios de consultoría para la adaptación de los HIS
provinciales (Sicap y Diagnose)
Para la implementación del Sistema de agendas y turnos, es necesario que los

diferentes HIS implementen en sus sistemas las interfaces necesarias para
disparar los procesos explicados en el ítem 1 del presente renglón, incluyendo
la integración a través de mensajería estándar HL7v2 para obtener los cupos,
confirmar reserva y cancelar las mismas.
Es por esto, que se contratarán los servicios de consultoría necesarios para
adaptar los HIS de la provincia (Sicap y Diagnose), de manera que puedan
interoperar con el Sistema de Administración de Agendas y Turnos a través de
la arquitectura de servicios que defina el producto de software adjudicado en el
inciso 1 del presente renglón .
permitan interoperar a los sistemas provinciales con el Sistema de Agendas y
turnos propuesto, quedando a cargo de la Sectorial de Informática de Salud la
codificación que demande dicha solución. También será responsabilidad de la
adjudicataria, llevar a cabo de manera coordinada con el equipo de la
mencionada Sectorial, la planificación, diseño y ejecución de las pruebas de
integración necesarias, y brindar el soporte que se requiera durante la
implementación y puesta en funcionamiento en los distintos efectores, de los
cambios desarrollados por la Sectorial de Informática de Salud para lograr el
objetivo propuesto.
Renglón IV
IV.1 - Producto de Software de Inteligencia de Negocios (Business

Intelligence): el producto licitado deberá permitir la integración de las
diferentes fuentes de información o plataformas con las que trabaja el
Ministerio de Salud de la provincia de Santa Fe, y su explotación en las
áreas estratégicas que se determinen, dentro del ámbito de dicho Ministerio
y en la red de salud de la provincia.
IV.2 - Implementación, soporte y mantenimiento inicial para la

solución de BI: Se contratarán servicios de consultoría para el diseño e
implementación de una solución que permita integrar la información producida
y/o almacenada por los distintos sistemas utilizados en el ámbito del Ministerio
de salud de la provincia, y llevar a cabo su explotación a través de la
herramienta de BI licitada en el punto anterior. El equipo responsable de
brindar este servicio de consultoría, trabajará con los equipos de gestión que
24
designe el Ministerio de Salud para la definición de procesos, proyectos e

25
3.2 Detalle de los componentes
Renglón I: Solución HCEC, PSC, servicios de

implementación de las soluciones licitadas y de
consultoría para la adaptación de los HIS
provinciales.
Se solicita una solución informática que permita construir y visualizar el
historial clínico del ciudadano, usuario de la red de salud de la provincia. Este
historial clínico, -en adelante Historia Clínica Electrónica Compartida (HCEC)-,
debe nutrirse de los sistemas de información provinciales utilizados
actualmente por los efectores de salud provinciales: Sicap en los centros de
atención primaria y Diagnose en los hospitales, como así también del nuevo
HIS, - licitado en el renglón II del presente pliego -, y que será implementado en
el hospital de Venado Tuerto y hospital de Ceres en todos sus componentes, y
de manera gradual en los Hospitales Provincial de Rosario y Dr. José María
Cullen, en la ciudad de Santa Fe.
Esta solución deberá proveer un marco de interoperabilidad clínica entre la

HCEC y los sistemas de información implementados en los efectores (HIS), que
lleven adelante la integración utilizando estándares internacionales que
permitan escalar con otros sistemas del ámbito municipal o privados (estos
últimos, fuera del alcance este proyecto).
Forma parte de esta solución, permitir a los ciudadanos visualizar su historial

clínico de salud a través de un portal, como así también interactuar con el
Sistema de Agendas y Turnos - renglón III del presente pliego-, y acceder a
material educativo propuesto por el Ministerio de Salud.
Se contratarán los servicios de consultoría para la implementación de las

soluciones de HCEC y PSC, siendo requisito que los mismos se lleven adelante
por empresas regionales.
Del mismo modo, forman parte de lo licitado en el presente renglón, los

servicios de consultoría para adaptar los HIS provinciales (Sicap y Diagnose) a
la nueva estructura de la HCEC.
Renglón I.1: Historia Clínica Electrónica

Compartida
Este Sistema debe proporcionar un modelo asistencial que permita el acceso y
la consulta de forma inmediata, segura y confidencial de la información
relevante del paciente, independientemente de su ubicación geográfica o lugar
de atención (hospital, centro de atención primaria) que haya registrado la
información.
El siguiente esquema representa la solución solicitada:
26
- Gráfico 4 -
Para lograr este objetivo, el producto de software propuesto para la solución de
la HCEC, deberá implementar los perfiles IHE necesarios para conformar un
historial clínico del ciudadano y que esté accesible a toda la red de salud de la
provincia.
Los perfiles de integración a implementar son:
● XDS - Cross-Enterprise Document Sharing: Permite compartir

documentos entre organizaciones y específica la infraestructura
necesaria para que diferentes organizaciones compartan documentos
clínicos.
● PIX - Patient Identifier Cross-Referencing: (Referencias cruzadas

entre identificadores de paciente). Define los actores y transacciones
(mensajes HL7) necesarios para mantener un registro maestro de
identificadores de pacientes y proporcionar esta información a otras
aplicaciones.
La solución requerida deberá basarse en una plataforma de interoperabilidad y

contar al menos con los siguientes componentes: un índice maestro de
pacientes, un repositorio de documentos, un registro de documentos CDA y
mensajería HL7, un canal de interoperabilidad y un visor para usuario final.
27
● Índice Maestro de Pacientes: este índice es el responsable de
identificar que un determinado conjunto de registros de pacientes
representen a la misma persona, garantizando que podamos enlazar
distintos documentos clínicos CDA para conformar de forma segura la
Historia Clínica Electrónica Compartida de un paciente.
Este componente deberá además, permitir y controlar la posibilidad de
fusión de registros duplicados en el HIS de los efectores.
● Registro XDS: encargado de indexar los documentos CDA, interactúa
con el IMP para actualizar o crear al paciente bajo el dominio del efector
de origen del documento.
● Repositorio XDS.b: Los repositorios guardan documentos CDA y

mensajes HL7.
● Canal de interoperabilidad: El sistema debe proveer un marco de

interoperabilidad sobre una arquitectura orientada a servicios que
permita el intercambio de información entre los distintos sistemas
implementados en los efectores provinciales y la HCEC, según los
perfiles y estándares promovidos por IHE (Integrating the Healthcare
Enterprise).
● Documentos mínimos: Los documentos a intercambiar serán CDA,

mensajería HL7 v2, y documentos personalizados. Los mismos serán
implementados en forma evolutiva, dando prioridad a la continuidad
asistencial.
● Visor para el usuario final: deberá proveer de una aplicación web que
permita al agente de salud acceder a la HCEC, con los permisos de
autenticación correspondientes.
Este visor deberá ser parametrizable, permitiendo visualizar diferentes

vistas según el rol que consulte la historia clínica compartida (médico,
enfermero, otros).
Tal como lo muestra la gráfica a continuación, los HIS tributarán a la HCEC, a

través de los canales de interoperabilidad, no sólo los documentos CDA, sino
también mensajería HL7 v2, para al menos los siguientes eventos ADT o SIU
que se especifiquen.
28
- Gráfico 5 -
De esta manera, el producto a adquirir para la solución de la HCEC, deberá

recibir los documentos clínicos CDA, guardarlos en sus respectivos repositorios,
indexarlos en el registro XDS.b y contestar solicitudes de resúmenes y de
documentos clínicos para ser visualizados por el usuario final. Cumpliendo con
las siguientes funcionalidades:
● Envío de documentos al repositorio
● Registro de metadatos del documento en el repositorio
● Consulta de documentos
● Despliegue de los documentos
● Actualización del identificador o índice único de pacientes
29
Renglón I.2: Portal de Salud del Ciudadano
PSC – Portal de Salud del Ciudadano: Este aplicativo brindará el acceso
individual de cada ciudadano a su Historia Clínica personal en forma clara y
visual, desde donde podrá acceder a todos sus eventos clínicos registrados en
cualquier punto de la red de servicios de salud de la provincia. Este acceso se
podrá efectuar de distintas modalidades, aplicaciones web y dispositivos
móviles.
La aplicación para dispositivos móviles debe poder correr sobre sistemas

operativos Android, IOS y Windows phone, con interfaces amigables e
intuitivas. Debe prever seguridad tanto en los datos del usuario como en la
conexión al servidor.
El producto de software para la solución del portal del ciudadano, usará la

información de los documentos CDA, y mensajes HL7v2 guardados en los
repositorios XDS.b.
La información visualizada en el PSC es la información contenida en la HCEC,

que deberá cumplir con reglas de acceso y visibilidad que se definirán durante
la ejecución del proyecto a medida que se integre la información.
Asimismo, deberá permitir enrolar al ciudadano, otorgando un usuario único y

clave de acceso para el ingreso al portal, pudiendo cotizar diferentes
alternativas para el soporte.
El portal del ciudadano deberá permitir al usuario interactuar con el sistema de

turnos, visualizando las especialidades y turnos disponibles, registrando
reservas y/o cancelando las mismas.
La herramienta solicitada, deberá contemplar la funcionalidad de mostrar

material educativo o de prevención asociados a patologías para ser mostrado
al ciudadano, así como también brindar la posibilidad de incluir
progresivamente acceso a distintas páginas web, documentos y/o aplicaciones
que oportunamente se disponga desde el Ministerio de Salud de la provincia.
Renglón I.3: Servicio de implementación, soporte y mantenimiento

inicial de la solución de HCEC y el PSC
Se requieren servicios de implementación y puesta en marcha de las
soluciones licitadas para la Historia Clínica Electrónica Compartida y el Portal
de Salud del ciudadano.
La estrategia de implementación será gradual en la medida del avance de la

integración de la información de los diferentes HIS, considerándose un plazo
máximo de 24 meses.
30
Paralelamente, se deberá brindar soporte a los administradores de sistemas de
la provincia, y un servicio de mantenimiento preventivo, correctivo y evolutivo
de la solución, que permita garantizar el correcto funcionamiento de la misma
según los requisitos definidos, así como también alcanzar el objetivo de
estabilizar la implementación de esta solución, y acompañar los primeros pasos
en la mejora contínua.
El soporte y mantenimiento se llevarán a cabo durante la implementación, y

hasta un período máximo de 12 meses posteriores a la puesta en marcha
satisfactoria de la solución.
Renglón I.4: Servicio de consultoría para la adaptación de los HIS

de la provincia (Sicap y Diagnose)
Se contratarán servicios de consultoría necesarios para adaptar los software de
la provincia, para que puedan utilizar la nueva estructura de la historia clínica
electrónica compartida.
Tanto SICAP como Diagnose deberán contemplar la actualizacion de

informacion en la HCEC y visualizar los registros clínicos del paciente en la
misma, utilizando los canales de interoperabilidad clínica definidos para tal fin.
Los software de la provincia son: Sicap y Diagnose, el primero, es la

herramienta informática utilizada para el registro de atenciones ambulatorias e
inmunizaciones en los centros de salud de la provincia. Entre otras
funcionalidades en Sicap se registra la dispensa nominalizada de
medicamentos y el control de stock de los mismos; el seguimiento del paciente
en toda la red de atención (recibe por migraciones las atenciones de los HIS de
los hospitales), junto con los reportes sanitarios necesarios para tomar
decisiones; y el seguimiento de pacientes con patologías específicas. En este
sistema también se realiza la inscripción y facturación del Programa Sumar del
Ministerio de Salud de la Nación.
Sicap es un aplicativo web, desarrollado en php, con arquitectura centralizada

con base de datos MySql.
En los efectores con servicios de internación se encuentra implementado

Diagnose, un software para gestión hospitalaria compuesto por diferentes
módulos: admisión y turnos; guardia; internaciones; laboratorio; imágenes;
epicrisis; quirófano y anatomía patológica en el área asistencial y stock;
compras; pagos y facturación en el área administrativa. Actualmente 59
efectores tienen implementado al menos un módulo de Diagnose.
Es un aplicativo de escritorio desarrollado en Visual Basic, utilizando bases de

datos MySql, con implementaciones locales en cada efector. Actualmente
implementa servicios web para interactuar con la base de datos central de
31
pacientes e interactúa con otras bases de datos centrales, a través de
migraciones.
Los servicios de consultoría comenzarán una vez definidos los canales de

interoperabilidad que tendrán que implementarse en el punto 1 del presente
renglón.

permitan interoperar a los sistemas provinciales con la HCEC propuesta,
quedando a cargo de la Sectorial de Informática de Salud la codificación que
demande dicha solución. También será responsabilidad de la adjudicataria,
llevar a cabo de manera coordinada con el equipo de la mencionada Sectorial,
la planificación, diseño y ejecución de las pruebas de integración necesarias,
y brindar el soporte que se requiera durante la implementación y puesta en

32
Renglón II: Producto de Software para el ámbito hospitalario y
servicios de consultoría para su implementación
Renglón II. 1 HIS (LIS, RIS, ERP)
HIS: Solución en el Ámbito Hospitalario:

La solución ofrecida debe permitir registrar los eventos producidos durante el
proceso asistencial del paciente en el efector, integrada con los sistemas
propios del hospital (LIS/RIS/PACS/ERP/BI) e interoperando con la HCEC, a
través de los canales de interoperabilidad clínica propuestos en el renglón I del
presente pliego. En este marco de interoperabilidad, deberá implementar los
perfiles IHE: XDS - Cross-Enterprise Document Sharing: Permite compartir
documentos entre organizaciones y específica la infraestructura necesaria para
que diferentes organizaciones compartan documentos clínicos; y PIX - Patient
Identifier Cross-Referencing: (Referencias cruzadas entre identificadores de
paciente). Estos perfiles definen los actores y transacciones (mensajes HL7)
necesarios para mantener un registro maestro de identificadores de pacientes
y proporcionar esta información a otras aplicaciones.
Los documentos clínicos CDA, que deberá el HIS reportar a la HCEC, serán
definidos en forma evolutiva durante la ejecución del proyecto, dando prioridad
a la continuidad asistencial, de forma que se definan documentos para eventos
específicos como datos mínimos de intercambio.
Será una funcionalidad del HIS visualizar los registros clínicos del paciente en la
HCEC, utilizando los canales de interoperabilidad clínica definidos para tal fin.
En la integración con los sistemas hacia el interior del efector, deberá

contemplar el uso de estándares para el intercambio electrónico de
información clínica. Con la imagen digital: DICOM, con los informes de
laboratorio: el estándar de referencia de interoperabilidad semántica LOINC,
disponiendo de resultados comparables e interactuando a través de mensajería
CDA – HL7, siendo deseable la aplicación de los perfiles IHE especificados para
cada dominio.
Asimismo, la solución informática en el ámbito hospitalario, deberá interactuar

con otros sistemas de la red (especificados en el anexo II del presente pliego),
a través de los canales de interacción definidos para cada uno de ellos.
Siempre que sea posible se usarán los Servicios de Terminología Clínica, que
permitan la gestión y uso de terminologías estándares tales como SNOMED CT,
33
CIE-9-MC, CIE-10, LOINC, etc., permitiendo la normalización, el mapeo entre
terminologías y la creación de subconjuntos propios para la institución.
34
En todos los módulos en general, y en particular, aquellos que involucran la
interacción o comunicación inmediata con los ciudadanos se debe permitir el
envío de mensajes (SMS, correo electrónico) para lograr la notificación de
eventos, ya sea de agenda, turnos, o cualquier otro. Se utilizarán Proveedores
de Servicios propios de la Provincia y/o de terceros. En el caso que los servicios
de terceros tengan costos asociados, los mismos estarán a cargo de la
provincia.
La especificaciones funcionales del sistema de información para el ámbito
hospitalario son descritas en cada uno de los apartados subsiguientes:
Gestión de la configuración
Seguridad
En todos los módulos del presente pliego, el sistema deberá garantizar la

validación de acceso por usuario, permitiendo la configuración de perfiles
específicos. De esta manera, debe garantizar la integridad, disponibilidad y
privacidad de la información administrada por el sistema informático.
Con tal objetivo, deberá proveer de un módulo que permita administrar y

configurar distintos tipos de usuarios y perfiles con diferentes alcances, según
se detallan a continuación:
● Permitir definir perfiles con diferentes niveles de acceso por: efector,

sector, roles, procesos específicos, usuarios, privilegios , e información a
visualizar.
● Las habilitaciones por usuarios y/o perfiles deberán tener un período de
validez.
● La creación de usuarios deberá contemplar la posibilidad de validar
contra bases de datos externas.
● Derechos de utilización: solicitar información, visualizar, modificar,
borrar, ingresar, etc.
Deberá realizar controles y registro de:
● Transacciones
● Ubicación y horario
● Acceso interno y/o externo
● Caducidad de contraseñas por antigüedad vencida
● Mostrar o habilitar el acceso a los diversos módulos y/o sus partes en
función de rol, privilegios definidos para cada uno de los usuarios.
● Capacidad de “single-sign-on”, de manera de efectuar el ingreso por un
único sitio y alternar por los diversos módulos y sus opciones sin requerir
“login” adicionales.
● Definición de duración sesión, con opciones de : salida temporaria o
definitiva.
35
● Inhabilitación de usuarios por superación de “login” fallidos.
● Inhabilitación temporaria o definitiva de usuarios.
● Registros de “login/logout”, identificando: ET, lugar físico del suceso, día,
hora.
● Registro de “login” fallidos.
Deberá contemplar la gestión auditoría, con las siguientes características:
A dos niveles, de acceso y de transacciones sobre las Bases de Datos, de
manera de poder reconstruir y auditar operaciones sobre las mismas.
Identificando toda la información relevante para determinar al mínimo detalle
posible las partes intervinientes.
Administración y configuración de agendas
Las prácticas y atenciones brindadas por el efector se organizarán por

agendas. El acceso a las mismas estará validado por las restricciones de
acceso definidas en cada perfil de usuario del módulo de seguridad.
Estas agendas deberán estar disponibles durante todo el proceso de atención

del paciente, identificando la oferta de turnos en todos los efectores, servicios,
especialidades, prestaciones, prácticas y profesionales a cargo de brindar el
servicio, direccionando la demanda a través de cupos o bloqueos que reflejen
los acuerdos previos entre efectores de la red.
Para especificar estos cupos o acuerdos entre efectores que permitan

“compartir” turnos a la red de salud, deberá interoperar con el Sistema de
Administración de Agendas y Turnos (licitado en el renglón III del presente
pliego), a través de los canales de interoperabilidad que éste determine,
garantizando el uso de los estándares para mensajería para intercambio de
información clínica HL7 v2 o superior.
El módulo deberá permitir crear y administrar dichas agendas, contemplando

las siguientes características:
● Las agendas deberán configurarse por:
○ Días y horarios, continuos (ej. de 08:00 a 10:00 hs.) y discontinuos

(ej. de 08:00 a 10:00 y de 14:00 a 18:00 hs)
○ Atendidos por un profesional o por equipo de profesionales.
○ Con posibilidad de registrar turnos de diferente duración, en cada

agenda. (ej. un turno puede durar 15 minutos, para un control y
45 minutos para consulta por primera vez)
● La agenda deberá poder contemplar:
○ Demanda espontánea.
36
○ Turnos programados, con límites de horizonte.
● Reservar turnos para que puedan administrar otros efectores. Es

decir, con posibilidad de “proteger” o “bloquear” cierta cantidad de
turnos en las distintas agendas para ser usados por otros efectores
y/o especialidades de diferentes niveles de atención, que serán
administrados por el sistema de Agendas y Turnos, licitado en el
renglón III, del presente pliego.
● Las agendas deberán ser flexibles por períodos. Se refiere a la

posibilidad de agendar un día a la semana, uno o dos veces por mes,
en un período específico, etc.
● Deberá permitir las siguientes modificaciones, ante cancelaciones, o

reasignación de turnos otorgados por ausencias médicas:
○ Reprogramación de turnos otorgados en forma individual o grupal

a otra fecha, a otro profesional, a otra prestación y otro efector, en
un período específico.
○ Deberá permitir registrar el motivo de la reprogramación.
● Deberá contemplar un horizonte que limite el otorgamiento de

turnos, parametrizables por efector, prestación, práctica o profesional
a cargo de brindar el servicio.
● Deberá permitir otorgar turnos multi cita, es decir, podrá sugerir

todos los turnos que necesite un usuario de la red disponibles en el
mismo día.
● Control de accesos a la parametrización de agendas, como así

también, al otorgamiento de turnos en los diferentes efectores,
niveles, especialidades y profesionales.
Gestión y configuración de camas
El módulo deberá permitir configurar diferentes criterios de categorización y/o

agrupamiento de las camas disponibles en el efector, considerando las
siguientes especificaciones:
● Deberá permitir identificar la disposición de las camas dentro del efector
en piso, sector, habitación.
● Deberá permitir validar los servicios autorizados a internar en cada
sector.
● Deberá permitir clasificar las camas, considerando los siguientes
criterios:
○ Estado de la cama: libre, ocupada, reservada, fuera de servicio, en
reparación, bloqueada por aislamiento, respiratorio, de contacto, etc.
37
○ Validaciones por: categoría de edad, tipo de cuidado, si requiere
aislamiento, si tiene oxígeno, si tiene respirador, si es crítica, etc.
● Deberá comunicar al sistema de Emergencias Sanitarias (CADSIES),
especificado en el Anexo II del presente pliego, las modificaciones en la
dotación de camas del efector.
Gestión administrativa
La gestión administrativa tendrá a su cargo el registro administrativo de los

eventos producidos en los procesos de atención del paciente y su vinculación
con la red de salud de la provincia. Del mismo modo, deberá interactuar con
los demás sistemas de información del efector (ERP, LIS, RIS), contemplando
las interacciones que se describen en cada funcionalidad, como así también
con los otros sistemas de la red, descritos en el Anexo II del presente pliego.
Admisión de pacientes
El sistema deberá permitir el registro de los datos identificatorios y filiatorios

del usuario de la red de salud en su contacto con el efector, de manera que
pueda ser identificado unívocamente durante todo el proceso de atención del
mismo, cuyas funcionalidades se describen en los siguientes módulos:
Gestión de pacientes
El módulo de gestión de paciente deberá permitir administrar en forma
centralizada y unívoca, la información filiatoria de los ciudadanos y su grupo
familiar, que se relacionen con los efectores de salud de la provincia.
Una característica importante de este módulo es asegurar la integridad de los

datos, evitando la duplicidad de registros, detectándola y fusionándola cuando
esto suceda.
De esta manera se pretende garantizar la actualización de la información

básica de identificación personal, teniendo como punto de partida los datos de
pacientes existentes, de manera que estén disponible en forma centralizada,
para toda la red de salud de la provincia.
Todo evento de admisión de paciente y/o actualizaciones de datos
demográficos deberán comunicarse vía mensajes HL7 v2 - ADT, interoperando
con la HCEC, a través de los canales que defina la solución para la HCEC,
licitada en el renglón I del presente pliego.
El módulo deberá gestionar los pacientes asignándoles una identificación
unívoca, donde las principales funcionalidades son:
38
● Registro de nuevos pacientes. Deberá permitir identificar al ciudadano
en forma unívoca e inequívoca, en cada acto administrativo en el
proceso de atención del paciente.
● Búsqueda de pacientes. El sistema deberá adaptarse a distintas

opciones de identificación de paciente (pulseras inviolables con códigos:
RFID, QR, barras u otros). La provisión de los dispositivos de impresión
estarán a cargo del efector.
● Gestión de Grupo familiar.
● Deberá contemplar la posibilidad de registrar ciudadanos sin información

identificatoria ante la admisión en casos puntuales como urgencias y
emergencias.
● Deberá permitir registrar información personal identificatoria de

ciudadanos con documentación nacional e internacional.
● El sistema debe contemplar un proceso de fusión o unificación de

registros asociados al mismo paciente pero que por error, se encuentran
registrados en sistema como pacientes diferentes.
Detección de pacientes con obras sociales
Durante el proceso de admisión, al identificar el paciente, el sistema deberá

informar en forma automática el estado de cobertura del mismo, cumpliendo
con las siguientes funcionalidades:
● El sistema obtendrá la información de cobertura del paciente, a través

de la consulta al padrón provincial de obras sociales, explicitado en
Anexo II del presente pliego.
● Requerir toda información adicional que necesite el módulo de

facturación a financiadores del ERP a implementar.
● Emitir los formularios exigidos por la Superintendencia de salud, o los

definidos por otros organismos y que sean indispensables para dar
correcto cumplimiento al proceso de facturación a financiadores, como
así también contemplar la conformidad del paciente.
● Interoperar con el módulo de facturación a financiadores del ERP

solicitado.
Gestión de turnos
La gestión de turnos se realizará a través de agendas, previamente

configuradas, según lo especificado en el punto Administración y configuración
de agendas, del presente pliego.
39
El usuario podrá otorgar y/o reprogramar los turnos a pacientes en todas
aquellas agendas cuya visibilidad estará controlada por los permisos
habilitados en cada perfil de usuario.
El proceso de otorgamiento de turnos deberá estar disponible durante todo el

proceso de atención del paciente, identificando la oferta de turnos en todos los
efectores, servicios, especialidades, prestaciones, prácticas y profesionales a
cargo de brindar el servicio, direccionando la demanda a través de cupos o
bloqueos que reflejen los acuerdos previos entre efectores de la red.
Para visualizar, reservar y/o cancelar turnos en estos cupos o acuerdos entre
efectores que permiten “compartir” turnos a la red de salud, deberá
interoperar con el Sistema de Administración de Agendas y Turnos (licitado en
el renglón III del presente pliego), a través de los canales de interoperabilidad
que éste determine, garantizando el uso de los estándares para mensajería
para intercambio de información clínica HL7 v2 o superior.
Funcionalidad solicitada en la gestión de turnos:
● Reprogramación de turnos otorgados en forma individual o grupal a otra

fecha, a otro profesional, a otra prestación y otro efector, en un período
específico y registrar el motivo de la programación.
● Deberá permitir otorgar turnos multi cita, es decir, podrá sugerir todos
los turnos que necesite un usuario de la red disponibles en el mismo día.
● Deberá recepcionar del módulo de referencia y contrarreferencia, la

solicitud de un turno a otro efector, o nivel de complejidad.
● Deberá permitir programar turnos por tratamiento, (ej. tratamiento de

kinesiología, todos los martes y jueves a las 10:00 hs.)
Gestión de internación
El sistema deberá permitir registrar la internación de un paciente, en las camas

previamente configuradas, según lo especificado en el punto Gestión y
configuración de camas del presente pliego.
Para llevar adelante esta tarea, deberá poder visualizar al instante el estado
real de las camas en los sectores habilitados para el perfil de usuario
correspondiente.
Para cada internación deberá:
● contemplar el origen de la internación: Consultorio Externo, Guardia,

Quirófanos, SIES (Sistema Integrado de Emergencia Sanitaria)
● permitir clasificar la internación por nivel de cuidado (bajo, mínimo,

intermedio, alto y crítico).
40
● permitir obtener trazabilidad del paciente durante la internación dentro
del efector, a través del registro del ingreso, pases entre sectores,
servicios y egresos.
● permitir registrar internaciones transitorias.
● permitir registrar internaciones domiciliarias.
● permitir consultar toda información asociada a la internación.
● actualizar el estado de las camas en cada evento del proceso de

internación (estado Ocupada, ante una internación, estado: libre, ante
un egreso, etc.). En el mismo evento, deberá interactuar con el sistema
de Emergencias Sanitarias (CADSIES), descrito en el Anexo II del
presente pliego.
● permitir detectar internaciones con egresos administrativos inconclusos,

es decir, se registró un egreso desde la gestión de camas, pero no se
completó la información clínica/administrativa, requerida para completar
el proceso de internación y consignar la información en la historia clínica
del paciente.
● permitir el registro del egreso administrativo, requerido por la Dirección

General de Estadística Provincial.
● permitir realizar censo diario de cada sector.
● realizar cierre mensual por sector generando los archivos de datos

requeridos por la Dirección General de Estadística Provincial, para
alimentar los sistemas SIHOS y SIPES, descritos en el Anexo II del
presente pliego.
● permitir realizar los informes que el efector requiera a partir de los datos
generados desde las internaciones.
● contemplar los códigos de servicios, efectores, diagnósticos (CIE10),

medio de traslado, operaciones, causa externa (CIE10), deberán ser
compatibles con los códigos/descripciones establecidos desde la
Dirección General de Estadística Provincial, utilizando Vocabularios
controlados a través de servicios de terminología.
41
Gestión de archivo de historias clínicas
● El sistema deberá proveer un módulo para gestión de archivo de
historias clínicas físicas que contemple las siguientes funcionalidades:
○ Deberá permitir realizar la entrega automatizada, por lotes o

individuales, de fichas físicas de los pacientes citados de acuerdo
a agendamiento o por requerimiento.
○ Deberá permitir gestionar el movimiento de las fichas clínicas
(entradas y salidas) para atención, auditoria, traslados,
investigación, juzgados, etc.
○ Realizar estadística por movimiento de historias.
○ Permitir integrarse con lectores de códigos de barra para salida y
entrada de historias. La provisión de los dispositivos de soporte
para esta funcionalidad serán provistas por el efector.
○ Visualizar el número de historia clínica física en la pantalla de la
Ficha Clínica Digital.
○ Deberá permitir gestionar números de Fichas Clínicas digitales.
Gestión de traslados y derivaciones
El módulo deberá interactuar con el sistema de traslados y derivaciones de la

provincia, informando el estado de las salas de guardias y emergencias.
Asimismo, deberá registrar las solicitudes de traslados entrantes y salientes del

efector, para obtener de otros sistemas la disponibilidad de ambulancias, y
lograr una mejor coordinación y aprovechamiento de recursos.
Funcionalidad solicitada:
● Interactuar con el sistema de derivaciones y traslados de la provincia, de

manera que permita gestionar los traslados por derivación e
interconsulta, según la complejidad del paciente a trasladar.
● Registrar la información del traslado: paciente, patología, acompañantes

(agentes de salud y/o familiar) tipo de ambulancia, razón del traslado o
derivación y su integración con la historia clínica electrónica compartida.
● Interoperabilidad con el sistema de derivaciones y traslados para brindar

estado de las salas de emergencia del efector.
Gestión asistencial
42
El sistema deberá proveer a todo integrante de los equipos de salud, desde las
instancias de atención asistencial en Ambulatorio, Guardia e Internación, un
módulo específico que le permita interactuar con los demás sistemas del
efector (LIS, RIS, PACS, ERP, BI) y contemplando las funcionalidades descritas
en los siguientes ítems:
● Deberá ser configurable, dinámico y personalizable, acorde al perfil del

usuario. El usuario deberá ser un profesional habilitado con permisos
específicos para cada funcionalidad descrita.
● Consultar la ficha clínica del paciente, accediendo a toda la información
relativa al paciente registrada en el ámbito del HIS del hospital. La
información del paciente podrá ser visualizada desde diferentes vistas
(pediátrica, adultos, crítica, perinatal y neonatológica) y cuyo detalle se
entregará durante la ejecución del proyecto. Asimismo, la consulta podrá
ser accedida desde diferentes criterios de búsqueda, por ejemplo: por
paciente, diagnósticos, antecedentes comunes, servicios, episodios.
● Interactuar e interoperar con la HCEC, en lo referido a la información del

paciente contenida en el ámbito de la red de salud provincial,
respetando lo definido en el punto Historia Clínica Electrónica
Compartida (HCEC) del presente pliego.
● Interactuar con el módulo de antecedentes descrito en el punto Módulo

antecedentes presente pliego.
● Deberá interactuar con el módulo gestor de indicaciones, prescripciones

y solicitudes, que permita realizar en forma electrónica todas las
indicaciones, prescripciones y solicitudes que surjan del proceso de
atención del paciente descrito en el punto: Módulo de indicaciones,
prescripciones y solicitudes .
● Deberá permitir acceso a las agendas para realizar consultas y citas del
módulo Gestión de turnos.
● Deberá permitir acceso fácil y rápido a listas y mapa de camas ocupadas

y disponibles.
● Deberá interactuar con el módulo de internaciones descrito en el punto:

Gestión de internaciones, del presente pliego.
● Deberá permitir acceso personalizado a Librerías de Formularios,
Protocolos y Guías Clínicas, que facilite una búsqueda fácil y rápida,
recibiendo las alertas definidas en el módulo soporte para la toma de
decisiones, descritas en el punto: Soporte para la toma de decisiones ,
del presente pliego.
● Deberá permitir llevar un registro de “Notas”.
43
● Deberá contemplar la posibilidad de facilitar al profesional la realización
cálculos que surgen de la atención médica, ej. IMC, tablas, cálculos,
score, apache, categorización del riesgo, etc.
● Deberá interactuar con el módulo de constantes y parámetros vitales,

descrito en el punto: Módulo de constantes y parámetros vitales, del
presente pliego.
● Deberá permitir interactuar con el módulo de traslados y derivaciones,

descrito en el punto: Gestión de traslados y derivaciones, del presente
pliego, cuando lo requiera.
● Deberá interactuar con el módulo de referencia y contrareferencia,

descrito en el punto: Módulo de referencia y contrareferencia, del
presente pliego.
Gestión de guardias y emergencias
En el caso particular del Gestión asistencial en el ámbito de la Guardia del

efector deberá contemplar las siguientes funcionalidades:
● Debe permitir registrar el triage en el proceso de recepción y admisión

del paciente. La categorización de acuerdo al riesgo como resultado del
proceso de triage, debe reflejarse en las salas de espera de manera que
permita asignar prioridades en la atención. El formato del triage se
definirá en el proyecto.
● El módulo deberá permitir visualizar la lista y tiempos de espera de los
pacientes agendados, brindando la información necesaria para la
priorización por categorización del riesgo (producto del triage realizado
en el proceso de recepción del paciente) facilitando la gestión priorizada
de acceso y registrando en tiempo real las atenciones realizadas.
● Debe estar integrado con el módulo de Gestión asistencial, de manera
que permita al médico registrar la atención de los servicios de
emergencia, consignando la misma información que hoy requieren los
sistemas en producción (ejemplo, datos de accidentología).
● Deberá consignar las prácticas realizadas dentro del ámbito de la
guardia.
● Deberá consignar los tratamientos indicados dentro del ámbito de la
guardia.
Gestión asistencial - registro ambulatorio
44
Dentro de la gestión asistencial, el módulo de registro ambulatorio deberá
permitir registrar la información producida en la atención ambulatoria en todo
el proceso de atención del paciente, consignando la información requerida en
la Registro Diario de Consultas Ambulatorias (RDCA), definido por la Dirección
General de Estadística y utilizado en todos los efectores de la provincia.
Deberá contemplar las siguientes funcionalidades:
● permitir el registro médico de la información consignada en el RDCA,

herramienta definida por el Ministerio de Salud de la Provincia,
contemplando la normativa especificada por la Dirección General de
Estadística. En ella se consigna:
○ Si la consulta es la primera o ulterior por la patología consultada.
○ Códigos de diagnósticos (CIE10) utilizando Vocabularios
Controlados a través de servicios de terminología.
○ Texto narrativo.
○ Datos antropométricos.
○ Derivaciones o interconsultas internas y/o externas según
nomenclador provincial.
● registrar el resultado y/o informe asociado a la práctica o atención
médica realizada.
● permitir ampliar y personalizar plantillas con la información de variables
y parámetros que cada especialidad requiere, y que serán definidos
durante el proyecto. (Medicina física y rehabilitación, Nutrición y
Dietética, Odontología, familiograma, determinantes sociales, etc.)
Gestión asistencial en internaciones
Dentro del módulo de gestión asistencial, deberá contemplar un módulo de

internaciones que le permita al profesional integrante del equipo de salud del
efector, realizar las siguientes funcionalidades:
● Registrar las evoluciones diarias.
● Interactuar con el módulo de indicaciones, prescripciones y solicitudes

descrito en el presente módulo.
● Registrar la información requerida al alta del paciente, según lo

especificado para el alta registro del egreso administrativo por la
Dirección General de Estadística de la provincia.
● Registrar la epicrisis del episodio, utilizando vocabulario controlado a

través de los servicios de terminología.
Gestión de quirófano
45
Gestión de la actividad quirúrgica, permitiendo la programación de las
intervenciones solicitadas desde los servicios que lo requieran (Internación,
Ambulatorio, Guardia, SIES).
● Gestión de agenda de intervenciones y procedimientos quirúrgicos,

por día, tipo y/o quirófano:
○ Programados
○ Espontáneos
○ Urgencias
○ Coordinados entre efectores
○ Ambulatorios
○ Cirugía de día
○ Cancelación de turnos
● Listas de espera y pacientes alternativos.
● Vinculación con procesos de internación, reserva de cama, etc.
● Plan quirúrgico: diario, semanal, mensual, anual.
● Lista de procedimientos prequirúrgicos personalizables.
● Requerimientos pre-quirúrgicos automáticos a sectores o servicios
complementarios (Farmacia, Esterilización, Depósito Central, etc.). -
EN BASE A PROTOCOLOS
● Identificación inequívoca de pacientes mediante pulseras inviolables
(códigos: RFID, QR, barras, etc). La provisión del equipamiento y
consumibles no se contemplan en esta licitación.
● Registro de información (tiempos, recursos, procedimientos, actores,
riesgo, etc.) pre, intra y post quirúrgica.
● Inventario post-quirúrgico.
● Gestión de muestras de Anatomía Patológica, prótesis, implantes, y
cualquier otro material de similares características.
● Ingreso de la codificación de los procedimientos quirúrgicos en base a
la codificación definida por la Dirección General de Estadística.
● Clasificación de procedimientos a los efectos de la liquidación de
honorarios, integrado al ERP.
Módulo de indicaciones, prescripciones y solicitudes
El módulo de indicaciones, prescripciones y solicitudes, deberá permitir

generar las mismas en forma electrónica, de manera que las áreas
involucradas puedan visualizarlas y registrar su resolución.
Deberá cumplir con las siguientes funcionalidades:
● Configurar Solicitudes típicas o favoritas asociadas a perfiles de usuario.
46
● Gestionar solicitudes de: prescripciones farmacológicas, prácticas
complementarias, prescripción de dietas, indicaciones para el Cuidado
de enfermería u otro profesional, solicitud de interconsultas, internación,
utilizando filtros tales como: rango de fecha, estados, servicios clínicos,
prestaciones, etc., e interconectando aquellos sistemas necesarios
(Farmacia, listas de trabajo en LIS, RIS, módulo de enfermería, etc.).
● Deberá contemplar la funcionalidad de realizar la indicación electrónica

de todas las prácticas, indicaciones, insumos y/o servicios brindados por
el efector, obteniendo la información de los artículos y servicios
ofrecidos en el ámbito hospitalario.
● La posibilidad de realizar las prescripciones e indicaciones electrónicas,

deberá estar disponible durante todo el proceso de atención del
paciente: en consultas ambulatorias, internaciones, tratamientos
prolongados, etc.
● Deberá permitir realizar varias peticiones a la vez en forma rápida y

sencilla, así como también gestionar solicitudes a grupos de pacientes.
● Utilizar paquetes de órdenes, por ejemplo exámenes pre-quirúrgicos.
● En el caso especial de la prescripción farmacológica, deberá considerar:
○ la misma deberá realizarse por monodroga y deberá obtenerse del

listado de medicamentos que cuenta la farmacia del efector,
mostrando la existencia actualizada de los mismos e indicando si
forman parte del Formulario Terapéutico de la Provincia.
○ Si la monodroga solicitada, no está contemplada en el Formulario

Terapéutico de la Provincia, deberá interactuar con otros sistemas
provinciales, a saber: PREMO (caso especial de medicamentos
oncológicos) y Farmamed (para todo medicamento fuera del
formulario terapéutico).
○ Para el caso de los medicamentos de baja rotación y alto costo,

emitir formulario de Certificación Negativa.
○ El profesional deberá consignar diagnóstico, dosis, tiempo y

tratamiento y un texto libre para indicaciones de administración a
enfermería cuando lo requiera.
○ Emitir alertas, según criterios:
■ Tiempo de Stop (tratamiento empírico o dirigido)
■ Validación de protocolos
■ Tratamientos que requieren autorización.
47
■ Diagnósticos que implican plazos máximos de renovación
de medicación o dosis máxima permitida.
● Deberá controlar la duplicidad de indicaciones.
Soporte para la toma de decisiones
● Para el caso de prescripciones de medicamentos, deberá emitir
alertas por alergias, y/o contraindicaciones, especificadas en la Ficha
Clínica del Paciente. Además, deberá contemplar todo alerta que
surja de la validación de protocolos, descrito en el módulo de gestión
de prescripciones.
● Deberá permitir establecer Rangos de Seguridad y Alertas para cada
constante, (basados en protocolos) considerando las variables de
edad, y sexo del paciente, entre otras subdivisiones.
Módulo Antecedentes
El módulo de antecedentes, deberá permitir el registro y visualización de los

antecedentes de un paciente, contemplando las siguientes consideraciones:
● Deberá permitir registrar antecedentes familiares, configurables.
● Deberá permitir registrar un antecedente de tipo personal, asociado

al proceso de atención (diagnóstico cie10, práctica quirúrgica, etc.),
consignando la fecha de diagnóstico, y un texto narrativo.
● Deberá permitir registrar alergias, consignando fecha de detección y

texto narrativo.
● Para cada antecedente deberá poder visualizar los antecedentes del

paciente, categorizados por (familiares, personales, alergias),
consignando:
○ Fecha de diagnóstico.
○ Texto narrativo.
● Deberá permitir registrar/consultar alertas de factores de riesgos,

interactuando con el módulo: Soporte para la toma de decisiones,
descrito en el presente pliego.
● Deberá permitir consultar el carnet de vacunación, interactuando con

el módulo de vacunas de Sicap (ver Anexo II del presente pliego).
Gestión de enfermería
48
Gestionar las peticiones de prácticas de enfermería a realizar, ya sea por
indicaciones electrónicas o no, durante el proceso de atención del paciente
ambulatorio y/o internación y registrar el resultado de las mismas, impactando
sobre la gestión de insumos que corresponda.
● El módulo deberá permitir ser configurable, dinámico y

personalizable, acorde al perfil del usuario.
● Deberá permitir gestionar Peticiones: Mostrar el estado en que se
encuentran las diferentes solicitudes de los pacientes a su cargo, por
ejemplo: laboratorio, UMT, anatomía patológica, imágenes,
Interconsultas, movilización y otros centros de sangre.
● Deberá permitir visualizar todas las indicaciones a realizar, generadas
en forma electrónica o no, dentro del proceso de atención
ambulatorio o de internación, como así también las evoluciones
previas del médico, enfermera y otros profesionales, ordenadas
cronológicamente y pertenecientes al episodio en curso.
● Deberá facilitar el registro de la práctica realizada en documentos y/o
formularios definidos para enfermería, como ser: registro de
constantes clínicas, confirmación de cuidados realizados,
medicamentos suministrados (vinculados al stock de medicamentos),
Escalas, planes de cuidado, protocolos, pautas de categorización y
guías clínicas. etc.
● Deberá permitir visualizar el Mapa de Camas, ocupadas y disponibles
y permitir la Gestión de Camas según las necesidades del usuario.
● Deberá permitir visualizar y gestionar de diferentes listas de trabajo a
través de diferentes filtros tales como: cuidados programados,
exámenes, procedimientos, administración de fármacos y dietas etc.,
sean estas indicadas por médicos, enfermeras u otros profesionales.
● Deberá permitir evaluar y seguir eventos adversos.
● El registro de las prácticas deben responder a los estándares y
nomencladores utilizados en el registro único de atención ambulatoria
de la provincia de Santa Fe.
Módulo de constantes y parámetros vitales
● Deberá permitir el uso de un listado referencial de parámetros vitales

predefinidos, de acuerdo a necesidades del paciente y / o grupos.
● Contemplar el uso de filtros (fecha y hora) para la visualización de
constantes, puede ser por paciente y/ o por Unidad Clínica.
● Deberá permitir registrar medidas antropométricas, y signos vitales.
49
● Otorgar una visualización centralizada de todas las constantes
registradas al paciente, además de visualizaciones gráficas de la
evolución de constantes seleccionadas.
● Es deseable la integración con equipamiento clínico, capturando en
línea, el registro de constantes medidas por los mismos.
● Es deseable la integración con Sistema Centralizado de Monitoreo de
cada estación de enfermería disponible al momento de
implementación del módulo.
Módulo de Referencia y Contrareferencia
● Deberá permitir la gestión centralizada de referencia y

contrarreferencia de interconsultas en la red. Para cubrir esta
funcionalidad, deberá interoperar con el Sistema de Administración
de Agendas y Turnos descrito en el Renglón III del presente pliego.
● Deberá permitir realizar Interconsulta entre especialistas entre los
servicios de Atención abierta, Atención Cerrada, Urgencia y/o al alta
del paciente.
● Deberá permitir gestionar derivaciones desde las urgencias a través
de Interconsulta.
● Deberá permitir dar priorización, por ejemplo aquellos pacientes que
por diferentes causas han sido devueltos a lista de espera.
Servicio de terminología
Se solicita una solución que permita mapear los datos clínicos ingresados
durante todo el procesos de registro asistencial, a distintos clasificadores
estándares mencionados en el presente pliego, evitando que el equipo de salud
deba realizar la tarea de codificación durante el registro del dato clínico, a
través de una codificación semi-automática.
Los datos utilizados por este servicio terminológico deben estar almacenados
en un repositorio de datos clínicos cuando se han representado con el Servidor
de Terminología, y serán extraídos luego que el servidor de Terminología los
traduzca al vocabulario estándar elegido.
Deberá basarse en un modelo de datos en capas y el acceso a los mismos

desde las aplicaciònes informàticas deberá realizarse por medio de funciones o
servicios estándares.
Las capas son:
Lenguaje Natural: Es el lenguaje usado a diario tanto por pacientes como por
miembros del equipo de salud. Es un vocabulario no controlado.
50
Vocabularios de Interfase: Están representados por terminologías, listas de
términos que los usuarios de los sistemas pueden utilizar para el ingreso de
datos. Suelen construirse a partir del lenguaje natural propio de cada
Institución.
Vocabularios de Referencia: Comprenden las nomenclaturas que se utilizan

como forma de almacenamiento de los datos, con el máximo nivel de detalle y
con las referencias al modelo de conocimiento que permite su utilización por
computadoras.
Vocabularios de Salida: Son las clasificaciones y agrupaciones que se utilizan

para el análisis de la información.
Este servicio deberá representarse en español, con no menos de 1.000.000 de

términos de salud en el mismo idioma y agrupados en diferentes dominios.
Deberá reconocer términos NO válidos, o sin sentido en un registro clínico.
El oferente deberá ofrecer el servicio de administración y mantenimiento del

servidor de terminología, con el aval de especialistas en codificación clínica y
otras especialidades, procesos administrativos, farmacológicos , enfermería y
medicina.
Este servicio de terminología deberá estar disponible no sólo para las

aplicaciones relacionadas con el presente HIS, sino también disponible como
servicio de soporte para todas las aplicaciones utilizadas por el Gobierno de la
provincia de Santa Fe, que lo requieran.
ERP: Solución en el Ámbito Hospitalario
Requerimientos generales
El ERP propuesto debe enmarcarse dentro de la actual normativa del Estado

generando todas las integraciones necesarias y disponibles.
Las integraciones requeridas con otros sistemas serán especificadas en Anexo
II del presente pliego.
Las funciones básicas requeridas para el ERP son las siguientes:
● Automatizar los procesos básicos (administrativos y de apoyo) del
hospital: dispensa de medicamentos, gestión de insumos, gestión de
recursos humanos y gestión contable financiera.
● Debe proveer un sistema integrado que maneje, registre y controle
todas las funciones administrativas y económicas del Hospital.
● Debe emitir toda la documental exigida por los organismos de control
de la provincia.
51
● Respecto del proyecto ERP este DEBE ser contratado de manera
conjunta con el HIS (Sistema de Información Hospitalario), logrando
con ello una mejor y mayor integración, versatilidad, utilización de la
información, garantía de servicios y respaldo tecnológico.
Dispensa de medicamentos
Comprende el registro de la medicación entregada al paciente ambulatorio, y

su dispensa hacia las salas de internación en dosis unitaria, por prescripción
médica realizada en forma electrónica o manual, a todos los usuarios de la red
de salud de la provincia.
● Deberá contemplar la posibilidad de responder a prescripciones

electrónicas y/o manuales. Las prescripciones manuales pueden
originarse en otros efectores de la red de la provincia.
● Deberá permitir la identificación unívoca e inequívoca del paciente a
quien se realizará la dispensa. Del mismo modo, en el caso de
internaciones deberá identificar el sector y la cama del paciente
internado.
● Deberá contemplar el control de dispensas por tratamiento y/o
protocolos, especificados en el punto Gestión asistencial.
● Deberá permitir consultar la existencia de la droga solicitada en el
stock de las bodegas del efector.
● Deberá poder consultar las entregas realizadas al paciente en otros
efectores de la red de salud. Para esto podrá consultar la información
a través del canal de interoperabilidad con otros sistemas descripto
en el Anexo II del presente pliego.
Gestión de insumos
Se considera gestión de insumos a todo medicamento, material médico

quirúrgico, odontológico, material de curaciones, etc., que se requiera para
llevar adelante el proceso de atención de un paciente, asegurando la
trazabilidad de los mismos.
La gestión de los insumos abarca las siguientes tareas:
● Solicitud del insumo al área correspondiente, interactuando con otros

sistemas de información de la red de salud de la provincia. Para el
caso de medicamentos, deberá interoperar con SUFYD, en los
eventos de centralización de pedidos, solicitud de medicamentos,
recepción de mercadería y distribución, cuyo detalle se encuentra en
el Anexo II del presente pliego.
52
● La gestión de la compra hasta la dispensación ambulatoria o en
internación, retroalimentando el sistema a los efectos de la reposición
de mercancías.
● Todos los movimientos de ingreso y egreso de los diferentes

depósitos incluyendo transferencias internas.
● Multi-Catálogo (Medicamentos, Material de Curaciones, Descartables,

Material quirúrgico, etc.).
● Deberá permitir personalizar y parametrizar la visibilidad de insumos,

organizando por Código, Presentación, Marca Comercial, lote, fecha
de vencimiento, etc..
● El sistema deberá permitir administrar el catálogo general de

insumos contemplando la utilización de códigos internos asociados a
códigos de barra o QR (o similar).
● Debe permitir la gestión de la logística inversa: devoluciones, canjes,

disposición final, etc.
● Debe permitir la Trazabilidad de los productos almacenados

(seguimiento de lotes y caducidad)
● Debe permitir Manejo de distintas categorías de stock (mínimo,

máximo, y alerta)
● Debe permitir la Gestión de roturas, pérdidas, desecho por

vencimiento, etc.
● Debe permitir la Gestión de préstamos a otras instituciones de salud.
● Debe permitir la Ubicación de los productos que se encuentran en la

bodega.
● Debe permitir la Gestión de inventario de existencias (valorado y no

valorado).
● Debe permitir la Generación de inventarios actuales y a fecha

anterior.
● Debe permitir el Intercambio de mercadería entre almacenes
● Debe contar con un Informe para desestiba, de insumos para

satisfacer los pedidos acorde a los criterios de almacenaje.
● Debe contemplar la gestión de dispensación al paciente internado a

través de unidosis.
● Debe permitir la Gestión automática de Reposición de Almacenes y

Farmacias.
53
● Debe contar con un módulo de tratamiento prolongado.
● INFORMES: Informes predefinidos, indicadores, que faciliten la toma

de decisiones y el control de la gestión. Por ejemplo: Brindar
información individual y globalizada de los movimientos de todos los
insumos que se gestionan a través de Centros de consumo,
Farmacias y del Depósito de Medicamentos. Brindar información de
demanda satisfecha e insatisfecha en consultas parametrizables.
● Debe contar con una herramienta que permita la confección de

informes según necesidades. Por ej.: Informes de consumos por
paciente, por médico, por artículo, por grupo terapéutico, etc., en
períodos de tiempo a definir por el usuario que realiza la consulta.
Gestión de recursos humanos
La informatización de los procesos de apoyo a la gestión de recursos humanos

dentro del efector, y su interacción con el Sistema de Recursos Humanos de la
Provincia de Santa Fe (SARH).
● Administración de diferentes tipos de horarios, en los que deberán

contemplarse los horarios rotativos y médicos con cargas horarias
semanales distribuidas en distintas frecuencias.
● Control de asistencia. (debe contemplar la integración del dígito

pulgar, facial o tarjeta)
● Administración y control de Franquicias y novedades.
● Reporte y comunicación de franquicias y novedades al Sistema de

Recursos Humanos de la provincia para imputación en la liquidación
de haberes. Detallado en Anexo II del presente pliego.
● Reporte de horas trabajadas, que deberá interactuar con sistemas

internos de liquidación de incentivos, que se calculan en función a la
cantidad de horas trabajadas por los agentes.
● Proporcionar información para análisis.
Gestión contable y financiera
Integrar los procesos de contabilidad, facturación a obras sociales, compras y

tesorería.
El ERP propuesto debe proporcionar apoyo a la gestión administrativo-técnica
mediante los siguientes módulos:
54
Módulo Contabilidad.
Debe apoyar la gestión financiera del efector, de manera que respete las
normas y procedimientos técnicos especificados por la ley de contabilidad de la
provincia y que permita la obtención de los libros legales, balances básicos e
informes financieros que sean necesarios, para el análisis, interpretación y
proyección de la información económico - financiera de toda la organización, de
acuerdo a la legislación y normativa vigente.
El sistema deberá operar con datos centralizados y en línea, el registro de

operaciones de cualquier índole que afecte a la contabilidad, se ingresará
desde las fuentes generadoras de los eventos y actualizarán en forma
automática en los maestros de cuentas contables, presupuestarias y de gestión
de costos. La actualización de los movimientos contables deberá ser en línea,
permitiendo registrar, procesar y consultar la información en todas las
unidades orgánicas del efector que sean debidamente autorizadas.
Debe permitir un eficiente control de los flujos de dinero hacia y desde el

Hospital, apoyando las funciones administrativas y de control del Área de
Tesorería del mismo.
Debe contemplar la generación de archivos para transferencias bancarias.
Debe permitir la clasificación del gasto, e imputación del mismo por Fuente de
Financiamiento.
En el proceso del pago debe contemplar la liquidación de retenciones y su

exportación a los sistemas provistos por AFIP y API.
Módulo Gestión Patrimonial.
El módulo debe contemplar las siguientes funcionalidades:
● Permitir el control del inventario y los procesos contables de

actualización de los bienes físicos.
● Contemplar para los bienes, el valor histórico y el valor actual.
● Los procesos contables deben respetar los estándares establecidos por

la ley de la provincia que rige a los hospitales públicos.
● Las compras, movimientos, y/o bajas de estos bienes deben estar

integrados a las funciones que controlan los pedidos, autorizaciones y
órdenes de Inversión.
● Debe permitir clasificar los bienes del Activo Fijo de acuerdo a su

ubicación y uso, permitiendo la mantención de parámetros y tablas para
dar la posibilidad de adaptarlo a las necesidades del Hospital.
55
● Debe permitir el registro de altas y retiros de bienes con sus respectivos
procesos contables, contar con capacidades para efectuar procesos
individuales y masivos.
● Emisión de informes.
Módulo Gestión Presupuestaria.
Su principal función debe ser formular y controlar presupuestos de gastos e

inversiones. Además, debe contemplar las siguientes funcionalidades:
● Debe contar con facilidades de navegación de manera de poder ir desde

los presupuestos a los datos del gasto/costo y los hechos económicos
que los originaron.
● Contará además con un módulo unificado de costos y gastos que

permita conocer y determinar el aporte y el costo de cada una de las
actividades del Hospital, permitiendo formular y controlar gastos e
inversiones de capital.
● Consultar las transacciones que originan los costos/gastos por cada uno
de los atributos (Centro de pedido, Actividad, Proyecto, Orden de Trabajo
y otros). Debe permitir la formulación y manejo de más de una versión
de presupuestos.
Módulo Abastecimiento.
Debe proveer al Hospital de una administración efectiva de las compras, un

control de los almacenes (bodegas) y una integración con la contabilidad,
incluyendo los procesos de cierre (diario, mensual, anual).
El sistema debe ser capaz de relacionar los conceptos de gasto de material con
los conceptos definidos para control de costos; por lo tanto debe contemplar
funciones como consumo de material en actividades y/o proyectos de
inversión, el cual deberá estar altamente integrado con el módulo de gestión
de presupuesto.
Además deberá incluir funcionalidades para la gestión de compras, como

control administrativo de pedidos de materiales y servicios, desde centros de
pedido, registro y evaluación de cotizaciones, gestión de órdenes de compras,
órdenes de provisión, etc.
56
En el caso de las funcionalidades para la gestión de almacenes, se debe contar
con mantención de catálogos y/o padrón único provincial considerando sus
ubicaciones, bodegas, grupos de clasificación, gestión de pedidos de material,
devolución, consumos, transferencia de materiales, recuperación de
materiales, gestión de stock, etc.
Módulo Administración de Contratistas y Contratos.
Este módulo debe permitir ingresar y controlar la gestión de los contratistas del
Hospital, contener funciones para mantenimiento de postulantes e inscriptos
en los registros de contratistas y en los de consultores y su situación a la fecha
de requerimiento de los reportes, sus especialidades y sus categorías, sus
datos entre otros, de teléfonos, fax, correos electrónicos, nombre de
sociedades y personas constituyentes de ellas administración en forma
estandarizada de la información y procedimientos asociados a los contratos del
Hospital, registro y mantención de los recursos que el contratista pone a
disposición de la Compañía y sus características.
Debe permitir, a requerimiento del usuario, la definición flexible de parámetros

de evaluación y control con que el Hospital medirá la actuación del contratista
y sus recursos. Es necesario una relación en línea con los sistemas de pago del
Hospital de manera que pueda controlar la individualización completa del
Contratista, de los estados de pago, en curso y cursados, cálculos de reajuste,
intereses, multas, control de garantías y fechas de vigencia. Debe crear
reportes de los contratistas que incluyan datos históricos, los que se
encuentren en curso con el Hospital y con terceros, todos ello ordenados a
discreción del usuario según distintos parámetros.
Módulo de facturación a financiadores
Tal como lo prevé la ley de descentralización hospitalaria, el módulo de

facturación a financiadores debe contemplar las siguientes funcionalidades:
● Deberá identificar la cobertura del paciente en todo proceso de atención

del paciente, emitiendo el formulario requerido por la Superintendencia
de Salud de la Nación, para aquellos pacientes que están activos en
algún plan de obra social.
● Deberá emitir una factura a la obra social por las prestaciones

realizadas, utilizando los nomencladores y convenios activos para cada
efector.
● Llevar un registro de cobros y/o débitos en las cuentas corrientes de las

obras sociales.
57
● Estos movimientos deberán estar integrados con los sistemas financieros
correspondientes.
● Deberá facilitar los reportes e informes necesarios para permitir el

control y gestión de todo el proceso de facturación.
Gestión de Reportes e informes
El sistema de información deberá completarse con un sistema de

análisis de información que utilice la información generada en las
diferentes áreas asistenciales y módulos de una manera constante e
integrada.
Se deberá proveer de una herramienta dinámica, flexible y de fácil utilización
por parte de los usuarios, que permita generar nuevos informes, basados en el
modelo de datos y/o en los datos registrados en los distintos módulos del
sistema.
Se persigue con ello disponer de:
● Informes predefinidos o estáticos.

● Informes ad-hoc.
Deberá contar además, con una herramienta que permita a los usuarios
avanzados explotar la información, para propósitos de apoyo a las decisiones y
para obtener información de carácter ejecutivo (Ej. Herramienta de Data
WareHousing, con desarrollo de cubos).
Con cualquiera de estas herramientas, se deberán poder obtener y cruzar

datos de todas las actividades de las distintas áreas del efector, desde las
siguientes perspectivas: Estadísticas, Epidemiológica y Administrativa.
Perspectiva Administrativa
Deberá brindar reportes de la Información Administrativa del Efector, que

analizada junto a la información de producción, permitirá obtener indicadores
de rendimiento y costo de cada sector o servicio.
Consideramos aquí, toda la información involucrada en los procesos del

ERP:
● Dispensa de medicamentos.
● Gestión de Insumos.
● Gestión de recursos Humanos
● Gestión Contable y Financiera
58
● Facturación a Financiadores
Perspectiva estadística
Contar con la producción estadística de todos los servicios del efector, basados
en los registros clínicos y administrativos, y los indicadores especificados por la
Dirección General de Estadística.
● Deberá emitir la producción de todos los servicios del hospital,

basados en la unidad de producción de cada uno de ellos, ejemplo: n°
de atenciones, cantidad de egresos, cantidad de raciones, cantidad
de recetas dispensadas, etc.
● Toda información de producción deberá permitir ser clasificada, por

grupo etáreo, sexo, u otro atributo del paciente o la práctica
realizada, según lo requiera el operador.
● Las consultas deberán ser detalladas o totalizadas, como así también,

deberán permitir su visualización geocodificada, según domicilio del
paciente o efector.
● Deberá generar los indicadores que surjan de la relación producción -

recursos, que especifique la Dirección General de Estadística de la
Provincia y que se describen en anexo adjunto.
● Las consultas deberán ser flexibles y permitir la posibilidad de

personalizarlas.
● Deberá enviar los archivos de producción a la Dirección General de

Estadística, para que se informen al Ministerio de Salud de la Nación
y cuyo diseño se detalla en anexo adjunto.
● Deberá permitir generar informes e indicadores que permitan

optimizar el uso de las camas disponibles como así también conocer
la realidad dentro de cada efector según sean requeridos por la
Dirección General de Estadística Provincial
Vigilancia epidemiológica
Deberá brindar la información indispensable para conocer la conducta y/o

riesgos, que afectan a un conjunto de ciudadanos, ante una patología
determinada, con el fin de intervenir en los mismos a través de la prevención y
el control.
Es indispensable conocer esta información a través de servicios GIS (sistemas

de información geográfica).
59
El sistema deberá tomar las bases nomencladas y consumir los servicios de la
IDESF (Infraestructura de Datos Espaciales de Santa Fe). Ver Arquitectura de la
Solución.
Interoperabilidad HIS/ERP
El sistema de información hospitalario (HIS), encargado del registro y obtención
de información en todos los ámbitos de la atención del ciudadano en el efector,
ya sea en los procesos del negocio como en los servicios de apoyo, deberá
proporcionar información al sistema de gestión de recursos (ERP) en todas las
especificaciones descritas en el punto: ERP, del presente pliego, a través de
lenguajes informáticos estandarizados, como HL7, DICOM, u otros.
LIS: Solución en el Ámbito Hospitalario

El LIS propuesto deberá permitir una gestión integral no sólo desde el punto de
vista analítico, sino también administrativo, que incluya módulos de
Estadísticas, Configuración e informes.
La empresa adjudicataria proporcionará el detalle de las funcionalidades
específicas de la aplicación para cada una de las actuaciones incluidas en el
proceso analítico, así como la solución específica para los laboratorios
especializados del Hospital. Específicamente el LIS deberá permitir gestionar
los flujos y rutas de las muestras en los laboratorios, cambiar su
comportamiento en tiempo real, mantener la trazabilidad, etc, siguiendo el
flujo continuo de muestras.
El LIS permitirá explotar, en términos de volumen y de complejidad la

información contenida en la base de datos.
Para ello deberá contar con los siguientes módulos que permitan:
1. Gestión de peticiones, resultados e informes.

● Deberá contar con un registro unificado de todas las muestras
recibidas junto con las pruebas analíticas que se les solicitan. Los
usuarios pueden solicitar cualquier tipo de prueba analítica:
❖ Bioquímica.
❖ Hematología.
❖ Coagulación.
❖ Hormonas.
❖ Inmunología.
❖ Microbiología.
❖ Serología.
60
● Dependiendo de la configuración las pruebas podrán solicitarse
individualmente, por perfiles de pruebas. Se deberán poder definir
catálogos de pruebas por Servicio peticionario discriminando
según prioridad de la petición.
● Se deberá poder obtener listados con todos los pacientes
analizados en un período concreto, lo que facilita al usuario un
control del movimiento registrado en su laboratorio en ese plazo.
● El sistema permitirá la impresión de etiquetas para los tubos que
permitan una identificación unívoca de estos.
● Se requiere poder registrar y trazar el circuito de las muestras
permitiendo conocer quién y cuándo las muestras son
recepcionadas en el laboratorio y distribuidas a cada sección. La
recepción de muestras se realizará mediante la identificación de
los códigos de barra de los tubos de muestra.
● Las opciones de registro de resultados podrá hacerse de forma
automática mediante la conexión con analizadores,
independientemente de su marca o modelo, o mediante registro
manual por medio de hojas de trabajo o muestra a muestra.
● El usuario podrá acceder a las muestras para la introducción de
resultados, modificación, para su repetición, la localización para
identificar al paciente o consultar resultados pendientes.
● Permitirá ver la evolución numérica y gráfica de los resultados de
cada paciente y acceder rápidamente a aquellos cuyos resultados
están fuera de los valores de referencia de cualquier análisis.
● Se requiere disponer de un módulo integrado para las muestras de
la sección de microbiología que permita la gestión específica de
estas, tanto a nivel de listas de trabajo como de resultados.
● Permitirá la validación automática de aquellas muestras que
cumplen una serie de condiciones definidas por cada usuario. Las
muestras no validadas automáticamente podrán validarse de
forma manual.
● En la validación se deberá de tener en cuenta los valores de
referencia de cada análisis, valores de pánico y delta check.
2. Gestión de la configuración.
● El sistema deberá de disponer de un módulo de configuración, de
fácil manejo y con acceso a usuarios autorizados, para la gestión
de las tablas maestras.
61
● La configuración de usuarios, seguridad y permisos con distintos
niveles o grados de acceso al sistema, deberá ser definido en el
módulo de administración de usuarios único, común a todos los
módulos del HIS.
● Configurar las pruebas analíticas incluyendo valores de referencia
según población (edad, sexo, etc.), unidades, valores de pánico,
delta check, etc.
● Definición de resultados cualitativos aceptados por prueba
analítica.
● Definición de perfiles y catálogos de petición.
● Establecer los criterios de validación para cada prueba (reglas de
decisión, rangos de alarma, etc.).
● Configurar la hojas de trabajo por sección según la estructura del
Hospital. Hojas de trabajo específicas para la sección de
microbiología.
3. Gestión de estadísticas y trazabilidad de usuarios.
● Deberá contar con un módulo de estadísticas menú con listados y

filtros que permitan obtener la información requerida sobre los
procesos registrados en el sistema por cada una de las opciones
disponibles.
● El sistema deberá presentar la posibilidad de interconexión con
aplicaciones externa tipo planillas de cálculos.
El LIS deberá proveer las interfaces de Conectividad necesarias entre el LIS y

los distintos tipos de equipos utilizados por el laboratorio, como mínimo según
se detalla (alguno de los los equipos se contratarán en modalidad comodato,
otros por compra, no siendo posible precisar identificación de los mismos) :
● Química Analítica:
1 (uno) Autoanalizador automático multiparamétrico

(comodato)
1 (uno) Analizador de gases en sangre (comodato)
1 (uno) Analizador de iones (compra)
● Hematología:
1 (uno) Contador Hematológico (comodato)
62
Interoperabilidad HIS/LIS
El LIS deberá facilitar la perfecta integración con el HIS y otros entornos del
ámbito hospitalario. La estrategia de integración o interoperabilidad con otros
Sistemas de Información deberá caracterizarse por la adopción de estándares
de comunicación sanitarios:
Se deberá de disponer de 2 líneas de trabajo independientes y compatibles:
● Por una parte se recibirán las peticiones, vía mensajería HL7, desde el
sistema HIS del efector. De la misma forma, ante consultas desde el HIS, se
devolverán los resultados una vez validados.
● Se habilitará un acceso externo a través de una URL a la aplicación tanto

para el registro de la petición (petición electrónica) como para la consulta
de los resultados analíticos y emisión de los informes.
La empresa adjudicataria deberá realizar los trabajos que sean necesarios para
integrar la solución ofertada con los sistemas de información disponibles en el
Hospital (HIS/ERP). Los productos software y licencias necesarios para la
integración con los sistemas especificados en la presente licitación, será por
cuenta del adjudicatario.
RIS: Solución en el Ámbito Hospitalario
Sistema de información radiológica (RIS) - Características

Generales:
Se requiere un sistema RIS para la gestión administrativa, funcional, documental y

del conocimiento de áreas de Diagnóstico por Imágenes.
El objetivo es dotar al Efector de Salud de una solución tecnológicamente

avanzada y correctamente dimensionada que de soporte a las necesidades de los
distintos servicios que trabajan con imágenes médicas.
El software deberá contar con todos los elementos necesarios para un uso clínico
adecuado. Se deberán incluir todas las licencias necesarias para asegurar una
funcionalidad continuada según las necesidades crecientes del hospital.
El software deberá permitir utilizar el sistema de modo que el funcionamiento sea

lo más ágil, correcto y completo posible.
RIS - Esquema solicitado:
La solución debe contemplar un área de gestión de imagen médica formada por

módulos independientes. Estos módulos se harán cargo de cubrir las siguientes
macro funcionalidades:
63
● RIS (Radiology Information System). Este sistema debe ofrecer todos los
procesos necesarios para gestionar la actividad de los servicios de imagen.
● PACS (Picture Archiving and Communications System). Este sistema

gestiona el almacenamiento, recuperación, distribución y presentación de
imágenes (mediante visores clínicos integrados). Este módulo será provisto
por el Ministerio de Salud de la provincia de Santa Fe.
Tecnologías Implementadas
Implementación integral en base a software libre: DCM4CHEE
Soporta DICOM 3
Implementa interfaces HL7 v2.x
Diseñado en conformidad con perfiles/actores IHE (Integrating the

Healthcare Enterprise) del framework de radiología.
Facilita la integración con sistemas de información en general y

particularmente en un entorno IHE.
Desarrollado en Java.DOO
Motor de aplicaciones JBoss (implementación de código libre de la

especificación JavaEE, licencia LGPL)
Motor de Base de Datos:
● MySQL
IHE Integration Profiles:
● Access to Radiology Information
● Consistent Presentation of Images
● Evidence Documents
● Key Image Note
● Patient Information Reconciliation
● Simple Image and Numeric Report
● Scheduled Workflow
● Basic Security
Software libre: licencia múltiple GPL, LGPL
● Visores. Deberá proporcionar una doble solución:
64
● Visor clínico. Su principal misión es la de permitir el acceso a las
imágenes a través de web. Debe ser una solución que privilegie la
velocidad de acceso a las imágenes pero ofrecer, al mismo tiempo
abundantes herramientas de elaboración de imagen. Será provisto
por el fabricante de cada uno de los equipos de captura asociados al
área de de referencia, en su etapa de grabación de los estudios en un
medio portable (CD/DVD).
● Visor diagnóstico. Estos visores deben ofrecer funcionalidades de

elaboración de imagen avanzadas que faciliten la labor de
diagnóstico por imagen. Será provisto por el fabricante de cada uno
de los equipos de captura asociados al área de referencia.
Cada módulo deberá poderse instalar en servidores independientes de manera que

se pueda decidir la configuración de despliegue que sea considerada más
conveniente.
Con la utilización de un sistema RIS/PACS se pretende automatizar, agilizar y

organizar la labor de sus profesionales y, sobre todo, mejorar la atención clínica.
Por esta razón se espera que la adopción de esta solución introduzca un flujo de
trabajo unificado donde cada usuario pueda desde el RIS acceder a todas las
funcionalidades que necesite, pertenezcan al módulo que pertenezcan.
La solución buscada facilitará que el radiólogo informante pueda:
● Consultar el trabajo diario que debe desempeñar, buscar los estudios, los
informes o los pacientes que le interesan.
● Abrir, una vez que tenga identificado el examen que quiere informar, el
visualizador de imágenes con un único click. Este se abrirá precargando el
examen que el médico ha seleccionado: el radiólogo deberá poder informar
mientras visualiza las imágenes, además, deberá poder acceder de forma
inmediata al histórico de las mismas y, en general, a la historia clínica
radiológica (imágenes de estudios anteriores).
● Informar usando un sistema de dictado que deberá ser perfectamente

integrado en la solución.
● Grabar en un CD/DVD los exámenes e informes de un paciente.
Así, por ejemplo, el técnico también podrá:
● Consultar el trabajo diario que debe desempeñar seleccionando la

modalidad o las fechas de los estudios que le interesan.
● Encontrar que la lista de trabajo se carga de forma automática, de

manera que no tenga que insertar datos de paciente y/o estudio de forma
manual, sin embargo, podrá cargar manualmente los casos que lo ameriten.
● Conocer dónde se encuentra el paciente con el fin de optimizar su tiempo.
65
● Solucionar de forma simple e inmediata los posibles errores que pueden
ocurrir, como, por ejemplo, el asociar una prueba al paciente equivocado.
● Imprimir en un CD/DVD los exámenes e informes de un paciente.
Así, por ejemplo, el administrativo podrá:
● Consultar los huecos y la planificación del personal.
● Ejecutar las estadísticas que se necesiten para mantener controlado el

trabajo y la organización del departamento.
Todas estas funcionalidades se realizará desde un único punto: el RIS, que será el
orquestador de todas las demás funcionalidades del sistema.
RIS - Descripción funcional

El Sistema de Información de Radiología deberá proporcionar las herramientas
necesarias para gestionar la actividad y las exigencias de todos los servicios de
imagen médica.
Deberá cubrir el flujo de trabajo de los profesionales de un servicio de diagnóstico

por imagen permitiendo hacer un registro informático de la actividad que se realiza
en su servicio, desde el registro de la solicitud, a partir de los datos enviados desde
otros sistemas de información, hasta la elaboración y validación del informe
definitivo y la entrega de la actividad realizada para que se pueda hacer, en caso
de corresponder, la gestión de la facturación, tanto interna como externa.
Deberá comprender los procesos necesarios:
● Gestionar las citas/peticiones y los recursos de los departamentos de

imagen médica recibidas por HIS.
● Priorizar de las pruebas atendiendo a diferentes reglas o criterios definidos

en cada departamento.
● Recoger y planificar la actividad realizada en los servicios de diagnóstico por

imagen.
● Elaborar los informes de los exámenes realizados.
● Consultar y controlar la información relacionada con dicha actividad.
● Controlar los flujos de trabajo de los servicios de diagnóstico por la imagen.
● Integrarse en los flujos de trabajo de la organización.
Interoperabilidad HIS/RIS/PACS
El sistema RIS/PACS deberá actuar coordinadamente con el sistema HIS del
Hospital. Para ello deberán realizarse diversas integraciones para mantener
una sincronización e integridad de datos adecuada.
66
La integración con el HIS del Hospital deberá alcanzar, como mínimo, las
siguientes funcionalidades:
● Creación y actualización de datos administrativos de pacientes.
● Creación y actualización de solicitudes.
● Creación y actualización de citas.
● Visualización y actualización de informes de resultados.
Para dichas integraciones, toda mensajería referente al intercambio electrónico

de información clínica debe basarse en el estándar HL7. En cuanto al
intercambio de imágenes, deberá respetarse el estándar DICOM.
Canal de Interacción con otros sistemas provinciales

El HIS, deberá interoperar e integrar información con otros sistemas propios del
Ministerio, sistemas transversales de la administración pública central y
diferentes programas nacionales. Para esto deberá utilizar los canales de
interacción definidos por la Sectorial de Informática del Ministerio de Salud y
detallados en Anexo II, del presente pliego.
Estas interacciones definidas en el Anexo II, son los requisitos mínimos de

integración, sin perjuicio de lo cual deberán contemplarse todos los
requerimientos de integración que se identifiquen en el transcurso del
proyecto.
Para lograr la integración descrita, se deberá considerar la interoperabilidad

técnica, semántica y organizacional de la solución propuesta con los otros
Sistemas.
Para lograr esta interoperabilidad se solicita que contemple – en el caso que lo

permita – el protocolo utilizado internacionalmente para el intercambio
electrónico de información clínica, el estándar HL7 (Health Level 7).
Renglón II. 2 Servicios de implementación, soporte y

mantenimiento inicial del producto para la
solución en el ámbito hospitalario
Como parte de este renglón, se contratarán servicios de consultoría para la

implementación de la herramienta informática del ámbito hospitalario (HIS). El
alcance de la misma comprende la implementación completa de todos los
módulos de HIS en el hospital de Venado Tuerto y en el hospital de Ceres,
prevista para mediados del año 2017, y posteriormente, la implementación
modular del producto en los hospitales Provincial de Rosario y J. M. Cullen de la
ciudad de Santa Fe.
67
La estrategia de implementación será cuidadosamente planificada en
coordinación con el equipo de proyecto del GSF.

El soporte y mantenimiento se llevarán a cabo desde el inicio de la primera

implementación, y hasta un período máximo de 12 meses posteriores a la
puesta en marcha satisfactoria de la última de ellas.
68
Cada implementación deberá realizarse a través de la integración con
Empresas de localización Provincial, siendo deseable que la ubicación real se
encuentre en la ciudad de implementación.
La/s Empresa/s u Organización/es oferentes deberán acreditar un vínculo

laboral para la implementación del renglón citado, con empresas radicadas en
la Provincia de Santa Fe.
La/s empresa/s con las cuales se establezca la relación, deberán constar en la

presentación de la oferta, con los siguientes datos:
● Nombre o Razón Social
● Domicilio Legal. Se considera el domicilio legal para acreditar la

localización en la Provincia.
● Tipo de empresa (indicar modalidad societaria o unipersonal)
● Antecedentes Fiscales y Contractuales: deberán acreditar los mismos

antecedentes fiscales y contractuales solicitados a la empresa oferente.
● Antecedentes laborales en el rubro solicitado o similares: acreditar al

menos 6 (seis) meses de servicios en la Provincia, anteriores a la
publicación del presente pliego.
Las condiciones en que se establezcan las vinculaciones laborales serán de

estricta responsabilidad de las empresas.
Renglón III: Producto de Software y servicio de

implementación, soporte y mantenimiento
inicial, para la Administración de Agendas y
Turnos
Renglón III.1 - Producto de software y servicio de implementación,

soporte y mantenimiento inicial para la administración de agendas y
turnos: Esta solución debe permitir administrar en forma centralizada, los
cupos de agendas asignados a cada efector, según se acuerde en la red de
servicios de salud, por especialidad, práctica o nivel de atención.
El sistema debe permitir al ciudadano - a través del portal - y a los efectores de

la red, conocer los turnos disponibles según su cupo, reservarlo, confirmar y
cancelar las reservas.
69
Para lograr esta comunicación con los sistemas HIS de los diferentes efectores,
la solución solicitada deberá encargarse de la comunicación bidireccional con
los mismos, donde un paciente o HIS, podrá seleccionar, reservar y/o cancelar
un turno para la especialidad o procedimiento que requiera.
Una vez confirmada la asignación y/o cancelación del turno a un paciente, se

deberá informar al HIS correspondiente dicha información. Del mismo modo
que el HIS, deberá informar al sistema de administración de agendas y turnos,
cualquier modificación en la agenda del cupo acordado.
La solución deberá incluir la funcionalidad de gestionar listas de espera con

administración centralizada, por especialidad, antigüedad en la lista, hipótesis
diagnóstica, grupos etarios y complicaciones por diagnóstico.
Deberá incluir el servicio de notificar al paciente de sus reservas y/o

cancelaciones de turnos por e-mail o SMS y enviar recordatorios.
La comunicación entre sistemas, deberá utilizar los estándares para

intercambio de información HL7 v.2 o superior, incluyendo mensajes de tipo
ADT para registrar pacientes y actualizar los datos demográficos y SIU para
intercambio de información de citas.
El sistema deberá permitir visualizar las citas vinculadas a un paciente,

identificando si fue atendido o no, cancelaciones y motivos de cancelación.
Del mismo modo, deberá brindar la posibilidad de obtener informes y reportes

con indicadores como: porcentajes de cancelaciones, motivos de cancelación,
porcentajes de ausentismo, y los que se determinen durante el proyecto, para
una especialidad, práctica, profesional, paciente o efector.
Se requieren además los servicios de consultoría necesarios para la

implementación y puesta en marcha de la solución, y requisitos de
comunicación e interoperabilidad solicitados. La estrategia de implementación
y puesta en marcha será gradual y se avanzará simultáneamente con los
efectores que implementen el nuevo HIS, con los que usan SICAP y en forma
gradual se van a ir incorporando los Hospitales que trabajan actualmente con
Diagnose, considerándose un plazo de 12 meses y según la planificación que
realizara oportunamente el equipo de Proyecto del GSF.

El soporte y mantenimiento se llevarán a cabo durante la implementación, y

hasta un período máximo de 12 meses posteriores a la puesta en marcha
70
satisfactoria de la solución.
Renglón: III.2 - Servicios de consultoría para la adaptación de los HIS

provinciales (Sicap y Diagnose)
Para la implementación del Sistema de agendas y turnos, es necesario que los

diferentes HIS implementen en sus sistemas las interfaces necesarias para
disparar los procesos explicados en el ítem 1 del presente renglón, incluyendo
la integración a través de mensajería estándar HL7v2 para obtener los cupos,
confirmar reserva y cancelar las mismas.
Es por esto, que se contratarán los servicios de consultoría necesarios para

adaptar los HIS de la provincia (Sicap y Diagnose), del presente pliego -, de
manera que puedan interoperar con el Sistema de Administración de Agendas
y Turnos a través de la arquitectura de servicios que defina el producto de
software adjudicado en el inciso 1 del presente renglón .

permitan interoperar a los sistemas provinciales con el sistema de
Administración de Agendas y Turnos propuesto, quedando a cargo de la
Sectorial de Informática de Salud la codificación que demande dicha solución.
También será responsabilidad de la adjudicataria, llevar a cabo de manera
coordinada con el equipo de la mencionada Sectorial, la planificación, diseño y
ejecución de las pruebas de integración necesarias, y brindar el soporte que
se requiera durante la implementación y puesta en funcionamiento en los
distintos efectores, de los cambios desarrollados por la Sectorial de Informática
de Salud para lograr el objetivo propuesto.

La descripción de estos sistemas, se detalla en el Renglón I, inciso 4 del

presente pliego.
Renglón IV:
Herramienta de Inteligencia de Negocios y consultoría

para la integración de datos y explotación de
la información.
Renglón IV.1 - Producto de Software de Inteligencia de Negocios

(Business Intelligence)
71
Se requiere la provisión e instalación de un producto de software de
Inteligencia de Negocios, que permita la integración de las diferentes fuentes
de información o plataformas con las que trabaja el Ministerio de Salud de la
provincia de Santa Fe, y su explotación en las áreas estratégicas que se
determinen, dentro del ámbito de dicho Ministerio y en la red de salud de la
provincia.
Licenciamiento y Propiedad Intelectual

El adjudicatario deberá proveer 50 licencias concurrentes o en su defecto,
120 licencias nominales.
Respecto de la modalidad de licenciamiento:
● Se entiende por "licencia nominal" al derecho de utilización de software que se asigna a

sólo una persona física para usar el software instalado en uno o más servidores, pudiendo
eventualmente modificarse dicha asignación a una persona física distinta.
● Se entiende por "licencia concurrente" al derecho de utilización simultánea de una

licencia y un producto por una cantidad establecida o ilimitada de usuarios. En caso de no
especificarse en la oferta el límite de usuarios concurrentes, se entenderá como ilimitada.
De manera general, deberán cumplirse los requisitos detallados en el punto “5.

Consideraciones Generales” de las bases del presente pliego, que incluye
condiciones para las licencias.
Y en particular, si la herramienta ofertada ya se encontrase entre las

soluciones en uso en el GSF (independientemente de las versiones del
producto), la adjudicataria será responsable de la rehabilitación del servicio de
mantenimiento y actualización del producto pre-existente si fuera necesario. Se
deberá garantizar la continuidad de la solución previamente implementada, así
como también deberá asegurarse disponer de los entornos configurados
permitiendo alojar a todas las instancias de la aplicación, nuevas y pre-
existentes, en el caso de que el GSF así lo requiera.
Requerimientos de la herramienta para la Integración de fuentes

de información y repositorio de datos
Requerimientos referidos al origen de la información y la carga

de datos
Deberá cumplir con los siguientes requerimientos:
● detallar las tecnologías soportadas por la herramienta. La solución
mínimamente debe poder extraer datos y escribir datos desde y hacia los
siguientes motores de bases de datos y tecnologías de repositorios de datos:
Oracle, PostgreSQL, MS-SQL Server, MySQL, SYBASE, DB2, Informix, Access,
XML, Web Services, planillas y archivos de textos con registros de tamaño
fijo y variable.
72
● soportar orígenes y destinos heterogéneos en el mismo proceso de
integración.
● consolidar diferentes tablas de hechos con estructuras diferentes sin que
tengan que provenir de una misma fuente de datos.
● utilizar la sintaxis completa de comando SQL
(StructuredQueryLanguage), estándar ANSI (American
NationalStandardsInstitute).
● presentar capacidades para ETL (ExtractTransform and Load) -
Extracción, Transformación y Carga de datos y EL-T, en forma integrada a
la herramienta desde una misma interfaz.
● programar la ejecución de los procesos de carga de datos integrados a la
herramienta.
● visualizar de manera gráfica el modelo de datos después que los datos
sean cargados.
● alertar al usuario si existió alguna falla en el proceso de carga de datos y
mantener automáticamente la última versión cargada con éxito.
● guardar los desarrollos realizados en un repositorio central.
● este repositorio debe soportar el versionado de los diferentes objetos
definidos.
● el repositorio debe soportar el trabajo concurrente de múltiples
desarrolladores participantes del mismo proyecto.
● la herramienta debe permitir realizar ingeniería reversa sobre los objetos
(tablas y archivos) sobre los que trabajará, para simplificar la carga de las
definiciones de los mismos.
● definir funciones de transformación propias para ser reutilizadas en
diferentes procesos.
● brindar una manera de organizar el proyecto de desarrollo.
● permitir la gestión de la configuración y versionado del desarrollo y
evolución de los procesos y transformaciones.
● comparar objetos de diferentes versiones para determinar sus
diferencias.
● generar reportes para documentar el proyecto. Los reportes deben
incluir, orígenes y destinos de los procesos de integración, la definición
de ciertos objetos desarrollados, las comparaciones de diferentes
versiones de un determinado objeto.
● generar archivos de log de los procesos de ETL.
● ejecutar los procesos de extracción en múltiples servidores, permitiendo
configurar qué proceso corre en qué servidor.
● permitir que los servidores que ejecuten procesos, puedan estar
distribuidos geográficamente de forma que las extracciones se ejecuten
cerca de donde residen los datos.
● definir múltiples disparadores para cada proceso de extracción.
● definir disparadores que dependan del estado de finalización de múltiples
procesos anteriores.
73
● configurar permisos por conexión individual y por tipo de conexión
(BBDD, Archivo, etc.).
● desarrollar y configurar procesos de carga desde de dispositivos móviles.
● realizar validaciones como violación de valores no nulos, referencias de
integridad, valores fuera de rango y otros. Los registros que no cumplan
las mismas deben ser separados en un apartado para su posterior
análisis y corrección.
● los registros erróneos deben poder ser reinsertados en el flujo de
posteriores ejecuciones una vez solucionados los problemas presentados.
● debe ser posible hacer una depuración (debug) de los desarrollos,
pudiendo establecer breakpoints en puntos preestablecidos, avanzar la
ejecución paso a paso y parar la ejecución ante un error.
● permitir instalarse en servidores dentro de la red de la provincia (on-
premise).
Repositorio y modelos de Datos

● Repositorio de datos estructurados: datawarehose y eventualmente data
marts que se consideren apropiados (sujeto a aprobación del equipo del
GSF).
● Repositorio de metadatos: modelo de datos relacional y modelos MOLAP, y/o
ROLAP u HOLAP (Hibryd OLAP), para la explotación de los datos.
Monitoreo y Administración
● La herramienta debe poseer una consola de administración única tanto
para configurar los procesos de extracción y acceder a las ejecuciones ya
realizadas, como para configurar accesos a las visualizaciones.
● configurar y administrar las conexiones de datos a través de la consola
de administración.
● Debe permitir guardar registro de todas las ejecuciones realizadas en el
pasado,indicando el tiempo transcurrido en cada una de las ejecuciones,
la cantidad de registros transmitidos, las sentencias SQL generadas y los
errores encontrados.
● Desde la consola de administración y monitoreo debe ser posible re-
lanzar procesos que hayan quedado truncos por algún error.
● Debe ser posible tomar backup del repositorio de los desarrollos
realizados y del registro de ejecuciones.
● Debe ser posible exportar e importar la definición de los objetos
desarrollados para ser trasladados de un repositorio a otro.
Desempeño
● garantizar el acceso a una gran cantidad de memoria RAM.
● optimizar el uso de recursos del hardware interviniente
74
● instalar múltiples nodos para balanceo de carga y alta disponibilidad.
● permitir que los nodos que atienden las consultas de los usuarios, estén
distribuidos geográficamente.
● definir en qué nodo se ejecutará un determinado tablero o si podrá
ejecutarse en más de uno para alta disponibilidad y balanceo de carga.
● definir en qué nodo se ejecutará un determinado proceso de extracción o
transformación de datos o si podrá ejecutarse en más de uno para alta
disponibilidad y balanceo de carga.
Seguridad
● Debe ser posible crear diferentes usuarios para las diferentes personas
participantes del proyecto. Los usuarios deben estar identificados por una
contraseña.
● Los usuarios deben poder ser autenticados contra un servidor LDAP externo.
● Dependiendo del rol de cada usuario, debe ser posible crear usuarios
asignando diferentes perfiles de acceso.
● Los perfiles deben poder discriminar los siguientes roles:
- Desarrollador (crear y modificar los procesos de integración y otros
objetos
- relacionados)
- Operador (lanzar y visualizar las ejecuciones)
- Administrador de proyecto
- Administrador de Versiones
Requerimientos para la explotación de la información
Se requiere una herramienta de Business Intelligence (Inteligencia de

Negocios) que asista en el análisis y la presentación de datos y permita contar
con información relevante y oportuna para la toma de decisiones.
Objetivos
La herramienta de Inteligencia de Negocios deberá:
● permitir consolidar los datos procedentes de múltiples fuentes de
información en una sola aplicación.
● explorar las asociaciones entre los datos
● facilitar la toma de decisiones en tiempo real y en forma colaborativa
● contar con tecnologías que garanticen un desempeño óptimo en la ejecución
de consultas.
Se deberá informar explícitamente el tipo de tecnología ofrecida con esta
finalidad, y particularmente si la herramienta permite almacenar todos los
datos a ser consultados por los usuarios en todos los niveles de detalle
75
directamente en memoria RAM (Random Access Memory) del servidor, de
forma compacta, o sea no accediendo a los datos en cada consulta, sino a
los datos en memoria.
● presentar los datos con gráficos atractivos y tecnológicamente avanzados
● descubrir tendencias ocultas posibilitando descubrimientos que impulsen las
decisiones
● interactuar con aplicaciones, cuadros de mando y análisis interactivos
● interactuar con otras herramientas de BI
Funcionalidades de desarrollo y visualización

● permitir que todo el desarrollo se haga desde un navegador web sin requerir
instalación de componentes adicionales, ni equipos desktop, ni software
adicional en las estaciones de trabajo
Reportes y Tableros de control

● crear filtros de selección en el propio gráfico y / o leyenda a través de la
acción de hacer clic y arrastrar.
● desarrollar tableros y análisis desde dispositivos móviles como tabletas y
teléfonos.
● analizar tableros desde dispositivos móviles adaptando la visualización al
tamaño del dispositivo (ResponsiveDesign).
● presentar funciones que ayuden al desarrollo de métricas de al menos los
siguientes aspectos: la agregación, la manipulación de cadenas y fechas,
funciones lógicas, la manipulación de formas y funciones financieras.
● exportar datos a formato MS-Excel u LibreOffice.
● permitir que cada objeto (gráficos, tabla) pueda ser impreso separadamente.
● guardar el estado de las selecciones para utilizarlas nuevamente luego.
● mostrar los datos consultados, a los usuarios, en forma de gráficos de
barras, torta, línea, tacómetros, semáforos, etc.
● generar historias con datos estáticos desde la misma interfaz.
● buscar valores por cualquier parte del texto de un campo.
● buscar valores en toda la información relacionada a la vez.
● mostrar los valores relacionados a un filtro realizado y también los valores no
relacionados sin requerir desarrollos adicionales.
● filtrar sobre todos los campos relacionados sin necesidad de definir sobre
qué campos se va a filtrar de antemano.
● generar nuevas visualizaciones sobre modelos publicados y validados sin
que pueda modificar el modelo subyacente.
● compartir los gráficos o tablas desarrollados con otros usuarios con mismos
niveles de permisos.
● subir archivos propios de datos desde la misma interfaz de la aplicación.
● reflejar una selección realizada por el usuario en todos los gráficos o tablas
de un tablero simultáneamente.
76
● definir métricas y dimensiones para ser reutilizadas por los usuarios al
desarrollar nuevas visualizaciones como así también poder usar los campos
directamente.
● ejecutar un tablero o un conjunto de análisis en un equipo portátil
(notebook) sin conexión con el servidor (off-line) con todas las
funcionalidades previstas en este apartado.
● agregar información en gráficos de dispersión cuando se muestren números
muy grandes de puntos (miles).
● modificar el ordenamiento o los colores utilizados sin necesidad de editar o
modificar los tableros publicados.
● hacer análisis multidimensional sin depender de tener la información pre
agregada ni en tener las jerarquías predefinidas.
● desarrollar las visualizaciones mediante arrastrar y soltar (drag and drop)
incluso en dispositivos táctiles.
● tablero disponible en un portal BI con diversos gráficos de los diferentes
indicadores y tablas.
● tablero "portable" de consumo sin conexión a la red (off line) el cual permita
filtrar dinámicamente.
● Programación de reportes clave y tableros de forma automática y
distribución mediante envío a diferentes usuarios por mail.Guardado de
reportes clave con al menos 5 versiones (fotos) del reporte.
● Todos los reportes que accedan al data warehouse deberán utilizar un único
modelo (metadata)
Navegabilidad
● Navegabilidad sobre las tablas y cubos, utilizando las diferentes dimensiones
e indicadores involucrados sobre los diferentes temas.
● Posibilidad de "saltar" de un reporte a otro haciendo click en la variable clave
que se desea profundizar.
● Posibilidad de “saltar” de una tabla o cubo, a reportes de detalle
posibilitando analizar la información a distintos niveles.
● desde el tablero deberá ser posible hacer drill (click para profundizar)
● posibilidad de "saltar" de un reporte a otro haciendo click en la variable
clave que se desea profundizar.
Mobile
● Los reportes deberán ser posibles de acceder desde dispositivos móviles,
dando la posibilidad al usuario de realizar filtros de manera dinámica (en el
momento de la consulta). Ejemplo: filtrar un paciente para ver su detalle de
información, visualizar tablero, mapa, etc.
Elaboración de informes
77
● reutilizar los gráficos y objetos definidos en los tableros para envío
programado de reportes estáticos.
● enviar informes en formato MS Powerpoint, PDF, Pixel Perfect, HTML,
LibreOffice y MS Word.
● poseer un portal web que permita acceder únicamente a informes
estáticos distribuidos.
● permitir acceder al portal usuarios ajenos a la organización proveyendo la
autenticación necesaria.
● guardar varias versiones de los informes ejecutados.
● permitir a los usuarios finales de los informes que tengan los permisos
necesarios suscribirse a los informes que quieran recibir.
Eventos y Alertas
● Deberá permitir la configuración de alertas, especificando:
- Eventos disparadores y/o una condición a evaluar a partir de los
indicadores y métricas definidos.
- El momento en que deberá efectuarse la comprobación (“al abrir un
documento”, “después de recargar”, etc.).
● Las alertas deberán poder disparar alguna de las siguientes acciones:
- mensajes al operador
- envío de una notificación o informe vía email: permitiendo configurar
asunto, contenido (estático y/o dinámico) y destinatarios.
- envío de una notificación vía SMS: permitiendo configurar contenido
(estático y/o dinámico) y destinatarios.
· Deberán poder ser disparadas desde aplicaciones externas.
Scorecard
● Brindar de forma integrada, o permitir la implementación de una
herramienta que permita realizar scorecard, con ingreso manual de los
valores de cada métrica para un grupo de usuarios administradores.
● Dar visualización a los usuarios del scorecard, métricas y mapa por medio
del portal BI, sólo para un grupo de usuarios determinado.
● Implementar un set de reportes complementarios para visualizar en forma
gráfica:
- Por cada scorecard: Cantidad de métricas en sus estados, Proyectos en
sus estados, Resumen Valores de las métricas
- Resumen de los diferentes proyectos
- Evolución de métricas en forma de semáforo y valores.
- Resumen de métricas de cada scorecard con su puntuación
Modelo de Análisis Predictivo / Minería de Datos
78
● Modelo para soporte de análisis predictivo.
● Deberá estar integrado, o poder conectarse de forma directa con la solución
de BI para alimentar el modelo.
Integración e interoperabilidad con otros sistemas

Los requerimientos solicitados en este apartado deberán:
● compartir información entre diferentes niveles de gobierno, proporcionando
búsquedas rápidas y simultáneas a través de múltiples sitios y fuentes de
datos externas. Deberá buscar automáticamente y consolidar los resultados
de múltiples sistemas, lo que permitirá acelerar el acceso a información
valiosa.
● integrar nuevas visualizaciones y gráficos no nativas mediante desarrollos
web custom e integrarlas en los tableros como si fueran visualizaciones
nativas.
● integrar con las funcionalidades de backend como generación y disparo de
tareas, asignación de licencias, definición de permisos, etc.
● compartir información entre diferentes niveles de gobierno, proporcionando
búsquedas rápidas y simultáneas a través de múltiples sitios y fuentes de
datos externas. Deberá buscar automáticamente y consolidar los resultados
de múltiples sistemas, lo que permitirá acelerar el acceso a información
valiosa.
● integrar visualizaciones en gráficos y portales.
● permitir a aplicaciones de terceros conectarse a través de mecanismos
estándar y obtener resultados de métricas calculadas por el sistema.
Gestión de los datos y la seguridad

La herramienta deberá:
● permitir el acceso a bases de datos disponibles en el mercado, sea a través

de ODBC (Open Data Base Conectivity) u OLEDB (ObjectLinking and
Embedding Data Base).
● ofrecer independencia de la base de datos, permitiendo la conexión de la
misma aplicación con diferentes bases de datos relacionales, dimensionales,
u otras fuentes externas de manera simultánea, sin limitarse a la utilización
de ninguna base de datos para el almacenamiento de los datos.
● definir roles y permisos a usuarios individuales o a grupos de usuario que
permitan según lo que se disponga:
- Desarrollar nuevos tableros
- Desarrollar nuevas visualizaciones sobre tableros existentes
- Compartir visualizaciones desarrolladas con otros usuarios
- Generar nuevas conexiones de datos
- Desarrollar nuevas extracciones de datos
- Administrar grupos de procesos de carga
● contar con acceso al sistema basado en roles a través de un esquema de
79
acceso de usuarios autorizados.
● permitir controles de administración avanzados del sistema, para añadir,
suprimir o suspender usuarios y ajustar permisos o valores de seguridad.
● debe usar CAS o LDAP para la autenticación.
● definir grupos para filtrar la información de acuerdo a cada usuario.
(reportes, tablas, cubos, secciones de la metadatos y registros de la base de
datos)
● los reportes, tablas, cubos e información (datos) deberán ser filtrados de
forma automática teniendo en cuenta el grupo del usuario que ingresa.
● definir qué usuarios o grupos de usuarios tendrán permiso de exportar datos
e impresiones.
● analizar de forma gráfica el consumo de licencias y acceso a tableros por
parte de los usuarios.
● manejar encriptación en la comunicación entre diferentes servicios de la
plataforma.
● establecer la seguridad a nivel de registro y a nivel de columna.
● impedir que un usuario final pueda definir permisos ni sobre escribir
permisos definidos en la consola de administración,reservando este derecho
solamente a un administrador que pueda manejar los permisos en forma
centralizada.
● auditar desde la consola de administración qué usuarios tienen acceso a qué
tableros.
● auditar desde la consola de administración qué usuarios tienen acceso a qué
fuentes de datos.
● auditar desde la consola de administración qué usuarios tienen permisos
para desarrollar nuevos tableros.
para desarrollar nuevas visualizaciones sobre tableros ya publicados.
para compartir visualizaciones desarrolladas sobre tableros ya publicados.
para desarrollar nuevas historias sobre tableros ya publicados.
para compartir historias generadas sobre tableros ya publicados.
Auditoría
● Implementar un módulo de auditoría que permita monitorear la utilización de
los reportes acerca de qué reportes se ejecutaron, quién lo ejecutó, fecha
hora de ejecución, etc.
● permitir controles de auditoría para supervisar a los usuarios y asegurarse
de que el sistema se utilice de acuerdo con las políticas vigentes.
● Contar con un set de reportes disponibles para consultar la información de
auditoría.
80
Georreferenciación
● El sistema deberá poder tomar las bases nomencladas y consumir los
servicios de la IDESF (Infraestructura de Datos Espaciales de Santa Fe). Ver
Arquitectura de la Solución.
Renglón IV.2 - Implementación, soporte y mantenimiento inicial para

la solución de BI
Relevamiento, diseño e implantación de la solución de BI
Se contratarán servicios de consultoría para el diseño e implementación de una

solución de Inteligencia de Negocios (Business Intelligence) en el ámbito del
Ministerio de salud, y su explotación a través de las herramientas de BI licitada
en el Renglón IV.1.
La adjudicataria deberá establecer a los fines de este proyecto, un equipo

de consultoría cuyos integrantes deberán trabajar con los equipos de gestión
que designe el Ministerio de Salud para la definición de procesos, proyectos e
El sistema propuesto deberá ofrecer una completa explotación de datos que

permita conocer la actividad realizada a cualquier nivel de desagregación y
también disponer de las informaciones que permitan planificar mejor los
recursos a fin de mejorar la actividad asistencial. Para ello deberá disponer de
una base de datos orientada a la explotación de datos generada a partir de
distintas bases de datos de sistemas operacionales del Ministerio de Salud, o
de Fuentes externas de información.
Todos los diseños propuestos (arquitectura, modelos de datos, etc.) deberán

ser acordados y aprobados por el equipo del GSF.
Las actividades que deberá desarrollar dicho equipo, contemplan las

siguientes:
Planificación: Esto incluye la selección de un enfoque de (arriba hacia abajo,

de abajo hacia arriba o combinado), la selección de la arquitectura apropiada
de Data Warehouse, la selección adecuada del ámbito de información, fuentes
de datos y tamaño del metamodelo y la estimación de planes del programa.
Se deberá incluir el desarrollo de una Matriz de riesgo de implementación, con
ponderación y acciones propuestas para mitigar los impactos negativos.
El plan de desarrollo del proyecto, su alcance y el cronograma correspondiente,
deberán ser acordados con el equipo de proyecto del GSF.
81
Relevamiento y definición de Requerimientos: Será responsabilidad de la
consultoría la cuidadosa selección y especificación de requerimientos,
considerando tanto los de negocios como los de tecnología, con el fin de lograr
un proyecto sólido que arroje resultados con rapidez.
En esta tarea será fundamental la participación activa de los usuarios, para lo
cual el Ministerio de Salud designará un equipo de Gestión para que trabaje
junto a los consultores en la definición de los indicadores y los requerimientos
de información.
Sin perjuicio de los requerimientos que se recojan oportunamente, se

listan a continuación una serie de requisitos que deberán ser
contemplados por la solución:
- Requerimientos de integración de datos

El oferente deberá contemplar todas las tareas relativas a la integración de las
diversas fuentes de datos necesarias para satisfacer los requerimientos del
proyecto, analizando el formato de los datos a utilizar, las compatibilidades de
los sistemas y la factibilidad de la solución. A tal efecto se deberán realizar las
reuniones necesarias entre las partes involucradas.
Interconectar al menos treinta (30) fuentes de información o plataformas

que se definirán durante el diseño de la solución, además de las que se
listan a continuación, con las que trabaja el Ministerio de Salud de la
provincia de Santa Fe.
Plataformas (sistemas descritos en el Anexo II del presente pliego)

A los efectos de este inventario consideramos a cada uno de los siguientes
sistemas, como una única plataforma de información:
1. CADSIES: Sistema de Emergencias Sanitarias.

2. SARH: Sistema de Administración de Recursos Humanos de la Provincia.
3. SUFyD: Sistema único de farmacia y Droguería Central.
4. SICAP: Sistema de información para Centros de Atención Primaria
Base de datos MySql - Implementado actualmente en 559 efectores
5. Diagnose: Sistema de gestión hospitalaria
Bases de datos MySql - 59 efectores tienen implementado al menos un
módulo.
6. HCEC: Historia Clínica Electrónica Compartida, licitada en el Renglón I del
presente pliego.
7. Nuevo Sistema de Gestión Hospitalario: Solución informática integral
licitada en el presente pliego.
82
Otras fuentes de información
8. IDESF: Infraestructura de Datos Espaciales de Santa Fe.

9. Tablas maestras: comunes a todos los Sistemas del Ministerio de Salud
10. Padrón de Obras Sociales: base de datos de afiliados a Obras Sociales
Nacionales, Provincial y Prog. Nacional Incluir Salud.
- Tableros de control y Reportes

● Se requiere en promedio, un máximo de 3 tableros de control con los
distintos niveles de desagregación que se especifique, por cada área
definida (hasta 50 áreas).
TABLERO DE CONTROL: entendemos por tablero de control o cuadro

de mando a la “organización sistemática de información” de la organización
en una “vista” (o interfaz gráfica), incluyendo un conjunto de indicadores,
métricas y datos, cuyo seguimiento y evaluación periódica permitirá contar
con un mayor conocimiento de la situación monitoreada, facilitando el
ejercicio de la gestión y toma de decisiones estratégicas.
Cada tablero tendrá una “arquitectura de información” y según cómo se
diseñe, podrá permitir al operador “navegar” de manera dinámica a través
de la información disponible, mediante filtros, criterios de
agregación/desagregación, enlaces, etc.
A los fines del presente pliego, se considera un único tablero de control (o
cuadro de mando) a todas las instancias posibles de un tablero que resulten
de “navegar” a través del mismo de forma dinámica, seleccionando filtros,
agregando o desagregando información, etc.
● Se requiere en promedio, un máximo de 5 reportes con diferentes

análisis de las aperturas e indicadores definidos, por cada tablero de
control que se especifique.
REPORTES: son instrumentos que organizan y exhiben la información

obtenida de las bases de datos, con una finalidad, y según un formato y
diseño definidos con la intención de facilitar su interpretación a los
destinatarios. Los tableros de control o cuadros de mando pueden ser una
parte de los reportes y su base fundamental, pero otro aspecto importante
son los e-business insights o conclusiones que surgen a partir de los mismos;
no es suficiente contar con la medición de indicadores y controlarlos, es
importante conocer qué los afecta, e inferir su impacto.
- Scorecard
● Presentar una metodología para la implementación del scorecard.
83
Implementar una solución de scorecard para cada perfil estratégico
definido, de 20 métricas estratégicas y un mapa estratégico, con
información real, objetivo y tolerancia en cada métrica.
Algunos requerimientos básicos de información para el Ministerio de

Salud
Los siguientes requerimientos básicos, y generales de información, pretenden

sentar una base mínima y una referencia sobre algunas de las funcionalidades
que se deberán contemplar en la solución, independientemente de los demás
requerimientos específicos descritos y los que surjan de la actividad de
relevamiento y análisis que se llevará a cabo oportunamente.
● La plataforma deberá ser una herramienta de consulta ágil, dinámica y

de tiempo real para la visualización de datos estadísticos y de mapeo
sobre la actividad de la salud pública a nivel provincial, permitiendo en
forma sencilla reducir la granulación y selección hasta llegar a la
visualización (de mapeo y datos) de la ocurrencia en efectores de salud o
barrios.
● La plataforma deberá brindar información estadística, en tiempo real, sobre

las incidencias de las distintas alertas contempladas en la solución.
● Se deberá desarrollar una aplicación específica, que posea al menos 5

solapas y cada solapa tendrá al menos 6 objetos del tipo Tabla Simple, Tabla
Pivotante y/o cubos, Mapas y Gráficos de Barra, Torta, Dispersión, etc.; las
cuales atenderán las siguientes temáticas:
○ Cuadro general de métricas claves.
○ Información estadística de salud y georreferenciada actual e histórica.
○ Información epidemiológica georreferenciada actual e histórica.
○ Información operativa y georreferenciada de los distintos efectores.
○ Información sobre encuestas de satisfacción y confianza de la comunidad.
● Brindar herramientas para el Análisis de la Salud tanto a nivel

Estratégico como Táctico (estadísticas de salud, de tendencias; mapeo
basado en actividades, lugar, fecha; asignación de recursos; planes de
salud, análisis de tendencias basada en datos externos; tasas de satisfacción
y de confianza, reincidencia, muerte).
84
● Brindar herramientas y conocimiento para la Inteligencia de la Salud a
nivel Táctico (análisis de datos de salud; búsqueda global a través de
conjuntos de datos ilimitados; empleo de inteligencia georreferencial;
análisis de la salud a través de colaboración interhospitalaria y/u otros
efectores públicos y privados).
● Brindará información estadística sobre el personal tanto a nivel

Estratégico como Táctico (cantidad de personal por Región y por efector y
sus dependencias inferiores; edad; género; grado y/o jerarquía; actuaciones
y/o investigaciones realizadas; ausentismo y causales; capacitaciones y
especializaciones).
● La plataforma deberá brindar un Cuadro de Mando Integral en el que se

desplegarán el resumen con información obtenida en tiempo real, de las
métricas claves que se dispongan en los sistemas de información
utilizados por los centros de salud y áreas de Gestión del Ministerio de Salud,
desde las siguientes perspectivas: Estadística, Epidemiológica y
Administrativa.
● Deberá ofrecer un mapa de la salud, tanto en tiempo real como un mapa

que muestre evoluciones y tendencias, como así también históricos con su
evolución, contemplando al menos:
○ Hechos vitales
○ Morbilidad
○ Sala de situación de salud
○ Planes de salud
○ Calidad y resultados
○ Accesos y descargas desde los sitios web / portales del Ministerio de

Salud.
● Deberá brindar y facilitar la generación de informes y análisis, de los

distintos centros de salud, permitiendo el modelado de escenarios
posibles para la gestión de futuras acciones (Ej.: Asistir para determinar si la
adquisición o puesta a disposición de un nuevo equipamiento u otro tipo de
recurso en un efector o en una Región determinada, tendrá un impacto en su
rendimiento).
● Deberá brindar informes con datos estadísticos y mapeo sobre
85
tendencias y análisis de distintos indicadores y métricas de la salud
pública.
● Brindar información para la gestión de Rendición de Cuentas.
● También deberá brindar información estadística, en tiempo real, sobre la

calidad o resultado del servicio de salud pública, como por ejemplo:
tiempos de atención, tiempos de espera, triage, grado de satisfacción y de
confianza de la comunidad (a partir de eventuales encuestas realizadas por
el Ministerio de Salud u otros organismos), etc. Brindar informes detallando
gráficos de tendencias y tablas sobre la satisfacción y aceptación en la
provincia de Santa Fe en cada Región, Distrito, Ciudad, Pueblo o Paraje.
Análisis y diseño: en esta etapa se incluyen las siguientes tareas, en base a

los requerimientos recogidos en la etapa anterior.:
- Identificar las fuentes de datos y las transformaciones necesarias.
- Diseñar la arquitectura de datawarehose apropiada
- Diseñar y documentar el o los modelos de datos apropiados para facilitar la
explotación de la información.
- Modelo conceptual de datos.
- Modelos lógico y físico de datos, y la arquitectura de
almacenamiento.
- Diseñar los procesos de transformación y carga de datos.
- Se debe diseñar adicionalmente el área de Stage.
- Diseñar Los reportes, alertas y demás pantallas.
Implementación:
El equipo que brindará este servicio, trabajará con el equipo de proyecto del
GSF con la finalidad de coordinar todas las tareas involucradas en este punto.
Serán responsables de todas las tareas vinculadas a los despliegues de la

solución, que sean requeridas y coordinadas con el equipo de proyecto del GSF.
Para la explotación y visualización de datos se utilizara el Software provisto por

la adjudicataria según el Renglón IV.1 de la presente licitación.
Las actividades básicas contempladas en este punto son:

- Instalación y configuración del software de Integración de Datos en
los ambientes de Desarrollo, Test y Producción, de manera coordinada con
los administradores de sistema del GSF.
86
- Si es necesario, instalación y/o configuración del/los motores de
base de datos necesarios y cualquier otro software de base requerido.
- Instalación y configuración del software de BI licitado en el Renglón
IV.1, en los ambientes de Desarrollo, Test y Producción, de manera
coordinada con los administradores de sistema del GSF.
- Configuración de la herramienta de monitoreo y administración.
- Documentar y entregar el manual de instalación indicando los
usuarios creados, directorios utilizados, configuraciones realizadas, puertos
de red utilizados, acceso a las herramientas de administración, etc.
- Documentar y entregar el manual de operación para
administradores, el cual debe incluir información de cómo utilizar la
solución. Debe indicar cómo iniciar y detener los servicios, cómo tomar
backup y hacer restore, cómo aplicar parches, ubicación de los archivos de
log, y toda actividad que sea requerida para mantener el buen
funcionamiento de la solución en el tiempo.
- Fuentes de información: acceso / disponibilidad de las fuentes de
información y plataformas necesarias.
- Integración de datos: ejecución de los procesos de carga de datos hacia
el área de stage y ejecución de los procesos ETL y/o ELT definidos para
nutrir el/los repositorios finales.
- Configuración de la herramienta de explotación: creación de perfiles,
grupos, usuarios, configuración de parámetros, etc.
- Implementación de los requerimientos según el diseño producido en la
etapa anterior.
- Pruebas: la empresa deberá presentar según cronograma general del
proyecto, la planificación de los diferentes tipos de prueba que resulten
necesarias, así como también los escenarios y objetivos de prueba
correspondientes, que deberán ser sometidos a aprobación por parte del
GSF.
- Conformidad: la solución implementada deberá ser “aprobada” por
usuarios calificados.
Informes de avance:
El equipo de consultoría será responsable de la actualización permanente de la
planificación y cronogramas, y de brindar informes de avance del proyecto
bi-mensuales (salvo que desde el GSF se requiera otra periodicidad), con el
estado de todas las actividades.
Además se deberá elaborar un informe una vez concluida cada una de las
etapas, y un informe final con los resultados obtenidos en el proceso,
detallando como mínimo, y según la etapa que se completa:
- Áreas y perfiles detectados, que requerirán la explotación del Módulo de

BI.
87
- Objetivos concretos a satisfacer con la información brindada, en cada caso.
- Requisitos funcionales propuestos, y aprobados.
- Aperturas de los modelos de análisis: lista de dimensiones identificadas y
jerarquía de desagregación requerida en cada caso.
- Fuentes de dato necesarias en cada caso.
- Requisitos no funcionales.
- Objetivos no alcanzados
- Futuras mejoras necesarias detectadas.
Desde el Ministerio de Salud de la provincia, podrán requerir eventualmente

informes de avance en cualquier momento del desarrollo de este proyecto.
Configuración y puesta en marcha
- Configuración de puestos de trabajo

Se deberá proveer de manuales de instalación y configuración completos,
considerado todas las particularidades que pudieran requerir los diferentes
puestos de trabajo según los perfiles de operación contemplados.
Se podrán requerir tareas vinculadas a la instalación, configuración y
parametrización según corresponda, en los puestos de operadores que se
defina oportunamente.
- Puesta en marcha
El equipo brindará todo el soporte necesario para garantizar el éxito de la
puesta en marcha de la solución, en cada una de las áreas planificadas.
Capacitación: el adjudicatario tendrá a su cargo el diseño, organización y el

dictado de la capacitación de los usuarios, supervisores y administradores del
sistema, definidos por el Gobierno de Santa Fe.
La Proveedora llevará a cabo las capacitaciones iniciales a usuarios finales
(personal de planta y funcionarios), durante la puesta en marcha de la solución
en las diferentes áreas que se defina, y capacitará a capacitadores, que serán
personal del Ministerio de Salud, para realizar la instrucción a los usuarios
finales en futuras capacitaciones en lo que hace al uso y explotación de las
aplicaciones.
Deberán estar disponibles en esta instancia los manuales de operación y las
aplicaciones para realizar la práctica.
El Plan de formación deberá considerar como mínimo abordar los siguientes

temas:
88
Título: Administración de la Herramienta de Inteligencia de Negocio
Perfiles: Administradores de Plataforma
Horas: 40
Temario:
● Instalación y Configuración de la solución.
● Tareas básicas de administración como levantar y bajar los servicios,
modificar la configuración, etc.
● Toma de backups y restore de la herramienta.
● Monitoreo del estado de salud de los servicios.
Título: Uso de la Herramienta de Inteligencia de Negocios

Perfiles: Usuarios del área de sistemas y funcionarios del organismo
Horas: 32
Temario:
● Conexión a la herramienta.
● Visualización de tableros de control.
● Navegación por los indicadores y bajada a detalle.
● Definición de tableros de control propios.
Título: Desarrollo con la Herramienta de Integración de Datos

Perfiles: Desarrolladores de ETL /EL-T y Administradores de Base de Datos
Horas: 40
Temario:
● Descripción de la Arquitectura de la Solución.
● Instalación y configuración de la solución.
● Definición de los orígenes y destinos de los datos.
● Teoría y práctica de desarrollo de procesos de carga de datos. Uso de

diferentes tecnologías de repositorio de datos. Transformaciones.
● Teoría y práctica de validaciones en los datos cargados.
89
● Debugging y solución de errores.
● Seguimiento y auditoría de las ejecuciones históricas.
Transferencia tecnológica: En todo el ciclo de trabajo se trabajara con

técnicos de la sectorial de Informática, a los cuales durante el transcurso del
proyecto se deberá capacitar y brindar la transferencia tecnológica.
El adjudicatario deberá asegurar que, antes de la finalización del contrato,
dicho personal técnico esté en condiciones de realizar la administración del
sistema y los nuevos desarrollos en forma eficiente.
Se deberá brindar documentación en idioma español, en forma impresa y en
soporte digital magnético y/u óptico.
La mecánica para la transferencia tecnológica será a través de talleres de
trabajo que se realizarán en fechas a acordar. En dichos talleres la Proveedora
expondrá sobre los productos y documentos entregados, la contraparte
realizará consultas. Los acuerdos y las discrepancias quedarán reflejados en un
acta final.
Además se utilizarán estos talleres para exponer sobre el avance del proyecto y
explicar cómo y porqué el adjudicatario realizó las actividades técnicas de
todas las fases de elaboración del proyecto. Este tipo de taller deberá tener un
fuerte contenido práctico y deberá hacerse por lo menos dos veces por mes
desde el comienzo del proyecto. El temario y duración deberán informarse con
un mínimo de una semana de anticipación.
90
5. Consideraciones Generales
Plan de Trabajo
El oferente deberá presentar un Plan de trabajo en su oferta, por escrito y
además en formato digital (archivo tipo Project u open Project en pendrive).
Este plan deberá detallar todas las etapas de la provisión (se solicita un plan
separado para la capacitación). Deberá describir claramente las tareas, sub-
tareas, dependencias entre tareas, hitos y entregables y perfiles asignados a
cada tarea con su dedicación
Se deberá, además, especificar los hitos externos en los cuales el Gobierno de

Santa Fe deberá proveer la infraestructura tecnológica necesaria para llevar a
cabo las implementaciones de las soluciones. Por cada hito externo se deberá
indicar, además de la fecha, cada hardware con sus características.
El plan de trabajo propuesto deberá, además, incluir las tareas de

aseguramiento de calidad y pruebas necesarias que aseguren el software a
entregar.
Una vez adjudicado el proyecto, el plan de trabajo deberá ser aprobado por el
Gobierno de Santa Fe como condición previa a la adjudicación del proyecto.
El Plan de Trabajo comenzará a regir luego de que el Gobierno de Santa Fe

otorgue la Orden de Provisión.
Arquitectura de la Solución
El sistema deberá ser apto para funcionar en un entorno virtual, separado
físicamente de los dispositivos de almacenamiento y de los puestos de
operación y supervisión, en una configuración multisitio, multiservidores,
multiorganizaciones.
Deberá permitir la ejecución concurrente de varios usuarios (multitarea y
multiusuario) siendo accesible desde cualquier puesto conectado a la red
Provincial e Internet.
La solución debe garantizar los requerimientos no funcionales de: Alta
disponibilidad, seguridad, escalabilidad y desempeño a través de acuerdos de
niveles de servicio.
La implementación del sistema de salud será sobre máquinas virtuales de
acuerdo a lo indicado en cada caso. La arquitectura el sistema propuesto
deberá ser escalable horizontalmente sin puntos únicos de falla a nivel de
software. Si bien existirán máquinas virtuales de distinto tipo se deberán
considerar al menos los siguientes tipos:
 Balanceadores de carga
91
 Servidores de aplicaciones
 Administradores de Servicios Web
 Servidores de bases de datos
Estas definiciones se encuentran detalladas en el Estándar de Infraestructura
N° 5, Ambientes Arquitecturas y Zonas, el cual se anexa a la presente.
Escalabilidad
El sistema debe ser escalable horizontalmente, a partir del agregado de
servidores, manteniendo la funcionalidad del sistema en todo momento. Los
servidores podrán ser agregados en los balanceadores de carga o en los
Administradores de Servicios Web (o también Bus de Servicio Empresarial, ESB
por sus siglas en inglés). El sistema en su conjunto no deberá requerir
configuraciones adicionales que puedan ser disruptivas en el proceso de
ampliación de capacidades.
Como lineamiento general, se deberá implementar una arquitectura cercana a
los microservicios, a los fines de facilitar la escalabilidad.
Plataformas de implementación
Es deseable y se valorará que la implementación de la propuesta cumpla con lo
establecido en el Estándar de Infraestructura N°10, Plataformas Tecnológicas
para Aplicaciones y Datos, adjunto a la presente.
Cabe destacar que sólo se admitirán propuestas que de acuerdo a plataformas

Actuales y Anteriores, no aceptándose propuestas que requieran productos
obsoletos. La implementación de componentes de las Plataformas Futuras
deberá ser consensuada con el Gobierno de Santa Fe.
Seguridad
Gestión de usuarios
La generación de los usuarios del sistema, en todos los casos, deberá estar
alineada con la normativa de generación de usuarios, las cuales se encuentran
en el Documento Adjunto de Políticas de Seguridad N.º 2, Gestión de Usuarios.
Gestión de contraseñas
A los fines de la autenticación de los usuarios, es preferible y será valorada la
compatibilidad con CAS, el cual se encuentra implementado por la Secretaría
de Tecnologías para la Gestión. En su defecto el sistema deberá ser compatible
con LDAP, implementado en este caso con OpenLDAP. En ambos casos, sólo
deberá tenerse en cuenta la autenticación centralizada, quedando la
autorización a cargo de los productos a implementar por el adjudicatario.
Se deberá brindar un servicio de Identidad única que permita aunar todas

las aplicaciones licitadas en el presente pliego (HCEC, HIS y BI),
92
proporcionando a cada usuario de manera transparente, para todos los
sistemas un único perfil de identidad: información personal, credenciales de
autenticación, etc. Todo ello en conexión con las capacidades single-sign-on
específicamente requeridas para la solución del ámbito hospitalario, en el
Renglón II.1.
En caso que no sea posible la integración con el Sistema de Autenticación

Centralizado (CAS) del Gobierno de Santa Fe, el sistema deberá contemplar de
manera excluyente la integración con LDAP mencionada anteriormente.
Acceso a redes
Implementación central
En lo que respecta a los permisos de red que necesite el sistema para su
normal funcionamiento, se deberán tener en cuenta las normativas
detalladas en el Documento Adjunto de Políticas de Seguridad N.º 3,
«Acceso a Redes de Servidores».
Implementación regional
En el caso de una infraestructura regional, se deberá consensuar entre el
adjudicatario y el Gobierno de Santa Fe, la arquitectura de redes y
permisos, siguiendo los lineamientos mencionados en la sección anterior.
Infraestructura
Sistemas operativos
Es deseable y se valorará que los sistemas operativos a instalar y a utilizar por
el sistema cumplan con lo especificado en el Estándares de Infraestructura
N°3, Sistemas Operativos de Servidores, adjunto a la presente.
Infraestructura central
La implementación de servidores en la infraestructura central será mediante la
utilización de máquinas virtuales a excepción de los motores de base de datos,
donde el alojamiento de bases de datos será provisto como servicio por la
Dirección Provincial de Infraestructura Tecnológica. Asimismo en este caso los
balanceadores de carga serán provistos por el Gobierno de Santa Fe.
En este caso ninguna de las máquinas virtuales podrá superar los 32GiB de
memoria RAM, a los fines de facilitar la tolerancia a fallos y la movilidad de las
máquinas virtuales en infraestructura de virtualización del Gobierno de Santa
Fe.
Infraestructuras regionales
La implementación de servidores en la infraestructura regional será mediante
la utilización de máquinas virtuales, para todos los roles de servidores.
En este caso ninguna de las máquinas virtuales podrá superar los 16GiB de
memoria RAM, a los fines de facilitar la tolerancia a fallos y la movilidad de las
máquinas virtuales en infraestructura de virtualización del Gobierno de Santa
Fe.
93
Hardware
A continuación se describe el esquema de hardware para soportar las
aplicaciones de misión crítica de los hospitales, diseñada para no tener
puntos únicos de falla, garantizando la continuidad de negocio mediante la
reducción o eliminación del tiempo fuera de servicio. El siguiente gráfico,
describe de que manera interactúan los componentes a utilizar para dar
cumplimiento a los requerimientos expresados anteriormente.
Se detallan algunos de los servicios que debe soportar la solución:

 PACS (Picture Archiving and Communication System)
 RIS (Radiology Information System)
 HIS (Hospital Information System)
 HCEC (Historia Clínica Electrónica Compartida)
 Servidores de bases de datos
 Servidor de Archivos
 Proxy Web
 Centrales de Telefonía IP
 Sistemas de Inventario TIC
 Consola de Administración Antivirus

94
Características del hardware
Servidores de Virtualización
Servidores físicos basados en arquitectura Intel Xeon, con un procesador
de 8 cores, 32 GB de memoria RAM, con fuentes de alimentación
redundantes e intercambiables en caliente, placa de administración
remota, 4 adaptadores de red LAN, distribuidos en 2 placas físicas
independientes y 2 discos rígidos hot-swap configurados en RAID 1 para
instalación del Hypervisor de Vmware.
Los equipos deben tener la capacidad de ejecutar múltiples sistemas
operativos y aplicaciones simultáneamente en el mismo servidor,
aumentando la escalabilidad, flexibilidad y agilidad de TI. Las máquinas
virtuales que ejecuten estos servidores se ubicarán físicamente en el
almacenamiento primario, y serán replicadas en el almacenamiento
secundario.
Deberán contar con una placa dedicada para backup, una placa para la
administración y 2 placas para producción, las cuales se conectarán
cada una a unidades diferentes de un switch, siendo redundante la
forma en que se conectan al almacenamiento externo.
Servidores de Backup
Servidor físico basado en arquitectura Intel Xeon, con un procesador de
8 núcleos, 32 GiB de memoria RAM, con fuentes de alimentación
redundantes e intercambiables en caliente, placa de administración
remota, 4 adaptadores de LAN, distribuidos en 2 placas físicas
independientes y 2 discos internos configurados en RAID 1, donde se
instala en sistema operativo y el software de respaldo. Deberá contar
con una placa dedicada conectada a la librería de cintas.
Este equipo ejecutará un plan de copias de seguridad, indispensable
para asegurar la disponibilidad y el resguardo de los datos del sistema.
El mismo debe incluir el guardado de copias de seguridad en un lugar
seguro y distante de donde se encuentran los servidores.
Librería de cintas
Dispositivo con una unidad LTO-6 y al menos 8 slots para la carga
automática de cintas, que permita hacer copias diarias de los datos y
prescindir de la intervención humana para el intercambio de las cintas si
fuera necesario.
Almacenamiento Principal
Dispositivo de almacenamiento con un total de 20 TB para alojar
máquinas virtuales, con características específicas que permiten
aprovisionamiento virtual, replicación, generación de snapshots y con un
software de administración y diagnóstico del sistema con entorno gráfico
administrable vía web.
Deberá contar con controladoras, fuentes de alimentación y ventilación
redundantes intercambiables en caliente, de manera que se pueda
95
acceder desde los servidores y el almacenamiento secundario, a través
de la red Ethernet 10GB iSCSI, en forma redundante.
Almacenamiento Secundario
Dispositivo de almacenamiento con un total de 20 TB dedicado para
almacenar las replicas de maquinas virtuales, con el fin de recuperar una
VM de forma inmediata.
Deberá contar con controladoras, fuentes de alimentación y ventilación
redundantes intercambiables en caliente, de manera que se pueda
acceder desde los servidores y el almacenamiento principal, a través de
la red Ethernet 10GB iSCSI, en forma redundante.
Continuidad de las Operaciones

Escenarios de Contingencia
Escenarios que se pueden presentar ante eventuales contingencias y de
qué manera se resuelven:
1. Caída de un servidor de virtualización: El esquema permite que desde
otro servidor de virtualización se pueda buscar la vm en el datastore y
levantarla (se supone que éste servidor tiene presentados los
datastores y los recursos de memoria y CPU necesarios).
2. Caída del Almacenamiento primario: presentar los datastores del
almacenamiento secundario donde residen las réplicas de las VM,
buscar las VM y levantarlas. En el caso que sea necesario se deberá
complementar con la copias de respaldo que se realizan diariamente
con el software de back up.
3. Caída de un switch: en esta arquitectura es transparente a la caída de
una de las unidades del switch dado que los mismos están conectados
en forma de stack y los hipervisores están conectadas a los mismos
en teaming dando de esta manera conectividad redundante a nivel de
red en los servicios a usuarios y multipath de accesos a los
almacenamientos.
4. Corrupción de una VM: utilizar un backup a nivel de VM, y
complementar con la copias de respaldo que se realizan diariamente
con el software de backup.
5. Pérdida de datos en una VM (Error Humano) recuperar los datos desde
las copias de respaldo que se realizan diariamente con el software de
backup.
Procedimientos de Contingencia
 Procedimiento ante la contingencia 1 ( Caída de un servidor de
virtualización): Las VMs que son consideradas críticas deberán estar
corriendo en cluster vmware con la característica de HA habilitada. De
manera tal que ante la caída de un nodo del cluster y teniendo la
disponibilidad de recursos en algún otro nodo , vencido el tiempo de
espera programado debería automáticamente levantarse en dicho nodo
96
dado que las VMs son visibles y están alojadas en un datastore común a
todos los miembros del cluster.
 Procedimiento ante la contingencia 2 ( Caída del Almacenamiento
primario): Este tipo de falla es considerada crítica dado que las VMs
están corriendo en datastore que no está más disponibles para los
hipervisores . Se deberá realizar varias operaciones manualmente
◦ Cortar la replicación entre el almacenamiento primario y secundario .
◦ Publicar las LUNs que estaban siendo replicadas para ser vistas
por los hipervisores.
◦ Reiniciar los servidores.
◦ En cada uno de los hipervisores agregar los datastores/LUNs que
contienen las Vms.
◦ Inventariar cada VM disponible en el datastore.
◦ Arrancar cada VM y chequear la misma , en caso de corrupción se
determinará si se puede corregir o eventualmente levantar la
misma desde el último backup disponible.
 Procedimiento ante la contingencia 4 ( Corrupción de una VM): Este
tipo de falla puede ser producto de mal funcionamiento o salida de
servicio no programado del HW de servidores o almacenamiento
para ello se deberá realizar varias operaciones manualmente
◦ Clonar la VM con otro nombre de manera tal que contenga los
últimos datos disponibles antes que salga de servicio lo que no
asegura que estos sirvan.
◦ Borrar la VM corrupta.
◦ Recuperar la VM desde el último backup de la misma.
◦ Inventariar la VM recuperada.
◦ Verificar los datos de la VM corrupta y determinar si son utilizable
o eventualmente recuperar los datos desde el último backup con
la consecuente pérdida de datos en el ínterin de los mismos.
Gestión de Archivos Binarios

En los casos en que la solución ofertada tenga la necesidad de incorporar
archivos binarios, la misma debe hacerse de acuerdo a lo establecido en el
Estándar de Infraestructura N°9, Archivos binarios en aplicaciones web, adjunto
al presente.
Por archivos binarios entendemos a documentos PDF, imágenes, documentos
escaneados, etc. Quedando excluidos de la presente las imágenes médicas, las
cuales serán gestionadas mediante PACS.
97
Licenciamiento y Propiedad Intelectual
La solución propuesta deberá correr preferentemente sobre una arquitectura
de software libre. En caso de no ofrecer soluciones de ese tipo, se deberán
incluir todas las licencias para la funcionalidad solicitada en el presente pliego.
El adjudicatario deberá proveer todas las licencias de los distintos tipos de
software que se necesiten para poner en funcionamiento la solución general en
su conjunto, en un entorno de prueba y en un entorno de producción. Estas
licencias incluyen las licencias de las herramientas, bases de datos y también
las de los sistemas operativos, si fuesen necesarias.
El adjudicatario deberá entregar las licencias y utilizar la versión más reciente
liberada por el fabricante para los componentes de software involucrados,
excepto que en éstas se verifique la existencia de problemas (bugs) o
incompatibilidades, las cuales serán explicadas al Gobierno de Santa Fe siendo
ésta la autoridad que decida al respecto. De idéntico modo, y sin cargo para el
Gobierno de Santa Fe, se deberán proveer e instalar los parches (o update) y/o
las actualizaciones (o upgrade) de software y correcciones que fueran
necesarios para garantizar la seguridad y el correcto funcionamiento del
sistema durante la vigencia del contrato.
En caso de que, en un futuro, luego de la implementación, se requiera la
adquisición de nuevas licencias de software, el proveedor deberá mantener el
precio unitario, en dólares estadounidenses, que cotizó al inicio de la licitación.
Todas las licencias deberán ser perpetuas, registradas con la siguiente
información de contacto:
Dirección Provincial de Infraestructura Tecnológica
San Martín 2466, 3er Piso, Santa Fe (3000), Santa Fe, Argentina.
dpit@santafe.gov.ar
(+54) (0342) 4508700
Entrega de Fuentes y documentación técnica del software
El GSF requiere garantías en la continuidad de los servicios implementados

como resultado de la presente licitación, inclusive en los casos en que por
razones de fuerza mayor la empresa adjudicataria no pueda continuar con los
servicios de mantenimiento sobre la solución.
En ese sentido el GSF se reserva el derecho de solicitar la entrega de los

Códigos Fuentes y la Documentación y los Procedimientos Para el Uso de
dichos códigos con cada liberación de la solución.
Se valorará especialmente la entrega de las fuentes en forma directa. Si ello no

fuera factible, será requisito para la empresa adjudicataria la contratación de
un servicio de custodia que permita disponer de los mismos en un tercero
98
(servicios escrow), para de esta forma tener garantizada la continuidad
evolutiva de la solución contratada. En este último caso, el servicio a contratar
deberá ser previamente aprobado por el GSF.
Cuando hablamos de fuentes nos referimos al código propiamente dicho, la

definición de las estructuras de base de datos, documentación, etc.
Dentro de la documentación requerida incluimos la arquitectura técnica, los

procedimientos para la instalación del producto, la especificación del entorno
de desarrollo, su versión, detalles de parametrización, configuración del
ambiente, los procedimientos de verificación que los fuentes entregados son
los que generan los binarios en ejecución, etc.
Los elementos mencionados anteriormente deberán permitir disponibilizar la

solución para su parametrización, modificación y desarrollo de acuerdo a
eventuales necesidades del GSF sobre las funcionalidades de la solución.
Servicios GIS
La solución deberá integrarse con los servicios GIS que provee la IDESF. Para
ello, los sistemas de georreferenciación deberán ser compatibles con los
estándares del Gobierno de Santa Fe (IDESF: Infraestructura de Datos
Espaciales de Santa Fe) que a su vez son compatibles con OCG (Consorcio
Geoespacial Abierto).
En tal sentido es preciso aclarar que los sistemas licitados en el presente pliego
deberán poder tomar la información producida por la IDESF (Infraestructura de
Datos Espaciales de Santa Fe), que ofrece servicios de Información Geográfica
basados en Normas y Estándares Abiertos e Interoperables, emitidos por el
Consorcio Geoespacial Abierto y la Organización de Estandarización
Internacional (ISO TC211). Estos servicios permiten el intercambio homogéneo,
de información heterogénea.
Específicamente, la IDESF implementa los siguientes servicios estándares:

-WMS (Web MapService): Soporte para la petición de mapas en formato raster
(imágenes png, GeoTiff). Es decir, imágenes georreferenciadas de mapas. Este
servicio permite también consultar la información asociada a los objetos
espaciales representados.
-WFS (Web FeatureService): Soporte para la petición de objetos geográficos en
formato vectorial. Es decir, transferir las geometrías de los objetos espaciales,
junto con sus atributos descriptivos.
99
-WFS-T (WFS Transaccional): Permite la transferencia de las geometrías de los
objetos geográficos de interés, y su edición (crear, eliminar, modificar) a través
de operaciones transaccionales.
-WCS (Web CoverageService): Soporte para la representación de mapas de
cobertura (por ej. Imágenes Satelitales)
-CSW (CatalogService Web): Este servicio permite gestionar un catálogo de
métodos de la Información Geográfica disponible (organismo generador de la
información, contacto, área de cobertura, tipo de inf., fechas de captura,
modificación, sistema de referencia, etc.)
-Tile Caching (WMS-C, WMTS, TMS, Google MapsKML, Virtual Earth): Servicio de
cacheo de mapas, que permite mejorar de manera considerable la experiencia
del usuario, al acelerar el acceso a los mapas.
Otros servicios adicionales ofrecidos:

-SLD: Servicio que permite aplicar estilos a los mapas, de manera dinámica.
-FE: Servicio que permite filtrar la información a transferir.
Los archivos recomendados para el intercambio estandarizado de información

geográfica son gml,sql y shapefile.
Para resolver la visualización de los diferentes mapas GIS (Sistemas de

Información Geográfica) requeridos en el presente pliego, o que surjan de su
implementación, el proveedor deberá entregar, instalar y ejecutar todo el
software necesario para que la solución quede operativa.
Servicios Profesionales
Previsión de Recursos Humanos en la implementación
El oferente deberá proporcionar y garantizar los recursos humanos, técnicos y
de infraestructura, dedicados plena o parcialmente al proyecto para la
implementación de las soluciones, en las etapas de análisis de requerimientos,
adaptación, implementación en el caso que corresponda, y configuración de las
soluciones, pruebas, puesta en marcha y entrada en producción utilizando los
aplicativos, transferencia tecnológica, capacitación y difusión, como también
en el soporte posterior a la puesta en marcha.
El adjudicatario debe establecer la participación de un equipo multidisciplinario
que considere el área clínica, administrativa, técnica y social (con formación
certificada en Gestión del Cambio, Coaching y Gestión de Personas), para lo
cual deberá detallar los recursos humanos destinados al proyecto, incluyendo
la descripción de roles y competencias de cada uno y la dedicación en horas
hombre al proyecto.
Por su parte, los efectores dispondrán de horas exclusivas de profesionales
dedicados al proyecto, las que se definirán en la etapa de planificación del
proyecto. El perfil de profesionales será del área: clínica, administrativa,
informática y estadísticas.
100
Capacitación y Transferencia Tecnológica
El adjudicatario tendrá a su cargo el diseño, organización y el dictado de la
capacitación de los operadores, supervisores y administradores del sistema,
definidos por el Gobierno de Santa Fe.
La capacitación a operadores deberá preverse en igual plazo para todos los
efectores donde se realice la implementación en todos los servicios donde se
habiliten los sistemas, comenzando 30 días hábiles antes de la puesta en
marcha. El oferente tendrá que mantener un staff de profesionales acorde con
el volumen de implementación, estableciendo un mínimo de 4 (cuatro) para
cada solución a implementar, durante no menos de 6 meses a partir del inicio
de las actividades sobre los sistemas. En el mismo plazo realizará la
transferencia de conocimiento a los equipos técnicos de cada uno de los
efectores de salud.
El plan de capacitación tendrá que prever a todos los usuarios de los sistemas
en las distintas áreas de los efectores (ver volumen de personal de los
efectores). El objetivo es lograr que los mismos adquieran las competencias
para operar la aplicación y contribuyan a la sostenibilidad de su uso.
Los cursos deben evaluarse con un cuestionario de satisfacción del participante
y un test de evaluación de adquisición de conocimientos o habilidades del
asistente. Se deberá realizar un informe final consolidado de la capacitación
dictada, que contenga la evaluación global y recomendaciones.
La capacitación ofrecida deberá garantizar la enseñanza sobre el uso y manejo
del sistema en sus distintos modos de funcionamiento y para todos sus
componentes y perfil de usuario.
Será beneficioso que se entregue la certificación correspondiente por la
capacitación realizada a cada participante.
Se deberá incluir un programa detallado de cada capacitación, calendarios,
cronograma de horas de dictado y el número máximo de personas por curso
para un buen aprendizaje del uso de las herramientas propuestas.
Se deberá prever el suministro de todo el material necesario para el correcto
dictado de las capacitaciones, como así también los manuales de uso y guías
prácticas de fácil interpretación para la operación de cada uno de los
componentes objeto del presente pliego.
Todas las acciones de capacitación deberán ser realizadas preferentemente en
instalaciones definidas oportunamente por el Gobierno de Santa Fe.
Los cursos que requieran práctica sobre los equipos, no podrán realizarse sobre
el entorno de producción. Y se deberá coordinar con el Gobierno de Santa Fe la
necesidad de licencias adicionales, equipos, etc., corriendo por parte del
adjudicatario todos los gastos incurridos a tales efectos.
La capacitación se deberá realizar en horario laboral, salvo que el Gobierno de
Santa Fe autorice lo contrario.
De la transferencia tecnológica:
Durante todo el desarrollo del proyecto se trabajará con técnicos de la

Sectorial Informática de Salud y del Gobierno de Santa Fe, a los cuales en el
mismo transcurso la adjudicataria deberá capacitar y brindar una completa
101
transferencia tecnológica, para el mantenimiento y administración de cada una
de las distintas soluciones licitadas en este pliego, sus diversos módulos,
subsistemas, etc.
La adjudicataria deberá garantizar que antes de finalizar el contrato, dicho

personal técnico esté en condiciones de realizar la administración y
mantenimiento del sistema, y en los casos que corresponda los nuevos
desarrollos, en forma eficiente.
Se deberá brindar documentación en idioma español, en forma impresa y en
soporte digital magnético y/u óptico.
La mecánica para la transferencia tecnológica será a través de talleres de
trabajo que se realizarán en fechas a acordar. En dichos talleres la Proveedora
expondrá sobre los productos y documentos entregados, la contraparte
realizará consultas. Los acuerdos y las discrepancias quedarán reflejados en un
acta final.
Además se utilizarán estos talleres para exponer sobre el avance del proyecto y
explicar cómo y porqué el adjudicatario realizó las actividades técnicas llevadas
a cabo durante cualquiera de las fases del desarrollo del proyecto. Este tipo de
taller deberá tener un fuerte contenido práctico y deberá realizarse al menos
dos veces por mes (cronograma a coordinar con el equipo de GSF) desde el
comienzo del proyecto. El temario y duración deberán informarse con un
mínimo de una semana de anticipación.
Documentación y estándares de proceso
- Documentación
Como actividad transversal a todo el proceso, se requiere la
confección y entrega de documentación de todo lo producido en cada
una de las etapas (minutas de reunión, informes de avance,
especificaciones y diagramas de procesos, modelos de datos,
diagramas de despliegue, notas de versión, manuales de usuario, etc.), y
actualización permanente de dichos documentos si existieran cambios,
puestos a disposición del equipo de proyecto de GSF en los plazos que
se acuerden.
Toda la documentación que se entregue deberá estar en idioma español,
y se presentará en soporte digital a través de los medios que se
acuerden, y si es requerido en forma impresa.
- Estándares
102
Salvo que se acuerde lo contrario, toda la documentación a entregar, así
como también los procesos contemplados en el desarrollo de las
actividades mencionadas: gestión del cambio, esquema de despliegues,
etc., deberán ajustarse a los estándares utilizados por el GSF, o
acordados oportunamente.
Plan de contingencia, rescisión o término del contrato

El objetivo del Plan de Contingencia, es el asegurar la integridad del proceso de
implementación, puesta en marcha, utilización y operación de los Sistemas
Implementados.
Este Plan deberá prever y responder ante los eventos que pongan en peligro
dicha implementación. Así mismo, en casos de imponderables, como
catástrofe, término anticipado del Contrato por parte del proveedor, u otros.
Este deberá garantizar la continuidad operacional de los sistemas, aun después
de su ausencia.
Para esto el proveedor deberá diseñar, presentar y proponer para su
aprobación por parte del Gobierno de la Provincia de Santa Fe, un Plan de
Contingencia, que al menos considere las siguientes partidas:
 Plan de Respaldo: Contemplará las medidas preventivas destinadas a
minimizar la posibilidad de ocurrencia de alguna emergencia
operativa.
 Plan de Notificación: Identificara los conductos regulares para el caso en
que se deba notificar una contingencia a quienes corresponda. Deberá
además evaluar la misma en términos de parámetros y el Plan de
Activación.
 Plan de Emergencia: Contemplará el curso de las acciones a seguir en
caso de materializarse alguna emergencia operativa. Su finalidad es
abortar la misma y/o minimizar sus efectos.
 Plan de Recuperación: Determinará el tipo de medidas a implementar,
después de la evaluación y contención de la emergencia operativa.
 Plan de Continuidad Operacional: Contemplará todas las acciones
necesarias, para que los efectores dispongan de una copia ejecutable de
los sistemas contratados y respaldos de las bases de datos, de forma tal
que le permitan seguir funcionando sin interrupciones, aún después del
retiro del proveedor.
Además, deberá contemplar los siguientes escenarios de riesgos:
 Problemas de operación de todos los sistemas licitados en el presente
pliego.
 Problemas de Comunicación con Sistemas de Apoyo o Interfaces.
 Plan de implementación de apoyo al proceso de continuidad:
◦ Contemplará todas las acciones necesarias para que el Efector no
detenga tus tareas.
103
◦ El oferente deberá prever la transferencia de conocimiento del plan
de contingencia a los equipos de profesionales que el Gobierno de
Santa Fe designe, durante un plazo no menor a 6 meses. Durante
dicho plazo la aplicación del plan de contingencia será exclusiva
responsabilidad del oferente.
Penalidades por incumplimiento

La presente cláusula establece las siguientes penalidades:
● Penalidades por incumplimiento del inicio del contrato

El incumplimiento del plazo de inicio del contrato de acuerdo con el
cronograma de implementación acordado, hará pasible al adjudicatario de la
aplicación automática de una multa equivalente al uno por mil (1 ‰) del valor
total del contrato, por cada día de mora en su incumplimiento.
● Penalidades por incumplimiento del Plan de trabajo

Sin perjuicio de la aplicación de penalidades por incumplimiento contractual
previstas por la Legislación Provincial, los avances en la presentación de un
entregable que superen el 50% de demora con respecto al Plan de Trabajo
aprobado, serán pasibles de la aplicación de una multa equivalente al cero
coma dos por mil (0,2 ‰) del valor total del desembolso para dicho entregable,
por cada día de mora en su incumplimiento.
OTRA OPCIÓN PODRÍA SER:
La Secretaría de Tecnologías para la Gestión (STG) ha establecido un sistema

de penalizaciones por incumplimiento de la calidad de los entregables y de los
plazos de implantación. En concreto:
INDICADOR Desviación Penalización
Entregable no aprobado por el Comité Segunda vez rechazado 1%
Técnico de Seguimiento y Mejoras
Entregable no aprobado por el Comité Cada vez que se rechaza después de 5%
Técnico de Seguimiento y Mejoras la segunda
Retraso en la entrega de un Cada semana de retraso 1%
documento según planificación
Retraso en la puesta en marcha de un Cada semana de retraso 1%
módulo según planificación
Incumplimiento de las sesiones de Por cada sesión no realizada 1%
formación
Implantación de funcionalidades Funcionalidad no implantada o no 5%
incluidas en el pliego cubierta
Integraciones incluidas en el pliego Integración no realizada o no cubierta 3%
Código fuente de los desarrollos No entrega del código fuente 10%
específicos
104
Como norma general, quedarán excluidas de las penalizaciones:
· Cuando haya situaciones extraordinarias que hagan imposible el
establecimiento de los indicadores para medir las penalizaciones.
· Que la desviación no sea exclusivamente responsabilidad del
adjudicatario.
La STG podrá ejercer estas penalizaciones si así lo considera necesario.
Todas las penalizaciones están referidas al importe total del proyecto y se
realizarán como una reducción en el importe de la siguiente factura que reciba
la STG. En caso de que no se vaya a recibir una próxima factura, supondrán un
abono para la STG por dicha cantidad penalizada.
En el caso de que las penalizaciones totales efectuadas llegasen al 25% del

valor total del proyecto, la STG se reserva el derecho de proceder a la
resolución del contrato sin perjuicio para la STG, o bien, la continuidad del
mismo aplicando nuevas penalizaciones.
● Penalidades por incumplimiento en el soporte técnico post

implementación
La falta de respuesta por parte del servicio técnico post implementación para la
resolución de problemas reportados, se multará de acuerdo a la siguiente
tabla:
Nivel Tiempo de Impacto Valor de referencia “V”: U$D 75

Criticida resolución
d máximo
(en horas
corridas)
1 24 horas Alto Por cada hora de mora se cobrará el
equivalente a 4 V
2 48 horas Medio Por cada hora de mora se cobrará el
equivalente a 3 V
3 72 horas Bajo Por cada hora de mora se cobrará el
equivalente a 2 V
4 15 días Muy Bajo Por cada día de mora se cobrará 1 V
Tabla 4 – tabla de penalización por incumplimiento en soporte técnico post

implementación.
La falta de prestación del servicio por medidas de fuerza del personal del
adjudicatario u otra causa y/o reiteración de deficiencias, facultará a la
Provincia a contratar a un tercero por cuenta del adjudicatario, a cargo de
quien estará el pago de la eventual diferencia de precios que resultare.
105
Sin perjuicio de lo antedicho la falta de cumplimiento a las condiciones
establecidas en el presente pliego, dará lugar a la aplicación de lo previsto en
el inc. l) del art. 139 del Decreto N° 1.104/16.
● Penalidades por incumplimiento de las condiciones de garantía

Los atrasos en el cumplimiento de las condiciones de garantía por causas
atribuibles al Adjudicatario, devengarán una multa equivalente a cincuenta
dólares estadounidenses (U$S 50) por cada día o fracción menor al día, de
atraso.
Mantenimiento
Garantía
La garantía incluye como mínimo la correcta operación de todas las
funcionalidades del servicio descritas en este documento.
Además, debe garantizar el correcto funcionamiento del servicio, después de
cada proceso de actualización y/o mejora.
El oferente deberá disponer personal in situ abocado a resolver los
inconvenientes que puedan surgir durante la implementación de las soluciones.
Además, deberá brindar soporte en lo referido a software, bases de datos y
clientes durante la implementación de su solución.
El período de garantía será como mínimo de 12 meses a partir de la aceptación
del trabajo. No obstante, los oferentes especificarán, en su caso, el tiempo de
garantía ofrecido superior al mínimo, así como el alcance de la misma.
Mantenimiento correctivo
Los servicios de mantenimiento correctivo se aplicarán dentro del plazo de
ejecución total del contrato, a aquellos sistemas que se hubieren
implementado y abarcará también las modificaciones necesarias durante el
período de garantía.
Se cubrirá el correcto funcionamiento de cada una de las partes componentes
del sistema que ofertaren, como así también la disponibilidad de personal
técnico.
El mantenimiento correctivo permitirá localizar y eliminar los posibles defectos
que hacen que el comportamiento del sistema sea diferente del establecido en
las especificaciones y/o que bloquean el funcionamiento del sistema.
Particularmente, ante problemas de disponibilidad de recursos, deberá
garantizar un servicio de mantenimiento y soporte ágil y respuestas
inmediatas.
El Adjudicatario será responsable por el correcto funcionamiento de los
sistemas solicitados en la presente gestión y la adecuada conservación de sus
instalaciones, debiendo para ello realizar el Mantenimiento Preventivo de todas
las componentes involucradas, de acuerdo a los requerimientos establecidos
en la presente sección.
El mantenimiento preventivo como el correctivo deben incluir:
106
● La atención y resolución de problemas, instrumentando todas las
etapas necesarias para cumplimentar dicho objetivo.
● Deberá prestarse en las oficinas y en las localidades donde se
instalen los sistemas objeto del presente pliego. El Gobierno de la
Provincia de Santa Fe no reconocerá gastos adicionales de traslado o
movilidad de equipos o técnicos.
● Al modificarse un módulo o procedimiento de un sistema, deberá
actualizarse la versión para su uso a todas las dependencias en que
ya se hubieren puesto en funcionamiento.
● Igualmente deberán unificar las versiones de utilitarios, sistema
operativo y todo otro software instalado dentro de la misma
plataforma. Se deberá remitir la documentación de la nueva versión.
● Un calendario de mantenimiento preventivo para cada uno y todos
los componentes del sistema, que así lo requieran.
● Como parte del mantenimiento preventivo se deberá realizar la
evaluación periódica de Rendimiento y Calidad: el monitoreo del
rendimiento y eficacia del sistema, adoptando las medidas
correctivas necesarias que permitan alcanzar los objetivos
requeridos. El Gobierno de Santa Fe comprobará el grado de
satisfacción de los usuarios, tanto finales como técnicos.
Evaluación y monitoreo de la solución implementada

La adjudicataria será responsable por un período de 6 meses a partir de la
puesta en marcha con conformidad del GSF de la solución integral licitada, de
llevar a cabo un proceso de evaluación y monitoreo del funcionamiento y
utilización de la herramienta, confianza y conformidad de los usuarios con la
solución. Y deberá presentar informes mensuales con el estado de situación
verificado.
Desde el Ministerio de Salud de la provincia se podrá requerir eventualmente,
determinado formato, periodicidad, contenido y/o medio de presentación para
dichos informes.
Soporte a usuarios finales

Se deberá brindar un servicio de soporte a usuarios finales por un período de al
menos 12 meses a partir de la puesta en marcha de cada implementación. La
empresa presentará las características del servicio ofertado, y deberá coordinar
procesos y protocolos de servicio con el equipo de proyecto del GSF.
En todas las tareas de soporte post implementación, el adjudicatario deberá
dar participación al personal del Gobierno de Santa Fe.
El soporte post implementación debe tener como mínimo el siguiente alcance:
• El adjudicatario deberá realizar la atención y resolución de
problemas, instrumentando todas las etapas necesarias para cumplimentar los
objetivos.
107
• El adjudicatario concederá el servicio preferentemente con
personal especializado de la(s) empresa(s) fabricante(s) de los productos
ofrecidos, o en su defecto con su propio personal o por un tercero, el que
deberá estar debidamente certificado por el(los) fabricante(s) o su
representante local. A sus efectos presentará, al momento de la entrega de los
productos, la lista de técnicos habilitados para prestar el servicio. El
adjudicatario es responsable ante eventuales incumplimientos de los terceros
que contrate.
• Las solicitudes de servicio se sujetarán como mínimo, a lo
siguiente:
- Se podrán efectuar telefónicamente, por correo electrónico o
mediante página web (considerándose todas estas formas igualmente válidas)
a las direcciones acordadas entre el Gobierno de Santa Fe y el adjudicatario.
• El Gobierno de Santa Fe notificará las anomalías en que se
presenten incluyendo la siguiente información:
- Fecha y hora
- Descripción del problema
- Usuarios afectados
- Nivel de criticidad de la falla
• El tiempo que transcurra entre el momento de reportar un
incidente de soporte técnico y el momento de atención de la empresa no
deberá exceder las dos (2) horas.
• Las resoluciones a los problemas que pudieran surgir deberán
ajustarse a lo establecido en la tabla siguiente. Para el caso en que la
resolución del problema sea imposible de resolver en los plazos estipulados, el
adjudicatario, deberá acordar con el Gobierno de Santa Fe un nuevo plazo,
teniendo este último la decisión única y exclusiva sobre el nuevo plazo de
resolución.
• El plazo para la resolución del problema reportado, deberá
responder al siguiente detalle, de acuerdo con la criticidad reportada y definida
exclusivamente por el Gobierno de Santa Fe:
108
Nivel Tiempo de Impact Detalle del Impacto
Criticida resolución o
d máximo (en
horas
corridas)
1 24 horas Alto Software detenido, fallas del Sistema
Operativo o indisponibilidad o falla de
máxima funcionalidad de
componentes vitales
2 48 horas Medio Software no detenido, falla en
componentes vitales solucionable en
forma transitoria y no definitiva.
3 72 horas Bajo Software no detenido, falla en
componentes que requieren solución
no inmediata.
4 15 días Muy Problemas en nuevos componentes o
Bajo funciones no utilizables aún en el
ambiente de producción.
Tabla 12 – Detalle de tiempos de resolución de acuerdo a la criticidad del

evento reportado
• Ante cada notificación el adjudicatario deberá realizar y presentar

al Gobierno de Santa Fe un informe que contendrá como mínimo la
siguiente información:
• Descripción detallada del problema, su causa y solución propuesta
• Documentación adjunta de los cambios hechos
• Recomendaciones (Opcional)
• Fecha y hora de resolución
• El soporte requerido deberá poseer las siguientes características:
• Cantidad ilimitada de incidentes a reportar y resolver
• Soporte 7x24: telefónico, correo electrónico y página web
• Soporte técnico en idioma español
• Soporte en la Web con acceso las veinticuatro (24) horas del día a
publicaciones de software y documentación relativa a Auditoría
• Cada vez que se genere una solicitud de soporte, según lo
establecido en las cláusulas precedentes, el adjudicatario deberá
entregar un número de orden registrable por tal reclamo en el que
deberá dejarse constancia como mínimo, de la fecha y horario en el que
se realizó tal orden y el problema reportado.
• El Gobierno de Santa Fe podrá cambiar el procedimiento de
soporte cuando lo decida. En este caso lo comunicará el adjudicatario
109
con la antelación suficiente.
Gestión de la Continuidad
El adjudicatario deberá garantizar en todo momento la continuidad de los
equipos de trabajo, y para ello deberá proponer los procesos de gestión para
las siguientes contingencias:
• Sustituciones temporales planificadas
• Sustituciones temporales imprevistas
• Sustituciones definitivas previstas
• Sustituciones definitivas imprevistas
Adicionalmente, se deberán definir los procesos de gestión para las ausencias

de los siguientes tipos:
• Vacaciones
• Permisos especiales
• Actividades varias internas de la compañía: formación,
seguimiento y control de la carrera profesional
Gestión del cambio

A partir del primer despliegue de la solución, y hasta un (1) año posterior a la
"puesta en marcha", se deberá brindar soporte para la “Gestión del Cambio”
con presentación de planificaciones y sub-planificaciones progresivas sujetas a
aprobación del GSF, que deberá contemplar el relevamiento, diseño e
implementación de modificaciones evolutivas de la solución, en función de los
siguientes dos objetivos:
a) Estabilización de la solución: lograr una solución estable, que

cumpla con los requerimientos funcionales y no funcionales planteados y
con los objetivos de la organización, sea de utilidad y tenga un buen
nivel de aceptación por parte de los usuarios.
b) Mejora continua: implementar cambios y mejoras iniciales en la

solución, para satisfacer necesidades no contempladas durante el
relevamiento, o manifestadas a través del uso de la herramienta, que
indefectiblemente surgen al evolucionar el diseño y durante los primeros
meses/años de utilización. Dos (2) personas disponibles en promedio 40
horas semanales.
En ambos casos también se requiere el mantenimiento de la documentación

que pueda verse afectada por los cambios, y según el caso pueden ser: de
funcionalidades, del código fuente, del modelo de base de datos, manuales de
instalación y configuración, manuales de usuario, etc.; así como también la
110
continuidad de los talleres de transferencia tecnológica y una conveniente
comunicación de las mejoras de la aplicación a todos los interesados
(comunicados y notas de versión), y eventuales refuerzos de capacitación (para
cambios importantes).
Seguridad y confidencialidad de la información

Tanto los licitadores como el/los adjudicatario/s se comprometen a dar un trato
reservado y confidencial a toda la información que la empresa licitadora o
adjudicataria pudiera obtener del Ministerio de Salud y sus dependencias y a
procurar su custodia y no divulgar por el personal a su cargo, salvo que medie
la autorización por escrito de dicho Ministerio.
Esta obligación estará en vigor aun cuando el contrato haya llegado a su
término o haya sido cancelado.
La empresa adjudicataria y el personal encargado de la realización de las
tareas guardarán secreto profesional sobre todas las informaciones,
documentos y asuntos a los que tengan acceso o conocimiento durante la
vigencia del contrato, estando obligados a no hacerlos públicos ni enajenar
cuantos datos conozcan como consecuencia o con ocasión de su ejecución.
La empresa adjudicataria será responsable de los daños y perjuicios directos o
indirectos sufridos por el Ministerio de Salud y sus dependencias, como
resultado del incumplimiento de la presente obligación.
Responsabilidad
La adjudicataria asegura al Gobierno de la provincia de Santa Fe, que las
creaciones y obras realizadas para las soluciones del presente pliego, serán
originales y no infringen derecho alguno de Propiedad Intelectual o Industrial
de terceros, incluyendo a título meramente enunciativo y no limitativo
derechos de autor, marcas y otros signos distintivos, patentes e invención,
licencias, modelos de utilidad, diseños industriales, frases publicitarias, nombre
comercial, nombres de dominio en Internet, secreto comercial, o información
no divulgada, derechos de imagen o bienes jurídicos similares, y que no se
encuentran gravados, sujetos a inhibición o afectados de cualquier forma que
afecte su libre disponibilidad por el Gobierno de la provincia de Santa Fe.
La adjudicataria declara asumir entera responsabilidad por acciones legales y/o
reclamaciones de cualquier naturaleza incluyendo, a título enunciativo y no
limitativo, reclamaciones extrajudiciales, judiciales, civiles, penales o
administrativas - que puedan originarse en relación con la originalidad y
autoría de las Obras realizadas para la provincia, y responderá de los daños y
perjuicios, multas, penas, costas, costos, gastos causídicos, honorarios de
abogado, gastos, y cualesquiera otras pérdidas que pudieren arrogarse al
Gobierno de la provincia de Santa Fe por tal motivo.
Será de exclusiva responsabilidad del adjudicatario el uso de patentes de
invención, marcas de fábrica o de comercio y otros tipos de propiedad
intelectual (derechos de copia y uso de libros y programas de computador,
etc.) pertenecientes a terceros que requiera para llevar a cabo el objeto de
111
esta licitación. Toda cantidad que el adjudicatario tuviera que pagar para poder
hacer uso de tales derechos de terceros, será de su exclusivo cargo y costo.
Seguimiento y control de la ejecución del proyecto

Todos servicios alcanzados por el presente pliego serán supervisados por la
Subsecretaría de Programas y Proyectos, en conjunto con la Sectorial de
Informática del Ministerio de Salud, pudiendo cualquiera de ellos, realizar las
modificaciones que considere pertinente para la mejora continua de la gestión.
La Subsecretaría de Programas y Proyectos podrá delegar las funciones de
control y seguimiento de los proyectos en la Sectorial de Informática del
Ministerio de Salud.
La modalidad para realizar el seguimiento y control de la ejecución del
proyecto, será la prevista por el Plan Tecnológico Provincial TecnoFe.
El oferente en su oferta deberá identificar como hitos externos en el plan de
trabajo las fechas concretas en la que el Gobierno de Santa Fe tiene que tener
el hardware, las comunicaciones y redes listas. Además, deberá claramente
especificar todo y cada uno de los hardware necesarios con sus capacidades
mínimas y con sus capacidades óptimas. Como así también para las
comunicaciones y redes.
El adjudicatario deberá, además de proveer las licencias, instalar y realizar la
puesta a punto de todo el software, herramientas y software de base en el
entorno de prueba y también en el entorno de producción.
Equipo de trabajo del proveedor

La oferta debe acompañarse de los antecedentes curriculares del equipo y de
la Gerencia del Proyecto, incluyendo años de formación académica y años de
experiencia en implantaciones sobre las mismas herramientas propuestas, así
como un listado con el perfil y horas de contrato de los otros profesionales y
técnicos que formarán parte del equipo del proyecto. También debe
acompañarse la estructura mediante la cual se organizarán estos recursos:
1. Participación de equipos multidisciplinarios: identificar con nombre y título
para participantes de los equipos.
2. Experiencia de los profesionales, en especial en implantación de HIS:
presentar cuadro resumen con nombres y años de experiencia atingente; la
información debe ser comprobable a través de los certificados y de los
antecedentes curriculares anexados.
3. Formación y competencias de los equipos de trabajo.
4. Número de horas de profesionales y técnicos puestos a disposición del
proyecto, detallar número de horas para cada uno de ellos.
5. Soporte de especialistas en mesa de ayuda para los distintos productos
instalados en la plataforma: identificar.
6. Soporte para mesa de ayuda, en periodo de explotación
7. Equipo para la asistencia en terreno para etapa de implantación: identificar
cada integrante.
112
8. Equipo de asistencia en terreno para etapa de explotación.
Perfiles requeridos
El equipo de trabajo dispuesto por la adjudicataria, deberá incluir como mínimo
especialistas con los perfiles que se enuncian a continuación, debiendo
dominar todos ellos el idioma español:
Director del Proyecto

Experto en conducción de equipos interdisciplinarios para implantación
de sistemas informáticos integrales en Establecimientos de Salud de
envergadura semejantes a los Hospitales a implementar y con entornos
de administración del sistema similares al que se solicita. Se valorará la
capacitación en planificación y control de gestión, y experiencia en
implementaciones de aplicaciones de sistemas de gestión con grandes
volúmenes de datos y operaciones, bases de datos relacionales y altas
exigencias de rendimiento.
Especialista en Soporte Técnico (hardware, software de base y

comunicaciones)
Experto en administración de sistemas operativos, manejo de redes
(WAN y LAN) y de diseño de configuración en sistemas de gestión de
grandes volúmenes.
Especialista en Seguridad y Auditoría Informática

Experto en implementación de software de seguridad y de auditoría de
grandes sistemas informáticos, tanto en torno al sistema como dentro de
los componentes internos del mismo.
Especialista en Administración de Bases de Datos

Experto en administración de grandes bases de datos,
fundamentalmente la utilizada en el Sistema Licitado.
Especialista en Informática Médica

Profesional Médico, con conocimientos básicos de Informática Médica, y
experiencia en proyectos de informatización de organizaciones de la
salud.
Especialista en Implementación de Sistemas y Gestión del

Cambio
Experto certificado en Implementaciones de similar envergadura al
Sistema Licitado y en Gestión del Cambio lograr una implementación con
participación activa de los usuarios involucrados en el proceso.
113
Estructura del equipo
Dentro de este servicio, el equipo de trabajo se organizará en dos capas
diferenciadas:
Figura 8 - Estructura del servicio de Soporte para el Desarrollo e

implementación de requerimientos
La Capa de Operación estará formada por todos aquellos perfiles dedicados

de forma específica al liderazgo, desarrollo de funcionalidades, testing e
implementación y que serán quienes estarán a disposición del proyecto.
La Capa de Gestión estará formada por aquel o aquellos perfiles externos al

equipo solicitado y encargados de asegurar el cumplimiento del servicio
estipulado en tiempo, calidad y forma, y de gestionarlo, el adjudicatario,
internamente en su empresa y ante el Gobierno de Santa Fe. Esta capa no
participará del consumo de horas estipulado.
6 Anexo I: Instrucciones para la preparación de la oferta

técnica y su posterior evaluación
Condiciones y Formalidades de las Propuestas
1. Antecedentes técnicos de los oferentes
El objeto de la firma o razón social deberá ser afín al objeto del llamado,
informando la antigüedad en el ramo. El oferente deberá acreditar una
antigüedad societaria superior a los tres (3) años. La misma será calculada
como el período que va desde la fecha de constitución de la sociedad según
consta en el Contrato Social o Estatuto Societario, hasta la fecha de apertura
de la presente gestión. La antigüedad se computará por año calendario,
114
independientemente de las fracciones de tiempo que correspondan al año de
inicio o al presente año. En el caso de una Unión Transitoria (UT) sólo se
computará la antigüedad de la empresa con mayor facturación anual.
En el caso que el oferente sea una UT, cada una de las empresas integrantes
deberán cumplir con los requisitos formales requeridos en la presente
licitación. No obstante, se considerarán en forma conjunta los antecedentes
aportados por las mismas.
El oferente deberá presentar una breve descripción de su experiencia en
ventas análogas y de similar envergadura a las requeridas, realizadas con éxito
y a satisfacción de los mandantes. Dicho listado deberá contener nombre,
dirección de correo electrónico y teléfono de cada empresa o entidad, a los
fines de que el organismo solicitante pueda requerir referencias
complementarias.
No se aceptarán propuestas de oferentes que, resultando personas físicas y/o
jurídicas, no sean comerciantes o casas establecidas en el rubro, distribuidores
mayoristas
2. Consultas y aclaraciones
Los interesados en la gestión podrán efectuar las consultas y pedidos de
aclaraciones que consideren necesarios. Las mismas deberán efectuarse por
escrito, estar firmadas y ser presentadas en la Dirección Provincial de
Contrataciones y Gestión de Bienes, hasta diez (10) días corridos antes de la
fecha límite de presentación de ofertas.
La DPCyGB podrá realizar aclaraciones generales a la presente Solicitud
mediante circulares que serán emitidas de oficio o en respuesta a consultas de
los adquirentes del Pliego hasta cinco (5) días corridos antes de la fecha de
presentación de ofertas.
Un ejemplar de todas las circulares estará a disposición de los interesados en la
DPCyGB.
La presentación de Oferta significa el reconocimiento por el Oferente
respectivo de estar en pleno conocimiento de dichas circulares.
El Oferente será plenamente responsable de la suficiencia de su Oferta y
deberá efectuar todas las investigaciones y verificaciones que considere
necesarias para la formulación de su Oferta y para asegurarse que la
información de respaldo de la misma sea adecuada.
El volumen y detalle de la información que solicite, deberá ser razonable de
acuerdo con los requerimientos de la preparación de las Ofertas, de la
existencia y disponibilidad de la información. La DPCyGB resolverá cualquier
controversia que se planteare en torno a esta cuestión.
La presentación de una Oferta implicará el reconocimiento por parte del
Oferente de que tuvo suficiente acceso a la información necesaria para
prepararla correctamente, y que se basó al efecto exclusivamente en su propia
115
investigación y evaluación, por lo que no serán admitidos ni durante la gestión
ni después de la firma de los Contratos, impugnaciones u otros reclamos
fundados en defectos o insuficiencia de la información provista, en la falta de
respuesta en término o en la demora en brindarlas.
Ninguno de los siguientes organismos: La Provincia, el Ministerio de Gobierno y
Reforma del Estado, el Ministerio de Seguridad y la Dirección Provincial de
Contrataciones y Gestión de Bienes; asumirán responsabilidad alguna respecto
de la calidad, suficiencia o exactitud de la información suministrada.
3. De la presentación de las Ofertas
Las propuestas deberán ser presentadas exclusivamente en formato

electrónico, mediante ……..por consultas al respecto deberán comunicarse al…
en el horario de 09:00 a 17 hs.
Se recibirán ofertas únicamente hasta el momento fijado para su apertura en la

convocatoria respectiva.
Se deberá adjuntar un índice con el nombre de cada uno de los documentos

que componen la oferta y una breve descripción de los mismos.
Los oferentes están obligados a presentar toda la información que sea

necesaria para evaluar sus ofertas en cumplimiento de los requerimientos
exigidos.
La ausencia de información referida al cumplimiento de un requerimiento podrá

ser considerada como “no cumple dicho requerimiento”, no dando lugar a
reclamación alguna por parte del oferente.
Toda la documentación de la oferta se ingresará en formatos abiertos, sin

contraseñas ni bloqueos para su impresión o copiado.
Cuando el oferente deba agregar en su oferta un documento o certificado cuyo

original solo exista en soporte papel, deberá digitalizar el mismo y presentarlo
con el resto de su oferta. En caso de resultar adjudicatario, deberá exhibir el
documento o certificado original.
4. Apertura Electrónica de las Ofertas
La apertura de las Ofertas se efectuará en forma automática en la fecha y hora

indicada. El Acta será remitida por …. a la o las direcciones electrónicas
previamente registradas por cada oferente en ……..Registro Único de
Proveedores del Estado. El acta de apertura permanecerá asimismo visible para
todos los oferentes en la plataforma electrónica.
116
Será de responsabilidad de cada oferente asegurarse de que la dirección
electrónica constituida sea correcta, válida y apta para la recepción de este
tipo de mensajes.
A partir de la fecha y hora establecidas, las ofertas quedarán accesibles para la

Administración contratante, no pudiendo introducirse modificación alguna en
las mismas. Asimismo, las ofertas quedarán visibles para todos los oferentes,
con excepción de aquella información que se entregada en carácter
confidencial.
Solo cuando la Administración contratante solicite salvar defectos o carencias

de acuerdo a lo establecido ….., el oferente deberá .... El instructivo de cómo
proceder se encuentra en…..
Una vez realizada la apertura electrónica de las ofertas, se verificará que todos
los oferentes hayan adquirido el Pliego de Condiciones.
5. De la Vigencia de las Propuestas
117
Las propuestas tendrán vigencia por un período mínimo de ...días calendario
contados a partir de la fecha de apertura, prorrogables automáticamente por
períodos sucesivos de ... días, salvo que mediare comunicación escrita por
parte de la firma oferente, lo que deberá comunicarse con una antelación no
inferior a …. días hábiles antes del vencimiento del plazo inicial o sus
prórrogas. En caso de que el oferente estipularse un plazo menor de
mantenimiento de oferta, se considerará como no estipulado, siendo válido
únicamente el término establecido en el presente numeral.
6. Requerimientos presentación Oferta Técnica
En general en la oferta presentada deberá completar la información solicitada

para cada renglón de acuerdo a lo requerido en el punto 4.2 Detalle de los
componentes.
Completar punto a punto la información correspondiente a cada renglón, en lo

que refiere a Antecedentes del oferente; Servicio de Implementación, soporte,
mantenimiento y capacitación; Equipos de trabajo; Arquitectura del sistema de
Seguridad; Funcionalidades y documentación.
En particular para cada funcionalidad, se solicita detallar respetando el orden

en que las mismas están descritas.
El oferente deberá presentar una planilla de cumplimiento de requerimientos

funcionales y no funcionales para cada renglón, los cuales serán valorados
como excluyentes, en el formato que se detalla a continuación:
118
Renglón I
Detalle de especificaciones funcionales y no Nro. de página

funcionales Requeridas en la oferta
Desde - Hasta
Antecedentes del oferente
Referencias de clientes con contratos vigentes. Datos de las
empresas.
Trayectoria del o de los productos en el mercado > a 2
años
Presencia en el mercado. Implementaciones en red de
establecimientos (cantidad de efectores) al menos 5
efectores. Referencias y datos de las empresas.
Servicio de Implementación, soporte,
mantenimiento y capacitación
Estrategia y plan de implementación adecuado al proyecto:
definición detallada del plan indicando sus objetivos, fases
e hitos principales, actividades, productos, análisis de
riesgos, plan de calidad y despliegue de los recursos, para
la implementación de cada una de las soluciones
requeridas.
Plan de incorporación de los recursos al equipo inicial.
Servicios de consultoría para adaptar los HIS provinciales a
la nueva solución HCEC: definición detallada del plan
indicando sus objetivos, fases e hitos principales,
actividades, productos, análisis de riesgos, plan de calidad
y despliegue de recursos.
Plan de gestión de cambio: estrategia, objetivos y
conformación de equipos de trabajo.
Especificar cómo se planificarán, estructurarán,
monitorearán y controlarán las comunicaciones del
proyecto, identificando entre otros: información a ser
comunicada, destinatarios, plazo y frecuencia y
responsable de la emisión.
Descripción de los servicios de mantenimiento y soporte
técnico, sus características, niveles de servicio y plazos de
prestación previstos y garantía.
Descripción detallada de cada una de las capacitaciones,
diseño, organización y dictado, a quién va dirigida,
duración, temario general, requisitos para su realización,
certificaciones y entrega de documentación.
Equipos de trabajo
Director del proyecto: Definición de responsable técnico
que dirigirá el proyecto por parte del adjudicatario.
Currículo del director.
119
Definición de los equipos de trabajo, indicando sus
integrantes, dedicación y funciones, y los roles con que
participa cada integrante.
Currículos de las personas que conforman el equipo de
trabajo.
Promedio de años de experiencia en implementaciones de
los Especialistas área clínica.
Promedio de años de experiencia en implementaciones de los
Especialistas en implementación.
Especialistas procesos productivos sanitarios.
Especialistas en instalación y mantención de equipamiento informático.
Arquitectura del Sistema y Seguridad
Aplicación WEB con arquitectura de N-capas.
Arquitectura lógica y física de la solución.

Incluir un diagrama de despliegue de los distintos ambientes (pruebas y
producción).
Nombre, versión y modalidad de licenciamiento de cada uno de los
componentes de software que integran la solución.
Especificación de toda la documentación que se entregará con las
herramientas.
Proponer las especificaciones de la infraestructura
tecnológica para aplicaciones y bases de datos para
montar los aspectos centralizados de la solución, la cual
Licencias y versiones:
Detalle de cada uno de los componentes de software utilizados en la
arquitectura física propuesta.
Licencias de software (versión más reciente) para cada uno de los
productos contemplados.
Definición de entorno, arquitectura y puesta a punto.
Update y/o upgrade de software requerido.
Resumen de software que entregará el adjudicatario.
Software, versión, tipo de licenciamiento, cantidad de
usuarios, tipos de usuarios.
La oferta debe incluir actualizaciones del software sin costo
adicional por un período de 3 años.
Se debe especificar detalladamente las características que
incluyen las licencias ofertadas.
Se debe indicar si el software ofertado tiene algún límite
técnico en cantidad de usuarios, uso de espacio en disco,
cantidad de CPU o cualquier otro aspecto que pueda limitar
el crecimiento de la solución a futuro.
Se debe indicar detalladamente como se debe aumentar el
licenciamiento del software ofrecido para escalar la
120
solución a futuro.
Se deben proveer los manuales del software ofertado y sus
componentes.
Funcionalidades y documentación
Renglón I - Para ambas soluciones:
Descripción funcional de cada herramienta.
Cumplimiento de funcionalidades requeridas en el presente pliego.
Indicando la forma de cumplimiento (lo trae incorporado la herramienta,
se parametriza, se desarrolla, etc.)
herramientas.
Renglón I.1: Descripción detallada de las funcionalidades
para la solución de Historia Clínica Electrónica Compartida,
que permita construir y visualizar el historial clínico del
ciudadano, usuario de la red de salud de la provincia.
Será condición la implementación de los perfiles de
integración: XDS - Cross-Enterprise Document Sharing
y PIX - Patient Identifier Cross-Referencing, utilizando
los siguientes componentes:
- Índice Maestro de pacientes
- Registro XDS
- Repositorio XDS.b
- Canal de interoperabilidad
- Intercambio de documentos CDA, mensajería HL7v2
y personalizados
- Visor para el usuario final
Renglón I.2: Descripción detallada de las funcionalidades
contempladas para el Portal de Salud del Ciudadano. Esta
solución debe brindar el acceso individual a cada
ciudadano de su Historial Clínico personal, a todos sus
eventos clínicos registrados en cualquier punto de la red
de salud, a través de aplicación web y dispositivos móviles.
- Deberá implementar los perfiles de integración
definidos por la HCEC, para lo cuál usará la
información de los documentos CDA, y mensajes
HL7v2 guardados en los repositorios XDS.b
- Deberá interoperar con el sistema de administración
de agendas y turnos
- Visualizar contenidos educativos
- Interfase de enrolamiento y esquema de seguridad
de acceso y visibilidad por usuario
Renglón I.3: Servicios de implementación para la
soluciones de HCEC y PSC
Renglón I.4: Servicios de consultoría para adaptar los HIS
provinciales a la nueva solución HCEC
121
Renglón II

Desde - Hasta
Referencias de clientes con contratos vigentes. D atos de las
empresas.
años
Presencia en el mercado. Implementaciones en
establecimientos con más de 100 camas. Referencias.
Presencia en el mercado. Implementaciones con al menos un
50% de módulos requeridos en las bases del HIS que estén en
explotación. Referencias y datos de las empresas.
requeridas, y específicamente además, para las
implementaciones en los hospitales de Venado Tuerto,
hospital de Ceres, Provincial de Rosario y J. M Cullen de
Santa Fe.
Servicios de consultoría para integrar los HIS provinciales a
la nueva solución: definición detallada del plan indicando
sus objetivos, fases e hitos principales, actividades,
productos, análisis de riesgos, plan de calidad y despliegue
de recursos.
Equipos de trabajo
122
trabajo.




Incluir un diagrama de despliegue de los distintos
ambientes (pruebas y producción).
Nombre, versión y modalidad de licenciamiento de cada
uno de los componentes de software que integran la
solución.
Especificación de toda la documentación que se entregará
con las herramientas.
Detalle de cada uno de los componentes de software
utilizados en la arquitectura física propuesta.
Licencias de software (versión más reciente) para cada uno
de los productos contemplados.
Se debe especificar detalladamente las características que
incluyen las licencias ofertadas.
123
solución a futuro.
componentes.
Funcionalidades documentación
Visión y enfoque de la solución integral, identificando los
distintos componentes, sus relaciones, destacando el
aporte de valor al sistema de salud pública y a los
programas y proyectos de TecnoFE.
Descripción funcional de cada herramienta.
Cumplimiento de funcionalidades requeridas en el presente
pliego. Indicando la forma de cumplimiento (lo trae
incorporado la herramienta, se parametriza, se desarrolla,
etc.)
El HIS propuesto debe interoperar con la solución de HCEC
dentro del marco técnico propuesto por IHE, especificado
en el renglón I del presente pliego.
Las funcionalidades de los módulos de Agendas y Turnos,
deberán interoperar con la solución de Agendas y Turnos
especificadas en el Renglón III del presente pliego.
El HIS deberá estar integrado con las soluciones ERP, LIS,
RIS -PACS propuestos.
HIS: descripción detallada de las funcionalidad del módulo
de gestión de la configuración que permita configurar
Seguridad, Agendas y Camas
de gestión Administrativa que contemple mínimamente:
Admisión de pacientes, Gestión de Turnos y Gestión de
internaciones.
de Gestión asistencial, que contemple mínimamente,
contemplando el uso de servicios terminológicos:
● Registro asistencial en guardia, en atención
ambulatoria, e internaciones.
● Gestión de quirófanos
● Módulo de indicaciones y prescripciones
● Gestión de enfermería
ERP: descripción detallada de las funcionalidad del ERP,
que contemple mínimamente la automatización de
procesos básicos, administrativos y de apoyo:
● Dispensa de medicamentos
● Gestión de insumos
● Gestión contable y financiera
● Gestión de Recursos Humanos
● Gestión de Informes y reportes
124
LIS: descripción detallada de las funcionalidad del Sistema
de gestión para Laboratorio, integrado al HIS
RIS: descripción detallada de las funcionalidad del módulo
de gestión de imágenes, interoperando con el PACS e
integrado al HIS
125
Renglón III

Desde - Hasta
Referencias de clientes con contratos vigentes . Datos de
las empresas.
años
Presencia en el mercado. Implementaciones en red de
establecimientos (cantidad de efectores). Referencias y
datos de las empresas.
requeridas.
Servicios de consultoría para adaptar los HIS provinciales a
la nueva solución de Gestión de Agendas y turnos:
riesgos, plan de calidad y despliegue de recursos.
conformación de equipos de trabajo
Especificar cómo se planificará, estructurará, monitorearán
y controlarán las comunicaciones del proyecto,
identificando entre otros: información a ser comunicada,
destinatarios, plazo y frecuencia y responsable de la
emisión.
Equipos de trabajo
126
trabajo.



Incluir un diagrama de despliegue de los distintos ambientes (pruebas y
producción).
Nombre, versión y modalidad de licenciamiento de cada uno de los
componentes de software que integran la solución.
herramientas.
Proponer las especificaciones de la infraestructura tecnológica para
aplicaciones y bases de datos para montar los aspectos centralizados de
la solución, la cual deberá ser consensuada con el Gobierno de Santa Fe.
Detalle de cada uno de los componentes de software utilizados en la
arquitectura física propuesta.
Licencias de software (versión más reciente) para cada uno de los
productos contemplados.
Software, version, tipo de licenciamiento, cantidad de usuarios, tipos de
usuarios.
Detalle de las características que incluyen las licencias
ofertadas.
solución a futuro.
componentes.
127
Funcionalidades documentación
Descripción funcional de cada componente.

etc.)
Renglón III.1:
Descripción detallada de las funcionalidad para la Gestión
de Agendas y Turnos, implementado los perfiles de
integración propuestos por IHE para la identificación de
pacientes, especificado en el renglón I del presente pliego.
Descripción detallada de la Plataforma de interoperabilidad
con el Portal de Salud del Ciudadano
Descripción detallada de la Plataforma de interoperabilidad
con los diferentes HIS utilizados por los efectores de la
provincia
Descripción detallada de las funcionalidades para la
Gestión de listas de espera.
Descripción detallada de las funcionalidades para la
Notificación al paciente vía SMS o email.
128
Renglón IV

Desde - Hasta
Referencias de clientes con contratos vigentes. Datos de
las empresas.
Experiencia a lo largo de los últimos 3 años en la
prestación de servicios análogos a los que se requieren en
el presente pliego. Indicando además referencias y datos
de las empresas.
(contemplando mínimamente las etapas y actividades
especificadas en el presente pliego) e hitos principales,
actividades, productos, análisis de riesgos, plan de calidad
y despliegue de los recursos, para la implementación de la
solución.
Específicamente, tareas contempladas para la integración
de diversas fuentes de datos.

Equipos de trabajo
Director del proyecto: definición de responsable técnico
129
trabajo.
Promedio de años de experiencia en desarrollo e
implementación de soluciones de Inteligencia de negocios.

Incluir un diagrama de despliegue de los distintos
ambientes (pruebas y producción).
Nombre, versión y modalidad de licenciamiento de cada
uno de los componentes de software que integran la
solución.
Detalle de cada uno de los componentes de software
utilizados en la arquitectura física propuesta.
Licencias de software (versión más reciente) para cada uno
de los productos contemplados.
Especificar detalladamente las características que incluyen
las licencias ofertadas.
solución a futuro.
componentes.
Funcionalidades y documentación
Descripción funcional de la herramienta de software.
130
etc.)
Renglón IV.1: Descripción detallada de las
funcionalidades para la solución para visualización de
mapa GIS.
Renglón IV.1: Compatibilidad con estándares del
Gobierno de Santa Fe.
7 Anexo II - Integración del HIS/ERP con Sistemas

Externos
131
NOMBRE DESCRIPCIÓN INFORMACION A INTEGRAR
PROGRAMAS PROVINCIALES TRANSVERSALES
SIPAF Sistema Prov. de No definida en el ámbito de
Administración Financiera: este Proyecto
Sistema utilizado en toda la
administración pública
provincial para la gestión
presupuestaria, financiera y
contable de cada Ministerio.
SARH Sistema de Administración El Módulo de RRHH del ERP
de Recursos Humanos: debe proveer mensualmente
Sistema transversal utilizado al SARH, las novedades para
para la gestión y control de la liquidación de Sueldos, en
todos los Recursos Humanos un archivo digital..
de la Provincia.
Sistema Nuevo sistema que va a No definida en el ámbito de
Provincial de adquirir la provincia para este Proyecto
Compras facilitar y transparentar la
gestión de las compras en
todas las dependencias
públicas de la Provincia.
PROGRAMAS DEL MINISTERIO DE SALUD
SICAP Sistema de Gestión para El HIS Licitado, debe replicar
Centros de At. Primaria. en el SICAP la siguiente
Sistema WEB con una base información a través de Web
única de pacientes que service:
posibilita la registración de - ABM de pacientes.
todas las prácticas - Las consultas ambulatorias
ambulatorias que se realizan del Hospital.
en los CAP’s de la Provincia. - Las Vacunas realizadas en el
efector.
- visualizar desde el HIS el
carnet de Inmunizaciones
del Paciente que reside en
SICAP.
Laboratorio Base Central donde se El LIS deberá informar las

central almacenan, procesan y prácticas de laboratorio
consultan todos los estudios solicitadas, realizadas y sus
de laboratorios y del cual se respectivos resultados a la
nutren para elaboración de Base de datos central, a
análisis e informes través del Web service
diferentes Direcciones definido.
Provinciales y Programas de
Salud.
SUFyD Sistema único de farmacia y El Módulo de Stock del ERP,
Droguería Central. Sistema deberá interactuar a través
utilizado para gestionar toda de los Web service definidos,
la logística de distribución para realizar las sig. Tareas:
de medicamentos en toda la - Solicitud/Recepción de
132
Red de la Provincia medicamentos a la
(Droguería Central, Droguería Central.
Droguerías Nodales, - Recepción de pedidos de los
Farmacias Hospitalarias,
CAP’s.
Centros de Salud y
Programas Nacionales) - Distribución de
medicamentos a los CAP’s.
- Consulta de Stock del
Hospital desde Nivel Ctral.
Tablas maestras Tablas normalizadas El HIS deberá Consultar

comunes a todos los diferentes Tablas maestras
Sistemas del Ministerio de que son utilizadas por otros
Salud. Sistemas del Ministerio de
Salud, de manera de adoptar
una codificación única.
Padrón de Obras Base de Datos de afiliados a El HIS deberá consultar la
Sociales Obras Sociales, donde se cobertura médica de los
consolidan los Padrones de pacientes en esta Base, a
todas las Obras Sociales través de 1 web service.
Nacionales, la obra Social
Provincial (IAPOS) y Prog.
Nacional Incluir Salud.
CADSIES Sistema Central de El HIS deberá suministrar a
Emergencias Sanitarias y través de Web service,al
derivaciones sistema de emergencias
Interhospitalarias. sanitarias CADSIE
- la dotación y estado de las
camas.
- Informar el estado de las
salas de Guardia y
emergencias
- Solicitudes de traslados
entrantes y salientes del
efector
PROGRAMAS NACIONALES
Sistema Nacional Este sistema es alimentado Deben remitir periódicamente

de Estadísticas por el aporte de información a la Dir. Prov. de Estadísticas,
de Salud. de todas las Direcciones a través de archivos digitales,
prov. de estadísticas, información de egresos
contempla registros de Hospitalarios y producción
vitales, morbilidad Ambulatoria.
hospitalaria, prod.
ambulatoria, entre otros.
Sistema Nacional Sistema del Ministerio de Deberá generar el informe C2
de Vigilancia de Salud de Nación para la (Enfermedades de
la Salud (SNVS) recolección sistemática de notificación obligatoria) para
los casos de notificación informar al SNVS.
obligatoria que fueron
133
atendidos en los distintos
efectores de salud.
Programa El SIVILA es el Módulo de Deberá generar un reporte,
Nacional de Vigilancia por Laboratorio con los datos de laboratorio
Vigilancia por del SNVS. Integra a la solicitados por el SIVILA, para
Laboratorios Vigilancia epidemiológica los facilitar la carga en dicho
(SIVILA) resultados de Laboratorios sistema.
de los efectores de Salud.
Sistema de Sistema que mantiene un No definida en el ámbito de
Integrado de Inf. registro actualizado de este Proyecto
Sanitaria (SIISA) Establecimientos de Salud
(REFES) y Profesionales
matriculados (REFEPS) de
todo el País.
SATI-Q, Software utilizado para El HIS, deberá generar una
colectar datos relacionados salida que facilite la carga de
a estándares de calidad en datos en este Sistema.
las Unidades de Cuidados
Críticos. Alimentan el
Programa Nacional de
Calidad de Atención de la
Sociedad Argentina de
Terapia Intensiva.
SIP, Sistema de Sistema de la OPS, que tiene El HIS deberá contemplar
Información por objeto recolectar todas las variables que
Perinatal. información referente a las solicita el SIP, y debe proveer
embarazadas y a los recién en archivo de texto la
nacidos en los servicios de información que se envía al
gineco/obstetricia y nivel central
neonatología en los
Establecimientos de Salud.
AFIP – Conjunto de sistemas de la Los módulos del ERP, deberán
Administración AFIP, a los cuales hay que interactuar a través del canal
federal de informar obligatoriamente de Interoperabilidad, para
Ingresos información de retenciones a suministrar a la AFIP la
Públicos. proveedores, facturación información que esta
electrónica, entre otros requiera.
8 Anexo III: Evaluación de las ofertas

1. Comisión Evaluadora:
Las ofertas que se presenten serán estudiadas y evaluadas por una Comisión
Evaluadora, integrada por 10 funcionarios que se detallan a continuación:
● Secretario de Tecnología para la Gestión, o quien este designe.

● Subsecretario de Programas y Proyectos de la Secretaría de Tecnología
para la Gestión, o quien ésta designe.
134
● Directores Provinciales del Ministerio de Salud:
o Director Provincial de Gestión de Procesos de Trabajo.
o Director Provincial de Gestión de la Información.
● Jefe de Sectorial de Informática del Ministerio de Salud, o quien este
designe.
● Secretario de Salud de 1er y 2do Nivel de Salud, o quien este designe.
● Secretario de Salud de 3er Nivel de Salud, o quien este designe.
● Secretario de Administración del Ministerio de Salud, o quien este
designe.
● Diez (10) profesionales de la salud –como mínimo- a designar por el
Ministerio de Salud.
La integración de la Comisión Evaluadora se publicará en el Sistema de
Información de Contratación Pública.
Esta Comisión informará sobre las ofertas que mejor cumplan con los criterios
de evaluación establecidos en el presente pliego y debiendo ser éstas las más
convenientes a los intereses de la del Gobierno de la Provincia de Santa Fe.
En caso de no considerar apropiadas las ofertas presentadas, podrá declararse

desierta la licitación. Aún ante esta situación, la Comisión Evaluadora verificará
la admisibilidad de las propuestas conforme a lo previsto en las presentes
Bases administrativas.
De considerarse necesario, la Comisión Evaluadora, requerirá a los

proponentes a través del portal de la provincia de Santa Fe, aclaraciones sobre
aspectos vinculados a su propuesta que no resulten suficientemente claros. Las
respuestas deberán ser entregadas a través del mismo medio dentro del plazo
establecido en el calendario respectivo.
Tanto las aclaraciones solicitadas como las respuestas a las mismas, pasarán a
formar parte integrante de los antecedentes del contrato en caso de serle
adjudicado.
2. Pautas para la evaluación de las propuestas:
Los criterios de evaluación que utilizará la Comisión Evaluadora y sus

ponderaciones son los siguientes, para cada renglón:
Renglón I:
Etapa 1:
a. Antecedentes del Oferente (puntaje máximo 27 puntos)
1. Trayectoria del oferente, aportando referencias de clientes:

certificados emitidos por los respectivos representantes legales de
135
clientes vigentes, hasta 3 (tres) años anteriores a la fecha de
publicación de la presente licitación.
2. Trayectoria -del o de los- productos ofrecidos y servicios

prestados: años en el mercado, años de evolución del software,
integraciones exitosas y mapa de ruta (roadmap) de la aplicación
ofertada.
3. Presencia en el mercado: número de establecimientos en la red de

salud implementados con el número de camas de cada uno de
ellos.
4. Certificaciones de calidad: normativas de calidad -CMMI y otras-,

fotocopias de certificados vigentes.
Antecedentes del Oferentes - Puntaje Máximo 27 puntos

Hasta 5
Trayectoria del oferente, 2
referencias
Referencias de clientes Referencias vigentes
con contratos vigentes Más de 5
6
referencias
Años de evolución del De 5 años hasta
2
Trayectoria del -o de los- software 10
Producto Años de evolución del
Más de 10 años 6
software
Hasta 5 2
Implementaciones en red
Presencia en el Mercado de establecimientos De 5 hasta 10 5
(Cantidad de Efectores)
Más de 10 9
2,
CMMI 0,5 por nivel
5
0,5 por
Certificaciones
certificación 3,
Otras Certificaciones
máximo puntaje 5
3,5
b. Metodología de Implementación (Puntaje máximo 45

puntos)
Considera los siguientes elementos:
136
1. Metodología de Implantación, en la cual se debe explicitar la
estrategia, el plan de implantación y fundamentar la proposición
en base a experiencias exitosas con esta metodología en
proyectos de similar envergadura o naturaleza.
2. Incorporación de un Plan de Gestión del Cambio, que involucre

tempranamente y en forma práctica a los usuarios, proponiendo
equipos de trabajo, metodología de trabajo, plan de comunicación,
análisis de riesgo y plan de formación y acompañamiento, los que
deben contemplar estrategias de incorporación de recursos
humanos al hospital.
3. Capacidad del oferente de contar con el modelo conceptual y el

conocimiento de la gestión en salud.
4. Cronograma de Implantación, en el cual se especifiquen tiempos

estimados para cada etapa considerando plazos establecidos en
las Bases de Licitación.
5. Vinculación con empresas locales para el abordaje de la

implementación.
137
Metodología de Implementación - Puntaje máximo 45 puntos
Estrategia de Implantación
SI/NO 5
adecuada al proyecto
Metodología de
Implementación Plan: descripción detallada
de la manera en que SI/NO 5
desarrollará la implantación
Incorporación de un Plan de
Equipos de trabajo SI/NO 5
Gestión del Cambio
Metodología de Trabajo SI/NO 3
Plan de comunicación SI/NO 3
Capacidad del oferente de
contar con el modelo Análisis de Riesgo SI/NO 3
conceptual y el
conocimiento de la gestión Plan de Formación y
SI/NO 3
acompañamiento
en salud
Implantaciones en red de
SI/NO 8
establecimientos.
Coincidencia del plan de
Cronograma de
implementación con el SI/NO 5
implantación
cronograma propuesto
1 punto por
Experiencia en Certificaciones específicas certificació
implementaciones aplicadas a la n. 5
certificadas. implementación
Máximo 5
c. Equipos de Trabajo (Puntaje Máximo 28 puntos)

técnicos que formarán parte del proyecto. También debe acompañarse la
estructura mediante la cual se organizarán estos recursos:
1. Promedio de años de experiencia en implementaciones de los

Especialistas área clínica

Especialistas en implementación

Especialistas procesos productivos sanitarios
138
Especialistas en instalación y mantención de equipamiento
informático
Equipos de Trabajo Puntaje Máximo 28 puntos
Promedio de años de experiencia en Hasta 5 años 2

implementaciones de los Especialistas área clínica Más de 5 años 5
implementaciones de los Especialistas en
implementación Más de 5 años 5

implementaciones de los Especialistas procesos
productivos sanitarios Más de 5 años 5

implementaciones de los Especialistas en instalación y
mantención de equipamiento informático Más de 5 años 5
Etapa 2:
d. Funcionalidades generales (Puntaje máximo 10 puntos)
Se evaluarán los productos complementarios que apliquen a la calidad de

gestión de las soluciones, sin contemplar las implementaciones de las mismas.
Funcionalidades Generales puntaje máximo 10 puntos

Valor agregado de productos
complementarios que apliquen a la
Valor agregado de
calidad de gestión de las soluciones.
productos SI/NO 10
La valoración no incluye la
complementarios
implementación de las
funcionalidades propuestas.
e. Arquitectura del Sistema y Seguridad (puntaje máximo 30

puntos)
139
Arquitectura del Sistema y Seguridad puntaje máximo 30 puntos
Cumplimiento Licencia GPL SI/NO 4
Arquitectura multisitio/ servidor SI/NO 3
Utilización de bases de datos soportadas por la
SI/NO
provincia 4
La interfaz del usuario independiente del navegador,
SI/NO
con soporte HTML5. 2
Sistema operativo cliente Linux, basado en Linux-
SI/NO
Debian 7
Arquitectura de Software Libre SI/NO 3
Compatibilidad con la infraestructura tecnológica de
SI/NO
la Provincia de Santa Fe 4
Integración con el Sistema de Autenticación SI/NO

Centralizado (CAS) 3
f. Evolución y Soporte del Sistema (Puntaje máximo 8 puntos)
Evolución y Soporte del Sistema puntaje máximo 8 puntos

≤3
referencias 0
≥3
referencias y
Referencias de clientes ≤5
Informe con referencias
relacionadas con calidad de referencias 1
de clientes
servicio
Entre 6 y 7
referencias 2
≥8
referencias 3
Conformación y disponibilidad Equipo de Desarrollo
SI/NO
de Equipos de Desarrollo formado en Argentina 2
Informe de experiencias
Capacidad de operar con otros exitosas de trabajos
SI/NO
proveedores y sus desarrollos con otros proveedores
de sistemas 3
140
g. Cumplimento de Funcionalidades HCEC, PSC Puntaje Màximo 52
Puntos
141
Cumplimento de Funcionalidades HCEC, PSC Puntaje Màximo 52 Puntos
Menos del
0
50 %
Historia Clínica Electrónica
Compartida: Porcentaje de Más del 50%
cumplimiento de hasta el 3
- canal de interoperabilidad
funcionalidad 80%
- visor presentada v/s Más del 80%
5
- implementación de perfiles de solicitada hasta 99%
integración IHE
1
100%
0
Portal de Salud del Ciudadano: Menos del
0
50 %
- visualización del historial
clínico del paciente Mas del 50%
hasta el 3
- interoperabilidad con sistema
Porcentaje de 80%
de turnos
cumplimiento de Mas del 80%
- visualización de contenido funcionalidad 5
hasta 90%
educativo presentada v/s
- implementación de perfiles de solicitada
integración IHE
1
100%
- Interfase de enrolamiento y 0
esquema de seguridad de
acceso y visibilidad por usuario
Menos del
0
50 %
Porcentaje de Mas del 50%

cumplimiento de hasta el 3
Flujo interno de seguimiento de 80%
funcionalidad
Procesos Sanitarios
presentada v/s Mas del 80%
solicitada 5
hasta 90%
1
100%
0
Exposición de caso práctico de Prueba de un caso Menos del
0
proceso clìnico en que se clínico de un paciente 50 %
muestren las relaciones entre
Mas del 50%
los diferentes componentes de
hasta el 3
los Sistemas Informàticos
80%
Mas del 80% 5
142
hasta 90%
1
100%
0
Vínculo laboral con empresas Vinculación con
1
de localización provincial para empresas localizadas en SI/NO
2
el cumplimiento del Renglón I.4 la provincia de Santa FE
Etapa 3:
h. Evaluación Económica (Puntaje máximo 100 puntos)
Evaluación Económica Puntaje máximo 100 puntos
5
1º Lugar 0
4
Valoración comparativa de 2º Lugar 0
Análisis de costo por renglón
la oferta económica (*)
3
3º Lugar 0
4º Lugar 0
Aceptación del cronograma de 3

Cumple
cumplimiento Si/No 0
2
1º Lugar 0
1
Costo de funcionalidades 2° Lugar 5
complementarias
1
3º Lugar 0
4º Lugar 0
i. Ponderación
143
Ponderación de la Etapa
sobre el total de la
Etapas de Evaluación puntuación
Antecedentes , Equipo e Implementación 40%
Funcionalidades Soluciones 40%
Economico 20%
Renglón II:
Etapa 1:


ofertada.
3. Presencia en el mercado: número de establecimientos con más de

100 camas y con al menos un 50% de módulos requeridos en las
bases del HIS que estén en explotación.

144
Hasta 5
referencias
5
referencias
2
Más de 10 años 5
software
Establecimientos con más
de 100 camas, con al
menos un 50% de
módulos requeridos en las
bases del HIS que estén
en explotación SI/NO 2
Establecimientos con más
Presencia en el Mercado
de 240 camas, con al
menos un 50% de
módulos requeridos en las
bases del HIS que estén
en explotación SI/NO 5
de establecimientos. SI/NO 4
2,
CMMI 0,5 por nivel
5
0,5 por
Certificaciones
certificación 3,
Otras Certificacion
máximo puntaje 5
3,5

puntos)
145



implementación.

SI/NO 5
Metodología de
Gestión del Cambio
conceptual y el
SI/NO 3
acompañamiento
en salud
SI/NO 8
establecimientos.
Cronograma de
implantación
1 punto por
Máximo 5
146



Etapa 2:
147
≤ 74% 1
Compatibilidad de la oferta con
Porcentaje de ≥ 75% y ≤
requerimientos de las Bases y 2
compatibilidad 94%
realidad local
≥ 95% 4
Valor agregado de
productos
complementarios que SI/NO 2
complementarios
apliquen a la calidad de
gestión de las soluciones
Grado de adecuación de los % de especialidades

registros clínicos a las médicas (total existentes
≥ 85% 1
diferentes especialidades en la red) a las que se
médicas adecua
Informes predefinidos de
gestión clínica
SI/NO 1
establecidos en las bases
del pliego
Informes predefinidos de
gestión administrativa
SI/NO 1
establecidos en las bases
de pliego
Facilidad para acceder a
informes de gestión Informes
predeterminados de
resultados de exámenes,
SI/NO 1
procedimientos y otros
formularios de uso
diverso
Herramienta de
generación de informes SI/NO 1
no predefinidos
e. Arquitectura del Sistema y Seguridad (puntaje máximo 30

puntos)
148
Utilización de bases de datos soportadas por la
SI/NO
provincia 4
La interfaz del usuario independiente del
SI/NO
navegador, con soporte HTML5. 2
Sistema operativo cliente Linux, basado en Linux-
SI/NO
Debian 5
Compatibilidad con la infraestructura tecnológica
SI/NO
de la Provincia de Santa Fe 4

Entrega del Código Fuente SI/NO 4

≤3
referencias 0
≥3
referencias y
de clientes
servicio
Entre 6 y 7
referencias 2
≥8
referencias 3
SI/NO
SI/NO
de sistemas 3
149
g. Cumplimento de Funcionalidades HIS e IMPLEMENTACION
(LIS-RIS-PAC-ERP) Puntaje Màximo 51 Puntos
150
Cumplimento de Funcionalidades HIS e IMPLEMENTACION (LIS-RIS-
PAC-ERP) Puntaje Màximo 51 Puntos
Menos del
50 % 0
Mas del
Porcentaje de cumplimiento 50% hasta
HIS de funcionalidad presentada el 80% 3
v/s solicitada Mas del
80% hasta
99% 4
100% 5
Menos del
50 % 0
Mas del
ERP de funcionalidad presentada el 80% 3
80% hasta
99% 4
100% 5
Menos del
50 % 0
Mas del
LIS de funcionalidad presentada el 80% 3
80% hasta
99% 4
100% 5
RIS Porcentaje de cumplimiento Menos del
de funcionalidad presentada 50 % 0
v/s solicitada
Mas del
50% hasta
el 80% 3
Mas del
80% hasta
99% 4
100% 5
151
Menos del
50 % 0
Mas del
Flujo interno de Porcentaje de cumplimiento 50% hasta
seguimiento de Procesos de funcionalidad presentada el 80% 3
Sanitarios v/s solicitada Mas del
80% hasta
99% 4
100% 5
Menos del
50 % 0
Mas del
Pruebas de Captura y operación de 50% hasta
interconectividad con imágenes almacenadas en el el 80% 3
Sistema RIS PACS PACS directo desde la ficha. Mas del
80% hasta
99% 4
100% 5
Menos del
50 % 0
Exposición de caso
práctico de proceso clìnico Mas del
en que se muestren las 50% hasta
Prueba de un caso clínico de el 80% 3
relaciones entre los
un paciente
diferentes componentes Mas del
de los Sistemas 80% hasta
Informàticos 99% 4
100% 5
Implementación del marco
técnico de IHE para el
dominio de Radiología en
SI/NO
el servicio de mensajería a
través del cual van a
interoperar el RIS y el HIS. 2
Aplicación de los perfiles SI/NO 2
IHE especificados para
cada dominio, en la
integración con los
sistemas hacia el interior
152
del efector, contemplando
el uso de estándares para
el intercambio electrónico
de información clínica, con
la imagen digital: DICOM,
con los informes de
laboratorio: el estándar de
referencia de
interoperabilidad
semántica LOINC,
disponiendo de resultados
comparables e
interactuando a través de
mensajería CDA – HL7.
Vinculación con empresas
Vínculo laboral con localizadas en la provincia de SI/NO
empresas de localización Santa FE 4
provincial para el
cumplimiento del Renglòn Vinculación con empresas
II.2 localizadas en las ciudades SI/NO
de implementación 8
Etapa 3:
j. Evolución Económica (Puntaje máximo 100 puntos)
153
5
1º Lugar 0
4
2º Lugar 0
3
3º Lugar 0
Valoración comparativa de
Análisis de costo por renglón la oferta económica (*) 4º Lugar 0

cumplimiento Cumple Si/No 0
2
1º Lugar 0
1
2° Lugar 5
1
3º Lugar 0
Costo de funcionalidades
complementarias 4º Lugar 0
k. Ponderación
Ponderación de la Etapa sobre

Etapas de Evaluación el total de la puntuación
Económico 20%
Renglón III:
Etapa 1:

154
ofertada.
3. Presencia en el mercado: número de establecimientos

interoperando con el sistema de agendas y turos implementados
en la red de salud, especificando el número de camas,
cuantificación de agendas y turnos en cada uno de ellos.


Hasta 5
referencias
con contratos vigentes Mas de 5
6
referencias
2
Más de 10 años 6
software
Hasta 5 2
Presencia en el Mercado de establecimientos De 5 hasta 10 5
(Cantidad de Efectores)
Más de 10 9
2,
CMMI 0,5 por nivel
5
0,5 por
Certificaciones
certificación 3,
Otras Certificacion
máximo puntaje 5
3,5

puntos)
155




implementación.
156
SI/NO 5
Metodología de
Gestión del Cambio
conceptual y el
SI/NO 3
acompañamiento
en salud
SI/NO 8
establecimientos.
Cronograma de
implantación
1 punto por
Máximo 5

estructura mediante la cual se organizan estos recursos:



157
informático



Etapa 2:

≤ 74% 1
Compatibilidad de la oferta con
Porcentaje de ≥ 75% y ≤
requerimientos de las Bases y 4
compatibilidad 94%
realidad local
≥ 95% 5
Valor agregado de
productos
complementarios que SI/NO 5
complementarios
apliquen a la calidad de
gestión de las soluciones
e. Arquitectura del Sistema y Seguridad (puntaje máximo 30 puntos)
158

Utilización de bases de datos soportadas por la provincia SI/NO 4
La interfaz del usuario independiente del navegador, con soporte
SI/NO
HTML5. 2
Sistema operativo cliente Linux, basado en Linux- Debian SI/NO 7
Compatibilidad con la infraestructura tecnológica de la Provincia
SI/NO
de Santa Fe 4


≤3
referencias 0
≥3
referencias y
de clientes
servicio
Entre 6 y 7
referencias 2
≥8
referencias 3
SI/NO
SI/NO
de sistemas 3
g. Cumplimento de Funcionalidades del Sistema de Agendas

y Turnos Puntaje Máximo 52 Puntos
159
Cumplimento de Funcionalidades del Sistema de Agendas y Turnos
Puntaje Máximo 52 Puntos
Menos del 50
% 0
Porcentaje de
Gestión de Agedas y Turnos funcionalidad hasta el 80% 3
solicitada hasta 99% 4
100% 6
Menos del 50
% 0
Porcentaje de
Plataforma de interoperabilidad Mas del 50%
cumplimiento de
para gestionar los turnos desde hasta el 80% 3
funcionalidad
el portal de salud del
ciudadano
100% 6
Menos del 50
% 0
Porcentaje de
Plataforma de interoperabilidad cumplimiento de Mas del 50%
con los HIS de los efectores de funcionalidad hasta el 80% 3
la provincia presentada v/s Mas del 80%
100% 6
Menos del 50
% 0
Porcentaje de
Notificaciones al paciente vía hasta el 80% 3
funcionalidad
SMS, o email
100% 6
Flujo interno de seguimiento de Porcentaje de Menos del 50 0

Procesos Sanitarios cumplimiento de %
160
Mas del 50%
hasta el 80% 3
funcionalidad
100% 6
Menos del 50
% 0
Exposición de caso práctico en
que se muestren las relaciones Mas del 50%
Prueba de caso hasta el 80% 3
entre los diferentes
práctico
componentes de los Sistemas Mas del 80%
Informáticos hasta 99% 4
100% 6
Vinculación con
empresas localizadas
SI/NO
Vínculo laboral con empresas en la provincia de
de localización provincial para Santa FE 6
el cumplimiento del Renglón Vinculación con
III.2 empresas localizadas
SI/NO
en las ciudades de
implementación 10
Etapa 3:
l. Evolución Económica (Puntaje máximo 100 puntos)
161
5
1º Lugar 0
4
Valoración comparativa de 2º Lugar 0
Análisis de costo por renglón
la oferta económica (*)
3
3º Lugar 0
4º Lugar 0

cumplimiento Cumple Si/No 0
2
1º Lugar 0
1
complementarias
1
3º Lugar 0
4º Lugar 0
m. Ponderación
Ponderación de la Etapa sobre

Etapas de Evaluación el total de la puntuación
Economico 20%
Renglón IV:
Etapa 1:

162
2. Presencia en el Mercado. Experiencia en implementaciones
similares en construcción de soluciones de BI.
3. Certificaciones de calidad: normativas de calidad -y otras-,


Hasta 5
referencias
12
referencias
Hasta 5 3
Experiencia en
implementaciones De 5 hasta 10 6
Presencia en el Mercado
similares en construcción 14
de soluciones de BI Más de 10
Normativas de Calidad SI/NO 9

Certificaciones
Otras SI/NO 5

puntos)



163
implementación.

SI/NO 6
Metodología de
Gestión del Cambio
conceptual y el
SI/NO 4
acompañamiento
en salud
SI/NO 9
establecimientos.
Cronograma de
implantación
Experiencia en
implementaciones Certificaciones Varias SI/NO 6
certificadas.
Etapa 2:


164
informático
Equipos de Trabajo Puntaje Màximo 48 puntos
Hasta 5 años 2
los Especialistas en área clínica Más de 5
6
años
Hasta 5 años 2
Promedio de años de experiencia de los Especialistas en
implementaciones de soluciones informáticas Más de 5
6
años
Hasta 5 años 2
los Especialistas procesos productivos sanitarios Más de 5
6
años
Promedio de años de experiencia en implementaciones de Hasta 5 años 2

los Especialistas en instalación y mantención de Más de 5
equipamiento informático 6
años
Hasta 5 años 2
Promedio de años de experiencia en implementaciones en
base de datos para inteligencia de negocios Más de 5
6
años
Hasta 5 años 2
Promedio de años de experiencia en implementaciones en
base de datos para inteligencia de negocios Más de 5
6
años
Hasta 5 años 2
Promedio de años de experiencia en análisis y
especificaciones de requerimientos Más de 5
6
años
Hasta 5 años 2
Promedio de años de experiencia en profesionales
especializados en herramientas de BI Más de 5
6
años
d. Evolución y Soporte del Sistema (Puntaje máximo 8

puntos)
165
Referencias de clientes Informe con referencias ≤ 3
relacionadas con calidad de de clientes referencias 0
servicio ≥ 3
referencias y
≤ 5
1
referencias
Entre 6 y 7
2
referencias
≥ 8
referencias 3
Conformación y disponibilidad Equipo de Desarrollo SI/NO
2
de Equipos de Desarrollo formado en Argentina
Capacidad de operar con otros Informe de SI/NO
proveedores y sus desarrollos experiencias exitosas
de trabajos con otros
proveedores de
3
sistemas
e. Arquitectura y funcionalidades del sw de BI, y características de los servicios

solicitados (Puntaje Máximo 44 Puntos)
Arquitectura y funcionalidades del sw de BI y características de los servicios

solicitados Puntaje Máximo 44 Puntos
Arquitectura y funcionalidades Arquitectura lógica y física de 10
del software de BI la solución.
Descripción funcional de la
herramienta.
Valor agregado de Funcionalidades y/o 5
funcionalidades y/o herramientas complementarias
herramientas complementarias que agreguen valor a la
solución
Integración de fuentes de Nivel de adecuación de la 9
información y soluciones herramienta a las
integraciones requeridas.
localización de la empresa Extranjera SI/N 0
para la prestación de los O
servicios del Renglón IV Nacional SI/N 10
O
Provincial SI/N 20
O
Etapa 3:
166
f. Evolución Económica (Puntaje máximo 100 puntos)

1º Lugar 50
Valoración 2º Lugar 40
Análisis de costo por
comparativa de la
renglón 3º Lugar 30
oferta económica (*)
4º Lugar 0
Aceptación del cronograma
de cumplimiento Cumple Si/No 30
1º Lugar 20

complementarias 3º Lugar 10
4º Lugar 0
g. Ponderación
Ponderación de la Etapa sobre el

Etapas de Evaluación total de la puntuación
Antecendentes , Equipo e
Implementación 40%
Económico 20%
3. Pruebas de Funcionalidad.
Las ofertas que cumplan con los requerimientos excluyentes, serán llamadas a
presentar su aplicación en una demostración con la versión de software
ofertada, en todas las soluciones de producto.
4. Tabla Resumen Evaluación Funcionalidad
Se presenta el cuadro con ponderaciones individuales para las Pruebas de

Funcionalidad. Al momento de notificar a los oferentes que harán la
demostración, se les entregará un documento explicativo con la funcionalidad,
cronograma y modalidad de presentación. Cada presentación se llevará a cabo
en instalaciones provistas por el oferente respectivo (podrán ser propias,
arrendadas etc.) comenzará en horario previamente acordado entre las partes
y se concretará sucesivamente cada dos días (día 1, día 3, día 5, día 7, etc.).
167
Evaluación Final. La evaluación final se obtendrá ponderando los tres
informes de evaluación, descritos en los puntos precedentes, como se señala a
continuación:
• Evaluación Etapa 1: 40%

La Comisión Evaluadora elaborará el "Informe Final de Evaluación" el cual

contendrá:
1. Un cuadro comparativo de las propuestas seleccionadas con las

respectivas evaluaciones parciales obtenidas en cada uno de los criterios
de evaluación, así como también la nota final.
2. Un análisis final de evaluación y de observaciones.
3. Una proposición fundada de adjudicación de la licitación o la

recomendación fundada, de declarar desierto el proceso o desestimadas
las propuestas, según sea el caso. En caso que la documentación
recibida en la oferta del proponente, no contenga la información
necesaria para el ítem que se está evaluando, se calificará con 0% (cero
por ciento) al mismo.
De existir dos o más ofertas calificadas con igual puntaje primará la más
económica, como mecanismo para resolver los eventuales empates que se
produzcan.
9 Anexo IV: Cronograma

Cronograma Renglón I:
Solución HCEC, PSC, servicios de implementación de las soluciones

licitadas y de consultoría para la adaptación de los HIS provinciales.
Cronograma Detallado:
168
https://docs.google.com/spreadsheets/d/1wAwnZxQbmYoK-
ugNjj8yx_MBa88tWmiHYbmPHiFSvWQ/edit#gid=1812757199
Cronograma Renglón II:
Producto de Software para el ámbito hospitalario y servicios de

consultoría para su implementación
Implementación en Venado Tuerto:
Implementación en Hospital de Ceres:
169
Implementación en Hospital Provincial de Rosario:
Implementación en Hospital Dr. José María Cullen:
170
Cronograma Renglón III:
Producto de software para administrar el sistema de agendas y

turnos de la red de salud
Cronograma Renglón IV:
Producto de Software y servicios profesionales para la

implementación y soporte de la soluciòn de BI
171
172

Sistemas de Información Hospitalaria

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sistemas de Información Hospitalaria

Transféré par

Droits d'auteur :

Formats disponibles

Pliego de condiciones particulares y

técnicas para la contratación de una

- Un Sistema de Información Hospitalario (HIS), el cual deberá

- Por otra parte, se requiere dotar a toda la red de atención sanitaria de la

- Una herramienta para la gestión de agendas y turnos para los servicios

- Una solución de Business Intelligence (Inteligencia de Negocios) que integre

Paralelamente se incluye como objeto, la contratación de servicios de soporte y

TecnoFE responde a un ejercicio de planificación, un ejercicio en el cual el

Estrategia para el Eje de Salud Pública

Programas que conforman el Plan de Salud Pública de TecnoFE

Alcance de esta gestión con respecto a TecnoFE

· PRG.SL.01. Estrategia en Salud

Los programas y proyectos alcanzados por la solución que se licita en

- El Programa “Estrategia en Salud”contempla proyectos e iniciativas

En ese sentido la implementación de una herramienta de “Inteligencia de

· PRG.SL.01. Estrategia en Salud

- El Programa de “Historia Clínica Compartida” contiene aquellos proyectos e

· SL.02 Selección e implantación de la solución de la Historia

En efecto todos y cada uno de los productos y servicios licitados en este

· PRG.SL.03. GESTIÓN DE HOSPITALES

Y en particular se encuentran alcanzados por este pliego los siguientes

· SL.04 Selección y provisión del nuevo ERP

Como se define en el plan estratégico provincial de tecnología, el proceso de

1. Producto de software ● Licencias ilimitadas y de uso

IV 1. Producto de Software de Ministerio de Salud, y toda la red

I.4 - Servicios de consultoría para adaptar los HIS de la provincia

Los mencionados servicios deberán contemplar las siguientes tareas:

Durante el período previsto para la cotización, el Ministerio de Salud publicará

II.1 - Solución informática para el ámbito hospitalario: Esta solución

II.2 - Servicios de implementación, soporte y mantenimiento inicial

● Hospital Venado Tuerto: El hospital de Venado Tuerto, es un hospital

● El nuevo hospital base referencial de Ceres , se encuentra en la

En etapas posteriores, se proyectan nuevas implementaciones según el

● Hospital Provincial de Rosario, se encuentra en la ciudad de Rosario,

● Hospital “José María Cullen”, se encuentra en la ciudad de Santa Fe,

Posteriormente, se proyectan nuevas implementaciones según el siguiente

● El nuevo hospital “J. B. Iturraspe”, se encuentra en la ciudad de

Paralelamente a los servicios de implementación, se requiere el soporte y

III.1 - Producto de software y servicio de implementación, soporte y

Todo HIS deberá responsabilizarse por implementar en su sistema los flujos y

Los servicios de consultoría mencionados, deberán contemplar las siguientes

Durante el período previsto para la cotización, el Ministerio de Salud publicará

IV.1 - Producto de Software de Inteligencia de Negocios (Business

IV.2 - Implementación, soporte y mantenimiento inicial para la

Paralelamente a los servicios de implementación, se requiere el soporte y

En el siguiente gráfico, se esquematiza el requerimiento objeto del presente

4.1.1 Descripción resumida de los componentes y sus

En esta solución se deben contemplar tres componentes necesarios para la

Esta solución está basada en una plataforma de interoperabilidad y consta al

La solución se debe implementar sobre un modelo de servicios que estarán

Canal de Interoperabilidad Clínica: Tal como se visualiza en el gráfico 1 del

Del mismo modo, deberá permitir el acceso al Registro compartido de la HCEC,

Estas estrategias de acceso e integración se extenderá en etapas posteriores a

Respetando el marco técnico propuesto, estos canales deberán aportar las

● Envío de documentos al repositorio

● Registro del metadato de los documentos en el repositorio

● Despliegue de los documentos

● Actualización del identificador o índice único de pacientes

Asimismo, podrá gestionar y/o cancelar los turnos programados de las

Del mismo modo, permitirá al ciudadano acceder a contenido educacional o

I.3 - Servicios de implementación, soporte y mantenimiento inicial de

Estos servicios deberán estar a cargo de proveedores nominalizados para la

I.4 - Servicios de consultoría para adaptar los sistemas provinciales

Los servicios de consultoría mencionados, deberán contemplar las siguientes