On November 12^th, Senator max Baucus gave us some insight into where healthcare reform in this country will be headed under the new leadership.  He published a white paper, Call to Action Health Reform 2009. 

In this document he laid out a plan that had three main goals:  1)  Ensuring health coverage for all Americans; 2)  Improving health care quality and value; and 3)  Achieving greater efficiency and sustainable financing.  In the white paper he discusses that we may have reached a tipping point where the main stakeholders in the process – consumers, businesses, labor, providers, plans, manufacturers and state and local governments – cannot afford the cost increases and cost shifting any longer and are willing to engage in serious reform efforts. 

To achieve these goals he wants to set up insurance exchanges that allow all citizens to purchase insurance.  He would allow older citizens to “buy into” Medicare and lower eligibility to those seeking access to Medicaid.  This would increase the consumer volume for many of our clients. 

Key to his whole approach is an increased focus on quality of care delivered versus volume of care delivered.  I see payments in the near future tied to improving outcomes, or as it is known, pay for performance.  To achieve these measures he will increase incentives and investments in healthcare IT (something which President-elect Obama campaigned on).   In his press conference he discussed immediately allowing providers to be incentivized to implement electronic medical records by giving them the same 2% incentive that is now available to Medicare providers for using e-prescribing (see my blog e-prescribing incentives).

Obviously this is in the early stages of development, but I think the train has left the station.

The eHealth Initiative recently released its Fifth Annual Survey of Health Information Exchanges at the State and Local levels.   In this survey we are starting to see the clinical benefit of interoperable clinical systems.    More than 130 HIE initiatives are in progress with 42 of them reporting to be operational. 

The biggest reported reasons for implementing an HIE are improving quality (97%) and patient safety (90%) with the biggest challenge being developing a sustainable business model. 

The big news in this survey is the positive clinical and financial benefits being reported by the users of the system.  69% of the fully operational exchanges reported a reduction in health care costs.  The savings were attributable to reduced staff time, reduced redundant tests and decreased cost of care for chronic patients.  More than half of the exchanges reported positive impact on the delivery of health care.   Major benefits were increased access to lab results, improved compliance with chronic care and prevention guidelines, reduced prescribing errors and more rapid identification of disease outbreaks – something critical to our public health clients. 

The bottom line was that 69% of the operational exchanges reported a positive ROI.  This is the first survey in which a majority of the participants reported a positive ROI.

When designing the content of your electronic health record, you have lots to think about. I've just written about data format decisions with some examples.  Databases also permit you to place rule-based controls around Clinician use of options and fields in the EMR. These tools protect data integrity by preventing unauthorized input and protecting content from modification. They help ensure that Clinicians are capturing the same sorts of information and that you are getting the information your organization must have. An effective controls strategy enforces desired content while minimizing the inclusion of inappropriate and unnecessary data. The type and extent of controls also implement your organization's goals and policies.

In other words, they are a very useful set of functions in your design toolkit. Now, what do I mean by Controls?  Here is a list of some with examples:

·    Define access to options and fields as for input or "read only"– Denying input access to finalized forms protects the integrity of the content and of accountability. Denying access to (disabling) a time field that auto-fills with the current time prevents fudging the time vital signs were recorded.

·    Make fields required or optional for filing. Required fields ensure completeness and consistency. Optional fields invite the addition of relevant information in consistent formats.

·   Use event logic e.g., "If this response is selected, then this will happen." If the required item “Pain Present Y/N” is clicked “No,” then the initially disabled fields for Intensity and Location remain disabled, preventing extraneous data. If  “Yes” is selected, then the Intensity and Location fields become enabled and required, ensuring compliance with organizational policies about assessing pain in all patients.

Hopefully I am giving you the idea. This document shows more examples of Controls with Avatar screen shots.

So often when I am giving demonstrations of our e-prescribing software, I am asked questions like “can it do this,” “can it do that?” Many times the question goes something like this, “If my patient is a 29 year old female with brown hair and long fingernails and I am considering prescribing a medication that will turn her hair purple, will it tell me that the patient doesn’t like purple hair because she can’t find purple nail polish?” My response: “Um…er…hmmm…well…no. It won’t do that.” Then I go on to ask “How do you know that now, that your client doesn’t like purple hair?” They respond, “Well, I have to ask her.”

Okay, so I’m being a bit outrageous, but I hope you see my point. Technology is wonderful and it can do many, many things. However, there is a point where clinicians need to be clinicians and use their training and skills. It takes many years of education and training to become a physician or other type of prescriber. If technology could do everything, including think and made clinical judgments on behalf of the physician, I suspect more people would become physicians.

Society has always had and continues to have great respect for physicians for their expertise in keeping us well. I doubt we’ll ever have (or want to have) that much respect for a computer application.

The content of an EMR captures data to serve many masters. These include payors, regulators, accrediting entities, researchers and the organization’s managers. Most of all, however, it must serve the work between client and clinician. In my previous blog, I wrote about the need to recruit a workgroup of clinicians with a broad array of clinical skills and homes. Then what? Well, the next step is to educate them about the technical underpinnings of the project, namely about databases.

In my experience the early leadership in software implementations comes from IT professionals. So, since you are reading this blog about electronic medical record implementation, I assume that you are probably pretty computer savvy and technically informed.  But let me plead with you to assume that the clinicians on the design workgroup are neither. Sure they email, write documents, Google and shop online, but most likely they do not understand what a database is. Since clinical documents are one of the main EMR outputs, they think that the EMR is some sort of giant MS Word document.  Thus they make comments such as “Why can’t you spell-check the whole thing at once?” and they expect to read the clinical information that has been entered by accessing the inputs screens rather than by viewing a report.

When considering data capture and, especially, information flow it is essential for the designers to grasp the database basics: that information is captured in various data types in input screens and stored in columns and rows in tables and that reports pull the information from any available table.  

I have shown many clinicians this simple database schematic. The frequent responses have been as if it were a revelation. They told me that now they “got it;” that they felt enlightened and empowered; and that they were eager to get going on the design task. And all it took was about half an hour. 

As I wrote last time, when you are designing the content of an EMR you have to consider the dimensions of clinical culture, information flow, specific data capture and the use of controls. Good design also means finding solutions to meet the often competing needs of clinicians, management and, yes, the software.  It’s a complex process. I don’t claim to have all the answers, but over the past eight years as EMR implementation manager and then consultant for Netsmart Technologies, I have struggled extensively with the issues. 

First and most importantly, as the project manager for the implementation at UBHC, I did not struggle alone. We cast a wide net to recruit a workgroup of 30 members. The members were supervisors and line clinicians from all disciplines and levels of care as well as the leaders of all stakeholder departments. Here is a list of the participants if you want more details. Our charge was to design the structure and content of our electronic health record. We met for half a day a week for three months. The learning curve was steep. (more on workgroup education next time) The process was intense. The turf issues and, shall I call it, specialty narcissism were very much present. Together they created the major threat of “Content Creep.” This is a situation in which Staff want the details of their specific domains included and in their customary formats. The back-and-forth process eventually made it clear that to accommodate this range of domains would result in content that was too lengthy and complex. The phrase: “That item means 100,000 clicks per year…Is it worth it?” became a regular refrain.

By the time we were done, the participants had had the opportunity to understand the needs and concerns of wide range of functional areas and all LOC.  They were then able to make recommendations based on detailed knowledge of the information needs in balance with the realities of staff time and the software. The focused group process was powerful in setting the stage for the necessary compromises. Patience and determination were essential to discovering the solutions.

 So get your clinical leaders and line clinician “best minds” together and jump in. You don’t have to wait until vendor selection is complete. You can begin the content analysis and struggle now. They are generic.

So far I’ve written mostly about reasons and motivations for implementing an EMR. I’m feeling restless to get going with doing it, so I’m going to skip ahead to thinking about the design of your EMR.  I picked design because of the challenging article by Drs. Pamela Hartzband and Jerome Groopman I wrote about in my last blog.  In the article they described the risks of clinicians going brain dead (my word) while filling in standardized forms and templates.  They ardently support what they call “Thinking” medicine and called for the EMR to work for the clinician and not the other way around.  So do I. It is the main reason I decided to morph from practicing psychiatrist to EMR implementer.

The challenge for the content designers is that they themselves not go brain dead. This would look like them just assembling items and pick-lists based on requirements of payors, accrediting entities, states, their own management and so forth. Of course, these various data-masters must be satisfied.  But the designers must also think deeply about how to use the technology to help the clinician capture the essential story behind the patient’s presenting problem(s) and then abstract a formulation that leads to a plan.

There are several dimensions to consider in the design process, including clinical culture, information flow, specific data capture and the use of controls. There are irreducible tensions among the needs of clinicians, management and, yes, the software.  The trick is to find a sensible balance with support of the clinical work as the highest value. I’ll write more about finding the way in upcoming blogs.

Design is as complex as it sounds, but do not be intimidated. The very good news is that software development is never completed. It evolves as you learn from experience and user feedback and as new functionalities become available. Also it is great FUN to be a creator of software and not just a consumer.

An effective electronic health record implementation requires oodles of collaboration among every slice and silo of the organization. Ideally such collaboration would be a given. But all staff members are human beings who tend to develop identities and loyalties based in shared relationships and experiences. In other words, locally. Enter turf as a perennial resistance to the change that comes with the move to an EHR.

At the time of our EMR implementation, my home organization had been in operation for more than 25 years. Many of the staff had been there for > 10 years. Place and people already had a long history together.

Factional divisions were plentiful; blaming the other was usual.  Many staff groups believed that their function was the crucial operation and that other functions existed to service their operation's needs.  There were adversarial relationships between programs.  For example, Inpatient staff thought a hospitalization was central to the treatment and that they could more properly diagnose and treat a patient based on their 24/7 observation. Outpatient staff, meanwhile, believed a hospitalization was a disruption in care and that they better understood the patient because of long-term contact in the natural setting.  Then there were fiscal staff who thought clinicians were too lazy to do correct documentation for billing, while clinical staff saw fiscal staff as lacking compassion. … and on and on. I’m sure there are 100’s of choice examples out there.

So what to do?  My condensed answer is to get them in a room together, give them a task and a strict timeline and tell them they must be successful.  Details to follow.

A recent article in the New England Journal of Medicine surveyed 3000 outpatient medical practices on their use of an electronic health record.  Among the many results was the finding that nearly 400 of the practices had already purchased an EHR system, but had not yet implemented it. There are many possible explanations for this. I want to use the finding to segue to talk about motivation and the implementation leadership. (The leadership may be one or several people.  Both configurations can work, and these thoughts pertain to both situations.)

There are many, many elements necessary for a successful EHR implementation (or I wouldn’t have material for an ongoing blog), but the implementers’ determination and energy are the primary forces driving an implementation through to its completion.

The organization’s implementers have to face the resistance of staff, the scope of the task and the personal effort level involved. They will probably develop feelings, such as anxiety, anger, frustration and their own resistance, which may look like procrastination, over planning, even letting themselves be persuaded that an EMR just cannot work in their setting.

The implementation leaders need to discern a personally important mission in the EHR project to support the deep and steadfast commitment that is necessary. As I wrote here in an early blog, for me the mission was to make the electronic health record serve the clinical work. The passion for this mission still energizes me.  

I’d like to hear other people’s thoughts, feelings and ideas about the mission for EMR implementers.