In recent articles I have drawn a distinction between an electronic medical record and run-of-the-mill computer applications. Typical computer applications begin when someone gets a notion to make a computer do something in particular such as create documents (Word), manipulate photos (Photoshop), manage finances (Quicken), or solve equations (Mathematica). The details of the "something" become a list of "functional requirements."

 The EHR Certification Criteria are an example of such a list, albeit a poor one. Armed with the requirements, developers define data elements that they believe will be needed. Their initial guesses are often wrong and, after development has begun, it may be necessary to devise an alternate approach (a workaround) or some requirements may be abandoned. The true nature of what is released will only be discovered as the users begin to interact with it. Typically, by the time large numbers of users get to try the application, the die has already been cast and major changes are precluded.

Clinical medicine is not at all like this. You can't write the functional requirements for the next encounter in advance. No one can predict what novel situation the next patient will bring or what information the physician will choose to document. Physicians do have some "functional requirements" related to specific procedures they perform but every physician's set is different and changes with time, experience, and medical science. Being unique and dynamic, few EHRs address a physician's personal requirements. Instead, most EHRs provide pre-built content for the major specialties that is of limited utility until customized for a particular site. Years are often required to get the major specialties up and running after which the institution is free to turn its attention to their niche activities such as pre-op notes, OT, PT, chaplain services, and the like. While those engaged in niche activities users wait their turn, they will be typing or dictating just like in the old days.

People change quickly; systems change slowly if at all. As time passes, the expectations for what an EHR ought to do will diverge from what a particular product was built to deliver. Eventually, the users will reach a point where they desire, and need, a different system. This point may be precipitated by changing needs and expectations or perhaps by the vendor going out of business or abandoning their former flagship product in favor of a new one.

This is the moment of truth. Is there an exit strategy? Was the need for one ever considered? What will happen to the precious data in the Operational Data Store (ODS) that relates to the healthcare process that are not yet completed? What will happen to your patient's lifetime (hopefully) medical records? Will your workflow continue unimpeded during the transition to a different product? Will all your charts remains readily accessible and at least as readable as before? How much customization that you did to meet the needs of those niche activities will need to be redone? How long will those folks have to wait while primary care is dealt with again?

It is my contention that archiving and accessing the medical record should be accomplished using an external system, the life cycle of which is not tied, lockstep, to that of the EHR application vendor. Doing so addresses the two hardest problems: providing a lifetime record and providing a neutral platform that can accept chart content from whatever system(s) were used to create it. It won't directly address all issues but it opens up avenues that would otherwise not be available, such as providing small, specialized departments with specialized applications from separate vendors that can submit content to the archive.

To summarize:

• The information in the medical record is different from the "data" expected by most computer programs.

• The import of medical record information gets bent, spindled, and otherwise mutilated when programs treat it as if it is nothing but a collection of data elements.

• The chart must last longer than transactional data.

• There are requirements placed on the stewards of the chart that are different from, and go far beyond, those placed on ordinary transaction-oriented systems.

• The typical EHR contains only a portion of the chart. Images, photos, videos, and other biophysical signals are typically stored in the systems that collected them, leading to a fragmented record.

The basic requirements that apply to storing and protecting medical records haven't changed simply because a computer is used in place of a physical file room. It is a good idea to maintain a separation of responsibility between the systems that archive the medical record and the ones that process day-to-day computations and transactions, as has been done in times gone by.