Інформаційна технологія класифікації клінічних діагнозів на основі семантико-синтаксичної моделі

Таблиця 2

Відповідність конструкторів концептів запропонованої класифікації

Спрощена Нотація	Приклад	Нотація логіки 	Опис
*Axis	{*F} фаза захворювання		Необов'язкова клінічна характе-ристика діагнозу
{*Axis1 {*Axis2}}	{*T{*F}}		Характеристика F може бути задана, якщо задана характе-ристика T
Axis&	{*O&} ускладнення		Можливість завдання декількох значень характеристики одночасно
!Axis	{!T} ст. важкості		Обов'язкова характеристика

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

, де F − абстрактний фрейм, C − фрейм, F.S – множина слотів супер-фрейму, Copy – предикат, що описує процес копіювання відповідної частини мережі, яка пов’язана з успадкованим слотом, GT – предикат, який описує синтаксичну трансформацію термінів при успадкуванні на основі описаних правил GTRules для даного слоту.

Таблиця 3

Загальна структура слоту

Перехід до об’єктно-орієнтованої моделі здійснюється наступним чином: структурна частина отриманої фреймової репрезентації відображається на даталогічну модель, а функціональна − на об’єктно-орієнтовану модель, яка описує контур керування класифікацією.

Концептуальна модель класифікації надана на рис. 1. Основою класифікації є композиція класів Frame та Slot, що відповідає за репрезентацію фреймової мережі клінічних діагнозів. Особливістю моделі є використання циклічного зв’язку на базі шаблону Composite, що дозволяє репрезентувати мережу з необмеженою кількістю рівнів ієрархії „частина-ціле”. Залежність слотів у рамках фрейму (конструктор імплікації слотів) визначається циклічним зв’язком класу Slot, що дозволяє задати нескінчену кількість вкладених слотів. Класи AFrameFrame та AFrameSlot відповідають за реалізацію механізму успадкування фреймів-концептів від абстрактних фреймів, при цьому передбачається можливість реалізації часткового успадкування. Важливою особливістю при реалізації успадкування є існування механізму граматичної трансформації філерів визначеного слоту, при якому зі значенням слоту абстрактного фрейму можуть бути пов’язані схеми граматичної трансформації, які визначаються композицією класів GT, GTItem, GTTypeID: клас GT визначає схему трансформації; клас GTItem визначає елементарну трансформацію в рамках фрейму-значення; GTType визначає тип трансформації. Елементарною трансформацією можна вважати заміну вказаних маркерів (Marker) в значенні атрибуту TS0 відповідного фрейму на фразу (Description) за визначеною схемою. Клас Axis відповідає за репрезентацію осей класифікації, тісно пов’язаних з визначенням слотів фреймів. Класи ICD, ICDFrame відповідають за зв’язок з МКХ-10.

Структура таблиці „фрейми” складається з наступних атрибутів: ID - ідентифікатор фрейму; SlotID - ідентифікатор слоту, значенням якого є фрейм; Element - номер характеристики даного класу для даного слоту; TS0 - значення у випадку примітивного концепту або термінальний рядок символів, який передує першому слоту, у разі комплексного, Note - додатковий атрибут для більш детального опису значення характеристики. Структура таблиці „слот” еквівалентна таблиці 3 з доданням атрибуту FrameID, який визначає до якого фрейму відноситься даний слот.

Визначено умови та вимоги до функціональної складової класифікації, які зведено до чотирьох пакетів: робота з класифікацією, робота з базою пацієнтів, взаємодія з іншими термінологічними системами і пошук та аналіз даних по пацієнтам. Побудовано алгоритми та класи керування класифікацією, основними з яких є: CClassificationEntry (репрезентує суб-мережу визначеного фрейму), СNotation(відповідає за нотацію), CCode (відповідає за репрезентацію ієрархічного коду), CFrameValue(відповідає за роботу з фреймом-значенням слоту), CDecoder(відповідає за декодування коду клінічного діагнозу) тощо. Алгоритми пов’язані з обробкою мережі та базуються на використанні механізмів рекурсії, яка виконується логікою програми (переклад на рівень БД не є реальним).

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

Термінологічна система (ТС) надає загальну множину концептів, визначень та термінів (синонімів), які відповідають тим чи іншим концептам та атрибутам, і забезпечує пріоритетну семанти­чну складову загальної системи: ієрархічні стосунки, стосунки „частина-ціла”, логічне озна­чення концептів. Визначення концепту описують його зміст: можливі атрибути, що задають характерис­тики концепту, родові стосунки або стосунки „частина-ціле”. Атрибут “PostOperation” посила­ється на логічну операцію, за допомогою якої склада­ється означення концепту; у разі підтримки ТС декількох логічних операцій можливо додання ще декіль­кох атрибутів задля можливості реалізації формули з дужками.

Розроблена класифікація відповідає за додатковий рівень обмежень щодо семантики описаного діагнозу та за граматичну інтерпретацію. Надбудова даної класифікації пов’язана з термінологічною системою за прави­лом: кожний фрейм (значення) розробленої класифікації має відображення на концепт термінологічної системи, та кож­ний слот має бути відображеним на атрибут ТС. Слід особливо відзначити блок класів FrameCon­straint, SlotConstraint, ValueConstraint, TypeOfConstraint, які вирішують задачу вилучення несумісних концептів-характеристик у рамках одного формулювання діагнозу. Так, FrameConstraint вказує на існування обмежень та на їх характер у вигляді: „всі комбінації значень усіх атрибутів є консистентними…”; „всі консистентні/інконсистентні окрім…”; „існують консистентні/інконсистентні…”. SlotConstraint – надає обмеження на комбінацію слотів: „поява будь-яких значень двох слотів є інконсистентним/консистентним”; „всі консистентні/інконсистентні окрім”; „існують консистентні/інконсистентні”. ValueConstraint – обмеження щодо комбінацію значень таким чином: „одне значення одного слоту і кожне значення другого слоту є консистентними/інконсистентними”; „одне значення одного слоту і одне значення другого слоту є консистентним/ інконсистентними”.

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

У четвертому розділі розглянуто особливості реалізації ПЗ та впровадження автоматизованого класифікатора клінічних діагнозів, який базується на принципах: перспективності засобів розробки інформаційних систем (технологій проектування та програмування); максимальної незалежності від особливостей технічних особливостей інформаційної платформи (специфіка провайдеру баз даних, операційна система); компонентно-орієнтованого підходу розробки інформаційних систем.

Основу контуру роботи з БД складають ряд програмних класів на основі композиційного використання стандартних засобів мови C# ІDbDataAdapter, ІDbCommand, IDbParameter, HashTable, DataTable, DataSet.

Контур класифікації (рис.2) складається з: редактора класифікації (UCSCD.Editor) та процесора скриптів (UCSCD.ScriptProcessor), які є засобами створення/редагування класифікації експертом (табл.4); бібліотек, що дозволяють здійснювати кодування/декодування клінічних діагнозів, завдання діагнозів пацієнтів, пошук та аналіз, пов’язаний з фактами класифікації в базі пацієнтів. При цьому особливою рисою є забезпечення незалежності класифікації від специфіки ГІС, яка базується на трьох способах використання класифікації: тільки класифікація як сервер термінології на базі API; класифікація і БД пацієнтів на базі API; класифікація і БД пацієнтів на базі візуальних компонентів.

В кінці розділу наведено приклади використання класифікації в підсистемах аналітики і статистики ГІС.

Таблиця 4

Набір основних команд керування класифікацією клінічних діагнозів

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

Розглянемо основні етапи та особливості даної технології.

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

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

Семантико-синтаксична модель на базі фреймового підходу об’єднує моделі семантичної та синтаксичної складових класифікації та описується: аксіомами та переліком конструкторів, пов’язаних з визначенням фрейму (табл.1, 2); структурою слоту (табл.3); визначенням функціональної складової класифікації (табл. 4).

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

Механізми зберігання та пошуку фактів (діагнозів пацієнтів) базуються на нормалізації ієрархічного коду і використанні опертатора SQL-92 LIKE, що дозволяє забезпечити компактне зберігання та швидкий пошук в БД.

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

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

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

У п’ятому розділі розглянуто особливості розробки госпітальної системи в контексті створення гнучких, легко адаптивних інформаційних систем. Особлива роль при цьому відведена організації, формі надання та використанню метаінформації для вирішення задач динамічної зміни або адаптації інтерфейсу користувача та підсистеми аналітики. Так, у рамках завдання побудови гнучкої госпітальної інформаційної системи запропоновано модельно-орієнтований підхід з використанням фреймової парадигми для побудови моделі системи, що дозволяє не тільки розширити метамову, яка стоїть над формалізмами моделей об’єктно-орієнтованого проектування шляхом включення додаткових граней, але й по-новому розглянути шляхи подання метаінформації.

Сутність підходу полягає в відображенні метаінформації, що міститься у зовнішньому джерелі, на ту або іншу функціональну вісь системи. Головною відмінністю від шаблону TypeSquare можна вважати виділення в окремий клас безлічі граней які описують атрибути. Крім того, виділено комплексні атрибути (слоти), які забезпечують зв'язок з концептами, задані гранями (обмеження на значення, тип умови). Так, безліч збережених об'єктів предметної області (сутності) можна розділити по типу на статичні (довідники) і динамічні. Кожна сутність має безліч атрибутів, які можуть бути простими (приймати значення, обмежені лише типом і розміром) або бути посиланнями на інші сутності (тобто бути слотами або зовнішніми ключами). При цьому на слоти можуть накладатися обмеження як за характером значення (наприклад, хірурги — це доктори зі спеціалізацією "хірургія"), так і за обов'язковістю завдання значення (якщо значення слота/атрибута не задане або задане невірно – примірник сутності не має змісту). З кожним із атрибутів/слотів може бути пов'язане певне число граней, які визначають їхнє відображення на ту або іншу функціональну вісь системи.

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

Структура таблиці sconcept складається з атрибутів: Name (ім’я концепту або таблиці в БД); OwnerID (посилання на концепт); TypeID (тип концепту, наприклад, концепт користувача, системний концепт, довідник); Description (природне ім'я концепту для відображення в інтерфейсі програми).

Структура таблиці sattribute складається з атрибутів: TableID (ID таблиці до якої належить атрибут), Description (опис атрибута), Name (природне ім'я атрибута для роботи с таблицями), Type (тип атрибута), Size (Розмір поля атрибута), Readonly (Прапор „тільки читання” для атрибута), Width (Ширина атрибуту в пікселях для відображення його на екрані), Caption (Підпис атрибуту, який виводиться на екран для користувача), VR (Обмеження на значення атрибута), FKey (ID концепту, з яким пов'язаний атрибут), PKey (прапорець, чи є цей атрибут первинним ключем свого концепту), Norder (порядковий номер атрибуту для виводу на екран), NRMin (мінімальне значення даного атрибуту), NRMax (максимальне значення даного атрибуту), iVR(додаткова умова або умови, що пов'язують можливі значення атрибута з контекстом системи), SlotType (тип зв'язку із зовнішнім концептом), DefaultFunction (значення за замовчанням).

Підсистема статистики. Так, приймаючи до уваги різноманітність і динамізм зміни статистичних форм звітності ДЛЗ України, а також формування поза-звітних форм для внутрішнього використання в ЛЗ, було обрано рішення для побудови цієї підсистеми на базі програмного шаблону „інтерпретатор” у рамках загального напрямку “захист коду від варіацій”, що найбільш відповідає запропонованим вимогам. Зміст підходу полягає в тому, що логіка побудови звіту виноситься в деяке зовнішнє стосовно системи джерело (файл, таблицю бази даних), яке може бути частково або повністю доступним користувачам з певними правами доступу. У загальному випадку, користувач може як змінювати саму логіку побудови вже існуючого звіту (алгоритм його формування), так і створювати нові звіти, при цьому код програми залишається незмінним. У цьому випадку сама програма працює як інтерпретатор команд користувача, описів, правил у реальні звіти. Зміна логіки побудови звіту може виконуватися двома способами: шляхом додавання SQL-команд з наступним заповненням стовпчиків примірника таблиці-шаблона звіту; шляхом додавання рядка з описом створення екземпляра компоненту та подальшим викликом його методів. Підсистема припускає незалежне використання компоненту виводу на друк і логіки побудови звіту. Загальна модель класів підсистеми представлена на рис. 4.

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

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

ВИСНОВКИ

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

В ході аналізу отриманих результатів були зроблені наступні висновки:

1. Простота в користуванні, компактність, врахування семантичних обмежень на формування діагнозу та обов’язкове надання механізмів формування синтаксично правильних описів діагнозів є основними факторами, які впливають на впровадження автоматизованого класифікатора клінічних діагнозів в лікувальні заклади України.

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

3. Концептуальна модель класифікації діагнозів, основана на формальної семантико-синтаксичної моделі з використанням фреймового і об’єктно-орієнтованого підходів опису знань, є базою для структурної та функціональної складових класифікації клінічних діагнозів.

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

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

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

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


8-09-2015, 22:13