Budowa systemu ekspertowego (Praca dyplomowa)(1)

informatyki zajmującą się odwzorowywaniem inteligentnego działania człowieka i
symulowaniem tej aktywności w maszynach oraz programach komputerowych.
Jednym z użytecznych zastosowań A.I są systemy ekspertowe. Do grupy
pionierów zajmujących się tymi systemami należy Edward Albert Feigenbaum.
Według niego definicja systemu ekspertowego brzmi następująco: „Jest to
inteligentny program komputerowy wykorzystujący procedury wnioskowania do
rozwiązywania tych problemów, które są na tyle trudne, że normalnie wymagają
znaczącej ekspertyzy specjalistów. Wiedza (niezbędna, by zapewnić odpowiedni
poziom ekspertyzy), wraz z procedurami wnioskowania, może być uważana za
model ekspertyzy, normalnie posiadanej tylko przez najle

pszych specjalistów w tej

dziedzinie. Wiedza systemu eksperckiego składa się zazwyczaj z faktów i
heurystyk. Fakty są podstawą bazy wiedzy systemu - informacją, która jest ogólnie
dostępna i powszechnie akceptowana przez specjalistów w danej dziedzinie.
He

urystyki są zwykle bardziej subiektywną (?) informacją, która charakteryzuje

proces oceny i rozwiązywania problemu przez określonego specjalistę.
Przykładami heurystyk są: intuicyjne domysły, przypuszczenia, zdroworozsądkowe
zasady postępowania. Poziom ekspertyzy, oferowany przez dany system
ekspercki, jest przede wszystkim funkcją rozmiaru i jakości bazy wiedzy danego
systemu.” [6].

W przypadku medycyny ekspertem posiadającym odpowiednią wiedzę i

kwalifikacje

, która pozawala na zdiagnozowanie pacjenta, jest lekarz. Ze względu

na obszerną wiedzę zawartą w nauce medycznej lekarze specjalizują się w
różnych dziedzinach takich jak: chirurgia, endokrynologia, kardiologia i wielu
innych.

Często w celu wyleczenia chorego potrzebna jest współpraca kilku

ekspertów o różnych specjalizacjach.

Szpitalny odział ratunkowy(skrót SOR) to miejsce gdzie trafiają chorzy w

nagłych przypadkach. W medycynie taki stan określa się jako nagłe zagrożenie
życia lub zdrowia. Chory, u którego wystąpił ten przypadek, jeżeli nie zostanie
wyleczony w jak najkrótszym okresie czasu, może stracić życie lub doznać
trwałego uszczerbku na zdrowiu. Specjalizacje jaką musi posiadać lekarz
dyżurujący w SOR to medycyna ratunkowa. W razie trudniejszego przypadku, w
celu postawienia trafnej diagnozy

oraz podjęciu odpowiednich działań, musi

skonsultować się z specjalistami z innych oddziałów, posiadających szerszą
wiedzę z danej dziedziny. W polskich warunkach często nie są oni dostępni w
krótkim czasie. Jednak, że liczy się czas od przyjęcia do postawienia diagnozy
oraz podjęcia skutecznych zabiegów ratujących życie lub zdrowie pacjenta. W
takich przypadkach użyteczny okazuje się system ekspertowy, który zawiera bazę
wiedzy z różnych dziedzin medycyny. Pozwala on w krótkim czasie skorzystać z
wiedzy ek

sperta z danej specjalizacji. Obniża to koszty oraz czas potrzebny do

zdiagnozowania pacjenta.

Współcześnie do dokumentowania przyjęć pacjentów w szpitalu używa się

aplikacji zbudowanych w oparciu o architekturę klient-serwer. Zapewnia to dużą
elastyczność, znacząco upraszcza wprowadzanie zmian w oprogramowaniu oraz

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

pozwala na obsługę kliku klientów jednocześnie. Serwer udostępnia usługi,
łączność między dwoma modułami zapewniona jest przez żądania(ang. Request)
oraz odpowiedzi(ang. Response). Jednym z rodz

ajów programów działających w

architekturze klient-serwer jest aplikacja internetowa. Po stronie serwera znajduje
się program i baza danych. Użytkownik końcowy komunikuje się z programem za
pomocą przeglądarki internetowej, wprowadza odpowiednie dane do bazy danych
lub je z powrotem uzyskuje. W p

rzypadku SOR użytkownikiem końcowym

odpowiedzialnym za obsługę przyjęć pacjentów jest lekarz i pielęgniarka.
Integracja systemu ekspertowego i aplikacji do obsługi przyjęć pozwala na
zachowanie architektury klient-s

erwer, ograniczenie kosztów szkoleń oraz

zapewnia bezpieczeństwo po stronie klienta.

2 Cel pracy

Celem pracy jest implementacja systemu

ekspertowego w aplikacji służącej do

obsługi przyjęć pacjentów w szpitalnym oddziale ratunkowym. Zadaniem systemu
eksp

ertowego będzie wspomaganie decyzji medycznych podejmowanych przez

specjalistę medycyny ratunkowej dyżurującego na SOR. System ekspertowy
zostanie

skonstruowany za pomocą e2gRuleEngine. Program e2gRuleEngine jest

darmowym

narzędziem do budowy systemów ekspertowych i został stworzony w

technologii JAVA aplet(ang. Applet)

, która pozwala na obsługę programu w oknie

przeglądarki internetowej. Dzięki takiemu rozwiązaniu możliwe jest zintegrowanie
systemu z aplikacją obsługi pacjentów działającą w technologii klient-serwer.

W pracy nie zostanie opisany program obsługujący przyjęcia, gdyż nie jest to

celem

pracy.

Zostanie użyty do pokazania sposobu wykorzystania

diagnostycznego systemu ekspertowego oraz przetestowania

jego działania.

3 System ekspertowy

Z definicji E.A Feigenbaum

’a wynika, że system ekspertowy to program

komputerowy, którego wbudowane mechanizmy wnioskowania umożliwiają
rozwiązywanie problemów wymagających konsultacji z ekspertem danej dziedziny
wiedzy.

Stopień ekspertyzy zależy od jakości oraz wielkości bazy wiedzy. System

ekspertowy posiada charakterystyczne cechy odróżniające go od innych
programów komputerowych. Należą do nich:



awna reprezentacja wiedzy w większości przypadków zrozumiała dla

użytkownika końcowego w postaci reguł, ram lub sieci semantycznych.



Procedury sterowania odseparowane od wiedzy eksperckiej.



ykorzystanie procesów wnioskowania zamiast jawnie zdefiniowanego

algorytmu.



Możliwość wyjaśnienia metody rozwiązania określonego problemu.

Systemy

ekspertowe

znajdują

głównie

zastosowanie

dziedzinach

niesformalizowanych, gdzi

e nie istnieją ścisłe algorytmy rozwiązania danego

problemu. Do dziedzin tych należą między innymi:



Medycyna



Geologia



Prawo



Administracja i z

arządzanie



Rolnictwo

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011



Leśnictwo



Architektura



Chemia

Okazują się także przydatne przy rozwiązywaniu problemów NP-zupełnych, gdzie
algorytmy obliczeniowe z powodu bardzo długiego czasu działania stają się
zupełnie nie przydatne.

Pierwsze systemy ekspertowe

powstały w latach 60. Poniżej zostały

przedstawione

niektóre systemy, które znacząco przyczyniły się do rozwoju tej

dziedziny.



Dendral - zbudowany

około 1965 roku w Stanford University przez Bruce

Buchanan

’a, Edwarda Feigenbaum’a oraz Joshua Lederberg’a. Był

wykorzystywany do określenia struktury molekularnej nieznanych
chemi

cznych związków organicznych w oparciu o analizę widm

spektroskopowych

. Do budowy systemu Dendral wykorzystano język

programowania

Interlisp. Dendral osiągnął wydajność porównywalną z

ekspertami -

ludźmi dzięki zastosowaniu algorytmu stworzonego przez

Josh

ua Lederberg’a służącego do semantycznego generowania wszystkich

możliwych struktur cząsteczkowych.[7]



Macscyma

– prace nad systemem rozpoczęły się w 1968 roku w

Massachusetts Institute of Technology (MIT), rozwój projektu został
zakończony w 1982 roku. Został napisany w języku MACLisp. System
Macscyma

służył

rozwiązywania

złożonych

problemów

algebraicznych.[8]



Mycin

– stworzony w latach 70 na uniwersytecie w Stanford system

ekspertowy

służący do diagnozowania bakteryjnych chorób krwi,

znalezieniu odpowiedniej terapii

i dawkowania leków w zależności od płci,

wieku i wagi chorego

. Baza wiedzy opierała się na regułach IF - THEN

stworzonych przez grupę lekarzy. Reguły zawierały także współczynniki
pewności, które pozwalały na określenie stopnia niepewności odpowiedzi.
Działanie programu polegało na odpowiadaniu na pytania zadawane przez
system. Po zadaniu około 50-60 pytań system udzielał odpowiedzi. W
każdym momencie działania programu można było sprawdzić dlaczego
zostało zadane dane pytanie(za pomocą polecenia WHY).[9]



Emycin

– projekt powstał w 1981 po usunięciu reguł z bazy wiedzy systemu

Mycin. Dało to możliwość tworzenia własnych reguł. Emycin był pierwszym
szkieletowym systemem ekspertowym.



Prospector

– program był używany do wspomagania zadań wykonywanych

przez geologów. Rozwijany od 1974 do 1983 w Stanford Research Institute.
Baza wiedzy składała się z około 1000 reguł. Dzięki programowi udało się
znaleźć złoża molibdenu.[10]



Internist/Caduceus

– system ekspertowy opracowywany od połowy lat 70

na University of Pittsburgh przez Harry Pople'a Jr. (informatyk) i Jacka D.
Myersa (internista)

. Program wspierał lekarzy w stawianiu diagnozy z

chorób wewnętrznych(interny). Osiągnął 85 % sprawności specjalisty z tej
dziedziny.[11]

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

W Polsce tworzeniem systemów ekspertowych zajmuje się firma AITECH.

Założył ją dr Krzysztof Michalik, który w latach 80 brał udział w tworzeniu
projektów PC-Expert i Diagnosta MC14007. W firmie AITECH powstał pierwszy
komercyjny szkielet systemu ekspertowego o nazwie PC-Shell. PC-Shell jest
narzędziem do budowy systemów ekspertowych z różnych dziedzin takich jak:
finanse, bankowość, diagnostyka, marketing, dydaktyka i wielu innych.

3.1

Podział systemów ekspertowych

Od lat 60 do czasów dzisiejszych wraz z rozwojem informatyki wytworzyło się

kilka podziałów systemów ekspertowych. Systemy ekspertowe dzielimy ze
względu na:



Sposób działania:

 Doradcze

– to czy użytkownik uzna bądź nie zaakceptuje wyniku

wyjściowego(wniosek) sztucznej ekspertyzy, zależy tylko od niego.
W przypadku zanegowania odpowiedzi system ekspertowy poszuka
innego rozwiązania.



Działające autonomicznie(bez kontroli człowieka) – Systemy

działające bez ingerencji człowieka tam, gdzie potrzebna jest szybka
reakcja na zmieniające się warunki(dane) np. systemu ekspertowe
czasu rzeczywistego

sterujące pracą elektrociepłowni.



Krytykujące – do systemu wprowadzane są dane wejściowe i

wyjściowe. Zadaniem systemu jest przeanalizowanie i pokazanie
krok po kroku w jaki sposób dana konkluzja została osiągnięta.



Dane otrzymywane na wyjściu (wnioski systemu):

 Diagnostyczne

– wykorzystywane np. w medycynie, mechanice.

System ocenia bie

żący stan na podstawie otrzymanych danych.

 Prognostyczne(Predykacyjne)

– służą do przewidywania przyszłego

stanu w oparciu o istniejące dane(bieżący stan). Używane przy
prognozowaniu pogody.

 Planowania

– po osiągnięciu wyznaczonego celu planują dalsze

działanie.



Sposób reprezentacji wiedzy:



Logika dwuwartościowa (ang. Boole’a) – fakty i wnioski mają

możliwość przyjęcia tylko jednej z dwóch wartości: prawda lub fałsz.



Logika wielowartościowa – argumenty faktów i wniosków mogą

przyjmować jedną, kilka lub nie przyjmować żadnej wartości.

 Logika rozmyta(ang. Fuzzy logic)

– jeden z rodzajów logiki

wielowartościowej, gdzie między stanem prawda(0) a fałsz(1) istnieje
jes

zcze pewien zbiór wartości.



Realizację projektu systemu ekspertowego:

 Systemy dedykowane

– systemy tworzone zarówno przez inżyniera

wiedzy oraz projektant systemu (definicja w podrozdziale 3.3
„Struktura budowy systemu ekspertowego”). Do zadań inżyniera
wi

edzy należy wypełnienie wiedzą eksperta bazy wiedzy, natomiast

funkcją

projektanta

systemu

jest

zbudowanie

modułów

programu(pod

rozdział 3.3).

 Systemy

narzędziowe(tzw. szkieletowe systemy ekspertowe) –

system ekspertowy z pustą bazą wiedzy. Do budowy systemu
wystarczy inżynier wiedzy, którego celem jest zbudowanie bazy
wiedzy po konsultacji z ekspertem.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011



Przetwarzaną informację:



Systemy z wiedzą pewną – gdy stwierdzenia w bazie wiedzy są

pewne np. logika dwuwartościowa.



Systemy z wiedzą niepewną – prawdziwość niektórych stwierdzeń

jest nie pewna np. logika rozmyta.

3.2

Zalety i wady systemów ekspertowych

Systemy ekspertowe jak każdy program komputerowy posiadają wady i zalety,

poniżej zostało wypunktowane ich zestawienie.
Zalety:



Systemy ekspertowe rozwiązujące problemy w czasie rzeczywistym, gdzie

wymagana jest analiza wielu danych w bardzo krótkim czasie działa lepiej
od człowieka, który nie jest w stanie przeanalizować tylu danych
jednocześnie. Systemy takie znajdują zastosowanie np. przy sterowaniu
elektrowni

ą atomową, systemami stacji lub statków kosmicznych.



Możliwe jest zgromadzenie wiedzy kilku ekspertów jednocześnie, co

pozawala na ograniczenie kosztów zatrudnienia oraz pozwala
użytkownikowi systemu na efektywniejszą pracę.



System ekspertowy tylko prezent

uje swoje rozwiązania użytkownikowi, to

czy użytkownik skorzysta z rozwiązania zależy tylko od niego.



Czas eksperta może być wykorzystany do rozwiązania trudniejszych

problemów. Łatwiejsze, często powtarzające się rozwiąże system
ekspertowy bez obecności specjalisty.



Sprawność systemu zależy głównie od jakości i ilości wiedzy zapisanej w

bazie wiedzy a nie od metody wnioskowania.



Modułowa budowa i oddzielenie bazy wiedzy od reszty systemu pozwala na

wprowadzanie zmian bez naruszania integracji całego systemu
ekspertowego.

Wady:



Zrobienie jakościowo i ilościowo dobrej bazy wiedzy wymaga stałej

obecności eksperta, czasu oraz nakładów finansowych. Zaprojektowanie
systemu ekspertowego jest opłacalne tylko wtedy, gdy będzie on używany
przez dłuższy okres czasu i dużą grupę osób.



Ograniczenie „dialogu” z programem w wyniku używania klawiatury.



System ekspertowy w porównaniu do specjalisty z danej dziedziny nie

potrafi sam rozszerzać swojej wiedzy. Jest całkowicie zależny od
użytkownika.



Nie zawsze wiedza eksperta

może być zapisana w sztywnych ramach

prezentacji wiedzy(reguły, ramy, sieci semantyczne).



Uzupełnianie faktów i reguł w bazie wiedzy może doprowadzić do

powstania błędów, co utrudni lub uniemożliwi poprawne działanie systemu.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Zalety i wady systemów ekspertowych wynikają również z porównania

ekspertyzy sztucznej i naturalnej. Za ekspertyzę naturalną odpowiada człowiek,
specjalista z danej dziedziny natomiast ekspertyza sztuczna jest wynikiem
działania programu komputerowego(systemu ekspertowego). Tabela 1 porównuje
zalety i wady tych dwóch ekspertyz.

Tab. 1

. Porównanie ekspertyzy sztucznej z naturalną.

Ekspertyza naturalna

Ekspertyza sztuczna

Zalety



twórcza (oparta na wiedzy i
intuicji)



trudna w dokumentacji



adaptacyjna



wykorzystanie wszystkich

zmysłów



szeroki zakres



stała, nie traci na wartości z
upływem czasu



łatwa w dokumentacji



łatwo

dostępna

(nie

jest

wymagana obecność eksperta z
danej dziedziny)



zgodna z bazą wiedzy

Wady



utrudniona dokumentacja



z upływem czasu występuje
utra

ta wartości ekspertyzy



kosztowna



nie dająca się przewidzieć



wąski zakres zgodny z faktami i
regułami zawartymi w bazie
wiedzy



przetwarzanie wiedzy w sposób
mechaniczny

3.3 Struktura budowy systemu ekspertowego

W celu zrozumienia struktury systemu ekspertowe

go należy wyjaśnić rolę ludzi,

którzy współdziałają z systemem:



Ekspert z danej dziedziny

– według definicji zawartej w „Nowym słowniku

języka polskiego” to „specjalista powołany do wydania orzeczenia lub opinii
w sprawach spornych, wchodzących w zakres jego kompetencji; biegły,
rzeczoznawca.”[1]



Inżynier wiedzy – to osoba zajmująca się kodowaniem wiedzy przekazanej

przez eksperta w formę deklaratywną możliwą do użycia przez system
ekspertowy[12]



Użytkownik – osoba korzystająca z systemu ekspertowego z zamiarem

uzyskania porady, którą mógł by uzyskać od eksperta z danej dziedziny.

W przypadku systemów dedykowany, gdy do budowy systemu ekspertowego

nie jest wykorzystywany szkielet(ang. Shell) dochodzi jeszcze jedna ważna rola:



Projektant systemu

(inżynier systemu) – informatyk, którego celem jest

zaprojektowanie i zbudowanie modułów systemu ekspertowego.

W zależności od wielkości projektu inżynier wiedzy i inżynier systemu może być
tą samą osobą.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Systemy ekspertowe mają ściśle określoną budowę. Jest to wzorzec projektowy

według, którego należy konstruować te systemy.

Rys. 1. Struktura systemu ekspertowego.

Systemów ekspertowych nie należy mylić z systemami z bazą wiedzy. Systemy

z bazą wiedzy nie posiadają modułu wyjaśniającego.

3.3.1 Baza wiedzy

Zawiera

wiedzę eksperta przetworzoną przez inżyniera wiedzy i zgromadzoną w

postaci sformalizowanej(reguły, ramy, sieci semantyczne), tak, aby mogła zostać
odczytana przez mechanizm wnioskujący systemu ekspertowego. Ważną zasadą
jest niesprzeczność i spójność przekształconej wiedzy. Nie zachowanie tej zasady
przez inżyniera wiedzy może doprowadzić do utrudnienia bądź całkowitego braku
działania program. Rozróżniamy następujące rodzaje baz wiedzy:



Baza tekstów (ang. Text base) – składa się z nieuporządkowanych danych.



Baza danych (ang. data base)

– struktura zawierająca dane ułożone w

sposób uporządkowany



Baza reguł (ang. Rule base) – jej zawartość stanowi wiedza zapisana w
postaci reguł z wybranej dziedziny



Baza modeli (ang. Model base)

– obejmuje modele matematyczne danej

dziedziny.



Baza wiedzy zdroworozsądkowej (ang. Common sense knowledge base) –
gromadzi reguły potencjalnych i racjonalnych działań człowieka.
O

dzwierciedla meta wiedzę systemu, czyli jak przetwarzać wiedzę zawartą

w systemie ekspertowy.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Większości przypadków występuje baza reguł. O to przykład reguły w tym typie

bazy wiedzy: IF rozrusznik nie odpala silnika AND wyczuwasz zapachu benzyny
THEN zbiornik paliwa jest pusty.

Budowa reguły z zaznaczonymi słowami kluczowymi zostanie opisane w

następnym podrozdziale 3.4 „Reprezentacja wiedzy”).

3.3.2

Baza faktów

Inaczej pamięć podręczna lub baza danych zmiennych. Baza pomocnicza, w

niej zapisywane są fakty oraz wnioski w trakcie użytkowania przez użytkownika
systemu ekspertowego. Baza faktów umożliwia także działanie mechanizmu
wyjaśniającego.

3.3.3

Mechanizm wnioskujący

Stanowi najważniejszą część systemu ekspertowego. „Maszyna wnioskująca

jest modułem, który wykorzystuje odpowiednie sposoby wnioskowania w celu
znalezienia rozwiązania lub postawienia diagnozy”.[2] Metody wnioskowania to
algorytmy pozwalające doprowadzić konsultację do konkluzji na podstawie faktów
i reguł zawartych w bazie wiedzy oraz danych odbieranych przez użytkownika.

3.3.4

Mechanizm wyjaśniający

Udostępnia opcję sprawdzenia w każdym momencie konsultacji dlaczego

została użyta dana reguła lub zadane pytanie. Jest niezwykle przydatny dla
inżyniera wiedzy w trakcie projektowania systemu ekspertowego. Sprawdzając
wyniki wnioskowania za pomocą mechanizmu wnioskowania inżynier może
sprawdzić jak zachowuje się system ekspertowy oraz sprawdzić współdziałanie
faktów i reguł.

Rys. 2

. Moduł wyjaśniający programu PC-Shell.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

3.3.5 Edytor bazy wiedzy

Pozwala użytkownikowi na uzupełnianie wiedzy przez wprowadzanie nowych

faktów i reguł do bazy wiedzy systemu ekspertowego. Powinien zawierać
mechanizm sprawdzający poprawność i niezgodność reguł w celu zapewnienia
bezbłędnego działania systemu.

Rys. 3. Edytor e2gRuleWriter do budowy bazy wiedzy dla e2gRuleEngine.

3.3.6

Interfejs użytkownika

Bez tego modułu nie mogłaby istnieć interakcja użytkownika z pozostałymi

częściami systemu ekspertowego oraz bazą wiedzy. Stanowi mechanizm
wejścia/wyjścia.

Odbiera

dane

użytkownika

zwracając

rezultaty

przeprowadzonego działania na bazie wiedzy przez mechanizm wnioskujący.
Odpowiada także za obsługę edytora bazy wiedzy.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Rys. 4

. Interfejs systemu ekspertowego zbudowanego za pomocą narzędzia

e2gRuleEngine.

3.4 Etapy tworzenia systemu ekspertowego

W procesie bu

dowy systemu ekspertowego zazwyczaj biorą udział trzy grupy

osób: eksperci, inżynierowie wiedzy i użytkownicy. Osoby te współpracują ze
sobą w trakcie trwania różnych okresów tworzenia systemu. Proces ten został
p

rzedstawiony na rysunku numer 5 i składa się z:



Identyfikacji problemu

– odbywa się przy współpracy eksperta z inżynierem

wiedzy. Polega na zdefiniowaniu celu oraz wymagań konstruowanego
systemu ekspertowego. Problem stawiany przed systemem ekspertowym
powinien charakteryzować się:



zawężoną specjalizacją,



musi być dokładnie zdefiniowany,



do rozwiązania problemu wykonywane są operacje na symbolach

(brak jawnego algorytmu rozwiązania).

Dla ułatwienia identyfikacji powinien zostać stworzony raport zawierający:

 Cel

– definicja zadań stawianych przed systemem ekspertowym.



Rozwiązanie – określa wynik działania systemu.



Wiedzę – źródło wiedzy z danej dziedziny (najczęściej jest nim
ekspert).

Istnieje prawdopodobieństwo braku dostępności eksperta z

danej dziedziny. W tym przypadku należy określić inne źródła
wiedzy.

 Zapotrzebowanie

– określenie grupy ewentualnych kupujących.



Infrastrukturę – środowisko sprzętowe potrzebne do działania
systemu.

 Koszty

– ekonomiczne uzasadnienie projektu.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Rys. 5. Etapy tworzenia systemu ekspertowego.



Pozyskiwanie wiedzy

– na tym etapie produkcji systemu ekspertowego

inżynier wiedzy dokumentuje wiedzę, po wcześniejszym rozpoznaniu
dziedziny w procesie identyfikacji problemu, przekazaną przez eksperta. W
przypadku niemożliwości uzyskania wiedzy od eksperta można skorzystać
z innych

źródeł do, których zaliczamy:



literaturę,

 dokumentacj

ę,

 bazy i hurtownie danych,
 eksperymenty.

Proces pozyskiwania wiedzy składa się z dwóch etapów: nabywania i
dokumentowania wiedzy z danej dziedziny oraz modelowania nabytej
wiedzy. Faza nabywania i dokumentowania polega na:



rozbiciu problemów na podproblemy,



ustaleniu faktów w postaci obiektów, atrybutów i wartości oraz

udokumentowaniu relacji jakie zachodzą między faktami,



znalezieniu rozwiązania problemu.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Modelowanie nabyt

ej wiedzy to projekt jawnego wzorca, który w dalszym

cyklu projektowania systemu pozwoli na sformalizowanie informacji
nabytych od eksperta w celu przeniesienia ich do bazy wiedzy. W
modelowaniu występują następujące metody:

 Diagram Obiekt - Atrybut - Wart

ość(ang. Object - Attribute - Value, w

skr

ócie OAV) – służy do opisywania rzeczywistych obiektów.

Upraszczają formalizowanie faktów w bazie danych.

Rys. 6

. Diagram OAV obiektu Książka.

 Tabela decyzyjna -

łatwa i czytelna metoda zapisywania wiedzy

zarówno dla inżyniera wiedzy jak i eksperta. Zbudowana jest z
wierszy

zawierających warunki i czynności. Stanowi jawny i

klarowny zapis warunków, które należy spełnić, aby mogła zostać
wykonana czynność.

Tab. 2. Tablica decyzyjna

Warunki

Okłada

Miękka Miękka Miękka Twarda Twarda Twarda

Wielkość

Mała

Średnia Duża

Mała

Średnia Duża

Cena

Tania

Droga

Czynności
Kupić

Nie

Tak

Nie

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

 Drzewa decyzyjne

– składają się z węzłów i gałęzi. Węzły definiują

podejmowane decyzje lub zmiany stanu rzeczy natomiast gałęzie
określają podjęte akcje. Do jednego węzła prowadzi tylko jedna
gałąź

Rys. 7. Drzewo decyzyjne.



Diagram przepływu – zbudowane podobnie jak drzewa decyzyjne, z

tą różnicą, że do jednego węzła może prowadzić wiele gałęzi.

Rys. 8

. Diagram przepływu.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011



Reprezentacja wiedzy

– formalizowanie modelu wiedzy eksperta. Szerszy

opis w pod

rozdziale 3.5 „Reprezentacja wiedzy”.



Implementacja systemu

– opracowanie gotowego systemu ekspertowego.

Wprowadzenie, przez inżyniera wiedzy, sformalizowanej wiedzy do bazy
wiedzy szkieletowego bądź dedykowanego systemu ekspertowego.



Testowanie systemu

– weryfikacja poprawności działania systemu. W

test

ach może uczestniczyć użytkownik.

3.5 Reprezentacja wiedzy

Działanie systemu ekspertowego zależy od jakości i ilości informacji zawartych

w bazie wiedzy, która składa się z odpowiednio przetworzonych i
sformalizowanych faktów i heurystyk tak, aby umożliwić wnioskowanie. Fakt to
określenie stanu rzeczy, zjawisko, które zachodzi lub zaszło w rzeczywistości. [1]
Heurystyki natomiast,

stanowią sposób rozwiązywania problemów przez

ekspertów biorących pod uwagę zaistniałe fakty. W bazie wiedzy heurystyki
występują pod postacią relacji i procedur. Relacje obejmują zależności między
dwoma lub większą liczbą faktów, z kolei procedury to mechanizmy jakim
podlegają fakty i relacje. Do najczęściej używanych technik reprezentowania
należą:



Sieci semantyczne

– to graficzna interpretacja, w postaci grafu, relacji i

asocjacji

zachodzących między stwierdzeniami oraz ich składowymi.

Stwierdzenia zapisywane są w postaci trójki: obiekt – atrybut - wartość, które
można przedstawić za pomocą diagramu OAV(rys. 7.). Sieć semantyczna
składa się z węzłów i łuków. Węzły mogą oznaczać obiekty, atrybuty
obiektów lub wartości atrybutów. Natomiast łuki służą do opisywania relacji
jakie zachodzą między węzłami. Sieci semantyczne mogą być także
wykorzystane do reprezentacji wiedzy niepewnej przez dodanie wag do
węzłów i łuków.[3] Zaleta tej techniki reprezentacji to przedstawienie wiedzy
w formie graficznej co przemawia do wyobraźni, jest intuicyjne i efektywne.

Rys. 9

. Przykład sieci semantycznej.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011



Reguły produkcyjne – większość systemów ekspertowych opartych jest o tę
technikę reprezentacji wiedzy, gdyż posiada wiele zalet takich jak:



bardzo zrozumiały zapis,

 prosta modyfikacja bazy wiedzy przez dodanie nowych

lub zmianę

istniejących reguł,



ułatwione rozwiązanie problemu przez właściwy dobór grupy reguł.

Reguły mają postać:

JEŻELI (Warunek) TO (Konkluzja)

Standardowo w bazie wiedzy zapisywane są w postaci kanonicznej(język
angielski):

IF(Warunek)THEN(Konkluzja)

Konkluzja(wniosek) to następstwo spełnienia(wystąpienia) warunku.
Warunki i wnioski składają się z par atrybut – wartość. Przykład:

Zwierzę jest Wróbel THEN Zwierzę ma gniazdo

Zwierzę jest Wróbel THEN Zwierzę jest Ptak

Zwierzę jest Ptak THEN Zwierzę ma Skrzydła

Możliwe jest łączenie kilku warunków oraz konkluzji za pomocą koniunkcji
oraz alternatywy. Koniunkcja to iloczyn logiczny, którego symbolem jest
AND

. W tym wypadku reguły mają postać:

Zwierzę jest Ptak THEN Zwierzę ma Pióra AND Zwierzę ma Skrzydła

IF Ptak ma Gniazdo AND

Ptak jest Mały THEN Ptak jest Wróbel

IF Ptak ma Gniazdo AND

Ptak jest Mały THEN Ptak jest Wróbel

AND

Wróbel ma Skrzydła

Alternatywa, inaczej suma logiczna, jest reprezentowana przez symbol OR i
reguły prezentują się następująco:

Zwierzę ma Gniazdo OR Zwierzę ma Pióra THEN Zwierzę jest Ptak

Zwierzę jest Ptak THEN Zwierzę jest Małe OR Zwierzę jest Średnie

Zwierzę ma Gniazdo OR Zwierzę ma Pióra THEN Zwierzę jest Małe OR

Zwierzę jest Średnie

Reguły produkcyjne mogą się zagnieżdżać. Sytuacja taka występuje wtedy,
gdy konkluzja(wniosek)

jednej reguły jest warunkiem(przesłanką) innej.

Prowadzi to do podziału warunków na możliwe do zapytania, których
wartość ustalana jest przez odpowiedź użytkownika na zapytanie systemu
ekspertowego oraz warunki wynikające z konkluzji innej reguły. Pozwala to
na ograniczenie zapytań i skrócenie czasu konsultacji.

Baza wiedzy

może zawierać wiedzę niepewną, w tym wypadku wzór

reguły wygląda następująco:

JEŻELI (Warunek) TO (Konkluzja)(CF)

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Współczynnik pewności ( ang. certainty factors lub confidence factors, w
skrócie CF) to wartość wyrażona w liczbach. Zbiór wartości jakie może
przyjmować, określa szkielet systemu ekspertowego. Do opisania metod
współczynnika zostaną użyte procenty z przedziału <0%,100%>, dla
warunku A współczynnik ten wynosi 60%, warunek B ma 80%.
Metody obliczania współczynnika pewności:

 Minimum

– pod uwagę brana jest najmniejsza wartość współczynnika

wartości warunków. W tym wypadku CF konkluzji wynosi 60%.

 Maksimum

– CF wynosi tyle, ile największy współczynnik warunku.

CF konkluzji ma 80%.



Średnia – współczynnik pewności obliczany jest na zasadzie średniej
arytmetycznej współczynników warunków. CF równe jest 70%.

 Suma probabilistyczna

– wzór na obliczanie współczynnika pewności

wygląda następująco:

CF= A+(B/100)*(100-A)

Po podstawieniu wartości A i B otrzymujemy wynik CF konkluzji, który
jest równy 92%.

 Iloczyn

– Obliczenia polegają na pomnożeniu dwóch CF przesłanek



Ramy

– to strukturalny opis danych. Rama(rys. 10.) reprezentuje obiekt,

który posiada atrybuty i wartości. Atrybuty, czyli cechy obiektu, zapisywane
są w klatkach (ang. Slot), wartości w fasetach(ang. Facet). Klatki jednego
obiektu nie mogą się powtarzać, fasety w jednej klatce nie mogą mieć tej
samej nazwy.

Rys. 10

. Przykładowa rama.

Relacje między ramami określone są przez hierarchię dziedziczenia, czyli
istnieją ramy podstawowe, podrzędne i nadrzędne. Wynik wnioskowania jest
rezultatem przechodzenia przez tę hierarchię.

3.6 Mechanizm wnioskowania

Istnieją dwa główne typy metod wnioskowania:



wnioskowanie w tył(ang. Backward chaining),

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011



wnioskowanie w przód (ang. Forward chaining).

Oba mechanizmy zostaną opisane w kolejnych podrozdziałach. Baza wiedzy, na
której zostanie przeprowadzone wnioskowanie będzie składać się z reguł z wiedzą
pe

wną. W systemie ekspertowym o nazwie AWARIA została zaimplementowana

następująca baza wiedzy:

Tab. 3. Baz wiedzy programu AWARIA.
Numer
reguły

Treść
reguły

Jeżeli światła po włączeniu nie świecą i
rozrusznik po przekręceniu kluczyka nie zaskakuje
to zalecana

czynność polega na naładowaniu lub zmianie akumulatora

Jeżeli zbiornik paliwa jest pusty
to zalecana

czynność polega na napełnieniu baku samochodu paliwem

Jeżeli rozrusznik po przekręceniu kluczyka zaskakuje powoli i

moc świecenia świateł jest słaba

to zalecana

czynność polega na naładowaniu akumulatora

Jeżeli rozrusznik po przekręceniu kluczyka zaskakuje i
zapach paliwa w baku jest obecny
to zalecana

czynność polega na odczekaniu 10 minut i ponownemu

uruchomieniu zalanego samochodu

Jeżeli rozrusznik po przekręceniu kluczyka zaskakuje i
zapach paliwa w baku jest nie obecny
to zbiornik paliwa jest pusty.

Reguły w trakcie wnioskowania będą zmieniały swój stan. Reguła nie sprawdzona
przez system będzie aktywna, natomiast sprawdzona, której konkluzja nie
zostanie potwierdzona zmieni status na odrzuconą. Gdy wniosek okaże się
prawdziwy reguła stanie się odpalona. Stan przechowywany jest w bazie faktów.

3.6.1 Wnioskowanie wstecz

Wnioskowanie wstecz(ang. hypothesis driver), czyli wnioskowanie dedukcyjne,

to p

roces polegający na potwierdzeniu prawdziwości hipotezy na podstawie

przesłanek. Hipoteza to cel lub inaczej rozwiązanie problemu stawianego przed
systemem ekspertowym.

Przesłanka jest traktowana jako nowa hipoteza w

przypadku, gdy użytkownik nie zna jej wartości lub stanowi konkluzję innej
reguły(zagnieżdżanie reguł). W trakcie działania systemu algorytm wnioskowania
wstecz szuka przesłanek potwierdzających nowe hipotezy dopóki nie zostaną
znalezione wartości przesłanek reguły, której konkluzja stanowi cel. Do
przechowywania celu(ang. Goal)

głównego oraz nowych hipotez(ang. Subgoal)

służy stos. Stos(rys. 12 na stronie 22) to struktura danych, w których ostatni
element dołączony do struktury jest pierwszym elementem do zdjęcia ze
stosu(bufor typu LIFO ang. last in, first out).

Wnioskowanie wstecz działa dopóki

na stosie nie zostanie główny cel i nie ma więcej reguł aktywnych które mogły by
dołączyć nowe hipotezy.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Rys. 11. Schemat blokowy wnioskowania wstecz.

Użytkownik zamierza znaleźć przyczynę awarii samochodu. W tym celu używa

nasz system ekspertowy AWARIA z bazą wiedzy przedstawioną w tabeli 3. Celem
wnioskowania jest znalezienie rozwiązania co zrobić, aby uruchomić samochód.
Moduł wnioskowania umieszcza cel na stosie(zalecana czynność) i sprawdza
pierwszą aktywną regułę, której konkluzja jest celem. Reguła pierwsza zawiera
sprawdzaną hipotezę i nie zagnieżdża się. System oczekuje podania wartości
przesłanek przez użytkownika. Odpowiedzi użytkownika i stos celów przedstawia
tabela numer 4.

Tab. 4

. Rozpoczęcie wnioskowania wstecz.

Fakty

Atrybut

Wartość

Światła

świecą

Rozrusznik

zaskakuje

Cel główny wnioskowania

zalecana czynność

Stos celi

zalecana czynność

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Z odpo

wiedzi użytkownika wynika, że światła świecą i rozrusznik zaskakuje,

więc reguła pierwsza zmienia stan z aktywnej na odrzuconą. Konkluzja tej reguły
nie spełnia przesłanek. Pod uwagę jest brana następna aktywna reguła
zawierająca cel znajdujący się na szczycie stosu, jest to reguła numer dwa.
System ekspertowy próbuje ustalić jaką wartość ma atrybut zbiornik paliwa.
Użytkownik nie wie czy w zbiorniku znajduje się paliwo, więc algorytm wnioskujący
dodaje nową hipotezę na wierzchołku stosu(tab. 5), a reguła druga nadal
pozostaje aktywna.

Tab. 5. Kolejny etap wnioskowania wstecz.

Fakty

Atrybut

Wartość

Światła

świecą

Rozrusznik

zaskakuje

Zbiornik paliwa

nie wiem

Cel główny wnioskowania

zalecana czynność

Stos celi

2. zbiornik paliwa
1.

zalecana czynność

Na szczycie stosu znajduję się teraz zbiornik paliwa. System przeszukuje bazę

wiedzy w celu odnalezienia reguł aktywnych, których atrybut wniosku to zbiornik
paliwa. W wyniku tego działania zostaje sprawdzona reguła piąta. Reguła zawiera
dwa warunki. Pierwszy z nich, atrybut rozrusznik, znajduje się już w bazie faktów i
jest prawdziwy,

natomiast drugi wymaga odpowiedzi użytkownika. Według

użytkownika zapach paliwa w baku nie jest obecny. Reguła piąta spełniła
przesłanki, więc wartość zbiornika paliwa w bazie faktów zmieniana jest na pusty.
Atrybut zbiornik paliwa ściągany jest ze szczytu stosu.

Tab. 6

. Wnioskowanie wstecz po usunięciu ze stosu atrybutu zbiornik paliwa.

Fakty

Atrybut

Wartość

Światła

świecą

Rozrusznik

zaskakuje

Zbiornik paliwa

nie wiem

Cel główny wnioskowania

zalecana czynność

Stos celi

zalecana czynność

wierzchołku stosu znowu znajduje się zalecana czynność, więc kolejny raz

zostaje sprawdzona pierwsza reguła aktywna z celem głównym wnioskowania w
konkluzji, jest to ponownie reguła druga. Tym razem jej warunki pasują do faktów
w pamięci podręcznej systemu ekspertowego. Zostaje znaleziona wartość
głównego celu wnioskowania przy pominięciu reguł: czwartej i piątej. Zalecana
czynność polega na napełnieniu baku samochodu paliwem.
Przykład wnioskowania wstecz ukazuje jego zalety. Wnioskowanie dedukcyjne nie
wymaga sprawdzenia wszystkich reguł w bazie wiedzy co powoduje
wygenerowanie mniejszej ilości faktów w wyniku czego oszczędzana jest pamięć
podręczna komputera oraz krótki czas ekspertyzy.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Rys. 12

. Schemat działania stosu celi modułu wnioskowania.

3.6.2

Wnioskowanie w przód

Wnioskowanie w przód(ang. Data driven), inaczej wnioskowanie indukcyjne,

rozpoczyna się od sprawdzenia faktów znajdujących się w bazie faktów(pamięci
p

odręcznej) systemu ekspertowego i porównaniu ich z częścią reguł

odpowiedzialną za warunki(IF). Reguła spełniająca warunki zostaje, przez
mechanizm wnioskujący, oznaczona jako prawdziwa, a jej konkluzja jest
dodawana do pamięci podręcznej. W trakcie trwania procesu wnioskowania fakty
mogą być także usuwane z pamięci podręcznej. Nowe fakty są generowane
dopóki nie zostanie znaleziony konkluzja lub nie zostaną wygenerowane nowe
fakty

(zbiór reguł aktywnych będzie pusty). Istnieje prawdopodobieństwo

wystąpienia kilku reguł do odpalenia. Wybranie odpowiedniej możliwe jest przez
użycie strategii sterowania wnioskowaniem. Należą do nich:



Strategia świeżości – najpóźniej dodana reguła do bazy faktów ulega
odpaleniu.



Strategia blokowania

– reguły już wykorzystane są usuwane z bazy faktów

co zapobiega powstawaniu pętli wnioskowania.



Strategia specyficzności – wybierana jest reguła o największej liczbie
warunków.



Strategia pierwszej reguły – pierwsza reguła, której warunki zostają
spełnione zmienia stan na odpaloną



Strategia przypadkowości – wybranie reguły w sposób losowy. Używana
jako strategia pomocnicza po wykorzystaniu jednej

z wcześniej

wymienionych strategii.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Rys. 13. Diagram wnioskowania indukcyjnego.[13]

Użytkownik ponownie zamierza skorzystać z programu AWARIA, tym razem w

systemie zaimplementowane jest wnioskowanie w przód. Aby program rozpoczął
inferencję opartą na tym algorytmie, w pamięci podręcznej systemu muszą
znaleźć się fakty. Użytkownik udzielił odpowiedzi na pytania o: światła, rozrusznik,
zbiornik paliwa, moc świecenia świateł, zapach paliwa w baku. Odpowiedzi i cel
wnioskowania przedstawia tabela 4.

Tab. 7

. Wnioskowania w przód. Ustalenie faktów przez użytkownika

Fakty

Atrybut

Wartość

Światła

świecą

Rozrusznik

zaskakuje

Zbiornik paliwa

nie wiem

Moc świecenia świateł

w normie

Zapach paliwa w baku

nie obecny

Cel

zalecana czynność

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

System rozpoczyna wnioskowanie po ustaleniu

wartości faktów przez

użytkownika. Warunki reguły pierwszej nie zostały spełnione, aby ją potwierdzić,
gdyż światła samochodu święcą i rozrusznik zaskakuje. Reguła ta jest usuwana ze
zbioru reguł aktywnych. Reguła druga nadal pozostaje oznaczona jako aktywna,
ponieważ użytkownik nie wie czy zbiornik paliwa jest pusty. Fakty zapisane w
pamięci podręcznej także nie spełniły przesłanek reguły trzeciej i czwartej, więc
ich wnioski

nie zostały potwierdzone(reguły zostały odrzucone). Warunki ostatniej

reguły zostały osiągnięte. Z konkluzji tej reguły wynika, że zbiornik paliwa jest
pusty, w skutek tego dochodzi do aktualizacji bazy faktów i aktualizacji wartości
atrybutu zbiornik paliwa.

Odpalenie tej reguły powoduje jej usunięcie ze zbioru

reguł aktywnych.

Tab. 8. W

nioskowanie w przód. Aktualizacja bazy faktów.

Fakty

Atrybut

Wartość

Światła

Świecą

Rozrusznik

Zaskakuje

Zbiornik paliwa

Pusty

Moc świecenia świateł

w normie

Zapach paliwa w baku

nie obecny

Cel

zalecana czynność

Reguła druga, nadal aktywna, ulega ponownemu sprawdzeniu i zostaje odpalona.
Zbiornik paliwa

jest pusty, więc zalecana czynność polega na napełnieniu baku

samochodu paliwem

. System AWARIA wyświetla za pomocą interfejsu

użytkownika rozwiązanie problemu. W tym wypadku wnioskowanie jest
przerywane, ponieważ cel został osiągnięty i nie ma więcej reguł aktywnych do
sprawdzenia.

Wnioskowanie w przód doskonale sprawdza się systemach pracujących bez

kontroli użytkownika gdzie dane, czyli fakty, zbierane są automatycznie lub gdy
wymaga

ne jest podanie wszystkich informacji przez rozpoczęciem wnioskowania

np.

ankieta. Wadą wnioskowania indukcyjnego jest możliwość całkowitego

zapełnienia pamięci operacyjnej komputera przez dodanie znacznej ilości faktów
do pamięci podręcznej systemu ekspertowego.

Opis narzędzia e2gRuleEngine do budowy systemów
ekspertowych

Aplet e2gRuleEngine(v8.01) to szkiel

etowy system ekspertowego dostępny za

darmo

stornie

http://expertise2go.com

. Budowa własnego systemu

ekspertowego polega na

uzupełnienia bazy wiedzy informacjami interesującej nas

dziedziny wiedzy. Baza wiedzy zapisywana jest w osobnym pliku. System
zbudowany w oparciu o e2gRuleEngine może być uruchamiany w trzech różnych
środowiskach:



przez

wywołanie w przeglądarce strony internetowej, która uruchamia

e2gRuleEngine jako plik odczytywany bezpośrednio z dysku twardego
komputera,



na lokalnym serwerze internetowym np. Apache Web serwer,

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011



używając publicznego serwera internetowego i udostępniając system

ekspertowy s

zerszemu gronu użytkowników.

Do uruchomienia e2gRuleEngine w na stronie WWW potrzebny jest odpowiedni
kod napisany w języku HTML oraz wirtualna maszyna Javy zainstalowana na
komputerze użytkownika. Kod HMTL wygląda następująco:

<applet code="e2gRuleEngine.class" archive="e2gRuleEngine.jar" width="700"
height="420">
<param name="KBURL" value="'nazwa_bazy_wiedzy.kb">
</applet>

Znaczniki

<applet>..</applet>

pozwalają

uruchomić

szkielet

systemu

ekspertowego w oknie przeglądarki. Pierwszy wymaga podania atrybutów,
którymi są:



code

– należy podać nazwę skompilowanej klasy apletu z rozszerzeniem

.class,



archive

– atrybut wymagany w przypadku e2gRuleEngine, gdyż klasy

app

letu spakowane są w archiwum

.jar,



width

– w której podajemy szerokość wyświetlanego apletu,



height

– określa wysokość apletu.

Archiwum e2gRuleEngine musi zostać wywołane z jednym parametrem o nazwie
KBURL,

którego wartość określa ścieżkę do bazy wiedzy zapisanej w osobnym

pliku o rozszerzeniu .kb. Pozwoli to na odnalezienie bazy wiedzy przez
mech

anizm wnioskujący. Opis innych parametrów można znaleźć na stronie

http://expertise2go.com/e2g3g/e2g3gdoc/e2gref.htm

Baza wiedzy systemu ekspertowego czytelna

dla modułu wnioskującego

e2gR

uleEngine musi być zapisana w postaci reguł produkcyjnych(podrozdział 3.4

„Reprezentacja wiedzy”), mających odpowiedni dla narzędzia format. Przesłanki i
konkluzje zapisywane są w postaci pary: atrybut – wartość. Wartości atrybutów
mogą stanowić jeden z trzech różnych typów:



ekstowy zawarty między cudzysłowami.



Numeryczny(ang. Numeric)

, która może być liczbą całkowitą lub

rzeczywist

ą.



Logiczny (ang. Boolean) przyjmujący wartość TRUE albo FALSE.

Typ atrybutu jest inicjowany, gdy po raz pierwszy zostanie

użyty w regule w trakcie

wnioskowania. Próba zmiany typu atrybutu po jego wcześniejszy ustaleniu
zakończy się błędem. Analogiczny błąd wystąpi przypadku pierwszego
wystąpienia atrybutu stwierdzeniach PROMPT i GOAL, które zostaną omówione
w dalszej części tego rozdziału.

W bazie wiedzy występują takie elementy jak: puste linie, jednoliniowe

komentarze, reguły, zapytania, stwierdzenia wyznaczające cel wnioskowania i
wartości domyślne atrybutów. Jednoliniowe komentarze podobnie jak puste linie
(linie tekstu zacz

ynającego się od słowa REM) są

ignorowane

przez moduł

wnioskujący. Reguły składają się z kilku elementów, każdy element występuje w
nowej linii.

Pierwsza linia reguły rozpoczyna się od stwierdzenia RULE, po którym

występuje nazwa reguły zamknięta w kwadratowych nawiasach. Początek
następnej linii stanowi przesłanka reguły, której początkiem jest słowo IF. Po nim
występuje atrybut zawarty w nawiasach kwadratowych połączony z wartością za
pomocą jednego z operatorów opisanych w tabeli. Jeżeli występuje więcej niż
jedna

przesłanka, to muszą być one połączone przez ten sam logiczny operator,

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

AND(iloczyn logiczny) lub OR(suma logiczna).

Każda przesłanka składająca się z

atrybutu, operatora i wartości musi znajdować się w oddzielnej linii. W przypadku
większej liczby warunków ten sam operator logiczny znajduje się na końcu każdej
przesłanki oprócz ostatniej. Linia występująca po ostatniej przesłance musi
zaczynać się od słowa THEN. Słowo to inicjuje część reguły odpowiedzialną za
konkluzję. Po THEN musi wystąpić nazwa atrybutu w kwadratowych nawisach z
przypisaną wartością za pomocą znaku równości(=), inne operatory z tabeli numer
9 traktowane są jako błąd. Do powiązania większej ilości wniosków służy operator
AND. Suma logiczna(OR

) powoduje wystąpienie błędu i zakończenie działania

programu.

Linia konkluzji, która nie jest zakończona słowem AND kończy ciało

reguły. Opcjonalnie można dołączyć do reguły współczynnik pewności(CF) przez
dodanie znaku @ i liczby z przedziału od 1 do 100 po wartości atrybutu konkluzji.

Tab. 9

. Operatory przypisania wartości atrybutu.

Operator Znaczenie operatora

rzykład

równy

[zbiornik paliwa] =

”pusty”

zbiornik paliwa jest pusty

mniejszy

[cena] < 120
cena jest mniejsze niż 120

mniejszy lub równy

[cena] <= 50
cena jest mniejsza niż lub równa 50

większy

[cena] > 150
cena jest

większa niż 50

większa lub równa

[cena] >= 80
cena jest większa lub równa 80

nie równa

[zbiornik paliwa] !

”pusty”

zbiornik paliwa nie jest pusty

nie równa(od v8.0)

[zbiornik paliwa] <>

”pusty”

zbiornik paliwa nie jest pusty

nie równa(od v8.0)

[zbiornik paliwa] !=

”pusty”

zbiornik paliwa nie jest pusty

równy jednej wartości z
(tylko typ tekstowy)

[

objawy] : ból, gorączka

ednym z objawów jest ból lub gorączka

nierówny

żadnej

wartości z
(tylko typ tekstowy)

[objawy] : ból, gorączka
żadnym z objawów nie jest ból lub gorączka

Reguła skonstruowana według wyżej wymienionych informacji powinna wyglądać
w sposób następujący:

RULE [Zawał serca z wstrząsem kardiogennym?]
If [Ból w klatce zawałowy] = true and
[STEMI] = false and
[NSTEMI] = true and
[Troponiny] > 0.03 and
[Ocena psycho-

ruchowa] = "splątany" and

[Wypełnienie tętna] = "nitkowate" and
[Napięcie tętna] = "miękkie" and
[Temperatura skóry] = "obniżona" and

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

[Niedociśnienie] = true and
[Zaburzenia oddawania moczu] = true and
[Oddech] = "szybki i głęboki"
Then [Rozpoznania towarzyszące] = "Wstrząs kardiogenny" @ 95 and
[Rozpoznanie] = "Zawał serca typu NonSTEMI" @ 95

Stwierdzenie PROMPT(zapytanie)

umożliwia ustawianie wartości przesłanek

przez użytkownika za pomocą interfejsu systemu ekspertowego i w bazie wiedzy
występują po regułach. Pierwsza linia stwierdzenia zaczyna się od słowa
PROMPT, po

którym musi wystąpić nazwa atrybutu przesłanki, zapisana w

nawiasach kwadratowych i

typ zapytania(Tab. 9). Fraza CF znajdująca się w tej

samej linii po typie zapytania daje możliwość podawania przez użytkownika
współczynnika pewności. Treść zapytania, zamkniętą w cudzysłowu, deklaruje się
w następnej linii.

Tab. 10

. Typy zapytań e2gRuleEngine

Typ zapytania

Opis

MultChoice

Przyciski radiowe (ang. Radio button)
dla typu tekstowego, możliwe jest tylko
wybór jednej odpowiedzi.

Choice

Rozwijana lista(ang. drop-down list) dla
typu

tekstowego

sadami

analogicznymi do MultChoice

ForcedChoice

MultChoice

bez

opcji

„I

don't

know/would rather not answer".

AllChoice

Umożliwia

zaznaczeniu

kilku

odpowiedzi(ang.

Check

box)

dla

wartości tekstowych.

YesNo

Przyciski

radiowe

wartościami

logicznymi true/false(typ boolean)

Numeric

Pole tekstowe przyjmujące wartości
numeryczne

Następne linie stanowią możliwe odpowiedzi. Dla MultChoice, Choice, AllChoice,
ForcedChoice są wartości zawarte między cudzysłowem. Numeric wymaga, aby w
dwóch osobnych liniach podać wartość minimalną i maksymalną w cudzyslowiu.
Nie należy wpisywać żadnych wartości, jeżeli rodzaj zapytania to YesNo. We
wszystkich typach oprócz Numeric i ForcedChoice istnieje możliwość wyboru
odpowiedzi, która nie ustala wartości warunku(opcja „I don't know/would rather not
answer")

. Jest on traktowany przez moduł wnioskujący jako nieznany. W bazie

wiedzy zapytanie AllChoice wygląda następująco:

PROMPT [Czyn

niki łagodzące ból w klatce] AllChoice CF

"Jakie są czynniki łagodzące ból w klatce?"
"Nitrogliceryna"
"Środki przeciwbólowe"
"Zaprzestanie wysiłku"
"Pozycja siedząca"
"Pozycja siedząca i pochylenie do przodu"
"B

rak czynników"

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

W bazie wiedzy musi wystąpić przynajmniej jedno stwierdzenie deklarujące cel
wnioskowania.

Rozpoczyna się słowem GOAL, po którym następuje para

nawiasów kwadratowych ze znajdującym się między nimi atrybutem konkluzji
jednej z

reguł. Deklaracja celu lub celów wnioskowania w bazie musi wystąpić po

regułach i może być zapisany przed lub po zapytaniach(PROMPT). Poprawnie
zapisanie celu:

GOAL [Rozpoznanie]

Oprócz wyżej wymienionych komponentów w bazie wiedzy można

zadeklarować wartość domyślną dla każdej przesłanki, maksymalną liczbę
odpowiedzi branych pod uwagę przy zapytaniu typu AllChoice i minimalną wartość
współczynnika pewności dla wszystkich rodzajów zapytań, aby odpowiedź mogła
zostać wzięta pod uwagę jako fakt. Zapis wartości domyślnych wygląda
następująco:

DEFAULT

[Wypełnienie tętna] = „W normie”

Maksymalną liczbę odpowiedzi można zadeklarować na dwa sposoby:

MAXVALS [Czynniki łagodzące ból w klatce] 4
MAXVALS [Czynniki łagodzące ból w klatce] = 4

Do ustawienia minimalnego współczynnika pewności(CF) służy zapis:

MINCF X

Gdzie X jest dowolną liczbą z zakresu od 0 do 100. Domyślnie wartość minimalna
CF wynosi 80.

Gdy w regule występują dwie przesłanki, współczynnik pewności

obliczany jest na podstawie iloczynu,

natomiast w przypadku ustalenia wartości

atrybutu z kilku źródeł(zapytanie i kilka zagnieżdżonych reguł) do kalkulacji
używana jest suma probabilistyczna(podrozdział 3.5 „Reprezentacja wiedzy”).

W trakcie sprawdzania poprawności utworzonej bazy wiedzy przydatne jest

używanie modułu wyjaśniającego oraz dodanie parametru o nazwie „DEBUG” z
ustawioną wartością TRUE. Parametr ten tworzy okno służące do odnajdywania i
usuwania usterek.

Za pomocą funkcji Trace is ON/OFF możliwe jest śledzenie

procesu inferencji. Display KB dump

wyświetla aktualny status przesłanek i reguł

w trakcie wnioskowania.

Stan przesłanki składa się z jej nazwy, wartości, typu

zamkniętego w nawiasach okrągłych(S dla typu tekstowego, N dla liczbowego i B
jako wartość logiczna), współczynnika pewności warunku oraz wskaźnik, czy
przesłanka jest prawdziwa bądź nie. Reguły prezentowane są w całości wraz z
dołączonym statusem. Status reguły może być nieznany(U), odpalony(F), gdy
przesłanki reguły okażą się prawdziwe lub fałszywy(X), w przypadku
niemożliwości dowiedzenia prawdziwości reguły. Opcja Analyze KB pozwala
sprawdzić poprawność bazy wiedzy, czy nie wystąpiły w niej błędy
typograficzne(tzw. literówki) i logiczne. Po naciśnięciu tego przycisku widoczne są
dwie sekcje:



ATTRIBUTE USAGE

– wyświetla wszystkie atrybuty w kolejności

alfabetycznej z zaznaczeniem,

które zapytanie lub reguła wyznacza jego

wartość i w jakiej regule dany atrybut został użyty.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011



VALUE USAGE

– pokazuje wartości typu tekstowego, także ułożone w

szeregu alfabetycznym. Po wartości, zamkniętej między cudzysłowami
,znajduje się długość ciągu tekstowego. Widoczne jest także miejsce
występowania danej wartości(przesłanka reguły, konkluzja reguły,
zapytanie) oraz

powiązanym z nią atrybutem.

Rys. 14. Okno odnajdywania i usuwania usterek e2gRuleEngine.

Podstawowym językiem apletu e2gRuleEngine jest język angielski. W sytuacji,

gdy trze

ba zaimplementować system ekspertowy w innym języku, przydatne

okazuje się stwierdzenie TRANSLATE, po którym następuje nazwa atrybutu, jaki
chcemy przetłumaczyć oraz jego wartość zamknięta w cudzysłowie. Do
poprawnego działania programu z bazą wiedzy w innym języku niż angielski
potrzebne jest dopisanie parametru apletu o nazwie KBENCODING. Parametr ten
określa jakiego kodowania tekstu użyto do utworzenia bazy wiedzy i umożliwia jej
poprawne odczytanie modułowi wnioskującemu oraz wyjaśniającemu. Nazwy
at

rybutów

dla

TRANSLATE

znajdują

się

stronie

http://expertise2go.com/e2g3g/e2g3gdoc/e2gref.htm

Wszystkie

możliwe

funkcje

szkieletowego

systemu

ekspertowego

e2gRuleEngine, także te, które nie zostały opisane w pracy znajdują się na stronie
wymienionej na początku bieżącego rozdziału.

Budowa systemu ekspertowego wspomagającego decyzje
medyczne

Konstrukcja systemu ekspertowego zostanie przedstawiona krok po kroku

według etapów opisanych w podrozdziale 3.4 o tytule „Etapy tworzenia systemu
ekspertowego

”. Schemat budowy systemu ekspertowego wspierającego decyzje

medyczne zostanie pokazany na

przykładzie jednej choroby, zawału serca typu

STEMI z towarzyszącym wstrząsem kardiogennym. Choroba ta znajduje się w

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

bazie wiedzy o nazwie kardiolog.kb, a

powyższy schemat posłużył do budowy

wszystkich baz wiedzy znajdujących się w systemie.

Pie

rwszą fazą budowy systemu była identyfikacja problemu. W pierwszym

etapie należy określić cel, zadania systemu ekspertowego oraz potencjalne źródło
wiedzy, które posłuży do budowy bazy wiedzy systemu. W celu identyfikacji
problemu zostanie utworzony raport, który zapoczątkuje proces tworzenia systemu
ekspertowego.

W raporcie znajdują się następujące elementy:



Cel

– zbudować system ekspertowy wspomagający decyzje medyczne

lekarza dyżurującego w szpitalnym oddziale ratunkowy(w skrócie SOR).



Rozwiązanie – w systemie zostaną zaimplementowane cztery bazy wiedzy
odpowiadające wiedzy czterech specjalistów z następujących dziedzin
medycyny:

 Kardiologa

– choroby układu sercowo – naczyniowego.

 Neurolog

– choroby obwodowego i ośrodkowego układu nerwowego.



Chirurgia ogólna – choroby leczone operacyjnie.

 Pulmonologia

– choroby układu oddechowego.

Zadaniem programu b

ędzie odnalezienie rozpoznania głównego choroby i

rozpoznania towarzyszącego chorobie, jeżeli wystąpiło oraz zalecenie
odpowiedniego postępowania na podstawie faktów. W przypadku tego
systemu fakty to objawy jakie zostaną zidentyfikowane w trakcie konsultacji
lekarza SOR z pacjentem

oraz te, które zostały wywnioskowane z reguł

zagnieżdżonych w trakcie inferencji. Dane(fakty) będą wprowadzane na
zasadzie dialogu

systemu z użytkownikiem, którym będzie powyższy

dyżurny medyk. Do budowy systemu zostanie wykorzystany szkieletowy
system ekspertowy e2gRuleEngine.



Wiedza

– z powodu braku ekspertów wiedza musiała zostać uzyskana z

innych źródeł. Źródłem tym była literatura

o tematyce medyczne. Pierwszą

z nich jest książka o tytule „Griffith 5 minut konsultacji klinicznej”[4], która
jest zbiorem chorób, ich objawów i metod leczenia, druga o nazwie
„Medycyna ratunkowa” dokładnie opisuje przypadki chorób możliwych do
wystąpienia u pacjentów zgłaszających się do Szpitalnego Oddziału
Ratunkowego.



Zapotrzebowanie

– nie dotyczy systemu ekspertowego budowanego do

pracy dyplomowej.



Infrastruktura

– system ekspertowy musi być zintegrowany z aplikacją

obsługi przyjęć pacjentów do SOR, która działa w architekturze klient –
serwer z interfejsem użytkownika typu cienki klient. Cienki klient to
komputer bądź terminal komputerowy z zainstalowanym oprogramowaniem
klienckim do obsługi aplikacji znajdującej się na serwerze. W przypadku
aplikacji obsługi przyjęć pacjentów do SOR interfejs użytkownika
uruchamiany jest w oknie przeglądarki internetowej. Jak już zostało
wspomniane, narzędzie e2gRule jest napisane w technologii Java aplet,
która umożliwia uruchomienie tego programu za pomocą przeglądarki
internetowej,

a cały kod źródłowy apletu znajduje się na serwerze.

Narzędzie to doskonale nadaje się do budowy systemu ekspertowego
współdziałającego z aplikacją klient - serwer. Do działania obu programów
jest wymagany serwer i

średniej klasy komputer PC z zainstalowaną

wirtualną maszyną Javy do obsługi apletu. Na serwerze musi być
zainstalowane oprogramow

anie Apache Web do obsługi aplikacji

internetowych z możliwością obsługi skryptowego języka programowania

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

PHP w wersji co najmniej 5.1 i

systemem zarządzania relacyjnymi bazami

danych MySQL 5.1.



Koszty

– narzędzie e2gRuleEngine jest bezpłatne podobnie jak wymienione

we wcześniejszym punkcie oprogramowanie Apache Web, PHP oraz
MySQL, więc implementacja obu programów(systemu ekspertowego i
aplikacji obsługi przyjęć pacjentów do SOR) nie wiąże się kosztami.

Po udanej identyfikacji problemu

następuje faza pozyskiwania wiedzy, która

składa się z dwóch etapów. Pierwszy z nich to nabywanie i dokumentacja wiedzy,
drugi polega na modelowaniu zdobytej wiedzy.

Już wiemy z poprzedniej fazy

budowy systemu ekspertowego, że rozwiązaniem problemu będzie skierowanie
celu w

nioskowania programu na rozpoznanie choroby z jaką trafił pacjent do SOR,

możliwego rozpoznania towarzyszącego chorobie i zalecenia co do postępowania
lekarza

(użytkownika systemu). Do udokumentowania mamy stan chorobowy:

zawał serca typu STEMI z towarzyszącym mu wstrząsem kardiogennym. W
każdej chorobie występuje zbiór charakterystycznych objawów, więc
dokumentację wiedzy rozpoczynamy od ich ustalenia. Dla czytelniejszego zapisu
podzielimy objawy na podmiotowe(subiektywne) i przedmiotowe(obiektywne), w
tra

kcie tworzenia bazy wiedzy podział ten nie będzie brany pod uwagę.

Podmiotowe to te odczuwane przez pacjenta zebrane przez lekarza w czasie
wywiadu(rozmowy z pacjentem), natomiast przedmiotowe

ustalane są w trakcie

badania pacjenta np. kolor skóry, sprawdzenie częstości bicia serca itp. Objawy
podmiotowe zawału serca typu STEMI to:



Ból zlokalizowany w klatce piersiowej zamostkowo, rozlany(trudny do

zlokalizowania).



Ból ma charakter ściskania

ucisku, nagłego bólu, tępego ucisku.



Trwa

dłużej niż 20 minut.



Brak jest czynników nasilających oraz łagodzących ból(np. lek

nitrogliceryna).

Do objawów przedmiotowych zaliczamy:



Podwyższone troponiny(wynik większy niż 0.03 ug/l)



Uniesienia odcinka ST w badaniu EKG w co najmniej dwóch kolejnych

odprowadzeniach. Uniesienie to w oprowadzeniach przedsercowych(V1-
V6)

musi

być

większe

niż

lub

równe

0,1

lub

kończynowych(I,II,III,aVF,aVR,aVL) większe niż 0,2 mV.

W przypadku rozległego zawału serca może towarzyszyć mu wstrząs
kardiogenny, którego objawy przedmiotowe charakteryzują się:



Zaburzeniami świadomości, pacjent jest splątany.



Napięcie tętna jest miękkie.



ypełnienie tętna jest małe lub nitkowate.



Oddech pacjenta

jest szybki i głęboki.



Występują zaburzenia oddawania moczu(anuria lub oliguria).



Z powodu dysfunkcji

obwodowego układu krwionośnego skóra pacjenta jest

zimna.



Niedociśnienie tętnicze.

We wstrząsie kardiogennym nie występują charakterystyczne objawy podmiotowe,
więc nie zostały wzięte pod uwagę w dokumentowaniu wiedzy.

Po udokumentowaniu powyższej wiedzy należy rozbić dany problem(zawał

serca z towarzyszącym mu wstrząsem kardiogennym) na podproblemy i

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

wyodrębnić z nich obiekty, atrybuty i wartości. Po dekompozycji otrzymujemy
następujące podproblemy:



Ból w klatce występujący przy zawale serca.



Uniesienie odcinka ST.



Zaburzenia oddawania moczu.



Niedociśnienie tętnicze

Ból u pacjenta może wystąpić w różnych miejscach, więc dokonujemy rozbicia
podproblemu

bólu w klatce zapisując obiekt o nazwie ból, którego atrybut to:



Lokalizacja bólu, a jej wartości, to miejsca, gdzie pacjent może odczuwać

ból: głowa, żuchwa, szyja, ramiona, klatka piersiowa, nadbrzusze, brzuch,
plecy, lewa kończyna górna, prawa kończyna górna, lewa kończyna dolna,
prawa kończyna dolna lub pacjent może nie zgłaszać dolegliwości
bólowych.

ten sposób uzyskujemy następną trójkę obiekt – atrybut – wartość. Następnie

możemy wrócić do problemu znajdującego się wyżej w hierarchii, jest to ból w
klatce występujący przy zawale serca. Dla klarownego i krótkiego zapisu
nazwiemy ten obiekt Ból zawałowy. Składa się on z następujący atrybutów i
wartości:



Subiektywne odczuwanie

bólu w klatce piersiowej(ból opisywany przez

pacjenta)

z wartościami: ucisk, ściskanie, nagły ból, tępy ucisk.



Charakter bólu w klatce, który przyjmuje następujące wartości: rozlany.



Umiejscowienie bólu w klatce piersiowej: zamostkowo.



Czas trwania bólu w klatce: dłużej niż 20 minut.



Czynniki nasilające ból w klatce piersiowej: nie występują.



Czynniki łagodzące ból w klatce piersiowej: nie występują.

Po określeniu obiektów z danej dziedziny wiedzy(medycyna) można przystąpić do
jawnej reprezentacji wiedzy, czyli jej modelowaniu. W normalnych warunkach etap
ten zostałby przeprowadzony po zdefiniowaniu większości obiektów, aczkolwiek
dla

klarowności zapisu faza ta zostanie przedstawiona po zdefiniowaniu każdego

obiektu dotyczącego zawału oraz wstrząsu kardiogennego. Modelowanie będzie
przyjmować postać tabel decyzyjnych, ponieważ można łatwo sformalizować je w
postaci reguł produkcyjnych, z których będą składały się bazy wiedzy systemu
ekspertowego wspomagającego decyzje medyczne. Tabela decyzyjna 10
przedstawia

zbiór wartości, jakie muszą zostać spełnione, aby konkluzje zostały

uznane za prawdziwe w przypadku bólu w klatce oraz bólu zawałowego.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Tab. 11. Tabela de

cyzyjna bólu w klatce i bólu o charakterze zawałowym.

Warunki

Lokalizacja bólu

Klatka
piersiowa

Ból w klatce
zawałowy

występuje występuje występuje

Subiektywne
odczuwanie

bólu

w klatce
piersiowej

ucisk

ściskanie

nagły ból

tępy ucisk

Charakte

r bólu w

klatce piersiowej

rozlany

Rozlany

Umiejscowienie
bólu w klatce
piersiowej

za
mostkowo

Czas trwania bólu
w klatce

dłużej niż
20 minut

Czynniki
nasilające ból w
klatce piersiowej

nie
występują

Czynniki
łagodzące ból w
klatce piersiowej

nie
występują

Konkluzje
Ból w klatce

ystępuje

(true)

Ból w klatce
zawałowy

ystępuje

(true)

ystępuje

(true)

ystępuje

(true)

ystępuje

(true)

Następnym w kolejności podproblemem było uniesienie odcina ST. Jest to

objaw zawału serca typu STEMI, z tego powodu następny obiekt będzie nosił
nazwę STEMI. Obiekt ten będzie składał się z atrybutów i wartości:



Uniesienia odcinka ST

: występuje(true).



Liczba uniesień ST większa niż dwa kolejne odprowadzenia: prawda(true).



Wysokość uniesienia odprowadzeń kończynowych (I,II,III,aVF,aVR,aVL):

>= 0,1 mV.



Wysokość uniesienia odprowadzeń przedsercowych(V1-V6): > 0,2 mV.

Jawna reprezentacja powyższego obiektu została przedstawiona w tabeli 11(Str.
34).

Zaburzenia oddawania moczu to kolejny obiekt z, którego można wydzielić nowy

podbroblem Stan oddawania moczu z atrybutami: anuria, oliguria i dobowe
oddawnie moczu w normie. Atrybuty te muszą zostać wydzielone ponownie jako
nowe obiekty,

gdyż to czy występują, zależy od ilości oddawanego moczu w ciągu

doby(atrybut obiektu anuria, oliguria, dobowe oddawanie moczu w normie)
przyjmuj

ącej różne wartości dla każdego z tych atrybutów. Model zaburzeń

oddawania moczu ukazuje tabela 12(Str. 34).

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Tab. 12. Tabela decyzyjna obiektu STEMI.

Warunki
Uniesienia odcinka
ST

występuje(true)

iczba uniesień ST

większa niż dwa
kolejne
odprowadzenia

prawda(true)

Wysokość
uniesienia
odprowadzeń
kończynowych
(I,II,III,aVF,aVR,aVL)

>= 0,1 mV

Wysokość
uniesienia
odprowadzeń
przedsercowych(V1-
V6)

> 0,2 mV

Konkluzje
STEMI

występuje(true)

Tab. 13

. Tabela decyzyjna obiektów zaburzenia oddawania moczu, stan

oddawania moczu, anuria, oliguria, dobowe oddawanie moczu w normie.
Warunki
Ilość
oddawanego
moczu w
ciągu doby

< 500 ml
na dobę

< 100
ml na
dobę

500 ml na dobę

Stan
oddawania
moczu

oliguria

Anuria

Konkluzje
Stan
oddawania
moczu

oliguria

anuria dobowe

oddawanie moczu
w normie

Zaburzenia
oddawania
moczu

ystępuje

(true)

ystępuje

(true)

Ostatnim

z wydzielonych podproblemów wstrząsu kardiogennego jest

niedociśnienie tętnicze. Niedociśnienie tętnicze(tabela decyzyjna Str. 35) jest
rozpoznaniem stanu

ciśnienia tętniczego pacjenta składającego się z ciśnienia

skurczowego oraz rozkurczowego,

a ich wartości dla hipotensji(niedociśnienia) są

następujące:



Ciśnienie skurczowe < 90 MmHg(ciśnienie słupa rtęci).



Ciśnienie rozkurczowe < 50 MmHg.

W trakcie przekształcania obiektów na tabele decyzyjne dochodzi do zmiany tróki
obiekt

– atrybut – wartość na parę składającą się z atrybutu i wartości, co ułatwi

późniejszą formalizację wiedzy w postaci reguł.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Tab. 14

. Tabela decyzyjna Niedociśnienia tętniczego

Warunki
Ciśnienie skurczowe

< 90 MmHg

Ciśnienie rozkurczowe

< 50 MmHg

Konkluzje
Niedociśnienie tętnicze

występuje(true)

Po przeanalizowaniu wszystkich podproblemów możemy w końcu wrócić do

problemów głównych, jakimi są zawał serca typu STEMI oraz wstrząsu
karodiogennego.

Po usunięciu nieistotnego podziału na objawy podmiotowe i

przedmiotowe atrybuty i wartości zawału serca typu STEMI prezentują się
następująco:



Ból w klatce zawałowy: występuje(true).



STEMI : występuje(true).



Troponiny: > 0.03 ug/l.

Przesłanki wstrząsu kardiogenngo także uległy zmianie:



Stan świadomości: splątany.



Wypełnienie tętna: małe lub nitkowate.



Napięcie tętna: miękkie.



Charakterystyka oddechu pacjenta

: szybki i głęboki.



Zaburzenia oddawania moczu: występują(true).



Temperatura skóry: obniżona.



Niedociśnienie tętnicze: występuje(true).

Jak zos

tało już wcześniej wspomniane celem wnioskowania systemu

ekspertowego

jest

znalezienie

rozpoznania,

możliwego

rozpoznania

towarzyszącego oraz zalecenia postępowania. Rozpoznanie to nic innego jak
zawał serca typu STEMI, rozpoznaniem towarzyszącym zawałowi serca jest
wstr

ząs kardiogenny. Obie choroby w powyższy sposób zostaną opisane w tabeli

decyzyjnej problemu głównego(tabela numer 14 Str.35) wraz z zaleceniem. Jawna
reprezentacja tych dwóch przypadków kończy przykład ukazania etapu nabywania
wiedzy. Z prz

ykładu wynika, że jest to trudny proces wymagający ciągłej

współpracy z ekspertem bądź przeszukiwania i analizowania innych źródeł. Etap
ten może zostać ułatwiony przez automatyzację pozyskiwania wiedz,
automatyzacja wymaga jednak opracowania specjalistycznego oprogramowania
przez inżyniera wiedzy co nie należy do najłatwiejszych zadań.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Tab. 15. Jawna reprezentacja wiedzy o Zawa

le serca typu STEMI i wstrząsie

kardiogennym.

Warunki
Ból w klatce zawałowy

występuje(true)

stępuje(true)

STEMI

występuje(true)

Troponiny

0.03 ug/l

Stan świadomości

splątany

Wypełnienie tętna

małe

nitkowate

Napięcie tętna

miękkie

Charakterystyka
oddechu pacjenta

szybki i głęboki

Zaburzenia oddawania
moczu

występują(true)

Temperatura skóry

obniżona

Niedociśnienie tętnicze występuje(true)

występuje(true)

Konkluzje
Rozpoznanie

zawał serca typu STEMI

Rozpoznanie
towarzyszące

wstrząs kardiogenny

Zalecenia

Pilna angioplastyka
wieńcowa

Przechodzimy do następnej fazy, którą według schematu etapów tworzenia
systemu ekspertowego(rys. 5. Str. 13) jest reprezentacja wiedzy. Do budowy bazy
wiedzy zostanie użyta technika reguł produkcyjnych z współczynnikiem
pewności(CF) w konkluzji wynoszącym 95%, które zostaną utworzone na
podstawie tabel decyzyjnych z poprzedniego etapu procesu projektowania
systemu ekspertowego. Na podst

awie powyższych tabel decyzyjnych została

stworzona poniższa baza wiedzy:

Jeżeli lokalizacją bólu jest klatka piersiowa to u pacjenta występuje ból w

klatce z 95% pewnością.

Jeżeli u pacjenta występuje ból w klatce piersiowej i subiektywnym

odczuwaniem bólu przez pacjenta jest ucisk lub ściskanie lub nagły ból lub
tępy ucisk i charakter bólu w klatce piersiowej jest rozlany i ból w klatce
piersiowej umiejscowiony jest za mostkowo i czas trwania bólu w klatce
piersiowej jest dłuży niż 20 minut i czynniki łagodzące ból w klatce
piersiowej nie występują i czynniki łagodzące ból w klatce piersiowej nie
występują to ból w klatce piersiowej ma charakter zawałowy 95%
pewnością.

Jeżeli uniesienia odcinka ST występują i liczba uniesień ST większa niż

dwa kolejne odprowadzenia w

ystępuje i wysokość uniesienia odprowadzeń

kończynowych (I,II,III,aVF,aVR,aVL) jest większa lub równa 0,1 mV i
wysokość uniesienia odprowadzeń przedsercowych(V1-V6) jest większa niż
0,2 mV to STEMI występuje z 95% pewnością.

Jeżeli uniesienia odcinka ST występują i liczba uniesień ST większa niż

dwa kolejne odprowadzenia występuje

i wysokość uniesienia odprowadzeń

kończynowych (I,II,III,aVF,aVR,aVL) jest większa lub równa 0,1 mV to
STEMI występuje z 95% pewnością.

Jeżeli uniesienia odcinka ST występują i liczba uniesień ST większa niż

dwa kolejne odprowadzenia występuje i wysokość uniesienia odprowadzeń

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

przedsercowych(V1-

V6) jest większa niż 0,2 mV to STEMI występuje z 95%

pewnością.

Jeżeli ilość oddawanego moczu w ciągu doby jest mniejsza niż 500 ml/dobę

to stanem oddawania moczu jest oliguria

z 95% pewnością.

Jeżeli ilość oddawanego moczu w ciągu doby jest mniejsza niż 100 ml/dobę

to stanem oddawania moczu jest anuria

z 95% pewnością.

Jeżeli ilość oddawanego moczu w ciągu doby jest większa niż lub równa

500

ml/dobę to stanem oddawania moczu jest dobowe oddawanie moczu w

normie

z 95% pewnością.

Jeżeli stanem oddawania moczu jest anuria lub oliguria to zaburzenia

oddawania moczu występują z 95% pewnością.

10.

Jeżeli ciśnienie skurczowe jest mniejsze niż 90 MmHg i ciśnienie

rozkurczowe jest mniejsze niż 50 MmHg to niedociśnienie tętnicze
występuje z 95% pewnością.

11.

Jeżeli ból w klatce zawałowy występuje i STEMI występuje i troponiny są

wyższe niż 0,03 ug/l i stanem świadomości pacjenta jest splątanie i
wypełnienie tętna jest małe lub nitkowate i napięcie tętna jest miękkie i
charakterystyka oddechu pacjenta jest szybka i głęboka i zaburzenia
oddawania moczu występują i temperatura skóry jest obniżona i
niedociśnienie tętnicze występuje to rozpoznaniem jest zawał serca typu
STEMI

z 95% pewnością i rozpoznaniem towarzyszącym jest wstrząs

kardiogenny

z 95% pewnością i zalecane czynności to pilna angioplastyka

wieńcowa.

Niektóre nazwy atrybutów zostały zmienione, aby reguły były bardziej czytelne.
Tak utworzoną bazę wiedzy może w końcu sformalizować według zasad z
rozdziału 4 „Opis narzędzia e2gRuleEngine do budowy systemów ekspertowych”
w etapie implementacji wiedzy

. Baza wiedzy może zostać umieszczona na

serwerze bezpośrednio lub za pośrednictwem edytora administratora aplikacji
obsługi przyjęć pacjentów do szpitalnego oddziału ratunkowego. Reguły w bazie
e2gRuleEnigne ułożone są w innej kolejności, dlatego mają inne numery niż w
etapie reprezentacji wiedzy oraz niektóre z nich musiały zostać podzielone na
kilka reguł(w e2gRuleEnigne mogą być stosowane tylko te same operatory
logiczne).

Powyżej przedstawione reguły w bazie wiedzy kardiolog wyglądają

następująco:

RULE [nr 29]
If [Lokalizacja bólu] : "klatka piersiowa"
Then [Ból w klatce] = true

RULE [nr 31]
If [Ból w klatce] = true and
[Subiektywne odczuwanie bólu w klatce] = "ucisk" and
[Charakter bólu w klatce piersiowej] = "rozlany" and
[Umiejscowienie bólu w klatce piersiowej] = "za mostkowo" and
[Czas trwania bólu w klatce] = "dłużej niż 20 minut" and
[Czynniki nasila

jące ból w klatce piersiowej] : "nie występują" and

[Czynn

iki łagodzące ból w klatce piersiowej] : "nie występują"

Then [Ból w klatce zawałowy] = true

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

RULE [nr 32]
If [Ból w klatce] = true and
[Subiektywne odczuwanie bólu w klatce] = "ściskanie" and
[Cha

rakter bólu w klatce piersiowej] = "rozlany" and

[Umiejscowienie

bólu w klatce piersiowej] = "za mostkowo" and

[Czas trwania bólu w klatce] = "dłużej niż 20 minut" and
[Czynniki nasilające ból w klatce piersiowej] : "nie występują" and
[Czynn

iki łagodzące ból w klatce piersiowej] : "nie występują"

Then [Ból w klatce zawałowy] = true

RULE [nr 33]
If [Ból w klatce] = true and
[Subiektywne odczuwanie bólu w klatce] = "nagły ból" and
[Charakter bólu w klatce piersiowej] = "rozlany" and
[Umiejscowienie b

ólu w klatce piersiowej] = "za mostkowo" and

[Czas trwania bólu w klatce] = "dłużej niż 20 minut" and
[Czynniki nasilające ból w klatce piersiowej] : "nie występują" and
[Czyn

niki łagodzące ból w klatce piersiowej] : "nie występują"

Then [Ból w klatce zawałowy] = true

RULE [nr 34]
If [Ból w klatce] = true and
[Subiektywne odczuwanie bólu w klatce] = "tępy ucisk" and
[Charakter bólu w klatce piersiowej] = "rozlany" and
[Umiejscowienie bólu w klatce piersiowej] = "za mostkowo" and
[Czas trwania bólu w klatce] = "dłużej niż 20 minut" and
[Czynniki nasilające ból w klatce piersiowej] : "nie występują" and
[Czyn

niki łagodzące ból w klatce piersiowej] : "nie występują"

Then [Ból w klatce zawałowy] = true

RULE [nr 35]
If [Uniesienia odcinka ST] = true and
[Liczba unie

sień ST większa niż dwa kolejne odprowadzenia] = true and

[Wysokość uniesienia odprowadzeń kończynowych (I,II,III,aVF,aVR,aVL)] >= 0.1
and
[Wysokość uniesienia odprowadzeń przedsercowych(V1-V6)] > 0.2
Then [STEMI] = true and
[NSTEMI] = false

RULE [nr 36]
If [Uniesienia odcinka ST] = true and
[Liczba uniesień ST większa niż dwa kolejne odprowadzenia] = true and
[Wysokość uniesienia odprowadzeń przedsercowych(V1-V6)] > 0.2
Then [STEMI] = true and
[NSTEMI] = false

RULE [nr 37]
If [Uniesienia odcinka ST] = true and
[Liczba uniesień ST większa niż dwa kolejne odprowadzenia] = true and
[Wysokość uniesienia odprowadzeń kończynowych (I,II,III,aVF,aVR,aVL)] >= 0.1

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Then [STEMI] = true and
[NSTEMI] = false

RULE [nr 69]
If [Ilość oddawanego moczu w ciągu doby] < 500
Then [Stan oddawania moczu] = "oliguria"

RULE [nr 70]
If [Ilość oddawanego moczu w ciągu doby] < 100
Then [Stan oddawania moczu] = "anuria"

RULE [nr 71]
If [Ilość oddawanego moczu w ciągu doby] >= 500
Then [Stan oddawania moczu] = "dobowe oddawanie moczu w normie"

RULE [nr 72]
If [Stan oddawania moczu] = "oliguria" or
[Stan oddawania moczu] = "anuria"
Then [Zaburzenia oddawania moczu] = true

RULE [nr 73]
If [Stan oddawania moczu] = "oddawanie moczu w normie"
Then [Zaburzenia oddawania moczu] = false

RULE [nr 74]
If [Ciśnienie skurczowe] < 90 and
[Ciśnienie rozkurczowe] < 50
Then [Niedociśnienie] = true

RULE [nr 1]
If [Ból w klatce zawałowy] = true and
[NSTEMI] = true and
[Troponiny] > 0.03 and
[Stan świadomości] = "splątany" and
[Wypełnienie tętna] = "małe" and
[Napięcie tętna] = "miękkie" and
[Temperatura skóry] = "obniżona" and
[Niedociśnienie] = true and
[Zaburzenia oddawania moczu] = true and
[Chrakterstyka oddechu pacjenta] = "szybki i głęboki"
Then [Rozpoznanie] = "Zawał serca typu NonSTEMI" @ 95 and
[Rozpoznania towarzyszące] = "Wstrząs kardiogenny" @ 95 and
[Zalecenia] = "Pilna angioplastyka wieńcowa"

Aby fakty,

które nie są konkluzjami innych reguł, mogły przyjąć określone wartości

w bazie wiedzy,

muszą wystąpić zapytania z ustawioną maksymalną liczbą

odpowiedzi dla typu AllChoice. Zapytania

prezentują się następująco:

PROMPT [Stan świadomości] MultChoice CF
"Jaki jest stan świadomości pacjenta?"

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

"splątany"
"senny"
"w normie"
"pobudzony"
"agresywny"

PROMPT [Lokalizacja bólu] AllChoice CF
"Gdzie pacjent lokalizuje ból?"
"głowa"
"żuchwa"
"szyja"
"ramiona"
"klatka piersiowa"
"nadbrzusze"
"brzuch"
"plecy"
"lewa kończyna górna"
"prawa kończyna górna"
"prawa kończyna dolna"
"lewa kończyna dolna"
"Pacjent nie zgłasza dolegliwość bólowych"

PR

OMPT [Subiektywne odczuwanie bólu w klatce] MultChoice CF

"Jaki jest charakter bólu w klatce?"
"ucisk"
"ciężkość"
"pieczenie"
"ściskanie"
"rozdzieranie"
"

kłucie"

"nagły ból"
"tępy ucisk"
"przeszywający"

PROMPT [Charakter bólu w klatce piersiowej] MultChoice CF
"Jaki jest chara

kter bólu?"

"miejscowy"
"rozlany"

PROMPT [Umiejscowienie bólu w klatce piersiowej] MultChoice CF
"Jakie jest umiejscowienie bólu w klatce piersiowej"
"lewa strona klatki piersiowej"
"prawa strona klatki piersiowej"
"za mostkowo"
"prz

ednia ściana klatki"

PROMPT [Czas trwania bólu w klatce] MultChoice CF
"Jaki jest czas trwania bólu?"
"krócej niż 3 minuty"
"od 3 do 15 minut"

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

"dłużej niż 20 minut"
"wiele godzin"
"dłużej niż kilka dni"

PROMPT [Uniesienia odcinka ST] YesNo CF
"Czy występuje uniesienie odcinka ST w wyniku badania EKG?"

PROMPT [Liczba uniesień ST większa niż dwa kolejne odprowadzenia] YesNo CF
"Czy uniesienia ST znajdują się w co najmniej dwóch odprowadzeniach?"

PROMPT

[Wysokość

uniesienia

odprowadzeń

kończynowych

(I,II,III,aVF,aVR,aVL)] Numeric CF
"O ile mV

uniesione są odprowadzenia kończynowe (I,II,III,aVF,aVR,aVL. Zakres

0.0-3.0 mV)?"
"0.0"
"3.0"

PROMPT [Wysokość uniesienia odprowadzeń przedsercowych(V1-V6)] Numeric
CF
"O ile mV uniesione są odprowadzenia przedsercowe(V1-V6)?"
"0.0"
"3.0"

PROMPT [Troponiny] Numeric CF
"Jaki jest wynik badania troponiny cTN(0.00 - 30.00 ug/l)?"
"0.0"
"20.0"

PROMPT [Czynniki nasilające ból w klatce piersiowej] AllChoice CF
"Jakie czynniki wpływają na nasilenie bólu w klatce?"
"wysiłek fizyczny"
"zimno"
"zmęczenie poposiłkowe"
"stres"
"połykanie"
"intensywne wymioty"
"skręcenie tułowia"
"głęboki wdech"
"kaszel"
"pozycja leżąca"
"nadciśnienie tętnicze"
"nie występują"

PROMPT [Czynn

iki łagodzące ból w klatce piersiowej] AllChoice CF

"Jak

ie są czynniki łagodzące ból w klatce?"

"nitrogliceryna"
"środki przeciwbólowe"
"zaprzestanie wysiłku"
"pozycja siedząca"
"pozycja siedząca i pochylenie do przodu"

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

"nie występują"

PROMPT [Wypełnienie tętna] MultChoice CF
"Jakie jest wypełnienie tętnicy promieniowej w trakcie badania tętna?"
"duże"
"małe"
"nitkowate"

PROMPT [Napięcie tętna] MultChoice CF
"Jakie jest napięcie tętna?"
"twarde"
"miękkie"

PROMPT [Temperatura skóry] MultChoice CF
"Jaka jest temperatura skóry?"
"w normie"
"obniżona"
"podwyższona"

PROMPT [Ilość oddawanego moczu w ciągu doby] Numeric CF
"Ile moczu oddaje pacjent w ciągu doby"
"0.0"
"1000.0"

PROMPT [Charakterystyka oddechu pacjenta] MultChoice CF
"Jak opiszesz oddech pacjenta?"
"szybki i głęboki"
"szybki i płytki"
"wolny i głęboki"
"wolny i płytki"

PROMPT [Ciśnienie skurczowe] Numeric CF
"Jakie jest ciśnienie skurczowe(0-270 MmHg)?"
"0.0"
"270.0"

PROMPT [Ciśnienie rozkurczowe] Numeric CF
"Jakie jest ciśnienie rozkurczowe(0-170 MmHg)?"
"0.0"
"160.0"

MAXVALS [Lokalizacja bólu] 11
MAXVALS [Czynniki nasilające ból w klatce piersiowej] 4
MAXVALS [Czyn

niki łagodzące ból w klatce piersiowej] 5

W bazie musi również wystąpić deklaracja celu lub celów

GOAL [Rozpoznanie]
GOAL [Rozpoznania towarzyszące]
GOAL [Zalecenia]

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Przydatne okazuj

e się także ustawienie minimalnego współczynnika pewności dla

odpowiedzi użytkownika. Jeżeli użytkownik ustawi współczynnik poniżej tego
minimum odpowiedź nie będzie traktowana jako fakt i nie zostanie dołączona do
pamięci podręcznej. System ekspertowy wspomagający decyzje medyczne będzie
akceptował odpowiedzi jako fakty przy minimalnym CF wynoszącym 80%:

MINCF 80

Do uruchomienia systemu ekspertowego w aplikacji obsługi przyjęć posłuży
poniższy kod będący funkcją PHP:

function showApplet($param){
echo'
<div class="applet" id="applet">
<applet

code="e2gRuleEngine"

archive="e2gRuleEngine.jar"

width="700"

height="420">
<param name="KBURL" value="'.$param.'.kb">
<param name="APPTITLE" value="Specjalistyczna konsultacja"/>
<param name="APPSUBTITLE" value="Wybrany specjalista: '.$param.'."/>
<param name="STARTBUTTON" value="Rozpocznij konsultację"/>
<param name="TITLCOLOR" value="#0000FF"/>
<param name="BGCOLOR" value="#FFFFFF"/>
<param name="KBENCODING" value="UTF-8"/>
<param name="NOLOGO" = value="true"/>
<param name="DEBUG" value="true"/>
</applet>
</div>
';
}

Parametr $param służy do wczytania wybranej bazy wiedzy. Po
zaimplementowaniu wiedzy do naszego systemu ekspertowego możemy
przystąpić do następnego etapu, którym jest testowanie systemu. Czynność ta
z

ostanie opisana w następnym rozdziale.

6 Testowanie systemu

Testowanie aplikacji, podobnie jak budowa systemu ekspertowego, jest

czynnością wymagającą czasu oraz dużej ilości dokumentacji, dlatego w bieżącym
rozdziale zostanie opisany jeden z przeprowadzonyc

h testów współdziałania i

poprawności działania obu aplikacji, programu do obsługi przyjęć pacjentów do
od

działu SOR i systemu ekspertowego wspomagającego decyzje medyczne.

Środowiskiem testowym dla interfejsu użytkownika po stronie klienta będzie laptop
o parametrach

znajdujących się w tabeli 15.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Tab. 16

. Parametry laptopa użytego do testów systemu.

Podzespoły

Parametry

Processor

Intel® Core™ 2 Duo T7500

Taktowanie rdzenia procesora

2.2 GHz

Ilość pamięci RAM

2 gb

Typ pamięci RAM

So-dimm ddr2 (667 MHz)

Pojemność dysku twardego

250 GB

Obrót napędu

5,400 Obr./min

Karta graficzna

ATI Mobility™ Radeon® HD2600

Ekran LCD

15,4’’

System operacyjny

MS Windows 7 Professional

Przeglądarka internetowa

Opera 11.01

Kody źródłowe obu aplikacji zostaną umieszczone na serwerze udostępnionym
przez firmę hostingowi 1&1 Internet Sp. z o.o.

Aby uruchomić interfejs aplikacji wpisujemy w oknie przeglądarki adres URL i

wchodzimy w moduł dla pielęgniarki. Przyjmujemy nowego pacjenta.

Rys. 15

. Przyjęcie pacjenta.

Następnie loguje się lekarz i używamy przycisku Konsultacje, aby wyświetlić

tabelę z pacjentami, których historia wymaga uzupełnienia lub trzeba skorzystać z
systemu ekspertowego wspomagającego decyzje medyczne, ponieważ żaden
specjalista z innych oddziałów nie jest dostępny. Pacjent trafił na oddział z
następującymi objawami:



Objawy podmiotowe:



Ból zlokalizowany w klatce piersiowej za mostkowo.



Ból jest rozlany, a pacjent odczuwa ucisk w klatce piersiowej.

 Z

wywiadu wynika, że ból trwa dłużej niż 20 minut i żadne czynniki

go nie łagodzą, ani nie nasilają.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011



Objawy przedmiotowe:



W EKG występuje uniesienie odcinka ST w dwóch kolejnych

odprowadzeniach kończynowych, wynosi 0,4 mV.

 Badanie

krwi wykazało podwyższone troponiny(0.7 ug/l).



Tętno pacjenta jest miękkie i nitkowate, jego oddech szybki i głęboki,

skóra wilgotna.



Ciśnienie skurczowe wynosi 80 MmHg a rozkurczowe 45 MmHg.



Pacjent jest splątany z trudem odpowiada na zadawane pytania.



Temperatura skóry jest obniżona.



Pacjent oddał mocz w ciągu doby o objętości przybliżonej półtora

szklanki

wody(około 300 ml).

O w

ynikach badań krwi lekarz został poinformowany telefonicznie, gdyż moduł

laboratoryjny pozwalający wprowadzać wyniki pacjenta nie został jeszcze
zaimplementowany.

Rys. 16. Panel konsultacyjny.

Lekarz uruchamia system ekspertowy przyciskiem Konsultacja i inicjuje

działanie systemu ekspertowego. Wybiera odpowiednią bazę wiedzy(kardiolog) i
rozpoczyna konsultację z systemem.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Rys. 17

. Interfejs systemu ekspertowego z rozpoczętą konsultacją.

Po zakończeniu „dialogu” lekarza z systemem ekspertowym i podaniu przez

niego wszystkich objawów pacjenta wyświetla się wynik konsultacji.

Rys. 18. Wniosek systemu ekspertowego.

System r

ozpoznał chorobę pacjenta, którą jest zawał serca typu STEMI z

towarzyszącym mu wstrząsem kardiogennym i zalecił odpowiednie postępowanie.
Po naciśnięciu przycisku wytłumacz wyświetla się cały proces, w jaki sposób
sy

stem doszedł do rozwiązania(na podstawie jakich faktów i reguł został

osiągnięty cel wnioskowania). Test został zakończony powodzeniem.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

Rys. 19

. Moduł wyjaśniający systemu ekspertowego.

Aplikacja obsługi przyjęć pacjentów do SOR została wyposażona w prosty edytor
bazy wiedzy. Po zalogowaniu się do modułu administratora uzyskujemy możliwość
edycji baz wiedzy zapisanych na serwerze.

Rys. 20. Edytor bazy wiedzy.

Budowa systemu ekspertowego wspomagającego decyzje medyczne

Konrad Strzelec – Inżynierska praca dyplomowa – WSTT w Świdnicy 2011

7 Podsumowanie

Systemy ekspertowe

stanowią ciągle rozwijającą się dziedzinę sztucznej

inteligencji.

Niestety te związane z medycyną, z bazą wiedzy rozwijaną przez kilka

lat,

nie osiągnęły 100% sprawności doświadczonego eksperta. Powyżej

zaprojektowany i zaimplementowany system ekspertowym jest tylko przy

kładem w

jaki sposób systemy te mogą zostać wykorzystane w medycynie i jak za pomocą
darmowych narzędzi można stworzyć programy, które w przyszłości mogą okazać
się użyteczne i dochodowe.

Cel pracy został osiągnięty. System ekspertowy wspomagający decyzje

medyczne został zbudowany i zintegrowany z aplikacją obsługującą przyjęcia
pacjentów do szpitalnego oddziału ratunkowego. Wykorzystanie narzędzia
e2gRuleEngine pozwoliło na łatwe zbudowanie systemu ekspertowego bez
ponoszenia kosztów. Aplet e2gRuleEngine jest ciągle rozwijany, połączenie tego
apletu z aplikacją zbudowaną w oparciu architekturę klient – serwer ułatwia
wymianę jego starszej wersji na nowszą z poprawionymi błędami i dodatkowymi
funkcjami bez naruszenia reszty systemu.

Dodatkowo aplikacja obsługi przyjęć

pacjentów została wyposażona w edytor baz wiedzy, którego nie posiada
e2gRuleEngine.

Jednakże medyczne systemy ekspertowe powinny być raczej wykorzystywane

do diagnozowania, niegroźnych powszechnie występujących schorzeń, które
można wyleczyć w domu bez wizyty u lekarza. Pozwoli to zaoszczędzić, czas,
pieniądze. Tam, gdzie liczy się czas, gdzie trzeba szybko i skutecznie udzielić
pomocy w stanie zagrożenia życia i zdrowia, systemy ekspertowe wspomagające
decyzje medyczne nie sprawdzi się z powodu ograniczeń, jakie narzuca interfejs
użytkownika systemu. Do szybkiej i wygodnej komunikacji w powyższym
przypadku wymagana byłaby komunikacja werbalna systemu z człowiekiem.
Właśnie w tym kierunku powinien podążać rozwój systemów ekspertowych po to,
by z

atrzeć różnicę między ekspertem-człowiekiem a ekspertem – programem.

Bibliografia

[1]

Red. Sobol E.: Nowy słownik języka polskiego. Wydawnictwo Naukowe PWN.

Warszawa 2002

[2] Red. Owoc. L

: Elementy systemów ekspertowych cz I. Wydawnictwo Akademii

ekonomi

cznej im. Oskara Langego we Wrocławiu. Wrocław 2006

[3]

Korbicz J., Kościelny J., Kowalczuk Z., Cholewa W.: Diagnostyka procesów.
Modele. Metody sztucznej inteligencji. Zastosowania., Wydawnictwo Naukowo-
techniczne, Warszawa 2007

[4] Dambro M. R.: Griffith 5 minut konsultacji klinicznej, Wydawnictwo Medyczne

Urban & Partner, Wrocław 2006

[5] Pousada L., Osborn H.H., Levy D.B.:Medycyna ratunkowa, Wydawnictwo

Medyczne Urban & Partner, Wrocław 1999

Źródła internetowe

[6] www.fizyka.umk.pl/~duch/cog-book/AI/AI7a.pdf
[7] http://pl.wikipedia.org/wiki/Dendral
[8] http://en.wikipedia.org/wiki/Macsyma
[9] http://pl.wikipedia.org/wiki/Mycin
[10] http://pl.wikipedia.org/wiki/Prospector