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.

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
    “Open Tool Support for System-Theoretic Process Analysis” by Asim Abdulkhaleq and Stefan Wagner
    “Using FRAM as a Quality Improvement Tool in Health Care”
    “Combining FMEA and FRAM in Healthcare Settings”
    There are a number of papers on the application of Functional Resonance Analysis Method (FRAM) in Healthcare Systems which are essentially Complex Adaptive Socio-Technical Systems.

    1. Thanks again. How does FRAM differ from cognitive work analysis? There seems to be a substantial overlap. CWA begin with the assessment of work environments/safety in nuclear power plants. Both FRAM and CWA seem to address the same problems in similar ways.

  3. Are you giving easy examples with the thought that diagnoses can be made more accurately, more easily, and/or more quickly with algorithms? I was thinking about that after talking to someone who said that the goal of his project was to “put in the hands of consumers a device on their smart phones that could access any piece of information they need in 15 seconds”. I was thinking, “What other type of problem do we think we can access the information in 15 seconds?” Or am I just not thinking in “new math” terms? In other words, are you thinking that consumers could put in information (direct measurements from devices or hand enter information) and receive a diagnosis as accurate as a clinician could supply in less time and at less expense? It sounds like self-navigating cars and airplanes, so maybe that’s what you’re saying. That doesn’t mean you are also giving the solution, but perhaps a set of options could be included with plans and costs attached. Is that medical care of the future?

    1. Hi Sandra, actually the goal was purely mathematical. I am proposing a more structured way of looking at what happens during clinical work from the standpoint of the recurrent patterns that occur. Diagnostic error is a major problem, and we need a better way of understanding errors. Often, when problems are described mathematically, it becomes possible to analyze them as abstractions that can then be used in real-world situations. I am convinced that both clinical software design and clinical informatics would be more robust if they could be understood mathematically. It is probably a pipe dream, but it worked on other fields, why not healthcare?

  4. Prolog is one of my favorite languages. I actually used to write a turbo prolog newsletter in the 80s.

Leave a Reply

Your email address will not be published. Required fields are marked *