Building Archimedes - a Q&A with 'Dr. Data' - ' Parts of the Archimedes '

Parts of the Archimedes Model

What are the parts of the model?

There are three main parts to model: human anatomy and physiology, care processes, and system resources. For the first, the model consists of thousands of simulated people. Each of them has a simulated anatomy and physiology, all represented at a clinically realistic level of detail in the form of differential equations. Each of them can develop diseases, get signs and symptoms, have behaviors and seek care. This brings us to the second part, the care processes. In the model, as in reality, when a person seeks care, a chain of clinical events is set in motion – taking a history and physical, doing tests, making decisions, giving treatments, following up and so forth. The care-process part of the model represents all of this with equations. The third part of the model – the system resources – simulates everything that happens as our simulated patient progresses through the healthcare system. It models every appointment, test, admission, use of a drug…and all the personnel, facilities, equipment and supplies, down to the sponges and finger cots if necessary.

Finally, the model keeps track of costs; every use of every object at every time is captured and available for any type of accounting or forecasting you might want. Put all these together and you have a virtual world that simulates, at a high level of detail, what happens in the real world. The beauty of this virtual world is that you can use it to explore hundreds of questions that would be infeasible to explore in the real world because of time, cost, need to randomize, sample size, unwillingness of patients or physicians to participate, or pace of technological change.

How did you and Len Schlessinger come up with the conceptual approach for Archimedes?

There were two main conceptual problems that had to be solved. One was the sheer size and complexity of the model, which would be several orders of magnitude larger and richer than any other model in healthcare. The other was the modeling of diseases. We were going to have to come up with a much more realistic model of physiology and clinical disease than currently existed.

For the first, I had heard about a mathematical model of the European War Theatre used by the U.S. Defense Dept. It included every town, every hill, and every road. The model knew whether a road was paved or unpaved, sand or dirt, because that would affect the speed of vehicles in the rain or shine. It included every jeep, personnel, even the rounds of ammunition. I said to myself, that's exactly what I want to do with healthcare. Len and I then learned that that model was written with object-oriented programming. So we decided to write ours in object-oriented programming, which has been a crucial part of this model.

With that decision in place, the other critical problem was how to model diseases. The traditional way of thinking about a disease is that it is an entity – something you "get," like "my father 'has' prostate cancer." But as we began to think about it, it became clear that a disease is really just a label, a name we place on a patient when certain biological conditions exist or criteria are met. This distinction is emphasized when you realize that many diseases are "man-made." For example, "hypertension," "hypercholesterolemia" or "osteoporosis" didn't even exist until some committee defined them to exist. Furthermore, different committees often defined the "same" disease in different ways, or they would change a definition. What this meant was that we needed to ignore the traditional concepts of disease and focus on the underlying biological variables on which they are defined.

That helped, but we still had to get all this into the language of object-oriented programming. That is, we had to cast everything important about diseases as objects. As we began to do that we saw immediately that we could cast a biological variable, like a person's blood pressure, as an object, but we quickly realized that there were other aspects of a disease that had no physical counterpart. A person's ability to read an eye chart is an example. "Pain" or "depression" are other examples. To address this we came up with the general concept of a "feature." Features could be physical, behavioral, psychological or anything else needed to capture the variables on which diseases are based.

The last piece of the disease puzzle was to model the "causes" of diseases. For some diseases, like pneumonia, the cause is clear and is easily cast as an object or feature. But for many diseases the cause is not known. Alzheimer's or even diabetes are examples. The breakthrough here was the realization that we could postulate imaginary features to represent the unknown causes of diseases. Thus, in the model, Type 2 diabetes is caused by something we call "Type 2 diabetes feature." That might seem fraudulent until you realize that, even though these things we call "primary features" are imaginary, it is possible to write equations for them that accurately reproduce the occurrence and progression of the real diseases. The best way to think about them is that we have described with equations the real causes of the diseases – they just haven't been found yet by the scientists, much in the way that Pluto's existence and position was predicted from Newton's equations years before it was finally spotted with a telescope.

How long did all this take?

Just days. Were we locked up in a room? No. I think we were in an airport. Once we both understood object-oriented programming well enough, we pretty much simultaneously came up with the idea for diseases as labels, features and imaginary/primary features. As I recall it, we were both looking at each other, both talking, and both saying the same thing. Was there a thrill? Yes. Imagine the moment in a bridge hand, or maybe a chess game when you see that you are going to make it. Take that moment and multiply it by ten.

The next task was to write equations for each of the features, hundreds, as functions of all the other features. Think of writing an equation for the orbit of each planet, subject to the gravitational pulls of not only the sun but all the other planets. Because the great majority of features are continuous, and because time is continuous, it was clear – although new for clinical modeling – that the form of the mathematics should be differential equations. To complete the illustration, this is the branch of mathematics Newton invented to analyze the planets. Here is where Len's strengths become so important. The branch of mathematics I specialized in was not the right kind, which probably explains why I didn't do this on my own much sooner. Len, in addition to being extremely smart, had the right training. He has taken the lead in developing a general method for deriving the equations we need from various types of data sources – patient specific data, like you would get from an automated medical record, or aggregated data, like those found in reports of clinical trials. How many equations are there? Scores, probably hundreds, we have never counted them.