Migration of data from an existing EMR - Is this an unforseen Achille's Heel?

One of the big issues that has recently come to my attention and something that I have discussed with colleagues in BC and around the country is that of the migration of patient information (clinical and other data) that is stored in one EMR when migrating to a new EMR system.

One of the benefits of being an early adopter of EMR has been the ability for practices to reduce dependency on paper processes and improve recall and manage patients better by having access to data in an electronic record format. As a result, some practices have been using EMR systems for more than 20 years in Canada (the unsung hero's of this process). However, as early adopters, standards were not defined for their system developers to ensure that the data was transportable between systems. Not just a core data set of clinical information such as office notes, lab or DI information, but 'all' the patient information that exists in the record. The largest investment in any EMR system is the time it takes to enter all of the data into the system.

Work is currently underway to establish pan-Canadian standards for EMR vendors that would create a requirement for vendors to modify or build their products to meet the specific standards for data transfer in the event that a physician would migrate to another product or would need to transfer a patient record. However there is a significant 'wrinkle' in this process that needs much more debate and which to date has not received much air time.

It is not just the clinical data that needs to be transferrable between systems, but the meta-data as well. And herein lies the challenge. As a clinical example, let's say that I receive a lab result on a patient for a CEA level (used to screen for Colon Cancer) and the level is just above the upper limit of normal. I send an internal message to my receptionist asking her to contact the patient and arrange for a repeat test in 6 months time. This is recorded in the EMR in addition to the contact that is made with the patient by the receptionist. However the patient does not return for follow up and when see 18 months later for an unrelated problem mentions some rectal bleeding - probably due to hemorrhoids. Investigation reveals an advanced adenocarcinoma of the rectum and the patient denies any effort by my office to contact him for follow up on the initially slightly abnormal CEA resut. In the interim, I have migrated to a new EMR system with all the bells and whistles, however the 'meta data' did not transfer with the migration. I have all my clinical notes and reports, but not the audit trail of what was said and done to try and contact the patient. The audit trail no longer exists as I do not have my old EMR system anymore. How would I defend myself in this situation?

The point I am trying to make is that if an existing user of an EMR decides to migrate to a new system, there may be a medico-legal imperitive for that physician to maintain a copy of the 'old' EMR system INDEFINITELY on an additional computer in the office in the event that an audit trail would need to be produced in the future. This is a very real problem.

Do you feel it is overstated as I have described the issue? Do you have any solutions or suggestions on how to deal with this problem? Who assumes the cost of supporting the old EMR? For how many years would it be necessary to maintain a copy of the original EMR? I am sure there are many more questions.

To comment, click on the 'Comments' link below.

Comments

[James Busser]

Please pardon the overlap, I am reposting this, having already emailed eslewhere the position which follows.

The long-term usability (future-proofing) of doctors' clinical data despite the possibility of choosing --- or needing --- to switch vendors (whether on account of insolvency, inadequate price/performance or whatever) should be a prime concern for any doctor contemplating an EMR.

We know that with EMR software there are many worries. "Performance agreements", though they can have value, should not be viewed as an adequate solution to this challenge.

The selection of an EMR is a key step, but as noted the Achilles heel comes having input one's data and any subsequent dependency on the data for clinical, practice management and medicolegal /quality assurance needs.

Vendors can
- lose data, or permit its corruption
- provide inadequate uptime, function, problem-solving, enhancements, and other services, and/or
- objectionably alter requirements or fees

Therefore while it is helpful to define these within a contract and through performance agreements, it is crucial to hold safe that

- all data that can be characterized as being re-usable and

- the full record of care, including alterations and logs of access, to the extent that it is clinically useful *or* may be required for practice management *or* medicolegally.

Accordingly, any framework agreement must

- make it feasible to transfer useful data into an alternate system and

- to affordably preserve access to required historical ("legacy") data where it cannot readily be transferred *into* an alternate system.

It is therefore incumbent on a framework to require that, especially where an EMR service provider should cease or wish to actively terminate service, but even if only at the decision of a client to terminate their agreement, it must be possible for the client to

- extract defined data, in a defined format, within a previously-negotiated limited one-time charge, and

- to continue to access (without ability to alter) that legacy data which was not defined or feasible to be transferred, but which continued to remain required for care, practice management or medicolegal purposes, and to be able to do so on a cost-reduced and, ideally, near-cost-recovery basis such as cost + 10%.

In the case of proprietary or "closed" EMR source code where the service provider may be defunct, escrow agreements may need to have been established in advance.

The prudent doctor should assure in advance that their record of care will be affordably and reliably accessible for at least 7 years past the age of majority or whatever maximally defines the limit of their accountability for patients' care.

[Mike Ramsden]

This will become increasingly troublesome with competition and consolidation, and expensive.

I migrated vendors somewhat over a year ago. I got very little help from my previous EMR vender (the change was prompted by changes in their front end/EMR package which led to the EMR becoming unavailable in the future) and found out subsequently that even the initial vendor had great difficulty extracting data from the EMR because of a sundering of the relationship from the provider of the EMR. That provider was not willing to supply any help to customers of the original supplier!

Fortunately, the vendor I migrated to was able to extract the data although it was not a straightforward process. This process imported only the clinical notes, documents and laboratory info. The clinical notes contain notation about (later) edits to correct errors however there was no way to import a log of the pre-correction clinical information, which is still present on the original database (as long as it continues to run!)

The metadata theefore was not captured well. Communication within the office was not captured at all by the system since their product was a hybrid. Messaging was not part of the package and is handled by Outlook within our office and unfortunately not integrated whatsoever. To keep track of messages where I feel it important, I would have to generate an encounter and "cut and paste." (the message log is available but not integrated.)

As far as the actual database goes, I have kept the original system running, since my new package required a new server. That means I am now running two servers, and two battery backups to power them. I dread the time when my original server, now 4 years old, fails. Hopefully it will have been 7 years (the Magic number).

This could become an interesting issue in B.C. for a significant proportion of current EMR users if they decide to migrate (if necessary) to new "approved" systems. What process will be in place to facilitate (where previous vendors are accomodating) or compel (where they are not) the process of migration? Some vendors tout their use of open standards however may still lock down their data.

It will be interesting as well, as was brought up in a meeting earlier this week of current users facing this issue, what cost issues might be required to continue to run a separate system in parallel to maintain the metadata as mentioned above. What licensing fees might be demanded to continue to run an the "old" system simply to maintain data which is no longer being used, but which is there "just in case" someone wants to review it in 6 years, even though all the clinical data was able to be imported?

You raise some interesting ideas. Should we be hopeful that these will be raised and addressed at this stage in the process of "designing" the future BC EMR package?

[Morgan Price]

Alan, Jim, and Mike

This is one of the challenging issues that is being faced everywhere and there is not a good solution that I have seen.

Not only do we need to transfer the data, but the context and progression of that data as it was used and developed as well.

There are few models of EMR data that even prescribe how to capture this consistently. These models are used in a surprisingly few number of products, thus making the conversion much harder.

Many systems do not capture all the data needed to do this properly so it cannot be exported.

The tricky part is mandating something that has not been defined --> what has to be exportable, down to the level of the data elements and meta data for each element, has not been defined anywhere that I know of yet in Canada.

It's a big task and one that has to be tackled. As I have said elsewhehre, much of the value of the EMR is in the data and how we as providers can access it and see trends, improvements, gaps, etc. Conversions lose that and they must not.

Morgan

[Bob Mullan]

as a prospective first time EMR buyer this discussion is very interesting. I will need to look at the proposed contract and see if it includes protection for data in a future migration.
Bob

[Michael Rath]

Alan has a valid point.

I think that there is a fairly simple solution:

"Practice Solutions" has a lovely interface that shows the entire medical record as a chronologically arranged "toilet paper roll" of events, including patient encounters, lab data, etc. What is needed is a "Chronological Display" feature, that looks just like the encounter printout common to most EMRs, but which integrates EVERYTHING, including encounter notes, lab results, tasks (internal communications),consult reports, appointments and anything else which is entered into the EMR. Everything is positioned sequentially according to the electronic date/time stamp. This could be printed to paper or to a pdf file which is then attached to the new EMR as a document. Not only does this solve the medicolegal issue, it provides a "view" of the chart which can be very useful from a workflow standpoint.

Michael

[Morgan Price]

Michael

This is definitely one approach that meets the requirements.

however, it creates, what I have been calling, an "EPR" or Electronic Paper Record that might not be useful to improve workflows, generate reminders, etc.

Having this output might be required for all EMRs but I worry that it not be seen as sufficient.

[Alan Brookstone on behalf of Dr. Brendan Byrne]

The following comments were submitted by Dr. Brendan Byrne. He provides some valuable insight. As Dr. Byrne is an EMR vendor, I have posted these comments on his behalf.

Transitioning from one EMR system to another is a complex process that needs some real thought. Here are some observations on the issue:

1. Proprietary vs. Non-Proprietary data structures PART 1– for all intents and purposes all EMR’s have a proprietary data structure. Open EMR standards are not specific enough to be true data standards for the purpose of data conversion.

2. Proprietary vs. Non-Proprietary data structures PART 2 – for all intents and purposes EMR’s that support the ODBC (Open Database Connectivity) standard are open and allow for data to be transferred.

3. Data Conversion is done for the purpose of office and clinical workflow – not for medico-legal purposes. The converted data is brought into the new systems so that the physician can move through the patient record without switching back and forth between systems. The converted data will not hold up in court as a true representation of the clinical record.

4. Projects like Alberta’s ToPD/CoPD(Transfer of Patient Data/Conversion of Patient Data) will allow for a useful data conversion for workflow purposes but will not contain all clinical patient data in the exact form that it was originally entered – and therefore it will not be the medico-legal record.

5. For Medico-legal purposes physicians must retain the ability to print from their original EMR system. This means that physicians have two real choices:
a. Maintain their old system server indefinitely
b. Print out all of their patient records and file them until they are needed
Either choice is problematic. Maintaining the old system without support from the original vendor may be challenging after several years. Printing out all records defeats the purpose behind moving to a chartless office.

6. The old EMR system is really like “Volume One” and the new EMR “Volume Two” and just like your paper charts “Volume One” needs to be safely stored until it is needed in the future.

7. An ideal solution to maintaining the old system is to convert the old server into a format that can then be re-created on any PC. It is now possible to convert the complete server to a hardware neutral format that can even be stored on DVD. With this type of backup, physicians have insurance against hardware failures on their old system, as they can move their old system to new inexpensive hardware at anytime. The DVD images of the old server can be kept in a safety deposit box. With this solution, physicians will be able to print their patient records from their old system at any time indefinitely.

8. A practical suggestion when converting to a new EMR is to go through all your patients that you have any reason to believe may require a medico-legal report or chart request and print these charts out to paper or pdf.

[Alan Brookstone]

The following comment was received by e-mail from a colleague in Alberta:

"Printing charts out from most EMR's does not capture workflow or messaging very well and those are important items needed in a medical legal case regardless if you are involved or not.

An additional problem in trying to keep the legacy computer system intact is that the operating system (including maintenance patches) and hardware may be obsolete and unsupported before 10 years have occurred."

[Ron Joe]

Migration of data and metadata from one EMR to another could be greatly simplified if not solved by standardizing the database. As I mentioned in a previous posting, an Electronic Medical Database (EMD) standard which defines how clinical events are stored into database tables will enable any vendor to retrieve that data and its clinical context in the way it was recorded. Using an EMD, or middleware application to orchestrate these data requests will give physicians the confidence they need to delve into this technology without fear of data loss or degradation when switching between software vendors. Having a standard middleware – EMD application will also obviate the need for data translation. Sound too simple? BC can become a world leader by adopting such a strategy and the time is right for such an innovative solution which addresses the major concerns mentioned above.