ЛЬВІВСЬКИЙ НАЦІОНАЛЬНИЙ МЕДИЧНИЙ УНІВЕРСИТЕТ

імені ДАНИЛА ГАЛИЦЬКОГО

кафедра медичної інформатики

МЕТОДИЧНІ ВКАЗІВКИ

до теми 11

“ Клінічні системи підтримки прийняття рішень. Засоби прогнозування. Моделювання системи підтримки прийняття рішень.”

з медичної інформатики

для студентів ІІ курсу

медичного факультету

Львів 2008

Класифікація медичних експертних систем

Оскільки медичні знання носять емпіричний характер, слабо структуровані і погано формалізовані, саме медичні задачі доцільно розв'язувати за допомогою експертних систем. На сьогодні найбільша питома вага використання ЕС належить медицині.

Основні типи медичних ЕС відносно вирішуваних завдань можна згрупувати в категорії, наведені в табл. 1

Таблиця 1.

Типові категорії способів застосування медичних ЕС.

Категорія	Проблема, що вирішується
Інтерпретація	Опис ситуації за інформацією, що поступає від давачів
Діагностика	Виявлення причин захворювання
Прогнозування	Визначення вірогідних наслідків заданих ситуацій
Лікування, реабілітація	Виконання послідовності наказаних дій, скерованих на приведення до норми
Навчання	Діагностика і корегування поведінки того, хто навчається
Планування	Визначення послідовності дій
Керування	Керування станом об'єкта

Експертні системи, що виконують інтерпретацію, як правило, використовують для опису ситуації інформацію від давачів систем спостереження (наприклад, значення пульсу, кров'яного тиску тощо), щоб встановити діагноз або тяжкість захворювання .

Діагностичні системи служать для визначення причин захворювання за симптомами, що спостерігаються у пацієнтів. Такі системи надають консультації, допомагають за наслідками діагностики виробити прогноз, підібрати курс лікування або реабілітації .

Експертні системи, що здійснюють прогнозування, визначають імовірні наслідки ситуацій, що спостерігаються. На сьогодні таких систем розроблено відносно мало, оскільки для їх реалізації часто вимагається використання досить складних методів імітаційного моделювання.

Експертні системи для лікування і реабілітації часто містять діагностичні компоненти, як, втім, і діагностичні системи містять компоненти для отримання рекомендацій стосовно лікування. Це цілком логічно, оскільки процеси діагностики і лікування взаємозв'язані .

Навчальні системи створюють модель знань, якими повинен володіти "учень" і модель, що показує як він застосовує ці знання для рішення конкретних задач. На основі аналізу моделі системи діагностують і вказують тому, що навчається, його помилки, і будують плани виправлення наявних помилок .

ЕС, що планують, визначають повну послідовність дій, перш ніж почнеться їх виконання. Прикладами можуть служити планування курсу лікування або ходу операції. Такі ЕС часто повинні мати здатність до повернення (принцип бектрекінгу), тобто відкидати деяку послідовність міркувань або частину плану внаслідок порушення обмежень задачі і повертати керування назад до попередньої точки або ситуації, з якої аналіз повинен початися заново. Повернення може дорого коштувати, особливо під час рішення задач медичної проблематики, де ціною помилки може бути життя пацієнта, тому задача планування часто розбивається на підпроблеми і робиться спроба впорядкувати їх так, щоб уникнути перепланування .

ЕС, що керують, адаптивно керують станом об'єкта - наприклад, станом хворих в умовах інтенсивній терапії. Тому такі ЕС повинні включати компоненти інтерпретуючих систем, щоб спостерігати стан об'єкта впродовж певного часу. Крім цього в ЕС, що керують, можуть використовуватися інші компоненти: діагностики, прогнозування, навчання, планування.

За зв‘язком з реальним часом ЕС поділяються на

Статичні ЕС розробляються у предметних областях у яких база знань та дані, що інтерпретуються не змінюються за час вирішення задачі.

Квазідинамічні ЕС інтерпретують ситуацію, що змінюється з деяким фіксованим інтервалом часу.

Динамічні ЕС працюють з даними, що змінюються під час вирішення задачі, іноді у режимі реального часу з безперервною інтерпретацією даних, що надходять.

За ступенем інтеграції з іншими програмами

Автономні ЕС працюють безпосередньо в режимі консультацій з користувачем, тільки у випадку експертних задач, при рішенні яких не потрібні традиційні методи обробки даних.

Гібридні ЕС суміщають стандартні пакети програм та засоби маніпулювання знаннями. Це може бути інтелектуальна надбудова над пакетом прикладних програм або інтегроване середовище для вирішення складних задач з елементами експертних знань.

Незважаючи на зовнішню принаду гібридного підходу, розробка таких систем є задача на порядок складніше, ніж розробка автономної ЕС. Стиковка не просто різних пакетів, а й різних методологій створює комплекс теоретичних та практичних труднощів.

Етапи розроблення експертних систем

Технологія розроблення ЕС вкдючає шість основних етапів: ідентифікація, концептуалізація, формалізація, виконання, тестування, дослідна експлуатація (рис.1).

На етапі ідентифікації визначаються завдання, які потрібно розв'язувати, формулюється мета розроблення, визначаються ресурси, експерти і категорії користувачів. Основними на цьому етапі є вибір проблеми (завдання) та вибір експерта.

Ідентифікація завдання полягає в складанні неформального (вербального) опису, в якому указуються: загальні характеристики завдання; підзадачі, що виділяються усередині даного завдання; ключові поняття (об'єкти), їх вхідні (вихідні) дані; а також знання, що відносяться до вирішуваного завдання.

Для розроблення ЕС потрібно отримати дані від експерта та ввести їх у систему. Невеликі системи можуть містити знання одного експерта, тобто пошук потрібного експерта є дуже важливим кроком у створенні ЕС. У розробленні ЕС беруть участь також інженери знань, які тісно співпрацюють з експертами, професійні програмісти, які запрошується для модифікації і узгодження інструментальних засобів. Крім того можуть залучатися потенційні користувчі. Для складних систем вважається за доцільне залучати до основного циклу розробки декілька експертів, щоб інженер знань міг переконатися в правильності свого розуміння основного експерта, а також для узгодження поглядів різних експертів на якість пропонованих рішень.

Результатом даного етапу є відповідь на питання, що треба зробити і які ресурси необхідно задіювати (ідентифікація завдання, визначення учасників процесу проектування і їх ролі, виявлення ресурсів і цілей), формулювання вимог до ЕС.

На етапі концептуалізації проводиться змістовний аналіз предметної області (ПО), виявляються основні поняття та їх взаємозв'язки, визначаються методи рішення задачі.

На цьому етапі створюється модель ПО, яка включає

• об’єктну модель, що описує структуру предметної області як сукупності взаємопов’язаних об’єктів;

• функціональну модель, що відображає дії та перетворення над об’єктами;

• модель поведінки, яка розглядає взаємодію об’єктів у часовому аспекті.

Об’єктна модель відображає основні поняття ПО (об’єкти), їх властивості та взаємозв’язки між ними. Елементарною одиницею є факт, що описує одну властивість або один зв’язок об’єкта.

Поняття ПО повинні утворювати систему, під якою розуміється сукупність понять, що володіють такими властивостями:

• унікальністю (відсутністю надмірності);

• повнотою (достатньо повним описом різних процесів, фактів, явищ і так далі наочній області);

• достовірністю (валідністью — відповідністю смислової інформації виділених одиниць їх реальним найменуванням)

• несуперечністю (відсутністю омонімії).

Виділені поняття ПО і встановлені між ними взаємозв'язки стають підставою для подальшої побудови системи класифікацій. Сукупності об’єктів з однаковим набором предикатів (властивостей і зв’язків) утворюють класи. Якщо об’єкти мають набір предикатів, що частково перетинається, то здійснюється більш складна класифікація об’єктів: клас об’єктів за значенням будь-якої властивості (ознаки) розбивається на підкласи так, що клас об’єктів містить загальні для підкласів властивості та зв’язки, а кожний із підкласів відображає специфічні властивості та зв’язки. Підкласи об’єктів автоматично успадковують загальні властивості і зв’язки вищестоячих класів, а сукупність взаємозв’язаних за відношенням узагальнення класів об’єктів утворює ієрархію спадковості властивостей.

Функціональна модель описує перетворення фактів, а також залежності між ними, що показують як одні факти утворюються від інших. функціональна модель відображає в узагальненій формі процес рішення характерних для неї задач. Функціональні залежності фактів представляються графічно у вигляді дерев мети (цілей) або графів.

Модель поведінки відображає зміни станів об’єктів у результаті виникнення деяких подій, що приводять до виконання певних дій (процедур). Стан об’єкта – це значення деякої властивості, що змінюється в часі. Набір дій, зв’язаний з деякою подією, визначає поведінку об’єкта, яка має вигляд правил або процедур.

На етапі формалізації визначаються способи представлення всіх видів знань (семантичні мережі, фреймові чи продукційні моделі і т.д), формалізуються основні поняття, визначаються способи інтерпретації знань, визначається стратегія пошуку рішення, моделюється робота системи, оцінюється адекватність цілей системи вибраним методам, поняттям і засобам.

На етапі виконання (реалізації) створюється прототип ЕС і проводиться наповнення експертами бази знань. Даний етап є найбільш важливим і найбільш трудомістким етапом розробки ЕС.

Процес набуття знань розділяють на

• вербалізацію – отримання знань від експерта і опис їх природною мовою,

• організацію та структурування знань, що забезпечує ефективну роботу системи

• представлення знань у вигляді, зрозумілому для ЕС.

Процес набуття знань здійснюється інженером знань на основі аналізу діяльності експерта в процесі рішення реальних задач

Прототип - це спрощена версія ЕС, що демонструє правильність обраного підходу та призначена для перевірки правильності кодування фактів, зв'язків та стратегій роздумів експерта.

Прототип ЕС повинен відповідати двом суперечливим вимогам:

• вміти розв'язувати типові задачі для конкретного застосування;

• час і трудомісткість розроблення повинні бути мінімальними.

Прототип повинен продемонструвати придатність методів інженерії знань для певного застосування. У випадку негативного результату розробляється новий прототип, або робиться висновок про непридатність методів інженерії знань для розв’язання даного завдання. У випадку успішного результату експерт за допомогою інженера знань розширює знання прототипу про ПО. У міру збільшення знань прототип може досягнути такого стану, коли він успішно вирішує всі задачі даної програми. Мета перетворення прототипу ЕС в кінцевий продукт полягає, як правило, у збільшення швидкодії ЕС та зменшенні необхідної пам'яті.

На етапі тестування експерт і інженер знань з використанням діалогових і пояснювальних засобів перевіряють компетентність ЕС.

Після розробки кінцевої версії ЕС необхідно провести детальне тестування, до якого залучаються інші експерти для перевірки працездатності системи на різних прикладах. Перевіряється їх точність та корисність.

Процес тестування продовжується доти, поки експерт не вирішить, що система досягла необхідного рівня компетентності.

На етапі дослідної експлуатації перевіряється придатність ЕС для кінцевих користувачів. За результатами цього етапу інколи можлива суттєва модифікація ЕС. На цьому етапі ЕС узгоджується з іншими програмними засобами у середовищі де вона працюватиме, та проводиться навчання користувачів системи. Узгодження включає забезпечення зв‘язку з існуючими на місці експлуатації системами та вимірювальними пристроями.

Процес створення ЕС не зводиться до строгої послідовності цих етапів тому, що в ході розроблення неодноразово потрібно повертатися на попередні етапи і переглядати прийняті там рішення.