FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: SYSTEM AND METHOD FOR CLINICAL DECISION SUPPORT
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman
SERVICES LIMITED Point, Mumbai, Maharashtra 400021,
India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter, in general, relates to decision support systems and, in particular, relates to a system and a computer-implemented method for clinical decision support.
BACKGROUND
[0002] Healthcare practitioners are required to make clinical decisions on a daily basis. Such decisions entail collecting information about the patient, deciding upon a diagnosis, and deciding upon a treatment for the patient. Healthcare practitioners undergo years of training in order to become adept at making such clinical decisions, and rely heavily upon prior experience and knowledge. In case of uncertainty, healthcare practitioners may also require to consult other healthcare practitioners for making appropriate clinical decisions. Even with all these resources, the complexity of some clinical decisions and the medical environment, may make clinical decisions difficult.
[0003] Recent advancements in the field of information technology have led to automation of day-to-day work activities in various industries including healthcare, thereby making complicated tasks of patient management simpler and efficient. For instance, clinical decision support systems (CDSS) have introduced automation in diagnosis and patient care. The clinical decision support system (CDSS) may be understood as an interactive decision support system (DSS) implemented through computer systems, which is designed to assist physicians and other healthcare professionals with decision making tasks, such as determining diagnosis and treatment options based on patient data. Thus it provides some degree of automation in the healthcare industry. CDSS can be used in different branches of the healthcare industry.
[0004] In the past few years, CDSS have been developed to support various aspects of the clinical care process. Generally, CDSS may provide point-of-care, case-specific clinical advice based on clinical information for a patient and a knowledge base. Typically, CDSS have been used to diagnose probability of illness with an objective of eliminating or highlighting the possibility of serious diseases in the absence of expert healthcare. CDSS have also been used for self-diagnosis in the absence of a healthcare setup. Further, CDSS have also been used for administrative purposes. For example, centralized databases or automated systems have been

created and maintained to keep information of patients, their addresses, medical history, doctors who attended the patients, last visit, gender, age, patients' complaints and the like. These records are maintained to keep an ease in daily businesses of hospitals and clinics. Such records are used to assist doctors and other healthcare professionals to prescribe treatment based on previous diagnosis.
[0005] CDSS typically use domain knowledge and a set of historical parameters to arrive at a set of probable diagnosis. Rule processing in a CDSS must have the capability of delivering accurate diagnosis pertaining to the inputs received after assessing it, using a set of domain knowledge parameters and at the same time effectively managing aspects of treatment such as pharmacotherapy and other investigations.
SUMMARY
[0006] This summary is provided to introduce concepts related to system and method for clinical decision support and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0007] In one implementation, the clinical decision support system, also referred to as system, comprises a processor, and a screening module coupled to the processor, wherein the screening module is configured to obtain user values for a plurality of rule parameters from a user. The system further comprises a rule engine coupled to the processor, wherein the rule engine is configured to identify one or more logical rules, from among a plurality of logical rules, based on the user value, wherein each of the plurality of logical rules includes the plurality of rule parameters from among multiple rule parameters. The system further comprises a plurality of diagnosis modules coupled to the processor, wherein each of the plurality of diagnosis modules is configured to execute one or more logical rules based at least on the plurality of rule parameters and the user values to determine at least one inference such that each inference corresponds to at least one disease.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The detailed description is described with reference to the accompanying figures. In the figures, the right-most digit(s) of a reference number identifies the figure in which the

reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0009] Figure 1 illustrates a network environment implementing a clinical decision support system, in accordance to an embodiment of the present subject matter.
[0010] Figure 2 illustrates a method for providing clinical decision support, in accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0011] A system and a computer-implemented method for clinical decision support are described herein. The systems and the methods can be implemented in a variety of computing devices, such as laptops, desktops, tablets, workstations, mainframe computers, and similar systems. Although the description herein is with reference to certain networks, the system and method can be implemented with different other networks albeit few variations as will be understood by a person skilled in the art.
[0012] Conventionally, the automation in medical profession is for administrative purposes. For example, a database is created and maintained to keep information of patients, their addresses, doctors who attended the patients, last visit, gender, age, patient complaints and like. These records are maintained to facilitate daily businesses of hospitals and clinics. For example, these records are used to assist doctors and other healthcare professionals to prescribe treatment based on previous diagnosis. Disease management has also advanced due to the introduction of practices such as Telemedicine, which has enabled healthcare professionals to cater to patients who are geographically dispersed. Although several aspects of the medical profession have been successfully automated in the past few years, the clinical decision making largely remains a manual activity.
[0013] In recent years, there have been efforts to evolve a clinical decision support system (CDSS) with all aspects of healthcare including diagnosis and post diagnosis care. However, with the complexity of clinical workflows and the demands on staff time, the institutions are not able to deploy the CDSS to this end. The CDSS are majorly deployed in a very small segment of overall healthcare. The use of the CDSS is thus typically limited to record keeping and involves manual inspection of medical records for determination of a disease.

[0014] In conventional techniques, the CDSS are mainly used for monitoring the patient's information like age, gender, patient's complaint and the like. The conventional CDSS are also used for supporting various health treatment packages in the clinical industry. However, none of the conventional systems provide solutions for disease diagnosis and treatment. The conventional systems are limited to information fetching systems vis-a-vis symptoms entered by a user.
[0015] In accordance with the present subject matter, a system and a computer-implemented method for clinical decision support are described. The system as described herein is a rule based system that diagnoses the existence of a disease using patient's inputs and logical rules built by a rule engine in the system. The diagnosis thus determined may be further used for a treatment regimen. According to an embodiment, the rule engine is configured to build a variety of logical rules. In one implementation, domain knowledge is converted into the logical rules that may assist a user, such as a medical practitioner in making an effective diagnosis. The logical rules thus incorporate domain knowledge of medicine in form of algebraic, mathematical or logical expressions. Based on inputs received from the medical practitioner, the rule engine, through the set of pre-configured logical rules, arrives at a diagnosis, which is then confirmed through a series of validations and then further used for managing treatment. The intelligence thus imparted by the clinical decision support system is effective in managing diseases and providing care to patients.
[0016] Further, the rule engine helps in automation and in making a diagnosis. The rule engine is configured to process rules using multiple iterations. In one implementation, the rules comprise a combination of parameters, values associated with said parameters, and a series of logical operators. The rule parameters may be understood as conditions or possibilities that are to be met for a logical rule to execute and to give an inference. For example, for a rule R which is “Fever AND Cough = Common cold”, ‘fever’ and ‘cough’ are rule parameters for the rule R. In other words, the rule parameter may also be referred to as symptoms of the disease which are preconfigured in logical rules. Thus, a logical rule may be understood as a structured query that comprises one or more rule parameters. Further, the rule parameter may have a plurality of predetermined values that can be provided by the user. After receiving an initial set of user values corresponding to one or more rule parameters, the rule engine processes these user values through a set of rule expressions and drives them through a set of iterations in order to arrive at an accurate diagnosis. The values thus received are processed through a series of rule

expressions, and compared against the various rules parameters of a further set of logical rules and any derived inferences from a prior set of processes rules. The logical rule with at least one rule parameter equal to the user value is selected by the rule engine. Based on the received user value corresponding to the rule parameters, logical rules are executed. Execution of a rule comprises iterating user inputs through a series of parameter sets which have been combined to construct rules that support decision making.
[0017] In one implementation, the logical rules may be executed based on strength of association of different rule parameters on a predetermined scale. For example, a domain expert may prioritize execution of a particular logical rule based on a combination of rule values received from user. For example, based on domain knowledge and expertise, a user may configure a logical rule to prioritize a combination of parameters such as ‘fever’ and ‘cough’ to infer ‘common cold’ over the inference ‘malaria’. In one implementation, all the logical rules are executed and the obtained inferences are prioritized based on their probability of occurrence, which in turn is determined on the strength of association of the parameter value with the rule expression. .
[0018] Further, the logical rules that can be built by the rule engine may vary in complexity. For example, a variety of logical rules varying from simple logical rules to complex logical rules can be built using the rule engine. In one implementation, users such as administrators and/or domain experts can be allowed to build the logical rules. For example, rules are built based on domain knowledge of domain experts such as neurologist, gynecologist, general physician, surgeon, pharmacist, and the like. Thus, clinical decision support system described herein is very flexible as rules can be configured based on the user knowledge, domain knowledge, new developments and the like to aid in diagnosis. The logical rules created can be stored in an internal repository of the system, or an external repository associated with the system.
[0019] In one implementation, the rule engine may receive additional user values to reiterate the previous inferences till the same inference is arrived at, in all further iterations. Alternately, if there is no match, the system can highlight a different inference as more parameter values are added. For example, the rule engine may receive further user values to be compared against the rule parameters. The matched logical rules are selected and executed. Thus, the rule engine

narrows down the selection of logical rules based on the user value received and matched against the rule parameters to arrive at a precise inference.
[0020] According to an implementation of the present subject matter, a user such as a medical practitioner or a nurse may provide user values to start with to the system. These user values may comprise details like presenting complaints or symptoms, personal history, past history, present history, social history, medication history or clinical examination findings as user value to the system, through a user interface. Based on the user value provided, the system identifies one or more set of rule parameters to initiate rule processing. The rule processing typically includes identifying a set of logical rules that aids in arriving at an inference, which subsequently determines a diagnosis. As previously stated, each logical rule is associated with a unique identifier and comprises at least one rule parameter for which one or more user values can be provided by the user. Further, the rule parameters may also include one or more sub-parameters and associated values.
[0021] The system initially selects one or more logical rules amongst pre-stored logical rules that match with the user values. Subsequently, the system retrieves a plurality of user values based on the rule parameters contained in the logical rules. The user values received are again compared with the logical rules to select and execute the logical rules to provide at least one inference. In another implementation, all the logical rules are selected having at least one rule parameter corresponding to the user value received. The rest of the rule parameters contained in the logical rules may probe question to further narrow down the selection of logical rules. Thus the rules may be combined based through mathematical and logical operators to provide an inference.
[0022] In one implementation, multiple layers/levels of rule parameters may exist within the system. For example, the rule parameter corresponding to the value ‘fever’ may have a plurality of sub parameters, which may correspond to values ‘high fever’, and ‘mild fever’. These sub-parameters may also have further layers of sub parameters, for example, indicating user values ‘high fever and shivering’ and ‘high fever with no shivering’ and so on. The user can provide user value corresponding to each of the rule parameters. Further, the values for the rule parameters are received as input from the user. In one implementation, the rule parameters can take on a plurality of values depending on the medical domain in which a CDSS operates, for

example, the parameters can have a binary type value (Yes/No or a True/False) or multiple objective values that can best be attributed to a parameter. Further, rule parameters define a ‘symptom’ and values for the parameter elicits a response from the user, which can be an equivalent of description of a ‘symptom’. Values for the said rule parameters are validated in a plurality of iterations to arrive at an accurate inference.
[0023] The retrieved rule parameters, sub-parameters, and the corresponding values are processed through a series of diagnostic modules that are configured to execute the logical rules and diagnose a particular disease or a group of related diseases in a patient. During execution, each of the diagnosis modules may further retrieve a plurality of other rule parameters, for example, sub-parameters or parameters in other layers, and display the same to the user on the user interface. For example, each diagnosis module may retrieve the rule parameters specific to that diagnosis module. On receiving user values corresponding to the other rule parameters, respective diagnosis modules compare, select, and execute the logical rules to derive inferences. In one implementation, derivation of each inference is based on a previously derived inference. This iterative process continues till no new inference can be derived. For example, when the last inference is same as previous inference, the iterative process of deriving inferences is stopped. In one implementation, the inferences may be prioritized based on a predetermined scale of the strength of association among a plurality of user values corresponding to one or more rule parameters.
[0024] In one implementation, based on the user value received and the iteration, the rule engine performs a provisional diagnosis to determine one or more provisional inferences. The system confirms the provisional inferences from among one or more provisional inference to determine at least one medical investigation result as per user value. The rule engine may infer provisional diagnosis along with at least one medical investigation result based on which additional user values must be received to select the logical rule. The medical investigation results may include, but are not limited to, blood pressure level, WBC count in the blood, level of sugar in the blood, presence of protein in the urine and the like. Based on the results obtained after the medical investigation, corresponding values are provided to the rule engine to continue the diagnosis. In one implementation, the user value may be received by the system based on the physical examination of the patient. For example, the user value may be received by the system

based on the physical examination by a doctor like physical examination of pulse rate, color of pupil of eyes and like.
[0025] In one implementation, the provisional inferences may be prioritized based on the strength of association of user values on a predetermined scale. The user may select or choose to prescribe the patient, a medical investigation based on the priority as inferred by the rule engine. For example, in case of multiple disorders, the priority may indicate which disease is more likely. The rule engine confirms the provisional inferences based on user values in response to medical investigation or physical examination results. One or more logical rules are selected and executed to provide at least one inference based on the user value received in response to the medical investigation results. The provisional inferences may be either inferred as final inferences or discarded as final inferences based on the user value received by the system from medical investigation results.
[0026] In one implementation, the inferences may be mapped to one or more diagnostic axes. Diagnostic axes are used to broadly group the symptoms and manifestations into a diagnosis or a plurality of diagnosis. The diagnosis axes are derived from domain knowledge. There may be multiple diagnosis axes that are predefined for an area of medical specialty. The derived inferences can be mapped to one or more diagnosis axes by the diagnosis modules, so as to provide a holistic view of diagnosis and to aid in disease management.
[0027] Based on such a mapping, a plurality of diseases can be identified and managed. A diagnosis thus derived can be applied for treatment. In one implementation, a pre-defined prescription template is generated for the patient based on the derived inference. The prescription template is pre-populated with names of the drugs, alternate choices for the same drug and a preferred dosage and means of administration. The healthcare practitioner is also provided with guidance, based on diagnosis to prescribe pharmacotherapy or other therapies and this may be based on details such as severity of the diagnosed allergies that a patient may have and so on.
[0028] In one implementation, a prescription is generated for the patient based on the identified diseases. The prescription may include, for example, prescribed treatments, medicines, dosages, etc for the one or more identified disease. In another implementation, the generation of the prescription may be based on receiving further inputs from the user. For example, further rule parameters may be retrieved specific to the identified disease, and displayed to the user to gather

specific details such as severity of the disease, family history of the disease, and the like. User response to such further rule parameters can be obtained and prescription can be generated based on received user value.
[0029] Further, the prescription may be based on a prescription template selected by the user. For example, the user may select the format of prescription based on his convenience indicating the patient's history and the like, with the prescribed treatment.
[0030] In one implementation, the treatment may be based on a plurality of treatment layers of the logical rules for selecting the correct treatment. The system may generate a matrix of different parameters based on which at least one inference can be drawn at each treatment layer of logical rules. The inference so obtained is fed on to the next treatment layer of logical rules. The next level of logical rule may further generate a matrix based on additional parameters. For example, the logical rules can be selected on the basis of a matrix comprising diagnosis and severity of a disease at first level of the treatment module. In one implementation, the selected logical rules based on the diagnosis and severity is further narrowed down in the second level of treatment. The matrix generated on the second level of treatment may be based on a number of visits, age, gender, and order of preference of a treatment. Similarly, in the third level of layers, logical rules may be based on the precautions that the patient must take in case of a particular disorder. Alternatively, it may also suggest order of preference of a treatment in case multiple disorders are detected. In one implementation, the treatment may also comprise dosages of medication.
[0031] In one implementation, the treatment module may prescribe a prescription template based on an intelligence layer. The intelligence layer may draw inference based on a matrix having a plurality of rule parameters and having at least one rule parameter indicating the medical investigation results. For example, the system may receive user value corresponding to rule parameter like ‘allergy’, ‘anemia’ and the like. Based on the user value received, the rule engine may select the logical rule which may be executed to infer variation in drug or dosage to the extent of discarding the drug.
[0032] In one implementation, the treatment layer may further comprise additional layers of logical rules which may provide additional information, for example, alerts based on the side effects seen in patient. In one implementation, the system can be further automated for post

treatment monitoring of a user. For example, the user’s post diagnosis health conditions may be analyzed to assess the improvement in patient’s health and to determine if the earlier provided prescription generated by the system should be varied based on the changes in the user’s current health conditions. In one implementation, patient's record at the time of generation of prescription is stored in a repository, and on the subsequent visit, the previous record(s) can be assessed by the medical practitioner to determine the improvement in the health of the patient.
[0033] In one implementation, each stage of screening, diagnosis and treatment can be configured to generate alert in response to user values received for a particular combination of rule parameters. The alerts may indicate need of intervention by the user. For example, alerts can be set for the user values corresponding to rule parameters which may indicate immediate attention like the need for IV Fluids, immediate referral to specialty centre, immediate oxygen, the need to look for or ask for other symptoms or signs and the like. Alternatively, alerts for physical examination of the patients can be set up, in case of specific user values like cough with blood in the sputum or fever with rigors.
[0034] In one implementation, the user may provide further user values based on the alert generated by the system. For example, based on the alert that indicates a possible dust allergy, the user may confirm or reject the possibility based on patient's input or symptoms. In one implementation, further diagnosis module may be generated by the system to diagnose the disease based on the further received user values in response to alerts. For example, based on the alert generated for dust allergy, the user value “itching” can be provided to the system by the user. Thus, based on alerts, the diagnosis of the disease may be varied by the system by selecting logical rules having rule parameters corresponding to the received user values.
[0035] In one implementation, an alert may be generated at the stage of generation of a prescription template based on the further inputs. For example, the alert may be set when a specific drug is selected by the user which must not be prescribed when a particular user value is received from the user. Alternatively, the alerts may be set to prescribe a particular treatment which is mandatory for a particular set of user values received by the system. In one implementation, the alerts may be set to change the last treatment prescribed based on further received user value.

[0036] The system and the method according to the present subject matter provides an automated, fast, and an efficient way of assisting the medical practitioners in making a clinical decision and/or prescribing treatments to the patients. The system analyzes the health condition of the patient to arrive at a determination of existence of a disease based on logical rules configured therein. The logical rules are dynamically configurable and thus can be modified as required with time. The system is further configured to provide post treatment diagnosis of a patient. The system may analyze the post treatment diagnosis based on factors like age, gender, medical illness, number of visits and the like, thus providing a complete assistance to the user.
[0037] These and other advantages of the present subject matter would be described in greater detail in conjunction with the following figures. While aspects of described systems and methods for medical rule engine can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s).
[0038] Figure 1 illustrates a network environment 100 implementing a clinical decision support system 102 for decision support in clinical diagnosis in accordance to an embodiment of the present subject matter. In said embodiment, clinical decision support system 102 is connected to and interacts with a plurality of computing devices 104-1...104-N, collectively referred to as the computing devices 104 and individually referred to as a computing device 104, over a network 106 through one or more communication links.
[0039] The clinical decision support system 102 may be implemented on a variety of computing devices, such as servers, a desktop computer, a notebook or portable computer, a workstation, a mainframe computer, and the like. The computing devices 104 may be implemented on a variety of computing devices, such as servers, a desktop computer, a notebook or portable computer, a workstation, a mainframe computer, laptops, notebooks, tablet computers, Personal Digital Assistants (PDA), mobile phones, multimedia enabled phones, smart phones, and the like.
[0040] Further, the network 106 may be a wireless network, a wired network, or a combination thereof. The network106 can also be an individual network or a collection of many individual networks interconnected with each other and functioning as a single large network, e.g., the internet or an intranet. The network106 can be implemented any of the different types of

networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network106 may either be a dedicated network or a shared network, and may use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), etc., for communication. Further, the network 106 may include network devices, such as network switches, hubs, routers, and host bus adapters (HBAs), for providing a link between the computing devices 104 and the system 102. Further, communication links between the clinical decision support system 102 and the computing devices 104 can be enabled through various forms of connections, for example, via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication.
[0041] In one implementation, the system and method for clinical decision support system 102 includes one or more processor(s) 108, interface(s) 110, and a memory 112 coupled to the processor 108. The processor(s) 108 can be a single processing unit or a number of units, all of which could include multiple computing units. The processor(s) 108 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 108 is configured to fetch and execute computer-readable instructions and data stored in the memory 112.
[0042] The interface(s) 110 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, a display unit, an external memory, and a printer. Further, the interface(s) 110 may enable the clinical decision support system 102 to communicate with other devices, such as web servers and external databases. The interface(s) 110 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the interface(s) 110 may include one or more ports for connecting a number of computing systems with one another or to a network. The Interface(s) 110 may also include those with medical Devices which can record medical parameters like Blood Pressure, Blood Sugar, Oxygen saturation in the blood (pO2), Electro cardiogram, and the like.

[0043] The memory 112 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In one implementation, the clinical decision support system 102 also includes module(s) 114 and data 116.
[0044] The module(s) 114, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The module(s) 114 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulate signals based on operational instructions.
[0045] Further, the module(s) 114 can be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit can comprise a computer, a processor, such as the processor 108, a state machine, a logic array or any other suitable devices capable of processing instructions. The processing unit can be a general-purpose processor which executes instructions to cause the general-purpose processor to perform the required tasks or, the processing unit can be dedicated to perform the required functions.
[0046] In another aspect of the present subject matter, the module(s) 114 may be machine-readable instructions (software) which, when executed by a processor/processing unit, perform any of the described functionalities. The machine-readable instructions may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium or non-transitory medium. In one implementation, the machine-readable instructions can be also be downloaded to the storage medium via a network connection.
[0047] In one implementation, the module(s) 114 further include a rule engine 115, a screening module 118, a diagnosis module 120, a treatment module 122, an improvement tracking module 124, and other module(s) 126. The other module(s) 126 may include programs or coded instructions that supplement applications and functions of the clinical decision support system 102 (hereinafter referred to as the system 102).
[0048] The data 116 serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the module(s) 114. The data 116 includes logical rules

117, screening data 128, diagnosis data 130, treatment data 132, improvement tracking data 134, and other data 136. The other data 136 includes data generated as a result of the execution of one or more modules in the module(s) 114.
[0049] In one implementation, the rule engine 115 is configured to build a variety of logical rules upon receiving a user value from a user. The logical rules are built based on domain knowledge, for example domain experts such as neurologist, gynecologist, general physician, surgeon, pharmacist, and the like may build such rules. In another implementation, the rule engine 115 is configured to build the variety of logical rules to derive inferences to be used for diagnosing a disease. Further, the rule engine 115 may use the inferences derived from one logical rule as an input to another logical rule in order to arrive at a conclusive inference for a set of symptoms.
[0050] Each of the logical rules may include one or more rule parameters. Each of the rule parameters may further include one or more sub-parameters or layers of sub-parameters. In one example, the rule parameters may be symptoms of various diseases. Further, each rule parameter and sub-parameter is associated with a value received from a user. The user may input one value from amongst a plurality of values assigned for each rule parameter. For example, for a rule parameter ‘fever’ a value ‘yes’ or ‘no’ can be assigned by the user. Each rule parameter may include one or more sub-parameter like ‘high fever’, ‘mild fever’ and ‘no fever’. For each sub-parameter, a plurality of value, for example ‘yes’ or ‘no’ may be provided by the user. In another implementation, the user values can be received based on predetermined options. For example, the user value can be provided to the system based on predetermined options like ‘high fever’, ‘mild fever’ and ‘no fever’ instead of binary inputs. In another example; a logical rule inferring viral infection may comprise rule parameters like ‘fever’ and ‘cold’.
[0051] Further, each logical rule may be associated with a unique identifier. In one implementation, several rule IDs are created for various combinations of rule parameters and their associated user values. Rule expressions are such that the value of a combination of rule parameters, rule sub-parameter and associated values, leads to an inference which may further prompt to receive user values for another series of rule parameters. Each logical rule points to another set of rule parameters that will be assessed based on user values and an inference will be

derived. The inference output is iterated based on the additional user values that are included in creating a logical rule to arrive at one inference.
[0052] Further, the Rule engine 115 operates in an iterative mode, wherein the first level of iteration considers user values in response to rule parameters and second iteration considers user values and inferences of the first iteration as input. Thus, inferences drawn for each user value corresponding to rule parameter is verified and validated at subsequent stages, until two or more iterations provide the same inference. Thus for example, in case a patient presents symptoms of fever, cough and shivering, the logical rules comprising parameters of these symptoms along with associated values of these parameters such as (mild fever, high grade fever etc) will be evaluated b the rule engine 115. Response to every parameter will prompt the rule engine 115 to point to a new set of parameters. An illustration of a rule is shown in the table 1.
Table 1

Module
S.No. Item User’s instructions Rules
Q1 Does he have a high fever? Rate the item as Yes, if the mentioned symptoms have been present Yes/No If Yes→ Go To Section B If No→ Go To The Diagnosis Module
Section B
Q2 Does he have shivering? Rate the item as Yes if shivering is present Yes/No Go To Q2
Q3 a b Does he have body ache or muscle ache? Rate the item as Yes, if muscle ache is present
Yes/No Go To Q3
Q4 Does he have Nausea? Rate the item as Yes if nausea is present Yes/No Go To Q4
Q5 Has he been perspiring? Rate the item as Yes if perspiration If all (Q2 to Q5) are Yes ---Go To Q6

is reported If any is No (Q2 to Q5) ---
Yes/No Go To The Diagnosis Module
Q6 a Does he have Weakness? Rate the item as If Yes→ Go To Q7
Yes, if symptoms If No → Go To The
b of weakness is
present
Yes/No Diagnosis Module
[0053] The rule engine 115 is configured to convert the above supplied value parameters along with algebraic, mathematical, and logical operators to evaluate and assess, and thereafter generate an inference. Each possibility may be identified with one unique identity R(i). For example, for the Q1 illustrated in the above table 1, the R(i) may be created as under,
R1= If Q1=Yes, then retrieve user value for corresponding rule parameter.
R2= If Q1=No; go to Module
R3= If Q2=Yes, go to Q3
and so on.
[0054] Based on the R(i) created for each possibility, various expressions can be formed for the series of action that the rule engine 115 can take. For example, if Q1 is marked yes, then the action is to probe Q2, Q3, Q4 and Q5 of section B. Similarly, other rule expressions can be formed based on values received for each possibility as illustrated in Table 2 below.
Table 2

Rule Expression Result
(R1) =1 Section B => (Q2, Q3, Q4,Q5)
(R1)=1 AND (R3 + R5 + R7 + R9) = 4 Q6
(R1)=1 AND (R3 + R5 + R7 + R9) < 4 Skip Module
(R1)=1 AND (R3 + R5 + R7 + R9 + R11) = 5 Q7
….. ….

[0055] When the user provides the user values to the questions, all the responses are assigned with the corresponding R(i). The R(i)s are then matched with corresponding rule expressions based on values received for each R(i). The rule expressions return either a true value or a false value based on the received user value. In one implementation, the rule engine 115 considers the result of the expressions having true values for the next set of actions. For example, as illustrated in table, if R1 receives a true value; i.e., 1 and at least one of R3, R5, R7 and R9 receives a false vale, i.e., 0, the diagnosis module is skipped and other diagnosis module is evaluated based on the received user value. It will be readily understood by the person skilled in the art that the above mechanism can also be implemented in a rule engine wherein user value is based on predetermined options.
[0056] In one implementation, logical rules within the system 102 can be updated by the user. For example, new logical rules can be added into the system 102 based on new developments or advancements in the field of medical science or preexisting logical rules can be edited or deleted from the system 102. For example, the user can modify the logical rules on the basis of his experience and practice. Alternatively, the rules may be modified to take user values for new rule parameters as inserted by user for inferences determined by him. For example, the user may insert a new rule parameter for a new diagnosis or another set of rules to diagnose the same disease using a different combination of parameters or investigative results for which user values can be received by the system.
[0057] As indicated previously, the logical rules assist users, such as medical practitioners, in clinical decision making. In one implementation, the users may interact with the system 102 through their respective computing devices 104 for clinical decision support. For clinical decision support, a user may provide patient data, such as disease symptoms, patient history and patient attributes data such as age, environmental characteristics and gender as an input to the system 102. In one implementation, the screening module 118 is configured to receive inputs from the user of the computing devices 104 through the interface(s) 110. Based on the patient data, the screening module 118 is configured to identify one or more logical rules amongst a plurality of pre-stored logical rules that match with the patient data.

[0058] Further, the screening module 118 retrieves a plurality of rule parameters contained in the logical rules. The rule parameters may be, for example, a set of questions for identifying general information like age, gender, patient diagnosis history, family history of any disease, medical illness like allergies and the like about the patient. The screening module 118 displays the retrieved rule parameters to the user, and subsequently obtains a user’s response to such parameters. The user’s response may be in the form of user values corresponding to the rule parameters. For example, the rule parameters may be in form of true/false type questions or objective type questions, and the values corresponding to such questions may be the binary values, i.e., either 0 or 1, or any other corresponding pre-defined value configured in a rule to obtain an inference. The user’s response to the initial set of rule parameters may be stored as screening data within the system 102.
[0059] Based on the rule parameters and the user values corresponding to the rule parameters, the screening module 118 invokes diagnosis module 120 configured to execute the logical rules to diagnose one or more diseases that the patient may be suffering from. The diagnosis module 120 may comprise of a plurality of diagnosis modules. Each of the diagnosis modules 120 is configured to diagnose a specific disease or a group of related diseases. In one implementation, the diagnosis module(s) 120 are configured to evaluate rule parameters by comparing, selecting, and executing the logical rules based on the user values corresponding to the rule parameters of the logical rules. In one implementation, the user values are received based on the standard procedure of the diagnosis of a particular disease for which diagnosis module(s) 120 is selected by the user. For example, based on the user values ‘fever’ and ‘cough’ received at the screening module 118, the diagnosis modules 102 corresponding to ‘common cold’ and/or ‘tuberculosis’ may be inferred. In one implementation, the user may assign a strength of association to a combination of user values based on a predetermined scale. The inferred diseases may be based upon priority set by strength of association of these user values with other rule parameters like age, gender, geographical location and the like. The strength of association may be determined based on a predetermined scale. For example, the strength of association can be assessed based on a scale of 1 to 100 base points. Alternatively, the strength of association may be based on scale based on alphabetical ratings like A+, A, B+, B and so on. Furthermore, strength of association of the rule parameters may be based on severity of

inferences which is determined based on user values received from user for rule parameters and rule sub-parameters.
[0060] In one implementation, the scale of strength of association may vary with the rule parameters, rule sub-parameters and user values. For example, for a disease D, the rule parameters P1 and P2 may have different scale of strength of association than for rule parameters P3 and P4. The scale of strength of association may vary based on patients’ screening history, symptoms and the like. Based on the priority, or otherwise, the user may select a symptom for further diagnosis, say ‘common cold’. Further the user values for symptoms may be received by the system.
[0061] Upon obtaining the user values corresponding to the rule parameters, respective diagnosis modules 120 are configured to select the logical rules from amongst the selected logical rules at the screening module 118. The selected logical rules may further be narrowed down by receiving further user values corresponding to rule parameters of the selected logical rules. Each of the diagnosis modules 120 performs this iterative process till no new inference can be derived. For example, when the last inference is same as previous inference, the iterative process of deriving inferences is stopped. In one implementation, derivation of each inference can be based on a previously derived inference.
[0062] In one implementation, the diagnosis module 120 may be configured to draw at least one provisional inference based on received user values. The provisional inferences are diseases which need to be confirmed based on additional user values like medical investigation results or physical examination results. The provisional inferences are inferred and provided with at least one medical investigation test. For example, the rule engine 115 may infer ‘Anemia’ and lung cancer as provisional inferences. Based on further user values received corresponding to rule parameter like ‘RBC count’ and lung related medical investigation results, at least one of the provisional inferences may be moved to a higher priority or confirmed as an inference by the diagnosis module 120. In another implementation, the system may suggest the medical investigation based on the domain knowledge incorporated in the logical rules. Thus, the inferences may be confirmed from among the provisional inferences based on at least one user value providing medical investigation result to the system.

[0063] In one implementation, the diagnosis modules 120 may be prioritized based on strength of association of various user values received from the user on a predetermined scale. Thus, for example, for a combination of a plurality of user values received from the user, a disease A may be more likely to be diagnosed as compared to a disease B, as understood in domain knowledge. This priority can be assigned to the combination of user values as strength of association through a predetermined scale.
[0064] In one implementation, the diagnosis modules 120 maps the inferences to one or more diagnosis axes. Diagnosis axes are used to broadly group the symptoms and manifestations into a diagnosis or a plurality of diagnosis. In one implementation, the diagnosis axes are derived from domain knowledge. Based on such a mapping, the diagnosis modules 120 are configured to identify one or more diseases that a patient may likely to suffer from. The diseases thus identified by the diagnosis modules 120 may be used for determining the treatment that may be given to the user. The diagnosis module 120 may subsequently save all the probable diseases thus diagnosed in the diagnostic data 130.
[0065] Based on the inferred diseases, the treatment module 122 with the system 102 may determine a plurality of modes of therapy to generate at least one prescription template for treatment of the user. In one implementation, the treatment module 122 may generate the prescription template based on a plurality of treatment layers of logical rules. The system 102 may receive user values for a predetermined matrix of rule parameters based on which at least one inference can be drawn at each treatment layer of logical rules. The inference so obtained at each treatment layer of logical rules is fed on the next treatment layer of logical rules. The next level of treatment layer of logical rule may further receive user values for a predetermined a matrix based on rule parameters of the logical rules at the respective next treatment layer of logical rules.
[0066] In one implementation, based on the inference or diagnosis generated by the rule engine 115, severity rating received from the user, a mode of therapy is determined at a first treatment layer of logical rule. For example, at the first treatment layer, the treatment module may determine one or more of pharmacotherapy, hospitalization, and various other therapies that are deemed fit according to the diagnosis, and a combination thereof as the mode of therapy. Further, at the second treatment layer, the treatment module 122 may be configured to generate

the prescription template based on the diagnosis and patient information, such as age, gender, patient's medical history, medical illness and the like. In one implementation, the prescription template may include options for providing drugs and suitable dosages of the drug for the patient that may be suggested by the user based on recommendations received from the treatment module 122. For instance, the treatment module 122 may be configured to suggest drugs suitable for the treatment of the patient. In one implementation the treatment module 122 may provides a list of drugs in the order of preference based on which the user may select a suitable drug.
[0067] In one implementation, a third layer of logical rules may be based on the precautions that the patient must take in case of a particular disorder. Alternatively, it may also suggest order of preference of a treatment in case multiple disorders are detected. In one implementation, the treatment prescription may also comprise dosages of medication. In one implementation the third treatment layer of logical rules may determine at least one restrictive dosage of medication from amongst the dosages suggested at any of the at least first and second treatment layer of logical rules. The restrictive dosages are dosages of medicine that should be avoided or reduced from amongst the suggested dosages due to existence of a particular disease or medical illness. For example, a patient A may be prescribed with lower amount of a particular medication due to existence of an allergy or a condition like renal disorder. Such medication may be referred to as restrictive dosage. In one implementation, the treatment layer may further comprise of additional treatment layer of rules which may provide additional information, for example, alerts based on the side effects seen in patient. In another implementation, the treatment module 122 may provide different dosage package for one or more disease based on parameters like age, severity, medical illness order of preference and the like.
[0068] In one implementation the treatment module 122 may prescribe a prescription template based on an intelligence layer, wherein the prescription template may be generated based on at least one of the medical investigation results and user values. For example, the system may receive user value corresponding to rule parameter like ‘allergy’, ‘anemia’ and the like. Based on the user value received, the rule engine may select the logical rule which may be executed to infer variation in drug or dosage to the extent of discarding the drug. In another implementation, the treatment module may prescribe a treatment based on any of the user values received by the system 102 in screening module 118 and diagnosis module 120.

[0069] In one implementation, each of the screening module (118), the diagnosis module (120), and the treatment module (122) is configured to set an alert for a combination of user values received in response to a combination of rule parameters. These alerts may prompt a need of an intervention from the user. For example, based on severity of fever and dehydration, an alert for IV Fluids can be set by the user. Similarly, an alert can be set when user values received may indicate a communicable disease or an epidemic. In one implementation the alerts can also be set for physical examination of the patient. For example, an alert can be set for specific physical examination of body part.
[0070] In one implementation, the diagnosis of the disease at the diagnosis module (120) may vary based on the user values received by the system. For example, for the alert of high blood sugar, further user values may be received by the system for diagnosis. Based on the further received user values, the diagnosis module (120) may select further logical rules that may be executed to vary the inferences.
[0071] In one implementation, the user values received in response of the alerts generated at the treatment module (122) may vary the prescription template generated in the treatment module (122). In one implementation, the prescription template may vary based on the user values received in the screening module (118) and diagnosis module (120). For example, based on the alert generated for diabetes, medicine prescribed in the prescription template may vary. Alternatively, the system 102 may vary the dosage of medicine on the user values received in response to the alerts generated at screening module (118), diagnosis module (120) and treatment module (122).
[0072] In one implementation, an improvement tracking module 124 with the system 102 is configured to track improvement in the patient’s health condition based on user values of the patient, received through the computing devices 104 in an improvement tracking format after the patient is prescribed with at least one treatment by the user. For example, the improvement tracking module 124 may update the health conditions of a patient as improvement, deterioration, or stagnant condition of patient after first treatment in the improvement tracking format. The user may further provide health conditions of the patient as input to arrive at a suggestion. For example, the user may provide input of patient as improving in the improvement tracking format. The user may further provide specific details like medical investigation results

like blood pressure, blood sugar level and like in the improvement tracking format. Based on the inputs to the improvement tracking format, the improvement tracking module 124 may execute appropriate logical rules and may vary the dosage prescribed by the treatment module 122. In one implementation, the improvement tracking module 124 may take additional inputs like number of previous visits, age, gender, patient medical illness like allergy from previously prescribed medicine to vary the dosage prescribed. Additionally, the improvement tracking module 124 may prescribe different treatment in case the treatment is not proving to be efficient for the patient. The improvement tracking module 124 may further save the prescription treatments and prescriptions thus obtained in the improvement tracking data 134.
[0073] Figure 2 illustrates a method 200 implementing a rule based decision support system 102 for decision support in clinical diagnosis, according to one embodiment of the present subject matter. The method 200 may be implemented in a variety of computing systems in several different ways. For example, the method 200, described herein, may be implemented using the rule engine 115 for assisting the user in the clinical decision support in diagnosis, as described above.
[0074] The method 200, completely or partially, may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. A person skilled in the art will readily recognize that steps of the method can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of the described method 200.
[0075] The order in which the method 200 is described is not intended to be construed as a limitation, and some of the described method blocks can be combined to implement the method, or an alternative method. Additionally, some of the individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or

combination thereof. It will be understood that even though the method 200 is described with reference to the rule engine115, the description may be extended to other systems as well.
[0076] At block 202, one or more logical rules are identified based on at least one user value provided by a user. In one implementation, the user value may be received from a user of a computing device, such as the computing device 104. For example, the user may be asked to provide the patient’s age and gender, and symptoms as can be perceived by the user or as explained by the patient to the user. Based on the patient data received by the system, a plurality of rules provided in a rule engine 115 is identified having at least one rule parameter equal to at least one user value received by the system 102. The user value may be received in response to a question that may provide inferences for diagnosis. In one implementation the rule parameter may further include sub-parameters. For example, a sub parameter may qualify a parameter on severity. In another implementation, a plurality of layers/levels of rule parameter may be present in the system 102
[0077] At block 204, at least one user value is received corresponding to each rule parameter from the user. For example, the user may input value ‘high’ or ‘normal’ as value to rule parameter ‘fever’. In one implementation, the value can be received in form of binary answers. For example, the values can be received as true-false format wherein true assigns a value 1 and false assigns a value 0 to rule parameter. In another implementation the user value may be received as one of predetermined options. For example, the user may choose options from one or more options to be provided as user value corresponding to a rule parameter.
[0078] At block 206, the logical rule having values for their respective parameters are executed to obtain inferences. For example, the logical rule defining common cold may be executed on receiving value for temperature as ‘high’ and sneezing as ‘yes’. In one implementation the system reiterates the process of receiving the additional user values and executing the logical rules till the inferences obtained don’t change with execution of logical rules on receiving further patient data.
[0079] At block 208, the rule engine 115 may identify one or more disease based at least on the inferences. In one implementation, the rule engine 115 may infer at least one provisional inference based on the received user values corresponding to the selected logical rules. The provisional inference are disease inferred based on the received user value and must take

additional user values corresponding to one or more rule parameter indicating medical investigation or physical examination results. For example, provisional inference may be confirmed based on the rule parameter like ‘blood sugar level’.
[0080] In one implementation the inferences are prioritized based on strength of association of user values corresponding to a plurality of rule parameter on a predetermined scale. For example, a set of user value received for a combination of rule parameter may be closely associated with one kind of disease then other by domain experts. Based on such likeliness of having a disease, rating is provided to combination of user values on a predetermined scale of strength of association through logical rules. Based on rating of strength of association of user values, the inferences may be prioritized for the ease of user.
[0081] In one implementation, the inferences are mapped to one or more diagnosis axes. The diagnosis axes are classification of diseases based on predefined categories. The classification of disease into diagnosis axes may further receive patient data peculiar to that diagnosis axis for accurate diagnosis of the disease. In another implementation, one or more related disease, may be identified based on the diagnosis axes based on the specific diagnosis axes. In one implementation, the diagnosis module 120 is configured to identify the diseases based on the mapping of the inferences with the diagnosis axes.
[0082] At block 210, prescription for the treatment of the identified diseases is generated. The prescription may include, for example, drug, drug dosage and like. In one implementation, the treatment is configured to generate prescription in a prescription template. In one implementation, the treatment prescription is provided based on multi-layer logical rules. The rule engine 115 derives inference at each treatment layer of logical rules based on matrix of different parameters. For example the first treatment layer of logical rule may comprise selection of logical rules based on severity and diagnosis. The second treatment layer of logical rule may further receive values against rule parameters like number of visits, level of improvement, age, gender, order of preference and the like. The logical rules are further selected based on the matrix generated by rule engine 115 and values received by the system from user. In one implementation, the treatment module 122 may have such additional treatment layers as determined by the person skilled in the art for correct prescription template. In one implementation, the treatment module 122 may comprise at least one treatment layer of logical

rules having logical rules selected based upon side effects seen in the patient. In one implementation prescription template may be based on the medical investigation results. For example, the system may receive user value corresponding to rule parameter like ‘allergy’, ‘medical illness’, ‘anemia’ and like. Based on the user value received, the rule engine 115 may select the logical rule, which may be executed to infer variation in drug or dosage to the extent of discarding the drug.
[0083] Although implementations of system and method for clinical decision support have been described in language specific to structural features and/or methods, it is to be understood that the present subject matter is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as implementations of clinical decision support system.

I/We Claim:
1. A clinical decision support system (102) comprising:
a processor (108);
a screening module (118) coupled to the processor (108), wherein the screening module (118) is configured to obtain user values for each of a plurality of rule parameters from a user;
a rule engine (115) coupled to the processor (108), wherein the rule engine (115) is configured to identify one or more logical rules, from among a plurality of logical rules, based on the user value, wherein each of the plurality of logical rules includes a combination of the plurality of rule parameters and rule expressions; and
a plurality of diagnosis modules (120) coupled to the processor (108), wherein each of the plurality of diagnosis modules (120) is configured to execute the one or more logical rules based at least on the plurality of rule parameters and the user values to determine at least one inference, wherein the at least one inference corresponds to a disease.
2. The clinical decision support system (102) as claimed in claim 1, wherein the screening
module is further configured to:
receive at least one patient data; and
identify at least one rule parameter based on the at least one patient data.
3. The clinical decision support system (102) as claimed in claim 1, wherein the clinical decision support system (102) further comprises a treatment module (122) coupled to the processor (108), and wherein the treatment module (122) is configured to recommend a mode of therapy from among a plurality of modes of therapy based on at least one of a plurality of treatment layers, inferences, and severity of a disease corresponding to the inferences.
4. The clinical decision support system (102) as claimed in claim 3, wherein the treatment module (122) is further configured to generate a prescription template comprising at least one of the disease corresponding to the inferences, drug, drug dosages, package of prescription, and a medical investigation.

5. The clinical decision support system (102) as claimed in claim 3, wherein the treatment module (122) is further configured to generate a prescription template comprising at least one of a plurality of dosages, and a suggested surgery based on a matrix, and wherein the treatment module (122) is configured to generate the matrix based on at least one of a number of visits, age, gender, inferences, medical investigation result, patient data, user value and order of preference of a treatment.
6. The clinical decision support system (102) as claimed in claim 3, wherein the treatment module (122) is further configured to determine at least one restrictive dosage from among the plurality of dosages based on the inferences.
7. The clinical decision support system (102) as claimed in claim 1, wherein the rule engine (115) is further configured to create the plurality of logical rules based on the plurality of rule parameters, one or more rule sub-parameters, user values corresponding to each of the plurality of rule parameters, user values corresponding to each of the one or more rule sub-parameters, and the rule expressions.
8. The clinical decision support system (102) as claimed in claim 1, wherein, the rule engine (115) is further configured to iterate the execution of the one or more logical rules to determine the at least one inference based on the at least one inference and additional user values, and wherein the iteration is performed till an inference of current iteration is equal to inference of a prior iteration.
9. The clinical decision support system (102) as claimed in claim 1, wherein the diagnosis module (120) is further configured to perform a provisional diagnosis to determine one or more provisional inferences.
10. The clinical decision support system (102) as claimed in claim 1, wherein the diagnosis module (120) is further configured to:
determine priority of inferences based on a scale of strength of association of the rule parameters of the logical rules, wherein the strength of association of the rule parameters of the logical rules is based on severity of the inferences, and wherein the severity of the inferences is based on at least one of the user values corresponding to each of the plurality of rule parameters and the user values corresponding to each of the one or more rule sub-parameters; and

provide the prioritized inferences to the user in a predetermined order of priority and the scale of strength of association corresponding to each of the inferences.
11. A computer implemented method for clinical decision support, the method comprising:
obtaining user values for each of a plurality of rule parameters from a user;
identifying one or more logical rules, from among a plurality of logical rules, based on the user value, wherein each of the plurality of logical rules includes a combination of the plurality of rule parameters and rule expressions; and
executing the one or more logical rules based at least on the plurality of rule parameters and the user values to determine at least one inference, wherein the at least one inference corresponds to a disease.
12. The method as claimed in claim 11, wherein the method further comprises identifying the plurality of rule parameters based on at least one patient data.
13. The method as claimed in claim 11, wherein the method further comprises recommending a mode of therapy from among a plurality of therapy using at least one of a plurality of treatment layers, inferences and severity of the disease corresponding to the inference.
14. The method as claimed in claim 11, wherein the method further comprises generating a prescription template comprising at least one of a plurality of dosages, and a suggested surgery based on a matrix, and wherein the treatment module (122) is configured to generate the matrix based on at least one of a number of visits, age, gender, inferences, severity of the disease corresponding to the inferences, drug, drug dosages, package of prescription, medical investigation results, patient data, user values and order of preference of a treatment.
15. The method as claimed in claim 14, wherein the method further comprises determining at least one restrictive dosage from among the plurality of dosages based on the inferences.
16. The method as claimed in claim 11, wherein method comprises creating the plurality of logical rules based on the plurality of rule parameters one or more rule sub-parameters, user values corresponding to each of the one or more rule sub-parameters and the rule expressions.

17. The method as claimed in claim 11, wherein the method further comprises iterating the execution of the one or more logical rules to determine the at least one inference based on the at least one inference and additional user values, and wherein the iteration is performed till an inference of current iteration is equal to inference of a previous iteration.
18. The method as claimed in claim 11, wherein the method further comprises performing a provisional diagnosis to determine one or more provisional inferences.
19. The method as claimed in claim 11, wherein the method further comprises:
determining priority of inferences based on a scale of strength of association of the rule parameters of the logical rules, wherein the strength of association of the rule parameters of the logical rules is based on severity of the inferences, and wherein the severity of the inferences is based on at least one of the user values corresponding to each of the plurality of rule parameters and the user values corresponding to each of the one or more rule sub-parameters; and
providing the prioritized inferences to the user in a predetermined order of priority and the scale of strength of association corresponding to each of the inferences.
20. A computer-readable medium having embodied thereon a computer program for
executing a method for clinical decision support, the method comprising:
obtaining user values for each of a plurality of rule parameters from a user;
identifying one or more logical rules, from among a plurality of logical rules, based on the user value, wherein each of the plurality of logical rules includes a combination of the plurality of rule parameters and rule expressions; and
executing the one or more logical rules based at least on the plurality of rule parameters and the user values to determine at least one inference, wherein the at least one inference corresponds to a disease.