ВестИНФО 2009 2 16sun.tsu.ru/mminfo/000063105/inf/07/image/07-065.pdf · Опыт применения систем данного рода в медицине достаточно

ВЕСТНИК ТОМСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА

2009 Управление, вычислительная техника и информатика № 2(7)

ОБРАБОТКА ИНФОРМАЦИИ

УДК 613.6:004.8

А.Г. Иванов, М.П. Дьякович

ПОДХОДЫ К СОЗДАНИЮ АВТОМАТИЗИРОВАННОЙИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ СИСТЕМЫ

ДИАГНОСТИКИ И ПРОГНОЗИРОВАНИЯПРОФЕССИОНАЛЬНЫХ НЕЙРОИНТОКСИКАЦИЙ

Настоящая работа посвящена вопросам создания информационной техноло-гии и реализующей ее информационно-аналитической системы, которая ис-пользует в качестве источника информации клинико-биологические, соци-ально-психологические и санитарно-гигиенические сведения о каждом ра-ботнике химического производства, подвергающемся воздействию нейро-тропных веществ, и предоставляет сервис экспертной поддержки принятиярешения вопросов диагностики и прогнозирования профессиональных ней-роинтоксикаций в профпатологической практике.

Ключевые слова: информационно-аналитическая система, экспертнаясистема, диагностика профессиональных нейроинтоксикаций, программнаяархитектура, требования к системе.

Производственный контакт с нейротропными веществами 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 Разработчик Создание, модификация и поддержка ИАС на уровне кодовприложений и объектов баз данных


П р о д о л ж е н и е т а б л . 2

1 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, обеспечивающая требуемый качественный уровень проектной информа-ции при построении моделей.

Управление требованиями представляет особую важность. Значимость этапованализа и проектирования в процессе создания ИАС были определены результа-тами исследования проблемной области. Предметом анализа и важным управ-ляющим ресурсом для ЖЦ ИАС являются требования пользователей каждого изклассов.

Реализация дисциплины управления требованиями включает анализ графовыхмоделей требований к создаваемой системе, позволяющий выявить и упорядочитьпо степени значимости ряд базовых функциональных и эксплуатационных харак-теристик ИАС. Собранные требования классифицируются по признакам принад-лежности соответствующим типам пользователей и распределяются на категориифункциональных и эксплуатационных, на основании которых, наряду со сводом


требований, составляющих внешнее описание программной системы, выполняет-ся построение моделей функций и качества ИАС. Для усовершенствования такихпостроений и снятия возможных противоречий при переходе от свода требованийк моделям функций и качества ИАС, была построена формальная модель, вклю-чающая построение и анализ двух основных графовых моделей-соответствий:«Классы пользователей – примитивы качества» и «Классы пользователей – функ-ции программной системы». Анализ моделей позволит провести ранжирование позначимости функциональных и эксплуатационных характеристик ИАС.

Модель «Классы пользователей – примитивы качества» была построена в це-лях формализации соответствия потребностей пользователей ИАС составу при-митивов качества программ. Иллюстрация построения модели на основе требова-ний, собранных на начальной итерации ЖЦ ИАС, представлена на рис. 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 в свойстве качественного


примитива bj. Под единицей потребности здесь следует понимать уникальноеупоминание описаний данного качественного свойства в контексте некоей макси-мально конкретизированной функции, действия или желаемой характеристикиИАС, принимаемые здесь атомарными. Для всех единиц потребностей значимостьпринимается равнозначной. Каждое выявленное не дублированное описание уве-личивает значение соответствующего коэффициента ωi,k на 1. Вычисление показа-теля совокупной значимости для любого из примитивов качества

( )( )

sum ,1

jb

j j kk

V bρ

== ω∑ , 1 ≤ k ≤ ρ(bj), 1 ≤ j ≤ 17,

где ρ(bj) – степень вершины, соответствующей данному примитиву качества, ωj,k –весовой коэффициент k-го ребра, инцидентного вершине bj, относительно каждойвершины в B, дает ряд значений (рис. 2), иллюстрирующих эталонную значи-мость качественных примитивов, позволяющих определить приоритетные на-правления в обеспечении качества ИАС и выявить необходимость в добавлениинедостающих требований. Важно, что модель будет нереалистична, если из сводатребований предварительно, на неформальном этапе анализа, не будут исключеныпротиворечия и неточности.

Рис. 2. Распределение формальной значимости по требованияммежду примитивами качества в проекте ИАС

Третье подмножество вершин C символизирует стандартные критерии качест-ва и вводится только для отображения соответствия примитивов качества – кри-териям. Никакие ребра, инцидентные вершинам множества C и при этом – вер-шинам множества B, не учитываются при подсчете степеней вершин множестваB. Значимость таких качественных критериев, как надежность и функциональ-ность, со всеми зависимыми примитивами, рассматриваются как максимизируе-мое априори и не ставится в прямую зависимость от пользовательских требованийк ИАС. Соответственно данные характеристики в настоящий анализ не включа-ются.


Таким образом, представленная модель позволяет обозначить и формализоватьстепень важности примитивов программного качества для классов пользователей,и, таким образом, упростить процесс управления требованиями и их применениядля формирования проектных решений.

Наряду с моделью качества рассматривается модель «Классы пользователей –функции программной системы», при построении которой множество 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,


управляемого кодом JavaScript, составляющим высококачественный пользова-тельский интерфейс с развитой событийной моделью, который обеспечивает не-прерывность работы пользователя, отправляет запросы XMLHTTPRequest и обра-батывает отклики сервера в функциях обратного вызова [19]. Защищенность дан-ного звена ИАС обеспечивается организационно-техническими мерами и изоли-рованностью от Интернет посредством межсетевых экранов.

Обучающая и инструктивная документация востребована конечными пользо-вателями как неотъемлемая часть ИАС. В критерии эффективности выделяетсявременная эффективность как примитив, наиболее различимый конечными поль-зователями. Критерий реализуется главным образом на уровне решений аппарат-ной платформы. Пользователи, обеспечивающие сопровождение ИАС, акценти-руют значимость технической эксплуатационной документации и отмечают вкритерии сопровождаемости ряд примитивов, максимально реализуемых присоздании программной архитектуры.

Создание архитектуры включает моделирование логической структуры при-ложения на уровне классов и компонентов, развертываемых в контейнерах J2EE-сервера. Основным источником информации на этом этапе служит функциональ-ная модель ИАС. Для реализации каждого функционального процесса в ИАС пре-дусматривается отдельное программное приложение, развертываемое на четырехсистемных ярусах и предусматривающее распределение компонентов в рамкахобобщенной структуры (рис 3).

Рис. 3. Обобщенная структура приложения в ИАС

Структура научного прототипа соответствует общей структурной модели от-дельного приложения в ИАС. В качестве программной технологии, реализующейвзаимодействие между клиентским и представительским уровнями на основе мо-дели AJAX, выбирается технология GWT (Google Web Toolkit) [20], позволяющаяразрабатывать AJAX-приложения на языке Java2 с последующей компиляцией вJavaScript и HTML для клиентского яруса и классы Java2, составляющих сервле-ты, выполняемые в контейнере сервлетов на сервере приложений и обеспечиваю-щие связь клиентского AJAX-интерфейса и части приложения на уровне функ-


циональной логики. Решение имеет ряд аналогов (ICEFaces и Ajax4JSF (AJAX forJava Server Faces), представляемых каркасом JBoss Seam 2.0, используемым в про-екте ИАС в качестве интегрирующего средства) [21] и имеет преимущество передними, заключающееся в унификации цикла разработки на основе единой про-граммной платформы и языка Java2. Главный процесс приложения обеспечивает-ся сессионным EJB3.0 – компонентом с поддержкой состояний. По мере необхо-димости, он подключает дополнительные сессионные компоненты без поддержкисостояний, расширяющие его функциональную логику, а также взаимодействует скомпонентами-сущностями в ярусе данных для выполнения транзакций с посто-янным хранилищем данных. Каждое приложение регистрирует все значимые про-граммные события в системном журнале, необходимом для администрированияИАС. Для этого сессионный компонент с поддержкой состояний используетслужбу передачи сообщений (JMS, Java Message Service) для установления асин-хронной связи с журнализирующим EJB3.0-компонентом, управляемым сообще-ниями. При этом используется одна из очередей сообщений на сервере. Компо-ненты-сущности реализуют часть логики приложения, относящейся к обработкеданных и взаимодействуют с базой данных (БД) через ряд последовательных ин-терфейсов, предоставляемых сервером приложений: диспетчер персистентности сфункцией объектно-реляционного преобразователя (ORM, Object-Relational Map-ping) – 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 могут быть применены без привлече-ния поддержки нечеткой информации, однако целесообразно их совместное ис-пользование как слоистой системы.


Рис. 4. Модель организации API-ядра ЭС его интеграции в ИАС

Заключение

Внедрение предлагаемой информационной технологии и в ее рамках – новых иизмененных функциональных процессов, программных продуктов и приложений,предназначенных для повышения эффективности и надежности клинико-диагно-стического процесса, позволит снизить ресурсоемкость процесса дифференциаль-ной диагностики профессиональных нейроинтоксикаций для достижения органи-зационных, экономических и медико-социальных эффектов, производимых со-вершенствованием процесса диагностики. Этап внедрения и испытательной экс-плуатации информационно-аналитической системы диагностики и прогнозирова-ния профессиональных нейроинтоксикаций потребует существенных усилий,присущих информатизации технологии традиционного ряда, однако помимо обо-значенных выше прямых эффектов, будет положено основание для интеграции иразвития новых прикладных медицинских сервисов. Решение совместимо с кон-цепциями SOA (сервис-ориентированной архитектуры программного обеспече-ния), что определяет не только возможность расширения функциональности ин-формационно-аналитической системы путем интеграции новых приложений иразвертывания прикладных сервисов на их основе, по общему принципу, описан-ному нами, но и стандартность технологии управления сервисами информацион-но-аналитической системы.

ЛИТЕРАТУРА

1. Лахман О.Л., Колесов В.Г., Андреева О.К. и др. Течение энцефалопатии в отдаленномпериоде профессиональной хронической ртутной интоксикации // Медицина труда ипромышленная экология. 2003. № 3. С. 46 – 48.

2. Колесов, В.А. Мещерягин, О.Л. Лахман О.Л. и др. Психопатологические проявления от-даленного периоида профессиональной нейротнтоксикации // Журнал неврологии ипсихиатрии. 2005. № 1. С.25 – 29.

3. Гусев А.В., Романов Ф.А., Дунаев И.П., Воронин А.В. Медицинские информационныесистемы: монография. Петрозаводск: ПетрГУ, 2005. 404 с.

4. Ifeachor E. Neural networks & expert systems in medicine & healthcare. World ScientificPublishing Company, 1998. 350 p.

5. Barnett G.O., Cimino J.J., Hupp J.A., Hoffer E.P. Xplain D. An evolving diagnostic decision-support system // JAMA. 1987. Jul 3; 258(1). P. 67 – 74.


6. Система поддержки принятия диагностических решений DXPlain – описание проектаhttp:/www. lcs.mgh. harvard. edu/ projects /dxplain.html

7. Rebrova O., Kilikowski V., Olimpieva S., Ishanov O. Expert system and neural network forstroke diagnosis // International Journal of Information Technology and Intelligent Comput-ing. 2006. V. 1. No. 2. P. 441 – 453.

8. Садыкова Е.В. Управление процессом постановки диагноза при помощи систем под-держки принятия решений врачом-клиницистом // Труды XVI Международной конфе-ренции «Новые информационные технологии в медицине, биологии, фармакологии иэкологии». Украина. Ялта – Гурзуф, 2008. С. 74 – 75.

9. Глазатов М.В., Поваляев А.С., Пшеничников Д.Ю., Шульман Е.И. Предпосылки разра-ботки и свойства медицинской информационной Intranet-системы // Сб. трудов Все-ройссийской конференции «Настоящее и будущее технологичной медицины». Ле-нинск-Кузнецкий, 2002. C. 19.

10. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программногообеспечения. СПб.: Питер, 2002. 496 c.

11. Хавар Заман Ахмед, Кэри Е. Амри. Разработка корпоративных Java-приложений с ис-пользованием J2EE и UML: пер. с. англ. М.: Изд. дом «Вильямс», 2002. 272 с.

12. Орлов С.А. Технология разработки программного обеспечения. 3-е изд. СПб.: Питер,2004. 527 с.

13. Официальный сайт оболочки для экспертных систем Jess (http://www.jessrules.com) 14. Orchard R. NRC Fuzzy Toolkit for the Java Platform, User's Guide, v.1.10, Institute for In-formation Technology National Research Council, Canada, September, 2006 (http://www.iit.nrc.ca/IR_public/fuzzy/fuzzyJToolkit2.html)

15. Боэм Б., Дж. Браун Дж., Каспар Х. и др. Характеристики качества программного обес-печения. М.: Мир, 1981. 200 с.

16. Липаев В.В. Качество программного обеспечения. М.: Финансы и статистика, 1983. 17. Официальный сервер компании JBoss, подразделения компании Red Hat (http://www.jboss.com)

18. Официальный сервер компании Sun Microsystems, разработчика платформы Java2(http://java.sun.com)

19. Статья с описанием технологии AJAX (http://www.adaptivepath.com/ideas/essays/archives/000385.php)

20. Страница продукта GWT(Google Web Toolkit) от производителя (http://code.google.com/webtoolkit)

21. Seam 2.0 reference guide (http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/seam/Seam_Reference _Guide /index.html)

22. Рыжов А.П. Элементы теории нечетких множеств и измерения нечеткости. М.: Диалог-МГУ, 1998. 116 с.

Иванов Антон ГеннадьевичИркутский государственный технический университетЕ-mail: [email protected]Дьякович Марина ПинхасовнаАФ-НИИ медицины труда и экологии человекаГУ МЭ ВСНЦ СО РАМН (г. Ангарск).Е-mail: [email protected] Поступила в редакцию 16 января 2009 г.

Documents

ВестИНФО 2009 2 16sun.tsu.ru/mminfo/000063105/inf/07/image/07-065.pdf · Опыт применения систем данного рода в медицине достаточно