Principles of Medicine for Engineers
Part 3: Mappings
From hardware to states to clinical symptoms
Our job as physicians is to take care of people in their multi-layered complexity. That means we need to understand how each of the layers affect each other.
In Part 1 and Part 2 we laid the foundations of systems medicine. The idea is that we can analyse anything, even complex things like (patho)physiology, most effectively if we stick to some core engineering principles.
In this part, I’ll lay a foundation of mappings, or relationships between distinct layers of understanding. This will be important to make sure we don’t criss-cross our wires between what’s actually happening, what we’re measuring as happening, and what the patient is experiencing.
What is a mapping?
Mathematics gives us a good definition of mapping. Simply: a set of rules that tells us how we go from one set of things to another set of things. In our systems language, the relationship between inputs and outputs can be described as a mapping.
Every part of this definition is important, eventually, but for now the important thing is: maps can get tangled — it’s not always possible to trace things back simply.
Example
One of the easiest mappings we can think of is the mapping from symptoms to binary disease state.
For example, we have a fairly simple mapping that we use to determine whether a patient has diabetes or not:
Here, we go from the measurement layer to the binarized disease layer. Is your fasting plasma glucose > 126? And/or is your A1c > 6.5%?
We can easily start adding nuance to this — namely pre-diabetes as an element of the “DM?” layer, an oral tolerance test as a control-impulse, etc. We’ll do that explicitly later.
The Three Layers
When trying to understand, I like to work in three layers: the hardware, the state/phase space, and the clinical statespace.
Using the heart+aorta organs as an example, we can see how the three layers may relate to each other. This is meant just as a first-order illustration, not as an accurate model cardiac model.
Here, our system is shown in grey. Note, we’re defining our system as the aorta, not the heart, here. That reflects our priorities, worries, differential, etc.
The states we chose to focus on were cardiac output (CO) and aortic flow (AF). The diagonal line reflects 1:1, a special case where the CO and AF are equal. In a “normal” (in the statistical sense) person, the AF is about equal to the CO, minus whatever blood goes above.
But if the aorta has some disease, we may see the AF decrease substantially. With a maintained CO, this may “map to” something like aortic rupture symptoms; with a reduced CO this may mean something more upstream in the circuit, like heart failure.
The Links
In the mapping view, we can trace out the different behaviors of the hardware in the state space, and then find a clean mapping from the statespace to symptoms and/or diagnoses. The goal is to find a clean link between all of these layers — an understanding of full (patho)physiology.
If we design our layers just right, we can push all of our complexity into layers and keep the interaction between layers quite simple. This has major implications for how we are able to treat diseases whether they seem complex or not.
This three-layer structure is purely from convenience and repeated demonstrations that these three layers are all I need to get ~70% of the way there. That is, of course, related to the things that I care about.
Summary
Mappings are at the heart of what physicians care about, and the structure of mappings is important as we try to understand how (patho)physiology pushes-forward to cause symptoms, and how we can try to invert the process to go from symptoms to (patho)physiology.
When trying to manage a disorder, we have to have to add a few more layers into the mix, and we have to better understand how these layers keep themselves in check with control loops. More on that next.
