 | Уровень сложности: средний Джин Вонг, бизнес-архитектор, IBM
05.10.2009 Организации в сфере здравоохранения проявляют большой интерес к ИТ-решениям на основе сервис-ориентированной архитектуры (SOA), способным существенно облегчить процесс перестройки отрасли. Однако согласовать средства, предлагаемые для осуществления таких проектов, с потребностями бизнес-пользователей - непростая задача. Анализ позиций и требований представителей бизнеса, привязка их к технологическим средствам - чрезвычайно важный этап внедрения SOA. На примере сети обмена информацией в сфере здравоохранения статья иллюстрирует методику и рекомендуемые подходы к вопросу удовлетворения таких потребностей с использованием ИТ-инструментария, обеспечивающего соответствие технологических нововведений в процессе внедрения SOA целям отрасли.
Трудности при согласовании ИТ-средств с задачами обмена медицинской информации
Требования к системам обмена информацией в сфере здравоохранения неуклонно растут с тех пор, как правительство США приняло стратегическую инициативу повсеместного внедрения к 2014 году электронных медицинских карточек (см. ссылку на статью "Буш пропагандирует план построения электронной медицины" в разделе Ресурсы). Обмена медицинской информацией между отдельными организациями в сфере здравоохранения, безусловно, недостаточно для удовлетворения потребностей пациентов и достижения адекватного уровня оказания медицинских услуг. Для улучшения качества заботы о пациентах, снижения расходов, увеличения продуктивности и эффективности оказываемой медицинской помощи необходимо, чтобы информацией в сфере здравоохранения можно было беспрепятственно обмениваться на уровне территориальных сообществ и целых штатов. Кроме того, для улучшения состояния здравоохранения в общегосударственном масштабе — в сфере контроля заболеваний и эпидемий — медицинские данные должны быть легко доступны по всей стране, на национальном и даже международном уровне (см. рисунок 1). Имевшая место несколько лет назад вспышка атипичной пневмонии показала необходимость оперативного доступа к медицинской информации (см. ссылку на сайт Всемирной организации здравоохранения в разделе Ресурсы).
| |
Рисунок 1. Сеть обмена медицинской информацией
Вместе с тем не стоит недооценивать трудности, возникающие при построении столь разветвленной сети обмена медицинской информацией. Необходимо, чтобы эффективность обмена информацией удовлетворяла потребности всех, кто в нем участвует: пациентов, поставщиков медицинских услуг, медицинских страховых компаний, правительства и других заинтересованных организаций. В то же время необходимо обеспечить тесное сотрудничество всех сторон, чтобы их услуги были доступны всем участникам сети, а также установить общеотраслевые стандарты для интеграции и использования медицинских данных.
Между имеющейся технологией и требованиями к полноценному обмену медицинской информацией имеется ряд несоответствий:
- С точки зрения информационных технологий: к моменту организации столь масштабного информационного обмена многие ИТ-группы уже будут иметь разработанные компоненты и ресурсы, предназначенные либо для внутреннего применения, либо для использования в соответствии с принципами open source. Это означает, что объемы технических средств будут продолжать расти, но отсутствие общей библиотеки, где все эти средства и ресурсы были бы собраны и упорядочены, может привести к необходимости заново изобретать уже известные технологии.
- С точки зрения бизнес-стратегии: требования к сети обмена медицинской информацией устанавливаются бизнес-пользователями в соответствии с их потребностями по принципу "от общего к частному". Однако многие из этих людей не вполне осведомлены о SOA-технологиях, на которые может опираться такая сеть. Из-за этого возникает разрыв между бизнес-стратегией и стоящей за ней технологией, который продолжает быть основным препятствием для многих SOA-инициатив по преобразованию сферы здравоохранения.
- Многие обычные бизнес-требования к разработкам в сфере обмена медицинской информацией удовлетворяются на различных уровнях сети в разных проектах, что порождает дублирование усилий по их сбору и удовлетворению.
Рассмотрим пример, иллюстрирующий необходимость единых стандартов. Сеть обмена медицинской информацией должна позволять регистрировать и идентифицировать пациента, а также записывать и хранить его данные. Без единого комплекса требований к ПО такая процедура идентификации и сбора данных потребует дополнительных шагов и трудозатрат — иначе возможна потеря каких-нибудь важных сведений. Кроме того, необходимо, чтобы требования к ИТ-составляющей, обусловливающие эффективную работу такой системы, согласовывались с требованиями со стороны бизнеса.
Как сообщается в ряде статей и обзоров, недостатки в определении и удовлетворении требований к программным продуктам часто ведут к ошибкам в разработке ИТ-проектов (см. ссылки на статьи "Почему отказывает программное обеспечение" и "Сокращение времени разработки благодаря средствам и методикам SDL" в разделе
Ресурсы). Даже при том, что аккуратная инженерия требований существенно упростилась благодаря прогрессу соответствующего ПО (например, IBM® Rational® RequisitePro®), и полезность ее для разработки решений в сфере здравоохранения общепризнанна, во многих проектах требования обрабатываются вручную, невзирая на высокие трудозатраты и невозможность полностью реализовать их потенциал (см. ссылку на статью "Технологии ПО в сфере здравоохранения" в разделе
Ресурсы). Такое различие между бизнес-требованиями в сфере здравоохранения и требованиями технологии, на которую этот бизнес опирается, проиллюстрировано на рисунке 2. Структурная фиксация и анализ требований, привязка требований к имеющимся ресурсам и управление их динамичными взаимоотношениями — мероприятия, которыми невозможно пренебречь в цикле разработки ИТ-решений. Именно такого рода трудности и пытается разрешить SOA.
Рисунок 2. Разрыв между бизнес-целями в сфере здравоохранения и имеющимися в отрасли ИТ-ресурсами
В данной статье описывается решение, призванное уменьшить этот разрыв при помощи методов и средств инженерии требований.
Удовлетворение бизнес-требований и внедрение SOA
Многие ИТ-проекты терпят неудачу из-за плохого менеджмента требований (см. ссылки на статьи "Почему отказывает программное обеспечение" и "Работа с новыми программными технологиями: структурная основа переноса технологий" в разделе Ресурсы). Среди наиболее распространенных причин неудачного менеджмента требований — нереалистичные или недостаточно четко обозначенные цели проекта и плохо определенные системные требования. Разработчикам очень легко увлечься "технологией преследования" вместо того, чтобы сосредоточиться на внедрении системы, соответствующей потребностям бизнеса. Потребность в инженерии привела в последнее время к возникновению в сфере разработки программных продуктов настоящей новой области деятельности, которая продолжает оставаться в центре внимания сообщества разработчиков (см. ссылки на книги и статьи "Фундаментальная природа мероприятий по инжинирингу требований как процесса принятия решения" и "Фиксация требований для быстрой разработки приложений" в разделе Ресурсы). Появляется все больше коммерческого ПО для обработки требований в процессе разработки ИТ-систем (см. ссылку на статью "Инжиниринг требований для систем, основанных на коммерчески доступных приложениях" в разделе Ресурсы). Но даже несмотря на такое повышенное внимание и на повсеместное внедрение SOA для нужд разработки ИТ-решений, практика систематической обработки требований к SOA-решениям в индустрии здравоохранения не столь распространена. Из-за сложного характера бизнес-процессов в этой отрасли и данных, с обменом которыми сопряжены эти процессы, фиксация и анализ требований оказываются здесь весьма затруднены.
SOA — это стиль ИТ-архитектуры, поддерживающий сервисную ориентированность и дающий возможность интегрировать осуществляемые вами бизнес-процессы в виде связанных друг с другом сервисов, способствуя таким образом маневренности вашего бизнеса. Одна из основных целей SOA — позволить организациям быть достаточно гибкими и восприимчивыми для того, чтобы внедрять новые бизнес-стратегии и производить новые услуги, которые бы соответствовали потребностям, вызванным динамичным характером сегодняшнего бизнеса (см. ссылку на статью "Возможности сервис-ориентированной архитектуры: бизнес-ценность, планирование и "дорожная карта" предприятия" в разделе Ресурсы). Цикл реализации SOA начинается с осмысления бизнес-целей и требований путем привлечения к разработке сервисов специалистов в той или иной предметной области. Необходимость этого обусловлена тем, что на этом этапе процесса внедрения SOA основное внимание уделяется последовательному итеративному процессу реализации бизнес-потребностей.
Менеджмент бизнес-требований — первый шаг цикла реализации SOA. Это ключевая отправная точка построения систем обмена медицинской информацией. Такой подход позволяет добиться того, что цели и требования к сервисам, так или иначе задействованным в сфере обмена медицинской информацией, становятся общими для всех заинтересованных сторон и корректно соблюдаются.
Формирование модели, согласующей требования к обмену медицинской информацией с ИТ
Рассмотрим этапы, из которых состоит привязка бизнес-требований к опорной технологии, при помощи которой реализуется SOA-решение:
Этап 1. Установление многократно используемого уровня, который привязывает бизнес-возможности обмена медицинской информацией к ИТ-ресурсам
Метод, описанный в данной статье, предполагает использование ПО для менеджмента требований (в данном случае Rational RequisitePro) в качестве средства учета, анализа и инженерии требований. В Rational RequisitePro необходимо создать компонентный слой, соответствующий разрабатываемому решению. Для этого нужно:
- Учесть, организовать и приоритизировать все имеющие отношение к здравоохранению функциональные и нефункциональные возможности, требующиеся Rational RequisitePro для обеспечения интероперабельности в сфере здравоохранения.
- Задействовать и организовать имеющиеся ИТ-средства, способствующие интероперабельности в сфере здравоохранения — компоненты решений, продукты, сервисы. Происходящие из разных источников, эти средства имеют самый различный характер — open source-средства, отраслевые стандарты, внутрикорпоративные средства, средства бизнес-партнеров, ИТ-средства общего характера.
- Воспользоваться функцией трассируемости в Rational RequisitePro для сопоставления всех компонентов-возможностей ИТ-средствам, способным эти возможности реализовать.
RequisitePro действует как реляционный репозиторий, хранящий все функциональные и нефункциональные возможности, а также опорные средства для реализации сети обмена медицинской информацией. Тем самым устанавливается промежуточный уровень, который может быть использован для устранения разрыва между более высоким уровнем бизнес-требований и уровнем технических средств. Однажды установленный, этот уровень может повторно использоваться для различных проектов, предполагающих использование средств, специфичных для сферы здравоохранения.
Этап 2. Учет бизнес-требований, исходящих от сторон, участвующих в обмене медицинской информацией
Инициатив по обмену медицинской информацией существует множество — как уже реализованных, так и разрабатываемых на уровне местных сообществ, штатов и регионов. Подобные инициативы осуществляются под управлением таких организаций, как Региональная организация медицинской информации (Regional Health Information Organization, RHIO), Национальная сеть медицинской информации (National Health Information Network, NHIN), а также разнообразных проектов информационного обмена в сфере здравоохранения, финансируемых из частных источников. Вероятно, многие из этих проектов нацелены на одни и те же требования и, соответственно, нуждаются в одной и той же технологии. Так, например, для всех этих инициатив необходим безопасный обмен данными пациента в электронном виде. Другой пример — использование для идентификации больных Главного каталога пациентов (Master Patient Index). И тем не менее организации до сих пор тратят огромные усилия, создавая часто используемые в различных системах комплексы требований традиционным образом, не задумываясь о том, что кто-то уже, быть может, проделал эту работу раньше или что этой информацией можно поделиться к общей выгоде. Таким образом, информационная сеть здравоохранения только выиграет от создания с помощью средств инженерии ПО пула общих требований, которые затем могли бы быть использованы повторно.
В процессе разработки ИТ-решений в сфере здравоохранения бизнес-цели, как правило, формулируются на более высоких уровнях ответственными за стратегию, после чего специалисты в предметной области, бизнес-аналитики и владельцы бизнес-процессов вырабатывают детализированные бизнес-требования. Чтобы решения, предназначенные для тех или иных инициатив соответствовали бизнес-целям, эти требования должны приниматься во внимание таким образом, чтобы каждое из них поверялось и ставилось в соответствие одной или нескольким бизнес-целям более высокого уровня. На рисунке 3 показано, как бизнес-требования к обмену медицинской информацией консолидируются и приоритизируются с помощью Rational RequisitePro.
С помощью такого метода может быть осуществлена не только фиксация, оценка и согласование этих требований. Данный программный продукт позволяет также управлять ими с помощью средств менеджмента изменений — осуществлять управление версиями, отслеживать историю изменений и коллективных обсуждений.
Описанные выше мероприятия создают необходимую базу требований для повторного использования, согласованную с общим направлением проекта. Именно это иллюстрирует рисунок 3.
Рисунок 3. Консолидация и приоритизация бизнес-требований к информационному обмену в сфере здравоохранения
Этап 3. Привязка требований к функциональным возможностям
При наличии многократно используемого технологического уровня, сформированного на
этапе 1, и уровня бизнес-требований, сформированного на этапе 2, согласование бизнеса и технологии существенно упрощается. Нам остается теперь связать каждое из требований с ИТ-возможностью, которая может это требование удовлетворить. Например, если требуемая бизнес-функция — это запрос карточки пациента, бизнес-архитектору естественно ассоциировать ее с хранилищем клинических документов — источником данных, к которому обращен запрос. В то же время осуществление этой функции в контексте соблюдения требований регулирующих органов потребует при запросе клинического документа сервисов аудита. Рисунок 4 иллюстрирует такую привязку требований к ИТ-возможностям в сфере здравоохранения.
Рисунок 4. Привязка бизнес-требований к ИТ-возможностям в сфере здравоохранения как пример связи бизнеса и технологии
Этап 4. Прозрачная привязка бизнес-целей и требований к технологическим средствам
После того как отношения между требованиями и ИТ-возможностями установлены, необходимо сделать следующий шаг — аккуратно "склеить" уровни бизнеса и технологии, как показано на рисунке 6. Поддерживая такую иерархию, легко видеть, на какие бизнес-требования опирается та или иная цель, с помощью какой технологии и каких средств она реализуется (см. рисунок 5).
Рисунок 5. Установление отношений между слоями делает возможным прозрачное трассирование от бизнес- к ИТ-представлениям
Рисунок 6 демонстрирует древовидную схему того, как высокоуровневая цель регистрации вспышки болезни поддерживается и реализуется начиная с уровня технологии через бизнес-уровень. Среди используемых технических средств можно видеть open source-компоненты, такие как Audit Trail и Node Authentication Profile от Integrating the Healthcare Enterprise (IHE ATNA), и Audit Trail and Node Authentication client от Open Health Framework (OHF ATNA).
Рисунок 6. Бизнес-цели информационного обмена в здравоохранении прослеживаются в Rational RequisitePro вплоть до ИТ-средств отрасли
Использование описанных в настоящей статье модели и методики позволяет значительно упростить и поднять уровень абстрагирования требований, которые в результате могут быть распространены на весь цикл разработки. В результате упрощается общение между владельцами бизнеса и техническими работниками, что, в свою очередь, способствует корректной трансляции и исполнению требований, а, значит, — производству продукта с необходимыми характеристиками (см. ссылку на статью "Согласование информационной технологии с задачами обмена медицинской информацией" в разделе Ресурсы). Кроме того, в системах, построенных по принципам SOA, такая инженерия требований позволяет распространить их на весь цикл разработки. Это облегчает задачу системного дизайна, конструирования и тестирования, позволяет создавать высококачественные продукты с минимумом материальных и временных затрат.
Заключение
Устранение разрыва между оказанием медицинских услуг и внедрением новых технологий — важнейшая из целей, на достижение которых направлено внедрение ИТ для усовершенствования медицинских практик. SOA представляет собой эффективный подход к решению этой задачи в контексте создания систем обмена медицинской информацией. Построение SOA исходя из задач бизнеса — это пошаговый подход, учитывающий бизнес-цели, трудности и реалии сферы здравоохранения. Подготовка такой системы к использованию SOA начинается с осмысления бизнес-потребностей с последующим ответом на вопрос, каким образом и какая технология может эти потребности удовлетворить. При помощи имеющихся на рынке готовых программных продуктов и описанной здесь методики вы легко сможете увязать требования со стороны бизнеса с соответствующими технологическими потребностями и подойти к ним систематическим образом. Вы также сможете увязать бизнес-требования с ИТ-возможностями и прозрачным образом соотнести их со средствами и продуктами, способными эти требования удовлетворить. Наконец, требования и средства, собранные в этой модели, могут быть повторно использованы во многих проектах в сфере здравоохранения, где важную роль играет обмен информацией. При таком подходе разработка проектов отталкивается от потребностей бизнеса, благодаря чему созданные решения более полно соответствуют бизнес-целям и в полной мере используют имеющиеся ИТ-ресурсы, тем самым снижая себестоимость проектов.
Слова благодарности
Автор хотела бы поблагодарить доктора Бена Абаму, Ричарда Адамса, доктора Энн Олдос, Эда Макко, д-ра Аджая Астхану, Леонарда Ли, Хаутона Агили и д-ра Прасанну Атму за их работу в команде и поддержку, направленные на определение стратегии и видения будущего.
Ресурсы Научиться
- Оригинал статьи "Align IT with a health information exchange for SOA solutions" (EN).
- Статья
"Буш пропагандирует план построения электронной медицины"
в газете The Washington Post представляет собой хороший обзор планов в области обмена медицинской информацией.(EN)
- Всемирная организация здравоохранения координирует мероприятия по обработке медицинской информации — в статье "ВОЗ координирует международные усилия по диагностике и лечению атипичной пневмонии".(EN)
- Прочтите статью Р. Н. Шаретт "Почему отказывает программное обеспечение" [PDF].(EN)
- Прочтите статью А. Астхана, Х. Ван и Б. Абама "Технологии ПО в сфере здравоохранения"(EN).
- Прочтите статью Т. Д. Корсон и В. К. Вайшнави "Работа с новыми программными технологиями: структурная основа переноса технологий".(EN)
- Прочтите статью "А. Аурум и К. Вохлин "Фундаментальная природа мероприятий по инжинирингу требований как процесса принятия решения".(EN)
- Ознакомьтесь со статьей "М. Ива "Фиксация требований для быстрой разработки приложений".(EN)
- Прочтите статью "С. Роллан "Инжиниринг требований для систем, основанных на коммерчески доступных приложениях".
- Прочтите статью "Н. Биберштейн, С. Бозе, М. Фьямант, К. Джоунз, Р. Шах. "Возможности сервис-ориентированной архитектуры: бизнес-ценность, планирование и "дорожная карта" предприятия".(EN)
- Раздел SOA и Web-сервисов на сайте IBM developerWorks содержит сотни полезных статей, а также руководств по разработке приложений Web-сервисов — начального, среднего и профессионального уровня.
- Играйте в SOA-Песочнице IBM! Повышайте свою квалификацию, получая непосредственный практический опыт в точках входа IBM SOA.(EN)
- На сайте IBM SOA вы найдете обзор SOA и узнаете, как IBM может помочь вам освоиться в этой области.(EN)
- Следите за техническими событиями и Web-трансляциями на developerWorks. В частности, посетите следующие технические брифинги, посвященные SOA и Web-сервисам:(EN)
- Ищите книги по этой и другим техническим темам в
книжном магазине Safari.
- Ознакомьтесь с краткой демонстрацией на тему Web-сервисов по запросу.(EN)
Получить продукты и технологии
Обсудить
Об авторе | | | Джин Вонг работает в компании IBM в качестве бизнес-архитектора и специалиста по решениям для проекта IBM Healthcare and Life Sciences Strategic Initiatives. Джин работала в отраслях промышленности, связанных с информационными технологиями и биологическими науками, а также в научных учреждениях в области научных исследований и разработок, разработки ПО, образования и консультирования. В настоящее время ее усилия направлены на ликвидацию разрыва между бизнесом и ИТ, а также на преобразование бизнес-процессов в отраслях здравоохранения и биологических наук для нужд сервис-ориентированного предприятия. Она имеет степень доктора наук в области химии. |
Выскажите мнение об этой странице
| |
