Approaches to creation of the automated informationanalytical system of diagnostics and forecasting professional neurotoxicosis.pdf Производственный контакт с нейротропными веществами 1 - 2 класса опасно-сти создает угрозу развития у работников химических предприятий профессио-нальных поражений мозга, характеризующихся невозможностью полного восста-новления здоровья и в постконтактный период [1, 2], что обусловливает важностьранней диагностики профессиональных нейроинтоксикаций (ПНИ) с целью свое-временного осуществления медико-социальных реабилитационных мероприятий.Клиницисту необходимо не только определить нозологическую форму, при кото-рой имеют место непротиворечивые отношения между множеством наблюдаемыхпризнаков (нарушений в органах и системах) и интегрирующим их понятием ди-агноза, но и учесть уровни производственных факторов, с которыми каузальносвязаны эти признаки. Диагностика профессиональных нейроинтоксикаций -сложный и многоступенчатый процесс, требующий значительных временных,финансовых и производственных затрат, сокращение которых может быть дос-тигнуто разработкой и внедрением компьютерной информационной технологии(ИТ) поддержки клинико-диагностического процесса.Создание информационных систем в области медицины и автоматизациябизнес-процессов клинических учреждений является на сегодня научно-инженерной областью, характеризующейся разнообразной и развивающейсяпрактикой [3]. Внедрение информационных технологий в медицине охватываетрегистрационно-учетные, вычислительные и аналитические функции медицин-ской структуры. В силу концептуальных трудностей, с которыми сталкиваютсяподходы к обобщению, упорядочению и формализации в сфере медицинской66 А.Г. Иванов, М.П. Дьяковичдиагностики, аналитические функции нуждаются в алгоритмическом и про-граммном обеспечении систем искусственного интеллекта, в частности эксперт-ных систем. Опыт применения систем данного рода в медицине достаточно по-зитивен, изучен и обобщен в иностранной литературе [4 - 6]. Отечественнаяпрактика столь же динамично развивает идеи применения средств искусствен-ного интеллекта в медицине, включая выбор, разработку, тестирование и оценкуприменимости алгоритмов и методов к частным задачам диагностики и меди-цинского прогноза [7, 8]. В актуальных отечественных разработках описывают-ся подходы к программной архитектуре и инфраструктуре медицинской инфор-мационно-аналитической системе (ИАС) [9]. В то же время, вопросы, касаю-щиеся разработки создания ИТ, позволяющих оптимально сочетать опыт кли-ницистов в области профессиональной патологии с возможностями автоматиза-ции сбора и интерпретации диагностических данных, а также создании баз зна-ний, позволяющих формировать алгоритмы дифференциальной диагностики, вдоступной нам литературе освещены недостаточно.Проблема создания медицинских ИАС является частью общей проблемы, тре-бующей решения сопутствующих задач, связанных с недостаточным уровнемкомпьютеризации медицинской практики и отсутствием навыков работы с подоб-ными системами у клиницистов. Трудность дифференцированной диагностики,высокая социальная значимость принятия врачами верного решения о признаниисвязи с нейроинтоксикации с производством, прогноза течения заболевания, обу-словливает необходимость разработки ИТ, включающей поддержку и техниче-ское консультирование клиницистов-профпатологов при принятии диагностиче-ских решений. Целью настоящего исследования явилась разработка подходов ксозданию автоматизированной информационно-аналитической системы диагно-стики и прогнозирования профессиональных нейроинтоксикаций, включающиханализ требований к ИАС, ее проектированию, разработке экспертной системы(ЭС) в ее составе и апробацией в клинических условиях.1. Результаты и их обсуждениеСоздание ИАС, включающей и координирующей работу регистрационных ианалитических сервисов, - нетривиальная задача. Сложность ее заключается вслабой структурированности медицинской предметной области, необходимостипредварительных исследований эвристических экспертных знаний и алгоритмапрогнозирования ПНИ, интеграции до 20 смежных функциональных процессов,развертывания прикладных сервисов с включением 2 классов пользователей, дей-ствующих на границе системы (математик и когнитолог). Анализ прецедентов по-зволил определить типологию функциональных процессов ИАС (см. табл.1).Сбор и анализ требований к ИАС выполнялся дифференцированно, для каждо-го из выявленных пользовательских классов (см. табл.2).Создание ИАС, обеспечивающей реализацию описываемой ИТ, требует орга-низации жизненного цикла (ЖЦ) на основе модели, применимой для распреде-ленной многопользовательской автоматизированной системы и характеризуемойакцентированной ролью этапов анализа требований и проектирования. Оценкаприменимости существующих процессов разработки программного обеспечения(ПО), проведенная с целью выбора эталонной модели системного ЖЦ, позволилаопределить в качестве таковой процесс RUP (Rational Unified Process), имеющийопределенные соответствия нормативным характеристикам ИАС [10 - 12].Подходы к созданию автоматизированной информационно-аналитической системы 67Т а б л и ц а 1Типология функциональных процессов ИАС№ Наименованиепрецедента Функциональный процессГраничные процессы1 Извлечение знаний Мета-анализ диагностики ПНИ, формализация эвристическихзнаний экспертов2Прием-передачаинформациипользователейПрием и регистрация данных социально-гигиенических ис-следований, проводимых врачами-гигиенистами и социолога-ми, результатов медицинских осмотров работников невроло-гами-профпатологамиВнутренние процессы1 Использование ЭС Применение ЭС врачом-профпатологом с целью диагностикии прогнозирования ПНИ у отдельного пациента2Регистрациямедицинскойинформации*Деятельность врачей-клиницистов по выполнению диагности-ческих процедур, установлению и регистрации частных диаг-нозов3 Ведениемедицинской БДПрименение методов многомерного анализа данных, верифи-кация сведений, поступающих в систему4 Поддержкабазы знаний ЭСДеятельность когнитолога по модификации фактов, правил-продукций, лингвистических переменных, управлению резер-вированием базы знаний5ПоддержкапрограммнойсистемыДеятельность разработчика-сопроводителя, реализующаяуправление программными компонентами, поддержка работыпользователей6 АдминистрированиеИАСДеятельность системного администратора по управлениюдоступа к программно-аппаратной инфраструктуре ИАС иподдержке работы пользователей в системеП р и м е ч а н и е . * Соответствующий функциональный процесс развертывается в рамкахкаждой из 11 диагностических __________процедур, касающихся обследования основных систем ор-ганизма.Т а б л и ц а 2Классификация функциональных ролей в ИАС№ Классыпользователей Функции1 2 3Внутренние пользователи1 Врач-профпатолог Установка диагноза ПНИ2 КлиницистУзконаправленное исследование организма пациента и уста-новление частного диагноза в соответствующей области ме-дицины3 Когнитолог Создание и поддержка базы знаний ЭС, привлечение и фор-мализация знаний экспертов4 Математик Верификация поставляемых в ИАС медицинских данных, иханализ с помощью методов многомерного анализа5 СистемныйадминистраторПостоянная техническая поддержка ИАС, оказание консуль-тативной помощи пользователям при работе в ИАС6 Разработчик Создание, модификация и поддержка ИАС на уровне кодовприложений и объектов баз данных68 А.Г. Иванов, М.П. ДьяковичП р о д о л ж е н и е т а б л . 21 2 3Внешние пользователи*7 Врач- гигиенист Анализ и оценка условий труда8 Социолог Оценка социально-бытовых условий жизни и социально-психологических характеристик работников9Невролог-профпа-толог поликлини-ческого __________отделенияСкрининговое обследование работающих, подготовка предва-рительного заключения по результатам углубленного меди-цинского осмотра работников, передача его в ИАС10Эксперт в областипрофпатологиинервной системыИсточник эвристических знаний для ИАС, не является ее ре-гулярным пользователемП р и м е ч а н и е . * Контакт с программной системой опосредован взаимодействием спользователями классов 3, 4.Развитие ИАС имеет итеративный характер. Перспективный план созданияИАС предполагает результатом первой итерации ЖЦ получение и внедрение на-учного прототипа, использующего контексты пациентов, которые формируютсякогнитологом (инженером по знаниям), исходя из информации о состоянии орга-нов и систем организма, поставляемой клиницистами. На второй и следующихитерациях предусмотрены ввод в действие и интеграция в ИАС регистрационныхподсистем для узких медицинских исследовательских процедур, которые будутиспользовать автоматизированное формирование контекстов пациентов. Даль-нейшее развитие системы даст возможность реализовать экспертную поддержкуустановления частных диагнозов на основе обследований пациентов клинициста-ми. Таким образом, будет расширена область применения сервиса ЭС. Примене-ние компонентной архитектуры лежит в основе архитектурной идеи ИАС. В ка-честве компонентов в проекте были рассмотрены единицы базового ПО, совмес-тимого на уровне интерфейсов программирования, и программные компонентныекаркасы. На основе анализа свойств современных программных средств ЭС былопринято решение о совместном использовании оболочки ЭС «Jess 7»[13] и пакетаобработки нечеткой информации «NRC FuzzyJ Toolkit» [14], реализованных вформе комплексов JAR(Java ARchive)-библиотек Java-классов и представляющихсовместимые API (Application Programming Interface) в качестве стандартного пу-ти интеграции в Java-приложения. Визуальное моделирование ПО с применениемязыка UML (Unified Modeling Language) - стандартная и неотъемлемая дисципли-на RUP, обеспечивающая требуемый качественный уровень проектной информа-ции при построении моделей.Управление требованиями представляет особую важность. Значимость этапованализа и проектирования в процессе создания ИАС были определены результа-тами исследования проблемной области. Предметом анализа и важным управ-ляющим ресурсом для ЖЦ ИАС являются требования пользователей каждого изклассов.Реализация дисциплины управления требованиями включает анализ графовыхмоделей требований к создаваемой системе, позволяющий выявить и упорядочитьпо степени значимости ряд базовых функциональных и эксплуатационных харак-теристик ИАС. Собранные требования классифицируются по признакам принад-лежности соответствующим типам пользователей и распределяются на категориифункциональных и эксплуатационных, на основании которых, наряду со сводомПодходы к созданию автоматизированной информационно-аналитической системы 69требований, составляющих внешнее описание программной системы, выполняет-ся построение моделей функций и качества ИАС. Для усовершенствования такихпостроений и снятия возможных противоречий при переходе от свода требованийк моделям функций и качества ИАС, была построена формальная модель, вклю-чающая построение и анализ двух основных графовых моделей-соответствий:«Классы пользователей - примитивы качества» и «Классы _____пользователей - функ-ции программной системы». Анализ моделей позволит провести ранжирование позначимости функциональных и эксплуатационных характеристик ИАС.Модель «Классы пользователей - примитивы качества» была построена в це-лях формализации соответствия потребностей пользователей ИАС составу при-митивов качества программ. Иллюстрация построения модели на основе требова-ний, собранных на начальной итерации ЖЦ ИАС, представлена на рис. 1.Рис. 1. Формальная модель «Классы пользователей - примитивы качества»Взвешенный неполный двудольный граф G6,17 со множествами вершин A(классы непосредственных пользователей ИАС) и B (примитивы качества про-грамм по номенклатуре [15,16]) моделирует соответствие q: AЎжB, являющеесянефункциональным отображением A в B. Направление упорядоченности вершин- сверху вниз задано схематически. Любое ребро (ai, bj) символизирует наличие втребованиях пользователей класса ai потребности в некоем качественном свойст-ве ИАС, представляемом примитивом bj. Над каждым символом ai приведен нату-ральный ряд, соответствующий весам ребер, инцидентных вершине ai, ребра упо-рядочиваются также - сверху вниз. Весовой коэффициент Ґшi,k k-го ребра,1 ЎВ k ЎВ Ґс(ai), 1 ЎВ I ЎВ 6, где Ґс(ai) - степень вершины ai, соответствует количествувыделенных единиц потребности пользователя класса ai в свойстве качественного70 А.Г. Иванов, М.П. Дьяковичпримитива bj. Под единицей потребности здесь следует понимать уникальноеупоминание описаний данного качественного свойства в контексте некоей макси-мально конкретизированной функции, действия или желаемой характеристикиИАС, принимаемые здесь атомарными. Для всех единиц потребностей значимостьпринимается равнозначной. Каждое выявленное не дублированное описание уве-личивает значение соответствующего коэффициента Ґшi,k на 1. Вычисление показа-теля совокупной значимости для любого из примитивов качества( )( )sum ,1bjj j kkV bҐс== ҐТ Ґш , 1 ЎВ k ЎВ Ґс(bj), 1 ЎВ j ЎВ 17,где Ґс(bj) - степень вершины, соответствующей данному примитиву качества, Ґшj,k -весовой коэффициент k-го ребра, инцидентного вершине bj, относительно каждойвершины в B, дает ряд значений (рис. 2), иллюстрирующих эталонную значи-мость качественных примитивов, позволяющих определить приоритетные на-правления в обеспечении качества ИАС и выявить необходимость в добавлениинедостающих требований. Важно, что модель будет нереалистична, если из сводатребований предварительно, на неформальном этапе анализа, не будут исключеныпротиворечия и неточности.Рис. 2. Распределение формальной значимости по требованияммежду примитивами качества в проекте ИАСТретье подмножество вершин C символизирует стандартные критерии качест-ва и вводится только для отображения соответствия примитивов качества - кри-териям. Никакие ребра, инцидентные вершинам множества C и при этом - вер-шинам множества B, не учитываются при подсчете степеней вершин множестваB. Значимость таких качественных критериев, как надежность и функциональ-ность, со всеми зависимыми примитивами, рассматриваются как максимизируе-мое априори и не ставится в прямую зависимость от пользовательских требованийк ИАС. Соответственно данные характеристики в настоящий анализ не включа-ются.Подходы к созданию автоматизированной информационно-аналитической системы 71Таким образом, представленная модель позволяет обозначить и формализоватьстепень важности примитивов программного качества для классов пользователей,и, таким образом, упростить процесс управления требованиями и их применениядля формирования проектных решений.Наряду с моделью качества рассматривается модель «Классы пользователей -функции программной системы», при построении которой множество B формиру-ется функциями ИАС, информация о которых находится на концептуальномуровне объектной модели анализа. Информация извлекается из прецедентов,включаемых, расширяющих и дифференцирующих прецеденты, определяющиеприкладные сервисы ИАС и основные ее функциональные процессы (табл.1),представляемые в графе элементами множества C.Соответствие q: BЎжC определяется отношениями зависимости и генерализа-ции между основными и подчиненными прецедентами и не имеет прямого отно-шения к выявлению значимости рассматриваемых элементарными функций ИАСдля классов пользователей. Алгоритм анализа данной графовой модели аналоги-чен изложенному, а результаты позволяют управлять приоритетами проекта ИАСв создании ее функциональности.Совместное исследование формальной значимости в моделях качества ифункций дает четкий ориентир при выборе составляющих системной архитекту-ры, направлений ее развития и опорных свойств. Для этого необходимо исследо-вать распределение формальной значимости только между примитивами конкрет-ного качественного критерия, что позволит уточнить форму проявления данногокритерия качества в ИАС. Так, особенности конфигурации свойства мобильностив ИАС включают необходимость создания кросс-платформенной компонентнойсистемной архитектуры и исключают полную автономность приложений, развер-тываемых в ИАС, обуславливая их зависимость от базового ПО. Для улучшениябаланса значимости в критерии мобильности необходимо уточнить требования сакцентом на значимость примитива структурированности. Указанное, наряду санализом модели функций, позволило определить архитектуру ИАС как ярусную,включающую клиентский и представительский, а также ярусы функциональнойлогики и данных. Реализация критерия мобильности в ИАС состоит в выборе ар-хитектурной платформы J2EE (Java2 Enterprise Edition), обеспечивающей незави-симость ИАС от аппаратно-программной платформы и позволяющей определятьее структуру на основе совместимых базовых компонент. Развертывание трехсерверных ярусов будет обеспечено сервером приложений JBossAS 4.2.1 GA [17],который предоставляет контейнеры сервлетов и компонентов EJB3.0 (EnterpriseJava Beans) и выполняется на базе процесса виртуальной машины Java, JVM (JavaVirtual Machine), поставляемой в комплексе JDK (Java Development Kit) v5.0 [18].Важным качественным критерием нами определена легкость применения. Доми-нирование примитивов устойчивости и коммуникабельности указывает на необ-ходимость реализации робастных приложений на уровне функциональной логики,а также пользовательских интерфейсов, обеспечивающих простоту и удобство вработе конечного пользователя. Базовой технологией взаимодействия клиентско-го и представительского ярусов в ИАС нами выбрана AJAX (AsynchronousJavaScript and XML), использующая протоколы HTTP (Hypertext Transfer Protocol) иHTTPS (Hypertext Transfer Protocol over SSL (Secure Sockets Layer)) для организациипередачи асинхронных сообщений между клиентом и сервером веб-приложения.AJAX опосредует взаимодействие обозревателя и веб-сервера (веб-контейнера насервере приложений) использованием клиентского объекта XMLHTTPRequest,72 А.Г. Иванов, М.П. Дьяковичуправляемого кодом JavaScript, составляющим высококачественный пользова-тельский интерфейс с развитой событийной моделью, который обеспечивает не-прерывность работы пользователя, отправляет запросы XMLHTTPRequest и обра-батывает отклики сервера в функциях обратного вызова [19]. Защищенность дан-ного звена ИАС обеспечивается организационно-техническими мерами и изоли-рованностью от Интернет посредством межсетевых экранов.Обучающая и инструктивная документация востребована конечными пользо-вателями как неотъемлемая часть ИАС. В критерии эффективности выделяетсявременная эффективность как примитив, наиболее различимый конечными поль-зователями. Критерий реализуется главным образом на уровне решений аппарат-ной платформы. Пользователи, обеспечивающие сопровождение ИАС, акценти-руют значимость технической эксплуатационной документации и отмечают вкритерии сопровождаемости ряд примитивов, максимально реализуемых присоздании программной архитектуры.Создание архитектуры включает моделирование логической структуры при-ложения _____на уровне классов и компонентов, развертываемых в контейнерах J2EE-сервера. Основным источником информации на этом этапе служит функциональ-ная модель ИАС. Для реализации каждого функционального процесса в ИАС пре-дусматривается отдельное программное приложение, развертываемое на четырехсистемных ярусах и предусматривающее распределение компонентов в рамкахобобщенной структуры (рис 3).Рис. 3. Обобщенная структура приложения в ИАССтруктура научного прототипа соответствует общей структурной модели от-дельного приложения в ИАС. В качестве программной технологии, реализующейвзаимодействие между клиентским и представительским уровнями на основе мо-дели AJAX, выбирается технология GWT (Google Web Toolkit) [20], позволяющаяразрабатывать AJAX-приложения на языке Java2 с последующей компиляцией вJavaScript и HTML для клиентского яруса и классы Java2, составляющих сервле-ты, выполняемые в контейнере сервлетов на сервере приложений и обеспечиваю-щие связь клиентского AJAX-интерфейса и части приложения на уровне функ-Подходы к созданию автоматизированной информационно-аналитической системы 73циональной логики. Решение _____имеет ряд аналогов (ICEFaces и Ajax4JSF (AJAX forJava Server Faces), представляемых каркасом JBoss Seam 2.0, используемым в про-екте ИАС в качестве интегрирующего средства) [21] и имеет преимущество передними, заключающееся в унификации цикла разработки на основе единой про-граммной платформы и языка Java2. Главный процесс приложения обеспечивает-ся сессионным EJB3.0 - компонентом с поддержкой состояний. По мере необхо-димости, он подключает дополнительные сессионные компоненты без поддержкисостояний, расширяющие его функциональную логику, а также взаимодействует скомпонентами-сущностями в ярусе данных для выполнения транзакций с посто-янным хранилищем данных. Каждое приложение регистрирует все значимые про-граммные события в системном журнале, необходимом для администрированияИАС. Для этого сессионный компонент с поддержкой состояний используетслужбу передачи сообщений (JMS, Java Message Service) для установления асин-хронной связи с журнализирующим EJB3.0-компонентом, управляемым сообще-ниями. При этом используется одна из очередей сообщений на сервере. Компо-ненты-сущности реализуют часть логики приложения, относящейся к обработкеданных и взаимодействуют с базой данных (БД) через ряд последовательных ин-терфейсов, предоставляемых сервером приложений: диспетчер персистентности сфункцией объектно-реляционного преобразователя (ORM, Object-Relational Mapping)- Hibernate, менеджер транзакций - JTA (Java Transaction API) и интерфейссоединений с БД - JDBC(Java DataBase Connectivity). Постоянное хранилищеданных обеспечивается JDBC-совместимым сервером БД Oracle 10g XE.Являясь центральным компонентом и прагматическим ядром ИАС, ЭС развер-тывается в рамках приложения аналогичной структуры. Классы оболочки ЭС Jess7, реализующие продукционный решатель на основе Rete-алгоритма, а также гра-фическую консоль и консоль командной строки, расширяются аналогичнымиклассами API обработки нечеткой информации NRC FuzzyJ Toolkit, реализующемметоды анализа нечетких множеств, методы нечеткой логики и лингвистическиепеременные Л. Заде [14, 22].Программная реализация задачи вывода на основе нечетких фактов и посред-ством нечетких правил предполагает использование объектов классов-наследни-ков, реализованных в NRC FuzzyJ Toolkit на основе базовых классов Jess7. Такимобразом, подход к построению кода управления нечетким выводом предполагаетиспользование объекта нечеткого решателя FuzzyRete вместо объекта Rete, пред-ставляющего решатель, реализованный в Jess7. Кроме того, объект Jess7 Consoleзамещается аналогичным объектом FuzzyConsole с поддержкой обработки нечет-кой информации. API ядра ЭС вызывается и используется сессионным компонен-том с поддержкой состояний в приложении ЭС. Данные, составляющие основыконтекста пациента, запрашиваются из БД и передаются в приложение посредст-вом комплекса, функционирующего в ярусе данных. Для собственно формирова-ния контекста пациента может быть вызван сессионный EJB3.0-компонент безподдержки состояний. Программная реализация базы знаний может включатьтекстовые файлы с кодом на языках CLIPS и JESS, а также представления нечет-кой информации в формате, поддерживаемом NRC FuzzyJ Toolkit. На рис. 4 ил-люстрируются две возможности использования функциональным приложениемAPI ЭС, в ходе реализации которых NRC FuzzyJ Toolkit может быть использованавтономно от Jess, равно как и средства Jess могут быть применены без привлече-ния поддержки нечеткой информации, однако целесообразно их совместное ис-пользование как слоистой системы.74 А.Г. Иванов, М.П. ДьяковичРис. 4. Модель организации API-ядра ЭС его интеграции в ИАСЗаключениеВнедрение предлагаемой информационной технологии и в ее рамках - новых иизмененных функциональных процессов, программных продуктов и приложений,предназначенных для повышения эффективности и надежности клинико-диагно-стического процесса, позволит снизить ресурсоемкость процесса дифференциаль-ной диагностики профессиональных нейроинтоксикаций для достижения органи-зационных, экономических и медико-социальных эффектов, производимых со-вершенствованием процесса диагностики. Этап внедрения и испытательной экс-плуатации информационно-аналитической системы диагностики и прогнозирова-ния профессиональных нейроинтоксикаций потребует существенных усилий,присущих информатизации технологии традиционного ряда, однако помимо обо-значенных выше прямых эффектов, будет положено основание для интеграции иразвития новых прикладных медицинских сервисов. Решение совместимо с кон-цепциями SOA (сервис-ориентированной архитектуры программного обеспече-ния), что определяет не только возможность расширения функциональности ин-формационно-аналитической системы путем интеграции новых приложений иразвертывания прикладных сервисов на их основе, по общему принципу, описан-ному нами, но и стандартность технологии управления сервисами информацион-но-аналитической системы.

Скачать электронную версию публикации