Настоящая концепция определяет цели, задачи, общую архитектуру, основные этапы создания региональной информационной системы в здравоохранении (далее – Система), а также механизм управления и ресурсного обеспечения создания и эксплуатации Системы. Настоящая концепция учитывает рамки, планы, архитектурные решения, а главное, тенденции в работах, которые проводит в области информатизации здравоохранения Минздравсоцравития России.
Так при разработке настоящей концепции использовался документ «Концепция создания единой государственной информационной системы в сфере здравоохранения (ЕГСИЗ)», утвержденная Приказом Министерства здравоохранения и социального развития Российской Федерации от 28 апреля 2011 № 364 (далее Концепция Минздрава).
Введение настоящего документа посвящено месту концепции в жизненном цикле проекта информатизации, определяется онтологическое место понятию «Концептуальное проектирование».
В главе 1 «Информатизация здравоохранения. Кто и чего хочет?» выявляются заинтересованные стороны в вопросах информатизации здравоохранения: органы и организации системы здравоохранения, а также граждане в рамках процессов ее непосредственного получения. Относительно структуры проекта концепция в этой главе стремится дать ответы на следующие вопросы: Кто чего хочет и почему (пациенты, медучреждения и органы управления здравоохранением)?
Глава 2 «Информатизация здравоохранения. Описание текущей ситуации» посвящена описанию текущей ситуации и формулированию проблемы заинтересованными лицами: гражданами, медучреждениями и органами управления здравоохранением. Этот раздел цитирует соответствующий фрагмент Концепции Минздрава, где перечислены наиболее острые проблемы в области управления здравоохранением, в области непосредственного оказания медицинской помощи, в области взаимодействия органов управления здравоохранением, медицинских организаций и медицинского персонала с населением и организациями по вопросам здравоохранения.
Далее в главе 2 предпринята попытка выявления истинных причин проблем и их взаимосвязи. Среди всех причин катастрофического отставания информатизации здравоохранения России от ведущих стран заключается в том, что мы почти не вкладываем денег во владение информационной системой в каждом отдельном ЛПУ, в ее развитие. Несмотря на то, что принята программа информатизации здравоохранения России и определены объемы финансирования, этих средств недостаточно. Это легко понять, если применить технику расчетов, известную как Совокупная стоимость владения информационной системой (Total cost of ownership, TCO). Можно ли оптимизировать затраты на владение информационной системой для отдельного учреждения? Настоящая концепция отвечает на этот вопрос утвердительно, так как здесь существуют скрытые резервы. О них речь пойдет в главе 4 "Как этого добиться? Какие задачи необходимо решить для достижения цели".
В главе 3 «Что должно быть. Цели создания системы» описана целевая система информатизации региона. Цели создания системы. Что мы хотим получить в итоге, чтобы это устроило всех. Ясно, что основные требования к целевой системе определяются теми требованиями, которые сформулированы в главе 1 настоящего документа «Информатизация здравоохранения. Кто и чего хочет?». Однако основные архитектурные решения системы информатизации регионального здравоохранения ограничены требованиями к созданию ЕГИСЗ, сформулированными в Концепции Минздрава и последующих связанных документах.
После ссылок на разделы Концепции Минздрава, определившими основные рамки разработки проекта региональной системы информатизации, следуют разделы описывающие основные архитектурные решения Региональной Системы Информатизации Здравоохранения (РСИЗ). Укрупнено РСИЗ базируется на двухслойной архитектуре. Первый слой состоит из вычислительных платформенных компонент, а уже на нем размещается, собственно, целевое прикладное программное обеспечение, реализующее функциональные требования к создаваемой системе.
В настоящей концепции выбраны три типа платформенных компонент, дано обоснование их выбора и описание базовых стандартов:
BPMS –Business Process Management System (лечебно-диагностические процессы; административно-хозяйственные процессы; процессы ведомственного и межведомственного взаимодействия)
Электронная медицинская карта – система (документирование лечебно-диагностического процесса; архивирование клинических документов и клиническая отчетность)
ERP- система (административно-хозяйственная деятельность и отчетность)
Почему, на наш взгляд, лечебно-диагностический процесс, административно-хозяйственный и процесс межведомственного и внутриведомственного взаимодействия лучше всего обеспечить процессными инструментами проектирования, внедрения и сопровождения? Что общего в этих видах деятельности? Существуют, как минимум, два уровня абстракции, исходя из которых, можно попытаться ответить на этот вопрос. Первая точка зрения отражает функциональный аспект деятельности, который можно представить в виде некоторого списка функций, нагруженных на деятельность. Вторая точка зрения отражает процессную составляющую деятельности. Здесь деятельность рассматривается как некоторый процесс, состоящий из цепочки переходов от одного узла к другому, каждый из которых есть либо действие, являющееся одной из функций деятельности, либо точка ветвления процесса: каким должен быть очередной шаг процесса. При этом важно понимать, что в процессах определяющим является обеспечение взаимодействия его участников, уровень коммуникационных сервисов и управление регламентом. И с этой точки зрения эти три вида деятельности для целей применения ИТ-технологий не имеют различий. Различия в функциональности, а не в топологии процессов.
Если для ИТ-поддержки функционального подхода эти три вида деятельности требуют различных ИТ-инструментов, то для поддержки процессной составляющей деятельности можно применить одну такую, набирающую популярность управленческую технологию, как управление бизнес-процессами (BPM - Business Process Management), которое представляет собой сочетание методологии, инструментария и принципов реализации проектов.
BPM – это движение и взгляд в будущее в медицине. По данным Gartner, Inc, ключевой компонентой четвертого поколения электронных медицинских записей будут процессы. Gartner утверждает, что "процессные системы будут неотъемлемой интегрирующей частью МИС”. Обоснование применения BPMS приведено в Приложении 3 «Доказательная медицина, стандарты оказания медицинской помощи и моделирование лечебно-диагностического процесса», а также в Приложении 5. «Возможности и вызовы процессного подхода (Workflow) в здравоохранении».
Масштабы и границы определения ЕГИСЗ обуславливают необходимость создания общей архитектуры и применения стандартов взаимодействия между ее различными частями. Общепринятым в мире является пациент-ориентированная общая электронная запись пациента (patient-centric shareable electronic health records, EHR). При этом она является ядром системы информатизации здравоохранения любого уровня. Это утверждение справедливо также и для любой МИС. И поэтому следует сосредоточиться на стандартах интеграции и интероперабельности приложений и информационных систем, обязательным элементом которых является поддержка ЭМК. Подробнее об этом смотри Приложение 4. «Система ЭМК и стандарты обмена медицинской информацией».
Система ЭМК в нашем представлении - это централизованное хранилище электронных медицинских записей по всем обращениям пациентов. Это хранилище представляет собой базу данных, содержащую исчерпывающую информацию о пациенте и набор сервисных программ для доступа к ней. Стандарты хранения и информационного взаимодействия медицинских систем можно разделить на следующие категории.
Стандарты сообщений, ставящие во главу угла протоколы конкретных взаимодействий и описывающие формат передаваемых сообщений. Содержат жесткие схемы документов и негативны к обновлениям схем сообщений. Примером может служить HL7v2(2).
Стандарты неконтролируемой обобщенной структуры, содержащие язык описания структур, но не контролирующие содержание контролируемых структур. Не позволяют говорить о «понимании» двумя системами друг друга. Аналогией может служить XML. Пример – HL7 CDAr2(3).
Стандарты контролируемой обобщенной структуры. Содержат способ формального описания хранимого и передаваемого контента. Примером может служить HL7 CDAr2 + HL7 templates.
Стандарты семантических платформ, содержат кроме трех предыдущих пунктов также формальное описание платформы для взаимодействия входящих в нее сервисов и алгоритмов их работы.
Стандарт openEHR позиционируется как стандарт семантической платформы. Стабильная информационная модель (IM), позволяет формировать информационный обмен документов неконтролируемой обобщенной структуры (категория 2). Поверх IM создана развитая система моделирования клинического контента, состоящая из архетипов и шаблонов. Эта модель позволяет эффективно управлять медицинскими знаниями, распространяя формальное описание схем по всем участникам информационного обмена, при этом гибко адаптируя их под свои нужды. Кроме того, двухуровневое моделирование позволяет добиться хорошего повторного использования разработанных схем.
Кроме клинического контента в стандарте openEHR также описаны вопросы коллективного ведения ЭМК: стандартный способ синхронизации баз данных (с помощью настройки требуемых потоков синхронизации), управление изменениями в разных системах и устранение конфликтов, вопросы версионности и т.д.
Спецификации openEHR используют имеющиеся международные стандарты там, где это уместно, и, насколько это возможно, с максимальной степенью совместимости. Это дает возможность разработчикам создавать цельные openEHR системы, при соблюдении стандартов или совместимости с ними.
Таким образом, вопросы коллективного управления семантически-значимым медицинским контентом, а также коллективного ведения единой региональной ЭМК пациентов субъекта РФ более проработаны в стандарте openEHR.
Далее в главе 3 описан слой прикладного программного обеспечения. Его состав, содержание и технологические решения определены рамками документа «Методические рекомендации по составу прикладных компонентов регионального уровня единой государственной информационной системы в сфере здравоохранения, а также функциональные требования к ним, обязательные для создания в 2011 – 2012 годах в рамках реализации региональных программ модернизации здравоохранения». Эти требования носят обязательный характер. В следующих разделах:
Состав прикладных компонентов регионального уровня ЕГИСЗ
Требования к прикладным компонентам регионального уровня
мы приводим основные положения этого документа.
Далее в концепции представлена архитектура прикладной составляющей РСИЗ. Здесь представлены принципы создания системы и ее состав. Состав прикладной системы регламентирован отраслевыми методическими рекомендациями и дополнен группой «Административно-хозяйственная система».
Глава 4. «Как этого добиться? Какие задачи необходимо решить для достижения целей». В этой главе обсуждаются верхнеуровневые задачи реализации проекта информатизации регионального здравоохранения. В частности задача оптимизации затрат на владение информационной системой. Среди затрат, составляющих ТСО, существуют скрытые резервы. Анализ структуры ТСО и поведения затрат показал, что большинство затрат являются эластичными - в них содержатся резервы для снижения стоимости. Первым источником снижения затрат является использование свободного программного обеспечения. Значительной экономии многих затрат на владение информационной системой можно достичь используя технологию облачных вычислений (cloud computing). Мы платим за услуги столько, сколько потребляем. Концентрация в одном месте вычислительных ресурсов и квалифицированного персонала, оказывающих услуги множеству клиентов приводит к тому, что издержки в расчете на одно рабочее место оказываются значительно ниже. Услуга становится дешевой, если тиражируется многократно и ее ресурсы простаивают минимально. Внедрение и эксплуатация должны осуществляться по аналогичной схеме: удаленно и одной высококвалифицированной командой. Бизнес-модель «IT как услуга» - это способ значительного снижения IT-затрат. Применительно к региональному здравоохранению "облако" может являться внутренним сервисом региональной системы охраны здоровья населения.
Существует еще один источник снижения потерь. Чтобы его реализовать, следует позаимствовать у западных коллег и новую бизнес-модель деятельности при разработке системы, основанную на принципах OpenSource. Бизнес-моделью разработки проекта информатизации регионального здравоохранения является задача создания сообщества OpenHealth.ru. Создание сообщества специалистов, являющихся основным интеллектуальным и производственным ресурсом разработки системы информатизации здравоохранения региона, - одна из важнейших задач для достижения поставленных целей. Сообщество OpenHealth.ru создает систему информатизации за счет различных источников финансирования, но результат его труда всегда лицензируется по правилам свободных лицензий - OpenSource.
Завершается глава 4 схемой возможного плана работ.
В Приложении 1 представлена возможная конфигурация технической архитектуры вычислительной платформы регионального здравоохранения.
Приложение 2 посвящено некоторым важным замечаниям реализации проекта. В частности – особенностям бухгалтерского, налогового и управленческого учетов при централизованной организации доступа к ИТ-ресурсам.
Об остальных приложениях мы уже упоминали.
Оглавление
Введение. Место концепции в жизненном цикле проекта информатизации
Глава 1. Информатизация здравоохранения. Кто и чего хочет?
Глава 2. Информатизация здравоохранения. Описание текущей ситуации
Глава 3. Что должно быть. Цели создания системы
Глава 4. Как этого добиться? Какие задачи необходимо решить для достижения целей
Приложение 1. Вычислительная платформа регионального здравоохранения. Техническая архитектура
Приложение 2. Некоторые важные замечания реализации проекта
Приложение 3. Доказательная медицина, стандарты оказания медицинской помощи и моделирование лечебно-диагностического процесса
Приложение 4. Система ЭМК и стандарты обмена медицинской информацией
Приложение 5. Возможности и вызовы процессного подхода (Workflow) в здравоохранении
|
