Richard Rathe, MD

Associate Professor of Family Medicine (ret.) and Medical Informatician

The Rational HPI Project

This page is home to my ongoing study of the changes to Clinical Documentation in the age of Electronic Medical Records. Many of these changes are not positive!

I have been working on tools within the Epic Systems EMR for several years under the rubric Rational History of Present Illness (RHPI). In 2015 I created an open-source tool called quickHPI (which you will see referenced below). In 2017 I began work on a Clinical Shorthand (aka ShortNote) and a web app to interpret it.

Below I’ve listed the major issues that must be addressed by a more Rational History of Present Illness

  1. Striking a Balance Between Clicking and Typing – Many HPI forms have too much specificity for use in primary care. They tend to have fields of buttons where a few typed words would be faster and more precise. quickHPI avoids this trap by providing text fields where buttons just get in the way.
  2. Platform Independence and Best Practices – With the widespread adoption of EMRs, the HPI has gone underground. Each proprietary system has its own set of templates that are not generally accessible for open review and discussion. This inhibits collaboration, quality improvement and research. It is no wonder my initial literature review yielded very little useful guidance for this project. QuickHPI is open source and available to anyone with a web browser.
  3. Support for Problem-Oriented Charting – EMR history forms often fall down when documenting multiple complex problems. The resulting documentation suffers from duplication and lack of context.
  4. Drawing a Bright Line Between Associated Symptoms and the Review of Systems  – Healthcare in the US is all about rules. This includes documentation required for billing. From a physician’s perspective these rules are rather arcane. One casualty has been the outpatient note. In order for coders and auditors to efficiently review our notes, symptoms must be put into categories and certain key phrases must be present. Otherwise we run the risk of not being paid for our effort. A sad situation, but there it is. To a coder (and an EMR) a symptom is a symptom is a symptom, regardless of its clinical significance. This has led to the bad practice of including non-relevant symptoms in the HPI. Associated Symptoms (positive or negative) should be pertinent to the problem under discussion. The Review of Systems is just a series of questions without context.
  5. Format Notes to Facilitate Visual Scanning and Rapid Assimilation of Information – The phenomenon of Note Bloat is becoming a significant problem in healthcare. EMRs make it easy to build lengthy notes with a paucity of useful information (low signal to noise). Synthesized text may actually obscure the key findings! Even worse are the errors introduced when information is repeatedly copied (garbage in, garbage out). QuickHPI generates notes in a structured format that minimizes the amount of non-informative text. This is referred to as the Least Ink Principal

    The best clinical documentation is that which gives to the reader the greatest amount of information in the shortest time with the fewest pixels.

    Paraphrased from Edward R. Tufte
    The Visual Display of Quantitative Information