Приложение 1. Вычислительная платформа регионального здравоохранения. Техническая архитектура
Приложение 1. Вычислительная платформа регионального здравоохранения. Техническая архитектура
Ниже приведена техническая архитектура и компонентный состав вычислительной платформы здравоохранения. При этом настоящая концепция рассматривает названные продукты только лишь в качестве возможных вариантов. Определение физических компонент логической архитектуры не является задачей концепции, а относится к компетенции следующих шагов развития проекта информатизации здравоохранения. Такое закрепление не может быть жестким, в принципе, так как здесь нас интересует только класс программных средств и используемые стандарты, а конкретные экземпляры могут меняться и заменяться в соответствии с развитием соответствующих технологий и предпочтений на местах.
BPM Suite BizAgi
BizAgi является одним из лидеров рынка систем BPMS (Business Process Management Suite). По мнению экспертов, от других BPM-систем BizAgi отличает ориентированность на удовлетворение потребностей бизнеса, в противоположность задачам чистой автоматизации.
Отличительные особенности BizAgi BPMS:
- Бескомпромиссная поддержка BPMN. BizAgi далеко выходит за пределы базового набора, обычно реализуемого поставщиками BPMS – в ней реализованы, такие, например, конструкции, как обмен сообщениями между процессами, компенсации и exclusive event gateway. Причем 100% того, что предлагается в моделере, может быть использовано в процессном движке и затем проанализировано при помощи компоненты BAM (Business Activity Monitoring).
- Доступная цена. BizAgi BPMS предлагается в нескольких конфигурациях: Xpress, Standard, Enterprise. Начальная конфигурация Xpress рекомендуется для использования при числе пользователей до 100 и предлагается по цене $120 за рабочее место ($100 лицензия и $20 годовая техническая поддержка). В конфигурациях Standard и Enterprise BizAgi соответствует потребностям крупных компаний и банков, что подтверждается сотнями успешных внедрений по всему миру.
- Поддержка русского языка. Пользовательский интерфейс русифицирован, компания Бизнес-Консоль осуществляет поддержку на русском языке.
Bizagi это решение BPM, которое позволяет строить модели деятельности, выполнять и совершенствовать бизнес-процессы, используя графическую среду, без необходимости программирования.
BizAgi Студия представляет собой строительство среду, которая преобразует процессы, разработанные с помощью BizAgi Process Modeler в приложения без необходимости программирования. BizAgi предлагает набор инструментов, который позволяет графически определять модели бизнес-процессов (блок-схемы, бизнес-правила, пользовательский интерфейс, и т.д.). Эта модели хранится в базе данных и интерпретируется и выполняются в BPM Server BizAgi без необходимости использования промежуточного кода.
Следующая диаграмма показывает все этапы, в которых BizAgi Студия поддерживает жизненный цикл процесса:
BizAgi Студия предлагает среду для совместной работы. Результаты работ (модели) надежно хранится в базе знаний, которые могут быть повторно использованы другими людьми. BizAgi делает возможным сотрудничество между командами, расположенными в различных местах. Пользователи могут проверять процессы, изменять и улучшать их, а затем проверять их снова.
Логическая архитектура BizAgi
На рисунке показаны логические уровни и структурные компоненты bizagi, а также взаимодействия между ними.
Верхний слой включает в себя организационные процессы. Эти процессы обычно включают в себя сочетание ручной деятельности (осуществляет человек) и автоматической деятельности (осуществляется системой).
Оба вида деятельности требуют сложной обработки данных (выраженных в сущностях (entities) bizagi и принятия решений на основе конкретных значений указанных данных (бизнес-правил). Эта функциональность поддерживается компонентами слоя бизнес-объектов (business object layer).
В bizagi, человек, который моделирует процесс всегда предполагает, что данные локальны, то есть, что в bizagi они выражены в модели сущность-связь. Организационный процесс никогда не должны содержать действия по доступу и/или обновлению данных; автоматические действия (которые предусматривают взаимодействие с системами других производителей) должны использоваться только для выполнения операций внешними системами.
Кроме того, бизнес-правила предполагают, что все данные, необходимые для принятия решений находятся внутри сущностей bizagi и, следовательно, не должны включать отображение данных и доступ к логике (знание, которое чуждо для бизнес-аналитика).
Если имеются данные о внешней системе, то bizagi поддерживает виртуализацию сущностей (таблиц) bizagi. Технология виртуализации сущностей в Bizagi поддерживает прозрачный доступ к данным, управляемым сторонними системами с помощью веб-сервисов, слой автоматизации интеграции корпоративных приложений (EAI), системы обмена сообщениями (например, IBM MQ Series), а также прямой доступ к базам данных. Когда вопрос о внешнем доступе к данным, сосредоточен на одном компоненте - виртуализация сущностей, то количество интерфейсов резко уменьшается, поддержка приложений упрощается, и гарантируется лучшее качество комплексного решения.
Другая альтернатива для выполнения B2B интеграции находится в слое Enterprise Service, через который bizagi публикует запрос для других приложений для вызова и использования сервисов, что позволяет оркестровать подобные автоматические задачи и процессы, с архитектурными стилями, направленными на внешние сервисы в организациях.
В реальных проектах BPM, некоторые бизнес-правила могут требовать сложных вычислений или обработки. Для того, чтобы сохранить бизнес-правила, понятными и гарантировать их надлежащее исполнение, bizagi позволяет использовать простую регистрацию и доступ этих программных компонентов, с помощью библиотеки компонентов и функций (Component Library and Functions).
Некоторые действия (шаги) в рамках процесса могут потребовать использования специальных инструментов для реализации специфических действий, таких как калькулятор - используется в деятельности кредитного аналитика - определить ежемесячные выплаты ипотечного кредита. Эти инструменты должны быть разработаны с использованием традиционных инструментов программирования и в дальнейшем могут быть легко интегрированы в bizagi.
Платформа OpenHealth
OpenHealth - первая российская платформа для развертывания/интеграции клинических приложений для внедрения коллективных ЭМК согласно открытому стандарту openEHR в масштабах субъекта РФ. Эта платформа базируется на вычислительной платформе здравоохранения openEHR. Платформа разработана российской компанией Infinnity Solutions с использованием спецификации openEHR.
Ключевые характеристики платформы openHealth:
- Масштабируемость и надежность архитектуры
- Поддержка развертывания сервисов системы на физически разделенных узлах ЦОД
- Поддержка распределения хранилищ однотипной информации на физически разделенных узлах ЦОД
- Устойчивость к нагрузкам:
- асинхронное взаимодействие сервисов на базе сообщений
- оркестровка сообщений
- Обеспечение заданного уровня качества функционирования отдельных сервисов:
- Приоретизация запросов
- Гарантированное времени отклика
- Балансировка нагрузки реальных обработчиков сообщений
- Устойчивость к сбоям и нештатным ситуациям:
- Гарантированная доставка сообщений
- Зеркалирование узлов ЦОД
- Кэширование данных
- Мониторинг/аудит/протоколирование
- Централизованная модель развертывания единого общего приложения для всех ЛПУ
- Обеспечение удаленного использования ПО через web-интерфейс
- Централизованное администрирование ПО
- Организация изолированных хранилищ под каждое ЛПУ
- Независимое конфигурирование отдельных ЛПУ
- Простое развертывание и внедрение ПО для новых ЛПУ
- Минимизация затрат на серверное оборудование и инфраструктуру ЛПУ
- Поддержка бизнес-модели использования ПО как услуги (SaaS)
- Пользовательский интерфейс в виде веб-приложения
- Минимум конфигурирования при подключении новых клиентов
- Кросс-платформенные тонкие клиенты, работающие из под веб-браузера
- Простота обновления серверной части ПО
- Централизованное кэширование данных
- Гибкая функциональная адаптация
- Конфигуратор функциональности без необходимости модификации исходных кодов
- Визуальные инструменты моделирования предметной области на основе открытого стандарта
- Средства кастомизации пользовательского интерфейса
- Изолированная учетная подсистема на реляционной БД для гибкой настройки учетных регистров и отчетности
- Открытость для интеграции
- Поддержка стандартного механизма web-сервисов
- Поддержка открытого международного стандарта обмена медицинскими данными
- Обеспечение интероперабельности за счет возможностей единой семантической платформы
- Безопасность
- Интеграция с Active Directory для аутентификации и управления пользователями
- Ролевое управлении доступом к данным и функциям
- Физически раздельное хранение персональных данных и документов в псевдомизированном виде
- Поддержка инфраструктуры открытых ключей ЭЦП
- Регистрация событий безопасности и действий пользователей по доступу к данным и функциям в журнале аудита.
Отличительной особенностью разработанной платформы openHealth является возможность централизованного управления на уровне региона схемами информационного обмена и медицинского контента согласно открытому международному стандарту openEHR. При этом ЛПУ, участвующие в коллективной ЭМК, получают возможность адаптации схем медицинского контента для своих нужд.
Сервисная модель, описанная в стандарте openEHR, позволила построить систему на основе масштабируемой архитектуры корпоративных приложений Enterprise Service Bus (ESB). Такая архитектура обладает возможностями резервирования сервисов и автоматического распределения нагрузки (как следствие, хорошей масштабируемостью), широкими возможностями по вариантам развертывания, а также возможностью интеграции с любыми сторонними приложениями.
Кроме информационной модели, которая охватывает огромное количество аспектов, существует и описание сервисной модели, то есть модели организации и взаимодействия сервисов. В платформе openEHR вся функциональность разбита на набор сервисов: в отдельный сервис выделены демографические данные (требующие защиты), данные терминологии также выделены в отдельный сервис (который может быть один на страну или регион), отдельно стоит сервис управления архетипами и шаблонами, и т.д.
Существенным плюсом является то, что эти сервисы могут разрабатываться разными вендорами.
Ядром платформенного решения на базе стандарта openEHR является система базовых типов и способ построения ссылок (IM). Это статическая неизменяемая часть.
Следующие слои являются динамическими, позволяющими проводить клиническое моделирование. Для улучшения качества моделирования, повышения уровня повторного использования, и для возможности гибкой настройки системы динамическая часть разделяется на составляющие: слой архетипов, слой шаблонов, запросов и привязки терминологии (классификаторы).
Стандарт openEHR позиционируется, как стандарт семантической платформы. Стабильная информационная модель (IM), позволяет формировать информационный обмен документов неконтролируемой обобщенной структуры. Это достигается путем отделения архетипов (повторно используемые блоки информации) от шаблонов (содержащих специфические требования ЛПУ), что дает возможность разработчикам систем свободно моделровать клинический контент без опасения нарушить интероперабельность, которая гарантируется на уровне архетипов.
Так для одного ЛПУ может быть создан шаблон выписного эпикриза, который значительно отличается от аналогичного документа другого ЛПУ, но так как оба базируются на одной и той же библиотеке архетипов, информация из такого документа может быть подвергнута машинной обработке на принимающей стороне.
Архетипы — концепции предметной области, содержат структуру данных и ограничения на данные, отличаются максимальной полнотой. Пример: вес человека, адрес, просто человек.
Шаблоны — сущности документооборота, объединяют архетипы в композит, убирают ненужные поля, ослабляют или усиливают ограничения, настраивают связи между входящими в состав архетипами. Например, способ задания адреса регистрации у человека (то есть выбор, какой конкретно архетип адреса будет использоваться) обычно задается на уровне шаблона.
Отметим, что на этапе моделирования архетипа человека мы не указываем, как конкретно будет задаваться адрес регистрации. Мы просто указываем в этом архетипе поле «Адрес» и, возможно, настраиваем на него какие-либо ограничения.
Все это реализуется за счет наличия в языках описания архетипов и шаблонов так называемых слотов. По сути это механизм позднего связывания, аналогичный стандартным механизмов платформ разработки .net и java.
Стоит отметить, что в зависимости от нужд, связывание может происходить как на уровне региона (федерации), так и на уровне ЛПУ.
В отдельный сервис вынесена идентификация справочных данных. Например, в осмотре пациента нужно проставить диагноз, при этом он может быть закодирован как МКБ-10, так и SNOMED’ом. Выбор конкретного справочника и управление им является, безусловно, отдельной задачей. Поэтому в платформе openHealth управление терминологиями вынесено в отдельный сервис.
Т.к. поверх IM создана развитая система моделирования клинического контента, состоящая из архетипов и шаблонов, полученная модель позволяет эффективно управлять медицинскими знаниями, распространяя формальное описание схем по всем участникам информационного обмена, при этом гибко адаптируя их под свои нужды.
Инструментальный комплекс автоматизации разработок "ИКАР 2.0"
Икар 2.0 - это программное инструментальное и исполнительное средство для разработки, эксплуатации и сопровождении систем автоматизации финансово-хозяйственной деятельности предприятия, разработанное компанией Комсофт. На базе этой платформы в 1998 году создано комплексное отраслевое решение для энергетики "Корпоративная информационная система "ИКАР" (версия 2.0)", которое с тех пор успешно используется и развивается.
В 2001 году компанией PriceWaterhouseCoopers в рамках проекта «Разработка плана реализации единой информационной системы ОАО «АК Транснефть» было проведено комплексное обследование уровня автоматизации одного из клиентов фирмы Комсофт - ОАО «Приволжские магистральные нефтепроводы». В результате обследования были сделаны следующие выводы:
Функции бухгалтерии, снабжения, сбыта и финансов автоматизированы практически полностью. Система «ИКАР» реализована на высоком профессиональном уровне и производит хорошее впечатление как с точки зрения построения логической архитектуры, так и ее реализации (структура БД, приложения). Сколько-нибудь существенных претензий со стороны пользователей нет. Необходимо отметить успешную интеграцию систем «АСКИД» и «ИКАР».
23 ноября 2004 года Оргкомитет Международного Форума бухгалтеров и аудиторов и Президиум Международной академии экономики и финансов присвоил бухгалтерской службе ОАО «Самараэнерго» почетное звание «Лучшая российская служба бухгалтерского учета - 2004», а главный бухгалтер ОАО «Самараэнерго» Варенов А.Ф. награжден почетным знаком «Отличник российской системы бухгалтерского учета».
Институт профессиональных бухгалтеров России провел экспертизу этого программного продукта. Результатом экспертизы стало заключение экспертной комиссии о том, что
Компьютерная программа "Корпоративная информационная система "ИКАР" (версия 2.0)" обеспечивает ведение бухгалтерского учета, составление бухгалтерской отчетности в соответствии с текущими правилами нормативного регулирования системы бухгалтерского учета РФ (по состоянию на 20.12.2005). При этом обеспечивается высокий уровень автоматизации реализуемых функций. Институт профессиональных бухгалтеров России подтвердил заключение экспертизы соответствующим сертификатом.
Экспертный совет по методологии автоматизации бухгалтерского учета, аудита и экономического анализа ИПБ России в своем заключении о результатах экспертизы отметил, что
широкая финансовая и управленческая функциональность в сочетании с высоким уровнем автоматизации реализуемых функций, при наличии развитых свойств адаптивности и настраиваемости свидетельствует о том, что Программный продукт может применяться на крупных производственных предприятиях различной отраслевой принадлежности различных организационно-правовых форм и форм собственности: коммерческих (включая унитарные предприятия) и некоммерческих.
ИКАР 2.0 как платформа
Икар 2.0 является платформой для прикладного программного обеспечения. Именно с помощью этого инструмента возможно визуальное описание модели предприятия при проектировании автоматизированной системы управления административно--хозяйственной деятельностью. С его помощью пользователь может самостоятельно развивать систему или строить собственные подсистемы и задачи.
Платформа ИКАР 2.0 обеспечивает следующий имидж, выстраиваемых на ее основе прикладных систем. Ядром прикладной системы является блок операционного учета, обеспечивающий необходимой информацией службы бухгалтерского, налогового, управленческого и других видов учета. Основой данной модели служит однократный ввод информации в систему с присвоением ей тех признаков, которые необходимы для дальнейшего анализа и построения различных видов отчетности.
На рис. Х схематично показан имидж прикладной системы. Внизу в виде плоскости и вектора времени показаны факты (события) финасово-хозяйственной деятельности, которые регистрируются в системе в виде первичных оправдательных документов. Это уровень операционного учета, который завершается реконструкцией этих самых фактов в соответствующих учетных моделях. Бизнес-логика этой реконструкции моделируется в виде набора шаблонов проводок, которые отражаются, как правило, в нескольких учетных моделях, по крайней мере, в одной. Каждая из учетных моделей представляет собой организованную совокупность показателей той или другой учетной системы (хозяйственной задачи). На самом верху рисунка размещен куб, который символизирует отчетность, анализ деятельности и подсистему принятия решений.
О моделировании в системе ИКАР 2.0
Информационное моделирование хозяйственной деятельности предприятий сводится, в конечном счете, к взаимосвязанному множеству экономических показателей, которые можно разделить на три группы:
- Показатели, включаемые в периодическую отчетность для фискальных органов и органов госстатистики
- Показатели, включаемые в отчетность ведомственного управления
- Показатели, включаемые в управленческую отчетность, необходимую менеджерам всех уровней для управления собственно предприятием
Ясно, также, что эти множества пересекаются. Первый слой моделирования (терминологический) состоит из системы классификаторов содержащих абстрактные символы и понятия (справочник элементов и статей затрат, справочник организационной структуры, материалов и т.д.), большинство из которых используются при моделировании учетных задач (второй слой моделирования).
Второй слой моделирования. Метод проектирования информационных систем здесь базируется на использовании основных принципов бухгалтерского учета, который является способом моделирования финансово-хозяйственной деятельности, и применении этих принципов и методов для организации учетно-аналитической работы во всех других управленческих задачах.
Информационные технологии для решения задач управления предприятием подразумевают наличие адекватной модели управляемой системы. Известно, что модели позволяют нам отображать явления и объекты реального мира на множество абстрактных символов и понятий, а связи между ними - на связи между соответствующими абстракциями.
Другими словами, абстрактные символы и понятия – это лишь элементы, составляющие модель. При моделировании методом бухгалтерского учета балансовые счета являются абстрактными символами, а связи между ними (проводки) - указывают на связи между объектами реального мира. Модели применяются для наблюдения за поведением исследуемой области (прототипа), а поведение предполагает «движение» во времени, взаимодействие между абстрактными символами, описывающими те или иные характеристики предметной области. Движение - это изменение состояния моделируемых объектов под воздействием фактов хозяйственной деятельности.
Центральным местом в данной методологии является выявление различных точек зрения на одни и те же факты хозяйственной деятельности (точка зрения главного бухгалтера, точка зрения начальника снабжения, точка зрения менеджера по задолженностям и т.д.). Далее для каждой точки зрения составляется свой план счетов (модель), чтобы получить для каждой управленческой задачи модель учета того или иного вида управленческой деятельности. Информация в модели поступает с первичных документов в виде набора проводок. Так как факты хозяйственной деятельности регистрируются первичными документами и интерпретируются в соответствии с разными точками зрения, то с одного первичного документа проводки могут быть записаны в любое количество моделей одновременно или в разное время.
В информационной системе должно быть столько моделей (планов счетов), сколько необходимо для решения различных задач управления. Например, бухгалтерская модель, модель для управления финансами, модель для управления запасами, модель для управления процессом заготовления материальных ценностей, модель для управления дебиторской и кредиторской задолженностью, модели бюджетов и бизнес-планов и т.д. Состав и аналитика системы счетов каждой из моделей определяется целями и задачами, поставленными перед моделями.
Третий слой моделирования - моделирование бизнес-логики. В учетных моделях все показатели подразделяются на качественные и количественные. При этом качественные показатели код подразделения, статья затрат и пр. выбираются из классификаторов и справочников (пусть даже косвенно, через документы), количественные показатели выбираются из первичных оправдательных документов. Но именно документ (хозяйственное событие, зафиксированное в документе) содержит модель (шаблон хозяйственной операции) для реконструкции факта и отражения его в учетных моделях.
Ключевые компоненты системы ИКАР 2.0
Диспетчер - это часть ядра системы, предназначенная для подключения внутренних (встроенных в основной модуль) и внешних (располагаемых в отдельных модулях) объектов. Здесь объектом обозначается программный код, реализующий какую-либо функцию и расширяющий общую функциональность системы. Объектом, например, может быть экранная форма документа, его печатная форма, отчеты или какая-либо процедура, вызываемая из DLL, пакета, внешнего или основного программного модуля. Объекты привязываются, чаще всего, к картотекам, содержащим документы. Функциональный, а не модульный подход. Здесь это означает, что под функцией понимается отдельная экранная форма, печатная форма, отчет и т.д. Все эти функции "назначаются" администратором и могут быть им же отключены, переделаны, заменены, изготовлены заново. Все они представлены самостоятельными исходными текстами (которые после компиляции могут быть DLL-функциями, EXE, COM) или шаблонами Excel (XLT файлами). Функциональная архитектура и метаданные обеспечивают большую степень гибкости и открытости системы, независимость пользователя от разработчика, способность настройки под конкретные условия применения и эволюционный путь развития информационной системы.
В модуле управления доступом назначаются права на просмотр и редактирование картотек, просмотр учетных данных различных систем (моделей) учета, доступ к общесистемным операциям и объектам, доступ к операциям документов
Все действия пользователя, связанные с обработкой информации, фиксируются в этом журнале действий пользователя. Здесь фиксируются код (сетевой) рабочей машины, идентификационные реквизиты пользователя, время события, идентификационные реквизиты документов, над которыми производились действия пользователя, статусы документов и пр.
Навигатор по картотекам. Графическое представление информационной модели предметной области, созданное описателем картотек, используется навигатором картотек для навигации по данным этой модели, визуализации и редактирования данных, визуального формулирования запросов к системе, конструирование вариантов отчетов, установление режимов санкционированного доступа к данным и операциям и т.д.
Навигатор по моделям учета. Навигатор по моделям используется как средство навигации по учетным системам. Он также используется в качестве средства проектирования моделей. Навигатор моделей предоставляет очень удобные возможности для проведения анализа состояния информационной модели предметной области в реальном масштабе времени, так, например, просматривая укрупненные экономические показатели, в любой момент можно «раскрыть» более детальные данные вплоть до первичных документов. Навигация по данным не регламентирует технологию работы пользователя, так как пользователь системы работает не с жестко заданным меню, а с данными, а еще точнее – с представлениями данных в удобной для восприятия и работы форме.
Transact-OLAP предназначен для комплексного многомерного анализа численной агрегированной информации. Данные из моделей и картотек преобразуются в упорядоченную структуру, или куб, позволяющий сфокусировать отчеты на требуемом уровне детализации. Система состоит из двух частей: построитель куба и OLAP-клиент.
Построитель картотек – одна из важных инструментальных частей системы Икар 2.0. Основной принцип построения картотек заключается в том, что картотеки строятся иерархично и основаны на таблицах и представлениях базы данных. В иерархических картотеках хранятся классификаторы и первичные документы, образуя, тем самым, централизованные хранилища классификаторов и первичных оправдательных документов. Эти хранилища являются основными данными, которыми оперирует операционный учет.
Построитель моделей используется в качестве средства проектирования моделей. Результатом проектирования моделей является блок метаданных, описывающий структуру моделей. Опираясь на структуру моделей, работает библиотекарь хозяйственных операций и навигатор по моделям.
Важным инструментальным элементом системы Икар 2.0 является Библиотекарь хозяйственных операций. С помощью библиотекаря описываются хозяйственные операции и шаблоны проводок. Библиотекарь хозяйственных операций, с одной стороны, является средством проектирования хозяйственных операций и скриптов проводок к ним, а с другой стороны, он является «движком» - средством реконструкции хозяйственных операций, т.е. генератором последовательностей проводок из скриптов и средством записи их в соответствующие модели. Библиотекарь хозяйственных операций, тем самым, обеспечивает динамическое единство картотек и моделей.
Система запросов - одна из составных частей инструментальной среды Икар 2.0. Основные функции - создание, модификация, выполнение запросов различных типов и назначений. Включает в себя ряд вспомогательных функций, облегчающих построение запросов: визуальный построитель SQL – запроса, Мастер описателя, а также выбор параметра, используемого в запросе, из картотек. Запросная система работает с множеством доступных картотек, к которым открыт доступ.