The promise of healthcare IT lies in the gulf—the one between what computers can do with speed and precision versus what healthcare can do to properly structure the data. In the end, the idea is that the precision and speed of IT will enable doctors and nurses to make better decisions with robust, real-time data delivered to them by precisely the right tool in the right space. While the government and other players are adding pressure to bridge the gulf, fundamental issues remain. HealthLeaders Media recently convened a panel of IT experts to address these questions.
John P. Kichak
vice president and chief information officer,
UNC Health Care,
Chapel Hill, NC
Richard Vaughn, MD
corporate vice president-clinical decision support,
SSM Health Care,
St. Louis, MO
Barbara R. Paul, MD
senior vice president and chief medical officer,
Community Health Systems, Franklin, TN
director of healthcare sales,
Sponsored by: CDW Healthcare
: The federal government clearly hopes to use the provisions in the HITECH Act to spread healthcare IT as a quality tool. What are the challenges with the levers they are pulling?
BARBARA R. PAUL
: CMS has moved squarely off of their old paradigm. Ten years ago, CMS was a pass-through bill payer and regulator. In fact, while I was there, leadership looked at quality-related data being collected through the Quality Improvement Organization (QIO) program, and realized that, while quality was improving, the pace was unacceptably slow. So there was a concerted effort internally to figure out what additional levers Medicare could apply to further incent, enable, or stimulate higher quality. Public reporting, pay-for-performance efforts, and even the healthcare reform debate—in which they're talking about changing large aspects of how payment occurs—are all part of this quality push. The other two pieces of Medicare's push are the creation and enforcement of IT standards and the support of enabling IT infrastructure. So, Medicare clearly sees the push that's going on right now with IT and with standards as part of a broad application of every lever they can find to incentivize, and stimulate higher-quality care. You're going to see more of this as time goes on.
JOHN P. KICHAK
: They are also pushing standardization through the back-end bill processes to be able to manage quality reporting. But they're also pushing a value proposition through HITECH, which is that they don't want the provider running that extra MRI; they don't want to pay for that extra MRI. And IT is a big part of that.
: Part of what's going on right now at the hospital level is that, first, there are core measures, which are chart abstracted. Someone, usually a nurse, reviews charts, finds the information and submits it through a process for public reporting of clinical process of care measures. And second, Medicare is also mining billing claims data for complication rates and mortality rates. So, as hospitals, we've got two different data sets populating the measures that are being publicly reported. One of the promises of EHR will be to have all of this information coming out the back side of a clinically robust data collection tool that is in real time. That way, we won't have people running down the hall looking for the doctor to make sure that he or she gave that beta-blocker, and/or we won't have stale claims data creating stale mortality rates and complication rates. I'm hoping that the EHRs can help to bring all that together into something that's much more clinically relevant.
: Do these provisions accelerate the path to concurrent data?
: The problem I see is that most of the electronic healthcare systems that are out there are, at best, version 1.5 clinical decision-support tools. Part of the problem is you can't get enough context around the patient. If you can't get your physicians to put in a coded nomenclature for problems, or if a nomenclature is not precise enough, then you can't run good decision-support rules. That's where we're going to have our problem, is getting enough context around the patient, getting our physicians to enter structured data.
: Most of those EHR IT systems ask the physician to enter in a patient's problems, and then the software provides some dictionary definition. Every vendor product has a different data model behind the scenes that they report off of for the decision support. That's where HITECH is trying to force that data to come together, because they're providing the standards. The key still is going to be that these EHRs have to learn "my" problems as a physician—learn what I do and what I assign and what I prescribe.
: My hope would be to leverage our academic institutions, let them build the rules, and then import those rules into various vendor products so that we're not all trapped in a vendor lock where we have to re-create the rules. Yes, we can reinterpret them, but let's let our academic institutions who are doing the research publish what is the standard of care and what makes sense. It doesn't necessarily have to be evidence-based medicine. It also could be the most efficient care from the state of knowledge about this disease process. We need to think two generations ahead as we build out our IT infrastructure and ask how can we leverage this and be very flexible in importing knowledge.
: Given the conditions and the complexity of the market, we're encouraging the community to establish standards so that we can move forward with well-funded development. In my opinion, the two biggest issues are the incredible complexity of these undertakings and the lack of funding. The average healthcare organization spends less than 2% of its overall
revenues on IT. And the kinds of
initiatives we're discussing are very, very costly. So unless we achieve some level of standardization, it's going to be challenging for the technology vendor community to further modify current applications to accommodate compliance requirements.
Time for IT
: Are the timelines laid out for IT implementation in the American Recovery and Reinvestment Act of 2009 realistic?
: There are different players within the vendor community, each with a unique perspective. Most of the technology providers are currently prepared to enable the capture, warehousing, and transmission of the data in question. The potential delay exists with the modification of applications to meet compliance requirements, followed by a necessarily lengthy implementation process. It's a lot of work to complete by 2011. Given the lack of sufficient funding coupled with the disagreement over standards, I think meeting the 2011 deadline may be difficult for many providers.
: It does provide a good push to move faster than we would have. That in itself is good, but it is an awfully aggressive timeline.
: There's been a big concern about the vendors being able to scale. That's going to be very interesting to watch, to see if they can deliver the same level of service and competence and special relationships with their clients. And the support side is another issue. Physicians, as we all know, expect that if they have a problem that you already figured it out and you're standing at their elbow before they can ask for help.
: We don't have the trained IT staff we need available. We've put everything overseas. So now we've got to bring it back to have the people to be able to implement it. So we're looking at a tremendous culture shift, because for so many years, we all were trying to cut costs, so we farmed out everything.
: The meaningful use directives call for 10% of orders to be entered in 2011. Is that bar too high or too low?
: My own personal feeling is I was a bit taken aback that they relaxed the meaningful use guidelines back to 10% of CPOE. I definitely think that we need to be moving toward CPOE. It's the foundation inpatient system from which everything else happens. I was hoping more in the neighborhood of about a third, to try to get more adoption, because it is the hardest application to get physician usage on because it's very labor intensive. As we implemented the CPOE, we almost added two hours to the day of a physician, and that was eight years ago. Over time, we have been able to now save them about 30 minutes, but it took us a long period of time to accomplish that and now we're going to expect everybody else to do that in 18 months to two years.
: The complex part of the equation isn't the functionality of the technology—it's the time needed to validate a technology's ability to support the hospital's workflow and patient safety requirements. One of our large hospital customers is deploying a palm-reading device for patient identification, and it's taken them two years to validate that the technology complies with patient care demands. That gives you an idea of how long it takes before a hospital can legitimize a technology investment and confirm that it won't compromise patient care.