Of Progress Notes and Problem Lists

We need to squeeze the subjectivity out of healthcare and make it more measurable; more understandable from an algorithmic perspective. Data and math need to play a larger role in diagnosis and treatment. We're moving down this path, everywhere, so that's a good thing. A simple example is the widespread use of BMI (algorithm-based) as it relates to the diagnosis of "obesity." BMI is not perfect, but it's much better than the subjective definitions of proper body weight that my generation grew up with.


The current heartbeat of the EHR remains the subjective progress note-- and other text based reports. The progress note, though once helpful, is now the single biggest hindrance to physician efficiency in the use and adoption of the EHR. The progress note costs millions to workaround via transcription services. It's a bottleneck to closing the encounter and everything downstream that depends on that closing. It is an enormous anchor in our attempts to become more data and mathematically driven. I'd like to have a dime for every NLP project that has been funded in healthcare to overcome the subjective-objective barrier around progress notes and other text reports. Progress notes are too long to write and too long to read, and often times they are simply a summary of data from other measurable events like labs and medications. We need to change the cultural expectation in healthcare and the specific expectation of payers that the progress note is a necessary artifact of patient care-- it should become optional and applied only where history of present illness and/or diagnosis is particularly challenging, and discrete data cannot adequately tell the entire story to other members of the care team.

The problem list is simply another form of subjectivity, as currently utilized in healthcare. It's an abbreviated form of the progress note, with all the inherited variation and inability to reliably apply math or discrete analysis. In the past, I thought the problem list was going to become a breakthrough tool in healthcare, but I've seen it become yet another source of confusing information to the broader members of a care team, not a helpful tool. Problem lists have become personal versions of shorthand for the progress note-- and thus only reliably legible to the author.

If we could constrain the subjective contents of the problem list; use algorithms to populate the problem list where we can (e.g., infer diabetes from labs and meds); and apply industry-wide guidelines around its utilization, the problem list could become the most efficient way to "tell the story" of patient care, as well as become a more objective description of the clinical encounter and diagnosis, opening the door for discrete data analysis and the influence of math.


I offer these thoughts not as an IT guy trying to force a user interface on a physician, but rather as a lifelong "Information Utilization" guy who has had the benefit of exposure to many different information-intense environments.

Data Warehouse Data Modeling

This is a fairly tech-ish blog entry, but given the rise of importance and number of projects related to data warehousing and business intelligence in healthcare-- which is a good thing-- I am concerned about the continued rate of costly and poorly informed decisions in the execution of those projects. A blog entry on the topic is probably worthwhile, even if a bit techie. The essence of this blog was originally posted among members of the Healthcare Data Warehousing Association (http://www.hdwa.org/).

I would caution those who are beginning the data modeling journey, and those who are relatively new to the journey and can still save themselves-- There is no single data modeling dogma which will solve your data modeling needs in an Enterprise Data Warehouse. Neither Ralph Kimball, Claudia Imhoff, nor Bill Inmon-- the oft cited "experts" in the field-- have ever had to actually live with the theories they espouse, especially in healthcare, in an operational setting over a long period of time.

Your DW data model should address three general needs and "metamodels", as follows:

(1) Data models that are essentially copies and/or denormalized versions of the production source systems, including all of their bizarre naming conventions. Some people call these "Operational Data Stores"-- whatever you want to call them is fine with me, as long as you stick to the basic principle of, "Copy the source system data. Maintain the truth and fidelity of that data, for better or worse, as you bring it into the DW." Maintaining the fidelity of the source system data is critical because, like lost fidelity in an audio recording, you can't go back once it's lost. But, as long as you have the original recording, you can do whatever you want to with the recording downstream. Data Analysts who are familiar with the typically arcane nature of the source systems will love you for giving them a better and easier place to run their queries than what they've had for the past 10-15 years in the source system environments, and they don't have to learn anything new about the data structures since you were so kind as to keep them intact.

(2) Data models that represent specialized data marts, spun off from the source system data models. These specialized data marts are driven by unique requirements-- let's say a financial dashboard or a diabetes registry or a full-fledged clinical quality improvement project-- and each of these unique data marts will also have their own unique and optimal way to model the data, including naming conventions that are customized to the Data Analysts in those unique environments. In 80% or more of the cases, most Data Analysts want simple rows and columns of data--there's a reason Excel is so beloved and there's a reason that the success of multidimensional cubes is not more widespread. In some cases, the analysis requirements might best be served by a star schema data model; or a snowflake; or a single wide and deep table with lots of redundancy, such as a row for every patient's encounter; or even a second or third normal form data model. The bottom line: Go with what works, with the simplest data model, and remember that most people will be very happy with simple rows and columns of data that they can suck into Excel for manipulation.

(3) A Master Reference data model area where you can store things for look-up (e.g., for data quality checks) like ICD-9 codes; CPT codes; SNOMED terms; LOINC terms; Drug codes; the Master Patient Index and Master Provider Index; local standards for department, facility, service line, charge codes; etc.

If you need a decent starting place to grease the wheels of your mind for a generalized healthcare data model, take a look at HL7 RIM and i2b2. They are at different ends of the data modeling spectrum-- RIM is pretty much 3NF and i2b2 is pretty much a star schema with a pinch of EAV-- but for gawd sake don't assume that either of these models will be the single data modeling approach which will satisfy all the needs that you will face in a healthcare data warehouse. Many healthcare organizations drank the Kimball Kool-Aid early in their evolution of BI and DW, and they are now discovering that they painted themselves in a corner that's going to cost a lot of time and money to unpaint.

In summary: (1) Maintain the fidelity of your source system data; (2) Design your subsequent data marts using the data model that makes sense for the analysts and reporting needs associated with that data mart; (3) Provide a robust Master Reference data model area which can be joined to your source system "Operational Data Stores" and specialized data marts.

Don't paint yourselves in a corner. Trust your common sense. Kimball, Imhoff, and Inmon know far less than you do about this topic.

Martin Luther King Day

Often times, we celebrate today as a day of tolerance for diversity, but tolerance is a frail description for what Martin Luther King envisioned. Tolerance for diversity is not enough. We are obliged to be grateful for it. We must be fascinated and humbled by it. In the sum of diversity in Mother Nature, we humans among that, we glimpse the sum of God's knowledge which connects us all.

Today we honor the man whose valor and Dream enabled tomorrow’s miracle. No matter what your political affiliation, tomorrow’s inauguration is undeniably amazing. In 1986—only 20 some years ago-- when this day was declared a national holiday, there were many among us who felt it unwarranted. Those feelings were largely a hangover from the discriminatory beliefs which the Day itself sought to overshadow. The path to tomorrow’s inauguration was tiled by the words and blood of a pastor from Atlanta, Georgia who found inspiration from non-violent, compassionate protest in another hero of humankind known simply by a singular name—Gandhi. It is no accident, but seems divine providence, which ensures the appearance of a person who, in the dark periods of humanity, emerges to keep the balance tipped toward good in the struggle between good and evil. Recall through history the emergence of these single individuals who appeared on stage and kept the story of God’s great experiment moving forward when violence and oppression seemed all but guaranteeing the end of good. Martin Luther King and Gandhi... Abraham Lincoln, Franklin Roosevelt, and Winston Churchill, are them too, along with many other pure souls, absent of fame or notoriety. There is great hope in the world that the man whose inauguration to President was made possible tomorrow by the man we honor today, is another such figure in another troubled period in human history.

As the colors in the palate of God’s artistry paint a picture which constantly progresses, we must embrace diversity as an invaluable clue to understanding our purpose in the Universe. Today especially, look around you. Extend a hand and offer a smile. Live The Dream. See the wonder, amazement, and beauty in the Colors of that palate. And be humbled by it all.

Investing in Mediocrity?

As reported in a recent article in the Boston Globe, David Kibbe, a senior adviser to the American Academy of Family Physicians, and Bruce Klepper, a healthcare market analyst, sent an open letter to our new president-elect, urging caution in the rush to invest in healthcare IT. Describing current systems as "expensive, cumbersome to use, and cannot easily exchange information about patients' health histories and treatments among different hospitals, labs, and doctors' offices. If America's physician practices suddenly rushed to install the systems of their choice, it would only dramatically intensify the [tower of] Babel that already exists."


The rush to deploy current market-leading EHRs is going to lock many healthcare systems into costly and imperfect clinical processes and technology. The functional difference between today's EHRs is minimal; they are rapidly converging on achieving commodity status, as the same old ideas are recirculated through the revolving door of HIMSS and AMIA. These EHRs are a hangover from the paper chart and motivated largely from the historical position of billing compliance and malpractice risk avoidance. They unfortunately perpetuate many of the ills of healthcare, rather than solve them.


We desperately need a revolutionary new approach in the design and functionality of EHRs-- one that is motivated from a position of physician efficiency, quality of care, and patient involvement in their own healthcare management-- with billing compliance and malpractice risk avoidance a natural but transparent consequence. Sinking billions of dollars into the current EHR market will leave no money or free market incentive remaining in the healthcare system to affect the revolutionary change in EHRs that we need. We should tell the EHR vendor market-- those in existence now and those who might emerge if sufficiently prompted--we expect more. As a taxpayer, I would protest major investments or subsidies of government money in the existing EHR market-- such investments would only reward mediocrity. As a healthcare IT professional, I would despair.


We should invest our healthcare IT dollars cautiously and in proven areas of value-- in many physician offices, this could be as simple as computerized registration, scheduling, and billing which improve clinical efficiency; access to wideband Internet services and the emerging lean (and inexpensive) web-based EHRs and PHRs (e.g., Relay Health) which support computerized order entry, especially ePrescribing; and tools that integrate data from existing diagnostic systems into a single user interface for quick reference by busy physicians.


The only thing worse than deploying an EHR is replacing one. Rather than rush headlong into purchasing a mediocre EHR today, we should pause, withhold our funds, and give free market capitalism a chance to react and catch-up to the opportunity by developing a new breed of EHRs which will leapfrog current thinking.