Dealing with EHR Dissatisfaction (Part 5)

This post is a continuation; Part 1 is at this link. In this post, I describe a examine the question: When it comes to EHRs, whose satisfaction is important?

Someone commented that EHR “satisfaction is in the eye of who? The physician? patient? government? business?... I only hope it is the patient that wins out.” This comment is intimately tied to the question: Who should gain the most VALUE/BENEFITS from EHR/health IT use?

I contend that if they improve clinical outcomes and quality-of-life (through prevention and treatment), while they contain or lower costs to providers/clinicians and prices to consumers/patients (i.e., increasing value/benefits to the providers and receivers of care), then our society (and species) wins in the long haul. A business model that focuses on short-term gains for “me & mine,” rather than on realizing a longer-term vision that focuses on the common good, inevitably harms consumers and those who care for them.

Beneficiaries of this dysfunctional business model are manufacturers, politicians, lobbyists, providers, consumers and others who line their pockets by “gaming the system” through all sorts of unscrupulous (and at times illegal) tactics. Some might conclude that this is just “the American way,” but based on the huge waste of money and resources in the in the UK's health IT system (NHS IT system one of 'worst fiascos ever'), I believe it’s a consequence of capitalism that has lost its way, along with its sense of virtue.

I contend that the underlying cause of our broken healthcare system is our pathologically mutated form of capitalism —a term coined by John Bogle, named by FORTUNE magazine as one of the four giants of the 20th century and by TIME magazine as one of the world's 100 most powerful and influential people—which he said is a “fundamentally a blight on our society…It says something very bad about American society…ultimately, the job of capitalism is to serve the consumer. Serve the citizenry. You're allowed to make a profit for that. But, you've got to provide good products and services at fair prices…What we've done is have…a pathological mutation of capitalism” (see this link).

The rational way forward with regards to EHRs, I contend, is for clinicians to demand health IT tools that enable them to increase value to the consumer and demand fair compensation for doing so (Pay for Value). These tools should be low cost, flexible, ever-evolving, interoperable, and highly useable & useful for the clinician, patient, and researcher/informaticists. It should combine the best (and simplest) methods for data entry, analytics, decision support, and presentation (display), as well as secure transport and storage. They should also be efficient and accommodate workflows (including referral point-of-care, and mandatory reporting processes), and they should include the capabilities that include clinical concept parsing & processing (i.e., tools that improve the use of clinical notes and aid in inductive and deductive reasoning). In addition, they should provide ongoing risk-adjusted information to clinicians about their individual patients and population (cohort) outcomes.

The use of innovative EHR add-ons (companion applications) is a sensible way forward, even though EHR vendors may resist for business reasons that run contrary to the goal of increasing value for patient and provider, which is not surprising as per Bogle’s criticism and the need for "real capitalism, not crony capitalism that we have now in many industries, especially healthcare.” And while EHRs should be able to incorporate information directly from patients, it should also be able to associate and substantiate it with clinical technicalities.

These capabilities are simply way too much for any EHR today, but they can be achieved over time through collaboration that expresses our views and needs, embraces creative destruction, and suppresses regulatory capture that increases complexity, cost, and inefficiency.

Dealing with EHR Dissatisfaction (Part 4)

This post is a continuation; Part 1 is at this link. In this post, I describe a vision of an ideal EHR system that can developed today.

Based on the complaints about EHRs, one can conclude that there would be increased satisfaction if EHRs are thought to be a component of an all-encompassing HIT system. This next-generation computerized system would manage clinical information, as well as administrative data, in a way that increases provider efficiency, enables providers to deliver high-value (cost-effective/safe/quality) preventive and acute care and rewards them for doing so, assists patients/consumers in taking better care of themselves (self-maintenance), and promotes population health.

So, imagine coming together to build a novel EHR-based HIT system that continuously improves clinical and economic outcomes by (in no particular order):

• Capturing clinical information accurately and automatically at point-of-care in real time in a way that requires little effort and workflow change

• Clearly presenting—to clinicians and patients—the biomedical, psychosocial (biopsychosocial) and economic information they need to: (a) bridge the knowledge gap (http://wellness.wikispaces.com/The+Knowledge+Gap) ; (b) make wise prophylactic, diagnostic, and treatment decisions; and (c) promote patient-centered cognitive support (http://curinghealthcare.blogspot.com/2009/06/meaningful-use-clinical-decision.html)

• Enabling networks of collaborators to: (a) perform clinical research in the field and lab through the streamlined collection, sharing, and analysis of large quantities of diverse clinical data; (b) build evolving health science knowledgebases with for clinical research, which transform this knowledge into evidence-based practice guidelines/protocols/pathways; (c) promote the continuity and coordination of care; (d) share observations, lessons learned, and best practices; and (e) effectively run PCMHs and ACOs

• Integrating sick care with well care (see http://wellness.wikispaces.com/Tactic+-+Well-Care+Sick-Care+Integration)

Also imagine that this next-generation EHR system:

• Facilitates ongoing biosurveillance and post-market drug & medical device surveillance

• Streamlines mandatory regulatory reporting.

• Connects providers/clinicians to one another in (a) loosely-coupled, occasionally connected, near-real-time, asynchronous, peer-to-peer mesh networks (e.g., DIRECT e-mail) and (b) tightly-coupled, continuously-connected, real-time networks (e.g., corporate VPNs)

• Secures PHI while it’s being exchanged (in transit) and while stored in a device (at rest), as well as protecting patient privacy

• Provides a hybrid approach to information access and exchange that includes Web-based tools, services and deidentified information stores in the cloud, along with standalone applications on users’ devices

• Provides useful business intelligence

I claim that, by working together, we can realize the vision described above by adding common off-the-shelf HIT tools and custom-built applications to EHRs. I know how this can be done!

Part 5 examines the question: When it comes to EHRs, whose satisfaction is important?

Dealing with EHR Dissatisfaction (Part 3)

This post is a continuation; Part 1 is at this link. In this post, I discuss what's needed to make EHRs more satisfactory and answer questions about my claims.

I wrote:

What’s needed is a paradigm-busting shift in which clinicians and software developers collaborate to create tools that are truly clinically useful and promote (rather than destroy) efficiency. We can start by redefining Meaningful Use – see my blog post at http://curinghealthcare.blogspot.com/2009/05/defining-meaningful-use-of-health-it_02.html

I then answered a question about my claim that over-reliance on XML and Web services is a big problem with HIT standards:

I'm not saying that XML can't work; just that XML is being over-used. When data sets are rather simple or XML is used for sending messaging operation instructions for web service, I have no problem with it. But when it comes to representing complex data, as in a CDA-based document or a complex form definition file, XML sucks!  

Here’s why: When you use XML in such cases: human readability is a joke, verbosity is huge, and parsing requirements and complexities are immense. It also forces conceptual incongruities just to keep data in hierarchies when such parent-child relationships are unnecessary. See http://curinghealthcare.blogspot.com/2009/12/dueling-data-formats.html and http://c2.com/cgi/wiki?XmlSucks.In fact, I’ve seen XML-related complexities bring the Query Health initiative to its knees (see http://curinghealthcare.blogspot.com/2012/08/disruptive-innovation-in-health-it-path_8.html).

I fought against this "let's use XML for everything" mentality since the mid-90's, but to no avail. Now the crap is hitting the fan!  

Bottom line is that there are much easier/simpler and more rational ways to represent complex data than XML, even hierarchical data. We've got to start busting maladaptive paradigms.

Regarding the web services issue, I have no problem with this architecture for the most part, but bringing SOAP and RESTful into the DIRECT Project, and relying on them exclusively in other Federal initiatives, adds similarly increased complexity, as well as vulnerability, as I discuss at http://curinghealthcare.blogspot.com/2012/07/oncs-direct-project-in-defense-of.html.

What we need is a hybrid approaches that balances web services and XML with simpler elegant methodologies.

These issues came to a head during the standards-making process at the S&I Framework Structured Data Capture (SDC) initiative where I fought for the inclusion of a much simpler approach to capturing data using electronic forms, but was voted down by the community (see http://wiki.siframework.org/Canddiate+Standards+List+Feedback). To their credit, however, they are allowing our team to pursue a pilot (on our own dime) even though it will demonstrate use of technology/methods that aren’t fully compliant with the implementation guide they are developing.

In any case, the kind of change we need isn't going to happen by EHR industry lobbyists or the Feds ... As I said before, it's got to be led by clinicians and researchers working closely with creative software developers (including nimble EHR/HIT vendors) who focus on designing and deploying clinical tools that are truly useful and useable.

In part 4 at this link, I discuss a practical vision of a next-generation EHR system that can be built today, which addresses the many criticisms of what is happening today.

Dealing with EHR Dissatisfaction (Part 2)

This post is a continuation; Part 1 is at this link.

The next issue turned to who should ultimately control a patient's data. Should it be the patient (patient access control), provider/clinician, care team/ACO/PCHM, HIE/gov't/CMS?

Here's what I wrote:

Some believe patients should have granular control of who gets to see their health data and, if de-identified and aggregated for population health research, that the patient should be compensated financially for authorizing such use of their data.

Concerns about PHI privacy and gov't control are certainly warranted and, I agree with Randall, that legacy systems have been incapable of doing what's needed to give patients peace of mind that storing their PHI in the cloud provides a high enough level of privacy protection. We cannot achieve the Triple Aim unless we have wide deployment of a secure, low-cost, always available, and simple way to exchange data from EHR to EHR, EHR to PHR, EHR to Population Health and After Market Surveillance repositories (with de-identified data), and from Person to Person (patient to clinician, clinician to patient, and clinician to clinician).

A pub/sub, loosely-coupled, mesh node network, with identity management and endpoint-to-endpoint encryption, is one way to achieve this.

The next issue raised is whether the actual goal of healthcare reform is to make it fail. I responded by saying:

I've heard from more than one person that current healthcare reform efforts were designed to fail. While I'm not sure about that, I AM confident that the cost, complexity, inefficiencies, and insecurities built into current implementation regulations are too big NOT to fail.

Nevertheless, the underlying goals of ARRA HIT--to improve care quality and contain costs/prices (i.e., increase value to the consumer)--are absolutely essential. We have a real big problem if all the spending and hassles are just a manipulation to funnel taxpayer's money into the coffers of certain big corporations under the guise of helping the common good.

As such, I believe physicians and other clinicians, researchers/informaticists, and HIT developers have a duty to participate in loosely coupled collaborative networks focused on ensuring that the HIT being developed is designed and used to improve patients' health and wellbeing, to minimize the burden and maximize the competency of providers, and to reward delivery of high value care.

I then went on to describe my experiences as a committed member of the government's HIT standards bodies:

Having been involved over the past few years in a half dozen HHS/ONC technical workgroups that determine EHR/HIT standards, my associates and I have been like David facing an arena of Goliaths. I've been dealing with the biggest EHR vendors, as well as Federal contractors and agencies. It's been a very frustrating and enlightening experience. We entered the arena with the faint hope that the powers-that-be would compare our simple, low-cost, highly capable, disruptive innovations to the complex, convoluted, expensive mainstream technologies currently being adopted.  

What we’ve found is that the standards-making process is rife with regulatory capture in which new standards are built on top of old standards without due consideration of modifying those standards in light of new and better technologies. Simplicity, efficiency, and usability are an afterthought. The result is an extraordinarily complex set of monolithic processes that few (if any) can implement and few are willing to use.  

Examples include, in no particular order: (a) an over-reliance on XML data representations and Web services, (b) long delays due to HL7 voting processes, (c) changes to DIRECT taking it from what was supposed to be one step above the fax to a convoluted amalgam of HISPs that make PHI vulnerable with exposure to man-in-the-middle attacks, (d) incestuous relationships between vendors and ONC that block innovation from “outsiders,” (e) reticence to deal with difficult clinical workflow issues, and (e) the natural tension between making huge leaps in EHR system capabilities and the “let’s just keep crawling until we can walk” mentality. The result is that money continues to be spent with dismal progress in enabling HIT to increase value to the consumer while enabling and rewarding providers for delivering such value.

It seems to me that most of these problems are due to business strategies and tactics supported by regulatory capture; it is not a technology issue, per se.

In part 3, at this link, I elaborate about the problems identified above.

Dealing with EHR Dissatisfaction (Part 1)

For the past few days, I’ve been involved in a very good conversation at LinkedIn HIMSS titled: Can we turn EHR dissatisfaction around?

Here’s a comment from person that struck a chord:

It took the doctor 2 minutes to dictate as opposed to 30 minutes to use speech, edit and/or type. In addition, if the text is not edited in most cases except for those of you have it down perfect, you get crappy documentation that is (oh my goodness) actually used down the road to treat a patient. I can also introduce you to several law suits filed due to the poor documentation of a physician who refused to edit his dragon speech and just let it go into the chart. I can also introduce you to a neurologist who spends 4 ADDITIONAL HOURS a day documenting in an EHR. He has been at it for over a year so apparently this brain surgeon is an idiot who can't be trained. All of your responses to this, even the "this is off topic" are very revealing as to one source of the problem. Like typical programmers, no one wants to hear they have a bad design or the product actually needs more work.

So, to stay on topic, "Can we turn it around?" yes but only when you listen to the experts in the field you are dealing with - medical record specialists and physicians - they seem to be the people you have left out of the equation.

I'm a clinician (clinical psychologist) and HIT software inventor/architect/developer with 33 years’ experience in both areas. What I've noticed is that programmers routinely rely on healthcare subject matter experts regarding product content, the same is often not true regarding workflow adaptation, usability and usefulness issues.

It's relatively easy to create databases and forms for data entry and presentation, but it's quit difficult to construct the inputs and outputs in ways that streamline workflows, integrate and organize complex interdisciplinary data in clinically meaningful manner, generate clinically useful information that supports decisions at point of care, and present that information in ways that promote knowledge and understanding that lead to greater value for the consumer/patient.

Herein lies the problem, imo, and it is where disruptive innovation is sorely needed!

Unfortunately, such creative destruction is often hindered by governmental regulatory capture in which big bucks direct the regulators who dictate the rules that constrain innovation, focus on appeasing big business, and drive up complexity and cost.

A short while later, Randall Oates, MD posted a comment that ended with:

It is time for more enlightened physicians to step up and assist/collaborate the transitions to processes generating EHR notes that are more clinically useful, while meeting basic billing/legal/reporting needs of others as well. Otherwise, physicians have to mainly blame themselves for systems that don't meet their needs.

To that I replied:

Randal, I'd to add to your excellent statement: "...and present, in a concise integrated view, the relevant interdisciplinary information needed to support their clinical decisions, at point of care, that is focused on continually improving outcomes and care value.

For past year and a half, I've been volunteering my time in a Federal workgroup (WG) called the 360X initiative and work alongside Cerner, Epic, and several other large EHR vendors and HIEs on implementing closed-loop referrals. In the WG, I'm a "little guy" offering novel ideas and methods to the "big guys."

I sincerely believe that the clinical and technical folks in the workgroup do want to improve their products, despite the fact that I have had to repeatedly insist that instead of focusing on doing the minimum; we focus on dealing with the big, complex issues, especially regarding workflows.

I'm also involved in several other Fed workgroups that create HIT meaningful use standards. What I've noticed is a general tendency to keep things complicated, while at the same time, minimizing the scope of their efforts. Many times, when I’ve tried “push the capabilities bar” higher--and even offered innovative ways to do it)--I’ve heard the phrase: “We should first crawl and then walk before we try to run.” Unfortunately, after all these years, when it comes to enhancing EHR systems' clinical usefulness and security, there's too much crawling under the "low bar," and a general aversion to trying to "leap over the high bar."

I believe there are many reasons for this and they mostly relate to the “business layer” supported through regulatory capture by HHS/ONC.

After three decades of HIT involvement, I’ve come to the conclusion that what we need is to transform EHR products into “EHR systems” (a term I helped add to the Fed’s lexicon and workgroup charters). These EHR systems would be enhanced through integration with low cost, easy-to-use “companion applications” that fill in gaps in EHR usability, usefulness, interoperability, and protection of PHI.

The companion apps are likely to be disruptive innovations created by loosely-coupled collaborative networks of small nimble companies and individuals with diverse backgrounds and experiences, who share, discuss, evaluate, and continually evolve models (types of apps) focused on different use cases and types of end-users.

 [Continued in Part 2 at this link]

Should "Value" Be the New Mantra in Health Care?

On  the Commonwealth Fund blog at this link is a new post titled: "Should "Value" Be the New Mantra in Health Care?"

 

This is good to see! I began blogging about the need to focus on Value to the Consumer back in 2007, starting with a post at http://curinghealthcare.blogspot.com/2007/10/path-to-profound-healthcare.html.

 Value is a complex issue that brings into light the notion of cost-effectiveness and how to compensate providers who demonstrate a commitment to high-value care via Pay for Value (P4V) models.

 I contend that a firm focus on value is the ONLY way to solve the daunting problems plaguing healthcare delivery. If we don't, costs will continue to rise without corresponding quality improvements, and cost reductions will likely result in worse care outcomes.