The APACHE II Score is the most-referenced risk score for ICU mortality, with over 15,000 citations in PubMed since its publication 22 years ago, and is still used today both clinically and in research. We talked with Dr. William Knaus, first author on the APACHE paper, about his experience in developing the APACHE II Score, as well as the increasing need for technology in healthcare (and its disappointing uptake and implementation).
When we started [developing APACHE] in the 1970s, DRGs [diagnosis-related groups] were just coming on the scene, and obviously they were oriented towards the business and financing aspects of healthcare. There’s little correlation to the clinical. But people were relying on DRGs as a way to classify and identify patients, especially in the ICU. So it was important at that time to not so much reinvent the diagnostic system, but to talk about how patients come in at different levels of severity. And at that time, there was really nothing out there. People would use one single blood test, like a blood lactate level, and then they would pick a threshold, above this or below that. But drawing thresholds is a losing method when you have a continuous measure, like blood lactate. Then Bryan Jennett created the Glasgow Coma Scale score, and was very successful with that. But that only applied to head trauma patients and emergencies.
So we started looking at the role of using physiology of a patient in the intensive care unit and to then develop a comprehensive measure of severity that could at least begin to discriminate one patient from another better than the DRG. We were unexpectedly well-received. At our first critical care congress in the late ’70s, there was an extraordinary amount of interest, and so we began to pursue that. We evolved that—it had a large number of variables, and even something as simple as the equations we had developed for APACHE at that time, you would have to put them on the computer on Friday evening and wait until Monday morning. We were dealing with technology that was still not able to handle computations of large volume. So we decided to hone down APACHE II to put it down on one side of a piece of paper, and I think that was the single most important efficiency that we made. I remember we had a research associate who was hiking in the Himalayas, and she was hospitalized in Kuala Lumpur, she said there was nothing in the hospital, some oxygen, no mattresses. But there was APACHE II, taped to the wall. So we knew that there was something to the simplicity of the use of that.
There was a big strategic discussion about whether we should just stop and then just continuously update with a new database, because as we know now, with the scoring systems of any kind of classification system, it’s not like wine, it doesn’t get better with age. You need a database that is very current. APACHE II published a couple years ago how much the outcomes in critical care had changed across the spectrum and we are doing better than we had before, so databases from years and years ago don’t really represent contemporary outcomes.
But at that time, technology was getting a lot better, computers were beginning to run faster, we had a lot more computer speed, and we envisioned the future even in the late ’80s and early ’90s that we could have an algorithmic-based system that would retrieve data automatically for people, and be able to help them make critical decisions based on how sick the patient was, whether the therapy was working, how long the patient was anticipated to stay, etc. It was the last time that the country before most recently was trying to make some headway with interoperability in healthcare technology.
But at that time we didn’t know. We were looking forward towards the future where people would be collecting data and using scoring systems, like they still do on MDCalc, and would be able to consult a computer, much like Google’s algorithms do now. It’s continuously learning from the database who you are, what you ask for, etc. And we really thought that you could have a system which was dynamic and algorithmic-based, that could start to provide some decision support that I and many others felt we needed.
And of course what has happened, to make a long story short, that in the decades since APACHE II was published, it’s been extraordinarily disappointing to me personally, that we’ve made such little progress in pushing healthcare technology forward with interoperability and with modern computers. We ended up not being able to achieve those very ambitious goals. I think it continues, it’s being updated nicely, and over the years the full APACHE IV system, which is the latest version with the latest algorithm and database, is not really being used nearly asmuch as APACHE II.
So in retrospect, if we had known the future was going to be as limited in the development of healthcare technology, I think we would’ve said, let’s stay with APACHE II and let’s just try and update the database so it would be compatible with contemporary outcomes. While we have developed systems like APACHE IV which are much more sensitive and much more capable than APACHE II, the ability to feed those algorithms automatically is still extremely limited. So if you’re using APACHE, make sure you use it with a database, either yours or someone else’s, that uses contemporary patients, so the relationship between the score and what happens to people does change over time. You can use the same score, but you want to have current patients and their outcomes in the system.
The inability, for whatever reason, of healthcare to achieve the same degree of technology that the banking and retail and all other large industries have, is going to be seen as the major shortcoming of modern times. I don’t want to comment on who is responsible for that, but we have a series of products that historically began in business, in the financial offices, and never saw or never wanted to develop the capability to talk to each other. That’s what we’re unfortunately stuck with.
People are taken care of by clinicians, but there is no system out there that was designed primarily with clinicians in mind. Whereas all these websites that are so popular—Google, Amazon, Apple you name it—why are they so popular? Because they take information about what the user wants and what the user needs. The user is a person, an individual. It’s not an institution. If only medicine had been able to see that, and somehow make that transition from developing an information system for an institution or a practice as opposed to developing it for the individuals using it. I haven’t seen that happen.
ABOUT THE CREATOR
William Knaus, MD, is a professor of medicine at The University of Chicago and director of Applied Genomics Research Informatics at NorthShore University Health System. Dr. Knaus is an active researcher in many areas including cancer genomics, sepsis, and outcomes of seriously ill patients.
To view Dr. Knaus’ publications, visit PubMed