TERMS AND CONDITIONS
HOMOEOPIMis a software providing instant medical assistance to the human species in their day to day life.Homoeopimdeclares certain terms and conditions as follows:
GeneralHomoeopim is nothing but a technology which tries to monitor and diagnosis health conditions of human species through commands sent by the software.In the growing trend of the medical field and to minimize the need for visiting the hospitals Homoeopim has come up with certain technological development which can reduce the time as well costs of the public health system and can increase the efficiency the medical assistance which is a challenging aspect in this highly populated country .Homeopim isacompletely experimental toy suite of programmes andassumes 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.
Homoeopim does not take any responsibility whatsoever of any human being any way affected from this instant “technology”. The usage should be at their own risk and consequences and no legal action at any point can be taken against Homeopin because as stated above “It is a toy and in no way a substitute to a real doctor.
About the Software.
This document (“TERMS AND CONDITIONS”) is a electronic record in terms of Information Technology Act, 2000 and rules thereunder, as applicable and the amended provisions pertaining to electronic records in various statutes, as amended from time to time by the Information Technology Act, 2000. This Electronic record is generated by a computer system and does not require any digital or physical signatures.
HOMOEOPIM is an internet-based portal and a mobile application together be referred as “technology” and use of this “technology” is offered to users subject to acceptance of all terms and conditions including applicable policies if any and/or modifications made from time to time which shall be updated in the website and same shall be maintained and controlled by the “Admin”.
HOMOEOPIM reserves the right to bring any changes in the terms and conditions from time to time and shall continue informing or intimating of such changes and the continued usage of any user shall deemed to be “acceptance” of such changes or modifications therefore one should frequently review this terms and conditions to understand the terms and conditions that apply to your use of this “technology”.
HOMOEOPIM was last updated on 03/07/2023 and this date will be updated only when the master clips file is recreated or when there are any code changes. The main database gets modified almost on a daily basis and its state shall not be reflected in this date.
The Technology and the Services provided by it.
On Homoeopathy
To many, Homoeopathy is nonsense. Well, it is so, because a `remedy' without a single molecule is nonsensical, as far as our current science is concerned.
With that out of our minds, does Homoeopathy work? It seems to, at least to many of us. Then how does it work? Forget all that! Let's get down to business.
On Homoeopim
A‘real’doctor is better than this suite of programmes for the following reasons:
We have a minuscule team and even a rudimentary entry on the >1000 remedies listed in Kent's repertory will require at least another five years, even after neglecting a host of sub-rubrics, as we are doing now.
There has been a huge increase in the number of symptoms/rubrics in recent years. Many new remedies have also appeared. These are not included in the old and free Materia Medicas and Repertories that we are consulting. This new material is available in commercial software that most serious doctors use nowadays. This situation will remain until something can be done about it.
Several experienced doctors reject many symptoms as `peripheral' and concern themselves with the `core'. We do not know how to do that but are toying with the idea of using something like random forests, adaboost, etc. to make the system gain `experience'. We may use genetic algorithms also to tweak the scores in `symptom_remedy_map' to make the prescriptions approach that of experienced physicians. But all that is in some misty future!
Body language and facial expressions are important `symptoms' that good Homoeopaths lay great emphasis on. May be someday, our software will use the web-cam to do something similar with emotion recognition. But someday is not today.
Mental symptoms are extremely important. Doctors just allow the patient to talk on and on and like the psychologists of yore, collect rubrics. These will not be available through simple questions and answers. However, may be some of the test pictures and anecdotes/reactions used by psychiatrists could help. That module is not there.
Some people, like Dr. Sehgal, have used metaphoric mappings of rubrics to tangible symptoms. This method appears to be promising in chronic cases. This will be almost impossible to implement until genuine AI comes along.
Upshot
Please do not judge Homoeopathy on the basis of this very rudimentary and inadequate software! We are basically grossly under-powered.
Privacy and confidentiality
Our focus has been on making `homoeopim' work and the issue of users' privacy and confidentiality has not been worked on to the extent desirable. The forms use the `post' method and so, provided you use `https://' and not `http://', your passwords are safe from other users. However, everything is stored without encryption inside the database tables. This means that the admin. can, as of now, read the passwords and also the symptoms entered by the users, which may be embarrassing and constitute a violation of privacy. Resolving this will need rather invasive changes to the code and use of some Java script, increasing the size of the downloads and a serious reallocation of our resources. I would request you to trust us, as of now. If you install the software in your own machine, which is what we really intend to enable, this issue will be of less concern to you. We will make a virtual machine with everything already installed available for download, and also the full source code, for updating the system periodically and for those who may intend to install from scratch. This will come as soon as the first version is ready - you are looking at a sneak peek, remember?
The SQL query form uses an user-id separate from the owner of the database, with very restricted permissions. You can't access the details of the user entries through it, so users are protected from each other! If you are paranoid, you can delete the symptoms before you log out, but in that case you have to enter the same symptoms again and again.
Versioning Scheme
The version number goes as a.b.c, where c changes on substantial database and CLIPS updates, b changes on software code updates and a pertains to major changes in algorithm, policy or reliability of the code.
Homoeopim documentation page.
These are all CGI programmes with simplest HTML input and output. HTML forms are used for input and the outputs are dynamically created HTML pages.
The database consists of tables, some of which are described below:
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 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.
Symptom (multi-parameter) Search
This is probably what you want while searching for remedies from the database with multiple symptoms. This is a simple SQL-based search with three text widgets for symptoms. Wild cards are inserted automatically before and after the search strings. The search goes as follows:
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.This ensures that only those remedies are selected which have all the entered symptoms at least somewhere in the Materia Medica listing. Thus, if you enter `fever' and `headache', remedies with fever will be located and then only those with headache will be selected from that set.
Symptom (single CLIPS string) Search
This will be useful if you want to see the CLIPS strings that are used for the search - mainly useful for developers, debugging and modifications. Here, the SQL search is made on the CLIPS string using direct `and' clause, so if you enter `fever' and `headache', only those remedies will be selected which have structures like `fever with headache', where all the search strings occur together in a single CLIPS string. If the remedy has one entry for fever and another for headache, it will not be selected. Each remedy name will be clickable for going over to the corresponding Materia Medica page.
Query database (SQL)
This is for using SQL queries directly on the database. To use this you will have to know the details of the tables. This is not password protected because the query is not executed by the owner but another user with highly restricted access (through `grant').
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!
Please use only lowercase for symptom entry.
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.
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 are flushed from the database - otherwise that list will continue to grow.
The patient can enter new symptoms in plain English - they will be parsed by CLIPS. Each symptom entry goes into a table in the database. The type of the symptom (aggravation, amelioration, symptom, etc.) has to be selected. 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' later.
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 score 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 patient's 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.
User ObligationSubject to the compliance with the above stated terms and conditions a user is personal and has access to this technology and the relationship between the Homeopim and the user shall be one to one and the record shall be kept confidential.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 already warned!
It is stated that a user after using this technology if at any point of time decides to buy any medications from outside then it should be purely on the basis one's own risk and consequences and HOMOEOPIM is in no way responsible for any adverse affect caused by any medications brought from outside by any of the users.
Users acknowledges and agrees that by accessing or using the website only for the purpose for getting medical assistance and not for any other purpose and in such process no offensive, indecent or otherwise objectionable content should be exchanged or displayed, transmitted or shared and if any such things are carried out then HOMEOPIM have reserved their rights to block the user from future use.
In any event an user come across any abuse or violation of the said terms and conditions or become aware of any objectionable content on the website a user can always report to the admin in the “Comment” Section but at the cost of repetition HOMOEPIM again declares that it shall not be liable to any legal action taken by any individual user.
Lastly you hereby expressly agree to receive any communications by way of emails or SMS or any other mode from this “Technology” or you may opt-out your preferences of communication available in the website and a user also have liberty can unsubscribe and/or opt-out from receiving any communications from the instant “HOMOEOPIM” any time as and when decided.