Transfer of Patient Data. What do you do if your Vendor goes out of Business?

The following question and commentary is provided by Dr. David Vincent. As it is an issue that is great importance, I have posted it on his behalf.

"I have a concern that I would be interested to see if others have a solution to. I have used EMR for almost four years now. I have spent 100's of hours inputing data for CPP maintenance. My concern is that if my vendor ceases to support his program, which isinternet based, for reasons of bankrupcy, non compliance re provincial standards. Or should the Ontario government finally get to the point where they are seriously supporting physicians in acquiring and maintaning EMR, and the program I use does not "work" with their system, I have no way that I am aware of, of moving all the work I have done into another EMR software. Most companies will only guarantee migration of patient demographics,and nothing else. This is a big disincentive for me to change programs as all this time I have personally spent would be lost.

AS I get deeper into this process I am worried that if I had to change programs for any reason that the task as I see now of reentering all that information would be so daunting that I would likely give up Family practice and start something new. This is the big "time" gamble of going into full EMR, with one of the many companies that provide it. In the future I don't see how all of the current EMR companies will survive as EMR evolves and the government fully supports it and therefore will have their own standards. The company I work with does give me backup files in pdf format when ever I ask for them, so I can at least have a local back up. Are the leaders at the government/policy level looking at this issue so that when the time comes, people like myself, will have some way of transferring data to a new program that will not take 100's of hours again?

I would think that vendors should have to show how they are going to deal with this issue before becoming an approved EMR vendor. Or alternatively does anyone know of a software program that could convert this information into another program? I would appreciate any comments or advice anyone may have on this issue. Dr. David Vincent."

To comment on this posting, please click on the 'Comments' link below.

Comments

[Alan Brookstone]

David,

You have captured very succinctly the issue that faces many physicians who have implemented an EMR. What happens to your data if your vendor goes out of business or ceases to be 'acceptable' based on changes in provincial or national standards or vendor compliance programs. The greatest cost associated with a 'full' EMR implementation is not the cost of the hardware, software or support. It is the hundreds (or thousands) of hours of your time (@ $150 - $200 per hour) that are spent entering data into your system for clinical purposes or as you mention above - CPP maintenance.

There is no simple solution to this problem. As we are still very underimplemented in EMR as far as national adoption is concerned, it is likely that there will be much consolidation in the marketplace before we reach a stable state. If you look at more developed settings such as the UK, there are much fewer vendors providing EMR software with a significantly larger client base. There are also enforced standards as far as transfer of data is concerned to ensure that data is transportable from one vendor to another.

The issue comes down to standards. Until there are required standards for the capture (and transfer) of information between systems (and all of the vendors are in conformance with the standard), there is no easy solution to this problem. One of the other difficulties that we face is that the problem extends beyond the requirement for vendor standards. For example, in Canada we have generally used ICD 9 (or ICD10 codes more recently) to record clinical descriptions of the data that we submit to our provincial medical plans for billing purposes. There has been no requirement for quality in data coding during this time. For example, you could use a 781 code for musculoskeletal disorder vs. 724 for back pain and still get paid by the provincial payment agency. As a result, when your data is transferred to a new EMR, without a standard terminology that is accurate and relevant, it may not be possible to put your data in the correct place in the new system. This is also complicated by the fact that there are provincial variants of the ICD9 coding system that evolved over a period of time.

I am keen to hear other physicians views on this issue as it is one that will be a significant problem in the future.

[Guy Gokiert]

we live in the land of plenty-called Alberta. We have a program to allow docs to engage in EMRs but that program may well go away with the new negotiations now ongoing.
We have had that very scenario happen in our office with the result as David predicted. The new company claimed it could transport the data from the old EMR but we get very little other than the notes and no lab or other data.
It is frustrating and we are not hopeful that the next move-if it has to happen-will even provide more frustration and problems.
Guy Gokiert in Westlock, AB

[Ian Gillespie]

When BC converted to electronic billing in the late 1980s, there were about 90 companies competing for the narrow vertical software market. The BCMA Computer Committee required any vendor that received a "BCMA approved" rating to be a member of the Medical Software Vendors Association and to have an export/import utility for demographic information in a standardized file format.
Benefits were that no vendor could retain an MD as a user of their software simply because of the disincentive of repeat data entry AND prices and support became much more competitive.
EMRs contain a lot more data in varied formats and .pdf output is not satisfactory for data transfer even if its a very useful standard for printing and viewing data. It would be of great benefit for the CMA, with provincial division support, to define (or adopt an existing) standard data format that specified the field names, field size, and field format for not only demographic data, but for everything that might be entered in an electronic medical summary record.
Diagnosis used for billing could be a different field than a longer text-based diagnostic description field, as the billing diagnostic code may be simplified and not contain the detail used clinically. Would welcome any collaboration in advocating for such an initiative.

[Tim Janzen]

Dr. Brookstone is correct that many of the vendors in AB have varying standards for exporting data. That is until now. It is my understanding that the VCUR 2006 requirements predominantly deal with the issue of exporting patient information.

VCUR - Vendor Conformance Useability Requirements - which were set up in consultation with vendors, physicians and the government. A physician can only receive government funding if the vendor's current version meets the requirements.

While the VCUR standards aren't perfect, they have moved the bar higher and we all hope this will be the case for exporting data. It will mean that physicians can freely move between softwares that fit their needs.

It is my understanding that the VCUR 2008 standards are to be negotiated with other provincial regulatory bodies with the hopes of achieving a national standard.

[Ian Gillespie]

That's great news in Tim Janzen's post about the VCUR standards. Online searching found that the Alberta Tri-partite Master Agreement of 2003 agreed to implement VCUR not later than March 31, 2004. Any information about whether the current standards are in the public domain and, if so, how they can be accessed? Also, anything about the proposed negotiation process to achieve a national standard?

[Jel Coward]

Why would anyone choose to be locked in to a vendor that could go out of business? Ok, so I did it in the UK - and got badly bitten - suffered data loss and many hours were put in to trying to save what I could.

Now, I would __never__ do that. When we selected our EMR here in Canada, I had one criterion - it had to be Open Source. OSCAR has a number of companies that can install, support and develop it because the source code is shared freely. If one company ceases operations, there are others. This freedom of choice is great - and the security of not relying on a single company for the survival of the product is even better.
Is it unethical to lock information that belongs to patients (and may be critical to their lives) into the fortunes of one company? I suggest that it is not.

[Morgan Price]

This is a very significant and real issue.

What if you have to maintain the record for 7 seven years for medicolegal reasons?

What if a patient just moves to another city and you need to transfer the records?

Jel raises an important approach to avoid lock in and one that there is a lot of confusion about.

The other part is to realize that the data you put in needs to be able to come out. We do not have these standards to do that yet. They are not "fun" to work on but they are key. Ask your vendors about how they are working towards this.

Morgan

[Eugene Leduc]

As others have stated, a database standard for transfer of data between vendors is needed in Canada. The CMA would be a likely body to lobby for this but with their vested interest in one vendor, they are now in a conflict of interest. I don't hold out much hope there. Perhaps this is where government may be able to help: the Alberta VCUR specifications being a good example.

[Jel Coward]

Morgan appropriately asks the following:
What if you have to maintain the record for 7 seven years for medicolegal reasons?

Jel replies:
Absolutely! If the vendor is still in business you can choose to keep paying them for a license to use their product (if they continue to support it of course...). If they are out of business, you had better hope that the software is robust enough to let you continue running a standalone version without any support....the chances of this seem slim given a recent survey in BC showing average 'down time' of 1.8 hours a month _with_ support. Oh, but the latter might not even be legal if you don't _own_ the software.
...or, if you have an open-source EMR, you can keep running it and get one of the multitude of folks able to support it, to do just that...and they will have to compete on price.

Morgan wrote:
The other part is to realize that the data you put in needs to be able to come out. We do not have these standards to do that yet. They are not "fun" to work on but they are key. Ask your vendors about how they are working towards this.

Jel replys:
Having been involved with EMRs since the early 90's I can say that every vendor I have ever talked to has said that they are working on this....and yet I have not seen one of them deliver on the production of a utility to migrate data to another vendors software. I have always wondered about the reasons, and I try to resist the temptation of jumping to unkind conclusions. When asking vendors about this, remember that being able to produce an exportable limited data set is _not_ the same thing as being able to export the entire medical record.

[Adam Chen]

Our software vendor has a standard clause in the contract to allow keeping an indefinite standalone version of the software, so in case of termination we will still have access to patient files, indefinitely without fees.

Fortunately we don't anticipate having to switch. But if forced by circumstances, I would find it quite acceptable to just import data sets and not the entire file. Electronic clutter seems just as problematic as paper clutter.

It would be ideal to have all the info on Cumulative Patient Profile transferred. Perhaps it can be used as a test for new vendor selection, to check for integrity of data transferred. Ontario OHIP still uses ICD-6 codes, so we won't expect perfect translation of the problem list.

One can also transfer clinical notes on an "as needed" basis. Using old software, one can "print" using a pdf writer, then transfer the pdf file generated into the new program and link to patient file. This feature is available for free with PaperPort that comes with many new scanners and multi-function machines nowadays (Brothers, Xerox).

[Michael Rath]

I may have come up with a solution to this.

Most EMRs have a means of attaching scanned in documents. The EMR creates a link to the document, wherever it may reside.

Since locums often work at my clinic, I wanted the option of letting them fill out a paper encounter sheet in lieu of using the EMR. The encounter sheet is then scanned in as a "visit" attachment.

The folder for the "visit" attachment exists as a subfolder of a folder tree as descibed in the "Paperport" thread. Visits, Imaging reports, Consults all comprise items in a Paperport style folder tree, which is accessed from within the EMR.

Of course, the Paperport folder can be accessed independent of the EMR and read with a Paperport reader or with Adobe Reader. To keep the Paperport file complete, each electronic visit can be "printed to file" and converted to a compressed pdf document to be inserted along with the scanned information.

The result is a database within the EMR database, one which is completely reproducible and transferable.

[Jel Coward]

Adam wrote:
'Our software vendor has a standard clause in the contract to allow keeping an indefinite standalone version of the software, so in case of termination we will still have access to patient files, indefinitely without fees.'

Have you asked the following questions?
1. What is meant by 'standalone'? Is it one machine, without being networked? If so then that might be quite awkward from a workflow perspective.

2. What if the 'standalone' version breaks? Who can fix it? (I don't mean legally, I mean, who would actually be able to do that? My worry being that if it is not open source then that might be quite difficult, if not impossible.

3. Have you asked them if you can have access to, and export as you see fit, the database?

[Adam Chen]

Our software uses an Escrow agent for source code, which verifies on an annual basis whether the code is compatible with the updated version of EMR. This allows data export in the event of the vendor's business closure. We have not yet subscribed to the Escrow service, but can do so at any time.

The database is considered "Property of the Clinic" in our contract. We would need to use the source codes to export information on the Cumulative Patient Profile, but scanned documents can be simply transferred by save, cut and paste.

Jel rightly points out the difficulty working out of one computer. In the event of vendor closure, we will retain all existing network set-up; the "One copy" applies only if we terminate the contract. In case the program malfunctions, we can still contact the vendor for reparation.

[Steve Cronje]

I cannot agree more with what Jel Coward has to say in this thread.

Open Source, in my opinion, is the only way to go.

That goes for both the CODE, and the DATABASE. Using an open source database makes the retrieval of information in the event of provider rigor mortis much more convenient and easily achievable.

I would also like to see standards related to WHAT open source software (OSS) is deemed acceptable, especially for the database side of things.

There is some OSS that is stable, well-documented and mature. Others are not. It is not enough that we use OSS, it needs to be a pre-condition, from which further guarantees are sought.

OSS also eliminates vendor and OS lock-in. I have not used Windows for many years now, but need to run it on one machine so I can do my billings, as I cannot validate access to my payor with anything other than a Windows or Mac OS (I run Linux). Try explaining that to an IT department that runs Microsoft software only!

[Ron Joe]

The EMR/EHR/EPR distinction seems to relate to the custodianship of data, but how about a different concept which could blur the edges while at the same time potentially solve some of the frequently identified problems which exist in electronic records today.

How about the concept of an Electronic Medical Database (EMD). Rather than each implementation defining itself from the ground up for EMR, EPR, DI, LIS, CPOE implementations, why can we not agree on a core database structure to which all these intended applications can add or query? The generic query language would be of a higher level than a SQL database which would optimize development time. It relieves each intended application of the burden of implementing separately and disparately, the intricacies of database structure and storage rewriting their own versions which simply makes smooth interoperability impossible. Why don’t we develop a structure which can constructively solve many of the questions relating to electronic records. A fundamental change in standards can be tweaked at this level. If ICD9 changes to SNOMED, then it can be changed at the core database level for all of us to enjoy and not worry about. If the fee guide changes why should we need to update our EMR software? Again, it should be part of the core services. A new immunization to code? Why should every vendor need to go back to their database tables to update it? Someone at the health department can do this. The Good European Health Record (GEHR) standard may be a good start, in fact, it’s the only completed EMR standard I’ve seen and it looks pretty darn good. If we all use the same database structure then we can support each other. Transfer a medical record to another facility? Do a simple SQL query for patient “Jane”, define the scope, and use a simple export command to the recipient’s EMD, like magic, its in, it sounds too simple? No fields to translate, no incomplete data worries. It’s all in. If your EMR company goes belly up, just use another front-end, or you may not even need to, remember, all base tables are changed at the core abstraction layer in the EMD. With this scheme, physicians would retain the custodianship of their own patient data, as would as each stakeholder in the healthcare equation. The intricacies of permissions and grant of access can be implemented with an interface engine (that’s another story).