Un HIS se puede construir de tres maneras: con una suite que lo cubre casi todo, combinando los mejores productos de cada área o apoyándose en desarrollos del propio sistema público. En la práctica casi todos los centros mezclan las tres. Esta lección explica los modelos sin evaluar productos ni empresas, y cómo se compran en el sector público, donde los pliegos y los anuncios son públicos.

Quién fabrica los sistemas: tres modelos

El mercado de sistemas de información sanitaria se describe mejor por modelos que por nombres. Esta lección no cita productos ni empresas, ni los compara: las cuotas de mercado y la valoración de cada producto exigirían fuentes públicas fiables que aquí no se han verificado [PENDIENTE: estudio oficial o independiente del mercado de HIS en España, con año].

Las columnas de ventajas y costes recogen argumentos habituales del sector, no conclusiones de un estudio.

La mezcla es la norma. El pliego público de un hospital universitario madrileño describe un centro con sistemas corporativos de su consejería, aplicativos departamentales de distintos proveedores y desarrollos propios, entre ellos una estación clínica propia y un visor clínico de la consejería ¹.

Suites integradas

Una suite reúne en un mismo producto la gestión de pacientes, la estación clínica y buena parte de los departamentales. Su argumento principal es el dato único: el paciente, el episodio y la petición existen una sola vez, y no hay que sincronizarlos entre sistemas.

Su riesgo principal es la dependencia. Cuanto más del mapa cubre un producto, más caro es sustituirlo. Por eso en una suite importan tanto las funciones como la salida: si los datos se pueden exportar en formatos estándar, si las interfaces con terceros están documentadas y quién es dueño de las adaptaciones hechas para el centro.

Best-of-breed: lo mejor de cada casa

El modelo contrario elige un sistema especializado para cada área (laboratorio, imagen, farmacia, quirófano) y los une al núcleo. Es frecuente en servicios con procesos muy técnicos, como se vio en la lección de departamentales.

Su coste es la integración. Cada sistema tiene su propia copia del paciente, su catálogo y sus usuarios. Sin un buen índice de pacientes, un motor de integración y estándares de mensajería, el modelo se degrada en sistemas que no se hablan. Esos elementos se estudian en el módulo de interoperabilidad.

Desarrollos y plataformas del sistema público

El tercer modelo es característico de la sanidad pública española, donde varias administraciones han construido o gobiernan sistemas comunes. Algunos ejemplos públicos:

• Cataluña, primaria: la ECAP es la historia clínica informatizada de toda la red de atención primaria desde 2001, con adhesión obligatoria en primaria ⁶.
• Cataluña, hospitales: Argos assistencial figura en el catálogo del Departament de Salut como sistema de información hospitalaria común y modular para centros del SISCAT, desarrollado con orientación colaborativa y alineado con el plan director de sistemas de información del SISCAT ⁵.
• Andalucía: Diraya es el sistema que soporta la historia clínica electrónica del Servicio Andaluz de Salud e integra la información de salud de las personas atendidas en sus centros ⁷. Su receta electrónica se puso en marcha en 2003 ⁷.

Que una solución sea pública no significa que todo el software sea de fabricación propia: puede combinar desarrollo interno, productos de mercado y servicios contratados. Lo que la define es que la administración la gobierna. En Cataluña, además, el catálogo distingue soluciones de adhesión obligatoria y otras a demanda ⁹, así que una parte del mapa de cualquier centro del SISCAT viene ya decidida.

El ERP: la otra mitad del mapa

Un hospital también es una empresa. El ERP cubre la contabilidad, el presupuesto, las compras y el almacén, los activos y, a veces, los recursos humanos y la nómina. El pliego madrileño citado enumera por separado la gestión económica, la de suministros, la de recursos humanos y nómina, y la de turnos ¹.

En el sector público, el ERP tiene obligaciones propias. Las empresas que facturan a una administración están obligadas a la factura electrónica, que puede exceptuarse por reglamento hasta 5.000 euros (art. 4) ⁸, y cada administración dispone de un punto general de entrada de facturas electrónicas (art. 6) ⁸. El ERP de un hospital público tiene que recibirlas por ese circuito.

El HIS y el ERP se tocan en tres puntos: los consumos (lo que se gasta por paciente o por servicio), la facturación de la actividad y la contabilidad analítica. Decidir si el ERP y el HIS son del mismo proveedor es, en el fondo, la misma pregunta de suite frente a best-of-breed.

Cómo compra el sector público

Los centros públicos compran sus sistemas por contratación pública, y eso hace visible el mercado. Los anuncios de importe suficiente se publican en el Diario Oficial de la Unión Europea, con su clasificación por códigos CPV. Dos ejemplos de 2025, que se citan sin valorarlos:

El segundo caso ilustra una figura que aparece a menudo cuando ya hay un sistema implantado. La LCSP solo permite adjudicar sin publicidad previa en supuestos tasados; uno es que el contrato solo pueda encomendarse a un empresario determinado porque «no exista competencia por razones técnicas» o porque proceda proteger derechos exclusivos, incluidos los de propiedad intelectual (art. 168.a.2.º) ⁴. Es la cara contractual de la dependencia del proveedor: evolucionar un sistema propietario suele requerir a quien tiene sus derechos.

Los pliegos son públicos y son la mejor fuente para conocer el mercado sin depender de la publicidad de nadie: dicen qué módulos se piden, qué integraciones se exigen, cuánto se presupuesta y quién resulta adjudicatario.

Criterios para comparar sin nombres

• Encaje con las plataformas comunes: en Cataluña, publicación en la HC3, receta electrónica, IS3 e índice de pacientes, como condición y no como mejora.
• Modelo de datos: qué se guarda estructurado y qué como documento; qué terminologías usa.
• Apertura: estándares de integración, acceso a los datos, exportación completa al final del contrato.
• Propiedad y continuidad: quién es dueño de las adaptaciones, qué pasa si el producto deja de evolucionar.
• Cobertura por ámbito: agudos, sociosanitario, salud mental, primaria. Un mismo producto puede ser sólido en uno y débil en otro.
• Coste total: licencias, implantación, integración, migración, mantenimiento y personal propio durante toda la vida del sistema.

Caso práctico

Una fundación privada sin ánimo de lucro, con un hospital de agudos y un centro sociosanitario concertados, debe renovar su HIS. No está sujeta a los mismos procedimientos de contratación que un ente público, pero quiere comparar con rigor.

Su equipo empieza por los pliegos publicados por centros públicos parecidos: le sirven para saber qué módulos se piden, qué integraciones se exigen en Cataluña y qué presupuestos se manejan ². Después dibuja su mapa: la estación clínica de primaria no es suya, la receta y la HC3 son obligatorias, y su laboratorio lo presta otra entidad del territorio.

Con ese mapa, la decisión ya no es «qué marca», sino «qué modelo». Opta por una suite para agudos y sociosanitario y mantiene separado el laboratorio. Exige en el contrato la exportación completa de los datos en formatos estándar al terminar, para no repetir la dificultad que tuvo al salir del sistema anterior.

Qué implica para los sistemas

Decisión	Qué se gana	Qué se paga
Suite integrada	Dato único del paciente y del episodio	Dependencia; menor profundidad en algunos servicios
Best-of-breed	Mejor sistema por servicio	Interfaces, catálogos y usuarios por duplicado
Solución pública común	Homogeneidad y datos compartidos 5 6	Menos margen de decisión del centro 9
ERP del mismo proveedor que el HIS	Consumos y facturación sin interfaz	Más dependencia; obligaciones de facturación electrónica que debe cumplir igual 8
Evolución de un sistema ya implantado	Continuidad	Posible contratación sin concurrencia 3 4

El momento de evitar la dependencia es antes de firmar, no al final del contrato. Las cláusulas de datos, documentación de interfaces y propiedad de las adaptaciones valen más que cualquier funcionalidad añadida.