Одним из важнейших показателей любой ИТ-системы является ее производительность. В целом специалисты признают, что решение, размещенное в «облаке», будет с этой точки зрения менее производительным, чем его аналог, размещенный на собственных серверах. В настоящее время внутренние ЛВС организаций, как правило, обладают пропускной способность 100 Мбит/сек. от компьютера пользователя до сервера, а отдельные сегменты сетей соединяются по оптоволоконным каналам связи 1 Гбит/сек. Сеть в классической модели создается, как правило, с существенным запасом по производительности, а ее стоимость составляет не самую основную часть от всех затрат на проект. При этом трафик, который передается по внутренней ЛВС, четко регулируется самим заказчиком.

В случае «облачной» модели достигнуть таких же характеристик существенно сложнее, поэтому пропускная способность может стать ниже, особенно в случае применения открытых каналов связи. Более того, при эксплуатации «облака» через публичные каналы связи возрастают риски нарушения безопасности и управляемости решения, т.к. кроме трафика, генерируемого самой МИС, по этим каналам передается и весь другой трафик, отключить который в условиях Интернет не представляется возможным.

В связи с этим для здравоохранения очень важно грамотно разработать проект создания защищенной корпоративной интранет-сети, способной удовлетворить всем требованиям по производительности, масштабируемости и безопасности. Необходимо помнить, что облачные технологии позволяют очень эффективно и фактически без существенных затрат масштабировать производительность при росте нагрузки, добавляя решению дополнительные вычислительные ресурсы. Но при этом общая производительность всей системы подчиняется правилу «узкого горла» - МИС будет работать с такой скоростью, которая обеспечивается самым слабым звеном всей системы. В случае «облаков» плохо выполненные каналы связи могут стать тем самым слабым звеном, дискредитирующим все их преимущества.

Доступность  и безопасность

Гарантированная стабильность и доступность медицинских данных – обязательное требование к МИС. Если информационная система отключится даже на несколько часов, врач не сможет получить медицинские данные о пациенте, медсестра – список лечебных назначений, аптека потеряет контроль над движением лекарственных средств и т.д. В случае классической модели выход из строя серверного узла или какого-то отдельного сегмента ЛВС – это локальная проблема данного ЛПУ. В случае «облачной» модели – это риски остановки работы всех ЛПУ региона, подключенных к «облачной» МИС. Все это очень похоже на принцип «сложить яйца в одну корзину».

Эту опасность также следует учитывать в проектах, и для ее устранения есть вполне доступные решения. Это, во-первых, резервирование каналов связи. Во-вторых, это применение соответствующих программных систем для мониторинга и выявления проблем в работе инфраструктуры, включая системы мониторинга сети, серверного оборудования, резервного копирования и восстановления и т.д. Наконец, важнейшим выходом из ситуации является применение соответствующего аппаратного обеспечения, специально спроектированного для обслуживания «облачного» решения и поддерживающего избыточность компонентов, виртуализацию, перераспределение ресурсов в режиме реального времени и по «запросу» и т.д.

Краеугольным камнем здравоохранения является вопрос безопасности и сохранности персональных данных. Безопасность – «ахиллесова пята» «облачных» решений. Полноценная защита данных и полное соответствие требованиям ФЗ 152 даже в классической модели – задача не из легких и недешевых. Размещение базы данных МИС и со всей персональной информацией о пациентах в «облаке» – шаг достаточно рискованный, требующий всестороннего анализа таких рисков и создания надежной системы защиты.

Вся сложность тут кроется в том, что меры защиты информации должны быть одинаковыми для любой схемы реализации проектов – классической или «облачной». Эти меры предусматривают защиту периметра, шифрование данных при их хранении и передаче информации по каналам связи, защиту рабочих мест пользователей и оборудования ЦОДа и т.д. В случае «облака» эта защита должна учитывать уже не только инфраструктуру самого ЛПУ, но и затрагивать все каналы связи, которые могут распространяться (в случае регионального внедрения) на сотни километров. Риски перехвата информации по таким каналам, а значит несанкционированного доступа и дискредитации системы безопасности, существенны.

Это означает, что «облачные» проекты автоматизации ЛПУ также многократно должны быть обеспечены ответными превентивными мерами по защите от угроз. Во-первых, крайне важно не допустить, чтобы  поставщик решений халатно относился к этой  проблеме либо предлагал переложить решение задачи «на потом». Во-вторых, для реализации проекта еще на этапе его проработки нужно подключать профессиональных специалистов по безопасности, с помощью которых прорабатывать и предусматривать соответствующие программно-аппаратные средства защиты, включая надежное шифрование, ограничения доступа к серверному оборудованию, надежное протоколирование работы, регламентированный доступ на основе групповых политик и т.д.

Еще одна опасность состоит в том, что в случае «облака» доступ к персональным медицинским данным пациентов могут получить лица, не имеющие на то никаких прав и оснований – операторы ЦОДа, разработчики или обсуживающий персонал «облачного» решения или даже некие «надзорные» государственные органы, которые могут вынудить провайдера услуги предоставить им такой доступ. В связи с этим, кроме технических мер защиты, должны быть обязательно предусмотрены и организационные меры, такие как контроль сотрудников, имеющих доступ к «облачной» инфраструктуре, выбор заслуживающего доверие поставщика и т.д. Возможным решением была бы передача всего ЦОДа в управление государственным служащим со стороны заказчика, но и тут есть свои большие «минусы».

Основные препятствия для проникновения «облачных» технологий в здравоохранение

Источник: «Врач и информационные технологии», 2011

В случае реализации доступа к «облаку» через открытый канал связи (т.е. интернет) всегда есть риск, что злоумышленник, обладающий логином и паролем (подобравший его, укравший или насильственно отнявший у легального пользователя), может не просто получить свободный доступ к информации, но и производить в ней самые различные модификации: изменять медицинские данные, вносить заведомо ложную информацию и т.д. Согласно общепринятому мнению, интерфейс работы «облачной» информационной системой реализуется через браузер. Все это вместе взятое означает, что потенциальному злоумышленнику не нужно обладать специальным ПО и физически располагаться в здании ЛПУ – достаточно простого обычного компьютера и какого-нибудь интернет-кафе, чтобы нанести непоправимый ущерб системе и здоровью пациента. Решением этого рода проблем является отказ от использования открытых каналов связи в пользу создания выделенной защищенной интранет-сети (где обеспечить меры защиты существенно проще и дешевле). Вторым важным шагом является идея выбора тех программных систем, которые работают через специализированное ПО (например, «толстого клиента» вместо браузера) или хотя бы имеют возможность программного ограничения функциональности для web-интерфейса.

Зависимость от поставщика решения

Пожалуй, самым сложным местом «облачной» модели для медицинских организаций является жесткая зависимости заказчика от разработчиков или поставщиков облачных решений. Напомним, что изначально одной из существенных предпосылок создания облачных вычислений явилось стремление организаций сократить расходы и зависимости от ИТ-профессионалов: ПО становилось все проще в обслуживании, его интерфейс становился все более понятным и доступным. На этом фоне надобность в собственных дорогих ИТ-специалистах сокращалась. Постепенно у организаций-пользователей информационных систем сформировалась идея сократить свой ИТ-штат и расходы на него, передав все на аутсорсинг. На такое стремление заказчиков ИТ-индустрия и предложила идею «облачных» вычислений.

Проблема заключается в том, что реализация «облачных» вычислений на самом деле усиливает привязанность заказчика к поставщику ИТ-решения, т.к. теперь все ресурсы - аппаратные, системные, да и просто данные - находятся в «облаке», которым монопольно владеет его создатель. В результате, фактически, всегда есть риск, что поставщик такого решения попросту «выкрутит руки» заказчику. Выходом из этой ситуации является создание именно «частного облака» под заказ, владельцем которого должен стать государственный заказчик, лучше – региональный комитет по здравоохранению.  В этом случае вся система будет находиться в руках непосредственно администрации здравоохранения региона, которая уже сама будет решать – создавать ли собственный штат ИТ-персонала или отдавать обслуживание «облака» на аутсорсинг.

Еще одной проблемой является то, что раньше, в классической модели, сам заказчик являлся владельцем ПО, серверов и всей информации, хранимой в этом ПО. Он мог независимо принимать решения об использовании того или иного прикладного ПО, конвертировать и свободно распоряжаться своими данными. В облаке же ПО, сервера и данные находятся, фактически, в централизованном виде. И если заказчик и разработчик не договорятся по цене, условиям использования и перспективам развития конкретного решения, то заказчик может оказаться в ситуации, когда он потеряет не только право использовать такое решение, но и доступ ко всем данным, в этом решении созданном и накопленном. Исключить такую зависимость, обеспечив на будущее возможность гибкой и быстрой модификации «облачной» МИС или экспорт из нее накопленной информации можно при условии поставки системы с открытым исходным кодом, возможностью ее самостоятельной модификации и четким и подробным документальным сопровождением, включая описание форматов данных, внутреннего API системы и т.д.

Для медицинской организации это означает следующее: если вы применяете «облачную» МИС и успешно ее используете, то в системе накапливается огромное количество самой разнообразной информации – от полного реестра пациентов ЛПУ до всех результатов обследования, лечения, наблюдения и т.д. На основе этой информации ЛПУ формирует различные отчеты, включая государственную годовую статистическую отчетность, получает готовые реестры на оплату услуг и т.д. Получается, чем эффективнее для учреждения система, тем сильнее она от нее зависит. В связи с этим «облачный» проект автоматизации должен быть построен таким образом, чтобы заказчик являлся не только пользователем, но и полноправным владельцем всей системы, включая ее аппаратное и программное обеспечение. Применение аренды созданных сторонними организациями решений является крайне рискованным, хотя и очень привлекательным с точки зрения экономии начальных затрат решением. Представьте, что в один прекрасный момент стоимость аренды такой МИС будет увеличена настолько, что ЛПУ не сможет платить? С этой точки зрения все будет очень похоже на «первую бесплатную инъекцию» наркотика. Может быть, для начала, все бесплатно и хорошо, но потом – с этой «иглы» уже не слезть.

Экономическая эффективность

Одним из самых ярких преимуществ «облаков» является сокращение расходов. Однако аналитики приводят примеры, когда общая совокупная стоимость владения «облачным» решением может оказаться выше, чем в классической схеме, поэтому оценку экономической эффективности и принятие специальных мер по ее обеспечению необходимо планировать.

Большинство примеров и расчетов показывают, что начальные затраты на развертывание информационной системы на основе «облачных» вычислений, как правило, ниже. Например, Эми Спеллманн из Optimal Innovations, Ричард Джимарк из Hyperformix и Марк Престон из RS Performance проанализировали перспективы гипотетического интернет-магазина, руководство которого должно выбрать: держать ли собственный сервер или подписаться на сервис облачных вычислений Amazon. Для каждого из двух вариантов на два года вперед были рассчитаны затраты и потребление энергии. В итоге выяснилось, что расходы на сайт, созданный с помощью Amazon, вначале будут ниже, чем затраты на внутренний сервер, но со временем начнут превышать их — даже с учетом сэкономленной энергии.

Это объясняется тем, что решение нужно заказчику постоянно, по мере роста «облачных» вычислений для него потребуется все больше вычислительной мощности, а это значит – что оплата за использование «облака» будет постоянно увеличиваться. Более того, нужно четко понимать, что в стоимость аренды «облачного» решения все равно входят те же самые затраты (электроэнергия, разработка и сопровождение ПО, аппаратная инфраструктура, обслуживание и т.д.), от которых планирует избавиться заказчик, но плюс к этому сюда же включена прибыль поставщика такого решения. В связи с этой потенциальной опасностью, а также учитывая высказанные ранее оценки других рисков, мы рекомендуем проработать «облачные» проекты таким образом, что исполнитель (поставщик решения) создавал всю инфраструктуру для заказчика по принципу «частного облака» на заказ, а постоянная во времени оплата за использование этого ресурса отсутствовала.

Конечно, совсем без услуг поставщика решения обойтись не получится: нужно обязательно планировать техническую поддержку и сопровождение, возможно, понадобятся какие-то специальные доработки и т.д. Но их стоимость и трудозатраты для исполнителя уже будут аналогичными при классической схеме, а значит – на итоговую стоимость владения проектом для заказчика и, как следствие, экономическую эффективность «облака» по сравнению с обычной моделью, влиять не будут.

В целом, перспективы массового и обоснованного применения «облачных» вычислений в отечественной медицине очевидны. Несмотря на различные объективные сложности, «облачные» вычисления будут активно развиваться и, в том числе, конечно же, и на рынке программного обеспечения для медицины. Очевидно, что для отдельных задач «облака» оправданы и целесообразны уже сейчас: это различные дополнительные сервисы, ориентированные на web. Например, системы удаленной записи к врачу через интернет (так называемые «Электронные регистратуры»), системы для хранения персональных медицинских записей самими пациентами, шлюзы для подключения к МИС из мобильных устройств (типа iPhone или планшетных компьютеров), централизованные системы сбора и анализа аналитической информации и т.д.

По мере развития «облачных» вычислений ситуация, вероятно, будет развиваться и далее. Есть предпосылки для появления первых «больших» региональных проектов. Вместе с этим, необходимо обратить внимание, что в здравоохранении есть жесткое, выверенное за сотни или даже тысячи лет врачебной практики, правило - не навреди. В случае «облаков» это означает обязательный учет и оценку существующих рисков, выбор надежных поставщиков и применение проверенных временем специализированных «облачных» решений.

Александр Гусев