CC BY
71
СПИСОК ЛИТЕРАТУРЫ
1. Курочкин С.С., Стась К.Н. Международные стандарты по аттестации систем контроля и управления и оцениванию их характеристик // Промышленные АСУ и контроллеры. - 2000. -№ 3. - С. 33-34.
2. Хенли ЭДж., Кумамото Х. Надежность технических систем и оценка риска / Пер. с англ. - М.: Машиностроение, 1984. - 528 с.
3. Smith D.J. Reliability, Maintainability and Risk, Seventh Edition: Practical Methods for Engineers including Reliability Centred Maintenance and Safety-Related Systems. - Butterworth-Heinemann, 2005. - 368 p.
4. Смит Д.Д. Безотказность, ремонтопригодность и риск. Практические методы для инженеров, включая вопросы оптимизации надежности и систем, связанных с безопасностью. - М.: Группа ИДТ, 2007. - 432 с.
5. Пономарев А.А. Показатель текущей опасности технологического процесса // Средства и системы автоматизации: Матер. V научно-практ. конф. - Томск: Изд-во ТУСУР, 2004. -C. 106-108.
6. Курочкин С.С., Стась К.Н. Международные стандарты по функциональной безопасности систем контроля и управления // Промышленные АСУ и контроллеры. - 1999. - № 9. -С. 27-29.
7. Пономарев А.А., Агеев Ю.М. Прогнозирование аварийных ситуаций на объекте управления с использованием пакета MAT-LAB // Электронные средства и системы управления: Матер. Междунар. научно-практ. конф. - Томск: Изд-во ИОА СО РАН, 2004. - С. 85-88.
8. МЭК 61508 61508-1(1998)/Cor.(1999) (Functional Safety of Electrical/Electronic/Programmable Electronic Safety Related Systems). Функциональная безопасность электрических/электронных/электронных программируемых систем безопасности. Часть 1. Общие требования.
9. МЭК 61511-1 (Functional Safety: Safety Instrumented Systems for the Process Industry Sector). Функциональная безопасность. Инструментальные системы безопасности для промышленных процессов. Часть 1. Требования к структуре, определениям, системе, программному и аппаратному обеспечению.
10. Гражданкин А.И., Лисанов М.В., Печеркин А.С. Использование вероятностных оценок при анализе безопасности опасных производственных объектов // Безопасность труда в промышленности. - 2001. - № 5. - С. 33-36.
Поступила 06.10.2009 г.
УДК 004.9
СОВМЕСТНОЕ ИСПОЛЬЗОВАНИЕ ЯЗЫКА BPEL И СПРАВОЧНОЙ СИСТЕМЫ ДЛЯ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ ЗДРАВООХРАНЕНИЯ
А.А. Пономарев, Нгуен Хоанг Чинь
Томский политехнический университет Email: boss@aics.ru
Рассматривается новый подход к задаче повышения эффективности управления лечебной деятельностью за счет проектирования, мониторинга бизнес-процессов, а также вопросы повышения информационной составляющей лечебного процесса при совместном использовании Web-сервисов и сервера онтологии.
Ключевые слова:
BPEL, BPMN, RIM, бизнес-процесс, лечебно-диагностический процесс. Key words:
BPEL, BPMN, RIM, business process, medical process.
В настоящее время процесс информатизации происходит почти во всех поликлиниках. Для повышения качества и рентабельности медицинского обслуживания, внедряется специализированное программное обеспечение - медицинские информационные системы. В последнее время количество поликлиник увеличивается, следовательно, конкурентность возрастает. Повышение конкурентоспособности зависит от успеха реализации мероприятий, оптимальным образом воздействующих на лечебно-диагностический процесс. Эти мероприятия включают: процессы маркетинга, рекламы и взаимодействия с общественностью, финансирования, технической эксплуатации, мотивации персонала, безопасности, проектного развития, снабжения и
логистики. Для достижения успеха в лечебно-диагностическом процессе необходимо повышение эффективности управления лечебной деятельностью за счет совершенствования и реинжиниринга бизнес-процессов (БП), а также благодаря их оперативному мониторингу и управлению. Основная задача реинжиниринга заключается в том, что он предполагает радикальные и резкие изменения, связанные с отказом от текущего порядка работы, и разработку совершенно новых методов выполнения работ. Совершенствование БП базируется на эволюционном повышении результативности деятельности, предполагающем не кардинальное изменение технологии работы, а постоянную оптимизацию логистической цепочки выполняемых операций [1].
Формально, результатом реинжиниринга является описание и рекомендации по выполнению БП. Насущной проблемой является трудность мониторинга и соотнесения текущего состояния дел и рекомендованной цепочки операций. Решение такой задачи и рассматривается в настоящей работе.
На данный момент описание БП выполняется с помощью разных стандартов, таких как UML диаграмма деятельности, XPDL (XML Process Définition Language), BPMN (Business Process Modeling Notation), BPML (Business Process Modeling Language), BPEL4WS (Business Process Execution Language For Web Services), BPDM (Business Process Definition Metamodel). Среди этих стандартов соединение BPEL4WS с BPMN является подходящим способом для описания БП [2-4].
BPMN используется для визуального представления, а BPEL4WS поддерживает транзакции информации через Web-сервисы; другие стандарты используются преимущественно для описания БП и не могут быть использованы для мониторинга текущих процессов.
Использование BPEL4WS позволит не только описывать БП, но и выполнять задачи мониторинга. Спецификация BPEL4WS проектировалась без учета специфики предметной области лечебной деятельности, к тому же в ней отсутствуют специальные характеристики для описания основных участников (элементов) - пациент, врач, поликлиника и др. Это приводит к трудностям при её использовании для хранения информации о пациенте и его истории болезни, совместимости информационных систем не только на техническом и программном уровнях, но и на семантическом уровне (неточность и неоднозначность интерпретации терминов).
Сообщение о таком событии, как госпитализация больного, в информационных системах различных производителей может включать разные наборы характеристик. Применяются совершенно различные термины для обозначения одного и того же события или состояния, или наоборот - под одним и тем же термином могут пониматься различные события и состояния. Такая проблема возникает из-за того, что разные учреждения используют разные стандарты и форматы описания данных. В данной работе предлагается использовать международный стандарт HL7 (Health Level 7), разрабатываемый с 1987 г. [5]. HL7 является синтаксическим стандартом для обмена, управления и интеграции электронной медицинской информации. Он поддерживает выполнение таких задач, как обеспечение безопасности и идентификацию участников, повышение доступности и достижение согласованности передачи, и, самое важное -структурирование передаваемых данных плюс возможность проектирования систем. Ключевой элемент стандарта HL7 - RIM (Reference Information Model, справочная информационная модель). Данная модель позволяет представить рассматривае-
мый домен HL7 как единое целое. RIM является согласованной моделью совместно используемой информации, и на её основе формируется содержимое всех ^7-сообщений. В действительности, модель позволяет передавать непротиворечивые данные и многократно использующиеся понятия между несколькими информационными блоками, в том числе и сообщениями.
Для устранения недостатка BPEL4WS, связанной с недостаточной выразительной мощностью описания медицинских данных, предлагается совместное использование справочной системы и языка BPEL. Применение языка BPEL позволит унифицировать описание БП, а использование справочной системы позволит повысить информационную составляющую при описании объектов, участвующих при проектировании и мониторинге БП.
В данной статье рассматриваются:
• возможность построения диаграммы БП в медицине с помощью графической нотации моделирования BPMN на конкретном тематическом примере;
• варианты хранения БП в формате XML (BPEL, BPMN);
• структура базы данных для хранения результатов.
Приведем конкретный пример процесса госпитализации пациента в стационаре с момента обследования до момента его выписки.
На первом этапе пациент попадает в поликлинику, либо, обращаясь самостоятельно, либо его доставляет в отделение скорая помощь.
Следующим этапом является обследование для определения дальнейших задач по работе с этим пациентом, результатом которого может быть один из трёх вариантов: отказ от госпитализации, направление в другую больницу или госпитализация. Если пациент отказался от лечения или его направляют в другую больницу, то процесс заканчивается. Иначе инициируется процесс лечения в стационаре, рис. 1.
Сразу после госпитализации ответственные лица определяют отделение, палату и койко-место для пациента, затем определяют лечащего врача.
Лечащий врач составляет план лечения на конкретный период времени. План лечения формируется из назначения процедур, медикаментов и сбора различного вида анализов. Через некоторое время лечащий врач проводит осмотр, по итогам которого вносится корректировка в план лечения. Процесс лечения завершается выпиской. Перед выпиской необходимо оформить ряд документов и выполнить расчет стоимости лечения в случае оказания платных медицинских услуг. В состав обязательных для оформления документов входят статистическая карта (форма 066), история болезни (форма 003), выписной эпикриз и др.
Госпитализация
Г
Выбор врача
И
г
План лечения
и .
г
Выписка
ш
-О
ó
Рис. 1. Принятие решения о госпитализации пациента
ó
В случае использования медицинских информационных систем данные, характеризующие течение лечебного процесса, вносятся в систему различными участниками с использованием соответствующих автоматизированных рабочих мест (старшая и процедурная сестры вносят отметки об исполнении назначений лечащего врача, узкие специалисты оформляют протоколы наблюдений, с использованием цифрового оборудования регистрируются жизненно важные показатели) и, как правило, накапливаются в базе данных, что позволяет их использовать в задачах мониторинга.
Описание лечебного процесса можно выполнить с использованием спецификации BPMN в виде набора диаграмм в программе «BP Expert» [6], рис. 1, 2, где с помощью спецификации языка BPEL получается описание перечисленных диаграмм, пригодное для выполнения задачи мониторинга с применением разработанного программного продукта. Для мониторинга БП с использованием сервисов переменные в каждом элементе определяются с помощью спецификации WSDL (Web Services Definition Language), однако недостатком данного подхода является трудность работы с данными при большом количестве экземпляров однотипных БП. Для устранения такого недостатка предлагается использовать справочную систему, основанную на онтологии для повышения информативной составляющей за счет применения дополнительных атрибутов - элементов БП справочной системы и задания дополнительных требуемых характеристик с использованием сервисов.
Для обеспечения сопряжения со справочной системой разработана структура базы данных (БД), рис. 4, и набор сервисов для обращения к ней.
На приведенном фрагменте схемы БД выделены таблицы «BPXX» для хранения основной информации о бизнес-процессе, а также необходимые данные для построения диаграммы в нотации BPMN. При обращении к БД сервисы получают значения статических переменных, такие, как состояние дея-
тельности, срок ее действия и т. д. (ВР, ВР_Б1ешеп1, ВР_Б^). Определение динамических переменных происходит за счет выполнения сервисов и действий пользователя индивидуально для каждого экземпляра выполняемого БП (BP_Service_Attr_SaveVa1ue).
Ai-{a<M, а<|2, ащ}
A2={a2i, а22, а2т} Ai
Ak={ak1> Эк2, ..., Эк|} Ак-1
Рис. 2. Развернутое описание процесса госпитализации. Набор динамических переменных
Далее рассматриваются шаги реализации предлагаемого подхода. Его суть заключается в том, что в качестве параметров на вход подсистемы мониторинга подают идентификаторы БП, имена (или адреса) сервисов, наименования классов онтологии, к которым привязан БП, а на выходе образуется множество атрибутов, каждый из которых несет какую-то информацию, описывающую экземпляр БП. Все сведения о текущем состоянии БП при завершении работы сохраняются в базе данных.
BP Class
PK Ш.
пате
I
Ï
BP_Flow
РК id
FK1 id_bp
пате
guid
guid beg in
guid end
parentguid
font width
fontcolor
width
color
isSequence
BP Attributes
PK id
FK1 name Id., class
BP
PK id
name
author
guid
date creation
date isp
comment
status
BP _Efement
PK 14
FK1 id_bp
name
name
index
type
guid
parenlguid
status
date Jsp
note
top
left
widtti
height
color
fontcolor
fiilcoior
penwidth
fontwidth
id_ver
FK2 id_cfass
FK3 id service
BP Attr _SaveValue
PK Id
FK1 id_attr ref_code date _ réf..code
BP_Servsce
PK M
name Щ
1
BP_Servi«!_At!r
PK Id
FK1 id service name type
I
BP Service Attr SaveValue
PK M
FK1 id_attr valus
BP Row Point
PK jd
X
У
number
FKl id flow
Рис. 3. Структура базы данных для хранения элементов экземпляра бизнес-процесса
Для определения динамических переменных используют возможности программного продукта [6], где при описании элементов БП можно указать ссылку на класс справочной системы и, тем самым, определить дополнительный набор атрибутов. Благодаря использованию сервисов также возможно определить новые переменные или изменить значения существующих, в результате чего каждый элемент БП может быть описан индивидуальными атрибутами. Т. о., на момент завершения элементы описываются набором атрибутов, каждый из которых участвует в описании экземпляра БП.
На рис. 2 показано формирование описания БП с помощью атрибутов, где А - множество динамических атрибутов (определенных в результате указания принадлежности классу справочной системы), полученных в момент выполнения БП.
В реальной системе элементы БП описывается не только динамическими, но и статическими атрибутами Астат={а^а/Ь astat2,..., astatp}, а также константами - K{const1, ..., constn}. Таким образом, при полном описании элемента на выходе получим множество атрибутов и констант, характеризующих выделенный элемент конкретного экземпляра БП:
Авых={А, Астат, К}. (*)
Рассмотрим БП Б, который состоит из п этапов, каждый этап может быть простым или сложным (содержит вложенный элемент или подпроцесс). Каждый элемент описывается множеством атрибутов (*).
Среди атрибутов Астат БП отдельно выделяем атрибуты:
• ах{: переменная статуса, которая определяет состояние соответствующего /-го элемента; а/1е{0,1} где 0 - задача не выполнена, 1 - задача выполнена;
• а/2: переменная, определяющая дату окончания выполнения задачи /-го элемента;
• а/3: переменная, которая представляет собой значения цвета /-го элемента.
Таким образом, предлагаемая система БП, содержащая конечное множество этапов БП - Б {Б1,...,Бп}, описывается набором атрибутов Б1{А1вых1, ..., А1вых£}, ..., Бп{Апвых1, ..., Апвыхт},
где А1вых1, ..., А1вых£ ... Апвых1, ..., Апвыхт являются простыми или вложенными элементами, определяемые соответствующими атрибутами (*). Каждый БП описывается множеством атрибутов: Б{а1ь а12, а13, ...,а^а/7р1, сотйь сомЙ2, ..., сотИп1,...а1ь..., ап1, ап2, ап3, astatnpn, сотЩ, сотШ2, ..., соп^п„„,...,ап„,}.
Для решения задачи мониторинга и определения состояния БП в интересующий момент времени предлагается использовать алгоритм, рис. 4.
Алгоритм состоит из шести основных шагов: Шаг 0. Если Б/=0, то переход на шаг 1, иначе найти А//е Б/ и переход на шаг 1. Шаг 1. Если ау!=1 (задача выполнена), то а/3=^ (где / - новое значение) и переход на шаг 3, иначе переход на шаг 2. Шаг 2. Если а'2>текущее время для невыполненных задач и а/'1=0, то а'3=красный цвет, переход на шаг 5. Иначе переход на шаг 4.
Рис. 4. Алгоритм определения состояния БП на диаграмме
Шаг 3. Если}<т, то переход на шаг 1, иначе шаг 4. Шаг 4. Если Кп, то переход на шаг 0, иначе переход на шаг 5. Шаг 5. Алгоритм завершен.
Предложенный алгоритм позволит с использованием специальных процедур, реализованных на стороне хранилища данных, на основе регистрируемых в БД значений соответствующих объектов определять не только текущее состояние интересуемого экземпляра БП (выполнен, не выполнен, в работе) и представлять их графически с различной цветовой заливкой, но и получить доступ ко всем его атрибутам, на основании значений которых можно принимать оперативные управленческие решения и собирать статистику.
Выводы
Рассмотрен подход к задаче повышения эффективности управления лечебной деятельностью с ис-
СПИСОК ЛИТЕРАТУРЫ
1. Иванов В.В., Богаченко П.В. Медицинский менеджмент. - М.: ИНФА-М, 2007. - 256 с.
2. Сальников А. Oracle BPEL Process Manager 2.0 [Электронный ресурс]. - режим доступа: http://www.oracle.com/glo-bal/ru/ip/10g/as/bpel.html. - 05.10.2009.
3. Пономарев А.А. Нгуен Хоанг Чинь. Редактор бизнес-процессов // Технологии Microsoft в теории и практике программирования: Труды VI Всерос. научно-практ. конф. - Томск, 2009. -С. 328-330.
4. BPEL4People specification version 1.0-2007 [Электронный ресурс]. - режим доступа: http://www.oracle.com/technolo-gy/tech/standards/bpel4people/index.html. - 05.10.2009.
пользованием проектирования и мониторинга бизнес-процессов. При мониторинге бизнес-процессов повысится информационная составляющая лечебного процесса за счет использования:
• языка BPEL;
• инструмента унифицированного описания шаблонов;
• алгоритма расширенного описания бизнес-процессов совместно с Web-сервисами и справочной системы для получения динамических атрибутов.
Интеграция существующей медицинской информационной системы лечебно-профилактического учреждения с предложенным программным продуктом позволит без значительных затрат качественно повысить её возможности, в частности, унифицировать бизнес-процессы, выполнить сопряжение данных об объекте в случае использования разнородных источников за счет использования сервисов.
5. Health Level Seven [Электронный ресурс]. - режим доступа: http://www.hl7.org/. - 05.10.2009.
6. Пономарев А.А. Нгуен Хоанг Чинь. Разработка программного обеспечения и его компонентов для описания бизнес-процессов // Труды III университетской научно-практической конференций иностранных студентов, магистрантов и аспирантов ТПУ: Сб. тезисов докл. - Томск: Изд-во ТПУ, 2009. -С. 142-143.
Поступила 06.10.2009 г.
