Monthly Archives: June 2009

Tailored vs. best practices EMRs

A number of recent articles about electronic medical records (EMRs) have argued that any new system should be tailored to the procedures in a hospital or the office of a doctor. The alternative is to build the system based on best practices and retrain the doctor and staff.

Looking at an EMR system for a single location will almost always lead to a tailored solution because it can be installed quicker and the cost and pain of installation appear to be lower. However, when an EMR system is looked at as part of a larger network—CCHIT: White Paper on interoperability—the pendulum swings to a best practice solution.

A useful analogy comes from early experience with word processing systems. Initially, each PC manufacturer provided a custom version of its own word processor. That worked as long as a PC was little more than an electronic typewriter that produced paper documents to be distributed. Documents prepared and printed in different offices where similar enough that the reader could ignore the variances. As offices began to share the electronic forms of documents between computers and with other offices (usually in the form of a floppy disk) tailored systems no longer worked. The word processing software became separate from the hardware and independent software firms like Microsoft, WordPerfect, and a few others became the standards, often within a particular industry. Microsoft Word eventually won, but now software from other companies like Google is showing up in response to changes in computer and network technology.

A unique EMR in a doctor’s office can function very well until the office sends or receives information from EMRs in the offices of other practitioners, laboratories, payers, public health, etc. Sooner or later the doctor’s system will have to be able to interface to other systems if it is to receive and provide the information needed by the doctor and her patients.

The selection and implementation of a best parctices EMR will require careful review of several systems to find the one that provides the features and functions required by a specific practice. Then options will have to be selected to tailor the system to that practice’s specific style.

The pros and cons of Tailored vs. Best Practices systems are listed in the following matrix. (Note: row numbers are provided for reference only; no ranking is intended except for the first row.)


Tailored Solution

Best Practice Solution


Familiar, easier to implement which initially means lower cost and pain New, requires retraining and breaking old habits, takes longer and costs more


Built on a single practice, may or may not be best way or even a particularly good way Takes advantage of experience of multiple practices to find best way or ways


Uses experience with manual methods as a basis for an automated system, rather like using a bicycle as a model for a motorcycle Based on a combination of manual and automated experience from multiple sources


Current practices have to be documented before they can provide the basis for a new s6ystem, requires time and cost Best practices have been defined and incorporated in new versions


Each practice’s manual processes are imbedded in its systems All locations using the same vendor/version have essentially the same processes, e.g., Microsoft Word is essentially the same in all offices


A doctor who has a private and hospital(s) practice must learn a different system for each location A doctor who has a private and hospital(s practice can move from one to the other in terms of using the system and the way information will be presented


All training for the system will have to be tailored to the specific system Standardized training material and classes can be used to train new employees and update current users


Sysem training and best practice training such of some continuing education may conflict System changes can be implemented to coincide with training in new and improved best practices as part of continuing education


Networked users will have to become familiar with any unique features or functions of a doctor’s office increasing the risk of error and reducing the ease of use Network users will find a standardized system easer to use which will in turn minimize the risk of errors.


Each new member of the practice will have to be trained; this training will not improve their resume for future employment Newly hired experienced users of standardized systems will get up to speed faster thus providing greater value to the office and will see improvements in their skills as career builders


The substance and format of a question can shape the respondent’s answers. Differences in the questions or prompts on different systems can impact the answers in unforeseen ways. Standardized questions in terms of both content and format reduce the variability of the answers of different respondents. Better initial answers increase the value of the subsequent use of the data.


Changes in regulations or common practice require changes in each individual system; usually requires technical assistance Changes in regulations or common practice can be made automatically for all comparable systems via automatic download – similar to version changes for common office software such as Word


Each new computer application must be developed for a specific system A new computer application can be developed for multiple systems and costs are shared over many system rather than just one.

Posted for comment on Linkedin at: HealthCare Information Technology and at: Health Informatics Technology (HIT) View comments on these sites.

The problem is in the data

Legacy computer systems were almost always funded by one department and developed to meet that department’s needs. There was little incentive to make them compatible with earlier systems except to provide necessary means to exchange results of computations.

EMR systems are now attempting to bring together information based on the treatment of a single patient from systems that were designed to manage a single clinical or business process. Two choices: standardize the data or develop a system solution. Standardizing the data just from this point forward would be huge and expensive project and would of course make all of the historic data essentially worthless. Microsoft’s Amalga system has been receiving a great deal of press coverage as a system solution to deal with disparate data formats and types. The system was developed in 1996 at Washington Hospital Center and was acquired by Microsoft in 2006.

Amalga’s Web site focuses on the stand-along organization:

Microsoft Amalga HIS EMR consolidates data from across the organization to tell the complete story of a patient’s history, condition, and progress.

Complete story within the organization, but hardly the “complete sorry of a patient’s history.”

On the other hand, another Amalga Web site says: information in the patient’s EMR can be sent “to the patient’s personal HealthVault record” where the patient can share it with other health care professionals.

Maybe we are not to far away from a system solution to the data problem. Microsoft has a well publicized solution. There are probably other solutions that are not well publicized but can also assist in dealing with the problems in the data. Microsoft has often been a dominant player but has seldom been totally free from competition.

While on the topic of Amalga there is one other part to the story. The uses and users of EMRs have become diverse enough that it is almost impossible to fully define what is wanted and needed – even if we could, it would change. By analogy, who would have expected that the iPhone would have led to more than 50,000 applications? How many unforeseen applications will there be for ERMs?

One example of an unforeseen need is a response to swine flu and the need to track cases and exposure in the emergency department of El Camino Hospital:

Within a matter of hours, clinicians at El Camino modified a few fields within Amalga to capture information specific to possible flu cases coming through the hospital’s busy emergency room. The result is a real-time dashboard that is keeping hospital officials appraised of possible swine flu cases at El Camino and will help them respond appropriately should one or more cases be confirmed. Clinicians are praising Amalga for the solution’s flexibility and the way it can be adapted to meet specific organizational needs as they arise.

Microsoft has announced plans to provide guidance to other Amalga customers so they too can immediately begin using the solution to monitor flu activity. This could prove especially valuable where Amalga has been deployed to gather community-wide clinical data. One example of that is the Wisconsin Health Information Exchange where more than a dozen emergency rooms in the state are now able to share real-time clinical data thanks to Microsoft Amalga.

In one product there is a possible solution to part of the problems with the data and an excellent example of the need to build flexibility into EMR systems.

In praise of nay-sayers

One of the first things that happens in the early stage of almost any complex undertaking is a parade of nay-sayers: the people who have all of the reasons it can’t be done. If they don’t show up it is a sign that the goals of the undertaking have not been set high enough.

Yesterday (June 16) the HIT Policy Committee published its ‘First Draft’ of Meaningful Use. (See links on the sidebar)  There are the usual cries of “It can’t be done” which suggest the goals are set high enough to require more than business as usual. That’s good news.

The task of those committed to completing the definition of meaningful use is to sort out the cries that point to real problems that need to be addressed from those that are simply complaints.  There are huge benefits in terms of time and cost to implement if problems are found and solved during early discussions rather than later during implemented.

Sometimes the solution is to clarify the goal, sometimes to change it, and sometimes to use widespread discussion to find a way to do what appeares to be impossible.  The importance of widespread discussion is particularly important where the subject is as complex as electronic medical records with little understanding of the needs of some of the users. (See Expanding Scope – Increasing Complexity )

Are the goals set too high? I hope so because that’s the stimulus for discussions and potential breakthroughs in quality of care and cost reduction. Will they change? Almost certainly, but there is a great deal of work ahead to determine what changes need to be made. We have been here before with Y2K and HIPAA and succeeded.

One way to sort the contributions from complaints is to look for the positive along with what sounds negative. Just negative? Probably just a complaint. Positive and what appears to be negative? Probably all or mostly contribution. A very good example of contribution is a post by Chilmark Research that both complements and critiques the draft.

Here’s to the nay-sayers and to those who use their cries of “It can’t be done!” to good advantage to discover and solve problems early.

Expanding scope – increasing complexity

The development of electronic medical records began in the facilities of providers – that’s where the medical information was housed. Much of the discussion of EMRs continues to focus on the needs of providers; that’s appropriate given the state of the technology. At the same time, the scope of use for EMRs is expanding as illustrated in the figure below.

Early implementations were largely restricted to prearranged exchanges among a limited number of members of a local medical community. EMRs and the Internet are both evolving rapidly and the Internet now provides the technology to move information in any form to anywhere at any time. HIPAA standardized the coding and transmission of medical billing information. Various agencies and bodies have evolved or are evolving standards for coding and transmitting the contents of electronic medical records. The technical problems associated with the creation and movement of EMR information are significant, but solvable.

Now there are additional sources of complexity as the needs of users change, “ownership” of data becomes less clear, the number of potential security leaks increases, etc. Those will be addressed in future posts. The important point here is that the conversations about EMR scope and issues needs to expand to reflect the growing number of stakeholders, and the ways the records and their data will be used.

Our focus:

EMR-net explores the premise that the most significant value of electronic medical records will be in the network that allows the records to be shared among all or most of a patient’s medical care providers. The people and systems that capture the data and the systems that process it are important but the significant value will be in the sharing of at data between providers, services, and patients.

The flip side of value is cost. The most significant costs are the investment the provider must make to acquire the system and get data loaded, and the cost of complexity. Early in the development of EMR systems they were by and large stand-alone with interfaces that were essentially extensions of fax transmissions. Data formats and protocols were of limited importance. As the number of interfaces and the amount of traffic increases compatibility among systems becomes increasingly important. Additional sources of data and uses also raises issues of data quality.

The systems to capture the data in an electronic format had to be in place before the network could develop: without the data there could be no network. We are now well beyond proving that the data can be captured although there are still debates about the best ways to do that. The Internet is providing the network structure and the network processes are evolving.

As the network becomes more robust it creates more value and complexity. That value from the network is part of the benefit of an EMR system for each medical facility that choses to make the investment and join the network. The complexity is part of the cost of creating a massive network with minimal impact on what has alread been invested and maximum flexibility for future development.

We reserve the right to express an opinion on almost any EMR topic, but our focus is on the value and complexity of the network