Rev: 08 Sep 2002.

Introduction

This page discusses the issues involved in migrating from one electronic medical record (EMR) to another. The same issues apply to a lesser extent to any clinical automation system with persistent data.

The motivation for creating this resource is to educate the customer and vendor community about this issue, which I believe is of much greater interest than most persons initially assume. The Question, initially posed on the Fam-Med list, outlines the topic. It is followed by a tabular listing of potential solutions and a Q & A section incorporating comments and feedback from the Fam-Med and AAFP/EMR lists. The Left Behind and The UK Experience sections expand on this and an important related topic -- the medicolegal issues with the legacy data.

For the Fam-Med discussions on this topic see http://lists.fpen.org/guest/archives/FAM-MED/log-2001.05/ and subsequent archives. The OIO Library Entry and Linux Medical News host metadata and discussions on this document.

The Question

The original question was posted on the Fam-Med list on May 25, 2001. I added a later follow-up to some initial responses. The following is an edited version of the initial question ...

For some years I have been pondering a question that I've rarely seen discussed^[8]. I would like to raise it here, and see if Fam-Med readers wish to contribute their thoughts or insights. The question is: How can a practice switch EMR vendors?

Now many persons may think this isn't a very interesting question. If you choose a product well, why should you want to switch? Other persons assume this is pretty straightforward, like switching from WordPerfect to Word ^[9]. Or perhaps the user thinks it reasonable to pay someone to print every page of every record, create paper charts for every patient, then manage the conversion the same way that you one would go from paper records to electronic records.

I think this is an interesting question. There are many reasons a practice might want to change EMR vendors. A practice might be acquired, or it might be sold. It could split or merge. It could change character (FP to multispecialty). A vendor might raise rates, or go out of business, or change markets, or leave the market. A product could be suited to a small practice but not a large one, to a single site but not multiple sites, etc.

As to the change being straightforward, I believe that may not be correct. The more complex and powerful the EMR, the less likely that migration will be easy. It may even be very difficult to move a list of active problems from one product to another. Products may use no codes for problems, proprietary codes, ICD-9, SNOMED, etc. Transferring a list of immunizations as anything other than text will be difficult (does the product even accept text only immunization lists?). Then there are very tricky things, like pending tasks, reminders, alerts, etc. Labs and reports might be transferred using HL-7, but I know of no product that exports labs as HL-7, and the industry rule of thumb for HL-7 interface work is about $20,000.00 per interface. Encounters could be bundled up separately and treated as reports, but if the encounter text were formatted using (say) HTML, and the target product used RTF, they would not be readable. Then there might be ancillary data -- audit trails, digital signatures, etc.

So what do Fam-Med readers think? Is this an interesting question? How might it affect the decisions people make about adopting an EMR, particularly in mid-sized practices? Should vendors be asked to support a standard way for customers to leave them for another vendor? How might vendors (understandably) feel about such a request?

A Spectrum of Solutions

	Synopsis	Description	Comments
1.	Print and Restart	Print out all records for all patients, creating a complete set of paper charts. Start over, as with an initial product implementation (see patient with paper record and new product).	Not all products have an automated way to generate a paper record for every patient. Even if batch printing of the entire record is supported, this is obviously terribly expensive.
2.	Print to PDF and treat as a report.	Instead of batch printing to paper, batch print to PDF. Then treat each output PDF as a report which can be viewed.	Requires support for PDF files in the new product, and a way to match the output PDF files to appropriate patients and retrieve them with the new product. Some of the PFD files may be very large and hard to navigate. Significantly less costly if it can be done. See Left Behind for a discussion of why this "Print to PDF" feature may be quite important, and the relation to optical disk or other non-editable persistent storage.
3.	"Face Sheet" as coded data, rest as reports.	Demographics, active problem list, allergies/sensitivities, medication list, immunizations are sent as coded transactions. Other items are sent as individual reports or as a single PDF file. (See comments on output formats.)	One can imagine many variants in between #2, 3, and 4. Even exchanging active problem lists, is, however, currently very challenging.
4.	Major coded data and test results as transactions, some reports as HL-7 text files or PDF.	Similar to 3, but more coded material.	I don't know of any EMR-like product that exports even lab data as HL-7 transactions.
5.	The Holy Grail	Everything goes smoothly from one product to another including all coded data, health maintenance status, alerts, audit trail data, permissions, access rules, access control lists, input templates, flowsheet templates, alert and reminder medical logic modules, pediatric growth charts, ACOG pre-natal records, drug interaction modules.	Not in my lifetime -- but I'm a battle-scarred cynic.

Questions and Answers

Why should I care? I love my vendor, and they're financially stable and they're very popular. They won't go out of business and even if they did there are so many users someone would support us.: There are many reasons a practice might want to change EMR vendors in addition to dissatisfaction with an existing product. A practice might be acquired by an organization using a different product, or a change in practice management systems might mandate an EMR vendor change. Any change in character or composition of a practice might make an existing product inappropriate -- EMR products tend to be practice size specific (some target 1-3 docs, others target large integrated delivery networks, etc).

Even if the practice doesn't change, vendors do. Even Microsoft has abandoned products and markets - several times. IBM has been in and out and in and out of the healthcare marketplace. It's hard enough to judge the financial viability of a publicly traded large vendor -- but share prices are a decent starting point. It's far harder to judge the viability of a privately held company. Companies large and small can be acquired, with dramatic shifts in market focus and product direction. If a competitor acquires a company, product merger will invariably occur. Some customers may prefer to switch to a new vendor rather than accept a vendor mandated product switch.

Even if your vendor is currently successful, and even if they can today make a reasonably reliable commitment to support migration to another product, things change. People come and go. A change in the healthcare marketplace (further integration, less integration, regulation, payment change) may totally disrupt business models. As a vendor is squeezed they may be less able or inclined to delivery on such promises. It may be wiser to have an exit strategy that does not rely upon a vendor's cooperation.
So few practices actually have anything like an EMR -- isn't it premature to discuss this now?: This may be the best time to discuss the issue. If it's not addressed now, and problems become widespread, there could be a 'backlash' against all EMR deployment. I also have the (unproven) belief that many physicians are 'holding back' on committing to an EMR because they can't see how their practice could survive an implementation failure (see Why is it in the interest of vendors that customers be able to switch products?)
What about non-EMR clinical automation, like prescribing-only products?: If those products generate persistent patient-related data, such as a medication list or problem list, the issues are quite similar (though less severe).
What is the relationship of this problem with moving a patient between practices?: If two practices use the same release of the same product, it is theoretically possible that one could move all patient data from one practice to the other ^[5] (See The Holy Grail). Even this 'simplest case' transfer relates to the 'exit strategy' problem, as the existence of the 'transfer transaction' could be used to support data export. If we think about moving a patient between two practices that use different products, then this problem is identical to the one discussed here.^[6]
Why is it in the interest of vendors that customers be able to switch products?: Is it better to have 30% of a tiny and unhealthy market, or 10% of a large and healthy market? As long as purchasing an EMR is a 'lifelong commitment' with no affordable way to switch products, customers may be wise to stick with paper products.
Why would vendors ever make it easier for customers to switch?: Vendors could recognize that this is in the interests of the market as a whole, but that's a bit abstract.^[3] A vendor might also decide to make this a marketing advantage ("we're so good, we dare to let you leave us"), but customers are probably not yet experienced enough to see the point. In practice vendors have quite limited resources (no-one is getting rich building EMRs, yet) and customers have a very long list of function requests. ^[4] Vendors will not invest resources to develop this kind of functionality until major customers require it or (much less likely) it becomes a regulatory requirement.

Of course one should not expect vendors to provide this functionality for free. I could see an export function being a reasonably costly add-on module. Even if it cost a customer (say) $5000 to purchase the 'export module', this would be a fraction of the cost of doing the export with a consultant or printing all documents and starting over again. The wise customer would probably purchase this module up-front and test it out periodically, but a high cost for this module will make it less painful for the vendor to commit development resources to it.
What about escrow and other contractual protections?: I've wondered if some sort of insurance mechanism could be put in place, but in practice most escrow agreements are of limited use (see Adrian Midgley's note). Even if escrow worked, and a practice ended up with (documented!) source code, source code alone is unlikely to help much with transitioning from an EMR^[10]. Even with source code, data model, standard database access, and documentation that challenge will be great.
What about conversion vendors?: C. Erwin wrote: "... companies such as Two Point Conversion and Infowerks convert information from one system to another when a chain pharmacy, for example, acquires another small (or large) chain of stores."

Chris is correct about the conversion vendors. They exist in all IT industries and some of them are huge. The EMR marketplace is too small yet to support many such vendors, though many consultants (like myself) would be happy to take on the job.

Because so much medicine is still done in small practices, the cost of hiring a vendor like Two Point Conversion would probably be prohibitive. Barring vast consolidation of medicine (as was once expected but has since receded) I think the only way this problem can be addressed in a cost-effective fashion is to require that vendors support some standard processes for conversion as described here.
Open-source software -- is that the answer?: The application source code may be of limited value, but an open source data model can be of great value to a consultant who is handling data transfer. More importantly, an open-source model might allow someone to create and sell export solutions to the customer base.^[2]
If I switch products, how will I maintain access to my old product? What about audit trail questions (HIPAA)? What if I'm sued and the litigants request access to data that's only in my old product?: See Left Behind: The Residual Record and Legal Discovery.
How does an ASP (application service provider, remote application hosting, etc.) model affect exit strategies?: It makes the problem more acute, since in most ASP databases are not resident at the customer site.^[1] One solution to this is to create a 'data repository' at the customer site that replicates the data, but preferably not the data structure^[1], of the remote database. This repository can be incrementally updated daily from the 'source of truth' database and it can have a data structure optimized for reporting?
How does changing EMR vendors relate to ad-hoc reporting?: An ad-hoc reporting tool, by definition, allows users to extract data from a database. For example, one may ask for a list of all active diagnostic codes and diagnoses associated with all patients -- that query is the basis for transferring data to another product, particularly if the reporting tool allows query results to be saved in a standard format (comma delimited, tab delimited, Access tables, Oracle tables, XML, etc). (See also ASP exit strategy.)
What about document output formats (reports, encounters, etc)? How are they relevant?: There are two issues here. First is the format, next is the ability of the "legacy" application to output the format and the "replacement" application to accept and display it.; There are very few standard document formats. HTML/XML are obvious contenders, but the standard HTML/XML file is really a set of instructions for how a browser should construct a page -- for example, a web page will point to an image, but the HTML file does not include an image. MIME documents (such as Microsoft's web archive format used in Outlook) can tightly couple the image file and the text. PDF is probably the best overall choice, Microsoft's .DOC format is proprietary but is a de facto standard.

Of course even if the "legacy" application uses (for example) .DOC internally, or can export all documents as .DOC or .PDF, there's no certainty the "new" application will be able to display it. Successfully using a document format requires both export support (legacy product) and import/display support (replacement product).
The product is using an industry standard database, I have the data model, I can access all my data at any time and I can output all information in a standard document format. Am I okay?: The challenge may still be very large. Is there an automated way to export all that data? Is there an automated way to import and process all that data? (Doing 8,000 distinct import/export transactions might be tedious for some.)

Will the data flow as a transaction (pt data bundle, perhaps formatted as XML, is moved as a (BIG) transaction from system A to B), a series of transactions (lab data is sent as a HL-7 transactions) or as a series of import/export routines (first transfer all active problems for all patients, then all medications for all patients, then ....)?; Even if your current system is optimized for exporting this data, will your new system be able to handle it? What about semantics (meaning of data)? Allergies in one system may mean drug reactions, another system may use 'sensitivity' to include all intolerances (taste, etc).

How will data be identified as belonging to one patient (that is, how will it all be coupled together)? How will the importing program know how to 'file' the bundles (e.g. what's a coded problem, what's a text report, what's a lab result)?
What are the relevant standards efforts?: See Links. HL-7, ASTM and others all have efforts related to standardizing the data structures and semantics of the clinical record. My personal bias is that it will take many years for these efforts to bear fruit, and that there may be room for much more modest interim standard.
What's the International (esp. UK) experience?: In the UK, Netherlands and elsewhere in Europe EMR systems have been established for years. They feel the pain of this problem. See The UK Experience.
What do I (e.g. jf) think of this problem?: I think it really is a serious problem for deploying clinical automation broadly, and I think it's one of the things holding back progress on clinical automation and error reduction in the US ^[7].
Next Steps?: Educating consumers about the importance of this topic, so they in turn will require vendors to support a minimal standard for moving data. Creating a minimal and real-world standard that could be implemented within the next 2-3 years.

Left Behind: The Residual Record and Legal Discovery

When I first thought about the problem of switching EMR vendors, I focused on the clinical aspects. As I've explored this further I've realized that some of the most interesting legal issues have to do with the data in the "legacy" (abandoned, past) EMR.

If the "legacy" EMR was the true legal record (digital signatures, some sort of auditing trail, authentication, non-repudiation, access controls, etc) then the problem is more severe, but I think it's still an interesting issue even if a paper chart was being maintained as the "true" legal record. ^[11]

There are two broad issues -- one has to do with the data that doesn't get transferred from the old record to the new record. The other is more subtle, basically it has to do with maintaining the legal status of any transferred or archived data from the prior product. I'll discuss the simpler issue first.

The data that isn't transferred

As we can see from the above discussions (see esp. A Spectrum of Solutions) no transferal process will be perfect. For example, it's unlikely that all the audit data will be transferred, or all the history related to alerts and warnings ^[12]. Consider, for example, a lawsuit that relied on a question about a critical alert: when was it generated? viewed? who saw it? If the legacy record were no longer operational, how could such questions be answered? How would the jury be instructed to handle the missing evidence? Who would bear the cost of attempting to retrieve the data? There must be precedents from other industries, but I know of no precedents in medicine.

The data that is transferred: maintaining a chain of evidence

Most clinical automation systems will, as part of system security, limit the ability of users to alter data. Users cannot, generally, alter a signed encounter in any significant way. ^[13] These limits, however, will probably not apply to the data as it is being moved from system A to system B. There may be many opportunities along the way for a knowledgeable user to alter the data, without generating any kind of audit trail. Given this ability, from a legal perspective, would the (for example) "legacy" encounters have any standing? Perhaps from a legal perspective the fact that data was transferred doesn't alleviate any of the need to be able to access the legacy record, just as for The data that isn't transferred.

A proposal

I think there's a reasonable approach that would address the above issues, but the final say will have to be with the courts. There are two parts to this:

Transferred should not have legal standing. It is treated as historical data, but it cannot be assumed that the transferred encounter has not been altered -- it does not have the standard protections of data created within an EMR.
System vendors need a way to produce readily accessible legal archives of patient data that can live independently of the EMR. Simply printing paper is unlikely to suffice -- it's too easy to alter the output. An authenticated and digitally signed PDF output file, that had a structure similar to the paper chart perhaps with additional audit trails, might be an acceptable option. This file would have to be generated by the "legacy" EMR, and it would be signed using the private key of the EMR vendor. It could be attached to the patient record in the new EMR as a report, and it would be maintained separately on optical disk storage (or other persistent medium).

Why would vendors ever produce the above-mentioned legal archive output? See Why would vendors ever make it easier for customers to switch?

The UK Experience

Mike Bainbridge from the UK pointed out two relevant UK projects. The text below is paraphrased from his original posting. Note that any solution that would allow one to move patients between practices also allows a practice to move their patients between EMRs ^[6].

GP to GP record transfer - This NHS project has just re-started. It follows on from the successful Textbase project which Nick Booth presented a couple of years back at SCAMC (won the beat paper prize as I recall). This extracted data from 5 disparate systems and put the data into a common XML format which was then readable.

The standard for the message format was the CEN TC251 ENV 13606 standard which is now, as I understand it, being incorporated into the HL7 standard for clinical record transfer. There doesn't seem to be a new web site yet but I am sure this will be corrected. The project plans to allow the transfer of records in and out of different systems using this standard ...
Standard Query Language for Primary Care systems. To be sold in the UK the vendor must submit their software to an Accreditation process (see NHSIA) Part of this accreditation involves the inclusion of an 'HQL' (HEalth Query Language) interpreter. This allows a health community to extract anonymised data in a standard format for clinical audit, commissioning, governance etc. There is a crown copyright implementation of HQL called MIQUEST (Morbidity and Inquiry Export Syntax).

Contributors

Special thanks to those who have contributed to this discussion (see archives). All opinions here are my own unless otherwise noted, these persons bear no blame for what is written here. Special thanks to Adrian Midgely, Mike Bainbridge, Alan E. Zuckerman, William Davis, Bob Bernstein, and many others.

History

June 2, 2001: incorporate initial comments, develop further.
May 25, 2001: initial version.

Footnotes

[1]	An ASP database must support high transaction volumes and often requires a very high-end (e.g. Oracle) database management system. It may have an object-relational or mixed data model with many performance oriented modifications. Such a database will be very difficult for the end-user to work with and often cannot support ad-hoc report generation because of the impact of ill-formed or complex SQL queries on transactional performance.
[2]	I have reservations about the GPL license that accompanies some open source products -- which means I'm in decent company (Bret Glass, Jon Udell) and in company of ill-repute (Microsoft). If a vendor were to create code to manage transfers in and out of an open-source EMR they would have to be careful that they could choose to keep that code 'closed-source' -- if that's how they wanted to make a living.
[3]	See also "tragedy of the commons" for an introduction as to why this is unlikely to occur spontaneously.
[4]	I'd argue that the lists are usually too long and miss the most important items, but that's another page.
[5]	Actually, I don't know of any products in the US market that even do this.
[6]	This isn't obvious at first, but think about it. If you can move one patient between two practices with different EMR-like products, then you can move a collection of patients (one at a time) between two practices -- and that's switching vendors.
[7]	The big barrier is probably the way health care is purchased; in a system where the consumer is not the purchaser. That's another minor problem to be addressed elsewhere ... :-)
[8]	One recent exception: Electronic Medical Records: 10 Questions I Didn't Know to Ask. Jaymi S. Meyers, MD FPM -- see item 9. I think the author was overly optimistic about how the transfer process might work.
[9]	Typically some data would be lost in such a switch, since the two applications have different feature sets (Word compound documents, WPs way of outlining, macros, etc) but the basic structure of a wordprocessing document is relatively similar and the conversion works. OTOH, if you've every tried moving data from Outlook (allows embedded documents, internal links, complex data structures) to the Palm Desktop (very simple flat file database) you may have a bit more difficulty.
[10]	I think most people who've worked in development shops know how reluctant developers are to touch each other's code. Trying to figure out a complex application, and especially to reconstruct a data model, by looking at source code is not something most developers are keen to try -- even if the source code is exceptionately well written and documented. Having access to database schema, database tables, data models and selected source code is a much better start.
[11]	Warning: I am no lawyer. Even so, I find it hard to imagine that any kind of electronic record won't be considered as part of a Discovery process -- even if the user thinks of the paper record as the true "legal record".
[12]	Some of this data may not even be displayed in the user interface, but it may be accessible through direct examination of database tables.
[13]	Many systems allow users to "hide" encounters (e.g. encounter was dictated on the wrong patient), but typically there's a clear way in the user interface to locate and view the hidden encounter.
[14]	No-one knows how long PDF will persist, but it is being used increasingly in the DOD and government for archival storage and scanned document management.

Metadata - Keywords

Since Google does not use indexing information stored in meta tags, I've reproduced some of the meta tags here to facilitate indexing.

<meta name="author" content="John G. Faughnan">
<meta name="keywords" content="EMR,EHR, electronic health record, exit strategy, CPR, CPRI,PMRI, Patient Medical Record Information. electronic medical record, EPR, electronic patient record, clinical automation, changing vendors, HL-7, EHCR, electronic health record communication, RIM 3.0, export, transfer, conduit, jfaughnan,jgfaughnan,.en-us,.us,english">

Author: John G. Faughnan. The views and opinions expressed in this page are strictly those of the page author. Pages are updated on an irregular schedule; suggestions/fixes are welcome but they may take weeks to months to be incorporated. I reserve copyright except where noted, if you want to repost or quote a page just ask. Anyone may freely link to anything on this site and print any page; no permission is needed for linking, printing, or distributing printed copies.

Changing EMR Vendors: Exit Strategies