ISACA Journal
Volume 3, 2,018 

Translated Articles 

Seguridad en el cuidado de la salud—Tres paradojas y la necesidad de un cambio de paradigma 

Giuliano Pozza, CGEIT, e-CF Plus (CIO), ITIL v3 

¿El papel del director de información (CIO) sigue siendo relevante para la seguridad de TI en el cuidado de la salud? El mundo de la información y la administración de datos está cambiando más rápido que nadie podría haber predicho hace unos años, y la atención a la protección de datos confidenciales está creciendo, como lo demuestra claramente el nuevo Reglamento General de Protección de Datos de la Unión Europea (GDPR). El papel del CIO como custodio de la información y los datos, en el cuidado de la salud u otros contextos, cada vez se vuelve más paradójico de muchas maneras.1 Uno de los puntos críticos de los CIO del cuidado de la salud es, sin duda, la seguridad, aunque la seguridad de TI no es, de ninguna manera, un elemento descuidado en las agendas de los CIO. 2015 fue un año horrible para las violaciones de datos en el cuidado de la salud, con más registros de atención médica robados que en cualquier otro momento desde que los registros se empezaron a mantener en los Estados Unidos. Según un resumen de mitad del año 2016 sobre violaciones de datos,2 la tendencia es persistente: en junio del 2016, más de 11 millones de registros de pacientes estuvieron expuestos en los Estados Unidos y 2017 siguió la misma tendencia con respecto al número de infracciones informadas, aunque el número de registros expuestos fue menor que años anteriores.3 La figura 1 muestra el estado de las infracciones de datos mundiales de 2011 a 2017 como se explica en el Informe Anual de la Asociación Italiana de Ciberseguridad 2018 (Clusit).4 El informe recopila datos sobre infracciones conocidas en todo el mundo de fuentes públicas. Es impresionante observar el marcado aumento en las infracciones relacionadas con el cuidado de la salud de 2015 a 2016 (hasta un 103 por ciento), con un aumento adicional desde 2016 (73 eventos) hasta 2017 (80 eventos).

Un análisis de violaciones de datos muestra que se pueden clasificar de acuerdo con seis categorías principales:5

  • Hackeo de Cibercrimen—Este es un escenario común, no necesariamente involucrando habilidades cibernéticas de alto nivel. La forma más fácil de eludir la seguridad del hospital es atacar a los trabajadores por medio de phishing e inducirlos a hacer clic en enlaces maliciosos.
  • Pérdida o robo de dispositivos móviles y medios—Los datos confidenciales están en todas partes, a menudo fuera de la infraestructura asegurada por TI. Los dispositivos móviles están, por naturaleza, sujetos a robo y pérdida y, en muchos casos, la ausencia de encriptación en los dispositivos da como resultado una fuga de datos confidenciales no deseados.
  • Accidente interno—Un trabajador bien intencionado realiza una acción que da como resultado el acceso no autorizado a datos confidenciales.
  • Socio comerciale—Una organización externa que trabaja para un hospital experimenta una brecha de datos que involucra datos confidenciales de los clientes.
  • Fraude malicioso interno—Este es uno de los tipos más peligrosos de infracciones de datos. A menudo se dice que es difícil proteger a una organización de ataques externos y casi imposible desde adentro.
  • Husmeo interno—Un trabajador accede a los datos del paciente sin necesidad legítima de hacerlo.

Otras fuentes difieren ligeramente en cuanto a la clasificación y la redacción, pero todas coinciden en este tipo de infracciones de datos.

La probabilidad de una violación de datos se correlaciona con la explosión de datos. Un experto de la industria estima que el crecimiento general del volumen de los requisitos de almacenamiento de datos en el sector salud se duplican cada 18 meses (otra variación de la Ley de Moore).6 El crecimiento abarca todos los tipos de datos, desde los datos estructurados en la historia clínica electrónica (EMR) hasta los datos no estructurados y de imágenes.7 Sin embargo, las imágenes y los datos no estructurados, la peor condición desde el punto de vista de la seguridad, son el verdadero combustible de esta explosión de datos.

Yendo más allá de las violaciones de datos, existen sistemas de tecnología controlados por software en el cuidado de la salud (dispositivos médicos, sistemas de automatización, sistemas de control de supervisión de control y adquisición de datos [SCADA], sistemas robóticos) donde un problema de seguridad para el software de control podría convertirse directamente en un problema de seguridad para los pacientes. La reacción de las organizaciones del cuidado de la salud a tales amenazas generalmente es fortalecer las medidas de seguridad de las tecnologías de la información y la comunicación (TIC), que esencialmente refuerzan el poder del CIO sobre la seguridad de TI. Verdaderamente, con el contexto tan desafiante, la función del CIO es potencialmente crucial para la seguridad en el cuidado de la salud y para el cumplimiento con el GDPR. Sin embargo, tres paradojas pueden socavar incluso la estrategia de seguridad más sólida.

Paradoja 1: ¿Hay más cosas en Shadow IT que en IT oficial?

“Hay más cosas en el cielo y en la tierra, Horatio, de lo que sueñas en tu filosofía”.8 Parece que “hace mucho tiempo en una galaxia muy, muy lejana”9 cuando los sistemas de TI se limitaban a un número bien definido de aplicaciones administradas por el departamento de TI. Era un tiempo diferente y, al parecer, una galaxia diferente. Por supuesto, los departamentos que no son de TI (por ejemplo, marketing, producción, recursos humanos [HR]) a veces eludían las TI tradicionales y configuraban sistemas departamentales. Sin embargo, no era tan difícil, si era necesario y deseado, incluir tales sistemas (a menudo llamados shadow TI o soluciones TI no administradas por el departamento de TI) en TI oficial. Para muchas compañías, era una estrategia tácita permitir que los departamentos individuales “Experimentar” con aplicaciones locales y luego seleccionar las mejores soluciones para ser incluidas en la TI corporativa. En cierto modo, si existía un modelo de gobernanza adecuado, TI nunca perdió el control.

Luego vino la nube, con su poderoso y fascinante conjunto de servicios: Software como Servicio, Plataforma como Servicio e Infraestructura como Servicio. Representó una gran cantidad de oportunidades para que los usuarios y departamentos desarrollasen soluciones informáticas ocultas con posibilidades sin precedentes. El departamento de TI tradicional, como suele ocurrir durante una revolución decisiva, aplicó el mismo modelo de gobernanza que la era previa a la revolución, permitiendo a los usuarios experimentar con las nuevas tecnologías y tratando de capturar lo mejor de la TI corporativa. Muchos departamentos de TI probablemente aún sigan esta estrategia. Buscan en la nube las mejores soluciones, usan diferentes soluciones en la nube y asumen que saben lo que hacen sus usuarios y por qué.

Aquí hay un problema típico de “hipermetropía”, es decir, un tipo común de error de visión donde los objetos distantes se pueden ver más claramente que los objetos que están cerca. Un interesante informe de Cisco10 indica que los departamentos de TI estiman que sus empresas están utilizando un promedio de 51 servicios en la nube. El mismo informe evaluó que, en una empresa promedio, en realidad se están utilizando 730 servicios en la nube. Otro informe esclarecedor fue publicado recientemente por Logicalis.11 La compañía entrevistó a 420 CIO en Europa, América del Norte, América Latina y Asia Pacífico con resultados interesantes. Entre los panelistas, el 34 por ciento de los CIO afirmaron que pueden influir en menos del 50 por ciento del gasto de TI. En 2015, el 66 por ciento de los CIO todavía tenían la capacidad de influir en más del 50 por ciento del gasto de TI. Es interesante observar que esta cifra había disminuido en un 6 por ciento en comparación con los datos de 2014.12

Paradoja 2: En el cuidado de la salud, una cantidad grande y creciente de datos sensibles y los sistemas más peligrosos y potencialmente peligrosos para la vida son, desde la perspectiva de seguridad, están en una “tierra de nadie” (Llámalo Shadow IT o no).

Si la paradoja 1 se extiende en prácticamente todos los mercados, las cosas se vuelven más interesantes cuando el enfoque se traslada al cuidado de la salud. Además de las aplicaciones administradas de TI “oficiales”, hay una serie de sistemas de información y automatización críticos que normalmente pasan desapercibidos bajo el radar de los departamentos de TI, como los sistemas de automatización de diferentes tipos y los sistemas de datos de dispositivos médicos (MDDS). Estos abarcan una amplia perspectiva, teniendo en cuenta tanto la información como los sistemas de automatización, ya que, desde el punto de vista de la seguridad, ambos son cruciales. Los sistemas de automatización se distribuyen de manera desigual en los hospitales, mientras que los MDDS están presentes de forma significativa en todos los hospitales. La siguiente es una breve lista de sistemas tecnológicos, que generalmente son sistemas controlados por software y conectados a la red, que caen en una especie de “sin tierra “con respecto a la gobernanza y seguridad de TI. No es necesario decir, que este tipo de sistemas tienen una gran superficie de ataque y un riesgo potencialmente alto:

  • Sistemas de automatización de edificios (BAS)—Muchos hospitales modernos incluyen sistemas “por diseño” para monitorear y controlar la iluminación; calefacción, ventilación y aire acondicionamiento (HVAC); uso de energía; seguridad; fuego; y ascensores. En otros casos, una infraestructura BAS completa o parcial se instala sobre un hospital existente, incluidos los datos de videovigilancia. Dado que los hospitales son, en la mayoría de las ocasiones, compuestos de muchas ubicaciones conectadas, la infraestructura BAS con frecuencia controla un número considerable de edificios. Un ataque de seguridad contra un sistema de este tipo podría tener un impacto profundo no solo en la seguridad del hospital, sino también en la seguridad de las personas.
  • Sistemas robóticos—El uso de sistemas robóticos se está convirtiendo en una práctica estándar en algunas especialidades. Probablemente el más famoso es el Da Vinci Surgical Sistema por Intuitive Surgical. Un informe ofrece un buen punto de partida para comprender el concepto de la difusión de la robótica, por ejemplo, en urología.13 Ambos son dispositivos aprobados por la Administración de Drogas y Alimentos de los Estados Unidos (FDA), y ambos se pueden usar en una red para respaldar la “presencia remota” de un médico o cirujano.
  • Dispositivos médicos y MDDS—Según la FDA:
    Los dispositivos médicos van desde simples depresores de lengua y cuñas hasta marcapasos programables complejos con tecnología de microchip y dispositivos quirúrgicos láser. Además, los dispositivos médicos incluyen productos de diagnóstico in vitro, como equipos de laboratorio de uso general, reactivos y kits de prueba, que pueden incluir tecnología de anticuerpos monoclonales.14

Sin embargo, la categoría de dispositivos médicos también incluye productos electrónicos y equipos de diagnóstico altamente emisores de radiación. Los ejemplos incluyen productos de ultrasonido de diagnóstico, máquinas de rayos X y láseres médicos. Los dispositivos médicos se usan ampliamente dentro y fuera de los hospitales. Los dispositivos médicos históricamente fueron estaciones independientes sin módulo de supervisión. El subconjunto de dispositivos de imágenes médicas normalmente se conecta a través de un sistema de archivo de imágenes y comunicación (PACS) para compartir datos de imágenes, y los sistemas de laboratorio tienen una solución de automatización dedicada y gestión de datos llamada sistemas de información de laboratorio (LIS). PACS y LIS son objetos bien definidos sujetos a regulaciones específicas y generalmente (pero no siempre) administrados por el departamento de TI. Además de LIS y PACS, otros dispositivos médicos a menudo están equipados con MDDS, como se definió anteriormente, y esta es una zona gris con respecto a la seguridad de TI. Una violación de datos (o una pérdida de integridad de datos) en tales sistemas puede tener consecuencias importantes.

Están surgiendo situaciones interesantes en las que la automatización de edificios/cuartos, el MDDS y la robótica convergen en un complejo sistema SCADA. Por ejemplo, el Sistema de gestión de imágenes y modelos de terapia (TIMMS) es un sistema complejo para integrar y administrar dispositivos médicos heterogéneos, sistemas de información clínica y componentes de cirugía asistida por computadora en el quirófano.15

Este ejemplo evidencia la convergencia de TI con la automatización del quirófano y la administración de dispositivos médicos. La consecuencia de este tipo de evolución tecnológica y convergencia (que no es, por supuesto, una tendencia negativa en sí misma) es que la “tierra de nadie” se hace cada vez más amplia, a veces excede la tierra bajo el gobierno de TI o el Departamento de Ingeniería clínica. No es exactamente un Shadow TI, ya que estos sistemas son, de alguna manera, tecnologías oficiales, pero desde la perspectiva de seguridad, son sistemas que no están administrados en muchos hospitales, exactamente como lo es Shadow TI.

Yendo más allá, los dispositivos médicos administrados por la ingeniería clínica son también una amenaza potencial a la seguridad. Por ejemplo, algunos dispositivos de imágenes pueden no estar equipados con software antivirus, y generalmente el sistema operativo de la estación de trabajo conectada a un dispositivo médico no se parchea con regularidad (a veces no está incluido en el proceso de administración del parche). Además, traiga políticas de traer sus propios dispositivos (BYOD), aplicadas en muchos hospitales sin las prácticas adecuadas de control y limitación de riesgos, y los problemas con los dispositivos médicos implantables16 plantean amenazas nuevas y sin precedentes a la seguridad en los hospitales. La reciente acción de campo de la FDA en Abbot Laboratories, que requiere una actualización de firmware para abordar las vulnerabilidades de ciberseguridad en los marcapasos cardíacos implantables, es un ejemplo sorprendente del nivel de problemas de seguridad que existen actualmente en el cuidado de la salud.17

Una vez más, la tendencia es más contundente en el cuidado de la salud (donde un problema de seguridad en un sistema SCADA que controla un quirófano podría tener un efecto de consecuencias aterradoras), pero es análogo a lo que está sucediendo con los sistemas SCADA en otras industrias también. Un informe de 2012 de Accenture proporciona una descripción interesante del fenómeno.18

Paradoja 3: Los CIO están trabajando duro para fortificar las murallas de la ciudadela, pero no hay una ciudadela para defenderse.

El enfoque tradicional de la seguridad de TI se centra en fortalecer la seguridad de los sistemas de TI. Si esta afirmación parece puramente tautológica (y lo es), es importante considerar las implicaciones. Las paradojas anteriores demuestran que los sistemas tecnológicos (TI o automatización) fuera de las fronteras de los departamentos de TI están creciendo y a veces superando los sistemas de TI tradicionales. Por otra parte, en el cuidado de la salud, los sistemas más vulnerables (y a veces peligrosos) son probablemente los que están fuera del perímetro de TI. Utilizando una metáfora, los profesionales de TI están dedicando gran parte de su tiempo y esfuerzo a la seguridad, fortificando una parte de los muros alrededor de la ciudadela de los datos confidenciales de los pacientes administrados por sus hospitales. Sin embargo, la idea de fortificar solo una parte de una pared (por ejemplo, omitiendo el MDDS) es claramente ineficaz, como una casa donde la entrada principal está protegida por una puerta de seguridad impenetrable mientras todas las ventanas están abiertas. Además, explorando aún más la analogía, la idea de una ciudadela que protege los datos confidenciales está desactualizada. En un ecosistema donde los sistemas informáticos tradicionales coexisten con los datos administrados por el usuario (BYOD, shadow IT) y con un gran número de otros sistemas de administración de datos (nube, MDDS, SCADA), la protección de datos e infraestructuras críticas debe abordarse desde un diferente punto de vista. La metáfora apropiada es probablemente una ciudad abierta con varios sitios críticos, no una ciudadela amurallada.

Si todavía es cierto que la mayoría de las violaciones de datos reportadas son aún bastante tradicionales en su enfoque,19 es probable que, en un futuro cercano, los ataques cibernéticos se concentren en la parte más débil de la superficie de ataque, es decir, la “tierra de nadie” descrito en la paradoja anterior. Una representación ficticia de lo que podría parecer un ataque cibernético a través de dispositivos médicos está narrado en el libro The Fifth Domain.20

Un nuevo paradigma

Las paradojas discutidas respaldan la necesidad de un cambio completo en la perspectiva. La (r) evolución se puede articular en cuatro áreas:

  • Estrategia
  • Tecnología
  • Procesos
  • Pesonas

Estrategia
El primer giro en U consiste en redefinir la visión de la seguridad de TI, donde un punto clave es seleccionar la analogía correcta. Como se explicó anteriormente, el objetivo no puede ser la defensa de una ciudadela, sino más bien la protección de una ciudad abierta con una amplia superficie de ataque. Es necesario administrar a un nivel de seguridad diferente e incluso es posible planear asegurar o sellar partes de la ciudad (edificios o infraestructuras críticas) cuando está siendo atacado, pero amurallar la ciudad no es una opción hoy en día. Esto no está lejos del enfoque utilizado para proteger la infraestructura crítica. Un ejemplo interesante de este enfoque aplicado a la infraestructura del cuidado de la salud es el proyecto Ataques terroristas contra hospitales: riesgo y evaluación, herramientas y sistemas (AMENAZAS),21 parte del programa europeo de la Unión Europea para Protección de Infraestructura Crítica (EPCIP).

El segundo giro en U es pasar de un enfoque en silos (equivalente a fortificar una parte de un muro) a un enfoque integrado y holístico de la seguridad. Deben abordarse todas las tecnologías de información y automatización en el hospital, independientemente de quién sea responsable de qué. Una estrategia puramente centrada en las fronteras de los departamentos de TI no tiene sentido. La seguridad debe ir más allá de las fronteras obsoletas y abarcar TI tradicional, nube, ingeniería clínica, automatización de edificios y todas las subcategorías de shadow TI que manejan datos u operaciones relevantes y/o sensibles.

Tecnología
La tecnología puede ser un habilitador de un enfoque integrado y holístico de la seguridad. Esto se puede abordar en dos direcciones:

  1. En la evaluación y adquisición de tecnología, es importante garantizar que la seguridad sea uno de los requisitos básicos, incluidos por diseño en la tecnología bajo evaluación. Esto fue sencillo en el pasado, pero hoy en día es todo un desafío debido a la variedad de tecnologías involucradas (TI tradicional, servicios en la nube adquiridos por el usuario, dispositivos médicos, robótica y automatización). La tarea de evaluar nuevas tecnologías no puede ser llevada a cabo por un solo departamento sin coordinación con TI y otros departamentos técnicos. Un claro ejemplo de la importancia de un enfoque transfronterizo es la selección de una herramienta de seguridad de punto final. El software antivirus tradicional es una respuesta (parcial) para estaciones de trabajo de usuarios finales, pero en muchos casos, los fabricantes de estaciones de trabajo de equipos de diagnóstico no permitirán que el departamento de informática instale software antivirus. En la actualidad, la solución está a la vuelta de la esquina: TI debe seleccionar un software de protección de punto final basado en el principio de monitoreo de integridad. El software calculará un código hash de los archivos del sistema y alertará a los usuarios (o los departamentos de TI/ingeniería clínica) si los archivos del sistema cambian en comparación con una línea base certificada. Este enfoque es una técnica común utilizada en los sistemas SCADA, pero a menudo se pasa por alto en el cuidado de la salud porque, dado que el monitoreo de la integridad es difícil de aplicar para los clientes tradicionales, generalmente no está incluido en los requisitos que el departamento de TI considera esenciales para una solución antivirus.
  2. Al seleccionar las herramientas y los servicios (por ejemplo, centros de operaciones de seguridad [SOC]) para respaldar la seguridad, el departamento de TI debe incorporar una visión arquitectónica más que una mera evaluación de un único producto en un enfoque tradicional y mejor de su clase. El objetivo no es tener el mejor antivirus, el firewall más efectivo o el software de prevención de pérdida de datos (DLP) más ajustado, sino construir la arquitectura de seguridad mejor integrada y habilitada para multidominio (por ejemplo, TI, ingeniería clínica y automatización).

Procesos
Los procesos y las metodologías también deben actualizarse. En la actualidad, el departamento de TI tiene un conjunto de metodologías centrales para la gobernanza y la seguridad (por ejemplo, IT Infrastructure Library [ITIL], COBIT 5, Organización Internacional de Normalización [ISO]/International Electrotechnical Commission [IEC] ISO/IEC 27001), mientras la ingeniería clínica está funcionando en un conjunto diferente de metodologías (por ejemplo, una evaluación de tecnología de salud [HTA]). Esto estaba bien hace unos años, cuando el equipo de diagnóstico era puramente máquinas. Ahora, los dispositivos de captura de datos (como dispositivos médicos con MDDS) y las tecnologías de automatización están mayoritariamente definidos por software y controlados por software: se necesita un nuevo conjunto de metodología y nuevos procesos para guiar la forma en que se evalúan, implementan y ejecutan las nuevas tecnologías.

Personas
Las personas y las estructuras organizacionales se encuentran entre los temas cruciales en todo esfuerzo humano. Como se ha descrito en este artículo, muchas organizaciones del cuidado de la salud no tienen en cuenta la convergencia tecnológica subyacente. Los tres departamentos de tecnología típicos en un hospital (es decir, instalaciones, ingeniería clínica y TI) nacieron cuando los edificios eran muros y ladrillos, los dispositivos médicos eran máquinas tontas y TI manejaba un conjunto bien definido de aplicaciones y datos. Ahora, los edificios son ecosistemas de Internet de las cosas (IoT) que generan flujos de datos críticos y continuos, los sistemas robóticos controlados por software (que van desde la administración logística hasta la cirugía) son tanto generadores de datos como componentes de infraestructura crítica, y TI está dispersa en cientos de servicios internos y externos. Muchas organizaciones están reaccionando con el establecimiento de un departamento de tecnología unificada. Esta no es una nueva tendencia: un artículo del 2006 propuso la convergencia entre TI y la ingeniería clínica.22 Si no es posible la convergencia entre TI y la ingeniería clínica, se debe designar al menos un oficial de seguridad de la información (CISO), reportando directamente al director ejecutivo (CEO), no al CIO.

Además, una sección transversal de diferentes habilidades y competencias debería ser el objetivo de cada organización tecnológica que tenga como objetivo construir una cultura común y conciencia sobre los temas de seguridad. El Informe del Instituto de Investigación de Atención de Emergencia 2018 destacó el ciberataque como el principal peligro para los dispositivos médicos.23 Por lo tanto, los profesionales de TI deben conocer las características específicas de los dispositivos médicos, y los ingenieros clínicos deben estar capacitados en lo esencial de la seguridad de TI.

Los marcos metodológicos (esta vez, para la gestión de personas) deberían evolucionar. Por ejemplo, la Comunidad Europea está estandarizando los perfiles profesionales de TI en torno al llamado Marco de e-Competencia.24 El marco es un hito en el desarrollo de competencias digitales, pero un enfoque profesional cruzado que conecta las TIC y la ingeniería clínica (o las TIC y la automatización de plantas, para contextos más generales) aún no está incluido en la última versión del marco.

Juntando las piezas

Dejando a un lado por un momento los grandes problemas con la metodología y los marcos, existe un camino tangible para que los hospitales y las organizaciones de TI del cuidado de la salud deseen abordar la seguridad y la gobernanza de una manera alineada con la convergencia tecnológica que se produce y con el principio de rendición de cuentas del GDPR.

Inspirándose en el Modelo de madurez de capacidades,25 es posible proponer un camino en cinco etapas (figura 2).

Las etapas se pueden definir de la siguiente manera:

  • Etapa 1 (Inicial)—Existe administración de seguridad “local”, no estructurada.
  • Etapa 2 (Administrada)—Se ha implementado la administración de seguridad estructurada para las TIC. Existe una conciencia general sobre la seguridad en otras áreas técnicas (utilizando el departamento de TIC como experto interno de turno).
  • Etapa 3 (Definido)—Existen esfuerzos de coordinación y políticas en materia de seguridad entre diferentes áreas tecnológicas (por ejemplo, TIC, instalaciones, ingeniería clínica), pero no existe una organización transfronteriza dedicada a la seguridad.
  • Etapa 4 (Administrado cuantitativamente)—Un rol transfronterizo en seguridad (por ejemplo, el CISO que informa al CEO) supervisa la estrategia y las políticas de seguridad con un enfoque de 360 grados. A nivel departamental, la seguridad está bien administrada, con indicadores clave de rendimiento (KPI) y procesos de monitoreo.
  • Etapa 5 (Optimización)—Esta es una estrategia y organización de seguridad convergente. Los departamentos de tecnología en el hospital están bajo una responsabilidad unificada. La seguridad y la gobernanza se gestionan con un enfoque holístico.

Es probable que cualquier hospital, con el tiempo y los recursos adecuados, pueda alcanzar la etapa Definida; ir más lejos es más complicado. Alcanzar el nivel 4 es más difícil (“hic sunt leones”),26 ya que requiere un fuerte compromiso y un enfoque interdepartamental.

Si la etapa 5 parece demasiado audaz, vale la pena considerar esta idea al analizar un contexto más amplio durante un taller de Cisco:

IoT se compone de una Internet de Comunicaciones, una Internet de Energía y una Internet de Logística que trabajan juntas en un solo sistema operativo, encontrando continuamente formas de aumentar la eficiencia termodinámica y la productividad en la recopilación de recursos, la producción y distribución de bienes y servicios, y el reciclaje de desechos. [..] Juntos, estos tres sistemas operativos comprenden la fisiología del nuevo organismo económico. Las tres Internets interoperables del IoT requieren una transformación en las funciones de cada empresa. [..] Expresé mis dudas sobre la viabilidad de los jefes de información (CIO) en una economía de IoT en evolución y sugerí que en el futuro, la TI, los servicios de energía y la logística se integrarían en una única función bajo la supervisión de un jefe de productividad (CPO ). El CPO combinaría experiencia en TI, experiencia en energía y experiencia en logística con el objetivo de utilizar el IoT para optimizar las eficiencias termodinámicas y la productividad de las operaciones de la compañía.27

Este nuevo enfoque holístico para la seguridad, la gobernanza y la organización es el verdadero cambio de juego. La convergencia cultural de diferentes profesiones, más que una pura convergencia organizativa o técnica, es lo que permitirá a los CIO de salud (y tal vez a otros CIO) sobrevivir a lo que se puede definir como una tormenta perfecta o, desde un punto de vista más optimista. una oportunidad perfecta.

Notas finales

1 Heller, M.; The C.I.O. Paradox: Battling the Contradictions of IT Leadership, Routledge, USA, 2012
2 HIPAA Journal, “Major 2016 Healthcare Data Breaches: Mid Year Summary,” HIPAA Journal, 11 July 2016, https://www.hipaajournal.com/major-2016-healthcare-data-breaches-mid-year-summary-3499/
3 HIPAA Journal, Healthcare Data Breach Statistics, https://www.hipaajournal.com/healthcare-data-breach-statistics/
4 Clusit, Rapporto Clusit 2018 sulla sicurezza ICT in Italia, CLUSIT, Italy, 2018
5 Houlding, D.; “6 Most Common Types of Healthcare Data Security Breaches,” IT Peer Network, 18 February 2016, https://itpeernetwork.intel.com/6-most-common-types-of-healthcare-data-security-breaches/
6 A generally accepted computing rule stating that computer processing speed doubles every two years. Moore’s Law, www.mooreslaw.org/
7 DeGaspari, J.; “Managing the Data Explosion,” Healthcare Informatics, 1 October 2013, www.healthcare-informatics.com/article/managing-data-explosion
8 Shakespeare, W.; Hamlet, 1603
9 As seen in the opening sequence of every numbered film of the Star Wars series
10 Earle, N.; “Do You Know the Way to Ballylickey? Shadow IT and the CIO Dilemma,” Cisco Blogs, 6 August 2015, https://blogs.cisco.com/cloud/shadow-it-and-the-cio-dilemma
11 Rogers, M.; “The Shadow IT Phenomenon,” Logicalis, https://www.us.logicalis.com/globalassets/united-states/whitepapers/cio-survey-2015-shadow-it-phenomenon.pdf
12 Ibid.
13 Babbar, P.; A. Hemal; “Robot-Assisted Urologic Surgery in 2010—Advancements and Future Outlook,” Urology Annals, 2011, vol. 3, no. 1, www.urologyannals.com/article.asp?issn=0974-7796;year=2011;volume=3;issue=1;spage=1;epage=7;aulast=Babbar
14 US Food and Drug Administration, “Is the Product a Medical Device?” USA, www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Overview/ClassifyYourDevice/ucm051512.htm
15 Lemke, H.; M. Vannier; “The Operating Room and the Need for an IT Infrastructure and Standards,” International Journal of Computer Assisted Radiology and Surgery, November 2006, vol. 1, no. 3, p. 117-121
16 Pozza, G.; “Beyond BYOD: Can I Connect My Body to Your Network?” ISACA Journal, vol. 5, 2014, https://www.isaca.org/Journal/archives/
17 US Food and Drug Administration, “Firmware Update to Address Cybersecurity Vulnerabilities Identified in Abbott’s (Formerly St. Jude Medical’s) Implantable Cardiac Pacemakers: FDA Safety Communication,” USA, 29 August 2017, https://www.fda.gov/MedicalDevices/Safety/AlertsandNotices/ucm573669.htm
18 Sholten, B.; C. S. Filho; E. Smits; “Who Owns Information Systems in the Plant?” Accenture, 2012, https://www.accenture.com/t20150624T211125__w__/in-en/_acnmedia/Accenture/Conversion-Assets/DotCom/Documents/Global/PDF/Industries_10/Accenture-MES-Who-Owns-Information-Systems-Plant.pdf
19 Department of Health and Human Safety, Office of Civil Rights, “Cases Currently Under Investigation,” USA, https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf
20 Pozza, G.; J. D. Halamka; The Fifth Domain: Wake Up, Neo, CreateSpace Independent Publishing Platform, 19 January 2014
21 THREATS, www.threatsproject.eu/index.html
22 Grimes, S. L.; “Convergence of Clinical Engineering and Information Technology,” 24 August 2006, http://accenet.org/publications/Downloads/Presentations/chime.pdf
23 ECRI Institute, Top 10 Health Technology Hazards, ECRI, 2018
24 European e-Competence Framework, “ICT Profiles,” www.ecompetences.eu/ict-professional-profiles/
25 CMMI Institute, http://cmmiinstitute.com/
26 “Here are the lions,” meaning to say that this is the crucial point.
27 Rifkin, J.; The Zero Marginal Cost Society: The Internet of Things, the Collaborative Commons, and the Eclipse of Capitalism, St. Martin’s Griffin, USA, 2015

Giuliano Pozza, CGEIT, e-CF Plus (CIO), ITIL v3
Es un ingeniero biomédico de formación y el director de información (CIO) de Ospedale San Raffaele, la clínica privada e institución de investigación más importante de Italia. También es el presidente de la Asociación Italiana de Profesionales de Sistema de Información de la Salud. Anteriormente, fue CIO de la Fondazione Don Carlo Gnocchi Onlus, una organización italiana de atención social y rehabilitación en todo el estado. También trabajó para el Istituto Clínico Humanitas y en la práctica del cuidado de la salud de la consultora Accenture.

 

Add Comments

Recent Comments

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and from opinions endorsed by authors’ employers or the editors of the Journal. The ISACA Journal does not attest to the originality of authors’ content.