J Med Syst (2013) 37:9989 DOI 10.1007/s10916-013-9989-5
ORIGINAL PAPER
SAMS – A Systems Architecture for Developing Intelligent Health Information Systems Özgün Yılmaz & Rıza Cenk Erdur & Mustafa Türksever
Received: 24 July 2013 / Accepted: 8 October 2013 / Published online: 7 November 2013 # Springer Science+Business Media New York 2013
Abstract In this paper, SAMS, a novel health information system architecture for developing intelligent health information systems is proposed and also some strategies for developing such systems are discussed. The systems fulfilling this architecture will be able to store electronic health records of the patients using OWL ontologies, share patient records among different hospitals and provide physicians expertise to assist them in making decisions. The system is intelligent because it is rule-based, makes use of rule-based reasoning and has the ability to learn and evolve itself. The learning capability is provided by extracting rules from previously given decisions by the physicians and then adding the extracted rules to the system. The proposed system is novel and original in all of these aspects. As a case study, a system is implemented conforming to SAMS architecture for use by dentists in the dental domain. The use of the developed system is described with a scenario. For evaluation, the developed dental information system will be used and tried by a group of dentists. The development of this system proves the applicability of SAMS architecture. By getting decision support from a system derived from this architecture, the cognitive gap between experienced and inexperienced physicians can be compensated. Thus, patient satisfaction can be achieved, inexperienced physicians are supported in decision making and the personnel can improve their knowledge. A physician can diagnose a case, which he/she has never diagnosed before, using this system. With the help of this system, it will be possible to store general domain knowledge in this system
Ö. Yılmaz (*) : R. C. Erdur : M. Türksever Department of Computer Engineering, Ege University, Bornova 35100, Izmir, Turkey e-mail:
[email protected] R. C. Erdur e-mail:
[email protected] M. Türksever e-mail:
[email protected]
and the personnel’s need to medical guideline documents will be reduced. Keywords Health information system . Electronic health record . Multi-agent system . Decision support system . Reasoning . Ontology
Introduction The lately technological improvements in information technology (IT) have made a great impact on medical organizations. Today, health information systems are used in virtually every hospital. Health information technologies (HIT) are used mainly to increase efficiency, quality of service and to reduce costs in hospitals [1]. In a hospital information system, health records of the patients are stored electronically. If these patient data are shared then many benefits such as more reduced costs and more utilization can be achieved. By enabling the sharing of these patient records across different hospitals, the physicians will be able to access to a patient’s past records, comprehend a more detailed situation of the patient right away and take the timely actions. This might be crucial especially in emergency situations where the patient is unconscious and unable to talk to the diagnosing physician about his/her past medical past. Or again, in an emergency situation, the physician might need to view laboratory test results, before taking an action and by incidence if the patient had already taken the necessary tests during his/her previous visit to a hospital, then the physicians can take appropriate actions according to these test results without losing the precious time. Also there might be situations where a patient cannot describe his/her past medical experience completely. Sharing of patient records will also further reduce costs, spent time and maximize patient satisfaction, because all of the past information regarding the patient is accessible and there is no need for patients to store and bring medical images, test results, etc. with them.
9989, Page 2 of 17
SAMS architecture also includes a recommendation subsystem for physicians to assist physicians in decision making. Diagnosing a patient and making a decision on a treatment option is prone to errors even for experienced physicians. There are a huge number of factors other than patient’s medical status, such as age, gender, financial status and past medical information concerning the patient. Sometimes these might be ignored by physicians. A treatment option which is appropriate for a patient might not be appropriate for another patient showing the same symptoms. If this decision making process is automated by an expert system which can also learn from past experiences, then many benefits can be gained. By employing a rule-based recommendation system, domain knowledge is decoupled from the source code of the system. By defining new rules, new functionalities can be added to the system with ease without the need to change the source code of the programs. And hence a flexible and extensible system is developed. One shortcoming of expert systems is the lack of learning. In SAMS, this shortcoming is overcome by applying rule induction. In this paper, SAMS, a novel and original health information system architecture for developing intelligent and distributed health information systems is proposed. SAMS architecture can be adapted to other medical or dental specialties. Systems derived from SAMS architecture will act both as a health information system and a decision support system. A health system implementing SAMS architecture will be able to store electronic health records (EHR), share patient records among different hospitals and support physicians in decision making. The system is intelligent because the system is rule-based, makes use of rule-based reasoning and has the ability to learn and evolve itself. The learning capability is achieved by rule induction, extracting rules from previous given decisions by the users (physicians) and then adding the extracted rules to the system. Rule induction can be performed automatically by the system or manually with the intervention of the physicians. The system enables the physicians to construct their own rules. Learning capability is important because in some situations the system might not come up with any suggestions, or it might be required to go beyond the guidelines. These situations can be captured by the system implementing our architecture. Getting remote expertise from other hospitals is also possible in SAMS architecture. The proposed architecture is novel and original in all of these aspects. SAMS architecture is based on a semantic infrastructure. Patient records are stored in OWL (Web Ontology Language) [2] ontologies. Reasons for using ontologies are to provide high expressiveness, knowledge sharing, knowledge reuse and inference support. Medical guidelines are expressed using a rule language. This rule language can be SWRL (Semantic Web Rule Language) [3] or another language supported by the used inference engine. Decision support is provided by obtaining new facts from patient data by making inference using the defined rules.
J Med Syst (2013) 37:9989
For ontology manipulation, semantic web frameworks such as Jena [4] and OWL API [5] can be used. For inference, third party OWL reasoners such as FaCT [6], RacerPro [7], Pellet [8] and HermiT [9] can be used to make rule based reasoning. In addition to reasoning, SPARQL (SPARQL Query Language for RDF) [10] can be used to query ontologies. The advantage of SPARQL is that it is possible to use logical operators other than ‘and’ in SPARQL queries. SAMS architecture is a multi-agent system. In SAMS, we need software entities that are running in different computers, communicating with each other and showing proactive behavior. Software agents are software entities showing autonomous and proactive behavior, running in highly dynamic and complex environments [11]. Software agents are used in SAMS because there is need to software entities having agent characteristics. Also working environments of systems derived from SAMS are dynamic and complex. Agents are suitable for running in dynamic and complex environments such as SAMS. The software agents can be developed by using a third party agent development framework such as JADE [12], JADEX [13], JACK [14], and etc. As a case study, a system derived from SAMS architecture is developed for use by dentists in the dental domain. The use of the developed system is described with a scenario. For evaluation, the developed dental information system will be used and tried by a group of dentists. If new needs emerge during this pilot use then the system can be further improved by making modifications to the system. The subsequent sections of this paper are as follows. In next section, the most known standardization efforts about medical knowledge representation is presented. In “Motivation”, a motivating scenario is presented to show the benefits of SAMS architecture. In “SAMS”, SAMS architecture is described in detail. Employed strategies and techniques are discussed to maximize performance. Interactions between the agents are described according to the motivating scenario discussed in “Motivation”. In “Case Study”, as a case study, a health information system implemented for use in the dental domain is described. In “Related Work”, related research is surveyed. Research related to the medical knowledge representation and similar systems are reviewed. SAMS architecture is evaluated according to the related work. In “Conclusion”, conclusion is discussed.
Foundations of Medical Knowledge Representation Like in many fields of science, there are standardization efforts in medicine and medical information systems. These efforts include medical thesauruses and clinical coding systems which are used for classification and healthcare ontologies [15].
J Med Syst (2013) 37:9989
Medical thesauruses, clinical coding/classification systems are developed to provide compatibility and prevent redundancy and ambiguities related to medical terms [15]. Some of the mainly used coding and terminological systems are as follows: &
&
&
&
&
&
International Classification of Diseases (ICD): ICD is a classification system endorsed by World Health Organization (WHO). Latest version of this classification system is ICD-10. The ICD is the international standard used to classify diseases and other health problems recorded on health records and death certificates. These records are also used to compile national mortality and morbidity statistics by WHO member states [15, 16]. Unified Medical Language System (UMLS): UMLS is a system containing many health and biomedical vocabularies and standards from many sources to enable interoperability between software systems. The main purpose of UMLS is to make biomedical information, machine readable and machine-processable. UMLS also provides knowledge sources and software tools for developers to build health and biomedical information systems [17]. HL7 (Health Level 7) Standards: HL7 standards provide a framework for exchange, integration, sharing, and retrieval of electronic health information. These standards define information packaging and communication stating the language, structure and data types required for integration between systems. HL7 standards also support clinical practice and many perspectives such as management, delivery and evaluation of health services [18]. Logical Observation Identifiers Names and Codes (LOINC): LOINC is an initiative developed by Regenstrief Institute, which aims to facilitate the information exchange and pooling of results for clinical care, outcomes management, and research. LOINC codes are universal identifiers for laboratory and other clinical observations that are used in message fields for communication between different systems [19]. Clinical Terms Version 3 (CTV3): CTV3 is a version of Read Codes which is a standard terminology for describing the care and treatment of patients developed by James Read. CTV3 influenced SNOMED system, resulting in development of SNOMED CT [15, 20]. Systematized Nomenclature of Medicine - Clinical Terms (SNOMED CT): SNOMED CT is a clinical terminology started by the College of American Pathologists. It is now maintained by International Health Terminology Standards Development Organisation (IHTSDO). SNOMED CT improves health care by supporting the development of electronic health records that record clinical information in ways that enable meaning-based retrieval [15, 21].
Another approach to standardization is defining ontologies. Ontologies are shared conceptualizations describing a
Page 3 of 17, 9989
domain. Ontologies are superior to relational databases in terms of expressiveness. Ontologies are not just a taxonomy of concepts, but concepts, properties, constraints and relationships between the concepts in a specific domain. In this sense, ontologies are superior to classification systems. They also support knowledge sharing, knowledge reuse and inference using description logic and rules [15]. Some of the most widely known medical ontologies are as follows: &
&
& &
&
Generalized Architecture for Languages, Encyclopedias and Nomenclatures (GALEN): GALEN is a medical terminology server which supports the development of clinical coding schemes. This terminology is written in a formal language called GRAIL (GALEN Concept Representation Language) and also distributed in OWL [15, 22]. OpenEHR: OpenEHR is an open-source collaboration project which targets enabling information and communication technology to effectively support healthcare, medical research and other related areas. OpenEHR includes ontologies, terminology and a semantically enabled health computing platform in which medical knowledge can be represented and shared [23]. The Gene Ontology (GO): The Gene Ontology project provides an ontology of terms defining gene product properties across all species [15, 24]. The Open Biological and Biomedical Ontologies (OBO): The OBO Foundry is a collaborative effort which involves developers of science-based ontologies to establish a set of principles for ontology development with the goal of creating a suite of orthogonal interoperable reference ontologies in the biomedical domain [25]. The Foundational Model of Anatomy Ontology (FMA): FMA ontology provides an ontology which models human anatomy to be understandable by humans and computers. The FMA ontology can be extended to cover all other species. The FMA ontology makes anatomical information available to knowledge modelers and other application developers for education, clinical medicine, electronic health record, biomedical research and all areas of health care delivery and management. The goal is to provide consistency and standards in anatomical class representation [26].
In SAMS, medical domain is modeled using OWL ontologies for high expressiveness, knowledge sharing, knowledge reuse and inference support. In addition to these, ability to arrange medical terms into taxonomies is a great advantage. When developing ontologies for SAMS derived systems, we recommend taking these previous efforts into account. For example, ICD is a standard and ICD codes should be included in disease ontologies.
9989, Page 4 of 17
Motivation In this section, a motivating scenario for showing what SAMS architecture is capable of is presented. When a new patient comes, the physician enters patient’s identification number to the system using his/her computer and searches the system if there is any information previously entered to the system by other physicians from the same hospital or possibly from different hospitals. The physician finds that there is existing health information regarding the patient in other hospitals and downloads existing health information to the local data repository of the hospital. By doing this, the physician avoids entering duplicate data and wasting his/her and patient’s time. Now the physician is able to view all of the past medical information about the patient including previous test results, medical images and comments electronically, avoiding the need for the patient to bring this information with him/her. Then the physician enters current symptoms and any other information regarding the patient to the system. After the completion of entering data, the system might recommend the physician for the patient to take further diagnostic tests that might be needed. The physician might approve the recommendations or might give his/her decision. If the physician makes a decision which is not recommended by the system, the system captures the case as a rule by making rule induction. Rule induction can be performed automatically or manually aided by the physicians. The extracted rule is added to the system. Next time a similar case is encountered the system can make a recommendation obtained by this rule. The system gets the test results from the laboratory electronically without the need to be entered by the physician. After the analysis phase is completed, the physician can take expertise from the system for diagnosis and treatment. The physician can agree with the suggestions or he/she can make another decision which is not a suggestion. If it is the latter case, then again the system extracts rule(s) from this situation and adds the rule(s) to the system.
SAMS In this section, SAMS architecture is described in detail. The SAMS architecture is capable of fulfilling the scenario described in the previous section. A system, derived from SAMS architecture is an intelligent multi-agent system. Intelligence comes from the fact that system is a rule based system which has the learning capability. The main disadvantage of rule based systems is the lack of learning capability. This shortcoming is overcome in SAMS architecture by making rule induction. Modeling the Knowledge In SAMS, medical knowledge and data are stored in ontologies. Modeling a domain using ontology has many benefits
J Med Syst (2013) 37:9989
over traditional modeling schemes. First of all, ontologies are much more expressive than relational databases and XML Schema. In SAMS, it is recommended that ontologies are encoded in OWL (Web Ontology Language), because one of the ontology languages RDFS (RDF Schema) is more inferior to OWL and the other one DAML+OIL is obsolete. Ontology is a shared vocabulary. In an ontology, domain is described using classes (concepts), properties and relationships between these classes. The main benefits of ontologies are as follows: &
& &
Knowledge sharing: By using ontologies, computational entities such as software agents, services, etc. from different vendors have a common vocabulary while interacting with each other. Hence, semantic interoperability is achieved between different systems. Knowledge reuse: Ontologies created by different people and from different domains can be reused eliminating the need to start from scratch. Logical reasoning: Another advantage of modeling knowledge using ontology models is the reasoning capability. Reasoning based on Description Logic (DL) or rulebased reasoning (inference) can be accomplished. By reasoning over the ontology models, new facts can be obtained and inconsistencies can be eliminated. There are many proven inference engines such as FaCT [6], RacerPro [7], Pellet [8] and HermiT [9] which are ready to be used. SWRL can be used as a rule language. Some reasoners employ their own rule language. Also SPARQL (SPARQL Query Language for RDF) which can be more flexible than rules can be used to query ontologies.
In SAMS, large medical knowledge is decomposed into smaller ontology modules. Of course, medical knowledge can be modeled in a single ontology, but this is not practical in domains like medicine which is very complex and contains vast amount of information. Decomposing larger ontologies into smaller ontologies makes them flexible and easier to manage and update. Then the ontology modules can be integrated and they can constitute the whole domain [27]. The knowledge representation in SAMS is very flexible. The knowledge representation can be modified to meet certain criteria and needs of different medical specialties. A possible representation of medical knowledge in SAMS is shown in Fig. 1. The overall knowledge is decomposed into two dimensional orthogonal parts. One of the dimensions is the specialty. The general ontology is decomposed into medical specialties. The second dimension is the knowledge categories about a medical specialty. In Fig. 1 the specialty is decomposed into patient, domain, diagnose and treatment sub-ontologies. The sub-ontologies of the decomposed specialty and the granularity of this decomposition may vary. Individuals which are the instances of OWL classes are stored separately. Also rules are stored specific to each specialty. System rules are rules added
J Med Syst (2013) 37:9989
Fig. 1 Knowledge representation in SAMS
to the system by system administrator, and the inducted rules are rules extracted by the system from physician decisions. System and inducted rules are kept separately. In Fig. 1, patient ontology models the patient characteristics related to each specialty in addition to a general patient ontology. In some circumstances, a general patient model for some medical specialties might not be sufficient. For example, in some cases it might be needed to store information such as financial status, distance to hospital, psychological status, personal traits and etc. of the patient. Therefore, while not mandatory, a patient ontology specific to a specialty can be stored in SAMS. Medical domain ontology models the domain specific information except diagnostic concepts (diseases, defects, etc.) and treatment concepts. Diseases, defects and treatments are modeled in separate ontologies for flexibility and management reasons. For example, for the dentistry domain, domain ontology should model the teeth, their position, anatomy of mouth, blood vessels, etc. Of course, medical domain ontology can be further modularized into smaller parts. Diagnosis ontology models knowledge about anamnesis (patient story), symptoms, diseases, defects and etc. For example, information about a broken or missing limb is captured in this ontology. Finally, treatment ontology models knowledge about treatment options, prescriptions, complications, consultation and etc. Ontology manipulation and rule-based reasoning are very resource consuming tasks. Therefore it is better to apply some approaches to increase performance. For reasoning, one patient’s individuals can be replicated instantly in a memory stored temporary ontology and reasoning can be applied on this temporary ontology. This will definitely increase the performance of the system since only one patient’s information is taken care of in the reasoning process. Note that this doesn’t affect the outcome of the reasoning process because
Page 5 of 17, 9989
each patient’s information is independent from the other patients’ information. Current ontology manipulation APIs, such as Jena and OWL API, normally first load the ontology to main memory and then operate in main memory. If the ontology becomes very large, then random access memory might be insufficient. In this case, ontologies can be stored in relational databases. When working with database stored ontologies, there is no need to excess amounts of free memory. The main benefit of storing ontologies in relational database is that very large ontologies can be handled. The mentioned APIs also support storing ontologies in relational databases by their database back-ends [28, 29]. However, the inference performance of database stored ontologies is very poor. But this shortcoming can be overcome in SAMS by using the before mentioned temporary ontology approach. Hence inference performance of SAMS is immune to suffering when working with very large ontologies whether they are stored in random access memory or as a persistent ontology in a database. Alternatively to storing the ontologies in database, if the size of the individuals (patient instance data) becomes too large, clustering can be applied. Patient health records can be distributed across many inexpensive computers, provided that all of the individuals related to same patient are stored on the same computer. Then, when reasoning is needed, the cluster containing the patient’s individuals does the reasoning. This strategy is further discussed in the next subsection. Overview of the Architecture In this section, SAMS architecture is described. The general overview of SAMS architecture is shown in Fig. 2. Because our emphasize in here is to show the novel sides of SAMS, typical subsystems, a traditional health information system should have such as PACS (Picture Archiving and Communication System), registration, etc. is excluded from Fig. 2. SAMS architecture is a multi-agent system for building intelligent medical information systems. SAMS architecture can be adapted and applied to different specialties of medicine and dentistry. The systems derived from this architecture will be able to store electronic health records of the patients, share patient records amongst different hospitals and provide physicians local or remote expertise to assist them in decision making. Also the derived system will be capable of learning from physician decisions and the system will be able to evolve itself. In SAMS, the agents must be connected to each other over a network to communicate with each other. The hospital platform which is shown in Fig. 2 is distributed over a hospital compound. KB (Knowledge base) is composed of medical knowledge and patient information which is stored in modular ontologies and related files as described in the previous subsection. System rules and inducted rules are stored separately. The suggestions inferred from inducted rules are emphasized to the physicians. To provide
9989, Page 6 of 17
J Med Syst (2013) 37:9989
Fig. 2 A general overview of SAMS architecture
electronic health record sharing, the domain ontology models should be the same for every hospital. System rules and inducted rules may not be the same for every hospital. Knowledge base (KB), EHR (Electronic Health Record) agent, recommender agent, rule induction agent and hospital agent are all stationed on the hospital platform server. Hospital platform server can be constituted of multiple server computers to increase performance. Then agents and the KB of the hospital platform server can be distributed across different server computers according to aforementioned strategies. Of course, ensuring the security of the hospital platform server is crucial for the privacy of the patients. Each physician is assigned a physician agent. Each physician can be assigned to one computer or several physicians can share one computer to use their agents assigned to them. The sharing of electronic health records is shown in Fig. 3. For sharing electronic health records, a matchmaker agent is maintained in a remote computer. Two strategies can be employed here for sharing. One of the strategies is that, matchmaker agent stores information (agent identifier, date, time, etc.) about the hospitals which store a patient’s health records. When requested, matchmaker agent sends this information to requesting hospital agent. Then the hospital agent
Fig. 3 Sharing of electronic health records
can communicate with only the agents of these hospitals and download the patient’s past medical information. The other one is, matchmaker agent only stores the identifiers of the agents and when requested, sends a list of all of the hospital agent identifiers to the requesting agent. Then the hospital agent broadcasts a message to all agents inquiring past medical records of a patient. In SAMS, each physician is assigned a physician agent. Physician agent acts as an interface between the system and the physician. Knowledge acquisition is realized through the physician agent. Physicians can view, add, delete and update patient records, view patient’s records stored in different hospitals, synchronize a patient’s records with other hospitals and get expertise from the system by using the physician agent. Physician agents perform these tasks by communicating with EHR agent, recommender agent and hospital agent. Each hospital has a hospital agent running on a server computer. Hospital agent acts as a gateway between hospital platform agents (physician agents, EHR agent and etc.) in the hospital platform and other hospital agents. Hospital agent can retrieve information of the patients stored in different hospitals by communicating with other hospital agents. Hospital agents find agent addresses of the other hospital agents by querying matchmaker agent according to the employed strategy. Physician agents of a hospital should be able to communicate with the EHR agent in order to retrieve patient information kept in the other hospitals. EHR (Electronic Health Record) agent is directly responsible for viewing, adding, deleting and updating health records according to request messages from physician agents. Health records stored in other hospitals are also accessed through the EHR agent. Each hospital has exactly one EHR agent to satisfy concurrency. Recommender agent provides assistance to the physicians by making recommendations when requested. Recommender agent infers suggestions by making rule based reasoning using the rules and derives new facts from existing facts. If there are no suggestions or the physician makes another decision, the physician agent informs rule induction agent about this situation. Then
J Med Syst (2013) 37:9989
the rule induction agent extracts rule(s) from this new situation according to decision made by the physician. Getting remote expertise from other hospitals is also possible in SAMS. The physician can get remote expertise by making use of the rules of other hospitals. This is provided by sending a remote assistance request message including patient information to another hospital. The other hospital’s recommender agent extracts patient information from this message, makes inference using its own rules and sends back the results. Learning from past experience is achieved by the rule induction agent. Rule induction agent extracts rule(s), thus knowledge from decisions made by physicians, when requested by physician agent. This extracted knowledge is added to the inducted rules set. Rule induction can be performed automatically or manually. In automatic mode, there is no user (physician) intervention. The system handles everything with regards to related medical specialty domain. In manual mode, when the physician makes a decision, he/she indicates the individuals and literals in the ontology which he/she used to reason. So the rule induction agent can extract a precise rule set from this decision. Rule induction is a very important concept here. Especially in automatic mode where there is no physician intervention, there is a trade-off in how much general or specific the rules should be inducted with regards to physician decisions. If the rules are too general then most of the suggestions inferred from the rules will be irrelevant to the real life solutions. If the rules are too specific then they won’t cover every similar situation. This will increase the number of rules decreasing the reasoning performance. To overcome these problems during automatic rule induction, reviewing and then fine tuning the rules by a human expert can be performed. Actually recommender agent and rule induction agent running in the hospital platform could be stationed on physicians’ computers which would result in each physician having one physician agent, one recommender agent and one rule induction agent. This could increase the reasoning performance, because reasoning workload is divided between physician computers and now each physician computer is responsible for reasoning over one physician’s patients’ data. But this time security issues would emerge. In SAMS, knowledge-base and all of the agents except the physician agent are located in the hospital platform server for ensuring high security. As mentioned in the previous subsection, for increasing reasoning performance, a temporary ontology can be created containing related components and only the individuals related to the patient that will be reasoned. Then the reasoning can be carried out using this ontology which has fewer individuals than the original ontology containing all patient data. This will increase reasoning performance and work flawlessly because deducing recommendations for a person is independent from the other people’s information. To increase performance of the hospital platform server, the individuals that belong to patients can be divided into clusters in
Page 7 of 17, 9989
which all of the individuals related to a patient are in the same cluster. Then each data cluster can be handled by a different computer, each running EHR agent, recommender agent and rule induction agent. This configuration will again work flawlessly for the reasoning part because every individual related to a patient is on the same computer and a patient’s information is independent from the other patients’ information. Of course the rules must be shared by each computer or replicated. As a result, this will divide the knowledge base across many computers reducing total ontology size, consequently reducing the needed amount of free memory and eliminating the need to persistent ontologies which are stored in a relational database management system.
Agent Interactions In this section, interactions between the agents of a SAMS derived system are described in a interaction diagram as shown in Fig. 4 according to the scenario mentioned in “Motivation”. For communication, FIPA ACL messages defined by the FIPA [30] specification are used. Physician agent, EHR agent, recommender agent, rule induction agent, hospital agent and matchmaker agent interact with each other by exchanging ACL messages each corresponding to a communicative act. The detailed explanations of the messages in Fig. 4 are as follows: 1. When a new patient comes, physician enters patient identifier and requests his/her agent to retrieve any past medical information concerning the patient. The physician agent sends a request message containing patient identifier and operation type to EHR agent. Operation type can be “view”, “add”, “delete” or “update”. In this message, operation type is set to “view”. 2. EHR agent gets the request message sent by the physician agent, searches the knowledge base and responds to the physician agent by sending an inform message containing, if there is any, all of the information about the patient in the current hospital. When the physician agent gets this message, it extracts its contents and shows patient information to the physician, if there is any information in the message. 3. The physician wants to download and save medical information of the patient that is kept in other hospitals. The physician could also view medical information without saving them. So the physician requests this from his/her agent. The physician agent sends a request message to hospital agent stating this request. To accomplish this task hospital agent must find all of the hospital’s hospital agent identifiers (addresses). (Note: In this scenario broadcasting strategy mentioned in the previous subsection is used.) 4. Hospital agent queries the matchmaker agent for the identifiers of the hospital agents.
9989, Page 8 of 17
J Med Syst (2013) 37:9989
Physician agent
EHR agent
Hospital agent
Recommender agent
Rule induction agent
Matchmaker agent
Other hospital agent 1
...
Other hospital agent n
Request [1]
Inform [2]
Request [3] Inquiry [4]
Inform [5]
Request [6] Request [6]
Inform [7] Inform [8]
Inform [7]
Inform [9]
Request [10]
Inform [11] Request [12]
Inform [13]
Request [14]
Inform [15] Request [16]
Request [17]
Inform [18]
Request [19]
Inform [20]
Fig. 4 Interactions between the agents in SAMS architecture
5. Matchmaker agent replies hospital agent by sending an inform message containing the identifiers of the registered hospital agents.
6. Hospital agent now knows the identifiers of the hospital agents in the system. Hospital agent sends request messages to all of the hospital agents. Also authentication
J Med Syst (2013) 37:9989
7. 8. 9.
10.
11.
12.
13.
14.
15. 16.
17.
information (might be a password or biometric authentication can be used here) of the patient is included in this message. Other hospitals’ agents reply to the request by sending inform messages containing information that the patient gave permission for sharing. Hospital agent processes incoming messages and sends a request message to EHR agent for the addition of this information to the knowledge base. EHR agent informs physician agent when the information is added to the knowledge base and also sends this information to the physician agent. Physician agent processes this information and shows it to the physician. The physician can now view the patient’s past medical status. The physician examines the patient, asks questions and may be requests from the patient to take further diagnostic tests. Then the physician enters all of the collected facts (information) to the system with the aid of the physician agent. Physician agent sends a request message containing new facts for addition to EHR agent. EHR agent adds the new facts to the knowledge base and sends an inform message to the physician agent. When the physician agent receives this inform message, it updates its user interface and reflects the changes made to the physician. According to the scenario, the physician wants to get expertise (assistance) for diagnosing the patient from the system. So the physician, with the aid of his/her physician agent makes a request. The physician agent sends a request message to the recommender agent. Recommender agent makes rule-based reasoning and sends back a list of recommendations enveloped in an inform message. Physician agent extracts recommendations from the inform message and shows them to the physician. The user can then filter the recommendations. The physician doesn’t agree with the recommender agent and he/she enters his/her decision. Then the physician makes a save request from the physician agent. Physician agent sends a request message to the EHR agent for adding the diagnosis. EHR agent performs the addition and informs the physician agent about the outcome of this operation. Because the physician doesn’t agree with the recommender agent, the physician agent sends a rule induction request to the rule induction agent. This request can entail automatic (unsupervised) or manual (supervised) induction. The physician doesn’t want to supervise the induction process. So, the rule induction agent extracts the rule(s) automatically from user decision and adds them to the inducted rules. The physician has diagnosed the patient. Now the physician wants to get assistance for possible treatment
Page 9 of 17, 9989
options. The physician agent makes a treatment assistance request. The recommender agent again carries out the reasoning task. 18. The recommender agent completes the reasoning task and sends back to the physician agent a list of treatment options. 19. Finally, the physician chooses a treatment option from the list. The physician agent sends a request message to the EHR agent for adding the chosen treatment option. If the physician were to choose a treatment which is not in the list, then the rule induction agent would be notified about this situation by a request message for rule induction. 20. EHR agent sends back an inform message to notify the physician agent when the update operation is successful.
Case Study As a case study, a system for use by dentists is implemented conforming to SAMS architecture. This dental information system will be used in the hospitals in a pilot area. If new needs emerge during pilot use then the system can be further improved by making modifications to the system. The software agents are developed using JADE (Java Agent Development Framework) [12] and coded in Java programming language. The benefits of using a framework such as JADE are that it provides a ready communication infrastructure and behaviors. The Protégé-OWL API [31] is used to manipulate ontologies and make rule-based reasoning. The Protégé-OWL API is an open-source Java library for the Web Ontology Language. JESS [32] rule engine is used as a plug-in from Protégé-OWL API to make rule-based reasoning. The ontologies used by the system are developed using Protégé [33] ontology editor. As described in “Modeling the Knowledge”, the whole ontology is decomposed into smaller parts and they are developed separately. Then they are integrated to represent the whole knowledge base. Ontologies are encoded in OWL. As a rule language SWRL is used. As mentioned in “Foundations of Medical Knowledge Representation”, in an ontology, knowledge is expressed using classes, object properties, data properties and restrictions. Instance data is created by creating individuals from classes. Classes represent concepts. Object properties link individuals to individuals. Datatype properties link individuals to data values [34]. Restrictions can be applied on properties to mandate cardinality and value constraints. A general view of the whole ontology spanning different sub-ontologies is shown in Fig. 5. Some of the classes are omitted in this figure, because there are an enormous number of classes. Every Patient individual (individual derived from Patient class) must have exactly one PersonalInfo individual. This is mandated by using OWL restrictions. Every Patient
9989, Page 10 of 17
J Med Syst (2013) 37:9989 Class Patient
Domain
ObjectProperty
ObjectProperty
ObjectProperty
HasBodySystem
HasExamination
HasPersonalInfo
Range
Range
Range
Class
Class
Class
BodySystem
Examination
PersonalInfo
Class DigestiveSystem
subClassOf
subClassOf
Class
Domain
OralCavity
ObjectProperty HasDiagnosis Option
ObjectProperty
ObjectProperty
ObjectProperty
HasPatientModel
HasSymptom
HasTreatment
Range
Range
Range
ObjectProperty
ObjectProperty
ObjectProperty
HasAnamnesis
HasComplication
HasDiagnosis
Range
Range
Range
Class
Class
Class
Class
Anamnesis
Complication
Diagnosis
PatientModel
R an
ge
Class
Class
Symptom
Treatment
ObjectProperty HasTreatment Option Ra ng
e
subClassOf
subClassOf
subClassOf
Class DentalPatient Model
Class
Class
DentalDiagnosis
Disease
Class DentalTreatment
subClassOf
subClassOf
subClassOf
Class ClassificationOf PartiallyEdentulous Arches
Class SoftTissueRelated Diagnosis
Class
Class
DentalDisease
SystemicDisease
Class ToothRelated Diagnosis
Class BoneRelated Treatment
Class SoftTissueRelated Treatment
Class ToothRelated Treatment
Class BoneRelated Diagnosis
Fig. 5 A general view of the whole ontology
individual can have zero or more BodySystem and Examination individuals. BodySystem class models human body parts, organs, tissue, vessels and etc. constituting a concept hierarchy. For example, OralCavity is a subclass of DigestiveSystem which is a subclass of BodySystem. An Examination individual is related to zero or more Anamnesis, Complication, Diagnosis , PatientModel , Prescription , Symptom , Treatment , X-
RayExamination individuals. All these concepts are modeled as classes and linked using object properties for flexibility and extensibility reasons. HasDiagnosisOption and HasTreatmentOption object properties are used to provide assistance to the physicians. Possible diagnosis and treatment recommendations are listed to the physicians as the range individuals of these properties. These recommendations are
J Med Syst (2013) 37:9989
inferred from the rules in the system. Similar to BodySystem class, Diagnosis and Treatment classes should have subclasses forming diagnosis and treatment hierarchies. To provide a generic health information system solution, the system is immune to ontology changes. Graphical user interface of the data entry panels of the system is created on the fly by traversing the used ontology structure and GUI (Graphical User Interface) is not dependent on the used ontologies. The declaration of the properties which are supposed to provide assistance is achieved by using annotations. @provides_assistance keyword should be added as a comment to object properties which will be providing assistance. Currently the physician can get recommendation for diagnosis and treatment through evaluating the ranges of HasDiagnosisOption and HasTreatmentOption properties. If this system were to be used with another medical specialty where there are different properties to be assisted in the ontology, then the system administrator could adapt the system by simply adding @provides_assistance comment to the properties providing recommendations. Additionally, figures can be displayed and shown to the users in the data entry frames. Relevant information is shown to the user drawn on the figure and also through tool tip texts. This is achieved by providing figure information as comments in ontology classes. As a start, a total of 28 SWRL rules are defined and added to the system which provides recommendations for dental treatment. To use the system, the physician logs into the system with his/her user name and password. The physician can search patients’ electronic health records using the search window. Search window is shown in Fig. 6. Simple and detailed search is available. The physician can search local and remote patient Fig. 6 Search window
Page 11 of 17, 9989
records. Local records are records that are kept on the local server of the hospital. Remote records are records which are stored on different hospital servers. The physician can access only records which he/she has access rights. The search results are listed on the right panel. Then the physician can view both local and remote medical records of a patient which he/she has access rights, but can only make changes on the local records if he/she has authorization for editing the record. The remote records are read-only. The physician can import shared remote records to the local server by choosing one of the synchronization options. The physician can import only personal information of the patient from the chosen hospital, all information from the chosen hospital or all of the information in all of the hospitals registered in the system. Also partial information (ontology individuals) about a patient can be downloaded and saved to local server during viewing the patient records without the need for a full synchronization. A knowledge acquisition window for an instance is shown in Fig. 7. The physician can edit patient records using these windows. As mentioned earlier, a knowledge acquisition window represents an instance (individual) of an ontology class and knowledge acquisition windows are created dynamically. All of the properties and their values are listed in the knowledge acquisition window. The physician can add an existing instance as a property value, create and add a new instance as a property value and remove a property value instance. Added property value individuals can be viewed and changed by double clicking. Also cardinality constraints are checked and if the cardinality constraints are not met, then this situation is emphasized to the user by showing a red border around the related property.
9989, Page 12 of 17
Fig. 7 Knowledge acquisition window for an instance
Knowledge acquisition windows can contain figures as mentioned earlier. The user can get information through tool tip texts from the figures by hovering mouse over the related part of the figure. Instances are named automatically by the system without user intervention to guarantee uniqueness. A naming scheme is adopted for this reason. Every instance name starts with the name of the instance it is related to, if there is any. After that the name of the class it is derived from and a number is added. This naming scheme guarantees uniqueness and also the generated instance names are self-explanatory. Teeth can be created automatically by the system. This functionality is added because it is a time consuming task to create 32 teeth and defining positional relations among them. Changes can be made to the teeth individuals after the teeth are created automatically by the system. A Scenario In this section, the developed system will be illustrated with a scenario where a physician enters patient information just after the oral diagnose of the patient and gets assistance from the system. The teeth in human oral cavity are shown in Fig. 8.
J Med Syst (2013) 37:9989
The teeth shown in the figure are named according to the twodigit FDI (World Dental Federation) notation. This notation is also used in the developed ontologies. According to the scenario, the dentist diagnoses a patient with teeth numbered 14, 15 and 16 as missing. These 3 teeth are the teeth consecutive to the canine tooth (tooth numbered 13 in the figure). The dentist creates a new examination individual for the patient and enters the missing teeth as diagnosis to the system. After the dentists clicks “Get Assistance” button, possible treatment options are listed to the dentist associated with HasTreatmentOption property as shown in Fig. 9. There are 2 recommendations. One of them is removable partial denture and the other one is dental implant. The dentist discards the recommendations and enters dental bridge as treatment which is not listed. Usually when there are 3 missing consecutive teeth, dental bridge is not applicable, but because one of the abutment teeth is canine tooth which has a strong root, dental bridge can be applied. When the dentist clicks the save button, the system realizes the need to adapt itself to this new circumstance and starts the rule induction process. The dentist is asked if he/she wants to help rule induction process. If the dentist is willing to participate, a dialog window for each to be assisted rule appears. This dialog window, as shown in Fig. 10, contains a tree view of the patient individual and all of the related property values represented as check boxes. The dentist participates by choosing the values he/she used to come to this decision. Equality and comparison operators can be used during this process. For this scenario the dentist chooses the facts that the canine tooth is healthy and has 3 consecutive missing teeth and 1 healthy tooth. A part of this selection is shown in Fig. 11. If a class assertion for an individual isn’t needed in the rule body (meaning that an individual can be created from any class), the user should tick the “Ignore OWL Class” check box node under that OWL individual’s name. In this case, the user wants this rule to be applied to any canine tooth (tooth numbered 13, 23, 33 or 43). So he/she ticks “canine” and also ticks “Ignore OWL Class” check box under sams:Patient3_OralCavity1_T13_1 node in Fig. 11. As one can see in the rule body below, there isn’t such a term as sams:T13(?Patient_3_OralCavity_1_T13_1) . In fact all of the teeth classes should be ignored, because neighboring relations among the teeth are used in the antecedent of the will be inducted rule. Absolute numbered teeth names are not used to get a more generic rule. For this case, the inducted SWRL rule under the dentist supervision is shown in Table 1. If the dentist denies supervising the rule induction process, then rule induction is carried out automatically. The inducted rule without the dentist supervision is shown in Table 2. As one can see, names of the individuals are used as variable names in the inducted rules. The former inducted rule is more general than the latter. The former rule encapsulates situations regarding all 4 of the canine teeth (teeth numbered 13, 23, 33, and 43 in Fig. 8) in the oral cavity. On the other
J Med Syst (2013) 37:9989
Page 13 of 17, 9989
Fig. 8 Human teeth
hand, the latter rule encapsulates the situations regarding only canine tooth numbered 13. The system enables the physicians to construct their own rules which is a great advantage.
Related Work In this section, related work are reviewed and compared to SAMS as shown in Table 3. There are related works [15, 35–40] which use OWL ontologies in the medical domain. Some of them [36–38] also use rules in addition to using OWL ontologies. But these systems lack some characteristics such as learning from experience, sharing of patient records in comparison to SAMS. Pathak et al. [27] survey modular ontology techniques and their applications in the biomedical domain. It is discussed
Fig. 9 The user gets recommendations from the system
that knowledge, especially medical knowledge stored in ontologies are continuously becoming complex and very large in size. As a solution to this problem, it is concluded that large ontologies should be divided into smaller parts and handled modularly. In modular ontology techniques, the emphasis is on either extracting and managing modules of an ontology (ontology decomposition) or developing them independently and integrating independent modules into a larger ontology (ontology composition) [27]. In SAMS, the modular ontology technique is used. Kiani et al. [35] present a system for ontology-based negotiation of dental therapy options. Negotiation is a process which involves many people and opinions. A lot of possible decisions should be evaluated by the decision makers and this is a time consuming sophisticated task. As a solution to this problem, authors suggest ontology-based negotiation. In this
9989, Page 14 of 17
J Med Syst (2013) 37:9989 Table 1 Inducted rule with dentist supervision sams:Patient(?Patient3) ^ sams:HasExamination(?Patient3,?Examination_3) ^ sams:Examination(?Examination_3) ^ sams:HasDiagnosis(?Examination_3,?HealthyTeeth) ^ sams:HealthyTooth(?HealthyTeeth) ^ sams:HasDiagnosedTooth(?HealthyTeeth,?OralCavity_1_T13_1) ^
Fig. 10 Rule induction assist window
work, semantic web concepts such as ontologies and semantic reasoning are employed to implement a system to facilitate negotiation. The target domain of the project is negotiation of dentists over the treatment of wisdom teeth [35]. Park and Kim [36] present a tooth positional ontology. Dentists are assisted in dental decision making for missing teeth by the system. Assistance is provided by inference using SWRL rules over the ontology [36]. The ontology proposed in this related work lacks modularity. The dental patient isn’t modeled. Most importantly the system lacks learning ability. Also the tooth positional ontology is simple and open to further improvement. Juarez et al. [15] discuss medical knowledge representation, knowledge management and knowledge acquisition. According to the authors, medical knowledge standardization can be used to provide a consistent terminology control and to simplify the integration between knowledge management
Fig. 11 The user chooses facts for assisting rule induction
sams:alternateName(?OralCavity_1_T13_1,“Canine”) ^ sams:HasDiagnosedTooth(?HealthyTeeth,?OralCavity_1_T17_1) ^ sams:HasSequentialNeighbor(?OralCavity_1_T17_1,?OralCavity_1_T16_1) ^ sams:HasDiagnosis(?Examination_3,?Examination_3_MissingTooth_1) ^ sams:MissingTooth(?Examination_3_MissingTooth_1) ^ sams:HasDiagnosedTooth(?Examination_3_MissingTooth_1, ?OralCavity_1_T14_1) ^ sams:HasSequentialNeighbor(?OralCavity_1_T14_1, ?OralCavity_1_T13_1) ^ sams:HasDiagnosedTooth(?Examination_3_MissingTooth_1, ?OralCavity_1_T15_1) ^ sams:HasSequentialNeighbor(?OralCavity_1_T15_1, ?OralCavity_1_T14_1) ^ sams:HasDiagnosedTooth(?Examination_3_MissingTooth_1, ?OralCavity_1_T16_1) ^ sams:HasSequentialNeighbor(?OralCavity_1_T16_1, ?OralCavity_1_T15_1) -> sams:HasTreatmentOption(?Examination_3,sams:Bridge_in) ^ sams:Bridge(sams:Bridge_in) ^ sams:HasTreatedTooth(sams:Bridge_in,?OralCavity_1_T14_1) ^ sams:HasTreatedTooth(sams:Bridge_in,?OralCavity_1_T15_1) ^ sams:HasTreatedTooth(sams:Bridge_in,?OralCavity_1_T16_1)
tools and the health information system. An effective knowledge acquisition process can be established in specific medical fields by adapting knowledge acquisition tools. The aim of this work is to define computational models and to design mechanisms for the effective acquisition and management of medical knowledge in real-life hospital departments. A system which employs ontology-based medical knowledge representation and management is proposed. Model-based inference is used in the system [15]. This system lacks learning from experience and sharing of patient health records. Lezcano et al. [37] state that current archetype languages do not provide direct support for mapping to formal ontologies and for providing reasoning on clinical knowledge. In this article, it is suggested that definitions expressed in the openEHR Archetype Definition Language (ADL) are translated to a formal representation expressed using the Web Ontology Language (OWL). Then SWRL rules are applied to the converted ontology. The purpose of this study is that inference support for clinical applications implemented using ADL are provided by conversion to OWL and then using SWRL rules [37]. Casteleiro et al. [38] focuses on the integration between electronic health records and medical guidelines which
J Med Syst (2013) 37:9989
Page 15 of 17, 9989
Table 2 Inducted rule without dentist supervision sams:HasExamination(?patient, ?exam) ^ sams:HasDiagnosis(?exam,?diag0) ^ sams:HasDiagnosis(?exam,?diag1) ^ sams:MissingTooth(?diag0) ^ sams:HealthyTooth(?diag1) ^ sams:HasDiagnosedTooth(?diag0,?Patient_3_OralCavity_1_T14_1) ^ sams:T14(?Patient_3_OralCavity_1_T14_1) ^ sams:HasDiagnosedTooth(?diag0,?Patient_3_OralCavity_1_T15_1) ^ sams:T15(?Patient_3_OralCavity_1_T15_1) ^ sams:HasDiagnosedTooth(?diag0,?Patient_3_OralCavity_1_T16_1) ^ sams:T16(?Patient_3_OralCavity_1_T16_1) ^ sams:HasDiagnosedTooth(?diag1,?Patient_3_OralCavity_1_T13_1) ^ sams:T13(?Patient_3_OralCavity_1_T13_1) ^ sams:HasDiagnosedTooth(?diag1,?Patient_3_OralCavity_1_T17_1) ^ sams:T17(?Patient_3_OralCavity_1_T17_1) ^ -> sams:HasTreatmentOption(?exam,sams:Bridge_in) ^ sams:HasTreatedTooth(sams:Bridge_in, ?Patient_3_OralCavity_1_T14_1) ^ sams:HasTreatedTooth(sams:Bridge_in, ?Patient_3_OralCavity_1_T15_1) ^ sams:HasTreatedTooth(sams:Bridge_in, ?Patient_3_OralCavity_1_T16_1)
encapsulate evidence-based medicine. In this paper, a simulation framework and a computational test-bed, called V.A.F. Framework, for supporting simulations of clinical situations that boost the integration between Health Level Seven (HL7) and Semantic Web technologies are presented. Higher integration between electronic health records and evidence-based medicine can be accomplished which can lead to healthcare
Table 3 Comparison of SAMS with other related work
Pathak et al. [27] Kiani et al. [35] Park and Kim [36] Juarez et al. [15] Lezcano et al. [37] Casteleiro et al. [38] Kirn [39] Laleci et al. [40] SAMS
Sharing of EHRs
Ontology- Modular based Ontology
Reasoning Learning
N/A
N/A
Yes
N/A
N/A
N/A
Yes
No
Yes
No
No
Yes
No
Yes
No
No
Yes
Yes
No
N/A
Yes
N/A
Modelbased Yes
Yes
Yes
Yes
Yes
No
N/A N/A
No Yes
No No
No Yes
No No
Yes
Yes
Yes
Yes
Yes
No
systems that provide more support to physicians and increase patients’ safety. Rules written in SWRL are used and reasoning is supported [38]. Kirn [39] proposes the OnkoNet architecture which provides users ubiquitous healthcare services over mobile devices. OnkoNet is a multi-agent system. An ontology for hospital scenarios is used for providing agent interoperability. The ontology here is not used for medical knowledge representation. OnkoNet mobile agent architecture includes architectures on the macro and micro levels. It also includes cooperation protocols, inference models controlling system behavior, and a health ontology. Inference is not used to obtain new facts in the medical domain [39]. OnkoNet lacks learning ability. Laleci et al. [40] propose SAPHIRE, a multi-agent system for remote healthcare monitoring through computerized clinical guidelines. It is deduced that by using a decision support system, remote monitoring costs can be decreased. Ontologies are used for semantic mediation of the clinical content. Ontologies and rules are not used for medical knowledge representation. Medical guidelines are represented using GLIF (Guide Line Interchange Format) [40]. This system lacks learning from experience. As a result, SAMS architecture provides sharing of electronic health records of the patients. A physician can view medical records of a patient which are stored in different hospitals that are covered by the system. Thus, the physicians will be able to view the patient’s medical history without the need to question the patient. This is crucial in emergency situations where a patient is unconscious. The medical domain is modeled modularly using OWL ontologies. By using ontologies; higher expressiveness, knowledge sharing, knowledge reuse and inference support are provided. With the addition of defined rules to the ontologies, better expert knowledge can be defined. Physicians are supported by making rule-based reasoning using the defined rules over the ontologies. New facts are deduced from old facts and they are used to assist physicians in decision making. Consequently, the physicians’ need to medical guideline documents will be reduced. In some situations such as lack of equipment, abandoning of some methods or techniques and etc., it might be necessary to take an alternative path. Situations like these are captured by the learning ability of the system. SAMS has the ability to learn from past experience by rule induction. If the user discards the recommendations provided by the system, then the system makes rule induction and extracts a rule or rules with respect to physician’s decision. The system enables the physicians to construct their own rules by manual rule extraction. The inducted rules are added to the system in order to be used later in similar situations. Rule induction can be performed automatically or manually under physician’s supervision. SAMS is original and novel in comparison to reviewed related work, mainly because of the learning capability, sharing of patient records and also combining all of the before mentioned characteristics.
9989, Page 16 of 17
Conclusion Nowadays, health information systems are used by hospitals mainly to increase efficiency, quality of service and to reduce costs. With the technological improvements which enable access to resources anytime and anywhere, storing and sharing of electronic health records (EHR) become an increasingly important issue. In this paper, SAMS, a health information system architecture for developing intelligent health information systems is proposed. The proposed architecture can be adapted and applied to different specialties of medicine and dentistry. The systems satisfying SAMS architecture will be able to store electronic health records of the patients, share them among different hospitals and provide physicians local or remote expertise to assist them in decision making. The system is intelligent because the system is rule based, makes use of rulebased reasoning and has the ability to learn. A better representation of the domain knowledge is achieved by using modular ontologies and rules. The learning capability is achieved through rule induction which is provided by extracting rules from previous given decisions by the users (physicians) and then adding the extracted rules to the system. SAMS architecture supports manual and automatic rule induction. In manual mode, the physicians supervise the induction process. This enables the physicians to construct their own rules. In automatic mode, the system extracts rules without user intervention. The proposed system is novel and original mainly because of reasoning, learning ability and also in all of the previously mentioned characteristics. In SAMS, medical knowledge is represented with OWL ontologies and rules. As a rule language, SWRL or any other language supported by the reasoner can be used. By using ontologies; knowledge sharing, knowledge reuse and inference support are provided. Ontologies are developed using modular ontology techniques. Medical domain knowledge is decomposed into two orthogonal dimensions. One of the dimensions is the medical specialty type. The second dimension is about concepts constituting a specialty. Because these concepts might vary from specialty to specialty, a flexible model is developed. For instance, a specialty can be decomposed into sub-ontologies such as patient ontology, medical domain ontology, diagnosis ontology, treatment ontology and etc. Individuals which are the instances of OWL classes are stored separately. Systems derived from SAMS architecture will have many benefits to the physicians and the general public. SAMS has expert system characteristics and the physicians can get assistance in decision making from the system. General medical guideline knowledge can be stored in SAMS. This will reduce the physicians’ need to medical documents and compensate cognitive gap between experienced and inexperienced physicians. A physician can
J Med Syst (2013) 37:9989
diagnose a case, which he/she has never diagnosed before, using this system. As a result, the patients’ demand to get examined by an experienced physician will be reduced and patient satisfaction will be improved. Also we argued some strategies to increase overall system performance. To reduce the number of individuals stored per computer, individuals can be distributed across different computers. When this is not possible, persistent ontologies can be used. Persistent ontologies are stored in a relational database system when the size of the ontology becomes very large which will finally result in insufficient memory. When persistent ontologies are used, reasoning performance suffers. Also as the number of the individuals increase, again reasoning performance suffers whether the ontology is persistent or not. This problem can be solved by creating an in-memory kept temporary ontology which only stores the individuals of the patient that is to be reasoned over. The reasoning performance of SAMS is immune to suffering when working with very large ontologies by the application of these strategies. Although these strategies are specific to SAMS, they can also be applied in similar circumstances to maximize performance. As a case study, a health information system conforming to SAMS architecture is implemented for use by dentists in the dental domain. The use of the developed system is described with a scenario. The development of this system proves the applicability of SAMS architecture and the aforementioned ideas. As a future work, this dental information system will be used in the hospitals in a pilot area. If new needs emerge during pilot use then the system can be further improved by making modifications to the system. Acknowledgements We would like to thank Dr. Gökhan Yılmaz and his colleagues from the Department of Prosthodontics, Faculty of Dentistry, Ege University. Conflict of interest The authors declare that they have no conflict of interest.
References 1. Lapointe, L., Mignerat, M., and Vedel, I., The IT productivity paradox in health: A stakeholder’s perspective. International Journal of Medical Informatics 80(2):102–115, 2011. URL http://www. sciencedirect.com/science/article/pii/S1386505610002248. 2. McGuinness DL, van Harmelen F (2004) OWL Web Ontology Language Overview. Http://www.w3.org/TR/owl-features/ [last accessed 05/05/2013] 3. Horrocks I, Patel-Schneider PF, Boley H, Tabet S, Grosof B, Dean M (2004) SWRL: A Semantic Web Rule Language Combining OWL and RuleML. Http://www.w3.org/Submission/SWRL/ [last accessed 05/05/2013] 4. Apache Jena (2013) Apache jena. Http://jena.apache.org/ [last accessed 05/05/2013] 5. OWLAPI (2013) The OWL API. Http://owlapi.sourceforge.net/ [last accessed 05/05/2013]
J Med Syst (2013) 37:9989 6. Horrocks I (2003) The FaCT System. Http://www.cs.man.ac.uk/ horrocks/FaCT/[last accessed 05/05/2013] 7. RacerPro (2012) What is RacerPro? An overview. Http://www. racersystems.com/products/racerpro/ [last accessed 05/05/2013] 8. Pellet (2012) Pellet: OWL 2 Reasoner for Java. Http://clarkparsia. com/pellet/ [last accessed 05/05/2013] 9. Hermit (2013) Hermit OWL Reasoner. Http://hermit-reasoner.com/ [last accessed 05/05/2013] 10. Prud’hommeaux E, Seaborne A (2008) SPARQL Query Language for RDF. Http://www.w3.org/TR/rdf-sparql-query/ [last accessed 05/ 05/2013] 11. Wooldridge M (2002) An Introduction to Multiagent Systems. John Wiley & Sons Ltd. 12. Jade (2013) Jade - Java Agent DEvelopment Framework. Http://jade. tilab.com/ [last accessed 05/05/2013] 13. Braubach L, Pokahr A (2007) Jadex Tutorial. Http://jadex.informatik. unihamburg. de/docs/jadex-0.96x/tutorial/index.single.html [last accessed 05/05/2013] 14. Agent Oriented Software (2013) Jack. Http://www.agentsoftware. com.au/products/jack/ [last accessed 05/05/2013] 15. Juarez, J. M., Riestra, T., Campos, M., Morales, A., Palma, J., and Marin, R., Medical knowledge management for specific hospital departments. Expert Systems with Applications 36(10):12,214–12, 224, 2009. URL http://www.sciencedirect.com/science/article/pii/ S0957417409004163. 16. World Health Organization (2013) International Classification of Diseases (ICD). Http://www.who.int/classifications/icd/en/ [last accessed 05/05/2013] 17. National Library of Medicine (2006) Unified Medical Language System. Http://www.nlm.nih.gov/pubs/factsheets/umls.html [last accessed 05/05/2013] 18. Health Level 7 (HL7) (2013) Introduction to HL7 Standards. Http:// www.hl7.org/implement/standards/index.cfm?ref=nav [last accessed 05/05/2013] 19. Regenstrief Institute (2010) LOINC Background. Http://loinc.org/ background [last accessed 05/05/2013] 20. National Library of Medicine (2010) Clinical Terms Version 3 (CTV3) (Read Codes) Source Information. Http://www.nlm.nih. gov/research/umls/sourcereleasedocs/current/RCD/ [last accessed 05/05/2013] 21. SNOMED International (2013) SNOMED Clinical Terms. Http:// www.ihtsdo.org/snomed-ct/ [last accessed 05/05/2013] 22. OpenGALEN (2013) OpenGALEN Mission Statement. Http://www. opengalen.org/ [last accessed 05/05/2013] 23. Open EHR Foundation (2007) Welcome to openEHR. Http://www. openehr.org/home.html [last accessed 05/05/2013] 24. Gene Ontology Consortium (2012) An Introduction to the Gene Ontology. Http://www.geneontology.org/GO.doc.shtml [last accessed 05/05/2013] 25. OBO Foundry (2013) The Open Biological and Biomedical Ontologies. Http://obofoundry.org/ [last accessed 05/05/2013] 26. FMA (2013) Foundational Model of Anatomy. Http://sig.biostr. washington.edu/projects/fm/AboutFM.html [last accessed 05/05/2013] 27. Pathak, J., Johnson, T. M., and Chute, C. G., Survey of modular ontology techniques and their applications in the biomedical domain.
Page 17 of 17, 9989 Integr Comput-Aided Eng 16(3):225–242, 2009. URL http://dl.acm. org/citation.cfm?id=1576283.1576287. 28. Redmond T (2010) An Open Source Database Backend for the OWL API and Protege 4. In: Proceedings of the 7th InternationalWorkshop on OWL: Experiences and Directions (OWLED 2010), URL http:// ceur-ws.org/Vol-614/owled2010_submission_20.pdf 29. Apache Jena (2013) SDB - persistent triple stores using relational databases. Http://incubator.apache.org/jena/documentation/sdb/ index.html [last accessed 05/05/2013] 30. FIPA (2002) FIPA ACL Message Structure Specification (SC00061G). Http://www.fipa.org/specs/fipa00061/SC00061G. html [last accessed 05/05/2013] 31. Protege (2013) Protege-owl api. Http://protege.stanford.edu/plugins/ owl/api/ [last accessed 05/05/2013] 32. Jess (2013) Jess, the rule engine for the java platform. Http:// herzberg.ca.sandia.gov/ [last accessed 05/05/2013] 33. Protege (2013) Protege. Http://protege.stanford.edu [last accessed 05/ 05/2013] 34. Bechhofer S, van Harmelen F, Hendler J, Horrocks I, McGuinness DL, Patel-Schneider PF, Stein LA (2004) Owl web ontology language reference. Http://www.w3.org/TR/owl-ref/ [last accessed 05/ 05/2013] 35. Kiani M, Francis M, Zand-Moghaddam Y, Verma P (2010) Ontology-Based Negotiation of Dental Therapy Options. In: Joshi M, Boley H, Akerkar R (eds) Advances in Semantic Computing, vol 2, TMRF India, chap 4, pp 52–78 36. Park, S., and Kim, H. G., Dental Decision Making on Missing Tooth Represented in an Ontology and Rules. In: Mizoguchi, R., Shi, Z., and Giunchiglia, F. (Eds.), The Semantic Web - ASWC 2006, Lecture Notes in Computer Science. Springer Berlin, Heidelberg, pp. 322– 328, 2006. URL http://dx.doi.org/10.1007/11836025_32. 37. Lezcano, L., Sicilia, M. A., and Rodríguez-Solano, C., Integrating reasoning and clinical archetypes using OWL ontologies and SWRL rules. Journal of Biomedical Informatics 44(2):343–353, 2011. URL h t t p : / / w w w. s c i e n c e d i r e c t . c o m / s c i e n c e / a r t i c l e / p i i / S1532046410001711. 38. Casteleiro, M. A., Des, J., Prieto, M. J. F., Perez, R., and Paniagua, H., Executing medical guidelines on the web: Towards next generation healthcare. Knowledge-Based Systems 22(7):545–551, 2009. URL http://www.sciencedirect.com/science/article/pii/ S0950705109000112. 39. Kirn, S., Ubiquitous healthcare: The onkonet mobile agents architecture. In: Aksit, M., Mezini, M., and Unland, R. (Eds.), Objects, Components, Architectures, Services, and Applications for a NetworkedWorld, Lecture Notes in Computer Science . Springer Berlin, Heidelberg, pp. 265–277, 2003. URL http://dx.doi.org/10. 1007/3-540-36557-5_20. 40. Laleci GB, Dogac A, Olduz M, Tasyurt I, Yuksel M, Okcan A (2008) SAPHIRE: A Multi-Agent System for Remote Healthcare Monitoring through Computerized Clinical Guidelines. In: Annicchiarico R, Cortés U, Urdiales C, Walliser M, Brantschen S, Calisti M, Hempfling T (eds) Agent Technology and e-Health, Whitestein Series in Software Agent Technologies and Autonomic Computing, Birkhäuser Basel, pp 25–44, URL http://dx.doi.org/10. 1007/978-3-7643-8547-7_3