Rev: 08 Sep 2002.
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.
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
For some years I have been pondering a question that I've rarely seen discussed
. 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 . 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,
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?
||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.
||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.
||"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.
||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.
||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.
- 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 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  (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.
- Why is it in the interest of vendors that customers be able to
- 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.
 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. 
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. 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
- 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
- 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. One solution to this is
to create a 'data repository' at the customer site that replicates the data, but
preferably not the data structure, 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
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
- 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 .
- 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.
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,
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. 
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.
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 . 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.  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.
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
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 .
- 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
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
Consultants for assistance
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.
- June 2, 2001: incorporate initial comments, develop further.
- May 25, 2001: initial version.
||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.
||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
||See also "tragedy
of the commons" for an introduction as to why this is unlikely to occur
||I'd argue that the lists are usually too long
and miss the most important items, but that's another page.
||Actually, I don't know of any products in the US
market that even do this.
||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
||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 ... :-)
||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.
||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.
||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.
||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
||Some of this data may not even be displayed in
the user interface, but it may be accessible through direct examination of database
||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.
||No-one knows how long PDF will persist, but it
is being used increasingly in the DOD and government for archival storage and scanned
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,
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.