91658 (680111), страница 3
Текст из файла (страница 3)
Таблиця 3
Загальна структура слоту
| Ім’я грані слоту | Опис грані слоту |
| SuperSlot | Слот, від якого наслідується даний |
| MemberSlot | Ідентифікатор слоту |
| SlotIsDependentOf | Слот, від якого даний залежить |
| ValueClass | Ім’я концепту (фрейму), з яким задається відношення |
| Cardinality.Min | Обмеження на мінімальну кількість значень |
| Cardinality.Max | Обмеження на максимальну кількість значень |
| OrderInFrame | Порядок слоту у фреймі |
| OrderInSlot | Порядок підпорядкованого слоту в слоті |
| DirectionForOrderInSlot | Покажчик напрямку місцезнаходження підпорядкованого слоту в слоті |
| TerminalString1 | Термінальний рядок перед клінічною характеристикою |
| TerminalString2 | Термінальний рядок за клінічною характеристикою |
| TerminalString3 | Термінальний рядок, який стоїть за слотом у фреймі |
Перехід до об’єктно-орієнтованої моделі здійснюється наступним чином: структурна частина отриманої фреймової репрезентації відображається на даталогічну модель, а функціональна − на об’єктно-орієнтовану модель, яка описує контур керування класифікацією.
Концептуальна модель класифікації надана на рис. 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 (відповідає за декодування коду клінічного діагнозу) тощо. Алгоритми пов’язані з обробкою мережі та базуються на використанні механізмів рекурсії, яка виконується логікою програми (переклад на рівень БД не є реальним).
Для того, щоб проаналізувати можливість інтеграції розробленої класифікації з сучасними термінологічними системами, сформовано формальну модель узагальненої термінологічної системи з використанням апарату логіки предикатів, яка об’єднує запропонований підхід з підходами SNOMED CT, UMLS.
Термінологічна система (ТС) надає загальну множину концептів, визначень та термінів (синонімів), які відповідають тим чи іншим концептам та атрибутам, і забезпечує пріоритетну семантичну складову загальної системи: ієрархічні стосунки, стосунки „частина-ціла”, логічне означення концептів. Визначення концепту описують його зміст: можливі атрибути, що задають характеристики концепту, родові стосунки або стосунки „частина-ціле”. Атрибут “PostOperation” посилається на логічну операцію, за допомогою якої складається означення концепту; у разі підтримки ТС декількох логічних операцій можливо додання ще декількох атрибутів задля можливості реалізації формули з дужками.
Розроблена класифікація відповідає за додатковий рівень обмежень щодо семантики описаного діагнозу та за граматичну інтерпретацію. Надбудова даної класифікації пов’язана з термінологічною системою за правилом: кожний фрейм (значення) розробленої класифікації має відображення на концепт термінологічної системи, та кожний слот має бути відображеним на атрибут ТС. Слід особливо відзначити блок класів FrameConstraint, SlotConstraint, ValueConstraint, TypeOfConstraint, які вирішують задачу вилучення несумісних концептів-характеристик у рамках одного формулювання діагнозу. Так, FrameConstraint вказує на існування обмежень та на їх характер у вигляді: „всі комбінації значень усіх атрибутів є консистентними…”; „всі консистентні/інконсистентні окрім…”; „існують консистентні/інконсистентні…”. SlotConstraint – надає обмеження на комбінацію слотів: „поява будь-яких значень двох слотів є інконсистентним/консистентним”; „всі консистентні/інконсистентні окрім”; „існують консистентні/інконсистентні”. ValueConstraint – обмеження щодо комбінацію значень таким чином: „одне значення одного слоту і кожне значення другого слоту є консистентними/інконсистентними”; „одне значення одного слоту і одне значення другого слоту є консистентним/ інконсистентними”.
Таким чином, розроблено механізм взаємодії зі стандартними термінологічними системами, який дозволяє представити розроблену класифікацію як потенціальну частину більш загальної сучасної термінологічної системи для розширення її семантичних та синтаксичних можливостей при описі клінічних діагнозів.
У четвертому розділі розглянуто особливості реалізації ПЗ та впровадження автоматизованого класифікатора клінічних діагнозів, який базується на принципах: перспективності засобів розробки інформаційних систем (технологій проектування та програмування); максимальної незалежності від особливостей технічних особливостей інформаційної платформи (специфіка провайдеру баз даних, операційна система); компонентно-орієнтованого підходу розробки інформаційних систем.
Основу контуру роботи з БД складають ряд програмних класів на основі композиційного використання стандартних засобів мови C# ІDbDataAdapter, ІDbCommand, IDbParameter, HashTable, DataTable, DataSet.
Контур класифікації (рис.2) складається з: редактора класифікації (UCSCD.Editor) та процесора скриптів (UCSCD.ScriptProcessor), які є засобами створення/редагування класифікації експертом (табл.4); бібліотек, що дозволяють здійснювати кодування/декодування клінічних діагнозів, завдання діагнозів пацієнтів, пошук та аналіз, пов’язаний з фактами класифікації в базі пацієнтів. При цьому особливою рисою є забезпечення незалежності класифікації від специфіки ГІС, яка базується на трьох способах використання класифікації: тільки класифікація як сервер термінології на базі API; класифікація і БД пацієнтів на базі API; класифікація і БД пацієнтів на базі візуальних компонентів.
В кінці розділу наведено приклади використання класифікації в підсистемах аналітики і статистики ГІС.
Таблиця 4
Набір основних команд керування класифікацією клінічних діагнозів
| Описання команд керування класифікацією | |
| Команда | Значення |
| Putframe : | Визначити фрейм (Напр.: putframe:C15: Захворювання {!L стравоходу} {, p !W }) |
| Putslotvalue:.= | Визначити філер слоту (Наприклад: Putslotvalue: C15:L1 = шийного відділу) |
| Deleteframe: | Видалення фрейму (Deleteframe:K25) |
| Deleteslot: | Видалення слоту (Deleteslot:K25:T) |
| Deleteslotvalue: | Видалення філеру слоту(Deleteslotvalue:K25:T1) |
| Aframe: : | Визначити фрейм (Напр.: aframe:A1:{!I}{*O}) |
| Aframeslotvalue:.= | Визначити філер слоту абстрактного фрейму (Напр.: Aframeslotvalue: A1:I1 = кровотеч) |
| Frameaframe:[+gtn]: | Визначити успадкування фрейму fn від afn, використовуючи схему трансформації (Напр.: Frameaframe:A1+1:C15) |
| Gt:::{=;} | Визначити схему граматичної трансформації для фрейму (Напр.:Gt:A1:1:1=ою;2=ею;3=єю) |
| Changeslotaxis:: | Зміна осі (Changeslotaxis:K29.4: K>S) |
| Moveframe: | Зміна імені фрейма (зв’язок фрейму з іншим кодом МКХ-10) |
| Icd10:.: | Поставити у відповідність кодової комбінації класифікації код МКХ-10. (Icd10:K21-O5:K22.2) |
| fn - ім’я фрейму; fv - опис фрейму в нотації розробленої класифікації; svn – ім’я філеру слоту ; sv – філер слоту; svm - філер слоту з маркерами; sn – ім’я слоту; gtn - номер схеми граматичної трансформації; mn – імя маркеру; mv – значення маркеру; icd10n – код МКХ-10. | |
Розуміючи під поняттям інформаційної технології сукупність методів, алгоритмів і засобів щодо репрезентації, зберігання, пошуку, передачі та обробки інформації, слід зазначити, що строга етапність вирішення проблеми створення електронної класифікації клінічних діагнозів, сукупність методів та засобів стосовно формалізації, проектування та реалізації формують інформаційну технологію класифікації клінічних діагнозів, яка може бути використана при розробці класифікацій в інших областях знань (медицини, хімії, біології).
Розглянемо основні етапи та особливості даної технології.
На першому етапі визначено основні вимоги стосовно класифікації: простота та ясність опису множини понять, які складають предметну область (клінічні діагнози); композиційна модель утворення складних понять; контроль семантичної коректності сформованих понять; наявність механізмів граматично-коректних описів закодованих понять.
Методологія формалізації предметної області (другий етап) базується на розділенні семантичної та синтаксичної складових об’єкту класифікації і застосуванні апаратів формальних граматик та дескрипцій них логік для їх моделювання, з їх подальшим об’єднанням на базі фреймового підходу опису знань, оперуючи формалізмами фреймів, слотів, граней.
Семантико-синтаксична модель на базі фреймового підходу об’єднує моделі семантичної та синтаксичної складових класифікації та описується: аксіомами та переліком конструкторів, пов’язаних з визначенням фрейму (табл.1, 2); структурою слоту (табл.3); визначенням функціональної складової класифікації (табл. 4).
На третьому етапі здійснюється відображення фреймової моделі класифікації на концептуальну та даталогічну моделі, які створюється з застосуванням шаблону Composite на базі об’єктно-орієнтованого підходу до проектування. Алгоритми роботи з класифікацією базуються на рекурсії, дозволяючи проводити ефективну роботу зі складними мережами.
Механізми зберігання та пошуку фактів (діагнозів пацієнтів) базуються на нормалізації ієрархічного коду і використанні опертатора SQL-92 LIKE, що дозволяє забезпечити компактне зберігання та швидкий пошук в БД.
На четвертому етапі здійснюється моделювання інтеграції розробленої класифікації зі стандартними, вже існуючими термінологічними системами. Результатом показано як класифікація може бути інтегрована в сучасну термінологічну систему з метою її доповнення відповідно термінології клінічних діагнозів.
Реалізація класифікації (п’ятий етап) базується на принципах відкритості та компонентності, що дозволяє її використання в вже існуючих системах.












