Esa es una pregunta difícil de responder de forma general. Las TI en la sanidad son increíblemente diversas. Hay muchos entornos de trabajo diferentes, algunos casi completamente desarticulados – pagadores (compañías de seguros, etc.), organizaciones de atención gestionada como Kaiser, centros de compensación de reclamaciones, consultorios médicos, hospitales comunitarios, centros médicos académicos, Big Pharma, ingeniería biomédica, etc., así como cientos (¿miles?) de proveedores de aplicaciones especializadas para la atención sanitaria, por ejemplo, historias clínicas electrónicas, sistemas de facturación, sistemas de registro, sistemas de laboratorio, sistemas de información radiológica, sistemas de imagen digital, sistemas de farmacia, motores de integración, almacenamiento de datos, llamada a enfermería, sistemas de alerta y monitorización, dispositivos integrados como marcapasos o bombas de insulina, etc.
Así que… Algunas de estas áreas son bastante innovadoras y están haciendo ingeniería de software y desarrollo de aplicaciones de última generación, otras son bastante regresivas. Sólo puedo hablar del entorno de la informática hospitalaria y del laboratorio clínico por experiencia directa.
En general, la TI en los hospitales lleva muchos años de retraso con respecto al estado de la técnica. Las aplicaciones basadas en mainframe de pantalla verde todavía se utilizan activamente en toda la industria, y los sistemas de registro médico electrónico (EMR) dominantes para los hospitales son, en el mejor de los casos, aplicaciones cliente-servidor que se despliegan (normalmente) en Citrix con un enorme gasto. La interoperabilidad entre sistemas es marginal, por decirlo amablemente.
La mayoría de las organizaciones de TI de los hospitales ya no hacen mucho o ningún desarrollo de software internamente, ya que en los últimos años han pasado a utilizar sistemas monolíticos como Cerner y Epic, que intentan abordar todos los nichos y procesos tanto en el entorno de los pacientes internos como en el de los externos. En 2004, Kaiser canceló 400 millones de dólares (según sus propias cuentas) tras un intento fallido de desarrollar su propio EMR, y en su lugar compró Epic, implementándolo en toda su organización a un coste de (de nuevo, según sus propias cuentas, 4.000 millones de dólares). Así que hay muy poco que se pueda reconocer como «ingeniería de software» en los hospitales, excepto en algunos centros importantes con un enfoque académico o de investigación. Por otro lado, si usted acaba de aterrizar en 2014 a través de un viaje en el tiempo desde mediados de 1980, se sentiría completamente en casa.
Sólo para hacer esto más concreto – Epic, el actual favorito de los EMRs para las grandes organizaciones, no sólo tiene un cliente grueso escrito en Visual Basic, pero el back-end es Cache (una tecnología de base de datos pre-relacional de los años 60 que es esencialmente una versión comercializada de MUMPS). A los médicos les gusta el sistema, y de ahí su éxito, pero tiene una fontanería compleja y frágil, y es un sistema caro y que requiere mucha mano de obra para su implantación y funcionamiento. Cerner, el otro EMR dominante para pacientes internos, al menos utiliza un RDBMS moderno y creíble en el back-end, pero por lo demás tiene casi los mismos problemas.
Hay algunas cosas interesantes que están sucediendo en los sistemas de bajo mantenimiento basados en la nube para entornos ambulatorios, Practice Fusion y eClinicalWorks son dos de los que me han impresionado, pero hay muchos otros.