Table of Contents

THE SOLUTION OF THE PRIZE CASE USING OBJECT REPERTORY

This is an attempt to illustrate the possibilities of using Object Repertory for solving the prize case i.e. we try to present how the process would work if the Object Repertory already existed.

Let's just take the main symptom to present the process.

Strong pulsating pain in the forehead that pulsates in harmony with heart pulse, ONLY on motion. When he lies still in his bed, there is no pain, but when he moves, however slightly, such as turning in his bed, his heart pulse accelerates immediately and the pulsating headache in the forehead presents itself.

Recording the symptom

There are no rubrics in Object Repertory, the symptoms are recorded as a network of interconnected objects, so we need to somehow specify what we are looking for. The most thorough way would be to record the symptom in the same format as is used for recording other symptoms within Object Repertory and then just hit the SOLVE button and wait until the software figures out the best matching remedy for the situation – by browsing and evaluating the existing networks of symptoms and the related ontological connections. On the image below is a visual representation of how you would record this single symptom (yes, it is a single symptom, albeit a complicated one).

While you have probably gone “Hell, no!” upon seeing the graph, it is really not THAT complicated, if you study it a bit. It takes a bit of getting used to, but once you get into it, you should be able to do it really quickly. In fact, you need to do the same thing in your mind anyway, in order to be able to understand the symptom fully and completely.

But even if you don't feel up to it (recording the symptoms directly), you could use an indirect approach and start with the things you ARE able to define easily.

So, step by step, the software would ask you such questions and if you answered correctly, you would still end up with a graph similar to the one shown above, the only difference being the questions and options offered to you by the software instead of you defining them directly. This mode of recording the symptoms can be used with great advantage as a case analysis helper tool. You just start with the phenomena presented by the patient and slowly, utilizing the pertinent questions offered by the software, work your way to a fully-defined symptom – although having a fully-defined symptom is quite relative as there are many more variants the software could nag you with, such as “And what about that motion aggravation – is it at the beginning of motion, on moving continuously or after the motion is finished?”; “What kind of rest are we talking about here – sitting, lying, watching TV, non-movement etc.” But at one point you decide to STOP, NO MORE QUESTIONS, GIVE ME YOUR BEST SHOT.

Evaluation

This is a very good part of the process. If your case is well-defined, the software will come up with the remedy automatically, offering a precise explanation why it believes this to be the best remedy and even quote the relevant parts of the materia medica, just for you.

If the case is not so well-defined, it will start asking the questions (yes, those same you wanted to stop in the previous point) to narrow down the choice of the remedies. If, for example, you only defined the pain in the forehead, it would start with “What kind of pain? How intense the pain? What aggravates the pain? Do you really want to be a homeopath?” etc.

Is it really possible?

I am sure every homeopath would like to have such a system, but it's not difficult to understand if some consider this a dubious sci-fi. So, is such a system a real option, is it possible? Yes, it is perfectly possible.

The power of the system lies in the way how data is recorded (object-connection relations) and their connection to the ontological net (a knowledge base defining how things work in general, what are the relations between various objects etc.). This way of storing symptom data does, in fact, employ the software with artificial intelligence, allowing it to reason in a similar way as a human being does. The more advanced the ontogical net, the better the reasoning.

For example, the software may reason like this – there is a pain in the forehead, it is pulsating and there is a concomitant action with heart → so this is probably a congestive headache. And it is able to make this connection by utilizing the definitions in the ontological net. With the advanced state of the underlying ontological net, which can be improved regardless and independently of the recorded symptoms, the possiblities are truly mind-blowing and will most likely surpass the abilities of even a best homeopath.

Such a system of symptom representation is a dream-come-true solution of the historical problem, which, until the invention of computers, remained and must have remained unsolved – you could either have a quick generalized index that is easy to use (repertory) or a fully represented symptom (materia medica) that is difficult to find and understand, but not both. Now, for the first time, we COULD have both.

If you are interested in learning more about this project, please continue here.