# A Mathematical View of Clinical Work

Whenever I mention working on models of clinical work or describing clinical care mathematically, the comments vary from how esoteric such an endeavor seems to protestations that medicine is an art.  Math is not out of place in medicine. In fact, it is part of everyday practice; it is simply not recognized as such.

Back in the sixth grade when I first encountered the “new math,” the discussion of sets was interesting enough, but the value of sets was not obvious.  Nowadays, everyone knows about sets, and still the value of using sets to solve problems outside of those in math books is lost on most.  Even so, clinical care, like everything else, is replete with sets.

Of course, simply naming sets and identifying what they contain by itself is not a very interesting way to spend one’s time. Add a few algorithms, though, and things get interesting.

Clinicians spend a good amount of time diagnosing ailments.  One way of looking at the diagnosis process is as a relation between sets.  Let’s say there are two sets: everyone (U) and those with diagnosis “X” (D).  The main problem to be solved is determining how to identify who from U is also in D. For this, we need an algorithm.

Predicates
Predicate logic provides one way of looking at the diagnostic process mathematically.   We can use a predicate of the form Diagnosis (x) to represent the English statement: x has this diagnosis. Thus, if hypertension is the problem of interest, then Hypertension (x) is a way of saying: “x has hypertension.”

Starting with every living human being as a member of the universal set, we need criteria to move anyone from U to D. D is called the truth set for our Hypertension (x) predicate, and every person with hypertension is a member of D, except we have no idea who those people are.

What makes for a good algorithm? Obviously, we want to identify every person in U who belongs in D, but how? The best algorithm will be one that correctly places each person in U with hypertension into D, and never places a person without hypertension into D.

To build the algorithm we need criteria to use for screening purposes. Assuming that a BP greater than 140/90 counts as hypertensive, we use this to start the algorithm.

If BP (x) > 140/90, Then Hypertension (x)

We can make this more formal by making it a universal conditional statement.

For all x in U, If BP (x) > 140/90, Then Hypertension (x)

In its current form, this is a little too simplistic for real life.  Let’s allow for variations and say that BP readings should be at least two weeks apart and number 3 should be done before making the final diagnosis.

1. IF ( BP (x) > 140/90 ), THEN repeat Measurement after 2 weeks
2. IF ( BP (x) > 140/90 ), THEN repeat Measurement after 2 weeks
3. IF ( BP (x) > 140/90 ), THEN Hypertension (x)

This is the beginning of a basic algorithm for diagnosing hypertension.   It is both easy for humans to learn and to create in computer code.

Of course, additional criteria that look for secondary causes of hypertension could be added to the algorithm as well.

Making use of truth sets
Earlier, I mentioned that the truth set of a predicate contains the elements that make the predicate true. This fact becomes useful in many situations.   Truth sets can be collected by applying an algorithm one person at a time (diagnosing), or when using database technology, by executing a query (aggregating).   For example, in an EHR a search for the ICD code for hypertension (401.9) would return everyone with that code in their problem list. Another way of gathering a truth set would be searching through vital signs while looking for everyone with three BPs greater than 140/90 who had no medications listed for hypertension.

Once a truth set is available, it can be used for many applications — monitoring treatment effectiveness, finding subjects for clinical trials, creating a registry, or screening for complications.

As a medical student and resident, I was taught biostatistics — predictive value, Bayes theorem, etc., which were quite informative, but hard to apply when interacting with a patient. Looking back, predicate logic, truth sets, and algorithms would have been great aids in helping me understand and structure my thinking because they are closer in form to the thought patterns seen in diagnosing problems. Frankly, I think practice guidelines would make more sense if discussed in terms of both logic and clinical evidence.

Everyday clinical practice is mathematical. Diagnostic criteria, treatment guidelines, lab procedures, etc. are all algorithms, which means their results are sets. Any process that can be reliably reproduced contains some type of pattern, and if there is a pattern, it can be described and studied mathematically.   The value of looking at clinical care mathematically should not be underrated.   Since programming relies on algorithms, and algorithms are inherently mathematical, clinical software design might benefit significantly (see Yes, Programming Is Math…).

Studying clinical algorithms as both clinical and mathematical objects would provide a new means of analyzing clinical care. In addition, a library of tested mathematically-based clinical algorithms would prevent those who are new to clinical software development from having to reinvent the wheel.   As it turns out, the new math is really useful…

1. This was quite an interesting read. Are you aware of any softwares that are doing this currently in clinical research? What do you feel would be the major benefits of having such a software available, and specifically, how do you feel this software might be implemented during research programs?

1. Matt, thanks for your comment. No, I am
not aware of any software that converts logic to clinical applications. Yes, I do think predicate logic is feasible in clinical research. After all, all research protocols are algorithms…

2. May I suggest the following papers in the context of EHR Systems and Clinical Guidelines/Protocols/Workflows–
“A Science of Connectedness” by Kurt C. Stange
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2746514/
“Open Tool Support for System-Theoretic Process Analysis” by Asim Abdulkhaleq and Stefan Wagner