Thursday, July 15, 2010

Open Source H&P For More Efficient Hospital Care.

The cost of delivering health care in America is out of control.  Blame it on doctors.  Blame it on hospitals.  Blame it on drug companies.  Blame it on patients.  Everyone is to blame.  But, what are we going to do about it?  How can we make it cheaper? Efficiency is not the driver of  IT support. The perfect example is the  history and physical examination.  Performing an H&P is a basic skill learned in  medical school.  A history and physical has highly defined characteristics. What are these characteristics?   Here I give an explanation on how to bill the high level hospital admission CPT®  99223.   How much of this information is important in the H&P and how much is documented entirely for billing purposes is a matter for debate.  I suggest the vast majority of what is documented in an H&P is wasted time, money and resources.  It takes money to support IT.  It takes money to support transcription.  It takes money to pay for all the ink and paper to print all this stuff up.

Very few folks will ever end up reading your documentation.  The vast majority of an H&P is just killing trees. So how can we make it better?  How can we improve and  simplify the H&P process?  Under current fee for service, every physician must perform an H&P with all required E&M components to get paid. If you have a hospitalist, cardiologist, gastroenterologist, pulmonologist and nephrologist, seeing a patient,  every physician must complete their H&P or consult note to get paid.  

It's time to change all that.  Several months ago I was reviewing a chart from a patient in the ICU.  Every doctor's group had their own H&P.  Every single one of them was different.  The GI doctor only documented a FH for GI issues.  The cardiologist only documented issues related to the heart.  Everyone was doing their own thing.  There was no coherency in the H&P process.  I saw lots of inefficient reproduction of effort and in fact, multiple errors of commission  and omission.

Every doctor need to duplicate process because every doctor must do it to get paid.  Then it hit me.  Why not have an open source H&P?  Open source is a method.    It is a community effort to build upon and improve the final product.  Open source gives community access to all the key players in an effort to create the best possible product.  In this case, an effort to produce one grand H&P that documents key portions of a patient's medical history.  Why can't we have an open source H&P?  Because nobody pays for one unified effort.  Because nobody pays for it, no hospital's IT is set up to support it.  

Why should we have an open source H&P?  An open source history and physical could be the greatest efficiency weapon to hit patient care in decades. It has the ability to correct rampant inaccuracies in the patient's medical chart,  reduce waste, reduce transcription associated costs and improve and increase the speed and efficiency from which physicians can do their patient evaluations.  That means you need fewer doctors, fewer physician assistants and nurse practitioners spending less time doing data gathering.  There is no need for every doctor to reproduce all efforts every time.  Having access to an ongoing, constantly updated history could dramatically improve patient safety, reduce costs and increase efficiency.

Build it and they will come.  Talk about a physician recruitment and nurse retention  home run. This is the Holy Grail of medical documentation.  Much like the open source capability of Google's document platform  which allows any invited reader to edit the ongoing document and the ability to quickly and easily view those changes, some day I hope information technology departments provide physicians and nurses the ability to generate open source documents as a single updated face sheet that can  be reviewed on a daily basis and screened quickly for all changes in a predefined period of time. Open source H&Ps provide a simple solution to an expensive problem.
Print Friendly and PDF
Blog Widget by LinkWithin