plik

Budowa systemu ekspertowego wspomagającego decyzje medyczne

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

Wstęp

Sztuczna inteligencja (ang. Artificial intelligence, w

skrócie A.I) jest dziedziną

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



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

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