ANLAMSAL WEB ve ETMEN TEKNOLOJ LER KULLANARAK SA LIK B LG S STEM GEL T RME

Transkript

1 EGE ÜN VERS TES FEN B L MLER ENST TÜSÜ (YÜKSEK L SANS TEZ ) ANLAMSAL WEB ve ETMEN TEKNOLOJ LER KULLANARAK SA LIK B LG S STEM GEL T RME Kibariye GÜNEY Tez Danı manı: Yrd.Doç.Dr. Rıza Cenk ERDUR Bilgisayar Mühendisli i Anabilim Dalı Bilim Dalı Kodu : Sunu Tarihi : 10/09/2009 Bornova- ZM R 2009

2 ii

3 iii Kibariye GÜNEY tarafından yüksek lisans tezi olarak sunulan Anlamsal Web ve Etmen Teknolojileri Kullanılarak Sa lık Bilgi Sistemi Geli tirme ba lıklı bu çalı ma E.Ü. Lisansüstü E itim ve Ö retim Yönetmeli i ile E.Ü. Fen Bilimleri Enstitüsü E itim ve Ö retim Yönergesi nin ilgili hükümleri uyarınca tarafımızdan de erlendirilerek savunmaya de er bulunmu ve 10 Eylül 2009 tarihinde yapılan tez savunma sınavında aday oybirli i/oyçoklu u ile ba arılı bulunmu tur. Jüri Üyeleri: mza Jüri Ba kanı :Yrd.Doç.Dr Rıza Cenk ERDUR... Raportör Üye :Yrd.Doç.Dr Murat Osman ÜNALIR... Üye :Yrd.Doç.Dr Geylani KARDA...

4 iv

5 v ÖZET ANLAMSAL WEB ve ETMEN TEKNOLOJ LER KULLANARAK SA LIK B LG S STEM GEL T RME GÜNEY, Kibariye Yüksek Lisans Tezi, Bilgisayar Mühendisli i Bölümü Tez Yöneticisi: Yrd. Doç. Dr. Rıza Cenk Erdur Eylül 2009, 145 sayfa Yazılım etmenleri günümüzde bilgi teknolojileri alanının en önemli ve en hızlı geli im gösteren ara tırma alanlarından birisidir. Bir yazılım etmeni, kullanıcısı adına belirli amaçları yerine getirmek üzere davranma yetene i olan, özerk (otonom) ve amaç yönelimli bir yapıya sahip yazılım bile enidir. Çoketmenli sistem ise, tek bir etmenin kendi ba ına çözemedi i veya etkin bir biçimde çözemeyece ini dü ündü ü problemleri birbiriyle i birli i yaparak e güdümlü bir biçimde çözmek için bir araya gelen etmen toplulu udur. Bu çalı mada, anlamsal web ve çoklu etmen teknolojileri kullanılarak, HL7 uyumlu tıbbi veri ileti imi ve akıllı randevu alma süreçlerini yerine getiren çoketmenli bir sa lık bilgi sistemi tasarlanmı ve gerçekle tirilmi tir. Sistem gerçekle tirilirken FIPA (Foundation For Intelligent Physical Agents) standartlarına uyumlu JADE (Java Agent Development Environment) etmen geli tirme çerçevesi kullanılmı tır. Geli tirilen çok-etmenli sistemde; Merkezi Randevu Sistemini, MedicalNet Sistemini, tıbbi merkezleri, tıbbi merkez içerisinde bulunan departmanları, departman içerisinde çalı an doktorları ve kullanıcıları (hastaları) temsil eden etmenler altı ayrı etmen sınıfından türetilmektedir. Bu etmenlerin her birinin kendilerine özgü davranı ları vardır ve bu davranı larını kullanıcılara ve doktorlara servis sa lamak için yönetmektedirler. Sistemde özerk çalı an etmenlerle, doktorlar tarafından HL7 uyumlu hasta verisine eri ilebilmekte ve hasta adına akıllı randevu alma i lemleri gerçekle tirilebilmektedir. Ayrıca, Anlamsal Web teknolojilerinin sundu u olanaklardan faydalanmak amacıyla, JADE uygulama tanımlı ontoloji ve içerik

6 vi dili modeli kullanılarak Sa lık Ontolojisi adında basit bir ontoloji geli tirilmi tir. Geli tirilen çok-etmenli sistemde yer alan etmenlerin, birbirlerine kayıtlanma ve akıllı randevu alma a amasında, bu anlamsal bilgi üzerinde i lem yapması ve birbirleriyle ileti imlerinde bu ontolojiyi kullanmaları sa lanmı tır. Anahtar sözcükler: Yazılım etmenleri, çok-etmenli sistemler, HL7 uyumlu veri aktarımı, akıllı randevu alma i lemleri, ontoloji

7 vii ABSTRACT DEVELOPING A HEALTHCARE INFORMATION SYSTEM USING SEMANTIC WEB and AGENT TECHNOLOGIES GÜNEY, Kibariye MSc Thesis, Department of Computer Engineering Supervisor: Asst. Prof. Dr. Rıza Cenk Erdur September 2009, 145 pages Nowadays, software agent technology is one of the most important and rapidly developing research areas of the information technologies domain. A software agent is an autonomous and a goal-oriented software entity that has the ability of acting in order to achieve particular objectives on behalf of its owner. A Multi-agent System is a group of collaborative agents, in which complex problems those cannot be handled by a single agent are solved. In this study, a health information system which can transfer the HL7 compliant medical data and execute the intelligent appointment processes has been designed and implemented using semantic web and multi agent technologies. FIPA (Foundation For Intelligent Physical Agents) compliant JADE (Java Agent Development Environment) agent development framework has been used to implement the system. The agents in the developed multi-agent system have been derived from six different classes representing Central Appointment System, MedicalNet System, medical centres, departments in the medical centre, doctors working in the department, and users (patients). Each of these agents has specific behaviours and these behaviours provide services to users and doctors. Autonomous agents working in the system allow doctors to access the HL7 compliant patient data and they can execute intelligent appointment processes on behalf of patients. In addition, to make use of the advantages provided by the Semantic Web technologies, a simple ontology named Health Ontology has been developed using the JADE application-defined ontology and content language model. The agents process this semantic knowledge and communicate with each

8 viii other using this ontology while registering themselves and organizing intelligent appointments. Keywords: Software agents, multi-agent systems, HL7 compliant data transfering, intelligent make appointment processes

9 ix TE EKKÜR Bu tez çalı masının ba ından sonuna kadar bana her türlü deste i sa layan danı manım sayın Yrd.Doç.Dr. Rıza Cenk ERDUR a, tez savunma jürime katılımları ve de erli yorumlarından dolayı sayın Yrd.Doç.Dr. Murat Osman ÜNALIR (Ege Üniversitesi) ve sayın Yrd.Doç.Dr. Geylani KARDA a (Uluslararası Bilgisayar Enstitüsü), yüksek lisans e itimim süresince verdi i destekten ötürü EMOT ve ATAKALP Hastaneleri Yönetimine ve tüm çalı ma arkada larıma te ekkür ederim. Yüksek lisans e itimimi tamamlamada bana maddi destek sa layan TÜB TAK B L M NSANI DESTEKLEME DA RE BA KANLI I na te ekkürlerimi sunmayı bir borç bilirim. Bugünlere ula mamda en büyük katkı sahibi olan aileme ve yakın arkada larıma ve özellikle bu çalı mamda yardımlarını esirgemeyen Tolga Utku ONBAY a en derin te ekkürlerimi sunarım.

10 x

11 xi Ç NDEK LER Sayfa ÖZET... v ABSTRACT... vii TE EKKÜR... ix Ç NDEK LER... xi EK LLER D Z N... xv KISALTMALAR D Z N... xxi 1. G R ALT YAPI Yazılım Etmenleri ve Çok-Etmenli Sistemler Yazılım etmenleri Çok-etmenli sistemler FIPA çoklu-etmen mimarisi JADE (Java Agent Development Framework-JADE) çoklu-etmen platformu Anlamsal Web Anlamsal web Anlamsal web in geli imi Ontoloji TÜRK YE'DE E-SA LIK... 25

12 xii Ç NDEK LER (devam) Sayfa 3.1. E-Sa lık nedir? Türkiye'de E-Devlet Dokümanlarının Birlikte lerli ini Sa lamak Ulusal Sa lık Bilgi Sistemi: Sa lık-net Sa lık-net in ortaya çıkı ı Sa lık-net nedir? Sa lık-net in yapısı Sa lık-net için gerekli standartlar Sa lık-net e yardımcı uygulamalar Di er E-Sa lık Projeleri Tele-Tıp Merkezi Hastane Randevu Sistemi (MHRS) Elektronik Sevk Sistemi E-Reçete Elektronik Kimlik Kartı SOYUT S STEM M MAR S Önerilen Çok-Etmenli Sistem Mimarisi Sa lık Ontolojisi JADE Etmenlerinin ç Detayları Sistemin kullanıcı giri i için hazır hale getirilmesi...65

13 xiii Ç NDEK LER (devam) Sayfa Kullanıcının sisteme dahil olması Doktor tarafında bir senaryo Sistemin Sa ladı ı Güvenlik Kısıtları BENZER ÇALI MALAR HeCaSe: Ki iselle tirilmi Sa lık Servisleri Sa layan Etmen Tabanlı Bir Sistem Sa lık Alanında Etmen Teknolojilerinin kullanılması: GruSMA çalı ması (HeCaSe2) Organ Nakil lemlerini Yönetmeye Yardımcı Bir Çok-Etmenli Sistem PalliaSys: Özürlü Hasta Ünitesindeki Bilginin Yönetimi çin Çok-Etmenli Bir Sistem E-Tıp Sistemi Tasarlamak çin Bir Çok-Etmenli Yakla ım Hintli Kırsal Bebek ve Çocuk Bakımı çin Çok-Etmenli Tıbbi Sistem SAPHIRE: Anlamsal Birlikte Çalı abilirlik Tabanlı Akıllı Sa lık Takibi De erlendirme SONUÇ ÖNER LER KAYNAKLAR D Z N EKLER Ek 1 Sa lık Ontolojisinin Mimarideki Etmenler Üzerindeki Yeri

14 xiv Ç NDEK LER (devam) Sayfa Ek 1.1 Randevu Merkezi Etmeni Ek 1.2 MedicalNet Etmeni Ek 1.3 Tıbbi Merkez Etmeni Ek 1.4 Departman Etmeni Ek 1.5 Doktor Etmeni Ek 1.6 Kullanıcı Etmeni Ek 2 Tıbbi Merkez Etmeni çerisindeki MedicalCentreOfferRequestsServer Görev çeri i Ek 3 HL7 Formatındaki Verileri Ayrı tıran, Kolay Anla ılabilir Bir Yapı Ek 3.1 Hasta Kabul Veriseti Ek 3.2 Hasta Çıkı Veriseti Ek 3.3 Tetkik Sonucu Veriseti Ek 3.4 Reçete Veriseti Ek 3.5 Muayene Veriseti Ek 3.6 Yatan Hasta Veriseti ÖZGEÇM...145

15 xv EK LLER D Z N ekil Sayfa ekil 2.1 Etmen-Çevre Etkile imi (Vidal et al., 2001)... 4 ekil 2.2 Bir Etmenin Girdilerine li kin Örnekler (Vidal et al., 2001)... 5 ekil 2.3 FIPA Etmen Yönetimi Referans Modeli (FIPA, 2002) ekil 2.4 FIPA leti Yapısı (FIPA, 2000) ekil 2.5 Ta ıma letisinin Olu turulması (FIPA, 2000) ekil 2.6 Behaviour Sınıfının UML Sınıf Diyagramı (Bellifemine et al., 2005).. 16 ekil 2.7 Bir JADE Da ıtık Etmen Platformu Örne i (Bellifemine et al., 2005). 17 ekil 2.8 Etmen Parçacı ının Çalı ma Yöntemi (Caire, 2003) ekil 2.9 Anlamsal Web Katmanları (Berners Lee, 1999) ekil 3.1 Sa lık Bakanlı ı E-Sa lık Projeleri ekil 3.2 Sa lık-net in Yapısı ekil 3.3 Karar Destek Sistemi (Do aç, 2008) ekil 3.4 Ulusal Sa lık Veri Sözlü ü Veri Elemanları ekil 3.5 Hasta Kabul Veri Seti ekil 3.6 Sa lık-net i Kullanan Kurumlar (Do aç, 2008) ekil 3.7 Sa lık-net le leti im (Do aç, 2008) ekil.3.8 Test Bed Uygulaması Arayüzü ekil 3.9 TestBATN Arayüzü ekil 3.10 TestBATN Mimarisinin Basit Gösterimi

16 xvi EK LLER D Z N (devam) ekil Sayfa ekil 3.11 MHRS in Yapısı (Arslan, 2008)...45 ekil 3.12 MHRS çin Ayrılan 4 Bölge ekil 4.1 Çok-Etmenli Sistem Mimarisi...53 ekil 4.2 çerik Referans Modeli (JADE Tutorial, 2008)...56 ekil 4.3 Sa lık Ontolojisinin Olu turulması...58 ekil 4.4 OntologyBeanGenerator Arayüzü...59 ekil 4.5 Sa lık Ontolojisi çerisindeki Etmen Aksiyonları,Yüklemler ve Kavramlar...60 ekil 4.6 Sa lık Ontolojisi UML Sınıf Diyagramı...61 ekil 4.7 MedicalNet Etmeni Setup Metodu Ardıl Etkile im Diyagramı...65 ekil 4.8 RegisterToMedicalNetAgent Görevi Ardıl Etkile im Diyagramı...67 ekil 4.9 Doktor Giri Ekranı...68 ekil 4.10 Kullanıcı Giri Ekranı...69 ekil den 6 ya Kadar Uygulanan Adımlar çin Akı Diyagramı...70 ekil 4.12 SearchRegisteredAppointmentBehaviour Görevi Ardıl Etkile im Diyagramı...71 ekil 4.13 MedicalNet Etmenlerinin Eri im Bilgilerini Dizin Kolayla tırıcıdan Ö renen lemin Ardıl Etkile im Diyagramı...72 ekil 4.14 SearchMedicalNetForMedicalCentresAIDBehaviour Görevi Ardıl Etkile im Diyagramı...73 ekil 4.15 SearchPatientCases letisi çin SearchMedicalNetForMedicalCentresBehaviour Görevi Ardıl Etkile im Diyagramı...74

17 xvii EK LLER D Z N (devam) ekil Sayfa ekil 4.16 SearchAllMedicalCentres letisi çin SearchMedicalNetForMedicalCentresBehaviour Görevi Ardıl Etkile im Diyagramı ekil 4.17 RequestForContractBehaviour Görevi Ardıl Etkile im Diyagramı ekil 4.18 Tıbbi Merkezler Listesi Arayüzü ekil den 12 e Kadar Uygulanan Adımlar çin Akı Diyagramı ekil 4.20 SearchSelectedMedicalCentreForDoctorsAppointmentsBehaviour Görevi Ardıl Etkile im Diyagramı ekil 4.21 Tıbbi Merkez Etmenine Gelen SearchDoctorsAppointments ste i çin Ardıl Etkile im Diyagramı ekil 4.22 Departman Etmenine Gelen SearchsDoctorsAppointments ste i çin Ardıl Etkile im Diyagramı ekil 4.23 Kullanıcı Tarafı Doktor Zaman Çizelgesi Arayüzü ekil den 15 e Kadar Uygulanan Adımlar çin Akı Diyagramı ekil 4.25 MakeAppointmentOperationBehaviour Görevi Ardıl Etkile im Diyagramı ekil 4.26 Doktorun Uyguladı ı lemler çin Akı Diyagramı ekil 4.27 Doktor Tarafı Doktor Zaman Çizelgesi ekil 4.28 GetPatientInformationBehaviour Görevi Ardıl Etkile im Diyagramı. 84 ekil 4.29 Hasta Bilgileri çin Bir Arayüz ekil 4.30 Muayene lemi çin Bir Arayüz ekil 4.31 Yatan Hasta lemi çin Bir Arayüz ekil 5.1 HeCaSe Mimarisi (Isern et al., 2003)... 90

18 xviii EK LLER D Z N (devam) ekil Sayfa ekil 5.2 Zaman Çizelgesi Plug-in Arayüzü (Isern et al., 2003)...92 ekil 5.3 Bir Doktordan Randevu Almayı Sa layan Arayüz (Isern et al., 2003)..93 ekil 5.4 Tercih Plug-in i Arayüzü (Isern et al., 2003)...94 ekil 5.5 Randevu Almak çin Uygulanan 4 Katmanlı CFP Protokolü (Isern et al., 2003)...94 ekil 5.6 HeCaSe2 Etmen Tabanlı Sistem Mimarisi (Moreno et al., 2006)...95 ekil 5.7 Çok-Etmenli Sistemin Mimarisi (Moreno, 2003)...97 ekil 5.9 PalliaSys Sisteminin Mimarisi (Moreno, 2003)...98 ekil 5.10 E-Tıp Sistemin Çok-Etmenli Toplumu (Tian and Tianfield, 2003) ekil 5.11 Çok-Etmenli Sistem Mimarisi (Tian and Tianfield, 2003) ekil 5.12 Çok-Etmenli Sistem çerisindeki Etkile imler (Tian and Tianfield, 2003) ekil 5.13 Sistemin Basit Mimarisi (Mago and Devi, 2007) ekil 5.14 SAPHIRE Projesinin Kavramsal Gösterimi (Hein et al., 2006) ekil 5.15 SAPHIRE Çok-Etmenli Sistemi (Laleci et al., 2006) ekil Ek 1.1 Randevu Merkezi Etmeni UML Sınıf Diyagramı ekil Ek 1.2 MedicalNet Etmeni UML Sınıf Diyagramı ekil Ek 1.3 Tıbbi Merkez Etmeni UML Sınıf Diyagramı ekil Ek 1.4 HealthCareInformationSystem Sınıfı çin UML Sınıf Diyagramı..128 ekil Ek 1.5 Departman Etmeni UML Sınıf Diyagramı...129

19 xix EK LLER D Z N (devam) ekil Sayfa ekil Ek 1.6 Doktor Etmeni UML Sınıf Diyagramı ekil Ek 1.7 Kullanıcı Etmeni UML Sınıf Diyagramı ekil Ek 3.1 MedicalCase Sınıfı UML Sınıf Diyagramı ekil Ek 3.2 Muayene Sınıfı UML Sınıf Diyagramı ekil Ek 3.3 Yatan Hasta Sınıfı UML Sınıf Diyagramı ekil Ek 3.4 Hasta Kabul Veriseti UML Sınıf Diyagramı ekil Ek 3.5 Hasta Çıkı Veriseti UML Sınıf Diyagramı ekil Ek 3.6 Tetkik Sonucu Veriseti UML Sınıf Diyagramı ekil Ek 3.7 Reçete Veriseti UML Sınıf Diyagramı ekil Ek 3.8 Muayene Veriseti UML Sınıf Diyagramı ekil Ek 3.9 Yatan Hasta Veriseti UML Sınıf Diyagramı

20 xx

21 xxi KISALTMALAR D Z N Kısaltmalar Açıklama AAS Abstract Architecture Specification ACC Agent Communication Channel ACL Agent Communication Language AID Agent Identifier AMS Agent Management System ANSI American National Standards Institute AOP Agent Oriented Programming AP Agent Platform API Application Programming Interfaces ATC Anatomical Therapeutic and Chemical BA Broker Agent BDI Belief Desire Intention B DB Bilgi lem Daire Ba kanlı ı CCL Constraint Choice Language CG Clinical Guideline CHC Community Health Care CL Content Languages

22 xxii KISALTMALAR D Z N (devam) Kısaltmalar Açıklama DA Doctor Agent DEP Department Agent DF Directory Facilitator DW DataBase Wrapper EHR Electronic Health Record ESK Elektronik Sa lık Kaydı ER Entity Relationship FIPA Foundation For Intelligent Physical Agents FIPA-OS FIPA Open Source GUI Grafical User Interface GUID Globally Unique Agent Identifier HL7 Health Level Seven HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol ICD International Classification of Diseases ICPC2 International Classification of Primary Care Second Edition IDL Interface Definition Language

23 xxiii KISALTMALAR D Z N (devam) Kısaltmalar Açıklama IEEE Institute of Electrical and Electronics Engineers IIOP Internet Inter-Orb Protocol IP Interaction Protocol IPA Intelligent Pediatric Assistant JADE Java Agent Development Environment JVM Java Virtual Machine KIF Knowledge Interchange Format KQML Knowledge Query Manipulation Language MAS Multi-Agent Systems MCA Medical Centre Agent MCDM Multi Criteria Decision Making MHRS Merkezi Hastane Randevu Sistemi MIB Management Information Base MSHCP Multi-Services HealthCare Platform MSISDN Mobile Subscriber Integrated Services Digital Number MSVS Minimum Sa lık Veri Setleri MTP Message Transport Protocol

24 xxiv KISALTMALAR D Z N (devam) Kısaltmalar Açıklama MTS Message Transport System MVS Minimum Veri Setleri NHS National Health Service OECD Organisation for Economic Co-operation and Development OSI Open System Interconnection OWL Web Ontology Language PA Personal Agent PCU Palliative Care Unit PDA Personal Digital Assistant PHC Primary Health Care RDF Resource Description Framework RDFS Resource Description Framework Schema RMA Remote Monitoring Agent RMI Remote Method Invocation RPC Remote Procedure Call SAB M Sa lık Bakanlı ı leti im Merkezi SDO Standards Developing Organization

25 xxv KISALTMALAR D Z N (devam) Kısaltmalar Açıklama SGK Sosyal Güvenlik Kurumu SKRS Sa lık Kodlama referans Sunucusu SL Semantic Language SMS Short Message Service SMTP Simple Mail Transfer Protocol SUT Sa lık Uygulama Tebli i TestBATN Layers Testing Business, Application, Transport and Network TILab Telekom talya Laboratuarları UA User Agent UML Unified Modeling Language URI Universal Resource Identifier USBS Ulusal Sa lık Bilgi Sistemi USVS Ulusal Sa lık Veri Sözlü ü WHO World Health Organization XML Extensible Markup Language

26 xxvi

27 1 1. G R Açık, dinamik de i imlerin çok oldu u ve heterojen ortamların yapısına uygun yazılımların geli tirilmesi iste i yeni teknoloji arayı larına neden olmu tur. Bu arayı ların en önemli sonuçlarından birisi yazılım etmeni (software agent) teknolojisidir. Bir yazılım etmeni (software agent), kullanıcısı adına belirli amaçları yerine getirmek üzere davranma yetene i olan özerk (otonom) ve amaç yönelimli bir yapıya sahip yazılım bile enidir. Tek bir etmenin kendi ba ına çözemedi i veya etkin bir biçimde çözemeyece ini dü ündü ü problemleri birbiriyle i birli i yaparak e güdümlü bir biçimde çözmek için bir araya gelen etmenler toplulu u ise çok-etmenli sistem (multi-agent system) olarak adlandırılmaktadır (Sycara, 1998). Böyle bir etmen sistemine birçok sektörde oldu u gibi, sa lık sektöründe de ihtiyaç duyulabilmektedir. Hasta verisinin hastane içerisinde farklı lokasyonlarda bulunması, hastanede hasta ile ilgili bilgilere eri mek isteyen çok sayıda ki inin olması ve her hastanenin hasta verisini kendi iste i ekilde depolaması gibi sa lık alanında kar ıla ılan birçok sorun vardır. Buradan da anla ılaca ı gibi sa lıkla ilgili problemler oldukça karma ıktır. Bu nedenle sa lık alanındaki karma ık problemlerin çözümü için standart yazılım mühendisli i çözümleri üretmek yerine, çok-etmenli sistemleri kullanmanın daha kullanı lı olaca ı dü ünülmü tür. Sorunları çözmekte çok-etmenli sistemlerin önerilmesinin nedenleri; çok-etmenli sistemlerin bile enlerinin farklı bilgisayarlarda yani farklı lokasyonlarda çalı abilmesi böylece etmenlerin her birinin problemi çözmek için gerekli olan bilginin bir parçasını tutabilmesi, veri alı veri i yapabilmek için bir çe it etmen ileti im dili kullanarak di er etmenlerle ileti im kurabilmesi ve bu ileti imdeki gidip gelen iletiler içerisinde ontolojilerin kullanılmasıyla hastanelerin ortak bir terminoloji ile haberle ebilmesi, olarak verilebilir. Herhangi bir tıbbi merkezden randevu almak isteyen hastayı temsil eden ve onun yerine ilgili randevu i lemlerini gerçekle tiren yazılım etmenlerinin var olması, sistemin daha hızlı i lemesini ve i lemlerin mümkün oldu unca hasta yararına sonuçlanmasını sa layacaktır. Ayrıca doktorlara, HL7 uyumlu hasta verilerine eri ebilme olana ı verilerek hastanın tanı, te his ve tedavisinin daha kolay ve do ru bir ekilde yapılması sa lanmı olacaktır.

28 2 Tez çalı masında; hastaların bilgilerinin tutuldu u MedicalNet adı verilen sistemi, randevuların tutuldu u Merkezi Randevu Sistemini, tıbbi merkezleri, departmanları, doktorları ve hastaları temsil eden etmenlerin olu turdu u çoketmenli bir sa lık bilgi sistemi tasarlanmı ve gerçekle tirilmi tir. Sistem FIPA (Foundation For Intelligent Physical Agents) uyumlu JADE (Java Agent DEvelopment Framework) çerçevesi kullanılarak geli tirilmi tir. Tezin 2. Bölümünde, tez çalı masının temelinde yatan teknolojiler olan anlamsal web ve etmen teknolojilerinin genel bir tanımlaması yapılıp, bu çalı mada kullanılan JADE çoklu-etmen platformu hakkında bilgi verilmi tir. 3. Bölümde, Türkiye de e-sa lık alanında geli tirilen çalı malara de inilmi ve bu çalı malardan tez çalı ması ile ili kili olan Sa lık-net ve Merkezi Hastane Randevu Sistemi detaylandırılmı tır. 4. Bölümde, tez çalı masında geli tirilen sistemin mimarisi, mimari üzerinde bulunan etmenler, etmenler arası ileti imin önemli bir parçası olarak çerik Ontolojisi (Content Ontology) konusunun mimari yapıdaki yeri ve bir Sa lık Ontolojisi geli tirilmesi ve mimarideki etmenlerin bu ontolojiyi nasıl kullandıkları, geli tirilen sistemin kullanıcı giri i için hazırlanması, kullanıcının sisteme girmesi ile gerçekle tirilen i lemler, doktorun sisteme girmesi ile gerçekle tirilen i lemler anlatılmı ve son olarak sistemin sa ladı ı güvenlik kısıtlarına de inilmi tir. 5. Bölümde, literatürde sa lık alanında yapılan çalı malardan kısaca bahsedilmi ve tez çalı ması literatür ba lamında de erlendirilmi tir. Son olarak 6. Bölümde, varılan sonuçlar de erlendirilmi ve 7. Bölümde, çalı manın devamı olabilecek öneriler verilmi tir.

29 3 2. ALT YAPI Bu bölümde tez çalı masının alt yapısını olu turan etmenler, çok-etmenli sistemler, FIPA mimarisi, uygulama geli tirmek için kullanılan JADE platformu ve anlamsal web hakkında temel bilgiler yer almaktadır Yazılım Etmenleri ve Çok-Etmenli Sistemler Açık, dinamik de i imlerin çok oldu u ve heterojen ortamların yapısına uygun yazılımların geli tirilmesi iste i yeni teknoloji arayı larına neden olmu tur. Bu arayı ların en önemli sonuçlarından birisi yazılım etmeni (software agent) teknolojisidir. Yazılım etmenleri, 1990 lı yıllardan ba layarak nternet üzerine da ılmı, de i ik biçemlerde tutulan, sürekli de i en ve geli en bilgilerin kullanıcı amaçları do rultusunda derlenmesi ve i lenmesini gerektiren web temelli uygulamalarda ba arı ile kullanılmı tır (Williamson et al., 1996). Yazılım etmenleri günümüzde de bilgi teknolojileri alanının en önemli ve en hızlı geli im gösteren ara tırma alanlarından birisi olma özelli ini korumaktadır (Luck et al., 2005). Etmen tabanlı mimariler, çalı ma zamanında de i ebilen mimariler sunmakta, etmenlerin plan yapma kabiliyetleri sayesinde beklenmedik durumların üstesinden kolayca gelebilmektedirler (Mylopoulos et al., 2002). Bu bölümde etmen teknolojisi tanıtılacak, etmenlerin sahip olması gereken özellikler belirtilecek ve sonra da çok-etmenli sistemler tanıtılacaktır Yazılım etmenleri Bilgisayarlar, ne yapacaklarını bilme konusunda çok iyi de ildirler. Bir bilgisayarın gerçekle tirdi i her i lem, programcı tarafından dı arıdan verilmeli, planlanmalı ve kodlanmalıdır. Program, tasarımcısının beklemedi i bir durumla kar ıla ırsa, iyi sonuç vermeyecektir. Ço u durumda, bilgisayarların itaatkâr, yalın ve hayal gücü olmayan yardımcılar olmaları birçok uygulama için yeterli görülebilir. Bununla birlikte, gittikçe artan sayıda uygulama için ne yapmaları gerekti ine karar veren sistemlere gerek duyulmaktadır. Bu tür bilgisayar sistemleri, etmenler olarak bilinmektedir. Etmen kavramı, üst düzey amaçlarını gerçekle tirmek için kendi bilgisini, becerilerini ve di er kaynakları kullanarak bulundu u çevreyi algılayan ve üzerinde hareket eden, problem çözme varlı ı

30 4 anlamına gelir. Bir etmen, tipik olarak çevresini (gerçek dünyanın bir parçasında yer alan etmenler durumunda fiziksel algılayıcılarla ya da yazılım etmenleri durumunda yazılım algılayıcılarıyla) algılayacak ve çevresini de i tirmek için çalı tırılan mevcut aksiyonlar listesine sahip olacaktır (AGENT Consortium, 1998). ekil 2.1 de etmen çevre etkile iminin basit bir gösterimi verilmi tir. ekilde de gösterildi i gibi; etmen çevresini algılar, algıladıklarını kullanarak uygun eylemi seçer ve eylemi gerçekle tirerek çevreyi etkileyen çıktı üretir. Bu etkile im genellikle devamlıdır, sona ermez. ekil 2.1 Etmen-Çevre Etkile imi (Vidal et al., 2001) ekil 2.2 de gösterildi i gibi, bir etmenin algılayabildi i nesneler (etmen girdisi); duyusal (sensory) bir bilgi, ba ka bir etmenden alınan bir ileti veya etmenin kendisi tarafından tanımlanan kendileri için ayarladıkları hatırlatmalar gibi bir olay olabilmektedir. Örne in, bir cevap için belirli bir süre beklemek isteyen bir etmen süre sonunda kendisine sürenin doldu unu hatırlatmak için bir olay ba latabilmektedir. Etmenin bekledi i cevap olaydan önce gelirse etmen olayı sonlandırabilmektedir. E er cevap olay ba latıldıktan sonra gelirse, etmen cevabın istedi i zamandan daha geç geldi ini anlayabilmekte ve ona göre i leyi ine devam edebilmektedir (Vidal et al., 2001)

31 5 ekil 2.2 Bir Etmenin Girdilerine li kin Örnekler (Vidal et al., 2001) Literatürde etmenlerin tanımı yapılırken iki farklı görü ten bahsedilmektedir. Bunlardan birincisi; etmenleri yetenekleri açısından daha zayıf olarak ele alan görü tür (weak notion). Buna göre herhangi bir yazılımın etmen sıfatını ta ıyabilmesi için dört özelli i barındırması gerek ve yeter ko uldur. Bu özellikler; özerklik, amaç-yönelimlilik, kar ıt-eylemlilik ve sosyal yetenek özellikleridir (Luck et al., 2004). Bu özellikler, bölümün devamında ayrıntılı olarak anlatılaca ı için burada açıklanmamı tır. Bununla birlikte, etmenleri yetenekleri açısından daha güçlü ele alan görü e göreyse (strong notion), etmenlerin temel özelliklerine ek olarak; inanç, arzu ve niyet (Belief Desire Intention-BDI) zihinsel süreçlerini modelleyen daha akıllı varlıklar olmaları gerekti i savunulmaktadır. Klasik yapay zeka yakla ımına dayanan bu görü e göre, etmenlerin kendi iç yapılarında, bulundukları ortamı sembolik olarak modelleyebilmeleri gereklidir (Luck et al., 2004). Bu iç modeller üzerinde i leme ve çıkarsamalar yaparak, hayat döngüleri içerisinde bir sonraki adımda ne yapmaları gerekti ine karar verebileceklerdir. Bir etmene ili kin özellikler iki grupta incelenmektedir. Her etmende olması gereken özellikler birincil özellikler olarak adlandırılmaktadır. Birincil özellikler, bir etmeni klasik donanım veya yazılım sistemlerinden ayıran özelliklerdir. Bir donanım veya yazılım sisteminin etmen olarak nitelendirilebilmesi için mutlaka birincil özellikleri barındırması gerekmektedir. Bunun dı ında, bir sistemin etmen olma kavramını güçlendiren ve genellikle geli tirilen uygulamaya ba lı olan

32 6 özellikler de bulunmaktadır. Bu özellikler ikincil özellikler olarak adlandırılmaktadır (Erdur, 2001). Bir etmenin birincil özellikleri, özerklik, kar ıt-eylemlilik, amaçyönelimlilik, sosyal yetenek ve süreklilik özellikleridir. Bu özellikler (Erdur, 2001): Özerklik; bir etmenin insan kullanıcıların, di er etmenlerin veya sistemlerin do rudan katılımı olmadan görev ba latabilme ve çalı abilme yetene i olarak tanımlanmaktadır. Özerk bir etmen, kendi eylemleri (action) ve içsel durumunu kontrol edebilmektedir. Bir etmenin özerk olması onun sınırsız bir özerklik çerçevesi içinde çalı tı ı anlamına da gelmemektedir. Bir etmenin özerkli i kullanıcısı tarafından denetlenebilmelidir. Bu ba lamda, etmenler gerekti inde kullanıcılarına danı arak onlardan aldıkları geribildirimler (feedback) do rultusunda eylemlerini planlamaktadırlar. Örne in, kullanıcısına gelen e- postaları izleyen ve yeni bir e-posta geldi inde kullanıcısını uyaran bazı uygulamalar gibi. Kar ıt-eylemlilik (Reactivity): Bir etmen sürekli olarak bulundu u ortamı algılamalı, ortamdaki de i imlere göre bilgisini, amaçlarını, eylemlerini de i tirebilmelidir. Bununla birlikte gerekti inde di er etmenlere ileti göndererek söz konusu de i ikli i onlara da bildirebilmelidir. Etmenin içinde bulundu u ortam, fiziksel algılayıcılar ile algılanabilen fiziksel bir ortam, bir etmenler toplulu u veya nternet olabilmektedir. Örne in, nternet ortamında herhangi bir konuda bilgi sunan bir sunucuyu izleyen bir etmen, izledi i sunucudaki bilgide güncelleme yapıldı ını algıladı ında bilgisini, amaçlarını ve eylemlerini gözden geçirmeli, ayrıca bu de i ikli i ilgili kullanıcı ve etmenlere onlara ileti göndermek yolu ile bildirmelidir. Amaç-yönelimlilik (Goal-orientedness): Amaç-yönelimlilik, bir etmenin kendisinden beklenenleri yerine getirmek için planlama yaparak bu planların gerektirdi i eylemleri gerçekle tirmesi olarak tanımlanmaktadır. Bir etmenin eylemde bulunması, bu tez kapsamında, o eyleme ili kin yordam, yöntem veya fonksiyonların i letilmesi anlamında kullanılmaktadır. Etmenin bir eylemde bulunabilmesi için o eyleme ili kin ön ko ulların sa lanmı olması gerekmektedir. Etmenin bir eylemde bulunması sonucunda etmenin bilgisi, varsayımları de i ebilmekte veya ba ka etmenlere ileti göndermesi gerekebilmektedir.

33 7 Sosyal yetenek (Social ability): Bir etmen, planlarına ili kin görevlerini tamamlayabilmek için genelde di er etmenler veya insan kullanıcıları ile etkile mek durumunda kalmaktadır. Bu etkile im ancak bir etmenler arası ileti im dili kullanarak sa lanabilecektir. Etmenler arası ileti im, çok-etmenli sistemlerin en önemli konularından birisidir. Kalıcı süreklilik (Temporal continuity): Bir etmen, belli bir görevi yapıp durmamalıdır. Etmenler belli bir ortamda sürekli olarak çalı an birimlerdir. Etmen, ba lattı ı görevleri tamamladıktan sonra da etkin olarak kalmalı ve çevresini algılayıp gereken eylemleri gerçekle tirmek için hazır olarak beklemelidir. Bir etmenin ikincil özellikleri arasında gezicilik, ö renme, akılcılık, dürüstlük ve olumluluk sayılabilmektedir. Bir etmenin ikincil özelliklerin tümünü içermesi gerekmemektedir. kincil özelliklerden bazıları a a ıda açıklanmaktadır (Erdur, 2001): Gezicilik (Mobility): Bir etmen e er a üzerinde bir yerden ba ka bir yere gidebiliyor ise "gezici etmen" olarak adlandırılmaktadır. Ö renme (Learning): Bir etmen kendisini ortama uyarlayabilmeli, kullanıcı e ilimlerini ö renerek eylemlerini bu do rultuda de i tirebilmelidir. Akılcılık (Rationality): Bir etmenin amaçları do rultusunda planlama yapmak için çalı ması "akılcılık" olarak adlandırılmaktadır. Akılcı bir etmen, kasıtlı olarak, amaçlarına ula mayı engellemek için plan yapmamalıdır. Dürüstlük (Veracity): Bir etmenin kasıtlı olarak yanlı bilgi ileti iminde bulunmaması "dürüstlük" olarak adlandırılmaktadır. Olumluluk (Benevolence): Bir etmenin, amaçlarına ters dü medikçe kendisinden beklenen her eyi yerine getirmek için çalı ması "olumluluk" olarak adlandırılmaktadır. Etmenlerle ilgili birincil ve ikincil özellikleri açıkladıktan sonra yeni bir etmen tanımı verilebilir:

34 8 Etmen, kendisinden beklenenleri yerine getirmek için belli bir ortamda belli derecede özerklik çerçevesinde çalı an, algılayıcıları ile ortamdaki dinamik de i imleri algılayan ve elde etti i algılara göre bilgisini, amaçlarını yeniden de erlendiren, amaçları do rultusunda planlama yaparak bu planlara ili kin eylemleri gerçekle tiren, di er etmenler ile bir etmenler arası ileti im dili aracılı ı ile ileti imde bulunma yetene i olan ve bulundu u ortamda süreklilik gösteren yazılım veya donanım tabanlı sistemdir (Erdur, 2001) Etmen ile Nesne Ayrımı Etmene Dayalı Programlama (Agent Oriented Programming-AOP) Nesneye Dayalı Programlamanın geli tirilmi hali olarak tanımlanmaktadır. Nesneye Dayalı Programlamada temel varlık nesne dir. Bir nesne, veri yapıları ve bu yapılarla ilgili metotların mantıksal birle imidir. Nesneler pasif varlıkların (ev,vb..) birer soyutlaması olarak kabul edilmekte, etmenler bu soyutlamayı aktif varlıklar için de olası hale getirdikleri için nesnelerden daha geli mi olarak nitelendirilmektedirler. Etmenler nesnelere benzemekle birlikte zihinsel bile enler, inanç gibi yapıları da desteklemektedirler (Yurdakul, 2007) Bu özelliklere ek olarak etmenler, etmenler arası yüksek seviyeli etkile imi FIPA-ACL (FIPA Agent Communication Language) (FIPA, 2002), KQML (Knowledge Query Manipulation Language) (Finin et al., 1995) gibi etmen ileti im dillerini kullanarak) desteklemektedirler. Nesne yönelimli sistemlerde, bir eylemin yapılıp yapılmayaca ı (bir yöntemin ça rılıp, ça rılmayaca ı) ça rımı yapan nesne tarafından kararla tırılmaktadır. Örne in, A nesnesi, B nesnesindeki metot1 isimli yöntemi ça ırmak için B.metot1() biçiminde bir kod i letmelidir. Oysa, etmenlerde bu tür bir ça rım yoktur. Bir A etmeni, B etmeninden metot1 isimli metodun ça rılmasına kar ılık gelen bir eylemde bulunmasını istedi inde, bu iste ini bildiren bir etmen ileti im dili iletisini B etmenine göndermektedir. Bu gönderim, eylemin mutlaka yapılaca ı anlamına gelmemektedir. B etmeni, kendi bilgi tabanında yer alan bilgiler çerçevesinde eylemi yapıp yapmayaca ına karar vermektedir (Erdur, 2001).

35 Çok-etmenli sistemler Çok etmenli sistemler (multi-agent systems-mas), etmen adı verilen varlıkların birbirleriyle etkile ti i sistemlerdir. Etmenler; bireysel amaçlarını ve bütün sistemin amaçlarını kar ılamak için birbirleriyle ileti im kurarlar ve i birli i yaparlar, koordinasyon sa larlar ve görü ürler. Tek bir etmenin yalnız ba ına kendi bilgi ve bireysel yeteneklerini kullanarak çözemedi i veya etkin bir biçimde çözemeyece ini dü ündü ü problemleri birbiriyle i birli i yaparak e güdümlü bir biçimde çözmek için bir araya gelen etmenlerin olu turdu u a, i birlikçi (cooperative) çok-etmenli sistem (MAS) olarak adlandırılmaktadır (Sycara, 1998). Çok-etmenli sistemler, birden çok, ayrık ve ba ımsız etmenin, her birinin tek ba ına çözemeyece i kadar karma ık olan problemleri çözebilmek amacına yönelik olarak gev ek ba lı (loosely-coupled) bir yapı altında bir araya geldi i sistemlerdir (Elamy, 2005). Çok-etmenli sistemler, özellikle da ıtık durumda ve farklı yetenekleri olan etmenleri bir araya getirebilme özellikleri olmasından dolayı, do ası gere i da ıtık olan uygulama alanları için uygundurlar. Bu tip uygulama alanlarına örnek olarak, da ıtık algılayıcı a ları, hava trafik kontrol sistemleri, karar destek sistemleri, telekomünikasyon yönetim sistemleri, mobil ve her yerde olan (ubiquitous) sistemler gösterilebilir FIPA çoklu-etmen mimarisi FIPA, çok-etmenli sistemler arasındaki birlikte-çalı abilirli i (interoperability) ve tekrar kullanılabilirli i en üst düzeye çıkartmak için evrensel standartlar ortaya koymak amacı ile kurulan, kar amacı gütmeyen bir topluluktur (FIPA, 2002) yılında kurulmu tur. Etmen tabanlı bilgi i lem alanında standartları belirleyen kurumların ba ında gelen FIPA, etmen ileti im dilleri (Agent Communication Languages-ACL), çerik Dilleri (Content Languages-CL), etkile im protokolleri (Interaction Protocols-IP), etmen yönetimi ve etmen mesajla ma altyapıları konularında standartlar geli tirmektedir (Luck et al., 2004). FIPA standartlarına uyan, yani FIPA uyumlu bir sistem FIPA uyumlu her heterojen sistem ile birlikte çalı abilir (Georgousopoulos and Rana, 2002).

36 10 FIPA mimarisinde etmenlerin sahip oldu u karakteristikler a a ıda verilmi tir (Do aç and Çingil, 2003): Her etmenin tek ve de i emeyen bir etmen-ismi (agentname) vardır. Etmenlerin öznitelikleri (attribute) olabilir. Etmenler, söz-eylem (speech-act) eklinde belirtilebilen iletiler gönderip alarak haberle irler ve bunlar bir etmen ileti im dilinde kodlanmı tır. Her etmen, bir veya daha fazla aktarım tanımlamalarına sahiptir be bu tanımları di er etmenlere ileti aktarırken kullanırlar. Ta ıma (transport) iletilerin aktarımı için bir mekanizmadır. Her ta ıma-tanımı belirli formdaki bir ileti aktarımı ile ilgilidir, IIOP (Internet Inter-Orb Protocol), SMTP (Simple Mail Transfer Protocol) ve HTTP (Hypertext Transfer Protocol) gibi. Ta ıma iletisi (transport-message) bir etmenden di erine kullanılan aktarıma uygun bir formatta gönderilir. Bir yer bulucu (locator) aktarım tanımlamalarını içerir, her biri ilgili etmene gönderilen bir iletinin aktarımındaki gerekli bilgiyi içerir. Servisler etmenler için kolaylık sa lar. Bir servis, desteklenen bir grup eylem (action) olarak tanımlanır. Her eylem, servis ile o servisi kullanan etmen arasındaki etkile imi tanımlamaktadır. Bir somut mimarinin FIPA uyumlu olabilmesi için, etmen kayıtları (registration), etmen bulma (discovery) ve etmenler arası ileti transferi için mekanizmalara sahip olması gerekmektedir (Erdur, 2001). FIPA Soyut Mimarisi (FIPA AAS-FIPA Abstract Architecture Specification) iki tane destek servisi tanımlamaktadır. Bunlar: Dizin Servisleri (Directory Facilitator-DF) ve leti Aktarım Servisleridir (Message Transport System-MTS). Servisler etmenler eklinde, ya da metot ça rılması üzerinden eri ilen ve etmen-olmayan yazılımlar eklinde Java, C++ içinde sa lanan programlama arayüzlerini kullanarak gerçekle tirilebilirler (Do aç and Çingil, 2003) FIPA Etmen Yönetimi FIPA Etmen Yönetimi spesifikasyonu, FIPA etmenlerinin bulundu u ve çalı tıkları platformu sa lamaktadır. Etmenlerin yaratılması, kayıtlanması, göç etmesi ve silinmesi durumlarının mantıksal bir referansını olu turmaktadır. Etmen yönetimi referans modelinde yer alan ögeler ekil 2.3 de gösterilmektedir. Bu

37 11 ögeler mantıksal yetenek gruplarıdır (örne in servisler) ve herhangi bir fiziksel konfigürasyon içermemektedir. Referans model, bir etmen platformunda olan servisleri desteklemek için gerekli olan temel yapıları ve ontolojileri tanımlamaktadır (FIPA, 2002). ekil 2.3 FIPA Etmen Yönetimi Referans Modeli (FIPA, 2002) FIPA etmen yönetim ontolojisine göre (Do aç and Çingil, 2003): Bir etmen, bir Etmen Platformu (Agent Platform-AP) üzerindeki temel aktördür, bir veya daha fazla servis yetene ini, birle tirilmi ve entegre edilmi bir i leme modeline ba lar. Her etmenin bir sahibi vardır, bu bir organizasyon ya da kullanıcı olabilir. Bir etmen, Etmen Kimli i (Agent Identifier-AID) ile tanımlanır, bu aynı zamanda etmen ismi olarak da bilinir. Etmen Yönetim Sistemi (Agent Management System-AMS) bir beyaz sayfalar sunucusudur. Platform içindeki etmenlerin yaratılması, silinmesi ve genel durumunu yönetir. Her etmen geçerli bir AID almak için bir

38 12 AMS ye kayıtlanmalıdır. AMS, bir etmen platformunda o an yerle ik tüm etmenlerin indekslerini (etmenlerin AID lerini) tutar. Dizin Servisi (Directory Facilitator-DF) bir sarı sayfalar sunucusudur. Etmenler servislerini DF ye kayıt ettirebilirler ya da di er etmenler tarafından önerilen servisleri bulmak için DF i sorgulayabilirler. Her Etmen Platformunda en az bir DF bulunmak zorundadır. Spesifik bir servis sorgulandı ı zaman, DF bilgiyi elde etmek için di er DF lerle ili ki kurabilir. leti Aktarım Servisi (Message Transport System-MTS), farklı etmen platformları üzerinde bulunan etmenler arasındaki ileti im için kullanılan servistir. Yazılım, etmenle ilgili olmayan, i letilebilir talimat koleksiyonlarının tümünün bir etmen üzerinden eri ilebilir olmasını sa lamaktadır. Etmenler yazılıma yeni servis eklemek için, yeni ileti im protokollerini elde etmek için, yeni güvenlik protokolleri/algoritmalarını elde etmek için, yeni müzakere protokollerini elde etmek için, ta ınmayı destekleyen araçlara eri mek için gibi nedenlerle eri ebilirler Etmen leti imi FIPA sistemlerinde etmenler birbirlerine ileti (mesaj) göndererek ileti im kurarlar. Bir ileti etmen ileti im dilinde yazılır ve içerik tanımlama diliyle yazılmı bir içeri e sahiptir. FIPA nın tanımladı ı ileti yapısı ekil 2.4 de gösterilmektedir. Bu ileti, iletiyi gönderene kar ılık gelen etmen-ismi ve iletinin alıcısı ya da alıcılarına kar ılık gelen bir ya da daha fazla etmenin isimlerini içermektedir. Ayrıca iletinin, ontoloji gibi bir içerik tanımlama dili ile yazılmı içerik bölümü vardır. Bir ontoloji, ilgili yorumu ile birlikte olan semboller toplulu udur ve etmenler toplulu u ya da servisler tarafından payla ılabilir. Ayrıca bir ontoloji sahası içerisinde var olan kısıtları anlatan mantıksal ifadeleri de içerebilir (Do aç and Çingil, 2003).

39 13 ekil 2.4 FIPA leti Yapısı (FIPA, 2000) FIPA ACL FIPA ACL iletiye dayalı bir etmen ileti im dilidir. Çok etmenli sistemlerde, etmenler amaçlarına ula mak için di er etmenlerle birlikte çalı mak zorundadırlar. Di er etmenlerle etmen ileti im dili kullanarak ileti im kurarlar. FIPA ACL iletisi; ileti aktarım ayrıntılarını içeren Envelope, iletinin içerik bölümü ve i letimselini (performative) ve i letimsele ait di er parametrelerini içeren Payload bölümünden olu ur (FIPA, 2000). ekil 2.5 Ta ıma letisinin Olu turulması (FIPA, 2000)

40 14 FIPA ACL iletisinin hazırlanı ı ekil 2.5 de gösterilmi tir. Bir ileti ( ekil 2.4), payload içerisine kodlanır (encode). payload ileti içerisine yeni bir ey eklemez sadece farklı bir gösterim için kullanılır. Gönderici ve alıcı bilgisini içeren uygun bir envelope olu turulur. payload ve envelope ikisi beraber ta ıma iletisini (transport-message) meydana getirir (FIPA, 2000 ). FIPA ACL iletilerin paketlenmesinde standart bir yöntemdir, böylece iletinin alıcısının iletinin anlamını ve amacını kavraması sa lanmı olur (FIPA, 2000 ). FIPA u içerik dillerini destekler: FIPA Semantik Dili (FIPA Semantic Language-SL), FIPA Kısıt Seçim Dili (FIPA Constraint Choice Language-CCL), FIPA Bilgi De i im Formatı (FIPA Knowledge Interchange Format-KIF) ve FIPA Kaynak Tanımlama Çerçevesi (FIPA Resource Description Framework- RDF) FIPA Uyumlu Platformlar ve Araçlar Günümüzde çok-etmenli sistemler ile uygulama geli tirmek mümkündür. Bunun için JADE (Java Agent Development Framework), SEAGENT (Dikenelli et al., 2005), ZEUS (Collis et al., 1998), FIPA-OS (FIPA Open Source) (Poslad et al., 2000) ve JADEX (Braubach et al., 2004) gibi çerçevelerden birini kullanmak gereklidir. JADE en çok kullanılan çerçevelerden biridir. Tez çalı masında sistem geli tirmek için JADE kullanılmı tır. Bu nedenle, bundan sonraki bölümde detaylı olarak anlatılacaktır JADE (Java Agent Development Framework-JADE) çoklu-etmen platformu Teze kapsamındaki proje geli tirilirken; FIPA uyumlu çoklu-etmen platformu olarak JADE (Bellifemine et al., 2001) kullanılmı tır. JADE in FIPA uyumlu olması, açık kaynak kodlu bir çalı ma olması, endüstri ve akademik çalı malarda çokça kullanılması, ontoloji temelli içerik dillerinin (Content Language-CL) kullanımı için deste inin olması, asenkron mesaj-geçi i tarzı ileti im altyapısının bulunması, bloke olmayan ve tek i parçalı (single-threaded) çalı ma mantı ını kullanması ve içerisinde kullanıma hazır çe itli davranı (görev)

41 15 kütüphanelerini barındırması gibi nedenlerle çalı ma geli tirilirken JADE kullanılması uygun görülmü tür. JADE (Java Agent Development Environment) FIPA uyumlu bir çokluetmen platformu ve bu platform üzerinde FIPA uyumlu etmenler geli tirmek için Java tabanlı bir kütüphane altyapısı sunan araçlardan olu ur (Luck et al., 2004). TILab (Telekom talya Laboratuarları) tarafından da ıtılan ve 1999 yılından beri kullanıcı katkılarıyla geni leyen JADE bir açık kaynak kod projesidir. JADE in temel amacı etmen tabanlı sistem geli tirmeyi basitle tirmek ve bir dizi sistem servisleri ve etmenler ile FIPA uyumlulu unu sa lamaktır (Do aç and Çingil, 2003). JADE, üzerinde çalı an etmenlerin özerk olma ve sosyallik gösterebilme özelliklerini yerine getirebilmeleri için gereken temel i levleri sa lar. JADE, platform üzerinde çalı an etmenlerin aktif birer i parçacı ı olarak çalı masını destekleyerek, etmenlerin özerk olmasını, etmenler arası kar ılıklı (peer-to-peer) etkile imlerin asenkron mesajla ma protokolleri aracılı ıyla gerçeklenmesiyle de etmenlerin sosyal olmasını sa lanmaktadır. Geli tirilen etmenler, JADE in altyapı kütüphanesi tarafından sa lanan etmen sınıfı (agent class) kullanılarak ve bu sınıf geni letilerek (extend) yaratılır. Platform üzerindeki etmenler birbirlerinden ba ımsız olarak çalı maya ba latılabilir, durdurulabilir, dondurulabilir, kopyalanabilir ya da platformdan çıkartılabilirler. Platform bunlara ilaveten standart FIPA ACL iletileri olu turulabilmesi için de Uygulama Programlama Arayüzleri (Application Programming Interfaces-API) sunar. Spesifik etmen süreçleri yani davranı lar (görevler), JADE altyapısının sundu u davranı sınıfı kullanılıp geni letilerek elde edilirler. Altyapının sa ladı ı standart metotlar sayesinde, etmenlere belli davranı tipleri kazandırılabilmekte, gerekti inde yeni davranı lar eklenip, gerekmeyen davranı çıkarılabilmektedir. Etmenler hayat döngülerine ba ladıktan sonra, kendileri için tanımlı olan davranı ları dönerli (round-robin) ve kesilemeyen bir sıralamayla (non-preemptive schedule) yerine getirirler. ekil 2.6 da JADE etmen davranı larının UML (Unified Modeling Language) sınıf diyagramı gösterilmi tir. ekilde görüldü ü gibi JADE etmen davranı ları temelde ikiye ayrılır. Bunlar basit (SimpleBehaviour) ve alt davranı lara ayrılabilen birle ik ve karma ık (CompositeBehaviour) etmen davranı larıdır. Ayrıca bu davranı ların bir alt

42 16 sınıfları olan, sık kullanılan ve altyapı tarafından standart olarak sunulan davranı kalıpları; döngüsel (cyclic), bir kereye mahsus (one-shot), paralel, sıralı ve sonludurum makinesi tipi davranı lar da görülebilmektedir (Ate, 2008). ekil 2.6 Behaviour Sınıfının UML Sınıf Diyagramı (Bellifemine et al., 2005) Bir JADE etmen platformu birden fazla makine üzerine da ılmı bir çok içericiden (container) olu abilmektedir. Her bir içerici içerisinde, bir ya da bir çok etmen bulunabilmektedir. çericiler, etmenler arası haberle menin sorunsuz bir biçimde gerçekle mesini ve etmenlerin platform tarafından sunulan servislere eri imlerini sa larlar. Aynı içerici bünyesindeki etmenler aralarında Java olay mekanizmasıyla, aynı platform üzerindeki etmenler Java RMI (Remote Method Invocation) mekanizmasıyla haberle irlerken, platformlar arası haberle me standart FIPA leti Ta ıma Protokolleri (Message Transport Protocol-MTP) kullanılarak gerçekle tirilir. ekil 2.7 de üç farklı makine üzerinde da ıtık olarak gerçeklenen bir JADE etmen platformu ve bu platforma ait üç etmen içericisi ve her bir içerici içerisinde üç adet uygulama etmeni gösterilmektedir. Her bir içerici

43 17 ayrı bir Java sanal makinesi (Java Virtual Machine-JVM) üstünde çalı makta, uygulama etmenleri farklı birer i parçası olarak ya am döngülerini sürdürmekte ve faklı içericilerdeki etmenler birbirleriyle RMI mekanizması aracılı ıyla haberle mektedirler (Bellifemine et al., 2005). ekil 2.7 Bir JADE Da ıtık Etmen Platformu Örne i (Bellifemine et al., 2005) Her bir JADE platformu, FIPA nın ana bile enlerini, AMS, DF ve Etmen leti im Kanalını (Agent Communication Channel-ACC) içerir. Platform çalı tırıldı ında bu etmenler platforma otomatik olarak eklenir. JADE, bir etmenden di erlerine ileti gönderimi ve alımı için aktarım mekanizması ve etmenlerin ya am döngülerinin takibi ve yönetimi için, grafik arayüzlü bir Uzaktan zleme Etmeni (Remote Monitoring Agent-RMA) de sa lamaktadır. Ayrıca etmenler çalı tırıldıklarında GUID (Globally Unique Agent Identifier) de erlerini platformdan alırlar, çünkü JADE, FIPA uyumlu bir isimlendirme servisine sahiptir. JADE in Grafiksel Kullanıcı Arayüzü (Grafical User Interface-GUI) vardır, böylece etmenlerin ve içericilerin (container) ya am döngülerinin uzaktan yönetilebilmesi ve aynı zamanda etmenlerin izlenmesi ve kontrol edilmesi sa lanır. Ayrıca JADE çerçevesi içerisinde hata ayıklamak için grafiksel araçlar da bulunmaktadır.

44 Etmen Görevlerinin JADE Çerçevesi Kullanılarak Programlanması JADE çerçevesinde bir etmenin yapması gereken i, davranı lar (behaviour) ile gerçekle tirilir. Bir davranı, JADE altyapısında gelen jade.core.behaviours.behaviour sınıfı geni letilerek (extend) olu turulur. Etmenin olu turulan davranı içerisindeki görevi yerine getirebilmesi için addbehaviour() metodunu çalı tırması gerekir. Davranı lar; bir etmen ba ladı ında (setup() metodu içerisinde) ya da di er davranı lar içerisinden herhangi bir zamanda eklenebilirler. JADE Behaviour sınıfını geni leten her sınıf action() metodunu gerçekle tirmek zorundadır. Bu metot, davranı çalı ır durumdayken gerçekle tirilmesi gereken i lemleri tanımlamaktadır. Bir etmen birçok davranı ı aynı anda çalı tırabilir. Ancak bir etmendeki davranı ların zamanlamasına dikkat etmek gerekmektedir, çünkü bir davranı ın çalı abilmesi için di er davranı ın tamamlanması gerekebilir. Bu durumda programcı, davranı lar arasındaki zamanlamayı iyi belirlemelidir. 2003). Etmen i parçacı ının çalı ma yöntemi ekil 2.8 de verilmi tir (Caire, ekildeki akı diyagramında da görüldü ü gibi, bir etmen setup metodu ile çalı maya ba lar ve takedown metoduyla çalı masını tamamlar. Arada kalan zaman etmenin ya am süresini gösterir. Bu ya am süresi içerisinde etmen sırasıyla kuyruktan davranı ları alır ve action() metodu ile i letir. Davranı ın done() metodu ( boolean bir de er döndürür) ça rılmı sa davranı kuyruktan atılır, ça rılmamı sa kuyrukta en son sıraya konur. Her iki durumdan sonra, etmen sıradaki davranı a geçer.

45 19 ekil 2.8 Etmen Parçacı ının Çalı ma Yöntemi (Caire, 2003) 2.2. Anlamsal Web Anlamsal web Temelleri daha eski dönemlerde gerçekle tirilen yapay zeka çalı malarına dayanmakla birlikte ubat 2001 tarihinde, World Wide Web Konsorsiyumu tarafından, verinin web üzerinde anlamsal gösterimini sa lamak amacıyla Anlamsal Web (Semantic Web) kavramı ortaya atılmı tır. World Wide Web in kurucusu Tim Berners Lee, Anlamsal Web in günümüzdeki web teknolojilerinin bir uzantısı oldu unu, Anlamsal Web kullanılmasıyla bilginin anlamının daha iyi bir ekilde tanımlandı ını, ve böylece bilgisayar ve kullanıcıların birlikte çalı abilirliklerinin arttı ını söylemi tir (Komesli and Ünalır, 2007). Günümüz bilgi i lem uygulamalarının hemen hemen hepsi kendi içlerinde dı a kapalı (kapalı dünya yakla ımı) bir ekilde varlıklarını devam

46 20 ettirmektedirler. Uygulamanın tasarımcıları ve geli tiricileri, geli tirdikleri modeli uygulamanın içine gömerler. Örne in, da ıtık bir uygulamada, da ıtık yapıdaki bile enler arasındaki ileti im ya soket tabanlı, ya bir çe it Uzaktan Yordam Ça ırma (Remote Procedure Call-RPC, Remote Method Invocation-RMI, CORBA), ya da bunların daha modern versiyonları olan web servisleri kullanılarak gerçekle tirilir. Benzer ekilde bir veritabanı uygulamasında da, veri modelleri ve bu uygulamanın modelleri kullanı ekilleri, yazılım programlarının içine gömülür. Geli tirilen modellerin di er insanlar tarafından anla ılabilmesi ancak yorum satırları, basit açıklayıcı notlar, UML modelleri, ER (Entity Relationship) diyagramları, kavramsal ve mantıksal emalar, IDL (Interface Definition Language) ya da MIB (Management Information Base) benzeri biçimsel diller kullanarak yapılabilmektedir. Bu durumda bile modellerin anla ılabilmesi insan faktörüne ba lıdır (Ate, 2008). Açık dünya yakla ımına geçi üst veri (meta-data) kavramını uygulamakla sa lanabilir. Artık, insanların bilgisayarların seviyelerine inerek uygulama geli tirmeleri yerine, bilgisayarları insanların düzeyine çıkartarak çalı tırmak ve bu sayede onlardan daha fazla verim almak mümkün hale gelmi tir. Eskiden kullanılan makineye yönelik byte tabanlı aktarım yapılarının yerine XML (Extensible Markup Language) gibi karakter tabanlı ve geli tirilebilir mesajla ma formatları kullanılmaya ba lanmı tır. XML (Bray et al., 2006), kullanıcıların dokümanlarına geli igüzel yapılar eklemesine olanak sa lar ancak eklenen yapıların ne anlama geldi i konusunda herhangi bir destek vermez. Yani iki farklı XML sözdizimi, bunları okuyan bir insan için farklı anlamlar ifade edebilir ancak, bir bilgisayar açısından anlamsal olarak herhangi bir farkları yoktur. Buradan da anla ılabilece i gibi, üst veri yapısı olarak yalnızca XML kullanımı açık dünya yakla ımını uygulamak için yeterli de ildir. Anlamsallı ın sa lanabilmesi için XML in üzerinde ba ka birtakım katmanlara ihtiyaç oldu u görülmektedir (Ate, 2008) Anlamsal web in geli imi Anlamsal Web in geli imi adım adım ilerlemektedir, her adım bir di erinin üzerine bir katman in a etmektedir (Antoniou and Harmelen, 2004). Tim Berners Lee nin Anlamsal Web için sundu u katmanlı mimari ekil 2.9 göstermektedir.

47 21 Unicode ve URI (Universal Resource Identifier) katmanlarında uluslararası karakter kümeleri kullanılır ve bu katmanlar Anlamsal Web de nesnelerin tanımlanabilmesine imkan sa larlar. XML katmanı, tüm mimarinin dil bilgisi yapısını ve sözdizimini olu turur. Ancak yukarıda da bahsedildi i gibi, anlamsallık deste i içermemesi nedeniyle; XML, XML sim Uzayları ve XML ema üst veri yapıları kullanılarak olu turulan modellerin, insanlar tarafından incelenip anla ılması ve bilgisayar tarafından otomatik i lenip çıkarsama yapılması mümkün olmamaktadır. Bu sorunu gidermek için, bir üst seviyede RDF (Resource Description Framework-Kaynak Betimleme Çatısı) ve RDF ema (Resource Description Framework Schema-RDFS) üst veri katmanı yer almaktadır (Berners Lee, 1999) ekil 2.9 Anlamsal Web Katmanları (Berners Lee, 1999) Ontoloji katmanı, sözlüklerin de i imini sa lar ve farklı kavramlar arasındaki ili kileri tanımlar. Ontolojiler, birlikte çalı acak uygulamalar için payla ılan ortak bir terminoloji sa lamaktadırlar. Bir ontoloji, veriler arasındaki sıradüzenleri, karma ık ili kileri ve bunların anlamlarını ortaya çıkarmak amacıyla kullanılır. (Urgancıo lu, 2006). Dokümanlardaki de i iklikler, sayısal imza katmanı tarafından belirlenir. Bu katmanlar, W3C çalı ma grupları tarafından standart hale getirilmektedir (Komesli and Ünalır, 2007). ekil 2.9 daki yapıda ontoloji katmanından bir üst seviyeye çıktı ımızda mantık katmanıyla kar ıla maktayız. Bu katman çıkarsamaların gerçekle tirilebilmesi için kuralların yazılmasını sa lar. Bu katman sayesinde,

48 22 ontolojilere mantıksal kurallar eklenerek, modellenen veri parçaları arasında mevcut olan ancak do rudan anla ılamayan ili kiler, çıkarsama motorları vasıtasıyla ortaya çıkarılabilirler (Urgancıo lu, 2006). Kanıt katmanı, kuralları uygular ve Güven katmanının mekanizması ile birlikte verilen kanıtların güvenilir olup olmadı ı de erlendirilir (Komesli and Ünalır, 2007) Ontoloji Farklı veri tabanlarında, aynı kavrama kar ılık gelen farklı tanımlar kullanılabilmektedir. Anlamsal web`de ontolojiler kullanılarak bu tür problemler çözülmeye çalı ılmaktadır. Örne in, iki farklı veri tabanında "ad" ve "isim" olarak iki farklı tanımlama kullanılabilir. Bir uygulama, bu iki veritabanındaki bilgileri birle tirmek istedi inde bu iki tanımlamanın aynı anlama geldi ini anlayabilmelidir. Bu ekilde aynı anlama gelen bir çok tanımlama ile kar ıla ılabilir. Bunun için getirilen çözüm, Anlamsal Web in bir bile eni olan ontolojilerdir (Berners-Lee et al., 2001). Genelde, ontolojiler belirli bir alan için olu turulurlar. Bir ontoloji, terimler listesinden ve bu terimler arasındaki ili kilerden olu ur. Terimler, alanın önemli kavramlarını (nesne sınıflarını) ifade etmektedir. Örne in, bir üniversite kurumundaki, memur kadrosu, ö renciler, amfiler ve yönetmelikler kavram olarak tanımlanabilir (Antoniou and Harmelen, 2004). Ontolojilerdeki çıkarsama kuralları daha ileri bir güç sa lamaktadır. Daha önce de bahsedildi i gibi, bir ontoloji çıkarsama kurallarının uygulanması ile nesneler arasındaki gizli kalmı ili kileri ortaya çıkarabilir. Ayrıca, arama motorları ontoloji içerisinde bütün sayfalardan ilgili sayfaları aramak yerine tam anlamına uygun arama yapabilirler. Bu durumda nternet sayfaları ile sorgular arasındaki terminoloji farklılı ı ortadan kaldırılmı olur. Buna ek olarak, nternet aramalarında genelleme/özelle tirme gibi bilgilerin kullanılmasını sa lar. E er bir sorgu sonucunda hiçbir doküman bulunamazsa, arama motoru kullanıcıya daha genel bir sorgu önerebilir. Ya da e er çok fazla sonuç bulunduysa arama motoru bazı özelle tirmeleri önerebilir (Yurdakul, 2007).

49 ): Günümüzdeki önemli ontoloji dilleri unlardır (Antoniou and Harmelen, XML yapısal dokümanlar için bir söz dizim gösterimidir. Bu dokümanlarda hiçbir anlam kısıtlaması yoktur. XML ema, XML dokümanlarının yapısını sınırlandıran bir dildir. RDF nesneler (kaynaklar) için veri modelidir. RDF, XML söz dizimi ile gösterilen veri modellerine basit bir anlam sa lar.. RDF ema, RDF kaynakların sınıflarını ve özelliklerini tanımlamak için kullanılan bir sözlük tanımlama dilidir. OWL (Web Ontology Language) özellikleri ve sınıfları tanımlayan daha zengin bir sözlük tanım dilidir; OWL ile sınıflar arasındaki ili kiler, önemlilik, e itlik, daha zengin özellik tipleri, özelliklerin karakteristikleri ve sıralı sınıfları tanımlanabilmektedir.

50 24

51 25 3. TÜRK YE'DE E-SA LIK Bu bölümde anlatılanların ço u Sa lık Bakanlı ının Sa lık-net için hazırlamı oldu u nternet sitesinden alınmı tır. Alıntıların nereden oldu u dipnotlarla gösterilmi tir. Daha detaylı bilgi için sagliknetiledigeresaglik.htm adresine bakılabilecektir E-Sa lık nedir? Bir e-sa lık ara tırmacısı olan Gunter Eysenbach a göre e-sa lık, nternet ve benzer teknolojilerin, hizmete ait verilerin elde edilmesi, aktarılması ve geli tirilmesi suretiyle sa lık hizmet kalitesinin geli tirilmesini sa layan ve medikal informatik, sa lık hizmetleri ve süreçlerinin kesi im kümesini olu turan önemli bir alandır. Daha geni anlamıyla ele alırsak, sadece teknik geli meyi adresleyen de il, yerel ve genel sa lık hizmetlerinin geli mesi için bilgi ve haberle me teknolojilerinin kullanılmasını gerekli gören bir dü ünce tarzı, anlayı ve kavrayı tır 1. Yukarıda tanımı verilen E-Sa lık çalı maları kapsamında Türkiye de Sa lık Bakanlı ı tarafından, ülke genelinde sa lık sektöründe görev alan tüm aktörlerin katkısıyla olu turulacak ulusal sa lık bilgi sistemi, eri im hakları tanımlanmı yetkili ki i ve kurulu larca ula ılabilir, tüm vatanda ları kapsayan, her bireyin kendi bilgilerine eri ebildi i, do um ile ba layıp tüm ya am süresince sa lıkla ilgili verilerinden olu an i levsel bir veritabanının; yüksek bant geni likli ve tüm ülkeyi kapsayan bir ileti im omurgasında payla ılması ve tele tıp uygulamalarına varan teknolojilerin mesleki pratikte kullanılmasını sa lamak amacıyla çe itli projeler gerçekle tirilmi tir 1. Sa lık Bakanlı ı tarafından yürütülmekte olan e- sa lık projeleri ekil 3.1 de gösterilmi tir. Bu projeler ilerleyen konularda ayrı ayrı ele alındı ı için burada anlatılmamı tır. 1 ktaedonusum.htm, son eri im 3 A ustos 2009

52 26 ekil 3.1 Sa lık Bakanlı ı E-Sa lık Projeleri Türkiye'de E-Devlet Dokümanlarının Birlikte lerli ini Sa lamak IEEE Sözlük tanımına göre Birlikte lerlik (interoperability) bilgi alı veri inde bulunan iki veya daha fazla sistemden, bilgiyi alan sistemin herhangi ba ka bir müdahaleye gerek kalmadan veriyi i leyebilmesidir. Di er bir deyi le, alıcı sistemin, gönderici sistemden aldı ı veri ya da servis iste ini ba ka bir müdahaleye gerek kalmadan i leyip kullanabilmesidir (IEEE, 1990). edevlet uygulamalarında birlikte çalı abilirli e bir örnek olarak HL7 v3 dayalı Sa lık-net projesi verilebilir Ulusal Sa lık Bilgi Sistemi: Sa lık-net Sa lık-net in ortaya çıkı ı Sa lıkta Dönü üm Programı nın bütün bile enleri arasında uyumun sa lanabilmesi için bütünle ik bir sa lık bilgi sistemine ihtiyaç oldu u gözlemlenmi tir. Buradan hareketle Sa lık Bakanlı ı bir e-sa lık projesi olan Sa lık-net i devreye almı tır 2. Sa lık-net, sa lık hizmetlerinde e güdüm, sa lık envanterinin olu turulması, bireylerin tıbbi kayıtlarının korunması, sevk basamakları esnasında 1 ktaedonusum.htm, son eri im 3 A ustos lsaglik.htm, son eri im 3 A ustos 2009

53 27 bilgi transferi ve temel sa lık uygulamalarındaki verilerin toplanması amacıyla ortaya çıkmı tır 1. Daha önce bu konuyla ilgili de i ik çalı malar yapılmı, tüm hastanelerin aynı uygulama üzerinden veri göndermesine dayalı yapılar, yapı çok geni oldu u için çok etkili çalı amamı tır 2. Projenin temeli, aslında Aile Hekimli i'ne dayanmaktadır. Aile Hekimli i ile beraber, da ıtık yapıda çalı an, merkezle sürekli ileti im halinde olması gereken ki iler olan Aile Hekimlerinin mevcudiyeti söz konusu olmu tur. Sadece veri payla ımı de il, hekimlerin performansını ölçüm için de ihtiyaç olan bu mekanizma için, yerel uygulamaların yanı sıra, merkezi bir uygulama ile verilerin toplanması ve payla ılması dü ünülmü tür 2. Proje, daha sonra Dünya Bankası deste i ve Avrupa Birli inin bu konudaki yönlendirmeleri ile beraber, T.C. Sa lık bakanlı ı tarafından geni letilerek önce Ulusal Sa lık Bilgi Sistemi daha sonra Sa lık-net adı altında olu turulmu tur Sa lık-net nedir? Sa lık-net, sa lık kurumlarında üretilen her türlü veriyi, do rudan üretildikleri yerden, standartlara uygun ekilde toplamayı, toplanan verilerden tüm payda lar için uygun bilgiler üreterek sa lık hizmetlerinde verim ve kaliteyi artırmayı hedefleyen, entegre, güvenli, hızlı ve geni leyebilen bir bilgi ve ileti im platformudur 3. Sa lık-net ile yapılmak istenen; vatanda ların do umdan ölüme kadar ve ölüm sonrasında sa lık verilerini merkezde güvenli bir ekilde tutmak suretiyle sa lık bilgisine eri imi kolayla tırıp hizmet kalitesini artırmaktır. Tanı, tahlil ve tetkik bilgilerinin hasta mahremiyeti çerçevesinde payla ımı ile hekimlerin ve 1 lsaglik.htm, son eri im 3 A ustos son eri im 3 A ustos son eri im 3 A ustos 2009

54 28 sa lık kurumlarının hastaya ait sa lık verilerine eri imi sa lanacak, vatanda ların hastanede daha kısa sürede daha iyi hizmet almasına imkân tanınacaktır. Sa lık- NET sistemi ile yapılacak analiz çalı maları ile koruyucu ve tedavi edici sa lık hizmetlerinin etkinli i artırılacaktır Sa lık-net in yapısı ekil 3.2 Sa lık-net in Yapısı 2 ekil 3.2 de standartların, Sa lık-net in yapısı görülebilmektedir. Veriyi üretildikleri yerden do rudan toplamayı hedefleyen projede verilerin depolanması, de i tirilmesi, güvenlik ve bilginin kurum içerisinde ve kurumlar arasında payla ılması ve farklı sistemlerin birlikte çalı masını sa layabilmek için verilerin belirlenmi standartlar do rultusunda toplanması ihtiyacı ortaya çıkmı tır. Bu yapıyı kurabilmek için yapılması gereken ilk çalı ma ise bir standartlar altyapısının olu turulmasıdır 2. Standartlara oturtulmu bir yapı veri toplama konusunda verimi artıracak, tekrarlı ve hatalı verileri azaltacak ve toplanan verinin amacına uygun kullanılması sa lanacak, sa lık hizmetlerine ili kin verinin, enformasyon ve bilgilerde tanımlama ve kavram birli i sa lanacak ve verilerin, tek düzeli i, 1 son eri im 3 A ustos lsaglik.htm, son eri im 3 A ustos 2009

55 29 bütünlü ü, do rulu u, güvenilirli i ve tutarlılı ı daha üst seviyelere çıkarılması sa layacaktır. Standardizasyon konusunda Ulusal Sa lık Veri Sözlü ü, Minimum Veri Setleri ve Sa lık Kodlama Referans Sunucusu adı altında üç bile en olu turulmasına karar verilmi tir 1. Ayrıca sa lık verilerinin toplandı ı ESK (Elektronik Sa lık Kaydı) veritabanı ve toplanan verilerin analiz amaçlı göstergelere dönü türüldü ü Karar Destek Sistemi de Sa lık-net in bile enleri arasındadır 1. ekil 3.3 de Karar Destek Sisteminin yapısı gösterilmi tir. ekil 3.3 Karar Destek Sistemi (Do aç, 2008) Bu Karar Destek Sistemi; Son bir ayda Ankara ili Polatlı ilçesinde görülen ishal vakaları? zmir ili Kar ıyaka ilçesinde son bir yılda gerçekle en ölü do umlar? Tüm Türkiye de ilçe bazında kanser vakaları? gibi sorulara cevap verebilir (Do aç, 2008). Sa lık-net portalı, Sa lık-net sisteminin dı a açılan yüzü olarak tasarlanmı tır. Portalın kullanıcıya göre dinamik içerik gösterme özelli i olup her kullanıcı, kendi yetkilerine uygun bir içerikle kar ıla maktadır. Vatanda lar, sa lık hizmet sunucuları ve sa lık bili imi sektör temsilcileri kendilerine ayrılan 1 lsaglik.htm, son eri im 3 A ustos 2009

56 30 bölümlerde sa lık ve sa lık bili imi konularıyla ilgili bilgileri ve güncel geli meleri takip edebilirler 1. Vatanda lar; portalı kullanırken, ba lı bulundu u aile hekimini görebilirler. Ayrıca ileride Elektronik Kimlik Kartı devreye alındı ı zaman portal vasıtasıyla Merkezi Hastane Randevu Sistemi üzerinden randevu alıp hastanelere gidebilecek, kendilerine ait sa lık kayıtlarını görebilecek, ba lı bulundukları Aile Hekimlerine bilgi alma amaçlı danı abileceklerdir 1. Sa lık Hizmet Sunucuları; kendi konularıyla ilgili güncel bilgi ve düzenlemeleri takip edebildikleri gibi, yetkileri çerçevesinde portaldaki uygulamalar vasıtasıyla veri bildirimi yapabilirler, kendileri için hazırlanmı olan sa lık rapor ve detay istatistiklerine ula abilirler 1. Sa lık Sektörü Temsilcileri; sa lık bili imi alanında ortaya çıkan standartları takip edebilirler, Hastane Bilgi Sistemi yazılımları, Aile Hekimli i Bilgi Sistemi yazılımları, bu yazılımların gerektirdi i donanım ve mesajla ma standartları, veri güvenli i ve mahremiyeti vb. konularda son geli meleri ve sektörün uyması gereken normlar hakkında bilgi sahibi olabilirler 1. Sa lık-net in ana hatları öyledir 2 : Web teknolojisine dayalı, aile hekimli i, hastane ve di er bile enlerin ba ımsız yazılımlarından standart veri transferi yapabilen altyapı, Karar mekanizmasında rol alacak, hastalık yüküne ve sa lık harcamalarına, epidemiyolojik ve demografik analizlere yönelik yeterli ve gerekli bilgiye merkezden ula ılabilme olana ı sa layan Karar Destek Sistemi, Ülke düzeyinde sa lıkla ilgili verilerin toplanması ve sa lık hizmeti sunumunda elde edilen veriler do rultusunda hizmet planlanması yapılabilmesi için bilgi ve ileti im teknolojilerinin sa ladı ı olanakları kullanarak veri toplanması, toplanan bu verilerin kurumsal bir yapı 1 son eri im 3 A ustos lsaglik.htm, son eri im 3 A ustos 2009

57 31 dâhilinde de erlendirilmesi ve aksayan noktalarda sorun gidermeye yönelik geri bildirim mekanizması, Uluslar arası kurumlar (WHO, EUROSTAT, OECD) tarafından istenen göstergelerin takip edilmesini sa layacak raporlama sistemati i, Ulusal Sürveyans sistemini destekleyecek uygulamalar ile sa lıkla ilgili olaylarda erken uyarı sistemleriyle entegrasyon, Elektronik kimlik kartının kullanıma ba lamasıyla birlikte nternet üzerinden vatanda ın kendi sa lık kayıtlarına eri im imkanı, Sa lık-net için gerekli standartlar Ulusal Sa lık Veri Sözlü ü (USVS) Günümüz dünyasında her alanda bilginin öneminin giderek artması, bilgiyi do ru bir ekilde elde etme konusundaki ihtiyacı artırmı ve bu ihtiyacı kar ılamak üzere önemli çalı malar yapılmaya ba lanmı tır. Özellikle sa lık bili imi alanında pek çok uluslararası standardın geli tirildi i görülmektedir. Bu standartlar; verinin tanımlanması, aktarılması, saklanması, mahremiyetinin korunması ve analiz edilmesi a amalarında nasıl bir yöntem izlenece i konusunda kurallar getirmektedirler 1. Ülkemizdeki duruma bakıldı ında; sa lık alanında politika üretmek için hayati öneme sahip verilerin toplanmasında, saklanmasında ve analiz edilmesinde ulusal veya uluslararası standartların olmadı ı, özellikle veri toplama konusunda ciddi bir karma anın mevcut oldu u görülmü tür ve karar sürecinde etkili bilgiye eri im için ön art olan veri standartlarının belirlenmesi amacıyla, Ulusal Sa lık Veri Sözlü ü (USVS) hazırlanmı tır 1. Sözlük, farklı kategorilerde veri kümelerinin oldu u hiyerar ik terim ve nesneler toplulukları (Ontoloji ve "Ontoloji"ler) ve bu terimler arası ili kilerden olu maktadır. Bununla birlikte USVS, bir veri sözlü ü niteli i ta ımayan; ancak SKRS (Sa lık Kodlama Referans Sunucusu) bünyesinde yer alacak ve yine ülke çapında referans olarak kullanılacak olan kodlama ve sınıflandırma sistemlerinin tanımlarını da barındırmaktadır son eri im 3 A ustos 2009

58 32 Veri sözlü ü, sa lık kurumlarından verilerin belirlenmi standartlar do rultusunda toplanmasını, analizini ve de erlendirilmesini sa lamaktadır. Aynı zamanda, sahadan sa lık verisi toplama konusunda verimi arttırmakta, tekrarlanan ve hatalı verileri azaltmakta ve toplanan verinin amacına daha uygun bir ekilde kullanılmasına imkân tanımaktadır 1. Ulusal Sa lık Veri Sözlü ü, 10 ayrı küme ba lı ında toparlanabilecek tam 261 adet veri elemanından meydana gelmektedir. Her bir veri elemanı bir veya birden fazla veri seti içerisinde yer almaktadır. Mevcut sürümde 261 veri elemanı toplam 46 veri seti içerisinde yer almaktadır 2. Bu veri elemanlarının olu turdu u küme ve onlardan bazıları ekil 3.4 de görülebilmektedir. ekil 3.4 Ulusal Sa lık Veri Sözlü ü Veri Elemanları 2 Sözlük içerisinde veri elemanının tanımı yapılırken; mantıksal açıklamalar ve teknik açıklamalar bir arada yapılmaktadır. Mantıksal açıklamalar, veri elemanının kavramsal olarak ne anlama geldi ini ifade ederken; teknik açıklamalar, bilgi sistemlerinde veri elemanı tanımlanırken hangi özelliklere sahip olması gerekti i ifade edilmektedir son eri im 3 A ustos igi.htm, son eri im 3 A ustos 2009

59 Minimum Sa lık Veri Setleri (MSVS) Minimum Veri Setleri (MVS), Sa lık Bakanlı ının sahadan toplayaca ı minimum içeri e sahip veri gruplarını ifade etmektedir. MVS ile; imdiye kadar kâ ıt ortamda toplanan veriler, geli en haberle me ve bili im teknolojisi altyapısını kullanarak daha hızlı ve do ru bir ekilde do rudan verinin üretildi i bilgi sisteminden elektronik ortamda Sa lık Bakanlı ına iletilebilmektedir 1. Sa lık Kurumları, veri setleri içerisinde yer alan veri elemanlarını kullandıkları bilgi sistemleri aracılı ıyla veya Sa lık-net portalı üzerindeki veri seti bildirim ekranları aracılı ıyla Sa lık Bakanlı ına iletmektedirler. ekil 3.5 de Hasta Kabul Veri Seti örne i görülmektedir. Bu veri seti içerisinde 8 adet veri elemanı yer almakta olup, bu veri elemanlarının veri seti içerisindeki zorunluluk durumları, birden fazla tekrar etme gibi özellikleri Ulusal Sa lık Veri Sözlü ü, Minimum Sa lık Veri Setleri ba lı ı içerisinde tanımlanmı tır 1. ekil 3.5 Hasta Kabul Veri Seti Sa lık Kodlama Referans Sunucusu (SKRS) Sa lık Kodlama Referans Sunucusu (SKRS) ile, Türkiye sa lık sisteminin izlenebilir, ölçülebilir ve daha kolay yönetilebilir bir yapıya kavu turulması için 1 dir.htm, son eri im 3 A ustos 2009

60 34 ihtiyaç duyulan, Sa lık Bilgi Sistemi standartlarının mevcutları bir araya getirilmektedir 1. SKRS nin kapsadı ı sistemler 1 : Tanı Sınıflama Sistemi (International Classification of Diseases-ICD 10, International Classification of Primary Care Second Edition-ICPC2) laç ve laç Sınıfları Kodlama Sistemi (Anatomical Therapeutic and Chemical-ATC) Sa lık Uygulama Tebli i (SUT) Kodları Bran Kodları... Sa lık Kurumlarının vermi oldukları hizmetlerin E-sa lık projesi kapsamında sisteme kaydedilebilmesi için Sa lık Kodlama Referans Sunucusundaki ilgili cevap de erlerini belirleyerek bu kodların Sa lık-net e veri gönderilirken kullanılmasını sa lamaları gerekmektedir 1. Sa lık Kodlama Referans Sunucusu (SKRS) ve Ulusal Sa lık Veri Sözlü ü (USVS) ili kisi Ulusal Sa lık Veri Sözlü ünde, tanımlanan her bir veri elemanının veri kapsamında bir kodlama veya sınıflamaya ihtiyacı varsa, bu kodlar veri elemanı tanımında yer alan SKRS Sistem Kodu de eri kullanılarak SKRS den sorgulanmak suretiyle elde edilebilir 1. Örne in, Kabul ekli veri elemanı için SKRS Sistem Kodu, 0cda417a-8e35-44e7-ae1e-6b38f43d0168 olarak tanımlanmı tır. Bu SKRS Sistem Kodunu kullanarak SKRS web servislerinden, Kabul ekli ne ait veri kapsam alanı de erleri alınabilmektedir. Hastaneler, SKRS web servislerinden Kabul ekli veri elemanının alabilece i de erleri ö rendikten sonra Sa lık-net e veri gönderirken bu de erlerden birini kullanırlar. Gönderilen veri yalnızca SKRS de tanımlanan de erlerden biri olabilir. Kabul ekli için verilen örnek geni letilirse, hastanelerin gönderebilecekleri de erler; kurum dı ından sevkli gelen bir hasta için 1, kurum içinden sevkli kabul edilen bir hasta için 2 ve bunlara uymuyorsa (di er) 8 olabilmektedir. 1 son eri im 3 A ustos 2009

61 Teknik standartlar Health Level Seven (HL7 1 ) Bili im Teknolojilerinin sa lık alanında kullanılmaya ba laması ile birlikte sa lık organizasyonları yazılım irketlerinden kendi ihtiyaçlarına göre yazılım almaya ba ladılar. Bu durumda ya anan en büyük sıkıntı hali hazırda kullanılan yazılımın yeni alınan yazılım ile entegrasyonu idi. lk a amada getirilen çözüm sadece iki sistemi entegre etmeye yönelik özel bir çözümdü ve ileride ba ka sistemler alınaca ı dü ünülürse alınan her sistem için harcanan efor katlanarak artıyordu. Bu sorunu çözme amaçlı olarak, HL7 konsorsiyumu kurulmu tur (T.C. Sa lık Bakanlı ı B DB, 2008). Health Level Seven (HL7), Amerikan Ulusal Standartlar Enstitüsü (American National Standards Institute-ANSI) tarafından akredite edilmi, sa lık bili imi alanında standart geli tiren bir organizasyondur (Standards Developing Organization-SDO). Temel olarak sa lık bilgilerinin elektronik olarak ileti imini sa layan mesajla ma standartlarını üretir. HL7 ismi Açık Sistem Ba lantı Modeli ndeki (Open System Interconnection-OSI) en üst seviye olan Uygulama Seviyesi nden (Application Level) gelmektedir. Uygulama seviyesi, ileti imi yapılacak verinin tanımı, veri alı veri inin zamanlaması ve belirli hataların uygulamaya tanıtılmasını sa lar (Tıp Bili imi Derne i, 2006). HL7 çalı malarına 1987 yılında ba lamı olup yılları arasında v2.1 i çıkarmı tır. lk ba larda bu standardın amacı klinik veriden çok Hasta Özlük, Hasta Hesap gibi yönetimsel veri standartları üzerineydi. Daha sonra 1994 yılında sürüm 2.2, 1997 yılında sürüm 2.3, ve 2003 yılında ise sürüm 2.5 çıkarılmı tır. Her yeni sürümde genel olarak HL7 ın kapsama alanı geni letilmi tir li yılların sonuna do ru HL7 organizasyonu bu sürümdeki sıkıntıları görerek, v2.x standartlarını iyile tirmek yerine, sil ba tan yeni XML ve Nesne Tabanlı bir standardın ilk adımlarını atmaya ba ladı ve bu standardı Sürüm 3 olarak isimlendirilmi tir. HL7 v2.x teki temel sorunlar dört ana ba lık altında incelenebilir (T.C. Sa lık Bakanlı ı B DB, 2008): 1 son eri im 3 A ustos 2009

62 36 1. leti uyumsuzlu u: HL7 iletilerini geli tiren HL7 Teknik Komiteleri, iletileri geli tirirken kuralları belli olan formal bir metodoloji kullanmamaktadır. Her komite kendine göre ad hoc olarak nitelendirilen bir süreç ile ileti tanımı üretmektedir. Bu durum komiteler arası tekrar kullanımı oldukça azaltmı ve aynı bilgi (information) için farklı veri formatlarının (data format) üretilmesine yol açmı tır. Böylece HL7 ın kendi komiteleri aralarında uyumsuz olan iletiler üretmi lerdir. 2. Opsiyonellik Sorunu: HL7 v2.x te tüm uygulamaların bilgi ihtiyacını kar ılamak ve herkesin uyumlulu unu kolayla tırmak amacıyla, ileti tanımlarında ço u dilimi ve bu dilimlerdeki veri alanlarını seçimli (opsiyonel) olarak tanımlamı tır. Ayrıca uygulamacıların kendi ihtiyaçlarına göre kendi dilimlerini Z kodu kullanarak yaratmalarına izin vermektedir. Bu durum belli bir süre sonra iki HL7 uyumlu oldu unu söyleyen yazılımın farklı veri modellerine sahip olmalarına ve dolayısıyla birbirleri ile ba arılı ileti alı veri inde bulunamamalarına yol açmı tır. Bu sebeple ki iler HL7 ı standart olarak sorgulamaya ba lamı tır. 3. Uyumluluk Beyanı: HL7 v2.x te uygulamaların HL7 a nasıl ve ne kadar uyduklarını söyleyebilecekleri bir mekanizma bulunmamaktadır. HL7 v2.x e uyumlu olmak için u sayıda ileti mutlaka sa lanmalıdır diye bir kural yoktur. Bu durum sadece bir-iki iletiyi uygulayan yazılımların bile HL7 a uyumlu olduklarını iddia etmelerine yol açmı tır. Bu sebeple literatürde HL7-vari (HL7-ish) gibisinden kavramlar ortaya çıkmı tır. Bu sebeple yine iki HL7 uyumlu oldu unu söyleyen yazılım konu amamaya ba lamı tır. 4. Bilgisayar ın i leyebilece i bir ema nın bulunmayı ı: HL7 v2.x iletileri yukarıda da belirtildi i üzere Soyut leti Sözdizimleri kullanılarak tanımlanmı tır. Bir uygulayıcı, uyumlu ileti üretmek için standardın bulundu u yüzlerce sayfalık dokümanı okuyup tek tek her bir veri alanını kontrol etmek zorunda kalmaktadır. Bu durum uygulamacılara büyük sorunlar çıkarmaktadır. ekil 3.6 da Sa lık-net i kullanan kurumlar, yani Sa lık-net in payda ları gösterilmi tir. Bu kurumların tıbbi bilgi sistemleri Sa lık-net e bilgileri HL7 v3 formatında Web Servis Teknolojileri kullanarak gönderirler. Bu amaçla Sa lık-net sistemi tıbbi bilgi sistemi istemcilerine Web Servis arayüzleri (Sa lık-net Web Servisleri) açmı tır.

63 37 ekil 3.6 Sa lık-net i Kullanan Kurumlar (Do aç, 2008) HL7 v3 uyumlu 25 ve di er 16 olmak üzere toplam 41 Web servisi ile sahadan Elektronik Hasta Bilgisi toplanmaktadır (Do aç, 2008). Sa lık-net içerisindeki tanımlanan, HL7 v3 uyumlu Web servislerinden bazıları a a ıda listelenmi tir (Do aç, 2008): Muayene Yatan Hasta Hasta Kayıt Hasta Özlük Bilgileri Vatansız Kayıt Tetkik Sonucu Do um Bildirimi Ölüm Bildirimi... Sa lık-net le birlikte; sahadan verilerin HL7 v3 ileti yapısına uygun olarak Sa lık Bakanlı ı sunucularına gönderilmesi sa lanmı tır. ekil 3.7 de bu gönderim basit ekilde gösterilmi tir. Bu verilerin karar destek sistemlerince i lenerek etkin bilgiye dönü türülmesi ve Aile Hekimlerinin hastaların eski sa lık kayıtlarına ula abilmesi sa lanmı tır. lerleyen a amalarında hasta sa lık kayıtlarının ülkedeki sa lık kurumları arasında ve di er ülkelerle payla ımı dü ünülmektedir (Do aç, 2008).

64 38 ekil 3.7 Sa lık-net le leti im (Do aç, 2008) Sa lık-net e yardımcı uygulamalar Test Bed Test Bed 1, uzak saha uygulamalarının Sa lık-net e entegrasyonu çalı malarında kullanmak üzere hazırlanmı bir uygulamadır. Henüz Sa lık-net web servislerine adapte olamamı uzak saha uygulamaları ile bu uygulamaların Sa lık-net web servislerine entegrasyon sürecinde kar ıla tıkları hataları görebilmesi ve hazırlamı oldukları iletileri üçüncü parti yazılım kullanımına ihtiyaç duymadan test edebilmeleri amacıyla kullanıma sunulmu tur. ekil 3.8 de Test Bed uygulama arayüzü gösterilmi tir. 1 uzu.pdf, son eri im 3 A ustos 2009

65 39 ekil.3.8 Test Bed Uygulaması Arayüzü 1 Test Bed aracılı ıyla 1 ; Hastaneler hazırlamı oldukları iletileri göndererek format kontrolünden geçirebilirler, Göndermi oldukları iletinin merkez servislerde i lenmesinden sonra da, do rulama ve i kurallarından ne cevap döndü ünü görebilirler TestBATN (Testing Business, Application, Transport and Network Layers) Bu bölümde anlatılanlar SRDC yazılım irketinin nternet sitesinden alınmı tır. Alıntıların nereden oldu u dipnotlarla gösterilmi tir. Daha detaylı bilgi için g=tr adresine bakılabilecektir. Belirli standartlara uydu unu iddia eden uygulamaların, Uygunluk ve Birlikte lerlik gereksinimlerinin test edilmesi, elektronik ortamda i (E- ) yapan organizasyonlar arasındaki bilgi alı -veri inin sa lıklı olması açısından büyük önem arz etmektedir. E- uygulamaları arasındaki ileti imin do rulu u ancak test 1 uzu.pdf, son eri im 3 A ustos 2009

66 40 etme yoluyla garanti edilebilir ve ürünler ancak test edilerek bir sertifikaya ba lanabilirler 1. ekil 3.9 TestBATN Arayüzü 1 TestBATN, uygulamaların tanım kümelerinden ve kullanılan standartlardan ba ımsız olarak çalı ır. ekil 3.9 da TestBATN ın Grafiksel Kullanıcı Arayüzü gösterilmi tir. Grafik Kullanıcı Arayüzü ile çalı tırılacak olan test senaryosunu ve test edilecek olan sistemin ve standartların özelliklerini TestBATN 'a yüklemek yeterlidir 1. TestBATN mimarisinin basit bir gösterimi ekil 3.10 da verilmi tir. Örne in TestBATN, HL7 v3 ve Web Servis tabanlı Ulusal Sa lık Bilgi Sistemi (USBS) kapsamında geli tirilen yazılımların uygunluk ve birlikte i lerlik gereksinimlerinin test edilmesinde kullanılmaktadır. TestBATN, birlikte i lerlik katmanlarının tümünü test etme kabiliyetine sahiptir. Bu katmanlar; Haberle me Katmanı (Communication Layer), Doküman çerik Katmanı (Document Content Layer) ve Süreci Katmanı (Business Process Layer) olarak sıralanabilir son eri im 3 A ustos 2009

67 41 ekil 3.10 TestBATN Mimarisinin Basit Gösterimi 1 Uygunluk ve Birlikte lerlik testleri; uygulamaların belirtilen standartlara uyup uymadı ını, bu uygulamaların, standartlara uygun di er sistemlerle birlikte çalı ıp çalı amadı ını kontrol eder. TestBATN, bu ihtiyacı kar ılayan otomatik ve farklı hizmet alanlarına uyarlanabilir bir yapı sunar 1. TestBATN sistemi a a ıdaki özelliklere sahiptir 1 : Birlikte i lerlik katmanlarının farklı bölümlerini simüle edebilen, yüksek düzeyli test yapıları içeren bir Test Çalı tırma Modeli. Bu model, de i ik standartlara dayalı senaryoların, e de er test senaryolarının yazılmasını ve de i ik katmanları test edecek adaptörlerin dinamik olarak entegre edilmesini olanaklı kılar. Dinamik test senaryolarının yaratılmasını sa layan, hem insan-okuyabilir hem de makine-i leyebilir bir Test Tanımlama Dili. Test Tanımlama Dili, 1 son eri im 3 A ustos 2009

68 42 halihazırda yazılmı ve statik test senaryolarına nazaran dinamik olarak test senaryoları yaratmayı, de i tirmeyi, yönetmeyi ve geli tirmeyi olanaklı kılar. Birlikte i lerlik katmanlarının hepsini otomatikle tirerek test edebilme yetisi. Test i leyi inin bir kısmını otomatikle tirmek, yani birlikte i lerlik katmanlarının bazıları için test araçları sa layarak kalanını kullanıcıya bırakmak kullanıcı yükünü artırarak hatalara ve zaman kaybına yol açar. TestBATN sistemi bu sorunları ortadan kaldıran bir tasarıma sahiptir. TestBATN sistemi, katılımcılar için maliyeti dü ük tutma çabası içindedir. Sa ladı ı Grafik Kullanıcı Arayüzü ile test tasarımcılarının, uygunluk ve birlikte i lerlik testleri için, tekrar kullanılabilir test yapısı parçacıkları olu turmalarına olanak sa lar. TestBATN Web teknolojileri kullanılarak geli tirilmi olup Web üzerinden hizmet vermektedir. nternet ça ında, birlikte i lerlik testleri zaman ve yer kısıtı olmaksızın gerçekle tirilebilmelidir. Uygulama geli tiriciler, ürünlerini, Web üzerinden, her an, nternet eri imi olan herhangi bir yerden test edebilmelidirler Di er E-Sa lık Projeleri Tele-Tıp Teletıp Projesi, tıbbi görüntüleme alanında yeterli uzmanın olmaması, kompleks vakalarda ikinci görü olarak konsultasyon ihtiyacının giderilmesi, hasta memnuniyetinin artırılması ve do ru te his ve tedavi i lemlerinin uygulanması amacıyla geli tirilmi tir 1. Tıp alanındaki görüntüleme teknolojilerinin geli imi ve çe itlenmesi, tedavi kurumlarındaki i süreçlerinin önemli bir bölümünü olu turan tıbbi görüntülerin ar ivlenmesi ve kullanılmak üzere ar ivden geri ça rılmasından do an gereksinim nedeniyle bu i lemlerin de elektronik ortama ta ınmaya ba laması standardizasyon, maliyet gibi birçok amaçla bu alanda bir düzenleme yapılması zorunlulu u do urmaktadır son eri im 3 A ustos 2009

69 43 Proje, ilk etapta Radyoloji ve Patoloji alanındaki Sa lık hizmeti sunumunun, Sa lık-net omurgası üzerinden ikinci ve üçüncü basamak sa lık kurumları arasında uzaktan verilmesi, uzman sayısının yeterli olmadı ı hastanelerde veya konsültasyon hizmetinin alınması gerekti i kompleks vakalarda önemli bir eksikli i gidermektedir. Uzaktan yapılacak te his ve raporlamalar birinci veya ikinci görü olarak kayda girilmektedir 1. Teletıp Projesi kapsamında yakın zamanda kronik hasta takibi ve ya lı bakımı için imkanlar sunmaya ba lanması planlanmı tır 1. Bakanlık Bilgi lem Dairesinde Teletıp ile ilgili tüm operasyonların yönetildi i bir Teletıp Merkezi kurulmu tur. Teletıp kapsamında yer alan gönderici hastaneler radyoloji ve patoloji görüntülerini önce teletıp merkezine iletmektedir. Teletıp merkezinde gerekli yönlendirmeler yapılarak alıcı hastanelerin ilgili görüntüleri raporlaması sa lanmaktadır. Teletıp hizmetleri ile ilgili gerçekle tirilen tüm i lemler Teletıp Merkezinde raporlanmaktadır 1. Teletıp Projesinde yer alan hastanelerden bazıları a a ıda verilmi tir. 1 Gönderici Hastaneler: Amasya Sabuncuo lu erefettin Devlet Hastanesi Elazı Devlet Hastanesi Hatay Antakya Devlet Hastanesi Kayseri E itim Ve Ara tırma Hastanesi... Alıcı Hastaneler: Ankara Dr. Sami Ulus Çocuk Sa. E itim Ve Ara tırma Hastanesi Ankara Atatürk E itim Ve Ara tırma Hastanesi Ankara Dı kapı E itim Ve Ara tırma Hastanesi Ankara Numune E itim Ve Ara tırma Hastanesi Ankara E itim Ve Ara tırma Hastanesi 1 son eri im 3 A ustos 2009

70 Merkezi Hastane Randevu Sistemi (MHRS) Merkezi Hastane Randevu Sistemi temelde, vatanda ların merkezi bir sistemden randevu alarak istedikleri herhangi bir hastaneye gitmelerini sa lamayı hedeflemi tir. Proje vatanda memnuniyetinin artırılması ve hastanelerde sa lık hizmet verim ve kalitesinin artırılması amacıyla ortaya çıkmı tır Randevu sistemine ihtiyaç var mı? Randevu sistemleri, hem hastaların hem de sa lık personelinin zaman yönetimine yardımcı olmalarının yanı sıra hizmet kalitesini ve hasta memnuniyetini artırmaları nedeniyle modern sa lık hizmetinde önemli bir yere sahiptir. Ancak, randevu sistemlerinin uygulamalarına baktı ımızda, telefon, nternet, kısa mesaj, kiosk gibi teknolojik imkânların kullanıldı ı çok çe itli örnekler görülmektedir 1. Ancak bu uygulamalar, birden çok hastaneyi entegre eden uygulamalar de il sadece bir hastanede uygulanan sistemlerdir. Kimi örneklerde sadece SMS (Short Message Service) kullanılıyorken, kimilerinde nternet ve Kiosk da bir eri im kanalı olarak yer almaktadır. Nadiren daha pahalı bir yöntem olan bir ça rı merkezi üzerinden randevu uygulaması yapan hastaneler görmek de mümkündür 1. Bazı hastanelerde hala kuyruklara rastlamak da mümkün olabilmektedir. Bütün bunlar dikkate alındı ında, merkezi randevu sistemlerinin bir ihtiyaç oldu u görülmü tür Nasıl bir sistem tasarlanıyor? Merkezi Hastane Randevu Sistemi, tüm devlet hastanelerinin ba lı oldu u bir sistem olacaktır. Hastaneler, doktorların çalı ma cetvellerini düzenli bir ekilde merkezi bir sisteme aktaracaklardır (kaynaklar), ça rı merkezini arayan vatanda lar da (kaynakları kullanacak kullanıcılar) bu çalı ma cetveline göre bo olan saatler için randevu alabileceklerdir. Bu sistem ile hastanelerin çalı ma sürelerinin %75 i için randevuya açık olacaktır. Kalan %25 lik süre, kontrol muayeneleri ve tetkik sonuçlarının de erlendirilmesi için ayrılacaktır. Bu oranlar, sistemin i leyi i gözlemlenerek gerekti inde de i tirilebilecektir. Çalı ma 1 mi.htm,son eri im 3 A ustos 2009

71 45 cetvelleri, her hastane için aynı olmayacak; ancak tamamen hastanelerin tasarruflarına da bırakılmayacaktır. Poliklinik i lemlerinin yo unlu unun gün içinde homojen da ılmamasının da önüne geçilmesi hedeflenmi tir 1. Vatanda ların randevu sistemine eri imi, ba langıçta sadece ça rı merkezleri, yani operatörler üzerinden olacaktır. Ça rı merkezlerine, Bakanlı ın üç haneli sabit hattı ile eri ilecektir. Ancak bu hat, Bakanlı ın halen kullanılmakta olan 184 SAB M den (Sa lık Bakanlı ı leti im Merkezi) farklı olacaktır. Operatörler, özellikle sa lık meslek liseleri mezunlarından seçilecek ve özel bir e itime tabi tutulacaklardır. Her ne kadar tıbbi bir yönlendirme hizmeti vermeleri mümkün olmasa da, vatanda ların en azından yanlı poliklini e gitme oranlarının dü ürülmesinde katkılarının olaca ı dü ünülmü tür. SMS, nternet ve kiosk gibi eri im kanalları, sistemin suistimal edilmesi endi esi nedeniyle ba langıçta kullanıma açılmayacaktır. Elektronik kimlik kartı ile birlikte, vatanda lar do rudan nternet üzerinden kendileri de randevu alabileceklerdir 1. Vatanda lar ba ka bölgedeki hastanelerden randevu alabileceklerdir. Aile Hekimleri sisteme dahil olacak ve hastaları için nternet üzerinden randevu alabilecek, bu sayede sevk zinciri Elektronik Sevk Sistemi ile hayata geçirilecektir. Sistemin yapısı ekil 3.11 de gösterilmi tir. ekil 3.11 MHRS in Yapısı (Arslan, 2008) 1 m.htm, son eri im 3 A ustos 2009

72 MHRS in Uygulamaya geçi i Önceleri tek bir ilde pilot uygulamanın ardından dört bölgede yaygınla tırma planlanıyorken, daha sonra hem pilot hem de yaygınla tırmanın dört bölgede aynı anda ba lanmasına karar verilmi tir. Bölgeler, nüfus yo unlu u, poliklinik sayıları ve hastanelerin yönetimsel bölgeleri dikkate alınarak belirlenmi tir. Bölge merkezleri ekil 3.12 de gösterildi i gibi stanbul, Ankara, zmir ve Erzurum olarak belirlenmi tir. Pilot uygulamanın, bölgelerin merkez illerinde ba laması (sadece stanbul bölgesinde pilot uygulamanın Kocaeli nde yapılması planlanmı tır) ve en az 6 ay sürmesi planlanmı tır. Ardından yaygınla tırma dönemin ba laması ve 12 ay içerisinde tüm Türkiye de sistemin devreye alınması tasarlanmı tır 1. ekil 3.12 MHRS çin Ayrılan 4 Bölge Di er ülkelerdeki uygulamalar Randevu sistemi deyince, akla ilk gelen ülkeler aile hekimli ini ba arı ile uygulayan ve dolayısıyla sevk zincirini hayata geçirmi olan ülkelerdir. Ancak genel anlamda randevu uygulamalarının tüm ülkede ve tüm alanlarda ba arılı bir ekilde uygulandı ı örnek neredeyse yok denecek kadar azdır. Kimi örneklerde eyalet veya il bazında uygulanırken, kimilerinde sadece belirli bran lar veya 1 htm son eri im 3 A ustos 2009

73 47 operasyonlar için randevu uygulaması yapılıyor. En geni uygulamalardan biri ngiltere de kullanılmaktadır 1. Sistem kısaca Seç ve Rezerve Et (Choose and Book) adıyla anılıyor. Aile Hekimleri tarafından sevk edilen hastaların elektronik ortamda kendi istedikleri yer, zaman ve tarihte hastane ve klinik randevuları alabilmelerini sa lıyor. ngiltere de Ulusal Sa lık Hizmetleri nin (National Health Service-NHS) modernize edilmesi projesinin bir parçası olarak görülen sistemin, hastaların seçimleri, hizmete eri im, hastane kuyruklarının ve bilgi teknolojileri yatırımlarının azaltılması konularında iyile tirmeleri de beraberinde getirmesi hedeflenmi tir yılında ihale edilen ve tanıtım faaliyetleri 2004 yılında gerçekle tirilen sistem 2005 yılından itibaren devreye alınmaya ba lanmı tır Elektronik Sevk Sistemi Elektronik Sevk Sistemi, Merkezi Hastane Randevu Sisteminin tam olarak devreye alınmasıyla birlikte devreye alınacaktır. Sistem büyük oranda MHRS ve Sa lık-net altyapısını kullanacaktır. öyle ki; bir hastane hastasını ba ka bir sa lık kurumuna sevk edece i zaman, hastanın da bilgisi dahilinde Merkezi Hastane Randevu Sistemi üzerinden ilgili sa lık kurumundan hastası için randevu alacak ve hastanın sa lık kayıtlarını Sa lık-net vasıtasıyla ilgili hastaneye gönderecektir E-Reçete E-reçete, ka ıt ortamına aktarılması zorunlu olmadan elektronik ortamda saklanabilen ve yine elektronik ortamda bir yerden bir yere aktarılabilen bir çe it reçetedir. Halen kullanılmakta olan ka ıt reçeteye göre; nsan kaynaklı hataların minimuma indirilmesi; Zamandan tasarruf; Sürekli güncellenebilme ve geli tirilebilme imkânı; Hızlı ve yinelenebilir hizmet, Hasta takibi ve Gereksiz ilaç kullanımının kontrol altına alınarak sa lık giderlerinin azaltılması vb. gibi bir çok avantajı vardır. Ayrıca mevcut uygulamada bir hastanın bilgilerini ö renen bir 1 htm son eri im 3 A ustos esaglik.htm son eri im 3 A ustos 2009

74 48 sa lık kurulu u veya doktor o ki iye, ki inin haberi olmadan bir reçete yazabilmektedir. E-reçete nin Elektronik kimlik kartı ile beraber kullanılmasının sa layaca ı ek bir avantaj olarak, Elektronik kimlik kartı ile birlikte E-Reçetenin kullanılması bu usulsüzlü ü ortadan kaldıracaktır Elektronik Kimlik Kartı Türkiye Cumhuriyeti vatanda larının kullandıkları nüfus cüzdanlarının birkaç yıl içinde elektronik kimlik kartları ile de i tirilmesi planlanmaktadır. Bu kartlarda parmak izi tanıma özelli i olacaktır. 70 Milyon kimlik kartının elektronik kimlik kartları ile de i tirilmesi bir anda gerçekle tirilmesi durumunda, önceden görülemeyen sorunlar ortaya çıkabilece inden, bu i lem için önce pilot uygulamalar yapılması öngörülmü tür. lk olarak Bolu ilinde bir pilot uygulama yapılacaktır. Bu pilot uygulama sırasında çok sınırlı bir sayıda vatanda ın kimlik kartları Elektronik Kimlik Kartı ile de i tirilecektir. Projenin ilerleyen a amalarında, her vatanda, Elektronik kimlik kartını kullanarak Sa lık-net portalına giri yapabilecek ve kendisiyle ilgili uygulamaları kullanabilecektir 1. Gelecekte elektronik kimlik kartının birçok e-devlet uygulamasında kullanılması planlanmaktadır. E-devlet uygulamaları açısından bu kartı ilk olarak Sa lık Bakanlı ı ve Sosyal Güvenlik Kurumunun kullanması öngörülmü tür 1. Elektronik Kimlik kartı, kamu hizmetlerinin elektronik ortamda güvenli ve güvenilir altyapılar üzerinde vatanda odaklı ve kaliteli olarak sunulmasını sa layacak, vatanda ın günlük ya amdaki i ve i lemlerini kolayla tıracak ve hızlandıracaktır. Aynı zamanda, hizmet sunumunda vatanda ların kimli inin geleneksel yöntemler ile do ru olarak saptanamamasının getirdi i usulsüzlükler de önlenecektir 1. Yeni kimlik kart sahibi vatanda lar sa lık hizmeti verilen tüm kurum ve kurulu larda kimliklerini do rulattıktan sonra sa lık hizmetlerini alabileceklerdir. Aynı ekilde elektronik ortamda yazılan ve sa lık personeli tarafından elektronik imzalanmı olan e-reçete ve e-raporlarını yazdırıp ilaçlarını eczanelerden herhangi bir belge ta ımaya gerek kalmadan alabilecektir esaglik.htm, son eri im 3 A ustos 2009

75 49 Elektronik kimlik kartlarındaki parmak izi okuyucusuyla entegre çalı ma özelli i birçok usulsüzlü ü ortadan kaldıracaktır. Bu kimlik kartının yaygınla ması ile birlikte, her Türk vatanda ının Sa lık-net portalına giri yapıp kendisi ile ilgili mahrem bilgileri de içeren uygulamalar çalı tırabilmesi mümkün hale gelecektir. Elektronik kimlik kartı yaygın olarak kullanılmaya ba landı ında, herhangi bir vatanda ın a a ıdaki i lemleri yapabilmesi planlanmı tır 1 : Kendisi ile ilgili elektronik sa lık kayıtlarına bakabilece i uygulama, Muayene randevusu almasını sa layan uygulama Tele Konsültasyon, aile hekimini de i tirme i lemi 1 esaglik.htm, son eri im 3 A ustos 2009

76 50

77 51 4. SOYUT S STEM M MAR S Türkiye de u anda kullanılan ve bir önceki bölümde tanıtılan Sa lık-net sisteminin temel amaçları arasında, tüm hastaneler arasında ortak bir terminoloji olu turmak ve böylece bilgi payla ımını sa lamak gösterilebilir. Heterojen veri kaynaklarındaki bilginin birle tirilmesi birlikte i lerlik (interoperability) olarak adlandırılır. Bilginin birlikte i lerlik problemi, verilerin farklı formatlarda veya farklı anlamlarda sunulmasından kaynaklanmaktadır. Bu problemi çözmek amacıyla Sa lık-net e sadece HL7 formatında veri gönderilebilmektedir. Böylece gönderilen veri tüm sa lık kurumlarında aynı anlama gelmektedir. Hastaya konulan tanılar, radyoloji ve laboratuvar sonuçları, hastaya uygulanan tetkikler, yapılan ameliyatlar, hastaya kullanılan ilaç ve sarf malzemeler Sa lık- NET sistemine kaydedilen bilgilerden bazılarıdır. Sa lık-net sistemi hasta verilerinin; sa lık kurumları tarafından kaydedilmesine, gönderen kurum tarafından güncelenmesine veya silinmesine izin vermektedir. Sa lık-net sistemi içerisinde tutulan verilere, sadece gönderen kurum eri ebilmektedir. Tez projesi kapsamında olu turulan projelerden biri olan MedicalNet isimli sistem, Sa lık-net teki verilere eri ebildi i dü ünülerek tasarlanmı tır. Fakat u a amada, Sa lık-net verilerine eri emedi i için yerel veritabanındaki verileri kullanmaktadır. Bu veriler Sa lık-net sistemi gibi, HL7 formatında kaydedilmi tir. Sistem geli tirilirken ilerde Sa lık-net üzerinden, hastanın T.C kimlik numarası kullanılarak herhangi bir hastaneye yaptı ı tüm geli lerinin ve bu geli lerine ili kin tüm verilerinin sorgulanabilece i dü ünülmü tür. Ayrıca bu sistemde o anda aktif olan tüm tıbbi merkezlerin bilgisi de tutulmaktadır. Bir önceki bölümde anlatılan di er bir e-sa lık projesi olan Merkezi Hastane Randevu Sistemi, Sa lık Bakanlı ı tarafından sadece devlet hastaneleri için yürütülmesi planlanmı ve henüz kullanılmaya ba lanmamı bir projedir. Tez projesi kapsamında, Merkezi Hastane Randevu Sisteminin ülke çapındaki tüm hastaneleri kapsayaca ı varsayılmı ve bu sistemin verilerine eri ebilecek Merkezi Randevu Sistemi adında bir sistem gerçekle tirilmi tir. Geli tirilen Merkezi Randevu Sistemi, tüm randevuların tutuldu u yerel bir veritabanını kullanmaktadır. Sistem geli tirilirken, alınan ve silinen randevuların tıbbi merkezler tarafından sisteme bildirilece i ve kullanıcıların kimlik numaralarını ve

78 52 gitmek istedikleri bran ı girerek, bu de erlere sahip olan tüm randevularını sorgulayabilece i dü ünülmü tür. Tez projesi çerçevesinde, anlamsal web ve çoklu etmen teknolojileri kullanılarak, tıbbi veri ileti imi ve akıllı randevu alma süreçlerini sa layan bir çok-etmenli sistemin olu turulması amaçlanmı tır. Projede etmen teknolojilerinin kullanılmasıyla, geli tirilen sistemin özerk bir yapıda olması sa lanmaktadır. Proje kapsamında özerk çalı an etmenlerle, HL7 uyumlu hasta verisine doktorlar tarafından eri ilebilmekte ve hasta adına akıllı randevu alma i lemleri yerine getirilebilmektedir. Doktorların hastanın geçmi tıbbi verilerine eri mesiyle, tanı tedavi sürecinin hızlanması ve bunun yanı sıra akıllı randevu alma süreçlerinin gerçekle tirilmesi bu tez projesinin en temel getirileri olarak söylenebilir. Sonraki bölümlerde, tez projesinde geli tirilen sistemin detayları anlatılmı tır Önerilen Çok-Etmenli Sistem Mimarisi ekil 4.1 de geli tirilen sistemin mimarisi gösterilmi tir. A a ıda, mimarideki etmenler ayrıntılı olarak incelenmi tir. MedicalNet Etmeni (MedicalNet Agent): O anda sisteme kayıtlı olan Tıbbi Merkezlerin bilgisini tutar. Bu etmen, önceki bölümde tanımlanan MedicalNet sistemi üzerinde çalı maktadır. Sa lık-net sisteminde u anda sadece hasta verisi gönderilebilmektedir. Kayıtlı olan hasta verilerine eri im olana ı yoktur. Bu nedenle MedicalNet sistemi içerisinde, geçici olarak olu turulan ve hastaların tüm tıbbi kayıtlarının tutuldu u varsayılan, yerel veritabanı (MedicalNet veritabanı) ile ileti im MedicalNet Etmeni aracılı ı ile gerçekle tirilmi tir. Bir tıbbi merkezdeki bilgi 3 katmanda tutulur. Her tıbbi merkezin yalnızca bir adet Tıbbi Merkez Etmeni (Medical Centre Agent-MCA), tıbbi merkezdeki her departman için bir tane olmak üzere Departman Etmenleri (Department Agent- DEP) ve her departmandaki her doktor için bir tane olmak üzere Doktor Etmenleri (Doctor Agent-DA) vardır.

79 53 ekil 4.1 Çok-Etmenli Sistem Mimarisi Tıbbi Merkez Etmeni (Medical Centre Agent-MCA): Tıbbi merkezin ismi, adresi, ne tipte bir hastane oldu u (U1 : Üniversite hastanesi, OH: Özel Hastane, gibi), hangi kurumlarla anla malı oldu u (Sosyal Güvenlik Kurumu- SGK, çe itli özel sigorta irketleri, vb.) gibi tıbbi merkezle ilgili olan genel bilgileri tutar. Ayrıca tıbbi merkez içerisinde, o anda sisteme dahil olan, aktif durumdaki, departmanların bilgisine sahiptir. Departman Etmeni (Department Agent-DEP): Kendi departmanı ile ilgili departmanın ismi gibi genel bilgileri tutar. Ayrıca kendi departmanı içerisindeki aktif doktorların bilgisine sahiptir.

80 54 Doktor Etmeni (Doctor Agent-DA): Verilen doktorun adı, soyadı, kimlik numarası gibi bilgileri tutar. Ayrıca doktorun zaman çizelgesine de sahiptir. Doktorların çok-etmenli sisteme eri imi için grafiksel bir arayüz sa lar. Bu arayüzle doktorlar zaman çizelgelerini görebilirler ve randevu almı bir hastanın eski bilgilerini ö renmek için sorgulama yapabilirler. Randevu Merkezi Etmeni (Appointment Centre Agent): Bu etmen, önceki bölümde tanımlanan Merkezi Randevu Sistemi üzerinde çalı maktadır. Merkezi Randevu Sistemi içerisinde, geçici olarak olu turulan ve hastaların tüm randevularının tutuldu u varsayılan, yerel veritabanı (MedicalNet veritabanı) ile ileti im Randevu MErkezi Etmeni aracılı ı ile gerçekle tirilmi tir. Kullanıcı Etmeni (UserAgent): Kullanıcıların çok-etmenli sisteme eri imi için grafiksel bir arayüz sa lar. Kullanıcılar bu arayüz vasıtasıyla sunulan servislere (sorgulama, randevu alma, randevu silme, gibi...) eri ebilirler. ekil 4.1 den de anla ılabildi i gibi sistemdeki her Doktor Etmeni, sadece kendi Departman Etmeni ile mesajla abilir. Aynı zamanda her Departman Etmeni de Tıbbi Merkez Etmeni ile mesajla abilir. Güvenlik nedeniyle Doktor Etmeninin do rudan MedicalNet Etmenine eri mesine ya da Kullanıcı Etmeninin do rudan Doktor Etmenine eri mesine izin verilmemi tir. Bu tez çalı masında, FIPA uyumlu etmen platformu olan açık kaynak kodlu JADE etmen geli tirme platformunun kullanıldı ına ve JADE in tercih edilmesinin nedenlerine daha önceki konularda de inilmi tir. Mimaride bulunan etmenler arasındaki etkile imler, FIPA nın tanımladı ı Request, Query ve Inform protokolleri kullanılarak gerçekle tirilmi tir. Ancak, etmenler arası etkile imler tasarım a amasında belirlenmi içerik ekilleriyle sınırlanırsa, mimarinin esnekli i kaybolacak ve açık olması sa lanamayacaktır. Bu nedenle, etmenler arasındaki etkile imler belirli ontolojiler ve içerik dilleri kullanarak gerçekle tirilmi tir. çerik dilleri, etmenler arası ileti imde iletilerin nasıl kodlanaca ını belirlerler ve böylece iletilerin belli bir yapısallıkta olmalarını sa larlar. Ancak, iletilerin yapısal olarak belli bir standartta olu turulmaları, etmenlerin ileti iminin anlamsal olarak zengin bir ekilde olması için yeterli de ildir. Bunu sa layacak olan, içerik ontolojisidir. Tez projesi kapsamında içerik ontolojisi olarak, basit bir sa lık ontolojisi olu turulmu tur. A a ıda, öncelikle bu ontolojinin tanımı yapılacak daha sonra da bölüm 4.1 de

81 55 bahsedilen mimarideki etmenlerin iç yapıları ve etmenler arasındaki etkile imler detaylı bir ekilde incelenerek etmenlerin platforma nasıl entegre oldukları anlatılmaya çalı ılacaktır. Etmenlerin sa lık ontolojisindeki kavramları kullanmaları nedeniyle, ontolojinin tanımı etmenlerin iç detaylarının anlatılmasından önce anlatılmı tır Sa lık Ontolojisi JADE etmenleri arasında ileti im için üç yöntem kullanılır. Birinci ve en çok kullanılan yöntem iletinin içeri ini tanımlamak için string kullanılmasıdır. letinin içeri i atomik bir veriyse bu yöntem uygundur. Fakat ileti içeri i soyut kavramlar, nesneler veya yapısal verilerden olu uyorsa bu yöntem kullanılmamalıdır. kinci yöntem; ileti içeri i olarak serile tirilmi Java nesnelerini yani Java teknolojisini kullanmaktır. Bu yöntem tüm etmenlerini Java da gerçekle tiren kısmi uygulamalar için uygundur. Bu yöntemin dez avantajı ise insanlar tarafından okunamamasıdır. Üçüncü yöntem ise; önceden tanımlanmı sınıfların uzantısı olarak ta ınabilen nesnelerin tanımlamalarını içerir yani bu yöntemde JADE uygulama tanımlı ontoloji ve içerik dili modeli kullanılır. Böylece JADE iletileri standart FIPA formatında ifreleyebilir veya de ifreleyebilir. Bu da JADE etmenlerinin di er etmen sistemleriyle birlikte çalı abilmesine olanak sa lar. Çalı ma kapsamında HL7 formatındaki sınıfların ontolojik olarak modellenmesi ba ka bir çalı ma konusu olarak görülmü ve bu nedenle doktorların hastanın eski bilgilerine eri ebilmesi a amasındaki ileti alı veri i için, ikinci yöntem kullanılmı tır. Bu çalı mada akıllı randevu alma ve etmenlerin birbirlerine kayıtlanma süreçlerindeki ileti alı veri i için ise üçüncü yöntem yani, JADE in uygulama tanımlı ontoloji ve içerik dili modeli kullanılmı ve Sa lık Ontolojisi adında basit bir ontoloji olu turulmu tur. Geli tirilen Sa lık Ontolojisi içerisindeki bile enler JADE ontoloji geli tirme modelinden gelen ve a a ıda daha ayrıntılı açıklanan; Concept, Predicate, AgentAction ve AID kavramlarından türetilmi tir. Bu ontoloji, randevu alma ve etmenlerin birbirlerine kayıtlanma i lemleri için kullanılmı tır.

82 56 ekil 4.2, üçüncü yöntem olan JADE ontoloji modeli için tanımlanan, çerik Referans Modelinin UML sınıf diyagramını göstermektedir. ekil 4.2 çerik Referans Modeli (JADE Tutorial, 2008) Bu model içerisindeki sınıflardan, Sa lık Ontolojisi içerisinde kullanıldı ı dü ünülerek, sadece yüklem, etmen aksiyonu ve kavram sınıflarına de inilmi tir. JADE ontoloji modelinde yüklemler, etmenlerin içinde bulundukları ortam hakkında bir önermede bulunan ve do ru (true) ya da yanlı (false) de er alabilen ifadelerdir. Örnek olarak; (Works-for (Person :name John) (Company :name TILAB)) cümlesi, John isimli ki inin TILAB irketi için çalı tı ını belirtmektedir. Yüklemler, INFORM ya da QUERY-IF mesajlarında içerik olarak gönderildiklerinde bir anlam ta ırlar (JADE Tutorial, 2008). Kavramlar, çe itli özellikler cinsinden ifade edilebilen karma ık yapıları gösteren ifadelerdir. Örnek olarak; (Person :name John :age 33)

83 57 bir kavramı ifade etmektedir. Kavramlar, ACL iletilerinin içinde do rudan kullanıldıklarında bir anlam ifade etmezler. Genellikle, di er kavramlar ya da yüklemlerin içinde kullanıldıklarında bir anlam ta ırlar. Örnek olarak a a ıdaki kavram; Tolkjien )) (Book :title The Lord of the rings :author (Person :name J.R.R. The Lord of the rings isimli kitabın yazarını (J.R.R. Tolkjien isimli bir ki i oldu unu) ifade etmektedir (JADE Tutorial, 2008). Etmen aksiyonlarıysa, etmenler tarafından yerine getirilmesi beklenen i levleri i aret eden, özel bir çe it kavram türüdür. Örnek olarak, (Sell (Book :title The Lord of the rings ) (Person :name John)) Bu deyim; John, The Lord of the rings isimli kitabı sat, demektir. Etmen aksiyonları REQUEST mesajları içerisinde gönderildiklerinde anlam ta ırlar (JADE Tutorial, 2008). Etmenlerin belirli bir amaca yönelik (akıllı randevu alma ve birbirlerine kayıtlanma süreçlerini gerçekle tirmek) olarak etkile imde bulundukları dü ünülürse, bu amaca yönelik kavram, etmen aksiyonu ve yöntemlerin belirlenip, bir ontoloji olarak modellenmeleri gerekmektedir. Özellikle geni ontolojiler olu turulurken, ontoloji tanımlama sınıflarının ve ontoloji içerisindeki yüklem, etmen aksiyonu ve kavramları temsil eden Java sınıflarının elle (hiçbir araç kullanılmaksızın) olu turulması zaman kaybına neden olmaktadır. OntologyBeanGenerator adı verilen özel bir plug-in sayesinde Protege 1 kullanarak uygulama tanımlı bir JADE ontolojisi olu turmak mümkün hale gelmi tir (JADE Tutorial, 2008). Stanford Üniversitesi tarafından geli tirilmi olan Protege ontoloji editörü, ontoloji geli tirilmesi konusunda kolaylık sa lamaktadır. Grafik arayüzü sayesinde ontolojiler görsel olarak tanımlanmakta ve böylelikle de alan modellemesi yapılabilmektedir. Protege, sistem geli tiricileri ve uzmanları 1 son eri im 15 A ustos 2009

84 58 tarafından bilgi tabanlı sistemlerin geli tirilmesi amacıyla kullanılan entegre bir yazılım aracıdır. Protege üzerinde; JADE ontoloji modeli uyumlu bir ontoloji yaratmak için, ilk önce OntologyBeanGenerator eklentisi içerisinde gelen ve OWLSimpleJADEAbstractOntology adı verilen ontolojinin projeye dahil edilmesi (import) gerekir. Bu ontoloji; kavram, yüklem ve etmen aksiyonu tipindeki temel soyut elemanları içerir. Geli tirilmek istenen ontoloji içerisindeki elemanların, bu soyut elemanlar altında olu turulması gerekir. Ayrıca OWLSimpleJADEAbstractOntology hazır bir kavram olarak AID i de içerir. Kısacası; OWLSimpleJADEAbstractOntology ontolojisi projeye eklendikten sonra, Protege sınıf a acı üzerinde dört yeni sınıf (Concept, Predicate, AgentAction ve AID) görünür. Ontoloji geli tirilirken alan modelinde tanımlanan elemanların bu dört sınıftan bir tanesinin altında yaratılması gerekir (JADE Tutorial, 2008) ve proje çerçevesinde olu turulan Sa lık Ontolojisi içerisinde bulunan kavramlar bu dört sınıftan türetilmi tir. ekil 4.3 de akıllı randevu alma ve birbirlerine kayıtlanma süreçlerinde kullanılmak amacıyla olu turulan Sa lık Ontolojisinin, Protege ekranı üzerindeki görüntüsü verilmi tir. ekil 4.3 Sa lık Ontolojisinin Olu turulması OntologyBeanGenerator, Protege de tanımlanan ontolojiden otomatik olarak ontoloji tanımlama sınıflarını ve ayrıca yüklem, etmen aksiyonu ve kavram

85 59 sınıflarını yaratır. Ontoloji tanımlama a amasında Java kodları yazmak yerine bu eklentiyi kullanmak çok daha kolay ve kısa süren bir yöntemdir. Bu eklenti, JADE eklentisi olarak geli tirilmi ve adresinden elde edilebilmektedir. Bu eklentinin Protege e nasıl eklenece i ve bir Protege ontolojisinin JADE ontolojisine nasıl dönü türülece i detaylı olarak ve adreslerinden ö renilebilir (JADE Tutorial, 2008). OWLSimpleJADEAbstractOntology projeye dahil edildikten sonra, proje üzerinde Project Configure ve daha sonra OntologyBeanGeneratorTab ı seçilir. Bunun sonucunda, Protege ekranında Ontology Bean Generator sekmesi ortaya çıkar ( ekil 4.4). Bu araç kullanılarak; RDF(S), XML ve Protege projelerinden FIPA/JADE uyumlu ontolojiler olu turulabilir. ekil 4.4 OntologyBeanGenerator Arayüzü Proje geli tirilirken, OntologyBeanGenerator sekmesi üzerindeki Generate Beans butonuna basılarak ontolojideki bile enlerden JADE uyumlu sınıflar olu turulmu tur. Olu an sınıflar interface tipindedir ve ileti içerisinde ta ınabilen nesneleri gösterirler ( ekil 4.5). Bu nesneler, çe itli i levler için etmen aksiyonları ve yüklemler, ayrıca etmenler arasında gidip gelen iletilerde ta ınan bilgiler için kavramlar olabilmektedir.

86 60 ekil 4.5 Sa lık Ontolojisi çerisindeki Etmen Aksiyonları,Yüklemler ve Kavramlar Ontolojinin kullanılabilmesi için proje kapsamında, bu interface sınıflarını gerçekle tiren sınıflar olu turulmu tur. ekil 4.6 da ise, geli tirilen sa lık ontolojisinin tamamı, UML sınıf diyagramı biçiminde gösterilmi tir. Bundan sonra, etmenler arası gidip gelen iletilerin içindeki bilgiler, birer Java nesnesinin üyeleri olarak i lenebileceklerdir.

87 61 ekil 4.6 Sa lık Ontolojisi UML Sınıf Diyagramı A a ıda, Sa lık Ontolojisi içerisinde olu turulan kavram, etmen aksiyonları ve yüklemler a a ıda kısaca anlatılmı tır. Tıbbi Merkez (MedicalCentre) kavramı; tıbbi merkezin adı, adresi gibi bilgilerinin ta ınması için olu turulmu tur. Bu bilgiler arasında, U1: Üniversite hastanesi gibi, Tıbbi Merkezin Sınıfı (MedicalCentreClass) bilgisi de ta ınır. Bir tıbbi merkez, Genel Tıbbi Merkez (PublicMedicalCentre) ve Özel Tıbbi Merkez (PrivateMedicalCentre) olmak üzere iki farklı türde olabilir. Hastanenin genel olması; devlet hastanesi, üniversite hastanesi, e itim hastanesi gibi bir kamu kurulu u oldu unu gösterir. Özel olması ise; bir tıp merkezi, dal merkezi veya özel hastane yani bir özel kurulu oldu unu gösterir. Hasta Kabulü (PatientCase) kavramı, MedicalNet Sistemi içerisinde tutulan bilgilerden birkaçını; tıp merkezinin ismini, departman ismini ve doktor ismini, içerir. Bu kavram hastanın daha önce gitmi oldu u tıbbi merkezi, o tıbbi merkezdeki departmanı ve doktoru Kullanıcı Etmenine bildirmek için kullanılır. Doktor (Doctor) kavramı, doktor bilgisini (adı, soyadı, kimlik numarası, zaman çizelgesi, Doktor Etmeninin AID de eri gibi) ta ımak için kullanılır.

88 62 Departman (Department) kavramı, departman bilgisini (departman adı, Departman Etmeninin AID de eri gibi) ta ımak için kullanılır. Kayıtlı Randevu (RegisteredAppointment) kavramı, Merkezi Randevu Sisteminde kayıtlı olan randevuları ta ımak için kullanılır. Randevu (Appointment) kavramı, randevu bilgilerinin (doktor bilgisi, ba langıç biti zamanı gibi) ta ınması için kullanılır. RegisterMedicalCentre aksiyonu; Tıbbi Merkez Etmeninin, MedicalNet e kayıtlanmasını sa lamak amacıyla olu turulmu tur. çerisinde tıbbi merkez kavramını ta ır. RegisterDepartment aksiyonu; Departman Etmeninin, tıbbi merkeze kayıtlanmasını sa lamak amacıyla olu turulmu tur. çerisinde departman kavramını ta ır. RegisterDoctor aksiyonu; Doktor Etmeninin, departmana kayıtlanmasını sa lamak amacıyla olu turulmu tur. çerisinde doktor kavramını ta ır. SearchPatientAppointments aksiyonu; kullanıcının, Merkezi Randevu Sisteminde kayıtlı olan tüm kayıtlı randevu bilgilerini ö renebilmesini sa lamak amacıyla olu turulmu tur. SearchMedicalCentreAID aksiyonu; Kullanıcı Etmeninin, kayıtlı randevuların tıbbi merkezlerinin AID de erlerini ö renebilmesi amacıyla olu turulmu tur. çerisinde kayıtlı randevuların tutuldu u bir liste vardır. SearchPatientCases aksiyonu; kullanıcının, MedicalNet Sisteminde kayıtlı olan tüm hasta kabullerinin (PatientCase) ö renilmesini sa lamak amacıyla olu turulmu tur. çerisinde arama yapılmasını sa lamak amacıyla kimlik numarası de erini ta ır. SearchAllMedicalCentres aksiyonu; kullanıcının, sistemde kayıtlı tüm tıbbi merkezleri ö renebilmesini sa lamak amacıyla olu turulmu tur. SearchDoctorsAppointments aksiyonu; kullanıcının, tıbbi merkezi seçtikten sonra o tıbbi merkezdeki istedi i departmanda bulunan doktorların

89 63 tamamının veya belirli bir tanesinin zaman çizelgesini ö renebilmesi için olu turulmu tur. MakeAppointmentOperation aksiyonu; kullanıcının, randevu alma veya silme i lemini gerçekle tirmesini sa lamak amacıyla olu turulmu tur. çerisinde Randevu kavramını barındırır. MakeAppointmentOperationOnAppointmentCentre aksiyonu; alınan randevunun tıbbi merkez tarafından, Merkezi Randevu Sistemine kaydedilmesini sa lamak amacıyla olu turulmu tur. çerisinde Kayıtlı Randevu kavramını barındırır. Contracts bir yöntemdir (predicate). Kullanıcının, tıbbi merkezin kendi kurumuyla anla ması olup olmadı ını sorgulamasını sa lamak amacıyla olu turulmu tur. Mimaride tanımlanan etmenlerin, ontoloji elemanlarını nasıl kullandıkları etmenlerin sınıf diyagramları verilerek Ek 1 de anlatılmaya çalı ılmı tır. JADE, içerik ontolojisinin iletiler içerisinde kodlanmasında çe itli içerik dillerini desteklemektedir. JADE standart kütüphanesiyle birlikte gelen Jade.content paketi SL içerik dili için gereken kodlayıcı ve çözücü sınıfları hazır olarak sunmaktadır. SL dili, ileti içeriklerini string veri tipinde kodlamak için etmen temelli uygulamalarda sıklıkla kullanılan bir içerik dilidir. Bu tezde verilen uygulama örneklerinin tamamında ileti içeriklerini kodlamada SL içerik dili kullanılmı tır. JADE ontoloji modelini kullanılarak geli tirilen ontolojiler, belli bir alana ve uygulamaya yönelik olarak ele alınır ve bu model üzerinden etkile ime giren etmenler arasında gidip gelen ileti içeriklerinin ta ıdı ı anlamsal boyut da modelin getirdi i kısıtlarla sınırlı kalmaktadır. Bu durum, tez kapsamında gerçeklenen uygulama için yeterli olmakla birlikte; anlamsal web tekniklerine do rudan destek veren bir çoklu-etmen platformu ve standart bir içerik dilinin kullanımı, daha genel alan ontolojilerinin platforma entegrasyonunu kolayla tıracak ve açık ortamlardaki etmenler arasında daha yüksek seviyeli etkile imlerin gerçekle ebilmesine imkan verecektir (Dikenelli et al., 2006).

90 JADE Etmenlerinin ç Detayları ekil 4.6 da verilen ontolojiye göre aralarında etkile imde bulunan ve Sa lık Bilgi Sistemi ( ekil 4.1) içerisinde yer alan çe itli etmenlerin iç yapıları bu bölümde detaylandırılmaya çalı ılacaktır. Daha önceki bölümlerde de belirtildi i gibi, mimari üzerinde yer alan etmenler, etmen paradigması açısından zayıfnosyon (weak-notion) etmenler olup, iç yapıları durumlarını sembolik olarak modelleyecek ekilde geli tirilmemi tir. Bu anlamda, bu etmenler aksiyonlarını yerine getirirlerken inanç, arzu, niyet (BDI) genel çerçevesi içinde karar alıp hareket etmemekte, daha ziyade sosyal yönleri kuvvetli, reaktif ve gerekti inde proaktif davranabilen etmenler olarak dü ünülmeleri gerekmektedir. Etmenlerin iç detayları ele alındı ında ba langıçta belli formatlara uydukları görülmektedir. Her bir JADE etmeni setup metodunda, verdikleri hizmetleri platformun dizin kolayla tırıcısı üzerine kayıt ettirirler. Bu i lemi gerçekle tiren MedicalNet Etmeni için kod örne i a a ıdaki gibidir. Burada MedicalNet Etmeni medicalnet bilgi servisini sunmaktadır. Aynı ekilde di er etmenlerde kendi sa ladıkları servisi DF ye kaydettirirler. DFAgentDescription dfd = new DFAgentDescription(); dfd.setname(getaid()); ServiceDescription sd = new ServiceDescription (); sd.settype("medicalnet-information"); sd.setname("jade-medicalnet-information"); dfd.addservices(sd); try { DFService.register(this, dfd); } catch (FIPAException fe) { fe.printstacktrace(); } Daha sonra da kullandıkları ontoloji ve içerik dili kodlayıcısını, kendi içerik yöneticisi nesnesi üzerinde kayıt altına almaktadırlar. Bu i lemi yerine getiren kod parçacı ı a a ıda verilmi tir. private Codec codec = new SLCodec(); private Ontology ontology = HealthcareOntology.getInstance(); //Register the codec. getcontentmanager().registerlanguage(codec); //Register the ontology used by this application getcontentmanager().registerontology(ontology);

91 65 setup() metodu içerisinde yapılan bu i lemler tüm etmenler için geçerlidir. ekil 4.7 de MedicalNet Etmeni setup() metodu içerisinde yapılan i lemlerin ardıl etkile im diyagramı gösterilmi tir. Bundan sonra yapılan i lemler etmenlerin özelliklerine göre farklılık göstermektedirler. ekil 4.7 MedicalNet Etmeni Setup Metodu Ardıl Etkile im Diyagramı Sistemin kullanıcı giri i için hazır hale getirilmesi Sistem tasarlanırken MedicalNet Etmeni ve Randevu Merkezi Etmeninin sabit bir IP adresi ve sabit bir port numarasıyla (yani sabit bir AID le) sürekli çalı an yapıda oldu u dü ünülmü tür. Bu nedenle sitemi çalı tırma i lemine, öncelikle bu etmenlerden ba lanmalıdır. Daha öncede belirtildi i gibi, JADE tek i parçalı (single-threaded) yakla ım kullanır. Yani JADE içerisinde yaratılan etmenler tek bir i parçacı ından olu mu tur ve etmenler üzerindeki tüm görevler Behaviour nesneleri eklinde modellenmekte ve gerçekle tirilmektedir. Behaviour nesneleri addbehaviour() metoduyla, etmen sınıfında bulunan, hazır görevler (scheduler) kuyru una eklenir. Etmen hazır görevler kuyru undaki ilk görevin action() metodunu i letir. action() sonucunda done() metodu ça rılarak görevin tamamlayıp tamamlamadı ı kontrol edilir. Tamamlanması durumunda görev kuyruktan atılır ve sıradaki göreve geçilir. JADE içerisinde çalı an bu mantık geli tirilmek istenen çalı ma için yeterli görülmemi tir. Çünkü; etmene her gelen istek için bir görev yaratıldı ı dü ünüldü ünde bir görev sonlanmadan (ya da bekleme durumuna geçmeden) di er görev ba latılamaz. Yani ikinci gelen istek için yapılması gereken i lemler, ilk gelen iste in i lemlerini beklemek zorundadır. Daha açık bir ekilde anlatmak

92 66 gerekirse; örne in bir doktor, Doktor Etmeni aracılı ıyla Hasta1 isimli hastanın bilgisini görüntülemek istiyor olsun. Aynı anda Hasta2 isimli hasta o doktordan randevu almak isteyebilir. Sadece JADE etmenleri içerisindeki tek i parçalı yakla ım kullanılırsa Doktor Etmeni Hasta1 in bilgisini almadan Hasta2 ye randevu veremez. lemler istek sırasına göre yapılır. Bu da olu turulmak istenen sistemin kullanılabilirli ini azaltır. Bu nedenle tez çalı ması kapsamında; sunucu mantı ında çalı an tüm etmenlerin içerisinde, her gelen istek için bir i parçacı ı yaratılması uygun görülmü tür. Bu etmenler Randevu Merkezi Etmeni, MedicalNet Etmeni, Tıbbi Merkez Etmeni, Departman Etmeni ve Doktor Etmenidir. Bundan sonraki anlatımlarda ve diyagramlarda, etmenler üzerindeki i parçacıklarından bahsedilece i için konunun burada anlatılması uygun görülmü tür. MedicalNet Etmeni setup() metodu içerisinde, registerontology() i leminden sonra, döngüsel görev tipindeki MedicalNetOfferRequestsServer görevini yaratır ve hazır görevler kuyru una ekler. Bu görevin action() metodunun kod içeri i a a ıdaki verilmi tir. public void action() { ACLMessage msg = myagent.receive(); if (msg!= null) { MedicalNetThread medicalnetthread = new MedicalNetThread(msg); medicalnetthread.start(); } } else { block(); } Koddan da anla ılaca ı gibi her gelen istek için bir i parçacı ı yaratılır. Randevu Merkezi Etmeni de aynı mantıkla çalı ır. Etmen setup() metodunu gerçekle tirdikten sonra, AppointmentCentreOfferRequestsServer döngüsel görevini yaratır ve hazır görevler kuyru una ekler. Bu görevin de kod içeri i MedicalNet Etmeni ile aynı olaca ından tekrar gösterilmemi tir. Bu a amada artık MedicalNet Etmeni de, Randevu Merkezi Etmeni de kendilerine gelecek istekleri dinlemeye ba lamı lardır. Bundan sonra sistemin tıbbi merkez tarafı çalı tırılabilir.

93 67 Bir önceki bölümde etmenleri anlatırken, Tıbbi Merkez Etmeninin içerisinde o anda sisteme kayıtlı olan tüm Departman Etmenlerinin tutuldu undan bahsedilmi ti. Yani öncelikle (MedicalNet Etmeni ve Randevu Merkezi Etmeninin daha önceden çalı tırıldı ı varsayılarak) Tıbbi Merkez Etmeni çalı tırılmalıdır. Tıbbi Merkez Etmeni çalı tırıldı ında kendi AID de erlerini yerel veritabanına kaydeder ve daha sonra etmenin setup() metodunun içerisinde, RegisterToMedicalNetAgent görevi yaratılır ve bu görev Tıbbi Merkez Etmeni içerisindeki hazır görevler kuyru una eklenir. Bu görev bir kereye mahsus (OneShotBehaviour) bir görev tipindedir yani bir kere çalı ır ve biter. Burada daha önceden de söylendi i gibi sabit bir adresi bulunan MedicalNet Etmeninin AID de erlerinin sistemde kayıtlı oldu u varsayılmı tır. Bu görevin action() metodu içerisinde MedicalNet Etmenine bir RegisterMedicalCentre etmen aksiyonu gönderilir. Ve böylece MedicalNet Etmeni Tıbbi Merkezin bilgisini kendi içerisinde bulunan bir listeye ekler. Bu i lemin ardıl etkile im diyagramı ekil 4.8 de gösterilmi tir. ekil 4.8 RegisterToMedicalNetAgent Görevi Ardıl Etkile im Diyagramı RegisterMedicalCentre iletisinin cevabını alan Tıbbi Merkez Etmeni döngüsel görev tipinde olan MedicalCentreOfferRequestsServer görevini çalı tırır. Bu görevin detayları konuyu da ıtaca ı dü ünülerek Ek 2 de ayrıntılı olarak anlatılmı tır. Kısaca; Tıbbi Merkez Etmeni

94 68 MedicalCentreOfferRequestsServer göreviyle, kendisine gelen iletileri dinlemeye ba lar. Bu a amada artık Departman Etmenleri sisteme dahil olabilirler. Departman Etmenleri de yaratıldıklarında AID de erlerini yerel veritabanına kaydederler ve daha sonra Tıbbi Merkez Etmenine RegisterToMedicalCentreAgent görevinin action() metodu içerisinde bir RegisterMedicalCentre etmen aksiyonu gönderirler. Departman Etmeni tıbbi merkeze ileti gönderebilmek için gerekli olan Tıbbi Merkez Etmeni AID de erini yerel veritabanından ö renir. Bu register iletisini alan Tıbbi Merkez Etmeni, kendi içerisinde bulunan, aktif departmanların tutuldu u listeye departman bilgisini ekler ve ekledi i cevabını geri döndürür. Cevabı alan Departman Etmeni, Tıbbi Merkez Etmenindeki MedicalCentreOfferRequestsServer göreviyle aynı mantıkta çalı an döngüsel bir görev yaratır. Yani Departman Etmeni de kendisine gelen iletileri dinlemeye ba lar. Bu durumda artık Doktor Etmenleri de sisteme eklenebilirler. Bunun için öncelikle doktorun sisteme giri yapması gerekir. Tez çalı ması çerçevesinde, doktorun sisteme dahil olabilmesi için bir grafiksel kullanıcı arayüzü tasarlanmı tır. Bu arayüz ekil 4.9 da gösterildi i gibidir. ekil 4.9 Doktor Giri Ekranı Burada doktorun kullanıcı adı ve ifresini do ru olarak girmesi gerekir. Yanlı bir giri yaparsa sistem bunu Kullanıcı adı veya ifre yanlı tır. Tekrar deneyiniz! hata iletisiyle kullanıcıya (doktora) bildirir. Di er bir de i le sadece izin verilen doktorlar sisteme giri yapabilir. Böylelikle yetkisi olmayan ki ilerin sisteme giri i engellenmi olur. Doktor sisteme giri yaptıktan sonra artık kendini Departman Etmenine kaydettirebilir. Doktor Etmeni bu i lem için gerekli olan alıcı adresini, yani Departman Etmeninin AID de erini, veritabanından ö renir ve daha sonra kendisini ili kili oldu u Departman Etmenine RegisterToDepartmentAgent görevi içerisinde gönderilen RegisterDoctor etmen

95 69 aksiyonu ile kaydettirir. Doktor Etmeni bundan sonra, kendisine gelen iletileri dinleyebilmek için Tıbbi Merkez Etmenindeki MedicalCentreOfferRequestsServer göreviyle aynı mantıkta çalı an döngüsel bir görev yaratır. Bu i lemle birlikte, sistemde kayıtlı olan tüm etmenler (Randevu Merkezi Etmeni, MedicalNet Etmeni, Tıbbi Merkez Etmenleri, Departman Etmenleri ve Doktor Etmenleri) birbirine ba lanmı tır ve kullanıcıdan istek bekleme durumundadır. Departman Etmeninin gerçekle tirdi i RegisterToMedicalCentreAgent görevi ve Doktor Etmeninin gerçekle tirdi i RegisterToDepartmentAgent görevinin ardıl etkile im diyagramları ekil 4.8 dekine benzer olaca ından tekrar gösterilmemi tir Kullanıcının sisteme dahil olması Kullanıcının sisteme dahil olabilmesi için de bir grafiksel arayüz tasarlanmı tır. Bu arayüz ekil 4.10 da gösterilmi tir. Kullanıcı kimlik numarasını ve randevu almak istedi i bran ı arayüze girerek sisteme giri yapar. ekil 4.10 Kullanıcı Giri Ekranı Sistemin i leyi ini daha kolay anlatabilmek için, bundan sonraki i lemler olası senaryolar olarak ayrı ayrı numara verilerek anlatılmı tır. A a ıda öncelikle adımlar için akı diyagramları verilecek daha sonra adımların detayları anlatılacaktır. lk 6 adımdaki i lemler için akı diyagramı ekil 4.11 de gösterilmi tir.

96 70 ekil den 6 ya Kadar Uygulanan Adımlar çin Akı Diyagramı

97 71 1. Bir kullanıcı sisteme 2. Defa giriyorsa; ya randevu tarihini unutmu tur, ya randevusunu iptal etmek istiyordur ya da farklı bir bran tan randevu almak istiyordur. Bu nedenle Kullanıcı Etmeni ilk önce hastanın sistemde kayıtlı randevusu olup olmadı ına bakar ve e er varsa randevunun alındı ı tıbbi merkezi ve doktoru kullanıcıya iletir. Bu i lem SearchRegisteredAppointmentBehaviour görevi ile gerçekle tirilmi tir. Kullanıcı sisteme girdikten sonra ilk olarak Kullanıcı Etmeni yaratılır ve Kullanıcı Etmeni de SearchRegisteredAppointmentBehaviour görevini yaratarak i lemlerine ba lar. Daha sonra bu görevi hazır görevler kuyru una ekler. Kuyrukta bekleyen ba ka bir görev olmadı ı için SearchRegisteredAppointmentBehaviour görevi çalı maya ba lar. verilmi tir. Bu görevin çalı masıyla olu an ardıl etkile im diyagramı ekil 4.12 de ekil 4.12 SearchRegisteredAppointmentBehaviour Görevi Ardıl Etkile im Diyagramı Bu görevin sonucunda Randevu Merkezi Etmeninden, kendisinde kayıtlı olan tüm kayıtlı randevu (RegisteredAppointment) tipindeki nesneleri döndürmesi beklenir. Kayıtlı randevu tipindeki nesnelerin içerisinde tıbbi merkezin ve doktorun bilgileri de kayıtlıdır.

98 72 Hastanın sistemde kayıtlı bir randevusu varsa, liste doluysa, 2. Adımdan devam edilir. Liste bo sa, yani kullanıcının sistemde kayıtlı olan bir randevusu yoksa, 3.Adıma geçilir. 2. SearchMedicalNetForMedicalCentresAIDBehaviour: Hastanın sistemde kayıtlı bir randevusu varsa (liste bo de ilse) Kullanıcı Etmeni SearchMedicalNetForMedicalCentresAIDBehaviour görevini ba latır. Bu görev ilk önce platformdaki MedicalNet Etmenlerinin eri im bilgilerini dizin kolayla tırıcıdan ö renir. Bu i lemin kod örne i a a ıdaki gibidir. lemin ardıl etkile im diyagramı ekil 4.13 de gösterilmi tir. DFAgentDescription template = new DFAgentDescription(); ServiceDescription sd = new ServiceDescription(); sd.settype("medicalnet-information"); template.addservices(sd); try { DFAgentDescription[] result = DFService.search(myAgent, template); medicalnetagents = new AID[result.length]; for (int i = 0; i < result.length; ++i) medicalnetagents[i] = result[i].getname(); } catch (FIPAException fe) { fe.printstacktrace(); } ekil 4.13 MedicalNet Etmenlerinin Eri im Bilgilerini Dizin Kolayla tırıcıdan Ö renen lemin Ardıl Etkile im Diyagramı

99 73 Bu a amada artık Kullanıcı Etmeni, sistemdeki MedicalNet Etmenlerini biliyor demektir. Görev, bundan sonraki i lem olarak, kayıtlı randevuların ait oldu u tıbbi merkezlerin sistemde o anda aktif olup olmadı ını ö renmek için MedicalNet Etmenine ileti gönderir. Bu i lemler için ardıl etkile im diyagramı ekil 4.14 de gösterilmi tir. ekil 4.14 SearchMedicalNetForMedicalCentresAIDBehaviour Görevi Ardıl Etkile im Diyagramı letinin cevabında kullanıcıya bir liste geri döner. Bu liste bo sa; yani kullanıcının daha önceden almı oldu u randevular olmasına kar ın o randevuların alındı ı tıbbi merkezler o anda aktif de il demektir ve i letime 3. Adımdan devam edilir. Ancak liste doluysa kullanıcı, AID de erleri ile birlikte tıbbi merkezler listesine sahip demektir ve hastanın kabullerine hiç bakılmadan 6. Adıma geçilir. 3. E er kullanıcı aynı bran a sahip bir tıbbi merkeze daha önceden gitmi se; gene o tıbbi merkezdeki aynı doktordan randevu almak ister. Çünkü insanlar genelde yeni bir tıbbi merkezde yeni bir doktora gitmek yerine alı ık oldu una gitmeyi tercih ederler. Bu i lem için öncelikle kullanıcının eski bilgilerinin ö renilmesi gerekir. Bu i lemi SearchMedicalNetForMedicalCentresBehaviour görevi yerine getirir. Bu görev de i lemine, bir önceki adımda anlatıldı ı gibi, platformdaki MedicalNet Etmenlerinin eri im bilgilerini dizin kolayla tırıcıdan ö renmekle ba lar. Bundan sonra, Kullanıcı Etmeni SearchMedicalNetForMedicalCentresBehaviour görevi vasıtasıyla, kullanıcının sistemde kayıtlı olan kabullerini ö renmek amacıyla

100 74 MedicalNet Etmenine SearchPatientCases etmen aksiyonunu gönderir. Bu görevin ardıl etkile im diyagramı ekil 4.15 de gösterilmi tir. ekil 4.15 SearchPatientCases letisi çin SearchMedicalNetForMedicalCentresBehaviour Görevi Ardıl Etkile im Diyagramı lem sonrasında MedicalNet Etmeninden geri dönen liste doluysa 4. Adımdan devam edilir. E er liste bo sa, kullanıcı daha önceden hiçbir sa lık kurulu una gitmemi demektir ve 5. Adıma geçilir. 4. Burada Kullanıcı Etmeni, kullanıcının (hastanın) daha önceki i lemleri ile ilgili bilgilere sahiptir. Kullanıcı Etmeni içerisindeki parsepatientcase() metoduyla hastanın kabulleri ayrı tırılır ve sisteme girerken belirtti i bran tipinde daha önceden bir kabulü varsa o tıbbi merkez, Kullanıcı Etmeni içerisindeki listeye eklenir ve 6. Adıma geçilir. parsepatientcase() metodunun kod içeri i a a ıda verilmi tir. E er o bran ta daha önceden bir kabulü yoksa, 5. Adımdan devam edilir. public void parsepatientcase (List patientcases) { if (patientcases.size() == 0) {... } else { PatientCase patientcase = null; for (int i = 0; i < patientcases.size(); i++) { patientcase = (PatientCase) patientcases.get(i);

101 75 if (patientcase.getdepartment(). getdepartmentname().equals(departmentname)) { addmedicalcentre(patientcase.getmedicalcentre()); } adddoctorsnationalid(patientcase.getdoctor().getnationalid()); } } } adımdaki ile aynı metod kullanılır ancak bu sefer MedicalNet Etmenine, sistemde o anda aktif olan tüm tıbbi merkezlerin listesini ö renebilmek için SearchAllMedicalCentres etmen aksiyonunu gönderir. ekil 4.16 da i lemin ardıl etkile im diyagramı verilmi tir. ekil 4.16 SearchAllMedicalCentres letisi çin SearchMedicalNetForMedicalCentresBehaviour Görevi Ardıl Etkile im Diyagramı ste in cevabı olarak, MedicalNet Etmeni kendisine kayıtlı olan o andaki tüm aktif tıbbi merkezlerin listesini kullanıcıya geri bildirir. Ve bir sonraki adıma geçilir. 6. Kullanıcı Etmeni bu a amaya kadar gelmi se elinde tıbbi merkezlerin bir listesi var demektir. Ancak bu tıbbi merkezlerin kullanıcının sa lık sigortası ile anla malı olup olmadı ı bilinmemektedir. Kullanıcı randevu

102 76 alırken kendi sa lık sigortası ile anla ması olan hastaneleri tercih edecektir. Bu nedenle Kullanıcı Etmeni elinde bulunan tıbbi merkezler listesinindeki tüm merkezler için ayrı ayrı RequestForContractBehaviour görevi yaratır. Bu görev QUERY_IF iletisi ile Tıbbi Merkez Etmenine, tıbbi merkezin kullanıcının kurumuyla anla malı olup olmadı ı bilgisini sorar ( ekil 4.17). ekil 4.17 RequestForContractBehaviour Görevi Ardıl Etkile im Diyagramı E er tıbbi merkezin hastanın kurumu ile anla ması varsa, Kullanıcı Etmeni bu merkezi listesine ekler. Kullanıcı Etmeni listesindeki tüm tıbbi merkezlere bu iletiyi gönderip cevaplarını aldıktan sonra kullanıcının listeden istedi i tıbbi merkezi seçmesi için, elindeki tıbbi merkezler listesini ekil 4.18 deki gibi bir arayüzle kullanıcıya bildirir. ekil 4.18 Tıbbi Merkezler Listesi Arayüzü

103 77 Bundan sonraki 4 adım için akı diyagramı ekil 4.19 da gösterilmi tir. ekildeki akı diyagramı üzerinde adımların numaraları görülebilmektedir. ekil den 12 e Kadar Uygulanan Adımlar çin Akı Diyagramı 7. Arayüz üzerinde tıbbi merkezi adı ve adresi bilgileri bulunmaktadır. Bu a amada karar kullanıcıya bırakılmı tır. stedi i tıbbi merkezi seçer ve Zaman Çizelgesini Gör butonuna basar. Bu i lemle birlikte Kullanıcı Etmeninde

104 78 SearchSelectedMedicalCentreForDoctorsAppointmentsBehaviour ba latılır. ekil 4.20 de görevin ardıl etkile im diyagramı verilmi tir. görevi ekil 4.20 SearchSelectedMedicalCentreForDoctorsAppointmentsBehaviour Görevi Ardıl Etkile im Diyagramı Bu görevle Kullanıcı Etmeni, seçilen Tıbbi Merkez Etmenine istenen bran taki tüm doktorlar veya belirtilen doktor için Search Doctor Appointments etmen aksiyonunu gönderir. 8. Bu istek tıbbi merkeze geldikten sonra ilgili departmana bildirilir ( ekil 4.21). ekil 4.21 Tıbbi Merkez Etmenine Gelen SearchDoctorsAppointments ste i çin Ardıl Etkile im Diyagramı

105 79 9. Departman Etmeni iste i aldıktan sonra e er istekle beraber doktor belirtilmi se yalnızca o doktora iletiyi iletir. Gelen iste in içerisinde herhangi bir doktor belirtilmemi se; o anda kendi içerisinde kayıtlı olan tüm aktif doktorlara iste i iletir ( ekil 4.22). ekil 4.22 Departman Etmenine Gelen SearchsDoctorsAppointments ste i çin Ardıl Etkile im Diyagramı 10. ste i alan Doktor Etmeni/Etmenleri doktor bilgisini (doktor adı, soyadı, zaman çizelgesi) cevap olarak geri gönderir. 11. Departman Etmeni, iletiyi göndermi oldu u tüm doktorlardan cevaplarını ö rendikten sonra doktorlar listesini Tıbbi Merkez Etmenine bildirir. 12. Tıbbi Merkez Etmeni de bu cevabı Kullanıcı Etmenine bildirir. Yani iste in cevabı geldi i yoldan geri dönerek kullanıcıya bildirilir. Kullanıcı iste inin cevabını aldı ında ekran görüntüsü ekil 4.23 deki gibidir.

106 80 ekil 4.23 Kullanıcı Tarafı Doktor Zaman Çizelgesi Arayüzü Sistem tasarlanırken doktorların haftada 6 i günü ve 9:00-18:00 saatleri arasında çalı tı ı varsayılmı tır. Doktorla ilgili doktorun adı, soyadı, çalı tı ı tıbbi merkezin adı ve adresi gibi bilgilerle birlikte zaman çizelgesi arayüzde gösterilmi tir. Bu zaman çizelgesi üzerinde doktorun dolu zamanları farklı renklerle belirtilmi tir. Dolu zamanlar gösterilirken; randevu kendi randevusu ise kırmızı, ba ka birinin randevusu ise mavi renkle gösterilir. Ayrıca kullanıcının birden fazla doktor arasından seçim yapma olana ı varsa ekranın sa alt kısmında bulunan leri ve Geri butonlarına basarak bu doktorlar arasından istedi ini görüntüleyebilir. Bu a amadan sonra kullanıcı sistem üzerinden bir randevu alabilir veya kayıtlı bir randevusu varsa bu randevuyu silebilir. Bu i lemler için uygulanan adımlar ekil 4.24 de akı diyagramı eklinde gösterilmi tir.

107 81 ekil den 15 e Kadar Uygulanan Adımlar çin Akı Diyagramı 13. Kullanıcı, ekil 4.23 de görüldü ü gibi, doktorun zaman çizelgesi üzerindeki bo zamanları arasından istedi i zaman dilimini seçip randevu alma iste ini Kullanıcı Etmenine bildirir. Veya kendisine ait olan randevuyu seçip (ekran üzerinde kırmızı ile gösterilmi tir) randevu silme iste ini Kullanıcı Etmenine bildirir. Bu iki durumda da Kullanıcı Etmeni MakeAppointmentOperationBehaviour görevini ba latır. Bu görevle Kullanıcı Etmeni, randevu alma veya silme iste ini ilgili Tıbbi Merkez Etmenine bildirir. ekil 4.25 de görevin ardıl etkile im diyagramı verilmi tir.

108 82 ekil 4.25 MakeAppointmentOperationBehaviour Görevi Ardıl Etkile im Diyagramı 14. stek tıbbi merkeze geldikten sonra ilgili departmana, departman da ilgili doktora bildirilir. 15. Doktor Etmeni iste i aldı ında iste in tipine göre ya randevuyu siler ya da yeni bir randevu alır. Doktor Etmeninin iste i aldıktan sonraki kod içeri i a a ıda verilmi tir. E er istek yeni bir randevu alma iste i ise; doktor nesnesi üzerindeki appointmentissuitable() metodu randevu alınmak istenen zaman aralı ının uygun olup olmadı ını kontrol eder. steklerin cevabı daha önce de belirtildi i gibi geli i yoldan geri kullanıcıya bildirilir. if (makeappointmentoperation.getoperationtype().equalsignorecase(add_appointment)) { if (doctor.appointmentissuitable(newappointment)) { try { healthcareinformationsystem.adddoctorapointment(newappointment); } catch (SQLException e) { e.printstacktrace(); } } else { reply.setperformative(aclmessage.refuse); } } else if (makeappointmentoperation.getoperationtype().equalsignorecase(delete_appointment)) try { healthcareinformationsystem.deletedoctorapointment(newappointment); } catch (SQLException e) { e.printstacktrace(); }

109 Doktor tarafında bir senaryo Sistemin getirdi i di er bir yenilik olarak, hastanın eski verilerine eri imden bahsedilmi ti. Doktor sistem üzerinden, hastanın gitmi oldu u tüm tıp merkezleri, hastaya konan tanıları, hastanın o tıp merkezinden hangi tetkik ve tedavileri aldı ı, hangi ilaç ve sarf malzemeleri kullandı ı gibi hastaya ili kin olan tüm verileri ö renebilir ve bu verileri kullanarak kısa sürede daha tutarlı ve kesin tedaviler önerebilir. Bu bölümde doktora sunulan servislerin nasıl gerçekle tirili i ayrıntılı olarak anlatılacaktır. Öncelikle doktorun sisteme girmesinden hasta bilgisini ö renmesine kadar olan i lemleri anlatan akı diyagramı ekil 4.26 da gösterilmi daha sonra i lemlerin detaylarına inilmi tir. ekil 4.26 Doktorun Uyguladı ı lemler çin Akı Diyagramı Doktor, kullanıcı adı ve ifresini do ru olarak girdikten sonra ekil deki arayüz ekrana gelir.

110 84 ekil 4.27 Doktor Tarafı Doktor Zaman Çizelgesi Bu arayüz doktorun zaman çizelgesini göstermektedir. Bu zaman çizelgesi üzerinde kırmızı ile gösterilen bölümler doktorun dolu oldu u zaman dilimlerini gösterir. Ayrıca randevusu olan hastanın kimlik numarası da arayüzde belirtilmi tir. Bu ekran üzerinden doktor hastayı seçerek hasta verilerini arama iste ini, Doktor Etmenine bildirir. ste i alan Doktor Etmeni GetPatientInformationBehaviour görevini ba latır. Görevin ardıl etkile im diyagramı ekil 4.28 de verilmi tir. ekil 4.28 GetPatientInformationBehaviour Görevi Ardıl Etkile im Diyagramı

111 85 ekilden de anla ılaca ı gibi istek, Departman Etmenine iletilir. Departman Etmeni iste i Tıbbi Merkez Etmenine, Tıbbi Merkez Etmeni de MedicalNet Etmenine bildirir. ste i alan MedicalNet Etmeni hastanın verilerini, HL7 formatında, bir liste halinde döndürür. ste in cevabı geldi i yoldan Doktor Etmenine geri bildirilir. Doktor Etmenine gelen cevap HL7 formatındadır. HL7 formatındaki hasta verisinin okunabilmesi için Java nesnelerine yüklenmesi gerekir. Bu Java sınıfları, Sa lık Bakanlı ının yayınladı ı web servislerinin wsdl dosyalarından açık kaynak araçlar olan Apace Axis2/Java ve Apache Ant yardımıyla üretilmi tir (T.C. Sa lık Bakanlı ı B DB, 2008). Bu i lemler Sa lık-net sitesinde yayınlanan Yeni Ba layanlar çin HL7 Kılavuzu dokümanı yardımıyla gerçekle tirilmi tir. Bu a amada gelen HL7 formatındaki veri, olu turulan Java nesnelerine yüklenebilir. Ancak bu nesnelerin kullanıcılar veya program geli tiriciler tarafından okunabilmesinin zor oldu u anla ılmı ve bunun için HL7 uyumlu Java nesnelerini, daha kolay anla ılabilir formatta sunan (ayrı tıran) Java nesneleri olu turulmu tur. Sunulan yapı daha ayrıntılı olarak Ek 3 de incelenmi tir. Bu geli tirilen Java sınıflarının içerikleri ve isimlendirmeleri için Sa lık-net sitesinde yayınlanan, HL7 Mesajları Entegrasyon Klavuzu Hiyerar ik Mesaj Tanımları dokümanlarından faydalanılmı tır. Cevap, Ek 3 de önerilen yöntemle ayrı tırılarak kullanıcının ve programcının anlayabilece i bir formata dönü türülür. Elde edilen hasta kabulü (PatientCase) tipindeki nesneler ekil 4.29 daki gibi bir arayüzle doktora bildirilir. Bu hasta kabulü tipindeki nesneler, tez kapsamında sadece muayene veya yatan hasta olabilir. Ekranda; hasta adı, soyadı, cinsiyeti gibi hastanın genel bilgilerinin yanında hastanın hangi tıbbi merkeze ne zaman gitti i ve ne i lem uygulandı ı gibi bilgiler görüntülenir.

112 86 ekil 4.29 Hasta Bilgileri çin Bir Arayüz Doktor i lem hakkında daha fazla bilgi ö renmek istiyorsa, bu i lemi seçerek farklı bir ekranda tüm bilgileri görüntüleyebilir. Örne in, Muayene i lemi için Muayene Bilgilerini Getir butonuna basarak hastanın o muayene i leminin içeri ini görüntüleyebilir. Bu arayüz ekil 4.30 de verilmi tir. ekil 4.30 Muayene lemi çin Bir Arayüz Aynı ekilde yatan hasta bilgisini de Yatan Hasta Bilgilerini Getir butonuna basarak ekil 4.31 deki gibi görüntüleyebilir.

113 87 ekil 4.31 Yatan Hasta lemi çin Bir Arayüz 4.4. Sistemin Sa ladı ı Güvenlik Kısıtları Sistem çerçevesinde sa lanan güvenlik kısıtları a a ıda verilmi tir: MedicalNet verilerine, yalnızca MedicalNET Etmeni üzerinden eri ilebilmektedir. Merkezi Randevu Sisteminde tutulan verilere de sadece Randevu Merkezi Etmeni üzerinden eri ilebilir. Daha öncede de bahsedildi i gibi Doktor Etmeninin do rudan MedicalNet Etmenine eri mesine ya da Kullanıcı Etmeninin do rudan Doktor Etmenine eri mesine izin verilmemi tir. Yani Doktor Etmeni yalnızca Departman Etmenini, Departman Etmeni de yalnızca Tıbbi Merkez Etmenini tanır. Tıbbi Merkez Etmeni, Tıbbi merkezin dı a açılan kapısı olarak çalı ır. Gelen ve giden iletiler Tıbbi Merkez Etmeni üzerinden dı etmenlere gönderilirler. Kullanıcı adı ve ifresini do ru olarak giren doktorlar sisteme giri yapabilir. zinsiz kullanıcıların sisteme giri i engellenmi tir. Kullanıcılar (hastalar) kimlik numaralarını do ru bir ekilde girmeden sisteme giri yapamazlar.

114 88

115 89 5. BENZER ÇALI MALAR Literatürde etmenlerin sa lık alanında kullanılmasıyla ilgili pek çok çalı ma bulunmaktadır. Bunlardan bazıları çok-etmenli sistem yakla ımını, bazıları ontoloji tabanlı sistem yakla ımını, bazıları da ontoloji ve çok-etmenli sistem yakla ımını beraber kullanan çalı malardır. Bu bölümde literatürdeki çalı malar ile ilgili genel bilgiler verilmi tir. Son olarak tez çalı ması literatür ba lamında de erlendirilecektir HeCaSe: Ki iselle tirilmi Sa lık Servisleri Sa layan Etmen Tabanlı Bir Sistem Bu sistem geli tirilen sisteme örnek te kil etti i için daha ayrıntılı bir ekilde anlatılmı tır. GruSMA takımı, çok-etmenli bir sistem olan Sa lık Hizmetleri Servisleri ni tasarlamı ve geli tirmi tir. Geli tirilen sistem, HeCaSe, 2003 yılında uluslararası Agentcities Agent Technology yarı masında iki ödül almı tır (Moreno et al., 2006). AgentCities: Bir ehirdeki akıllı servislerle i birli i yapan açık sistemler için bir network olu turmayı hedefleyen bir Avrupa projesidir. Bu projenin geli tirilmesindeki asıl amaç; ehrin ziyaretçileri ya da vatanda larına müze, sinema, tiyatro veya kültürel etkinlikler hakkında bilgi veren servisleri sunan etmen tabanlı platformlar için bir network olu turmaktır. Bu proje kapsamında; HeCaSe olarak isimlendirilen bir sistem olu turulmu tur. HeCaSe; kullanıcılarına (bir ehrin vatanda ı veya ziyaretçisi) sa lık servisi sa layan etmen tabanlı bir sistemdir. Bu çok-etmenli sistem, bir bölgenin tıbbi merkezleri, departmanları ve doktorları hakkında bilgi sahibi olan etmenlerden olu ur (Isern et al., 2003). ekil 5.1 de sa lık bilgisi sunan bu çok-etmenli sistemin (HeCaSe) mimarisi görülmektedir.

116 90 ekil 5.1 HeCaSe Mimarisi (Isern et al., 2003) Bu çok-etmenli sistem 6 farklı etmen tipinden olu maktadır. Bunlar: Ki isel Etmen (Personal Agent-PA); Ki isel Etmen, kullanıcılara çoketmenli sisteme eri mek için grafiksel bir arayüz sa lar. Kullanıcılar bu arayüz vasıtasıyla sunulan servislere (sorgulama, randevu alma, tercihler, gündem gibi) eri ebilirler (Isern et al., 2003). Aracı Etmeni (Broker Agent-BA); Aracı Ermeni, sistemdeki di er etmenlerle Kullanıcı Etmeni arasında köprü görevi görür. Kullanıcı bir sorgu yapmak istedi inde bunu Aracı Etmeni (BA) vasıtasıyla gerçekle tirir. Sisteme

117 91 yalnızca eri imine izin verilen kullanıcıların girmesine izin verir (Isern et al., 2003). Bir tıbbi merkezdeki bilgi 3 katmanda tutulur. Her tıbbi merkezin yalnızca bir adet Tıbbi Merkez Etmeni (Medical Centre Agent-MCA), tıbbi merkezdeki her departman için bir tane olmak üzere Departman Etmenleri (Deparment Agent-DEP) ve her departmandaki her doktor için bir tane olmak üzere Doktor Etmenleri (Doctor Agent-DA) vardır. Tıbbi Merkez Etmeni; merkezin açılı tarihi, merkezin adresi gibi genel bilgileri tutar. Her Departman Etmeni, kendi departmanın bilgilerini tutar. Örne in göz hastalıkları departmanının tüm bilgisi gibi. Her Doktor Etmeni, verilen doktorun zaman çizelgesini tutar (Isern et al., 2003). Veritabanını Saran Etmen (DataBase Wrapper-DW); kullanıcıların sa lık kayıtlarından olu an bir veritabanına eri imi kontrol eder (Isern et al., 2003). Sistemin sa ladı ı servisler a a ıda sıralanmı tır (Moreno, 2003): Kullanıcı, belirli özelliklerde bir tıbbi merkez arayabilir. Örne in belirli bir ehirde bulunan ve Kalp hastalıkları departmanına sahip olan bir tıbbi merkez arayabilir. Kullanıcı, kendi sa lık kayıtlarına eri ebilir. Kullanıcı, kendi istedi i bir hastanede, kendi istedi i bir doktordan randevu alabilir. Muayene sırasında doktor, hastanın bilgilerine eri ebilir ve de i tirebilir. Sistem sa lık kayıtlarına güvenli bir ekilde eri imi garanti etmektedir. Yalnızca izin verilen kullanıcı ve doktorlar kayıtlara eri ebilir. Bunun için 3 katmanlı bir güvenlik mekanizması tasarlanmı tır (Moreno, 2003). 1. Sistem JADE in bir güvenlik plug-in i olan JADE-S kullanılarak gerçekle tirilmi tir. Böylece sistemdeki etmenler arasındaki tüm iletiler SSL (Secure Sockets Layer) kullanılarak ifrelenir. 2. Sistem ayrıca farklı tipte etmenlerin tanımlanmasına ve bu tipler için farklı haklar verilmesine izin verir. (Ki isel Etmen yalnızca Aracı Etmenden ileti alma ve gönderme hakkına sahiptir. Yani Ki isel Etmen, sistemdeki di er etmenlerin hiçbirine do rudan eri emez)

118 92 3. Sa lık kayıtları gibi, özel bilgi ta ıyan tüm iletiler genel bir anahtar ifreleme algoritması kullanılarak ifrelenir. Her hastanın ki isel verilerini (isim, adres, do um tarihi, meslek, gibi), sa lık bilgilerini (alerjileri, yetersizlikleri, tıbbi geçmi i, gibi), güvenlik bile enlerini (kullanıcı adı, ifre, gibi), zaman çizelgesini (randevu, hatırlatma, gibi) ve tercihlerini (doktorları, tıbbi merkezleri ve ehirleri sıraya koymak gibi) saklayan kendine özel bir profili vardır. Buradaki ilk üç bile en, doktorlar veya kullanıcı tarafından eri ilebilen ki isel kayıtların olu turulması için kullanılır. Zaman çizelgesi ve tercihler de randevu süreçlerini yönetmek için kullanılır. Zaman çizelgesi plug-in i, kullanıcı etkile imi için bir arayüz sa lar ( ekil 5.2). Bu arayüz sayesinde kullanıcılar randevu alabilir, randevularını kontrol edebilir, de i tirebilir ve silebilirler. Bu plug-in, randevu görü meleri süresince çizelgeyi yönetmek amacıyla hem Ki isel Etmenin hem de Doktor Etmeninin içerisinde bulunur (Isern et al., 2003). ekil 5.2 Zaman Çizelgesi Plug-in Arayüzü (Isern et al., 2003) Tercihler plug-in i bir çok alandaki tercihleri yönetmeye olanak tanır. Her alanın (sa lık hizmetleri gibi) kendine özel kriterleri vardır. Her kriter farklı de erler alabilir. Kullanıcı, alan içerisinde bulunan de erlere kendi tercihlerini

119 93 girmelidir (Tarrana=Best, Montblanc=OK, gibi). E er kullanıcı bir tıbbi merkeze gitmek istemiyorsa bu de eri Veto olarak belirleyebilir (Isern et al., 2003). Kullanıcı bir kere tercihlerini girdikten sonra plug-in, tüm kriterleri göz önünde bulundurarak önerileri sıraya koyar. Bu sıralama i lemini gerçekle tirmek için MCDM (Multi Criteria Decision Making) yöntemleri kullanılmı tır. Bu plug-in alınan önerileri sıraya koymak amacıyla Ki isel Etmen içerisinde gerçekle tirilmi tir. Randevu iste inden sonra alınan öneriler, kullanıcının girmi oldu u tercih kriterlerine göre (tedavinin yeri, doktorun veya tıbbi merkezin ismi, gibi) sıralanır (Isern et al., 2003). E er kullanıcı kriter içerisindeki de erleri bilmiyorsa (doktorların isimlerini ya da tıbbi merkezleri bilmiyorsa), plug-in her sorgu çalı tırılı ında yeni de erler üretir ( ekil 5.3). Her sorgudan sonra alınan önerilere yenilerini ekler. Bundan sonraki a amada kullanıcı yeni kriter de erlerini girebilir. Böylece bir sonraki aramada bu de erler de dikkate alınır (Isern et al., 2003). ekil 5.4 de önerilen ehirlerin, tıbbi merkezlerin, doktorların isimleri ve verilmi olan tercih de eri görülüyor. ekil 5.3 Bir Doktordan Randevu Almayı Sa layan Arayüz (Isern et al., 2003)

120 94 ekil 5.4 Tercih Plug-in i Arayüzü (Isern et al., 2003) Kullanıcı doktora gitmek istedi inde HeCaSe üzerinden randevu alabilir. Randevu alma süreçleri birçok etmenle görü me yapmayı gerektirir. Bu protokol ekil 5.5 de gösterilmi tir. Burada kullanıcı profiline uyan en uygun öneriyi gerçekle tirmek amacıyla veri en genelden en özel etmene yönlendirilir. ekil 5.5 Randevu Almak çin Uygulanan 4 Katmanlı CFP Protokolü (Isern et al., 2003)

121 Sa lık Alanında Etmen Teknolojilerinin kullanılması: GruSMA çalı ması (HeCaSe2) HeCaSe2 çalı masında, HeCaSe sistemi ile klinik yönergeler birle tirilmi tir. Klinik yönergeler (clinical guideline-cg) pratisyen hekimlere hasta tedavi kararlarını almalarında yardımcı olmak amacıyla kaydedilmi lerdir. CG ler doktorların, te hisin ve tedavinin tüm durumlarını ve bir sonraki adıma geçmeden önceki alınmı olan tüm bilgileri hatırlayamamalarından kaynaklanan hataları azaltmalarına yardımcı olurlar (Moreno et al., 2006). Sa lık kurulu ları CG leri kolay anla ılabilir, do rulanabilir ve yeni bir bilgi geldi inde kolay güncellenebilir formal bir dille yazarlar. Bu CG ler her tıbbi merkezin durumuna kolay uyarlanabilirler. Bu kadar yararına ra men CG lerin çok fazla kullanılmamasının nedeni; doktorların günlük i akı larına bu CG leri kolay entegre edilebilen araçlarının olmamasıdır. HeCaSe sisteminin yeni versiyonu olarak geli tirilen, HeCaSe2, hastalar üzerinde CG lerin uygulanmasına olanak tanır (Moreno et al., 2006). ekil 5.6 da sisteminin mimarisi gösterilmi tir. Burada daha önce geli tirilmi olan HeCaSe projesine ek olarak iki adet yeni etmen tipi göze çarpmaktadır. ekil 5.6 HeCaSe2 Etmen Tabanlı Sistem Mimarisi (Moreno et al., 2006)

122 96 Servis Etmenleri (Service Agents), mevcut olan klinik servislerin (kan tahlili, x-ray gibi) her biri için bir tanedir. Servisin zaman çizelgesini kontrol eder. Tıbbi merkezle veya özel bir departmanla ili kilidirler. Yönerge Etmeni (Guideline Agent), bir CG deposuna eri ir. Herhangi bir doktor bir hastayı muayene etti inde, doktor kesin bir hastalık te hisi koyabilir. Bu durumda, doktor kendi Doktor Etmenini kullanarak tedavi protokolünü ö renmek için Yönerge Etmenine soru sorar. Doktor Etmeni hastaya yönergeyi uygulamaktan sorumludur. Doktor Etmeni gerekti inde doktora uygun kanıtları sorabilir. Örne in; bir yönergeyi uygularken, Doktor Etmeni hasta hakkında bazı tıbbi verilere ihtiyaç duyabilir. E er tıbbi kayıtlar bu verileri içeriyorsa, Tıbbi Kayıtçı Etmeni bu verileri do rudan getirebilir. E er bu veriler bir testten elde edilecekse, kan tahlili gibi, Doktor Etmeni uygun Servis Etmenini bulmalı, onunla irtibata geçmeli ve hastanın test olabilece i mümkün olan en iyi zamanlamayı yapmalıdır. Test sonuçları elde edildi inde, Servis Etmeni bu sonuçları do rudan Tıbbi Kayıtçı Etmenine gönderir. Sistem sonuçları hastanın tıbbi kayıtlarının içinde saklar ve servisi isteyen Doktor Etmenine incelenen sonuçlarla birlikte bir ileti gönderir. Doktor Etmeni de uygun tıbbi yönergenin uygulamasını kaldı ı yerden devam ettirecek olan doktora haber verir (Moreno et al., 2006) Organ Nakil lemlerini Yönetmeye Yardımcı Bir Çok-Etmenli Sistem spanya daki hastanelerde organ nakil i lemlerinin yönetimini koordine etmek için ekil 5.7 de görüldü ü gibi bir çok-etmenli sistem tasarlanmı tır. Bu sistem çerçevesinde ülke her biri özerk eyaletlerden olu an 6 bölgeye ayrılmı tır. Örne in ekilde Z2 bölgesi 3 özerk eyalet içermektedir. ekilde görülen tüm etmenlerin farklı bilgileri ve farklı görevleri vardır (Moreno, 2003).

123 97 ekil 5.7 Çok-Etmenli Sistemin Mimarisi (Moreno, 2003) Bu çok-etmenli sistemde hiyerar iye ait olmayan 2 etmen daha vardır. Birincisi, Acil Durum Yönetisicidir (Emergency Coordinator). Çok kritik durumdaki nakil için bekleyen hastaların listelerini tutar. Bu hastalara kısa süre içinde nakil yapılmazsa hayatları risk altındadır (Moreno, 2003). kincisi, Tarihsel Etmen (Historical Agent); spanya da yapılan tüm nakillerin verilerini tutar. Bu bilgilerle tarihsel dosyalar olu turur ve istatistiklerini çıkarır (Moreno, 2003). Bir organ geldi inde, organı almaya en çok ihtiyacı olan hastanın mümkün olan en kısa sürede bulunması önemlidir. Bu arama i lemi için spanya da spanya modeli - Spanish Model olarak da bilinen bir model kullanılır (Moreno, 2003). Bu arama i lemi bir grup adımdan olu ur. lk adımda organı kullanabilecek acil hasta var mı diye kontrol yapılır. E er acil hasta yoksa, 2. adım olarak donörün bulundu u hastanede organ nakli için bekleyen hastalara bakılır. Burada da bir alıcı bulunamazsa 3. adım olarak, aynı ehirdeki di er hastanelere bakılır. E er alıcı bulunamazsa 4. adımda, aynı eyalet içerisindeki di er hastanelere bakılır. Yine bir alıcı bulunamazsa 5. adımda, aynı bölge içerisindeki di er eyaletler aranır. Bunda da bir alıcı bulunamazsa 6. ve son adım olarak, aynı ülke

124 98 içerisindeki di er bölgelere bakılır. Böylelikle organ nakil i lemi için en uygun alıcı bulunmaya çalı ılır (Moreno, 2003) PalliaSys: Özürlü Hasta Ünitesindeki Bilginin Yönetimi çin Çok- Etmenli Bir Sistem Bu bölümde PalliaSys projesi olarak bilinen çalı ma anlatılmı tır. Bu proje kapsamında özürlü hastaların bakımını arttırmak amacıyla bilgi teknolojileri ve çok-etmenli sistemler birlikte kullanılmı tır. Hastalar ölümcül bir hastalı ın ilerlemi evresinde olabilirler ya da ya lı ve engelli hastalar olabilirler. Bu hastalar; hastanelerdeki Özürlü Hasta Ünitelerinde (Palliative Care Unit-PCU), özel tıbbi merkezlerde veya kendi evlerinde olabilirler. Hastalar bulundukları yerlerin herhangi birinde doktorlar tarafından ziyaret edilirler (Moreno, 2003). ekil 5.9 da sisteme veri göndermek veya sistemden veri almak için kullanılan yöntemler ve sistemin mimarisi gösterilmi tir. ekil 5.9 PalliaSys Sisteminin Mimarisi (Moreno, 2003) PalliaSys sisteminin ana amaçlarından bir tanesi bakıma muhtaç hastaların bilgilerinin toplanması ve birle tirilmesini sa lamak ve aynı zamanda bu insanlara verilen bakımı arttırmaktır. Hastalarla ilgili bilgi, tıbbi merkezin Özürlü Hasta Ünitesinde bulunan merkezi bir veritabanında saklanır. Bu bilgi a a ıda anlatılan

125 99 yöntemlerle veritabanına eklenebilir, güncellenebilir ve izlenebilir (Moreno, 2003). 1. Birinci yöntem; genellikle evlerinde ya ayan hastalar veya yakınları düzenli olarak teknik olmayan verileri hastaneye gönderirler. Bu veriler; a rının derecesi, hastanın gücü, halsizlik, ba dönmesi, uyu ukluk, reçetelerini aldıkları son tarih veya aldıkları ilaçların miktarları eklinde olabilir. Bu verileri göndermek için hasta ve yakınları de i ik ileti im teknikleri kullanabilirler. Bunlar; Cep telefonlarından SMS iletileri göndermek Bir PC den standart bir iletisi göndermek Web sayfasında bulunan bir HTML (Hypertext Markup Language) formu doldurmak Tüm bu ileti im teknolojileriyle ili kili olan bir sunucu vardır. leti im Yöneticisi (Communication Manager) olarak ta bilinen bu etmen veriyi alır ve Veritabanını Saran Etmene (Data Base Wrapper) gönderir. Veritabanını Saran Etmen, PCU nun veritabanına eri imi kontrol eder (Moreno, 2003). 2. kinci yöntem; Ambient Intelligence paradigmasının kullanılması. PCU daki her hasta akıllı bir etmenin alıcılarına ba lıdır. Bu etmen hastayı görüntüler ve düzenli olarak leti im Yöneticisine (Communication Manager) rapor gönderir. leti im Yöneticisi Etmeni, PCU Yöneticisi (PCU Coordinator) adı verilen di er bir etmene bu veriyi iletir. PCU Yöneticisi Etmeni de bu hastadan sorumlu olan doktorla ili kili olan Doktor Etmenine bu veriyi gönderir (Moreno, 2003). 3. Üçüncü ve son yöntem; doktorlar özel tıbbi merkezlerde veya hastaların evlerinde bir muayene gerçekle tirirken PDA (Personal Digital Asistant) ta ırlar. Bu PDA üzerinde devamlı çalı an akıllı bir etmen vardır. Bu etmen muayene ile ilgili bilgileri sorar ve wireless olarak hastanın bilgilerini leti im Yöneticisine gönderir. leti im Yöneticisine da bu bilgiyi Veritabanını Saran Etmene gönderir. Veritabanını Saran Etmen de PCU nun veritabanına veriyi iletir (Moreno, 2003). Bu bilgi teknolojileri; hastalara ve doktorlara veri gönderme için de kullanılır. Bir hasta herhangi bir konuda bilgi almak istiyorsa; bilgi kanallarından birinden istekte bulunur. Örne in; kendi sa lık kayıtlarının bilgisine eri mek için

126 100 istekte bulunabilir. leti im Yöneticisi, Veritabanını Saran Etmenden gelen sorgu cevabını aldıktan sonra; bu bilgiyi bir SMS iletisi veya ile hastaya gönderir. Aynı zamanda e er bir doktor hasta muayenesi sırasında bilgiye ihtiyaç duyuyorsa; leti im Yöneticisi, bilgiyi doktorun PDA sı üzerinde çalı an etmene gönderir (Moreno, 2003). PCU mimarisinde gösterilen etmenler incelenecek olunursa: leti im Yöneticisi (Communication Manager); Çok-etmenli sistemin etmenleri ile sunucular arasında bir arayüz görevi görür ayrıca, PDA lar üzerinde çalı an Doktor Etmenlerinden ve hastaların durumlarını gösteren etmenlerden bilgiyi alır (Moreno, 2003). Veritabanını Saran (Data Base Wrapper); Bakıma muhtaç hastaların tüm bilgilerinin tutuldu u PCU veritabanına eri imi kontrol eder. Veritabanında saklanan tüm verilere eri ebilir ve ayrıca bu veriler için yapılan istekleri alır (Moreno, 2003). Doktor Etmeni (Doctor Agent); PCU daki her doktor için bir tane Doktor Etmeni (Doctor Agent) vardır. Bu etmen; doktorun masaüstü bilgisayarı üzerinde çalı ır. Etmen; doktorun hasta bilgilerini kolaylıkla elde etmesine, veritabanından özel verileri sorgulayabilmesine veya doktorun kendi zaman çizelgesini kontrol edebilmesine izin veren görsel bir arayüz sa lar. Örne in; evinde ya ayan bir hasta kendisini kötü hissediyor olabilir. Bu durumda hasta leti im Yöneticisine SMS veya yolu ile bir istekte bulunur. leti im Yöneticisi bu iste i PCU Yöneticisine gönderir. PCU Yöneticisi de veriyi sorumlu doktorun Doktor Etmenine iletir. Bu durumda Doktor Etmeni, doktorun zaman çizelgesinde doktorun ziyaret yapabilece i bo zamanı bulur ve bu bilgi aynı yoldan hastaya iletilir (Moreno, 2003). Hasta Etmeni (Patient Agent); her hasta için bir tane Hasta Etmeni (Patient Agent) vardır. Hastanın geli imini sürekli izlemekten sorumludur. Veritabanını Saran Etmen, hasta verisinde bir de i iklik oldu unda Hasta Etmenine haber verir. Bu etmen hastaların hastalık durumları hakkında düzenli olarak rapor göndermelerini kontrol eder. E er hasta rapor göndermeyi unutursa hastalara hatırlatma iletisi gönderir. Hastaların reçetelerinin yanlı takibini rapor eder. Doktorun yapaca ı ziyaretler için zaman çizelgesi tutar. E er bir Hasta

127 101 Etmeni zamanında gönderilmeyen bir rapor oldu unu veya hastalık derecesinin arttı ını fark ederse Doktor Etmenine hata iletisi gönderir (Moreno, 2003). Veri Analizcisi (Data Analyser); Veri Analizcisi, Veri madencili i (Data mining) ve Makine ö renme (Machine Learning) tekniklerinde uzmandır. Bu etmen Veritabanını Saran Etmen aracılı ı ile veritabanındaki verilere eri ir ve bu verileri hasta modelleri yaratmak için kümeleme gibi gözetmensiz makine ö renme tekniklerini kullanarak analiz eder. Bu etmen farklı türdeki hastaların geli mesini izleyerek bu hastaların gelecek durumları için önceden karar vermeyi sa layacak modeller geli tirir. Bu modeller tümevarımsal makine ö renme teknikleri kullanılarak olu turulurlar (Moreno, 2003) E-Tıp Sistemi Tasarlamak çin Bir Çok-Etmenli Yakla ım E-tıp, çok sayıda tıbbi süreç ve servisten olu ur. Çok-etmenli sistem yakla ımı, e-tıp sistemlerin karma ıklı ını çözmek için etkin bir yöntem olarak görülmü tür (Tian and Tianfield, 2003). Sistem geli tirmek için kullanılan bu çok-etmenli yakla ım olu ur (Tian and Tianfield, 2003). 4 adımdan 1. Etmen rollerini belirlemek 2. Bu roller için sorumlulukları ve servisleri belirlemek 3. Amaçları ve bu amaçlara ula mak için izlenmesi gereken planları belirlemek 4. Sistemin inanç (belief) mimarisini belirlemek. 2003): A a ıda e-tıp sistemi içerisindeki etmenler anlatılmı tır (Tian and Tianfield, Arayüz Etmenleri (Interface Agents); e-tıp sistemine yol gösterme ve klavuzluk sa larlar. Ki isel Etmenler (Personal Agents); Arayüz Etmenlerinin bir çe ididir. Bu etmenler kullanıcıya çok-etmenli sisteme eri im için bir grafiksel arayüz sa larlar. Bu arayüzle kullanıcıların sorgu yapabilmesini ve sorgu sonuçlarını görebilmesini sa larlar.

128 102 Aracı Etmen (Broker Agent): çok-etmenli sistemin tüm yetenekleri hakkında bilgi sahibi olan etmenlerdir. Kullanıcı, Aracı Etmen vasıtasıyla di er etmenlerle ileti im kurabilir ya da tüm etmenler arasında genel bir arama yapabilir. Doktor Etmeni (Doctor Agent): belirtilen doktorun zaman çizelgesini ve randevularını yönetir. Yönetim Etmeni (Administration Agent): görevlerin atanması ve departmanlar ve etmenler arasında i birli i sa lama gibi tıbbi yönetim i levlerini gerçekle tirir. Denetleyici Etmen (Controller Agent): tüm e-tıp sistemleri ve aracıları arasında kontrolü sa lar. Etmenler arasındaki çakı maları denetler. Departman Etmeni (Department): departmanın tüm bilgisine sahiptir ve departmandaki tıbbi ili kileri yönetir. zleme Etmeni (Monitoring Agent), Te his Etmeni (Diagnosis Agent), Tedavi Etmeni (Therapy Agent), Cerrahi Etmen (Surgery Agent), Danı ma Etmeni (Consultation Agent), E itim Etmeni (Training Agent) ve Kayıt Etmeni (Record Agent) departmandaki hastaların ve tıbbi verilerinin izlenmesi, te his, tedavi, cerrahi müdahale, danı ma, ve e itimi gibi i levleri yerine getirirler. Veritabanını Saran Etmen (Database Wrapper Agent): hastaların tıbbi verilerinin saklandı ı veritabanına eri imi denetler. Veritabanını Saran Etmen, Hasta Etmeni ve Doktor Etmeni arasındaki ileti imin tamamı ifrelidir. E itim Etmeni (Education Agent): en yeni tıbbi teknolojileri gerçekle tirir ve doktorlar veya e-tıp sistemindeki di er etmenler için e-ö renmeyi sa lar. Karar Destek Etmeni (Decision Support Agent): çok çe itli bilgileri birle tirirler ve Te his Etmeniyle beraber etkin karar yakla ımı sa larlar. Bir çok-etmenli sistem, toplum gibi dinamik bir sistemdir. Çok-etmenli sistem dı sal sistemlerle etkile im halindedir. Ayrıca çok-etmenli sistem içerisindeki etmenler de birbirleriyle etkile im içerisindedirler. Bu etkile imler ifreli veya ifresiz, dı sal ve içsel olabilir. Çok-etmenli sistemin etkile im modeli

129 103 içsel ve dı sal model olarak 2 ye ayrılır. E-tıp sistemdeki içsel etkile im sadece bir departmandaki etmenler arasında de il aynı zamanda farklı departmanlar arasındadır. E-tıp sistemdeki dı sal etkile im ise di er sistemlerledir. E-tıp sistem de, çok-etmenli toplum içerisindeki etmenler ekil 5.10 da gösterildi i gibi; denetleme, gerçekle tirim ve arayüz olarak üç gruba ayrılırlar. çsel ileti im; denetleme, gerçekle tirim ve arayüz grupları arasındadır. Dı sal ileti im ise; arayüz grubuyla çevre arasındadır. Çok-etmenli toplumun çekirde inde, hastalardan ve denetim grubundan gelen ihtiyaçları kar ılayan, gerçekle tirim etmenlerinin bulundu u gerçekle tirim grubu vardır (Tian and Tianfield, 2003). ekil 5.10 E-Tıp Sistemin Çok-Etmenli Toplumu (Tian and Tianfield, 2003) eker hastaları için teletıp-örnek bir çalı ma eker hastalı ı kandaki glikoz seviyesine ba lı olan kronik bir hastalıktır. Bu sa lık sürecini yönetmek için geli tirilen teletıp sistemi, hastanın gerçek zamanlı izlenmesini, hekime verilerin aktarılmasını ve daha sonra uygun bir tedavi seçilmesini sa layan tıbbi servisleri içerir. Bu servisler sırasıyla, zleme Etmeni, Veri leme Etmeni, Te his Etmeni, Tedavi Etmeni, Danı ma Etmeni, E itim Etmeni, Ar ivleme Etmeni, Departman Etmeni ve Arayüz Etmeni tarafından gerçekle tirilir (Tian and Tianfield, 2003). zleme Etmeni (Monitoring Agent); eker hastalarını gerçek zamanda gözlemler ve gözlenen verileri Veri leme Etmenine aktarır. Veri leme Etmeni (Data Processing Agent); gözlemlenmi verileri birle tirir ve bunlardan istatistik çıkarır.

130 104 Te his Etmeni (Diagnosis Agent); durumu de erlendirir ve hasta için uygun bir yargılama yapar, Tedavi Etmeni (Therapy Agent); uygun bir tedavi yöntemi tanımlar. Danı ma Etmeni (Consultation Agent); hastaların incelenmesi için danı ma sa lar ve Te his Etmeni ile ileti im halindedir. Karar Destek Etmeni (Decision Support Agent); karar deste i sa lar ve Te his Etmeni ile ileti im halindedir. E itim Etmeni (Training Agent); hastalara ilaçlarını nasıl alacakları ve kendilerine nasıl dikkat edecekleri konusunda e itim verir. Tedavi Etmeninin yöntemini kullanır. Ar ivleme Etmeni (Archival Agent); hasta kayıtlarını ve tedavi yöntemlerini kaydeder ve hastaların veritabanını günceller. Tıbbi veritabanı ile entegredir ve önemli veritabanlarını ifreler. Departman Etmeni (Department Agent); teletıp sisteminin denetimini gerçekle tirir. sa lar. Arayüz Etmeni (Interface Agent); arama servislerini ve bilgi servislerini ekil 5.11 de eker hastaları için geli tirilen çok-etmenli bir sistem olan teletıp sistemin mimarisi gösterilmi tir. Burada da sistem, arayüz, gerçekle tirim ve denetim olmak üzere 3 gruba ayrılmı tır;. Bu çok-etmenli sistemde; denetleme grubu i i belirler ve etmenler arasındaki çakı maları giderir. Arayüz grubu, hastalarla ve di er e-tıp servislerle ba lantıyı sa lar. Gerçekle tirim grubu ise, amaçlara ula mak için izleme, te his, tedavi, danı ma ve ar ivleme i levlerini yerine getirir (Tian and Tianfield, 2003).

131 105 ekil 5.11 Çok-Etmenli Sistem Mimarisi (Tian and Tianfield, 2003) Bu çoklu etmen sisteminde, içsel etkile imler teletıp süreçleri gerçekle tiren etmenler arasındaki birlikte i lerlik üzerine odaklanırken, dı sal etkile imler di er e-tıp sistemlerle entegrasyon üzerine odaklanır (Tian and Tianfield, 2003). ekil 5.12 de çok-etmenli sistem içerisindeki etkile imler gösterilmi tir. ekil 5.12 Çok-Etmenli Sistem çerisindeki Etkile imler (Tian and Tianfield, 2003)

132 106 ekildeki çift yönlü oklar etkile imleri göstermektedir. Kesikli çizgilerle gösterilen küçük elips teletıp sisteminin gerçekle tirim grubunun kapsamını gösterirken, büyük elips de teletıp sisteminin kapsamını göstermektedir. Ok 1 teletıp sisteminin çevreyle etkile imini gösterirken, ok 2 di er e-tıp sistemlerle etkile imini göstermektedir. Ok 3 teletıp sistemdeki gerçekle tirim grubunun denetim grubuyla etkile imini gösterirken, ok 4 arayüz grubuyla etkile imini göstermektedir. Ok 6; Doktor Etmeni, Ki isel Etmen ve Güvenlik Etmeni gibi e- tıp sistemin arayüz grubu ile Arayüz Etmeni arasındaki etkile imi gösterirken, ok 5 yönetim ve denetleme etmeni gibi e-tıp içerisindeki denetleme grubu ve Departman Etmeni arasındaki etkile imi göstermektedir. Gerçekle tirim grubunda Te his Etmeni önemli bir rol oynar. Te his i lemini karma ık bir i lem olmasından dolayı, Te his Etmeni sadece gerçekle tirim grubundaki di er etmenlerle etkile im halinde de ildir, aynı zamanda ok 7 ile gösterildi i gibi Karar Destek Etmeni, Klinik Etmen, E itim Etmeni ve Danı ma Etmeniyle de etkile im halindedir. 8 ile 17 arasındaki tüm oklar teletıp sistemin gerçekle tirim grubu içerisindeki etmenler arasındaki içsel etkile imleri göstermektedir. E itim Etmeni ok 18 de gösterildi i gibi Tedavi Etmeninin metotlarını gerçekle tirir. Ayrıca Ar ivleme Etmeni ok 19 da gösterildi i gibi veritabanı ile do rudan etkile im halindedir (Tian and Tianfield, 2003) Hintli Kırsal Bebek ve Çocuk Bakımı çin Çok-Etmenli Tıbbi Sistem Bu çalı mada, Hindistan ın kırsal alanlarındaki bebek ve 5 ya ından küçük çocuklar için, sa lık pratisyenlerinin klinik karar vermesine yardımcı olan bir çoketmenli sistem anlatılmaktadır. Devlet yeterli sayıda uygun çocuk doktoru olmamasından dolayı kırsal alanlara çocuk uzmanı atayamamaktadır. Yazılım etmenlerinin bu probleme gerçekçi bir çözüm getirece i dü ünülmü ve bu amaçla sa lık pratisyenlerine; küçük çocuk ve bebeklerin hastalıklarını te his etmelerinde, hastalıkları sınıflandırmalarında (a ır, orta, hafif) ve tedavi planını olu turmalarında yardımcı olması için bir çok-etmenli sistem geli tirilmi tir (Mago and Devi, 2007).

133 107 ekil 5.13 Sistemin Basit Mimarisi (Mago and Devi, 2007) Sistemin mimarisi ekil 5.13 de verilmi tir. A a ıda mimari detaylı olarak anlatılmı tır. Sa lık Pratisyenleri için GUI, PHC (Primary Health Care) pratisyenleri için arayüz sa lamak amacı ile geli tirilmi tir. A a ıdaki amaçlar için kullanılır (Mago and Devi, 2007). Akıllı Pediatrik Asistan (Intelligent Pediatric Assistant-IPA) tarafından yayımlanan hesap tanımlamalarını gösterir. Ana problemi, belirtilerini ve hasta çocu un gözlemlerini girmenizi sa lar. Bu bilgileri Kullanıcı Etmenine aktarır. Hastalı ın te hisini ve tedavi planını gösterir. Kullanıcı Etmeni (User Agent-UA): Bu etmen istemci tarafındaki arayüzle (GUI), sunucu tarafındaki Akıllı Pediatrik Yardımcı (IPA) arasında etkile imi sa lar. Kullanıcı Etmeni, Grafiksel Kullanıcı Arayüzünden ve Akıllı Pediatrik Yardımcıdan gelen iletileri anlamak için çocuk hastalıkları ontolojisini kullanır. Bu etmen GUI üzerinden yapılan sorgulamayı, insan müdahalesi olmadan karar verebilmesi için IPA ya aktarır. Bu etmen grafiksel kullanıcı arayüzü (GUI) ile birlikte PHC tarafında bulunur (Mago and Devi, 2007). Akıllı Pediatrik Yardımcı (Intelligent Pediatric Assistant-IPA); CHC (Community Health Care) tarafında bulunur. Kullanıcı Etmeni ile etkile im halindedir. Ana problemi alır ve hastalı a karar vermede ve tedavi planı

134 108 olu turmada yardımcı olacak ili kili sorular sorar. IPA ve Kullanıcı Etmeni, etkile imi sa lamak için ortak bir çocuk hastalı ı ontolojisi ve sözlü ünü kullanırlar. IPA, yardım arayan PHC pratisyenlerini görüntüleyebilmek için GUI ile etkile imdedir. IPA; Kullanıcı Etmeni tarafından sorulan sorulara cevap verir. Bu cevabın içerisinde do rudan insan müdahalesi olmaksızın karar verdi i hastalık ve uygun tedavi bilgileri bulunur. Bu davranı JADE kullanılarak gerçekle tirilmi tir (Mago and Devi, 2007). Pediatristler için GUI: IPA nın GUI si CHC de bulunan pediatristlere bir arayüz sa lamak için tasarlanmı tır. Burada, iste in yapıldı ı kırsal kesimdeki ko ulların gösterilmesi amaçlanmı tır. Ayrıca, belirli bir PHC de u ra ılan durumların toplam sayısını da göstermektedir (Mago and Devi, 2007). Kırsal kesimdeki sa lık pratisyenleri, Kullanıcı Etmeninin arayüzünü kullanarak kendilerini IPA ya kaydederler. Hesap tanımlaması IPA tarafından atanır. IPA da etkin durumda olan PHC ler görüntülenir. Kullanıcı Etmeninin arayüzünü kullanan PHC pratisyeni, çocu un adı, ya ı, ana problemi gibi bilgilerini girdi olarak verir. Kullanıcı Etmeni bu bilgileri IPA ya iletir. IPA sonuca ula madan önce daha fazla soru sorabilir. Ek soruları PHC pratisyeni cevaplar ve IPA ye geri gönderir. IPA bu bilgiler do rultusunda hastalı a te his koyar tedavi planını PHC pratisyenine bildirir (Mago and Devi, 2007). Böylelikle bebek ve çocuk hastalıkları konusunda uzman hekim bulunmamasına ra men çocuk için do ru te his ve tedavi yöntemleri uygulanmı olmaktadır SAPHIRE: Anlamsal Birlikte Çalı abilirlik Tabanlı Akıllı Sa lık Takibi SAPHIRE (Intelligent Healthcare Monitoring based on Semantic Interoperability Platform) projesi çerçevesinde akıllı sa lık takip ve karar destek sistemleri geli tirerek, kablosuz tıbbi algılayıcılardan elde edilen bilginin sa lık bilgi sistemlerine entegrasyonunu sa lamak amaçlanmı tır. Akıllı etmen teknolojisi ve bu etmenlerin davranı larını belirlemede kullanılan klinik uygulama yönergelerine dayalı olarak çalı an akıllı karar destek mekanizmaları sayesinde hasta takibi yapılır. Sa lık personeli geli tirilen bu akıllı karar destek sistemi ile birçok yatan, ayaktan ve evdeki hastalar için daha do ru kararlar verebilmekte ve bu hastaların daha iyi takibini sa layabilmektedir. Hasta tarafından bakıldı ında SAPHIRE ile

135 109 daha iyi tedavi ve evde bakım olana ı getirmektedir. Evde bakım uygulamalarında, ya lıların hayat kalitesinin artırılması, hastalıkların önceden te hisi ve sa lık harcamalarının azaltılması gibi faydalar sa laması beklenmektedir. ekil 5.14 SAPHIRE Projesinin Kavramsal Gösterimi (Hein et al., 2006) ekil 5.14 de SAPHIRE projesinin kavramsal bir gösterimi bulunmaktadır. Bu ekilde de gösterildi i gibi, projenin çekirde inde hastanede (ya da evde bakım senaryosu için dü ünülürse evde) bulunan hastalar vardır. Çe itli algılayıcılar hastalardan veri toplarlar. Bu algılayıcı verileri wireless olarak bir birlikte i lerlik platformuna aktarılır. Bu platform, MSHCP (Multi-Services HealthCare Platform) olarak isimlendirilmi tir. Etmenler bu verileri birle tirir ve de erlendirirler ve böylece hastanın durumunu için bir çıkarsama yaparlar. Akıllı Anlamsal Karar Destek Sistemi (Intelligent Semantic Decision Support System) bu verileri ve çe itli hastanelerden topladıkları hastanın eski verilerini kullanarak hastanın tedavisi için bir öneri getirir (Hein et al., 2006). SAPHIRE Klinik Karar Destek Sistemi, Klinik uygulama yönergelerini yaymak ve gerçekle tirmekten sorumlu olan bir çok-etmenli sistemdir. Bu sistem birbiriyle i birli i yapan bir grup etmenden olu ur (Laleci et al., 2006). Sistemin bile enleri ve aralarındaki etkile imler ekil 5.15 de gösterilmi tir.

136 110 ekil 5.15 SAPHIRE Çok-Etmenli Sistemi (Laleci et al., 2006) 2006): Her bir SAPHIRE etmeninin görevi birbirinden farklıdır (Laleci et al., Agent Factory Etmeni (Agent Factory Agent): hastaya bir yönerge tanımlaması bulur ve daha sonra, buldu u klinik uygulama yönergesini çalı tıracak olan Yönerge Etmenini yaratır. Hastane bilgi sistemleri içerisindeki i levleri gerçekle tiren tıbbi servisleri, algılayıcı servislerini ve hastanın Elektronik Hasta Kaydı (Electronic Health Record-EHR) dokümanlarının, doküman tanımlayıcılarını bulur ve böylece yönerge tanımlaması i lenmeye hazır hale gelir. EHR Etmeni (EHR Agent): SAPHIRE mimarisi içerisinde EHR Etmeni, hastanın Elektronik Sa lık kayıtlarına eri ilmesinde bir köprü görevi görür. EHR Etmeni EHR yi di er etmenlerden soyutlar. Ontoloji Etmeni (Ontology Agent): SAPHIRE sistemi içerisinde yönerge tanımlama a amasında, hasta verileri HL7 RIM i temel alan bir referans bilgi modeli ile modellenir. Bu da tıbbi Web servislerinin, algılayıcı verilerinin ve EHR dokümanlarının farklı referans modeli ve klinik terminoloji kullanmasına olanak tanır.

137 111 Yönerge Etmeni (Guideline Agent): klinik uygulama yönergelerini gerçekle tiren etmendir. Bu etmen, hasta için tanımlanan yönergeyi yönetir ve yönerge tanımında bulunan etkinlikleri gerçekle tirir. zleme Etmeni (Monitoring Agent): yönerge gerçekle tirilirken, yönergenin o anki durumu zleme Etmenine bildirilir. zleme Etmeni Klinik Pratisyenlerinin yönergenin gerçekle tirimini izleyebilmesi için bir arayüz sa lar. Alarm Yayma Etmeni (Alarm Distribution Agent): yönerge gerçekle tirimi tamamlandı ında, tıbbi pratisyenler veya gerekliyse hasta yakınları için çe itli alarmlar, duyurular veya hatırlatmalar yayımlamak gerekebilir. Bu gibi durumlarda alarm iletileri ve iletilerin ula tı ı bilgisi Alarm Yayma Etmenine bildirilir. Bu etmen alarm iletilerini, mümkün olan en etkin ve en güvenilir yöntemle gerekli alıcılara iletmek için tasarlanmı tır. SAPHIRE, biri hastane di eri evde bakım olmak üzere iki pilot uygulama kapsamında gerçekle tirilmi tir. Pilot uygulamalar, sensör verisinin, alarm sisteminin, elektronik hasta kayıtlarının, kılavuz ilkelerin do ru bir ekilde uygulamaya konulup konulmadı ını test etmektedir. Bükre Acil Yardım Hastanesi (Spitalul Clinic de Urgen Bucure ti), akut koroner sendromlu hastaların tedavisi için bu pilot uygulamayı geli tirmi tir. Böylece hastane ve ayaktan bakım ünitelerinin i yükü azaltılmaya çalı ılmı tır. nsan hataları asgariye çekilerek karma ık tanı tetkiklerinde, tedavi yöntemlerinde ve yo un bakımda geçirilen zaman azaltılarak sa lık harcamalarının dü mesine yardımcı olunması amaçlanmı tır. Evde bakım pilot uygulamasının amacı ise klinik bir kılavuz ilke modeli üzerine in a edilen karar-destek sistemi aracıyla, evde aralıklı olarak izlenen hastalardan gelen veriyi elektronik hasta kayıtlarıyla birle tirmektir. Revaskularizasyon (kalp hastalarına uygulanan bir tedavi yöntemi) tedavisi ertesi iskemi kalp rahatsızlı ı olan hastalar uygulama kapsamına alınmı tır. Bu pilot uygulama Almanya Bad Rothenfelde de Schuechtermann-Schillersche Klinik) hastanesinde yapılmı tır.

138 De erlendirme Tez çalı ması kapsamında önerilen mimari geli tirilirken, bölüm 5.1 de anlatılan HeCaSe sistemi referans alınmı tır. HeCaSe sistemi, tek bir platform üzerinde gerçekle tirilmi tir. Yani sistem tek bir bilgisayar üzerinde çalı maktadır. Ancak tüm hastaların bilgilerinin tutuldu u MedicalNet ve tüm randevuların tutuldu u Randevu Merkezi Etmenleri dü ünüldü ünde sistemin tek bir bilgisayar üzerinde olamayaca ı anla ılmı ve Randevu Merkezi Etmeni ve MedicalNet Etmeni için ayrı birer platform dü ünülmü tür. Daha sonra sistemin, küçük bir hastanede de il de farklı lokasyonlarda departmanları olan çok büyük bir hastane için de çalı ması gerekti i göz önünde bulundurularak Tıbbi Merkez Etmeni ve Departman Etmeni için de birer tane olmak üzere 4 farklı platformdan olu ması gerekti ine karar verilmi tir. Di er etmenlerden farklı olarak, Doktor Etmeni çalı tırıldı ında, ait oldu u departmanın içinde bulundu u platforma yeni bir içerici (container) olarak eklenir. Ayrıca Kullanıcı Etmeni de çalı tırıldı ında MedicalNet Etmeninin içerisinde bulundu u platforma yeni bir içerici olarak eklenir. Kısacası tez çalı ması HeCaSe Sisteminden farklı olarak, 4 farklı platform üzerinde çalı maktadır. Ayrıca HeCaSe den farklı olarak hasta verileri HL7 formatında aktarılır. Geli tirilen proje kapsamında, HL7 formatındaki verilerin ayrı tırmasını yapan kolay anla ılabilir bir yapı da önerilmi tir. Tez çalı masında; akıllı randevu alma a amasında tıbbi merkezler bulunurken, kullanıcıdan ba ımsız etmen etkile imleri gerçekle tirilir (Randevu Merkezi Etmenine kayıtlı randevuları sormak, MedicalNet Etmenine kayıtlı geli leri sormak, gibi) Ancak HeCaSe sisteminde randevu kriterlerini girme kullanıcıya (hastaya) bırakılmı tır. Kullanıcının kriter girebilmesi için, tıbbi merkezler ve doktorlar hakkında daha önceden bilgi sahibi olması gerekir. HeCaSe2 (bölüm 5.2) projesi, HeCaSe sistemi ile klinik yönergeleri birle tirmi ve Servis Etmenleri vasıtası ile laboratuvar, radyoloji gibi servislerden otomatik olarak randevu alma i lemini gerçekle tirmi tir. Tez çalı masının ilerleyen a amalarında, bu çalı ma örnek alınarak tez projesi geni letilebilir. Ancak u anda tez projesi içerisinde klinik yönergeler ve di er servislerden randevu alma ile ilgili i lemler gerçekle tirilmemi tir. Organ Nakil lemlerini Yönetmeye Yardımcı Bir Çok-Etmenli Sistem (bölüm 5.3) projesinde, çok-etmenli bir sistem geli tirilmi ve bu sistem uygun donörün bulunması i lemini gerçekle tirmi tir. Tez projesinden amaç olarak tamamiyle farklıdır.

139 113 PalliaSys: Özürlü Hasta Ünitesindeki Bilginin Yönetimi çin Çok-Etmenli Bir Sistem (bölüm 5.4) projesinde, özürlü hastaların daha iyi bakılabilmesi amacıyla bilgi teknolojileri ve çok-etmenli sistemler birlikte kullanılmı tır. Tez projesinde ise, çok-etmenli sistemler ile anlamsal web teknolojileri birle tirilmeye çalı ılmı tır. E-Tıp Sistemi Tasarlamak çin Bir Çok-Etmenli Yakla ım (bölüm 5.5) projesi, hastanın gerçek zamanlı izlenmesini, hekime verilerin aktarılmasını ve daha sonra uygun bir tedavi seçilmesini kapsayan i lemleri yapabilmek için geli tirilmi bir çok-etmenli sistemdir. Bu sistemdeki etmenler akıllı karar deste i sa layabilmek için birbirleriyle ileti im kurarlar. Hintli Kırsal Bebek ve Çocuk Bakımı çin Çok-Etmenli Tıbbi Sistem (bölüm 5.6) projesi, yeterli sayıda uzman çocuk doktoru bulunmayan kırsal kesimlerde pratisyenlerin küçük çocuk ve bebeklerin hastalıklarını te his etmelerinde, hastalıkları sınıflandırmalarında ve tedavi planını olu turmalarında yardımcı olması için bir çok-etmenli sistem geli tirilmi tir. Bu sistemde pratisyen, çocu un durumu ile ilgili verileri girer ve do ru karar verebilmek için uzman doktora danı ır. SAPHIRE; Anlamsal Birlikte Çalı abilirlik Tabanlı Akıllı Sa lık Takibi (bölüm 5.7) çalı masında, akıllı sa lık takip ve karar destek sistemleri geli tirerek, kablosuz algılayıcılardan toplanan bilginin sa lık bilgi sistemlerine aktarılması amaçlanmı tır. Sistem amacına ula mak için, etmen teknolojisini ve bu etmenlerin davranı larını belirlemede kullanılan klinik uygulama yönergelerine dayalı olarak çalı an akıllı karar destek mekanizmalarını kullanır. ncelenen çalı maların amaç ve kullanılan yöntem olarak tez projesinden farklı oldu u görülmektedir. Tez projesi, hasta bilgilerine eri im ve akıllı randevu alma i lemleri için anlamsal web ve etmen teknolojilerini kullanan çok-etmenli bir sistemdir.

140 114

141 SONUÇ Tez projesi çerçevesinde, anlamsal web ve çoklu etmen teknolojileri kullanılarak, tıbbi veri ileti imi ve akıllı randevu alma süreçlerini yerine getiren çok-etmenli bir sa lık bilgi sistemi geli tirilmi tir. Proje kapsamında özerk çalı an etmenlerle, doktorların sistem üzerinden hastanın eski verilerine eri ilmesine ve hastaların akıllı randevu alma i lemlerini yerine getirmelerine olanak sa lanmı tır. Ayrıca, etmenler arasında ortak bir terminoloji olu turmak amacıyla, JADE ontoloji ve içerik dili modeli kullanılarak Sa lık Ontolojisi adında basit bir ontoloji geli tirilmi tir. Geli tirilen çok-etmenli sistemde yer alan etmenlerin, randevu alma ve birbirlerine kayıtlanma süreçlerindeki ileti imlerinde bu ontolojiyi kullanmaları sa lanmı tır. Bunun yanı sıra, sisteme istenildi i anda yeni etmenler (MedicalNet ve Randevu Merkezi Etmeni hariç) eklenerek uygulama geni letilebilmektedir. Randevu sistemlerinin, hastaların ve sa lık personelinin zaman yönetimine yardımcı olmaları ve aynı zamanda hizmet kalitesi ve hasta memnuniyetini arttırmaları nedeniyle sektör içerisinde önemli bir yeri vardır. Bu nedenle geli tirilen randevu sistemlerinin etkin, kullanı lı ve kısa sürede çözüme ula tıran bir yapıda olması beklenmektedir. Herhangi bir tıbbi merkezden randevu almaya çalı an hastayı temsil eden ve onun yerine ilgili randevu i lemlerini yürüten yazılım etmenlerinin var olması, sistemin daha hızlı i lemesini ve i lemlerin mümkün oldu unca hasta yararına sonuçlanmasını sa layacaktır. A a ıda akıllı randevu i lemlerinde kullanılan yöntemler listelenmi tir: Bir kullanıcı sisteme ikinci defa giriyorsa; ya randevu tarihini unutmu tur, ya randevusunu iptal etmek istiyordur ya da farklı bir bran tan randevu almak istiyordur. Bu nedenle, ilk önce hastanın sistemde kayıtlı bir randevusu olup olmadı ına bakılır e er varsa; ba ka bir arama yapılmadan randevunun alındı ı tıbbi merkez ve doktor için sorgulama yapmasına izin verilir. E er kullanıcı aynı bran a sahip bir tıbbi merkeze daha önceden gitmi se; gene aynı tıbbi merkezdeki aynı doktordan randevu almak ister. Çünkü insanlar yeni bir tıbbi merkezde yeni bir doktora gitmek yerine alı ık oldu una gitmeyi tercih ederler. Bu nedenle, hastanın

142 116 sistemde kayıtlı olan eski bilgilerinin ö renilmesi gerekir. Bu bilgilerden hastanın istenilen bran a daha önceden gidip gitmedi i ö renilir. Böyle bir bilgi varsa aramaya devam edilmeden kullanıcının, o tıbbi merkezin o doktoru için sorgulama yapmasına izin verilir. Kullanıcı kendi sa lık sigortası ile anla malı olan tıbbi merkezden randevu almak ister. Bu nedenle di er tıbbi merkezler için sorgulama yapmasına gerek yoktur. Akıllı randevu süreçlerinde kullanılan bu yöntemlerle, tıbbi merkez arama i lemi için kısıtlar getirilmi ve böylece sistem performansı arttırılmı tır. Bilginin birlikte i lerlik problemi, verilerin farklı formatlarda veya farklı anlamlarda sunulmasından kaynaklanmaktadır. Bu problemi çözmek amacıyla hasta verileri HL7 formatında gönderilmektedir. Sistem doktorlar tarafından HL7 standartlarındaki hasta verisine eri ebilmeyi desteklemektedir. Doktorlara, hastanın eski verilerine eri ebilme olana ı verilerek hastanın tanı, te his ve tedavisinin daha kolay ve do ru bir ekilde yapılması sa lanmı olacaktır. Tez projesi kapsamında geli tirilen sistem, Sa lık-net ve Merkezi Hastane Randevu Sistemi içerisinde bulunan verileri kullanarak, randevu alma sürecinde hastalara ve sa lık kurumlarına birçok fayda sa layabilmektedir. Ayrıca doktorlara, Sa lık-net içerisinde bulunan hasta verilerine eri ebilme olana ı verilerek hastanın tanı, te his ve tedavisinin daha kolay ve do ru bir ekilde yapılması sa lanmı olacaktır.

143 ÖNER LER leri bir çalı ma konusu olarak; güvenlik konusu üzerine gidilip yeni kısıtlamaların getirilmesi dü ünülebilir. Örne in kullanıcıların (hastaların) sisteme girerken sadece kimlik numaralarını girmesi yeterli görülmeyip, sisteme her giri inde farklı olmak üzere, do um tarihi, telefon numarası, baba adı, annesinin kızlık soyadı, gibi ki isel sorular da sorulabilir. Aynı zamanda doktorların da sisteme giri i için de buna benzer sorular hazırlanıp do ru cevapları giren kullanıcıların sisteme eri imine izin verilebilir. Buna ek olarak, ba ka bir çalı mada; HeCaSe sisteminin gerçekle tirdi i güvenlik mekanizmaları, geli tirilen sistem için de eklenebilir. Kısaca; bir güvenlik plugin i olan JADE-S kullanılarak, sistemin tekrar gerçekle tirimi yapılabilir. Böylece sistemdeki etmenler arasındaki tüm iletiler SSL kullanılarak ifrelenebilir. Ayrıca, Kullanıcı Etmenlerinin sistemdeki di er etmenlere do rudan eri imi engellenip, bunun için bir Aracı Etmen tasarlanabilir. Böylelikle Kullanıcı Etmenleri sadece Aracı etmene eri ebilirler. Sa lık kayıtları gibi, özel bilgi ta ıyan tüm iletiler genel bir anahtar ifreleme algoritması kullanılarak ifrelenebilir. Ayrıca tez projesinde u anki a amada kullanıcıların sisteme giri i bir Java Aplet uygulamasıyla gerçekle mektedir. leride jsp (Java Server Pages) sayfalarıyla kullanıcıların sisteme giri i sa lanabilir. Böylece intenet olan her yerden sisteme eri im sa lanmı olacaktır. Bunun yanı sıra, tez çalı masının u anki durumunda, platform üzerinde çalı an etmenler arasındaki ileti im için, ileti im ontolojisi (sa lık ontolojisi) kullanılmaktadır. Bu ontolojinin kullanılabilmesi için etmenler arasında önceden bir anla manın yapılmı olması gerekmektedir. Kullanılan ileti im ontolojisinin zaman içinde de i ip geli mesi durumunda, de i en ontolojinin kullanılabilmesi için etmen yazılımlarının hepsinde güncelleme yapılması gerekmektedir. Bu sorunu çözmek için mimariye, ontoloji servisi benzeri bir yapı eklenip, kullanılan ontolojinin dinamik olarak güncellenebilmesi konusu da ba ka bir çalı manın konusu olarak dü ünülebilir. Böylece anlamsal olarak zenginle tirilmi bilgi tabanına yeni örnekler dinamik olarak eklenebilecek ve bilgi tabanında do rudan eri ilemeyen bilgilerin çıkarsama yoluyla elde edilebilmesi sa lanabilecektir.

144 118

145 119 KAYNAKLAR D Z N AGENT Consortium, Generalisation Modelling Using an Agent Paradigm, Project Report D A1, ESPRIT/LTR/ Antoniou, G., and Harmelen, F.V., 2004, A Semantic Web Primer, The MIT Press, England, 259p. Arslan,Y., 2008, Merkezi Hastane Randevu Sistemi, 2.Ulusal Sa lık Kurultayı, Antalya, yed2008/yakup_arslan_mhrs.pdf (Eri im tarihi: 3 A ustos 2009) Ate, A. F., 2008, Anlamsal Web ve Etmen Teknolojileri Kullanarak Katma De erli Telekomünikasyon Servisleri çin Bir Çerçeve Geli tirilmesi, Doktora Tezi, Ege Üniversitesi Fen Blimleri Enstitüsü, zmir. Bellifemine, F., Poggi, A. and Rimassa, G., 2001, Developing multi-agent systems with FIPA compliant agent framework, Software Practice and Experience, 31(2): pp. Bellifemine, F., Caire, G., Trucco T. and Rimassa, G., 2005, JADE Programmer s Guide, Italy, 27-58pp. Berners-Lee, T., 1999, Weaving the Web, New York:Harper Berners-Lee, T., Hendler J. and Lassila O., 2001, The semantic web, Scientific American, 284(5): 34-43pp. Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E. and Yergeau, F. (Editors), 2006, Extensible Markup Language (XML) 1.0 (Fourth Edition), W3C Recommendation, Braubach, L., Pokahr, A., Lamersdorf, W., 2004, Jadex: A Short Overview, Net.ObjectDays, AgentExpo, Caire, G., 2003, JADE tutorial JADE programming for beginners, 22p. Collis, J.C., Ndumu, D.T., Nwana, H.S., and Lee, L.C., 1998, The ZEUS agent building tool-kit, BT Technol J Vol 16 No. Dikenelli, O., Erdur, R.C., Gümü, Ö., Ekinci, E.E., Gürcan, Ö., Karda, G., Seylan,., and Tiryaki, A.M., 2005, SEAGENT: A platform for developing semantic web based multi-agent systems, Autonomous Agents and Multi-Agent Systems, 5(3):

146 120 KAYNAKLAR D Z N (devam) Dikenelli O., Erdur, R. C., Karda, G., Gümü, Ö., Seylan,., Gürcan, Ö., Tiryaki, A. M. ve Ekinci, E. E., 2006, Developing Multi Agent Systems on Semantic Web Environment Using SEAGENT Platform, Lecture Notes in Artificial Intelligence, Springer-Verlag, LNAI 3963, Do aç, A., 2008, E-Devlet Dokümanlarının Birlikte lerli ini Sa lamak, (Eri im tarihi: 3 Mart 2009) Do aç, A., and Çingil,., 2003, B2B e-commerce Technology: Frameworks, Standards and Emerging Issues, Chapter 4, (Eri im tarihi: 15 Nisan 2009) Elamy, A. H., 2005, Perspectives in agents-based technology, AgentLink News, 18: 19-22pp. Erdur, R.C., 2001, Yazılım Etmeni Teknolojisinin nternet Tabanlı Yazılım Yeniden Kullanımına Uygulanması, Ege Üniversitesi Fen Bilimleri Enstitüsü Bilgisiyar Mühendisli i Anabilim Dalı Doktara Tezi. Finin, T., Labrou, Y. and Mayfield, J., 1995, KQML as an agent communication language, (Eri im tarihi: 13 Nisan 2009), 22 p. FIPA, 2000, FIPA Abstract Architecture Specification, (Eri im tarihi: 18 Mayıs 2009), pp. FIPA, 2002, FIPA ACL Message Structure Specification, (Eri im tarihi: 18 Mayıs 2009), 11 p. FIPA, 2002, FIPA Agent Management Specification, (Eri im tarihi: 18 Mayıs 2009), 35 p. Georgousopoulos, C., and Rana, O.F., 2002, An approach to conforming a MAS into a FIPA-compliant system, Agents and Multi-Agent Systems, pp.

147 121 KAYNAKLAR D Z N (devam) Hein, A., Nee, O., Willemsen, D., Scheffold, T., Do aç, A., Laleci, G.B., 2006, SAPHIRE - Intelligent Healthcare Monitoring based on Semantic Interoperability Platform - The Homecare Scenario -, 1st European Conference on ehealth (ECEH 06), Fribourg,Switzerland, 1-3pp. IEEE, 1990, Institute of Electrical and Electronics Engineers, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, New York. Isern, D., Sanchez, D., Moreno, A. and Valls, A., 2003, HeCaSe: An Agent- Based System to Provide Personalised Medical Services, Tarragona, Spain, (Eri im tarihi: 7 Haziran 2009) JADE Tutorial, 2008, Application-Defined Content Languages and Ontologies, (Eri im tarihi: 9 A ustos 2009) Laleci, G.B., Do aç, A., Olduz, M., Ta yurt,., Yüksel, M., and Okcan, A., 2006, SAPHIRE: A Multi-Agent System for Remote Healthcare Monitoring through Computerized Clinical Guidelines. Luck, M., Ashri, R. and D inverno, M., 2004, Agent-Based Software Development, Artech House, USA, 208p. Luck, M., McBurney P., Shehory, O. and Willmott, S., 2005, Agent Technology: Computing as Interaction, A Roadmap for Agent Based Computing, AgentLink III, U.K. Komesli, M., and Ünalır, M.O., 2007, Anlamsal Co rafi Bilgi Sistemleri, Review of Social, Economic & Business Studies, Vol.9/10, Mago, V.K. and Devi, M.S., 2007, A Multi-agent Medical System for Indian Rural Infant and Child Care, Proceeding of the 20th International Joint Conference on Artificial Intelligence-07 (IJCAI-7), Hyderabad, India, pp. Moreno, A., 2003, Medical Applications of Multi-Agent Systems, Tarragona, Spain, (Eri im tarihi: 7 Haziran 2009) Moreno, A., Valls, A., Isern, D. and Sánchez, D., 2006, Applying Agent Technology to Healthcare: The GruSMA Experience, Tarragona, Spain.

148 122 KAYNAKLAR D Z N (devam) Mylopoulos, J., Kolp, M. and Giorgini, P., 2002, Agent-Oriented Software Development, In Proceedings of the 2nd Hellenic Conference on Artificial Intelligence (SETN-02), 15p. Poslad, S., Buckle, P. and Hadingham, R., 2000, The FIPA-OS agent platform: Open source for open standards, In Proceedings of PAAM 2000, 14p. Sycara, K.P., 1998, Multiagent Systems, AI Magazine, 19(2):79-92pp. Tıp Bili imi Derne i, 2006, HL7 Özet Bilgi Dokümanı, (Eri im tarihi: 6 A ustos 2009) Tian, J., and Tianfield, H., 2003, A Multi-agent Approach to the Design of an E-medicine System, MATES 2003, LNAI 2831, Springer-Verlag Berlin Heidelberg, 85-94pp. T.C. Sa lık Bakanlı ı B DB, 2008, Yeni Ba layanlar çin HL7 Kılavuzu (Sürüm 2.0), eni_baslayanlar_icin_hl7.pdf (Eri im tarihi: 6 A ustos 2009) Urgancıo lu, K., 2006, li kisel Veritabanı ile Ontolojiler Arasında Dönü ümün Gerçekle tirilmesi: Oracle 10G RDF Veri Deposu Üzerinde Örnek Bir Uygulama, Yüksek Lisans Tezi, Ege Üniversitesi Fen Bilimleri Enstitüsü, zmir. Vidal, J.M., Buhler, P.A. and Huhns, M.N., 2001, Inside an agent, IEEE Internet Computing, 5(1):82-86pp. Williamson, M., Decker, K., and Sycara, K., 1996, Unified information and control flow in hierarchical task networks, In Working Notes of the AAAI- 96 workshop Theories of Action, Planning and Control. Yurdakul,., 2007, Çokluortam Verilerinin Aranması ve Aktarılması çin Bir Çok-Etmenli Sistem Geli tirme, Yüksek Lisans Tezi, Ege Üniversitesi Fen Bilimleri Enstitüsi, zmir.

149 123 EKLER Ek 1 Sa lık Ontolojisinin Mimarideki Etmenler Üzerindeki Yeri Ek 2 Tıbbi Merkez Etmeni çerisindeki MedicalCentreOfferRequestsServer görevi Ek 3 HL7 formatındaki verileri ayrı tıran, kolay anla ılabilir bir yapı

150 124

151 125 Ek 1 Sa lık Ontolojisinin Mimarideki Etmenler Üzerindeki Yeri Bu bölümde, sa lık ontolojisinin mimarideki etmenler üzerindeki yerini anlatmak amacıyla etmenler tek tek ele alınıp incelenecektir. Etmenlerin ontoloji üzerinden hangi, aksiyon ve yüklemleri kullandıkları ve hangi davranı ları gerçekle tirdikleri, etmenlerin UML sınıf diyagramları verilerek anlatılacaktır. Tüm etmenler HealthcareInformationSystemVocabulary isminde bir interface i uygular. Bu interface sınıfı, etmenler arasında gönderilen iletilerin konu ma tanımlayıcısı (ConversationId) bölümlerindeki de erlerin tanımlandı ı sözlük niteli inde bir sınıftır. Bu sınıf içerisindeki kod içeri i örne i a a ıda verilmi tir. public static final String ADD_APPOINTMENT = "add appointment"; public static final String DELETE_APPOINTMENT = "delete appointment"; Burada kullanıcının yeni bir randevu iste i veya var olan randevusunu silmek için yolladı ı ileti içerisindeki konu ma tanımlayıcısı alanına eklenen de erler verilmi tir. Ayrıca tüm etmenler, HealthcareOntoloji isminde ontolojiyi tanımlayan singleton sınıfın bir örne ine sahiptirler. Bu sınıf JADE altyapısında tanımlanmı Ontology sınıfının geni letilmesi ile olu turulmu tur. Ek 1.1 Randevu Merkezi Etmeni Randevu Merkezi Etmeninin UML sınıf diyagramı ekil Ek 1.1 de verilmi tir. ekilde görüldü ü gibi etmenin, ontoloji içerisindeki MakeAppointmentOperationOnAppointmentCentre ve SearchPatientAppointments aksiyonları ile ili kisi vardır. Kendisine gelen iletiler yalnızca bu aksiyonlar eklindedir. Etmen ya am süresi boyunca, AppointmentCentreOfferRequestsServer isminde döngüsel bir davranı ı gerçekle tirir.

152 126 ekil Ek 1.1 Randevu Merkezi Etmeni UML Sınıf Diyagramı Ek 1.2 MedicalNet Etmeni MedicalNet Etmeninin UML sınıf diyagramı ekil Ek 1.2 de verilmi tir. ekilde görüldü ü gibi etmenin, ontoloji içerisindeki SearchPatientCases, SearchMedicalCentreAID, SearchAllMedicalCentres ve RegisterMedicalCentre aksiyonları ile ili kisi vardır. Kendisine gelen iletiler yalnızca bu aksiyonlar eklindedir. Etmen ya am süresi boyunca, MedicalNetOfferRequestsServer isminde döngüsel bir davranı ı gerçekle tirir. Ayrıca, içerisinde o anda sisteme kayıtlı olan tüm aktif tıbbi merkezlerin bir listesini tutar. ekil Ek 1.2 MedicalNet Etmeni UML Sınıf Diyagramı

153 127 Ek 1.3 Tıbbi Merkez Etmeni Tıbbi Merkez Etmeninin UML sınıf diyagramı ekil Ek 1.3 de verilmi tir. ekilde görüldü ü gibi etmenin, ontoloji içerisindeki MakeAppointmentOperation, MakeAppointmentOperationOnAppointmentCentre, RegisterMedicalCentre, RegisterDepartment, SearchDoctorsAppointments aksiyonları ve Contracts yüklemi ile ili kisi vardır. Etmen ya am süresi içerisinde, RegisterToMedicalNetAgent bir kereye mahsus görevini ve MedicalCentreOfferRequestsServer döngüsel görevini gerçekle tirir. Ayrıca, içerisinde o anda sisteme kayıtlı olan tüm aktif departmanların bir listesini tutar. ekil Ek 1.3 Tıbbi Merkez Etmeni UML Sınıf Diyagramı Diyagram üzerinde HealthCareInformationSystem isimli bir singleton sınıf bulunmaktadır. Bu sınıf, tıbbi merkez içerisindeki etmenlerin do rudan hastane bilgi sistemi veritabanına eri mesini engellemek amacıyla olu turulmu tur. ekil Ek 1.4 de bu sınıf için UML sınıf diyagramı gösterimi verilmi tir.

154 128 ekil Ek 1.4 HealthCareInformationSystem Sınıfı çin UML Sınıf Diyagramı ekilden de anla ılaca ı gibi HealthCareInformationSystem nesnesi gelen veritabanı iste ini (veri çekme, ekleme, silme, güncelleme) DBFacede nesnesine yönlendirir. DBFacede nesnesi de gelen istek tipine göre bir sınıf yaratır ve veritabanı iste i o sınıf üzerinden veritabanına i lenir. Ek 1.4 Departman Etmeni Departman Etmeninin UML sınıf diyagramı, ekil Ek 1.5 de verilmi tir. ekilde görüldü ü gibi etmenin, ontoloji içerisindeki RegisterDepartment, RegisterDoctor, MakeAppointmentOperation ve SearchDoctorsAppointments aksiyonları ili kisi vardır. Kendi Departman nesnesine (kavramına) sahiptir. Etmen ya am süresi içerisinde, RegisterToMedicalCentreAgent bir kereye mahsus görevini ve DepartmentOfferRequestsServer döngüsel görevini gerçekle tirir. Ayrıca, içerisinde o anda sisteme kayıtlı olan tüm aktif doktorların bir listesini tutar.

155 129 ekil Ek 1.5 Departman Etmeni UML Sınıf Diyagramı Ek 1.5 Doktor Etmeni Doktor Etmeninin UML sınıf diyagramı ekil Ek 1.6 da verilmi tir. ekilde görüldü ü gibi etmenin, ontoloji içerisindeki RegisterDoctor, MakeAppointmentOperation ve SearchDoctorsAppointments aksiyonları ili kisi vardır. Etmen ya am süresi içerisinde, RegisterToDepartmentAgent ve GetPatientInformationBehaviour bir kereye mahsus görevlerini ve ayrıca DoctorOfferRequestsServer döngüsel görevini gerçekle tirir. ekil Ek 1.6 Doktor Etmeni UML Sınıf Diyagramı

156 130 Ek 1.6 Kullanıcı Etmeni Kullanıcı Etmeninin UML sınıf diyagramı ekil Ek 1.7 de verilmi tir. ekilde görüldü ü gibi etmenin, ontoloji içerisindeki SearchPatientAppointments, SearchMedicalCentreAID, SearchPatientCases, SearchAllMedicalCentres, SearchDoctorsAppointments, MakeAppointmentOperation aksiyonları ve Contracts yüklemi ile ili kisi vardır. Etmen ya am süresi içerisinde; SearchSelectedMedicalCentreForDoctorsAppointmentsBehaviour, SearchRegisteredAppointmentBehaviour, MakeAppointmentOperationBehaviour, SearchMedicalNetForMedicalCentresAIDBehaviour, RequestForContractBehaviour ve SearchMedicalNetForMedicalCentresBehaviour bir kereye mahsus görevlerini gerçekle tirir. ekil Ek 1.7 Kullanıcı Etmeni UML Sınıf Diyagramı

157 131 Ek 2 Tıbbi Merkez Etmeni çerisindeki MedicalCentreOfferRequestsServer Görev çeri i A a ıda, Tıbbi Merkez Etmeni içerisindeki MedicalCentreOfferRequestsServer görevi ve bu görev içerisinde yaratılan i parçacı ının içeri i anlatılmı tır. Departman ve Doktor Etmenlerinin döngüsel görevlerinin iç yapıları ve görev içerisinde yaratılan i parçacı ı yapıları benzer olaca ından onlara tekrar de inilmemi tir. public void action() { ACLMessage msg = myagent.receive(); if (msg!= null) { if (msg.getinreplyto() == null) { threadid++; MedicalCentreThread medicalcentrethread = new MedicalCentreThread(threadID, msg); medicalcentrethread.start(); } else { StringTokenizer stok = new StringTokenizer(msg.getConversationId(), "&"); stok.nexttoken(); String tempid = stok.nexttoken(); MedicalCentreThread tempmedicalcentrethread = threadlist.get(tempid); if (tempmedicalcentrethread!= null) } tempmedicalcentrethread.receivemessage(msg); } } else { block(); } Sistem içerisinde Tıbbi Merkez Etmeni, (Departman Etmeni ve Doktor Etmeni de aynı ekilde) gelen iste i aldı ı ve cevapladı ı için sunucu, iste i di er bir etmene bildirdi i için istemci rolünü üstlenmi tir. Bu etmen, MedicalNet ve Randevu Merkezi Etmeninden farklı olarak, gelen iletinin InReplyTo bölümüne bakar; bo sa bir istek, doluysa kendisinin gönderdi i iste e bir cevap oldu unu anlar. E er ileti bir istekse (zaman çizelgesini ö renme, randevu alma veya silme, gibi), etmen içerisinde global olarak tanımlanmı threadid de eri arttırılarak bu de er ve iletiyle birlikte MedicalCentreThread tipinde bir i parçacı ı yaratılır. Bu

158 132 i parçacı ı ba ka bir etmene iletiyi iletme görevini yerine getirir. leti di er etmene iletilirken threadid de eri de eklenerek gönderilir. Bu de er, cevap geldi inde iletinin hangi i parçacı ı içerisinden gönderildi ini bulmak için kullanılır. E er gelen ileti, kendi gönderdi i iste in cevabı niteli indeyse; (MedicalNet ten istenen hasta bilgisi iste i gibi), iletinin konu ma tanımlayıcısı (ConversationId) bölümü ayrı tırılarak threadid de eri elde edilir. Etmen içerisinde bulunan i parçacı ı listesinden bu de ere sahip olan i parçacı ı bulunur ve çalı maya devam etmesi için receivemessage() metodu çalı tırılır. Bu metodun anlatımı akı ı bozmamak amacıyla bölümün sonunda verilmi tir. Üstte MedicalCentreThread isminde, Java da tanımlanmı Thread sınıfından türetilmi bir sınıfın varlı ından bahsedilmi tir. Konunun anla ılması açısından bu sınıfın daha ayrıntılı incelenmesinin gerekti ine karar verilmi tir. MedicalCentreThread sınıfının run( ) metodu kod içeri i a a ıdaki gibidir. public void run() { reply = msg.createreply(); if (msg.getperformative() == ACLMessage.REQUEST) { try { ContentElement content = getcontentmanager().extractcontent(msg); Concept action = ((Action) content).getaction(); if (action instanceof MakeAppointmentOperation) handlemakeappointmentoperation ((MakeAppointmentOperation) action); else if (action instanceof SearchDoctorsAppointments) handlesearchdoctorsappointments ((SearchDoctorsAppointments) action); else if (action instanceof RegisterDepartment) registerdepartment(getcontentmanager().extractcontent(msg)); } catch (UngroundedException e) { e.printstacktrace(); } catch (CodecException e) { e.printstacktrace(); } catch (OntologyException e) { e.printstacktrace(); } } else { if (msg.getperformative() == ACLMessage.QUERY_IF) handlecontractquery(msg);

159 133 else { StringTokenizer stok = new StringTokenizer(reply.getConversationId(), "&"); String tempconversationid = stok.nexttoken(); if (tempconversationid.equals (PATIENT_INFORMATION)) getpatientinformation(msg.getcontent()); } } } Metot içerisinde ilk önce iletinin i letimsel (performative) bölümüne bakılır. Bu bölümdeki de er iletinin; randevu alma veya silme iste i, doktorların veya belirli bir doktorun zaman çizelgesini ö renme iste i, departman kayıt iste i, tıbbi merkezin kurumla anla ması olup olmadı ını ö renme iste i veya hasta bilgilerini ö renme iste i olmasına göre farklılık gösterir. Farklı tipteki her istek için farklı bir i lem uygulanır. Tıbbi merkezin kurumla anla ması olup olmadı ını ö renme iste i haricindeki di er i lemler birbirine benzer oldu undan, örnek te kil etmesi bakımından sadece handlemakeappointmentoperation i leminin anlatılması uygun görülmü tür. handlemakeappointmentoperation() metodunun kod içeri i a a ıdaki gibidir. public void handlemakeappointmentoperation( MakeAppointmentOperation makeappointmentoperation) { IAppointment newappointment = makeappointmentoperation.getappointment(); if (medicalcentre.getdepartments()!= null) { for (int i = 0; i < medicalcentre.getdepartments().size(); i++) { if (newappointment.getdepartment().getdepartmentname().equals(((department) medicalcentre.getdepartments().get(i)).getdepartmentname())) { newappointment.setdepartment ((IDepartment) medicalcentre.getdepartments().get(i)); makeappointmentoperation.setappointment(newappointment); sendrequestfornewappointmentmessagetodepartmentagent(makeapp ointmentoperation); break; } } } }

160 134 Bu metot içerisinde Tıbbi merkeze gelen randevu alma veya silme iste inin öncelikle hangi departmana gönderilece i bulunur ve daha sonra sendrequestfornewappointmentmessagetodepartmentagent() metodu ça rılarak bu istek Departman Etmenine bildirilir. sendrequestfornewappointmentmessagetodepartmentagent metodunun kod içeri i a a ıda verilmi tir. public void sendrequestfornewappointmentmessagetodepartmentagent( IMakeAppointmentOperation makeappointmentoperation) { tempappointment = makeappointmentoperation.getappointment(); ACLMessage cfp = new ACLMessage(ACLMessage.REQUEST); cfp.setlanguage(codec.getname()); cfp.setontology(ontology.getname()); try { getcontentmanager().fillcontent(cfp,new Action(getAID(), makeappointmentoperation)); } catch (CodecException e) { e.printstacktrace(); } catch (OntologyException e) { e.printstacktrace(); } cfp.addreceiver(makeappointmentoperation.getappointment().getdepartment().getdepartmentaid()); cfp.setconversationid(reply.getconversationid() + "&" + id); cfp.setreplywith(reply.getconversationid()); myagent.send(cfp); if (threadlist == null) threadlist = new Hashtable<String, MedicalCentreThread>(); } threadlist.put(integer.tostring(id), this); Kodda da görüldü ü gibi, i parçacı ının tanımlayıcı (id) de eriyle beraber ileti, Departman Etmenine gönderilir ve i parçacı ı Tıbbi Merkez Etmeni içerisinde bulunan listeye eklenir. Gelen ileti, tıbbi merkezin kurumla anla ması olup olmadı ını ö renme iste i ise handlecontractquery() metodu ça rılır. Burada di er metotlardan farklı olarak istek ba ka bir etmene iletilmez. Do rudan cevap hazırlanıp Kullanıcı Etmenine bildirilir.

161 135 Daha önce de bahsedildi i gibi, cevap geldikten sonra cevabın hangi i parçacı ına ait oldu u bulunur ve o i parçacı ının receivemessage() metodu çalı tırılır. MedicalCentreThread sınıfı içerisindeki receivemessage() metodu kod içeri i a a ıda verilmi tir. public void receivemessage(aclmessage reply2) { StringTokenizer stok = new StringTokenizer(reply2.getConversationId(), "&"); String tempconversationid = stok.nexttoken(); String tempid = stok.nexttoken(); if (reply2.getperformative()!= ACLMessage.REFUSE) { if (tempconversationid.equals(patient_information)) { try { reply.setcontentobject(reply2.getcontentobject()); } catch (IOException e) { e.printstacktrace(); } catch (UnreadableException e) { e.printstacktrace(); } } else { if ((tempconversationid.equals(add_appointment)) (tempconversationid.equals(delete_appointment))) sendappointmentrequesttoappointmentcentre( tempappointment, reply2.getconversationid()); try { getcontentmanager().fillcontent(reply, getcontentmanager().extractcontent(reply2)); } catch (UngroundedException e) { e.printstacktrace(); } catch (CodecException e) { e.printstacktrace(); } catch (OntologyException e) { e.printstacktrace(); } } reply.setperformative(reply2.getperformative()); threadlist.remove(tempid); myagent.send(reply); } } this.stop(); Burada gelen cevabın konu ma tanımlayıcısı de erine göre bir i lem uygulanır. Örnekten devam edersek, cevap ya randevu silme ya da randevu alma iste i içindir. Bu nedenle sendappointmentrequesttoappointmentcentre() metodu ça rılır. Metodun kod içeri i a a ıda verilmi tir.

162 136 public void sendappointmentrequesttoappointmentcentre( IAppointment tempappointment, String conversationid) { ACLMessage cfp = new ACLMessage(ACLMessage.REQUEST); cfp.setlanguage(codec.getname()); cfp.setontology(ontology.getname()); IRegisteredAppointment registeredappointment = new RegisteredAppointment(); registeredappointment.setappointment(tempappointment); registeredappointment.setmedicalcentre(medicalcentre); IMakeAppointmentOperationOnAppointmentCentre makeappointmentoperationonappointmentcentre = new MakeAppointmentOperationOnAppointmentCentre(); makeappointmentoperationonappointmentcentre.setregisteredappointment(registeredappointment); try { getcontentmanager().fillcontent(cfp, new Action(getAID(), makeappointmentoperationonappointmentcentre)); cfp.addreceiver(getappointmentcentreagent()); cfp.setconversationid(conversationid); cfp.setreplywith(conversationid); myagent.send(cfp); } } catch (CodecException e1) { e1.printstacktrace(); } catch (OntologyException e1) { e1.printstacktrace(); } lem içerisinde gelen cevaba göre, iste i yapan etmene gönderilmek üzere bir ileti hazırlanır. Daha sonrada ileti yapan etmene iletilir. parçacı ı artık görevini tamamlamı tır. Bundan sonra, i paçacı ı, Tıbbi Merkez Etmeni içerisinde bulunan i parçacı ı listesinden silinir ve sonlandırılır.

163 137 Ek 3 HL7 Formatındaki Verileri Ayrı tıran, Kolay Anla ılabilir Bir Yapı Sa lık-net in tanımladı ı web servisleri kullanılarak elde edilen ileti sınıfı (MCCIIN000001TR01Message) içerisindeki bile enler (sınıflar) Component1, Component2,... diye devam etmektedir. Bu sınıf isimlerinden, yapılan i levin anla ılmasının mümkün olmadı ı görülmü, bu nedenle yeni bir yapı önerilmi tir. Bu bölümde, HL7 formatındaki verileri kullanıcıların veya programcıların daha kolay anlayabilmesi için, proje kapsamında geli tirilen, ayrı tırma mekanizmasına kısaca de inilmek istenmi tir. Doktor Etmeni sistemden hasta bilgilerini istedikten sonra, doktora cevap olarak hasta bilgilerinin tutuldu u bir liste döner. Bu listedeki sınıflar, serile tirebilir nesneler olan javax.xml.bind.jaxbelement tipindedir. Daha önce de belirtildi i gibi JADE etmenleri arasındaki ileti imde serile tirilebilir Java nesneleri kullanılacaksa; etmenler arasında gidip gelen nesnelerin, serile tirilebilir nesneler olması gerekir. Listedeki her bir nesne, verinin tipine göre ayrı tırma sınıfları (ExaminationDecoder veya InpatientDecoder) içerisine gönderilir. Bu ayrı tırma sınıfları içerisinde, veriler programcının anlayabilece i formata dönü türülür. Ayrı tırma i leminden sonra elde edilen nesneler, Doktor Etmeni içerisindeki listeye eklenir. A a ıda bu i lemin kod içeri i verilmi tir. private Vector<MedicalCase> decodemessage( Vector<javax.xml.bind.JAXBElement> messages) { Vector<MedicalCase> medicalcaselist = null; javax.xml.bind.jaxbelement object = null; if (messages.size() > 0) medicalcaselist = new Vector<MedicalCase>(); for (int i = 0; i < messages.size(); i++) { object = messages.elementat(i); if (object.getvalue() instanceof hl7.muayene.mcciin000001tr01message) { ExaminationDecoder examinationdecoder = new ExaminationDecoder((hl7.Muayene.MCCIIN000001TR01Message) object.getvalue()); medicalcaselist.add(examinationdecoder.getdecodeexamination()); } else if (object.getvalue() instanceof hl7.yatanhasta.mcciin000001tr01message) {

164 138 InpatientDecoder inpatientdecoder = new InpatientDecoder((hl7.YatanHasta.MCCIIN000001TR01Message) object.getvalue()); medicalcaselist.add(inpatientdecoder.getdecodeinpatient()); } } } return medicalcaselist; Konunun daha iyi anla ılabilmesi için, ayrı tırma i leminin nasıl yapıldı ı ve olu an Java sınıflarının içerikleri detaylı olarak incelenmi tir. Ayrı tırıcı sınıfları tiplerine göre Muayene (Examination) veya Yatan Hasta(Inpatient) sınıfını olu tururlar ( ekil Ek 3.1). Bu sınıfların iç detayları, ayrıntıya inilmeden sınıf diyagramları gösterilerek anlatılmaya çalı ılmı tır. Bu diyagramlar daha anla ılır olması açısından parçalanarak gösterilmi tir. ekil Ek 3.1 MedicalCase Sınıfı UML Sınıf Diyagramı ekilde, Tıbbi Kabul isminde bir üst veri tipinden türetilen Muayene ve Yatan Hasta tipinde iki sınıf gösterilmi tir. Tez projesinde örnek te kil etmesi açısından, Sa lık-net içerisindeki veri tiplerinden sadece ikisi incelenmi tir. Bu veri tipleri gelecekte tamamlanıp sistemin, tüm Sa lık-net verileri için çalı ması sa lanabilecektir. ekil Ek 3.2 de bir Muayene sınıfı için bir UML sınıf diyagramı gösterilmi tir.

165 139 ekil Ek 3.2 Muayene Sınıfı UML Sınıf Diyagramı ekil Ek 3.3 de Yatan Hasta sınıfı içerisinde tutulan nesneler gösterilmi tir. Burada da görüldü ü gibi, Muayene ve Yatan Hasta içerisinde test sonuçları ve reçete bilgilerinin tutuldu u veriseti sınıfları aynıdır. Yani aynı verileri içerirler. Di er veriseti sınıflarında ise; bazı bilgiler ortak, bazıları farklıdır. Bu nedenle, ortak bilgilerin tutuldu u sınıflardan ve o sınıfların geni letilmesi ile elde edilen veri tipine özel sınıflardan olu an, sınıf hiyerar ileri geli tirilmi tir. Ayrıca, veri tipleri içerisinde bir birinden farklı, Muayene veriseti (ExaminationMSVS) ve Yatan Hasta veriseti (InpatientMSVS) gibi, özel verisetleri de vardır. Bundan sonraki bölümde ilk önce Muayene ve Yatan Hasta için ortak olan verisetleri anlatılacak, daha sonra da özel verisetlerinden bahsedilecektir. ekil Ek 3.3 Yatan Hasta Sınıfı UML Sınıf Diyagramı

166 140 Ek 3.1 Hasta Kabul Veriseti ekil Ek 3.4, hasta kabul veriseti için UML sınıf diyagramı gösterimidir. Burada gösterilen ReceptionMSVS sınıfı, hasta kabul veriseti içerisinde ortak olan elemanların tutuldu u sınıftır. Bu sınıf içerisinde; SGK takip numarası (SocialSequrityFollowNumber), vaka türü (CaseType) ve sevk bilgisinin (ReferralInformation) tutuldu u bölüm vardır. Muayene ve Yatan Hasta için bu veriseti içerisindeki di er bilgiler farklılık gösterir. Örne in; Muayene için kabul tipi de eri tutulurken; Yatan Hasta için, kabulün protokol numarası, ödeme ekli, kabulü yapan doktor gibi bilgiler tutulur. ekil Ek 3.4 Hasta Kabul Veriseti UML Sınıf Diyagramı

167 141 Ek 3.2 Hasta Çıkı Veriseti ekil Ek 3.5 de Hasta Çıkı veriseti için UML sınıf diyagramı gösterilmi tir. Burada sevk tanıları ve çıkı bilgisi her iki veri tipi için ortaktır. Yatan Hasta veri tipi, Muayeneden farklı olarak çıkı a karar veren doktor bilgisini de içerir. ekil Ek 3.5 Hasta Çıkı Veriseti UML Sınıf Diyagramı Ek 3.3 Tetkik Sonucu Veriseti Tetkik sonucu veriseti için UML sınıf diyagramı ekil Ek 3.6 da verilmi tir. Bu veriseti, her iki veri tipi içinde ortaktır ve tetkik bilgisini (Test) içerir. Tetkik bilgisi içerisinde; tetkiki yapan doktor, i lem zamanı ve kurum bilgileri tutulur. ekil Ek 3.6 Tetkik Sonucu Veriseti UML Sınıf Diyagramı

168 142 Ek 3.4 Reçete Veriseti Reçete veriseti, reçete bilgilerinin tutuldu u verisetidir. Reçete veriseti için UML sınıf diyagramı ekil Ek 3.7 de verilmi tir. Bu veriseti içerisinde ilacın kullanımı hakkında bilgilerin tutuldu u ilaç bilgileri (MedicationInformation), reçete bilgilerinin tutuldu u (PrescriptionHeaderInformation) bölümü bulunur. Ayrıca reçeteyi yazan doktor ve konan tanılar gibi bilgilerde tutulur. ekil Ek 3.7 Reçete Veriseti UML Sınıf Diyagramı

169 143 Ek 3.5 Muayene Veriseti Muayene veriseti sadece muayene veri tipi içerisinde tutulur. ExaminationMSVS sınıfı, Muayene MSVS bilgilerinin bulundu u bir verisetini belirtir. ekilde Ek 3.8 de muayene veriseri için sınıf diyagramı verilmi tir. Bu veriseti içerisinde, rapor bilgileri (ReportInformation), müdahale bilgileri (ProcedureInformation), tanı bilgileri (Diagnosis), tetkik bilgileri (Test) ve poliklini in yeri, muayenenin ba langıç ve biti zamanı gibi muayene bilgileri (ExaminationInformation) tutulur. ekil Ek 3.8 Muayene Veriseti UML Sınıf Diyagramı

170 144 Ek 3.6 Yatan Hasta Veriseti Yatan Hasta veriseti, sadece yatan hasta veri tipi için tanımlanmı tır ve içerisinde Yatan Hasta MSVS bilgilerini tutar. ekilde Ek 3.9 da yatan hasta veriseri için sınıf diyagramı verilmi tir. Bu veriseti içerisinde, kullanılan malzeme bilgileri (UsedMedicalEquipmentInformation) ve dı etken bilgilerinin (OutherAgentInformation) yanında, muayene verisetinde de bulunan; müdahale bilgileri (ProcedureInformation) ve poliklini in yeri, muayenenin ba langıç ve biti zamanı gibi muayene bilgileri (ExaminationInformation) de tutulur. ekil Ek 3.9 Yatan Hasta Veriseti UML Sınıf Diyagramı