Last update - 03/07/2023
This is a completely experimental toy suite of programmes. We assume no responsibility whatsoever for any harm arising from its misuse as a serious or reliable resource. IT IS A TOY AND IN NO WAY A SUBSTITUTE FOR A REAL DOCTOR - you have been warned!
| Tables |
| Queries |
| Chikitsha |
remedy: remedy names (long, short. alternative names) along with unique integral indices.
symptom: the table of symptoms. The fields are as follows:
A unique integral index.
A string describing the symptom in simple but non-grammatical English. These are not rubrics.
A question in simple but grammatically correct English (hopefully!) which a doctor may presumably ask.
A CLIPS-LHS string. We use the CLIPS expert system. This is a typical CLIPS string with wild-cards, alternatives, compounding constructs, etc., which allows the system to read in input from the patient in free-running English and find matches with the symptom string.
gender - this will allow the system to avoid goof-ups like asking for menses-specific questions to a male patient. Options are `both', `female', `male'.
age dependence - `y' or `n' depending on whether the symptom has age dependence, i.e. you don't ask questions on milk-teeth to a person aged forty.
A starting age and an ending age to be considered if age dependence is `y'.
Symptom type - `local' or `compounding'. There are a whole set of `symptoms' which are not so - they are qualifiers to other symptoms. We keep them because instead of having a huge multiplicity of symptoms (as in the case of typical rubrics) like `fever in the morning', `fever at noon', `fever at night' etc. we prefer to have `fever' as a genuine symptom and `morning', `noon', `night', etc. as compounding symptoms which can be joined together using CLIPS logical constructs like `and', `or', etc. Other examples of compounding symptoms are `after eating', `during menses', etc. They are generally described as `concomitant' symptoms in the standard texts.
Whether generals - the idea is to ask questions on general characteristics at the time of registration of the patient itself so that the system has some more material to `chew on' even when the patient enters only a few symptoms This has not yet been implemented.
aggravation: aggravation strings with unique integral indices. The fields are a subset of the symptom table.
amelioration: same as the above, but for ameliorations.
aggravation_remedy_map: a map containing integers corresponding to indices of aggravation and remedy pairs. There is a field for notes in case the aggravation is not general but specific to some symptom. Each entry also has a unique index of its own.
amelioration_remedy_map: similar to aggravation_remedy_map.
symptom_remedy_map: this is also a table of maps, but the symptom id field is a string rather than integral. This allows compounding symptoms together (mostly with `compounding symptoms') with the help of angular-bracket-enclosed symptom ids, e.g. (and<123><2877>) using CLIPS syntax for the logical operators. These will be correctly processed by the parser which generates the master CLIPS file. There is a field for a numerical score which shows how significant each pair is (this is typically indicated with colours or fonts in Materia Medica). Note that negative scores can be used to indicate counter-indications. There is also an `isunique' field. When this is set, additional code is generated to keep the compounding symptom unique to its companion symptom. Say for instance, `after eating' has been set because it was found in a compound construct with `headache'. Now if somewhere in the CLIPS network, `pain in eyes' has been compounded with `after eating', even a simple selection of `pain in eyes' will trigger that rule also. `isunique' tags conjoined symptoms with an unique identifier.
Sundry tables for patient data: These are a set of tables containing data specific to the patients, like list of symptoms, list of questions asked, login details, etc. They are not searcheable from the SQL interface within the query sub-system.
Ignore empty strings to prevent dumping the whole database due to the wild-cards.
Query the database against one symptom and load the result into a temporary table.
Search on that temporary table for the other symptoms.
It goes as:
There is a suite of programmes (not CGI but simply terminal based) which the administrator can run to sanity-check the symptom entries. There is also `build_chikitsha_clp' which goes through the database entries and generates a master CLIPS file. This file has to be copied into the CGI directory for use by the other programmes. This procedure has to be followed whenever there are modifications to the database except for operations performed by the patient. There is also `create_words_table' which parses the symptom clips_lhs strings and makes a list of words which are spell checked and entered into the `words' table in the database. This table forms a `dictionary' for fuzzy matching the strings entered by the patients. There is also `clips_strings_for_fuzzy_search' which populates the table `clips_strings_for_fuzzy_check'. This programme splits the compound CLIPS strings from the symptom table across the `or' clause and then forms all combinations with the words separated by '|' to generate many candidate strings for symptom entries (the CLIPS specific symbols are removed). The idea is to provide the user with a choice when she enters a symptom in free language (optional).
The patient registers herself with a password. This is a one-time operation. We have not (yet!) implemented any OTP or e-mail based `forgot password' functionality. So if you forget the password you have to create a new user id.
For using this program, the patient logs in. Submit buttons with various options appear - `log out' is self-explanatory! Please do not forget to log out so that internally generated OTPs and the list of already asked questions are flushed from the database - otherwise those lists will continue to grow.
The patient can enter new symptoms in plain English - they will be parsed by CLIPS. To check for typos and American/U.K. English problems and the like, there is a `words check' button. It is strongly advised that this option be always availed of. On performing the fuzzy search, the results are displayed below. If changes need to be made to the originally entered string, the patient can cut and paste, edit and otherwise modify her input. We use U.K. English and since CLIPS looks for exact matches except for the wildcards, `colour' should be used instead of `color'. The other button with fuzzy functionality is `symptom check'. This button will do a fuzzy match on the table `clips_strings_for_symptom_check' and suggest already entered symptoms (it will show the symptom strings, not the CLIPS strings, while performing the match with the cleaned-out CLIPS strings) that seem to match the user's input closely. A well-written CLIPS entry can perform an impressive amount of language processing, but users will be sure to find previously unthought of combinations of words to express their discomfort and here the fuzzy search may save the day! Each symptom entry goes into a table in the database. The type of the symptom (aggravation, amelioration, symptom, etc.) has to be selected. Note: the `symptom check' button only works with symptom entries - not aggravation or ameliorations entries as of now. Only one symptom should be entered at a time and the process repeated for as many symptoms as desired. Entry of more than one symptom by using commas, etc. in the same widget will cause erroneous operation.
The patient can see a list of the symptoms already entered (persistent across sessions). She can select specific symptoms for deletion and mark some as `primary' and use buttons to change the database entries accordingly. We will discuss the meaning of `primary' shortly.
The patient can ask the system to suggest remedies. Now the symptom, aggravation and amelioration entries for the patient are thrown (asserted) into the CLIPS network. CLIPS creates a global score variable for each remedy right at the beginning with values of zero. Now on each match, the score for the pair from the corresponding match table is added to the existing value of the global variable corresponding to that remedy.
The remedies along with their total scores are displayed, sorted by score. If any remedy matches a primary symptom as selected by the user, it is displayed in a different colour (red now, but this may change), but the ordering is not altered. This is for the following reason - say a patient comes with fever. After considering all the other symptoms (maybe through the iteration operations), it may happen that the best match does not handle fever, but matches very well with the other symptoms/characteristics. It is now up to the patient/doctor to decide whether to go in for a remedy for `fever' with a moderate score or conclude that other problems need to be taken care of on a priority basis.
The patient can also choose to `iterate'. This is handled as follows:
The system runs the symptom set through CLIPS to get a set of scores.
The scores are used to create a set of Boltzmann weights with a `temperature' which can be selected. Higher the temperature, more equal will be the Boltzmann weights for each remedy even with different scores (basically e^(score/kBT) ).
Metropolis algorithm is now used to select a remedy. Thus, remedies with higher scores do have a higher probability of being selected (how sharply depends on the temperature), but the other remedies also stand a chance. This allows some human-like beating about the bush. This is related to the functionality called `hill climbing'.
The list of questions for the chosen remedy (from the question in the symptom table for the symptoms pairing with this remedy from the symptom_remedy_map table!) is now processed at random and a question selected. The patients' personal data contain a list of questions that have been already asked and those are avoided (this works partially now, only for the symptoms entered by the iterate module and not for the symptoms entered by the patient on her own - so some questions will still be repeated). This question is presented to the patient in a clickable HTML form. In the case of compound symptoms, all the coupled questions will be asked together in a group. How the symptoms are compounded will also be shown with the help of a logical construct on the symptom ids (which id goes with which symptom/question is also shown) with the logical operators in `prefix' form {(or(bhoot)(petni)) implies either bhoot or petni, etc. - this is the LISP syntax - originally the expert system was developed in LISP by contractors, but later the C version was developed by NASA to speed it up}. The patient asserts these symptoms only if the logical requirements are satisfied (so you need not click on all the questions inside of an `or' clause).
The process of selecting remedies and questions is repeated twenty times to present a questionnaire to the patient. She selects whichever apply (if the system runs out of symptoms, the number of questions asked may be less - the iteration code processes the aggravations and ameliorations before the symptoms proper). The symptom string corresponding to each question marked is entered into the database under the patient's entries.
Now the new set of symptoms is in hand. Iteration can be done repeatedly and the suggested remedies checked from time to time till some come out with significantly larger scores.