Medical Diagnosis System _MDS_ 2022 v01012023.pdf

Medical Diagnosis System
Design & Framework
Shubhadha Iyer
White Paper January 2023
This White Paper provides the High-level Design (HLD), Framework and
functionality for a Medical Diagnosis System (MDS), envisioned by the author
Shubhadha Iyer (S.Iyer) --Management Consultant/ Sr. Business Analyst (M.S.-
USA, IIT B.Tech, PGDBA) with 15+ years’ work experience, including 5+ year’s
project experience in Healthcare IT/software. It is to be significantly noted that
S.Iyer has never been involved on any project or training, concerning the subject
matter of this paper i.e., clinical or medical diagnosis and related areas.
Information in this document is entirely the result of S.Iyer’s own independent
research, study and solution formulation and has no connection whatsoever to
any past or present work taken up by S. Iyer for companies.
Confidential
The document is being submitted for a general review and not to be included as
part of any initiatives or for any purpose other than review and evaluation,
without the author Shubhadha Iyer’s official participation. In addition to general
discussions based on online research, and the author’s analytical observations
this White Paper may contain certain confidential information prepared by the
author Shubhadha Iyer, marked with a copyright for 2023 © by S. Iyer where
applicable. These sections are meant to be kept confidential.

Contents
Medical Diagnosis Systems (MDS) for Self-Diagnosis.....................................................................................................4
 Introduction........................................................................................................................................................4
Market Analysis ..............................................................................................................................................................5
Current Challenges for MDS...........................................................................................................................................6
Challenges for Medical Diagnosis Applications......................................................................................................6
Scope of the MDS Design .......................................................................................................................................6
Framework for a Medical Diagnosis System ..................................................................................................................7
Object Oriented Design (OOD) ...............................................................................................................................7
Matching based on Condition-Symptom Sets........................................................................................................7
Symptom Features (SF)...........................................................................................................................................7
Condition-Symptom Profiles...................................................................................................................................8
Design of the Medical Condition ............................................................................................................................8
MDS Process for Symptom Matching and Verification ........................................................................................10
Equations for MDS Scoring...................................................................................................................................16
Configuration of the MDS Meta Data...................................................................................................................17
Overview of the Matching Process.......................................................................................................................19
MDS Scoring Methodologies ................................................................................................................................20
Detection of Comorbidities and Co-existing Conditions ......................................................................................26
MDS Process for Disease Detection .....................................................................................................................26
Workflow Example for the MDS...................................................................................................................................27
Case Examples: Symptom Matching and Scoring.................................................................................................30
Case Examples: Condition Matching and Scoring.................................................................................................31
Limitations and Constraints..........................................................................................................................................35
Future Enhancements ..................................................................................................................................................36
Appendix.......................................................................................................................................................................37
Symptom Feature (SF) for HPI Matching..............................................................................................................37
Symptom Weightage Model for this MDS............................................................................................................39
Rule types for Medical Diagnosis..........................................................................................................................39
Methods to calculate Matching and Risk factors .................................................................................................40
Reference Sources........................................................................................................................................................41

Medical Diagnosis System January 1, 2023
3 | P a g e
Prepared by Shubhadha Iyer Confidential
Tables & Figures
Table 1 Symptom Profile matching Scores for Top Conditions....................................................................................30
Table 2 Condition Matching and Scoring......................................................................................................................31
Table 3 Final scores based on Test Results...................................................................................................................32
Table 4 Case Examples: MDS Process Steps with Score calculations...........................................................................33
Table 5 Symptom Feature Values for HPI Matching.....................................................................................................37
Figure 1 MDS API Classes................................................................................................................................................9
Figure 2 MDS API Classes................................................................................................................................................9
Figure 3 MDS Object Model .........................................................................................................................................11
Figure 4 MDS Object Model .........................................................................................................................................11
Figure 5 MDS Workflow................................................................................................................................................15
Figure 6 MDS Workflow................................................................................................................................................15
Figure 7 MDS Workflow (Matching of HPI) ..................................................................................................................16

4 | P a g e
Medical Diagnosis Systems (MDS) for Self-Diagnosis
 Introduction
Empowered by different types of AI, the technology for automated Medical Diagnosis has shown good
progress in recent years. Online symptom checkers have especially gained popularity in the form of Mobile
Apps that enable users to self-diagnose and triage. This paper takes a look at Medical Diagnosis Systems
that work similar to Medical Symptom Checkers. Observing the many benefits that such a tool can provide,
we then propose a design and framework for an online Medical Diagnosis System in the same product
category. Vast research and studies have already been accomplished by scholars and scientists in the field.
In this paper, the aim is to add some innovative design features as part of a practical diagnosis solution.
Medical Diagnosis Systems and related Tools have an important role to play in Healthcare
Medical Diagnosis Systems are a type of Clinical Decision Support system (CDSS). Of these, Symptom
Checkers have emerged as a popular tool. Starting with a set of known symptoms entered by the user, the
Medical Symptom Checker will interactively ask the user a series of questions regarding the patient, then
process the input symptoms, answers, and related information to arrive at the correct diagnosis.
Getting the Right Diagnosis, then finding the Right Treatment
Between experiencing a health problem to locating the best doctor/ specialist and getting the right
treatment for an illness-- then preparing for other complications, there’s many a battle to be won!
 We know that Doctors and medical professionals work round the clock to save people from illness.
 The medical diagnostic thought process that goes on in a Doctor’s head is truly amazing and
inimitable. Yet, in many parts of the world, a patient must deal with crowded Hospital waiting lines
and rushed, impatient Hospital staff before finally getting diagnosed and treated.
 In this landscape, medical diagnosis tools can narrow down all possible causes, and prepare the
patient with prior knowledge—thereby reducing the waiting time before Patient meets Doctor.
 People in remote areas will need medical diagnosis too, and this includes many possible settings.
You may be living at a faraway location, or just out on a Camping trip when a problem strikes.
 Understanding all possible causes, and based on that, learning about First Aid options, and courses
of treatment can save you a significant amount of time, suffering and confusion.
 Getting a more comprehensive, incisive Diagnosis on a condition can help the patient seek effective
treatment plans, which could be a lifesaver in the long-term.
 For example, a patient with severe burning sensation was diagnosed by the Doctor simply as an
internal infection. The patient was treated for infection and seemed to recover. Five years later,
after a sudden downturn, it was discovered the patient also had an insidious Cancer malignancy
that had exacerbated in recent years. By then, it was too late.

5 | P a g e
 A good Medical Diagnosis application can literally go a long way in dealing head-on with all aspects
of the current problem. It can help plan in advance for future complications, and co-morbidities.
As an informed patient, you can ask your Physician focused questions, well in time.
 Not just for confused and neglected people patients, there are destitute animals needing medical
attention, but live Veterinary expertise may not be there on the spot. Mobile diagnostic aids can
help animal welfare groups understand the medical problem, connect the animal to the right
doctor, and get them the treatment they need in a cost-effective way.
Market Analysis
We see the exciting, cutting-edge field of automated Medical Diagnosis is still growing! Medical Symptom
Checker Apps are now being actively researched and reviewed, with a few “top of the list” Symptom
Checkers renowned for providing diagnosis with high accuracy. We take stock of some new age products
and solutions currently available for Medical Diagnosis.
Recent Products in
Medical Diagnosis
Observations
 Medical Symptom
Checkers
Known as convenient tools to enable self-diagnosis and triaging of issues,
this technology has seen increasing usage in recent years.
 Tele Health
Tele Health platforms are now popular, widely available, and it works! The
view forwarded here, is that Symptom Checkers can work with Tele Health,
to better inform and prepare the user, before signing up for TH sessions.
 Google Search
A convenient way to browse and explore a wide range of causes,
possibilities, and many other aspects of a health problem. However, we do
have to manually process this online information overload using our own
judgment, with no medical expertise to guide us to the right diagnosis.
 AI/ ML Models for
specific Diseases
Trained AI-based Models that use Classifiers, Neural Networks and other
models, are increasingly used to predict certain diseases. They are also
used in symptom checkers. The data is often input from Medical devices.
 Medical Devices to
detect specific
Conditions
Devices to diagnose and monitor specific conditions E.g., Diabetes,
Alzheimer’s, Heart health and comorbidities. These devices have made
great strides within the spectrum of each disease.
 Fitness devices &
Wearables
Health data can be sourced from other types of gadgets including fitness
and Wearables, and these can be utilized as part of an AI/ ML solution.

6 | P a g e
Current Challenges for MDS
Challenges for Medical Diagnosis Applications
To be able to drill down from a generic set of ailments, right down to one or more causes, is no doubt
a formidable task, one that challenges the latest in Healthcare IT/Software, Technology, and AI/ ML.
 One way to make this work would be for a generic diagnostic application to first gather
information, arrive at a preliminary set of conditions/ causes, and feed its output into other
specialized Disease-based programs. For this, we need an Ecosystem with the generic top-level
diagnosis bot, to network with the disease-specific bots, downstream on the diagnostic path.
 A realistic symptom checker must interface with the user’s Medical History, specifically: -
o Should be possible for the MDS to take in Patient data including demographics.
o Should be possible to take in Patient Medical History and Family Medical History.
o Should be possible to take in Vital Signs, and other signs data if required.
o As medical Test Results usually play an important role in the diagnosis, it should be
possible for the system to request and process this information.
 Cases resulting in multiple diagnosis should be managed accurately, to arrive at a Primary
diagnosis as well as other levels. The MDS should also facilitate the detection of Comorbidities.
 The design should be flexible, dynamic and extensible to accommodate any number of changes
in the medical data, rules, and logic so that we can keep building on its knowledge base.
Scope of the MDS Design
In the current design, we start with functionality similar to that of a symptom checker, which should include
a Medical knowledge base of symptoms and diseases.
 In response to multiple input symptoms entered by the user, along with patient demographics, a
list of probable conditions should be generated from the database. Until and including this step,
the proposed MDS is meant to be similar to a standard symptom checker.
 Looking beyond the first step, the current approach examines some design enhancements in
selected parts of the clinical diagnostic process. This is an effort to narrow the search focus and
refine the list of probable conditions. Specifically, we have applied deeper matching logic for
symptom-based matching based on HPI elements or symptom features configured in the MDS.
 The design considers matching and scoring algorithms to further refine the numeric score, based
on “symptom profiles” as configured for each medical condition. This is followed by condition-level
matching and scoring, for which the logic considers matches based on associated symptoms and
signs for that condition. The condition object is represented by symptoms, signs, and a number of
factors that work to support or reduce the condition probability.
 This MDS also provides a “reverse” process of disease detection for a given input disease.

7 | P a g e
Framework for a Medical Diagnosis System
The design suggested here, applies design concepts based on the following approaches: -
Object Oriented Design (OOD)
The following objects are used in this design.
1. Object to represent Patient Data including Age, gender, and BMI. This object design allows basic
patient demographics to be provided.
2. Object to represent the Medical Condition. Every condition is linked to multiple condition-symptom
objects, which we call the “condition-symptom set” and this refers to some basic symptoms.
3. Objects to represent the medical Symptom(s) and signs (considered to be the Chief Concern, CC)
and multiple Symptom Features (SF) based on HPI for each condition-symptom match.
4. Object to represent the Medical Condition-Symptom association.
5. Other objects to represent the Past Medical History (PMH) and Family History (FH) which should
include structured information on pre-existing conditions, medications and allergies.
6. Object to represent the user input for Vital Signs. Body temperature, heart rate, BP and other signs.
7. Object to enable input and processing of suggested Tests and structured Test Results information
at the Condition level.
Matching based on Condition-Symptom Sets
Input symptom(s) and associated symptoms entered by the user, will be matched to existing medical
conditions in the database through their linked condition-symptom sets.
8. We start with a set of all matching combinations between a list of input symptoms (S1´, S2´, S3´,S4´)
and medical conditions (MC1, MC2, MC3) each of which has a “condition-symptom set” (MC1 : {S1,
S2}, MC2 : {S2, S5}, MC3 : {S2, S3, S6}). And in case of multiple matches for the same condition,
consider only the match with the highest number of matching symptoms. We get what we refer to
here, as the initial set of “condition-symptom set matches” which we then list and rank in order of
relevance to the problem (Condition-Symptom matches: - MC1: {S1, S2}, MC3: {S2, S3}, MC2: {S2}).
Symptom Features (SF)
For diagnosis, each symptom must be fully and accurately described with qualitative and numeric
measures where required. In the current design the Symptom Features (SF) object enables this.
9. An instance of “Symptom Features” is expected to capture all key elements of the “History of the
Present Illness (HPI)” in extended format. Every time the user enters a symptom, the symptom
features must also be input.
10. Furthermore, the current design allows a symptom associated to a condition to have multiple
“symptom features” set up for it. These may be used typically to describe symptoms on different
body parts (with “Location” as the key and/ or other keys such as disease “Stage”, “Severity”, or
“Progression”). Associations between profiles are allowed, this version supports hierarchies.
11. Think of the Symptom Features as a “condition-symptom profile” that can facilitate the matching
process, and ultimately serve to construct the disease profile.

8 | P a g e
12. User is expected to enter “Associated Symptoms and signs” as part of the HPI for each input
symptom. This design and framework adopt the following convention: -
 Terms in this element are meant to describe “signs” related to the symptom e.g., “Visible
signs of inflammation”) and may also contain other symptoms associated to the given
symptom profile e.g., “Deformity of joints” associated to “Joint Pain” for certain profiles.
Note: - there are associated symptoms and signs also directly linked at the condition level.
13. Certain types of rules involved in matching and score calculations are also referenced in this object.
Condition-Symptom Profiles
As noted earlier, there can be multiple “Symptom Features” (SF) associated to a given condition-
symptom (also referred to as “condition-symptom profile” or “symptom profile”) in this design.
 The SF profile may be based on Location as the index “key”, and/or some other key.
o For example, Osteoarthritis (OA) profiles were created based on the disease stage (or severity), with
the profiles being categorized as “Early” stage, “Mid” stage and “Late” or “Advanced” stage.
o To describe Rheumatoid Arthritis (RA), a symptom profile was created for “Leg joints” (MC1_S1_SF1).
We may want to expand on this, by adding symptom features for “Shoulder pain” related to RA,
setting up a separate symptom profile (MC1_S1_SF2) for the “shoulder” location.
 For a condition, at least one SF profile should match with user inputs for it to be added to
the matching condition-symptoms list, but not all SF profiles have to match. Logically, this
depends on what “keys” are used to construct the symptom profile.
 When a configured SF profile matches the input symptom profile to satisfy a particular
condition, the matching score that is computed indicates to what extent or percentage they
are matching, based on a comparison of all the HPI elements.
 To summarize, how accurately each SF profile is configured, and how weights or parameters
are set for the scoring algorithms -- will determine accuracy of the match for symptoms.
 Matching score calculations also involve certain types of rules as configured at multiple
levels. There are factors and signs that, if found relevant and applicable to the case, will
increase or reduce the probability or risk of a condition-symptom match. This functionality
is driven by rules that process Patient data, HPI input data, medical history, and Test Results,
and may result in an adjustment to the matching scores at every step. To summarize, in
addition to these approaches: - Medical Knowledge base, APIs for matching and scoring,
Probabilistic methods, Fuzzy logic, and interfaces for running AI/ ML data matching models,
this design also applies Rule-based processing at Condition and Symptom features level.
Design of the Medical Condition
Medical Conditions have been widely modeled and applied in Healthcare IT/software applications.
 Beyond the basic constructs, we consider some attributes that serve to refine the diagnosis.
a. Condition-Symptom set: - Set of basic symptoms associated with a medical condition.
b. Signs: - Signs information that can be used for diagnosis at the condition-level.
c. Risk factors: - List of factors that increase the risk i.e., matching score for that condition.
d. Contradicting factors (contraFactors): - List of factors that will eliminate the condition as
a possibility or reduce the condition matching score.

9 | P a g e
Figure 1 MDS API Classes
Figure 2 MDS API Classes

Further details on the MDS workflow and functionality suggested in this design are outlined as follows: -
1. Step 1- Matching Symptom Sets based on Symptom Names
This program deploys algorithms to keep adjusting the matching scores based on interactive data
inputs and results. Starting with this step,
a. User is asked to enter the Patient Data (PD) including Age, Gender and body mass index BMI.
b. The user is asked to enter the symptom(s) into the MDS.
c. Matching initially involves an attempt to match the input symptom name(s) with the
symptom sets pre-configured for medical conditions in the database.
d. A list of matched conditions is generated (in memory), the extent of matching computed as
a weighted average score in each case. The starting list of matched conditions can result in
a long, exhaustive list. E.g., Four (4) common input symptoms (15 symptom combinations)
must consider (medically valid) disease matches with all of these combinations.
e. It is observed that in order to confirm a medical condition, certain symptoms will play a
more important role. To enable this, weights are attached to condition-symptoms, to
indicate how critical the symptom is to diagnose that condition.
f. A top matching rank at this point simply means that based on the input symptom name(s) -
the number of matching symptom(s) is highest for that condition and/or the highest number
of top/severe symptom(s) have matched. For details on the MDS scoring and matching
methodologies applied in this design, refer to the section: - “MDS Scoring Methodologies”
for Condition and Symptom Matching.
2. Step 2- Entry of standard HPI Symptom Features (SF)
To narrow the choices, the detailed and descriptive “associated symptoms and signs” part of HPI
will now be matched between the input symptom features to be provided by the user, and existing
symptom features. Matching is expected to show varying percentage of similarity to the input data.
a. This step involves asking the user to fill in HPI symptom features for each previously entered
input symptom, in response to focused HPI questions.
b. Symptom Verification Questionnaire (SVQ): - User is presented with dropdown lists of
values to select from for each HPI element, and questions in single or multiple-choice format
to enable accurate and comprehensive entry of HPI information for each input symptom.
c. How are these questions generated? For each condition-symptom match, the system will
fetch the linked symptom feature (SF) objects i.e., the symptom profiles configured as MDS
metadata for that medical condition and symptom. And for each HPI element in the SF,
display a union of all available values to select from. The user must select applicable values
for each symptom feature from the combined list of available choices. Note: - In case of
“Severity”, user will be asked to enter a value (scale of 1-10) in an input field.
d. As part of HPI inputs, user must also select applicable values for “Associated symptoms and
signs” from a list of available terms. This element is known to contain other associated
symptoms for the given symptom profile (with weights attached, which based on this design
will override the condition-level weights) and in certain cases, descriptive terms for signs.
MDS Process for Symptom Matching and Verification

11 | P a g e
Figure 3 MDS Object Model
Figure 4 MDS Object Model

12 | P a g e
e. Certain modifying factors and associated symptoms & signs configured in the matched
symptom profiles will contain terms related to Medical History e.g., “History of Joint Injury”
that must be verified. The system will dynamically check for these at the next step.
f. Similarly, factors or signs in the matching symptom profiles may require verification of
Patient Data (PD) e.g., to confirm the presence of “Obesity” or Vital Signs (VS) -e.g., “Fever.”
As patient data was already entered, PD checks can be performed at any point. Vital Signs
checks will be performed following the next step of data entry.
g. The matching symptom profiles may also contain “key” signs that can only be verified based
on Test Results e.g., “High Uric Acid.” This verification is also done at the next step by asking
the user to enter test results referenced by condition-level rules for the concerned sign.
3. Step 3- Entry of the Medical History, Vital Signs (VS) and Test Results
To support the next matching and verification steps, the system will ask for the medical history and
display other questions related to vital signs and test results.
a. Medical History (MH) Questionnaire and the Vital Signs (VS) Questionnaire
o User can enter structured data inputs for past medical history (PMH), family history
(FH), and vital signs (VS) in response to specific questions.
o If there were factors, symptoms or signs from previous HPI steps requiring medical
history or vital signs verification, questions specifically concerning those factors and
signs will be asked at this point. Refer the section on “MDS Auto-keys”.
o The above inputs are meant to trigger any global, condition-specific or symptom-
specific rules that serve to validate or dismiss the concerned sign or factor, and in
terms of the scoring, will raise or lower the matching score for a condition-symptom.
o If user does not enter the Medical History or Vital Signs, this step can be skipped.
Matching rules will assume there was no match for that sign or factor.
b. Test Results (TR) Questionnaire
o User will be asked to provide structured data inputs for- Test results corresponding
to Tests linked to an associated sign and referenced by the condition. E.g., “Uric Acid
Blood Test” to test for “High Uric Acid” will ask for entry of “UA level” in mg/dL.
o If the test results are not readily available, the user can skip this step which will mean
a non-matching score on this sign.
c. Instead of skipping the above data entry steps, the user can choose to save the session
information and log out, to perform the required MH, VS and TR data entries at a later time.
4. Step 4- Score Adjustment based on Matching of standard HPI Symptom Features
System will now run a (backend) match between the input HPI elements and pre-configured
“symptom profiles” set up for each condition-symptom match and adjust each condition score.
a. The system will also process the data inputs for medical history, vital signs, patient data and
test results along with the HPI feature values previously selected by the user. Calculation of
matching scores based on symptom feature profiles requires a separate algorithm. For
details, refer the section: - “Scoring Model for Symptom Profile Matching”.

13 | P a g e
b. Integrating Medical History for Condition matching and Symptom Verification: - In case the
matched condition-symptom had a factor, symptom or sign involving medical history, Rule-
based processing of the PMH or FH data can have an impact on the matching symptom
profile score which may be raised or reduced (+/-) by a certain percentage.
o For example, the profile “OA-Joint Pain-Advanced” has “History of Joint Injury” as an Aggravating
factor, and the system will first check for this in the PMH inputs. If user had provided this, the system
will regard this as a positive match. If not found, the SF will be considered non-matching on this factor.
c. To summarize, the resulting condition score may either remain the same, or be scaled down,
based on the extent of matching found on the symptom profiles.
o For example, the “RA-Joint Pain” condition-symptom match had a score of 5 from Step 1. Thereafter,
Step 4 finds the HPI inputs only partially “fitted” the symptom profiles set up for RA, with a matching
score of 52% (as some HPI inputs did not match the ranges and lists configured in the symptom
profile). Accordingly, the score for RA is now lowered to 5*0.52 = 2.6.
d. At end of this step, matching Condition scores are refined and updated which may lead to a
re-ranking of matched conditions. At this point: - Higher the extent of the match for critical
symptoms as determined by the symptom features, the more probable that condition.
e. Note: - We have suggested a full-fledged symptom profile design to fully describe any
symptom feature. While this is required for primary symptoms, it may seem overdone in
cases where in-depth symptom feature details are not required for diagnosis. E.g. “Stiffness”
was selected as an associated symptom for the “Arthritis-Joint Pain” profile. In this case, we
need only the “Severity” feature to process the matching and scoring for this profile.
f. To accommodate the above case, the symptom profile design is “collapsible”. In other
words, user does not have to enter in-depth information for every feature. To enable this
functionality, the design allows the configuration of certain features as mandatory, which is
specific to the condition and symptom being processed. Symptom Features not considered
mandatory or relevant for diagnosis may be left unselected by the user during HPI inputs.
g. Refer the section: - “Symptom Profile Configuration”.
5. Step 5- Condition Verification based on Associated Symptoms, Signs and Factors
Based on the initial input symptom(s), a list of matched conditions was generated and based on the
symptom features, the matching scores were adjusted. We observe that condition-symptom sets
must have matched only partially at this point. There may be associated symptoms not yet entered.
For a more accurate match, associated symptoms & signs must also be entered for each condition.
a. Condition Verification Questionnaire for Symptoms: -
o To support this function, user will now be asked to select from a combined list of
symptoms, which is the union of all symptoms left out of the previously matched
condition-symptom sets and not already entered by the user.
o System will again run the match of input (condition-level) symptoms with the
symptom set of each matched condition based on the symptom names, and signs (if
any). Following this, matching will require HPI inputs to be entered for each
associated symptom (to the extent required) and the scores adjusted for each
condition-symptom profile.
o System will re-calculate the aggregate score for each condition.

14 | P a g e
b. Condition Verification Questionnaire for Factors & Signs: -
o Based on the signs and factors configured for each condition, user must also indicate
which signs or factors- e.g., Risk factors, are applicable to the problem. This is
normally done by asking the user to select from dropdown lists of available choices.
o Alternately, if there are signs and factors not displayed in the dropdown lists but are
instead auto-enabled with condition-specific rules, the system will: -
o Dynamically trigger rules to check these signs/ factors
o E.g., for “Aging” set up as a risk factor for OA, rules will be triggered to check if
patient Age (part of the patient data inputs) will raise the risk of OA. In the case
example, patient Age is 55 based on which the Aging Rule for OA will be triggered.
o In other cases, the system will ask the user specific questions to confirm the
sign/ factor in question.
o E.g., if “Smoking” appears as a risk factor for RA, the user will be asked “Is Smoking
a part of your Personal Habits?” Answer: “Y/N”. In case of “Y” the “Smoking” risk
factor is confirmed, and the condition risk score will be raised by a certain margin.
o If applicable risk factors are detected, the condition risk score will be raised. In other
words, if a sign (may be weighted) or risk factor is confirmed, this will also raise the
composite condition matching score by a certain margin (%).
c. Condition Verification Questionnaire for Medical History and Vital Signs: -
o Certain condition-level Signs or factors may again require the verification of medical
history, or vital signs checks. These verifications will be done again, if required, based
on specific questions displayed to the user. This step will serve to confirm or dismiss
the factor or sign in question.
o E.g., “Does the condition Gout appear as an illness in your Family History?” Answer: “Y/N”.
In case of “Y” the “Genetic” risk factor is confirmed for the case (based on FH verification).
o Matching condition scores will be further refined based on the above verification of
condition signs and factors.
d. For details concerning the above steps, refer “Scoring Model for Condition verification based
on associated Symptoms, Signs and Factors (MDS Process: step 5)”.
6. Step 6- Entry and Processing of Test Results at Condition level
a. To further refine the previous matching scores, the system will now ask for Test Results data,
this time for Tests required to dismiss or confirm the condition, by lowering (or raising) its
probability by a configured margin (%). Again, the user can choose to save the session
information and log out, to perform the required test result data entries at a later time.
b. Test Results questionnaire: - User will be asked to provide structured data inputs for- Test
results corresponding to the Tests referenced by each matched condition.
c. The above inputs will trigger global and condition-specific Rules related to Test Results that
quantitatively support or contradict (+/-) the existence of a condition.
d. After score adjustment based on the above, a condition will move near to the top or if below
a given lower limit (say 20%) the condition(s) can be eliminated as a cause. The re-ranked
list of matching conditions will now be displayed to the user with final updated scores.

15 | P a g e
Figure 5 MDS Workflow
Figure 6 MDS Workflow

16 | P a g e
Figure 7 MDS Workflow (Matching of HPI)
Equations for MDS Scoring
Object Description of terms Equations
Symptom
Profile
nSF: Number of symptom features in the
ith Symptom profile of a condition.
SF_match_scorej =
(
∑ 𝑆𝐹_𝑠𝑒𝑙𝑒𝑐𝑡𝑒𝑑_𝑓𝑖𝑒𝑙𝑑_𝑤𝑒𝑖𝑔ℎ𝑡𝑖
𝑆
𝑖=1
∑ 𝑆𝐹_𝑓𝑖𝑒𝑙𝑑_𝑤𝑒𝑖𝑔ℎ𝑡𝑖
𝑀
𝑖=1
)*100
HPI_matchi = (
∑ 𝑆𝐹_𝑤𝑒𝑖𝑔ℎ𝑡𝑗
𝑛𝑆𝐹
𝑗=1 ∗𝑆𝐹_𝑚𝑎𝑡𝑐ℎ_𝑠𝑐𝑜𝑟𝑒𝑗
∑ 𝑆𝐹_𝑤𝑒𝑖𝑔ℎ𝑡𝑗
𝑛𝑆𝐹
𝑗=1
)
HPI_matchi = MAX (HPI_match1,…HPI_matchP)
SF_weightj : Configured feature weight for the
jth symptom feature of a profile.
SF_match_scorej : Matching score (%) for the jth
symptom feature (SFj) of the profile
based on weighted averaging of
selected fields. For non-weighted
elements, the default Weight = 1.
HPI_matchi : HPI Matching score (%) for the ith
Symptom profile of a condition with
the highest HPI Matching score.
SF_field_weighti Weight attached to the ithfield of
M fields in the symptom feature.
SF_selected_field_weighti Weight attached to the ith selected
field in the symptom feature (SFj).
Condition 𝐻𝑃𝐼_𝑚𝑎𝑡𝑐ℎ𝑖: Matching score (%)/100 for the ith
symptom with weight wi for a total
no. of N condition symptoms.
Condition_match_score =
(
∑ 𝑤𝑖
𝑁
𝑖=1 𝐻𝑃𝐼_𝑚𝑎𝑡𝑐ℎ𝑖
∑ 𝑤𝑖
𝑁
𝑖=1
) (1 +
∑ 𝑅𝑓𝑖
𝑀
𝑖=1
100
) (1 ±
∑ 𝑇𝑅𝑖
𝐾
𝑖=1
100
)
(1 −
∑ |𝐶𝑓𝑖|
𝐶
𝑖=1
100
)
𝑅𝑓𝑖 : ith Risk factor score (%) for a total
no. of M risk factors for a condition.
𝑇𝑅𝑖 : ith Test Result score (%) for a total
no. of K test results for a condition
𝐶𝑓𝑖 : ith contrafactor score (%) for a total
no. of C contraFactors configured
for a condition.

17 | P a g e
Configuration of the MDS Meta Data
MDS Metadata configuration is an important part of this design. Discussed below are configurable
components of the system:-
Symptoms, Signs, and Factors
At condition-level, the basic symptoms set was previously discussed. The condition can also have
signs, and different types of factors including Risk factors. At symptom profile level, the symptom
features (SF) based on HPI will include the modifying factors and associated symptoms and signs.
Text descriptors for Signs and Factors
Beyond the strictly medical terms for “signs and symptoms” that form the standard MDS metadata,
this design allows other types of “descriptive text” to be configured to represent signs and factors.
i. E.g., for the Rheumatoid Arthritis (RA) condition, we configured the risk factor “Genetic”, and the sign:
“Systemic symptoms”. At symptom-level we added “visible signs of inflammation” in associated
symptoms and signs. For Lyme disease, we can have “Flu-like symptoms” as a condition-level sign.
MDS Auto-keys
Certain descriptive fields included as part of “Signs” or “factors” at condition and symptom profile-
level, are set up with special properties – in this design, we call them “auto-keys”. These are
“hidden” keys, i.e., not directly shown to the user as part of any questionnaire.
 These descriptive keys are linked to Rules for dynamically cross-checking medical history,
patient data, vital signs, or test results. If this data is not available, the user will be asked
specific questions about the auto-key enabled factor/ sign.
 Users are normally able to select applicable terms from lists displaying medical symptoms
and signs, and from lists with descriptive terms for signs and factors. But users cannot be
expected to make sense of complex medical terms e.g., “Hyperuricemia”, nor can they check
the medical history on their own. For these reasons, the system will trigger auto-key rules,
for asking specific questions where required and for triggering rules to check the data.
 Essentially, auto-keys are set up to enable backend verification of a given factor or sign and
will return true or false. These are hidden terms that will not be directly selected by the user
from a dropdown list. But will be scored during matching, based on the verified output.
 If an auto-key appears in the HPI element of a particular condition or symptom profile being
matched, at the time of HPI inputs it will trigger rules to dynamically perform these checks
on the patient data or medical history. Or, in certain cases, it will first involve displaying
questions directly asking the user about the auto-key enabled sign/ factor and processing
the inputs through rule-based processing to confirm or dismiss that sign/ factor.
 For a symptom profile auto-key, auto-questions will be asked at time of HPI Input (symptom
verification). For a condition-level auto-key, questions will be asked at the time of condition
verification when the user is asked to provide associated symptoms for the condition.
o Examples: - The condition Rheumatoid Arthritis (RA) has an auto-key for “Genetic” which dynamically
checks the Family History (FH) for RA, and if applicable, the rule will return true (to confirm the
Genetic risk for RA). The result is a higher matching score for RA to indicate the increased risk the
patient may face. In case the Family History (FH) data was not provided earlier, user is directly asked
this Q. “Does Rheumatoid Arthritis appear as a serious illness in your Family History? (Y/N) If yes,
which Relation(s) did this condition affect?” (Dropdown list of family relations for user to select from).
For more examples on auto-key functionality, refer to the next section.

18 | P a g e
Condition Configuration
For the Condition- in addition to the medical symptoms set, terms may be configured as Signs, Risk
factors, or Contradicting factors. Each of these attributes has a list of descriptive text fields, where
certain fields may be configured with auto-keys and can trigger rules for checks and validations.
 Contradicting factors or contraFactors: - these serve to eliminate the condition as a cause
or reduce its risk/ probability by a high margin if certain signs or factors are applicable (or
not). With contraFactors set up in the condition, if the rule that validates the sign or factor
is found to be true (or false, in some cases) the score will be reduced by a high margin.
 In this design, contraFactors are configured to have an opposite effect to Risk factors for
calculating the probability of a condition.
 As discussed earlier, certain signs and factors are auto enabled. Note: - ContraFactors can
include signs and factors that are not auto-key enabled. In such cases there is no verification
required based on medical history or other data. The contra factor rule simply checks if a
particular field was selected by the user, or not, and adjusts the score accordingly.
o For Rheumatoid Arthritis (RA) we have “Visible Signs of Inflammation” listed as a sign for the “Joint
Pain-Advanced” profiles. At condition level, the rule “Input. Associated” + NOT IN + (“Visible Signs of
Inflammation”) is configured under contraFactors. During HPI inputs, if the user did not select this
term from the list of associated symptoms and signs, it means the RA probability can be reduced by
a certain percentage because the patient does not show any visible signs of inflammation.
 Risk factors and signs for a condition are widely known and self-explanatory. In terms of the
scoring set up for the current MDS, if a Risk factor is found to be applicable to the case, this
should work to raise the probability of the condition by a certain margin (%).
o E.g. - For Gout, Hyperuricemia or “High Uric Acid” is an important indicator which appears as an
associated sign in the “Joint Pain” profile. At condition-level, this is a known Risk factor for Gout.
Hence if this condition “Hyperuricemia” is found applicable, the risk or probability of Gout will go up.
o Furthermore, “Hyperuricemia” has an auto-key Rule (IF UA > UA_Upperlimit THEN Hyperuricemia =
TRUE) that checks for its applicability to the case by checking the Uric Acid (UA) level. Note: - this is a
hidden key i.e., user is not directly asked whether she has “Hyperuricemia”. User is only asked to
input the Uric Acid value (from the Uric Acid Blood Test) at the time of HPI entry.
o If user has the UA value available, and enters it, and if the value exceeds the upper limit the rule will
proceed to confirm this condition (output is “true”) and the matching score will go up. Else, if the
value is within the normal UA range, the output is “false” and the score remains unchanged.
 Note: - Test results data may not be readily available, as the patient has not yet taken the
test. If user proceeds to the next step without test result entry, the sign or factor is
considered a zero match. To avoid this scenario, user can log out and save the session
information. When user is ready with the Blood test and/or other test results at a later time,
the matching and scoring process will resume after the user logs in and inputs the required
test data. The result will be processed as part of the final score calculation for this condition.
 Signs for a condition may also be weighted and may contain descriptive terms that are in
certain cases, auto enabled.
o For Example, Rheumatoid Arthritis (RA) has the sign “systemic symptoms” configured at condition
level. During verification, auto-rules will check if the user had previously selected “Fever”, “Fatigue”
and “Stiffness” as symptom or condition level inputs. If yes, the weight for this sign will be applied for
score calculation to raise the condition matching score. If not, there is no impact on the score, as the
symptom is considered non-matching on this sign.

19 | P a g e
Symptom Profile Configuration
The following points related to the symptom profile configuration are outlined for this MDS:-
 As discussed in previous sections, Associated Symptoms and signs in the symptom profile
can be weighted, similar to the condition-level configuration of basic symptoms and signs.
Factors and descriptive terms that appear in the other HPI elements are not weighted.
 Mandatory fields: - An HPI element may have certain values that, if not matching with any
user input values, will eliminate that symptom profile from the list of profile matches. These
fields must be configured as mandatory, so that if the user submitted HPI inputs that are
missing any mandatory fields, the matching of these profiles will not be completed.
 At the condition-level, if a mandatory rule is configured and the matching field not selected
by the user, the condition will be removed from the list of possible causes.
o Mandatory field example: - Lyme disease symptom profiles have “Environmental exposure to tick
bites” set up as mandatory for the “Setting” element (i.e., symptom feature). If user did not select
this field during HPI inputs, the system will discard these symptom profile(s) as profile matches. If this
field was also set up at condition level (contraFactors: - “Input. Setting” + NOT IN + (“Environmental
exposure to tick bites”), then Lyme disease will be removed from the list of matching conditions.
 Mandatory features: - In addition to mandatory fields, there are certain HPI elements i.e.,
symptom features that may also be set as “mandatory”. User must select at least one value
from this element. E.g., “Location”—if at least one field matches for this feature, it will be
considered a match for the symptom profile, unless there are other mandatory features in
the profile that do not match. For most profiles, we assume that “Location” is mandatory.
Further points concerning the configuration are discussed as part of the scoring methods.
 This design allows symptom profiles to have hierarchical relationships. For example, the
generic symptom profile “Arthritis-Joint Pain-Leg Joints” is at the level above “OA-Joint Pain-
Leg Joints”, and “RA-Joint Pain-Leg Joints”. This and other types of condition and symptom
class associations can be generated at the time of metadata configuration.
Overview of the Matching Process
Matching Process for MDS will perform the following activities:-
Level of Matching Matching will be performed at the symptom profile and condition level.
Symptom 1. Matching rules will run the check to make sure the user input complies with basic rules and conventions.
2. User inputs will be matched with pre-configured fields for each HPI element (i.e., symptom feature).
3. Matching rules will determine if there are mandatory features that have not been input through HPI.
4. Matching rules will determine if there are mandatory fields that have not been input through HPI.
5. Symptom profiles missing mandatory features or fields will be removed from the profile matches.
6. Auto-key enabled fields (if configured in the HPI element) will cross-check medical history and other data.
7. Matching results will be passed to the scoring models for the symptom profile.
Condition 8. Rules will check for any confirmed contraFactors thereby eliminating that condition from the list.
9. Matching rules will determine if there are condition symptoms and signs matching the user inputs.
10. Matching rules will determine if there are condition risk factors matching the user inputs.
11. Matching results will be passed to the scoring models for the condition.

MDS Scoring Methodologies
The following sections will now outline the guidelines for data entry, matching and scoring in the course of
condition symptom matching and verification as implemented in this design.
 The composite score in this model represents the estimated probability of a cause. At a
granular level, the score also reflects the importance of a certain symptom, or symptom
feature for diagnosis of a condition.
 The scoring model will accept the output of matching, with user input features matched to
each symptom profile and then apply its logic and scoring rules to translate the given
matched data into quantifiable measures, resulting in a composite score (%age).
 The MDS scoring models suggested here, should enable multi-level custom configurations
for scoring based on a specific condition, condition-symptom profile, symptom feature, or
atomic data element i.e., symptom/sign/factor.
Scoring Model for Condition-level Matching (MDS Process: Step 1 & Step 5)
As previously discussed, the design allows basic symptoms and signs in the condition-symptom set
to be weighted for scoring, and after matching based on symptom names, a weighted average score
is computed for the condition-symptom match.
a. The condition object can also have factors, and other descriptive text configured as signs.
Of these, the signs are weighted. Risk factors are associated to % increase in the risk score.
b. Mathematical models can be used to calculate the exact risk due to signs/factors e.g.,
“Aging”, “Obesity”, “Genetic” and other risk factors that amplify the risk for OA and RA. Here
the scoring model for condition-level matching may also apply statistical models based on
medical reports, to raise the score points for certain factors and signs.
c. In certain cases, opportunities for variable or dynamic scoring emerge. An example where
Math models and predictive models based on research may be used.
o “Aging”- a risk factor for RA and OA, is known to vary with Age. Thus “Aging” when set up with an
auto-key, can be linked to a graph function (“Age vs. Arthritis risk”) that looks up the risk value based
on patient Age. For OA, the auto-key function will be triggered to confirm “Aging” as a valid risk for
the over-50 age group. Even patients approaching 50 and those over 60, can be assessed for risk.
d. ContraFactors: - The function and behavior of these factors was discussed previously. If a
contra Factor is confirmed as applicable for the case, the matching score is usually changed
to 0% and the condition removed from the matched conditions list.
e. Risk factors: - If a risk factor is confirmed for the case, the matching score will be raised.
Entry of input symptoms for matching Condition Symptom sets (MDS Process: Step 1, Step 5)
a. Related/ unrelated symptoms: - When the user enters multiple symptoms at the start (e.g.,
S1´, S2´), we do not assume these are related/ associated to each other, or otherwise.
b. Symptom associations are considered: - a) among symptoms in the condition-symptom set
and b) symptoms that form part of the HPI “associated symptoms and signs” feature {S2´´}.
c. In either case, the system will search for matching conditions based on all possible
combinations of input symptoms appearing separately or as a set {S1´, S2´, {S1´, S2´´}}.

21 | P a g e
d. Note that if the entire input symptoms list matches the condition-symptom set as a subset,
the score for that condition could be high enough to be listed at the top.
Score calculation for matching Condition Symptom Sets (MDS Process: Step 1 & Step 5)
a. If at least a partial match is found between input symptoms and a condition-symptom set,
that condition is listed and ranked as a probable cause, with a weighted scoring method.
b. A condition symptom can have a weight ranging from 1 to 5, where 5 indicates significance
or importance for diagnosing that condition. Weight = 1 indicates the symptom may be
present in some cases but is not so important, and middle values indicate a gradation.
c. How are these weights set? We suggest empirical data and physician estimates (probability
estimates based on medical sources) would be the best to determine the weights. Refer the
Appendix section:- “Symptom Weightage Model for this MDS” to see how the condition-
symptom weights have been set for this model, based on percentage of patients having a
particular symptom in the presence of the given condition, i.e., the prevalence.
d. E.g., based on estimates taken from medical findings we would set the weights as follows:-
i. “One study estimates that 80 percent of people with untreated Lyme have muscle and joint
symptoms”. Based on these findings we set the weightage of “Joint Pain” associated with Lyme
disease as 4 out of 5 in the condition-symptom set. Another observation, “Among adults with Lyme,
60 percent reported fever in a 2013 study” based on which we set the “Fever” weight as 3.
ii. Based on medical data “70-80% of people with Lyme disease, develop a Rash” therefore weightage
for “Rashes” associated with Lyme disease is set as 4 out of 5 in the condition-symptom set.
iii. “The prevalence of sleep disturbance among people with knee OA is estimated at more than 70%” –
thus the weightage of “Sleep disturbances” in the basic OA symptoms is set as 4 out of 5.
Scoring Model for Symptom Profile Matching (MDS Process: Step 2 & Step 4)
For matching symptom features (SF) provided in the input profile to those in the configured profiles,
corresponding HPI elements need to be matched and scored.
 As Symptom Features involve different types of data input fields and data types depending
on the HPI element, we started by establishing conventions for Metadata configuration of
condition-symptom profiles, and for matching of symptom features. These standards will
determine the matching and scoring accuracy to a large extent. For the current design,
guidelines concerning data inputs, matching and scoring of HPI Symptom Features (SF) are
provided in the Table 5 Symptom Feature Values for HPI Matching”.
 Symptom profiles can have weighted signs and symptoms in the HPI element for Associated
Symptoms and Signs, with an average score output from weighted scoring.
 For HPI elements in which the fields are not weighted, such as modifying factors, the default
weight = 1 for matching fields. The weighted score simply reflects the percentage of fields
that matched (No. of matching fields/ Total no. of fields) in that HPI element.
 Feature-wise matching requirements are listed below (Note:- We have considered some
typical, illustrative configurations for HPI and do expect some variation in specific cases)
o “Location” feature is configured as a list of text fields. Similar to a number of other
SF elements this will involve a match between multiple choice text inputs.

22 | P a g e
o And as mentioned earlier, “Location” is considered a mandatory feature where at
least one matching field must be provided.
o “Onset” element is a single choice text input to be matched to the configured value
and is also mandatory.
o “Quality” is a mandatory multiple-choice list of fields describing the nature of the
problem. Similar to modifying factors, quantitative matching is done to score this
element, i.e., the more fields selected, the higher the score.
o “Quality”, “Timing” and “Setting” features share the same behavior with regard to
data input and matching. “Frequency” is another element that can be included.
o “Severity” is a mandatory input on a scale of 1-10 as per medical standards for HPI.
To determine a match, symptom profiles can be configured with a severity range
that the user input should be in. Examples:-
 “Severity” –when configured as a valid range of (7-10) for “Joint Pain” profiles, then user
input of 8 will result in a full match on this element. Another possible configuration is “Fever”
configured as a range (e.g., 98.5-101) degrees F. As the user cannot be expected to enter an
exact value for some features, an input value within this range could be considered a match.
 How are borderline inputs managed? What if user enters severity of ‘6’ for the “Joint Pain”
case, or 97 degrees F for Fever? (A number of methods including Fuzzy models can be applied
here. Refer Methods to calculate Matching and Risk factors in Appendix).
o “Duration” can be configured as a series of permissible time range values for “Past”
occurrences, or a “From” and “To” time range. In certain cases, the user input time
range will be processed by matching rules to check if it matches the configured time
range, within specified tolerance limits. In case there is no time range configured,
there is no prescribed format, and any input value will be allowed for that profile. In
any case, matching rules are required to process the input for this element.
 Once the matching is done, an average score will be computed based on the scoring rules
for each HPI element. A composite score must then be computed for the entire symptom
profile for which a customized scoring model is required with weights for the HPI elements.
 The above requirements indicate that parts of this configuration will be specific to the
symptom profile being matched. To enable this and related functionality, the design must
allow customized matching and scoring to be set up for the condition and symptom profiles.
Refer to the matching process flow charts, and case examples of the customized scoring
model for symptom profiles in the section: - “Workflow Example for the MDS”.
Rules for Matching HPI Symptom Features (MDS Process: Step 2 & Step 4)
a. Rule-based processing is required to enable some functions at the Symptom Features level.
This includes rules for matching and scoring, check rules triggered by auto-keys, and rules
for verification of the medical history, patient data, vital signs and test results.
b. Some configuration examples:-
i. “Patients with a history of joint injury are at increased risk of developing arthritis. Post-traumatic
arthritis makes up approximately 12% of all OA cases and can result from injuries sustained in
automobile or military accidents, falls, or sports”. This indicates “History of Joint Injury” is an
aggravating factor for OA. We configure the profile “Joint Pain-OA-Advanced” accordingly, noting that
the “History of...” prefix will trigger symptom-level rules to check the medical history.

23 | P a g e
ii. For Lyme disease, research studies indicate that “Two-thirds of people have their first episode of joint
pain within six months of the infection”. Based on this we configure the “Duration” of Joint Pain as
“past 6 months” as a permissible time range in the profiles for “Lyme disease-Joint Pain”. If required
for diagnosis, matching rules will further process the user input time range entered,
c. Importance or “weight” of a condition-symptom for diagnosis can vary based on various
factors, such as disease stage, or affected location. We configure this by adding the
symptom in the “Associated Symptoms and signs” (HPI element) with different weights
based on the symptom profile, which will override any other weights set at condition level.
i. “Lyme disease” cases show “Facial Palsy” mostly in the Early Disseminated stage, not the early
localized stage. We configure this in the following way. “Facial Palsy” was previously weighted 4
for diagnostic relevance in the basic condition-symptom set. Now we create the profiles “Lyme
disease-Joint Pain-Early Localized”, “Lyme disease-Joint Pain-Early Disseminated” and “Lyme
disease-Joint Pain-Late Disseminated”.
ii. For the early localized stage profile, “Facial Palsy” is set in the “Associated Symptoms and signs”
with weight = 1 which will override the weight of 4 in the basic symptom set.
iii. Unless the symptom profile contains an overriding associated symptom-weight, the weight in
the basic condition symptom set is taken for scoring. For the Late disseminated and other late-
stage profiles, the basic condition-symptom set weight (4) is taken for “Facial Palsy” scoring.
d. Processing of Medical History (PMH, FH), Patient Data and Vital Signs (VS) in the SF
i. Symptom Profile(s) of a medical condition may have certain modifying factors
and Associated Symptoms & signs configured in the symptom feature (SF) which
need to be verified against medical history, vital signs and patient data.
ii. The symptom profile factors and signs related to PMH, FH, PD and VS are linked
to rules meant for cross-checking the above datasets.
iii. While taking symptom features (HPI) inputs, the system will check if the HPI
element has any factors/signs involving the medical history or vital signs and
generate a questionnaire with specific questions to confirm the factors/ signs.
iv. In course of symptom features matching, rules triggered by these factors/ signs
will then process the user inputs/ answers for PMH, FH and VS, and based on the
result the symptom matching score may be modified further.
e. Examples are provided below:-
i. The symptom profile “OA-Joint Pain-Advanced” has the following configured as an Aggravating
factor: - “History of Joint Injury” which is linked to the rule pseudo-code (IF PMH.PriorConditions
[] has “Joint Injury” THEN “History of Joint Injury” = True). This indicates if Joint Injury is a prior
condition for this patient, the symptom feature score must include this factor as a match.
ii. To verify the above, the system will add this question in the medical history questionnaire
displayed to the user: - “Do you have Joint Injury as a pre-existing Condition?” (Y/N). If user
answers No, there is no match, and no impact on scoring. If yes, the factor is validated as a match.
f. The design is not dependent on AI/ Machine Learning models for data matching, but these
can be readily integrated to determine the symptom weights and enable robust scoring.
g. In summary, the system design applies rules and methods based on the symptom profile
and HPI element and is expected to involve a combination of these approaches: - Medical
Knowledgebase, probabilistic methods, AI, and Rule-based processing required at a number
of steps, at the end of which we arrive at a composite matching score.

24 | P a g e
Scoring Model for Condition verification based on associated Symptoms, Signs and Factors
(MDS Process: step 5)
Rule-based processing is required at the Condition level, to enable some functions.
 Processing of Medical History (PMH, FH), Patient Data (PD) and Vital Signs (VS) as part of
condition verification:-
i. Condition-specific rules work to further refine the matching scores based on
verification of factors and signs that involve Patient Medical History (PMH) and
Family History (FH), patient data, and vital signs.
ii. A medical condition may have certain Risk factors and Contradicting factors
configured, that need to be verified. These factors and signs are linked to Rules
meant for cross-checking the above datasets.
iii. For each condition match, the system will check if there are any factors/ signs at
condition level requiring verification. If yes, the user will be asked specific (Y/N)
questions to verify them (except for PD) at the condition verification step.
iv. Rules triggered by these factors/ signs will then process the PMH, FH, PD and VS
inputs, and based on the result the condition matching score may be modified.
v. Some examples of Risk factor rules are provided below:-
i. The condition OsteoArthritis (OA) has the following configured as risk factors: “Obesity”,
“Aging”. Let us assume OA has matched based on input symptom names, and features.
ii. Now at the condition verification step, the rule for “Obesity” (IF PD.BMI > 30 THEN
“Obesity” = TRUE) is triggered to cross-check the Patient Data. In this case, BMI = 25, so
there is no impact on the score. If the rule had instead confirmed “Obesity” the
condition_risk_score would be raised by a margin, because “Studies have shown that
obese women had nearly four times the risk of knee OA”. Note: - Exact increase in the
risk score due to Obesity should be set based on medical expertise and can be
implemented using statistical or Fuzzy models.
iii. Similarly, the OA rule for “Aging” is meant to cross-check with Patient Data and return
a numeric risk. For patients above 50, this factor may raise the OA probability by about
30% and in this case, Age = 55, therefore the risk should be increased to some extent.
Statistical or Fuzzy models may be applied to enable accurate gradation in risk with Age.
iv. In a different case, the condition Rheumatoid Arthritis (RA) has “Genetic” as a risk factor.
If RA matched based on symptoms, the “Genetic” rule (IF FH.relationIllnesses [] has
“Rheumatoid Arthritis” THEN “Genetic” = TRUE) is triggered to check the Family History.
v. “If a relative (parent, sibling, etc.) has RA, it increases one's risk of getting the
disease, 0.8% compared to 0.5% for those who have no family history”. If “Rheumatoid
Arthritis” appears as a condition for a blood relation, the risk score may go up by 0.8%
thereby raising the probability or risk of RA.
vi. Based on the above configuration, the system will add this question to the medical
history questionnaire following HPI data entry by the user: - “Do you have Rheumatoid
Arthritis (RA) as a condition in your family history?” (Y/N). If user answers Y, the risk
score, and overall condition score will move up. Else, there is no impact on the score.
 Processing of Test Results as part of condition verification:-
i. For Tests referenced by the Condition, test results can finally be added to confirm
or lower the probability of the matching condition.

25 | P a g e
ii. Test results may be required for confirming certain signs, even at earlier points
in the matching process. The test name will be displayed to the user, with the list
of input fields (parameters) in which user will need to enter the test results.
iii. The complexity and depth of decision-making involved in processing clinical test
results to confirm or reject a condition, is at a very high level in the current
Healthcare/IT landscape. We suggest interfacing with a separate diagnostic
module for this purpose, for specialized processing of Diagnostic Lab Test results.
Customized scoring model for Symptom Profiles and Conditions
In addition to the matching and scoring conventions, we need a customized solution for scoring:-
 The relative importance of features for verifying a symptom or condition, may differ across
condition-symptoms. A doctor will consider only some features and feature values important while
differentiating one condition from another, and the key characteristics will vary between diseases.
 Therefore, the ability to build and configure flexible scoring models that can be customized for
symptom profiles is important. Similarly, it should be possible to configure customized scoring for
condition-level signs and factors, so that important signs and risk factors confirmed in the matching
process can be accurately factored into the scoring model.
 The current scoring model allows the relative importance of a field or “sign” to be set as part of
associated symptoms and signs (x-axis), and the relative importance of a symptom feature to be set
among the HPI elements (i.e., y-axis) based on relevance of a symptom feature for diagnosis.
 For example, OA symptom profiles, the Timing feature “Early morning inactivity stiffness < 30 mins.”
is an OA characteristic for symptom and condition matching, and also helps to differentiate OA.
Hence this feature may also be added as a sign at condition-level with appropriate weightage.
 As part of this scoring model, HPI elements are also weighted, based on relevance of an HPI feature.
o E.g., features that include “Onset”, “Quality”, “Duration” and “Timing” are important characteristics to detect
an Arthritis condition based on how the pain started, the type of pain, and the frequency of pain. For this the
MDS is expected to provide a flexible and wide range of symptom descriptors for users to select from.
o Decisions such as, is this Arthritis type of pain, and what is the stage of the disease? Can be made based on
these features, so we expect these features to be given high weightage in the scoring models.
o For a different condition such as “Lyme disease”, the “Setting” element could be the characteristic that takes
on importance. For “Gout”, it may be the associated symptoms and signs that contain key diagnostic criteria.
 Reusable scoring templates and other tools that help to conveniently adapt and customize a scoring
model for the given profile, can of course make this solution less tedious to implement.
 Another important reason we will need element-based or feature-based weights for symptom
profiles, is to prepare for AI/ ML algorithms to be applied as part of the matching & scoring process.
The system design is not, however, dependent on AI/ML models.
 A design aspect that should be customized at SF-level, is the deviation from the prescribed range
or value of an input, as in the case of input values for “Severity”, for which Fuzzy logic scoring may
be utilized. Refer Methods to calculate Matching and Risk factors in Appendix.
 Disclaimer: - Weights for symptoms, signs and factors described in the case examples are meant for
demonstrating the MDS application design and functionality. Final weights must be decided based
on medical expertise.

26 | P a g e
Detection of Comorbidities and Co-existing Conditions
Like other advanced Clinical Decision Support Systems, this MDS aims to support the processing logic for
condition comorbidities, complications and other condition associations. The workflow and functionality
outlined below describes how this MDS can facilitate the detection of Comorbidities.
 How to set up “comorbidities” and “complications”? The MDS database will provide a mapping
between the disease and known comorbidities with corresponding prevalence based on medical
data. OA comorbidities can be used as a good case example. “One-third of adults with OA have
heart disease”—Accordingly, Osteoarthritis (OA) will be mapped to “Heart disease” with 33%
probability.
 As described in previous sections, at the end of the MDS Process for Symptom Matching and
Verification, the system displays the list of top matching conditions. As part of this enhancement,
the system will also display the list of co-existing conditions (which may or may not be part of the
top matching conditions at the end of diagnosis).
 User will be informed that these are the comorbidities associated to each of the top conditions
identified as a probable cause of their problem. E.g., for “Osteoarthritis” the user will see the
following list:- “Heart disease”, “Obesity”, “Diabetes”, “Metabolic Syndrome” and “Depression”
listed as potential comorbidities.
 User may now want to check and see if there is a real risk from any of the above listed comorbidities.
To enable this functionality, the system allows the user to start a “reverse” process of disease
detection, by answering a series of questions related to the suspected disease(s).
MDS Process for Disease Detection
Workflow steps that form part of the “MDS Process for Disease detection” are outlined below. Based on
this disease detection workflow, the MDS can be used to generate Questionnaires for Disease detection,
across condition categories.
a. To check if the patient is at risk of a comorbidity, the user must start by entering the suspected
condition name. E.g., for OA comorbidity detection, user enters “Heart disease”.
b. System will display a list of basic symptoms for the suspected disease and ask user to select any
applicable symptoms. If the input symptom matches some of the pre-configured symptoms for the
condition “Heart disease”, user will be asked to provide the HPI entries.
c. What should the symptom profile configuration be, in such cases? For comorbidities, a special
profile may be required that captures the features for associated comorbidities.
d. The entire list of questions to the user forms the “Disease Questionnaire” generated by the system.
e. For each input symptom matching the “OA-Heart Disease” profile(s), system will calculate the HPI
matching score based on the matching symptom profile, if any.
f. Once the symptoms are matched, user will be asked to confirm the applicable signs and factors
configured at condition level. In this case, signs and factors for “OA-Heart Disease.”
g. System will now calculate the composite condition score for the given condition, and this will be
displayed. Depending on the matching score, user may be advised that the comorbidity risk from
this particular condition is high, moderate or low.

27 | P a g e
Workflow Example for the MDS
1. User opens the Medical Diagnosis System and starts the session. In response to questions or options
on Patient Data (demographic details) this data will be entered.
a. We consider a Case Example where User Age = 55, Gender = Female, BMI = 25.
2. User will now enter one or more Symptoms by selecting from a list. This input forms the patient’s
Symptom Set S´ = {S1´, S2´, S3´}.
a. In this case, User enters only “Joint Pain”.
3. The system will then deploy a search algorithm to match the input Symptoms {S1´} with the
Symptom set {S1, S2, S3…} linked to each Medical Condition (MC) in the database. At this point, the
match is based only on symptom names.
a. To start with, “Joint Pain” being a fairly common problem, appears as a symptom for all these conditions: -
Osteoarthritis (OA), Rheumatoid Arthritis (RA), Injury, Viral Infection, Lupus, Gout, Lyme disease, Bursitis,
Fibromyalgia, and about 15 more conditions (for this case example)
4. A list of matching conditions has been generated (in memory). Each matching Symptom- condition
set on the list will have a matching score, based on how many symptoms in the pre-configured
condition-symptom set match the given combination of input symptom names.
5. To support the above scoring, the design required the “importance” or “weight” of a symptom to
be set for each condition-symptom (1-5 scale). Based on the scoring algorithm for matching by
symptom names, if more top symptoms can be detected for a condition, it should move up the list.
a. Rheumatoid arthritis has the “Joint Pain” symptom set as 5. For OA, joint pain is 5. For Lyme disease it is 4 and
for Gout it is 5. As joint pain is the only symptom to be matched, these weights reflect the final matching score.
6. Next, user will be asked for more information regarding each Symptom. The Symptom features
design is based on standard HPI elements as the reference source, to be used in the initial phase
and other phases of the matching process.
a. In the case example, user selects the following terms from the system-generated list(s): Location(s) “Feet” and
“Knees”, “Multiple joints”, Pain severity of 8, “Gradual” and “sometimes sudden” onset of “intermittent”,
“sharp or intense” pain with “flares” for the “past 1 year”, relieved by “pain killers”, exacerbates with “cold
weather”, “extended activity”, “repetitive stress on the joint”, “over exertion” and “high intake of sweetened
beverages”, the setting is “None”. For answers to the question: “Which of the following Associated symptoms
and signs apply to your problem?” user selected “Stiffness” with 8 on the HPI severity scale.
7. At this point, user may also input answers to specific questions on Past Medical History (PMH) &
Family History (FH) if available. And if any Vital Signs (VS) are requested, that too should be entered.
Test Results may also be requested for confirming certain signs. The system will integrate these
data inputs for validating certain factors/ signs configured in the matching HPI element.
8. The system will then deploy a matching algorithm to match the HPI symptom features.
a. Based on the above inputs, Osteoarthritis (OA) that is set up with “Joint Pain” Severity as medium to high (7-
10) will match the user input of severity 8. (Suppose OA was set to Joint Pain as low (3) on the pain scale, it is
not a match, and the matching score for this HPI element would be 0%).
b. Overall, symptom feature matching results in 52% match with the RA-Joint Pain-Leg Joints profile, and a score
of 85% match with the OA-Joint Pain-Early profile. For the Gout-Joint Pain-Leg Joints profile, it is a 65% match.

28 | P a g e
c. For Lyme disease, SF matching results in a 0% HPI match with all the Lyme Disease-Joint Pain profiles because
the mandatory feature requirement “Environmental exposure to tick bites” was not selected. Auto-checks on
“History of Joint Injury” for OA are positive, as the medical history check reveals a past injury.
d. “Hyperuricemia” for Gout is auto enabled to request for the Uric Acid blood test results. After entering HPI
inputs, the UA input field is displayed. User enters a value e.g., 7.3 mg/dL which triggers the rule to confirm
Hyperuricemia and will also raise the symptom profile matching score. (Note: - At the next condition-level
matching step, confirmation of this condition will also raise the composite score i.e. Gout risk by a high margin).
9. Note that Symptom features are not just text, and can be any data type (text, digits, decimals, or
class intervals with a tolerance limit, even binary and images) that gives an objective measure, as
required for a specific HPI element. Thus the “Fever” symptom can have its “Temperature” feature
set to 98.5 or (98 – 101) degrees F depending on a particular condition-symptom profile.
10. Symptom features matching may result in the condition scores being further adjusted. Based on
this design the matching or “fitting” of HPI feature points between the input symptom and the
configured condition-symptom can result in a score between 100% (full symptom-attribute match)
to maybe 10 % or lower (indicates no exact match on any attribute, depends on the scoring model
configuration. Setting the cut-off as 20%, trailing matches can be eliminated).
11. For each Medical Condition on the scoring list, the composite score at this point reflects the extent
to which input Symptom features matched the configured Condition Symptom features.
a. The matched condition scores are adjusted for the above SF matching results respectively (RA = 5*0.52 = 2.6,
OA = 5*0.85 = 4.25, Lyme disease = 4*0.0 = 0, Gout = 5*0.65 = 3.25 and others)
b. Lyme disease did not get a match on the mandatory symptom feature, “Environmental exposure to tick bites”
and is therefore, removed from the matching profiles. As this factor was also configured at condition level,
Lyme disease is eliminated from the list of matching conditions.
c. As revealed by “Joint Pain” features entered in the HPI, the nature of pain is found to be too different from
“Bursitis”. Combined with a negative on other symptoms, a low score (< 20%) rules out this condition.
d. HPI inputs including the Timing and Duration reveal no present “Injury”, and this is removed from the list.
e. The Joint Pain profile for Fibromyalgia was configured to detect “widespread pain”, pain in other parts
including “Head, neck, shoulders, arms, hip” and “muscle twitching and cramps”. As these signs were not
selected for the Joint Pain HPI, Fibromyalgia gets a low score (HPI match < 50%) but cannot be ruled out.
12. Following the above Symptom profile matching and score adjustment, the list of matching
conditions will be re-ranked with scores updated (in memory).
13. Condition-level Matching will now take place. System will check for "associated symptoms” set up
for a Medical Condition. Essentially, this logic will check to see which other symptoms associated
with each matched condition, are experienced by the patient. Dropdown lists will be displayed
asking the user to select any other basic symptoms that are applicable to their problem.
14. If the user does confirm any condition-level symptoms, the system will prompt for symptom
features i.e. HPI details on each symptom, and also then match with the available symptom profiles
for each condition. In case HPI for a symptom was previously entered, it will not be asked again.
a. To verify associated symptoms based on the union of symptom sets of partially matched conditions, the
system will display a list for the user to select from: -
“Swelling in joints”, “Joint Deformity”, “Fatigue”, “Limited range of motion”, “Crepitus”, “Bone Spurs”,
“Sleep disturbances”, “Rashes”, “Fever”, “Facial Paralysis”, “Skin Lesions”, “Nasal congestion”, “Runny nose”,
“Headache”, “Cough”, “Throat Pain”, “Anxiety”, “Depression”, “Hair Loss”, “Chest Pain”, “Photosensitivity”.
b. User selects “Sleep disturbances” (HPI severity of 8) and “Fatigue” (HPI severity 7).

29 | P a g e
c. Note: - User had previously selected “Stiffness” as an associated symptom which received an overall high
match of 80% on the symptom profile (Arthritis-Stiffness-Leg Joints). Therefore “Stiffness” is not repeated in
the above condition symptoms list but will be considered for scoring at condition level.
d. We find a low match on basic “Lupus” symptoms with “Rashes”, “Skin Lesions”, “Photosensitivity”, “Hair Loss”,
“Chest Pain” and “Fever” not being selected.
e. As “Fever” is not applicable, with no other “Viral Infection” symptoms this condition is ruled out.
f. There is still a low match on “Fibromyalgia” with only “Sleep disturbances” and “Fatigue” selected by the user
that match the condition symptoms.
15. As a result of user selection of condition-symptoms, the scores are updated.
16. User will also be asked to select from a dropdown list of signs. If anymore data is required, user will
be asked specific questions related to the patient data, medical history, and vital signs in order to
confirm signs or factors that are auto-enabled at condition-level.
17. Answers entered by the user will trigger Condition-specific Rules that will now run checks based on-
Patient data, structured data entered for the Medical History, Vital Signs (VS) and any other rule
checks required for diagnosing that condition.
18. As noted earlier, there can be global and/or condition-specific Rules set up in the system that work
to raise or lower the probability of a condition. Based on this design there can be a good symptom
match to start with, but rules that check for signs and contradicting factors set up at condition level,
can lower the score or eliminate a condition. Valid risk factors will raise the condition probability.
a. OsteoArthritis risk factor “Aging” has the Rule: “Patient.Age > 50”. As “Age” of the user is 55 years, there is a
demographic match on this factor (Risk of OA due to “Aging” = True). (Suppose we had a statistical function
set up to give an exact matching score for the 55-year patient, the condition_risk_score will move up by a
certain margin %). Also, the PMH confirmation of “History of Joint Injury”, set up as a condition-level risk factor,
has raised the OA score by 10% as the PMH revealed a “fall at home”, two years ago.
b. Signs data can also support or contradict the confirmation of a condition. In this case, body temperature and
other vital signs entered by the user, appear normal.
19. The Matching phase concludes with a list of matched Conditions and updated scores indicating the
extent of the match.
a. At this point the list consists of: - Osteoarthritis, Rheumatoid Arthritis, Gout, Fibromyalgia, and Lupus.
20. The next matching phase will involve refining the scores based on additional data inputs requested
from the user for the (fully or partly) matched Conditions. At this point we need the Test Results.
21. As each Condition was set up to reference certain Lab Tests and Test Results, system will now inform
the User what Tests to take for each matching Condition. And user will be prompted to enter
structured Test results in each data field. User has the option to save the session data until this
point, log out, and resume the process once the Test Results are available.
a. In this case, user is informed that the following Test results are required: - Routine including Blood, RA Factor,
ANA Profile, Electrolytes, and TSH, and the screen will display specific test result data fields to be entered.
22. Test results (qualitative) are derived based on test result data and the limits set up for each Test:-
a. RA Factor is Negative.
b. ANA profile is negative.
c. TSH is within normal limits but borderline high.
d. ESR is higher than normal for the given gender-Age combination.
e. Uric Acid is above the upper limit

30 | P a g e
23. Condition rules will process the test inputs and reach the following conclusions:-
a. ANA negative combined with a low score on Lupus symptoms, should rule out this condition.
b. RA and ANA negative indicates lack of autoimmune indicators, and this should lower the RA probability.
c. TSH should raise the probability of RA but due to negative RA and ANA, the RA score is not raised in this case.
d. ESR above normal supports the presence of infection or inflammation, and this should increase the probability
of OA, RA and Gout for elderly patients.
e. Uric Acid being High, will trigger the UA Rule for “Gout” and raise its probability by a high margin (+ 5%)
f. Gout condition score is now calculated after factoring in the increased risk from “Hyperuricemia”.
24. The final ranked list of probable conditions displayed to the user is: -
a. Osteoarthritis, Gout, Rheumatoid Arthritis, and Fibromyalgia.
25. Note: - Weights for symptoms and scoring for factors and tests as shown in the case examples are
for illustrative purposes only and must be reviewed by medical professionals. The main objective
of this effort is to demonstrate the MDS framework, and design from an IT/ software viewpoint.
Case Examples: Symptom Matching and Scoring
Table 1 Symptom Profile matching Scores for Top Conditions
Symptom
Features
(SF)
Input Values
(selected by
user or auto
enabled)
Rheumatoid Arthritis
(RA)
Osteo Arthritis (OA) Gout
SF_match_score SF
weight
SF_match_score SF
weight
SF_match_score SF
weight
Location Knees, Feet,
Multiple joints
50% 5 100% 5 30% 5
Quality Intermittent,
Flares, Sharp or
intense pain
80% 5 50% 5 100% 5
Duration Past 1 year 100% 5 100% 5 100% 5
Timing Morning stiffness
< 30 mins.
0% 5 100% 5 0% 5
Severity 8 100% 5 100% 5 100% 5
Onset Gradual,
sometimes
sudden
100% 5 100% 5 100% 5
Aggravating
Factors
Cold weather,
over exertion,
Extended activity,
Repetitive stress
on Joint, High
intake of
sweetened
beverages
50% 5 100% 5 30% 5
Alleviating
Factors
Painkillers 100% 2 100% 2 100% 2
Associated
Symptoms
& Signs
Stiffness,
[Hyperuricemia]
20% 5 20% 5 50% 5
Profile Matching score 52% 85% 65%

31 | P a g e
Case Examples: Condition Matching and Scoring
Table 2 Condition Matching and Scoring
Condition Symptom Set Weight HPI Match Score Aggregate
score
Rheumatoid
Arthritis
Joint Pain 5 52% 2.6
Swelling 5 0 0
Fever 3 0 0
Fatigue 3 80% 2.4
Stiffness 5 80% 4.0
Rheumatoid Nodules 2 0 0 9.0
Risk Factors Genetic + 1% False 0
Aging + 3% True + 3%
Obesity + 15% False 0
Smoking + 1% False 0
SIgns Systemic Symptoms + 2% False 0 + 3%
ContraFactors N/a 0
Final score
(RA)
9.0 (+3%) 9.3
score
Osteo Arthritis Joint Pain 5 85% 4.25
Swelling 5 0 0
Limited Range of motion 5 0 0
Fatigue 3 80% 2.4
Stiffness 5 80% 4.0
Crepitus 5 0 0
Bone Spurs 5 0 0
Sleep Disturbances 4 80% 3.2 13.85
Risk Factors Aging + 10% True + 10%
Obesity + 15% False 0
History of Joint Injury + 10% True + 10% + 20%
SIgns N/a 0
ContraFactors N/a 0

32 | P a g e
Final Score
(OA)
13.85
(+20%)
16.6
score
Gout Joint Pain 5 65% 3.25
Swelling 4 0 0
Fever 3 0 0
Fatigue 1 80% 0.8
Stiffness 4 80% 3.2 7.3
Limited Range of motion 4 0 0
Risk Factors Obesity + 1% False 0
Diabetes + 1% False 0
High BP + 1% False 0
Heart disease + 1% False 0
Metabolic syndrome + 1% False 0
Kidney disease + 1% False 0
Genetic + 1% False 0
Hyperuricemia + 5% True + 5% + 5%
Signs N/a 0
ContraFactors N/a 0
Final Score
(Gout)
7.3 (+5%) 7.7
Table 3 Final scores based on Test Results
Condition Applicable Test Results Impact of Test Results Final Score calculated
Rheumatoid Arthritis
(RA)
RA Factor: Negative
ANA: Negative
ESR: High
TSH: Normal+
-20% 9.3 (– 20%) = 7.4
Osteo Arthritis (OA) ESR: High +1% 16.6 (+ 1%) = 16.8
Gout ESR: High
Uric Acid Blood Test
UA level: High
+5% 7.3 (+ 5%) = 7.7

Table 4 Case Examples: MDS Process Steps with Score calculations
Condition
(Matching)
Rheumatoid
Arthritis (RA)
Osteo Arthritis (OA) Lyme Disease Gout
Condition Symptom
Set
with weights
(Configured)
{Joint Pain : 5,
Swelling : 5,
Fatigue : 3,
Fever : 3,
Stiffness : 5 }
{Joint Pain : 5,
Stiffness : 5,
Swelling (Effusion) : 4,
Limited range
of motion : 5,
Crepitus: 4,
Fatigue : 3,
Sleep Disturbances : 4,
Bone Spurs : 3 }
{Joint Pain : 4,
Rashes : 5,
Fever : 3,
Headache : 3
Facial Paralysis : 1,
Stiffness : 3,
Sleep disturbances : 2 }
{Joint Pain : 5,
Stiffness : 4,
Fatigue : 1,
Fever : 3,
Swelling : 4,
Limited range of
motion : 4 }
Step 1
Condition-Symptom
Match {INPUT =
Joint Pain}
{Joint Pain} {Joint Pain} {Joint Pain} {Joint Pain}
Step 1
Score based on
matching symptoms
5 5 4 5
Step 2
Matching Symptom
Profiles
(Configured) with
Relevance to HPI
inputs
RA-Joint Pain-Leg
Joints
(52% match)
OA-Joint Pain-Leg Joints-
Early (85% match)
Lyme Disease-Joint
Pain-Leg Joints-Early
Localized
(0% match)
Gout-Joint Pain-Leg
Joints
(65% match)
Mid
(60% match)
Lyme Disease-Joint
Pain-Leg Joints-Early
Disseminated
(0% match)
Advanced (40% match)
Lyme Disease-Joint
Pain-Leg Joints-Late
Disseminated
(0% match)
Step 3
Symptom Factors/
Signs that require
MH & PD rule
checks and
Output from these
checks
N/a Aggravating factors :
History of Joint Injury
PMH.Prior_Injuries: “Fall
at home.”
Based on the above,
“History of Joint Injury” =
TRUE
N/a N/a
Step 4
Score adjustment
based on matching
of HPI inputs with
configured profiles
Adjusted score
5*0.52 = 2.6
(52% match
on HPI)
Adjusted score
5*0.85 = 4.25
(85% match
on HPI)
Adjusted score
4*0.0 = 0
(0% match on HPI as
the Mandatory feature
“Environmental
exposure to Tick bite”
was not selected)
Adjusted score
5*0.65 = 3.25
(65% match
on HPI)
Associated sign:-
Hyperuricemia
(TRUE)
Uric Acid level >
UA_Upperlimit

34 | P a g e
Condition
(Matching)
Rheumatoid
Arthritis (RA)
Osteo Arthritis (OA) Lyme Disease Gout
Condition Symptom
Set
with weights
(Configured)
{Joint Pain : 5,
Swelling : 5,
Fatigue : 3,
Fever : 3,
Stiffness : 5 }
{Joint Pain : 5,
Stiffness : 5,
Swelling (Effusion) : 4,
Limited range of motion :
5,
Crepitus: 4,
Fatigue : 3,
Sleep Disturbances : 4,
Bone Spurs : 3 }
{Joint Pain : 4,
Rashes : 5,
Fever : 3,
Headache : 3
Facial Paralysis : 1,
Stiffness : 3,
Sleep disturbances : 2 }
{Joint Pain : 5,
Stiffness : 4,
Fatigue : 1,
Fever : 3,
Swelling : 4,
Limited range of
motion : 4 }
Step 5
Condition
Symptoms
verification and
Calculation of
updated scores
Condition
symptoms match :
 Stiffness (80% HPI
match on
Arthritis-
Stiffness-Leg
Joints),
 Fatigue (80% HPI
match on
Arthritis-Fatigue)
Condition symptoms
match :
 Stiffness (80% HPI match
on Arthritis-Stiffness-Leg
Joints),
 Fatigue (80% HPI match
on Arthritis-Fatigue),
 Sleep disturbances (80%
match on Arthritis-sleep
disturbances)
Condition symptoms
match : N/a
 This condition was
removed from the
matching conditions
list as there was no
symptom profile
match.
Condition
symptoms match :
 Stiffness (80% HPI
match on
Arthritis-
Stiffness-Leg
Joints),
 Fatigue (80% HPI
match on Gout-
Fatigue)
Risk factors :
Genetic (FALSE),
Aging (TRUE)
(+ 3%)
Risk factors:
Aging (TRUE) (+ 10%),
Obesity (FALSE),
History of Joint Injury
(TRUE) (+10%)
N/a Risk factors :
Genetic (FALSE),
Hyperuricemia
(TRUE) (+ 5%)
Signs :
Systemic
Symptoms (FALSE)
N/a N/a N/a
Updated score:-
2.6 + 5*0.8 + 3*0.8
= 9.0 (+ 3%) =
9.3
Updated score:-
4.25 + 5*0.8 + 3*0.8 +
4*0.8 = 13.85 (+20%) =
16.62
N/a Updated score:-
3.25 + 4*0.8 +
1*0.8 = 7.3 (+5%) =
7.7
Step 6
Score updated
based on
(Test Results for
Medical Tests
applicable for each
Condition)
RA Factor: negative
ANA: Negative
ESR: High
TSH: Normal+
ESR: High
N/a
ESR: High
Impact from Test
results (- 20%)
= 9.3 (-20%) = 7.4
Impact from Test results
(+ 1%)
= 16.62 (+1%) = 16.8
Impact from Test
results:-
Hyperuricemia
(TRUE)
(Already factored)
Final score = 7.4 Final score = 16.8 Final Score = 7.7

Medical Diagnosis System _MDS_ 2022 v01012023.pdf

Medical Diagnosis System _MDS_ 2022 v01012023.pdf

Recommended

Recommended

More Related Content

Similar to Medical Diagnosis System _MDS_ 2022 v01012023.pdf

Similar to Medical Diagnosis System _MDS_ 2022 v01012023.pdf (20)

Recently uploaded

Recently uploaded (20)

Medical Diagnosis System _MDS_ 2022 v01012023.pdf