Studies in System Science (SSS) Volume 1 Issue 3, September 2013
www.as-se.org/sss
MedAdvice24 – A Decision Support System for Medical Advice Maria J. Assena, João Peixe, Fernando Almeida Innovation and Development Centre, Higher Institute of Gaya, ISPGaya Av. dos Descobrimentos, 333, 4400-103 V. N. Gaia, Portugal maria.assena@msn.com; ispg3216@ispgaya.pt; falmeida@ispgaya.pt Abstract This article presents a clinical decision support system that intends to help clinics and patients to identify a potential disease based on several symptoms perceived and inserted in an IT application of patients’ details. This knowledge is represented through a Business Intelligence algorithm, which uses data from the patient's history to diagnose possible illness. The application offers a registration/login to allow only its utilization by registered users and turns possible the store and access to previous saved information whenever it is necessary. This information will be also used to check the possibility of potential diseases, as well to provide appropriate treatment, namely, the generation of electronic prescription, knowing the type of allergies that the patient may have to certain medication. It is also intended that the electronic prescription is sent to email address of family doctor. Keywords Health; Decision Support System; Information and Communications Technology; Business Intelligence Algorithm
Introduction This academic project was designed in the framework of the discipline of Decision Support Systems and intended to provide a new guidance for health. The motivation to develop this project is to decrease the waiting time on queues, costs of medicines, displacements of medical vehicles and redundant procedures in the course of the treatment of patients’ ailments, for example, a common flu. Furthermore, mostly in remote areas, people are deprived of the access to experts to diagnose disease (Carvalho, 2012). The main objective of this system is to produce relevant data and information for consultations, and with the results obtained at this stage, produce possible diagnoses and an electronic prescription to treat the symptoms. Therefore, the medical environment will be changed from hospital-based one to citizen-based one and the whole health care processes from diagnosis to the electronic prescription with the properly treatment. Our services will be
available when users require them on the available application online 24 hours per day. According to Know and Kim’s (2008) this is an essential requirement for a clinical decision support system. In health, as in many areas, effective use of information technology has often been seen as necessary to many of the core activities that are undertaken. Separate communities have worked on ehealth, on broader health policy and on improving the use of Information and Communications Technology (ICT) (Bend, 2004). The application can frequently provide useful advice which is not foolproof. In the past, the history of the use of the blood pressure cuff showed that in the early part of the last century physicians were uneasy about relying on the cuff to determine a patient’s blood pressure, instead of using their palpation skills, which was the practice at that time. Nowadays, patients are even allowed to do it by themselves at home. This example illustrates how new devices or systems that appear to challenge what clinicians perceive as their unique skills are likely to be resisted. However, according to Berner (2009), until the use of this application as routine as the use of the blood pressure cuff, it is important to be sensitive to resistance of using these systems. The structure of the paper is organized as follows: in section 2 the state of art provides a brief description on the architecture of a decision support system (DSS) and analyzes the importance of DSS when applied to the clinical area; in section 3 our approach is presented, which contains the system architecture, requisites, modeling and business intelligence algorithm; in section 4 the implementation is conducted; in section 5 the main results are shown, and finally, section 6 draws the conclusions and provides some suggestion for future work. State of the Art A Decision Support System (DSS) is an interactive computer-based system developed with the intention 39
www.as-se.org/sss
of helping someone to make certain decisions. These systems were created in order to serve as deputies to people who perform important decisions in order to expand its capabilities. All are involved in making a decision, since the extraction of data through the storage, use of templates, interface and even the user (Scorsatto, 2012). Bonczek, Holsapple, and Whinston (1980) defined “DSS as a computer-based system with three key components: a language system (a mechanism to provide communication between the user and other components of the DSS), a system of knowledge (repository knowledge of problems, data or processes) and the system problems processor (the junction between the other two components)”. The knowledge-based systems are often called "expert systems". These programs analyze the data using symbolic logic, an explicit knowledge base and have the ability to display the conclusions so that the users can understand the output. By definition, an expert system is a computer program that simulates the thought process of a human expert to solve complex decision problems in a specific domain. An expert system may be viewed as a computer simulation of a human expert, merging human knowledge with computer power in solving problems (Turban, Sharda, and Delen, 2010; Biswas et al, 2011; Scorsatto, 2012).
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
the solution. According to Mateo, Gerardo, and Lee (2007), one of the main applications for expert systems is the systems diagnosis, where the application is able to infer potential problems based on symptoms. Its architecture is divided into two basic components: a database containing all relevant knowledge about the problem in an organized way (knowledge base); a set of intelligent methods of manipulation of this knowledge, the inference mechanisms (Cardoso et al., 2003). Researchers have identified several factors common among successful clinical decision support systems (CDSS). According to Zheng (2006) and Byrne et al. (2012), these factors include: Clinical workflow integration–CDSS must be integrated into the complete patient care workflow. For workflow integration to be successful, CDSS must also be fast and realtime responses are required; Simple and minimalist interventions–information provided for clinical decision makers should consist of brief imperative sentences. When additional information is necessary for the CDSS to provide a recommendation, only the data absolutely needed should be requested; Recommendation based interventions–CDSS is considered most effective when interventions redirect, rather than stop, a course of treatment. Therefore, CDSS should provide recommendations for treatments, rather than exclusively diagnostic assessment; Computer-based decision support–a CDSS should be seen as a computerized information system, rather than a collection of manual audit processes;
FIG. 1 GENERIC ARCHITECTURE (ADAPTED FROM BURSTEIN AND HOLSAPPLE, 2008)
FIG. 1 shows an overview of the generic architecture of a decision support system. The user communicates through the user interface. The user interface originates from the junction of the base data, which stores all data from business intelligence. The user interface performs all calculations necessary to fulfill the function of the application-symptoms and diseasetreatment, and the knowledge base containing all the necessary data about the symptoms associated with the disease. The expert system is "informed" about the characteristics of the problem and decides, during processing, which is the most likely path to achieve 40
Continual knowledge base and user interface updates the diagnostic and treatment information in a CDSS needs frequent updating as known medical knowledge is generated by research and data-mining. CDSS can provide support for clinicians at various stages in the care process, from preventive care through diagnosis and treatment to monitoring and following-up. CDSS implementations can include, for example: order sets tailored for particular conditions or types of patients; access to guidelines and other external databases that can provide useful and up to date information for particular patients with specific diseases; reminders for preventive care; and alerts about potentially dangerous situations that need to be addressed (Bates and Bitton, 2010).
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
As previously stated, the most common use of CDSS is to address clinical needs. However, CDSS can also potentially lower costs, improve efficiency, and reduce patient inconvenience (Hughes, 2009). In fact, CDSS can sometimes address all three of these areas simultaneously, for example, by alerting clinicians to potentially duplicate testing (Miller, 2010). When there is a need of more complex cognitive tasks, such as diagnostic decision-making, the mission of CDSS is to assist, rather than to replace, the clinician. The CDSS may offer suggestions, but the clinician must detect the information, review the suggestions, and decide whether to take action and what action to take. TABLE 1 provides a brief overview of the most target areas of a CDSS. TABLE 1 MAIN CDDS APPLICATIONS AREAS (BERNER, 2009)
Target Areas Preventive care
Diagnosis Planning or implementing treatment Follow-up management Hospital, provider efficiency Cost reductions and improved patient convenience
Examples Immunization, screening, disease management guidelines for secondary prevention Suggestions for possible diagnoses that match a patient’s signs and symptoms Treatment guidelines for specific diagnoses, drug dosage recommendations, alerts for drugdrug interactions Corollary orders, reminders for drug adverse event monitoring Care plans to minimize length of stay, order sets Duplicate testing alerts, drug formulary guidelines
According to Robbins, Gurupur, and Tanik (2011), planning for any new health information technology system includes typically a number of common key steps, such as analyzing the environment, identifying the needs and functional requirements, evaluating the project risks, etc. These tasks are typically performed before the implementation phase. With respect to the CDDS domains, these pre-implementation tasks assume a decisive role. In a CDSS implementation, we need to know whose decisions are supported, what information is presented, when it is presented, and how it is presented to the user (Borbolla et al., 2010; Scheepers-Hoeks, 2011). There are also similar products in the market field of CDSS. Two of the most predominant platforms are OpenClinical and VisualDX. These solutions generically use artificial intelligence systems to improve diagnostic accuracy and medical services. OpenClinical maintains an extensive archive of
www.as-se.org/sss
artificial intelligence systems in routine clinical use. The archive contains summaries of artificialintelligence based computer systems that have been in routine use in medical settings. Entries range from simple knowledge-based expert systems to quite advanced systems capable of performing complex inferences (OC, 2013). VisualDX, a web-based clinical decision support system that aims to enhance diagnostic accuracy, aid therapeutic decisions, and improve patient safety, is oriented to problem solving, and provides search by symptoms, visual clues and other patient factors, by diagnosis or medication (VDX, 2013). Methodology and Approach Environment Analysis In 2007, the Portuguese Ministry of Health created a telephonic line called Health 24 that has facilitated the access of citizen to information and health care services. The mission of this initiative is to become the single point of entry for the Provision of Health Care and Social State, accessible to the entire community, thus minimizing inconsistencies and contributing to greater effectiveness and efficiency of the public health sector. Furthermore, Health 24 offers a package of additional services relevant to people, by which, a citizen can search for a pharmacy in Portugal and can also browse the network of National Health Services. Additionally, the site offers functionality similar to a FAQ about the most pertinent diseases and health services requested by population. An example of the interface provided by Health 24 is given in FUG. 2.
FIG. 2 WEB INTERFACE OF HEALTH 24 (H24, 2013)
The Health Line 24 has been considered a very successful project and receives around 1800 telephone calls per day. Besides that, it is estimated that the existence of this telephonic line helps remove 15 to 20 thousands users of emergency units each month 41
www.as-se.org/sss
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
(Marcelino, 2012). However, there is an opportunity to improve these services and increase the level of integration of information technologies (IT) in care services. We do not intend to replace the role of clinicians, which will still remain absolutely crucial in this process, but we want to help and assist clinicians in identifying potential diseases and corresponding available treatments. At the same time, we also want to increase the level of interaction between clinicians and citizens. Functional Requirements The functional requirements were divided according to their priority (high, middle and low). 1) High Priority Requirements •
Editing the list of diseases in the application – there is the possibility to insert, update, and delete the registration of diseases present in the application;
•
Request for counseling – an authenticated user informs the application of the symptoms that affect him/her, in order to find the associated pathology;
•
User registration – the registration of the user in the application is made by associating an email to each user.
FIG. 3 COMPONENT DIAGRAM
The system only authorizes the access for authenticated users. When the user is authenticated, he/she can have access to the historical records or he/she can start a new counseling request. The edition of the parameters table is only available for the system administrator. The structure of the database tables can be seen in FIG. 4.
2) Medium Priority Requirements •
•
Creation of electronic prescriptions – when the user gets the recommended treatment, he/she will receive an electronic prescription. This is developed using XML technology; History consultation – historical diseases consultation, symptoms and recommended treatments, as well as prescription consultation for each user are made by statistical analysis of the data stored;
3) Low Priority Requirements •
Historical update by user – the user can also update his/her historical disease details;
•
Transmission of history to the family doctor– the historical record of user diseases may be sent to the family doctor, using XML documents or Web Services.
FIG. 4 CLASS DIAGRAM
The database is composed of the user tables, disease history, treatment, prescription and allergy. Initially, the user registers their allergies. After the symptoms are manifested, a list with possible diseases is reported. That may or may not be related to the patient historical case, depending on if it is the first time that the patient uses the application. Otherwise, the historical data will influence the disease detection. Then, it is suggested to the user of the adequate treatment for his/her allergies and, finally, an electronic prescription is given to the patient. Modeling
System Architecture The architecture of the system (FIG. 3) is presented using the UML component diagram. 42
FIG. 5 WORKING PROCESS OF THE PATHOLOGY IDENTIFICATION
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
As shown in the workflow in FIG. 5, modeling is characterized by symptoms, disease and pathology. The symptoms are displayed on the database application and the user will choose those that best identify his/her disease. In accordance with the symptom chosen, disease is diagnosed. The pathology (study of disease) is the relationship between symptoms and diseases, which makes it possible to identify a disease based on its symptoms. Any algorithm that generates the pathology is presented in the section below. Business Intelligence Algorithm The purpose of the algorithm is to determine the most probable disease compared to the symptoms shown by the user and in view of existing information in the database of medical knowledge. The production of the results depends on the completion of a previous set of conditions:
The database must be filled in with information concerning the characterization of diseases in terms of symptoms and treatments;
For each disease, the probability of this to occur in society should be indicated and the weight that this information should be is in the final calculation (factor fF);
For each symptom that characterizes a specific disease, it is necessary to indicate the probability of this symptom found in this disease. This information (factor fS) is the one that will have a greater weight in the final calculation;
The historical record of diseases identified by the program gives the weight of history in the final calculation (factor fH), and its calculation more or less, depends on the number of occurrences of the diseases listed in the user’s history. Note that the existing historical records that come from manual input (not produced by the program in previous visits) are not considered in the calculation because of the lack of credibility of this data;
The program parameters area sets the weight factor fF (frequency of disease in society);
The program parameters area sets the weight factor fH (which reflects the quality of the history of the user) or if there is a record of the occurrence of any of the diseases listed. If true then the weight of this factor is 5% and it will be increased by 5% for each new found occurrence;
www.as-se.org/sss
The program parameters area defines the minimum acceptable value for the program accomplishes the issuance of a prescription (Pmin). Only a value with a high degree of security should be allowed in the next step. Otherwise, the result should be considered inconclusive, at least so far as to generate a prescription;
The weight of factor S depends on the weight of other factors, i.e.: fS = 100% - fH – fF (1)
At this phase, the process of “Request of Counseling” is initiated. This is based on the following stages: 1) System Report a) The user starts by pointing out the first symptom from the existing symptoms in the database (the user can search for a name or write the name of the symptom); b) At this moment, the user can do the “Request for Counseling”; c)
If the user must indicate the symptoms one by one he/she intends to analyze. Each time the list that appears only displays the symptoms of other diseases that contain all the symptoms already identified;
d) In this way, the final list of symptoms is identified: LS. 2) Request for Counseling a) Identify the weight assigned to factor fF (frequency of disease in society); b) Given the symptoms listed (LS), determine the list of diseases (LD) that are characterized with all the symptoms reported; c)
Identify weight to be the factor fH (historical) counting the number of times any diseases of the LD is registered in the history of the user;
d) Knowing the weight factor fF and the weight factor fH is now possible to determine the weight factor S (symptoms): fs = 100% - fH - fF (2) e) Calculate the probability as a function of the symptoms listed. There are two factors to be taken into account: •
The probability of the occurrence of each symptom on each disease. For each disease consider the likelihood of various symptoms identified – S1; 43
www.as-se.org/sss
•
•
f)
The “strength” of the symptoms identified for each disease must be calculated. This is the weight of the identified number of symptoms versus the total number of symptoms that characterize the disease (if a patient shows three identified symptoms in three possible symptoms, then the strength is maximum; on the other side, if a patient only shows three symptoms in six possible symptoms, then the strength will be equal to 50%) – S2; The weighting of these two factors results in the value to be considered for the final value: pSYMPTOMS = S1 * S2 (3)
Calculate the weight of each disease in the history of the LD of the user and divide by the total number of all occurrences. Then the result for the final calculation is recorded: pHISTORIC
g) Weight calculation of each disease, given the probability of its occurrence in the society. It follows to consider the value for the final calculation: pFREQUENCY
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
email is sent to the user to confirm login details. After the first login, the user can change his password; 2) Login in Application After the registration, the user can always log in the application. The system verifies whether the user has valid credentials to enter in the application; 3) Change Password with the Power Meter There are several features available through the menu. One is to change the password with an auxiliary panel that allows the user to have an idea of the sensitivity security degree of the password. The password security level is divided into very weak, weak, medium, strong or very strong; 4) Request for Counseling The request for advice is the most important part of the prototype, because it allows the application to investigate, through inserted symptoms, the disease, if the result is conclusive. Furthermore, the system displays the most suitable treatment (i.e., the electronic prescription). An illustration of this process is given in FIG. 6;
h) Calculate the final frame in each disease. This is assigned to a final probability pDISEASE, in which the various factors have been taken into consideration previously calculated as follows: pDISEASE=(pSYMPTOMS*fS)+(pHISTORIC*fH)+(p FREQUENCY*fF) (4) It is important to highlight that the program will only generate the prescription if a disease can be determined with a degree of probability greater than or equal to the parameters defined as the minimum acceptable value (Pmin). Implementation In order to validate our approach, a prototype has been developed based on the .NET 3.0 framework. This prototype is written in C# and uses a SQL Server database. The features implemented in the prototype are chosen based on the level of priority established for each functional requirement and time available constraints. A short overview of the implemented features is given in this section. 1) User Registration User registration is made in the application. An 44
FIG. 6 REQUEST FOR COUNSELING
5) Query History On the initial menu, the user can also introduce some data into his health history. Data entered will not be used to calculate any request for advice. However, the data inserted automatically in history (after each visit of the application with conclusive results), will be relevant to making a diagnosis; 6) Application Management This function is only available to the system administrator, and allows the edition of existing diseases (as well as associated symptoms and treatments), insertion of new treatments and symptoms, and finally the inspection and removal of users.
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
Results In this section, we present some scenarios of the utilization of the prototype, considering a sample database of diseases and the estimation of several parameters. It is important to note that the database used can be easily improved with more and better data. The same happens with the parameters table, which can be easily customized. TABLE 2 is an extract of the diseases stored in the database and their respective relation with the symptoms. TABLE 2 DATABASE OF DISEASES AND SYMPTOMS
Disease
Phthisis
Flu
Malaria
Abdominal Abscess
Probability to occur in society
15%
85%
10%
45%
Symptom Cough Expectoration Coughing up Blood Perspiration Weight Loss Loss of Appetite Weakness Sternutation Store Throat Bodily Pain Headache Fatigue Fever Cough Headache Fatigue Fever Cough Chills Nausea Tremors Vomiting Shortness of Breath Swelling of the Liver Abdominal Pain Fever Weight Loss Loss of Appetite Weakness Chills Abdominal Distention Nausea Diarrhea
Probability to occur in disease 95% 90% 50% 80% 80% 80% 60% 90% 79% 67% 90% 80% 90% 75% 90% 80% 99% 5% 78% 80% 80% 90% 89% 35% 99% 80% 60% 60% 80% 80% 99% 80% 70%
TABLE 3 PARAMETER TABLE
Parameter Weight of the factor disease frequency in the society Weight to consider no occurrences in the historical data Weight to consider one occurrence in the historical data Weight to consider two occurrences in the historical data Weight to consider three or more occurrences in the historical data
Value 10% 0% 5% 10% 15%
TABLE 3 contains the auxiliary system parameters
www.as-se.org/sss
which are needed for the calculation of the occurrence probability of a certain disease in a patient. Case Number 1 The user A, without any historical record in the application, makes a counseling request by providing the following symptoms: Fatigue, Fever and Cough. With these symptoms, the system diagnoses two diseases: Flu and Malaria. 1) Factor Frequency (Disease in the Society) This factor is calculated, determining the weight of each disease, regarding the frequency in the society, as shown in the following table: TABLE 4 CALCULATION OF FACTOR FREQUENCY
Disease Flu Malaria
Frequency 85% 10% 95%
Final (factor F) 89,5% 10,5%
2) Factor Historic (User) As previously stated, in this case there isn’t any user history record in the database. 3) Factor Symptoms (Indicated by User) Two sub-factors are analyzed: The occurrence weight of each symptom in each disease;
•
TABLE 5 CALCULATION OF FACTOR SYMPTOM – OCCURRENCE LEVEL
Disease Flu Malaria
Fatigue 80% 80%
Fever 90% 99%
Symptoms Cough 75% 5%
Average (sF1) 81,7% 61,3%
The “strength” of the provided symptoms facing the number of total symptoms that exist in the knowledge base of each disease.
•
TABLE 6 CALCULATION OF FACTOR SYMPTOM – “STRENGTH” LEVEL
Flu
Number of identified symptoms 3
Number of symptoms of the disease 4
Malaria
3
10
Disease
Weight (sF2) 75,0% 30,0%
These two sub-factors combined produce the following result: TABLE 7 CALCULATION OF FACTOR SYMPTOM
Disease Flu Malaria
sF1 81,7% 61,3%
sF2 75,0% 30,0%
sF1 * sF2 61,3% 18,4% 79,7%
Final (factor S) 76,9% 23,1%
Currently, the weight of each factor should be determined: 45
www.as-se.org/sss
•
•
•
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
The weight assigned to the factor frequency of the disease in society is 10% and can be defined in the parameters table; The weight assigned to the factor historical of the user is of 0% that is the value defined in the parameters, in the cases in which the total of historical records of the user in the referenced diseases is zero;
historical records of the user in the referenced diseases is three; •
By combining all the obtained results, the system produces the following final table: TABLE 10 FINAL RESULTS OF DISEASES
The weight of the factor symptoms is determined depending on the above two. In this case, it is 90%.
By combining all the obtained results, the system produces the following final table: TABLE8 FINAL RESULTS OF DISEASES
Disease Flu Malaria
Frequency (factor F) 10% 89,5% 10,5%
Historic (factor H) 0% 0,0% 0,0%
Symptom (factor S) 90% 76,9% 23,1%
Final 78,2% 21,8%
Case Number 2 The same user, sometime after they have added several records in the program of counselling advice (the manual records are not considered in the calculation process of the most probably disease), makes a new counselling request in the application by providing the same symptoms referred to in the case 1: Fatigue, Fever and Cough. With these symptoms the system diagnoses two diseases: Flu and Malaria. In this case, the calculation process of the factors frequency of the disease in society (factor F) and symptoms (factor S) remains unchanged.
Disease Flu Malaria
TABLE 9 TABLE OF FACTOR HISTORIC
Disease
Number of occurrences in historic
Final (factor H)
Flu Malaria
3 0
100% 0%
The next step includes determining the weight of each factor:
46
•
The weight assigned to the factor frequency of the disease in society remains unchanged (10%);
•
The weight assigned to the historical factor of the user is 15%, which is the value defined in the parameters, in the cases in which the total
Frequency (factor F) 10% 89,5% 10,5%
Historic (factor H) 15% 100,0% 0,0%
Symptom (factor S) 75% 76,9% 23,1%
Final 81,6% 18,4%
Regarding the case 1, it can be seen that the fact of existence in the users historical several records of flu has resulted in a higher probability assigned to this disease, 76.6% in the case 1 of while 81.6% in the case 2 . Case Number 3 The user A, without any historical record in the application, makes a counselling request, by providing the following symptoms: Chills, Fever and Nausea. With these symptoms, the system diagnoses two diseases: Malaria and Abdominal Abscess. 1) Factor Frequency (Disease in the Society) This factor is calculated to determine the weight of each disease, regarding the frequency in society, as shown in the following table: TABLE 11 CALCULATION OF FACTOR FREQUENCY
1) Factor Historic (User) The summary of the historical record of the user includes three flu records, as shown in the table below:
The weight of the factor symptoms is determined depending on the above two. In this case, it is 75%.
Disease Abdominal Abscess
Frequency 45%
Final (factor F) 81,8%
Malaria
10%
18,2%
55%
2) Factor Historic (User) Summary of the user’s historical records includes three Malaria records and one of Abdominal Abscess. TABLE 12 TABLE OF FACTOR HISTORIC
Disease Abdominal Abscess Malaria
Number of occurrences in historic 0 2
Final (factor H) 0,0% 100,0%
3) Factor Symptoms (Indicated by User) Two sub-factors are analyzed: i.
The occurrence weight of each symptom in each disease;
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
TABLE 13 CALCULATION OF FACTOR SYMPTOM – OCCURRENCE LEVEL
Symptoms Chills Fever Nausea Average (sF1)
Disease Abdominal Abscess Malaria
80%
80%
80%
80,0%
78%
99%
80%
85,7%
ii. The “strength” of the provided symptoms facing the number of total symptoms that exist in the knowledge base of each disease. TABLE 14 CALCULATION OF FACTOR SYMPTOM – “STRENGTH” LEVEL
Disease
Number of identified symptoms
Number of symptoms of the disease
Weight (sF2)
3
9
33,3%
3
10
30,0%
Abdominal Abscess Malaria
These two sub-factors combined produce the following result: TABLE 15 CALCULATION OF FACTOR SYMPTOM – COMBINATION OF TWO LEVELS
sF1
sF2
sF1 * sF2
Final (factor S)
80,0%
33,3%
26,7%
50,9%
85,7%
30,0%
25,7% 52,4%
49,1%
Disease Abdominal Abscess Malaria
After that, the weight of each factor is determined as follows: •
The weight assigned to the factor frequency remains at 10%;
•
The weight assigned to the historical factor of the user is 10%, which can be defined in the parameters table, in the cases in which the total historical records of the user in the referenced diseases is two;
•
The weight of the factor symptoms is determined depending on the above two. In this case, it is 80%.
By means of combination of all the obtained results, the system produces the following table: TABLE 16 FINAL RESULTS OF DISEASES
Disease Abdominal Abscess Malaria
Frequency (factor F) 10%
Historic (factor H) 10%
Symptom (factor S) 80%
Final
81,8%
0,0%
50,9%
48,9%
18,2%
100,0%
49,1%
51,1%
www.as-se.org/sss
the patient history (factor H), the final score given to Malaria is higher than Abdominal Abscess. Conclusions The application of decision support systems in health care has contributed significantly to the development of worldwide health care, improving service and quality for the user. However, by itself a clinical decision support system can only have a great impact on society and provide reliable results if the medical knowledge is properly integrated into the application. With this project implemented, time spent by people in queues will be shortened. It will also be good for people who are embarrassed of certain subjects, as they would feel comfortable and safety. For the application to correctly detect the disease associated with the displayed symptoms, several calculations are necessary. In the database, all the diseases and the symptoms associated with each of them are stored. Each symptom has a probability of occurrence for a particular disease and the probability of its occurrence in society. The probability of catching a particular disease is determined by means of the factor of the frequency of the disease in the society, the factors of the user’s history and the factors of the provided symptoms. The historical factors, as shown, have an important weight in the discovery of the disease, since it is likely that a person has a tendency to manifest again a disease that they previously had. As future work, this application can serve as an input of a vast repository of information on various diseases. Also, it may be implemented in a user profile as a new functionality that allows each patient to put their data in relation to their nutrition and physical activity. In this case, the application could do the calculations in accordance with not only current data and history but also the data regarding their physical activity, nutrition and age. This would help promote patient well-being, by sending an e-mail periodically to each patient in order to prevent disease and promote health and patient attendance. ACKNOWLEDGMENT
In this case, it can be indicated that the factor historic ends up having a determining weight in the final result, considering that the frequency probability of Malaria is only 18,2%. However, due
The design and implementation of MedAdvice24 was made with the contribution of a software team composed of analysts and programmers. We would like to express gratitude to Alexandre Azevedo, André Queirós, André Oliveira, Hugo Duarte and José A. Ferreira.
47
www.as-se.org/sss
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
REFERENCES
H24. “Saúde 24: o número que o liga à saúde”. Accessed
Bates, Davis, and Bitton, Asaf. “The future of health information technology in the patient-centered medical home.” Health Affairs, 29(4), 2010, 614-621. Bend, Jamie. “Public Value and e-Health”, Institute for Public Policy Research, 2004, 19-20. Berner, Eta. “Clinical decision support systems: State of the Art.” AHRQ Publication, June 2009. Accessed July 12, 2012. http://healthit.ahrq.gov/portal/server.pt/gateway/PTARG S_0_1248_874024_0_0_18/09-0069-EF.pdf. Biswas, Dipanwita, Bairagi, Sagar, Panse, Neelam, and Shinde,
Nirmala.
“Disease
Diagnosis
System.”,
International Journal of Computer Science & Informatics, I (2011): 48-49. Bonczek, Robert, Holsapple, Clyde, and Whinston, Andrew. “The evolving roles of models in decision support systems.”Decision Sciences, 11(2), 1980, 337-356. Borbolla, Damian, Otero, Carlos, Lobach, David, Kawamoto, Kensaku, Lopez, Gastón, Luna, Daniel, and Queirós, Fernando. “Implementation of clinical decision support system using a service model: results of a fesibility study,” Studies in Health Technology and Informatics, 160 (2010): 816-820. Burstein, Frada, and Holsapple, Clyde. “Handbook on Decision Support Systems.” London: Springer, 2008. Byrne, Colene, Sherry, Dylan, Mercincavage, Lauren, Johnston, Douglas, Pan, Eric, and Schiff, Gordon. “Advancing Clinical Decision Support: key lesson in clinical
decision
support
implementation.”
Hughes, Courtney. “Using Clinical Decision Support to Improve Health and Achieve Cost Savings.” Anvita Health White Papers, 2009. Accessed February 18, 2013. http://anvitahealth.com/pdf/Anvita%20Health%20Report %20-%20CDS%20ROI.pdf Kwon, Pyung-Jin, Kim, Heon, and Kim, Ungmo. “A study on the web-based intelligent slef-diagnosis medical system.” Journal of Advances in Engineering Software, 40(6), 2009, 402-406. Marcelino, Cátia. “PT vai gerir Linha Saúde 24 por quase 18 milhões de euros.” Construlink, 2012. Accessed February 15, 2013. http://www.construlink.com/Homepage/5069. Mateo,
Romeo,
Gerardo,
Bobby,
and
Lee,
Jaewan.
“Healthcare Expert System Based on the Group Cooperation Model.” Paper presented at International Conference on Intelligent Pervasive Computing, Jeju Island, Korea, October 11-13, 2007. Miller, Katharine. “Clinical Decision Support: providing quality
healthcare
with help
from
a
computer.”
Biomedical Computation Review, 6(1), 2010, 19-28. OC. “OpenClinical: knowledge management for medical care”. Accessed May 9, 2013. http://www.openclinical. org/ Robbins, David, Gurupur, Varadraj, and Tanik, John. “Information Architecture of a Clinical Decision Support System.”
Paper
presented
at
IEEE
Southeastcon,
Nashville, Tennessee, March 17-20, 2011. Scheepers-Hoeks, Anne-Marie, Grouls, Reve, Neef, Cees,
Westat
Ackerman, Eric, and Korsten, Erik. “Success Factors and
Techincal Report, 2012. Accessed February 11, 2013.
Barriers for Implementation of Advanced Clinical
http://medicine.yale.edu/cmi/glides/localize/555_140800_
Decision Support Systems, 2011. Accessed February 11,
acds-lessons-in-cds-implementation-deliverablev2.pdf.
2013.
Cardoso, Jefferson, Queiroz, Rodrigo, Lopes, Cláudia, and Rosa, Valéria. “Um sistema especialista para apoio à
http://cdn.intechopen.com/pdfs/18695/InTech-
Success_factors_and_barriers_for_implementation_of_ad vanced_clinical_decision_support_systems.pdf.
decisão em exames ortopédicos de ombro, cotovelo e
Scorsatto, Filipe. “Sistema de Apoio à Decisão.” Trabalho de
punho.” Universidade Estadual do Sudoeste da Bahia,
Informática Aplicada, 2012. Accessed July 17, 2012.
2003. Accessed July 17, 2012. http://www.sbis.org.br/
http://ensino.univates.br/~felipesc/.
cbis9/arquivos/648.pdf.
Turban, Efraim, Sharda, Ramesh, and Delen, Dursun.
Carvalho, Paula. “Longe do médido, sem dinheiro e sem transportes”, March 2012, Jornal Público, Versão online. Accessed 1538728.
48
May 9, 2013. http://www.saude24.pt/
July
05,
2012.
http://m.publico.pt/Detail/
Decision Support and Business Intelligence Systems. New Jersey: Prentice Hall, 2010. VDX. “VisualDX: a faster, more accurate diagnosis”, Accessed May 9, 2013. http://www.visualdx.com/
Studies in System Science (SSS) Volume 1 Issue 3, September 2013
Zheng, Kai. “Design, implementation, user acceptance, and evaluation of a clinical decision support system for evidence-based medicine practice.” PhD diss., Carnegie Mellon University, 2006. Maria João, Assena. Coimbra, Portugal, 1990. BsC. in Computer Management at ISPGaya, V.N.Gaia, Portugal. Her research interests are in the field of support decision systems and quantitative methods applied to management. João, Peixe. Ílhavo, 1970. BsC in Management at Open University, Aveiro, Portugal. He is a teacher at EPADRV in
www.as-se.org/sss
information technology and management. His research interests are in the field of database systems, data warehousing and support decision systems. Fernando, Almeida. Porto, 1979. PhD in Computer Science Engineering at Faculty of Engineering of University of Porto, Portugal. He is a coordinator teacher at ISPGaya and author of more than 60 papers and 3 books in the field of IT and innovation. His research interests are in the system of big data management, software engineering, software quality and innovation science. He is also editor of two international journals.
49