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.

In my last two blogs I’ve presented my ideas about implementing an EMR with three groupings of clinicians in mind. First we covered the “Excited” but impatient, then the “Willing” but concerned and skeptical.  Now let’s focus on the “Frightened” and again ask:

·       who they are?

·       what is their attitude to computers?

·       what does their motivation look like?

These clinicians are definitely mature. They have no kids at home and are less likely to have embraced new technology. They’ve had long professional careers and been at their organization for years. They are settled into established roles and methods in their work.  They may be eying their pensions and counting the years to retirement.  They are the elders of the community whose wisdom and experience bring such value to a clinical team.  They are computer naïve, intimidated.

When faced with the move from paper to computer, their initial response will probably be resistance, as they share the Willing group’s concerns about computerization diminishing the work and disrupting functional routines.  They may also present as grumpy.  Beneath these reactions, they are mostly worried they will look dumb and feel embarrassed as they learn. Some will fear they will never be able to master the machine.

These organization elders must be approached with great respect and sensitivity.  They must be extravagantly supported.  One-to-one on site tutoring is a frequent plan.  Training in a peer group setting by a peer rather than a whippersnapper preserves dignity and creates support. Use your ingenuity to help these clinicians become less anxious about giving the EMR a try.  My favorite success vignette is of a psychiatric elder who in the beginning protested mightily about computerization. After personalized training, he was so delighted and energized by his mastery of the software that he evolved into an enthusiastic local champion.  So rewarding for both of us.

Please share any tips and happy outcome stories you may have. 

I’ve been writing about “the clinician” as if this word represents a homogenous group of people. Of course, this generalization is not correct, especially when it comes to individuals facing the move from a paper chart to an electronic medical record.  So I like to divide my one big generalization into three smaller ones.  I find it useful to think of three groups of people and ask:

·       who they are?

·       what is their attitude to computers?

·       what does their motivation look like?

This blog will focus on the third I call “the Excited.”  These clinicians are younger, computer-philes from our modern computer culture.  They are the kids of the organization. (Is my age showing?)  They are newer to their work and not greatly invested in established roles and methods.  They are also newer to the organization, and less identified with the organization’s history and culture.

When facing an EMR implementation, the excited group will probably be – well - excited.  A wise implementer will draw their enthusiasm and knowledge into the implementation effort.  Make sure they are represented in planning groups and tapped to be local champions. I enjoyed a mentoring relationship with two of our up-and-coming clinicians who became great boosters of the EMR in their clinical units.

But, no surprise, with the energy and computer skills comes impatience. These computer-philes are used to interacting with action packed graphics, to intuitively following their bliss through hyperlinks and to expressing themselves extensively on MySpace.  The content of the EHR is structured and controlled through required fields and software procedures.  They need help to be patient with the restrictions of the software.  They need help to see that the content designers are not dolts and to accept that there are legitimate clinical and compliance reasons behind design decisions.

It is the implementer’s job to ensure that these two last statements are correct.

At a workshop a couple of years ago, a behavioral health executive contemplating an EHR implementation asked me, “How can I get my clinicians excited about this implementation?” My short answers are “Be realistic” and “It depends.”

Clinicians have different needs for information and a different relationship to an EHR than executives. Managers need information to lead the organization. I would also add that they do very little of the direct data input, so they get the benefit of the reports without much personal effort.  Not so for the clinicians who, along with support staff, are the main sources of the content being entered into the EHR. So what might get a busy clinician excited about an EMR implementation? Let’s think about this question from the point of view of salaried clinicians in a behavioral health organization.

Such clinicians are not much interested in organization finances, compliance and other executive concerns.  They too want information, but of a very different sort. They want an efficient method to capture relevant client history.  They would appreciate tools that could help them define the treatment and track progress. They need to communicate with themselves and with other staff treating the client both currently and in the future. Approaching these needs will be experienced as helping them do their core job, providing the best care they can for their patients. So far, so good.  Clinicians further need to capture data and document their work to satisfy all the various data masters of the universe, eg payers and accrediting entities. This is experienced as extraneous to their core job. (They feel grumpy about doing it and will feel grumpy about the EHR that ensures they do it.)  And, of course, they want EHR content to be easy to access and navigate.

If you are an implementer, don’t set yourself up for disappointment by expecting clinicians to be excited about the EHR implementation itself. Moving from paper to computer involves lots of changes for clinicians. A well-executed implementation is critical in getting the EHR off on the right foot. Do understand, though, that the long-term success of the EHR you are implementing depends on how well the system you deploy serves the work the clinicians are doing.  It depends on their having ready access to a computer, on the functionality of the software you have chosen, the design of the content, the usefulness of the outputs, the adequacy of the supports.  None of this is magic. Digging down into the details and finding good solutions at the level of the clinicians at their jobs is the work of the implementation.

I’ll write about my experiences and thoughts on these challenges in future blogs.

During this electrifying political season, there is a flurry of attention being given to Electronic Health Records. Nationwide implementation of  EHR’s is a core component of candidate plans to reform the American health care system. The main reasons put forth include to save money, reduce medical errors, avoid redundant testing, identify previously ineffective treatment,  and provide access to current medications from any point of care.   The media is high profiling phrases such as “interoperability,” “RHIO’s” and “Personal Health Record (PHR).”

Adding to the intensity of the EHR discussion, the federal government is proposing penalties for EMR non-adopters. Our largest technology companies, namely Microsoft and Google, are charging into competition to capture the hot property of the PHR.

Some of the enabling technology for these high level goals is in place. Some crucial components are not. What are the providers of healthcare to do? More particularly, how can those contemplating software for behavioral health, addictions, MRDD and public health approach the question of why should they embark on such an undertaking? Here is my thought. To borrow a saying:

Plan globally and for the future………Act locally and for the present

An organization’s top planners must be aware of the national vision and policy trends concerning EHRs. They must be informed about technology trends. Only then can they define their own plans and make decisions. For example, they should not cast their lot with a vendor which cannot demonstrate its ability to lead or at least keep up with technical developments over the long haul.

I  began my career in the 70's as a community psychiatrist. I was part of a team out in the field working to engage people with Serious and Persistent Mental Illness. The work was challenging and creative. It demanded a wide scope of thought and action. I loved it. In the late 90's in what seemed a sudden shift, I found myself confined to an office and the managed care driven 20-30 minute med check. I wrote the prescriptions, while others were gifted with out-reach and the therapeutic relationship. I felt cut-off, suffocated. As a community psychiatrist I was a dinosaur, an unhappy one.

Then our CEO suggested that I take on the leadership role in the implementation of the newly purchased electronic medical record (EMR). My response: a startled "Me?!" "Yes, you," he said. "Think about it." As a clinician I focused on the human rather than the technical dimension. Why would I join the dark side of the business managers and number crunchers? I was a novice computer user, how could I lead a computer software implementation? The "Why?" answer is short and simple. I'll tell it now. The "How" answer has many, detailed parts and has to wait for later blogs.

So OK, why? I knew enough of trends in the larger world to be totally convinced that computers in clinical care were inevitable. It followed immediately from this realization, that the urgent call was to make the computer serve the work. Another question emerged: "Who better than a senior clinician to try to make this happen?" I pondered this new question. I acknowledged the importance of the goal. Then before my mind’s eye, the question flipped to "Why not me?" I saw the timeliness of the opportunity. The challenge energized me. Yes, indeed, why not me. It became clear that I must try. I accepted the job. My personal buy-in was complete.